TW200816752A - System and method for supporting voice call continuity for VoIP emergency calls - Google Patents

Abstract

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.

Description

200816752 IX. DESCRIPTION OF THE INVENTION: TECHNICAL FIELD The present disclosure generally relates to a system and method for effectively supporting Voice Call Continuity (VCC) for Voice over Internet Protocol (VoIP) emergency calls. [Prior Art] Voice Call Continuity (VCC) is a feature that is being standardized by the Third Generation Partnership Project (3GPP) and the Third Generation Partnership Project 2 (3GPP2). The definition of VCC is given by 3GPP in the publicly available document 3GPP TS 23.206 ('Voice Call Continuity between CS and IMS; Stage 2'). 3GPP2 also gives the definition of VCC in the same publicly available document 30??2 0042-001-0 (nVoice Call Continuity between IMS and Circuit Switched Systems-Stage 2''). Both definitions of VCC are very similar, and when the wireless terminal exchanges between wireless access using a support circuit mode and wireless access using a VoIP support, it supports a wireless terminal to a certain The continuity of a voice call from another device (wireless or non-wireless). In particular, the use of VCC avoids having to release a call (eg, a circuit mode call) and re-establish a call (eg, using VoIP) when the user exchanges access, which can result in significant delay and is in progress. The user in the user is causing interference and may be unable to re-establish the call. Specific examples of wireless access networks that support circuit modes are sometimes referred to as circuit switched (CS) domains, including mobile communication using wideband code division multiple access (W-CDMA) and cdma2000 1X, general purpose Mobile Telecommunications 120633.doc 200816752 System (UMTS). Examples of wireless access networks that support ν〇ΙΡ include ports %^W-CDMA, cdma2000 1XEV-D〇 (evolution data optimization), and various wireless LAN (WLAN) and WiMax networks. In some cases, the same access network (eg, UMTS W-CDMA) can support both circuit mode and %1?, but requires the user's wireless terminal to use only one of them (any time) for a particular call. . 〇Ο When a wireless user loses coverage of a particular WLAN and needs to use another-access network, sometimes the ongoing call can be handed over from _ wireless network to another network without Interrupt service (provided that this type of access (circuit mode or ν〇ΙΡ) remains unchanged). However, when (for example, because the new access network does not support the previously used access type) and the type of access needs to be changed, it usually releases the call and re-establishes the δ haitong again using the new access type. Beta tongue. Vcc is a capability that can be handed over between v〇Ip and circuit mode without interruption. Currently, both 3GPP and 3GPP2 define vcc' for normal non-emergency calls and vcc may not explicitly support emergency calls using circuit mode or νοΙΡ originating. This is due to the fact that the solution for vcc is the best solution for both the 3GPPA3GPP2 and the solution for supporting circuit mode and v〇IP emergency call. The main reason for this incompatibility is that the solution to support emergency calls relies on the support from the network that currently provides services to the unemployed (called the visited network), and the solution requires the user. Song support in the local network (even if § is different from the network you are accessing). Lack of VCC support for emergency calls咅咗 #麦Μ未者··If wireless users need 120633.doc 200816752 in different access networks (or in the same access network) in the use of circuit mode and use VoIP If you make changes, you will have to release the calls and re-issue them. For example, this is because the user has moved the location or the current access network is blocked or subjected to some other abnormal condition. This may be particularly disadvantageous because if the user re-originates the call, the call may not pass to the same Public Safety Response Point (PSAP) operator (i.e., the same person) as before. In addition, if a callback number is not provided when the call is first established (for example, the wireless terminal is in the original access network)

If there is no proper authorization in I), the PSAP operator may not be able to re-send the call. Therefore, the ability to extend VCC to support emergency calls has advantages. SUMMARY OF THE INVENTION As described in 3GPP TS 23.206 ("Voice Call Continuity between CS and IMS; Segment 2"), VCC mainly supports a new call called VCC Call Continuity Control Function (VCC CCCF). In the IMS (IP Multimedia Subsystem) entity, it is also referred to as a \/^ application or (in some specific environments) a domain transfer function in a subsequent version of J. As described in 3GPP2 draft X.P0042-001-0 (''voice call continuity between IMS and circuit-switched systems--section 2Π), VCC is supported by a VCC Application Server (VCC AS). The VCC application server is an entity similar to the 3GPP VCC application. Both the 3GPP VCC application and the 3GPP2 VCC AS are defined and located in the local network of the calling wireless user. This definition is related to VoIP in 3GPP TS 23.167. The current solution defined by the IMS emergency call is incompatible with the 3GPP2 solution ("120633.doc 200816752 with -IP emergency service") as defined in 3GPP2 X.P0049-000-0, where IMS VoIP emergency call Support is limited to the network you are accessing. So, IMS emergency Not support VCC, unless define a new method or VCC unless IMS emergency calls routed through the local network for the Internet access.

Ο The method disclosed in this paper uses the former solution because the local network support for IMS emergency calls can significantly change the current solution for v〇Ip emergency calls but introduces many new problems, such as reliable Sexual issues, support for required requirements in the countries visited, and possible delays. This local network-based solution will also be incompatible with IMS emergency calls that support unauthorized users (for example, in the absence of a roaming agreement between the visited and the local network). The local network solution will also be incompatible with supporting C S emergency calls, as these CS emergency calls are also supported on the visited network. The method disclosed herein can achieve vcc support for emergency calls and has the following capabilities: • Support for the transfer of IMS (VoIP) to circuit switched (cs) domains for an emergency call originating in the IMS (VoIP) or CS domain • Supports the transfer of CS to IMS (VoIP) domain for emergency calls originating in 1"3 (¥〇1?) or (::8 domain) • Supports unauthorized wireless user equipment (UE) • Support Unauthorized UE - where the UE is not authorized to use the non-emergency call access network

• Support for UEs on the local network and when roaming • After an access network vcc to Jiang 5 brothers and six 仏Λ ^ Branch to another access network, mention 120633.doc 200816752 for continuous positioning support positioning Support usually means, _ PQ Λ Β, SAP obtains the geographic location (eg, precise latitude and longitude) of the wireless user who initiated the emergency call when the call is initiated and/or during a subsequent call. ability. Currently, forced circuit mode emergency calls are available in, for example, 35 continents and North America, and it is likely that forced emergency calls will soon be available. For positioning, 'continued support means that after changing the access type (for example, changing from ν〇ΙΡ to 电路 circuit mode), the PSAP can still obtain the location of the wireless user. Other aspects, advantages, and novel features of the invention will become apparent from the Detailed Description. [Embodiment] I. Wireless communication system This exemplary embodiment uses a spread spectrum wireless communication system to support a broadcast service. Wireless communication systems are widely deployed to provide various types of communication, such as voice, data, etc. These systems can be based on Code Division Multiple Access (CDMA), Time Division Multiple Access (TM), Orthogonal Frequency. Multiple Access (〇FDMA), 3GPP LTE (Long Term Evolution) radio access, 3Gpp2 uMB (Super Mobile Broadband), WiMax or some other modulation technology. A system can be designed to support one or more standards, such as · Provided by an alliance called the Second Generation Partnership Program (referred to herein as 3Gpp)

The standard and the standard are embodied in a set of files, including: D〇cument 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 120633.doc 200816752 24.008(lfMobile 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)'f); Standards provided by the Alliance of Partner Program 2" (referred to herein as 3GPP2), including: Document Nos. X.P0042-001-0 (nVoice Call Continuity Between IMS and Circuit Switch Systems), o X .P0049-000-0(,fAll-IP Emergency Servicesn) ^ and X.S0024(,fIP-Based Location Services''); the TIA/EIA/ATIS J-STD-036 (''Enhanced Wireless 9-1- 1 Phase II”) and related IETF RFC files, such The IETF RFC files include: IETF RFC 3261 (,, SIP: Session Initiation Protocol'') and IETF RFC 2327 (''SDP: Session Description Protocol''). The above cited standards and references are incorporated herein by reference. 1 is used as an example of a communication system 100 that can support a number of Q users and is capable of implementing at least some aspects and embodiments of the present invention. In Fig. 1, reference numerals 102A to 102G refer to cells, reference numerals 160A to 160G refer to node B, and reference numerals 106A to 106J refer to an access terminal, or a user equipment (UE). Can use any of a variety of algorithms and methods to

• Transmission in the scheduling system. System 1 provides communication for a number of cells 102A through 102G, each of which is served by a corresponding node B 1 60A through 1 60G. In the exemplary embodiment, some of the nodes b 160 have multiple receive antennas while the other nodes have only one receive antenna. Similarly, some nodes B 1 60 have multiple transmit antennas, while others have 120633.doc -10- 200816752 single transmit antennas. There is no limitation of the combination of the antenna and the receiving antenna. Therefore, the node 叮 is 叮, the radiant antenna and the single receiving antenna, or have multiple connections σσ Lianggu ~ 1 antenna and - early The transmitting antenna, or both, has one or more transmitting and receiving antennas. The terminals (or UEs) i〇6 within the coverage area can be fixed (i.e., stationary) or acted upon. As shown in Fig. 1, various terminals (or UEs) 106 are distributed throughout the system. On any of the saga, ‘depending on whether to use softswitch

或 or whether the terminal (small) is designed and operated to receive (same or sequential) multiple transmissions from multiple Node Bs' each terminal (or ue) i〇6 and at least: a taxi may be multiple Node B 16 进 communicates on the downlink and uplink. The downlink refers to the transmission from the Node B to the terminal (or the uplink, and the uplink refers to the transmission from the terminal (or UE) to the Node B. In the exemplary embodiment, some terminals The machine (or ue) i〇6 has multiple receiving days and lines while the other terminals only have one receiving antenna. In Figure i, the Node B 160A transmits data to the terminal (or UE) on the Yanhai downlink. 106A and l6J, the node B i6〇B transmits the data to the terminal (or UE) 106B and 106J, and the node b 16〇c transmits the data to the terminal (or UE) 106C, etc. The increasing wireless data transmission Demand and the expansion of services that can be provided via wireless communication technologies have led to the development of several specific data services. One service is called High Rate Packet Data (HRPD). k,, eia/tia_ IS856 cdma2000 High Rate Packet Data Air An exemplary HRPD service is provided in the Interface Specification (which is referred to as the "HRPD Specification"). The HRPD service is typically an overlay of a voice communication system, 120633.doc -11 - 200816752: providing for transmission in a wireless communication system Material package is valid As the number of tributary transmissions and the number of transmissions increase, the finite bandwidth used by the radio transmission becomes a key resource. Therefore, there is a need for a schedule, a communication, and a transmission to optimize the available. The advantage of bandwidth is to use an efficient and fair method. In the exemplary embodiment, the system 100 of Figure 1 is consistent with a wireless access class system having HRPD services. Figure 2 is an exemplary 3GPP. W-CDma communication is your 々金^ < 1 port simplified system

U. As described above, 'a radio network controller can be used as defined in the context of 3GPP', 13) provides a network between... and various distributed--geographical regions (4) (as defined in the context of 3Gpp) Interface. For convenience of explanation, only one node B 160 is displayed. Typically, the geographic area is subdivided into a number of smaller areas called cells 1 shown in Figure 1). Each Node B 16〇 is configured to serve all user equipments in its corresponding cell (Qing Qi for service. In some high-traffic services, the area 102 can be divided into several sectors, each _ sector Each of the Node Bs 160 serves the sector. In the illustrated exemplary embodiment, the UE 106A_C is shown communicating with the Node B. Each ue i〇6a_c can be via one or more of the RNC 130. The nodes 3 16 access the network 104 ' or communicate with other ue 1 〇 6. The modern communication system is designed to allow multiple users to access a common communication medium. Many multiple access technologies are used in this technology. Conventional, Example T, Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Domain Dividing Re-Access Polarization Division Multiple Access, Code Division Multiple Access (CDMA), and other similar multiple storage Take the technology. The multiple access concept allows one more than 120633.doc -12- 200816752 Ο

Channel assignment method for CJ user access-common communication links. These channel assignments can take a variety of forms depending on the particular multiple access technology. By way of example, in an FDMA system, the total frequency spectrum is typically divided into a number of smaller sub-bands, and each use-use obtains its own sub-band for accessing the communication key. Alternatively, as in the Fdma variant of, for example, FDMA, each user may be allowed to access a number of different frequency channels. Alternatively, in a TDMA system, each user feeds the entire frequency spectrum during the periodic reproduction time slot. In a CDMA system, each user can always receive the entire frequency (four)' but can distinguish its transmission by using the code. An example of a communication system that supports transmission and is suitable for scheduling transmissions to multiple users is illustrated in FIG. The following is a detailed description of Figure 3, which specifically refers to the section "16" and "13" connected to a packet network interface 146. View 130 includes a -channel scheduler (10) that implements a scheduling algorithm for transmission within the system. The channel scheduler 132 determines the length of a service inter-office based on the rate at which the remote device receives the bedding time (as indicated by the most recently received signal), during which the data is intended to be transmitted. To any such specific remote station. The service interval may be discontinuous in time, but may occur every n slots. According to one embodiment, the first portion of the packet is transmitted during the first time in the first slot and the second portion is transmitted at the subsequent time after the four slots. Same = Any subsequent portion of the packet is transmitted in a plurality of slots having a similar four-slot spread (i.e., four slots spaced apart from one another). According to an implementation L, the instantaneous rate of the received data Ri determines the length of the service interval Li associated with the specific data sequence. In addition, the channel scheduler 132 selects a particular data queue for the transfer wheel. After 120633.doc • 13 - 200816752, the relevant amount of data to be transmitted is retrieved from a data queue 172 and provided to channel element 168 for transmission to the remote station associated with data queue 172. As discussed below, the channel scheduler 132 selects the queue to provide the material, and transmits a query containing the weight associated with each of the columns in the next service interval to transmit the material. The weight associated with the transport queue is then updated. Ο u

The read 13 is interfaced with the packet network interface 146, the public switched telephone network (PSTN) 148, and all of the nodes b in the communication system (for simplicity, only one node B 16 is shown in Figure 2B). The RNC 13 coordinates the communication between the remote stations in the communication system and other users connected to the packet network interface 146 and the psTN 148. The PSTN 148 interfaces with the user via a standard telephone network (not shown in Figure 2B). The RNC 13G includes a number of selector elements 136, but for simplicity only one selector element is shown in Figure 4. Each selector element 136 is assigned control - communication between one or more Node Bs and a remote station (not shown). If the selector element 136 has not been assigned to a given remote station, then the call is made = the processor 141 needs to call the remote station. Then, the call control control jie 14 1 directs the node B 1 60 to place a call to the remote station. The data source m contains a quantity of resources to be transmitted to a given remote station. The second cultivating source 122 provides the data to the packet network interface 146. The packet network interface 146 receives the material and routes the material to the (four) device component. I: selects the device component 136 to transmit the data to each of the target remote end 1 p, point B 1 60. In the exemplary embodiment, B 1 60 0 & 4 points are points, and a data stored in the data to be transmitted to the remote station is queued 120633.doc -14- 200816752 172 Passing to the channel element (6) in the form of a data packet. In the exemplary embodiment, 'on the forward key path, - the package, refers to a certain amount of the maximum value of the bit data and the quantity = the fixed groove, , the data transmitted to the target remote station (example:::: channel element 168 will insert control palm for each data packet. In the (IV) illustrative embodiment, channel element 168 implements _ j Γ

CJ checksum, CRC, data packet and control station code ^ Block, TM 兀 composition - format packet. In the exemplary embodiment, channel element 168 then encodes the formatted + formatted packet and interleaves the symbols within the money code packet: in the embodiment of the invention, the code is used to cover the interleaved material and The code is extended. The extension is supplied to the RFm7G, and the Lions (4) signal is used for integral modulation, economy, and amplification. The forward link signal is wirelessly transmitted to the link via the antenna. At the remote station 1〇6, the antenna receives the positive link signal and will route it to a/receiver. The receiver performs the wave, amplification, and integration of the signal: = two quantities. The digitized signal is provided to a demodulator, which is digitized by a short PNI and PNQ code at & solution (4). The line is despread and de-covered using a Walsh code. The poor material is provided to a decoder that performs the inverse processing of the node βι number processing function, specifically deinterlacing, decoding, and verifying functions. The decoded data is provided to a data slot. 120633.doc 200816752 FIG. 4 illustrates another embodiment of a UE (in a 3Gpp context) or an AT (in a 3GPP2 context) 1-6 according to the present patent application, wherein the UE or AT 106 includes a transmitting circuitry 264 (including pA 3〇8), receiving circuitry 408, throttling control 3〇6, decoding processing unit 258, processing unit 302, carrier control unit 412, and memory 416. The throttle control unit 〇6 constructs at least one set of throttle rules such as those described above. The throttling rules provide means and methods for controlling the transmit power on the RL. (In the following discussion, the present invention will be primarily described in the context of a 3GPP architecture reference model. However, it should be understood that with the disclosed information, those skilled in the art can easily implement a 3 (5 卯 2 network architecture). Or modify and use the invention in other network architectures. II. Architecture Reference Model

Figure A,,,, and the reference model of the 3GPP implementation of the current domain transfer procedure (as disclosed in 3 GPP jS 23.206). In general, the domain transfer program j achieves voice continuity between the S domain 500 and the IP-based domain 51〇 while maintaining an active voice, all with a VCC, while using the VCC-enabled UEs 516 and 518. The domain transfer program associated with the user's call and including the start and subsequent transfer is executed and controlled by the domain transfer function in the user's local 1MS network 5 1G, and the domain transfer function is formed in FIG. 5A. Part of the program 504. ~ As shown in Figure 5A, static anchoring techniques are used to facilitate the use of VCC users with VCC-enabled UEs 516 and 518 at the time of dialog setup.

As a stand-up 3pcc (third-party call control) function. Call the DTF: € (: user 8 < 80 ^ 514 to perform the initial or end of the initial filter 120633.doc -16 - 200816752 '). The DTF inserts itself into the communication path 0 of the VCC user voice call made by the Vcc UEs 516 and 518 by using a route 3pCC function. For an initial voice conversation, the dtf terminates the access line from the user to establish a far-end remote line; for a final voice conversation, the DTF terminates a remote line from the far end And establish an access line towards the user. The DTF then coordinates the call control and communication exchanges between the access line and the far line associated with a voice call of a vcc subscriber. As shown in FIG. 5A, when the access line is established via the CS domain 500 and the IMS 510, respectively, 3pcc exists at the kDTF to clarify its use for the domain transfer procedure. Figure 5A illustrates the 3 pcc at 0117 and its use for the domain transfer procedure, so it only shows the messaging and bearer components associated with implementing and performing the domain transfer. Figure 5B shows an exemplary reference model of 3GPP that is different from the standard 3GPP reference model for normal VCC (disclosed in 3gpp TS 23.206 and shown in Figure 5A). The difference from the reference model of VCC supporting IMS (VOIP) emergency calls in 3GPP TS 23.206 includes: using the VCC application 572 in the visited network instead of using the local vcc application (the display is the component in Figure 5A) 504), and using the emergency call-to-talk control function (E-CSCF defined in 3GPP TS 23·167) 576 in the visited network instead of using the servo CSCF in the local network as in 3GPP TS 23.206 ( The S-CSCF 'is shown as element 5 14 in Figure 5A). The visited network agent CSCF (P-CSCF) is also part of the model, but it is not shown in Figure 5B. Note that the VCC application 752 in FIG. 5B may also be referred to as 120633.doc • 17-200816752 VCC Call Continuity Control Function (CCCF), a VCC Application Server (VCC AS), or a Domain Transfer Function (DTF). . Figure 6A shows a pair of reference models supplemented by the model in Figure 5A, but from the standpoint of defining services in 3GPP TS 23.167. The components include a location retrieval function (LRF) 610, a user equipment (UE) 620, a proxy CSCF (P-CSCF) 630, an emergency CSCF (E-CSCF) 640, and an S-CSCF 650, such as those in 3GPP TS 23.167. Works as defined. Figure 6B includes the same reference model as Figure 5B, however this figure is shown from the perspective of the model supporting IMS (VoIP) emergency calls as defined in 3GPP TS 23.167. In FIG. 6B, unlike the reference model disclosed in 3GPP TS 23.167 (and shown in FIG. 6A), the VCC application 660 has an interface to the E-CSCF 640 in the visited network and may have a pass to access. The interface of the P-CSCF 630 in the network. As defined in 3GPP TS 23.206, the emergency call will be anchored within the VCC application. In addition, the positioning support will be anchored in the LRF 6 10 within the visited network so that the PSAP can continue to obtain updated positioning estimates from the LRF 610 regardless of how the UE 620 changes its servo network and servo domain. LRF 610 can be referred to herein as an anchor LRF. By replacing the VCC application of Figure 5B (as element 5 72) with the VCC application of Figure 6B (as component 660) with a VCC AS, a reference model suitable for 3GPP2 can be obtained. As described below in the description of 3GPP, it should be understood (unless otherwise noted) that the same description can be used to define a VCC support method for 3GPP2 emergency calls, as long as certain terms and objects are changed from 3GPP context to 3GPP2 context. In particular, the mentioned 3GPP VCC application entity can be replaced by a 3GPP2 VCC AS. It may also be substituted for some other 3GPP objects mentioned below, for example, a 3GPP2 MPC (Motion Location Center) may be substituted for a 3GP GMLC (Gateway Action Location Center). III. VCC Support Negotiation For a normal VCC, the local network (e.g., the local S-CSCF) can know the UE's VCC capabilities based on subscription information obtained from the UE Local Subscriber Server (HSS). The UE may already know the VDN (E.164 voice domain transfer number) and VDI (Voice Domain Transfer SIP URI) of the VCC support and domain transfer of the local network, or other numbers and addresses equivalent to the VDN and VDI, thereby VCC can be implemented without any explicit negotiation and information transfer when a voice call is originated for the first time. While it is desirable to support VCC for CS and VoIP emergency calls in the same manner, some explicit messaging changes may be required. For example, if there is no negotiation for VCC support, then it is difficult to support VCC. This is because when the UE changes the domain, it will not know whether the old and new domains can cooperate to support the VCC in a roaming situation, and therefore it will not know whether the existing call can continue. In the following discussion, it is assumed that VCC support for IMS emergency calls is provided in the visited network. III.A. The method for communicating that the UE has the VCC function is to convey to the visited network (eg, P-CSCF, E-CSCF or Voice Mobile Service Switching Center (VMSC)) that the UE has the VCC function, and the following possible solutions exist. . (a) If the visited network is a local network for the UE, it can discover the VCC capabilities of the UE from the UE subscription information in the local HSS. 120633.doc -19- 200816752 (b) The visited network can assume that the UE has the function of VCC (regardless of whether the UE is truly available). For example, if the visited network is not a local network and therefore cannot use scheme (a), then the UE can be assumed to have VCC functionality.

(c) the visited network (eg, P-CSCF or VMSC) may be logged in to the local network (for example) from the S-CSCF in response to a Session Initiation Protocol (SIP) REGISTER message (which is defined in the IETF) The UE's VCC capability is found in the 200 OK ' response in RFC 3261 or in a UE subscription message provided by the HLR/HSS to the VMSC. C j (d) The UE may inform the visited network of its VCC capabilities in one of the following ways: i. during registration (eg, in the SIP REGISTER message); or ii. when originating an IMS emergency call (eg, in SIP INVITE information); or iii. when originating a CS mode emergency call (eg, in emergency SETUP information as defined in 3GPP TS 24.008). Q scheme (a) applies to emergency calls originating in the PS (Packet Exchange) domain, and if the UE is not roaming (ie, is served by its local network), then it can be used with 3 〇 ? 8 23.206 The same mechanism used for common 乂 (: (: for non-emergency calls) to discover VCC capabilities. For scenario (b), the visited network assumes that the UE has VCC functionality and is originating The VCC resource is assigned during the emergency call (eg, as explained later in Section IV and Figure 7.) However, if the UE actually has VCC functionality and the emergency call requires a transition between the IMS (VoIP) and the circuit switched domain These VCC resources can only be used. Therefore, although the emergency call itself may not be damaged by 120633.doc -20- 200816752 (this is because the vcc resource is only used for intermediate call communication), it will cause the vcc resource of the UE. Some waste. For the emergency call originating in the domain, the waste may be small, because the number of such calls is usually a small part of all VoIP calls (both emergency and non-emergency). Combine scheme (a) with scheme (b) to The ability to access the Internet only with vcc UE's local network beneath it is not the case, it can further reduce the level of waste. However, for emergency calls originating CS, the level of waste may be more

Ο 冋, because most CS emergency calls will come from at least the original XJE that cannot support VCC at the beginning. Both schemes (a) and (b) avoid the impact on the UE, which is desirable for achieving a common VCC solution for both emergency and non-emergency calls (from the perspective of the UE). Scheme (C) can also avoid the impact on the UE. However, scheme (c) may only be limited to authorized UEs. Solution (di) avoids the impact on the local network, but is also limited to authorized UEs, and the solution (丄(1) and ^上丨) is valid for all ues, but from the perspective of UE, it needs a new one. The VCC variant. ΙΙΙ·Β·Transportation of the vcc function of the visited network To communicate to the UE that the visited network has the vcc function and transfer vdn and VDI (if needed), the following solutions exist. (e) The UE may discover vcc capabilities of the visited network from system broadcast messages or other fixed-type messages that are not proprietary to any UE (eg, WLAN advertisements associated with a particular visited network) (and possibly Discover any of the network base stations and / or VDN and VDI). Such messages may be transmitted to all UEs by the current 120633.doc -21 - 200816752 access point to provide the same information for network information (eg, network identity and support capabilities). (f) The UE may use DHCP or use a hypertext transfer protocol (HTTP) or security from a server in a visited network whose role is to provide information about the emergency call (eg, also including local emergency numbers). HTTP (HTTPS) to discover the vcc capabilities of the visited network and VDN and VDI (if needed). (g) The visited network may indicate its VCC capabilities to its UE in the following situations: i. during registration (eg, in a SIP 200 OK message); or ii. when replying to an IMS emergency call origination (eg In the SIP 200 OK message); or iii. when replying to a PS mode Attach request (for example, using the network feature support parameter in 3GPP TS 24.008); or iv. in replying to a CS emergency call origination (eg , in the Facility parameter in the CONNECT message defined in 3GPP TS 24.008). (h) The local network can download information about the network known to be capable of supporting the emergency call VCC to the UE, or download to the Universal Integrated Circuit Card (UICC) in the UE. For example, the local network can provide the UE with a Mobile Country Code (MCC) and a Mobile Network Code (MNC) for all such VCC capable networks. Additional information such as VDN and VDI used by these networks is also available. Scheme (e) can be applied to wireless networks (eg, UMTS, GPRS, and GSM networks) and can also be used for WLANs. It avoids any point-to-point traffic impact on the UE. Solution (f) applies to IMS originating calls and avoids SIP effects 120633.doc -22- 200816752 and can meet the need to provide a local emergency number from a server in the visited network to a UE. The UE may use DHCP or DNS to obtain the address of the server based on a known fully qualified function variable name (FQDN) containing the known functional variable name of the visited network. (for example, based on the MCC and MNC of the visited network) and a fixed username, for example, ''61^巧6110 strict support@<visited network domain>''. As a variant, the VCC capability (and if VDN and VDI bit addresses are required) can be directly signaled when the UE discovers the P-CSCF and DNS server address using DHCP. The scheme (g.i) may only be valid for authorized UEs, while schemes (g.ii) (g.iii) and (g.iv) are valid for both authorized and unauthorized UEs. Scheme (h) is valid for all UEs and can be used for messaging unique to each local network. III.C. Required messaging changes Supporting schemes 0), ((1) and chemification) (described in sections 111. 8 and 1113 above) The required SIP messaging changes can be supported in at least four different ways. (1) Use the existing SIP title field (for example, Record-Route, Route, Contact) to transfer new messages. (j) Extend the SIP header blocking in SIP REGISTER, SIP INVITE, and SIP 200 OK by creating a new option flag indicating V C C support. To transfer additional VCC information (for example, VDN and VDI), a new SIP extension associated with the Supported VCC option tag will be used.

(k) Extend the dialog description protocol (SDP defined in IETF RFC 2327) in SIP 120633.doc -23 - 200816752 INVITE and SIP 200 OK by defining new IANA registered or unregistered attributes. For example, a new attribute attribute can be used to indicate VCC support, and one or two different value attributes can be assigned to communicate VDN and VDI to the UE (e.g., from an E-CSCF or VCC application). The attributes of the media level (as opposed to the attributes of the conversation level) may be more suitable for selectively defining specific media (e.g., audio) that support VCC. (1) A combination of two or more of the schemes (i), (j), and (k) may be used. For example, the SIP capability can be communicated using only the new support option tag in (1), and (k) The new SDP level value attribute conveys any further VCC information (eg, VDN and VDI). As an example of the scheme (1), the UE can indicate its support for the VCC in the SIP REGISTER message by including the support SIP header field (which includes a new option label indicating VCC support). If the visited network supports vcc and VDN and VDI (if needed) in a new SIP extension, the 200 OK returned by the visited network P-CSCF may include the same option tag. As another example, the same exchange can occur during SIP establishment in SIP INVITE & 200 0K. These same examples can be applied to scenarios (k) and (1), but where new SDP attributes are used to convey VCC indications and/or information about VCC. In order to avoid the impact of SIP and other peer-to-peer communication between the UE on the empty interfacing plane and the visited network, schemes (a), (b), (c), (e), (f) and (h) can be used. a combination. However, allowing SIP and CS domain messaging to affect the UE can avoid the impact on the local network and can support VCC of unauthorized UEs, for example, using (d.ii)(d.iii), (g.ii) , (g.iii) and (g.iv). 120633.doc -24- 200816752 IV. IMS Emergency Call Origination An emergency call origination can occur as defined in 3GPP TS 23.167 with some changes to the VCC negotiation use. In particular, to preserve the continuity of location support and the continuity of voice calls after any domain transfer, the E-CSCF or P-CSCF in the visited network will need to invoke the LRF in order to obtain or verify the location and select the destination. The PSAP previously sent a SIP INVITE (for IMS emergency calls) to the VCC application. The VCC application will then anchor the incoming call line and initiate a new outgoing call line to the PSAP via the E-CSCF. Therefore, the E-CSCF is called from the VCC application on the outgoing call line. When the VCC application accepts the SIP INVITE, the E-CSCF will perform common positioning and routing as defined in TS 23.167 and will be via IP or via a Media Gateway Control Function (MGCF) and the Public Switched Circuit Network (PSTN). The call is transferred to the PSAP. The location and routing of the outgoing call line portion must be implemented in accordance with the VCC application so that the association with the Anchored Location Capture Function (LRF) remains constant throughout the duration of the call. Continuous contact with the anchored LRF will achieve continuity of positioning support. In particular, when the call is finally released, regardless of the number of previous domain transfers, the E-CSCF will remain on the call communication path, and thus will be able to notify the LRF that the call is released, thereby enabling the LRF to follow 30 ?? D 8 23.167 request to release the call record. Figure 7 illustrates the next exemplary call originator and, as a possible option, includes several of the above schemes for negotiating the use of VCC and transferring any VCC related information. Li 7 beginning #着ϋ话J. In this step, the user initiates an emergency call 120633.doc -25 - 200816752. #/银向滞J. The User Equipment (UE) 710 may implement an emergency registration by the visited network P-CSCF 720 and the local network S-CSCF (not shown) as described in 3GPP TS 23.167, if it contains such credentials. Program. The SIP REGISTER message sent by the UE 710 or the SIP 200 OK message returned by the local S_CSCF may indicate to the visited network p_cSCF 720 that the UE 710 has the VCC function. The 200 OK returned by the visited network P-CSCF 720 to the UE 710 may also indicate that the visited network has the Vcc function and may provide one

C I VDN and VDI (if required). #銶3(7^^/7^ "greedy, %〇>). The user equipment (1^) 710 sends an INVITE with an emergency indication to the visited network P-CSCF 720. The INVITE may contain Any positioning object that the UE 710 has. The positioning object is dependent on the access network technology. The INVITE may also indicate the UE's support for the VCC (if this is not communicated to the visited network in step 2), and The identification information of the UE may be included, for example, a SIP and a callback address or number. Q Steps 4a, 4b, and 4c are based on any indication of VCC support in the INVITE or know the VCC support obtained in step 2 or according to the scheme. (a) and/or (b) (described above in Section III.A) Know or assume the support of VCC, P-'CSCF 720 can forward the INVITE in two different ways.

- i. Step 锧 (7; ν Τ / 7 Έ (# 扃,. The P-CSCF forwards the SIP INVITE together with an indication of possible VCC support to an E-CSCF 740. And in step 4b (INVITE (emergency, VCC) )), based on the indication of VCC support in step 4a or due to network policy (for example, assuming all UEs support VCC), E-CSCF 740 forwards the SIP INVITE to 120633.doc -26- 200816752 a VCC application 760; or ii. Step 4c (INVITE). The 戠CSCF forwards the SIP INVITE directly to the VCC application. Step 5 (INVITE) VCC Application 760 Anchor The incoming call line initiates an outgoing line by sending (or sending back) the INVITE to the E-CSCF 740. The INVITE will still carry an emergency indication but no. Instruct the VCC support again. 6 (Population Location J ° E-CSCF 740 as defined in 3GPP TS 23.167 (/ Implement common processing for the establishment of emergency calls. If the location object provided in the INVITE is insufficient to determine the correct PSAP or if the IMS core Need a help with a route determination function (RDF), or require the IMS core to verify the decision The object then sends the capture location request to the LRF 730 to implement the location capture functionality. The capture location request may include identifying information of the UE 7 10 and the IP Connectivity Access Network (IP-CAN) ( For example, MSISDN, IMSI, and/or IMEI), and may include a method of accessing the UE (e.g., UE IP address). Q The capture location requirement may also include any of the positioning objects provided in the INVITE in step 3. The retrieved address request may further include an indication of VCC support and identification information of the VCC application 760 (eg, VDN and 'VDI). However, this may be only later in sections VI.B.1 and VI.B. As described in .2 - required in programs C and D. The step-by-step thinness is positioned. The LRF 730 can obtain a temporary location estimate. The method for obtaining the temporary location estimate depends on the UE 7 1 0 being used. Accessing IMS access technology, and may include using 120633.doc -27-200816752 secure user plane positioning as defined in PS-NI-LR or PS-MT-LR or OMA AD SUPL as defined in 3GPP TS 23.271 ( SUPL) program: "Secure user plane positioning architecture" ', 〇MA TS ULP : user level Positioning protocol ", or other processes formula .LRF 730 may invoke a routing determination function (RDF) to convert the temporary positioning or locating any object received in the step into a 6-bit address of the PSAP. The LRF can record the information received in step 6. Step back to position J. The positioning information and/or PSAP address (obtained in step 7) is returned to the E-CSCF 740. The LRF 730 can also return to identify itself and any correlation information (e.g., ESQK) stored in step 7. For the remainder of the call, the LRF 730 is used as the anchor LRF. #耀%,外;% ^ Based on the positioning information provided in step 8, the E-CSCF 740 uses the PSAP address provided in step 8 or selects an emergency center or may select the PSAP itself, and will include the positioning information and any A request for related information is sent to the emergency center or PSAP 780.

Step 9a (INVITE) sends the INVITE to an MGCF/MGW (media gateway control function/media gateway) 770; and in Q step 9b (IAM), continues the SS7 ISUP to the emergency center or PSAP IAM; or step 9c (INVITE). Send the INVITE directly to the tight center or PSAP 780. - Steps 10a, 10b, and 10c. Intermediary messaging for establishing a call may occur (for example, from a PSAP function) The PSTN returns an SS7 ISUP ACM), which is not shown in the figure. When the PSAP answers the call, the following steps occur: PSAP 780 returns an SS7 ISUP ANM to 120633.doc -28- 200816752 MGCF/MGW 770; And in step i〇b (200 OK), the %0€?/乂0^¥ will return a 200 0 to the ugly 480?; or the step 76>c "2(10)0 magic. The PSAP 780 will have a 200 OK Return directly to E-CSCF 760. #锗""2〇0 (9 幻. E-CSCF 740 returns 200 0K to the VCC application (on the outgoing call line starting in step 5) 760. Step 12 ( 200 OK). If step 4c was used earlier, the VCC application 760 will return a 200 OK to the E-CSCF (used in step 4). On the incoming call line) 740 or P-CSCF 720 (not shown in Figure 7). If in step 2 or before step 2, UE 7 10 does not find support for the visited network to VCC and any associated VCC For information (eg, VDN, VDI), the 200 OK returned by VCC application 760 may indicate support for VCC and may include a VDN and/or VDI. Step 13 (200 OK) 〇 E-CSCF 740 or P-CSCF 720 returns 200 OK to UE 710 (eg, if returned from P-CSCF 720 from E-CSCF). To reduce the impact on VCC application 760, E-CSCF 740 or P-CSCF 720 is not in step 12. The VCC application 760 can place any VCC indication and VDN/VDI in the 200 OK. Then, the UE 710 stores any received VDN and/or VDI. The UE 7 10 and the emergency center 780 in FIG. After establishing an emergency call, the emergency center can request a more accurate location from the LRF 730 using the programs defined in 3GPP TS 23.167 and TS 23.271. V. CS emergency call origination

An illustrative solution to support VCC 120633.doc -29-200816752 calls originating in the CS (Circuit Switched) domain is illustrated in FIG. As described below, in this case, the E-CSCF is invoked from the VCC application on the outgoing call line, and in addition, the MSC can use an existing GMLC MAP query on the incoming call line to the VCC application to correct Route the incoming call line to the VCC application. In this example, the GMLC routes the incoming call line to the VCC application using an IP Multimedia Routing Number (IMRN). As shown below, the GMLC query and the use of IMRN may be partially or completely transparent to the MSC. Step 1 (Start emergency call). In this step, the user initiates an emergency call. Step 2 (emergency establishment). UE 8 10 initiates an emergency voice call in the CS domain by transmitting an emergency setup message to VMSC 83 0 (as defined in 3GPP TS 24.008). The setup message may indicate that the UE supports VCC. Step 3 (Locating the program). The VMSC 830 may initiate a procedure in the RAN to obtain a temporary location estimate for the UE 810 as defined and permitted in 3GPP TS 23.271. Step 4 (MAP User Location Report). Based on the local VMSC 830 policy or based on subscription information obtained from the UE local HLR/HSS or based on any VCC indication received in step 2, the VMSC 830 sends a MAP User Location Report to an Emergency Service Provider (PSAP). In conjunction with the GMLC 8 50, for example, based on the Serving Cell ID and the emergency number dialed, the call is typically sent to the Emergency Service Provider (PSAP). The MAP User Location Report carries the IMSI, MSISDN, IMEI, VMSC address and Serving Cell Identity or SAI of the UE. It also includes any position estimates obtained at step 120633.doc -30-200816752 obtained in step 3. In areas where the VMSC 830 is typically not the GMLC 850 to determine the PSAP (e.g., the European Union), the message may carry the location address of the intended destination PSAP. If the MS provides an indication of VCC support in step 2, the MAP user location report may also carry the indication. Step 5 (MAP User Location Report ACK). The GMLC 850 assumes that the UE 810 supports 乂0: (:, or from the subscription information to determine 1^ support ¥0: (3 (if 1^810 by • local network servo), or GMLC 850 from any of the steps provided in step 4 ¥ (^ indicates to the disc to fix 1 ^ support again (: (:. 〇) \41^ 8 5 0 storage 1; ugly 810 call record, including all the information received in step 4. GMLC 850 assigns the call An IP Multimedia Routing Number (IMRN). The IMRN may be an international ITU E.1 64 ISDN/telephone number, a national ISDN/telephone number or some other number, or a combination of numbers or parameters (eg, by a decimal sequence) Or a plurality of decimal sequences. The IMRN may also be referred to as another name, for example, as a routing number. Minimally, the IMRN implements the call routed to the VCC application 870 in steps 6 and 7 and identifies the Q GMLC. The IMRN may also temporarily identify the call record stored in the GMLC and/or may indicate the PSAP as needed. The GMLC returns a MAP User Location Report ACK to the VMSC 830, the MAP User Location Report • ACK Carrying NA-ESRD or NA-ESRK parameters or some other parameter The IMRN of some other parameter group. The GMLC 850 can also agitate a CS-MT-LR (not shown in Figure 4) by the VMSC 83 to obtain a temporary location estimate for the route or obtain a precise location that is subsequently provided to the PSAP. Estimate. As further explained in Section VI, if a temporary location estimate is obtained in this step instead of in step 3, the program of Figure 8 can be reused to support the domain transfer from IMS to 120633.doc -31 - 200816752 CS. 830 routes the call based on the IMRN received in step 5. If the existing NA-ESRK or NA-ESRD parameters are used to convey the IMRN, the call routing program in the Bay ij VMSC 830 can be used with the ordinary emergency call originator in 3GPP TS 23.271. The call routing program used is the same. Based on the IMRN route, the VMSC 830 routes the call to the MGCF 840 in the visited network. The MGCF 840 is in the visited IMS to the CSCF (not shown in Figure 8). Displaying) an INVITE, or MGCF 840 may be routed directly to E-CSCF 860, an S-CSCF (not shown in Figure 8), or VCC application 870. The INVITE contains the identity of UE 8 10 (eg, as a contact bit) MSISDN Tel U RI) The Ι-CSCF or S-CSCF (not shown) or E-CSCF 860 will augment the PSI-based application server terminal to the VCC application 870 based on the IMRN. Step 8 (INVITE) 〇 The VCC application 870 anchors the incoming call line Q and initiates an outgoing line by sending (or sending back) the INVITE to the E-CSCF 860. The INVITE (e.g., in the SIP INVITE TO header) carries information identifying an emergency call and enabling IMRN recovery (e.g., may include 'unique digits in the IMRN and may not include known fixed digits). The location information (for example, pidf-lo) does not need to be included. Step 9 (Capture Positioning). For example, based on the inclusion of IMRN information in step 8, E-CSCF 860 can send a pick location request to an LRF 850 identified by or associated with the IMRN. The retrieval location request includes the IMRN information received in step 8 and any UE identification (e.g., an MSISDN Tel 120633.doc -32-200816752 URI). The retrieval location request may further include an identification information (e.g., VDN and VDI) for the VCC application that is not supported by the VCc. However, this is only required in the programs c and D described in the later sections VLB1 & VIB2. , step m〇 (g shout < stand). Based on any of the received 2UE identification (eg, MSISDN) in step 9 and/or based on IMRN information, LRF 850 interacts with GMLC 850 and retrieves (}]^1^(:: 85〇 the call stored in step 5 Record the factory record. Using any temporary location information already in the call log, or any temporary location obtained according to step 5 (once this has been completed), or the identity of the established pSAp destination, the LRF 850 will have a PSAP address and possibly The positioning information is returned to the E-CSCF 860. If the Lrf is different from the GMLC, the LRF will provide an anchor point that further supports positioning, and may copy the call record obtained from the GMLC and stored from the E-CSCF receiving (in step 9). The Lrf can return correlation information (eg, ESQK) to the E-CSCF 860 to identify itself and the call record. The LRF can further interact with the GMLC ◎ to agitate a CS_MT-LR program by the VMSC 830 ( Obtaining a precise location estimate for the UE as defined in 3〇ρρ 2 3 · 2 7 1 . If the IMRN provided by the GMLC 850 in step 5 indicates the PSAP and if [the heart is closely related to the GMLC (eg, Part of the same entity) Then, the E-CSCF 860 can use the pSAp address obtained in step 1 and will contain any positioning information and any correlation. A call request for information (eg, ESQK or IMRN) is sent to the emergency center or PsAP. The call request can be sent to the PSTN (not shown) via MGCF/MGW 840, 120633.doc -33 - 200816752 or can be directly Send as a SIP INVITE to an IP-enabled emergency center or PSAP. Step 12 (establish the rest of the CS emergency call). The rest of the S1 shoe is based on the description of the 3D? (:(: €3 originating program occurs between UE 810, VMSC 830, MGCF 840, VCC Application 870, E-CSCF 860, and PSAP. In step 2 of Figure 8, an emergency setup message (defined in 3GPP) The emergency U-parameters in TS 24.008 may include any VCC indication as a new service class (this is because there are currently 3 spare bits so that up to 3 new service classes can be defined). This is in CS. The remaining life expectancy of the mode is operational , do not expect any new emergency category. After establishing an emergency call between the UE 810 and the PSAP in Figure 8, the PSAP can use the program defined in 30??8 23.167 and Ding 23.271 from 1^? 85 0 request A more precise positioning. In particular, the PSAP can identify LRF 850 for any correlation information (e.g., ESQK or IMRN) received from E-CSCF 860 in step 11 of FIG. If steps 9 and 10 have not been performed, the LRF 850 will need to interact with the GMLC 850 as described for step 10 in Figure 8 to retrieve the UE records established in the GMLC 850 in step 5 of Figure 8. For example, the above program may use cell IDs or a temporary location estimate to preserve support for existing PSAP routing options, may not require any new impact on the MSC, and may currently be defined in the manner of 3GPP TS 23.167 & TS 23.271 To support the precise positioning of the PSAP. It can also send an emergency call originating from CS to an IP-enabled PSAP. 120633.doc -34- 200816752 In the case of 3GPP2, Figure 8 is also suitable for describing the origination of CS emergency calls in addition to the following: in addition to replacing the VCC application with a 3GPP2 similar entity, it can also resemble 3GPP2 messages. Instead of the 3GPP MAP message shown in steps 4 and 5. In this case, the 3GPP2 messages in steps 4 and 5 will be separate) the J-system 3GPP2 MAP origination request and the MAP origination request acknowledgement; the MSISDN in step 4 will be replaced by the action identification number (MIN), or The Action Directory Number (MDN) and GMLC in 8 will be used by the 3GPP2 Mobile Location Center (MPC). 〇 VI. Domain Transfer Domain transfer can occur in a manner similar to that used for normal VCC (as defined in 3GPP TS 23.206). Figures 9A and 9B are based on the illustration in 3GPP TS 23.206, which shows the exchange of user planes. To obtain VCC support for IMS emergency calls, the S-CSCF 910 shown in Figures 9A and 9B will be replaced by E-CSCF 1050 (in the visited network; shown in Figures 10A and 10B), and UE#B 920 And 930 (shown in Figures 9A and 9B, respectively) will correspond to PSAP 1060 (shown in Figures 10A and 10B).

VI.A·Domain Transfer IMS to CS

In order to support the transfer of an IMS emergency call from the IMS domain to the CS domain when the UE moves out of the IMS coverage area and enters the CS coverage area, two alternatives will be described herein. In the procedure A described in this section, the VCC-capable UE behaves as a normal VCC (described in 3GPP TS 23.206) and uses the VDN obtained from the visited or local network and uses the above described section III.B. The scheme (e), (f), (g) or any of the parties initiates a new call line to the VCC application in the CS domain. 120633.doc -35- 200816752

ΐ Α Α · 域 域 域 域 至 至 至 程式 程式 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于 于Supporting further continuity of UE positioning to the PSAP is limiting. However, the program has the advantage that it is compatible with the IMS to CS domain transfer of a normal VCC from the perspective of the UE. Figure 11 illustrates an illustrative embodiment of a program A. #锧7〈Build. If the UE determines that the domain is required to be transferred to the CS and the user is not subordinate to the CS domain, then the UE implements a CS slave, including a location update to its HLR/HSS. It then initiates a voice call in the CS domain using the VDN previously obtained from the original visited network or the local network to establish an access line via the CS domain. For this program, we assume that the UE can be authenticated in the CS domain. Step 2 (CS originating program). In the CS network, the originating call is handled as if a normal CS call originated. The visited mobile switching center (VMSC) 1130 routes the call to the original visited IMS network via the MGCF 1140 in the original visited network. Step 4 (INVITE (VCC Application). The MGCF 1140 initiates an INVITE to the Interrogation CSCF (I-CSCF; not shown in Figure 11) in the original visited IMS, or the MGCF may directly route to the E-CSCF 1160. An S-CSCF or VCC application 1170. Based on the VDN, the I-CSCF or S-CSCF (not shown) or the E-CSCF 1160 drives the psi-based application server terminal to the VCC application 1170. 120633.doc -36- 200816752 Step 5 (UPDATE or INVITE) 〇VCC Application 11 70 updates the outgoing memory by communicating the access line 8 established in the incoming domain to the remote end via 彳8〇?1160 The access line update occurs according to the SIP dialog modification program in IETF RFC 3 261. The VCC application 1170 can also explicitly indicate the domain transfer to £-〇8〇?1160. Step 6 (Location Update). The CSCF 1160 sends a location update along with the new SDP information to the anchor LRF 1150. At a minimum, the E-CSCF 1160 should indicate to 1^1^1150 that there is already a 域3 domain transfer (eg, ¥(:( : Application 1170 may learn from VDN and not VDI and/or transfer from domain involved in MGCF 1140. In a CS domain transfer) Step 7 (UPDATE or INVITE) If the PS AP has an IP function (as shown in Figure 10A), then the update continues to the PSAP, or if the PSAP only has CS functionality (eg Figure 10B) The U continues to the MGCF. Step 8 (Completion of the CS domain call line). In the VCC application 1170, E-CSCF 1160 or S-CSCF (if present), I-CSCF (if present) A new call line in the incoming CS domain is established between the MGCF 1140, the VMSC 1130, and the UE 1110. Step 9 (release of the source access line). Release the previous incoming access line, the previous incoming access line is previously The access line established on the IMS. If possible, the UE 1110 should cancel the registration in the visited network P-CSCF and the local network S-CSCF. In an embodiment, the program A has transferred the UE to the CS domain. Continuous support for positioning may be subject to the following restrictions: If the PSAP sends a request to the anchor 120633.doc -37-200816752 LRF to obtain the location of the UE, the LRF may not be able to use the same program to obtain the location, because the UE is The program may be in use (or expected to be used) in the IMS domain. For example, if the LRF used 〇MA SUPL based on SIP transmission between UDP/IP, TCP/IP and LRF and UE, the access loss to the PS domain after the ij UE is transferred from the IMS domain to the CS can be prevented. Further use of SUPL. In addition, the LRF may not be able to use the control plane positioning solution defined in 3GPP TS 23.271 • (for example, in clause 9.1.3 of 3GPP TS 23.271) for CS emergency calls, as it may not be aware of this

D VMSC address. However, the LRF may use the more general CS-MT-LR program set forth in clauses 9.1.1 and 9.1.2 of 3GPP TS 23.271, where the LRJF (which behaves or accesses a gateway action location center (GMLC) )) The VMSC address is obtained by querying the local HLR/HSS of the UE. However, this has a disadvantage: the UE's HLR/HSS will need to support the CS-MT-LR query program and there may be billing problems between the visited network and the local network (this is due to the local network) May not be aware of the importance of emergency calls)°

VI.A.2. Domain Transfer IMS to CS-Program B In an alternative embodiment, IMS to CS domain transfer can be achieved regardless of whether a UE has sufficient credentials to register in the newly visited network. Program B is applicable to the UE and can achieve continuity of positioning support without limitation. However, in one embodiment, the program may be limited to domain transfers between networks belonging to the same operator. In addition, Program B requires a new VCC Domain Transfer variant in which the VDN is not known in the UE. FIG. 12 illustrates an illustrative embodiment of a program B. 120633.doc -38 - 200816752 Step 1 (Emergency SETUP (VCC)). If the UE determines that a domain transfer to the CS is required and the user is not subordinate to the CS domain, the UE 1210 may implement a CS slave if it includes such credentials. It then initiates an emergency voice call in the 03 field by sending an urgent setup message to the VMSC 1230 (as defined in 3GPP TS 24.008). The emergency setup message may include an indication of VCC support. However, there is no need to include any VDNs. Step 2 (MAP User Location (IMSI, IMEI)). Based on the local VMSC policy or subscription information obtained from the local HLR/HSS of the UE or based on any VCC indication received in step 1, the VMSC 1230 sends a MAP User Location Report to the Emergency Service Provider (PSAP). (The call will typically be sent to the emergency service provider) associated with the GMLC 1250. The MAP User Location Report carries the same information as the information to be sent for a normal emergency call origination (eg, step 4 in FIG. 8), including IMSI, MSISDN, IMEI, VMSC address, and serving cell identity. Or SAI. In an embodiment, no location estimate is included and an indication of VCC usage may be included. Step 3 (MAP User Location ACK (VDN)). Based on a local policy or due to receiving a VCC indication in step 2, the GMLC interacts with an associated LRF (eg, a logical LRF within the same physical entity as the GMLC) or with a set of associated LRFs (eg, using a map) 7 or the program described in FIG. 8) searches for the UE 1210 call record originally established in the anchor LRF 1250. The anchor LRF 1250 can use the IMSI, MSISDN, and/or IMEI received in step 2 to identify the correct call record. If no call record is found and the UE does not indicate a VCC domain transfer in step 1, the GMLC 1250 may consider 120633.doc -39-200816752 to be a new emergency call and continue to establish the emergency call - for example, as shown 8 In the case of supporting vcc originating from CS emergency calls. If the UE is not found and if the UE indicates a VCC domain transfer in step 1, the GMLC 1250 will instead return a MAP User Location Report return error to the VMSC (not shown), and the VMSC will Release the call attempt. From the user's point of view, this will cause the UE to release the call and allow the user to retry the emergency call after the VCC domain transfer fails. Otherwise, if the call record is found, the GMLC 1250 returns a MAP User Location Report ACK back to the VMSC 1230, which carries the VDN required to establish a new access line. When the call is originated for the first time (eg, in step 6 of FIG. 7 or in step 9 of FIG. 8), the LRF 125 0 will obtain the VDN, and when the GMLC 1250 locates the call record within the LRF, The VDN will be provided to the GMLC 1250. The existing NA-ESRK or existing NA-ESRD parameters can carry the VDN in the MAP User Location Report ACK. In step 2, the GMLC 1250 also stores information received from the VMSC 123 0.

Q step is mixed. The VMSC 1230 routes the new line based on the VDN received in step 3. If the existing NA-ESRK or NA-ESRD parameters are used to convey the VDN, the route of the line can be the same as the route used for normal emergency call origination. Based on VDN routing, VMSC 1230 passes through

The MGCF 1240 in the access network routes the call to the IMS network that was originally accessed. Step 5 (INVITE (VCC application)). The MGCF 1240 initiates an INVITE to the I-CSCF in the visited IMS (not shown), or the MGCF 1240 may route directly to the E-CSCF 1260, an S-CSCF (not shown), or the VCC shall be 120633.doc -40-200816752 Program 1270. The Ι-CSCF or S-CSCF (not shown) or E-CSCF 1260 drives the PSI-based application server terminal to the VCC application 1270 based on the VDN.

Step 6 (UPDATE or INVITE). The VCC application 1270 updates the outgoing access line by communicating the access line SDP established in the incoming domain to the far end via the E-CSCF 1260. Access line updates occur according to the SIP dialog modification program in IETF * RFC 3 261. The VCC application 1270 can also explicitly transfer the 08 domain to the €80卩1260. 〇 Step 7 (Location Update). The E-CSCF 1260 sends a location update along with the new SDP information to the anchor LRF 1250. At a minimum, the E-CSCF 1260 should indicate to the LRF 1250 that a CS domain transfer already exists. LRF 1250 correlates the indication with an indication of the domain transition determined in step 3, and determines that UE 1210 has now changed the domain to the domain indicated in step 2. The LRF 1250 communicates this information to the GMLC selected by the VMSC 1230 in step 2. Step 8 (UPDATE or INVITE). The update proceeds to y PSAP (as shown in Figure 10A) or proceeds to the MGCF (as shown in Figure 10B). Step 9 (release of the source access line). A new incoming call line is established between the VCC application 1270, E-*CSCF 1260 or S-CSCF (if present), I-CSCF (if present), MGCF 1240, VMSC 1230 and UE 1210. Step io (the rest of the cs call setup). The m-channel is accessed, and the source access line is the access line previously established on the IMS. If possible, the UE 1210 should cancel the call in the visited network 1^€8〇? and the local network 8-〇8€? 120633.doc -41 - 200816752 is published in an embodiment in the steps of Figure 12. In the emergency establishment information, the emergency category may include any _ coffee indication as a new service;; #3 spare digits before the Μ may define up to 3 new service categories). In the example in this embodiment, the UE can start the program based on the following information and start the program (in the case of allowing two programs): Ο 九 (9) According to the original visited network, the (10) can be indicated. Support program b. (9) It is determined that the new access cs domain and the original access secret or the domain is owned by the same operator, or the same network, or has the arrangement of the support program B. () Information about the support program B already in the UE (for example, provided by the local network operator). It can be used in the section m + Tian ^ ^ early mB to convey the vcc-related scheme (the scheme (4), (7) or (4)) to the UE, to convey clearly or implicitly ( m) Information in the middle. The determination in (n) may be based on the predicate--the operator's _mnc in the original visited domain and the newly visited (four) domain, for example, (d). As the second generation, it is determined that the system broadcast information (e.g., the information of the newly accessed network support program 3 and possibly the other = program B network) can be received based on the network accessed from the newly visited network. Alternatively, the selection system, (9) and (4) may be based on information that identifies all operators having the arrangement of the support program B and is stored in the simple (e.g., as permitted in (4)). In addition to allowing unauthorized branch-domain transfers, program b also enables 120633.doc -42-200816752 to enable anchor LRFs to utilize the generic locator defined in 3GPP TS 23.271 (for example, in clause 9.1.3) To locate a UE that has initiated an emergency call. This is achieved because of steps 2 and 3 in Figure 12. In steps 2 and 3, the VMSC obtains and stores information about the GMLC, and the LRF and GMLC obtain and store information about the VMSC. This can then achieve a CS-MT-LR without having to query the local HSS/HLR of the UE.

In an embodiment, the further aspect of the program B is: the VMSC is located in the call originating program and can be in an emergency call with a common circuit mode (such as 3GPP TS 23.271 and the common D8/^1 in/eight Ding 18: The call originating program is the same as that defined in 1-8 Ding-036, and/or can be the same as the VCC-supported call originating program of a CS originating emergency call (as illustrated in Figure 8). From the point of view of GMLC, the program is almost identical to the program of an ordinary circuit mode emergency call with respect to the MAP communication transaction with the VMSC. In the case of 3GPP2, Figure 12 is also suitable for describing IMS to CS domain transfer procedure B except for the following: in addition to a 3GPP2 similar entity (J. The VCC application can be replaced by a similar 3GPP2 message). The 3GPP MAP message shown in steps 2 and 3. In this case, the 3GPP2 messages in steps 2 and 3 will be 3GPP2 MAP origination request and MAP origination request acknowledgement respectively; the MSISDNs in steps 2 and 3 will be identified by the action. The number (MIN) ^ or the Action Directory Number (MDN) is replaced, and the GMLC in Figure 12 will be replaced by the 3GPP2 Mobile Location Center (MPC).

VI.B. Domain Transfer CS to IMS To support the transfer of an emergency call from the CS domain to the IMS domain, this document describes two alternatives. 120633.doc -43 - 200816752

Νΐ·Β·1·Domain Transfer CS to IMS-Program C In the procedure c described in this section, a UE with VCC functionality behaves like a normal VCC (described in 3GPP TS 23.206) and uses Section III above. Any of the schemes (e), (f), (g) or (h) described in B and the VDI obtained from the visited network or the local network originating from the VCC application in the IMS domain A new call line. The call will be handled as if it were a normal originating SIP call, and therefore the call is only available to a UE with sufficient credentials to register in the newly visited network. This program is shown in Figure 13. Step 1 (INVITE (VDI)). If 螌\]Έ 1310 determines that the user does not register with the IMS when the domain is required to be transferred to the IMS, the UE 1310 initiates registration with the IMS as specified in 3GPP TS 23.206. Subsequently, the UE initiates an IMS origination session to the VCC application 1350 in the original visited network using the VDI previously obtained from the visited network (eg, as described in Section IV of the article and Figures 7 and 8 above), To establish an access line via IMS and request the active 〇3 conversation domain to transfer to the IMS. The SIP INVITE can be routed through the P-CSCF in the newly visited network or local network (not shown) and the S-CSCF in the local network (not shown), and finally arrive at the original visited network. S-CSCF (not shown) or preferably E-CSCF 1340. Step 2 (INVITE (VDI)) 处理 The S-CSCF (not shown) or E-CSCF 1340 in the original visited network processes the IMS conversation and delivers it to the VCC application 1350. Step 3 (UPDATE or INVITE). The VCC application 1350 completes the establishment of a new incoming access line via the IMS. The VCC application 1350 implements the domain transfer by 120633.doc -44-200816752 using the access line update procedure as specified in 3GPP TS 23.206 to enable the remote line update to newly establish access line connection information. The UPDATE or re-INVITE is sent to the E-CSCF 1340 for use in originating the call (e.g., according to Figure 7 or Figure 8). The VCC application 1350 can also explicitly indicate a domain transfer to £<8〇? 1340. record. The E-CSCF 1340 updates the tinned LRF 1330 with new SDP information, for example, indicating that the UE 1 3 1 0 is now using the IMS domain and providing the UE IP address. Step 5 (UPDATE or INVITE) 〇 The update proceeds to the PSAP (as shown in Figure 10A) or MGCF (as shown in Figure 10B). Step 6 (release of the source access line). The source access line is then released as specified in 3GPP TS 23.206, which is the access line previously established on the CS. This includes releasing the previous incoming CS line by the E-CSCF 1340. Since the LRF should have the IP address of the UE and therefore the OMA SUPL (or any other positioning solution involving IP transmission (eg, 3GPP2 X.S0024)) can be invoked, the UE can continue to be located after the completion of the program C. support. However, only the more general PS-MT-LR program described in clauses 9.1.1 and 9.1.6 of 3GPP TS 23.271 (where the LRF queries the local HLR/HSS of the UE for the visited SGSN address) is used. The 3GPP control plane solution can be used to implement UE positioning for GPRS access.

VI.B.2. Domain Transfer CS to IMS-Program D In an alternative embodiment, the program D supporting CS to IMS domain transfer is 120633 regardless of whether UE 14 10 has sufficient credentials to register in the new PLMN. Doc -45- 200816752 will apply to the UE 1410. The program has fewer restrictions on continuous positioning support. Figure 14 illustrates one exemplary embodiment of the program D. Step 1 (INVITE). Prior to transmitting the INVITE, if UE 14 10 contains sufficient credentials as defined in 3GPP TS 23.167 (i.e., does not use a normal registration), it will perform an emergency registration in the newly visited IMS network. The emergency registration system is required to support the UE 142 0 callback (via the newly visited network) and to authenticate the UE 1420 in the new visited IMS. The UE 1410 then sends an INVITE indicating the IMS emergency call to the P-CSCF in the newly visited network (not shown in Figure 14). The SIP To header in the INVITE may include a SIP URI indicating the transfer of an existing emergency call VCC domain. This SIP URI can easily be added to other SIP URIs that need to support emergency calls without any new SIP messaging changes. The SIP INVITE may also include a routing header containing address information of the originally visited network, for example, SIP of the original visited network created from MCC-MNC (Mobile Country Code and Mobile Network Code) The URI, and possibly the cell ID and the location area from which the call originated for the first time. Based on an indication of an existing emergency call VCC domain transfer, the P-CSCF does not invoke VCC support (eg, by transferring the SIP INVITE to the VCC application in the newly visited network as allowed in FIG. 7) Instead, the INVITE is passed to a local E-CSCF 1430. Step 2 (Capture Positioning). Based on the indication of the VCC domain transfer, if any of the address information received in step 1 regarding the original visited network is sufficiently accurate to determine the VDI required for subsequent routing, the E-CSCF 1430 may proceed to step 5. Otherwise, the E-CSCF 1430 is from an LRF 1440 (which may be a 120633.doc - 46 - 200816752 local LRF 1440, or preferably a routing header information provided by the UE 1420 in step j in the original visited network) Instructed LRF 1450) requests location and routing information. The E-CSCF 1430 provides UE identification information for the LRF 1440, such as IMSI, MSISDN, IMEI. The E-CSCF 1430 also indicates the VCC domain transfer. #微3(#/屏遥话记录 LRF 1440 can interact with other LRF 1450 to search for the original call record established in the anchored LRF when the first emergency call is initiated according to Figure 7 or Figure 8. If LRF 1430 The interaction and search will be more limited in the original visited network (or support the original visited network), for example, the LRF itself may be the anchor LRF. #声外迈S7定# (TZ) / Knife. If the call record is found, the LRF 1430 will return the routing information to the E-CSCF 1420 in the form of a VDI. Knife. Used in the step 2 or provided by the LRF 1440 in step 4. The VDI, E-CSCF 1430 can forward the INVITE directly to the VCC application 1470 in the original visited network or forward it to the IMS core (e.g., E-CSCF 1460) in the original visited network. Step 6 ( INVITE (VDI). If required, the IMS core (eg, E-CSCF 1460) in the original visited network forwards the INVITE to VCC application 1470. Step 7 (UPDATE or INVITE) 〇VCC application 1470 Communication from the access line SDP established in the incoming domain via the E-CSCF 1460 to the far To update the outgoing access line, the VCC application 1470 can also explicitly indicate the domain transfer to the E-CSCF 1460. #锧 to locate the new E_CSCF 1460 by the new SDP information (example 120633.doc -47-200816752 That is, it indicates that the UE 1420 is using the IMS domain and provides the IP address of the UE) to update the anchor LRF 145 0. Step 9 (UPDATE or INVITE) 〇 The update proceeds to the PSAP (as shown in FIG. 10A) Or MGCF (as shown in Figure 10B) Step 70 (0 Kang Cunhuan, Pound Road #放). Subsequently, the source access line is released as specified in 3GPP TS 23.206, the source access line was previously in CS The built-in • access line. This includes the release of the previous incoming CS line by the E-CSCF. The program in Figure 14 is applicable to both registered and unregistered UEs. The method of continuing to provide location support can also be used with the program. C is the same, for example, by using OMA SUPL and the UE IP address provided to anchor LRF 1450 in step 8 of Figure 14 or using the 3GPP PS-MT-LR program for GPRS access positioning. However, as an additional The benefits can be used in 3GPP TS 23.271 (in clauses 9·1·6Α and 9·1·7) ) Defined 3GPP PS-NI-LR and PS-MT-LR programs for emergency calls. This can be achieved if the xje indicates an emergency call for GPRS access and/or GPRS PDP establishment. This can trigger

The SGSN incites a PS-NI-LR to obtain a location or provide its address to a GMLC. If the GMLC is associated with the anchor lrf, the address of the Servo 01 > 118 Support Node (SGSN) can be provided to the anchor LRF • thereby making it possible to use the PS-MT-LR without having to query the local HLR/HSS (and also allows for an unauthorised ue to be located if no HLR/HSS is used). However, this capability can be limited to situations where the same operator has both new and original visited networks. The various aspects of the present disclosure are set forth above. It should be clear that it can be 120633.doc -48- 200816752

The teachings herein are embodied in a variety of forms and any particular structure, function, or both disclosed herein are merely representative. Based on the teachings herein, those skilled in the art will appreciate that the aspects disclosed herein can be constructed independently of any other aspect and that two or more of the aspects can be combined in various ways. For example, any number of aspects described herein can be used to construct a device or a practice-method. In addition, other structures, functionalities, or structures and functions may be used in addition to one or more of the aspects described herein to construct such a device or practice the method. As a matter of some of the above concepts, 'in some aspects', a number of flat = channels can be established based on the pulse repetition frequency. In some aspects, a flat light channel can be established based on pulse position or offset. In some aspects, parallel channels can be established based on a time hopping sequence. In some grievances, parallel channels can be established based on pulse repetition frequency, pulse position or offset and time hopping sequences. Those skilled in the art will appreciate that information and signals may be represented using any of a variety of different techniques and techniques. For example, the materials, instructions, commands, information, signals, bits, symbols, and cymbals & may be mentioned in the above description may be voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles or Any combination of them is indicated. Those skilled in the art should further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps illustrated in connection with the embodiments disclosed herein can be constructed as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, the functions of various (four) components, m circuits, and steps are generally explained above. Whether such functionality is built as hardware or as software depends on the specific application and design constraints imposed on the entire system. Those skilled in the art can construct the functionality in a different manner for each application, but the determination of such constructs should not be construed as causing a departure from the scope of the invention. The various illustrative logic blocks, modules, and circuits set forth in connection with the embodiments disclosed herein may be constructed or implemented by a general purpose processor, a digital signal processor (DSP), or an application-specific integrated circuit ( Asic), Field Programmable Gate Array (FPGA) or other programmable logic device, Octopus f) or transistor logic, discrete hardware components, or any combination designed to implement the functions described herein . A general purpose processor may be a microprocessor, but another selection system, which may be any conventional processor, controller, microcontroller or state machine. A processor can also be constructed as one of the computing devices σ , for example

For example, a combination of a DSP and a microprocessor, a plurality of microprocessors, - a plurality of microprocessors in combination with a DSP core, or any other such configuration. S It should be understood that any particular order or hierarchy of steps in any disclosure process is an example of an exemplary method. Based on the design preferences, it is understood that U can re-arrange the specific sequence of steps or stages in the processes while remaining within the scope of the present disclosure. The accompanying method is to be construed as an s The steps of the method or algorithm described in connection with the embodiments disclosed herein may be directly applied as hardware, a software module executed by a processor, or a combination of both. The software module can reside in random access memory (RAM), flash memory, read-only memory (ROM), electronically programmable R〇M (EPR〇M), and electronically erasable programmable ROM (EEPROM). ), scratchpad, hard disk, removable; 2 633.doc -50-200816752 type disk, CD-ROM or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from or write information to the storage medium. Alternatively, the storage medium may be part of the processor. The processor and storage media • can reside in an ASIC. The ASIC can reside in a user terminal (UE). Alternatively, the processor and the storage medium can reside as discrete components in a user terminal (or UE). The description of the disclosed embodiments is provided to enable those skilled in the art to make or use the invention. A person skilled in the art will readily be able to devise various modifications of the various embodiments, and the general principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is intended to be accorded to the broadest scope of the principles and novel features disclosed herein. BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 illustrates an exemplary communication system 1 that can support a variety of uses (and at least some aspects and embodiments of the present invention; FIG. 2 is an exemplary CDMA communication). A simplified functional block diagram of the system, FIG. 3 is an exemplary communication system that supports HDR transmission and is suitable for scheduling transmissions to multiple users. FIG. 4 illustrates an exemplary AT; FIG. A standard reference model of a 3GPP implementation (as disclosed in 3GPP TS 23.206); and Figure 5B illustrates a modified reference model in accordance with the present invention, which is different from the standard model of the VCC (as disclosed in 3GPP TS 23.206 and as Figure 120633.doc -51 - 200816752 shown in 5A); Figures 6A and 6B show an eight (5) l-knife that complements the model shown in Figures 5A and 5B (but from 3GPP TS 23 Z 167) Reference model for defining service perspectives; • 81 7® Interpretation - Exemplary Call Origination Program; . 1 Project 8 Graphical Interpretation - Support for an illustrative solution for vcc calls originating in the cs (circuit switched) domain Program;

Ο Figure 9AA 9B shows an exemplary model for exchanging the user plane (as disclosed in 3GPP TS 23.206); Figure 1 and Figure 8 illustrate the exchange of user planes in accordance with the present invention. The standard model (as disclosed in 3Gpp 23.2〇6 and shown in Figures 9A and 9B); Figure 11 illustrates an exemplary embodiment of the transition from IMS to CS domain, Figure 12 illustrates the domain transition 1]^8 to (An exemplary alternative implementation of 8: Figure 13 illustrates an exemplary implementation of domain transfer (^ to 1 Asahi 8) and Figure 14 illustrates an illustrative alternative from CS to IMS domain transfer and [main components DESCRIPTION OF SYMBOLS 〃 100 Communication System 102A Cell 102B Cell 102C Cell 102D Cell 102E Cell 102F Cell 120633.doc -52- 200816752 102G Cell 104 Network 106 User Equipment 106A User Equipment, Access Terminal 106B User Equipment, Storage Terminal device 106C user equipment, access terminal '106D user equipment, access terminal 106E user equipment, access terminal \ 106F user equipment, access terminal 106G User equipment, access terminal 106H user equipment, access terminal 106J user equipment, access terminal 1061 user equipment, access terminal 120 system 122 data source 130 radio network controller 132 channel row 136 selector component ' 141 call control processor 146 packet network interface 148 public switched telephone network 160 node Β 160 Α node Β 160 Β node Β 120633.doc -53 - 200816752

160C Node B

160D Node B

160E Node B

160F Node B

160G Node B 168 Channel Element 170 RF Unit 172 Data Queue 258 Decoding Processing Unit 264 Transmit Circuitry 302 Processing Unit 306 Throttling Control

308 PA 408 Receiver System 412 Carrier Control Unit

416 Memory 500 CS Domain 504 VCC Application 510 IP-based Domain 516 User Equipment, Access Terminal 518 User Equipment, Access Terminal 572 VCC Application 576 Emergency Call Dialogue Control Function 610 Location Capture Function 120633. Doc • 54 - 200816752 620 User Equipment 630 Proxy Call Conversation Control Function 640 Emergency Call Conversation Control Function 650 Servo Call Conversation Control Function 660 VCC Application 710 User Equipment 720 Proxy Call Conversation Control Function

730 730 Positioning Capture Function 740 Emergency Call Dialog Control Function 760 VCC Application 770 Media Gateway Control Function / Media Gateway 780 Emergency Center 810 User Equipment 830 Voice Action Service Switching Center 840 Media Gateway Control Function 850 Gateway Action Location Center 860 Emergency Call Conversation Control Function 870 VCC Application 910 Servo Call Conversation Control Function 920 User Equipment 930 User Equipment 1050 Emergency Call Conversation Control Function 1060 Public Safety Response Point 1110 User Equipment 120633.doc -55 - 200816752 1130 Accessed Mobile Switching Center 1140 Media Gateway Control Function 1150 Anchor Positioning Capture Function 1160 Emergency Call Dialogue Control Function 1170 VCC Application 1210 User Equipment 1230 Voice Action Service Switching Center

1240 Media Gateway Control Function 1250 Gateway Action Location Center 1260 Emergency Call Dialog Control Function 1270 VCC App 1310 User Device 1330 Anchor Location Capture Function 1340 Emergency Call Dialog Control Function 1350 VCC App 1410 User Device 1420 User Equipment 1430 Emergency Call Conversation Control Function 1440 Tinding Positioning Function 1450 Positioning Function 1460 Emergency Call Conversation Control Function 1470 VCC Application 120633.doc -56-

Claims (1)

200816752 Patent Application Range: 1. A system for supporting Voice Call Continuity (VCC) for emergency calls in a wireless access environment, comprising: ϋ accessing a vcc application in the Internet Protocol Multimedia Subsystem (IMS), It facilitates the domain transfer between the visited mMs subsystem and the Circuit Switched (CS) subsystem; and 'there is a tight communication between the IMS subsystems in the visited IMS subsystem. a -CSCF) subsystem that is operationally coupled to the VCC application to facilitate domain transfer between the IM S subsystem and the cs subsystem. 2. The system of claim 1, wherein the accessed chest subsystem further comprises a media gateway control function (MGCF) sub-system that is operatively coupled to the touch subsystem. 3. The system of claim 2, wherein the accessing (10) subsystem further comprises operatively consuming the MG, the first media gateway (MGW) subsystem. Q 4· The system of claim 2, wherein the cs sub-Li #$^. Gamma ^ Millennium, and further includes a statement that can communicate with the MGCF subsystem. q The Service Switching Center (VMSC) is a sub-system. '5 · The system of the first item, the second unit (2), and the at least one user equipment (6), such as the system of claim 5, further whitening the UEi-, and including one in operation A proxy system coupled to the early 7C to facilitate communication. σ Dialog Control Function (P-CSCF) Sub 7 _ The system of claim 1 further includes a 撷 撷 功能 120 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 633 And its implementation is related to the function of the location. 8 • As claimed in claim 1, the first access to the IMS subsystem is in an access network. 9 · If the request item 1 is in the network, first, wherein the accessed IMS subsystem is in a local 1 〇 种 种 种 种 种 种 种 种 支援 支援 支援 支援 支援 支援 支援 支援 支援 支援 支援 支援 支援 支援The method of reading (10) C), comprising: / facilitating by the VCC application - domain transfer between the Internet Protocol Multimedia Subsystem j (IMS) and the Circuit Switched (CS) subsystem; and hunting by - emergency The Call Conversation Control Function (E-CSCF) facilitates domain transfer between an Internet, a Network Coordination Multimedia Subsystem (IMS), and a Circuit Switched (4) subsystem. Authorized η. The method of claim 10's further includes supporting an emergency call from a User Equipment (UE). 12. The method of claim 1 further comprising supporting an emergency call from an unauthorised user equipment (UE). 13. The method of claim 1, further comprising supporting an emergency call from a user equipment (UE) in a local network. 14. The method of claim 10, further comprising locating a user equipment (UE) after positioning from a first wireless access network vcc to a second wireless access network. 15. The method of claim 14 wherein the method further comprises: on the outgoing call line / CC application knowing that the E_SCSF is used for 6 consecutive weeks to achieve positioning support for the continuous I20633.doc 200816752. 16. The method of claiming ι〇, which further includes communicating Vcc related information from a user device (UE). 17. The method of claim 1, further comprising indicating VCC in an emergency SETUP message transferred from ims to Cs. 18. * 〇 19. The method of 士明求1 ,, further comprising using an existing map service from the parent service change center (MSC) to a gateway action location center (Gmlc) to The MSC routes an emergency call to the VCC application in a partially or completely transparent manner. The method of claim 10, further comprising performing a location update on a location acquisition function (LRF). 20. The method of claim 1 , further comprising using a gateway action location center (GMLC) query from a mobile services switching center (MSC) to facilitate the domain in a manner that is partially or completely transparent to the MSC Transfer. twenty one. 22. The method of claim 10, wherein the step of step comprises anchoring the location acquisition in an anchor location acquisition function (LRF) when establishing an emergency call. A system for supporting voice call-to-home (VCC) for emergency calls in a wireless access environment, comprising: a domain-first component between the visited Internet Protocol Multi-Functional Replacement (CS) subsystem, It is used to facilitate an integrated subsystem (IMS) subsystem and a circuit transfer; and a second component in the visited IMS subsystem that is operatively configured to facilitate the IMS subsystem Domain-transferable beta with the CS5 system's 120633.doc 200816752, a computer-readable medium for supporting voice call continuity (vcc) for emergency calls in a wireless access environment, the computer readable medium comprising: The computing device implements the following code: The Hunting-Emergency Call Conversation Control Function (E-CSCF) facilitates an Internet Protocol Multimedia Subsystem (IMS) and a Circuit Switched (cs) Subsystem: Transfer; and the location of the user equipment (UE) after the transfer from the _th wireless access network VCC to a second wireless access network. The computer readable medium of claim 23, wherein the UE is authorized by the UE to be authorized 25. The computer readable medium of claim 23, wherein the ue is a UE. 26. The computer of claim 23 is Read the media, where the 1; £ is in the local network. 〇 120633.doc