Research Article
Policy Based QoS Architecture for Media Streaming in UMTS
Department of Computer Science and Engineering Anna University, India-600025
P . Narayanasamy
Department of Computer Science and Engineering Anna University, India-600025
The success of wireless voice services has created opportunities for multimedia data and entertainment services, leading to a ubiquitous information environment for the future. The potential for wireless data services has also been demonstrated recently through the tremendous success of push to talk [Push-to-talk over Cellular (PoC), PoC Release 1.0, 08.2003) technology. More and more users are getting accustomed to the concept of wireless appliances that can provide many attractive services by integrating contents, voice and text commnnications. Alongside this development, the core global information networks are becoming a reality than converge multimedia-streaming service on a single seamless network Infrastructure. Multimedia streaming services are also technically applicable over evolving 3G wireless networks. Although a few proprietary streaming technologies rule the Internet today, the proliferation of Internet Engineering Task Force (IETF) (www.ietf.org) standardized protocols such as RTF (Schulzrinne et al., 2003), RTCP (Schulzrinne et al., 2003), SIP (Rosenberg et al., 2002) and XCAP (Rosenberg, 2005) aims to standardize an open streaming concept in major wireless standardization organizations (3GPP (http://www.3gpp.org), 3GPP2 (http://www. 3gpp2.org/), OMA (http://www.openmobilealliance.org/) will bring a strong open standard-based service to wireless market place.
Media streaming application may become a highly popular service for the mobile telecommmrication market if it provides the QoS. Most multimedia applications do make use of some signaling protocol such as SIP to establish the connection and those signaling protocols do not care resources reservation. Multimedia streaming applications are forced to rely on existing QoS protocol (such as RSVP (Mankin et al., 1997) in order to get resource reservation and some order of QoS assurance. In the existing system there is no such option to provide QoS for media streaming. Therefore new commmrication architecture is needed to integrate mechanism allowing QoS guarantees as well as high rate for the commmrications services. This study is going to address the topic of integrating the QoS architecture with the multimedia signaling protocols by achieving a fair degree of QoS using Policy Based architecture.
UMTS ARCIDTECTURE
Telecommnnication networks are gradually shifting from circuit switched to packet switched networks. At the same time the applications are converging to multimedia based applications. For case study, this study considers the architecture conceptually similar to IF-based 3G U1\.1TS Release 5/6 multimedia networks in terms of heterogeneity in access network technologies. A logical view of the architecture is presented in Fig. 1.
UMTS Rel.5/6 specifies the provision of traditional circuit and packet switched services over a single converged IF based Packet-switched (PS) networks. Control signaling is facilitated by an all-IF multimedia core network subsystem (IMS) (3GPP IS 23.228 2001) with full IF packet support including full UMTS call control capabilities.
Fig. 1: | UMTS release 5/6 architecture |
The IMS works in conjnnction with the PS Core Network (PS-CN). Since SIP has been chosen by 3GPP as the signaling protocol between user equipment (UE) and the IMS as well as between components within the IMS, UMTS Rel.5/6 is the ideal platform for the implementation of the proposed Policy Based QoS for media streaming in 3G. Figure 1 depicts the main components of the UMTS Release 5/6 architecture that is the UMTS Radio Access Network (UTRAN), the PS-CN and the IMS. The Serving and Gateway GPRS Support Nodes (SGSN and GGSN) constitute the PS-CN. Each SGSN is connected to a number of Radio Network Controller's (RNCs) thereby acting as serving node for all mobiles that are under coverage of these RNCs. The GGSN is the point of Packet Data Network (PDN) interconnection between external networks and the UMTS Public Land Mobile Network (PLMN).
The added IMS functionalities are control functionalities; the user data traffic is still carried by the PS domain. The main advantage of the IMS is that it offers operators a scalable service platform on which new services can be developed rapidly in a flexible way, without requiring any changes to the PS domain. The new functionalities introduced in IMS are the Call State Control Function (CSCF), the Media Gateway Control Function (MGCF) and the Media Resource Function (MRF). There are three types of CSCFs, each paying a specialized role. The Proxy CSCF (P-CSCF) is the first contact point within the IMs for a UE. It behaves like a SIP proxy that accepts SIP messages and routes them to other CSCFs. The Serving CSCF (S-CSCF) controls the session states in the network by enforcing the service profiles of participating parties retrieved from a Home Subscriber Subsystem (HSS), which is a user database of the users in the network. The S-CSCF serving a UE normally resides in the home network of the UE. The Interrogating CSCF (I-CSCF) is the contact point of a UMTS network for all external originated connections destined to aTE with in the network. The role of an I CSCF is to maintain network configuration independence and to hide the configuration, capacity and topology of a network from external parties. The MGCF provides a control signaling capabilities for interworking with other Circuit Switched (CS) systems. It controls the Media Gateway, which provides the user traffic data interworking functionalities. Finally the MRF serves as multi party conferencing and announcement server.
POLICY BASED NETWORKS
The IETF has defined a policy framework (Yavatkar et al., 2000) to transform sets of policy rules to network device configurations in an administrative domain. Figure 2 shows the components in the policy framework that includes policy management application, policy repository, policy decision point and policy enforcement point. Following is the description about the main components of the framework
Policy management application: It supplies the interfaces to make the network administrator specific and store the policies in a repository. It also acts as a monitor of the state in the network managed by means of policies.
Policy repository: It is a storage that uses the decision points (PDPs) to recuperate policies. The use of an access protocol is required to be able to accede. The IETE suggests the use of a Lightweight Directory Access Protocol (LDAP) (Weltman, 2006), but other possible solutions such as other directories, databases or web servers are also available. Policies are stored in a high level and are independent from the network devices.
Policy decision points: They are the points where all decisions that must be applied on the network are created. PDPs process the policies and information about the network state to decide which policies are necessary to apply in the network. These policies are send as configuration data to PEPs. The architecture considers that there is a PDP component and one or several PEPs that rule all physic devices. The PDP is responsible for locating the set of rules that PEP has to apply, recuperating them from the repository and transforming them into a format and syntax that can be understood by the device and distributed to the PEPs. In the same way, the PDP act as a monitor for the network state and check if all required conditions are satisfied to the policy application. If the PDP relevant policies change, then the PDP must load the repository policies again.
Policy Enforcement Points (PEPs): They are the items involved in the execution of the policies that the PDP orders. Some examples of these PEPs are routers, firewalls, proxies, etc. PEP receives the policies in the shape of specific configuration actions and it is responsible for their establishment in the device.
Fig. 2: | Policy bases UMTS QoS architecture |
The IETF PBN establishes COPS (Chan, 2001) to transfer policies decisions to the PEPs and to transfer request from PEPs to the policy server. The model is open to other mechanisms such as HTTP, FTP or SNMP.
PBQoSARCHITECTURE
As a service platform IMS aims at real-time multimedia services that easily integrate with each other and telephone services. By bringing together call control and service provision into a horizontally integrated system IMS enables new combinations of services and service elements. Having put in place the functionalities to handle IP multimedia calls, the next big challenge is to ensure and provide sufficient QoS resources to users in the U1v!TS network. PBQoS architecture uses standardized protocols, such as SIP, RTP, RTCP, XCAP and HTTP. These protocols have been used in the internet and mobile community for quite some time.
The core of the proposed architecture consist of two main elements the Quality Control Function (QCF) and the Policy Enforcement Point (PEP). PEP often resides in the policy aware network nodes that carry out actions stipulated by policy rules. Since the GGSN is in the data path, it is the logical location to place the PEP.
Fig. 3: | IETF policy framework |
QCF is residing on the Applications Servers (AS). ASs is not pure IMS entities; rather, they are functions on top of IMS. However ASs are described here as part of IMS functions because ASs are entities (it contains the QCF). ASs could greatly simplify the introduction of new services and enable operators to leverage their ownership of the access network by introducing opportunities for service-based control of the access for a whole variety of services (potentially including third-party services) in an operator-controlled manner. QCF is the main component in the PBQMS architecture. QCF is responsible for making policy decisions based on session and media related information obtained from the P-CSCF and it plays the role of PDP in policy-based networks. In the IMS, the session setup signaling is separated from the data path of the session. The QCF resides on the signaling path. The resource reservation for the media streaming session is taken based on the decisions of the QCF, which retrieves the policy rules from the policy repository. The main functions of QCF are: Authorization of session QoS resources, Resource reservation, Session release, Correlation of charging information.
The policy repository can be an external entity to the QCF. At the heart of the QCF is the policy repository, which stores the policy information; the operator decides the granularity of this information. For example, policy information can relate to all Access Point Names (APN) that are reachable via the UMTS network, or only to the given APN. The mobile operator defines policy information. The PBQMS architecture entities are shown in Fig. 3.
In PS domain, GGSN maintains connectivity to other packet switched external networks such as the Internet. From the service point of view, the GGSN controls PDP activation and IP flows into the external IP networks. As such, it is logical place to embed the PEP in GGSN. The role of the PEP is to reserve the network resources according to the QCF response and authorize IP flows to use the network resources that have been reserved and allocated to them. The above process takes place at the IF bearer service level. The translation, allocation and mapping fnnction within the GGSN will map this resource information into the format used by the admission control frmction at the UMTS base station level. When PEP first starts up, it establishes a TCP connection to the QCF by listening on the well-known port. The network operators may preconfigure the location of the QCF. All connection between the PEP and the QCF occurs through this TCP connection. Once the TCP connection is established, the PEP may negotiate a security association with the QCF to facilitate the application of security mechanism on the commmrication channel.
A lightweight XCAP protocol is likely to be used in between policy repository. QCF and the P-CSCF for this purpose through a TCP connection. The XCAP protocol acts in two modes of operation. In the push mode, the QCF initiates commnnication with the P-CSCF and sends its decision. In the Pull mode, the P-CSCF initiates commnnication with QCF to request a decision for a particular IF flow. The P-CSCF acts as a client and sends request to the QCF, which act as policy server. The QCF return decisions to the P-CSCF in response to its requests. The P-CSCF and QCF maintain state information for every request.
During the establishment of the SIP session (i.e., SIP INVITE). P-CSCF is the first contact point in the IMS domain for the UE. Hence it is the natural place to authorize the usage of network resources such as the bandwidth and the QoS requested by the UE. The QoS requirements of the UE are carried in the SDPng (Bose et al., 2003) within the SIP message. The P-CSCF will contact the QCF usiug XCAP REQ to get the QoS policy decisions. Besides the QoS requirements in the SDPng, the QCF examines the source and destination address in its decision-making. The QCF refers to the policy rules, which are generally stored in the policy repository. It then generates an authorization token and the negotiated QoS information and sends the same to the P-CSCF using XCAP RES. This negotiated QoS information and the token is sent to the UE via SIP UPDATE messages so that UE can reserve the resources using RSVP for the transmission of the media packets.
Once the GGSN receives a request for resource reservation establishment for the data path from the UE, the PEP in the GGSN must verify the QoS request and the authorization token with the QCF. An authorization token and the relevant flow identifiers, QoS parameters are extracted from the reservation request message and send to the QCF using XCAP Request (XCAP REQ) message. The QCF then uses the token and the other information's to attempt to correlate this request to a previously installed authorization state in its database. If these correlations can be made, the QCF supplies the PEP with the decision to reserve network resources with the specified QoS level in the XCAP response (XCAP RES) message. The PEP executes the decision and reports the result to the QCF using XCAP report status (XCAP RPS). Any subsequent modification of the QoS resource reservation in the GGSN on the reception of an update request for the same media session will be performed only after the verification of the session request with the QCF. When the GGSN received a release network resource request, the PEP component must delete the installed request state in the QCF by sendiug the XCAP Delete Request (XCAP DREQ).
POLICY BASED QoS DELIVERY
The establishment of an IF multimedia session using this PBQoS architecture is different from the normal IF multimedia session. Additional steps are taken to check the policy repository for the decision on request, whether to grant or deny the required network resources for that session. Three basic steps are involved in setting up IF multimedia session using this PBQoS architecture. They are: session initiation, authorization of session and QoS resources and resource reservation. Figure 4 shows the sequence of events that takes place during the establishment of an IF multimedia session between the caller and the callee.
Session initiation: Session initiation depends on the type of service. At session establishment, the UE negotiates the media and network characteristics (QoS, bandwidth, etc.) to use in the session using SIP. As SIP is defined as a envelop for transporting session data, an additional protocol SDPng is necessary to define configuration description for sessiOn establishment or sessiOn adaptation. SDPng is an extensibility of the X1.1L schema defiintions (http://www.w3.org).
Authorization of session and QoS resources: The P-CSCF contacts the QCF to obtain authorization for session resources. This is the initial interaction between the P-CSCF and the QCF. The P-CSCF provides the QCF with the media-related information (session requirements) to be used for the session using XCAP REQ. The QCF then checks whether the policy defined in its policy repository with the provided session requirements. Based on the policy information contained in the policy repository, the QCF authorizes (accepts or rejects) the use of QoS resources and provides the P-CSCF with th e Policy based QoS negotiation binding information to be used for the session using XCAP DEC.
Fig. 4: | Policy Based QoS negotiation |
After receiving the XCAP DEC message from the QCF the P-CSCF for the SIP UPDATE message with the binding information along with the authorization token and send it to the UE.
Resource reservation: By receiving the SIP UPDATE message from the P-CSCF. the UE sends the SIP PRACK message (start reservation) along with the authorization token to the other user thro the GGSN to inform about the start of network reservation. When the GGSN received the resource reservation message from the UE, it requests authorization from the QCF using XCAP REQ. The QCF verifies the authorization token and required network resources correspond to the ongoing session and send the XCAP DEC to the PEP. PEP sends the XCAP RPS to the QCF as a response to the XCAP DEC. Network resource reservation proceeds at the network/transport layer using RSVP. The next sequence depends on the model used for network resource reservation (caller initiated/callee initiated). If RSVP is not available in the peer to peer or terminated at the network edge, the callee will not receive RSVP PATH. Therefore. by using SIP UPDATE (reservation ready) the caller and the callee inform each other about the state of the network reservation and about the final capability of QoS level to be enforced for the session to be established.
Session release: Session release can be initiated by either the UE or the QCF. Sometimes the QCF is also allowed to initiate a revoke authorization, which leads to session release. If the UE requests the P-CSCF to terminate the session, the P-CSCF asks the QCF to release the resources and terminate the authorization. The QCF removes the authorization for the media component(s) of this session and requests PEP to release the network resources for that session.
The present study introduced Policy Based QoS Architecture for negotiating QoS parameters at application, session and transport layers. The special features of this architecture are the negotiation of QoS configuration used for QoS adaptation and QoS adaptation rules for enabling mobile multimedia capable devices to utilize UMTS networks. The basic operations here described were detailed when SIP signaling is assumed to be the signaling protocol for the call initiation. The resource allocation operations were performed using a slightly modified implementation of the SDPng and the XCAP protocol. This architecture simplifies the introduction of new services including third party services. This will allow operators to offer value added services to their customers by applying service level local policies at the QCF, it is hoped that network operators can gain finer control of user access to their networks and the ammmt of QoS resources that can be requested from the network. The ability to control service access and QoS resources consumptions in a 3G network is necessary for the deployment of commercially viable mobile services that are attractive to end users requiring different levels of QoS and thus to generate additional revenues.