U.S. patent application number 14/617603 was filed with the patent office on 2015-06-25 for deactivating existing bearer/context for emergency bearer establishment.
This patent application is currently assigned to BROADCOM CORPORATION. The applicant listed for this patent is BROADCOM CORPORATION. Invention is credited to Marko T. AKSELIN, Hannu P. HIETALAHTI.
Application Number | 20150181404 14/617603 |
Document ID | / |
Family ID | 45508897 |
Filed Date | 2015-06-25 |
United States Patent
Application |
20150181404 |
Kind Code |
A1 |
HIETALAHTI; Hannu P. ; et
al. |
June 25, 2015 |
DEACTIVATING EXISTING BEARER/CONTEXT FOR EMERGENCY BEARER
ESTABLISHMENT
Abstract
A method, user equipment and non-transitory computer readable
memory for establishing an emergency service using a wireless
network includes unilaterally deactivating, at the user equipment
when the user equipment needs to establish an emergency service, at
least one active context with the wireless network without
deactivating at least one other active context. Thereafter
directing to the wireless network, a request to establish the
emergency service that identifies the emergency service and one or
more contexts that remain active after the unilateral deactivation
of the at least one active context by the user equipment,
synchronizing, in response to and based on the request, current
context status information of the user equipment with the wireless
network, and then establishing the emergency service using the
wireless network with which the active context was deactivated.
Inventors: |
HIETALAHTI; Hannu P.;
(Kiviniemi, FI) ; AKSELIN; Marko T.; (Oulu,
FI) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
BROADCOM CORPORATION |
IRVINE |
CA |
US |
|
|
Assignee: |
BROADCOM CORPORATION
IRVINE
CA
|
Family ID: |
45508897 |
Appl. No.: |
14/617603 |
Filed: |
February 9, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13922862 |
Jun 20, 2013 |
8953575 |
|
|
14617603 |
|
|
|
|
13307386 |
Nov 30, 2011 |
8477752 |
|
|
13922862 |
|
|
|
|
Current U.S.
Class: |
455/404.1 |
Current CPC
Class: |
H04W 4/90 20180201; H04W
60/06 20130101; H04W 76/10 20180201; H04W 76/50 20180201 |
International
Class: |
H04W 4/22 20060101
H04W004/22; H04W 76/02 20060101 H04W076/02 |
Foreign Application Data
Date |
Code |
Application Number |
Nov 29, 2011 |
GB |
1120537.4 |
Claims
1-24. (canceled)
25. A method, comprising: deactivating a first active context with
a wireless network, by a user equipment, while maintaining a second
context as active, responsive to a request to establish an
emergency service; and transmitting a request to establish the
emergency service to the wireless network, by the user equipment,
the request identifying the emergency service and the active second
context.
26. The method of claim 25, further comprising establishing the
emergency service, by the user equipment, using the wireless
network with which the first context was deactivated.
27. The method of claim 25, wherein deactivating the first active
context is performed unilaterally.
28. The method of claim 25, further comprising transmitting an
emergency attach request to the wireless network, by the user
equipment, responsive to the local deactivation clearing resources
used for active packet domain communication.
29. The method of claim 25, wherein deactivating the first active
context further comprises transmitting a deactivation message to
the wireless network explicitly indicating the first context as a
deactivated context.
30. The method of claim 29, wherein transmitting the deactivation
message to the wireless network is performed subsequent to
transmission of the request to the wireless network to establish
the emergency service.
31. The method of claim 29, wherein the request to establish the
emergency service transmitted to the wireless network comprises a
SERVICE REQUEST and the deactivation message transmitted to the
wireless network comprises one of a PDN CONTEXT DEACTIVATION or a
PDN DISCONNECT REQUEST including a cause indicator explicitly
identifying the service as an emergency service.
32. The method of claim 31, wherein the SERVICE REQUEST is an
EXTENDED SERVICE REQUEST.
33. The method according to claim 25, further comprising:
establishing packet data network services with the second context
for Internet protocol multimedia subsystem signaling; establishing
an emergency session with an Internet Protocol multimedia
subsystem; and activating a voice data context for the established
emergency session.
34. The method of claim 25, further comprising synchronizing
current context status information of the user equipment with the
wireless network.
35. A system, comprising: circuitry configured to unilaterally
deactivate a first active context with a wireless network while
maintaining a second context as active, responsive to a request to
establish an emergency service; and a transmitter configured to
transmit, to the wireless network, a request to establish the
emergency service, the request identifying the emergency service
and the active second context.
36. The system of claim 35, wherein the circuitry is further
configured to establishing the emergency service using the wireless
network with which the first context was deactivated.
37. The system of claim 35, wherein the circuitry is configured to
deactivate the first active context unilaterally.
38. The system of claim 35, wherein the transmitter is further
configured to transmit an emergency attach request to the wireless
network, responsive to the local deactivation clearing resources
used for active packet domain communication.
39. The system of claim 35, wherein the transmitter is further
configured to transmit a deactivation message to the wireless
network explicitly indicating the first context as a deactivated
context.
40. The system of claim 39, wherein the transmitter is further
configured to transmit the deactivation message subsequent to
transmission of the request to the wireless network to establish
the emergency service.
41. The system of claim 39, wherein the transmitter is further
configured to transmit, to the wireless network, a SERVICE REQUEST,
and one of a PDN CONTEXT DEACTIVATION or a PDN DISCONNECT REQUEST
including a cause indicator explicitly identifying the service as
an emergency service.
42. The system of claim 41, wherein the SERVICE REQUEST is an
EXTENDED SERVICE REQUEST.
43. The system of claim 35, wherein the circuitry is further
configured for: establishing packet data network services with the
second context for Internet protocol multimedia subsystem
signaling; establishing an emergency session with an Internet
Protocol multimedia subsystem; and activating a voice data context
for the established emergency session.
44. A non-transitory computer-readable storage medium comprising a
set of computer-readable instructions stored thereon, which, when
executed by a processing system, cause the processing system to
perform the steps of: deactivating a first active context with a
wireless network, by a user equipment, while maintaining a second
context as active, responsive to a request to establish an
emergency service; and transmitting a request to establish the
emergency service to the wireless network, by the user equipment,
the request identifying the emergency service and the active second
context.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This is a Continuation of U.S. patent application Ser. No.
13/307,386, filed Nov. 30, 2011, which in turn claims the benefit
under 35 U.S.C. .sctn.119 of GB 1120537.4, filed Nov. 29, 2011, the
entire disclosure of each of which is incorporated herein by
reference.
TECHNICAL FIELD
[0002] The exemplary and non-limiting embodiments of this invention
relate generally to wireless communication systems, methods,
devices and computer programs, and more specifically relate to
establishing wireless emergency services particularly when too many
resources are in use for non-emergency purposes.
BACKGROUND INFORMATION
[0003] The following abbreviations that may be found in the
specification and/or the drawing figures are defined as
follows:
[0004] 3GPP third generation partnership project
[0005] DL downlink
[0006] EPS evolved packet system
[0007] EUTRAN evolved UTRAN
[0008] GPRS general packet radio service
[0009] IMS Internet protocol multimedia subsystem
[0010] PDN packet data network
[0011] PDP packet data protocol
[0012] PS packet switched (domain)
[0013] QCI quality class indicator
[0014] RAT radio access technology
[0015] RR radio resource
[0016] RRC radio resource control
[0017] UE user equipment
[0018] UL uplink
[0019] UTRAN universal terrestrial radio access network
[0020] VoIP voice over Internet protocol
[0021] IMS services such as IMS VoIP use a PS domain bearer for PS
connectivity in the serving network. IMS voice emergency sessions
also use PS domain bearers (see 3GPP TS 23.060 v10.5.0 and 3GPP TS
23.401 v10.5.0). The PS domain provides the bearer as PDN
connections that consist of one or more contexts as detailed at
3GPP TS 23.401 v10.5.0. "Contexts" in the GPRS radio access
technology refers to PDP contexts, and in the EPS radio access
technology refers to EPS bearer contexts. 3GPP TS 24.008 v10.4.0
and 3GPP TS 24.301 v10.4.0 detail that the UE may support a maximum
of 11 simultaneous contexts. This is the maximum allowed by the
3GPP system and different UE models and manufacturers may support
less than the maximum 11 contexts. For example, EUTRAN category 3
devices require only eight contexts. Certain other implementation
reasons may leave a UE with the capacity to support only a maximum
of six contexts, though in practice some widely deployed UEs
support up to five contexts, many networks support only three and
it appears that at least one mobile device operating system is
limited to supporting only one context for its host UE.
[0022] In practice, it is possible that any given UE has PS domain
bearers established for other purposes at the time the UE sees the
need to establish PS emergency bearer services. In normal operation
an IMS VoIP capable UE may have several contexts established; IMS
VoIP itself reserves one context for signaling purposes that is
used for registering to the IMS and also to establish normal
(non-emergency) sessions. Then the UE may also have an additional
PDN connection.
[0023] The PDN need not support IP dual stack (IPv4 and IPv6), in
which case the PDN supporting both IP versions instructs the UE to
establish separate PDN connections; one for IPv4 traffic and one
for IPv6 traffic (see 3GPP TS 24.008 v10.4.0 and 3GPP TS 24.301
v10.4.0; these specifications use the term should instead of may
for the network `instructing` summarized above). This network
configuration can double the number of active contexts that the UE
must handle in parallel.
[0024] Regardless of the number of simultaneous contexts supported
by the UE and the capabilities of the UE and the network to support
(or not) dual stack bearers and different IP versions, it is
possible that at a given time for a given UE the maximum number of
contexts have already been activated for other purposes at the time
of emergency VoIP voice call establishment. The UE will detect that
it does not have enough resources to proceed with PS emergency
bearer establishment due to too many active contexts.
[0025] A typical network configuration would still allow emergency
access via so called Access Class 10 for a UE whose access for
other services is barred (see 3GPP TS 22.011 v11.1.0 clause 4.4).
Access Class 10 is broadcast in system information and informs UEs
in the cell whether they are allowed to initiate an emergency call
regardless of their access class barring status, so this allows the
UE to establish an emergency call. Context deactivation is a normal
priority procedure and subject to barring, so if the UE already has
got its maximum number of active contexts, it is not allowed to
deactivate PDP contexts in GPRS or to disconnect the PDN in EPS in
order to relieve the necessary resources for the subsequent
emergency call that would be allowed in this situation. But IMS
emergency services are not yet deployed in real networks and
devices, and so these problems related to establishing them have
not yet been encountered in practice. Below is a review of relevant
procedures for emergency services in GPRS and EPS networks.
[0026] There is an option already specified for a UE to use a PS
attach procedure for emergency purposes, but this is restricted to
a strictly limited service case when the UE cannot attach to the
network for any other than emergency services (see 3GPP TS 24.008
v10.4.0 and 3GPP 24.301 v10.4.0). Those same specifications detail
a service request procedure for a UE to initiate new services that
has already successfully attached to the network. The GPRS service
request contains PDP context status for the purpose of
synchronizing the PDP context status between the UE and the
network, if for some reason re-synchronizing is necessary.
[0027] If the UE has run out of EPS bearer contexts or GPRS PDP
contexts, then it is allowed (per 3GPP TS 24.008 v10.4.0 and 3GPP
24.301 v10.4.0) to relieve either some or all of those resources by
means of a UE-initiated EPS PDN disconnect procedure or a PDP
context deactivation in GPRS and then establish the connectivity
that is required for a PS emergency call. There are two shortfalls
with this prior art approach: a) it imposes a long delay to
establish an emergency call, and b) it may not be possible if the
UE's Access Class is barred per clause 4 of 3GPP TS 22.011
v11.1.0.
[0028] So in current practice emergency calls can override several
obstacles that would otherwise deny the UEs right for uplink
access, such as if the UE is in limited service and is not able to
attach for normal service or having a network assigned back-off
timer running. But if the UEs access to the network is barred, the
UE-initiated deactivation of PDP contexts in GPRS and the
UE-requested PDN disconnect procedure in EPS are forbidden. The UE
would be allowed to establish an emergency call, but cannot do so
since the procedures to relieve the resources that are essentially
required for setting up the emergency call are normal priority
procedures with no possibility to indicate "emergency" use. See
3GPP TS 44.018 clause 3.3.1.1.1; 3GPP TS 36.331 clause 5.3.3 and
3GPP TS 25.331 clause 8.1.8.
[0029] What is needed in the art is a way to assure a UE which
needs to establish emergency services may do so under any
conditions so long as the UE has sufficient signal strength with
the network, and without undue delay given the emergency nature of
the call.
SUMMARY
[0030] In a first exemplary embodiment of the invention there is a
method for establishing an emergency service for a user equipment
using a wireless network. The method includes unilaterally
deactivating, at the user equipment when the user equipment needs
to establish an emergency service, at least one active context with
the wireless network without deactivating at least one other active
context; thereafter directing to the wireless network, a request to
establish the emergency service and that identifies the emergency
service and one or more contexts that remain active after the
unilateral deactivation of the at least one active context by the
user equipment; synchronizing, in response to and based on the
request, current context status information of the user equipment
with the wireless network, and then establishing the emergency
service using the wireless network with which the active context
was deactivated.
[0031] In a second exemplary embodiment of the invention there is a
portable telecommunications user equipment, which includes a
processing system including at least one processor and at least one
memory storing a computer program. The at least one memory with the
computer program is configured with the at least one processor to
cause the user equipment to at least: unilaterally deactivate at
least one active context with a wireless network without
deactivating at least one other active context when the user
equipment needs to establish an emergency service; thereafter
direct to the wireless network, a request to establish the
emergency service and that identifies the emergency service and one
or more contexts that remain active after the unilateral
deactivation of the at least one active context by the user
equipment, such that in response to and based thereon, current
context status information of the user equipment is synchronized
with the wireless network, and then establish the emergency service
using the wireless network with which the active context was
deactivated.
[0032] In a third exemplary embodiment of the invention there is a
non-transitory computer readable memory tangibly storing a computer
program executable by at least one processor. The computer program
includes code to be executed on a processing system of a user
equipment. The code unilaterally deactivates, when the user
equipment needs to establish an emergency service, at least one
active context with the wireless network without deactivating at
least one other active context. Thereafter the code directs to the
wireless network, a request to establish the emergency service and
that identifies the emergency service and one or more contexts that
remain active after the unilateral deactivation of the at least one
active context by the user equipment, synchronizes, in response to
and based on the request, current context status information of the
user equipment with the wireless network, and then establishes the
emergency service using the wireless network with which the active
context was deactivated.
BRIEF DESCRIPTION OF THE DRAWINGS
[0033] FIG. 1 is a signaling diagram illustrating a local detach
followed by an emergency attach for UE that is already attached to
a cell needing to establish emergency services, according to an
exemplary embodiment of these teachings.
[0034] FIG. 2 is a signaling diagram illustrating a UE's local
deactivation of contexts followed by its SERVICE REQUEST indicating
context status for establishing emergency services according to an
exemplary embodiment of these teachings.
[0035] FIG. 3 is a signaling diagram illustrating a UE's
deactivation of contexts followed by establishment of emergency
contexts according to an exemplary embodiment of these
teachings.
[0036] FIG. 4 is a logic flow diagram that illustrates from the
perspective of the UE the operation of a method, and a result of
execution of computer program instructions embodied on a computer
readable memory, in accordance with exemplary embodiments of these
teachings.
[0037] FIG. 5 is a simplified block diagram showing the UE and a
network access node, and are exemplary electronic devices suitable
for use in practicing the exemplary embodiments of this
invention.
DETAILED DESCRIPTION
[0038] In general, a UE which has too many active contexts to add
another for an emergency call will need to prioritize its emergency
request above the other services and make the necessary resources
available, even if it means deactivating some other connections
that are used for lower priority services. The network needs to be
informed about the UE's context status, which contexts are kept and
which one is deactivated, to relieve resources for the PS emergency
call. This problem is particularly difficult for EPS technology
where there is no means for the UE to indicate the current EPS
bearer context status to the network. In GPRS it is less difficult
because the UE uses GPRS mobility management protocol service
requests that contain a PDP status information element, though in
GPRS the UE still needs to have some means for deactivating PDP
contexts to ensure resources are available for an IMS emergency
session.
[0039] One aspect of these teachings is how the UE selects which
ongoing (non-emergency) services to abandon in favor of
establishing a higher priority emergency call, as well as the means
to indicate this choice to the network with minimum signaling
overhead. In order to optimize the signaling to speed up the
emergency call establishment, certain embodiments of these
teachings detailed below utilize implicit signaling; this avoids
extra delays caused by session management protocol deactivation
signaling that would have to be executed prior to when the UE first
actually requests PS emergency bearer services.
[0040] This situation, in which the UE needing an emergency service
for which it has no excess PDP or EPS contexts, is resolved by the
example implementations shown at FIGS. 1-2. Namely, the UE selects
one or more contexts that are locally deactivated, and uses
enhanced signaling to request the emergency services of the
wireless network. One such enhanced signaling is to use an Extended
Service Request procedure instead of the conventional Service
Request procedure.
[0041] But as noted in the background section above, there is
another problem in prior art emergency call setup in that there is
a process for a UE which is camped in a cell but not attached to
the network to establish an emergency call, but no process to do so
if the UE is already attached to the network, even if it's not
using all its contexts. When the UE is attached the core network is
aware of the UE's presence since the core network authorizes that
attachment, but if the UE is only camping on the cell the core
network is not aware of its presence. The procedure the UE must use
in that latter `attached` case is to request a normal connection,
which the UE is not able to specify is for an emergency service. If
there are insufficient resources in the cell the UE's request may
easily be denied since the network will not know that request is
for preparing a subsequent emergency request.
[0042] This situation is resolved by the example implementation
shown at FIG. 1, an emergency attach procedure. While the emergency
attach procedure is currently specified to be used by a UE only
when attempting PS emergency access while camped on a cell not
providing normal services, FIG. 1 shows an adaptation which
resolves the problems above in case the UE is attached to the
network rather than only camped in a cell, namely a local detach
followed by an emergency attach.
[0043] FIG. 1 is a signaling diagram illustrating this solution.
For each of FIGS. 1-3, there is illustrated signaling between the
UE 20, a packet switched core network 30 and an IMS core network
40. From the UE's perspective the signaling is between itself and a
network access node such as a NodeB or an eNB as shown at FIG. 5;
that access node then relays the relevant messages (or content
thereof) to the PS core network 30 which as shown further relays
the relevant information to and from the IMS network 40.
[0044] FIG. 1 begins with the UE 20 having an active PS connection
102 with the PS core network 30. This means the UE is attached to
the network, and as noted above this precludes the UE 20 from using
the conventional emergency attach procedure which is reserved only
for UEs which are only camped in the cell (for example, if the UE
is not allowed normal access to this cell but is allowed to access
it for emergency purposes only). At 104 the UE detects a need to
establish an emergency data session. For example, the UE may be a
vehicle mounted device using the PS domain connection for real-time
navigation when an auto accident occurs and the UE knows, from a
particular user input (or series of inputs) or from automatic
connection to crash/airbag deployment sensors, to establish an
emergency connection. At block 106 the UE unilaterally locally
detaches from the connection of 102 and the UE sends an emergency
attach message at 108. In an embodiment there is no additional user
input needed for the local detach 106 operation; initiating an
emergency call as noted in the example auto accident scenario above
is sufficient to trigger both the local detach 106 and the
emergency attach 108 protocols.
[0045] Initiating the emergency attach 108 with the local detach
106 allows the UE to start `from clear` to proceed with the
emergency attach 108, that is, the UE starts the emergency attach
108 without an existing attachment 102 to the network. This
establishes a mobility management connection for session management
protocol and clears the reserved resources which were reserved for
the previous attach 102, freeing those resources for establishing
the emergency session.
[0046] The remainder of FIG. 1 is similar also at FIGS. 2-3, with
exceptions noted for the IMS registration 112, 212 and 312.
Specifically, following the emergency attach message 108 the PS
core network 30 and the UE 20 exchange signaling to establish
emergency PDN services 110, such as for example to establish a
single PDP (GPRS) or EPS context for IMS signaling. Once
established the session is registered to the IMS core network 40
and the emergency session is established at 112, and finally the PS
core network 30 can establish for the UE 20 a media bearer 114 for
which the context established at 110 will be active, a VoIP context
on the emergency session in this example. Since the UE detaches at
block 106 of FIG. 1, the registration to the IMS at message
exchange 112 of FIG. 1 is always required after the PDN is
established at message exchange 110. The FIG. 1 embodiment is quite
useful for the case there is a resource shortage in the network.
This is because if the UE were to simply request another bearer by
conventional procedures it could not indicate to the network that
the requested bearer was for emergency services.
[0047] The embodiment of FIG. 2 utilizes an extended service
request to establish emergency signaling and to indicate the UE's
context status, to inform the network of those contexts which the
UE 20 has locally deactivated. In this embodiment, before signaling
anything to the network 30 the UE 20 has detected that is has too
many active contexts in its active PS domain communications 202 to
co-exist with an IMS emergency session which the UE 20 would like
to establish after detecting a need for it at 204.
[0048] In an embodiment of these teachings there is an algorithm by
which the UE 20 methodically chooses which one or more PDP or EPS
contexts to locally deactivate. In order to assure that the network
can provide a VoIP bearer that ensures a sufficient amount of
resources for the emergency call (for example, aggregate downlink
and uplink bit rates for the UE 20), the UE 20 will deactivate some
or all bearer resources that provide guaranteed bit rates. If these
alone do not free up enough resources the next contexts to be
deactivated are the remaining non-guaranteed bit rate bearers. More
particularly, in one specific embodiment the selection algorithm
goes through the established bearers in their priority order, QCI
4-QCI 1, QCI 9-QC15. QCI is a scalar representing quality of
service class identifier that is used as a reference to access
node-specific parameters that control bearer level packet
forwarding treatment (e.g. scheduling weights, admission
thresholds, queue management thresholds, link layer protocol
configuration, etc.). The UE may also apply activity monitoring in
determination of PDP or EPS contexts to be deactivated; those with
little activity are considered a lower priority, and the algorithm
considers them sooner for deactivation, than bearers having a
higher level of traffic/activity.
[0049] Once the UE 20 has locally deactivated one or more of its
PDP or EPS contexts the UE prepares an extended service request 208
to inform the network which contexts remain active (for example, a
bitmap). The use of the extended service request is currently used
for circuit-switched fall back (see 3GPP TS 24.301 v10.4.0, which
specifies that circuit-switched services can be used in case
packet-switched services cannot) and contains an information
element to synchronize the EPS context status between the UE and
the network only for that circuit switched fall back. The normal
service request enables no such synchronization. Typically, the
circuit-switched fall back is used for speech or
short-message-service/text messaging scenarios. In the FIG. 2
embodiment there is a new service type (for example, added to
subclause 9.9.3.27 of 3GPP TS 24.301 v10.4.0) allocated for
emergency session use. This new service type enables the extended
service request to be used for emergency signaling connection
establishment. In order that this embodiment may be easily backward
compatible with legacy signaling there is a value reserved with the
default handling of the service type `packet services via S1` for
indicating emergency signaling connection establishment. This
signaling connection is then used for activating a context for IMS
emergency session initialization. In the reference specification
version, the extended service request PDU already contains an EPS
bearer context status information element that the UE 20 can use in
the FIG. 2 embodiment to indicate to the network 30 all the
remaining contexts that the UE 20 has not deactivated and which the
UE 20 still considers active prior to the emergency bearer
establishment. That is, the UE 20 locally deactivates one or more
PDP or EPS contexts at 206 and the status information element in
the extended service request 208 is used for synchronizing its
current context status information with the network 30.
[0050] The extended service request 208 establishes the RR
connection at 210 with the access stratum/access node of the
network and indicates `emergency` as the establishment cause. This
cause is delivered by the radio access network (GPRS or EPS) to the
packet switched core network 30 in S1 connection establishment
signaling. Since the emergency PDN services establishment signaling
210 identifies `emergency` as the establishment cause, in a
particular embodiment of these teachings there is no similar
indicator of `emergency` in the extended service request 208 (for
example, such an emergency indication is absent from the `service
type` field of that message 208). In other embodiments the `service
type` field of message 208 indicates emergency service in addition
to the emergency establishment cause in message 210.
[0051] For the remainder of FIG. 2, the PS core network 30 and the
UE 20 exchange signaling to establish emergency PDN services 210,
such as for example to establish a single PDP (GPRS) or EPS context
for IMS signaling. Once established the session is registered to
the IMS core network 40 and the emergency session is established at
212, and finally the PS core network 30 can establish for the UE 20
a media bearer 214 for which the PDP or EPS context established at
210 will be active, a VoIP context on the emergency session in this
example.
[0052] A new registration to the IMS services at exchange 212 may
or may not be needed. IMS registration is made with dedicated
signaling on a default bearer to a specific PDN. For FIG. 1 any
previous registration from the UE being attached at 102 was lost
from its detach at 106. In FIG. 2 there is no detach, only a PDP or
EPS context deactivation at 206. So the UE may in some cases remain
registered to its home public land mobile network which can provide
the IMS services, in which case there is no additional IMS
registration needed at exchange 212. The IMS registration in the
exchange of 212 is conditional on whether the network requires a
new PDN connection for the UE 20 to a local access point that will
provide local IMS emergency service (the network indicates whether
it supports this `emergency bearer services` feature through
evolved mobility management EMM and GPRS mobility management GMM
signaling). 3GPP TS 23.167 clause 7.2 lists a set of conditions
which must be met before a UE can initiate an emergency IMS
registration (either not registered or roaming; has sufficient
credentials to authenticate; and is able to detect an emergency
session) and in an exemplary embodiment of these teachings those
also give the conditions under which the UE registers to IMS
emergency services at message exchange 212.
[0053] While the embodiments of FIGS. 1-2 are based on local
deactivation of PDP or EPS contexts without the UE specifically
signaling that deactivation to the network, the FIG. 3 embodiment
details explicit signaling by the UE of the deactivated PDP or PDN
context(s) following the UE's service request for an emergency
call. As with FIG. 2, at FIG. 3 before signaling anything to the
network 30 the UE 20 has detected that is has too many active PDP
(GPRS) or EPS contexts in its active PS domain communications 302
to co-exist with an IMS emergency session which the UE 20 would
like to establish after detecting a need for it at 304. In this
embodiment also the UE 20 may apply a prioritization algorithm as
detailed above for the FIG. 2 embodiment so as to determine which
of its active context(s) is/are to be deactivated and which are to
be retained. The UE 20 must be able to signal at 308 a sufficient
number of contexts which are deactivated to make space for the
subsequent emergency connectivity, which means the conventional
requirement for the UE to analyze whether or not it is barred need
to be changed.
[0054] In conventional practice before a PDN disconnect the UE
needs to initiate a service request procedure but 3GPP TS 24.301
v10.4.0 at Annex D.1 allows the UE to indicate the RRC
establishment cause as "emergency calls" only if the SERVICE
REQUEST message is sent for the following reasons: [0055] If a
SERVICE REQUEST is to request user plane radio resources for
emergency bearer services, the RRC establishment cause shall be set
to Emergency call. (See Note 1) [0056] If a SERVICE REQUEST is
triggered by a PDN CONNECTIVITY REQUEST that has request type set
to "emergency", the RRC establishment cause shall be set to
Emergency call. (See Note 1)
[0057] For the second item above, the conventional procedures
provide that the SERVICE REQUEST for PDN DISCONNECT REQUEST shall
be sent using "originating calls" RRC establishment cause, which
for the case of FIG. 3 does not give the network any indication of
the real reason for the disconnect which is to relieve resources
for a subsequent emergency request that will follow as soon as the
required resources are available. In a normal case this only
reduces the priority of the procedure that is preparing ground for
emergency request, but if the UEs Access Class is barred, this
drawback blocks the PS emergency call completely as no PDN
connectivity resources can be freed for the emergency request.
[0058] Therefore, in this embodiment the UE 20 will send the
SERVICE REQUEST 306 which has the RRC establishment cause
identified as "emergency call" prior to the PDN DISCONNECT REQUEST
308. To implement this in GPRS and EPS the relevant specifications
will need to be adapted to allow this order of the messages.
[0059] It is also advantageous that the PDP context deactivation
(GPRS) and PDN disconnect (EPS) procedures (both message 308 of
FIG. 3) should be initiated with indicated RRC establishment cause
"emergency calls" or by overriding the Access Class Barring
evaluation for context deactivation that is required for subsequent
outgoing emergency connectivity request.
[0060] Following the UE's service request indicating emergency
session 306 and the indication of which contexts the UE deactivated
308 the establishment of a PS emergency call proceeds normally and
as detailed for FIGS. 1-2. Specifically, the PS core network 30 and
the UE 20 exchange signaling to establish emergency PDN services
310, such as for example to establish a single PDP (GPRS) or EPS
context for IMS signaling. Once established the session is
registered to the IMS core network 40 and the emergency session is
established at 312, and finally the PS core network 30 can
establish for the UE 20 a media bearer 314 for which the context
established at 310 will be active, a VoIP context on the emergency
session in this example. The IMS registration at 312 is
conditional, using the same conditions described at FIG. 2 for
message exchange 212.
[0061] Exemplary embodiments of these teachings provide the
following technical effects. The solution detailed with respect to
FIG. 1 has the advantage of being already a specified procedure, so
it is simple to implement as it re-uses a limited service state
procedure (camped in the cell only) in the normal service state
(attached to the network). It is also an advantage that no
additional session management signaling is required. The drawback
that all data communications are removed (meaning the UE may need
to re-establish connections again after the emergency connection is
no longer needed) is seen to be minor since the emergency may be
quite severe against possibly trivial non-emergency data
sessions.
[0062] A technical effect arising from the FIG. 2 embodiment is
that all resources that are not absolutely required to process the
PS emergency call are preserved. The FIG. 2 embodiment aligns
simply with GPRS and so would be quite simple to adopt in that RAT
since no additional session management signaling is required. While
this embodiment may change the conventional procedure to cover a
wider range of services, since this relates to emergency services
the change is seen to be worthwhile. There are two main
distinctions over the conventional procedures with FIG. 2; namely
there is a local deactivation of PDP context (GPRS) or local PDN
disconnection (EPS) without explicit signaling, and the PDP
context/PDN connection synchronization mechanism is added to the
EXTENDED SERVICE REQUEST which is conventionally used for a
different purpose and cannot indicate active or deactivated
contexts.
[0063] It is also possible for another embodiment to enhance the
emergency attach of FIG. 1 by adding an EPS context status. This
improves the FIG. 1 embodiment at the cost of adding that EPS
context status information element to the ATTACH REQUEST message.
This may or may not be the most efficient signaling since that
information element would remain but be unnecessary for
non-emergency attach instances.
[0064] The FIG. 3 embodiment provides the technical effect of
clearing out the PDP context of PDN connectivity resources in
preparation for a subsequent emergency call in the SERVICE REQUEST
message, but such explicit signaling is less elegant than the FIG.
2 embodiment. The RRC establishment cause "emergency call" can only
be applied from the emergency call related signaling and the
SERVICE REQUEST would be signaled using normal priority, but this
is the way around the UE's access class being barred and the prior
art emergency call establishment not even getting through. This
also is easy to adopt since it follows existing procedures fairly
closely, with the change that the UE's use of the "emergency call"
as its RRC establishment cause or its overriding of its access
class being barred.
[0065] Now are detailed with reference to FIG. 4 further particular
exemplary embodiments from the perspective of the UE 20. FIG. 4 may
be performed by the whole UE 20 shown at FIG. 4, or by one or
several components thereof such as a modem. At block 402, in
response to determining that a UE having an active connection with
a wireless network needs to establish an emergency service, the UE
unilaterally deactivates an active session or context with the
wireless network. For the case shown at FIG. 1 the UE may begin
with an active radio connection. For the cases shown at FIGS. 2-3
the UE may be in idle mode and begin with one or more active
logical connections but no active radio connection, which have been
released and require establishment before any signaling with the
network. These two scenarios are evident from the `active session
or context` which in block 402 is deactivated. Thereafter at block
404 the UE sends to the wireless network signaling to establish the
emergency service, in which the signaling specifically identifies
the service as an emergency service.
[0066] Further portions of FIG. 4 represent various of the specific
but non-limiting embodiments detailed above. Block 406 relates to
the FIG. 1 embodiment and specifies that the unilateral
deactivating of block 402 is the UE locally detaching from an
active packet domain communication with the wireless network; and
that the signaling of block 404 is an emergency attach which is
established following the local detaching which clears resources
used for the active packet domain communication.
[0067] Block 408 relates to the FIG. 2 embodiment, in which the
unilateral deactivating of block 402 is at block 408 the UE
deactivating one or more (PDP or EPS) contexts; and the signaling
of block 404 is an extended service request which identifies one or
more contexts which remains active after the deactivating.
[0068] Block 410 relates to the FIG. 3 embodiment, in which the
unilateral deactivating of block 402 is at block 410 the UE
deactivating one or more contexts; and the signaling of block 404
is specifically at block 410 a deactivation message explicitly
indicating which one or more contexts are deactivated. Block 412
has further implementation details of this embodiment; the
signaling to establish the emergency service comprises a SERVICE
REQUEST and the deactivation message comprises one of a PDN CONTEXT
DEACTIVATION or a PDN DISCONNECT REQUEST, and the deactivation
message has a cause indicator explicitly identifying the service as
an emergency service.
[0069] FIG. 4 is a logic flow diagram which may be considered to
illustrate the operation of a method, and a result of execution of
a computer program stored in a computer readable memory, and a
specific manner in which components of an electronic device such as
the UE are configured to cause that electronic device to operate.
The various blocks shown in FIG. 4 may also be considered as a
plurality of coupled logic circuit elements constructed to carry
out the associated function(s), or specific result of strings of
computer program code stored in a memory.
[0070] Such blocks and the functions they represent are
non-limiting examples, and may be practiced in various components
such as integrated circuit chips and modules, and that the
exemplary embodiments of this invention may be realized in an
apparatus that is embodied as an integrated circuit. The integrated
circuit, or circuits, may comprise circuitry (as well as possibly
firmware) for embodying at least one or more of a data processor or
data processors, a digital signal processor or processors, baseband
circuitry and radio frequency circuitry that are configurable so as
to operate in accordance with the exemplary embodiments of this
invention.
[0071] Reference is now made to FIG. 5 for illustrating a
simplified block diagram of various electronic devices and
apparatus that are suitable for use in practicing the exemplary
embodiments of this invention. In FIG. 5 there is a UE 20 in the
GPRS or EPS system operating under a network access node 22 (such
as a Node B or an eNodeB) via wireless link 21. The radio access
network (GPRS or EPS) which includes the access node includes a
higher network node (radio network controller RNC or mobility
management entity MME) 24 which provides connectivity with further
networks such as for example the PS and IMS core networks 30, 40
shown at FIGS. 1-3. There is also a data/control path 23 coupling
the access node 22 with the higher network node 22.
[0072] The UE 20 includes processing means such as at least one
data processor (DP) 20A, storing means such as at least one
computer-readable memory (MEM) 20B storing at least one computer
program (PROG) 20C, communicating means such as a transmitter TX
20D and a receiver RX 20E for bidirectional wireless communications
with the eNB 22 and with the second device 26 via one or more
antennas 20F. While only one transmitter and receiver are shown it
is understood there may be more than one. Also stored in the MEM
20B at reference number 20G are the emergency bearer establishment
signaling procedures according to these teachings as detailed
above, and the rules/algorithm for prioritizing contexts as also
detailed above.
[0073] The access node 22 also includes processing means such as at
least one data processor (DP) 22A, storing means such as at least
one computer-readable memory (MEM) 22B storing at least one
computer program (PROG) 22C, and communicating means such as a
transmitter TX 22D and a receiver RX 22E for bidirectional wireless
communications with the UE 20 via one or more antennas 22F. The
emergency bearer establishment signaling procedures according to
these teachings as detailed above are stored in the memory 22B of
the access node 22 at unit 22G.
[0074] The higher network node 24 has functionally similar
capabilities for processor 24A, memory 24B and programs 24C. While
not particularly illustrated for the UE 20 or access node 22, those
apparatus are also assumed to include as part of their wireless
communicating means a modem similar to that shown for the higher
network node at 24H, and which may be inbuilt on an RF front end
chip within those devices 20, 22 and which also carries the TX
20D/22D and the RX 20E/22E.
[0075] At least one of the PROGs 20C/22C in the UE 20 and in the
network access node 22 is assumed to include program instructions
that, when executed by the associated DP 20A/22A, enable the device
to operate in accordance with the exemplary embodiments of this
invention, as was discussed above in detail. In these regards the
exemplary embodiments of this invention may be implemented at least
in part by computer software stored on the MEM 20B, 22B which is
executable by the DP 20A/22A of the devices 20, 22; or by hardware,
or by a combination of tangibly stored software and hardware (and
tangibly stored firmware). Electronic devices implementing these
aspects of the invention need not be the entire apparatus 20, 22,
as shown, but exemplary embodiments may be implemented by one or
more components of same such as the above described tangibly stored
software, hardware, firmware and DP, or a system on a chip SOC or
an application specific integrated circuit ASIC or a digital signal
processor DSP.
[0076] In general, the various embodiments of the UE 20 can
include, but are not limited to: data cards, USB dongles, cellular
telephones; personal portable digital devices having wireless
communication capabilities including but not limited to
laptop/palmtop/tablet computers, digital cameras and music devices,
Internet appliances, remotely operated robotic devices or
machine-to-machine communication devices.
[0077] Various embodiments of the computer readable MEMs 20B/22B
include any data storage technology type which is suitable to the
local technical environment, including but not limited to
semiconductor based memory devices, magnetic memory devices and
systems, optical memory devices and systems, fixed memory,
removable memory, disc memory, flash memory, DRAM, SRAM, EEPROM and
the like. Various embodiments of the DPs 20A/22A include but are
not limited to general purpose computers, special purpose
computers, microprocessors, digital signal processors (DSPs) and
multi-core processors.
[0078] Various modifications and adaptations to the foregoing
exemplary embodiments of this invention may become apparent to
those skilled in the relevant arts in view of the foregoing
description. While the exemplary embodiments have been described
above in the context of the GPRS and EPS systems, it should be
appreciated that the exemplary embodiments of this invention are
not limited for use with only this one particular type of wireless
communication system, and that they may be used to advantage in
other wireless communication systems such as for example UTRAN and
others in which UEs may need to set up emergency services while
already attached to the network.
[0079] Some of the various features of the above non-limiting
embodiments may be used to advantage without the corresponding use
of other described features. The foregoing description should
therefore be considered as merely illustrative of the principles,
teachings and exemplary embodiments of this invention, and not in
limitation thereof.
* * * * *