ATIS 0300027-2011 Next Generation Interconnection Interoperability (NGIIF) Reference Document Part VI Network Management Guidelines Attachment A Emergency SS7 Restoration Operation.pdf

1、 ATIS-0300027 Next Generation Interconnection Interoperability (NGIIF) Reference Document Part VI, Network Management Guidelines Attachment A Emergency SS7 Restoration Operations Planning Considerations Version 12.0 ATIS is the leading technical planning and standards development organization commit

2、ted to the rapid development of global, market-driven standards for the information, 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 Technolog

3、ies, Quality of Service, Billing and Operational Support, Emergency Services, 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 Downloadabl

4、e Security, Policy Management and Network Optimization. ATIS is the North 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 th

5、e Inter-American Telecommunication Commission (CITEL). ATIS is accredited 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 Generatio

6、n Interconnection Interoperability Forum (NGIIF). The NGIIF addresses next-generation network interconnection and interoperability issues associated with emerging technologies. Specifically, it develops operational procedures which involve the network aspects of architecture, disaster preparedness,

7、installation, maintenance, management, reliability, routing, security, and 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

8、document shall be made through the NGIIF issue resolution process. Note Regarding 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 NO

9、F Reference Document is Issue 13. Disclaimer and Limitation of Liability The 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 pro

10、fessional standards and applicable regulations. No recommendation as to products 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 REPRE

11、SENTATION OR WARRANTY IS MADE OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR 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

12、BE LIABLE FOR LOST PROFITS OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES. ATIS 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-0300027, NGIIF Reference Document, Part VI, Network Management Guidelines, Attachment A,

13、 Emergency SS7 Restoration Operations Planning Considerations, Formerly NIIF 5023 The NGIIF Reference Document, Part VI, Network Management Guidelines, Attachment A, Emergency SS7 Restoration Operations Planning Considerations, is an ATIS standard developed by the NGIIF. Published by Alliance for Te

14、lecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC 20005 Copyright 2011 by Alliance for Telecommunications Industry Solutions All rights reserved. 2 No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the pri

15、or written permission of the publisher. For information contact ATIS at 202.628.6380. ATIS is online at . Printed in the United States of America. 3 EMERGENCY SS7 RESTORATION OPERATIONS PLANNING CONSIDERATIONS Table of Contents 1. GENERAL 4 2. FAILURE TYPES 4 A. Signaling Transfer Point (STP) Failur

16、es 4 B. Link and Linkset Failures 5 C. Congestion 5 3. LINES OF DEFENSE 5 A. Traffic Categories and Considerations 6 B. Preventing Propagation and Lessening Impacts of Failures 7 C. Manual Intervention in the CCSN 7 D. NM Preplans 8 E. Access to Preplans 9 F. Customer Notification 9 G. Media 9 H. An

17、nouncements 9 I. Operator Alert 9 4. RESTORATION 10 A. Restoring the CCSN 10 B. Release and Patch Administration 10 C. Restoring Service 12 D. Network Management and CCSN Events 13 4 1 GENERAL Throughout this document the CCSN and PSTN are addressed as separate networks, even though both subnetworks

18、 comprise the new public switched network and both are necessary to complete calls. This is done in order to better focus on their uniqueness and concerns, separately, before attempting to merge the two, and perhaps miss some important issues. In addition, although more is presented on the maintenan

19、ce side, maintenance should not be construed as more important than network traffic management. In the order of things, however, maintenance is vital with the advent of the CCSN. The CCSN must evolve to a consistently stable network to allow Network Traffic Management (NTM) efforts to be effective.

20、Additionally, NTM functions can greatly assist in this stability. Recent Common Channel Signaling Network (CCSN) outages are causing speculation that more severe problems will occur in the future. The industry in general is concerned that they may not be properly prepared to diagnose troubles quickl

21、y and contain their proliferation in an integrated CCSN. One of several areas being addressed in this document is the recovery procedures for CCSN failures. Also addressed are actions that might be taken to contain the spread, or worsening, of network failures when Telecommunications Providers (TPs)

22、 and Telecommunications Customers (TCs) are interconnected. These two areas of concern are inter-related and require both an understanding of their inter-relationship and a comprehensive plan of action. This document assumes a 100% deployment of CCS interconnection between an TP and TC. It provides

23、a view of factors that a typical Network Provider might consider in planning responses to potential network events. 2 FAILURE TYPES As with any network, there are numerous events that can cause failures. In this respect the CCSN is quite similar to other networks. Unlike most other networks, however

24、, the CCSN comes the closest to being self-managed. It automatically takes preprogrammed actions (via the SS7 protocol) to continue functioning when various abnormal conditions exist. Signaling Network Management functions provide for reconfiguration of CCSN resources in the event of signaling link

25、or signaling point failures. When a failure occurs, the objective is that, the reconfiguration should be carried out so that messages are not lost, duplicated or put out of sequence and that the number of messages in the network does not become excessive. These types of failures, which are transpare

26、nt to the PSTN and the traditional Network Traffic Management (NTM), are not reviewed in this document except when, in combination with other events, they will have an impact on service. A point to be made, however, is that efforts are being made to review and enhance the protocol, if necessary, to

27、make it more reliable and effective in failure scenarios since self-healing networks is the strategic direction. We do not suggest that these failures are not important. Any failure in the CCSN must be viewed as extremely crucial and expeditiously dealt with since combinations of events can impact c

28、ustomers and have potentially far reaching consequences. Failures that will be discussed in this document include those described in the following subsections. 2.1 Signaling Transfer Point (STP) Failures STP failures, at present, represent the greatest threat to the overall reliability of a CCSN, si

29、nce links from all associated Signaling End Points (SEP) terminate on the STP pair. The failure of a single STP should not, in and of itself, cause any severe impact on the ability of the PSTN to route calls. It is only when an STP failure is coupled with another condition in the CCSN that signaling

30、 traffic is impaired, causing an impact on the PSTN. Examples of conditions under which an STP failure will impact the CCSNs message processing capabilities are as follows: If software errors in either the mated STP or an associated SEP trigger an abnormal reaction to the failed STP, individual SEPs

31、 or all associated SEPs could become isolated from the CCSN. 5 If individual signaling linkset failures to the mated STP are in effect prior to and during the STP failure; offices could be isolated. If the CCS network and its components have not been engineered adequately, congestion etc. could be e

32、ncountered. 2.2 Link and Linkset Failures As in the case of a single STP failure, the failure of a single link or linkset should have no severe impact on signaling traffic since the CCSN is engineered to self manage. It is only when coupled with other conditions in the CCSN that there would be an im

33、pact. The impact could range from complete SEP isolation (no messages to or from an SEP) to a condition where some individual SEPs cannot send and receive messages to or from other individual SEPs. Conditions which could impact an SEPs ability to send and receive signaling messages include the follo

34、wing: Failure of an SEPs combined linkset to communicate with the mated STPs due to one or a combination of causes: SEP hardware SEP software facility failure facility failure and no physical route diversity of links making up combined linkset Failure of a combination of linksets in the routing path

35、 to another SEP due to the same causes listed above. 2.3 Congestion The levels of congestion in the CCSN refer to the queued messages in the buffers associated with the network elements. There are four congestion levels (0, 1, 2 and 3) that are specified by the SS7 protocol. There are also four leve

36、ls of priorities for messages, such as Transaction Capabilities Application Part (TCAP) messages which are usually a priority one. These priorities are used in concert with levels of congestion. For example, a congestion level of two would indicate to all nodes coming into an STP not to send any mes

37、sages with priority less than two. A congestion level of three would advise not to send any messages with priority less than three. Since maintenance messages are assigned a priority three, and the highest congestion level is three, maintenance messages would continue to flow (which is mandatory for

38、 the CCSN to function). The SS7 protocol is designed to throttle-back volumes of messages when experiencing congestion. In the event this process fails, the congestion may become unmanageable, resulting in internal STP congestion which can then cause links and linksets to fail. If this condition is

39、replicated in mated STPs, network outages may occur, isolating an office. 3 LINES OF DEFENSE Controlling the impact of network failures, particularly with common channel signaling, is an essential activity. The spread of certain type failures (e.g. STPs) is not only extensive, but rapid. TPs and TCs

40、 should carefully review the layout of their PSTN, with an overlay of their CCSN, and consider key lines of defense. There should be a realization that the impact of one network event can be boundless across network boundaries. It is not only widespread, but deep, in its effect. One TP event may not

41、 only impact a Local Access Transport Area (LATA), and all its offices, but also the inter-LATA traffic. Conversely, trouble in an TC network can affect one or more TP networks and possibly other TC networks. For these reasons, this Section reviews activities applicable to the 6 CCSN, including a di

42、scussion on Network Management in a CCSN environment and pre-plans for the PSTN. The following section divides traffic into unique categories with corresponding lines of defense and activities to be considered. 3.1 Traffic Categories and Considerations The transition from MF signaling to common chan

43、nel signaling demands a new awareness of the potentially widespread outages due to CCSN failures. The result can be total loss of service to a customer. This section categorizes traffic into groups whose vulnerabilities are similar and whose control activities may be unique. After each discussion re

44、garding outages affecting each category, there is a brief discussion on action considerations. NOTE: In the considerations that are addressed in the following sections, F-links are suggested as a possible alternative. It should be noted that requirements for F-links do not currently exist, but are b

45、eing reviewed. It should also be noted that with the advent of new services that may require the use of an SCP, F-links may not be a good long term investment in some scenarios. This is an individual assessment and should depend on the strategic directions of the interconnecting companies. 3.1.1 Int

46、raswitch (AP) During the failure types discussed in Section 2, calls outside the switch will not be completed, causing abnormal numbers of retries, in turn, congesting the switch and potentially disabling it. Network Traffic Management techniques, such as call-gapping, would be ineffective in this s

47、ituation, since dial tone is not selective, but responsive to any off-hook condition, and the dialed digits must still be entertained. Switch processing is not split between pre-disposition and final disposition, i.e., there is no capability to up-front drop any NXX code not resident in the switch a

48、nd only process resident codes. The capability to introduce an announcement (e.g., “only calls to the following NXX codes will be processed at this time“), before dial tone, is also not available. Consideration: The objective here is to alert the public in an effort to stop redialing calls that have

49、 no chance of being completed, hence avoiding switch congestion. There needs to be a review of requirements or techniques that can be implemented to prevent congesting the switch, so intraswitch traffic can still be executed. It should be noted that the introduction of Integrated Services Digital Network (ISDN) may reduce congestion since these calls would not require an analog, sequential, time-consuming process. Announcements before dial tone may be a practical solution for digital switches, although perhaps not for analog switches. It should be understood that the concern