A Proposed Model For QoS guarantee In IMSbased Video Conference services

International Journal of Intelligent Information Technology Application, 2009, 2(5):243-249 A Proposed Model For QoS guarantee In IMSbased Video Conference services Maryam Kiani Department of Electrical Engineering, Science & Research Branch, Islamic Azad University, Tehran, Iran Email: kian_mary@yahoo.com Mohammad Ali Pourmina and Farbod Razzazi Department of Electrical Engineering, Science & Research Branch, Islamic Azad University, Tehran, Iran Email: pourmina@srbiau.ac.com, razzazi@payasoft.com Abstract A technical prerequisite for a converged network is an extensible platform that supports the delivering of next generation multimedia services with QoS requirements over multiple access network technologies. The 3GPP SIP-based IP Multimedia Subsystem (IMS) which is an important building block for next generation converged networks, is defined for this purpose. The Session Initiation Protocol (SIP), whose purpose is to handle sessions, forms a major protocol of the IMS standard. SIP facilitates the establishment, modification, and termination of sessions in IMS. On the other hand Video conferencing is one of the most welcomed broadband services for business as well as residential users. This article analyses the mechanisms of resource allocation and admission control by employing logical interfaces that carry SIP messages for Video conference service in NGN. Electronic Blackboard. The deployment of Video conference services over different broadband access networks is made possible by the new types of broadband access networks and improved media coding algorithms. This paper presents the current standardization efforts on Video conference platforms. In this paper, after a short introduction to IMS-based Video conferencing, we introduce its basic principles and technical purposes in section 2. Overview of TISPAN NGN is presented in section 3. In section 4, the mechanisms for QoS support are explained, focusing on the resource allocation and admission control solutions. In the last section access network technologies is explained. Index Terms NGN, IMS, QoS, Video Conferencing, RACS, NASS I. INTRODUCTION The idea of a Next Generation Network (NGN) is commonly understood as a new kind of network architecture together with its related technologies. An NGN architecture is developed with the purpose of integrating different multiple services (data, voice, video, etc.) and of facilitating the convergence of fixed and mobile networks. In this respect, the TISPAN group from ETSI is working in the specification of a Next Generation Network, mainly based on IMS as the service signaling architecture.[1] IMS based NGN have been considered to develop unified service architecture using multi-service concept. Where services can be provided and controlled over the single common service control platform (e.g. based on IMS) independently from any access technology. On the other hand a multimedia teleconference is an information exchange system for people to conduct meetings effectively without leaving their offices. Sitting in front of their workstations, conferees can see each other via real-time motion videos on their multimedia workstation displays, talk and listen to all the conversation via realtime audio, and watch presentations via an on-line 1999-2459 /09/$25.00 2009 Engineering Technology Press II. MOTIVATION FOR THE USE OF IMS IMS based Video conferencing platform is service platform architecture which is able to provide Video conference service controlled and handled by IMS core subsystem and delivered independently from underlying IP transport networks. There exist at least three different stages of evolution for video conferencing architecture: 1- Non-NGN based Video conferencing solutions. It is possible to make some inter working with NGN but generally a separate service control and application layer were developed specially for Video conference service. 2- NGN based Video conferencing architecture. It enables interaction and inter working over specified reference point between Video conference application and some existing common NGN components. These components include transport control elements for resource admission and control subsystem (RACS) or the TISPAN network attachment subsystem (NASS). 3- IMS based Video conferencing architecture. It specifies Video conferencing functions supported by the IMS subsystem and employs these functions to allow reused IMS functions and also make service initiation and control based on SIP (Session Initiation Protocol). 243

A. The advantages of IMS based Video conferencing concept Deploying IMS functionalities to support Video conference service enables more interesting Video conferencing features as follows: - Integrated user registration and authentication (single sign-on) - User subscription management - Session management, routing, service trigger, numbering - Interaction with existing NGN service enablers (presence, messaging, group management, etc.) - Roam and nomadic support - QoS and bearer control - Unified charging and billing The IMS based Video conferencing can also bring additional advantages such as support for mobility, enabling interaction with existing NGN service enablers, service personalization as well as provide converged applications integrated voice, data, video and mobile services to flexible quadruple play service concept. A. IMS based functional architecture for Video conferencing service The functional architecture of IMS based Video conferencing presented in this section contains main functions and reference points defined in TISPAN IMS Video conferencing concept. The main functions are including the service control function, the media control function and the media delivery function. The SSF may optionally generate this service selection information. It may also retrieve and forward the service selection information. - Optionally provides service selection presentation information. This presentation information may be personalized when it is delivered over unicast mode. Optionally receives selection request from UE. The User Equipment communicates with the video conference Service Control Functions via the Core IMS for the purpose of session management, and may use the Ut reference point for the purpose of service profile configuration or interaction with video conference application server (in our realization it is also used for service discovery and selection functionalities). Video conference application server functions (IASF) use the ISC interface to communicate with the IMS based NGN service control. There is Multimedia Service Control Function (MSCF) which should be used as reusable service control element for any multimedia services not just for video conference service. This additional functional element extend IMS core without special needs to change IMS core functionality or interfaces. MSCF is used for control tasks across distributed media control and delivery architecture. Each UE has at least four interfaces for media control over Xc (originally Xc ) and media delivery over Xd (originally Xc ) as well as Gm interface to IMS and Ut interface to IASF. Media Control Functions (MCF) can control Media Delivery Functions (MDF) over Xp reference point that also allows building a really scalable and distributed media delivery infrastructure. Figure1. Functional architecture for video conference service The Service Discovery Function (SDF) and Service Selection Function (SSF) are functions which provide information necessary to the UE to select an video conference service. Tasks of the SDF: - Generates and/or provides the service attachment information. - Provides personalized service discovery. The service attachment information consists of SSF addresses in the form of URIs and/or IP-addresses. Tasks of the SSF: - Provides the service selection information, e.g. a list of available services that the UE can then browse and select. C. TISPAN NGN functional architecture The functional architecture of TISPAN NGN is covered in detail in [1]. Regarding QoS provision mechanisms, in the transport control sub layer the most relevant component is the Resource and Admission Control Subsystem (RACS). This subsystem performs policy control, resource reservation and admission control functions in the NGN. The RACS subsystem provides applications with the capability of reserving resources from the transport networks, guaranteeing QoS provision for the value-added services in the NGN. Further details can be found in [2]. The service layer comprises a set of subsystems that provide service control functionalities. Among them, the Core IMS [3], provides the means to negotiate SIP-based multimedia services to NGN terminals. It is a subset of the IMS as it was defined in the 3GPP Release 6 specifications, restricted to the session control functionalities. Finally, the service layer also provides a set of common components. One of these components is the Application Server Function (ASF). The functionality of the ASF in the NGN architecture consists of providing value-added services to the NGN terminals. D. The IMS Core The IMS core is access independent which means that same services can be delivered over different types of 244

access technologies. In the IMS specification the core of IMS comprises two main nodes: the Call Session Control Function (CSCF) and the Home Subscriber Server (HSS). In the IMS architecture overview (Figure 2 below) the General Switched Telephony Network (GSTN) inter-working functions Media Gateway Control Function (MGCF) and Media Gateway (MGW) have been depicted beside the IMS Core [4,5]. The Call Session Control function (CSCF) is the heart of the IMS architecture and is used to process SIP signaling. The main function of the CSCF is to provide session control for terminals and applications using the IMS network. Session control includes the secure routing of the SIP messages, subsequent monitoring of the SIP sessions and communicating with the policy architecture to support media authorization. It has also the responsibility for interacting with the HSS. It can play three different roles: Serving-, Interrogating and Proxy- Call Session Control Function (S-, I- and P-CSCF). The Home Subscriber Server (HSS) is the master database that contains user and subscriber information to support the network entities handling calls and sessions. Figure2. IMS architecture overview When a user registers in the IMS domain, the user profile (relevant information related to the services to be provided to the user) is downloaded from the HSS to the CSCF. For session establishment, HSS provides information on which CSCF currently serves the user. When more than one HSS is deployed in the network, a Subscriber Location Function (SLF) is needed to locate the HSS that holds the subscription data for a given user. Both the HSS and SLF use Diameter. application servers in the Service Layer, and in their exchanges with the HSS containing the user and subscriber information. H.248 media control protocols: H.248 is a control protocol used between media control functions and media resources. Examples of nodes with media control functions are the Media Gateway Control Function (MGCF) and Media Resource Function Controller (MRFC). IPv6: Originally, IMS was specified to use IPv6; however, with 3GPP Release 6, IMS does provide support for IPv4 and private address scheme. This means that even though IMS is expected to drive the adoption of IPv6, it is not dependent on IPv6 availability in order to be successfully launched. F.NASS This module provides registration and (potentially) initialization of user equipment so that the subscriber can access the services provided in the Service Layer. From a network perspective, NASS provides network-level identification and authentication. This module is also responsible for managing the IP address space within the Access Network and providing authentication to service sessions. Network attachment is provided based on either implicit or explicit user identification credentials stored in its database (respectively, physical or logical Layer 2 addresses, or user name and password) (see Figure 3). This subsystem provides five essential functions: - Dynamic provisioning of IP addresses and other terminal-configuration parameters - Authentication at the IP layer prior to or during the address-allocation procedure - Authorization of network access based on user profiles - Access network configuration based on user profiles - Location management at the IP layer E. Key protocols used in the IMS network Session Initiation Protocol (SIP): SIP is the main signaling protocol used in IMS networks. In SIP there is just one single protocol, which works end-to-end and supports the establishment and termination of user location, user availability, user capability, session set-up and session management. SIP is also designed to enable additional multimedia sessions and participants to be dynamically added or removed from a session. These are the major reasons SIP has been selected in IMS; it is also considered to be flexible and secure. Diameter; a development of the current RADIUS protocol, was chosen as the policy support and Accounting, Authentication, Authorization (AAA) protocol for IMS. Diameter is used by the S-CSCF, I-CSCF and the SIP Figure3. ETSI TISPAN NASS Architecture G. RACS The Resource and Admission Control Subsystem (RACS) arbitrates between service control functions (SCF) and transport functions for QoS related transport resource control within access and core networks. The 245

RACS is the most important logical network element for the interaction between the service layer and the transfer functions for resource control and QoS support within the respective NGN (see Figure 4). RACS can be divided into two functional blocks: the Serving Policy Decision Function (S-PDF) and the Access Resource and Admission Control Function (A-RACF), as described in [6]. The A-RACF and the SPDF perform similar functions, such as making bandwidth management decisions, but they do this at different points in the network. An A-RACF would typically be assigned to a specific access network, while an SPDF would interact with one or multiple A-RACFs. The A-RACF and the SPDF interact using the Diameter protocol, which is an AAA (authentication, authorization, and accounting) protocol defined by the IETF. The SPDF, in turn, interacts with a Policy Enforcement Point (PEP) in the underlying core network via a profile of H.248, the media gateway controller signaling protocol defined jointly by the ITU-T and the IETF. In the core network, this PEP could be, for instance, a border gateway function. In the access network, the A-RACF interacts with PEPs located in the underlying access (and metro) networks, such as access nodes and IP edge routers, via the Ra and Re reference points. The basic RACS functionalities in TISPAN NGN are indicated below: - Policy Control. The RACS subsystem applies to resource reservation requests a set of policy rules to check if these requests can be authorized and to determine how must they be served. Policy control is also performed in the access network, applying network policies specific to each particular access line. - Admission Control. The RACS subsystem verifies if the requested QoS demands can be satisfied with the resources that are available in the involved access network. - Resource reservation. The RACS subsystem provides the means to reserve bearer resources on the access network. - NAT/Gate Control. The RACS subsystem controls NAT functionalities and performs gate control functions, at the limit between the access and core networks and in the limit between core networks [2,7]. H. Putting RACS and NASS all together Prior to any interaction with services (such as IMS), an IP connection must first be established. To obtain an IP pipe, the user connects to the network through another subsystem called the Network Attachment Subsystem (NASS), which is responsible for authentication and authorization of the subscriber to the access network. The NASS also provides the IP address and binds this IP address with such parameters as a line identifier, which identifies the access type. Once attached to the access network, the NASS uploads a set of static policy parameters to the A-RACF in the RACS. Static policy parameters may include such items as the maximum bandwidth that the access line can support. At this point, the user can begin to interact with the services. To do this, some application signaling will take place between the user and an Application Function (AF) in order to register the user with the application. When a user starts to use a service (e.g., through the initiation of a SIP INVITE to a CSCF in the case of an IMS service), it is at this point that the AF begins to interact with the RACS specifically to communicate the bandwidth and potentially other resource control requirements to the SPDF. Note that the AF discovers which SPDF to talk to either by querying the NASS specifically the Connectivity Session Location Function (CLF) to obtain the IP address or Fully Qualified Domain Name (FQDN) of the SPDF, or via some other means, such as static configuration (see Figure 5). The SPDF then applies policies and, if appropriate, initiates a command to the BGF to enforce particular traffic policies. The SPDF may also initiate a further resource request to the A-RACF to request reservation of resources in the access network. This subsequent request may result (after application of policy at the A-RACF) in a command to the IP edge router to apply a particular traffic policy. Figure5. RACS and NASS Figure4. TISPAN RACS architecture (Release 1) Given that it acts as the fulcrum for policy-based resource control in the network, the SPDF also supports the coordination of resource control requests/responses for a particular RACS session. For example, the SPDF may wait for a response from the A-RACF as to whether or not resources can be assigned before replying to the AF with the overall status of all resources that have been assigned [2,8,9]. 246

III. QOS PROVISIONING IN TISPAN NGN Three different NGN QoS control scenarios can be distinguished (ETSI TS 185 001, 2005). The application of a specific scenario, amongst others, depends on the QoS signaling capabilities of the respective user equipment that initializes a session requiring certain QoS conditions within the respective NGN s transport network. For clarity, no protocol details, message responses or acknowledgements are displayed in the respective figures. Only the primary QoS signaling message ways are described. The necessary signaling for the release of resources after a session termination is not accounted [10]. In real-life NGN, the reservation and the release of resources have to be signaled by the RACS not just to one network element within the transfer functions block but to all network elements of the IP transport network that are part of the respective resource path and, at the same time, have to be kept informed about QoS conditions for the respective call. Scenario 1 - This scenario can be applied if the user equipment initializing the respective session has no QoS capabilities at all. Figure 6 shows the principal of this scenario. also called the push model because the resource allocation is pushed from the top (service and call control functions) via the RACS down to the transfer functions. Scenario 2 - The application of this scenario assumes that the respective user equipment has QoS signaling and managing capabilities (i.e., the user equipment can make use of IntServ/RSVP). It is also assumed that the resources demanded by the user equipment do not have to be authorized by the service and call control functions before the allocation of resources in the IP transport network can be applied. Figure 7 shows the principal of this scenario. The user equipment starts layer 3 QoS signaling (e.g., by sending RSVP messages, step 1.). The responsible subsystem of the transfer functions requests QoS authorization at the RACS (step 2.) based on information given within the QoS signaling. If the resource request can be granted, the RACS triggers the resource reservation in the transfer functions of the respective NGN s IP transport network (step 3.). This scenario is also referred to as the pull model, because the permission to allocate the resources requested by the user equipment is pulled down by the respective NGN s transfer functions from the RACS. Scenario 3 - The application of scenario 3 assumes that the respective user equipment has certain QoS signaling and managing capabilities (i.e., the user equipment can make use of IntServ/RSVP). It is also assumed that the resources demanded by the user equipment have to be authorized by the service and call control functions before the allocation of resources in the IP transport network can be applied. Figure8 shows the principal of this scenario. Figure6. NGN QoS and resource control scenario 1 (ETSI TS 185 001, 2005) A user equipment without specific QoS signaling capabilities requests a service (e.g., the initiation of a voice session) by sending a SIP service request (step 1.) to the service and control functions of the NGN it is connected to. The service and control functions identify the required resource conditions (e.g., a certain minimum bandwidth provided) for the respective service and, in step 2., send a resource request to the RACS. The RACS might authorize the subscriber to use a specific amount of resources (depending on the subscriber s user policy) and check whether the requested resources are available within the NGN s transport network. If the resource request can be fulfilled, the RACS triggers the resource reservation (step 3.) in the transfer functions of the respective NGN s IP transport network. This scenario is Figure7. NGN QoS and resource control scenario 2 (ETSI TS 185 001, 2005) A user equipment supporting layer 3 QoS signaling capabilities (such as RSVP) requests a service by sending a SIP service request (step 1.) to the service and control functions of the NGN it is connected to. The service and control functions identify the required resource conditions for the respective service and may relay an associated authorization token to the user equipment. Also, the service and call control functions initiate the policy enforcement within the RACS (step 2.). 247

The user equipment starts layer 3 QoS signaling (e.g., by sending RSVP messages, step 3.) and, within the signaling, turns the before given authorization token to the NGN s transfer functions. The responsible subsystem of the transfer functions requests QoS authorization at the RACS (step 4.) based on the authorization token information. If the resource request can be granted, the RACS triggers the resource reservation (step 5.) in the transfer functions of the respective NGN s IP transport network. This scenario can be referred to as the push-pull model, because the resource allocation is first pushed from the top (service and call control functions) down to the RACS and, from there, is pulled down by the respective NGN s transfer functions after the authorization token has been sent by the user equipment within QoS signaling. IV. QOS PROVISIONING IN IMS-BASED VIDEO CONFERENCING SUBSYSTEM Figure 9 depicts the typical steps that occur at power up of the UE. Some of the steps are not new in them selves, but exist already in NGN. 1- Network Attachment: In this step the UE attaches to the network [11].This step includes IP configuration, P- CSCF address discovery, etc. 2- IMS Registration: In this step, the UE performs regular IMS Registration [12]. 3- Service Attachment: In this step, the UE retrieves the configuration information (server addresses and other relevant information) needed to retrieve the appropriate information to access the services that the user is authorized to. The user preferences and the capabilities of the UE can be taken into account to enable personalized service discovery. The UE could retrieve the service discovery information through the Push mode and Pull mode. 4- Service Selection: In this step, the UE retrieves data related to specific services and makes appropriate service selection. The detailed sequence of steps 3-4 is described in the figures below: Pull mode: After the UE attaches to the IMS network, the UE actively requests the service attachment information from the SDF. Figure 10: video conference service attachment and selection in pull mode Figure 8: NGN QoS and resource control scenario 3 (ETSI TS 185 001, 2005) Figure 9: UE start-up procedure 1- The UE makes a service attachment request. 2- The core IMS relays the request to the appropriate entity (here, SDF). 3- The SDF determines the proper SSF (or SSFs) according to the UE's capabilities, the user's profile and also the location of the UE (Personalized Service Discovery). The user profile may be retrieved from the UPSF or any other entity where it is stored. 4- Configuration information that includes the SSF address (es) is (are) routed back to the UE. 5- Core IMS relays the configuration information related to video conference service back to UE. 6- The UE requests the SSF to get the selection data. 7- The SSF delivers the requested data to the UE. For the purpose of service configuration update, steps 4 and 5 described above can be repeated at any time after completion of the video conference service attachment and selection procedure. 248

Push mode: When the UE attaches to the IMS network, the SDF actively sends the service attachment information to the UE. 1- The SDF gets the status of the UE, e.g. the S-CSCF sends a third-party REGISTER request to the SDF after the IMS Registration or by other method, and then the SDF gets the status of the UE. 2- The SDF determines the proper SSF (or SSFs) according to the UE's capabilities, the user's profile and also the location of the UE (Personalized Service Discovery). The user profile may be retrieved from the UPSF or any other entity where it is stored. 3- Configuration information that includes the SSF address (es) is (are) routed back to the UE. 4- Core IMS relays the configuration information related to video conference service back to UE. 5- The UE requests the SSF to get the selection data. 6- The SSF delivers the requested data to the UE. Figure 11: video conference service attachment and selection in push mode V. CONCLUSIONS In this paper, we have proposed the scheme for QoS mechanism for video conference service using SIP. Today Internet uses the IP protocol suite that was primarily designed to transport data and provide best effort data delivery. Traditional data differ from voice and video in aspects of delay-constraints and packet loss tolerance. Hence as time-sensitive voice and video Applications are deployed on the Internet, the inadequacy of the Internet is exposed progressively. So NGN is demanded to provide end to end QoS urgently. Meanwhile, users demand on network quality of service is getting higher and higher. How to provide the end to end quality of service is one of the key issues of next generation network. We argued to consider the fullyintegrated IMS-based video conferencing deployment. This approach intensifies the issues of QoS assurance due to stricter requirements of real-time multimedia video conference service. Therefore, we proposed a model of service-aware quality assurance procedures for video conference service delivery within the NGN environment. The proposed solution is based on the recognized IMS, RACS, and NASS subsystems. The associated converged profile structure is presented, based on which the authentication, authorization, and admittance decisions are met in both the service and transport layers of the proposed framework. REFERENCES [1] TISPAN, ETSI ES 282 001 V1.1.1: Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture Release 1., August 2005. [2] TISPAN, ETSI ES 282 003 V1.1.1: Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-system (RACS); Functional Architecture., March 2006. [3] TISPAN, ETSI ES 282 007 V1.1.1: Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional Architecture., June 2006. [4] http://www.cablelabs.com/specifications/pkt-sp-23.228- I02-01013.pdf. [5] http://tools.ietf.org/html/rfc3261, IETF Specs - SIP: Session Initiation Protocol [6] ETSI, Tech, ES 282 003 : Resource and Admission Control Sub-system (RACS); Functional Architecture,, Rep., 2006. [7] I. Vidal, J. Garcia, F. Valera, I.Soto, and A. Azcorra, Adaptive quality of service for next generation residential gateways., 9th IFIP/IEEE International Conference on Management of Multimedia Networks and Services (MMNS), 2006, vol. 4267, pp. 183 194. [8] For the list of TISPAN Release 1 Specifications, see: http://portal.etsi.org/docbox/tispan/open/ngn_publishe d/published_ngn_specifications.doc [9] ES 282 004: Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-System (NASS) Note: ETSI Specifications can be download [10] ed at: http://pda.etsi.org/pda/queryform.asp (ETSI on-line account required). [11] ETSI TS 185 001 V1.1.1 (2005), Technical Specification, Next Generation Network (NGN); Quality of Service (QoS) Framework and Requirements, ETSI TISPAN EuQoS Project Web Site (2006), Home - EuQoS - End-toend Quality of Service support over heterogeneous networks, http://www.euqos.eu, (Accessed 16 April 2007). [12] ETSI ES 282 004: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-System (NASS)". [13] ETSI TS 182 006 (V1.1.1): "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description (3GPP TS 23.228 v7.2.0, modified)". [14] IETF RFC 3136: The SPIRITS architecture. [15] ETSI ES 201 915-1: Open Service Access (OSA); Application Programming Interface (API); Part 1: Overview (Parlay 3). [16] ETSI ES 283 003: Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 [Release 7], modified]. 249