Integration of the IMS/PCC Framework into the Mobile WiMAX Network

WIMAX: A TECHNOLOGY UPDATE Integration of the IMS/PCC Framework into the Mobile WiMAX Network Suma S. Cherian and Peretz Feder, Alcatel-Lucent Bahareh Sadeghi, Intel Corporation Richard Wisenöcker, Nokia Siemens Networks ABSTRACT This article highlights WiMAX network requirements and functionality for integration with 3GPP Rel 7 IMS/PCC architectures. INTRODUCTION IP multimedia subsystem (IMS) is an open standardized architecture for delivering mobile and fixed multimedia services over an IP network. The IMS standards were originally defined by the Third Generation Partnership Project (3GPP) and largely adopted by the Third Generation Partnership Project 2 (3GPP2). IMS is based on standardized IETF protocols (e.g., Session Initiation Protocol [SIP], DIAMETER, Real-Time Transport Protocol [RTP]), which enables it to provide services in an access-agnostic manner for different IP connectivity access networks (IP-CANs) including General Packet Radio Service (GPRS), interworking wireless LAN (I-WLAN), and WiMAX. In addition, the standards define a policy and charging control (PCC) framework that enables dynamic quality of service (QoS) selection and enforcement and flexible charging models (e.g., service and flow based charging) applicable to both IMS services like voice over IP (VoIP) and non-ims services such as streaming services. The initial WiMAX IMS/PCC framework is built on the 3GPP Rel 7 IMS architecture [1, 2]. Although IMS and PCC are defined as access-agnostic, the WiMAX network presents some unique requirements that require additional functionality to what is described in 3GPP Rel 7. This article presents the WiMAXspecific functionality required for IMS/PCC interworking that is being defined in the WiMAX Forum. The next section covers the WiMAX PCC interworking aspects. We then discuss WiMAX network considerations for interworking with an IMS network. The final section covers some of the planned and ongoing evolutions of the IMS and PCC frameworks in WiMAX. POLICY AND CHARGING CONTROL QOS IN WIMAX RELEASE 1.0 In WiMAX Relase1.0, only a static QoS model based on the concept of preprovisioned service flows is provided to allow the creation of different kinds of service flow bearers, ensuring specific QoS for specified IP connections after a successful network entry until the subscriber leaves the network. The QoS profiles of all the preprovisioned service flows are provided by the core network. In particular, the authentication, authorization, and accounting (AAA) server in the connectivity service network (CSN) provides the information as part of the authentication and entry procedure. The Release 1.0 model is extended in WiMAX Release 1.5 to allow for dynamic creation, modification, and deletion of service flows at any time by use of the PCC framework. PCC ARCHITECTURE OF WIMAX RELEASE 1.5 To facilitate reuse of the existent IMS framework specified by 3GPP, WiMAX reuses the 3GPP PCC framework and adapts it as needed to provide support of dynamic QoS for WiMAX networks. Although the 3GPP PCC framework has been defined as access-agnostic, it is not directly applicable to WiMAX as there are some requirements specific to the WiMAX network that require additional functions to those provided by 3GPP Rel 7 PCC. In this section we first provide an overview of the 3GPP PCC Release 7 framework, then identify the WiMAX-specific requirements not provided by 3GPP Rel 7 PCC, and finally present the WiMAX PCC architecture currently under specification in WiMAX Release 1.5 [6]. Overview of 3GPP PCC Release 7 The PCC framework has been developed in 3GPP Rel 7 as an access-agnostic framework to be used by different IP-CANs. Figure 1 illustrates the PCC architecture as defined in [4]. The policy and charging rules function (PCRF) is in charge of providing control over service data flow detection, gating, QoS, and 66 0163-6804/08/$25.00 2008 IEEE IEEE Communications Magazine October 2008

flow-based charging in the policy and charging enforcement function (PCEF) in the access gateway, and consists of policy control decision and flow-based charging control functionalities. The PCRF receives input for decision making from the application function (AF), subscription profile repository (SPR), and PCEF. The AF (e.g., P-CSCF in IMS) is the network entity that offers applications requiring dynamic policy and/or charging control, and communicates with the PCRF information regarding the dynamic service session status (i.e., activation/deactivation of applications at the subscriber terminal) and the QoS requirements of the application. The SPR is a logical entity that contains the subscription information needed by the PCRF for making decisions regarding subscription-based policies. The PCEF is the functional entity responsible for service flow detection, policy enforcement, and flow-based charging. The PCEF is located in the radio access network gateway and, as specified by the PCRF, implements the policy control by gating and enforcement of the QoS attributes. The PCEF maps the QoS class identifier values, provided by the PCRF, to the specific QoS attributes of the access network and enforces the authorized QoS according to the rules received from the PCRF. The PCEF also enforces charging control and reports the data volume and duration measurements to the offline and online charging systems (OFCS and OCS, respectively). For online charging, an authorization from the OCS is required prior to resource usage. The communication between the PCRF and the AF, SPR, and PCEF is via the Rx, Sp, and Gx interfaces, respectively. While the definition of the Sp reference point is not finalized as part of Rel 7, the Gx and Rx interfaces are DIAME- TER-based protocols. Differences between 3GPP PCC Release 7 and WiMAX PCC R1.5 3GPP Rel 7 PCC assumes a single fixed policy and charging enforcement point in the core network for the lifetime of an IP session (i.e., the traffic plane for each IP session passes through a single PCEF). Instead, WiMAX performs policy and charging enforcement in the access network as specified in Release 1.0. Based on these preconditions, PCEF was placed in the access network with the advantage that no new protocol was required to be developed between the core and access networks. To allow for potential enforcement of policy and charging rules in the core, WiMAX supports an optional PCEF (C-PCEF) that may reside at the home agent (HA) or any other core network element on the bearer plane. A new logical entity, the policy distribution function (PDF), was introduced on the path between the PCRF and the PCEF(s) to support the relocation of the enforcement point in the access network (A-PCEF), and distribute policies to the A-PCEF and C- PCEF. For QoS activation, WiMAX follows the PUSH model instead of the PULL model preferred in 3GPP Rel 7. In the PUSH Subscription profile repository (SPR) Online Charging system (OCS) Offline charging system (OFCS) Figure 1. 3GPP PCC Rel 7 architecture. model, the PCRF triggers enforcement of QoS requirements at the access network when service information is received from the AF. Hence, the MS does not need to perform QoS reservation, which is necessary with the PULL model. This allows for optimization of QoS settings by the network and would simplify the client applications on the terminals. As a consequence, support for network-initiated QoS enforcement is identified as mandatory, whereas terminal-initiated is optional. In addition to the authorization per application performed in 3GPP Rel 7 PCC, the WiMAX PCC framework also requires subscription-based QoS authorization for each subscriber. This is a requirement since there is no further authorization performed at the PCEF (as is the case with the GGSN in 3G networks) or any other entity except the PCRF. WiMAX PCC Release 1.5 Figure 2 depicts the WiMAX Release 1.5 PCC architecture. 1 Support of PCC in Release 1.5 requires the addition of new functions in the CSN, while no new function is introduced in the access service network (ASN). The functions/entities that are not present in the 3GPP Rel 7 PCC architecture (Fig. 1) are described below. The WiMAX network reference model functionally partitions the end-to-end WiMAX network into an ASN and a CSN. The ASN comprises the WiMAX base stations and ASN gateway, providing functionalities such as WiMAX layer 2 connectivity, AAA client, Dynamic Host Configuration Protocol (DHCP) proxy/relay, foreign agent (FA), and PCC Sp Gy Gz Application function (AF) Rx Policy and charging rules function (PCRF) Gx Policy and charging enforcement function (PCEF) Gateway (GW) 1 The functional entities and interfaces related to charging, roaming, and PCC rule enforcement in the core are not presented in this article as they are currently under discussion in WiMAX Release 1.5 and not fully specified. IEEE Communications Magazine October 2008 67

The C-PCEF is an optional enforcement point located in the Connectivity System Network (CSN). The C-PCEF allows CSN-based accounting and gating control in the core, but does not perform any QoS enforcement. ASN CSN AAA/SPR ASN A-PCEF/SFA Accounting agent/ accounting client FA/AR PCC-R3-P (MIP) Policy distribution function (PDF) HA Gx C-PCEF Sp PCRF Accounting client Rx AF (P-CSCF or non-ims application server) Figure 2. WiMAX PCC architecture. 2 The A-PCEF is collocated with Anchor-SFA and may relocate in case of user re-authentication. enforcement. The CSN provides IP connectivity services to the WiMAX subscriber and typically includes the AAA server, DHCP server, HA, and PCC control entities as well as an optional core enforcement point. The SPR functionality is to provide QoS-specific profile information to the PCRF for subscription-based policy decisions. The SPR may be collocated with the AAA server. The AAA server is responsible for access authentication, security, and accounting for subscribers. The PDF is a WiMAX-specific logical entity on the path between the PCRF and the PCEF(s). The PDF is introduced to support the relocation of the enforcement point in the access network (A-PCEF) and distribute policies to the C- PCEF. Furthermore, the PDF is the entity in charge of mapping the 3GPP Rel 7 Gx interface to the WiMAX-specific PCC-R3-P interface when interworking with a 3GPP PCRF. The PDF can be a standalone network entity or integrated with the PCRF. The A-PCEF is the mandatory policy and charging enforcement point and is located at the ASN-GW. The A-PCEF encompasses all the functions of the PCEF, and is responsible for translating the policy and charging rules received from the PCRF/PDF to the WiMAX-specific QoS and charging attributes; that is, mapping of the PCC QoS identifier values into IEEE 802.16e-2005 [5] or IEEE 802.16Rev2 [3] QoS parameters settings and performing accounting according to the received charging rules. The A- PCEF is collocated with the anchor service flow authorization (Anchor-SFA), which is the WiMAX network entity in charge of enforcing the QoS and charging rules. The service flow management (SFM), located in the base station (BS), is the final bearer enforcement point for the over-the-air QoS requested by the SFA. The SFM also performs admission control to ensure that all admitted subscribers receive the requested and authorized QoS. The C-PCEF is an optional enforcement point located in the CSN. The C-PCEF allows CSNbased accounting and gating control in the core, but does not perform any QoS enforcement. The PCC interface on R3 (PCC-R3-P) is defined based on the Gx interface as specified in 3GPP Rel 7. The differences from the Gx are limited to extension of the QoS parameters allowing full support of UGS and ert-vr service types, which are specifically optimized for real-time service flows and the transport of fixed-size data with periodic arrival similar to T1/E1 and circuit-switched connections. Additional modifications to Gx procedures were introduced in R3-PCC-P to add support for PCC session re-anchoring in case of A-PCEF relocation. 2 While Gx is based on DIAMETER only, R3-PCC-P allows support of RADIUS as an option in addition to identifying DIAMETER as the mandatory solution. NETWORK ENTRY In WiMAX Release 1.5 with the PCC framework, the network entry procedure is combined with the PCC procedures for IP session establishment to allow PCC-based dynamic QoS handling. The network entry procedure of WiMAX includes the activation of at least one data connection (service flow) to allow IP traffic and provide the mobile station (MS) a rudimentary bearer for IP address allocation and other basic functionalities like Mobile IP (MIP) tunnel establishment. Figure 3 illustrates the network entry procedure for WiMAX; the SFA initiates the creation of the subscriber-specific preprovisioned service flow to provide capabilities for IP address allocation initiated by the MS. After the MS is successfully assigned an IP address, the ASN-GW triggers an IP-CAN session establishment by sending an IP-CAN session request message to the PCRF via the PDF. The PCRF verifies the request and might contact the AAA server for translation of a pseudo-network access identifier (NAI) [7] and to request subscriber information. For a successful IP-CAN session establishment, the A-PCEF (collocated with the SFA) verifies whether the preprovisioned service flows need to be further modified. This depends on information received during the authentication procedure as well as the bearer-specific information that might be provided by the PCRF with the 68 IEEE Communications Magazine October 2008

MS 802.16e link setup BS (SFM) Bearer establishment Perform IP-address allocation ASN-GW (A-PCEF, SFA) AAA-serverprovided preprovisioned QoS C-PCEF PDF PCRF AAA/SPR server AF EAP user authentication IP-CAN session establishment request The A-PCEF translates the received policy and charging rules to WiMAX specific QoS parameters and accounting filters. Finally, the BS verifies that the required radio resources are available and activates the bearer on the radio link. IP-CAN session establishment response Req. subscriber information Establishment of additional bearers User plane establishment completed IP-CAN session est. req. Confirm request Figure 3. WiMAX network entry procedure. IP-CAN session response message. In addition, the C-PCEF, when deployed, may also create an IP-CAN session; the creation is triggered by the completion of user plane establishment between the CSN and ASN, which can be detected by a successful MIP registration at the HA. DYNAMIC QOS HANDLING Figure 4 depicts the procedures for dynamic QoS handling, for which a successfully established IP-CAN session is a requirement. The PCRF is informed by the AF regarding the activation of an application that requires specific QoS. The PCRF verifies the policy and subscriber profile before authorization of the requested QoS. With successful authorization, the PCRF provides policy rules and charging rules to the A-PCEF as well as the C-PCEF, if applicable, via the PDF. The A-PCEF translates the received policy and charging rules into WiMAX-specific QoS parameters and accounting filters. Finally, the BS verifies that the required radio resources are available and activates the bearer on the radio link. INTEGRATION OF IMS INTO WIMAX NETWORK ARCHITECTURE IMS functions at the application/service layer; therefore, the role of the WiMAX network is primarily to provide IP connectivity to the user to access IMS services. However, there are some WiMAX network-specific considerations for IMS integration discussed in this section, such as P-CSCF placement and discovery in roaming scenarios, and WiMAX support of IMS-based emergency services. WIMAX IMS ARCHITECTURE In a non-roaming scenario, as shown in Fig. 5, the user is always connected to the home network and therefore accesses IMS services via the home network (hcsn). 3 IMS services can be provided by the same business entity providing the CSN infrastructure or by a third party service provider with a contractual relationship with the WiMAX network service provider. For simplicity, this article assumes IMS entities located in the CSN. In a roaming scenario users can access IMS services in the home network from a visited ASN/CSN to which they roam. If the visited CSN also supports IMS, the user can access the IMS services in the home using the proxy call session control function (P-CSCF) in the visited network. The decision on which P-CSCF to use is made by the home network and will depend on several factors, including roaming arrangements, home network policies, and subscriber profile. Using the local P-CSCF enables the visited network operator to compute roaming charges based on the IMS services being used over their network. It also enables them to provide local breakout for certain IMS services 3 The figure does not include all the IMS entities; for example, I-CSCF, S-CSCF, HSS, BGCF, and others are not shown for brevity. IEEE Communications Magazine October 2008 69

In a Mobile IP scenario, having HA in the home network and the P-CSCF in the visited can create an undesirable trombone effect in routing of the signaling traffic if reverse tunneling is enabled. MS BS (SFM) ASN-GW (A-PCEF, SFA) C-PCEF PDF PCRF AF IP-CAN session established Rule update Rule update Perform policy check Service activation Service request Perform bearer binding, QoS mapping and charging rule install Request bearer establishment Rule update Rule update Request bearer establishment Admission control Confirm request Confirm request Confirm update Confirm update Confirm request Figure 4. Dynamic QoS establishment procedure. such as emergency service. The WiMAX IMS R1.5 architecture assumes that the P-CSCF is collocated in the same network (home or visited) with the entity allocating addresses to the MS (i.e., DHCP server, HA). In a MIP scenario, having the HA in the home network and the P- CSCF in the visited one can create an undesirable trombone effect in routing of the signaling traffic if reverse tunneling is enabled. P-CSCF DISCOVERY The P-CSCF is the first point of contact with the IMS core network (CN) proxying registration, session setup, and other messages between the IMS client and the IMS CN. The P-CSCF can reside in the home or visited network in roaming scenarios. This section describes how the MS discovers the address of the P-CSCF in order to register and initiate a session with the IMS CN. Current 3GPP procedures for P-CSCF discovery include a PDP context-based procedure that is GPRS access-specific and a generic DHCPbased approach that can be used for other access technologies. In the DHCP-based approach, the MS uses the DHCP SIP server option to indicate that it wishes to receive P-CSCF addresses/fqdns from a DHCP proxy/server. The WiMAX ASN can support either a DHCP proxy or DHCP relay function to provide the P-CSCF addresses to the MS. The ASN indicates its IP service capabilities (including DHCP relay/proxy capabilities) to the AAA server during device/user access authentication. The AAA server, based on the ASN capabilities information, home network policies, and/or subscriber profile, provides either a P-CSCF address (IP addresses or domain names) or DHCP server information in the AAA reply to the ASN. If a P-CSCF address is received, the ASN stores this information and acts as a DHCP proxy enabling the MS to retrieve the P-CSCF addresses directly from the ASN using DHCP procedures. If the ASN receives a DHCP server address, the ASN provides a DHCP relay function and relays DHCP messages from the MS to the DHCP server. The DHCP server includes the P-CSCF information in the DHCP exchange with the MS. In roaming scenarios, the vaaa acting as an AAA proxy can append the vp-cscf, vha, and/or visited DHCP server information in the AAA exchange between the ASN and the haaa server. The haaa server makes the final decision on whether the visited or home entities should be used. It then includes the selected entities in the AAA reply to the ASN. The haaa assigns a P-CSCF and other entities (i.e., DHCP server, DNS server, HA) to be collocated in the same network (home or visited) to avoid the routing issues described in the previous section. If both visited and home P-CSCF information is provided by the home, the ASN can choose the P-CSCF. 70 IEEE Communications Magazine October 2008

MS R1 (IMS Sig) (IMS bearer) ASN A-PCEF / SFA Accounting client/ accounting agent FA / AR ASN PCC-R3-P R3 (IMS Sig) (IMS bearer) Figure 5. IMS-WiMAX mobile IP non-roaming architecture. EMERGENCY SERVICES IMS-based emergency services (ES) call delivery involves the following main steps: detection of the ES request, determining the location of the nearest ES network, and finally, routing the call to it. These steps are performed by the IMS entities (P-CSCF, E-CSCF) as described in [8] and are generally independent of the WiMAX network. There are, however, some specific functionalities that the WiMAX network needs to provide to support ES, such as unauthenticated ES access to subscriptionless devices, communicating location information as required to the ES network, prioritization of the ES call with matching QoS and service flow creation, and providing a local breakout if available. Subscriptionless ES: When a subscriptionless device enters the WiMAX network, an optional initial network entry attempt is made by the device using provisioned credentials, which fails authentication since the device/user has no subscription. However, when the user makes an ES call, the MS attempts an ESbased network entry using an ES decorated NAI (e.g., {sm=2}username@nsprealm, where sm=2 indicates an ES call). The WiMAX network permits ES only access to the device using this ES decorated NAI. During this step the MS is assigned an IP address and discovers a P-CSCF address. The MS then sends the ES VoIP call to the discovered P- CSCF. The rest of the steps with respect to detection and routing of the ES call by the IMS CN are as described in [8]. Location information: If the MS has location information available, it shall include this information in the ES request. The location information may consist of network location information, that is, the location identifier and/or geographical location information. The IMS CN uses this location information to direct the call to the appropriate ES network. To find out the accurate location of the MS, ES network queries the location server (LS), which in turn triggers a retrieval procedure for network-based location determination using the WiMAX ASN or MSbased location determination. Prioritization: For reliable ES call delivery, it is important to prioritize the ES session over non-emergency sessions. The IMS CN can use Gx PDF PCRF E-CSCF HA Rx C-PCEF CSN Mw P-CSCF Mm/Mi/Mg Mw (IMS Sig) Mb (IMS bearer) the PCC framework to request that the WiMAX IP-CAN assigns the appropriate QoS and service flows for prioritization of the ES session. Local breakout: A visited network can provide local breakout for ES, whereby an emergency IMS session is established in the visited network regardless of whether the MS is registered with IMS in the home network. This topic is still being developed in [3]; some preliminary ideas are discussed later. WIMAX IMS/PCC EVOLUTION This section provides an overview of planned and ongoing evolutions of the IMS and PCC frameworks in WiMAX networks. The section specifically focuses on harmonization with 3GPP Rel 8 and TISPAN RACS as well as the common IMS initiative. Some preliminary ideas for support of local breakout for emergency services are also presented. INTERWORKING WITH THE 3GPP PCC FRAMEWORK Home IMS network In interworking with 3GPP PCC, the WiMAX PCC framework is connected to the 3GPP PCRF. Earlier in this article, the need for a WiMAX-specific functional entity, the PDF, for enabling interworking with 3GPP Rel 7 PCC is discussed. One should note that even with the PDF present in the network, as long as the functionalities of the PCRF and PDF are implemented in separate entities and are not collocated, there are limitations imposed on WiMAX QoS capabilities. WiMAX supports five data delivery service types specified in [5]: UGS, ert-vr, RT-VR, NRT-VR, and BE. UGS and ert-vr service types require the PCRF to provide the packet interval and/or packet size AVP information to the PDF/PCEF. If these AVPs are not carried to the PCEF, which is the case when a 3GPP PCRF is connected to WiMAX PCC entities by a Gx interface, UGS and ert-vr service types cannot be supported. Currently 3GPP is defining Rel 8, in which an evolved packet system (EPS) provides connectivity to different access technologies, including WiMAX as a trusted non-3gpp IP access. Rel 8 PCC is being defined to accommodate this architecture. Figure 6 depicts the non-roaming 3GPP A visited network can provide local breakout for emergency service, whereby an emergency IMS session is established in the visited network regardless of whether the MS is registered with IMS in the home network. IEEE Communications Magazine October 2008 71

The goal of interworking between 3GPP PCC Rel 8 and WiMAX PCC framework is achieved by ensuring that not only the architectures of the two frameworks match, but also that the PCC protocol defined on WiMAX R3 reference point is the same as the PCC protocol defined on Gxa. 4 For example, an IPv6 MS already has a local IP address in the CoA, so only local P-CSCF discovery procedures are needed; or an MS might already have a local address and vp-cscf address if it is already receiving services via the visited network. Trusted non-3gpp IP access STa Gxa Gxa 3GPP AAA server PCRF Figure 6. Trusted non-3gpp IP access PCC architecture in 3GPP Rel 8. Rel 8 PCC architecture related to trusted non- 3GPP IP access (WiMAX) [9]. Without getting into the architectural details, we point out the similarities between the WiMAX Release 1.5 PCC framework and the 3GPP Rel 8 PCC, and how the WiMAX PCC framework can evolve in future releases to converge with the 3GPP PCC framework. Comparing the WiMAX PCC architecture presented in Fig. 2 with the architecture in Fig. 6, we observe the followings: A-PCEF maps to the access GW in the trusted non-3gpp access. C-PCEF maps to the PDN-GW. Integrating the PDF with the PCRF, the two architectures become identical. The goal of interworking between 3GPP PCC Rel 8 and the WiMAX PCC framework is achieved by ensuring that not only the architectures of the two frameworks (currently being developed independently) match, but also that the PCC protocol defined on the WiMAX R3 reference point is the same as the PCC protocol defined on Gxa. COMMON IMS INITIATIVE: INTEGRATION OF WIMAX PCC AND TISPAN RACS TISPAN is an extension to the IMS architecture developed by ETSI to meet the requirements of broadband fixed access networks. However, in order to prevent fragmentation of IMS standards, an effort has been initiated by ETSI and 3GPP to develop a common global IMS used for mobile, fixed, and convergence. The development of common IMS as an enhanced 3GPP IMS structure is being carried out in 3GPP Rel 8. The TISPAN policy architecture is called the resource and admission control subsystem (RACS), and enables applications (SIP and non- SIP) to request and reserve resources from the access and aggregation networks [10]. Even though the TISPAN architecture is based on 3GPP IMS, the components and interfaces used in the RACS model are quite different from the 3GPP PCC model in order to handle fixed network requirements and non-sip applications that were not addressed by 3GPP in initial releases. Therefore, integrating WiMAX, which Gx Packet data network (PDN) Gateway S6b Rx SGi Operator s IP services uses the 3GPP PCC model, with the TISPAN RACS framework will require modification of the RACS architecture to support the 3GPP PCC-based interfaces toward the WiMAX network. Integration of WiMAX with existing broadband fixed access networks (e.g., digital subscriber line) using a TISPAN-based policy management infrastructure, in harmonization with the common IMS effort in 3GPP, is currently an ongoing task in WiMAX Release 1.5. LOCAL BREAKOUT FOR IMS EMERGENCY SERVICE In roaming scenarios it is highly desirable to provide local breakout for emergency services since only the local network may know the appropriate ES network that can handle the ES call in the user s roaming area. Since ES is not a subscription service, it can be supported entirely in the visited network without interaction with the home network. With local breakout for ES, the user continues to use the home network for all other subscription-based services. Local breakout requires intelligence in the device to detect a native or roaming ES call and then select the visited network for the service. The MS can detect it is roaming through the NSP-ID advertisement information. In scenarios where more than one visited network is available, it is desirable for the MS to be able to select a visited network based on the capabilities supported to avoid delays in attempting an ES call in one and then retrying in another if the first is not capable of providing local treatment for the call. Once network selection is done, the MS initiates an ES based network entry (if necessary) 4, as described earlier, to obtain a local IP address and a local P-CSCF. If the visited network can support a local breakout, the vaaa includes the visited network addresses (P-CSCF, DHCP server) in the request to the haaa. The haaa server is configured with an ES profile, and, based on the profile and the parameters in the request, it sends back in the response the P- CSCF to be used for the ES call or the address of a DHCP server provisioned with the P-CSCF address. The MS then uses the DHCP proxy/ relay mechanisms mentioned earlier to retrieve this info. 72 IEEE Communications Magazine October 2008

If the MS does not have the capability of detecting an ES call or has roamed to a visited network and directs the call to its home network, the hp-cscf should be able to indicate to the MS via a 380 (alternative service) response that it should initiate the ES call in the visited network. SUMMARY This article presents the WiMAX-specific architecture and functionality required to integrate a WiMAX Release 1.5 network with existing IMS/PCC architectures defined in the 3GPP Rel 7 standards. The goal in defining this architecture has been to limit changes to the standard 3GPP interfaces/components to a minimum. New functionality and interfaces have been defined where necessary in the WiMAX architecture to meet WiMAX access-specific requirements. It is expected that the current architecture will evolve in future releases to be harmonized with 3GPP Rel 8 and the common IMS framework, and will support TISPAN Interworking. REFERENCES [1] 3GPP TS 24.229, Rel 7 v. 7.11.0, Internet Protocol (IP) Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), http://www.3gpp.org/ftp/specs/archive/ 24_series/24.22/24229-7b0.zip [2] 3GPP TS 23.228, Rel 7 v. 7.11.0, IP Multimedia Subsystem (IMS), http://www.3gpp.org/ftp/specs/archive/ 23_series/23.22/23228-7b0.zip [3] WiMAX Forum; http://www.wimaxforum.org/ [4] 3GPP TS 23.203, Rel 7 v. 7.6.0, Policy and Charging Control Architecture ; http://www.3gpp.org/ftp/specs/ archive/23_series/23.20/23203-760.zip [5] IEEE 802.16e-2005 and 802.16/COR1, Local and Metropolitan Area Networks, Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands, http://www.ieee802.org/16/ [6] IEEE 802.16Rev2/D4, Local and Metropolitan Area Networks, Part 16: Air Interface for Broadband Wireless Access Systems, http://www.ieee802.org/16/ [7] B. Adoba et al., The Network Access Identifier, RFC 4282, Dec. 2005; http://www.ietf.org/rfc/rfc4282.txt [8] 3GPP TS 23.167, Rel 7 v. 7.8.0, IP Multimedia Subsystem (IMS) Emergency Sessions ; http://www.3gpp.org/ ftp/specs/archive/23_series/23.167/23167-780.zip [9] 3GPP TS 23.402, Rel 8 v. 8.1.1, Architecture Enhancements for Non-3GPP Accesses, http://www.3gpp.org/ ftp/specs/archive/23_series/23.402/23402-811.zip [10] ETSI ES 282 003 v. 1.1.1, Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN), Resource and Admission Control Sub-system (RACS), Functional Architecture. BIOGRAPHIES SUMA S. CHERIAN (scherian@alcatel-lucent.com) is a member of technical staff in the Mobile Access Group at Alcatel- Lucent, Whippany, New Jersey. She has been working at Alcatel-Lucent since 1996, doing systems engineering and architecture work for packet, wireless, and next generation networks and applications. She is currently working on WiMAX systems engineering. She holds a Master s degree in electrical engineering from Rutgers University, New Jersey. PERETZ FEDER [M] (pfeder@alcatel-lucent.com) is a technical manager at Alcatel-Lucent Bell Labs. He leads a group of network engineers who define, develop, characterize, and verify wireless mobile IP networks including cellular and IEEE systems. He has worked with first-, second-, and thirdgeneration wireless systems, developing radio channel cards and protocols for the Alcatel-Lucent flagship AMPS and Flexnet networks. Recently he has been working with high-speed fourth-generation wireless systems and leads his company delegation at the WiMAX Forum. He holds B.S.E.E. and M.S.E.E. degrees from Columbia University School of Engineering, New York City, New York. BAHAREH SADEGHI (bahareh.sadeghi@intel.com) received her Ph.D. in electrical and computer engineering from Rice University, Houston, Texas, in 2004. She then joined the Communications Technology Laboratory at Intel Corporation as a research scientist. She has been conducting research in wireless mesh networking, the interworking of 3GPP and WiMAX networks, and more recently the area of personal area networks operating at 60 GHz. RICHARD WISENOCKER (richard.wisenoecker.ext@nsn.com) received his Austrian professional title as an electrical engineer in 1988 from the Higher Technical Institute Schellinggasse Vienna, Austria. He joined Siemens in 1989 and has been working for Nokia Siemens Networks since 2007. He has been working as a researcher on IMS and policy-based networks for several years, and as a WiMAX standardization delegate since 1996. The goal in defining this architecture has been to limit changes to the standard 3GPP interfaces/components to a minimum. New functionality and interfaces have been defined where necessary in the WiMAX architecture to meet WiMAX access specific requirements. IEEE Communications Magazine October 2008 73