高通5G平台（SDX55\SDX62\SDX65）：ping包异常问题排查指南

1. 背景

移动通信延续着每十年一代技术的发展规律，已历经1G、2G、3G、4G的发展。每一次代际跃迁，每一次技术进步，都极大地促进了产业升级和经济社会发展。从1G到2G，实现了模拟通信到数字通信的过渡，移动通信走进了千家万户；从2G到3G、4G，实现了语音业务到数据业务的转变，传输速率成百倍提升，促进了移动互联网应用的普及和繁荣。当前，移动网络已融入社会生活的方方面面，深刻改变了人们的沟通、交流乃至整个生活方式。4G网络造就了繁荣的互联网经济，解决了人与人随时随地通信的问题，随着移动互联网快速发展，新服务、新业务不断涌现，移动数据业务流量爆炸式增长，4G移动通信系统难以满足未来移动数据流量暴涨的需求，急需研发下一代移动通信（5G）系统。

可能有人会问，5G到底是什么？对于个人而言有什么用？用官方解释5G就是第五代移动通信技术（5th Generation Mobile Communication Technology，简称5G），是具有高速率、低时延和大连接特点的新一代宽带移动通信技术，5G通讯设施是实现人机物互联的网络基础设施。对于我们最直观的感受，就是网速快了，比如1GB的电影，以前4G下载需要数分钟、甚至数十分钟，现在仅需1s左右即可下载完成，这就是5G。一句话就是高速率、低时延。

2019年是5G元年，到现在已经演进近三年，5G技术发展迅速，5G应用均也已走进千家万户，与我们生活息息相关，我们最直接接触到的有5G手机、5G家庭CPE、5G直播等，都极大的便利了我们的生活，提高了我们的用户体验。

5G作为一种新型移动通信网络，不仅要解决人与人通信，为用户提供增强现实、虚拟现实、超高清(3D)视频等更加身临其境的极致业务体验，更要解决人与物、物与物通信问题，满足移动医疗、车联网、智能家居、工业控制、环境监测等物联网应用需求。最终，5G将渗透到经济社会的各行业各领域，成为支撑经济社会数字化、网络化、智能化转型的关键新型基础设施。

要能够使用5G网络，就必须使用5G芯片，通常可以叫做modem或基带。行业内做的最好的有三家：高通、展锐、MTK，展锐5G模组有V510、UDX710等，MTK有T750、T830等，高通有过渡阶段的SDX55、支持R16的SDX62\SDX65、甚至速率达到10 Gbps的SDX70。但这么多的5G通信模组，在网络连接进行数据业务时经常出现链路异常问题，需要分析排查。今天就和大家分享一下高通5G平台ping包异常问题排查方法。

2. Ping包数据流走向及网络架构

2.1 终端与网络架构图

当终端在做ping包业务时，数据流走向如下图所示：

注：上图中蓝色箭头为上行Ping包的请求，红色为Ping Reply.

2.2 终端与基站之间协议栈数据流走向图

从协议栈角度来看，终端的上下行数据走向如下图（图中以LTE为例，SA类似）

注：图中红色箭头表示上行数据，下行的和上行数据流走向相反。

3. Ping包问题常见分析思路

常见的Ping问题现象一般为Ping不通，其实分为两类：Ping Request未发出去，及未收到Ping Reply

3.1 终端与基站之间协议栈数据流走向图

如果测试场景中，有网络侧参与，问题出现时，通常需要抓取终端的Wireshark，QXDM及基站侧数据包。

根据文中之前提到的终端与网络架构图可以看出，终端发送Ping Request时，数据流走向为：AP->PDCP->RLC->MAC->PHY，终端最终通过物理层将Ping Request发到基站的物理层。

如果有网络侧参与，需要基站抓取数据包，确认基站是否已经收到了终端的Ping Request。这样做的目的是可以快速地对问题定界，确认到底数据包丢在了哪个节点。

• 对于Ping Request未发出去的问题：
  如果基站侧已经收到了Ping Request，说明我们终端发送的没问题，需要排查host侧和网络侧各个节点。
  如果基站未收到，极大可能是因为我们终端未发出去，出现这种情况，首先需要排查终端拨号状态，确认拨号正常，其次需要排查无线环境，RSRP,SINR等参数是否OK。如果无线环境排查无异常，就需要获取终端QXDM、WIRESHARK等log进一步排查
• 对于未收到Ping Reply问题：
  首先要确认Ping Request是否已经发送到服务器，这个可以和服务器端确认，如果未收到，请按照Ping Request的排查思路进行排查。如果收到，则需要按照逆向的数据流进行分析，排查基站侧是否有发给UE。

3.2 测试场景无网络侧参与

对于无网络侧参与的问题，需要先做简单的排查：

• 排查终端注网及拨号是否正常
• 排查无线环境是否正常。（RSRP,SINR各项参数）
• 对比测试，Ping其他网站及服务器是否能Ping通。（如果能Ping通，大概率非终端问题）
  上述三条排查完成后，确认无异常，则需要抓取终端的Wireshark及QXDM log。

3.3 QXDM Log分析思路

• 抓到QXDM后，用QCAT打开，导出PCAP log，如下图所示：
  
• 用QXDM打开PCAP log，过滤出Ping包内容（在过滤栏输入icmp进行筛选）
  
• 在QCAT中输入0x11EB，过滤出数据包
  
• 找到Ping包的数据包，在过滤器中输入0xB870,确认MAC是否已经把数据包发出去（物理层log是二进制码流，需要从MAC确认，下图以NR为例）
  
• 如果基站侧收到了Ping Request，会在NR5G RLC DL Status PDU中返回ACK。
  
• 基站回复Ping Reply, 可以通过PDCP DL Data Pdu消息查看
  

3.4 如何将PCAP log中的ping信息和QCAT log相应信息对应起来

• 在PCAP log中，输入icmp过滤出Ping包信息，选择试图->时间显示格式->UTC时间，将时间显示格式设置和UE一样，下图以时延高为例：
  
• 找到此数据包Ping Request和Reply对应的Data内容，如下图所示
  
• 在QCAT log中过滤出消息，并找到与上面Data内容相同，且时间点对应的数据包（上图中，源IP为192.168.1.1， 服务器地址为192.168.1.4）
  
  

3.4 如何计算Ping消息在网络侧耗费的时间

• 按照3.3描述找到问题发生点Ping Request消息
  
• UE在SFN <112>发送了ping request消息,RLC SN=18。（Ping Request由应用侧发给协议栈后，首先进入PDCP，从NR5G PDCP UL States中能看到，Ping R equest属于数据业务，占用DRB资源，起对应的SN为18，进而通过查看NR5G L2 UL Data Pdu找出18所对应的SFN为112）
  
  
• 网络侧在SFN<117>，SN<18>上回复ACK，表示网络侧已经收到终端发起的Ping Request，这期间耗时：（117-112）*10=50ms
  
• 终端在SFN<129>上收到Ping Reply, 在网络侧耗时(129-117)*10=120ms。（如下图所示，从PCAP log中可以看到，Ping Reply的长度为60bytes，因此在PDCP DL Data Pdu中，找到60bytes对应的SFN，即为Ping Reply消息）
  
  
  综上：网络侧耗时为50+120=170ms。

对于时延问题，如果确认时延主要集中在网络侧，首先要排查无线环境，查看RSRP,SINR等参数，如果客户对时延要求比较严格，参照以往经验，RSRP应不低于-75dbm, SINR需稳定在30左右。其次，如果无线环境OK，则需要告知客户，非终端问题，需要网络侧进行分析，按照文中之前网络架构图中，排查各个节点，确认时延或者丢包发生在哪个网元。