BSS 高级维护

1. BSS高级维护

2. 目 录 • 序论 • 第一章 告警处理 • 一、告警格式与组成 • 二、告警处理流程 • 三、常见的十类BSS告警 • 四、注意要点 • 第二章 实际故障处理解析 • 一、TCU故障处理 • 二、BTS启动分析 • 三、BSC reset分析 • 四、快速故障定位、故障处理小窍门 • 第三章 典型操作精解 • 一、时钟校准 • 1、          BSC&RXCDR时钟校准 • 2、          MCU时钟校准 附录：常见告警的分类 • 附录

3. 内容提要 • 本部分内容综述GSM BSS子系统网络的维护技术，主要介绍网络维护应当具有的理念，提供维护过程中分析问题的一般思路，对常见告警的处理，实际故障解析等。还有常见操作精解和维护工作的建议等内容。通过本部分的学习读者将具有GSM BSS网络维护的一般知识，掌握BSS基站子系统基本维护技能，能够承担日常的网络维护工作。

4. 序 论

5. 维护工作的要旨——防患于未然 • 系统建设完成后，就转入系统维护工作。由于此时系统已经给终端用户提供服务，网络的任何故障均可能对终端用户产生影响，从而对运营商的形象产生影响。所以维护工作的要旨是防患于未然，将系统隐患尽早排除，不要使其成为系统故障而影响系统的性能。 • 预防性维护是我们的最佳选择，定期对任何一个基站进行严格的检测调整，保证系统及其附属外围设备正常工作，并将正常运行时的所有系统数据整理归档，以供日常维护参考。通过集中性预防维护，可以及时发现系统隐患并加以排除，最大限度地提高现行系统设备的利用率，增强系统设备的可靠性，从而减轻平时日常维护的压力。 • 由于各个方面的原因，诸如传输、不同厂家设备配合、各个厂家硬件的稳定性、软件、气候、环境等，使得系统会出现一些不可预知的问题。如何解决此类问题，尽快恢复系统工作，是我们需要学习的技术。这也是本资料所要讲述的内容。

6. 维护工作的最高境界：防患于未然 • 不断学习系统知识 • 掌握必要的维护技术 • 日常巡检 • 集中性预防维护 • 系统会出现不可预知问题的原因 • 传输 • 不同厂家设备配合 • 各个厂家硬件的稳定性 • 软件 • 气候 • 环境

7. 分析问题的一般思路 • 遇到问题时，保持清醒的头脑，认真仔细地分析问题，作好必要的检查，收集相关数据。最大限度地掌握材料对于我们迅速准确地判断问题是很有帮助的。 • 首先我们要分清问题是局部问题,还是系统问题。是单个载频的问题还是整个CELL下所有载频的问题；是一个CELL的问题还是整个BTS基站的问题；是一个基站的问题还是整个BSC的问题；是一个BSC的问题还是MSC下所有BSC的问题。通过初步的故障定位，进行初步的处理与测试，缩小故障范围，如此循环，直到找到最终的故障原因。 • 其次我们要通过各种方法，寻找问题可能具有的规律。比如是否发生在特定的地点，特定的时间，具有周期性等等。这样就会迅速定位故障。 • 通过检查系统状态，进行路测，客户访问，故障反馈登记，问题分类等等。及时、准确地记录发生的事件，使得后续的工程师能够尽快地进入工作。 • 在检查系统状态时，应当作好LOG文件，即利用所使用的终端通讯软件，将数据记录成文件保存，以便上级技术支持工程师能够根据这些数据来分析问题。

8. 总 则 • 保持冷静，迅速作出反应 • 组织人力进行必要的检查、测试 • 分清是系统问题还是局部问题 • 逐步缩小故障范围 • 作好LOG，注意保存数据

9. 第一章 告警处理

10. 机房运行维护人员经常会碰到告警，有些告警是操作维护过程中自然产生的，有些告警是瞬时性的，不会影响系统正常运行，但大多数告警是会影响系统性能的，有的甚至会导致BSS复位，对移动通信系统造成严重影响。因此对于运维人员来说，了解告警系统，掌握一定的告警分析和处理技能，显得非常重要。本章正是从这个角度出发，介绍移动系统产品的告警系统和告警格式，并详细分析了常见的十类BSS告警。我们希望通过告警分析，能够帮助运维人员提高分析处理告警的能力。机房运行维护人员经常会碰到告警，有些告警是操作维护过程中自然产生的，有些告警是瞬时性的，不会影响系统正常运行，但大多数告警是会影响系统性能的，有的甚至会导致BSS复位，对移动通信系统造成严重影响。因此对于运维人员来说，了解告警系统，掌握一定的告警分析和处理技能，显得非常重要。本章正是从这个角度出发，介绍移动系统产品的告警系统和告警格式，并详细分析了常见的十类BSS告警。我们希望通过告警分析，能够帮助运维人员提高分析处理告警的能力。

11. 本章包括两部分主要内容，前一部分介绍了产品的告警系统和告警格式，后一部分深入分析了常见的十类BSS告警。本章还给出了在处理告警时一些需要注意的东西。本章包括两部分主要内容，前一部分介绍了产品的告警系统和告警格式，后一部分深入分析了常见的十类BSS告警。本章还给出了在处理告警时一些需要注意的东西。 • 告警可以使我们监控系统的运行状况 • 分析告警的不同级别 • 重视严重的告警 • 学习告警处理方法 • 告警的格式

12. 一、 告警格式与组成 • 告警系统是为了故障定位，系统性能分析及方便维护而设置的。 • 告警信息可以在OMCR的告警窗口上显示，也可以在本地维护终端（LMT）上显示。BSS产生的告警信息，以字符的形式发往OMCR。也可以通过命令设置使告警显示在LMT上(各县所用软件为cindy)。

13. 1、告警的种类和格式 • 告警可以分为硬件告警和软件告警两种： • 硬件告警是由于BSS内的硬件故障所引起的告警。 • 软件告警是由GPROC检测到软件进程运行出错所引起的告警。 • 只有GPROC设备（BSP，CSFP，DHP，BTP，pool GPROC）才会产生软件告警信息。软件告警（Software Fault Management或SWFM）分为两类。

14. 告警举例 #0 – NEW –*NONE*. CommuncationFailureEvent- CAGE - BSS01(BSS01:SITE-0:): 0 CAGE 1 - 30/03/1999 14:23:56. [18] Expansion KSWX Slot 22 Communication Failure - FMIC - Major - -/-. (BSS01:SITE-0:):0 SITE Impacted to Major.

15. #0：告警ID • NEW：告警状态 • NONE：正在处理此告警的人员 • CommuncationFailureEvent：告警的类型 • CAGE：告警级 • BSS01(BSS01:SITE-0:): 0 CAGE 1：发生告警的位置 30/03/1999 14:23:56：告警发生时间 • [18]：告警编号 • Expansion KSWX Slot 22 (见框架配置表)Communication Failure：告警描述 • FMIC：告警的清除类型 • Major：告警严重等级(主要告警)_ • (BSS01:SITE-0:): 0 SITE Impacted to Major:告警附加信息

17. 2、告警编号和消除类型 告警编号对于每种设备都有唯一的一个十进制数表示。每种设备的告警编号从0到254。(见附录)对于不同的设备告警编号可能重复，但与设备相关的编号是唯一的。有些情况下同样的告警编号表示类似的告警。 例如242号告警表示设备退出服务(MMS\MTL\RSL)。

18. 告警的清除类型可分为三类： • Intermittent • Fault Management Initiated Clear（FMIC） • Operator Initiated Clear（OIC） • Intermittent表示告警是偶发性的，对系统没有危害。此告警发生后在OMCR会自动消除。当此类告警频繁产生时，会增加OML链路的负荷。我们可以使用disp_throttle命令来查看告警门限设置，还可用chg_throttle命令调节其门限值。 • FMIC告警的清除由系统的错误管理进程（Fault Managerment Process）自动进行。FM进程管理一张现有告警的列表，只有当告警产生的原因消失后FM才会产生‘clear’消息将此告警从告警列表中删除。 • OIC需要由操作人员手动将告警清除。FM进程检测到告警产生并判断为OIC类型时，将此告警加入现有告警列表中。此后FM不再进行任何处理。当操作人员将告警产生的原因解决后，必须将此告警清除。

19. 清除告警步骤 • 在OMCR和BSC上均能够清除告警。OMCR上清除告警按以下步骤进行： • 打开告警窗口，单击鼠标左键选中要清除的告警项 • 单击鼠标右键弹出快捷菜单 • 选择快捷菜单的“Handle” • 选择快捷菜单的“Clear” • 确认告警已被清除 • 在BSS上清除告警，先使用disp_act_alarm命令查看有哪些OIC告警。然后使用del_act_alarm命令将告警清除。清除命令如下: • del_act_alarm <location> <device_name> <dev_id1> <dev_id2> <dev_id3> <alarm_code> (只对OIC告警)

20. 3、告警的类型 OMCR将告警分成六种不同的类型，可以在OMCR的告警说明中找到"FailureEvents" 字段，其为不同类型告警的名称。

21. 类型 含义 举例 Communication 数据从一点传到另一点时发生错误而产生的告警 一般当信令丢失或呼叫建立出错时发生此种告警1、mms syn loss 2、frame slip daily 3、bit error 4、dri-ctu activelinkcommunication failure(critical) Quality of Service 系统的服务质量下降时产生此告警 一般当消息响应超时或带宽减少时会发生此种告警：多见于时钟失锁gclk_mcuf phase lock failure（major） Processing 当软件或进程出现错误时产生此告警 一般当进程数据被破坏或系统内存溢出时产生此种告警dri-CTU channelcoder internal messageerror—intermittent(warning) Equipment 当硬件出错时产生此告警。 一般当出现配置错误，传输、电源等问题时产生此种告警dri standby link communication failure(minor) Environment 当设备所处的环境不利于正常工作时产生告警 一般当出现烟雾，火光被检测到时产生此种告警 Link 当OMCR与BSS间的X.25链路出现问题时产生此告警

22. 影响 行动 举例 严重 (Critical) 已经影响了系统的服务 应该立即采取措施 当系统的某一功能出现此种告警而退出服务，应立即将其恢复。 重大 (Major) 已经影响了系统的服务 应该马上采取措施 系统的服务容量降低，此时应采取措施恢复容量。 较轻 (Minor) 此错误不会对系统的服务造成影响 应采取措施减少更多的此类告警产生 当此种告警数量不断增加时，系统的容量可能受到影响。 警告 (Waring) 潜在产生影响系统服务的告警的可能 如果必要应该进行必要的分析，采取措施避免产生更严重的告警 清除 (Clear) 告警已经被清除 无 待定 (Investigate) 表明此错误的等级无法确定，需要人工进一步分析 进一步查找原因 4、告警的等级 告警严重级别表明此故障发生对系统的影响程度。系统将告警的等级分为6级。

23. 告警的等级可以查看也可以根据要求改变。使用以下两条命令可以查看和改变告警的等级，命令如下：告警的等级可以查看也可以根据要求改变。使用以下两条命令可以查看和改变告警的等级，命令如下： • 查看等级disp_severity <device_name> <alarm_code> • 改变等级chg_severity <device_name> <alarm_code> <severity> 例如： • MMI-RAM0115> disp_severity DRI 12 系统显示：DRI Alarm Code 12 severity: WARNING • MMI-RAM0115>chg_severity DRI 12 major 系统显示：COMMAND ACCEPTED

24. 二、告警处理流程 • 有关告警的窗口不论是打开还是处于最小化，当有新的告警产生时，都会自动添加在告警的窗口中。在OMCR上可以用多种方法查看告警。 • 第一种方法：OMCR桌面图形界面GUI上的ALARM按钮 在OMCR桌面图形界面GUI上双击告警按钮，打开告警窗口，可以看到所有网元（NE）的告警信息； • 第二种方法：通过GUI上的EVENT MANEGMENT 点击GUI上的EVENT MAMT按钮，打开Display Subscription List窗口，选择窗口中告警中的一项，选择open按钮就打开告警窗口； • 第三种方法：打开MAP图，然后选中对应的单元节点 从NETWORK MAP上查看告警，单击GUI上的NETWORK MAP按钮，打开MAP LIST窗口，选定其中的一个网元，双击鼠标左键打开MAP窗口，在MAP图上用鼠标左键点击要查看的网络单元节点，选中后接点会变为紫色，单击鼠标右键在快捷菜单内选择ALARM项，此时会出现告警窗口显示此节点单元的所有告警。 • 用disp_act_alarm 命令行查看告警（县cindy软件）。

25. 打开告警窗口之后，查看告警的状态项，新产生的告警状态项为NEW，操作者为NONE。新告警被选中后会改变颜色，比如：Critical告警的告警字为红色，背景为白色，对于其它种类告警的告警字为黑色，背景为白色，并且告警的状态项变为SEEN，表明有工程师已经阅读了该项告警。如果人工clear后,告警字变绿,背景为白色. • 告警窗口中状态项为“NEW”的告警是新产生需要处理的告警。

26. 2、告警处理优先级别 • 我们可以根据告警的严重级别，以及出现告警的网元在系统中的重要性，对不同的告警情况进行相应的处理。在此我们提供一般原则下的优先级别。对于基站来说从RXCDR到BSC，再到BTS；信令链路按照MTL、RSL、XBL的次序；告警严重级别由高到低分别是Critical、 Major、 Minor、 Warning、 Investigate、Clear。在相同的告警级别中，Critical告警按照以下顺序All RXCDR-All MTL -All BSC-All RSL-All BTS-All X.25 link-All other Critical alarms。Major 告警按照以下顺序All RXCDR-All BSC-All BTS-All other Major alarms。其它告警按照Minor、Warning 、Investigate、Clear alarms的顺序进行处理。

27. The sites Remote Transcoder (RXCDR) Base Station Controller (BSC) Base Transceiver Station (BTS) The links Message Transfer part Link (MTL) Radio Signalling Link (RSL) X.25 link Critical告警按照以下顺序： All RXCDR - Critical alarms All MTL - Critical alarms All BSC - Critical alarms All RSL - Critical alarms All BTS - Critical alarms All X.25 link - Critical alarms All other Critical alarms 告警处理的优先级别

28. Device 1st parent dev 2nd parent dev 3rdparent dev 4thparent dev RSL MMS MSI CAGE CAB SITE BSS MTL MMS MSI CAGE CAB SITE BSS OML MMS MSI TCU DRI CAB SITE BSS XBL MMS MSI CAGE CAB SITE BSS • 当某个设备或链路处于OOS等非正常状态时，不仅与起本身相关，而且与其上一级（parent）设备有关，对parent设备进行进行必要的处理是解决问题的重要手段。如果某个设备处于OOS等状态下，此设备下一级（child）设备不能正常工作。在此我们给出常见的设备之间的从属关系（parent-child）：

29. 总 则 • 查看告警 • 分清告警的级别 • 明确与告警有关的设备 • 根据告警手册或经验对告警进行处理 • 解决问题，消除告警

30. 三、常见的十类BSS告警 • 某些的告警只在特定的告警条件下才会发生，有些告警发生得多一些，比较普遍。我们无法把所有的告警都进行详细的分析，并且这也没有必要。这里我们根据掌握的资料和经验，列举了经常碰到并具普遍意义的十类BSS告警，通过这些告警的分析，希望能够拓宽工程师的思路，帮助帮助提高处理告警、排除故障的能力。我们在本文的附录中列举了其它告警的扼要信息，供工程师查考。

31. 1、OML为E-U或D-U的问题 • 在BSC或RXCDR看到此现象时，还可能看到相关的一些告警，如OML 242号告警等。 • 背景原理： OML链路是OMCR到RXCDR或BSC的信令链路，主要用于BSS的操作维护。OML使用X.25协议。OMCR通过Router与BSS相连，在BSS端，操作数据在2M线的某些时隙中传输，到达Router后，Router中的虚拟交换电路把它们分门别类送往OMCR进行处理。同时OMCR的数据也通过Router交换后发往相应的NE。

32. 可能引起此类告警的原因： • ①相关的MMS口退出服务 • ②主用MSI板没有插 • ③数据库中关于OML链路的定义不对 • ④DTE地址定义不对 • ⑤路由器定义不对 • ⑥软件进程问题

33. 解决思路： 如果OML链路从来没有起来过，那么首先应该检查硬件连接是否正确，特别是主用的MSI板是否插上了，因为主用MSI板上定义了NE起来时用于从OMCR下载软件和数据库的OML链路。然后核对DTE地址及路由器的设置是否正确。 如果OML链路以前是好的，那么首先要搞清是否有人对OML相关的参数改动过，如数据库中关于OML链路的定义、DTE地址、路由器设置等。在确认没有改动过后，应检查硬件问题，如MMS口是否退服、MSI板是否故障等（根据菊花链、拓扑图）。硬件也没有问题时，可初步确定为软件进程问题，可以设置一些Filter收集进程数据，并对相关的几个进程作一些操作（如重启进程）来恢复OML链路(注意:在OMC上,如果不能确认另一条(OML1)是正常的(E-U NO REASON),一定不能LOCK在用的OML0(B-U NO REASON)。

34. BSC533拓扑图

35. 菊花链

36. 参考操作步骤： OML链路的问题涉及的设备比较多，例如：OMCR，路由器，RXCDR等，为了正确定位故障应结合数据收集来处理问题。 ⑴进入BSC键入state 0 ,disp_p 0命令查看BSC的状态以及带OML的GPROC板状态，如GPROC板坏,则更换 (bsc:gproc 0 0 slot18;rxcdr:bsp 0 0 slot25)； (2)state 0 oml * *，看OML的状态； (3)根据菊花链或disp­_link(rxcdr)查找相关连接 (4)在rxcdr上用state 0 mms * *及state 0 msi * *查相关MSI板,如为硬件故障,则更换MSI板; (5)在bsc上disp_conn查bsc与rxcdr相关连接,找故障范围; (6)disp_eq 0 oml 0 0查看OML所属的MMS，查看OML的状态; (7)根据mms查看MSI板状态；如为硬件故障,则更换MSI板; (8)根据相关连接查是否为传输物理路由故障; (9)如果物理路由正常,检查相关数据或路由器。

37. 2、GCLK无法锁相的问题 • GCLK无法锁相时会产生GCLK Failed Phase Lock的提示，并可能伴随出现4、14、13号等告警。 • 背景原理： GLCK 的功能是使得系统与更准确的时钟同步，对于BSS来说，GCLK要与MSC的时钟同步。时钟同步的目的是在射频部分提供0.05ppm（ppm为百万分之一。即如时钟为16.384M，则频率误差为16.384×0.05 =  0.8192Hz ）的高精度的时间同步。因此要提供参考时钟的E1/T1链路要尽量减少滑帧和失同步。 GCLK要与上一级时钟同步必须要有上一级时钟的参考信号，时钟参考信号是根据数据库的定义从指定的MMS口上提取的。在database中需要定义不同MMS口的时钟提取优先等级（可在设备上用state 0 mms * *查看时钟提取的MMS口，再根据msi拓扑图查看物理路由）。

38. GCLK在工作时有四种不同的状态： • ①自由振荡状态：此状态是当GCLK刚上电时，其内部的晶体振荡器（OCXO）需要有预热的过程，以保持其正常的工作环境。此时间是固定不变的（30分钟），无法更改。在自由振荡状态下，时钟输出保持在0.05ppm的精度内。 • ②Hold Frequency：此状态是GLCK与2M失锁时的状态。此时GCLK使用前一次ADC输出的值输入DAC以控制时钟，此状态是一个过渡状态，一般持续10秒。

39. ③Set Frequency：此状态一般在Hold Frequency之后。使用LTA（Long Term Average）值输入DAC以控制时钟。 正常锁相工作时GCLK每30分钟采样一个输出值存入内部存储器，存储器最大可以存放48个值，采用先入先出原则更新。所谓LTA就是指将这48个值取平均输入到DAC。Set Frequency状态下，GCLK不再往存储器中存放新值，只是使用以前的旧值，存储器停止更新，这是与锁相状态的不同之处。 • ④锁相状态：此状态分为两个子状态， • Acquiring Frequency Lock State，此状态是一个过渡状态，由硬件决定。 • Frequency Lock State，此状态内GCLK已与E1/T1锁相，但需等待一段时间，以确定锁相稳定之后就进入锁相状态。

40. GCLK要与E1/T1同步必须有合适的时钟提取端口，这些端口的优先级按以下原则确定：GCLK要与E1/T1同步必须有合适的时钟提取端口，这些端口的优先级按以下原则确定： • ①MMS是否为B-U • ②MMS的等级（在database中定义） • ③在一定时间内MMS处于OOS状态的次数 • ④如果以上都相同，则轮流作为时钟源

41. 除了MMS口的等级外，在DATABASE中还有一些参数与GCLK有关：除了MMS口的等级外，在DATABASE中还有一些参数与GCLK有关： • 设置是否允许时钟同步 chg_el phase_lock_gclk <*> <site> <*> 0 Disable phase locking、1 Enable phase locking • 设置时钟同步端口切换时间 chg_el wait_for_reselection <element_value> <location> <element_value> 1 to 255（缺省值为10） 如果2Moos,而在10s内又恢复,则仍做为时钟源 • 设置时钟同步端口优先级 modify_value<site>mms_priority<*>mms <mms_id1><mms_id2><*>0 to 255 255: 优先级最高,同步于，0:不被选 1: 优先级最低 • 设置LTA告警门限 chg_el lta_alarm_range<element_value> <location><element_value> 1 to 255（缺省值为7） 每30分钟对gclk进行一次轮询当前48个值(8bit)与以前48个的平均值相比,有25%超出范围+_10,则产生gclk告警 • GCLK尝试重新锁相 reattempt_pl <location> <gclk_id1>

42. 可能引起此类告警的原因： • ①因传输问题引起MMS退服 • ②MSI板或MMS口硬件故障 • ③数据库定义不合理 • ④GCLK本身的问题，需要校正或更换

43. 解决思路： 当出现GCLK无法锁相的告警时首先要搞清楚参考时钟是从哪里来的。 检查一下数据库中有关GCLK的参数设置是否合理，如锁相应向上锁，即RXCDR向MSC锁、BSC向RXCDR锁、BTS向BSC或上一级的BTS（只有菊花链的情况）锁，向下一端的MSI口的时钟提取优先级应设为0。另外也不能只允许一个MMS口可以提取时钟。 如果数据库设置没有明显不合理之处，应注意一下与时钟提取有关的MMS口和MSI板的状态，MMS口退服可能是传输问题引起的，也可能是MSI板或MMS口硬件故障引起的。如果MSI板工作正常则应着重检查传输质量。 在排除了数据库、MSI硬件和传输原因之后，应校正或更换GCLK板。

44. 参考操作步骤： • ⑴为了利于问题的分析应收集以下数据(为今后分析提供依据)： • ①state <location> gclk * * （查看GCLK的状态） • ②disp_el phase_lock_gclk <location> （查看是否允许锁相） • ③disp_eq 0 mms <id 1><id 2><id 3> （查看MMS的参数，主要是时钟提取优先级） • ④disp_el wait_for_reselection <location> （查看时钟提取切换时间） • ⑤disp_el lta_alarm_range <location> （查看LTA告警范围） • ⑥disp_eq <location> gclk <id_1><id_2><id_3> full（查看GCLK硬件版本信息）

45. ⑵当GCLK无法锁相时可采用以下的方法： • ①reattempt_pl <location> <gclk_id1> • ②使用lock/unlock命令（在上BSC倒换GCLK）看是否能使得GCLK锁相恢复。 • ③查看MSI，MMS是否处于正常状态，是否有E1的相关告警产生，是否有MMS作为时钟源。 • ④查看提供时钟的MMS是否与上一级的链路连接，上一级的时钟是否正常工作。 • ⑤查看提供时钟的MMS的等级是否设置正确（一般为255）。 • ⑥试着使用其它的MMS作为时钟源。（对于M-CELL可更换NIU）。 • ⑦重新校准GCLK的时钟，或更换时钟板，具体校准的过程可见手册（68P02901W43，第二章为GCLK调测，第三章为MCU时钟调测，第四章为MCUm的时钟调测）。 • ⑧如果出现无法校准，备用端的GCLK也不能用，并且没有备件。用仪表检查上行和下行链路的时钟，看是否为2.048M。可使用hp37717C 分析仪。以确定是那一端出现问题。

46. 3、MMS告警和退出服务 （MTL XBL CIC OML PATH RSL） • 背景原理： 在MOTORLOA系统中除了硬件问题有四种与传输相关的情况会导致MMS告警或退出服务。 • BER（Bit Error Rate） 误码率 • Sync loss 同步丢失 • Remote alarm 对端失同步告警 • Frame slip 滑码

47. ①BER（Bit Error Rate）误码率 MMS通过监测0时隙的固定位来计算误码率，ber_loss_daily和ber_loss_hourly分别定义了24小时和1小时误码率的门限值，误码率超出门限值时，就会产生误码率告警。ber_oos_mon_period定义了误码率监测时间长度，在这个时间长度内误码率超过1‰（由MMS硬件决定），MMS将要退出服务。

48. ②Sync loss 同步丢失 MMS通过检测同步位来与对端同步，当同步位出错时，算失同步一次。失同步时间超过sync_time_oos设定的值时，MMS将退出服务。重新同步后，时间超过sync_time_restore设定的值后，MMS重新进入服务。当24小时和1小时内的失同步次数分别超出sync_loss_daily和sync_loss_hourly定义的值时，MMS会产生sync_loss告警。此外24小时内失同步的次数超出sync_loss_oos定义的值时，MMS也会退出服务，同样恢复正常后时间超过sync_loss_restore定义的时间，MMS重新进入服务。

49. ③Remote alarm 对端失同步告警 对端MMS失同步后，会回送一个失同步标志。MMS检测到此标志后开始计时，对端失同步时间超过remote_time_oos定义的时间，MMS就退出服务。对端失同步恢复后，超过remote_time_restore定义的时间，MMS就重新进入服务。24小时和1小时内对端失同步的次数分别超出remote_loss_daily和remote_loss_hourly定义的值时，MMS会产生remote_alarm告警。24小时内对端失同步次数超出remote_loss_oos设定的值时，MMS也会退出服务，对端恢复后超出remote_loss_restore定义的时间，MMS就重新进入服务。

50. ④Frame slip 滑码 24小时和1小时内滑码的次数分别超出slip_loss_daily和slip_loss_hourly定义的值时，MMS会产生frame_slip告警。24小时内滑码次数超出slip_loss_oos设定的值时，MMS会退出服务，滑码恢复后超出slip_loss_restore定义的时间，MMS就重新进入服务。 Daily –Waring：表示在24小时内告警门限超出，一般在此告警之前就会有其它更敏感的告警产生。此告警不会对系统的服务产生影响。 Hourly - minor alarm ：表示在1小时内有大量的问题产生。链路的性能降低，对系统的服务可能会产生影响。 OOS - Critical alarm：MMS退出服务。