Mayday/9-1-1 Field Operational Test (FOT) Design Report
For the PDF version of this document, please click here.
Document Number: 232003
Revision E
March 10, 2006
Prepared for:
Minnesota Department of Transportation
This document was prepared by:
Melvin Gail Linnell, PhD
Telcordia Technologies
mlinnell@telcordia.com
Stan Wainberg, PhD
Telcordia Technologies
swainber@telcordia.com
Lawrence Haynes
Program Manager
SAIC
haynesla@saic.com
For further information, please contact:
Stan Wainberg, PhD
Telcordia Technologies
swainber@telcordia.com
Bradley Estochen, P.E.
ITS Project Manager
Office of Traffic, Security and Operations
Minnesota Department of Transportation
Bradley.estochen@dot.state.mn.us
Lawrence Haynes
Program Manager
SAIC
haynesla@saic.com
Trademark Acknowledgments
Telcordia® is a registered trademark of Telcordia Technologies, Inc. All other brand or product names are trademarks of their respective companies or organizations.
Table of Contents
1. Introdution 1.1 Purpose 1.2 Scope 1.3 Intended Audience 1.4 Relationship to Other Documents 1.5 Document Organization 1.6 Acknowledfements 1.7 Definitions
2. Network Architecture 2.1 TSPECRS Network Architecture 2.2 Example Successful TSPECRS Scenario
3. Prototype Lab and Network Configuration for Mayday/9-1-1 Testing 3.1 Lab and Network Test Configuration 3.2 Mayday/0-1-1 FOT Vehicle Test Unit 3.3 Serving MSC 3.3.1 S-MSC TSPECRS Call Origination 3.3.2 S-MSC TSPECRS Call Routing 3.4 TSPECRS Telematics Call Center 3.5 Tandem MSC 3.6 Home Location Register 3.7 Mobile Positioning Center (MPC) 3.8 Selective Router 3.9 PSAPs 3.9.1 IES Served PSAPs 3.9.2 Qwest Served PSAPs 3.10 Network Connectivity 3.10.1 Network Connectivity 3.10.2 Telcordia Lab to Minnesata Selective Router ansd ALI DBs
4. FOT Testing 4.1 Evaluation Team 4.2 Test Plan 4.3 Selected PSAPs 4.4 Data Collection 4.4.1 Data Collection Form Example 4.4.2 XML Data Example 4.4.3 NSTS Data Example 4.4.4 Sample PSAP Screen 4.5 Test Schedule
5. Reference
APPENDIX A - Acronyms>
APPENDIX 8 - XML Schema for TCC to T-MSC/NEDR Interface
APPENDIX c - Model Call Center and Opertions Environment Functional Block Diagram
APPENDIX D - Detailed System Call MessagesList of Figures
Figure 2-1 TSPECRS Architecture Figure 2-2 Successful TSPECRS Call = Wireless Network Uses NCAS Figure 3-1 Mayday/9-1-1 FOT Test Configuration Figure 3-2 High Level Call Flow for Test Call Figure 3-3 Detailed Call Flow for Test Call Figure 3-4 Portable OnStar Test Unit Figure 3-5 Minnesota E9-1-1 Network Figure 3-6 OnStar - Telcordia Connectivity Figure 3-7 Telcordia Lab to Minnesota SR Connectivity Figure 3-8 Telcordia Lab to ALI DB Connectivity Figure 4-1 Data Collection Form Figure 4-2 PSAP Screen (1 of 3) Figure 4-3 PSAP Screen View (2 of 3) Figure 4-4 PSAP Screen (3 of 3) IES Special Application Figure C-5-1 Model Call Center - Functional Block Diagram
Within the United States, there are significant, well-acknowledged challenges in routing and delivering Telematics Service Provider (TSP) emergency calls, and associated vehicle location and crash data information, across the nation to the appropriate local Public Safety Answering Points (PSAPs) using the local, native 9-1-1 networks. The 9-1-1 networks are local, disconnected from each other, and are not coordinated at a national level. Telematics calls must traverse long distances, far from the location of the emergency, to the national, centrally located Telematics Call Center (TCC) of the TSP. Once at the TCC, there is no existing, effective way to route these calls back to the relevant, local 9-1-1 network as an emergency call. Today, the TSP calls are routed via the Public Switched Telephone Network (PSTN) to an administrative line at the appropriate PSAP. This is accomplished by the TCC using a lookup table for these telephone numbers in a database that must be kept up to date. Since these calls come in on the administrative line, the PSAP may not give them the same priority as normal arriving 9-1-1 calls. Since these calls are PSTN voice only, many of the data features associated with 9-1-1 networks interconnecting to wireless and wireline networks are not available between the TCC and PSAPs. All of the data information must be provided to the PSAP operator verbally which can lead to mistakes and delays. The TSP Emergency Call Routing Service (TSPECRS) Concept of Operations provides more details on this issue and the type of information and data that the TSPs wish to send to the PSAPs [1]
In addition to the basic 9-1-1 data/information related to call back number, vehicle location, and vehicle identification, the TSPs are able to send to the TCC various crash data during an emergency call. Telematics emergency calls can be of three types: emergency-key-press calls, Automatic Crash Notification (ACN) calls and Advanced Automatic Crash Notification (AACN) calls. Emergency-key-press calls are also known as SOS calls. ACN calls are also known as airbag calls. Further details are in Concept of Operations Report [1].
The TSP Emergency Call Routing Service (TSPECRS) System Specification [2] specifies the architecture, interfaces/protocol and system requirements to facilitate routing of a TSP emergency call to the appropriate 9-1-1 network and PSAP, by utilizing the Wireless Service Provider (WSP) network. TSPECRS allows a TCC to make TSP emergency calls via the wireless network (and the PSTN), and make them appear as wireless E9-1-1 Phase 2 calls to the PSAPs. In addition, the TSPECRS System Specification describes procedures that would facilitate transmission of TSP data to the PSAPs via the signaling network of the WSP. This solution relies on the ongoing partnership of TSPs with WSPs to leverage existing wireless network resources with special enhancements for TSPECRS. TSPECRS specific enhancements are also required at the PSAPs and in the 9-1-1 databases to retrieve Telematics vehicle crash data from the TSPs to allow display on PSAP screens.
This document outlines the architecture, network connectivity, lab facilities and test procedures used to demonstrate and test TSPECRS. This effort and field testing was done under an SAIC contract with the State of Minnesota, called "Voice Routing for Mayday Field Operational Test," and contract number SC # ONS02807. The overall Mayday Field Operational Test also includes testing on the data routing that is possible from a TSP and a separate series of reports are available for that portion of the test [10] , [11]. The state of Minnesota received the sponsorship and funding for this program from the United States Department of Transportation - ITS Joint Program Office - Public Safety Program and National Highway Traffic Safety Administration - Emergency Medical Services Division. In particular, SAIC and Telcordia teamed with the Minnesota Department of Transportation (MNDOT) and OnStar to set up this Mayday/9-1-1 Field Operational Test (FOT) and perform the testing. In addition, this team was supported by Qwest, Hutchinson Telephone, Intrado and Independent Emergency Services (IES), providing connectivity and 9-1-1 service access, including access to twenty-two (22) PSAPs. Further, IES enhanced their 9-1-1 systems to accept additional AACN information sent to their PSAPs. This team also coordinated with Battelle, which was responsible for the evaluation of the voice routing capabilities of the Mayday/9-1-1 FOT, and sponsored by USDOT ITS-Joint program Office, Public Safety Program. In particular, the team provided input and feedback to Battelle in the development of the "Detailed Evaluation Plan," [3] and coordinated efforts during the actual testing and evaluation phase. Additional documentation by this operational team and the evaluation team provides the FOT test results, evaluation, lessons learned and path forward. [4][5].
The following subsections detail the document purpose, scope, intended audience, document organization, and definitions.
This document describes a proof of concept demonstration environment to support the Field Operational Test (FOT) for the TSPECRS voice routing functionality, as described in reference [2]. This document provides a description of the proposed architecture for TSPECRS, and modifications specific to this demonstration, and test procedures, used for the FOT and subsequent evaluation. The TSPECRS System Specification is a basis for this document and corresponding FOT efforts [2]. As such throughout the remainder of this document, the FOT will be referred to as the Mayday/9-1-1 FOT. In particular, the following is included in this document:
This document supports the evaluation process of the TSPECRS solution. A companion document called "Mayday/9-1-1 Field Operations Test Results and Path Forward," provides information and detail on the Mayday/9-1-1 FOT results and path forward [4]. The FOT evaluation results are described in "Final Report: Mayday/9-1-1 FOT Analysis" developed by Battelle [5]. The document "Test Plan: Mayday/9-1-1 Field Operations Test Independent Testing of Voice Routing Functions," authored by Battelle, lays out the evaluation and acceptance test plan, including the supporting statistical analysis to determine the success of the FOT demonstration[3].
This document provides an overview of the TSPECRS System Specification, and detailed description of the demonstration/test environment, and testing to be performed. The network operations and aspects of TSPECRS are beyond the scope of this Specification and are not of concern for this FOT.
The intended audience of this document or parts thereof includes:1.4 Relationship to Other Documents
This document is based on the TSPECRS System Specification. This document references the evaluation and acceptance test plan developed by the government evaluation team headed by Battelle, and is a companion document to a test results document [3][4]. The data portion of the Mayday/9-1-1 Project has corresponding documentation in the following two documents: 1) Mayday/9-1-1 Field Operational Test Data Routing Concept of Operations Report [10] and 2) Mayday/9-1-1 Field Operational Test Data Routing Project Final Report [11].
The organization of the remainder of this document is as follows:
The Minnesota Department of Transportation gratefully acknowledges the invaluable contributions of the following individuals and organizations. Without their generous donation of time, experience, and expertise, the success of this project would not have been possible:
This section shows the TSPECRS network architecture and the enhancements to the network architecture including the network entities and associated interfaces.
2.1 TSPECRS Network Architecture
Figure 2 1 illustrates the TSPECRS architecture as specified in the TSPECRS System Specification, with the addition of the National Emergency Data Router (NEDR) to facilitate connectivity between the TCC(s) and ALI Databases (DBs) for crash data transfer. Note that the SRs, SRDBs, PSAPs and ALI DBs constitute the 9-1-1 network within a region. This 9-1-1 network is connected to the WSP network by 9-1-1 trunks connected to each S-MSC and by E2 data interfaces to the MPC of the WSP. All interfaces in the architecture are based on existing standards for 9-1-1 and wireless networks. However, as shown in the TSPECRS System Specification, all wireless system interfaces, protocols and procedures require a small enhancement to support TSPECRS. In addition, the E2 interface and/or the NEDR interfaces require an enhancement to transport the AACN information. The TCC to T-MSC data interface is new to the industry. The NEDR and its interfaces to the ALI and TCC is also new to the industry.
Figure 2-1 TSPECRS Architecture
2.2 Example Successful TSPECRS Scenario
TSPECRS call to a PSAP used Non-call Associated Signaling (NCAS) methodology for the FOT demonstration and Voice Routing Evaluation.
Figure 2-2 illustrates this TSPECRS message call flow. This scenario describes a successful TSPECRS call to a PSAP. The wireless network uses NCAS methodology for 9-1-1 call processing. Other example call flows are shown in the TSPECRS System Specification. Note that this figure also shows where signaling enhancements are required.
Figure 2-2 : Successful TSPECRS Call – ireless Network Uses NCAS
Note: If the call is handed off to another Serving MSC, the ROUTREQ message will be sent to the Anchor MSC[1]. It is irrelevant whether the TMS has subsequently handed off or not since the responsibility for setting up the call to the PSAP remains in the anchor system.
Note: The S-MSC maintains two calls references since there are two separate calls involving the S-MSC. One of the calls is between the S-MSC and the TCC and the other is between the T-MSC and the S-MSC.
Note 1: The PSAP agent may verbally request the TCC advisor to provide the TMS location information. The TCC advisor will have to switch the Telematics call to data mode and probe the TMS to provide its updated location information. Once the updated TMS location information is received, it can be provided to the ALI via another ACN Directive message. Alternatively, the first ACN directive message can provide the case ID and the OCC callback number to the ALI, which can be used by the ALI to query the NEDR for updated TMS location information.
Note 2: In the FOT, the NEDR was logically associated with the T-MSC signaling/control logic. As such, the original TCC to T-MSC data burst included the ACN information. In addition, the ACN information was sent over the E2 interface to the ALI DB on request from the PSAP. The TSPECRS System Specification shows a direct link between the TCC and ALI DBs to transfer the ACN, using an ACN Directive message and a corresponding acknowledgement message. The standards bodies may have to revisit these NEDR concept and interfaces.
3. Prototype Lab and Network Configuration for Mayday/9-1-1 Testing
This section of the document describes the full Mayday/9-1-1 FOT test configuration, in addition to more details on the message flows for a test call. In the first subsection, an overview of the entire system is provided, in addition to test call flows. In each of the subsequent subsections, a component of the configuration is described, in addition to the network connectivity.
3.1 Lab and Network Test Configuration
Figure 311 illustrates the full test configuration for the Mayday/9-1-1 FOT. As shown, the test configuration consists of four segments, combining real live networks and laboratory systems:
The OnStar lab connects to the Telcordia lab via the PSTN for voice calls and the internet for data transfer. The Telcordia lab connects to the Minnesota 9-1-1 networks via a T-1 transmission facility which contains the voice and data circuits.
The Telcordia lab prototype reflects the wireless network elements of a WSP, affected by the TSPECRS, including the MPC. In particular, the lab combines real network switching elements (i.e., 5ESS switch) for the call routing and software systems (i.e., Network Services Test System (NSTS) and host computer) to simulate the signaling/control associated with the T-MSC, HLR, MPC and the multiple S-MSCs. Thus using AIN TCAP signaling for coordination, the combination of the switch and signaling/control software systems provide full MSC capabilities as relates to the TSPECRS needs. Different elements within the NSTS/host computer perform the signaling/control functions of the S-MSC/VLR, T-MSC, HLR and MPC. For the FOT, the NEDR function was logically implemented in the T-MSC signaling/control element, allowing the AACN data received from OnStar to be transferred to the ALI DBs via the E2 interfaces. The decision to use the Telcordia laboratory equipment to represent the enhanced WSP instead of the actual wireless network elements for TSPECRS was made based on two major considerations: 1) the cost of having equipment vendors develop the new capability for the MSCs, HLR, MPC and have these capabilities deployed in OnStar’s WSP network was beyond the level of available funding and 2) the time required to develop and deploy the service was beyond the desired time frame for the Mayday/9-1-1 FOT and demonstration.
Figure 3‑ 2 shows a high level view of the call flow for the FOT demonstration. Figure 3-3 provides a detailed view of the message and signaling flow for a call during the demonstration, and between the test elements. In Figure 3‑ 3, the first line marked “a”, indicates a call being made from the test vehicle to the OnStar Lab/Call Center – this call actually transverses the Wireless Service Provider’s (i.e., Verizon Wireless) network, and does not use a lab network until after reaching the OnStar lab.
Figure 3-1 Mayday/9-1-1 FOT Test Configuration
Figure 3-2 High Level Call Flow for Test Call
Figure 3-3 Detailed Call Flow for Test Call
Mayday/9-1-1 FOT Vehicle Test Units were provided by OnStar. The portable test unit on the OnStar Equipped Vehicle (OEV) was designed to transmit the same information that a real installed unit would if the “SOS” button was pushed, an ACN event occurred, or an AACN event occurred. Part of the unit provided by OnStar is a computer that is used to control the scenario of interest for a particular test call. During the testing process, a vehicle operator (or test call initiator) drove to various serving areas of the selected PSAPs, deployed the test unit and initiated a test call. Figure 3‑ 4 shows the portable test unit.
Figure 3 4 Portable OnStar Test Unit
For the FOT, the test call originated from a Mayday/9-1-1 FOT Vehicle Test Unit (or TMS), was routed through the MSCs of Verizon Wireless (the WSP) serving the region, and subsequently routed through the PSTN to the TCC in the OnStar lab. The actual wireless network was used, with no network modifications for this segment of the FOT call. Subsequent calls/connections, starting at the TCC and terminating on the PSAPs, relate to the new TSPECRS capabilities specified in [2] and simulated for the FOT and demonstration.
For TSPECRS, the 9-1-1 calls are routed back to the S-MSC serving the TMS, and subsequently routed onto the local 9-1-1 network.
For the Mayday/9-1-1 FOT, the function of the Serving MSC for routing the calls was performed by a combination of a 5ESS switch and NSTS simulator in the Telcordia laboratory. The simulator performed the SS7 signaling using the wireless ANSI-41 protocol, and associated control functions. The 5ESS switch provided the voice switching and call routing. SS7 AIN TCAP signaling was used between the wireless simulator and the 5ESS switch to coordinate the call routing with the wireless processing, signaling and control. The 5ESS switch had four trunk groups to itself (loop around trunks) to simulate the connectivity between the T-MSC and four different S-MSCs (corresponding to the S-MSCs in the Verizon Wireless network). There were also three CAMA/MF trunk groups from the Telcordia 5ESS switch to the three Selective Routers in Minnesota ( Minneapolis, Rochester and Hutchinson). Each of the CAMA trunk groups had two trunks to the SR. The simulated S-MSC had an SS7 signaling link into a Tekelec Eagle STP (in the Telcordia laboratory) for the signaling connectivity to the 5ESS (transport of AIN TCAP) and to the other wireless elements.
3.4 TSPECRS Telematics Call Center
For the FOT, a combination of OnStar’s Laboratory and a live OnStar Call Center were used to model the TCC. The test call initially arrives at the OnStar Laboratory where a custom application receives the data from the Vehicle Test Unit. Upon receiving the data from the TMS in the test vehicle, the OnStar Lab application accesses a web service application at the T-MSC in Telcordia’s laboratory. The OnStar TCC application sends the vehicle data to T-MSC in an XML format (schema is shown in Appendix B). The T-MSC application returns a 10 digit phone number (or TLDN) that is used to route the Mayday/9-1-1 FOT call to the simulated T-MSC at Telcordia. The call is then forwarded to the OnStar Call Center where an OnStar Emergency Advisor interacts with the test call initiator in the test vehicle. The voice call connection between the OnStar Call Center and the T-MSC is over the PSTN. The data link between the TCC at OnStar and the Telcordia T-MSC is via the internet (described in detail in sect 3.10). Appendix C shows a view of a model call center.
For the FOT, the function of the Tandem MSC (T-MSC) at Telcordia was performed by a combination of a 5ESS switch, a UNIX host and a simulator. The simulator performed the SS7 signaling using the ANSI-41 protocol, the UNIX host had a web service enabled to exchange XML data with the OnStar Laboratory; and the 5ESS switch provided the voice call switching. The TCC voice access to the T-MSC is via an ISDN Primary Rate Interface (PRI) connection to the PSTN (at the Red Bank, NJ, Verizon Central Office). Calls arrive on this PRI facility and are routed through the Telcordia lab network prior to being routed back to Minnesota and the appropriate Selective Router. The simulated T-MSC had an SS7 signaling link into a Tekelec Eagle STP, in the Telcordia lab, for the AIN TCAP interactions with the 5ESS and signaling to the other wireless elements.
While the NEDR was not physically represented in the FOT test bed, information that would normally have been sent to the NEDR was sent to the T-MSC over the XML data interface between Telcordia and OnStar systems. This information was passed to the application simulating the MPC and was available to be passed over the E2 interfaces to the ALI DBs. AACN information was passed over the E2 interface to a custom built application at the IES ALI DB. Three PSAPs and the ALI DB in the IES region were also enhanced to accept the AACN information.
For the FOT, the Home Location Register (HLR) was simulated using NSTS simulator. The SS7 signaling messages exchanged between the HLR, the S-MSC/VLR and the T-MSC were formatted as described in the TSPECRS System Specification, which is an enhancement to the TIA/EIA/ANSI-41 standards. The simulated HLR had an SS7 signaling link into a Tekelec Eagle STP in the Telcordia lab for signaling connectivity to the other wireless elements.
For the FOT, the Mobile Positioning Center (MPC) was simulated using the NSTS simulator and a UNIX host. The UNIX host maintained the E2 interfaces to the ALI DBs, and the NSTS simulator processed ALI DB requests and exchanged SS7 signaling with the S-MSC. The signaling messages, exchanged between the MPC and the S-MSC, were formatted as described in the TSPECRS Specification which is an enhancement to the TIA/EIA/ANSI-41 standards. The signaling messages exchanged between the MPC and the ALI databases were formatted as described in the E2 interface documents provided by Qwest and IES [7],[9], which are based on NENA standards [6],[8]. The simulated MPC had an SS7 signaling link into the Tekelec Eagle STP, in the Telcordia lab, for the internal lab signaling interactions.
For the FOT, actual 9-1-1 Selective Routers (SRs) were used in Minnesota. Three SRs, two in the Qwest territory and one in the IES territory were selected for inclusion in the testing. Qwest is the major local exchange carrier. Independent Emergency Services (IES) provides 9-1-1 service to independent local exchange carriers that serve the more rural parts of Minnesota. The SRs in the Qwest territory were in Minneapolis and Rochester. The SR in the IES territory was in Hutchinson. All of the SRs were in-service Lucent 5ESS switches. For pre-FOT internal testing, an additional Selective Router (i.e., DMS 100/200) in the Telcordia lab was used at times to route to a lab PSAP. Figure 3-5 shows all of the SRs in Minnesota.
All PSAPs for the FOT test calls were live county or city PSAPs serving selected areas of Minnesota. In addition, IES and Telcordia had test PSAPs that were used for pre-FOT verification testing. Figure 3-5 shows the E9-1-1 network Selective Routers and county boundaries for the State of Minnesota. Note that outside of the Minneapolis/St Paul metropolitan area, most PSAPs in Minnesota are on a county basis. A select set of PSAPs were chosen to give a sample of both rural and urban PSAPs, and to provide a range of equipment types for connectivity.
Figure 3-5 Minnesota E9-1-1 Network
The PSAPs in IES were:
In addition to the normal E9-1-1 information such as lat/long, IES developed a special application in the ALI DB and three PSAPs to receive additional AACN data in the E2 message from the MPC, and display the additional crash data at the three PSAPs. For the FOT, the additional information was passed in the Location Description parameter, which is defined in the E2 standard, but using presently a non-standard coding of the XML contents, shown in Appendix B.
The PSAPs in Qwest territory were in two parts of Minnesota – Minneapolis and Rochester. The Minneapolis PSAPs were:
The Rochester PSAPs were:
In addition, some Mayday/9-1-1 FOT test calls were forwarded to the Mayo Clinic Emergency Communications (secondary PSAP). The Qwest PSAPs were not enhanced for the FOT, but accepted the normal E9-1-1 information such as lat/long.
The data connection between the OnStar TCC Lab and the T-MSC in the Telcordia Lab was via the public internet for the data transfer. A web service application at the T-MSC responded to requests from the OnStar TCC lab by providing a 10-digit phone number (TLDN) that was used by the OnStar Emergency Advisor to place the Mayday/9-1-1 FOT call to the T-MSC, that was destined to the SR and the appropriate PSAP. OnStar used the PSTN to set up a three-way call with the TMS and connect to the Telcordia switch for the voice call routing. The TLDN phone number provided back by Telcordia on the data link, allowed the OnStar TCC to voice connect to the 5ESS switch via the incoming Primary Rate Interface (PRI), leased from Verizon for the purposes of this FOT demonstration. The Telcordia Lab and OnStar lab data connection had routers configured to allow the OnStar nodes to access the Telcordia web service at the T-MSC, enabling the exchange of the necessary service information. In coordination with call set-up, the data link between the OnStar Lab and the Telcordia Lab was tested to ensure that the message exchange was reliable and met the message transport time performance needs for the FOT. Figure 3-5 shows the OnStar to Telcordia connection arrangements.
Figure 3-6 OnStar - Telcordia Connectivity
A T-1 transmission facility was leased from Qwest to connect the Telcordia Lab in Red Bank, NJ to a Qwest Point of Presence (POP) in Minneapolis, MN. From the T-1 POP in Minneapolis, nine DS0 circuits (connecting to the T-1 facility circuits) were leased (from Qwest and Hutchinson Telephone) to connect to the three SRs and three ALI Databases (DBs). There were two DS0 trunk circuits leased to each of the three SRs (at Minneapolis, Rochester and Hutchinson). There was one DS0 56 kbps data circuit leased to connect to each of three ALI DBs. The ALI DBs were located in Minneapolis, MN, Denver, CO, and Hutchinson, MN. The Minneapolis and Denver ALI DBs are a mated pair serving the Qwest 9-1-1 network in the Minnesota area of interest, and supported by Intrado. The Hutchinson ALI DB helped serve the 9-1-1 network in the IES territory. The DS0s connecting to the ALI DBs were used for data transport using the TCP/IP protocol. The E2 interface application protocol used the TCP/IP services for connectivity between the MPC and the ALI DBs. The E2 interface followed the NENA standard, but the interfaces were slightly different for Qwest and IES, in that the latter carried AACN data. (For the FOT, IES supported the Location Description Parameter in the E2 protocol to have non-standard XML AACN data enclosed.) The DSOs to the SRs were voice channels (i.e., 9-1-1 trunks) used to carry the emergency calls. These voice channels were CAMA trunks using MF signaling for the call set-up. The TSPECRS System Specification allows for either SS7 or MF trunk signaling, where SS7 is more forward-looking and evolvable. Although SS7 signaling could have been used for the trunk signaling, the in-band MF signaling was adequate for this FOT demo, in that proper information was sent and the extra signaling time delay was not significant for the FOT. SS7 was not used for the FOT due to the significant additional leasing expense and added complexity in the interconnection. The MF trunk signaling included the ESRK to allow the SR to route the call to the appropriate PSAP. Figures 3-6 and 3-7 show the Telcordia lab to the SRs and to ALI DBs connection arrangements.
All trunk and data circuits went through rigorous testing before acceptance of the leases, and use in the FOT. In support of the TSPECS FOT, the Minnesota Department of Public Safety made available a large set of ESRKs (or PANIs) for unique assignment to the PSAPs and provisioning of the corresponding SRs. In addition to the ESRK assignments, other data files were provided to Qwest and Intrado to facilitate the provisioning of the SRs and ALI DBs. In addition to the trunk testing to each of the SRs, all the E2 interfaces went through rigorous testing before full acceptance and use in the FOT. After all the circuits were connected and systems provisioned, end-to-end tests were done to each of the PSAPs to check for correct call routing and data transfer.
Figure 3-7 Telcordia Lab to Minnesota SR Connectivity
Figure 3-8 Telcordia Lab to ALI DB Connectivity
4. FOT TestingThe USDOT hired Battelle (supported by the Melcher Group) to evaluate the performance of the Mayday/9-1-1 FOT. The USDOT and Mitretek provided oversight to the evaluating group and coordinated efforts with the FOT operational team. Representatives from these organizations are listed below:
A detailed sequential acceptance test plan was developed by the evaluation team. The details of the acceptance test plan are documented in reference [3]. The focus of the acceptance test plan is to evaluate the voice routing functionality of the TSPECRS system, which automatically routes a TSP initiated emergency call as a native 9-1-1 call to the appropriate PSAP, and includes the sending of location information, call back number and so on. The first phase of the acceptance test plan requires 147 test calls to be evenly placed to the 22 selected PSAPs. If a sufficiently small number of call failures (one or less) are observed, the test is considered a success, and the FOT is complete. If two-to-four call failures are observed, the test results are inconclusive and an additional set of calls must be completed to validate the success or failure of the Mayday/9-1-1 FOT. The test plan allowed for up to two retest efforts if the results are inconclusive. If five or more Mayday/9-1-1 FOT call failures occur, then the FOT fails the Mayday/9-1-1 FOT validation test.
Although not the focus of the evaluation team, the automatic transport of the vehicle crash data (AACN) to the IES PSAPs was available for demonstration and evaluation. Also, at the end of the FOT evaluation, available operations and qualitative feedback from selected users and stakeholders was collected and analyzed. A final evaluation report is to be provided by Battelle’s team.
The acceptance test plan documented the characteristics of a successful Mayday/9-1-1 FOT test call. However, there were certain conditions that were outside the control of the project team that could cause a test call to fail. For example, the T-1 transmission facility may fail and not allow the call to be completed. If a test call failed due to any condition that was outside the control of the project team, that test call would be repeated when the condition cleared or was corrected.
4.3 Selected PSAPsThe selected PSAPs are listed in section 3.9.
The Minnesota Department of Transportation, with the agreement of the evaluation team, selected test call sites in each of the geographic regions supported by the 22 selected PSAPs. Coordinating with the evaluation team, a data collection form was created to record the results of each test call. The testing procedure required that the test initiator drive to a selected location; deploy the Vehicle Test Unit’s GPS antenna and wait two minutes to assure GPS and satellite reception; select the test scenario on the unit; and place a call. The call (and data) would reach the OnStar Call Center Lab; a discussion would take place with the OnStar Emergency Advisor; the call (and data) would be forwarded to the Telcordia T-MSC; and subsequently routed to the appropriate PSAP, based on the received location (Latitude and Longitude) of the vehicle. A discussion would take place between the test initiator and the PSAP attendant to ensure that the proper PSAP was reached, the proper Lat/Long was received, and the appropriate “Call Back Number” was received. The results of the conversation were recorded on the data collection form by the test initiator. The forms were aggregated on a daily basis, and then forwarded electronically to the evaluation team.
As a part of the test call process, the XML data sent from OnStar to the Telcordia Lab was saved in a date and time stamped file. These files were also forwarded to the evaluation team daily. All the above data sent to the evaluators was used to confirm the success (or failure) of the test calls.
In addition to the above, Telcordia also had real-time data available during the testing sequence, showing the full Mayday/9-1-1 messages and data, as the test call progressed through the wireless logical prototype elements in the Lab and flowed to the Minnesota 9-1-1 networks.
Section 4.4.1 shows an example of the form used by the test initiator to record data for each test call during the testing. Subsections 4.4.2 and 4.4.3 show some of the data that was collected at the Telcordia lab. Section 4.4.4 shows an example of the screens viewed at a PSAP. The sample form, XML and NSTS data (4.4.1, 4.4.2, 4.4.3, and Appendix D) are all from the sample test call.
The following figure shows an example data collection form filled out by the test initiator for each FOT test call.
Figure 4-1 Data Collection Form
The following is a textual representation of the XML data processed on a single call during the FOT:
<vei:VehicularEmergencyIncident>
<aacnDataType>
<deltaV>17.0</deltaV>
<pdof>-94.0</pdof>
<multImp>true</multImp>
<rollOv>false</rollOv>
</aacnDataType>
<airbagType>
<drDep>
<sideDep>false</sideDep>
<frtDepType>
<nearDep>true</nearDep>
<stage1>false</stage1>
<stage2>false</stage2>
<unknownDeployed>false</unknownDeployed>
</frtDepType>
</drDep>
<passDep>
<sideDep>false</sideDep>
<frtDepType>
<nearDep>true</nearDep>
<stage1>false</stage1>
<stage2>false</stage2>
<unknownDeployed>false</unknownDeployed>
</frtDepType>
</passDep>
</airbagType>
<incidentTimeStamp>2005-08-19T16:40:03<IncidentTimeStamp>
<locationType>
<latitude>44.90940856933594</Latitude>
<longitude>-92.96788024902344</Longitude>
</locationType>
<providerDataType>
<callBackNumber>A8668593363</callBackNumber>
</providerDataType>
<Cid>2667</Cid>
<vehicleDataType>
<esn>05100158198</esn>
<mdn>2483218198</mdn>
<min>2483212091</min>
<sid>14165198</sid>
<vin>MNDOTGEN6000001</vin>
</vehicleDataType>
</vei:VehicularEmergencyIncident>
The following is an example of the data collected by the Telcordia Network Services Test System (NSTS), which simulated the signaling and control for the T-MSC, S-MSCs, HLR and MPC. The data in the example shows the contents of the signaling messages, with a minimal amount of detail. Appendix D shows two of these messages in full detail. The messages are traveling between the elements in the network that are simulated by NSTS. Each message that goes between elements simulated by the NSTS appears twice (once going to the STP and once from the STP). Messages between a simulated node and an actual node only appear once (going to the STP). In brief, the way to read the data is as follows:
The first field indicates the node that is generating or receiving the message.
The second field indicates direction (C=receive, T=transmit)
The third field indicates the time of day for the message.
The fourth field indicates the type of message (TCAP message: QRYP – Query with permission or RESP – Response; ISUP message: IAM – Initial Address Message, ACM – Address Complete Message, ANM – Answer Message, SUS – Suspend Message, REL – Release Message, RLC – Release Complete Message).
The fifth field indicates the SS7 Destination Point Code
The Sixth field indicates the SS7 Originating Point Code
The remaining fields are message dependent and add little to this discussion. The data that was collected had full message content for all messages, with more detailed coding available if required for analysis.
TMS C 16:41:32.141 QRYP TMSC 5ESS 1sls021 ssn247 02a903a1
TMS T 16:41:32.143 QRYP HLR TMSC 1sls007 ssn011 02a903a1
HLR C 16:41:32.187 QRYP HLR TMSC 1sls019 ssn011 02a903a1
HLR T 16:41:32.189 QRYP MSC2 HLR 1sls007 ssn012 a103a902
MSC C 16:41:32.261 QRYP MSC2 HLR 1sls019 ssn012 a103a902
MSC T 16:41:32.264 RESP HLR MSC2 1sls007 ssn013 a103a902
HLR C 16:41:32.319 RESP HLR MSC2 1sls019 ssn013 a103a902
HLR T 16:41:32.322 RESP TMSC HLR 1sls007 ssn012 02a903a1
TMS C 16:41:32.358 RESP TMSC HLR 1sls019 ssn012 02a903a1
TMS T 16:41:32.361 RESP 5ESS TMSC 1sls007 ssn247 02a903a1
MSC C 16:41:32.691 IAM MSC2 5ESS 1sls147 1 612-225-2222
MSC T 16:41:32.693 IAM 5ESS MSC2 1sls147 24 908-999-2222
MSC C 16:41:32.882 QRYP MSC2 5ESS 1sls029 ssn247 018803a5
MSC T 16:41:32.885 QRYP MPC MSC2 1sls007 ssn013 018803a5
MPC C 16:41:32.925 QRYP MPC MSC2 1sls019 ssn013 018803a5
MPC T 16:41:32.928 QRYP MSC2 MPC 1sls007 ssn014 a5038801
MSC C 16:41:32.955 QRYP MSC2 MPC 1sls019 ssn014 a5038801
MSC T 16:41:32.957 RESP MPC MSC2 1sls007 ssn013 a5038801
MPC C 16:41:32.992 RESP MPC MSC2 1sls019 ssn013 a5038801
MPC T 16:41:32.995 RESP MSC2 MPC 1sls007 ssn014 018803a5
MSC C 16:41:33.026 RESP MSC2 MPC 1sls019 ssn014 018803a5
MSC T 16:41:33.028 RESP 5ESS MSC2 1sls007 ssn247 018803a5
MSC C 16:41:33.644 ACM MSC2 5ESS 1sls147 24
MSC T 16:41:33.646 ACM 5ESS MSC2 1sls147 1
MSC C 16:41:33.874 ANM MSC2 5ESS 2sls147 24
MSC T 16:41:33.876 ANM 5ESS MSC2 2sls147 1
MSC C 16:42:41.439 SUS MSC2 5ESS 1sls147 24
MSC T 16:42:41.442 SUS 5ESS MSC2 1sls147 1
MSC C 16:42:51.670 REL MSC2 5ESS 1sls147 1
MSC T 16:42:51.671 REL 5ESS MSC2 1sls147 24
MSC C 16:42:51.799 RLC MSC2 5ESS 2sls147 24
MSC T 16:42:51.802 RLC 5ESS MSC2 2sls147 1
A sample view of the screen seen at the IES Test PSAP is shown in the next two figures. There are two figures because the screen is divided between two monitors and in order to fit the view in the document, it is shown as separate figures.
Figure 4-2 PSAP Screen (1 of 3)
Figure 4-3 PSAP Screen View (2 of 3)
Figure 4-4 PSAP Screen (3 of 3) IES Special Application
The first phase of the Mayday/9-1-1 FOT testing started on August 10, 2005 and ended on August 19, 2005. Since all test calls were successful, a second phase of test calling was not necessary. There were a few conditions that were beyond the control of the project team that required some test calls to be redone.
[1] Telematics Service Provider Emergency Call Routing Service (TSPECRS) Concept of Operations, Telcordia Technologies, SAIC, July 8, 2004 .
[2] Telematics Service Provider Emergency Call Routing Service (TSPECRS) System Specification, Telcordia Technologies, SAIC and OnStar, November 14, 2003.
[3] Detailed Test Plan – Mayday/9-1-1 Field Operation Test Independent Testing of Voice Routing Functions, Battelle, August 4, 2005 .
[4] Final Report: Mayday/9-1-1 Field Operational Test (FOT) Results and Path Forward, Telcordia Technologies, SAIC, and MNDOT, March 2006.
[5] Final Report: Mayday/9-1-1 Field Operations Test Analysis, Battelle, Date TBD.
[6] NENA Recommendation 05-XX, NENA Standard for the Implementation of the Wireless Emergency Service Protocol E2 Interface via TCP/IP, October 2002.
[7] IES – Dynamic ALI Interface Specification, Document Number: IES0120, Revision E, October 25, 2002.
[8] NENA Recommendation 02-10, Recommended Formats & Protocols For ALI Data Exchange, ALI Response & GIS Mapping, January 2002.
[9] Qwest Detailed SR/ALI to MPC/GMLC Interface Specifications for TCP/IP Implementation of TIA/EIA/J-STD-036E2, Issue 1.11, April 2004.
[10] Mayday/9-1-1 Field Operational Test Data Routing Concept of Operations Report, Minnesota Department of Transportation, June 1, 2004
[11 ]Mayday/9-1-1 Field Operational Test Data Routing Project Final Report, Minnesota Department of Transportation, TBD
Appendix A - Acronyms
Appendix B – XML Schema for TCC to T-MSC/NEDR Interface
The TCC to NEDR interface shall use XML schema for delivery of ACN information. XML interface via HTTPS Simple Object Access Protocol (SOAP) invocation shall be used for Mayday/9-1-1 FOT demonstration and evaluation.
Airbags Deployed consists of the following boolean (true or false) parameters: Driver Side Airbag Deployed, Driver Front Airbag Near Deployed, Driver Front Airbag Stage1, Driver Front Airbag Stage2, Driver Front Airbag Unknown Deployed, Passenger Side Airbag Deployed, Passenger Front Airbag Near Deployed, Passenger Front Airbag Stage1, Passenger Front Airbag Stage2, Passenger Front Airbag Unknown Deployed
The following is the XML Schema that was used for the XML interface between the OnStar Lab and the Telcordia Lab.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://axisws" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://axisws" xmlns:intf="http://axisws" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns2="http://CallManager.asd.onstar.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:types>
<schema targetNamespace="http://CallManager.asd.onstar.com" xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<simpleType name="DeviceEventType">
<restriction base="xsd:string">
<enumeration value="ACN"/>
<enumeration value="AACN"/>
<enumeration value="E-KEY"/>
</restriction>
</simpleType>
<complexType name="AACNDataType">
<sequence>
<element name="deltaV" type="xsd:float"/>
<element name="deviceEventType" nillable="true" type="tns2:DeviceEventType"/>
<element name="multipleImpacts" type="xsd:boolean"/>
<element name="pdof" type="xsd:float"/>
<element name="preCrashHeading" type="xsd:float"/>
<element name="rollOver" type="xsd:boolean"/>
</sequence>
</complexType>
<complexType name="AirbagDeployedType">
<sequence>
<element name="nearDeployed" type="xsd:boolean"/>
<element name="stage1" type="xsd:boolean"/>
<element name="stage2" type="xsd:boolean"/>
<element name="unknownDeployed" type="xsd:boolean"/>
</sequence>
</complexType>
<complexType name="AirbagLocationType">
<sequence>
<element name="frontDeployedType" nillable="true" type="tns2:AirbagDeployedType"/>
<element name="sideDeployed" type="xsd:boolean"/>
</sequence>
</complexType>
<complexType name="AirbagType">
<sequence>
<element name="driverDeployed" nillable="true" type="tns2:AirbagLocationType"/>
<element name="passsengerDeployed" nillable="true" type="tns2:AirbagLocationType"/>
<element name="rearImpact" type="xsd:boolean"/>
<element name="unknownDeployed" type="xsd:boolean"/>
<element name="unknownNearDeployed" type="xsd:boolean"/>
</sequence>
</complexType>
<complexType name="LocationType">
<sequence>
<element name="latitude" type="xsd:float"/>
<element name="longitude" type="xsd:float"/>
</sequence>
</complexType>
<simpleType name="DatumType">
<restriction base="xsd:string">
<enumeration value="WGS84"/>
<enumeration value="NAD83"/>
</restriction>
</simpleType>
<simpleType name="ProviderDataSourceType">
<restriction base="xsd:string">
<enumeration value="CVO"/>
<enumeration value="PSA"/>
<enumeration value="PSAP"/>
<enumeration value="RAP"/>
<enumeration value="TSP"/>
</restriction>
</simpleType>
<complexType name="ProviderDataType">
<sequence>
<element name="callBackNumber" nillable="true" type="xsd:string"/>
<element name="datum" nillable="true" type="tns2:DatumType"/>
<element name="eventVerified" type="xsd:boolean"/>
<element name="incidentOriginator" type="xsd:boolean"/>
<element name="providerDataSource" nillable="true" type="tns2:ProviderDataSourceType"/>
<element name="providerName" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
<complexType name="VehicleDataType">
<sequence>
<element name="esn" nillable="true" type="xsd:string"/>
<element name="mdn" nillable="true" type="xsd:string"/>
<element name="min" nillable="true" type="xsd:string"/>
<element name="sid" nillable="true" type="xsd:string"/>
<element name="vin" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
<complexType name="EmergencyIncidentType">
<sequence>
<element name="aacnDataType" nillable="true" type="tns2:AACNDataType"/>
<element name="airbagType" nillable="true" type="tns2:AirbagType"/>
<element name="incidentTimeStamp" nillable="true" type="xsd:dateTime"/>
<element name="locationType" nillable="true" type="tns2:LocationType"/>
<element name="providerDataType" nillable="true" type="tns2:ProviderDataType"/>
<element name="tccCaseid" nillable="true" type="xsd:string"/>
<element name="vehicleDataType" nillable="true" type="tns2:VehicleDataType"/>
</sequence>
</complexType>
</schema>
</wsdl:types>
<wsdl:message name="getTLDNRequest">
<wsdl:part name="in0" type="tns2:EmergencyIncidentType"/>
</wsdl:message>
<wsdl:message name="getTLDNResponse">
<wsdl:part name="getTLDNReturn" type="xsd:string"/>
</wsdl:message>
<wsdl:portType name=" Enterprise">
<wsdl:operation name="getTLDN" parameterOrder="in0">
<wsdl:input message="impl:getTLDNRequest" name="getTLDNRequest"/>
<wsdl:output message="impl:getTLDNResponse" name="getTLDNResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="EnterpriseSoapBinding" type="impl: Enterprise">
<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="getTLDN">
<wsdlsoap:operation soapAction=""/>
<wsdl:input name="getTLDNRequest">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://axisws" use="encoded"/>
</wsdl:input>
<wsdl:output name="getTLDNResponse">
<wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://axisws" use="encoded"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="EnterpriseService">
<wsdl:port binding="impl:EnterpriseSoapBinding" name=" Enterprise">
<wsdlsoap:address location="http://localhost:8080/WebModule/services/Enterprise"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Appendix C – Model Call Center & Operations Environment
Figure C-5-1 illustrates the high level functional block diagram of a model call center.
Figure C-5-1 Model Call Center - Functional Block Diagram
A Telematics Service Provider typically provides real-time help 24 hours a day, 365 days a year. The following subsections provide details about the various components in a typical TCC.
Infrastructure & Networking
A TCC has interfaces to the PSTN network via an End Office (EO), as well as, the ability to contact or be contacted by a TMS over a voice and/or data connection. A TCC also has interfaces to the PSAP administrative line, as well as other outbound and inbound voice call connectivity over the PSTN and data connectivity over the IP network.
Telephony
Automatic Call Distribution (ACD)
The TCC has an ACD to distribute TSPECRS requests to available Call Center personnel based on call type and other criteria. Emergency calls are given highest priority and are typically handled by a specially trained team of emergency advisors. For the purposes of the FOT, a special events team of Call Center personnel serviced the test calls.
Interactive Voice Response (IVR)
For the purposes of the FOT, incoming TSPECRS call requests might be routed to an IVR, while the call termination to the PSAP is in progress. The IVR provides the requisite announcements to the Telematics subscriber.
Outbound Dialer
The TCC may have an outbound dialer to facilitate accessing PSAPs directly over administrative lines and for attempting to reach the Telematics subscriber if the inbound emergency call is disconnected or if the FOT requires it.
Customer Relationship Management (CRM)
The TCC CRM production implementation consisted of various service applications and databases for providing assistance to the Telematics subscribers. Some of the services may include : automatic notification of air bag deployment, stolen vehicle location, remote door unlock, emergency services dispatch, roadside assistance, remote diagnostics, route support, convenience services and concierge.
These applications define the workflows and provide the GUI interfaces to the Call Center personnel, and may also provide web and email interfaces.
The applications utilized for the FOT are distinct from the production applications by design, so as not to jeopardize the integrity of live emergency call handling for Telematics subscribers. The live OnStar TCC was linked with the lab TCC, which provided the new XML data interface and call routing to the T-MSC at the Telcordia lab facility. In addition, the specially trained OnStar call taker was provided with visual prompts to support the dialogue during the FOT calls.
Support
The Support function consists of Network Management, administration and monitoring of real-time performance of the Call Center operations. The monitoring may include the generation of periodic measurement reports.
Appendix D – Detailed System Call Messages
The following is a sample of three of the ANSI-41 coded TCAP messages used in the signaling for the FOT, as seen at the NSTS.
********** 16:41:32.143 D Packet (# 35853), DTE Node 3 Link 0 **********
Raw Data (hex):
8c 8c 3f 93 02 e0 e5 01 e0 e5 07 09 80 03 05 07 02 c1 0c 02 c1
0b 59 e2 57 c7 04 02 a9 03 a1 e8 4f e9 4d cf 01 01 d1 02 09 0f
30 44 81 07 00 15 04 00 00 01 01 84 09 01 00 01 0a 42 38 12 02
19 95 03 00 15 04 96 01 03 9f 50 09 02 30 21 0a 00 00 00 00 00
9f 81 2a 01 01 e1 15 c0 06 05 08 13 61 04 30 c1 08 00 00 3f df
04 bd e3 b7 c2 01 11
MSU - Length Indicator: 63, Priority: 1
Service Indicator: SCCP message (0x03)
Subservice Field: National network (0x02)
SCCP message (0x03)
DPC: 229 224 2
OPC: 229 224 1
SLS: 7
UDT unitdata (0x09)
Protocol Class: 0 (0x00)
Message handling: Return message on error (0x08)
Called Party Address:
Route on destination point code (0x01)
National address indicator coding (0x01)
Subsystem Number: IS41
(12) (0x0c)
GT indicator: No global title included (0x00)
Calling Party Address:
Route on destination point code (0x01)
National address indicator coding (0x01)
Subsystem Number: IS41
(11) (0x0b)
GT indicator: No global title included (0x00)
Data Field Length: 89 (0x59)
TCAP Package Type: Query With Permission (0xe2)
Class: Private Use: Usage in National TCAP/Private TCAP (0x03)
TCAP Message length: 87 (0x57)
Transaction ID: (0xc7)
Origination ID: 2 169 3 161 (0x02a903a1)
Component Sequence, ID Length = 79
Invoke Component (Last), ID Length = 77
Invoke ID: (0x01)
Private TCAP Operation Code, Length = 2
Reply Not Required (0x00)
IS-41 MAP Location Request
Parameter Sequence, ID Length = 68
Billing ID:
Anchor SID: 0051
Anchor switch number: 40
ID number: 000010
Segment counter:
Number of intersystem handoffs: 1
Digits:
Type of Digits: Dialed (Called Party Number) (0x01)
Nature of Number: National - No Presentation Restriction (0x00)
Numbering Plan: Unknown or Not Applicable, Numbering Plan (0x00)
Encoding: BCD (0x01)
Digits: 248-321-2091
MSC ID:
SID : 21 (0x00 0x15 )
SWNO: 4 (0x04)
System My Type Code:
AT&T (0x03)
Calling Party Digits 1: (Ext. Decode)
Type: ANI (Calling Party Number) (0x02)
Nature of Number: National - No Presentation Restriction (0x00)
Numbering Plan: Telephony Numbering (0x02)
Encoding: BCD (0x01)
Routing Digits: 000-000-0000
Emergency Call Type: (Ext. Decode)
Length: 1
TSPECRS (0x01)
Position Information: (Ext. Decode)
Length: 21
Generalized Time (0xc0)
Length: 6
Date: 8-19-2005
Time: 16:40:03
Geographic Position (0xc1)
Length: 8
LPRI/Screening 00
Type of Shape 00
Encoded Lat = 0x3fdf04
Encoded Long = 0xbde3b7
Position Source (0xc2)
Length: 1
Handset GPS (0x11)
********** 16:41:32.189 D Packet (# 35860), DTE Node 3 Link 2 **********
Raw Data (hex):
8c 8c 33 93 05 e0 e5 02 e0 e5 07 09 80 03 05 07 02 c1 0d 02 c1
0c 4e e2 4c c7 04 a1 03 a9 02 e8 44 e9 42 cf 01 01 d1 02 09 10
30 39 81 07 00 15 04 00 00 01 01 89 03 05 10 01 88 05 42 38 12
02 19 95 03 00 15 04 96 01 03 9f 81 2a 01 01 e1 15 c0 06 05 08
13 61 04 30 c1 08 00 00 3f df 04 bd e3 b7 c2 01 11
MSU - Length Indicator: 51, Priority: 1
Service Indicator: SCCP message (0x03)
Subservice Field: National network (0x02)
SCCP message (0x03)
DPC: 229 224 5
OPC: 229 224 2
SLS: 7
UDT unitdata (0x09)
Protocol Class: 0 (0x00)
Message handling: Return message on error (0x08)
Called Party Address:
Route on destination point code (0x01)
National address indicator coding (0x01)
Subsystem Number: IS41
(13) (0x0d)
GT indicator: No global title included (0x00)
Calling Party Address:
Route on destination point code (0x01)
National address indicator coding (0x01)
Subsystem Number: IS41
(12) (0x0c)
GT indicator: No global title included (0x00)
Data Field Length: 78 (0x4e)
TCAP Package Type: Query With Permission (0xe2)
Class: Private Use: Usage in National TCAP/Private TCAP (0x03)
TCAP Message length: 76 (0x4c)
Transaction ID: (0xc7)
Origination ID: 161 3 169 2 (0xa103a902)
Component Sequence, ID Length = 68
Invoke Component (Last), ID Length = 66
Invoke ID: (0x01)
Private TCAP Operation Code, Length = 2
Reply Not Required (0x00)
IS-41 MAP Routing Request
Parameter Sequence, ID Length = 57
Billing ID:
Anchor SID: 0051
Anchor switch number: 40
ID number: 000010
Segment counter:
Number of intersystem handoffs: 1
Mobile Serial Number: 84935048 (0x05 0x10 0x01 0x88 )
Mobile Identification Number: (MIN) 2483212091
MSC ID:
SID : 21 (0x00 0x15 )
SWNO: 4 (0x04)
System My Type Code:
AT&T (0x03)
Emergency Call Type: (Ext. Decode)
Length: 1
TSPECRS (0x01)
Position Information: (Ext. Decode)
Length: 21
Generalized Time (0xc0)
Length: 6
Date: 8-19-2005
Time: 16:40:03
Geographic Position (0xc1)
Length: 8
LPRI/Screening 00
Type of Shape 00
Encoded Lat = 0x3fdf04
Encoded Long = 0xbde3b7
Position Source (0xc2)
Length: 1
Handset GPS (0x11)
********** 16:41:32.264 D Packet (# 35869), DTE Node 3 Link 4 **********
Raw Data (hex):
aa a4 3a 93 02 e0 e5 05 e0 e5 07 09 80 03 05 07 02 c1 0c 02 c1
0d 26 e4 24 c7 04 a1 03 a9 02 e8 1c e9 1a cf 01 01 d1 02 09 10
30 11 95 03 00 1a 02 9f 57 09 09 09 09 0a 16 22 52 22 22
MSU - Length Indicator: 58, Priority: 1
Service Indicator: SCCP message (0x03)
Subservice Field: National network (0x02)
SCCP message (0x03)
DPC: 229 224 2
OPC: 229 224 5
SLS: 7
UDT unitdata (0x09)
Protocol Class: 0 (0x00)
Message handling: Return message on error (0x08)
Called Party Address:
Route on destination point code (0x01)
National address indicator coding (0x01)
Subsystem Number: IS41
(12) (0x0c)
GT indicator: No global title included (0x00)
Calling Party Address:
Route on destination point code (0x01)
National address indicator coding (0x01)
Subsystem Number: IS41
(13) (0x0d)
GT indicator: No global title included (0x00)
Data Field Length: 38 (0x26)
TCAP Package Type: Response (0xe4)
Class: Private Use: Usage in National TCAP/Private TCAP (0x03)
TCAP Message length: 36 (0x24)
Transaction ID: (0xc7)
Responding ID: 161 3 169 2 (0xa103a902)
Component Sequence, ID Length = 28
Invoke Component (Last), ID Length = 26
Invoke ID: (0x01)
Private TCAP Operation Code, Length = 2
Reply Not Required (0x00)
IS-41 MAP Routing Request
Parameter Sequence, ID Length = 17
MSC ID:
SID : 26 (0x00 0x1a )
SWNO: 2 (0x02)
Destination Digits: (Ext. Decode)
Type: Last Calling Party (0x09)
Nature of Number: International - No Presentation Restriction (0x01)
Numbering Plan: Unknown/Not Applicable (0x00)
Encoding: BCD (0x01)
Routing Digits: 612-225-2222
Footnote: