LTE日常维护案例介绍doc资料.ppt

LTE日常维护案例介绍 目录 业务类故障处理 设备类故障处理 传输类 设备类故障处理 射频类 设备类故障处理 硬件更换类 传输类故障 传输类故障处理 传输类故障 传输故障处理思路 总体思路 分层 逐段排查定位分层法 根据协议层 逐层定位 定位出实际故障点 逐段法 完成故障隔离 对数据流进行分段 逐段环回 逐段定位 具体排查项 物理层故障排查ARP IP层故障排查IPPATH异常处理SCTP异常处理问题定界指导 传输类故障 传输故障逐层排查方法简介 抓包 维护通道类故障 维护通道类故障处理 DHCP 站点 2 自动发现 U2000 S W CME 中心机房 Support网站 1 1 提取版本包 1 2 组织配置数据 1 4 打开开站工具 上传数据 启动开站 上报ESN 4 调测License下发 1 安装上电 3 自动配置 Config S W 限制和约束 在开站之前 必须 硬件安装完毕 U2000调测完毕 eNodeB与U2000之间的传输正常 eNodeB的软件版本必须从Support网站上取得 并且已经上传到U2000Server 1 3 导出开站列表 DHCP自发现失败 典型故障 DHCP自发现失败故障处理 实现原理 1 为了避免DHCP广播包冲击U2000 引入路由器进行DHCPRelay 转化为单播报文 2 DHCP过程目的是实现eNodeB的OMCH的建立 即获取IP 路由等 2 eNodeB上电后 4步完成DHCP过程 常见问题需分析具体消息中的取值DHCPDISCOVERDHCPOFFERDHCPREQUESTDHCPACK DHCP流程 该流程分四步 1 基站在检测到可用的链路后 广播DHCPDISCOVER报文 以查找可用的U2000 2 U2000进行ESN匹配 如果匹配成功 U2000会发送DHCPOFFER报文给L3交换机 并携带分配的IP地址等信息 以响应DHCPDISCOVER 3 eNB收到DHCPOFFER后 判断ESN是否正确 如果正确 则停止DHCP探测过程 并发送DHCPREQUEST广播报文 向U2000服务器发起确认信息 4 U2000同样需要进行ESN匹配判断 确认信息正确后发送DHCPACK报文给eNB 基站收到DHCPACK报文 进行ESN匹配 匹配成功后 分配的IP地址等信息生效 并生成OMIP和相关路由信息 维护通道类故障 DHCP自发现失败故障处理 问题描述某局点 在站点安装完成并加电后 使用U2000进行自开站 发现某站点在发送OFFER报文后 在DHCP配置管理中一直未出现上报的REQUEST报文 问题原因在U2000抓包看 已收到eNodeB上报REQUEST报文 但在上报的REQUEST中未携带OPTION54字段 因此导致该站的REQUEST报文被U2000抛弃 同时 在基站侧镜像抓包后证明基站发送的REQUEST报文已携带OPTION54字段 结论 IPRAN修改了DHCP报文 丢弃了OPTION54字段 维护通道类故障 VLAN自学习失败故障处理 问题描述W市T运营商LTE工程在开站过程中DHCP四个报文都是正常的 从U2000上可以看到已经下发ACK消息到基站 且基站也收到U2000发送的ACK消息 但是ACK消息之后又重复DHCP四个报文 导致基站操作维护链路一直不能建立 1 首先进行现象确认 DHCP过程正常 而OM通道建立失败 可能是由于DHCP过程中下发的配置有误或者是传输侧配置有误 2 其次进行配置核查 结合现象核查DHCP下发的配置 DHCP下发的主要配置如图所示 核查后发现配置参考与规划相同 3 再次进行传输侧相关参数核查 主要是与OM通道相关的配置 如VLAN 网关IP 核查后发现VLAN配置与规划不一致 修改summary表中基站的VLAN 重新导入CME中 重新导出开站数据和开站列表 开站正常 处理过程 维护通道类故障 VLAN自学习失败故障处理 VLAN自学习 在U2000上创建PnP调测任务后 U2000周期性向基站发送OM通道建立请求 该报文的源IP地址为U2000IP地址 目的IP地址为基站的OMIP地址 此数据包会被发送至基站侧Relay的L3路由器上 如果L3路由器上无对应此报文目的IP地址及eNBOMIP的ARP表项 L3设备就会广播ARP报文 此时基站则会接收到此ARP报文 并从ARP报文中取出正确的VLAN信息同时进行保存 重点 基站学习到的VLAN是IPRANL2上配置的VLAN 1 DHCP四个报文中从基站上报的discover和request报文中的VLAN都是从IPRANL2上学习到的 所以基站所发的这两个报文能正常到达U2000 而U2000也可以把offer和ack报文发送到基站 2 U2000给基站下发ACK消息后 基站会把从U2000上配置的操作维护IP VLAN和路由在基站侧生效 在建立操作维护之前基站会使用U2000ACK消息中的VLAN和IPRANL2上配置的VLAN进行对比 如果一致会建立操作维护链路 如果不一致则把从ACK消息中获取到的IP 路由及VLAN全部失效 重新启动DHCP流程 案例根因 传输类案例 传输引起的开站失败案例 问题现象某局点 在进行开站时 发现从U2000上看 每次开站时都是进行到99 时 失败 排查步骤1 首先进行现象确认 从U2000开站界面上可以看到基站已完成了版本下载 配置下载 在进行激活配置后等待站点重新启动完成时超时 2 其次进行配置核查 版本能够下载成功 说明ESN无误 VLAN IP和路由没有问题 复位后OMCH建立失败 可能原因是版本和配置文件激活失败 或激活成功后OMCH通道建立失败 核查结果版本与配置文件匹配 没有问题 端口模式 VLAN IP 路由配置均无误 3 再次进行传输侧相关参数核查 发现ATN的端口协商模块为强制 实际要求为自适应 改为自适应后 开站成功 此处失败 目录 业务类故障处理 设备类故障处理 传输类 设备类故障处理 射频类 设备类故障处理 硬件更换类 射频类故障 射频类故障处理 1 2 3 RSSI 外部干扰 互调 驻波 CPRI接口 电调天线故障 射频类故障 RSSI故障处理 RSSI过低 RSSI不平衡 RSSI过高 RSSI RSSI理论值 1 2 方法1 方法2 1 记录空载时的RSSI值 2 通过ADDCELLSIMULOAD加载模拟负载 3 在U2000跟踪RSSI差值是否大于4dB 1 通过STRRFTEST进行反向互调干扰检测 过低告警门限为 114dBm 空载下RSSI的计算方法如下 174 10 logBW NF 其中BW为带宽 单位为Hz NF为射频模块的噪声系数 通常为2 2 5左右 举例 LRRU2 6G2T2R 5MHz小区带宽 那么空载下的RSSI参考值大小 174 10 log 5 10 6 2 5 104 5dBm RSSI过高 标准要求不超正常值6dB 因此20M RSSI 92dBm 15M RSSI 93dBm 3 频谱扫描 OK NOK 射频类故障 RSSI故障处理 先按要求进行后台单站测试 加载和不加载的时候RSSI差值大于等于4dBm的定义为内部干扰 工程质量问题和互调问题 需安排站处理恢复 如果RSSI值高于 92dBm 排除测试方法 驻波 射频通道告警等问题后 就可以认为 疑似存在外部干扰 需要网优人员上站扫频 如果客户扫频扫不出干扰 作为重点问题 由客户及网优 产品人员一起上站去排查处理 如扫频扫出干扰 处理干扰问题 备注 主分集RSSI均偏高且基本一致 优先考虑外部干扰问题 主分集RSSI只有一个偏高 且相差较大 优先考虑互调问题 射频类故障 互调问题处理 目前商用的互调测试仪都只能测试天馈系统的互调大小 无法定位出互调故障点的位置 在这种情况下 业界最成熟也是广泛采用的互调故障点定位方法是 分段排查法 或者使用 替换法 逐段馈线检查替换 分段排查法 如下图所示 射频类故障 电调天线故障处理 电调基本原理 远程电调天线RET RemoteElectricalTilt 由天线 远端控制单元RCU RemoteControlUnit 和AISG AntennaInterfaceStandardGroup 控制线缆组成 见图1 两种连接方式 RRU RFU SBT RCU和RRU RCU 射频类故障 电调天线故障处理 配置步骤 电调天线调测过程 通过网管远程控制 第一步 设置ALD供电开关MODRETPORT RRU直接给RCU供电方式 MODANTENNAPORT 使用SBT或塔放给RCU供电方式 第二步 扫描ALD设备SCNALD第三步 添加ALD设备ADDRET第四步 配置电调天线与RRU的对应关系MODRETSUBUNIT第五步 加载RET天线配置数据文件DLDRETCFGDATA第六步 校准RET天线CLBRET第七步 设置RET天线下倾角MODRETTILT第八步 查询RET天线下倾角DSPRETSUBUNIT 射频类故障 电调天线故障处理 常见电调故障 射频类故障 驻波故障处理 射频类故障 CPRI接口故障处理 射频类故障 射频类故障处理案例 华为LTE基站RRU光路异常分析 目前LTE基站基本采用DBS3900方式组网 因此BBU RRU的光路故障是我们日常维护中最经常遇到的问题之一 这类故障常见的告警包括 告警类别那么多 吓死人了 射频类故障 射频类故障处理案例 华为LTE基站RRU光路异常分析 其实 没有那么复杂 BBU RRU光路涉及的设备就那么几个 你说能复杂到哪去呢 是吧 下面我们来分析看看 BBU和RRU尾纤直连 BBU和RRU中间转接光路 BBU和RRU尾纤接ODF架 处理方式 后台查询1 通知后台查询BBU光模块的收发光功率是否正常 2 如果RRU没有中断 查询RRU光模块的收发光功率是否正常 通过后台的光功率查询 可以初步判断故障原因是光衰过大还是链路中断 射频类故障 射频类故障处理案例 华为LTE基站RRU光路异常分析 现场排查 建议携带 光功率计 光模块 短尾纤 做以下操作前可以先查看光模块规格是否正确 拔插光模块 尾纤 查看尾纤头是否有尘灰等 以下4个步骤 基本可以完成故障的排查和处理 其实挺简单的吧 所以不要在检查前随意就换了光模块或者RRU哦 1 用尾纤在BBU光口环回 和后台确认BBU的光模块收发光是否正常 如果正常可以排除BBU端口和光模块问题 否则请按顺序更换BBU光模块 端口 单板直到环回BBU光模块收发光正常 2 在BBU侧用光功率计测量RRU过来的光功率是否正常 如果不正常 检查下一步 3 在RRU测量RRU发出的光功率 如果正常 请检查光路 如果不正常 请按顺序更换光模块 RRU端口 RRU直至发出的光功率正常 4 在RRU处测量BBU过来的光功率 如果不正常 请检查光路 如果正常 请按顺序更换光模块 RRU端口 RRU直至正常 射频类故障 射频类故障处理案例 1 问题现象 上报ALM 26529射频单元驻波告警 重要 与ALM 29243小区服务能力下降告警问题分析 如果驻波告警后处理开关打开 上报重要级别射频单元驻波告警 将关闭驻波告警对应的发射通道 触发小区服务能力下降告警 此时先处理驻波告警如果未打开驻波告警后处理开关 则两个告警分别排查 问题处理步骤1 查询驻波告警门限 确认门限配置正确 LSTRRU 默认驻波门限2 0 驻波后处理门限3 0 2 离线驻波测试 确认驻波检测的结果确实高 输入小区的下行中心频率 避免天馈组件中存在频段不匹配的组件 如合路器等 导致测试的结果错误 3 上站排查 发现驻波异常的通道天馈线缆断开 重新连接好后测试驻波恢复 射频类故障 射频类故障处理案例 2 问题描述 上报ALM 26521射频单元接收通道RTWP RSSI过低告警 问题处理步骤 确认是否存在ALM 26532射频单元硬件故障告警 如果存在按告警帮助处理 不存在 2 排查接收通道衰减配置 如果有塔放 塔放是否正常工作 没有使用塔放 且通道衰减为0 没有问题 3 复位射频单元 复位后不恢复 带备件上站排查 4 交换射频单元正常与异常通道的天馈连接 交换后射频单元未随天馈转移 5 更换射频单元后恢复 待返板分析 射频类故障 射频类故障处理案例 3 问题描述 上报ALM 29243小区服务能力下降告警问题分析 1 配置与单板实际支持规格不符 小区配置的 小区发送和接收模式 大于RRU实际支持的规格 例如配置2T4R小区 RRU实际只能支持2T2R RRU实际支持的规格可以通过查询RRU电子标签确认 2 小区配置的 小区发送和接收模式 大于LBBP实际支持的规格 例如配置2T4R小区 LBBP实际只能支持2T2R LBBP实际支持的规格可以通过产品文档 硬件描述 确认 3 如果是SFN小区 由于配置错误或RRU不可用导致配置的 SFN小区扇区设备数量 与实际可用的扇区设备数量不一致修改 SFN小区扇区设备数量 与实际一致 或解决RRU不可用问题 MODCELL LocalCellId 0 MultiRruCellFlag BOOLEAN TRUE MultiRruCellMode SFN SectorEqmNum n 4 CPRI带宽不足DSPCPRILBR查询当前协商到的线速率 将该速率与实际配置所需的CPRI速率进行对比 如果小于实际配置所需CPRI速率 CPRI不压缩场景下 20M 15M2T2RCPRI接口带宽需求为2 5Gbps 20M 15M2T4RCPRI接口带宽需求为4 9Gbps 具体计算可参考2013年FAQ CPRI接口速率如何计算 则根据 最大速率能力 部分的描述判断是RRU侧的光模块还是LBBP侧的光模块速率过低导致 同时可以通过DSPSFP确认光模块的详细信息 如果光模块速率正确 但是协商到的速率小于两侧光模块的速率 则有可能是CPRI链路其它故障导致 射频类故障 射频类故障处理案例 3 5 射频单元发射通道或接收通道关闭查看是否存在26259 射频单元驻波告警 26545 射频单元发射通道手动关闭告警 26532 射频单元硬件故障告警 26538 射频单元时钟异常告警 26524 射频单元功放过流告警 如果存在先排除告警 注意 在射频单元驻波告警后处理开关关闭 通过LSTRRU查询 时 不会因为驻波大于驻波比告警后处理门限 默认值3 关闭发射通道 故此时不会导致小区服务能力下降告警 6 CPRI链路异常查看是否存在26230 BBUCPRI光模块异常告警 26232 BBU光模块收发异常告警 26233 BBU光接口性能恶化告警 26234BBUCPRI接口异常告警 26503 射频单元光模块收发异常告警 26504 射频单元CPRI接口异常 26506 射频单元光接口性能恶化告警 如果存在先排除告警 问题处理步骤 确认小区配置实际单板规格是否支持 小区配置2T4R RRU3632 LBBPd3单板 CPRI未压缩时 2T4R20M小区需要4 9GCPRI速率 查看CPRI协商结果 从线速率上确认 CPRI速率不足导致小区服务能力下降 DSPSFP或DSPELABLE查询光模块支持的速率 确认为LBBP侧使用了2 5G光模块 更换光模块告警恢复 射频类故障 射频类故障处理案例 4 问题描述 出现 电调天线马达故障告警 和 电调天线未校准告警 华为双频六端口天线替换原C网天线并安装华为RRU3638 C网天线的RCU先级联到LTE天线的RCU上 然后将RCU通过AISG电缆连接到RRU3638 通过网管对站点3个小区进行电调数据加载 总显示校准失败 多次校准后出现3个小区LTE侧电调马达永久堵转现象 问题分析 1 RCU马达硬件故障 2 RCU的电压供电不足会导致马达驱动力不足 RCU线接触不良 线未拧紧等 或RCU线过长 馈线馈线松动 过长都可能导致供电不足3 加载的配置文件与RCU不匹配 射频类故障 射频类故障处理案例 4 问题处理步骤 1 加载电调数据 显示校准失败 通过DSPRETPORT查看端口电流值 均显示正常范围 2 SCNALD扫描电调天线 并不存在序列号错误的现象 3 删除电调数据 RSTALD复位天线设备 复位RRU 重新加载数据 仍显示电调未校准 4 需上站处理了 但是3个小区都出现马达堵转硬件故障的几率很小 则怀疑加载电调数据时绑定RCU序列号可能出现LTE侧和C网侧混淆 则删除数据 将每个小区电调序列号LTE侧和C网侧互换 重新加载电调数据 加载成功 目录 业务类故障处理 设备类故障处理 传输类 设备类故障处理 射频类 设备类故障处理 硬件更换类 U2000FDD LTE的UMPT板故障恢复指导书 在现实LTE网络运维中 基站单板故障不可避免 LTE网络没有了基站控制器 其运行配置全部储存在基站上 因此更换主控板时 需要完全更新数据 华为网管集成了CME对数据进行管理 通过CMECurrent区实时同步网元配置的功能 可以实现不需要重新开站而只需要利用已保存的数据完成快速建站 达到更换主控板前的站点状态 需要在现场更换单板前完成Step1 Step3步骤工作 否则网管数据可能会被新更换单板数据覆盖 1 删除即插即用中原来的基站数据 注意记录基站ESN号 2 进入CME Current区 打开Current区 导出目标站点的 即插即用数据 3 校验完成后 进入 即插即用 界面 点击进行重新开站 4 更换主控板 待开站正常结束 5 检查数据配置是否与之前相同 及基站各项状态是否正常 目录 业务类故障处理 设备类故障处理 传输类 设备类故障处理 射频类 设备类故障处理 硬件更换类 业务类故障处理案例1 问题描述某LTEFDD站点下只能接入一个终端 第二个终端无法连接上 后来更换多个终端 发现有的可以接入 有的则不行告警信息 无版本 V100R008C01SPC240 问题分析 1 用户接入类问题 首先排查终端问题 是否只涉及某一类终端 其次确认失败时现象 是否网络无响应 还是已接入无法做业务 2 接入失败 要通过信令确认在哪一个阶段被拒绝 是RRC阶段还是E RAB阶段 LTE系统中的承载如下图所示 业务类故障处理案例1 问题处理步骤 1 通过跟踪可以看到UE会给MME回复S1AP INITIAL CONTEXT SETUP RSP消息后 等待了52秒给MME又发送了释放请求 原因为传输资源不可用 2 S1AP INITIAL CONTEXT SETUP REQ携带的地址如下 解析后为10 100 34 68 1 3 查看告警情况测试时间段28号告警上报情况是正常的 到10 100 34 68无异常告警 业务类故障处理案例1 4 从CHR统计可以看到90 的掉话都是由于UEM UECNT REL RECV GTPU RESET BEAR REQ 导致RAB阶段掉话 这个错误值的含义是RRC重建 重配置GTPU资源失败 5 查看CHR日志 选取了多次失败记录看 都指向不同的对端IP 有10 100 34 12 10 100 34 65 10 100 34 34等等 如下图只是一个举例 说明并不是某一条链路存在问题 所有链路都有问题 再看对应释放时间点的debug日志 看到有GTPU的EchoResponse超时记录 以及明显的IPPATHdown的记录 说明是IPPATH链路故障导致对端没有回EchoResponse 6 检查传输链路 对所有对端IP进行PING测试 500字节20次包大部分都能PING通 1500字节基本不能通 调整到1472能PING通 1473字节PING不通 说明传输MTU存在瓶颈 设置的MTU值不满足我们的要求 要求传输更改MTU值或者更换传输链路 7 由于当前使用异厂家传输 修改MTU未协调成功 修改到华为传输下 ping1500字节能通 业务测试正常 业务类故障处理案例1 案例中IPPATH故障却未上报告警 IPPATH故障是否有检测机制 是否会上报告警 如果打开了GTPU静态检测 MODGTPU IPPATH会通过GTPUECHO报文检测业务通道 检测机制根据配置MODGTPU来定的 默认是20s一次 连续3次才上报告警 LSTGTPU 查询GTPU配置信息 ECHO帧超时时长 毫秒 20000ECHO帧超时次数 3差分服务码 0静态检测开关 使能 静态检测 1分钟检测一轮 1分钟定时器超时后 在所有IPPATH上发送GTPUECHO检测报文 收到SGW应答 检测正常结束 检测不通 等待 ECHO帧超时时长 MODGTPU设置 默认5秒 后 发送下一个报文 一共发送 ECHO帧超时次数 MODGTPU设置 默认3次 超时后上报 IPPath故障告警 Link方式 或 用户面承载链路故障告警 End Point方式 动态检测 只检测有用户承载的IPPATH 检测机制与静态相同 检测到故障后不上报告警 会释放对应IPPATH上的承载用户 接入类故障 接入类常见故障处理 当出现终端无信号情况时 首先检查小区是否正常开工 排查基站侧告警 2 小区正常后 仍无法搜到网络 则确认终端是否支持LTE对应频段 FDD TDD模式 3 终端发起attach流程后 未发起鉴权就被MME拒绝 一般原因为终端在EPC侧的开户数据存在异常 需要协调EPC配合定位 4 终端与EPC双向鉴权失败 导致终端被拒绝接入 一般原因为写卡的KI OP OPC与开户的KI OP OPC不一致 该问题需要EPC配合解决 5 当安全模式流程通过后 终端接入失败分为两种情况 a 基