WO2007106604A2

WO2007106604A2 - Seamless handoff between access networks with saved session information

Info

Publication number: WO2007106604A2
Application number: PCT/US2007/060187
Authority: WO
Inventors: Ajith T. Payyappilly; Rajeev S. Kurundkar; Sriram Nagesh Nookala; Vipin A. Sali
Original assignee: Qualcomm Incorporated
Priority date: 2006-01-05
Filing date: 2007-01-05
Publication date: 2007-09-20
Also published as: ATE547912T1; EP2011362A2; CN101496431A; KR101008408B1; US8218530B2; ES2382826T3; KR20080091202A; JP2009522952A; JP4801173B2; EP2011362B1; US20070155376A1; CN101496431B; WO2007106604A3

Abstract

More seamless handoff between access networks is achieved by saving session information for each access network upon being handed off from the access network and invoking the saved session information upon being handed back to the access network. An access terminal establishes a first session with a first access network, which may entail performing QoS negotiation with the first access network and setting up packet filters at a packet data gateway. The access terminal exchanges data with the first access network in accordance with the configuration of the first session. The access terminal saves the first session configuration after being handed off to a second access network, establishes a second session with the second access network, and exchanges data with the second access network in accordance with the configuration of the second session. The access terminal uses the saved first session configuration upon being handed back to the first access network.

Description

SEAMLESS HANDOFF BETWEEN ACCESS NETWORKS WITH SAVED SESSION INFORMATION

BACKGROUND

[0001] The present Application for Patent claims priority to Provisional Application No. 60/756,962 entitled "METHOD TO MAKE HANDOFFS BETWEEN MPA AND EMPA EVDO NETWORKS SEAMLESS" filed January 5, 2006, and assigned to the assignee hereof and hereby expressly incorporated by reference herein.

I. Field

[0002] The present disclosure relates generally to communication, and more specifically to techniques for performing handoff between wireless communication networks.

II. Background

[0003] Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, and so on. These wireless networks may be multiple-access networks (or simply, access networks) capable of supporting multiple users by sharing the available resources. Examples of such access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, and Orthogonal Frequency Division Multiple Access (OFDMA) networks. [0004] A user may utilize an access terminal (e.g., a cellular phone) to obtain various communication services. Each service may be satisfactorily provided to the user by ensuring that a specified quality of service (QoS) is achieved for that service. QoS may be quantified by different parameters for different services. For example, a voice service may require a relatively stringent delay and a certain minimum guaranteed data rate whereas a packet data service may require a certain target packet error rate. [0005] An access terminal may perform negotiation with a first access network to obtain the desired QoS for a service. The access terminal may thereafter move into the coverage of a second access network and may be handed off from the first access network to the second access network. The access terminal may need to perform negotiation with the second access network to obtain the desired QoS for the service. In general, the access terminal may perform QoS negotiation for each access network to which the access terminal is handed off. The QoS negotiation with each access network typically requires exchanges of signaling messages between the access terminal and the access network, which consumes valuable radio resources. The QoS negotiation also disrupts service, which may be undesirable for the user.

[0006] There is therefore a need in the art for techniques to more efficiently perform handoff between access networks.

SUMMARY

[0007] Techniques for performing handoff between access networks more seamlessly are described herein. The techniques achieve seamless handoff by (1) saving session information for each access network upon being handed off from the access network and (2) invoking the saved session information upon being handed back to the access network.

[0008] In an embodiment, an access terminal establishes a first session with a first access network, which may be an access network supporting Multi-flow Packet Application (MPA) in CDMA2000 IxEV-DO, an access network supporting Enhanced Multi-flow Packet Application (EMPA) in CDMA2000 IxEV-DO, or some other access network. The session establishment may entail performing QoS negotiation with the first access network and setting up packet filters at a packet data gateway for the first access network. The configuration of the first session may comprise the QoS negotiated with the first access network, flow information, information used to create the packet filters, and so on. The access terminal then exchanges data with the first access network in accordance with the configuration of the first session.

[0009] The access terminal saves the first session configuration after being handed off from the first access network to a second access network. The access terminal establishes a second session with the second access network and exchanges data with the second access network in accordance with the configuration of the second session. The access terminal uses the saved first session configuration upon being handed back to the first access network. This allows the access terminal to avoid performing QoS negotiation again with the first access network and setting up new packet filters at the packet data gateway. The access terminal then exchanges data with the first access network in accordance with the first session configuration.

[0010] Various aspects and embodiments of the invention are described in further detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The features and nature of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference characters identify correspondingly throughout.

[0012] FIG. 1 shows an access terminal communicating with multiple access networks.

[0013] FIGS. 2A, 2B and 2C show exemplary protocol stacks.

[0014] FIG. 3 shows a data processing module at the access terminal.

[0015] FIG. 4 shows a call flow for a scenario in which the access terminal is repeatedly handed off between two access networks.

[0016] FIG. 5 shows a call flow with less signaling using saved session configurations.

[0017] FIG. 6 shows a process performed by the access terminal.

[0018] FIG. 7 shows a process performed by an access network.

[0019] FIG. 8 shows a block diagram of the access terminal.

DETAILED DESCRIPTION

[0020] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs.

[0021] The techniques described herein may be used for various wireless wide area networks (WWANs) such as CDMA, TDMA, FDMA, and OFDMA networks. A CDMA network may implement one or more radio technologies such as CDMA2000, Wideband-CDMA (W-CDMA), and so on. CDMA2000 covers IS-2000, IS-856, and IS-95 standards. The CDMA2000 family of standards is described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2). IS-2000 Releases 0 and A are commonly referred to as CDMA2000 IX (or simply, IX), IS-2000 Release C is commonly referred to as CDMA2000 IxEV-DV (or simply, IxEV-DV), and IS-856 is commonly referred to as CDMA2000 IxEV-DO (or simply, IxEV-DO). A TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM). W-CDMA and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). The techniques described herein may also be used for wireless local area networks (WLANs) such as IEEE 802.11 networks. These various radio technologies and standards are known in the art. For clarity, the techniques are specifically described below for IxEV-DO access networks.

[0022] FIG. 1 shows a deployment 100 in which an access terminal (AT) 110 is capable of communicating with multiple access networks (ANs) 120a and 120b. Access terminal 110 may be a cellular phone, a personal digital assistant (PDA), a wireless device, a modem card, a handheld device, or some other wireless communication unit or device. Access terminal 110 may also be referred to as a mobile station (MS), a user equipment (UE), a user terminal, and so on. Access terminal 110 may also be able to communicate with other access networks such as a CDMA Ix network, a GSM network, a Universal Mobile Telecommunications System (UMTS) network that utilizes W-CDMA, an IEEE 802.11 network, and so on.

[0023] Each access network 120 may include various network entities described by 3GPP2, such as base stations and Packet Control Functions (PCFs). In general, each access network 120 may include any number of base stations 130 and any number of PCFs 140. For simplicity, only one base station 130 and one PCF 140 are shown for each access network 120 in FIG. 1. Access terminal 110 may communicate with an base station 130 in an access network 120 via an air- link connection. For packet data service, base station 130 communicates with PCF 140, which further communicates with a Packet Data Serving Node (PDSN) 150. PCF 140 controls the transmission of packets between base station 130 and PDSN 150.

[0024] PDSN 150 supports packet data service for access terminals in access networks 120a and 120b. For example, PDSN 150 may be responsible for the establishment, maintenance, and termination of Point-to-Point Protocol (PPP) sessions for the access terminals. PDSN 150 may also assign dynamic Internet Protocol (IP) addresses to the access terminals. PDSN 150 may couple to the Internet and/or other data networks (e.g., a data network 160) and may communicate with other entities (e.g., a remote host 170) that couple to these data networks. [0025] Access network 120a implements IxEV-DO and supports Multi-flow Packet Application (MPA), which is a set of protocols that allows for setup of multiple flows to carry data between an access terminal and an access network. MPA includes a Radio Link Protocol (RLP) that provides retransmission and duplicate detection, a Data Over Signaling Protocol that provides transmission and duplicate detection of higher layer data packets using signaling messages, a Location Update Protocol that defines location update procedures and messages in support of mobility management for MPA, and a Flow Control Protocol that provides flow control for MPA. IxEV-DO and MPA are described in 3GPP2 C.S0024-A, entitled "cdma2000 High Rate Packet Data Air Interface Specification," Version 2.0, July 2005, which is publicly available. [0026] Access network 120b implements IxEV-DO and supports Enhanced MPA (EMPA), which is an enhanced set of protocols that allows for exchange of multiple flows to carry data between an access terminal and an access network. EMPA is described in 3GPP2 C.S0063-0, entitled "cdma2000® High Rate Packet Data Supplemental Services," January 2005, which is publicly available. [0027] FIG. 2A shows an exemplary protocol stack 200 at access terminal 110. Protocol stack 200 is supported by both MPA and EMPA and includes an application layer, a transport layer, a network layer, a link layer, and a physical layer. Applications (APP) at access terminal 110 may exchange data with applications at remote host 170 using a data protocol stack composed of the transport layer and the network layer. The transport layer may utilize Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and/or some other protocol. The network layer typically utilizes IP. Transport layer data (e.g., for TCP and/or UDP) is encapsulated in IP packets, which are exchanged between access terminal 110 and remote host 170 via access network 120a or 120b and PDSN 150. The link layer between access terminal 110 and access network 120a or 120b is implemented with PPP over RLP. Access terminal 110 maintains a PPP session with PDSN 150 for a data session and communicates with access network 120a or 120b via RLP for data exchanges. RLP operates on top of an air-link interface, e.g., IxEV-DO.

[0028] FIG. 2A also shows data flow in the transmit direction. Any number of applications may be active, and each active application may exchange one or more IP flows in each direction. The IP flows may also be referred to as QoS flows, traffic flows, data flows, and so on. Each IP flow may carry a specific type of data, e.g., audio, video, or control. Data for the IP flows is encapsulated by TCP and/or UDP (either TCP or UDP for each IP flow), then encapsulated by IP and further multiplexed into one PPP flow to be sent to PDSN 150. The PPP flow may be demultiplexed into one or more RLP flows, which may be processed by RLP and Medium Access Control (MAC) and then sent to access network 120a or 120b. For protocol stack 200, one or more IP flows may be mapped to a single PPP flow, which may then be mapped to one or more RLP flows.

[0029] FIG. 2B shows another exemplary protocol stack 210 supported by EMPA. For protocol stack 210, applications at access terminal 110 may exchange data using a data protocol stack that may be implemented with TCP and/or UDP over IP. For protocol stack 210, IP operates directly over RLP, and PPP is removed. Each active application may send one or more IP flows. The data for the IP flows is encapsulated by TCP and/or UDP, then encapsulated by IP, and further mapped to one or more RLP flows. The RLP flows are processed by RLP and MAC and then sent to access network 120b. For protocol stack 210, any number of IP flows may be mapped to any number of RLP flows.

[0030] FIG. 2C shows yet another exemplary protocol stack 220 supported by EMPA. For protocol stack 220, applications at access terminal 110 may exchange data using a data protocol stack that may be implemented with TCP and/or UDP over IP. For protocol stack 220, IP operates over Robust Header Compression (ROHC) protocol, which in turn operates over RLP. Each active application may send one or more IP flows. The data for the IP flows is encapsulated by TCP and/or UDP, encapsulated by IP, processed by ROHC, and further mapped to one or more RLP flows. The RLP flows are processed by RLP and MAC and then sent to access network 120b. For protocol stack 220, any number of IP flows may be mapped to any number of RLP flows.

[0031] Access terminal 110 may exchange one or more IP flows via access network 120a or 120b at any given moment. The QoS for each IP flow may be defined using QoS parameters supported by the access network. Different levels of QoS may be specified for different IP flows to achieve the desired performance. [0032] Each IP flow may also be defined by (and associated with) one or more packet filters. Each packet filter may be formed by one or more filter parameters/ components for one or more fields of an IP header and/or one or more fields of a higher layer header (e.g., a TCP or UDP header). A data packet matches a packet filter if the applicable fields of that data packet conform to the filter parameters of that packet filter. In the transmit direction, outbound data packets from higher layer applications may be filtered with one set of packet filters to segregate these data packets into appropriate IP flows, which may thereafter be sent at the specified QoS to a serving access network. In the receive direction, inbound data packets from the serving access network may be filtered with another set of packet filters to segregate the inbound data packets into appropriate IP flows, which may thereafter be routed to the proper destination at access terminal 110. Access terminal 110 may form a traffic filter template (TFT) that includes packet filters to be used by PDSN 150 for IP flows for access terminal 110. The TFT may be sent to and installed at PDSN 150 to filter traffic data for access terminal 110.

[0033] FIG. 3 shows an embodiment of access terminal 110. Higher layer applications 310 execute over a data processing module 320, which may be implemented with software, firmware, hardware, or a combination thereof. For example, module 320 may be part of system software for access terminal 110. In the embodiment shown in FIG. 3, module 320 includes a data protocol stack 322, a QoS module 330, and an IP filter module 340. Data protocol stack 322 may implement any combination of protocols for any number of layers, e.g., UDP and/or TCP over IP. [0034] QoS module 330 performs various functions to support QoS. QoS module 330 may provide an interface via which higher layer applications 310 can specify QoS for IP flows using pertinent QoS parameters. QoS module 330 may perform conversion between the QoS parameters specified by applications 310 and QoS parameters supported by the access networks. QoS module 330 may also negotiate QoS with the access networks.

[0035] IP filter module 340 performs various functions to support packet filtering. IP filter module 340 may specify packet filters to be applied at access terminal 110 such that (1) IP flows are mapped to the proper RLP flows in the transmit direction and (2) RLP flows are mapped to the proper IP flows in the receive direction. IP filter module 340 may also specify packet filters to be applied at PDSN 150 on outbound packets to be sent to access terminal 110 and inbound packets received from access terminal 110. IP filter module 340 may generate, modify, and send a TFT via access network 120a or 120b to PDSN 150. The TFT contains packet filters to be applied at PDSN 150. [0036] FIG. 4 shows an exemplary call flow 400 for a scenario in which access terminal 110 is repeatedly handed off between access networks 120a and 120b. In the example shown in FIG. 4, access network 120a is the initial serving access network for access terminal 110. For simplicity, the signaling between access terminal 110 and access network 120a for session negotiation and terminal authentication as well as the signaling between access terminal 110 and PDSN 150 for PPP negotiation and user authentication are not shown in FIG. 4.

[0037] At access terminal 110, higher layer applications (APP) 310 may start a QoS application, which is an application having QoS requirements (step 410). The QoS application may be for voice, video, packet data, messaging, and so on and may utilize one or more IP flows for each of the forward and reverse links. Applications 310 send to data processing module 320 a QoS request with pertinent QoS parameters for the IP flows (step 411). Module 320 performs over-the-air (OTA) negotiation with access network 120a for the desired QoS (step 412). The QoS negotiation allows access network 120a to allocate and grant resources, if available, to access terminal 110 to achieve the desired QoS. In general, QoS may be negotiated for each IP flow. Module 320 also determines packet filters to be applied at access terminal 110 as well as packet filters to be applied at PDSN 150 for the QoS application. Module 320 then exchanges signaling with PDSN 150 to set up a TFT at PDSN 150 for the QoS application (step 413). After setting up the TFT, module 320 provides to applications 310 an indication that QoS has been granted (step 414). Thereafter, the QoS application may send and receive data over the established IP flows at the desired QoS levels via access network 120a and PDSN 150 (step 415).

[0038] Access terminal 110 may be roaming and/or may be located between the coverage areas of access networks 120a and 120b. Access terminal 110 may move out of the coverage of access network 120a and into the coverage of access network 120b. Upon detecting loss of coverage with access network 120a, module 320 may provide to applications 310 an indication of the established IP flows and QoS for access network 120a being lost (step 416). Access terminal 110 may then perform a handoff procedure to be handed off from access network 120a to access network 120b (step 420). [0039] Upon receiving the lost of QoS indication from module 320, applications 310 may again send a QoS request with pertinent QoS parameters for the QoS application (step 421). Module 320 may then perform over-the-air negotiation with access network 120b for the desired QoS (step 422), determine packet filters for the QoS application, and exchange signaling via access network 120b to delete the old TFT and set up a new TFT at PDSN 150 for the QoS application (step 423). Module 320 may then provide to applications 310 an indication that QoS has been granted (step 424). Thereafter, the QoS application may send and receive data over the established IP flows at the desired QoS levels via access network 120b and PDSN 150 (step 425). [0040] Access terminal 110 may thereafter move back into the coverage of access network 120a. Upon detecting loss of coverage with access network 120b, module 320 may provide to applications 310 an indication of the established IP flows and QoS for access network 120b being lost (step 426). Access terminal 110 may then perform a handoff procedure to be handed off from access network 120b to access network 120a (step 430). Applications 310 may again send a QoS request with pertinent QoS parameters for the QoS application (step 431). Module 320 may then perform over-the- air negotiation with access network 120a for the desired QoS (step 432), determine packet filters for the QoS application, and exchange signaling via access network 120a to delete the old TFT and set up a new TFT at PDSN 150 for the QoS application (step 433). Module 320 may then provide to applications 310 an indication that QoS has been granted (step 434). Thereafter, the QoS application may send and receive data via access network 120a and PDSN 150 (step 435).

[0041] Access terminal 110 may thereafter move back into the coverage of access network 120b. Access terminal 110 may then perform steps 436 through 445 in the same manner as steps 416 through 425, respectively, to establish QoS with access network 120b and to set up a new TFT with PDSN 150 so that data may be exchanged between access terminal 110 and PDSN 150 via access network 120b. [0042] As shown in FIG. 4, access terminal 110 may exchange signaling with an access network 120 to negotiate QoS and may also exchange signaling with PDSN 150 to set up a TFT whenever access terminal 110 is handed off to the access network. The signaling exchanges may be needed since IxEV-DO standard does not support seamless handoff between MPA and EMPA. The signaling exchanges are undesirable for several reasons. First, valuable radio resources are consumed to exchange the signaling over the air. Second, the QoS application may need to specify QoS each time a handoff is made to a new serving access network. [0043] In an aspect, seamless handoff between access networks is achieved by (1) saving session information/configuration for each access network upon being handed off from the access network and (2) invoking the saved session information/ configuration upon being handed back to the access network.

[0044] FIG. 5 shows an exemplary call flow 500 for a scenario in which access terminal 110 is repeatedly handed off between access networks 120a and 120b. For call flow 500, higher layer applications 310 may start a QoS application (step 510). Applications 310 may send a QoS request with pertinent QoS parameters for IP flows (step 511). Module 320 may then perform over-the-air negotiation with access network 120a for the desired QoS (step 512), determine packet filters for the QoS application, and exchange signaling via access network 120a to set up a TFT at PDSN 150 for the QoS application (step 513). Module 320 may then provide an indication that QoS has been granted (step 514). Thereafter, the QoS application may send and receive data via access network 120a and PDSN 150 (step 515).

[0045] In an embodiment, access terminal 110 (e.g., module 320) stores session information/configuration for access network 120a. The session information may comprise the QoS parameters negotiated with access network 120a, reservation labels used for IP flows exchanged with access network 120a, binding of IP flows to RLP flows, binding of Reverse Traffic Channel-Medium Access Control (RTC-MAC) to RLP, and/or other binding for access network 120a, other state information, and so on. Reservation labels are identifiers for IP flows. In an embodiment, access network 120a also stores session information for access terminal 110. The session information stored by access network 120a may include QoS information, binding information, and/or other state information. The session information stored by access network 120a may be the same as or different from the session information stored by access terminal 110. The session information stored at both entities 110 and 120a may be used later to facilitate seamless handoff.

[0046] Access terminal 110 may move out of the coverage of access network 120a and into the coverage of access network 120b. Upon detecting loss of coverage with access network 120a, module 320 may provide to applications 310 an indication of the established IP flows and QoS being suspended (step 516). Applications 310 receive the indication and do not need to take any action. [0047] Access terminal 110 may then perform a handoff procedure to be handed off from access network 120a to access network 120b (step 520). Module 320 may then perform over-the-air negotiation with access network 120b for the desired QoS (step522). Since the desired QoS is stored by module 320, the QoS application does not need to send another QoS request. In an embodiment, the reservation labels used for IP flows exchanged with access network 120a are also used for IP flows to be exchanged with access network 120b. In an embodiment, the binding of IP flows to RLP flows, the binding of RTC-MAC to RLP, and/or other binding previously used for access network 120a are also used for access network 120b. The use of the same reservation labels and the same binding for both access networks 120a and 120b allows PDSN 150 to use the same TFT to filter traffic data to be forwarded via access networks 120a and 120b. In this case, module 320 does not need to exchange signaling with PDSN 150 to set up a new TFT, as shown in FIG. 5.

[0048] In an embodiment, access network 120b stores session information for access terminal 110. The session information stored by access network 120b may include QoS information, binding information, and/or other state information. The session information stored by access network 120b may be the same as or different from the session information stored by access terminal 110. In any case, the session information stored at both entities 110 and 120b may be used later to facilitate seamless handoff.

[0049] After completing QoS negotiation with access network 120b, module 320 provides to applications 310 an indication that QoS has resumed (step 524). Thereafter, the QoS application may send and receive data on the established IP flows at the desired QoS levels via access network 120b and PDSN 150 (step 525).

[0050] Access terminal 110 may thereafter move back into the coverage of access network 120a. Upon detecting loss of coverage with access network 120b, module 320 may provide to applications 310 an indication of QoS being suspended (step 526). Access terminal 110 may then perform a handoff procedure to be handed off from access network 120b to access network 120a (step 530). Access network 120a may retrieve and use the session information previously stored by access network 120a for access terminal 110. In this case, the negotiation for QoS may be avoided. After handoff is completed, module 320 may provide to applications 310 an indication that QoS has resumed (step 534). Thereafter, the QoS application may send and receive data via access network 120a and PDSN 150 (step 535).

[0051] Access terminal 110 may thereafter move back into the coverage of access network 120b. Upon detecting loss of coverage with access network 120a, module 320 may provide to applications 310 an indication of QoS being suspended (step 536). Access terminal 110 may then perform handoff from access network 120a to access network 120b, which may retrieve and use the session information previously stored for access terminal 110 (step 540). In this case, the negotiation for QoS may be avoided, and module 320 may quickly provide an indication that QoS has resumed (step 544). The QoS application may then send and receive data via access network 120b and PDSN 150 (step 545).

[0052] In the embodiment shown in FIG. 5, access terminal 110 may negotiate QoS with a given access network 120 the first time that the access terminal communicates with the access network. Access terminal 110 and access network 120 may each store session information/configuration for the access terminal. Thereafter, if access terminal 110 is handed back to access network 120, the stored session information may be retrieved, and QoS negotiation may be avoided. Furthermore, access terminal 110 may use the same reservation labels and binding for all access networks served by the same PDSN 150, so that the same TFT may be used for these access networks. Hence, TFT setup may also be avoided whenever access terminal 110 is handed off to another access network served by the same PDSN 150.

[0053] Comparing call flow 400 in FIG. 4 to call flow 500 in FIG. 5, steps 421, 431 and 441 for QoS request, steps 432 and 442 for QoS negotiation, and steps 423, 433 and 443 for TFT setup have been eliminated from call flow 500. Steps 432 and 442 for QoS negotiation and steps 423, 433 and 443 for TFT setup may be considered as major steps. Each major step is composed of a number of smaller steps that may involve exchange of several signaling messages between access terminal 110 and access network 120. For example, each QoS negotiation step may involve exchanges of 7 or 8 signaling messages between access terminal 110 and access network 120 to negotiate QoS. [0054] The embodiment shown in FIG. 5 may substantially reduce over-the-air signaling when access terminal 110 is repeatedly handed off between access networks, since there is no need to re-negotiate QoS or to set up TFT over again. Furthermore, module 320 may handle QoS negotiation for a new access network without involving the QoS application. Since module 320 stores the session information, the QoS application does not need to send a new QoS request for each handoff. The QoS application may only notice temporary suspension of QoS while handoff is in progress and may be able to resume exchanging data earlier upon receiving a QoS resumed indication from module 320 after completion of handoff.

[0055] FIG. 6 shows an embodiment of a process 600 performed by access terminal 110 for a session with multiple access networks. Access terminal 110 establishes a first session with a first access network, which may be MPA capable access network 120a, EMPA capable access network 120b, or some other access network (block 612). The session establishment may entail performing QoS negotiation with the first access network, setting up packet filters (e.g., a TFT) at a packet data gateway (e.g., PDSN 150) for the first access network, and so on. The configuration of the first session may comprise the QoS negotiated with the first access network, flow information used to create the packet filters, and so on. Access terminal 110 thereafter exchanges data with the first access network in accordance with the configuration of the first session (block 614).

[0056] Access terminal 110 saves the first session configuration after being handed off from the first access network to a second access network, which may be EMPA capable access network 120b, MPA capable access network 120a, or some other access network (block 616). Access terminal 110 establishes a second session with the second access network (block 618). The session establishment may entail performing QoS negotiation with the second access network using the same reservation labels and binding such that the packet filters already set up at the packet data gateway may still be used. Access terminal 110 then exchanges data with the second access network in accordance with the configuration of the second session (block 620). [0057] Access terminal 110 saves the second session configuration after being handed off from the second access network to the first access network (block 622). Access terminal 110 uses the saved first session configuration upon being handed back to the first access network (block 624). Depending on the network design and operation, access terminal 110 may reinstate/restart the first session that was established earlier with the first access network or may start a new session with the first access network. In any case, the use of the saved first session configuration allows access terminal 110 to avoid performing QoS negotiation again with the first access network and setting up new packet filters at the packet data gateway. Access terminal 110 then exchanges data with the first access network in accordance with the first session configuration (block 626).

[0058] Access terminal 110 uses the saved second session configuration upon being handed back to the second access network (block 628). This allows access terminal 110 to avoid performing QoS negotiation again with the second access network and setting up new packet filters at the packet data gateway. Access terminal 110 then exchanges data with the second access network in accordance with the second session configuration (block 630).

[0059] FIG. 7 shows an embodiment of a process 700 performed by an access network 12Ox for a session with access terminal 110. Access network 12Ox may be MPA capable access network 120a, EMPA capable access network 120b, or some other access network.

[0060] Access network 12Ox establishes a session for access terminal 110 (block 712). This may entail performing QoS negotiation with access terminal 110 and exchanging signaling with access terminal 110 to send packet filters (e.g., a TFT) to a packet data gateway (e.g., PDSN 150). The configuration of the session may comprise the negotiated QoS, flow information, and so on. Access network 12Ox exchanges data with access terminal 110 in accordance with the configuration of the session (block 714). Access network 12Ox saves the session configuration after access terminal 110 is handed off to another access network (block 716). Access network 12Ox uses the saved session configuration for access terminal 110 when access terminal 110 is handed back to access network 12Ox (block 718). This allows access network 12Ox to skip QoS negotiation with access terminal 110 and to skip signaling exchanges to set up new packet filters at the packet data gateway when access terminal 110 is handed back to access network 12Ox. Access network 12Ox exchanges data with access terminal 110 in accordance with the session configuration (block 720).

[0061] FIG. 8 shows a block diagram of an embodiment of access terminal 110. In the transmit direction, data and signaling to be sent by access terminal 110 are processed (e.g., formatted, encoded, and interleaved) by an encoder 822 and further processed (e.g., modulated, channelized, and scrambled) by a modulator (Mod) 824 to generate output chips. A transmitter (TMTR) 832 then conditions (e.g., converts to analog, filters, amplifies, and frequency upconverts) the output chips and generates a reverse link signal, which is transmitted via an antenna 834. In the receive direction, forward link signals transmitted by base stations in access networks are received by antenna 834. A receiver (RCVR) 836 conditions (e.g., filters, amplifies, frequency downconverts, and digitizes) the received signal from antenna 834 and provides samples. A demodulator (Demod) 826 processes (e.g., descrambles, channelizes, and demodulates) the samples and provides symbol estimates. A decoder 828 further processes (e.g., deinterleaves and decodes) the symbol estimates and provides decoded data. Encoder 822, modulator 824, demodulator 826, and decoder 828 may be implemented by a modem processor 820. These units perform processing in accordance with the radio technology (e.g., IxEV-DO, CDMA2000, W-CDMA, or GSM) used by the serving access network.

[0062] A controller/processor 840 directs the operation of various units at access terminal 110. Controller/processor 840 may implement protocol stack 300 in FIG. 3, process 600 in FIG. 6, and/or other processes to support communication services. A memory 842 stores program codes and data for access terminal 110. Memory 842 may store session information/configuration (e.g., QoS parameters, flow information, packet filters, and so on) for each access network of interest.

[0063] FIG. 8 also shows a simple embodiment of access network 12Ox, which includes a processor 850 and a memory 852. Processor 850 performs various functions for communication with access terminals and may implement 700 in FIG. 7 and/or other processes to support communication with the access terminals. Processor 850 may be a single processor or a collection of processors. Memory 852 stores program codes and data for access network 12Ox. Memory 852 may also store session information/ configuration for access terminal 110 as well as other access terminals that communicate with access network 12Ox.

[0064] The techniques described herein may be implemented by various means. For example, these techniques may be implemented in hardware, firmware, software, or a combination thereof. For a hardware implementation, the processing units at an access terminal may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or a combination thereof. The processing units at an access network or a network entity may also be implemented within one or more ASICs, DSPs, processors, and so on. [0065] For a firmware and/or software implementation, the techniques may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The firmware and/or software codes may be stored in a memory (e.g., memory 842 or 852 in FIG. 8) and executed by a processor (e.g., processor 840 or 850). The memory may be implemented within the processor or external to the processor.

[0066] The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An apparatus comprising: at least one processor configured to establish a first session with a first access network, to exchange data with the first access network in accordance with configuration of the first session, to save the first session configuration after being handed off from the first access network to a second access network, and to use the saved first session configuration upon being handed back to the first access network; and a memory coupled to the at least one processor.

2. The apparatus of claim 1, wherein the at least one processor is configured to establish a second session with the second access network upon being handed off from the first access network to the second access network, to exchange data with the second access network in accordance with configuration of the second session, and to save the second session configuration after being handed off from the second access network.

3. The apparatus of claim 2, wherein the at least one processor is configured to use the saved second session configuration upon being handed back to the second access network.

4. The apparatus of claim 1, wherein the at least one processor is configured to negotiate quality of service (QoS) with the first access network, and wherein the first session configuration comprises the QoS negotiated with the first access network.

5. The apparatus of claim 4, wherein the at least one processor is configured to skip QoS negotiation with the first access network upon being handed back to the first access network.

6. The apparatus of claim 2, wherein the at least one processor is configured to receive a single request for quality of service (QoS) from an application and to establish both the first session with the first access network and the second session with the second access network in accordance with the single request for QoS from the application.

7. The apparatus of claim 2, wherein the at least one processor is configured to receive a request for quality of service (QoS) from an application, to negotiate QoS with the first access network in accordance with the request for QoS, and to negotiate QoS with the second access network in accordance with the request for QoS upon being handed off from the first access network to the second access network, wherein the first session configuration comprises the QoS negotiated with the first access network, and wherein the second session configuration comprises the QoS negotiated with the second access network.

8. The apparatus of claim 7, wherein the at least one processor is configured to provide an indication of QoS being suspended upon being handed off from the first access network to the second access network, and to provide an indication of QoS being resumed after completing QoS negotiation with the second access network.

9. The apparatus of claim 1, wherein the at least one processor is configured to create a traffic filter template (TFT) for at least one flow exchanged with the first access network, and wherein the first session configuration comprises information used to create the TFT.

10. The apparatus of claim 9, wherein the at least one processor is configured to exchange signaling with the first access network to send the TFT to a packet data serving node.

11. The apparatus of claim 9, wherein the at least one processor is configured to skip TFT creation upon being handed back to the first access network.

12. The apparatus of claim 1, wherein the first access network supports Multi-flow Packet Application (MPA) in CDMA2000 IxEV-DO, and wherein the second access network supports Enhanced Multi-flow Packet Application (EMPA) in CDMA2000 IxEV-DO.

13. The apparatus of claim 1, wherein the second access network supports Multi-flow Packet Application (MPA) in CDMA2000 IxEV-DO, and wherein the first access network supports Enhanced Multi-flow Packet Application (EMPA) in CDMA2000 IxEV-DO.

14. A method comprising : establishing a first session with a first access network; exchanging data with the first access network in accordance with configuration of the first session; saving the first session configuration after being handed off from the first access network to a second access network; and using the saved first session configuration upon being handed back to the first access network.

15. The method of claim 14, further comprising: establishing a second session with the second access network upon being handed off from the first access network to the second access network; exchanging data with the second access network in accordance with configuration of the second session; and saving the second session configuration after being handed off from the second access network.

16. The method of claim 14, wherein the establishing the first session comprises negotiating quality of service (QoS) with the first access network, and wherein the first session configuration comprises the QoS negotiated with the first access network.

17. The method of claim 14, wherein the establishing the first session comprises creating a traffic filter template (TFT) for at least one flow exchanged with the first access network, and wherein the first session configuration comprises information used to create the TFT.

18. An apparatus comprising: means for establishing a first session with a first access network; means for exchanging data with the first access network in accordance with configuration of the first session; means for saving the first session configuration after being handed off from the first access network to a second access network; and means for using the saved first session configuration upon being handed back to the first access network.

19. The apparatus of claim 18, further comprising: means for establishing a second session with the second access network upon being handed off from the first access network to the second access network; means for exchanging data with the second access network in accordance with configuration of the second session; and means for saving the second session configuration after being handed off from the second access network.

20. The apparatus of claim 18, wherein the means for establishing the first session comprises means for negotiating quality of service (QoS) with the first access network, and wherein the first session configuration comprises the QoS negotiated with the first access network.

21. The apparatus of claim 18, wherein the means for establishing the first session comprises means for creating a traffic filter template (TFT) for at least one flow exchanged with the first access network, and wherein the first session configuration comprises information used to create the TFT.

22. A processor readable media for storing instructions operable in a wireless device to: establish a first session with a first access network; direct exchange of data with the first access network in accordance with configuration of the first session; save the first session configuration after being handed off from the first access network to a second access network; and use the saved first session configuration upon being handed back to the first access network.

23. The processor readable media of claim 22, and further for storing instructions operable to: establish a second session with the second access network upon being handed off from the first access network to the second access network; direct exchange of data with the second access network in accordance with configuration of the second session; and save the second session configuration after being handed off from the second access network.

24. The processor readable media of claim 22, and further for storing instructions operable to: negotiate quality of service (QoS) with the first access network, and wherein the first session configuration comprises the QoS negotiated with the first access network.

25. The processor readable media of claim 22, and further for storing instructions operable to: create a traffic filter template (TFT) for at least one flow exchanged with the first access network, and wherein the first session configuration comprises information used to create the TFT.

26. An apparatus comprising: at least one processor configured to establish a session for an access terminal at a first access network, to exchange data with the access terminal in accordance with configuration of the session, to save the session configuration after the access terminal is handed off to a second access network, and to use the saved session configuration for the access terminal when the access terminal is handed back to the first access network; and a memory coupled to the at least one processor.

27. The apparatus of claim 26, wherein the at least one processor is configured to negotiate quality of service (QoS) with the access terminal, wherein the session configuration comprises the negotiated QoS.

28. The apparatus of claim 27, wherein the at least one processor is configured to skip QoS negotiation with the access terminal when the access terminal is handed back to the first access network.

29. The apparatus of claim 26, wherein the at least one processor is configured to exchange signaling with the access terminal to send a traffic filter template (TFT) to a packet data serving node.

30. The apparatus of claim 29, wherein the at least one processor is configured to skip the exchange of signaling with the access terminal to send the TFT to the packet data serving node when the access terminal is handed back to the first access network.

31. A method comprising : establishing a session for an access terminal at a first access network; exchanging data with the access terminal in accordance with configuration of the session; saving the session configuration after the access terminal is handed off to a second access network; and using the saved session configuration for the access terminal when the access terminal is handed back to the first access network.

32. The method of claim 31, wherein the establishing the session for the access terminal comprises negotiating quality of service (QoS) with the access terminal, wherein the session configuration comprises the negotiated QoS.

33. The method of claim 31, wherein the establishing the session for the access terminal comprises exchanging signaling with the access terminal to send a traffic filter template (TFT) to a packet data serving node.

34. An apparatus comprising: means for establishing a session for an access terminal at a first access network; means for exchanging data with the access terminal in accordance with configuration of the session; means for saving the session configuration after the access terminal is handed off to a second access network; and means for using the saved session configuration for the access terminal when the access terminal is handed back to the first access network.

35. The apparatus of claim 34, wherein the means for establishing the session for the access terminal comprises means for negotiating quality of service (QoS) with the access terminal, wherein the session configuration comprises the negotiated QoS.

36. The apparatus of claim 34, wherein the means for establishing the session for the access terminal comprises means for exchanging signaling with the access terminal to send a traffic filter template (TFT) to a packet data serving node.

37. A processor readable media for storing instructions operable to: establish a session for an access terminal at a first access network; direct exchange of data with the access terminal in accordance with configuration of the session; save the session configuration after the access terminal is handed off to a second access network; and use the saved session configuration for the access terminal when the access terminal is handed back to the first access network.

38. The processor readable media of claim 37, and further for storing instructions operable to: negotiate quality of service (QoS) with the access terminal, wherein the session configuration comprises the negotiated QoS.

39. The processor readable media of claim 37, and further for storing instructions operable to: direct exchange of signaling with the access terminal to send a traffic filter template (TFT) to a packet data serving node.