欢迎来到麦多课文档分享! | 帮助中心 海量文档,免费浏览,给你所需,享你所想!
麦多课文档分享
全部分类
  • 标准规范>
  • 教学课件>
  • 考试资料>
  • 办公文档>
  • 学术论文>
  • 行业资料>
  • 易语言源码>
  • ImageVerifierCode 换一换
    首页 麦多课文档分享 > 资源分类 > PDF文档下载
    分享到微信 分享到微博 分享到QQ空间

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

    • 资源ID:540939       资源大小:135.09KB        全文页数:15页
    • 资源格式: PDF        下载积分:10000积分
    快捷下载 游客一键下载
    账号登录下载
    微信登录下载
    二维码
    微信扫一扫登录
    下载资源需要10000积分(如需开发票,请勿充值!)
    邮箱/手机:
    温馨提示:
    如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
    如需开发票,请勿充值!如填写123,账号就是123,密码也是123。
    支付方式: 支付宝扫码支付    微信扫码支付   
    验证码:   换一换

    加入VIP,交流精品资源
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    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


    注意事项

    本文(ATIS 0300027-2011 Next Generation Interconnection Interoperability (NGIIF) Reference Document Part VI Network Management Guidelines Attachment A Emergency SS7 Restoration Operation.pdf)为本站会员(deputyduring120)主动上传,麦多课文档分享仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文档分享(点击联系客服),我们立即给予删除!




    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
    备案/许可证编号:苏ICP备17064731号-1 

    收起
    展开