Rochester Institute of Technology RIT Scholar Works
Theses
2002
Economic analysis of the cost of inconsistencies in the implementation of ISDN network layer standards
Thomas Bennett
Follow this and additional works at: https://scholarworks.rit.edu/theses
Recommended Citation Bennett, Thomas, "Economic analysis of the cost of inconsistencies in the implementation of ISDN network layer standards" (2002). Thesis. Rochester Institute of Technology. Accessed from
This Thesis is brought to you for free and open access by RIT Scholar Works. It has been accepted for inclusion in Theses by an authorized administrator of RIT Scholar Works. For more information, please contact [email protected]. Economic Analysis of the Cost of Inconsistencies in the Implementation of ISDN Network Layer Standards
By
Thomas R. Bennett
Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Information Technology
Rochester Institute of Technology
B. Thomas Golisano College of Computing and Information Sciences
March 2002 Thesis Reproduction Permission Form
Rochester Institute of Technology
B. Thomas Golisano College of Computing and Information Sciences
Master of Science in Information Technology
Economic Analysis of the Cost of Inconsistencies in the Implementation of ISDN Network Layer Standards
I, Thomas R. Bennett, hereby grant permission to the Wallace Library of the Rochester Institute of Technology to reproduce my thesis in whole or in part. Any reproduction must not be for commercial use or profit.
Date: ~) J&/JOQ;2.. Signature of Author: _ Rochester Institute of Technology
B. Thomas Golisano College of Computing and Information Sciences
Master of Science in Information Technology
Thesis Approval Form
Student Name: Thomas R. Bennett
Project Title: Economic Analysis of the Cost of Inconsistencies in the Implementation of ISON Network Layer Standards
Thesis Committee
Name Signature Date
Prof. Rayno Niemi Chair
Prof. Jim Leone Committee Member
Mr. Michael Valcourt Committee Member TABLE OF CONTENTS
Chapter Page TABLE OF CONTENTS i LIST OF FIGURES ii LIST OF TABLES iv
ACKNOWLEDGEMENTS v ABSTRACT 1 I. INTRODUCTION 2 II. BACKGROUND 9 III. CASE STUDY ANALYSIS 35 A. PROCESS FOR SELECTION 35 B. TESTING AND ALAYISIS PROCEEDURE 36 C. CASE A 45 D. CASE B 50 E. CASE C 56 F. CASE D 62 G. CASE E 71 H. CASE F 75 I. CASE G 82 D. CASE H 86 IV. CASE STUDY ECONOMIC EVELUATION 94 V. SUMMERY OF IMPACT AND RECOMMENDATIONS 1 1 1 VI. REFERENCES 117 LIST OF FIGURES
Number Page 1-1 Typical Analog Telecommunications Network 2 1-2 OSI Reference Model and ISDN Protocol Stacks 4
1-3 Primary Rate ISDN Channel Mapping - FAS 4 II-l ISDN Physical Layer Interface Points 10 II-2 Typical Multi-Vendor ISDN Configuration 11
II-3 Extended Super Frame Format - DS1 Signaling 12 II-4 B8ZS Line Coding- DS1 Signaling 13 II-5 The I Frame for the Data-Link Layer 15 II-6 The U Frame for the Data-Link Layer 16 II-7 The S Frame for the Data-Link Layer 17 II-8 Procedure for I Frame Acknowledgement Using RR Frames 18 II-9 General Message Format Layer 3 22 11-10 The Call Reference 23 11-11 Messages Passed via PSTN Signaling System 26 11-12 SS7 Protocol Stack 27 11-13 Message Flow for Call Establishment 28 11-14 ANSI and ITU-T Initial Address Message (IAM) Format 29 11-15 ANSI and ITU-T Address Complete Message (ACM) Format 30 11-16 ANSI and ITU-T Answer Message (ANM) Format 31 11-17 Message Flow for Call Tear Down 32 11-18 ANSI and ITU-T Release (REL) Message Format 33 11-19 ANSI and ITU-T Release Complete (RLC) Message Format 34 III-l The Setup Message 36 III-2 Typical Analyzer Schematic (non 5ESS) 38 III-3 Typical Analyzer Schematic (5ESS) 39 III-4A Typical Setup Message 40 III-4B Setup Message Header 41 III-4C Bearer Capability IE Decode 42 III-4D Channel ID IE Decode 43 III-4E Calling Party IE Decode 44 III-4F Called Party IE Decode 45 "A" III-5A Case Setup Message 47 "A" III-5B Case Release Complete Message 48
"A" III-5C Case decoded Release Complete Message 49 III-5D North American Numbering Plan 49 "A" III-5E Case Decoded Called Party IE 50 "B" III-6A Case Setup Message 52 "B" III-6B Case Call Proceeding Message 53 "B" III-6C Case Progress Message 53
"B" III-6D Case Disconnect Message 54
"B" III-6E Case Release Message 54
"B" III-6F Case Setup Message, Called Number I.E. Decode 55
n "B" III-6G Case Progress Message. Progress I.E. decode 56 "C" III-7A Case Setup Message 58 "C" III-7B Case Release Complete Message 59
"C" III-7C Case Decoded Release Complete Message 60
"C" III-7D Case Decoded Network Specific Facility I.D 61 "D" III-8A Case SS7 ISUP Release Message 63
"D" III-8B Case SS7 Initial Address Message 64 "D" III-8C Case Setup Message 66 "D" III-8D Case Decoded Calling Party IE 67 "E" III-9A Case Setup Message 73 "E" III-9B Case Call Proceeding Message 74 "E" III-9C Case Progress Message 74 "E" III-9D Case Disconnect Message 75
"F" 111-10 Case Intra Switch Connection Diagram 76
"F" III-10A Case User A Setup Message 78 "F" III-10B Case User A Call Proceeding Message 79 III-10C Case "F" User A Disconnect Message 79
"F" III-10D Case User A Release Message 79 III-10E Case "F" User A Release Complete Message 80 III-10F Case "F" User A Decoded Progress IE 81
"F" III-10G Case User A Decoded Progress IE (after software fix) 82 III-11A Case "G" SS7 ISUP Release Message 84 III-11B Case "G" SS7 ISUP Release Complete Message 84 III-11C Case "G" SS7 ISUP IAM Access Transport 85
"G" III-11D Case Setup Message Progress Message 86 III-11E Case "G" ISUP Access Transport (post fix) 86 III-12A Case "H" SS7 ISUP IAM (3.1 Khz) 88 "H" III-12B Case Setup Message (speech) 89 III-12C Case "H" Bearer Capability IE Decode 90 III-12D Case "H" Setup Message Progress IE Decode 91 "H" III-12E Case Layer 3 Setup Message with Progress I.E. Removed 92 III-12F Case "H" SS7 IAM Showing Speech Transfer Rate 92
m LIST OF TABLES
Number Page 1-1 Signaling in an Analog Telecommunications Network 3 II-l Common SAPI and TEI Address's 14
II-2 Examples of U Frames 16
II-3 Examples of the S Frame 17 II-4 ISDN Call Control (Layer 3) Messages 21 II-5 Message Types / Values 24 II-6 Information Element Identifiers 25 III-l Valid Information Elements 37 III-2 Layer 3 Timers 69
"E" III-3 Case Summary of Events 72 "F" III-4 Case Summary of Events 77
IV-1 Layer 3 Trouble Reports - 1/1/01 through 12/31/01 95 IV-2 Case "A" Costs 97 IV-3 Case "B" Costs 98 IV-4 Case "C" Costs 99 IV-5 Case "D" Costs 100 IV-6 Case "E" Costs 101 IV-7 Case "F" Costs 102 IV-8 Case "G" Costs 103 IV-9 Case "H" Costs 104 IV-10 Group I Average Expenses 105 IV-11 Group II Average Expenses 106 IV-12 Group III Average Expenses 106 IV-13 Group IV Average Expenses 107 IV-14 Annual Expenses by Group 107 IV-15 Percentage ofTotal Annual group Expense by Type 109 IV-16 Percentage ofTotal Annual Expense by Group 109
IV ACKNOWLEDGMENTS
I would like to thank Dr. Rayno Niemi for his support and the patience he has shown me through out this project. I would also like to thank professor Diane Bills for assisting in my re-admittance to the graduate school at RIT, and allowing me to continue with this thesis.
There are several people at WorldCom who directly assisted me in preparing this
Thesis. I would like to thank Shawn Haubrich, Jason Bauman, Tracey Knight and
Matthew Ottey for their help in data captures and analysis. I would also like to acknowledge the management in WorldCom for providing flexibility with my work schedule so that I could continue the research for this thesis. Special thanks to Roland
Lemus and Michelle Shuchman for providing me the opportunity to do what I truly enjoy, and derive a paycheck to boot.
I, also want to thank my two sons', Justin and Travis for helping me recover from computer crashes, and giving me spiritual strength to continue with this project. And my daughter Ashley for her light heart and sense of humor which was sorely needed during the later stages when I remained glued to a PC for days at a time.
Finally, I would like to thank my dear wife Sheree. She has remained by my side, through thick and thin for twenty-two plus years. She has endured the endless routine of night school, undergraduate and graduate studies, and put up with my antisocial behavior patterns during the past months as I neared completion of this thesis. Through all this she never lost faith in me, and her inspiration and strength became the driving force in me to finish this thesis. I was truly blessed the day that I met Sheree. ABSTRACT
Case studies depicting ISDN network layer interoperability and standards nonconformance were evaluated, and categorized by type. In each case study the root cause of the interoperability problem was identified, and validated with reference to the applicable ISDN standard. Corrective measures were proposed, and where implemented, the results of the correction were documented. Relative costs associated with the interoperability issue were identified, and recommendation's outlining the best method for avoiding these inconsistencies going forward were presented. C h ap t e r I
INTRODUCTION
Integrated Services Digital Network (ISDN) is an architecture envisioned in the late 1970's as the successor to the conventional narrow band analog public telephone network. ISDN was
"squeeze" intended to more capabilities from the embedded base of metallic twisted pair telephone cable. Conventional analog telephone services use a single 3000-Hertz channel to carry information (voice) as well as the signaling required to establish and tear down the connection (fig. 1-1).
Class 5 Station Switching Tl (tip) System L I N Twisted Pair (300 to 3 300 Hz) E
I Rl (ring) N T E R F A C E
Figure 1-1. Typical Analog Telecommunications Network
The signaling mechanisms, or protocols used for this are extremely simple and date back to the
19th late century. These include completing and breaking a current loop to initiate and tear down a connection (Table 1-1). Signaling Type Signaling Method Purpose Loop Start complete current loop, convey On/Off hook status
TltoRl leads -typical 20 milli-amp circuit
Ground Start momentary ground on Tl convey On/Off hook status lead
Reverse Battery momentary DC polarity convey On/Off hook status reversal Tl, Rl leads
Pulse momentary break in convey dialed digits from current loop Tl to Rl station to line interface in leads class 5 switching system
Dual Tone Multi combinations oftones convey dialed digits from Frequency between 350 hz and 1633 station to class 5 switching
hz system - and call progress (i.e. dial tone, busy) from class 5 switching system to station
Table 1-1. Signaling in an Analog Telecommunications Network
ISDN, on the other hand, is a network architecture that uses a digital transport mechanism, and packet signaling system to invoke sophisticated circuit and packet switched services. Calls are set up, and torn down over a separate packet channel which rides on a digital transport
channels" data stream containing separate "bearer used for information transport. Since ISDN involves a digital transport, this technology can be used to carry digitized voice, video, data of other mixed signals efficiently over the conventional Public Switched Telephone Network
(PSTN). ISDN can be implemented in nearly every major metropolitan area in North America.
It is cost effective because it can utilize the network infrastructure, which currently exists for
mile" provides a method to extend the digital PSTN the analog services. ISDN "last to the end user.
From a protocol prospective, ISDN is a digital architecture, which uses a three-layer protocol stack, roughly mapping to the Open Systems Interconnect (OSI) reference model's
[19]. physical, data link, and network layers (fig. 1-2) Application
Presentation
Session
Transport
Network Q.931& T1.607& TR-NWT- ATT NTT * Q.932 T1.608 001268 > "*
Data Link Q.920 & T1.602 TR-TSY-000793 * Q.921 >
Physical 1.421 T1.403& * & T1.408 1.431
OSI Reference ITU ANSI BELLCORE PROPRIETARY Model
Figure 1-2. OSI Reference Model and ISDN Protocol Stacks
Basic rate ISDN uses a two (2)-wire transport layer, and provides 2 digital circuit switched
B" D" "bearer or channels for information transport, and 1 packet switched "data or channel, which is used to set up and tear down connections on the bearer channels. Primary rate ISDN
employs the same protocol structure as basic rate ISDN, but uses a 1.544 Mb/s digital transport mechanism to provide a greater quantity of B channels (fig. 1-3).
Four (4) Wire Digital ANSI Tl.403 Compliant ^Channels
D- Channel
Transmission Facility
Channel Transmission Rate Quantity
B Channel - 64Kb/s 23
D Channel - 64Kb/s 1
Figure 1-3. Primary Rate ISDN Channel Mapping Primary rate ISDN is the delivery of ISDN services using physical, link, and network layer protocols established by American National Standards Institute (ANSI), Bell Communications
Research (Bellcore, now Telcordia Technology) and the Consultative Committee on
International Telephone and Telegraph (CCITT, also referred to as the International
Telecommunications Union, Telecommunications Committee ITU-T). These physical and
data link layer standards have been in existence in North America for several decades, and are
universally implemented in a number of protocol stacks besides ISDN.
The standards for protocols at the network layer of ISDN are used to define the call set up,
progress, and tear down for voice and data connections over the public switched telephone
network (PSTN). ISDN development in North America evolved through a succession of
adaptations of the ITU-T Q.931 network layer protocol. Mismatches at the network layer due
to incorrect implementations between user equipment and network will be service impacting.
ITU-T's Q.931 network layer protocol was adapted in North America by the major
equipment manufactures and deployed as part of semi proprietary protocol implementations
of ISDN (fig. 1-2). Two variants of Q.931 became predominant. The first was developed by
American Telephone and Telegraph, (A.T.&T., now Lucent Technologies) and is commonly
known as 5ESS custom [1]. This adaptation was implemented on Lucent's class 5 Electronic
Switching Systems (5ESS) and was intended to interface with Lucent provided user equipment.
The other was developed by the Canadian equipment manufacturer, Northern Telecom (now
Nortel Networks) and is commonly known as DMS. This adaptation was implemented on
Nortel's DMS family of class 4 and class 5 switching systems and was intended to interface with Nortel's private branch exchange (PBX) equipment.
These adaptations at the network layer allow for proprietary implementations or feature
enhancements outside what was defined in Q.931. The equipment manufactures, by modifying
a standard network layer protocol, were able to integrate existing equipment families into
ISDN networks at a much lower cost and fostered the deployment of ISDN in North
America. This strategy accelerated the acceptance of ISDN, and allowed for a more seamless
transition from non-ISDN traditional switched services. coupling" The major drawback was that a "close between the network and user equipment at the network or call control layer developed. While both Lucent Technologies and Northern
Telecom enjoyed wide spread success in marketing there own versions of ISDN, other equipment manufactures were forced to implement these semi proprietary protocol stacks, or become effectively locked out of the ISDN market. For any further user cost reduction to be realized, greater competition and choices would need to become available to end-users. The
same manufacturer specific adaptations of the ISDN network layer that created the
environment for ISDN proliferation now are restricting its advancement [20].
As a response to the need to eliminate manufacturer dependency, ISDN network standards were developed to offer alternatives to these proprietary implementations. Bellcore released
Technical References for National ISDN 1 (Nil) and National ISDN 2 (NI2). NI2 was
defined in network technical recommendation TR-NWT-001268 that was released in
December of 1991. The call control portion (network layer) of these standards is variations on
ITU-T Q.931. The intention of these standards is follow a progression away from the
proprietary implementations of 5 ESS Custom and DMS and move towards a close
implementation of ITU-T Q.931 at the network layer. The advantage is that all equipment
manufactures and network providers now have a non-proprietary protocol suite, which, when
implemented correctly, will allow for total interoperability between network services and
equipment. The major drawback now is that every manufacturer has to interpret, and
implement this protocol correctly and consistently throughout the network. Failure to
accomplish this results in interoperability problems, which can occur between the user and the
network, or between networks provided by different carriers. As the complexity of services grows, and users became more sophisticated, the subtle inconsistencies in implementation of
the ISDN network layer which not do not impact simple voice connections may in fact prevent operation of more complex connections (ISDN multi channel video for example).
When these inconsistencies begin to effect the ability for users to invoke connections, technical resources for the user, equipment manufacturers and network providers will be engaged to trouble shoot and correct these inconsistencies. There will be a cost associated with this effort and as I will demonstrate in this thesis, will be of considerable magnitude. I have extracted data from actual ISDN network issues worked by a major ISDN service provider (WorldCom) for the calendar year 2001. I analyzed this data and segmented the individual trouble reports into categories, or groups that share common traits. Each network layer issue could be categorized into one of four (4) main groups:
Group 1 - Connection Establishment
Group 2 Information Inconsistency
Group 3 - Timer Handling
Group 4 Information Mapping
Group 1 involves inconsistencies in defining the required or mandatory information required
for the establishment of connections at the network layer. These are the most common
problems and usually the easiest to correct. An example would be a user providing an incorrect
station" digit string for the required element "called in a connection request. Group 2 issues
involve supplementary information used to further define connection states, or the progress of
connections that is beyond what is mandatory to establish the connection. An example would
be a user providing invalid information for the optional parameter "calling party". Group 3
issues are associated with network layer timers. These timers are generally used to terminate
connections if predefined events do not occur. An example of this inconsistency would be
failure to recognize the Progress message sequence used to stop timer T310, and a connection
request failing due to expiry of this timer. Group 4 issues are the most infrequent, but are the
most difficult and costly to correct. These problems are caused when user-to-user specific
information must be mapped between ISDN networks and the PSTN. An example of this
type ofinconsistency would be a network switching system incorrectly mapping a data transfer
rate from the ISDN messaging into the PSTN signaling system (SS7) messaging.
By categorizing these common problems, and describing their cause and correction, one
can identify a cost associated with the various groups of ISDN interoperability issues. More
recommendations detection and importantly, going forward, for early avoidance of these problems can be made. These recommendations, if implemented by ISDN users, will reduce the occurrence or serious ISDN interoperability, and help lower the cost associated with ISDN deployment.
Chapter two provides a background of ISDN network layer evolution in North America.
The standards are identified and common implementation errors are categorized. In chapter 3
the process where inconsistencies are identified, analyzed and categorized is established, and
detailed case studies representative of over two (2) years of study will be examined. In chapter
4 an economic analysis will be developed based on the data defined in chapter 3. The overall
impact that these types of problems (technically and economically) have on the ISDN user
community is depicted in chapter 5. This final chapter will provide a summary of the case
study analysis and economic impact evaluation provided in chapters 3 and 4, with
recommendations going forward which will aid users in avoiding the network layer
implementation problems, which these cases studies identify. Chapter II
BACKGROUND
This chapter will provide a background on how ISDN network layer interoperability issues
arise, are detected, and corrected. The focus will be on business applications utilizing primary
rate ISDN services.
ISDN has gained popularity as a local transport mechanism, which can be used for both
analog and digital services. Commercial users are able to utilize primary rate ISDN to provide
one (1) medium capable of connecting analog private branch exchanges (PBX's), digital
routers and ISDN video conferencing servers to the PSTN [20]. Once connected to the
PSTN, switched connections can be made which establish point-to-point circuits for voice or
data. In effect, the PSTN can be used to provide virtual point-to-point connections nearly
anywhere in the world. This flexibility, the ability to transport mixed mode signals over one
facility makes ISDN an economical alternative to using separate non-ISDN networks to
transport these diverse services. However, along with this flexibility ISDN introduces a new
level of complexity. Both the network, and the user's equipment must accurately and
consistendy pass information and map data in accordance with the standards for the ISDN
network layer, and PSTN signaling system. When these network protocols are not
implemented correctiy, interoperability issues arise which are often complex and costiy to
correct.
Before we can analyze and categorize ISDN network layer (layer 3) implementation
inconsistencies, we should briefly review the physical and data link layers (layers 1 and 2) in
order to gat a perspective on why implementation inconsistencies at the network are so
significant
The Open Systems Interconnect (OSI) reference model can be used to show the relationships between the associated protocols, which make up the protocol stack for primary rate ISDN as it is deployed in North America. The physical layer (layer 1) for primary rate
ISDN in North America is defined by ANSI T1.403 and T1.408. ANSI T1.403 describes the telecommunications network-to-customer DS1 metallic interface (fig. 1-3), and Tl.408 describes the Customer Installation Metallic Interfaces - (Layer 1 Specification). These
standards define all of the physical and electrical properties and specifications of the digital
transport mechanism at the DS1 signal rate [14]. The physical layer accepts the protocol data
units (PDU's) from the data link layer, adds framing and line coding necessary to encapsulate
these PDU's into a digital signal which conforms to these standards. The standards also
describe various devices, which are normally used in physical layer transport (logically or
physically) and the interface points between them.
Figure II-l depicts the set of interface points, which are significant to ISDN.
Network Provided User Provided
Network NT1 NT2 TE1 Access (Switching (NIU) (PBX) (Station) System)
S/T
Interface Description Applicable Standards U Network Interface ANSI T1.403 and Tl.408
DS1 Rate -point of BELLCORE TR-NWT-001268 interface to the DS 1 transport facility
S/T User interface - DS1 Rate ANSIT1.605 demarcation point in North America between Network
and user provided equipment
Figure II-l. ISDN Physical Layer Interface Points
These points, known as the U, S/T interfaces, define signal and connection characteristics as well as ownership for devices at various points in the ISDN signal path. The deregulation of
the telecommunications industry in North America which began in the 1980's has created a
need for defining ownership as well as signal and connection requirements for the various
10 elements of the physical layer. Figure II-2 depicts a typical arrangement where multiple
equipment and service providers must interface with each other at these designated points.
ISDN Service Provider >"- User Scope Scope End-to-End ISDN
WorldCom ISDN TE1 -Lucent Service Provider Layers 2-3 Layers 2-3 I End-to-End DS1 WorldCom/Verizon Layer 1 I NT2 (PBX) Lucent Layers 1-3 I Verizon - Local NT1 (NIU) Transport Verizon S/T Layer 1 Layer 1
Provider Protocol Scope ofResponsibility Laver WorldCom Layers 2/3 Interface correctly with Users TE1 (Lucent) Layer 1 Interface correctly with Local Transport Provider (Verizon)
Verizon Layer 1 Interface correctly with service provider (WorldCom) Transport layer 1 to NT1 demarcation point Correctly interface with NT2 (Lucent)
Lucent Layer 1 Interface correctly with NT1 (Verizon) Layer 2/3 Interface correctly with ISDN Service Provider (WorldCom)
^. Logical Connection
Physical Connection -^
Figure II-2. Typical Multi-Vendor ISDN Configuration
"U" The first interface point on the physical layer is known as the interface. This point
defines the portion of the physical layer which consists of the DS1 transport from the ISDN service provider to the user. The signal, and interface properties at this interface conform to
ANSI T1.403. This signal is a 1.544 Mb/s digital, using Extended Super Frame (ESF) frame format (fig. II-3) [20], and Binary Eight Bit Zero Substitution (B8ZS) line coding (fig II-4) [20].
11 This interface point is located just prior to the Network Termination point one (NT1). The
NT1 is an active device, which has remote diagnostic capabilities to aid in trouble shooting
Extended Super Frame (2 Super Frames^ 4608 Bits UD 12 Bits EOC 6 Bits CRC
4"" 6 FB - Repeating Pattern every Frame Bit from the Super Frame (00101 1)
0 0 1
Super Frame (12 Frames) 2304 Bits UD
12 FB - Repeat Pattern (10001101110 0)
-d h
Frame = 24 PCM words 1 1 1 1 1 1 1 1 1 1 1 1 1 II 1 1 1 1 1 1 1 1 1 1 192BitsUD FB 1FB
PCM Word 8 Bits UD
FB = Framing Bit UD = User Difta CRC = Cyclic Redtindan;yCheck EOC = Embeiided()pera ions riianrlei PCM = Pulse Code Modi latioil
Figure II-3. Extended Super Frame Format - DS1 Signaling
layer 1 problems. This device can also provide signal regeneration and impedance matching for
four- interface. The NT1 is used to terminate the DS1 wire the circuitry beyond the (4) loop
to interface with user equipment. into a modular jack (typically an RJ-45 modular jack) [14]
the NT1 is owned and maintained the This portion ofthe physical layer up to and including by
transport provider utilized by the ISDN service provider.
12 Max Consecutive Zeros - Non B8ZS (7) Signal Level +
Bit Value 10000001001001000
Consecutive Zeros Greater than 7 - B8ZS
Bipolar Bipolar Signal Violation Violation Level +
Bit Value 1000000000 1001000
Figure IT-4. Binary Eight Bit Zero Suppression Line Coding - DS1 Signaling
"S/T" The second interface point, and the first which involves user provided equipment is
"U" interface. Electrically, and physically, this interface is very similar to the interface. The
signal and connection requirements are governed by ANSI T1.605 and the device, which
corresponds to this point, the network termination point two (NT2). This interface point is
user provided equipment and is the point where layer 1 terminates. While the NT1 is owned
and maintained by the transport provider for the DS1 line, the NT2 is owned and maintained
by the user [21]. Figure II-2 depicts a typical arrangement
The multi vendor environment, which was spawned by deregulation, has created some
procedural and administrative challenges for DS1 transport's physical layer. Ordering, and
maintenance for the physical connections required to transport ISDN primary rate service may
require several discrete entities. The example provided in figure II-2 is a fairly typical
configuration, which offers some administrative challenges to the user particularly when the
physical layer breaks down. Fortunately, the standards, which define layer one, have been in
existence in one form or another for nearly twenty five (25) years. The technology is proven, reliable and the delivery of DSl's for various customer applications including ISDN has
13 become fairly commonplace. Because of this, implementation inconsistencies at this layer are
not very common.
Again, referring to the OSI reference model the data link layer (layer 2) for primary rate
TR-TSY- ISDN in North America is defined by two standards. ANSI T1.602 and Bellcore
000793. These protocols define the standard for ISDN data link layer signaling for application
at the user-network interface (fig 1-3). The data link layer standard defines the procedures for
link" communicating across "the and is referred to as the link access procedure for the D
channel, or LAP-D. The function of LAP-D is to control procedures for error detection, and
correction of abnormalities detected on the physical layer (layer 1). LAP-D was based on the
high-level data link control (HDLC) [20] protocol set established by the International
Standards Organization (ISO). This bit oriented protocol places control information in the
"bit" same position within the frame, and relies on discrete patterns to convey this
information. LAP-D is capable of providing levels of multiplexing within each frame, which
can be used to direct commands and responses to a particular user device, or a particular data
type. This makes this protocol ideal for dealing with ISDN's multiple user devices and data
types which can exist at the same user interface. LAP-D incorporates a unique two (2)-part
address consisting of a terminal endpoint identifier (TEI) and a service access point identifier
(SAPI) to care for this requirement (Table II-l). These two parameters combine to form the
data link connection identifier (DLCI) [20]. LAP-D includes functions for:
Value Description SAPI=0 Call Control Procedure SAPI=1 Packet Mode using Q.93 1 Call Control Procedure SAPI=16 Packet Communications Conforming to X.25 Procedure SAPI=32-62 Frame Relay SAPI=63 Layer 2 Management Procedures
rm=o Primary Rate Interface rEI=l-63 Non-automatic TEI Assignment rm=64-i26 Automatic TEI Assignment rm=i27 TEI Management
Table II-l. Common SAPI and TEI Address's
"D" A) The provision for more than one data link connection for a user interface. A
unique DLCI value contained in each frame is used to accommodate this.
14 B) Frame delimitating, alignment and transparency, which allows transmission of a
sequence ofbits to be interpreted as a frame.
C) Sequence control to maintain the sequential order of frames transmitted across the data link.
D) Recovery from detected data link errors.
E) Notification of unrecoverable errors.
F) Flow control.
The basis for all layer 2 communication is the exchange of information contained in frames.
There are three types of frames, which are supported by ANSII T1.602 and Bellcore TR-TSY-
000793. These are the information (I) frames, Supervisory (S) frames, and unnumbered (U) frames. These frames are used to convey all the necessary information required to establish the link, communicate across the link, disconnect the link, and restart the link in the event of a failure at either layer 1 or 2. Each of these frame types will be discussed in some detail.
"0" The Information or I frame is distinguished by the presence of the value in bit position
lofoctet4(fig.II-5)[16,22].
Bits Octet 5 4 3
1 0 111111 0
2 SAPI c/r 0
TEI 1 3
N(S) 0 4
N(R) p 5
Information
Frame Check Sequence n-2,n-l
0 1 11111 0
N (S) is the sequence number ofthe frame being sent. N(R) is the sequence number ofthe next I frame expected. P-bit is a request for an acknowledgement. Figure H-5. The I Frame for the Data Link Layer
15 This frame is used to transfer network layer information, which is encapsulated in the information octets. The other fields are used for addressing to indicate polling, to indicate command or response, and to convey the number ofthe frame assigned by the transmitter and the number of the frame next expected.
"1" The Unnumbered (U) frame is identified by the presence of the value at bit positions 1 and 2 of octet 4 (fig. II-6) [16,22]. These frames, and the Unnumbered Information (UI) sub type are used to encapsulate network (layer 3) information. Examples of U frames are depicted in Table II-2.
Bits Octet 6 5 4 3 2
0 1 1 1 1 1 1 0 1
SAPI c/r 0 2
TEI 1 3
M M M p/f M M 1 1 4
Information
Frame Check Sequent:e n-2,n-l
0 1 1 1 1 1 1 0
p/fis poll final bit
M bits are used to indicate a subsequent layer 3 message
Figure DI-6. The U Frame for the Data Link Layer
- 1) SABME - Set Asynchronous Balanced Mode Extended Used to initiate link 2) DISC - Disconnect - used to disconnect the link
- 3) UA - Unnumbered Acknowledgement Affirmative response to a SABME and/or DISC. 4) - Disconnect Mode - negative response to a SABME
- 5) UI - Unnumbered Information Used when delivering non-sequenced information frames. 6) FRMR - Frame Reject - Response to unrecoverable link layer errors.
Table II-2. Examples ofU Frames
"0" The Supervisory (S) frame is distinguished by the presence of the value in bit 2, and the
"1" [16,22]. These frames are used to signal receipt of an value of in bit 1 of octet 4 (fig. II-7)
acknowledgement of I to poll the other side of out-of-sequence frame, to provide frames, the
are in interface, and to respond to polls. Examples of S frames depicted Table II-3.
16 Bits Octet 6 5 4 3 2
0 1 1 1 1 1 1 0 1
SAPI c/r 0 2
TEI 1 3
X X X X S S 0 1 4
N(R) 5
Frame Check Sequence 6/7
0 1 1 1 1 1 1 0 8
Figure D-7. The S Frame for the Data Link Layer
- 1) RR Receiver Ready - The transmitter ofthis frame indicates the ability to receive additional information frames starting with N(R) xxx. This frame also can be used to clear a previous receiver not ready condition.
- 2) RNR Receiver Not Ready - The transmitter ofthis frame indicates a busy condition and the inability to receive additional information frames. a. N(R) xxx in this frame indicates the next expected N (S) number once the busy condition has been cleared b. Indication of severe buffer congestion
- 3) REJ-Reject Used for Automatic Retransmission Request (ARQ). Retransmission should commence starting with frame N(R) xxx.
Table II-3. Examples of S Frames
A typical link establishment procedure can by initiated by the network or the user
equipment. In the example provided in fig. II-8, the network has initiated link establishment by
sending an unnumbered (U) Set Asynchronous Balanced Mode Extended (SABME) frame to the user.
17 SPCS Class II Network User
SABME
I N(S)=0,N(R)=0
RRN(R)=1
IN(S)=1,N(R)=0
I N(S)=2,N(R)=0
RRN(R>
Figure II-8. Procedure for I frame Acknowledgement Using RR Frames
The user equipment would respond to this frame with an unnumbered acknowledgement
"ready" (UA) frame. This two (2)-message sequence establishes the link as to begin transferring (I) frames. Subsequentiy, this process continues with the network issuing an
Information (I) frame with the sequence number being sent, N (S) and the sequence number expected in the next I frame, N(R) both equal to 0. The user equipment will respond with a supervisory (S) Receiver Ready (RR) frame with N(R) = 1 indicating that the user equipment is expecting a subsequent information (I) frame with sequence number = 1. The network is
18 shown responding to the users RR with a subsequent information (I) frame(s) with N (S) values incrementing to corresponded to the N(R) value sent by the user in the previous RR
frame. The user will respond to the network I frames, each time incrementing the value of the
N(R) field to keep track of the I frame sequence. This process will continue with I and RR
frames being exchanged in intervals compliant with layer 2 timer T-200, which is typically set
to 1 sec [16,22].
ANSI Tl. 602 and Bellcore TR-TSY-000793 define bit oriented data link protocols, which
are based on OSI's HDLC. FLDLC is a well established, and proven data link protocol.
Inconsistencies in implementation of layer 2 protocols are rare, but more common than at
layer 1. Usually, when inconsistencies at this layer occur, they prevent link establishment, or
link switch over in the event that multiple data link (D) channels are present at the interface.
Interoperability issues at layer 2 will prevent any higher layer (3 and above) from establishing,
and therefore normally prevent any useful communication across the interface from occurring.
By comparison to the data link layer, implementation errors at the network layer (layer 3)
often go undetected. The network layer is the layer, which is used to invoke network layer
services, and depending on the complexity of the service, slight errors in implementation of
the standards at this layer may never become service impacting. Or, as is often the case, will
up" "crop long after the initial installation and activation of the ISDN service has been
completed when some new application or service is invoked. Information provided at this
layer is directiy mapped into the PSTN signaling network. This mapping will determine unique
connection types, transport rates, and access transport parameters, which are not normally
used by non-ISDN services. This requires a great deal of interoperability that does not
normally take place in the PSTN. Because of this, there is a much greater risk of problems
these specialized transport. It is these arising due the network elements misinterpreting
instances when the trouble becomes most difficult, and costly to analyze and correct.
The network layer for ISDN in North America are defined by ANSI and Bellcore standards
standard Q.931. ANSI the which both are closely related to ITU-T T1.607 is layer 3 signaling
specification for circuit-switched bearer services and T1.608 is the specification for X.25
packet-switched bearer service. These protocol standards correlate with ITU-T standards
Q.931 [17] and Q.932 [15] respectively. The Bellcore standard, TR-NWT-001268 corresponds
19 to ANSI T1.607, and ITU-T Q.931. This layer is used to establish user-to-user switched circuit and switched packet connections. It is this protocol layer, which performs the connection set up, progress and tear down. Some of the key functions of this layer are:
A) Process the primitives for communication with the data link layer.
B) Generation and interpretation of layer 3 messages for peer to peer communication.
C) Administration of timers and logical entities (i.e. call reference values) used in
connection control.
D) Access resource administration for circuit and packet switched connections.
E) Network connection control.
F) Conveying user-to-network and network-to-user information.
G) Segmentation and reassembly.
H) Error detection.
I) Error recovery.
J) Set message sequence.
K) Congestion control and user data flow control.
L) Restart
All of these functions are conveyed to layer 2, where they are encapsulated into layer 2 frames and passed to layer 1 for transport. Table II-4 depicts fifteen (15) layer 3 messages as identified in ANSI T1.607, Bellcore TR-NWT-001268 and ITU-T Q.931.
20 ALERTING: This message is sent by the called user to the network and by the network to the calling user to indicate that the called user alerting has been initiated CALL PROCEEDING: This message is sent by the called user to the network and by the network to the calling user. In the network to user direction, it indicates that the requested call establishment has been initiated and that no more information will be accepted. CONGESTION CONTROL: This message is sent by the user or the network to indicate the establishment or termination of flow control on the transmission of user information messages. CONNECT: This message is sent by the called user to the network and by the network to the calling user to indicate call acceptance by the called user. CONNECT ACKNOWLEDGE: This message is sent by the network to the called user to indicate that the user has been awarded the call. It may also be sent by the calling user to the network to allow symmetrical call control procedures. DISCONNECT: This message is sent by the user to request the network to clear an end-to-end connection, or is sent by the network to indicate that the end-to-end connection is cleared. FACILITY: This message is now described in Q.932. INFORMATION: This message is sent by the user to the network to provide additional information. If may be used to provide information for call establishment or miscellaneous call-related information. NOTIFY: This message is sent by the user or the network to indicate information pertaining to a call, such as user suspend. PROGRESS: This message is sent by the user or by the network to indicate the progress of a call in the event of interworking or in the relation to the provision of in-band information or patterns. RELEASE: This message is sent by the user or by the network to indicate that the equipment sending the message has disconnected the channel (if any) and intends to release the channel and the call reference and that the receiving equipment should release the channel and prepare to release the call reference after sending a RELEASE COMPLETE message. The meaning may be modified in the context of supplementary services (e.g. conferencing). RELEASE COMPLETE: This message is sent by the user or by the network to indicate that the equipment sending the message has released the channel (if any) and call reference, the channel is available for reuse, and the receiving equipment will release the call reference. RESUME: This message is sent by the user to request the network to resume a suspended call. RESUME ACKNOWLEDGE: This message is sent by the network to the user to indicate completion of a request to resume a suspended call. RESUME REJECT: This message is sent by the network to the user to indicate failure of a request to resume a suspended call. SETUP: This key message is sent by the calling user to the network and by the network to the called user to initiate call establishment. SETUP ACKNOWLEDGE: This message is sent by the network to the calling user to indicate that call establishment has been initiated, but that additional information may be required. STATUS: This message is sent by the user or by the network in response to a STATUS INQUERY message or at any time during the call to report certain error conditions. STATUS INQUIRY: This message is sent by the user or by the network at any time to solicit a STATUS message from the peer layer 3 entity (Sending a status message in response to a status inquiry message is mandatory). SUSPEND: This message is sent by the user to request the network to suspend the call. SUSPEND ACKNOWLEDGE: This message is sent by the network to the user to indicate completion of a request to suspend a call. SUSPEND REJECT: This message is sent by the network to the user to indicate failure of a request to suspend a call. USER INFORMATION: This message is sent by the user to the network to transfer information to the user deliver information remote user. This message is also sent by the network to the to from another user. This message is used ifthe user-to-user transfer is part ofthe allowed information transfer.
Table II-4. ISDN Call Control (Layer 3) Messages
21 These messages are commonly used in the establishment, progress and termination of connections.
Every layer 3 message must contain the following information:
A) The protocol discriminator. This is used to distinguish messages intended for user-
to-network call control from other messages.
B) The call reference. This is a unique value, which is used to identify the call or facility
registration-cancellation request at the local user-network interface to which the
particular message applies.
C) The message type. The purpose of this field is to identify the purpose and
subsequent structure ofthe message.
D) Other information elements. These information elements are dependant on the
message type, and can be used to convey a multitude of supplementary information.
Figure II-9 depicts the general message format for all layer 3 messages.
Bits Octet 8 7 6 5 4 3 2 1
PROTOCOL DESCRIMINATOR 1
0 0 0 0 length ofcall reference 2
1/0 CALL REFERENCE 3
MESSAGE TYPE 0 4
OTHER INFORMATION AS REQUIRED 5 and higher
Figure II-9. General Message Format - Layer 3
The first field, the protocol discriminator is a single octet, which is used to determine what
4* type of message will follow. When this field is set to a value of 08 Hex (setting the bit in the position to 1) the following layer 3 message will be interpreted as a user-network call control
1st 2nd message. If this field is set to a value of 03 Hex (bits in the and position are set to 1), the
22 following layer 3 message will be interpreted as a maintenance message. Other values for the protocol discriminator are reserved for escape sequences and future uses [17,18].
The call reference value field consists of multiple octets and is used to identify the call at the local network-user interface to which this particular message applies (fig 11-10).
Bits Octet 8 7 6 5 4 3 2 1
0 0 0 0 length of call reference
1/0 CALL REFERENCE
CALL REFERENCE 4 etc.
Figure 11-10. The Call Reference
The first octet contains the length of the call reference value (in octets). Example, a length of
01 Hex would indicate a call reference value, which consists of one (1) octet, and would be contained in the subsequent octet of the message. A length of 02 Hex indicates that the next two (2) octets are used to make up the call reference value etc. The value itself consists of a flag (in bit position 8) and 7 bits (bits 1-7), which make up the call reference value. A value of
"0" "1" for the flag indicates the message is from the origination interface, is used for the termination interface [17,18].
The third component of the layer 3 message is a one-octet field, which is used to determine the message type. ANSI T1.607, Bellcore TR-NWT-001268 and ITU-T Q.931 define some fifteen (15) message types (Table II-4). These are used to perform connection establishment, call information, and call clearing and information.
23 BITS HEX MESSAGE GROUP 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 01H ALERTING Call Establishment 0 0 0 0 0 0 1 0 02H CALL PROCEEDING 0 0 0 0 0 0 1 1 03H PROGRESS 0 0 0 0 0 1 0 1 05H SETUP 0 0 0 0 0 1 1 1 07H CONNECT 0 0 0 0 1 1 0 1 ODH SETUP ACK. 0 0 0 0 1 1 1 1 OFH CONNECT ACK.
0 0 1 0 0 0 0 0 20H USERINFORMATIO Call Information 0 0 1 0 0 0 0 0 21H SUSPEND REJECT 0 0 1 0 0 0 0 0 22H RESUME REJECT 0 0 1 0 0 0 0 0 24H HOLD 0 0 1 0 0 0 0 0 25H SUSPEND 0 0 1 0 0 0 0 0 26H RESUME 0 0 1 0 0 0 0 0 28H HOLD ACK. 0 0 1 0 0 0 0 0 2DH SUSPEND ACK. 0 0 1 0 0 0 0 0 2EH RESUME ACK. 0 0 1 0 0 0 0 0 30H HOLD REJECT 0 0 1 0 0 0 0 0 31H RETRIEVE 0 0 1 0 0 0 0 0 33H RETRIEVE ACK 0 0 1 0 0 0 0 0 37H RETRIEVE REJECT
0 1 0 0 0 1 0 1 45H DISCONNECT Call Clearing 0 1 0 0 0 1 1 0 46H RESTART 0 1 0 0 1 1 0 1 4DH RELEASE 0 1 0 0 1 1 1 0 4EH RESTART ACK. 0 1 0 1 1 0 1 0 5AH RELEASE COMPLETT
0 1 1 0 0 0 0 0 60H SEGMENT Miscellaneous 0 1 1 0 0 0 1 0 62H FACILITY 0 1 1 0 0 1 0 0 64H REGISTER 0 1 1 0 1 1 1 0 6EH NOTIFY 0 1 1 1 0 1 0 1 75H STATUS INQUERY
Table II-5. Message Types / Values
"other" The fourth and final component of the layer 3 message is the information elements. There are a number of these information elements and there use is specific to the type of message it is being used with (Table II-6). These information elements are used to convey specific information such as data rate, call types, numbering plans and numbers called.
24 BITS HEX INFORMATION ELEMENT TYPE 8 7 6 5 4 3 2 1
1 0 0 0 - - - - 8xH RESERVED Single Octet Information
1 0 0 1 - - - - 9xH SHIFT Elements 1 0 1 0 0 0 0 0 AOH MORE DATA 1 0 1 0 0 0 0 1 A1H SENDING COMPLETE
1 0 1 1 - - - - BxH CONGESTION LEVEL
1 1 0 1 - - - - DxH REPEAT INDICATOR
0 0 0 0 0 0 0 0 00H SEGMENTED MESSAGE Variable Length Informa 0 0 0 0 0 1 0 0 04H BEARER CAPABILITY Elements 0 0 0 0 1 0 0 0 08H CAUSE 0 0 0 0 1 0 1 0 10H CALL IDENTITY 0 0 0 1 0 1 0 0 14H CALL STATE 0 0 0 1 1 0 0 0 18H CHANNEL ID. 0 0 0 1 1 1 0 0 1CH FACILITY 0 0 0 1 1 1 1 0 1EH PROGRESS IND. 0 0 1 0 0 0 0 0 20H NET. SPEC. FAC 0 0 1 0 0 1 1 1 27H NOTIFICATION IND. 0 0 1 0 1 0 0 0 28H DISPLAY 0 0 1 0 1 0 0 1 29H DATE/TIME 0 0 1 0 1 1 0 0 2CH KEYPAD FACILITY 0 0 1 1 0 1 1 0 32H INFO. REQUEST 0 0 1 1 0 1 0 0 34H SIGNAL 0 0 1 1 0 1 1 0 36H SWITCHHOOK 0 0 1 1 1 0 0 0 38H FEATURE ACT. 0 0 1 1 1 0 0 1 39H FEATURE IND. 0 0 1 1 1 0 1 0 3AH SERVICE PROFILE 0 0 1 1 1 0 1 1 3BH ENDPOINT ID. 0 1 0 0 0 0 0 0 40H INFORMATION RATE 0 1 0 0 0 0 1 0 42H END-TO-END TRANSIT DEL. 0 1 0 0 0 0 1 1 43H TRANSIT DELAY SEL.-IND. 0 1 0 0 0 1 0 0 44H PACKET LAYER BIN. PARMS 0 1 0 0 0 1 0 1 45H PACKET LAYER WIN. SIZE 0 1 0 0 0 1 1 0 46H PACKET SIZE 0 1 0 0 0 1 1 1 47H MIN. THROUGHPUT CLASS 0 1 0 1 1 0 0 6CH CALLING PARTY NUMBER 0 1 0 1 1 0 1 6DH CALLING PARTY SUB. ADD 0 1 0 0 0 0 70H CALLED PARTY NUMBER 0 1 0 0 0 1 71H CALLED PARTY SUB. ADD 0 1 0 1 0 0 74H REDIRECTING NUMBER 0 1 1 0 0 0 78H TRANST NETWORK SELECT 0 1 1 0 0 1 79H RESTART IND. 0 1 1 1 0 0 7CH LOW LAYER COMP. 0 1 1 1 0 1 7DH HIGH LAYER COMP. 0 1 1 1 1 0 7EH USER-USER 0 1 1 1 1 1 7FH ESCAPE FOR EXTENSION OTHER VALUES RESERVED
Table II-6. Information Element Identifiers
25 In order for ISDN connections to take place, the information provided in the ANSI Bellcore T1.607, TR-NWT-001268 or ITU-T Q.931 messages must be correctly interpreted by
all the user and network equipment in the connection path (fig 11-11) [24].
1a. tM* /j* 2A. ACM
STP - Signal Transfer Point (Packet Switch)
SSP - Signal Switching Point (Class 5 End Office)
Figure 11-11. Messages Passed via PSTN Signaling System [23]
Initially, the serving local network switch must correctiy interpret the users call establishment messages. This switch then must map positions of the ISDN network call establishment messages into the ISDN User Part (ISUP) of the PSTN signaling system in order to set up the connections within the PSTN (fig 11-12) [24]. These connections often are transported by numerous carriers (local and long distance). The terminating end local switching network must then correcdy decode the ISUP messages, and map them into ISDN call establishment an progress messages for the terminating end user equipment Any incorrect interpretation of a message associated with call initiation or call progress can cause the connection to fail.
26 ANSI ISUP Message ITU-T ISUP Message fixation Octet 0 0 *l|ipfcOft Octet f \ Subservtoe Field Service Indicator Subservice Fie Id Service indicator DPC Member DPC LowOrder Octet e DPC Cluster Routing DPC HighOrder 6-bits DPC Netwrk Label Orders \ l OP C Middle-Order Octet OP C Member
__ *;: 4-bit OP C High-Order OP C Cluster StS/StC 4-to its 5 CIC LowOrder Octet OP C Network t 4-bits spare CIC High-Order 4-bits Li** Sefection \ ;-^3nali"n9 ?N spare : : \^N ;;;.; , \ Message Type \ CIC LowOrder Octet
2-bts CIC High-Order 6-bits spare Interpretation Varies Message Type According to Message Type Value 11 Interpretation Varies According to Message Type Value
The mandatory fixed part may be followed by the mandatory variable part and/or the optional part. The mandatory variable part contains mandatory variable-length parameters. The optional part contains optional parameters which are identified by a one-octet parameter code followed by a length indicator ("octets to follow") field. Optional parameters may occur in any order. If optional parameters are included, the end of the optional parameters is indicated by an octet containing all zeros.
Figure 11-12. SS7 Signaling ISUP Protocol Stack [23]
27 A typical message flow diagram for an ISDN call is provided in figure 11-13.
Q.931 SS7 Signaling ISDN User Part (ISUP) Q.931 TIME Limit
3 4 1 TX 1 1 rx IAM IAM SETUP i w to 4 sec. typ
tl CALLPROC CALL PROC
10 sec. typ.
10 9 8
* 1 t2 ALERT ACM ACM ALERT \ 14 15 " 11 1 1 min. typ.
* 1 ,..1.
CONN ANM ANM CONN
12
CONN AC*
NT2 NT2 Calling Called
ABBREVIATIONS
OX: Originating Exchange (Serving ISDN Switch) TX: Transit Exchange (Tandem ISDN Switch) DX: Destination Exchange (Terminating ISDN Switch) SETUP: Setup Message CALL PROC: Call Proceeding Message ALERT: Alerting Message CONN: Connect Message CONN ACK: Connect Acknowledge Message IAM: Initial Address Message ACM: Address Complete Message ANM: Answer Message: NT2: Network termination 2 (PBX)
Figure 11-13. Message Flow for Call Establishment
A user (NT2) sends an ISDN setup message to the originating exchange. This network switch must correcdy interpret this setup message and create an ISUP initial address message (IAM).
If the setup message is valid, an ISDN call proceeding message will be returned to the
28 originating user satisfying layer 3 timer T310 [18] in the users equipment and the IAM (fig, II-
14) [24] is launched into the PSTN signaling network.
Initial Address Message
"forward" An Initial Address Message is sent (IAM) in the direction by each switch needed to complete the circuit between the calling and called the party party until circuit connects to the destination switch. An IAM contains the called party number in the mandatory variable part and may contain the calling party name and number in the optional part. ANSI Initial Address Message (IAM) ITU-T Initial Address Message (IAM)
o 1 f : SIO and Routing Label SIO and Routing Label > ft CIC LowOrderOctet OC Low-OrderOctet 2-bits CIC High-Order 8-btts spare 4-ftfls spare CIC High-Order 4-bits
.10 Sfesssgefype lvalue = 1 Si Message Type value = 1 ! ;:NS&s.#Ci)Wfi3fiIndicators Wafer* ofC'jnnection IrwSvtiori
Forward Can Indicators bits H . A Mandatory Forward Call Indicators bits H. A Fixed Forward Call Indicators bits P.J Part FohAjardCall Indicators bits P. Mandatory Fixed ,14 \ Calling Patty Category % i Catstig Partycategory Part ^ jOffset ot 1st Mandatory Var. Parameter value 3 % Transmission Medium Hiel -7 : : H3 |^ Offset of 2nd MandatoryVar.Parameter Offset of Mandatory Var. Parameter value = 2 ' value = 0 it value = 0 if Offset ofStel of OfitJon# J* t no opt. part no opt. part _ Length Indicator of Called Party No. MscdaUsy UserService Information Called Party Number Vartssie Mandatory of octets = Length Indicator value t ofoctets = Length Indicator value Pan Vapafcle
Psrt sequence Lengthtnciisstorsif:Called partyno. Optomi Parameter Cc de V may CsiadPatty Number l Optional Parameter Lengthindicator repeat # ofoctets = Length Indicator value Ni OpfioftatParameter Option!
': sequence - "OpSr>noj Parameter Code v \ pot octet* Length iricfcaforyifoe *> may repeat \V Optional Parameter Length Indicator \j End of Optional Parameters indicator value =0
optional P*>8e1r Osfensl
= v ; # ofoctats ten^h Indicator value l-'aHl
\ j End of Oftftonat Parameters Indicator value = 0
Figure 11-14. ANSI and ITU-T Initial Address Message (IAM) Format [23]
The packet-signaling network will relay the IAM through any number of transit or tandem exchanges to the destination exchange. This network switch must then convert the information resident in the IAM into an ISDN setup message to be sent to the called party.
and if correct will The called party equipment will interpret the setup message, it is send an
ISDN Call Proceeding Message to the destination network switch, again satisfying layer 3
"ringing" timer T310 in the destination switch. The terminating users equipment will begin the called station, and send an ISDN Alerting Message to notify the network of this event. This
will cause the destination network alerting message, if it is formatted correctiy, switch to
29 launch an ISUP Address Complete Message (ACM). The ACM message (fig 11-15) [24] will be relayed through the transit tandem switches to the originating exchange, where an Alerting
Message to be sent to the calling user.
Address Complete Message
"backward" An Address Complete Message (ACM) is sent in the direction to indicate that the remote end ofa trunk circuit has been reserved. The originating switch responds to an ACM message by connecting the calling party's line to the trunk to complete the voice circuit from the calling party to the called party. The originating switch also sends a ringing tone to the calling party's line. ANSI Address Complete Message (ACM) ITU-T Address Complete Message (ACM)
o 1 r f : f SIO and Routing Label SIO and Routing Label X s 8 v e CIC LowOrder Octet CIC Low-Order Octet 1 9 C 2-bits CIC High-Order 6-bits 4-bltSSpare CIC High-Order 4-brts \ spare 101 ~~ Message Tw \ value = 6 I Message Iype value = 6 11 \J BackvwdCalllndicatorsbitsH..A Mandatory Backward Call IndicatorsbitsH.A Mandatory Fixed Fisjed STBackward C all Indicators bits P . I Part Backvrd Call Indicators bits P .1 Part Mandator. ' Mandatory " ;C ; Offsetto Startof Optional Part Offset to Start ofOptional Part c ariatee Part Variable Part Optional p ammeter Code sequence Optional ParameterCode sequence may may Optional parameter Len0ri Indicator repeat Optional ParameterLength Imfcalor repeat
Optional Parameter Optional patsraeter Optional! Optional $ of octets Length Indicator value # ot octets Length Indicator value PlSlti Pari
End ofOptional Parameterslndicator value = 0 \ End ot Opttonat Parameters Indicator value = 0
* * value = 0 if no optional part value = 0 it no optional part
Figure 11-15. ANSI and ITU-T Address Complete Message (ACM) Format [23]
When the called party answers, this will generate an ISDN Connect Message to the destination network switch, which will acknowledge this by returning an ISDN connect acknowledge message to the called user. The destination network switch will launch an ISUP Answer
Message (ANM). This ANM (fig 11-16) [24] will be relayed to the originating network switch, which will cause an ISDN Connect Message to be sent to the originating user. At this time, a
64Kb/s circuit switched channel connection will exist between the originating and terminating users.
30 Answer Message When the called party answers, the destination switch terminates the ringing tone and sends an Answer Message (ANM) to the switch. The switch originating originating initiates billing after verifying that the calling party's line is connected to the reserved trunk. ANSI Answer Message (ANM) ITU-T Answer Message (ANM)
Optional Pammeter Optional Parameter Ootionsl # ofoctets Iength indicator value # of octets L engtft Indicator value Port
InstofOptional ParametersIndicator value = 0 \ | End ot Optional Parameters Indicator -value = 0
* * value = 0 if no optional part value = 0 if no optional part
Figure 11-16. ANSI and ITU-T Answer Message (ANM) Format [23]
The disconnecting mechanism required to tear down this connection is described in figure II-
17. The originating user (NT2) issues an ISDN Disconnect Message (DISC) to the originating network switch. If this message is formatted correctiy, the network switch will respond to this
DISC message with an ISDN Release Message (REL), and launch an ISUP Release Message
(REL) into the PSTN signaling network.
31 Q.931 SS7 Signaling ISDN User Part (ISUP) Q.931 Time
TX DX h 1 1 S 30 sec. max
4 sec. typ.
\~ REL DISC
i >w 1
30 sec. max t4 6 1 S'> I ^ 1 4 sec. typ. RLC RLC
NT2 NT2 Calling Called ABBREVIATIONS
OX: Originating Exchange (Serving ISDN Switch) TX: Transit Exchange (Tandem ISDN Switch) DX: Destination Exchange (Terminating ISDN Switch) DISC: Disconnect Message REL: Release Message RLC: Release Complete Message NT2: Network Termination 2 (PBX)
Figure 11-17. Message Flow for Call Tear Down
This ISUP REL message (fig. 11-18) [24] will be relayed through the signaling network to the destination exchange switch, which will send the terminating user (NT2) an ISDN DISC message. The terminating end NT2 will answer this DISC message with an ISDN release message (REL). If this REL message is formatted correcdy, the destination end network switch will reply with an ISDN release complete message (RLC) and launch an ISUP release complete (RLC) into the signaling network.
32 Release Message A Release Message is sent in either direction (REL) indicating that the circuit is being released due to the cause indicator specified. up" An REL is sent when either the or = calling called party "hangs the call (cause 1 6). An REL is also sent in the backward direction ifthe called party line is busy (cause = 17). ANSI Release Message (REL) ITU-T Release M essage (REL)
o 1 f : SIO and Label Routing SIO and Routing Label
CIC LowOrderOdet CIC Low-Order Octet t 2-bits t CIC High-Order 6-blts spare >T 4-blts spare CIC High-Order 4-bits Mandatory Message Type -12 Message Type = 12 Mandatory Fixed Rati -V ..ftesflftert, :Offset of 1 st var Parameter = |s^ Mandatory value 2 Offset ot 1 st Mandatory Var Parameter value = 2 value = 0 if Otfeet to Start of Optional Part Otfset to Start of Optional Part ho opt part Mot Length Indicator ot Cause Indicators Length Indicator of Cause Indicators Mandatory Mandatory Release Cause Indicator Parameter Variable Release Cause Indicator Parameter Vanable * of = Part octets Length Indicator value # of octets = Length Indicator value Part
sequence ; \ Optional Parameter Code Optional Parameter Code may \ \ Optional Parameter Length Indicator repeat Optional Parameter length Indicator \. Optional Parameter Ormwfii: Optional Parameter >s:
Figure 11-18. ANSI and ITU-T Release (REL) Message Format [23]
This RLC message (fig. 11-19) [24] will be relayed to the originating network switch and all
network resources for this connection will be released. At this point, the call reference values
at both user-to-network interfaces will be returned for reuse, and all resources for this
connection will be released.
It is apparent from these call flow diagrams that there is a high degree of interaction between network switching and signaling systems with user equipment. The standards, which apply for ISDN at the network layer, must be implemented correcdy and consistency in order for complex user connections to take place.
33 Release Complete Message A Release Complete Message (RLC) is sent in the opposite direction ofthe REL to acknowledge the release ofthe remote end ofa trunk circuit and end the billing cycle as appropriate. ANSI Release Complete Message (RLC) ITU-T Release Complete Message (RLC)
o 1 f SIO and Label f Routing SIO and Routing Label
s a- e X CIC LowOrder Octet CIC LowOrder Octet t ?j& CICHighJDrder6-bits spare CIC High-Order 4-bits \ swr! 4-bits -"^SandaTo-ry of'yl Figure 11-19. ANSI and ITU-T Release Complete (RLC) Message Format [23] If any device along the call path does not accurately perform the functions associated with the network layer, interoperability issues will arise. As the degree of complexity in user services increases, so to will the probability that network layer issues relating to incorrect implementation will occur and negatively impact the end users. Chapter III identifies actual case studies collected over a two (2) year period, which depict instances where incorrect implementations of layer 3 protocols by user equipment and network providers caused interoperability problems which were service impacting. These problems represent an accurate cross section of the issues that are typically encountered by users and network providers while implementing network connections using primary rate ISDN. 34 Chapter III CASE STUDY ANALYSIS The background provided in chapter II established the groundwork for understanding the various layers, which comprise the primary rate ISDN protocol stack. Layer 1 (physical) was discussed in depth. This layer uses protocols, which were developed by ANSI and Telcordia and have been in use in North America since the mid 1970's. Layer 2 (data link) and layer 3 (network) were examined in greater detail. These protocols were developed for packet transport, and have been derived from various ANSI, and ITU-T standards. Layer 3 has become the focus of this research because implementation inconsistencies at this layer can be extremely difficult to isolate and correct. The basic scheme for categorization of these implementation inconsistencies was introduced. I will continue to develop this concept in chapter III. Process for Case Selection I have spent the past three (3) years of my professional career investigating ISDN network layer interoperability issues. ISDN end users report these issues initially as some sort of service impairment, feature interoperability, or the inability to invoke a particular service. The case studies presented in this chapter are a summery of the data collected over this time period, and represent typical issues, which arise when layer 3 is not implemented consistentiy across the network. These issues can be categorized into four (4) main groups. Group I Connection Establishment Group II - Information Inconsistency Group III -Timer Handling Group IV - Information Mapping The case studies related to each category will be discussed in order, beginning with Group I, connection establishment. 35 The process of call or connection establishment begins with the layer 3 set up message (fig. III-l). This is the initial layer 3 message that conveys all required information on the connection to be established. This information is passed in the form of information elements (IE's), which are unique descriptors of various parameters required to make an end-to-end connection. There are some twenty one (21) IE's, which can be used to construct a set-up message. Most of these are optional, or conditionally required depending on the presence of other related IE's (Table III-l). Bits Octet 8 7 6 5 4 3 2 1 Protocol Discriminator 1 0 0 0 0 Length ofCall Ref 2 Call Reference Value 3 0 Message Type 4 Other Information Elements as Required 5 and higher Figure HI-1. The Set-up Message The process of capturing data from the PSTN and a users primary rate ISDN service is depicted in figure III-2 and figure III-3. The user ISDN data is decoded from a packet capture "D" of a users channel using an Agilent (former Hewlett Packard) Internet Advisor, Model 2300C. The corresponding SS7 network signaling ISDN User Part (ISUP) information is obtained from a Geoprobe Ver 4.6 analyzer manufactured by INET Corporation. Both of these analyzers can be remotely accessed so that data captures can be done from essentially anywhere without involving personnel at the users location, or class 5 stored program controlled switch (SPCS) site. 36 Information Element Direction Type Protocol Discriminator Both Mandatory Call Reference Both Mandatory Message Type Both Mandatory Bearer Capability Both Mandatory Channel Identification Both Mandatory Facility Both Optional Progress Indicator Both Mandatory ifinband Tones are provided Network-Specific Facility Both Optional included if Facilities other than Public ISDN are used for the call Display Both Optional Network can provide on subscription basis the ability to transfer the IE between users without network interpretation or Interaction Calling Party Number Both Optional Calling Party Sub address Both Optional Called Party Number Both Mandatory Called Party Sub address Both Optional Original Called Number Both Optional Transit Network Selector Both Optional Redirecting Number Both Optional Lower Layer Capability Both Optional Higher Layer Capability Both Optional Locking Shift Code set 5 Both Optional Code set 5 IE's Both Optional Locking Shift Code set 6 Both Optional Code set 6 IE's Both Optional Locking Shift Code set 7 Both Optional Code set 7 IE's Both Optional Table III-l. Valid Information Elements 37 Intranet Connection Protocol Protocol Analyzer (SS7 - Analyzer ISUP) (Layer 1-3) 1 2 / * "\ N, Switch System SPCS 56 KB 'A' Link N^ "s toSTP 3 A P Digital Cross ISDN Primary Connect Rate Interface System Circuit under Test (dacs) 4 "A" Protocol analyzer 1 is physically bridged onto the Signaling System (SS7) links at the stored program controlled switch (SPCS) / network interface (3). This analyzer is used to capture all SS7 ISDN User Part (ISUP) messaging between the SPCS and the Public Switched Telephone Network (PSTN). The Primary rate ISDN circuit under test is provisioned (hardware and software) in the SPCS (3) and physically connected to a Digital Access and Cross Connect System (DACS) (4). The circuit is mapped through this device, and connected to a Tl facility which routes to the user class II CPE (5) Protocol Analyzer 2 is electronically bridged onto the Primary Rate ISDN circuit under test at the DACS (4). This analyzer will capture layer 1 (physical), layer 2 (data link) and layer 3 (network) messaging. Remote access to devices 1-4 is made through an Intranet IP connection. Component Description Manufacturer Model Protocol Analyzer INET Corp Geoprobe Ver 4.6 Protocol Analyzer Agilent 2300C Switch Interface various (note 1) various (note 1) DACS Alcatel Model 1631 Customer equipment various various Note 1: Switching system manufacturer's, types and software load a) Nortel Networks - DMS 500 - software NA 00 1 2 b) Siemens - EWSD - Software release 1 7 Figure HI-2. Typical Analyzer Connection Scheme for Data Capture 38 Intranet Connection Protocol Analyzer (SS7 ISUP) 1 , / "n \ CPE 56 KB "A" Link N. Switch Class II to^STP ^4 System 4 SPCS p digital Cross 3 2 ISDN Primary Connect Rate Interface System Circuit under Test (dacs) 4 "A" Protocol analyzer 1 is physically bridged onto the Signaling System (SS7) links at the Stored Program Controlled Switch (SPCS) network interface (3). This analyzer is used to capture all SS7 ISDN User Part (ISUP) messaging between the switching system and the Public Switched Telephone Network (PSTN). The Primary rate ISDN circuit under test is provisioned (hardware and software) in the SPCS (3) and physically connected to a Digital Access and Cross Connect System (DACS) (4). The circuit is mapped through this device, and connected to a Tl facility which routes to the user Class II CPE (5) Protocol Analyzer 2 is integrated into the Lucent 5ESS switching system and can be enabled through software to monitor the Primary Rate ISDN circuit under test at the DACS (4). This integrated analyzer will capture layer 1 (physical), layer 2 (data link) and layer 3 (network) messaging. Remote access to devices 1-4 is made through an Intranet IP connection. Component Description Manufacturer Model 1 Protocol Analyzer METCoip Geoprobe Ver 4.6 2 Protocol Analyzer Lucent Integrated in switch 3 Switch Interface Lucent various (note 1 ) 4 DACS Alcatel Model 1631 5 Customer equipmerit various various Note 1: Lucent Technology - 5ESS - Software Release 14.1 Figure III-3. Lucent 5ESS Analyzer Connection Scheme for Data Capture voice connection which could be obtained from the data A typical set up message for a capture process described above can be seen in fig. III-4a this setup message includes the following IE's: 1) Protocol Discriminator - mandatory IE 2) Call Reference - mandatory IE 39 3) Message Type - mandatory IE 4) Bearer Capability - mandatory IE 5) Channel Identification - mandatory IE 6) Calling Party Number - optional IE 7) Called Party Number - mandatory IE Q.931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 0 (FROM side that originated call ref) Call Reference Value = 0x00-16 Message Type = SETUP (0x05) Information Element = Bearer Capability (0x04) Information Element Length = 3 Coding Standard = CCITT Info Trans Cap = Speech Transfer Mode = 64-kbps, Circuit Layer 1 User Info = u-law Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Exclusive D-channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 1 Information Element = Calling Party Number (0x6c) Information Element Length = 12 Number Type/Plan = Nat. ISDN Origin/Pres = Allowed/Net. Prov Digits = 3132300008 Information Element = Called Party Number (0x70) Information Element Length = 5 Nmbr Type/Plan = Local ISDN Digits = 0074 Hex Data 08 02 00 16 05 04 03 80 90 a2 18 03 a9 83 81 6c 0c 21 83 33 31 33 32 33 30 30 30 30 38 70 05 cl 30 30 37 34 Figure IH-4A. Typical Setup Message 40 The analy2er performs the decoding function on each of these component IE's. To verify the accuracy of the analyzer, the raw hexadecimal data provided at the end of the data capture can be manually decoded. Closer investigation of the data provided in figure III-4a shows that the layer 3 information of interest begins with the protocol discriminator (08h). This value is followed by the Call reference length octet (02h), the call reference flag octet (OOh), the call reference value octet (16h) and the message type octet (05h) as shown in fig. III-4b. The III- example setup message was manually decoded beginning with the bearer capability IE (fig. III- 4c), and continuing with the channel identification IE (fig. III-4d), the calling party IE (fig. 4e) and finally the called party ID (fig. III-4f). The values derived by manually decoding each of these information elements are identical to the automatic decode provided by the Agilent 2300C. Occasionally, the analyzer will misinterpret the raw data. This is usually due to a configuration problem with software in the analyzer. The correct decoding of the setup message is critical in working group I problems since these issues deal with incorrect interpretation of the manditory IE's which are passed from the user to the SPCS in the setup message. Raw hex from data capture Protocol Discriminator (08 hex) - Beginning of Layer 3 Info Call Reference Length (02 hex) Call Reference Flag (00 hex) Call reference Value (16 hex) li"Message Type (05 hex - Setup) 08 02 00 16 05 04 03 80 90 a2 18 03 a9 83 81 6c 0c 21 83 33 31 33 32 33 30 30 30 30 38 70 05 cl 30 30 37 34 Figure DI-4B. Setup Message Header Information 41 Raw hex from data capture Bearer capability IE (04h) IE Length (03h) Data Values (80h,90h,a2h) am 02 01 be 26 08 02 00 16 05 04 03 80 90 a2 18 03 a9 83 81 6c 0c 21 83 33 31 33 32 33 30 30 30 30 38 70 05 cl 30 30 37 34 HEX Binary Equivalent Description (TR-NWT-001268) 80h 10 0 0 0 0 00 4444 4444 Last Octet ofDescription ITU-T (CCITT) Standard Speech HEX Binary Equivalent Description (TR-NWT-001268) 90h 1 0 0 1 Q Q 0 Q Last Octet ofDescription Circuit Mode 64Kb/s HEX Binary Equivalent Description (TR-NWT-001268) a2h 10 10 0 0 10 4444 4444 Last Octet of Description Layer 1 ID ITU-T G.711mu-law Figure m-4C. Bearer Capability IE Decode 42 Raw hex from data capture Channel I.D. IE (18h) IE Length (03h) iData (a9h,83h,81h) m 18 03 a9 83 81 6c 0c 21 83 33 31 33 32 33 30 30 30 30 38 70 05 cl 30 30 37 34 HEX Binary Equivalent Description (TR-NWT-001268) A9h 10 10 10 0 1 4444 44/tl Last Octet ofDescription Primary Rate Exclusive Channel Chan Sel. Implicit Interface Defined Spare Non-D-Chan HEX Binary Equivalent Description (TR-NWT-001268) 83h 10 0 0 0 0 11 tttt tttt Last Octet of Description Binary Code Assigned - Interface HEX Binary Equivalent Description (TR-NWT-001268) 81h 10 0 0 0 0 0 1 4444 tttt Channel is indicated in this octet Last Octet ofDescription ITU-T Std. Chi Figure III-4D. Channel Identification IE Decode 43 Raw hex from data capture Calling Party IE (6ch) ; IE Length (Och) 6c Oc 21 83 33 31 33 32 33 30 30 30 30 3! Data(21h,83h,33h,31h,33h,32h,33h,30h,30h,30h,30h38h) HEX Binary Equivalent Description (TR-NWT-001268) 21h 0 0 10 0 0 0 1 4444 4444 E. 164 Number Plan National Number Description Extended next Octet HEX Binary Equivalent Description (TR-NWT-001268) 83h 10 0 0 0 0 11 4444 4444 Last Octet of Description Presentation Spare Network Provided Subsequent Octets HEX Binary Equivalent Decoded Values (TR-NWT-001268) 33h 00110011 3 - first digit of Calling Number NPA 31h 0001 0001 1 - second digit of Calling Number NPA 33h 00110011 3 - final digit of Calling Number NPA 32h 00110010 2 - first digit of Calling Number Exchange 33h 00110011 3 - second digit of Calling Number Exchange 30h 0011 0000 0 - final digit of Calling Number Exchange 30h 0011 0000 0 - first digit of calling Number Station ID 30h 0011 0000 0 - second digit of calling Number Station ID 30h 00110000 0 - third digit of calling Number Station ID 38h 0011 1000 8 - final digit of calling Number Station ID Figure m-4E. Calling Party Number IE Decode 44 Raw hex from data capture 70 05 cl 30 30 37 34 4 4 Data (clh,30h,30h,37h,34h) IE Length (05h) Called Party IE (70h) HEX Binary Equivalent Description (TR-NWT-001268) clh 110 0 0 0 01 4444 tttt E. 164 Number Plan Subscriber Number Last Octet of Description Subsequent Octets HEX Binary Equivalent Decoded Values (TR-NWT-001268) 30h 00110000 0 - first digit of called Number Station ID 30h 0011 0000 0 - second digit of called Number Station ID 37h 00110111 7 - third digit of called Number Station ID 34h 00110100 4 - final digit of called Number Station ID Figure m-4F. Called Party Number EE Decode Group I - Connection Establishment "A" Case Study is an actual trouble, which was reported initially on 12/07/2001. The user was located in Miami Florida, and the ISDN service was being used for inbound and outbound voice only. The service was recently activated (11/29/01), and the user had experienced numerous issues associated with the service activation. The only remaining problem was that the user was unable to receive any inbound calls what so ever. The specifics of this service arrangement are: ISDN Service Parameters A) SPCS Type - Siemens EWSD class 5 end office 45 B) Switch Software load - Release 17 - Layer 2 protocol - C) TR-TSY-000793 configured for facility associated signaling - Layer 3 protocol - D) Bellcore TR-NWT-001268 configured for calling number delivery and 3 digit called party number delivery Customer Class II Equipment A) Type-EricksonMD-llD B) Software Load unknown C) Layer 2 protocol unknown - configured for facility associated signaling D) Layer 3 protocol load - Bellcore TR-NWT-001268 A data capture was taken on 12/5/01 of an inbound call attempt to the users primary rate ISDN service. The circuit was connected to a protocol analyzer (fig. III-2), test calls were placed from a non ISDN service (919-377-0934) to the user (813-371-8101) and the layer 3 call control messaging was captured. A setup message issued by the SPCS (fig. III-5a) and a release complete message issued by the users equipment (fig III-5b) were the only layer 3 records associated with the test calls. 46 Q.931: AT&T5ESS Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 0 (FROM side that originated call ref) Call Reference Value = 0x00-2c Message Type = SETUP (0x05) Information Element = Bearer Capability (0x04) Information Element Length = 3 Coding Std = CCITT Info Trans Cap ==3.1 KHz Audio Transfer Mode = Circuit Transfer Rate = 64 Kbit/s Layer Id = Layer 1 Proto Id = G.711 u-law Speech Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Exclusive D-channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B-channel units Channel Number = 1 Information Element = Progress Indicator (Oxle) Information Element Length = 2 Coding Std = CCITT Location = Transit Network Prog Desc = Orig Addr non-ISDN Information Element = Calling Party Number (0x6c) Information Element Length = 12 Address Type = National Number Plan = ISDN/Telephony Presentation = Allowed Screening = Network Provided Number Digits = 9193770934 Information Element = Called Party Number (0x70) Information Element Length = 4 Number Type = Local/Directory Number Plan = ISDN/Telephony Number Digits = 101 Hex Data 08 02 00 2c 05 04 03 90 9 0 a2 18 03 a9 83 81 le 02 83 83 6c 0c 21 83 39 31 39 33 37 37 30 39 33 34 70 04 cl 31 30 31 Figure III-5A. Case "A" Called Party Number IE Decode 47 Q.931: AT&T5ESS Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference = Flag 1 (TO side that originated call ref) Call Reference Value = 0x00-2c Message Type = REL COM (0x5a) Information Element = Cause (0x08) Information Element Length = 2 Coding Std = CCITT Location = Priv Net Serv Local User Class = Normal Event Cause Val = Unassigned Number Cause Decimal Value = 1 Hex Data 08 02 80 2c 5a 08 02 81 81 Figure m-5B. Case "A "Release Complete Message The release complete message has a cause code of 01 hex, which the protocol analyzer decodes as "unallocated number". The manual decode of this release complete message confirms this (fig. III-5c). This indicates that the user equipment does not recognize the called number in the setup message as being valid. It is a normal practice for the SPCS to perform digit manipulation for calls to the user. Most often the only numbers of interest to the user equipment are the last four (4) station digits of a standard ten (10) digit called number (fig III-5d). For example, a user may have five hundred numbers associated with a primary rate ISDN service, 716-992-4000 through 4999. To simplify number translations in the user equipment, the user may request to have some of the leading digits in the called party number deleted. The trailing digits (3 or 4) would then be sent as the called party number in the setup message to the user. This is precisely what is occurring in case study "A". 48 Raw hex from data capture Protocol Discriminator (08 hex) - Beginning of Layer 3 Info Call Reference Length (02 hex) Call Reference Flag (80 hex) Call reference Value (2c hex) Message Type (5a hex - release complete) IE Type (08 hex - cause) IE Length (02 hex) Data (81 m hex, 81 hex) 08 02 80 2c 5a 06 02 81 81 HEX Binary Equivalent Description (TR-NWT-001268) 81h 10 0 0 0 0 0 1 till Spare Private Net. Serv. Local User Last Octet ofDescription ITU-T Standard HEX Binary Equivalent Description (TR-NWT-001268) lh 10 0 0 0 0 0 1 A AAA AAAA Last Octet of Description Unallocated Number Figure DH-5C. Case "A" Decoded Release Complete Message NPA- NXX- xxxx Number Plan Administration Exchange Station Code OR Area Code - Location in Class 5 Switch Unique number, 0001 - North America - Administered where this exchange through 9999 Identifies by Telcordia resides a users line Figure HI-5D. North American Numbering Plan 49 The called number party element in the setup message, when decoded by the protocol "101" analyzer indicates that is being sent for all connection attempts made to 813-371-8101. Manually decoding the called party IE from the setup message confirms this (fig. III-5e). This data was presented to the and it was user, determined that this particular calling part number had not been established in the users Class II equipment. When it was established, inbound calls completed without issue. Raw hex from data capture 70 04 cl 31 30 31 ' k tttt Data(clh,31h,30h,31h) IE Length (04h) Called Party IE (70h) HEX Binary Equivalent Description (TR-NWT-001268) clh 1 1 0 Q mi E. 164 Number Plan Subscriber Number Last Octet ofDescription Subsequent Octets HEX Binary Equivalent Decoded Values (TR-NWT-001268) 31h 0011 0001 1 - first digit of called Number Station ID 30h 00110000 0 - second digit of called Number Station ED 31h 00110001 1 - third digit of called Number Station ID Figure III-5E. Case "A" Decoded Called Party IE "B" Case study is an actual trouble, which was reported initially on 10/04/2001. The user was located in, Minneapolis Minnesota and the ISDN service was used for inbound and outbound voice and data. The user reported that they were unable to complete any international voice calls. The specifics of this service arrangement are: 50 ISDN Service Parameters A) SPCS Type Lucent 5ESS class 5 end office B) Switch Software load - Release 14.1 Layer 2 protocol - - C) TR-TSY-000793 configured for facility associated signaling D) Layer 3 protocol - Bellcore TR-NWT-001268 Customer Class II Equipment A) Type Lucent Definity G3 B) Software Load unknown C) Layer 2 protocol - unknown - configured for facility associated signaling D) Layer 3 protocol load - Bellcore TR-NWT-001268 A data capture was taken on 10/05/01 of an outbound call attempt to an international number (441244280390) from the users primary rate ISDN service. The circuit was connected to a protocol analyzer (fig. III-3), test calls were captured from the users equipment to one of the international numbers reported (441244280390) and the layer 3 call control messaging was captured via a software trap enabled in the Lucent 5ESS switch. A setup message issued by the users equipment (fig. III-6a), call proceeding (fig. III-6b) and progress messages (fig. III-6c) issued by the SPCS, disconnect message (fig. III-6d) issued by the users Class II equipment, and release message (fig. III-6e) message issued by the Lucent SPCS. The disconnect message in this instance is in descript (cause code 16, normal clearing). 51 08 Q. 931 Call Control Message Call Reference Value Orig 218 M 05 Message Type SETUP I 04 Bearer Capability Length = 3 80 Coding Standard CCITT Info Transfer Cap. Speech 90 Transfer Mode Circuit Transfer Rate 64 kbit/s A2 Layer 1 Protocol G.711 u-law I 18 Channel Identification Length = 3 A9 Interface ID Impl.icitly Defined Interface Type Primary Preferred/Exclusive Exclusive D Channel Indicator Not D Channel Channel Selection As Indicated 83 Coding Standard CCITT Coding Type Number Channel Type B Channel 95 Channel Number 21 I 28 Display Length = 8 Display C. Heath I 6C Calling Party Number Length = 11 80 Type of Number Unknown Type Numbering Plan Unknown Numbering Plan Number 9528523760 I 70 Called Party Number Length = 16 91 Type of Number International Number Numbering Plan ISDN/Telephony E.164/E.163 Number 011441244280390 Raw Hex Data 08 02 00 DA 05 04 03 80 90 A2 18 03 A9 83 95 28 08 43 2E 20 48 65 61 74 68 6C 0B 80 39 35 32 38 35 32 33 37 36 30 70 10 91 30 31 31 34 34 31 32 34 34 32 38 30 33 39 30 Figure III-6A. Case "B" Setup Message 52 Event 2 01/10/04 11:45:41 TEI 0 08 Q.931 Call Control Message Call Reference Value Dest 218 M 02 Message Type CALL PROCEEDING I 18 Channel Identification Length = 3 A9 Interface ID Implicitly Defined Interface Type Primary Preferred/Exclusive Exclusive D Channel Indicator Not D Channel Channel Selection As Indicated 83 Coding Standard CCITT Coding Type Number Channel Type B Channel 95 Channel Number 21 Raw Hex Data 08 02 80 DA 02 18 03 A9 83 95 Figure III-6B. Case "B" Call Proceeding Message Event 3 01/10/04 11:45:41 TEI 0 08 Q.931 Call Control Message Call Reference Value Dest 218 M 03 Message Type PROGRESS I 08 Cause Length = 2 82 Coding Standard CCITT Location Local Public Network 9F Class Normal Event Value #31, Normal, Unspecified I IE Progress Indicator Length = 2 84 Coding Standard CCITT Location Remote Public Network 88 Value In-band Information/Pattern Avail Raw Hex Data 08 02 80 DA 03 08 02 82 9F IE 02 84 88 Figure III-6C. Case "B" Progress Message 53 Event 4 01/10/04 11:45:46 TEI 0 08 Q.931 Call Control Message Call Reference Value Orig 218 M 45 Message Type DISCONNECT I 08 Cause Length = 2 80 Coding Standard CCITT Location User 90 Class Normal Event Value #16, Normal Call Clearing Raw Hex Data 08 02 00 DA 45 08 02 80 90 Figure III-6D. Case "B" Disconnect Message Event 5 01/10/04 11:45:46 TEI 0 08 Q.931 Call Control Message Call Reference Value Dest 218 M 4D Message Type RELEASE Raw Hex Data 08 02 80 DA 4D Figure III-6E. Case "B" Release Message When the setup message in investigated, the called number IE indicates that the called number type is international, and the called number includes the prefix code for international dialing- direct 011 (011441244280390). This digit string is incorrect for called numbers, which are declared to be international. In this case, the 011 prefix is not required for direct dialing an international number. When the 011 prefix is added to a called number, which is anticipated to be international, the prefix is interpreted as part of the international number. The class 5 SPCS will attempt to map this 011 prefix into a known country code. The call will fail to an in- announcement as depicted by the progress message issued by the switching system with band information (fig. III-6c). The in-band information is an announcement informing the caller that the number dialed was invalid. Manual decoding ofthe setup message called number IE (fig. III-6f), and the progress message progress indicator (fig. III-6g) verify the switch protocol analyzer decode. This information was forwarded to the user who changed routing tables in the user equipment to delete the 011 prefix from the called number IE and international connections could then be established. 54 RAW HEX DATA 70 10 91 30 31 31 34 34 31 32 34 34 32 38 30 33 39 30 tttttttttttttttttt Data(clh,31h,30h,31h) IE Length (lOh) Called Party IE (70h) HEX Binary Equivalent Description (TR-NWT-001268) 91h 1 0 0 1 0 0 01 ???? AAAA 1 1 E.164 Number Plan International Number Last Octet ofDescription Subsequent Octets HEX Binary Equivalent Decoded Values (TR-NWT-001268) 30h 0011 0000 0 - first digit of country code 31h 00110001 0 - second digit of country code 31h 00110001 1 - third digit of country code 34h 00110100 4 - first digit of city code 34h 0011 0100 4 - second digit of city code 31h 00110001 1 - third digit of city code 32h 00110010 2 -first digit of 34h 00110100 4 - second digit of 34h 00110100 4 - third digit of 32h 00110010 2 - fourth digit of 38h 0011 1000 8 -fifth digit of 30h 00110000 0 - sixth digit of 33h 00110011 3 - seventh digit of 39h 0011 1001 9 - eight digit of 3CIh 0011 0000 0 - ninth digit of Figure m-6F. Case "B" Setup Message, Called Number IE Decode 55 RAW HEX DATA IE 02 84 88 I Data (84h,88h) IE Length (02h) Progress Indicator IE (leh) HEX Binary Equivalent Description (TR-NWT-001268) 84h 1 0 0 0 01 0 0 Spare Private Net. Serving Remote User Last Octet ofDescription ITU-T Standard HEX Binary Equivalent Description (TR-NWT-001268) 88h 10 0 0 10 0 0 AAAA AHA Last Octet of Description In-band Information Pattern Available Figure III-6G. Case "B" Progress Message, Progress IE Decode Group II Information Inconsistency The next set of case studies will investigate examples of Group II, information "C" inconsistency. Case Study is an actual trouble, which was reported initially on 11/21/2001. The user was located in, Dallas Texas and the ISDN service was used for inbound and outbound voice only. The user reported that they were unable to complete voice connections to specific exchanges within the Dallas Metropolitan Area. The specifics of this service arrangement are: 56 ISDN Service Parameters A) SPCS - Nortel Networks DMS 500 class 5 end office B) Switch Software load - LLT00.12 - Layer 2 protocol TR-TSY-000793 - configured C) for facility associated signaling D) Layer 3 protocol - Bellcore TR-NWT-001268 Customer Class II Equipment A) Type - Lucent Definity G2 B) Software Load - unknown Layer 2 protocol - unknown - C) configured for facility associated signaling D) Layer 3 protocol load - Bellcore TR-NWT-001268 A capture was taken on of an data 11/23/01 outbound call attempt to the users primary rate ISDN service. The circuit was connected to a protocol analyzer (fig. III-2), test calls were captured from the users equipment to a number in the effected exchange (214-929-5445) and the layer 3 call control messaging was captured. A setup message issued by the users equipment (fig. III-7a) and a release complete message issued by the SPCS (fig III-7b) were the only layer 3 records associated with the test calls. The release complete message indicated a cause code of value of 54 "inbound calls barred". 57 Q.931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 0 (FROM side that originated call ref) Call Reference Value = 0x00-79 Message Type = SETUP (0x05) Information Element = Bearer Capability (0x04) Information Element Length = 3 Coding Std = CCITT Info Trans Cap = Speech Transfer Mode = Circuit Transfer Rate = 64 Kbit/s Layer Id = Layer 1 Lay. 1 Prot = G.711 u-law Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Preferred D-channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 23 Information Element = Undefined (0x20) Information Element Length = 2 Information Element = Calling Party Number (0x6c) Information Element Length = 12 Number Type = National Number Plan = 7 Presentation = Allowed Screening = User Prov Un-Screened Number Digits = 9723307100 Information Element = Called Party Number (0x70) Information Element Length = 11 Number Type = National Number Plan = 7 Number digits = 2149295445 Hex Data 08 02 00 79 05 04 03 80 90 a2 18 03 al 83 97 20 02 00 81 6c 0c 21 83 39 37 32 33 33 30 37 31 30 30 70 0b al 32 31 34 39 32 39 35 34 34 35 Figure III-7A. Case "C" Setup Message 58 Q.931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 1 (TO side that originated call ref) Call Reference Value = 0x00-79 Message Type = REL COM (0x5a) Information Element = Cause (0x08) Information Element Length = 2 Coding Std = CCITT Locat = User Cause = Incoming calls barred Cause Decimal Value = 54 Hex Data 08 02 80 79 5a 08 02 80 b6 Figure III-7B. Case "C" Release Complete The setup message for this call (fig. III-7a) shows a network specific facility (NSF) IE. Normally, these IE's are used to invoke a special network service, i.e. a wide area transport service (WATS). These types of call setups are common with ISDN interfaces to class 3 (Inter Lata access SPCS's) but they are very uncommon with ISDN interfaces to class 5 SPCS's. There are two (2) basic requirements in order for the SPCS to process connection requests using a NSF IE's. First, the user must subscribe for the specific network service, which the IE is invoking, and second, the NSF IE must be syntactically correct. As it turns out, neither of these two requirements is met in this example. This ISDN user has not subscribed to any network specific facility. This stops the connection from processing by immediately releasing barred" the connection request with the cause code "incoming calls (fig. III-7c). By decoding the NSF IE in the setup message (fig. III-7d), and comparing it with the reference for it in Bellcore TR-NWT-001268 it can be seen that there are additional octets which define the service being requested which are not present in the IE. This information was presented to removed from the connection the user, and when the NSF IE was setup, these connections could be made. 59 Raw hex from data capture Protocol Discriminator (08 hex) - Beginning of Layer 3 Info Call Reference Length (02 hex) Call Reference Flag (80 hex) Call reference Value (79 hex) - Message Type (5a hex release complete) IE Type (08 hex - cause) IE Length (02 hex) Data IrT (81 hex, 81 hex) 08 02 80 79 5a 08 02 80 b6 HEX Binary Equivalent Description (TR-NWT-001268) 80h 10 0 0 0 0 0 0 "" mi i Last Octet of Description Spare User ITU-T Standard HEX Binary Equivalent Description (TR-NWT-001268) b6h 1 0 J 1 Q 1 man*, mm Last Octet ofDescription Incoming Calls Barred Figure III-7C. Case "C" Decoded Release Complete Message 60 Raw hex from data capture 20 02 00 81 P Data (00h,81h) IE Length (02h) Network Specific Facility IE (20h) HEX Binary Equivalent Description (TR-NWT-001268) OOh 000 0 0 0 00 1 Length ofNetwork ID HEX Binary Equivalent Description (TR-NWT-001268) 81h 10 0 0 0 0 0 1 AAAA mi Carrier ID Code Last Octet of Description User Specified Net. ID Figure III-7D. Case "C" Decoded Network Specific Facility ID 61 "D" The next study in this group, case study relates to a problem which was reported on 12/7/2001 where an ISDN user in La Jolla California could not make specific voice Intra Lata connections to cellular users in San Diego California. The specifics of this service arrangement are: ISDN Service Parameters A) SPCS Type - Nortel Networks DMS 500 class 5 end office B) Software Load -LLT00. 12 Q Layer 2 protocol TR-TSY-000793 configured for facility associated signaling Customer Class II Equipment A) Type- Dialogic LSI/161SC B) Software Load unknown C) Layer 2 protocol - unknown - configured for facility associated signaling D) Layer 3 protocol load - Telcordia Technology TR-NWT-001268 The circuit was connected to a protocol analyzer (fig. III-2) and layer 3 and Signaling System Seven (SS7) data capture were taken on 12/8/2001 of outbound connection attempts to 619-518-2083 from the ISDN user in La Jolla. The called number (619-518-2083) is owned by Pacific Bell Mobile, a cellular carrier in Southern California. Calls from the ISDN user in La Diego. common Jolla are routed from the WorldCom class 5 SPCS (DMS 500) in San The language location identifiers (CLLI) and originating point codes (OPC) for these switches are as follows: WorldCom class 5 Local San Diego Switch CLLI - SNDICAETDS0 OPC - 001-144-104 62 Pacific Bell Mobile Switch in San Diego CLLI - SNDGCA0291T Point Code - 251-142-002 The for the OPC Release Message captured on the SS7 protocol analyzer for these connection attempts indicates that the connection was released, or refused by the cellular carrier (fig. III- 8a) with a cause value of interworking unspecified. Octet005 Routing label DPC: Net-Clstr-Mbr 001-144-104 MFSSNDG OPC: Net-Clstr-Mbr 251-142-002 00010111 SLS 23 Octet012 Circuit identification code CIC 6149 00 Spare 0 Octet014 ISUP Release message 00001100 Message type REL Release 00000010 Pointer->cause 2 00000000 Pointer->optionals 0 Octet017 Cause indicators parameter 00000010 Parameter length 2 ....1010 Location Unknown ...0.... Spare 0 .00 Coding standard CCITT standard 1 Extensionbit 1 .1111111 Cause Value Interworking, unspecified 1 Extensionbit 1 Checksum CRC16 0000110010101101 hex=0CAD Figure III-8A. Case "D" SS7 ISUP Release Message 63 The partial Initial Address Message (IAM) captured for his call is shown in fig. III-8b). Investigation of the IAM octet 34 reveals that the calling party number provided by the ISDN user was 18585522200. The WorldCom local SPCS interpreted the nature of this address this to be a unique international number. In fact, this number's nature of address for this connection should be national as shown in octet 34 of the SS7 ISUP IAM, This octet is mapped from what the ISDN user provides in the Type of Number parameter of the Calling Party Information Element (IE) ofthe layer 3 setup message. DPC: Net-Clstr-Mbr 251-142-002 OPC: Net-Clstr-Mbr 001-144-104 MFSSNDG Octet016 Forward call indicators parameter 0 Nat'l/International Not an incoming international call 00. End-to-end method No end-to-end method available ....0... Interworking No interworking encountered ...0.... End-to-end indicator No end-to-end information available . . 1 indicator ISDN user part used all the way 00 preference ISDN user part preferred all the way 1 Orig ISDN access Originating access ISDN 00. SCCP method No indication ...0... Spare 0 ... 1 ... . Ported number ind Number translated 000 Reserved for nat'l 0 0000 1010 Parameter name code ISUP Calling party number parameter 00001000 Parameter length 8 .0000100 Nature of address Unique international number 1 Odd/even odd number of address signals 00 Screening indicator Reserved (for "user provided, not screened") ....00.. No addr presentation Presentation allowed .000.... Numbering plan Unknown (no interpretation) 0 Spare 0 Address signals 18585522200 0000.... Filler 0 Figure III-8B. Case "D" SS7 ISUP Initial Address Message Investigating the calling party IE in the layer 3 setup message for this connection confirms that the calling number (18585522200) is being provided by the user (fig. III-8c). By manually decoding the raw hexadecimal data for the Calling Party IE, it was discovered that the ISDN user's equipment was providing an invalid Type of Number (fig. III-8d). There are four (4) possible types ofnumbers that can be declared: 64 1) Unknown user is not specifying 2) Subscriber - used for digit strings of less than ten numbers, usually interpreted as an NXX / Station combination. 3) National - used for digit strings often numbers, usually interpreted as an NPA / NXX / Station code combination. 4) International - used for digit strings where the country code, city routing code and local number is interpreted. Since the type of number was not declared, and the user was sending an eleven digit calling party number string, the WorldCom class 5 SPCS interpreted this to be an international number and formatted octet 34 of the IAM correspondingly. The terminating end cellular switch was decoding this information, and expected the eleven-digit string provided as an "International" calling party to map into a valid country and city code and city routing code, which it does not. Because ofthis, the IAM for this connection was refused (released). 65 .931: DMS-100 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference = Flag 0 (FROM side that originated call ref) Call Reference Value = 0x00-23 Message Type = SETUP (0x05) Information Element = Bearer Capability (0x04) Information Element Length = 3 Coding Std = CCITT Info Trans Cap = Speech Transfer Mode = Circuit Transfer Rate = 64 Kbit/s Layer Id = Layer 1 Lay. 1 Prot = G.711 u-law Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Exclusive D- channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 23 Information Element = Calling Party Number (0x6c) Information Element Length = 13 Number Type = Unknown Number Plan = Unknown Presentation = Allowed Screening = User Prov Un-Screened Number Digits = 18585522200 Information Element = Called Party Number (0x70) Information Element Length = 12 Number Type = National Number Plan = 7 Number digits = 16195182083 08 02 00 23 05 04 03 80 90 a2 18 03 a9 83 17 6c Od 00 80 31 38 35 38 35 35 32 32 32 30 30 70 0c al 31 36 31 39 35 31 38 32 30 38 33 Figure III-8C. Case "D" Layer 3 Setup Message 66 Raw hex from data capture Calling Party IE (6ch) I IE Length (Odh) 6c Od 00 80 31 38 35 38 35 35 32 32 32 30 30 Data (00h,80h,31h,38h,35h,38h,35h,35h,32h,32h,32h 30h 30h) HEX Binary Equivalent Description (TR-NWT-001268) OOh 0000 0000 AAAA tttt Unknown Number Plan 1 INVALID Number Description Extended next Octet HEX Binary Equivalent Description (TR-NWT-001268) 80h 10 0 0 00 0 0 AAAA AAAA Last Octet ofDescription Presentation Allowed Spare User Provided Subsequent Octets HEX Binary Equivalent Decoded Values (TR-NWT-001268) 31h 00110001 1 - first digit of Calling Number Country Code 38h 0001 1000 8 - second digit of Calling Number Country Code 35h 00110101 5 - first digit of Calling Number City Routing Code 38h 0011 1000 8 - second digit of Calling Number City Routing Code 35h 00110101 5 - first digit ofLocal Calling Number 35h 00110101 5 - second digit ofLocal Calling Number 32h 0011 0010 2 - third digit of Local Calling Number 32h 0011 0010 2 - third digit of Local Calling Number 32h 00110010 2 - fourth digit of Local Calling Number 30h 00110000 0 - fifth digit of Local Calling Number 30h 00110000 0 - final digit of Local Calling Number Figure III-8D. Case "D" Calling Party Number IE Decode 67 When the originating ISDN user changed the setup parameters for this connection to: 1) Number Type = National 2) Provided a ten digit calling party The cellular carrier then accepted the connection request and connected the call. Group HI Timer Handling There are a number of timers which control specific layer 3 events associated with the establishment and tear down of connections. The intent of these timers is to prevent the unnecessary allocation of switching or network resources in the event that required or anticipated events do not occur. A brief description of these timers, their purpose, and how they are controlled is given in Table. III-2. Group III issues generally arise when a timer is not stopped or started properly upon the receipt of a specific sequence of layer 3 messages. 68 Timer Range Default Value Cause For Normal At The Number Initiation Termination Expiry T301 3 to 7 minutes 5 minutes SPCS receives CONNect SPOS clears call from in steps of 1 ALERTing received from the to called and the called Class minute called Class II calling Class II II equipment equipment equipment T303 1 to 4 seconds 4 seconds SPCS transmits or ALERTing, On first in steps of 0.5 retransmits PROGress, or expiration: if second SETUP to called CONNect called Class II Class II equipment received from equipment has called Class II not responded, equipment. If SPCS notification of retransmits delay objective is SETUP. If call is not supported also not cleared, it is on receipt of an (0) objective CALL that the SPCS PROCeeding send notification of delay to calling Class II equipment. On second expiration: SPCS provides unsuccessful call treatment. T-delay T303 SPCS sends first ALERTing, SPCS sends SETUP message PROGress, or notification of CONNect delay to the received from the calling Class LI called Class II equipment equipment T305 2 to 60 30 seconds SPCS sends Disconnect, SPCS sends seconds in Disconnect to the RELease, or RELease to the steps of 1 Class II equipment RELease Class H second COMplete equipment received from the Class II equipment T306 30 to 150 60 seconds SPCS sends calling Class II SPOS sends Disconnect to seconds in PROGress to the equipment the calling Class steps of 30 calling Class II initiates clearing II equipment seconds equipment for an unsuccessful call Table III-2. Layer 3 Timers (1 of 2) 69 Timer Range Default Value Cause For Normal At The Expiry Number Initiation Termination 4 T308 2 to 10 seconds seconds SPCS sends RELease or SPCS in steps of I RELease to the RELease retransmits second Class II COMplete received RELease and starts equipment from the Class II T408 or restarts equipment T308 T309 10 to 90 90 seconds SPCS detects data 1) STATus, 1) When T322 also seconds in link malfunction Disconnect, expires, the steps of 10 during active call RELease, or SPCS initiates seconds RELease restart, or 2) SPCS COMplete received clears call from the Class 1 1 internally, and equipment. 2) As awaits indication of an implementation layer 2 option upon layer 2 reestablishment reestablishment. before initiating restart. T310 3 to 10 10 seconds SPCS receives ALERTing, SPCS provides seconds in CALL PROGress, unsuccessful call steps of 1 PROCeeding from CONNect, or treatment second; the called Class II Disconnect with T3 10 equipment received from the >T303 called Class II equipment T316 10 to 120 30 seconds SPCS transmits or SPCS receives If first attempt, seconds in retransmits RESTart retransmit steps of 1 0 RESTart to Class II ACKnowledge RESTart; if second seconds equipment from Class II attempt, take equipment channel(s) out of service and start T- rest. T320 20 to 60 30 seconds For B-channel Call Request packet For B-channel seconds in access: received or access: steps of 5 1) CONNect sent or Incoming Call disconnect link seconds received for first packet delivered layer and initiate packet call. over the B-channel; clearing. 2) Last logical or Disconnect channel cleared, received. Table III-2. Layer 3 Timers (2 of2) 70 The first example of timer handling inconsistency is case E. This problem was first reported in March of 2001. A hospital complex in Philadelphia Pennsylvania was using a primary rate ISDN interface to provide voice services for it's centrally located main private branch exchange (PBX). The hospital had several other buildings within the complex, each with its own satellite PBX. The satellite PBX's were connected back to the main PBX with point-to- point non-ISDN trunks. All inbound calls came into the main PBX where they would be subsequendy routed to the satellite locations over the point-to-point non-ISDN trunks. The hospital reported intermittent connection failures to stations served off of the satellite PBX's. ISDN Service Parameters - A) SPCS Type - Siemens EWSD class 5 end office - Philadelphia Pennsylvania CLLI PHLAPAFGDSO B) Software Load Release 17 C) Layer 2 protocol - TR-TSY-000793 - configured for non-facility associated signaling D) Layer 3 protocol - Telcordia Technology TR-NWT-001268 Customer Class II Equipment A) Type- Siemens/Rolm 9751 B) Software Load - unknown C) Layer 2 protocol - unknown - configured for non-facility associated signaling. D) Layer 3 protocol load - Telcordia Technology TR-NWT-001268 protocol analyzer (fig. and layer 3 and The circuit was connected to a III-2) Signaling System Seven (SS7) data capture were taken on 11/20/2001 of inbound connection attempts to 610-891-3777. The layer 3 capture indicates that a valid setup message was issued by the WorldCom class 5 SPCS (fig. III-9a) which was subsequendy responded to by call proceeding messages from the users Class II equipment The capture (fig. III-9b) and progress (fig. III-9c) 71 also indicates that the WorldCom class 5 SPCS issued a disconnect message before the user answered (fig. III-9d) with a timer expiry, cause code 102 The cause code does not identify which layer 3 timer is expiring, however is possible to identify which timer is expiring by investigating the time stamps associated with the layer 3 messages related to this connection attempt. A summary ofthese events with time stamps is shown in Table III-3. Record Direction Message Message Time T310 No. Type Stamp Elapsed Time 26 To User Setup 12:46:04.5875077 30 From User Call Proc. 12:46:04.6823789 T310 Started 49 From User Progress 12:46:07.6043801 82 To User Disconnect 12:46:14.6913847 10.009058 - timer expired 84 From User Rel. 12:46:14.8556322 86 To User Rel . Comp . 12:46:14.8675097 "E" Table III-3. Case Summary of Events 72 ,931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 0 (FROM side that originated call ref) Call Reference Value = 0x10-44 Message Type = SETUP (0x05) Information Element = Bearer Capability (0x04) Information Element Length = 3 Coding Standard = CCITT Info Trans Cap =3.1 KHz Audio Transfer Mode = 64-kbps, Circuit Layer 1 User Info = u-law Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Preferred D- channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 17 Information Element = Progress Indicator (Oxle) Information Element Length = 2 Coding Std = CCITT Locat = Pub Net Serv Local User Prog Desc = Orig Addr non-ISDN Information Element = Calling Party Number (0x6c) Information Element Length = 2 Number Type/Plan = Unknown Origin/Pres = ? Information Element = Called Party Number (0x70) Information Element Length = 8 Nmbr Type/Plan = Local ISDN Digits = 8913777 al le 02 HEX 02 01 ca lc 08 02 10 44 05 04 03 90 90 a2 18 03 83 91 82 83 6c 02 00 cO 70 08 cl 38 39 31 33 37 37 37 Figure III-9A. Case "E" Layer 3 Setup Message 73 Q.931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 = Call Reference Flag 1 (TO side that originated call ref) Call Reference Value = 0x10-44 Message Type = CALL PROC (0x02) Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Exclusive D- channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 17 HEX 08 02 90 44 02 18 03 a9 83 91 Figure III-9B. Case "E" Layer 3 Call Proceeding Message .931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 1 (TO side that originated call ref) Call Reference Value = 0x10-44 Message Type = PROGress (0x03) Information Element = Progress Indicator (Oxle) Information Element Length = 2 Coding Std = CCITT Locat = Priv Net Serv Rem User Prog Desc = Not End-End ISDN HEX 08 02 90 44 03 le 02 85 81 Figure III-9C. Case "E" Layer 3 Progress Message 74 Q.931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 0 (FROM side that originated call ref) Call Reference Value = 0x10-44 Message Type = DISConect (0x45) Information Element = Cause (0x08) Information Element Length = 2 Coding Std = CCITT Locat = Pub Net Serv Local User Cause = Recov on Timer Expiry Cause Decimal Value = 102 HEX 08 02 10 44 45 08 02 82 e6 Figure III-9D. Case "E" Layer 3 Disconnect Message The summary shows that the disconnect message was issued by the class 5 SPCS approximately ten (10) seconds after the call proceeding message was received from the users Class II equipment. According to TR-NWT-001268, references for layer 3 timers, timer T310 is expiring. This timer is usually set for ten (10) seconds, and is initiated when the class 5 SPCS receives a call proceeding message from the user Class II equipment. This timer should have been stopped approximately 0.3 seconds after it was started when the user equipment issued a progress message (record # 49). The purpose of this layer 3 timer (T310) is to limit the time that a SPCS will wait for a response to a connection attempt. In this case, the class 5 SPCS failed to stop this timer, and when it expired the connection attempt was terminated with a disconnect message. A call report was. opened with the WorldCom SPCS manufacturer, Siemens in response to this problem. Siemens enabled a feature on the ISDN access for this circuit, which had been problem. Once the feature was compliance with designed specifically to eliminate this enabled, TR-NWT-001268 with respect to timer T310 was restored, and the customer complaint closed. The next case in this group, Case F depicts a problem encountered with a user in Washington DC that was experiencing difficulties establishing voice connections to specific reported in September of 2001 users in the Washington DC area. The problem was initially and it involved intra switch ISDN to ISDN voice connections. In this instance, user A initiates 75 a voice connection request to user B which is subsequentiy rejected by user B. User A in this case is reporting the problem (fig.III-10). ISDN Setup WorldCom Setup ISDN User A ^ SPCS - Wash. DC UserB Initiates Call Proc Call Proc CLLI: Rejects Conn. WASHDCINDSO Conn. Disconnect Disconnect Request Request ^ ' Figure IH-10. Case "F" Intra Switch Connection Diagram ISDN Service Parameters - A) SPCS Type Nortel Networks DMS 500 class 5 end office - Washington DC. - CLLI : WASHDCINDSO B) Software Load -LLT00. 13 C) Layer 2 protocol TR-TSY-000793 - configured for non-facility associated signaling D) Layer 3 protocol - Telcordia Technology TR-NWT-001268 Customer Class II Equipment A) Type - Mitel - model unknown B) Software Load - unknown C) Layer 2 protocol - unknown - configured for non-facility associated signaling. D) Layer 3 protocol load - Telcordia Technology TR-NWT-001268 Data captures of this connection request were performed (fig. III-2) and the layer 3 data as captures from the initiating interface (user A) is shown in figure III-10a through figure III-10e. 76 Since this connection was an intra switch, ISDN user to ISDN user connection, no SS7 captures are available. Review of the layer 3 captures indicates that the terminating end (user B) is disconnecting this connection request with a cause code 16, normal clearing (fig. III-10c). The previous messages include setup issued from user A (fig. III-10a), and a call proceeding message issued from user B. of A summary these messages with the corresponding time stamps is provided in Table III-4. From this summary, it is clear that timer T310 in user A's equipment is expiring and according to TR-NWT-001268 this is a correct implementation. For this timer to be stopped, user B's equipment must issue a progress, alerting or connect message. Since none of these actions occurred, user A's T310 timer expires, and the connection attempt is subsequentiy disconnected. Record Direction Message Message Time T310 No. Type Stamp Elapsed Time 11 To User B Setup 11:03:27.6850328 13 To User A Call Proc. 11:03:27.8072806 T310 Started 113 To User B Disconnect 11:04:37.8127241 10.0054435 - timer expired 115 To User A Rel. 11:04:37.8569664 117 To User B Rel. Comp. 11:04:37.9650981 "F" Table III-4. Case Summary of Events - User A 77 .931: DMS-100 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 0 (FROM side that originated call ref) Call Reference Value = 0x00-99 Message Type = SETUP (0x05) Information Element = Bearer Capability (0x04) Information Element Length = 3 Coding Std = CCITT Info Trans Cap = Speech Transfer Mode = Circuit Transfer Rate = 64 Kbit/s Layer Id = Layer 1 Lay. 1 Prot = G.711 u-law Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Exclusive D- channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 13 Information Element = Progress Indicator (Oxle) Information Element Length = 2 Coding Std = CCITT Locat = Priv Net Serv Local User Prog Desc = In-Band Info Avail Information Element = Calling Party Number (0x6c) Information Element Length = 11 Number Type = National Number Plan = ? Number Digits = 7034803080 Information Element = Called Party Number (0x70) Information Element Length = 11 Number Type = National Number Plan = 7 Number digits = 7037478500 08 02 00 99 05 04 03 80 90 a2 18 03 a9 83 Od le 02 81 88 6c 0b al 37 30 33 34 38 30 33 30 38 30 70 0b al 37 30 33 37 34 37 38 35 30 30 "F" Figure III-10A. Case Layer 3 Setup Message - User A 78 Q.931: DMS-100 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference = Flag 1 (TO side that originated call ref) Call Reference Value = 0x00-99 Message Type = CALL PROC (0x02) Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Exclusive D-channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 13 08 02 80 99 02 18 03 a9 83 8d "F" Figure III-10B. Case Layer 3 Call Proceeding Message - User A .931: DMS-100 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 = Call Reference Flag 0 (FROM side that originated call ref) Call Reference Value = 0x00-99 Message Type = DISConn (0x45) Information Element = Cause (0x08) Information Element Length = 2 Coding Std = CCITT Locat = Priv Net Serv Local User Cause = Normal Clearing Cause Decimal Value = 16 08 02 00 99 45 08 02 81 90 "F" Figure III-10C. Case Layer 3 Disconnect Message - User A Q.931: DMS-100 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call Reference Flag = 1 (TO side that originated call ref) Call Reference Value = 0x00-99 Message Type = RELease (0x4d) 08 02 80 99 4d Figure III-10D. Case "F" Layer 3 Release Message 79 Q.931: DMS-100 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 = Call Reference Flag 0 (FROM side that originated call ref) Call Reference Value = 0x00-99 Message Type = REL COM (0x5a) 08 02 00 99 5a Figure III-10E. Case "F" Layer 3 Release Complete Message On the surface, it would seem reasonable to pursue this issue with the terminating end user (user B). However, user A initially reported this trouble. In fact, user B was totally unaware that this issue even existed. These conditions would make it difficult to initiate correction for this issue with user B. Closer examination of the setup message issued from user A revealed a curious progress IE (fig. III-10a). User A was setting up this connection and declaring the availability of in band information (i.e. a recording). While this information element is syntactically value, it is highly unusual to encounter one formatted in this manner. This IE was manually decoded to confirm this progress indicator (fig. III-10f). In working this issue with user A's equipment manufacturer, it was discovered that these connection attempts were originated from analog stations connected to the ISDN PBX. It was also discovered that there was a known issue with incorrect progress indicators being used for these types of connection requests. The PBX vendor had a software patch for this, and when implemented, changes the progress indicator ISDN" to "call not end-to-end (fig. III-10g). The connection requests originally reported as a problem now connected without issue. 80 RAW HEX DATA IE 02 81 88 I Data(81h,88h)Data (: IE Length (02h) Progress Indicator BE (leh) HEX Binary Equivalent Description (TR-NWT-001268) 81h 10 0 0 0 0 0 1 till Last Octet of Description Spare Private Net. Serving Local User ITU-T Standard HEX Binary Equivalent Description (TR-NWT-001268) 88h 10 0 0 10 0 0 AAAA AAAA Last Octet of Description In-band Information Pattern Available "F" Figure III-10F. Case Decode of Progress IE 81 RAW HEX DATA IE 02 81 81 I Data(81h,81h)Data (: IE Length (02h) Progress Indicator IE (leh) HEX Binary Equivalent Description (TR-NWT-001268) 81h 10000001 AAAAitttt Last Octet of Description Spare Private Net. Serving Local User ITU-T Standard HEX Binary Equivalent Description (TR-NWT-001268) 81h 10 0 0 0 0 0 1 AAAA AAAA 1 Last Octet ofDescription Call is not end-to-end ISDN "F" Figure III-10G. Case User A Progress IE after Software Change Group IV - Information Mapping evaluated in this thesis involves incorrect The final group of inconsistencies being and ISUP. The data presented in subsequent information mapping between ISDN layer 3 SS7 chapters will show that these inconsistencies occur far less frequentiy than group I, II, or III issues, but they can be some ofthe most difficult to identify and correct. The first example of a group IV issue is depicted in case study G. This trouble was initially reported in December of 2001. An ISDN user in Los Angeles California reported that they 82 could not initiate voice connections to certain specific Pacific Bell ISDN users in the Los Angeles Metropolitan Area. ISDN Service Parameters - A) SPCS Type Siemens EWSD class 5 end office - Los Angeles California - LSAGCAXADSO B) Software Load - Release 17 - Layer 2 protocol - C) TR-TSY-000793 configured for non-facility associated signaling D) Layer 3 protocol - Telcordia Technology TR-NWT-001268 Customer Class II Equipment A) Type Lucent Definity G3 B) Software Load unknown C) Layer 2 protocol unknown - configured for non-facility associated signaling. D) Layer 3 protocol load - Telcordia Technology TR-NWT-001268 Data captures were arranged for connection attempts from the ISDN user in Los Angeles (fig III-2). The OPC for the SS7 ISUP release message indicates the connection request was released from the interconnecting network with a bearer capability not implemented cause code (fig. Ill-lla). This was acknowledged by the WorldCom SPCS (fig.III-llb). 83 3 3 Ch# : RD2 ANSI SS7 Flags :1 Count:l Time:ll:36:18.8293 10000000 3 BIB/BSN 3 1/0 10001111 3 FIB/FSN 3 1/15 3 3 . .010000 SU type/length. . . . MSU16 00 3 Spare 3 0 octet003 Service information * octet , 3 0101 Service indicator. ISUP ISDN User Part 3 ..10 Message priority. . 2 3 10 Network indicator. N National network octet004 Routing label DPC: Net-Clstr-Mbr 3 216-005- 003 OPC: Net-Clstr-Mbr 3 251-141- 004 00000111 SLS 3 7 CIC 3 25 00 spare 3 0 octet013 Message type 3 ' 00001100 Headers H1/H0 3 REL Release 3 ' 00000010 Pointer-> Cause... 3 2 3 ' 00000000 Pointer-> Optional 3 0 3 octet016 Cause Indicators parameter 3 1 3 3 00000010 Parameter length. . 2 ' 3 0001 Location Local private network 1 3 .. .0 spare 0 1 3 .00 Coding standard. . . CCITT standard 1 ' Extension bit 3 1 ' 3 .1000001 Cause value BearerCapabilityNotImplemented 1 ' Extension bit 3 1 Checksum ' CRC 16 3 1001101000110000 hex=9a30 Figure III-11A. Case "G" SS7 ISUP Release Message 3 3 3 Ch#:SDl ANSI SS7 Flags :1 Count :1 time: 11: 36: 18. 931 3 3 11010000 3 BIB/BSN 3 1/80 3 10000001 3 FIB/FSN 3 1/1 3 3 3 ..001011 SU type/length MSU11 3 00 3 Spare 3 0 3 octet003 Service information octet 3 0101 3 Service indicator. J ISUP ISDN User Part 3 3 3 ..10 Message priority. . 2 3 10 3 Network indicator. 3 N National network 3 octet004 Routing label . 3 ' DPC: Net-Clstr-Mbr 251-141-004 3 1 OPC: Net-Clstr-Mbr 216-005-003 3 00110000 1 SLS 48 3 ' CIC 25 3 00 ' spare 0 3 octet013 Message type 3 00010000 1 Headers H1/H0 3 RLC Release Complete 3 Checksum CRC 16 3 0011110001001110 hex=3c4e Figure III-11B. Case "G" SS7 ISUP Release Complete Message The OPC 251-141-004 referenced is a Pacific Bell tandem switch in Los Angeles California. A trouble ticket was opened with Pacific Bell on this issue. Pacific Bell indicated that the release 84 was from the ISDN user. coming terminating The terminating user was releasing this connection request with an invalid element cause code. The information being passed in the SS7 ISUP Initial Address Message (IAM) access transport parameter (octet 33) from Pacific Bell to the terminating ISDN user via an information element was being rejected as invalid. Since Pacific Bell was simply passing on what it received from WorldCom, the trouble report was closed, and the issue referred back to WorldCom. WorldCom then began a detailed analysis of how the SS7 ISUP Access transport parameter was being constructed in its Los Angeles class 5 local SPCS. The access transport parameter, octet 33 of the SS7 ISUP IAM (fig. III-l lc) is used to convey information on the state, or progress of a connection request from one network to another. In the case of this connection request, the WorldCom class 5 SPCS was formatting this parameter based on what it received from the ISDN user originating the connection request via a layer 3 setup message. The field in the setup message, which provides the information that is mapped into the SS7 ISUP IAM access transport parameter, is the progress indicator. Figure III-10d depicts the progress indicator IE that was provided by the originating ISDN users PBX. The values, which should be directly mapped into the SS7 ISUP IAM, should be exacdy the same as the hexadecimal data provided in this IE (le 02 85 83). Investigating the access transport parameter, octet 33 of the IAM it is clear that the WorldCom class 5 Siemens SPCS is not directiy replicating this value. The WorldCom switch is formatting values of le 02 03 05 00 le 02 85 83 into the access transport parameter (fig. III-llc). This is invalid, and the terminating end Pacific Bell ISDN user's equipment recognizes this, and rejects any connection request containing this information (fig. III-l lb). 3 3 octet033 ISUP Optional Parameter 3 3 3 00000011 3 Parameter name.... Access transport 3 3 3 3 00001001 Parameter length. . 9 3 3 3 3 Info, elements.... le 02 03 05 00 le 02 85 83 3 3 octet044 ISUP Optional parameter "G" Figure III-11C. Case SS7 ISUP Initial Address Message -Access Transport 85 Information Element = Progress Indicator (Oxle) Information Element Length = 2 Coding Std = CCITT Locat = Priv Net Serv Local User Prog Desc = Orig Addr non-ISDN Hex le 02 85 83 Figure III-11D. Case "G" Layer 3 Progress Indicator A call report was opened with Siemens EWSD, and a software patch was written to correct this condition. Siemens recognized the problem, agreed that it was inconsistent and developed a software patch to correct this condition. Once this patch was implemented, the issue was corrected. A data capture of the reformatted access transport parameter is shown in figure III- lle. 3 octet033 ISUP Optional Parameter 3 3 3 00000011 Parameter name.... 3 Access transport 3 3 3 3 3 00001001 Parameter length. . 4 3 3 Info, elements.... 3 le 02 85 83 3 3 octet044 ISUP Optional parameter 3 Figure III-11E. Case "G" Access Transport (post fix) The final case study, which will be examined in this group, case study "H", was a trouble initially reported in December of 2001. An ISDN user in Philadelphia Pennsylvania was unable to initiate voice connections to another ISDN user outside the continental United States. ISDN Service Parameters A) SPCS Type - Siemens EWSD class 5 end office - Philadelphia Pennsylvania B) Software Load - Release 17 C) Layer 2 protocol - TR-TSY-000793 - configured for facility associated signaling D) Layer 3 protocol - Telcordia Technology TR-NWT-001268 Customer Class II Equipment 86 A) Type unknown B) Software Load unknown C) Layer 2 protocol - unknown - configured for facility associated signaling. D) Layer 3 protocol load - Telcordia Technology TR-NWT-001268 This issue was referred to WorldCom local services group by WorldCom's long distance group. The ISDN user originating these connection requests has WorldCom as their ISDN service provider as well as WorldCom long distance as their international carrier. The long distance group had identified that the terminating end user could not accept connection requests, which were set up requesting an information transfer capability of 3.1 KHz audio. The long distance group had detected this information transfer rate on connection requests via SS7 protocol captures taken in the long distance network. Protocol analyzers were attached (fig. III-2) to perform data captures of SS7 and layer 3 messaging for these connection attempts. The SS7 ISUP IAM captured in test connection attempts monitored verified the 3.1 KHz information transfer rate observed by the long distance group (fig. III-12a). The layer 3 setup message which generated this SS7 IAM, however indicates that an information transfer rate of speech (fig. III-12b). The bearer capability IE from the user's setup message was manually decoded (fig. III-12c) to confirm the information transfer rate. Indeed, the transfer rate provided in the setup was speech. 87 octet004 Routing label DPC: Net-Clstr-Mbr 244-001-065 OPC: Net-Clstr-Mbr 216-003-002 00110100 SLS 52 CIC 1373 00 spare 0 octet013 Message type 00000001 Headers HI/HO IAM Initial Address octet014 ISUP Nature of connection indicators parm 00 Satellite No satellite circuit in connection 00. . Continuity check. . Continuity check not required . . .0 Echo suppressor... Outgoing half echo cntrl device not included 000 spare 0 ' octet017 ISUP Calling party s category parameter 00001010 Clg party category Ordinary calling subscriber 00000011 Pointer->User info 3 00000110 Pointer-> Called # 6 00001110 Pointer-> Optional 14 octet021 ISUP User service information parameter 00000011 Parameter length. . . .10000 UnfoXfrCapability 3. 1 KHz audio 00 ICodingStandard. . . CCITT standard lExtension bit. . . . Last Octet . .10000 2InfoXfr-Rate 64 Kbit/s 00 2Transfer mode .... Circuit mode 2Extension bit. . . . Last Octet . .00010 3UserInfoLayerlPrtc mu-law 01. 3Layer 1 Ident .... User Information Layer 1 Protocol 3Extension Bit. . . . Last Octet Figure III-12A. Case "H" SS7 IAM Showing 3.1 Khz Transfer Rate 88 .931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call = Reference Flag 0 (FROM side that originated call ref) Call Reference Value = 0x02-00 Message Type = SETUP (0x05) Information Element = Bearer Capability (0x04) Information Element Length = 3 Coding Standard = CCITT Info Trans Cap = Speech Transfer Mode = 64-kbps, Circuit Layer 1 User Info = u-law Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Exclusive D-channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 9 Information Element = Progress Indicator (Oxle) Information Element Length = 2 Coding Std = CCITT Locat = Priv Net Serv Local User Prog Desc = Not End- End ISDN Information Element = Calling Party Number (0x6c) Information Element Length = 11 Number Type/ Plan = Nat. ISDN Digits = 6102492343 Information Element = Called Party Number (0x70) Information Element Length = 16 Nmbr Type/Plan = Unknown Digits = 011886287923258 HEX 08 02 02 00 05 04 03 80 90 a2 18 03 a9 83 89 le 02 81 81 6c 0b al 36 31 30 32 34 39 32 33 34 33 70 10 80 30 31 31 38 38 36 32 38 37 39 32 33 32 35 38 Figure III-12B. Case "H" Layer 3 Setup Message- Speech Transfer Rate 89 Raw hex from data capture Bearer capability IE (04 hex) IE Length (03 hex) Data Values (80 hex, 90 hex, a2 hex) 04 03 80 90 a2 HEX Binary Equivalent Description (TR-NWT-001268) 80h 10 0 0 0 0 00 tttt AAAA Last Octet of Description TTII-T ream Standard Speech Figure HI-12C. Case "H" Bearer Capability IE Decode On the surface, it would appear that the WorldCom class 5 SPCS was not correcdy bearer IE into octet the mapping the information transfer rate from the layer capability 21, user service information parameter correcdy. An optional progress message was provided by the user in the layer 3 setup message declaring this connection attempt to be non end-to-end ISDN. The manual decode of this IE confirmed this (fig. III-12d). Test simulation done from an ISDN test set connected to the Philadelphia SPCS with this IE removed (fig. III-12e) identified that it was the presence of this IE, which caused the Siemens SPCS to incorrectiy format user service information parameter of the SS7 IAM (fig. III-12f). 90 RAW HEX DATA IE 02 M 81 Data(81h,81h) IE Length (02h) Progress Indicator (leh) HEX Binary Equivalent Description (TR-NWT-001268) 81h 10 0 0 0001 Last Octet of Description Spare Private Net. Serving Local User ITU-T Standard HEX Binary Equivalent Description (TR-NWT-001268) 81h 10 0 0 0 0 0 1 AAAA AAAA Last Octet of Description Call is not end-to-end ISDN Figure III-12D. Case "H" Progress IE Decode 91 Q.931: NI-2 Protocol Discriminator = 0x08 (Q.931 Call Control) Call Reference Length = 2 Call = Reference Flag 0 (FROM side that originated call ref) Call Reference Value = 0x02-00 Message Type = SETUP (0x05) Information Element = Bearer Capability (0x04) Information Element Length = 3 Coding Standard = CCITT Info Trans Cap = Speech Transfer Mode = 64-kbps, Circuit Layer 1 User Info = u-law Information Element = Channel Identification (0x18) Information Element Length = 3 Interface Id Present = Implicit Interface Type = Primary Channel = Exclusive D-channel = No Info Chan Selection = As Indie Coding Std = CCITT Number/Map = Number Channel Type = B Channel Number = 9 Information Element = Calling Party Number (0x6c) Information Element Length = 11 Number Type/Plan = Nat. ISDN Digits = 6102492343 Information Element = Called Party Number (0x70) Information Element Length = 16 Nmbr Type/Plan = Unknown Digits = 011886287923258 08 02 02 00 05 04 03 80 90 a2 18 03 a9 83 89 6c 0b al 36 31 30 32 34 39 32 33 34 33 70 10 80 30 31 31 38 38 36 32 38 37 39 32 33 32 35 38 "H" Figure III-12E. Case Layer 3 Setup Message with Progress IE Removed 00000001 Headers H1/H0 IAM Initial Address octet014 ISUP Nature of connection indicators parm 00 Satellite No satellite circuit in connection 00.. Continuity check. . Continuity check not required . . echo cntrl not . . .0 Echo suppressor. Outgoing half device included 000 spare 0 octet015 ISUP Forward call indicators parameter octet021 ISUP User service information parameter 00000011 Parameter length. . 3 . .00000 UnfoXfrCapability Speech 00 ICodingStandard. . . CCITT standard lExtension bit. . . . Last Octet . .10000 2InfoXfr-Rate 64 Kbit/s 00 2Transfer mode. . . . Circuit mode 2Extension bit. . . . Last Octet . .00010 3UserInfoLayerlPrtc mu-law 01. 3Layer 1 Ident. . . . User Information Layer 1 Protocol 3Extension Bit. . . . Last Octet Figure III-12F. Case "H" SS7 IAM Showing Speech Transfer Rate 92 The layer 3 call setup message from the user's Class II equipment is correct. The IE being inserted is the result of the connection attempt originating from an analog station (hence, the connection is not end-to-end ISDN). A call report was opened with WorldCom's SPCS manufacturer, Siemens who identified this inconsistency. Since speech and 3.1 KHz audio are both valid information transfer rates for a non IDSN connection, it was a difficult and time consuming task convincing Siemens to correct this issue without charging WorldCom for development of the software needed to correct this problem. Siemens had planned to correct this problem with the next subsequent release of their generic software load for the EWSD SPCS. Since this release is not scheduled until midyear 2002, Siemens wrote a patch to correct this issue. When it was applied, the ISUP IAM information transfer rate was correcdy complied to indicate the intended transfer capability in the user's setup message (Speech). 93 Chapter IV CASE STUDY ECONOMIC EVALUATION The inconsistencies associated with implementation of layer 3 ISDN protocol depicted in this thesis have a significant negative economic impact on users, network providers and equipment manufacturers. These inconsistencies slow the deployment of ISDN, and can create an atmosphere of uncertainty within the user community as to the viability of this network architecture. The purpose of this thesis was not to perform a extensive economic analysis of economic impact of layer 3 inconsistencies. However, an estimation of these costs can be determined from the case study evaluations provided in this thesis. These cost estimations are realistic, and conservative. Their presentation in this thesis will further convey the significance of ISDN layer 3 implementation inconsistencies. Each group of inconsistencies describes a general category of interoperability issues, which share common traits. Each group requires varying degrees of technical support to properly address. This support often includes user consultants, network service providers and equipment manufactures support engineers. As the level of complexity increases, so does the level of technical support required to address the issue. Level I generally relates to basic desk" technician or "help type technical support. Level II usually involves senior technician or associated with Senior Engineer targeted at engineering support. Level III generally is support, specific hardware or software abnormalities. Level IV support usually involves major redesign. These issues are interoperability, which lead to code rewrites or harder protracted, for correction. take a long time to isolate, and determine responsibility problems requires a detailed Evaluating the economic impact of layer 3 interoperability the level of involvement all parties understanding of the problems encountered, by associated, provided and the steps taken to resolve the issue. The detailed case evaluations in this thesis the process are used as the starting point for this economic analysis. They provide step-by-step resolved. Simple arithmetic and by which a problem was identified, trouble shot, isolated and "hard" some basic assumptions can provide most of the cost associated with these problems. 94 "soft" There are other costs, which are a bit more ambiguous to define. These costs are associated with lost revenue, or increased expense related to changes in operational procedures around" associated with "work or implementation of stopgap measures required until the issue is permanendy resolved. To obtain the total scope of the economic impact of these issues, one needs to understand both the individual cost on a case-by-case basis, and the frequency of occurrence. Over the past three (3) I have worked as a Senior Network Engineer with a company (WorldCom) that provides Primary Rate ISDN service. I have seen the deployment of coundess ISDN services, and worked on resolving numerous layer 3 interoperability issues. This has afforded me a unique perspective on the different types of interoperability issues; their complexity, frequency, and the effort required by users, network providers, and equipment manufactures to correct them. I have used this experience as a basis for establishing the groupings provided in chapter III. Typical examples of cases for each grouping were evaluated to form a better understanding " of the scope of work required. This understanding will lead to determining the "hard cost "soft" associated with issue resolution for each group. The intangible or can be estimated for the groups where it is applicable, based on an understanding of the problem as it impacted the users, service providers and equipment manufactures involved. The data in table IV-l represents the number of occurrences of layer 3 issues by group, which were reported to WorldCom during the calendar year 2001. By simply multiplying the number of occurrences (table IV-l) by the average cost associated with each group, the total WorldCom can determined. Since economic impact of these layer 3 issues addressed by be WorldCom is only one of many ISDN service providers, these costs only represent a portion ofthe total scope ofthe issue in North America. Group I Group II Group III Group IV Total % Total % Total Total 158 60.5 82 31.4 19 7.3 2 0.8 Table IV-l. Layer 3 Trouble Reports: 1/1/01 through 12/31/01 95 All economic analysis will be based on data obtained from actual trouble reports from January 2001 through December 31, 2001. Technical support costs for levels 1 through 4 are based on costs used by my company and typical vendor data compiled during this time frame. These costs include processing trouble reports, and engaging the proper level of technical and administrative expertise to address each group of issues. Based on this data, the following average costs will be calculated for each group where they are applicable: Average cost - User Technical Consultant Level I through Level IV Average cost User Equipment Manufacturer - Level I through Level IV Average cost Service Provider - Level I through Level IV Average Cost - Service Provider Equip. Man. - Level I through Level IV Average Lost Revenue / increased expense - User 96 Group I Case Analysis "A" Resolution of case required the involvement of both level I and level II technical support. The user was impacted with a 16-hour service outage, which was approximated based on data provided by the customer's service account team within WorldCom. The costs incurred by each participant in the trouble isolation, and resolution process is depicted in Table IV-2. Expense Type Tech Level Hours Cost/Hour Total User 1 3 $75 $225 Notel $500 TOTAL $725 User Consultant 1 3 $75 $225 TOTAL $225 Service Provider 1 4 $75 $300 2 1 $100 $100 TOTAL $400 Table IV-2. Case "A" Costs Note 1: Soft costs associated with rerouting inbound traffic to toll free numbers - Source: WorldCom account team 97 "B" Resolution of case required the involvement of both level I and level II technical support. The user was impacted with a 10-hour service outage and incurred some charges for redirecting this traffic as a result of PBX programming changes, and higher usage fees. The costs incurred by each participant in the trouble isolation, and resolution process is depicted in Table IV-3. Expense Type Tech Level Hours Cost/Hour Total User 1 2 $75 $150 Note 2 $1,000 TOTAL $1,150 User Consultant 1 4 $75 $300 2 2 $100 $200 TOTAL $500 Service Provider 1 6 $75 $450 2 2 $100 $200 TOTAL $650 Table IV-3. Case "B" Costs Note 2: Soft cost associated with moving outbound international calls to a backup service Source: customer 98 Group II - Case Analysis "C" Resolution of case required the involvement of both level I and level II technical support. The user was unable to initiate any international connections for a period of several days. The costs incurred by each participant in the trouble isolation, and resolution process is depicted in Table IV-4. Expense Type Tech Level Hours Cost/Hour Total User 1 3 $75 $225 Note 3 $800 TOTAL $1 ,025 User Consultant 1 6 $75 $450 2 4 $100 $400 TOTAL $850 Service Provider 1 6 $75 $450 2 3 $100 $300 TOTAL $750 Table IV-4. Case "C" Costs Note 3: Soft Costs associated with rerouting calls to specific exchanges to alternate facilities Source: customer and WorldCom account team 99 "D" Resolution of case required the involvement of both level I and level II technical support The issue involved joint troubleshooting between a local service provider, other common carrier, a user consultant and a user equipment provider. Coordination of efforts between all the associated parties was cumbersome and costiy. The costs incurred by each participant in the trouble isolation, and resolution process is depicted in Table IV-5. Expense Type Tech Level Hours Cost/Hour Total User 1 4 $75 $300 TOTAL $300 User Consultant 1 6 $75 $450 2 8 $100 $800 TOTAL $1 ,250 Service Provider 1 12 $75 $900 2 8 $100 $800 TOTAL $1,700 Table IV-5. Case "D" Costs 100 Group HI - Case Analysis "E" Resolution of case required the involvement of level I, level II and level III technical support The issue was related to incorrect timer handling on the part of the service providers stored program controlled switch (SPCS). The issue became protracted due to the difficulty determining scope of responsibility between the service provider and the manufacturer of their SPCS. The user was affected as well, due to poor service and excessive temporary measures, which were required to transfer calls to the satellite hospital locations. The costs incurred by each participant in the trouble isolation, and resolution process is depicted in Table IV-6. Expense Type Tech Level Hours Cost/Hour Total Serv. Prov. 1 4 $75 $300 Equip. Man. 2 2 $100 $200 TOTAL $500 User 1 10 $75 $750 Note 4 - - $5,000 TOTAL $5,750 User Consultant 1 12 $75 $900 2 6 $100 $600 TOTAL $1,500 User Equip. Man 1 20 $75 $1,500 2 6 $100 $600 3 4 $175 $700 TOTAL $2,800 Serv. Provider 1 20 $75 $1,500 2 10 $100 $1,000 TOTAL $2,500 Table IV-6. Case "E" Costs Note 4: Soft coats associated with routing satellite PBX traffic to an attendant - Source: Customer PBX vendor 101 "F" Resolution of case required the involvement of level I, level II and level III technical support. The issue was determined to be layer 3 timer expiry related to layer 3 message on the end processing terminating users equipment, user "B". A correction was identified and implemented the user by originating user, "A". The costs incurred by each participant in the trouble isolation, and resolution process is depicted in Table IV-7. Expense Type Tech Level Hours Cost/Hour Total Serv. Prov. 1 6 $75 $450 Equip. Man. 2 2 $100 $200 TOTAL $650 User 1 20 $75 $1,500 2 18 $100 $1 ,800 TOTAL $3,300 User Consultant 1 10 $75 $750 Note 5 $2,500 TOTAL $3,250 User Equip. Man 1 15 $75 $1,125 2 10 $100 $1,000 3 3 $175 $525 TOTAL $2,650 Serv. Provider 1 12 $75 $900 2 6.5 $100 $650 TOTAL $1,550 Table IV-7. Case "F" Costs Note 5: Soft Costs associated with lost revenue due to inability to call specific clients - Source Customer 102 Group TV - Case Analysis "G" Resolution of case required the involvement of all levels of technical support available. This issue involved incorrect mapping of layer 3 IE's into the SS7 access transport. The problem was and complex, required coordination between all parties associated with the ISDN service plus another carrier used for transport across the PSTN. The costs incurred by each participant in the trouble isolation, and resolution process is depicted in Table IV-8. Expense Type Tech Level Hours Cost/Hour Total Serv. Prov. 1 10 $75 $750 Equip. Man. 2 4 $100 $400 3 4 $175 $700 4 20 $250 $5,000 TOTAL $6,950 User 1 15 $75 $1,125 Note 6 $2,500 TOTAL $3,625 User Consultant 1 10 $75 $750 2 4 $100 $400 TOTAL $1,150 User Equip. Man 1 6 $75 $450 2 6 $100 $600 3 4 $175 $700 TOTAL $1,750 Serv. Provider 1 50 $75 $3,750 2 45 $100 $4,500 TOTAL $8,250 Table IV-8. Case "G" Costs Note 6: Soft cost associated with rerouting traffic to specific codes Source: customer 103 "H" Resolution of case required the involvement of all levels of technical support available. This issue involved incorrect mapping of the layer 3 call type into the SS7 ISUP information transport rate. The problem was complex, and required coordination between all parties associated with the ISDN service plus another carrier used for transport across the PSTN. The issue impacted the user with additional expense. The costs incurred by each participant is depicted in Table IV-9. Expense Type Tech Level Hours Cost/Hour Total Serv. Prov. 1 4 $75 $300 Equip. Man. 2 2 $100 $200 3 2 $175 $350 4 20 $250 $5,000 TOTAL $5,850 User 1 35 $75 $2,625 Note 7 $10,000 TOTAL $12,625 User Consultant 1 4 $75 $300 2 4 $100 $400 TOTAL $700 User Equip. Man 1 2 $75 $150 2 1 $100 $100 3 1 $175 $175 TOTAL $425 Serv. Provider 1 65 $75 $4,875 2 51 $100 $5,100 TOTAL $9,975 Table IV-9. Case "H" Costs Note 7: Soft cost associated with lost revenue, and added expense in using other carriers for international calls Source: Customer and WorldCom account team 104 From these cost summaries it is clear that the layer 3 inconsistencies depicted in the case studies for each group have a significant economic impact on the ISDN community. The average costs incurred for each group have been complied in tables IV-10, through IV-13. Per occurrence, users, consultants, equipment manufacturers and service providers to correct a typical Group I layer 3 inconsistencies expend an average of $1,825. For group II this cost rises to $3,963. For group III the cost average is $12,225. Finally, for each occurrence of a group IV layer 3 inconsistencies, an average of $25,600 will be spent to correct the issue, and cover the associated costs related to rerouting of calls etc. Group I Expense Type Case A Case B Total Average User - hard costs $225 $1 50 $375 $1 88 - User soft costs $500 $1 ,000 $1 ,500 $750 User Consultant $225 $500 $725 $363 User Equip. Man Service Provider $400 $650 $1,050 $525 Serv. Prov. Equip. Man. Cumulative for Group $3,650 $1 ,825 Table IV-10. Group I Average Expenses 105 Group II Expense Type CaseC Case D Total Average User - hard costs $225 $300 $525 $263 User - soft costs $800 $800 $400 User Consultant $2,900 $1 ,250 $4,150 $2,075 User Equip. Man Service Provider $750 $1 ,700 $2,450 $1 ,225 Serv. Prov. Equip. Man. Cumulative for Group $7,925 $3,963 Table IV-11. Group II Average Expenses Group III Expense Type Case E Case F Total Averaqe User - hard costs $750 $750 $1,500 $750 User - soft costs $5,000 $2,500 $7,500 $3,750 User Consultant $1,500 $1,550 $3,050 $1,525 User Equip. Man $2,800 $2,650 $5,450 $2,725 Service Provider $2,500 $3,300 $5,800 $2,900 Serv. Prov. Equip. Man. $500 $650 $1,150 $575 Cumulative for Group $24,450 $12,225 Table IV-12. Group III Average Expenses 106 Group IV Expense Type Case G Case H Total Average User - hard costs $1,125 $2,625 $3,750 $1,875 User - soft costs $2,500 $10,000 $12,500 $6,250 User Consultant $1,150 $700 $1,850 $925 User Equip. Man $1,750 $425 $2,175 $1,088 Service Provider $8,250 $9,975 $18,225 $9,113 Serv. Prov. Equip. Man. $6,850 $5,850 $12,700 $6,350 Cumulative for Group $51,200 $25,600 Table IV-13. Group IV Average Expenses Based on these and of expenses, the number troubles per group reported during the time frame over evaluated, 800,000 dollars was spent in 2001 resolving layer the 3 reported by WorldCom users alone (table IV-14). Expense Type Group I Group II Group III Group IV Total AH User - hard costs $29,704 $21,566 $14,250 $3,750 $69,270 User- soft costs $118,500 $32,800 $71,250 $12,500 $235,050 User Consultant $57,354 $86,100 $28,975 $1,850 $174,279 User Equip. Man $51,775 $2,176 $53,951 Service Provider $82,950 $100,450 $55,100 $18,226 $256,726 Serv. Prov. Equip. Man. $10,925 $12,700 $23,625 Totals $288,508 $240,916 $232,275 $51,202 $812,901 Table IV-14. Annual Expense by Group 107 These studies, and the costs associated with them were based on actual reports for services provided by WorldCom. WorldCom is a competitive local exchange carrier (CLEC), which operates a predominantiy digital network, and has featured ISDN as a service delivery since 1993. Other large CLECs, incumbent local exchange carriers (ILECS) such as Verizon, Bell South, southwestern Bell and SBC communications and long distance carriers such A.T. and T, and Sprint also provide primary rate ISDN service. This would suggest that the annual expense associated with layer 3 ISDN problems presented in this thesis is but a small portion of the total annual expensed incurred nation wide. Exacdy what percentage of the national total these figures represent is difficult to estimate and is beyond the scope of this thesis. It is clear that the cost depicted in this analysis is staggering and even more shocking when one realizes that the amount expended to correct layer 3 interoperability issues identified in this thesis is only a portion ofwhat is expended annually in North America. An analysis of this data yields some interesting trends. The expenses presented in this chapter represent real expenditures related to isolating and correcting layer 3 issues. In many instances, parties will be reimbursed for costs associated with a particular issue if it can be determined that one specific party was at fault. Service providers will often cover the costs of result of a SPCS. the ISDN users they support if the issue can be determined to be the And, to the class III CPE providers will also reimburse ISDN users if the inconsistency is isolated CPE. In spite of this cross allocation of costs, we can analyze some trends, and state some key observations from this data. Table IV-l depicts the frequency of occurrence for the layer 3 issues identified in this I or II issues. Let us thesis. This data shows that over 90% of all cases involve Group Group parties involved in these the ISDN the consider the three (3) main issues, namely users, providers. three entities will consultants that support the users and the ISDN service These I and II issues and will always incur some almost always be involved in trouble shooting group determined to be at fault. Table IV-l 5 depicts the expense regardless of who is ultimately type. percentage oftotal group expense-by-expense 108 Expense Type Group 1 Group II Group III Group IV User - hard costs 10.5% 9.0% 6.1% 7.3% User - soft costs 41.3% 13.6% 30.7% 24.4% User Consultant 19.3% 35.7% 12.5% 3.6% User Equip. Man 22.3% 4.1% Service Provider 28.9% 41.7% 23.7% 35.6% Serv. Prov. Equip. Man. 4.7% 24.8% Table IV-15. Percentage ofTotal Annual Group Expense by Type The component of largest Group I user costs are the soft costs. In general, these costs are associated with work around processes and procedures. These include rerouting traffic, using alternate carriers and services, and the added burden placed on call center attendants. User hard costs (actual PBX or station programming done by the user) represent a much less significant amount. By comparison, in Group II the hard costs for the user are roughly the same as Group I, with the predominant cost component shifting to the User Consultant. This is due to the increased complexity of Group II issues. Most of the time, easy work around and temporary user initiated fixes are not applicable. This results in an increased dependence on consulting firms or equipment vendors. From the service provider's standpoint, the difference in complexity of Group II issues generally requires involvement of a higher level of technical expertise. More than 65% of the total cumulative expense related to correcting layer 3 issues is related to working Group I and II issues (fig. IV-16). % % of Total Group Occurrence Total Expenses Expenses 1 60.5 $288,508 35.5 II 31.4 $240,916 29.6 III 7.3 $232,275 28.6 IV 0.8 $51,202 6.3 ALL $812,901 Table IV-16. Percentage ofTotal Annual Expense by Group Group III has a frequency of occurrence of just over 7%, yet this group alone accounts for of all IV-16). soft nearly 30% of the total expense related to layer 3 issues types (table User costs are high due to lost revenue related to outages and changes in procedures due to the 109 impact on their business. This group of inconsistencies requires engaging very high level tech support is on the part of the user Consultant, and the Service Provider. These issues can become difficult to trouble shoot, due to the problem timer issues present in separating cause and effect. The degree of frequency ofthese issues makes them a significant component of the total cost associated for all groups. Group IV issues are rare, occurring in less than 1% of all reported cases, but they require the highest degree of technical support from all parties. Even though these issues occur infrequentiy, they still represent over 6% of the total cost associated with all groups. This issues are usually isolated to a major problem with the implementation of the layer 3 protocol, and are the most difficult to isolate, and identify fault. They are protracted, and at times go unsolved because of the difficulty in convincing a party to accept the burden of expense needed to correct the problem, group represents the need for software for the layer 3 issues identified in this thesis. This data shows that over 90% of all cases involve Group I or Group II issues. 110 Chapter V SUMMARY AND RECOMMENDATIONS This thesis deals with the interoperability issues, which arise when ISDN layer 3 protocols are not implemented accurately and consistendy. I have provided a background, detailed case and examples, explored the relative costs associated with correcting these inconsistencies once they are identified and reported as network troubles. These costs become part of the operational expenses associated with ISDN, and as demonstrated in chapter IV, can run into the millions of dollars annually. ISDN is a radical departure from the conventional user to network interfaces, which have been used for decades. ISDN provides a feature rich, sophisticated packet switched signaling system unlike any other, which has been deployed for general telephony applications. The standards, which govern the operation of ISDN, are more complex, and are still in a state of evolution. Conventional in-band interfaces by comparison are simple, mature technologies. There is a much broader, deeper experience base with implementation of these technologies when compared to ISDN. ISDN users, service providers, and equipment manufactures simply have less experience with ISDN from the implementation and repair perspectives. I have seen indications over the past 3 years that demonstrate that as deployment of ISDN continues to grow, the experience issue will be diminished to the point where it is no longer a contributing factor. While the quantity of reported layer 3 problems may be rising, the percentage of installations where they are a factor is dropping. We are simply deploying more ISDN than ever before. In the near term, I believe that there are steps that can be taken which will reduce the expense related to layer 3 interoperability issues. The recommendations advanced in this chapter will deal with ways to reduce the cost associated with layer 3 interoperability problems. The focus now should be on how best to avoid the conditions, which lead to layer 3 problems. Ideally, if one could identify every condition, which increases the potential for problems before the ISDN service is activated, one might be able to avoid these issues all 111 together. In this way, the expense associated with correcting these problems would no longer be a component of the total operational costs associated with primary rate ISDN deployment Cost avoidance can be in large controlled by both the end users and service providers. The selection of equipment, applications, and service providers made by the users will play a large role in how successful the ISDN implementation will ultimately be. Equally important are the pre-installation configuration and testing verification performed by the service provider. Based on the case study analysis presented in this thesis, I believe that there are five (5) main keys to successful ISDN deployment. If the ISDN user and service provider follow these keys the probability of encountering these layer 3 inconsistencies will be gready reduced. They will be described and presented as recommendations in this chapter. The first key is to understand what ISDN is, and the importance of layer 1 in the ISDN protocol suite. While this thesis was limited to layer 3, one would be remise in neglecting the importance of layer 1. Good reliable digital connectivity is the foundation for primary rate ISDN. There are still regions of the country where basic Tl services are somewhat unreliable. ISDN will not cure bad facilities. Users should ask potential service providers details about the Tl facility. Length and type of the Tl transport facility (metallic/optical) are important. The longer the metallic portion of the circuit it, the more susceptible it is to signal degradation. Circuits with a higher percentage of fiber optics generally perform better than those, which have a larger metallic component. Layer 1 forms the highway for layers 2 and 3 to ride on, and ride" glass generally gives a "smoother than copper. Service providers should perform extensive pre-installation facility testing to insure the integrity of the physical layer. The second key is to understand the capabilities of the user Class II customer premise equipment (CPE). Group I and II issues involve predominancy CPE configuration issues. These two groups alone account for 92% of all layer 3 trouble reports. They also account for over 66% of all expenses related to layer 3 interoperability issues and the user component cost in both of these groups is quite significant. Most Class II CPE manufactures now have ISDN capabilities. Large and small manufactures alike now provide offerings from a few hundred dollars to tens of thousands of dollars. Many manufacturers offer procedures to migrate from traditional switched services to ISDN. These arrangements sometimes involve the additional "sit" of adjunct processors, which between older analog station equipment and the ISDN 112 service. This arrangement adds complexity, and generally offers limited performance. It does allow users to extend the usefulness of older PBX systems, which may represent a significant capitol investment. can This create a myriad of layer 3 problems and should be carefully evaluated prior to implementation. Users need to fully understand the diagnostic capabilities of the CPE under evaluation. Even the least expensive ISDN CPE has the capability to perform layer 3 data captures. Understanding these capabilities can help avoid the use of cosdy technical consultants. Users should also ask potential equipment providers for demonstrations and examples of successful deployments of systems, which are similar to what is being planned. In light of the cost associated with correcting layer 3 issues after installation, time and energy spent up front understanding the Class II equipment to be deployed will help reduce or eliminate the cost associated with correcting layer 3 issues after installation. The third key is to understand the capabilities and limitations potential ISDN service providers. Group III issues are split between class III equipment and the service provider's SPCS. While Group III issues account for only about 7% of all reported troubles, they represent over 27% of the total expense for all layer 3 issues. ISDN is a marriage between the Class II customer premise equipment (CPE) that the user selects and the stored program controlled switching system (SPCS) that the service provider has deployed. Knowledge of the service provider's hardware and software will aid the user in configuring the Class II CPE selected. Standards greatiy aided the deployment of ISDN, but we are not yet at the "plug and play" level. There are still examples of Class II CPE and SPCS's, which simply do not work well together in ISDN applications. The fourth key is simplicity. Simple operations tend to reduce the probability of encountering Group IV problems. Inese issues occur very infrequendy, but when they do, they are the most difficult, and individually the most cosdy. Users need to understand the planned applications and how they interact with ISDN layer 3. Trouble reports, which comprise Group II, are rich with examples where optional information elements (IE's) were incorporated into layer 3 messages and caused failures because a network element somewhere the information provided. along the connection path could not correcdy interpret The important point here is that less can actually be more. Equipment that provides simple, clean messaging to initiate, establish, and tear down a connection are generally best. Users should 113 "typical" investigate layer 3 data captures generated from operational systems similar to what is being planned. Decode the setup messages and compare them with the layer 3 standards. If there are items present which are not needed (optional IE's) they could be a source of concern later on. Since problems associated with group II accounted for nearly $200,000 annually for the sample set represented in this thesis, any up front effort, which minimizes complexity, will contribute gready in avoiding these costs. The fifth and final key to avoiding the conditions which lead to layer 3 interoperability problems is to thoroughly test before accepting ISDN service from a prospective provider. Generally, there are two acceptance tests which are performed for any primary rate ISDN acceptance, the facility test and the service test. The facility test involves testing the Tl link. back" Some providers will place the Tl facility in a "loop mode and run extensive sets of test patterns for periods of 24 to 48 hours over the transport system. The purpose of these tests is to stress the facility, and identify any design flaws or configuration mismatches which may lead to intermittent problems. Users need to understand how the prospective service provider intends to qualify the transport facility before actually activating the ISDN service. Finally, prior to actual ISDN service activation, users should have a test plan prepared which identifies every type of connection envisioned for the ISDN service, and a means to verify that these connections can be made. While connection testing is underway, layer 3 data captures should be made to verify setup parameters and results. These data captures will then form a baseline ofperformance at time of activation. This is important for two reasons: 1) It demonstrates how the connections were established. The entire layer 3 messaging from the Class II equipment and the SPCS are recorded showing what worked and what didn't. This is invaluable if on the spot analysis is needed to determine why something didn't work. 2) Hardware and software in both the Class II equipment and the SPCS are subject to change. The service provider constandy upgrades software in the SPCS, as does the Class II equipment manufacturer, often times with out advance notice. If something stops working which previously had been demonstrated to work, new data captures can be obtained and compared with the original captures to determine what has changed. 114 there are items to concerned Clearly be during the next few years while the user community gains experience and attains a higher comfort level with ISDN. The data analysis provided in this thesis has identified specific actions, which are recommended to prospective ISDN users. Implementation of will these processes help reduce the cost associated with deploying ISDN. Based on this analysis, I can make the recommendations to upper management at WorldCom. testing" 1) Modify the Tl acceptance procedure to include "stress Tl circuits to remote loop backs, running quasi random, 55 octet, 1 in 8, and 3 in 24 patterns for no less than 12 hours, and preferably 24 hours. This will help reduce the cost associated with chronic layer 1 issues, which are often incorrecdy diagnosed as layer 3 problems. 2) Encourage WorldCom sales to identify the users class III equipment by model number, hardware and software revisions. This will enable WorldCom provisioning to utilize predetermined values when designing software to implement primary rate ISDN. This will help reduce the occurrence of Group I and Group II issues which are often caused by configuration mismatches. 3) Encourage WorldCom sales to identify the anticipated user applications. This will allow WorldCom field installation to pretest these applications prior to user acceptance. It also will flag any known interoperability issues prior to actual service activation. This will help reduce the occurrence of Group III and Group IV issues which often surface when unique customer applications are evoked over the ISDN service. 4) Perform layer 2 and 3 data captures at the time of installation. This will verify messaging and conformity during the test and turn up phase, and provide a good record ofwhat was tested at the time of installation. I am confident that following the recommendations outlined in this chapter will lead to more successful implementations of ISDN, and in time primary rate ISDN deployment will become as common and straightforward as ground start trunk interfaces are now. Continued education, research, and understanding these of these common problems will lead to more lower cost, and more successful implementations of this truly twenty first century service. As 115 demonstrated in this thesis, ISDN layer 3 interoperability issues exist and can be classified. Analysis of the data samples leads to a better understanding of how these interoperability issues arise, the cost associated with them and the effort required addressing them. This understanding also sheds a light on how some of these issues might be avoided, and more successful implementations of ISDN achieved 116 Bibliographic Citations 1) AT&T Technical Reference (TR) 41459, AT&T Network ISDN User-Network Interface Description, June 1999 2) Worldcom Publishing, CPE requirements for ISDN Primary Rate Interface, Document 014-001 8-04.3D-ER 3) Lucent Technologies Documentation, 5ESS Switch Documentation, Release 235- 401-103 June 2000 4) Siemens Communications, Digital Electronic Switching System (EWSD) Release 17 Documentation, USPCBRV0077/013 August 2000 5) Northern Telecom Publications, DMS 500 Release 12.03:LEC0013, Doc. Number 1.888.435.6762 Documentation, January 2000 6) National ISDN Council, ISDN Standards, www.nationalisdncouncil.com 7) Cisco Systems Inc., Configurations and CPE Guidelines for ISDN Compatibility, www.cisco.com 8) Telecordia Technologies, Bellcore Reference Documents - TR's, LSSGR's for ISDN, www.telecordia.com 9) SBC global Network - Pacific Bell ISDN User Guide, www.pacbell.com 10) Lucent technologies Switch Solutions, ISDN Applications Guidelines, http://www.lucent.com/products/ 1 1) Nortel Networks ISDN page, Switched Applications, Network Guidelines, http://www.nortelnetworks.eom/products/Q 1 /bus services/isdnbri/index.html 12) Siemens EWSD Switch, Switched Applications, Network Guidelines, http://www.icn.siemens.com/icn/products/ewsd/ewsdsw.html 13) North American ISDN Users Forum, ISDN Standards and Applications, http://www.niuf.nist.gov/ 14) ANSI Tl.403-1999, "Network and Customer Installation Interfaces - DS1 - Electrical Interface, " ANSI, New York, 1999 15) ANSI Tl.608-1997, "Digital Subscriber Signaling System Number 1 - (DSS1) - Service," Signaling Specification for X.25 Packet Switched Bearer ANSI, New York, 1997 117 16) ANSI T1.602-1996, "ISDN Data-Link Layer Signaling Specification for Applications Interface," at the User-Network ANSI, New York, 1996 17) ANSI Tl.607-1998, "ISDN Layer 3 Signaling Specifications for Circuit Switched Bearer Service for Digital Subscriber Signaling System Number 1 DSS1," ANSI, New York, 1998 18) "ISDN Primary Rate Interface Call Control Switching and Signaling Generic Equipment," Requirements for Class II TR-NWT-001268, Bellcore/Telcordia, December 1991 19) Open Source Initiative, OSI, http://www.opensource.org/ 20) Minoli, Daniel. Telecommunications Handbook 3rd Edition. Artech House Norwood MA, 1997 21) ANSI Tl.605-1991, "ISDN - Basic Access Interface S and T Interface Points (Layer 1 Specification)," ANSI, New York, 1991 22) "ISDN D-Channel Exchange Access Signaling and Switching requirements (Layer 2)," TR-TSY-000973 REV01, Bellcore Telcordia, October 1994. 23) Performance Technologies, Signaling System Seven (SS7) Tutorials, http://www.pt.com/tutorials/ss7/ ANSI Tl "ISDN Rate - Customer Installation Metallic Interfaces 24) .408-1990, Primary Specification)," - (Layer 1 ANSI, New York, 1990 118