U.S. patent application number 14/244682 was filed with the patent office on 2014-08-07 for managing a packet service call within mobile communications user equipment.
This patent application is currently assigned to Apple Inc.. The applicant listed for this patent is Apple Inc.. Invention is credited to Sanjeevi Balasubramanian.
Application Number | 20140220944 14/244682 |
Document ID | / |
Family ID | 47595093 |
Filed Date | 2014-08-07 |
United States Patent
Application |
20140220944 |
Kind Code |
A1 |
Balasubramanian; Sanjeevi |
August 7, 2014 |
MANAGING A PACKET SERVICE CALL WITHIN MOBILE COMMUNICATIONS USER
EQUIPMENT
Abstract
While a circuit service, CS, call is in progress, a request for
a packet service, PS, call is received from a background task that
is running in the mobile communications user equipment. In response
to receiving the request, several air interface parameters that
relate to the in-progress CS call are evaluated, in order to decide
whether or not to block the PS call based on the evaluation. Other
embodiments are also described and claimed.
Inventors: |
Balasubramanian; Sanjeevi;
(Santa Clara, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Apple Inc. |
Cupertino |
CA |
US |
|
|
Assignee: |
Apple Inc.
Cupertino
CA
|
Family ID: |
47595093 |
Appl. No.: |
14/244682 |
Filed: |
April 3, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13348520 |
Jan 11, 2012 |
8712425 |
|
|
14244682 |
|
|
|
|
Current U.S.
Class: |
455/414.1 ;
455/552.1 |
Current CPC
Class: |
H04W 4/16 20130101; H04W
48/16 20130101; H04W 76/16 20180201; H04W 88/06 20130101 |
Class at
Publication: |
455/414.1 ;
455/552.1 |
International
Class: |
H04W 4/16 20060101
H04W004/16; H04W 88/06 20060101 H04W088/06 |
Claims
1. A method for managing, within mobile communications user
equipment, a packet service, PS, call, the method comprising: while
a circuit service, CS, call is in progress, receiving a request for
a PS call from a background task running in the mobile
communications user equipment; in response to receiving the request
from the background task, evaluating a plurality of air interface
parameters relating to the in progress CS call; and deciding
whether or not to block the PS call based on the evaluation.
2. The method of claim 1, wherein the background task has a lower
priority for establishing a PS call than that of one other
background task which is also running in the mobile device.
3. The method of claim 1, wherein the plurality of air interface
parameters comprise received signal strength from a serving base
station and user equipment transmit power to the serving base
station.
4. The method of claim 3, further comprising: in response to
receiving the request from the background task, accessing a stored
history of PS call blocks by the mobile communications user
equipment, and wherein the decision whether or not to block the PS
call is further based on the stored history.
5. The method of claim 4, wherein the decision is to block the PS
call when a) received signal code power, RSCP, from the serving
base station is less than a predetermined threshold and EcNo is
less than a predetermined threshold, and b) the stored history
indicates that there have been fewer than a maximum number of PS
call blocks.
6. The method of claim 4, wherein the decision is to block the PS
call when a) user equipment transmit power is greater than a
predetermined threshold, and b) the stored history indicates that
there have been fewer than a maximum number of PS call blocks.
7. The method of claim 5, further comprising: starting a timer in
response to the decision to block the PS call; and upon expiry of
the timer, and the CS call being still in progress, evaluating a
plurality of air interface parameters relating to the in progress
CS call and then deciding whether or not to block the PS call based
on the evaluation.
8. The method of claim 6, further comprising: starting a timer in
response to the decision to block the PS call; and upon expiry of
the timer, and the CS call being still in progress, evaluating a
plurality of air interface parameters relating to the in progress
CS call and then deciding whether or not to block the PS call based
on the evaluation
9. The method of claim 4, wherein the decision is to allow the PS
call when one of a) received signal code power, RSCP, from the
serving base station is greater than a predetermined threshold and
b) EcNo is greater than a predetermined threshold, and user
equipment transmit power is less than a predetermined
threshold.
10. The method of claim 4, wherein the decision is to allow the PS
call when the stored history indicates that a maximum number of PS
call blocks have been reached.
11. The method of claim 9, further comprising resetting the stored
history to indicate there have been zero PS call blocks.
12. A mobile telephony device, comprising: a processor; and data
storage having stored therein a telephony module that, when
executed by the processor, manages a circuit service, CS, call that
is in progress; the data storage further having stored therein a
packet service, PS, call manager that, when executed by the
processor, receives a request for a PS call from a background task
running in the mobile device, and in response evaluates a plurality
of air interface parameters relating to the in progress CS call,
and then decides whether or not to block the PS call based on the
evaluation.
13. The device of claim 12, wherein the data storage has stored
therein further instructions that, when executed by the processor,
respond to the PS call request from the background task by
accessing a stored history of PS call blocks which have been made
by the device, and wherein the decision whether or not to block the
PS call is further based on the stored history.
14. The device of claim 13, wherein the decision is to block the PS
call when the processor evaluates the parameters and thereby
determines that a) received signal code power, RSCP, from the
serving base station is less than a predetermined threshold and
EcNo is less than a predetermined threshold, and b) the stored
history indicates that there have been fewer than a maximum number
of PS call blocks.
15. The device of claim 13, wherein the decision is to block the PS
call when the processor evaluates the parameters and thereby
determines that a) user equipment transmit power is greater than a
predetermined threshold, and b) the stored history indicates that
there have been fewer than a maximum number of PS call blocks.
16. The device of claim 14, wherein the data storage has stored
therein further instructions that, when executed by the processor,
start a timer in response to the decision to block the PS call, and
upon expiry of the timer, and the CS call being still in progress,
evaluate a plurality of air interface parameters relating to the in
progress CS call and then decide again whether or not to block the
PS call based on the evaluation.
17. The device of claim 12, wherein the decision is to allow the PS
call when the processor evaluates the parameters and thereby
determines that one of a) received signal code power, RSCP, from
the serving base station is greater a predetermined threshold and
b) EcNo is greater than a predetermined threshold, and user
equipment transmit power is less than a predetermined
threshold.
18. The device of claim 13, wherein the decision is to allow the PS
call when the stored history indicates that a maximum number of PS
call blocks have been reached.
19. The device of claim 17, wherein the data storage has stored
therein further instructions that, when executed by the processor,
reset the stored history to indicate there have been zero PS call
blocks.
20. A non-transitory machine-readable medium having stored therein
instructions that, when executed by a processor in mobile telephony
user equipment, control when a packet service, PS, call that is
requested by a task running in the user equipment is allowed to be
established during an in progress circuit service, CS, call,
wherein the instructions program the processor to respond to the PS
call request by evaluating a) a plurality of air interface
parameters relating to the in progress CS call and b) a stored
history of PS call blocks which have been made by the user
equipment, and then decide whether or not to block the PS call
based on the evaluation.
21. The machine-readable medium of claim 20, wherein the stored
instructions are such that the decision is to block the PS call
when the processor evaluates the parameters and thereby determines
that a) received signal code power, RSCP, from the serving base
station is less than a predetermined threshold and EcNo is less
than a predetermined threshold, and b) the stored history indicates
that there have been fewer than a maximum number of PS call
blocks.
22. The machine-readable medium of claim 20, wherein the stored
instructions are such that the decision is to block the PS call
when the processor evaluates the parameters and thereby determines
that a) user equipment transmit power is greater than a
predetermined threshold, and b) the stored history indicates that
there have been fewer than a maximum number of PS call blocks.
23. The machine-readable medium of claim 22, wherein the medium has
stored therein further instructions that, when executed by the
processor, start a timer in response to the decision to block the
PS call, and upon expiry of the timer, and the CS call being still
in progress, evaluate a plurality of air interface parameters
relating to the in progress CS call and then decide again whether
or not to block the PS call based on the evaluation.
24. The machine-readable medium of claim 20, wherein the stored
instructions are such that the decision is to allow the PS call
when the processor evaluates the parameters and thereby determines
that one of a) received signal code power, RSCP, from the serving
base station is greater than a predetermined threshold and b) EcNo
is greater than a predetermined threshold, and c) user equipment
transmit power is less than a predetermined threshold.
25. The machine-readable medium of claim 20, wherein the decision
is to allow the PS call when the stored history indicates that a
maximum number of PS call blocks have been reached.
26. The machine-readable medium of claim 25, wherein the medium has
stored therein further instructions that, when executed by the
processor, reset the stored history to indicate there have been
zero PS call blocks.
Description
RELATED APPLICATION
[0001] The instant application is a continuation application of,
and hereby claims priority to, pending U.S. patent application Ser.
No. 13/348,520, which is titled "Managing a Packet Service Call
within Mobile Communications User Equipment," by inventor Sanjeevi
Balasubramanian, which was filed on 11 Jan. 2012, and which is
incorporated by reference.
BACKGROUND
[0002] Mobile terrestrial communication networks can now provide
the user of a mobile device such as a cellular phone or a smart
phone both packet services and circuit services simultaneously. The
circuit service enables the user of a smart phone to participate in
delay sensitive multimedia communications, such as a live spoken
conversation, via a voice or video call with a far-end user. This
is referred to as a circuit service (CS) call. At the same time,
the smart phone can conduct a data session with a remote server to,
for instance, download a web page or upload its geo positional
location data, as enabled by a packet service (PS) call.
Simultaneous PS and CS calls are occurring more frequently as
mobile communication network providers are willing to provide more
services to their subscribers. When the mobile communications user
equipment is in an area where there is relatively poor radio
frequency (RF) coverage from a serving base station system, there
is a higher probability that an ongoing CS call will be dropped by
the network due to uplink loss, or by the user equipment due to
downlink loss. One particular scenario for a potential CS call drop
is where a CS call is in progress when a PS call is being
established that was requested by a background task running in the
user equipment.
SUMMARY
[0003] An embodiment of the invention is a method for managing,
within mobile communications user equipment, a packet service (PS)
call, so as to improve the retainability of an in progress circuit
service (CS) call, particularly when the user equipment finds
itself in a poor RF coverage area. The method includes receiving a
request to establish a PS call from a background task, while the CS
call is in progress. In response, a number of air interface
parameters that relate to the in progress CS call are automatically
evaluated, to decide whether or not to block the PS call. This
technique may be useful when the requesting background task has a
lower priority (for establishing a new PS call) than that of one
other background task, which may also be running in the user
equipment. Examples of such low priority background tasks include a
game application that has been moved into the background, a
location services task, and an email client in the background, all
of which may need to access a remote server over the Internet at
any given moment.
[0004] The decision whether or not to block the requested PS call
may be further based on a stored history of PS call blocks
performed by the user equipment. For instance, the decision may be
to block the PS call when received signal code power, RSCP, from
the serving base station is less than a predetermined threshold and
a parameter known as EcNo is also less than a predetermined
threshold, while the stored history indicates that there have been
fewer than a maximum number of PS call blocks. Alternatively, the
decision may be to block the PS call when user equipment transmit
power is greater than a predetermined threshold, and the stored
history indicates there have been fewer than the maximum number of
PS call blocks.
[0005] Another embodiment of the invention is a mobile telephony
device (e.g., a smart phone) that has a processor and data storage
in which are stored a telephony module and a PS call manager. The
telephony module (when executed by the processor) manages a CS call
that is in progress. The PS call manager may then receive a request
to establish a PS call from a background task running in the mobile
device, and in response evaluates several air interface parameters
that relate to the in progress CS call. On that basis, the PS call
manager then decides whether or not to block the PS call. The air
interface parameters may include received signal strength from a
serving base station, and user equipment transmit power to the
serving base station (in connection with the in progress CS call).
When the decision is to block the PS call, the PS call manager may
start a timer in (response to the decision to block the PS call).
Upon expiration of the timer, and the CS call being still in
progress, the PS call manager can evaluate the air interface
parameters again and then decide whether or not to continue to
block the PS call.
[0006] When the decision is to allow the PS call, because a stored
history indicates that a maximum number of PS call blocks have been
reached, then the PS call manager may reset the stored history to
indicate that there have been zero PS calls, in preparation for the
next PS call request coming from a background task.
[0007] The above summary does not include an exhaustive list of all
aspects of the present invention. It is contemplated that the
invention includes all systems and methods that can be practiced
from all suitable combinations of the various aspects summarized
above, as well as those disclosed in the Detailed Description below
and particularly pointed out in the claims filed with the
application. Such combinations have particular advantages not
specifically recited in the above summary.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The embodiments of the invention are illustrated by way of
example and not by way of limitation in the figures of the
accompanying drawings in which like references indicate similar
elements. It should be noted that references to "an" or "one"
embodiment of the invention in this disclosure are not necessarily
to the same embodiment, and they mean at least one.
[0009] FIG. 1 is a block diagram of a mobile communications network
showing a PS call and a CS call in progress simultaneously.
[0010] FIG. 2 is a block diagram of another mobile communications
network supporting simultaneous CS and PS calls in progress.
[0011] FIG. 3 is a combined software and hardware diagram of
relevant portions of a mobile station or mobile communications user
equipment, in accordance with an embodiment of the invention.
[0012] FIG. 4 is a flow diagram of an algorithm that can be
performed by a PS call manager running in the mobile communications
user equipment.
DETAILED DESCRIPTION
[0013] Several embodiments of the invention with reference to the
appended drawings are now explained. While numerous details are set
forth, it is understood that some embodiments of the invention may
be practiced without these details. In other instances, well-known
circuits, structures, and techniques have not been shown in detail
so as not to obscure the understanding of this description.
[0014] FIG. 1 is a block diagram of a mobile terrestrial
communications network showing a PS call and a CS call. The mobile
communication network includes a mobile station 2, in which the
embodiments of the invention are implemented. The mobile station 2
is also referred to as mobile communications user equipment or a
mobile telephony device. The device is a consumer electronics unit
that is typically purchased by a user who may also be a subscriber
to mobile communication services that are delivered via the
network. Examples include a cellular telephone, a smart phone, a
tablet computer, and a laptop or notebook computer. The device is
capable of two-way real-time voice communications, also referred to
as voice calls and video calls (e.g., cellular phone calls). Such
calls require that the network guarantee a quality of service (QoS)
in terms of reserving sufficient network resources so as to ensure
sufficiently short communications signal delay, in order to enable
a natural sounding spoken conversation between the user and another
user at a far-end of the communications network. The far-end user
may be conducting the conversation through, for instance, landline
telephone user equipment 15 which is an end node of a public
switched telephone network (PSTN) 9. Such voice or video calls are
examples of what are referred to here as circuit service (CS)
calls, because traditionally a voice call was guaranteed the needed
QoS by virtue of a dedicated circuit being assigned to the call by
Plain Old Telephone Service (POTS), and that was created through
which to connect the near-end and far-end user stations, for the
entire duration of the call.
[0015] A CS call as used here is a wireless service for delay
sensitive communications. CS calls are for applications that are
more sensitive to bit error rates and to variant routing delays.
Examples of such communications include two-way, real-time or live
voice telephony. As suggested above, a CS call may be a service
that can guarantee a fixed delay QoS. This is in contrast to a
packet service (PS) call as described below, a service which the
mobile station 2 is also capable of providing.
[0016] A PS call is a wireless service for delay tolerant Internet
Protocol (IP) applications, such as email, chat, multimedia message
service (MMS), MP3 streaming, multi-party gaming, electronic
banking and electronic commerce, wireless imaging, presence (e.g.,
using session initiation protocol (SIP) service), and GPS/location
based services. A PS call may not be able to guarantee a fixed
delay QoS. Note that in the network depicted in FIG. 1, the PS call
is entirely transported by a packet switched service in the packet
core network, where the content to be communicated to and from the
mobile station 2 is split into packets or segments and each segment
has its own header information; not so with the CS call (while it
is transported in the circuit core network). Another difference
between the CS and PS call services lies in their QoS.
[0017] The mobile communications network can provide CS and PS
calls that are in progress simultaneously. In other words, a user
of the mobile station 2 can participate in a spoken conversation
with the far-end user over the PSTN 9 (e.g., user of the landline
station 15), while at the same time send an update or notification
to a server 12 via the Internet 11. These may be, for instance,
notifications from a client or mobile application running in the
mobile station 2, that are directed to a game server, an instant
messaging server (e.g., where an end-user desktop 13 also contains
an instant messaging client that is alerted regarding the presence
of a peer instant messaging client running in the mobile station 2)
and a location services server.
[0018] To enable the provision of simultaneous PS and CS calls, the
mobile communications network may be in accordance with the
specifications provided by the third generation partnership project
(3GPP) under General Packet Radio Service (GPRS) and universal
mobile telecommunications system (UMTS). In this architecture, a
radio access network (RAN) 3 has an air interface to the mobile
station 2 that uses wideband code division multiple access (WCDMA),
and a predominantly wired interface to the packet and circuit cores
using asynchronous transfer mode (ATM) as the transport. The RAN 3
has several base transceiver stations (BTSs) also referred to as a
wideband BTS (WBTS) 5, or a Node B as described in the 3GPP
specifications. The WBTS 5 may support multipurpose wireless
solutions, including transceivers for GSM, enhanced data rates for
global evolution (EDGE), and microwave plesiochronous or
synchronous digital hierarchy interfaces (PDH or SDH). The radio
access network 3 also includes a base station controller or radio
network controller (BSC/RNC) 6 in which decisions for network
operation are made. It may contain a high-speed packet switch to
support a reasonable throughput of CS and PS traffic (e.g., voice
and data traffic). It is also responsible for control of all the
WBTSs that are connected to it, and maintains a link to the packet
and circuit cores, via a link to a media gateway (MGW) and a mobile
switching center server/visitor location register (MSC server/VLR)
7 for the circuit core, and a separate link to a serving GPRS
support node (SGSN) 8 for the packet core. Access to Internet
services is provided by a gateway GPRS support node 10.
[0019] The circuit core may include, in addition to the MSC
server/VLR 7, a high-speed data connection to a gateway MSC (GMSC)
4 which may be a gateway to a plain old telephone system analog
network in the PSTN 9. The circuit core may be based on a
traditional global system for mobile communications (GSM) core
network that is typically used for providing cellular voice
telephony services, while the packet core may be a general packet
radio service (GPRS) core network that provides data services
(traffic in the form of packets e.g., IPV4 or IPV6 packets, and
usually referred to as non-voice services). The GPRS core network
allows an existing GSM base station system infrastructure to be
reused, where the latter was originally designed for a GSM voice
network. GPRS traffic is redirected by the base station controller
or radio network controller 6 to the packet core via a serving GPRS
support node (SGSN) 8. The typical GSM functionality of the home
location register (HLR), equipment identity register (EIR), and
authentications center (AuC) are needed to support CS and PS calls
with the mobile station 2. Such GSM functionality may thus be
shared by the packet services so that a user of the mobile station
2 who is sending an email does not need their location information
handled any differently than when making a phone call.
[0020] The packet core contains the SGSN 8 which connects to the
radio access network 3 and performs authentication and mobility
management. An IP backbone connects the SGSN 8 to a gateway GPRS
support node (GGSN) 10 which is at the edge of and provides access
to services on the Internet 11. The Internet Protocol may be used
to connect the serving GPRS support node (SGSN) 8 with the gateway
GPRS support node (GGSN) 10, allowing data services such as email
or web browsing on the mobile station 2.
[0021] The traditional architecture of FIG. 1 has evolved into that
of FIG. 2, where the circuit core has been replaced with an IP
network infrastructure that is based around voice over IP (VoIP)
technology. The mobile communications network is now essentially
made of several IP clouds, which may be merged into a single IP
over ATM backbone as shown. The IP protocol thus extends across the
whole communications network all the way to the WBTS 5. In this
case, the home location register, visitor location register, and
EIR may be generalized and referred to as the HLR subsystem or home
subscriber server (HSS) 17. CS calls such as voice and video calls
are supported through the introduction of an IP multimedia
subsystem (IMS) 19. It should now be appreciated that while
originally the reference to a CS call referred to a communications
session that was established through a circuit core that was
separate from a packet core, the evolved mobile network depicted in
FIG. 2 uses the same core network infrastructure shown, including
the now shared components of the SGSN 8 and the GGSN 10, to support
both PS and CS calls simultaneously.
[0022] The radio access network (RAN) 3 provides a service
described as a radio access bearer (RAB) to enable the transfer of
user data between the mobile station 2 and the core mobile network.
For each user connection to the core network, a RAB is established
for transport of signaling or traffic. There may be multiple RABs
that have been requested and then set up. A RAB assignment request
is a message that initiates the establishment of a radio link and
associated radio bearers in the core network. The request also
contains the needed QoS parameters for the RNC to determine the
requisite resource allocation for the radio link and the other
requirements in order to meet the QoS. This is where a PS call may
be distinguished from a CS call, that is, in the form of two RABs
that have different QoS.
[0023] The mobile station 2 may be idle and is ready to connect to
the network, for example, in response to a page or to perform a
location update. After sending a connection request and receiving a
response set up message from the radio network controller 6, a
connection is established between the mobile station 2 and the RNC
6 such that the mobile station is now connected with the network.
Once the mobile device is thus connected with the mobile network,
it cannot start to send and receive data over the packet core until
it has established a session, which may be referred to as an active
packet data protocol context (PDP context). A PDP context is needed
when the user selects a particular service by, for instance,
scrolling through a menu that is being displayed in the mobile
station 2 and selecting an Internet application such as a Web
browser or a music streaming program. The PDP context activation
results in the mobile station 2 obtaining an IP address. A request
for an external network connection is passed from the mobile
station through the network, to the SGSN 8. The SGSN 8 then locates
the correct GGSN 10 which will be used to route data from the
mobile station to the correct external network (e.g., the
Internet). There may be more than one GGSN connected to the
external network for load sharing and a redundancy. Once a PDP
context has been activated in this manner (and the PS call is thus
said to be established), the user can then use the services
provided by an access point to the external network, in this
example the Internet, e.g. surfing the web, checking email, and
streaming music. The mobile station 2 may have several PDP contexts
that are active at any one time, with one IP address for each
primary PDP context that is activated.
[0024] Turning now to FIG. 3, a combined software and hardware
diagram of relevant portions of the mobile station 2, in accordance
within an embodiment of the invention, is shown. The diagram also
shows the situation where a CS call is in progress, meaning that
the CS call has already been setup and established between the near
end and far end devices (e.g., mobile station 2 and VOIP station
14), such that a live two-way voice conversation can be conducted
by the near end and far end users, respectively. A PS call manager
33 in the mobile station 2 has received a request for a PS call
from a background task 32 that is running in the mobile station 2.
There may be several background tasks 32_1, 32_2, . . . as shown.
The requesting background task 32 may be a game, a location
service, an e-mail client, or other background task that may need
access to an external network, i.e., outside the core mobile
network.
[0025] The PS call manager 33 can respond to the received PS call
request by either blocking the call (issuing a PS call block, which
may eventually make its way back to the requesting background task
32) or it may decide to send a PDP context request to service the
PS call request. This is depicted by the dotted lines in FIG. 3.
The PDP context request may be signaled to a conventional PS call
protocol stack 30, which may be present as part of the operating
system running in the mobile station 2 together with a CS call
protocol stack 31. The call protocol stacks 30, 31 may be part of a
3G-324M software tool kit that contains application programming
interfaces for developing software that enables packet service and
circuit service calls in a mobile station. It should be understood
that the PS call manager 33, including the capabilities described
below in connection with the algorithm of FIG. 4, may be supplied
as part of such a software tool kit to developers of software that
runs in a mobile station and that enables, for instance, the
telephony application 24 to manage all aspects of a CS call.
[0026] Upon receiving the PS call request, the PS call manager 33
may evaluate several air interface parameters that relate to the in
progress CS call, in order to decide whether or not to block the PS
call. In one embodiment, these air interface parameters may include
received signal strength from a serving base station, and user
equipment transmit power to the serving base station. Another air
interface parameter may be received signal code power. Such
parameters may be provided by a base band processor 28 and/or by a
radio transceiver 27. The base band processor 28 may be a GSM/UMTS
base band processor, or it may be a HSPA/EDGE multimedia base band
processor that interfaces with an EDGE/HSPA multi-mode, multi-band
cellular transceiver.
[0027] In addition to evaluating the air interface parameters, the
PS call manager 33 (upon receiving the PS call request) may access
a stored history of PS call blocks by the mobile station 2. Its
decision as to whether or not to block the current PS call is
further based on the stored history. Details of various algorithms
for the decision making process are given below in connection with
FIG. 4.
[0028] Still referring to FIG. 3, the mobile station 2 may include
a user interface touch screen 20 on which can be displayed several
graphical objects 21-23 during the in progress CS call. These
include a call identifier object 21, which in the case of an
outgoing call displays the name, telephone number or address of the
called party. Alternately, the call identifier object displays the
name, telephone number or address of the calling party in the case
of an incoming call. Also shown is an elapsed time object 22, which
indicates the elapsed time of the incoming call or outgoing call.
Finally, this being a touch screen user interface, there is a
keypad object 23, which contains several virtual buttons that are
typically present in a telephony handset including a mute button, a
speaker phone button, and a hang up or end button. As an
alternative to the touch screen 20, a separate display and keyboard
or keypad may be provided. A speaker 25 and microphone 26 may be
integrated within the housing of the mobile station 2, such as an
earpiece speaker or receiver that is located at one end of a
cellular or smart phone handset, and a primary or speaker
microphone at another end. Alternatively, the speaker 25 and
microphone 26 may be part of a headset that is communicatively
coupled to the handset via a cable connection or via a wireless
connection.
[0029] Turning now to FIG. 4, a flow diagram of an algorithm that
can be performed by the PS call manager 33 is shown. Performance of
this algorithm may occur in parts; in other words, not all of the
branches and conditions shown are required in each instance. The
process may be triggered by the incoming PS call request that is
received from the background task 32. This may be a low priority
background task, or a low priority request from a background task
(collectively referred to in FIG. 4 as a "low priority PS
background call request"), where the background task has a lower
priority for establishing a PS call than that of a foreground task
that may, or may not, be running in the mobile station 2. There may
also be at least one higher priority background task running in the
mobile station 2. As an alternative, the algorithm in FIG. 4 could
apply to any PS call request regardless of the priority of the
requesting background task.
[0030] Upon receipt of the PS call request, if there is no CS call
that is in progress (block 41), then the PS call may be allowed to
continue (block 42), i.e. the PS call manger 33 may send a PDP
context request through the PS call protocol stack 30 (see FIG. 3).
If, however, the PS call request is received during an ongoing CS
call (block 41), then one or more of the conditions indicated in
block 43 are evaluated and may result in the following outcomes. In
one outcome, the decision is to block the PS call (block 45) when
the following two conditions are satisfied: the measured received
signal code power, RSCP.sub.meas., from the serving base station is
less than a predetermined threshold (RSCP.sub.threshold) while
measured EcNo is also less than a predetermined threshold
(EcNo.sub.threshold); and the stored history of PS call blocks
indicates that there have been fewer than a maximum number of PS
call blocks. In another instance, the decision is to block the PS
call (block 45) when the following two conditions are satisfied:
user equipment transmit power (UETX) is greater than a
predetermined threshold (TX.sub.thres); and the stored history
indicates that there have been fewer than a maximum number of PS
call blocks. In both instances, when the decision is to block the
PS call (block 45), a timer may be started in response to the
decision to block the PS call, such that upon expiry of the timer,
and the CS call being still in progress, one or more air interface
parameters are reevaluated to decide whether or not to continue to
block the PS call. In other words, as recited in block 45, the PS
background call request is blocked for a fixed time interval, and
then the one or more conditions in block 43 are reevaluated after
the timer has expired (where the timer interval is indicated as
T.sub.block).
[0031] In another outcome, evaluation of the conditions in block 43
results in a decision to allow the PS call (block 42). In one
instance, this occurs when measured RSCP from the serving base
station is greater than its threshold or measured EcNo is greater
than its predetermined threshold, while the user equipment transmit
power UETX is less than its predetermined threshold. In another
outcome, the decision is to allow the PS call when the stored
history indicates that a maximum number of PS call blocks have been
reached. In both cases, where the decision is to allow the PS call
(block 42), the stored history may be reset to indicate that there
have been zero PS call blocks. Until that point, each time block 45
is reached, the variable that counts the number of call blocks
(N.sub.blocked) is incremented. The algorithm described above,
including its various outcomes, presents an efficient technique for
selectively blocking low priority PS background call requests, in a
manner that is believed to reduce the likelihood of dropped calls
due to multiple RABs (e.g., at least two that have different QoS)
being present simultaneously in the mobile station 2.
[0032] As explained above, an embodiment of the invention may be a
machine-readable medium (such as microelectronic memory) having
stored thereon instructions, which program one or more data
processing components (generically referred to here as "a
processor") to perform the digital operations described above in
connection with the PS call manager. In other embodiments, some of
these operations might be performed by specific hardware components
that contain hardwired logic (e.g., dedicated digital filter
blocks). Those operations might alternatively be performed by any
combination of programmed data processing components and fixed
hardwired circuit components.
[0033] While certain embodiments have been described and shown in
the accompanying drawings, it is to be understood that such
embodiments are merely illustrative of and not restrictive on the
broad invention, and that the invention is not limited to the
specific constructions and arrangements shown and described, since
various other modifications may occur to those of ordinary skill in
the art. For example, the mobile network architecture described in
FIG. 1 and FIG. 2 has a UMTS terrestrial radio access network and
UMTS cores (circuit and packet). The PS call manager may
alternatively or in addition be configured to manage PS calls in a
mobile station that complies with other popular mobile terrestrial
cellular network specifications in the industry. These include
radio interface technologies and core network architectures such as
IMT-Advanced (International Mobile Telecommunications Advanced)
featuring WiMax 2 as described in IEEE 802.16m, OFDMA (Orthogonal
Frequency Division Multiple Access), and LTE-Advanced (Long Term
Evolution) as described in 3GPP Technical Report (TR) 36.913 which
features the Evolved Packet Core (EPC) also known as the System
Architecture Evolution (SAE) core. The description is thus to be
regarded as illustrative instead of limiting.
* * * * *