Quality of Service Provisioning Issue of Accessing IP ...

Quality of Service Provisioning Issue of Accessing IP Multimedia Subsystem via Wireless LANs

Asma A. Elmangosh, Majdi A. Ashibani, and Fathi Ben Shatwan Electrical Engineering Department, The Higher Institute of Industry {a_elmangosh, mashibani, ashatwan}@hii.edu.ly

Abstract. The Third Generation Partnership Project (3GPP) has specified the IP Multimedia subsystem (IMS) as a service control platform that allows creation of new multimedia and multi-session applications utilizing wireless and wireline transport capabilities. Supporting many types of communications such as instant messaging (IM), push-to-talk cellular walkie-talkie service, and multimedia telephony; the IMS should provide mechanisms to negotiate various levels of Quality of Service (QoS) that should be established at session set-up and maintained throughout the life of the session. In this paper we will cover the accessing of IMS service using Wireless LAN (WLAN) in the transport plane. We will investigate the interworking architecture specified by 3GPP, and propose a framework of the QoS provisioning required in establishing IMS sessions from/to WLAN terminals.

1. INTRODUCTION The IP Multimedia Subsystem (IMS) standard by the 3rd Generation Partnership Projects (3GPP and 3GPP2) represents the global service delivery platform standard for providing multimedia applications in Next Generation Networks (NGN) [2]. The IMS can be defined as “a global, accessindependent and standard based IP connectivity and service control architecture that enables various types of multimedia services to end-users using common Internet-based protocols”.

IMS allows convergence of different transport networks by employing a standardized architecture independent of the access network technology, this way IMS services can be provided over any IP connectivity access network (IP-CAN), such as Universal Mobile Telecommunications System (UMTS), Digital Subscriber Line (xDSL), or Wireless local access network (WLAN). Although Release 5 IMS specifications contain some UMTS-specific features, in Release 6 access specific issues were separated from the core IMS description. IMS employs Internet Engineering Task Force (IETF) protocols to realize standardized reference architecture, and provides a common signaling framework for end user registration, session control, security, profile management, accounting, and end-to-end QoS management. The Session Initiation Protocol (SIP) is the main signaling protocol used in IMS to establish, modify and terminate multimedia sessions between participants. Other protocols are used for specific tasks, such as Session Description Protocol (SDP) to describe the media characteristics to be supported within the sessions, Common Object Policy Service (COPS) to perform local policy-based admission control in different IP-CAN gateways, and Diameter to query HSS registry and to perform charging actions. 3GPP has recently developed a cellular-WLAN interworking architecture, as an add-on to the existing 3GPP cellular system specifications published within 3GPP Release 6 specifications [3], the main driver is to enable 3GPP system operators to provide public WLAN access as an integral component of their total service offering to their cellular subscribers. The subscribers benefit from the interworking service through the greater coverage, higher data-rate, and lower overall cost. The desired interworking between WLAN and IMS can be seen from different points of view. However, the most important aspects are the session negotiation level; which provide service continuity from the user perspective, and the Quality of Service (QoS) provisioning, which guarantee QoS consistency across different access networks. This paper aims to address the problem of how QoS can be provisioned for the end user willing to establish a multimedia IMS session using WLAN as his/her IP-CAN. The remainder of this paper is organized as follows. Section 2 presents the interworking architecture of 3GPP-WLAN as specified by the 3GPP. Section 3 provides a brief view of the related work concerning the subject. Section 4 discusses the QoS aspects of 3GPP IMS-WLAN interworking. Finally the paper is concluded in Section 5.

2. INTERWORKING ARCHITECTURE OF 3G AND WLAN 3GPP-WLAN interworking architecture, as specified by 3GPP, is focused on the interworking functionality between 3GPP based core network and 802.11 technology based WLAN systems. The loose coupling approach has been chosen in this architecture since it provides greater flexibility and scalability than the tight coupling approach. The WLAN is directly connected to the Internet backbone and the 3GPP core network. The typical 3GPP-WLAN interworking system, as specified in 3GPP [3] is shown in Fig. 1. The WLAN User Equipment (WLAN UE) is equipment that uses UICC (Universal Integrated Circuit Card) utilized by a 3GPP subscriber to access the WLAN AN for 3GPP interworking purpose. The WLAN UE may be capable of WLAN access only, or it may be capable of both WLAN and 3GPP radio access. For enabling interworking with WLANs, the 3GPP Packet Switched (PS) core network incorporates three new functional elements: the 3G Authentication, Authorization and Accounting (AAA) server, the WLAN Access Gateway (WAG), and the Packet Data Gateway (PDG). The WLAN must also support similar interworking functionality to meet the access control and routing enforcement requirements.

Fig. 1. 3GPP-WLAN Interworking System Architecture

Authentication, Authorization and Accounting (AAA) is one basic prerequisite for providing IP connectivity and other services by the 3G network via a WLAN system. The 3G AAA server in the 3GPP network terminates all AAA signaling originated in the WLAN that pertains to the WLAN UE. This signaling is securely transferred across the Wa interface, which is based on Extensible Authentication Protocol (EAP) [7].

The 3G AAA server interfaces with other 3G components, such as the WAG, PDG, and home subscriber server (HSS), which stores information defining the subscription profiles of 3G subscribers. The 3G AAA server can also route AAA signaling to/from another 3G networks, in which case it serves as a proxy and is referred to as a 3G AAA proxy. PDGs are responsible for charging data generation, IP address management, tunnel termination and QoS handling. The PDG role in QoS handling will be further discussed in this paper. A WAG is a 3GPP network’s gateway via which the data to and from the WLAN Access Network (WLAN AN) is routed via a Public Land Mobile Network (PLMN) through a selected PDG in order to provide a WLAN UE with 3G PS based services. WAGs are responsible for charging data generation and routing enforcement. HSS is located within the 3GPP subscriber’s Home Network, which maintains required authentication and subscription data to access the 3GPP-WLAN interworking service. To access 3G services, the subscriber needs to first authenticate and get authorized from the 3GPP network, and then WLAN access network allows the UE to access the 3G Core network, and assign him/her a local IP address, which identifies the WLAN UE in the WLAN AN. An end to end IP tunnel is then set up between a UE and a PDG to direct all UE packets through the 3G operator network. The home operator may also wish that all subscriber data were routed via the home network to collect independent charging information and to apply operator’s policies. The requirements to remotely connect to private IP networks and to route traffic via a certain point in the network imply the need to tunnel data packets, as per 3GPP specification. According to the 3GPP specification [5], IPSec [8] tunnel using Encapsulated Security Protocol (ESP) [9] is used between the UE (within WLAN AN) and the PDG of 3G core network. In IPSec tunneling, a tunnel endpoint encrypts and encapsulates the data packet within a new packet destined to the other endpoint of the tunnel. The packet is then decapsulated, decrypted and delivered to the indicated original destination. The Remote IP address is used to transport the encapsulated data packet over the IPSec tunnel. It represents the identity of the UE in the network and is used by UE in accessing the 3G service. The Remote IP address is used for the inner packet (containing encapsulated data payload) of the IPSec tunnel.

3. RELATED WORK A feasibility study carried out within the 3GPP introduced six interworking scenarios at [1], each scenario realizes an additional step in integrating WLAN in the 3GPP service offering and naturally includes the previous level of integration of the previous scenario. The third scenario “Access to 3GPP system packet switch based services” is the most related scenario to our paper. This scenario extends the 3GPP system PS-based services (e.g. IMS, MBMS) to the WLAN. However, it is a matter of implementation whether all services or a subset of the services is provided. Scenario 3 does not provide service continuity. When a user changes access (e.g. from 3G to WLAN), the sessions need to be re-established. The interworking of WLANs and cellular networks will maximize user satisfaction in terms of service availability and high data rates at rational cost, and further boost the penetration of the two networks. Categories and examples of future services that could be provided using the 3G-WLAN interworking are discussed in [10]. The 3GPP-WLAN interworking has been discussed by Marquez et al. [11] from the session negotiation point of view, analyzing the SIP interworking for each interworking level as defined by 3GPP [1]. The authors also provided a comparison between basic SIP as defined by IETF and the SIP extensions contained in the 3GPP specification. Early WLAN standards can be considered as a wireless version of Ethernet by virtue of supporting a best-effort service based on Ethernet like medium access control (MAC) protocol and up to 54Mbps transmissions rates. A new extension of IEEE 802.11 is emerging to enhance the MAC to support QoS in WLANs named IEEE 802.11e [6], which provides DiffServ type aggregate QoS classes to the air interface. The limitations of legacy 802.11 MAC layer in QoS supporting have been described in [12], the article also investigates the features of 802.11e by evaluating the performance of the Enhanced Distributed Channel Access (EDCA) and the HCF Controlled Channel Access (HCCA) mechanisms using NS-2 simulator. Wallenius et al. [13] analyze how well 802.11e’s QoS properties perform under the different kind of simulation scenarios when packet sizes and channel error rates are varied. The paper concluded that EDCF can be implemented with 3G to support QoS at the situations when 3G devices will use fast WLAN access to the core network; however their simulation work focused only on the wireless medium. The technical specification in [4] was introduced to investigate the necessity and reliability of the applicable QoS mechanism between the

WLAN UE and PDG, and the possible impacts on the 3GPP-WLAN interworking entities, also to ensure that the architecture for 3GPP/WLAN Interworking described in Section 2 is supported by other QoS-related mechanisms being developed in 3GPP. In this paper we provide further investigation of the QoS provision procedures to be supported in the interworking framework.

4. QOS PROVISIONING USING WLAN ACCESS NETWORKS QoS refers to the ability to deliver network services according to the parameters specified in a Service Level Agreement (SLA). At a network resource level; QoS refers to a set of capabilities that allow a service provider to prioritize traffic, control bandwidth, and network latency. Typically different applications have different requirements on end-to-end delay characteristics, throughput, and reliability. While video streaming requires higher bandwidth, it can tolerate slightly more delay and loss rates than does voice over IP (VoIP). As QoS perceived by the user is as weak as the weakest link, the list of addressed network elements must cover the full end-to-end chain of the radio channel, IP core network and IMS domains. A policy-based QoS solution is adopted by the 3GPP for ensuring that sufficient QoS resources are provided to the authorized users in the network [14]. This way the QoS policy is separated from its implementation on various devices. The policy rules are stored in the policy repository from which the Policy Decision Function (PDF) retrieve the appropriate policy rules in response to policy events that are triggered by the contracted IP QoS services by the Policy Enforcement Function (PEF). The PDF translates the acquired policy rules into a set of QoS mechanism configuration actions based on the capabilities of the PEF and the current network conditions. The PEF then executes these PDF-supplied actions to handle the triggering policy events in accordance with the requested IP QoS services. In 3GPP-IMS Release 6 QoS provisioning for IMS over interworking WLAN was not considered. In this paper we try to address this issue and investigate the possible QoS parameters mapping producers using different implementations of the PDF in the 3GPP core network. The end-to-end service should provide transport of user data and signaling between the WLAN UE and another terminal Equipment (TE) over different bearer services of the network. The considered QoS architecture

for WLAN-3GPP IP access consists of 3GPP IP access bearer service and external bearer service, as shown in Fig. 2. The external bearer service may implement several network services such as UMTS bearer service. The 3GPP IP access bearer service provides transport of signaling and data for the IP domain between the UE and the PDG. WLAN bearer service supports WLAN access network specific bearer capability between WLAN UE and the access network. The WLAN support of QoS in layer 2 bases is being addressed by the IEEE 802.11e Work group [6]. Most WLAN technologies do not provide support for QoS, except of IEEE 802.11e. When the WLAN technology used to access IMS service, does not offer sufficient support for QoS (e.g. IEEE 802.11a/b), best effort approach may be used to approximate the service, however this will provide limitations on the services that can be offered to the end user in nonreal time services only. We propose that the QoS capability of the WLAN access network should be send along with other capabilities to the 3GPP AAA server in the access request. This information can be used later on the session initiation procedure to prevent provisioning a high-priority QoS at core network for an end user attached to a QoS support-less access network.

Fig. 2. QoS architecture for WLAN 3GPP IP Access.

According to the 3GPP’s proposed architecture described in Section 2, a tunnel is established between the WLAN UE and the PDG carrying traffic of different QoS levels. Since the data within this tunnel is encrypted including the IP header, the intermediate nodes may not distinguish the individual IP flows and their QoS requirements. For this situation be believe that the best option is using the Differentiated Service (DiffServ) QoS architecture by both UE and PDG. DiffServ outperforms other QoS architectures; such as Integrated Service (IntServ) by providing scalability, flexi-

bility and efficient resource allocation. We expect DiffServ to become a key QoS assurance technique in the upcoming All-IP NGN. Basically, the IP DiffServ octet contains a Differentiated Services Code Point (DSCP) to identify and select the particular Per-Hop Behavior (PHB) that an IP packet will receive at a given network node. A DSCP is set in the IP header of each packet. As for the resource admission control within a DiffServ domain, the PEP is the node that handles resource and policy enforcement (typically the edge router), while the PDP is the server that handles resource allocation and policy decisions (a bandwidth broker in DiffServ terminology). The user’s QoS profile will be downloaded from the HSS to the AAA server at the QoS provisioning phase. According to our purposed freamwork, the QoS profile will include the maximum bandwidth and the maximum DCSP per service allowed to the user. In 3GPP specification in [3] suggests that the implementation of PDG by reusing the gateway GPRS support node (GGSN) deployments of the UMTS. This implementation could be done via using a subset of the Gn reference point, in order to allow re-use of existing GGSN functionality without upgrading them. In this configuration the end-to-end tunnel between WLAN UE and PDG is terminated by the Tunnel Termination Gateway (TTG) of the PDG. A setup of a GTP (GPRS tunneling Protocol) tunnel is triggered towards the GGSN part of the PDG. In the following subsections we compare and analyze the possible QoS parameters mapping process using different ways of implementing the PDG. 4.1. Using a stand-alone PDG: In this implementation the resource reservation could be based on DiffServ QoS mechanism mainly, without the need of the Packet Data Protocol (PDP) context activation used in the UMTS network. Fig. 3 shows our proposed QoS parameter translation process for this PDG implementation. When the Proxy Call Session Control Function (P-CSCF) gets the negotiated SDP parameters of each multimedia component of the desired session from the terminating side through SIP signaling interaction, the P-CSCF maps the SDP parameters to service information per application, and passes it to the PDF over the Gq interface. The PDF authorizes every component negotiated for the session, generates an authorization token and sends it to the P-CSCF (using Gq Interface). The PDF shall map from the service information to the Authorized IP QoS parameters (data rate and DiffServ Code-point (DSCP)) per flow, which shall be passed to the PEP in the PDG via the Go interface. The UE

have to derive the IP QoS parameters (data-rate and DSCP). The mapping/translation function in the UE maps the IP QoS parameters to the WLAN QoS parameters (EDCA Access Category (AC)) for each flow identifier. It is also required that the Access point (AP) in the WLAN access network (WLAN AN) supports a mapping function in order to translate the WLAN QoS parameters to/from IP QoS parameters. We also propose that the support of DiffServ QoS mechanism has to be added to the WAG to handle the routed packets according to their DSCP.

Fig. 3. QoS parameters translation using a stand-alone PDF.

In our proposed framework, the WLAN UE performs packet classification and conditioning in the IP layer before forwarding the IP packets to the AP. the translation/mapping function in the UE has to map IP layer QoS (DiffServ) parameters to the 802.11e MAC layer parameters, by mapping the DSCP placed in the IP header to a suitable EDCA AC, thus IP packets are encapsulated into EDCA 802.11e MAC frames, and forwarded to the proper priority queue. The PDG in this implementation has to support DiffServ and acts as an edge router. The PEP element in the PDG will be responsible for the resource and policy based authorization, such as the comparison between the requested QoS parameters by the UE and the authorized QoS parameters, and it could degrade it if necessary. Table 1 presents the proposed mapping scheme between DiffServ PHBs and EDCA 802.11e ACs. This mapping scheme has been evaluated in our previous work [15].

Table 1. QoS mapping between DiffServ PHBs and EDCA ACs Traffic Class Voice Video Best Effort Best Effort Best Effort Background

DiffServ PHB EF AF12 AF22 AF23 AF33 BE

EDCA AC AC_VO AC_VI AC_BE AC_BE AC_BE AC_BK

IMS QoS Class A B C D E F

4.2. Implementing PDG by reusing GGSN: This implementation can be used by mobile operators those willing to reuse their existing infrastructure and functionality to support users accessing from a WLAN UE. Fig. 4 depicts the required QoS parameters translation according to this implementation of the PDF. The same mapping processes in the P-CSCF, the PDF, and the UE explained in the previous subsection have to be done without any notable changes. Using the UMTS GGSN the resource reservation means PDP context activation. Thus the TTG element in the PDG has to perform a mapping of the QoS parameters from IP level to UMTS level in order to establish a GTP tunnel with the GGSN for every IP tunnel with the UE. The GTP tunnel is established by sending a PDP context activation request from the TTG towards the GGSN. Using the Go Interface the PEP element in the GGSN sends a COPS request to the PDF, which in response sends the configuration parameters to be enforced by the PEP through the Go Interface. The GGSN shall compare the UMTS QoS parameters of the PDP context (set by the TTG) against the derived authorized UMTS QoS parameters from mapping of authorized IP QoS parameters. Table 2 presents the proposed mapping scheme between DiffServ PHBs, UMTS QoS classes and EDCA 802.11e ACs. We believe that this configuration will be costly in term of the required signaling and translation/mapping process, because of the PDP Context Activation procedure which has to be held between the TTG and the GGSN in the PDF. In addition the multi-mapping process in this implementation could cause inconsistency in the delivered QoS level to the end user.

Fig. 4. QoS parameters translation re-using GGSN.

Table 2. QoS mapping between DiffServ PHBs, UMTS QoS class and EDCA ACs Traffic Class

EDCA AC

DiffServ PHB

UMTS QoS Class

Voice Video Best Effort Best Effort Best Effort Background

AC_VO AC_VI AC_BE AC_BE AC_BE AC_BK

EF AF12 AF22 AF23 AF33 BE

Conversational Streaming Interactive Interactive Interactive Background

IMS QoS Class A B C D E F

5. CONCLUSION In this paper we have discussed the access of IMS services by users connected to WLAN, with focus on the QoS provisioning issue. We propose and analyze the mapping processes that are required for end-to-end resource reservation for users willing to access IMS services using their IEEE 802.11e equipment terminals. We have proposed DiffServ as a promising approach for QoS provisioning over the end-to-end IMS-WLAN interworking in order to achieve scalability. We expect that DiffServ will become a key QoS assurance technique in the upcoming All-IP NGN. Some further work should be

undertaken to evaluate both ways of the PDG implementations in providing consistency in the end-to-end QoS delivered to the end WLAN user. REFERENCES [1] 3GPP TR 22.934 v6.2.0, “Feasibility Study on 3GPP System to WLAN Interworking (Release 6),” Sept. 2003. [2] 3GPP TS 23.228 v6.b.0, “IP Multimedia Subsystem (IMS),” TS 23.228, Release 6, Oct. 2005. [3] 3GPP TS 23.234 v6.7.0, “3GPP System to WLAN Interworking; System Description (Release 6),” December 2005. [4] 3GPP TS 23.836 v1.0.0: “Quality of Service (QoS) and policy aspects of 3GPP-Wireless Local Area Network (WLAN) interworking (Release 7)”, Nov 2005. [5] 3GPP, 3GPP TS 33.234 V 6.1.0, “3G Security, Interworking Security (Release 6)” [6] IEEE 802.11 WG, Draft Supplement to Standard for Telecommunication and Information Exchange between Systems – LAN/MAN Specific Requirements – Part II: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications: MAC Enhancements for Quality of Service, IEEE 802.11e Draft 11.0, October 2004. [7] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", IETF RFC 2284, March 1998 [8] S. Kent and R. Atkinson,”Security Architecture for the Internet Protocol”, IETF RFC 2401, November 1998. [9] S. Kent and R. Atkinson, “IP Encapsulating Security Payload (ESP)”, IETF RFC 2406, November 1998. [10] D. Axiotis et al., “Services in interworking 3G and WLAN environments”, IEEE wireless Communication, October 2004. [11] F. Marquez et al., “Interworking of IP multimedia core networks between 3GPP and WLAN”, IEEE Wireless Communications, June 2005 [12] Q. Ni. "Performance Analysis and Enhancements for IEEE 802.11e Wireless Networks". IEEE Network, July/August 2005 [13] E. Wallenius, T. Hämäläinen, T. Nihtilä, J. Joutsensalo , K. Luostarinen, "3G Interworking with WLAN QoS 802.11e", IEEE VTC 2003. [14] W. Zhuang, Y. Gan, K. Loh, K. Chua, “Policy-Based QoS Architecture in the IP Multimedia Subsystem of UMTS”, IEEE Network, May/June 2003. [15] A. Elmangosh, M. Ashibani, F. Ben-Shatwan, “The Interworking between EDCA 802.11e and DiffServ”, IEEE eSCO-Wi 2007.