Documente Academic
Documente Profesional
Documente Cultură
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
16 TIMER VALUES........................................................................................................16-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.
1-1
Bell Atlantic Supplement TPG-00-001
Introduction Issue 1, March 2000
1
CLASS is a service mark of Telcordia Technologies
1-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Introduction
1-3
Bell Atlantic Supplement TPG-00-001
Introduction Issue 1, March 2000
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.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
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.
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.
• 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).
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
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
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:
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.
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.
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-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.
• 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.
• 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.
• 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.
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
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.
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.
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-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-3
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Capabilities Supported – Internetwork Call Control
• 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)
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.
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-3
Bell Atlantic Supplement TPG-00-001
Capabilities Supported – Internetwork Call Control Issue 1, March 2000
4-4
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Capabilities Supported – Internetwork Call Control
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-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.
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
Bell Atlantic Supplement TPG-00-001
Capability-Related Protocol Issue 1, March 2000
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.
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.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
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.
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-1
Bell Atlantic Supplement TPG-00-001
ISUP Non-Capability Related Protocol Issue 1, March 2000
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
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:
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
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
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Transaction Capabilities Application Part (TCAP) Protocol
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.
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.
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.
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.
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 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.
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.
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-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.
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
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
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).
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
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.
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.
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.
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.
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-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
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
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).
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
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
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
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:
17-1
Bell Atlantic Supplement TPG-00-001
Maintenance & Testing Issue 1, March 2000
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-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix A
*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
** 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.
Appendix B-1
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C
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.
Appendix C-1
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000
3. Transmission failures
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
7. AERM check
Appendix C-3
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000
Appendix C-4
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C
3. Changeover
Appendix C-5
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000
4. Changeback
5. Forced Rerouting
6. Controlled Rerouting
7. Management Inhibiting
Appendix C-6
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C
Appendix C-7
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000
Appendix C-8
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C
C. ISUP Tests
Reset of circuits
Blocking of circuits
Circuit group blocking/unblocking
Circuit Blocking/Unblocking
Appendix C-9
Bell Atlantic Supplement TPG-00-001
Appendix C Issue 1, March 2000
Timers
Appendix C-10
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Appendix C
Dual seizure
7. Bearer services
64 kb/s unrestricted
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
(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
Glossary-1
Bell Atlantic Supplement TPG-00-001
Glossary Issue 1, March 2000
Glossary-2
TPG-00-001 Bell Atlantic Supplement
Issue 1, March 2000 Glossary
** 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