SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 46

LTE — 3GPP RELEASE 8 Voice Call Handover Mechanisms in Next-Generation 3GPP Systems

Apostolis K. Salkintzis, Motorola Mike Hammer, Cisco Itsuma Tanaka, NTT DOCOMO Curt Wong, Siemens Networks

ABSTRACT path, and progressively scale network capacity and service innovation in a economically effi- The evolved 3GPP system is a hybrid mobile cient way. The integrated system is characterized network architecture supporting several radio by a heterogeneous architecture (i.e., supporting access technologies and several mobility mecha- diverse radio access networks) capable of provid- nisms. In this article we briefly review the archi- ing mobile broadband services in strategic geo- tecture and key components of this system, with graphic areas and ensuring the “best connection” particular emphasis on how it can support voice of users at any place, anytime. However, such call mobility in several deployment scenarios. integration requires us to address a vast range of First, we present the so-called single-radio voice interoperability and migration issues that arise call continuity mechanisms that enable mid-call from the need to support seamless mobility handover of VoIP calls from E-UTRAN access across new and legacy radio access technologies, to the legacy UTRAN/GERAN or 1xRTT and migrate the legacy services to new radio access. Then we focus on deployment scenarios accesses. As an example, consider a user that ini- that do not support voice services on E-UTRAN tiates a voice call inside a 4G hotspot. This call and present the so-called fallback mechanisms is carried out over the 4G access network with that enable handover from E-UTRAN to voice over IP (VoIP) technologies; but as the UTRAN/GERAN or 1xRTT at the beginning of user goes out of 4G coverage, the call needs to a voice call. Finally, we address the application- be sustained and seamlessly handed over to the layer voice call handover mechanisms enabled by “umbrella” 2G/3G access network, which typical- the IP multimedia subsystem. Our conclusion is ly provides a much wider radio footprint. that the next generation of 3GPP systems are It may also happen that voice services are not highly sophisticated mobile communication sys- initially supported over 4G access (e.g., in order tems that support extended voice call mobility to eliminate the cost of deploying VoIP-based mechanisms, capable of addressing all commer- services), in which case the user would have to cial deployment needs. be handed over to the overlay 2G/3G access right after the call request is made. In this case INTRODUCTION the 2G/3G access is used as a fallback access that supports the legacy services when they are not As the wireless industry makes its way to the yet available in the 4G access. All these require- next generation of mobile communication sys- ments create the need for voice call handover tems, it is important to engineer solutions that mechanisms from the emerging 4G access tech- enable seamless integration of the emerging nologies to the legacy 2G/3G access technolo- fourth-generation (4G) technologies within the gies. currently deployed 2G/3G infrastructures. This is In this article we focus on such voice call important because, in most cases, the second- handover mechanisms and address in particular and third-generation (2G/3G) systems provide the voice call handover mechanisms in the next- the solid ground on which the next-generation generation Third Generation Partnership Pro- systems will be built, and will continue providing gram (3GPP) networks, which typically take the main revenue stream for operators for sever- place between the evolved 3GPP radio access al years along the migration path to 4G. The network (evolved UMTS terrestrial radio access integration of emerging access and core tech- network [E-UTRAN] [1]) and the legacy nologies within the existing 2G/3G networks 3GPP/3GPP2 radio access networks, (e.g., code-division multiple access [CDMA], UTRAN/GERAN and CDMA2000 1xRTT. In Global System for Mobile Communications this context we present and explain the technical [GSM], General Packet Radio Service [GPRS], details of three different voice call handover and Universal Mobile Telecommunications Sys- mechanisms, which aim at addressing three dif- tem [UMTS]) can enable a smooth evolution ferent deployment scenarios of next-generation

46 0163-6804/09/$25.00 © 2009 IEEE IEEE Communications Magazine • February 2009

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 47

2G/3G 3GPP core

lu-cs MSC E MSC Legacy UTRAN circuit-switched lu-ps services

A/lu-cs GERAN Gn SGSN GGSN Gi Gb/lu-ps

S3 S4 Packet data network(s) 3GPP EPC MME S11 e.g. IMS, S1-AP Internet, etc. S1-U S5 E-UTRAN S-GW P-GW SGi S6a Gxc Gx User S2b Gxb equipment AAA/ PCRF (UE) S101 Gxa HSS ePDG S103 STa S2a SWn EPC: Evolved packet core S-GW: Serving gateway CDMA2000 P-GW: PDN gateway HRPD MME: Mobility management entity ePDG: Enhanced packet data gateway PCRF: Policy and charging rules function HSS: Home subscriber server AAA: Authentication, authorization, accounting WiMAX WLAN

n Figure 1. Simplified architecture of the evolved 3GPP network.

3GPP systems. First we present handover mech- radio accesses. It is also assumed that in such anisms that enable mid-call handover of VoIP deployments there are no transport layer mecha- calls from E-UTRAN access to the legacy nisms (e.g., based on mobile IP and its deriva- UTRAN/GERAN or 1xRTT access (note that tives) that can meet the voice continuity E-UTRAN access is sometimes also referred to requirements. We also provide some background as 4G access). These mechanisms are particular- material in the next section, where we present ly important in deployment scenarios where the key aspects of the next-generation 3GPP sys- voice services are supported on E-UTRAN (as tems, and introduce the fundamental network explained later, E-UTRAN supports only IP- elements and interfaces. Finally, we wrap up our based services) but, due to limited E-UTRAN discussion by providing a number of concluding coverage, handover to UTRAN/GERAN or remarks. 1xRTT is necessary to maintain seamless voice services over wider geographical areas. Second, we focus on deployment scenarios that do not AN OVERVIEW OF NEXT- support voice services on E-UTRAN. This most- ENERATION YSTEMS ly targets initial deployments of evolved 3GPP G 3GPP S systems, in which voice services are not yet To provide some background material for our migrated to E-UTRAN (i.e., not supported yet further discussion, we present here a short over IP). For those scenarios, we present the key overview of the evolved (or next-generation) aspects of a voice call handover mechanism that 3GPP systems. Readers interested in more enables handover from E-UTRAN to UTRAN/ details on the evolved 3GPP systems are referred GERAN or 1xRTT at the beginning of a voice to the 3GPP specifications [1–5] and other arti- call. The handover is triggered by the arrival of cles in this Feature Topic. an originating or terminating voice call, which As part of Release 8 of the 3GPP specifica- can only be served on UTRAN/GERAN or tions, 3GPP has been studying and specifying an 1xRTT access and in the traditional circuit- evolved packet system (EPS) under the System switched (CS) domain [2]. We then address Architecture Evolution (SAE) work item [2]. voice call handover mechanisms enabled by the The EPS is composed of a new radio access net- IP multimedia subsystem (IMS). Such mecha- work, called E-UTRAN [1], and a new all-IP nisms mostly target deployment scenarios in core network, called evolved packet core (EPC) which voice services are supported on E- [3, 4]. The EPC can be considered an evolution UTRAN and non-3GPP-defined radio accesses, of the legacy GPRS architecture with additional such as WLAN and WiMAX, and there is also a features to improve performance, supporting need to support voice continuity across these broadband E-UTRAN access, PMIPv6 mobility,

IEEE Communications Magazine • February 2009 47

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 48

and integration with non-3GPP radio technolo- SINGLE-RADIO In order to provide gies such as wireless LAN (WLAN), CDMA2000, and WiMAX. As shown in Fig. 1, VOICE CALL CONTINUITY seamless continuity the evolved 3GPP network is virtually composed of voice services in of an evolved version of the legacy 2G/3G net- Especially in the first days of E-UTRAN deploy- wide geographical work (with the well-known UTRAN/GERAN ment, coverage will be limited and available only radio accesses) and the EPC, which supports E- in scattered strategic locations, where wireless areas, it is important UTRAN access and integration with a range of broadband services are most needed. Therefore, for the next non-3GPP accesses. Note that for simplicity all in order to provide seamless continuity of voice network interfaces are not shown in Fig. 1. The services in wide geographical areas, it is impor- generation of 3GPP interfaces relevant to the voice call handover tant for the next generation of 3GPP systems to systems to seamlessly mechanisms are presented and discussed in sub- seamlessly hand over voice calls between E- handover voice calls sequent sections. UTRAN [1] and UTRAN/GERAN coverage As shown in Fig. 1, a number of diverse areas. Although this is not a new requirement between E-UTRAN access networks, such as CDMA2000, WLAN, (e.g., similar voice continuity requirements exist and UTRAN/GERAN WiMAX, GERAN, UTRAN, and E-UTRAN, between UTRAN and GERAN, and between are connected to a common core network (the CDMA2000 1xRTT and HRPD), in this case coverage areas. EPC) based on IP technology through different there are new challenges we have to face. First, interfaces. All 3GPP-specific access technologies voice calls on E-UTRAN can only be carried out are connected through the serving gateway (S- via IP-based technologies and therefore are pro- GW), while all non-3GPP specific access tech- vided as IMS-based services. On the contrary, nologies are typically connected through the voice calls on UTRAN and GERAN are typical- packet data network gateway (P-GW) or evolved ly carried out with conventional CS technologies packet data gateway (ePDG), which provides and therefore are provided as CS domain ser- extra security functionality for untrusted access vices. This creates the need to transfer and con- technologies (e.g., legacy WLANs with no strong tinue voice calls between two different service built-in security features). The S-GW acts as a domains, CS and IMS. Second, the voice calls mobility anchor for mobility within 3GPP-specif- need to be transferred across service domains ic access technologies, and also relays traffic and radio access technologies with so-called sin- between the legacy serving GPRS support node gle-radio mobile terminals, that is, mobile termi- (SGSN) accesses and the P-GW. For E-UTRAN, nals that cannot support simultaneous signaling the S-GW is directly connected to it through the on both E-UTRAN and UTRAN/GERAN radio S1 interface, while the SGSN is the intermediate accesses. This is a key requirement because E- node when GERAN/UTRAN is used. It is UTRAN and UTRAN/GERAN radio channels important to mention that a mobility manage- may be deployed on the same or neighboring ment entity (MME) is also incorporated in the frequency bands; having mobile terminals simul- architecture for handling control functions such taneously active on both radio channels presents as authentication, security, and mobility in idle severe technical challenges for the design of the mode. physical layer. This requirement for single-radio For access to EPC through WLAN, mobile terminals makes the use of existing dual- CDMA2000 HRPD, or WiMAX [3], different radio voice call transfer mechanisms (e.g., mech- data paths are used. HRPD and WiMAX are anisms specified in 3GPP TS 23.206 [6]) considered trusted non-3GPP accesses and are infeasible for voice call continuity between E- directly connected to a P-GW through the S2a UTRAN and UTRAN/GERAN access. interface, which is used particularly for trusted Below we present and explain the single- non-3GPP accesses. On the other hand, a radio solutions recently standardized by 3GPP WLAN considered as untrusted access (e.g., for enabling voice call continuity between E- because it may not deploy any strong security UTRAN and UTRAN/GERAN, and between E- measures) connects to the ePDG and then to a UTRAN and CDMA2000 1xRTT (the stage 2 P-GW through the S2b interface. In this case specification can be found in [7]). We primarily the ePDG serves as a virtual private network focus on voice call handover in the direction (VPN) gateway and provides extra security from E-UTRAN to UTRAN/GERAN and from mechanisms for EPC access. All data paths E-UTRAN to CDMA2000 1xRTT, since this is from the access networks are combined at the considered much more important (due to the P-GW, which incorporates functionality such as limited E-UTRAN coverage) than the other packet filtering, QoS policing, interception, direction of handover. For this reason, only this charging, and IP address allocation, and routes direction of handover is also supported by the traffic over SGi to an external packet data net- current standards [7]. work (e.g., for Internet access) or the operator’s internal IP network for accessing packet services VOICE CALL TRANSFER FROM provided by the operator. Apart from the net- E-UTRAN TO UTRAN/GERAN work entities handling data traffic, EPC also contains network control entities for keeping Figure 2a shows the architecture that enables user subscription information (home subscriber single-radio voice call continuity (SR-VCC) server [HSS]), determining the identity and between the E-UTRAN and conventional privileges of a user and tracking his/her activi- UTRAN and GERAN radio networks [7]. This ties (access, authorization, and accounting architecture is based on the IMS and requires all [AAA] server), and enforcing charging and QoS voice calls initiated on E-UTRAN to be policies through a policy and charging rules anchored in IMS (a later section explains how function (PCRF). this is done). The architecture also requires at

48 IEEE Communications Magazine • February 2009

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 49

2G/3G 3GPP core Although the MSC lu-cs solution for SR-VCC E UTRAN lu-ps was originally MSC required to enable A or lu-cs GERAN SGSN enhanced Gb or lu-ps for SR-VCC the handover of one ongoing voice call

S3 Sv from E-UTRAN to D UTRAN or GERAN, User S4 equipment during the standard- (UE) MME S6a HSS ization process it was S11 IP multimedia enhanced to further S-GW S5 P-GW SGi subsystem facilitate the (IMS) handover of E-UTRAN S1-U 3GPP EPC potential non-voice sessions that might Non-voice path before handover Voice path before handover Non-voice path after handover to GERAN Voice path after handover to GERAN be active in parallel with the voice call.

Enhanced GERAN or S-GW/ Remote UE E-UTRAN MME MSC MSC SGSN UTRAN P-GW IMS end

1. Measurement reports Voice path before handover Handover decision 2. Handover required

3a. Request reservation of PS resources

MME splits voice bearers from 3b. Request reservation of CS resources non-voice bearers and initiates their relocation towards the MSC and SGSN, respectively. 3c. PS resources reserved

3d. CS resources reserved

4. Initiation of session transfer (STN-SR)

IMS session transfer 5. Handover command procedures Voice packets from remote end are forwarded to enhanced MSC UE moves to GERAN 6. HO detection 7a. PS handover complete 7b. Update bearer

8. CS handover complete

Voice path after handover completion

n Figure 2. a) Architecture for single-radio VCC between E-UTRAN and UTRAN/GERAN; b) message flow diagram for voice and non-voice single-radio handover from E-UTRAN to UTRAN or GERAN (with dual transfer mode capability).

least one mobile switching center (MSC) server and the associated SR-VCC procedures, which in the traditional CS domain to be enhanced are further explained below. with interworking functionality and a new inter- Although the solution for SR-VCC was origi- face, called Sv. Such an enhanced MSC server is nally required to enable the handover of one referred to as “MSC server enhanced for SR- ongoing voice call from E-UTRAN to UTRAN VCC”; when combined with a standard media or GERAN, during the standardization process gateway (MGW), it is referred to as “MSC it was enhanced to further facilitate the hand- enhanced for SR-VCC.” In addition, the MME over of potential non-voice sessions that might in the EPC (discussed previously) requires addi- be active in parallel with the voice call. To better tional functionality to support the Sv interface explain this, we show in Fig. 2a user equipment

IEEE Communications Magazine • February 2009 49

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 50

(UE) that has a voice session and a non-voice • If the neighbor UTRAN/GERAN cells can During the execution session (say, a video streaming session) active in support VoIP E-UTRAN. We assume that both sessions are • If the UE has an active voice call of the IMS session enabled by IMS, so the data flows of these ses- Based on this information, the serving E- transfer procedure, sions (indicated with the double-head arrows) UTRAN cell decides when an SR-VCC hand- the Remote End is enter the IMS cloud. When the UE goes out of over is required and selects the target UTRAN E-UTRAN coverage, the SR-VCC procedure is or GERAN cell (which in this case can support updated with new triggered to relocate all data flows to (say) a only voice services in the traditional CS domain). Session Description GERAN radio cell. In the example shown in Fig. When this decision is taken, the E-UTRAN 2a, this cell is not controlled by the MSC sends a Handover Required message (step 2) to Protocol (SDP) enhanced for SR-VCC, so another MSC is the MME with some information indicating that contact details (e.g., involved (however, this is not always the case). SR-VCC handover is required. with a SIP re-INVITE The voice session is relocated from the P-GW to This information is necessary in the MME in the MSC enhanced for SR-VCC and the non- order to decide what type of handover to exe- message) and voice session is relocated from the S1-U inter- cute; in this case it will be a handover toward the subsequent down- face to the S4 interface and then to GERAN CS domain and a handover toward the packet- through the SGSN. In this example the GERAN switched (PS) domain. In turn, the MME sepa- stream voice packets radio access supports simultaneous access to rates the active voice bearer of the UE from its are forwarded to the voice and non-voice (GPRS) services. To meet active non-voice bearer(s) and initiates two MSC enhanced for the seamless voice transfer requirements (i.e., handover procedures in parallel: one to hand make the voice transfer imperceptible to the over the non-voice bearer(s) to the PS domain SR-VCC. user), this handover process should create voice and another to hand over the voice bearer to the interruption of no more than a few hundreds of CS domain of the 2G/3G core. These procedures milliseconds. For the non-voice session(s), how- are typically executed in parallel, but for the ever, seamless transfer cannot be guaranteed sake of presentation, Fig. 2b shows them in given the limited data bandwidth offered by sequence: first the PS handover and then the CS UTRAN/GERAN compared to the broadband handover. Step 3a is used for preparing the non- data capabilities of E-UTRAN. Therefore, voice resources in the PS domain according to although non-voice session(s) can be transferred the standard relocation procedures specified in and continue in the UTRAN/GERAN packet- 3GPP TS 23.060 [5]. Also, step 3b is used for switched domain, there is no guarantee that the preparing the voice resources in the CS domain transfer would be seamless and the quality of according to the relocation procedures in 3GPP service sustained after the transfer. TS 23.060 [5] and the inter-MSC handover pro- The SR-VCC solution is further explained cedures in 3GPP TS 23.008. Note that in the below with the aid of the message flow diagram example message flow of Fig. 2b, E-UTRAN illustrated in Fig. 2b. In this example diagram decided to transfer the voice and non-voice ses- the UE is initially in E-UTRAN and has active sions of the UE to a neighbor GERAN cell, voice and non-voice sessions in parallel. The which supports both PS and CS services in paral- voice session is anchored in IMS and terminates lel (also called dual transfer mode [DTM]). This at the remote end, which is a traditional public GERAN cell is also connected to a legacy MSC switched telephony network (PSTN) phone; (i.e., not enhanced for SR-VCC), which does not thus, IMS/PSTN interworking functionality is interface directly with the MME, so the voice invoked. At the top of the diagram, the path of handover signaling must pass through an MSC the voice flow is illustrated, which goes through enhanced for SR-VCC and an inter-MSC hand- the appropriate (IMS/PSTN) interworking func- over must be carried out between the MSC tions in the IMS subsystem and is then routed to enhanced for SR-VCC and the legacy MSC. the UE via P-GW, S-GW, and E-UTRAN (note Message 4 is a key step in the handover pro- that for convenience the S-GW and P-GW are cedure and merits further explanation. This mes- shown in the same box). A similar flow path sage is merely a new voice call request (e.g., an could be traversed by the non-voice session, ISUP IAM) toward a special number, called ses- although this is not shown in Fig. 2b for simplici- sion transfer number for SR-VCC (STN-SR). ty. At the end of the flow diagram the voice and This call request is routed to a special applica- non-voice sessions are transferred, and continue tion server in the IMS subsystem, called service in a GERAN or UTRAN cell. centralization and continuity application server During its active voice session the UE takes (SCC AS), which then correlates the received inter-radio access technology (inter-RAT) mea- STN-SR with an active IMS voice session, in this surements; that is, it measures the signal strength case with the voice session between UE and the and quality of the neighbor UTRAN and/or remote end (see 3GPP TS 23.237 [8] and a sec- GERAN channels. The list of available inter- tion in this article for further details). The recep- RAT channels is regularly transmitted in the sys- tion of a new call request for STN-SR is a signal tem information of the serving E-UTRAN cell. for SCC AS that the associated IMS voice ses- The UE transmits inter-RAT measurement sion needs to be redirected to a new endpoint reports as well as measurement reports for the (in this case to the MSC enhanced for SR-VCC); currently selected E-UTRAN cell (step 1 in Fig. therefore, it triggers the IMS session transfer 2b), which are typically input to the handover procedures specified in 3GPP TS 23.237 [8]. decision algorithms. Apart from the measure- Note that for each UE, a dedicated STN-SR ment reports, the serving E-UTRAN cell knows: number is configured in the HSS, and the MSC • If the UE is SR-VCC-capable (this informa- enhanced for SR-VCC receives this number tion comes from the MME during attach- from the MME (in step 3b), which receives this ment or handover) number from the HSS during the UE’s initial

50 IEEE Communications Magazine • February 2009

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 51

attachment to EPC. During the execution of the ing message, including the necessary 1x parame- IMS session transfer procedure, the remote end ters (e.g., 3G1x overhead parameters, RAND In some initial is updated with new Session Description Proto- value) to the UE to start the 1xRTT SR-VCC deployments of col (SDP) contact details (e.g., with a Session procedure (steps 1–2, Fig. 3b). In step 3 the UE Initiation Protocol [SIP] re-INVITE message), starts the 1x SR-VCC procedure with the 1xRTT evolved 3GPP and subsequent downstream voice packets are MSC (based on 3GPP2 X.S0042-0 [9]). This is systems there will be forwarded to the MSC enhanced for SR-VCC done by establishing a signaling tunnel via EPC (more correctly, to the MGW associated with and 1xCS IWS. When the 1xRTT MSC has no support of voice this MSC). received a positive acknowledgment from the services on E-UTRAN. After both PS and CS resource preparation is 1xRTT radio for traffic allocation and from the In such deployments completed (steps 3c and 3b, respectively), the IMS for successful domain transfer, it returns an MME responds to the Handover Required mes- IS-41 handoff message to the UE (similar to the however it is still sage received in step 2 with a Handover Com- handover command) via the established signal- necessary that users mand, which is then transmitted to UE in step 5. ing tunnel (step 5). Upon receiving this message, This command includes information describing the UE then performs the handover to 1xRTT on E-UTRAN be able the CS and PS resources allocated for the UE access and continues to transmit voice via that to participate in (e.g., the target GERAN cell identity, carrier system. The voice bearer path is no longer car- voice calls. This can frequency, traffic channel specification). After ried by the EPC. E-UTRAN requests the MME this step, the UE moves to the indicated target to release the UE context (step 6). The MME be achieved by GERAN cell and uses conventional GERAN completes this procedure by requesting the S- conducting a so- handover completion procedures. In step 6 the GW to suspend the EPS bearer, step 7. (I.e., S1- UE is detected in the target GERAN cell, and in U bearers are released for all EPS bearers and called fallback to a steps 7 and 8 the PS and CS relocation/handover the voice bearer is deactivated. The non-GBR legacy 2G/3G access procedures are completed, respectively. After bearers are preserved and marked as suspended network. step 7b the non-voice bearers are switched from in the S-GW). Upon receipt of downlink data the S1-U interface to the S4 interface, and after the S-GW should not send a downlink data noti- step 8 the voice bearer is fully re-established fication message to the MME. with a new access leg in the GERAN CS domain. Note that the voice gap created by the handover procedure starts from the execution of the IMS VOICE CALL HANDLING WITH session transfer procedures to the completion of ALLBACK TO step 8 and is expected to last a few hundreds of F 2G/3G milliseconds. As discussed before, in some initial deployments of evolved 3GPP systems there will be no sup- VOICE CALL TRANSFER FROM port of voice services on E-UTRAN. In such E-UTRAN TO CDMA2000 1XRTT deployments, however, it is still necessary that users on E-UTRAN be able to participate in Figure 3a shows the architecture that enables voice calls. This can be achieved by conducting a SR-VCC between the E-UTRAN and CDMA so-called fallback to a legacy 2G/3G access net- 1xRTT radio networks. This architecture work that supports traditional voice services requires a 1xCS interworking solution (IWS) (e.g., UTRAN, GERAN, or CDMA2000 1xRTT) function in the traditional 3GPP2 CS domain to at the moment a voice call is requested. This interwork with EPS via a new interface, called fallback is effectively a service-based handover S102. The 1xCS IWS enables UE to communi- mechanism, a handover triggered by a service cate with the 1xRTT MSC while it is connected request, which in this case is a request for an to the EPC via E-UTRAN. From SR-VCC per- originating or terminating voice call. After the spective, this mechanism minimizes the voice user falls back to 2G/3G access, standard CS gap by allowing the UE to establish the target voice call setup procedures are used to establish CS access leg while it is still on the E-UTRAN the voice call in the CS domain. This technique access, prior to the actual handover to 1xRTT of falling back to the 2G/3G CS domain for access. The MME in the EPC (discussed previ- voice services is considered an interim solution ously) requires additional functionality to sup- that can fill the gap between the initial E- port the S102 interface and mainly functions as a UTRAN deployment and the introduction of signaling relay station between the UE and 1xCS voice and other IP services over E-UTRAN. IWS. The fallback to the 2G/3G CS domain (or CS This architecture was designed to handle only fallback for short) is enabled by the following the voice part of an IMS session [7]. The trans- characteristics: fer of a non-voice component is not specified • Mobility management is combined with EPS (different from SRVCC to UTRAN/GERAN). mobility management. This SR-VCC solution is further explained • Paging request for terminating calls are below with the aid of the simplified message delivered to the UE via EPS. flow diagram illustrated in Fig. 3b. In this exam- • 2G/3G is used for paging responses and fur- ple diagram the UE is initially in E-UTRAN and ther call handling as well as for all originat- has an active IMS voice session. The voice ses- ing calls. sion terminates at the remote end, which may be Figure 4a shows the architecture that enables a traditional PSTN phone. CS fallback to the UTRAN/GERAN CS domain. Similar to the SR-VCC for 3GPP system, the Note that although this figure concentrates on VoIP/IMS path is initially established over E- fallback to UTRAN/GERAN, a similar architec- UTRAN. When E-UTRAN detects the need for ture can also be used for fallback to CDMA2000 SR-VCC to 1xRTT handover, it sends a signal- 1xRTT access. Details for both architectures as

IEEE Communications Magazine • February 2009 51

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 52

The architecture MAP 3GPP2 core 1xRTT connects the Mobile MSC HLR A1 Switching Center and the Mobility A1 1xCS 1xRTT IWS Management Entity CS access via the new SGs interface. This inter- S102 User face is based on the equipment Gs interface which (UE) MME S6a HSS connects MSC and S11 IP multimedia Serving GPRS S-GW S5P-GW SGi subsystem (IMS) Support Node and E-UTRAN S1-U was introduced to 3GPP EPC

reuse the concept of Voice path before handover combined mobility Voice path after handover to 1xRTT management between the CS and 1xCS 1xRTT 1xRTT S-GW/ Remote PS domains. UE E-UTRAN MME IWS MSC CS access P-GW IMS end

1. Measurement reports Voice path before handover Handover decision 2. Handover request (start 1x SRVCC)

3. Start SRVCC (MEID, 1xOrigination (VDN)...)

1xRTT traffic allocation 4. Initiate domain transfer 3GPP2 VCC Voice call transfer 5. 1x Handoff CMD 4. Domain transfer successful procedures UE moves to 1xRTT HO detection 6. Release UE context 7. Suspend EPS bearer

Voice path after handover completion

n Figure 3. a) Architecture for single-radio VCC between E-UTRAN and 3GPP2 1x RTT CS; b) simplified message flow diagram for voice session handover from E-UTRAN to 3GPP2 1xRTT CS access.

well as fallback procedures can be found in diagram showing how CS fallback is conducted 3GPP TS 23.272 [10]. in order to facilitate a mobile originating call. In The architecture connects the mobile switch- this example diagram the UE is initially in E- ing center (MSC) and MME via the new SGs UTRAN and has active IP packet connection. interface. This interface is based on the Gs inter- The UE has attached to the MME in EPC and face, which connects the MSC and SGSN, and to an MSC in the 2G/3G CS domain by conduct- was introduced in order to reuse the concept of ing a combined EPS/IMS Attach procedure [5]. combined mobility management between the CS It is assumed also that the target 2G/3G access and PS domains [5]. To combine the mobility supports simultaneous PS and CS services. The management between E-UTRAN and 2G/3G, following procedure takes place when UE and there is need for a mapping mechanism that the network are not configured to use IMS. If maps between E-UTRAN tracking areas and UE is configured to use IMS voice or IMS SMS 2G/3G location areas. When the UE moves to services and is registered to IMS, it shall initiate E-UTRAN, its 2G/3G location area must also be calls via IMS, even if it is attached to the 2G/3G updated so that incoming calls can be correctly CS domain. delivered to the UE. The mapping of tracking/ When UE decides to make a mobile originat- location areas is performed by the MME, and ing call, the UE sends a Service Request mes- the combined mobility management procedures sage with a CS fallback indication to the MME (e.g., combined attached [5]) are reused as much (step 1) so that the MME can initiate the as possible to minimize the impact on the MSC. required handover procedures. If CS fallback is Figure 4b illustrates an example message flow allowed for the UE, the MME sends a message

52 IEEE Communications Magazine • February 2009

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 53

2G/3G 3GPP core

lu-cs MSC enhanced for CSFB UTRAN lu-ps

A or lu-cs GERAN SGSN Gb or lu-ps

S3 SGs D S4 User equipment (UE) S6a MME HSS

S11 Packet data S5 SGi network S-GW P-GW (e.g. Internet)

S1-U E-UTRAN 3GPP EPC

Non-voice path before handover Non-voice after handover to GERAN Voice path after handover to GERAN

UTRAN/ Enhanced S-GW/ UTRAN/ Enhanced S-GW/ UE E-UTRAN MME GERAN SGSN MSC P-GW UE E-UTRAN MME GERAN SGSN MSC P-GW IP-packet path before handover IP-packet path before handover 1a. Service request 1a. Paging 2a. S1-AP message 1b. Paging 2b. Optional measurement report solicitation 2a. Service request 2b. CS page reject 3. Packet-switched handover 3a. S1-AP message UE moves to 2G/3G 3b. Optional measurement report solicitation 4a. SABM (with CM service request) 4b. Complete layer 3 information with 4. Packet switched handover 4c. UA (with CM service request) CM service request) UE moves to 2G/3G 5b. Service reject 5a. Service reject If the 5a. SABM (with paging response) MSC is 5b. Complete layer 3 information (with 5c. Location area update changed 5c. UA (with paging response) paging response) 6. CS call establishment procedure 6b. RRC release 6a. Connection reject If the MSC is Voice path after handover 6c. Location area update and roaming retry changed 7a. Forward relocation complete 7. CS call establishment procedure 7b. Forward relocation complete ack 8a. Update PDP context request Voice path after handover 8b. Update PDP context response 8a. Forward relocation complete 8b. Forward relocation complete ack IP packet path after handover If the 9a. Update PDP context request 9. Routing area update procedure routing area 9b. Update PDP context response is changed IP packet path after handover If the routing 10. Routing area update procedure area is changed

n Figure 4. a) Simplified architecture of 3GPP CS Fallback; b) mobile originating call for CS fallback, UE in active mode; c) mobile ter- minated call for CS fallback, UE in active mode.

(step 2) that instructs the eNB to transfer the which PS resources are first reserved in the tar- UE to a neighboring UTRAN/GERAN cell. get UTRAN/GERAN cell and then a handover Before the eNB does so, it may request some command is sent to the UE to instruct it to radio measurement reports from the UE in move to the target UTRAN/GERAN cell. When order to discover the best target UTRAN/ fallback to UTRAN/GERAN is successful, the GERAN cell (step 2b). In turn, a standard PS UE sends a standard CM Service Request mes- handover procedure is initiated (step 3) in sage to the MSC to request call establishment

IEEE Communications Magazine • February 2009 53

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 54

Access leg IMS was designed to PSTN PSTN PSTN enable intelligent, phone SSP IMS components 2G 2G IP-based services, 2G MGC phone MSC SCC-AS Remote leg and features to be (3PCC) User 3G 3G Circuit CS 3G MGC located in the equipment phone MSC switch phone (UE) evolved 3GPP I/S-CSCF EPS 4G 4G network. One key phone access I/S/P- IMS Possible SIP SIP CSCF phone aspect focused on combo Enterprise client IP-PBX AAA/ of types P-CSCF HSS/ here is the ability to HLR WiMAX SIP WiMAX maintain services client ASN even when the user SIP WiFi WiFi client AP is moving across IMS: IP multimedia subsystem PSTN: Public switched telephone netork different access CSCF: Call session control function CS: Circuit switch SIP: Session initiation protocol SSP: Service switching point networks and MGC: Media gateway controller MSC: Mobile switching center HSS: Home subscriber server PBX: Private branch exchange terminal types. AAA: Authentication, authorization, HLR: Home location register accounting AS: Application server 3PCC: Third party call control SCC: Service centralization and continuity

(a)

UE GERAN MSC with WLAN EPC CSCFs SCC MGCF PSTN/ISDN Remote IMS centralized AS MGW network ISDN WLAN CS services phone STI-1 allocated Signaling path prior to transfer to PS path Voice (and data) path prior to transfer

STI-2 Setup STN-SR INVITE (STN, SDP-MGW/MSC) INVITE allocated to CS path Additional signaling path following transfer Re-INVITE Re-INVITE (remote, SDP-MGW/MSC) PTSN/ISDN leg Voice path following transfer is unchanged

Signaling path: Media path: Packet-based Packet-based Circuit-based TDM Circuit

(b)

n Figure 5. a) IMS service continuity architecture based around the SCC-AS; and b) simplified message flow diagram for voice call transfer with IMS service continuity mechanisms.

(steps 4a–4c). In some cases (see [5] for details), gram, the UE is initially in E-UTRAN and has the CM Service Request may be sent to an MSC an active data connection, and the target access other than the MSC with which the UE was reg- supports simultaneous support of PS and CS ser- istered in E-UTRAN. In this case, the new MSC vices. rejects the originating call request and a loca- When there is an incoming call request, the tion update procedure is performed (steps request is first routed to the MSC/VLR in 5a–5c) followed by another CM Service Request which the UE is registered through combined and the normal voice call establishment proce- CS fallback attach or combined tracking area dures (step 6). update procedures. When the MSC/VLR In parallel with voice call establishment, the receives the incoming call request, it sends a PS handover (initiated in step 3) between SGSN paging message to the MME over the SGs inter- and S-GW/PGW is completed (steps 7a–7b), and face (step 1a). The MME then forwards this the active PS bearers are switched to UTRAN/ paging message to the UE over E-UTRAN GERAN access after the update PSP context access (step 1b). This paging message is an procedure is finished (Steps 8a, 8b). Finally, a NAS message that can securely carry a caller’s typical routing area update can be performed ID. By informing the user of the caller’s ID when the UE detects that it is now in a different prior to fallback, the user can decide whether routing area (step 9). to accept CS fallback to legacy access for voice Figure 4c shows how CS fallback works for calls. This caller ID notification over a paging mobile terminating calls. In this example dia- message is introduced especially for CS fallback

54 IEEE Communications Magazine • February 2009

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 55

to avoid unwanted fallback, especially when a WLAN and GERAN as the source and target user is engaged in fast data services over E- access technologies, respectively, it is equally The SCC AS UTRAN. applicable to any other source and target access terminates the Similar to mobile originated calls, PS hand- technologies. In some cases (e.g., when the over and CS fallback are triggered by sending a underlying transport network cannot support original session Service Request message to the MME (Step voice transfer between two specific access tech- request (say from 2a). If the user rejects incoming call request nologies) the IMS service continuity proce- before fallback, the MME returns a reject mes- dures are the only means to enable such voice UE) and initiates a sage to the MSC (Step 2b). When UE moves to transfer. new session towards 2G/3G, UE sends a paging response to the Figure 5b considers an example where a the Remote ISDN MSC (steps 5a–5c). The paging response can be mobile device (UE) has a multimedia session rejected by the MSC if the UE is sending it to with a fixed device (remote ISDN phone). At phone. By doing so, the wrong MSC, and location area update is the top of the figure, the path followed by sig- the SCC AS appears triggered. Location area update also triggers naling (SIP) messages and the path followed by the originating MSC to redirect the call to the user traffic (voice and data) are shown. Note as a third-party correct MSC by means of an existing roaming that the signaling path needs to go through the between UE and retry procedure (steps 6a–6c). When a paging SCC application sserver (SCC AS) [8], which is Remote ISDN phone, response is successfully returned to the correct the element that effectively enables session MSC, the CS call establishment procedure transfer by using third-party call control (3PCC) which controls the takes place (step 7). PS handover is also com- procedures. In particular, the SCC AS splits the call between them pleted in a similar way, as explained in the pre- session between the UE and the remote ISDN vious section. phone into two parts (or legs): one part between (hence, the term the UE and SCC AS (called the access leg), and third-party call another part between the SCC AS and remote control). IMS-BASED ISDN phone (called the remote leg). This split is OICE ALL ONTINUITY performed when the multimedia session is initi- V C C ated. The SCC AS terminates the original ses- As mentioned before, voice call continuity mech- sion request (say from the UE) and initiates a anisms in the evolved 3GPP system are also pro- new session toward the remote ISDN phone. By vided by the IMS [11]. The IMS is a service doing so, the SCC AS appears as a third party control subsystem in the evolved 3GPP architec- between the UE and remote ISDN phone that ture (Fig. 1) and is based on SIP defined by the controls the call between them (hence the term Internet Engineering Task Force (IETF) in RFC third-party call control). 3261 and many related RFCs. IMS was designed As opposed to other handover mechanisms to enable intelligent IP-based services and fea- (e.g., the SR-VCC discussed previously), in all tures to be located in the evolved 3GPP net- IMS service continuity mechanisms it is the UE work. One key aspect focused on here is the that makes handover decisions based on precon- ability to maintain services even when the user is figured operator policies, user preferences, and moving across different access networks and ter- the availability of neighbor access technologies. minal types. One operator policy could, for example, indicate The IMS specifications (e.g., 3GPP TS 23.228 that GERAN CS has higher preference than [11]) define the functionality of IMS compo- WLAN for voice sessions, so when the UE uses nents, including various types of call session con- WLAN and discovers an available GERAN trol functions (CSCFs) and application servers, access in its vicinity, it will try to transfer its which take advantage of SIP procedures to regis- ongoing voice and other sessions to GERAN ter users with IMS, and originate, terminate, access. transfer, and release multimedia sessions. When the UE makes the handover decision, Because voice is still the key service for service it sends a standard CS Setup message to a spe- providers, the first service continuity solution cial destination number, called a session transfer with IMS was designed to enable voice call con- number (STN), which causes the Setup messages tinuity (VCC) between a conventional access to be translated to a corresponding SIP INVITE network supporting CS voice (e.g., GSM, UMTS, message, and then routed to the SCC AS. Note CDMA2000 1xRTT) and a VoIP access network that the Setup message and the translated (e.g., a WLAN). This was defined in 3GPP TS INVITE message going to the SCC-AS create a 23.206 [6] as part of 3GPP specifications Release third signaling leg (UE-CS to SCC) in addition 7. The second solution, service centralization to the existing access leg (UE-WLAN to SCC) and continuity (SCC), defined in 3GPP TS and remote leg (SCC to remote ISDN phone). 23.237 [8] and 3GPP TS 23.292 [12], expands the After receiving the INVITE message from the VCC solution, and provides enhanced call trans- MSC enhanced with IMS centralized services fer functionality and service centralization in the [12], the SCC-AS generates the re-INVITE to IMS. There is a common architectural theme, as the MGCF, which updates the remote leg at the shown in Fig. 5a. MGW to point to the MSC (with IMS central- Figure 5b shows an example of a mobile ized services) rather than the UE’s WLAN IP user’s voice call being transferred from WLAN address. Therefore, the voice media from the access to GERAN CS domain access using remote leg MGW is redirected to the MSC. The IMS service continuity procedures. One of the path of the voice media component after the ses- benefits of using the IMS to transfer voice calls sion transfer is shown at the bottom of Fig. 5b. is that the same service continuity procedures Note that in this example, if there are other can be used no matter what the source and tar- media components (in addition to voice) active get accesses are. Hence, although Fig. 5b shows between the UE and the remove ISDN phone,

IEEE Communications Magazine • February 2009 55

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.

SALKINTZIS LAYOUT 1/19/09 2:46 PM Page 56

they will either be released after voice is trans- ADDITIONAL READING ferred to GERAN CS domain or continue over Since E-UTRAN [1] A. K. Salkintzis, N. Passas, and D. Skyrianoglou, “On the the WLAN. Of course, the latter case requires coverage will initially Support of Voice Call Continuity Across UMTS and dual-radio capabilities in the UE (i.e., capability Wireless LANs,” Wireless Commun. Mobile Comp. J., be limited compared to operate simultaneously on the WLAN and 2007. to the coverage of GERAN radio access.) BIOGRAPHIES the legacy radio CONCLUSIONS APOSTOLIS K. SALKINTZIS [SM‘04] ([email protected]) technologies, many received his Diploma (honors) and Ph.D. degree from the The next generation of 3GPP systems support a Department of Electrical and Computer Engineering, Dem- different handover new wireless broadband radio access technology ocritus University of Thrace, Xanthi, Greece. In 1999 he was a sessional lecturer at the Department of Electrical and mechanisms have called E-UTRAN, and a vast range of mobility Computer Engineering, University of British Columbia, been standardized mechanisms that facilitate many deployment sce- Canada, and from October 1998 to December 1999 he was narios and support a flexible evolutionary path also a post-doctoral fellow in the same department. During by 3GPP in order to toward 4G mobile systems. Since E-UTRAN 1999 he was also a visiting fellow at the Advanced Systems Institute of British Columbia, Canada. During 2000 he was enable ubiquitous coverage will initially be limited compared to the with the Institute of Space Applications and Remote Sens- coverage of legacy radio technologies (UTRAN, ing (ISARS) of the National Observatory of Athens, Greece. voice call services in GERAN, CDMA2000, etc.), many different Since 1999 he has been with Motorola Inc. working on the many deployment handover mechanisms have been standardized design and standardization of wireless communication net- works, focusing in particular on UMTS, WLANs LTE, WiMAX, scenarios. by 3GPP in order to enable ubiquitous voice call and TETRA. He has many pending and granted patents, has services in many deployment scenarios and sup- published more than 65 papers in referreed journals and port service continuity across a wide range of conferences, and is a co-author and editor of two books in radio environments. In this article we present the areas of Mobile Internet and Mobile Multimedia tech- nologies. He is an editor of IEEE Wireless Communications and explain these handover mechanisms, and and Journal of Advances in Multimedia, and has served as identify the key motivation behind them. It is lead guest editor for a number of special issues of IEEE shown that when voice services are supported Wireless Communications, IEEE Communications Magazine, over E-UTRAN, the so-called SR-VCC mecha- and others. His primary research activities lie in the areas of wireless communications and mobile networking, and nisms [7] can be used to seamlessly hand over particularly on seamless mobility in heterogeneous net- voice calls to legacy radio technologies such as works, IP multimedia over mobile networks, and mobile UTRAN, GERAN, and 1xRTT. On the other network architectures and protocols. He is an active partici- hand, when no voice services are supported over pant and contributor in 3GPP and chair of the Quality of Service Interest Group (QoSIG) of IEEE Multimedia Commu- E-UTRAN, CS fallback mechanisms [10] can be nications Technical Committee. He is also a member of the used to transfer the user to a legacy radio access Technical Chamber of Greece. that supports conventional voice services over the CS domain. Finally, we explain the applica- MIKE HAMMER ([email protected]) received his B.S. degree in electrical engineering from the University of Dayton, tion-layer handover mechanisms supported by Ohio, and his M.B.A. from the Florida Institute of Technol- the IMS, which can facilitate additional voice ogy. He completed electrical engineering graduate course- call continuity scenarios, especially when no ver- work at the U.S. Air Force Institute of Technology, and tical (or intersystem) mobility is supported by received his M.S.E.E. from George Mason University. Cur- rently, he represents Cisco Systems at the WiMAX Forum the network layer [8, 12]. All these handover and ATIS, with a focus on mobility and VoIP architectures, mechanisms allow the next generation of 3GPP and previously SIP-related product development. Prior to systems to support sophisticated voice call conti- that he was a Booz, Allen, and Hamilton consultant help- nuity in all commercial deployments. ing U.S. law enforcement create lawful intercept architec- ture and standards for digital and mobile networks, as well as helping the Department of Defense on Defense Messag- REFERENCES ing System requirements, electronic commerce, and PKI capabilities. Before that, as an U.S. Army officer, he [1] 3GPP TS 36.300 v8.6.0, “Evolved Universal Terrestrial planned missile tests, managed the migration of the Army Radio Access (E-UTRA) and Evolved Universal Terrestrial European Telephone System from analog to digital, Radio Access Network (E-UTRAN); Overall Description; planned the first Internet for U.S. Army Europe, then creat- Stage 2,” Rel. 8, Sept. 2008. ed and taught the first data networking courses for the [2] 3GPP TS 23.002 v8.3.0, “Network Architecture” Rel. 8, U.S. Army Computer Science School. His interest is in con- Sept. 2008. vergence of wireline and wireless technologies and migra- [3] 3GPP TS 23.402 v8.3.0, “3GPP System Architecture Evo- tion of circuit-based networks to packet-based systems. lution: Architecture Enhancements for Non-3GPP Accesses,” Rel. 8, Sept. 2008. ITSUMA TANAKA received a degree (M.Eng.) from Imperial [4] 3GPP TS 23.401 v8.3.0, “General Packet Radio Service (GPRS) College London, United Kingdom. In 2004 he joined NTT Enhancements for Evolved Universal Terrestrial Radio Access DOCOMO, Inc. and has been involved in many mobile ser- Network (E-UTRAN) Access,” Rel. 8, Sept. 2008. vices and architecture design projects. Since 2007 he has [5] 3GPP TS 23.060 v8.2.0, “General Packet Radio Service been an active participant and contributor in 3GPP SA2, (GPRS); Service Description; Stage 2,” Rel. 8, Sept. 2008. focusing in particular on UMTS and SAE. He is a rapporteur [6] 3GPP TS 23.206 v7.6.0, “Voice Call Continuity (VCC) of various 3GPP work items. He is a member of IEICE. between Circuit Switched (CS) and IP Multimedia Sub- system (IMS); Stage 2,” Rel. 7, Mar. 2008. CURT WONG is currently in the role of specialist at Nokia [7] 3GPP TS 23.216 v8.1.0, “Single Radio Voice Call Conti- Siemens Networks, Redmond, Washington. He has been nuity (SRVCC); Stage 2,” Rel. 8, Sept. 2008. with Nokia since 1995 working in several different roles [8] 3GPP TS 23.237 v8.1.0, “IP Multimedia Subsystem (IMS) and technologies. His primary focus has been in the areas Service Continuity; Stage 2,” Rel. 8, Sept. 2008. of wireless technologies and system level developments, [9] 3GPP2 X.S0042-0, “Voice Call Continuity between IMS with emphasis on the infrastructure side of cellular net- and Circuit Switched System.” works. His current activities and involvement are mainly on [10] 3GPP TS 23.272 v8.1.0, “Circuit Switched Fallback in voices services over LTE, including IMS, emergency aspects, Evolved Packet System; Stage 2,” Rel. 8, Sept. 2008. and interworking with legacy 2G and 3G networks. He is [11] 3GPP TS 23.228 v8.6.0, “IP Multimedia Subsystem an active participant in and contributor to 3GPP standards. (IMS); Stage 2,” Rel. 8, Sept. 2008. He has a B.S. in electrical engineering from the University [12] 3GPP TS 23.292 v8.1.0, “IP Multimedia Subsystem of Texas at Austin and an M.S. in telecommunications from (IMS) Centralized Services; Stage 2,” Rel. 8, Sept. 2008. Southern Methodist University, Dallas, Texas.

56 IEEE Communications Magazine • February 2009

Authorized licensed use limited to: National Chung Cheng University. Downloaded on November 29, 2009 at 14:15 from IEEE Xplore. Restrictions apply.