J Netw Syst Manage DOI 10.1007/s10922-013-9271-7

Policy and Charging Control for Virtual IMS Client Salekul Islam • Jean-Charles Gre´goire

Received: 5 July 2012 / Revised: 15 February 2013 / Accepted: 18 February 2013 Ó Springer Science+Business Media New York 2013

Abstract In its latest releases, the IP multimedia subsystem (IMS) service model provisions Quality of Service (QoS) and enforces charging through its policy and charging control (PCC) architecture. By exploiting the intrinsic segregation of the signalling and media planes that the IMS service model offers, a virtual IMS client could be developed that simplifies terminal device implementation by offloading signalling and session management tasks to a remote server. In this paper, we study how the IMS/PCC architecture can be deployed in conjunction with a virtual IMS client. Although a virtual IMS client assigns the signalling tasks (accomplished through session initiation protocol and session description protocol) to a remote server, information related to QoS should be propagated back to the access network and also the end user’s terminal device. Therefore, designing a virtual IMS client that only deals with the media plane is challenging. In this paper, we propose a PCC architecture for the virtual IMS client that keeps the end user’s terminal as simple as possible while providing the necessary functions of the IMS/PCC architecture. Since QoS provisioning is access network specific, we explore the proposed architecture for two predominant networks access methods: UMTS from 3GPP and WLAN from IP-based access. Keywords IMS
Virtual client
QoS provisioning
Charging control
Policy enforcement
Roaming

S. Islam (&) Computer Science and Engineering Department, United International University, Dhaka, Bangladesh e-mail: [email protected] J.-C. Gre´goire E´nergie Mate´riaux Te´le´communications, Institut national de la recherche scientifique, Montreal, Canada e-mail: [email protected]

123

J Netw Syst Manage

Abbreviations 3GPP 3rd generation partnership project AAA Authentication, access and accounting BS Bearer service CSCF Call session control functions EPS Evolved packet system GW Gateway H-PCRF Home PCRF IMS IP multimedia subsystem IP-CAN IP connectivity access network OCS Online charging system OFCS Offline charging system PCC Policy and charging control PCEF Policy and charging enforcement function PCRF Policy and charging rules function PDN Packet data network PDN-GW PDN gateway SDP Session description protocol Serving-GW Service gateway SIP Session initiation protocol UE User equipment V-PCRF Visiting PCRF WAG WLAN access gateway WLAN Wireless local area networks

1 Introduction The IP multimedia subsystem (IMS) [1] is a session initiation protocol (SIP) [2]based generic architectural framework for delivering voice, video and data communication services to mobile and fixed users. The IMS service model offers a horizontal layer of infrastructure/transport at the bottom, supporting an application layer above. The benefit of IMS is to provide, through its middleware, accessindependent, unique and common mechanisms for Quality of Service (QoS), charging, authentication, security, etc. In its latest release [3], the IMS service model addresses the combination of policy enforcement and charging through its policy and charging control (PCC) architecture. In the PCC architecture, QoS provisioning has been accomplished through policy enforcement (e.g., users cannot use more than a certain bandwidth during peak hours). Policy control is also needed to enforce charging decisions (e.g., when a user runs out of credit the ongoing sessions the user is involved in may have to be terminated). Note that, policy control and charging are not always co-located and there are several aspects in which they are not related. In the world of computing, the term virtualization refers to the creation and management of a virtual version of a resource that is normally provided in a

123

J Netw Syst Manage

physical way. This concept can be extended to any type of hardware or software resource. While most of the recent efforts on virtualization have focused on moving server-side computing resources into the cloud, there is also an increased interest in the simplification of the user terminal’s functions. Virtual clients, first as remote desktops but later as access to remote applications, have proven to be cost-effective for corporate use, e.g. for employees in offices. They have only recently emerged in the general public as a trend to the application-as-a-service (AaaS), running in a remote server, accessed through the Internet, through the Web browser. We have previously [4] studied a virtual IMS client that keeps its simplicity by offloading signalling and session management tasks to a remote server we name a surrogate. The surrogate implements the IMS client and accomplishes communication with the IMS core on behalf of the virtual client. Although the virtual IMS client [4] provides a number of benefits including lightweight user equipment (UE), network access mode agnosticism, multiplexing IMS registrations, reduced cost, etc., QoS provisioning and proper charging techniques are yet to be addressed. In this paper, we focus on a PCC architecture for virtual IMS clients, including support for roaming. An end user is willing to have ubiquitous access to services maintaining the same QoS even when she is not geographically located in her home network. IMS supports mainly two types of roaming: visited access and home routed access (the SIP signalling proxy is located in the home network). Using the PCC architecture, operators can provide seamless roaming support for both cases, apply dynamic PCC, and provide the same QoS to the user. Since a virtual IMS client decouples the end user’s terminal device from the IMS client, the virtual IMS client might well always remain deployed inside the home network. Hence, the end user could communicate with the IMS core through the virtual IMS client no matter whether she is getting IP access from the home or the visited network. The virtual IMS client, by taking advantage of this, could support a PCC architecture that reduces inter-network communications (between the home and the visited network). In this paper, we design an access architecture for the virtual IMS client. Although IMS was originally designed by the wireless standards body, 3rd generation partnership project (3GPP) for the UMTS, it was later extended to support other IP connectivity access networks (IP-CAN), such as Wireless LAN (WLAN), CDMA 2000 and fixed line through the Next Generation Networking [5] architecture. Note that although QoS and charging policies are determined and then supplied by the home network to the IP-CAN, the actual policy enforcement is accomplished while media is delivered through the IP-CAN to the end user’s device. Therefore, any study on QoS provisioning and charging in IMS should address different types of IP-CANs individually, which is beyond the scope of this paper. Hence, in this paper, we primarily include two predominant networks access technologies: UMTS from 3GPP and WLAN from IP-based access. The paper is organized as follows. In the next section we present the IMS PCC architecture, and then, in Sect. 3, we introduce our earlier work on client virtualization. Section 4 describes how client virtualization is extended to support IMS PCC. In Sect. 5, we present use cases of two specific issues—QoS and

123

J Netw Syst Manage

charging—and discuss how they are handled in our virtualized model. The next section summarizes different benefits, limitations, and open issues that need to be addressed in the proposed model. Section 7 presents related work and Sect. 8 is the conclusion.

2 IMS PCC Architecture The PCC architecture encompasses two main functions: policy control (e.g., gating control, QoS control, QoS signalling, etc.) and flow based charging (that includes charging control and online credit control). We observe that an IMS virtual client user and a roaming user access IMS services similarly, i.e., the end user might be geographically located outside the home network. Therefore, our description of IMS technology starts with PCC architecture in the case of roaming users. Based on the location (in visited or home networks) of the policy and charging enforcement functions (PCEF), control functions (P-CSCF) and the users’ subscription database (not shown in this paper), different scenarios exist for QoS provisioning to roaming users [6]. Since the virtual IMS client communicates through the home network’s P-CSCF, we continue our discussion with the visited access or local breakout (where the PCEF resides inside the visited network) PCC architecture while the P-CSCF is located in the home network [1]. Figure 1 depicts this PCC architecture. A similar but slightly different architecture exists for the home routed access roaming scenario. In the rest of this paper, our discussion is limited to visited access roaming, although the extensions and/or modifications presented in this paper could be applicable to home routed access roaming. Figure 1 also clearly identifies the two orthogonal planes—signalling path and media flow path—that are separated by the IMS service model. Finally, in this figure, we show two different access types: UMTS/3GPP and IP-based WLAN. 2.1 IMS Core The IMS core [1] implements functional components for call control including different, specialized call session control functions (CSCF), namely the proxy CSCF

Fig. 1 Policy and charging control architecture in IMS for visited access roaming

123

J Netw Syst Manage

(P-CSCF), the interrogating CSCF (I-CSCF), and the Serving CSCF (S-CSCF). All can be considered extensions of SIP proxies. The P-CSCF is the first proxy encountered by the user requests. They are forwarded to the signalling plane’s central switching node, the S-CSCF, which can process requests based on the user profile. When roaming, requests go through a P-CSCF in the visiting network to the S-CSCF in the home network through a special relay located at the edge of the home network, the I-CSCF. The home subscriber server (HSS) is the master user database and supports the IMS network entities to handle calls and service sessions. IMS supports user-to-user or user-to-network services, with the support of application servers (AS). 2.2 Key Functional Entities of PCC Architecture The existing PCC architecture has evolved through a succession of 3GPP Releases, with R8 introducing two key elements: the policy and charging rules function (PCRF) and the PCEF. The PCRF is responsible for making PCC decisions on receiving session and media-related information from the P-CSCF. The PCEF is a logical entity that enforces policy decisions made by the PCRF. It resides in the PDN-GW (Packet Data Network Gateway) that provides connectivity from the UE to external PDNs by being the point of exit and entry of traffic for the UE. In the case of WLAN access, the PDN-GW is the edge router in the 3G home domain that establishes and controls the connection of the user to the external network and services (i.e., IMS overlay) located in the 3G domain [7]. IMS enables flexible alternatives for charging through the online charging system (OCS) for pre-paid type charging and the offline charging system (OFCS) for postpaid type charging [8]. The interface between the PCEF and the OCS shown in Fig. 1 is being used for online credit control for service data flow based charging. For a visited access, the PCEF in the visited network may use a proxy-OCS between the PCEF and the OCS of the home network [3, 9]. Although the OCS and the OFCS have been included in the PCC architecture, the charging architecture is composed of other key entities that we discuss later in Sect. 2.6 2.3 Access Specific Elements Different access technologies support access to IMS in their own way, adding devices as they require for proper interface with the IMS core. For example, in the case of 3GPP access we find the SGSN (Serving GPRS Support Node), located inside the Serving-GW. It is required that a form of access control be performed and a bridge to IMS access be implemented to recover the user profile and implement its preferences. Therefore, these elements must support a number of functions, obviously including AAA (Authentication, Access and Accounting), but also QoS and also enforcement of various policies, such as time limitation, limits on bandwidth consumption, and also possibly user priority. However, the extent to which these functions are supported may depend on the access technology used. While they are fully supported in 3G networks, it is a different matter for WLAN access [7]. In this case,

123

J Netw Syst Manage

we have the AAA Peer (that interacts with the AAA Server through the AAA Proxy) and WAG (WLAN Access Gateway). The WAG is the entry point for the UE that forwards data towards the PDN-GW. This access readily supports authorization and accounting and also policies integrated with the IMS core, but only in as much as they are implemented by the WAG. Support for QoS is another issue altogether, as we study below. 2.4 QoS Provisioning in 3G Access For QoS provisioning, the PCC architecture enforces PCC and QoS rules. The PCC rules detect a packet belonging to a service data flow. The QoS rules are derived from the PCC rules [10]. These rules might be defined dynamically by the Home PCRF (H-PCRF) or preconfigured in the PCEF. The services are defined in the home network, and their requirements must be transmitted to the visited network. The H-PCRF can provision PCC (and also the extracted QoS) rules to the PCEF (via the V-PCRF) of the visited network in two ways: Push mode The H-PCRF pushes the PCC rules unilaterally to the PCEF (through the V-PCRF) when the rules are selected. Pull mode The PCC (QoS) rules are pulled (requested) by the PCEF (through the V-PCRF) when it receives a PDP context activation request from the end user terminal. The interaction between the UE and the serving gateway is shown in Fig. 2. Inside the PCEF, there exists an IP bearer service (BS) manager that manages the IP BS using a standard IP mechanism [11]. The translation/mapping function (not shown in Fig. 1) provides the interworking between the mechanism and parameters used within the Access Specific BS and those used within the IP BS. It resides in the serving gateway and optionally in the UE. In the serving gateway, the IP QoS parameters are mapped into access-specific QoS parameters, where needed. In the UE, the QoS requirements determined from the application layer (e.g., SDP) are mapped either to the PDP context parameters or to IP layer parameters (e.g., RSVP). The access specific BS manager handles resource reservation requests from the UE. It resides in the serving gateway and in the UE. In the case of 3GPP access, the message sequence for QoS provisioning in the PCC architecture is shown in Fig. 3. In this figure, we assume that the pull mode is being used for QoS provisioning. The messages’ sequence is explained in the following: (Steps 1–5) The IMS client initiates an IMS session. From the end-to-end SIP and session description protocol (SDP) [12] message-exchange during IMS session establishment, the P-CSCF extracts SDP information describing the session to be established and forwards this information to the H-PCRF by sending an AAR (AA-Request) message.

123

J Netw Syst Manage

Fig. 2 Interaction between UE and Serving Gateway

(Steps 6–8) The H-PCRF stores service information and identifies the IP CAN session. With the session description, the H-PCRF selects a set of PCC rules for the session. The PCRF returns an AAA (AA-Answer) message to the P-CSCF. Next, the P-CSCF sends the final SDP answer to the IMS client. (Step 9) On receiving the SDP information, the IMS client application maps the SDP information to access specific (e.g., UMTS) QoS parameters (depending on the IP CAN of the end users terminal). (Steps 10–12) When the end user terminal performs the PDP Context Activation procedure, the PCEF (serving gateway) requests the IP QoS parameter authorization (i.e., the PCC rules to be applied) from the V-PCRF by sending a credit-control request (CCR) message. The V-PCRF forwards the CCR message to the H-PCRF. (Steps 13–16) The H-PCRF installs the previously selected PCC rules in the PCEF by authorizing the PCC rules and generating the QoS rules. The H-PCRF replies with a credit-control answer (CCA) carrying authorized IP QoS parameters. When the V-PCRF receives the PCC rules (through the CCA message) from the H-PCRF, the V-PCRF extracts the QoS rules from the PCC rules, validates the former, and if the QoS validation is successful, the V-PCRF shall provision the PCC rules to the PCEF by sending the CCA message. (Steps 17–18) The PCEF maps the authorized IP QoS to the requested accessspecific QoS parameters and accepts the PDP Context Activation request.

2.5 QoS Provisioning in WLAN How PCC can be used together with non-3GPP access networks is defined in [13]. In this context, non-3GPP access refers to everything else than 3GPP-defined access, including WLAN access. In order to exploit all the QoS mechanisms of PCC with WLAN, the WLAN should support some kind of bearer model equivalent to the evolved packet system (EPS) bearer model. Note that EPS is the combination of long term evolution (LTE) in the access with the evolved packet core (EPC) to

123

J Netw Syst Manage

Fig. 3 Message sequence for QoS provisioning with 3G access

provide the mobile subscriber with an always-on, ready to use IP connectivity. Figure 4 shows possible message sequences for QoS provisioning in case of WLAN access. Since many steps of these message sequences are similar to QoS provisioning then, in case of 3G access (shown in Fig. 3), we explain the following steps that are different: (Step 9a) On receiving the SDP information, the IMS client application maps SDP information to WLAN QoS parameters, such as enhanced distributed channel access (EDCA) and access category (AC). (Steps 9b–10a) When the WAG receives a resource reservation request from the UE, it maps the WLAN QoS parameters to EPS bearer parameters and sends a PDP context type message to the PDN-GW that hosts the PCEF. (Steps 18a–18b) The PDN-GW (PCEF) sends an Accept PDP context type message to the WAG. Finally, the WAG returns an Accept resource reservation message to the UE that confirms the reservation of resources to provide the requested level of QoS.

123

J Netw Syst Manage

Fig. 4 A possible message sequence for QoS provisioning with WLAN access

Note that in the case of WLAN access, there is no formal specification for resource reservation along the path, UE to PDN-GW. Therefore, messages 9b, 10a, 18a, and 18b shown in Fig. 4 are yet to be specified by standardization bodies. Another important issue is mapping WLAN QoS parameters to the EPS bearer (i.e., step 9c in Fig. 4) and vice-versa. However, no specific mapping rules have been defined yet. Practically, all these limitations mean that no suitable QoS reservation mechanism and mapping functions do exist in the current or near future WLAN network or terminal equipment and thus PCC cannot be used with WLAN to ensure certain levels of QoS for services running over the WLAN access, short of having a dedicated infrastructure engineered for specific services and exploiting 802.11 priority mechanisms. Note however that this restriction applies only to QoS. 2.6 Charging Architecture The IMS charging architecture and information flow for both online and offline charging has been shown in Fig. 5. Although OCS and OFCS have been presented as single entities in Fig. 1, they are composed of a number of functionalities. In the charging architecture, a network element that can collect accounting metrics implements the charging trigger function (CTF). Offline charging can be applied to sessions or to events (e.g., the sending of an instant message). For offline charging, the CTF generates charging events based on

123

J Netw Syst Manage

Fig. 5 IMS charging architecture and information flow

its accounting metrics and sends these charging events to the charging data function (CDF). Note that all the CSCFs, the AS, the MRFC, the MGCF, the BGCF, and also the PCEF, implement the CTF in offline charging. The CDF uses the information in the charging events to generate charging data records (CDRs) that is sent to the charging gateway function (CGF). The CGF acts as a gateway between the IMS and the billing domain and transfers the CDRs to the billing domain. Online charging is based on credit-based charging and supports both session-based and event-based charging. The AS, the MRFC, the S-CSCF and the PCEF implement the CTF function and send charging events to the online charging function (OCF). The OCF communicates with the rating function (RF) and with the account balance management function (ABMF). The RF determines the value of the network resource usage (described in the charging event) and returns the rating output (monetary or nonmonetary units) to the OCF. The RF may handle a wide variety of rateable instances: rating of data volume, rating of session/connection time, rating of service events, etc. The ABMF is responsible for maintaining user credits. It contains information about all user accounts–their total, reserved, and available–balance. Let us mention, again, that charging/accounting functions are commonly supported in wireless access as part of their AAA functions. Carrier-grade devices will support a RADIUS interface to these functions.

3 IMS Client Virtualization The virtual IMS client we developed in [4] is shown in Fig. 6. In this architecture, most of the signalling load is transferred to a server co-located with a P-CSCF,

123

J Netw Syst Manage

Fig. 6 IMS client virtualization

which we shall call a surrogate. The surrogate acts as a virtual server for the user to access, organize, provision, and monitor her SIP–based services. Accessing IMS services requires instantiating the IMS client installed within the surrogate. The surrogate presents an IMS client to the core, acting as a server–side of the virtualized client for the user. However, the surrogate is transparent for the IMS operations in the network and it has no impact on the IMS core architecture. The surrogate implements a Web server, which receives the users’ input through the GUI running on the Web client inside the UE. In this model, any end user device (e.g., mobile device, laptop, PC, IP phone, etc.) with IP connectivity could be used as an UE. A middle layer is needed between the Web server and the IMS client to transfer the GUI’s input to the IMS client applications and IMS session status (e.g., IMS registration success) to the Web server. The IMS client framework inside the surrogate implements IMS Applications as the top layer. Since the user interface layer is already implemented in the UE (through the Web-based GUI), an IMS Applications layer is required to be implemented to expose different IMS applications to the Web server. The UE communicates with the surrogate using HTTP while the surrogate communicates with the IMS core using SIP messages. Accessing IMS services is also related to UE authentication by the IMS core and how media would be delivered to the user’s platform.

123

J Netw Syst Manage

We must mention that the UICC is a smartcard that securely stores the IMS subscriber’s identity and credentials. An ISIM (IP Multimedia SIM) application depends on the UICC smartcard for hosting the application, which—by its very essence—could not be deployed inside the surrogate. Hence, an IMS soft client that instantiates a virtual ISIM application is required for our architecture and therefore, not shown. This virtual ISIM application is beyond the scope of this paper and also not shown in Fig. 6. As one can see, this earlier work did, however, not support IMS’ PCC and QoS functions. In the next section, we look in detail at the integration of these functions in an extended virtual client model.

4 Proposed Model In the previous section, we have presented IMS’ PCC architecture and our IMS client virtualization model. Our challenge now is to see how both can be integrated. One of the client’s virtualization key benefits is to push some of the complexity of interacting with the IMS platforms further away from the access network. The virtual client architecture assumes that the surrogate (that hosts the IMS client implementation program) is implemented and maintained by the home network provider, although it might well be implemented by a third party or the visited network provider. Since an IMS client mostly communicates with the home network, the surrogate, located inside the home network, will reduce the control messages’ propagation time. While this solution is beneficial for the signalling path, it also raises issues on the media path, with QoS being more critical and of course related to charging. In this section, we study how such integration can be done. In line with the use of 3/4G access networks, we assume that the user will authenticate with the network to gain access to data communications, and this will be independent of any access to the IMS infrastructure. This process will give the user access, most likely through DNS, to the key nodes relevant to the media channel. We also assume that a form of peering exists between the visiting IMS and the home IMS infrastructures, which is extended to serve the purposes of our architecture. 4.1 IMS Client Virtualization and Roaming In our model, a virtual client is used to fully virtualize the IMS (SIP) client and the SIP session is always initiated/terminated at the surrogate. Therefore, the IMS service session will be accessed as if the end user were located in the home network. If we consider only the IMS (SIP) signalling plane, we can say that roaming has simply disappeared. No matter whether the end user is located in the home or a foreign network, or accessing IMS services through 3/4G networks or WLAN/ broadband, the IMS registration, session establishment, modification, etc. will be the same. However, if we consider how media is being accessed, both roaming and nonroaming cases are possible depending on where (in the home or a foreign network) the user physically is.

123

J Netw Syst Manage

Now, to provision the PCC, we must cater to its roles both in the IMS core’s entities (e.g., P-CSCF, S-CSCF) and on the access side (e.g., GGSN in GPRS, WAG in WLAN). While the PCC is playing its role in a core IMS entity (e.g., S-CSCF is involved in online charging), our proposed architecture will largely behave like the existing non-roaming IMS. However, for the access side, we must consider a further disconnect from wireless access and the IMS infrastructure. 4.2 PCC Architecture for a Virtual IMS Client The proposed PCC architecture for a virtual IMS client is shown in Fig. 7. This architecture has many similarities with the IMS PCC architecture for visited access roaming using the P-CSCF from the home network (shown in Fig. 1), except that the functionalities of the UE have been split over the end user terminal and the virtual IMS client. The IMS service model successfully separates the control plane and media plane. Since the media should be delivered to the end user’s terminal device, it is not possible to apply virtualization on the media plane. If we consider the UE’s architecture shown in Fig. 2, we can identify the two key components inside the UE—applications and Access specific BS Manager—relevant for our purposes. We can roughly include applications in the control plane and the Access specific BS Manager in the media plane. The applications include the IMS (SIP and SDP) client, the universal integrated circuit card (UICC), and any other IMS application enablers. The Access specific BS Manager receives the PDP context parameters, which are mapped from the application layer’s QoS requirements and requests the serving gateway (PCEF) to reserve resources as per the PDP context parameters. Proper resource reservation at the serving gateway is a necessary condition for attaining a satisfying QoS level. Thus, the Access specific BS Manager is an integral part of the end user’s terminal device and cannot be virtualized.

Fig. 7 Policy and charging control architecture for the virtual IMS client

123

J Netw Syst Manage

5 Use Cases We discuss here, in more detail, two important dimensions of the extended virtual IMS client architecture: QoS provisioning and charging. 5.1 QoS Provisioning for a Virtual IMS Client Since QoS is actually defined for the media, the access network through which the media is delivered to the end user’s device must also be adequately provisioned. Hence, depending on the access network, we can expect different implementation scenarios and their relevant message sequences as well. 5.1.1 3GPP Access Network In the case of 3GPP access, the message sequence for QoS provisioning in our proposed PCC architecture is shown in Fig. 8. In this figure, we assume that QoS provisioning is done in pull mode. The message sequences are explained in the following: (Step 1) Through the Web-based user interface, the end user selects a service and a corresponding Service Request message is sent to the IMS client. (Steps 2–6) The IMS client initiates an IMS session. From the end-to-end SIP and SDP message-exchange during IMS session establishment, the P-CSCF extracts and stores SDP information describing the session to be established and forwards this information to the H-PCRF by sending an AAR (AA-Request) message. (Steps 7–9) Using the session description, the H-PCRF selects a set of PCC rules for the session. The PCRF returns an AAA (AA-Answer) message to the P-CSCF. Next, the P-CSCF sends the final SDP answer to the IMS client. (Steps 10–11) On receiving the SDP information, the IMS client maps this information to access specific (e.g., UMTS) QoS parameters (depending on the IP-CAN of the end user’s terminal) and sends a Service Response message carrying the mapped access specific QoS parameters. The steps 12–20 in Fig. 8 are the same as the steps 10–18 in Fig. 3; therefore, the PDP context activation procedure is not explained again here.

5.1.2 WLAN Access We note that WLAN access follows a similar process to set up QoS for the user. First, following the steps 1–11 of Fig. 8 the IMS call setup will be completed and the UE will receive the WLAN specific QoS parameters. Next, following the steps 9b–18b of Fig. 4, the required resources will be reserved at the terminal equipment and inside the network nodes.

123

J Netw Syst Manage

Fig. 8 Message sequence for QoS provisioning in virtual IMS client with 3G access

5.2 Charging for Virtual IMS Client According to the PCC specification [3], the OCS is always located in the home network, while the OFCS might be located in the visited and/or home network. Note that the offline charging does not require any communication between the home and the visited network, and hence, it is relatively straightforward to implement. In the case of the virtual IMS client, offline charging could be implemented following the IMS/PCC specification. Therefore, we limit our discussion to online charging in virtual IMS clients. In the case of online charging, the PCRF and other entities (e.g., the PCEF) that implement CTF have to communicate with the OCS, which is located in the home network. The communication between the H-PCRF (e.g., the H-PCRF sends an Initial Spending Limit Report Request to the OCS during IP-CAN session establishment [3]) and the OCS could easily be accomplished since these two are directly connected. An entity from the visited network (e.g., the PCEF sends Credit Requests messages to the OCS during IP-CAN session establishment [3]) may need to

123

J Netw Syst Manage

communicate with the OCS in the home network. The PCC specification (while missing on some details) mentions that an entity from the visited network communicates with the OCF in the home network through a proxy-OCF located in the visited network (see Fig. 1). The communication between the PCEF of the visited network and the OCS of the home network through the proxy-OCS has been explained in [9]. Figure 9 shows how an Online Charging Request is sent from the serving GW (PCEF) or the AAA proxy from the visited network to the OCS through a proxyOCS. The home OCS first identifies a subscriber profile for the roaming user and then grants an allotment of service units from the account balance. The home OCS returns an Online Charging Response back to the proxy-OCS that includes the allotment of service units. If the allotment is granted, the proxy-OCS determines a rating for the session and grants a quota of service units to one or more network elements based on the allotment of service units and the rating. When the allotment is expired, the proxy-OCS sends another Online Charging Request message to the home OCS to receive another allotment. If we compare the proposed architecture and the communication scenario shown in Fig. 9, we find similar entities located in the visited and home networks.

Fig. 9 Message sequence of credit control performed in the visited network [9]

123

J Netw Syst Manage

Therefore, we conclude that, in the case of a virtual IMS client, the communications between the visited and home networks required to accomplish online charging could be easily established.

6 Discussion 6.1 Benefits If we compare PCC provisioning in the regular IMS client with the proposed virtual IMS client, we find many similarities between these two models. Although, since the virtual IMS client is being deployed in the surrogate at the proximity of the IMS core network, there is no way to avoid resource reservation and charging at the access networks; still, the proposed virtual IMS client model provides a number of other benefits, which are summarized in the following: 1.

2.

3.

Lightweight UE The resource constraints on the UE are reduced, as it does not need to have a large compute/storage capacity. It is also possible to extend the lifespan of the UE. Reduced communication between UE and IMS core A complete IMS call setup may require more than one end-to-end communication between the IMS client and the IMS core network (although Figs. 3 and 4 have shown only one round). The proposed model reduces the number of end-to-end communications by implementing the IMS client inside the home network, thereby improving latency. Reduced costs The IMS virtual client could be implemented as a SaaS fashion inside the Cloud computing infrastructure [14]. Thus, it is possible for several users to share licensed software on a server machine. This also means that licensed software does not need to be installed on all UEs.

6.2 Limitations and Open Issues In spite of a wide range of benefits, the proposed virtual IMS client has some constraints and also some open issues that will be addressed in future research. These are as follows: 1.

2.

Partial virtual client Due to the QoS provisioning and charging requirements, it is not possible to design a fully virtual IMS client. A set of minimum functionalities that play a role in or cooperate with the virtual client for resource reservation, mapping of QoS parameters and charging will have to be implemented inside the UE. Communication between the UE and the virtual client The virtual IMS client inside the surrogate establishes the IMS call and thus takes part in SDP negotiation on behalf of the UE. In order to exchange SDP messages, the UE’s capabilities, the type of access network and other related information should be

123

J Netw Syst Manage

3.

4.

transmitted to the virtual client. However, right now there is no standard way to exchange such information. Performance of the surrogate The surrogate is the focal point of computing and processing in our solution. The surrogate may have to receive hundreds of IMS calls, maintain IMS sessions, connections and state information from different users. Traditional techniques of multiple instances and load balancing, already present in the 3GPP architecture, can be used to support this load. Furthermore, if the virtual IMS client is implemented inside a Cloud computing infrastructure [14], it could benefit from the multitenancy and the elasticity offered by Cloud computing. Full implementation of the proposed architecture Although we have not implemented the proposed architecture in this study, we have previously experienced implementing a virtual IMS client [4] (using eXtended osip (eXosip) library of C programming) and integrated that with OpenIMSCore [15] (an open source IMS core implementation developed by the FOKUS group). The virtual IMS client we implemented is similar to the IMS client provided by the University of Cape Town (UCT) IMS research group [16]. The UCT research group has also released a PCC extension that could be integrated to the OpenIMSCore. Hence, with some effort, but little risk, our previous implementation could be extended to implement a prototype of our proposed integration of PCC architecture.

7 Related Work In this section, we summarize some related work on QoS provisioning, charging architecture and other IMS related research carried out by individual researchers outside the 3GPP community. Providing QoS in heterogeneous multi-hop environments where the underlying layer 2 technologies can be different at different hops is a challenging problem. In [17], IP-level QoS signalling has been used to support end-to-end QoS for different applications. A small set of IP QoS parameters has been defined and used in the case of Wireless-to-cellular handover. How the PCC architecture could be applied to the EPS has been described in [18]. PCC specifications, defined as part of the 3GPP Release 8, have evolved significantly from previous releases to support multiple-access technologies, roaming, and mobility for EPS. The existing specification of PCC needs a clear definition and standardized process of the interchanged messages while deploying PCC rules. The core of the information unit of the PCC architecture is the PCC rules, which might be implemented different ways as per the present specification. In [19], the problem of multiple interpretations in the PCC architecture and how this could lead to different implementations is exposed. Additionally, two different prototypes of the PCRF have been designed and compared.

123

J Netw Syst Manage

Although, non-3GPP access and 3GPP access integration have been specified in [13], many access-specific details are yet to be defined, specially while deploying PCC architecture. To integrate UMTS and WLAN systems, a policy-based QoS management architecture is proposed and different UMTS/WLAN interworking scenarios are discussed in [20]. Note that this scheme is based on a policy framework [21] which was being used in the earlier 3GPP releases and is now superseded by the PCC architecture. For better integration of IMS/PCC and WiMAX, the WiMAX specific functionality defined in the WiMAX Forum is presented in [22]. Due to the slow deployment of the original IMS architecture, a number of efforts have been taken to explore alternative ways to deploy IMS. In a self-organizing and adaptive IMS architecture [23], the IMS functional components and corresponding nodes can adapt dynamically based on features like network load, number of users, and available system resources. Another alternative that may escalate IMS deployment is a blend of service mashups with built-in features of IMS. A framework that helps to blend these two has been presented in [24]. 8 Conclusion We have presented extensions to our early virtual IMS client model that include provisions for the PCC function and QoS, suitable for roaming scenarios. Our extensions integrate perfectly into the current IMS standard architecture on the network side. On the client side, the implementation of QoS can remain challenging and will strongly depend on the access technology used. Certainly, in the case of WLAN, the guarantees that can be provided to the user remain practically nonexistent for general public access, although a trend towards better, quality enabled WLAN access networks to complement LTE has emerged. This combination presents great opportunities for our extended virtual IMS client model.

References 1. 3rd Generation Partnership Project: Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS). 3GPP TS 23.228 V11.4.0 (2012) 2. Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Sparks, R., Handley, M., Schooler, E.: SIP: Session Initiation Protocol. RFC 3261 (2002) 3. 3rd Generation Partnership Project: Technical Specification Group Services and System Aspects; Policy and charging control architecture. 3GPP TS 23.203 V11.5.0 (2012) 4. Gre´goire, J.-Ch., Islam, S.: Virtual terminals for IMS. In: Prasad, A., Buford, J., Gurbani, V. (eds.) Future Internet Services and Service Architectures. River Publishers (2011) 5. Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN): NGN Functional Architecture. ETSI ES 282 001 V2.0.0 (2008) 6. 3rd Generation Partnership Project: Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control (PCC) over S9 reference point; Stage 3. 3GPP TS 29.215 V11.4.0 (2012) 7. 3rd Generation Partnership Project: Technical Specification Group Services and System Aspects; 3GPP system to Wireless Local Area Network (WLAN) interworking; System description. 3GPP TS 23.234 V10.0.0 (2011)

123

J Netw Syst Manage 8. 3rd Generation Partnership Project: Technical Specification Group Services and System Aspects; Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging. 3GPP TS 32.260 V11.3.0 (2012) 9. Cai, Y., Liu, C.-Z.: Online Charging for Roaming Users in a Proxy Online Charging System of a Visited Network. U.S. Patent 0 264 096 (2009) 10. 3rd Generation Partnership Project: Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control (PCC) over Gx/Sd reference point. 3GPP TS 29.212 V11.4.0 (2012) 11. 3rd Generation Partnership Project: Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; End-to-end Quality of Service (QoS) concept and architecture. 3GPP TS 23.207 V10.0.0 (2011) 12. Handley, M., Jacobson, V., Perkins, C.: SDP: Session Description Protocol. RFC 4566 (2006) 13. 3rd Generation Partnership Project: Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses. 3GPP TS 23.402 V11.2.0 (2012) 14. Islam, S., Gre´goire, J.-Ch.: Giving users an edge: a flexible cloud model and its application for multimedia. Future Gener. Comput. Syst. 28, 155–162 (2012) 15. OpenIMSCore: The open source IMS core project. Available: http://www.openimscore.org/ 16. Waiting, D., Good, R., Spiers, R.,Ventura, N.: Open Source Development Tools for IMS Research. In: The proceedings of 4th international conference on testbeds and research infrastructures for the development of networks and communities (2008) 17. Fodor, G., Eriksson, A., Tuoriniemi, A.: Providing quality of service in always best connected networks. IEEE Commun. Mag. 41(7), 154–163 (2003) 18. Balbas, J.-J.P., Rommer, S., Stenfelt, J.: Policy and charging control in the evolved packet system. IEEE Commun. Mag. 47(2), 68–74 (2009) 19. Albaladejo, A.D., de Gouveia, F.C., Corici, M.I., Magedanz, T.: The PCC Rule in the 3GPP IMS Policy and Charging Control Architecture. In: The proceedings of IEEE GLOBECOM, pp 1–5 (2008) 20. Zhuang, W., Gan, Y.-S., Loh, K.-J., Chua, K.-C.: Policy-based QoS management architecture in an integrated UMTS and WLAN environment. IEEE Commun. Mag. 41, 118–125 (2003) 21. Yavatkar, R., Pendarakis, D., Guerin, R.: A Framework for Policy-Based Admission Control. RFC 2573 (2000) 22. Cherian, S., Feder, P., Sadeghi, B., Wisenocker, R.: Integration of the IMS/PCC framework into the mobile WiMAX network. IEEE Commun. Mag. 46(10), 66–73 (2008) 23. Dutta, A., Makaya, C., Das, S., Chee, D., Lin, J., Komorita, S., Chiba, T., Yokota, H., Schulzrinne, H.: Self organizing IP Multimedia Subsystem. In: The proceedings of IEEE internet multimedia services architecture and applications, pp 1–6 (2009) 24. Sinkar, K., Loeb, S., Dutta, A.: Mobile contextual mashup service for IMS. In: The proceedings of IEEE internet multimedia services architecture and applications, pp 1–6 (2008)

Author Biographies Salekul Islam is an assistant professor at United International University, Bangladesh. He worked as an FQRNT postdoctoral fellow at INRS, a constituent of the Universite´ du Que´bec. He has a Bachelors degree from Bangladesh University of Engineering and Technology, a Masters degree and a Ph.D. degree from Concordia University, Canada. His research interests are in the design, analysis and validation of protocols for telecommunication networks and secure multicast. Jean-Charles Gre´goire is an associate professor at INRS, a constituent of the Universite´ du Que´bec with a focus on research and education at the Masters and Ph.D. levels. His research interests cover all aspects of telecommunication systems engineering, including protocols, distributed systems, network design and performance analysis, and more recently, security. He also has made significant contributions in the area of formal methods.

123