A system and method are disclosed to support voice call Continuity (vcc) for emergency calls. The system includes a vcc application in a visited internet-protocol multimedia subsystem (IMS) to facilitate domain transfers between the IMS subsystem and a circuit-switched (CS) subsystem. The system further includes an emergency call session control function (E-CSCF) subsystem in the visited IMS subsystem that is operatively coupled to the vcc application to facilitate domain transfers between the IMS subsystem and the CS subsystem.
|
20. A method for supporting voice call Continuity (vcc) for emergency calls in a wireless access environment, comprising:
receiving a request for an emergency call via a radio link at a node in a visited network, wherein the emergency call is destined for a public safety answering point (PSAP);
establishing the emergency call by having support for location anchored in the visited network, wherein the emergency call is routed via a vcc application in the visited network; and
moving the emergency call from one to the other of a circuit switched domain and a packet switched domain by sending a request for handover to the vcc application,
wherein the visited network provides continuing support for location.
1. An apparatus for supporting voice call Continuity (vcc) for emergency calls in a wireless access environment, comprising:
a receiver for receiving a request for an emergency call via a radio link from a user equipment (UE) at a node in a visited network, wherein the emergency call is destined for a public safety answering point (PSAP);
a component of the visited network for establishing the emergency call by having support for location anchored in the visited network
a vcc application in the visited network for routing the emergency call and for moving the emergency call from one to the other of a circuit switched domain and a packet switched domain,
wherein the visited network provides continuing support for location.
47. An apparatus for supporting voice call Continuity (vcc) for emergency calls in a wireless access environment, comprising:
means for receiving a request for an emergency call via a radio link from a user equipment (UE) at a node in a visited network, wherein the emergency call is destined for a public safety answering point (PSAP);
means for establishing the emergency call by having support for location anchored in the visited network, wherein the emergency call is routed via a vcc application in the visited network; and
means for moving the emergency call from one to the other of a circuit switched domain and a packet switched domain by sending a request for handover to the vcc application,
wherein the visited network provides continuing support for location.
46. At least one processor for supporting voice call Continuity (vcc) for emergency calls in a wireless access environment, comprising:
a first module for receiving a request for an emergency call via a radio link from a user equipment (UE) at a node in a visited network, wherein the emergency call is destined for a public safety answering point (PSAP);
a second module for establishing the emergency call by having support for location anchored in the visited network, wherein the emergency call is routed via a vcc application in the visited network; and
a third module for moving the emergency call from one to the other of a circuit switched domain and a packet switched domain by sending a request for handover to the vcc application,
wherein the visited network provides continuing support for location.
41. A computer program product for supporting voice call Continuity (vcc) for emergency calls in a wireless access environment, comprising:
a non-transitory computer-readable storage medium, comprising:
a first set of instructions for causing a computer to receive a request for an emergency call via a radio link from a user equipment (UE) at a node in a visited network, wherein the emergency call is destined for a public safety answering point (PSAP);
a second set of instructions for causing the computer to establish the emergency call by having support for location anchored in the visited network, wherein the emergency call is routed via a vcc application in the visited network; and
a third set of instructions for causing a computer to move the emergency call from one to the other of a circuit switched domain and a packet switched domain by sending a request for handover to the vcc application,
wherein the visited network provides continuing support for location.
2. The apparatus of
wherein the vcc application is further located in a visited internet-protocol multimedia subsystem (IMS) to facilitate domain transfers between the visited IMS subsystem and a circuit-switched (CS) subsystem; and
an emergency call session control function (E-CSCF) subsystem in the visited IMS subsystem that is operatively coupled to the vcc application to facilitate domain transfers between the visited IMS subsystem and the CS subsystem.
3. The apparatus of
6. The apparatus of
7. The apparatus of
8. The apparatus of
10. The apparatus of
11. The apparatus of
means for facilitating domain transfers between a visited internet-protocol multimedia subsystem (IMS) subsystem and a circuit-switched (CS) subsystem; and
means in the visited IMS subsystem that is operatively coupled to the first means for facilitating domain transfers between the visited IMS subsystem and the CS subsystem.
13. The apparatus of
14. The apparatus of
15. The apparatus of
16. The apparatus of
17. The apparatus of
18. The apparatus of
19. The apparatus of
21. The method of
facilitating domain transfers between an internet-protocol multimedia subsystem (IMS) and a circuit-switched (CS) subsystem through at least one of the vcc application or an emergency call session control function (E-CSCF).
22. The method of
23. The method of
24. The method of
25. The method of
26. The method of
27. The method of
28. The method of
29. The method of
30. The method of
31. The method of
32. The method of
33. The method of
34. The method of
35. The method of
36. The method of
37. The method of
38. The method of
39. The method of
40. The method of
42. The computer program product of
a set of instructions for causing the computer to retrieve a location of the user equipment (UE) that follows a vcc transfer from a first wireless access network to a second wireless access network.
|
The present Application for Patent claims the benefit of the following U.S. Provisional Patent Applications: (1) U.S. Provisional Application Ser. No. 60/795,774, filed on Apr. 28, 2006, entitled “SUPPORT OF VCC FOR VOIP EMERGENCY CALLS,” by Stephen Edge; (2) U.S. Provisional Application Ser. No. 60/796,669, filed May 1, 2006, entitled “SUPPORT OF VCC FOR VOIP EMERGENCY CALLS,” by Stephen Edge; and (3) U.S. Provisional Application Ser. No. 60/815,738, filed on Jun. 21, 2006, entitled “SYSTEM AND METHOD FOR SUPPORTING VOICE CALL CONTINUITY FOR VOIP EMERGENCY CALLS,” by Stephen Edge and assigned to the assignee hereof and hereby expressly incorporated by reference herein.
1. Field
This disclosure relates generally to a system and method to effectively support Voice Call Continuity (VCC) for Voice-Over-IP (VoIP) emergency calls.
2. Background
Voice Call Continuity (VCC) is a feature that is being standardized by the Third Generation Partnership Project (3GPP) and by the Third Generation Partnership Project 2 (3GPP2). A definition of VCC has been produced by 3GPP in 3GPP TS 23.206 (“Voice Call Continuity between CS and IMS; Stage 2”) which is a publicly available document. A definition of VCC has also been produced by 3GPP2 in 3GPP2 X.P0042-001-0 (“Voice Call Continuity between IMS and Circuit Switched Systems—Stage 2”) which is also a publicly available document. Both definitions of VCC are very similar and support continuity of a voice call from a wireless terminal to some other device (wireless or non-wireless) when the wireless terminal switches between using a wireless access that supports circuit mode and a wireless access that supports VoIP. In particular, use of VCC avoids having to release a call (e.g., a circuit mode call) and re-establish a call (e.g., using VoIP) when the user switches access which would cause significant delay and disturbance to the users involved in the call and might result in an inability to re-establish the call.
Specific examples of wireless access networks that support circuit mode, sometimes referred to as the circuit switched (CS) domain, include the Global System for Mobile Communications (GSM), Universal Mobile Telecommunication System (UMTS) using wideband code division multiple access (W-CDMA) and cdma2000 1X. Examples of wireless access networks that support VoIP include UMTS W-CDMA, cdma2000 1xEV-DO (Evolution Data Optimized) and various wireless LAN (WLAN) and WiMax networks. In some cases, the same access network (e.g. UMTS W-CDMA) can support both circuit mode and VoIP, although the user's wireless terminal would be required to use just one of them (at any one time) for a particular call.
When a wireless user loses coverage for a particular wireless access network and needs to make use of another access network, it is sometimes possible to handover an ongoing call from one access network to the other without disruption of service provided the type of access (circuit mode or VoIP) remains unchanged. When the type of access needs to change, however (e.g., because the new access network does not support the previously used access type), it will normally release the call and re-establish it again using the new access type. VCC is a capability that enables handover between VoIP and circuit mode without such a disruption.
VCC is currently defined by both 3GPP and 3GPP2 for normal non-emergency calls and may not explicitly support emergency calls originated using either circuit mode or VoIP. This is because the solution being defined for VCC in both 3GPP and 3GPP2 is incompatible with the solutions defined and being defined to support circuit mode and VoIP emergency calls. The main source of this incompatibility is that the solutions to support emergency calls rely on support from the network, known as the visited network, that is currently serving the wireless user, whereas the solutions for VCC require VCC support in the user's home network even when different from the visited network.
The lack of VCC support for emergency calls means that such calls will have to be released and re-originated if a wireless user needs to change between use of circuit mode and use of VoIP in different access networks (or in the same access network)—e.g., because the user has moved or the current access network is congested or subject to some other anomalous condition. This may be particularly disadvantageous because if the user re-originates the call, the call may not go through to the same Public Safety Answering Point (PSAP) operator (i.e., to the same person) as before. In addition, the PSAP operator may not be able to re-originate the call if a callback number was not provided when the call was first established—e.g. if the wireless terminal is not properly authorized in the original access network. There would thus be an advantage to extending the capability of VCC to support emergency calls.
As described in 3GPP TS 23.206 (“Voice Call Continuity between CS and IMS; Stage 2”), VCC is mainly supported in a new IMS (IP Multimedia Subsystem) entity known as a VCC Call Continuity Control Function (VCC CCCF) also referred to in later versions of 3GPP TS 23.206 as a VCC Application or (in certain specific contexts) as a Domain Transfer Function. As described in the 3GPP2 draft X.P0042-001-0 (“Voice Call Continuity between IMS and Circuit Switched Systems—Stage 2”), VCC is supported by a VCC Application Server (VCC AS), which is an entity similar to the 3GPP VCC Application. Both the 3GPP VCC Application and 3GPP2 VCC AS are defined to be located in the calling wireless user's home network. This definition is incompatible with the current solution for VoIP IMS Emergency calls defined in 3GPP TS 23.167 and with the 3GPP2 solution being defined in 3GPP2 X.P0049-000-0 (“All-IP Emergency Services”) where IMS VoIP emergency call support is restricted to the visited network. As such, it would not be possible to support VCC for IMS Emergency calls unless a new method of VCC is defined for the visited network or unless IMS emergency calls are routed through the home network.
The method disclosed here uses the former alternative since home network support of IMS Emergency calls would significantly change the current solution for VoIP emergency calls as well as introduce a number of new problems such as liability issues, support of visited country regulatory requirements and possibly latency issues. Such a home network based solution would also be incompatible with supporting IMS emergency calls from unauthorized users (e.g., where there is no roaming agreement between the visited and home networks). A home network solution would also be incompatible with supporting CS emergency calls since these are also supported in the visited network.
The method disclosed herein enables VCC support for emergency calls and has the following capabilities:
Support of location refers generally to the capability of a PSAP to obtain the geographic location (e.g., accurate latitude and longitude) of a wireless user who has initiated an emergency call when the call is initially made and/or at later times during the call. Such a capability is currently mandated for circuit mode emergency calls in (for example) both Europe and North America and may be mandated later for VoIP emergency calls. Continuing support for location means that after changing access type (e.g., from VoIP to circuit mode), it will still be possible for the PSAP to obtain the wireless user's location.
Other aspects, advantages and novel features of the present disclosure will become apparent from the following detailed description of the disclosure when considered in conjunction with the accompanying drawings.
I. Wireless Communication System
The exemplary embodiment employs a spread-spectrum wireless communication system, supporting a broadcast service. Wireless communication systems are widely deployed to provide various types of communication such as voice, data, and so on. These systems may be based on code division multiple access (CDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), 3GPP LTE (Long Term Evolution) wireless access, 3GPP2 UMB (Ultra Mobile Broadband), WiMax, or some other modulation techniques.
A system may be designed to support one or more standards such as the standard offered by a consortium named “3rd Generation Partnership Project” referred to herein as 3GPP, and embodied in a set of documents including Document Nos. TS 23.206 (“Voice Call Continuity Between CS and IMS; Stage 2 (Release 7)”), TS 23.167 (“IP Multimedia Subsystem (IMS) Emergency Sessions (Release 7)”), TS 24.008 (“Mobile Radio Interface Layer 3 Specification; Core Network Protocols; Stage 3 (Release 6)”), TS 23.271 (“Functional Stage 2 Description of Location Services (LCS) (Release 7)”), TR. 21.905 (“Vocabulary for 3GPP Specifications”), and TS 23.002 (“Network Architecture (Release 7)”); the standard offered by a consortium named “3rd Generation Partnership Project 2” referred to herein as 3GPP2, including Document Nos. X.P0042-001-0 (“Voice Call Continuity Between IMS and Circuit Switch Systems”), X.P0049-000-0 (“All-IP Emergency Services”), and X.S0024 (“IP-Based Location Services”); the TIA/EIA/ATIS J-STD-036 (“Enhanced Wireless 9-1-1 Phase II”); and relevant IETF RFC documents, including IETF RFC 3261 (“SIP: Session Initiation Protocol”) and IETF RFC 2327 (“SDP: Session Description Protocol”). The standards and documents cited above are hereby expressly incorporated herein by reference.
Terminals (or UEs) 106 in the coverage area may be fixed (i.e., stationary) or mobile. As shown in
Increasing demand for wireless data transmission and the expansion of services available via wireless communication technology have led to the development of specific data services. One such service is referred to as High Rate Packet Data (HRPD). An exemplary HRPD service is proposed in “EIA/TIA-IS856 cdma2000 High Rate Packet Data Air Interface Specification” referred to as “the HRPD specification.”HRPD service is generally an overlay to a voice communication system that provides an efficient method of transmitting packets of data in a wireless communication system. As the amount of data transmitted and the number of transmissions increases, the limited bandwidth available for radio transmissions becomes a critical resource. There is a need, therefore, for an efficient and fair method of scheduling transmissions in a communication system that optimizes use of available bandwidth. In the exemplary embodiment, system 100 illustrated in
Modern communications systems are designed to allow multiple users to access a common communications medium. Numerous multiple-access techniques are known in the art, such as time division multiple-access (TDMA), frequency division multiple-access (FDMA), space division multiple-access, polarization division multiple-access, code division multiple-access (CDMA), and other similar multi-access techniques. The multiple-access concept is a channel allocation methodology which allows multiple user access to a common communications link. The channel allocations can take on various forms depending on the specific multi-access technique. By way of example, in FDMA systems in general, the total frequency spectrum is divided into a number of smaller sub-bands and each user can be given its own sub-band to access the communications link. Alternatively, as for example in the OFDMA variant of FDMA, each user can be allowed to access many different frequency channels. Alternatively, in TDMA systems, each user is given the entire frequency spectrum during periodically recurring time slots. In CDMA systems, each user is given the entire frequency spectrum for all of the time but distinguishes its transmission through the use of a code.
One example of a communication system supporting the HRPD transmissions and adapted for scheduling transmissions to multiple users is illustrated in
In addition, the channel scheduler 132 selects the particular data queue for transmission. The associated quantity of data to be transmitted is then retrieved from a data queue 172 and provided to the channel element 168 for transmission to the remote station associated with the data queue 172. As discussed below, the channel scheduler 132 selects the queue for providing the data, which is transmitted in a following service interval using information including the weight associated with each of the queues. The weight associated with the transmitted queue is then updated.
RNC 130 interfaces with packet network interface 146, Public Switched Telephone Network, Public Switched Telephone Network (PSTN), 148, and all Node Bs in the communication system (only one Node B 160 is shown in
RNC 130 contains many selector elements 136, although only one is shown in
Data source 122 contains a quantity of data, which is to be transmitted to a given remote station. Data source 122 provides the data to packet network interface 146. Packet network interface 146 receives the data and routes the data to the selector element 136. Selector element 136 then transmits the data to each Node B 160 in communication with the target remote station. In the exemplary embodiment, each Node B 160 maintains a data queue 172, which stores the data to be transmitted to the remote station.
The data is transmitted in data packets from data queue 172 to channel element 168. In the exemplary embodiment, on the forward link, a “data packet” refers to a quantity of data which is a maximum of 1024 bits and a quantity of data to be transmitted to a destination remote station within a predetermined “time slot” (such as ≈1.667 msec). For each data packet, channel element 168 inserts the control fields. In the exemplary embodiment, channel element 168 performs a Cyclic Redundancy Check, CRC, encoding of the data packet and control fields and inserts a set of code tail bits. The data packet, control fields, CRC parity bits, and code tail bits comprise a formatted packet. In the exemplary embodiment, channel element 168 then encodes the formatted packet and interleaves (or reorders) the symbols within the encoded packet. In the exemplary embodiment, the interleaved packet is covered with a Walsh code, and spread with the short PNI and PNQ codes. The spread data is provided to RF unit 170 which quadrature modulates, filters, and amplifies the signal. The forward link signal is transmitted over the air through an antenna to the forward link.
At the remote station 106, the forward link signal is received by an antenna and routed to a receiver. The receiver filters, amplifies, quadrature demodulates, and quantizes the signal. The digitized signal is provided to a demodulator (DEMOD) where it is despread with the short PNI and PNQ codes and decovered with the Walsh cover. The demodulated data is provided to a decoder which performs the inverse of the signal processing functions done at Node B 160, specifically the de-interleaving, decoding, and CRC check functions. The decoded data is provided to a data sink.
In the following discussion, the invention will be described mainly in the context of the 3GPP architecture reference model. However, it is understood that with the disclosed information, one skilled in the art could easily adapt for use and implement aspects of the invention in a 3GPP2 network architecture or in other network architectures.
II. Architecture Reference Model
As shown in
As shown in
Reference models applicable to 3GPP2 are obtained by replacing the VCC Application in
III. Negotiation of VCC Support
For normal VCC, the home network (e.g., home S-CSCF) can be aware of the UE's VCC capability from subscription information obtained from the UE's home subscriber server (HSS). The UE can be already aware of the home network support of VCC and the VDN (E 164 Voice Domain Transfer Number) and VDI (Voice Domain Transfer SIP URI) used for domain transfer (or other numbers and addresses equivalent to a VDN and VDI), enabling VCC without any explicit negotiation and information transfer when a voice call is first originated.
It would be desirable to support VCC for CS and VoIP emergency calls in the same manner, although some explicit signaling changes may be needed. For example, without any negotiation of VCC support, it may be difficult to support VCC because when the UE changes domain, it will have no idea in a roaming situation whether the old and new domains can collaborate to support VCC and hence it won't know whether the existing call can be continued or not. In the following discussion, it is assumed that VCC support for IMS emergency calls is provided in the visited network.
III.A. Methods to Convey that the UE is VCC Capable
To convey to the visited network (e.g., P-CSCF, E-CSCF or Voice Mobile-Services Switching Centre (VMSC)) that the UE is VCC capable, the following alternatives are possible.
i. during registration (e.g., in the SIP REGISTER message); or
ii. when originating an IMS emergency call (e.g. in the SIP INVITE message); or
iii. when originating a CS mode emergency call (e.g., in the Emergency SETUP message defined in 3GPP TS 24.008).
Alternative (a) is applicable to an emergency call originated in the PS (packet switched) domain and may use the same mechanism for VCC capability discovery that is used for normal VCC support (for non-emergency calls) as described in 3GPP TS 23.206 if the UE is not roaming (i.e., is served by its home network).
With alternative (b), the visited network assumes that the UE is VCC capable and assigns VCC resources when the emergency call is originated (e.g., as described later in section IV and in
Both alternative (a) and alternative (b) avoid impacting the UE, which is desirable to enable a common VCC solution (from the perspective of the UE) for both emergency and non-emergency calls.
Alternative (c) also avoids impacting the UE. However, alternative (c) may be restricted to authorized UEs only.
Alternative (d.i) avoids impacting the home network but is again restricted to authorized UEs only while alternatives (d.ii) and (d.iii) are valid for all UEs although they require a new variant of VCC from the UE perspective.
III. B. Methods to Convey that the Visited Network is VCC Capable
To convey to the UE that the visited network is VCC capable and transfer the VDN and the VDI if needed, the following alternatives are possible.
i. during registration (e.g., in a SIP 200 OK message); or
ii. when replying to an IMS emergency call origination (e.g. in the SIP 200 OK message); or
iii. when replying to a PS mode Attach request (e.g. using the Network Feature support parameter in 3GPP TS 24.008); or
iv. when replying to a CS Emergency call origination (e.g. in a Facility parameter in a CONNECT message defined in 3GPP TS 24.008).
Alternative (e) would be suitable for wireless networks (such as UMTS, GPRS and GSM networks) and could be possible for WLANs. It also avoids any point-to-point signaling impacts to the UE. Alternative (f), which is applicable to IMS originated calls, avoids SIP impacts and could fit in with the need to provide local emergency numbers to a UE from some server in the visited network. The address of this server could be obtained by the UE using either DHCP or a DNS query on some known Fully Qualified Domain Name (FQDN) containing the visited network's known domain name (e.g., based on the visited network's MCC and MNC) and some fixed user name—e.g. “emergency-support@<visited network domain>”). As a variant, VCC capability (and VDN and VDI addresses if needed) could be signaling directly when the UE uses DHCP to discover the P-CSCF and DNS server addresses.
Alternative (g.i) may only be valid for authorized UEs while alternatives (g.ii) (g.iii) and (g.iv) are valid for authorized and unauthorized UEs.
Alternative (h) can be valid for all UEs and may use signaling proprietary to each home network.
III.C. Required Signaling Changes
The SIP signaling changes required to support alternatives (c), (d) and (g) (described in sections III.A and III. B above) could be supported in at least four different ways.
As one example of alternative (j), the UE could indicate its support of VCC in the SIP REGISTER message by including the Supported SIP header field containing a new option tag indicating VCC support. The 200 OK returned by the visited network P-CSCF could then include the same option tag if the visited network supports VCC plus the VDN and VDI (if needed) in a new SIP extension. As another example, the same exchange could occur during call establishment in the SIP INVITE and 200 OK. The same examples apply to alternatives (k) and (l) but with the VCC indication and/or VCC related information conveyed using new SDP attributes.
In order to avoid SIP and other point-to-point signaling impacts between the UE and visited network on the air interface, some combination of alternatives (a), (b), (c), (e), (f) and (h) can be used. However, allowing SIP and CS domain signaling impacts for the UE can avoid impacts to the home network and support VCC for unauthorized UEs—e.g. using alternatives (d.ii) (d.iii), (g.ii), (g.iii) and (g.iv).
IV. IMS Emergency Call Origination
Emergency call origination could occur as defined in 3GPP TS 23.167 but with some changes to negotiate usage of VCC. In particular, in order to preserve continuity of location support as well as continuity of the voice call following any domain transfer, either the E-CSCF or P-CSCF in the visited network would need to send the SIP INVITE (for the IMS emergency call) to the before invoking the LRF to obtain or verify location and select the destination PSAP. The VCC Application would then anchor the incoming call leg and originate a new outgoing call leg through the E-CSCF towards the PSAP. The E-CSCF is thus invoked on the outgoing call leg from the VCC Application. On receiving the SIP INVITE from the VCC Application, the E-CSCF would perform normal location and routing as defined in TS 23.167 and transfer the call to the PSAP either via IP or through a Media Gateway Control Function (MGCF) and the Public Switched Telephone Network (PSTN). Performing location and routing as part of the outgoing call leg from the VCC Application is essential in order that the association with the anchor Location Retrieval Function (LRF) remain preserved throughout the duration of the call. The continued association with the anchor LRF will enable continuity of location support. In particular, when the call is finally released, the E-CSCF will still be on the call signaling path regardless of the number of preceding domain transfers and will thus be able to inform the LRF that the call was released, thereby enabling the LRF to release its record of the call in compliance with requirements in 3GPP TS 23.167.
An exemplary solution to support VCC calls originated in the CS (circuit switched) domain is illustrated in
In step 2 of
After the emergency call has been established between UE 810 and the PSAP in
The above procedure preserves support for existing PSAP routing options (e.g. using cell ID or an interim location estimate), may not require any new impacts to MSCs and supports accurate location retrieval by the PSAP in the manner currently defined in 3GPP TS 23.167 and TS 23.271. It also enables CS originated emergency calls to be sent to IP capable PSAPs.
In the case of 3GPP2,
VI. Domain Transfer
Domain transfer can occur in a very similar manner to that for normal VCC as defined in 3GPP TS 23.206.
VI.A. Domain Transfer IMS to CS
Two alternative procedures are described here to support domain transfer for an IMS emergency call from the IMS domain to the CS domain when the UE moves out of IMS coverage and into CS coverage. In procedure A described in this section, the VCC capable UE behaves as for normal VCC (described in 3GPP TS 23.206) and originates a new call leg in the CS domain to the VCC Application using the VDN obtained from the visited or home network using any of alternatives (e), (f), (g) or (h) described in section III.B above.
VI.A.1. Domain Transfer IMS to CS—Procedure A
In one embodiment, procedure A is applicable to a UE 1110 that has sufficient credentials to register in the new visited network supporting the CS domain and places limitations on the continuity of support for providing further UE location updates to the PSAP. However, the procedure has the advantage of being compatible from the UE perspective with IMS to CS domain transfer for normal VCC.
In one embodiment, continuing support of location after procedure A has transferred the UE to the CS domain may be restricted as follows. If the PSAP sends a request to the anchor LRF to obtain the location of the UE, it may not be possible for the LRF to continue using the same procedure to obtain location as it may have been using (or expecting to use) while the UE was in the IMS domain. For example, if the LRF was using OMA SUPL based on UDP/IP, TCP/IP and/or SIP transport between the LRF and UE, the loss of access to the PS domain by the UE following IMS to CS domain transfer may prevent further use of SUPL. In addition, the LRF may not be able to use the control plane location solutions defined in 3GPP TS 23.271 for CS emergency calls (e.g., in clause 9.1.3 of 3GPP TS 23.271) because it may not know the VMSC address. However, the LRF could use the more general CS-MT-LR procedure described in clauses 9.1.1 and 9.1.2 of 3GPP TS 23.271 in which the LRF, behaving as or accessing a Gateway Mobile Location Center (GMLC), obtains the VMSC address by querying the UE's home HLR/HSS. A disadvantage of this, however, is that the UE's HLR/HSS will need to support the CS-MT-LR query procedure and there may be billing issues between the visited network and home network (since the home network may not be aware of the emergency call significance).
VI.A.2. Domain Transfer IMS to CS—Procedure B
In an alternative embodiment, procedure B, which enables IMS to CS domain transfer, would be applicable to a UE whether or not it has sufficient credentials to register in the new visited network and enables continuity of location support without limitation. However, in one embodiment, this procedure may be restricted to domain transfer between networks belonging to the same operator. Furthermore, procedure B requires a new variant of VCC domain transfer in the UE in which knowledge of a VDN is not needed.
In one embodiment, in step 1 of
The indication in (m) can be conveyed explicitly or implicitly to the UE using any of the alternatives (alternatives (e), (f) or (g)) described in section III.B for conveying VCC related information to a UE.
The determination in (n) could be based on detecting the same operator identification in the original visited domain and new visited CS domain—e.g. the same MCC-MNC. Determination might instead be based on system broadcast information received from the new visited network (e.g. information that the new visited network supports procedure B and possibly the identifications of other networks with which procedure B is supported). Alternatively determination of both (m) and (n) might be based on information stored in the SIM/USIM for the UE (e.g., as allowed in (o)) identifying all operators who have an arrangement to support procedure B.
Besides allowing domain transfer for unregistered UEs, procedure B also enables the anchor LRF to make use of the normal location procedure defined in 3GPP TS 23.271 (e.g., in clause 9.1.3) to locate a UE that has originated an emergency call. This is enabled due to steps 2 and 3 in
In one embodiment, a further aspect of procedure B is that the call origination procedure at the VMSC can be identical to that for a normal circuit mode emergency call (e.g., as defined in 3GPP TS 23.271 and joint TIA/EIA/ATIS J-STD-036) and/or identical to that for VCC support for a CS originated emergency call as described in
In the case of 3GPP2,
VI.B. Domain Transfer CS to IMS
Two alternative procedures are described herein to support domain transfer for an emergency call from the CS domain to the IMS domain.
VI.B.1. Domain Transfer CS to IMS—procedure C
In procedure C described in this section, the VCC capable UE behaves as for normal VCC (described in 3GPP TS 23.206) and originates a new call leg in the IMS domain to the VCC Application using the VDI obtained from the visited network or home network using any of alternatives (e), (f), (g) or (h) described in section III.B above. The call is treated like a normal originating SIP call and thus is only applicable to a UE that has sufficient credentials to register in the new visited network. It is illustrated in
Once procedure C has been completed, it will be possible to continue location support for the UE because the LRF should now have the UE's IP address and can thus invoke OMA SUPL (or any other location solution involving IP transport such as 3GPP2 X.S0024). However, use of the 3GPP control plane solution to enable location of the UE for GPRS access will only be possible using the more general PS-MT-LR procedure described in clauses 9.1.1 and 9.1.6 of 3GPP TS 23.271 in which the LRF queries the UE's home HLR/HSS for the visited SGSN address.
VI.B.2. Domain Transfer CS to IMS—Procedure D
In an alternative embodiment, procedure D supporting CS to IMS domain transfer would be applicable to a UE 1410 whether or not it has sufficient credentials to register in the new PLMN. The procedure places fewer restrictions on continued location support.
Various aspects of the disclosure have been described above. It should be apparent that the teachings herein may be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein is merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, such an apparatus may be implemented or such a method may be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein. As an example of some of the above concepts, in some aspects concurrent channels may be established based on pulse repetition frequencies. In some aspects concurrent channels may be established based on pulse position or offsets. In some aspects concurrent channels may be established based on time hopping sequences. In some aspects concurrent channels may be established based on pulse repetition frequencies, pulse positions or offsets, and time hopping sequences.
Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
It is understood that any specific order or hierarchy of steps in any disclosed process is an example of a sample approach. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.
The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal (or UE). In the alternative, the processor and the storage medium may reside as discrete components in a user terminal (or UE).
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Patent | Priority | Assignee | Title |
10178522, | Aug 02 2005 | Qualcomm Incorporated | VoIP emergency call support |
10348781, | Dec 27 2009 | AT&T Intellectual Property I, L.P. | Method and apparatus for enabling registration of aggregate end point devices through provisioning |
10674431, | Jan 17 2018 | T-Mobile USA, Inc. | Systems and methods for cellular network service allocation |
10708748, | Aug 02 2005 | Qualcomm Incorporated | VoIP emergency call support |
10827392, | Nov 10 2009 | Telefonaktiebolaget LM Ericsson (publ) | Handover delay optimization |
10869235, | May 14 2008 | Huawei Technologies Co., Ltd. | Method and apparatus for negotiating security during handover between different radio access technologies |
11178597, | Jan 17 2018 | T-Mobile USA, Inc. | Systems and methods for cellular network service allocation |
11576089, | May 14 2008 | Huawei Technologies Co., Ltd. | Method and apparatus for negotiating security during handover between different radio access technologies |
8670443, | Dec 26 2008 | NEC Corporation | Communication system, femto-cell base station, and communication method |
9143538, | Nov 03 2008 | AT&T Intellectual Property I, L.P. | Method and apparatus for enabling registration of endpoint devices through provisioning |
9160772, | Dec 27 2009 | AT&T Intellectual Property I, L.P. | Method and apparatus for enabling registration of aggregate end point devices through provisioning |
9294964, | Nov 10 2009 | TELEFONAKTIEBOLAGET L M ERICSSON PUBL | Handover delay optimization |
9686326, | Dec 27 2009 | AT&T Intellectual Property I, L.P. | Method and apparatus for enabling registration of aggregate end point devices through provisioning |
9788181, | Aug 02 2005 | Qualcomm Incorporated | VOIP emergency call support |
9854421, | Jun 12 2006 | Apple Inc. | Transfer of emergency services session between disparate subsystems |
9949190, | Oct 31 2013 | Samsung Electronics Co., Ltd. | Method and apparatus for controlling WLAN |
Patent | Priority | Assignee | Title |
20030026245, | |||
20050233727, | |||
20060291487, | |||
20070014281, | |||
20070149166, | |||
WO3009627, | |||
WO3049467, | |||
WO2006078212, | |||
WO2007072462, |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Apr 25 2007 | Qualcomm Incorporated | (assignment on the face of the patent) | / | |||
May 01 2007 | EDGE, STEPHEN W | Qualcomm Incorporated | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 019243 | /0690 |
Date | Maintenance Fee Events |
Aug 05 2016 | REM: Maintenance Fee Reminder Mailed. |
Dec 25 2016 | EXP: Patent Expired for Failure to Pay Maintenance Fees. |
Date | Maintenance Schedule |
Dec 25 2015 | 4 years fee payment window open |
Jun 25 2016 | 6 months grace period start (w surcharge) |
Dec 25 2016 | patent expiry (for year 4) |
Dec 25 2018 | 2 years to revive unintentionally abandoned end. (for year 4) |
Dec 25 2019 | 8 years fee payment window open |
Jun 25 2020 | 6 months grace period start (w surcharge) |
Dec 25 2020 | patent expiry (for year 8) |
Dec 25 2022 | 2 years to revive unintentionally abandoned end. (for year 8) |
Dec 25 2023 | 12 years fee payment window open |
Jun 25 2024 | 6 months grace period start (w surcharge) |
Dec 25 2024 | patent expiry (for year 12) |
Dec 25 2026 | 2 years to revive unintentionally abandoned end. (for year 12) |