BellSouth E911 User Manual

Download

Page 1

Wireless E911 Guide

Customer Guide

CG-EWCG-001

Issue 3, January 6, 2004

Page 2

Wireless E911 Guide CG-EWCG-001 Copyright Issue 3, January 6, 2004

April, 2002 - January 6, 2004

Page ii

Page 3

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Table of Contents

Contents

Subject Page

Introduction / Revision History . . . . . . . . ............................. vii

Purpose ...................................................... vii

Version Information ..............................................

1. Overview of E911 . . . . ....................................... 1

1.1 Definition of E911 .............................................

1.1.1 Selective Routing ...........................................

1.1.2 Automatic Number Identification (ANI) .............................

1.1.3 Automatic Location Identification (ALI) ............................

1.1.4 Premises Based ALI Systems ....................................

1.2 PSAP Display ................................................

1.3 Databases Required to Support E911 .................................

1.4 Master Street Address Guide (MSAG) ................................ 3

1.5 Telephone Number (TN) Database .................................. 3

1.6 E911 Tandem / Network Information ................................. 4

1.7 Glossary of Terms .............................................

1.8 Database Escalation Procedures .................................... 8

1.8.1 Access To NDSC Analysts ..................................... 8

1.8.2 Level One Escalation: Intrado ................................... 8

1.8.3 Level Two Escalation: Intrado ................................... 8

1.8.4 Level Three Escalation: Bellsouth ................................. 8

2. Coordination of Wireless Interconnection . . . . . . . ................... 9

2.1 Overview ...................................................

2.2 Coordination Process: Wireless Carrier ............................... 9

2.3 Coordination Process: BST Wireless Account Team ....................... 10

2.4 Coordination Process: BST Wireless E911 Implementation Manager ............ 10

2.5 Coordination Process: Mobile Position Center Provider ..................... 11

2.5.1 Steps for Establishment/Change of Mobile Position Center Provider ........... 11

2.5.2 Initial Establishment of Mobile Position Center Provider .................. 12

2.5.3 Change of Mobile Position Center Provider ........................... 12

2.5.4 Information Required for Phase 2 MPC/GMLC Circuits to the ALI Hosts ....... 12

2.5.5 Forms ................................................... 13

3. Network Specifications and Ordering ............................. 15

3.1 Overview ................................................... 15

3.2 Specifications & Ordering Process: .................................. 15

3.2.1 Option 1: BellSouth NORTEL Solution Carring Phase 1 Data Only (CBN & pANI) 15

3.2.2 Specification & Ordering Process: Option 2: Third Party Vendor Solution ....... 16

3.3 Wireless Carrier Owned Hardware .................................. 16

3.3.1 Trunking ................................................. 16

3.3.2 Data Connections Required For Wireless Carrier Owned Hardware - Phase 1 Only . 17

3.4 Wireless Phase 2 .............................................. 17

vii

1 1 1 1 2 2 3

Page iii

Page 4

Wireless E911 Guide CG-EWCG-001 Table of Contents Issue 3, January 6, 2004

3.5 Interface Testing .............................................. 18

4. MSAG Maintenance and ESN Assignment . . . . . . . ................... 19

4.1 Overview ...................................................

4.2 ESN Assignments .............................................

4.3 MSAG Maintenance and Validation ..................................

19 19 20

5. TN Database Updates . ....................................... 23

5.1 Overview ...................................................

5.2 TN Database Daily Updates: Wireless Carrier Responsibilities ................ 24

5.3 E911 Customer Responsibilities ....................................

5.4 Instructions for NXX Table Update Form ..............................

5.5 NXX Table Update Form . . ......................................

5.6 MSAG Formatting .............................................

5.6.1 Correct Format .............................................

5.6.2 Incorrect Format ............................................

26 27 29 30 30 30

5.7 Standard Street Suffix (Thoroughfare) Designations / Directionals .............. 31

5.7.1 BellSouth Street Suffix (Thoroughfare) Abbreviations (Table) ............... 31

5.8 Standard Location Designations .................................... 32

5.9 Updating the TN Database . . ......................................

5.10 Service Order Interface File Specifications ............................. 34

5.11 SOIR File Data Record Layout ..................................... 34

5.11.1 Table: SOIR File Data Record - BellSouth 512 Character Format for Data Exchange 34

5.12 SOIR File Header Record Layout ................................... 40

5.12.1 Table: SOIR File Header Record - BellSouth 512 Character Format for Data

Exchange ................................................

5.13 SOIR File Trailer Record Layout ................................... 40

5.13.1 SOIR File Trailer Record - BellSouth 512 Character Format for Data Exchange . . . 40

5.14 Mechanized File Transfer . . ...................................... 41

5.15 Mechanized File Confirmations .................................... 41

6. TN Errors and Corrective Action . . . . ............................. 43

6.1 Overview ...................................................

6.2 Electronic Error Delivery . . ......................................

43 43

6.2.1 The Confirmation Report ...................................... 43

6.2.2 The Statistics Report . . . ......................................

6.2.3 Distribution of Daily Reports .................................... 47

6.2.4 TN Error Deletion ........................................... 48

6.3 Error Codes and Error Descriptions .................................. 48

6.4 Error Code and Corrective Action ................................... 50

6.5 Compiled Error Report .......................................... 58

7. PSAP Inquiries . . . . . . ....................................... 59

7.1 Overview ................................................... 59

7.2 PSAP Inquiry Form ............................................ 60

7.3 PSAP Inquiry Log ............................................. 61

7.3.1 Instructions for Completing PSAP Inquiry Log ........................ 61

7.4 Inquiry Flow ................................................ 62

7.5 Investigation Procedures . . . ...................................... 62

Page iv

Page 5

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Table of Contents

7.5.1 ALI Record Not Found . . ...................................... 62

7.5.2 Wrong ALI Display Of: . ......................................

7.5.3 Address — Community — Location ...............................

7.5.4 ESN ....................................................

7.5.5 Misroutes ................................................

7.6 Blank Forms .................................................

7.6.1 PSAP Inquiry Log ...........................................

62 62 63 63 63 64

8. No Record Found (NRF) Processing . ............................. 65

8.1 Overview ...................................................

8.2 No Record Found (NRF) Processing .................................

8.3 No Record Found (NRF) Report Schedule .............................

8.4 No Record Found (NRF) Report Layout ...............................

8.5 NRF Investigation .............................................

65 65 65 66 66

9. NENA Company Registration Process . . . . . . . . . ................... 69

9.1 NENA Cmpany ID Registration Service ...............................

9.2 Purpose of the NENA Company ID Registration Service .................... 69

9.3 Use of the Service .............................................

9.4 Instructions .................................................

9.4.1 Input Form ................................................

70 70 70

10. Reconciliation . . . . . . . ....................................... 73

10.1 Overview ...................................................

10.2 Notification and Scheduling . ......................................

10.3 .........................................................

73 73 73

Appendix A. BellSouth Wireless E9–1–1/SS7 Interconnection Guide . . . . . . . . 75

A.1 BellSouth Wireless E-9–1–1/SS7 Interconnection Guide .................... 75

A.2 Executive Summary ............................................

A.2.1 Identified Options: ...........................................

75 76

A.2.1.1 Call Scenario 1, ESRK Delivery .................................. 76

A.2.1.2 Call Scenario 2, CBN and ESRD Delivery - WITHOUT a hybrid: (WITHOUT a

hybrid architecture at the Selective Router) ........................... 77

A.2.1.3 Call Scenario 2, CBN and ESRD Delivery - WITH a hybrid: (WITH a hybrid

architecture at the Selective Router) ................................ 77

A.2.1.4 Call Scenario 3, CBN, ESRD and GLP Delivery: (GLP = Geodetic Location

Parameter) ................................................

A.2.2 Database Steering Options ...................................... 78

A.3 Scope and introductory text . ...................................... 78

A.3.1 Wireless E9-1-1 Service Introduction ............................... 78

A.4 Reason for Revision ............................................ 79

A.5 Organization of this Document ..................................... 79

A.6 Wireless CCS Network Interconnection Architecture ....................... 81

A.6.1 General Interconnection Information ............................... 81

A.6.2 Wireless Phase 1 vs. Phase 2 .................................... 81

A.7 Interface Protocol for Wireless Call Setup when using SS7/ISUP signaling. ....... 83

A.7.1 Calling Party Number . . ...................................... 83

A.7.2 Calling Party Number Parameter .................................. 84

Page v

Page 6

Wireless E911 Guide CG-EWCG-001 Table of Contents Issue 3, January 6, 2004

A.7.3 Generic Digits Parameter & GDP Type ............................. 84

A.7.4 Charge Number Parameter .....................................

A.7.5 Calling Party Category Parameter (CPC, aka: CPCat) ....................

A.7.6 Originating Line Information Parameter .............................

A.8 Cross Reference Tables to J-STD-036-A ...............................

85 85 85 86

A.8.1 Wireline Compatibility Mode (NDET uses signaling option E911_STD) ........ 86

A.8.2 ISUP Initial Address Message Parameter Contents for NCAS (NDET uses signaling

option WRLS_STD, because MSC c

an support GDP) ....................

A.8.3 ISUP Initial Address Message Parameter Contents for NCAS (NDET uses signaling

annot

option WRLS_CLD because MSC c

support GDP) .................. 88

A.8.4 ISUP Initial Address Message Parameter Contents for CAS ................ 90

A.9 Cross Reference Tables to NENA TID 05-501 - SS7 Guidelines for MSC to Selective

Router Connectivity. ...........................................

A.9.1 Call Scenario 1: ESRK Delivery ..................................

A.9.2 8.2 Call Scenario 2: CBN and ESRD Delivery .........................

A.10 Attachment "A" - CPCat & OLI Notes ................................

91 92 92 94

A.10.1 Calling Party Category parameter (CPC): ............................ 94

A.10.2 Originating Line Parameter (OLI): ................................ 94

A.11 Attachment "B" - Wireless Customer Questions & Answers: .................. 95

A.11.1 Why is BellSouth issuing this document? ............................ 95

A.11.2 Do I have to change my existing trunks to SS7? ........................ 95

A.11.3 Will this let me deliver ESRDs/ESRKs from more than one NPA on the SS7 trunk

group? ..................................................

A.11.4 Will this let me reduce the number of trunk groups I have in place? ........... 95

A.11.5 What if I don’t have SS7 signaling "A" link connectivity to support trunking to the

appropriate NDET? ..........................................

A.11.6 What do I do for Continuity Testing on these SS7 trunks? ................. 96

A.12 11.0 Attachment "C" - Wireless Customer Checklist ....................... 96

Page vi

Page 7

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Introduction / Revision History

Introduction / Revision History

Purpose

This document addresses Wireless E911.

Version Information

Added SS7/ISUP signaling option for trunking between the MSC and E911 tandems. Added Appendix A.

Page vii

Page 8

Wireless E911 Guide CG-EWCG-001

Introduction / Revision History Issue 3, January 6, 2004

Requested By /

Made By

Tom Breen / Bill

Marczak / Mike

Harfield

Rosemary Parker /

Mike Harfield

Genia Harris /

Mike Harfield

Rosemary Parker /

Mike Harfield

Table A Revision History

Date / Issue Description Change

Chapter Action

Request

Added SS7/ISUP signaling

option for trunking between

the MSC and E911 tandems.

All N/A January 6, 2004 /

Added Appendix A.

Record Layout Table to

N/A May 22, 2003 / 2b Revised SOIR File Data

MSAG Maintenance

and ESN Assignment

show "Sent to PSAP" field

footnotes in table column.

"GMLC" Term, Changed

contact for "Level One

Escalation: Intrado".

N/A April 3, 2003 / 2a Overview of E911: Added

Overview of E911;

Coordination

of Wireless

Interconnection;

Coordination of Wireless

Interconnection: Added

"Coordination Process:

Network

Specifications and

Ordering

Mobile Position Center

Provider"

Network Specifications and

Ordering: Added "Wireless

Phase 2".

Corrected FAX numbers. Rosemary Parker /

Added step in TN Database

Daily Updates: Wireless

Carrier Responsibilities and

changed address in Inquiry

Flow for INTRADO.

- continued -

/1c

N/A December 2, 2002

TN Database Updates N/A January 8, 2003 /

TN Database Updates

and PSAP Inquiries

Page 8

Page 9

CG-EWCG-001 Wireless E911 Guide

Issue 3, January 6, 2004 Introduction / Revision History

Requested By /

Made By

Rosemary Parker /

Mike Harfield

Rosemary Parker /

Mike Harfield

Date / Issue Description Change

Table A Revision History (continued)

Request

Chapter Action

entitled, "Overview of

E911", "Coordination of

All N/A July 15, 2002 / 1b Revisions to sections

Wireless Interconnection",

and "Network Specifications

and Ordering".

entitled "TN Errors and

Corrective Action"

Various N/A June 20, 2001 / 1a General revisions to section

All N/A April 4, 2002 / 1 Initial Issue Rosemary Parker /

Page 9

Page 10

Wireless E911 Guide CG-EWCG-001

Introduction / Revision History Issue 3, January 6, 2004

Page 10

Page 11

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Overview of E911

1. Overview of E911

1.1 Definition of E911

"911" has been designated in the United States as the number to be used by the public to summon emergency aid or to report a crime, fire or accident. Its main purpose is to make it easier for people in time of emotional stress to contact the proper emergency agency. An important advantage of 911 emergency service is improved (reduced) response time.

The original 911 service, known as Basic 911 (B911), routes a call to one centralized answering location. The attendant at the answering location obtains the pertinent information that identifies the call and the caller’s need. The attendant then determines the appropriate agency and dials the number to transfer the caller to that agency.

Enhanced 911 service, or E911, is a full featured electronic system that provides three (3) major enhancements to Basic 911 service:

1.1.1 Selective Routing

Electronically routes 911 emergency calls to the proper Public Safety Answering Point (PSAP) based on the Emergency Service Number (ESN) code that has been assigned to the cell site address or the longitude/latitude of the caller’s location. This may be accomplished by assigning "pseudo-ANI" telephone numbers to each face of each antenna in order to designate a fixed location for the serving area. Some wireless solutions allow the assignment of a pseudo-ANI telephone number to a specific PSAP rather than an antenna face. An ESN is assigned to the "pseudo-ANI" telephone numbers during database record processing and is assigned from the Master Street Address Guide (MSAG) based on the address. Some solutions may dynamically assign the ESN based upon the longitude/latitude of the caller’s location. Wireless Carriers must work with the local governmental agencies and agree on call routing, ESN assignments, and MSAG valid addresses. This process is described later in this document. Wireless Carriers should identify selective routing capabilities for premises based ALI systems and make arrangements to deliver wireless calls directly to the PSAP in those cases where selective routing is not utilized. See Premises Based ALI Systems below.

1.1.2 Automatic Number Identification (ANI)

Provides the PSAP with the 7-digit pseudo-ANI telephone number representing the antenna face which received the wireless 9-1-1 call or the pseudo-ANI PSAP routing number, depending on the wireless solution implemented. Interfaces utilizing Feature Group D signaling between the E911 selective routing tandem and the PSAP may be capable of sending 10-digit ANI or 10-digit ANI and 10-digit call back number to the PSAP. Pseudo-ANI numbers must be assigned from the wireless carrier’s number range and must be geographically valid for the E911 selective routing tandem service area.

1.1.3 Automatic Location Identification (ALI)

Provides the PSAP with cell site location information associated with the pseudo-ANI. Phase 1 compliance also requires ALI to contain the wireless subscribers call back number. This may be accomplished by the

Page 1

Page 12

Wireless E911 Guide CG-EWCG-001 Overview of E911 Issue 3, January 6, 2004

wireless carrier providing a real-time update to the ALI databases during 9-1-1 call processing. Phase 2 requires both of the data elements provided in Phase 1 plus the longitude and latitude of the caller’s location when they dialed 9-1-1. BellSouth supports E2 connectivity between MPCs and the ALI database hosts as defined in BellSouth Technical Reference TR73610, Issue 2. BellSouth will deliver the lat / long data to the PSAP in the ALI response message as described in BellSouth Technical Reference TR73528, Issue 6. Wireless Carriers must ensure dynamically updated records will comply with TR73528 when delivered to the PSAP. These Technical References may be found on the following web site:

Note: To receive the maximum benefit of E911, the initial ALI database record must be assigned an

MSAG valid address even if the tower is located in a rural area. MSAG valid addresses are obtained from the addressing authority in the E911 area where the cell site is located.

1.1.4 Premises Based ALI Systems

Premises based ALI systems may have a separate database, software, and hardware located on the E911 Customer premises. Wireless Carriers must identify all premises based systems in their service areas and comply with any special data or interface requirements. Carriers should meet with PSAPs to determine if selective routing or direct trunking is used to deliver 911 calls. If calls are not selectively routed to premises based ALI systems, the carrier may need to deliver wireless 911 calls to the PSAP administrative lines or use other arrangements as negotiated with the PSAP. This guide does not address issues related to premises based ALI systems.

1.2 PSAP Display

The PSAP display for the ANI and ALI has been configured so that the PSAP attendant can immediately recognize from the English Language Translations (ELT) that the call is being made from a wireless device. The ALI response may contain the cell site sector location, subscriber call back number, and lat/long when available. An example of a typical PSAP display is shown. This screen/display will vary based on which PSAP equipment is chosen by the E911 Customer.

Page 2

Page 13

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Overview of E911

1.3 Databases Required to Support E911

Three (3) data files (or databases) are required to provide the data for display at the PSAP:

• Master Street Address Guide (MSAG)

• Telephone Number (TN) Database

• E911 Tandem/Network Information (TN/ESN)

1.4 Master Street Address Guide (MSAG)

The MSAG contains all street information in the full featured E911 service area. The Emergency Service Numbers (ESNs) are assigned to the streets for routing 911 calls to the proper PSAP. As data records for the pseudo-ANI telephone numbers are processed from the wireless carriers, the address information on the data record is validated against the MSAG. Address information on the data records must exactly match

the MSAG information or the data records will be considered an error and returned to the wireless carrier for correction. Data records are not posted to the database until they pass validation.

1.5 Telephone Number (TN) Database

The TN database contains all of the wireline subscriber records and wireless pseudo-ANI records for all carriers in the E911 service area. This information includes the telephone number, name of the wireline subscriber, address, location, class and type of service. For the wireless carrier, it includes the pseudo-ANI

Page 3

Page 14

Wireless E911 Guide CG-EWCG-001 Overview of E911 Issue 3, January 6, 2004

telephone number which has been assigned by the carrier, the carrier name, and the MSAG valid address of the cell site sector location. A full description of the data fields in the TN database may be found inTN Database Updates.

The TN database is updated by the wireless carrier on an ongoing basis as new pseudo-ANI numbers are assigned or when existing information changes. This includes changes in antenna face coverage area when it impacts routing of 911 calls to the appropriate PSAP. The data record which is sent by the wireless carrier is validated against the MSAG for an exact address match and is assigned the appropriate ESN which is loaded into the E911 host database and the E911 tandem routing database. Details for providing TN data to the E911 host is explained later in this document. Some wireless solutions will dynamically update the cell site location, call back number, longitude, and latitude during 911 call processing. Wireless carriers are still required to provide "static" pseudo-ANI data records to the E911 host with MSAG valid addresses. These "static" records will be dynamically updated during 911 call processing. The cell site location information provided during the dynamic updates are not validated against the MSAG, but the original "static" record provided in the SOIR process will be validated and must contain MSAG valid information.

Wireless Carriers must provide valid data records for inclusion in the TN database prior to testing or activating service. If data records are not posted to the TN database, the PSAP will receive a "NO RECORD FOUND" display when subscribers dial 911 which may delay getting them the emergency services they need.

1.6 E911 Tandem / Network Information

Interconnection arrangements to the E911 tandem are negotiated with the wireless carrier’s BST Interconnection Services Account Representative. The wireless carrier must provide a minimum of two (2) Type 2C redundant trunks to the E911 tandem office(s) that will serve the Mobile Switching Center (MSC). Additional facilities may be required depending on the technical solution used to dynamically pass the wireless call back number and longitude/latitude to the ALI database. Data circuits must exist between MPCs and the ALI database hosts for the E2 interface required for Phase 2.

Determining the proper PSAP to route wireless 911 calls must be negotiated between the wireless carrier and the E911 Coordinators in the serving areas. This must also include the proper PSAP to receive the wireless 911 call in the event of an ANI (pANI) failure from the MSC. All 911 calls will default route to the negotiated PSAP when an ANI (pANI) failure occurs. E911 Coordinators must agree on the PSAP to receive these calls. Once agreement has been reached with the E911 Coordinators, the wireless carrier will notify the BST Interconnect Account Representative of the PSAP location for default routing. This will allow for BST to establish the necessary translations in the E911 tandem office. The BST Interconnect Account Representative may assist the wireless carrier in identifying which E911 tandem office should be used to route calls to a specific PSAP.

Page 4

Page 15

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Overview of E911

1.7 Glossary of Terms

Table B Glossary of Terms

Term

ACAC Address Verification

Request (AVR)

Access Carrier Advocacy Center A form issued by each telco to refer and resolve address

discrepancies with the E911 Customer.

Definition

ALEC Alternative Local Exchange Carrier Alternate Routing A standard feature provided to allow E911 calls to be routed to a

designated alternate location if :

1. all E911 trunks to the primary PSAP are busy OR

2. the primary PSAP closes down for a period. (i.e. night service)

Automatic Location Identification (ALI)

A feature by which the address associated with the telephone number (ANI or pANI) is forwarded to the PSAP for display.

Automatic Number Identification (ANI)

The telephone number assigned by the wireless carrier to the cell face or PSAP. Also known as Pseudo-ANI and Emergency Service Routing Digits (ESRD).

Note: The pseudo-ANI number MUST be assigned from the wireless carrier number pool and be geographically correct for the

serving area. BST BellSouth Telecommunications, Inc. Call Back Number Telephone number PSAP will use to dial the 911 caller in the event

the call is disconnected. Also known as wireless Mobile Directory

Number (MDN), Wireless Subscriber ANI (WS-ANI) and Calling

Party Number (CPN). Call Through Testing The process of testing the network, equipment and database

associated with an E911 system prior to the final cutover. CMRS Commercial Mobile Radio Service CSU Channel Service Unit DSU Data Service Unit E2 Interface The TIA / EIA / J-STD-036 E2 interface utilized to provide phase

2 location information to the ALI database from the MPC. Refer

to BellSouth TR73610, Issue 2. E911 Customer A governmental agency responsible for providing public safety and

purchasing 911 service.

- continued -

Page 5

Page 16

Wireless E911 Guide CG-EWCG-001 Overview of E911 Issue 3, January 6, 2004

Table B Glossary of Terms (continued)

Term Definition

E911 Tandem Central Office Switch

Emergency Service Number (ESN)

Emergency Service

The central office designated for a geographical area to receive end

office E911 calls and route to the appropriate PSAP.

A number associated with the geographical area served by the same

fire, police and ambulance districts.

See ANI or pANI Routing Digits (ESRD)

End Office The central office switch receiving E911 calls from subscribers.

For wireless, this would be the MSC. FCC Federal Communications Commission FOC Function of Change GMLC (see MPC) ICO Independent Telephone Company Integrated Services

Digital Network User

A message protocol to support call set up and release for interoffice

voice call connections over SS7 signaling. Part (ISUP)

Intrado A vendor designated by BST to handle E911 data maintenance

(formerly SCC) LOC Location Master Street Address

Guide (MSAG)

Mobile PositionCenter (MPC)

Mobile Switching Center (MSC)

National Emergency Number Association (NENA)

NPA NRF NXX

All street data, including street names, address ranges and ESNs

used to validate incoming telephone number data for provisioning

of selective routing.

The network entity that provides phase 2 location information to

the ALI database over an E2 interface. For the purposes of this

document, MPC and GMLC are considered equivalent although a

GMLC is unique to the GSM environment.

Wireless equivalent of an End Office, which provides switching

functions from wireless calls.

A professional association of 9-1-1 emergency number entities

responsible for the planning, implementation, management and

administration of national emergency number issues.

The area code of the telephone number.

No Record Found

The first three(3) digits of a telephone number following the NPA.

- continued -

Page 6

Page 17

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Overview of E911

Table B Glossary of Terms (continued)

Term Definition

Pseudo-ANI (pANI) The telephone number assigned by the wireless carrier to designate

a specific cell antenna face or PSAP. Also see Automatic Number

Identification (ANI). Public Safety

The answering location for 911 calls. Answering Point (PSAP)

RCF Remote Call Forwarding SALI Stand Alone Automatic Location Identification SCC Communications A vendor designated by BST to handle E911 data maintenance

(now Intrado) Selective Routing (SR) A standard feature that routes an E911call from the E911 tandem to

the designated PSAP based upon the address and assigned ESNof

the pseudo-ANI telephone number record. ServiceOrderInterface

Record (SOIR) Signaling System

7 (SS7)/Common Channel Signaling 7 (CCS7)

A formatted data record sent to the E911 host computer system by

the wireless carrier. (see TSS)

An out-of-band signaling system used to provide basic routing

information, call set up and other call termination functions.

Signaling is removed from the voice channel and put on a separate

data network. Subscriber Person or end user making a 911 call. System ID A two(2) character code used to identify a tandem. (Assigned by

BST) Tandem Routing An arrangement for connecting E911calls to the correct PSAP

based on the ESN associated to the pseudo-ANI telephone number

service address. (see Selective Routing) Telco (Telephone

Company)

A term used interchangeable throughout this document to depict a

Bell Operating Co., an Independent Company, an Alternative Local

Exchange Carrier (ALEC) or a Wireless service provider. TN Transaction Servicing

System (TSS)

Telephone Number

The BellSouth E911vendor’s computer system that performs

database processing. WSANI Wireless Subscribers ANI (see ANI or pANI)

Note: Additional wireless and technical information may be found on the NENA web site at

http://nena9-1-1.org:Click here to access website.

Page 7

Page 18

Wireless E911 Guide CG-EWCG-001 Overview of E911 Issue 3, January 6, 2004

1.8 Database Escalation Procedures

The following procedures have been established for Wireless Carrier escalation of database related issues to BellSouth / Intrado: (Examples of these issues are, but not limited to: MSAG problems, NPA / NXX updates, etc.)

The initial trouble / problem referral made by the Wireless Carrier should go to the Intrado NDSC Data Analyst. The escalation process will normally begin after a referral is made to the NDSC with unsatisfactory or no resolution.

1.8.1 Access To NDSC Analysts

DIAL 1-888-584-3810, AT THE PROMPT, ENTER THE APPROPRIATE EXTENSION NUMBER.

1.8.2 Level One Escalation: Intrado

Data Opns SUPERVISOR (Kelley Thomson) extension 6269

1.8.3 Level Two Escalation: Intrado

Data Opns MANAGER (Mike Wallace) extension 6270

1-888-584-3810

1.8.4 Level Three Escalation: Bellsouth

BellSouth Wireless E911 Implementation Manager: (205) 321-4785 If the problem has not been resolved by Intrado or the problem has not been resolved to the customer’s

satisfaction, the BellSouth Wireless E911 Implementation Manager should be contacted:

1. The BellSouth Wireless E911 Implementation Manager should be notified of the problem.

2. The BellSouth Wireless E911 Implementation Manager will involve the BellSouth Address/911 Staff Support organization as required. All 911 / addressing issues should be referred by the Wireless E911 Implementation Manager to the Address / 911 Staff.

3. The Address / 911 Staff Support group will investigate and resolve or escalate up to the highest level necessary within BellSouth and / or Intrado. When the problem is resolved, A / 911 Staff Support will advise the Wireless E911 Implementation Manager who will notify the customer of the resolution.

Page 8

Page 19

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Coordination of Wireless Interconnection

2. Coordination of Wireless Interconnection

2.1 Overview

This section provides the Wireless Carrier with the steps necessary to interconnect with the BellSouth (BST) E911 network.

The FCC Wireless Phase 1 Order requires the Wireless Carrier to provide both the cell site sector location information and the wireless subscribers call - back number for wireless 911 calls. Phase 2 requires the additional data fields longitude and latitude be provided to represent the location of the caller when they dialed 911. Cell site sector location information is provided in "static" database records as described in TN Database Updates. The subscriber’s call - back number, longitude, and latitude must be provided real

- time during 911call processing. Various technical solutions may be chosen by the Wireless Carrier to provide the required data to the ALI database. Wireless Carriers must work with Intrado to ensure the chosen solution is compatible with the BST ALI database interfaces. Some solutions allow the "static" database records to be assigned on a PSAP basis with the cell site sector location information, call - back number, and the longitude / latitude being provided real-time during 911 call processing.

Wireless Carriers must order Type 2C trunks for transmission of the voice and pseudo-ANI (pANI) numbers to the E911 tandem. Some solutions may require SS7 / ISUP trunking between the wireless MSC and the E911 tandem. If SS7 connectivity will be used, refer to Appendix A of this guide. In addition to these trunks, Wireless Carriers may be required to order two(2) digital data circuits with secondary channel to the BST Automatic Location Identification (ALI) computers. These circuits are necessary to provide Phase 1 real-time updates to the ALI database for storing the wireless subscribers ten digit call-back number and for some solutions, cell site sector location information. Two redundant ALI computers work as a mated pair, therefore a digital data circuit is required to each of the two ALI computers. The need for digital data circuits depends on the technical solution chosen. Steps to determine if there is a need, and how to order these circuits, are described in this section.

Wireless Carriers must also provide E2 connectivity between the MPCs and the ALI database hosts allowing Phase 2 location information to be populated in the ALI databases.

Interconnection to the BST E911 network involves the effort of various BST departments. The BST Wireless Account Team and Wireless E911 Implementation Manager will be the coordinators between the Wireless Carrier and the various BST departments to assist with steps necessary for interconnection.

2.2 Coordination Process: Wireless Carrier

The Wireless Carrier will notify the BST Wireless Account team and provide general information concerning the request to interconnect to BST’s E911 network. This information should include the states, counties, and / or parishes that are involved in the wireless coverage area, the method of interconnection to the BST network, and the technical solution chosen to provide the wireless subscribers call - back number and longitude / latitude to the ALI database, and E2 interface information.

Wireless Carriers must meet with each of the E911 Customers in the wireless coverage area to discuss cell site locations, valid addresses and formats for static database records, ESN assignments, identification

Page 9

Page 20

Wireless E911 Guide CG-EWCG-001 Coordination of Wireless Interconnection Issue 3, January 6, 2004

of the appropriate E911 tandem, 911 call routing, default routing for ANI failures, and assignment of geographically valid pANI numbers from the wireless carrier’s number range. The E911 customers must agree on which PSAP will accept 911 calls from the various cell sites including when ANI failures occur. Wireless Carriers should also determine if the E911 Customers wish to segregate wireless 911 calls from wireline 911 calls by implementing separate trunk groups to the PSAP. All premises based E911 databases should be identified as well as any special procedures necessary to update those databases.

Carriers must also work directly with Intrado to include the Carrier’s pANI numbers in the appropriate Security Tables and to identify the appropriate E2 interface to invoke for Phase 2.

A Service Inquiry must be initiated by the Wireless Carrier through the BST Account team for the Type 2C trunk connections and/or SS7 /ISUP trunks to the E911 tandems. If SS7 connectivity will be used, refer to Appendix A of this guide. The BST Wireless E911 Implementation Manager will discuss with the Wireless Carrier the process of ordering / provisioning the digital data circuits to the ALI computers, if new circuits are required.

The Wireless Carrier must contact Intrado, the BST E911 database vendor, for all database related steps necessary for the establishment and maintenance of wireless database records and interfaces to the ALI computers. Carriers must post valid records in the E911 database prior to testing or turning up service. Additional information related to database requirements is found in this guide.

Since access to E911 is a critical issue in today’s environment, it is necessary for the Wireless Carrier to provide 24 X 7 contact name and telephone number information for maintenance and trouble handling / clearing.

2.3 Coordination Process: BST Wireless Account Team

The BST Wireless Account team will receive the initial request from the Wireless Carrier and initiate the BST Service Inquiry process for interconnection to the BST E911 network. The BST Account team will contact the BST Wireless E911 Implementation Manager to begin the internal BST coordination process.

Various BST departments will review the Service Inquiry and update with additional required information. The BST Account team will then complete form RF-1004WS and forward this form, along with a copy of the Service Request, to the BST Wireless Service Center where service orders will be input into the service order system.

A copy of the form RF-1004WS will also be distributed to the BST Implementation team and Intrado.

2.4 Coordination Process: BST Wireless E911 Implementation Manager

The BST Wireless E911 Implementation Manager will assist the Wireless Carrier with the requirements for connecting to the BST E911 network. During this process the BST Wireless E911 Implementation Manager will determine if it is necessary for the Wireless Carrier to order digital data circuits to the BST ALI computers. The technical solution chosen by the Wireless Carrier will determine the need for these data circuits:

Page 10

Page 21

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Coordination of Wireless Interconnection

• If the Wireless Carrier is connecting to a DMS100 E911 tandem utilizing an existing Nortel wireless connection to the ALI computers, no additional data circuits will be required for Phase 1.

• If the Wireless Carrier provides their own wireless solution hardware in their network, the Wireless Carrier must provide the data circuits.

• If the Wireless Carrier contracts with a third party to provide the connection to the ALI computers, the data circuits should be provided by the third party.

• If new solutions are negotiated, the BST Wireless E911 Implementation Manager will work with the Wireless Carrier and the BST team to determine the interconnection requirements and process flow.

The BST Wireless E911 Implementation Manager will coordinate with the BST Wireless Access Carrier Advocacy Center (ACAC) the provisioning, testing, and Wireless Carrier acceptance of the Type 2C trunks to the BST E911 tandems as required. The BST Wireless E911 Implementation Manager will also coordinate with the BST departments and Intrado, the provisioning, testing, and acceptance of new data circuits to the ALI computers if applicable.

The BST Wireless E911 Implementation Manager will issue a Teleprocessing Request form to Intrado and the BST IT Transport Group if new data circuits are required to the ALI computers.

As required, the BST Wireless E911 Implementation Manager will assist the Wireless Carrier through the necessary processes required to complete the interconnection to the BST E911 network.

2.5 Coordination Process: Mobile Position Center Provider

The Wireless Carrier will be required to submit written notification naming the Mobile Position Center (MPC) provider they have selected. Note that MPC and GMLC are equivalent with respect to this guide although a GMLC is unique to the GSM environment. This written notification should be submitted to the BST Wireless E911 Implementation Manager. Any subsequent change in MPC provider also requires written notification naming the new provider selected.

2.5.1 Steps for Establishment/Change of Mobile Position Center Provider

The Wireless Carrier is required to provide written notification of their selected or modified MPC provider to the BST E911 Implementation Manager via US Mail, electronic mail, or fax:

BST Wireless E911 Implementation Manager Attn: John Storey 3535 Colonnade Parkway Birmingham, AL 35243 Tel: 205-977-7653 Fax: 205-977-7692 Email: John.Storey@bellsouth.com

Page 11

Page 22

Wireless E911 Guide CG-EWCG-001 Coordination of Wireless Interconnection Issue 3, January 6, 2004

2.5.2 Initial Establishment of Mobile Position Center Provider

The first step for the Wireless Carrier in establishing their MPC provider is to contact the BST Wireless E911 Implementation Manager. At that time a discussion will take place to determine the method of connectivity. The Wireless Carrier will be provided a questionnaire used to direct the Wireless Carrier to the next steps required for Phase II connectivity. Once it has been determined what the needs of the Wireless Carrier are, they will be directed to the appropriate network entity that will provide location information to the ALI database. When the determination has been made, the Wireless Carrier will then be asked to provide written notification to the BST Wireless E911 Implementation Manager as to who they have selected as their MPC provider.

If the Wireless Carrier will use their own equipment and provide their own E2 Interface to BST, the first step is to contact the BST ICS E911 Product Manager. The Wireless Carrier is required to sign the Wireless E911 Phase 2 MPC Operator Interface Agreement and to work with the BST Wireless E911 Implementation Manager to connect the E2 circuits to the ALI databases.

2.5.3 Change of Mobile Position Center Provider

Should the Wireless Carrier change the MPC provider that was initially selected, written notification to the BST Wireless E911 Implementation Manager will be required. This notification may be sent via US Mail, electronic mail, or faxed to the address noted above.

2.5.4 Information Required for Phase 2 MPC/GMLC Circuits to the ALI Hosts

The following information can be used by Wireless Carriers or their MPC/GMLC providers in placing orders for the E2 Data Links which will connect their MPCs or GMLCs to BellSouth’s ALI Host Computers located in the 4 Data Centers. The BellSouth ALI Host Computers in Miami, FL and Charlotte, NC serve FL, GA, NC and SC. The BellSouth ALI Host Computers in Birmingham, AL and Nashville, TN serve LA, MS, AL, TN and KY. MPCs/GMLCs must be connected to the appropriate ALI host pairs for the states served.

PLASE NOTE - the following also contains information related to these circuit orders which must be returned to BellSouth’s Wireless E911 Implementation Manager as soon as it is available. This will aid in completion of preliminary forms that must be provided in advance of the orders to the data center personnel. to insure there are no delays in connecting and extending the circuits.

Note that there is a

separate form for each of the BellSouth ALI Host Computer locations.

You should also contact Doug McCambridge at Intrado (720-494-6271) to schedule coordinated testing of these circuits. Intrado requires at a minimum 5 days notice prior to testing. Questions/comments can be directed to John Storey at 205-977-7653 or by e-mail at John.Storey@bellsouth.com.

Detailed Circuit Information (Circuit IDs for all segments of the circuits with 24 X 7 Contact names and numbers, etc.) is required so that service technicians can communicate with each other in the event of outages or maintenance issues.

Page 12

Page 23

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Coordination of Wireless Interconnection

2.5.5 Forms

irmingham D

ashville DATACenter: (serving LA, MS, AL, TN, KY)

harlotte DATACenter: (serving FL, GA, NC, SC)

iami DATACenter: (serving FL, GA, NC, SC)

Center: (serving LA, MS, AL, TN, KY)

ATA

Page 13

Page 24

Wireless E911 Guide CG-EWCG-001

Issue 3, January 6, 2004

Page 14 - Blank

Page 25

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Network Specifications and Ordering

3. Network Specifications and Ordering

3.1 Overview

This section provides the Wireless Carrier with the Network Specifications and Ordering Procedures to be followed when ordering facilities to interconnect to the BST E911 network.

Due to the complex nature and many processes involved with interconnecting to the BST E911 network, coordination between the Wireless Carrier and the various BST organizations involved will be accomplished through the Wireless Carrier’s Marketing Account team and the BST Wireless E911 Implementation Manager.

3.2 Specifications & Ordering Process:

3.2.1 Option 1: BellSouth NORTEL Solution Carring Phase 1 Data Only (CBN & pANI)

This solution can be used for delivery of CBN and pANI as the Wireless Carrier begins to make Phase 2 location data available via an E2 interface, as described in J-STD-036. The Wireless Carrier will be required to order a trunks, connecting directly to the appropriate BellSouth E911 Tandem switch. If SS7 connectivity will be used, refer to Appendix A of this guide.

Note: These trunks must use J-STD-034.7 POI-T8 (MF) Interface Signaling which can be designed

w Refer to J-STD-034.7 for details. Ensure the BellSouth Wireless Account Team specifies the correct option on the order form.

The Wireless Carrier will deliver a twenty(20) Digit FG-D signal consisting of the ten(10) digit call back number (CBN) and the ten(10) digit pseudo ANI (p-ANI), to the BellSouth E911 Tandem switch. This signal is in the following format: KP + II + 10 Digit CBN + ST + KP + 10 Digit p-ANI + ST Note that the "II" digits are placeholders and may be filled with any two(2) digits.

These trunks are to be ordered through the Wireless Carriers BellSouth Wireless Account Team as an addendum to the Wireless Carriers existing contract with BellSouth.

The Wireless Carrier is NOT required to order / purchase data link connections to the BellSouth ALI Host computers when using this option to provide Phase 1 information. The connection to the ALI Host computers will be handled by BellSouth. Wireless Carrier’s are responsible for providing E2 connectivity between the MPCs and BellSouth ALI Host computers as defined in BellSouth Technical Reference TR73610, Issue 2.

minimum of two(2), Type 2C, Feature Group - D (FG-D) or SS7/ISUP signaling

ith or without

the optional pause for acknowledgement after the 1st stage address field.

Page 15

Page 26

Wireless E911 Guide CG-EWCG-001 Network Specifications and Ordering Issue 3, January 6, 2004

3.2.2 Specification & Ordering Process: Option 2: Third Party Vendor Solution

The Wireless Carrier will be required to order a minimum of two (2), Type 2C, CAMA or SS7/ISUP signaling trunks, connecting to the appropriate BellSouth E911 Tandem switch. If SS7 connectivity will be used, refer to Appendix A of this guide.

If using CAMA signaling, the Wireless Carrier must be able to deliver to the BellSouth E911 Tandem the two(2) stage CAMA MF signal required for interfacing directly with the appropriate BellSouth E911 Tandem switches. This signal is in the following format:

Stage 1: KP + 11 + ST

Stage 2: KP + Info Digit + 7 Digit ANI (p-ANI) + ST

These trunks are to be ordered through the BellSouth Wireless Account Team as an addendum to the Wireless Carriers existing contract with BellSouth.

The Wireless Carrier is NOT required to order / purchase data link connections to the BellSouth ALI Host computers when using this option. The connection to the ALI Host computers is handled by the provider of the solution chosen by the Wireless Carrier. Wireless Carriers must work with Intrado to ensure the chosen solution is compatible with the supported interfaces to the ALI Host computers. Wireless Carriers must establish E2 connectivity between MPCs and the BellSouth ALI Host computers for Phase 2 as defined in BellSouth Technical Reference TR73610, Issue 2.

3.3 Wireless Carrier Owned Hardware

If the Wireless Carrier chooses to purchase their own protocol conversion hardware as a means of achieving Phase I Compliance, the specifications / ordering process will be as follows:

3.3.1 Trunking

The Wireless Carrier’s protocol conversion hardware must be able to deliver the two(2) stage CAMA MF signal required for interfacing directly with the BellSouth E911 Tandem switch. This signal is in the following format:

Stage 1: KP + 11 + ST Stage 2: KP + Info Digit + 7 Digit ANI (p-ANI) + ST

These trunks are to be ordered through the BellSouth Wireless Account Team as an addendum to the Wireless Carriers existing contract with BellSouth.

Page 16

Page 27

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Network Specifications and Ordering

3.3.2 Data Connections Required For Wireless Carrier Owned Hardware - Phase 1 Only

In addition to the Type 2C CAMA or SS7 trunks, the Wireless Carrier will be required to purchase two(2)data link connections from their protocol conversion hardware directly to the BellSouth ALI Host computers. Two(2) data links are required because the BellSouth ALI Host computers are mated pairs for redundancy, and are located in different locations for diversity.

These data links are 9.6 or 19.2 Kbps asynchronous or up to 56Kbps synchronous for X.25. The Secondary Channel feature is required in order to deploy end-to-end diagnostic and configuration capability from the master end (BellSouth Data Center) without disruptive consequences. The characteristics of the equipment used to modulate the data links are:

• Sub-rate digital Channel Service Unit/Data Service Unit (CSU / DSU) compatible with Memotec SC56

• 10 bit data character

- 1 start bit

- 8 data bits (8th bit ignored)

- 1 stop bit

• Full Duplex

• Continuous Carrier

For additional information and details concerning the data interface, please refer to the following document which can be found on website www. interconnection.bellsouth.com/guides/html/tech_ref.html: and may be amended from time to time: TR 73610 BELLSOUTH E911 REAL-TIME DATA INTERFACES FOR WIRELESS AND COMMERCIAL MOBILE RADIO SERVICE (CMRS) CONNECTION

In most cases, these data links will be interlata / interstate connections. As such, they must be ordered through the Wireless Carriers Interexchange Carrier of choice. The BellSouth portion of these circuits will be provisioned and maintained through the appropriate BellSouth Interexchange Access Customer Advocacy Center (ACAC).

Wireless Carriers must work with Intrado to ensure wireless solutions are compatible with the supported interfaces to the BellSouth ALI host computers.

3.4 Wireless Phase 2

BellSouth supports the implementation of Wireless E911 Phase II through the nondiscriminatory access to its ALI database for those companies wishing to provide Mobile Position Center (MPC) functionality. For the purposes of this document, GMLC and MPC are considered equivalent although a GMLC is unique to a GSM environment. This access is facilitated through the BST ALI Interface. The MPC is defined as the network entity that provides location information to the ALI database. Each MPC provider must execute a contract with BellSouth. This contract must be signed and in place prior to testing Phase II. Wireless Carriers should ensure they have contracted with an MPC provider prior to negotiating Phase

Page 17

Page 28

Wireless E911 Guide CG-EWCG-001 Network Specifications and Ordering Issue 3, January 6, 2004

II testing and implementation. BellSouth requires that Wireless Carriers provide notification in writing upon the selection or change in MPC providers.

BellSouth is not responsible for the location determination technology, the accuracy of the location determination technology, or the investigation or maintenance of said technologies. Only the data required and specified by the FCC in its Report and Order 94-102 will be delivered by BellSouth to the PSAP when provided by the CMRS. This required data includes the cell site or sector location, the callback number, and the longitude/latitude of the caller. The delivery, or lack of delivery, of additional data elements which may be provided by the Wireless Carrier will not be the responsibility of BellSouth and BellSouth assumes no responsibility or liability for such information.

3.5 Interface Testing

Wireless Carriers shall conduct joint testing of wireless interfaces to the BellSouth ALI computers. Testing will be required for first occurrences of a particular interface or vendor, and whenever changes are made to an existing interface.

Testing shall be conducted with Intrado utilizing their test facility in Colorado, as well as field testing with the BellSouth production ALI computers within the BellSouth region. Charges may be incurred by the Wireless Carrier for this testing. Details shall be specified in interface agreements.

Page 18

Page 29

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 MSAG Maintenance and ESN Assignment

4. MSAG Maintenance and ESN Assignment

4.1 Overview

This section provides general information on ESN assignments and guidelines for working with BST, BST’s data vendor, Intrado, and with the E911 Customer on MSAG maintenance. The Wireless Carrier must meet with the E911 Customers in the wireless service area and agree on 911 call routing, default routing, ESN assignments, and properly assigning MSAG valid street addresses to each ALI database record. Intrado will be the point of contact for data processing and data issue resolution. All other issues should be directed to the BST Wireless E911 Implementation Manager.

4.2 ESN Assignments

ESN mapping is necessary if calls are to be routed to more than one PSAP within an E911 service area. The E911 Customer is responsible for providing boundary information to BST during the conversion to E911 and, ongoing, as emergency districts change.

When an E911system is being implemented, the E911 Customer provides BST the boundaries depicting each fire, police and EMS jurisdiction for the E911 service area. After all emergency service boundaries have been defined, a different ESN is assigned to each geographical area with the same set of responding agencies, i.e., police, fire, and EMS.

The ESN controls 911 call routing to the proper PSAP and provides emergency agency information for each wireline 911 call. The ESN numbers are assigned to the E911 serving area based on the ESN numbers available in the E911 tandem central office switch. The ESN for wireless 911 calls are used to route the call to the proper PSAP. Due to the geographical variation in service areas of different cell sites, it is not currently feasible to display specific emergency agency information for wireless calls. Cell site service areas generally do not match existing emergency service boundaries. Creating additional ESN boundaries for wireless service areas would be difficult for the E911 Customer and quickly exhaust the ESN numbers available.

The Wireless Carrier must meet with each E911 Customer in the service area and provide wireless service coverage areas for each cell site. The E911 Customers must agree on which PSAP should receive 911 calls based on the coverage area for each antenna face. This may require agreements between political jurisdictions if the wireless service area crosses jurisdictional boundaries. In addition to deciding PSAP routing, the E911 Customers must also decide on which PSAP should receive all 911 calls where the ANI (pANI) is not delivered to the E911 tandem with the call. This condition is known as "ANI failure" and must be default routed to a specific PSAP. The E911 Customers should agree and assign ESN numbers for both normal and default routing. Wireless Carriers must provide BST the list of PSAPs identified to receive default routed calls and the associated trunk groups.

Wireless Carriers must identify E911 Customers using premises based ALI systems. Premises based systems may have special data and interface requirements to enable the dynamic wireless data to be included in those systems.

Page 19

Page 30

Wireless E911 Guide CG-EWCG-001 MSAG Maintenance and ESN Assignment Issue 3, January 6, 2004

For areas with existing E911 service, existing ESN numbers should be assigned for wireless call routing. Any of the currently assigned ESN numbers for a specific PSAP can be selected and placed in the corresponding MSAG entries for the cell site addresses as described in the next section. The PSAP should identify which ESNs should be used.

4.3 MSAG Maintenance and Validation

The Master Street Address Guide (MSAG) is the portion of the E911 database which contains the address and ESN information. The MSAG associates the appropriate ESN to the pseudo-ANI number based on the address on the data record provided by the Wireless Carrier.

It is the responsibility of the E911 Customer to assign, maintain and resolve discrepancies in MSAG data for their service area. The E911 Customer is also responsible for providing new address information and changes to address information to the BST data vendor for updating to the MSAG database.

It is the responsibility of all telcos (wireless and wireline) participating in an E911 service area to ensure that all data records sent to the E911 host database have an MSAG valid address. Each telco will work directly with the E911 Customer to resolve any address discrepancies.

The Wireless Carrier and E911 Customers must agree on the formatting of the Wireless Carrier data records. Some wireless solutions require that each antenna face or PSAP, depending on the wireless solution implemented, be assigned an MSAG valid address. The carrier and E911 Customer must work together and agree on how the address and cell site sector location information should be formatted and to ensure the addresses exist in the MSAG database with the appropriate ESN to route 911 calls to the agreed upon PSAP. For some solutions, each antenna face should be assigned unique pseudo-ANI (pANI) numbers by the Wireless Carrier to identify the specific cell site sector location. In other solutions, each PSAP is assigned unique pANI numbers. Pseudo-ANI numbers must be geographically valid for the E911 selective routing tandem used to route the calls to PSAPs. The Wireless Carrier must create SOIR data records for the cell sites or PSAPs containing the MSAG valid street address previously agreed upon with the E911 Customer. If the street address in the SOIR data record is not formatted exactly to match the MSAG entries, the SOIR data record will be in error and returned to the Wireless Carrier for correction. Refer to tab "TN Database Updates" for detailed information on providing data for the E911 database.

For some solutions, the address used for the cell site is the address that has been assigned to the structure where the tower is located. Or, if the tower is being constructed where there is no existing structure, it is the E911 address assigned by the County to the new tower location.

If all antenna faces for a tower will route calls to the same PSAP, the one address may be shown for each pseudo-ANI number associated with that tower. If it is determined that one or more of the pseudo-ANI numbers will need to route to a different PSAP, then different addresses for each face must be obtained from the E911 Customer. Prior to sending the pseudo-ANI data record to the E911 host, the cell site address should be validated with the E911 customer’s MSAG in an effort to minimize error fallout and ensure proper ESN assignment for call routing. If the address(es) to be used are not currently in the MSAG, then the E911 Customer should send a MSAG ledger document to the BST data vendor to add the address to the MSAG database. The pseudo-ANI data records for that cell site should not be transmitted by the wireless carrier until the address has been added to the MSAG database.

Page 20

Page 31

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 MSAG Maintenance and ESN Assignment

Some solutions will dynamically provide the cell site location, subscriber call back number, and lat/long during 911 call processing. Wireless carriers are still required to provide "static" pseudo-ANI data records to the E911 host with MSAG valid addresses. These "static" records will be dynamically updated during 911 call processing. The cell site location information provided during the dynamic updates are not validated against the MSAG, but the original "static" record provided in the SOIR process will be validated against the MSAG.

Page 21

Page 32

Wireless E911 Guide CG-EWCG-001

Issue 3, January 6, 2004

Page 22 - Blank

Page 33

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Database Updates

5. TN Database Updates

5.1 Overview

The E911 Telephone Number (TN) database contains data records provided by the different wireline and wireless carriers offering service within the E911 service area. For wireline service, the TN records contain the subscriber’s telephone number, name, service address, and other information about the fixed wireline subscriber location that may be helpful in providing emergency response. Wireless data must be treated differently due to the nature of the service and the mobility of the caller’s location. Individual wireless subscriber information is not entered into the E911 TN database unless the service is provided to a fixed location.

Phase 1 of FCC Docket 94-102 requires Wireless Carriers to provide the cell site sector location information and call back number for each 911 call to allow the PSAP to have a general idea of where the call originated and enable them to call the person back in the event the call is disconnected. Phase 2 of the FCC Docket requires Wireless Carriers to additionally provide the latitude and longitude coordinates of the caller’s location. There are various technological solutions available for Wireless Carriers to meet these Phase 1 and 2 requirements.

Some solutions require that the TN data records provided by the Wireless Carriers define cell site sector location information of the geographical area from where the 911 call originated. This is normally done by creating TN records that represent each face of each antenna. These records must contain an MSAG valid address of the antenna structure and contain cell site sector location information that will help the PSAP in locating the general vicinity of the 911 caller. These data records are assigned numbers by the Wireless Carrier, sometimes referred to as Pseudo-ANI or pANI numbers. Some technological solutions require pANI numbers to be assigned to each antenna face while other solutions require pANI numbers to be assigned to each PSAP. In either case, the database records originally provided by the Wireless Carriers must contain MSAG valid addresses. Multiple pANI numbers per antenna face or PSAP may also be required to handle concurrent 911 calls from the same antenna face. Wireless Carriers must determine the E911 database impact and requirements for the technological solution implemented.

The ten digit call back number of the wireless caller and the latitude/longitude coordinates are normally provided to the full featured E911 database by way of a real time update during 911 call processing. This interface to the E911 database will vary by the technological solution implemented, but normally involves updating the corresponding TN database pANI record to include the ten digit call back number of the caller, latitude/longitude, and in some solutions, the cell site sector location information. Concurrent 911 calls processed by the same antenna face may require multiple pANI numbers and database records to be assigned. As the PSAP receives the 911 call and pANI from the Wireless Carrier, the real time update takes place and stores the caller’s call back number and latitude/longitude in the TN database pANI record. The PSAP equipment will query the E911 database using the number provided with the call. The Automatic Location Identification (ALI) returned to the PSAP will include the cell site sector location information, latitude/longitude, and the caller’s ten digit call back number. Premises based ALI systems may not support pANI database records or a real time update interface. Wireless Carriers should identify premises based ALI systems in their service area and explain the impact to the E911 Customers.

In most cases a Wireless Carrier will offer service in areas already converted to Enhanced 911. All pseudo-ANI TN records must be initially loaded into the E911 database and updated on an ongoing daily

Page 23

Page 34

Wireless E911 Guide CG-EWCG-001 TN Database Updates Issue 3, January 6, 2004

basis as changes occur. Wireless Carriers will send daily updates to the E911 database via a mechanized file transfer. Specifications for mechanized file transfer are described later in the tab. The file must include pseudo-ANI TN records for the cell site locations or PSAPs in each E911 serving area. Only cell site or PSAP information should be supplied, individual wireless subscriber data should not be provided unless the service is provided to a fixed location. Pseudo-ANI numbers must be geographically valid for the E911 selective routing tandem used to route calls to PSAPs. Prior to a new NXX being implemented, the Wireless Carrier must furnish the NXX Table update form to the BST Wireless E911 Implementation Manager. The form and instructions for its completion are included in this tab. The Wireless Carrier would begin submitting TN database records, also known as Service Order Interface Records (SOIRs), after the MSAG has been updated with cell site addresses and the NXXs have been added to the table.

The procedures for loading the pseudo-ANI TN records and the daily update process, including technical specifications, are provided in this document. All pseudo-ANI TN records must match the E911 MSAG

database exactly before the record will be loaded to the TN database.

5.2 TN Database Daily Updates: Wireless Carrier Responsibilities

STEP ACTION

1 Obtain official NENA Company

2 Include every pseudo-ANI TN

3 Include blocks of pseudo-ANI

4 Work directly with Intrado to

Identifier and include on each pseudo-ANI TN database record.

record within each E911 service area.

numbers for each antenna face (or PSAP) to handle concurrent 911 calls. Pseudo-ANI numbers must be geographically valid for the E911 selective routing tandem used to route calls to PSAPs.

include the Carrier’s Pseudo-ANI numbers in the appropriate Security Tables and to identify the appropriate E2 interface to invoke for Phase 2.

Page 24

Page 35

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Database Updates

STEP ACTION

5 Coordinate MSAG updates for the

cell sites (or PSAPs) submitted on Maintenance Ledgers by the E911 Customer (including naming/numbering street data)

6 Update address on pseudo-ANI

7 Any new service and all

8 Resolve Daily Service Order

9 Update pseudo-ANI (TN) records

(TN) records as address data or cell site coverage area is modified.

subsequent activity affecting the cell site location or PSAP records must be updated into the TN database. Each record affected must be sent individually with the appropriate changes. For example, if the address changes for a cell site which has 3 pseudo-ANI telephone numbers, all three(3) individual pseudo-ANI (TN) records must be updated.

Interface Record (SOIR) update errors within 24 hours.

with valid MSAG address to resolve 911 call misroute conditions.

10 Handle special update

requirements including area transfer updates and NPA splits. Mass changes must be coordinated with BST.

Page 25

Page 36

Wireless E911 Guide CG-EWCG-001 TN Database Updates Issue 3, January 6, 2004

STEP ACTION

11 Three(3) weeks prior to testing

or implementing a new NXX, the Wireless Carrier must furnish the NXX Table update form to the BST Wireless E911 Implementation Manager. The form and instructions for its completion are contained in this tab.

12 Work with E911 Customer

13 Transfer data files to INTRADO

14 Identify and resolve special

15 Provide dynamic update interface

to resolve address or ESN discrepancies.

to test database processing at least one week prior to service implementation.

requirements for premises based ALI systems.

to populate call back number and latitude / longitude in ALI database.

5.3 E911 Customer Responsibilities

The on-going maintenance responsibilities for the E911 customer are shown below:

• Notify INTRADO of MSAG changes which affect TN records.

• Resolve Address Verification Requests (AVR) referred by INTRADO/Telco.

• Submit PSAP Inquiry Forms to INTRADO.

• Submit ESN realignments / new ESN requirements to the BST marketing contact.

Pseudo-ANI (TN) records that do not have MSAG valid addresses or that error for any other reason, will go to an error file and will not display if a 911 call is made. The PSAP attendant will see "NO RECORD FOUND". Wireless Carriers must ensure all cell site sector locations are defined in the E911 database.

Page 26

Page 37

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Database Updates

Pseudo-ANI records that are not geographically correct for the E911 selective routing tandem may result in "NO RECORD FOUND" or a wrong ALI display due to improper NPA translation.

5.4 Instructions for NXX Table Update Form

Table C Instructions for NXX Table Update Form

Instructions for NXX Table Update Form

ACTION CODE: Circle the CODE that reflects the purpose of the form being

submitted:

A - ADD

Add new information to an existing account, i.e. an additional NXX

C - CHANGE Change information previously submitted, i.e. Contact Name,

Phone, etc.

N - NEW

New Request. Circle NEW if this is the first request OR if submitting information for a new state.

COMPANY NAME: Enter the Wireless Carrier company name. COMPANY

Enter the address to be used for correspondence on data issues.

ADDRESS: CONTACT NAME: CONTACT PHONE

NUMBER: TELCO ID / OCN:

Enter the name of the person responsible for data issues. Enter the full telephone number of the person responsible for data

issues. Enter the four(4) digit numeric Telco ID or Operating Company

Number issued by BELLCORE.

NENA CO. IDENTIFIER:

EFFECTIVE DATE:

Enter the 3-5 character Company ID code registered with NENA (National Emergency Number Association)

Enter the anticipated date that you will begin sending database updates. Please note that this form must be submitted no later

than three(3) weeks prior to the implementation of testing, not submission of data.

FAX NUMBER:

SERVICE REQUEST FOR:

Enter the full fax telephone number of the person responsible for data issues. Error reports and data correspondence will be faxed to this number.

Circle the state where service will be offered. Please use a separate form for each state. (SF = South FL, NF = North FL)

- continued -

Page 27

Page 38

Wireless E911 Guide CG-EWCG-001 TN Database Updates Issue 3, January 6, 2004

Table C Instructions for NXX Table Update Form (continued)

Instructions for NXX Table Update Form NPA / NXX(s): List all NPA/NXXs for pANI records in this service area. E911 TANDEM CLLI: Enter the CLLI code for the E911 tandem for which 911 calls

using a pANI with This NXX will be routed to. (The BST Wireless E911 Implementation Manager can assist you in determining this value). The NPA/NXXs for the pANI records must be valid in this E911selective routing tandem.

Completed forms should be faxed to the BST Wireless E911 Implementation Manager, (205) 977-7692 (fax).

Page 28

Page 39

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Database Updates

5.5 NXX Table Update Form

Figure 1 NXX Table Update Form

Page 29

Page 40

Wireless E911 Guide CG-EWCG-001 TN Database Updates Issue 3, January 6, 2004

5.6 MSAG Formatting

There are basic guidelines for the format of the address on the incoming TN records in order for the TN record to find an exact match to an existing entry in the MSAG database. TN records which do not match the MSAG exactly will error back to the Wireless Carrier for resolution and re-transmission of the TN data. Wireless Carriers must work with the E911 Customer and agree on cell site address formats and to ensure corresponding entries are present in the MSAG database. Cell site sector location information provided by some solutions real time during 911 call processing is not validated against the MSAG, although the initial TN record added to the database must have an MSAG valid address.

An example of an MSAG entry in the E911 database is shown below:

Range

100-399

Prefix

Directional

N MAIN

Street Name

Street Suffix

(Thoroughfare)

Post

Directional

ST SW CHARLOTTE

Community

The address for the TN record being submitted via file transfer would need to be formatted to match the MSAG format shown below:

5.6.1 Correct Format

125 N MAIN ST SW CHARLOTTE

The SOIR will be formatted as follows: House Number = 125

PREFIX DIRECTIONAL = N STREET NAME= MAIN ST SW (includes street name, street suffix, & post directional) COMMUNITY = CHARLOTTE

5.6.2 Incorrect Format

125 NORTH MAIN STREET SW CHARLOTTE 125 N MAIN STREET SW CHARLOTTE 125 NORTH MAIN ST SW CHARLOTTE

All of the above examples shown in the incorrect format would have generated an error back to the Wireless Carrier.

Some other basic rules or guidelines for address format are:

• Avoid using punctuation such as periods, commas, and / or ampersands. Punctuation is only allowed as part of the street name. (i.e. O’HENRY)

• Standard street suffix (thoroughfare) and/or directional abbreviations must always be used. Refer to the valid list of standard abbreviations shown in this tab.

Page 30

Page 41

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Database Updates

5.7 Standard Street Suffix (Thoroughfare) Designations / Directionals

The following table outlines the BellSouth street suffix (thoroughfare) abbreviations.

5.7.1 BellSouth Street Suffix (Thoroughfare) Abbreviations (Table)

Table D BellSouth Street Suffix (Thoroughfare) Abbreviations (Table)

T / F Abbrev ALY ANX ARC AV

Description T / F Abbrev Description

ALLEY ANNEX ARCADE AVENUE

LN LOOP LOOP MKT MNR

LANE

MKT MANOR

BDWK BOARDWALK MT MOUNT BEND BLK

BEND BLOCK

MTN MOUNTAIN NK

NECK

BLVD BOULEVARD PASS PASS BR BRANCH PATH BTM

BOTTOM

PD BYP BYPASS PK CIR CIRCLE PKE CRES

CRESCENT

PKWY

PATH POND PARK PIKE PARKWAY

CRK CREEK PL PLACE CRSG CROSSING PLZ CSWY

CAUSEWAY

PLAZA PIER

CT COURT PROM PROM CTR CENTER PT POINT CV DR

COVE DRIVE

PVT DR

RD ROAD

PRIVATE DRIVE

ESPLND ESPLANADE RDG RIDGE EST

ESTATE

RDWY

ROADW A Y

EXPWY EXPRESSWAY ROW ROW EXT EXTENSION RT ROUTE

- continued -

Page 31

Page 42

Wireless E911 Guide CG-EWCG-001 TN Database Updates Issue 3, January 6, 2004

Table D BellSouth Street Suffix (Thoroughfare) Abbreviations (Table) (continued)

T / F Abbrev Description T / F Abbrev Description FRK FORK RUN FRWY GRDN

FREEWAY GARDEN

SQ SQUARE ST

RUN

STREET

HBR HARBOR STA STATION HL HLS HOLW HOLLOW TR

HILL HILLS

TER TERRACE THRWY

THRUWAY TRAIL

HT HEIGHT TRC TRACE HTS

HEIGHTS

TRNPK

TURNPIKE

HWY HIGHWAY VLG VILLAGE ISL ISLAND WAY JCTN

JUNCTION

WHF LDG LANDING WK LK

LAKE

WAY WHARK WALK YARD

When "Avenue" precedes a street name that is a letter or number, it is not considered a street suffix designation and is, therefore, spelled in full. Refer to examples shown below. When the name of a street is an alphabetic character, the word "Street" is spelled in full. Refer to the examples shown below.

Directional words, North (N), South (S), East (E), West (W), North East (NE), North West (NW), South East (SE), South West (SW) are abbreviated except when used as lettered streets. Refer to the examples shown below.

Street Examples:

511 1ST 733 33RD 23 STREET A NE 600 1ST STREET 733 N 33RD TER 25 SOUTH RD 411 1ST AV 985 NW 5TH CT 60 NORTHEAST BLVD 512 1ST NE 109 E STREET 622 22ND PL SW 735

AVENUE K

5.8 Standard Location Designations

A portion of the TN data record layout described in this tab includes a data field for specific location information. This field is not edited on incoming SOIRs for content, however, there are certain format standards that the PSAP customer is accustomed to seeing on wireline database records. For wireless

Page 32

Page 43

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Database Updates

data records, the location data field may be used to define the cell site sector geographical service area. Wireless Carriers should work with the E911 Customer and agree on the TN data record formats including use of the LOCATION (LOC) data field.

There are four(4) levels of identifiers used for different types of information. Those identifiers are shown as follows in the appropriate hierarchical level:

Level 1: BLDG, WNG, PIER Level 2: FLR Level 3: APT, RM, LOT, SLIP, SUIT, UNIT Level 4: DES

These identifiers may be used uniquely or combined. The identifiers and associated data cannot exceed the size limitation of the data field. Some examples are shown below:

EXAMPLE 1: APT 2-B EXAMPLE 2: BLDG 6 APT 2-B EXAMPLE 3: FLR 6 SUIT 2-B EXAMPLE 4: DES NEXT TO POOL EXAMPLE 5: .25 MI NE OF MAIN ST (wireless example)

5.9 Updating the TN Database

The Wireless Carrier must provide data records for the E911 database as described in this tab. Data records are validated for proper format and to ensure the address information is defined in the MSAG database. The TN data record includes a "Function of Change" data field to indicate the type of processing that should be performed for this record. Processing rules for some of the "Function of Change" data values are described below:

Function of Change

Data Value:

C Change the corresponding record in the database. A data record must

Insert this data record into the database. There must not be another data record with the same TN (pANI) or calling number in the database or the insert will fail.

already exist in the database with the same TN (pANI) or calling number. The entire database record is replaced by the new data record, therefore the incoming record must have all appropriate data fields populated.

Delete the corresponding record in the database. A data record must already exist in the database with the same TN (pANI) or calling number.

Delete the corresponding record in the Error File. No processing is performed against the E911 database.

Processing Rules:

Page 33

Page 44

Wireless E911 Guide CG-EWCG-001 TN Database Updates Issue 3, January 6, 2004

5.10 Service Order Interface File Specifications

This section describes BellSouth Service Order Interface file specifications and Service Order Interface Record (SOIR) layouts. BellSouth SOIR layouts resemble the 512 character NENA Version 2 layouts for Data Exchange with some BellSouth specific differences. Files for updating the BellSouth E911 database must adhere to the following file specifications:

1. All files contain a single file header record, followed by one or more data records, followed by a single file trailer record. All records are 512 characters in length. Layouts are described in this tab.

2. All data must be in ASCII format.

3. All data must be in upper case.

4. Required fields must contain valid data. Required fields are indicated in the layouts with capitalized field names.

5. Optional fields may be space filled, unless otherwise noted, if data values are not available. Optional fields are indicated in the layouts with lower case field names.

5.11 SOIR File Data Record Layout

5.11.1 Table: SOIR File Data Record - BellSouth 512 Character Format for Data Exchange

Page 34

Page 45

CG-EWCG-001 Wireless E911 Guide

Issue 3, January 6, 2004 TN Database Updates

Type of activity the record is being

submitted for. Valid entries:

• C - Change

• D - Delete

• I - Insert

• E -Delete Error

• U - Unlock (LNP)

• M - Migrate (LNP)

Three(3) digit area code of the Calling

Number.

Seven(7) digit telephone number of the

Calling Number. For Wireless, pseudo

ANI of PSAPor antenna face receiving

wireless call.

House number. The field should be space

filled if no house number is available.

House number extension (e.g., 1/2). The

field should be space filled if suffix does

not apply. Do not lead with hyphen.

Leading street direction prefix.The field

should be space filledif no prefix applies.

Valid entries: N, S, E, W, NE, NW, SE,

SW.

Position Bytes Type BellSouth Description

Field Name

Database

Table E SOIR File Data Record - BellSouth 512 Character Format for Data Exchange

1 1

FUNCTION

CODE

7 N

- continued -

2-4 3

5-11

CALLING

NUMBER

(TN)

12 - 21 10

HOUSE

NUMBER

22 - 25 4

house number

suffix

prefix directional 26 - 27 2

Yes

Sent to PSAP Stored in

No No

Yes Yes NPA

Yes Yes

Yes - Only

eight(8)

characters sent

to PSAP.

Yes Yes

Page 35

Page 46

Wireless E911 Guide CG-EWCG-001

TN Database Updates Issue 3, January 6, 2004

MSAG valid service address of the

Calling Number, PSAP or Antenna

Site. Include street name, street suffix

(i.e.thoroughfare designation) and post

directional. Street Suffixes must conform

to BellSouth MSAG standards; valid

Post Directional entries are: N, S, E, W,

NE, NW, SE, SW.

EX: MAIN ST NW

Valid service community of the street

name / house number as designated by

the MSAG.

Alpha postal state abbreviation (e.g., AL,

FL, GA, KY, LA, MS, NC, SC, and TN).

Additional address information (free

formatted) describing the exact location

of the Calling Number (e.g., APT 718).

Field Name Position Bytes Type BellSouth Description

Database

Table E SOIR File Data Record - BellSouth 512 Character Format for Data Exchange (continued)

28 - 93 66

STREET NAME

STREET

Yes - Some

solutions

SUFFIX

POST

DIRECTIONAL

may change

this data via

dynamic

update

during

911 call

processing.

94 - 125 32

COMMUNITY

NAME

Yes - Some

solutions

may change

this data via

dynamic

update

during

911 call

STATE 126 - 127 2

processing.

location 128 - 187 60

Yes - Only

twenty(20)

characters

stored and

sent to

- continued -

PSAP.

Page 36

Sent to PSAP Stored in

Yes - Only 48

characters sent

to PSAP.EX:

Main St NW

Yes - Only 18

characters sent

to PSAP.

Yes Yes

Yes - Value of

G = Wireless

P1 (Sent

to PSAP

as WRLS).

Value of H =

Wireless P2

(Sent to PSAP

as WPH2)

Page 47

CG-EWCG-001 Wireless E911 Guide

Issue 3, January 6, 2004 TN Database Updates

G=Wireless P1

Carrier name associated with the Calling

Number.

Value of:

H=Wireless P2

Value of:

0=Not Non-Pub

3=Non-Pub

Phone company exchange identifier

for the serving telephone office of the

customer; ALEC and Wireless may be

blank.

Emergency Service Number associated

with theHouse Number and StreetName;

this field is blank on input and derived

from the MSAG validation process.

Area code of the Main Number

associated with the Calling Number. For

wireless, use same value as NPA field.

Main telephone number associated with

the Calling Number. For wireless use

same value as Calling Number field.

Field Name Position Bytes Type BellSouth Description

Database

Table E SOIR File Data Record - BellSouth 512 Character Format for Data Exchange (continued)

188 - 219 32

CUSTOMER

NAME

220 1

CLASS OF

Yes

SERVICE

221 1

TYPE OF

SERVICE

EXCHANGE 222 - 225 4

226 - 230 5

Yes esn

7 N

- continued -

231 - 233 3

234 - 240

NUMBER

Sent to PSAP Stored in

Yes Yes

Yes - Value of

G = Wireless

P1 (Sent

to PSAP

as WRLS).

Value of H =

Wireless P2

(Sent to PSAP

as WPH2)

No Yes

Yes - Only

three(3)

characters sent

to PSAP.

No No MAIN NPA

Yes Yes MAIN

Page 37

Page 48

Wireless E911 Guide CG-EWCG-001

TN Database Updates Issue 3, January 6, 2004

Service order number for the activity

establishing this record.

Date on which the record was created in

the format MMDDYY.

County Identification code (usually the

FIPS code). Will be blank on input and

derived from MSAG validation process.

Telephone Company Identification code

as assigned through NENA registration

process.

Code which indicateswhether data is part

of the initial database creation process or

part of the daily update process.

Daily = Space

Initial Load = C

Postal Zip Code.

Postal Zip Code Extension.

This field is mutually used by data

exchange partners to pass information

not defined in previous fields.

Code used to uniquely identify a

customer. For ICO, ALEC, and Wireless

companies this code can be blank on

input or filled with 999. TN processing

will convert all blanks to 999.

Optional notes

Field Name Position Bytes Type BellSouth Description

Database

Table E SOIR File Data Record - BellSouth 512 Character Format for Data Exchange (continued)

order number 241 - 250 10

251 - 256 6

EXTRACT

- continued -

287 - 289 3

DA TE

county identifier 257 - 260 4

COMPANY ID 261 - 265 5

source identifier 266 1

zip code 267 - 271 5

zip +4 272 - 275 4

general use 276 - 286 11

CUSTOMER

CODE

290 - 319 30

Page 38

Sent to PSAP Stored in

No Yes

Yes Yes

No Yes

No No

No Yes

No Yes comments

Page 49

CG-EWCG-001 Wireless E911 Guide

Issue 3, January 6, 2004 TN Database Updates

Longitude / X coordinate.

Field Name Position Bytes Type BellSouth Description

x coordinate 320 - 328 9

Latitude / Y coordinate.

y coordinate 329 - 337 9

Reserved for future use. Structure

elevation.

Reserved for future use. Identification

z coordinate 338 - 342 5

cell identifier 343 - 348 6

number indicating a geographic region

of cellular coverage.

Reserved for future use. Subset / section

sector identifier 349 1

of a cell.

Taxing Area Rate Code. ALEC and

TAR CODE 350 - 355 6

Wireless populate with zeros.

Remote Call Forward Number field;

356 - 365 10

remote call

Wireless Providers must send spaces; if

Wireless Provider has dynamic update

forward (rcf)

number

interface, or other providers send RCF,

mobile directory number or RCF will be

sent to PSAP following field identifier

of ALT#

This field is reserved for the processing

company’s use.

Always an asterisk (*)

512 1

reserved 366 - 511 146

END OF

RECORD

Database

Table E SOIR File Data Record - BellSouth 512 Character Format for Data Exchange (continued)

Sent to PSAP Stored in

Yes -

Dynamically

updated in

DB.

Yes -

Dynamically

updated in

DB.

Yes -

Dynamically

updated in

DB.

Yes -

Dynamically

updated in

DB.

No No

No Yes

Yes Yes

No No

Page 39

Page 50

Wireless E911 Guide CG-EWCG-001 TN Database Updates Issue 3, January 6, 2004

5.12 SOIR File Header Record Layout

5.12.1 Table: SOIR File Header Record - BellSouth 512 Character Format for Data Exchange

Field Name

HEADER

Position

Bytes Type BellSouth Description

1-5 5

INDICATOR EXTRACT DATE 6-11 6 COMPANY NAME CYCLE COUNTER

12-61 50 62-67 6

county identifier 68-71 4

state

72-73 2

general use 74-93 20

release number 94-96 3

format version 97 1

reserved 98-511 414

END OF RECORD

512 1 Always "*"

5.13 SOIR File Trailer Record Layout

N N

Always "UHL "

Date formatted as MMDDYY

New customers start at 000001; each subsequest file cycle is incremented by 1 until reaching 999999

5.13.1 SOIR File Trailer Record - BellSouth 512 Character Format for Data Exchange

Field Name

TRAILER

Position Bytes Type BellSouth Description

1-5 5

Always "UHL "

INDICATOR EXTRACT DATE 6-11 6 COMPANY NAME 12 - 61 50 RECORD COUNT

62 - 67 6

Date formatted as MMDDYY

Does not include header and trailer record

END OF RECORD

Page 40

reserved 98 - 511 414

512 1 Always "*"

Page 51

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Database Updates

5.14 Mechanized File Transfer

The Service Order Interface Record (SOIR) is the TN database information that is mechanically transmitted to INTRADO for inclusion in the E911 database. If the Wireless Carrier data file passes all validity checks, it will be processed to the E911 database.

PLEASE NOTE: THE PREFERRED METHOD OF DATA TRANSMISSION IS CONNECT:MAILBOXTM,A PRODUCT OFFERED THROUGHINTRADO. OTHER METHODS OF DATA TRANSMISSION MAY BE SUPPORTED BY INTRADO. PLEASE COORDINATE THROUGH THE BST WIRELESS IMPLEMENTATION MANAGER AND INTRADO.

Establishment of CONNECT MAILBOXTM to the INTRADO system will be coordinated through the BST Wireless E911 Implementation Manager / INTRADO. Once established, support for Connect MailboxTM will be handled by INTRADO.

Connect Mailbox™ Client for Windows requires the following minimum system requirements:

• Microsoft Windows Version 3.1 or later

• 4MB of Memory

• 2MB of Hard Disk Space (3MB During Installation)

• VGA or Better Card with a Color Monitor

• Hayes Compatible Modem with full Carrier Detect Support

• Utilizes Z Modem as the interface protocol

INTRADO will work with customers that wish to use an alternative client product, so long as that product supports X-Modem, Z-Modem, or Kermit.

5.15 Mechanized File Confirmations

When an file is sent, a check will be made to determine if any errors exist in the header, data, or trailer records. If no errors are detected, a positive response will be sent via mechanized fax to the Wireless Carrier. The positive confirmation detail record is shown below:

Page 41

Page 52

Wireless E911 Guide CG-EWCG-001 TN Database Updates Issue 3, January 6, 2004

If an error is detected, an error confirmation notice will be sent via mechanized fax. The following error conditions will be detected:

• Record Count Mismatch

• Cycle Mismatch

• Header Record Not Found

• Trailer Record Not Found

The error confirmation notice is shown below:

Page 42

Page 53

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Errors and Corrective Action

6. TN Errors and Corrective Action

6.1 Overview

This section provides procedures for correcting errors that are generated when updates to the E911 database do not pass database edits. Records that fail the edits will be sent daily in an error report to the Wireless Carrier. Errors are sorted in TN order and an error code is provided on each error to aid the Carrier in identifying the erroneous information.

Wireless Carrier error records will not be manually corrected or processed to the E911 database. A corrective SOIR must be issued to update the TN information in the E911 database and / or to delete the error record as appropriate. The records which error wireless data to be included in the E911 database.

The Wireless Carrier is expected to resolve the errors by:

• Issuing Address Verification Requests (AVR) to the E911 Coordinator for MSAG changes.

• · Issuing corrective SOIRs within 24 hours of receipt.

must be corrected as quickly as possible for the

6.2 Electronic Error Delivery

Errors are delivered to the Wireless Carrier’s Intrado Connect Mailbox. Confirmation files and Statistics files with information on error records and records that have processed successfully are generated .

6.2.1 The Confirmation Report

The Confirmation reports list the daily update records that are in error, along with a three-digit error code. The error code descriptions and corrective action are provided in this tab. (Note: Only records in error are included on this report. If the record has successfully processed and posted in the ALI database it will not be included on this report.)

Example of the Confirmation report is shown below. The record layout for electronic errors is in NENA Version 2 format. There is a three (3) digit error code located at the end of the record in reserved fields 378-380 followed by an "E" to indicate the record is in error.

Page 43

Page 54

Wireless E911 Guide CG-EWCG-001 TN Errors and Corrective Action Issue 3, January 6, 2004

Table F Confirmation Report Fields and Descriptions

FIELD DESCRIPTION

FUNCTION CODE Valid codes are:

• : I=Insert

• C=Change

• P=Main account delete

• E=Error delete

• U=Unlock

• M=Migrate NPA CALLING

Three(3) digit number of Calling Number Seven(7) digit number of Calling Number

NUMBER HOUSE NUMBER House Number. The field should be spaced filled if no house

number is available.

HOUSE NUMBER SUFFIX

PREFIX DIRECTIONAL

House number extension (e.g. /2). The field should be spaced filled if no suffix applies.

Leading street direction prefix. The field should be spaced filled if no prefix applies. Valid entries: N, S, E, W, NE, NW, SE, SW

STREET NAME Valid street address of the Calling Number.

Page 44

STREET SUFFIX Valid street abbreviation. POST

DIRECTIONAL

Trailing street direction suffix. The field should be spaced filled if no suffix applies. Valid entries: N, S, E, W, NE, NW, SE, SW

- continued -

Page 55

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Errors and Corrective Action

Table F Confirmation Report Fields and Descriptions (continued)

COMMUNITY NAME

Valid service community of the street name/house number as

designated by the MSAG. STATE Alpha state abbreviation LOCATION Additional address information (free formatted) describing the

exact location of the Calling Number (e.g. APT 718). CUSTOMER

Subscriber name associated with the Calling Number. NAME

CLASS OF SERVICE

Value of:

• 8=Moble (pre-Phase 1)

• G=Wireless Phase 1

• H=Wireless Phase 2 (with X,Y)

TYPE OF SERVICE

Value of:

• 0=Not Non-pub or FX

• 1=FX not Non-pub

• 2=Not used

• 3=Non-pub, not FX

• 4=Non-pub, FX

• 5=Not Used

EXCHANGE Local Exchange Carrier exchange identifier for the serving

telephone office of the customer. MAIN NPA

Three(3) digit area code of the Main Number associated with

the Calling Number. MAIN NUMBER

Seven(7) digit telephone number of the Main Number associated

with the Calling Number. ORDER NUMBER Service order number for the activity establishing this record. EXTRACT DATE Date for which the record was created in the form MMDDYY COUNTY ID County Identification Code (usually the FIPS code). COMPANY ID NENA registered Company Identification Code. SOURCE ID Indicates whether data is part of the initial database creation

process or part of the daily update process.

• Daily = Space

• Initial Load = C ZIP CODE Postal Zip Code ZIP+4 Postal Zip Code Extension

- continued -

Page 45

Page 56

Wireless E911 Guide CG-EWCG-001 TN Errors and Corrective Action Issue 3, January 6, 2004

Table F Confirmation Report Fields and Descriptions (continued)

GENERAL USE Mutually used by data exchange partners to pass information

not defined in previous fields.

CUSTOMER

Code used to uniquely identify customer.

CODE COMMENTS Optional notes may be displayed at PSAP X COORDINATE Longitude / X coordinate Y COORDINATE Latitude / Y coordinate Z COORDINATE Structure elevation CELL ID Identification number indicating a geographic region of cellular

coverage. SECTOR ID Sub set / section of a cell. TAR CODE Taxing Area Rate Code RESERVED Positions 356-511 are reserved. Positions 378-380 are used by

Intrado to populate the three(3) digit error code (e.g. 709). END OF RECORD Always an asterisk (*)

6.2.2 The Statistics Report

The Statistics Report provides information about the processed daily update records The top portion of the report shows the number of records received, followed by the number of records in error, and the number of inserts, changes and deletes that were successfully processed. The bottom portion of the report lists all the valid error codes for the BellSouth region and the number of errors with that error code. Example of the Statistics Report is shown below.

Page 46

Page 57

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Errors and Corrective Action

Figure 2 The Statistics Report

6.2.3 Distribution of Daily Reports

Intrado forwards daily reports electronically each business day. The Saturday and Sunday Confirmation and Statistical reports are included in Monday’s cycle. To retrieve reports after sending a file: (1) return

Page 47

Page 58

Wireless E911 Guide CG-EWCG-001 TN Errors and Corrective Action Issue 3, January 6, 2004

to Intrado Connect, (2) click on the transfer key, and (3) click on the download key and automatically retrieve your reports.

6.2.4 TN Error Deletion

When a SOIR is processed, a check is made to determine if an error record exists in the error file with the same TN on the SOIR. If an error record other than a U (Unlock) or M (Migrate) exists, the error record will be deleted and the TN will be processed to the E911 Database if the subsequent SOIR is successful. If an error other than for a U (Unlock) or M (Migrate) SOIR occurs while processing the subsequent SOIR, a new error record will be written to the error file, thus only one SOIR record should ever be present in the error file for any given TN.

TN error records requiring deletion will be deleted by issuing a subsequent SOIR with an FOC = "E". When the FOC = "E" on the subsequent SOIR, the error file will be searched for a match on TN and, if found, the error will be deleted from the error file. SOIRs sent with a FOC of "E" are used ONLY to delete a TN from the error file and are not processed to a matching TN embedded record in the E911 database. An example of a situation where an "E" FOC might be used is to delete a TN error record where the original SOIR had been with an invalid TN.

6.3 Error Codes and Error Descriptions

The following error codes may be generated and sent via fax. Note: If an error code is received that is not reflected in this guide, please refer to the BellSouth

Wireless E911 Implementation Manager.

Table G Error Codes and Error Descriptions

ERROR DESCRIPTION

100 Customer Code not numeric 101 NPA/NXX not valid 103 Main TN not numeric 105 Name Missing 106 Address Missing 107 House number contains invalid characters 108 House number is too long 109 Street direction is too long 110 Street Direction is invalid

Page 48

111 Street name is too long

- continued -

Page 59

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Errors and Corrective Action

Table G Error Codes and Error Descriptions (continued)

ERROR DESCRIPTION

112 Street name has invalid characters 113 Community Name is too long 114 Community Name has invalid characters 115 Service class invalid 116 House Number Suffix is too long 120 TN is incorrectly formatted 126 Invalid type of service 701 House number is not in MSAG range 702 Record already exists, insert not allowed 704 Record does not exist for delete 705 Main record not found for delete 709 Street not found in MSAG 710 customer code doesn’t match on change 711 Customer code or street name does not match on delete 712 Record does not exist for change 713 TN and Main Account mismatch 729 Change failed, completion date conflict with disconnect file 730 Insert failed, completion date conflict with disconnect file 731 Change failed, completion date conflict with TN database 732 Record in disconnect with greater completion date 735 Delete failed, record in TN database has same completion date 738 MSAG update caused TN error 739 Invalid house number format 741 Update not allowed; flagged for PS / ALI 751 Invalid Function Code 752 Invalid Company ID 753 No record exists on Unlock 754 No record exists on Lock 755 Unable to migrate a locked record

- continued -

Page 49

Page 60

Wireless E911 Guide CG-EWCG-001 TN Errors and Corrective Action Issue 3, January 6, 2004

Table G Error Codes and Error Descriptions (continued)

ERROR DESCRIPTION

756 Company Code mismatch on Change 757 Company Code mismatch on Delete 758 Company ID mismatch on Unlock 760 Lock exceeded number of retries 762 U or M Function Required for LNP 781 Error record does not exist for delete 782 Company Code mismatch on error delete 783 Unlock failed; Main account has sublines 792 Record exists with a Company Code mismatch

6.4 Error Code and Corrective Action

Table H Error Codes and Corrective Action

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

100 Customer Code not

numeric

101 NPA / NXX not

valid

103 Main TN not

numeric

105 Name missing The customer name field on the incoming

106 Address missing The address field on the incoming SOIR

A character other than 999 is sent in the customer code field of the incoming record

The incoming record contains a NPA / NXX combination that is not valid E911 database tables

The main telephone number shown on the SOIR is non-numeric

SOIR is blank

is blank

Issue corrective SOIR for errored TN showing 999 in the customer code field

Determine if NPANXX is correct and

• If correct, submit NXX Table UpdateForm to INTRADO and resubmit I FOC SOIR for TN

• If incorrect, submit E FOC SOIR to delete TN error and submit new SOIR for correct TN

Submit E FOC SOIR to delete invalid TN error and resubmit new SOIR for correct TN

Issue corrective SOIR for errored TN with correct customer name

Issue corrective SOIR for errored TN with correct MSAG valid street address.

Page 50

- continued -

Page 61

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Errors and Corrective Action

Table H Error Codes and Corrective Action (continued)

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

107 House number

contains invalid characters

108 House number is too

long

109 Street direction is

too long

110 Street direction is

invalid

111 Street name is too

long

112 Street name has

invalid characters

113 Community name is

too long

The house number on the incoming SOIR contains characters other than alpha or numeric.

The house number on the incoming SOIR contains too many characters

The directional prefix for the street on the incoming SOIR contains too many characters

The directional prefix for the street on the incoming SOIR contains invalid characters

The street name with thoroughfare and suffix on the incoming SOIR contains too many characters

The street name for the street on the incoming SOIR contains invalid characters

The community name on the incoming SOIR contains too many characters

Determine the correct MSAG valid house number and submit corrective SOIR for errored TN

Determine the correct MSAG valid street name and submit corrective SOIR for errored TN

Determine the correct MSAG valid community name for the street address and submit corrective SOIR for errored TN

114 Community

name has invalid characters

115 Service Class

Invalid

116 House number

suffix is too long

120 TN is incorrectly

formatted

126 Invalid type of

service

The community name for the street on the incoming SOIR contains invalid characters

The incoming record has an invalid class of service

Thehouse number suffixon the incoming SOIR contains too many characters

The TN on an incoming SOIR is not made up of ten numeric characters.

The type of service on an incoming SOIR contains a type of service value other than 0 or 3

- continued -

Determine the correct MSAG valid street name and community and submit corrective SOIR for errored TN

Submit corrective SOIR with valid class of service

Determine the correct house number suffix and submit corrective SOIR for errored TN

Check the NPANXX in the record for all numeric and no blanks. Submit E FOC with NPANXX of errored TN to delete error record then re-submit SOIR with correct TN

Submit SOIR with valid type of service, 0or3

Page 51

Page 62

Wireless E911 Guide CG-EWCG-001 TN Errors and Corrective Action Issue 3, January 6, 2004

Table H Error Codes and Corrective Action (continued)

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

701 House number is not

in MSAG range

702 Record already

exists, insert not allowed

The house number on the incoming SOIR is not found in the house number range for the street and community on the MSAG

The SOIR has a FOC of I and attempts to insert a TN into the database that already exists

Determine if the street range exists in the MSAG.

• If the house number on the SOIR is correct but is not in the MSAG, issue an AVR to the E911 coordinator to update the MSAG house number range

• If the house number on the SOIR is incorrect issue a SOIR with the correct house number that matches the MSAG house number range

Using the image of the existing record that is sent with the error, determine if the existing database TN is incorrect or if the SOIR error is incorrect.

• If the existing database TN is incorrect, resubmit the SOIR with a FOC of C to overlay the existing data with the SOIR data

• If the error record TN is incorrect, resubmit a SOIR with FOC of E to delete the errored record and then resubmit another SOIR for the correct TN

704 Record does not

exist for delete

705 Main account record

not found for delete

The TN for the incoming SOIR does not exist in the database

The main account TN on the incoming SOIR does not exist in the database

- continued -

Determine if the account has been disconnected:

• If disconnected, submit E FOC SOIR to delete error record

• If error record was issued for invalid TN, submit E FOC SOIR to delete error record and resubmit new D FOC SOIR for correct TN

Determine if the account has been disconnected:

• If disconnected, submit E FOC SOIR to delete error record

• If error record was issued for invalid TN, submit E FOC SOIR to delete error record and resubmit new D FOC SOIR for correct TN

Page 52

Page 63

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Errors and Corrective Action

Table H Error Codes and Corrective Action (continued)

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

709 Street not found in

MSAG

710 Customer code

doesn’t match on change

711 Customer code or

street name does not match on delete

The directional prefix, street name, community or state on the incoming SOIR cannot be found in the MSAG

The customer code shown for the incoming SOIR doesn’t match the customer shown on the existing database record

The customer code, directional prefix, street name and suffix on the incoming SOIR does not match the TN in the database

Determine if the street exists in the MSAG:

• If the prefix, street, community and state shown on the error record is not found in the MSAG issue an AVR to the E911 Coordinator to have the MSAG updated (Note: Once the MSAG is updated the error record will process and load.)

• If the prefix, street, community or state on the error record is incorrect and a valid MSAG entry exists, resubmit a corrective SOIR

Determine the correct customer code and resubmit corrective SOIR with customer code of 999 or blanks

Using the image of the existing record that is sent with the error, determine if the TN in the database should be deleted

• If the existing database TN is should be deleted, resubmit a correct D FOC SOIR

• If the existing database TN should not be deleted and the error record TN is incorrect, resubmit a SOIR with FOC of E to delete the errored record and then resubmit another SOIR for the correct TN

712 Record does not

exist for change

The incoming C FOC SOIR TN is not found in the TN database

- continued -

Determine if the error record TN is valid:

• If error record TN is valid, no action is necessary. Processing in the TN database will change the C FOC to an I FOC and insert the record.

• If the error record TN is invalid, resubmit a D FOC SOIR to delete the TN from the TN database and then resubmit the C FOC SOIR for the correct TN

Page 53

Page 64

Wireless E911 Guide CG-EWCG-001 TN Errors and Corrective Action Issue 3, January 6, 2004

Table H Error Codes and Corrective Action (continued)

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

713 TN and main

account mismatch

729 Change failed,

completion date conflict with disconnect file

730 Insert failed,

completion date conflict with disconnect file

731 Change failed,

completion date conflict with TN database

Themain account shownon the incoming SOIR doesn’t match the main account shown on the database record.

An incoming SOIR contains a completion date that is equal to or earlier that the completion date of the record that has been deleted

The incoming insert SOIR is for a TN that has been disconnected and the date on the insert SOIR is the same or prior to the date of the disconnected TN.

The incoming change SOIR has a completion date that is the same or prior to the date of the TN shown in the database

Submit D FOC on existing database record to delete TN with different main account and IFOC with appropriate changes on corrective SOIR showing the TN and the main account as the same number.

Determine if TN is valid and should be changed

• If TN is valid submit corrective SOIR with changes showing a completion date that is later than the disconnect date

• If the TN is invalid, submit E FOC to delete error record

Determine if the insert record should have posted prior to the disconnect:

• If yes, issue E FOC SOIR to delete the error record

• If no, issue resubmit I FOC SOIR with completion date later than disconnect date

Determine the correct sequence of order activity for the TN:

• If the error record change is correct, resubmit C FOC SOIR with later completion date

• If error record is incorrect, submit E FOC SOIR to delete error record

732 Record in

disconnect with greater completion date

Page 54

The incoming change SOIR has a completion date that is the same or prior to the date of the TN in the disconnect file

- continued -

Determine the correct sequence of order activity for the TN:

• If the error record change is correct, resubmit C FOC SOIR with later completion date

• If error record is incorrect, submit E FOC SOIR to delete error record

Page 65

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Errors and Corrective Action

Table H Error Codes and Corrective Action (continued)

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

735 Delete failed, record

in TN database has same completion

738 MSAG update

caused a TN error

739 Invalid house

number format

741 Update not allowed,

flagged for PS-ALI / PinPoint

751 Invalid function

code

The incoming delete SOIR has a completion date that is the same completion date of the TN in the database

This error is not generated as a result of incoming SOIR but is generated when INTRADO performs a MSAG update that deletes the address shown on the TN record

The incoming SOIR contain special or invalid characters for an alpha or alphanumeric house number

The TN on the incoming SOIR belongs to a TN that is shown for a PS / ALI or PinPoint PBX customer

The incoming SOIR contains an invalid function code. Valid function codes are:

• C = CHANGE

• D = DELETE

• I = INSERT

• E = DELETE ERROR

• U = UNLOCK

• M = MIGRATE

Determine the correct sequence of order activity for the TN:

• If the error record delete is correct, resubmit D FOC SOIR with later completion date

• If error record is incorrect, submit E FOC SOIR to delete error record

Contact INTRADO Data Analyst for resolution.

Determine correct house number for TN and resubmit correct SOIR

Submit E FOC SOIR to delete error record

Resubmit the SOIR with valid function code

752 Invalid company ID The incoming SOIR has an invalid

NENA ID

753 No record exists on

unlock

The TN on the incoming unlock SOIR does not exist in the TN database

- continued -

Resubmit the SOIR with a valid NENA ID

Determine if the correct TN was sent on the error record:

• If correct, submit IFOC SOIR for TN and then resubmit U FOC SOIR

• If incorrect, submit E FOC SOIR to delete error record

Page 55

Page 66

Wireless E911 Guide CG-EWCG-001 TN Errors and Corrective Action Issue 3, January 6, 2004

Table H Error Codes and Corrective Action (continued)

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

754 No record exists on

lock

755 Unable to migrate

locked record

756 Company code

mismatch on change

The TN on the incoming Migrate SOIR does not exist in the database.

The TN in the database for the incoming Migrate SOIR shows a locked status

The NENA ID on the incoming C FOC SOIR does not match the NENA ID of the TN record in the database

Determine if the error record TN is valid:

• If error record TN is valid, no action is necessary. Processing in the TN database will change the M FOC to an I FOC and insert the record.

• If the error record TN is invalid, resubmit a E FOC SOIR to delete the error record

Determine if the error record TN is valid:

• If valid, contact the donor company to issue an unlock SOIR. The error record will process once the unlock SOIR is received.

• If the error record TN is invalid, resubmit a E FOC SOIR to delete the error record

Determine if the error record NENA ID is valid:

• If valid, contact the donor company to issue an unlock SOIR and resubmit the SOIR as a M FOC with the appropriate changed data

• If the error record NENA ID is invalid, resubmit a E FOC SOIR to delete the error record

757 Company code

mismatch on delete

Page 56

The NENA ID on the incoming D FOC SOIR does not match the NENA ID of the TN record in the database

- continued -

Determine if the error record NENA ID is valid:

• If valid, contact the donor company to issue an unlock SOIR and resubmit the SOIR as a M FOC to migrate the record and the a subsequent D FOC to delete the TN record

• If the error record NENA ID is invalid, resubmit a E FOC SOIR to delete the error record

Page 67

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 TN Errors and Corrective Action

Table H Error Codes and Corrective Action (continued)

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

758 Company code

mismatch on unlock

760 Lock exceeds

number of retries

762 NENA ID required

for U or M FOC SOIR

781 Error record does

not exist for delete

The NENA ID on the incoming U FOC SOIR does not match the NENA ID of the TN record in the database

The 755 error for a Migrate order is unsuccessful for 30 days

The incoming U or M SOIR does not have a valid three(3) to five(5) digit NENA ID

The incoming E FOC TN cannot be found in the error database

Determine if the error record NENA ID is valid:

• Contact the donor company to issue an unlock SOIR

• Resubmit the SOIR as a M FOC to migrate the record

• Resubmit a subsequent U FOC to unlock

If the error record NENA ID is invalid, resubmit a E FOC SOIR to delete the error record

No action required. INTRADO will take appropriate action based on dial tone ownership as shown in NPAC. Carrier will receive notification of action taken for the TN on the weekly NPAC Validation report.

Submit E FOC to delete SOIR record from error Resubmit correct U or M SOIR with valid NENA ID

Verify the TN on the E FOC SOIR record matches the TN in the error database:

• If TN matches, no action required. The errored record has been previously deleted or resolved.

• If TN doesn’t match re-submit E FOC SOIR for correct TN

782 Company code

mismatch on error delete

The incoming E FOC TN contains a NENA company ID that does not match the NENA ID shown on the TN in the error database

- continued -

Verify the NENA ID on the E FOC SOIR record matches the TN in the error database:

1. If NENA ID matches, no action required. The errored record has been deleted or resolved.

2. If NENA ID doesn’t match re-submit E FOC SOIR for correct NENA ID

Page 57

Page 68

Wireless E911 Guide CG-EWCG-001 TN Errors and Corrective Action Issue 3, January 6, 2004

Table H Error Codes and Corrective Action (continued)

ErrorCode Error Message Occurs when. . . Corrective Action for . . .

783 Unlock failed; main

account has sublines

The incoming U FOC TN is in the database as a main account with other TNs shown as sublines but no U FOC was received on the sublines(Note: Since the main account and Calling number TN are to be the same TN, this error would be receivedonly if the TN in the database had been submitted with a different main account on a previous SOIR.)

792 I FOC record exists

with a different Company ID

The TN shown on the I FOC SOIR has a different NENA Company ID than the existing TN in the database

6.5 Compiled Error Report

There are two possible correctiveactions:

1. If all accounts shown with the main account are to be unlocked submit a U FOC for each TN associated with the original main account.

2. If all accounts are not to be unlocked submit a D FOC for the existing subline showing the erroneous main account and then resubmit an I FOC for the TN shown with the Calling number TN as the main account.

Verify the TN on the errored record:

• If the TN is correct and is to be migrated, submit an E FOC on the error record SOIR and then resubmit a corrective SOIR with appropriate record changes as a M FOC

• If the TN on the error record is incorrect, submit an E FOC to delete the error record.

As stated earlier in this tab, it is imperative that all errors must be corrected as soon as possible. Until an error is corrected, the information will either be in the database incorrectly or not in the database at all. This could result in E911 calls being directed to the wrong PSAP and having to be transferred to the appropriate PSAP.

In addition to sending the daily errors, a compiled error report will be forwarded to each Carrier on a monthly basis in an effort to ensure that the Carrier is aware of all unresolved daily errors. The error report is sorted in street name order to aid in resolving address errors.

Page 58

Page 69

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 PSAP Inquiries

7. PSAP Inquiries

7.1 Overview

E911 is a critical emergency service. Therefore, any address condition that interferes with a caller reaching the appropriate PSAP, and having an accurate display, must be corrected as quickly as possible. For this reason, the E911 Inquiry Form has been developed as a tool for the PSAP attendants to use in reporting address problems encountered with the E911 system.

Wireless Carriers will receive E911 Inquiry Forms from the E911 Customer (county) or INTRADO. Inquiry forms should be logged by the Carrier. A PSAP Inquiry Log form and instructions are provided in this tab. Once the inquiry has been handled, it should be returned to the originator. If the originator of the inquiry is unknown, the form should be returned to INTRADO.

The E911 Inquiry Form is divided into five (5) sections. (sample on the following page)

GENERAL: information relating to the PSAP attendant preparing the form DATABASE: problems relating to the ALI data displayed at the PSAP REPAIR: COMMENT: input of additional pertinent information ACTION: response section

problems relating to the network or equipment

Page 59

Page 70

Wireless E911 Guide CG-EWCG-001 PSAP Inquiries Issue 3, January 6, 2004

7.2 PSAP Inquiry Form

Page 60

Figure 3 PSAP Inquiry Form

Page 71

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 PSAP Inquiries

7.3 PSAP Inquiry Log

The following is an example of a PSAP Inquiry Log and instructions for completion:

Figure 4 PSAP Inquiry Log

7.3.1 Instructions for Completing PSAP Inquiry Log

1. Serial Number Enter the serial number assigned by the E911 Customer

2. Date Received Enter the date the Inquiry was received

3. NPA / Telephone Number

4. 911 Call Date Enter the date of the 911 call

5. Action taken Enter the action taken to handle the inquiry

Enter the NPA and telephone number being referred on the Inquiry

- continued -

Page 61

Page 72

Wireless E911 Guide CG-EWCG-001 PSAP Inquiries Issue 3, January 6, 2004

- continued -

6. Date Returned Enter the date the Inquiry was returned to the originator

Response Code Enter the appropriate response code as follows:

• Trouble Cleared, Enter date

• No trouble found

• Referred to repair

7.4 Inquiry Flow

Inquiry Forms that involve the "Database Reason For Inquiry" will be forwarded to the Carrier for investigation and resolution. The inquiry form should be logged by the wireless carrier and the disposition noted. A PSAP Inquiry Log form and instructions are provided in this tab. Once the inquiry has been resolved, it should be returned to the originator. Inquiries received from INTRADO should be returned to:

FAX: 888-778-7876 INTRADO, Inc. BellSouth NDSC 1601 Dry Creek Drive Longmont, CO 80503

7.5 Investigation Procedures

7.5.1 ALI Record Not Found

The Carrier should investigate to determine why the pseudo-ANI record is not in the database. If the TN is found on the NRF Report, check to see if the TN is a valid pseudo-ANI number. If valid, a SOIR should be sent to insert the pseudo-ANI TN record. If it is determined that the TN record is in the error file, a corrective SOIR should be sent to resolve the error. Once resolved, check action: "Trouble cleared as of (enter the date) and return the form to the originator.

7.5.2 Wrong ALI Display Of:

The E911 Customer will complete the "Should Be" section detailing correct information on the E911 Inquiry form, when the ALI displays incorrect information. The Carrier should investigate the discrepancies and make the appropriate database updates as described below.

7.5.3 Address — Community — Location

Investigate as necessary with the E911 Customer to determine the correct address including a check for MSAG validity. Update the address information for the pseudo-ANI record by submitting a corrected SOIR with the valid information. Once resolved, check action: "Trouble cleared as of (enter the date)" and return the inquiry to the originator. If no change is needed to the pseudo-ANI TN record, check action: "Investigation Completed. No action required as of (Enter the date)" and return the inquiry to the originator.

Page 62

Page 73

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 PSAP Inquiries

7.5.4 ESN

Investigate as necessary with the E911 Customer to determine the correct address. Update the address information for the pseudo-ANI TN record by submitting a corrected SOIR with the valid information. Once resolved, check action: "Trouble cleared as of (enter the date)" and return the inquiry to the originator. If it is determined that the pseudo-ANI address is correct, check action: "Trouble Referred to Other on (Enter date)". These Inquiry Forms should be returned to INTRADO for investigation. If it is determined that a correction in the pseudo-ANI TN record is necessary, INTRADO will contact the wireless carrier for a new SOIR to be sent.

7.5.5 Misroutes

A misroute indicates the E911 call routed to the wrong PSAP. Routing is determined by the ESN associated with the matching address record in the MSAG database. Investigate as necessary with the E911 Customer to determine the correct address. The E911 Customer should be able to assist with identifying the MSAG valid address and the associated ESN to route the calls to the desired PSAP. Update the address information for the pseudo-ANI TN record by submitting a corrected SOIR with the MSAG valid information. Check action: "Trouble cleared as of (enter the date)" and return the inquiry to the originator. If it is determined that the pseudo-ANI address is correct, check action: "Trouble Referred to Other on (Enter date)". These Inquiry Forms should be returned to INTRADO for investigation. If it is determined that a correction in the pseudo-ANI TN record is necessary, INTRADO will contact the wireless carrier for a new SOIR to be sent.

7.6 Blank Forms

Blank Forms may be reproduced locally as needed. An example of a PSAP Inquiry Log follows.

Page 63

Page 74

Wireless E911 Guide CG-EWCG-001 PSAP Inquiries Issue 3, January 6, 2004

7.6.1 PSAP Inquiry Log

Page 64

Figure 5 PSAP Inquiry Log

Page 75

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 No Record Found (NRF) Processing

8. No Record Found (NRF) Processing

8.1 Overview

A No Record Found (NRF) condition occurs when a subscriber calls 911 and no database information exists for the cell site pseudo-ANI telephone number. The purpose of an NRF investigation is to:

• identify the reason a NRF occurred

• take corrective action to update the database as necessary

There are several reasons a record may not be available for retrieval:

• the record may be in the Error File

• the record may not have posted between the time the cell site has been "turned up" and the time the record is processed and entered into the database

• the update SOIR file transmission may have failed to complete successfully

• the record may not have been sent to be inserted into the database

It is imperative the Wireless Carriers ensure all appropriate pseudo-ANI records are successfully posted to the E911 database before conducting 911 call testing or turning up service. Wireless 911 calls processed without corresponding pseudo-ANI records in the database will result in NRFs at the PSAP and manual investigation by the INTRADO Data Integrity Unit.

8.2 No Record Found (NRF) Processing

Each PSAP in the region is served by a primary ALI processor and secondary ALI processor. These processors alternate responses to ALI retrieval requests (bids) coming from the PSAP. Therefore, audit data, including NRF data, is found on the audit files from both the primary and secondary ALI processors. This data is combined to produce one NRF report.

8.3 No Record Found (NRF) Report Schedule

The NRF report will be generated every day, Sunday through Saturday. This report provides information about NRFs for investigation. NRF details will appear on the report once the appropriate carrier is identified.

The following schedule has been developed for the generation of daily NRF reports. The NRF report will be faxed daily (Monday-Friday) to the appropriate Carrier or data provider.

Fri / Sat / Sun’s NRFs NRF reports distributed on Monday Monday’s NRFs NRF report distributed on Tuesday

- continued -

Page 65

Page 76

Wireless E911 Guide CG-EWCG-001 No Record Found (NRF) Processing Issue 3, January 6, 2004

- continued -

Tuesday’s NRFs NRF report distributed on Wednesday Wednesday’s NRFs NRF report distributed on Thursday Thursday’s NRFs NRF report distributed on Friday

8.4 No Record Found (NRF) Report Layout

The NRF report is separated by Wireless Carrier and by state and sorted by telephone number. A summary is provided for numbers of NRFs. Following is an example of the NRF report:

The NRF Report will include:

Company: Wireless Carrier name in report heading Run Date:

Date and time of NRF report creation State: Two(2) character state identifier TN:

Pseudo-ANI number, including NPA, which resulted in NRF Bid Date: Date, time, and day of week of PSAP query (bid) that resulted in

NRF County Name: Name of couty for the PSAP receiving NRF PSAP ID: Two(2) character State identifier, 8 - 10 character PSAP name and

four(4) character PSAP ID of agency that received the NRF Status: Status of referral: OPENED, PENDERR, REF - LEC Total NRFs: Total number of NRFs

8.5 NRF Investigation

The Wireless Carrier will only be required to investigate and correct NRFs that are not found in the E911 database or if the record was in the error file at the time of the 911 call.

The Wireless Carrier should:

Page 66

• Determine if the TN should be in the E911 database.

Page 77

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 No Record Found (NRF) Processing

• If the TN should be in the database, a SOIR should be submitted to insert the TN record or to resolve an outstanding error in the error file.

• Research why the record was not in the database and take action to prevent further NRF occurrences.

• Advise INTRADO to close the NRF if the TN has been disconnected or not needed in the database

When all NRFs on a report have been resolved, the Wireless carrier should file the NRF report and retain for a period of one(1) year from the date of the 911 call that resulted in the NRF.

Status codes are assigned to each TN on the No Record Found Report. All NRFs are initially assigned as “OPENED”. The status can be changed by the INTRADO Data Analyst as resolutions are completed. “CLOSED” will be assigned as soon as the investigation is complete and the E911 database is updated.

The Analyst will assign “REF — LEC” when the investigation cannot be completed in the time frame which the Analyst began their work. This status would be typical when additional information or action is required from the Carrier.

The STATUS notations are described as: Pending — In Error File (PENDERR) — Telephone number was found in the error file and has been referred to Wireless Carrier for resolution of the error condition. Referred to LEC (REF — LEC) — The NRF has been referred to the Carrier for resolution. The Telephone number is not in the TN database or the error file.

If the record is found in the E911 database, the event will be “CLOSED” and the NRF will not be forwarded to the Carrier. If the TN is found in the error file, the status will be changed to “PENDERR” and will be included in the NRF report. The Carrier should resolve the outstanding error to prevent further NRFs from occurring. If the record is not found in the E911 database or error file, the status will be changed to REF — LEC and the report provided to the Carrier for resolution.

Page 67

Page 78

Wireless E911 Guide CG-EWCG-001

Issue 3, January 6, 2004

Page 68 - Blank

Page 79

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 NENA Company Registration Process

9. NENA Company Registration Process

9.1 NENA Cmpany ID Registration Service

Wireless Service Providers and the FCC mandate placed upon them for delivery of location information and the wireless subscribers callback number generates a need in 9–1–1 service for identification of the relationship between the telecommunication company and telephone number. This need is driven by two factors:

Data Base Management

• supports tracking in 9–1–1 data record processing and quality management by both the 9–1–1 service provider and the data source Company

• administration and management of error processes with multiple data providers

Speed of identification by PSAPs

• when a PSAP needs to quickly contact the originating Company for line interrupt, call trace, and other emergency actions, the typical use of the NPA-NXX for Company identification will no longer be effective

• an identifier that can be applied to each telephone number record is needed to support individual telephone number portability

• a Company ID that associates 24 Hour access numbers with each telecommunications company is needed for the above functions

9.2 Purpose of the NENA Company ID Registration Service

A national Company ID for 9–1–1 service will allow the PSAP to identify the Wireless Carrier serving the caller, and to determine the 24 x 7 number of that Carrier for emergency contact needs. In the Company ID database description, (below), each Carrier would identify one ID for each service area supported by the same 24 x 7 contact number. If the Carrier has a national switching center that would take calls form PSAPs for emergency assistance, the Carrier would need only one Company ID.

A national 9–1–1 Company ID registration point was recommended by NENA Standards work groups in 1996, and subsequent work has been directed to making this service a part of the NENA Web Site, for general access. This approach is intended to support standardization of 9–1–1 Company Identifiers, and to supply a single point of administration for the Company ID file content and update.

Use of the Internet allows telecommunications companies, state, county, city, and PSAP to access and use the ID information. In addition, the design of this service allows each telecommunications company to assign multiple IDs, so that individual service areas and 24 hour contact information can be identified.

Note: Use of the previously established NECA code was considered for the above functions.

However, NECA codes are numeric and not as immediately interpretable as are alpha IDs. In addition, NECA codes do not apply to certain types of 9–1–1 call providing entities, such as resellers and PBX operators, that are needed in 9–1–1 applications.

Page 69

Page 80

Wireless E911 Guide CG-EWCG-001 NENA Company Registration Process Issue 3, January 6, 2004

9.3 Use of the Service

For your convenience, NENA has created an online Company Identifier Data Base Input Form that you can either print out and fill in or you can complete it online, hit the submit button, and you will be invoiced for the fee. The NENA Web page address is http://www.nena9–1–1.org/companyid. C

ere to access website

lick

If you choose to print it out and fill it in, please send it or fax it to the address / fax below: FAX: 614–933–0911 Address: 422 Beecher Road, Columbus, OH 43230

An annual fee of $100 will apply for each ID registered by NENA.It is recommended that the Company Identifier be one that a public safety telecommunicator can readily interpret. A 3–5 character contracted spelling of the Company name is usually possible. The Company’s choice for an Identifier is likely to be accepted by NENA, provided that it is not already registered by another Company.

9.4 Instructions

The chosen Company ID code structure should be alpha ONLY using upper case characters. All IDs in the data base must be unique and the must be limited to 3–5 characters.

The 24 hour by 7 day telephone number should be a number that will allow the safety agencies to contact the Carrier’s switching support center for line interrupts, call traces, or other emergency contact reasons.

The area covered by the 24 x 7 number may be national, regional, a single state, or other combinations. Please concisely indicate coverage area in the “Area Supported” field by the use of 2–character state abbreviations, or “ALL” to indicate all US States. This will allow searching the “Area Supported” field for those Companies registered in a given area.

Please call NENA at 800–332–39011 if you have any questions.

9.4.1 Input Form

Company Identifier Data Base

Page 70

Page 81

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 NENA Company Registration Process

Figure 6 Input Form

Page 71

Page 82

Wireless E911 Guide CG-EWCG-001

Issue 3, January 6, 2004

Page 72 - Blank

Page 83

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 Reconciliation

10. Reconciliation

10.1 Overview

Wireless Carriers or their agents are granted an extract of their E9-1-1 data annually for database reconciliation. The BellSouth Implementation Manager offering a yearly reconciliation of data sends a letter and extract request form to each company in the first quarter of the year. This document outlines the procedures used to request a data extract for the purpose of reconciliation.

10.2 Notification and Scheduling

Complete the "9-1-1 Database Reconciliation Extract Request" form that was attached to the annual letter and return it to the INTRADO Continuous Improvement Analyst via mail or fax. The INTRADO Continuous Improvement Analyst will contact you and negotiate an extract date.

10.3

The Wireless Carrier or their agent is responsible for:

• Requesting the Data Extract.

• Reconciling their data by comparing the extract file with data currently maintained within their carrier database.

• Sending updates as required to the E9-1-1 database via Service Order Interface (SOI)

INTRADO is responsible for:

• Scheduling Data Extracts.

• Determining Extract dates.

Page 73

Page 84

Wireless E911 Guide CG-EWCG-001

Issue 3, January 6, 2004

Page 74 - Blank

Page 85

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

A. BellSouth Wireless E9–1–1/SS7 Interconnection Guide

A.1 BellSouth Wireless E-9–1–1/SS7 Interconnection Guide

This document is intended to provide an explanation of how SS7/ISUP trunks can be used for delivery of Wireless E9-1-1 calls in the BellSouth E9-1-1 serving area.

NOTE: The need to provide and maintain the reliability and integrity of E9-1-1 service is a top priority. Therefore, deployment/implementation of SS7/ISUP trunking for E9-1-1 is subject to due date negotiation between BellSouth and any interconnection customer. The migration onto this newer signaling technology cannot be subject to the Customer Desired Due Date (CDDD) processes.

NOTE:Failure to deploy SS7/ISUP signaling correctly for Wireless E9-1-1 may result in significant service interruptions or undesirable anomalies, including but not limited to a total inability to complete the call.

NOTE: This document uses acronyms and terms as described in the NENA Master Glossary of E9-1-1 Terms available at http://www.nena9-1-1.org in the NENA Recommended Technical Standards section.

ere

Click h

to access this information.

NOTE: All interconnecting carriers need to be familiar with and in compliance with TR 73554 Issue D, December 2002 (or later), BST GUIDELINES TO TECHNICAL PUBLICATION GR-905-CORE. The BST CCS Network has its own particular architectural variations and technological capabilities. TR 73554 is a supplement to GR-905.) TR 73554 is available through the appropriate BellSouth Interconnection Services Account Representative.

Before any new device is connected to the BellSouth Common Channel Signaling Network (CCSN) it must meet the following two requirements:

1. It must have undergone and passed MTP Level 2 and Level 3 protocol testing by Telcordia or other suitable independent lab testing facility

2. It must have undergone and passed interoperability testing at the Bellsouth Technology Assessment Center (BTAC) in Birmingham

This does not include Level 3 protocol testing on new links from known switch types (#5ESS, DMS100, etc.). SS7 is a mature technology and, over the years, there have been only rare occasions of mismatches at the Level 3 protocol. These differences have typically been non-traffic affecting differences in timer settings. For these reasons BellSouth has taken the position that the continued investment in time and Level 3 protocol test equipment would be imprudent. However, any other type of devices (e.g., PBXs, VMS host machines, packet switching devices, etc.) that are not routinely connected to the network, will be asked to undergo lab testing with a "standards" lab such as Telcordia or BTAC. We acknowledge there may be some carriers who don’t undergo such lab testing, and we reserve the right to remove them from our CCSN without prior notice if their equipment causes us or any of our customers a problem.

A.2 Executive Summary

BellSouth provides Wireless Carriers with connectivity to its Enhanced 9-1-1 Selective Routing network so they may meet their (FCC mandated) responsibility to provide Enhanced 9-1-1 service to their customers.

Page 75

Page 86

Wireless E911 Guide CG-EWCG-001 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Issue 3, January 6, 2004

NENA (National Emergency Number Association) has published a Technical Information Document: "NENA 05-501 Technical Information Document on SS7 Guidelines for MSC to Selective Router Connectivity." (available at: h

ttp://www.nena9-1-1.org/9-1-1TechStandards/tech_info_docs.htm ). That document identifies many of the possible call setup parameter options that can occur within the enhanced 9-1-1 network on an SS7/ISUP trunk between a Wireless Service Provider’s MSC and an Enhanced 9-1-1 selective router. The use of SS7 signaling greatly reduces post dial delay and also provides more reliable ANI delivery when compared to traditional MF signaling. (Throughout this document the term SS7 is to be construed to mean SS7/ISUP signaling.)

As a high level statement, the intent of this BellSouth Wireless E9-1-1/SS7 Interconnection Guide is to list the call setup parameters shown in the NENA 05-501 TID that are supported by BellSouth, so wireless carriers can chose the one(s) that best meet their needs.

This documentation will identify, to the Wireless Service Provider, the parameters they need to populate in their 9-1-1 Signaling System #7 Initial Address Message (SS7 IAM) to provide Phase 1 or Phase 2 E9-1-1 service to their customers.

NOTE: Wireless service providers who desire to take advantage of the SS7 signaling format for E9-1-1 service should contact their BellSouth Account Representative to begin a test and installation plan or to discuss technical information.

This document identifies only SS7 signaling options supported for E9-1-1 trunk interconnection. SS7 interconnection for E9-1-1 is a service choice made by the wireless carrier, and does not limit, reduce, or eliminate the current option to deliver E9-1-1 calls to BellSouth using traditional CAMA-MF or FG-D signaling protocols.

A.2.1 Identified Options:

Section 4 of the NENA 05-501 document describes the various combinations of the call setup parameters. Three Call Signaling Scenarios representing the four common Wireless E9-1-1 Solutions defined in Section 3 of the NENA 05-501 TID are as follows:

• Call Signaling Scenario (1) ESRK delivery

• Call Scenario 2, CBN and ESRD Delivery - WITHOUT a hybrid

• Call Scenario 2, CBN and ESRD Delivery - WITH a hybrid

• Call Signaling Scenario (3) CBN, ESRD, and GLP (Geodetic Location Parameter) delivery

NOTE:This BellSouth document further clarifies those NENA 05-501 descriptions by distinguishing between Call Signaling Scenario (2) CBN and ESRD Delivery without a hybrid architecture at the SR; and Call Signaling Scenario (2) CBN and ESRD Delivery WITH a hybrid architecture at the SR. The NENA 05-501 authors elected to allow companies (like BellSouth) who offer a hybrid solution to define their hybrid solution in their own documents. This document does that for BellSouth’s hybrid offering.

A.2.1.1 Call Scenario 1, ESRK Delivery

BellSouth supports the following options as listed in table 4-1 (ESRK Delivery) in "NENA 05-501 Technical Information Document on SS7 Guidelines for MSC to Selective Router Connectivity":

Page 76

Page 87

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

A1, A2, A3, B1, B2, and B3 are supported using the E911_STD trunk options on the BellSouth Nortel DMS E9-1-1 Tandem (Referred to as NDET throughout this document.). For all practical purposes these calls appear to be like wireline calls at the NDET.

A.2.1.2 Call Scenario 2, CBN and ESRD Delivery - WITHOUT a hybrid: (WITHOUT a hybrid architecture at the Selective Router)

BellSouth supports the following options as listed in table 4-2 (CBN and ESRD Delivery) in "NENA 05-501 Technical Information Document on SS7 Guidelines for MSC to Selective Router Connectivity": A1, A2, B1, B2, C1, C2, D1, D2 are supported using the E911_STD or WRLS_STD trunk options on the BellSouth NDET. The strongly preferred, and recommended, trunk option is WRLS_STD because it is seen as the standard for wireless E9-1-1 calls. A3, B3, C3, D3 are supported using the E911_STD trunk option only. E1, E2, F1, F2, G1, G2, H1, H2, I1, I2, J1, J2, K1, K2, L1, L2 are supported using ONLY the WRLS_CLD option on the NDET. Option I3 is

NOT SUPPORTED on the NDET platform.

NOTE: Call scenario 2 is sometimes called "20 digits to the PSAP". In Phase 1 it was known as Callpath

Associated Signaling (CAS). In Phase 2 (according to J-STD-036-A) it is known as Non-Callpath Associated Signaling (NCAS).

A.2.1.3 Call Scenario 2, CBN and ESRD Delivery - WITH a hybrid: (WITH a hybrid architecture at the Selective Router)

NOTE: Call scenario 2 is sometimes called "20 digits to the PSAP". In Phase 1 it was known as Callpath Associated Signaling (CAS). In Phase 2 (according to J-STD-036-A) it is known as Non-Callpath Associated Signaling (NCAS).

NOTE: Call Scenario 2, CBN and ESRD Delivery - WITH a hybrid is available on ALL of BellSouth’s (64) NDETs.

A.2.1.4 Call Scenario 3, CBN, ESRD and GLP Delivery: (GLP = Geodetic Location Parameter)

BellSouth does not support this method at this time due to the inability of the selective router platform and the MSC platforms to use and/or route on the GLP, or to support ISDN PSAPs in an industry standard manner.

Page 77

Page 88

Wireless E911 Guide CG-EWCG-001 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Issue 3, January 6, 2004

A.2.2 Database Steering Options

The NENA 05-501 document also defines data base steering options that are used to interconnect the wireless carrier’s network with the BellSouth Enhanced 9-1-1 ALI Database systems. BellSouth will support the data steering options referred to as "E2" and "E2+", as defined in BellSouth Technical Reference TR 73610, and in the Intrado technical document "BellSouth SR/ALI to MPC Interface Specifications for TCP/IP Implementation of TIA/EIA/J-STD-036 E2" (Contact Intrado for the latest issue supported on BellSouth ALI Data Base systems).

WARNING

The MOST IMPORTANT thing this document can relay is the following: IT IS IMPERATIVE THATALL PARTIES UNDERSTAND WHAT IS REQUIRED TO MAKE WIRELESS E9-1-1 WORK PROPERLY IN AN SS7/ISUP ENVIRONMENT. Any questions or doubts that the WSPs Network/Translations Engineer may have, should be brought to the attention of BellSouth BEFORE proceeding with any provisioning steps. The WSPs BellSouth Account Representative will arrange to get answers to any questions from the appropriate BellSouth Network/Translations E9-1-1 personnel. The WSP (or their agent) must have the ALI database pre-populated with records matching the pANIs (ESRD/ESRK) they will use, or the call will default route, and the PSAP will receive a "no record found" rather than the expected location information. Failure to deploy SS7/ISUP signaling correctly for Wireless E9-1-1 may result in significant service interruptions or undesirable anomalies, including but not limited to, a total inability to complete the call.

A.3 Scope and introductory text

A.3.1 Wireless E9-1-1 Service Introduction

Wireless E9-1-1 service enables Wireless Service Providers (referred to as WSP or WSPs throughout this document) to comply with the FCC mandate for providing an Enhanced 9-1-1 service to wireless users that is somewhat equivalent to the service provided to landline users. FCC Docket 94-102 requires WSPs to make E9-1-1 service available in two phases. The first phase of 94-102 (Phase I, initially effective April 1,

1998) requires each WSP to provide a Public Safety Answering Point (PSAP) with the caller’s Call Back Number (CBN), and a "general" location of the caller equivalent to the serving cell site or sector, but only if the PSAP requests Phase I service in writing and is capable of receiving and utilizing the data.

That general location is represented by a 10 digit number generally known as a psuedoANI (pANI), but also known as Emergency Services Routing Digits (ESRD) or Emergency Services Routing Key (ESRK) based on the type of wireless E9-1-1 solution in use. From the BellSouth E9-1-1 Tandem’s point of

Page 78

Page 89

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

view, this general location number is simply used to determine which PSAP should receive the call. This document will use the term pANI generically, except where it is more appropriate to use ESRD or ESRK. Other industry documents specify which precise term is applicable for different situations, but that distinction is beyond the scope or intention of this document.

The second phase of 94-102 (Phase II, initially scheduled to begin October 1, 2001) requires each WSP to be able to deliver a wireless 9-1-1 call with Phase I requirements, plus longitude and latitude coordinates of the caller, accurate to within 150 meters or less, depending on the technology used for location determination. Originally, WSPs were to begin to make wireless Phase II available by October 1, 2001 to qualified PSAPs that requested Phase II service by April 1, 2001. After April 1, 2001, the WSPs were to begin to make Phase II available to qualified PSAPs within six months of a receiving their request for Phase II service. The FCC modified the original start date in late 2001. Generally speaking, Phase 2 began in late 2002, and it is expected to roll out continually until ubiquitous coverage is provided across all of the USA.

The "BellSouth Wireless E9-1-1 Solution" (aka: WLS911) currently supports Phase I service by allowing a wireless carrier to send the caller’s CBN and the pANI directly to a BellSouth Nortel DMS E9-1-1 Tandem switch (NDET) using dedicated FG-D Multi-Frequency signaling trunks. This Solution can also serve as the underlying architecture to support a WSP in becoming Phase 2 compliant, if they chose to deploy their own architecture in a manner that accommodates delivery of longitude and latitude coordinates to a PSAP through the BellSouth ALI database, once they are obtained over an "E2" interface, as described in J-STD-036-A (BellSouth will also support the modification of E2 generally known as E2+).

In the BellSouth hybrid scenario the CBN and pANI would continue to be transported through the BellSouth E9-1-1 Network to the PSAP using WLS911, and the longitude and latitude coordinates would be obtained through the BellSouth ALI database, across an E2 interface provided by the WSP. BellSouth does not provide the E2 interface transport facilities. There are also other technical/architectural "Solutions" available in the industry for a WSP to become Phase 1 and/or Phase 2 compliant. Those solutions are beyond the scope of this document, but BellSouth does permit such alternative Solutions to be used via our Network.

NOTE: J-STD-036-A describes Phase II standards in greater detail. BellSouth will support E2 functionality in the manner fully described in the Intrado document "BellSouth SR/ALI to MPC Interface Specifications for TCP/IP Implementation of TIA/EIA/J-STD-036 E2" (Contact Intrado for the latest issue supported on BellSouth ALI Data Base systems.

Partly due to the E9-1-1 industry’s migration into Wireless Phase II, and also due to other recent and future (anticipated) technological developments in the E9-1-1 industry in general, BellSouth will begin (in 2004) to allow the use of Common Channel Signaling (CCS) technology to support Wireless E9-1-1 service.

NOTE: This capability will be thoroughly tested in each instance before it is made available for use.

A.4 Reason for Revision

If this document is revised, this section will summarize the change(s).

A.5 Organization of this Document

This document is to be used in conjunction with the following publications:

Page 79

Page 90

Wireless E911 Guide CG-EWCG-001 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Issue 3, January 6, 2004

• TR 73554 Issue D, December 2002 (or later), BST GUIDELINES TO TECHNICAL PUBLICATION GR-905-CORE (Telcordia document GR-905-CORE specifies the interfaces required to interconnect out-of-band Common Channel Signaling (CCS) networks that utilize the Signaling System Number 7 (SS7) protocol provided by a different CCS Network. The BST CCS Network will have its own particular architectural variations and technological capabilities. Therefore, the intent of the TR 73554 is to supplement GR-905.)

• NENA 05-501, NENA Technical Information Document on SS7 Guidelines for MSC to Selective Router Connectivity, Original Issue, October 2002. The NENA 05-501 Technical Information Document (TID) provides a reference for Wireless Service Providers (WSP) on the basics of E9-1-1 SS7 translations to the Selective Router (SR). It was issued to address the obvious need for guidance on SS7 translations between the MSC and the SR. It presents a broad view of the E9-1-1 related SS7 translations that exist today (2002), and possible ones for the future.

NOTE: This BellSouth Wireless E9-1-1/SS7 Interconnection Guide document references configurations detailed in the NENA 05-501 SS7 Guidelines for MSC to Selective Router Connectivity TID. The two documents should be used together to gain a more clear understanding of the requirements surrounding using SS7/ISUP supported trunking for wireless E9-1-1 in BellSouth’s E9-1-1 serving area.

• J-STD-036-A Enhanced Wireless 9-1-1 Phase 2. This Joint Standard has been issued and approved by the Telecommunications Industry Association and the Alliance for Telecommunications Industry Solutions, June 2002. This joint standard defines the messaging required to support information transfer to identify and locate wireless emergency services callers.

• NENA 03-006, RECOMMENDED STANDARDS FOR E9-1-1 CALL CONGESTION MANAGEMENT. This NENA document provides additional details regarding how to establish the proper quantity of Wireless trunks into an E9-1-1 Tandem based on generally accepted "best practices".

• "BellSouth SR/ALI to MPC Interface Specifications for TCP/IP Implementation of TIA/EIA/J-STD-036 E2" (Contact Intrado for the latest issue supported on BellSouth ALI Data Base systems). This is an Intrado document that fully describes the Intrado SR/ALI E2 messaging interface. This is the interface that BellSouth is using!

Specific "Wireless E9-1-1" interconnection requirements for the CCS network interconnection architecture and the interface protocol for call setup are defined in this BellSouth Wireless E9-1-1/SS7 Interconnection Guide document. This document will define the interconnection requirements in the BellSouth E9-1-1 Network when using SS7/ISUP in concert with one of the various Wireless E9-1-1 options identified in J STD-036-A, and in the NENA 05-501 and 03-006 documents.

The MOST IMPORTANT thing this document can relay is the following:

IT IS IMPERATIVE THAT ALL PARTIES UNDERSTAND WHAT IS REQUIRED TO MAKE WIRELESS E9-1-1 WORK PROPERLY IN AN SS7/ISUP ENVIRONMENT.Any questions or doubts that the WSPs Network/Translations Engineer may have, should be brought to

the attention of BellSouth BEFORE proceeding with any provisioning steps. The WSPs BellSouth Account Representative will arrange to get answers to any questions from the appropriate BellSouth Network/Translations E9-1-1 personnel.

Page 80

Page 91

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

The WSP (or their agent) must have the ALI database pre-populated with records matching the pANIs (ESRD/ESRK) they will use, or the call will default route, and the PSAP will receive a "no record found" rather than the expected location information.

A.6 Wireless CCS Network Interconnection Architecture

A.6.1 General Interconnection Information

Signaling System 7 - Common Channel Signaling using ISDN User Part protocol (SS7/ISUP) for Wireless E9-1-1 is only supported for Type 2C trunks (interconnected directly to a BellSouth E9-1-1 tandem switch) as defined in GR-145-CORE. The Type 2C trunks shall be dedicated for Wireless E9-1-1 traffic. There will always be a minimum of two trunks per trunk group. Ideally, they should be provisioned in a diverse manner so that a single network fault or incident would not render both trunks inoperable. In sizing the new SS7/ISUP TG, Wireless Network Planners should build toward providing a P.01 Grade Of Service (GOS) (see NOTE below).

NOTE:

The NENA document, NENA 03-006, RECOMMENDED PROCEDURES FOR E9-1-1 CALL CONGESTION MANAGEMENT provides additional details regarding how to establish the proper quantity of Wireless trunks into an E9-1-1 Tandem based on generally accepted "best practices". ( 03-006 is pending publication on the NENA web site at h

ttp://www.nena9-1-1.org as of March 25, 2003)

If a WSP elects to provide direct MF trunks to be used as backup in the event of an SS7 failure, BellSouth can support such an arrangement. If MF backup is used, the quantity of MF trunks will be determined by WirelessNetwork Planning practices, but in no case will it be less than two trunk members per TrunkGroup (TG). Since CAMA-MF only delivers a 7 digit pANI, CAMA-MF Trunk Groups are to be provisioned on a per NPA basis. FG-D MF signaling allows for delivery of a full 10 digit pANI number, along with a full 10 digit CBN, so FG-D MF Trunk Groups can be provisioned to carry multiple NPAs as long as all default routed calls should route to the same PSAP. CAMA-MF requires NPA specific trunk groups so the NDET can "build" a 10 digit pANI upon receipt of only 7 digits across the NPA specific trunk group.

All trunk groups (p

rimary and back-up) must take into account that only ONE default PSAP can be associated with an E9-1-1 Trunk Group. It is imperative that the Wireless Network Planner keep this in mind when determining how many trunk groups will be needed for service in any given area.

THAT DECISION CAN HAVE SIGNIFICANT IMPACT ON PSAPs.

As mentioned above, when sizing the new SS7/ISUP TG, Wireless Network Planners should build toward providing a P.01 GOS. The size of the backup MF TGs shall be a minimum of two, but otherwise may not necessarily achieve a P.01 GOS, since they are not expected to be frequently called upon. They are after all - ONLY INTENDED FOR BACKUP!

A.6.2 Wireless Phase 1 vs. Phase 2

It is VERY important that all parties understand that differences of opinion (currently) exist in regard to the meaning of certain terms used in the Wireless E9-1-1industry at large. Most are just slight nuance differences, but if two or more people use the same term to mean different things it causes confusion. This section will attempt to clarify how BellSouth interprets certain Phase 1 and Phase 2 terms, especially in

Page 81

Page 92

Wireless E911 Guide CG-EWCG-001 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Issue 3, January 6, 2004

regard to how they are used in this document. There may be significant impact to Wireless E9-1-1 service if the Wireless Engineer fails to understand these differences during establishment of initial interconnection using SS7/ISUP for wireless E9-1-1.

Generally speaking, the term CAS (Callpath Associated Signaling) means the same thing in Wireless Phase 1 and Phase 2. In each case, ALL of the FCC mandated data is carried directly from the WSPs MSC through the BellSouth E9-1-1 Tandem to the PSAP. In Phase 1, CAS includes two (significant) data elements, the CBN and the pANI. In Phase 2, CAS includes those two elements as well as the longitude/latitude coordinates of the caller (aka: x, y) when they dialed 9-1-1 on their wireless device. Phase 2 CAS requires SS7/ISUP between the MSC and the BellSouth E9-1-1 Tandem, and ISDN to the PSAP. As of 3Q2002 Phase 2 CAS is NOT supported in BellSouth. (ISUP Initial Address Message Parameter Contents for CAS are fully described in J-STD-036-A, Annex-D, Section D.1.3)

In Phase 1, NCAS includes two (significant) data elements: the pANI and the CBN. In Phase 1 NCAS, ONLY the pANI is sent directly from the WSPs MSC through the BellSouth E9-1-1 Tandem to the PSAP (with the callpath). The CBN is added to the existing pANI record in the BellSouth ALI-DB by the WSP or their agent during call setup, using an out-of-band signaling path (hence NCAS). The updated pANI ALI record including the CBN & cell/sector address data is delivered to the PSAP through the BellSouth ALI database using the BellSouth Standard ALI format. (The various NCAS architectures are beyond the scope of this document. See J-STD-034 and each NCAS vendor’s own documents for details.)

In Phase 2, NCAS includes those same two (significant) data elements as well as the longitude/latitude coordinates of the caller when they dialed 9-1-1 on their wireless device (and potentially can include updated data upon demand). However, in Phase 2, NCAS (as defined in J-STD-036-A, Annex-D, Section D.1.2) includes BOTH the CBN and the pANI being sent directly from the WSPs MSC through the BellSouth E9-1-1 Tandem to the PSAP. In this instance the PSAP obtains the longitude/latitude coordinates through the BellSouth ALI database (using the BellSouth Extended ALI format) via the WSPs E2 interface. (The various E2 interface architectures are beyond the scope of this document. See J STD-036-A and Intrado’s "BellSouth SR/ALI to MPC Interface Specifications for TCP/IP Implementation of TIA/EIA/J-STD-036 E2" for details).

In Phase 2 there is an alternative method of data delivery that J-STD-036-A refers to as Wireline Compatibility Mode (WCM), which ONLY sends the pANI (ESRK) directly from the WSPs MSC through the BellSouth E9-1-1 Tandem to the PSAP (Sounds like Phase 1 NCAS doesn’t it? Hence the terminology confusion!). In WCM the CBN and the longitude/latitude coordinates are added to an existing pANI record in the BellSouth ALI-DB during the call by the WSP or their agent using an out-of-band signaling path defined as an E2 interface. An updated Phase 2 compliant pANI ALI record including the CBN, cell/sector address data and longitude/latitude coordinates is delivered to the PSAP through the BellSouth ALI database using the BellSouth Extended ALI response format. If the x, y coordinates of the caller are unknown at the time the updated pANI ALI record is created, the WSP (or their agent) is expected to fall back to a Phase 1 compliant record that would include the CBN & cell/sector address data. (The E2 interface architecture and operations are beyond the scope of this document. See J-STD-036-A, and Intrado’s "BellSouth SR/ALI to MPC Interface Specifications for TCP/IP Implementation of TIA/EIA/J-STD-036 E2" for details.)

In BellSouth there is another alternative method of data delivery that is structured upon the J-STD-036-A NCAS Solution in Phase 2, or on J-STD-034 CAS in Phase 1. In either case it is a 20 digits to the PSAP type solution. However, this 20 digit solution can be used between the MSC and the NDET even if the PSAP is not capable of receiving 20 digits from the NDET. This is accomplished by using the BellSouth

Page 82

Page 93

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Wireless E9-1-1 Solution (WLS911), a Hybrid architecture functional in both Phase 1 and Phase 2 environments. WSPs should see their BellSouth account team for details on how the WLS911 Solution may be of value in their overall architecture plans.

A.7 Interface Protocol for Wireless Call Setup when using SS7/ISUP signaling.

A WSP choosing to interconnect with SS7 trunks using ISUP signaling in support of delivery of Wireless E9-1-1 calls shall comply with one of the following three signaling options available in the BellSouth E9-1-1 Network. On the BellSouth NDET switches the options are known as "WRLS_STD" or "WRLS_CLD" or "E911_STD". Any one of these three can be supported on the BellSouth NDET switches on a per incoming trunk group basis.

designations on various Wireless switches.) NOTE: The WRLS_STD signaling option is used when the pANI is located in the Generic Digits (GDP)

Parameter. Calling Party Number is used as the callback number. Charge Number is ignored by the NDET. This is the industry standard for wireless calls on the NDET.

The WRLS_CLD signaling option is used when the pANI is located in the Called Party Number parameter, instead of the digits 9-1-1. Calling Party Number is used as the callback number. Charge Number is ignored by the NDET. Generic Digits (GDP) Parameter IS NOT ALLOWED!

(They would of course be known by other nomenclature

Depending on which signaling option is chosen, the WSP will send an Initial Address Message (IAM) containing the following parameters when sending a wireless E9-1-1 call to a BellSouth E9-1-1 tandem:

• Calling Party Number Parameter

• Called Party Number Parameter

• Generic Digits (GDP) Parameter (NOT allowed if the WSP uses WRLS_CLD)

• Charge Number Parameter

NOTE: Although Charge Number Parameter is allowed as an optional parameter, it is ignored by the NDET when using either of the WRLS_xxx signaling options.

• Calling Party Category Parameter

• Originating Line Information Parameter Calling Party Number Parameter

A.7.1 Calling Party Number

The Calling Party Number parameter value is variable depending upon which trunk group signaling option is being used. If the intention is to achieve Wireline Compatibility Mode (using E911_STD), the Calling Party Number parameter shall contain the pANI that will be used for Selective Routing, and will be sent to the PSAP to retrieve additional call data via the ALI database path. Otherwise, in either of the WRLS_xxx signaling options the Calling Party Number parameter shall contain the caller’s CBN (or a number being used as a substitute when the CBN is unknown).

The wireless carrier shall specify the contents of the Calling Party Number (i.e., the CBN or a pANI) at the time the trunk group is ordered (via their BellSouth account team using form RF-1004-WS). Once a trunk group is provisioned, the wireless carrier shall adhere to their choice (i.e., a trunk cannot signal the CBN for one call and a pANI for another call).

Page 83

Page 94

Wireless E911 Guide CG-EWCG-001 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Issue 3, January 6, 2004

A.7.2 Calling Party Number Parameter

Calling Party Number is a required parameter in the IAM. The Called Party Number parameter value is variable depending upon which trunk group signaling option is being used. In any case it shall either contain the digits "911" or a pANI.

The Called Party Number parameter includes the digits "911" when the pANI is provided in the Generic Digits Parameter (WRLS_STD signaling option), or when the Calling Party Number contains the pANI (E911_STD for Wireline Compatibility Mode).

The Called Party Number parameter contains the pANI when the Generic Digits Parameter

is not

used, but Wireline Compatibility Mode is not desired (WRLS_CLD signaling option). The need to use WRLS_CLD may be a result of a situation where the WSP switch cannot support a GDP parameter. In that case the pANI would appear in the Called Party Number parameter. If a WSP switch can support a GDP, and if

s not

Wireline Compatibility Mode i

desired, then the GDP is the recommended place to put the pANI

(WRLS_STD signaling option). The wireless carrier shall specify the contents of the Called Party Number (i.e., the digits "911" or a pANI)

at the time the trunk group is ordered (via their BellSouth account team using form RF-1004-WS). Once a trunk group is provisioned, the wireless carrier shall adhere to their choice (i.e., a trunk cannot signal the digits "911" for one call and a pANI for another call).

Called Party Number is a required parameter in the IAM.

A.7.3 Generic Digits Parameter & GDP Type

The Generic Digits Parameter (if required) shall contain a pANI. The "type of digits" field in the Generic Digits Parameter shall be coded 01101 (decimal 13) for cell site and sector identification. A Generic Digits Parameter is conditionally required in the IAM.

A Generic Digits Parameters

hall be included in the IAM when a wireless carrier chooses to send the digits "911" in the Called Party Number parameter (WRLS_STD signaling option). If a WSP switch can support a GDP, and if Wireline Compatibility Mode is not desired, then the GDP is the recommended place to put the pANI.

A GDP shall NOT be included in the IAM if the Calling Party Number or the Called Party Number parameter contains the pANI.

The wireless carrier shall specify whether a Generic Digits Parameter will be included in the IAM at the time the trunk group is ordered (via their BellSouth account team using form RF-1004-WS). Once a trunk group is provisioned, the wireless carrier shall adhere to their choice (i.e., a trunk cannot include a GDP for one call and not for another call).

Generic Digits Parameter is a conditionally required parameter in the IAM.

In all cases where GDP is used, "type of digits" must equal "13". Delivery of a pANI in a GDP that isn’t type 13 will not work as intended.

Page 84

Page 95

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

A.7.4 Charge Number Parameter

If present, the Charge Number parameter shall contain the caller’s CBN or the non-dialable callback number, or in Wireline Compatibility Mode it shall contain the pANI. Charge Number is an optional parameter in the IAM.

Charge Number is an optional parameter in the IAM. NOTE: Charge Number Parameter is ignored by the NDET when using either of the WRLS_ xxx

signaling options.)

A.7.5 Calling Party Category Parameter (CPC, aka: CPCat)

The Calling Party Category parameter shall be coded as 11100000 (decimal 224) for "emergency service call".

Calling Party Category is a required parameter in the IAM.

NOTE:

The Calling Party Category parameter encoding "emergency service call" is not required on all E9-1-1 tandem switches and may be waived in some instances. WSPs seeking to waive this requirement should consult their BellSouth representative. See Attachment "A" for details

A.7.6 Originating Line Information Parameter

For call scenarios #2, and #3 (with or without a hybrid architecture at the Selective Router), the Originating Line Information parameter shall be coded either as 00111101 (decimal 61) for "cellular services (type1)," 00111110 (decimal 62) for "cellular services (type2)," or 00111111 (decimal 63) for "cellular services (roaming)." The OLI parameter carries the II digits defined by the NANP administrator. The OLI parameter and the II values can be found in T1.113 (ANSI ISUP standard). Telcordia has also listed the wireless II values (61, 62, and 63) in the E9-1-1 SS7 generic requirements document GR-2956.

For call scenario #1, (WCM) the Originating Line Information parameter shall be coded either as 00 (POTS).

Click here to view call scenarios. Originating Line Information is a required parameter in the IAM. The Originating Line Information parameter is not required on all E9-1-1 tandem switches and may

be waived in some instances.

NOTE:

WSPs seeking to waive this requirement should consult their BellSouth representative. See Attachment "A" for details. BellSouth NDETs running software NA016 or higher will require the OLI parameter IF AIN OFF-BOARD SELECTIVE ROUTING IS BEING USED.

Page 85

Page 96

Wireless E911 Guide CG-EWCG-001 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Issue 3, January 6, 2004

A.8 Cross Reference Tables to J-STD-036-A

The intention of this section is to provide a method for a WSP to assess which type of BellSouth supported SS7/ISUP signaling option can best fit their needs. Each decision MUST take into account the capability of the WSPs MSC and the capability of the PSAP CPE, and may be impacted by the type of ALI steering options involved.

The following pages in this section represent the different interconnection scenarios that are described in J-STD-036-A for Wireless E9-1-1 Phase 2.

A.8.1 Wireline Compatibility Mode (NDET uses signaling option E911_STD)

If the WSP will be using a Wireless E9-1-1 Phase 1 Non Callpath Associated Signaling (NCAS) Solution, as described in J-STD-034 or Wireless E9-1-1 Phase 2 Wireline Compatibility Mode, as described in J-STD-036-A to deliver the Call Back Number (CBN) and/or x, y coordinates to the PSAP via the ALI database, Table "A" below describes an acceptable interconnection method (known as Wireline Compatibility Mode in , as described in J-STD-036-A). In this interconnection method ONLY the pANI is sent into the BellSouth NDET, directly from the WSPs MSC over dedicated trunks. The pANI is used by the NDET for selective routing, and then the pANI is sent to the PSAP the same way ANI would be on a landline call. That may be as an 8 or 10 digit number, depending on the capability of the PSAP CPE.

The NCAS or WCM Solution provider is expected to create a record in the BellSouth ALI database that will contain the CBN (among other data normally included by the NCAS provider, which may or may not also include Phase 2 data). That activity is beyond the scope of this document.

Extracted in part from Annex D: of J-STD-036-A, clarified for use in BellSouth. Table "A" ISUP Initial Address Message Parameter Contents for Wireline Compatibility Mode (ESRK).

In this mode only the ESRK is sent as the ANI o

ver dedicated trunks to the Selective Router because the

trunk between the Selective Router and the PSAP supports transport of only one 7/10 digit number.

Orreq Parameters ISUP Parameters Value

Digits(Dialed) Called party number (911) (see Note 1 below) MDN (aka: CBN) Calling party number (see Note 2

ESRK

below)

DMH_BillingDigits Charge Number (see Note 2

ESRK

below)

GenericDigits Generic digits parameter (see Note

3 below)

NOT ALLOWED (see Note 3 below)

GeographicPosition Calling geodetic location n/a n/a Originating Line Information

(OLI)

If included, use value 00 (POTS)

NOTES:

Page 86

Page 97

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

1. For an ESC, the ISUP Called Party Number parameter shall only be populated with the digit value "911".

2. The Calling Party Number MUST be included in the IAM message. The Charge Number may also be included in the IAM, but if so it MUST be the SAME as the Calling Party Number.

3. The Generic digits parameter SHALL NOT be included in the IAM.

A.8.2 ISUP Initial Address Message Parameter Contents for NCAS (NDET uses

signaling option WRLS_STD, because MSC c

support GDP)

(NCAS as described in J-STD-036-A, Annex-D, Section D.1.2)

As this (NDET) signaling option’s name implies, this should only be used on trunks handling wireless traffic exclusively, and is the industry standard for wireless calls (on an NDET). This option uses the pANI in the Generic Digits parameter to route the call and uses the Calling Party Number Parameter as the callback number. If the WSP will be using a Non Callpath Associated Signaling (NCAS) Solution (as described in J-STD-036-A, Annex-D, Section D.1.2) that intends to deliver the Call Back Number (CBN) and the pANI to the PSAP via the trunk between the Selective Router and the PSAP, Table "B" below illustrates an acceptable interconnection method. In this interconnection method BOTH a pANI (ESRD) and the CBN (aka: MDN) are sent in the SS7/ISUP IAM directly from the WSPs MSC over dedicated trunks into the BellSouth NDET. The pANI is used by the NDET for selective routing, and then the CBN and the pANI are sent to the PSAP using Enhanced MF signaling (E-MF). This is of course dependant on the ability of the PSAP CPE to receive and utilize E-MF. As of 3Q2003 no PSAPs in BellSouth’s E9-1-1 service area are using E-MF, but many may migrate toward it beginning in 4Q2003 or 1Q2004.

When using this interconnection method the NCAS Solution provider might still create a record in the BellSouth the ALI database containing the pANI &/or the CBN (among other data normally included by the NCAS provider, which may or may not also include Phase 2 data). That is beyond the scope of this document.

See Table “B” below. See prior page for an explanation of when this type of interconnection is acceptable.

NDET uses signaling option WRLS_STD, because MSC c

an support GDP)

Extracted in part from J-STD-036-A, Annex-D, Section D.1.2, but clarified for use in BellSouth

Table "B" ISUP Initial Address Message Parameter Contents for Phase 2 NCAS. In this mode both an ESRD and the MDN are sent in the IAM, assuming that the trunk between the

Selective Router and the PSAP supports transport of at least two 7/10-digit numbers.

NOTE:

This 20 digit solution can be used between the MSC and the NDET even if the PSAP is not capable of receiving 20 digits from the NDET. This is accomplished by using the BellSouth Wireless E9-1-1 Solution (WLS911), a Hybrid architecture functional in both Phase 1 and Phase 2 environments. WSPs should see

Page 87

Page 98

Wireless E911 Guide CG-EWCG-001 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Issue 3, January 6, 2004

their BellSouth account team for details on how the WLS911 Solution may be of value in their overall architecture plans.

Orreq

UP Parameters Value

Parameters

Digits(Dialed) Called party number (see Note 1

911

below)

MDN (aka: CBN) Calling party number (see Note 3

below)

CBN or the non-dialable number used in lieu of a real callback

DMH_BillingDigits Charge Number (see Note 3 below) CBN or the non-dialable number

used in lieu of a real callback (see Note 3 below)

GenericDigits Generic digits parameter (see Note 2

ESRD

below) GeographicPosition Calling geodetic location n/a n/a Originating Line Information (OLI) If included, use value 61 OR 62

NOTES:

1. 911 is used as the Called party number. In BellSouth the MSC MUST use dedicated trunks to the Emergency Services Network Entity (ESNE) to route the Emergency Services Call (ESC).

2. The Type of Digits field within the Generic Digits Parameter should be set to 01101 (decimal

13) to indicate Location Identification Number .

3. The Calling Party Number MUST be included in the IAM message. The Charge Number may also be included in the IAM, but if so it MUST be the SAME as the Calling Party Number. Although Charge Number Parameter is allowed as an optional parameter, it is ignored by the NDET when using either of the WRLS_xxx signaling options.

A.8.3 ISUP Initial Address Message Parameter Contents for NCAS (NDET uses signaling option WRLS_CLD because MSC c

annot

support GDP)

As this signaling option’s name implies, this should only be used on trunks handling wireless traffic exclusively. This type of signaling (WRLS_CLD) looks for the pANI in the Called Party Number parameter rather than the Generic Digits Parameter. It uses the Calling Party Number parameter as the callback number. Signaling type WRLS_CLD assumes the Called Party Number is always the pANI. This

signaling option (WRLS_CLD) IS N

OT TO BE USED IF WIRELINE COMPATIBILITY MODE

IS DESIRED (use E911_STD instead). The need to use WRLS_CLD is assumed to be the result of a

situation where the WSP’s MSC switch cannot support a GDP parameter. In that case the pANI would appear in the Called Party Number parameter, as long as WCM i

Page 88

s NOT desired.

Page 99

CG-EWCG-001 Wireless E911 Guide Issue 3, January 6, 2004 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

WARNING

If an MSC switch can support a GDP, and if Wireline Compatibility Mode is NOT desired, then the GDP is the recommended place to put the pANI.

If the WSP will be using a Non Callpath Associated Signaling (NCAS) Solution (as described in J-STD-036-A, Annex-D, Section D.1.2) that intends to deliver the Call Back Number (CBN) and the pANI to the PSAP via the trunk between the Selective Router and the PSAP, Table "C" below illustrates an acceptable interconnection method. In this interconnection method BOTH a pANI (ESRD) and the CBN (aka: MDN) are sent in the SS7/ISUP IAM directly from the WSPs MSC over dedicated trunks into the BellSouth NDET. The pANI is used by the NDET for selective routing, and then the CBN and the pANI are sent to the PSAP using Enhanced MF signaling (E-MF). This is of course dependant on the ability of the PSAP CPE to receive and utilize E-MF. As of 3Q2003 no PSAPs in BellSouth’s E9-1-1 service area are using E-MF, but many may migrate toward it beginning in 4Q2003 or 1Q2004.

See Table “C” below. See prior page for an explanation of when this type of interconnection is acceptable. (NDET uses

signaling option WRLS_CLD because MSC cannot support GDP). Extracted in part from J-STD-036-A, Annex-D, Section D.1.2, b

ut clarified for use in BellSouth

Table "C" ISUP Initial Address Message Parameter Contents for Phase 2 NCAS

In this mode both an ESRD and the MDN are sent in the IAM, assuming that the trunk between the Selective Router and the PSAP supports transport of at least two 7/10-digit numbers.

NOTE:

- continued -

Page 89

Page 100

Wireless E911 Guide CG-EWCG-001 BellSouth Wireless E9–1–1/SS7 Interconnection

Guide

Issue 3, January 6, 2004

- continued -

Orreq

ISUP Parameters Value

Parameters

Digits(Dialed) Called party number (see Note 1

pANI (see Note 1 below)

below)

MDN (aka: CBN) Calling party number (see Note 3

below)

CBN or the non-dialable number used in lieu of a real callback

DMH_BillingDigits Charge Number (see Note 3 below) CBN or the non-dialable number

used in lieu of a real callback (see Note 3 below)

GenericDigits Generic digits parameter (see Note 2

below)

NOT ALLOWED (see Note 2 below)

GeographicPosition Calling geodetic location n/a n/a Originating Line Information (OLI) If included, use value 61 OR 62

NOTES:

1. The pANI is used as the Called party number. In BellSouth the MSC MUST use dedicated trunks to the Emergency Services Network Entity (ESNE) to route the Emergency Services Call (ESC).

2. The Generic Digits Parameter IS NOT ALLOWED TO BE SENT IN THE IAM WHEN USING WRLS_CLD!

A.8.4 ISUP Initial Address Message Parameter Contents for CAS

There are no ISDN PSAPs in the BellSouth E9-1-1 serving area. Therefore the interconnection arrangement shown in Table "D" below IS NOT SUPPORTED.

Shown here for reference ONLY.

WARNING

This I

S NOT SUPPORTED in BellSouth.

Extracted in part from Annex D: of J-STD-036-A Table "D" ISUP Initial Address Message Parameter Contents for CAS.

Page 90