intelligent connection manager for seamless interworking of multi-technology mobile devices

◆ Intelligent Connection Manager for SeamlessInterworking of Multi-Technology Mobile DevicesEdward Grinshpun, David W. Faucher, and Sameer Sharma

As wireless service providers ramp up their Long Term Evolution (LTE)installations, and telecommunications and cable operators continue toexpand Wi-Fi coverage, 100 percent wireless coverage with overlappingareas of 3G, 4G, and Wi-Fi access is becoming a reality. Ensuring that a multi-mode device can roam across different radio access technologies whilemaintaining seamless session and service continuity across virtual privatenetwork (VPN), Voice over Internet Protocol (VoIP), and streaming videoapplications is critical. Differences in 3GPP, 3GPP2, and WiMAX standards ledto the absence of uniform interworking solutions. Specific interworkingstandards per access technology pair define the behavior and interfaces forcommon core network components including the IP anchor, AAA, and HSS, aswell as the IP Multimedia Subsystem (IMS). This paper discusses theIntelligent Wireless Connection Manager (IWCM), a critical component of amobile device platform that enables seamless and transparent inter-technology mobility for user applications through IP session continuity,make-before-break handoff algorithms, and uniform quality of service (QoS)and policy management APIs. © 2011 Alcatel-Lucent.

expand inexpensive Wi-Fi* hotspots and 3G/4G fem-

tocell and picocell alternatives to Wi-Fi. One hundred

percent wireless service coverage with overlapping

areas of different access is becoming a reality.

User equipment (UE) vendors are responding

with a variety of multi-technology 3G, 4G, and Wi-Fi

mobile devices such as laptops/netbooks with built-in

or external USB-based modem cards, smartphones,

and iPADs*. Still, users expect not only to always stay

connected, but also to seamlessly maintain applica-

tion sessions while crossing the invisible boundaries of

different radio access technology (RAT) coverage

IntroductionFourth generation (4G) broadband wireless net-

work installations (e.g., Long Term Evolution [LTE]

and Worldwide Interoperability for Microwave Access

[WiMAX]) are expected to coexist for the duration of

a multi-technology transition period with a vast

embedded network of established high speed third

generation (3G) infrastructures including 3GPP2 High

Rate Packet Data (HRPD) and Evolved High Rate

Packet Data (eHRPD), 3GPP Wideband Code Division

Multiple Access (WCDMA) and Universal Mobile

Telecommunications System (UMTS). Meanwhile,

telecommunications and cable operators continue to

Bell Labs Technical Journal 15(4), 5–22 (2011) © 2011 Alcatel-Lucent. Published by Wiley Periodicals, Inc. Published online in Wiley Online Library (wileyonlinelibrary.com) • DOI: 10.1002/bltj.20469

6 Bell Labs Technical Journal DOI: 10.1002/bltj

areas. While a few applications (most notably e-mail,

web browsers, and certain file download programs)

are designed to maintain session continuity regard-

less of Internet Protocol (IP) address changes, many

applications such as Voice over Internet Protocol

(VoIP), video streaming, and secure virtual private

network (VPN) data sessions require underlying IP

session continuity as a prerequisite for this application

session continuity. In addition, real time applications

like video and VoIP require specific quality of service

(QoS) preservation. For the latter, packet loss, delay,

and general degradation of QoS conditions during

Panel 1. Abbreviations, Acronyms, and Terms

3G—Third generation3GPP—3rd Generation Partnership Project3GPP2—3rd Generation Partnership Project 24G—Fourth generationAAA—Authorization, authentication, and

accountingANDS—Access network discovery and selection ANDSF—ANDS functionAPI—Application programming interfaceCDMA—Code division multiple accessCM—Connection managerCMIP—Client MIPCoA—Care of addressDHCP—Dynamic Host Configuration ProtocolDL—DownlinkDR—Dual radioEAP—Extensible Authentication ProtocolEAP-AKA—EAP for UMTS Authentication and

Key AgreementeHRPD—Evolved high rate packet dataEPC—Evolved packet coreETSI—European Telecommunications Standards

InstituteE-UTRAN—Evolved UMTS terrestrial radio

access networkEV-DO—Evolution data optimizedFMCA—Fixed-Mobile Convergence AllianceGPRS—General packet radio serviceGTP—GPRS Tunneling ProtocolGUI—Graphical user interfaceHA—Home agentHRPD—High rate packet dataHSS—Home subscriber serverIMS—IP Multimedia ServiceIOT—Interoperability testIOTA—Integration of Two Access

(Technologies) Bell Labs ProjectIP—Internet ProtocolIWCM—Intelligent wireless connection

managerL2—Layer 2

L3—Layer 3LMA—Local mobility anchorLTE—Long Term EvolutionMAC—Medium access layerMIH—Media independent handoverMIHF—MIH functionMIP—Mobile IPMN—Mobile nodeNWG—Network Working GroupOS—Operating systemPCC—Policy and charging control PCRF—Policy and charging rules functionPDN-GW—Packet data network gatewayPMIP—Proxy MIPPoA—Point of attachmentQoS—Quality of serviceR8—Release 8RAN—Radio access networkRAT—Radio access technologyRF—Radio frequencySAP—Service access pointSAR—Specific absorption rateSP—Service providerSR—Single radioSSID—Service set identifierTLS—Transport Layer SecurityTTLS—Tunneled Transport Layer SecurityUE—User equipmentUL—UplinkUMTS—Universal Mobile Telecommunications

SystemUSB—Universal serial busVoIP—Voice over Internet ProtocolVPN—Virtual private networkWCDMA—Wideband code division multiple

accessWiMAX—Worldwide Interoperability for

Microwave AccessWISH—Wireless Interworking with Seamless

HandoversWLAN—Wireless local area network

DOI: 10.1002/bltj Bell Labs Technical Journal 7

inter-technology handover may lead to noticeable

quality degradation in the application session, at times

comparable to session loss. 3GPP standards specify a

requirement of sub-300 millisecond bearer traffic

interruption on LTE-eHRPD inter-technology hand-

over [14]. Seamless VoIP and high resolution video

may require bearer traffic interruptions of less than 50

milliseconds.

The problem of multi-technology interworking

with seamless handovers is challenging; there is no

generic solution that suits all combinations of wireless

access. Wireless standards (3GPP, 3GPP2, WiMAX) use

different network architectures, different authentica-

tion and authorization procedures and protocols, dif-

ferent IP mobility paradigms, different access network

discovery and selection methods, and different flavors

of quality of service flow establishment. Attempts to

define generic and universal mechanisms for inter-

working of wireless access technologies, such as media

independent handover (MIH) IEEE 802.21, are cur-

rently not embraced by the 3GPP, 3GPP2, and WiMAX

standards bodies. See also a different approach in [21].

4G standards have defined specific per access tech-

nologies pairs interworking architectures and proce-

dures to support inter-technology hand-offs with IP

session continuity [3, 19, 22, 24]. Consensus is grow-

ing that 3GPP Release 8 evolved packet core [2],

defined in [3] as the common architecture for LTE

interworking with other non-3GPP and 3GPP tech-

nologies, provides the path to commonality [3, 21,

22, 25].

Interworking architectures differ for single radio

(SR) and dual radio (DR) UEs. So called tightly cou-

pled interworking architecture with optimized inter-

technology handovers applies to both SR and DR

devices, and defines dedicated signaling and bearer

plane tunneling functions between the correspond-

ing radio access networks (RANs) of different access

technologies. Such specialized coupling allows for bet-

ter network side control over QoS bearer traffic char-

acteristics during inter-technology handovers,

conceptually somewhat similar to intra-technology

tunneling procedures. However, besides the associ-

ated network side complexity, SR interworking

imposes significant additional requirements on the

UEs in the handover preparation phase, to tunnel

medium access control (MAC) messages of the target

RAT while connected over the source RAT. This

requirement presents significant challenges for the UE

vendors, delaying the appearance of SR devices on

the market. In addition, many UE devices include

built-in Wi-Fi radio, resulting in the necessity of the

DR approach for interworking with 3G/4G.

This paper focuses on seamless interworking for

DR and multi-radio devices as a practical near-term

matter. For DR devices, the 3GPP, 3GPP2, and WiMAX

standards define loosely coupled interworking archi-

tecture with functional elements and procedures for

the network side support of IP session continuity on

inter-technology handovers [3, 10, 11, 14, 23–26].

However, in order to achieve a seamless user experi-

ence during inter-technology handovers, in addition

to the specified standards, some key specialized seam-

less inter-technology handover functions and algo-

rithms have to be implemented in the UE. The UE

operating systems (OS) currently on the market (e.g.,

laptop/netbook Windows*, Mac*, Android*, iPhone*,

Windows Mobile*, and embedded OSs used in hand-

sets or multi-technology USB dongles) do not have

native support for such functions.

We present a portable intelligent wireless con-

nection manager (IWCM) component add-on to the

UE mobile device platform, providing a critical miss-

ing component of uniform seamlessness for all applica-

tions. IWCM also serves as an application enablement

foundation, with technology-neutral application pro-

gramming interfaces (APIs) to wireless modem devices,

and an API mechanism to enforce a variety of service

provider (SP) interworking policies.

These research results are a product of multi-year

collaboration between the Bell Labs Wireless

Interworking with Seamless Handoffs (WISH) team

and Alcatel-Lucent product units on 4G, 3G, and Wi-

Fi interworking. Initial results received by the Bell

Labs (IOTA) project for 3G/Wi-Fi interworking were

published in [17, 18]; also see [16]. WISH IWCM

addresses specifics for seamless interworking in 4G

(LTE, WiMAX) access technologies, fully realizes a mix

of client-based and network-based mobility schemes,

and emphasizes the importance of access technology

neutral 802.21 media independent handover (MIH)-

like device adapter APIs and policy/QoS APIs.


We begin by discussing generic concepts of loosely

coupled interworking architecture for multi-radio

devices. We then focus on the UE role and functions

in the enablement of seamless handovers and present

details on the IWCM reference architecture, applica-

tions, and associated access technology neutral device

adapter APIs.

Interworking With Seamless Handovers for4G/3G/Wi-Fi Multi-Radio Devices: Basic LooselyCoupled Architecture

4G (LTE and WiMAX) interworking with 3G tech-

nologies and Wi-Fi has been extensively addressed by

the standards [3–6, 10, 11, 15, 23, 25, 26]. Figure 1illustrates the main components of a standards-

defined, loosely coupled interworking architecture

for multi-radio UE. Note that the so-called non-

optimized LTE-eHRPD interworking architecture might

utilize some components of tightly coupled inter-

working added to the basic loosely coupled premise,

e.g., measurements of target RAN available at the

source RAN [3, 9, 14].

Different access technology RANs are not aware

of each other; all intelligence of inter-technology han-

dovers is concentrated in the common core network

components and in the UE device.

The common core network components include

the IP mobility anchor, authentication and autho-

rization, the policy and charging control (PCC) func-

tion for enabling QoS-based IP services (e.g., IP

Multimedia Services [IMS]), and optional access net-

work discovery and selection function (ANDSF) for

assisting UE in discovering available networks.

Subsequent sections of this paper describe the

specialized intelligent connection manager function

in the UE device, a Bell Labs technology providing

Authentication/authorization

PCC

Commoncore

servicesApplicationIP services(e.g., IMS)

Radio accessnetwork

Technology A

Radio accessnetwork

Technology B

IPtransportnetwork

Wi-Fi accesswithout mobility

infrastructure

IP mobilityanchor

RAT A specificmobility tunneling

RAT B specificmobility tunneling

Multi-radioUE with ICM

Overlay CMIPtunnel between

UE and IPmobility anchor

ANDSFserver

3G, 4G or Wi-Fi†

with mobilityinfrastructure

3G—Third generation4G—Fourth generationANDSF—Access network discovery and selection functionCMIP—Client Mobile IPICM—Intelligent connection manager

IMS—IP Multimedia ServiceIP—Internet ProtocolPCC—Policy and charging controlRAT—Radio access technologyUE—User equipment

†Registered trademark of the Wi-Fi Alliance.

Figure 1.Components of loosely coupled interworking architecture for multi-radio UE.


the capability to perform make-before-break inter-

technology handover procedures in compliance with

a variety of technology-specific mobility standards,

which achieves seamlessness by minimizing inter-

technology handover latency, packet loss, delay, jitter,

reordering and QoS degradation.

In the remainder of this section we detail the

aforementioned common core network components,

together with access network discovery and selection

function and IEEE 802.21 considerations.

Common IP Mobility Anchor Function and IP SessionContinuity

4G (LTE, WiMAX) and 3G wireless standards

define RAT-specific IP mobility anchors for intra-

technology mobility. For each RAT, the corresponding

IP mobility anchor presents the registered UE device

as directly attached to the outside world, and main-

tains technology-specific mobility signaling and bearer

traffic tunneling to/from the serving RAN with the

current IP point of attachment (PoA) for the UE. As the

UE moves, its IP PoA may move as well (macro han-

dover). In conjunction with the handover, technology-

specific mobility re-registration of the new IP PoA

with the IP mobility anchor causes the latter to switch

the bearer tunnel to the new PoA. This allows the UE

to maintain IP session continuity with the same IP

address reachable via the IP mobility anchor.

Make-before-break inter-technology handover—

standard practice for multi-radio UE— refers to a pro-

cedure in which the UE continues an IP data session

over the old RAT while performing network entry

and over-the-air flow set up, and initiating IP con-

nectivity registration with the common IP mobility

anchor over the new RAT. We provide more details on

this procedure in the sections on common PCC and

seamless interworking algorithms below.

Interworking standards generally define the com-

mon IP mobility anchor function as a union of each

technology-specific IP mobility anchor. 3GPP, 3GPP2,

and WiMAX specifications devised significant differ-

ences in the choice of IP mobility anchors, mobility

modes (client-based versus network-based), and

mobility signaling protocols and tunneling mecha-

nisms. Examples are as follows:

• 3GPP2 [12] and WiMAX [24] define Mobile IP

(MIP)-based tunneling with MIP home agent

(HA) function as an IP mobility anchor (with

RAT-specific differences in MIP extensions and

authentication mechanism). 3GPP2 HRPD ini-

tially defined client-based mobility with the client

MIP (CMIP) function in the UE [12], and later

added network-based mobility with the proxy

MIP (PMIP) client function in the RAN [7].

WiMAX [24] allows CMIP, but existing deploy-

ments use PMIP; 3GPP2 eHRPD uses PMIP [8, 9].

• 3GPP general packet radio service (GPRS)-based

standards (including LTE and UMTS) define

network-based mobility with GPRS Tunneling

Protocol (GTP) or PMIP [2], with current deploy-

ments predominantly using GTP. Starting with

Release 8, 3GPP defines LTE-to-non-3GPP-based

interworking with the packet data network gate-

way (PDN-GW) as a common IP mobility anchor,

implementing local mobility anchor (LMA) MIP

HA functions to support CMIPv4 and PMIPv6-

based mobility anchoring from 3GPP2, WiMAX,

and wireless local area network (WLAN) Wi-Fi

access. This architecture allows for hybrid tun-

neling methods with the common IP anchor at

the PDN-GW: GTP over LTE or other 3GPP (e.g.,

UMTS) access (network based mobility), CMIP

over 3GPP2 HRPD, or optionally WLAN Wi-Fi:

PMIPv6 over 3GPP2 eHRPD and over WiMAX.

• Many Wi-Fi RAN installations do not have inher-

ent mobility agents. An upcoming standard [26]

defines new Wi-Fi RAN components with PMIP

network-based mobility and associated security

procedures for interworking with WiMAX. The

3GPP defines security, authentication, and autho-

rization procedures for Wi-Fi/3GPP interworking

in [4] and [6]. With mobility infrastructure pre-

sent in the Wi-Fi access network, network-based

mobility procedures apply. In the absence of

the mobility infrastructure in the Wi-Fi access

network (e.g., at a hotspot or coffee shop), a mul-

timode UE may use a CMIP overlay tunnel over

Wi-Fi access, as depicted in Figure 1, using CMIP

with a collocated care of address (CoA). Here, the

UE first obtains the local care of address and then


registers this care of address with the common

HA/LMA function to establish a MIP tunnel and

to obtain a home IP address for session mobility.

Security association procedures for the MIP ses-

sion are outlined in [3].

A multi-mode UE has to be aware of the mobility

mode (e.g., client-based with CMIP versus network-

based with GTP, PMIP, or other tunneling methods in

the network) supported by the access network for the

specific RAT, since the corresponding IP connectivity

establishment procedures differ significantly. With

network-based mobility, UE establishes IP connectiv-

ity as a non-mobile host on network entry, and the

network maintains IP session continuity on IP PoA

change. With client-based mobility, the UE explicitly

manages mobility by performing CMIP registration

with an IP mobility anchor on network entry; UE has

the responsibility to perform MIP session re-registration

any time the PoA changes. Inter-technology han-

dovers between RATs with heterogeneous mobility

modes (i.e., client-based and network-based mobi-

lity) require special functionality from the DR UE.

Common Authentication and Authorization FunctionThe common authentication and authorization

function allows the network to authenticate a multi-

mode UE device/user, and authorize IP sessions and

IP-based services via any available RAT.

3GPP, WiMAX, and 3GPP2 devised different

authentication/authorization procedures, methods, and

protocols requiring special reconciliatory interworking

standards for the corresponding access technology

pairs. 3GPP Release 8 introduced an evolved packet

core all-IP architecture with a 3GPP home subscriber

server (HSS) as a common home authentication/

authorization function, and a 3GPP AAA server as an

interworking conduit for other access technologies

utilizing AAA [2, 3]. WiMAX and 3GPP2 utilize tech-

nology-specific AAA servers for authorization,

authentication, and accounting (AAA), with inter-

working architecture defining common home AAA

with dual-mode access technology-specific interfaces

to the corresponding RANs and HA/LMA [11, 23].

Wi-Fi access also utilizes AAA [6]. Among technol-

ogy standards utilizing AAA, there are also differences

in Extensible Authentication Protocol (EAP) methods

used for authentication and keys distribution. WiMAX

defined EAP-Transport Layer Security (TLS) as

mandatory with EAP-Tunneled Transport Layer Security

(TTLS), and EAP for 3rd Generation Authentication and

Key Agreement (EAP-AKA) as optional. Meanwhile,

3GPP2 eHRPD uses EAP-AKA, which is different from

other Code Division Multiple Access (CDMA) technolo-

gies like 3G1x and HRPD/evolution data optimized

(EV-DO).

Multi-mode UE may need to maintain a consis-

tent technology-specific set of user/session creden-

tials for session continuity on inter-technology

handovers, and may need to transfer or map creden-

tials used for initial network entry via RAT A during

inter-technology handover to RAT B. Session re-

authentication on inter-technology handover using the

transferred credentials is performed via technology-

specific authentication/authorization methods.

Common PCCStarting with Release 8, 3GPP defined common

PCC architecture accepted by other wireless standards

[1]. This architecture defines the common policy and

charging rules function (PCRF) in the common core

network, which provides further access to common

IP-based application services, e.g., IMS. It allows sup-

porting dynamic RAT-specific over-the-air QoS flows

for IP-based applications, including VoIP, real time

video streaming, and real time gaming.

Preventing application session QoS degradation

during inter-technology handovers is challenging for a

number of reasons. Per technology pair mapping of

RAT-specific QoS flow profiles/templates is required;

for some RAT pairs it is already defined [14], for others

it might be non-trivial, especially when interworking

with Wi-Fi WLAN access. Different over-the-air flow

setup procedures are defined and implemented by vari-

ous standards. 3GPP2 HRPD deployments use predom-

inantly UE device-initiated QoS flow setups, though

network-initiated QoS is allowed [13]. The WiMAX

Forum Network Working Group (NWG) 1.5 has both

UE-initiated and network-initiated QoS flow setup, but

pre-NWG1.5 standard WiMAX deployments use only

a network-initiated QoS flow setup. 3GPP evolved

UMTS terrestrial radio access network (E-UTRAN)

allows both UE-initiated and network-initiated QoS


flow setup, with network-initiated QoS being preferred

and prioritized in deployments.

As a result, make-before-break procedures spe-

cific to each interworking technology pair are required

for seamless inter-technology handovers with QoS.

Common PCC needs to be access technology aware.

With homogeneous network-initiated QoS to network-

initiated QoS inter-technology handover, make-

before-break procedures for QoS flow establishment

over the target RAT are controlled by the PCRF, with

the UE device playing a passive role. With homoge-

neous UE-initiated QoS to UE-initiated QoS inter-

technology handover, make-before-break procedures

for QoS flow establishment over the target RAT are

controlled by the UE establishing QoS flows over the

target RAT prior to IP mobility switch, with PCRF

playing an authorization role. Heterogeneous inter-

technology handover procedures—those between

network-initiated QoS and UE-initiated QoS—are

more challenging. Here, make-before-break proce-

dures of setting QoS flows over the target RAT prior to

the IP mobility tunnel switch, and tearing down QoS

flows over the source RAT, need to be properly cor-

related between PCRF and UE.

802.21 ConsiderationsMedia independent handover is an IEEE 802.21

standards-based solution that defines access technology-

agnostic interworking procedures. The IEEE 802.21

working group, initially chaired by Ajay Rajkumar

from Bell Labs, began work in 2004, resulting in a

standard being approved in January 2009.

The goal of MIH is to facilitate handovers between

heterogeneous access networks through the definition

of a core set of services and components that would

exist within both UE and throughout the network.

MIH partitioned the services into three general cate-

gories: command, event, and information. Additionally,

MIH defines a protocol for communication between

MIH-capable nodes (e.g., mobile node [MN] to net-

work, or network to network) that allows for coordi-

nated efforts before, during, and after a handover.

An MIH-capable node contains an MIH function

(MIHF) that provides one or more of the core services

to the upper layers (MIH users), and expects a mini-

mum set of functions from the lower (link) layers.

As shown in Figure 2, MIH users gain access to MIH

services through an MIH service access point

(MIH_SAP), whereas MIHF gains access to lower layer

MIH users

MIH_SAP

MIH function (MIHF)(command, event and information services)

Remote(MIHF)

RAT 1

MIH_LINK_SAP

RAT 2

MIH_LINK_SAP

RAT 3

MIH_LINK_SAP

…RAT 4

MIH_LINK_SAP

MIH

_NET

_SA

P

MIH

_NET

_SA

P

UENetwork

MIH—Media independent handoverMIHF—MIH functionRAT—Radio access technology

SAP—Service access pointUE—User equipment

Figure 2.Media independent handover.


functions via an MIH link service access point

(MIH_LINK_SAP). When communicating with peer

MIHFs, it uses the MIH network service access point

(MIH_NET_SAP), which provides both layer 2 (L2) and

layer 3 (L3) transport. It is through the combination

of all of these service access points (SAPs) that MIH is

able to provide the three distinct services: command,

event, and information. (See [20] for further details).

The distributed nature of MIH requires a signifi-

cant initial investment in order to begin receiving

some of the benefits it provides. Now that MIH (or

more accurately IEEE 802.21) is an actual standard,

we should start seeing more effort in this area. In fact,

Bell Labs’ IEEE 802.21 MIH server recently completed

successful interoperability tests (IOTs) at a Fixed-

Mobile Convergence Alliance (FMCA) interoperabil-

ity event hosted and managed by the European

Telecommunications Standards Institute (ETSI).

The current 3GPP, 3GPP2, and WiMAX standards

do not include network side MIH components; UE

usage of MIH components is considered a vendor-

specific device implementation, outside the standards

scope. The WISH intelligent wireless connection

manager (IWCM) utilizes a set of MIH-like access

technology-neutral APIs, similar to a subset of MIH

command and event services related to control and

monitoring of state, behavior and presence of the

device, link, and network. See the IWCM section

below for details.

Access Network Discovery and Selection Function The process of active RAT re-selection at the UE

involves discovering available networks for each RAT,

evaluation of the potential handover candidates (by

taking into account operator policies, user preferences,

and signal conditions), and the inter-technology han-

dover trigger if the conditions are right.

Starting with Release 8, 3GPP defined the access

network discovery and selection function [3] in the

network to provide UE with the available access net-

work information and associated service provider poli-

cies. UE can obtain the IP address of the ANDSF as

part of host IP information on initial network entry.

Intelligent Wireless Connection ManagerThis section describes the IWCM, a portable mid-

dleware technology from the Bell Labs WISH project,

which provides a critical, seamless interworking add-on

component for a multi-radio mobile device platform.

When integrated with a UE device’s network pro-

tocol stack, the IWCM provides standards-compliant

(3GPP, 3GPP2, WiMAX, Wi-Fi) and service provider

policy-based functionality that enables seamless and

transparent session and service continuity on inter-

technology handovers to IP-based VoIP, video, and

data applications.

We introduce this section by describing the UE-

side procedures for seamless inter-technology han-

dover. Next, we present an overview of the IWCM

reference architecture, followed by a more detailed

description of its components.

The WISH IWCM prototype, available at Bell

Labs, is used for a variety of customer demonstrations,

trade shows, and ongoing research work.

Multi-Radio UE Procedures During Seamless Inter-Technology Handover

Networking standards outline the basics of multi-

radio UE behavior to support inter-technology handovers

with IP session continuity. In order to satisfy inter-

working requirements and service provider policies

for different access technologies, UE needs to support

a variety of mobility modes to maintain IP session

continuity on inter-RAT handovers. In addition, truly

seamless handover requires special functions and

operation procedures at the UE device to minimize

or eliminate packet data stream impairment, e.g.,

minimize handover latency, packet loss and reorder-

ing, and QoS degradation. This section highlights such

UE procedures for loosely coupled interworking archi-

tecture. Note that a tightly coupled architecture model

further increases the network role in seamless inter-

working, allowing implementation of some of the

described procedures (e.g., intelligent buffering) in

the network instead of in the UE.

Figure 3 illustrates inter-technology handoff pro-

cedures for dual radio UE.

• Step 1. At start time, access network discovery and

selection (ANDS) using pre-configured policies/

preferences together with dynamic signal quality

measurements yield selection of RAT A for initial

network entry.

• Steps 2–5. Outline procedures for network entry

with RAT A from the UE perspective.


• Step 6. As the UE moves across different access

coverage areas, the best access technology is being

re-evaluated. The ANDS algorithm in the UE

takes into account dynamic signal quality analy-

sis, together with analysis dynamically received

from the ANDSF server or preconfigured service

provider policies and user preferences. Special

considerations apply to handovers with QoS. As a

result, RAT re-selection occurs and B is chosen.

• Step 7. Authentication/authorization session cre-

dentials are transferred or mapped from the RAT

A device adapter to the RAT B device adapter for

network entry over the new access mode.

• Step 8. While the application session continues

over the active RAT A connection, a simultaneous

make-before-break over-the-air connection is

established over RAT B, using the credentials of

step 7. If RAT B supports it, the mobility mode

with a supported IP version and supported IP con-

nectivity establishment method is also negotiated

with RAN B. Alternatively, this information might

be received as part of the policies from the ANDSF

server over RAT A in step 6, or it may be statically

preconfigured.

• Step 9. IP mobility mode is selected for RAT B,

based upon information dynamically received in

step 6 and step 8, RAT B service provider policies

or preconfigured RAT B IP operation specifics.

• Step 10. Intelligent buffering starts for uplink (UL)

and downlink (DL) bearer traffic in conjunction

with make-before-break IP registration with the

common IP mobility anchor over the RAT B in

step 11. This is intended to minimize packet loss,

delay, jitter and reordering on data path switch.

• Step 11. Make-before-break IP connectivity estab-

lishment procedure is performed over RAT B,

ANDS—Access network discovery and selection algorithmANDSF—Access network discovery and selection functionCAN—Converged access networkIP—Internet ProtocolIWCM—Intelligent wireless connection manager

Commonauthentication/authorization

CommonIP mobility

anchor

CommonPCC

RANtechnology A

Dual radioUE withIWCM

1. Initial ANDS => RAT A

2. Establish over-the-air connection over RAT A. Authenticate.

3. Select IP mobilitymode for RAT A

4. Establish IP session and QoS flows over RAN A. Bidirectional bearer tunnel between RAN A and IP anchor.

11. Make-before-break. Establish IP session, and IP CAN QoS flows over RAN B. Bearer session switched to RAT B.

6. ANDS –reselection =>switch to RAT B

Get network information and possibly policy for IP mobilitymode for RAN B and additional credentials.

7. Transfer credentials

8. Make-before-break. Establish over-the-air connection over RAT B. Authenticate.

10. Start of bearer planebuffering + handover withQoS algorithm procedures

9. IP mobility mode forRAT B selected

12. Completion of bearerplane buffering

13. Uplink and downlink bearer traffic over RAT B, technology specific tunneling with IP anchor

RANtechnology B

ANDSFserver

5. Uplink and downlink bearer traffic over RAT A, technology specific tunneling with IP anchor.

PCC—Policy control and chargingQoS—Quality of serviceRAN—Radio access networkRAT—Radio access technologyUE—User equipment

Figure 3.Seamless inter-technology handover procedures for dual radio UE.


based upon the selections in step 9. IP level user/

session credentials from step 7 are used to authen-

ticate and authorize inter-technology IP session

transfer. The common IP mobility anchor, upon

receiving the binding registration (sent by the UE

over RAT B for client-based mobility, or by RAN B

for network-based mobility) re-affirms the same

IP address for the session and switches the data

path tunnel from the RAN A to the RAN B.

• Step 12. UE completes IP connectivity establish-

ment and buffering procedures started in step 10.

Bearer path under the virtual interface is switched

to RAT B.

• Step 13. IP and application sessions continue over

RAT B.

Seamless user experience on inter-technology

handover is created by a combination of make-before-

break handover, efficient network discovery and

selection, and buffering procedures in step 6 through

step 12.

IWCM Reference Architecture and FunctionalDescription

The IWCM function controls all UE aspects of RAT

selection and inter-technology handovers described

above. The IWCM behavior is controlled predomi-

nantly by service provider policies (dynamic or stati-

cally configured at the UE), with the addition of a

limited number of user preferences as allowed by ser-

vice provider policy. In this section, we present the

IWCM reference architecture followed by a more

detailed description of its significant components.

The reference architecture for WISH IWCM is

shown in Figure 4. It consists of two parts: a bearer

Applications

Connection manager

Protocol mobilityengine

Device adapter abstraction layer

WiMAXAuth

Bearer (data) plane

Policy/QoS agent

Policy clientGUI (optional)

Devices

LTE CDMA Wi-Fi† …

WiMAXLTE CDMA Wi-Fi …

Auth Auth Auth

Policy enforcement engine

Virtual adapter

TCP/IP stack

Control plane

User Kernel

Vendor/deviceproprietary APIs

Technology-neutral API

(e.g., 802.21)

QoS API

Buffering algorithmsTunneling *Standardization is highly

desirable

LTE—Long Term EvolutionQoS—Quality of serviceTCP—Transmission Control ProtocolWiMAX—Worldwide Interoperability for Microwave AccessWISH—Wireless Interworking with Seamless Handovers

Auth—AuthorizationAPI—Application program interfaceCDMA—Code division multiple accessGUI—Graphical user interfaceIP—Internet Protocol

†Registered trademark of the Wi-Fi Alliance.

Figure 4.Reference architecture for the WISH intelligent wireless connection manager.


(data) plane and a control plane. The top and bot-

tom halves of Figure 4 represent user and kernel

space, respectively. The IWCM bearer (data) plane is

implemented as a kernel driver; while its architec-

ture and algorithms are portable, the implementa-

tion is typically OS-specific and highly optimized for

performance. The IWCM control plane is imple-

mented as an application in the user space, and as

such, both its architecture and implementation are

highly portable.

Following is a brief functional description of

major components:

• Connection manager (CM) module. Controls access

link and connection state machines, network dis-

covery and selection, and network entry; man-

ages session continuity and handovers with

make-before-break procedures, and user and ses-

sion credentials transfer; controls policy enforce-

ment and real time policy related measurements

(e.g., signal quality); controls user plane and

seamless handover algorithms. The CM module

interfaces with the device adapters layer via

802.21-like technology neutral APIs, and receives

policy updates from external policy client appli-

cation via the policy/QoS agent abstraction layer.

• Protocol mobility engine. Implements a variety of

standards-defined RAT-specific IP level proce-

dures, including different mobility modes (client-

based and network-based) and associated IP

connectivity establishment methods.

• Policy/QoS agent. Implements an abstraction layer

for the policy agent API interfacing with the pol-

icy clients (e.g., ANDSF client or other service

provider policy client), and an abstraction layer

for application of the QoS API.

• Device adapter. Exposes technology-neutral

802.21-like APIs in the abstraction layer by hiding

vendor-specific device adapter driver APIs and

providing an example of the required plug-and-

play modem device support for seamless inter-

technology handovers.

• Bearer (data) plane. Manages a collection of physical

interfaces through a single virtual interface pre-

sented to the OS IP stack, directs bearer traffic to

and from the currently active device, implements a

policy enforcement engine controlled by the CM,

provides tunneling for client-based mobility with

collocated CoA, and implements UL and DL

buffering algorithms realization on handovers.

Additionally, it allows the protocol mobility engine

to bypass the OS IP stack, and send/receive MIP

and Dynamic Host Configuration Protocol (DHCP)

signaling messages over the new RAT, while con-

tinuing to direct application bearer traffic over the

old RAT, e.g., during make-before-break handovers.

• Graphical user interface (GUI). (Optional) graphical

user interface for configuring, monitoring, and/or

controlling the operation of the ICWM.

The IWCM design is flexible, extensible, and

highly configurable, allowing for the easy addition of

new access technologies with the ability to mix and

match devices, mobility protocols, and algorithms. The

list of technologies currently supported by the proto-

type WISH IWCM includes LTE, WiMAX, CDMA2000

(EV-DO/HRPD/eHRPD), WCDMA, and Wi-Fi.

In the following subsections, we detail the most

significant IWCM functions.

Policy control. The term policy refers to a broad set of

parameters controlling IWCM behavior. Such policies

are predominantly defined by service providers, and

can be classified into the broad categories of static (pre-

configured at the UE) or dynamic. As a matter of service

provider policy, some limited number of user prefer-

ences may also be allowed. The list of policy parameters

includes, but is not limited to, the following:

• Policies to configure only a subset of RAT adapters

to be controlled by IWCM under the virtual

adapter, resulting in a multi-homed UE interface

configuration, with seamless inter-technology

handoffs only between the subset of the inter-

faces grouped under the virtual adapter.

• Access network discovery and (re-) selection related

policies, including information available from the

ANDSF server, preconfigured network selection

preferences, handover trigger inputs (signal quality

range thresholds), and scanning parameters.

• Mobility mode and options to be used by the spe-

cific RAT (client based mobility with CMIP or net-

work based mobility) and IP version (IPv4, IPv6,

or dual stack IPv4v6).

• Optional (service provider allowed) user preferences

(e.g., manual handover with user intervention


versus automatic handover, interface priorities, and

profile of home Wi-Fi access point).

• Optional authentication credentials.

• Power and battery life management control poli-

cies impacting multiple radio operations.

• Overall control of radio frequency (RF) emissions

and transmit power for multiple radios.

• Technology-specific service level limitations, e.g.,

aggregated data limits for 3G access.

External policy client applications (e.g., ANDSF

client or other custom policy applications) can use

the policy agent API to communicate policies to the

IWCM. The policies can be statically preconfigured or

dynamically received from the network (specifics of

how the policy client obtains such policies are out-

side of the scope of this paper).

IWCM provides a policy enforcement function for

both the bearer and control plane, thus enabling ser-

vice providers to control multi-radio UE behavior.

Note that as a matter of policy, SPs may allow a user

to control certain predetermined sets of preferences

(e.g., a choice of manual versus automatic network

selection, or giving highest priority to home Wi-Fi or

other predefined Wi-Fi service set identifiers [SSIDs]

when in range).

CM and protocol mobility engine. Protocol mobility

engine operations are controlled by the CM, which

applies the relevant policies and provides credentials.

The mobility engine provides support for standards-

defined RAT-specific mobility modes (both client and

network based) with associated IPv4/IPv6 or dual

stack connectivity establishment methods.

An integrated MIP client function (client-based

mobility) supports a variety of MIP extensions specific

for WiMAX and 3GPP2 EV-DO/HRPD; for MIP version 4

(MIPv4), it also supports both foreign agent-based CoA

(as per WiMAX and 3GPP2) and collocated CoA (typi-

cal for Wi-Fi interworking) configurations. An inte-

grated DHCP client supports additional DHCP options

(e.g., carrying user identity or requesting an ANDSF

server IP address) necessary for interworking with net-

work-based mobility, as well as the acquisition of local

IP addresses for CMIP with collocated CoA.

CM also controls policy enforcement functions and

buffering algorithms in the user plane, in conjunction

with the make-before-break inter-technology han-

dover procedures.

Seamless interworking algorithms. A seamless

inter-technology handover experience is achieved via

a combination of several algorithms implemented in

the UE as listed below. Specific details of the algo-

rithms’ realization are outside the scope of this paper.

All algorithms are implemented in the CM, except for

intelligent buffering, which is implemented in the

bearer (data) plane and controlled by the CM.

• Enhanced network discovery and selection. The goals

of this algorithm include maintaining active RAT

with a signal quality within the policy-defined

boundaries; timely selection of a new RAT to mini-

mize the possibility of the currently active RAT

signal deteriorating below an acceptable level and

impacting the quality of application sessions;

avoiding a ping-pong effect of frequent back-and-

forth handovers between RATs at RAT coverage

boundaries; and enforcing both static and

dynamic SP policies. This algorithm makes use of

signal quality monitoring via an interface with

device adapters, in conjunction with associated

power and battery life policy.

• Make-before-break with dual radio. Assuming suffi-

cient access coverage areas overlap between the

new and the currently active RATs, a timely hand-

over trigger to the new RAT allows performing in

a make-before-break fashion network entry and

the establishment of IP connectivity over the new

RAT (using the second radio), while maintaining

a quality application session over the old RAT (via

the active radio). The IP mobility anchor switches

the data path tunnel from the old RAN to the new

RAN after processing the mobility binding regis-

tration message from the new RAN (e.g., the cor-

responding GTP message for LTE, or the

PMIP/CMIP message for non-3GPP technologies).

This reduces the possibility of a potential traffic

interruption gap up to the order of a mobility reg-

istration roundtrip delay between the UE and the

mobility anchor. Further improvements are pos-

sible using bicasting methods during handover

(e.g., MIP-defined simultaneous bindings with DL

bicasting) and by applying intelligent handover


buffering algorithms, controlled and timed by the

CM in juxtaposition with the make-before-break

procedures.

• Intelligent buffering during handover. When the UE

performs a make-before-break network entry and

the mobility anchor switches the data path tun-

nels from the old RAN to the new RAN, transient

UL packets over the old RAN can be lost, and

transient DL packets over the old RAN can arrive

out of order, especially on handover from 3G to

LTE, where the new leg is faster. Proper buffering

schemes in the UL and DL directions allow such

packet loss and reordering to be addressed.

Specialized per flow buffering may be necessary

for handovers with QoS. Additional DL data

stream synchronization algorithms may be

needed in the case of DL bicasting.

• Handover with QoS. The technology-neutral QoS

API exposed by the policy/QoS agent module pro-

vides an opportunity for higher layer applications

to request the creation/deletion of certain QoS

flows for those devices and RATs that support UE-

initiated QoS flow setup. One of the benefits of

providing this QoS API is that higher layer appli-

cations do not need to be concerned about the

specifics of how QoS flows are established for

each of the different access technologies. It has a

single, consistent view of how to request QoS-

specific flows. The CM, along with the device

adapter APIs, provide the necessary translation of

QoS parameters in order to create/delete a specific

QoS flow. The capability of the RAT to support

UE-initiated QoS flow setup is communicated as

a policy to the CM. As discussed above, support of

handovers with QoS between heterogeneous

access networks, where one of the networks has

a UE-initiated QoS flow setup and another has a

network-initiated QoS flow setup, requires coop-

eration between the PCC function and the UE (in

addition to a common PCC function in the net-

work). In the WISH IWCM architecture, such

cooperation is a function of the CM and device

adapter, using the device adapter API to retrieve

the currently configured QoS flows and to establish

specific QoS flows. For example, when handing

over from an access technology that supports

network-initiated QoS flow setup to an access

technology that supports a client-initiated QoS

flow setup, CM can (in a make-before-break fash-

ion) retrieve the current settings from the source

access technology device adapter, map the

retrieved QoS flow profile to the target access

technology, and then establish (as part of the

make-before-break handover procedure) the cor-

responding QoS flow on the target access tech-

nology.

• Power and battery life management. The power and

battery life management algorithm parameters

are provided to CM as a policy. The algorithm

allows battery usage to be minimized through a

variety of techniques, such as powering-up a sec-

ond radio only if the signal quality of the active

RAT radio degrades, or if location-based informa-

tion received from the ANDSF server indicates

the availability of the second RAT, controlling the

frequency of scans on the second radio.

• Controlling RF emissions and resolving specific absorp-

tion rate (SAR) issues for multi-radio UEs. When DR

UE has both radios on and it is located at a cell

boundary with poor signal quality for both RATs,

both radios begin transmitting at maximum power,

resulting in combined RF emissions exceeding

the limits specified by Federal Communications

Commission (FCC) regulations. The algorithm to

address this issue utilizes CM, minimizing instances

when both radios are turned on and controlling

the combined transmit power.

Device adapter APIs. The WISH IWCM defines a

set of technology-neutral IEEE 802.21 MIH-like APIs

between the CM and the device adapters, which are

used as a technology-independent abstraction layer

for controlling and monitoring the modem devices,

specifically in the context of seamless inter-technology

handovers. In turn, the device adapters layer trans-

lates the technology-independent APIs into access

technology-specific device adapter/driver APIs.

Currently, 3G/4G modem device vendors implement

proprietary vendor and technology device adapter/

driver APIs, resulting in the need for development

work in order to integrate each individual device with

API Description

(Synchronous command/responses)

Open/close API library API for opening and closing device control library.

Get/set device configuration Configures device and network related dynamic or static parameters,including network name, operator, packet data protocol context,operating modes or user profiles/credentials. Retrieves administrativestatus of the configured parameters.

Get device/link status Retrieves extended operational status for the device and link, e.g.,mode (idle/active), connection state, signal strength indicators, speed,and current configuration related to the connected network.

Get/set QoS Retrieves information on currently active QoS service flows (regardlessof whether network-initiated or UE-initiated QoS flow setup is usedby the RAT. Set up QoS flow when the RAT allows for UE-initiated QoSflow setup.

Scan for available networks Returns the list of available networks, together with thecorresponding NAP and NSP information, and signal strengthindicators.

Airlink up/down Set up or tear down of over the air connectivity with the selectedradio access network.

Get/set power mode API for power and battery management, e.g., putting the device intoor taking it out of power saving/idle/sleep mode, powering the deviceon or off, or setting Tx power levels.

Subscription This provides the capability to get/set dynamic session authenticationcredentials.

(Asynchronous notifications)

Mode change Provides a notification that a device experienced a mode change, e.g., transitioned to an idle, sleep, or active state.

Link up/down Provides a notification that an over the air connection was eitherestablished or torn down.

Link detected Provides a notification that a new network has been detected. Forexample, this may occur due to a change in position (i.e., a previouslyout-of-range access network is now detected) or perhaps by a changein signal conditions.

Link parameters report Provides a notification that handover-related thresholds have beencrossed. The thresholds for each of the corresponding parametersmust have been previously configured.

Intra-technology handoff Provides a notification of when an intra-technology handover beginsand/or ends. This information may be useful for delaying the decisionto perform an inter-technology handover as conditions may changesignificantly.

Scan complete Provides a notification that a previously initiated scan of availablenetworks has completed.

QoS setup complete Provides a notification that a previously initiated QoS set up hascompleted.

Airlink up/down complete Provides a notification that a previously initiated over the airconnection establishment or tear down procedure has completed.

Table I. Device adapter APIs.

API—Application programming interfaceNAP—Network access providerNSP—Network service providerQoS—Quality of service

RAT—Radio access technologyTx—TransmitterUE—User equipment


any type of connection manager. Standardization of

the device adapter APIs is required for true plug-and-

play functionality. Certain standardization activities

have been started by working groups in different stan-

dards bodies (e.g., WiMAX Forum Service Provider

Working Group), however the effort is still far from

complete.

Table I presents the set of device APIs identified

by the WISH IWCM specifically for multi-technology

interworking with seamless handoffs, including both

the synchronous command/response access and asyn-

chronous notifications. The former is used for config-

uration, monitoring, and control operations, whereas

the latter provides a performance-efficient mechanism

for monitoring real time events. Note that in the

absence of asynchronous notifications, implementa-

tions may choose the less performance-efficient

polling model.

ConclusionsIn this paper, we presented a new intelligent wire-

less connection manager (IWCM) functional compo-

nent add-on to the mobile device platform for

multi-radio UE devices. We discussed basic concepts of

the 3G/4G/Wi-Fi loosely coupled interworking archi-

tecture for multi-radio devices (single radio devices

are not expected in the near term), and demonstrated

that interworking with seamless handovers requires

new capabilities not present in current UEs. The addi-

tion of IWCM to the UE platform provides such capa-

bilities. We also presented a reference architecture

and high level functional description of the Bell Labs

WISH IWCM, optimized for seamless interworking

with 4G access technologies, e.g., LTE.

AcknowledgementsThe authors thank Peretz Feder for many fruitful

discussions and for his contribution to problem for-

mulations. The authors also wish to thank Scott

Miller, Milind Buddhikot, and Girish Chandranmenon

for making IOTA documentation and software avail-

able to the WISH project.

*TrademarksAndroid is a trademark of Google Inc.iPad, iPhone, and Mac are registered trademarks of Apple

Inc.

Wi-Fi is a registered trademark of the Wi-Fi Alliance.Windows and Windows Mobile are registered trade-

marks of Microsoft Corporation.

References[1] 3rd Generation Partnership Project, “Technical

Specification Group Services and SystemAspects, Policy and Charging ControlArchitecture,” 3GPP TS 23.203, Dec. 2009,�http://www.3gpp.org/ftp/Specs/html-info/23203.htm�.

[2] 3rd Generation Partnership Project, “TechnicalSpecification Group Services and SystemAspects, General Packet Radio Service (GPRS)Enhancements for Evolved Universal TerrestrialRadio Access Network (E-UTRAN) Access,”3GPP TS 23.401, Dec. 2009, �http://www.3gpp.org/ftp/Specs/html-info/23401.htm�.

[3] 3rd Generation Partnership Project, “TechnicalSpecification Group Services and SystemAspects, Architecture Enhancements for Non-3GPP Accesses,” 3GPP TS 23.402, Dec. 2009,�http://www.3gpp.org/ftp/Specs/html-info/23402.htm�.

[4] 3rd Generation Partnership Project, “TechnicalSpecification Group Core Network andTerminals, 3GPP System to Wireless Local AreaNetwork (WLAN) Interworking, WLAN UserEquipment (WLAN UE) to Network Protocols,Stage 3 (Release 9),” 3GPP TS 24.234, v9.0.0,Dec. 2009, �http://www.3gpp.org/ftp/Specs/html-info/24234.htm�.

[5] 3rd Generation Partnership Project, “TechnicalSpecification Group Core Network andTerminals, 3GPP Evolved Packet System,Optimized Handover Procedures and ProtocolsBetween E-UTRAN Access and cdma2000HRPD Access—Stage 3,” 3GPP TS 29.276, Dec.2009, �http://www.3gpp.org/ftp/Specs/html-info/29276.htm�.

[6] 3rd Generation Partnership Project, “TechnicalSpecification Group Service and SystemAspects, 3G Security, Wireless Local AreaNetwork (WLAN) Interworking Security(Release 9),” 3GPP TS 33.234, Oct. 2009,�http://www.3gpp.org/ftp/Specs/html-info/33234.htm�.

[7] 3rd Generation Partnership Project 2, “NetworkPMIP Support,” 3GPP2 X.S0054-220-A, v1.0, Aug. 2008, �http://www.3gpp2.org/Public _html/specs/tsgx.cfm�.

[8] 3rd Generation Partnership Project 2, “NetworkPMIP Support,” 3GPP2 X.S0061-0, v1.0, Dec. 5,


2008, �http://www.3gpp2.org/Public_html/specs/tsgx.cfm�.

[9] 3rd Generation Partnership Project 2,“Interoperability Specification (IOS) forEvolved High Rate Packet Data (eHRPD) RadioAccess Network Interfaces and Interworkingwith Enhanced Universal Terrestrial RadioAccess Network (E-UTRAN),” 3GPP2 A.S0022-0, v1.0, Mar. 2009, �http://www.3gpp2.org/Public_html/specs/tsga.cfm�.

[10] 3rd Generation Partnership Project 2,“HRPD/1XRTT and 3GPP E-UTRAN (LTE)Interworking and Inter-Technology Handoff:Stage 1 Requirements,” 3GPP2 S.R0129-A,v1.0, Apr. 2, 2009, �http://www.3gpp2.org/Public_html/specs/tsgs.cfm�.

[11] 3rd Generation Partnership Project 2,“Interoperability Specification (IOS) for HighRate Packet Data (HRPD) Radio AccessNetwork Interfaces and Interworking withWorld Interoperability for Microwave Access(WiMAX),” 3GPP2 A.S0023-0, v1.0, Apr. 2009,�http://www.3gpp2.org/Public_html/specs/tsga.cfm�.

[12] 3rd Generation Partnership Project 2,“cdma2000 Wireless IP Network Standard:Chapter 2—Simple IP and Mobile IP AccessServices,” 3GPP2 X.S0011-002-E, v1.0, Nov.2009, �http://www.3gpp2.org/Public_html/specs/tsgx.cfm�.

[13] 3rd Generation Partnership Project 2,“cdma2000 Wireless IP Network Standard:Chapter 4—Quality of Service and HeaderReduction,” 3GPP2 X.S0011-004-E, v1.0, Nov.2009, �http://www.3gpp2.org/Public_html/specs/tsgx.cfm�.

[14] 3rd Generation Partnership Project 2, “E-UTRAN—eHRPD Connectivity andInterworking: Core Network Aspects,” 3PGG2X.S0057-0, v2.0, Dec. 2009, �http://www.3gpp2.org/Public_html/specs/tsgx.cfm�.

[15] 3rd Generation Partnership Project 2, “WiMAX-HRPD Interworking: Core Network Aspects,”3GPP2 X.S0058-0, v2.0, June 2010,�http://www.3gpp2.org/Public_html/specs/tsgx.cfm�.

[16] D. Benenati, P. M. Feder, N. Y. Lee, S. Martin-Leon, and R. Shapira, “A Seamless Mobile VPNData Solution for CDMA2000, UMTS, andWLAN Users,” Bell Labs Tech. J., 7:2 (2002),143–165.

[17] M. Buddhikot, G. Chandranmenon, S. Han, Y.-W. Lee, S. Miller, and L. Salgarelli, “Design

and Implementation of a WLAN/CDMA2000Interworking Architecture,” IEEE Comm. Mag.,41:11 (2003), 90–100.

[18] M. Buddhikot, G. Chandranmenon, S. Han, Y.W. Lee, S. Miller, and L. Salgarelli, “Integrationof 802.11 and Third-Generation Wireless DataNetworks,” Proc. 22nd IEEE Internat. Conf. onComput. Commun. (INFOCOM ‘03) (SanFrancisco, CA, 2003), vol. 1, pp. 503–512.

[19] P. Feder, R. Isukapalli, and S. Mizikovsky,“WiMAX-EVDO Interworking Using Mobile IP,”IEEE Commun. Mag., 47:6 (2009), 122–131.

[20] Institute of Electrical and Electronics Engineers,“IEEE Standard for Local and MetropolitanArea Networks—Part 21: Media IndependentHandover Services,” IEEE 802.21-2008, Jan.21, 2009.

[21] R. Sigle, O. Blume, L. Ewe, and W. Wajda,“Multi-Radio Infrastructure for 4G,” Bell LabsTech. J., 13:4 (2009), 257–276.

[22] P. Taaghol, P. Feder, and R. Isukapalli, “MobileWiMAX Integration with 3GPP and 3GPP2Networks,” WiMAX Technology and NetworkEvolution (K. Etemad and M.-Y. Lai, eds.),John Wiley & Sons, Hoboken, NJ, 2010,Chapter 11.

[23] WiMAX Forum, Network Working Group,“WiMAX Forum Network Architecture—WiMAX—3GPP2 Interworking,” WMF-T37-004, May 2009.

[24] WiMAX Forum, Network Working Group,“Network Architecture—Release 1.5—Stage 3:Detailed Protocols and Procedures,” T33Protocol Specification, Sept. 2009.

[25] WiMAX Forum, Network Working Group,“WiMAX—3GPP EPS Interworking,” Draft T37-009-R016-v01, Oct. 2009.

[26] WiMAX Forum, Network Working Group,“WiMAX and WiFi Interworking,” WMF-T37-010-R016-v01, Sept. 2010.

(Manuscript approved September 2010)

EDWARD GRINSHPUN is team leader for the Alcatel-Lucent Bell Labs Wireless Internetworkingwith Seamless Handovers (WISH) project,which focuses on new methods,architecture, and algorithms to create andfurther enhance a seamless user experience

for handovers between 3G, 4G, and Wi-Fi wirelessaccess technologies. He is based in Murray Hill, NewJersey. Prior to joining Alcatel-Lucent, he helduniversity research positions in Israel and Canada.


Since joining Alcatel-Lucent almost 15 years ago, Dr. Grinshpun has worked as a technical team lead indevelopment and systems engineering for broadbandwireline and wireless products in the areas ofembedded systems efficiency, multi-service platforminfrastructure, high availability middleware, callprocessing, IP routing and multiprotocol labelswitching (MPLS), triple play content delivery, 4Gwireless networks architecture, and IP mobility andinterworking. He received the Bell Labs President’saward as a member of the WiMAX Technologies andInnovations project team, has authored over 20publications, and has served as an invited speaker at anumber of international conferences. He holds a Ph.D.in mathematical physics from Almaty University,Kazakhstan.

DAVID W. FAUCHER is a researcher in the Alcatel-Lucent Bell Labs Radio Access ResearchDepartment in Murray Hill, New Jersey. Hehas worked in a number of areas includingdigital transmission systems, securetelephones, IP security, and mobile and data

networking. He is currently working on wireless inter-technology with seamless handovers. Mr. Faucher has aB.S. in computer science from the University ofMassachusetts at Amherst, and an M.S. in computerengineering from the University of Lowell, Lowell,Massachusetts.

SAMEER SHARMA is research and development directorfor 4G wireless and LTE at Alcatel-LucentBell Labs in Murray Hill, New Jersey. Prior tojoining Alcatel-Lucent, he worked in variousmultinational, regional, and nationalcorporations in Singapore and India. He

received a B.E. in electronics engineering fromVisvesvaraya National Institute of Technology (VNIT),Nagpur, India, and an M.Tech. in computer science fromthe Indian Institute of Technology, Chennai. He has led and managed diverse global cross-functional projectsand teams developing complex new products andtechnologies, and has received numerous awards and recognitions during his academic life andprofessional career. He is a member of the Alcatel-Lucent Technical Academy, and a recipient of the BellLabs President’s Award for leading the WiMAXTechnologies and Innovations project. ◆

intelligent connection manager for seamless interworking of multi-technology mobile devices

Documents