外场传输问题定位手段

一、基站内传输基本情况介绍：基站与外部网络通过S1口相连，S1口进来的数据首先进入NP处理器，NP据数据类型更新IP头信息，一般来说数据分为两类：一类是信令面数据，从NP出来后经过ETHSW到达SCT板上的PPC处理器，由HL或OM负责处理；另一类是业务面数据，从NP出来后经过ETHSW到达基带板，以BPOG板卡为例，数据在基带板上进入DSP处理器，由L2进行处理并继续转给PL完成后续空口处理。大致框架如图所示SCTE板BPOG板PPC（HL/OM）ETHSWNPDSP（L2/PL）ETHSWDSP（L2/PL）DSP（L2/PL）S1口调测口信令流业务流业务流业务流业务流PPC（OM）驱动控制基站侧镜像抓包功能建立在所有信令面和业务面数据都会流经NP与ETHSW相连的端口的基础上，在这个ETHSW上设置镜像功能，就可以将数据通过调测口抓取进行分析。参见红色连线。二、驱动常用的传输定位手段：1、71号日志关键内容分析NP处理器IPRAN口连接状态正常情况下71号日志中应有如下打印：[NP:]-------------------显示各IPRAN端口的状态-------------------[PHY]:TheEthPort#0isLinkUp,TheEthPhyInfois:EthPhyLinkStatus:LINKUPEthPhySfpMode:OPTICALSFPEthPhySPEEDMODE:1000MbpsEthPhyDuplexMode:FULLDUPLEX[PHY]:TheEthPort#1isLinkDown,PleaseCheckNetwork![NP:]-------------------显示PHY端口状态记录----------------------2009-01-0100(+8):00:42phy0linkdown2009-01-0100(+8):00:42phy1linkdown2009-01-0100(+8):00:44phy0linkupoptical1000Mbpsfullduplex2013-11-2806(+8):34:00phy0linkdown2013-11-2806(+8):38:44phy0linkupoptical1000Mbpsfullduplex其中，EthPhySPEEDMODE表明S1口和PTN连接的速率，通常应是1000Mbps，如果这里协商成100Mbps那么速率肯定会受影响，除了速率外还有link状态、双工状态等记录。SCTP_SERVER端偶联状态和SCTP_CLIENT端偶联状态记录了SCTP链路建立和断开的通知，包括通知时间、偶联ID、源目的IP以及断链原因等。在关注COMMUNICATIONLOST时，AbortValue为21，表明断链原因是收到了对端发来的abort报文；AbortValue为46，表明断链原因是向对端多次重传报文失败或心跳丢失Iub口发送数据丢失计数和Iub口接收数据丢失计数记录了SCTP链路上行丢包和下行丢包出现GAP的时间点，若相同时间点多次出现GAP，且该情况一直持续，则推断Iub口上行有丢包出现，可能影响业务流程，记为可疑故障。请联系研发人员定位。SCTPLINKINFO记录了提取日志时刻SCTP链路的状态。其中链路的STATUS字段为1代表偶联已建立，0为未建立。若链路出现故障，可对比此表中信息与LMT上显示是否一致，若不一致以此表为准。SCTPASSOCINFO记录了某个偶联从建立起到提取日志时累计的性能计数。重点关注以下字段：sctp_ctlchk_hbchknum和sctp_ctlchk_hbackchknum分别为该偶联发送的心跳数和接收到的心跳回复数，网络状况良好的情况下两者应相等或者相差为1，若差值较大，说明心跳丢失严重。可通过隔一段时间提取两份71号日志，对比这段时间内丢包率2、DIYPS模块TCP协议分析功能请马明礼补充，这部分功能需要结合CDL工具使用，可以统计出GTPU链路3、基站侧镜像抓包功能在LTE的LMT-B上选择“传输管理-镜像功能”，右键点击将镜像开关设置为打开，这样在基站的外部调试网口就镜像出了NP处理器与ETHSW芯片之间的所有收发数据，相当于获得了外部网元与基站的所有交互数据。抓包结果分析通过基站侧镜像抓包获得的内容如图所示，由于外部传输网络进入基站的数据包首先经过了NP处理器，然后才到达ETHSW芯片，镜像是将进入到ETHSW的数据包拷贝一份到调试口，因此这里抓到的数据包源IP和目的IP均为基站内部IP（NP处理器会根据链路规划配置，将报文更换IP地址和端口号，之后将报文从内部以太端口发出）。例如源IP为10.0.1.193的是NP芯片的IP地址，目的IP为10.0.4.205的是4槽位BPOG上DSP1的core4（也就是PDCP所在核的IP），包的协议类型为UDP。如果单单看这个抓包显示，是无法看出服务器和UE的IP地址以及数据包类型的。此时需要选中其中一条报文，右键选择“DecodeAs”，这里会显示将报文按照哪一种协议解析，此处咱们选择GTP报文。按照GTP协议解析后，数据包的源IP和目的IP变为了真正的服务器与终端的IP，例如下图中序号7的数据包为从服务器112.15.166.94发往终端172.16.0.76的下行GTPU包，长度为1450字节。下面是几个通过抓包定位的传输问题，可以参考三、典型业务速率低问题分析常见的业务速率低问题在问题复现时可以上站抓包分析，同时终端侧在对应时间段也可进行抓包分析。下面是宁波彩虹大厦站点在复现下行FTP业务速率低时的基站侧抓包结果，复现时该站点小区中仅有一个UE在进行测试，此时基站侧上下行残留bler为0。服务器侧IP为112.15.166.94，终端侧IP为172.16.0.47。该抓包针对GTP类型包进行了过滤，并选择了streamindex=5的数据包。其中序号（No）为28743和28770两行是基站侧连续收到的这个stream线程的两个GTP包，其包序号（Sequencenumber）分别为179521和183601，差值为4080，约为3个GTP包，因此抓包显示TCPPrevioussegmentnotcaptured，仅基站的上一级节点PTN设备存在丢包。此时终端发起了TCPDupACK，要求重传包序号为180881的GTP包，参见28821行，此后服务器重发了180881和182241两个GTP包，参见28856和28857行。在此之后未再次见到序号为180881的GTP包，说明这包数据确实是丢在基站外侧，而非空口环节。1、S1无法建立完成问题分析S1链路的建立过程目前主要分为三个阶段：驱动配置完成-驱动建立完成-与对端建立完成，其中前两步主要由OM和DD配合完成，属于SCTP链路底层建立过程，最后一步为基站高层与核心网高层建立过程。一般而言，如果底层SCTP链路存在问题，当前状态会反复在驱动配置完成到驱动建立完成变换。以宁波鄞县体委站点SCTP链路反复删建问题为例，参见下图在基站侧的镜像抓包结果，其中基站侧的IP地址为192.168.136.66，核心网侧的IP地址为192.168.168.3，可以看到从第49行开始基站发起SCTP建立的INIT报文，到第52行核心网回复COOKIE_ACK报文，按理此后SCTP底层应该就建立成功了，但是就在这时核心网又发出了一个SHUTDOWN报文和一个ABORT报文，导致SCTP链路删除，此后57行再次重复上述过程。出现这种情况的主要原因是，在核心网侧收到基站回复的COOKIE_ACK报文后，在进行高层交互过程中又收到了来自同一个基站IP发出的INIT报文，造成核心网误认为链路存在问题，因此发起SHUTDOWN进行删链。核心网侧抓包情况如下，请注意在10650行底层握手完成后，12568行已经开始进行高层交互，但在14873行又收到来自IP同为192.168.136.66的基站发出的INIT报文，核心网侧判断这种情况链路存在问题因此触发了删链操作。根据两侧的抓包分析，判断网络内有IP相同的站点在与核心网进行交互，因此对该站点后续做了修改基站侧IP的处理，故障恢复。2、传输闪断问题分析传输闪断问题一般分成两类：一类是两个站点IP配置冲突导致PTN学习到的基站MAC地址不断变化；另一类是传输链路质量较差导致丢包严重。我们以南京近期排查的燕归园站点和雨山路站点进行举例，由于南京这边采用了OM通道与业务通道分IP的设置，因此这两个站点虽然出现S1链路闪断，但是OM通道未受到影响，远程LMT和OSPStudio还能够连接，可远程操控。对于燕归园站点，主要表现为远程LMT能够正常连接并提取公共日志，S1链路在建立完成2分多钟之后就发生断开，其间没有上报局间以太link状态改变告警，但是很快就会重新建立S1成功。OMC上告警显示如下：告警源产生时间清除时间间隔时间测试区域,燕归园小区试扩L329225,小区1,小区状态信息02013-03-0200:01:232013-03-0200:03:390:02:16测试区域,燕归园小区试扩L329225,小区1,小区状态信息02013-03-0200:04:222013-03-0200:06:410:02:19测试区域,燕归园小区试扩L329225,小区1,小区状态信息02013-03-0200:07:222013-03-0200:09:390:02:17测试区域,燕归园小区试扩L329225,小区1,小区状态信息02013-03-0200:10:222013-03-0200:12:420:02:20测试区域,燕归园小区试扩L329225,小区1,小区状态信息02013-03-0200:13:222013-03-0200:15:400:02:18测试区域,燕归园小区试扩L329225,小区1,小区状态信息02013-03-0200:16:232013-03-0200:18:400:02:17测试区域,燕归园小区试扩L329225,小区1,小区状态信息02013-03-0200:19:242013-03-0200:21:410:02:17查询驱动71号日志SCTP链路状态也基本符合这一规律，检查基站侧的传输参数配置也未能发现异常，在这种情况下采取了上站抓包的策略，抓包仍旧是使用通过将NP内口与ETHSW交互的数据镜像到近端调试口的方法进行的，整理抓包的结果如下，其中基站侧的业务IP为100.68.129.182，MME侧的IP为100.68.253.4和100.68.253.12。可以看到在94行-102行完成了一次S1建立过程，此后大约维持了5次SCTP心跳交互，参见193行-267行，之后基站侧连续10次分别向两个MME发送心跳检测报文没有收到心跳ack回复，参见279行-353行，基站主动触发了ABORT报文进行删链操作，其后再次重复上述过程，形成闪断的现象。这种抓包效果与S1建立成功后局间以太link状态改变很类似，因此一开始仍旧是怀疑中间传输线路不稳定，采取更换光模块和光纤的方法尝试恢复，没有效果，也进行了整站复位的操作仍旧无效。鉴于S1链路和X2链路同时存在此种现象，暂时排除了MME侧的问题，重点仍旧怀疑传输PTN未能转发心跳ack报文，联系中兴PTN技术支持。对方检查后发现PTN与燕归园站点连接的端口上学到的该站点MAC地址在两个值之间不断更新，其中一个为燕归园站点对外的MAC地址，另一个未知。后请机房同事轮询了该可疑MAC地址所属站点，发现确为我司尧化门T站点，该站点业务IP配置与燕归园重复，为配置文件问题，OM通道配置正确。但是该站点添加了多条S1链路，因此未同时表现闪断情况，修改后燕归园闪断问题恢复。对于雨山站点，主要表现为S1链路故障告警以30分钟为间隔产生和清除，远程LMT能够连接，能进行简单操作，例如查询某一配置参数，但是无法上传一致性文件，远程OSPStudio连接基站主控控制台后发现经常性断开连接，