Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links

Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links

An SAIC Company

Telcordia Technologies Generic RequirementsGR-2878-COREIssue 4December 1999

Comments Requested (See Preface)

GR-2878-COREGeneric Requirements for CCS Nodes Supporting ATM HSLs Issue 4Copyright Page December 1999

Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links

Prepared for Telcordia Technologies by members of the Telecom Networks Planning and Design Practice, Network Signaling Standards and Architecture Group

Target audience: Suppliers of Signaling Transfer Points (STPs), Service Control Point (SCP) nodes, and Common Channel Signaling Switching Offices/Service Switching Points (CCS SOs/SSPs) to North American Local Exchange Carrier (LEC) CCS networks.

This document replaces GR-2878-CORE, Issue 3, November 1998.

Related documents GR-82-CORE, GR-1241-CORE, GR-606-CORE, GR-310-CORE.

Technical contact Frank Bevacqua, (732) 758-2399, [email protected]

To obtain copies of this document, contact your company’s document coordinator or call 1-800-521-2673 (from the USA and Canada) or 1-732-699-5800 (all others), or visit our Web site at www.telcordia.com. Telcordia employees should call (732) 699-5802.

Copyright © 1995, 1997-1999 Telcordia Technologies, Inc. All rights reserved.

Project Funding Year: 1999

Trademark AcknowledgmentsTelcordia is a trademark of Telcordia Technologies, Inc.COMMON LANGUAGE is a registered trademark of Telcordia Technologies, Inc.NetPilot, SEAS, and CLLI are trademarks of Telcordia Technologies, Inc.CLASS is a service mark of Telcordia Technologies, Inc.

ii

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Disclaimer

Telcordia Technologies Generic Requirements Notice Of Disclaimer

This Generic Requirements document (GR) is published by Telcordia Technologies to inform the industry of the Telcordia view of proposed generic requirements for CCS Nodes Supporting ATM-Based High Speed (1.5 Mb/s) Signaling Links (HSLs). The generic requirements contained herein are subject to review and change, and superseding generic requirements regarding this subject may differ from those in this document. Telcordia reserves the right to revise this document for any reason (consistent with applicable provisions of the Telecommunications Act of 1996 and applicable FCC rules).

Telcordia specifically advises the reader that this GR does not directly or indirectly address any Year-2000 (“Y2K”) issues that might be raised by the services, systems, equipment, specifications, descriptions, or interfaces addressed or referred to herein. As an example, and not a limitation, neither this GR nor Telcordia is directly or indirectly assessing or determining whether specific services, systems, or equipment, individually or together, in their current form or as they may be implemented, modified, or augmented in the future, will accurately process dates and date-related data within or between the twentieth and twenty-first centuries, in either direction, including elapsed time, time difference, and/or leap year calculations.

TELCORDIA AND THE FUNDING PARTICIPANTS IDENTIFIED IN THE PREFACE MAKE NO REPRESENTATION OR WARRANTY, EXPRESSED OR IMPLIED, WITH RESPECT TO THE SUFFICIENCY, ACCURACY, OR UTILITY OF ANY INFORMATION OR OPINION CONTAINED HEREIN.

TELCORDIA AND FUNDING PARTICIPANTS EXPRESSLY ADVISE THAT ANY USE OF OR RELIANCE UPON SAID INFORMATION OR OPINION IS AT THE RISK OF THE USER AND THAT NEITHER TELCORDIA NOR ANY FUNDING PARTICIPANT SHALL BE LIABLE FOR ANY DAMAGE OR INJURY INCURRED BY ANY PERSON ARISING OUT OF THE SUFFICIENCY, ACCURACY, OR UTILITY OF ANY INFORMATION OR OPINION CONTAINED HEREIN.

LOCAL CONDITIONS MAY GIVE RISE TO A NEED FOR ADDITIONAL PROFESSIONAL INVESTIGATIONS, MODIFICATIONS, OR SAFEGUARDS TO MEET SITE, EQUIPMENT, ENVIRONMENTAL SAFETY OR COMPANY-SPECIFIC REQUIREMENTS. IN NO EVENT IS THIS INFORMATION INTENDED TO REPLACE FEDERAL, STATE, LOCAL, OR OTHER APPLICABLE CODES, LAWS, OR REGULATIONS. SPECIFIC APPLICATIONS WILL CONTAIN VARIABLES UNKNOWN TO OR BEYOND THE CONTROL OF TELCORDIA. AS A RESULT, TELCORDIA CANNOT WARRANT THAT THE APPLICATION OF THIS INFORMATION WILL PRODUCE THE TECHNICAL RESULT OR SAFETY ORIGINALLY INTENDED.

This GR is not to be construed as a suggestion to anyone to modify or change any product or service, nor does this GR represent any commitment by anyone, including but not limited

iii

GR-2878-COREGeneric Requirements for CCS Nodes Supporting ATM HSLs Issue 4Disclaimer December 1999

to Telcordia or any funder of this Telcordia GR, to purchase, manufacture, or sell any product with the described characteristics.

Readers are specifically advised that any entity may have needs, specifications, or requirements different from the generic descriptions herein. Therefore, anyone wishing to know any entity’s needs, specifications, or requirements should communicate directly with that entity.

Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right under any patent, whether or not the use of any information herein necessarily employs an invention of any existing or later issued patent.

TELCORDIA DOES NOT HEREBY RECOMMEND, APPROVE, CERTIFY, WARRANT, GUARANTEE, OR ENDORSE ANY PRODUCTS, PROCESSES, OR SERVICES, AND NOTHING CONTAINED HEREIN IS INTENDED OR SHOULD BE UNDERSTOOD AS ANY SUCH RECOMMENDATION, APPROVAL, CERTIFICATION, WARRANTY, GUARANTY, OR ENDORSEMENT TO ANYONE.

If further information regarding technical content is required, please contact:

Stanley Wainberg, DirectorCCS Network Standards, Requirements, and Architecture -Telecom Networks Planning and DesignTelcordia Technologies331 Newman Springs Road, Room 2Z-231Red Bank, New Jersey 07701-56991-732-758-2122

For general information about this or any other Telcordia documents, please contact:

Telcordia Technologies Customer Service8 Corporate Place, Room 3A-184Piscataway, New Jersey 08854-41561-800-521-2673 (US & Canada)1-732-699-5800 (all others)1-732-336-2559 (FAX)http://www.telcordia.com

iv

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Contents

Generic Requirements for CCS Nodes SupportingATM High Speed Signaling Links (HSLs)

Contents Contents

Preface ....................................................................................................................Preface-1

1. Introduction................................................................................................................1-11.1 Purpose and Scope ...........................................................................................1-11.2 Related Documents ..........................................................................................1-11.3 Organization of This Document.......................................................................1-21.4 Requirements Terminology..............................................................................1-31.5 Requirement Labeling Conventions.................................................................1-4

1.5.1 Numbering of Requirement and Related Objects ...............................1-41.5.2 Requirement, Conditional Requirement, and Objective Object

Identification .......................................................................................1-51.6 Summary of Changes .......................................................................................1-5

1.6.1 Reasons for Reissue ............................................................................1-51.6.2 Highlights of Principal Revisions and Additions................................1-51.6.3 Change Bars ........................................................................................1-51.6.4 List of Revisions .................................................................................1-6

2. HSL Signaling and Network Architecture .................................................................2-12.1 SS7 and ATM Protocol Architecture ...............................................................2-1

2.1.1 Overview.............................................................................................2-12.1.2 Physical Layer.....................................................................................2-22.1.3 ATM Layer .........................................................................................2-3

2.1.3.1 Overview of ATM Technology ..........................................2-32.1.3.2 Application of ATM to HSLs .............................................2-5

2.1.4 Signaling ATM Adaptation Layer (SAAL) ........................................2-52.1.4.1 Common Part (CP) .............................................................2-62.1.4.2 Service Specific Connection Oriented Protocol (SSCOP) .2-62.1.4.3 Service Specific Coordination Function (SSCF)................2-72.1.4.4 SAAL Layer Management..................................................2-7

2.1.5 Signaling Network Layer (MTP - Level 3).........................................2-72.2 HSLs in LEC CCS Networks - Topology Overview .......................................2-8

2.2.1 HSL Deployment Drivers ...................................................................2-82.2.2 HSL Implementation at CCS Network Nodes ....................................2-92.2.3 HSL Deployment in LEC CCS Networks...........................................2-92.2.4 Potential Use of HSLs in CCS Network Interconnection .................2-112.2.5 Potential Future HSL Application to Broadband

Network Interworking.......................................................................2-11

v

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Contents December 1999

GR-2878-CORE

3. Network Element Requirements ................................................................................3-13.1 ATM and Physical Layer Requirements ..........................................................3-1

3.1.1 ATM Layer Requirements ..................................................................3-13.1.2 Physical Layer Requirements..............................................................3-2

3.1.2.1 Synchronization Requirements...........................................3-43.1.2.2 Connector............................................................................3-5

3.2 Signaling ATM Adaptation Layer (SAAL) Requirements ..............................3-53.2.1 AAL Type 5 Common Part .................................................................3-53.2.2 SSCOP-Related Requirements............................................................3-6

3.2.2.1 General................................................................................3-63.2.2.2 Credit Determination and Peer-to-Peer Flow Control ........3-7

3.2.3 SSCF-Related Requirements...............................................................3-73.2.4 Layer Management-Related Requirements.........................................3-8

3.2.4.1 Error Monitoring for In-Service Signaling Links...............3-93.2.4.2 Determination of Failed Proving Attempts.........................3-93.2.4.3 Forced Proving Procedures to Prevent Link Oscillations...3-93.2.4.4 Timer for No Receipt of Credit ........................................3-113.2.4.5 Peer-to-Peer Layer Management Communications..........3-12

3.2.5 Other - SAAL Related Requirements ...............................................3-123.2.5.1 Signaling Link Speed........................................................3-123.2.5.2 PDU Lengths ....................................................................3-12

3.2.6 SAAL Timer and Parameter Values .................................................3-133.3 Message Transfer Part - Level 3 ....................................................................3-15

3.3.1 Signaling Message Handling ............................................................3-163.3.1.1 Message Routing ..............................................................3-163.3.1.2 Message Handling During Overload ................................3-18

3.3.2 MTP Network Management Functions.............................................3-193.3.2.1 Congestion Control ...........................................................3-193.3.2.2 Signaling Link Activation, Restoration, Deactivation, and

Link Set Activation...........................................................3-213.3.2.3 Signaling Link Changeover ..............................................3-293.3.2.4 Transfer Restricted Timer.................................................3-313.3.2.5 Signaling Link Test...........................................................3-313.3.2.6 Use of the MTP3 Link Oscillation Filter for HSLs

at STPs ..............................................................................3-323.4 SCCP Functions .............................................................................................3-34

4. Node Operations Requirements .................................................................................4-14.1 General .............................................................................................................4-1

4.1.1 Scope and Organization of the HSL Operations Requirements..........4-14.1.2 General Considerations and Related Operations Requirements .........4-2

4.2 Configuration Management (Memory Administration)...................................4-34.2.1 Configuration of Common Link Parameters.......................................4-34.2.2 Configurable Parameters: Physical Layer Interface (DS1).................4-74.2.3 Configurable Parameters: ATM Layer ...............................................4-7

vi

ab


4.2.3.1 Configuration of the ATM Interface at the CCS Node.......4-94.2.3.2 Configuration of the Signaling Link VCC/VCL ..............4-11

4.2.4 Configurable Parameters: SAAL (SSCOP/SSCF/Layer Management) .................................................4-18

4.2.5 MTP3 Link Congestion Thresholds ..................................................4-204.2.6 Link Marginal Performance Thresholds ...........................................4-214.2.7 Link Parameter Administration: Data Operations ............................4-224.2.8 Summary of HSL Configurable Parameters .....................................4-23

4.3 In-band Operations Flows ..............................................................................4-314.3.1 Physical Layer Operations Flows: DS1-Level..................................4-314.3.2 ATM-Layer Operations Flows..........................................................4-32

4.4 Fault Management (Maintenance) .................................................................4-344.4.1 Link Event Notification Functions....................................................4-35

4.4.1.1 Link Outage-Related Event Detection and Reporting ......4-354.4.1.2 Common Requirements for Link Event Reports ..............4-394.4.1.3 Link Outage Event Report ................................................4-414.4.1.4 Link Available Event Report ............................................4-514.4.1.5 Sustained Link Failure/Craft Referral Event Report ........4-554.4.1.6 Unavailable-Link Minor State Change Event Report.......4-574.4.1.7 Oversized Message Routing Attempt on an MTP2 Signaling

Link...................................................................................4-614.4.2 Link Status Logging..........................................................................4-644.4.3 Lower-Layer Fault-Management Surveillance Functions ................4-68

4.4.3.1 ATM-Layer Defect and Failure Detection and Reporting4-684.4.3.2 Physical Layer Defect and Failure Detection and Reporting

(DS1).................................................................................4-694.4.4 Link Testing Functions .....................................................................4-71

4.4.4.1 Physical-Level Testing: DS1 ESF Loopbacks..................4-714.4.4.2 ATM-Layer OAM Loopback Tests ..................................4-73

4.4.5 Link Control Functions (Removal From Service) ............................4-734.5 Performance Management (Maintenance and Network

Traffic Management) .....................................................................................4-744.5.1 Scheduled Link Performance Measurements....................................4-75

4.5.1.1 MTP Level 3 Performance Measurements: Daily and Marginal............................................................................4-76

4.5.1.2 MTP Level 3 Performance Measurements: 5-Minute ......4-784.5.1.3 SAAL-Level Performance Measurements: Daily and

Marginal............................................................................4-824.5.1.4 SAAL-Level Performance Measurements: 5-Minute.......4-844.5.1.5 ATM-Level Performance Measurements: Daily and

Marginal............................................................................4-864.5.1.6 Physical-Level (DS1) Performance Measurements..........4-87

4.5.2 Exception-Based Performance Monitoring.......................................4-874.5.2.1 HSL Marginal Performance Reports ................................4-87

vii


GR-2878-CORE

4.5.2.2 HSL Threshold Crossing Alerts (TCAs) ..........................4-894.5.2.3 Exception-Based Facility Monitoring (DS1)....................4-90

4.5.3 Management-Initiated Performance Monitoring ..............................4-904.5.3.1 SAAL-Level: SSCOP PDU Data Capture........................4-914.5.3.2 ATM-Level: Use of F5 Performance Monitoring

OAM Cells........................................................................4-914.5.3.3 DS1 Level: Scheduling of DS1 Performance Reports......4-92

4.6 Network Data Collection (NDC) ...................................................................4-924.6.1 MTP Level 3 Link Traffic and Performance Measurements

(30 Minute) .......................................................................................4-944.6.1.1 MTP3 Link Measurements ...............................................4-944.6.1.2 MTP3 Link Set Measurements .........................................4-99

4.6.2 SAAL-Level Measurements: 30-minutes .......................................4-1004.6.2.1 SAAL-Level Link Measurements...................................4-1004.6.2.2 SAAL-Level Link Set Measurements ............................4-101

4.6.3 ATM-Cell Traffic Measurements: 30-Minutes...............................4-1024.6.3.1 ATM-Level Link Measurements ....................................4-1024.6.3.2 ATM-Level Link Set Measurements ..............................4-102

4.6.4 Additional Measurement Requirements..........................................4-103

5. Operations Interface Support .....................................................................................5-15.1 General .............................................................................................................5-15.2 Configuration Management/Memory Administration OS Interface Support ..5-3

5.2.1 For STPs (GR-310-CORE) .................................................................5-35.2.2 For CCS End-Nodes............................................................................5-55.2.3 For All CCS Nodes (GR-981-CORE).................................................5-6

5.3 Maintenance OS Interface Support ..................................................................5-65.3.1 For Fault Management Functions .......................................................5-6

5.3.1.1 For All CCS Node Types (TA-TSY-000387) ....................5-65.3.1.2 For STPs (GR-310-CORE).................................................5-75.3.1.3 For SCPs (TA-NWT-000365) ............................................5-8

5.3.2 For Performance Management Functions ...........................................5-85.3.2.1 For All CCS Node Types (TA-TSY-000387) ....................5-85.3.2.2 For STPs (GR-310-CORE).................................................5-9

5.4 Network Traffic Management (NTM) OS Interface Support ........................5-105.4.1 For All CCS Node Types (GR-495-CORE) .....................................5-105.4.2 For STPs (GR-310-CORE) ...............................................................5-105.4.3 Considerations For CCS SOs/SSPs...................................................5-11

5.5 Network Data Collection (NDC) OS Interface Support ................................5-115.5.1 For All CCS Node Types (GR-376-CORE) .....................................5-115.5.2 For STPs (GR-310-CORE) ...............................................................5-125.5.3 For SCPs (TA-NWT-000365)...........................................................5-135.5.4 For CCS SOs/SSPs (FSD 45-09-0100).............................................5-13

5.6 User-System Interface (USI) Support (TR-TSY-000825) .............................5-14

viii

ab


6. Performance ...............................................................................................................6-16.1 Reliability .........................................................................................................6-16.2 Network Performance Parameters and Objectives...........................................6-1

6.2.1 Parameters Related to the Message Transfer Part...............................6-26.2.2 Message Transfer Times .....................................................................6-36.2.3 SAAL Performance.............................................................................6-56.2.4 ATM Layer Performance ....................................................................6-5

6.3 Capacity............................................................................................................6-6

7. Environmental Requirements.....................................................................................7-17.1 Power................................................................................................................7-17.2 Equipment ........................................................................................................7-17.3 Electromagnetic and Electrical Environment...................................................7-1

8. Quality........................................................................................................................8-18.1 Introduction ......................................................................................................8-18.2 Reliability and Quality Switching Systems Generic Requirements.................8-1

8.2.1 System Design and Architecture.........................................................8-28.2.2 Manufacturing and Production............................................................8-28.2.3 In-Service Performance and Product Support.....................................8-2

9. Transitional Considerations .......................................................................................9-1

10. Supplier Support ......................................................................................................10-110.1 General ...........................................................................................................10-110.2 HSL NE Operations Documentation..............................................................10-110.3 HSL NE Software Documentation.................................................................10-2

Appendix A: Guidelines for Peer-to-Peer Credit Flow Control and Receive Buffer Sizing ...............................................................................................A-1A.1 SAAL Flow-Control Mechanism....................................................................A-1A.2 Credit Assignment Schemes ...........................................................................A-2A.3 Basic Credit Requirements.............................................................................A-4A.4 Impact of Level 3 Capacity on Credit Allocation ..........................................A-7A.5 Impact of Message Size .................................................................................A-7A.6 Guidelines ......................................................................................................A-9

Appendix B: Overview of SAAL Error Monitors ........................................................... B-1B.1 SAAL Error Monitor....................................................................................... B-1B.2 Proving Algorithm .......................................................................................... B-2

Appendix C: Analysis of HSL Transmit Congestion Thresholds ................................... C-1C.1 Link Transmit Congestion Control ................................................................. C-1

C.1.1 STP-STP HSL Transmit Congestion ................................................. C-2C.1.2 STP-SCP HSL Transmit Congestion ................................................. C-4

C.2 Message Size Sensitivity of Buffer Thresholds .............................................. C-5

Appendix D: HSL Measurement Summary.....................................................................D-1

ix


GR-2878-CORE

D.1 HSL and MTP2 Measurements Comparison ..................................................D-1D.2 HSL Link Marginal Performance Indicators.................................................D-14

Appendix E: Considerations Regarding HSL Marginal Performance Thresholds.......... E-1E.1 Number of Automatic Changeovers................................................................ E-1E.2 SSCOP SD PDUs Transmitted Requiring Retransmission............................. E-2

E.2.1 Average Sustained BER Criteria........................................................ E-3E.2.2 Error-Burst Frequency Criteria .......................................................... E-6E.2.3 Recommendations Regarding the PDUs-Retransmitted Thresholds . E-8

E.3 SSCOP Connection Sum-of-Errors Counter ................................................... E-9E.4 SSCOP Errored PDUs Sum-of-Errors Counter............................................... E-9

Appendix F: The Effectiveness of Congestion Controls ................................................. F-1F.1 Network Model ............................................................................................... F-2F.2 Overload Scenarios ......................................................................................... F-4

F.2.1 Level 3 Capacity Limitations in STP1 only....................................... F-4F.2.2 Level 3 Capacity Limitations in all STPs .......................................... F-5

F.3 Summary ......................................................................................................... F-6

Appendix G: Notes on Protocol Standards Discrepancies ..............................................G-1G.1 General ............................................................................................................G-1G.2 SSCF (T1.645) SDL Diagram vs. State Table Discrepancy ...........................G-1G.3 Table 6/Q.2140 Initial-State-Column Labeling Errors ...................................G-3

References ........................................................................................................References-1

Glossary ............................................................................................................... Glossary-1

Acronyms...........................................................................................................Acronyms-1

Requirement-Object Index ..........................................................................................ROI-1

x

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 List of Figures

List of Figures Figures

Figure 2-1. High-Speed Link Protocol Model..............................................................2-2Figure 2-2. ATM Cell Structure ...................................................................................2-4Figure 2-3. LEC Potential HSL Deployment Plans ...................................................2-10Figure 2-4. Example Architectures for HSLs Used in CCS Network

Interconnection ........................................................................................2-12Figure 2-5. Potential CCS Network - Broadband Network Interconnection

Architecture .............................................................................................2-13Figure 3-1. ATM NNI Cell Structure ...........................................................................3-1Figure C-1. Network Architecture for HSL Simulation .............................................. C-1Figure F-1. Network Model Used in Telcordia Congestion Control Study ................ F-2

xi

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4List of Figures December 1999

GR-2878-CORE

xii

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 List of Tables

List of Tables Tables

Table 3-1. SAAL Timers and Parameters .................................................................3-14Table 4-1. Summary of HSL Configurable Parameters ............................................4-27Table 6-1. High Speed Link Output Delay .................................................................6-4Table 6-2. High Speed Link Cross-STP Transport Time............................................6-5Table C-1. Message Categories .................................................................................. C-2Table C-2. Preliminary STP-STP HSL Congestion Threshold and Buffer Size

Recommendations ....................................................................................C-3Table C-3. Preliminary STP-SCP HSL Congestion Threshold and Buffer Size

Recommendations ....................................................................................C-4Table D-1. HSL and MTP2-Links Measurements Summary and Comparison;

Plus GR-310/TA-365 Interface Standardized Data Groupings and Register Labels........................................................................................................D-4

Table D-2. HSL and MTP2 Link Marginal Performance Indicators ........................D-14Table F-1. Call Processing Capacities of the SSPs in Figure F-1 ............................. F-2Table F-2. SMH Congestion Thresholds in Secondsa................................................ F-4

xiii

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4List of Tables December 1999

GR-2878-CORE

xiv

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Preface

Preface Preface

This Preface contains important information about the Telcordia Technologies GR process in general, as well as important information about this document.

The Telcordia GR Process

Generic Requirements documents (GRs) provide the Telcordia Technologies view of proposed generic criteria for telecommunications equipment, systems, or services, and involve a wide variety of factors, including interoperability, network integrity, funding participant expressed needs, and other input.

The Telcordia GR process implements Telecommunications Act of 1996 directives relative to the development of industry-wide generic requirements relating to telecommunications equipment, including integral software and customer premises equipment. Pursuant to that Act, Telcordia invites members of the industry to fund and participate in the development process for such GRs. Invitations to fund and participate are issued monthly in the Telcordia Digest of Technical Information, and posted on the Telcordia web site at http://www.telcordia.com/DIGEST.

At the conclusion of the GR development process, Telcordia publishes the GR, which is available by subscription. The subscription price entitles the purchaser to receive that issue of the GR (GR-CORE) along with any Issues List Report (GR-ILR) and revisions, if any are released under that GR project. ILRs contain any technical issues that arise during GR development that Telcordia and the funding participants would like further industry interaction on. The ILR may present issues for discussion, with or without proposed resolutions, and may describe proposed resolutions that lead to changes to the GR. Significant changes or additional material may be released as a revision to the GR-CORE.

Telcordia may also solicit general industry nonproprietary input regarding such GR material at the time of its publication, or through a special Industry Interaction Notice appearing in the Telcordia Digest of Technical Information. While unsolicited comments are welcome, any subsequent work by Telcordia regarding such comments will depend on funding support for such GR work. Telcordia will acknowledge receipt of comments and will provide a status to the submitting company.

Preface–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Preface December 1999

GR-2878-CORE

About GR-2878-CORE

A. Funders of GR-2878-CORE, Issue 4, are

BellSouth, SBC Communications, and US WEST.

B. Relative Maturity Level

This technology area is ready for implementation and deployment. Initial network deployment of this technology has already begun in 1999. This GR issue incorporates clarifications, revisions, and corrections relative to requirements presented in prior issues of this document, as well as new functional requirements, based on industry input, revised industry standards, and related Telcordia GRs.

C. GR-2878-CORE Plans

Telcordia proposes to update and maintain this GR on a ongoing basis as suppliers implement this technology and network providers gain operational experience. Subject to client funding and participation, a subsequent update in the form of a superseding Issue 5 of this GR is anticipated in late 2000.

To Submit Comments

When submitting comments, please include the GR document number, and cite any pertinent section and requirement number. In responding to an ILR, please identify the pertinent Issue ID number. Please provide the name and address of the contact person in your company for further discussion.

Comments should be submitted by March 31, 2000.

Send comments to:

Telcordia — GR-2878-CORE Frank BevacquaSenior Engineer - CCS Network and Operations Requirements331 Newman Springs Road, Room NVC 2X-269Red Bank, NJ 07701-5699USA

Phone: (732) 758-2399FAX: (732) 758-4343E-Mail: fbevacqu @telcordia.com

Preface–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Introduction

1. Introduction

1.1 Purpose and Scope

This GR provides the Telcordia view of proposed generic requirements for 1.5 Megabit-per-second1 (Mb/s) Asynchronous Transfer Mode (ATM) High-Speed Signaling Links (HSLs) implemented at Local Exchange Carrier (LEC) narrowband Common Channel Signaling (CCS) network nodes. The HSLs described in this document shall use the ATM and Signaling ATM Adaptation Layer (SAAL) protocols currently defined for signaling channels in the Broadband Integrated Services Digital Network (B-ISDN) environment for their data-link- and link-layer functions, respectively, and level 3 of the Signaling System No. 7 (SS7) protocol’s Message Transfer Part (MTP) at the network layer. These links shall be implemented over dedicated DS1-rate (1.544 Mb/s) physical-layer transmission link facilities.

The generic requirements provided in this document cover the SS7 protocol and message handling functions and operations capabilities applicable to Signaling Transfer Points (STPs) and CCS end nodes (i.e., including CCS Switching Offices (CCS SOs), Service Switching Points (SSPs), and Service Control Point (SCP) nodes) that implement 1.5-Mbps HSLs. In this document, an instance of these network elements is referred to generally as an HSL network element (HSL NE).

1.2 Related Documents

Several documents referenced in this GR are considered key to the understanding of the generic requirements presented in this document. The key references are described in the following list. This document relies on GR-246-CORE,[1] Telcordia Technologies Specification of Signaling System Number 7 (SS7), as the detailed SS7 protocol basis for the CCS network. For the lower layer protocol functions and procedures, this document relies on the following Telcordia Generic Requirements, American National Standards Institute (ANSI), and International Telecommunications Union - Telephony (ITU-T) documents:

• TR-NWT-01112,[2] Broadband ISDN User to Network Interface and Network Node Interface Physical Layer Generic Criteria.

• GR-1113-CORE,[3] Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols.

• GR-499-CORE,[4] Transport System Generic Requirements (TSGR): Common Requirements.

1. HSLs shall operate on 1.544 Mbps (DS1-rate) physical facilities with a 1.536 Mbps bearer channel available to higher layers (i.e., the ATM-layer and above), excluding DS1 framing overhead.

1–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Introduction December 1999

GR-2878-CORE

• ANSI T1.635,[5] Broadband ISDN - ATM Adaptation Layer Type 5 Common Part Functions and Specification.

• ANSI T1.637,[6] B-ISDN Signaling ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP).

• ANSI T1.645,[7] B-ISDN Signaling ATM Adaptation Layer - Service Specific Coordination Function for Support of Signaling at the Network Node Interface (SCCF at the NNI).

• ANSI T1.652,[8] B-ISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI.

• ITU-T Recommendation Q.2110,[9] B-ISDN - ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP) Specification.

• ITU-T Recommendation Q.2140,[10] B-ISDN - ATM Adaptation Layer - Service Specific Coordination Function for Signalling at the Network Node Interface (SSCF at NNI).

• ITU-T Recommendation Q.2144,[11] BISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI.

A more complete Reference List is provided at the end of this GR document.

1.3 Organization of This Document

The remainder of this document is organized as follows:

• Section 2: HSL Signaling and Network Architecture. This section gives a high-level description of the SS7 and ATM protocol stacks and the CCS network architecture to be used for high speed (1.5-Mb/s) signaling links deployed in the CCS networks of Telcordia clients.

• Section 3: Network Element Requirements. This section describes requirements for STPs and end nodes to provide the features and functions necessary to support HSLs.

• Section 4: Node Operations Requirements. This section provides requirements for the incremental operations functions to be provided by CCS nodes to support ATM based HSLs over and above operations requirements described in relevant CCS node GRs, including GR-82-CORE,[12] Signaling Transfer Point (STP) Generic Requirements, GR-606-CORE,[13] LSSGR: Common Channel Signaling, and GR-1241-CORE[14] Supplemental Service Control Point (SCP) Generic Requirements. It addresses operations functionality in the domains of Configuration Management (Memory Administration), Fault Management, Performance Management (for both network maintenance and Network Traffic Management (NTM) surveillance), and Network Data Collection (NDC).

1–2

ab


• Section 5: Operations Interface Support. This section provides requirements for operations systems interfaces. It provides a mapping of the HSL operations data and functions to current and planned CCS node - OS interfaces.

• Section 6: Performance. This section provides objectives and requirements for HSL performance in LEC CCS networks.

• Section 7: Environmental Requirements. This section describes environmental requirements associated with equipment supporting HSLs.

• Section 8: Quality. This section provides quality assurance requirements for HSLs.

• Section 9: Transitional Considerations. This section describes transitional issues associated with HSL deployment.

• Section 10: Supplier Support. This section describes specific support expected from CCS node suppliers implementing HSLs.

Seven appendixes (A through G) provide additional information on HSL performance, operations, and implementation considerations for potential use by CCS node suppliers. These include

• Appendix A: Guidelines for Peer-to-Peer Credit Flow Control and Receive-Buffer Sizing

• Appendix B: Overview of SAAL Error Monitors

• Appendix C: Analysis of HSL Transmit Congestion Thresholds

• Appendix D: HSL Measurements Summary

• Appendix E: Considerations Regarding HSL Hourly Marginal Performance Thresholds

• Appendix F: The Effectiveness of Congestion Controls

• Appendix G: Notes on Protocol Standards Discrepancies.

A detailed list of References follows the indicated appendixes, along with a Glossary, a list of Acronyms, and a Requirements Object Index (ROI), useful for implementation and conformance tracking.

1.4 Requirements Terminology

The following requirements terminology is used throughout this document:

• Requirement — a feature or function that, in the view of Telcordia, is necessary to satisfy the needs of a typical LEC. Failure to meet a requirement may cause application restrictions, result in improper functioning of the product, or hinder

1–3


GR-2878-CORE

operations. A Requirement contains the words shall or must and is flagged by the letter “R.”

• Conditional Requirement — a feature or function that, in the view of Telcordia, is necessary in specific LEC applications. If a LEC identifies a Conditional Requirement as necessary, it shall be treated as a requirement for the application(s). Conditions that may cause the Conditional Requirement to apply include, but are not limited to, certain LEC application environments, elements, or other requirements, etc. A Conditional Requirement is flagged by the letters “CR.”

• Objective — a feature or function that, in the view of Telcordia, is desirable and may be required by a LEC. An Objective represents a goal to be achieved. An Objective may be reclassified as a Requirement at a specified date. An objective is flagged by the letter “O” and includes the words it is desirable or it is an objective.

• Conditional Objective — a feature or function that, in the view of Telcordia, is desirable in specific LEC applications and may be required by a LEC. It represents a goal to be achieved in the specified Condition(s). If a LEC identifies a Conditional Objective as necessary, it shall be treated as a requirement for the application(s). A Conditional Objective is flagged by the letters “CO.”

• Condition — The circumstances that, in the view of Telcordia, will cause a Conditional Requirement or Conditional Objective to apply. A Condition is flagged by the letters “Cn.”

1.5 Requirement Labeling Conventions

As part of the Telcordia GR Process, proposed requirements and objectives are labeled using conventions that are explained in the following two sections.

1.5.1 Numbering of Requirement and Related Objects

Each Requirement, Objective, Condition, Conditional Requirement, and Conditional Objective object is identified by both a local and an absolute number. The local number consists of the object's document section number and its sequence number in the section (e.g., R3-1 is the first Requirement in Section 3). The local number appears in the margin to the left of the Requirement. A Requirement object's local number may change in subsequent issues of a document if other Requirements are added to the section or deleted.

The absolute number is a permanently assigned number that will remain for the life of the Requirement; it will not change with new issues of the document. The absolute number is presented in brackets (e.g., [2]) at the beginning of the requirement text.

Neither the local nor the absolute number of a Conditional Requirement or Conditional Objective depends on the number of the related Condition(s). If there is any ambiguity

1–4

ab


about which Conditions apply, the specific Condition(s) will be referred to by number in the text of the Conditional Requirement or Conditional Objective.

References to Requirements, Objectives, or Conditions published in other Generic Requirements documents will include both the document number and the Requirement object’s absolute number. For example, R2345-12 refers to Requirement [12] in GR–2345.

1.5.2 Requirement, Conditional Requirement, and Objective Object Identification

A Requirement object may have numerous elements (paragraphs, lists, tables, equations, etc.). To aid the reader in identifying each part of the requirement, an ellipsis character (...) appears in the margin to the left of all elements of the Requirement.

Tables and Figures within Requirements are identified separately from others within the document text, and do not appear in the Table of Contents. They are numbered sequentially beginning with Table 1 and Figure 1.

1.6 Summary of Changes

1.6.1 Reasons for Reissue

This GR is being reissued to incorporate clarifications, revisions, and corrections to the generic criteria published in Issue 3, as well as to introduce new functional requirements, based on funder and industry input and corrections to published industry standards.

1.6.2 Highlights of Principal Revisions and Additions

Principal revisions concern new requirements and objectives clarifying criteria for the HSL NE’s use of Normal Link Set Activation versus Emergency Link Set Restart procedures, as defined under the SS7 protocol, which determine whether normal or emergency proving is used on the activation or restoration of individual HSLs.

1.6.3 Change Bars

Change bars are used in the right margins to denote lines containing new or modified text relative to Issue 3, November 1998. Because these markings are automatically generated, they denote both substantive revisions and minor editorial and format changes. A detailed list of the substantive revisions is documented below in Section 1.6.4.

1–5


GR-2878-CORE

1.6.4 List of Changes

The following is a detailed listing of substantive changes to this GR, relative to Issue 3. It includes new requirements objects as well as substantively modified and clarified requirements, and new or revised explanatory text, where such revisions might impact the functionality or compliance of the CCS node’s implementation of HSLs. Note that numerous minor editorial revisions, corrections, and format changes deemed not to be of a substantive nature, are summarized but are not documented in detail here.

Absolute numbers for requirements objects introduced in prior issues have been frozen. New requirements objects introduced in the current Issue are tagged with absolute numbers ascending from and including [230].

1. Section 3.3.2.2.2 (Use of Emergency Proving). Several modified and new requirements objects clarify the criteria under which the HSL NE shall utilize Link Set Emergency Restart procedures versus Link Set Normal Activation procedures for the restoration or activation of HSL and MTP2 link sets. These modifications reflect changes recently adopted for the ANSI T1S1 version of the SS7 protocol standard for the Message Transfer Part (MTP). They are intended primarily to address prior concerns regarding the ambiguity of the previously stated criteria for “emergency conditions” in the standard, and to prevent the HSL NE implementation’s potential overuse of emergency proving (a zero-duration proving interval for HSLs) when link set outages occur. More specifically:

a. Former requirement R3-51 [226], which contained the previously proposed criteria for emergency proving, has been removed from the GR as it not longer applies given the revised T1S1 standard. It has been replaced with new requirement R3-51 [230]. This new requirement states that emergency proving shall be used for HSLs upon link set outage but only when the corresponding link set is undergoing emergency restart procedures . It refers to the more detailed Link Set Emergency Restart procedures specified in GR-246-CORE,[1] and for which more detailed criteria are specified in the following new (and separate) requirements objects.

b. New requirement R3-52 [231] has been added to specify that normal proving shall be used for HSLs when there is no link set outage, or upon link set outage when the corresponding link set is undergoing Link Set Normal Activation procedures. It refers to the more detailed Link Set Normal Activation procedures specified in GR-246-CORE.[1]

Consistent with the revised standard, the following additional requirements objects have also been added to clarify the specific network conditions under which the Link Set Emergency Restart and Link Set Normal Activation procedures are to be invoked for link sets containing HSLs.

c. A new requirement, R3-53 [232], has been added to specify the network conditions under which the HSL NE must apply Link Set Emergency Restart (i.e., link set outage with adjacent node isolation or local MTP Restart).

1–6

ab


d. New conditional objective CO3-54 [233] has been added to specify additional network conditions under which it is desirable for the HSL NE to apply Link Set Emergency Restart (i.e., link set outage with isolation of remote signaling points accessible via the link set, or severe local transmit congestion on alternate link sets). These additional criteria are subject to the ability of the HSL implementation to immediately detect the specified network conditions and whether it can do so without degrading the NE’s signaling performance or further delaying link restoration.

e. A new requirement, R3-55 [234], has been added to specify that the HSL NE must use normal link set activation procedures (rather than emergency link set restart procedures) when none of the network conditions specified in R3-53 [232] and CO3-54[233] apply to the restarting link set.

f. A new objective, O3-56 [235], has been added that the same link set emergency restart criteria applied to HSL link sets should also be applied to MTP2 link sets and any “mixed” (MTP2/HSL) link sets that may be configured at the HSL NE on a transitional basis.

g. New footnotes have been added to clarify relationships between the modified T1S1 standards for these criteria and the corresponding language used in the new requirements objects.

2. Section 3.3.2.2.3 (Interruption of Normal Proving Under Emergency Conditions). Objective O3-57 [228] has been modified to clarify the definition of “emergency conditions,” consistent with the modifications just described under revision item 1. Specifically, the former cross reference to now-removed requirement [226] in Section 3.3.2.2.2, has been replaced with a more appropriate cross-reference to the criteria specified in R3-53 [232] and CO3-54 [233]).

3. Appendix G (Notes on Protocol Standards Discrepancies). This appendix has been updated to reflect recent activity in ITU-T and ANSI T1S1 standards bodies to correct the cited errors in the standards documentation.

4. The References section has been updated to reflect the most current Issue numbers and and publication dates associated with the cited reference documents.

5. Global Editorial Revisions. Although these do not impact HSL NE functionality, several global editorial changes have been made for conformance with revised Telcordia documentation standards, which impact text throughout this document. These changes include the following.

a. The new corporate name of Telcordia Technologies (or Telcordia) has replaced that of its predecessor company throughout the text of this GR.

b. The document format and page headings have been changed throughout the document, which may impact the size of the printed image on each page, and thus may have caused requirements to shift to different page numbers from where they

1–7


GR-2878-CORE

were previously located. This may be the case even where there have been no substantive changes or additions to the requirements.

c. References to the SEASTM system have been updated to reflect the scheduled retirement of that system as a LEC operations system by the end of 1999. Where discussed in an historical context, it is now referred to as “the former SEASTM system.” Prior references to the SEASTM-STP and SEASTM-SCP node interfaces have either been removed or replaced by references to the NetPilotTM -STP interface or interfaces to other successor OSs that still utilize the same interface specifications. Such OSs include the NetPilot system’s own STP Configuration Management applications, as well as other SEASTM-successor OSs for other operations domains, which emulate the former SEASTM system through the NetPilotTM CCS Message Router function. Numerous requirements objects and explanatory text have been reworded to effect this editorial change in Sections 4 and 5, and in Appendix D. None of these revisions are substantive with respect to STP or SCP functionality.

These editorial revisions may result in the inclusion of change bars for many lines of document text. However, only the aforementioned revisions cited under revision list items 1 and 2 are regarded as functionally substantive.

1–8

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 HSL Signaling and Network Architecture

2. HSL Signaling and Network Architecture

This section provides an overview of the SS7 protocol architecture used for HSLs and the CCS network architecture into which HSLs will likely be deployed.

2.1 SS7 and ATM Protocol Architecture

2.1.1 Overview

The fundamental principle of the signaling system structure is the division of functions into separate modules or entities. These modules generally consist of a common transfer part and users of the transfer part. The function of the transfer part is to serve as a transport system providing reliable transfer of signaling messages between the locations of communicating users or application functions. The term User in this context applies to any functional entity that utilizes the transport capability provided by the transfer part.

In existing CCS networks, the Message Transfer Part (MTP), defined in Section T1.111 of GR-246-CORE, provides the transfer part functions. The MTP is further divided into three functional levels consisting of Signaling Data Link functions (MTP Level 1), Signaling Link functions (MTP Level 2), and Signaling Network functions (MTP Level 3).

Asynchronous Transfer Mode (ATM) is the signaling data link layer selected for the implementation of high speed (1.5-Mb/s) signaling links in the funding clients' CCS networks, replacing corresponding aspects of the existing MTP Level 2 and MTP Level 1 protocols. ATM is a specific packet-oriented data transfer and networking protocol using an asynchronous time division multiplexing technique to multiplex information flow in fixed-length blocks, called “cells”.

The protocol structure that will support the transport of signaling information on ATM is based on the BISDN Protocol Reference Model (PRM) described in the ITU-T Recommendation I.121,[15] B-ISDN Protocol Reference Model and Its Application. In this model, signaling data link functions are provided by an appropriate physical layer in combination with the ATM layer, signaling link functions are provided by the Signaling ATM Adaptation Layer (SAAL), and the signaling network functions are provided by MTP level 3.

The B-ISDN PRM uses the concept of three interactive plane structures: the User Plane, the Control Plane, and the Management Plane. The User Plane, with its layered structure, transfers the user information. The Control Plane, also with a layered structure, handles the call and connection control functions, including signaling. The Management Plane provides management application functions and a mechanism for information exchange between Control Plane processes and User Plane processes. The Control Plane functions are provided by the SAAL and the Management Plane functions are provided by the Layer Management (LM) entity. The physical and ATM layer functions are common to both the

2–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4HSL Signaling and Network Architecture December 1999

GR-2878-CORE

User Plane and the Control Plane. Various physical access rates for signaling can be implemented in the PRM and are specified for B-ISDN User-Network Interface (UNI) and Network-Node Interface (NNI) reference models. Implementation of a specific access rate is dependent upon the specific application need. For the HSLs described in this document, and as assumed to be used in most LEC narrowband CCS networks, the NNI reference model and a 1.544-Mb/s physical interface will be used.

The network signaling protocol model supporting high speed (1.5-Mb/s) signaling links is illustrated in Figure 2-1. The following subsections describe the protocol stack’s principal layers, sublayers and other functional modules.

2.1.2 Physical Layer

The physical layer provides a means for ATM cells to be transmitted on a transport facility. At this time, SONET, DS3, and DS1 have been specified as physical layers for carrying

Figure 2-1. High-Speed Link Protocol Model

AA

L5 C

P

1.5 -Mb/s.

Bit Stream

MTP 3

SSCF

SSCOP

AAL5 CPCS

AAL5 SAR

ATM

PHY(DS1)

Laye

r M

anag

emen

t

SS

CS

MTP 3

SSCF

SSCOP

AAL5 CPCS

AAL5 SAR

ATM

PHY(DS1)

Laye

r M

anag

emen

t

AA

L5 C

PS

SC

S

ATM&

PHY

SAAL

Sig.Layer

CCS NE CCS NE

2–2

ab


ATM cells. The physical transmission rates that have been specified include 2,488,320 Mb/s, 622.080 Mb/s, 155.520 Mb/s, 51.840 Mb/s, 44.736 Mb/s, and 1.544 Mb/s. For the high speed signaling link implementation, at this time, only the DS1 (1.544 Mb/s) rate is considered. DS1 access arrangements can take advantage of the embedded facilities currently available in LEC networks and would avoid the higher cost of SONET facilities. Transport of ATM cells over DS1 is accomplished by utilizing the direct mapping of ATM cells into the Extended Superframe Format (ESF) DS1 frame payloads. The mapping of ATM cells onto DS1 frames is described in TR-NWT-001112.[2] 1

The interface specification for the DS1 layer is provided in ANSI T1.646,[16] 2 Broadband ISDN and DS1/ATM User-Network Interfaces: Physical Layer Specification, TR-NWT-001112,[2] and GR-499-CORE.[4]

2.1.3 ATM Layer

Asynchronous Transfer Mode (ATM) is the chosen solution for the signaling-data-link layer of the HSLs described in this document. It is implemented directly above the physical layer (DS1 ESF).

2.1.3.1 Overview of ATM Technology

ATM is a specific packet-oriented data transfer and networking protocol using an asynchronous time division multiplexing technique. It can be used to support multiple permanent and switched “Virtual Channel Connections” (VCCs) multiplexed onto common underlying physical connections. The ATM virtual connections may be “channel-switched” via a network of ATM network elements, also called Broadband Switching Systems (BSSs). By utilizing such virtual connections, instead of dedicated physical channels, ATM can provide high data transfer efficiency and flexibility because it allows better utilization of the underlying physical layer (transmission facility) resources, and is capable of supporting very high data rates at high levels of performance in terms of low data transfer delays.

1. Note that the mapping of ATM cells over DS1 as described in TR-NWT-001112 is for the UNI. This is to be applied to 1.5-Mb/s HSLs at the NNI.

2. As standards letter ballots and contributions, these were formerly numbered T1E1 LB93-05 and T1E1.2/94-002 R1.

2–3


GR-2878-CORE

The multiplexed information flow on the ATM virtual connections is organized in fixed-size blocks, called cells. An ATM cell, shown in Figure 2-2, consists of an information field (called the cell payload) and a header.

Figure 2-2. ATM Cell Structure

The information field is transported transparently by the ATM layer, i.e., no processing (such as error control) is performed on the information field. The header size is 5 octets and the information field size is 48 octets. Cell sequence integrity is maintained on the ATM virtual connection. Cell sequence integrity implies that cells that originate at a connection end point are delivered at the destination end point in the same order in which they were transmitted.

To support their routing on the ATM virtual connections, through the ATM network, the ATM cells are each individually labeled, using a Virtual Path Identifier (VPI) field and a Virtual Channel Identifier (VCI) field in the header. These fields are used to associate the cell with a particular Virtual Path Link (VPL) and Virtual Channel Link (VCL) multiplexed over a given physical transmission link between two ATM nodes. Many VCLs may be carried within a single VPL. The VCI field in the ATM cell header associates each cell with a particular VCL over the given physical transmission link on which the cell is transmitted or received. Many VCLs and VPLs may terminate at a given physical transmission interface at an ATM NE or ATM network endpoint.

Each ATM NE can “cross-connect” VCLs terminating at its different physical interface ports to support pre-established routes for the cells through a network involving other ATM NEs. Together, the network of ATM NEs can support end-to-end virtual connections (VCs). Virtual connections through the ATM network are referred to as Virtual Channel Connections (VCCs) and Virtual Path Connections (VPCs). A VCC is a logical communication channel that provides for the transport of ATM cells between two connection endpoints. VCCs are therefore made up of one or more chained VCLs. All VCLs within a VPL share the same VPI value in the ATM header. In each VPL, VCIs are reserved for specific uses, including signaling between the ATM NEs. (Detailed discussions of VPI and VCI assignments for signaling channels are provided in Section 3.)

Header(5 Octet)

Payload(48 Octet)

2–4

ab


For signaling, an ATM virtual channel connection constitutes a signaling data link and can operate at rates of 64 Kb/s or higher, including the data rate of 1.536 Mb/s chosen for HSLs (i.e., 1.544 Mb/s less the DS1 framing overhead3).

2.1.3.2 Application of ATM to HSLs

For the specific application of ATM to the initial implementation of HSLs in LEC CCS networks, as defined in this document, each HSL shall be implemented as a direct, point-to-point (i.e., single-VCL) ATM VCC between two CCS nodes over a dedicated DS1 transmission link. That is, there shall not be any multiplexing of the ATM cells or any intermediate ATM NEs through which to switch or cross-connect any chained ATM VCLs to support the signaling data link. Only a single ATM VCL (at 1.536 Mb/s) supporting each HSL shall terminate at each CCS node’s physical DS1 interface. This is done to simplify operations and minimize the potential points of failure for each link. As such, HSLs deployed between CCS nodes do not require any interconnection between the narrowband CCS network and ATM NEs/BSSs. The CCS nodes must simply support the ATM-layer directly mapped onto a DS1 transmission link termination. A single VPI value of 0 and a single VCI value of 5 may be used for the VCL supporting each HSL. This treatment is consistent with the values used for the these identifiers on associated-mode signaling channels between ATM NEs in the Broadband ATM network.

The use of ATM at the data link layer will allow ATM NEs, which do not support the MTP2 link-layer protocol, to interconnect with CCS network nodes via HSLs in the future. Such interconnection will likely be necessary to support signaling interactions between the broadband and narrowband network environments, as discussed in Section 2.2.

A more detailed specification of the ATM layer is provided in ANSI T1.627,[17] Broadband ISDN - ATM Layer Functionality and Specification, and in GR-1113-CORE.[3]

2.1.4 Signaling ATM Adaptation Layer (SAAL)

Under the ATM protocol, an ATM Adaptation Layer (AAL) is defined to enhance the services provided by the ATM layer, so as to support the specific functions required by the next higher layer of the data communications protocol stack. One particular type of AAL service is the Signaling AAL (SAAL) which comprises the AAL functions necessary to support signaling. The SAAL consists of the following 4 sublayers or modules: the AAL Common Part (CP) type 5, the Service-Specific Connection Oriented Protocol (SSCOP), the Service-Specific Coordination Function (SSCF), and SAAL Layer Management (LM).

3. Under DS1 ESF, 1 of every 192 bits is reserved for framing, leaving 191 bits available for payload data. This corresponds to the 1.536 Mb/s of bandwidth available to carry ATM cells (out of the 1.544 Mb/s capacity of the DS1 transmission link) in the HSL application.

2–5


GR-2878-CORE

The SAAL at the Network Node Interface (NNI) provides signaling link functions for the transfer of signaling messages over one individual signaling data link. The SAAL functions provide for reliable transfer of signaling messages between two signaling points. A signaling message delivered by the higher SS7 protocol layers is transferred over the signaling link as a variable length SAAL Protocol Data Unit (PDU). A specific type of SAAL PDU, called an SSCOP Sequenced Data (SD) PDU is used to transport the signaling messages conveyed down the protocol stack by MTP level 3 (MTP3). Other SAAL (actually SSCOP) PDU types are used for signaling link management purposes, i.e., to convey the status of the signaling link to peer processes at the far-end signaling node and to control signaling link functions. The SAAL thus provides link layer functions comparable to those provided by MTP level 2 (MTP2) for conventional 56-Kb/s signaling links.

An overview of the SAAL is provided in ANSI T1.636,[18] Telecommunications - B-ISDN Signaling ATM Adaptation Layer - Overview Description.

2.1.4.1 Common Part (CP)

Several AAL CPs have been defined in ANSI T1.635:[5] Type 1, Type 3/4, and Type 5. The type 5 CP has been chosen to be used for signaling. The purpose of the Type 5 CP is to support those capabilities necessary to meet the upper layer data transfer needs while using the service of the ATM layer. The protocol provides for the transport of variable-length frames (from 1 to 65535 octets in length) with error detection capabilities. The frame is padded to align the resulting PDUs so as to fill an integral number of ATM cells. A 32-bit Cyclic Redundancy Check (CRC-32) is used to detect errors. The CRC checksum and a length indicator are encoded as fields within a data “trailer” transmitted along with the aligned data payload frame within a CP-AAL5 PDU. The length field is used by the far-end CP-AAL5 to extract the frame from the CP-AAL5 PDU and pass it up the protocol stack to the SSCOP sublayer of the SAAL.

The detailed protocol specification for the Type 5 CP used for HSLs is provided in ANSI T1.635.[5]

2.1.4.2 Service Specific Connection Oriented Protocol (SSCOP)

SSCOP is a connection-oriented protocol with error recovery capabilities. It provides a generic, reliable data transfer service for different AAL interfaces defined by the SSCF. SSCOP utilizes the services of the AAL Type 5 CP, which provides assured information transfer and a mechanism for the detection of corrupted SSCOP PDUs, as described in Section 2.1.4.1.

The protocol specification for the SSCOP is provided in ANSI T1.637.[6]

2–6

ab


2.1.4.3 Service Specific Coordination Function (SSCF)

The function of the SSCF is to map the services of the SSCOP of the AAL to the requirements of the invoking higher layer. For HSLs, the SSCF maps the services of the signaling SSCOP of the SAAL to MTP Level 3. The SSCF also provides communication with the SAAL Layer Management functional entity for proper operation of the signaling link. Two SSCFs have been defined for signaling: the signaling SSCF at the UNI and the signaling SSCF at the NNI. For HSLs, the SSCF format structure for the NNI will be used.

The protocol specifications for the SSCF is provided in ANSI T1.645.[7]

2.1.4.4 SAAL Layer Management

The SAAL layer management functions at the NNI perform a coordination function between Systems Management and the SAAL. The functions of layer management (LM) include error processing, measurements, and determination of link quality during proving and during normal operation.

The protocol specification for the SAAL Layer Management function is provided in ANSI T1.652.[8] That specification is based upon prior ITU-T recommendations specified in ITU-T Q.2144,[11] BISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI.

2.1.5 Signaling Network Layer (MTP - Level 3)

MTP level 3 (MTP3) provides those transport functions and procedures that are common to, and independent of, the operation of individual signaling links. These functions fall into two major categories:

(1) Signaling message handling functions: these functions direct the message to proper signaling link or higher level function.

(2) Signaling network management functions - these functions control the current message routing and information about the status of the signaling network. In the event of changes in the status, they also control re-configuration and other actions to preserve or restore the normal message transfer capability.

MTP3 functions for quasi-associated signaling remain independent of the signaling lower layer protocols, such as the signaling-data-link and link-layer functions provided by the SAAL and ATM, except for minor changes needed to support MTP3’s interface with the SAAL. Among those minor changes is an expansion of the message sequence number used within the MTP Network Management (MTP-NM) Changeover Order (COO) and Changeover Acknowledgment (COA) messages, to accommodate the longer sequence numbers used by the SAAL relative to those used for MTP2-based 56-Kb/s signaling links.

2–7


GR-2878-CORE

New MTP-NM message types, known as the Extended Changeover Order (XCO) and Extended Changeover Acknowledgment (XCA), support the longer SAAL-based sequence numbers and are used for HSLs in place of the COO and COA messages. Another change, which is actually a consequence of the signaling link using the SAAL in the protocol stack, is that the maximum message size for an MTP3 signaling message is no longer restricted to the previous maximum 272-octet size applicable to MTP2 Message Signal Units (MSUs) transmitted on conventional 56-Kb/s links. The SAAL shall be capable of supporting a corresponding maximum SSCOP PDU size of 4096 octets at that level.

More detailed discussions of HSL-specific MTP level 3 functions are provided in Section 3 of this document. Detailed specifications of the MTP3 functions can be found in GR-246-CORE,[1] Chapter T1.111.4.

2.2 HSLs in LEC CCS Networks - Topology Overview

2.2.1 HSL Deployment Drivers

HSL deployment is being planned in some LEC CCS networks in response to the following service-and-traffic-related drivers:

1. The need to provide additional CCS link capacity to accommodate the anticipated growth in signaling traffic volumes due to new or anticipated services and service-driven interconnection arrangements. Examples of such service and regulatory drivers include: Local Number Portability (LNP), interconnection with new Wireless Service Providers (WSPs) and Personal Communications Services (PCS) providers, CCS network unbundled access, and potential offerings of interLATA CLASSSM services. In addition, continued traffic growth is also expected in existing services, e.g., POTS call-set-up, 800/8NN Toll-Free Data Base Service, Alternate Billing Services (ABS/LIDB), intraLATA CLASS services, and Advanced Intelligent Network (AIN-based) services.

2. The need to address link port limitations in some existing CCS node architectures, which may become more acute given the anticipated number of new networks and service providers with which LEC CCS networks may need to interconnect in the future.

3. The need to maintain or improve end-to-end signaling delay performance for existing and new services under higher loads and increased interactions between signaling applications and data bases.

2–8

ab


4. As one solution to accommodate anticipated long signaling messages,4 exceeding the 279-octet limit imposed by the MTP level 2 (link layer) protocol.

5. The anticipated need to interconnect the narrowband CCS networks’ STPs to ATM NEs (Broadband Switching Systems [BSSs]) in the future, e.g., to support Broadband/ATM NE access to narrowband CCS network SCPs and to support other potential broadband/narrowband interworking interactions between the narrowband CCS SOs/SSPs and BSSs.

2.2.2 HSL Implementation at CCS Network Nodes

A signaling node can terminate both HSLs and 56-Kb/s MTP2 links. STPs supporting both link types shall be capable of relaying messages from any link to any other link. As discussed in Section 2.1, the HSLs will use the services of the SAAL CP, the SSCOP and the SSCF over the ATM layer. On reception of ATM cells at a signaling node, the SAAL CP-AAL5 within the node will reassemble them into appropriately formatted CP-AAL5 PDUs. These PDUs will then be reformatted as SSCOP PDUs and their MTP3 signaling data fields will be passed up the protocol stack to MTP level 3, using the services of the SSCF. If additional MTP routing is required, such as in the case of an STP, signaling messages will be routed internally within the node to the appropriate transmitter, which, if also a HSL, will then segment the messages into ATM cell payloads, before transmitting those cells over the ATM-based signaling links.

2.2.3 HSL Deployment in LEC CCS Networks

Figure 2-3 provides an overview of the network topology, including a view of potential HSL deployment in the CCS networks of the funding Telcordia clients.

Most large LECs are planning HSL deployment on at least some of their STP B-and-D link set quads (i.e., the network “backbone”), STP C-link sets, and SCP A-link sets, where traffic concentrations are expected to warrant them. HSL deployment on A-link sets to CCS SOs/SSPs is under consideration, primarily for very large access tandem switches. However, such deployment is viewed by most LECs as having lower priority because signaling message traffic volumes generated by most CCS SOs/SSPs on their A-links may not yet be high enough to justify them. That could change if either the signaling message volumes from SSPs increase drastically (e.g., due to new services or an increase in trunk connections needed for carrier interconnection), or if the need to accommodate long SCCP messages arises in the future (e.g., for evolving applications such as new AIN services and/or AIN Third Party Mediated Access) without the development of SCCP S&R capabilities.

4. The other solution to the long message problem being message segmentation and reassembly (S&R) provided by the SCCP, BISUP, and ISUP layers at signaling end points and/or at interworking STPs.

2–9


GR-2878-CORE

As shown in Figure 2-3, the first phase of HSL deployment is expected to involve the conversion of C-links between selected mated STPs, B-and-D link set quads between those selected STP pairs, and A-links between selected STP pairs and SCPs. These are the principal locations in the network where the traffic concentration is anticipated to be sufficiently high to justify the deployment of HSLs. Note that the actual order of conversion of 56-Kb/s signaling links to HSLs will be based on the specific needs of the respective LEC CCS networks and will likely be determined by the actual traffic loads to be supported on those links sets.

In the future, A-links from some selected SSPs (e.g., large end offices, access tandems, and principal LATA tandems), may be considered for conversion to HSLs if the traffic is sufficient to warrant it.

In general, all links in each link set shall be comprised of either 56-Kb/s MTP2 links or 1.536-Mb/s HSLs, except for transitional arrangements where both link types may coexist in the same link sets. Such arrangements shall exist only during interim periods at link conversion. (See also Section 9 below, regarding transitional considerations).

Expected signaling throughput and utilization levels of HSLs are to be consistent with traffic and network architecture considerations, including the traffic load, utilization objectives, the level 3 through-put capacities at either end, and expected traffic characteristics, including the message-size mix of traffic for different services.

√

Figure 2-3. LEC Potential HSL Deployment Plans

SCP

A LinksSSP

SSP

SSP

To Other STP Pairs

STP STP

Broadband ATM - NE

STPSTPB Links C Links

HSL

56 Kb/s linksFuture HSLs

2–10

ab


As defined in GR-82-CORE[12] for the 56 Kb/s-based CCS network, signaling link diversity objectives are also applicable to HSLs.

2.2.4 Potential Use of HSLs in CCS Network Interconnection

While HSLs will likely not be used for network interconnection during their initial deployment within the LEC CCS networks, there are a number of reasons why they may eventually be deployed for this purpose. If a LEC uses a single gateway STP pair to interconnect with multiple Interexchange Carriers (IXCs) or other LECs, then port limitations at the gateway STP may become a concern. HSLs could provide capacity relief by reducing the number of link ports utilized at the gateway STP, i.e., by replacing several MTP2 DS0-rate links to an interconnecting network with a single SAAL-based DS1 HSL. It is also possible that the interconnecting LECs and IXCs may want to upgrade their inter-network MTP2 56-Kb/s links to HSLs for reasons similar to the previously cited service and traffic drivers.

While interconnecting networks may have different architectures and different internetwork traffic volumes, the interconnecting D-link set quads are likely candidates for the eventual conversion to HSLs. D-link set quads, in general, can carry the largest volumes of traffic and have the highest potential for growth. Figure 2-4 shows an example architecture for network interconnection when HSLs are used for a D-link set quad to a large IXC. Note that the interconnected small LEC also depicted in the example of Figure 2-4 uses MTP2 56-Kb/s A-links to interconnect to the LEC gateway STP pair and as such does not likely have sufficient signaling traffic to require HSLs.

GR-2946-CORE,[19] CCS Network Interface Specification (CCNIS) Supporting Network Interconnection using High Speed Signaling Links (HSLs), provides functional requirements for a HSL-based CCS network interface, including the parameter information that needs to be exchanged between the interconnected networks’ administrations.

2.2.5 Potential Future HSL Application to Broadband Network Interworking

In addition, as depicted at the lower-left side of Figure 2-3, LECs may also consider using HSLs to interconnect selected ATM NEs, i.e., Broadband Switching Systems (BSSs), directly with their narrowband CCS networks (e.g., via A-links to a pair of STPs or via B-links from ATM BSSs having the STP function). Those HSLs would conform to the requirements specified in this GR. Such interconnection could provide the ATM NEs with signaling access to the narrowband CCS network’s Service Control Points (SCPs) and would also support other signaling interactions between the two network environments, such as connection-control interworking through Interworking Broadband Switching Systems (I/W BSSs), or broadband/narrowband interworking units (IWUs) and terminal adapters (TAs) associated with the BSSs.

2–11


GR-2878-CORE

Currently, evolving Broadband/ATM networks are typically separate from the LECs’ narrowband Public Switched Networks (PSNs) and CCS networks, the latter of which now support call and connection control signaling for the narrowband PSN only. The Broadband/ATM networks currently utilize associated-mode signaling over signaling-channel Virtual Connections (VCs) between the interconnected ATM BSSs, parallel to the bearer-channel VCs. However, potential signaling needs for proposed broadband services or service features may require Broadband/ATM network interconnection with the LECs’ current CCS networks in the future. Figure 2-5 illustrates the potential network architecture, including the network interworking arrangements that would be needed to support these types of signaling interactions.

The deployment of HSLs thus positions the narrowband (NB) CCS network’s STPs to support such interconnections and interworking arrangements in the future.

Figure 2-4. Example Architectures for HSLs Used in CCS Network Interconnection

STP STP

STPSTP

HSL

56-Kb/s links

LEC Gateway STP pair

Large Interconnecting Network’s STP pair

(e.g., large IXC)

CCS SOs/SSPs

Interconnecting -Small LEC

CCS Network

2–12

ab


Figure 2-5. Potential CCS Network - Broadband Network Interconnection Architecture

SAAL HSL Link Set (1.5 Mb/s)

MTP2 Link Set (56 Kb/s)

NB Circuit-Switched MessageTrunk Group

BB/ATM Signaling Channel VCLBB/ATM Bearer Channel VCL

IWU IWU

NB STPs

NB SCP

CCSSO/SSP

ATM BSS

CCSSO/SSP

ATM BSS

ATM BSSsWith STPFunction

ATM BSS ATM BSS

BB SCP

Narrowband (NB) CCS Network

Broadband (BB) ATMNetwork

HSLs

2–13


GR-2878-CORE

2–14

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Network Element Requirements

3. Network Element Requirements

3.1 ATM and Physical Layer Requirements

3.1.1 ATM Layer Requirements

ATM is a high-bandwidth multiplexing and switching technology that provides flexible networking by using fixed length packets, called ATM cells. The ATM cell consists of two parts: a 5-octet header and a 48-octet information field (payload). The ATM cell header includes routing fields (i.e., Virtual Path Identifier (VPI) and Virtual Channel Identifier (VCI) fields), as well as fields to indicate the type of information contained in the payload, fields used by Header Error Control (HEC) functions, and the Cell Loss Priority (CLP), which is to be used when traffic from multiple VCLs on the physical transmission link is in contention. The ATM cell information field contains the actual information that is to be transported over the network. Figure 3-1 shows the ATM cell structure.

Figure 3-1. ATM NNI Cell Structure

ATM cells are each individually labelled, using the VPI/VCI fields in the header, for a preestablished route. These fields associate the cell with a particular connection through the network. Connections in the ATM network are referred to as Virtual Channel Connections (VCCs) and Virtual Path Connections (VPCs). VCCs are made up of Virtual Channel Links

12345678

VPI

VPI VCI

VCI

VCI PTI

Information Field

48 Octets

1

5

.

.

.

.

6.......

HEC

CLP

3–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Network Element Requirements December 1999

GR-2878-CORE

(VCLs) between network nodes. The VCI field in the ATM cell header associates each cell with a particular VCL over a given physical link.

Many VCLs may be carried within a single Virtual Path Link (VPL). All VCLs within a single VPL share the same VPI value in the ATM header. For HSL connections, only a single VPI and a single VCI within the VPI is considered sufficient, because a dedicated DS1 physical layer connection will be used to support the HSL’s VCC.

The purpose of the ATM layer protocol is to provide a common set of services to the ATM layer users. The fundamental service of the ATM layer in a signaling node is to transfer information received from the CP-AAL5 (CP-AAL5 PDUs) after adding ATM header information (5 octet cell header) over the ATM virtual connection. The virtual connection that is to be established over the physical layer is described in Section 3.1.2. The CCS nodes with high speed signaling links (henceforth referred to as “HSL NEs” shall conform to Requirements [1], [2], and [3] to provide ATM layer functionalities.

R3-1 [1] The HSL NE shall provide the ATM layer functionalities as described in Section 2 of GR-1113-CORE,[3] including the specific requirements listed in this section.

R3-2 [2] The ATM cell structure coding shall conform to the coding structure defined in GR-1113-CORE[3] for the NNI (Network-Node-Interface) format.

R3-3 [3] The HSL NE shall use the VPI and VCI fields to identify the ATM signaling link.

For signaling applications in the CCS network, VPI=0, and VCI=5 will be generally used. However, it shall be possible to configure VPI and VCI values through the configuration management function. See Section 4 for further details.

3.1.2 Physical Layer Requirements

DS1/T1 has been chosen as the physical layer for HSLs. Other physical layer interfaces are possible for future implementations. Current needs for the bandwidth in funding clients’ CCS networks can be met by a DS1-rate interface. However, as those networks evolve with increasing deployment of SONET facilities, SONET OC/STS-1 and OC/STS-3 may become desirable in the future. In the near term SONET interfaces and DS3 interfaces to the HSL NE are not perceived to be cost effective. Sub-STS-1 SONET interfaces (i.e., VT and VTG) are being defined in standards bodies, but the requirements for these interfaces are not considered sufficiently matured for this application.

Generic Requirements for the B-ISDN User-to-Network Interface (UNI), TR-NWT-001112,[2] describes physical layer requirements for the DS1 UNI. DS1 requirements for

3–2

ab


the NNI are currently under study in ANSI. TR-NWT-001112[2] addresses the following parameters applicable for the physical layer at CCS nodes:

• Bit Rate (1.544 Mb/s)

• Interface Symmetry (interface is symmetrical)

• Signal Format

— Extended Superframe Format (ESF) (per GR-499-CORE[4] and ANSI T1.403,[20] Network and Customer Installation Interfaces - DS1 Electrical Interface)

— ATM Cell Mapping (Direct Mapped per TR-NWT-001112[2])

— Cell Rate Decoupling (Unassigned cell insertion/removal per GR-1113-CORE[3])

• Power (no power on T1 interface)

• Header Error Control (HEC) Generation and HEC Check (per Section 10 of TR-NWT-001112)[2]

• Self-Synchronous Scrambler (not supported on DS1 interfaces)

• Cell Delineation (per Section 10 of TR-NWT-001112)[2]

• Physical Layer Maintenance (per GR-499-CORE[4] and ANSI T1.408,[21] ISDN Primary Rate - Customer Installation Metallic Interfaces, Layer 1 Specification, including

— Support of bit-oriented alarm messages

— Support of bit-oriented loopback messages

— Support for performance monitoring.

• PMD Characteristics of the 1.544-Mb/s UNI (per GR-499-CORE[4] and ANSI T1.403[20]), including

— Line code (B8Zs)

— Pulse shape (Figure 9-5 in GR-499-CORE)[4]

— Power levels (Table 9-13 in GR-499-CORE)[4]

— Pulse imbalance (Table 9-13 in GR-499-CORE)[4]

— Pulse density (Table 9-13 in GR-499-CORE)[4]

— Jitter and wander (Table 9-13 in GR-499-CORE).[4]

R3-4 [4] The HSL NE shall conform to the physical layer requirements described in Section 8 of TR-NWT-001112[2] with the exception of the synchronization requirements and the specified connector.

3–3


GR-2878-CORE

The ESF format provides some functionality that may be useful to operations personnel and operations systems in maintaining and trouble-shooting signaling links. In particular, the CRC-6 provides a measure of error performance and the bit-oriented messages provide an end-to-end line loopback capability. The loopback capabilities are not as powerful as those available via the DS0A interface, since none of the intermediate points along the DS1 path can be looped back. The loopback provides only an end-to-end loopback capability for the physical layer connection. The performance monitoring capabilities may be useful for sectionalization, if the transmission equipment along the DS1 path supports “Intermediate Performance Monitoring” as described in Section 2.6.5 and Section 3.6 of GR-820-CORE,[22] Generic Digital Transmission Surveillance. These capabilities provided by the ESF will be useful in sectionalizing problems to either the physical layer or higher layers.

R3-5 [5] The HSL NE physical layer interface shall generate a DS1 signal conforming to the Extended Superframe Format (ESF) as described in GR-499-CORE.[4]

3.1.2.1 Synchronization Requirements

TR-NWT-001112[2] requires that DS1 signals carrying ATM cells be Primary Reference Source (PRS) traceable. A PRS is a highly accurate clock that is at the top of the synchronization signal hierarchy and is used to time a network. GR-436-CORE,[23] Digital Synchronization Network Plan, describes the synchronization network that is used to achieve PRS traceability. All synchronized elements within a central office take their timing from the office BITS (Building Integrated Timing Supply) clock. The BITS clock is the master clock for the office. If the BITS clock fails, the network element reverts to its internal clock. This is one advantage of DS1 links compared to DS0A links. DS0A links require phase alignment between transmitter and receiver to operate. The phase alignment is provided by the Composite Clock (CC) signal from the BITS clock. If the CC signals from the BITS clock fails, the DS0A links would also fail. DS1 interfaces clock data into a buffer with a clock that is recovered from the DS1 signal itself. Therefore, DS1 interfaces do not need a phase reference from an external signal, and with the DS1 interface, the link will not fail or degrade if the external reference from the BITS clock is lost. The DS1s should not be terminated at slip-buffers and therefore no data should be lost during frequency offset conditions. There is no need for slip-buffers since the DS1 is not channelized. Cell-rate decoupling, as described in GR-1113-CORE,[3] provides for frequency accommodation between the physical layer and the ATM layer. The cell-rate decoupling is capable of accommodating frequency offsets at the DS1 layer, as long as the ATM layer is not using more than the full DS1 capacity.

The DS1 signal should be timed from the systems main clock. In central office environments, the system clock shall be externally timed by the office BITS clock. In environments where no BITS is available, the system clock may be line-timed, i.e., timed by one of its traffic interfaces. If the system should enter holdover, the frequency of the DS1

3–4

ab


may drift but this should not affect performance as DS1 data throughput should be maintained without data loss due to slip buffers and cell rate decoupling.

R3-6 [6] The HSL NE shall support the external timing mode as defined in GR-1244-CORE,[24] Clocks for the Synchronized Network: Common Generic Criteria. The external timing mode would require the HSL to support redundant input.

R3-7 [7] The HSL NE shall be able to switch between inputs as described in GR-1244-CORE.[24]

CR3-8 [8] The HSL NE may be required to support the line-timing mode, as described in GR-1244-CORE,[24] if deployed in environments where no BITS clock is available to provide external timing.

R3-9 [9] The HSL NE shall provide a stratum 4 clock to provide a free-run clock if all timing references are lost. Requirements for stratum 4 clocks are provided in GR-1244-CORE.[24]

3.1.2.2 Connector

R3-10 [10] An appropriate connector based on the specific switching office needs shall be provided.

3.2 Signaling ATM Adaptation Layer (SAAL) Requirements

The SAAL consists of a Segmentation and Reassembly (SAR) layer and a Convergence Sublayer which is specified as two sublayers: a Common Part Convergence Sublayer (CPCS) and a Service-Specific Convergence Sublayer (SSCS). The SSCS is functionally divided into two parts: the Service Specific Connection Oriented Protocol (SSCOP), which provides an assured data transfer service and the Service Specific Coordination Function (SSCF). The SSCF at the NNI performs a coordination function between the service required by the Message Transfer Part (MTP) Level 3 and the service provided by SSCOP. Layer Management (LM) at the NNI provides, or supports, the SSCS with measurements and error processing functions.

3.2.1 AAL Type 5 Common Part

The AAL Type 5 Common Part shall be used to support the capabilities necessary to meet the upper layer data transfer needs while using the services of the ATM layer. The Service Specific Part (SSP) of the AAL5 shall be used to provide those capabilities.

3–5


GR-2878-CORE

R3-11 [11] The HSL NE shall utilize the AAL Type 5 Common Part as specified in Section 8 of GR-1113-CORE.[3]

R3-12 [12] The Max_SDU_Deliver_Length parameter in the CP-AAL5 shall be set to 4100 octets to support SSCOP PDUs as long as 4096 octets.

3.2.2 SSCOP-Related Requirements

3.2.2.1 General

The SSCOP provides the link layer functions in the high speed (1.5 -Mb/s) signaling link protocol model including the following functions:

• Sequence Integrity: for SSCOP SDUs

• Error Correction by selective Retransmission: Correction of sequence errors through retransmission

• Flow Control: controlling the rate at which the peer SSCOP entity may send information

• Error Reporting to Layer Management: reporting of detected errors to the Layer Management entity, if necessary

• Keep Alive: keeping the link connection in an established state when prolonged absence of data exchange occurs during connection setup

• Local Data Retrieval: capability to retrieve in-sequence SDUs not yet transmitted, if necessary

• Connection Control: capability to provide the necessary functions to establish, release, and resynchronize an SSCOP connection

• Protocol Error Detection and Recovery: capability to detect and recover from the errors in the operation of the protocol

• Status Reporting: the exchange of status information between the SSCOP peer entities.

ANSI T1.637[6] provides the detailed descriptions for each of these functions.

R3-13 [13] The HSL NE shall conform to the SSCOP protocol as defined in ANSI T1.637[6] and including Requirement R3-14 [14].

R3-14 [14] The SSCOP shall implement Credit and peer-to-peer flow control as specified in ANSI T1.637[6] for the SSCOP SD PDUs and conform to the intent and clarifications provided in Section 3.2.2.2.

3–6

ab


3.2.2.2 Credit Determination and Peer-to-Peer Flow Control

Receiver (i.e., peer-to-peer) flow control is based on the receiving SSCOP reducing “credit” to prevent the transmitting SSCOP from sending additional PDUs. As stated in the SSCOP protocol specification, T1.637,[6] the amount of receive buffer storage available should, in principle, match or exceed the credit granted to the transmitter. The conditions under which credit is reduced and the processes used to reduce credit are implementation-dependent, but should be related to the amount of receive buffer space allocated to the signaling link and the bandwidth/delay of the connection, and should minimize the possibility of message loss. The maximum amount of time a receiver can reduce the credit to 0 without causing the transmitting end of the signaling link to fail the link depends on the amount of time a transmitter can tolerate having no credit, which is specified in the Layer Management requirements (see Section 3.2.4). Peer-to-peer flow control using the credit mechanism can also be applied to control the rate at which the receiver will accept the PDUs. The rate of PDUs allowed at the receiver can be a function of the local congestion state of the link. That is, if an SSCOP entity detects that the received PDUs can not be delivered to the higher layer (e.g., MTP 3) due to congestion at the higher layer, the SSCOP may elect to suspend the acceptance of new SD PDUs by lowering the credit allowed to the transmitter. Determining the suitable mechanism for credit assignment and flow control should take into considerations the buffer size, the processing restrictions at the higher layers, and link error characteristics.

Annex F of T1.637[6] provides a basis for the establishment of a default window size. Annex F states that the receive buffer size should be adequate for two POLL time periods and three round trip delays. Appendix A of this GR discusses this Annex and identifies two methodologies for determining the buffer size and credit window for high speed (1.5 -Mb/s) signaling link applications in CCS nodes.

O3-15 [15] The receive buffer size and credit window in the HSL NE should conform to the guidelines described in Appendix A. Selection of either of the two methodologies (Fixed credit or Moving credit) is dependent on the particular implementation.

In addition, Appendix F of this GR presents additional considerations regarding the performance of the SAAL flow-control mechanism and its relationship to the MTP level 3 Signaling Message Handling (SMH) congestion control functions that protect an STP’s level 3 processor from becoming overloaded.

3.2.3 SSCF-Related Requirements

The SSCF is the uppermost sublayer in the SAAL protocol stack. Utilizing the services of underlying SAAL sublayers and its own functions, the SSCF provides SAAL service to the SAAL user (i.e., MTP3 in the case of HSLs). The SSCF functions include

3–7


GR-2878-CORE

• Mapping: mapping of SSCF signals between the SSCOP and MTP3

• Local Retrieve: supporting the changeover procedure in MTP level 3

• Flow Control: congestion control using four levels of congestion as described for MTP level 3

• Change Link Status: providing link status and control information to MTP level 3 and to the SSCOP

• Reporting to Layer Management: the reporting to layer management of events concerning the status of the SSCOP connection and PDUs received in error.

In addition to the previous list of functions, the SSCF also facilitates the exchange of processor outage information when it is notified by the layer management of a processor outage condition. When the SSCF is informed of the processor outage, it releases the SSCOP connection by sending an AA-Release request to SSCOP and informs MTP level 3 via an AAL-OUT_OF_SERVICE signal. ANSI T1.645[7] describes in detail the procedures for the processor outage condition. The SSCF also provides link alignment functions, including proving, as described in ANSI T1.645.[7]

R3-16 [16] The HSL NE shall conform to the SSCF protocol as defined in ANSI T1.645,[7] including Requirement R3-17 [17].

R3-17 [17] The SSCF shall implement flow control procedures as defined in ANSI T1.645[7] including the national multiple congestion levels option described in Section 3.3.2.1 of this GR (Congestion Control).

3.2.4 Layer Management-Related Requirements

The layer management function provides the interfaces to the SSCOP, to the SSCF and to Systems Management. The layer management functions include

• Error processing

• Measurements

• Notification of processor outage status

• Determination of link quality during proving

• Determination of link quality during normal operation.

R3-18 [18] The HSL NE shall conform to the Layer Management protocol specification as provided in ANSI T1.652,[8] including the clarifications and requirements provided in the following sections.

3–8

ab


3.2.4.1 Error Monitoring for In-Service Signaling Links

The error monitoring procedures for determining when the error rate on an in-service signaling link becomes intolerable and when the link should be taken out of service are described in ANSI T1.652.[8] ANSI T1.652[8] provides a description for the In-Service error monitor in Annex B. Appendix B of this document provides a discussion of the error monitoring methods presented in ANSI T1.652[8] and addresses issues that should be considered for implementation in the HSL NE.

R3-19 [19] The HSL NE shall implement an error monitoring algorithm as described in ANSI T1.652.[8]

3.2.4.2 Determination of Failed Proving Attempts

The determination of a failed proving attempt is made by Layer Management. It uses the MAA-ERROR.indications it receives from SSCOP to measure PDU transmission errors during proving and MAAL-REPORT.indication signals from the SSCF to determine the status of proving attempts.

The SSCF notifies Layer Management of the beginning of proving with the MAAL-PROVING.indication. Upon determination that the proving attempt has failed, Layer Management sends a MAAL-PROVING-UNSUCCESSFUL.request signal to SSCF.

R3-20 [20] The HSL NE shall provide the procedure to determine failed proving attempts in Layer Management in accordance with ANSI T1.652.[8] Appendix B of this document provides a discussion of the proving algorithm contained in ANSI T1.652.[8]

The default period for normal proving is determined by the number of messages sent during normal proving and the time interval between transmission of successive proving PDUs (LM parameters n1 and T3 in Table 3-1 of this document) as described in ANSI T1.645.[7] For 1.5-Mb/s SAAL links, the normal proving period is 1 minute and the emergency proving period is zero.

3.2.4.3 Forced Proving Procedures to Prevent Link Oscillations

Layer management may override the decision of whether to perform normal or emergency proving, which is usually made by the local user of the SSCF, i.e., MTP level 3 for HSLs. It may do so by using the MAAL-FORCE_PROVING.request to notify the SSCF to use forced proving, by using the MAAL-FORCE_EMERGENCY.request to instruct the SSCF to use emergency proving (no proving period), and the MAAL-CLEAR_FORCE_MODES.request to cancel forced normal proving or forced emergency proving.

3–9


GR-2878-CORE

For HSLs, the layer management function will include a capability to override an emergency proving request from MTP level 3, in cases when the link is known to have recently recovered from link failure, so as to minimize the possibility of link oscillation (i.e., placing the link into service and then taking it out-of-service quickly). Link oscillations might otherwise occur, given that a zero proving period applies to HSLs under emergency conditions (e.g., when no routes are available to a given destination).

R3-21 [21] The layer management function shall use a timer (Timer_FORCE-PROVING) to monitor the status of the link after it is placed into service upon successful completion of proving (normal or emergency). Timer_FORCE-PROVING shall be started when proving is completed and the link is placed into service at the SAAL.

R3-22 [22] If the link goes out-of-service due to link failure before Timer_FORCE-PROVING expires, Layer Management shall issue a MAAL-FORCE-PROVING.request to the SSCF to force a normal proving period for the link. However, the MAAL-FORCE-PROVING.request shall not be issued if the link is removed from service at the SAAL by management action.

R3-23 [23] If Timer_FORCE-PROVING expires before the link goes out-of-service, Layer Management shall issue a MAAL-CLEAR_FORCED_MODES.request to the SCCF.

R3-24 [24] Timer_FORCE-PROVING shall be provisionable to a value between 0 and 20 minutes with a default value set at 10 minutes.

The normal proving procedure, invoked during link restoration either under normal conditions, or forced under emergency conditions per the indicated requirements, should effectively prevent link oscillations because of the duration of the normal proving period (i.e., whose default value is 60 seconds). Because of this, the MTP level 3 link oscillation filter (LOF), which is required to prevent link oscillations on MTP2-based 56-Kb/s signaling links at STPs, may not be needed for HSLs. (See also Section 3.3.2.6 [Use of the MTP3 Link Oscillation Filter for HSLs at STPs].)

The HSL NE is expected to override the forced proving procedure for manually initiated link restorations as addressed in the following conditional requirements.

CR3-25 [203] If the HSL NE implementation supports User System Interface (USI) commands or maintenance channel interface commands to initiate the manual restoration of signaling links, it shall override (not apply) the forced proving procedure as defined in Requirement R3-23 [23], i.e., it shall allow emergency proving, when such manual restorations are invoked during emergency conditions and Timer_FORCE-PROVING has not expired. This override of the forced proving procedure shall apply only

3–10

ab


to the HSL NE’s first emergency proving action for a HSL when manual restoration is invoked and the link is forced into service. Timer_FORCE-PROVING shall be reset upon completion of emergency proving and the forced proving procedure shall be invoked for any subsequent automatic emergency proving attempts if the HSL should fail while Timer_FORCE-PROVING is running.

CR3-26 [204] If the HSL NE implementation supports USI or maintenance channel interface commands to initiate the forced manual restoration of signaling links by forcing emergency proving (regardless of whether emergency conditions apply), it shall override (not apply) the forced proving procedure as defined in Requirement R3-23 [23], i.e., it shall allow emergency proving, when such forced manual restorations are invoked and Timer_FORCE-PROVING has not expired. This override of the forced proving procedure shall apply only to the HSL NE’s first emergency proving action for a HSL when forced manual restoration is invoked and the link is forced into service. Timer_FORCE-PROVING shall be reset upon completion of emergency proving and the forced proving procedure shall be invoked for any subsequent automatic emergency proving attempts if the HSL should fail while Timer_FORCE-PROVING is running.

3.2.4.4 Timer for No Receipt of Credit

The ANSI T1.652[8] specification indicates that the SSCOP notifies Layer Management using the MAA-ERROR.indication signal when it has a PDU to transmit but does not have any credit. When Layer Management receives this signal, it will start Timer_NO-CREDIT. Upon expiration of Timer_NO-CREDIT, Layer Management sends the MAAL-RELEASE.request signal to the SSCF.

R3-27 [25] The HSL NE shall provide a Timer_NO-CREDIT in Layer Management. Timer_NO-CREDIT shall be started when Layer Management receives a MAA-ERROR.indication signal from SSCOP indicating lack of credit. Timer_NO-CREDIT shall be stopped when Layer Management receives a MAA-ERROR.indication signal from SSCOP indicating credit was obtained. As given in Table 3-1, Timer_NO-CREDIT shall have a configurable range of 1 to 6 seconds, and a default value of 1.5 seconds. If Timer_NO-CREDIT expires, Layer Management shall send a MAAL-RELEASE.request to SSCF to release the connection (i.e., fail the signaling link)1.

1. A similar function is performed in MTP level 2 links via timer T6, as described in Section 9.3 of Chapter T1.111.3 of GR-246-CORE[1].

3–11


GR-2878-CORE

3.2.4.5 Peer-to-Peer Layer Management Communications

Peer-to-peer layer management communications using the MAA-UNITDATA signal is for further study.

3.2.5 Other - SAAL Related Requirements

3.2.5.1 Signaling Link Speed

ATM virtual channels (i.e., signaling data links) shall be provided to the SAAL at a rate of 1.536 Mb/s. Additional considerations for signaling link throughput and engineering are provided in Section 8. The equivalent peak transmission rate of ATM cells, including any OAM cell overhead, is given in Requirement R3-28 [26].

R3-28 [26] The network element supporting high speed links shall support a peak bandwidth of 3,622 ATM cells/second available to the SAAL layer for each HSL.

3.2.5.2 PDU Lengths

The current MTP Level 2 protocol allows message lengths up to 265 octets (or 272 octets including the MTP Level 3 routing label). The SAAL allows PDUs to have lengths up to a maximum of 4096 octets.

It should be noted that unless end-to-end connectivity is provided on high speed links, message routing complications, including message loss, may result. Handling of longer messages are under study. See also Section 3.3.1.1 for requirements relating to the routing of longer messages through HSL STPs.

3–12

ab


3.2.6 SAAL Timer and Parameter Values

Default timer and parameter values are given in Table 3-1 for the SSCOP, SSCF, and Layer Management entities of the SAAL. Each of the timers and parameters (except parameters k and j) must be provisionable by operating company personnel. Tolerances are also provided for each timer. The tolerance of a timer is a range relative to the provisioned value (i.e., plus or minus a percentage) within which the actual duration of a timer must be measured (see Table 3-1). Minimum settable ranges are specified, within which each timer must be capable of being provisioned. Additional requirements regarding the administration of these and other HSL parameters are presented in Section 4.2, Configuration Management (Memory Administration).

R3-29 [27] The HSL NE shall use the timer and parameter nomenclature and default values provided in Table 3-1 for the SSCOP, SSCF, and Layer Management. See Section 7.7 of ANSI T1.637,[6] ANSI T1.645,[7] and ANSI T1.652,[8] for further details on these parameters and timers.

R3-30 [28] The timer and parameter values provided in Table 3-1 (except k and j) shall be provisionable within the minimum settable ranges specified in Table 3-1.

3–13


GR-2878-CORE

Table 3-1. SAAL Timers and Parameters

Timers or Parameters Default Valuea Minimum Settable Range

Tolerance

k (Maximum SSCOP SDU size) 4096 octets Not applicable Not applicable

j (Maximum SSCOP-UU size) 4 octets Not applicable Not applicable

MaxCC (Maximum number of unacknowledged BGN, END, ER, or RS PDUs)

4 PDUs 1 - 10 PDUs Not applicable

MaxPD (Maximum number of SD PDUs sent between POLL PDUs)


MaxSTAT (Maximum number of list elements in a STAT PDU)


Timer_CC (Time between transmission of unacknowledged BGN, END, ER, or RS PDUs)

200 msec 100-2000 msec

± 10%

Timer_KEEP-ALIVE (for 3622 cells/sec signaling rate)

100 msec 25 - 500 msec ± 10%

Timer_NO-RESPONSE (Maximum time interval during which at least one STAT PDU must be received)

1.5 sec 0.2 - 2.0 sec -5%, +20%

Timer_POLL (for 3622 cells/sec signaling rate)

100 msec 25 - 500 msec ± 10%

Timer_IDLE (Maximum time of the IDLE phase of an SSCOP connection)

100 msec 25 - 1000 msec

± 10%

Timer_T1 (Time between link release and re-establishment during alignment)

5 sec 1 - 15 sec ± 10%

Timer_T2 (Time SSCF will attempt alignment)

120 sec 15 - 180 sec ± 10%

Timer_T3 (Time between proving PDUs)

1000 µsec 276-25000 µsec

± 10%

n1 (PDUs sent during normal proving)

60000 PDUs 500-500000 Not applicableSSC

F (

T1.

645)

SSC

OP

(T

1.63

7)

3–14

ab


Note that the default values for SCCF parameters T2, T3, and n1 are different from those given in ANSI T1.645.[7] The default values in ANSI T1.645[7] are considered to be inadequate to verify during proving that the link quality is sufficiently high to ensure that the link is likely to stay in service. The default values cited in Table 3-1 are consistent with those recommended in Annex B of ANSI T1.652[8] and do verify that link quality is sufficient to keep the link in service when the reference In-Service Error Monitor defined in that annex is used. Since the default normal proving period that results from the default values of SCCF parameters n1 and T3 is 60 seconds, normal proving will not successfully complete if T2 is set to the ANSI T1.645[7] recommended default value of 30 seconds.

3.3 Message Transfer Part - Level 3

As discussed in Section 2, network layer functions of the Message Transfer Part (MTP) Level 3 will be used for high speed links. MTP Level 3 (MTP3) performs two functions: routing messages to the correct link or MTP application (Signaling Message Handling) and controlling routing in response to changes in the status of CCS network components (Signaling Network Management).

Max_NRP (Maximum number of retransmitted SSCOP PDUs permissible for link proving)

1 0 - 10 Not applicable

Timer_REPEAT-SREC (Minimum interval between reports of an SSCOP recovery)

1 hour 0.5 - 24 hours ± 10%

Timer_NO-CREDIT (Maximum interval without credit)

1.5 sec 1 - 6 sec. ± 10%

T_sup (Superblock size) 120 sec 10 - 600 sec Not applicable

T_loss (STAT loss limit) 1.3 sec 0.5 - 10 sec Not applicable

α [alpha](Exponential smoothing factor)

0.1 0 - 1.0 Not applicable

thres (Threshold for comparing the running Quality of Service)

0.244 0 - 1.0 Not applicable

τ [Tau] (Error monitoring interval) 100 msec 25 - 250 msec ± 10%

N_blk (Monitoring intervals per block)

3 intervals 1 - 25 intervals Not applicable

N (Monitoring intervals after 400 ms error event)

9 intervals 1 - 25 intervals Not applicable

Timer_FORCE-PROVING 10 minutes 0 - 20 minutes ± 10%

a. for all signaling rates unless otherwise specified

Table 3-1. SAAL Timers and Parameters (Continued) L

ayer

Man

agem

ent

(T1.

652)

3–15


GR-2878-CORE

3.3.1 Signaling Message Handling

The MTP signaling message handling function ensures that signaling messages originated at a User Part are reliably transferred to the user part at the destination node.

R3-31 [29] The HSL NE shall perform the MTP signaling message handling functions discussed in Section 2 of Chapter T1.111.4 of GR-246-CORE.[1] The HSL NE, based on the functionalities being provided (i.e., switch, STP, or SCP) shall also conform to the additional requirements described in GR-82-CORE,[12] GR-606-CORE,[13] or GR-1241-CORE,[14] as applicable.

3.3.1.1 Message Routing

The message routing function determines the signaling link over which each outgoing message is sent. An outgoing link set (or a combined link set) is determined on the basis of the destination point code in the message routing label and a particular link within the link set selected on the basis of the Signaling Link Selection (SLS) field.

For HSLs, signaling message routing functions at the CCS nodes will be in accordance with the descriptions and requirements provided in GR-246-CORE[1] and in Section 4.2.3.2 of GR-82-CORE.[12]

R3-32 [30] The HSL NE shall provide the signaling message routing functions as discussed in Section 2.3 of Chapter T1.111.4 of GR-246-CORE.[1] The HSL NE, based on the functionalities being provided (i.e., switch, STP, or SCP), shall also conform to the message routing requirements described in GR-82-CORE,[12] GR-606-CORE,[13] and GR-1241-CORE.[14]

In the current implementation of 56 Kb/s MTP2 signaling links, MTP level 3 messages of up to 272 octets of user information, including the routing label and service information octet, can be transferred to MTP level 2. In a HSL NE, it is possible that MTP level 3 may receive messages from the User Part of the SAAL (i.e., level 3) of sizes greater than 272 octets (up to 4000 octets). In this case, the MTP level 3 should be able to route the longer message to an outgoing HSL or transfer the message to the application layer.

O3-33 [31] As an implementation option, it is desirable HSL NE MTP level 3 function shall be able to transfer messages longer than 272 octets up to a maximum of 4000 octets (excluding SAAL overhead) over a high speed link. The following node-specific conditional requirements are also applicable, subject to the implementation’s ability to handle messages in this length range.

3–16

ab


CR3-34 [32] If an STP receives a message on a high speed link that is longer than 272 octets (at the MTP Level 3, including the routing label) and the message is destined for a 56-Kb/s MTP2 link, then the STP shall discard the message and notify maintenance. This notification shall include the OPC, the DPC, and the length of the message.

CR3-35 [33] If an STP receives a message on a high speed link that is longer than 272 octets (at the MTP Level 3, including the routing label) and the message is destined for another high speed link, then the STP shall route the message (without notifying maintenance).

CR3-36 [34] If an end node (a switch or an SCP) receives a message on a high speed link that is longer than 272 octets, the message shall be routed to the intended application layer for further processing.

CR3-37 [35] The end node (a switch or an SCP) shall be able to originate and transmit a message longer than 272 octets over the high speed link.

3.3.1.1.1 Signaling Link Selection

GR-246-CORE[1] contains requirements for load sharing of traffic over available links in a link set (or a combined link set) using the Signaling Link Selection (SLS) field. In the current issue of GR-246-CORE[1] and in GR-82-CORE,[12] an 8-bit SLS field is specified with the objective to provide a conversion from the previously specified 5-bit SLS field to the 8-bit SLS field. The reason for the 8-bit SLS is to allow more signaling links in B- and D-link sets and allow a better load balance on signaling links. Although with HSLs, the need for more signaling links is reduced, the 8-bit SLS shall be required in HSL NEs to maintain compatibility in the network.

R3-38 [36] The HSL NE shall support the 8-bit SLS field.

R3-39 [37] The HSL NE shall support link set-sizes up to 16 links for any link set.

3.3.1.1.2 Message Sequencing

Proper message sequencing is assured by the SAAL and the ATM layers of the HSL protocol structure. The SAAL layer maintains proper sequencing of SD PDUs and the ATM layer maintains cell sequence integrity. At the MTP3/SAAL service boundary, the HSL NE’s SAAL must ensure that messages sent over the HSL are transmitted in the order they are received from the higher layer (i.e., MTP level 3). Similarly, MTP level 3 in an HSL NE transfers messages to the SAAL layer in the order they are received from the MTP level 3 user (e.g., SCCP or ISUP).

3–17


GR-2878-CORE

R3-40 [38] The HSL NE shall ensure that sequencing of user messages and signaling network management messages is maintained. That is, messages shall be delivered in the order they are received from the local or peer user.

3.3.1.2 Message Handling During Overload

This section considers STP message handling overload. Detailed discussions and requirements for mitigating message handling overload are provided in Section 13.7.7. of Chapter T1.111.4 of GR-246-CORE[1] and in GR-82-CORE.[12] Requirements provided in this section are primarily applicable to Signaling Transfer Points (STP) but may also be applicable to signaling end nodes as well.

R3-41 [39] The total throughput of an HSL NE shall be at least the engineered failure load when the offered load is increased to equal or greater than the engineered failure load. This is assuming that incoming traffic on each of the signaling links is equal to or greater than the engineered failure load (80% of utilization, see Section 6) and there are no internal failures.

Situations may arise when the signaling message handling function cannot handle the offered load. In particular, this may occur when the incoming traffic to one or more destinations is disproportionately higher than others, or during the initial implementation phase when sufficient level 3 signaling message processing capacity is not available to handle the full capacity of the configured 1.5-Mb/s links and 56-Kb/s links. In this case, an HSL STP shield be able to control the traffic destined for the overloaded resources.

Precise criteria to control this condition are dependent on the particular implementation. Some guidelines describing acceptable practices are discussed in the following paragraphs.

The HSL STP’s first defense against overload in the message handling function is to reduce the rate at which incoming messages are accepted to a level that the message handling function can process without overload. This can be accomplished by invoking the level 2 flow control procedures and possibly a triggering of the transfer-controlled procedures at the adjacent node. Level 2 flow control procedures and requirements for 56-Kb/s MTP links are provided in Section 9 of GR-246-CORE.[1] For 1.5-Mb/s SAAL-based signaling links, ANSI T1.637[6] describes the basis for level 2 flow control. Appendix A of this document, using the principles of ANSI T1.637,[6] describes acceptable methodologies for implementing level 2 flow control in 1.5-Mb/s SAAL links.

If the level 2 flow control is not sufficient to control the message handling overload in an HSL STP, then MTP level 3 may invoke Signaling Message Handling (SMH) congestion controls to discard traffic and send Transfer Controlled (TFC) messages as described in Section 4.2.3.5 of GR-82-CORE.[12]

3–18

ab


R3-42 [40] The HSL NE shall conform to all applicable requirements described in Section 4.2.3.5 of GR-82-CORE[12] when it detects that the signaling message handling functions are in danger of becoming overloaded.

3.3.2 MTP Network Management Functions

The MTP network management functions form a subset of MTP Signaling Network Functions (Level 3). These functions define actions and procedures required to maintain signaling service and to restore normal signaling conditions if disruptions occur in signaling links or in signaling points.

MTP network management functions and procedures are described in GR-246-CORE[1] and specific requirements and actions needed at particular CCS nodes (i.e., STP, switch, and SCP) are provided in GR-82-CORE,[12] GR-606-CORE,[13] and in GR-1241-CORE,[14] respectively. In this document, network management procedures and requirements that are needed for HSLs, over and above those described in these three referenced GRs, are provided.

R3-43 [41] The HSL NE shall provide the network management functions as described in GR-246-CORE[1] and shall provide capabilities necessary for specific nodes as described in GR-82-CORE,[12] or GR-606-CORE,[13] or GR-1241-CORE.[14]

3.3.2.1 Congestion Control

Section 3.8 of Chapter T1.111.4 of GR-246-CORE[1] describes criteria for the determination of signaling link and signaling route congestion at MTP level 3. It also provides the network management procedures for congestion control in the CCS network.

R3-44 [42] The HSL NE shall provide signaling link and route congestion control capabilities as described in Section 3.8 of Chapter T1.111.4 of GR-246-CORE.[1]

For HSLs, congestion is determined at the SSCF by some implementation-dependent function and reported to the MTP level 3 via the AAL-LINK_CONGESTED.indication. The SSCF uses four levels of congestion with the lowest level indicating no congestion to MTP level 3.

R3-45 [43] The HSL NE shall provide an appropriate congestion reporting function at the SSCF layer using the four levels of congestion. Procedures for reporting congestion to MTP level 3 (SAAL user) are provided in ANSI T1.645.[7]

3–19


GR-2878-CORE

The MTP level 3 congestion control is based on the CCS node determining the status of the signaling link’s transmit and retransmit buffer occupancy and comparing them against predetermined levels of buffer fill. If predetermined buffer thresholds are exceeded, an indication is given to MTP level 3, which initiates the sending of response-mode transfer-controlled (TFC) messages to the originators of the traffic. In U.S. networks, three separate congestion thresholds are provided for each of the three congestion levels, corresponding to congestion onset, abatement, and message discard actions.

R3-46 [44] The HSL NE shall implement congestion thresholds as discussed in Section 3.8 of Chapter T1.111.4 of GR-246-CORE.[1] In addition, the HSL NE, depending on its functions, shall meet specific requirements stated in GR-82-CORE,[12] GR-606-CORE,[13] and GR-1241-CORE.[14] Actual implementation of congestion thresholds in the SSCF is node-implementation dependent.

GR-246-CORE[1] does not specifically discuss implementation options for transmit and retransmit buffers for high speed (1.5-Mb/s) SAAL signaling links. To accommodate MTP level 3 congestion control procedures in the HSL NE for SAAL-based HSLs, appropriate buffers at MTP level 3 and the SSCF must be modelled, which will allow the HSL NE to implement MTP level 3 congestion control in terms of MTP level 3 messages.

Some general guidelines are provided as follows for the setting of congestion thresholds. The onset threshold for congestion status 1 should be set sufficiently high so that congestion will not occur when a signaling link changeover procedure is executed. When changeover is executed, messages are buffered until a changeover acknowledgment message is received in response to a changeover order message. After the HSL NE receives the acknowledgment, the buffered messages are transferred to the link transmit buffers of the links to which the changeover is being executed. The changeover procedure should not cause congestion on the links to which the changeover is being made. For CCS end nodes, given that there should be no or very little feedback delay between the crossing of an onset threshold and MTP Level 3 recognizing the crossing of the threshold, the discard thresholds for each congestion level may need to be only a few messages higher than the onset thresholds. For STPs, there should be enough separation between the onset and discard thresholds at each level to allow the TFCs to be sent to, and acted upon by, the sources to minimize the STP’s discarding of traffic. These guidelines are not meant to specify an implementation but are given for informational purposes. Further guidance may be provided in the future in this area.

The transmit and receive buffer sizes must also be sized sufficiently to accommodate the 1.5-Mb/s signaling link speed. In addition, the congestion thresholds must also be assigned default values for the 1.5-Mb/s signaling links separately from those used for the the 56-Kb/s MTP2 links configured at the same node. Upon upgrading the latter links to HSLs, the congestion thresholds must be either automatically changed or manually changed (through provisioning) to the new applicable values.

3–20

ab


Appendix C provides further information regarding the basis and recommendations for HSL transmit buffer congestion thresholds in STPs and SCPs.

R3-47 [45] The congestion thresholds in the HSL NE shall be automatically or manually assigned to default values (implementation dependent) for any given signaling link speed (i.e., 56-Kb/s or 1.5-Mb/s). If the congestion thresholds must be assigned manually, the thresholds shall be provisionable.

CR3-48 [46] As a per-carrier option, the STP shall have a minimum transmit buffer (or combined transmit and retransmit buffer) size of 5730 messages (based on average message size of 25 octets) if the congestion thresholds are implemented in messages, and at least 143,250 octets if the congestion thresholds are implemented in octets.

3.3.2.2 Signaling Link Activation, Restoration, Deactivation, and Link Set Activation

3.3.2.2.1 General Procedures

Signaling link activation, restoration, deactivation, and signaling link set activation are signaling link management procedures to make a signaling link ready to carry signaling traffic, restore a faulty signaling link or link terminal, and take a link out of service. These procedures are described in GR-246-CORE.[1] One important step in the signaling link or signaling link set activation and restoration process is the initial alignment procedure for signaling links, including the proving of the signaling link. For high speed (1.5-Mb/s) signaling links, procedures for signaling link alignment is accomplished at the SSCF (Service Specific Coordination Function) sublayer of the SAAL and is described in T1.645.[7] In establishing a connection for the SAAL user, the SSCF passes through several stages of alignment procedures including a proving procedure. The proving procedure relies upon an error monitoring function in layer management. The SSCF proves in the link unless it has received an AAL-EMERGENCY.request from MTP level 3 or a notification of emergency status from the remote end via SSCOP-UU parameter of an AA-ESTABLISH.request confirm or indication.

R3-49 [47] The HSL NE shall activate, restore, and deactivate high speed signaling links as described in Section 12, Chapter T1.111.4, of GR-246-CORE,[1] and alignment and proving procedures described in ANSI T1.645[7] and in ANSI T1.652,[8] respectively. The HSL NE shall also conform to the specific application-related procedures described in GR-82-CORE,[12] GR-606-CORE,[13] and GR-1241-CORE.[14]

3–21


GR-2878-CORE

Whenever the SSCF fails to prove in a HSL, i.e., when SSCF Timer T2/T1.645 expires (default value 120 seconds), it informs MTP3 via an AAL_OUT-OF-SERVICE.indication and the SSCOP connection is released. The SSCF must then await a positive signal from MTP3 to commence subsequent alignment and proving attempts. In the absence of any conditions at MTP3 or higher layers that would prevent it, the HSL NE’s MTP3 is always expected to attempt to restore the HSL to service at the SAAL without delay and repeat the process as often as necessary to restore the link, when it detects such unsuccessful proving attempts. The following requirement addresses this expected behavior of MTP3 in such cases.

R3-50 [225] In the event an HSL’s MTP3 receives an AAL_OUT-OF-SERVICE.indication from the local SSCF, indicating the SSCF’s failure to align and prove in the SSCOP connection for a duration corresponding to the expiration of SSCF Timer T2/T1.645 (Time SSCF will attempt alignment), MTP3 will respond immediately (without delay) to initiate link restoration via an AAL-START.request and will repeat this action as necessary for any subsequent alignment failures until the link is successfully restored, unless MTP3 is prevented from doing so by one or more of the following conditions or procedures:

… 1. link restoration is delayed by the MTP3 Link Oscillation Filter (LOF) (see also Section 3.3.2.6) (for STPs only)

… 2. link restoration is delayed by MTP Restart procedures

… 3. link restoration is prevented due to a local processor outage affecting MTP3 functions

… 4. the link is deactivated by operations systems or personnel.

3.3.2.2.2 Use of Emergency Proving

Of increased concern with respect to the longer default normal proving period for SAAL-based HSLs (60 seconds) relative to that for MTP2 links (2.3 seconds) is the speed with which an HSL can be restored under emergency conditions, for example, when destinations normally accessible via the link set in which the HSL resides become isolated from the HSL NE. Current SAAL procedures call for a zero-duration proving interval under such emergency conditions, i.e., the link is restored as soon as the SSCOP connection is successfully reestablished (but without the local SSCOP exchanging proving PDUs with its remote peer) and the link then successfully passes the MTP3 Signaling Link Test (SLT) procedure. (For MTP2 links, the default emergency proving period is 0.6 seconds, shorter than the normal proving period, but still non-zero.)

Prior to 1999, the ANSI SS7 protocol standard was not precise about the specific criteria under which Link Set Emergency Restart procedures (in which emergency proving is used

3–22

ab


for some or all member links) are to be invoked, versus Link Set Normal Activation procedures (in which normal proving is used for all member links). The protocol had specified only that Link Set Emergency Restart is applicable when “... an immediate reestablishment of the signaling capability of the link set is required.” However, a full definition of when this was required was not provided. It was further stated that more specific criteria “... may vary between different applications of the signaling system.”

Of particular concern has been the reported practice of some MTP2-link implementations in which emergency restart was applied whenever there are no other links available in the link set (i.e., whenever the link set is recovering from a link set outage), regardless of the status of route sets to SS7 destinations or other network conditions. This could result in the application of emergency proving even when no destinations are isolated (because alternate routes are still available) and no other adverse network conditions, such as congestion, actually exist. In single-link link sets, which may apply for HSLs, this criteria would consistently result in emergency proving (and hence no proving interval), since there would never be any other available HSLs in the link set. This concern, and broader concerns about the lack of more specific criteria for emergency link set restart versus normal link set activation, brought about a series of standards contributions to T1S1, resulting in a clarification of the standard in this regard. This clarification is documented as ANSI T1S1 contribution T1S1.3/99-113(06201),[51] and will be incorporated into the forthcoming adopted ANSI SS7 MTP standard in T1.111[39] and into the forthcoming update of GR-246-CORE,[1] Chapter T1.111.4.

Consistent with this recent standards clarification, the following requirements objects address the HSL NE’s initiation of normal versus emergency proving for HSLs.

R3-51 [230] The HSL NE shall initiate HSL activation or restoration attempts in emergency mode (following MTP3’s issuance of an emergency proving request (AAL-EMERGENCY.request) to the SSCF ) when all of the following conditions apply:

… 1. the link set is recovering from a link set outage condition, i.e., in which there were or are no other links available in the link set, and

… 2. the link set is undergoing Link Set Emergency Restart procedures, as specified in GR-246-CORE,[1] Chapter T1.111.4, Section 12.2.4.2.

R3-52 [231] The HSL NE shall initiate HSL activation or restoration attempts in normal mode (when necessary, following MTP3’s issuance of an AAL-EMERGENCY-CEASES.request issued to the SSCF) whenever:

… 1. the link set is not recovering from a link set outage; or

… 2. the link set is recovering from a link set outage, but the link set is undergoing Link Set Normal Activation procedures, as specified in GR-246-CORE,[1] Chapter T1.111.4, Section 12.2.4.1.

3–23


GR-2878-CORE

The following requirements objects specify criteria under which Link Set Emergency Restart versus Link Set Normal Activation procedures apply to a HSL link set recovering from a link set outage.

R3-53 [232] The HSL NE’s local MTP3 must initiate Link Set Emergency Restart procedures for a HSL link set restoration or activation, and shall issue an AAL-EMERGENCY.request to the SSCF for each member link, when it detects that all links in that link set have become unavailable and one or both of the following network conditions apply:

… 1. the adjacent signaling point at the far end of the link set is inaccessible, i.e., there are no available (allowed) routes to that signaling point via any other link set; or

… 2. the local signaling point at the HSL NE is itself undergoing MTP restart.

CO3-54 [233] It is desirable2 that the HSL NE initiate Link Set Emergency Restart Procedures for a HSL link set restoration or activation, and issue an AAL-EMERGENCY.request to the SSCF for each member link, when it detects that all links in the link set are unavailable and one or both of the following network conditions apply. This conditional objective shall be subject to the ability of the HSL NE implementation to detect these network conditions immediately at the time link set outage is detected and restart is initiated, and without an undue processing burden that would otherwise degrade the signaling performance of the HSL NE or substantially delay link restoration or activation.3

… 1. One or more remote (non-adjacent) destination signaling points that are normally accessible via that link set are not currently accessible via any other route (link set) in their respective route set(s).

… 2. The HSL link set is a member of a signaling route set in which the other (available) link sets comprising those routes are experiencing severe local link transmit congestion on one or more member links,

2. The clarified T1S1 standard for emergency restart, as stated in T1S1.3/99-113(06201)[51] specifies only that emergency restart may be used under these network conditions. This conditional objective on the HSL NE is thus stronger than the criteria of the standard, as it states the criteria are desirable if it is possible for the implementation to discern the corresponding network conditions.

3. For example, if an implementation requires the HSL NE to perform a resource-intensive search of all route sets to remote destination signaling points accessible via given link set, at the time the link set outage occurs, in order for it to detect these network conditions, then it might not be able to make such determinations quickly, and therefore might not satisfy the condition under which this conditional objective applies. However, an implementation that maintains such network status information on an exception basis only for each link set may be able detect the remote node isolation or route set congestion immediately or without significant delay, such that the condition of this CO would apply. The applicability of the cited condition is therefore implementation-dependent.

3–24

ab


defined as a link transmit queue occupancy at or exceeding the level 2 congestion onset threshold(s).

R3-55 [234] The HSL NE must initiate Normal Link Set Activation procedures (i.e., it must not use Emergency Link Set Restart procedures) when it detects all links in an HSL link set are unavailable but none of the network conditions cited in R3-53 [232] and CO3-54 [233] are satisfied for the unavailable link set. (If the network conditions cited for CO3-54 [233] cannot be immediately determined by the HSL NE at the time a link set restoration is initiated, then normal activation must be invoked unless one or both of the network conditions cited in R3-53 [232] apply.)

O3-56 [235] It is an objective that the HSL NE also apply the same Link Set Emergency Restart criteria specified for HSLs in R3-53 [232], CO3-54 [233] and R3-55 [234] as well4 to its:

… 1. MTP2 link sets

… 2. mixed link sets containing HSLs and MTP2 links, as may exist during transitional arrangements.

The condition of a link set outage combined with the other applicable network conditions cited in R3-53 [232] and CO3-54 [233] are said to be the “emergency conditions” under which Emergency Link Set Restart and emergency proving should be applied.

3.3.2.2.3 Interruption of Normal Proving Under Emergency Conditions

Under the SAAL protocol, HSLs will not automatically revert to emergency proving once normal proving commences and while it remains in progress. This is because the SSCF at the end of the link declaring the emergency condition, while it is informed by its local MTP3 that the emergency condition exists and can reset the local user-proving mode to emergency for subsequent link restoration attempts, does not interrupt normal proving. It is also incapable of conveying that change in proving mode to its peer SSCF at the far-end node while normal proving remains in progress. Either proving is successfully completed at both ends, or one end or the other releases the SSCOP connection.

The current procedures imply that proving may persist for as long as the normal proving period if an emergency condition arises while proving is already underway. Such a

4. The clarified Link Set Emergency Restart criteria as stated in ANSI T1S1.3/99-113(06201)[51] apply to SS7 link sets in general, regardless of their link-layer protocol, and thus apply to MTP2 links as well as HSLs. Hence these requirements will apply as well to any MTP2 links at the HSL NE. Other Telcordia GRs for CCS nodes (e.g., GR-82-CORE[12] for STPs, GR-1241-CORE[14] for SCPs, and GR-606-CORE[13] for CCS SOs/SSPs) may be updated at a later date to reflect these same requirements for signaling links in general, or the revised standard may merely be incorporated by reference.

3–25


GR-2878-CORE

restoration delay, which may be as long as 1 minute under default assumptions, may not be acceptable to CCS network operators when emergency conditions arise.

Current Emergency Proving Procedures

To understand this current protocol limitation, it is important to consider the SAAL processing that now takes place for a given HSL undergoing normal proving when MTP3 declares a link set emergency restart condition. Procedures are based on state transitions defined in T1.645,[7] Table 6, and Figure D.2.

1. During normal proving, the HSL’s SSCOP is exchanging proving PDUs with its SSCOP far-end peer at a rate of 1 every T1.645/T3 seconds (default 1000 micro-seconds) until the count T1.645/n1 (default 60000) proving PDUs is satisfied as monitored by the SSCF. The SSCF-NNI state (upper boundary/SSCOP/LM) is 2/10/3 (alignment/data transfer ready/proving). Its local User Proving Status (the user being MTP3) is “normal” (UPS = NM). Its local Management Proving Status (MPS) based on previously received LM signals will be “neutral,” assuming the local layer management has not invoked forced normal proving to prevent link oscillations, and that a corresponding emergency condition has not been conveyed by the far-end SSCOP. The HSL will continue proving until: n1 is satisfied, the number of errored PDUs detected exceeds the limit imposed by LM parameter Max_NRP (Maximum number of of retransmitted SSCOP PDUs permissible for link proving; default = 1 PDU), or the SSCOP connection otherwise fails or is taken down.

2. When the local MTP3 declares the emergency condition for the HSL, it generates an AAL-EMERGENCY.request primitive to the local SSCF.

3. Upon receipt of the AAL-EMERGENCY.request primitive, the local SSCF sets its local User Proving Status (UPS) to “emergency,” (UPS = EM), per SSCF procedures defined in T1.645,[7] Table 6 and Figure D.2 (Part 13 of 20). However, it remains in state 2/10/3 until proving is either completed or fails. It does not inform local SSCOP to terminate the transmission of proving PDUs. Nor does it request its local SSCOP inform the far-end-SSCOP of the emergency condition. That cannot be done while proving PDUs are exchanged.

4. If proving fails or if the HSL subsequently proves in and later fails while the emergency condition persists, the next link alignment attempt, per procedures defined in T1.645,[7] Tables 7 and 8, will cause the local SSCF to generate the AA-ESTABLISH.request to the local SSCOP, with the SSCOP-UU data parameter set to “emergency.” This will then cause the local SSCOP to send UPS = EM as SSCOP User-to-User (SSCOP-UU) Information encoded in a subsequent Begin (BGN) PDU. Both ends will then use emergency proving procedures (a zero proving interval).

The SAAL protocol is structured this way to allow layer management to force normal proving to prevent link oscillations that could otherwise occur under emergency proving, if the SAAL user (MTP3) alone was allowed to establish the proving mode. (These forced

3–26

ab


proving procedures are described in Section 3.2.4.3 [Forced Proving Procedures to Prevent Link Oscillations].)

Therefore, in order for normal proving to be suspended in such cases, positive action would need to be taken by the HSL NE’s local Systems Management function, interacting with the Layer Management (LM) and MTP3 at the CCS node, to suspend normal proving and restart the link in emergency proving mode.

Such an action is in fact desirable when emergency conditions arise during normal proving, and is an objective as cited below. Specifically, the HSL NE’s Systems Management function, while implementation-dependent, should have access to all link state information maintained by MTP3 and by LM, and should be capable of stimulating those protocol functional blocks to initiate the necessary actions to suspend any normal proving in progress when the emergency condition arises. No modifications to the current standard MTP3, SSCF, or SSCOP procedures are required, however new interactions between Systems Management and MTP3 and LM are needed to support this objective.

Additional Procedures for Suspension of Normal Proving on Emergency

O3-57 [228] If while a HSL is undergoing normal proving, the HSL NE declares an “Emergency Condition,” for that HSL link set (per criteria specified in Section 3.3.2.2.2, R3-53 [232] and CO3-54 [233]), it is an objective that the HSL NE interrupt the normal proving process and revert immediately to emergency proving in an attempt to immediately restore the HSL, per the following procedures:

… 1. Whenever the HSL NE initiates HSL restoration under the link set normal activation procedure and is awaiting completion of normal proving, i.e., MTP3 has issued an AAL-START. request to the local SSCF and is awaiting the receipt of an AAL-IN_SERVICE.indication during normal proving, it shall monitor the status of the link set and associated route sets for the occurrence of an emergency condition per the criteria specified in R3-53 [232] and CO3-54 [233].

… 2. Upon declaration of the emergency condition for the link set and the proving HSL, MTP3 should inform local Systems Management.

… 3. Local Systems Management should then interrogate local Layer Management to determine whether TIMER_FORCE-PROVING is running for the link.

… a. If TIMER_FORCE-PROVING is running then the link has recently been restored. Forced normal proving is in progress to prevent potential link oscillations and should not be overridden. The process shall exit the procedure at (go to) Step 5 and continue with normal proving.

3–27


GR-2878-CORE

… b. If TIMER_FORCE-PROVING is not running, then System Management should attempt to restore the link immediately, and the process should proceed as follows.

… 4. Local Systems Management should then cause MTP3 to issue the following primitives to the local SSCF to interrupt normal proving and restart the link with emergency proving:

… a. AAL-STOP.request

… b. AAL-EMERGENCY.request

… c. AAL-START.request.

… (Upon receipt of the AAL-START.request, based on existing procedures, the local SSCF should then switch to emergency proving for link restoration, given that the value of the Management Proving Status (MPS) is neutral, and will generate the AA-ESTABLISH.request to the local SSCOP, with the SSCOP-UU data parameter set to “emergency.” This will then cause the local SSCOP to send User Proving Status (UPS) = EM as SSCOP User-to-User (SSCOP-UU) Information encoded in a subsequent Begin (BGN) PDU, which will re-establish the SSCOP connection. Both ends should then use emergency proving and restore the link to service immediately.)5

… 5. Exit. Otherwise, no further action is taken by Systems Management and the local SSCF continues with normal proving.

CR3-58 [229] If the procedure defined in O3-57 [228] is implemented by an STP supporting HSLs, Step 4 c. shall be subject to any applicable delays resulting from the invocation of the MTP3 Link Oscillation (LOF) filter, Procedure A,6 as described in GR-246-CORE,[1] Section 12.2.2, assuming the latter is supported by (and enabled for) the HSL. (See also Section

5. It should be noted that the procedure as defined here will not ensure emergency proving for the subsequent link restoration attempt if the far-end HSL NE has its Timer_FORCE-PROVING set to a higher value than that at the local end initiating this procedure. That is, the far-end will use forced normal proving if its Timer_FORCE-PROVING is still running, overriding emergency proving, regardless of the value of UPS sent in the SSCOP-UU parameter of the BGN PDU. This means that network administrators should ensure that Timer_FORCE-PROVING is set to the same value at each end of each HSL within the LEC CCS network or, when HSLs are used in network interconnection, as coordinated with the far-end network administration.

6. In LOF Procedure A, the Link Oscillation Timer (T32) may be running at the time this procedure is invoked. However, note that if the HSL STP implements LOF Procedure B instead, the AAL-START.request delay will not apply. When a link fails and is undergoing normal proving, LOF Procedure B’s Probation Timer (T33) and Suspension Timer (T34) are not running. Timer T33 is started at link recovery and T34 is started only if the link fails within T33 of that last recovery or activation. Therefore, a suspension period (remainder of T34) cannot be in effect if the link is already undergoing normal proving when this emergency condition arises. That is, the proposed procedure to revert to emergency proving once normal proving is underway potentially interacts with LOF Procedure A, but should not interact with LOF Procedure B.

3–28

ab


3.3.2.6.) That is, the generation of the AAL-START.request in O3-57 [228], Step 4 c. shall normally be delayed for the remainder of Timer T1.111.4/T32 (Link Oscillation Timer), if LOF Procedure A is used and T32 is still running at the time restoration is re-attempted.

A more detailed discussion on the application of the MTP3 Link Oscillation Filter to HSLs and its potential interactions with the SAAL Forced Proving Procedure is presented in Section 3.3.2.6 (Use of the MTP3 Link Oscillation Filter for HSLs at STPs).

3.3.2.3 Signaling Link Changeover

Signaling link changeover procedures are used to divert traffic carried by a failed signaling link to an alternative signaling link or links while avoiding message loss, duplication, or mis-sequencing. The changeover procedures include buffer updating and retrieval. Detailed descriptions of changeover procedures at MTP level 3 are provided in GR-246-CORE.[1] For HSLs, the changeover procedure relies on the local retrieve function of the SSCF in the SAAL. This function accommodates the MTP level 3 commands for data retrieval (AAL-RETRIEVE-BSNT.request and AAL-RETRIVE_REQUEST_AND_FSNC.request) by interacting with SSCOP. A description of the data retrieval process at the SSCF is provided in ANSI T1.645.[7]

R3-59 [48] The HSL NE shall initiate and perform the signaling link changeover procedures as described in GR-246-CORE.[1] The data retrieval procedure shall be as described in ANSI T1.645.[7] In addition, applicable requirements specific to particular network element functions (i.e., STP, switch, and SCP) shall be as described in GR-82-CORE,[12] GR-606-CORE,[13] or GR-1241-CORE,[14] respectively.

The changeover procedure at MTP level 3 relies on the exchange of changeover order and changeover acknowledgment messages between the nodes at either end of a signaling link. The formats for these messages are described in GR-246-CORE.[1] The changeover order and changeover acknowledgment messages include: the routing label indicating the originating and destination signaling point codes (OPC and DPC), the Signaling Link Code (SLC) indicating the identity of the unavailable signaling link, and the changeover-order or changeover-acknowledgment signal (conveyed by the appropriate H0 and H1 codes). The changeover messages include the forward sequence number of the last message signal unit (MSU) (for MTP2 links) or the last Sequence Data (SD) Protocol Data Unit (PDU) (for SAAL-based HSLs) processed by the node generating the message. For HSLs, a 24-bit sequence number field is used. New H1 code values (0011 [decimal 3] and 0100 [decimal 4]) are used in these messages to distinguish them as either an Extended Changeover Order (XCO) or an Extended Changeover Acknowledgment (XCA) message, respectively, as opposed to their conventional Changeover Order (COO) and Changeover Acknowledgment (COA) counterparts used for 56-Kb/s MTP2 links, which use the shorter 7-bit sequence number.

3–29


GR-2878-CORE

R3-60 [49] The HSL NE shall recognize and process Extended Changeover Order (XCO) and Extended Changeover Acknowledgment (XCA) messages for HSLs, which shall use a 24-bit sequence number field, and H1 field encodings of 0011 and 0100, respectively, as described in Section 15 of Chapter T1.111.4 of GR-246-CORE.[1]

In the signaling architecture considered for HSLs by Telcordia clients, it is likely that HSLs will be required to interwork with MTP2-based 56-Kb/s links. This will likely occur under two scenarios:

1. During the transition period when an existing link in a 56-Kb/s link set is replaced by a HSL (see discussions in Section 9).

2. For an HSL NE (e.g., an STP) supporting both MTP2 56-Kb/s and HSLs on normal and alternate routes (e.g., an MTP2 B-link set quad and an HSL C-link set).

Under these two scenarios, the changeover and changeback between a high speed link and a 56-Kb/s link may occur. Since changeover procedures for HSLs use the new H1 field encoding and the new sequence number formats in the changeover order and changeover acknowledgment messages, level 3 processing for 56-Kb/s links should thus be able to process these new messages and allow the HSL NE to correctly carry out the changeover from a high speed link to a 56-Kb/s link, and vice versa. Further considerations regarding the changeover and changeback between HSLs and a 56-Kb/s links under transitional arrangements is provided in Section 9.

R3-61 [50] The HSL NE shall be able to correctly recognize and process Extended Changeover Order (XCO) and Extended Changeover Acknowledgment (XCA) messages for a HSL received over 56-Kb/s MTP2 links and HSLs.

R3-62 [51] The HSL NE shall be able to correctly recognize and process the conventional Changeover Order (COO) and conventional Changeover Acknowledgment (COA) messages for 56-Kb/s MTP2 links received over HSLs and 56-Kb/s MTP2 links.

It is possible that HSL NE suppliers may wish to establish contingency procedures to address the unlikely event that the CCS node receives an incorrect changeover order message type for the link type, at such nodes supporting both HSLs and MTP2 links. Specifically, this refers to the node’s receipt of a conventional COO message for/about an HSL, or an XCO message for/about an MTP2 link, the latter message type having a longer sequence number to accommodate the SAAL layer. Such events are not expected to occur, because it is assumed that both link types will be supported at the node and will need to be properly translated as being of the respective types (i.e., “link classes”) in order to be operational. Yet, the possibility of such protocol violations exists due to potential implementation (software) errors or corrupted translations data. Requirements R3-60 [49] through R3-62 [51] state only that the HSL NE’s MTP3 must be capable of processing both

3–30

ab


changeover message types about their respective link types, regardless of which type of link the arrive on. However, the requirements do not address this error scenario, and two interpretations of the current standards and requirements are possible, resulting in either of the following reactions by the receiving CCS node:

1. Discard the message as invalid for the link type, and normally perform a time-controlled changeover as if the COO/XCO had never been received and link failure was detected at the link layer.

2. Recognize the COO or XCO as a valid changeover order signal but with an invalid sequence number and initiate an immediate changeover to divert new traffic, but without retrieval of the retransmit buffer contents. The latter procedure is implied by current standards in GR-246-CORE[1] regarding the receipt of unusable sequence numbers in changeover orders.

The Telcordia view is that requirements should not be established for the node’s handling of such protocol non-conformances. Either solution should be regarded as acceptable in the extremely unlikely event that such protocol violations occur.

3.3.2.4 Transfer Restricted Timer

The Transfer Restricted control invoked on HSLs will be implemented in accordance with the currently specified SS7 Transfer Restricted procedure described in GR-246-CORE.[1] Specifically, Timer T11/T1.111.4 (see GR-246-CORE,[1] Chapter T1.111.4, Section 13.4) is used to indicate a long-term failure condition, and causes invocation of the transfer-restricted procedures at an STP. This timer, as documented in Table 6-1 of GR-82-CORE,[12] uses a default value of 90 seconds and a configurable range of 30 to 90 seconds. Prior issues of GR-82-CORE[12] specified a default value of 65 seconds at STPs, but that value was considered too close to the HSL default normal proving period of 60 seconds, as discussed in Section 3.2.4.2, which might have caused unnecessary network management actions under certain failure conditions. Thus, the default value for timer T11 has been changed to 90 seconds, as most LEC STPs are expected to support at least some HSLs.

3.3.2.5 Signaling Link Test

The SS7 Signaling Link Test (SLT) procedure is designed to verify a signaling link’s SLC and far-end point code (FE PC) assignment to its physical link port at the CCS node and can detect looped-back link facilities, improperly cross-connected link facilities, link translation errors, and other irregularities in the link operation.

R3-63 [52] The HSL NE shall make provisions for the testing of HSLs using the Signaling Link Test (SLT) procedures described in GR-246-CORE,[1]

3–31


GR-2878-CORE

Chapter T1.111.7, Section 2.2, and all applicable NE requirements such as those in GR-82-CORE,[12] GR-606-CORE,[13] and GR-1241-CORE.[14]

3.3.2.6 Use of the MTP3 Link Oscillation Filter for HSLs at STPs

For MTP2-based 56-Kb/s signaling links, the default normal and emergency proving periods are 2.3 and 0.6 seconds, respectively. Because of these relatively brief proving intervals, it is possible under certain conditions that MTP2 links can fail, rapidly recover, and fail again repeatedly, resulting in a condition known as link oscillation. To guard against this phenomenon, STPs utilize the MTP level 3 Link Oscillation Filter (MTP3 LOF), which is designed to detect such oscillations (i.e., whenever such link recoveries and failures occur closely spaced in time) and delay subsequent link restoration attempts. These procedures are defined for signaling links at STPs in GR-246-CORE,[1] Chapter T1.111.4, Section 12.2.2, and in GR-82-CORE,[12] Section 4.2.4.10. These requirements make no distinction as to the type of link-layer protocol used to support the signaling link, and specifically whether or not equivalent procedures like those of the SAAL are in fact available to prevent link oscillations at the link layer. This might be interpreted to imply that the MTP3 LOF should be applied to HSLs as well as MTP2-based links.

However, for the SAAL-based HSLs addressed in this GR, the default normal proving period is 60 seconds. As discussed in Sections 3.2.4.2 and 3.2.4.3 of this document, the SAAL normal proving procedure, used during HSL restoration under normal conditions, and the SAAL Forced Proving procedure, which forces normal proving if closely-spaced failures and recoveries occur under emergency conditions, should effectively prevent link oscillations because of the longer proving time. Assuming the STP uses a normal proving period for HSLs equal to or comparable to the 60-second default, it will not be necessary for it to invoke the MTP3 LOF as well as the Normal Proving or Forced Proving procedures to prevent such link oscillations.

In addition, unintended link restoration delays may result if both the SAAL Forced Proving procedure described in Section 3.2.4.3 and the MTP3 LOF are both invoked for the same HSL upon link restoration attempts. The specific restoration delays for a HSL would depend upon the MTP3 LOF procedure chosen by the implementation (Procedure A or B as defined in GR-246-CORE[1]), the configured values of the LOF probation and suspension timers (as applicable to the chosen LOF procedure), the configured values of parameters determining the SAAL normal proving period, and the conditions under which the link subsequently fails relative to the time of prior link restoration. If the MTP3 LOF and the SAAL Forced Proving procedures are both applied to a HSL, the restoration delay can be as long as 2 minutes, even under emergency conditions when other CCS nodes may be isolated from the STP. This may occur when the LOF’s link restoration delay (which can be as long as 60 seconds under default assumptions) is added to the forced normal proving period (whose current default is also 60 seconds). It may also be difficult or impossible for network personnel to alleviate this problem for HSLs by lowering the LOF’s link restoration delay for HSLs only, as this delay is governed by timers T32/T1.111.4 or T34/

3–32

ab


T1.111.4 (depending upon whether LOF Procedure A or B is used). These timers tend to be implemented as node-level parameters that are not always configurable on a per-link basis. Therefore, for most current implementations, it is unlikely that the LOF’s restoration delay could be selectively lowered for HSLs relative to that for MTP2 links.

Because of these considerations, it is recommended that the MTP3 LOF not be applied to HSLs at STPs, although it should be applied normally to any MTP2 links terminating at that same STP.

It is possible at the current stage of HSL development that STP implementations supporting both link types may already employ the MTP3 LOF in layer 3 software that is common to both HSLs and MTP2 links. Also, it is possible that network operations personnel may effectively disable the SAAL Forced Proving procedure by lowering Timer_FORCE-PROVING to 0, and may also effectively reduce the HSL normal proving period by reducing SSCF parameter n1/T1.645 (the required number of proving PDUs). Such actions, while contrary to the intent of the normal proving and Forced Proving procedures, could allow HSL oscillations to occur. This suggests that the MTP3 LOF might then serve as a useful “backup” safeguard against link oscillations, even for HSLs, where the Forced Proving procedure is supported by the STP. Because of these considerations, the omission of the MTP3 LOF procedures for HSLs at STPs will be an objective rather than a requirement. In addition, conditional objectives will apply to CCS nodes supporting the MTP3 LOF for HSLs, under which network personnel should have the ability to disable it for all HSLs on a per-node basis, and selectively lower the values of Timers T32 or T34 (T.111.4) to reduce the LOF’s link restoration delay for HSLs.

O3-64 [205] It is an objective that the MTP Level 3 Link Oscillation Filter (MTP3 LOF), as defined in GR-246-CORE,[1] Chapter T1.111.4, Section 12.2.2, and in GR-82-CORE,[12] Section 4.2.4.10, NOT be applied to HSLs at STPs.

CO3-65 [206] If an STP implementation elects to apply the MTP3 LOF to HSLs for which the SAAL Forced Proving procedure is also supported per Requirements R3-21 [21] through R3-24 [24], it is an objective that it provide a capability allowing network operations personnel and management systems responsible for fault and performance management to disable and enable the MTP3 LOF on a per-node basis (i.e., for all HSLs at the STP) via a configurable STP parameter.

CO3-66 [207] If an STP implementation elects to apply the MTP3 LOF to HSLs for which the SAAL Forced Proving procedure is also supported per Requirements R3-21 [21] through R3-24 [24], and if the STP supports both HSLs and MTP2 links, it is an objective that the STP provide a capability allowing network operations personnel and management systems responsible for fault and performance management to modify values of Timer T32/T1.111.4 (if it implements LOF Procedure A) or T34/

3–33


GR-2878-CORE

T1.111.4 (if it implements LOF Procedure B) on a per-link and a per link-parameter-set basis.

The capability described in CO3-66 [207] should allow users to establish lower values for the MTP3 LOF link restoration delay for those HSLs that use the default 60-second normal proving period, or a proving period of comparable duration. The LOF restoration delays for those HSLs could be lowered to near-zero, with the node relying on the proving period to prevent link oscillations, while MTP2 links or any HSLs configured to use proving periods significantly shorter than the 60-second default, could have their LOF restoration delays set higher. In the latter case, the MTP3 LOF rather than the proving period would prevent link oscillations.

R3-67 [208] STPs supporting both HSLs and 56 Kb/s MTP2 links shall normally apply the MTP3 LOF to all 56-Kb/s MTP2 links per requirements specified in GR-246-CORE,[1] Chapter T1.111.4, Section 12.2.2, and GR-82-CORE,[12] Section 4.2.4.10.

3.4 SCCP Functions

The SS7 protocol’s Signaling Connection Control Part (SCCP) provides specialized routing and management functions to the MTP. The SCCP functions are described in Chapter T1.112 of GR-246-CORE[1] and in applicable network element requirements. All SCCP functions should apply normally to user part message traffic handled on HSLs.

R3-68 [53] The HSL NE shall provide the necessary SCCP functions as described in GR-246-CORE[1] and in specific network element generic requirements documents, i.e., GR-82-CORE,[12] GR-606-CORE,[13] and GR-1241-CORE.[14]

3–34

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Node Operations Requirements

4. Node Operations Requirements

This section provides requirements and objectives for new operations functions to be provided by CCS nodes to support ATM-based HSLs. The requirements apply to all 3 CCS node types that support HSLs, including STPs, SCP nodes, and CCS SOs/SSPs, unless otherwise noted. These requirements may be incorporated into the operations sections of the relevant CCS node GRs, including GR-82-CORE[12] (for the STP), GR-1241-CORE[14] (for the SCP Node), and GR-606-CORE[13] (for CCS SOs), or merely incorporated by reference in those documents, at a later date.

Operations system interface requirements for these operations functions are addressed separately in Section 5.

4.1 General

4.1.1 Scope and Organization of the HSL Operations Requirements

The section is organized according to the commonly recognized operations domains defined under the ITU-T’s Telecommunications Management Network (TMN) operations architecture model. Specifically, the operations domains addressed (and the corresponding subsections in which requirements are provided) are as follows:

• Configuration Management (Memory Administration) (Section 4.2)

• Fault Management (Maintenance) (Section 4.4)

• Performance Management (Maintenance and Network Traffic Management) (Section 4.5)

• Network Data Collection (NDC) (Section 4.6).

The nomenclature in parentheses ( ) denotes the more traditional LEC name or names corresponding to each of the indicated TMN operations domains.

In addition, requirements for prerequisite in-band operations flows that are common to both the Fault Management and Performance Management domains, and which are to be supported within the message stream of the applicable layers of the HSL protocol architecture, are separately addressed under

• In-band Operations Flows (Section 4.3).

No incremental operations requirements for HSLs have been identified for the operations domains of Security Management or Accounting Management at CCS nodes.

Within each domain subsection, operations requirements are provided for the CCS node’s support of HSLs at each layer of the signaling protocol architecture, e.g., at the physical

4–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Node Operations Requirements December 1999

GR-2878-CORE

(DS1) layer, the ATM layer, the SAAL (including its various sublayers), and MTP level 3 (MTP3), where applicable.

4.1.2 General Considerations and Related Operations Requirements

Under the chosen protocol architecture, each HSL terminated at the CCS node shall be implemented as the endpoint of an ATM Permanent Virtual Circuit (PVC) Virtual Channel Connection (VCC). While the CCS node (STP, SCP, or CCS SO) is not itself an ATM NE, i.e., it is not assumed to have an ATM switching fabric and is not involved in the switching of ATM cells or the cross-connection of ATM Virtual Channel Links (VCLs), each of its HSL terminations is nevertheless an end-point of an ATM VCC. As such, the CCS node must support a subset of the necessary ATM NE operations capabilities applicable to ATM VCC end-points, as well as operations capabilities specific to the SAAL and higher-level functions for each signaling link. Therefore, a subset of the operations requirements defined for ATM NEs and their signaling channels shall be applicable to the CCS node. Those requirements are contained in GR-1248-CORE, Generic Requirements for Operations of ATM Network Elements,[25] and shall be frequently referenced and/or appropriately excerpted in this section. That document in turn references other documents concerning operations requirements for the ATM layer and the physical-level (DS1) interface.

It is assumed that, in its initial implementation, the HSL protocol architecture described in previous sections shall be used to support only a direct, dedicated, point-to-point ATM VCC between each pair of CCS nodes, rather than a multi-VCL VCC involving one or more intermediate ATM NEs, i.e., Broadband Switching Systems (BSSs). Also, the physical-layer (transmission link) termination to be supported is assumed to be DS1 only. These assumptions simplify, to some degree, the operations functions required to support the HSL terminations at CCS nodes. In particular, the single link speed and direct ATM connection simplify requirements for aspects of configuration management, fault management, and performance management at the ATM layer. However, in the future, the same ATM-based HSL protocol stack might be used at CCS nodes with higher link speeds (above DS1) and with multiple (concatenated) VCLs comprising the end-to-end ATM VCC, supported by one or more intermediate ATM NEs. Therefore, CCS node suppliers may wish to consider for their HSL implementation certain configuration management, fault management, and performance management capabilities needed for such architectures that shall not be required at this time for CCS nodes. Such operations capabilities, while not currently cited as requirements or objectives, shall be cited in narrative text as information only for consideration by suppliers.

In addition to operations capabilities pertaining to the ATM and physical layers, higher-level operations functions shall be needed at CCS node to manage the SS7 HSLs as CCS network components. These are based on signaling link operations requirements as defined in the previous-mentioned CCS node GRs. In particular, GR-82-CORE,[12] the STP GR, Section 5 (Operations Requirements), and Section 6 (Performance Management) shall be frequently referenced regarding operations functions concerning signaling link memory

4–2

ab


administration, event reporting, and performance measurements. Many of these requirements shall be directly applicable, or appropriately adapted to, the HSL operations functions as addressed in this section.

4.2 Configuration Management (Memory Administration)

Configuration Management (traditionally Memory Administration) refers to those functions by which management systems and personnel provide data to and retrieve data from network elements for the purposes of identifying, specifying, and configuring the elements’ resources, their routing of traffic, and the services they support. With respect to the CCS nodes’ support of HSLs, these functions shall or may include the administration of translations concerning the HSL physical port terminations at the node, their underlying ATM interfaces and VCLs, and the operational parameters associated with the HSL at each layer of the protocol architecture. For each such configured entity, potentially configurable generic parameters are discussed and requirements and objectives are presented for the subset of those parameters that shall or should be management-configurable. Management-configurable parameters are those that are to be administrable (i.e., set or changed) by management systems or personnel responsible for CCS node configuration management functions. Other generic parameters shall be considered potentially configurable, subject to the supplier’s implementation of the HSL protocol stack.

The following subsections address the potentially configurable parameters at each layer of the HSL protocol stack, along with related requirements for data administration. Specifically,

• Section 4.2.1 addresses so-called “common” link parameters concerning administration of the link as a CCS network component.

• Section 4.2.2 addresses configuration management for the physical layer (DS1).

• Section 4.2.3 addresses potentially configurable parameters for the ATM-layer.

• Section 4.2.4 addresses configuration management for operational parameters to be used by the SAAL.

• Section 4.2.5 addresses configuration of the HSLs’ MTP level 3 link transmit congestion thresholds.

• Section 4.2.7 describes required data operations that must be supported to administer the configured entities and their parameter values.

4.2.1 Configuration of Common Link Parameters

Many CCS nodes (especially STPs) shall likely need to support both the HSLs described in this document and existing conventional 56-Kb/s MTP2-based signaling links within the

4–3


GR-2878-CORE

same node architecture. The HSLs shall have numerous configurable attributes that are expected to be identical to those of conventional 56-Kb/s signaling links.

It is important that the CCS node’s configuration management capabilities support the provisioning of the high-speed link sets and their constituent HSLs as CCS network components in a manner that is as consistent as possible with that used for the 56-Kb/s MTP2 links at the same node, so that similar data fill procedures may be used. This should include the administration of configurable link attributes common to both HSLs and the conventional 56-Kb/s links. Such common link attributes include those that shall be used to uniquely identify each signaling link and should also support a mechanism to distinguish the HSLs from the 56-Kb/s links in terms of their link speed and protocol stack. The latter is necessary so that management systems and the node can determine the proper group of “class-specific” configurable parameters to apply to each link. Such common treatment is strongly desired for both types of signaling links at all CCS nodes. To promote such consistency, the current memory administration data model defined in GR-82-CORE and GR-310-CORE,[26] NetPilot/SEAS-STP Interface Specification: User Program Layer (UPL) Application Message Descriptions and Functional Requirements, for MTP2-based 56-Kb/s signaling links at STPs shall be extended to HSLs at all CCS nodes that support them. The following requirements and objectives address such functionality.

R4-1 [54] The CCS node shall allow authorized management systems and personnel to provision HSLs by assigning each such HSL to a physical port location (link termination) on the node that supports a DS1 interface, and by associating the link with a link set already configured at the node.

R4-2 [55] To facilitate transition activity, i.e., the conversion of link sets from the conventional 56-Kb/s MTP2 protocol stack to the HSL protocol stack, the CCS node’s configuration management capabilities shall allow both 56-Kb/s links and HSLs to coexist (i.e., reside at the same time) in the same link set.

O4-3 [56] It is an objective that CCS nodes supporting both MTP-based 56-Kb/s signaling links and the ATM-based HSLs defined in this document, support the same set of “common” link parameters, as defined in Requirement R4-4 [57], for both classes of signaling links.

It should be noted that O4-3 [56] is stated as an objective, rather then a requirement, to allow for cost or other implementation considerations regarding revisions to existing CM/MA capabilities for the 56-Kb/s links.

R4-4 [57] For HSLs, the CCS node shall allow authorized management systems and personnel to configure, on a per-link basis, the following common SS7 signaling link attributes and parameters:

… a. Link ID: Link Set Name - Member Number (SLC)

4–4

ab


… The unique network identifier of the link, formed by the concatenation of its 8-character alphanumeric COMMON LANGUAGE® Link Set Name (LSN) and 2-character numeric member number (00-15) - the decimal equivalent of its SS7 Signaling Link Code (SLC) - within the link set.

… b. Equipment Port Identifier (supplier-specific)

… The locally unique identifier for the signaling link’s physical port termination at the CCS node (assumed to be a DS1 termination for HSLs). The port equipment may be separately configurable.

… c. Link Speed

… The nominal data rate for the signaling link excluding transmission (level 1) overhead, to be set at 1.536-Mb/s for HSLs1. (Other recognized configurable link speeds currently defined in generic requirements include 9.6, 56, and 64-Kb/s, although only 56-Kb/s is commonly used in North America.)

… d. Link Class (new2)

… An alphanumeric identifier conveying the type of signaling link, in terms of its protocol architecture, which shall determine its applicable group of configurable parameters. Two link classes shall be initially supported:

… - SAAL- MTP2.

… HSLs shall be assigned to link class “SAAL,” corresponding to a given set of parameters applicable to the MTP3/SAAL/ATM protocol stack discussed. (Conventional 56-Kb/s signaling links utilizing the MTP3/MTP2 protocol stack shall be assigned to link class “MTP2,” corresponding to their own applicable set of parameters, including, for example, MTP level-2 [T1.111.3] timers.)

… e. Link Parameter Set Identifier (new)

1. 1.536-Mb/s is the approximate data rate available to the ATM cells on the ATM VCC supporting each HSL after the DS1 overhead is deducted from the 1.544-Mb/s DS1 line rate. The effective data rate available to transport MTP3 messages is less than this value due to additional overhead at the ATM layer (including ATM cell headers), and the AAL-CP5 and SSCOP sublayers of the SAAL, and is subject to assumptions regarding average MTP3 message size and traffic mix. Higher link speeds may be applicable in the future, but are beyond the scope of the HSL definition and requirements addressed in this document.

2. “New” denotes that this attribute has not previously been defined in prior generic requirements documents as an attribute of 56-Kb/s signaling links.

4–5


GR-2878-CORE

… An alphanumeric identifier referencing a particular set of configured values for the link parameter set that shall be assigned to the given link, and which shall be applicable to a given population of signaling links in that link class sharing the same value of this identifier. Links in the same link class may be assigned to different link parameter sets if their differing physical characteristics, such as link speed, length (which determines propagation delay), node capabilities at each end, or facility quality, necessitate the use of different values for the applicable parameters.

When provisioned, each HSL shall be assigned values for its Link Class (= “SAAL”) and Link Parameter Set ID, which shall in turn be mapped by the CCS node to a separately administered “table” or “vector” of values to be used for that link. This scheme shall allow a set of link parameter values to be administered at the CCS node in a single data structure and applied to (i.e., shared by) a multiplicity of links within that class that have the same characteristics, rather than require that management administer them redundantly on a per-link basis.

R4-5 [58] Each HSL shall be assignable to a configured Link Parameter Set under Link Class = “SAAL” based on the value of its populated Link Parameter Set Identifier. The CCS node shall use the values of the SAAL parameters and MTP level 3 congestion thresholds defined in that parameter set to support relevant level 2 and level 3 processing for the HSL.

Requirements for the configuration of the parameter values comprising each HSL Link Parameter Set are addressed in Sections 4.2.4 (Configurable Parameters: SAAL (SSCOP/SSCF/Layer Management)) and 4.2.5 (MTP3 Link Congestion Thresholds).

Per O4-3 [56], the same general scheme is intended for application to both HSLs and conventional 56-Kb/s links at the same CCS node, although the identity of the link parameters referenced shall be different for each link class (SAAL or MTP2).

Telcordia may update GR-310-CORE[26] and GR-82-CORE[12] in the future so that the new link attributes, Link Class and Link Parameter Set ID are incorporated within the generic CM/MA data model for all signaling links at STPs. While the requirements discussed in Section 4.2.1 do not strictly apply to CCS nodes supporting only 56-Kb/s MTP2-based signaling links, support of the common attributes for all signaling links at all CCS nodes is strongly encouraged.

Under the data model specified in this section, link-speed and link-class (the latter denoting the protocol stack) are separately configurable, so as to decouple the relationship between link speed and protocol. This has been done for reasons of flexibility and forward compatibility with possible future combinations of link speeds and protocol stacks. The only required combinations to be supported by the CCS node are “56-Kb/s MTP2” and

4–6

ab


1.536-Mb/s SAAL”. Other combinations are possible, such as “1.536-Mb/s MTP2.” However, such protocol architectures are beyond the scope of the HSL definition and requirements addressed in this document3.

CR4-6 [59] In addition, if applicable to the CCS node’s HSL implementation, the CCS node shall support the administration of all implementation-specific configurable parameters of the following types on a per-link basis:

… a. Port Equipment Options (implementation-specific)

… Any implementation-specific parameter settings for the equipment comprising the link termination, configurable on a per-link basis.

… b. Other Supplier-Specific Link Attributes

… Any other supplier-specific link parameters, identifiers, or other link attributes configurable on a per-link basis.

A more detailed description of the this generic link’s attributes is provided in GR-310-CORE,[26] Section 7.1.1.1.2.3 E. Although these link attributes are defined generically only for STPs in that document, their descriptions there are the most detailed currently available for these link parameters in the CCS node GRs, and shall be regarded as applicable to the other CCS node types (SCPs and CCS SOs) as well.

Additional configurable link attributes (parameters) that are applicable only to HSLs are addressed in the following subsections. Some of these parameters shall be required as management-configurable on a per-link basis. Others shall be management-configurable as part of a link parameter set, which may be assigned to a population of one or more HSLs within the defined HSL link class. Still others pertaining to ATM-specific aspects of the protocol stack are merely identified as potentially configurable.

4.2.2 Configurable Parameters: Physical Layer Interface (DS1)

At this time, no generic configurable parameters have been identified as required for the support of the CCS nodes’ HSL physical layer (DS1) interfaces.

4.2.3 Configurable Parameters: ATM Layer

At the ATM layer, each HSL shall be implemented as an ATM Permanent Virtual Circuit (PVC) Virtual Channel Connection (VCC) between the two interconnected CCS nodes.

3. The funding Telcordia clients currently have no plans to deploy 1.536-Mb/s signaling links using the MTP2 protocol.

4–7


GR-2878-CORE

As perceived by each CCS node at this layer, each HSL is an ATM Virtual Channel Link (VCL) termination. In the ATM environment, each VCL terminating at an ATM NE is uniquely identified by the combination of its physical port identifier (i.e., “the ATM interface”), an ATM Virtual Path Identifier (VPI), and an ATM Virtual Channel Identifier (VCI). At ATM NEs, many thousands of VCLs may terminate at a single ATM interface, hence the VPI and VCI are needed to uniquely distinguish each VCL. Both the ATM interface and each VCL that terminates at that interface are separately configurable at ATM NEs, per requirements in GR-1110-CORE,[27] Broadband Switching System (BSS) Generic Requirements and GR-1248-CORE.[25] That is, the ATM interface is configured, then VCLs are configured and assigned to that ATM interface. Under those requirements, the ATM interface and each VCL have numerous management-configurable or potentially configurable parameters, including the VPI and VCI values to be assigned to each VCL.

For the special case of the initial HSL application at CCS nodes, as defined in this document, each terminated HSL shall correspond to a single, direct, ATM VCL on a DS1-rate ATM interface4. This can simplify configuration management. For example, because there is only a single VCL termination per interface, any fixed VCI value might be used for the HSL’s VCL, provided that the same value is used at each end of the link. (However, VCI=5 shall be the recommended VCI value for HSLs, consistent with the conventional value reserved for the signaling channel between ATM NEs.)

It should also be possible to fix the values of most of the other generic ATM interface and VCL parameters (i.e., treat them as predefined or simply not applicable as variable parameters) for each HSL, rather than configure them via management systems as they would need to be at ATM NEs. This is because the wider range of configurable parameter values for these objects shall not be needed. Such predefined ATM parameter values may be treated as “hard-coded” values by the CCS node supplier as a function of a specialized HSL interface design.

However, it is conceivable that some suppliers may “reuse” “off the shelf” ATM NE components, such as ATM interface cards in their HSL implementations at CCS nodes. In these cases, such components are likely to support a wider range of configurable values for these ATM parameters. It may be necessary for suppliers utilizing such equipment in their HSL implementation to preset or pre-configure these parameters to applicable values. In such cases, the ATM-level parameters might be configured automatically by the CCS node’s system management function prior to HSL activation at the time the supporting equipment unit or units (e.g., the ATM interface cards) for the HSLs are installed, equipped, defined to the node, or put into service. Alternatively, the CCS node supplier may elect to implement some or all of these ATM-layer parameters as management-configurable for flexibility, in case the node’s ATM interfaces may need to support other HSL architectures in the future, such as higher link speeds, multiple VCLs per ATM interface and/or multi-segment (multi-VCL) VCCs switched through one or more intermediate ATM NEs.

4. The ATM layer is capable of supporting higher-speed interfaces and multiple VCCs per interface, but such architectures are beyond the scope of the HSL definition addressed in this GR.

4–8

ab


Because of these considerations, and to promote consistency with ATM NE configuration management requirements, it may be useful for CCS node suppliers to implement each HSL’s ATM interface and VCL termination as separate configured entities with separate potentially configurable parameters.

Whether or not the indicated ATM-layer parameters are in fact made management-configurable shall be left to the supplier as an implementation issue. For each of these potentially configurable ATM-layer parameters, the suitable predefined or default value applicable to a direct-VCC HSL shall be identified in the following subsections. Also presented, for supplier consideration, shall be additional information regarding the potential value added by the CCS node treating selected ATM-interface and VCL parameters as management-configurable, to promote forward compatibility with possible future HSL architectures.

4.2.3.1 Configuration of the ATM Interface at the CCS Node

Each HSL termination at the CCS node shall be functionally regarded as an ATM Broadband Network Node Interface (B-NNI) utilizing ATM Virtual Circuit (VC) service (rather than Virtual Path (VP) service).

According to configuration management requirements defined for ATM NEs’ in GR-1248-CORE,[25] Section 5.2.1, the following parameters are to be maintained at the ATM NEs for each ATM interface, either as management-configurable parameters or as attributes assigned or determined by the implementation:

• Interface ID

• Maximum number of simultaneously active Virtual Path Connections (VPCs) supported

• Maximum number of simultaneously active Virtual Circuit Connections (VCCs) supported

• Number of allocated VPI bits

• Number of allocated VCI bits.

(Note that additional ATM interface parameters specified in GR-1248-CORE,[25] Section 5.2.1 are not applicable to HSLs, as they apply to UNI and B-ICI ATM interface’s only. Those include ATM Subscriber Address [UNI only], Preferred Carrier [UNI only], ILMI Channel Identifier [UNI only], and Carrier Network [B-ICI only]).

Depending on the nature of the CCS node’s implementation of the ATM-layer for HSLs, it may be necessary to preset or configure the parameters for each HSL’s ATM interface. The following text addresses the relevant configuration management functionality for these potentially configurable parameters.

4–9


GR-2878-CORE

1. Interface ID

This parameter contains the locally unique ID of the underlying physical path termination point at the NE. Because there is only a single ATM interface mapped to the DS1 interface at the CCS node, there is no need to treat the ATM interface as a separately configurable entity distinct from the link port cited earlier. If necessary to support the configuration of the ATM interface at the CCS node, this identifier may be set equal to the Equipment Port Identifier for the HSL’s physical port termination, which is required to be configurable as a common link parameter, as specified in Section 4.2.1. The format for this parameter shall be implementation-specific.

2. Maximum number of simultaneously active Virtual Path Connections (VPCs) supported (by the ATM interface)

For the initial implementation of HSLs as defined in this document, ATM Virtual Connection (VC) service, rather than Virtual Path (VP) service shall be required. That is, the ATM interface is required to support only a single DS1-rate VC connection, and no VP connections (i.e., VPI = 0 shall be used). Therefore, this parameter may be set equal to 0 (zero) if necessary to configure the ATM interface. Although normally configurable from 1 to 12 at ATM NEs, there would be no need to configure this parameter to other values unless higher-rate ATM interfaces, each supporting multiple HSLs, using VP service (with VPI values other than 0) were being considered for future implementation. Such architectures are not currently envisioned for CCS nodes.

3. Maximum number of simultaneously active Virtual Circuit Connections (VCCs) supported

For the initial implementation of HSLs as defined in this document, the ATM interface shall be required to support only a single VC connection at the DS1-rate for the HSL. Therefore, this parameter may be set equal to 1 (one) if necessary to configure the ATM interface. There would be no need to configure this parameter to other values unless higher-rate ATM interfaces (such as over DS3 or SONET), each supporting multiple HSLs on corresponding VCCs, were being considered for future implementation. Such architectures are not currently envisioned for CCS nodes.

4. Number of allocated VPI bits

This parameter conveys the number of bits to be used in the VPIs in the ATM cells for the VPLs terminated on the ATM interface. This parameter may be set equal to 1 at CCS nodes for HSLs, since the ATM interface shall support only a single DS1-rate VC connection, and no VP connections (i.e., VPI = 0 shall be used). Only 1 bit is needed to express VPI=0. Although this parameter is normally configurable from 1 to 12 at ATM NEs, there would be no need to configure it to other values unless higher-rate ATM interfaces, each supporting multiple HSLs, using VP service (with VPI values other than 0) were being considered for future implementation. Such architectures are not currently envisioned for CCS nodes.

4–10

ab


5. Number of allocated VCI bits

This parameter conveys the number of bits to be used in the VCIs in the ATM cells for the VCLs supported on the ATM interface. The range of possible VCI values supported shall be dependent on the maximum number of VCI bits that may be recognized by the ATM interface equipment when processing each ATM cell header. This value is generally implementation dependent. To support only the recommended VCI value of 5 for the required single VCC supporting the HSL on the ATM interface, at least 3 bits are needed. This parameter may therefore be set to 3 if necessary for the CCS node to configure its ATM interface. It is not required at this time for this parameter to be management-configurable. However, suppliers may wish to consider making this parameter management configurable if the HSL’s ATM VCI is implemented as management-configurable and allows VCI values larger than 5. (Also see Section 4.2.3.2.) This would enable the ATM interface to accommodate any differences in the number of VCI bits supported at the CCS node at each end of the VCL. ATM header formats shall allow values for this parameter to range between 3 and 16 bits. If this parameter were implemented as management configurable and no management input was provided, the CCS node might default to the maximum number of VCI bits supported by the relevant equipment unit(s) comprising the ATM interface at the CCS node.

O4-7 [60] It is an objective that the CCS node support management system requests to retrieve the current or assumed values of the ATM interface parameters (i.e., whether or not they are management-configurable) for each HSL.

4.2.3.2 Configuration of the Signaling Link VCC/VCL

The ATM VCC termination (i.e., VCL) supporting each HSL shall have a number of potentially configurable parameters. These shall include the VCI value to be used for the ATM cells transmitted and received on that VCL, descriptive information for the VCL, and ATM traffic descriptors, which define the bandwidth allocated to the VCC along with other performance parameters. As was the case for the ATM interface parameters, many of the VCC/VCL parameters may be fixed for HSLs, but may be made management-configurable depending on the HSL implementation and supplier considerations regarding forward compatibility with possible future network architectures. The following text addresses the relevant configuration management functionality for these potentially configurable parameters.

4–11


GR-2878-CORE

4.2.3.2.1 VCL Identifiers

According to configuration management requirements defined for ATM NEs’ ATM interfaces in GR-1248-CORE,[25] Section 5.2.2, the following parameters concerning VCC/VCL identity are generally management-configurable:

• Locally unique identifier for the VCL termination

• Identity of the underlying (supporting) VPC termination

• Identity of the underlying (supporting) VCC termination

• VPI value

• VCI value.

Of these parameters, all may be fixed for the HSL implementation at CCS nodes as defined in this document. However, it may be desirable that the VCI value be management-configurable to provide additional flexibility in VCI assignments and for reasons of forward compatibility with possible future architectures. Configuration management considerations and applicable assumed or default values for each of these VCL parameters are discussed in the following list.

1. Locally unique identifier for the VCL termination

This parameter contains the locally unique ID of the HSL’s VCL termination at the CCS node. Because there is only a single VCL supported on the ATM interface, directly mapped onto to a DS1 interface, there is no need to treat the VCL as a separately configurable entity distinct from the link port cited earlier. If necessary to support the configuration of the VCL at the CCS node, this identifier may be set equal to the Equipment Port Identifier of the HSL’s physical port termination (for convenience), which is required to be configurable as a common link parameter, as specified in Section 4.2.1. The format for this parameter shall be implementation-specific. There would be no need to configure this parameter to other values unless multiple HSL VCC terminations were to be implemented on the same physical interface operating at some higher rate, e.g., DS3, in the future. Such architectures are not currently envisioned for CCS nodes.

2. Identity of the underlying (supporting) VPC termination

Again, for the initial implementation of HSLs as defined in this document, VP service will not be used for HSLs, so there will be no VPC termination. This parameter may be set to null if necessary to configure the HSL’s VCC. That is, VPI = 0 is implied for VC service rather than VP service. This parameter need not be management-configurable.

4–12

ab


3. VPI value

The virtual path identifier to be used for ATM cells on the VCL. The VPI shall be set = 0 for VC service, since VP service is not needed for HSLs. This parameter need not be management-configurable.

4. VCI value

The VCI value is the numeric virtual channel identifier to be used for ATM cells on the VCL. A specific value must be either configured or predefined for the HSL implementation at CCS nodes. For the initial HSL implementation defined in this document, a default VCI value of 5 is recommended, consistent with the conventional value reserved for the signaling channel between ATM NEs. It is not required for the VCI to be management configurable at this time.

However, it may be desirable for suppliers to implement the VCI as a management-configurable parameter in order to provide additional flexibility in anticipation of possible future HSL architectures, for which a variable VCI assignment might be needed. In the future, ATM NEs may be used as intermediate nodes (between the CCS nodes) in each HSL’s ATM VCC. Alternative node architectures have also been discussed in which CCS STPs are implemented in combined nodes having both STP and ATM NE (BSS) functions. In such cases, a predefined VCI value (such as VCI = 5) may be already assigned for the ATM interface termination at the ATM NE’s end of the VCL. For example, network administrations may have the need to separate associated signaling traffic (e.g., ATM NE-to-combined node B-ISUP messages already using VCI = 5) from quasi-associated signaling traffic (e.g., ATM NE TCAP queries bound for SCPs via the STP function) on different VCCs terminating on the same ATM interface at the STP. By making the VCI configurable, the CCS node could provide additional flexibility to address such contingencies.

If this parameter was to be made management configurable at the CCS node, it is recommended that be supported as the decimal equivalent of the binary 16-bit VCI address. For the VCI, the ATM cell header format supports an allowable value set of 5, and 32 through M, where M = 2N - 1 (N = the allocated number of VCI bits for the ATM interface, M <= 65535). (Per ATM standards, VCI values 0-4 and 6-31 are reserved and may not be used.)

The following requirements and objectives apply regarding configuration management for each HSL’s ATM VCL termination.

R4-8 [61] If the HSL implementation does not support the ATM VCL’s VPI and VCI values as management configurable parameters, or if those parameters are implemented as management-configurable, but no management input is provided, the CCS node shall default to the values VPI = 0 and VCI = 5, consistent with the conventional values of these parameters used for the signaling channel between ATM NEs.

4–13


GR-2878-CORE

O4-9 [62] It is an objective that the CCS node support management system requests to retrieve the current or assumed values of the ATM VCL parameters (i.e., whether or not they are management-configurable) for each HSL.

R4-10 [63] Each ATM VCL supporting HSL(s) at the CCS network node shall be automatically configured as a VCC endpoint, per GR-1248-CORE, Section 5.2.3 (R5-11).

4.2.3.2.2 VCL ATM Traffic Descriptors

According to configuration management requirements defined for ATM NEs in GR-1248-CORE,[25] Section 5.2.2, a series of ATM Traffic Descriptors are to be maintained for each ATM VCL. These traffic descriptors include parameters that may be used by the ATM NE for the allocation of capacity to the VCC and policing parameters that are enforced (in the ingress direction only) at those ATM interfaces for which a Usage Parameter Control (UPC) or Network Parameter Control (NPC) function is available. These parameters are primarily a function of the bandwidth to be used by the VCL, in contention with the other VCLs terminating on the same ATM interface. They may also be used to allocate internal resources within the ATM NE to that particular ATM VCL. These parameters, which may be management-configurable for VCLs at ATM NEs, include

• Ingress and Egress Peak Cell Rate (PCR) for Cell Loss Priority (CLP)=0 and CLP=0+1 traffic

• Ingress and Egress Sustainable Cell Rate (SCR) for CLP=0 and CLP=0+1 traffic

• Ingress and Egress Burst Tolerance (BT) for CLP=0 and CLP=0+1 traffic

• Ingress and Egress Cell Delay Variation (CDV) tolerance for CLP=0 and CLP=0+1 traffic

• Ingress and Egress Quality of Service (QoS) Class.

More detailed information on ATM Traffic Descriptors may be found in GR-1110-CORE,[27] Sections 6.3.1 and 8.6.2.

For the DS1-rate HSL implementation at CCS nodes, a single link speed (corresponding to a constant peak cell rate) shall be used, and only one VCL supporting the HSL shall be terminated for each ATM interface. In this application of ATM, there is no contention for bandwidth or other resources among VCLs, therefore the use of the ATM traffic descriptors shall not be required. Subject to the implementation of the ATM interface for HSLs at the CCS node, these traffic descriptors shall likely be treated as constants or may simply not be applicable to ATM-layer processing if such allocation and policing functions are not supported or are disabled. Therefore, they are not required to be management-configurable

4–14

ab


at this time. However, they may be regarded as potentially management-configurable given the following considerations:

— Values for the traffic descriptors may need to be preset or automatically configured for each HSL’s ATM VCL if the HSL implementation utilizes ATM interface equipment (e.g., ATM interface cards) designed to support a wider-range of ATM-based services.

— In addition, it may be desirable for CCS node suppliers to implement these traffic descriptors as management-configurable in order to support the possibility of higher link speeds (i.e., higher-rate interfaces above DS1), multiple VCLs per ATM interface (i.e., per transmission link), and varying performance criteria for the HSLs in the future.

For each ATM traffic descriptor, the following text defines the applicable default values to be automatically configured or assumed by the CCS node, if necessary, for the HSL application. Also included for each traffic descriptor is a discussion of additional considerations regarding the possible support of each descriptor as a management-configurable parameter.

1. Ingress and Egress Peak Cell Rate (PCR) for Cell Loss Priority (CLP)=0 and CLP=0+1 traffic

The PCR defines the maximum or peak cell rate for the VCL. For the HSL capability defined in this document, this parameter may be set to the constant value of 3622 cells per second, corresponding to the approximate equivalent bandwidth of 1.536-Mb/s available to ATM cells when directly mapped onto DS1 frames. If necessary, this value may be preset or assumed by the implementation. This parameter need not be management configurable, unless other link speeds shall also be supported on the ATM interface equipment.

The possibility exists that higher-rate link terminations may be supported in the future at CCS nodes (e.g., on DS3 or SONET interfaces) with the same overlying protocol stack. In such cases, each ATM interface could support a number of potentially higher-speed HSLs, each on its own ATM VCL. In anticipation of such an implementation, it may be desirable that Peak Cell Rate be made management-configurable rather than pre-set for the VCL. CCS node suppliers may wish to consider such an alternative in their ATM interface designs.

2. Ingress and Egress Sustainable Cell Rate (SCR) for CLP=0 and CLP=0+1 traffic

The SCR defines the objective long-term average cell rate to be supported on the VCL. For the HSL application of ATM, as defined in this document, where only a single DS1-rate VCL is supported for each ATM interface and there is no contention for the available bandwidth, enforcement of this parameter is not considered important. If necessary for the CCS node’s implementation of the interface, the SCR may be set equal to the PCR value of 3622 cells per second as defined in item 1. As was the case for the PCR, the SCR value may be preset or assumed by the implementation, if

4–15


GR-2878-CORE

necessary. This parameter need not be management-configurable, unless other link speeds shall also be supported.

For the same reasons cited in the preceding item (item 1) for the PCR, suppliers may wish to consider making this parameter management-configurable in support of potentially higher link speeds and multiple VCLs (HSLs) on each ATM interface, in the future.

3. Ingress and Egress Burst Tolerance (BT) for CLP=0 and CLP=0+1 traffic

The BT parameter determines the maximum burst size (MBS), i.e., the number of consecutive cells on the VCL that shall be permitted onto the ATM interface by the enforcement process, given the peak cell rate and the physical-layer line speed. It restricts any one VCL from dominating the ATM interface’s cell stream during traffic bursts. It must be set to accommodate at least the largest-sized level-2 PDU anticipated for the application. For the HSL application, where the ATM interface supports only one VCL on the ATM interface, enforcement of this parameter is generally not applicable. However, if necessary to support the HSL implementation, the largest value defined for this parameter may be used. According to GR-1110-CORE,[27] Section 6.3.1.4, Table 6-4, that largest BT value corresponds to an MBS of 210 cells. This value may be preset or assumed by the implementation, if necessary.

This parameter need not be management configurable at the CCS node, unless multiple-VCL ATM interfaces are being contemplated for future HSL applications.

4. Ingress and Egress Cell Delay Variation Tolerance (CDVT) for CLP=0 and CLP=0+1 traffic

CDVT defines the amount of cell delay variation to be accommodated by the enforcement function for the VCL in the network ingress direction. For the HSL application at CCS nodes, where only a single VCL is supported on the ATM interface, significant cell delay variations are not anticipated. Therefore, the smallest defined value for this parameter may be configured, if necessary, for the CCS node’s HSL implementation. Allowable configurable values currently defined for the DS1 UNI in GR-1110-CORE include: 100, 150, 200, 250, 350, or 500 microseconds. The CCS node may therefore default to or assume the smallest configurable CDVT value allowed, i.e., 100 microseconds, as specified in GR-1110-CORE,[27] Table 6-2, Column 1.

This parameter need not be management-configurable at the CCS node, unless multiple-VCL ATM interfaces are being contemplated for future HSL applications. Operating experience may indicate that values other than the assumed default may be needed.

5. Ingress and Egress Quality of Service (QoS) Class

The QoS Class determines the performance objectives that must be met by the ATM VCL when it must discard cells during enforcement of the traffic parameters. It is

4–16

ab


generally used for statistical multiplexing of ATM cells from multiple VCLs onto the ATM interface. Each assigned class value corresponds to performance parameter values for Cell Loss Ratio and Cell Delay Variation as specified in GR-1110-CORE,[27] Section 8.6.2, Table 8-8. Allowable values of QoS Class for DS1 direct-mapping ATM interfaces currently include QoS classes 1, 3, and 4. Its use is generally not applicable to the single-VCL ATM interfaces required for the HSL application. However, if necessary to support the HSL implementation, the CCS node should default to QoS Class 3, the minimum acceptable QoS intended to support low latency, connection-oriented data transfer applications. This QoS class corresponds to an ATM cell loss ratio of less than or equal to 10-7. It is believed to be adequate for the HSL application.

This parameter need not be management-configurable at the CCS node, unless multiple-VCL ATM interfaces are being contemplated for future HSL applications.

Because the traffic descriptor parameters shall likely be the same for all HSLs or large subpopulations of them, rather than set on a per-link or per-VCL basis, they would probably best be configurable on a per-link-parameter-set (LPS) basis, if they were to be supported as management-configurable parameters at CCS nodes.

CR4-11 [64] The CCS node shall utilize the following default values for the indicated ATM traffic descriptors for each ATM interface supporting HSLs:

… 1. PCR = 3622 cps

… 2. SCR = 3622 cps

… 3. BT = 210 cells

… 4. CDVT = 100 microseconds

… 5. QoS Class = 3

… or other, suitable, implementation-dependent default values, in the event that the ATM traffic descriptors must be configured to support the HSL interface implementation, but the node does not support those attributes as management-configurable parameters for each HSL.

O4-12 [65] It is an objective that the CCS node support management system requests to retrieve the current or assumed values of the ATM traffic descriptor settings (i.e., whether or not they are management-configurable) for each HSL. Parameters for which no applicable values are configured should be populated and reported as null arguments.

4–17


GR-2878-CORE

4.2.4 Configurable Parameters: SAAL (SSCOP/SSCF/Layer Management)

A variety of timers and other parameters shall be employed by the SAAL’s SSCF, SSCOP, and Layer Management (LM) entities at the CCS node to provide level-2 functions for each HSL. These parameters are expected to be fixed for large numbers of, if not all, HSLs using the 1.536-Mb/s nominal link speed. Yet there is a possibility that these parameters may need to be tuned for different subpopulations of HSLs to accommodate differences in physical attributes, such as link length (propagation delay), the quality of service on available facilities, or equipment capabilities at each end of the link. They may also need to be changed in the future if the specified protocol stack is someday used with higher link speeds. Therefore, these parameters shall be configurable on a per-link-parameter-set basis. (Requirements R4-13 [66] and CR4-14 [67] are consistent with those applicable to ATM NE signaling channels as defined in GR-1248-CORE,[25] Section 14.3.2, Requirements R14-1 and R14-2, and GR-1417-CORE,[28] Broadband Switching System SS7 Requirements Using the Broadband Integrated Services Digital Network User Part [BISUP], Table 2-1.)

R4-13 [66] The CCS node shall support as management-configurable attributes, the following SAAL parameters for HSLs, including the indicated allowable parameter units and minimum configurable ranges, as identified in Table 3-1, on a per-link-parameter-set (LPS) basis for each LPS configured under Link Class = “SAAL”:

… 1. SSCOP: MaxCC/T1.637

… 2. SSCOP: MaxPD/T1.637

… 3. SSCOP: MaxSTAT/T1.637

… 4. SSCOP: Timer_CC/T1.637

… 5. SSCOP: Timer_KEEP-ALIVE/T1.637

… 6. SSCOP: Timer_NO-RESPONSE/T1.637

… 7. SSCOP: Timer_POLL/T1.637

… 8. SSCOP: Timer_IDLE/T1.637

… 9. SSCF-NNI: Timer_T1/T1.645



… 12. SSCF-NNI: n1/T1.645

… 13. SAAL LM: Max_NRP/T1.652

… 14. SAAL LM: Timer_REPEAT-SREC/T1.652

4–18

ab


… 15. SAAL LM: Timer_NO-CREDIT/T1.652

… 16. SAAL LM: ISERM: T_sup/T1.652

… 17. SAAL LM: ISERM: T_loss/T1.652

… 18. SAAL LM: ISERM: alpha/T1.652

… 19. SAAL LM: ISERM: thres/T1.652

… 20. SAAL LM: ISERM: Tau/T1.652

… 21. SAAL LM: ISERM: N_blk/T1.652

… 22. SAAL LM: ISERM: N/T1.652

… 23. SAAL LM: Timer_FORCE-PROVING/T1.652.

CR4-14 [67] If the CCS node’s HSL implementation supports the Fixed Credit mechanism for level 2 flow control, as defined in Appendix A (Guidelines for Peer-to-Peer Credit Flow Control and Receive Buffer Sizing), then the node shall support the administration of the following additional configurable parameters for each Link Parameter Set (LPS) configured under Link Class = “SAAL”. (Also indicated are suggested minimum configurable parameter ranges and default values.)

… 1. Fixed Credit Allocation, in terms of one of the following two configurable parameters:

… a. Fixed Credit Increment (NR), in units of SSCOP PDUs per update (allowable range: 300-2000 PDUs, default = 1200 PDUs)

… b. Equivalent Fixed Credit Allocation Rate (RPDU), in units of SSCOP PDUs per second throughput allowed by the flow-control algorithm (allowable range: 150 - 3622 PDUs/sec, default = 3622).5

… 2. Fixed Credit Allocation Frequency (bc), referring to the granting of the additional fixed credit allocation with every nth STAT PDU (n = bc), (allowable range = 1-5 STATs, default = 3 STATs).

… If the CCS node does not support the fixed credit mechanism, these parameters shall be coded as null values in the LPS.

5. The recommended configurable range assumes the worst-case of single-cell PDUs, a minimum allowed throughput of one DS0-rate link equivalent, and a maximum throughput equal to the full physical capacity of the DS1-rate link (3622 cps). The recommended default corresponds to 1.0 erlangs throughput per HSL, the maximum physical occupancy of the link, assuming the HSL implementation can support such PDU rates at MTP level 3. A lower default value commensurate with the HSL NE’s MTP3 actual throughput capacity per HSL may be applicable instead, and if so, should be used to prevent receive-buffer overflow.

4–19


GR-2878-CORE

The Fixed Credit flow control parameters, including the recommended default values and acceptable ranges, are sensitive to related assumptions regarding the status polling interval, average PDU size, link length (due to the effects of propagation delay), and the rate at which the level 3 processor can accept and process incoming MTP3 messages. These values are based on an assumed polling (“inter-STAT” interval) of 100 ms (the recommended default) and link lengths ranging from near 0 to 5000 miles. Detailed considerations for the setting of these parameters are discussed separately in Appendix A.

If the implementation chooses to parameterize the flow control procedure via the PDU processing rate (RPDU) rather than NR, i.e., item 1(b) rather than 1(a), it is assumed that it can then use RPDU and bc to calculate NR for the real-time application of the flow control mechanism.

It is expected that the HSL NE will establish its own suitable implementation-specific default value and configurable range for NR or RPDU, based on the PDU throughput that can be supported by its SAAL implementation and its MTP level 3 processing capacity per HSL. In particular, the upper limit of the configurable range should correspond to a rate at which the implementation can still accept and process the SSCOP PDUs. Similarly, the Fixed Credit Allocation Frequency (bc) default value and configurable range should be established based on the HSL NE implementation’s ability to grant credit to the transmitter with the indicated frequency.

CR4-15 [209] If the CCS node’s HSL implementation supports the Fixed Credit mechanism for level 2 flow control, it shall establish suitable default values and configurable ranges for parameters NR or RPDU, and bc, that are appropriate for its flow control implementation and consistent with the available throughput capacity per HSL.

4.2.5 MTP3 Link Congestion Thresholds

MTP-level 3 transmit congestion thresholds, which are applicable in general for SS7 signaling links, regardless of their level-2 protocol, shall be supported for both HSLs and conventional 56-Kb/s signaling links. Unlike conventional 56-Kb/s signaling links, however, the HSL transmit congestion thresholds are expected to be larger in value, due to the higher link speeds and larger link transmit buffers, and shall be based on MTP3 messages or MTP3 message octets rather than the prior measures of MSUs or MSU octets. The CCS node shall utilize the same scheme for parameter administration via link class and link parameter set as defined for the applicable ATM and SAAL-layer parameters.

R4-16 [69] The CCS node shall support as management-configurable parameters the following MTP level 3 link transmit congestion thresholds, for each Link Parameter Set configured under Link Class = “SAAL”:

… 1. Level 1 onset

4–20

ab


… 2. Level 1 discard

… 3. Level 1 abatement



… 6. Level 2 abatement



… 9. Level 3 abatement.

O4-17 [70] It is an objective that the CCS node utilize the recommended default values specified in Table 4-1 for HSL MTP3 link congestion thresholds in the absence of management input.

Assumptions and considerations regarding the recommended default congestion thresholds are documented in Appendix C. For any of the MTP3 link congestion thresholds, suppliers may elect to use alternative, implementation-specific default values in lieu of the recommended defaults.

4.2.6 Link Marginal Performance Thresholds

HSL NEs shall be required to support threshold crossing alerts and exception reporting of HSL marginal performance per performance management requirements specified in Section 4.5.2.1. These thresholds concern performance management measurements collected at the SAAL and MTP3 layers.

O4-18 [210] It is an objective that the HSL NE support as management-configurable parameters on a per-link-parameter-set basis,6 HSL hourly marginal performance thresholds for the following hourly performance management measurements, as defined in Sections 4.5.1.1, 4.5.1.3, and 4.5.2.1. (Also indicated are suggested minimum configurable parameter ranges and default values.7)

… 1. Number of Automatic Changeovers (default = 3; range = 1 to 32)

6. These parameters are required to be user-settable on at least a per-node basis for all HSLs by the fault management function, per R4-102, but their handling by configuration management on a per-LPS basis is preferred as conveyed in this objective. In addition, fault management should also be able to modify HSL MP thresholds for established LPSs per O4-103.

7. Defaults and configurable ranges may be implementation dependent. Values shown are suggested only. See also Appendix E.

4–21


GR-2878-CORE

… 2. SSCOP SD PDUs Transmitted Requiring Retransmission(default = 550; range = 10 to 10000)

… 3. SSCOP Connection Sum-of-Errors Counter(default = 5; range = 1 to 32)

… 4. SSCOP Errored PDUs Sum-of-Errors Counter(default = 2; range = 1 to 32).

(See also Section 4.5.2.1 and Appendix E regarding the HSL NE’s application of the HSL marginal performance thresholds and its establishment of suitable default values.)

4.2.7 Link Parameter Administration: Data Operations

R4-19 [71] Via its local User System Interface and via interfaces to authorized management systems responsible for configuration management functions, the CCS node shall support common configuration management data operations for HSLs consistent with those supported for conventional 56-Kb/s signaling links. These include:

… 1. Assign/Add a Signaling Link

… The ability to create the signaling link as an object within the node’s configuration management data base, establish its identity via its unique identifiers, assign the link to an equipped link port, associate it with an already configured link set, and configure all other link-level attributes or parameters as defined in Section 4.2.1.

… 2. Delete/Disconnect a Signaling Link

… The ability to remove the link as an object from the node’s configuration management data base after it is no longer in service.

… 3. Change Signaling Link Attributes

… The ability to reconfigure all configurable link-level attributes or parameters, other than the link’s unique identifiers, as defined in Section 4.2.1.

… 4. Retrieve/Verify Signaling Link Parameters

… The ability to retrieve from the CCS node’s configuration management data base the values of all configurable link-level attributes or parameters as defined in Section 4.2.1.

… 5. Add/Define Link Parameter Set

… The ability to create a link parameter set as an object within the node’s configuration management data base, establish its identity via the

4–22

ab


assignment of a unique Link Parameter Set Identifier within that link class, and configure all link-parameter-set-level attributes or parameters as defined in Sections 4.2.2 through 4.2.6.

… 6. Delete Link Parameter Set

… The ability to remove the link parameter set and its parameter values as an object from the node’s configuration management data base after it is no longer referenced (used) by any configured signaling link.

… 7. Update Link Parameter Set

… The ability to reconfigure all link-parameter set-level attributes or parameters, other than the LPSI, for a given LPS as defined in Sections 4.2.2 through 4.2.6.

… 8. Retrieve/Verify Link Parameter Set

… The ability to retrieve from the CCS node’s configuration management data base the values of all configurable link-parameter-set-level attributes or parameters for a given LPS, as defined in Sections 4.2.2 through 4.2.6.

R4-20 [72] The CCS node shall populate a special default link parameter set for HSLs containing the system default values of the SAAL parameters, MTP3 congestion thresholds, and (if supported per LPS) link marginal performance thresholds, to be used for HSLs in the absence of management input. The special default LPS shall NOT itself be management configurable, but shall be retrievable by management systems and/or personnel so that they may determine the default values in use.

CR4-21 [73] Via its local User System Interface and via interfaces to authorized management systems responsible for configuration management functions, the CCS node shall support all necessary configuration management data operations to configure, reconfigure, and retrieve any management-configurable parameters associated with each HSL’s DS1 interface, ATM-interface, and ATM VCL/VCC, per considerations presented in Sections 4.2.2 and 4.2.3.

4.2.8 Summary of HSL Configurable Parameters

Table 4-1 summarizes configuration management requirements and objectives for the various HSL parameters identified in the previous subsections. Each row corresponds to a configurable or potentially configurable parameter, including parameters that are to be management-configurable, and those that may be preset, automatically configured, or

4–23


GR-2878-CORE

assumed by the CCS node, if necessary, to support the HSL implementation. The columns convey relevant information about the CCS node’s configuration management support for these parameters, as follows:

• “Parameter Category/Parameter Name” conveys both the parameter category according to the aspect of the signaling protocol architecture supported, as described in the previous subsections, and the name of each individual parameter. Parameters are categorized into the following groups by protocol layer or other function:

— Common Link Parameters

— DS1 Interface Parameters

— ATM Interface Parameters

— ATM VCC/VCL Parameters

— SAAL Parameters

— MTP Level 3 Congestion Thresholds

— HSL Marginal Performance Thresholds.

• “Section Ref” refers to the section in this document in which the detailed configuration management requirements and objectives for the parameter are provided.

• “Configured Per” defines the basis (object cardinality) for which the particular parameter value is to be configured, including

— Link (per link)

— LPS (per Link Parameter Set within Link Class “SAAL”)

— DS1 port (per DS1 physical layer interface)

— ATM Infc (per ATM interface)

— VCL (per ATM Virtual Channel Link Termination).

Note that the designations “per DS1 interface,” “per ATM interface,” and “per VCL” are equivalent to “per link,” since each HSL shall be implemented as a single, dedicated ATM VCC/VCL terminating on a single, dedicated DS1-rate physical layer interface, as defined in this document. Those designations are used instead to denote that these parameters are more formally configurable on those bases. They are listed separately to promote forward compatibility with future possible HSL implementations involving higher link speeds and potentially multiple VCL terminations per ATM interface (transmission link). See also [Note 2] to Table 4-1.

• Management Configurable conveys whether or not the indicated parameters are to be management-configurable. i.e., administrable by management systems or operations personnel via operations interfaces:

4–24

ab


— (R) denotes that it is required that the parameter be management-configurable.

— (CR) denotes that it is a conditional requirement that the parameter be management-configurable, subject to the applicability of the parameter to the CCS node’s HSL implementation.

— (O) denotes that it is an objective that the parameter be management-configurable.

— NR: conveys that there are no requirements or objectives that this parameter be management configurable. Its value may be preset or otherwise automatically configured or assumed by default by the CCS node, as necessary, or it may be implemented as management-configurable, subject to the supplier’s implementation of the ATM layer for HSLs.

Where (R), (CR), or (O) are used, the corresponding object index (e.g., requirement number) is cross-referenced in the table.

• Input Reqmt. specifies whether input from a management system, user, or process is required for the specified parameter.

— M: denotes that management input is mandatory and no default value shall be applied or assumed.

— O: denotes that management input is optional and that a suitable default value shall be applied or assumed in the absence of management input.

— P: denotes that a preset or fixed node-configured value may be used for this parameter.

— N/A denotes that no management input may be applicable, i.e., for cases where the parameter is not implemented as management-configurable.

P, O, or N/A shall be used for parameters where Management Configurable = NR.

• Preset Value or Default Value conveys the recommended or required preset or fixed node-configured value to be used or assumed by the CCS node, or the recommended default value to be used (for optionally entered management-configurable parameters), respectively. The following abbreviations are used for the units or qualifying notes for the preset or default values:

cps cells per second

mcs microseconds

ms milliseconds

msg MTP3 messages

null conveys a special null argument configured to convey that the parameter shall not be applicable when used for HSLs

PDUs SSCOP Protocol Data Units

4–25


GR-2878-CORE

SD PDUs SSCOP Sequenced Data PDUs

sec seconds

STATs STAT PDUs.

N/A used within the Preset or Default Value column denotes that neither a preset nor default value is applicable to the indicated parameter either because management input is mandatory or because no generic configurable parameters have been identified.

I/D used within the Preset or Default Value column denotes that the preset or default value shall be implementation-dependent.

• Minimum Settable Range or Value Set conveys the minimum recommended or required configurable numeric range or the set of values that may be used for the parameter. Abbreviations/notation used are as follows:

cX alphanumeric character string of length c

kN numeric character string of length k

x-y numeric range between values x and y, inclusive.

Where a range is specified, units are the same as those specified for the default or preset value.

Examples: “8X + 2N” = 8 alphanumeric + 2 numeric characters

“10-100 ms” = 10 through 100 milliseconds.

N/A used within this column conveys that a range or value set is not applicable, either because the value must be fixed for HSLs, or because no generic configurable parameters have been identified.

I/D used within this column denotes that the minimum settable range or value set shall be implementation-dependent.

Notes (numbered in [brackets]) within table entries denote that additional clarifying information follows Table 4-1.

4–26

ab


r t

C

-

-

-

-

-

-

-

D

-

A

-

-

-

-

-

A

-

-

-

-

Table 4-1. Summary of HSL Configurable Parameters

Parameter Category

- Parameter Name

Section Ref.

Configured Per

Management.ConfigurableNR, (R), (CR)

InputRqmt

(M,O,P)

Preset or Default Value

MinimumSettableRange oValue Se

ommon Link Parameters:

Link ID: LSN-MN 4.2.1 Link (R) 4-4a M N/A 8X + 2N

Equipment Port Identifier (EPI) 4.2.1 Link (R) 4-4b M N/A I/D

Link Speed 4.2.1 Link (R) 4-4c M N/A N/A (=1536Kb/s)

Link Class 4.2.1 Link (R) 4-4d M N/A I/D{SAAL}

Link Parameter Set ID (LPSI) 4.2.1 Link (R) 4-4e M N/A I/D

Port Equipment Options 4.2.1 Link (CR) 4-6a [Note 1] O I/D I/D

Supplier-Specific Attribute(s) 4.2.1 Link (CR) 4-6b [Note 1] O I/D I/D

S1 1 Interface Parameters:

None Identified 4.2.2 DS1 Infc.

NR N/A N/A N/A

TM Interface Parameters:

Interface ID 4.2.3.1 ATM Infc.

NR P, O, or N/A

[Note 2] I/D

Maximum VPCs 4.2.3.1 ATM Infc.

NR P, O, or N/A

0 N/A

Maximum VCCs 4.2.3.1 ATM Infc.

NR P, O, or N/A

1 N/A

Allocated VPI Bits 4.2.3.1 ATM Infc.

NR P, O, or N/A

1 bit N/A

Allocated VCI Bits (N) 4.2.3.1 ATM Infc.

NR P, O, or N/A

I/D(minimum 3 bits)

N/A

TM VCC/VCL Parameters:

VCL Local Identifier 4.2.3.2 VCL NR P, O, or N/A

[Note 2] I/D

VPC Local Identifier (not applicable) 4.2.3.2 VCL NR P, O, or N/A

null I/D

VPI Value 4.2.3.2 VCL NR P, O, or N/A

0 N/A

VCI Value 4.2.3.2 VCL NR P, O, or N/A

5 5, 32-MM = 2N-1(or I/D)

4–27


GR-2878-CORE

-

-

- A

- A

- A

S

- 0

- 0

- 1

- 0

- 0

- (F

.0

- 0

- 0

- 5

- 0

- 0

- -0

- =S

0

- 4

- .0

- =

0

- =

0

- =

.0

- =

.0

r t

Peak Cell Rate (PCR) 4.2.3.2 VCL or LPS

NR P, O, or N/A

3622 cps N/A

Sustainable Cell Rate (SCR) 4.2.3.2 VCL or LPS

NR P, O, or N/A

3622 cps N/A

Burst Tolerance (BT) 4.2.3.2 VCL or LPS

NR P, O, or N/A

210 cells I/D or N/

Cell Delay Variation Tolerance (CDVT) 4.2.3.2 VCL or LPS

NR P, O, or N/A

100 mcs I/D or N/

QOS Class 4.2.3.2 VCL or LPS

NR P, O, or N/A

3 I/D or N/

AAL Parameters:

SSCOP: MaxCC/T1.637 4.2.4 LPS (R) 4-13, Table 3-1 O 4 PDUs 1-1

SSCOP: MaxPD/T1.637 4.2.4 LPS (R) 4-13, Table 3-1 O 500 PDUs 5-212

SSCOP: MaxSTAT/T1.637 4.2.4 LPS (R) 4-13, Table 3-1 O 67 PDUs 3-102

SSCOP: Timer_CC/T1.637 4.2.4 LPS (R) 4-13, Table 3-1 O 200 ms[Note 3]

100-200

SSCOP: Timer_KEEP-ALIVE/T1.637 4.2.4 LPS (R) 4-13, Table 3-1 O 100 ms 25-50

SSCOP: Timer_NO-RESPONSE/ T1.637 ailed SSCOP Connection)

4.2.4 LPS (R) 4-13, Table 3-1 O 1.5 sec

[Note 3]

0.2-2

SSCOP: Timer_POLL/T1.637 4.2.4 LPS (R) 4-13, Table 3-1 O 100 ms 25-50

SSCOP: Timer_IDLE/T1.637 4.2.4 LPS (R) 4-13, Table 3-1 O 100 ms 25-100

SSCF-NNI: AERM Timer_T1/T1.645 4.2.4 LPS (R) 4-13, Table 3-1 O 5 sec 1-1

SSCF-NNI: AERM Timer_T2/T1.645 4.2.4 LPS (R) 4-13, Table 3-1 O 120 sec 15-18

SSCF-NNI: AERM Timer_T3/T1.645 4.2.4 LPS (R) 4-13, Table 3-1 O 1000 mcs 276-2500

SSCF-NNI: n1/T1.645 4.2.4 LPS (R) 4-13, Table 3-1 O 60000 PDUs

50050000

SAAL LM: Max_NRP Maximum number of retransmitted SCOP PDUs permissible for link proving

4.2.4 LPS (R) 4-13, Table 3-1 O 1 attempt 0-1

SAAL LM: Timer_REPEAT-SREC 4.2.4 LPS (R) 4-13, Table 3-1 O 1 hour 0.5-2

SAAL LM: Timer_NO-CREDIT 4.2.4 LPS (R) 4-13, Table 3-1 O 1.5 sec 1.0 - 6

SAAL LM: ISERM: T_sup: Superblock Size

4.2.4 LPS (R) 4-13, Table 3-1 O 120 sec 10-60

SAAL LM: ISERM: T_loss STAT Loss Limit

4.2.4 LPS (R) 4-13, Table 3-1 O 1.3 sec 0.5-1

SAAL LM: ISERM: Alpha Exponential Smoothing Factor

4.2.4 LPS (R) 4-13, Table 3-1 O 0.1 0-1

SAAL LM: ISERM: thres QoS Threshold

4.2.4 LPS (R) 4-13, Table 3-1 O 0.244 0-1

Table 4-1. Summary of HSL Configurable Parameters (Continued)

Parameter Category

- Parameter Name

Section Ref.

Configured Per


InputRqmt

(M,O,P)



4–28

ab


- =

0

- In

5

- In

5

- 0

-

F

0

- E

2

- F

5

M 0

0

)

-

-

-

-

-

-

-

-

-

(c

r t

SAAL LM: ISERM: Timer_Tau Error Monitoring Interval

4.2.4 LPS (R) 4-13, Table 3-1 O 100 ms 25-25

SAAL LM: ISERM: N = Monitoring tervals Spanning 400 ms Error Event

4.2.4 LPS (R) 4-13, Table 3-1 O 9 intervals 1-2

SAAL LM: ISERM: N_blk = Monitoring tervals per Block

4.2.4 LPS (R) 4-13, Table 3-1 O 3 intervals 1-2

SAAL LM: Timer_FORCE_PROVING 4.2.4 LPS (R) 4-13, Table 3-1 O 10 minutes 0-2

SAAL Level 2 Flow Control: NR =

ixed Credit Increment

4.2.4 LPS (CR) 4-14 O 1200 PDUs or I/D

3-200

SAAL Level 2 Flow Control: RPDU = quivalent Fixed Credit Allocation Rate

4.2.4 LPS (CR) 4-14 O 3622PDUs/secor I/D

150-362

SAAL Level 2 Flow Control: bc = ixed Credit Allocation Frequency

4.2.4 LPS (CR) 4-14 O 3 STATsor I/D

1-

TP Level 3 Congestion Thresholds: msgs ormsg octets

(or I/D)[Note 4]

0 -507

0 - 14325

(or I/D

Level 1 Abatement 4.2.5 LPS (R) 4-16 O 780

19500

Level 1 Onset 4.2.5 LPS (R) 4-16 O 930

23250

Level 1 Discard 4.2.5 LPS (R) 4-16 O 2490

62250


66000


69750


108750


112500


116250


131250

ontinued next page)


Parameter Category

- Parameter Name

Section Ref.

Configured Per


InputRqmt

(M,O,P)



4–29


GR-2878-CORE

H

- 2

- R

0

- C

2

- C

2

r t

Notes for Table 4-1:

[Note 1]: Port Equipment Options and Supplier-Specific Attributes are implementation-dependent link-level parameters identified in GR-82-CORE[12] and GR-310-CORE[26] for STPs. They shall be supported as configurable link parameters only if applicable to the CCS node’s implementation of HSLs.

[Note 2]: The local identifiers for the ATM interface and ATM VCC/VCL shall not be separately configurable for HSLs, as there shall be a one-to-one relationship between the HSL, ATM interface, the ATM VCC/VCL, and the transmission link (DS1) interface, and there is no need to separately distinguish each for configuration management purposes. However, if necessary to support the ATM interface for the HSL implementation, the CCS node shall populate these parameters with the link’s Equipment Port Identifier (EPI), a mandatory input for the HSL, per requirements in Section 4.2.1. The supplier may wish to consider making these parameters separately configurable if higher link speeds are used in the future such that multiple links (each an ATM VCL) may terminate on the same physical interface, such that the one-to-one relationship would no longer apply.

[Note 3]: The indicated default values are assumed for terrestrial facilities (corresponding to relatively short propagation delays). For satellite facilities (corresponding to significantly longer propagation delays) see also Table 3-1 regarding the recommended provisional default settings for these parameters.

[Note 4]: The indicated congestion thresholds may be implemented in terms of MTP3 messages or MTP3 message octets, depending on the specifics of the congestion procedures and the HSL design. The suggested values are based on preliminary results of HSL simulation studies for STP-STP B or D links dominated by ISUP traffic. Larger values will likely be applicable to octet-implemented congestion thresholds for SCP-STP A-link HSLs, whose traffic will be comprised of TCAP messages with a larger average message size. The simulation studies and results are documented in

SL Marginal Performance Thresholds: [Note 5]

Number of Automatic Changeovers 4.2.6 LPS (O) 4-18, (O) 4-103 O 3 1-3

SSCOP SD PDUs Transmitted Requiring etransmission

4.2.6 LPS (O) 4-18, (O) 4-102 O 550or I/D

[Note 6]

10-1000

SSCOP Connection Sum-of-Errors ounter

4.2.6 LPS (O) 4-18, (O) 4-103 O 5 1-3

SSCOP Errored PDUs Sum-of-Errors ounter

4.2.6 LPS (O) 4-18, (O) 4-103 O 2 1-3


Parameter Category

- Parameter Name

Section Ref.

Configured Per


InputRqmt

(M,O,P)



4–30

ab


Appendix C of this GR. CCS node suppliers may wish to utilize implementation-specific values of these thresholds instead of the suggested provisional values as defaults, based on the anticipated traffic mix for their HSL NE customers.

[Note 5]: While these parameters are used for performance monitoring functions and are required to be user-settable on at least a per-node basis for all HSLs per R4-102 [153], it is an objective (O4-18 [210]) that they be settable via configuration management commands on a per-LPS basis, as defined in this section. The specified defaults and configurable ranges are recommendations only per considerations discussed in Appendix E (Considerations Regarding HSL Marginal Performance Thresholds).

[Note 6]: The specified recommended default and configurable range for SSCOP SD PDUs retransmitted, in particular, will be heavily dependent on the HSL’s engineered occupancy, which in turn is dependent upon the HSL implementation’s supported throughput per HSL. It is also sensitive to assumptions regarding the nominal error rates expected on the link facility. (See also Appendix E, Section E.2.) Therefore, HSL NE suppliers may wish to utilize implementation-specific values instead of the recommended provisional values as defaults.

4.3 In-band Operations Flows

To support the Fault Management and Performance Management functions required below for each HSL link termination, the CCS node must support the following exchanges of operations messages and data with its peers at the physical and ATM layers in the signaling protocol architecture, consistent with ATM NE generic requirements for ATM terminations, as specified in Section 4 of GR-1248-CORE.[25] Requirements or objectives regarding the use of these capabilities in Fault Management and Performance Management, respectively, are addressed in the indicated subsections within Sections 4.4 and 4.5.

4.3.1 Physical Layer Operations Flows: DS1-Level

As shall be the case for ATM NEs (addressed in GR-1248-CORE),[25] DS1-rate facility terminations supporting ATM at the CCS nodes shall use the Extended Superframe (ESF) Format. Bit-oriented operations information will be communicated between the entities terminating the DS1 connection via a 4-Kb/s data channel, and a 2-Kb/s Cyclic Redundancy Check (CRC) channel, built into the DS1 frames. Each ESF frame, which is comprised of 24 individual DS1 frames, makes these overhead embedded communications channels available by efficiently using the DS1 framing bits in each 24-frame “superframe”. Specifically, 18 of the 24 DS1 framing bits in each ESF are used for bit-oriented operations communication at the physical layer: 6 for error correction (CRC-6) and 12 for the 4-Kb/s data link channel. The 4-Kb/s data link channel is used to report far-end performance monitoring results, to activate and deactivate a line-level loopback

4–31


GR-2878-CORE

capability, and to notify downstream network transport elements about faults that have occurred in upstream facility spans (e.g., a yellow alarm indication). The communication of an Alarm Indication Signal (AIS) to the far end is handled by the node inserting all ones in the DS1 payload and thus does not need to be communicated by the data link channel itself. The following requirement applies regarding the support of these functions.

R4-22 [74] At each HSL’s DS1 termination, the CCS node shall support the use of the ESF embedded 2-Kb/s CRC channel and the 4-Kb/s data link channel as set forth in GR-499-CORE,[4] Section 10.2.4 (Multiframe Arrangements: Extended Superframe), consistent with GR-1248-CORE,[25] Section 4.1.1, Requirement [12].

Requirements for the use of these capabilities in management-initiated link testing functions are presented separately in Section 4.4.4.1 (Physical-Level Testing: DS1 ESF Loopbacks). Requirements for their use in management-initiated DS1 performance monitoring are presented separately in Section 4.5.3.3 (DS1 Level: Scheduling of DS1 Performance Reports).

4.3.2 ATM-Layer Operations Flows

The ATM-layer, similar to physical-layer, is defined in ATM standards and in the ATM NE generic operations requirements of GR-1248-CORE.[25] The relevant operations information to be addressed include data such as fault indications, performance monitoring data, and cell-level loopback test requests. Such data may be exchanged through the use of ATM Operations and Maintenance (OAM) cells as described in GR-1248-CORE,[25] Section 4.2. However, only a subset of the ATM-layer flows defined for ATM NEs shall be required at the CCS nodes terminating the ATM VCCs supporting the HSLs. This is because these HSL requirements assume only a “direct,” dedicated, i.e., single-VCL VCC, shall be implemented between the two CCS nodes rather then a segmented multi-VCL VCC supported by one or more intermediate ATM NEs. This simplifies the operations functions by obviating the need for ATM segment-level OAM flows and associated fault and performance management functions, such as those supporting fault sectionalization to a particular intermediate ATM NE. Specifically, the CCS node shall support a subset of the defined ATM F5 operations flows providing ATM-cell loopback and performance monitoring functions for the underlying ATM VCC of each HSL.

R4-23 [75] The CCS node shall support the generation and processing of the OAM cell type for the OAM Cell Loopback capability for Fault Management, per requirements defined in GR-1248-CORE,[25] Section 4.2.2 (Common OAM Cell Payload Structure), Table 4.1.

O4-24 [76] It is an objective that the CCS node support the generation and processing of the following standard OAM cell types for Performance

4–32

ab


Management, per requirements defined in GR-1248-CORE,[25] Section 4.2.2 (Common OAM Cell Payload Structure), Table 4.1, including

… a. Forward Monitoring

… b. Backward Reporting.

CR4-25 [77] Each HSL termination at the CCS node shall support the applicable ATM F5 (VC-level) operations flows supporting the previous functions, utilizing connection OAM cells (i.e., PTI = 5), and acting as the connection end point, for the VCC comprising the HSL, per GR-1248-CORE,[25] Section 4.2.1 B.

CR4-26 [78] For each HSL, the CCS node shall terminate and process all applicable (supported) incoming connection ATM OAM cells (i.e., cells with PTI= 5 of the supported cell types) it receives as a VCC connection endpoint.

F4 operations flows (i.e., PTI=4, for Virtual Path [VP] connections) need not be supported at CCS nodes for HSLs, as HSLs shall not utilize ATM VP service.

CR4-27 [79] The CCS node shall be capable of generating and inserting the applicable “connection” OAM cells into the outgoing cell stream of the configured VCC comprising each HSL.

Additional operations requirements addressing the use of OAM Cell Loopback capabilities for HSL fault management are presented in Section 4.4.4.2 (ATM-Layer OAM Loopback Tests). Objectives addressing OAM-cell based performance monitoring are presented in Section 4.5.3.2 (ATM-Level: Use of F5 Performance Monitoring OAM Cells).

Beyond the OAM cell types and functions, ATM NEs are also required to support OAM cell generation and processing for the following additional fault management functions according to requirements in GR-1248-CORE:[25]

— Alarm Indication Signal (AIS)

— Remote Defect Indicator (RDI)

— Continuity Check.

The AIS and RDI operations flows are used by an ATM NE to send downstream and upstream failure notifications, respectively, to other ATM NEs supporting a VCC and its end-point(s). They are needed for segment-level fault sectionalization to a given ATM NE when an ATM VCC is comprised of multiple VCLs. These functions shall not be applicable to the direct single-VCL VCCs used for HSLs as defined in this document. Therefore, these functions shall not be required at this time at CCS nodes terminating HSLs. They may be required in the future if multi-VCL VCCs, utilizing one or more intermediate ATM NEs

4–33


GR-2878-CORE

rather than a direct point-to-point connection, are used to support ATM-based HSLs between CCS nodes.

The Continuity Check function involves the exchange of ATM OAM “heartbeat” cells between ATM-level peer entities at each end of a VCC, at fixed intervals, to support the detection of a loss of continuity at that layer, independent of the availability of the physical path (in this case DS1). Because this function is redundant with much of the connection-monitoring functions provided by the SAAL at level 2, and the DS1 failure detection capabilities defined for level 1, the Continuity Check OAM cells and functions shall not be required at this time for CCS nodes terminating HSLs.

O4-28 [80] It is an objective that the CCS node additionally support the generation and processing of the standard OAM cell types and function types for Activation/Deactivation of Performance Monitoring per requirements defined in GR-1248-CORE,[25] Section 4.2.2 (Common OAM Cell Payload Structure), Table 4.1.

The activation/deactivation function for ATM VCC performance monitoring may be supported either through management system commands at the operations interfaces to the CCS nodes at each end of the VCC, via OAM cells from the network node at either end of the connection, or both ends. It is an objective that they be supported via OAM cells so that they may be initiated remotely from either end, even when each end is managed by a different network administration, e.g., when the CCS node at each end of the link is administered by a different carrier. A similar Activation/Deactivation flow is also defined for the Continuity Check function at ATM NEs. However, it shall not be required because the Continuity Check function itself is currently not required at CCS nodes.

R4-29 [81] The CCS node shall terminate and discard, without disrupting the HSL’s ATM VCC, any received connection and path OAM cells for OAM functions it does not support.

4.4 Fault Management (Maintenance)

Fault Management (traditionally a component of the Network Maintenance domain) refers to those functions by which management systems and personnel detect, verify, sectionalize, isolate, and repair troubles in network equipment or network software, so as to maintain and assure the quality of service provided to customers. As supported by network nodes these activities involve the use of surveillance (alarm/event reporting and logging) and testing functions. For HSLs, incremental requirements for these functions are presented in the indicated subsections for the following aspects of link surveillance and testing:

• Link Event Notification Functions (4.4.1)

• Link Status Logging (4.4.2)

4–34

ab


• Lower-Layer Fault-Management Surveillance (4.4.3)

• Link Testing Functions (4.4.4)

• Link Control Functions (Removal From Service) (4.4.5).

4.4.1 Link Event Notification Functions

Link event notification refers to capabilities concerning the real-time reporting, over operations interfaces, of alarms and other events of interest to operations personnel responsible for fault management functions. Specifically in this case, the events of interest shall concern HSL outages, sustained failures, link restorations, minor link state changes during outages, and (for STPs only) attempts to route MTP3 messages exceeding the 272-octet limit to a non-SAAL link. General requirements regarding the detection and reporting of these events are presented in the first two subsections:

• Link Outage-Related Event Detection and Reporting (4.4.1.1)

• Common Requirements for Link Event Reports (4.4.1.2).

The subsections that follow present detailed requirements for the detection criteria for each event and the contents of the respective event notifications, including

• Link Outage Event Report (4.4.1.3)

• Link Available Event Report (4.4.1.4)

• Sustained Link Failure/Craft Referral Event Report (4.4.1.5)

• Unavailable-Link Minor State Change Event Report (4.4.1.6)

• Oversized Message Routing Attempt on an MTP2 Signaling Link (4.4.1.7).

4.4.1.1 Link Outage-Related Event Detection and Reporting

The CCS node shall be required to report all events resulting in the transition of a HSL between the available and unavailable states (in either direction) as perceived by MTP level 3 for user part message traffic as well as several additional related event indications. The following subsections convey definitions and general requirements and objectives for these event notifications and their transmittal over applicable operations interfaces.

4.4.1.1.1 General Requirements

R4-30 [82] For HSLs, the CCS node shall support the following four on-occurrence event reports concerning link outages and their recovery:

4–35


GR-2878-CORE

… 1. Link Outage

… The event that an available link becomes unavailable to SS7 user-part message traffic as perceived by MTP level 3, due to failure, processor outage, inhibiting, or removal from service.

… 2. Link Available

… The event that an unavailable link becomes available to SS7 user-part message traffic as perceived by MTP level 3, due to link restoration, activation, or uninhibiting.

… 3. Sustained Link Failure - Craft Referral Timer Expiration

… The event that a failed link has not been restored for a duration exceeding the MTP level 3 failed link craft referral timer (Timer T19/T1.111.4).

… 4. Unavailable-Link Minor State Change

… The event that a link already unavailable to SS7 user-part message traffic as perceived by MTP level 3, due to failure, processor outage, inhibiting, and/or removal from service has undergone a minor state change, such as inhibiting or uninhibiting at MTP level 3, or failure, restoration, or activation of the link at level 2 (i.e., at the SAAL for HSLs), but remains unavailable due to the persistence of one or more such link outage conditions.

4.4.1.1.2 Differences Relative to Prior Link Outage Reporting Requirements for MTP2 Links

The notifications for HSLs shall replace prior link outage reporting requirements for 56-Kb/s MTP2-based signaling links as defined in GR-82-CORE,[12] the STP GR8.

One obvious difference between these and those earlier requirements is that the set of causes or reasons for link outage shall be different for the SAAL-based links due to differences in the level 2 procedures, signals, and PDUs.

Another significant difference is that those earlier requirements include separate alarm surveillance messages for the occurrence of several distinct events that result in link outage when the link was previously in the available state, including

• failure

• remote processor outage

8. Operations generic requirements for the other CCS node types, in GR-606-CORE,[13] for CCS-capable SPCSs, and GR-1241-CORE[14] for the SCP node, currently do not include specific link outage event reporting requirements at the level of detail provided in GR-82-CORE[12] for the STP.

4–36

ab


• manually caused link unavailability at the near end

all as detected at the reporting node.

The event definitions conveyed in those prior requirements left certain aspects of event detection and reporting open to supplier interpretation. The event definitions did not necessarily cover all detectable causes of link outage (e.g., local processor outage and remote management inhibit conditions were not explicitly included). Also, there were conflicting interpretations as to whether link failures should be reported immediately when the link first transitions into the unavailable state (as may be needed by certain OS applications monitoring real-time network status), upon a subsequent alignment or proving failure, or significantly later upon expiration of Timer T19/T1.111.4 after repeated failed alignment and proving attempts (as may be needed for local craft notification or repair/dispatch activity). (Timer T19’s provisional value is 8 minutes, according to current standards - a long interval compared to link restoration times.) Some implementations also delayed the generation of failure notifications until after diagnostic routines had been run on the link terminal. In some cases, link set outage and node isolation indications, when caused as a result of the link outage, were generated before the corresponding link failure indications due to the previously stated delays, resulting in user confusion. The recovery message definitions also did not explicitly take into consideration that MTP-2 based links recovering from certain conditions like processor outage may yet remain unavailable to user-part message traffic due to subsequent events occurring after the initial event that resulted in the original link outage, e.g., because of a link failure at MTP-level 2 or because the link was later inhibited at MTP level 3. Differing supplier interpretations had caused certain OS surveillance applications to miss some link outage and recovery boundary conditions for some CCS node implementations.

To remedy these requirements shortcomings and ensure that all link outage and recovery transitions are reported for HSLs, the set of four messages (Link Outage, Link Available, Sustained Link Failure, and Unavailable Link Minor State Change) shall replace those previously defined for MTP2 link outages.

• The Link Outage notification shall be required to convey any MTP-level-3-perceived link outage, i.e., any transition out of the available state to one where the link is unavailable to SS7 user part message traffic, including those attributed to link failure, processor outage (local or remote) (which for HSLs shall be considered a link failure case under the SAAL [level 2] protocol, rather than link blocking under the MTP2 protocol), and management inhibiting (local or remote). A link outage cause indicator shall convey the specific reason discerned by the reporting CCS node for the link outage occurrence, based on events monitored at MTP level 3, SAAL Layer Management (LM), and, where applicable, the physical layer (DS1), at the time of the outage.

• Link Available covers transitions back to the available state, regardless of whether or not the link has been unavailable for multiple reasons since it first experienced the link outage.

4–37


GR-2878-CORE

• The Sustained Link Failure notification shall be separately used to support “craft referral” (i.e., exception-based investigation and dispatch functions) upon expiration of the T19 timer.

• The Unavailable Link Minor State Change notification shall be used to report events in which a link was already unavailable but, rather than becoming available, experiences a subsequent event that changes or augments the reason it remains unavailable to MTP level 3 user part message traffic. Parameters within the event report shall convey the specific minor state change.

— For example, after a link is first inhibited (reported as a Link Outage), it is then removed from service at the link layer (for HSLs, the SAAL) due to management action. The subsequent removal from service shall be reported as an Unavailable Link Minor State Change.

— In another example, a link fails (reported as a Link Outage), but while attempting to automatically realign and prove in, is marked inhibited at MTP level 3. It then recovers its SSCOP connection and undergoes successful proving, but remains unavailable due to its inhibited status. The MTP3 inhibit event, and the successful proving attempt restoring it to service at the SAAL, would each be reported as an Unavailable Link Minor State Change because, in each instance, the link is not yet available to MTP user part message traffic.

Detailed requirements for the CCS node’s generation of these event reports and their data content are addressed separately in Sections 4.4.1.3 through 4.4.1.6.

While the requirements presented in this document apply strictly only to HSLs, a common treatment for link outage event reporting for both HSLs and MTP2-based 56-Kb/s links, when implemented within the same CCS node, and across CCS nodes, is strongly desired. Therefore, the event reporting criteria and content requirements for the event notifications are written inclusively to apply to both HSLs and MTP2-based links, and may be applied to all CCS node types supporting HSLs. The HSL-specific event criteria and output parameter arguments are identified along with equivalent or analogous criteria also cited for MTP2-based links.

O4-31 [83] It is an objective that CCS nodes supporting both MTP-based 56-Kb/s signaling links and the ATM-based HSLs defined in this document support the same set of “common” link outage event notifications, as defined in Requirement R4-30 [82], for both classes of signaling links.

The preceding is stated as an objective, rather than a requirement, to allow for cost or other implementation considerations regarding revisions to existing event reporting capabilities for the 56-Kb/s MTP2 links.

It is the intention of Telcordia to also revise existing operations generic requirements in GR-82-CORE,[12] GR-606-CORE,[13] and GR-1241-CORE,[14] so that the event report message definitions for link outage and recovery are consistent for both HSLs and existing

4–38

ab


56-Kb/s MTP2-based signaling links at all node types and cover both link classes. For STPs, this proposed change is documented as Issue # 110 (Proposed Changes to Link Outage Event Reporting) in GR-82-ILR,[29] Signaling Transfer Point (STP) Generic Requirements Issues List Report.

4.4.1.2 Common Requirements for Link Event Reports

The following common requirements apply to the generation of event notifications concerning signaling links at CCS nodes supporting HSLs.

4.4.1.2.1 Common Parameters

Event reports for signaling links as described in Requirement R4-30 [82] shall contain certain required common data parameters.

R4-32 [84] The CCS node supporting HSLs shall provide the following common information in all HSL event reports:

… 1. Event ID

… The specific trouble condition or event being reported for the link.

… 2. The identity of the reporting CCS node detecting the event, in terms of both:

… a. Its COMMON LANGUAGE® CLLI™ code

… b. Its self-identity signaling point code (SPC).

… 3. The detect time of the event, including

… a. The calendar date (month, day, and year)

… b. The time of day (hour, minute, second, and decimal fraction of one second)

… c. Time zone assigned to the reporting node.

… 4. The report time of the event, i.e., the time at which the event report is generated and queued for output at the applicable operations interface, in the same format.

… 5. Event Severity

… The priority-of-action indication for the reported event condition, conveying (one of)

… a. Critical alarm

4–39


GR-2878-CORE

… b. Major alarm

… c. Minor alarm

… d. Action may be required

… e. Recovery

… f. Information only.

… 6. Sequence Number

… A unique ordered number associated with each event notification used to determine when messages from a particular CCS node are missing.

… 7. Link Identifier(s)

… The identify of the link experiencing the event, in terms of:

… a. Its unique Link ID (i.e., Link Set Name and Member Number [SLC])

… b. Its locally unique Equipment Port Identifier.

… 8. Additional relevant link attributes, including

… a. Link speed (56 or 1536-Kb/s [the latter for HSLs])

… b. Link class (MTP2 or SAAL [the latter for HSLs])

… c. Link type (i.e., from the link set type) {A, B, C, D, E, F}

… d. The link’s Far-End (FE) CLLI code

… e. The link’s FE PC.

Additional, event-specific parameters shall convey additional information about each event occurrence.

O4-33 [85] It is an objective that the CCS node supporting HSLs provide the same common information in its event reports for its MTP2-based 56-Kb/s links as it shall provide for SAAL-based HSLs as defined in R4-32 [84].

4.4.1.2.2 Management System Notification and CCS Node Logging

R4-34 [86] The CCS node shall transmit the indicated link event notifications over the following operations interfaces:

… a. the CCS node’s Maintenance OS interface (i.e., the “maintenance channel”)

… b. the CCS node’s local User System Interface (USI)

4–40

ab


… subject to any filtering or thresholding at the CCS node for those messages as may be defined for the CCS node implementation of those interfaces.

CR4-35 [87] For STPs and SCP nodes supporting the so-called “administrative channel” interface to LEC OS applications emulating the former SEASTM system interfaces defined in GR-310-CORE[26] (for STPs) and TA-NWT-000365,[30] SCP Node/SEAS, SCP Node/SMS Generic Interface Specification (for SCP nodes), per individual client-company requirements, the specified link event notifications shall be transmitted over those interfaces as well.9

Also see Section 5 for additional requirements regarding operations interface support for HSLs at CCS nodes.

R4-36 [88] The CCS node shall additionally record each link event report in its local maintenance log, for later access by authorized personnel at the USI and maintenance OS interfaces.

O4-37 [89] For those events concerning link outage and recovery, it is an objective that each link event notification be generated no later than 2.5 seconds after the event occurrence.

O4-38 [90] It is an objective that the time-stamp included in each link event report and log record support a minimum precision of 1 millisecond (ms).

4.4.1.3 Link Outage Event Report

The Link Outage event report shall convey the transition of a signaling link from the available state to the unavailable state as perceived by MTP level 3 for any reason. This message is intended to replace the previously defined notifications for Link Failure, Remote Processor Outage, and Link Near-End Manually Made Unavailable events as defined in GR-82-CORE,[12] Section 6.6.2 for the STP, and covers those and all other detectable outage causes for both HSLs and 56-Kb/s MTP2 links at all CCS node types.

R4-39 [91] The CCS node supporting HSLs shall report immediately upon its occurrence, the event that a HSL has become unavailable to SS7 user part message traffic, as perceived by MTP level 3, for any reason, including link failure, deactivation, inhibiting, or manual removal from service. This event shall be reported as a “Link Outage.”

9. The applicable syntax for the indicated event messages have yet to be defined within those interface specifications.

4–41


GR-2878-CORE

O4-40 [92] It is an objective that the CCS node supporting HSLs report immediately, upon its occurrence, the event that an MTP2 56-Kb/s signaling link has become unavailable to SS7 user part message traffic, as perceived by MTP level 3, for any reason, including link failure, deactivation, blocking due to processor outage, inhibiting, or manual removal from service. This event should be reported as a “Link Outage” in a manner consistent with the same notification provided for HSLs with identical output parameters describing the details of the link outage event.

The objective O4-40 [92] may be made a requirement in the future. Information requirements for the generated link outage event reports are provided in Requirement R4-41 [93] and cover link outage events for both the HSL and MTP2 link classes.

R4-41 [93] Each generated Link Outage notification shall contain the following information:

… 1. All common information defined under Requirement R4-32 [84], including, specifically for this event:

… a. An event indicator conveying link outage (e.g., REPT-LKOTG)

… b. The event severity indication for a “minor alarm”.

… 2. Link Outage Cause Indicator

… The reason the link transitioned to the unavailable state as determined by CCS node system management, based on event information logged at MTP level 3, the link layer (for HSLs: SAAL Layer Management [LM], for MTP2 links: MTP level 2 procedures), and/or the physical layer transmission link interface. One of the following outage causes shall be conveyed based on the indicated event detected for the link. (Bracketed text in italics notes common aspects, similarities, and differences in the cited link outage cause detection criteria between the HSLs addressed in this document and conventional MTP2-based signaling links.)

… a. Failure: Excessive Duration of Far-End Receiving Congestion

… For a HSL, a No Credit condition, detected by SAAL LM via the receipt of a MAA-ERROR “no credit” indication conveyed from the HSL’s local SSCOP process, has persisted until the SAAL’s LM Timer_NO-CREDIT has expired, resulting in the link being declared failed due to an excessive duration of far-end receiving congestion. LM has issued a MAAL-RELEASE request to the SSCF to remove the link from service.

4–42

ab


… For an MTP2 link, an excessive duration of receipt of Status Indication Busy (SIB) LSSUs has been declared as a result of the expiration of timer T1.111.3/T6.

… (While this outage cause is common to both HSLs and 56-Kb/s MTP2-based links, the detection criteria differ for each due to differences in level-2 procedures and PDUs.)

… b. Failure: Excessive In-Service Error Rate

… For a HSL, LM’s In-Service Error-Rate Monitor (ISERM) has removed the link from service due to a detected excessive error rate, indicated by the number of retransmitted SSCOP SD PDUs. As a result, local LM has issued a MAAL-RELEASE request to the local SSCF to remove the link from service.

… For an MTP2 link, the MTP2 Signaling Error Rate Monitor has removed the link from service based on excessive SUs received in error.


… c. Failure: Excessive Delay of Acknowledgment

… For a HSL, the local SSCOP process has not received at least one Solicited Status Response (STAT PDU) for its transmitted Status Request (POLL PDU) message(s) during an interval exceeding the SSCOP Timer_NO-RESPONSE, i.e., that timer has expired, and the SSCOP connection has been released. This condition is conveyed to the HSL’s local LM process by local SSCOP via a MAA-ERROR indication with code “P” (Timer_NO-RESPONSE Expiry).

… For an MTP2 link, the remote end has not acknowledged a transmitted MSU and Timer T1.111.3/T7 has expired.


… d. Failure: MTP3 Changeover Order (COO) Message Received

… The CCS node has received an MTP level 3 network management (MTP-NM) Changeover Order (COO) message from the CCS node at the far-end of the link, has declared the link failed, and has diverted message traffic to other available links. (This outage

4–43


GR-2878-CORE

cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… e. Failure: Request Received from Maintenance or Management System

… The CCS node’s system management function has received an external request from an authorized management system, maintenance system, or the local user-system interface to declare the link failed at the near-end. While forced into failure, it is assumed that the link has not been removed from service, i.e., it shall not be prevented from being restored by automatic procedures at level 2 (additional outage causes follow concerning manual removal from service). (This outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… f. Failure (HSLs Only)/ Blocking (MTP2 Links only): Local Processor Outage (Spontaneous)

… A local processor outage condition has spontaneously occurred, which has prevented MTP level 3 functions from accepting incoming MTP3 messages and submitting outgoing MTP3 messages to and from level 2, precluding the use of the link.

… For a HSL, the link has been declared failed. LM must be capable of detecting this condition through implementation-dependent interactions with system management. It is detected when local LM notifies the local SSCF function via a MAAL_LOCAL_PROCESSOR_OUTAGE.request indication, which causes the SSCOP connection to be released. The CCS node at the far end of the HSL is informed via the transmittal by the reporting CCS node of an SSCOP END (Disconnect) PDU with “processor outage” conveyed in its SSCOP UU data fields.

… For an MTP2 link, level 2 has commenced transmission of Status Indication Processor Outage (SIPO) LSSUs on the link to inform the far-end of the processor outage condition. The link is regarded as blocked rather than failed.

… (Local processor outage shall be a link outage cause common to both HSLs and MTP2-based 56-Kb/s links. However, the detection criteria differ due to the cited differences in level 2 PDUs and procedures.)

… g. Failure (HSL Only) /Blocking (MTP2 Links Only): Local Processor Outage (Management Initiated)

4–44

ab


… A local processor outage condition has been forced for the link as a result of management action, which has prevented MTP level 3 functions from accepting incoming MTP3 messages and submitting outgoing MTP3 messages to and from level 2. Detection and level 2 processing (at the SAAL for HSLs, or MTP2) are as defined for the spontaneous processor outage case. However, only the system management function at the CCS node at which the processor outage condition is induced can distinguish this condition from a spontaneous processor outage event. The far-end CCS node cannot distinguish this event from an ordinary (spontaneous) remote processor outage.

… (Induced local processor outage shall be a potential link outage cause common to both HSLs and MTP2-based 56-Kb/s links. However, its application was originally defined for MTP2 links only, where links may be considered blocked rather than failed. It may not be supported by all CCS node implementations. The detection criteria defined differs for HSLs and MTP2 links due to the cited differences in level 2 PDUs and procedures.)

… h. Failure: SSCF Remote Release (HSL Only) /Blocking (MTP2 Links Only): Remote Processor Outage

… The CCS node has detected remote processor outage for the signaling link.

… For a HSL, the CCS node’s local SSCOP process for that HSL has received an SSCOP END (Disconnect Command) PDU from the far end with the SSCOP-UU data field conveying “Processor Outage (PO)” and has released the signaling connection. Local SSCOP at the reporting CCS node will inform the local SSCF via an AA-RELEASE.indication signal. The local SSCF in turn notifies local LM via a MAAL-REPORT.indication, conveying SSCF Remote Release (RR) due to remote processor outage. The link is regarded as failed and must undergo subsequent realignment and proving prior to restoration.

… For an MTP2 link, the CCS node has received Status Indication Processor Outage (SIPO) LSSUs from the far-end and regards the link as blocked (rather than failed). Traffic may be resumed immediately upon termination of receipt of SIPO LSSUs.

… (Remote processor outage shall be a link outage cause common to both HSLs and MTP2-based 56-Kb/s links. However, the detection criteria defined here differs for each link class due to the cited differences in level 2 PDUs and procedures.)

4–45


GR-2878-CORE

… i. Failure: SSCF Remote Release: Out-of-Service (HSLs Only)

… For a HSL, the CCS node’s local SSCOP process for that HSL has received an SSCOP END (Disconnect Command) PDU from the far end with the SSCOP-UU data field conveying “Out of Service (OOS)” and has released the signaling connection. Local SSCOP at the reporting CCS node will inform the local SSCF via an AA-RELEASE.indication signal. The local SSCF in turn notifies local LM via a MAAL-REPORT.indication, conveying SSCF Remote Release (RR) due to the remote out-of-service condition. The link is regarded as failed. (This is the SAAL analog of the following MTP2 link outage condition.)

… j. Failure: Remote Level 2 Outage or Realignment (MTP2 Links Only)

… For an MTP2 link, level 2 has received consecutive Status Indication Out-of-Service (SIOS), Status Indication Out-of Alignment (SIO), Status Indication Normal Alignment (SIN), or Status Indication Emergency Alignment (SIE) LSSUs. The link is regarded as failed. (This is the MTP2 analog of the preceding SAAL link outage condition.)

… k. Failure: SSCF Remote Release - Protocol Error (HSLs Only)

… For a HSL, the CCS node’s SSCOP process for the HSL has received an SSCOP END (Disconnect Command) PDU from the far end with the SSCOP-UU data field conveying “Protocol Error (PE)" and has released the signaling connection. Local SSCOP at the reporting CCS node will inform the local SSCF via an AA-RELEASE.indication signal. The local SSCF in turn notifies LM via a MAAL-REPORT indication, conveying SSCF Remote Release (RR) due to the remotely detected protocol error condition. One example of such a protocol error condition is an error in SD PDU sequence numbering, although other SAAL protocol errors shall also apply. (This outage condition is specific to HSLs. It has no direct MTP2 analog. However, the cited protocol error example regarding PDU sequence number errors corresponds to an MTP2 SU sequence number error generally detected and reported at the near-end (receiver) instead as “Abnormal Forward Indicator Bit Received/Backward Sequence Number Received (FIBR/BSNR),” as cited in the next outage cause.)

… l. Failure: Abnormal FIBR/BSNR (MTP2 Links Only)

4–46

ab


… For an MTP2 link, an SU sequencing error has been detected: Abnormal Forward Indicator Bit Received/Backward Sequence Number Received, and the link is declared failed. (This event is the MTP2 analog of the sequence number error example cited for the preceding SAAL error condition.)

… m. Failure: SSCF Remote Release - Management Initiated (HSLs Only)

… The CCS node’s local SSCOP process for the HSL has received an SSCOP END (Disconnect Command) PDU from the far end with the SSCOP-UU data field conveying “Management Initiated (MI)" and has released the signaling connection. Local SSCOP at the reporting CCS node will inform the local SSCF via an AA-RELEASE.indication signal. The local SSCF in turn notifies local LM via a MAAL-REPORT.indication, conveying SSCF Remote Release (RR) due to the management-initiated remote release condition. (This outage condition is specific to HSLs. It has no direct MTP2 analog.)

… n. Failure: Hardware Problems (Implementation-Dependent)

… The local (near-end) link terminal or level-2 processor has failed due to a hardware error or fault condition, resulting in link failure. Detection shall be implementation dependent. (This outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… o. Failure: Software Problems (Implementation-Dependent)

… The local (near-end) link terminal or level-2 processor has failed due to a software or program error condition, resulting in link failure. Detection shall be implementation dependent. (This outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… p. Failure: Failed Periodic Signaling Link Test (SLT)

… The link has been removed from service because it failed a periodic in-service MTP3 Signaling Link Test (SLT). The reporting CCS node sent a Signaling Link Test Message (SLTM) to the far-end CCS node and did not receive a valid Signaling Link Test Acknowledgment (SLTA) message with the OPC equal to the link’s configured far-end (FE) PC. (The periodic SLT and the removal action upon its failure may not apply to all implementations or may not be active at all nodes or for all links. (This outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

4–47


GR-2878-CORE

… q. Failure: Facility Outage

… The link failed because of a sustained facility (transmission link) outage detected at the level-1 interface. This condition may not be discernible by all CCS node implementations.

… For HSLs, such an outage would be detected via a DS1 Loss of Signal (LOS), Loss of Frame (LOF), or Loss of Cell Delineation (LCD) failure condition10. This assumes that system management shall or may be capable of detecting the facility outage as the underlying cause of link failure, even though the failure would otherwise be indirectly detected and reported by SAAL functions.

… For MTP2 links, this outage cause would correspond to a transmission link outage at the DS0 (or potentially other-rate) interface.

… (This outage cause shall generally be common to both HSLs and MTP2-based links. However, its detection criteria may differ according to the type of transmission link interface.)

… r. Failure: Unresolved

… The link has failed, but the failure mode precludes CCS node system management from determining the failure cause. (This general outage cause shall be common to both HSLs and MTP2-based links. It shall be implementation-dependent.)

… s. Failure: Other/Implementation-Specific

… The link has failed due to some other failure condition specific to the particular CCS node implementation. Additional diagnostic information shall be provided to clarify or specify the particular failure condition. (This general outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… t. Management-Inhibit: Local (Near-End)

… The link has been made unavailable to user part message traffic because it has been management-inhibited at the reporting CCS node. (This outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… u. Management-Inhibit: Remote (Far-End)

10. The DS1 LOS, LOF, and LCD failure conditions shall also be detected and reported separately and independently of the higher-level of HSL outage, as defined in Section 4.4.3.2: Physical Layer Defect and Failure Detection and Reporting (DS1).

4–48

ab


… The link has been made unavailable to user part message traffic because it has been management-inhibited at the far-end CCS node. (This outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… v. Manually Removed from Service (Maintenance)

… The link has been manually removed from service at the near-end by a mechanism other than the management-inhibit procedure and has been forced to remain in the unavailable state due to management action initiated via operations interfaces by personnel or management systems responsible for network maintenance or fault management. (This outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… w. Manually Removed from Service (Configuration Management/Memory Administration)

… The link has been manually removed from service at the near end by a mechanism other than the management-inhibit procedure and has been forced to remain in the unavailable state due to management action initiated at operations interfaces by personnel or management systems responsible for memory administration or configuration management. (This outage cause and its detection criteria shall be common to both HSLs and MTP2-based links.)

… 3. Link Oscillation Filter Indicator11

… For link failure cases only, an indicator shall convey whether link restoration attempts shall be delayed due to the MTP Level-3 Link Oscillation Filter, as defined in GR-82-CORE,[12] Section 4.2.4.10, and if so, which of the two allowed standard procedures has been invoked in terms of the delay timer employed. One of the following arguments shall be conveyed:

… a. Link Oscillation Timer - Procedure A (T1.111.4/T32)

… b. Suspension Timer for Link Oscillation - Procedure B (T1.111.4/T34)

11. The use of the MTP3 Link Oscillation Filter (MTP3 LOF) is not recommended for HSLs because the expected normal proving interval for HSL restoration shall likely be greater than either value of the link oscillation timers T32 or T34, whose current provisional values are set at 60 seconds. Therefore, it is possible that closely spaced recoveries sufficient to trigger the LOF may never occur for HSLs, and/or that the LOF will not be implemented for HSLs. [See also Section 3.3.2.6 (Use of the MTP3 Link Oscillation Filter for HSLs at STPs)]. However, this parameter shall be retained in the event report to accommodate MTP2 links and the possibility that the LOF may be invoked for HSLs if implemented and enabled at the node and if timer settings permit it.

4–49


GR-2878-CORE

… c. None: link oscillation filter not triggered or not used, restoration attempts shall not be delayed.

… 4. Link Oscillation Filter Restoration Delay

… For link failure cases where the Link Oscillation Filter is triggered (cases a. and b.), this parameter shall convey the remaining time in seconds (as of failure detection) until link restoration attempts shall be resumed, i.e., the remainder of timer T1.111.4/T32 or timer T1.111.4/T34.

O4-42 [94] It is an objective that the CCS node additionally provide, as clarifying text within the Link Outage event report, any applicable additional information, parameters, or other data that would be useful to maintenance personnel in clarifying the cause or other details of the link outage condition, or in assisting them in trouble sectionalization or isolation. Such information should include any applicable implementation-specific diagnostics available at the time the link outage is reported. Specifically, such text should include the following information.

… 1. If the outage is caused by local management intervention (i.e., local management inhibit, manual removal from service, or induced processor outage), clarifying information should include the identity of the operations interface or remote management system (operations system), and, if known, the operations application or logon process, responsible for initiating the action.

… 2. For link failure cases attributed to hardware or software problems at the link terminal, or spontaneous local processor outage, clarifying information should include any implementation-specific diagnostics about the supporting equipment elements available at the time of report generation, such as

… a. Lists of failed or suspect hardware components or software modules

… b. Proposed repair or replacement actions.

… 3. For facility outages, clarifying information should include any available diagnostics on the underlying failure event, e.g., LOS, LOF, or LCD conditions.

R4-43 [95] In cases of link failure, the CCS node shall not delay the generation of the link outage event report until a subsequent failed alignment attempt, nor until expiration of the MTP3 Link Craft Referral Timer [T1.111.4/T19], but instead shall report the outage immediately upon its detection, i.e., upon the link’s unavailability to MTP user part message traffic.

4–50

ab


R4-44 [96] In cases of link failure, the generation of the link outage report by the CCS node shall not be subject to delays associated with any diagnostic procedures performed on the link terminal, if such diagnostic procedures would cause the CCS node to delay message generation beyond the objective event reporting delay of 2.5 seconds. If any diagnostic procedures on the link terminal are underway but incomplete at the intended message generation time, then event-message generation shall proceed. If necessary, the link outage cause may be attributed to the condition resulting in the failure’s detection (e.g., excessive error rate) rather than a definitive diagnostic result indicating link terminal hardware or software problems.

O4-45 [97] It is an objective that the link outage notification be reported immediately before the generation of any higher-level event reports concerning a link set outage or node isolation condition resulting from the link outage, as inferred by the CCS node. It is assumed that the detect times for the corresponding events shall be assigned in the above order, if delays in the inference of those events by the CCS node cause their detect times to be different from one another.

4.4.1.4 Link Available Event Report

The Link Available event report shall convey the transition of a signaling link from the unavailable state to the available state with respect to MTP user part message traffic as perceived by MTP level 3 for any reason. This message is intended to replace the previously defined notifications for the Recovery from Link Failure, Recovery from Remote Processor Outage, and Link Near-End Manually Made Available events as defined in GR-82-CORE,[12] Section 6.6.2 for the STP, and covers those and all other detectable causes of link availability or recovery for both HSLs and MTP2 56-Kb/s links at all CCS node types.

R4-46 [98] The CCS node shall report, immediately upon its occurrence, the event that a HSL unavailable to SS7 user-part message traffic due to link failure, inhibiting, deactivation, manual removal from service, or its existence in a pre-service state, has become available to MTP user part message traffic, as perceived by MTP level 3. This shall include:

… a. For a previously failed or inactive link, link restoration/activation: the successful establishment or reestablishment of the link connection and successful proving at level 2 (for a HSL, the SAAL), followed by a successful Signaling Link Test (SLT) and resumption of MTP user part message traffic at MTP level 3.

4–51


GR-2878-CORE

… b. For a link previously in-service at the link layer but management-inhibited, link uninhibiting.

… This condition shall be reported as a “Link Available” event.

O4-47 [99] It is an objective that the CCS node supporting HSLs report immediately, upon its occurrence, the event that an MTP2 56-Kb/s signaling link that had been unavailable to SS7 user-part message traffic due to link failure, inhibiting, processor outage, deactivation, manual removal from service, or its existence in a pre-service state, has become available to MTP user part message traffic, as perceived by MTP level 3. For an MTP2 link, this shall include:

… a. Conditions (a) and (b) as cited in R 4-46 [98] (with MTP2 taking the place of SAAL procedures)

… b. For a link previously in-service at level 2 but blocked by local or remote processor outage, termination of SIPO LSSUs.

… This condition should be reported as a “Link Available” event in a manner consistent with the same notification provided for HSLs, with identical output parameters describing the details of the link availability event.

Objective O4-47 [99] may be made a requirement in the future. Information requirements for the generated link available event report are provided in Requirement R4-48 [100] and cover link available events for both the HSL and MTP2 link classes.

R4-48 [100] Each generated Link Available event notification shall contain the following information:

… 1. All common information defined under Requirement R4-32 [84], including:

… a. An event indicator conveying the link is available (e.g., RCVRY-LKOTG)

… b. The event severity indication for a “recovery” event.

… 2. Availability Cause Indicator

… The reason the link transitioned to the available state as determined by CCS node system management, based on event information logged at system management and at MTP level 3. One of the following indications shall be provided. (Parenthetical text in italics notes common aspects, similarities, and differences in the cited link available detection criteria between the HSLs addressed in this document and conventional MTP2-based signaling links.)

… a. Link Restoration

4–52

ab


… The link has been restored after a reported link outage.

… For a HSL, the successful reestablishment of the SSCOP connection, followed by successful link proving, a successful Signaling Link Test (SLT), and the resumption of MTP user part message traffic at MTP level 3.

… For MTP2-based links, this condition shall be based instead on successful alignment and proving per MTP2 procedures, followed by the successful SLT and the resumption MTP user part message traffic at MTP level 3.

… b. Link Activation

… A link previously inactive or in a pre-service condition, has been successfully activated and made available to MTP user part message traffic. Level 2 procedures for HSLs and MTP2 links are as defined for Link Restoration. (This assumes that the implementation can distinguish link activation from restoration. If such is not the case, the argument “restoration” may be used whenever the link becomes available.)

… c. Unblocking: Termination of Remote Processor Outage (MTP2 Links Only)

… The resumption of MTP user part message traffic following the termination of receipt of SIPO LSSUs (This condition does not apply to HSLs, which are considered failed under processor outage, and which must undergo link restoration procedures [realignment and proving] before they are again available to MTP user part message traffic.)

… d. Unblocking: Termination of Local Processor Outage (MTP2 Links Only)

… The resumption of MTP user part message traffic following recovery from local processor outage and the termination of transmission of SIPO LSSUs. (This condition does not apply to HSLs, which are considered failed under processor outage, and which must undergo link restoration procedures [realignment and proving] before they are again available to MTP user part message traffic.)

… (Remaining causes cited concern MTP3 link uninhibiting and shall be common to both HSLs and MTP2 links.)

… e. Uninhibit - Local Management

4–53


GR-2878-CORE

… The link was previously marked locally inhibited and has been successfully uninhibited as a result of an MTP-NM Link Uninhibit Request message sent by the reporting CCS node, as initiated by local management.

… f. Uninhibit - Local MTP Routing Control

… The link was previously marked locally inhibited and has been successfully uninhibited as a result of an MTP-NM Link Uninhibit Request message sent by the reporting CCS node, as initiated by local MTP routing control in response to the route set to the far-end node destination becoming unavailable.

… g. Forced Uninhibit - Local MTP Routing Control

… The link was previously marked remotely inhibited and has been successfully uninhibited as a result of an MTP-NM Link Forced Uninhibit message sent by the reporting CCS node, as initiated by local MTP routing control in response to the route set to the far-end node destination becoming unavailable.

… h. Forced Uninhibit - Remote MTP Routing Control

… The link was previously marked locally inhibited and has been successfully uninhibited as a result of an MTP-NM Link Forced Uninhibit message sent by the far-end CCS node, as initiated by its MTP routing control function in response to the route set to the near-end node destination becoming unavailable.

… i. Uninhibit - Remote

… The link was previously marked remotely inhibited and has been successfully uninhibited as a result of an MTP-NM Link Uninhibit Request message received from the far-end (remote) CCS node, as initiated at the far-end, either by management or automatically by MTP routing control.

… 3. Correlated Link Outage Sequence Number

… The sequence number of the last Link Outage event report generated for the given signaling link and against which the Link Available notification may be correlated. This sequence number may be null for the case of link activation or where the status of the CCS node prevents it from retaining the link outage report sequence number.

O4-49 [101] It is an objective that the CCS node additionally provide, as clarifying text within the Link Available event report, any applicable additional information, parameters, or other data that would be useful to

4–54

ab


maintenance personnel in clarifying the link activation or restoration event.

4.4.1.5 Sustained Link Failure/Craft Referral Event Report

The Sustained Link Failure/Craft Referral event report provides a separate indication that a failed link or an inactive link attempting activation has failed to prove-in for a period exceeding the T19 Failed Link Craft Referral Timer. This message is intended to replace the reported practice, supported by some CCS node implementations, of delaying the generation of Link Failure notifications for existing 56-Kb/s links until T19 expires. It shall allow a similar indication to be provided, separate from the immediate Link Outage notification, that may be used for purposes of local craft referral or initiating manual investigation and repair/dispatch activities for failed links. It may be applied to all signaling links (both 56-Kb/s and HSLs) and all CCS node types.

R4-50 [102] The CCS node shall report, immediately upon its occurrence, the event that a failed HSL, or an inactive HSL for which activation has been initiated, has remained in the out-of-service state at level 2 (for HSLs, the SAAL), and has not been successfully activated or restored for a duration exceeding the MTP level 3 Failed Link Craft Referral Timer (Timer T19/T1.111.4). This condition shall be reported as a “Sustained Link Failure/Craft Referral” event.

O4-51 [103] It is an objective that the CCS node supporting HSLs should report, immediately upon its occurrence, the event that a failed MTP2 link, or an inactive MTP2 link for which activation has been initiated, has remained in the out-of-service state at level 2 (MTP2), and has not been successfully activated or restored for a duration exceeding the MTP level 3 Failed Link Craft Referral Timer (Timer T19/T1.111.4). This condition should be reported as a “Sustained Link Failure/Craft Referral” event in a manner consistent with the same notification provided for HSLs, with identical output parameters describing the details of the event.

This objective may be made a requirement in the future. Information requirements for the generated event report are provided in Requirement R4-52 [104] and cover this event for both the HSL and MTP2 link classes.

R4-52 [104] Each generated Sustained Link Failure/Craft Referral Report notification shall contain the following information:


4–55


GR-2878-CORE

… a. An event indicator conveying sustained link failure (e.g., REPT-SUSTNLKF)

… b. The event severity indication for a “minor alarm”

… c. The detect time corresponding to the time of the T19 expiration.

… 2. Failure Type Indicator conveying one of:

… a. Link restoration failure

… b. Link activation failure.

… 3. Timer T19/T1.111.4

… The value of MTP level 3 timer T19 in seconds.

… 4. Initial Link Failure/Activation Time

… The date and time at which (a) the initial link failure was detected and reported as a link outage, or (b) signaling link activation was initially attempted. For link failures, this parameter shall allow maintenance personnel to locate the original outage notification in CCS node or OS alarm/event logs.


… For the case of link restoration failure, the sequence number of the last Link Outage event report generated for the given signaling link and against which the Sustained Failure notification may be correlated. This sequence number may be null for the case of link activation failure or where the status of the CCS node prevents it from retaining the link outage sequence number.

… 6. T19 Reset Indicator

… Conveys whether or not the T19 timer has been reset upon generation of this event notification, since the SS7 protocol allows either as an implementation-specific option. A reset T19 timer implies that subsequent sustained link failure notifications shall be generated if the outage condition persists for a subsequent interval of length T19.

… 7. Notification Number

… For implementations where T19 is reset and multiple successive sustained link failure notifications may be generated for the given initial link failure condition or link activation attempt, the number of the current sustained link failure notification for the given link failure or activation. It shall be initialized at 1 for the first T19 timer expiration, and shall be incremented for each subsequent expiration prior to link restoration.

4–56

ab


… 8. Link Restoration Attempt/Abandonment Indicator

… An indicator conveying whether the CCS node is continuing to automatically attempt link restoration or activation, or has abandoned further attempts pending manual intervention.

O4-53 [105] If additional implementation-specific diagnostic information is available about the status of the link terminal and/or about link restoration (alignment and proving) attempts made while timer T19 was running, it is an objective that such information be conveyed as well in clarifying text within the Sustained Link Failure/Craft Referral Report.

4.4.1.6 Unavailable-Link Minor State Change Event Report

The Unavailable Link Minor State Change event report shall convey a minor state change event for an unavailable signaling link, after which it remains unavailable to MTP user part message traffic as perceived by MTP level 3. Generally, it shall be used to convey a change in either the link’s MTP3 inhibit status or the level 2 service status (i.e., the alignment status for MTP2 links, or, for HSLs, the state of the SAAL connection as perceived by SSCF, SSCOP, and LM), when the link was already unavailable to MTP user part message traffic, and remains so due to an outstanding inhibit condition or level 2 outage. For MTP2 links it may also be used to convey link blocking and unblocking due to processor outage, where the link was already unavailable.

R4-54 [106] The CCS node shall report, immediately upon its occurrence, the event that a HSL already unavailable to MTP user-part message traffic due to link failure, inhibiting, deactivation, manual removal from service, or its existence in a pre-service state, experienced a change in its MTP3 link inhibit status or its level 2 (SAAL) in-service status, but remains unavailable to MTP user part message traffic, as perceived by MTP level 3. This shall include the following.

… 1. For an already failed or inactive link:

… a. Link inhibiting or uninhibiting (either local or remote).

… b. Restoration of level 2 (the SAAL connection) to the in-service state without a resumption of traffic due to a remaining inhibit condition.

… c. The commencement of normal proving or forced normal proving (for HSLs, after SSCOP connection establishment or reestablishment).

4–57


GR-2878-CORE

… d. Alignment/proving unsuccessful (for HSLs, after SSCF Timer_T2/T1.645 expiry and notification to MTP3 via an AAL-OUT_OF_SERVICE.indication).

… 2. For a link already in-service at level 2 (the SAAL) but unavailable due to inhibiting:

… a. Failure or removal from service of the level 2 connection, or

… b. Link inhibiting or uninhibiting (either local or remote).

O4-55 [107] It is an objective that the CCS node supporting HSLs report immediately, upon its occurrence, the event that an MTP2 signaling link already unavailable to MTP user-part message traffic due to link failure, inhibiting, processor outage, deactivation, manual removal from service, or its existence in a pre-service state, experienced a change in its MTP3 link inhibit status, its level 2 (MTP2) in-service status, or its processor outage status, but remains unavailable to MTP user part message traffic, as perceived by MTP level 3. This should include:

… 1. The conditions described in R4-54 [106] (with MTP2 replacing SAAL status and procedures at level 2).

… 2. The blocking or unblocking of the unavailable MTP2 link, where it remains unavailable due to a remaining processor outage, inhibit, and/or failure condition.

… This event should be reported in a manner consistent with the same notification provided for HSLs, with identical output parameters describing the details of the event.

This objective may be made a requirement in the future. Information requirements for the generated event report are provided in Requirement R4-56 [108] and cover this event for both the HSL and MTP2 link classes.

R4-56 [108] Each generated Unavailable-Link Minor State Change event notification shall contain the following information.


… a. An event indicator conveying an unavailable link minor state change (e.g., REPT-UNVLK-STCHG)

… b. The event severity indication for “action may be required.”

… 2. Status Change Indicator

… The specific event resulting in the level 2 status change or MTP3 inhibit status change, as determined by CCS node system

4–58

ab


management, based on event information logged at MTP level 3, the link layer [MTP2, or for HSLs, SAAL Layer Management (LM)], and/or the physical layer (i.e., the DS1 or DS0 interface). One of the following indications shall be provided for the event. Except where indicated, event conditions for HSLs and MTP2 links are as defined for the corresponding outage and availability cause indicators for the Link Outage and Link Available event reports, as provided in Sections 4.4.1.3 and 4.4.1.4 respectively.

… (Conditions cited with the asterisk (*) are unlikely to occur for links already unavailable to MTP user part message traffic, but can theoretically occur if the link is carrying test message traffic.)

… [Bracketed text does not apply to MTP2 links.]

… a. Failure: Excessive Duration of Far-End Receiving Congestion*

… b. Failure: Excessive In-Service Error Rate*

… c. Failure: Excessive Delay of Acknowledgment*

… d. Failure: Request Received from Maintenance or Management System

… e. [Failure:] Local Processor Outage (Spontaneous)

… f. [Failure:] Local Processor Outage (Management-Initiated)

… g. [Failure: SSCF Remote Release -] Remote Processor Outage

… h. Failure: SSCF Remote Release - Out-of-Service (HSLs Only)

… i. Failure: Level 2 Outage or Realignment (MTP2 Links Only)

… j. Failure: SSCF Remote Release - Protocol Error (HSLs Only)

… k. Failure: Abnormal FIBR/BSNR (MTP2 Links Only)

… l. Failure: SSCF Remote Release - Management Initiated (HSLs Only)

… m. Failure: Hardware Problems (Implementation-Dependent)

… n. Failure: Software Problems (Implementation-Dependent)

… o. Failure: Failed Periodic Signaling Link Test (SLT)

… p. Failure: Facility Outage

… q. Failure: Unresolved

… r. Failure: Other/Implementation-Specific

… s. Management-Inhibit: Local (Near-End)

4–59


GR-2878-CORE

… t. Management-Inhibit: Remote (Far-End)

… u. Manually Removed from Service (Maintenance)

… v. Manually Removed from Service (Configuration Management/Memory Administration)

… w. Level 2 Link In Service

… The successful restoration of the link at level 2.

… For HSLs, the establishment or reestablishment of the SSCOP connection, followed by successful proving, but without resumption of MTP3 user part message traffic, due to a remaining inhibit condition.

… For MTP2 links, this condition shall be defined instead in terms successful alignment and proving per MTP2 procedures without availability at MTP level 3, due to a remaining inhibit condition.

… x. Uninhibit - Local Management

… y. Uninhibit - Local MTP Routing Control

… z. Forced Uninhibit - Local MTP Routing Control

… aa. Forced Uninhibit - Remote MTP Routing Control

… ab. Uninhibit - Remote

… ac. Unblocking: Termination of Remote Processor Outage (MTP2 Links Only)

… ad. Unblocking: Termination of Local Processor Outage (MTP2 Links Only)

… ae. Commencing normal proving after connection establishment/reestablishment

… af. Commencing emergency proving after connection establishment/reestablishment.

… ag. Alignment/proving unsuccessful.


… The sequence number of the last Link Outage event report generated for the given signaling link and against which the Unavailable Link State Change notification may be correlated. This sequence number may be null for the case of initial link activation or where the status of the CCS node prevents it from retaining the link outage report sequence number.

4–60

ab


… 4. Current MTP3 Inhibit Status

… The inhibit status of the link as perceived by MTP level 3 procedures at the CCS node, following the state-change event (regardless of whether or not it changed as a result of the event); one of:

… a. Not inhibited

… b. Inhibited - local

… c. Inhibited - remote

… d. Inhibited - both.

… 5. Current Level 2 Service Status

… The current status of the level 2 connection as perceived by either the SCCF (for HSLs) or MTP2 (for MTP2-based links) at the CCS node, following the state-change event (regardless of whether or not it changed as a result of the event); one of:

… a. Out of Service

… b. Alignment

… c. In Service

… d. Proving

… e. Aligned Ready.

O4-57 [109] It is an objective that the CCS node additionally provide, as clarifying text within the Unavailable Link Minor State Change event report, any applicable additional information, parameters, or other data that would be useful to maintenance personnel in clarifying the link state change, the current link status, or the original link outage event report.

4.4.1.7 Oversized Message Routing Attempt on an MTP2 Signaling Link

As cited earlier, STPs shall be required to simultaneously support both SAAL-based HSLs and conventional 56-Kb/s MTP2-based signaling links. Because HSLs shall be capable of handling messages at the link layer up to the maximum SSCOP SD PDU size of 4096 octets allowed by SSCOP, while MTP2 based links shall be restricted to message lengths not exceeding 272 MSU octets, it is possible that large messages exceeding the MTP2 limit (e.g., large TCAP or B-ISUP messages) may be incorrectly routed to an MTP2 link, which cannot accommodate them. The resulting message discards must be reported to maintenance systems responsible for fault management, so that the STP routing table errors responsible for such incorrect routing attempts may be rectified. This message shall apply only to MTP2-based signaling links at STPs that support HSLs.

4–61


GR-2878-CORE

R4-58 [110] An STP supporting HSLs shall report, immediately upon each occurrence, the event that an MTP3 message received on a HSL, or re-originated by the STP as a result of a Global Title Translation (GTT) or other SCCP translation it performed, has attempted to route over an MTP2 signaling link, but exceeds the MTP2-imposed length limit of 272 octets, and has been discarded by the STP as a result.

R4-59 [111] Each generated Oversized Message Routing Attempt notification shall contain the following information:

… 1. All common information defined under Requirement R4-32 [84], including, specifically for this event:

… a. An event indicator conveying the oversized message routing attempt (e.g., REPT-OVSZMSG)

… b. The event severity indication for a “minor alarm”

… c. Attempted MTP2 Link ID

… The identity of the MTP2 link to which the oversized message was directed, in terms of its common link identifiers:

… - Its unique Link ID (Link Set Name and Member Number [SLC])

… - Its locally unique Equipment Port Identifier.

… 2. The length of the discarded message in MTP3 message octets12.

… 3. The discarded message’s routing label OPC.

… 4. The discarded message’s routing label DPC.

… 5. The discarded message’s Service Indicator (SI).

… 6. Incoming HSL ID

… If the STP attempted to through-switch the message, which arrived on a HSL, the identify of that HSL, in terms of:

… a. Its unique Link ID (Link Set Name and Member Number [SLC])

… b. Its locally unique Equipment Port Identifier.

… If the message was originated at the STP itself as a result of a GTT, this parameter shall be null.

… 7. SCCP Message Fields

12. That is, the length of the MTP3 message unsuccessfully submitted to MTP2 procedures for transmission on the link. This excludes MTP2-related octets that would have been added if were possible to transmit the message on the link.

4–62

ab


… If the discarded message was an SCCP message, the following SCCP data fields from the discarded message shall be reported (if populated):

… a. The SCCP message type

… b. The Called Party Address (CdPA) Translation Type (TT)

… c. The CdPA Global Title Address (GTA)

… d. The CdPA Routing Indicator (RI)

… e. The Calling Party Address (CgPA) Point Code

… f. The CgPA Subsystem Number (SSN).

… (This information is intended to allow personnel to locate erroneous DPC values in provisioned GTT data that may be responsible for the message routing error, as well as determine the source of the impacted message traffic and the impacted signaling application or services.)

O4-60 [112] It is an objective that the CCS node additionally provide, as clarifying text within the Oversized Message Routing Attempt event report, any applicable additional information, parameters, or other data that would be useful to maintenance personnel in clarifying the cause or other details concerning the discarded message, or assisting them in trouble isolation. Such information may include, for example, additional data from the signaling information field of the discarded message, which might convey the source of the message or the impacted signaling application or services.

When such MTP routing errors occur, it is likely that a large number of such oversized message discards shall take place, such that a large number of corresponding event notifications would potentially be generated.

R4-61 [113] In order to prevent flooding of the operations interface channels with the event indications, the following procedure shall be used by the STP to limit the generation of such notifications. The STP shall generate an Oversized Message Routing Attempt notification for each of only the first n occurrences of such message discards within each successive m-minute clock interval, where n and m are variable parameters.

R4-62 [114] Output limits n and m shall be management-configurable on a per-STP basis for this specific event notification, via the interface from the management system responsible for fault management of the STP, i.e., via the maintenance OS interface, and via the management system responsible for configuration management of the STP. The following default values shall be assumed at installation: n = 10 occurrences in m = 5 minutes.

4–63


GR-2878-CORE

Output limits shall be set so that sufficient information is available for event diagnosis by operations personnel. It should also be noted that although this event notification is throttled via this management-configurable parameter, the total message discards will be measured on a 5-minute and a 30-minute accumulation interval for performance management purposes. (See also Sections 4.5.1.1 and 4.6.1.1.)

4.4.2 Link Status Logging

The event reporting functions defined within Section 4.4.1 provide alerting capabilities that enable management personnel and systems to keep apprised of HSL outages, recoveries and minor state changes. This enables management to detect - and begin to sectionalize or isolate - link failures and potentially dispatch personnel for repair and restoration efforts on an exception basis.

An additional useful capability for the CCS node is a mechanism enabling maintenance personnel and management systems responsible for fault management to track the transient status of each HSL, including all relevant state transitions at MTP level 3 and the SAAL concerning link outage and recovery. At the SAAL level, this shall include detailed intermediate state-transition information on the link alignment and proving process for a failed or inactive HSL, so that a detailed time-stamped record of SAAL connection failures and alignment attempts is available for analysis. Such a record may be used, for example, to ascertain the current state or recent history of a failed HSL undergoing alignment attempts and to detect repeated link alignment failures. This shall involve the logging by the CCS node of all transitions between applicable states recognized by MTP level 3 (available or unavailable) and SAAL Layer Management (which recognizes numerous distinct alignment states and SSCOP connection states for the link based on its monitoring of the SSCF and SSCOP). Such detailed logged information may also be useful in assessing the performance and compatibility of SAAL-level timers and other parameters as set at each end of each HSL. In addition, the CCS node shall also log changes in the link’s MTP3 inhibited status (local, remote, both, neither). It shall be an objective that the log of state transitions be maintained by the CCS node and be made available for retrieval by applicable management systems and personnel. Because of the potentially resource-intensive nature of this capability, especially during multiple link failures and recoveries, this logging function is stated as an objective rather than a requirement. Specifically, the following objectives address aspects of this logging function at the CCS node. They may be changed to requirements or conditional requirements in the future.

O4-63 [115] It is an objective that the CCS node log all transitions of each HSL into each of the following states - each state defined as a concatenation of the following three status components (with possible values noted in parentheses):

… — MTP3 Availability Status(Available or Unavailable - to MTP user part message traffic)

4–64

ab


… — SSCF Alignment Status(Out of Service, Alignment, In Service, Proving, or Aligned Ready)

… — SSCOP Connection Status(Idle, Outgoing Connection Pending, Outgoing Disconnection Pending, or Data Transfer Ready).

… That latter two components shall be consistent with SSCF alignment state definitions and SSCOP connection state definitions provided in ITU Recommendation Q.2144,[11] Section 5.3 (State Transition Table of LM for the Management of SAAL at the NNI), and ANSI T1.645[7] (formerly T1S1/94-398), Section 12 (State Transition Table of the SSCF at the NNI). (SSCOP connection status is defined in the latter reference.)

… Specifically the transitions to be logged should include those of the HSL into each of the following possible compound states:

… 1. Unavailable: Out of Service - Idle

… In this state, no signaling connection exists and the SSCF waits for an AAL -START.request from the SSCF user (MTP3). The SSCOP connection is idle (no PDUs are being exchanged).

… 2. Unavailable: Out of Service - Outgoing Disconnection Pending

… The SAAL user (MTP3) or LM has issued an AAL-STOP.request or an AA-RELEASE.request, respectively, which has caused the SSCF to issue an AA-RELEASE request. The SSCF is waiting for a confirmation of the SSCOP connection release, AA-RELEASE.confirm.

… 3. Unavailable: Alignment - Outgoing Connection Pending

… In this state, the SSCF is in the process of establishing an SSCOP connection (attempting alignment). The user (MTP3) has issued an AAL-START.request, and the SSCF is waiting for a confirmation of the SSCOP connection.

… 4. Unavailable: Alignment - Idle

… In this state, the SSCF has received an AAL-START.request but is waiting between alignment attempts. The SAAL user (MTP3) has requested that the SSCF provide an SSCOP connection. The request was passed to SSCOP by means of an AA-ESTABLISH.request, but the connection establishment or proving was unsuccessful and the SSCF is waiting to repeat the process. The process will be repeated until a supervisory function indicates that this process is to be abandoned.

4–65


GR-2878-CORE

… 5. Unavailable: Alignment - Outgoing Disconnection Pending

… In this state, the SSCF, or in the case of unsuccessful proving - Layer Management (LM), has requested the release of the SSCOP connection. The request was passed to SSCOP via an AA-RELEASE.request, and the SSCF is awaiting confirmation of the SSCOP connection release, AA-RELEASE.confirm. This state transition within SSCF is not indicated to the SAAL user.

… 6. Unavailable: Proving - Data Transfer Ready

… In this state, an SSCOP connection has been established and LM is conducting Alignment Error Rate Monitoring (AERM) to verify the quality of the link.

… 7. Unavailable: Aligned Ready - Data Transfer Ready

… In this state, the SSCF has completed proving and is awaiting an indication from its peer that the signaling link may be put into service at level 2.

… 8. Unavailable: In-Service - Data Transfer Ready

… In this state, the signaling connection may be used by the SCCF user (MTP3) to transfer messages (i.e., it is in service at level 2). LM conducts ongoing In-Service Error Rate Monitoring (ISERM). However, the HSL is considered unavailable to user part message traffic by MTP level 3 because it is either inhibited or is awaiting successful completion of an MTP-T&M Signaling Link Test (SLT).

… 9. Available - In-Service - Data Transfer Ready

… The HSL is considered available to user part message traffic by MTP level 3. It has successfully passed a Signaling Link Test, is not inhibited, and may be used to transfer MTP3 messages over the SSCOP connection as SD PDUs.

O4-64 [116] It is an objective that the link status log also record all changes in the link’s inhibited state at MTP level 3, independent of whether or not the inhibit or uninhibit action caused a change in the MTP level 3 availability state (e.g., the link may have already been unavailable at the time it was marked inhibited). When each inhibit status change occurs, the log shall record the new inhibit status, one of:

… • Not inhibited

… • Inhibited - local

… • Inhibited - remote

4–66

ab


… • Inhibited - both

… and shall append it to the current link availability, alignment, and connection states cited, in the link status log record.

O4-65 [117] For those HSL status changes resulting in a change in the link’s availability to MTP user part message traffic, its’s inhibit status, or the in-service state of the SAAL, it is an objective that the CCS node should also capture in the HSL log record: the applicable Link Outage Cause Indicator, Availability Cause Indicator, or Status Change Indicator from the corresponding (separately generated) Link Outage Event Report, Link Available Event Report, or Unavailable Link Minor State Change Event Report (respectively), per detection criteria specified in Section 4.4.1.3, R4-41 [93]; Section 4.4.1.4, R4-48 [100]; and Section 4.4.1.6, R4-56 [108].

O4-66 [118] It should be possible for authorized management systems and personnel responsible for the fault management function to enable and disable the HSL status logging function at the CCS node on a per-link basis and globally for all HSLs at the CCS node.

O4-67 [119] Each HSL state transition log entry or record should include the identity of the HSL undergoing the state transition (in terms of its configured Link ID), the state it entered, and a date-and-time stamp.

O4-68 [120] It is an objective that the time-stamp logged for each HSL state transition log entry or record support a minimum precision of 1 millisecond (ms).

O4-69 [121] The HSL state transition log entries should be maintained at the CCS node and shall not be automatically transmitted on operations interfaces on an unsolicited basis, so as to avoid duplication of link outage and recovery event notifications sent on those interfaces.

O4-70 [122] It is an objective that the HSL state transition log be maintained at the CCS node for a minimum retention interval of 24 hours.

O4-71 [123] The contents of the HSL state transition log should be available for retrieval via commands submitted by authorized personnel at the USI and by authorized management systems via operations interfaces, including the CCS node’s interface to its maintenance OS responsible for fault management functions.

4–67


GR-2878-CORE

O4-72 [124] HSL state transition log records should be retrievable from the CCS node according to user-specified request parameters denoting the identity of the HSL and the timestamp range for which records are to be provided.

O4-73 [125] It is an objective that the CCS node support a capability by which a real-time stream of copies of the HSL state transition log entries for any selected HSL may be directed to the maintenance channel interface as event notifications so that those notifications may be logged by the OS or management system responsible for fault management functions.

4.4.3 Lower-Layer Fault-Management Surveillance Functions

Below the SAAL, additional surveillance functions are potentially applicable as discussed in the following subsections:

• ATM-Layer Defect and Failure Detection and Reporting (4.4.3.1)

• Physical-Layer (DS1) Defect and Failure Detection and Reporting (4.4.3.2).

These capabilities are intended to provide additional information on lower-layer failures and anomalies, which may be correlated with HSL outages or degraded HSL performance. They are intended for use in trouble detection and isolation.

4.4.3.1 ATM-Layer Defect and Failure Detection and Reporting

ATM NE generic operations requirements in GR-1248-CORE,[25] Section 6.1.2, address surveillance capabilities for the detection and reporting of ATM-layer defects and failures, including the detection and generation of ATM In-Band Defect Indication Signals (AIS and RDI OAM cells) as described in Section 4.3. However, as discussed in that section, these ATM-layer fault management functions shall not be required for the direct, dedicated, point-to-point, single-VCL VCCs used to support ATM-based HSLs, where no intermediate ATM NEs are involved.

Therefore, no failure detection and reporting capabilities for ATM-layer outages or defects shall be required at this time for CCS nodes terminating HSLs. They may be required in the future if multi-VCL VCCs, utilizing one or more intermediate ATM NEs, rather than the described point-to-point (direct) single-VCL VCCs, are ever used to support ATM-based HSLs between CCS nodes.

The separate link outage detection and reporting requirements presented in Section 4.4.1 for MTP level 3 and the SAAL are deemed sufficient to support HSL failure detection. In addition, DS1-level defect and failure detection and reporting requirements, described immediately below in Section 4.4.3.2, provide additional information that may be used to

4–68

ab


detect when underlying facility outages have occurred, which may be correlated with the reported (higher-level) HSL failures.

4.4.3.2 Physical Layer Defect and Failure Detection and Reporting (DS1)

Consistent with Fault Management requirements specified for ATM NEs in GR-1248-CORE,[25] Section 6.1.1, CCS nodes supporting HSLs shall be required to detect and report failures concerning Loss of Signal (LOS), Loss of Frame (LOF), and Loss of Cell Delineation (LCD) events at their HSL’s DS1 interfaces as well as failures conveyed by the remote end or intermediate DS1 Network Transport Elements (NTEs) on the ESF data channel. In addition, they must support the generation of necessary DS1 in-band maintenance signals concerning such level 1 outages for use by the intermediate DS1 NTEs, and the far-end CCS node, which may be affected by them. Applicable requirements and objectives are presented in the following subsections.

4.4.3.2.1 LOS and LOF Event Detection

R4-74 [126] The CCS node shall support fault detection and in-band alarm surveillance requirements for the following fault conditions at each HSL’s DS1 interface:

… a. Loss of Signal (LOS)

… b. Loss of Frame (LOF)

… as defined for alarm indication signal processing per GR-499-CORE.[4]

R4-75 [127] On each HSL’s DS1 interface, the CCS node shall support the generation of the DS1 in-band Alarm Indication Signals (AIS), including declaration, removal, and reporting, as defined in TR-NWT-001112.[2]

4.4.3.2.2 Loss of Cell Delineation (LCD) Failure Detection

Under normal operation of the DS1 interface receiving ATM cells, the cells are delineated (i.e., extracted) from the DS1 frame payloads after the starting position of each cell is first located. However, if 7 consecutive ATM cells have Header Error Control (HEC) violations, an Out-of-Cell Delineation (OCD) anomaly is said to occur. The OCD anomaly will continue until either cell delineation is re-established (i.e., referred to as returning to the “sync” state), or a transition is made into the Loss of Cell Delineation (LCD) defect state after a waiting period of X ms (reframe time) has expired. (X = 50 ms is recommended for DS1-rate transmission systems based on criteria in GR-499-CORE.)[4] If the LCD defect

4–69


GR-2878-CORE

persists for a threshold interval of 2.5 ± 0.5 seconds, then LCD failure is declared for the DS1 facility.

R4-76 [128] The CCS node shall support applicable fault-detection and alarm surveillance functions for the Loss of Cell Delineation (LCD) failure condition for each HSL’s DS1 interface, as defined in GR-1248-CORE,[25] Section 6.1.1.3, and GR-499-CORE.[4]

Note that the generation of ATM AIS cells on the HSL’s VCL, upon detection of an LCD defect, shall not be required at this time for the CCS node, as it shall be for ATM NEs as specified in the reference in this section, because only a direct ATM VCC is required for HSLs.

4.4.3.2.3 DS1 Failure Notification and Logging

R4-77 [129] The CCS node shall generate applicable event notifications for all DS1 failure events concerning:

… 1. LOS

… 2. LOF

… 3. LCD

… 4. all other applicable performance-related DS1 failure conditions according to criteria specified in GR-820-CORE,[22] Section 4.2 “DS1 Performance Failures” and Table 4-1 “DS1 Failure Definitions”.

R4-78 [130] The indicated DS1 failure notifications shall be transmitted over the following operations interfaces:

… a. The CCS node’s Maintenance OS interface (i.e., the “maintenance channel”)

… b. The CCS node’s local User System Interface (USI).

… Such reporting shall be subject to any filtering or thresholding at the CCS node for those messages as may be defined for the CCS node implementation of those interfaces.

R4-79 [131] Each DS1 failure event notification shall include the identity of the HSL in terms of its Link ID (LSN and Member Number) and Equipment Port Identifier, the DS1 failure cause, a date-and-time stamp, and any other applicable diagnostic information for the DS1 interface.

R4-80 [132] Event notifications for the indicated DS1 failure conditions shall be generated independently of any higher-level Link Outage notifications

4–70

ab


generated for the same signaling link (as described in Section 4.4.1.1), regardless of whether or not the DS1 failure results in a link failure (reported as a case of link outage). Specifically, the higher-level link outage notifications shall not be suppressed when the DS1 failure indication is generated.

R4-81 [133] The CCS node shall additionally record each DS1 failure event report in its local maintenance log, for later access by authorized personnel at the USI and maintenance OS interfaces.

4.4.4 Link Testing Functions

4.4.4.1 Physical-Level Testing: DS1 ESF Loopbacks

When a signaling link fails, network operations personnel responsible for fault management will attempt to sectionalize the failure, to distinguish problems with the near-end link terminal at a given CCS node from a facility outage or from link terminal problems at the link’s far-end CCS node. In the DS0 environment used to support conventional 56-Kb/s signaling links, capabilities exist to allow users to loop back the physical-level signal between the link termination at a CCS node and the remote DS0 termination at the far-end CCS node (if possible), or to intermediate DS0 network transport elements (NTEs), at which an outage in a facility span may be causing the link outage. That loopback function thereby enables operations personnel to sectionalize the data link outage to a given DS0 facility span, and allows them to provide such information to facility maintenance personnel to whom they shall generally hand-off the trouble.

For HSLs, the DS1 ESF format supports a similar, but not as extensive, line loopback capability. Specifically, the 4-Kb/s embedded operations channel (described in Section 4.3.1, R4-22 [74] and in GR-499-CORE[4]), provides (among other functions) a loopback capability that may be used to confirm continuity of the DS1 transmission link up to the terminating point of the DS1 ESF “clear channel”. Such capabilities shall likely be used in the initial steps of trouble verification and sectionalization for a link failure.

R4-82 [134] The CCS node shall allow authorized personnel to initiate, via commands submitted at the USI and via the operations interface from the Maintenance OS (i.e., the management system responsible for fault management), DS1 ESF line loopback tests for individual HSLs that are out of service,13 enabling those personnel to confirm continuity of the

13. Because the loopback tests are intrusive (service affecting), provisioned HSLs must not be enabled to carry MTP3 message traffic or be undergoing alignment at the time such tests are initiated. That is, the HSL must reside in the compound link state of “unavailable” (MTP3), “out-of-service” (SCCF), and “idle” (SSCOP), before the DS1 loopback may be initiated.

4–71


GR-2878-CORE

signaling data link (transmission link) between the DS1 termination at the CCS node and the remote termination point of the DS1 data link’s ESF embedded operations channel. The test shall utilize the DS1 ESF data link unscheduled message capabilities, loopback functions, and associated message codewords as defined in GR-499-CORE,[4] Section 10.2.4.3.C and Table 10-13.

R4-83 [135] It shall be possible for users to initiate the indicated DS1 loopback testing functions at the indicated operations interfaces for any of the CCS node’s equipped and active DS1 ports, even prior to their assignment to CCS HSLs, so as to support facility testing prior to turn-up of the HSLs. This implies that users shall be able to select equipped but unassigned DS1 Equipment Port Identifiers at the CCS node for which to generate the loopback tests, in addition to their ability to select the Link IDs of already configured HSLs.

Note that there are limitations in the loopback capabilities supported under the current definition of DS1 ESF. The control code structure defined for the DS1 ESF embedded operations channel does not support commands and diagnostics to perform loopbacks to specific intermediate facility spans, as did DS0 for 56-Kb/s links, and therefore cannot support link fault sectionalization between the termination points of the HSL’s DS1 connection. So the DS1 loopback capabilities to be provided shall involve a loss of some trouble sectionalization functionality relative to those available for existing DS0 (56-Kb/s) signaling links. Full link fault sectionalization shall therefore likely require the use of surveillance data on the failures of individual facility spans generated at intermediate NTEs as accessed through OSs responsible for fault management of network transport facilities.

Also, depending upon the transmission network architecture supporting the DS1 transmission link, the terminating point of the loopback may be the CCS node at the far-end of the HSL, or it may be some intermediate network element configured as the endpoint of the DS1 connection, where the embedded data channel terminates. At such DS1 termination points, the information conveyed on the DS1 ESF embedded operations channel is lost. Therefore, the DS1 loopback capability does not necessarily operate on an end-to-end basis with respect to the HSL’s far-end CCS node. The ability of the CCS node to perform end-to-end loopback testing on the HSL’s DS1 connection shall therefore depend upon the initiating and far-end CCS nodes being configured as the end-points of the DS1 connection. This is expected to be the case for the dedicated, direct, ATM VCC implementation of HSLs as defined in this document.

In the future, if one or more intermediate ATM NEs were involved in supporting the HSL’s ATM VCC, then each such ATM NE would represent a DS1 termination point, and end-to-end DS1 loopbacks could not be supported for the HSL connection. If such ATM HSL architectures are supported in the future, CCS network personnel would require access to fault management capabilities in ATM management systems to perform end-to-end trouble sectionalization.

4–72

ab


4.4.4.2 ATM-Layer OAM Loopback Tests

A similar loopback capability at the ATM layer shall allow fault-management personnel to confirm the ability of the CCS node to exchange ATM-cells with its peer at the far-end of the HSL. Because it is assumed that there are no intermediate ATM NEs supporting the HSL’s ATM VCC, only connection-level, rather than segment-level cell loopback test capabilities shall be required at CCS nodes at this time. The use of such capabilities for ATM-level fault sectionalization at intermediate NEs shall not be applicable to the direct VCC case.

R4-84 [136] The CCS node shall allow users to initiate, via the USI and via the operations interface from the Maintenance OS (i.e., the management system responsible for fault management), ATM OAM Loopback tests toward the link’s remote ATM VCC termination, so as to determine or confirm the availability or outage of ATM-layer functions for that HSL between the initiating CCS node and the far-end CCS node.

R4-85 [137] On each HSL’s ATM VCC termination (VCL), the CCS node shall support all functional requirements for the ATM cell loopback capability applicable to VCC endpoints for loopbacks to and from the remote VCC endpoint, as specified in GR-1248-CORE,[25] Section 6.2.2 (VPC/VCC Testing Capabilities).

4.4.5 Link Control Functions (Removal From Service)

The CCS node shall need to provide the following link control functions allowing the removal of HSLs from service by management systems and personnel. Such capabilities are needed to facilitate fault management functions, such as intrusive link testing, the intentional redirection of link traffic, and the forced isolation of signaling points.

R4-86 [138] The CCS node shall allow personnel via the USI and via the operations interface from the Maintenance OS (i.e., the management system responsible for fault management), to gracefully remove designated unavailable HSLs from service at level 2 (the SAAL), after the HSLs have been inhibited from carrying user part message traffic, and maintain them in that state until subsequent management interventions removal action shall render the link “out-of-service” at the SSCF, and “idle” at SSCOP.

In addition to the control function cited in R4-86 [138], the CCS node shall also support the following forced removal-from-service action that is not dependent on the inhibit status of the link or the status of the route sets it supports.

4–73


GR-2878-CORE

R4-87 [139] The CCS node shall allow personnel via the USI and via the operations interface from the Maintenance OS (i.e., the management system responsible for fault management), to unconditionally force designated HSLs out of service and maintain them in that state until subsequent management intervention.

… 1. The forced removal action shall render the link: “unavailable” to MTP user part message traffic at MTP level 3, “out-of-service” at the SSCF, and “idle” at “SSCOP”.

… 2. The forced removal action shall not require the link to first be inhibited.

… 3. The forced removal action shall be accepted regardless of the current availability status of the route sets that utilize the affected link sets in which each HSL resides.

… 4. The CCS node shall support the removal from service of HSLs designated on a per-link basis or by the link set in which they reside.

R4-88 [140] The CCS node shall allow personnel via the USI and via the operations interface from the Maintenance OS (i.e., the management system responsible for fault management), to initiate the restoration to service of HSLs removed via the link control capabilities.

4.5 Performance Management (Maintenance and Network Traffic Management)

The Performance Management operations domain includes those operations functions concerned with short-term performance monitoring of network components and the service provided to network users. This activity maps generally to two of the more traditionally named LEC operations functions of Network Maintenance Surveillance and Network Traffic Management (NTM) Surveillance.

• Network Maintenance Surveillance is intended primarily to monitor and trend measurements concerning the availability and performance of network components, such as signaling links, and detect marginal performance in support of preventive maintenance activity. Maintenance Surveillance reports are typically generated on time frames ranging from one hour to one day, and are addressed on an exception basis. Longer term statistics on network performance may also be generated from such measurement data. With respect to the CCS network (CCSN), relevant data primarily concern signaling link traffic, congestion, availability, and message loss.

• Network Traffic Management (NTM) is instead concerned with real-time or near-real time traffic and performance monitoring. Such monitoring is performed to detect traffic overloads or service-affecting resource outages, and support network

4–74

ab


management decisions regarding higher-level manual or automatic control actions within the Public Switched Network (PSN), so as to mitigate the effects of the overload or outages, throttle-back traffic, and optimize the use of available network resources. With respect to the CCSN, where little or no manual control capabilities are available at the SS7 protocol level, NTM surveillance is geared mainly toward the detection of CCSN outages and congestion, to help PSN network traffic managers (1) determine whether the CCSN is the root cause of, or primary contributor to, call blocking or overloads in the PSN, and/or (2) determine conversely when PSN overloads are contributing to CCSN overloads. With respect to HSLs, the link performance data of primary interest to NTM personnel shall be those concerned with link unavailability, link transmit congestion, and SS7 message discards.

For HSLs, requirements for the surveillance activity shall be organized in three subsections addressing

• Scheduled Link Performance Measurements (Section 4.5.1)

• Exception-Based Performance Monitoring (Section 4.5.2)

• Management-Initiated Performance Monitoring (Section 4.5.3).

4.5.1 Scheduled Link Performance Measurements

Scheduled link performance measurements are those measurements that are to be routinely collected by each CCS network node for its HSLs to support-short term performance monitoring. They are intended to facilitate the more traditionally named operations functions of Network Maintenance Surveillance and Network Traffic Management Surveillance just described. These include measurements to be accumulated and reported on a marginal (hourly) and daily (24-hour) basis for network maintenance and a five-minute basis for NTM. Marginal measurements are those to be collected and reported on an hourly interval, but only for those links whose selected hourly measurements exceed one or more of the marginal performance threshold criteria for those measurements in each hour. (See also Section 4.5.2.1 regarding link marginal performance exception reporting).

In the following subsections, the performance measurement requirements are organized according to both their accumulation or reporting interval (hourly and marginal, or five-minute) and the layer of the HSL protocol stack to which they apply (MTP3, SAAL, or ATM, where applicable). Additional measurement intervals and a separate report generation structure shall be applicable to DS1 performance monitoring.

Note that many of the following numerous measurements cited, in particular those concerning MTP3 functions, shall be common to both the SAAL-based HSLs, which are the subject of this document, and conventional MTP2-based signaling links. Other measurements shall be unique to HSLs. Of the HSL-specific measurements, some may be similar in definition (i.e., they shall be analogous) to performance measurements already defined for MTP2 links and differ only with respect to the definition of the Protocol Data

4–75


GR-2878-CORE

Units (PDUs) to be measured, and may be viewed as “replacing” those measurements for the HSL case. Other HSL-specific measurements concern PDUs and events unique to the HSL protocol stack for which no direct MTP2 analog is defined. Where applicable, explanatory notes (parenthetical in italics) appear after each measurement definition to clarify such relationships. In addition, Appendix D of this GR provides a summary of these and other HSL measurements and their relationship to previously defined MTP2 link measurements.

4.5.1.1 MTP Level 3 Performance Measurements: Daily and Marginal

At MTP level 3, the CCS node shall be expected to collect performance measurements concerning each HSL’s availability to user part message traffic as well as the overall volume of MTP3 messages carried by the link. Most of these measurements shall be the same as or similar to those measurements collected for conventional MTP2-based signaling links.

R4-89 [141] For its HSLs, the CCS node shall support the collection and reporting of the following MTP level 3 link performance measurements, on a per-link basis, for the indicated accumulation and reporting intervals: daily [d] and/or marginal [m]:

… 1. MTP3 Messages Transmitted [d, m]

… The number of MTP Level 3 (MTP3) messages submitted to the SAAL for transmission to the far end, including those for which retransmissions of SSCOP SD PDUs may have been necessary. Note that SSCOP retransmissions are not included in this count. (Replaces MSUs Transmitted [Including Retransmissions], which is applicable only to MTP2 links.)

… 2. MTP3 Messages Received [d, m]

… the number of MTP3 messages received from the far end. (Replaces MSUs Received, which is applicable only to MTP2 links.)

… 3. MTP3 Message Octets Transmitted [d]

… the number of octets comprising MTP3 messages submitted to the SAAL for transmission to the far end, excluding additional octets added by the SAAL and ATM layers. Note that SSCOP retransmissions are not included in this count. (Replaces MSU Octets Transmitted [including Retransmissions], which is applicable only to MTP2 links.)

… 4. MTP3 Message Octets Received [d]

4–76

ab


… The number of octets associated with MTP3 messages received from the far-end, excluding additional octets added by the SAAL and ATM layers. (Replaces MSU Octets Received, which is applicable only to MTP2 links.)

… 5. Link Available Time [d, m]

… The total time in seconds the link was available to MTP level 3 user part message traffic. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 6. Number of Automatic Changeovers [d, m]

… Number of times the changeover procedure is invoked to move traffic from the link taken out of service to one or more alternate in-service links. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 7. Number of Hourly Thresholds Exceeded for Automatic Changeovers [d]

… An hourly threshold is used to determine if the previous measurement (Number of Automatic Changeovers) for a given link should cause that link to appear on the signaling link marginal performance report for a particular hour. This measurement counts the number of times that threshold was exceeded over a 24-hour period (i.e., the number of hourly signaling link marginal performance reports on which the link was reported as having exceeded its threshold for automatic changeovers). (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 8. Near-End Forced Link Unavailable [d]

… The number of times the link was manually made unavailable to MTP level 3 due to actions initiated at or for the reporting CCS node, e.g., manual deactivation, local management-inhibiting, manually induced local processor outage, or requests received from a maintenance or management system. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 9. Number of Far-End Management Inhibits [d]

… The number of times the link was successfully inhibited from the far-end (remotely inhibited). (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 10. Number of Signaling Link Failures - All Types [d]

… The number of times the signaling link has failed to prove in after an automatic changeover (i.e., after a detected link failure). (This

4–77


GR-2878-CORE

measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 11. Cumulative Duration of Signaling Link Failures - All Types [d]

… The total time in seconds that the signaling link was unavailable to MTP level 3 traffic due to (i.e., following) signaling link failures. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

The generation of HSL marginal performance reports is addressed separately in Section 4.5.2.1 (HSL Marginal Performance Reports).

R4-90 [142] STPs supporting both HSLs and MTP2 links shall additionally provide the following MTP level 3 performance measurement on a 24-hour accumulation interval [d]:

… • Oversized Message Discards

… The number of SS7 (MTP3) messages discarded because they exceeded the 272-octet message size limit for MSUs on an MTP2 link. This measurement shall be provided on the following measurement bases:

… 1. On a per-link basis for all MTP2 links.

… 2. Summed across all MTP2 links on a system-total basis.

4.5.1.2 MTP Level 3 Performance Measurements: 5-Minute

R4-91 [143] For its HSLs, the CCS node shall support the collection and reporting of the following MTP level 3 link performance measurements, on a per-link basis, for each successive five-minute interval during which the respective measurements are non-zero. Zero-valued link measurements shall not be reported and shall be inferred as such by their absence on five-minute measurement reports.

… 1. Duration of Link Outage

… The total time in seconds the link was unavailable to MTP level 3 user part traffic during the measurement interval, regardless of whether the unavailability resulted from link failure or manual action at the reporting node or remote node. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 2. Duration of Level 1 Link Congestion

… The total time in seconds the link was in congestion level 1 during the measurement interval. This total time is obtained by summing the time

4–78

ab


duration of each individual level 1 link congestion event. A level 1 link congestion event begins when the level 1 congestion onset threshold is first reached or exceeded, or at the start of the measurement interval if the link is already at congestion level 1. The level 1 congestion event ends when one of the following occurs: (1) the occupancy first falls below the level 1 congestion abatement threshold, (2) the occupancy reaches or exceeds the congestion onset threshold for congestion level 2, or (3) the measurement interval ends. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)


… The total time in seconds the link was in congestion level 2 during the measurement interval. This total time is obtained by summing the time duration of each individual level 2 link congestion event. A level 2 link congestion event begins when the level 2 congestion onset threshold is first reached or exceeded, or at the start of the measurement interval if the link is already at congestion level 2. The level 2 congestion event ends when one of the following occurs: (1) the occupancy first falls below the level 2 congestion abatement threshold, (2) the occupancy reaches or exceeds the congestion onset threshold for congestion level 3, or (3) the measurement interval ends. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)


… The total time the link was in congestion level 3 during the measurement interval. This total time is obtained by summing the time duration of each individual level 3 link congestion event. A level 3 link congestion event begins when the level 3 congestion onset threshold is first reached or exceeded, or at the start of the measurement interval if the link is already at congestion level 3. The level 3 congestion event ends when one of the following occurs: (1) the occupancy first falls below the level 3 congestion abatement threshold, or (2) the measurement interval ends. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 5. Event Count for Entering Level 1 Link Congestion

… Number of times congestion level 1 was entered. Congestion level 1 is entered when the link was previously not congested, and the link transmit buffer occupancy at a given scan reaches or exceeds the level 1 congestion onset threshold, but does not reach or exceed the congestion onset threshold for levels 2 or 3. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)


4–79


GR-2878-CORE

… Number of times congestion level 2 was entered. Congestion level 2 is entered when the link was previously not congested or congested at level 1, and the link transmit buffer occupancy at a given scan reaches or exceeds the level 2 congestion onset threshold, but does not reach or exceed the congestion onset threshold for level 3. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)


… Number of times congestion level 3 was entered. Congestion level 3 is entered when the link was previously not congested or congested at level 1 or 2, and the link transmit buffer occupancy at a given scan reaches or exceeds the level 3 congestion onset threshold. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)

… 8. Priority 0 MTP3 Messages Discarded Due to Congestion

… Number of Priority 0 MTP3 messages discarded due to link transmit congestion at levels 1, 2, or 3. (This HSL measurement replaces the MTP2 link measurement: Priority 0 MSUs Discarded Due to Congestion. However, the two measurements are equivalent.)


… Number of Priority 1 MTP3 messages discarded due to link transmit congestion at levels 2 or 3. (This HSL measurement replaces the MTP2 link measurement: Priority 1 MSUs Discarded Due to Congestion. However, the two measurements are equivalent.)


… Number of Priority 2 MTP3 messages discarded due to link transmit congestion at level 3. (This HSL measurement replaces the MTP2 link measurement: Priority 2 MSUs Discarded Due to Congestion. However, the two measurements are equivalent.)

… 11. Priority 3 MTP3 Messages Discarded Due to Full Transmit Buffer

… Number of Priority 3 MTP3 messages discarded due to a full transmit buffer. (This HSL measurement replaces the MTP2 link measurement: Priority 3 MSUs Discarded Due to Full Transmit Buffer. However, the two measurements are equivalent.)

In the measurements just described, counts of MTP3 messages on HSLs shall generally be equivalent to counts of MSUs on MTP2 links.

Note that as a result of the SAAL replacing MTP2, the following previously defined measurements are no longer strictly applicable, at least from an MTP level 3 perspective:

4–80

ab


— Cumulative Duration of Far-End Processor Outage (based on receipt of SIPO LSSUs)

— Cumulative Duration Status Indication “Busy” LSSUs Received.

However, comparable SAAL-level five-minute measurements applicable to HSLs are defined in Section 4.5.1.4.

R4-92 [144] STPs supporting both HSLs and MTP2 links shall additionally provide the following MTP level 3 performance measurements on a five-minute interval:


… The number of SS7 (MTP3) messages discarded because they exceeded the 272-octet message size limit for MSUs on an MTP2 link

… 1. On a per-link basis for all MTP2 links, on an exception basis only (i.e., only when non-zero)

… 2. Summed across all MTP2 links at the STP on a system-total basis, for each interval, regardless of the measurement value.

O4-93 [211] It is an objective that STPs supporting HSLs should additionally collect and report on demand the following five-minute MTP level 3 traffic counts on a per-link set basis, for all link sets containing HSLs, regardless of the measurement values:

… 1. MTP3 Messages Transmitted

… The number of MTP Level 3 (MTP3) messages submitted to the SAAL for transmission to the far end, including those for which retransmissions of SSCOP SD PDUs may have been necessary. Note that SSCOP retransmissions are not included in this count. (Replaces MSUs Transmitted [Including Retransmissions], which is applicable only to MTP2 links.)

… 2. MTP3 Messages Received

… The number of MTP3 messages received from the far end. (Replaces MSUs Received, which is applicable only to MTP2 links.)

… 3. MTP3 Message Octets Transmitted

… The number of octets comprising MTP3 messages submitted to the SAAL for transmission to the far end, excluding additional octets added by the SAAL and ATM layers. Note that SSCOP retransmissions are not included in this count. (Replaces MSU Octets Transmitted [including Retransmissions], which is applicable only to MTP2 links.)

4–81


GR-2878-CORE

… 4. MTP3 Message Octets Received

… The number of octets associated with MTP3 messages received from the far-end, excluding additional octets added by the SAAL and ATM layers. (Replaces MSU Octets Received, which is applicable only to MTP2 links.)

4.5.1.3 SAAL-Level Performance Measurements: Daily and Marginal

Similar daily and marginal measurements shall be collected at the SAAL for each HSL. In the HSL protocol stack, it is the SAAL, rather than MTP level 2, that is responsible for the establishment of the signaling link connection, link-level error detection and retransmission, and both alignment and in-service error-monitoring. Its functions shall include CRC checks on received SSCOP protocol data units (PDUs), and the retransmission of applicable PDUs, known as SSCOP Sequenced Data (SD) Protocol Data Units (SD PDUs), which shall contain the MTP3 messages as user data. The SAAL’s Layer Management (LM) function (or entity) monitors and supervises several of these functions through event indications received from and sent to the SSCF-NNI and SSCOP sublayers of the SAAL. LM shall be responsible for detecting and counting events concerning such protocol abnormalities and reporting both events and measurements to the System Management (SM) function at the CCS node, which shall in turn be responsible for making them available to external management systems (i.e., operations systems) or users via the CCS node’s operations interfaces. The performance measurements to be routinely collected for HSLs at the SAAL level shall address protocol abnormalities experienced at the SSCOP sublayer, including SSCOP SD PDU retransmissions and errored SSCOP PDUs received, and the loss and resynchronization of SSCOP connections. The errored PDUs include unexpected PDUs, invalid PDUs (as defined in SSCOP) and PDUs with sequence number errors or list-element errors.

The SSCOP monitoring functions shall count and threshold such abnormalities. Threshold crossings for key measurements shall indicate marginal link performance and shall be reported by the CCS node to management systems through operations interfaces. (See also Section 4.5.2.1.) In most cases, the abnormalities described in this section are communicated to layer management through an MAA-ERROR indication. A list of the error codes can be found in Appendix 1 of the SSCOP standards documents ITU Q.2110[9] and ANSI T1.637.[6]

Most of the counter data defined in the following requirements are a subset of those applicable to ATM NE signaling channels, as defined in GR-1248-CORE,[25] Section 14.3.4 (SSCOP/SSCF Performance Management Requirements: Performance Monitoring).

R4-94 [145] SSCOP Connection Monitoring Counters . The CCS Node shall count and threshold the following SSCOP protocol monitoring events at the receive side of each HSL’s SSCOP signaling connection.

4–82

ab


… 1. SSCOP Connection Sum-of-Errors Counter. The CCS node shall count and threshold a sum of errors counter that is incremented when any of the following events occurs. In addition, the CCS node shall individually count each of those events.

… 2. SSCOP Connection Disconnect. The abnormal occurrence of this event is characterized by the expiry of Timer_NO_RESPONSE. This event is communicated to layer management with MAA-ERROR code P.

… 3. SSCOP Connection Initiation Failure. This condition indicates the inability to establish an SSCOP connection. This event occurs whenever the number of expiries of the connection control Timer_CC exceeds MaxCC or upon receipt of a connection reject message BGREJ PDU. This event is communicated to layer management with MAA-ERROR code O.

… 4. SSCOP Connection Re-establishment/Resynchronization. This event occurs upon receipt of an SSCOP BGN PDU or RESYNC PDU.

R4-95 [146] SSCOP Errored PDUs Counters . The CCS Node shall count and threshold the following SSCOP PDU errors at the receive side of each HSL’s SSCOP signaling connection.

… 1. SSCOP Errored PDUs Sum-of-Errors Counter. The CCS node shall count and threshold a sum of errors counter that is incremented when any of the following PDU errors are detected. In addition, the CCS node shall individually count each of those PDU errors.

… 2. Unexpected SSCOP PDUs. The receipt of unsolicited or inappropriate PDUs as conveyed by MAA-ERROR indications with error codes A through M.

… 3. Invalid SSCOP PDUs. These are defined in SSCOP and consist of PDUs with incorrect length (MAA-ERROR code U), undefined PDU type codes, or PDUs not 32-bit aligned.

… 4. SSCOP PDUs with Other/List Element Errors (Errors Q-T). These include PDU N(S), N(PS), N(R) errors, or list elements errors in STAT/USTAT PDUs. These events are communicated to layer management with MAA-ERROR codes Q through T.

R4-96 [147] SSCOP SD PDUs Transmitted Requiring Retransmission. The CCS node shall count and threshold at the transmit side of each HSL’s SSCOP signaling connection, the number of SSCOP SD PDUs transmitted that required retransmission because they were not acknowledged by the far-end’s SSCOP peer. It shall obtain this count by accumulating the count

4–83


GR-2878-CORE

parameter of MAA-ERROR indication signals of type “V” (SD loss), which are sent to the HSL’s SAAL Layer Management function by SSCOP.

R4-97 [148] Accumulation and Reporting. For its SAAL-based HSLs, the CCS node shall support the collection and reporting of the following SAAL-level link performance measurements (based on the above counter definitions), on a per-link basis, for the indicated accumulation and reporting intervals: daily [d] and/or marginal [m]:

… 1. SSCOP SD PDUs Transmitted Requiring Retransmission [d, m]

… (This measurement replaces Number of Negative Acknowledgments Received, which is applicable only to MTP2 links.)

… 2. Hourly Marginal Performance Thresholds Exceeded for SSCOP SD PDUs Transmitted Requiring Retransmission [d]

… 3. SSCOP Connection Disconnects [d, m]

… 4. SSCOP Connection Initiation Failures [d, m]

… 5. SSCOP Connection Reestablishments/Resynchronizations [d, m]

… 6. SSCOP Connection Sum-of-Errors Counter [d, m]

… 7. Hourly Marginal Performance Thresholds Exceeded for SSCOP Connection Sum-of-Errors Counter [d]

… 8. Unexpected SSCOP PDUs Received [d, m]

… 9. Invalid SSCOP PDUs Received [d, m]

… 10. SSCOP PDUs Received with Other/List Element Errors [d, m]

… 11. SSCOP Errored PDUs Sum-of-Errors Counter [d, m]

… 12. Hourly Marginal Performance Thresholds Exceeded for SSCOP Errored PDUs Sum-of-Errors Counter [d].


4.5.1.4 SAAL-Level Performance Measurements: 5-Minute

R4-98 [149] For its SAAL-based HSLs the CCS node shall support the collection and reporting of the following SAAL-level link performance measurements, on a per-link basis. A report containing these measurements shall be generated at the end of the first and each successive five-minute interval during which the respective measurements are non-

4–84

ab


zero. Zero-valued link measurements shall not be reported and shall be inferred as such by their absence on five-minute measurement reports.

… 1. Signaling Link Alignment Failures

… The number of times Layer Management (LM) received a MAAL-REPORT.indication signal conveying “Alignment Not Successful”, per measurement recommendations in ITU Q.2144.[11]

… 2. Lack-of-Credit Events

… The number of times SSCOP notified LM via an MAA-ERROR.indication signal that it had PDUs to send to its peer but could not do so because it was not given credit by the far end. Each occurrence is indicative of receiving buffer congestion at the far-end resulting in an invocation of level-2 flow control.

… 3. Cumulative Duration of Lack-of-Credit (Far-End Receiving Congestion)

… The cumulative duration of time in seconds during which SSCOP had PDUs to send to its peer but could not do so because it was not given credit by the far end, summed over all Lack-of-Credit events occurring during the measurement interval, as detected by LM via receipt of MAA-ERROR.indication signals from SSCOP. (This measurement replaces the measurement Cumulative Duration of Busy-Link Status Units [SIB LSSUs] Received as an indication of far-end receiving congestion. SIB LSSUs are applicable only to MTP2 links.)

… 4. Cumulative Duration of Far-End Processor Outage

… The cumulative duration in seconds during which the use of the link was precluded due to a remote (far-end) processor outage condition, summed across all far-end processor outage events. Each far-end processor outage event is considered to occur at the time local LM receives a MAAL-REPORT.indication signal from the local SSCF indicating “processor outage.” That indication is generated when the local SSCOP receives an SSCOP END (Disconnect Command) PDU from the far-end SSCOP process with the SSCOP-UU data field conveying “processor outage,” and the link is considered failed. The far-end processor outage event is considered to end when subsequent alignment attempts are initiated by the far-end. In accumulating this duration measurement at the start of a given interval, the CCS node shall include far-end processor outage events detected in prior intervals that are still in progress. (This measurement replaces the measurement “Cumulative Duration of Far-End Processor Outage” for MTP2 links, which is defined as the duration of receipt of SIPO

4–85


GR-2878-CORE

LSSUs from the far-end. SIPO LSSUs are applicable only to MTP2 links.)

… 5. Cumulative Duration of Local Processor Outage

… The cumulative duration in seconds during which the use of the link was precluded due to a local processor outage, summed across all local processor outage events. Each local processor outage event is considered to occur at the time LM issues an MAAL-LOCAL_PROCESSOR_OUTAGE.request signal to the SSCF, based on implementation-specific instructions from system management, and ends when LM issues the MAAL-LOCAL_PROCESSOR_RECOVERED.request signal to the SSCF. In accumulating this duration measurement at the start of a given interval, the CCS node shall include local processor outage events detected in prior intervals that are still in progress.

4.5.1.5 ATM-Level Performance Measurements: Daily and Marginal

Consistent with ATM NE performance management measurement requirements specified in Section 7.1.2.1 of GR-1248-CORE[25] , the CCS node shall be required to collect performance measurements concerning ATM cell discards due to cell header processing errors. These are potentially indicative of deterioration or defects in ATM-level processing equipment, software errors, or translation errors at the far-end node (if applicable). While other measurement intervals are applicable to ATM NEs, CCS nodes shall collect these measurements instead on the traditional daily and marginal basis for each HSL.

R4-99 [150] The CCS node shall collect the following performance measurements regarding incoming ATM cells at the ATM interface of each HSL, on a daily (d) and marginal (m) basis, per measurement definitions specified in GR-1248-CORE,[25] Section 7.1.2.1:

… 1. Number of Cells Discarded Due to Header Error Control (HEC) Violations

… 2. Out of Cell Delineation (OCD) Anomalies

… 3. Number of Cells Discarded Due to Protocol (ATM-Layer Header) Errors.


4–86

ab


4.5.1.6 Physical-Level (DS1) Performance Measurements

R4-100 [151] The CCS node shall support the collection of all scheduled performance measurements and reports applicable to DS1 terminations as specified in GR-820-CORE,[22] Section 4 (DS1 Performance Monitoring).

Generally, such routinely collected transmission performance measurements are not reported to management systems or personnel by NEs unless the NEs are specifically instructed to do so via operations interfaces. There are no routine scheduled DS1 performance reports required for CCS node HSLs at this time. The subset of such measurements applicable to thresholded reports are discussed in Section 4.5.2.3, Exception-Based Facility Monitoring (DS1). The ability of users to schedule and request detailed performance reports for specific links is addressed separately in Section 4.5.3.3, DS1 Level: Scheduling of DS1 Performance Reports.

4.5.2 Exception-Based Performance Monitoring

Exception-based performance monitoring refers to automated performance management capabilities resulting in outputs that are to be generated only on an exception basis, when thresholds are crossed for key performance indicators. Such exception-based reports have been defined for HSLs based on performance monitoring at MTP level 3, the SAAL, and the physical layer (DS1), as described in the following subsections.

4.5.2.1 HSL Marginal Performance Reports

Link marginal performance reports are generated for signaling links whose key performance measurements exceed certain predefined thresholds, suggesting that link performance is “marginal”. For HSLs, marginal performance shall be based on different criteria than those used for MTP2-based links due to differences in level 2 functions and messages.

4.5.2.1.1 Link Marginal Performance Report Criteria

R4-101 [152] The CCS node shall declare marginal performance for a given HSL, and include that HSL on a corresponding hourly Link Marginal Performance Report (MPR), when one or more of the following key performance measurements, generated by performance monitoring functions at MTP level 3 and the SAAL, exceed their hourly marginal performance thresholds:

… 1. Number of Automatic Changeovers

4–87


GR-2878-CORE

… 2. SSCOP SD PDUs Transmitted Requiring Retransmission

… 3. SSCOP Connection Sum-of-Errors Counter

… 4. SSCOP Errored PDUs Sum-of-Errors Counter.

… These measurements are defined in Sections 4.5.1.1 and 4.5.1.3.

R4-102 [153] The CCS node shall enable authorized management systems and users responsible for fault management functions to administer the HSL marginal performance thresholds on at least a per-node basis for all HSLs. In the absence of management input, the CCS node shall default to appropriate implementation-specific default values for these parameters.

O4-103 [212] It is an objective that the CCS node allow authorized management systems and users responsible for fault management functions to administer the values of the indicated HSL marginal performance thresholds for groupings of HSLs mapped to Link Parameter Sets (LPSs), where the LPSs are created by configuration management/memory systems or interfaces per O4-18 [210]. The per-LPS threshold values should take precedence over any configured per-node values administered per R4-102 [153].

O4-104 [213] It is an objective that the CCS node allow authorized management systems and users responsible for fault management functions to additionally administer the values of the indicated HSL marginal performance thresholds a per-link-set basis. The per-link-set threshold values should take precedence over any configured per-LPS values administered per O4-18 [210] and O4-103 [212], and any configured per-node values administered per R4-102 [153].

See also Section 4.2.6 regarding the HSL NE’s administration of these parameters as part of the Link Parameter Sets maintained by the Configuration Management function. Appendix E discusses additional considerations for the setting of the HSL marginal performance thresholds by the user and the establishment of suitable implementation-specific default values for the HSL NE.

4.5.2.1.2 HSL Marginal Performance Report Content

R4-105 [154] When a HSL appears on the MPR for a given hour, all scheduled measurements whose measurement interval is defined as “marginal” under the scheduled performance measurement requirements in Section 4.5.1 shall be included in the MPR, not only those measurements whose values exceeded the marginal thresholds. Those specific measurements that

4–88

ab


exceeded the hourly marginal performance thresholds for the HSL shall be so indicated within the MPR along with the threshold values.

4.5.2.2 HSL Threshold Crossing Alerts (TCAs)

A threshold crossing alert is an event report generated immediately (on occurrence) whenever a key performance indicator or measurement for a network element or component crosses a predefined threshold for that measurement.

Two specific TCA event reports have been identified for HSL performance management as defined in the following. These include

• Link Marginal Performance TCA (Section 4.5.2.2.1)

• MTP Level 3 Link Transmit Congestion TCA (Section 4.5.2.2.2).

4.5.2.2.1 Link Marginal Performance TCA

R4-106 [155] The CCS node shall generate immediately upon occurrence a threshold crossing alert (TCA) at the point in time at which any of the indicated hourly link marginal performance thresholds for the key performance indicators defined in R4-101 [152] is first crossed within any given hour. Each associated TCA shall contain, at a minimum, a timestamp, the signaling link identifier, and the identifier and value of the counter exceeding the marginal performance threshold.

4.5.2.2.2 MTP Level 3 Link Transmit Congestion TCA

R4-107 [156] As part of its performance-management functions for HSLs, the CCS node shall generate immediately upon occurrence, event reports conveying threshold crossing alerts (TCAs) for all link transmit congestion events, including the initial onset of congestion and all subsequent changes in transmit congestion level as indicated by crossings of the onset, discard, and abatement thresholds for congestion levels 1, 2, and 3.

… 1. The event reports shall be the same as those used for MTP2 links.

… 2. The congestion event reports shall provide the value of the thresholds crossed, including the their units, with MTP3 messages or MTP3 message octets replacing the threshold units of MSUs or MSU octets applicable to MTP2 links.

Measurements of link transmit congestion events (counts and durations) are separately addressed in Sections 4.5.1.2 and 4.6.1.1.

4–89


GR-2878-CORE

4.5.2.2.3 Reporting of TCAs

R4-108 [157] The CCS node shall transmit the indicated TCAs as event reports over the following operations interfaces:

… a. The CCS node’s Maintenance OS interface (i.e., the “maintenance channel”)

… b. The CCS node’s local User System Interface (USI).

… These are subject to any filtering or thresholding at the CCS node for those messages as may be defined for the CCS node implementation of those interfaces.

4.5.2.3 Exception-Based Facility Monitoring (DS1)

Standard performance monitoring requirements for DS1 ESF facility terminations shall apply, consistent with performance monitoring requirements stated for ATM NE DS1 interfaces in GR-1248-CORE,[25] Section 7.1.1.1 (Facility Monitoring of ATM Over DSn). Specifically, the following requirement applies.

R4-109 [158] For each HSL’s DS1 interface, the CCS node shall support all exception-based (thresholded) ESF DS1 performance monitoring functions as requirements or objectives, as defined in GR-820-CORE,[22] Section 4 (DS1 Performance Monitoring), specifically Section 4.7.5 (DS1 Thresholding Criteria) and Section 4.7.6 (Default Values for DS1 Rate Thresholds).

4.5.3 Management-Initiated Performance Monitoring

Management-initiated performance monitoring refers to those PM and report generation functions initiated on a selective basis for specified network components - in this case, HSLs - at the request of management systems and personnel. Such functions may be regarded as too resource-intensive or not of sufficient importance to perform continuously on a global basis for all HSLs, but are considered useful when applied to specific links for which performance problems have been detected. Requirements and objectives are presented for three such PM features in the indicated sections:

• At the SAAL level: SSCOP PDU Data Capture (4.5.3.1)

• At the ATM-layer: Use of F5 Performance Monitoring OAM Cells (4.5.3.2)

• At the DS1 level: Scheduling of DS1 Performance Reports (4.5.3.3).

4–90

ab


4.5.3.1 SAAL-Level: SSCOP PDU Data Capture

O4-110 [159] It is an objective that the CCS node support the SSCOP Protocol Data Capture feature, which shall provide for the trapping of SSCOP PDUs on management-selected HSLs, consistent with requirements for this function as defined for ATM NE signaling channels in GR-1248-CORE,[25] Section 14.3.4.2.

Due to the potentially resource-intensive nature of this function, it is currently cited as an objective, rather than a requirement. It is intended for use as a trouble-shooting tool when SAAL-level performance problems are indicated for a given HSL.

4.5.3.2 ATM-Level: Use of F5 Performance Monitoring OAM Cells

At the ATM layer, active performance management functions provided through OAM cells allow users to collect detailed error statistics on lost and errored ATM cells at each end of an ATM VCC. Such capabilities may be useful in performance analysis of each HSL’s ATM connection.

O4-111 [160] It is an objective that the CCS node support, via the USI and via the operations interface from the Maintenance OS (i.e., the management system responsible for maintenance-oriented performance management), the initiation of ATM VCC Performance Monitoring functions supporting the collection and reporting of detailed ATM-layer performance measurements for selected HSLs.

… a. Specifically, the applicable functionality is that based on ATM connection (VC) F5 Performance Monitoring via OAM cells as defined for ATM NEs in GR-1248-CORE,[25] Section 7.1.3 (VP/VC Performance Monitoring). This measurement capability is contingent upon the CCS node’s support of the prerequisite ATM operations flows per the objectives cited in Section 4.3.2 (ATM-Layer Operations Flows).

… b. Users should be able to activate monitoring at the near-end, the far-end, or both, subject to the node’s support of the ATM OAM operations flows for remote activation and deactivation of performance monitoring per the objectives cited in Section 4.3.2 (ATM-Layer Operations Flows).

… c. The CCS node should be capable of collecting and reporting the indicated VC performance measurements cited in GR-1248-CORE,[25] Section 7.1.3.2.2, Table 7-7 for user-selected HSLs, for the indicated measurement intervals.

4–91


GR-2878-CORE

Due to the complexity of these procedures at the ATM interface and their prerequisite ATM-layer operations flows, their resource-intensive nature, and the number of measurements involved, these additional measurement capabilities are cited as an objective rather than a requirement for the CCS node at this time. For the same reasons, the CCS node may restrict the number of HSLs for which this performance monitoring measurement function may be active simultaneously.

The incremental value of these measurements may be lessened by the fact that extensive measurements are already required at the SAAL and DS1 levels for link performance along with selected measurements of ATM-layer anomalies. Also, there shall be no bandwidth contention among VCCs, since only a single VCL termination shall be supported for the DS1 rate HSL, so that cell loss due to priority discards are not expected to occur.

4.5.3.3 DS1 Level: Scheduling of DS1 Performance Reports

R4-112 [161] The CCS node shall allow users, via the USI and via the operations interface from the Maintenance OS (i.e., the management system responsible for fault management), to schedule the generation of detailed DS1 performance reports for selected HSLs, per DS1 performance measurement requirements specified in GR-820-CORE,[22] Section 4, and common transmission parameter reporting and retrieval requirements specified in GR-820-CORE,[22] Section 3.4.

R4-113 [162] It shall be possible for users to initiate the indicated performance monitoring and report generation functions at the indicated operations interfaces for any of the CCS node’s equipped and active DS1 ports, prior to their assignment to CCS HSLs, so as to support facility validation prior to turn-up of the HSLs. This implies that users shall be able to select equipped but unassigned DS1 Equipment Port Identifiers at the CCS node for which to generate performance reports in addition to their ability to select the Link IDs of already configured HSLs.

4.6 Network Data Collection (NDC)

The Network Data Collection (NDC) operations domain refers to the ongoing scheduled collection of traffic and performance measurement data needed to support both long-term network engineering and planning, as well as ongoing short-term network traffic and capacity monitoring functions commonly associated with traditional Network Administration activities (e.g., “network servicing” to prevent short-term capacity exhaust, or the calculation of network performance indices). Measurements for this domain have historically been collected from network elements on a 30-minute, 15-minute, or hourly basis, for use in busy-hour or busy-period analysis. Thirty minutes is the principal

4–92

ab


accumulation and reporting interval currently specified in CCS node generic requirements for the NDC domain. It shall continue to be required at CCS nodes for HSLs14.

For MTP2 links, traffic measurements used in link engineering are made in units of MSUs and MSU octets, including octets added and used by MTP level 2 procedures, since the octet stream is mapped directly onto DS0 frame payloads. Link occupancy can be computed directly from the MSU octet loads compared against the maximum physical data rate in octets (at 56-Kb/s) supported on the link.

For HSLs, however, MSUs no longer apply. MTP3 messages and message octets can still be measured (which of course no longer contain the former MSU message fields that would be added by MTP level 2). However, such counts are not indicative of the total octet load submitted to the DS1 transmission link. This is because significant overhead is added when the MTP3 messages are submitted down the protocol stack. Additional header octets are added when each MTP3 message is encoded as user information and padded out to a 4-octet multiple within an SSCOP Sequenced Data (SD) PDU. Further header octets are added when each SSCOP SD PDU is in turn encoded as user data and padded out to a 48-octet multiple in an AAL CP5 PDU. Still further overhead octets are added when each AAL CP5 PDU is segmented into 48-octet ATM cell payloads and the 5-octet header is added to each ATM cell before transmission. The percentage of overhead added is not fixed, but rather is dependent on the size of each MTP3 message submitted to the SAAL for transmission. On average, overhead will be dependent on the average message size and the distribution of message sizes in the traffic mix handled by each link. In addition, the SSCOP sublayer itself has additional PDU types (such as STATs and USTATSs) supporting level 2 flow control, SSCOP connection management, and other link layer functions. The ATM layer also supports OAM cells for fault and performance management. Although their contribution is proportionally small, these messages also use part of the available bandwidth. Therefore, the total occupancy of a HSL must ultimately be measured in terms of the number of ATM cells carrying “user information” (i.e., signaling information and SAAL overhead) and ATM OAM information per unit time. These measures may then be compared to the total available cell rate of approximately 3622 cells per second at 1.536-Mb/s, to determine actual resulting link occupancy.

Link engineering methods for HSLs are likely to be based, at least in part, on such ATM-cell-based link occupancy measurements. Additional considerations may involve the capacity of involved CCS node processors to handle the involved SAAL PDUs, PDU octets, MTP3 messages, and MTP3 message octets at the higher levels of the protocol stack.

Because of this, the strategy used here for HSL NDC is essentially to measure the link traffic on several levels: at MTP level 3, so as to determine the message rates, message sizes, and octet loads generated by the MTP’s user parts; at the SAAL level, to determine the effective traffic at level 2; and at the ATM-cell level, to measure directly the resulting

14. Shorter measurement intervals or extreme-value statistics have been proposed as alternatives to the 30-minute accumulation interval for CCS nodes. These remain under study and may be stated as requirements or objectives in the future.

4–93


GR-2878-CORE

link occupancy when the MTP3 message traffic plus the overhead from all the layers of the protocol stack are considered. The following subsections describe measurements required at each of these levels on both a per-link and a per-link-set basis for HSLs.

4.6.1 MTP Level 3 Link Traffic and Performance Measurements (30 Minute)

At MTP level 3, the CCS nodes shall be required to collect principally the same measurements previously collected for conventional MTP2-based links, with the exception that measurements of MSUs and MSU octets shall now be replaced with measurements of equivalent MTP3 messages and MTP3 message octets. Some of these measurement definitions are subtly changed relative to those of MTP2 links due to the exclusion of message octets formerly used by MTP level 2 functions, and the exclusion of retransmitted messages from the indicated counts. This is due to the fact that level 2 error detection and retransmission are SAAL functions (supported by the AAL CP5 and SSCOP, respectively), and cannot be directly discerned by MTP level 3. Analogous measurements of level 2 activity are instead provided at the SAAL-level as discussed separately in Section 4.6.2. Other measurement definitions are unchanged relative to their definitions used for MTP2-based links because they deal entirely with MTP level 3 functions.

Several measurement definitions provided here are the same as those provided for corresponding performance measurements cited in Section 4.5.1 (Scheduled Link Performance Measurements), and differ only in terms of their accumulation interval.

Existing definitions for some measurements common to both HSLs and MTP2 links may also be found in the STP GR, GR-82-CORE,[12] Section 6.4.4. (The relationships between the required HSL measurements and, where applicable, their MTP2 link analogs, are cited in italicized text within parenthesis.)

4.6.1.1 MTP3 Link Measurements

R4-114 [163] The CCS node shall support the collection of the following MTP3 measurements every 30 minutes on a per-link basis for all HSLs.


… The number of MTP Level 3 (MTP3) messages submitted for transmission to the far end, including those for which retransmissions of SSCOP SD PDUs may have been necessary. Note that SSCOP retransmissions are not included in this count. (Replaces MSUs Transmitted [including Retransmissions], which is applicable only to MTP2 links.)


4–94

ab


… The number of MTP3 messages received from the far end. (Replaces MSUs Received, which is applicable only to MTP2 links.)


… The number of octets comprising MTP3 messages submitted for transmission to the far-end, excluding additional octets added by the SAAL and ATM layers. Note that SSCOP retransmissions are not included in this count. (Replaces MSU Octets Transmitted [including Retransmissions], which is applicable only to MTP2 links, and which includes MTP2 octets.)


… The number of octets associated with MTP3 messages received from the far-end, excluding additional octets added by the SAAL and ATM layers. (Replaces MSU Octets Received, which is applicable only to MTP2 links, and which includes MTP2 octets.)

… 5. Link Maintenance Usage

… The total time the link was manually made unavailable to MTP level 3 user part message traffic during the measurement interval, including management-inhibit (local or remote), deactivation, or other manual removal from service as discerned at the reporting CCS node. (This measurement shall be common to both HSLs and MTP2 links.)

… 6. Duration of Link Outage

… The total time the link was unavailable to MTP level 3 user part message traffic during the measurement interval, regardless of the outage cause or whether the outage resulted from manual or automatic actions. (This measurement shall be common to both HSLs and MTP2 links.)

… 7. MTP3 Messages Received Requiring GTT (STPs only)

… The number of incoming MTP3 messages requiring GTT, regardless of the outcome of any gateway screening. (This measurement shall be common to both HSLs and MTP2 links.)

… 8. MTP3 Message Octets Received for Messages Requiring GTT (STPs only)

… The number of MTP3 message octets associated with MTP3 messages received that required GTT, excluding octets removed in level 2 (SAAL) processing. (Replaces MSU Octets Received for Messages Requiring GTT, which is applicable only to MTP2 links, and which includes MTP2 octets.)

4–95


GR-2878-CORE

… 9. Average Link Transmit Buffer Occupancy (MTP3 messages or MTP3 message octets)

… This measurement requires that the link transmit buffer occupancy (either in MTP3 messages or MTP3 message octets, subject to the CCS node’s implementation of link transmit congestion thresholds) be sampled at regular scanning intervals. The measurement is made by summing the occupancy values obtained in each sample and dividing it by the number of samples made. (This measurement is common to both HSLs and MTP2 links, however, the units for HSLs differ from those used for MTP2 links, which are based on either MSUs or MSU octets, and which are assumed to include octets added by MTP2.)

… (Because link transmit congestion occurs infrequently and generally over short intervals relative to the length of the measurement interval, this measurement is often close to zero, due to the diluting effects of the computed average, and its usefulness has been questioned for signaling links in general. The following measurement has been added to provide a potentially more useful indication of link transmit buffer occupancy).

… 10. Peak Link Transmit Buffer Occupancy (MTP3 messages or MTP3 message octets)

… The highest observed link transmit buffer occupancy recorded over successive scans during the measurement interval (either in units of MTP3 messages or MTP3 message octets, subject to the CCS node’s implementation of link transmit congestion thresholds). (This measurement is cited specifically for HSLs and has no current MTP2 analog. Except for its units, which are in MTP3 messages or MTP message octets, rather than MSUs and MSU octets, it is equally applicable to MTP2-based links.)



4–96

ab





… The total time the link was in congestion level 3 during the measurement interval. This total time is obtained by summing the time duration of each individual level 3 link congestion event. A level 3 link congestion event begins when the level 3 congestion onset threshold is first reached or exceeded, or at the start of the measurement interval if the link is already at congestion level 3. The level 3 congestion event ends when one of the following occurs: (1) the occupancy first falls below the level 3 congestion abatement threshold, or (2) the measurement interval ends. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)


… Number of times congestion level 1 was entered. Congestion level 1 is entered when the link was previously not congested, and the link transmit buffer occupancy at a given scan reaches or exceeds the level 1 congestion onset threshold, but does not reach or exceed the congestion onset threshold for levels 2 or 3. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)


… Number of times congestion level 2 was entered. Congestion level 2 is entered when the link was previously not congested or congested at level 1, and the link transmit buffer occupancy at a given scan reaches or exceeds the level 2 congestion onset threshold, but does not reach or exceed the congestion onset threshold for level 3. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)


4–97


GR-2878-CORE

… Number of times congestion level 3 was entered. Congestion level 3 is entered when the link was previously not congested or congested at level 1 or 2, and the link transmit buffer occupancy at a given scan reaches or exceeds the level 3 congestion onset threshold. (This measurement shall be common to both SAAL-based HSLs and MTP2 links.)


… Number of Priority 0 MTP3 messages discarded due to link transmit congestion at levels 1, 2, or 3. (This HSL measurement replaces the MTP2 link measurement: Priority 0 MSUs Discarded Due to Congestion. However, the two counts are equivalent.)


… Number of Priority 1 MTP3 messages discarded due to link transmit congestion at levels 2 or 3. (This HSL measurement replaces the MTP2 link measurement: Priority 1 MSUs Discarded Due to Congestion. However, the two counts are equivalent.)


… Number of Priority 2 MTP3 messages discarded due to link transmit congestion at level 3. (This HSL measurement replaces the MTP2 link measurement: Priority 2 MSUs Discarded Due to Congestion. However, the two counts are equivalent.)

… 20. Priority 3 MTP3 Messages Discarded Due to Full Transmit Buffer

… Number of Priority 3 MTP3 messages discarded due to a full transmit buffer. (This HSL measurement replaces the MTP2 link measurement: Priority 3 MSUs Discarded Due to Full Transmit Buffer. However, the two counts are equivalent.)

… 21. Average Link Output Delay for Sampled MTP3 Messages

… For HSLs, link output delay is defined as the time from when an MTP3 message is first placed in the signaling link’s output controller buffer until its last bit is handed off to the SSCF for transmittal. This measurement requires that the link output delay of an MTP3 message be sampled every 10 seconds, totaled over the measurement interval, and divided by the number of such samples to form the reported average. (An analogous measure of link output delay is required for MTP2-based 56-Kb/s links, but is based instead on the sum of queuing delay and emission time of sampled MSUs as measured at MTP level 2.)

… 22. Number of MTP3 Messages Sampled for Link Output Delay

4–98

ab


… The number of MTP3 messages sampled for link output delay over the measurement interval. (An analogous measure of MSUs sampled for link output delay is required for MTP2-based 56-Kb/s links.)

R4-115 [164] STPs supporting both HSLs and MTP2 links shall additionally provide the following MTP-level-3 measurement on a 30-minute accumulation interval:


… The number of SS7 (MTP3) messages discarded because they exceeded the 272-octet message size limit for MSUs on an MTP2 link

… 1. On a per-link basis for all MTP2 links

… 2. Summed across all MTP2 links on a system-total basis.

4.6.1.2 MTP3 Link Set Measurements

R4-116 [165] The CCS node shall support the collection of the following MTP3 measurements every 30 minutes on a per-link set basis for all link sets containing HSLs. (For those measurements where the definition has been omitted, the supplier shall utilize the measurement definitions provided for measurements of the same name required for individual HSLs, as defined in Section 4.6.1.1, except that the following measurements shall be aggregated across all HSLs in the link set).





… 5. MTP3 Messages Received Requiring GTT (STPs only)

… 6. MTP3 Message Octets Received for Messages Requiring GTT (STPs only)

… 7. Total Duration of Link Set Inactivity (Link Set Outage).

… The total time that all links in the link set were simultaneously unavailable to MTP level 3 user part message traffic (i.e., the duration of link set outage), regardless of whether individual links were failed or made manually unavailable. (This measurement shall be common to both SAAL-based HSL link sets and MTP2-based link sets.)

(See the additional requirements concerning mixed HSL/MTP2 link sets in Section 4.6.4.)

4–99


GR-2878-CORE

4.6.2 SAAL-Level Measurements: 30-minutes

4.6.2.1 SAAL-Level Link Measurements

R4-117 [166] The CCS node shall support the collection of the following SAAL-level measurements every 30 minutes on a per-link basis for all HSLs:

… 1. Duration in the In-Service State

… The number of seconds the link is regarded in service (at level 2) by SAAL LM based on its perception of the link’s SCCF alignment status, per LM state definitions provided in ITU Recommendation Q.2144[11], Section 8.2, Table 4/Q.2144. In this state the link is not necessarily available to user part message traffic as perceived by MTP level 3.

… 2. Signaling Link Alignment Failures

… The number of times Layer Management (LM) received a MAAL-REPORT.indication signal conveying “Alignment Not Successful”, per measurement recommendations in ITU Q.2144, Section 8.2, Table 4/Q.2144.[11]

… 3. SSCOP SD PDUs Transmitted

… The number of SSCOP Sequenced Data (SD) PDUs that were transmitted during the indicated interval (including retransmissions).

… 4. SSCOP SD PDUs Retransmitted

… The number of SSCOP SD PDUs that were retransmitted during the indicated interval, based on an accumulated count of such retransmissions as conveyed to LM in MAA-ERROR indication signals of type “V” (SD loss) sent from SSCOP.

… 5. SSCOP SD PDU Octets Transmitted

… The number of octets associated with SSCOP SD PDUs transmitted during the indicated interval (including retransmissions).

… 6. SSCOP SD PDU Octets Retransmitted

… The number of octets associated with SSCOP SD PDUs retransmitted during the indicated interval.

… 7. SSCOP SD PDUs Received

… The number of SSCOP SD PDUs that were received during the indicated interval.

4–100

ab


… 8. SSCOP SD PDU Octets Received

… The number of octets associated with SSCOP SD PDUs received during the indicated interval.

… 9. Total SSCOP PDUs Transmitted

… The number of SSCOP PDUs of all types that were transmitted during the indicated interval (including SD PDU retransmissions).

… 10. Total SSCOP PDUs Received

… The number of SSCOP PDUs of all types that were received during the indicated interval.

… 11. Total SSCOP PDU Octets Transmitted

… The number of octets associated with SSCOP PDUs of all types that were transmitted during the indicated interval (which may include SD PDU retransmissions).

… 12. Total SSCOP PDU Octets Received

… The number of octets associated with SSCOP PDUs of all types that were received during the indicated interval.

4.6.2.2 SAAL-Level Link Set Measurements

R4-118 [167] The CCS node shall support the collection of the following SAAL-level measurements every 30 minutes on a per-link-set basis for all link sets containing HSLs. (For those measurements where the definition has been omitted here, the supplier shall utilize the measurement definitions provided for measurements of the same name required for individual HSLs, as defined in Section 4.6.2.1, except that the following measurements shall be aggregated across all HSLs in the link set.)

… 1. SSCOP SD PDUs Transmitted

… 2. SSCOP SD PDUs Retransmitted

… 3. SSCOP SD PDU Octets Transmitted

… 4. SSCOP SD PDU Octets Retransmitted

… 5. SSCOP SD PDUs Received

… 6. SSCOP SD PDU Octets Received

… 7. Total SSCOP PDUs Transmitted

… 8. Total SSCOP PDUs Received

4–101


GR-2878-CORE

… 9. Total SSCOP PDU Octets Transmitted

… 10. Total SSCOP PDU Octets Received.

4.6.3 ATM-Cell Traffic Measurements: 30-Minutes

4.6.3.1 ATM-Level Link Measurements

R4-119 [168] The CCS node shall support the collection of the following ATM-cell measurements every 30 minutes on a per-link basis for all HSLs. The measurements to be provided are a subset of those specified for ATM NE VCLs in GR-1248-CORE,[25] Section 8.2.1 (Traffic Load Measurements for Interfaces and VPL/VCLs) and Section 8.2.4, Table 8-1 (NDC Scheduled Measurements).

… 1. Total incoming (received) NDC-valid ATM cells on the HSL’s VCL

… 2. Total outgoing (transmitted) NDC-valid ATM cells on the HSL’s VCL

… 3. Total incoming (received) ATM user-information (UI) cells

… 4. Total outgoing (transmitted) ATM user-information (UI) cells.

… Note that NDC-valid cells include all UI and OAM cells, but exclude idle (unassigned) cells carried on the HSLs ATM VCL.

4.6.3.2 ATM-Level Link Set Measurements

R4-120 [169] The CCS node shall support the collection of the following ATM-cell measurements every 30 minutes on a per-link-set basis for all link sets containing HSLs. The measurement definitions are the same as those used for ATM-level link measurements as defined in Section 4.6.3.1, except that the following measurements shall be aggregated across all HSLs in the link set.

… 1. Total incoming (received) NDC-valid ATM cells on the HSL’s VCL

… 2. Total outgoing (transmitted) NDC-valid ATM cells on the HSL’s VCL

… 3. Total incoming (received) ATM user-information (UI) cells

… 4. Total outgoing (transmitted) ATM user-information (UI) cells.

4–102

ab


4.6.4 Additional Measurement Requirements

R4-121 [170] The collection of the HSL measurement data shall not in any way change or impact the definitions of link measurements or link set measurements collected for 56-Kb/s MTP2-based signaling links at the CCS node. That is, traffic measurements in units of MSUs and MSU octets are to continue to be collected for those MTP2 links and link sets. Link and link set measurements of MTP3 messages and MTP3 message octets are to be collected for SAAL-based HSLs and HSL link sets only.

R4-122 [171] Traffic measurements in units of MSUs and MSU octets, and MTP3 messages and MTP3 octets collected for individual signaling links and link sets, shall be treated as separate measurement types in all CCS node measurement reports and shall be identified by distinct measurement names and register labels.

R4-123 [172] During transition periods where HSLs and MTP2-based links reside in the same link sets, HSL measurements of MTP3 messages and MTP3 message octets shall not be aggregated with MTP2-based link measurements of MSUs and MSU octets to form link set totals. Instead, separate totals for each distinct measurement type shall be aggregated for the respective types of signaling links and both sets of measurements shall be reported for the link set.

R4-124 [173] At CCS nodes supporting both HSLs and MTP2-based links, when other, higher-level, measurements of SS7 messages (not octets) are collected at MTP level 3 and on a system-total or per-equipment-unit basis, where such measurements are currently defined in units of MSUs (based on the prior assumption that the node supports all MTP2-based links), the CCS node shall aggregate counts of MTP3 messages with MSU counts for messages received on different links to obtain those system or equipment unit message totals, as necessary. That is, the CCS node shall recognize the equivalence of MTP3 message counts and MSU counts when considered on a node or equipment unit basis. For convenience, the current nomenclature of units in MSUs for such measurements shall be retained.

For example, system-total measurements of MSUs originated, terminated, and through-switched are currently required at STPs. The measurement definition may be regarded as a misnomer, because MSUs are technically an MTP-level 2 PDU. To support the collection of such system totals in the future at STPs with both HSLs and MTP2 links, the STP shall aggregate counts of MTP3 messages handled on HSLs with counts of MSUs handled on MTP2-based links, and shall retain their current unit nomenclature in MSUs. (Additional information on required STP measurements may be found in GR-82-CORE,[12] Section 6.4.)

4–103


GR-2878-CORE

4–104

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Operations Interface Support

5. Operations Interface Support

CCS nodes supporting HSLs shall be expected to provide for the necessary exchange of required operations data and messages concerning the HSLs over their existing and planned operations interfaces. These interfaces shall include those between each CCS node (i.e., the STP SCP, or CCS SOs/SSPs) and the LEC operations systems (OSs) or management systems supporting each of the indicated network operations domains, as well as the node’s local (and “remoted”) User-System Interfaces (USIs).

This section provides high-level requirements for such interface functionality. It includes a mapping of the HSL operations data and functions identified in Section 4 to current and planned CCS node - OS interfaces, and is structured accordingly. Emphasis has been placed on a minimal set of operations interface functions needed to support the initial deployment of HSLs by LECs given existing legacy OS interfaces. However, longer-term potential OS-node interface architectures are also considered.

Section 5.1 presents general considerations and objectives regarding the integration of HSL operations support into each node’s current operations interface interactions for signaling links. Remaining subsections present requirements for the specific operations functions and data to be supported over each of the recognized generic LEC operations interfaces. Specifically, they shall address

• Configuration Management/Memory Administration (CM/MA) OS Interface Support (Section 5.2)

• Maintenance OS Interface Support (Section 5.3)

• Network Traffic Management (NTM) OS Interface Support (Section 5.4)

• Network Data Collection (NDC) OS Interface Support (Section 5.5)

• User-System Interface (USI) Support (Section 5.6).

Most of those requirements shall be conditional upon the specific needs of each LEC and the set of operations capabilities to be supported in general for signaling links on each node’s operations interfaces.

The operations interface functionality applies to all CCS node types, except where specific node types are cited (e.g., the STP).

5.1 General

OSs and OS - node interfaces for the operations domains, identified above, tend to vary by LEC, node type, and node supplier. Some LECs are currently in the process of transitioning their CCS network operations from so-called “legacy” OSs and OS-node interfaces to their chosen “strategic” or next-generation OSs, some of which utilize new generic OS-node interfaces.

5–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Operations Interface Support December 1999

GR-2878-CORE

One such legacy OS has been the SEASTM System, which until recently in several large LEC CCS networks, has provided support for one or more of the MA/CM, NDC, network maintenance surveillance, and NTM surveillance functions for STPs via the operations interface specified in GR-310-CORE,[26] and NDC and maintenance surveillance support for the SCP nodes via the operations interface specified in TA-NWT-000365.[30] The various operations functions once provided by the SEASTM System have been migrated to other LEC-selected OSs that separately support each operations domain. For STP MA/CM functions, the SEASTM System’s MA application has been replaced at several large LECs by its successor OS, the NetPilotTM System. Telcordia also provides an interface mediation device known as the NetPilotTM CCS Message Router function, which allows other OSs meeting the GR-310-CORE[26] and TA-NWT-000365[30] interfaces to emulate the prior SEASTM applications and access the STP and SCP operations capabilities, while appearing to those CCS nodes as if they were a single operations system. The original SEASTM mainframe system and its remaining applications are targeted for retirement at those LECs still utilizing them no later than the end of 1999. The migration of these functions to successor OSs is to be completed by this time, which corresponds to the publication date of this GR. However, the continued use of the GR-310-CORE[26] and TA-NWT-000365[30] interfaces by LEC STPs, SCPs, and successor OSs, via the NetPilotTM CCS Message Router function, is anticipated to continue for an indefinite period until these interfaces are eventually replaced by successor generic interfaces.

Some of the new LEC-selected strategic OSs for some operations domains shall support new standardized OS-node interfaces based on the generic Open Systems Interconnection/Common Management Information Service Element (OSI/CMISE) interface architecture model, while others shall continue to support the existing operations interfaces formerly used by the legacy systems. Generic OSI/CMISE OS-node interfaces have been defined for NTM OSs and NDC OSs, and are applicable to all three CCS node types.

The main point to consider is that not all CCS nodes shall necessarily support all published OS-node interface generic requirements and interfaces for each operations domain. The specific interface or interfaces employed for each domain and for each node type shall therefore be determined by individual LEC purchasing and deployment decisions regarding their respective OSs and CCS nodes. Because of these differences in LEC operations interfaces, it is important that the CCS nodes provide such interface support for HSLs in a manner that is as consistent as possible with that provided for the MTP2-based 56-Kb/s links in the same time frame, so as to minimize any adverse operations impacts, and allow the same OSs to provide support for both link classes. The following general objectives apply.

O5-1 [174] It is an objective that the CCS nodes support the transfer of all relevant operations messages and data pertaining to HSLs over the same operations interfaces they shall utilize for comparable operations messages and data supporting 56-Kb/s MTP2-based signaling links.

5–2

ab


O5-2 [175] It is an objective that operations interface outputs, including measurement data, event notifications, and retrieved CM/MA data for HSLs shall be organized and presented in a manner consistent with that used for comparable data reported for existing conventional 56-Kb/s MTP2-based signaling links.

5.2 Configuration Management/Memory Administration OS Interface Support

5.2.1 For STPs (GR-310-CORE)

CR5-3 [176] As a per-LEC option for those LECs that utilize the NetPilotTM System for STP memory administration/configuration management, the STP shall support all configuration management data operations and data attributes required for HSLs, as identified in Section 4.2, via the interface defined in GR-310-CORE,[26] Section 7.

Specific revisions and additions have yet to be provided for the NetPilotTM user-view data entity set descriptions and Recent Change and Verify (RC&V) command and response message specifications needed to support those interactions. Those revisions, if provided in the future, shall be based on the HSL CM data and data operations requirements as presented in Section 4.2 of this document. These shall likely include:

1. The addition of the 2 new common link parameters defined in Section 4.2.1: Link Class and Link Parameter Set, as data attributes in the interface’s RC&V LINK entity set, and corresponding enhancements to the ASGN-, CHG-, and VFY-SLK interface command/response message specifications.

2. Support for a new SAAL Link Parameter Set (SAAL LINK PARM SET) entity set, to be referenced by configured HSLs, and which shall include as data attributes

(a) a link parameter set identifier

(b) the various required and conditionally required SAAL-level parameters

(c) the 9 required link transmit buffer congestion thresholds

(d) the 4 HSL marginal performance thresholds.

The HSL parameter sets are defined in Sections 4.2.4, 4.2.5, and 4.2.6, and are summarized within Table 4-1 in Section 4.2.8.

As of the publication date, there are as yet no definite plans to incorporate the HSL parameters just described into the GR-310-CORE[26] interface data model and message specifications. Such updates, if made in the future, will be dependent upon NetPilotTM user priorities for the development of HSL parameter administration features in the NetPilotTM

5–3


GR-2878-CORE

system. However, the current GR-310-CORE[26] interface specification already supports an argument of “1536 Kb/s” in the existing user view and in the corresponding ASGN-, CHG-, and VFY-SLK interface command/response messages. This argument can be used to distinguish HSLs from conventional 56-Kb/s MTP2 links, allowing them to be provisioned at STPs. Assuming the STP can default to the assumption that the 1536-Kb/s links are in fact SAAL-based HSLs, i.e., of Link Class “SAAL” as defined in Section 4.2.1, its configuration management function can utilize established system defaults for these HSL parameters, or may otherwise rely on the local or remoted USI, or the NetPilotTM interface Flow-Through capability, to allow configuration of the individual HSL parameters and the assignment of link parameter set IDs to HSLs. The following conditional requirements address this mode of support for HSL configuration management, as an alternative to the full support via the NetPilotTM - STP interface as specified in CR5-3 [176].

CR5-4 [214] As a per-LEC option for those LECs that utilize the NetPilotTM System for STP memory administration/configuration management, or other CM/MA OSs emulating the NetPilotTM-STP interface, the HSL STP shall support the assignment of link speed “1536” (Kb/s) to the Link Speed Parameter, allowing HSLs to be assigned within existing link sets and mapped to appropriately equipped DS1-rate link equipment ports, via the “Assign Signaling Link” (ASGN-SLK) command of the NetPilotTM-STP interface, as currently defined in GR-310-CORE,[26] Section 7.2.13.

CR5-5 [215] As a per-LEC option for those LECs that utilize the NetPilotTM System for STP memory administration/configuration management, or other CM/MA OSs emulating the NetPilotTM-STP interface via the NetPilotTM CCS Message Router function, but for which the HSL STP does not provide full support for HSL parameter administration via that interface as defined in CR5-3 [176], and if no other SS7 protocol stacks are supported for signaling links at the 1536 Kb/s link speed, the STP shall key on the 1536 Kb/s link speed value, default to Link Class = “SAAL” for that link, and shall apply either

… 1. HSL parameter values for a Link Parameter Set as mapped to that link and separately configured via other STP operations interfaces (e.g., via the USI or the NetPilotTM-STP Flow-Through interface), or

… 2. appropriate predefined system default values for HSLs, in the absence of user input to configure those parameter values.

… The HSL STP shall apply such treatment for all link parameters identified in Sections 4.2.4, 4.2.5, and 4.2.6.

CR5-6 [216] As a per-LEC option for those LECs that utilize the NetPilotTM System for STP memory administration/configuration management, or

5–4

ab


other CM/MA OSs emulating the NetPilotTM-STP interface via the NetPilotTM CCS Message Router function, but for which full support for HSL parameter administration is not provided via the NetPilotTM-STP interface per CR5-3 [176], the STP shall allow the assignment of a Link Parameter Set Identifier value for each HSL through the use of the Supplier-Specific Signaling Link Parameter(s) block within the “Assign Signaling Link” (ASGN-SLK) and “Change Signaling Link Attributes” (CHG-SLK) commands of the NetPilotTM-STP interface, as currently defined in GR-310-CORE,[26] Sections 7.2.13 and 7.2.15, respectively.

CO5-7 [217] As a per-LEC option for those LECs that utilize the NetPilotTM System for STP memory administration/configuration management, or other CM/MA OSs emulating the NetPilotTM-STP interface via the NetPilotTM CCS Message Router function, it is an objective that the HSL STP support the administration of the HSL Link Parameter Sets, each identified by a configured Link Parameter Set Identifier value, via implementation-specific commands conveyed via the NetPilotTM-STP interface’s FLOW-THRU (Flow-Thru) command message as specified in GR-310-CORE,[26] Section 10.2.2.

Aside from the HSL parameters assignable to groups of HSLs on a per-link-parameter set basis, there may be additional implementation-specific parameters assignable to each individual HSL. If such parameters exist for a given STP implementation, then the STP should allow for the administration of such per-HSL parameters via the supplier-specific parameter blocks in the existing NetPilotTM-STP interface commands defined for signaling links, per the following conditional objective.

CO5-8 [218] As a per-LEC option for those LECs that utilize the NetPilotTM System for STP memory administration/configuration management, or other CM/MA OSs emulating the NetPilotTM-STP interface via the NetPilotTM CCS Message Router function, for which other HSL parameters may be configured on a per-link-basis, the STP should allow the assignment of values for such parameters through the use of the Supplier-Specific Signaling Link Parameter(s) block within the “Assign Signaling Link” (ASGN-SLK) and “Change Signaling Link Attributes” (CHG-SLK) commands of the NetPilotTM-STP interface, as currently defined in GR-310-CORE,[26] Sections 7.2.13 and 7.2.15, respectively.

5.2.2 For CCS End-Nodes

Configuration management for the CCS end-nodes (i.e., SCPs and CCS SOs/SSPs) is typically assumed to be provided locally at those nodes’ USIs. (See also Section 5.6.) No comprehensive generic MA/CM OS - node interface covering all CCS functions has yet

5–5


GR-2878-CORE

been defined for those node types, and hence no incremental MA/CM interface functionality is specified as required for HSLs at this time. However, a GDMO-compliant OSI/CMISE ASN.1 CCS data model description, which has thus far been limited in scope to HSL parameters only, has in fact been defined for CCS nodes in general and is incorporated within GR-981-CORE,[31] Service Configuration Management for Switching Network Elements (NEs). Its applicability to CCS end-nodes and STPs is addressed in the following subsection.

5.2.3 For All CCS Nodes (GR-981-CORE)

Some limited object-oriented OSI/CMISE modeling of configuration management data for CCS node signaling functions has been performed by Telcordia and industry participants and has been incorporated into the generic CM/MA OS-NE interface defined in GR-981-CORE.[31] Currently, that data model includes CCS end-node data only for HSLs as defined in this GR and does not address the entire set of generic configurable CCS/SS7 parameters and other data. This portion of that data model is commonly referred to as the “CCS fragment” and it is anticipated that the GR-981-CORE[31] data model will be expanded in the future to incorporate additional configurable CCS/SS7 routing and translations data. As such, CCS node implementations that elect to support an OSI/CMISE MA/CM interface are encouraged to adopt that CCS fragment for the administration of HSLs via that interface.

CO5-9 [219] As a per-LEC option, it is an objective that CCS nodes supporting HSLs and an OSI/CMISE CM/MA interface, should support the administration of all HSL CM/MA data attributes and data operations, as identified in Section 4.2, via the generic OSI/CMISE-based MA/CM interface defined in GR-981-CORE.[31]

5.3 Maintenance OS Interface Support

5.3.1 For Fault Management Functions

5.3.1.1 For All CCS Node Types (TA-TSY-000387)

R5-10 [177] The CCS node shall support the Fault Management functions identified in Section 4.4, including the transmittal of supported event notifications and the receipt of all necessary command instructions, via its “maintenance channel” interface to the Network Maintenance OS, according to the interface specification defined in TA-TSY-000387,[32] Generic Requirements for the Interim Defined Central Office Interface

5–6

ab


(IDCI). Specifically, the interactions to be supported via that interface include

… 1. Reporting of the HSL link event notifications defined in Section 4.4.1, including

… a. Link Outage

… b. Link Available

… c. Sustained Link Failure/Craft Referral

… d. Unavailable Link Minor State Change

… e. Oversized Message Routing Attempt on an MTP2 Signaling Link.

… 2. HSL status logging interactions (if those objectives are supported and the capability is enabled), as specified in Section 4.4.2.

… 3. DS1-level event notifications, as defined in Section 4.4.3.2.

… 4. Initiation of, and results-reporting for, ATM and DS1 loopback testing capabilities, as specified in Section 4.4.4.

… 5. The removal and restoration of HSLs from service as defined in Section 4.4.5.

The semantics of the involved operations messages supporting these functions, i.e., their specific format and content, are assumed to implementation-specific, subject to the general message syntax and content requirements for the maintenance channel interface messages as defined in TA-TSY-000387[32] and the information content requirements in Section 4.4.

5.3.1.2 For STPs (GR-310-CORE)

CR5-11 [178] As a per-LEC option for those LECs that utilize a Maintenance OS emulating the former SEASTM System via the NetPilotTM CCS Message Router function, to support STP fault management, the STP shall additionally transmit the required HSL-related link event notifications (as identified in Section 4.4.1) via the interface defined in GR-310-CORE,[26] Section 8.

The detailed message specifications for the new STP-to- Maintenance OS autonomous messages, which are to be used to convey these event notifications have yet to be defined in Section 8 of that document. Their specification remains deferred pending a determination of the LECs’ need for STPs to transmit these notifications via the GR-310-CORE[26] interface to the maintenance OSs, in addition to their reporting on the STP’s maintenance channel interface. Any such new GR-310-CORE[26] autonomous message specifications shall be based on the information content requirements for the cited notifications as presented in Section 4.4.1 of this document.

5–7


GR-2878-CORE

5.3.1.3 For SCPs (TA-NWT-000365)

CR5-12 [179] As a per-LEC option for those LECs that utilize a Maintenance OS emulating the former SEASTM System via the NetPilotTM CCS Message Router function, to support SCP node fault management, the SCP node shall additionally transmit the required HSL-related link event notifications (as identified in Section 4.4.1) via the interface defined in TA-NWT-000365.[30]

The detailed message specifications for the new SCP-node-to-Maintenance OS autonomous messages, which are to be used to convey these event notifications, have yet to be defined in TA-NWT-000365.[30] Their specification has been deferred pending a determination of the user need for SCPs to transmit these notifications via the TA-NWT-000365[30] interface to the maintenance OS in addition to their reporting on the SCP’s maintenance channel interface. As was the case for the STP autonomous messages, any such new TA-NWT-000365[30] autonomous message specifications shall be based on the information content requirements for the cited notifications as presented in Section 4.4.1 of this document.

5.3.2 For Performance Management Functions

5.3.2.1 For All CCS Node Types (TA-TSY-000387)

R5-13 [180] The CCS node shall support the maintenance-oriented Performance Management functions identified in Section 4.5 , including the transmittal of supported measurement reports and the receipt of all necessary command instructions, via its “maintenance channel” interface to the Network Maintenance OS, according to the interface specification defined in TA-TSY-000387.[32] Specifically, the performance management interactions to be supported via this interface include the following:

… 1. The reporting of all identified daily performance measurements as identified in Section 4.5.1.

… 2. The transmittal of all exception-based performance reports, including link marginal performance reports, DS1 performance reports, and associated threshold crossing alerts (TCAs) as identified in Section 4.5.2.

… 3. Interactions for all supported management-initiated performance monitoring functions, including initiation and results reporting, for the capabilities identified in Section 4.5.3.

5–8

ab


5.3.2.2 For STPs (GR-310-CORE)

CR5-14 [181] As a per-LEC option for those LECs that utilize a Maintenance OS emulating the former SEASTM System via the NetPilotTM Message Router capability to perform STP maintenance surveillance functions, the STP shall additionally support the collection of all scheduled daily HSL measurements identified in Section 4.5.1 via the data collection interface defined in GR-310-CORE,[26] Section 6.

CO5-15 [182] As a per-LEC option for those LECs that utilize a Maintenance OS emulating the former SEASTM System via the NetPilotTM Message Router capability, to perform STP maintenance surveillance functions, it is an objective that the STP also support the collection of

… 1. the HSL measurements identified as “daily” in Section 4.5.1, instead on a day-to-hour basis via the interface defined in GR-310-CORE,[26] Section 6

… 2. the HSL measurements identified as “marginal” in Section 4.5.1, instead on a scheduled hourly basis, via the interface defined in GR-310-CORE,[26] Section 6.

The new HSL daily, day-to-hour, and hourly measurement registers shall need to be appended to the current set of register definitions now defined for existing 56-Kb/s links as specified under the P_MTCD, D_MTCDTH, and D_MTCH data collection schedules in Appendix B, Sections B.6, B.8, and B.9, respectively, of GR-310-CORE.[26] A GR-310-CORE[26] update to incorporate these measurements in those appendixes has yet to be provided, and is not currently scheduled. STP suppliers may utilize their own supplier-specific measurement register labels and append these data to the indicated SEASTM maintenance-oriented data collection schedules and entity-type (ENTTYPE) data groupings. However, the use of standardized measurement register labels and schedule/entity-type data groupings is recommended as defined in Appendix D of this GR, and as expressed in the following conditional objective.

CO5-16 [220] As a per-LEC option for those LECs that utilize a Maintenance OS emulating the former SEASTM System via the NetPilotTM CCS Message Router capability to perform STP maintenance surveillance functions, it is an objective that the STP utilize the standardized measurement register labels and schedule groupings defined in Appendix D of this GR to report the measurements described in CR5-14 [181] and CO5-15 [182] to the Maintenance OS. These include the measurement data groupings identified in Appendix D, Table D-1, under the following measurement bases:

… 1. “d/M-PM/L” (appended to SCHED = P_MTCD and D_MTCDTH, ENTTYPE = LINK)

5–9


GR-2878-CORE

… 2. “m/M-PM/L,”(appended to SCHED = D_MTCH, ENTTYPE = LINK).

5.4 Network Traffic Management (NTM) OS Interface Support

5.4.1 For All CCS Node Types (GR-495-CORE)

CR5-17 [183] As a per-LEC option, the CCS node supporting HSLs shall support the collection of all scheduled five-minute link exception measurements and scheduled link set measurements identified in Section 4.5.1 via the generic OSI/CMISE-based NTM interface defined in GR-495-CORE,[33] Generic Operations Interfaces Using OSI Tools: Network Traffic Management (NTM).

The new five-minute HSL measurement data have already been modeled and included in the appropriate OSI/CMISE Management Information Base (MIB) GDMO data model description within GR-495-CORE.[33]


CR5-18 [184] As a per-LEC option for those LECs that utilize an NTM OS emulating the former SEASTM System via the NetPilotTM Message Router function, to perform STP NTM surveillance, the STP shall additionally transmit all scheduled five-minute link exception measurements, scheduled link set measurements, and STP system total measurements identified in Section 4.5.1.2 (MTP Level 3 Performance Measurements: 5-Minute) via the interface defined in GR-310-CORE,[26] Section 6.

The new HSL five-minute measurement registers shall need to be appended to the current set of register definitions now defined for existing 56-Kb/s links as specified under the D_NM and A_NM data collection schedules in Appendix B, Sections B.7 and B.11 of GR-310-CORE,[26] respectively. An interface specification update to incorporate these measurements has yet to be provided, and is not currently scheduled. STP suppliers may utilize their own supplier-specific measurement register labels and measured-entity-type data groupings, and append these data to the indicated GR-310-CORE[26] data collection schedules. However, the use of standardized measurement register labels and schedule/measured-entity-type data groupings is recommended as defined in Appendix D of this GR, and as expressed in the following conditional objective.

CO5-19 [221] As a per-LEC option for those LECs that utilize an NTM OS emulating the former SEASTM System via the NetPilotTM Message Router capability to perform STP NTM surveillance functions, it is an objective

5–10

ab


that the STP utilize the standardized measurement register labels and schedule groupings defined in Appendix D of this GR to report the measurements described in CR5-18 [184] to the NTM OS. These include the measurement data identified in Appendix D, Table D-1, under the following measurement bases:

… 1. “5x/NTM/L” (appended to SCHED = A_NM, ENTTYPE = LINK)

… 2. “5/NTM/LS” (appended to SCHED = D_NM, ENTTYPE= LNKSET)

… 3. “5/NTM/STP” (appended to SCHED= A_NM, ENTTYPE = STP).

5.4.3 Considerations For CCS SOs/SSPs

Most CCS-capable Stored Program Controlled Switching Systems (SPCSs), i.e., CCS SOs and SSPs, currently support the collection of NTM measurement data and discrete event indicators via the interface specified in TR-NWT-000746,[34] Stored Program Control System/Operations System (SPCS/OS) - Network Traffic Management Operations System (NTM OS) Interface Via a Network Data Collection Operations System (NDC OS), FSD 45-18-0403. However, the FSD 45-18-0403 interface primarily concerns switch and trunk group surveillance data and associated NTM controls, and currently does not support the collection of SS7 measurements for 56-Kb/s signaling links. It is thus not a likely candidate for extension to support the collection of the new HSL NTM-related five-minute measurements cited in Section 4.5.1. It should be noted, therefore, that if the CCS SO/SSP does not support the GR-495-CORE interface described Section 5.4.1, there is no other generic operations interface currently defined as a vehicle to support the collection of the new five-minute NTM HSL measurements for this node type.

5.5 Network Data Collection (NDC) OS Interface Support

5.5.1 For All CCS Node Types (GR-376-CORE)

CR5-20 [185] As a per-LEC option, the CCS node shall support the collection of all scheduled 30-minute link measurements identified in Section 4.6 via the generic OSI/CMISE-based NDC OS interface defined in GR-376-CORE,[35]Generic Operations Interfaces Using OSI Tools: Network Data Collection (NDC).

The indicated HSL measurement data have already been modeled and included in the appropriate OSI/CMISE Management Information Base (MIB) ASN.1/GDMO data model description within GR-376-CORE.[35]

5–11


GR-2878-CORE


CR5-21 [186] As a per-LEC option for those LECs that utilize a Network Data Collection OS emulating the former SEASTM System via the NetPilotTM CCS Message Router function for STP network data collection, the STP shall support the collection by the NDC OS of all 30-minute HSL and link set NDC traffic and performance measurements defined per requirements specified in Sections 4.6.1 through 4.6.4, via the interface defined in GR-310-CORE,[26] Section 6.

CO5-22 [222] As a per-LEC option for those LECs that utilize a Network Data Collection OS emulating the former SEASTM System via the NetPilotTM CCS Message Router function for STP network data collection, it is an objective that the STP additionally support the collection by the NDC OS of the 24-hour (daily) maintenance measurements identified in Section 4.5.1, via the data collection interface defined in GR-310-CORE,[26] Section 6.

The new HSL 30-minute measurement registers shall need to be appended to the current set of register definitions now defined for existing 56-Kb/s links as specified under the P_COMP data collection schedule in Appendix B, Section B.2 of GR-310-CORE.[26] Also, as previously cited, the new daily maintenance measurements, which may be of interest to the NDC function, shall need to be appended to the current set of register definitions now defined for existing 56-Kb/s links as specified under the P_MTCD data collection schedule in Appendix B, Section B.6 of GR-310-CORE.[26] An interface specification update to incorporate these measurements has yet to be provided, and is not currently scheduled. STP suppliers may utilize their own supplier-specific measurement register labels and append these data to the indicated GR-310-CORE[26] data collection schedules and entity-type data groupings. However, the use of standardized measurement register labels and data groupings is recommended as defined in Appendix D of this GR, and as expressed in the following conditional objective.

CO5-23 [223] As a per-LEC option for those LECs that utilize an NDC OS emulating the former SEASTM System via the NetPilotTM CCS Message Router capability to perform STP NDC functions, it is an objective that the STP utilize the standardized measurement register labels and schedule groupings defined in Appendix D of this GR to report the measurements described in CR5-21[186] and CO5-22 [222] to the NDC OS. These include the measurement data identified in Appendix D, Table D-1, under the following measurement bases:

… 1. “30/NDC/L” (appended to SCHED = P_COMP, ENTTYPE = LINK)

… 2. “30/NDC/LS” (appended to SCHED = P_COMP, ENTTYPE = LNKSET)

5–12

ab


… 3. “d/M-PM/L” (appended to SCHED = P_MTCD, ENTTYPE = LINK).

5.5.3 For SCPs (TA-NWT-000365)

CR5-24 [187] As a per-LEC option for those LECs that utilize a Network Data Collection OS emulating the former SEASTM System via the NetPilotTM CCS Message Router function for SCP node network data collection, the STP shall support the collection by those systems of all 30-minute HSL and link set NDC traffic and performance measurements defined per requirements specified in Sections 4.6.1 through 4.6.4, via the interface defined in TA-NWT-000365,[30] under the message description “Report Node Measurements” (REPT-NOM).”

The new HSL 30-minute measurement registers shall need to be appended to the current set of register definitions now defined for existing 56-Kb/s links as specified in that message specification within TA-NWT-000365.[30] The interface specification update to incorporate these measurements has yet to be provided and is not currently scheduled. SCP node suppliers may utilize their own supplier-specific measurement register labels and append these data to the indicated TA-NWT-000365 data collection schedules and measured-entity-type data groupings. However, the use of standardized measurement register labels and data groupings is recommended as defined in Appendix D of this GR, and as expressed in the following conditional objective.

CO5-25 [224] As a per-LEC option for those LECs that utilize an NDC OS emulating the former SEASTM System via the NetPilotTM CCS Message Router capability to perform SCP node NDC functions, it is an objective that the STP utilize the standardized measurement register labels and schedule groupings defined in Appendix D of this GR to report the measurements described in CR5-24 [187] to the NDC OS. These include the measurement data identified in Appendix D, Table D-1, under the following measurement bases:

… 1. “30/NDC/L” (appended to SCHED = C_COMP, ENTTYPE = LINK)

… 2. “30/NDC/LS” (appended to SCHED = C_COMP, ENTTYPE= LNKSET).

5.5.4 For CCS SOs/SSPs (FSD 45-09-0100)

CR5-26 [188] Per LEC-specific needs, CCS-capable Stored-Program-Controlled Switching Systems (SPCSs), i.e., CCS SOs and SSPs, shall support the collection by the Network Data Collection OS (NDC OS) of

5–13


GR-2878-CORE

… 1. all 30-minute HSL and link set NDC traffic and performance measurements defined per requirements specified in Sections 4.6.1 through 4.6.4

… 2. the subset of daily (24 hour) performance measurements defined within Sections 4.5.1.1, 4.5.1.3, and 4.5.1.5

… via the interface specified in TR-NWT-000740,[36] Stored Program Control System/Operations System (SPCS/OS) - Network Data Collection Operations System (NDC OS) Interface, FSD 45-09-0100.

Under the standardized “sectionalized” data packaging scheme employed in the FSD 45-09-0100 interface, the new HSL measurements would have to be defined in terms of standardized section identifiers and keywords. Such definitions generally vary by supplier and switch software release, and must be defined on an implementation-specific basis and provided to the NDC OS supplier.

5.6 User-System Interface (USI) Support (TR-TSY-000825)

R5-27 [189] In addition to the node-OS interface support defined above for the respective operations systems, the CCS node shall support those same operations interactions for HSLs via the node’s local (and remoted) User System Interface (USI) work positions.

R5-28 [190] The CCS node shall support all such user-node operations interactions for HSLs, for each of the indicated operations domains as defined in Section 4 of this document, via messages exchanged on the node’s User System Interface (USI), according to generic requirements for the USI as presented in TR-TSY-000825,[37] Operations Technology Generic Requirements (OTGR): User-System Interface - User System Language.

5–14

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Performance

6. Performance

6.1 Reliability

The HSL NE downtime objectives are related to the CCS network unavailability objective. This corresponds to an average of no more than 10 minutes cumulative downtime per year between two signaling end points, and applies only to the Message Transfer Part of the SS7 protocol. This objective has been recommended in ANSI standard ANSI T1.111.6,[38] Message Transfer Part Signaling Performance and has been adopted by ANSI Committee T1 and incorporated in ANSI T1.111,[39] Signaling System Number 7 (SS7) - Message Transfer Part.

The 10-minute end-to-end downtime objective and its allocation scheme to the access and backbone segments will remain applicable to CCS networks using HSLs. However, since new link interface cards (supporting the DS1 interface, ATM, and SAAL protocols) will be used in high speed links, their impact on the current STP “link specific” downtime objectives and requirements described in Table 9-1 of GR-82-CORE[12] will be the subject of further study.

The failure modes associated with the DS1 link interface affect only the HSL terminating on that interface. The expected link interface unavailability is determined the probability that the link interface is not available for signaling traffic. This interface unavailability is included in the expected value of the STP signaling link’s unavailability. Failure modes associated with the STP processor(s) are assumed to be independent of the DS1 link interface failure modes.

6.2 Network Performance Parameters and Objectives

CCS nodes supporting ATM-based HSLs are required to support CCS network performance objectives by providing a quality of service equal to or greater than that provided by NEs supporting existing narrowband (56-Kb/s) signaling links. The basic performance objectives for existing narrowband (56-Kb/s) signaling network elements are in most cases applicable for the HSL NEs providing ATM/SAAL-based signaling links. Performance requirements and objectives are discussed in various Telcordia and industry documents relevant to the high speed signaling link application. A bibliography of relevant Telcordia documents is provided here:

• GR-246-CORE[1] provides the fundamental specifications and requirements applicable to the SS7 protocol. Chapter T1.111.7 of that document includes objectives for the Message Transfer Part (MTP) in relation to route set availability, message delay, and message transfer times applicable for various signaling elements, protocols, and transmission error conditions.

6–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Performance December 1999

GR-2878-CORE

• GR-82-CORE[12] provides requirements and objectives for performance required at an STP. Section 9 of that document defines objectives for STP total system and link downtime and cross-STP delay requirements. The cross-STP delay requirements are derived from the estimates of processing time at the node and link output delay. The estimation of the link output delay is based on the 56-Kb/s link speed. Applicability of requirements for link output delay for 1.5-Mb/s high speed signaling links is discussed in the following paragraphs.

• GR-606-CORE[13] provides requirements and objectives applicable to signaling points serving as CCS switching offices or SSPs.

• GR-1241-CORE[14] discusses the applicable requirements and objectives for SCPs.

• GR-499-CORE[4] provides performance requirements and objectives for the DS1 physical interface. Specifically, Section 4 of GR-499-CORE provides DS1-level error performance requirements.

• GR-1110-CORE[27] provides performance parameters for the ATM cell delay. Section 8 and Appendix A of that document define applicable parameters that are considered important for the ATM layer.

In general, the overall performance of a high speed signaling link is dictated by the user environment at the service layer. These performance requirements are then translated into various network performance parameters and apportioned into various signaling network elements. The parameters that are useful for meeting the user performance requirements using high-speed links are defined in the documents summarized in the following sections.

6.2.1 Parameters Related to the Message Transfer Part

The following parameters are defined in GR-246-CORE.[1]

• MTP Signaling Route Set Unavailability: is the probability that an MTP signaling route set used to reach a particular destination cannot perform its required function at a given instant of time.

• Undetected Errors: is the capability that signaling link errors will not remain undetected for more than a predetermined value. This parameter is dependent on the signaling data link error rate characteristics.

• Loss of Messages: this parameter defines average message loss that is acceptable due to failure of the Message Transfer Part.

• Messages Out-of-Sequence: parameter defines the maximum number of messages that can be delivered out-of-sequence.

6–2

ab


6.2.2 Message Transfer Times

This parameter defines the average transfer time for a message transiting from an originating application to a destination application. The components of the message transfer time consist of (1) message transfer time at the originating end, (2) message transfer time at the signaling transfer point, and (3) message transfer time at the destination node. Message transfer times at the origination and destination points are described in GR-246-CORE.[1] The STP transfer time, referred to as the “Cross-STP Transport Time” contributes the most to the overall end-to-end transfer time or delay. Cross-STP Transport Time is described in GR-82-CORE[12] and is defined as the interval of time beginning when a message is received at the incoming signaling link and ending when the message is transmitted on the outgoing signaling link. The cross-STP transport time is derived from two components, (1) node processing time, and (2) link output delay, and can be expressed as follows:

cross-STP transport time = STP node processing time + link output delay.

STP node processing time consists of the interval beginning when the STP receives the last bit of a message from the incoming signaling link, and ending when the STP places the message in the output link buffer. For HSLs, the link output delay is measured at MTP level 3, beginning when a MTP level 3 message is placed in the output buffer and ending when the last bit of the message is successfully handed of to the SSCF layer.

Link output delay is the interval beginning when the STP places the message in the output signaling link buffer, and ending when the STP transmits the last bit of the message on the outgoing signaling link. For HSLs, the link output delay is measured at MTP level 3 , begins at the time the MTP level 3 message is placed in the output buffer, and ends at the time the last bit of the message is successfully handed off to the SSCF layer.

Based on the previous definitions, the STP node processing time is independent of the signaling link speed and is primarily a function of the STP’s internal processing characteristics and the processing load imposed on the STP. The traffic’s message-length distribution is considered to have little effect on STP node processing time, with the assumption that message lengths are under the MTP level 2 maximum message length (i.e., 279 octets). GR-82-CORE[12] provides the mean and 95-percentile objectives for node processing time expected at an STP for normal and failure-condition loads (see Section 9.2 of GR-82-CORE[12] for definition of normal and failure condition loading). It is expected that the HSL NE with high speed (1.5-Mb/s) signaling links using the ATM/SAAL lower layer protocols should be able to meet the STP node processing time requirements described in GR-82-CORE.[12] It should be noted that the basis for node processing time estimates provided in GR-82-CORE[12] assumed MTP level 2 as the data link layer. With HSL applications use ATM/SAAL as the data link layer, processing time should include processing in the SAAL and ATM layers.

6–3


GR-2878-CORE

R6-1 [191] The HSL STP node processing time shall be equal to or less than the corresponding node processing time values provided in Section 9.2.1 of the GR-82-CORE.[12]

Link output delay is the sum of the queuing delay and message emission time. Queuing delay is the time beginning when a message is placed in the output signaling link buffer to when the first bit is transmitted. Both queuing delay and the message emission time are functions of signaling data link speed. GR-82-CORE[12] provides the expected values of link output delay for 56-Kb/s signaling links. For high speed (1.5-Mb/s) signaling links, expected values for link output delay for corresponding message lengths will be smaller. Table 6-1 provides link output delay values for high speed (1.5-Mb/s) signaling links. The message length characteristics are represented by a lower bound (i.e., assuming all messages are 15 octets long) and an upper bound (i.e., assuming all messages are 279 octets long) to align these values with the data in Table 9-4 of GR-82-CORE.[12] Since, HSLs may carry longer messages than 279 octets, (i.e., up to 4096 octets), Table 6-1 also indicates corresponding link output delay values for message lengths up to 4096 octets as allowed by the SAAL protocol.

Table 6-1. High Speed Link Output Delay

Based on the node processing times described in Table 9-3 of GR-82-CORE[12] and link output delay values described in Table 6-1. The corresponding values of Cross-STP Transport Times for high speed (1.5-Mb/s) link STPs are provided in Table 6-2. Table 6-2 shows cross-STP transport times for the lower bound (i.e., 15-octet messages), the upper bound (i.e., 279-octet messages), and the SAAL maximum message length (i.e., 4096 octets).

Range Loading Link Output Delay (ms)

Mean 95%

Lower Bound Normal 0.4 TBD

Failure 0.8 TBD

Upper Bound Normal 2.2 TBD

Failure 5.0 TBD

SAAL Normal 31.6 TBD

Failure 71.5 TBD

6–4

ab


Table 6-2. High Speed Link Cross-STP Transport Time

6.2.3 SAAL Performance

The end-to-end performance parameters discussed in the preceding section rely on the protocol mechanism in place, specifically, the data link layer and network layer protocols. In the HSL context, the link layer is comprised of the SAAL stack. The SAAL receives a message from an application layer through MTP level 3. Once the SAAL receives the message, it transmits it to the other end. If the message gets lost while being transmitted from the MTP level 3 to SAAL or vice-versa, or gets corrupted when transmitted on the signaling link, the timer in the application layer signaling entity would time out. The SAAL entity in the signaling node should implement a robust design that will minimize the message loss. The overall message loss probability for the signaling node shall be as specified in GR-246-CORE.[1]

R6-2 [192] The HSL NE shall ensure a robust SAAL implementation that will allow it to meet the message loss and delay criteria described in GR-82-CORE.[12]

6.2.4 ATM Layer Performance

The ATM layer performance parameters are defined in ANSI T1.511,[40] B-ISDN ATM Layer Cell Transfer - Performance Parameters and in GR-1110-CORE.[27] The relevant performance parameters discussed in these documents include; Cell Loss Ratio, Cell Transfer Delay, and Cell Delay Variations. Application of these parameters relates to information transport performance for an ATM connection in a broadband network environment (using broadband network elements such as ATM multiplexers/demultiplexers) where many services are offered over the same ATM interface. Since the high speed (1.5-Mb/s) signaling link will rely on a single point-to-point ATM connection dedicated to only SS7 signaling message transport, the ATM performance parameters such as Cell Loss or Cell Transfer Delay are not considered applicable.

Range Loading Cross-STP Transport Time (ms)

Mean 95%

Lower Bound Normal 43.4 TBD

Failure 80.8 TBD

Upper Bound Normal 45.2 TBD

Failure 85.0 TBD

SAAL Normal 74.6 TBD

Failure 151.5 TBD

6–5


GR-2878-CORE

6.3 Capacity

The processing capacity at an HSL NE is dependent on the specific implementation. In general the processing capacity will depend on the signaling NE architecture, number of links terminated and load carried by links under normal and failure conditions. The HSL NE may also include, in most instances, both 56-Kb/s and 1.5-Mb/s signaling links, as is anticipated at STPs. The following general requirements are applicable for processing capacity at an HSL NE.

R6-3 [193] High speed (1.5-Mb/s) signaling link processors shall be able to support full available throughput on a 1.5-Mb/s link (equivalent to 3622 cells per second) without degrading performance.

R6-4 [194] Overall signaling processing capacity at an HSL NE shall be able to support total load imposed by all links including 56-Kb/s and 1.5-Mb/s links under both normal and failure conditions. Signaling link utilization of 40% during normal operation and 80% during failure operation shall be considered.

Under some postulated failure conditions or NE resource-limiting conditions, an HSL NE may control the rate of received traffic on a 1.5-Mb/s signaling link, in order to avoid the impending processing overload condition.

6–6

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Environmental Requirements

7. Environmental Requirements

7.1 Power

R7-1 [195] The HSL NE, including any equipment specific to its implementation of HSLs, shall be designed to obtain power from a nominal -48 volt DC CO power system. Refer to GR-513-CORE,[41] LSSGR: Power Section 13 (a module of LSSGR, FR-64), for power system requirements.

7.2 Equipment

R7-2 [196] The HSL NE , including any equipment specific to its implementation of HSLs, shall satisfy the spatial and environmental requirements described in GR-63-CORE,[42] Network Equipment-Building System (NEBS) Requirements: Physical Protection.

7.3 Electromagnetic and Electrical Environment

GR-63-CORE[42] provides requirements to ensure that a switch complies with Federal Communications Commission (FCC) specifications, that it has intrasystem electromagnetic compatibility, and that intersystem electromagnetic compatibility exists between systems in the CO. It also includes electrical safety requirements.

7–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Environmental Requirements December 1999

GR-2878-CORE

7–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Quality

8. Quality

8.1 Introduction

This section provides an overview of the generic Reliability and Quality (R&Q) requirements for the HSL NE. The intent of these generic R&Q requirements is to assist the LECs in continuing to provide excellent service, reducing maintenance costs, and providing stable and dependable system operation.

FR-796,[43] Reliability and Quality Generic Requirements (RQGR), is a collection of Telcordia generic requirements proposed to help ensure the uninterrupted performance, reliability, and quality of products intended for use as network elements in a typical LEC network. A brief description of each document in the RQGR collection appears in GR-874-CORE,[44] An Introduction to the Reliability and Quality Generic Requirements (RQGR).

Among all the R&Q requirements documents, TR-NWT-000284,[45] Reliability and Quality Switching Systems Generic Requirements (RQSSGR), in particular, gives the R&Q requirements for switching systems, including the STP. In this section, only the key items of the RQSSGR are listed. Further details are to be found in the RQSSGR and its references.

8.2 Reliability and Quality Switching Systems Generic Requirements

In addition to the quantitative reliability performance objectives stated in Section 6, qualitative and analytical generic R&Q requirements and objectives applicable to network system design, manufacture, and support are provided or referenced in the RQSSGR. These generic reliability and quality requirements are intended to help ensure that network systems provide stable and dependable operation throughout their service life, and that maintenance and administration costs are continually reduced. The RQSSGR also provides requirements for the development of reliability models appropriate for the analysis of system architecture and recovery designs against quantitative objectives.

The RQSSGR is subdivided into three major categories:

• System Design and Architecture

• Manufacturing and Production

• In-Service Performance and Product Support.

Each category is summarized in Sections 8.2.1, 8.2.2 , and 8.2.3, respectively.

8–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Quality December 1999

GR-2878-CORE

8.2.1 System Design and Architecture

The System Design and Architecture section of the RQSSGR addresses the following areas of system design and architecture requirements:

• System Reliability Performance

• Hardware Design and Architecture

• Software Design and Architecture

• Conformance to Requirements.

8.2.2 Manufacturing and Production

The Manufacturing and Production section of the RQSSGR describes the requirements for the incorporation of R&Q practices in the manufacturing and production phases of the product life cycle. These phases also require that certain procedures be used to help ensure the R&Q of the shipped product. The areas of the requirements include

• Testing

• Component and Device Reliability

• Product Inspection

• Supplier Data Program

• Quality Program

• Manufacturing Program

• Periodic Product and Process Requalification.

8.2.3 In-Service Performance and Product Support

The In-Service Performance and Product Support section of the RQSSGR provides in-service performance and product support requirements for switching network elements. The requirements for in-service performance monitoring and practices are described. The product support requirements and objectives address the following elements of a product program:

• Reliability and Quality Cost

• Engineering and Ordering

• Installation

• First Office Application

8–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Quality

• Training

• Technical Assistance

• Deliverable Customer Documentation

• Product Change Procedures

• Repair

• Supplier's Spares Plan

• Engineering Complaints.

8–3

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Quality December 1999

GR-2878-CORE

8–4

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Transitional Considerations

9. Transitional Considerations

This section addresses transition issues that will be applicable when HSLs signaling links are introduced in the CCS networks. Initially, HSLs are expected to be deployed within existing link sets to allow verification of the HSL operation, prior to the removal of the 56-Kb/s MTP2 signaling links, which are to be replaced. Under this transition scenario, HSLs will be required to interwork with existing 56-Kb/s links within the same link set or in a combined link set. Also, after the initial deployment period, there may be situations where both types of links will remain in separate link sets used as normal and alternate routes to certain destinations, for example, in a B-link-set quad and a C-link set.

When the two different types of links (56-Kb/s and 1.5 Mb/s) may be operating in the same link set or in a combined link set, situations involving link failures must be considered. Potential concerns arise during link failures when an HSL and 56-Kb/s links are used in the same link set. Specifically, there is a potential for transmit congestion on the 56-Kb/s links during the execution of changeover and changeback procedures. The following paragraphs discuss these concerns and identify potential solutions and requirements.

When a changeover is performed on a HSL, the changeover order and changeover acknowledgment messages contain the extended changeover signals (i.e., H1 encodings 0011 and 0100, respectively), and carry as information the 24-bit sequence number of the last message accepted from the link. During the transition period and possibly (though unlikely) on a long term basis for some network architectures, the changeover messages for the high speed signaling links will be transported over 56-Kb/s signaling links. To ensure that the sequence controlling procedures of the changeover process operate correctly, the new formats of the changeover messages must be recognized by the receiving signaling points. When a 56-Kb/s signaling link terminal receives the changeover acknowledgment message with the new H1 and sequence number encoding, this information must be processed correctly so that the changeover procedures can be executed without error. Such processing is addressed in R3-61 [50] and R3-62 [51] in Section 3.3.2.3.

When changeover, changeback, or controlled rerouting is performed, messages are buffered for a period of time to ensure proper sequencing and to reduce message loss. After that period of time, the buffered messages are transferred to the new link or route. Since it is expected that the processors performing these functions for HSLs will be much faster than those for 56-Kb/s links, there is the potential that the processors for the HSLs could congest the 56-Kb/s links when transferring buffered messages for changeover, changeback, or controlled rerouting.

When a HSL is contained in the same combined link set as a 56-Kb/s link during the transition period, it will be carrying the same amount of traffic as each 56-Kb/s link. If the HSL fails, the number of messages that will be buffered will be approximately the same as for a 56-Kb/s link, and therefore should not cause congestion. During the transition period and also over the long term, HSLs may serve as alternate routes for primary routes containing 56-Kb/s links. In these cases, changeback and controlled rerouting may be performed to divert traffic from HSLs back to 56-Kb/s signaling links.

9–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Transitional Considerations December 1999

GR-2878-CORE

As described during the transition stage and for some limited long term applications, the potential for congestion due to changeover, changeback, and controlled rerouting are unlikely, and congestion thresholds specified for current 56-Kb/s links are probably adequate. However, additional examination of congestion thresholds under these conditions are for further study, and new requirements that the HSL NE support larger transmit buffers and higher transmit congestion thresholds to accommodate such traffic are possible, and may be introduced in future issues.

9–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Supplier Support

10. Supplier Support

10.1 General

R10-1 [197] The HSL NE supplier shall meet the supplier-support generic requirements published in the following Telcordia documents:

… • GR-454-CORE,[46] Generic Requirements for Supplier-Provided Documentation.

… • GR-839-CORE,[47] Generic Requirements for Supplier-Provided Training.

… • TR-NWT-000840,[48] Supplier Support Generic Requirements (SSGR).

GR-454-CORE[46] describes the Telcordia view of proposed generic requirements for documentation that suppliers should provide with Network Elements (NEs) and Network Systems (NSs) that a typical LEC purchases to meet its needs.

GR-839-CORE[47] provides the Telcordia view of proposed generic requirements that affect supplier-provided training. It documents the generic training requirements from the needs assessment stage through the development, delivery, implementation, and evaluation phases, and addresses existing training as well as training to be developed.

TR-NWT-000840[48] addresses the following aspects of supplier support:

• Engineering and Ordering

• Installation and Removal

• First Application

• Technical Assistance

• Repair and Return

• Spares.

Additional supplier-support requirements related to documentation are stated in Sections 10.2 and 10.3.

10.2 HSL NE Operations Documentation

R10-2 [198] HSL NE USI work position manuals shall describe each work position, and for HSL-related functionality: the installation procedures, how to set options and parameters, how to use the work station, and how to populate pertinent fields in each screen.

10–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Supplier Support December 1999

GR-2878-CORE

R10-3 [199] In addition, detailed descriptions shall be provided for all new HSL NE output messages pertaining to HSLs and related functions defined in this GR.

R10-4 [200] Documented RC&V procedures shall be provided for all HSL provisioning activities defined in Section 4.2 of this GR.

10.3 HSL NE Software Documentation

R10-5 [201] A set of clearly defined and documented Regression Test and Acceptance Procedures shall exist for the running of basic sanity tests on the HSL NE software on completion of installation and initialization activities.

R10-6 [202] As discussed in GR-282-CORE,[49] Software Reliability and Quality Acceptance Criteria (SRQAC), for each new software release or fix, lists shall be provided that include all modules in the load, all problems fixed in the release, all known problems in the release, and all modules affected by the change. Changes to all affected documentation shall also be included.

10–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Guidelines for Peer-to-Peer Credit Flow Control and Receive Buffer Sizing

Appendix A: Guidelines for Peer-to-Peer Credit Flow Control and Receive Buffer Sizing

A.1 SAAL Flow-Control Mechanism

This section briefly describes the flow-control mechanism provided by the Service Specific Connection Orientation Protocol (SSCOP) in the SAAL. A full description of SSCOP may be found in ANSI Recommendation T1.637.[6]

In SSCOP, flow control is achieved by the receiver allocating a "credit'' to the transmitter, which indicates the number of user PDUs (protocol data units) the transmitter is allowed to send. The receiver informs the transmitter of the available credit via a STAT (status) PDU (which is sent in response to the POLL PDU sent by the transmitter). Polls are sent periodically by the transmitter with a spacing of TIMER_POLL seconds. The available credit may also indicated by USTAT (Unsolicited Status) PDUs, which are sent by the receiver whenever it detects a new gap in the sequence numbers of the transmitted PDUs. The protocol prevents the transmitter from transmitting PDUs in excess of the granted credit. The credit mechanism is briefly described in the following text.

The SSCOP receiver maintains three counters:

1. VR(R): the next expected sequence number (or "seqno" in protocol documentation), i.e., all PDUs with a smaller seqno have already been received correctly and acknowledged by the receiver.

2. VR(H): the highest expected seqno, i.e., the highest seqno seen by the receiver thus far is VR(H)-1.

3. VR(MR): the maximum seqno, i.e., the receiver will not accept any PDU with seqno of VR(MR) or higher.

It is clear that the range [VR(R), VR(MR)-1] defines the granted credit since any PDU with seqno in this range will be accepted and all others will be discarded1. If VR(R) reaches VR(MR), the credit becomes zero. SSCOP does not specify precisely how VR(MR) should be updated by the receiver and allows credit-granting schemes to be implementation dependent.

The SSCOP transmitter maintains three separate counters:

1. VT(A): Last acknowledged seqno, which is updated by the VR(R) value carried by a STAT/USTAT.

2. VT(S): Next highest seqno to be transmitted.

1. This also implies that VR(H) < VR(MR).

A–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Guidelines for Peer-to-Peer Credit Flow Control and Receive Buffer Sizing December 1999

GR-2878-CORE

3. VT(MS): Maximum seqno to be transmitted. It is updated by the VR(MR) value conveyed by a STAT/USTAT. The transmitter stops transmitting new PDUs if VT(S) reaches VT(MS).

Note that once VT(S) reaches VT(MS), a larger VR(MR) value must be provided by the receiver before the transmitter can transmit new user PDUs. (The transmitter continues transmission of management PDUs such as STATs, USTATs, POLLs, etc., and the retransmission of missing or dropped user PDUs while it has no credit to transmit new user PDUs.)

When VT(S) reaches VT(MS), the transmitter starts TIMER_NO-CREDIT, which has a default value of 1.5 seconds. If this timer expires before the no-credit situation is remedied the link is taken out of service. This aspect of the protocol must be considered if the credit mechanism is used as a method of flow control. Another important aspect in this regard is the impact of a no-credit situation on link error monitoring. In the event of a credit-rollback (i.e., when the credit is taken away for an already transmitted PDU), retransmissions may occur and will be regarded as "errors'' by the error monitor. The proposed SAAL error monitor does contain a provision to handle this situation: the monitor requires that the no-credit situation be reported to layer management by the transmitter. The error monitor, residing in layer management, monitors this indication, and ignores any retransmissions while the no-credit situation is in effect. Thus, as long as the discarding happens due to credit-rollback, the error monitor will not take the link out of service. However, this disabling of the error monitor during zero credit periods also implies that link errors will go unnoticed by layer management. Thus, if the zero credit periods occur frequently and prevails for several polling intervals, the link may suffer sufficient errors to warrant its removal from service, but will not actually be taken out of service.

A.2 Credit Assignment Schemes

As stated in Section A.1, SSCOP does not provide any specific mechanism for advancing the VR(MR) counter. The following discussion proposes two simple schemes for doing so.

• Moving Credit: In this scheme, whenever a PDU with the next expected seqno is received, both VR(R) and VR(MR) move forward by one, thereby leaving the available credit unchanged. If an out-of-sequence PDU is received, VR(MR) is not advanced. The following points can be noted regarding this scheme:

1. If an adequate amount of credit is granted initially, that credit is maintained continuously so long as there are no link errors. That is, the scheme does not, as such, provide any flow control.

2. Flow-control can be effected if VR(MR) is incremented when a PDU is accepted by level 3, rather than when it is received by level 2. In this case, the credit will fall to zero if level 3 remains congested for some time, and will grow back when it can accept messages again.

A–2

ab


3. The flow-control mechanism ensures the credit never exceeds the available buffer space, i.e., buffer space will never run out before the credit has.

• Fixed Credit: Here VR(MR) does not move automatically on the reception of an in-sequence PDU. Instead, VR(MR) is explicitly advanced by the receiver periodically. For example, every time the receiver sends out a STAT, it may advance VR(MR) by a fixed amount, say NR. In general, VR(MR), may be advanced after every "block" of some bc 1 STATs. The main points regarding this scheme are as follows:

1. Even under no-error conditions, the amount of credit granted determines the average rate at which the receiver will accept the PDUs. That is, this scheme can perform flow control without having to depend on the filling up of the receive buffer.

2. By choosing NR such that the rate at which the PDUs are passed to level 3 remains below the processing rate of level 3, the scheme can control level 3 congestion.

3. In the moving credit scheme, a USTAT PDU and every STAT PDU communicates an updated VR(MR) value to the transmitter. In contrast, in this fixed-credit scheme, VT(MS) changes only as a result of credit-granting STATs sent periodically (i.e., every nth STAT PDU as conveyed by parameter bc).

4. To avoid granting more credit than the available receive buffer space, the scheme must specifically limit the granted credit to max (NR - O, 0) where O is the occupied buffer space in messages.

In general, the receive buffer may hold two types of PDUs: (a) out of sequence PDUs that cannot be delivered to level 3, and (b) in-sequence PDUs (i.e., those with a seqno of less than VR(R)) which are not yet accepted by level 3. The precise mechanism of transferring in-sequence PDUs to level 3 depends on architectural details of the network element, and may be such that in-sequence PDUs remain in the receive buffer for some time even if level 3 is not congested. For example, if level 3 scans all its level 2 buffers periodically, the PDUs will accumulate in the receive buffer until the next scan instant. Thus, in the event of link errors or a slow transfer rate to level 3, the receive buffer may become full. If the transmitter is assigned more credit than the available receive buffer space, more PDUs will continue to arrive and will be dropped. The resulting retransmissions will be considered as "errors'' by the error monitor. It is also possible that the PDU with a sequence number of VR(R) is dropped while the receive buffer is being occupied by out-of-sequence PDUs (which could result in a deadlock situation since out-of-sequence PDUs cannot be delivered to level 3). To avoid these problems, the assigned credit should never exceed the available buffer space.

Neither the moving credit nor the fixed credit scheme needs any specific assumptions regarding how the messages are transferred from level 2 to level 3, as long as the transfer scheme is "fair'', i.e., the rate at which level 3 attempts to take PDUs from a given link is roughly proportional to its engineered PDU rate. For example, if the credit scheme is designed to allow a DS1 SAAL link to carry n DS0 links worth of traffic, level 3 must

≥

A–3


GR-2878-CORE

attempt to take messages from the SAAL links at n times the rate at which it takes messages from a DS0 link.

The next two sections address the problem of estimating the required credit (and hence the required receive buffer size) for both moving and fixed credit schemes. Section A.3 examines the case where no processing capacity limitations exist on the receive end, i.e., when link errors and potential starvation due to lack of credit are the only concerns of the receiver in choosing to grant credit. Section A.4 addresses the case when the processing capacity limitations require the credit to be reduced below the levels recommended in Section A.3. Since the processing capacity limitation may be a temporary phenomenon, the receive buffer sizing should always assume adequate level 3 capacity.

Although ANSI and ITU standards do not contain any specific guidelines for credit allocation, they do provide a default window size (Annex F in ANSI T1.637[6]). This default size assumes ample processing capacity and is chosen to have a negligible impact on performance in the presence of link errors, i.e., give almost the same performance as an infinite window size. Accordingly, the default size allows up to three PDU losses connected with a given sequence number (e.g., loss of a user PDU, followed by a loss of a USTAT PDU, followed by a loss of a POLL or STAT PDU). This may be overly pessimistic and may result in large receive buffer size requirements. Thus, even in the absence of processing limitations, it may be desirable to allocate a smaller credit, as discussed in the next section.

A.3 Basic Credit Requirements

Initially, it is assumed that there are no link errors and the minimum credit needed is established to ensure that the transmitter can indefinitely transmit PDUs at the full link capacity. It is clear that regardless of the scheme for updating VR(MR), the updated value is reflected on the transmit side (by the assignment of VT(MS) = VR(MR)) only when a STAT arrives. Thus, when a STAT arrives and updates VT(MS), the new value of VT(MS) must be large enough to allow the transmitter to keep going until the next STAT arrival. Let Tpoll denote the polling interval and ds denote a suitable measure of the jitter in the arrival time of successive STATs. (Setting ds as twice the standard deviation of STAT inter-arrival time should be adequate in most situations.) Then the transmitter should have enough credit to keep transmitting for the Tpoll + ds seconds. Let rpdu denote the maximum rate at which user PDUs can be transmitted, and BEmin denote the required minimum credit. Then Cmin rpdu (Tpoll+ds). Let ncells denote the average PDU size in cells at the ATM layer, and rlink denote the link speed in cells/second. Then rpdu can be estimated as:

rpdu = [rlink - 2/Tpoll]/ncells. (A-1)

For a DS1 link with Tpoll = 0.1 sec,

rpdu 3600/ncells.

≥

≈

A–4

ab


The second consideration in setting the credit is the effect of nonzero end-to-end transit delay of POLLs and STATs, henceforth denoted as eu. eu includes the one-way propagation delay (tp), plus the processing, queuing, and transmission time of management messages (tu). Of these, the first can be regarded as approximately constant, whereas the second one can be measured in some suitable way (e.g., a 90-percentile value). Thus, eu can be measured as:

eu = tp + tu (A-2)

Because of the delay eu, the transmitter and receiver don't have the same view of the SSCOP state. Let Tu denote the maximum number of PDUs that can be transmitted during the time eu. Now, at the time of sending a STAT, VR(MR) = VR(R) + C on the receive side, where C is the allocated credit; however, the transmitter could already be ahead by Tu, i.e., VT(S) may already be VR(R) + Tu. By the time the STAT reaches the transmit end, VT(S) could have advanced by another Tu. Thus, the additional credit given by the next STAT is not C, but only C - 2Tu. It follows that

BEmin = rpdu(Tpoll + ds + 2eu). (A-3)

Because of frequent link rearrangements, it is undesirable to use the actual link length in estimating tp. For regional networks, it seems adequate to use a design link length of L = 2500 miles, which gives a one-way propagation delay of 25 ms (using the 0.01 ms/mile rule). Assuming that the SSCOP implementation gives highest processing priority to management PDUs, POLLs and STATs should encounter very little queuing delay. In the HSL context, it is also reasonable to expect that SSCOP/CP5 will deliver one PDU at a time to the ATM layer (instead of doing a batch transfer). In such a case, POLLs/STATs should not encounter any queuing delays at the ATM layer either. Thus, tu perhaps should not exceed a few milliseconds. The variability in transit delay yields the jitter ds, which also should be very small in the HSL context.

Let us now consider the impact of link errors on the credit requirement. Link errors affect credit allocation only if there is a significant chance that link errors will make the separation between VR(R) and VR(H) larger than BEmin. A single link error (which results in a USTAT being generated almost immediately) results in about a 2eu-second delay before the retransmitted PDU will arrive again. This results in a separation of only 2 eu rpdu between VR(R) and VR(H), which is less than BEmin. However, if the USTAT or the resulting retransmission get lost, re-reception can be delayed by as much as Tpoll + 2eu seconds (because the second loss will be reported by the next STAT). Thus, a credit of BEmin allows for one or two losses, which appears reasonable.

Links often suffer from severe error bursts such that during the error burst almost all PDUs are lost or corrupted. If the user PDUs are long, it is possible, but unlikely, that POLLs/STATs get through, but the user PDUs do not. In this case, the transmitter keeps getting updated credit and keeps transmitting throughout the error burst. The SAAL error monitor is designed to ride over error bursts of length up to tb = 0.4 seconds. Thus, following the error burst, the separation between VR(R) and VR(H) could be tb rpdu, and grow to

A–5


GR-2878-CORE

(tb + 2eu) rpdu until the first retransmission arrives. It seems reasonable to let BEmax = (tb + 4eu) rpdu, since random errors following the burst are highly unlikely.

Under normal conditions, the credit granted, say BE, can be set somewhere between the limits BEmin and BEmax. The receive buffer size must be chosen to be greater than or equal to BE. A larger credit requires more buffer space, but results in fewer unnecessary transmissions in cases of long error bursts. Given that long error bursts occur only rarely, the advantage of a larger buffer size may be insignificant. In fact, a large buffer may be undesirable from the delay perspective.

With the moving credit scheme, the appropriate credit is granted by simply setting VR(MR) = BE initially. With the fixed credit scheme, one first needs to determine the credit allocation interval. Since a new credit can be provided only with the granularity of polling, it is convenient to specify the credit allocation interval in the units of polling intervals, henceforth denoted as bc. Assuming, for simplicity, that the queuing/processing delays experienced by successive POLLs (and STATs) are i.i.d. (independent, identically distributed random variables), the jitter in the inter-arrival time between successive STATs is bc ds. Therefore, the minimum credit requirement for the fixed credit scheme is given by:

BEmin = rpdu (bc Tpoll + bc ds + 2 eu). (A-4)

The BEmax value does not change as it depends only on the length of the error burst that the error monitor must tolerate.

There are several considerations for choosing the allocation interval bc. (The following discussion assumes a polling interval of 100 ms.)

1. As bc increases, less control is exercised on the arriving traffic over short periods. For example, with bc = 10, a DS1 SAAL link could dump about 3600 cells of user traffic on the receive end before the credit is shut off.

2. A large bc requires a large receive buffer to hold the traffic in the event of a level 3 congestion event.

Substituting equation (A-2) in (A-4), yields:

BEmin = rpdu [bc Tpoll + ds bc + 2tu + 2tp] (A-5)

It is clear that as bc increases, the contribution of tp goes down. This is significant, since tp is chosen based on the maximum link length rather than the actual length. Thus for very short links, the tp portion in the equation (A-5) denotes the "error'', i.e., the overestimate in the credit requirements. A larger bc results in a lower error.

From these considerations, a bc in the range of 3-5 STATs seems appropriate. With tp = 0.025 secs, and a negligible tu, the percentage overestimate in the credit is about 16.7% for bc = 3, and 10% for bc = 5.

A–6

ab


A.4 Impact of Level 3 Capacity on Credit Allocation

If the level 3 processor cannot handle the full engineered rate of the high speed SAAL link, the fixed credit scheme may need to grant smaller credit than BEmin. Let r'pdu denote the actual traffic rate on the SAAL link that MTP level 3 can handle. Then the required credit can be computed by simply substituting r'pdu for rpdu in equations (A-3) and (A-4). That is, the credit requirement to accommodate the processing rate of MTP level 3 (BEL3) is given in the following equation:

BEL3 = r'pdu (Tpoll + ds + 2 eu) (A-6)

and for the fixed credit method:

BEL3 = r'pdu (bc Tpoll + bc ds + 2 eu). (A-7)

The appropriate technique for estimating r'pdu depends on the precise details of the situation involved. Following are two simple examples illustrating how r'pdu may be determined.

Suppose that the signaling needs or the available capacity indicate that only a fraction of the bandwidth of a DS1 SAAL link need be supported. Then, r'pdu = rpdu.

Suppose that the average occupancy of the level 3 processor without the SAAL link is projected to be no more than u Erlangs, which is less than the desired engineered load of, say ue. Then,

r'pdu = (ue - u)/sL3 (A-8)

where sL3 is the average processing time of a message by MTP level 3.

In estimating r'pdu, it is important to specify the prevailing operating conditions of the nodes on either end of a SAAL link. For example, suppose that SAAL links are used between two pairs of STPs (in B or D link sets). In this situation, each SAAL link will be engineered to carry 0.2 Erlangs of traffic, so that a double failure can be tolerated. If the credit allocation is done here based on normal conditions, the granted credit will be inadequate under failure scenarios. On the other hand, if the credit allocation scheme assumes a double-failure scenario, the credit granted under normal conditions will be 4 times the expected value, which will allow a substantial surge in traffic before the flow-control goes into effect. Of these, the latter method seems more appropriate as it does not restrict the traffic unnecessarily. A third option is to vary the granted credit appropriately as a side effect of SS7 TFR/TFP/TFA procedures.

A.5 Impact of Message Size

SSCOP requires that the credit be specified in PDUs. However, equation (A-1), which is required in this estimation, involves ncells, the average PDU size in units of ATM cells. Estimating ncells, in turn, requires detailed knowledge of message lengths so that the overhead of padding and PDU headers could be computed correctly. Since actual message

ηη

A–7


GR-2878-CORE

sizes could be different from those assumed, the credit to be given may be either underestimated or overestimated. In particular, if the actual message sizes are larger than assumed in equation (A-1) the granted credit is more than required. On the other hand, if the actual message sizes are smaller than estimated, the granted credit will be inadequate. Of these two situations, the former is perhaps preferable as it avoids unnecessary flow control. Since a fill-up of the receive buffer will eventually cut-down the credit, the flow control will still take effect eventually, although somewhat belatedly.

Depending on the implementation details, the receive buffer may either hold SSCOP PDUs or MTP3 messages. Since SSCOP headers are really not needed, it is more efficient to store data in MTP3 format in the receive buffer. In any case, so long as the receive buffer is sized in terms of MTP3 messages or PDUs, the available buffer space is known precisely, and it is trivial to ensure that the granted credit does not exceed the available space. Unfortunately, this is not the case if the receive buffer is sized in terms of bytes. (Byte sizing is attractive, as it puts a hard limit on memory requirements and delays experienced.) With byte sizing, there are two important issues to consider:

1. Determining buffer size to be allocated (needed only during the SSCOP connection setup)

2. Determining available buffer space in terms of messages at the time of the VR(MR) update (needed if not all the received messages have been accepted by MTP level 3).

Let us first address these issues assuming that there are no capacity limitations at level 3. Then, equation (A-3) or (A-4) can be used for credit allocation. In this case, a conservative estimate of required buffer size can be obtained by using the same equations but by considering rpdu in the units of bytes/second. In particular, a DS1 SAAL link can carry at most 3600 x 48 = approximately 172 Kb/s of user traffic. Thus, irrespective of the quality of the estimates of ds and tu, the receive buffer size computed using rpdu = 172 Kb/s in the credit formulae cannot fall short, as long as no backlog develops in the receive buffer. Now, if the backlog does develop, both credit schemes will reduce allocated credit by the number of backlogged PDUs. (In the moving credit scheme, this adjustment occurs automatically, whereas in the fixed credit scheme, the credit must be explicitly reduced.) However, if messages transmitted in the credit allocation interval are longer, the link may carry more than the allowed number of bytes. In the absence of a level 3 capacity limitation, a large backlog is highly unlikely; therefore, the problem can be addressed by a slight increase in the buffer size. In fact, since the credit allocation and buffer sizing scheme already assumes a rather extreme situation with respect to end-to-end transit delays, an increase is not even necessary for all practical purposes.

If the level 3 capacity limitation does exist, larger backlogs are possible, however, the allocated credit is also smaller. Thus, unless a smaller receive buffer size is used in this situation, it should work just fine here as well.

A–8

ab


A.6 Guidelines

This section summarizes the discussion on credit allocation and buffer sizing, and provides some guidelines for choosing the scheme and the credit/buffer amounts for it.

It is clear from the preceding discussion that both moving and fixed credit schemes can provide effective flow control. The moving credit scheme is somewhat simpler to implement, but does not provide a rate control. Instead, as MTP level 3 starts to fall behind, the PDUs accumulate in the receive buffer until the receive buffer is full and the credit drops to zero. As a result of this behavior, if the arrival rate on the SAAL link fluctuates, these fluctuations will be directly transferred to level 3. In contrast, the rate control provided by the fixed credit scheme smooths the traffic coming to level 2. Unfortunately, the credit allocation in the fixed-credit scheme should also be conservative and should avoid credit starvation under failure conditions. Consequently, the fixed credit scheme may also not achieve a very tight rate control. Overall, it appears that the fixed-credit scheme is somewhat superior, but not by much.

In the current SAAL application, a pair of nodes may have only two SSCOP connections. In such an environment, it may be adequate to hard code the receive buffers sizes, rather than allocating buffer space dynamically at the time of SSCOP connection establishment. In such an environment, the receive buffer should be sized assuming ample processing capacity, since the limited processing capacity may be a temporary condition. Let BE denote the chosen credit value in the range BEmin and BEmax, as discussed in Section A.3. If the receive buffer is sized in terms of messages, the appropriate size is BE itself. However, if the buffer is sized in bytes, the size should be computed by using the following procedure: First, compute BEmin using equations (A-3) or (A-4) with rpdu expressed in bytes/second. Then scale up this value to correspond to the chosen BE value.

Let Fc denote the desired credit. In the absence of MTP level 3 capacity limitations, Fc = BE, where BE is computed as detailed in Section A.3. Under MTP level 3 capacity limitations, Fc = BEL3, where BEL3 can be computed following the suggestions described in Section A.4. When the SSCOP connection is established, the SSCOP transmitter may unilaterally assume a credit of Fc PDUs. That is, VT(MS) can be initially set to Fc. Subsequently, the moving credit scheme will automatically regulate the credit appropriately. However, the fixed credit scheme will need to compute a new credit value every bc polling intervals. The computed value should be set to max (Fc-O,0), where O is the current occupancy of the receive buffer in messages. This will ensure that the allocated credit never exceeds the available buffer space, as desired.

The effective MTP level 3 processing capacity available for a given SAAL link may change due to processor upgrades or introduction of more links. Therefore, the allocated credit BE and the allocation interval bc should be easily provisionable. For memory administration purposes, we propose the appropriate range for bc to be 1 to 5 polling intervals with a default of 3 intervals. Assuming an average PDU size of 1.2 cells, zero jitter, and zero length link, the lower bound on BEmin is thus 300. With the same PDU size, a link length of 5000 miles, a processing/queuing delay of 20 ms, and a jitter of 12 ms

A–9


GR-2878-CORE

between STATs, the upper bound on BE is about 2000. (A larger PDU size will only result in a smaller estimate of this upper bound.) The default value of BEmin is proposed to be 1200, which corresponds to bc = 3 with another 100 ms available for jitter and end-to-end delay.

A–10

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Overview of SAAL Error Monitors

Appendix B: Overview of SAAL Error Monitors

B.1 SAAL Error Monitor

This section provides a brief overview of a SAAL “reference” error monitor, which has been accepted by the ITU-T and ANSI as an example of an error monitor that satisfies all error monitoring criteria specified in the ITU-T Draft Recommendation Q.2144,[11] Section 9.1.1. More detailed descriptions of the error monitor, including default parameter values, are contained in Appendix II of ITU-T Q.2144[11] and ANSI T1.652,[8] Annex B. This error monitor comprises three algorithms, summarized as follows.

1. Algorithm 1: This is intended for high error rates. It removes the link from service whenever the queue of untransmitted and unacknowledged messages, i.e., the sum of the SSCOP transmission queue and transmission buffer, exceeds the maximum queue that could be caused by an error burst of length 400 ms, given the input traffic and link capacity. This algorithm responds accurately to extreme traffic conditions (e.g., overload) as well as expected traffic conditions. Algorithm 1 periodically (every

seconds) makes a determination of whether the link should be taken out of service. It computes the number of bytes arrived (NA), number of bytes given to the ATM layer for transmission (NT), and the number of bytes acknowledged (or expunged from the transmit buffer) (NF) during the last seconds. From this information, it computes the current transmit congestion and a (dynamically changing) threshold. If the transmit congestion goes above the threshold, the link is taken out of service. This algorithm handles a no-credit situation by setting NT to zero during zero-credit measurement intervals. Algorithm 1 needs to examine the message to determine the number of bytes, every time a message arrives at the SSCOP layer, is given to the ATM layer for transmission/retransmission, or is acknowledged by the receiver. Since the error monitor resides in the layer management function, the processing needed to compute NA, NT and NF must be done by SSCOP/SSCF. None of this computation is required in the current SSCOP/SSCF specification, and must be done as an implementation enhancement. The reporting of NA, NT and NF to layer management also constitute an implementation enhancement.

2. Algorithm 2: This is intended for intermediate error rates. It removes the link from service when retransmissions occur too frequently within the monitoring intervals. This algorithm is parameterized so that it acts when the errors are sufficient to cause unacceptable delays, but allows Algorithm 1 to take precedence when the error is severe enough to cause sufficient queue build up.

Algorithm 2 sets a penalty factor of 1 or 0 for each monitoring interval, depending on whether any retransmissions occurred during that interval. It then computes an average penalty factor over a block of N measurement intervals, and performs exponential smoothing over successive intervals. If at the end of any block, the smoothed penalty factor exceeds a threshold, the link is taken out of service.

Ta

Ta

B–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Overview of SAAL Error Monitors December 1999

GR-2878-CORE

Algorithm 2 handles a no-credit situation by ignoring retransmission reports during intervals with zero credit.

Algorithm 2 only needs a signal whenever a STAT/USTAT results in retransmissions. Current SAAL standards require this information to be supplied by SSCOP to the layer management function.

3. Algorithm 3: This is intended for very low and zero user-traffic situations, where the other two algorithms will become ineffective. This algorithm counts the POLLs sent and STATs received over a large block, termed a superblock. If the difference between the POLLs sent and STATs received exceeds a threshold, it takes the link out of service.

Algorithm 3 requires that SSCOP inform layer management of a STAT arrival even if that STAT does not result in any retransmissions. This information is currently not required to be supplied by SSCOP to layer management.

Because of the overhead of measuring NA, NT and NF in bytes, it may be desirable to consider a variation of Algorithm 1 where these quantities can be measured in PDUs. A preliminary examination of this option indicates that it can work satisfactorily. However, more detailed testing is recommended prior to its implementation.

B.2 Proving Algorithm

This section provides a brief overview of a SAAL proving algorithm, which has been accepted as the ITU draft recommendation. A detailed discussion of the proving criteria is contained in the ITU-T Draft Recommendation Q.2144,[11] Section 9.4.

The proving algorithm for SAAL links is an adaptation of the AERM (Alignment Error Rate Monitor) used for proving 56/64-Kb/s CCS links. The algorithm sends test PDUs over the link at a specified proving PDU rate r over a proving period of 1 minute. If the link suffers from more than one error during this time, the proving is tried again, otherwise, the link is returned to service. The PDU rate r is determined such that the proving procedure is in consonance with the in-service error monitor. That is, if the existing error rate is such that the error monitor will take the link out of service in a matter of minutes or less, the proving algorithm should have almost zero probability of proving the link in 8 minutes (the provisional value of the MTP level 3 craft referral timer, T19/T111.4). The parameter r depends on the link speed, as specified in Section 9.4 of Recommendation Q.2144.[11] For a 1.5-Mb/s link, r = 1322 cells/sec, which corresponds to a 0.365 Erlang load.

For the default settings of the SCCF parameters defined in Table 3-1 of this GR (T3 = time between proving PDUs = 1000 µsec, and n1 = number of proving PDUs = 60000, corresponding to a default normal proving period of 60 seconds), and assuming an ATM-layer data rate of 3622 cells/second and a proving PDU size of one ATM cell, the equivalent average link occupancy during proving is approximately 0.276 Erlang.

B–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Analysis of HSL Transmit Congestion Thresholds

Appendix C: Analysis of HSL Transmit Congestion Thresholds

This appendix provides an overview of the Telcordia analysis supporting the recommendations for transmit buffer size described in Section 3.3.2.1 and guidelines for setting transmit congestion thresholds in CCS nodes.

C.1 Link Transmit Congestion Control

The HSL buffer size and transmit congestion guidelines for STPs and SCPs are based on the results from a simulation study of HSL transmit congestion. The simulation modeled many aspects of the SS7, SSCOP, and ATM protocols, call and message processing scenarios, link and route set congestion, traffic mixes, customer behavior, and network architecture applicable to HSL deployment in LEC CCS networks.

The network architecture used for the HSL transmit congestion simulation included a dual-LATA network with 2 STPs, 32 SSPs, and 1 SCP. The first LATA (LATA-1) is represented by an STP (STP-1) with 16 SSPs and the second LATA (LATA-2) is represented by an STP (STP-2), also with 16 SSPs, as well as an SCP (SCP-1). A conceptual view of this network model is shown in Figure C-1.

The network architecture model considered in the simulation, as shown in Figure C-1, consisted of 1.536-Mb/s HSLs for the B-links between the STPs and the A-link between the SCP and STP-2. The A-links between the SSPs and STPs have link speeds of 56-Kb/s.

Figure C-1. Network Architecture for HSL Simulation

SSP 101

SSP 116 SSP 216

SSP 201SCP-1

STP-1 STP-2

1.536-Kb/s

56-Kb/s

LATA-2LATA-1

C–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Analysis of HSL Transmit Congestion Thresholds December 1999

GR-2878-CORE

The HSL simulation examined transmit congestion thresholds and associated buffer sizes for HSLs implemented between a pair of STPs and between an STP and SCP to verify the network performance during various overload conditions. The overload on HSLs were simulated by increasing the offered loads from the SSPs. In particular, the simulation examined the relationship between specific onset (Oi), abatement (Ai), and discard (Di) transmit buffer thresholds and their impact on the message throughput and end-to-end delay. This relationship was used to identify an optimum set of threshold values which optimized throughput and minimized delay. The following performance criteria were used to evaluate the network performance and determine the optimal threshold values:

• Call Throughput

Call throughput is measured in terms of the number of calls that are completed at the application layer (i.e., level 4). A goal of the study was to achieve the highest call throughput subject to the constraints of the message delay and message discard criteria.

• End-to-End Message Delay

The one-way end-to-end delay at the application layer (i.e., application level to application level) was not to exceed 1 second for 95 percent of the messages processed during loads of 2.0 Erlangs.

• Message Discard

Message discard is measured in terms of the number of messages discarded due to congestion at an STP at MTP level 3 and was expected not to exceed 1 percent of the total messages received at an STP.

C.1.1 STP-STP HSL Transmit Congestion

The simulated traffic for the study of STP-STP HSL congestion consisted of ISUP messages (i.e., IAM, ACM, ANM, REL, and RLC messages). The ISUP and network management message lengths, shown in Table C-1, were used for the study.

Table C-1. Message Categories

Message Category Message Type Octets/Message

ISUP Initial Address Message (IAM) 45

Address Complete Message (ACM) 20

Answer Message (ANM) 18

Release Message (REL) 22

Release Complete Message (RLC) 17

C–2

ab


In addition, the following message priorities were used for each of the ISUP messages: IAM = priority 0; ACM/REL = priority 1; ANM/RLC = priority 2.

Three categories of call processing capacities, referred to as small, medium, and large, were specified for the SSPs. The study assumed 12 small SSPs, 6 in each LATA, each with a call rate capacity of: 60,000 calls/hour; 8 medium SSPs, 4 in each LATA, each with a call rate capacity of 192,000 calls/hour; 12 large SSPs, 6 in each LATA each with a call rate capacity of 384,000 calls/hour. The following offered loads were generated on the A-links from the SSPs to the STPs: 0.199 Erlangs from the small SSPs, 0.636 Erlangs from the medium SSPs, and 1.271 Erlangs from the large SSPs, which resulted in an offered load of 0.789 Erlangs on the HSL between STP-1 and STP-2. The appropriate number of links in the A-link sets is determined by the simulation model based on the offered load values and an engineered load of 0 .4 Erlangs.

Based on the simulation results, the preliminary recommendations for STP HSL congestion thresholds and total buffer size measured in seconds are shown in Table C-2.

The threshold conversion to messages is based on the following:

where ‘A’ is the threshold in seconds identified in the first row of Table C-2, 3600 cells/sec is the approximate ATM cell rate for DS1 links, and 1.2 is the average number of cells per

MTP Network Management

Transfer Controlled Message (TFC) 40

Signaling Route Set Congestion Test Message (SRSCT)

20

Table C-2. Preliminary STP-STP HSL Congestion Threshold and Buffer Size Recommendations

A1 O1 D1 A2 O2 D2 A3 O3 D3 Total Buffer

Size

seconds .26 .31 .83 .88 .93 1.45 1.50 1.55 1.75 1.91

messages 780 930 2490 2640 2790 4350 4500 4650 5250 5730

octets 19.5K 23.25K 62.25K 66K 69.75K 108.75K 112.5K 116.25K 131.25K 143.25K

Table C-1. Message Categories (Continued)

Message Category Message Type Octets/Message

A 3600× cellssec------------

1.2cellsmsg------------

--------------------------------------

C–3


GR-2878-CORE

message, assuming an IAM message requires 2 cells and the other ISUP messages require 1 cell. The threshold conversion to octets is based on the following:

where ‘B’ is the threshold in messages identified in the second row of Table C-2, and 25 is the average message length in octets.

C.1.2 STP-SCP HSL Transmit Congestion

The traffic for the STP-SCP HSL congestion was simulated using TCAP messages with an average message length of 90 octets. Only level-1 congestion thresholds (i.e., A1, O1, and D1) are considered, since TCAP messages include only priority-0 messages.

Simulation results indicated that when the same level-1 thresholds are used as recommended for STP-STP HSLs, only a slight increase in delays were experienced. Call set-up delays increased only slightly and end-to-end delays at the SCP was smaller than those observed for STP-STP HSL congestion. Overall, better performance was observed on the STP-SCP HSL with the same level-1 thresholds recommended for STP-STP HSLs, as those shown in Table C-2. The preliminary recommendations for STP-SCP HSL congestion thresholds and total buffer size measured in seconds are shown in Table C-3.

The total buffer size allows the same separation between the discard threshold and the total buffer size as that recommended for STP-STP HSLs to accommodate network management messages.

The threshold conversion to messages is based on the following:

Table C-3. Preliminary STP-SCP HSL Congestion Threshold and Buffer Size Recommendations

A1 O1 D1 Total Buffer

Size

seconds .26 .31 .83 0.99

messages 312 372 996 1188

octets 28.08K 33.48K 89.64K 106.92K

B 25octsmsg----------×

A 3600× cellssec------------

3cellsmsg------------

--------------------------------------

C–4

ab


where ‘A’ is the threshold in seconds identified in the first row of Table C-3, 3600 cells/sec is the approximate ATM cell rate for DS1 links, and 3 is the average number of cells per TCAP message. The threshold conversion to octets is based on the following:

where ‘B’ is the threshold in messages identified in the second row of Table C-3, and 90 is the average TCAP message length in octets.

C.2 Message Size Sensitivity of Buffer Thresholds

The congestion thresholds discussed in Section C.1 are based on current SS7 message sizes with an average ISUP message size of 25 bytes and an average TCAP message size of 90 bytes. This section discusses how the congestion control procedures would perform if the actual messages in the network are much longer. This is an important aspect of setting congestion thresholds since the message sizes are expected to increase in the future as more parameters are used to support AIN services. Since vendors may implement congestion thresholds in terms of either messages or bytes, both situations are examined and compared here.

An increase in message size will increase delays under normal conditions, and will cause more severe link overloads with the same degree of overload in terms of call setup volume. In particular, if an STP-STP or STP-SCP HSL link is experiencing congestion, the end-to-end delay (D) experienced by messages will increase. Thus, an important side effect of increased message size is that the desired objective of P(D>1 second) < 5% (i.e., the probability of D>1 second remaining less than 5%) will be difficult to meet. Another impact of increased message size is the drop in call throughput under overload conditions. There are two aspects that lead to a decrease in call throughput:

1. As message size increases, the link capacity in messages/second goes down. Thus, the maximum achievable call throughput will decrease in proportion to the increase in message size measured in terms of ATM cells.

2. The congestion control scheme may work differently for longer messages and thus result in further reduction in call throughput.

The first condition will occur irrespective of the congestion control scheme used, and thus for a fair comparison of call throughput with different message sizes, they should be scaled appropriately. The second effect is a function of the congestion control scheme, and is of primary concern in this sensitivity study. Our analysis indicates no significant impact in this regard, i.e., the scaled call throughput is insensitive to the message size. The message discard probability also does not appear to show much sensitivity to message size.

The impact of increased message size on the end-to-end delay D depends on whether the buffer thresholds are set in terms of messages or bytes. With a byte implementation, an

B 90octsmsg----------×

C–5


GR-2878-CORE

increase in message size allows fewer messages to accumulate before a given threshold is reached, which tends to limit message delays under congestion conditions. Such an advantage is not accrued if the thresholds are implemented in terms of messages.

Our analysis indicates that with byte implementation, the overall delay remains about the same if the comparison is made at the same actual overload level. For example, suppose that with the present message sizes, the normal call volume results in a 0.8 Erlang load on the HSL link. Then a 2.5 fold increase in call volume will currently result in a 2.0 Erlang offered link load. However, if the average message size, measured in terms of ATM cells, increases by a factor of 1.2, the same 2.5 fold increase in call volume will result in an actual offered load of 2.4 Erlangs on the link. Under these conditions, P(D>1 sec) will be higher than 5% with both byte and message thresholding (because the 5% objective applies only to a 2.0 Erlang actual load). However, if the call volume increases only by a factor of 2.08 under long-message conditions, the link will experience a 2.0 Erlang actual load. The analysis shows that in this case, the 5% objective is met when thresholds are set using bytes and exceeded when set using messages. Thus, it is concluded that thresholds using bytes show a better behavior in terms of sensitivity compared to thresholds set in message sizes.

In the example just described, the unacceptable delay performance when the message increases 1.2 fold and the call volume is 2.5 times the normal can be viewed in two ways:

1. Since the link load increases by the same factor of 1.2 even under normal call volume, thereby increasing the link load from 0.8 Erlangs to 0.96 Erlangs, it is time to put in another link to handle the offered load. In this case, the question of unacceptable delay performance becomes irrelevant.

2. The original setting of thresholds should anticipate the increased message size and thereby assume longer messages (e.g., 1.2 x 25 = 30 bytes) to start with. In this case, the 30 byte size will be used for both choosing the thresholds and engineering the link. That is, the normal call volume will initially place a load of only 0.8/1.2 = 0.67 Erlangs instead of 0.8 Erlangs. As a result, with byte thresholds, desired delay performance will be obtained if the average message size increases 1.2 fold and the call volume becomes 2.5 fold.

Thus, in either case, desired congestion performance can be obtained if the thresholds are implemented in bytes.

C–6

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 HSL Measurement Summary

Appendix D: HSL Measurement Summary

This appendix provides a quick-reference summary of required and objective HSL measurements to be collected from CCS nodes for multiple operations purposes. It is based on Performance Management and NDC requirements specified in Section 4 and operations interface requirements presented in Section 5.

• Section D.1 provides a summary and comparison of such measurements as collected for HSLs vs. MTP2 links. Also specified for the HSL measurements are objective measurement labeling criteria to be used by STPs and SCPs supporting the data collection interfaces defined in GR-310-CORE[26] and TA-NWT-000365.[30]

• Section D.2 provides a comparison of the specific measurements to be used as link marginal performance indicators for each link type.

D.1 HSL and MTP2 Measurements Comparison

Table D-1 lists required HSL measurements and includes a comparison of the measurement types to be collected from HSLs and/or HSL link sets, and those to be collected on current MTP2 (56 Kb/s) signaling links and link sets. Some such measurements are common to both link types, while others are unique to HSLs. Still others may be similar or functionally equivalent to one another for each link type, differing only in terms of their definitions, units, and nomenclature, because of differences in the link-layer protocol used. Table D-1 provides the details of this comparison, along with recommended data register labels and data groupings to be used to convey these measurements via the GR-310-CORE[26] and TA-NWT-000365[30] data collection interfaces.

Table columns convey the following information:

• HSL Measurement Name [GR-310/TA-365 Measurement Register Label] (column 1): contains the name of each measurement required or recommended to be collected for HSLs based on generic operations requirements and objectives specified in Sections 4 and 5. Also included [in brackets] are the names of the recommended standardized measurement register labels to be used by the CCS node (STP or SCP) in identifying these measurement data when they are conveyed across the GR-310-CORE[26] and TA-NWT-000365[30] interfaces.

• Analogous MTP2-Link Measurement Name (column 4) conveys the approximately analogous (or in some cases the same) measurement currently required or recommended to be collected on existing MTP2 links, plus their current STP and SCP register labels as used on the GR-310-CORE[26] and TA-NWT-000365[30] interfaces [again in brackets].

• Layers (in columns 2 and 5) denote the layers of the signaling protocol stack at which each measurement is (or may be) functionally collected, and/or at which the traffic, condition or event it counts is detected. These may differ for each link type. Multiple

D–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4HSL Measurement Summary December 1999

GR-2878-CORE

layers may be involved regarding some measurements. For some measurements, the specific layers involved may be subject to the implementation. The layers cited include

— SCCP

— MTP3

— MTP2

— SAAL

— ATM.

• R E C N (in column 3) conveys the relationship between the required HSL measurement and the corresponding MTP2-link measurement listed in the table, where:

— R denotes the HSL measurement replaces the indicated MTP2 link measurement for the HSL or HSL link set, because of differences in the protocol data units being measured or functional differences in the protocol stack. The counts are not expected to be numerically equivalent unless the notation E (below) is also included for the measurement pair.

— E denotes the two measurements use different names but their counts are numerically equivalent, i.e., they measure or count the same traffic, event, or condition, and differ only in terms of the specific units measured (e.g., PDUs) or other nomenclature applicable to the link-layer protocol (e.g., counts of MTP3 messages on HSLs are equivalent to counts of MSUs on MTP2 links).

— C denotes the measurement is common to both HSLs and MTP2 links, i.e., the same measurement is collected for both link types and is independent of the link layer protocol used.

— N denotes the measurement is new and is applicable to HSLs only, i.e., it does not correspond to any analogous measurements required for MTP2 links.

Note that some of these relationships as expressed are subject to interpretation and the specifics of the HSL implementation at the CCS node.

• Basis (column 6) refers to the basis or bases on which the indicated HSL measurement type is to be collected at CCS nodes, in terms of its:

Interval/Operations Domain/Measured Object, where:

— Interval denotes the required or objective accumulation interval(s) for the measurement as defined in Section 4; one or more of:

30: 30 minutesd: daily (24 hours)m: marginal (hourly when performance thresholds are exceeded)

D–2

ab


5: 5-minute (scheduled - regardless of value)5x: 5-minute (exception only - when value is non-zero).

— Operations Domain refers to the traditional LEC operations domain name conveying the operations purpose for which the measurement collected over that interval is used; one or more of:

NDC: Network Data Collection (for Network Engineering & Planning andNetwork Administration/Capacity Monitoring)

NTM: Network Traffic ManagementM-PM: Network Maintenance - Performance Management

— Measured Object (per) denotes that the measurement is collected per link (L), per link set (LS), or per STP (STP).

Multiple bases apply to some measurement types.

• GR-310/TA-365 Data Collection Schedule/Measured Entity Type(Column 7):

conveys the data collection keyword arguments to be used to identify the data collection schedule (SCHED) (i.e., data report) and measured-entity-type (ENTTYPE) used to organize the data for transmission over the interfaces defined in those documents.

SCHED values include

— P_COMP: STP Scheduled-Polled Component Measurements

— C_COMP: SCP Node Scheduled-Polled Component Measurements

— P_SERV: STP Scheduled-Polled Service Measurements

— P_MTCD: STP Scheduled-Polled Daily Maintenance Measurements

— D_MTCH: STP On-Demand Hourly Maintenance Measurements

— D_MTCDTH: STP On-Demand Day-to-Hour Maintenance Measurements

— A_NM: STP Autonomous 5-Minute Network (Traffic) Management Measurements

— D_NM: STP On-Demand 5-Minute Network (Traffic) Management Measurements, and

— P_SYSTOT: STP Scheduled-Polled System Totals.

ENTTYPE values include

— LINK: per link

— LNKSET: per link set

— STP: per STP.

D–3


GR-2878-CORE

Plus G of 10)

HSL M

[GR-Me

Reg

ts:ementelative 2 ents

MTP3 MTransm[MSGS HSLs)

.

MTP3 MReceive[MSGS

MTP3 MTransm[MOCT

wer

or not

MTP3 MReceive[MOCT

wer AL/

)

• Comments (column 8) provide additional information on the nature of the differences between the measurements cited for each link type, such as differences in PDUs, measurement units, and link-level protocol procedures concerning the generation of the compared measurements.

The HSL measurements are grouped first according to the layer of the protocol at which they are measured, and then within each grouping, in the approximate order in which they are specified in Section 4.

Table D-1. HSL and MTP2-Links Measurements Summary and Comparison;R-310/TA-365 Interface Standardized Data Groupings and Register Labels (Sheet 1

easurement Name

310/TA-365asurement ister Label]

Layers

RECN

AnalogousMTP2-Link

Measurement Name

(GR-310/TA-365 DC Measurement

Register Label)

Layers

Basis:Interval/

Operations Domain/

Measured Object (Per)

GR-310/TA-365DC Schedule (SCHED) &

Measured-Entity-Type

(ENTTYPE)Grouping

CommenHSL MeasurDifferences R

to MTPMeasurem

essages itted TRAN]

MTP3 R MSUs Transmitted (including retransmissions)(MSUTRAN)

MTP2 30/NDC/L

30/NDC/LS

5/NTM/LSd/M-PM/L

m/M-PM/L

P_COMP/LINKC_COMP/LINKP_COMP/LNKSETC_COMP/LNKSETD_NM/LNKSETP_MTCD/LINKD_MTCDTH/LINKD_MTCH/LINK

Link layer retransmissions(at SSCOP for are not counted

essages dRCVD]

MTP3 RE

MSUs Received(MSURECVD orMSURECD)

MTP2 30/NDC/L

30/NDC/LS

5/NTM/LSd/M-PM/L

m/M-PM/L

P_COMP/LINKC_COMP/LINKP_COMP/LNKSETC_COMP/LNKSETD_NM/LNKSETP_MTCD/LINKD_MTCDTH/LINKD_MTCH/LINK

Counts areequivalent.

essage Octets ittedTRAN]

MTP3 R MSU Octets Transmitted (including retransmissions)(OCTTRAN orTOCTRAN)

MTP2 30/NDC/L

30/NDC/LS

5/NTM/LSd/M-PM/L

P_COMP/LINKC_COMP/LINKP_COMP/LNKSETC_COMP/LNKSETD_NM/LNKSETP_MTCD/LINKD_MTCDTH/LINK

Excludes any lolayer octets(SAAL/ATM fHSLs). SSCOPretransmissionscounted.

essage Octets dRCVD]

MTP3 R MSU Octets Received(OCTRECVDor TOCTRECD)

MTP2 30/NDC/L

30/NDC/LS

5/NTM/LSd/M-PM/L

P_COMP/LINKC_COMP/LINKP_COMP/LNKSETC_COMP/LNKSETD_NM/LNKSETP_MTCD/LINKD_MTCDTH/LINK

Excludes any lolayer octets (SAATM for HSLs

D–4

ab


Link MUsage [

DuratioOutage[DURL

Link Av[LNKA

NumbeChange[ACHG

Hourly ExceedAutomaChange[HTXA

Near-EUnavai[NEAR

Far-EndInhibits[FARM

NumbeLink FaTypes [

Cumulaof SignFailures[DRDC

MTP3 MReceiveGTT (S[MSGS

ivalent

MTP3 MReceiveMessagGTT (S[MOCT

wer AL/

)

Plus G of 10)

HSL M

[GR-Me

Reg


aintenance MTCEUSG]

MTP3 C Same MTP3 30/NDC/L P_COMP/LINKC_COMP/LINK

None

n of Link

KOTG]

MTP3 C Same MTP3 30/NDC/L

5x/NTM/L

P_COMP/LINKC_COMP/LINKA_NM//LINK

None

ailable TimeVAIL]

MTP3 C Same MTP3 d/M-PM/L

m/M-PM/L

P_MTCD/LINKD_MTCDTH/LINKD_MTCH/LINK

None

r of Automatic oversOVRS]

MTP3 C Same MTP3 d/M-PM/L

m/M-PM/L


None

Thresholds ed for tic oversCHOV]

MTP3 C Same MTP3 d/M-PM/L P_MTCD/LINKD_MTCDTH/LINK

None

nd Forced Link lableUNAV]


None

Management GINH]


None

r of Signaling ilures - All NMDCLFLR]


None

tive Duration aling Link - All TypesLFLR]


None

essages d Requiring TPs)RGTT]

SCCPMTP3

R

E

MSUs Received Requiring GTT (STPs Only)[MSUSRGTT]

SCCPMTP3MTP2

30/NDC/L30/NDC/LS

P_COMP/LINKP_COMP/LNKSET

Counts are equ

essage Octets d for es Requiring TPs)RGTT]

SCCPMTP3

R MSU Octets Received for Messages Requiring GTTs[OCTRCGTT]

SCCPMTP3MTP2

30/NDC/L30/NDC/LS

P_COMP/LINKP_COMP/LNKSET

Excludes any lolayer octets (SAATM for HSLs


easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–5


GR-2878-CORE

AveragTransmOccupamessagoctets)[OCCU[OCCU

nk AL/

)

Peak LiBuffer O(MTP3messag

[PKOCPKOCC

posed re verage P2

e of the n the be ble to . xcludes octets or

DuratioLink Co[TDCN

DuratioLink Co[TDCN

DuratioLink Co[TDCN

Event CEnterinConges[ECCN


Plus G of 10)

HSL M

[GR-Me

Reg


e Link it Buffer ncy (MTP3 es or message

MSGS] orMOCT]

MTP3SAAL

R Average Link Transmit Buffer Occupancy (MSUs or MSU octets)[OCCUPOCT][OCCUPMSU]

MTP3MTP2

30/NDC/L P_COMP/LINKC_COMP/LINK

Excludes any lilayer octets (SAATM for HSLs

nk Transmit ccupancy

messages or e octets)

CMSG orOCT]

MTP3SAAL

N Not required in prior GRs, but potentially applicable as well:

Link Transmit Buffer: Maximum Observed Occupancy (octets)[MAXOCCUP]

30/NDC/L P_COMP/LINKC_COMP/LINK

New msmt profor HSLs as mouseful than the aoccupancy; notrequired for MTlinks but the uspeak rather thaaverage would equally applicaboth link typesPKOCCOCT eany lower layer(SAAL/ATM fHSLs)

n of Level 1 ngestion

GLV1]

MTP3SAAL

C Same MTP3MTP2

30/NDC/L

5x/NTM/L

P_COMP/LINKC_COMP/LINKA_NM/LINK

None


GLV2]

MTP3SAAL

C Same MTP3MTP2

30/NDC/L

5x/NTM/L


None


GLV3]

MTP3

SAAL

C Same MTP3

MTP2

30/NDC/L

5x/NTM/L


None

ount for g Level 1 Link tion GLV1]

MTP3

SAAL

C Same MTP3

MTP2

30/NDC/L

5x/NTM/L


None

ount for g Level 2 Link tionGLV2]

MTP3

SAAL

C Same MTP3

MTP2

30/NDC/L

5x/NTM/L


None


easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–6

ab



PriorityMessagDue to [MSGD

ivalent


ivalent.


ivalent.

PriorityMessagDue to Buffer [

ivalent.

AveragDelay fMTP3 M[LINKD

d from e buffer

e the until tually he link.

MTP3 MSampleOutput [MSGS

the mpled

Total DSet InacSet Out[TDLSI

Plus G of 10)

HSL M

[GR-Me

Reg


ount for g Level 3 Link tionGLV3]

MTP3

SAAL

C Same MTP3MTP2

30/NDC/L

5x/NTM/L


None

0 MTP3 es Discarded CongestionISC0]

MTP3

SAAL

RE

Priority 0 MSUs Discarded Due to Congestion

[MSUDISC0]

MTP3MTP2

30/NDC/L

5x/NTM/L


Counts are equ


MTP3

SAAL

RE

Priority 1 MSUs Discarded Due to Congestion

[MSUDISC1]

MTP3MTP2

30/NDC/L

5x/NTM/L


Counts are equ


MTP3

SAAL

RE

Priority 2 MSUs Discarded Due to Congestion[MSUDISC2]

MTP3MTP2

30/NDC/L

5x/NTM/L


Counts are equ

3 MTP3 es Discarded Full Transmit MSGDISC3]

MTP3

SAAL

RE

Priority 3 MSUs Discarded Due to Congestion Full Transmit Buffer[MSUDISC3]

MTP3MTP2

30/NDC/L

5x/NTM/L


Counts are equ

e Link Output or Sampled

essages LAY]

MTP3

SAAL

R Average Link Output Delay for Sampled MSUs[LINKDLAY]

MTP2 30/NDC/L P_SERV/LINKC_COMP/LINK

Delay measureplacement in thMTP3 transmituntil last bit is submitted to thSCCF; whereasMTP2 delay is the last bit is actransmitted on t

essages d for Link DelayAMPL]

MTP3

SAAL

R MSUs Sampled for Link Output Delay (MSUSAMPL)

MTP2 30/NDC/L P_SERV/LINKC_COMP/LINK

Differs only byPDUs being sa

uration of Link tivity (Link age)NAC]

MTP3 C Same MTP3 30/NDC/LS P_COMP/LNKSETC_COMP/LNKSET

None


easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–7


GR-2878-CORE

N/A MTP2

MTP2 where rs may ssages ng over

DuratioService[SAAL

AL ent

SignalinAlignm[ALGN

AL ent.

link mmon es but ts of

uired .

SSCOPTransm(includiretransm[SDPD

ce k layer

SSCOPRetrans[SDPD

ce k layer

SSCOPOctets T(includiretransm[SDPD

replace he link

SSCOPOctets R[SDOC

replace he link

Plus G of 10)

HSL M

[GR-Me

Reg


N Oversized Message Discards on MTP2 Links - at STPs Supporting HSLs[OVSZDSCD]

MTP3 30/NDC/L30/NDC/STP5x/NTM/L5/NTM/STP

P_COMP/LINKP_SYSTOT/STPA_NM/LINKA_NM/STP

Applies only tolinks at STPs supporting bothlinks and HSLstranslation errocause large meto attempt routiMTP2 links.

n in the In- State INSV]

SAAL N None. Not required 30/NDC/L P_COMP/LINKC_COMP/LINK

Measured at SALayer Managem

g Link ent FailuresFLRS]

SAAL N None. Not required. 30/NDC/L5x/NTM/L

P_COMP/LINKA_NM/LINK

Measured at SALayer ManagemThe concept ofalignment is coto both link typno measuremenlink alignment attempts are reqfor MTP2 links

SD PDUs itted ng issions)

UTRN]

SAAL R MSUs Transmitted (including retransmissions)(MSUTRAN)

MTP2 30/NDC/L

30/NDC/LS

P_COMP/LINKC_COMP/LINKP_COMP/LNKSETC_COMP/LNKSET

SD PDUs replaMSUs at the lin

SD PDUs mittedURTR]

SAAL R MSUs Retransmitted(MSURETRN)

MTP2 30/NDC/L

30/NDC/LS



SD PDU ransmitted

ng issions)

UTRN]

SAAL R MSU Octets Transmitted (including retransmissions)(OCTTRAN orTOCTTRAN)

MTP2 30/NDC/L

30/NDC/LS


SD PDU octetsMSU octets at tlayer.

SD PDU etransmitted

TRTR]

SAAL R MSU Octets Retransmitted(OCTRETRN)

MTP2 30/NDC/L

30/NDC/LS


SD PDU octetsMSU octets at tlayer


easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–8

ab


SSCOPReceive[SDPD

ce k layer

SSCOPOctets R[SDOC

replace he link

Total STransmTypes)

nalogs s of

U) SU ch ired to r MTP2

Total SReceiveTypes)[

Total SOctets T(all PDU[PDUO

Total SOctets RPDU Ty[PDUO

SSCOPTransmRetrans[SDPD

r he d’s ent by

nt.

SSCOPDisconn[CDISC

Plus G of 10)

HSL M

[GR-Me

Reg


SD PDUs d

URCV]

SAAL R MSUs Received(MSURECVD)

MTP2 30/NDC/L

30/NDC/LS



SD PDU eceived

TRCV]

SAAL R MSU Octets Received(OCTRECVD)

MTP2 30/NDC/L

30/NDC/LS


SD PDU octetsMSU octets at tlayer

SCOP PDUs itted (all PDU [PDUSTRAN]

SAAL N None 30/NDC/L

30/NDC/LS


Rough MTP2 awould be countother (non-MStypes, but no sucounts are reqube measured folinks.

SCOP PDUs d (all PDU PDUSRCVD]


30/NDC/LS


Same as above

SCOP PDU ransmitted Types)

CTTR]


30/NDC/LS


Same as above

SCOP PDU eceived (all pes)

CTRC]


30/NDC/LS


Same as above

SD PDUs itted Requiring missionURRR]

SAAL R Number of Negative Acknowledgments Received(NEGACKS)

MTP2 d/M-PM/L

m/M-PM/L


For HSLs, errodetection is at ttransmitting enLayer Managemlack of acknowledgme

Connection ectsONX]

SAAL N None d/M-PM/L

m/M-PM/L



easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–9


GR-2878-CORE

SSCOPInitiatio[INITF

SSCOPReestabResync[CNRE

SSCOPSum-ofCounte[CNSU

nalog . Used SL

mance

Hourly PerformThreshofor SSCConnecErrors C[HTXC

UnexpePDUs R

[UNEX

Invalid Receive[INVLP

SSCOPReceiveElemen[PDUL

SSCOPErrors C[PDUS

nalog . Used SL

mance

Plus G of 10)

HSL M

[GR-Me

Reg


Connection n Failures

LRS]


m/M-PM/L


Connection lishments/hronizationsCONX]


m/M-PM/L


Connection -Errors rMERS]


m/M-PM/L


No direct measurement afor MTP2 linksas one of four Hmarginal perforcriteria.

Marginal ance lds Exceeded OP tion Sum-of-ounter

NERS]

SAAL N None d/M-PM/L P_MTCD/LINKD_MTCDTH/LINK

cted SSCOP eceived

PDUS]


m/M-PM/L


SSCOP PDUs dDUS]


m/M-PM/L


PDUs d with List-t ErrorsSTER]


m/M-PM/L


PDUs Sum of ounter

UMER]


m/M-PM/L


No direct measurement afor MTP2 linksas one of four Hmarginal perforcriteria.


easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–10

ab


Hourly PerformThreshofor SSCof-Erro[HTXP

Lack-of

[LACK

s the trol logous SSUs . re not e

l, s ed

redit”

0.

Cumulaof Lack[DRNO

Cumulaof Far-eOutage

this tilizes rion lease e is he far the e e

Plus G of 10)

HSL M

[GR-Me

Reg


Marginal ance lds Exceeded OP PDU Sum-rs CounterDUER]

SAAL N None d/M-PM/L D_MTCH/LINKD_MTCDTH/LINK

-Credit Events

CRED]

SAAL N Not required. 5x/NTM/L A_NM/LINK Lack of credit iSAAL flow conmechanism anato use of SIB Lfor MTP2 linksBecause SIBs aapplicable to thSAAL protocodetection of thicondition is basinstead on the transmitter’s “cwindow being decremented to

tive Duration of CreditCRED]

SAAL R Cumulative Duration of Busy Link Status Units (SIB LSSUs) Received

MTP2 5x/NTM/L A_NM/LINK

tive Duration nd Processor

[DRFEPRO]

SAAL C Same measurement name, but based on duration of receipt of SIPO LSSUs[DRFEPRO].

MTP2 5x/NTM/L A_NM/LINK For HSLs, SIPOLSSUs are not applicable. So measurement uinstead the critethat a remote rePDU indicatingprocessor outagreceived from tend, conveyingstart of a remotprocessor outagevent.


easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–11


GR-2878-CORE

Cumulaof LocaOutage

oncept cable to , local e is not

TP2

Incomin(OccupCells (Ucells) [I

cific not TP2

2

shall be MSU tted (or easure ancy.

OutgoinATM COAM c[OUTC

IncominCells [I

cific not TP2 any cells.

Outgoin[OGUIC

cific not TP2 any cells.

Plus G of 10)

HSL M

[GR-Me

Reg


tive Duration l Processor [DRLCLPRO]

MTP3SAAL

N Not required, objective only. Same measurement name, but based on duration of transmission of SIPO LSSUs, if it can be measured[DRLCLPRO]

MTP2 5x/NTM/L A_NM/LINK Although the cis equally appliboth link typesprocessor outagrequired to be measured for Mlinks.

g NDC-Valid ied) ATM I and OAM

NCCELLS]

ATM N None 30/NDC/L

30/NDC/LS


ATM-layer-spemeasurements,applicable to Mlinks.

No direct MTPanalog. These measurements used instead ofOctets TransmiReceived) to mtrue link occup

g NDC-Valid ells (UI and ells)ELLS]

ATM N None 30/NDC/L

30/NDC/LS


g ATM UI CUICELS]

ATM N None 30/NDC/L

30/NDC/LS


ATM-layer-spemeasurements,applicable to Mlinks. ExcludesOAM overhead

g ATM UI ELS]

ATM N None 30/NDC/L

30/NDC/LS


ATM-layer-spemeasurements,applicable to Mlinks. ExcludesOAM overhead


easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–12

ab


ATM CDue to ControlViolatio[HECD

cific not TP2 etect

Out of CDelineaAnoma

[OCDA

ATM CDue to PHeader[HDRD

Plus G of 10)

HSL M

[GR-Me

Reg


ells Discarded Header Error (HEC) ns)SCDS]

ATM N None. d/M-PM/L

m/M-PM/L


ATM-layer-spemeasurements,applicable to Mlinks. Used to dATM-layer performance problems.

ell tion (OCD) lies

NMLS]


m/M-PM/L


ells Discarded rotocol (ATM

) ErrorsSCDS]


m/M-PM/L



easurement Name


Layers

RECN

AnalogousMTP2-Link

Measurement Name


Register Label)

Layers

Basis:Interval/

Operations Domain/




(ENTTYPE)Grouping


to MTPMeasurem

D–13


GR-2878-CORE

D.2 HSL Link Marginal Performance Indicators

HSLs shall be placed on Marginal Performance Reports generated by the CCS nodes along with threshold-crossing alerts on the maintenance channel when these key indicator values cross user-specified hourly thresholds. Table D-2 summarizes the identities of the key marginal performance measurements for HSLs and compares them to their MTP2 link counterparts where applicable. CCS network operations personnel should establish values for the hourly thresholds based on network performance objectives and the anticipated quality of link facilities.

See also Appendix E regarding considerations for the establishment of default HSL marginal performance thresholds and their minimum configurable ranges.

Table D-2. HSL and MTP2 Link Marginal Performance Indicators

HSL Measurement Name Layers

RECN

Analogous MTP2-LinkMeasurement Name

Layers

Number of Automatic Changeovers

MTP3 C Number of Automatic Changeovers MTP3

SSCOP SD PDUs Transmitted Requiring Retransmission

SAAL R Negative Acknowledgments Received

MTP2

None --- MSUs Received in Error MTP2

SSCOP Connection Sum-of-Errors Counter

SAAL N None

SSCOP PDUs Sum of Errors Counter

SAAL N None

D–14

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Considerations Regarding HSL Marginal Performance Thresholds

Appendix E: Considerations Regarding HSL Marginal Performance Thresholds

The following considerations are offered regarding the establishment of default values and configurable ranges for the HSL hourly marginal performance thresholds as defined in Section 4.5.2.1 (HSL Marginal Performance Reports). The hourly performance measurements used as marginal performance indicators for HSLs include

• Number of automatic changeovers

• SSCOP SD PDUs transmitted requiring retransmission

• SSCOP connection sum-of-errors counter, and

• SSCOP errored PDUs sum-of-errors counter.

Recommendations are summarized in bold italicized type.

E.1 Number of Automatic Changeovers

Per R4-89 [141], this measurement accumulates, on an hourly interval, the number of times the MTP3 automatic changeover procedure was invoked to remove traffic from the HSL and redistribute that traffic to any alternate links remaining in service, when the link in question is removed from service by the link layer (for HSLs, the SAAL) at either the near end (the CCS node recording the measurement) or the far-end CCS node. It essentially counts the number of in-service link failures at either end, e.g., removals from service by the SAAL In-Service Error monitor or due to other link failure conditions. (This same marginal performance measurement also applies to 56-Kb/s MTP2-based signaling links using DS0 facilities. However, no default threshold value or configurable range has yet been defined for this measurement, for those links, in Telcordia generic requirements.)

For DS1 facilities with an acceptably low average Bit Error Rate (BER) and any random error bursts limited in duration (i.e., the SAAL LM In-Service Error Rate Monitor [ISERM] is designed to “ride over” [tolerate] error bursts of less that 400 ms in duration without HSLs being removed from service), the number of such automatic changeover events in a one-hour period should be reasonably small, say not more than 3 to 5 such events. However, the likelihood of changeovers may be expected to vary according to the type of facility, with higher rates possible on radio or satellite systems where error rates are higher, if such systems are used to support HSLs. Assuming that optical fiber facilities, which typically have higher-reliability and lower BERs, will be the norm for the deployment of most HSLs, any counts reaching or exceeding the lower end of this range, say 3 such events in any one hour would generally constitute marginal performance. Although somewhat arbitrary, this should be regarded as a reasonable value for this threshold under the given assumptions. Given that the default normal proving period for a HSL is 60 seconds, it will not be possible, even under the worst error conditions, for the HSL to fail and recover more than 60 times per hour. Certainly, performance that poor, under which the link availability

E–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Considerations Regarding HSL Marginal Performance Thresholds December 1999

GR-2878-CORE

for the hour would approach 0 percent because of all the time spent proving-in between successive failures, would be considered much worse than marginal. A value of 30, half that number of changeovers, still implying link availability of 50 percent or less, would probably be at the extreme upper limit of any reasonable marginal performance threshold. Assuming the CCS node implementation can support at least a 5-bit register for this performance measurement, allowing a maximum value of 32, a generous, flexible minimum configurable hourly threshold range of 1 to 32 automatic changeovers is probably more than sufficient.

Hence, the recommended default value for this hourly marginal performance threshold is 3, with a minimum configurable range of 1 to 32.

To allow this threshold to be set differently for different link facility types, the CCS node should allow its value to be administered on a per-link-parameter-set (LPS) basis, with the link parameter set identifier assignable to individual HSLs. Requirement R4-102 [153] currently requires that this threshold (like the other marginal performance thresholds) be configurable at least for all HSLs on a per -node basis. To accommodate the administration of this threshold for different facility types on a per-LPS basis, Objective O4-18 [210] has been specified in this GR, for this and the remaining marginal performance criteria.

E.2 SSCOP SD PDUs Transmitted Requiring Retransmission

This measurement accumulates, on an hourly interval, the number of SSCOP SD PDUs transmitted on the HSL that required retransmission because they were not acknowledged by the peer SSCOP process at the far-end. These counts are collected per R4-96 [147]. Each such retransmission will occur when bit errors corrupt one or more ATM cells comprising the AAL5/CP PDU, such that the PDU cannot be reassembled or it fails the AAL5/CP’s CRC check at the far-end. Each retransmitted SSCOP SD PDU is thus a reflection of such bit errors.

Such bit errors can occur randomly on transmission facilities, although such systems are engineered to an average bit error rate (BER) that provides an acceptable grade of service to the applications using the circuit supported by the facility. In addition, transport facility systems are typically prone to transient error bursts, during which many transmitted bits are corrupted at a rate much higher than the expected average background error rate.

The marginal performance threshold should be set such that it can detect either a sustained average Bit Error Rate (BER) significantly higher than the average BER expected on the DS1 facility, or an “excess” number of transient error burst events, beyond what would normally be expected on the DS1 facility supporting the HSL. The actual number of retransmitted PDUs will depend not only on the average BER or expected error-burst frequency, but also the traffic load on the link and the average PDU size. The threshold settings should probably vary on different links, because the number of retransmissions will vary with load and message length even if link quality is constant. The greater the number of bits comprising a PDU, the greater the probability the PDU will be corrupted at a given

E–2

ab


BER. For a constant BER, the more SD PDUs generated the greater the expected number of PDUs that will be corrupted and retransmitted. For an error burst of a given duration, where all bits are assumed corrupted, the number of errored PDUs will be proportional to the number of PDUs generated and inversely proportional to the PDU size.

Generally, the more liberal (higher) threshold value derived from the consideration of these two cases (average BER versus error burst tolerance) should be used to determine the default marginal performance threshold for a “typical” HSL, in order to minimize the chance of a false indication of marginal performance.

A “typical HSL” will be one with a typical traffic occupancy, carrying messages of a typical average SD PDU length, and operating on a DS1 facility performing such that its actual error rate is marginally below the expected maximum average BER or expected burst-error rate. Such error rates would generally not be sufficient to remove a HSL from service, but could indicate sufficient performance degradation such that preventive maintenance on the facility is indicated. Each of the two possible marginal performance criteria are considered in turn as follows.

E.2.1 Average Sustained BER Criteria

In order to estimate the number of expected SD PDU retransmissions under the sustained BER criteria, the following assumptions are made:

1. DS1 facilities are typically engineered to BERs not exceeding 1 in 108 on metallic media, and significantly better on optical fiber facilities. For the purposes of this analysis, one can assume this value as the worst-case engineered BER. Further, assume the link may be declared marginally performing if the number of retransmitted PDUs suggests an underlying average BER greater than 1 in (5 x 107), i.e., say about a factor of only 2 better than needed to ensure days between link takedowns by the error monitor.

2. Further assume a “typical” engineered link occupancy that does not exceed 0.20 erlangs per link. This is half the commonly used maximum occupancy objective of 0.40 erlangs/link in normal mode operation (corresponding to 80 percent in failure mode operation). This will allow for a lower load than the engineered objective maximum as is likely to be the case at initial HSL deployment and will also allow for STP implementations for which HSL link sets are engineered to a “derated” link capacity due to processor capacity restrictions at MTP layer 3 and above.

3. For the purposes of establishing a default threshold, an average AAL-CP5 PDU length of 3 ATM UI cells will be assumed. This would be consistent with an average MTP3 message size of approximately 120 to 130 MTP3 octets, which is anticipated for HSLs dominated by TCAP message traffic. This will likely be the case under the planned initial deployment of HSLs mainly on certain STP-SCP A-link sets, where the SCP traffic will consist mainly of service-related data base queries. In the Local Number

E–3


GR-2878-CORE

Portability (LNP) environment, such links may also be carrying vertical-service-related TCAP queries to be processed by the LNP Message Relay (a.k.a., 10-digit GTT) capability at the SCP. HSLs in D-link set quads used to access these SCPs for these functions via their adjacent STPs, as well as for ordinary SCP data base queries, are expected to carry the same types of TCAP messages. Therefore, it is reasonable to assume SPDU = 3 as an average PDU size.

At the nominal DS1 data rate of 3622 cells/second and at the assumed average BER of 5 x 10-7, the expected number of retransmitted SD PDUs per hour can then be approximated under worst-case assumptions about the distribution of bit errors over time.

The worst-case with respect to the number of errored PDUs can be modeled under the assumption that bit errors are uniformly distributed in time, and that each bit of each PDU could be corrupted independently of each other bit. This is done rather than assuming errors are bunched together in bursts, which would tend to affect a smaller number of PDUs per unit time on average. While this may not be realistic for most DS1 facilities, where errors tend to be “bursty” (or “bunched”), it will be useful for the approximation of an upper bound for the number of errored PDUs under the assumed marginal BER. By definition, the probability of corrupting any one bit is then equal to the assumed average BER (1 in 5 x 107).

Because of the independence assumption, the outcome of an errored or non-errored PDU may be modeled as the set of independent outcomes that each bit in the PDU is either corrupted or not corrupted. That is, the probability of receiving a correct PDU (Pcorrpdu) of length k bits is therefore the product of the probabilities that that each bit comprising the PDU is correct, i.e.,

Pcorrpdu = P{bit 1 is correct} x P{bit 2 is correct} x ... x P{bit k is correct}.

Again, by definition

P{any one bit is corrupted} = BER

and

P{any one bit is correct (not corrupted)} = 1- BER.

Therefore,

Pcorrpdu = (1- BER)k

Pcorrpdu is thus a polynomial of order k.

From the Binomial Theorem, a polynomial expansion of the general form (a + b)n can be expressed as

(a + b)n = Σm=0,n (n!/m! (n-m)!) an-m bm.

When specifically applied to Pcorrpdu, i.e., substituting a = 1 and b = -1(BER), one obtains

Pcorrpdu = (1 - BER)k = Σm=0,k (k!/m! (k-m)!) (-1)k-m (-1)BERm.

E–4

ab


The polynomial may thus be expanded to

Pcorrpdu = 1 - k(BER) + (higher-order terms in BER2, BER3, ... , BERk).

However, when the BER is very small, as it is under the assumed error rate of (5 x 10-7), the contributions of the second-order and higher-order terms are sufficiently small, so that those terms may be ignored, and one can thereby approximate the probability of receiving a correct PDU of length k as

Pcorrpdu ≈ 1 - k(BER).

Therefore, the probability of receiving an errored PDU as a function of the BER and PDU length in bits (k) is approximated as

Perrpdu = 1 - Pcorrpdu

≈ 1 - [1 - k(BER)]

≈ k (BER).

This agrees with the common intuitive assumption that the probability of rejecting a PDU is generally proportional to the PDU size and the error rate.

The assumed typical PDU size of 3 cells in bits (k) = 3 cells/ PDU x 53 octets/cell x 8 bits/octet = 1272 bits . Therefore, the probability of a corrupted SSCOP SD PDU (Perrpdu) at the assumed average(marginal) BER

≈ 5 x 10-7 (= 0.0000005) x 1272

≈ 0.000636.

Over a one hour interval, the number of transmitted PDUs (PDUtran ) at the assumed 20% link occupancy (R = 0.20 erlangs) is given by:

PDUtran = 0.20 x 3622 cells/secondx 3600 seconds/hour/ 3 cells per PDU

= 869280 SD PDUs.

Therefore the expected number of corrupted SD PDUs (which would require retransmission) over the one hour measurement interval is given by:

PDUretran = Perrpdu PDUtran

= 0.000636 (869280)

= 552.862

≈ 550.

Again this assumes that the time between successive bit errors at the sustained average BER is uniformly distributed over the measurement interval and that error events are independent. While this assumption may be simplistic relative to the actual distribution of

E–5


GR-2878-CORE

such errors (e.g., exponentially distributed in time, more likely resulting in error bursts), it yields a more liberal upper bound estimate regarding the number of errored PDUs, than if the errors occur “bunched” together in time, such that a smaller number of corrupted PDUs would be detected by the CRC checks.

Generalizing the above calculation as a function of link occupancy (R) and PDU size in ATM cells (SPDU), with the average BER assumed constant at 5 x 10-7 (= 0.0000005), one obtains:

Perrpdu = 8 (53) BER SPDU= 8 (53) (0.0000005) SPDU= 0.000212 SPDU

PDUtran = 3622 (3600) R /SPDU = 13039200 R /SPDU.

PDUretran = Perrpdu PDUtran = 2764.3401 R.

Because SPDU terms cancel, the number of SD PDU retransmissions at a constant BER becomes a function of the link occupancy R only.

Repeating the same calculation for HSLs engineered to 40 percent occupancy (0.40 erlangs/link) one obtains 1106 retransmissions per hour, and at 80 percent occupancy, 2211 retransmissions per hour.

E.2.2 Error-Burst Frequency Criteria

The HSL In-Service Error Monitor and its configured parameters are designed such that the HSL shall not be failed during error-bursts lasting as long as 400 ms. For the purposes of defining recommended default marginal performance criteria, it is recommended that as many as 4 such 400-ms error bursts will be permitted per hour before the link performance is declared “marginal.” That is, 4 error bursts in an hour, each of which is almost long enough to trigger changeover, would certainly mean link quality has deteriorated to the point that network operations personnel would want to be notified. Assuming each error burst lasts a full 400 ms (0.4 seconds) and results in the corruption of all ATM UI cells during that period, the number of corrupted and retransmitted SD PDUs per error burst can be calculated as follows:

Define Cb = Corrupted ATM UI cells per 400-ms burst.

Cb = 0.4 seconds x 3622 (cells/second ) x R

= 1448.8 R

where R = link occupancy (erlangs/link).

Define PDUretran,b = the number of PDUs retransmitted during a single error-burst of 400 ms in duration. Then,

E–6

ab


PDUretran,b = Cb/SPDU

= 1448.8 R/SPDU,

again where SPDU = the average PDU length in cells.

For the purposes of establishing a default threshold, again assume an average AAL-CP5 PDU length of 3 ATM UI cells. Therefore, set SPDU = 3.

To allow 4 such error bursts per hour, define PDUretran,h = 4 PDUretran,b. Then at the assumed “typical” HSL occupancy of 20%:

at R = 0.20, SPDU = 3; PDUretran,b = 97; and PDUretran,h = 388.

One can see that the threshold value for the four 400-ms bursts/hour criteria are very sensitive to average PDU size (SPDU) and link occupancy (R). Yet these parameters are likely to vary for different HSLs based on their offered traffic, link traffic engineering objectives (their engineered occupancy) and the traffic mix, the latter of which will determine the actual distribution of PDU sizes. For example:

• with SPDU = 3 at other potential HSL occupancies (e.g., 1/4 the typical maximum engineered link occupancy, at the typical maximum engineered link occupancy, and twice the typical maximum engineered link occupancy assuming, i.e., in failure mode), one obtains from the above equations:

at R = 0.10, PDUretran,b = 49, PDUretran,h = 194


at R = 0.80, PDUretran,b = 387, PDUretran,h = 1546.

Considering the same HSL occupancies at other average PDU lengths:

• with SPDU = 1:





• with SPDU = 2:





• with SPDU = 4:

E–7


GR-2878-CORE





E.2.3 Recommendations Regarding the PDUs-Retransmitted Thresholds

Under the indicated assumptions for “typically loaded” HSLs (20 percent occupancy and a PDU size of 3 ATM UI cells), the average-BER criteria yield the more liberal (higher) threshold value (550) relative to that of the error-burst criteria (388) . Hence, the threshold value reflecting the average-BER criteria (550) is recommended as a default, as it is the more conservative (higher) of the two threshold estimates.

However, due to the sensitivity of these estimates to PDU size and link occupancy, it is recommended that the configurable range of this parameter for HSLs be quite large, say between 10 and 10000 to allow for such differences and for even more liberal error burst criteria beyond the stated 4 per hour. An alternative approach might involve a ratio threshold based on the proportion of SD PDUs requiring retransmission (given the sensitivity to link occupancy R) rather than the absolute number of errored PDUs. However, such thresholds tend to be more difficult for suppliers to implement and for operations personnel to correctly administer. Hence, the absolute-number threshold will be retained.

It is also again recommended that the thresholds for PDUs requiring retransmission be configurable on at least a per-link-parameter-set basis, to support groups of HSLs with the same typical engineered occupancies and average PDU sizes, as well as different facility types with different average BERs and expected error-burst rates. R4-102 [153] currently requires that this threshold (like the other marginal performance thresholds) be configurable on at least a per-node basis for all HSLs. Objective O4-18 [210] addresses the administration of this parameter per LPS. Beyond this, it is further recommended that this threshold be configurable on a per-link-set basis so that that its value may be further “fine tuned” for link sets loaded to different average occupancies or having different traffic mixes (average PDU lengths). Objective O4-104 [213] has been specified for this purpose.

In summary, the recommended default hourly marginal performance threshold for SSCOP SD PDUs Transmitted Requiring Retransmission is 550, with a recommended minimum settable range between 10 and 10000, assignable on a per-link-set, per-LPS, and per-node basis.

E–8

ab


E.3 SSCOP Connection Sum-of-Errors Counter

Per R4-94 [145], this measurement accumulates, on an hourly interval, the sum of the number of SSCOP connection-related events of the following types at the receiving side of the HSL:

1. SSCOP Connection Disconnects

Failures of the SSCOP connection due to expiry of Timer_NO_RESPONSE.

2. SSCOP Connection Initiation Failures

The inability to establish an SSCOP connection, occurring when the number of expiries of the connection control timer Timer_CC exceeds MaxCC or upon receipt of a connection reject (REJ) PDU.

3. SSCOP Connection Re-establishments/Resynchronizations

Receipt of an SSCOP BGN PDU from the far end.

These counts include events that could occur because of errors on the transmission channel or the far-end SSCOP processor that cause the SSCOP connection or proving attempts to fail, resulting in attempts to reestablish the connection. In addition, item 2 is indicative of a failure or outage condition at the far-end SSCOP process under which it refuses or is unable to respond to normal connection initiation attempts still being made by the near-end. As was the case for automatic changeovers, a reasonable hourly default value for most HSLs would probably be in the 3 to 5 range (with perhaps larger values for radio facilities if applicable), perhaps with a configuration range of 1 to 32. Given that some underlying condition at the far-end SSCOP may result in multiple peg counts being scored for this register, a value at the upper end of this range, say 5 is suggested to define exceptional behavior for any given one-hour period.

Again assuming the CCS node implementation can support at least a 5-bit register for this performance measurement, a minimum settable hourly threshold range of 1 to 32 events is considered reasonable.

Hence, the recommended default value for this hourly marginal performance threshold is 5, with a minimum settable range of 1 to 32. If the size of the measurement register is larger, then the CCS node should be capable of setting an even larger allowable range for this threshold up to the maximum value supported by the allocated register length, rather than limiting the maximum value to the somewhat arbitrary upper limit of 32.

E.4 SSCOP Errored PDUs Sum-of-Errors Counter

Per R4-95 [146], this measurement accumulates, on an hourly interval, the sum of the number of PDU errors of the following types detected at the receiving side of the HSL:

E–9


GR-2878-CORE

1. Unexpected SSCOP PDUs

The receipt of unsolicited or inappropriate PDUs as conveyed by MAA-ERROR indications with error codes A through M.

2. Invalid SSCOP PDUs

The receipt of PDUs of incorrect length, with undefined PDU-type codes, or PDUs not 32-bit aligned.

3. SSCOP PDUs with Other/List Element Errors

This includes the receipt of SD PDUs with invalid N(S) or N(R) sequence number parameter errors or STAT/USTAT PDUs with list-element errors.

Provided the CCS node’s SAAL implementation is correct and timers are set reasonably, these events should happen only very rarely if at all. These might conceivably occur if: (i) memory gets corrupted in the link terminals, (ii) in the highly unlikely event that transmission errors slip past the CRCs, or (iii) when a message for one signaling link gets delivered to the terminal for another link. The latter might occur because of cell header corruption in an ATM cell multiplexing environment (as may be implemented in the future) but is also possible even with a dedicated DS1 transmission link per HSL, if a higher-level signal (on the transmission link) carrying more than one signaling link goes out of frame. If more than 1 or 2 of these events occurs on one link during any single hour, it would generally be regarded as quite exceptional.

Therefore, a default threshold of 2 with a configurable range at least as wide as that used above for the Connection Sum-of-Errors counter (1 to 32) is recommended. Again, if the size of the available measurement register is larger than five bits, then the CCS node should be capable of setting an even larger allowable range for this threshold up to the maximum value supported by the allocated register length, rather than limiting the maximum value to the somewhat arbitrary upper limit of 32.

* * *

The above recommendations regarding the basis on which these thresholds should be configured are incorporated into the body of this GR as Objective O4-18 [210] in Section 4.2.6 and Objectives O4-103 [212] and O4-104 [213] in Section 4.5.2.1.1 (Link Marginal Performance Report Criteria). The suggested default threshold values and configurable ranges are also reflected in the configuration management summary presented in Table 4-1 in Section 4.2.8 (Summary of HSL Configurable Parameters).

E–10

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 The Effectiveness of Congestion Controls

Appendix F: The Effectiveness of Congestion Controls

Appendix A describes the SAAL flow-control mechanism and various credit assignment schemes. That appendix also suggests that suitable flow-control (i.e., careful credit assignment) can protect an under-engineered (i.e., limited capacity) MTP level 3 processor from being overloaded. Although not commonly implemented, Signaling Message Handling (SMH) congestion control is another mechanism capable of doing that. Specifically, SMH congestion control is an MTP level 3 procedure that uses Transfer Controlled (TFC) messages to restrict incoming traffic. It functions like link congestion control but differs in the following ways:

1. Onset and discard thresholds occur at the same point for each congestion priority level (i.e., whenever the onset threshold for priority level i is crossed, all messages of priority less than i are discarded);

2. A TFC is only sent every Ngap dropped messages (where Ngap is a parameter). Furthermore, the counting of a dropped message does not depend on its source or destination.

This appendix summarizes the findings of an internal Telcordia simulation study addressing the effectiveness of SAAL flow-control and the SMH congestion control procedures in protecting an STP’s level 3 processor from being overloaded. In particular, Section F.1 defines the model network used in the Telcordia study, and Section F.2 describes two overload scenarios used to test these congestion control mechanisms and analyze their apparent effectiveness.

F–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4The Effectiveness of Congestion Controls December 1999

GR-2878-CORE

F.1 Network Model

The studied network model, shown in Figure F-1, consisted of one SCP and three LATAs, each containing an STP and 16 SSPs.

Figure F-1. Network Model Used in Telcordia Congestion Control Study

Specific aspects of this model follow:

• Call Rate, Traffic Mix, and Customer Behavior

Table F-1 contains the call processing capacities of the SSPs depicted in Figure F-1.

The assumed traffic mix was 70 percent POTS call set-up (ISUP), 15 percent toll-free, 5 percent LIDB, and 10 percent AIN. The number of SCP queries associated with an AIN call was geometrically distributed with a mean of 1.33.

Customer behavior was modelled according to GR-505-CORE[50], Call Processing. Post-dial abandonment delay, however, was set to a somewhat large value to avoid too many abandonments for calls routed through multiple tandems.

Table F-1. Call Processing Capacities of the SSPs in Figure F-1

SSP Size Number per LATA

Calls per hour (Thousands)

A-link load (Erlangs)

Small 2 330 .373

Medium 10 483 .546

Large 4 570 .645

56-Kbps links 1.536-Mbps links

16

1

2

LATA1

STP1

16

1

2

LATA2

STP2

161 2

LATA3

STP3

F–2

ab


• Links

The B-links between the STPs and the A-links to the end nodes were 1.536-Mbps SAAL HSLs and 56-Kbps links, respectively. Each A-link set was engineered (based on Table F-1) so that its A-links had a load of about 0.4 Erlangs. These A-link loads produced an offered load on the HSLs of about 0.35 Erlangs.

The HSLs used the link congestion control thresholds shown in Table F-2 and a fixed-credit flow-control scheme with the following parameter values:

— A polling interval of 0.1 seconds

— A credit allocation block size of 3 polling intervals

— A jitter in successive STAT arrivals of 0.05 seconds

— An end-to-end transit delay for POLLs and STATs of 0.035 seconds.

• Trunks, Subscriber Lines, and Call Routing

The trunk network was engineered so that the number of trunks equaled the average number of calls in progress when the call processors were operating at a utilization of 1.0. This ensured that trunk congestion (and the resulting generation of ACCs) occurred only in overload scenarios.

The number of subscriber lines at each switch equaled the average number of busy lines when the call processor was running at a utilization of 0.4. This aspect is important because the fraction of subscriber lines that are busy will increase with the load. Additionally, every subscriber line was equally likely to be requested by an incoming call.

All calls were interLATA. Some were routed directly, but others went through one or more tandems.

• Network Element Utilization

All network elements, including all level 3 processors, were engineered to operate at a comfortably low utilization level under normal circumstances. Given failure-mode loads, however, some of the those processors were under-engineered. Section F.2 provides additional details.

The SMH congestion control thresholds used are shown in Table F-2. In that table, Ai and Oi are the abatement and onset thresholds for priority level i.

F–3


GR-2878-CORE

In order to achieve acceptable delays during periods of congestion, each SMH abatement threshold was set to the corresponding HSL congestion abatement threshold, and each SMH onset threshold was roughly half way between the corresponding HSL onset and discard thresholds. Setting SMH onset thresholds lower would restrict throughput unnecessarily, while higher thresholds would cause intolerable delays. Note that these SMH thresholds may require rather large buffers, particularly when a single level 3 processor handles a group of links. Selecting better SMH congestion thresholds, however, is difficult because they depend heavily on the architectural details of level 3 processing.

Additionally, Ngap was set to 8, the recommended default value.

F.2 Overload Scenarios

To test the adequacy of SAAL-flow control and SMH congestion control in protecting an STP’s level 3 processor, the Telcordia study considered a focused overload at STP1 caused by an excessive number of calls directed towards LATA1 SSPs from LATA2 and LATA3 SSPs. Without HSLs between the STPs, such a focused overload would cause link congestion in STP2 and STP3 and would be handled by existing link congestion control mechanisms (i.e., STP1 would not become congested because the 56-Kbps link sets would be bottlenecks). With HSLs, however, no transmit congestion occurs due to the added link capacity, and STP1’s level 3 processor is at risk.

As summarized in Sections F.2.1 and F.2.2, the following scenarios were considered:

1. The level 3 processors in STP2 and STP3 were given capacity sufficient to handle fully loaded HSLs, but STP1 was under-engineered.

2. The level 3 processors in all three STPs were under-engineered.

F.2.1 Level 3 Capacity Limitations in STP1 only

When SMH congestion control is not implemented, SAAL flow-control can protect STP1’s level 3 processor; however, optimal network performance can only be achieved by precise

Table F-2. SMH Congestion Thresholds in Secondsa.

a. To convert these thresholds into messages (or octets), the average time that level 3 spends on each message is needed. That time can be derived from engineering parameters or direct measurements.

A1 O1 A2 O2 A3 O3 Total Buffer Size

.26 .62 .99 1.28 1.58 1.73 1.88

F–4

ab


credit assignment. Even slightly too much credit or a change in network parameters can lead to an overloading of STP1’s level 3 processor and cause very poor call setup and release delays.

Unfortunately, credit assignment depends on many uncertain quantities (e.g., the amount by which the transmitter runs ahead of the receiver, link length, and queuing delays suffered by STATs and POLLs). This difficulty suggests that credit assignment must be conservative (i.e., low) when only SAAL flow-control is used. Such an approach yields suboptimal network performance most of the time.

In fact, a credit assignment scheme that is too conservative may actually cause STP1’s level 3 processor to be overloaded. Specifically, very tight flow-control causes a large number of calls to fail when STP1’s level 3 processor is severely under-engineered. The subsequent reattempt traffic then places an even greater load on that processor.

On the other hand, too much or too little credit does not lead to an overloaded level 3 processor when SMH congestion control is used in STP1 (and STP2 and STP3). In fact, SMH congestion control can provide good network performance (i.e., call throughput and low setup delays) even without SAAL flow-control; however, that throughput is significantly lower than when near-optimal flow-control is also used. Note that these conclusions are also insensitive to message sizes (e.g., an IAM’s size) when the congestion thresholds in Table F-2 are specified in messages rather than seconds.

Given the above observations, a combination of near-optimal flow-control and SMH congestion control appears to be the best way to protect STP1’s level 3 processor.

F.2.2 Level 3 Capacity Limitations in all STPs

When SMH congestion control is not implemented, SAAL flow-control cannot protect STP1’s level 3 processor without severely restricting the throughput of calls from LATA1 during the overload period. Specifically, the number of successful calls from that LATA was much less than those from LATAs 2 and 3. In fact, LATA1’s SSPs were sometimes completely unable to originate calls. This “target silencing” phenomenon occurred when STP1’s links to STP2 and STP3 entered level 1 congestion. At that point, the focused overload caused LATA1 SSPs to generate so many ACM/ANM messages (which have nonzero priority) that IAMs from those SSPs (which have priority zero) could not get through. Hence, LATA1’s SSPs could receive but not originate calls.

On the other hand, SMH congestion control provided good call throughput and low setup delays with and without SAAL flow-control. Furthermore, those quantities were about the same for calls originating in all LATAs. Throughput, however, was higher when loose flow-control was also used. Note that these conclusions are also insensitive to message sizes (e.g., an IAM’s size) when the congestion thresholds in Table F-2 are specified in messages rather than seconds.

F–5


GR-2878-CORE

Given the above observations, SMH congestion control appears to be the best way to protect STP1’s level 3 processor and avoid the “target silencing” phenomenon. Adding SAAL flow-control increases call throughput.

F.3 Summary

This appendix summarized a Telcordia study that analyzed the effectiveness of SAAL flow-control and SMH congestion control in protecting an STP’s level 3 processor from being overloaded. It suggests that flow-control alone may be able to protect the processor but may not provide acceptable call performance (especially in overload situations). On the other hand, SMH congestion control alone may be able to do both. Moreover, call performance is even better when SMH congestion control and flow-control are used simultaneously.

F–6

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Notes on Protocol Standards Discrepancies

Appendix G: Notes on Protocol Standards Discrepancies

G.1 General

Several SAAL protocol standards documents are directly referenced by the functional requirements specified in Section 3 of this GR. These ANSI specifications include those defining the SSCOP in T1.637,[6] the SSCF in T1.645,[7] and the Layer Management (LM) in T1.652.[8] These protocol standards are thus effectively incorporated into this GR by reference. In the course of implementation and testing of HSLs, industry participants have noted minor internal discrepancies or inconsistencies in some of the protocol specifications. Until these are rectified by T1S1, suppliers should take note of them, and plan their implementations accordingly. Similar discrepancies have been noted in the corresponding ITU-T versions of the SAAL standards. The purpose of this appendix is to document such discrepancies and the Telcordia view of the correct interpretation of the protocol specifications needed for their resolution. These notes are intended as “placeholders” until the discrepancies can be rectified in future issues of the standards documentation. In future issues of this GR, additional discrepancy items may be added if they are discovered, and current discrepancy items may be updated and eventually removed as they are resolved in the standards documentation.

G.2 SSCF (T1.645) SDL Diagram vs. State Table Discrepancy

In the SSCF specification of ANSI T1.645[7] (1995), Figure D.2 (SSCF_NNI SDL Diagram) outlines the SSCF state transitions for a SAAL signaling link in terms of its (a) Upper Boundary State (i.e., for HSLs, with MTP3), (b) the SSCOP State, and (c) the Layer Management State, all as perceived by the SSCF-NNI based on the signals and primitives it exchanges with those other layers or functions. The composite SSCF state is expressed as a three-part numeric vector (a/b/c), with specific states assigned to each number.

Specifically, Figure D.2, Part 18 of 20, defines the applicable SSCF state transitions when the SSCF was previously in state 3/10/5 (In Service/Data Transfer Ready/In Service). The third diagrammed transition covers the event where the local SSCOP receives a Remote Release PDU on the HSL, as generated by the far-end SSCOP. This is conveyed by the local SSCOP to the local SSCF as an AA-RELEASE.indication signal. The diagram conveys that the SSCOP connection should then be placed in state “Outgoing Disconnection Pending,” such that the new state vector is 1/4/1 (Out-of Service/Outgoing Disconnection Pending/Out of Service). In this state the local SSCOP is awaiting the receipt of a Release Confirmation PDU from the far end. However, the latter event shall not occur because the far-end SSCOP initiated the remote release action and is not expected to send the Release Confirmation. The correct resulting SSCOP connection status should instead be “idle.” That is, the correct new SSCF state resulting from this event should be 1/1/1 (Out of Service/Idle/Out of Service).

G–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Notes on Protocol Standards Discrepancies December 1999

GR-2878-CORE

The corresponding state transition table in T1.645,[7] Table 6, on Page 26, describes the state transitions upon processing of AA-RELEASE.indication signals. For initial state 3/10/5 in column (3), the table correctly specifies the resulting “idle” state for the SSCOP connection after the local SSCF’s receipt of the AA-RELEASE.indication (refer to the rows marked AA-RELEASE.indication). The state table is correct, while the SDL figure is in error. Figure D.2 in T1.645[7] should therefore be modified to reflect the correct state transition to “idle,” (1/1/1) instead of 1/4/1, thereby making it consistent with the state transition table.

This discrepancy is not regarded as serious, as the table is likely to generally be regarded as correct, rather than the SDL diagram. However, if an implementation forces the SSCF’s perception of the SSCOP connection to transition into the “outgoing disconnection pending” state per the SDL diagram, the SSCOP connection may get “stuck” there (i.e., since no release confirmation will be forthcoming from the far end), at least until the local MTP3 restarts the link. The discrepancy should be corrected by a contribution to Working Group T1S1.5, the applicable ANSI T1 standards body responsible for the T1.645 specification,[7] if its members have not already been informed of it.

A similar discrepancy exists for the corresponding figure within the ITU-T version of the SSCF standard. Specifically, in the ITU-T Q.2140[10] specification, the SDL diagram in Figure III.2/Q.2140, Part 18 of 20 also contains the erroneous value (outgoing disconnection pending). This particular state transition is also improperly labeled in Table 6 of that document. (See also Section G.3 below). The error in the SDL diagram is not surprising, since T1.645[7] had been based on Q.2140,[10] and the original error in Q.2140[10] has likely been carried forward. Even though these ITU-T standards are not directly referenced by requirements in this GR and are not likely to be implemented in LEC network elements in North America, this discrepancy should be corrected by ITU-T Study Group 11 (SG11) in future issues of Q.2140.[10]

Status Update (12/99): This discrepancy has been noted in a contribution brought by members of ITU-T SG11, as documented in ITU-T Temporary Document PL/11-91, Addition to Implementors’ Guide for Q.2140.[52] The correction was approved at the SG11 meeting in Geneva in March 1999 and, along with others noted for Q.2140,[10] have been incorporated into a larger “Implementors’ Guide” for the last published standard. The updated guide, essentially comprising an addendum and errata for the standard, has been reissued as ITU-T COM 11-R 8, Implementors’ Guide for Q.2140.[53] That larger document is a cumulative interim placeholder for such corrections until they are incorporated into the body of the standard. The next issue of the complete Q.2140[10] standard is scheduled to be published in mid 2000. ANSI T1S1, which again bases its T1.645[7] specification on the Q.2140[10] standard, is expected to wait until the latter document is reissued sometime next year before T1.645[7] is updated to correct this and possibly other discrepancies.

G–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Notes on Protocol Standards Discrepancies

G.3 Table 6/Q.2140 Initial-State-Column Labeling Errors

In addition to the above specific SDL-versus-state-table discrepancy cited in Section G.2, Q.2140,[10] Table 6 has several other erroneous entries. Initial state columns on Pages 24 through 28 of that table are mislabeled. The table’s column headings repeat the initial states cited on pages 20 through 23, rather than presenting the correct initial states to which the cited transitions described in the rows apply. The 4 incorrectly labeled columns (initial states) on those pages are as follows:

• 1/1/1 (Out of Service/Idle)

• 1/4/1 (Out of Service/Outgoing Disconnection Pending)

• 2/1/2 (Alignment/Idle)

• 2/2/2 (Alignment/Outgoing Connection Pending).

Specifically, the correct initial states, which should appear in those columns of Table 6 on Pages 24 through 28, are instead:

• 2/4/2 (Alignment/Outgoing Disconnection Pending)

• 3/10/5 (In-Service/Data Transfer Ready)

• 2/10/3 (Proving/Data Transfer Ready)

• 2/10/4 (Aligned Ready/Data Transfer Ready).

In addition, the last row of the table on Page 23 should be moved to the top of Page 24, under its corrected column headings.

Again, even though these ITU-T standards are not directly referenced by requirements in this GR, this discrepancy should be corrected by ITU-T SG11, the applicable ITU-T standards body responsible for the Q.2140[10] standard.

Status Update (12/99): This particular discrepancy has also been noted by ITU-T SG11 and has already been addressed in the Q.2140 Implementors’ Guide. The correction is included in the guide version republished as ITU-T COM 11-R 8.[53] So the correction is also expected to be incorporated into the revised complete Q.2140[10] standard sometime in mid 2000.

G–3

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Notes on Protocol Standards Discrepancies December 1999

GR-2878-CORE

G–4

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 References

References References

1. GR-246-CORE, Telcordia Technologies Specification of Signaling System Number 7 (SS7), Issue 4 (Telcordia, to be issued).

2. TR-NWT-001112, Broadband ISDN User to Network Interface and Network Node Interface Physical Layer Generic Criteria, Issue 1 (Telcordia, June 1993).

3. GR-1113-CORE, Asynchronous Transfer Mode (ATM) Adaptation Layer (AAL) Protocols, Issue 1 (Telcordia, July 1994).

4. GR-499-CORE, Transport Systems Generic Requirements (TSGR): Common Requirements (a module of TSGR, FR-440), Issue 2 (Telcordia, December 1998).

5. ANSI T1.635, Broadband ISDN - ATM Adaptation Layer Type 5 Common Part (AAL/CP5) Functions and Specifications, approved January 4, 1994.

6. ANSI T1.637, B-ISDN Signaling ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP), ANSI, approved July 11, 1994.

7. ANSI T1.645, B-ISDN Signaling ATM Adaptation Layer - Service Specific Coordination Function for Support of Signaling at the Network Node Interface (SSCF at the NNI), ANSI, approved January 3, 1995.

8. ANSI T1.652, B-ISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI, approved March 8, 1996.

9. ITU-T Recommendation Q.2110, BISDN - ATM Adaptation Layer - Service Specific Connection Oriented Protocol (SSCOP) Specification, July 1994.

10. ITU-T Recommendation Q.2140, B-ISDN - ATM Adaptation Layer - Service Specific Coordination Function for Signalling at the Network Node Interface (SSCF at NNI), February 1995.

11. ITU-T Recommendation Q.2144, BISDN Signaling ATM Adaptation Layer - Layer Management for the SAAL at the NNI, October 1995.

12. GR-82-CORE, Signaling Transfer Point (STP) Generic Requirements, Issue 3 (Telcordia, December 1999).

13. GR-606-CORE, LSSGR, Section 6.5, Common Channel Signaling (a Module of LSSGR, FR-64), Issue 3 (Telcordia, November 1999).

14. GR-1241-CORE, Supplemental Service Control Point (SCP) Generic Requirements, Issue 2 (Telcordia, October 1999).

15. ITU-T Recommendation I.121, “B-ISDN Protocol Reference Model and Its Application,“ November 1990.

16. ANSI T1.646, Broadband ISDN and DS1/ATM User-Network Interfaces: Physical Layer Specification, 1995.

References–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4References December 1999

GR-2878-CORE

17. ANSI T1.627, Broadband ISDN - ATM Layer Functionality and Specification, 1999.

18. ANSI T1.636, Telecommunications - B-ISDN Signaling ATM Adaptation Layer - Overview Description, 1994.

19. GR-2946-CORE, CCSNIS Supporting Network Interconnection Using High Speed Signaling Links (HSLs), Issue 3 (Telcordia, December 1999).

20. ANSI T1.403, American National Standards for Telecommunications, Network and Customer Installation Interfaces - DS1 Electrical Interface, 1999.

21. ANSI T1.408, American National Standards for Telecommunications, ISDN Primary Rate - Customer Installation Metallic Interfaces, Layer 1 Specification, 1990.

22. GR-820-CORE, OTGR Section 5.1: Generic Digital Transmission Surveillance(a Module of OTGR, FR-439), Issue 2 (Telcordia, December 1997).

23. GR-436-CORE, Digital Network Synchronization Plan, Issue 1 (Telcordia, June 1994) plus Revision 1, June 1996.

24. GR-1244-CORE, Clocks for the Synchronized Network: Common Generic Criteria, Issue 1 (Telcordia, June 1995).

25. GR-1248-CORE, Generic Requirements for Operations of ATM Network Elements, Issue 4 (Telcordia, November 1998).

26. GR-310-CORE, SEAS-STP Interface Specification: User Program Layer (UPL) Application Message Descriptions and Functional Requirements, Issue 2 (Telcordia, to be issued).

27. GR-1110-CORE, Broadband Switching System (BSS) Generic Requirements, Issue 3 (Telcordia, to be issued).

28. GR-1417-CORE, Broadband Switching System SS7 Generic Requirements, Issue 5 (Telcordia, to be issued).

29. GR-82-ILR, Signaling Transfer Point (STP) Generic Requirements Issues List Report, Issue 2C (Telcordia, December 1998).

30. TA-NWT-000365, SCP Node/SEASTM, SCP Node/SMS Generic Interface Specification, Issue 4 (Telcordia, June 1993).

31. GR-981-CORE, Service Configuration Management for Switching Network Elements (NEs), Issue 1 (Telcordia, December 1996).

32. TA-TSY-000387, Generic Requirements for Interim Defined Central Office Interface (IDCI), Issue 2 (Telcordia, July 1990).

References–2

ab


33. GR-495-CORE, Generic Operations Interfaces Using OSI Tools: Network Traffic Management (NTM), (a module of OTGR, FR-439), Issue 3 (Telcordia, December 1998).

34. TR-NWT-000746, Stored Program Control System/Operations System (SPCS/OS) - Network Traffic Management Operations System (NTM OS) Interface Via a Network Data Collection Operations System (NDC OS), FSD 45-18-0403 (a module of LSSGR, FR-64), Issue 4 (Telcordia, September 1998).

35. GR-376-CORE, OTGR Section 15.3: Generic Operations Interfaces Using OSI Tools: Network Data Collection (NDC), (a module of OTGR, FR-439), Issue 4 (Telcordia, to be issued).

36. TR-TSY-000740, Stored Program Control System/Operations System (SPCS/OS) - Network Data Collection Operations System (NDC OS) Interface, FSD 45-09-0100 (A module of LSSGR, FR-64), Issue 3 (Telcordia, October 1998).

37. TR-TSY-000825, OTGR Section 10.A: User-System Interface - User System Language (A module of OTGR, FR-439), Issue 2 (Telcordia, February 1988).

38. ANSI T1.111.6, Message Transfer Part Signaling Performance, American National Standards Institute, 1996.

39. ANSI T1.111, Signaling System Number 7 (SS7) - Message Transfer Part, American National Standards Institute, 1996.

40. ANSI T1.511, B-ISDN ATM Layer Cell Transfer - Performance Parameters, 1994.

41. GR-513-CORE, LSSGR: Power, Section 13, (a module of LSSGR, FR-64), Issue 1 (Telcordia, September 1995).

42. GR-63-CORE, Network Equipment-Building System (NEBS) Requirements: Physical Protection (a module of LSSGR, FR-64; TSGR, FR-440; and NEBS FR, FR-2063), Issue 1 (Telcordia, October 1995).

43. FR-796, Reliability and Quality Generic Requirements (RQGR), (Telcordia, 1999 Edition).

44. GR-874-CORE, An Introduction to the Reliability and Quality Generic Requirements (RQGR), (a module of the RQGR, FR-796), Issue 3 (Telcordia, April 1997).

45. TR-NWT-000284, Reliability and Quality Switching Systems Generic Requirements (RQSSGR), Issue 2 (Telcordia, October 1990).

46. GR-454-CORE, Generic Requirements for Supplier-Provided Documentation (a module of LSSGR, FR-64; OTGR, FR-439; and TSGR, FR-440), Issue 1 (Telcordia, December 1997).

References–3


GR-2878-CORE

47. GR-839-CORE, Generic Requirements for Supplier-Provided Training (a module of LSSGR, FR-64; OTGR, FR-439; and TSGR, FR-440), Issue 1 (Telcordia, July 1996).

48. TR-NWT-000840, Supplier Support Generic Requirements (a module of LSSGR, FR-64; TSGR, FR-440; and OTGR, FR-439), Issue 1 (Telcordia, December 1991).

49. GR-282-CORE, Software Reliability and Quality Acceptance Criteria (SRQAC) (a module of RQGR, FR-796), Issue 3 (Telcordia, December 1996) plus Revision 1, December 1997.

50. GR-505-CORE, Call Processing (a module of LSSGR, FR-64), Issue 1 (Telcordia, December 1997).

51. ANSI T1S1.3/99-113(06201), Criteria for Emergency Link Set Restart, contribution presented by Telcordia at T1S1.3, Raleigh, NC; June 14-18, 1999.

52. ITU-T PL/11-91, Addition to Implementors’ Guide for Q.2140, SG11 Temporary Document (for COM 11-R 8), ITU-T Study Group 11, Geneva, March 1-19, 1999.

53. ITU-T COM 11-R 8, Report of the Meeting Held in Geneva from 1-19 March 1999: Part 1 - Implementors’ Guide for Q.2140 (02/1995), March 1999.

References–4

ab


NOTE:

All Telcordia documents are subject to change, and their citation in this document reflects the most current information available at the time of this printing. Readers are advised to check the current status and availability of all documents.

To Contact Telcordia

Telcordia Customer Service8 Corporate Place, Room 3A-184Piscataway, New Jersey 08854-4156USA1-800-521-2673 (USA and Canada)1-732-699-5800 (all others)1-732-336-2559 (FAX)

To Order Documents

• Perform the following steps to order from the on-line catalog:

1. Enter the URL line: telecom-info.telcordia.com

2. Click on the Search button located on top

3. In the Keywords field, enter the document number (or keywords),then click on Submit Search.

or . . .

1. Enter the above URL line

2. Click on the Browse button located on top, then click on the subject of interest.

• Telcordia employees should perform the following steps:

1. Access the Telcordia Internal Home Page

2. Click on the Services button located on the left

3. Click on DOCS - Telcordia Product Catalog

4. Enter data in one or more of the fields (e.g., enter a document number in the Product Number field), then follow the instructions to search the on-line catalog.

References–5


GR-2878-CORE

References–6

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Glossary

Glossary Glossary

Definitions OSI — Open Systems Interconnection; a

CCS — Common Channel Signaling; an out-of-band method of signaling

changeback — A procedure for diverting signaling traffic to a signaling link that was previously out of service

combined link set — A collection of link sets, all of which have equal desirability in routing to a CCS destination

DPC — Destination point code; an address used in the SS7 protocol

ECSA — Exchange Carriers Standards Association; a North American standards group

FSD — Feature specific document; documents appended to the LSSGR, containing requirements that are most independent of other switching functions or most likely to change

ISDNUP — Integrated services digital network user part; a component part of the SS7 protocol

link set — A collection of CCS links, all of which terminate on the same two signaling points

MTP — Message transfer part; a component part of the SS7 protocol

OA&M — Operations, administration, and maintenance; a component of the SS7 protocol that specifies procedures and measurements for managing the CCS network

OPC — Originating point code; an address used in SS7 protocol

model for data networks proposed by the International Standards Organization

SCCP — Signaling connection control part; a component part of SS7 protocol

SCP — Service control point; transaction processor-based system that provides a network interface to data base services

SLS — Signaling link selection; a parameter that is part of the routing label within the SIF

SP — Signaling point; a node in the CCS network

SS7 — Signaling System Number 7; the protocol specified internationally by CCITT Study Group XI/2 and domestically by the ECSA T1X1 Working Group

STP — Signaling transfer point; the packet switch in the CCS network that transfers messages from one signaling link to another at Level 3

T1X1.1 — The working group within the ECSA's T1 (telephone) Committee that is responsible for U.S. CCS standards

Glossary–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Glossary December 1999

GR-2878-CORE

Glossary–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Acronyms

Acronyms Acronyms

AAL — ATM Adaptation Layer GTA — Global Title Address

ACM — Address Complete Message

AERM — Alignment Error Rate Monitoring

AIS — Alarm Indication Signal

ANM — Answer Message

ANSI — American National Standards Institute

ATM — Asynchronous Transfer Mode

BSS — Broadband Switching System

CCS — Common Channel Signaling

CCSN — Common Channel Signaling Network

CDV — Cell Delay Variation

CDVT — Cell Delay Variation Tolerance

CLP — Cell Loss Priority

CO— Central Office

COO— Changeover Order

CP — Common Part

CPCS — Common Part Convergence Sublayer

CMISE — Common Management Information Service Element

DC — Direct Current

DPC — Destination Point Code

EPI — Equipment Port Identifier

ESF — Extended Superframe Format

FCC — Federal Communications Commission

GDMO — Guidelines for the Definition of Managed Objects

GTT — Global Title Translation

HEC — Header Error Control

HSL — High-Speed Signaling Link

IAM — Initial Address Message

IDCI — Interim-Defined Central Office Interface

ISDN — Integrated Services Digital Network

ISUP — ISDN User Part

ITU-T — International Telecommunications Union - Telephony

LCD — Loss of Cell Delineation

LEC— Local Exchange Carrier

LM — Layer Management

LOF — Link Oscillation Filter

LOF — Loss of Frame

LOS — Loss of Signal

LPSI — Link Parameter Set ID

LSN — Link Set Name

MBS — Maximum Burst Size

MIB — Management Information Base

MPR — Marginal Performance Report

MSU — Message Signal Unit

MTP — Message Transfer Part

MTP3— Message Transfer Part - Level 3

NDC — Network Data Collection

NE — Network Element

Acronyms–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Acronyms December 1999

GR-2878-CORE

NEBS — Network Equipment Building System

NNI — Network Node Interface

NPC — Network Parameter Control

NTE— Network Transport Element

NTM — Network Traffic Management

OAM — Operations, Administration, and Maintenance

OCD — Out-of Cell Delineation

OOS — Out of Service

OPC — Originating Point Code

OS — Operations System

OSI — Open Systems Interconnection

PC — Point Code

PCR — Peak Cell Rate

PDU — Protocol Data Unit

PRM — Protocol Reference Model

PRS — Primary Reference Source

PSN — Public Switched Network

PVC — Permanent Virtual Circuit

QoS — Quality of Service

RDI — Remote Defect Indication

REL— Release Message

RLC — Release Complete Message

SAAL — Signaling ATM Adaptation Layer

SAR — Segmentation and Reassembly

SCCP — Signaling Connection Control Part

SD — Sequenced Data

SCP — Service Control Point

SCR — Sustainable Cell Rate

SIB — Status Indication Busy

SIE — Status Indication Emergency Alignment

SIF - Signaling Information Field

SIN —Status Indication Normal Alignment

SIO — Status Indication Out-of-Alignment

SIOS — Status Indication Out-of-Service

SIPO — Status Indication Process Outage

SLC — Signaling Link Code

SLS — Signaling Link Selection

SLT — Signaling Link Test

SLTA — Signaling Link Test Acknowledgment

SLTM — Signaling Link Test Message

SONET — Synchronous Optical Network

SRSCT — Signal Route Set Congestion Test Message

SS7 —Signaling System Number 7

SSCF — Service-Specific Coordination Function

SSCOP —Service-Specific Connection Oriented Protocol

SSCS — Service-Specific Convergence Sublayer

SSN — Subsystem Number

STP — Signaling Transfer Point

TCA — Threshold Crossing Alert

TFC — Transfer Controlled

TMN — Telecommunication Management Network

Acronyms–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Acronyms

UAL— User Application Layer

UI — User Information

UNI — User-Network Interface

UPC — Usage Parameter Control

UPL — User Program Layer

USI — User-System Interface

VC — Virtual Circuit

VCC — Virtual Channel Connection

VCI — Virtual Channel Identifier

VCL — Virtual Channel Link

VPC — Virtual Path Connection

VPI — Virtual Path Identifier

VPL — Virtual Path Link

Acronyms–3

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Acronyms December 1999

GR-2878-CORE

Acronyms–4

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Requirement-Object Index

Requirement-Object IndexROI

[1] R3-1 Page 3–2[2] R3-2 Page 3–2[3] R3-3 Page 3–2[4] R3-4 Page 3–3[5] R3-5 Page 3–4[6] R3-6 Page 3–5[7] R3-7 Page 3–5[8] CR3-8 Page 3–5[9] R3-9 Page 3–5[10] R3-10 Page 3–5[11] R3-11 Page 3–6[12] R3-12 Page 3–6[13] R3-13 Page 3–6[14] R3-14 Page 3–6[15] O3-15 Page 3–7[16] R3-16 Page 3–8[17] R3-17 Page 3–8[18] R3-18 Page 3–8[19] R3-19 Page 3–9[20] R3-20 Page 3–9[21] R3-21 Page 3–10[22] R3-22 Page 3–10[23] R3-23 Page 3–10[24] R3-24 Page 3–10[25] R3-27 Page 3–11[26] R3-28 Page 3–12[27] R3-29 Page 3–13[28] R3-30 Page 3–13[29] R3-31 Page 3–16[30] R3-32 Page 3–16[31] O3-33 Page 3–16[32] CR3-34 Page 3–17[33] CR3-35 Page 3–17[34] CR3-36 Page 3–17[35] CR3-37 Page 3–17[36] R3-38 Page 3–17[37] R3-39 Page 3–17[38] R3-40 Page 3–18[39] R3-41 Page 3–18

[40] R3-42 Page 3–19[41] R3-43 Page 3–19[42] R3-44 Page 3–19[43] R3-45 Page 3–19[44] R3-46 Page 3–20[45] R3-47 Page 3–21[46] CR3-48 Page 3–21[47] R3-49 Page 3–21[48] R3-59 Page 3–29[49] R3-60 Page 3–30[50] R3-61 Page 3–30[51] R3-62 Page 3–30[52] R3-63 Page 3–31[53] R3-68 Page 3–34[54] R4-1 Page 4–4[55] R4-2 Page 4–4[56] O4-3 Page 4–4[57] R4-4 Page 4–4[58] R4-5 Page 4–6[59] CR4-6 Page 4–7[60] O4-7 Page 4–11[61] R4-8 Page 4–13[62] O4-9 Page 4–14[63] R4-10 Page 4–14[64] CR4-11 Page 4–17[65] O4-12 Page 4–17[66] R4-13 Page 4–18[67] CR4-14 Page 4–19[69] R4-16 Page 4–20[70] O4-17 Page 4–21[71] R4-19 Page 4–22[72] R4-20 Page 4–23[73] CR4-21 Page 4–23[74] R4-22 Page 4–32[75] R4-23 Page 4–32[76] O4-24 Page 4–32[77] CR4-25 Page 4–33[78] CR4-26 Page 4–33[79] CR4-27 Page 4–33[80] O4-28 Page 4–34[81] R4-29 Page 4–34

ROI–1

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Requirement-Object Index December 1999

GR-2878-CORE

[82] R4-30 Page 4–35[83] O4-31 Page 4–38[84] R4-32 Page 4–39[85] O4-33 Page 4–40[86] R4-34 Page 4–40[87] CR4-35 Page 4–41[88] R4-36 Page 4–41[89] O4-37 Page 4–41[90] O4-38 Page 4–41[91] R4-39 Page 4–41[92] O4-40 Page 4–42[93] R4-41 Page 4–42[94] O4-42 Page 4–50[95] R4-43 Page 4–50[96] R4-44 Page 4–51[97] O4-45 Page 4–51[98] R4-46 Page 4–51[99] O4-47 Page 4–52[100] R4-48 Page 4–52[101] O4-49 Page 4–54[102] R4-50 Page 4–55[103] O4-51 Page 4–55[104] R4-52 Page 4–55[105] O4-53 Page 4–57[106] R4-54 Page 4–57[107] O4-55 Page 4–58[108] R4-56 Page 4–58[109] O4-57 Page 4–61[110] R4-58 Page 4–62[111] R4-59 Page 4–62[112] O4-60 Page 4–63[113] R4-61 Page 4–63[114] R4-62 Page 4–63[115] O4-63 Page 4–64[116] O4-64 Page 4–66[117] O4-65 Page 4–67[118] O4-66 Page 4–67[119] O4-67 Page 4–67[120] O4-68 Page 4–67[121] O4-69 Page 4–67[122] O4-70 Page 4–67

[123] O4-71 Page 4–67[124] O4-72 Page 4–68[125] O4-73 Page 4–68[126] R4-74 Page 4–69[127] R4-75 Page 4–69[128] R4-76 Page 4–70[129] R4-77 Page 4–70[130] R4-78 Page 4–70[131] R4-79 Page 4–70[132] R4-80 Page 4–70[133] R4-81 Page 4–71[134] R4-82 Page 4–71[135] R4-83 Page 4–72[136] R4-84 Page 4–73[137] R4-85 Page 4–73[138] R4-86 Page 4–73[139] R4-87 Page 4–74[140] R4-88 Page 4–74[141] R4-89 Page 4–76[142] R4-90 Page 4–78[143] R4-91 Page 4–78[144] R4-92 Page 4–81[145] R4-94 Page 4–82[146] R4-95 Page 4–83[147] R4-96 Page 4–83[148] R4-97 Page 4–84[149] R4-98 Page 4–85[150] R4-99 Page 4–86[151] R4-100 Page 4–87[152] R4-101 Page 4–87[153] R4-102 Page 4–88[154] R4-105 Page 4–88[155] R4-106 Page 4–89[156] R4-107 Page 4–89[157] R4-108 Page 4–90[158] R4-109 Page 4–90[159] O4-110 Page 4–91[160] O4-111 Page 4–91[161] R4-112 Page 4–92[162] R4-113 Page 4–92[163] R4-114 Page 4–94

ROI–2

ab

GR-2878-COREIssue 4 Generic Requirements for CCS Nodes Supporting ATM HSLsDecember 1999 Requirement-Object Index

[164] R4-115 Page 4–99[165] R4-116 Page 4–99[166] R4-117 Page 4–100[167] R4-118 Page 4–101[168] R4-119 Page 4–102[169] R4-120 Page 4–102[170] R4-121 Page 4–103[171] R4-122 Page 4–103[172] R4-123 Page 4–103[173] R4-124 Page 4–103[174] O5-1 Page 5–2[175] O5-2 Page 5–3[176] CR5-3 Page 5–3[177] R5-10 Page 5–6[178] CR5-11 Page 5–7[179] CR5-12 Page 5–8[180] R5-13 Page 5–8[181] CR5-14 Page 5–9[183] CR5-17 Page 5–10[184] CR5-18 Page 5–10[185] CR5-20 Page 5–11[186] CR5-21 Page 5–12[187] CR5-24 Page 5–13[188] CR5-26 Page 5–13[189] R5-27 Page 5–14[190] R5-28 Page 5–14[191] R6-1 Page 6–4[192] R6-2 Page 6–5[193] R6-3 Page 6–6[194] R6-4 Page 6–6[195] R7-1 Page 7–1[196] R7-2 Page 7–1[197] R10-1 Page 10–1[198] R10-2 Page 10–1[199] R10-3 Page 10–2[200] R10-4 Page 10–2[201] R10-5 Page 10–2[202] R10-6 Page 10–2[203] CR3-25 Page 3–10[204] CR3-26 Page 3–11[205] O3-64 Page 3–33

[206] CO3-65 Page 3–33[207] CO3-66 Page 3–33[208] R3-67 Page 3–34[209] CR4-15 Page 4–20[210] O4-18 Page 4–21[211] O4-93 Page 4–81[212] O4-103 Page 4–88[213] O4-104 Page 4–88[214] CR5-4 Page 5–4[215] CR5-5 Page 5–4[216] CR5-6 Page 5–4[217] CO5-7 Page 5–5[218] CO5-8 Page 5–5[219] CO5-9 Page 5–6[220] CO5-16 Page 5–9[221] CO5-19 Page 5–10[222] CO5-22 Page 5–12[223] CO5-23 Page 5–12[224] CO5-25 Page 5–13[225] R3-50 Page 3–22[228] O3-57 Page 3–27[229] CR3-58 Page 3–28[230] R3-51 Page 3–23[231] R3-52 Page 3–23[232] R3-53 Page 3–24[233] CO3-54 Page 3–24[234] R3-55 Page 3–25[235] O3-56 Page 3–25

ROI–3

Generic Requirements for CCS Nodes Supporting ATM HSLs Issue 4Requirement-Object Index December 1999

GR-2878-CORE

ROI–4

ab

TELCORDIA ENTERPRISE LICENSE AGREEMENT AND LIMITED WARRANTY For Technical Documents: Generic Requirements (GRs), Special Reports (SRs), Technical References (TRs), Technical

Advisories (TAs), Family of Requirements (FRs), Family of Documents (FDs), Framework Advisories (FAs), Science Technologies (STs), Message Driven Program (MDPs), Information Publications (IPs), Audio Visuals (AVs) and

Telcordia Practices (BRs)

IMPORTANT! READ CAREFULLY

USE OF THIS PRODUCT INDICATES THAT YOU (LICENSEE OR USER) HAVE READ AND ACCEPT THE TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE WITH THE TERMS OF THIS AGREEMENT, PROMPTLY RETURN THE UNUSED

PRODUCT WITH ALL SEALS INTACT TO THE ADDRESS LISTED BELOW FOR A TELCORDIA CREDIT.

1. LICENSE GRANT

Telcordia grants to customer (“Licensee”) a non-exclusive, non-transferable, limited license to use this Licensed Product by employees of Licensee (“Users”) for internal business purposes only. All intellectual property rights, title and interest in all Licensed Products furnished to Licensee remain in Telcordia. This License does not preclude the execution of additional license agreements with Licensee for the Licensed Product(s).

Telcordia has exclusive rights to all Licensed Products which are protected by United States and international copyright laws.

2. LICENSEE’S USE:

a) Licensee may place the Licensed Products on a Local Area Network, Wide Area Network, server, internal web site, or other electronic computing platform shared or accessible to employees or affiliates of Licensee. Licensee may make paper and electronic copies of Licensed Products as determined by Licensee to be necessary for Licensee's internal purposes; provided all copies, in whole or in part, of the Licensed Products shall bear the same Telcordia copyright and disclaimer notices legend as appear on the Licensed Products originally furnished to Licensee by Telcordia.

b) Subject to the preceding paragraph, Licensee may reproduce and distribute Licensed Products to “Affiliates” defined as (i) the parent entity (corporation or partnership) which directly or indirectly owns the majority of the outstanding shares or interests of Licensee, (ii) a sibling entity (corporation or partnership) the majority of whose outstanding shares or interests are owned by its parent entity, or (iii) a subsidiary entity (corporation or partnership) the majority of whose outstanding shares or interests are owned by Licensee, provided, however, that such entity shall continue to remain an Affiliate hereunder only as long as the applicable ownership interest as described above exists.

Licensee may sublicense the rights granted in this section to an Affiliate, provided Licensee shall remain responsible for any breach by such Affiliate. Licensee shall ensure that such Affiliate as assignee agrees to be bound by the rights, obligations and limitations set forth herein, and such Affiliate shall be responsible for any breach by such Affiliate and Licensee shall ensure that Telcordia shall have the right of direct enforcement of such obligations against such Affiliate. If a direct enforcement claim is denied, for any reason, it is agreed that Licensor may assert such claim against Licensee.

c) Licensee may copy portions of Licensed Products to create specifications and related documentation (the “Licensee Documentation”).

d) Licensee may, in marketing a product or related services (collectively, “Licensee Product”), (i) make reference to the Licensed Product utilized in the development of Licensee Product; provided that Licensee shall make no statement, representation or warranty on behalf of Telcordia including but not limited to a certification by Telcordia of a product’s or related service’s compliance with the Licensed Product, unless otherwise agreed to by the parties in writing; or (ii) distribute the

Licensee Documentation to a third party prior to sale of the Licensee Product.

e) Licensee may refer to and/or incorporate portions of such Licensed Products in the Licensee Documentation for the Licensee Product and copy the Licensee Documentation for distribution in conjunction with the sale of the Licensee Product to any third party so long as the original Telcordia and copyright legends, as applicable, are acknowledged on the specifications and/or documentation.

f) Licensee must treat the Licensed Product(s) like any other copyrighted material.

g) Except as otherwise stated, it is understood that the foregoing license does not include the right to make copies of the Licensed Products for sale to third parties or to create derivative works for sale.

USER MAY NOT: a) Copy the Licensed Product, except as provided above; b) Make copies of the Licensed Product or portions thereof as are

permitted above for internal purposes that contain provisions that conflict or differ in content from comparable provisions of the Licensed Product, unless such differences are identified specifically, and it is made clear in such copies that the results are not part of the Licensed Product;

c) Transfer the Licensed Product to another party, except as provided above;

d) Licensee may not make the Licensed Product available, in whole or in part for the purposes of external distribution to third parties other than Affiliates.

e) Grant sublicenses, leases, or other rights to the Licensed Product or rent the Licensed Products to others, except as provided above; or

f) Make telecommunications data transmissions of the Licensed Product to the public or any third party.

g) Data, in whole or in part, may not be extracted from the Licensed Product(s) for use in any derivative Licensee product or used to verify and subsequently modify data in any Licensee product which is sold, licensed or otherwise provided to third parties unless Licensee has executed a separately negotiated Special License Agreement with Telcordia, except as provided above.

3. AUDITS

Upon reasonable written notice to Licensee, Telcordia shall have the right to review Licensee’s compliance with the terms and conditions of this License Agreement (“Agreement”). If such review reveals a violation of the requirements set forth herein, in addition to any other remedies it may have, Telcordia may terminate this Agreement in accordance with the Termination section of this Agreement.

4. FEES AND PAYMENTS All fees and charges due hereunder shall be paid in full within thirty (30) days of the date of the invoice. Overdue payments are subject to a late payment charge, calculated and compounded monthly, and calculated at an annual rate of either (1) one percent (1%) over the prime rate available in New York City, as published in The Wall Street Journal on the first Monday (or the next bank business day) following the payment due date; or (2) 12 percent (12%), whichever shall be

higher. If the amount of the late payment charge exceeds the maximum permitted by law, the charge will be reduced to that maximum amount.

Licensee shall pay or reimburse Telcordia for all sales or use taxes, duties, or levies imposed by any authority, government or government agency (other than those levied on the net income of Telcordia) in connection with this Agreement. If Telcordia is required to collect a tax to be paid by Licensee, Licensee shall pay this tax on demand. If Licensee fails to pay these taxes, duties or levies, Licensee shall pay all reasonable expenses incurred by Telcordia, including reasonable attorney's fees, to collect such taxes, duties or levies. Telcordia shall provide Licensee with one (1) Copy of the Licensed Product. Any additional copies in cd or paper media will be provided to Licensee at a cost of $75.00 per copy. Please contact our Customer Call Center noted below.

5. LIMITED WARRANTY Telcordia warrants that the media on which the Licensed Product is provided is free from defects in materials and workmanship for 90 days. Licensee’s sole remedy for breach of this warranty is Telcordia’s Product Replacement Plan described below. This warranty applies only to the original Licensee.

6. DISCLAIMER OF WARRANTIES EXCEPT AS SET FORTH ABOVE, THE LICENSED PRODUCT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, EVEN IF TELCORDIA HAS BEEN MADE AWARE OF SUCH PURPOSE, OR ANY WARRANTY AGAINST INFRINGEMENT OF PATENTS OR OTHER INTELLECTUAL PROPERTY RIGHTS. LICENSEE ASSUMES RESPONSIBILITY FOR THE SELECTION OF THE LICENSED PRODUCT TO ACHIEVE ITS INTENDED RESULTS, AND FOR THE USE AND RESULTS OBTAINED FROM THE LICENSED PRODUCT.

7. LIMITATION OF LIABILITY THE ENTIRE LIABILITY OF TELCORDIA, AND LICENSEE’S EXCLUSIVE REMEDY, IS THE REPLACEMENT OF ANY LICENSED PRODUCT WHICH DOES NOT MEET THE TELCORDIA LIMITED WARRANTY AND IS RETURNED TO TELCORDIA WITHIN 90 DAYS. IN NO EVENT WILL TELCORDIA BE LIABLE TO LICENSEE FOR ANY DAMAGES, INCLUDING DIRECT DAMAGES, LOST PROFITS, OR OTHER INDIRECT, SPECIAL, INCIDENTAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES ARISING OUT OF THIS AGREEMENT, EVEN IF TELCORDIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE WARRANTY GIVES LICENSEE SPECIFIC LEGAL RIGHTS, AND LICENSEE MAY ALSO HAVE OTHER RIGHTS WHICH VARY FROM STATE TO STATE. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION MAY NOT APPLY TO LICENSEE.

8. THIRD PARTY PRODUCTS AND INFORMATION WARRANTY Telcordia does not warrant Third Party products or information which Telcordia may use to prepare the Licensed Product. Third Party products or information may be warranted by Third Parties as expressly provided in the documentation accompanying the Third Party product or information, if any. Licensee’s exclusive remedy under any Third Party warranty is as provided in the Third Party documentation accompanying the Third Party product or information, if any.

9. LICENSED PRODUCT REPLACEMENT PLAN During the first 30 days after Licensee licenses the Telcordia Licensed Product, Telcordia will replace at no charge any Licensed Product which is returned to Telcordia because its media is defective in materials or workmanship. Returns for replacement of a defective Licensed Product should be sent postpaid to Telcordia using the Return Policy procedures stated below.

10. RETURN POLICY Licensed Product(s) may be returned within 30 days of receipt for Telcordia credit only. Returned Licensed Products must be in their original packaging with all seals intact. Returns not found to be defective in materials or workmanship will be subject to a 10%

restocking fee. Licensed Products that have been delivered electronically (downloaded from the Superstore) are not eligible for credits, refunds or returns, even if duplicative with Licensed Products that are the subject of prior or contemporaneous orders. Licensee assumes all responsibility for managing its inventory of Licensed Product(s).

11. TERMINATION

If Licensee or its User breaches one or more of its obligations under this Agreement, Telcordia may elect at any time, in addition to any other remedy, to terminate the license and rights granted. Prior to the termination, Telcordia must give Licensee two (2) months written notice specifying the breach. Telcordia may terminate the license and rights granted if Licensee does not remedy all breaches specified in the written notice within the two (2) month notice period. Upon termination of the license and rights granted, Licensee shall destroy or return all Licensed Product(s) and Documentation, including all copies, and certify in writing to Telcordia the destruction or return.

12. PUBLICITY

Notwithstanding anything herein to the contrary, each party is prohibited from using in advertising, publicity, promotion, marketing, or other similar activity, any name, trade name, trademark, or other designation including any abbreviation, contraction or simulation of the other without the prior, express, written permission of the other.

13. GENERAL Reexport. Licensee acknowledges that any commodities and/or technical data provided under this Agreement is subject to the Export Administration Regulations (“the EAR”) administered by the U.S. Commerce Department and that any export or re-export thereof must be in compliance with the EAR. Licensee agrees that it shall not export or reexport, directly or indirectly, either during the term of this Agreement or after its expiration, any commodities and/or technical data (or direct products thereof) provided under this Agreement in any form to destinations in Country Groups D:1 or E:2, as specified in Supplement No. 1 to Part 740 of the EAR, and as modified from time to time by the U.S. Department of Commerce, or to recipients or destinations that are otherwise controlled or embargoed under U.S. law. Foreign Tax Payment. For a Licensee which is not a United States corporation, Telcordia will not accept remittance of less than the full amount billed to Licensee as full payment unless: a) Licensee withholds that amount to satisfy tax withholding

requirements imposed by the country (other than the United States) in which Licensee resides or in which Licensee has accepted delivery of the Licensed Product; and

b) Licensee furnishes a receipt issued by the withholding tax jurisdiction and certifying deposit of the withheld amount into its treasury or other tax depository to Telcordia’s sole credit, or a certification on Licensee’s stationery that Licensee has deposited the withheld amount into its tax jurisdiction’s treasury or other tax depository to Telcordia’s sole credit.

Further, to ensure the orderly processing of Telcordia tax returns, Licensee shall provide to Telcordia a summary of all amounts withheld during the year no later than ten business days after December 31 of each year. Governing Law. This Agreement is a contract between Telcordia and the Licensee of the Licensed Product. This contract is to be interpreted in the federal and state courts of New Jersey, in accordance with the laws of the State of New Jersey without regard to its conflict of laws principles, and the parties consent to the jurisdiction of such courts for this purpose. Entire Agreement. Licensee further agree that this is the complete and exclusive statement of the Agreement between Licensee and Telcordia and supersedes any proposal or prior Agreement, oral or written, or any other communication between us relating to the subject matter of this Agreement. All questions about this Agreement should be directed to: Telcordia Technologies, Inc. Customer Service Center

One Telcordia Drive, RRC 1B180 Piscataway, NJ 08854

Phone: 1.866.672.6997 (USA) +1.732.699.6700 (Worldwide)

END OF TERMS AND CONDITIONS

Agreed: Company:____________________________________ Name:_______________________________________ Signature:___________________________________ Date:________________________________________

Revised 3/06

Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links

Documents

Transcript of Generic Requirements for CCS Nodes Supporting ATM High-Speed Signaling Links