Bellsouth E911 Users Manual

E911 to the manual 98e9d60e-61da-43f5-94c6-cd1ab3cb2701

2015-02-05

: Bellsouth Bellsouth-E911-Users-Manual-356898 bellsouth-e911-users-manual-356898 bellsouth pdf

Open the PDF directly: View PDF .
Page Count: 1

Download
Open PDF In Browser	View PDF

Customer Guide
CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide

Wireless E911 Guide
Copyright

CG-EWCG-001
Issue 3, January 6, 2004

Page ii

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
Table of Contents

Contents
Subject

Introduction / Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Version Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1. Overview of E911 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Telephone Number (TN) Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6
E911 Tandem / Network Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7
Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8
Database Escalation Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.1
Access To NDSC Analysts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.2
Level One Escalation: Intrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.3
Level Two Escalation: Intrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.4
Level Three Escalation: Bellsouth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. Coordination of Wireless Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Coordination Process: Wireless Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Coordination Process: BST Wireless Account Team . . . . . . . . . . . . . . . . . . . . . . .
2.4
Coordination Process: BST Wireless E911 Implementation Manager . . . . . . . . . . . .
2.5
Coordination Process: Mobile Position Center Provider . . . . . . . . . . . . . . . . . . . . .
2.5.1
Steps for Establishment/Change of Mobile Position Center Provider . . . . . . . . . . .
2.5.2
Initial Establishment of Mobile Position Center Provider . . . . . . . . . . . . . . . . . .
2.5.3
Change of Mobile Position Center Provider . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.4
Information Required for Phase 2 MPC/GMLC Circuits to the ALI Hosts . . . . . . .
2.5.5
Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3. Network Specifications and Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Specifications & Ordering Process: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1
Option 1: BellSouth NORTEL Solution Carring Phase 1 Data Only (CBN & pANI)
3.2.2
Specification & Ordering Process: Option 2: Third Party Vendor Solution . . . . . . .
3.3
Wireless Carrier Owned Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1
Trunking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2
Data Connections Required For Wireless Carrier Owned Hardware - Phase 1 Only .
3.4
Wireless Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page

vii
vii
vii
1
1
1
1
1
2
2
3
3
3
4
5
8
8
8
8
8
9
9
9
10
10
11
11
12
12
12
13
15
15
15
15
16
16
16
17
17

Page iii

Wireless E911 Guide
Table of Contents

CG-EWCG-001
Issue 3, January 6, 2004

3.5
Interface Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4. MSAG Maintenance and ESN Assignment . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
ESN Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
MSAG Maintenance and Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5. TN Database Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2
TN Database Daily Updates: Wireless Carrier Responsibilities . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7
Standard Street Suffix (Thoroughfare) Designations / Directionals . . . . . . . . . . . . . .
5.7.1
BellSouth Street Suffix (Thoroughfare) Abbreviations (Table) . . . . . . . . . . . . . . .
5.8
Standard Location Designations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.9
Updating the TN Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.10
Service Order Interface File Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.11
SOIR File Data Record Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.11.1
Table: SOIR File Data Record - BellSouth 512 Character Format for Data Exchange
5.12
SOIR File Header Record Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.12.1
Table: SOIR File Header Record - BellSouth 512 Character Format for Data
Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.13
SOIR File Trailer Record Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.13.1
SOIR File Trailer Record - BellSouth 512 Character Format for Data Exchange . . .
5.14
Mechanized File Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.15
Mechanized File Confirmations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6. TN Errors and Corrective Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
Electronic Error Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1
The Confirmation Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2
The Statistics Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3
Distribution of Daily Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4
TN Error Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3
Error Codes and Error Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4
Error Code and Corrective Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5
Compiled Error Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7. PSAP Inquiries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2
PSAP Inquiry Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3
PSAP Inquiry Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1
Instructions for Completing PSAP Inquiry Log . . . . . . . . . . . . . . . . . . . . . . . .
7.4
Inquiry Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5
Investigation Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Page iv

18
19
19
19
20
23
23
24
26
27
29
30
30
30
31
31
32
33
34
34
34
40
40
40
40
41
41
43
43
43
43
46
47
48
48
50
58
59
59
60
61
61
62
62

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
Table of Contents

7.5.1
ALI Record Not Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8. No Record Found (NRF) Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9. NENA Company Registration Process . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1
NENA Cmpany ID Registration Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2
Purpose of the NENA Company ID Registration Service . . . . . . . . . . . . . . . . . . . .
9.3
Use of the Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4
Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4.1
Input Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10. Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2
Notification and Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3
.........................................................
Appendix A.
BellSouth Wireless E9–1–1/SS7 Interconnection Guide . . . . . . . .
A.1
BellSouth Wireless E-9–1–1/SS7 Interconnection Guide . . . . . . . . . . . . . . . . . . . .
A.2
Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1
Identified Options: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1.1
Call Scenario 1, ESRK Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1.2
Call Scenario 2, CBN and ESRD Delivery - WITHOUT a hybrid: (WITHOUT a
hybrid architecture at the Selective Router) . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1.3
Call Scenario 2, CBN and ESRD Delivery - WITH a hybrid: (WITH a hybrid
architecture at the Selective Router) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.1.4
Call Scenario 3, CBN, ESRD and GLP Delivery: (GLP = Geodetic Location
Parameter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2.2
Database Steering Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3
Scope and introductory text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3.1
Wireless E9-1-1 Service Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4
Reason for Revision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.5
Organization of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6
Wireless CCS Network Interconnection Architecture . . . . . . . . . . . . . . . . . . . . . . .
A.6.1
General Interconnection Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6.2
Wireless Phase 1 vs. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7
Interface Protocol for Wireless Call Setup when using SS7/ISUP signaling. . . . . . . .
A.7.1
Calling Party Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7.2
Calling Party Number Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62
62
62
63
63
63
64
65
65
65
65
66
66
69
69
69
70
70
70
73
73
73
73
75
75
75
76
76
77
77
77
78
78
78
79
79
81
81
81
83
83
84

Page v

Wireless E911 Guide
Table of Contents

A.7.3
A.7.4
A.7.5
A.7.6
A.8
A.8.1
A.8.2
A.8.3
A.8.4
A.9
A.9.1
A.9.2
A.10
A.10.1
A.10.2
A.11
A.11.1
A.11.2
A.11.3
A.11.4
A.11.5
A.11.6
A.12

Page vi

CG-EWCG-001
Issue 3, January 6, 2004

Generic Digits Parameter & GDP Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Charge Number Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Calling Party Category Parameter (CPC, aka: CPCat) . . . . . . . . . . . . . . . . . . . .
Originating Line Information Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cross Reference Tables to J-STD-036-A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Wireline Compatibility Mode (NDET uses signaling option E911_STD) . . . . . . . .
ISUP Initial Address Message Parameter Contents for NCAS (NDET uses signaling
option WRLS_STD, because MSC can support GDP) . . . . . . . . . . . . . . . . . . . .
ISUP Initial Address Message Parameter Contents for NCAS (NDET uses signaling
option WRLS_CLD because MSC cannot support GDP) . . . . . . . . . . . . . . . . . .
ISUP Initial Address Message Parameter Contents for CAS . . . . . . . . . . . . . . . .
Cross Reference Tables to NENA TID 05-501 - SS7 Guidelines for MSC to Selective
Router Connectivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Scenario 1: ESRK Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Call Scenario 2: CBN and ESRD Delivery . . . . . . . . . . . . . . . . . . . . . . . . .
Attachment "A" - CPCat & OLI Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Calling Party Category parameter (CPC): . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Originating Line Parameter (OLI): . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Attachment "B" - Wireless Customer Questions & Answers: . . . . . . . . . . . . . . . . . .
Why is BellSouth issuing this document? . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Do I have to change my existing trunks to SS7? . . . . . . . . . . . . . . . . . . . . . . . .
Will this let me deliver ESRDs/ESRKs from more than one NPA on the SS7 trunk
group? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Will this let me reduce the number of trunk groups I have in place? . . . . . . . . . . .
What if I don’t have SS7 signaling "A" link connectivity to support trunking to the
appropriate NDET? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
What do I do for Continuity Testing on these SS7 trunks? . . . . . . . . . . . . . . . . .
11.0 Attachment "C" - Wireless Customer Checklist . . . . . . . . . . . . . . . . . . . . . . .

84
85
85
85
86
86
87
88
90
91
92
92
94
94
94
95
95
95
95
95
96
96
96

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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

Action
Request
#
N/A

N/A

N/A
N/A

Chapter

All

Page 8

MSAG Maintenance
and ESN Assignment

Overview of E911;
Coordination
of Wireless
Interconnection;
Network
Specifications and
Ordering

TN Database Updates

TN Database Updates
and PSAP Inquiries

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

Description

Corrected FAX numbers.

Overview of E911: Added
"GMLC" Term, Changed
contact for "Level One
Escalation: Intrado".
Coordination of Wireless
Interconnection: Added
"Coordination Process:
Mobile Position Center
Provider"
Network Specifications and
Ordering: Added "Wireless
Phase 2".

- continued -

Rosemary Parker /
Mike Harfield

Genia Harris /
Mike Harfield

Rosemary Parker /
Mike Harfield

Tom Breen / Bill
Marczak / Mike
Harfield

Change
Requested By /
Made By

Introduction / Revision History

December 2, 2002 Added step in TN Database
/ 1c
Daily Updates: Wireless
Carrier Responsibilities and
changed address in Inquiry
Flow for INTRADO.

January 8, 2003 /
2

April 3, 2003 / 2a

May 22, 2003 / 2b Revised SOIR File Data
Record Layout Table to
show "Sent to PSAP" field
footnotes in table column.

January 6, 2004 /
3

Date / Issue

Table A Revision History

Wireless E911 Guide
Issue 3, January 6, 2004

CG-EWCG-001

Action
Request
#
N/A

N/A

Chapter

All

Various

All

April 4, 2002 / 1

Initial Issue

June 20, 2001 / 1a General revisions to section
entitled "TN Errors and
Corrective Action"

July 15, 2002 / 1b Revisions to sections
entitled, "Overview of
E911", "Coordination of
Wireless Interconnection",
and "Network Specifications
and Ordering".

Description

Revision History (continued)

Date / Issue

Table A

Rosemary Parker /
Mike Harfield

Change
Requested By /
Made By

CG-EWCG-001

Issue 3, January 6, 2004
Introduction / Revision History

Wireless E911 Guide

Page 9

Wireless E911 Guide
Introduction / Revision History

Page 10

CG-EWCG-001
Issue 3, January 6, 2004

Overview of E911

1.1

Definition of E911

Wireless E911 Guide
Overview 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

Wireless E911 Guide
Overview of E911

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

1.3

Wireless E911 Guide
Overview of E911

Databases Required to Support E911

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

1.4

Master Street Address Guide (MSAG)
Telephone Number (TN) Database
E911 Tandem/Network Information (TN/ESN)

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

Wireless E911 Guide
Overview of E911

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

1.7

Wireless E911 Guide
Overview of E911

Glossary of Terms
Table B

Glossary of Terms

Term

Definition

ACAC

Access Carrier Advocacy Center

Address Verification
Request (AVR)

A form issued by each telco to refer and resolve address
discrepancies with the E911 Customer.

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

Wireless E911 Guide
Overview of E911

CG-EWCG-001
Issue 3, January 6, 2004

Table B

Glossary of Terms (continued)

Term

Definition

E911 Tandem Central
Office Switch

The central office designated for a geographical area to receive end
office E911 calls and route to the appropriate PSAP.

Emergency Service
Number (ESN)

A number associated with the geographical area served by the same
fire, police and ambulance districts.

Emergency Service
Routing Digits
(ESRD)

See ANI or pANI

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
Part (ISUP)

A message protocol to support call set up and release for interoffice
voice call connections over SS7 signaling.

Intrado

A vendor designated by BST to handle E911 data maintenance
(formerly SCC)

LOC

Location

Master Street Address
Guide (MSAG)

All street data, including street names, address ranges and ESNs
used to validate incoming telephone number data for provisioning
of selective routing.

Mobile Position Center The network entity that provides phase 2 location information to
(MPC)
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.
Mobile Switching
Center (MSC)

Wireless equivalent of an End Office, which provides switching
functions from wireless calls.

National Emergency
Number Association
(NENA)

A professional association of 9-1-1 emergency number entities
responsible for the planning, implementation, management and
administration of national emergency number issues.

NPA

The area code of the telephone number.

NRF

No Record Found

NXX

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

Page 6

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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
Answering Point
(PSAP)

The answering location for 911 calls.

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.
Service Order Interface A formatted data record sent to the E911 host computer system by
Record (SOIR)
the wireless carrier. (see TSS)

Note:

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

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.

Telephone Number

Transaction Servicing
System (TSS)

The BellSouth E911vendor’s computer system that performs
database processing.

WSANI

Wireless Subscribers ANI (see ANI or pANI)

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

Wireless E911 Guide
Overview of E911

1.8

CG-EWCG-001
Issue 3, January 6, 2004

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

CG-EWCG-001
Issue 3, January 6, 2004

2.
2.1

Wireless E911 Guide
Coordination of Wireless Interconnection

Coordination of Wireless Interconnection
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

Wireless E911 Guide
Coordination of Wireless Interconnection

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

•

•
•
•

Wireless E911 Guide
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

Wireless E911 Guide
Coordination of Wireless Interconnection

2.5.2

CG-EWCG-001
Issue 3, January 6, 2004

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

CG-EWCG-001
Issue 3, January 6, 2004

2.5.5

Wireless E911 Guide
Coordination of Wireless Interconnection

Forms

Birmingham DATA Center: (serving LA, MS, AL, TN, KY)
Nashville DATA Center: (serving LA, MS, AL, TN, KY)
Charlotte DATA Center: (serving FL, GA, NC, SC)
Miami DATA Center: (serving FL, GA, NC, SC)

Page 13

Wireless E911 Guide

Page 14 - Blank

CG-EWCG-001
Issue 3, January 6, 2004

3.
3.1

Wireless E911 Guide
Network Specifications and Ordering

Network Specifications and Ordering
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
3.2.1

Specifications & Ordering Process:
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 minimum of two(2), Type 2C, Feature Group - D (FG-D) or SS7/ISUP signaling
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
with or without the optional pause for acknowledgement after the 1st stage address field.
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.

Page 15

Wireless E911 Guide
Network Specifications and Ordering

3.2.2

CG-EWCG-001
Issue 3, January 6, 2004

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

Page 16

CG-EWCG-001
Issue 3, January 6, 2004

3.3.2
Only

Wireless E911 Guide
Network Specifications and Ordering

Data Connections Required For Wireless Carrier Owned Hardware - Phase 1

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

Wireless E911 Guide
Network Specifications and Ordering

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

4.
4.1

Wireless E911 Guide
MSAG Maintenance and ESN Assignment

MSAG Maintenance and ESN Assignment
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

Wireless E911 Guide
MSAG Maintenance and ESN Assignment

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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

Wireless E911 Guide

Page 22 - Blank

CG-EWCG-001
Issue 3, January 6, 2004

5.
5.1

Wireless E911 Guide
TN Database Updates

TN Database Updates
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

Wireless E911 Guide
TN Database Updates

CG-EWCG-001
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

Page 24

ACTION

Obtain official NENA Company
Identifier and include on each
pseudo-ANI TN database record.

Include every pseudo-ANI TN
record within each E911 service
area.

Include blocks of pseudo-ANI
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.

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

CG-EWCG-001
Issue 3, January 6, 2004

STEP

Wireless E911 Guide
TN Database Updates

ACTION

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

Update address on pseudo-ANI
(TN) records as address data or
cell site coverage area is modified.

Any new service and all
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.

Resolve Daily Service Order
Interface Record (SOIR) update
errors within 24 hours.

Update pseudo-ANI (TN) records
with valid MSAG address
to resolve 911 call misroute
conditions.

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

Page 25

Wireless E911 Guide
TN Database Updates

STEP

5.3

CG-EWCG-001
Issue 3, January 6, 2004

ACTION

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.

Work with E911 Customer
to resolve address or ESN
discrepancies.

Transfer data files to INTRADO
to test database processing at
least one week prior to service
implementation.

Identify and resolve special
requirements for premises based
ALI systems.

Provide dynamic update interface
to populate call back number
and latitude / longitude in ALI
database.

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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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
ADDRESS:

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

CONTACT NAME:

Enter the name of the person responsible for data issues.

CONTACT PHONE
NUMBER:

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

TELCO ID / OCN:

Enter the four(4) digit numeric Telco ID or Operating Company
Number issued by BELLCORE.

NENA CO.
IDENTIFIER:

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

EFFECTIVE DATE:

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:

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

SERVICE REQUEST
FOR:

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

Wireless E911 Guide
TN Database Updates

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

5.5

Wireless E911 Guide
TN Database Updates

NXX Table Update Form

Figure 1

NXX Table Update Form

Page 29

Wireless E911 Guide
TN Database Updates

5.6

CG-EWCG-001
Issue 3, January 6, 2004

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

Prefix
Directional

Street
Name

Street Suffix
(Thoroughfare)

Post
Directional

Community

100-399

MAIN

CHARLOTTE

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:
•
•

Page 30

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.

CG-EWCG-001
Issue 3, January 6, 2004

5.7

Wireless E911 Guide
TN Database Updates

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

Description

T / F Abbrev

Description

ALY

ALLEY

LANE

ANX

ANNEX

LOOP

ARC

ARCADE

MKT

AVENUE

MNR

MANOR

BDWK

BOARDWALK

MOUNT

BEND

MTN

MOUNTAIN

BLK

BLOCK

NECK

BLVD

BOULEVARD

PASS

BRANCH

PATH

BTM

BOTTOM

POND

BYP

BYPASS

PARK

CIR

CIRCLE

PKE

PIKE

CRES

CRESCENT

PKWY

PARKWAY

CRK

CREEK

PLACE

CRSG

CROSSING

PLZ

PLAZA

CSWY

CAUSEWAY

PIER

COURT

PROM

CTR

CENTER

POINT

COVE

PVT DR

PRIVATE DRIVE

DRIVE

ROAD

ESPLND

ESPLANADE

RDG

RIDGE

EST

ESTATE

RDWY

ROADWAY

EXPWY

EXPRESSWAY

ROW

EXT

EXTENSION

ROUTE

- continued -

Page 31

Wireless E911 Guide
TN Database Updates

CG-EWCG-001
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

FREEWAY

SQUARE

GRDN

GARDEN

STREET

HBR

HARBOR

STA

STATION

HILL

TER

TERRACE

HLS

HILLS

THRWY

THRUWAY

HOLW

HOLLOW

TRAIL

HEIGHT

TRC

TRACE

HTS

HEIGHTS

TRNPK

TURNPIKE

HWY

HIGHWAY

VLG

VILLAGE

ISL

ISLAND

WAY

JCTN

JUNCTION

WHF

WHARK

LDG

LANDING

WALK

LAKE

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:

5.8

511

1ST

733

33RD

STREET A NE

600

1ST STREET

733

N 33RD TER

SOUTH RD

411

1ST AV

985

NW 5TH CT

NORTHEAST BLVD

512

1ST NE

109

E STREET

622

22ND PL SW

735

AVENUE K

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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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:
Level 2:
Level 3:
Level 4:

BLDG, WNG, PIER
FLR
APT, RM, LOT, SLIP, SUIT, UNIT
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:
EXAMPLE 2:
EXAMPLE 3:
EXAMPLE 4:
EXAMPLE 5:

5.9

APT 2-B
BLDG 6 APT 2-B
FLR 6 SUIT 2-B
DES NEXT TO POOL
.25 MI NE OF MAIN ST (wireless example)

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:

Processing Rules:

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.

Change the corresponding record in the database. A data record must
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.

Page 33

Wireless E911 Guide
TN Database Updates

5.10

CG-EWCG-001
Issue 3, January 6, 2004

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

CALLING
NUMBER
(TN)
HOUSE
NUMBER

house number
suffix

Yes
Yes

Yes

Yes
Yes - Only
eight(8)
characters sent
to PSAP.
Yes

Yes

Yes
prefix directional

NPA

FUNCTION
CODE

Field Name

Stored in
Database

Sent to PSAP

26 - 27

22 - 25

12 - 21

5 - 11

2-4

Bytes

Type

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

House number extension (e.g., 1/2). The
field should be space filled if suffix does
not apply. Do not lead with hyphen.

House number. The field should be space
filled if no house number is available.

Seven(7) digit telephone number of the
Calling Number. For Wireless, pseudo
ANI of PSAPor antenna face receiving
wireless call.

Three(3) digit area code of the Calling
Number.

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)

BellSouth Description

Issue 3, January 6, 2004

- continued -

Position

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

CG-EWCG-001
Wireless E911 Guide
TN Database Updates

Page 35

Page 36

Yes - Only
twenty(20)
characters
stored and
sent to
PSAP.

Yes - Value of
G = Wireless
P1 (Sent
to PSAP
as WRLS).
Value of H =
Wireless P2
(Sent to PSAP
as WPH2)

location

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).

Valid service community of the street
name / house number as designated by
the MSAG.

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

BellSouth Description

Type

TN Database Updates

- continued -

128 - 187 60

126 - 127 2

STATE

Yes

28 - 93

Bytes

Yes

STREET NAME
STREET
SUFFIX
POST
DIRECTIONAL

Position

94 - 125

Yes - Some
solutions
may change
this data via
dynamic
update
during
911 call
processing.

Yes - Only 48
characters sent
to PSAP.EX:
Main St NW

Field Name

Yes - Only 18 Yes - Some COMMUNITY
characters sent solutions
NAME
to PSAP.
may change
this data via
dynamic
update
during
911 call
processing.

Stored in
Database

Sent to PSAP

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

Wireless E911 Guide
Issue 3, January 6, 2004

CG-EWCG-001

Yes

MAIN NPA

Yes

Bytes

Type

- continued -

234 - 240 7

231 - 233 3

226 - 230 5

222 - 225 4

221

220

188 - 219 32

Position

Main telephone number associated with
the Calling Number. For wireless use
same value as Calling Number field.

Area code of the Main Number
associated with the Calling Number. For
wireless, use same value as NPA field.

Emergency Service Number associated
with the House Number and Street Name;
this field is blank on input and derived
from the MSAG validation process.

Phone company exchange identifier
for the serving telephone office of the
customer; ALEC and Wireless may be
blank.

Value of:
0=Not Non-Pub
3=Non-Pub

Value of:
G=Wireless P1
Value of:
H=Wireless P2

Carrier name associated with the Calling
Number.

BellSouth Description

Issue 3, January 6, 2004

MAIN
NUMBER

esn

Yes
Yes - Only
three(3)
characters sent
to PSAP.

EXCHANGE

TYPE OF
SERVICE

Yes

CUSTOMER
NAME
CLASS OF
SERVICE

Yes

Field Name

Yes - Value of Yes
G = Wireless
P1 (Sent
to PSAP
as WRLS).
Value of H =
Wireless P2
(Sent to PSAP
as WPH2)

Stored in
Database

Sent to PSAP

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

CG-EWCG-001
Wireless E911 Guide
TN Database Updates

Page 37

Stored in
Database
Yes
Yes
Yes

Yes

Yes
Yes
No

Yes

Sent to PSAP

Page 38

Yes

Bytes

Type

- continued -

290 - 319 30

287 - 289 3

276 - 286 11

272 - 275 4

267 - 271 5

266

261 - 265 5

257 - 260 4

251 - 256 6

241 - 250 10

Position

Optional notes

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.

This field is mutually used by data
exchange partners to pass information
not defined in previous fields.

Postal Zip Code Extension.

Postal Zip Code.

Code which indicates whether data is part
of the initial database creation process or
part of the daily update process.
Daily = Space
Initial Load = C

Telephone Company Identification code
as assigned through NENA registration
process.

County Identification code (usually the
FIPS code). Will be blank on input and
derived from MSAG validation process.

Date on which the record was created in
the format MMDDYY.

Service order number for the activity
establishing this record.

BellSouth Description

TN Database Updates

comments

CUSTOMER
CODE

general use

zip +4

zip code

source identifier

COMPANY ID

county identifier

EXTRACT
DATE

order number

Field Name

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

Wireless E911 Guide
Issue 3, January 6, 2004

CG-EWCG-001

Yes y coordinate
Dynamically
updated in
DB.
No
No

No
Yes
Yes

No
No

Yes Dynamically
updated in
DB.

Yes

END OF
RECORD

Bytes

512

366 - 511 146

356 - 365 10

350 - 355 6

349

343 - 348 6

338 - 342 5

329 - 337 9

320 - 328 9

Position

Type

Always an asterisk (*)

This field is reserved for the processing
company’s use.

Remote Call Forward Number field;
Wireless Providers must send spaces; if
Wireless Provider has dynamic update
interface, or other providers send RCF,
mobile directory number or RCF will be
sent to PSAP following field identifier
of ALT#

Taxing Area Rate Code. ALEC and
Wireless populate with zeros.

Reserved for future use. Subset / section
of a cell.

Reserved for future use. Identification
number indicating a geographic region
of cellular coverage.

Reserved for future use. Structure
elevation.

Latitude / Y coordinate.

Longitude / X coordinate.

BellSouth Description

Issue 3, January 6, 2004

reserved

remote call
forward (rcf)
number

TAR CODE

sector identifier

cell identifier

z coordinate

Yes x coordinate
Dynamically
updated in
DB.

Yes Dynamically
updated in
DB.

Field Name

Stored in
Database

Sent to PSAP

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

CG-EWCG-001
Wireless E911 Guide
TN Database Updates

Page 39

Wireless E911 Guide
TN Database Updates

5.12

CG-EWCG-001
Issue 3, January 6, 2004

SOIR File Header Record Layout

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

Bytes

Type

1-5

Always "UHL "

6-11

Date formatted as MMDDYY

COMPANY NAME

12-61

CYCLE COUNTER

62-67

county identifier

68-71

state

72-73

general use

74-93

release number

94-96

format version

reserved

98-511

414

Field Name
HEADER
INDICATOR
EXTRACT DATE

END OF RECORD

5.13
5.13.1

512

BellSouth Description

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

Always "*"

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

Type

1-5

Always "UHL "

6 - 11

Date formatted as MMDDYY

COMPANY NAME

12 - 61

RECORD COUNT

62 - 67

98 - 511

414

Field Name
TRAILER
INDICATOR
EXTRACT DATE

reserved
END OF RECORD

Page 40

Position

512

BellSouth Description

Does not include header and trailer
record
Always "*"

CG-EWCG-001
Issue 3, January 6, 2004

5.14

Wireless E911 Guide
TN Database Updates

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 THROUGH INTRADO. 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

Wireless E911 Guide
TN Database Updates

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

6.
6.1

Wireless E911 Guide
TN Errors and Corrective Action

TN Errors and Corrective Action
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 must be corrected as quickly as possible for the
wireless data to be included in the E911 database.
The Wireless Carrier is expected to resolve the errors by:
•
•

6.2

Issuing Address Verification Requests (AVR) to the E911 Coordinator for MSAG changes.
· Issuing corrective SOIRs within 24 hours of receipt.

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

Wireless E911 Guide
TN Errors and Corrective Action

Table F
FIELD

CG-EWCG-001
Issue 3, January 6, 2004

Confirmation Report Fields and Descriptions
DESCRIPTION

FUNCTION CODE

Valid codes are:
• : I=Insert
• C=Change
• P=Main account delete
• E=Error delete
• U=Unlock
• M=Migrate

NPA

Three(3) digit number of Calling Number

CALLING
NUMBER

Seven(7) digit number of Calling Number

HOUSE NUMBER

House Number. The field should be spaced filled if no house
number is available.

HOUSE NUMBER
SUFFIX

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

PREFIX
DIRECTIONAL

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.

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 44

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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
NAME

Subscriber name associated with the Calling Number.

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

Wireless E911 Guide
TN Errors and Corrective Action

CG-EWCG-001
Issue 3, January 6, 2004

Table F Confirmation Report Fields and Descriptions (continued)

6.2.2

GENERAL USE

Mutually used by data exchange partners to pass information
not defined in previous fields.

CUSTOMER
CODE

Code used to uniquely identify customer.

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 (*)

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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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

Wireless E911 Guide
TN Errors and Corrective Action

CG-EWCG-001
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

111

Street name is too long
- continued -

Page 48

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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

Wireless E911 Guide
TN Errors and Corrective Action

Table G

CG-EWCG-001
Issue 3, January 6, 2004

Error Codes and Error Descriptions (continued)

ERROR

6.4

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

Error Code and Corrective Action
Table H

Error Codes and Corrective Action

Error Code

Error Message

Occurs when. . .

100

Customer Code not
numeric

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

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

101

NPA / NXX not
valid

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

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

103

Main TN not
numeric

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

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

105

Name missing

The customer name field on the incoming Issue corrective SOIR for errored TN
SOIR is blank
with correct customer name

106

Address missing

The address field on the incoming SOIR
is blank
- continued -

Page 50

Corrective Action for . . .

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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
TN Errors and Corrective Action

Table H
Error Code

Error Message

Error Codes and Corrective Action (continued)
Occurs when. . .

Corrective Action for . . .

107

House number
contains invalid
characters

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

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

108

House number is too The house number on the incoming
long
SOIR contains too many characters

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

109

Street direction is
too long

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

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

110

Street direction is
invalid

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

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

111

Street name is too
long

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

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

112

Street name has
invalid characters

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

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

113

Community name is The community name on the incoming
too long
SOIR contains too many characters

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

114

Community
name has invalid
characters

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

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

115

Service Class
Invalid

The incoming record has an invalid class Submit corrective SOIR with valid class
of service
of service

116

House number
suffix is too long

The house number suffix on the incoming Determine the correct house number
SOIR contains too many characters
suffix and submit corrective SOIR for
errored TN

120

TN is incorrectly
formatted

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

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

126

Invalid type of
service

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

Submit SOIR with valid type of service,
0 or 3

- continued -

Page 51

Wireless E911 Guide
TN Errors and Corrective Action

Table H
Error Code

Error Message

CG-EWCG-001
Issue 3, January 6, 2004

Error Codes and Corrective Action (continued)
Occurs when. . .

Corrective Action for . . .

701

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

702

Record already
exists, insert not
allowed

The SOIR has a FOC of I and attempts to Using the image of the existing record
insert a TN into the database that already that is sent with the error, determine if
exists
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

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

705

Main account record The main account TN on the incoming
not found for delete SOIR does not exist in the database

- continued -

Page 52

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

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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
TN Errors and Corrective Action

Table H

Error Codes and Corrective Action (continued)

Error Code

Error Message

Occurs when. . .

709

Street not found in
MSAG

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

710

Customer code
doesn’t match on
change

The customer code shown for the
Determine the correct customer code and
incoming SOIR doesn’t match the
resubmit corrective SOIR with customer
customer shown on the existing database code of 999 or blanks
record

711

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

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

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

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

Corrective Action for . . .
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

- continued -

Page 53

Wireless E911 Guide
TN Errors and Corrective Action

Table H
Error Code

Error Message

CG-EWCG-001
Issue 3, January 6, 2004

Error Codes and Corrective Action (continued)
Occurs when. . .

Corrective Action for . . .

713

TN and main
account mismatch

The main account shown on the incoming Submit D FOC on existing database
SOIR doesn’t match the main account
record to delete TN with different main
shown on the database record.
account and IFOC with appropriate
changes on corrective SOIR showing the
TN and the main account as the same
number.

729

Change failed,
completion date
conflict with
disconnect file

An incoming SOIR contains a
Determine if TN is valid and should be
completion date that is equal to or earlier changed
that the completion date of the record
• If TN is valid submit corrective
that has been deleted
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

730

Insert failed,
completion date
conflict with
disconnect file

The incoming insert SOIR is for a TN
Determine if the insert record should
that has been disconnected and the date have posted prior to the disconnect:
on the insert SOIR is the same or prior to • If yes, issue E FOC SOIR to delete
the date of the disconnected TN.
the error record
• If no, issue resubmit I FOC SOIR
with completion date later than
disconnect date

731

Change failed,
completion date
conflict with TN
database

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

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

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 -

Page 54

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
TN Errors and Corrective Action

Table H
Error Code

Error Message

Error Codes and Corrective Action (continued)
Occurs when. . .

Corrective Action for . . .

735

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

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

738

MSAG update
caused a TN error

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

739

Invalid house
number format

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

Determine correct house number for TN
and resubmit correct SOIR

741

Update not allowed,
flagged for PS-ALI
/ PinPoint

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

Submit E FOC SOIR to delete error
record

751

Invalid function
code

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

Resubmit the SOIR with valid function
code

752

Invalid company ID

The incoming SOIR has an invalid
NENA ID

Resubmit the SOIR with a valid NENA
ID

753

No record exists on
unlock

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

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

- continued -

Page 55

Wireless E911 Guide
TN Errors and Corrective Action

Table H

CG-EWCG-001
Issue 3, January 6, 2004

Error Codes and Corrective Action (continued)

Error Code

Error Message

Occurs when. . .

Corrective Action for . . .

754

No record exists on
lock

The TN on the incoming Migrate SOIR
does not exist 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

755

Unable to migrate
locked record

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

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

756

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

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

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

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

- continued -

Page 56

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
TN Errors and Corrective Action

Table H
Error Code
758

Error Message

Error Codes and Corrective Action (continued)
Occurs when. . .

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

Corrective Action for . . .
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

760

Lock exceeds
number of retries

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

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.

762

NENA ID required
for U or M FOC
SOIR

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

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

781

Error record does
not exist for delete

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

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

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

- continued -

Page 57

Wireless E911 Guide
TN Errors and Corrective Action

Table H
Error Code

CG-EWCG-001
Issue 3, January 6, 2004

Error Codes and Corrective Action (continued)

Error Message

Occurs when. . .

Corrective Action for . . .

783

Unlock failed; main The incoming U FOC TN is in the
There are two possible corrective actions:
account has sublines database as a main account with other
1. If all accounts shown with the main
TNs shown as sublines but no U FOC
account are to be unlocked submit a
was received on the sublines(Note: Since
U FOC for each TN associated with
the main account and Calling number TN
the original main account.
are to be the same TN, this error would 2. If all accounts are not to be unlocked
be received only if the TN in the database
submit a D FOC for the existing
had been submitted with a different main
subline showing the erroneous main
account on a previous SOIR.)
account and then resubmit an I FOC
for the TN shown with the Calling
number TN as the main account.

792

I FOC record exists
with a different
Company ID

6.5

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

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.

Compiled Error Report

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

CG-EWCG-001
Issue 3, January 6, 2004

7.
7.1

Wireless E911 Guide
PSAP Inquiries

PSAP Inquiries
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:

problems relating to the network or equipment

COMMENT:

input of additional pertinent information

ACTION:

response section

Page 59

Wireless E911 Guide
PSAP Inquiries

7.2

CG-EWCG-001
Issue 3, January 6, 2004

PSAP Inquiry Form

Figure 3

Page 60

PSAP Inquiry Form

CG-EWCG-001
Issue 3, January 6, 2004

7.3

Wireless E911 Guide
PSAP Inquiries

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

Date Received

Enter the date the Inquiry was received

NPA / Telephone
Number

Enter the NPA and telephone number being referred on
the Inquiry

911 Call Date

Enter the date of the 911 call

Action taken

Enter the action taken to handle the inquiry
- continued -

Page 61

Wireless E911 Guide
PSAP Inquiries

CG-EWCG-001
Issue 3, January 6, 2004

- continued -

7.4

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

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
7.5.1

Investigation Procedures
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

CG-EWCG-001
Issue 3, January 6, 2004

7.5.4

Wireless E911 Guide
PSAP Inquiries

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

Wireless E911 Guide
PSAP Inquiries

7.6.1

CG-EWCG-001
Issue 3, January 6, 2004

PSAP Inquiry Log

Figure 5 PSAP Inquiry Log

Page 64

CG-EWCG-001
Issue 3, January 6, 2004

8.
8.1

Wireless E911 Guide
No Record Found (NRF) Processing

No Record Found (NRF) Processing
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

Wireless E911 Guide
No Record Found (NRF) Processing

CG-EWCG-001
Issue 3, January 6, 2004

- continued -

8.4

Tuesday’s NRFs

NRF report distributed on Wednesday

Wednesday’s NRFs

NRF report distributed on Thursday

Thursday’s NRFs

NRF report distributed on Friday

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:

8.5

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

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.

CG-EWCG-001
Issue 3, January 6, 2004

•
•
•

Wireless E911 Guide
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

Wireless E911 Guide

Page 68 - Blank

CG-EWCG-001
Issue 3, January 6, 2004

9.
9.1

Wireless E911 Guide
NENA Company Registration Process

NENA Company Registration Process
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
•

•
•

9.2

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

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

Wireless E911 Guide
NENA Company Registration Process

9.3

CG-EWCG-001
Issue 3, January 6, 2004

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. Click
here to access website
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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
NENA Company Registration Process

Figure 6

Input Form

Page 71

Wireless E911 Guide

Page 72 - Blank

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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

Wireless E911 Guide

Page 74 - Blank

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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.
Click here 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

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

CG-EWCG-001
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: http://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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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)
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).
NOTE: Call Scenario 2, CBN and ESRD Delivery - WITH a hybrid is available on ALL of BellSouth’s
(64) NDETs.
A.2.1.4
Parameter)

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

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

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

A.2.2

CG-EWCG-001
Issue 3, January 6, 2004

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 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.
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
A.3.1

Scope and introductory text
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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

•

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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
A.6.1

Wireless CCS Network Interconnection Architecture
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 http://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
Wireless Network Planning practices, but in no case will it be less than two trunk members per Trunk Group
(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 (primary 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

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

CG-EWCG-001
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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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. (They would of course be known by other nomenclature
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!
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.

•
•
A.7.1

Calling Party Category Parameter
Originating Line Information Parameter Calling Party Number Parameter
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

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

A.7.2

CG-EWCG-001
Issue 3, January 6, 2004

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
Wireline Compatibility Mode is not 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 Parametershall 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

CG-EWCG-001
Issue 3, January 6, 2004

A.7.4

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

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

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

A.8

CG-EWCG-001
Issue 3, January 6, 2004

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 over 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
below)

ESRK

DMH_BillingDigits

Charge Number (see Note 2
below)

ESRK

GenericDigits

Generic digits parameter (see Note NOT ALLOWED (see Note 3
3 below)
below)

GeographicPosition

Calling geodetic location

n/a

Originating Line Information
(OLI)

If included, use value 00
(POTS)

NOTES:

Page 86

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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 can 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 can 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

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

CG-EWCG-001
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
Parameters
Digits(Dialed)

UP Parameters
Called party number (see Note 1
below)

Value
911

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

ESRD

Generic digits parameter (see Note 2
below)

GeographicPosition Calling geodetic location

n/a

If included, use value 61 OR 62

Originating Line Information (OLI)

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 cannot 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 NOT 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 is NOT desired.

Page 88

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
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.
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 “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, but 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:
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
their BellSouth account team for details on how the WLS911 Solution may be of value in their overall
architecture plans.
- continued -

Page 89

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

CG-EWCG-001
Issue 3, January 6, 2004

- continued Orreq
Parameters
Digits(Dialed)

ISUP Parameters
Called party number (see Note 1
below)

Value
pANI (see Note 1 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

NOT ALLOWED (see Note 2
below)

Generic digits parameter (see Note 2
below)

GeographicPosition Calling geodetic location

n/a

If included, use value 61 OR 62

Originating Line Information (OLI)

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!
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.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 IS 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

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

In this mode the initial position of the mobile is also sent in the IAM.
Orreq
Parameters

ISUP Parameters

Value

Digits(Dialed)

Called party number

(911) or PSAP DN (see Note 1
below) or ESRD

MDN

Calling party number

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

GenericDigits

ESRD

Generic digits parameter (see Note 2
below)

GeographicPosition Calling geodetic location

geographic position (x, y)

n/a

If included, use value 61 OR 62

Originating Line Information (OLI)

NOTES:
1. 911 is used as the Called party number if the MSC uses dedicated trunks to the Emergency
Services Network Entity (ESNE) to route the Emergency Services Call (ESC). The directory
number of the PSAP is used as the called party number if the MSC uses a shared trunk to route
the ESC to the ESNE. The ESRD may be used on dedicated trunks that do not support the
ISUP Generic Digits parameter.
2. The Type of Digits field within the Generic Digits Parameter (IF USED) should be set to
indicate Location Identification Number. GDP MUST NOT BE SENT IF WRLS_CLD
signaling option is used at the NDET.
3. The Charge Number, Calling Party Number or both may be included in the IAM message.
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.
WARNING
Remember, Phase 2 CAS IS NOT SUPPORTED in BellSouth!

A.9

Cross Reference Tables to NENA TID 05-501 - SS7 Guidelines for MSC to
Selective Router Connectivity.

The intention of this section is to provide a way 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.
Each of the following pages in this section represents a different interconnection scenario that is described
in NENA TID 05-501- SS7 Guidelines for MSC to Selective Router Connectivity.

Page 91

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

A.9.1

CG-EWCG-001
Issue 3, January 6, 2004

Call Scenario 1: ESRK Delivery

Call Scenario 1 describes the mode where an MSC uses ISDN User Part (ISUP) protocol to send an
ESRK to an E911 selective router. Call Scenario 1 supports the Wireline Compatibility Mode1described
in J-STD-036-A, Annex D, Section D.1.1. Wireless carriers can use Call Scenario 1 to support Phase I
and/or Phase II wireless E911 calls. The table below shows the possible alternatives for populating the
parameters in the Initial Address Message (IAM).
BellSouth’s equivalent of NENA 05-501 Table 4-1 (ESRK Delivery):
ISUP
OLI
CpCAT
CdPN
Parameter Wireless Emergency
Option

CPN

CHGN

GDP

NDET
signaling
option

Note(s)

Yes

911

ESRK

Blank

E911_STD
(WCM)

1, 2

Yes

911

ESRK

Blank

E911_STD
(WCM)

1, 2

Yes

911

Blank

ESRK

Blank

E911_STD
(WCM)

1, 2

Yes

911

ESRK

Blank

E911_STD
(WCM)

1, 2

Yes

911

ESRK

Blank

E911_STD
(WCM)

1, 2

Yes

911

Blank

ESRK

Blank

E911_STD
(WCM)

1, 2

NOTES:
1. This ISUP parameter option is widely supported in the U.S. It is estimated that 95% of the
E911 selective routers deployed in the U.S. support this option when the selective router has
been equipped with wireless E911 features.
2. "Blank"-- this parameter MUST NOT be populated.
A.9.2

8.2 Call Scenario 2: CBN and ESRD Delivery

Call Scenario 2 describes the mode where a MSC uses ISUP protocol to send the caller’s CBN and
ESRD to an E911 selective router. Call Scenario 2 supports the Phase 2 NCAS2 mode described in
J-STD-036-A, Annex D, Section D.1.2. Wireless carriers can use Call Scenario 2 to support Phase I
and/or Phase II wireless E911 calls. The table below shows the possible alternatives for populating the
parameters in the Initial Address Message (IAM).
1

J-STD-036 uses the term "Wireline Compatibility Mode" to describe scenarios where MSCs use the ISUP parameter mappings
normally used by landline switches to signal E911 calls to E911 selective routers.
2 J-STD-036 uses the term NCAS to describe scenarios where an MSC uses ISUP protocol to send CBN and ESRD to an
E911 selective router.

Page 92

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

BellSouth’s equivalent of NENA 05-501 Table 4-2 (CBN & ESRD Delivery):
ISUP
Parameter
Option

OLI
Wireless

Yes

CpCAT
CdPN
Emergency

CPN

CHGN

GDP

NDET
signaling
option

Note(s)

911

CBN

ESRD

WRLS_STD

Yes

911

CBN

Blank

ESRD

WRLS_STD

Yes

911

Blank

CBN

ESRD

E911_STD

Yes

911

CBN

ESRD

WRLS_STD

Yes

911

CBN

Blank

ESRD

WRLS_STD

Yes

911

Blank

CBN

ESRD

E911_STD

Yes

911

jCBN

CBN

ESRD

WRLS_STD

Yes

911

CBN

Blank

ESRD

WRLS_STD

Yes

911

Blank

CBN

ESRD

E911_STD

911

CBN

ESRD

WRLS_STD

911

CBN

Blank

ESRD

WRLS_STD

911

Blnk

CBN

ESRD

E911_STD

Yes

ESRD

CBN

Blank

WRLS_CLD

1, 2

Yes

ESRD

CBN

Blank

WRLS_CLD

1, 2

Yes

ESRD

CBN

Blank

WRSL_CLD

2, 3

Yes

ESRD

CBN

Blank

WRLS_CLD

2, 3

Yes

ESRD

CBN

Blank

WRLS_CLD

2, 3

Yes

ESRD

CBN

Blank

WRLS_CLD

2, 3

ESRD

CBN

Blank

WRLS_CLD

2, 3

ESRD

CBN

Blank

WRLS_CLD

2, 3

Yes

WSRD

CBN

ESRD

WRLS_STD

Yes

ESRD

CBN

Blank

ESRD

WRLS_STD

Yes

ESRD

Blank

CBN

ESRD

not
supported

Yes

ESRD

CBN

ESRD

WRLS_STD

Yes

ESRD

CBN

Blank

ESRD

WRLS_STD

Yes

ESRD

CBN

ESRD

WRLS_STD

- continued -

Page 93

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

CG-EWCG-001
Issue 3, January 6, 2004

- continued ISUP
Parameter
Option

OLI
Wireless

CpCAT
CdPN
Emergency

CPN

CHGN

GDP

NDET
signaling
option

Note(s)

Yes

ESRD

CBN

Blank

ESRD

WRLS_STD

ESRD

CBN

ESRD

WRLS_STD

ESRD

CBN

Blank

ESRD

WRLS_STD

NOTES:
1. This ISUP parameter option is widely supported in the U.S. It is estimated that 95% of the
E9-1-1 selective routers deployed in the U.S. support this option when the selective router has
been equipped with wireless E9-1-1 features.
2. "Blank"-- this parameter MUST NOT be populated.
3. This ISUP parameter option is available in some areas. It is estimated that 50% of the E9-1-1
selective routers deployed in the U.S. support this option when the selective router has been
equipped with wireless E9-1-1 features.

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

Calling Party Category parameter (CPC):

Prior to NA013 the Nortel DMS E9-1-1 Tandem (NDET) did not set or reference the CPC parameter
in the IAM of ISUP calls for E9-1-1 purposes.
In NA013, feature 59006371 entitled "E9-1-1 ISUP Enhancements" implemented setting the CPC
parameter in the outgoing IAM of ISUP E9-1-1 calls to "Emergency Service Call" which is a value of
#E0. This was to fulfill Telcordia standards. Even though the NDET began setting the CPC parameter, the
logic still did not require this value to be set to recognize E9-1-1 calls.
In NA016, feature 59029627 entitled "E9-1-1 ISUP and Log Enhancements" introduced a new Boolean sub
field named DEDICATD for the E9-1-1 option on ISUP IT trunks incoming to the tandem. If this Boolean
value is set to Y, the NDET assumes the trunk is dedicated to E9-1-1 traffic and the NDET does not check
the CPC parameter. If the DEDICATD Boolean is set to N, the NDET assumes the trunk is being shared
for both E9-1-1 and non-E9-1-1 traffic, and the NDET checks the CPC parameter to identify E9-1-1 calls.
A.10.2

Originating Line Parameter (OLI):

Prior to NA013 the Nortel DMS E9-1-1 Tandem did not set or reference the OLI parameter in the IAM of
ISUP calls for E9-1-1 purposes.
In NA013, Nortel feature 59006371 entitled "E9-1-1 ISUP Enhancements" implemented setting the
OLI parameter in the outgoing IAM for wireless E9-1-1 calls to "Cellular Services Type 1" (#3D) if the
originating office did not send the parameter. If the originating office sends the parameter, the NDET does

Page 94

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

not modify it, it simply passes whatever value it receives. Once again, the NDET sets this value, but as of
NA013 does not use it to identify wireless calls.
In NA016, the NDET began checking the OLI parameter on wireless E9-1-1 calls ONLY when using AIN
Selective routing. If the received value was #3d, #3e, or #3f (61, 62, 63), the ChargePtyStationType was
set accordingly in the TCAP TAT message to the remote database. If the originating wireless office did not
send the parameter, the NDET set the ChargePtyStationType to #3d (61) so the remote database knows to
use the correct parameter to perform Selective Routing. Other than when using AIN Selective routing,
the OLI parameter is not used for E9-1-1 purposes. If BellSouth NDET is running software NA016 or
higher and IF AIN OFF-BOARD SELECTIVE ROUTING IS BEING USED by the NDET, BellSouth will
require the WSP to provide the OLI parameter as defined in this document.

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

Why is BellSouth issuing this document?

There have been conflicting views on the meaning of the terms "CAS" and "NCAS" in the Phase 2
environment, and on what data should be placed in the various IAM parameters of an SS7 wireless call.
NENA recognized this conflict and established a committee that included members from the wireless
carriers, service providers, and public safety community. They created the "NENA 05-501 Technical
Information Document on SS7 Guidelines for MSC to Selective Router Connectivity" document so that
9-1-1 Service System Providers could clearly define the call setup methods supported in their respective
networks. BellSouth is documenting our supported interconnection guidelines through the perspective of
the NENA document so that all wireless carriers and switch providers see the requirements in a consistent
and uniform method.
A.11.2

Do I have to change my existing trunks to SS7?

No, this is an additional signaling option. As a WSP you should determine if it fits your needs. If you
choose to do so, BellSouth will utilize the same basic process that you currently use when ordering
E9-1-1 trunks. This document is merely a tool to clarify the interconnection requirements for wireless
E9-1-1 service if you intend to utilize SS7 signaling.
A.11.3
Will this let me deliver ESRDs/ESRKs from more than one NPA on the SS7
trunk group?
SS7 signaling does allow multiple NPAs to be delivered over a common trunk group. BUT, this may
be dependent on how default routing is defined.
A.11.4

Will this let me reduce the number of trunk groups I have in place?

Separate trunk groups may still be required dependent on how default routing is defined, and/or dependent
on congestion control needs.

Page 95

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

CG-EWCG-001
Issue 3, January 6, 2004

A.11.5
What if I don’t have SS7 signaling "A" link connectivity to support trunking
to the appropriate NDET?
You can order it through your normal BellSouth circuit ordering procedures. See BellSouth TR 73554
Issue D, December 2002 (or later), BST GUIDELINES TO TECHNICAL PUBLICATION GR-905-CORE
for details on 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.
A.11.6

What do I do for Continuity Testing on these SS7 trunks?

BellSouth encourages the use of continuity testing for 911 trunks using SS7 signaling, with the testing
rate of 100%. We also recommend the use of continuity tone levels of Transmit High - Receive High for
4 wire or digital switches (i.e., 4W4W (5ESS), THRH (DMS-100), etc.). We have no provisions to
deviate from the national standards of THRH if digital, and TLRH if the MSC is a 2-wire analog switch,
which isn’t likely today. If you need any other continuity test, please let your account team know so
that it can be provisioned separately.

A.12 11.0 Attachment "C" - Wireless Customer Checklist
Wireless Customer Checklist (in no particular order):
•
•
•

•
•
•
•

Does the MSC have SS7 signaling link connectivity to support trunking to the appropriate
NDET?
Do we know what call scenario we plan to follow? (i.e. WCM or NCAS WITH the BellSouth
hybrid functionality, etc.)
Do we know what trunk continuity test levels, and testing percentages that we plan to use?
(BellSouth encourages that the percentage be 100%.) Remember, BellSouth has no provisions
to deviate from the national standards of THRH if digital, and TLRH if the MSC is a 2-wire
analog switch, which isn’t likely today.
Do we know what TCICs we’re going to use?
Are the proper Destination and Originating Point Codes identified for the new trunk group(s)?
Is this group properly ordered as 1-Way, outgoing from the MSC, SS7, with the Mobile Carrier
office as the "A" end, and the BellSouth office as the "Z" end?
Do we have a testing method to generate a call on the SS7 E9-1-1 group, and a written Call
Through Test Plan to ensure these trunks are working correctly BEFORE we put live wireless
E9-1-1 service on them?

NOTE: This list is NOT intended to be all inclusive of the steps necessary to deploy wireless E9-1-1
service using SS7 signaling.
NOTE: Specific information regarding BellSouth’s point codes may be obtained from each carrier’s
BellSouth’s account team when orders are being placed for SS7 controlled trunk groups.

Page 96

CG-EWCG-001
Issue 3, January 6, 2004

Wireless E911 Guide
BellSouth Wireless E9–1–1/SS7 Interconnection
Guide

KEYWORDS

Wireless Carrier
BST Wireless E911

Page 97

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.4
Linearized                      : No
Warning                         : Invalid xref table

EXIF Metadata provided by EXIF.tools

Bellsouth E911 Users Manual

E911 to the manual 98e9d60e-61da-43f5-94c6-cd1ab3cb2701

Navigation menu

Versions of this User Manual:

Views

Navigation