Handoff between base stations of different protocol revisions in a cdma system

BACKGROUND

Countryside

The present invention relates, in general, to communication and, more specifically, to techniques for supporting the handover of a terminal between base stations of different protocol revisions in an extended spectrum communication system.

Background

Wireless communication systems are widely implemented to provide various types of communication such as voice, packet data, etc. These extended spectrum communication systems can be multiple access systems that can support communication with multiple users, and can be based on code division multiple access (CDMA), time division multiple access (TDMA) techniques. , multiple frequency division access (FDMA), or some other multiple access technique. CDMA systems can provide certain advantages over other types of systems, including greater system capacity.

A CDMA system is normally designed to conform to one or more CDMA standards. Examples of 15 such CDMA standards include "TIA / EIA / IS-95-A Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System" ["TIA / EIA / IS-95-A Standard for Station Compatibility mobile and base station for an extended spectrum, broadband and dual mode cellular system ”] (hereafter referred to as IS-95A), “TIA / EIA / IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System” [“TIA / EIA / IS-95-B Standard for compatibility between mobile station and base station 20 for a extended spectrum, broadband and dual mode cellular system ”] (hereinafter, IS-95B) and TIA / EIA / IS-2000 (hereinafter, IS-2000). Each CDMA standard can also be associated with multiple versions, each of which may include updates and new features for that standard. For example, the IS-2000 standard includes a Version 0, Version A, Version B, Version C, etc. New standards and versions of CDMA are continuously proposed and adopted for use. 25

The IS-95A standard, which covers the first generation CDMA, is primarily designed for voice communication. As such, it supports a call between a terminal and a base station at any given time. The IS-95B standard, which covers the next-generation CDMA, supports voice and data communication (albeit at a relatively low data rate). The IS-2000 standard supports both voice and high-speed data communication. For the family of standards composed of IS-95 and IS-30 2000, each newest CDMA standard and version within that family incorporates the features and functionality defined in previous CDMA standards and versions, and also adds improvements and / or new features

A specific CDMA standard / version can be assigned a specific level of signaling protocol revision (P_REV) that can be used to unambiguously identify that standard / version. For example, on side 35 of the base station, IS-95B, IS-2000 Version 0 and IS-2000 Version A are associated with P_REVs of 5, 6 and 7, respectively. A new version of a given norm can therefore be considered as another norm. In general, a newer CDMA standard is backward compatible with older CDMA standards. A terminal or base station designed to support a particular P_REV (for example, P_REV = 7) could also then support the lower P_REV (for example, P_REV = 5 and 6). 40

A wireless service provider may deploy, due to different deployment options available, different generations of base stations, near or near each other. This can result in compatibility problems if base stations with different P_REVs are used to support communication for a given terminal. For such a hybrid deployment, a terminal may be in communication with a base station of a particular P_REV and then be transferred to another base station of a different P_REV. A higher P_REV is generally associated with more parameters, since it supports more features and functions than a lower P_REV. Therefore, if the terminal is transferred between base stations of different P_REVs, there are challenges associated with the manipulation of parameters that are defined in a P_REV and not in another P_REV.

Therefore, there is a need in the technology of techniques to support the handover of a terminal 50 between base stations of different protocol revisions that may be associated with different parameters used for communication.

PCT Publication No. WO01 / 10159 discloses a system and method for controlling the transmission of information and the transfer of communication between frequency division multiplexing and time division multiplexing communication systems, using a multiple access scheme .

PCT Publication No. WO01 / 78240 discloses a continuous handover operation for a first signal transmitted according to a first communication standard and a second signal transmitted according to a second communication standard. 5

SUMMARY

Techniques are provided herein to support a handover of a terminal between base stations of different protocol revisions, as set forth in the appended claims. Various schemes to support handover are described herein. The particular scheme used for handover depends on the protocol revisions of the terminal and the target base station and, possibly, other factors (for example, whether or not there is a call on hold).

In one embodiment, a method is provided to support the handover of a terminal between base stations of different protocol revisions in an extended spectrum communication system. According to the procedure, a transfer of the terminal from a first base station to a second base station is made while the terminal is on an active call (data or voice) with the first base station. The first base station 15 supports a first protocol revision (for example, P_REV ≤ 5) and the second base station supports a second protocol revision (for example, P_REV ≥ 6) that is subsequent to the first revision of protocol. The active call can be maintained between the terminal and the second base station using a first service configuration previously established through the first base station for the active call.

A second service configuration can be established through the second base station for the active call. The second base station may consult the terminal for the second service configuration or simply assign the second service configuration. This query or assignment can be made after the second base station has been added to the active set of the terminal or after handover. Alternatively, the terminal may initiate the establishment of the second service configuration after being informed (for example, by means of a release of the active call or through a signaling message) that it can update its service. The second service configuration can also be for a call on hold (if any) that has been established before handover. In any case, the active call can then be maintained using the second service configuration if available.

Each service configuration comprises a particular service option instance to be used for an associated call. The first service configuration may comprise a first service option instance 30 for a low-speed packet data call (eg, SO 7), and the second service configuration may comprise a second service option instance for a high speed packet data call (for example, SO 33).

Various aspects and embodiments of the invention are described in more detail below. The invention further provides other methods, program codes, digital signal processors, terminals, base stations, systems and other devices and elements that implement various aspects, embodiments and features of the invention, as described in greater detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

The features, nature and advantages of the present invention will become more apparent from the detailed description set forth below when considered in conjunction with the drawings, in which 40 similar reference characters identify correspondingly throughout them and in those who:

FIG. 1 is a diagram of a CDMA communication system in which various aspects and embodiments of the invention can be implemented;

FIGS. 2A-2B are state machines for call processing in a terminal, as defined in IS-2000; Four. Five

FIG. 3 is a diagram illustrating the correlation between some of the sub-layers of a layer 3 defined by IS-2000;

FIGS. 4A-4H are diagrams illustrating a transfer of a terminal (with particular MOB_P_REV) from base station 1 (with P_REV = 5) to base station 2 (with a particular P_REV greater than 5) for various operating scenarios; and 50

FIG. 5 is a block diagram of a specific embodiment of various network elements in a system.

DETAILED DESCRIPTION

FIG. 1 is a diagram of a CDMA communication system 100 in which various aspects and embodiments of the invention can be implemented. System 100 provides communication for several cells, 5 giving a corresponding base station 104 service to each cell. Various terminals 106 are scattered throughout the system (only one terminal is shown in FIG. 1 for simplicity). Each terminal may communicate with one or more base stations 104 via direct and reverse links at any given time, depending on whether or not the terminal is active and that it is in continuous transfer or not. The direct link (i.e. downlink) refers to the transmission from the base station to the terminal, and the reverse link (i.e., uplink) refers to the transmission from the terminal to the base station.

System 100 may be designed to support one or more standards and versions of CDMA such as IS-95A, IS-95B, IS-2000 Version 0, IS-2000 Version A, etc. For simplicity, each version of a given standard can also be considered as a standard. All these standards are known in the technology and are incorporated herein by reference. On the side of the base station, the various CDMA standards are associated with different levels of signaling protocol revision (P_REV). And on the terminal side, the various CDMA standards are associated with different levels of revision of the mobile signaling protocol (MOB_P_REV). In particular, IS-95B, IS-2000 Version 0 and IS-2000 Version A are associated respectively with the P_REV of 5, 6 and 7 on the side of the base station, and associated respectively with the MOB_P_REV of 4/5, 6 and 7 on the side of the terminal. The P_REV of the base station and the MOB_P_REV of the terminal are not directly correlated for all CDMA standards.

A newer CDMA standard is generally backward compatible with older CDMA standards. Therefore, a terminal or base station designed to support a particular P_REV (for example, P_REV = 7) could also support lower P_REV (for example, P_REV = 5 and 6).

FIG. 2A is a 200 state machine for processing calls in a terminal, as defined in IS-2000. Upon power-up, the terminal switches from a Power On State 210 to a Mobile Station Initialization State 212.

In state 212, the terminal selects a particular system to use. If an analog system is selected, then the terminal goes to a state 214 and the operation begins in analog mode. On the contrary, if a CDMA system is selected, then the terminal proceeds to acquire and synchronize with the selected CDMA 30 system. After acquiring the synchronization of the selected CDMA system, the terminal enters an Inactive State 216 of Mobile Station.

In state 216, the terminal is "On" but not active. The terminal monitors a radio messaging channel for messages from a base station in an active set. The active set is a list of one or more base stations with which the terminal is currently communicating. If the terminal cannot receive the radio messaging channel 35 or if a new base station must be added to an active set of the terminal, then the terminal returns to state 212 and acquires the new base station. In state 216, the terminal can receive messages or an incoming call, originate a call, make records, transmit a message, or perform some other action. After initiating any of these actions, the terminal enters a State 218 of Access to the System.

In state 218, the terminal sends messages through one or more access channels to the base station in the active set and receives messages from the base station through the radio messaging channel in an attempt to access the base station. Depending on the result of the message exchange, the terminal may either return to State 216 Inactive if there is no active communication, or advance to a Mobile Station Control State 220 on the traffic channel if a call should be processed. Before entering state 220, a direct traffic channel is assigned to the terminal for the call. Four. Five

In state 220, the terminal communicates with the base station using the established direct and reverse traffic channels. At the end of the last call, the traffic channel is released and the terminal returns to state 212.

Each of the states shown in FIG. 2A is defined by a respective state machine that includes several substations.

FIG. 2B is a state machine for State 220 of Mobile Station Control over the traffic channel, as defined in IS-2000. From State 218 of Access to the System, after receiving the assigned direct traffic channel, the terminal enters a Substation 230 of Traffic Channel Initialization of state 220.

In the substate 230, the terminal verifies that it can receive data through the direct traffic channel, starts transmitting data through the reverse traffic channel and synchronizes the traffic channels between the terminal and the base station. The terminal then waits for an indication from layer 2 that the direct traffic channel has been acquired. After receiving this indication, the terminal goes to a Traffic Channel Substation 232.

In substation 232, the terminal exchanges traffic channel frames with the base station according to the current service configuration. During substation 232, one or more instances (or calls) of Call Control (CC) (described below) can be activated. The terminal remains in substate 232 if any call is active. After releasing the last call (either by the user of the terminal or through a Release Order Message or an Extended Release Message from the base station), the terminal goes to a Release Substation 234. 10

In substate 234, the terminal disconnects calls and physical channels. The terminal then returns to Traffic Channel Substation 232 if it receives an indication to enter this substate or, otherwise, it goes back to State 212 of Mobile Station Initialization.

The state machines shown in FIGS. 2A and 2B are described in more detail in a document of the IS-2000 TIA / EIA / IS-2000-5, entitled "Upper Layer (Layer 3) Signaling Standard for CDMA 15 2000 Spread Spectrum Systems" upper layer (layer 3) for CDMA 2000 extended spectrum systems), March 2000, which is incorporated herein by reference. Other CDMA standards (for example, IS-95B) define similar state machines for terminal call processing.

FIG. 3 is a diagram illustrating the correlation between some of the sub-layers of a layer 3 defined in IS-2000. Layer 3 manipulates call processing and service configuration. As shown in FIG. 3, Layer 3 includes a call control (CC) sublayer 312 that resides above a service option control (SOC) sublayer 314 that also resides above a radio resource control (RRC) sublayer 316. Sublayer 316 RRC defines the physical traffic channels available for data transmissions. Sublayer 314 SOC defines a set of parameters to be used for communication, such as multiplexing options, power control, direct link traffic channel characteristics, etc. Sublayer 312 of 25 call control identifies a set of ongoing calls that are being processed.

This document uses the following terminology:

<dl>&lt;dt /&gt;<dd>• Service option (OS) - A system service capability. The service options can be applications such as voice, data, fax, etc. </dd></dl>

<dl>&lt;dt /&gt;<dd>• Service option connection (OS connection) - A particular instance or session in which the service defined by a particular service option is used. A service option connection is associated with (1) a reference (CON_REF), which is used to uniquely identify the service option connection, (2) a service option, which specifies the type of particular service in use , (3) a type of direct traffic channel traffic, which specifies what type of direct traffic channel traffic is used to support the service option connection and (4) a type of reverse traffic channel traffic , that specifies what type of reverse traffic channel traffic is used by the service option connection. </dd></dl>

<dl>&lt;dt /&gt;<dd>• Service configuration - The common attributes used by a terminal and a base station for communication (that is, to form and interpret traffic channel frames exchanged between the terminal and the base station). This set of attributes includes negotiable and non-negotiable parameters. 40</dd></dl>

<dl>&lt;dt /&gt;<dd>• Service configuration register (SCR) - The register used to send information for negotiable parameters, including (1) direct and reverse multiplexing options, (2) direct and reverse traffic channel configurations, (3) transmission rates of direct and reverse traffic channel and (4) service option connections. Each SCR may include one or more service option connection records, and each service option connection record is associated with a service reference identifier (SR_ID). </dd></dl>

<dl>&lt;dt /&gt;<dd>• Non-negotiable service configuration register (NNSCR) - The register used to send information for non-negotiable parameters. </dd></dl>

<dl>&lt;dt /&gt;<dd>• Service reference identifier (SR_ID). The SR_ID identifies an associated service option instance. fifty</dd></dl>

A call is used to describe in general terms a communication session of a certain type of service (indicated by service option number) between a terminal and the CDMA system. For IS-2000, there is a one-to-one correlation between each call and an associated service option connection. Each call is also associated with a particular service option (OS), which formally defines the way in which data bits are processed by the terminal and the base station for that call. As examples, SO 7 is a service option 5 for a low-speed packet data call at P_REV = 5, and SO 33 is a service option for a high-speed packet data call at P_REV ≥ 6.

For IS-2000 Version A (that is, P_REV = 7), several calls can be processed concurrently. When each call is connected, a new call control (CC) state machine (indicated as CallX) is instantiated. The instantiated CC state machine is of a type that is selected based on the type of call being processed (eg voice, data, etc.). IS-2000 Version A supports several types of machines from different CC states.

In the example shown in FIG. 3, each call (CallX) is processed in sublayer 312 CC and correlated with a particular service option connection (connection NOS). In the example shown in FIG. 3, CallA correlates with OS Connection 1 and Call B correlates with OS Connection 2. Subscripts A and B 15 represent the caller IDs (CALLED ID) used to identify the calls, and subscripts 1 and 2 represent the references (CON_REF) for the established service option connections. In the example shown in FIG. 3, Conex.1 of SO is correlated with (i.e. uses) a dedicated control channel (DCCH) and a complementary channel (SCH), and Conex.2 of SO correlates with a fundamental channel (FCH) and a channel complementary. twenty

When the call correlated with a particular service option connection is released, that service option connection can also be released. Similarly, when the last service option connection correlated with a particular physical channel is released, that physical channel can be released.

Each CDMA standard defines the procedures for performing the service configuration and negotiation to configure various parameters used for communication between the terminal and the base station. As indicated above, the service configuration comprises both negotiable and non-negotiable parameters. During negotiation and / or confirmation, information for negotiable parameters may be sent in a service configuration register (SCR) included in an appropriate signaling message, and information for non-negotiable parameters may be sent in a non-negotiable service configuration register. negotiable (NNSCR).

Service option connections can be negotiated between the terminal and the base station through "service negotiation" procedures. If a service option connection is required to support a new call, then the service option request and assignment are achieved using the service negotiation procedures. The service negotiation procedures are described in detail in IS-2000.

The service options can also be negotiated between the terminal and the base station, or default service options can also be selected for use. The service option negotiation procedures are also described in detail in IS-2000 and IS-95.

The service negotiation and the service option negotiation are carried out through an exchange of signaling messages between the terminal and the base station. For IS-2000 the following signaling messages are sent by the base station through a direct dedicated signaling logical channel (f-dsch):

<dl>&lt;dt /&gt;<dd>• Service Connection Message (SCM): The base station can use this message to (1) 40 accept a service configuration proposed by the terminal, (2) instruct the terminal to start using the service configuration included in the message , or (3) instruct the terminal to use a particular stored service configuration. </dd></dl>

<dl>&lt;dt /&gt;<dd>• Universal Transfer Address (UHDM) Message: The base station can use this message to (1) indicate whether service negotiation or service option negotiation should be performed following a discontinuous transfer from CDMA to CDMA, (2) accept a service configuration proposed by the terminal, or (3) instruct the terminal to start using the service configuration included in the message. </dd></dl>

<dl>&lt;dt /&gt;<dd>• Status Request Message (SRQM): The base station can use this message to request the current service configuration from the terminal. fifty</dd></dl>

<dl>&lt;dt /&gt;<dd>• Incoming Traffic System Parameters (ITSPM) Message: The base station can send this message to inform the terminal that the packet area has changed (described below). </dd></dl>

<dl>&lt;dt /&gt;<dd>• Release Order Message: The base station can use this message to release an active call. </dd></dl>

<dl>&lt;dt /&gt;<dd>• Extended System Parameters (ESPM) Message: The base station can also send this message to inform the terminal that the packet area has changed. 5</dd></dl>

For IS-2000 the following signaling messages are sent by the terminal, either through a reverse dedicated signaling logical channel (r-dsch) or a reverse common signaling logical channel (r-csch):

<dl>&lt;dt /&gt;<dd>• Originating Message (ORM): The terminal can use this message to originate a new call. </dd></dl>

<dl>&lt;dt /&gt;<dd>• Enhanced Origination Message (EOM): The terminal can also use this message to originate a new call. 10</dd></dl>

<dl>&lt;dt /&gt;<dd>• Status Response Message (STRPM): The terminal can send this message to provide the base station with the current service configuration. </dd></dl>

<dl>&lt;dt /&gt;<dd>• The previous signaling messages are described in detail in the IS-2000 standard. </dd></dl>

Table 1 lists some of the main features that support P_REV = 5, 6 and 7 for calls. fifteen

Table 1

<dl><dt> P_REV = 5 </dt>&lt;dd /&gt;</dl>

<dl><dt> • Supports a data call and / or a voice call at any given time. </dt>&lt;dd /&gt;</dl>

<dl><dt> P_REV = 6 </dt>&lt;dd /&gt;</dl>

<dl><dt> • Enter the concept of service reference identifier (SR_ID) to identify each instance of service option. </dt>&lt;dd /&gt;</dl>

<dl><dt> • Enter the concept of call waiting, according to which a traffic channel can be released for a data call, but the SR_ID and PPP session information are held on hold so that the data call can resume quickly in a later moment. </dt>&lt;dd /&gt;</dl>

<dl><dt> • Supports an active data call at any given time. </dt>&lt;dd /&gt;</dl>

<dl><dt> P_REV = 7 </dt>&lt;dd /&gt;</dl>

<dl><dt> • Introduces the concept of concurrent services, according to which multiple calls can be concurrently supported, each call being uniquely identified by its associated SR_ID. </dt>&lt;dd /&gt;</dl>

<dl><dt> • Each call on hold data is also associated with an SR_ID. </dt>&lt;dd /&gt;</dl>

A wireless service provider can deploy different generations of base stations with different P_REVs near or next to each other. This may result in compatibility issues if base stations with different P_REVs are designated to provide communication for a given terminal. For such a hybrid deployment, the terminal may be in communication with a base station of a particular P_REV and then be transferred to another base station with a different P_REV.

The base station with the highest P_REV supports more features and functions for calls, as shown in Table 1, and is usually associated with more parameters used to define communication. Therefore, if the terminal is transferred between base stations of different P_REV, then there are challenges associated with the manipulation of parameters (for example, SR_ID) that are defined in a P_REV (P_REV ≥ 6) and not in another P_REV (P_REV ≤ 5).

The various compatibility scenarios can be briefly described with reference to FIG. 1. In FIG. 1, the base station 1 may be associated with the P_REV ≤ 5, while the base station 2 may be associated with a P_REV ≥ 6. If the terminal is associated with a MOB_P_REV of 5 and is transferred from base station 1 to base station 2, then base station 2 would need to operate with P_REV_EN_USO = 5 for communication with the terminal, and no incompatibilities would appear. However, if the terminal is associated with a MOB_P_REV ≥ 6 and is transferred from base station 1 (with P_REV ≤ 5) to base station 2 (with P_REV ≥ 5 6), then there may be ambiguity regarding the use of SR_ID , which is defined in P_REV ≥ 6 but not in P_REV ≤ 5, for active and waiting calls. These various scenarios are described in greater detail in the following figures.

For simplicity, the following figures specifically describe the P_REV of 5, 6 and 7. However, the techniques described herein to support transfers can be extended to 10 other P_REVs, and this is within scope of the invention. In the following figures, base station 1 may be associated with a P_REV ≤ 5 in FIGS. 4A-4H, and base station 2 is associated with P_REV = 6 in FIGS. 4A-4B and 4G and P_REV ≥ 7 in FIGS. 4C-4F and 4H.

For reasons of clarity in the following figures, specific service options SO 7 and SO 33 (which are defined in IS-707) are described. Other service options are also applicable and can be used for 15 data calls. For example, SO 7, or some other low speed packet data service option, can be used for a data call with a base station with P_REV ≤ 5, and SO 33, or some other packet data service option at high speed, it can be used for a data call with a base station with P_REV ≥ 6.

FIG. 4A is a diagram illustrating a transfer of a terminal (with MOB_P_REV = 6 or 7) from base station 1 (with P_REV = 5) to base station 2 (with P_REV = 6). For FIG. 4A, there are no data calls on hold (that is, no data wait) when the handover has occurred, and P_REV_EN_USO = 6 after the handover. For compatibility reasons, P_REV_EN_USO is given by the minor of (1) the P_REV of the destination base station and (2) the MOB_P_REV of the terminal (that is, P_REV_EN_USO = min {P_REV, MOB_P_REV}). In FIG. 4A two scenarios are shown, one for a handover with an active data call and another for a handover with an active voice call.

In the first scenario, the terminal initially originates a data call with the base station 1. Since base station 1 is associated with P_REV = 5, this data call may be for SO 7, which is a service option for a Data call by packet at low speed. While the data call is still active, the terminal is transferred from base station 1 to base station 2. Since the P_REV_EN_USO = 6 30 after handover, this data call can be associated with an SR_ID. However, since only one call has been established so far, there is no ambiguity in either the terminal or the base station 2 as to which call is being processed. Therefore, an SR_ID (i.e. not used) can be dispensed with for this data call. If an SR_ID is to be used for the data call, then base station 2 can send the SR_ID for this call in a service configuration register (SCR) included in a Service Connection Message or a Transfer Address Message Universal (SCM / UHDM) sent to the terminal. Both the terminal and base station 2 would thereafter use this SR_ID for the data call.

In the second scenario, the terminal initially originates a voice call with the base station 1. This voice call can be for the Multiplexing Option = 1 and the Radio Configuration (RC) = 1, which are defined in IS-95 and IS-2000. While the voice call is still active, the terminal is transferred to base station 2. 40 Since P_REV_EN_USO = 6 after handover, this voice call can be identified by an SR_ID. Again, since only one call has been established so far, there is no ambiguity in either the terminal or the base station 2, and SR_ID can be dispensed with. However, if an SR_ID is to be used for this voice call, then base station 2 can send the SR_ID in an SCR included in an SCM / UHDM. Both the terminal and base station 2 would thereafter use this SR_ID for the voice call. Four. Five

In one embodiment, for both scenarios described above, the destination base station 2 sends a SCM / UHDM to the terminal with the new service configuration records (for example, new SCRs and NNSCRs, including SR_ID) after the base station has been added to the active set. The message can be sent before or during the transfer. For this embodiment, the terminal may store the service configuration records for later use. fifty

In another embodiment, for both scenarios described above, the destination base station 2 sends a SCM / UHDM to the terminal with the new service configuration records after handover. For this embodiment, the SCM / UHDM can be sent only if the service configuration records are required (for example, if an SR_ID is to be used for the active call).

FIG. 4B is a diagram illustrating a transfer of a terminal (with MOB_P_REV = 6 or 7) from 55 base station 1 (with P_REV = 5) to base station 2 (with P_REV = 6), with data waiting and P_REV_EN_USO = 6 after the transfer. Again, two scenarios are shown in FIG. 4B, one for a transfer with an active data call and another for a transfer with an active voice call.

In the first scenario, the terminal initially establishes a data call with a base station (with P_REV = 6 or 7), which may be base station 2 or another base station in the system. This data call can be for SO 33, which is a service option for a high-speed packet data call, and can be assigned SR_ID = x. This data call is then put on hold and the terminal is transferred to the base station 1 during the wait.

For P_REV ≥ 6, the terminal and the base station establish a PPP session at the beginning of the first data call. This PPP session can be maintained even if the data call is put on hold, which would then allow data communication to resume more quickly if the call on hold is reconnected or a new data call is established. The service configuration for call waiting may or may not be retained by the terminal and the network, depending on the terminal and system implementations.

The terminal then originates a new data call with the base station 1. Since base station 1 has P_REV = 5, this new data call can be for SO 7. While this 15 data call is still active, the terminal it is transferred from base station 1 to base station 2. Since P_REV_EN_USO = 6 after handover, this active data call can be associated with an SR_ID.

In one embodiment, the PPP session with SO 7 established for the active data call is purged and the waiting SO 33 instance is reconnected for the active data call. The reconnected SO 33 instance can be for SR_ID = x or a new SR_ID = z. The particular SR_ID to be used for the reconnected SO 33 instance 20 can be determined based on various schemes. In a first scheme, base station 2 takes the session on hold (with SR_ID = x) from the wait. In a second scheme, base station 2 simply assigns a new SR_ID = z for the reconnected SO 33 instance. The SR_ID for the reconnected SO 33 instance (which may be the proposed SR_ID or the assigned SR_ID) can be sent to the terminal through an SCR in an SCM / UHDM. The PPP session with SO 33 can also be resynchronized, if necessary (for example, if SR_ID = z is to be used for the reconnected SO 33 instance instead of SR_ID = x).

In the second scenario, the terminal initially establishes a data call with a base station (with P_REV = 6 or 7) and is transferred to base station 1 when the data call is on hold. The terminal then originates a voice call with the base station 1 and, while the voice call is still active, it is transferred to the base station 2. Since the P_REV_EN_USO = 6 after the handover, this voice call can be associated with an SR_ID However, since there is only one voice call (active) and one data call (on hold) (that is, one of each type), there is no ambiguity in either the terminal or the base station 2, and can dispense with the SR_ID for the voice call. If an SR_ID is to be used for this voice call, then base station 2 can send the SR_ID through an SCR in an SCM / UHDM. Both the terminal and base station 2 would thereafter use this SR_ID for the voice call. 35

FIG. 4C is a diagram illustrating a transfer of a terminal (with MOB_P_REV = 6) from base station 1 (with P_REV = 5) to base station 2 (with P_REV = 7), without any data waiting and P_REV_EN_USO = 6 after of the transfer.

In the first scenario, the terminal initially originates a data call for SO 7 with the base station 1 and, while the voice call is still active, it is transferred to the base station 2. Even though the base station 2 has P_REV = 7, it needs to decrease to P_REV = 6 since the terminal has MOB_P_REV = 6, and therefore the P_REV_EN_USO = 6. The active data call can then be treated similarly to that described above for FIG. 4A. In particular, an SR_ID can be dispensed with for this data call, since there is only one call and there is no ambiguity in either the terminal or the base station 2. However, if an SR_ID is to be used for the data call , then base station 2 can send the SR_ID to 45 through an SCR in an SCM / UHDM.

In the second scenario, the terminal originates a voice call with the base station 1 and, while the voice call is still active, it is transferred to the base station 2. Again, the base station 2 needs to decrease to P_REV = 6 ( that is, P_REV_EN_USO = 6), and the voice call is treated similarly to that described above for FIG. 4A. fifty

FIG. 4D is a diagram illustrating a transfer of a terminal (with MOB_P_REV = 6) from base station 1 (with P_REV = 5) to base station 2 (with P_REV = 7), with data waiting and P_REV_EN_USO = 6 after transfer.

In the first scenario, the terminal initially establishes a data call with a base station (with P_REV = 6 or 7) for SO 33 and can be assigned SR_ID = x. This data call is then put on hold and the terminal is transferred to the base station 1 during the wait. The terminal then originates a new data call for SO 7 with the base station 1. While the SO 7 data call is still active, the terminal is transferred to the base station 2. Since P_REV_EN_USO = 6 after handover, the active data call 5 can be identified by an SR_ID. In one embodiment, the PPP session with SO 7 is purged and the waiting SO 33 instance is reconnected with SR_ID = x or a new SR_ID = z assigned by the base station 2. The PPP session with SO 33 can also be resynchronized, if necessary . In another embodiment, which is not shown in FIG. 4D, the waiting session SO 33 is purged (for example, after having been transferred to the base station 1) and the PPP session with SO 7 for the active data call is maintained by the base station 2 after the handover. For this embodiment, the SR_ID can be dispensed with for the active data call (since there is only one data call and there is no ambiguity) or one can be assigned by the base station 2 through an SCR in an SCM / UHDM

In the second scenario, the terminal has a data call SO 33 on hold with SR_ID = x when it was transferred to the base station 1. The terminal then originates a voice call with the base station 1 and, 15 while the voice call is still active, it is transferred to base station 2. Since the P_REV_EN_USO = 6 after the handover, this voice call can be associated with an SR_ID. However, since there is only one voice call (active) and one data call (on hold), there is no ambiguity in either the terminal or the base station 2, and SR_ID can be dispensed with. If an SR_ID is to be used for the active voice call, then base station 2 can send the SR_ID through an SCR in an SCM / UHDM. Both the terminal and base station 20 would thereafter use this SR_ID for the voice call.

FIG. 4E is a diagram illustrating a transfer of a terminal (with MOB_P_REV = 7) from base station 1 (with P_REV = 5) to base station 2 (with P_REV = 7), without any data waiting and P_REV_EN_USO = 7 after of the transfer.

In the first scenario, the terminal initially originates a data call for SO 7 with the base station 25 and, while the data call is still active, it is transferred to the base station 2. An SR_ID can be dispensed with for this call. data since there is no ambiguity with just one ongoing data call. However, if an SR_ID is to be used for this data call, then base station 2 can send the SR_ID through an SCR in an SCM / UHDM.

Since P_REV = 7 supporting multiple concurrent calls, another call (data or voice) 30 can be initiated by the terminal through an Enhanced Source Message (EOM) with a proposed SR_ID for the new call. In that case, two different SR_IDs would be required for the current data call and for the new call. The SR_ID proposed by the terminal for the new call can be accepted by the base station 2 and used for the new call. The base station 2 can then assign another SR_ID, if one has not already been assigned, for the current data call. The base station 2 then sends to the terminal both the proposed SR_ID for the new call and the SR_ID assigned for the current data call through an SCR in a SCM / UHDM.

In the second scenario, the terminal originates a voice call with the base station 1 and, while the voice call is still active, it is transferred to the base station 2. Again, an SR_ID can be dispensed with for this voice call already There is currently only one call. However, if an SR_ID is to be used, then base station 2 can send the SR_ID through an SCR in an SCM / UHDM. Similar to the first scenario, if another call is initiated by the terminal through an Enhanced Origination Message with a proposed SR_ID for the new call, then base station 2 can accept the proposed SR_ID for the new call and assign another SR_ID for the current voice call. In this way, both calls can be associated with unique SR_IDs.

FIG. 4F is a diagram illustrating a transfer of a terminal (with MOB_P_REV = 7) from base station 45 (with P_REV = 5) to base station 2 (with P_REV = 7), with data waiting and P_REV_EN_USO = 7 after of the transfer.

In the first scenario, the terminal initially establishes two data calls with a base station (with P_REV = 6 or 7), which may or may not be base station 2. These data calls can be for SO 33 and can be assigned SR_ID = xy SR_ID = y. In general, any number of data calls 50 (from 2 to 7) may have been established. Then, the data calls are put on hold and the terminal is transferred to the base station 1 during the wait. The terminal then originates a new data call for SO 7 with the base station 1. While the SO 7 data call is still active, the terminal is transferred to the base station 2. Since the P_REV_EN_USO = 7 after the handover, the Current data call can be identified by an SR_ID.

In one embodiment, the PPP session with SO 7 for the active data call is purged and one of the two 55 SO 33 instances on hold is reconnected for the active data call. Since there are multiple SO 33 instances waiting, the specific SO 33 instance that must be reconnected can be determined based on various schemes. In a scheme, the terminal autonomously selects which SR_ID to use for the reconnected SO 33 instance. The base station 2 consults the terminal with the current service configuration through a Status Request Message. The terminal then responds to the query with a Status Response Message that includes an SCR with the proposed SR_ID for the SO 33 instance to be reconnected. If base station 2 accepts the proposed SR_ID, then reconnect the corresponding SO 33 instance. In a second scheme, base station 2 simply assigns a new SR_ID = z for the reconnected SO 33 instance, without consulting the terminal. For both schemes, the final decision as to which SR_ID to use is taken by the base station and the terminal accepts the decision. The reconnected SO 33 instance can therefore be for SR_ID = xoy, or a new SR_ID = z. The SR_ID to be used for the reconnected SO 33 instance is then provided to the terminal through an SCR in an SCM / UHDM. The PPP session with SO 33 can also be resynchronized, if necessary (for example, if SR_ID = z is to be used for the reconnected SO 33 instance instead of SR_ID = xoy).

In another embodiment, both SO 33 instances are purged on hold (for example, when the terminal is transferred to the base station 1) and the PPP session with SO 7 is maintained for the active data call when the terminal 15 is transferred to the base station 2. For this embodiment, the SR_ID can be dispensed with (since there is currently only one data call) or a new SR_ID can be assigned by the base station 2 through an SCR in an SCM / UHDM.

In the second scenario, the terminal initially establishes two data calls and, while the calls are on hold, it is transferred to the base station 1. The terminal then originates a voice call with the base station 1 and, while the call Voice is still active, it is transferred to base station 2. Again, an SR_ID can be dispensed with for this voice call since there is no ambiguity with just one voice call. However, if an SR_ID is to be used for the voice call, then base station 2 can send the SR_ID through an SCR in an SCM / UHDM.

The terminal can also initiate a new data call through an Enhanced Source Message, 25 and can propose an SR_ID for this data call. The proposed SR_ID can be an SR_ID for one of the waiting data calls (that is, SR_ID = xoy) or another SR_ID (for example, the smallest number that is unused and currently available for SR_ID). The base station can accept the proposed SR_ID for the new data call and can assign another SR_ID for the current voice call. Thus, the new data call and the current voice call are associated with unique SR_IDs. 30

FIG. 4G is a diagram illustrating a transfer of a terminal (with MOB_P_REV = 6 or 7) from base station 1 (with P_REV = 5) to base station 2 (with P_REV = 6), with data waiting and P_REV_EN_USO = 6 After the transfer. In this figure, the terminal starts the use of a new SR_ID after the transfer to a base station with a higher P_REV.

Initially, the terminal establishes a data call for SO 33 with a base station (with P_REV = 35 6 or 7). Then, the call is put on hold and the terminal is transferred to base station 1 during the wait. The terminal then originates a new data call for SO 7 with the base station 1. While this data call is still active, the terminal is transferred to the base station 2. Since the P_REV_EN_USO = 6 after handover, the active data call can be identified by an SR_ID.

After being transferred to the base station 2, this base station releases the active data call 40 (which is a non-SO 33 call) by sending a Release Order Message to the terminal. After receiving this message, the terminal enters an inactive state and listens for an Extended System Parameter Message (ESPM) with Packet Zone ID (PZID) sent by the base station 2. By processing the ESPM from base station 2, the terminal can detect that the packet area has changed and that it can update its service option. Each P_REV may be associated with a different packet zone, indicating the service options available for that zone. When the terminal is transferred from a base station with P_REV = 5 to a base station with P_REV ≥ 6, the terminal can be upgraded from SO 7 (low packet data) to SO 33 (high speed packet data). The terminal can then originate a new data call for SO 33 through a Source Message (ORM) with a proposed SR_ID. A ready data field (DRS) in the ORM can be set to "1" to indicate that the terminal has data ready to be sent. The base station 2 can accept the request and a new SO 33 instance can be connected to the proposed SR_ID for the new data call.

FIG. 4G is also applicable for a transfer of a terminal (with MOB_P_REV = 6) from base station 1 (with P_REV = 5) to base station 2 (with P_REV = 7). In this case, the P_REV_EN_USO = 6 after the transfer. 55

FIG. 4H is a diagram illustrating a transfer of a terminal (with MOB_P_REV = 7) from base station 1 (with P_REV = 5) to base station 2 (with P_REV = 7), with data waiting and P_REV_EN_USO = 7 after transfer. In this figure, the terminal starts the use of a new SR_ID after the transfer to a base station with higher P_REV.

Initially, the terminal establishes two data calls for SO 33 with a base station (with P_REV = 5 6 or 7), which may or may not be the base station 2. In general, any number of data calls (from 2 to 7). Then, these calls are put on hold and the terminal is transferred to base station 1 during the wait. The terminal then originates a new data call for SO 7 with base station 1. While the data call with SO 7 is still active, the terminal is transferred to the base station 2. Since the P_REV_EN_USO = 7 after the handover, the active data call can be identified by a 10 SR_ID. The terminal can initiate the use of a new SR_ID for active data call after handover using several schemes.

In a first scheme, after being transferred to the base station 2, this base station releases the active data call (not from SO 33) by sending a Release Order Message to the terminal. After receiving this message, the terminal enters an inactive state, listens to an Extended System Parameter Message (ESPM) with Packet Zone Identifier, sent from base station 2, and detects that the packet zone has changed. The terminal can then originate a new data call for SO 33 through a Source Message (ORM) with a proposed SR_ID. The base station 2 can accept the terminal request, in which case the SO 33 instance can be connected to the proposed SR_ID for the new data call.

In a second scheme, after the terminal has been transferred to base station 2, this base station 20 informs the terminal that the packet zone has changed by sending an Incoming Traffic System Parameters Message (ITSPM) with a new packet zone identifier (PZID), which indicates that the terminal is in a new packet zone with SO 33. The ITSPM can therefore be used to cause the terminal to re-originate the active data call using SO 33. The terminal receives the ITSPM and determines that it can update its service option. The terminal can then originate a new data call with SO 33 through an Enhanced Source Message (EOM) requesting an instance of SO 33 with a proposed SR_ID (which can be SR_ID = xoy, or a new SR_ID = z) . The base station 2 can accept the terminal request, in which case the SO 33 instance can be connected to the proposed SR_ID for the new data call.

The first and second schemes represent two different mechanisms to inform the terminal that it can update its service option for a data call. The ITSPM and the EOM in the second scenario 30 can be used if both the terminal and the base station are associated with P_REV ≥ 7 (since the EOM does not have support by a P_REV_EN_USO &lt;7).

FIG. 5 is a block diagram of a specific embodiment of various network elements in system 100. System 100 includes a system controller 102 (which may be a mobile switching center (MSC) or a base system controller (BSC) ) which communicates with several base stations 104 (only one base station is shown in FIG. 5, for the sake of simplicity). The system controller 102 is further interconnected with a public switched telephone network 502 (PSTN) (for example, for voice services) and a packet data service node 504 (PDSN) (for example, for packet data services ). The system controller 102 coordinates the communication between the terminals in the wireless communication system and the base stations 104, the PSTN 112 and the PDSN 114. 40

In the embodiment shown in FIG. 5, the system controller 102 includes a call control processor 512, a certain number of selector elements 514 (only one selector element is shown in FIG. 5 for simplicity) and a scheduler 516. The control processor 512 Call control controls call processing, service negotiation, service option negotiation, etc., for each terminal. The call control processor 512 can implement various handover techniques described above. A selector element 514 is assigned to control the communication between each terminal and one or more base stations (possibly of different P_REV). The scheduler 516 is coupled to all selector elements 514 within the system controller 102 and schedules data transmissions for packet data users. The memory unit 510 stores data and program codes used by the call control processor 512 and possibly other units within the system controller 102. fifty

In the exemplary design shown in FIG. 5, the base station 104 includes a certain number of channel elements 522a to 522n. A channel element 522 is assigned to process the communication for each terminal and is coupled to the associated selector element 514 also assigned to the terminal. Each selector element 514 receives from the planner 516 the plan for the assigned terminal (for example, the data transmission rate, the transmission power and the transmission time) and sends the plan to the associated channel element 522. The 522 channel element 522 receives, encodes and modulates (for example, covers and widens) data for the assigned terminal. The modulated data is then converted into one or more analog signals, quadratured modulated, filtered and amplified by means of a transmitter 524 (TMTR) to provide a direct modulated signal, which is then routed through a duplexer 526 and It is transmitted through a 528 antenna.

In the receiving terminal 106, the direct modulated signal is received by an antenna 550 and is routed to a front end unit 552. The front end unit 552 filters, amplifies, reduces the frequency and digitizes the received signal to provide samples. The samples are then demodulated by a 554 demodulator (Demod), decoded by a decoder 556 and provided to a data sink 558. The demodulation and decoding are performed in a complementary way to the modulation and coding performed at the base station.

A controller 560 directs the operation of various elements within terminal 106 and also controls call processing, service negotiation, service option negotiation, etc. For the terminal. The controller 560 can receive from the decoder 556 decoded data for messages transmitted by the base stations, and can also provide data for messages to be transmitted to the base stations. Memory unit 562 stores data and program codes used by controller 560 and possibly other units within terminal 106. 15

The transmission of data on the reverse link occurs in a similar manner. Data is provided from a data source 564, encoded by an encoder 566 and modulated by a modulator 568 (Mod) to provide modulated data. The modulated data is then converted into analog signals, the frequency is increased and are conditioned by the front end unit 552 to provide a reverse modulated signal, which is then transmitted through the antenna 550. twenty

At the base station 104, the inverse modulated signal is received by the antenna 528, routed through the duplexer 526 and provided to a receiver 530 (RCVR). The 530 receiver filters, amplifies, reduces the frequency and digitizes the received signal, and provides samples to the channel element 522 assigned to the terminal. The assigned channel element 522 demodulates and decodes the data samples in a manner complementary to the modulation and coding performed at the terminal. The decoded data can be provided to the selector element 514 25 assigned to the terminal, which can subsequently forward the data to another base station 104, to the PSTN 502 or to the PDSN 504. The design, as described above, supports both transmission Voice and packet data in the system. Other designs can also be contemplated, and are within the scope of the invention.

The processing (for example, coding and modulation) for direct and reverse links is defined in the particular CDMA standard or system being implemented (for example, IS-95A, IS-95B and IS-2000).

The techniques described herein to support a handover of a terminal between base stations of different protocol revisions can be implemented by various means. For example, these techniques can be implemented in hardware, software, or a combination thereof. For a hardware implementation, the elements used to support handover can be implemented within one or more specific application integrated circuits (ASICs), digital signal processors (DSP), digital signal processing devices (DSPD), devices Programmable logic (PLD), field programmable gate formations (FPGA), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions described in this document, or a combination thereof. 40

For a software implementation, techniques to support the transfer of a terminal between base stations of different protocol revisions can be implemented with modules (for example, procedures, functions, etc.) that perform the functions described in this document. Both the terminal and the base stations (or network) perform the appropriate actions to achieve the transfer. The software codes for the terminal and the network can be stored in memory units (for example, memories 562 and 45 510 in FIG. 5) and executed by processors (for example, controller 560 and control processor 512 call). Each memory unit may be implemented within the controller / processor or externally thereto, in which case the memory unit may be coupled in communication with it through various means, as is known in the technology.

The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications of these embodiments will be immediately apparent to those skilled in the technology, and the generic principles defined herein may apply to other embodiments. Therefore, it is not intended to limit this description to the embodiments shown herein, but will be granted the broadest scope of the appended claims. 55