CA2577887A1

CA2577887A1 - Testing for mobile device locator systems, such as for e911

Info

Publication number: CA2577887A1
Application number: CA002577887A
Authority: CA
Inventors: J. Mark Dammrose
Original assignee: Cingular Wireless Ii, Llc; J. Mark Dammrose; At&T Mobility Ii, Llc; At&T Mobility Ii Llc
Current assignee: AT&T Mobility II LLC
Priority date: 2004-08-19
Filing date: 2005-08-19
Publication date: 2006-02-23
Also published as: EP1784997A4; EP1784997A2; WO2006021005A2; JP2008511209A; WO2006021005A3

Abstract

Emergency response systems that operate in association with mobile communication networks, such as E911, are tested using components of a system used in association with electronic surveillance under the Communications Assistance for Law Enforcement Act of 1994 (CALEA), or similar components. For example, CALEA features may be used to trigger E911 test queries. In some embodiments, an E911 test server stands in as a proxy for a CALEA collection function and receives information associated with test calls handled by a CALEA delivery function. This information may include location information associated with a test mobile station. The E911 test server may allow for reporting of test information (e.g., using email, SMS, etc.).

Description

TESTING FOR MOBILE DEVICE LOCATOR SYSTEMS, SUCH AS FOR E911 CROSS-REFERENCE TO RELATED APPLICATIONS

10001] This application claims the benefit of U.S. Provisional Patent Application No. 60/602,960, filed August 19, 2004, entitled "Testing'for Mobile Device Locator Systems, such as for E911 Phase 2" (attorney docket no. 101948103.USOO), which is herein incorporated by reference.

BACKGROUND
[00021 In the United States, people call 911 in the event of an emergency.
Typically, when the number 911 is dialed, a call is automatically forwarded to a public safety answering point (PSAP) also called a 911 call center. Once the call is connected the caller will tell a 911 operator about the emergency and, when possible, will give the caller's location. To help emergency response, the federal government mandated that, by 2001, landline-based telephone calling services provide a service called "enhanced 911" (E911), which allows 911 operators to trace any given phone call and access the address that the call is coming from.
[00031 Because the number of emergency 911 calls made from mobile phones is increasing, the federal government has also mandated that mobile phone and service providers implement E911 programs specific to wireless communications.
E911 for wireless communications is being implemented in three stages. For Phase 0, wireless service providers are required to direct all emergency calls to a PSAP even if the caller is not a subscriber to their service or the device is not activated. For Phase 1, the FCC requires that a phone number be displayed with each 911 call (automatic number identification (ANI)), allowing a PSAP
operator to call back if there is a disconnection. In addition, some sort of automatic location identification information may be required as part of Phase 1. Phase 2 is designed to bring wireless calls up to the level of landline-based E911 calls, which means a caller's phone number and location is automatically identified for each emergency call.
[0004] When the E911 for wireless the upgrade is universally complete, all cell phone 911 callers will be pinpointed to a range within FCC guidelines (e.g., meters to 300 feet of the caller's location). For example, a cell phone user's phone number and the address and location of the receiving antenna site will be sent to an E911 tandem, which is the switch that routes 911 calls to an appropriate PSAP
based on the ANI-defined geographic location. Once the caller's voice and callback number are transferred to the appropriate PSAP, the PSAP operator will be able to view a graphic display that shows the longitude and latitude of the caller as accessed through GPS satellites or other locator means. The PSAP operator's computer links to the ALI database, which stores address data and other information. The details of this process may vary, depending on the types of systems used.
[0005] Wireless service providers are currently configuring their systems to be compliant with the E911 requirements. In light of the nature of the service and the complexity of E911 Phase 1 and Phase 2 solutions, wireless service providers use a significant number of test calls to maintain the functionality and integrity of the E911 service. Testing may be in the context of periodic location accuracy certification, new installation validation, network modification validation, troubleshooting, etc., and may take place over the life of the network (i.e., not just at initial system configuration or implementation).
[0006] In some cases, wireless service providers test their systems by placing calls to the appropriate PSAP. However, this technique is often impractical and a waste of PSAP resources. While other test solutions exist, in general, they cannot effectively simulate automated end-to-end dataflow through the network without additional monitoring equipment. Such techniques often rely on dedicated monitoring equipment for called signaling within the network (e.g., SS7 monitors or mobile RF signaling). Also, existing testing techniques rely on the termination of test calls to the test platform to exact the data needed to generate location results.

In this context, simplification of the system is desirable, especially for large carriers that maintain multiple wireless network architectures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is a block diagram showing an example of a system for implementing an E911 testing scheme in an ANSI-41 network.
[ooos] Figures 2A-2D are block diagrams showing examples of systems for implementing an E911 testing scheme in variants of a Global System for Mobile Communication (GSM) environment.
[0009] Figures 3A and 3B are block diagrams showing examples of systems for implementing an E911 testing scheme in variants of a Universal Mobile Telecommunications System (UMTS) environment [0010] Figures 4A-4B are flow diagrams showing high-level transaction flows between various components of the system of Figure 1 (ANSI-41 network).
[0011] Figures 5A and 5B are flow diagrams showing high-level transaction flows between various components of the system of Figure 2A (GSM E5 network).
[0012] Figures 5C and 5D are flow diagrams showing high-level transaction flows between various components of the system of Figure 2B (GSM E5 network).
[0013] Figures 6A and 6B are flow diagrams showing high-level transaction flows between various components of the system of Figure 2C (GSM Lg-Interface network).
[0014] Figures 6C and 6D are flow diagrams showing high-level transaction flows between various components of the system of Figure 2D (GSM Lg-Interface network).
[0015] Figures 7A-7D are flow diagrams showing high-level transaction flows between various components within UMTS systems, such as the UMTS systems of Figures 3A and 3B.
[0016] In the drawings, the same reference numbers identify identical or substantially similar elements or acts. To facilitate the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced (e.g., element 204 is first introduced and discussed with respect to Figure 2).

DETAILED DESCRIPTION

[0017] The invention will now be described with respect to various embodiments.
The following description provides specific details for a thorough understanding of, and enabling description for, these embodiments of the invention. However, one skilled in the art will understand that the invention may be practiced without these details. In other instances, well-known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments of the invention.
[0018] It is intended that the terminology used in the description of the embodiments of the invention be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the invention. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

A. Overview [0019] A system and method for testing implementation of an E911 wireless system is described herein. In this system and method, a wireless service provider uses the infrastructure and capabilities of an unrelated but already-implemented electronic surveillance service, such as the services mandated by the Communications Assistance for Law Enforcement Act of 1994 (CALEA), to test an E911 service. While the CALEA service is unrelated to the E911 service, implementation of E911 testing configurations using the CALEA infrastructure allows for a simplified, efficient, and effective testing scheme for E911 systems, as both services are common to most North American wireless architectures.
[0020] Electronic surveillance services such as CALEA can have many components, including the interception of call content, commonly referred to as wiretapping, and the interception of "call identifying information," commonly referred to as "dialed number extraction." CALEA defines "call identifying information" as dialing or signaling information that identifies the origin, direction, destination, or termination of each communication generated or received by a subscriber by means of any equipment, facility, or service of a telecommunications carrier. In general, CALEA authorizes certain types of electronic surveillance in the fight against crime and terrorism. More specifically, CALEA defines the existing statutory obligation of telecommunications carriers to assist law enforcement in executing electronic surveillance pursuant to court order or other lawful authorization. For example, CALEA requires carriers to design or modify their systems to ensure that lawfully authorized electronic surveillance can be performed.
100211 The J-STD-025 standard serves as a CALEA standard for wire line, cellular, and broadband PCS carriers and manufacturers. The J-STD-025 standard defines services and features required by wire line, cellular, and broadband PCS
carriers to support lawfully authorized electronic surveillance and specifies interfaces needed to deliver intercepted communications and call identifying information to a law enforcement agency.
100221 In some embodiments, the system and method for testing employs test methodology that is independent of the location estimate technology (e.g., U-TDOA, A-GPS, E-OTD, etc.). The test methodology is also independent of the wireless network technology (e.g., GSM, UMTS, IS-136, CDMA, etc.).
100231 To test an E911 service using the otherwise unrelated CALEA
infrastructure, in some embodiments, test calls are made to a "dummy" 911 recipient. The configuration of the dummy 911 recipient is not important. For example, it can be nothing more than a number to a voicemail box. Perhaps more relevant for the testing scheme is the configuration of the wireless service provider's mobile switching centers (MSCs). For example, as they would with a typical CALEA monitored call, the mobile service provider's MSCs are configured to deliver call-associated event messages to a E911 test platform each time a test mobile station places an emergency call to the dummy 911 recipient. In some embodiments, the E911 test platform is set up to look like a law enforcement message collection function used in a CALEA system. As with message collection functions used in a CALEA system, the E911 test platform is configured to receive Lawfully Authorized Electronic Surveillance Protocol (LAESP) messages. The type of information sent to the test platform in the form of LAESP messages may include dialing or signaling information that identifies the origin, direction, destination, and/or termination of a communication generated or received by a subscriber.
[00241 In general, the E911 test platform uses the LAESP messages to trigger location requests based on call origination events, to provide notification of intersystem handoffs, to submit location update requests via detection of dual tone multi-frequency (DTMF) signals during the call, and to provide notification of test call release to enable resource reallocation. In this way, the testing scheme can be used to provide testing of new E911 services prior to PSAP integration, testing of site modifications, troubleshooting, pre-PSAP integration spot validation, and accuracy testing/validation over the life of the E91 1 system.

B. Representative System [00251 Figures 1-3B and the following discussion provide a brief, general description of a suitable environment in which the invention can be implemented.
Although not required, aspects of the invention are described in the general context of computer-executable instructions, such as routines executed by a general-purpose computer (e.g., a server computer, wireless device, or personal/laptop computer). Those skilled in the relevant art will appreciate that the invention can be practiced with other communications, data processing, or computer system configurations, including Internet appliances, hand-held devices (including personal digital assistants (PDAs)), wearable computers, all manner of cellular or mobile phones, embedded computers (including those coupled to vehicles), multi-processor systems, microprocessor-based or programmable consumer electronics, set-top boxes, network PCs, mini-computers, mainframe computers, and the like.

[00261 Aspects of the invention can be embodied in a special purpose computer or data processor that is specifically programmed, configured, or constructed to perform one or more of the computer-executable instructions explained in detail herein. Aspects of the invention can also be practiced in distributed computing environments where tasks or modules are performed by remote processing devices that are linked through a communication network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
[00271 Aspects of the invention may be stored or distributed on computer-readable media, including magnetically or optically readable computer disks, as microcode on semiconductor memory, nanotechnology memory, organic or optical memory, or other portable data storage media. Indeed, computer-implemented instructions, data structures, screen displays, and other data under aspects of the invention may be distributed over the Internet or over other networks (including wireless networks) on a propagated signal on a propagation medium (e.g., an electromagnetic wave(s), a sound wave, etc.) over a period of time, or on any analog or digital network (packet switched, circuit switched, or other scheme).
Those skilled in the relevant art will recognize that portions of the invention reside on a server computer, while corresponding portions reside on a client computer, such as a mobile device.
[00281 The illustrated embodiments show testing of an E911 system implemented within ANSI-41, GSM, and UMTS networks. However, the concepts described herein may apply to other types of communication networks that implement both CALEA and E91 1, or similar systems. In some embodiments, a preexisting wireless service provider system already configured for CALEA can be upgraded for E911 testing using only minimum modifications. Likewise, in some embodiments, upgrading a preexisting emergency communications services system (e.g., such as a preexisting MPC/GMLC system) to accommodate the E911 testing scheme involves only minor modifications. In some embodiments, the E91 1 testing system has the capacity to support large numbers of simultaneous calls network-wide, as well as significant numbers of outstanding location request operations without blocking. In addition, test calls may be stored in the system for documentation or tracking and the testing scheme may include reporting systems. In some embodiments, the various network components making up a testing platform may be configured to send the results of the location estimate back to the test mobile station via a short messaging service (SMS) message, email server, instant messaging server, etc. Likewise, the test platform may be configured to send results of a location estimate to a provisioned email address or email list.
[0029] Referring to Figure 1, the E911 testing scheme may be implemented in the context of an ANSI-41 environment 100. In the ANSI-41 environment 100, the testing scheme may include a test mobile station 102 from which test calls are placed and a voice response unit 104 (VRU) that provides audible feedback to a user making a test call. The ANSI-41 environment may also include a base station 106 and a mobile switching center (MSC) 108. In some embodiments, the MSC
108 is updated to obtain and store routing translations for a pool of test emergency services routing key numbers. The VRU 104 may also receive the test emergency services routing key numbers.
[0030] In the illustrated embodiment (utilizing an IS-136 MSC), a special trunking configuration may be used if the MSC 108 is not able to support shared trunk routing which uses a public switched telephone network directory number to reach the VRU 104. In addition, a home location register (HLR) (not shown) used in the testing scheme may be implemented to store a profile for the test mobile station 102. Such profiles may consist of private mobile directory numbers (MDNs) and/or mobile station ISDNs (MSISDNs), which may be configured so that the test mobile stations 102 cannot receive calls from outside the wireless service provider sector.
[0031] In some embodiments, the MSC 108 interfaces with a mobile positioning center (MPC) 110 that, together with a position determining entity 112, provides location information for the test mobile 102. The MPC 110 may have originally been implemented as CALEA infrastructure but may be updated to accommodate the E91 1 testing scheme so that it can identify E91 1 calls that originate from test MDNs. In some embodiments, the MPC 110 is also updated to use a different emergency services routing key pool for routing the test MDNs (versus the actual E911 PSAP pool of emergency services routing keys). In addition, the MPC 110 may be updated to establish one or more J-STD-036 E2 connections to the E911 test server 114.
[0032] An E911 test server 114 may then collect and compile location information received from the MPC 110 to produce test data. In some embodiments, the E911 test server 114 may trigger E911 location requests on the MPC 110. Such location requests may be triggered by real time call event messages received as permitted by the underlying CALEA framework. The location responses may be logged onto the E91 1 test server 114, which acts as a repository for the collected test data. The E911 test server 114 may be configured to immediately send the location estimate messages back to the test mobile station 102 (e.g., via a SMS
text message via an email server 116). The E911 test server 114 and the email server 116 may also be configured to send such a message to another destination (e.g., an email message sent to a desktop networked computer). The E911 test server 116 may also send out daily logs, via email, for each test mobile station 102 used in the system. Other network nodes that may be affected under the testing scheme include a delivery function (DF) node 118, which is provided as part of the underlying CALEA system. Typically, with CALEA, the delivery function node 118 is responsible for delivering intercepted communications to one or more law enforcement collection functions in the standard's format appropriate for the type of intercept. However, in accordance with some embodiments of the invention, the delivery function node 118 delivers messages to the E911 test server 116, which is functioning as a proxy or stand-in for law enforcement collection functions. The delivery function may deliver information over various types of channels (e.g., call content channels (CCCs) and call data channels (CDCs).
(0033] The testing scheme is intended to predict the quality of mobile station location information to be received by an emergency services network 120, including a public safety answering point (PSAP) system 122 and other components, during an actual 911 call. However, as shown in the illustrated embodiment, the testing scheme may not need to rely on components of the emergency services network 120 in its implementation.
[0034] Referring to Figure 2A, the E911 testing scheme may be implemented in the context of a GSM network 200, such as a general packet radio service (GPRS) network. As with the ANSI-41 network scheme 100 of Figure 1, the GSM network testing scheme may include a test mobile station 202 and a VRU 204. The GSM
network may also include a base station 206, and a base station controller (BSC) 208. A monitoring unit 210 may monitor communications between the base station 206 and the BSC 208. The GSM network 200 may also include a GSM
mobile switching center (GSM MSC) 212.
[0035] In the GSM network, an E911 test server 214 interfaces with an MPC 216 and a CALEA delivery function to collect location information during testing.
In addition, a PDE 220 may be involved in the location determining process for the test mobile 202. An email server 222 or other communication component may be involved in the dissemination of test data collected by the E91 1 test server 214.
[0036] Figures 2B-2D show other GSM network implementations in which the invention can be implemented. In these GSM network implementation, various aspects of the GSM network may vary. For example, the MPC 216 of Figures 2A
and 2B may be replaced with a gateway mobile location center (GMLC) component 226 in the GSM networks depicted in Figures 2C and 2D. As with the ANSI-41 testing scheme of Figure 1, the testing schemes illustrated in figures 2D are intended to predict the quality of mobile station location information to be received by an emergency services network coupled to the GSM network, including a PSAP system and other components, during an actual 911 call.
However, as shown in the illustrated embodiments, the testing scheme may not need to rely on components of the emergency services network 224 in its implementation.
[0037] Referring to Figure 3A, the E911 testing scheme may be implemented in the context of a UMTS network 300. The UMTS network testing scheme may include a test user endpoint 302 and a VRU 304. The UMTS network may also include a base station 306, and a radio network controller (RNC) 308. The UMTS
network 300 may also include a MSC 310.
[0038] In the UMTS network, an E911 test server 312 interfaces with a GMLC 314 and a CALEA delivery function 316 to collect location information during testing.
In addition, an email server 318 or other communication component may be involved in the dissemination of test data collected by the E911 test server 312.
[0039] Figure 3B shows another UMTS network implementation in which the invention can be implemented. As with ANSI-41 testing scheme of Figure 1 and the GMS testing schemes of Figures 2A-2D, the testing schemes illustrated in figures 3A and 3B are intended to predict the quality of mobile station location information to be received by an emergency services network coupled to the UMTS network, including a PSAP system and other components, during an actual 911 call. However, as shown in the illustrated embodiments, the testing scheme may not need to rely on components of the emergency services network in its implementation.
[0040] In general, while implementations of the invention are described above in the context of ANSI-41, GSM, and UMTS networks, it may also be possible to implement the invention in other types of networks or systems, such as other types of networks that have an underlying emergency response or location identification framework.

C. System Flows [0041] Figures 4A-4B, 5A-5D, and 6A-6D, and 7A-7D are representative flow diagrams that show processes that occur within the various system of Figures 1, 2A-2D, and 3A-3B. These flow diagrams do not show all functions or exchanges of data but, instead, provide an understanding of commands and data exchanged under the system. Those skilled in the relevant art will recognize that some functions or exchanges of commands and data may be repeated, varied, omitted, or supplemented, and other aspects not shown may be readily implemented. For example, while not described in detail, a message containing data may be transmitted through a message queue, over HTTP, etc.

[0042] The flows represented in Figures 4A-7D are high-level flows in which the entire transaction is shown from initiation to completion. The various entities that may be involved in the transactions of Figures 4A-7D are also depicted throughout Figures 1-3B.
[0043] Referring to Figure 4A, an initial location call flow in an ANSI-41 network (e.g., the ANSI-41 network depicted in Figure 1) may include a sequence of communications between various components of the ANSI- 41 network, including the test mobile station 102, the PDE 112, the MSC 108, the E911 test server 114, the MPC 110, and the VRU 104. At a communication 401, the test mobile station 102 initiates an emergency services test call. As illustrated, the emergency services call may be made by dialing the number "911." Alternatively, the emergency services call may be made by dialing a predetermined number that the MSC may recognize as an emergency services test call (e.g., "311"). At a communication 402a, the MSC 108, configured with various E911 features (e.g., features that allow for the display of the 911 caller's phone number at the receiving end), sends a first request message (e.g., ORIGREQ) to the MPC 164. The first request message may indicate the cell site and sector from which the mobile call originated, as well as MIN information, MDN information, and ESN information for the test mobile station 102. The called party number (CdPN) is identified as "911,"
and the calling party number (CgPN) is identified as the test mobile station (e.g., 555-NXX-XXXX).
[0044] At a communication 402b, the MSC 108 identifies the test call as a call requesting electronic surveillance (as it would with a CALEA call) and sends a J-STD-025 LAESP origination message to a delivery function (DF) node (shown only in Figure 1). A forwarding function at the DF node then forwards a LAESP
origination message to the E91 1 test server 116 as if the E911 test server 116 is a CALEA law enforcement collection function.
[0045] In association with a communication 403, the MPC 110 performs one or more of the following steps: The MPC 110 recognizes the test mobile station as an E911 test mobile station, based on the MDN of the test mobile station (or other identifying information). The MPC 110 analyzes the digits in the received origination request message and, based on this analysis, determines a routing scheme for the test call. The MPC 110 assigns a temporary test emergency services routing key (ESRK) (or returns a set of test emergency services routing digits (ESRD) associated with the cell/sector) as the routing digits to be used by the MSC 108 and sends this information to the MSC 108.
[0046] At a communication 404a, the MSC 108 forwards the call to a test destination other than the PSAP (e.g., the VRU 104). In this communication, an integrated services digital network user part (ISUP) initial address message (IAM) called party number (CdPN) signifies the test destination, and the calling party number (CgPN) is the test emergency services routing key (ESRK). At a communication 404b, as a result of receiving the ESPOSREQ from the E911 test server (and/or the ORIGREQ), the MPC 110 launches a position request message (GPOSREQ) to the appropriate PDE (not shown) associated with the serving cell/sector for the test mobile.
[0047] At a communication 405 the PDE 112 receives the request and initiates location estimate processes/procedures (which may be location technology dependent). At a communication 406, call setup signaling is completed. At a communication 407, the PDE 112 completes the location estimate processes/procedures (or a time-out event occurs). At a communication 408, the PDE 112 then returns the location of the test mobile station to the MPC 110 in the form of latitude and longitude information: At a communication 409, the MPC

returns the location information back to the E911 test server 114. At a communication 410, the E911 test server 114 logs the location information (test call results) in a report file. The E911 test server 114 may also (optionally) send the test call results to the mobile as an SMS message and/or email the test call results to a designated email account, or otherwise report the information as needed.
[0048] At a communication 411 the test call is released. At a communication 412a, the MSC 108 sends the E911 test server 114 an LAESP release message via the CALEA intercept. This permits the E911 server 116 to release any resources associated with the call, assuming any resources have been used. At a communication 412b, the MSC 108 sends a call termination report message is sent to the MPC 110 to permit the MPC 110 to release any resources used during the call. At a communication 413, the MPC 110 acknowledges receipt of the call termination report message.
[0049] Referring to Figure 4B, a location update call flow in an ANSI-41 network (e.g., the ANSI-41 network depicted in Figure 1) may include a sequence of communications between the various components, as shown in Figure 4A, in order to update the location for a test mobile station 102 that has moved to a different location after the test call is initially placed.
[0050] At a communication 421, it is assumed that an emergency services call has previously been established (e.g., call setup signaling is completed per the initial location call flow of Figure 4A). At a communication 422, an operator of. the test mobile station 102 requests a new E911 location (e.g., by typing in a code using a keypad of the test mobile station). At a communication 423, the MSC 108 receives the code input and in response, sends a dialed digit extraction message to the E91 1 test server 114.
[0051) At a communication 424, the E911 test server 114 generates and sends an ESPOREQ to the MPC 110 (e.g., by mapping a caselD/caIIID for the test call to the appropriate MDN and the digit to the proper location request type). At a communication 425 the MPC 110 receives the ESPOSREQ, which triggers the MPC 110 to generate an intersystem position request (ISPOSREQ). The MPC
110 then sends the ISPOSREQ to the MSC 108.
[0052] At a communication 426, the MSC 108 sends back the requested information (e.g., TDMA mobile information, mobile capabilities, serving cell) via an ISPOSREQ response message. At a communication 427, upon receiving the results of the ISPOSREQ, the MPC 110 builds a GPOSREQ (e.g., based on the ESPOSREQ and ISPOSREQ) to send to the PDE 112 that is requesting a location estimate. At a communication 428, the PDE 112 receives the GPOSREQ and initiates location estimate processes/procedures (which may be location technology dependent).

[0053] At a communication 429, based on the results of the location estimate processes/procedures, the PDE 112 calculates an acceptable location estimate (or a timer expires). The PDE 112 may then return updated location information for the test mobile station 102 to the MPC 110 via a GPOSREQ response (e.g., in the form of latitude and longitude information).
[0054] At a communication 430, the MPC 110 returns the location information back to the E911 test server in a ESPOREQ response. At a communication 431, the E911 test server 114 logs the received location information (e.g., in a report file).
The E911 test server 114 may also (optionally) send the results to the mobile as an SMS and/or email the results to a designated email account.
[0055] At a communication 432, the test call is released. At a communication 433a, the MSC 108 sends an LAESP release message to the E911 test server 114 via the CALEA intercept. This may permit the E911 test server 114 to release any resources associated with the test call. At a communication 433b, which may occur concurrently with communication 433a, the MSC 108 may send a call termination report (e.g., CALLTERMRPT) to the MPC 110 to permit it to release any resources associated with the call. At a communication 434, the MPC
acknowledges the call termination report with a response.
[0056] Referring to Figures 5A-5D, the testing scheme may be implemented in a GSM E5 network architecture (as previously illustrated with respect to Figures 2D). The GSM architecture may include several components, including the test mobile station 202, the base station controller 208, the PDE 220, the MSC 212, the E911 test server 214, the MPC 216, and the VRU 204.
[0057] Figure 5A shows an example of an initial location call flow in the context of a GSM E5 environment. At a communication 501, the test mobile station 202 initiates an emergency services call. As illustrated, the emergency services call may be made by dialing the number "911." Alternatively, the emergency services call may be made by dialing a number for a test call destination (e.g., "311 "). At a communication 502a, the MSC 212 identifies the test call as a test emergency service call and forwards call to the MPC 216 with the serving cell information (e.g., ESRD) and calling party number (e.g., MDN) in an integrated services digital network user part (ISUP) initial address message (e.g., IAM).
[0058] At a communication 502b, the MSC 212 identifies the call as requiring electronic surveillance (i.e., test mobile provisioned on MSC for CALEA
intercept) and forwards the call to the MPC 216 with the serving cell information (emergency services routing digits) and mobile directory number (MDN) for the calling party. In the illustrated example, the call forwarding is implemented using a J-STD-025 LAESP origination message sent via a CALEA DF to the E911 Test Server 214, as if the E911 test server 214 is a law enforcement collection function (CF).
[0059] At a communication 503a, the MPC 216 analyzes the MDN from the IAM
message and identifies the call as a test call based on the MDN. The MPC 216 then assigns a temporary test ESRK as the routing digits to the MSC 212. The IAM is returned to the MSC 212 over the ISUP loop-around (e.g., with the called and calling party set equal to the test-ESRK). At a communication 503b, upon determining that the serving cell sector is configured for E91 1, the MPC 216 sends a GPOSREQ message over the E5-interface (e.g., J-STD-036B) to the PDE 220 requesting a location estimate for the test call. At a communication 504, the PDE
220, triggered by the GPOSREQ message, initiates processes and procedures to generate a location estimate.
[0060] At a communication 505, the E911 test server 214, triggered by the LAESP
Origination message, sends an ESPOSREQ to the MPC 216, which may include the MDN of the test mobile station 202 (as received in the LAESP origination message). At a communication 506, the MSC 212 forwards the call to the test destination (e.g., a destination other than the PSAP) based on the test ESRK.
[0061] At a communication 507, call setup signaling is completed. At a communication 508, the PDE 220 calculates an acceptable location estimate or a timer expires. At a communication 509, the PDE 220 returns the location of the test mobile station 202 (e.g., in the form of a latitude and longitude) to the MPC
216 via a GPOSREQ response. At a communication 510, the MPC 216 returns the location information back to the E911 test server in an ESPOSREQ response.

[0062] At a communication 511, the E911 test server 214 logs the received location information in a report file. The E911 test server 214 may also (optionally) send the received location information to the mobile as a SMS message and/or email the results to a designated email account. At a communication 512, the test call is released. At a communication 513, the MSC 212 sends an LAESP release message to the E911 test server 214 via the CALEA intercept to permit the E911 test server 214 to release any resources associated with the call.
[0063] Referring to Figure 5B, a location update call flow in an GSM network (e.g., the GSM network depicted in Figure 2A) may include a sequence of communications between the various components, as shown in Figure 5A, in order to update the location for a test mobile station 202 that has moved to a different location after the test call is initially placed.
[0064] At a communication 521, it is assumed that an emergency services call has previously been established (e.g., call setup signaling is completed per the initial location call flow of Figure 4A). At a communication 522, an operator of the test mobile station 202 requests a new E911 location (e.g., by typing in a code using a keypad of the test mobile station). At a communication 523, the MSC 212 receives the code input and in response, sends a dialed digit extraction message to the E91 1 test server 214.
[0065] At a communication 524, the E911 test server 214 generates and sends an ESPOSREQ to the MPC 216 (e.g., by mapping a caselD/caIIID for the test call to the appropriate MSISDN and the digit to the proper location request type). At a communication 525 the MPC 216 receives the ESPOSREQ, which triggers the MPC 216 to generate a GPOSREQ. The MPC 216 then sends the GPOSREQ to the PDE 220.
[0066] At a communication 526, the PDE 220 calculates an acceptable location estimate (or a timer expires). At a communication 527, the PDE 220 returns location information (e.g., in the form of a latitude and longitude) for the updated location of the test mobile 202 to the MPC 216 in a GPOSREQ response. At a communication 528, At a communication 430, the MPC 110 returns the location information back to the E911 test server in a ESPOSREQ response. At a communication 529, the E911 test server 214 logs the received location information (e.g., in a report file). The E911 test server 214 may also (optionally) send the results to the mobile as an SMS and/or email the results to a designated email account.
[0067] At a communication 530, the test call is released. At a communication 531, the MSC 212 sends an LAESP release message to the E911 test server 214 via the CALEA intercept. This may permit the E911 test server 214 to release any resources associated with the test call.
[0068] Figure 5C illustrates an example of an initial location call flow in a second version of a GSM E5 network architecture. At a communication 541, the test mobile station 202 initiates an emergency services test call. At a communication 542a, the MSC 212 identifies the call as an emergency service call and forwards call to the MPC 216 with the serving cell information (ESRD) and calling party number (MDN) in an ISUP initial address message (IAM). At a communication 542b, the MSC 212 identifies the test call as requiring electronic surveillance (i.e., test mobile provisioned on MSC for CALEA intercept) and sends a J-STD-025 LAESP origination message via a CALEA DF to the E911 test server 214 as if the E911 test server 214 is a law enforcement collection function (CF). At a communication 543, the MPC 216 analyzes the MDN from the IAM message and identifies the call as a test call based on the MDN. The MPC 216 assigns a temporary test ESRK as the routing digits to the MSC. The IAM is returned to the MSC 212 over the ISUP loop-around with the Called and Calling Party = test-ESRK. In some embodiments, the call may not be routed to the MPC 216 via ISUP Loop-around trunks because the MPC 216 does not need call information.
The route can also be determined by the MSC based on dialed digit string (e.g., '119') or IMSI-specifc switch translations.
[0069] At a communication 544, upon determining that the serving cell sector via location data in the LAESP origination message, the E911 test server 214 sends a GPOSREQ message to the PDE 220 over the E5-interface (J-STD-036B). The sent message may request a location estimate for the test call. At a communication 545, triggered by the GPOSREQ message, the PDE 220 initiates processes and procedures to generate a location estimate. At a communication 546, the MSC 212 forwards the call to the test destination (i.e., not the PSAP) based on the test ESRK (or dialed digits, IMSI, etc).
[00701 At a communication 547, call setup signaling is completed. At a communication 548, the PDE 220 calculates an acceptable location estimate (or a timer expires). At a communication 549, the PDE 220 returns the location of the test mobile station 202 in the form of a latitude and longitude to the E911 test server 214 in a GPOSREQ response. At a communication 550, the E911 test server 214 then logs the data in a report file. The E911 test server 214 may also (optionally) send the results to the mobile as an SMS and/or email the results to a designated email account. At a communication 551, the test call is released.
At a communication 552, MSC 212 sends an LAESP release message to the E911 test server 214 via the CALEA intercept. This may permit the E911 test server 214 to release any resources associated with the test call.
[00711 Figure 5D illustrates an example of location update call flow in the second version of a GSM E5 network architecture. At a communication 561, it is assumed that an emergency services call has previously been established (e.g., call setup signaling is completed per the initial location call flow of Figure 5B). At a communication 562, an operator of the test mobile station 202 requests a new E911 location (e.g., by typing in a code using a keypad of the test mobile station).
At a communication 563, the MSC 212 receives the code input and in response, sends a dialed digit extraction message to the E911 test server 214.
(00721 At a communication 564, the E911 test server 214 generates and sends a GPOSREQ to the PDE 220 (e.g., by mapping a caselD/calllD for the test call to the appropriate MSISDN and the digit to the proper location request type). At a communication 565, the PDE 220 calculates an acceptable location estimate (or a timer expires). At a communication 566, the PDE 220 returns location information (e.g., in the form of a latitude and longitude) for the updated location of the test mobile 202 to the E911 test server 214 in a GPOSREQ response. At a communication 567, the E911 test server 214 logs the received location information (e.g., in a report file).

[00731 At a communication 568, the E911 server may also (optionally) send the results to the mobile as an SMS and/or email the results to a designated email account. At a communication 569 the test call is released. At a communication 570, the MSC 212 sends an LAESP release message to the E911 test server 214 via the CALEA intercept. This may permit the E911 test server 214 to release any resources associated with the test call.
[00741 Figures 6A-6D are representative flow diagrams that show an alternate implementation of the testing scheme that incorporates a into a GSM network architecture, and more particularly, a GSM network architecture having an Lg-Interface. This network architecture can be implemented with or without the occurrence of an ISUP loop-around and may include a sequence of communications between various network components including a test mobile station 202, a serving mobile location center (SMLC) 228, BSC 208, a MSC 212, an E911 test server 214, a GMLC 226, and a VRU 204.
[0075] Figure 6A illustrates an example of an initial location call flow in a GSM Lg-Interface network architecture. At a communication 601, the test mobile station 202 initiates an emergency services call. At a communication 602a, using existing E911 features, the MSC 212 launches a subscriber location report (SLR) message to the GMLC 226 with the test MSISDN and the serving cell/sector from which the mobile call originated (i.e. CGI or ESRD) to request an ESRK. At a communication 602b, the MSC 212 identifies the test call as requiring electronic surveillance (i.e., test mobile provisioned on MSC for CALEA intercept) and sends a J-STD-025 LAESP origination message from its CALEA Delivery Function (DF) to the E911 test server 214 as if the server is a law enforcement collection function (CF). At a communication 603a, the GMLC 226 analyzes the MSISDN from the SLR message and identifies the call as a test call (e.g., based on an MSISDN).
The GMLC 226 assigns a temporary test ESRK as the routing digits to the MSC.
The ESRK is returned to the MSC in a response message. At a communication 603b, triggered by the LAESP Origination message, the E911 test server 214 sends an ESPOSREQ to the GMLC 226 which includes the MDN of the test mobile station 202, as received in the LAESP Origination message. At a communication 603c, the GMLC 226 receives the ESPOSREQ, which triggers the generation of a provide subscriber location (PSL) request that is sent to the MSC
212.
[0076] At a communication 604a, the MSC 212 forwards the test call to the test destination (e.g. a destination other than the PSAP) based on the test ESRK.
At a communication 604b, the MSC 212 translates the data contained in the PSL to generate and send a provide location request (PLR) message to the SMLC 228.
[0077] At a communication 605a, call setup signaling is completed. At a communication 605b, the SMLC 228 calculates/obtains an acceptable location estimate using applicable positioning methods/procedures (or a timer expires).
At a communication 606, the SMLC 228 then returns the location of the test mobile station 204 in the form of a latitude and longitude to the MSC 212 in a PLR
response. At a communication 607 the MSC 212 then returns (via PSL) the location estimate of the test mobile station 204 to the GMLC 226 (e.g., in the form of a latitude and longitude) to the GMLC 226.
l00781 At a communication 608 the GMLC 226 returns the location information back to the E911 test server 214 in an ESPOSREQ response. At a communication 609, the E911 server then logs the data in a report file. The server may also (optionally) send the results to the mobile as an SMS and/or email the results to a designated email account. At a communication 610, the test call is released.
[00791 At a communication 611 a, an LAESP Release message is sent by the MSC
to the E91 1 server via the CALEA intercept to permit the E911 server to release any resources associated with the call (if any). At a communication 611b, the MSC 212 sends a SLR (release) message to the GMLC 226 (e.g., to permit the GMLC 226 to release any resources associated with the call). At a communication 612, the GMLC 226 acknowledges receipt of the SLR message.
[00801 Figure 6B illustrates an example of location update call flow in the GSM Lg-Interface network architecture. At a communication 621, it is assumed that an emergency services call has previously been established (e.g., call setup signaling is completed per the initial location call flow of Figure 6A). At a communication 622, an operator of the test mobile station 202 requests a new E911 location (e.g., by typing in a code using a keypad of the test mobile station). At a communication 623, the MSC 212 receives the code input and in response, sends a dialed digit extraction message to the E911 test server 214.
[00811 At a communication 624, the E911 test server 214 generates and sends an ESPOSREQ to the GMLC 226 (e.g., by mapping a caselD/caIIID for the test call to the appropriate MSISDN and the digit to the proper location request type). At a communication 625, the GMLC 226 receives the ESPOSREQ which triggers the generation of a PSL message that the GMLC 226 sends to the MSC 212. At a communication 626, the MSC 212 translates the data contained in the PSL
message to generate and send a PLR message to the SMLC 228.
100821 At a communication 627, the SMLC 228 calculates/obtains an acceptable location estimate using applicable positioning methods/procedures (or a timer expires). At a communication 628, the SMLC 228 returns location information (e.g., in the form of a latitude and longitude) for the updated location of the test mobile 202 to the MSC 212 in a PLR response. At a communication 629, the MSC 212 returns the location estimate of the test mobile station 202 in the form of a latitude and longitude to the GMLC 226 in a PSL response.
P0831 At a communication 630, the GMLC 226 returns the location information back to the E911 test server 214 in a ESPOSREQ response. At a communication 631, the E91 1 test server 214 then logs the data in a report file. The E911 server may also (optionally) send the results to the mobile as an SMS and/or email the results to a designated email account. At a communication 632 the test call is released. At a communication 633, the MSC 212 sends an LAESP release message to the E911 test server 214 via the CALEA intercept. This may permit the E911 test server 214 to release any resources associated with the test call.
(00841 At a communication 634, the MSC 212 sends a SLR (release) message to the GMLC 226 to permit the GMLC 226 to release any resources associated with the test call. At a communication 635, the GMLC 226 acknowledges receipt of the SLR message.

100851 Figure 6C illustrates an example of an initial location call flow in a GSM Lg-Interface network architecture with ISUP loop-around. At a communication 641, the test mobile station 202 initiates an emergency services call. At a communication 642a, the MSC 212 identifies the call as an emergency service call and forwards call to the GMLC 226 with the serving cell information (e.g., ESRD) and calling party number (e.g., MSISDN) in an ISUP initial address message (IAM). At a communication 642b, using E911 features within the MSC 212, the MSC 212 sends a PLR message to the SMLC 228 via the BSC 208. At a communication 642c, the MSC 212 identifies the test call as a call requiring electronic surveillance (e.g., as a test mobile provisioned on MSC for CALEA
intercept) and sends, for example, a J-STD-025 LAESP origination message from its CALEA delivery function to the E91 1 test server 214 as if the E91 1 test server 214 is a law enforcement collection function.
100861 At a communication 643a, the GMLC 226 analyzes the MDN of the test mobile station (based on information in the IAM message) and identifies the call as a test call (e.g., based on the MDN or called number). At this point, the GMLC

may assign a temporary test ESRK as the routing digits to the MSC 212. The GMLC 226 may return the IAM to the MSC 212 over the ISUP loop-around (e.g., with the called party and calling party set equal to the test ESRK). At a communication 643b, upon receiving the PLR initiated by the MSC 212, the SMLC
228 begins the applicable location estimate process and procedures. At a communication 643c, triggered by the LAESP origination message, the E911 test server 214 sends an ESPOSREQ message to the GMLC 226. The ESPOSREQ
may include the MDN of the test mobile station 202 (e.g., as received in the LAESP origination message).
[0087] At a communication 644, the MSC 212 forwards the test call to the test destination (e.g., a location other than the PSAP) based on the test ESRK. At a communication 645 call setup signaling is completed. At a communication 646, the SMLC 228 calculates/obtains an acceptable location estimate using applicable processes/procedures (or a timer expires). At a communication 647, the SMLC
228 sends the location estimate back to the MSC 212 in a PLR response via the BSC 208. At a communication 648, the MSC 212 returns the location estimate of the test mobile (e.g., in the form of a latitude and longitude information) to the GMLC 226 in a SLR message.
[0088] At a communication 649a, the GMLC 226 acknowledges receipt of the SLR
with a SLR response. At a communication 649b, the GMLC 226 returns the location information back to the E911 server in a ESPOSREQ response. At a communication 650, the E911 test server 214 may log the data in a report file.
The E911 test server may also send the results to the test mobile station 202 (e.g., as an SMS message) and/or may email the results to a designated email account.
100891 At a communication 651, the test call is released. At a communication 652a, the MSC 212 may send an LAESP release message to the E911 test server via the CALEA intercept (e.g., to permit the E91 1 server to release any resources associated with the call). At a communication 652b, the MSC 212 sends a SLR
(release) message to the GMLC 226 to permit the GMLC 226 to release any resources associated with the call. At a communication 653, the GMLC 226 acknowledges receipt of the SLR message.
[0090] Figure 6D illustrates an example of location update call flow in the GSM Lg-Interface network architecture with ISUP loop-around. At a communication 661, it is assumed that an emergency services call has previously been established (e.g., call setup signaling is completed per the initial location call flow of Figure 6C). At a communication 662, an operator of the test mobile station 202 requests a new E911 location (e.g., by typing in a code using a keypad of the test mobile station).
At a communication 663, the MSC 212 receives the code input and in response, sends a dialed digit extraction message to the E911 test server 214. At a communication 664, the E911 test server 214 generates and sends an ESPOSREQ to the GMLC 226 (e.g., by mapping the caselD/calllD to the proper MSISDN and by mapping the information in the dialed digit extraction to the proper location request type).
[0091] At a communication 665, the GMLC 226 receives the ESPOSREQ which triggers the generation of a ProvideSubscriberLocation (PSL) that is sent to the MSC. At a communication 666, the MSC 212 translates the data contained in PSL' to generate and send a PLR message to the SMLC 228. At a communication 667, the SMLC 228 calculates/obtains an acceptable location estimate using applicable positioning methods/procedures (or a timer expires). At a communication 668, the SMLC 228 returns location information for the test mobile station 202 (e.g., in the form of a latitude and longitude) to the MSC 212 in a PLR response.
[0092] At a communication 669, the MSC 212 returns the location information to the GMLC 226 in a PSL response message. At a communication 670, the GMLC
226 returns the location information back to the E911 test server 214 in an ESPOSREQ response. The E911 test server may then log the location information in a report file. The E911 server may also send the location information to the mobile as an SMS message and/or email the results to a designated email account. At a communication 671, the test call is released. At a communication 672, the MSC 212 sends a LAESP release message to the E911 test server 214 via the CALEA intercept (e.g., to permit the E911 test server 214 to release any resources associated with the call). At a communication 673, the MSC 212 sends a SLR (release) message to the GMLC 226 to permit the GMLC 226 to release any resources associated with the call. At a communication 674, the GMLC 226 acknowledges receipt of the SLR message.
[0093] Figures 7A-7D are representative flow diagrams that show an alternate implementation of the testing scheme in UMTS network architecture. This network architecture can be implemented with or without the occurrence of an ISUP loop-around and may include a sequence of communications between various network components including a test user endpoint 302, a RNC 308, a MSC 310, an E911 test server 312, a GMLC 314, and a VRU 304.
[0094] Figure 7A illustrates an example of an initial location call flow in a UMTS
network architecture. At a communication 701, the user endpoint 302 initiates an emergency services call. Note: The proper signaling message flow for UMTS call setup is not depicted, but condensed into a CM Service request for the purpose of maintaining clarity in the drawings. At a communication 702a , using E911 features within the MSC 310, the MSC 310 sends a SLR message to the GMLC
314 to request an ESRK. The SLR message may include the test MSISDN and information relating to the serving cell/sector from which the mobile call originated (e.g., CGI or ESRD). At a communication 702b, the MSC 310 identifies the test call as a communication requiring electronic surveillance (e.g., as a test mobile provisioned on the MSC 310 for CALEA intercept) and sends, for example, a J-STD-025 LAESP origination message from its CALEA delivery function to the E911 test server 312 as if the E911 test server 312 is a law enforcement collection function (CF).
[0095] At a communication 703a, the GMLC 314 analyzes the MSISDN from the SLR message and identifies the call as a test call (e.g., based on the MSISDN).
Accordingly, the GMLC 314 may assign a temporary test ESRK as the routing digits to the MSC 310. The SLR response message enables the ESRK to be returned to the MSC 310. At a communication 703b, triggered by the LAESP
origination message, the E911 test server 312 sends an ESPOSREQ (which may include the MDN of the user endpoint 302, as received in the LAESP origination message) to the GMLC 314. At a communication 703c, the GMLC 314 receives the ESPOSREQ, which triggers the generation of a PSL message that the GMLC
314 sends to the MSC 310.
[00961 At a communication 704a, the MSC 310, based on the test ESRK, forwards the call to the test destination (e.g., a destination other than the PSAP). At a communication 704b, the MSC 310 translates the data contained in the PSL to generate and send a LRC message to the RNC 308. At a communication 705a, call setup signaling is completed. At a communication 705b, the RNC 308 calculates/obtains an acceptable location estimate using applicable positioning methods/procedures (or a timer expires). At a communication 706, the RNC 308 returns the location of the user endpoint 302 (e.g., in the form of a latitude and longitude) to the MSC 310 in a location report message. At a communication 707, the MSC 310 returns the location estimate of the user endpoint 302 in the form of a latitude and longitude to the GMLC 314 in a PSL response message.
[00971 At a communication 708, the GMLC 314 returns the location information back to the E911 test server 312 in an ESPOSREQ response. At a communication 709, the E911 test server 312 logs the data in a report file.
The E911 test server 312 may also (optionally) send the results to a designated recipient via, for example, an SMS or email message. At a communication 710, the test call is released. At a communication 711a, the MSC 310 sends an LAESP
release message to the E911 test server via the CALEA intercept to permit the E911 test server to release any resources associated with the call. At a communication 711b, the MSC 310 sends an SLR (release) message to the GMLC 314 to permit the GMLC 314 to release any resources associated with the test call. At a communication 712, the GMLC 314 acknowledges receipt of the SLR message.
[0098] Figure 7B illustrates an example of location update call flow in the UMTS
network architecture. At a communication 721, it is assumed that an emergency services call has previously been established (e.g., call setup signaling is completed per the initial location call flow of Figure 7A). At a communication 722, an operator of the test user endpoint 302 requests a new E911 location (e.g., by typing in a code using a keypad of the test mobile station). At a communication 723, the MSC 310 receives the code input and in response, sends a dialed digit extraction message to the E911 test server 214.
[0099] At a communication 724, the E911 test server 312 generates and sends an ESPOSREQ to the GMLC 314 (e.g., by mapping a caselD/caIIID for the test call to the appropriate MSISDN and the digit to the proper location request type). At a communication 725, the GMLC 314 receives the ESPOSREQ which triggers the generation of a PSL message that the GMLC 314 sends to the MSC 310. At a communication 726, the MSC 310 translates the data contained in the PSL to generate and send an LRC message to the RNC 308.
[00100] At a communication 727, the RNC 308 calculates/obtains an acceptable location estimate using applicable positioning methods/procedures (or a timer expires). At a communication 728, the RNC 308 returns the location of the test user endpoint 302 (e.g., in the form of a latitude and longitude) to the MSC
310 in a LocationReport (LR) message.
[00101] At a communication 729, the MSC 310 returns the location estimate of the test user endpoint 302 to the GMLC 314 in a PSL response message. At a communication 730, the GMLC 314 returns the location information back to the E911 server in and ESPOSREQ response. At a communication 731, the E911 test server 312 logs the data (e.g., in a report file). The E911 server may also (optionally) send the results to a designated source (e.g., as an SMS to the test user endpoint 302 and/or as an email to a designated email account).
[00102] At a communication 732, the test call is released. At a communication 733, the MSC 310 sends an LAESP release message to the E911 test server 312 via the CALEA intercept to permit the E911 test server 312 to release any resources associated with the call (if any). At a communication 734, the MSC 310 sends a SLR (release) message to the GMLC 314 to permit the GMLC 314 to release any resources associated with the call. At a communication 735, the GMLC 314 acknowledges receipt of the SLR message.
[00103] Figure 7C illustrates an example of an initial location call flow in a UMTS
network architecture with ISUP loop-around. At a communication 741, the test user endpoint 302 initiates an emergency services call. At a communication 742a, the MSC 310 identifies the call as an emergency service call and forwards call to the GMLC 314 with the serving cell information (ESRD) and calling party number (MSISDN) in an ISUP initial address message (IAM). At a communication 742b, using E911 features within the MSC 310, the MSC 310 launches a LRC message to the RNC 308. At a communication 742c, the MSC 310 identifies the call as requiring electronic surveillance (e.g., as a test mobile provisioned on the MSC
310 for CALEA intercept) and sends, for example, a J-STD-025 LAESP origination message from its CALEA delivery function to the E911 test server 312, as if the E911 test server 312 is a law enforcement collection function.
[00104] At a communication 743a, the GMLC 314 analyzes the MDN (e.g., from the IAM message) and identifies the call as a test call (e.g., based on the MDN or the called number). The GMLC 314 then assigns a temporary test ESRK as the routing digits to the MSC 310. The GMLC 314 then returns the IAM to the MSC
310 over the ISUP loop-around (e.g., with the called and calling party set equal to the test ESRK). At a communication 743b, upon receiving the LRC initiated by the MSC 310, the RNC 308 begins executing applicable location estimate process and procedures. At a communication 743c, triggered by the LAESP origination message, the E911 test server 312 sends an ESPOSREQ message to the GMLC
314, which may include the MDN of the test user endpoint 302 (e.g., as received in the LAESP origination message).
[00105] At a communication 744, the MSC 310 forwards the call to the test destination (e.g., a destination other than the PSAP) based on the test ESRK.
At a communication 745 call setup signaling is completed. At a communication 746, the RNC 308 calculates/obtains an acceptable location estimate (or a timer expires). At a communication 747, the RNC 308 sends the location estimate back to the MSC 310 in a LR message. At a communication 748, the MSC 310 returns the location estimate of the test user endpoint 302 (e.g., in the form of a latitude and longitude) to the GMLC 314 in a SLR message.
[00106] At a communication 749a, the GMLC 314 acknowledges receipt of the SLR
message with a SLR response message. At a communication 749b, the GMLC
314 returns the location information back to the E911 test server 312 (e.g., in an ESPOSREQ response message). At a communication 750, the E911 test server 312 logs the location information in a report file. The E911 test server 312 may also send the location information to a designated client (e.g., the test user endpoint 302 as an SMS and/or a designated email account via email). At a communication 751, the test call is released.
[00107] At a communication 752a, the MSC 310 sends an LAESP release message to the E911 test server 312 via the CALEA intercept to permit the E911 test server 312 to release any resources associated with the call. At a communication 752b, the MSC 310 sends a SLR (release) message to the GMLC 314 to permit the GMLC 314 to release any resources associated with the call. At a communication 753, the GMLC 314 acknowledges receipt of the SLR message.
[00108] Figure 7D illustrates an example of location update call flow in the UMTS
network architecture with ISUP loop-around.
[00109] At a communication 761, it is assumed that an emergency services call has previously been established (e.g., call setup signaling is completed per the initial location call flow of Figure 7A). At a communication 762, an operator of the test user endpoint 302 requests a new E911 location (e.g., by typing in a code using a keypad of the test mobile station). At a communication 763, the MSC 310 receives the code input and in response, sends a dialed digit extraction message to the E911 test server 214.
[00110] At a communication 764, the E911 test server 312 generates and sends an ESPOSREQ to the GMLC 314 (e.g., by mapping a caselD/caIIID for the test call to the appropriate MSISDN and the digit to the proper location request type). At a communication 765, the GMLC 314 receives the ESPOSREQ, which triggers the generation of a PSL message that the GMLC 314 sends to the MSC 310. At a communication 766, the MSC 310 translates the data contained in the PSL to generate and send an LRC message to the RNC 308.
[00111] At a communication 767, the RNC 308 calcuiates/obtains an acceptable location estimate using applicable positioning methods/procedures (or a timer expires). At a communication 768, the RNC 308 returns the location of the test user endpoint 302 (e.g., in the form of a latitude and longitude) to the MSC
310 in a LocationReport (LR) message. At a communication 769, the MSC 310 returns the location estimate of the test user endpoint 302 to the GMLC 314 in a PSL
response message. At a communication 770, the GMLC 314 returns the location information back to the E911 server in an ESPOSREQ response. At a communication 771, the E911 test server 312 logs the data (e.g., in a report file).
The E911 server may also (optionally) send the results to a designated source (e.g., as an SMS to the test user endpoint 302 and/or as an email to a designated email account).
[00112] At a communication 772, the test call is released. At a communication 773, the MSC 310 sends an LAESP release message to the E911 test server 312 via the CALEA intercept,to permit the E911 test server 312 to release any resources associated with the call (if any). At a communication 774, the MSC sends a SLR
(release) message to the GMLC 314 to permit the GMLC 314 to release any resources associated with the call. At a communication 775, the GMLC 314 acknowledges receipt of the SLR message.

D. Conclusion [00113] Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising," and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense;
that is to say, in the sense of "including, but not limited to." Additionally, the words "herein," "above," "below," and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application. When the claims use the word "or" in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.
[00114] The above detailed description of embodiments of the invention is not intended to be exhaustive or to limit the invention to the precise form disclosed above. While specific embodiments of, and examples for, the invention are described above for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative embodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel, or may be performed at different times. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number, respectively.
[00115] The teachings of the invention provided herein can be applied to other systems, not necessarily the system described herein. The elements and acts of the various embodiments described above can be combined to provide further embodiments.

[00116] All of the above patents and applications and other references, including any that may be listed in accompanying filing papers, are incorporated herein by reference. Aspects of the invention can be modified, if necessary, to employ the systems, functions, and concepts of the various references described above to provide yet further embodiments of the invention.
[00117] These and other changes can be made to the invention in light of the above Detailed Description. While the above description details certain embodiments of the invention and describes the best mode contemplated, no matter how detailed the above appears in text, the invention can be practiced in many ways. As noted above, particular terminology used when describing certain features or aspects of the invention should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the invention with which that terminology is associated. In general, the terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification, unless the above Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the invention encompasses not only the disclosed embodiments, but also all equivalent ways of practicing or implementing the invention under the claims.
[00118] While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. For example, while only one aspect of the invention is recited as embodied in a computer-readable medium, other aspects may likewise be embodied in a computer-readable medium. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.

Claims

1. A system for testing a wireless network that communicates with users of mobile phones, the system comprising:
at least one mobile switching center associated with the wireless network, wherein the mobile switching center is coupled to a database and is configured to:
receive a call from one of the mobile phones, determine that the call is a call for emergency services, send a request for location information associated with the one mobile phone based on the determination that the call is for emergency services, determine that the call requires electronic surveillance, and send a wiretap message at least partially formatted under a Lawfully Authorized Electronic Surveillance Protocol (LAESP) based on the determination that the call requires electronic surveillance;
at least one location determining system, wherein the location determining system is configured to:
receive the request from the mobile switching center for location information associated with the one mobile phone, and determine a geographic location of the one mobile phone; and at least one test server coupled to communicate with the mobile switching center and the location determining system, wherein the test server is configured to:
receive the at least partially LAESP formatted wiretap message, send a location request message to the location determining system, receive the determined geographic location of the one mobile phone, and, log test data, including the determined geographic location of the one mobile phone, without requiring involvement of a Public Safety Answering Point (PSAP) or E911 call center.

2. The system of claim 1 wherein the one mobile phone has associated with it a test mobile directory number (MDN), wherein the test MDN is associated with a sequential block of test MDNs that cannot receive calls from outside the wireless network, wherein the mobile switching center is configured to translate calls received from the test MDNs into a number associated with a continuous range of Emergency Services Routing Key (ESRK) numbers to send the request for location information, and wherein the test server is configured to send, in near real time, the location information to the one mobile phone as an email message or as a Short Messaging Service (SMS) message.

3. The system of claim 1 wherein the location determining system recognizes the mobile phone as an E911 test mobile station based on the mobile directory number (MDN) of the test mobile phone.

4. The system of claim 1 wherein the wireless network is a Global System for Mobile Communication (GSM) network.

5. The system of claim 1 wherein the wireless network is associated with a Universal Mobile Telecommunications System (UMTS) environment.

6. The system of claim 1 wherein the wireless network is an ANSI-41 environment.

7. A method for testing a wireless network that facilitates communication using mobile phones, the method comprising:
receiving a call from one of the mobile phones;
determining that the call is for emergency services or for testing emergency services, sending a request for location information associated with the mobile phone based on the determination that the call is for emergency services or for testing emergency services, sending a wiretap message at least partially formatted under a Lawfully Authorized Electronic Surveillance Protocol (LAESP) based on the determination that the call requires electronic surveillance; and logging the location test data, including the determined geographic location of the one mobile phone, without requiring involvement of a Public Safety Answering Point (PSAP) or E911 call center.

8. The method of claim 7 wherein the call is placed by dialing the numbers 9-1-1, and wherein the mobile phone is identified as a test station based on its mobile directory number (MDN).

9. The method of claim 7 wherein the call is placed by dialing numbers other than the numbers 9-1-1, and wherein the dialed numbers allow the call to be recognized as an emergency services test call.

10. A method for testing emergency response functionality implemented on a wireless network, the method comprising:
receiving an emergency services test call from a mobile device for purposes of testing the emergency response functionality;
identifying the test call as a call requesting electronic surveillance in a system implemented, at least in part, for conducting surveillance under the Communications Assistance for Law Enforcement Act of 1994 (CALEA); and facilitating the receipt of a Lawfully Authorized Electronic Surveillance Protocol (LAESP) origination message by a test server, wherein the test server stands in for a CALEA law enforcement collection function, and wherein the test server generates test result data associated with the emergency response functionality.

11. The method of claim 10 wherein the emergency response functionality is associated with implementing E911 Phase 1.

12. The method of claim 10 wherein the emergency response functionality is associated with implementing E911 Phase 2.

13. The method of claim 10, further comprising:
identifying an approximate location of the mobile device at the time of the emergency services test call.

14. A system for testing emergency response functionality implemented on a wireless network, the method comprising:
means for receiving an emergency services test call from a mobile station;
means for identifying the test call as a call requiring electronic surveillance;
and means for facilitating the receipt of an electronic surveillance message by an emergency services test server, wherein the test server stands in for an electronic surveillance collection function.

15. The system of claim 14, further comprising:
means for identifying an approximate location of the mobile station at the time of the emergency services test call.

16. The system of claim 14, further comprising:

means for determining a routing scheme for the test call based on analyzing at least one code transmitted in association with the test call.

17. At a server system configured for collecting test data associated with testing emergency response functionality implemented on a wireless network, the method comprising:
receiving a message from a delivery function primarily intended for use in legal electronic surveillance of telephone communications including interception of call content and/or call data;
wherein the received message is associated with a test call placed from a mobile device for the purpose of testing the emergency response functionality, and wherein the received message includes information that can be used to assess the performance of the emergency response functionality as implemented on the wireless network.

18. The method of claim 17 wherein the received message indicates the cell site and sector from which the test call originated and mobile identification number (MIN) information, mobile directory number (MDN) information, and electronic serial number (ESN) information for the mobile device.

19. The method of claim 17 wherein the test call placed from the mobile device is forwarded from a mobile switching center to a test destination other than a public safety answering point (PSAP).

20. The method of claim 17 wherein the test call placed from the mobile device is forwarded from a mobile switching center to a test destination other than a public safety answering point (PSAP), and wherein information associated with the forwarded call includes an integrated services digital network user part (ISUP) initial address message (IAM) called party number (CdPN) that signifies the test destination and a calling party number (CgPN) that signifies a test emergency services routing key (ESRK).

21. The method of claim 17 further comprising:
in response to receiving the message from a CALEA delivery function, initiating a process for determining an approximate location of the mobile device, wherein the initiated process includes:
the server system sending a request message to a mobile positioning center, the mobile positioning center, upon receipt of the request message, launches a position request message to a position determining entity, and the positioning determining entity determining an approximate location of the mobile device, including latitude and longitude information.

22. The method of claim 17 further comprising:
in response to receiving the message from the delivery function, initiating a process for determining an approximate location of the mobile device, wherein the initiated process includes:
the server system sending a request message to a mobile positioning center, the mobile positioning center, upon receipt of the request message, launches a position request message to a position determining entity, the positioning determining entity determining an approximate location of the mobile device, the position determining entity returning location information to the mobile positioning center, the mobile positioning center returning the location information to the server system, and the server system comparing the returned location information with known location information.

23. The method of claim 17 wherein the delivery function is implemented according to CALEA J-STD-025.

24. The method of claim 17 wherein the received message is formatted according to a Lawfully Authorized Electronic Surveillance Protocol (LAESP).

25. The method of claim 17 wherein the legal electronic surveillance of telephone communications including interception of call content and/or call data is implemented in accordance with the Communications Assistance for Law Enforcement Act of 1994 (CALEA).

26. A computer-readable medium containing instructions for performing a method comprising:
testing emergency response functionality implemented in association with a wireless network including:
using CALEA features to trigger emergency response functionality test queries.

27. The computer-readable medium of claim 26 wherein triggering the emergency response functionality test queries includes placing at least one test call from a test station, wherein the test call is treated like a communication that requires surveillance under CALEA.

28. The computer-readable medium of claim 26 wherein triggering emergency response functionality test queries includes receiving, at a CALEA
delivery function, information about a at least one test call placed from a test station and forwarding at least some of the received information to a test server configured to serve as a proxy for a CALEA collection function with respect to test calls.

29. The computer-readable medium of claim 26 wherein the emergency response functionality includes providing location information for a mobile station that calls an emergency service provider.

30. The computer-readable medium of claim 26 wherein the method further comprises.
logging test data at a server.

31. The computer-readable medium of claim 26 wherein the method further comprises.
logging test data at a server; and sending logged test data to an email account or mobile device.