LTE日常维护案例.pptx

LTE日常维护案例介绍 目录 业务类故障处理 设备类故障处理 传输类 设备类故障处理 射频类 设备类故障处理 硬件更换类 传输类故障 传输类故障处理 类别 常见问题现象 传输类典型问题 信令终端/吞吐量异常 上层应用链路不通（SCTP、IPPATH、OMCH） IP冲突、路由错误等导致业务异常 VLAN错误、ARP异常导致链路不通 光纤/光模块故障,物理端口连接不良,光电模式协商不正确等导致物理链路不通 传输类故障 传输故障处理思路 总体思路：分层/逐段排查定位 分层法：根据协议层，逐层定位，定位出实际故障点； 逐段法：完成故障隔离，对数据流进行分段，逐段环回，逐段定位； 具体排查项： 物理层故障排查 ARP/IP层故障排查 IPPATH异常处理 SCTP异常处理 问题定界指导： 传输类故障 传输故障逐层排查方法简介 协议层 常见问题现象 L5 信令终端/吞吐量异常 L4 上层应用链路不通（SCTP、IPPATH、OMCH） L3 IP冲突、路由错误等导致业务异常 L2 VLAN错误、ARP异常导致链路不通 L1 光纤/光模块故障,物理端口连接不良,光电模式协商不正确等导致物理链路不通 排查方法 应用场景 PING 通断检测+MTU检测 TRACERT 传输路径排查、MTU探测 UDP环回 检测S1/X2链路质量 IP ROUTE 路由排查 排查方法 应用场景 DSP ARP ARP表项查询 DSCP/VLAN DSCP与VLAN优先级映射 抓包 维护通道类故障 维护通道类故障处理 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网站上取得，并且已经上传到U2000 Server。 1.3、导出开站列表 DHCP自发现失败 典型故障 DHCP自发现失败故障处理 【实现原理】 1、为了避免DHCP广播包冲击U2000，引入路由器进行DHCP Relay，转化为单播报文。 2、DHCP过程目的是实现eNodeB的OMCH的建立。即获取IP、路由等。 2、eNodeB上电后，4步完成DHCP过程。常见问题需分析具体消息中的取值 DHCP DISCOVER DHCP OFFER DHCP REQUEST DHCP ACK DHCP流程： 该流程分四步： 1） 基站在检测到可用的链路后，广播DHCP DISCOVER报文，以查找可用的U2000; 2） U2000进行ESN匹配，如果匹配成功，U2000会发送DHCP OFFER报文给L3交换机，并携带分配的IP地址等信息，以响应DHCP DISCOVER; 3） eNB收到DHCP OFFER后，判断ESN是否正确，如果正确，则停止DHCP探测过程。并发送DHCP REQUEST广播报文，向U2000服务器发起确认信息; 4） U2000同样需要进行ESN匹配判断。确认信息正确后发送DHCP ACK报文给eNB,基站收到DHCP ACK报文，进行ESN匹配，匹配成功后，分配的IP地址等信息生效，并生成OM IP和相关路由信息。 维护通道类故障 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、再次进行传输侧相关参数