Sie sind auf Seite 1von 83

TPG–00-001 Bell Atlantic Supplement

Issue 1, June 2000 Table of Contents

Bell Atlantic Supplement


Common Channel Signaling (CCS)
Network Interface Specification

Contents

1 INTRODUCTION.........................................................................................................1-1
1.1 GENERAL ...................................................................................................................1-1
1.2 P URPOSE....................................................................................................................1-1
1.3 ORGANIZATION OF THE DOCUMENT ................................................................................1-1
1.4 R ELATED DOCUMENTS .................................................................................................1-3
2 CCS NETWORK INTERCONNECTION ARCHITECTURE...........................................2-1
2.1 T YPES OF S IGNALING ACCESS ........................................................................................2-1
2.1.1 Signaling for Exchange Access Feature Groups.........................................................2-1
2.1.1.1 Feature Group D Service Arrangements................................................................................................2-1
2.1.1.2 Feature Group B Terminating Service....................................................................................................2-2
2.1.2 Bell Atlantic CCS Database Access.........................................................................2-2
2.1.3 Unbundled Signaling Services................................................................................2-2
2.2 P OINTS OF S IGNALING INTERCONNECTION WITH THE B ELL ATLANTIC NETWORK ....................2-2
2.2.1 Signaling Access Via Bell Atlantic STP Pairs...........................................................2-2
2.2.2 Signaling Points of Interface (SPOI).......................................................................2-3
2.2.3 STP and SPOI Location Information.......................................................................2-4
2.3 S IGNALING LINK AND LINK S ET R EQUIREMENTS ..............................................................2-4
2.3.1 Signaling Link Interface........................................................................................2-4
2.3.1.1 Current Link Interface................................................................................................................................2-4
2.3.1.2 Potential Future Link Interfaces.............................................................................................................2-4
2.3.2 Link Diversity Considerations................................................................................2-5
2.3.3 Signaling Link Set Sizing and Engineering Criteria..................................................2-5
2.3.3.1 General...........................................................................................................................................................2-5
2.3.3.2 D Link Sets...................................................................................................................................................2-6
2.3.3.3 Summary of Link Set Sizing Criteria......................................................................................................2-7
3 ADMINISTRATIVE CONDITIONS OF INTERCONNECTION......................................3-1
3.1 SS7 INTERCONNECT INFORMATION QUESTIONNAIRE..........................................................3-1
3.2 INTERCONNECTION AND NON -DISCLOSURE AGREEMENTS....................................................3-1
3.3 SS7 P ROTOCOL C ONFORMANCE/P RE-INTERCONNECTION T ESTING R EQUIREMENTS .................3-1
3.4 C OMPATIBILITY T ESTING .............................................................................................3-2
3.5 ICN P OINT C ODE ASSIGNMENTS ....................................................................................3-2
3.6 DISTRIBUTION AND S HARING OF P OINT C ODE INFORMATION ...............................................3-2
3.7 GATEWAY S CREENING AT B ELL ATLANTIC STP S..............................................................3-2
3.8 S ERVICE INTERVALS ....................................................................................................3-3
3.9 P OST-INTERCONNECTION R ESPONSIBILITIES AND R ELATIONSHIPS .........................................3-3
4 CAPABILITIES SUPPORTED - INTERNETWORK CALL CONTROL..........................4-1
4.1 ORIGINATING ACCESS SS7 ISUP PARAMETERS S UPPORTING NON -ISDN ACCESS ....................4-1
4.1.1 Calling Party Number (CPN)................................................................................4-2
4.1.2 Charge Number...................................................................................................4-3
4.1.3 Originating Line Information Parameter.................................................................4-3
4.1.4 Carrier Selection Parameter..................................................................................4-3
4.1.5 Transit Network Selection.....................................................................................4-3
4.1.6 Jurisdiction Information Parameter........................................................................4-3
Bell Atlantic Supplement TPG-00-001
Table of Contents Issue 1, March 2000

4.1.7 Generic Address Parameter...................................................................................4-4


4.1.8 Service Code Parameter........................................................................................4-4
4.1.9 Carrier Identification Parameter............................................................................4-4
4.1.10 Hop Counter...................................................................................................4-4
4.1.11 Generic Name Parameter...................................................................................4-4
4.1.12 Original Called Number Parameter....................................................................4-4
4.1.13 Redirecting Number Parameter...........................................................................4-4
4.1.14 Redirection Information Parameter.....................................................................4-5
4.2 ADDITIONAL SS7 ISUP PARAMETERS S UPPORTING INTEGRATED S ERVICES DIGITAL NETWORK
(ISDN).............................................................................................................................4-5
4.2.1 Access Transport Parameter (ATP).........................................................................4-5
4.2.2 Generic Address Parameter (GAP)..........................................................................4-5
4.3 P ROCEDURES FOR T ONES AND ANNOUNCEMENTS ..............................................................4-5
5 CAPABILITY-RELATED PROTOCOL.........................................................................5-1
5.1 ISDN USER P ART INTERNETWORK C ALL C ONTROL P ROTOCOL ............................................5-1
5.1.1 Address Complete Message....................................................................................5-1
5.1.2 Answer Message..................................................................................................5-1
5.1.3 Circuit Reservation Message..................................................................................5-1
5.1.4 Circuit Reservation Acknowledgement Message.........................................................5-1
5.1.5 Continuity Check.................................................................................................5-2
5.1.6 Exit Message.......................................................................................................5-2
5.1.7 Initial Address Message........................................................................................5-2
5.1.8 Release Message..................................................................................................5-2
5.1.9 Release Complete.................................................................................................5-2
5.1.10 Resume Message..............................................................................................5-2
5.1.11 Suspend Message.............................................................................................5-2
5.1.12 Call Progress Message.....................................................................................5-2
5.1.13 Confusion Message..........................................................................................5-2
5.2 ISUP PROTOCOL TO S UPPORT ISDN ACCESS ....................................................................5-3
5.2.1 Call Progress Message.........................................................................................5-3
5.2.2 Initial Address Message........................................................................................5-3
5.3 NX64........................................................................................................................5-3
6 ISUP NON-CAPABILITY RELATED PROTOCOL........................................................6-1
6.1 DUAL S EIZURE (GLARE) ON 2-WAY T RUNKS....................................................................6-1
6.2 C ONTINUITY C HECK (COT)..........................................................................................6-1
6.3 ISUP N ON -CAPABILITY (NON -CALL ) R ELATED MESSAGES.................................................6-1
6.3.1 Blocking Messages...............................................................................................6-1
6.3.2 Unblocking Messages...........................................................................................6-2
6.3.3 Circuit Group Blocking Messages...........................................................................6-2
6.3.4 Circuit Group Unblocking Messages.......................................................................6-2
6.3.5 Reset Circuit Message..........................................................................................6-2
6.3.6 Circuit Group Reset Messages...............................................................................6-2
6.3.7 Circuit Query Messages........................................................................................6-2
6.3.8 Circuit Validation Test Messages...........................................................................6-2
6.3.9 Continuity Check Request Message and Loop Back Acknowledgement Message...............6-3
6.3.10 Unequipped Circuit Identification Code Message...................................................6-3
7 SIGNALING CONNECTION CONTROL PART (SCCP) PROTOCOL............................7-1
7.1 C ONNECTIONLESS S ERVICE ...........................................................................................7-1
7.2 SCCP R OUTING .........................................................................................................7-1
7.3 SCCP M ANAGEMENT..................................................................................................7-3
8 TRANSACTION CAPABILITIES APPLICATION PART (TCAP) PROTOCOL...............8-1
8.1 GENERAL DESCRIPTION OF TCAP P ROCEDURES ................................................................8-1
8.1.1 General Transaction Procedures............................................................................8-1
TPG–00-001 Bell Atlantic Supplement
Issue 1, June 2000 Table of Contents

8.1.2 General Component Procedures.............................................................................8-2


8.2 GENERAL F ORMATTING P RINCIPLES................................................................................8-3
9 SERVICE OFFERINGS................................................................................................9-1
9.1 CLASS SM ..................................................................................................................9-1
9.2 LINE INFORMATION DATA B ASE (LIDB) ACCESS ...............................................................9-1
9.3 T OLL -FREE S ERVICE....................................................................................................9-1
9.4 891 C ALLING C ARD S ERVICE ........................................................................................9-2
9.5 C ALLING NAME DELIVERY (CNAM)...............................................................................9-2
10 INTERCONNECTION IN SUPPORT OF AIN...............................................................10-1

11 LOCAL NUMBER PORTABILITY (LNP)....................................................................11-1


11.1 C ALL S ETUP IN AN LNP E NVIRONMENT .....................................................................11-1
11.1.1 ICN to Bell Atlantic Originating Access..............................................................11-1
11.1.1.1 Bell Atlantic Provides Transport for ICN LNP Call Setup...........................................................11-1
11.1.1.2 Bell Atlantic AT/SSP Queries LNP Database..................................................................................11-2
11.1.1.3 ICN SSP Queries Bell Atlantic LNP Database................................................................................11-2
11.1.2 Bell Atlantic to ICN Originating Access..............................................................11-3
11.1.3 ICN to Bell Atlantic Terminating Access.............................................................11-3
11.1.4 Bell Atlantic to ICN Switching Office.................................................................11-3
11.2 R OUTING OF S ERVICE-RELATED MESSAGES IN AN LNP E NVIRONMENT ............................11-3
12 NUMBER POOLING...................................................................................................12-1

13 INTERCONNECTION WITH WIRELESS NETWORKS FOR CALL SETUP................13-1

14 SIGNALING LINK PHYSICAL-LEVEL SPECIFICATIONS.........................................14-1


14.1 LINK F ACILITIES ....................................................................................................14-1
14.2 LINK DIVERSITY R EQUIREMENTS ...............................................................................14-1
14.2.1 Definition of Link Diversity..............................................................................14-1
14.2.2 Diversity Conformance Specifications.................................................................14-1
14.2.2.1 Bell Atlantic STP to ICN STP...............................................................................................................14-1
14.2.2.2 Bell Atlantic STP to ICN SEP...............................................................................................................14-2
14.2.3 Ramifications of Diversity Non-Conformance.......................................................14-2
15 PERFORMANCE........................................................................................................15-1

16 TIMER VALUES........................................................................................................16-1

17 MAINTENANCE & TESTING.....................................................................................17-1


17.1 B ELL ATLANTIC P OSITION – C ERTIFICATION AND T ESTING P ROCEDURES .........................17-1
17.2 C HANNEL S ERVICE UNIT (CSU) – N O DS-0(A) INTERFACE ............................................17-2
17.3 DS-0(A) INTERFACE ................................................................................................17-2
APPENDIX A: TRANSLATION TYPE VALUES.................................................APPENDIX A-1

APPENDIX B: TONES AND ANNOUNCEMENTS...............................................APPENDIX B-1

APPENDIX C: LIST OF CONFORMANCE TESTS.............................................APPENDIX C-1

GLOSSARY.......................................................................................................GLOSSARY-1
Bell Atlantic Supplement TPG-00-001
Table of Contents Issue 1, March 2000
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Introduction

1 Introduction

1.1 General
The Common Channel Signaling (CCS) network has become a critical foundation for all
wireline and wireless carrier networks. The CCS network is rapidly expanding to support new
and existing services and network capabilities including Local Number Portability, various
Advanced Intelligent Network (AIN)/IN based services, and network unbundling. CCS network
technology is evolving into many new areas such as high speed signaling links and broadband
network interworking. In this rapidly changing environment, it is critical that carriers
interconnect their CCS networks in such a way so as to maintain network reliability, service
integrity, and network security.

The Telcordia Technologies document GR-905-CORE, Common Channel Signaling Network


Interface Specification (CCSNIS) Supporting Network Interconnection, Message Transfer Part
(MTP), and Integrated Services Digital Network (ISDN) User Part (ISUP), provides a detailed
description of current industry practices regarding CCS Network architecture, and defines
specifications relating to CCS Network Interconnection.

This document is a supplement to GR-905-CORE, not a replacement. This document


describes Bell Atlantic’s specific requirements in providing interface capabilities to ICNs
(Interconnecting Networks, i.e., Interexchange, Independent, Reseller, etc.) for connecting
to Bell Atlantic’s CCS network for those capabilities and optional parameters which GR-905-
CORE defines as being negotiable between a BOC and the ICN. This document should be used
in conjunction with the Bell Atlantic Principles for Common Channel Signaling Network
(CCSN) Interconnecting Networks document (TPG-00-002). The Principle’s document
identifies requirements of the interconnection beyond the point of interconnection and into
the interconnected network to ensure network security and reliability within Bell Atlantic.
1.2 Purpose
This document provides Interconnecting CCS Networks (ICNs) with Bell Atlantic-specific
information required for interconnecting with the Bell Atlantic CCS network. It does not
replace any mandatory requirements as specified in GR-905-CORE. It does define those
optional capabilities which GR-905-CORE has reserved for BOC implementation, and which
Bell Atlantic will implement and support. It also defines the interconnection architecture
supported by Bell Atlantic. This document will describe Bell Atlantic’s CCS network
interconnection requirements, and the CCS network interconnection architectures currently
supported by Bell Atlantic.
1.3 Organization of the Document
This interface specification consists of seventeen sections and three appendices.
Section 1 provides the introduction, including the intended audience, the purpose, the
organization of the document, and a listing of related documents.
Section 2 describes the Bell Atlantic CCS network interconnection architecture including
points of interconnection in the Bell Atlantic network, types of SS7 signaling access, and SS7
signaling link requirements (e.g., link interfaces, signaling points of interface (SPOI), link
diversity requirements, link engineering requirements).

1-1
Bell Atlantic Supplement TPG-00-001
Introduction Issue 1, March 2000

Section 3 describes the administrative conditions of CCS network interconnection including


non-disclosure agreements, point code assignments, gateway screening performed by Bell
Atlantic, and service intervals.
Section 4 describes the capabilities supported for internetwork call control including non-
ISDN access parameters, additional ISDN access parameters, and optional parameters for
inter-exchange carrier (IXC) interconnection.
Section 5 describes capability-related protocol requirements at the interface. This includes
non-ISDN access, ISDN access, and nx64 multirate connections.
Section 6 describes the non-capability related protocol requirements for duel seizure on two-
way trunks, continuity check, and non-capability related ISUP messages at the interface.
Section 7 describes the Signaling Connection Control Part (SCCP) protocol requirements for
connectionless service, SCCP routing, and SCCP management.
Section 8 describes the Transaction Capabilities Application Part (TCAP) protocol
requirements including a general description of TCAP procedures and formatting procedures.
Section 9 describes Bell Atlantic service offerings including CLASSSM1 , LIDB, Toll-Free
Service, 891 Calling Card Service, and Calling Name Delivery (CNAM).
Section 10 describes CCS network interconnection in support of Advanced Intelligent
Network (AIN) services.
Section 11 describes the impact of Local Number Portability (LNP) on call setup between
Bell Atlantic and an ICN, and the routing of service related messages in an LNP
environment.
Section 12 describes number pooling requirements as implemented in the Bell Atlantic
network.
Section 13 describes interconnection with wireless networks for call setup.
Section 14 describes physical level specifications including the bearer facility transmission
rate, and SS7 link diversity requirements.
Section 15 describes Bell Atlantic’s performance objectives regarding network availability and
reliability.
Section 16 defines Bell Atlantic’s specific CCS network timer values associated with initiated
messages and responses.
Section 17 provides guidelines for the testing and maintenance of the CCS network interface
between Bell Atlantic and the ICN.
Appendix A defines the format and coding of Bell Atlantic-recognized translation type
values.
Appendix B provides details on tones and announcements.
Appendix C provides a list of conformance tests that are required to be used by the ICN for
the validation of network elements prior to interconnection with the Bell Atlantic network.

1
CLASS is a service mark of Telcordia Technologies

1-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Introduction

1.4 Related Documents


This document in conjunction with GR-905-CORE will provide ICNs with compatibility
information required for interconnection to the Bell Atlantic CCS Network. In addition to
conforming to the documents referenced above, the ICN must conform to the SS7 protocol
requirements defined in GR-246-CORE. ICNs should also be compatible with relevant
specifications in ANSI T1S1 Standards (refer to ANSI T1.111 and T1.113).
The following are related reference documents:
GR-82-CORE, Signaling Transfer Point Generic Requirements, Issue 3 (Telcordia, December
1999)
GR-246-CORE, Specification of Signaling System Number 7, Issue 4 (Telcordia, December
1999)
TR-NPL-000258, Compatibility Information for Feature Group D Switched Access Service,
Issue 1 (Telcordia, October 1985)
GR-317-CORE, Switching System Generic Requirements for Call Control Using the
Integrated Services Digital Network User Part (ISDNUP), Issue 3 (Telcordia, November
1999)
GR-394-CORE, Switching System Generic Requirements for Inter-exchange Carrier
Interconnection Using the Integrated Services Digital Network User Part (ISDNUP),
Issue 3 (Telcordia, November 1999)
TR-NWT-000444, Switching System Generic Requirements Supporting ISDN Access Using
the ISDN User Part, Issue 3 (Telcordia, May 1993)
GR-499-CORE, Transport System Generic Requirements (TSGR): Common Requirements,
Issue 2 (Telcordia, December 1998)
GR-606-CORE, Common Channel Signaling, Section 6.5 (A module of LSSGR, FR-64), Issue
3 (Telcordia, November 1999)
GR-905-CORE, Common Channel Signaling (CCS) Network Interface Specification
(CCSNIS) Supporting Network Interconnection, Message Transfer Part (MTP), and
Integrated Services Digital Network User Part (ISDNUP), Issue 3 (Telcordia, December
1999)

TR-NWT-000938, Integrated Services Digital Network (ISDN): Network Transmission


Interface and Performance Specifications, Issue 2 (Telcordia, April 1993)

GR-954-CORE, Common Channel Signaling (CCS) Network Interface Specification


(CCNIS) Supporting Line Information Database (LIDB) Services, Issue 2 (Telcordia,
March 1997)

GR-1357-CORE, Common Channel Signaling Network Interface Specification (CCSNIS)


Supporting Switched DS1/Switched Fractional DS1 Service Capability (SWF-DS1), Issue
1 (Telcordia, May 1999)

GR-1428-CORE, CCS Network Interface Specification (CCSNIS) Supporting Toll-Free


Service, Issue 2 (Telcordia, May 1995)

1-3
Bell Atlantic Supplement TPG-00-001
Introduction Issue 1, March 2000

GR-1429-CORE, Common Channel Signaling Network Interface Specification (CCSNIS)


Supporting Call Management Services, Issue 1 (Telcordia, August 1994)

GR-1431-CORE, Common Channel Signaling Network Interface Specification (CCSNIS)


Supporting Broadband Services, Issue 5 (Telcordia, November 1999)

GR-1432-CORE, Common Channel Signaling Network Interface Specification (CCSNIS)


Supporting SCCP and TCAP, Issue 2 (Telcordia, December 1999)

GR-1434-CORE, CCS Network Interface Specification (CCSNIS) Supporting Wireless Services


Providers, Issue 3 (Telcordia, December 1998)

GR-1519-CORE, CCS Network Interface Specification (CCSNIS) Supporting TR-1188 Calling


Name Delivery, Issue 1 (Telcordia, October 1994)

GR-2863-CORE, CCS Network Interface Specification (CCSNIS) Supporting Advanced


Intelligent Network (AIN), Issue 2 (Telcordia, December 1995)

GR-2878-CORE, Generic Requirements for CCS Nodes Supporting ATM High-Speed


Signaling Links (HSLs), Issue 4 (Telcordia, December 1999).

GR-2946-CORE, CCSNIS Supporting Network Interconnection Using High-Speed Signaling


Links (HSL), Issue 3 (Telcordia, December 1999)

TRQ No. 02, Number Portability Switching Systems (American National Standards Institute,
April 1999)

TRQ No. 03, Number Portability Database and Global Title Translation (American National
Standards Institute, April 1999)

TRQ No. 04, Thousand Block Number Pooling Using Number Portability (American
National Standards Institute, July 1999)

ANSI T1.234-1993, Signaling System Number 7 (SS7) – MTP Levels 2 and 3 Compatibility
Testing

ANSI T1.235-1993, Signaling System Number 7 (SS7) – SCCP Class 0 Compatibility Testing
ANSI T1.236-1993, Signaling System Number 7 (SS7) – ISDN User Part Compatibility
Testing

ITU-T Recommendation Q.780, Signaling System No. 7 Test Specification – General


Description, (ITU, 1995)

ITU-T Recommendation Q.781, Signaling System No. 7 – MTP Level 2 Test Specification,
(ITU, 1996)

ITU-T Recommendation Q.782, Signaling System No. 7 – MTP Level 3 Test Specification,
(ITU, 1996)

ITU-T Recommendation Q.784.1, Signaling System No. 7 – ISUP Basic Call Test
Specification, (ITU, 1996)

1-4
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 CCS Network Interconnection Architecture

2 CCS NETWORK INTERCONNECTION ARCHITECTURE

2.1 Types of Signaling Access

Bell Atlantic offers the interconnection of its Common Channel Signaling (CCS) network
with the CCS networks of other telecommunications carriers (TCs), i.e., Interconnecting CCS
Networks (ICNs), to support the SS7 signaling interactions necessary for interoperability of
both carriers’ networks and the provision of telecommunications services. These interactions
include:
• Exchange-access signaling for the control of circuit-switched trunks between the Bell
Atlantic local exchange network and the networks of Interexchange Carriers (IXCs),
independent Local Exchange Carriers (LECs), Competitive Access Providers (CAPs),
facilities-based Competitive Local Exchange Carriers (CLECs), Tandem Service Providers
(TSPs), Other LATA Carriers (OLCs), Wireless Service Providers (WSPs), Internet
Service Providers (ISPs), and other, non-traditional telecommunications carriers;

• ICN signaling access to data base services offered by Bell Atlantic; and

• Access to BA’s STPs on an unbundled basis by CLEC ICNs in Bell Atlantic’s territory.

These types of signaling access are described below.

All such signaling interconnection arrangements are offered by Bell Atlantic. In accordance
with Bell Atlantic’s Principles for CCSN Interconnecting Networks. That document
establishes the responsibilities of the ICN and Bell Atlantic in ensuring the security and
integrity of the signaling interactions, both during and after the establishment of
interconnection, both at and beyond the point of interconnection.

2.1.1 Signaling for Exchange Access Feature Groups


SS7 signaling will be provided on switched-access Feature Group D (FGD) originating and
terminating service, and on Feature Group B (FGB) terminating service.
2.1.1.1 Feature Group D Service Arrangements
SS7 signaling connections will be provided when the SS7 option is ordered on FGD exchange
access arrangements. (SS7 is filed as a switched access ordering option in Bell Atlantic Tariff
FCC No. 1.) Specifically, SS7 signaling interconnection is offered as part of the following
FGD service exchange-access trunking arrangements:

• SS7 Direct-Routed:
An SS7-controlled trunk group is provided directly from the Bell Atlantic (BA) End
Office (EO) to an ICN Point of Presence (POP) switch in the Local Access and
Transport Area (LATA).

• SS7 via Access Tandem (AT)

2-1
Bell Atlantic Supplement TPG-00-001
CCS Network Interconnection Architecture Issue 1, March 2000

Exchange access calls are switched between the ICN POP and the BA EO via a BA
AT and SS7-controlled trunk groups. There are two applicable cases:
- Full SS7: SS7-controlled trunk groups are provided from the BA EO to the BA
AT, and from the BA AT to the ICN POP; and

- SS7/MF Interworking: A trunk group controlled via in-band Multi-Frequency


(MF) signaling is provided from the BA EO to the BA AT, and an SS7-
controlled trunk group is provided from the BA AT to the ICN POP. Such
arrangements are intended to be provided on a transitional basis only until all
BA EO-AT trunking is upgraded to SS7 signaling.

• SS7 Tandem overflow (Transitional)


SS7-controlled primary high-usage trunk groups are provided between the BA EO
and the ICN POP, with overflow traffic accommodated on SS7-controlled alternate
final trunk groups to the BA AT. An SS7-controlled trunk group is provided from
the BA AT to the ICN POP. Such arrangements are offered only on a transitional
basis.

• Multi-ACTL (Multiple POPS)

2.1.1.2 Feature Group B Terminating Service


SS7 signaling will also be offered on FGB terminating service. The FGB trunk group,
however, must be arranged as one-way terminating. (Bell Atlantic will not combine MF and
SS7 signaling for a two-way trunk group).

2.1.2 Bell Atlantic CCS Database Access


Bell Atlantic also offers signaling access to its Service Control Point (SCPs), supporting a
number of database services, e.g., Toll-Free/8NN Data Base Service, Line Information Data
Base (LIDB) services, and Local Number Portability (LNP) database services. More
information on the specific data base services offered on an interconnection basis are
described separately in Sections 9, 10, 11, and 12 of this document.

2.1.3 Unbundled Signaling Services


Bell Atlantic also offers unbundled access to its CCS network’s services to CLECs operating
in its territory, as required by law, subject to contractual business arrangements and/or
applicable tariffs. This includes access to - or use of - BA’s SS7 signaling network via access
to BA STPs or STP link ports.

2.2 Points of Signaling Interconnection with the Bell Atlantic Network

2.2.1 Signaling Access Via Bell Atlantic STP Pairs

The points of signaling interconnection, at which ICN CCS networks connect to the Bell
Atlantic CCS network, will be at designated BA Signaling Transfer Point (STP) pairs. BA will
support two modes of such signaling interconnection to its STP pairs:

2-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 CCS Network Interconnection Architecture

• via D-link-set quads from ICN STP pairs, and


• via A-link-set pairs directly from ICN Signaling End Points (SEPs).

Interconnection of ICN SEPs via E-link sets to alternate BA STP pairs is not offered at this
time.

The following guidelines apply regarding ICN interconnection to BA STP pairs for signaling
access to BA SEPs and services:

1. ICN interconnection for signaling access to BA CCS Switching Offices/Service Switching


Points (CCS SOs/SSPs) in a particular geographic area or “sector” of Bell Atlantic’s
network will be via a BA STP pair designated by BA as serving that sector.

2. Sectors as defined here may be a LATA or a subset of a LATA For purposes of efficiency
in portions of its network, BA has chosen to serve signaling of several LATAs via a
single STP pair. Signaling interconnection to address BA switching offices in any of these
consolidated areas shall be at BA’s designated serving STP pair.

3. ICN interconnection for signaling access to multiple BA network sectors through a BA
STP pair may be considered on a case-by-case basis, subject to business agreements or
applicable tariffs, and where technically feasible and allowed or mandated by regulation.
Again, such arrangements may be discussed at a pre-ASR meeting between the ICN and
BA contacts.

4. ICN interconnection for signaling access to database services will be via a BA-designated
STP pair associated with an SCP pair or other database providing each service.

An ICN’s signaling interconnection needs with respect to BA’s network will be assessed
through a “pre-ASR” SS7 Interconnect Information Questionnaire, which will be provided to
the ICN, along with supporting reference documentation, by BA’s Project Manager with the
ICN. Prior to the ICN’s submission of an Access Service Request (ASR), the details of the
questionnaire and specific interconnection arrangements may be addressed at a “pre-ASR”
meeting between the ICN and BA contacts, which will be arranged at the request of the ICN
or Bell Atlantic’s Project Manager.

2.2.2 Signaling Points of Interface (SPOI)

Bell Atlantic offers facility “meet-points” or Signaling Points of Interface (SPOI), at which
interoffice transmission facilities supporting ICN signaling links to BA STPs may be
terminated. These may or may not be co-located with the BA STPs. Unless otherwise
provided through specific business agreements, the ICN will be responsible for the cost and
operation of the link facilities to the SPOI.

For unbundled access to BA STP link ports, collocation of the link facility termination with
the serving STP is required. The ICN will be required to provide link facilities to the
collocation cage at the BA STP site.

2-3
Bell Atlantic Supplement TPG-00-001
CCS Network Interconnection Architecture Issue 1, March 2000

For exchange access, Bell Atlantic will interconnect with Interexchange Carrier (IXC) ICNs
at any mutually agreed-upon SPOI within the LATA for which exchange access trunk
signaling is provided.

As allowed by regulation, Bell Atlantic is currently in the process of consolidating its CCS
network toward a more centralized deployment of its STPs. As a result, its serving STP pairs
may be physically located in different LATAs from the BA SEPs for which they support ICN
signaling access. Therefore, BA STPs and their ICN SPOIs may be physically located in
different LATAs.

To facilitate its STP consolidation plans, Bell Atlantic is willing to evaluate other ICN
proposals for other signaling interconnection arrangements based on sound engineering,
operations, and cost justifications.
2.2.3 STP and SPOI Location Information
The locations of BA STP pairs, their served network sectors and accessible data base services,
and more detailed information on corresponding SPOIs/facility meet-points for
interconnecting signaling links, are specified in the “pre-ASR” documentation supporting
the SS7 Interconnect Information Questionnaire, which will be provided to the ICN by BA’s
Project Manager.

2.3 Signaling Link and Link Set Requirements

2.3.1 Signaling Link Interface

2.3.1.1 Current Link Interface

For ICN signaling links terminating at its STP pairs, Bell Atlantic currently supports 56-
kilobit-per-second (Kbps) signaling link terminations using the SS7 protocol’s Message
Transfer Part Layer 2 (MTP2) as the link layer protocol over MTP1 and DS0-rate
interoffice facilities at the signaling data link layer. SS7 protocol and functional
specifications for 56 Kbps MTP2 signaling data links are specified in GR-246-CORE, Chapter
T1.111.2. Additional requirements on 56-Kbps link physical layer specifications are
presented separately in Section 14.1.

2.3.1.2 Potential Future Link Interfaces

In addition, Bell Atlantic is considering the inclusion of ATM-based 1.536 megabit-per-


second (Mbps) High Speed Signaling Links (HSLs), using the Signaling-ATM Adaptation
Layer (SAAL) protocol at the link layer for use at the ICN interface. Functional and
operations requirements for HSLs are specified in Telcordia GR-2878-CORE, Generic
Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links (HSLs).
Specifications for the use of HSLs in CCS network interconnection are specified in Telcordia
GR-2946-CORE, CCS Network Interface Specification (CCSNIS) Supporting Network
Interconnection Using High-Speed Links (HSLs). That document serves as a supplement to
Telcordia GR-905-CORE. However, HSL technology is relatively new in terms of its recent
deployment in North American Local Exchange Carrier (LEC) CCS networks. As such, the
use of HSLs for ICN interconnection with the BA CCS network is not supported at this time,
but may be offered at a future date.

2-4
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 CCS Network Interconnection Architecture

Bell Atlantic is also considering the deployment of new signaling transport technologies in its
STPs and SCPs that would allow for the delivery of SS7 MTP-user-part signaling messages
over connectionless Internet Protocol (IP-based) data networks. The most likely candidate
protocol for use in CCS network interconnection is the Internet Engineering Task Force’s
(IETF’s) Signaling Transport (SIGTRAN) protocol stack, which includes capabilities for SS7
message encapsulation and MTP network management interworking functions. Above the IP
packet layer, the SIGTRAN protocol uses the User Datagram Protocol (UDP), the Simple
Control Transmission Protocol (SCTP), and two adaptation layers for SS7 message
encapsulation and network management – the MTP3 User Adaptation (M3UA) layer, or the
MTP2 User Adaptation (M2UA) layer. Such technologies are still in their early phases of
definition and development, but may potentially be used to replace some conventional SS7
signaling links as currently used for SS7 network interconnection. Network interface
specifications for these technologies are not yet available. Future applications might include
ICN access to IP-capable BA STPs, which shall be capable of protocol interworking with
non-IP-capable SS7 signaling end points. Such IP-based signaling interconnection
arrangements are under consideration but are not offered by Bell Atlantic at this time. Future
deployment of such interfaces is contingent, not only on the availability of standardized
implementations, but also on Bell Atlantic’s ability to properly manage and monitor the
interface and to protect its network against the admission of inappropriate signaling
messages.

2.3.2 Link Diversity Considerations


Bell Atlantic requires and provides minimum 3-way diversity on D-link set quads and
minimum 2-way link diversity for A-link-set pairs as used in ICN interconnection. More
specific requirements on the physical diversity of ICN-BA signaling connections are
presented separately in Section 14.2 of this document.

2.3.3 Signaling Link Set Sizing and Engineering Criteria


The following link set sizing and traffic engineering guidelines are offered for ICN signaling
link sets. These criteria are intended to allow each ICN-BA interconnection arrangement to:

• meet the negligible cumulative downtime objectives for the CCS network backbone (as
specified in GR-246-CORE)

• avoid the inefficiencies and limitations attributed to the load sharing algorithm inherent
in the SS7 protocol’s use of Signaling Link Selection (SLS) codes to distribute signaling
traffic, and

• ensure that sufficient link set capacity is available to handle offered signaling traffic even
in failure-mode scenarios.

2.3.3.1 General

2-5
Bell Atlantic Supplement TPG-00-001
CCS Network Interconnection Architecture Issue 1, March 2000

Bell Atlantic shall require that ICNs to engineer their interconnecting links to meet the
ANSI standard average downtime objective of 10 minutes per year for a signaling route. This
objective is specified in GR-905-CORE and GR-246-CORE.

All carriers must meet the same engineering guidelines as used for internal Bell Atlantic links.
They are:

• no more than 0.4 Erlangs (in the absence of failures) for A links from switches
• no more than 0.2 Erlangs (in the absence of failures) for D-links from STPs with a
minimum of three-way diversity for the quad.

• Bell Atlantic is not currently required to permit direct interconnection of other carriers’
SCPs to its network. If and when such SCPs are connected to Bell Atlantic STPs but not
collocated with them, then their A links can be engineered to carry no more than 0.4
Erlangs (in the absence of failures), instead of the 0.2 Erlangs recommended for Bell
Atlantic SCPs.

2.3.3.2 D Link Sets


If 4-way diversity can be achieved across D-link set quads, the links can be engineered to a
maximum capacity of 0.4 Erlangs except under the following scenarios:

• Even with 4-way diversity, D links should be engineered to 0.2 Erlangs if the connected
STP pairs are collocated.

• In the case of a 4-way diverse quad of 8 links per link set, the maximum engineered
capacity should be 0.3 Erlang, since the loss of a single link will reduce that link set’s
capacity to that of four links because of the 5-bit SLS algorithm. This exception will end
with the use of 5-to-8 -bit SLS interworking.

B/D links can be deployed in complements of 1, 2, 4, or 8 links per link set with full
engineered capacity utilization (i.e. 0.2 * n links). B/D link sets of 3 links, however, will not
provide full capacity due to the limitations of the 5-bit signaling link selection algorithm.
Engineered at 0.2 Erlangs, the third link will raise the capacity of the link set from 0.4 to
0.53 Erlangs (instead of 0.6 Erlangs if full capacity could be realized.) The fourth link will
bring the link set to the full 0.8 Erlangs.

3-link link sets can be deployed under the following conditions:

• While inefficient, it may be appropriate in low-growth situations where a fourth link is


not required.

• Five-to-eight-bit SLS interworking is available today. With an 8-bit SLS, a 3-link link set
will have a capacity of 0.59 Erlangs or essentially full utilization. Link sets of 5, 6 and 7
members are not recommended with the 5-bit SLS method, since they provide no
incremental capacity above 4 links. However, the implementation of 8-bit SLS will
expand the maximum B/D link-set size from 8 to 16 links, and will enable a more even
distribution of traffic to links than is possible with today’s 5-bit SLS. As a result, all
incremental link additions below 8 and all but four above 8 will provide nearly full
capacity. The restrictions on 5, 6 and 7-link link sets can then be dropped along with the
0.3-Erlang restriction on 8-link link sets that are 4-way diverse.

2-6
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 CCS Network Interconnection Architecture

BA STPs will support the use of both 5-bit and 8-bit SLS codes at the network interface. The
use of 8-bit SLS codes is recommended to promote improved link utilization and more even
traffic distribution within combined link sets and link sets.
2.3.3.3 Summary of Link Set Sizing Criteria

Tables 2-1 and 2-2 summarize these guidelines for ICN A-link sets and D-link sets,
respectively.

Table 2-1. A-Link Set Sizing Criteria

Criteria With 5-bit SLS Codes With 8-bit SLS Codes


A-Link Set Size # 1, 2, 3*, 4, 6*, 8, 16 1, 2, 3*, 4, 5, 6*, 7*, 8, 10*,
(Links per link set) 11*, 13*, 16
Maximum Engineered 0.40 0.40
Occupancy (Erlangs per
Link) in Normal-Mode
Operation with 2-way
diversity.

Table 2-2. D-Link Sizing Criteria

Criteria With 5-bit SLS With 8-bit SLS With 5-8bit SLS
Codes & Codes Interworking
D-Link Set Size # 1, 2, 3*, 4, 8 1, 2, 3*, 4, 5*, 6*, 1, 2, 3*, 4, 8, 10, 11,
(Links per link set) 7*, 8, 11*, 16 13, 16+
Maximum Engineered 0.20 0.20 0.20
Occupancy (Erlangs per
Link) in Normal-Mode
Operation with 3-Way
diversity.
Maximum Engineered 0.40 0.40 0.40
Occupancy (Erlangs per (except 0.30 for
Link) in Normal-Mode 8 links)**
Operation with 4-way
diversity.

Table Notes:

* at reduced capacity
** 0.30 Erlangs for 8-link link sets; only if STPs are not collocated
+ nearly full capacity for 3, 5, 6, 7, 10, 11 and 13 links
++ only if STPs not collocated

# Intermediate link counts other than those cited in the tables are possible but provide no
incremental capacity relative to the next lower number cited, due to the SLS-code load
distribution algorithm and should therefore not be considered.

& D-link sets cannot have more than 8 links when using a 5-bit SLS code because there are
only 8 SLS code values (3 bits) available for assignment to the member links for these cases.

2-7
Bell Atlantic Supplement TPG-00-001
CCS Network Interconnection Architecture Issue 1, March 2000

It should be noted that action thresholds, at which link set capacity should be augmented,
should be set lower than the above engineered maximum occupancies, such that additional
links can be in place before busy-period traffic causes the engineered maximums to be
exceeded. Insufficient link capacity combined with link failures can result in network
congestion in both the ICN and the BA CCS networks. It is the responsibility of the ICN
network administration to monitor their interconnecting link traffic and take appropriate
action to order additional links from Bell Atlantic when action levels are exceeded. BA
Project Managers may similarly monitor ICN link utilization and may advise the ICN
administrations of needed additional link capacity at action levels lower than the cited
engineering objectives.

2-8
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Administrative Conditions of Interconnection

3 ADMINISTRATIVE CONDITIONS OF INTERCONNECTION

3.1 SS7 Interconnect Information Questionnaire


Each ICN’s signaling interconnection needs with respect to BA’s network will be assessed
through a “pre-ASR” SS7 Interconnect Information Questionnaire, which will be provided to
the ICN, along with supporting reference documentation, by BA’s Project Manager. The ICN
is expected to provide all necessary information requested on the questionnaire. Prior to the
ICN’s submission of an Access Service Request (ASR), the details of the questionnaire and
specific interconnection arrangements may be addressed at a “pre-ASR” meeting between the
ICN and BA contacts, which may be arranged at the request of the ICN or BA. After the
details of the interconnection arrangements are negotiated, the ICN must then submit an ASR
as well as execute interconnection and non-disclosure agreements.

3.2 Interconnection and Non-Disclosure Agreements


Interconnection and non-disclosure and agreements must be signed before interconnection
with Bell Atlantic is allowed. No orders for interconnection will be processed without those
signed agreements.

As part of the interconnection agreement, the ICN must adhere to Bell Atlantic’s Principles
for CCSN Interconnecting Networks. That document establishes the responsibilities of the
ICN and Bell Atlantic in ensuring the security and integrity of the networks’ signaling
interactions, both during and after the establishment of interconnection, both at and beyond
the point of interconnection.

3.3 SS7 Protocol Conformance/Pre-Interconnection Testing Requirements


All applicable SS7 protocol and functional interconnection requirements specified in
Telcordia FR-905, Common Channel Signaling Network Interface Specifications (CCSNIS)
Family of Requirements, must be met by the carrier equipment before interconnection is
allowed. The applicable GR documents within this family of requirements will depend upon
the specific services supported through the interconnection arrangement with Bell Atlantic’s
CCS network. A key specification within that family is Telcordia GR-905-CORE, Common
Channel Signaling (CCS) Network Interface Specification (CCSNIS) Supporting Network
Interconnection, Message Transfer Part (MTP), and Integrated Services Digital Network User
Part (ISDNUP). GR-905-CORE includes basic MTP signaling capabilities required for all ICNs
as well as ISUP interactions needed for call control on interconnecting trunks.

Additional GR documents in this family will apply to interconnection for data base access and
other services utilizing the SS7 Signaling Connection Control Part (SCCP) and Transaction
Capabilities Application Part (TCAP). These services and the applicable specifications are
discussed further in Sections 7 through 13 of this document.

Bell Atlantic expects all ICN equipment used for interconnection to conform to the protocol
and functional requirements specified in GR-905-CORE and the other aforementioned
specifications. Bell Atlantic expects the ICN to exercise due diligence in ensuring that the
elements they will be using for interconnection and the software releases that they deploy
(including any customization of that software) are in compliance with applicable standards
and industry agreements, and that said equipment has been tested for such conformance prior

3-1
Bell Atlantic Supplement TPG-00-001
Administrative Conditions of Interconnection Issue 1, March 2000

to interconnection. The carrier shall provide Bell Atlantic with evidence of that effort.
Section 17 of this document provides additional criteria regarding Bell Atlantic’s policies for
carrier conformance testing prior to interconnection. Applicable conformance test cases,
which the ICN’s equipment is expected to have passed are listed in Appendix C of this
document. Additionally, application-specific tests may also be required to ensure
conformance of the application-level signaling protocol implementation.

3.4 Compatibility Testing


Bell Atlantic requires successful completion of certain compatibility tests to provide a level
of assurance that the two networks can safely interconnect and that signaling interactions
work correctly at the network interface. This testing must be completed before
interconnection of new ICN equipment can take place. These include interoperability tests
for the SS7 MTP at levels 2 and 3 as well as application-specific testing for ISUP, SCCP, and
TCAP-based interactions, depending on the services supported. The specific compatibility
tests to be performed will be determined based in the interconnecting carrier’s responses to
the SS7 Interconnect Information Questionnaire. These tests will proceed according to a
mutually agreed-upon test plan and schedule developed at the pre-ASR meeting prior to
interconnection. More detailed test cases and test criteria will be provided to the ICN at that
time.

3.5 ICN Point Code Assignments


Normally, the ICN interconnecting with Bell Atlantic’s CCS network will assign signaling
point codes (SPCs) to its (ICN) network elements based on a coding allocation assigned
uniquely by the North American Numbering Plan (NANP) Signaling Point Code
Administrator. For those “large-network” ICNs that interconnect on a BA-STP-to-ICN-STP
basis, these will typically use a unique Network Identifier (NI) code. Alternatively, “small”
networks may obtain an allocated unique network-cluster (NI-NC) identity, and “small-small”
networks consisting of only a few SEPs, may obtain an allocated network cluster member
(NCM) code range within reserved small-small network clusters. The ICN administration will
be responsible for obtaining such coding allocations from the NANP SPC administrator.

However, an ICN that does not have its own signaling network identifier (NI) as a “large”
signaling network, and is interconnecting with Bell Atlantic on a BA-STP-to-ICN-SEP basis,
may request point code assignments for its network element(s) as members of Bell Atlantic’s
network, using BA’s NI in its SPCs.

3.6 Distribution and Sharing of Point Code Information


Information regarding point codes for access trunk groups necessary for the interconnection
of other networks to the Bell Atlantic network will be disseminated as required. This must be
accompanied by a signed non-disclosure agreement.

3.7 Gateway Screening at Bell Atlantic STPs


Bell Atlantic will perform gateway screening of all ICN SS7 signaling messages arriving over
ICN link sets at its STPs prior to and during message routing procedures. The screening
process will discard any ICN signaling traffic that is attempting to access the BA network, its
services, or specific destinations (both within the BA network or in other CCS networks) for
which that traffic is not authorized per the interconnection agreement. Bell Atlantic may

3-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Administrative Conditions of Interconnection

screen all traffic arriving on inter-network (gateway) link sets against lists of allowed
Originating Point Codes (OPCs), Destination Point Codes (DPCs), and Service Information
Octet (SIO) values, including combinations of the these parameter values, to ensure that a
valid signaling relation exists between the signaling points and applications, consistent with
the interconnection agreement. Signaling Connection Control Part (SCCP) messages used to
transport service-related queries and response messages may be additionally screened to
validate their Calling and Called Party Address (CgPA and CdPA) fields against lists of
allowed originating and terminating signaling points and applications. SS7 network
management messages may be similarly screened to verify that their source, destination,
affected signaling points, and control actions are appropriate and consistent with the
signaling relations contracted in the interconnection agreement. The ICN must provide to
Bell Atlantic all necessary address information for the traffic it shall generate, to allow Bell
Atlantic to provision such screening criteria in its STPs.
3.8 Service Intervals
Each request for service interconnection will be treated individually. Estimated service
intervals will be provided after the customer’s Access Service Request (ASR) has been
reviewed and Bell Atlantic has determined that sufficient network resources, including
facilities, diverse routes, STP capacity, etc., exist to fulfill the request. In the event of a
problem, standard industry processes as established in the Ordering and Billing Forum (OBF)
and Network Interconnection/Interoperability Forum (NIIF) will apply. Bell Atlantic
encourages joint planning discussions with the ICN network administrations on initial
interconnection orders to ensure service is provisioned in a timely manner.

3.9 Post-Interconnection Responsibilities and Relationships


Subsequent to initial interconnection, the ICN is expected to ensure the protocol
conformance and compatibility of all future equipment and software upgrades associated with
its network elements that interface to the Bell Atlantic network. The ICN is also expected to
ensure protocol conformance and compatibility of any third-party carrier’s equipment that
connects to the ICN network and will generate SS7 message traffic transiting through the
ICN network to access Bell Atlantic’s CCS network. The ICN must disclose all such traffic to
Bell Atlantic. It must commit to perform Gateway Screening on all signaling messages
entering its own network, both before and after any Global Title Translation (GTT), to
ensure that only authorized and disclosed third-party signaling traffic is allowed to cross the
Bell Atlantic network interface. Further criteria for such post-interconnection traffic
monitoring and interconnecting carrier relationships are described in Bell Atlantic’s
Principles for CCSN Interconnecting Networks document.

3-3
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Capabilities Supported – Internetwork Call Control

4 CAPABILITIES SUPPORTED - INTERNETWORK CALL


CONTROL
Internetwork call control provides the transport of ISUP trunk signaling information
between a Bell Atlantic switch and an ICN switch to connect a trunk between those switches
to carry a call. Circuit-related ISUP messages are used for this purpose. Internetwork call
control is used to set up trunks between Bell Atlantic switches, which may be either end
offices or access tandems equipped with GR-394-CORE capability (for calls originating from
and terminating to a non-ISDN access interface) or TR-NWT-000444 capability (for calls
originating from or terminating to an ISDN access interface), and suitably equipped ICN
switches. In these cases, call routing is based on carrier identification code. In other cases,
interconnection to another network within the LATA uses switches that are based on GR-
317-CORE capabilities. In these cases, call routing is based on the dialed (or translated)
number. Internetwork call setup using SS7 is available for both originating and terminating
access. Section 4.1 of GR-905-CORE describes:
• Internetwork call control messages and their flows for a typical call setup and release
scenario and its possible variations including interworking with MF signaling

• Internetwork call control using CCS/SS7 for both originating and terminating access to
interLATA carriers

• Interconnection considerations for Other LATA Carriers (OLCs) and Tandem Service
Providers (TSPs)

• Tones and announcement considerations for internetwork call control

• Procedures for completion of the transmission path

• Handling of unrecognized messages and parameters

• Procedures related to ISUP reaction to TFC/isolation

• ISUP Automatic Congestion Control (ACC) procedures

• Hop Counter procedures


The above compatibility information provided in Section 4.1 of GR-905-CORE is required to
ensure compatibility with Bell Atlantic’s CCS network, with the variations noted in the
remainder of this section.

4.1 Originating Access SS7 ISUP Parameters Supporting Non-ISDN Access

The following text provides information concerning the parameters that are available in the
call setup messages traversing the CCS Interface. It should be noted that, as Bell Atlantic's
network supports new capabilities and parameters, they will be added to this section.

4-1
Bell Atlantic Supplement TPG-00-001
Capabilities Supported – Internetwork Call Control Issue 1, March 2000

The mandatory parameters supported by Bell Atlantic for originating access are the Message
Type, Nature of Connection, Forward Call Indicators, Calling Party’s Category, User Service
Information, and Called Party Number parameters. It should be noted that, for originating
access, Bell Atlantic supports the provisionable data item (described in GR-317-CORE) in
which the User Service Information parameter’s Information Transfer Capability field may
be coded either as “speech” or “3.1 kHz audio”, based on the outgoing trunk group’s
provisioning. As an intermediate switch, Bell Atlantic will use the received value of the
IAM’s User Service Information parameter’s Information Transfer Capability field in an
outgoing IAM subsequently sent from the Bell Atlantic switch. Bell Atlantic will treat a
received IAM with the User Service Information’s parameter’s Information Transfer
Capability field coded as “3.1 kHz audio” in the same way as if this field was coded as
“speech”, unless some other feature requires “3.1 kHz audio” treatment.

Calling Party Number, Charge Number, Originating Line Information, Carrier Selection,
Transit Network Selection, Jurisdiction Information, Generic Address, Service Code, Carrier
Identification, Hop Counter, Generic Name, Original Called Number, Redirecting Number, and
Redirection Information parameters are the optional parameters currently supported by Bell
Atlantic for originating access. Section 4.1 of GR-905-CORE contains and describes these
parameters.

For terminating access, the entry switch in the Bell Atlantic network shall receive from the
ICN all mandatory parameters and, based on agreements between the ICN and Bell Atlantic,
any other additional optional parameters that have been agreed to. The entry switch is the
first switch (an access tandem or an end office) where the call enters the Bell Atlantic
network for terminating access. Refer to Sections 4.1.3 and 4.2.3 of GR-905-CORE for
further details on terminating call control access.

The passage of an optional parameter between networks (with the exception of the Calling
Party Number, as described below) is subject to an agreement between the ICN and Bell
Atlantic. When such an agreement is in place, Bell Atlantic will include the optional
parameter in all appropriate SS7 setup messages, originating either direct from the end office
or when delivered to the ICN via the access tandem. The ICN will include the optional
parameter in all appropriate SS7 setup messages to Bell Atlantic.

The structures of the mandatory and optional parameters are defined in Appendix A of GR-
905-CORE. Calling Party Number, Charge Number, Originating Line Information, Carrier
Selection, Transit Network Selection, Jurisdiction Information, Generic Address, Service
Code, Carrier Identification, Hop Counter, Generic Name, Original Called Number,
Redirecting Number, and Redirection Information parameters are discussed below. For
additional information on these parameters, refer to GR-317-CORE and GR-394-CORE.

4.1.1 Calling Party Number (CPN)


The Calling Party Number (CPN) is used to identify the specific station set originating a call.
The CPN also contains a presentation bit, which denotes whether the presentation of the
calling party number is allowed or restricted by the end user.

Bell Atlantic will include CPN in all SS7 setup messages, originating either direct from the end
office or when delivered to the ICN via the access tandem when no MF interworking occurs.
Bell Atlantic requires that when technically feasible, the correct Calling Party Number be
provided by the ICN. For calls originated within the ICN network, Bell Atlantic requires that
the ICN provision its switches to generate IAMs that include the CPN and that they take

4-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Capabilities Supported – Internetwork Call Control

steps to ensure that the provided CPN correctly identifies the calling subscriber. For calls
originated outside the ICN network, Bell Atlantic requires that the ICN deliver any received
CPN in the IAM with which it hands off the call. The ICN will be required to work with Bell
Atlantic in addressing interconnected networks that do not provide the ICN network with the
CPN.

For security reasons across all networks, agreements and limits have to be reached on which
numbers will be allowed for population of the CPN.

4.1.2 Charge Number


The charge number parameter is the equivalent of the “ANI” (Automatic Number
Identification) information available today with MF Feature Group D (FGD). This parameter
is contained in the IAM together with the Originating Line Information Parameter (OLIP).
If the charge number and the calling party numbers are the same, the CPN instead of the
charge number parameter will be sent together with the OLIP.

4.1.3 Originating Line Information Parameter


The Originating Line Information Parameter (OLIP) is the binary equivalent of the “II”
information digits available today with MF FGD. This information reveals the originating
line class of service (indicates hotel, inmate Toll-Free call, coin call, etc.). The OLIP is sent
to the ICN with the charge number (see Section 4.1.2).

4.1.4 Carrier Selection Parameter


The carrier selection parameter provides information concerning the Interexchange Carrier
(IXC) selection of the end user. In addition, this parameter describes whether the IXC
selected was pre-subscribed, or whether the calling end user input the selected carrier
information in the dialing sequence.

4.1.5 Transit Network Selection


The Transit Network Selection (TNS) parameter contains carrier identification and the
circuit code. For domestic calls, the IXC receiving the call is identified in the TNS. As such,
the TNS is not passed to that IXC by the access tandem that receives the TNS. For
international calls, the switch receiving the TNS may be in an intermediate network, or an
international operator may be required. The TNS in this case identifies the International
Carrier (INC) and whether or not an international operator is requested. The TNS is needed
by the IXC on such calls and, therefore, is sent to the IXC.

4.1.6 Jurisdiction Information Parameter


Jurisdiction Information Parameter (JIP) is an optional parameter in the IAM. It contains six
binary coded decimal digits (NPA-NXX) that represent the jurisdiction information
(geographic origin of the call). For LNP, the JIP will be populated with the first six digits of
the ten-digit Location Routing Number (LRN) of the switch originating the call. With the
introduction of LNP, it is expected that JIP will be included in the IAM for all calls.

4-3
Bell Atlantic Supplement TPG-00-001
Capabilities Supported – Internetwork Call Control Issue 1, March 2000

4.1.7 Generic Address Parameter


The Generic Address Parameter (GAP) is used, in cases where a switch does perform a Local
Number Portability (LNP) query, to signal to the succeeding switches and networks that the
type of address it is sending is a “ported dialed number”, when the number has indeed been
ported. The parameter will be present if the number has been ported and will not be present if
the number has not been ported. The Bell Atlantic network will be capable of sending and
receiving GAP for LNP. Refer to Section 11 of this document for details.

4.1.8 Service Code Parameter


Service Codes allow individual calls to be identified and routed based on specific service
characteristics. This parameter is used to carry information from the MF facility code digits.

4.1.9 Carrier Identification Parameter


The Carrier Identification Parameter (CIP) provides information sent in the forward
direction to the transit network indicating the transit network selected by the originating
subscriber. Based on bilateral agreement between Bell Atlantic and the ICN, the CIP may be
included or may not be included on an IAM on a per trunk group and per CIP value basis. If
the CIP is to be sent to an ICN, it will be generated for FGD, 700, 900-NXX, and Toll-Free
database type calls for which there is no interworking.

4.1.10 Hop Counter


The Hop Counter parameter is used to detect the presence of call routing loops caused by
translation errors in the switch. The Hop Counter parameter is inserted in an outgoing IAM
by an intermediate switch which gives it a provisioned initial value, and it is normally
decremented by each succeeding switch until the call reaches the terminating switch, or the
hop counter value decrements to zero, at which point the call is released. If a call is
forwarded, the hop counter will be reinitialized to the provisioned initial value.

4.1.11 Generic Name Parameter


The Generic Name parameter (GN) is used to deliver information about whether a customer
has altered his or her calling name presentation status for the particular call in which the GN
parameter was received in the IAM.

4.1.12 Original Called Number Parameter


The Original Called Number parameter (OCN) is used in call forwarding to carry the
redirecting number value, nature of address, numbering plan, and the presentation
information associated with the user who initiated the first redirection.

4.1.13 Redirecting Number Parameter


The Redirecting Number parameter (RN) is used in call forwarding to carry the redirecting
number value, the nature of address, the numbering plan, and the presentation and screening
information associated with the latest instance (when there is more than one instance) of call
forwarding.

4-4
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Capabilities Supported – Internetwork Call Control

4.1.14 Redirection Information Parameter


The Redirection Information parameter (RI) is used in call forwarding to convey the Reason
For Redirection (RFR) values associated with the original instance of call forwarding and the
RFR associated with the latest instance of call forwarding (if multiple call forwardings have
occurred).

4.2 Additional SS7 ISUP Parameters Supporting Integrated Services Digital


Network (ISDN)
Refer to Section 4.2 of GR-905-CORE for compatibility information for interconnection
with Bell Atlantic’s CCS network for ISDN calls. As described in Section 4.2 of GR-905-
CORE, the usage of several ISUP parameters is modified for ISDN calls. Additional
originating access optional parameters supported for ISDN calls are described below.

4.2.1 Access Transport Parameter (ATP)


The ISUP Access Transport Parameter (ATP) is used to carry certain information elements
received from an ISDN access transparently through the SS7 network in either direction
between the originating and terminating switches. This parameter can be sent or not, within
an IAM to an ICN on a per ICN basis, in accordance with business arrangements between Bell
Atlantic and the ICN. Information transported in this parameter may consist of any or all of
the following information elements: Called Party Subaddress, Calling Party Subaddress, Low
Layer Compatibility, High Layer Compatibility, Progress Indicator, and Redirecting
Subaddress.

Bell Atlantic will include the ATP in the IAM if an ISDN user provides any information
element that is to be carried in the ATP. The ATP may also be included in the Address
Complete, Answer and Call Progress messages. It is expected that the ICN will transparently
transport any received ATP.

For additional information regarding these optional parameters to support ISDN access, refer
to TR-NWT-000444.

4.2.2 Generic Address Parameter (GAP)


The Generic Address Parameter (GAP) can be used to transport information similar to that
of the Calling Party Number (CPN) parameter but includes additional fields for “types of
address.” The four (4) types of possible combinations of numbers for transport are: Network
Provided (NP) number only; User Provided, Passed network Screening (UPPS) number only;
User Provided, Failed network Screening (UPFS) number and an NP; User Provided, Not
Screened (UPNS) and an NP. The GAP is used to transport the user provided (UP) number.

4.3 Procedures for Tones And Announcements


CCS call setup provides the terminating LEC the ability to release connections in some cases
when calls cannot be completed, e.g., on busy, allowing the originating network and/or the
ICN to provide tones and announcements. Providing tones and announcements at the
originating end office enables interoffice facilities to be released more quickly. Appendix B
identifies Bell Atlantic’s release back treatment for all SS7 and interworked calls.

4-5
Bell Atlantic Supplement TPG-00-001
Capabilities Supported – Internetwork Call Control Issue 1, March 2000

Bell Atlantic will provide a release with cause to enable the originating end of the call to
provide the appropriate response for a particular cause.

Bell Atlantic will work cooperatively with the industry in the Ordering & Billing Forum
(OBF), Network Interconnection/Interoperability Forum (NIIF) (formerly Network
Operations Forum - NOF), and T1S1.3 Standards to resolve open questions and to insure that
the appropriate tone or announcement is played at the near end in response to the cause
value in each message. The ICN is expected to do the same. Bell Atlantic will update
Appendix B of the document as these questions are resolved.

4-6
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Capability-Related Protocol

5 CAPABILITY-RELATED PROTOCOL
Sections 5.1 and 5.2 of GR-905-CORE describe the internetwork call control portion of the
ISUP protocol for non-ISDN calls and for calls involving an ISDN interface, respectively.
For each ISUP call control message, contents, origination and subsequent signaling are
described. The formats and codings of the ISUP messages are described in Appendix A of GR-
905-CORE and timer values are given in Appendix B of GR-905-CORE. These appendices
and Sections 5.1 and 5.2 of GR-905-CORE provide ICNs the relevant compatibility
information required for interconnection with Bell Atlantic CCS network with the variations
noted in this section.

5.1 ISDN User Part Internetwork Call Control Protocol


This section describes the internetwork call control portion of ISUP for non-ISDN calls. Bell
Atlantic intends to be fully compliant with the ISUP messages and protocol procedures
contained in GR-905-CORE.

It is expected that the ICN will pass all parameters unchanged to the terminating interface as
received from the originating interface, including those parameters that are unrecognized. All
ISUP call control messages to be supported across the Bell Atlantic/ICN CCS network
interface are briefly described below. Further details are provided in Section 5.1 of GR-905-
CORE. The ICN should promptly notify Bell Atlantic of any messages, parameters, or
options, documented in these sections, which they do not support. ISUP messages other than
those referenced in the following sections should not be addressed to Bell Atlantic and are
subject to discard.

5.1.1 Address Complete Message


The Address Complete Message (ACM) is sent in the backward direction when the called
party number information is complete and any continuity checks required throughout the
connection have been successfully completed.

5.1.2 Answer Message


The Answer Message (ANM) is sent in the backward direction to indicate that a call has been
answered.

5.1.3 Circuit Reservation Message


The Circuit Reservation Message (CRM) is sent in the forward direction to reserve an
outgoing SS7 supported circuit and initiate any required continuity check. This message is
used when there is an interLATA call using inband Exchange Access North American
signaling to Bell Atlantic’s SS7 AT.

5.1.4 Circuit Reservation Acknowledgement Message


The Circuit Reservation Acknowledgment (CRA) message is sent in the backward direction in
response to a CRM indicating that a circuit has been reserved for an incoming call.

5-1
Bell Atlantic Supplement TPG-00-001
Capability-Related Protocol Issue 1, March 2000

5.1.5 Continuity Check


The Continuity (COT) message is sent in the forward direction to indicate either the success
or failure of the continuity check performed on an SS7 circuit in the connection.

5.1.6 Exit Message


The Exit Message (EXM) is sent in the backward direction from an access tandem (AT) to
indicate that SS7 call setup information has successfully progressed to the adjacent ICN.

5.1.7 Initial Address Message


The Initial Address Message (IAM) is sent in the forward direction to initiate seizure of an
outgoing circuit and to transmit address and other information relating to the routing and
handling of a call. Refer to Section 4 of this document for the IAM parameters supported by
Bell Atlantic for internetwork call control.

5.1.8 Release Message


The Release (REL) message is sent in either direction to indicate that the specified circuit is
being released from the connection. The specified circuit is released before the REL is sent,
but the circuit is not idled (i.e., available for the next call) until a Release Complete (RLC)
message is received for the specified circuit.

5.1.9 Release Complete


The Release Complete (RLC) message is sent in either direction in response to a Release
message.

5.1.10 Resume Message


The Resume (RES) message is sent in the backward direction after a Suspend (SUS) message
has been sent, to indicate that the called party has reconnected. The RES informs the
network that the call which was suspended is being resumed.

5.1.11 Suspend Message


The Suspend (SUS) message is sent in the backward direction to indicate that the called party
has disconnected before receipt of a Release Message.

5.1.12 Call Progress Message


Certain features may cause a switch to receive an ACM for a call for which it has previously
transmitted an ACM. Under these conditions, it is expected that the switch sends a Call
Progress (CPG) message in the backward direction. The sent CPG should contain the
mandatory event information parameter and all the parameters received in the ACM as its
optional parameters.

5.1.13 Confusion Message


The Confusion (CFN) message may be sent in either direction to inform the adjacent switch
in a call connection that an unrecognized ISUP message has been received (from the adjacent

5-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Capability-Related Protocol

switch) for the call. Bell Atlantic will be prepared to receive a CFN from an ICN, but whether
an ICN sends a CFN to Bell Atlantic is the option of the ICN. Unless otherwise notified, Bell
Atlantic will send the CFN message to the ICN.

5.2 ISUP Protocol to Support ISDN Access


Bell Atlantic will support internetwork calls between a calling and a called party where at
least one of the parties is an ISDN subscriber. Bell Atlantic will be able to accept these types
of calls from an ICN, and expects that an ICN will be able to accept these types of calls from
Bell Atlantic. ISDN calls that cross the interface from the Bell Atlantic network to the ICN
network, and vice versa, are expected to be transported consistent with ISDN requirements in
the ICN network.

This section provides the additional ISUP protocol information that is needed to support
internetwork calls between calling and called parties where at least one of the parties is an
ISDN subscriber. The modified and additional formats and codings are contained in Appendix
A of GR-905-CORE. This appendix and Section 5.2 of GR-905-CORE provide ICNs the
relevant compatibility information required for interconnection with Bell Atlantic’s CCS
network to support ISDN access. The ICN should promptly notify Bell Atlantic of any
messages, parameters, or options, documented in these sections, which they do not support.

5.2.1 Call Progress Message


The Call Progress (CPG) Message is sent in the backward direction from the terminating
switch to indicate call progress information for a call terminating to an ISDN access
subscriber. Once the CPG has been received, the set of possible subsequent messages includes
the Answer and the Release message. The cause indicators parameter is included in the CPG if
the CPG is sent because the call is cleared at the terminating ISDN interface and an inband
tone or announcement has been generated. The cause indicators parameter contains
information on why the call was cleared at the terminating ISDN interface.

5.2.2 Initial Address Message


To support ISDN access, the Initial Address Message (IAM) will contain the access transport
parameter if needed. The user service information parameter coding that may be used is
speech, 3.1 kHz audio, 64 Kbps unrestricted digital information, or unrestricted digital
information rate adapted from 56 Kbps as described in GR-905-CORE. In addition, the user
service information parameter coding may be 384 Kbps, 1536 Kbps, or multirate (64 Kbps
base rate) as described in GR-1357-CORE, Common Channel Signaling (CCS) Network
Interface Specification Supporting Switched DS1/Switched Fractional DS1 Service Capability
(SWF-DS1).

5.3 Nx64
Bell Atlantic network protocol messages and protocol procedures for the nxDS0 (n is from 2
to 24) multirate connections will be consistent with GR-1357-CORE, which complements
GR-905-CORE.

5-3
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 ISUP Non-Capability Related Protocol

6 ISUP NON-CAPABILITY RELATED PROTOCOL

6.1 Dual Seizure (Glare) on 2-Way Trunks


Dual seizure (glare) is a problem which occurs on 2-way trunks when the switches on each side
of the trunk simultaneously seize that trunk for subsequent use in a call. When this occurs,
procedures must be followed to determine which side of the trunk can proceed with the
outgoing call and which side should release the switch path. The side of the trunk that is in
control will receive overriding control assignment for all calls. Tables controlling “dual
seizure control” can be settable in the SP.

The party that will control the circuit when glare occurs between a Bell Atlantic switch and
an ICN switch will be decided prior to interconnection by mutual agreement between Bell
Atlantic and the ICN.

6.2 Continuity Check (COT)


As described in Section 5, the Continuity (COT) message is sent in the forward direction to
indicate either the success or failure of the continuity check performed on an SS7 circuit in
the connection. If a continuity test is being performed on a circuit and it fails, another circuit
is selected. If the continuity test fails on the second circuit, the call is aborted and the
customer receives reorder tone. The continuity test is performed on a per circuit basis and its
frequency can be set for 1 out of ‘n’ calls, with ‘n’ being an integer from 1 to 16.

Bell Atlantic’s position on the frequency of continuity checks is the following: A continuity
check shall be performed for each call when using analog trunks, and a continuity test shall be
performed for 1 in 8 calls (statistical basis) when using digital trunks. This is consistent with
NIIF (formerly NOF) agreements.

6.3 ISUP Non-Capability (Non-Call) Related Messages


Section 3.2 of GR-905-CORE describes the ISUP messages and procedures that are not
directly used in call setup and related capabilities. For each of these messages, contents,
origination and subsequent signaling are described in GR-905-CORE. The formats and codings
of the ISUP messages are described in Appendix A of GR-905-CORE and timer values are
given in Appendix B of GR-905-CORE. These appendices and Sections 3.2 of GR-905-CORE
provide ICNs the relevant compatibility information required for interconnection with Bell
Atlantic CCS network. It is expected that the ICN be capable of correctly responding to each
of these messages, and of generating these messages, where appropriate.
6.3.1 Blocking Messages
The Blocking (BLO) message is sent to a switch to block transmission from that switch on
the specified circuit. The BLO may be sent in the forward or backward direction.

The Blocking Acknowledgement (BLA) message is sent in either direction in response to a


Blocking message indicating that the specified circuit has been blocked.

6-1
Bell Atlantic Supplement TPG-00-001
ISUP Non-Capability Related Protocol Issue 1, March 2000

6.3.2 Unblocking Messages


The Unblocking (UBL) message is sent to a switch to unblock or enable transmission from
that switch on the specified circuit. The UBL may be sent in the forward or backward
direction.

The Unblocking Acknowledgement (UBA) message is sent in either direction in response to


an Unblocking message indicating that the specified circuit has been unblocked.
6.3.3 Circuit Group Blocking Messages
The Circuit Group Blocking (CGB) message is sent to a switch to block transmission from
that switch on a specified group of circuits. To actually block a group of circuits, the CGB
must be sent twice within 5 seconds.

The Circuit Group Blocking Acknowledgement (CGBA) message is sent in response to a CGB
message.
6.3.4 Circuit Group Unblocking Messages
The Circuit Group Unblocking (CGU) message is sent to unblock or enable transmission on a
specified group of circuits.

The Circuit Group Unblocking Acknowledgement (CGUA) message is sent in response to the
Circuit Group Unblocking message. The CGUA indicates that the specified group of circuits
has been unblocked.
6.3.5 Reset Circuit Message
The Reset Circuit (RSC) message is sent to reset a circuit for which the status is unknown or
mutilated. The RSC resets the circuit to the idle condition, making the circuit available for
traffic.
6.3.6 Circuit Group Reset Messages
The Circuit Group Reset (GRS) message is sent to reset a specified group of circuits. In order
to reset the group of circuits, the GRS must be sent twice within 5 seconds.

The Circuit Group Reset Acknowledgement (GRA) message is sent in response to a Circuit
Group Reset message. The GRA is sent when two Circuit Group Reset messages have been
received within 5 seconds. The GRA indicates that the specified group of circuits has been
reset.
6.3.7 Circuit Query Messages
The Circuit Query Message (CQM) is sent in either direction to request the state of a single
circuit or a group of circuits.

The Circuit Query Response (CQR) message is sent in response to a Circuit Query Message.
The CQR indicates the states of the requested circuits.
6.3.8 Circuit Validation Test Messages
The Circuit Validation Test (CVT) message is sent to indicate that the sending end of an SS7-
supported circuit has sufficient and consistent information about the circuit and to initiate
testing of the other end.

6-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 ISUP Non-Capability Related Protocol

The Circuit Validation Response (CVR) message is sent in response to a Circuit Validation
Test message. The CVR indicates whether or not this end of the SS7-supported circuit has
sufficient and consistent information to use the circuit in a call connection.
6.3.9 Continuity Check Request Message and Loop Back Acknowledgement
Message
The Continuity Check Request (CCR) message is sent after a circuit has failed a continuity
check during call setup. The CCR initiates a continuity check within 1 to 10 seconds after the
determination that the first check has failed.

The Loop Back Acknowledgement (LPA) message is sent in response to a Continuity Check
Request message. The LPA indicates that a check-loop or transponder has been connected to
the circuit.
6.3.10 Unequipped Circuit Identification Code Message
The Unequipped Circuit Identification Code (UCIC) message is sent if a message is received
with an unequipped TCIC. A circuit is unequipped if no valid SS7 message can be received or
transmitted for that circuit (with the exception of the Circuit Query Message, Circuit Query
Response Message, and the UCIC message).

6-3
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Signaling Connection Control Part (SCCP) Protocol

7 SIGNALING CONNECTION CONTROL PART (SCCP)


PROTOCOL
This section describes, at a high level, the compatibility information required for
interconnecting with Bell Atlantic’s network to support the Signaling Connection Control
Part (SCCP) of the SS7 protocol. Detailed compatibility information, including message
formats, is provided in GR-1432-CORE.

The SCCP provides additional functions to the Message Transfer Part (MTP) to transfer
non-circuit-related signaling information. The SCCP protocol, as described in ANSI T1.112,
consists of four major functional components:

• SCCP connection-oriented control


• SCCP connectionless control
• SCCP routing
• SCCP management.

Bell Atlantic does not currently support connection-oriented control and does not expect to
send or receive internetwork SCCP messages related to SCCP connection-oriented
procedures.
7.1 Connectionless Service
SCCP connectionless controls provide efficient routing of messages that are independent of
voice network connections without the establishment of a signaling connection. There are
two types of connectionless transport that can be used for SCCP message exchange, and these
are identified by the protocol class assigned to the message.

1. Class 0 (basic connectionless service) which provides transport of message signal units
(MSUs) without establishing any relationship between two or more messages originating
from the same node. SCCP messages sent using connectionless Class 0 are transported
independently of each other.
2. Class 1 (MTP sequenced connectionless service) which maintains message sequencing
under normal circumstances by encoding related messages with identical Signaling Link
Selection (SLS) code values.
Bell Atlantic will send messages using SCCP Class 0, and expects to receive messages from
ICNs that interconnect to Bell Atlantic’s network using SCCP Class 0.
7.2 SCCP Routing

SCCP routing may be required at Bell Atlantic’s and/or the ICN STP(s) for certain service
applications. (See Section 9 for more detail regarding service applications that Bell Atlantic
offers or intends to offer that utilize internetwork SCCP message transport.) SCCP
functionality at an STP should only be invoked if the STP receives a message in which the
destination point code (DPC) in the routing label is one of the STP’s addresses, and the
Service Information Octet directs the message to the SCCP. SCCP routing procedures consist
of performing a Global Title Translation (GTT) to determine a DPC (and possibly a
subsystem number and/or routing indicator) for the message. While the SCCP routing

7-1
Bell Atlantic Supplement TPG-00-001
Signaling Connection Control Part (SCCP) Protocol Issue 1, March 2000

procedures described in GR-1432-CORE currently include the Intermediate Network Selection


(INS) capability, Bell Atlantic does not currently support the use of the INS capability.

Bell Atlantic will only accept internetwork SCCP-routed messages that are routed to a Bell
Atlantic STP or LNP SCP for GTT. Bell Atlantic will not allow messages that undergo SCCP
routing (i.e., GTT ) in an ICN to be routed directly to Bell Atlantic end nodes. In addition,
Bell Atlantic will only accept internetwork SCCP messages routed to a Bell Atlantic STP for
GTT that use a Global Title Indicator value of “2” in the Address Indicator of the Called
Party Address. Bell Atlantic will accept SCCP messages (e.g., LIDB, CNAM and CLASS
response messages) that are routed on the basis of Destination Point Code (DPC) and
Subsystem Number (SSN) via an ICN to a CLASS switch or Operator Services System in Bell
Atlantic’s network. Bell Atlantic will not accept any incoming internetwork SCCP messages
that are directly routed to Service Control Points (SCPs) within the Bell Atlantic network,
other than to LNP SCPs. In the case of messages addressed to an LNP SCP, Bell Atlantic will
only accept messages that are routed to an Alias Point Code and request Global Title
Translation.

There are two types of non-circuit related messages that may be transported as part of
normal SCCP connectionless service: the Unitdata (UDT) message and the Extended
Unitdata (XUDT) message. XUDT messages differ from UDT messages in that XUDT
messages contain optional SCCP parameters. At this time, Bell Atlantic supports UDT
messages only. Future plans may include support of XUDT messages by the Bell Atlantic
network when determined to be necessary to support advances in network signaling. See
Section 2.3.1 and Appendix A of GR-1432-CORE for details regarding the encoding of SCCP
UDT and XUDT messages.

If Bell Atlantic sends a UDT to an ICN STP, and that message requests SCCP routing, the
ICN STP is expected to perform a GTT on the SCCP Called Party Address of that message.
If the ICN STP is unable to perform a GTT, the ICN STP is expected to fail the message and
perform the following procedures:

• If the message return option has been specified in the SCCP portion of the message, the
ICN STP is expected to create a Unitdata Service (UDTS) message, with the return cause
field set to indicate the reason that the ICN STP failed the UDT message. The ICN STP
is expected to MTP-route the UDTS message.

• If the message return option is not specified in the SCCP portion of the message, the ICN
STP is expected to discard the UDT message.

The ICN STP should not expect to receive a UDTS message that requests SCCP routing.
However, if it does receive such a message, the ICN STP is expected to perform a GTT on
the SCCP Called Party Address of the UDTS message.

If a Bell Atlantic STP receives a UDT message that requests SCCP routing, the Bell Atlantic
STP will perform a GTT on the SCCP Called Party Address of the message. If the Bell
Atlantic STP is unable to perform a global title translation, it will fail the message and
perform the following procedures:

• If the message return option has been specified in the SCCP portion of the message, the
Bell Atlantic STP will create a UDTS message, with the return cause field set to indicate

7-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Signaling Connection Control Part (SCCP) Protocol

the reason that the STP failed the UDT message. The Bell Atlantic STP will MTP-route
the UDTS message.

• If the message return option is not specified in the SCCP portion of the message, the Bell
Atlantic STP will discard the UDT message.

The Bell Atlantic STP does not expect to receive a UDTS message that requests SCCP
routing. However, if it does receive such a message, the Bell Atlantic STP will perform a
GTT on the SCCP Called Party Address of the UDTS message.

It is expected that the ICN STP will not route an XUDT message into the Bell Atlantic
network until such time as the ICN has verified that the node that will receive the message
(i.e., the node identified by the DPC in the message) is capable of processing such a message.
If the ICN does not verify the receiving node’s ability, and the receiving node cannot process
the XUDT message, the receiving node will discard the received XUDT message due to an
unrecognized message type.

7.3 SCCP Management


Bell Atlantic will not send SCCP management messages to the ICN and does not expect to
receive SCCP management messages from the ICN except where specifically included in
bilateral agreements. In the absence of such bilateral agreements, SCCP management
messages received by the Bell Atlantic interconnecting STP will be ignored.

7-3
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Transaction Capabilities Application Part (TCAP) Protocol

8 TRANSACTION CAPABILITIES APPLICATION PART (TCAP)


PROTOCOL
This section describes, at a high level, the compatibility information required for
interconnecting with the Bell Atlantic network to support the Transaction Capabilities
Application Part (TCAP) of the SS7 protocol. The TCAP protocol provides procedures that
are used in a number of services that Bell Atlantic offers or intends to offer, and that may
require interactions with ICNs. These services are described in more detail in Section 9.

TCAP is an application layer protocol. In the Bell Atlantic network, TCAP is transported
using the MTP and SCCP layers of the SS7 protocol. TCAP supports the transfer of non-
circuit-related information between signaling nodes via a signaling network. TCAP provides
a framework for a common approach to services within a network, as well as a framework for
internetwork services. In its interactions with Bell Atlantic’s network to support
internetwork service operation, an ICN is expected to conform to the SS7 TCAP protocol,
as described in ANSI T1.114.
8.1 General Description of TCAP Procedures
A TCAP transaction consists of one or more TCAP messages between two application
processes. TCAP transactions can be one-way (i.e., unidirectional) or two-way (i.e.,
interactive). The application process that initiates the transaction indicates which case
applies, from its point of view, at the start of the transaction. The Transaction Capabilities
protocol format is separated into three portions, namely, Transaction, Dialogue, and
Component. The Transaction Portion is composed entirely of protocol control information
and identifies whether the TCAP transaction is expected to consist of a single or multiple
messages. It also provides a means for associating messages related to the same transaction.
The Component Portion contains protocol-related information as well as data concerning
the application process. It consists of zero, one or more Components. The Dialogue
Portion is used to pass information related to the version of TCAP being used, the
application context, and security. A general description of TCAP processing at the
transaction level and the component level is described below. Bell Atlantic conforms to these
procedures, and an ICN is expected to conform as well. Bell Atlantic does not support the
Dialogue Portion of the TCAP protocol at this time.

8.1.1 General Transaction Procedures


The transaction portion of a message identifies the status of the transaction (i.e., is the
transaction beginning, continuing, or ending) and whether the transaction between two nodes
is expected to consist of a single message (i.e., one way communication) or multiple messages
(i.e., interactive communication). This is reflected in the transaction portion of the message
in the Package Type field. In addition, the information in the transaction portion of the
message and the transaction-level procedures are responsible for maintaining an association
between all of the messages that are associated with a transaction.

If an application process needs to send information to another application process without


expecting a response from the receiving application process, the message will contain a
Package Type of “Unidirectional.”

If an application process has a need for interactive communication with another application
process, it will initiate the interaction by sending a message with one of the Query Package

8-1
Bell Atlantic Supplement TPG-00-001
Transaction Capabilities Application Part (TCAP) Protocol Issue 1, March 2000

Types. If the sending application process does not anticipate needing to send additional
messages, it will send the initial message with a Package Type of “Query with Permission,”
where the concept of “permission” refers to the fact that the sending application process
gives the responding application process permission to terminate the transaction if it wishes
to (i.e., by returning a message containing a “Response” Package Type). If the sending
application has a need to send multiple messages, it will use a Package Type of “Query
without Permission” in its initial message to indicate to the responding application process
that it should not terminate the transaction when it responds (i.e., it should use one of the
Conversation Package Types rather than a Response Package Type).

If the responding application process has a need to send multiple messages, it will use a
“Conversation Without Permission” Package Type when it responds to the Query message.
If the responding application process does not anticipate having to send more than one
message in response to the Query, it will either send a Response message to terminate the
transaction (assuming a Package Type of Query with Permission was received), or a
Conversation with Permission to continue the transaction.

If a responding application process receives a message containing a protocol error in the


transaction portion of the message, the TCAP protocol allows the responding application to
send an “Abort” Package Type to indicate that the protocol error was encountered. Bell
Atlantic should be consulted regarding the use of the "Abort" Package Type for AIN services.
Note that for the services described in Section 9 of this document, Bell Atlantic uses a
Response or Unidirectional message containing a Reject component (see below) to report
protocol errors.

The transaction portion of a TCAP message also contains a Transaction ID which is used to
correlate messages that are related to the same transaction.

8.1.2 General Component Procedures


Components provide information that either requests an action or responds to a previous
request. The component portion of a message can consist of zero, one or more components.
There are four main component types: Invoke, Return Result, Return Error and Reject.

An application uses an Invoke component to request that an operation be performed.


Depending on the service being supported, an application process may report the success or
failure of an invoked operation, success only, failure only, or neither success nor failure. If an
operation is successful, the application process that performed the operation will respond
with a Return Result component or, possibly, another Invoke component. If a response to an
operation is segmented among more than one component (Invoke or Return Result), then
the component type also carries an indication of which is the last of the responding
components. Therefore, there are actually two Invoke component types that can be used for
responding Invoke components (i.e., Invoke (Last) and Invoke (Not Last) and two Return
Result components (i.e., Return Result (Last) and Return Result (Not Last).

If an operation is unsuccessful due to an application error, the responding application process


will send a Return Error component. The Return Error component will contain the reason
for the failure.

If an operation fails due to a protocol error at the component level, the responding
application process will report the protocol error in a Reject component. If an operation
fails due to a protocol error in the transaction portion of the message, the protocol allows

8-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Transaction Capabilities Application Part (TCAP) Protocol

the responding application process to either report the protocol error in an Abort Package
Type, as discussed above, without any components, or by sending a Reject component in a
Unidirectional or Response Package Type. At this time, Bell Atlantic services use a Reject
component in a Unidirectional or Response Package Type to report a protocol error in the
transaction portion of the message.

8.2 General Formatting Principles


This section provides a high-level description of the formatting principles used in coding
TCAP messages and the data elements within them. Bell Atlantic conforms to these
formatting principles, and the ICN is expected to conform to them as well. See ANSI T1.114
for details related to the formats and codes associated with TCAP messages.

A TCAP message consists of a number of data elements. Data elements within a TCAP
message can be classified as protocol control information or parameters. The presence of
protocol control information (e.g., Transaction IDs, Component IDs) is determined based on
the Package Type and Component Type Identifiers in the message. Parameters provide
information that is significant to the application process. Each data element in a TCAP
message has a standard representation that consists of a sequence of octets containing an
Identifier, a length indicator, and, finally, the content of the data element. The rules related
to the formatting of the Identifiers and length indicators are described in detail in ANSI
T1.114.3.

As described above, the data elements within a TCAP message are associated with either the
transaction portion or the component portion of a TCAP message. The transaction portion
of all TCAP messages should explicitly indicate the Package Type (e.g., Query, Response).
The value of the Package Type implicitly indicates the number of Transaction IDs that
should be present, as well as providing the status of the transaction (i.e., beginning, middle,
end) and includes information needed to coordinate the termination of the transaction and
the release of the Transaction IDs.

The Package Type is followed by an octet that indicates the total length of the remainder of
the TCAP message.

Transaction ID information may or may not be present after the Total TCAP Message
Length, depending on the value of the Package Type. The transaction portion can either
contain one Transaction ID (i.e., an Originating Transaction ID if the Package Type is a
Query, or a Responding Transaction ID if the Package Type is a Response), two Transaction
IDs (i.e., Originating and Responding if the Package Type is a Conversation), or no
Transaction IDs (if the Package Type is “Unidirectional”). A Transaction ID Identifier and
Length Indicator will always be present after the Total TCAP Message Length, even if no
Transaction ID value is present (in which case the Transaction ID Length = 0).

While ANSI T1.114 allows for a Dialogue Portion to optionally be present after the
Transaction ID information in an TCAP message, Bell Atlantic does not currently support
this option and does not expect to send or receive internetwork TCAP messages that contain
a Dialogue Portion at this time.

For Query, Conversation, Response and Unidirectional Package Types, the next and last field
in the transaction portion of a TCAP message is the Component Sequence Identifier. This
field indicates that the component portion is to follow and specifies its length.

8-3
Bell Atlantic Supplement TPG-00-001
Transaction Capabilities Application Part (TCAP) Protocol Issue 1, March 2000

The component portion of a TCAP message may contain any number of components. Each
component contains a Component Type Identifier that identifies the component as an
Invoke, a Return Result, a Return Error, or a Reject. As described above, the Component
Type Identifier field also indicates whether this is the last responding component in a series
of logically linked components.

The Component Type Identifier field is followed by a length indicator that specifies the
length of the entire component. After the Component Length is the Component ID
information. This is used to correlate components with their responses. The two types of
Component IDs are Invoke IDs, which are assigned by the node that is originating the Invoke
component, and Correlation IDs that reflect the Invoke IDs assigned by the node that
originated the Invoke component. A component can contain zero, one or two Component
IDs. The number of Component IDs present will depend on the type of component and the
point in the transaction at which the component is sent.

If the component is an Invoke, the Component ID information should be followed by an


Operation Code. This field identifies the operation to be performed and indicates whether
this operation requires a reply. The operation code field is preceded by an octet that
identifies that the information to follow is an operation code, and a length indicator.

If the component is a Reject, the Operation Code is replaced by a 2-octet Problem Code. If
the component is a Return Error, the Operation Code is replaced by a 1-octet Error Code.

The Operation Code, Problem Code or Error Code (if present) is followed by the Parameter
Set/Sequence Identifier. A Parameter Sequence Identifier indicates that a specific sequence of
parameters is to follow. The Parameter Sequence Length specifies the total length of all the
parameters in the sequence. A Parameter Set Identifier indicates that a set of parameters will
follow (in any order). The Parameter Set Length specifies the total length of all the
parameters in the set.

If parameters are to be included in the component of a TCAP message, the data associated
with each parameter should be preceded by Identifier and Length Indicator octets.

8-4
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Service Offerings

9 SERVICE OFFERINGS

9.1 CLASSSM
CLASSSM Services are a set of call management features that utilize the capability to transport
a calling party’s number between switching offices with Common Channel Signaling (CCS)
call set-up messages. Some CLASSSM services use the TCAP protocol to allow a switching
office to obtain information from another switching office, such as the busy/idle status of a
line, without setting up a call between the switching offices. Automatic Callback and
Automatic Recall are examples of CLASSSM services.

GR-1429-CORE provides ICNs with compatibility information required for interconnecting


with Bell Atlantic’s CCS network for Automatic Callback, Automatic Recall, and the list
building capability (i.e., Screening List Editing) that is used with the Selective Call Rejection
and Distinctive Ringing/Call Waiting features.

ICNs that wish to offer CLASS services in conjunction with Bell Atlantic are required to use a
Translation Type (TT) value of 251 for messages requiring Global Title Translation.

Since the routing of Automatic Callback, Automatic Recall and Screening List Editing queries
is currently based on the NPA-NXX in the GTA field of the SCCP Called Party Address
parameter of the query message, this service has been impacted by the introduction of Local
Number Portability in Bell Atlantic’s network. See Section 11.2 for a discussion of the
impact of LNP on interconnection requirements related to the routing of TCAP queries.

9.2 Line Information Data Base (LIDB) Access


Gaining access to Bell Atlantic’s Line Information Data Base (LIDB) for services such as
Alternate Billing Service (ABS) provides real time billing validation for customers placing
intraLATA calls billed to a telecommunications calling card, billed to a third party number, or
placed collect. Operator Services Systems (OSSs) use TCAP messages to access information
stored in the LIDB. GR-954-CORE provides information related to the interconnection of
Bell Atlantic’s CCS network with ICNs to support LIDB access.

ICNs that access Bell Atlantic’s LIDB are required to use a TT value of 253 in their queries.

Since the routing of LIDB queries is currently based on the NPA-NXX in the GTA field of
the SCCP Called Party Address parameter of the query message, this service has been
impacted by the introduction of Local Number Portability in Bell Atlantic's network. See
Section 11.2 for a discussion of the impact of LNP on interconnection requirements related
to the routing of LIDB queries. Due to the impact of LNP on 6-digit Automatic Call Gapping
(ACG) controls related to LIDB queries, Bell Atlantic nodes that originate LIDB queries to
ICN-provided LIDBs should not receive requests for 6-digit ACG controls from ICN LIDBs
related to NPA-NXXs for which the ICN is not the code holder.

9.3 Toll-Free Service


Toll-Free Service is a service in which special treatment is applied to a call if the call is dialed
using a Service Access Code (SAC) or Interchangeable NPA (INPA) code that is assigned for
use with Toll-Free Service (e.g., “800,” “888”). If a Bell Atlantic switch equipped with

9-1
Bell Atlantic Supplement TPG-00-001
Service Offerings Issue 1, March 2000

Service Switching Point (SSP) functionality receives such a call, it will query a network
database to determine the ICN associated with the dialed toll-free number and, in some cases,
the actual POTS number to which the call should be routed. Bell Atlantic currently supports
Toll-Free Service using both Intelligent Network (IN) and Advanced Intelligent Network
(AIN) platforms. Detailed requirements for IN-based Toll-Free Service are described in TR-
NWT-000533. Detailed requirements for AIN-based Toll-Free Service are described in GR-
2892-CORE. Additional information for interconnection of Bell Atlantic’s CCS network
with ICNs to support IN-based Toll-Free Service is provided in GR-1428-CORE, and support
for interconnection using AIN-based queries/protocol is provided in GR-2902-CORE.

ICNs that access Bell Atlantic's Toll-Free Service Data Base to translate a Toll-Free
SAC/INPA to a dialable telephone number are required to use a TT value of 254 in their
queries.

9.4 891 Calling Card Service


891 telecommunication credit cards are used for payment of telephone charges and service
charges, and validation procedures. The 891 telecommunication credit card application
utilizes non-circuit-related signaling between an Operator Services System (OSS) and an 891
database.

ICNs that access a Bell Atlantic database for validation of 891 calling cards are required to use
a TT value of 1.
9.5 Calling Name Delivery (CNAM)
CNAM is a central office feature that allows a subscriber to have a calling party’s name and
the date and time of the call displayed on customer premises equipment (CPE) connected to a
switching system. CNAM is a companion service to Caller ID (which delivers the calling
number, as opposed to the calling name). The CNAM service can be utilized only when both
the originating and terminating lines are CCS/SS7-capable, when signaling for the call has
preserved the originating CCS/SS7 information, and when the terminating central office is
equipped with the CNAM feature. The provision of CNAM service depends on whether Bell
Atlantic has an agreement in place with the calling party’s LEC for access to CNAM
information. If no such agreement is in place, Bell Atlantic will provide the name of the
calling party’s state, based on the information contained in the Calling Party Number of the
received IAM. When a CNAM subscriber receives a call, the CNAM subscriber’s switch sends
a TCAP query to the appropriate CNAM database requesting the name associated with the
calling party’s number. If Bell Atlantic does not have an agreement with the owner of the
appropriate CNAM database, the query is sent to a Bell Atlantic “State Name” database. The
CNAM or State Name database sends a TCAP response message containing the name or state
name associated with the calling party number. Telcordia TR-NWT-001188 describes the
CNAM feature and Telcordia GR-30-CORE describes the CNAM network interface. GR-
1519-CORE provides additional information for interconnection of Bell Atlantic’s CCS
network with ICNs to support CNAM.

ICNs that query Bell Atlantic's network for the purpose of obtaining information in support
of Calling Name services are required to use a TT value of 5.

Since the routing of CNAM queries is currently based on the NPA-NXX in the Global Title
Address (GTA) field of the SCCP Called Party Address parameter of the query message, this

9-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Service Offerings

service has been impacted by the introduction of Local Number Portability in Bell Atlantic's
network. See Section 11.2 for a discussion of the impact of LNP on interconnection
requirements related to the routing of CNAM queries.

9-3
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Interconnection in Support of AIN

10 INTERCONNECTION IN SUPPORT OF AIN


This section describes the interfaces between Bell Atlantic's CCS network and an ICN for
access to Advanced Intelligent Network (AIN) capabilities. AIN allows a Local Exchange
Carrier (LEC) and LEC customers to create and modify telecommunications services for its
subscribers using a set of reusable, service-independent network functions. An ICN may
interconnect with Bell Atlantic’s CCS network for AIN using call control, non-circuit
associated messaging or both.

Call control interconnection occurs when an ICN Network Access Point (NAP) sets up a call
to a Bell Atlantic Service Switching Point (SSP), and the Bell Atlantic SSP queries an Bell
Atlantic Service Control Point (SCP) on behalf of the ICN NAP.

Non-circuit associated interconnection occurs when an ICN SSP queries a Bell Atlantic SCP,
or
an ICN transports the AIN messages between a remote ICN containing the SSP and an SCP in
Bell Atlantic’s network. Note that, as described in Section 7.2, all queries destined for a Bell
Atlantic SCP will undergo a final GTT at a Bell Atlantic STP.

The following architecture configurations are allowed by Bell Atlantic for interconnection to
their CCS network in support of AIN messaging:

• Interconnection of a switching office in the ICN with Bell Atlantic mated STP pair via
A-links.

• Interconnection of an STP pair in the ICN with a Bell Atlantic mated STP pair via D-
link quads.

Bell Atlantic expects the ICN to provide signaling address information for message screening
and routing purposes. In particular, Bell Atlantic expects the following information to be
disclosed by the ICN:

• The signaling point codes of all ICN NAPs that may set up calls to an Bell Atlantic SSP
for AIN processing.

• The signaling point codes of all ICN SSPs and the subsystem numbers of the AIN
application within those ICN SSPs that may send messages to Bell Atlantic.

• The (true) signaling point codes of any ICN STPs through which AIN messages originated
by Bell Atlantic may be routed. (This is necessary to facilitate Gateway Screening of
messages [e.g., UDTS or TFC messages] originated by those ICN STPs .)

Likewise, Bell Atlantic will provide the signaling point codes of all SCPs and the subsystem
numbers of the AIN application within those SCPs that send AIN messages to ICN SSPs.

The nature and conditions of access to Bell Atlantic's network for the purpose of accessing
Bell Atlantic’s AIN database will be negotiated by single points of contact through the Bell
Atlantic Account Managers prior to interconnection. Specific interconnection details,
including the TT values to be used with specific AIN services, will be addressed at the pre-
Access Service Request meeting, if requested.

10-1
Bell Atlantic Supplement TPG-00-001
Interconnection in Support of AIN Issue 1, March 2000

Bell Atlantic requires an ICN to follow the specifications in Sections 3.1, 3.2, and 5 of GR-
905-CORE for internetwork MTP and ISDNUP signaling, Sections 2 and 3 of GR-1432-
CORE for SCCP and TCAP signaling, as well as the specifications in GR-2863-CORE to
ensure network compatibility when interconnecting with Bell Atlantic’s CCS network for
AIN. Bell Atlantic should be contacted for details associated with interconnecting to Bell
Atlantic’s CCS network for access to specific AIN services.

10-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Local Number Portability

11 LOCAL NUMBER PORTABILITY (LNP)


This section describes, at a high level, the compatibility information required for
interconnecting with the Bell Atlantic network to support call setup and vertical service
operation in a Local Number Portability (LNP) environment. Detailed switch requirements
for supporting call setup in an LNP environment are provided in the T1S1.6 Working Group
on Number Portability Technical Requirements No. 2, Number Portability Switching Systems.
Detailed SCP and GTT function requirements are presented in the T1S1.6 Working Group on
Number Portability Technical Requirements No. 3, Number Portability Database and Global
Title Translation.

LNP refers to the ability of local exchange subscribers to change their local service providers,
physical locations and/or type of service within a defined geographic local number portability
area, without having to change their geographic North American Numbering Plan (NANP)
telephone numbers. These three types of LNP are referred to as local service provider
portability, location portability, and service portability, respectively.

Initial deployment of LNP capabilities in Bell Atlantic includes support of Local Service
Provider Portability (LSPP).

11.1 Call Setup in an LNP Environment


This section describes the following interfaces between an ICN that is not an IXC or
International Carrier (INC) and Bell Atlantic's CCS network:

1. the call control interface when the ICN sets up an LNP call (i.e., a call in which the
NPA-NXX of the dialed number is a portable NPA-NXX) to Bell Atlantic prior to
querying the LNP database
2. the call control interface when the ICN sets up an LNP call to Bell Atlantic's network
after querying an LNP database
3. the interface when the ICN queries Bell Atlantic's LNP database.

In addition to the above interfaces, this section also describes the call control interface that
enables Bell Atlantic to route an LNP call to an appropriate intermediate network (e.g., IXC
or INC) or to a terminating network.

11.1.1 ICN to Bell Atlantic Originating Access


An ICN switch may need to setup an LNP call to Bell Atlantic’s AT/SSP for originating
access, when the ICN is not an IXC or INC. The ICN switch is expected to use the following
procedures, which vary based on the capabilities of the ICN switch and the business
arrangements that exist between the ICN and Bell Atlantic.
11.1.1.1 Bell Atlantic Provides Transport for ICN LNP Call Setup
For local LNP calls, where the Bell Atlantic CCS network is a transient network (i.e., Bell
Atlantic is responsible for transporting an LNP call to an appropriate intermediate or
terminating network), the ICN is obliged to perform any LNP processing associated with the
call, unless a specific business agreement exists with Bell Atlantic which specifies that Bell
Atlantic will provide LNP processing for the ICN. Note that Bell Atlantic will waive this

11-1
Bell Atlantic Supplement TPG-00-001
Local Number Portability Issue 1, March 2000

obligation in instances where the ICN is temporarily unable to access its LNP database. Also
note that, for some interconnections, Bell Atlantic will be unable to perform LNP
processing.

11.1.1.2 Bell Atlantic AT/SSP Queries LNP Database


A. ICN Switch Equipped with GR-317-CORE Capability

In this case, the ICN switch is not LNP-capable and cannot, therefore, launch a query to
an LNP database. Using the GR-317-CORE capability, the ICN switch is expected to
formulate an IAM and route the call, as described in Section 4.1 of GR-905-CORE, to an
AT in Bell Atlantic’s network that is either itself LNP-capable, or is set up to route the
call to another switch that is LNP-capable.

If an LNP-capable switch in Bell Atlantic’s network recognizes an incoming call as one


requiring LNP processing, based on the dialed number in the Called Party Number
parameter of the received IAM, the Bell Atlantic switch will proceed with LNP
processing as described in Section 5 of the T1S1.6 Technical Requirements No. 2,
Number Portability Switching Systems.

B. ICN Switch Equipped With GR-394-CORE Capability

As in the previous case, the ICN switch is not LNP-capable. Using GR-394-CORE
signaling, the ICN switch is expected to formulate an IAM and route the call, as described
in Section 4.1 of GR-905-CORE, to an AT in Bell Atlantic’s network that is either itself
LNP-capable, or is set up to route the call to another switch that is LNP-capable.

If an LNP-capable switch in Bell Atlantic recognizes an incoming call as one which has
not undergone LNP processing, and one for which (based on the dialed number in the
Called Party Number parameter of the received IAM) Bell Atlantic can perform LNP
processing, the Bell Atlantic switch will proceed with LNP processing as described in
Section 5 of the T1S1.6 Technical Requirements No. 2, Number Portability Switching
Systems.

C. ICN Switch Not Equipped with GR-317-CORE or GR-394-CORE Capability

In this case, the ICN switch will use MF signaling to set up the call to an AT in Bell
Atlantic’s network that is either itself LNP-capable, or is set up to route the call to
another switch that is LNP-capable. Once again, if an LNP-capable switch in Bell
Atlantic’s network recognizes an incoming call as one requiring LNP processing, based on
the dialed digits that are received, the Bell Atlantic switch will proceed with LNP
processing as described in Section 5 of the T1S1.6 Technical Requirements No. 2,
Number Portability Switching Systems.
11.1.1.3 ICN SSP Queries Bell Atlantic LNP Database
In this case, the ICN LNP-capable SSP launches an LNP query to Bell Atlantic’s SCP before
setting up the LNP call. It is expected that the query to Bell Atlantic's LNP database will
follow the requirements in Section 5.1.1.1 of the T1S1.6 Technical Requirements No. 2,
Number Portability Switching Systems. ICNs that query the Bell Atlantic LNP database are
required to use a TT value of 11 (for AIN-based LNP queries) or a TT value of 248 (for IN-
based LNP queries). If, upon receipt of the response from Bell Atlantic's LNP database, the

11-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Local Number Portability

ICN determines that the call should be set up via/to a switch in Bell Atlantic's network, the
ICN SSP is expected to set up the call as described in Section 4.1 of GR-905-CORE, and
Section 5.1.1.2.1 of T1S1.6 Technical Requirements No. 2.

11.1.2 Bell Atlantic to ICN Originating Access


If Bell Atlantic determines that an IXC is needed to carry an LNP call, and a business
agreement exists between Bell Atlantic and the IXC which specifies that Bell Atlantic will
perform NP queries on calls destined for that IXC, Bell Atlantic’s SSP will proceed with LNP
processing as described in Section 5.1 of T1 Requirements No. 2, Number Portability
Switching Systems.

If the ICN is an INC, or an IXC for which Bell Atlantic has not agreed to perform NP
queries, Bell Atlantic will use the GR-394-CORE capability, as described in Section 4.1 of GR-
905-CORE, to set up the call to the ICN that will carry the call. In this case, the Bell
Atlantic switch will not apply LNP processing to that call prior to it being routed to the IXC.
Therefore, the signaling that the ICN should expect to receive from a Bell Atlantic switch
will be the same as for a non-LNP call.

11.1.3 ICN to Bell Atlantic Terminating Access


It is expected that an ICN will follow the procedures in Section 4.1 of GR-905-CORE when
routing an LNP call to Bell Atlantic with the following modifications. Bell Atlantic expects
that an LNP query will be done in a prior network if an LNP call is routed to Bell Atlantic for
termination processing. Therefore, Bell Atlantic expects to receive the Location Routing
Number (LRN) of a Bell Atlantic switch in the Called Party Number parameter and the dialed
digits in the Generic Address Parameter (if the number is ported), or the dialed digits in the
Called Party Number parameter (and no "ported number" GAP, if the number is not ported),
and Bit M of the Forward Call Indicators set to "number translated" in the incoming IAM.
Note that Bell Atlantic will waive this obligation in instances where the ICN is temporarily
unable to access its LNP database.

11.1.4 Bell Atlantic to ICN Switching Office


When an LNP call terminates in an ICN (i.e., not an IXC or INC), Bell Atlantic's switch (end
office or AT) sets up the call to the terminating ICN switch as described in Section 4.1 of
GR-905-CORE, with the following modification. If the call has undergone LNP processing in
a prior network, the ICN should expect to receive Bit M of the Forward Call Indicators
parameter of the received IAM set to "number translated," and either the LRN of an ICN
switch in the Called Party Number parameter and the dialed digits in the GAP (if the number
is ported), or dialed digits in the Called Party Number parameter (if the number is not
ported).

11.2 Routing of Service-Related Messages in an LNP Environment


This subsection addresses the interconnection of the Bell Atlantic CCS network with other
ICNs to support the internetwork routing of service-related TCAP messages in an LNP
environment. The NP GTT function will be used by Bell Atlantic to accurately route
messages for affected services to the appropriate network element when the NPA-NXX in
the Global Title Address (GTA) of the service query is no longer sufficient to uniquely

11-3
Bell Atlantic Supplement TPG-00-001
Local Number Portability Issue 1, March 2000

identify the targeted network element (e.g., CLASS switch, LIDB). The NP GTT function
involves the application of STP-like GTT processing on a 10-digit basis to a service query
without modifying the TCAP information or the SCCP Calling Party Address information in
the query. Detailed requirements for the NP GTT function are specified in the T1S1.6
Working Group on Number Portability Technical Requirements No. 3, Number Portability
Database and Global Title Translation. The Bell Atlantic services that will be impacted by
LNP include Calling Name Delivery, CLASSSM, and LIDB Access. (See Section 9 for details
related to network interconnection procedures as they apply to these services.)

To the greatest degree possible, the NP GTT function allows interactions with LNP to be
transparent to the originating service node (e.g., CLASS switch, Operator Services System).
Therefore, Bell Atlantic expects that when a service node launches a service-related TCAP
query toward the node that is currently serving the ported user, and it encounters a node in
the Bell Atlantic CCS network, the query should contain, whenever possible, the same MTP,
SCCP and TCAP information as in a pre-LNP query environment. Bell Atlantic will apply
the NP GTT function to incoming queries when it determines it is appropriate to do so based
on the information in the SCCP Called Party Address field of the received query message.

If the LNP GTT processing within the Bell Atlantic network determines that the destination
for a service-related query is outside of the Bell Atlantic network, the NP GTT functionality
within a Bell Atlantic node will use information populated in the NP GTT translation tables
to determine a new DPC for the query message. A service-related query will contain the same
information in the SCCP Calling Party Address and TCAP portions of the outgoing message
as were present in the received message. Bell Atlantic expects the GTA and Translation Type
in the SCCP Called Party Address parameter to be encoded in the outgoing message as
received. The subsystem number and the routing indicator in the routing label are also
expected to be unchanged unless Bell Atlantic has a specific business arrangement with the
destination network provider to do final translations on their behalf.

Bell Atlantic should be contacted regarding specific details associated with the application of
the NP GTT function to service-related messages. Bell Atlantic expects that an ICN will
route internetwork queries that have undergone NP GTT processing in Bell Atlantic’s
network if that query originated in Bell Atlantic's network.

11-4
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Number Pooling

12 NUMBER POOLING
Bell Atlantic has plans to support the Thousand Block Number Pooling capability described
in T1S1.6 Working Group on Number Portability Technical Requirements No. 4, Thousand
Block Number Pooling Using Number Portability. This capability shares an NPA-NXX
among carriers, allocating numbers in blocks of one thousand numbers within the same NPA-
NXX-X to a shared pool associated with a designated geographic area, such that directory
numbers are available to service providers in blocks of 1000. This approach to Number
Pooling utilizes the infrastructure associated with the Location Routing Number (LRN)
method for Number Portability for call routing. Likewise, the routing of non-call associated
signaling messages associated with certain services (e.g., CLASSSM, LIDB, CNAM, ISVM
MWI) in a Number Pooling environment relies on the mechanisms available with the NP
GTT function. Bell Atlantic’s planned implementation of Number Pooling only supports
pooling within a rate center.

Since Bell Atlantic’s Number Pooling implementation utilizes the LNP infrastructure for call
routing and the routing of non-call associated signaling messages, an ICN that wishes to
interconnect with Bell Atlantic’s network to support call setup and the routing of non-call
associated messages to pooled numbers must support the interconnection requirements
described in Section 11 for Local Number Portability.

12-1
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Interconnection with Wireless Networks for Call Setup

13 INTERCONNECTION WITH WIRELESS NETWORKS FOR


CALL SETUP
This section specifies interfaces between a Wireless Service Provider (WSP) and Bell Atlantic
to support call setup using the SS7 protocol. Signaling interfaces for interconnection between
WSPs and Bell Atlantic are based on GR-905-CORE and are detailed in GR-1434-CORE. As
described in GR-145-CORE, the following SS7-related interface is supported between a WSP
and Bell Atlantic:

1. The Type S interface represents the physical signaling link connection that Bell Atlantic
expects to exist with a WSP. Bell Atlantic will interconnect with WSPs at mutually
agreed upon SPOIs within the LATA where Bell Atlantic STPs are located. There are
two architecture configurations that Bell Atlantic will allow for interconnection of Bell
Atlantic’s CCS network with a WSP’s CCS network.
• Interconnection of two networks via a mated STP pair in Bell Atlantic’s network to
a mated STP pair in the WSP network via Diagonal-link (D-link) quads.
• Interconnection of a WSP switching system with a mated STP pair in Bell Atlantic’s
network via Access-links (A-links).
2. The Type 2A with SS7 interface represents a physical SS7-supported trunk connection
between a WSP and a tandem switch in the Bell Atlantic network.
3. The Type 2B with SS7 interface represents a physical SS7-supported trunk connection
between a WSP’s switch and an end office switch in the Bell Atlantic network.

Basic call control involves the setup and release of call connections between an ISDN or non-
ISDN user served by Bell Atlantic and an ISDN or non-ISDN user served by a WSP. This
involves call setup and release in both directions i.e., in the mobile-to-land direction (WSP-
to-Bell Atlantic) and land-to-mobile direction (Bell Atlantic-to-WSP) for both intraLATA
and interLATA calls. It is therefore possible that other LECs or IXCs may be involved in the
call connection.

Basic call control involves the exchange of a sequence of ISDNUP messages between Bell
Atlantic and a WSP. See Section 5.1 of GR-1434-CORE for details related to the contents of
the ISDNUP messages needed for call setup. The SS7 call control protocol applies to both
Type 2A with SS7 trunk interfaces and Type 2B with SS7 trunk interfaces. Bell Atlantic
expects a WSP to conform to existing timer values for SS7 ISDNUP signaling, as defined in
Appendix B of GR-905-CORE.

Bell Atlantic expects that the calling party number parameter to be passed unchanged in
signaling by the WSP if that information is supplied by Bell Atlantic in call setup messages.
Likewise, Bell Atlantic expects to pass the calling party number parameter unchanged in call
setup signaling if received in a call setup message from a WSP.

In addition, Bell Atlantic will accept a Jurisdiction Information Parameter (JIP) in an IAM
received from a WSP and pass the parameter unchanged to other ICNs (if other ICNs are
involved). Bell Atlantic will also accept a JIP in an IAM received from an ICN and pass the
parameter unchanged to a WSP. Further, Bell Atlantic expects that other ICNs will pass a JIP
received in an IAM generated by Bell Atlantic unchanged should Bell Atlantic generate an
IAM that contains a JIP.

13-1
Bell Atlantic Supplement TPG-00-001
Interconnection with Wireless Networks for Call Setup Issue 1, March 2000

Bell Atlantic will accept a charge number parameter and originating line number parameter in
an IAM from a WSP and pass the parameters unchanged to a Feature Group D (FGD) IXC.
Bell Atlantic may or may not record the contents of either of these parameters for
Automatic Message Accounting (AMA) or other purposes.

Bell Atlantic will accept a carrier selection parameter in an IAM from a WSP and pass the
parameter unchanged to a FGD IXC. The carrier selection parameter contains an indication
of whether the selected IXC was chosen via presubscription and/or input by the user on the
call. Bell Atlantic does not expect to receive the carrier selection parameter in an IAM for
calls not destined to a FGD IXC.

Bell Atlantic will accept a carrier identification parameter in an IAM from a WSP and pass
the parameter unchanged to a FGD IXC. The carrier identification parameter contains the
identification of the IXC to be used on the call. Note that separate business arrangements
must exist between Bell Atlantic and an IXC for the carrier identification parameter to be
sent in an IAM on a particular trunk group to the IXC.

In the case of a forwarded call, Bell Atlantic will include forwarding-specific information in
an IAM sent to a WSP and expects to receive forwarding-specific information in an IAM
from a WSP, as defined in GR-1434-CORE. Forwarding-specific information includes the
numbers of the first and last forwarding parties under a sequential forwarding scenario, the
reasons for the first and last forwarding (i.e., user busy, no reply, unconditional) and a counter
representing the number of times the call has been forwarded. This information is contained
in three parameters of the IAM: the original called number parameter, the redirecting number
parameter, and the redirection information parameter.

13-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Signaling Link Physical-Level Specifications

14 SIGNALING LINK PHYSICAL-LEVEL SPECIFICATIONS

14.1 Link Facilities


Signaling connections are provided at the DS-0(A) level and provisioned in a DS-1 bit stream
to ensure performance and reliability. Bell Atlantic can provision a signaling connection in
its common facilities network or in a spare channel of a customer designated DS-1 Special
Access service, provided diversity requirements are met.

Signaling link facility circuits will be provisioned, engineered, designed, and identified in
COMMON LANGUAGE coding as message trunks.

The Feature Group D (FGD) Access Service Request (ASR) is to be used to order signaling
connections, and includes additional fields for SS7 link-specific parameters consistent with
industry agreements at the Ordering and Billing Forum (OBF).

14.2 Link Diversity Requirements


Bell Atlantic requires and will provide a certain minimum level of physical diversity of the
ICN signaling links and interoffice transmission facilities used to support them, wherever
possible.

14.2.1 Definition of Link Diversity


Two signaling links are considered fully diverse if they are physically and electrically
separated, both inside and outside of the central office environment, such that a single failure
cannot cause the failure of both links. A common building, entrance facility, carrier system,
digital cross-connect system, power supply, timing source, cable, or supporting structure (e.g.,
conduit, poll, line, radio tower, etc.) should not serve them. Exceptions may be made for
common entrance facilities, power supplies, and timing sources, where limitations exist in the
CO environment.
14.2.2 Diversity Conformance Specifications
The following diversity arrangements conform to the network design objective for
appropriate levels of network availability as set by the ITU-T (formerly the CCITT), later
adopted as an ANSI Committee T1 standard, and cited by Telcordia as generic requirements
in GR-246-CORE. Refer to Section 14.2.3 regarding the ramifications of ICN non-
conformance to these diversity requirements.

14.2.2.1 Bell Atlantic STP to ICN STP


To provide the level of survivability as described in GR-905-CORE, in the case of BA STP to
ICN STP interconnection, the ICN should provide signaling links in a D-link-set quad
arrangement to three, geographically separate Signaling Points Of Interface (SPOIs) from
which Bell Atlantic will maintain this three-way diversity to its STP pair.


COMMON LANGUAGE is a registered trademark of Telcordia Technologies, Inc.

14-1
Bell Atlantic Supplement TPG-00-001
Signaling Link Physical Level Specifications Issue 1, March 2000

14.2.2.2 Bell Atlantic STP to ICN SEP


In the case of BA STP to ICN SEP interconnection, two SPOIs are required. The ICN will
need to provide signaling links (an A link-set-pair) to two, geographically separate SPOIs
from which Bell Atlantic will maintain two-way diversity to its STP pair.
14.2.3 Ramifications of Diversity Non-Conformance
It is recommended that the ICN also maintain this same minimum level of diversity in its
network, as specified above. If an ICN chooses to implement a lesser degree of diversity,
then the level of performance and reliability described in GR-905-CORE may not be
achieved.

In the BA STP to ICN STP interconnection arrangement, wherein the ICN does not
interconnect at three separate SPOI locations as stated above, Bell Atlantic will attempt to
provide three diverse facility routes from the BA STP pair to the ICN SPOI(s).

In the BA STP to ICN SP interconnection arrangement, wherein the ICN does not
interconnect at two separate SPOI locations as stated above, Bell Atlantic will attempt to
provide two diverse facility routes from the BA STP pair to the ICN SPOI(s).

14-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Performance

15 PERFORMANCE

It is Bell Atlantic's objective to be compliant with the 10-minute end-to-end network


downtime objective as described in Section 7 of GR-905-CORE. It is also Bell Atlantic's
objective to be compliant with the availability and performance objectives related to LNP
query processing and LNP GTT processing specified in Section 4.10 of the Illinois Number
Portability Workshop Generic Requirements for the SCP Application and the GTT Function
for Number Portability. Furthermore, Bell Atlantic expects each ICN interconnecting to its
network to have the same objectives, where applicable, and to be pro-actively working to
meet these objectives

15-1
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Timer Values

16 TIMER VALUES
Timers are used in the MTP and ISUP protocol to enable the interconnecting network
elements to correlate events, and to verify the results of maintenance actions.

Timer values will be set within the ranges specified in Appendix B of GR-905-CORE. It is
Bell Atlantic’s intention to set timer values so as to ensure signaling compatibility between
the Bell Atlantic CCS network and the interconnecting ICN CCS network.

16-1
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Maintenance & Testing

17 MAINTENANCE & TESTING


This section will specify the minimum set of testing procedures required for interconnecting
to the Bell Atlantic network.

17.1 Bell Atlantic Position – Certification and Testing Procedures


If a carrier wishes to interconnect with Bell Atlantic, Bell Atlantic expects that party to
exercise due diligence in ensuring that the elements that they will be using for
interconnection and the software releases that they deploy (including any customization of
that software) are in compliance with applicable standards and industry agreements. The
carrier shall provide Bell Atlantic with evidence of that effort. In addition, if new or modified
software is loaded on any interconnected element, the interconnecting party must ensure that
the new release is also in compliance with the applicable standards and industry agreements,
and shall furnish that information to Bell Atlantic. This conformance testing is needed in
order to verify the ability of the elements to handle the protocol and message flows required
to support jointly provided service. Bell Atlantic requires the use of the tests listed in
Appendix C for conformance testing of interconnecting elements prior to interconnection
with the Bell Atlantic network.

Bell Atlantic requires notification by the ICN of any tests that were not passed, as well as an
explanation of the consequences of interconnecting with equipment that is non-conformant
in this way. Bell Atlantic also requires a committed timetable for remedying the non-
conformance.

After interconnecting elements have been tested for conformance, Bell Atlantic will perform
interconnection compatibility testing which will give a level of confidence that the ICN’s
network and the Bell Atlantic network will be able to safely interconnect. Interconnection
compatibility testing tests only the compatibility of protocol exchanged at the point of
interconnection. It does not fully test the interconnecting platforms, software releases, or
other network or customer elements.

In addition to the above, application specific tests may be required before application-level
signaling interactions are allowed. MTP Level 2 & 3, ISUP and other applications only test
certain functionalities. The specific tests to be used will be determined based on the responses
to the SS7 Interconnect Information Questionnaire. These tests will proceed normally
according to a mutually agreed-upon test plan and schedule developed at a meeting prior to
interconnection. Tests for MTP Level 2 & 3, ISUP, and SCCP compatibility will be based on
those tests documented and published by ANSI T1M1.3. These are the following:

• ANSI T1.234-1993, Signaling System Number 7 (SS7) – MTP Levels 2 and 3


Compatibility
• ANSI T1.235-1993, Signaling System Number 7 (SS7) – SCCP Class 0 Compatibility
• ANSI T1.236-1993, Signaling System Number 7 (SS7) – ISDN User Part Compatibility

17-1
Bell Atlantic Supplement TPG-00-001
Maintenance & Testing Issue 1, March 2000

17.2 Channel Service Unit (CSU) – No DS-0(A) Interface


The appropriate Channel Service Unit (CSU) should be installed at both ends of the Bell
Atlantic STP to ICN STP, and/or Bell Atlantic STP to ICN SP links, except where a DS-0(A)
interface is available (see Section 17.3). To support this testing capability, ICNs connected
to the Bell Atlantic network are required to support the latching and loopback testing
capabilities.

The ability of the CSU to provide for loopback on a link is a major benefit to the
sectionalization of link troubles. In general, the CSU will eliminate any doubt as to trouble
locations on the physical media carrying CCS data between Bell Atlantic and other service
providers.

17.3 DS-0(A) Interface


The DS-0(A) interface is available on some STP and SP architectures. The DS-0(A) allows
loopback for fault sectionalization, and will eliminate the need for a CSU at that end of the
link.

17-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix A

APPENDIX A: Translation Type Values

Service Translation Type Subsystem Number*


SM
CLASS 251 251
LIDB 253 253
CNAM 5 253
Toll Free 254 254
LNP (AIN) 11 248
LNP (IN) 248 248
ISVM MWI 7 249
891 Calling Card 1 232
AIN (0.0) 250 250
AIN (0.1) 247 247

*The values illustrated in the table are the subsystem number values that Bell Atlantic uses
within its network for the services identified. Bell Atlantic recognizes that the assignment of
subsystem number values is a network-specific decision, however, for administrative
convenience, it is preferred that the subsystem number values used by ICNs that wish to offer
the above services in conjunction with Bell Atlantic align with the values shown in the table.

Appendix A-1
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix B

APPENDIX B: Tones and Announcements


The following table identifies the Bell Atlantic treatment for Tones and Announcements for
unsuccessful calls that will be released back toward the originating end:

Table B-1 – Handling of Events Resulting in an Unsuccessful Call

Event Caus Announceme Tone No Interworking Interworkin


e nt g
Valu
e
Unallocated 1 *INT --- RWC** TP
Number
No Route to 3 *VC 120 IPM RWC TP
Destination
User Busy 17 --- 60 IPM RWC RWC
Call 21 *INT --- RWC TP
Rejected
Number 22 *INT --- RWC** TP
Changed
Exchange 25 NC RO RWC TP
Routing
Error
Destination 27 *INT --- RWC** TP
Out of
Order
No Circuit 34 NC 120 IPM RWC TP
Available
Temporary 41 RO 120 IPM RWC TP
Failure
Switching 42 RO 120 IPM RWC RWC
Equipment
Congestion
Resource 47 RO 120 IPM RWC TP
Unavailable
Protocol 111 RO 120 IPM RWC TP
Error

* If no specialized announcements are available at the terminating exchange or an


operator services position, a generic announcement will be provided.

** TP will need to be used for these cause codes if specialized announcements specific to
the called party are to be played at the terminating exchange.

VC = Vacant Code RWC = Release With Cause


NC = No Circuit TP = Play in Terminating Network
RO = Reorder INT = Intercept

Appendix B-1
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C

APPENDIX C: List of Conformance Tests


This appendix lists the conformance tests that Bell Atlantic requires to be performed (as
applicable) on an interconnecting element. These tests are intended to ensure that the
network elements that ICNs will be using for interconnection and the software releases that
they deploy (including any customization of that software) are in compliance with applicable
standards and industry agreements. These tests are to be completed prior to the performance
of interconnection compatibility testing for interconnection to the Bell Atlantic network.
Bell Atlantic requires notification by the ICN of any tests that were not passed, as well as an
explanation of the consequences of interconnecting with equipment that is non-conformant
in this way. Bell Atlantic also requires a committed timetable for remedying the non-
conformance.

The list of MTP Level 2 tests shown here is based on ITU-T Recommendation Q.781; the
list of MTP Level 3 tests is based on ITU-T Recommendation Q.782; and the list of ISUP
tests is based on ITU-T Recommendation Q.784.1.

A. MTP Level 2 Tests

1. Link State Control (expected signal units/orders)

1.1 Initialization (Power Up)


1.2 Timer T2
1.3 Timer T3
1.4 Timer T1 and T4 (Normal)
1.5 Normal alignment - correct procedure (FISU)
1.6 Normal alignment - correct procedure (MSU)
1.7 SIO received during normal proving period
1.8 Normal alignment with PO set (FISU)
1.9 Normal alignment with PO set (MSU)
1.10 Normal alignment with PO set and clear
1.11 Set RPO when “Aligned not ready”
1.12 SIOS received when “Aligned not ready”
1.13 SIO received when “Aligned not ready”
1.14 Set and clear LPO when “Initial alignment”
1.15 Set and clear LPO when “Aligned ready”
1.16 Timer T1 in “Aligned not ready” state
1.17 No SIO sent during normal proving period
1.18 Set and cease emergency prior to “start alignment”
1.19 Set emergency while in “not aligned” state
1.20 Set emergency when “aligned”
1.21 Both ends set emergency
1.22 Individual ends set emergency
1.23 Set emergency during normal proving
1.24 No SIO sent during emergency alignment
1.25 Deactivation during initial alignment
1.26 Deactivation during aligned state
1.27 Deactivation during aligned not ready
1.28 SIO received during link in service
1.29 Deactivation during link in service
1.30 Deactivation during LPO

Appendix C-1
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000

1.31 Deactivation during RPO


1.32 Deactivation during the proving period
1.33 SIO received instead of FISUs
1.34 SIOS received instead of FISUs
1.35 SIPO received instead of FISUs

2. Link State Control (unexpected signal units/orders)

2.1 Unexpected signal units/orders in “out of service” state


2.2 Unexpected signal units/orders in “not aligned” state
2.3 Unexpected signal units/orders in “aligned” state
2.4 Unexpected signal units/orders in “proving” state
2.5 Unexpected signal units/orders in “aligned ready” state
2.6 Unexpected signal units/orders in “aligned not ready” state
2.7 Unexpected signal units/orders in “in service” state
2.8 Unexpected signal units/orders in “processor outage” state

3. Transmission failures

3.1 Link aligned ready (break Tx path)


3.2 Link aligned ready (corrupt FIBs)
3.3 Link aligned not ready (break Tx path)
3.4 Link aligned not ready (corrupt FIBs)
3.5 Link in service (break Tx path)
3.6 Link in service (corrupt FIBs)
3.7 Link in processor outage (break Tx path)
3.8 Link in processor outage (corrupt FIBs)

4. Processor Outage Control

4.1 Set and clear LPO while link in service


4.2 RPO during LPO
4.3 Clear LPO when “both processor outage”

5. SU Delimitation, Alignment, Error Detection and Correction

5.1 More than seven “1”s between MSU opening and closing flags
5.2 Greater than maximum signal unit length
5.3 Below minimum signal unit length
5.4 Reception of single and multiple flags between FISUs
5.5 Reception of single and multiple flags between MSUs

Appendix C-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C

6. SUERM check

6.1 Error rate of 1 in 256 - link remains in service


6.2 Error rate of 1 in 254 - link into out of service
6.3 Consecutive corrupted SUs
6.4 Time controlled break of the link

7. AERM check

7.1 Error rate below the normal threshold


7.2 Error rate at the normal threshold
7.3 Error rate above the normal threshold
7.4 Error rate at the emergency threshold

8. Transmission and reception control (Basic)

8.1 MSU transmission and reception


8.2 Negative acknowledgment of MSU
8.3 Check RTB full
8.4 Single MSU with erroneous FIB
8.5 Duplicated FSN
8.6 Erroneous retransmission - single MSU
8.7 Erroneous retransmission - multiple FISUs
8.8 Single FISU with corrupt FIB
8.9 Single FISU prior to RPO being set
8.10 Abnormal BSN - single MSU
8.11 Abnormal BSN - two consecutive FISUs
8.12 Excessive delay of acknowledgment
8.13 Level 3 stop command

9. Transmission and reception control (Preventive Cyclic Retransmission)

9.1 MSU transmission and reception


9.2 Priority control
9.3 Forced retransmission with the value N1
9.4 Forced retransmission with the value N2
9.5 Forced retransmission cancel
9.6 Repetition of forced retransmission
9.7 MSU transmission while RPO set
9.8 Abnormal BSN – Single MSU
9.9 Abnormal BSN – Two MSUs
9.10 Unexpected FSN
9.11 Excessive Delay of Acknowledgement
9.12 FISU with FSN expected for MSU
9.13 Level 3 Stop Command

Appendix C-3
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000

10. Congestion Control

10.1 Congestion Abatement


10.2 Timer T7
10.3 Timer T6

Appendix C-4
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C

B. MTP Level 3 Tests

1. Signaling Link Management

1.1 First signaling link activation


1.2 Signaling linkset deactivation
1.3 Signaling linkset activation

2. Signaling Message Handling

2.1 Message received with an invalid SSF (discrimination function)


2.2 Message received with an invalid DPC (discrimination function)
2.3 Message received with an invalid SI (distribution function)
2.4 Load sharing within a linkset
2.4.1 All links available
2.4.2 With two links available
2.5 Load sharing between linksets
2.5.1 Between two linksets
2.5.2 Between three linksets
2.5.3 Between three linksets and one route unavailable
2.5.4 Between three linksets and one linkset unavailable
2.6 Inaccessible destination
2.6.1 Due to a linkset failure
2.6.2 Due to a route failure
2.6.3 Due to a linkset and route failure
2.7 Message transfer function

3. Changeover

3.1 Changeover initiated at one side of a linkset (COO<->COA)


3.2 Changeover initiated at both ends at the same time (COO<->COO)
3.3 Changeover on expiration of timer T2 (COO or ECO -> -)
3.4 Unreasonable FSN in COO/COA
3.5 Reception of a changeover acknowledgment without sending a changeover
order (- <- COA or ECA)
3.6 Reception of an additional changeover order (- <- COO or ECO)
3.7 Emergency changeover at one side of a linkset (COO <-> ECA)
3.8 Emergency changeover at one side of a linkset (COO <-> ECO)
3.9 Emergency changeover at one side of a linkset (ECO <-> COA)
3.10 Emergency changeover at one side of a linkset (ECO <->ECA)
3.11 Emergency changeover at one side of a linkset (ECO<->COO)
3.12 Emergency changeover initiated at both ends at the same time
(ECO<->ECO)
3.13 Reactivation of a link during a changeover procedure
3.14 Simultaneous changeover
3.15 Changeover to several alternative links within a linkset
3.16 Changeover to another linkset w/the adjacent SP accessible
3.17 Changeover to another linkset w/the adjacent SP inaccessible
3.18 Changeover to two linksets
3.19 Changeover due to various reasons
3.20 Changeover as compatibility test
3.21 Reception of a changeover order on an available link

Appendix C-5
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000

4. Changeback

4.1 Changeback within a linkset


4.2 Additional CBA
4.3 Additional CBD
4.4 No acknowledgment to first CBD
4.5 No acknowledgment of repeat changeback declaration
4.6 Simultaneous changeback
4.7 Changeback from several alternative links within a linkset
4.8 Changeback from another linkset
4.9 Changeback from two linksets
4.10 Changeback due to various reasons
4.11 Time controlled diversion procedure

5. Forced Rerouting

6. Controlled Rerouting

7. Management Inhibiting

7.1 Inhibition of a link


7.1.1 Available link
7.1.2 Unavailable link
7.2 Inhibition not permitted
7.2.1 Local reject on an available link
7.2.2 Local reject on an unavailable link
7.2.3 Sending of LID
7.2.4 Reception of LID
7.3 Expiration of T14
7.3.1 On an available link
7.3.2 On an unavailable link
7.4 Additional Inhibition Messages (LIA, LID, LIN)
7.5 Inhibition asked by both ends
7.6 Manual uninhibition of a link
7.6.1 with changeback
7.6.2 without changeback
7.7 Expiration of T12
7.8 Not possible uninhibition
7.9 Automatic uninhibition of a link
7.10 Forced uninhibition of a link
7.10.1 Sending of LFU
77 7.10.2 Reception of LFU
7.11 Expiration of T13
7.12 Additional uninhibition messages (LUA, LUN, LFU)
7.13 Uninhibition at one side after test 7.5
7.14 Automatic uninhibition after test 7.5
7.15 Automatic uninhibition when two links are inhibited
7.16 Reception of traffic on an inhibited link
7.17 Management inhibiting test
7.17.1 Normal procedure

Appendix C-6
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C

7.17.2 Reception of an LLT or LRT on an uninhibited link


7.17.3 Reception of an LLT on a link locally inhibited
7.17.4 Reception of an LRT on a link remotely inhibited

8. Signaling Traffic Flow Control

8.1 Reception of a TFC


8.2 Sending of TFCs
8.3 Reception of a UPU
8.4 Sending of a UPU

9. Signaling Route Management

9.1 Sending of a TFP on an alternative route


9.1.1 Failure of normal linkset
9.1.2 On reception of a TFP
9.2 Broadcast of TFPs
9.2.1 On one linkset failure
9.2.2 On multiple failures
9.3 Reception of a message for an unaccessible destination
9.4 Sending of a TFA on an alternative route
9.4.1 Recovery of normal linkset
9.4.2 On reception of a TFA
9.5 Broadcast of TFAs
9.5.1 On one linkset recovery
9.5.2 Various reasons
9.6 Periodic sending of signaling-route-set-test messages
9.7 Reception of signaling-route set test message

10. Signaling Point Restart

10.1 Recovery of a linkset (SP A has not the STP function)


10.1.1 with use of point restart procedure
10.1.2 without use of point restart procedure
10.2 Recovery of a linkset (SP A has the STP function)
10.2.1 with use of point restart procedure
10.2.2 without use of point restart procedure
10.3 An adjacent signaling point becomes accessible via another signaling point
(SP A has not STP function)
10.4 An adjacent signaling point accessible via another signaling point (SP A has
STP function)
10.5 Restart of an SP having no STP function
10.6 Restart of an SP having STP function
10.7 Reception of an unexpected TRA
10.7.1 In an SP having no STP function
10.7.2 In an SP having STP function

11. Traffic test

12. Signaling link test

12.1 After activation of a link

Appendix C-7
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000

12.2 No acknowledgment to first SLTM


12.3 No acknowledgment to second SLTM
12.4 Unreasonable field in an SLTA
12.5 Reception of an SLTM in an attempt route
12.6 Additional SLTA, SLTM

13. Invalid Messages

13.1 Invalid H0, H1 in a signaling network management message


13.2 Invalid changeover messages
13.3 Invalid changeback messages
13.4 Invalid changeback code
13.5 Invalid inhibition messages
13.6 Invalid transfer control messages
13.7 Invalid signaling route management messages
13.8 Invalid Signaling-Route-Set-Test messages
13.9 Invalid traffic restart allowed message
13.10 Invalid H0, H1 in a signaling network testing and maintenance message
13.11 Invalid signaling link test messages
13.12 Invalid user part unavailable messages

Appendix C-8
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C

C. ISUP Tests

1. Circuit supervision and signaling supervision

(Test 1.1) Non-allocated circuits

Reset of circuits

(Test 1.2.1) RSC received on an idle circuit


(Test 1.2.2) RSC sent on an idle circuit
(Test 1.2.3) RSC received on a locally blocked circuit
(Test 1.2.4) RSC received on a remotely blocked circuit
(Test 1.2.5) Circuit group reset received
(Test 1.2.6) Circuit group reset sent
(Test 1.2.7) Circuit group reset received on remotely blocked circuits

Blocking of circuits
Circuit group blocking/unblocking

(Test 1.3.1.1) CGB and CGU received


(Test 1.3.1.2) CGB and CGU sent

Circuit Blocking/Unblocking

(Test 1.3.2.1) BLO received


(Test 1.3.2.2) BLO sent
(Test 1.3.2.3) Blocking from both ends; removal of blocking from one end
(Test 1.3.2.4) IAM received on a remotely blocked circuit
(Test 1.3.2.5) Blocking with CGB, unblocking with UBL

Continuity check procedure

(Test 1.4.1) CCR received; successful


(Test 1.4.2) CCR sent; successful
(Test 1.4.3) CCR received; unsuccessful
(Test 1.4.4) CCR sent; unsuccessful
(Test 1.4.5) CCR not received; unsuccessful; verify T27 timer

Receipt of unreasonable signaling information messages

(Test 1.5.1) Receipt of unexpected messages


(Test 1.5.2) Receipt of unexpected messages during call setup
(Test 1.5.3) Receipt of unexpected messages during a call

Appendix C-9
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000

2. Normal call setup – ordinary speech calls

Both way circuit selection

(Test 2.1.1) IAM sent by controlling SP


(Test 2.1.2) IAM sent by non-controlling SP

Called address sending

(Test 2.2.1) “ en bloc” sending

Successful call setup


(Test 2.3.1) Ordinary call (with various indications in ACM)
(Test 2.3.2) Ordinary call (with ACM, CPG, and ANM)
(Test 2.3.3) Ordinary call with CON
(Test 2.3.5) Blocking and unblocking during a call (initiated)
(Test 2.3.6) Blocking and unblocking during a call (received)

3. Normal call release

(Test 3.1) Calling party clears before address complete


(Test 3.2) Calling party clears before answer
(Test 3.3) Calling party clears after answer
(Test 3.4) Called party clears after answer
(Test 3.5) Suspend initiated by the network
(Test 3.8) Collision of REL messages

4. Unsuccessful call setup

(Test 4.1) Validate a set of known causes for release

5. Abnormal situations during a call

(Test 5.1) Inability to release in response to a REL after ANM

Timers

(Test 5.2.1) T7: waiting for ACM or CON


(Test 5.2.2) T9: waiting for ANM
(Test 5.2.3) T1 and T5: failure to receive a RLC
(Test 5.2.4) T6: waiting for RES (Network) message
(Test 5.2.5) T8: waiting for COT message if applicable
(Test 5.2.6) T12 and T13: failure to receive a BLA
(Test 5.2.7) T14 and T15: failure to receive a UBA
(Test 5.2.8) T16 and T17: failure to receive a RLC
(Test 5.2.9) T18 and T19: failure to receive a CGBA
(Test 5.2.10) T20 and T21: failure to receive a CGUA
(Test 5.2.11) T22 and T23: failure to receive a GRA

Reset of circuits during a call

Appendix C-10
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C

(Test 5.3.1) Reset of an outgoing circuit during a call


(Test 5.3.2) Reset of an incoming circuit during a call

6. Special call setup

Continuity check call

(Test 6.1.1) Continuity check required


(Test 6.1.2) COT applied on previous circuit
(Test 6.1.3) Calling party clears during a COT
(Test 6.1.4) Delay of through connect
(Test 6.1.5) COT unsuccessful

Automatic repeat attempt

(Test 6.2.1) Dual seizure for non-controlling SP


(Test 6.2.2) Blocking of circuit
(Test 6.2.3) Circuit reset
(Test 6.2.4) Continuity check failure
(Test 6.2.5) Reception of unreasonable signaling information

Dual seizure

(Test 6.3.1) Dual seizure for controlling SP

7. Bearer services

64 kb/s unrestricted

(Test 7.1.1) Successful call setup


(Test 7.1.2) Unsuccessful call setup
(Test 7.1.3) Dual seizure

3.1 kHz audio

(Test 7.2.1) Successful call setup

Multirate connection types

(Test 7.3.1) Successful multirate outgoing call setup


(Test 7.3.2) Successful multirate incoming call setup
(Test 7.3.3) Unsuccessful multirate call setup – one circuit already busy
(Test 7.3.4) Dual seizure of different connection types: Controlling exchange
(Test 7.3.5) Dual seizure of different connection types: Non-controlling exchange
(Test 7.3.6) Abnormal procedure, Multirate connection types call sent to an
exchange not supporting the procedure

8. Congestion control and user flow control

Automatic congestion control

(Test 8.1.1) Receipt of a release message containing an automatic congestion level

Appendix C-11
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000

parameter
(Test 8.1.2) Sending of a release message containing an automatic congestion level
control

9. Echo control procedure

Echo control procedure according to Q.767

(Test 9.1.1) Q.767 echo control procedure for call setup (initiated in SP A)
(Test 9.1.2) Q.767 echo control procedure for call setup (initiated in SP B)

Appendix C-12
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Glossary

GLOSSARY

ABS Alternate Billing Service


ACC Automatic Congestion Control
ACM Address Complete Message
ACTL Access Customer Terminal Line
AIN Advanced Intelligent Network
ALC A Link Concentrator
ANI Automatic Number Identification
ANM Answer Message
ANSI American National Standards Institute
ASR Access Service Request
AT Access Tandem
ATP Access Transport Parameter
BA Bell Atlantic
BOC Bell Operating Company
CAP Competitive Access Provider
CCS Common Channel Signaling
CCSNIS Common Channel Signaling Network Interface Specification
CCSSO Common Channel Signaling Switching Office
CdPA Called Party Address
CFN Confusion Message
CgPN Calling Party Address
CIP Carrier Identification Parameter
CLASS Custom Local Area Signaling Services
CLEC Competitive Local Exchange Carrier
CNAM Calling Name Delivery
COT Continuity Message
CPE Customer Premise Equipment
CPG Call Progress Message
CPN Calling Party Number
CRA Circuit Reservation Acknowledgement
CRM Circuit Reservation Message
CSU Channel Service Unit
DPC Destination Point Code
DS-0(A) Digital Signal Level 0A (64 Kbps)
DS-1 Digital Signal Level 1 (1.544 Mbps)
EC Exchange Carrier
EO End Office
ESF Extended Superframe Format
ESP Enhanced Service Provider
EXM Exit Message
FGB Feature Group “B”
FGD Feature Group “D”
GAP Generic Address Parameter
GR Generic Requirements
GTA Global Title Address
GTT Global Title Translation

Glossary-1
Bell Atlantic Supplement TPG-00-001
Glossary Issue 1, March 2000

HSL High Speed Links


IAM Initial Address Message
ICN Interconnecting Network (Interexchange, Independent, Reseller, etc)
IN Intelligent Network
INC International Carrier
INPA Interchangeable Numbering Plan Area
IXC Interexchange Carrier
ISDN Integrated Services Digital Network
ISDNUP Integrated Services Digital Network User Part
ISNI Intermediate Signaling Network Identification
ISUP Integrated Services User Part
JIP Jurisdiction Information Parameter
kbps kilobits per second
kHz kiloHertz
LATA Local Access and Transport Area
LEC Local Exchange Carrier
LERG Local Exchange Routing Guide
LIDB Line Information Data Base
Link Diversity **, ***
LNP Local Number Portability
LRN Location Routing Number
LSPP Local Service Provider Portability
MF Multifrequency
MSU Message Signal Unit
MTP Message Transfer Part
Multi-Sector One STP Pair Addresses Multiple Sectors
NANP North American Numbering Plan
NAP Network Access Point
NCM Network Cluster Member
NI Network Identifier
NIIF Network Interconnection/Interoperability Forum
NP Network Provided Number
NPA Numbering Plan Area
NP GTT Number Portability Global Title Translation
OBF Ordering and Billing Forum
OCN Original Called Number
OLC Other LATA Carriers
OLIP Originating Line Information Parameter
OPC Originating Point Code
OSS Operator Services Systems
POP Point of Presence
POTS Plain Old Telephone Service
Q/R Query/Response
REL Release Message
RES Resume Message
RLC Release Complete Message
SAAL Signaling-ATM Adaptation Layer
SAC Service Access Code
SCCP Signaling Connection Control Part
SCP Service Control Point (Database)
Sector EO Group which all subtend an STP pair

Glossary-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Glossary

SEP Signaling End Point


SIO Service Information Octet
SLS Signaling Link Selection
SPC Signaling Point Codes
SPOI Signaling Point of Interface
SS7 Signaling System 7
STP Signal Transfer Point
SSP Service Switching Point
SUS Suspend Message
SWF-DS1 Switched DS1/Switched Fractional DS1 Service
TC Telecommunications Carrier
TCAP Transaction Capability Application Part
TFC Transfer Control
TNS Transit Network Selection
TR Technical Reference
TSP Tandem Service Provider
TTN Translation Type
UDT Unitdata Message
UDTS Unitdata Service Message
UP User Provided
UPFS User Provided, Failed Network Screening Number
UPNS User Provided, Not Screened Number
UPPS User Provided, Passed Network Screening Number
WSP Wireless Service Provider
XUDT Extended Unitdata Message

** Link Diversity - 3 Way is defined as a “D” link quad of which at least three links are over
diverse routes to the ICN interface(s). They should not be served by a common building,
carrier system, cable, or supporting structure (radio tower, pole line, or conduit).

*** Link Diversity - 2 Way is defined as an “A” Link Pair in which each link in the pair is
provisioned over diverse routes to the ICN interface(s). They should not be served by a
common building, carrier system, cable, or supporting structure (radio tower, pole line, or
conduit).

Glossary-3

Das könnte Ihnen auch gefallen