1、 ATIS-0300026 Next Generation Interconnection Interoperability (NGIIF) Reference Document Part VI, Network Management Guidelines Version 12.0 ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the in
2、formation, entertainment and communications industry. More than 200 companies actively formulate standards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Servic
3、es, Architectural Platforms and Emerging Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Connected Vehicle, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North
4、American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited
5、by the American National Standards Institute (ANSI). For more information, please visit www.atis.org. Notice This document was developed by the Alliance for Telecommunications Industry Solutions (ATIS) sponsored Next Generation Interconnection Interoperability Forum (NGIIF). The NGIIF addresses next
6、-generation network interconnection and interoperability issues associated with emerging technologies. Specifically, it develops operational procedures which involve the network aspects of architecture, disaster preparedness, installation, maintenance, management, reliability, routing, security, and
7、 testing between network operators. In addition, the NGIIF addresses issues which impact the interconnection of existing and next generation networks and facilitate the transition to emerging technologies. All changes to this document shall be made through the NGIIF issue resolution process. Note Re
8、garding Previous Versions The NIIF Reference Document was formerly known as the Network Operations Forum (NOF) Reference Document. The NOF Reference Document was published and maintained by Bellcore. The last version of the NOF Reference Document is Issue 13. Disclaimer and Limitation of Liability T
9、he information provided in this document is directed solely to professionals who have the appropriate degree of experience to understand and interpret its contents in accordance with generally accepted engineering or other professional standards and applicable regulations. No recommendation as to pr
10、oducts or vendors is made or should be implied. NO REPRESENTATION OR WARRANTY IS MADE THAT THE INFORMATION IS TECHNICALLY ACCURATE OR SUFFICIENT OR CONFORMS TO ANY STATUTE, GOVERNMENTAL RULE OR REGULATION, AND FURTHER NO REPRESENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTIC
11、ULAR PURPOSE OR AGAINST INFRINGEMENT OF INTELLECTUAL PROPERTY RIGHTS. ATIS SHALL NOT BE LIABLE, BEYOND THE AMOUNT OF ANY SUM RECEIVED IN PAYMENT BY ATIS FOR THIS DOCUMENT, WITH RESPECT TO ANY CLAIM, AND IN NO EVENT SHALL ATIS BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. A
12、TIS EXPRESSLY ADVISES THAT ANY AND ALL USE OF OR RELIANCE UPON THE INFORMATION PROVIDED IN THIS DOCUMENT IS AT THE RISK OF THE USER. ATIS-0300026, NGIIF Reference Document, Part VI, Network Management Guidelines, formerly NIIF 5022 The NGIIF Reference Document, Part VI, Network Management Guidelines
13、, is an ATIS standard developed by the NGIIF. Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2011 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reproduced in a
14、ny form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. 2 Table of Contents 1 GENERAL 3 2 MINIMUM SET OF NETWORK MANAGEMENT CONTROLS 3 3
15、TERMINATING REROUTES INVOLVING AN INTEREXCHANGE CARRIER 4 4 TC SWITCH OR NETWORK FAILURES OR EXTENDED OUTAGES 4 5 MEDIA STIMULATED MASS CALLING (MSMC) EVENTS . 5 6 NETWORK MANAGEMENT SS7 CONTROLS FOR HIGH VOLUME CALL IN (HVCI) EVENTS 5 6.1 DESCRIPTION 5 6.2 SOLUTION . 6 6.3 CONCLUSION 6 7 SS7 NETWOR
16、K FAILURES 7 7.1 NETWORK RESTORATION PLANS 7 8 EMERGENCY COMMUNICATIONS . 8 8.1 PUBLIC PACKET SWITCHED NETWORK (PPSN) 8 9 TERMINATION OF TELECOMMUNICATIONS CUSTOMER SERVICE 8 10 RESPONSIBLE ORGANIZATION (RESPORG) 9 11 RESPORG TROUBLE REPORTING RESPONSIBILITIES 9 12 RECORDED ANNOUNCEMENTS 9 13 SS7 NE
17、TWORK OUTAGE MEASUREMENT 9 14 NETWORK MODIFICATION NOTIFICATION FORM 10 15 BLOCKED CALL MEASUREMENT FOR INTERCONNECTED COMPANY . 10 16 GLOSSARY . 10 17 APPENDIX A, MEDIA STIMULATED MASS CALLING EVENT NOTIFICATION FORM 11 18 APPENDIX B, COMPANY NAME . 12 18.1 NETWORK MODIFICATION NOTIFICATION FORM .
18、12 3 1 GENERAL This document has been developed to provide the Network Management personnel of the Telecommunications Provider (TP) and Telecommunications Customers (TC) with alternative guidelines for traffic management when the following conditions arise. Network congestion due to facility failure
19、s or abnormal calling periods. TC Switch or Network Failures or Extended Outages. SS7 Network failures. Termination of TC Service. Specific procedures will require preplanning and negotiations between the companies involved. This document does not replace nor supersede tariffs, contracts, or any oth
20、er legally binding documents. This document is being revised to delete the Contact Directories and add reference to a Service Provider Contact Directory. The Telecommunications Providers invite and encourage frequent TP and TC Network Management meetings to discuss and plan traffic management option
21、s. If a TC has a need or desire to investigate the availability and use of the options described in the following, they should contact the Telecommunications Provider Network Management Center listed in the Service Provider Contact Directory. 2 MINIMUM SET OF NETWORK MANAGEMENT CONTROLS The followin
22、g Network Management Controls represent a minimum level of control that is needed in every interconnected network switching node in order to ensure the overall integrity and reliability of the interconnected network: Automatic Code Gap (ACG) Call Gap (CG) Cancel To (CANT) Skip (SKIP) Automatic Conge
23、stion Control (ACC) Automatic Code Gap (ACG) - ACG is a code control that is implemented automatically in response to a request from a database to limit traffic. This control can be in the form of six (6) through ten (10) digits. A six-digit control is used to protect the database in instances of a
24、general overload. A ten-digit control is used to control focused overloads. Call Gap - CG is a code control that regulates the maximum rate at which calls are released toward a destination code. Equipment vendors commonly provide the capability to Call Gap at intervals of 0.10 to 600 seconds on a ra
25、nge of numbers from three (3), six (6), or seven (7), through ten (10) digits. Cancel To - CANT is a trunk group control that allows traffic to be canceled before hunting for a circuit to a destination. Equipment vendors commonly provide the capability to implement this control on a percentage basis
26、. SKIP - SKIP is a trunk group control that allows traffic to be directed to the next route before hunting for a circuit to a destination. Equipment vendors commonly provide the capability to implement this control on a percentage basis. 4 Automatic Congestion Control - ACC is a two-part feature. In
27、 order for ACC to function properly it must be implemented in the originating and terminating nodes of an interconnected network. The first part enables a (terminating) network node to alert interconnected nodes that it is in Machine Congestion 1 or 2 (MC1 or MC2). The second part allows a distant (
28、originating) network node to automatically react to an ACC message and enact trunk group controls (CANT and SKIP) on specific trunk groups. 3 TERMINATING REROUTES INVOLVING AN INTEREXCHANGE CARRIER Where the capability exists, terminating reroutes may be implemented temporarily to relieve network co
29、ngestion due to facility failures or recognized abnormal calling periods (e.g., Mothers Day, disasters, etc). Under these circumstances, reroutes have the potential to improve call completions and service to the customer. This procedure will not be used to circumvent normal trunk servicing. The only
30、 calls, from an TC, to be rerouted are terminating calls from an TC to an Access Tandem (AT) and are to be rerouted from the AT using a qualified office as a Via Office to the called End Office. The guidelines for rerouting are as follows: Only one additional link should be added to the overall conn
31、ection. At an TCs request a mutually agreed upon sample of potential reroutes should be activated at an agreed upon time and tested by the TC for transmission. As part of the pre-planning process, all involved links should meet TPs design requirements. The test results will be provided to the TP who
32、 will furnish them to the other TCs, upon request. A count of rerouted calls should be furnished to the TP trunk servicing, forecasting and design engineers so that rerouted traffic will not be reflected as capacity requirement for future capital expenditures. The Network Management Center should mo
33、nitor the via office performance prior to and during the reroute to assure the quality of the network is maintained. 4 TC SWITCH OR NETWORK FAILURES OR EXTENDED OUTAGES In the case where an TC suffers an extended network outage, the following options may be available to the TP and TC to reroute end
34、users. TP and TC pre-planning is strongly advised since this option list is not all inclusive. The TC or TCs have a reciprocal agreement to carry the traffic. This will require preplanning to assess the work necessary to reroute originating traffic (e.g., Translations and Billing). If the TC has mul
35、tiple switching POPs in the LATA, reroute to the working POP. The TP may provide a special recorded announcement at the request of the affected TC. The TP may route originating traffic to a recorded announcement with 101XXXX codes of TCs that volunteer to carry the traffic on an interim basis. The T
36、P and TC may decide to do nothing. 5 5 MEDIA STIMULATED MASS CALLING (MSMC) EVENTS The TP and/or TC needs to be advised of MSMC event, prior to the event taking place. The company receiving a customer request for a planned Media Stimulated Calling Event must notify the affected companys Network Mana
37、gement Center using the MSMC Event Notification Form (Appendix A). With respect to the fields “Nature of Service” and Contest Rules and Prize Information”, requesting such information on the MSMC Event Notification Form, it shall be understood that the provision of such information or any part there
38、of is optional and voluntary. Contact will be made via FAX or E-Mail which may be followed by a confirming telephone call to numbers listed in the NGIIF Service Provider Contact Directory for Media Stimulated Calling Event Contact. Control of the TP or TC network load during the event, should first
39、be attempted by the TP/TC in their respective network. The amount of control should be at the discretion of the individual TP/TC. Although cooperative Network Management controls during the event may be required, the TP/TC should not be expected to invoke controls before the actual event occurs. The
40、 TPs will provide the following information when network management controls are used on Toll Free calls: The start and stop time of control activities, The level of control, The number of blocked calls, where technology is available, The reason for the control. The party experiencing the outage wil
41、l inform their interconnected companies, as soon as possible. Existing FCC outage guidelines shall be utilized for reporting purposes. When a Toll Free number is identified, that number should only be passed to the TC(s) or RESP ORG carrying that traffic. 6 NETWORK MANAGEMENT SS7 CONTROLS FOR HIGH V
42、OLUME CALL IN (HVCI) EVENTS 6.1 Description High Volume Call In (HVCI) choke networks are designed to mitigate network congestion from large numbers of incoming calls solicited by an individual customer such as a radio station. Existing FCC guidelines specify in-band Multi-Frequency signaling trunki
43、ng between the originating switch and choke tandem switch. Figure 1 presents a simple diagram of the HVCI network. In this arrangement, excessive call attempts are terminated at the originating switch by limiting available outgoing trunks associated with HVCI NPA-NXX routing. TDM CHOKESVGOFCEOEO CUS
44、TOMER7D, 1+10D MF SS7/MF SFG/VFGChoke (HVCI) Network Architecture Historically, separate dedicated MF trunks between end offices and the choke tandem were used for HVCI codes. In this case, the volume of HVCI call attempts to the tandem was limited by the number of dedicated trunks to the choke tand
45、em. Often such trunk groups are limited to 2-12 members. Network Operators using newer technologies do not typically support MF signaling, or dedicated trunks to the choke tandem. Therefore calls for HVCI codes are carried to the choke tandem over common trunks. In this case, 6 the volume of HVCI ca
46、ll attempts to the tandem depends on the size of the common trunk groups carrying HVCI calls. The volume of SS7 signaling associated with HVCI impacts signaling network capacity. The unsuccessful call attempt rate at a choke tandem can be large enough to trigger A-link growth for the tandem. This ca
47、n especially be a problem for choke tandems where common trunks are used to deliver HVCI calls to the tandem. Since unsuccessful calls are not completing, it is desirable to handle them in a way that minimizes demands on signaling network capacity. 6.2 Solution “Far End Busy” is one approach that ca
48、n be used to reduce the frequency of call attempts to HVCI codes at a choke tandem. With this scheme, the tandem switch supplies the audible busy tone (or announcement) to the calling party. The incoming trunk is held up while busy tone is applied by the tandem and is not released until the calling
49、party goes “on-hook” or until the tone announcement cycle completes. (Normally when an incoming SS7 trunk encounters a “no trunk available” condition, the call is quickly released back to the originating switch, and the tone/announcement is provided from the originating switch.) Implementation to hold trunks up to tone/announcement for blocked calls is relatively simple. An overflow route is configured for the HVCI trunk leaving the tandem. The overflow route can be pointed to appropriate tone/announcement circuits. When a call to an HV
