BACKGROUND OF THE INVENTION [0002] The present invention generally relates to call handling in a communication network, and particularly relates to call handling for busy mobile stations where concurrent services are not supported.

[0003] Evolving wireless communication networks offer advanced packet data services along with legacy circuit-switched services. Packet data services include, for example, web browsing, streaming media, and email, while circuit-switched services include, for example, traditional low bit-rate voice and facsimile services usually associated with calls between subscribers on the Public Switched Telephone Network (PSTN) and subscribers operating in the wireless communication networks.

[0004] Several of the current wireless communication standards, such as the family of IS-2000 CDMA standards, include provisions for concurrent packet data and circuit- switched services. In a concurrent services environment where both the network and a particular mobile station support concurrent services, a user of the mobile station can send and receive voice calls while maintaining an active packet data connection with the network.

[0005] Despite such provisions in the standards, a great many existing wireless networks are not upgraded with concurrent services support, and a great many more existing mobile stations do not (and will not) support concurrent services. Lack of concurrent services support represents a challenge with regard to handling call termination and origination instances for busy mobile stations.

[0006] Broadly, mobile stations may be busy for a number of reasons. A mobile station may be busy in another voice call, busy in a packet data session, or busy in other non-voice calls that are not packet data calls in the strict sense. For example, a mobile station may be busy sending or receiving Position Location Determination (PLD) information, or busy sending or receiving Short Messaging Services (SMS) text or engaging in similar messaging activities. Where those services are allocated a dedicated traffic channel rather than an access channel, the mobile station is busy even though the mobile station user might not be aware of that condition.

[0007] Busy mobile stations pose potential service problems where concurrent service is not supported. In attempts to address the challenges presented in non- concurrent service scenarios, certain standards, such as the TIA-935 standard, define procedures for prioritizing circuit-switched calls over packet data calls. These procedures, referred to as Circuit-Switched Call Precedence Over CDMA Packet Data Session (CPOP), specify that if a (mobile station) user is engaged in a packet data call when an incoming voice call is received for that user, the network simply tears down the packet data connection and establishes a new connection for the incoming voice call.

One additionally may refer to the IS-2001 Inter-Operability for cdma2000 Access Network Interfaces standard that details such a prioritization approach as it is being considered by the standardization bodies.

[0008] This brute force approach provides for delivery of the incoming voice call but includes the inelegant, at least from the users'perspective, step of simply dropping the data connection in favor of terminating the incoming voice call at the mobile station.

Other types of communication networks, such as Wideband CDMA, may have similar call handling problems in non-concurrent service scenarios.

SUMMARY OF THE INVENTION [0009] The present invention comprises a method and apparatus providing improved call handling in a wireless communication network for non-concurrent service scenarios.

In general, the present invention sends an incoming voice call notification to mobile stations that are engaged in data calls. In one embodiment, such notification is sent to a mobile station using a traffic channel currently allocated to the data call and the incoming voice call is routed to voice mail or processed according to other desired call treatment.

Thus, the network provides an immediate indication that that the mobile station user has just missed an incoming voice call but does so by using the mobile station's existing traffic channel in a manner that does not disrupt the data call. The call notification sent to the mobile station can include calling party information, e. g., caller ID. The mobile station can be configured to store the information for later retrieval by the user in returning the missed call.

[0010] In another exemplary embodiment, the network is configured to attempt delivery of the incoming voice call by reusing communication resources already allocated to the data call such that signaling overhead is reduced. In such an embodiment, the network can reconfigure the mobile station's existing traffic channel to support voice traffic, and add associated voice processing needed, and then use the reconfigured/renegotiated traffic channel for delivering the incoming voice call to the mobile station.

[0011] Such renegotiation can be keyed to whether the user of the mobile station wishes to receive the incoming voice call in favor of the current data call. Thus, the network can determine that the mobile station is engaged in a packet data call, and send a notification message to the mobile station via control signaling on the data call's traffic channel, causing the mobile station to prompt the user. If a return response is received from the mobile station, indicating that the voice call is desired, the network renegotiates the traffic channel and ends or suspends the packet data call.

[0012] On the other hand, the data call can be a circuit-switched data call, such as Position Location Determination, SMS, etc. , that was not initiated by user-indeed the user may not be aware of the mobile station's busy condition. In such instances, the network simply renegotiates the traffic channel to support voice call delivery without prompting the user.

[0013] Thus, an exemplary method of call handling in a wireless communication network comprises receiving an incoming voice call for a mobile station that is busy in a data call, and sending an incoming call notification to the mobile station via signaling over an existing traffic channel allocated to the data call. The network can be configured to route the incoming voice call to voice mail in conjunction with sending the call notification to the mobile station, and can be configured to include calling party identification in the incoming call notification sent to the mobile station.

[0014] Further, if the network reconfigures a traffic channel from supporting a circuit- switched data call to supporting the incoming voice call, the network can, nonetheless, continue with the data call transaction via control signaling over the reconfigured traffic channel. That is, the network can continue with the data transaction by including associated signaling within the voice call traffic. In contrast, if the data call was a packet data call, the network ends or suspends the data transaction associated with the data call.

[0015] In one or more of its embodiments, the present invention can be implemented in networks and in mobile stations based on a variety of wireless communication network standards. Such standards include, but are not limited to, IS-2000 CDMA standards, and in other standards where non-concurrent services need to be reconciled for various busy-mobile call origination and termination scenarios.

BRIEF DESCRIPTION OF THE DRAWINGS [0016] Fig. 1 is a diagram of an exemplary wireless communication network in which the present invention can be embodied.

Figs. 2A and 2B are diagrams of processing logic for an exemplary embodiment of the present invention.

Figs. 3A and 3B are diagrams of processing logic associated with call notification delivery to a busy mobile station according to one embodiment of the present invention.

Figs. 4 and 5 are diagrams of exemplary Mobile Switching Center and Base Station processing logic associated with exemplary call notification and optional voice call delivery according to another embodiment of the present invention.

Fig. 6 is a diagram of exemplary mobile station processing logic according to one or more embodiments of the present invention.

Fig. 7 is a diagram of an exemplary mobile station that is configured to support one or more embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION [0017] Several developing wireless network standards provide support for concurrent services wherein a given mobile station simultaneously has both voice and packet data connections to the wireless network. Generally, the circuit-switched voice call is supported by the allocation of a fundamental channel (FCH) to the mobile station, and the one or more packet data connections are supported by the allocation of one or more supplemental channel (SCH).

[0018] Concurrent services must be supported by the network and by the mobile station. Thus, in many practical instances, concurrent services are not available because of the many existing networks and mobile stations do not support it. Even where concurrent service is supported, it is not always possible or desirable to use concurrent service in certain call handling scenarios.

[0019] For example, contemporary definitions of concurrent service provide for the simultaneous assignment of one fundamental channel and one or more supplemental channels, which implicitly limits concurrent services to concurrent voice-plus-packet- data. That is, circuit-switched voice service requires the allocation of a fundamental channel, leaving only data-oriented supplemental channels available for concurrent assignment to the mobile station.

[0020] However, there are non-voice data calls that are considered circuit-switched services and thus require the allocation of a fundamental (traffic) channel. This means that a conventional mobile station engaged in a non-voice circuit switched data call is unavailable for concurrent delivery of an incoming voice call because of the inability to assign another fundamental channel to support the required voice connection.

Examples of such non-voice data calls include calls associated with Position Location Determination (PLD), Short Message Service (SMS), Over-The-Air Service Provisioning and Parameter Administration (OTASP and OTAPA-see the TIA/EIA/IS-725-A standard). Another interesting characteristic of these types of non-voice data calls is that, oftentimes, a user of a mobile station busy in such services is unaware that his or her mobile station is engaged in a call with the network.

[0021] In general, the reader should understand that concurrent service may not be possible in certain scenarios, even if it is supported by the network and by the particular mobile station of interest. Where concurrent service is not supported or is not desirable, certain call handling dilemma are presented. For example, if a mobile station is busy in a packet data call, the network cannot deliver an incoming voice call to it without disrupting the packet data call. The earlier mentioned standard, IS-2001 Inter- Operability for cdma2000 Access Network Interfaces, gives priority to voice calls and thus specifies that the network will tear down an existing non-voice connection with a mobile station responsive to receiving an incoming (mobile terminated) voice call targeted to that mobile station.

[0022] The present invention provides improved call handling in that call scenario and in others where concurrent service is not possible or is not desired. Fig. 1 illustrates an exemplary wireless communication network 10 that is configured to provide improved call handling in non-concurrent service scenarios. Network 10 can be configured according to the IS-2000 family of standards, or according to other network standards as needed or desired. Those skilled in the art will appreciate that nomenclature for the illustrated network entities might vary according to the particular standard without departing from like functionality.

[0023] Network 10 comprises a Base Station (BS) 12 that includes a Base Station Controller (BSC) 14 and a Radio Base Station (RBS) 16. In practice, each BSC 14 supports one or more RBSs 16 and network 10 includes a plurality of BSs 12 to provide support over a desired service area or areas. Understanding the present invention does not, however, require the illustration of such details, and it should be understood that BS 12 could be configured differently without affecting the present invention.

[0024] An exemplary BSC 14 comprises call processing and interface circuits 18, e. g. , circuit and packet switching circuits and associated signal routing and processing circuits (microprocessors, etc. ), and a notification processor 20. Such processing circuits include, for example, voice encoders/decoders ("vocoders") that provide coding and decoding for over-the-air voice. Further, in an exemplary embodiment, the notification processor 20 comprises a microprocessor or other logic circuit that executes program instructions stored in a computer readable medium. Notification processor 20 can be implemented as a standalone microprocessor and memory subsystem within BSC 14, or it can be implemented using shared processing and memory resources.

[0025] BSC 14 communicates with and controls one or more mobile stations 22 through RBS 16. In turn, BSC 14 communicatively couples mobile station 22 to one or more external networks (and to other mobile stations 22 in network 10). For example, BSC 14 couples mobile station 22 through a Circuit Switched Core Network (CSCN) 24 to the Public Switched Telephone Network (PSTN) 26.

[0026] CSCN 24 comprises a Mobile Switching Center (MSC) 28 that provides circuit-switched incoming and outgoing call routing. MSC 28 includes call processing, switching, and interface circuits, and couples to the BSC 14 through a defined signaling/data interface (see, e. g., IS-2001 standard) that permits the MSC 28 and BSC 14 to provide inter-entity signaling to each other, as well as carry data between them.

CSCN 24 can include additional entities that are not shown for the sake of brevity, such as Home Location Registers (HLRs), Visitor Location Registers (VLRs), etc.

[0027] Providing further flexibility, BSC 14 couples mobile station 22 through a Packet Switched Core Network (PSCN) 30 to the Internet 32, or to other Public Data Networks (PDNs), private packet networks, etc. , as needed or desired. PSCN 30 includes a Packet Data Serving Node (PDSN) 34 to support packet data communications, and may include other entities as needed or desired. The call processing and interface circuits 18 of BSC 14 can include a Packet Control Function (PCF) that provides the Radio-Packet (RP) interface between communications being routed between BSC 14 and the PSCN 30. BSC 14 can be configured to communicate with a separate PCF via A8/A9 interfaces as specified in IS-2001.

[0028] Thus, network 10 provides voice and other circuit-switched call support for mobile station 22 and additionally provides packet-switched call support for mobile station 22. In this discussion, the term"call"is given broad scope and includes both data and non-data connections to network 10. Thus, unless specified otherwise, the term call means that the mobile station 22 is engaged in some type of connection with the network, be it circuit-switched voice, circuit-switched non-voice, packet data, or other.

[0029] Assuming that concurrent service is not supported either by the network or by the mobile station, or assuming that concurrent service in a specific call instance is not desired or is not possible, network 10 can be configured to execute program logic that implements the improved call handling of one or more exemplary embodiments of the present invention. Such processing logic can, for example, be implemented in MSC 28, or in BSC 14, or in a combination of MSC 28 and BSC 14 based on inter-entity signaling.

Additionally, as will be explained later, mobile station 22 can be configured with processing logic according to one or more embodiments of the present invention.

[0030] Figs. 2A and 2B illustrates exemplary program logic and method according to one embodiment of the present invention. Fig. 2A details exemplary mobile-terminated call handling from the network's perspective and Fig. 2B details mobile-originated call handling from the mobile terminal's perspective.

[0031] Mobile-terminated call handling processing begins in response to MSC 28 receiving an incoming voice call for mobile station 22 (Step 100). If the mobile station 22 is idle (Step 102), network 10 executes call delivery processing wherein it attempts to terminate the call to mobile station 22 (Step 104).

[0032] MSC 28 can determine whether mobile station 22 is busy by inspecting the associated VLR information or other data. If mobile station 22 is busy in a voice call, MSC 28 provides call handling as desired (Step 108). For example, the subscriber profile associated with mobile station 22 might indicate that a call waiting feature is enabled. If so, call waiting procedures can be executed. Otherwise, the call can be delivered to voice mail, a busy or unavailable indicator can be returned to the calling party, etc.

[0033] If the mobile station 22 is busy in a non-voice call, MSC 28 must determine whether to attempt call delivery (Step 110). Note that this operation might not be an explicit program logic operation-for example, MSC 28 can be configured always to attempt call delivery to non-voice busy mobile stations, or to make such attempt selectively based on provisioning data that identifies whether BSC 14 is configured to support such a delivery attempt, or based on receiving an indication from BSC 14 that it is so configured.

[0034] If no call delivery is to be attempted, MSC 28 simply can generate a Flash- With-information (FWI) message or the like to BSC 14 for delivery to the mobile station 22 via signaling on the mobile station's currently allocated traffic channel (Step 112).

The message can include, for example, caller identification information, or can simply provide an alert to the mobile station 22 that an incoming call was just missed.

Meanwhile, network 10 can provide whatever call treatment is desired for the incoming call. That is, MSC 28 can route the incoming call to voice mail, or it can return a busy indication to the calling party and drop the call (Step 112).

[0035] Thus, in the embodiment where call delivery is not attempted to the mobile station 22 when it is in a non-voice call, the user is nonetheless given a real-time alert that a party is attempting to call his or her mobile station. As noted, the alert message sent from the network 10 can include calling party information, and that data can be stored by the mobile station 22 for use in placing a return call. This would again allow the user to realize that someone is attempting to reach and free up his phone in case the caller tries again.

[0036] With this embodiment of the present invention, the mobile station user can remain engaged in a non-voice call, e. g. , a packet data call, and still be alerted to incoming voice calls. In contrast to the conventional approach, where the user either remains unaware of such calls, or such calls result in the data call being torn down, this embodiment of the present invention provides immediate call notification and permits the user to decide whether and when to return a missed voice call.

[0037] In another embodiment, network 10 is configured to attempt delivery of the incoming voice call (Step 110). In that case, network 10 can be configured to determine the nature of the non-voice call that mobile station 22 currently is engaged in. If mobile station 22 is engaged in a PLD, SMS, OTAPA, or other circuit-switched data call, it is likely that the user is unaware of the mobile station's busy status. These types of non- voice services are referred to herein as"Type 1"data services. In contrast, "Type 2" data services are packet data services such as web browsing, voice mail, streaming media, etc. , wherein the user almost certainly is aware that he or she is connected to the network 10.

[0038] How call delivery is attempted depends on whether the mobile station 22 is busy in a Type 1 or a Type 2 data call. BSC 14 can determine the call type by inspecting the Service Option (SO) connection of the mobile station 22, for example. If BSC 14 determines that the mobile station 22 is engaged in a Type 1 data call (Step 114), it reconfigures the mobile station's SO connection to support delivery of the voice call to the mobile station 22 (Step 116). BSC 14 adds vocoding resources as needed and signals MSC 28 to establish a data connection between them to carry the voice call traffic. Once the voice call is setup, BSC 14 alerts mobile station 22.

[0039] This all is explained in greater detail later herein but one should note that these operations permit the network 10 and the mobile station 22 to retain some or all of the communication resources, including traffic channels, that were allocated for the Type 1 data call for use in the voice call, thereby providing significant reductions in signaling.

That is, rather than tear down the mobile station's current connection, that connection is reused, with reconfiguration as needed, to support the incoming voice call.

[0040] Additionally, reconfiguring the mobile station's service connection from data to voice and keeping (reusing) the existing traffic channel reduces call setup (no paging or channel assignment needed), and leads to increased call setup reliability and security.

These latter benefits accrue because, with the present invention, the signaling messages associated with call notification and call delivery occur over the mobile station's existing dedicated traffic channel, which is a reliable and, possibly, secure, communication link. In a conventional network, such signaling occurs over common paging/access channels, which are shared and not power controlled, and which are more prone to message collisions/failures on the air interface.

[0041] In another advantage, network 10 can, in many instances, continue the operations that were being supported by the data call using, for example, blank-and- burst or dim-and-burst signaling over the same traffic channel as being used to carry the voice call. That is, although the existing traffic channel is changed over to voice service, the network 10 can be configured, where appropriate, to continue the prior data transaction over the voice channel.

[0042] Returning to the logic flow, if the mobile station 22 is busy in a Type 2 data call (Step 114) then most likely the user has initiated the connection to network 10, or at least is aware of it. In that case, it is appropriate to signal the mobile station 22 to prompt its user as to whether acceptance of the incoming voice call is desired (Step 120). If a negative response is received or no response is received, call delivery is not attempted, the ongoing Type 2 data call is left undisturbed, and desired call treatment is applied to the incoming voice call (Step 122). For example, the voice call can be routed to voice mail or a busy indicator can be returned to the calling party. If a positive response is received, e. g. , the mobile station 22 timely returns a response message, the mobile station's service connection is reconfigured for voice service and the mobile station 22 is alerted when the voice call is setup (Step 116).

[0043] In contrast to the above network-based processing logic, Fig. 2A additionally illustrates an exemplary processing method that can be implemented in the mobile station 22 to handle mobile-originated call processing (Step 124). Here, it is assumed that a user of the mobile station 22 has attempted to originate a voice call while the mobile station is busy. Practically, this means that mobile station 22 was busy in a Type 1 data call that the user was unaware, i. e. , it is assumed that the user will not simply begin dialing an outgoing number if the mobile station is engaged in Type 2 data call, e. g. , web browsing, etc. , or if it already is engaged in a voice call.

[0044] Thus, continuing with Fig. 2B, the mobile station 22 receives dialing input (e. g. , digits plus the"send"command) from its user and determines whether it is busy in a Type 1 data call (Step 126). If not (and assuming that it is otherwise idle), mobile station 22 executes call origination as would a conventional mobile terminal (Step 128).

However, if mobile station 22 recognizes that it is busy in a Type 1 data call, it sends the dialing information as a FWI message or the like on the traffic channel currently allocated to its ongoing data call (Step 130).

[0045] That is, the mobile station's processing logic is configured not to tear down the existing connection and execute a conventional call origination but rather to send the dialing information as signaling information on its currently allocated traffic channel and then wait for the network 10 to establish the voice connection using that existing channel (Step 132). Of course, mobile station 22 can be configured to provide the user with a dialing indication that is the same as or similar to what it would provide during conventional (normal) call origination, such that dialing out while busy in the data call appears like a conventional dialing process from the user's perspective. That is, mobile station 22 can be configured to provide its user with the same or similar call dialing indications as it would had the user dialed out when the mobile station 22 was idle and a conventional mobile-originated call was initiated.

[0046] Turning to Figs. 3A and 3B, one sees an illustration of exemplary processing logic at the MSC 28 and at the mobile station 22, respectively, supporting the no-call- delivery-attempt logic introduced in Fig. 2A at Step 112. As noted, the no-delivery processing option can be configure via appropriate provisioning information at MSC 28 or elsewhere in network 10, or can be dynamically selected by MSC 28. In either case, Fig. 3A illustrates logic that can be implemented in hardware, software, or some combination thereof, at MSC 28.

[0047] Processing begins with MSC 28 receiving an incoming voice call for mobile station 22 (Step 140) and determining whether the mobile station 22 is idle (Step 142).

As noted, MSC 28 can be configured to make the busy/non-busy determination by examining the VLR record. If the mobile station 22 is idle, conventional call delivery is attempted (Step 144). If, however, mobile station 22 is not idle but rather is voice busy (Step 146), MSC 28 provides call handling as desired (Step 148). As noted, such call handling can comprise voice mail delivery, call waiting delivery, or simply comprise returning a busy indicator to the calling party.. Which treatment is provided can depend on subscriber profile information, provisioning defaults, etc.

[0048] if the mobile station 22 is non-voice busy (Type 1 or 2 data call), MSC 28 sends a FWI message to BSC 14, preferably including calling party identification information, and provides desired call handling, e. g. , voice mail, busy, etc. (Step 150).

Note that BSC 14 delivers the FWI message to mobile station 22 via control signaling on the mobile station's currently allocated traffic channel.

[0049] Fig. 3B illustrates the corresponding mobile station logic. Mobile station 22 receives the incoming FWI via control signaling on its currently allocated traffic channel (Step 160). Mobile station 22 can be configured to store the notification message information (Step 162) and alert the user (text display, audio, etc. ) and continue with its current data call (Step 164). Later, at the user's discretion, the stored information can be used by mobile station 22 in originating an outgoing call to the earlier calling party (Step 166).

[0050] While Figs. 3A and 3B illustrated exemplary non-delivery logic, Figs. 4 and 5 illustrate exemplary processing logic for MSC 28 and BSC 14, respectively, in configurations where call delivery is attempted to mobile station 22. In Fig. 4, processing begins with the MSC 28 receiving an incoming voice call from the PSTN, from another MSC, etc. (Step 170).

[0051] MSC 28 determines whether the mobile station is idle (Step 172). It can make that determination by, for example, an examination of the VLR record. If the mobile station is idle, MSC 28 undertakes mobile-terminated call delivery procedures (Step 174). If the mobile station is busy, e. g. , on a traffic channel (not idle), MSC 28 sends a FWI message to BSC 14 to initiate incoming call notification and attempted delivery (Step 176). Coincident with this, MSC 28"parks"the incoming voice call and starts an internal timer, TPARK, that it uses to time-out the call delivery attempt while waiting for return signaling from BSC 14. During call parking, MSC 28 can be configured to provide a ringing or other indication to the calling party.

[0052] If TPARK expires before return signaling from BSC 14 (Step 178), MSC 28 provides desired call handling for the incoming call, e. g. , voice mail, etc. (Step 180). On the other hand, if a FWI message is returned by BSC 14 before expiration of TPARK (Step 182), this is an indication that the mobile station was voice busy and thus MSC 28 executes call waiting, call conferencing, or other processing as indicated by subscriber profile or provisioning information (Step 180).

[0053] Thus, where call delivery is to be attempted, MSC 28 sends a FWI message to BSC 14 to trigger call notification to the mobile station 22. If the mobile station 22 already is in a voice call, MSC 28 receives an appropriate FWI return message from the BSC 14. However, if the mobile station is non-voice busy (Type 1 or 2 data call), MSC 28 receives an Additional Services Request (ASR) message back from BSC 14 rather than a return FWI message (Step 184). The return ASR message is required because the mobile station's existing SO connection is non-voice and must be changed or reconfigured to reuse the mobile station's existing traffic channel for the incoming voice call. Thus, the ASR message serves the two-fold purpose of alerting MSC 28 to continue with the voice call delivery attempt and to add/reconfigure call resources as needed to support changing over the current data connection to voice service.

[0054] If an ASR message is received, MSC 28 proceeds with call setup and service swapping/reconfiguration as needed to reuse the communication resources assigned to the mobile station's existing data call (Step 186). To do so, MSC 28 sets up a voice connection between it and BSC 14 and triggers vocoder assignment and SO connection at BSC 14 by sending an Assignment Request (AR) message to BSC 14. In response, BSC 14 establishes a new SO connection for mobile station 22 to support the voice call.

Once BSC 14 renegotiates the traffic channel, it returns an Assignment Complete (AC) message to MSC 28 to indicate that mobile station 22 is ready for the voice call. (Note that BSC 14 can provide an alert, e. g. , ringing, to mobile station 22.) [0055] When the mobile station user answers the voice call, mobile station 22 returns a connect order to BSC 14, and BSC 14 in turn sends a connect message to MSC 28 indicating that mobile station 22 has answered the call. At this point, mobile station 22 is on the voice call with the calling party. The disposition of the mobile station's prior data call depends on its type and is explained in the detailed presentation of exemplary BSC processing immediately below.

[0056] After call delivery, MSC 28 updates the"call state"of mobile station 22 to record the fact that the mobile station 22 is now in voice service. For example, MSC 28 can be configured to update the VLR record. Updating the call state ensures that a subsequent incoming voice call while the mobile station 22 is still voice busy can be properly handled by MSC 28 according to call waiting or other voice-oriented call handling.

[0057] Fig. 5 illustrates exemplary BSC processing supporting attempted voice call delivery when mobile station 22 is busy. BSC 14 receives a FWI message from MSC 28 as an incoming call indication (Step 190). BSC 14 determines whether mobile station 22 is busy in a voice call (Step 191) and, if so, processing proceeds with call waiting procedures or other exemplary voice busy call treatment (Step 193). With call waiting, BSC 14 would simply forward the FWI message to mobile station 22, and relay any return response to the MSC 28 for call handling.

[0058] If, however, the mobile station is not voice busy but rather is busy in a data call, BSC 14 determines whether mobile station 22 is engaged in a Type 1 or Type 2 data call (circuit-switched data versus packet data) (Step 192). If the mobile station is engaged in a Type 1 data call, there is no need to alert the mobile station user before attempting call delivery, since the user likely is unaware of the busy condition.

Therefore, BSC 14 does not send a FWI message to mobile station 22 but rather immediately sends an ASR message to MSC 28 to proceed with call setup, such as setting up a BSC-MSC connection for voice bearer transport, setting up PSTN connections as needed, etc.

[0059] BSC 14 also reconfigures the mobile station's service option by, for example, adding vocoder resources to support voice processing and renegotiating the existing traffic channel for voice call use to support mobile termination of the voice call (Step 194). Note that because the ASR message is generated by the BSC 14 without mobile origination or paging input from mobile station 22, BSC 14 can be configured to request default voice service options, e. g. , EVRC, 8K or 13K vocoding. Such defaults can be renegotiated after the voice call is connected. Alternatively, MSC 28 can propose the service option to be used in its return assignment request based on, for example, subscriber profile or other information.

[0060] Regardless, BSC 14 proceeds with call setup after sending the ASR message by waiting for a corresponding AR message back from the MSC 28. Upon receipt of that return message, BSC 14 renegotiates the channel as needed and can provide an alert indication to the mobile station 22 so that it can provide its user with an incoming call indication, e. g. , ringing or other indicator (Step 196).

[0061] Service negotiation between the BSC 14 and the mobile station establishes a Service Configuration for supporting the incoming voice call. The Service Configuration identifies parameters and attributes used by the mobile station 22 and the BSC 14 that enables each of them to interpret the traffic channel frames.

[0062] Once the voice call is connected on the mobile station's existing traffic channel, network 10 can continue with the transaction being conducted in the prior Type data call. For example, if the mobile station 22 was engaged in a PLD or SMS transaction when the voice call came in, data associated with that transaction can continue via control signaling on the reconfigured traffic channel. In this manner, then, network 10 can be configured to complete the prior data call transaction by mixing control signaling in with voice traffic. As noted, such control signaling can be by blank- and-burst or dim-and-burst signaling on the traffic channel.

[0063] Rather than Type 1 data service, if the mobile station 22 is busy in a Type 2 data call (Step 192), then it is appropriate to notify the mobile station user as to the presence of the incoming voice call but leave it to the user's discretion as to whether the data call will be interrupted in favor of receiving the voice call. Thus, where BSC 14 detects that mobile station 22 is busy in a Type 2 data call, it sends an FWI message to mobile station 22 (Step 198) indicating that a return response should be provided as indication of the user's desire to receive the incoming voice call. BSC 14 can run one or more timers while waiting for the mobile station's return response (Step 200), and the failure to timely receive such response is taken as an indication that call delivery is not desired. Thus, BSC 14 can timeout its call delivery attempt (Step 202), which allows the earlier described TPARK timer in MSC 28 to expire, leading to the voice call being dropped, routed to voice mail, or other as desired.

[0064] If, however, BSC 14 receives a timely FWI message in return from mobile station 22, it takes that as an indication that the call delivery attempt should proceed.

Thus, BSC 14 sends an appropriately configured ASR message to MSC 28 and proceeds with reconfiguration, etc. , as described above-see Steps 194 and 196.

[0065] However, note that unlike a Type 1 data call, a Type 2 data call cannot be continued on the current traffic channel once it has been reconfigured for use in the voice call. Therefore, BSC 14 can be configured to signal the PCF as to whether the now-interrupted packet data call should be placed in dormancy or released. That is, the mobile station's packet data session can be preserved for a time in case the user wishes to resume the packet data call after ending the voice call. Dormancy or release can be signaled via the BSC's A8/A9 interface to the PCF.

[0066] Further, note that even where network 10 is configured to attempt voice call delivery to mobile stations busy in non-voice calls, provisioning or other data, e. g., subscriber profiles, can be used to control such attempts. For example, the network 10 can be configured such that a mobile station user can dynamically select whether call delivery is to be attempted. In that manner, voice call delivery could be disabled for a data call of particular importance to the user, or for a period of time (hours, days, etc.) and then re-enabled by the user. Alternatively, the mobile station 22 can be configured to include processing logic to enable or disable call delivery attempts, such as by ignoring call delivery attempt message from network 10.

[0067] Complementing the above exemplary MSC/BSC program logic, Fig. 6 illustrates exemplary mobile station processing logic in support of such call-delivery- attempt methods. While Fig. 6 illustrates user-prompt based call delivery, it should be noted that if the mobile station 22 is busy in a non-voice data service such as PLD or SMS, i. e. , a non-voice circuit-switched data service, then the MSC's FWI call notification message sent to BSC 14 is not forwarded by BSC 14 to mobile station 22 so that the user is not prompted regarding voice call delivery.

[0068] Rather, as explained, BSC 14 requests voice service from the MSC 28 and reconfigures the mobile station's service connection for voice service, including performing service renegotiation with the mobile station 22. That is, BSC 14 and the mobile station 22 signal each other as needed to renegotiate the traffic channel for use in supporting the voice call. Then, when BSC 14 alerts mobile station 22 that the voice call is setup, mobile station 22 answers the voice call by sending a connect order or the like to BSC 14.

[0069] As Fig. 6 illustrates, exemplary processing can be different where the mobile station is engaged in a packet data call because the mobile station user might want to retain the data call rather than receive the incoming voice call. Thus, in an exemplary packet data busy scenario, BSC 14 attempts to determine whether the mobile station user wishes to receive the incoming voice call by sending a call notification to the mobile station 22, e. g. , by sending a FWI message to mobile station 22 responsive to receiving the FWI message from MSC 28.

[0070] Thus, processing begins assuming that mobile station 22 is busy in a packet data call and receives a FWI message from BSC 14 (Step 210). In response to receiving the FWI message, mobile station 22 prompts the user to indicate whether reception of the voice call is desired (Step 212). If the user does not accept (Step 214), mobile station 22 continues with the current data service (Step216). Note that network 10 can timeout the call delivery attempt based on not receiving a return response from the mobile station 22.

[0071] If the user accepts, mobile station 22 returns a FWI message to BSC 14 (Step 218) and proceeds with renegotiation and call acceptance as explained earlier herein (Step 220). As part of that processing, the mobile station 22 and BSC 14 renegotiate the service connection to reuse the existing dedicated traffic channel for the voice call, and then the mobile station 22 waits on an alert message from the BSC 14 indicating that the voice call is setup. That alert can be used to trigger a ringing indicator or other alert to the user of mobile station 22.

[0072] In prompting the user, mobile station 22 can be configured to provide an audible prompt, a visible prompt, or both, to alert the user regarding the incoming voice call. For example, mobile station 22 can beep, can display a text message, can vibrate, or perform any combination of alert functions. If calling party identification information was included in the incoming FWI message, mobile station 22 can display that information to the user.

[0073] Fig. 7 illustrates an exemplary mobile station 22 that can be configured to support the present invention in any of its embodiments. Mobile station 22 comprises a receiver circuit 300, a transmitter circuit 302, a signal processing circuit 304, a system control circuit 306, user interface circuits 308, memory/storage devices 310, and an antenna assembly 312, including a duplexer/switch and transmit/receive antenna.

[0074] Signal processing circuit comprises one or more signal processors, e. g., DSPs, ASICs, FPGAs, etc. , that provide receive and transmit signal processing functions, such as encoding/decoding, error detection, etc. Note that some circuit elements in the receiver and transmitter circuits 300 and 302 can overlap with or be integrated with the signal processing circuits 304.

[0075] System control circuit 306 comprises a microprocessor or other logic circuit, and can be integrated with the processing circuits of circuit 304. System control circuit 306 provides overall device control processing and manages the user interface 308, which can comprise display screens, keypads, microphones, loudspeakers, etc.

[0076] Memory/storage devices 310 comprise one or more memory circuits that individually or in shared fashion provide program instruction and data storage for the processing and control circuits 304 and 306. Note that these memory circuits can be integrated within the processing circuits themselves.

[0077] Regardless, exemplary embodiments of mobile station processing logic can be embodied as a computer program comprising stored instructions in memory/storage devices 310 that, in this context, serve as a computer readable medium for storing such instructions. Of course, those skilled in the art will appreciate that like functionality can be provided in hardware-based logic circuits, or in a mix of hardware and software.

Further, those skilled in the art should appreciate that as used herein the term mobile station broadly refers to a range of wireless communication devices, including, but not limited to, cellular radiotelephones.

[0078] Further, it should be understood that the exemplary call handling methods discussed herein and illustrated in the accompanying figures can be implemented in hardware, software, some combination thereof. In one exemplary embodiment, BSC 14 includes one or more microprocessors and supporting circuits (e. g. , memory, interface, etc. ) that implement exemplary voice call notification and delivery methods based on executing program instructions comprising a computer program stored in a computer readable medium. Likewise, in an exemplary embodiment, MSC 28 comprises one or more microprocessor-based circuits or like processing logic, including supporting memory devices, to execute stored program instructions that implement exemplary voice call notification and processing in accordance with one or more embodiments of the present invention.

[0079] However, it should be understood that such details can be varied according to needs or desires. Indeed, the present invention is not limited these or any of the foregoing exemplary details but rather is limited only by the following claims and their reasonable equivalents.