案例02-基站漏配MME地址导致主叫未接通问题分析

案例-基站漏配MME地址导致主叫起呼收到ServiceReject产生未接通

问题描述:

15:14:58.112主叫占用LTE邳州人民公园F_1(38400,324),RSRP=-85 起呼后,立即收到核心网下发的Service Reject消息,随后主叫终端重选至3G发起呼叫,呼叫建立成功。

问题原因:

1、IMS分析

SBC在该时间段无消息,需要EPC看看为何发送service reject

2、EPC分析

EPC在15:13:51通知eNode B MME发生切换:

但是eNode B在15:14:55的时候还是往老的MME发送service request:

此时由于老的MME已经没有了用户的上下文会话信息,因此给eNodeB回了service reject,原因值=implicitly-detached。

3、eNodeB侧分析

基于问题:为什么eNode B在MME发生切换时,还往老的MME发service request

排查基站侧数据发现:MME POOL改造时LTE邳州民主路2西【调整】断站导致少加了到MME07的数据,因此才会发生eNode B切换时导致MME切换异常:

影响范围:

LTE邳州民主路2西【调整】漏配MME07地址,导致切换异常。11月23日整改后复测正常,该问题解决。

解决方案:

基站故障处理流程规范

基站故障处理流程规范 1.概述 1.1 编制背景 为进一步规范移动基站处理流程,及时处理基站发生的故障,保证基站故障设备能够在最短时间得以恢复及对网络指标的影响降到最低,特制定基站故障抢修指导手册,以便基站维护人员发现、处理、分析故障问题提供参考。 1.2 编制单位 中国移动通信集团江西有限公司鹰潭分公司网络部 1.3 指标要求 按照基站维护服务技术规范书的要求,基站维护人员在接到设备障碍通知后,应及时到现场处理。 1.4 处理原则 1.维护人员应按“先室内,后室外,先软件,后硬件”的原则进行故障处理 工作,即在排除电力、光缆中断的因素后,再进入基站处理故障,在排除 软件吊死、数据丢失等软件原因后,再对调、更换硬件。 2.在充分了解故障信息的情况下,尽量缩短故障处理时长,更换需更换且 仅需更换的板件。因此,接到故障通知后,应根据通知内容对故障进行 预判断,以便采取针对性的处理措施,定位真正的故障点,避免错误信 息误导,延长故障恢复时间。 3.维护人员在故障处理过程中,需协调其它部门或单位解决问题时,应立 即展开协调并向上级报告相关进展情况。 4. 对载频,主控板,传输板等故障处理应禁止在网络指标考核 (8:00-11:00,18:00-20:00)时段进行处理

2. 故障处理流程

3. 基站故障分类及参考处理步骤 3.1基站载频退服 步骤1:先要求机房查看载频信令是否激活,即是否处于WO状态。如果载频信令没办法激活或已激活,整个BCF也已重启,但载频依然退服,则带上对应型号的载频。 步骤2:到站后,若扇区没开跳频,则闭掉一块正常工作的载频,将故障板件和它对调。若扇区开了跳频,则先叫机房闭站。 步骤3:对调后,重新集成,观察载频是否能正常工作,如果故障随着载频走,则用新板更换故障载频;如果故障依然存在原位置,则可能与载频硬件无关,需重新定位故障点。 步骤4:故障恢复后,处理板卡标签和固定资产变动,签好出入登记本以及故障处理记录,离开基站。 3.2基站因停电退服 步骤1:维护人员接到停电通知后,首先需询问当地电力公司,看该基站附近是否在做电力抢修,如果电力公司确定是在做电力抢修,详细了解将停电时长及恢复供电时间。 步骤2:在得到确切的时间后,根据基站固定资源调查表,或平时巡检表的信息,判断电池组的持续供电时间,如果电业局确定能恢复供电的时间很短,远小于电池组的安全供电时间,则不必带油机前往基站发电,但需每隔1小时跟踪一次供电恢复情况。如果电池组不能或勉强能撑到交流供电恢复时间,则需立即带上小油机去站上发电。 步骤3:根据基站的配置选定功率匹配并已经过检测完好的油机和电缆线,备足燃油和工具(万用表、钳形表、电笔、绝缘胶布以及其他常用工具)及时到达市电故障的基站。 具体油机选定方法举例如下:某基站通信设备直流负荷为45A(空调、照明除外),配置 GFM400Ah/48V蓄电池2组,开关电源为48V电源,基站由三相交

华为基站故障处理实例

5.2.3华为基站故障处理实例 1. 天馈连接鸳鸯线导致扩容载频后话务量减小现象描述: 反映某 312 基站第二小区话务量减小,该站话务量减小是从扩容后,原来是一个载频,采用一个 CDU ,扩容后加了一块载频,同时将 CDU 更换为 EDU ,至此话务量急剧下降,连续 3 天话务量不足原来的 1/4 ,用户怀疑是覆盖范围减小。 告警信息:在告警台中观察不到任何关于该基站的告警,单板指示灯和运行状态均正常。 原因分析:由于用户增加了一块载频,该基站下的四块载频变为五块,但是 PSU 单板只用两块,所以初步分析可能由以下原因造成话务量减小: 1 ) PSU 单板不够用,由于每两块 TRX 需要一个 PSU ,所以有可能是这个原因所致; 2 )新更换的 EDU 有问题; 3 )扩容时连接跳线时接头没有连接牢靠,造成驻波比过大; 4 )小区的天馈连接错误。 处理过程:现场检查数据,没有任何问题,观察话统,发现的确从扩容后话务量就一直维持在 1ERL 左右,没有异常告警。到达现场后加入一块 PSU 板,通过话统对该小区进行测量报告数量的测量,发现很少,话务量没有提高,将 1 、 2 小区的 EDU 更换,现象依旧,仔细检查 TRX 和EDU 之间的连线,也没有错误,又检查天馈连线,发现第二小区的 EDU 的第二个发射端口 TX/RX_ANTB 错误的连接到第一小区天线的发端口,这样以来,第二小区的 BCCH 和 TCH 是通过不同的天线发出去的,造成可能指配信道所在的载频信号很弱,进而发生切换或掉话,切分集接收也不正确,所以造成该小区吸收不了话务量。将小区天线重新连接,二小区的话务量立刻提升了。 建议与总结:扩容,更换硬件时一定要信心连接线缆,避免连成鸳鸯线,交叉线,如果连接错误通常不会产生告警,故障比较隐蔽,同时会造成一些切换,掉话,话务量上不去的现象。 2. 数据配置不当导致 BTS3006A 在市电掉后出现非主 BCCH 载频退服 现象描述:某基站业务信道可用率突然下降,严重影响了考核指标。 告警信息:市电掉告警, PSU 保护,扩展 C3 。原因分析:由于 TCH 可用率 (%)= TCH 可用数目 / ( 1800/1900 小区 TCH 配置数目+ 900/850 小区 TCH 配置数目) 所以到局里采集 TCH 性能测量分析,发现有几个基站在 7 : 30 左右小区 TCH 可用数目比实际配置的数据少了 8 个,该基站配置为 S2/2 ,也就是少了一个载频的TCH 信道。

精品案例_SIP487的VoLTE未接通处理

SIP487的VoLTE未接通

目录 一、问题描述 (3) 二、分析过程 (4) 三、解决措施 (7) 四、经验总结 (8)

SIP487的VoLTE未接通 【摘要】本文分析于4月24日出现的VoLTE未接通的工单,发现18:30到19:00期间RCU1197设备产生大量未接通,对数据进行详细分析为设备吊死导致。 【关键字】VoLTE 未接通 SIP 吊死 【业务类别】优化方法 一、问题描述 问题发生过程中,终端由宁芜高速向南京行驶,行驶到南京境内后再由宁芜高速返回马鞍山,RCU1197设备4月24日18:30至19:00产生大量未接通事件,且未接通为全程存在。 图1:未接通事件截图

二、分析过程 图2:18:31:28起呼的未接通情况 核查相关基站,基站无告警和故障,底噪正常,负荷水平也较低,查询扇区性能指标,无线接通率和掉话率正常,无明显波动和异常。 图 图3:未接通占用扇区性能指标情况 问题数据未接通事件较多,选取18:31:28起呼的未接通事件进行分析。18:31:28.230进行起呼,占用MA-市区-昭明派出所-ZFTA-443830-51,RSRP-97dBm,SINR在10dB,信号良好。

图4:VoLTE信令流程 图5:18:31:28未接通的事件和信令详情 对呼叫流程和信令进行详细分析,18:31:28.230发起起呼后,18:31:38.351发起IMS_SIP_INVITE->Request,18:31:38.398收到Try100信令,随后在18:31:48.136收到INVITE 183消息,并在18:31:48.202上报PRACK,在18:31:48.234收到PACK200,。然后在18:31:58.198上报SIP_CANCEL信令,上报原因为IMS_SIP_INVITE 487。

中兴基站设备故障处理指导书

中兴基站设备故障处理指导书 V 1.0 网优中心系统分析部 2010年2月

版本说明

目录 前言 (5) 告警级别说明 (5) 紧急告警 (6) 硬件狗或LICENSE文件非法。 (6) 主要告警 (6) 未探测到CCM/BDM/CBM。 (6) PWRD485通信链路断。 (7) BTS掉站。 (7) 一次电源电池充电压过高。 (7) 一次电源电压过低。 (7) GPS处于搜星状态。 (8) GPS天馈开路。 (8) GPS卫星丢失。 (9) E1底层误码率高。 (9) PPP_UID链路中断。 (9) 第一条中继线错误。 (10) 检测到A BIS口E1连接变化。 (11) 温度告警。 (11) 机房烟雾告警。 (12) 次要告警 (12) PPM板异常或不在位。 (12) PSMB的+5V无输出告警。 (13) PSMB异常或不在位。 (13) PSMC异常或不在位。 (13) PSMD板异常或不在位。 (13) SAM板上DC-DC电源模块无输出告警。 (14) PPP链路HDLC故障。 (14) PPP链路故障。 (14) 中继线不可用。 (14) 背板拨码开关被改变。 (15) 未探测到CHM。 (16) 未探测到PA。 (16) 未探测到RFE。 (16) 未探测到TRX。 (17) 无法探测到GCM。 (17) CCM检测到GPS状态异常告警。 (17) CSM自检未通过。 (18) RFCM数据链路告警。 (18) RFIM数据链路告警。 (19) 未探测到RTR。 (19)

PA关断。 (19) PA去使能。 (20) 低功率告警。 (20) TRX反向链路RSSI低告警。 (21) 反向RSSI偏高。 (21) 未探测到FCE。 (22) 风扇故障告警。 (22) 湿度传感器没有安装或已经损坏告警。 (22) 湿度告警。 (23) 防雷器告警。 (23) 提示告警 (23) GPS长时间预热。 (23) GPS天馈故障。 (24) 时钟模块处于预热状态。 (24) 网元中单板已插,但OMC未配置。 (24) 未探测到SAM。 (24) 中继告警指示信号。 (25) HDLC通道不可用。 (25) 中继信号丢失。 (25) RFCM自动定标失败告警。 (26) TRX射频频综异常。 (26) RFE接收链路LNA过欠流。 (26) RFE低功率告警。 (26) 过去15分钟中继链路误码水平超过阈值。 (27)

基站故障处理流程规范

基站故障处理流程规范 IMB standardization office【IMB 5AB- IMBK 08- IMB 2C】

基站故障处理流程规范 1.概述 编制背景 为进一步规范移动基站处理流程,及时处理基站发生的故障,保证基站故障设备能够在最短时间得以恢复及对网络指标的影响降到最低,特制定基站故障抢修指导手册,以便基站维护人员发现、处理、分析故障问题提供参考。 编制单位 中国移动通信集团江西有限公司鹰潭分公司网络部 指标要求 按照基站维护服务技术规范书的要求,基站维护人员在接到设备障碍通知后,应及时到现场处理。 处理原则 1.维护人员应按“先室内,后室外,先软件,后硬件”的原则进行故障处理工作,即在排除 电力、光缆中断的因素后,再进入基站处理故障,在排除软件吊死、数据丢失等 软件原因后,再对调、更换硬件。 2.在充分了解故障信息的情况下,尽量缩短故障处理时长,更换需更换且仅需更换的 板件。因此,接到故障通知后,应根据通知内容对故障进行预判断,以便采取针 对性的处理措施,定位真正的故障点,避免错误信息误导,延长故障恢复时间。 3.维护人员在故障处理过程中,需协调其它部门或单位解决问题时,应立即展开协调 并向上级报告相关进展情况。

4.对载频,主控板,传输板等故障处理应禁止在网络指标考核(8:00-11:00,18:00- 20:00)时段进行处理 2.故障处理流程 3.基站故障分类及参考处理步骤 基站载频退服 步骤1:先要求机房查看载频信令是否激活,即是否处于WO状态。如果载频信令没办法激活或已激活,整个BCF也已重启,但载频依然退服,则带上对应型号的载频。 步骤2:到站后,若扇区没开跳频,则闭掉一块正常工作的载频,将故障板件和它对调。若扇区开了跳频,则先叫机房闭站。 步骤3:对调后,重新集成,观察载频是否能正常工作,如果故障随着载频走,则用新板更换故障载频;如果故障依然存在原位置,则可能与载频硬件无关,需重新定位故障点。 步骤4:故障恢复后,处理板卡标签和固定资产变动,签好出入登记本以及故障处理记录,离开基站。 基站因停电退服 步骤1:维护人员接到停电通知后,首先需询问当地电力公司,看该基站附近是否在做电力抢修,如果电力公司确定是在做电力抢修,详细了解将停电时长及恢复供电时间。 步骤2:在得到确切的时间后,根据基站固定资源调查表,或平时巡检表的信息,判断电池组的持续供电时间,如果电业局确定能恢复供电的时间很短,远小于电池组的安全供电时间,则不必带油机前往基站发电,但需每隔1小时跟踪一次供电恢复情况。如果电池组不能或勉强能撑到交流供电恢复时间,则需立即带上小油机去站上发电。

VoLTE手机被叫未接通案例分析及处理

VoLTE手机被叫未接通案例分析 【摘要】VoLTE试商用时出现大概率被叫无法接通现象,通过现场测试排查和端到端信令分析,将问题锁定在核心网侧。省NOC根据故障报告进行排查,针对核心网TLDN 回落机制分析,最终确认核心侧TLDN数据配置不全。 【关键字】VoLTE 被叫TLDN 回落 背景:随着网络优化和VoLTE商用的推进,安徽电信内部开通VoLTE用户预商用,要求各分公司试用并进行网络质量分析和疑难问题反馈,协助省公司完成VoLTE商用指导。 【故障现象】: 省公司开通VoLTE测试卡后,概率性出现VoLTE测试卡作为被叫无法接通现象,未接通时主叫保持呼叫状态,被叫手机无响应,直至主叫手机提示“无声、空号、无法接通、未开通此项业务、增值业务被终止”等各种声音通话结束:

图1:测试被叫无响应 【告警信息】: 登录基站无告警,网元测试,基站与MME、SGW等网元连接正常: 图2:网元节点测试

【原因分析】: (一)终端排查 现场倒换终端进行测试验证,发现开通VoLTE功能终端在CS域做被叫出现大概率未接通,主叫正常: 表1:终端排查 (二)无线环境分析 CQT测试,选取RSRP:-60dbm、SINR:30db覆盖正常,无线环境良好的测试点进行测试,依然出现被叫CS域无法接通现象: 图3:无线环境 (三)信令对比分析

通过以上分析可以看出本次未接通与无线环境无关,只是VoLTE 功能终端在CS域被叫引起的未接通,计划通过CS域被叫正常通话和未接通信令对比来分析差异。 正常接通时:IMS域主叫发起INVITE Request后,2s∽5s左右被叫在C网收到寻呼消息,进而发起CSFB回落到C网通话,信令流程如下: 图4:正常呼叫 被叫CS域未接通时:信令来看IMS域主叫15:33:48发起INVITE Request请求,15:34:18发起呼叫取消,随后IMS下发呼叫取消确认,并下发INVITE 487呼叫终止,主被叫信令流程如下: 此时,发起呼叫到终止经过30s时间,主叫超时释放,造成未接通,信令如下:

基站常见电源故障处理手册

基站常见电源故障处理手册 电源系统作为基础网络,其正常工作是通信网络安全可靠运行的基础。基站作为通信网络的组成单元,其安全工作同样要求电源系统的正常运行作为支撑,尽管不同的基站系统配置不尽相同,但电源系统主要由交流配电、开关电源、蓄电池、空调和接地系统组成或者由其中的一部分组成。基站电源系统的常见故障也基本类同。现将基站电源的常见故障和处理方法进行归类说明,作为维护人员处理基站电源故障的参考。 一、交流配电故障 基站的交流配电部分主要包括:业主(电力局)配电房分路开关、市电进线电缆、基站计量电度表、基站电源进线总开关、三相分路开关、单相分路开关等设备。部分郊线基站还配有变压器。常见的交流配电故障主要有: 1.基站交流断电:基站交流断电是指整个基站没有交流输入。对于此类故障首先判断是否电力局市电停电。(1)如果市电停电,对于VIP基站则采用移动油机进行应急发电。发电时必须将交流输入空开断开,油机电缆接入基站电源总开关的下桩头,保证油机电源不会倒送进入市电电网。根据油机的容量,切断空调开关、蓄电池的熔断器避免油机输出过载保护。注意:油机发电时必须保证通风和接地,避免操作人员的安全事故。(2)如果市电正常而基站内没有交流电源,则检查基站电源总开关是否跳闸、业主配电房内送往移动基站的开关是否跳闸。 2.空开跳闸:空开跳闸往往是由于负载或线路短路、空开容量与负载电流不匹配或空开损坏造成。此类故障的检查步骤一般为:(1)检查开关、分路电缆和设备是否存在短路烧焦的痕迹,如果存在,则首先排除设备和线路故障;(2)如果线路正常,可以试着合上跳闸的开关,如果开关立即跳闸,这说明负载侧存在短路现象或开关损坏。(3)如果开关合上后负载工作正常,测量负载电流与开关容量进行比较并观察一段时间。如果空开仍然跳闸,这说明开关损坏需要更换。 3.电源缺相:电源缺相是指三相电源中有一相或两相的电压为0V,电源缺相将造成开关电源、空调保护停机。产生的原因主要有:市电输入缺相或开关损坏。电源缺相的检查可用万用表从末级开始逐级向上测量三相电源的电压,根据

经典案例_光明路和汤王大道交口北附近未接通优化案例

光明路和汤王大道交口北附近未接通优化 摘要: VoLTE是通信基础话音业务的一次全面升级,是无线网、核心网、信令网、承载网、支撑系统的一次系统性改造和变革,VoLTE异常事件的处理相对于C网时代,有着重大区别,不仅关注无线侧问题,核心测问题更需要关注。 关键字:VoLTE 无线网信令网核心网 【故障现象】: UE由北向南行驶至光明路和汤王大道交口北附近UE占用BZ-市区-劳服中心-HFUA-439095-55小区信号(RSRP=-75dBm , PCI=89 )出现主叫未接通;见下图: 【原因分析】: 1.干扰情况分析 通过干扰核查没有发现异常

2.根据测试数据分析,问题路段主叫占用BZ-市区-劳服中心-HFUA-439095-55小区信号 (RSRP=-75dBm ,PCI=89 ),无线环境良好,根据信令分析,在测试LOG中,存在Precondition Failure导致的失败事件,表现为呼叫过程中,终端主动上发或收到网络侧下发的580 Precondition Failure消息,随后呼叫中止,出现未接通事件(Time: 20181022 14:47:59.255 ,经度:115.760589 纬度:33.858342)。

3.车辆由北向南行驶至光明路和汤王大道交口北附近UE占用BZ-市区-劳服中心-HFUA- 439095-55小区信号(RSRP=-75dBm , PCI=89 )之后一直发起寻呼消息,14:42:56.235发起 183 进程, 14:42:56.354 释放 EPS 承载, 14:47:43.215主叫收到网络侧下发的 580 进程,由于呼叫建立与切换过程冲突,专载被MME 释放;呼叫建立过程中专载建立与切换几乎同时发生,MME 未收到NAS 专载完成消息导致释放专载;UE就会回复invite580,专有承载丢失形成的未接通事件

护理不良事件案例分析

护理不良事件案例分析 病区:呼吸内科不良事件名称:住院病人跌倒 主持人:杨淑华记录日期:2014.8.27 参加人员:科室全体医护人员 一般情况介绍 1、病人基本情况介绍:307床,束玉民,男,77岁,发热48小时于2014-8-27入院。入院诊断:发热待查。 2、事情经过:患者于2014年8月27日上午10时30分起床到卫生间自解小便,从便器上站起时突感头晕跌倒在地,致左脸颧骨处皮肤轻微擦伤。主诉:感脸颊部疼痛,无恶心、呕吐,轻微头晕,无头痛。双侧瞳孔等大等圆约0.25cm,对光反射灵敏,测P:76次/分,R:20次/分,BP:110/70mmHg。医嘱予碘伏消毒伤处皮肤,并用无菌纱布覆盖,头颅CT,密切观察血压、意识2小时。患者拒做头颅CT,嘱其安心卧床休息,小便暂用便盆,变更体位时动作易缓慢,家属加强陪护,如有恶心、呕吐、头痛症状及时通知医护人员。 3、护士长调查经过:当班护士在患者入住病房时曾经详细宣教,起床时家属予以扶持,体位从低到高时可能头晕,等适应后再走路。患者及家属示理解,但未引起足够重视,导致患者从厕所跌倒。事情发生时护士正在巡视其他病房。 4、讨论:(1)发生跌倒的危险因素:

(2)针对该病人跌倒分析原因如下: 1)患者体虚,长时间高热消耗而进食少,卧位时间过长;2)病房内无卫生间,地面潮湿,光线不足。3)病人及陪护的安全防范意识不够。4)护士的健康宣教不够细致和深入。5)护理风险管理中未及时评估。 (3)整改措施:1)在心理上、精神上给予患者和家属支持和抚慰,让他们认识到因为高热,普遍体虚,变更体位时容易头晕跌倒,这样一方面使其重视,另一方面消除其紧张情绪;2)加强护理人员健康宣教能力的培训;3)改造卫生设施;4)强化护理安全服务意识,让科内所有护士对跌倒防范有足够的重视,加强自我保护意识,避免不必要的医疗纠纷发生。 护理部 2014年8月 28日

4G基站故障处理手册LTE

TD-LTE产品维护手册 1、基站操作维护常用命令 ●LTE登陆IP:局向设置为192.168.0.49 电脑IP设置为192.168.0.X 255.255.255.0 ●查询RRU光路信息: DSP SFP ●查询RRU驻波状态: DSP VSWR ●查询基站版本命令:LST SOFWARE ●查询盲启开关命令:DSP DHCPSW 2、近端处理光路故障 ●TDS侧光路查询可使用命令DSP OPINFO 查询原有TDS光路好坏,是 否有光衰,通过查看BBU和RRU光口的输入输出功率来确定。 ●LTE侧光路查询可使用命令DSP SFP 查询光路好坏,是否有光衰,目前 开站要求收发光功率一般不小于1500,最小不能小于1000 。

3、近端处驻波故障 ●现网驻波值门限一般设置为1.5,LTE开通后门限一般都改为1.8了,也 就是说如果驻波值不超过1.8,是不会上报驻波告警的。TDL 的通道编号为0~7,驻波可通过命令DSP VSWR 来查询。 ●TDS的通道编号为1~8,驻波可通过DSP RRUPARA 来查询

4、基站近端登陆可查到的常见告警 5、故障处理流程和方法 (1)故障处理流程:

●故障处理流程包括以下几个环节:备份数据、收集并记录相关信息、确定 故障范围和类别、定位故障原因、故障排除、确认故障是否被排除、记录故障处理过程。 6、故障处理方法 ●备份数据 为确保数据安全,在故障处理的过程中,用户应首先保存现场数据,备份相关数据库、告警信息、日志文件等。

●故障信息收集 故障信息是故障处理的重要依据。任何一个故障的处理过程都是从维护人员获得故障信息开始,维护人员应尽量收集需要的故障信息。 ●确定故障范围和类别 根据故障现象,确定故障的范围和种类。 ●定位故障原因 故障定位就是从众多可能原因中找出故障原因的过程,通过一定的方法或手段分析、比较各种可能的故障成因,不断排除非可能因素。 7、常用故障维护功能 ●用户跟踪 用户跟踪基于用户号码,可以按照发生时序完整的跟踪用户的标准接口、内部接口消息、内部状态信息,并显示在屏幕上。 ●接口跟踪 接口跟踪基于某个标准(或内部)接口,可以按照发生时序完整的跟踪该接口上的所有消息,并显示在屏幕上。 ●对比/互换 对比/互换可以帮助用户判断故障的范围或位置。 ●倒换/复位 倒换用于确定主用设备是否异常或者主备用关系是否协调;复位主要用于排除软件运行异常。 8、处理小区类故障 ●小区不可用故障是在当基站检测到小区激活失败导致小区业务不可用时,

案例05-起呼振铃后收到invite603导致未接通问题分析

案例-HTC 终端声音设置为勿扰模式导致主叫起呼振铃后收到 invite603 描述能正常通话; 问题描述:抓取CDS 测试LOG 发现,被叫回invite180后、立即上发invite603 问题原因: 常 原因 定位 Tim* Q,:片 U 15 12213 RFiCC vfln 沖 OhR Q wrJ : onC^rn 廿 3C€H ■审I 14 15 194J4 4 UOdlfR EPS E '.-'3r r'T C Wil4iat IR ? out it 1*15 1S427 WQ4tF EPS Bearer Cw-eit^ccfEl EP3SM U.t5 T5432 守 tiLMlorniiMooTrins 伽 UL _CMXH 1*1S 15435 f*CCH 1*15傅3轉 事p 卸M RCCM U 15 1W0 和 11 tai m 「一 t Meai5iifemertfieB

精品案例_TAC设置不合理导致VoLTE未接通

TAC设置不合理导致VoLTE未接通

目录 一、问题描述 (3) 二、分析过程 (3) 三、解决措施 (5) 四、经验总结 (6)

TAC设置不合理导致VoLTE未接通 【摘要】随着VoLTE业务的不断推广,VoLTE用户数逐步增加,VoLTE业务的感知成为关注的焦点。经过几个月的不断优化,铜陵VoLTE网络掉话率逐步减少,但是未接通现象仍时有发生。为提高用户的VoLTE通话感知,需时刻关注未接通发生的原因,逐步解决,提升接通率,保障用户通话感知。 【关键字】VoLTE 未接通 【业务类别】VoLTE、参数优化 一、问题描述 RCU设备在铜陵铜官区北京东路上进行VOLTE路测时,主叫起呼发出Invite消息后,在收到核心网响应Trying 100之前,先收到了核心网下发的RRC Connection Release消息,RRC连接释放后,接续被终止,出现了未接通事件。 二、分析过程 通过信令详细分析主叫起呼的过程,可以发现,起呼前,主叫刚完成重选过程,从TL-市区-康复中心-HFTA-448900-53小区(PCI:210)重选至TL-市区-市二院-HFTA-448913-54小区(PCI:356小区),由于源小区与目标小区处在不同的TAC,主叫发起了TAU请求:

在主叫上发TAU请求后,未等网络回复ATU Accept,主叫已开始了起呼,上发Invite消息。然而Invite上发0.172s后,主叫同时收到了网络下发的ATU Accept和RRC Connection Release消息(因此时主叫处在非业务态,ATU更新会伴随RRC连接的释放),主叫被叫同时释放,从而导致了Blocked Call事件的发生。

精品文档_邻区漏配导致的VoLTE语音未接通分析

邻区漏配导致的VoLTE语音未接通分析 案例

目录 一、问题描述 (3) 二、分析过程 (3) 三、解决措施 (5) 四、经验总结 (7)

邻区漏配导致的VoLTE语音未接通分析案例 【摘要】VOLTE是基于IMS的语音业务,而IMS由于支持多种接入和丰富的多媒体业务,成为全IP时代的核心网标准架构。经历了过去几年的发展成熟后,VOLTE已经实现规模商用。VOLTE测试中邻区漏配会导致通话质量较差、掉话、未接通等问题,本文主要分析由于邻区漏配造成的未接通处理过程。 【关键字】邻区VOLTE 【业务类别】优化方法、VoLTE、参数优化 一、问题描述 统计RCU指标时发现6月13日10:03:33时在通达路与航苑路交叉口附近出现一次未接通事件,车辆在该问题路段时由西向东行驶,占用XY-BB-蚌山区-万达悦府C区4#楼一单元电梯机房-ZFTA-440309-8小区信号,RSRP=-85dBm、SINR=-11.8dB;主被叫均出现未接通。 二、分析过程 主叫在10:03:28秒时发出IMS_SIP_INVITE->Trying的信令,在10:03:33时出现未接通事件,产生事件原因为IMS_SIP_INVITE 488,主叫占用BB-蚌山区-蚌山区金奥华府西门-ZFTA-156318-134小区信号,RSRP=-62dBm、SINR=23.6dB,主叫信号良好; 主叫:

分析被叫数据,被叫在10:03:09时发出IMS_SIP_BYE->OK 200的信令后,结束通话进入空闲态,占用XY-BB-蚌山区-万达悦府C区4#楼一单元电梯机房-ZFTA-440309-8小区信号,RSRP=-80dBm、SINR=-5dB左右,占用该小区信号后,重复发送RRC连接重配置消息,最终产生LTE RRC Radio Link Failure事件,无线链路失败后,小区重选至BB-蚌山区-蚌山区金奥华府西门-ZFTA-156318-134小区后,信号恢复正常,被叫在10:03:33.836时发IMS_SIP_INVITE->Trying 100消息,还未建立QCI承载便发生了未接通事件。 从测试数据分析上看,在RRC连接重配置不成功产生了LTE RRC Radio Link Failure 的事件,提示无线链路异常发起重建,说明该未接通非流程冲突、SIP消息丢失、核心网的

经典案例_UE不活动定时器设置较小导致VOLTE未接通

无线-UE不活动定时器设置较小导致VOLTE未接通

目录 一、问题描述 (4) 二、分析过程 (4) 三、解决措施 (5) 四、经验总结 (6)

UE不活动定时器设置较小导致VOLTE未接通 【摘要】在eNodeB L2 MAC检测到DRB上下行都没有数据接收/发送之后,启动计时器计数,在当该计数器满足UE不活动定时器配置值后,L2上报L3发起释放(L3在S1口会向核心网发送“S1AP_UE_CONTEXT_REL_REQ”消息,且消息内携带的原因值为“User-inactivity”);当计数器未满足UE不活动定时器配置值时L2 MAC又检测到DRB有数据发送/接收后,计时器重新计数。由于UE不活动定时器超时导致RRC异常释放,然后上报CANCEL,导致为未接通,影响用户感知。 【关键字】UE不活动定时器VoLTE 【业务类别】VoLTE 一、问题描述 网优人员接到用户投诉在市区金隆公司附近打电话时,几乎每天都会遇到别人打自己电话,自己手机没反应,接不到电话。为此在现场展开测试分析优化。起呼过程中主被叫手机一直占用金隆公司基站,4G无线环境良好。 二、分析过程 主要的几个事件过程如下: (1)起呼过程中主被叫手机一直占用金隆公司基站,无线环境良好。 (2)先是主叫挂机,RRC被释放,主叫上报INVITE,主叫收到INVITE100,主叫建立EPS 专用承载。 (3)主叫RRC被释放,主叫RRC建立,收到INVITE183,收到INVITE180。 (4)主叫RRC被释放,主叫RRC建立,收到INVITE183,收到INVITE180。 (5)主叫RRC建立,主叫收到INVITE200同时上报ACK,主叫上报BYE。 (6)网络侧连续4次下发INVITE200,上报ACK和BYE,主叫收到网络侧下发的CANCEL481,原因为Cancel request received after dialog active state,收到BYE500,原因为Unexpected message received。 (7)主叫收到BYE200消息,正常释放EPS承载。 由于UE不活动定时器超时导致RRC异常释放,9s后上报CANCEL,导致一起未接通。

NOKIA基站故障处理-案例分析

第五章案例分析: 故障案例分析一: 驻马店市区刘阁基站(DE34)TRX2有7533告警(TX ANTENNA OR CONBINER CONNECTION FAULTY)由于连接在同一个合路器上的TRX1工作正常,初步判断AFEA 没有故障,TX连线紧固,则判断可能是TRX坏或者TX连线坏,更换TRX后故障解除。但是到3月9号,TRX2再次出现7533告警,由于TRX为新换的,TX连线无故障,分析认为合路器AFEA不稳定,存在隐患,更换AFE后故障解除,没有重复出现。 故障案例分析二: 西平人和基站(DE34)BCFA故障,更换后无法自启,检查发现软件包不对应(使用的板件是返修的库存板件,没有考虑软件包问题),灌入对应软件包重启后,Sec2和Sec3无法正常工作,其中Sec2的TRX7正常,而TRX8和Sec3的TRX9和TRX10均有7514告警(13MHZ CLOCK IS MISSING IN TRX)按照Nokia告警处理提示应更换TRX,但三块TRX同时坏的可能性不大,考虑可能为其他原因引起。于是将Sec2正常运行的TRX7和出故障的TRX8倒换位置,(操作过程中对该层PSUA断电)结果Sec2两块TRX均恢复正常。于是将Sec3的PSUA断电再加电,该扇区亦恢复正常。分析认为有时TRX内部软件需要重新掉电初始化。这一点和后来改半速率过程中,有些DE34站虽然数据与BSC完全对应,仍然出现OMU信令不活的现象类似,出现这种情况时,对基站供电单元CSUA掉电再加电就可以解决。 故障案例分析三: 遂平红堂基站(UltraSite)O改S后,Sec1一直占不上用户,且有7602(Mismatch between BSC/MMI configuration file and the actual)告警,经检查发现,硬件数据库中Sec1的数据不完整,补充完整后再上传进去,重启BCF,故障解除。 故障案例分析四: 妇幼保健院(ULTRASITE)断站,且断站时有7606告警,告警提示为合路器反射功率过高。根据以往经验,产生这个告警的原因有两种,驻波比过高或合路器坏,测试驻波比正常,更换合路器重起基站后告警消失,后期观察没有再出现这个告警。 故障案例分析五: 市区502基站(ULTRASITE)的SEC3反复闪断,有7705,7706,7723,8102等告警。到基站后发现传输板时而亮黄灯,时而亮绿灯,并且掉话非常明显。因为有传输告警,所以先从传输板、传输连接件和传输线考虑。自环传输板正常,检查DDF架。结果发现DDF架的2M接头松动,紧固后传输板没有再出现间歇性闪烁,基站正常运行。 故障案例分析六: 驻马店市区关王庙基站(UltraSite)的Sec2反复出现7604告警(Rx levels differ too much between main and diversity antennas),造成严重掉话。测量天线驻波比正常,更换宽带合路器WCGA和双工器DVGA仍不能解决,对基站主设备彻底检测确定正常,检查天馈部分,发现馈线进入机房后的接头处松动,重做接头并紧固后告警消除。对此故障分析认为,有时天馈系统的驻波比正常,并不能说明故障一定不是出在天馈系统。有些并不严重的连接松动情况可能无法在驻波比中显示。因此在处理这类故障的时候,测量天馈系统的参数只是判断故障的一个参考,还需要对连接部分进行仔细的检查。

经典案例_华佗大道与京珠线交口未接通优化案例

华佗大道与京珠线交口未接通优化案例 摘要:VoLTE是通信基础话音业务的一次全面升级,是无线网、核心网、信令网、承载网、支撑系统的一次系统性改造和变革,保障良好的无线环境、是保障VoTLT良好通话的前提。 关键字:VoLTE 无线网信令网 【故障现象】: 通过分析亳州_市区_RCU1194测试_未知_未知--0000119420190114141910p4 RCU数据发现EPC和IMS核心网进行信令跟踪期间出现主叫UE在通话结束时,上发IMS_SIP_BYE->Request后,没有收到IMS_SIP_INVITE->OK信令,IMS下发IMS_SIP_UPDATE 500,随后又下发IMS_SIP_INVITE487出现未接通,如下图: 【原因分析】: 1.车辆行驶在十河小学基站附近开始占用BZ-市区-十河小学-HFTA-439184-0小区信号, 一直到市区李庄基站还在占用之后一直占用L2100小区;经过U2000对BZ-市区-李庄-HFTA-439184-55小区核查在该小区在2019/1/14没有出现告警。

2.经过核查干扰排查BZ-市区-李庄-HFTA-439184-55小区没有干扰存在。 3.通过TA接入测量分析用户的TA值在区间3和区间4范围的接入次数较多。 4.通过查看BZ-市区-十河小学-HFTA-439184-0小区的两两切换发现BZ-市区-十河小学-

HFTA-439184-0小区和BZ-市区-十河小学-HFTA-439184-2小区、BZ-市区-十河小学-HFTA-439184-50小区、BZ-市区-李庄-HFTA-439184-54小区存在切换出失败次数。 5.通过对RCU数据分析发现主叫UE信令,主叫UE在15:12:54发起 IMS_SIP_INVITE->Request做语音业务,15:12:57上报IMS_SIP_PRACK,UE在通话结束时下发IMS_SIP_BYE->Request后,没有收到IMS_SIP_INVITE->OK信令,IMS下发IMS_SIP_UPDATE 500;由于很长一段时间占用L2100小区没有及时切换到周边L1800小区导致问题区域RSRP=-110dbm左右出现覆盖差现象。

4G基站设备安装及常见问题处理

4G基站设备安装要点及常见问题处理 随着铁塔公司的建立,基站及其配套机房、电源等将成为铁塔公司的技术要点,本文主要从基站设备安装、线缆布放、电源配置、天馈线安装等方面进行详细讲解,同时介绍了铁塔类型、施工工艺、标签规范等方面,是4G基站建设中不可多得的经验总结。 一. 基站主要设备安装、各类线缆布放示意图 基站内部设备安装示意图 电缆走线槽道安装 1.电缆走道及槽道安装位置应符合施工图的规定,左右偏差不得>50mm。 2.水平槽道水平度每米偏差不得>2mm,垂直槽道垂直度偏差不得>3mm。 3.电缆走道安装牢固稳定,具备防震功能。 4.电缆应有序地绑扎在走道上。

基站内部走线槽道布线安装

信号线的布放 1. 布放的信号线应平直,无扭曲打结,转弯处应自然圆滑,符合设计要求。 2. 屏蔽线外层应与接地体连接可靠。 3. 芯线应无损伤,焊点光滑、均匀,无漏焊、虚焊、错焊。 4. 系统控制器到信道机的电缆最大允许长度应符合产品说明书的要求。 5.信号线、高频馈线、电源线应分开布放。 电源线和地线的安装 1.电源线和地线安装方法: 根据电源线和地线的实际走线路径量得所用电源线和地线的长度,分别裁剪-48 伏电源线和工作地线、和保护地线;用裁纸刀剥开电源线和地线的绝缘外皮,其长度与铜鼻子的耳柄等长。用压线钳将铜鼻子压紧,用热缩管将铜鼻子的耳柄和裸漏的铜导线热封;不得将裸线漏出.将电源线的一端与BTS 机柜的电源接线柱固定,电源线沿走线架整齐布放,并用扎带绑扎,另一端和电源柜的接线排连接。 2.电源线的区分:电源线分为:-48 伏线(一般为黑色)、工作地线(一般为蓝色),保护地线(一般为黄色)。但有时不同厂家提供的电源线的颜色和线经大小不同。 二. 基站电源:交流、直流配电箱开关电源、远供电源 电池设备的安装 1、通信基站电源系统的组成 2、通信基站交流供电系统 3、通信基站直流供电系统 4、蓄电池 5、远供电源

关于CMSERVICEREJECT未接通的典型案例分析

关于CM SERVICE REJECT未接通的典型案例分析 问题描述:在近期的测试中,主叫手机占用到和田街客运站(39199-45451)小区呼叫因为受到严重干扰无线链路超时掉话,而被叫在很长一段时间内(主叫手机20s再次起呼)仍然处于专用模式下。主叫手机掉话20s后重选到富丽华大酒店(39199-45291)再次起呼,系统下发“CM SERVICE REJECT”主叫未接通。Reject cause:Message not compatible with the protocol state— 问题分析:相关资料对此次服务请求拒绝的解释如下: 因此怀疑此次未接通和无线侧没有任何关系,将相关信息发送给交换核查人员,得到的反馈为:主叫再次起呼的时候主被叫均处于专用模式下。因此经推断分析,主叫下行无线链路超时要早于上行无线链路超时(可以理解为上行无线质量更加优于下行无线质量),主叫无线链路超时后释放信道,而上行网络侧并不清楚手机已经释放信道,仍然处于通话模式下,同时网络对RLT超时的设置为64(即64×0.48=30.72s),即考虑最好的情况下,主叫下行

掉话后有可能BSC在30s以后才会向MSC发送强行拆链信息,交换侧释放信道。主叫20s 以后再次起呼,因为网络侧仍然没有释放信道,故下行发送“CM SERVICE REJECT”,拒绝本次起呼。 综上,以上现象只能发生在无线链路超时掉话且上行质量优于下行质量,即主被叫无线链路超时严重不一致的情况下;同时,发生此种掉话必定会发生一次未接通,这对于集团公司测试的考核来说,大大放大了网络问题,对接通率是一个很大的考验。因此控制干扰、改善网络无线质量是网络优化的重中之重。

基站维护经验基站可换设备故障处理

基站可换设备故障处理 载频常见故障说明 F文中提到的故障都是客户返修中最常见的,也是返修中最有可能发生WQFault- Found”情况的。通过了解造成这些故障的可能原因,用户就能在故障发生时确定故障背后的真正原因。这将减少网络故障时间并提高系统可靠性。 1.1“DRI Not Detected"和"Waiting for Connection,, 这两种故障都是由于MCU/MCUF不能与载频通信。术语DRI是所有类型载频的软件 总称。在“DRI Not Detected”的情况下,从载频到MCU/MCUF的上行链路中断; 而“Waiting for Connection”的情况则是从MCU/MCUF到载频的下行链路中断。 这些链路可能受多种因素影响,列举如下: ?数据库错误一一MCU/MCUF试图寻找物理上不存在的載频。 ?载频未加电或光纤的收发弄反。 ?TCU上的光纤损坏或弄脏。 ?CTU的背板接头或前面板有物理损坏。 ?系统处于过渡状态,会在几分钟内口行恢复。 ?TCU-B在”tcu_clock 0”后没有硬件"reset",在载频上按"reset"后会恢复。 ?载频硕件故障,更换載频能正常。 ?MCU/MCUF硕件故障,更换MCU/MCUF能够恢复正常。 ?FMUX故障引起,更换FMUX后能够恢复。 1.2“Inhibited" 该故障说明载频产生了一个严重告警。当处理一个“Inhibited。的载频时,应当记录下当前的告警。 ?软件和硕件载频重启。 ?更换敎频。 ?其它原因。 1.3“Code Load Fail” 和U CEB Configuration Fail J, 这两种故障说明在软件下载期间载频的固件和数字硕件间发生通信错误。这可能由 各种原因造成。很多情况下该故障可通过重新下载软件清除,载频也可正常工作。 1.4“No HDLC reset pending” 该故障通常是由于MCU/MCUF间的通信中断造成,而载频则可能处于软件下载过程中或正常工作状态。该故障通常会在儿分钟内口行淸除,也可通过JNS”#戈频清除。 1.5“Code Load” 这不是故障,只是表明软件下载仍在进行中。一次完整的软件下载可能需耍15?20 分钟,但对「?戦频的过程只耍1分钟左右。重要的是尽管可能发生错误,下载过程并没有彼中断。在下载过程结束前不要在该器件上进行任何操作,否则会使载频坏 掉。

相关文档
最新文档