LTE日常维护案例介绍

,Page,#,HUAWEI TECHNOLOGIES CO.,LTD.,单击此处编辑母版标题样式,英文标题,:32-35pt,颜色,:R153 G0 B0,内部使用字体,:,FrutigerNext LT Medium,外部使用字体,:Arial,中文标题,:30-32pt,颜色,:R153 G0 B0,字体,:,黑体,英文正文,:20-22pt,子目录,(2-5,级,):18pt,颜色,:,黑色,内部使用字体,:,FrutigerNext LT Regular,外部使用字体,:Arial,中文正文,:18-20pt,子目录,(2-5,级,):18pt,颜色,:,黑色,字体,:,细黑体,配色参考方案：,建议同一页面内不超过四种颜色，以下是组配色方案，同一页面内只选择一组使用。,（仅供参考）,客户或者合作伙伴的标志放在右上角,.,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,优先级映射,抓包,维护通道类故障,维护通道类故障处理,eNodeB,DHCP,站点,2,、自动发现,U2000,Config,Config,Config,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,、再次进行传输侧相关参数核查，主要是与,OM,通道相关的配置，如,VLAN,，网关,IP,，核查后发现,VLAN,配置与规划不一致，,修改,summary,表中基站的,VLAN,，重新导入,CME,中，重新导出开站数据和开站列表。,开站正常。,处理过程,维护通道类故障,VLAN,自学习失败故障处理,VLAN,自学习：,在,U2000,上创建,PnP,调测任务后，,U2000,周期性向基站发送,OM,通道建立请求。该报文的源,IP,地址为,U2000 IP,地址，目的,IP,地址为基站的,OM IP,地址。此数据包会被发送至基站侧,Relay,的,L3,路由器上，如果,L3,路由器上无对应此报文目的,IP,地址及,eNB OMIP,的,ARP,表项，,L3,设备就会广播,ARP,报文，此时基站则会接收到此,ARP,报文，并从,ARP,报文中取出正确的,VLAN,信息同时进行保存。,重点：基站学习到的,VLAN,是,IPRAN L2,上配置的,VLAN,1,、,DHCP,四个报文中从基站上报的,discover,和,request,报文中的,VLAN,都是从,IPRAN L2,上学习到的，所以基站所发的这两个报文能正常到达,U2000,，而,U2000,也可以把,offer,和,ack,报文发送到基站；,2,、,U2000,给基站下发,ACK,消息后，基站会把从,U2000,上配置的操作维护,IP,、,VLAN,和路由在基站侧生效；,在建立操作维护之前基站会使,用,U2000 ACK,消息中的,VLAN,和,IPRAN L2,上配置的,VLAN,进行对比，如果一致会建立操作维护链路,；如果不一致则把从,ACK,消息中获取到的,IP,，路由及,VLAN,全部失效，重新启动,DHCP,流程,案例根因：,传输类案例,传输引起的开站失败案例,问题现象,某局点，在进行开站时，发现从,U2000,上看，每次开站时都是进行到,99%,时，失败,。,排查,步骤,1,、首先进行现象确认，从,U2000,开站界面上可以看到基站已完成了版本下载、配置下载，在进行激活配置后等待站点重新启动完成时超时。,2,、其次进行配置核查，版本能够下载成功，说明,ESN,无误，,VLAN,、,IP,和路由没有问题，复位后,OMCH,建立失败，可能原因是版本和配置文件激活失败，或激活成功后,OMCH,通道建立失败。核查结果版本与配置文件匹配，没有问题，端口模式,/VLAN/IP/,路由配置均无误。,3,、再次进行传输侧相关参数核查，发现,ATN,的端口协商模块为强制（实际要求为自适应），改为自适应后，开站成功。,eNB,路由器）,M,2000,下载软件,下载配置,激活配置,激活软件,基站复位重启,复位后，,U2000,以新配置登陆站点,此处失败,目录,业务类故障处理,设备类故障处理,-,传输类,设备类故障处理,-,射频类,设备类故障处理,-,硬件更换类,射频类故障,射频类故障处理,1,2,3,RSSI,外部干扰,互调,驻波,CPRI,接口,电调天线故障,射频类故障,RSSI,故障处理,RSSI,过低,RSSI,不平衡,RSSI,过高,RSSI,RSSI,理论值,带宽,FDD,dBm,TDD,dBm,20M,-98,-97,15M,-99,-98,10M,-101,-100,5M,-104,-103,3M,-106,-105,1.4M,-110,-109,1,通道衰减值检查,互调干扰检测,2,方法,1,方法,2,1,、记录空载时的,RSSI,值；,2,、通过,ADD CELLSIMULOAD,加载模拟负载；,3,、在,U2000,跟踪,RSSI,差值是否大于,4dB,。,1,、通过,STR RFTEST,进行反向,互调,干扰检测；,过低告警门限为,-114dBm,空载下,RSSI,的计算方法如下：,-174+10*logBW+NF,其中,BW,为带宽，单位为,Hz,，,NF,为射频模块的噪声系数，通常为,2-2.5,左右，举例：,LRRU 2.6G 2T2R,，,5MHz,小区带宽，那么空载下的,RSSI,参考值大小,=-174+10*log(5*106)+2.5=-104.5dBm,。,RSSI,过高：,标准要求不超正常值,6dB,；因此,20M,：,RSSI=-92dBm,，,15M,：,RSSI=-93dBm,3,频谱扫描,OK,NOK,射频类故障,RSSI,故障处理,先按要求进行后台单站测试，加载和不加载的时候,RSSI,差值大于等于,4dBm,的定义为,内部干扰,（,工程质量问题和互调问题）,，需安排站处理恢复；,如果,RSSI,值高于,-,92dBm,，排除测试方法、驻波、射频通道告警等问题后，就可以认为“,疑似存在外部干扰,”，需要网优人员上站扫频；,如果客户扫频扫不出干扰，作为重点问题，由客户及网优，产品人员一起上站去排查处理；,如扫频扫出干扰，处理干扰问题；,RSSI,异常情况,现象,产生的主要可能原因,RSSI,过低,主（分）集长时间,RSSI,低于,-,114dBm,左,右,或出差,RSSI,过低告警,天馈各个接头接触不好，天馈、,TRX,、,CDU,、功放故障,RSSI,过高,主（分）集长时间,RSSI,高于,-,92dBm,或在一定时间内高于,-,92dBm,开关和跳线错误,天馈驻波、硬件故障、接头进水、系统工作不正,常和,互调、外部干扰,RSSI,主分集差异过大,主（分）集两者间,RSSI,长时间或在一定时间内相差,6dB,以上或出现,RTWP,接收不平衡告警,天馈驻波、天线安装问题、硬件故障、外部干扰,备注：主分集,RSSI,均偏高且基本一致，优先考虑外部干扰问题；主分集,RSSI,只有一个偏高，且相差较大，优先考虑互调问题。,射频类故障,互调