PPP Drop导致的分组业务掉线分析与优化报告V2.9.docx

PPP Drop导致的分组业务掉线分析与优化报告珠海世纪鼎利通信科技有限公司2013-1-20目录1概述22背景介绍33PPP掉线机制43.1集团测试规范规定43.2软件判断机制44PPP连接原理64.1基本原理64.2PPP流程65PPP掉线场景分析（广州）95.1PPP掉线场景分类95.2PPP掉线主要场景验证95.2.1AN边界场景95.2.2异频边界场景115.2.3空口质差场景135.2.4SINR正常场景145.2.51X/DO互操作155.3PPP掉线分析结论156PPP掉线分析思路156.1逐层分析思路156.1.1AirLink层分析要点166.1.2PPP层分析要点176.2PPP掉线分析关键数据267PPP掉线全流程分析案例261 概述随着3G智能手机的普及以及越来越多的上网终端出现，3G用户数增速在考验着我们目前的3G网络。另外3G应用也在经历着一个爆炸式的增长，在这些应用的背后也需要3G网络提供一个强有力的支撑。种种迹象表明，目前我们网络已经进入一个移动互联网时代，3G网络的承载能力以及网络的健壮性都将是影响我们网络发展的决定性因素。在3G网络发展的同时，有些因素会对客户感知产生负面的影响，其中PPP掉线问题就是这些不良影响的一种。本文对PPP Drop导致的分组业务掉线进行分析，找出影响PPP Drop的关键因素，并给出相应的优化方案，提升3G用户感知。2 背景介绍广州9月和10月DT测试PPP掉线次数分别为14次和20次，PPP掉线率分别为1.54%和1.82%，PPP掉线指标较差。通过对PPP掉线LOG的分析，当PPP掉线伴随有空口掉线时，FTP上传业务和下载业务的速率几乎降低至0；当PPP掉线不伴随有空口掉线时，FTP下载业务的速率从1151kbps降低至837kbps，FTP上传业务的速率从526kbps降低至442kbps，严重影响用户感知。下图为当PPP掉线不伴随有空口掉线时，FTP上传/下载业务速率变化趋势：说明：PPP掉线前无空口掉线，横坐标代表时间，PPP掉线时刻的前20s和后40s；PPP掉线的时刻为20。下图为当PPP掉线伴随有空口掉线时，FTP上传/下载业务速率变化趋势：说明：PPP掉线前有空口掉线，横坐标代表时间，PPP掉线时刻的前40s和后40s；PPP掉线的时刻为40，空口掉线的时刻为31。3 PPP掉线机制3.1 集团测试规范规定PPP Drop判断准则：网络原因造成PPP拨号连接异常断开，判断依据为在测试终端主动释放拨号连接前的任何中断。需要判断AT侧还是PDSN侧终止了PPP连接，这个可以根据是哪里一侧发出Termination Request消息来判断。当DCE（PDSN）发出Termination Request消息时，说明PDSN中止了PPP连接。当DTE（AT）发出Termination Request消息时，说明AT中止了PPP连接。3.2 软件判断机制鼎利软件采集机制：在PPP拨号成功后，属于业务态的的阶段，任何在PPP Hangup之前的中断都判断为PPP异常断开，并记一次PPP掉线。PPP掉线是通过测试软件在进入业务态后监测Windows API接口程序，来判断PPP连接的状态，如果在没有达到测试时长时，PPP连接的任何中断都将导致软件判断为PPP掉线。正常业务流程如下：异常业务流程如下：通过对正常流程和异常流程的对比，我们发现在异常流程中缺少了正常流程的第三和第四个步骤。在业务开始后，还没有达到测试时长时，出现了PPP Dial Drop的情况引起测试中断，软件自动判定为一次PPP掉线，并在事件列表里插入一次PPP掉线标记。4 PPP连接原理4.1 基本原理用户终端与应用服务器之间端到端协议栈模型图如下图所示。PPP协议为点到点传输协议，位于终端与PDSN 之间。PPP（Point-to-Point Protocol点到点协议）是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。这种链路提供全双工操作，并按照顺序传递数据包。设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据，使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案。在前向，PDSN 将应用服务器侧的报文分装成PPP 格式的报文通过DO 网络发送给不同的终端；在反向，PDSN 将DO 网络上报的报文拆掉PPP 后还原成IP 报文路由到服务器上去。PPP 层涉及的网元包括PDSN 和终端，涉及的接口包括A10、A8、R-P 接口、Abis接口和空口。4.2 PPP流程PPP协议中提供了一整套方案来解决链路建立、维护、拆除、认证、上层协议协商等问题。PPP协议包含这样几个部分：链路控制协议LCP（Link Control Protocol）；网络控制协议NCP（Network Control Protocol）；认证协议，最常用的包括口令验证协议PAP（Password Authentication Protocol）和挑战握手验证协议CHAP（Challenge-Handshake Authentication Protocol）。一个典型的PPP链路建立过程分为三个阶段：创建阶段、认证阶段和网络协商阶段。阶段1：创建PPP链路LCP负责创建链路。在这个阶段，将对基本的通讯方式进行选择。链路两端设备通过LCP向对方发送配置信息报文（Configure Packets）。一旦一个配置成功信息包（Configure-Ack packet）被发送且被接收，就完成了交换，进入了LCP开启状态。应当注意，在链路创建阶段，只是对验证协议进行选择，用户验证将在第2阶段实现。阶段2：用户验证在这个阶段，客户端会将自己的身份发送给远端的接入服务器。该阶段使用一种安全验证方式避免第三方窃取数据或冒充远程客户接管与客户端的连接。在认证完成之前，禁止从认证阶段前进到网络层协议阶段。如果认证失败，认证者应该跃迁到链路终止阶段。在这一阶段里，只有链路控制协议、认证协议，和链路质量监视协议的packets是被允许的。在该阶段里接收到的其他的packets必须被静静的丢弃。最常用的认证协议有口令验证协议（PAP）和挑战握手验证协议（CHAP）。 阶段3：调用网络层协议认证阶段完成之后，PPP将调用在链路创建阶段（阶段1）选定的各种网络控制协议（NCP）。选定的NCP解决PPP链路之上的高层协议问题，例如，在该阶段IP控制协议（IPCP）可以向拨入用户分配动态地址。这样，经过三个阶段以后，一条完整的PPP链路就建立起来了，网络层的报文便可以在链路上进行传输。下图为一次PPP连接的典型流程图：A ： AT 和 PCF 建立空中链路。 B ： PCF 向 PDSN 发送 A11-Registration Request 信令，其中 lifetime 值不为 0 ，请求建立 A10 数据链路。C ： PDSN 成功响应 PCF 请求，向 PCF 回 A11-Registration Reply ，其中的 code 码为 0 。 D ： AT 和 PDSN 进行 PPP 协议的 LCP 阶段协商。 E ： LCP 协商成功后， PDSN 向 AT 发送 CHAP-Challenge 请求信令。 F ： AT 成功响应，向 PDSN 发送 CHAP-Response 信令。G ： PDSN 收到 CHAP-Response 信令后，就向 AAA 服务器发送 Radius Access Request 信令，到 AAA 对用户进行鉴权。 H ： AAA 鉴权成功，向 PDSN 发送 Radius Access Accept 信令。 I ： PDSN 收到 Radius Access Accept 信令后，向 AT 发送 CHAP Success 信令。 J ：鉴权成功后， AT 和 PDSN 进行 PPP 协议的 IPCP 阶段协商，为 AT 协商 IP 地址。 K ： IPCP 协商成功后， PDSN 向 AAA 发送 Radius Accounting Request 信令，其中 Acct-Status-Type 值为“ Start ”，开始计费。 L ： AAA 成功响应 PDSN 请求，向 PDSN 发送 Radius Accounting Reply 信令。 M ： AT 通过 PDSN 进行数据通信 在上述整个 PPP 链路建立过程中，与无线部分有关的仅仅是前三部分，也就是 AT 和 PCF 及 PDSN 建立空中链路这一过程。在这一过程完成后，基站、 PCF 等无线部分已经将用户终端与 PDSN 之间的链路建立完成，剩余的过程是终端与 PDSN 服务器进行业务及 PPP 协议协商的过程。5 PPP掉线场景分析（广州）5.1 PPP掉线场景分类月份PPP掉线总次数其中PPP掉线前空口掉线次数PPP掉线场景异频切换AN边界SINR正常空口质差1X/DO互操作9月上传93153009月下载540500010月上传940422110月下载1140343111月上传100010011月下载220200012月上传320111012月下载1000100合计411912012624个月共计41次PPP掉线，其中AN边界切换场景20次，占比48.78%；异频切换场景1次，占比2.44%；SINR良好场景12次，占比29.27%；空口质差场景6次，占比14.63%。1X/DO互操作2次，占比4.88%。41次PPP掉线前发生空口掉线有19次，广州4个月省测数据中共产生293次空口掉线，通过对空口掉线和PPP掉线的分析，空口掉线不是引起PPP掉线的必然因素。4个月的PPP掉线，其中FTP上传业务PPP掉线22次，FTP下载业务PPP掉线19次，说明PPP掉线和FTP业务类型不存在必然联系。5.2 PPP掉线主要场景验证5.2.1 AN边界场景 通过上面的分析，AN边界场景占PPP掉线类问题的49.28%，为此我们选取了AN边界对PPP掉线问题进行了多次验证测试。验证结果如下：日期时间点卡类型发起端发起阶段掉线原因12月20日12:40预付费DCELCPCHAP不成功12月20日12:47预付费DCELCPCHAP不成功1月4日12:36预付费DCELCPCHAP不成功1月5日11:11预付费DCELCPCHAP不成功1月5日11:14预付费DCELCPCHAP不成功1月5日11:20预付费DCELCPCHAP不成功1月14日11:42预付费DCELCPCHAP不成功1月14日11:57预付费DCELCPCHAP不成功1月14日14:48预付费DCELCPCHAP不成功1月14日14:57预付费DCELCPCHAP不成功1月14日15:07预付费DCELCPCHAP不成功1月14日15:18预付费DCELCPCHAP不成功1月14日15:28预付费DCELCPCHAP不成功通过对AN边界场景进行验证，该场景确实存在PPP掉线问题，并且该场景掉线机率比其他场景要大。通过对AN边界PPP掉线问题进行验证，我们发现在该场景下PPP掉线主要是因为在CHAP阶段不成功导致。具体分析定位如下：从空口抓包的数据来看，在掉线前DCE向DTE发起过Configuration Request消息，要求对PPP进行重新配置。如下图：结合整个流程来看，本次PPP重配置是由于AT跨AN切换导致，在跨AN切换时，PDSN发起了LCP重配置的要求，从空口抓包数据可以看出LCP阶段是正常的，问题出现在鉴权阶段。我们可以看到鉴权过程只有Challenge阶段和Response阶段，PSDN并没有回复成功消息，而是直接回复了Termination Request拆除PPP连接。这一点对比下图的正常的CHAP流程可以看出。根据核心网提供的PDSN的信令跟踪结果也可以验证是PDSN发起的Termination Request消和Registration Update消息。PDSN的信令如下：从PDSN侧信令跟踪来看，PDSN与AAA之间接入请求是正常的，即PDSN向AAA发送了Access-Request消息，AAA也给PDSN回复了Access-Accept消息，但是PDSN没有给AT下发Chap Success消息，而是直接下发了Term-Req消息，导致PPP拆线。5.2.2 异频边界场景验证一、未打开异频切换地点：南村电缆厂至石基金山路段验证结果：异频边界未打开异频开关情况下不会导致PPP掉线现场测试结果如下：AT占用南村电缆厂-D-1起呼，起呼时占用78频点，随着车辆移动经过单载波基站石基金山-D未发生切换，无线信号差,SINR=-17，测试中存在空口掉线问题，此原因由于DO载波站点未打开硬切换开关导致与37频点未能切换。验证结果显示在未打开异频切换的载波边界也不会导致PPP掉线。验证二、打开异频切换地点：复苏村至化龙草堂路段验证结果：异频边界打开异频开关情况下不会导致PPP掉线现场测试结果如下：测试前打开异频切换复苏村-D-L-2的异频开关，添加异频邻区，脚本如下：MOD DOPHOALG: CN=1112, SCTID=2, CRRID=11, OFSDOHHOSW=ON;ADD NBRCDMACH: CCDMACH=1112-1112-2-78, TYP=EVDO, NBRCDMACHS=861-861-861-0-37, SFFLAG=SINGLE, DFFLAG=SINGLE, NBFLAG=SINGLE;ADD NBRCDMACH: CCDMACH=1112-1112-2-78, TYP=EVDO, NBRCDMACHS=861-861-861-2-37, SFFLAG=SINGLE, DFFLAG=SINGLE, NBFLAG=SINGLE;终端占用复苏村-D-L-2扇区78频点PN494起呼，然后向华龙草堂方向行驶，在行驶过程中终端能够顺利切换到化龙草堂-高危_节点-D-L-0扇区37频点PN78，并未发生空口掉线。在测试中也没有出现PPP掉线问题。5.2.3 空口质差场景验证一、室内弱覆盖地点：滨江东路 丰盈居地下车库验证结果：室内弱覆盖问题不会导致PPP掉线现场测试结果如下：10:14:23时刻在地下车库室外拨号成功，FTP开始下载业务，然后走入地下车库，模拟信号有好变差的过程。从测试现场的情况看，随着进入车库的距离增大，信号逐步变差，在10:16:53，完全进入车库，终端也由DO成功切换到1X上。如下图：本次切换是终端在DO网络上进入休眠后的切换，从这个场景可以验证，在无线环境变差的情况下，终端经历了从激活态到休眠态再到1X网络的过程，这些行为均没有导致PPP掉线。验证二、室外弱覆盖地点：海珠仑头至大学城路段验证结果：室外弱覆盖问题不会导致PPP掉线现场测试结果如下：从上图看在15:51:27时刻PPP拨号成功，开始做下载业务，在15:52:01时刻出现Out Of Service，软件自动中断业务释放PPP，也没有出现PPP掉线的情况。本次测试从拨号开始至业务终端无线环境均不是很好，中间还存在空口掉线问题，这些问题最终也没有导致PPP掉线。5.2.4 SINR正常场景 在对PPP掉线的分析过程中，有一部分PPP掉线前空口质量良好，跟华为工程师确认也不存在AN内跨PCF切换问题，这类场景明显跟无线环境没有关系。5.2.5 1X/DO互操作在4个月的测试中互操作问题共出现2次，这类问题可以通过关闭测试语音和短信功能，对终端进行强制锁网测试等手段规避，因此没有对该类问题进行验证。5.3 PPP掉线分析结论根据PPP掉线验证的结论，和我们对4个月的PPP掉线数据的分析，我们得到如下结论：1空口质差：通过对空口质差区域PPP掉线验证的结果来看，在空口质量较差的情况下也不不会引起PPP导线，并且在通过对4个月的空口质差点分析，PPP掉线与空口质差点也不存在必然联系。月份空口质差点空口质差PPP掉线次数9月上传17109月下载153010月上传729210月下载763311月上传87011月下载111012月上传121112月下载520空口质差点：连续5s内SINR-6.5db的点。2AN边界： AN间切换问题导致的PPP掉线目前可以定位到是由PDSN发起，通过空口抓包数据可以判断在PPP重协商的CHAP阶段失败，PDSN释放PPP连接。目前跨AN切换引起的48.78%的PPP掉线需要核心侧进行协助处理，单从无线侧无法解决。3.SINR正常：对于该类问题，仅从测试数据分析，我们无法判断该类问题出现的原因。由于掉线前空口质量良好，可以判断此类PPP掉线跟无线侧没有必然联系。4.异频切换：对异频切换场景的验证结果显示在异频边界不存在PPP掉线问题，并且通过4个月的测试数据分析，4个月中只出现过1次该场景的PPP掉线问题。因此PPP掉线与异频边界也不存在必然的联系。6 PPP掉线分析思路6.1 逐层分析思路 基于移动互联网的PPP掉线分析必须对DO网络进行逐层分析，由面到点，只有这种分析方式才能快速定位出PPP掉线中的相关问题。下面主要针对AirLink层和PPP层进行分析。6.1.1 AirLink层分析要点AirLink层也就是我们通常所说的空口，在端到端网络结构中，该层位于AT和BTS之间。由于该层位于DO网络协议的最底层，因此，空口质量的好坏对DO网络的PPP掉线也有直接的影响。对于AirLink层的处理流程图如下当PPP掉线发生在如下的场景时，我们就需要对AirLink层进行分析，判断出空口的某些状态和行为是否对PPP连接产生影响。1) AT是否处于多载波边界，如果在多载波边界出现信号差，则可能导致AT初始化引起PPP掉线问题。2) AT是否处于AN边界，如果AT处于AN边界，并且AN边界信号差，存在乒乓切换或者多AN边界，AN间切换频繁的情况，则会导致PCF与PDSN之间有频繁地切换发生，引起释放PPP连接。3) AT处于DO覆盖边界或者处于快衰落区域，此时可能会触发DO向1X网络的互操作，引起PPP连接异常，而拆除PPP连接。4) AT处于连续的DO弱覆盖区，此时AT可能会产生空口掉线问题，也可能导致AirLink层异常。 以上无线问题会引起PPP阶段的重配置，在重配置的过程中，如果存在某些流程异常就会导致AT与PDSN之间的协商失败，进而引发PPP掉线。验证数据表明这些情况只是PPP掉线的一个诱因，并不是导致PPP掉线的根本原因。6.1.2 PPP层分析要点在AirLink层的问题得到排除后，我们就要对PPP掉线进出入关键环节的分析，即PPP层的问题分析，PPP协议层的两个对端为AT和PDSN。在端到端网络结构中，PPP层承担了AT与PDSN之间的通信，除去前面两节提到的BTS和AN网元外，在该层还会涉及到另外两个网元，也就是PCF和PDSN。 由于AirLink层已经在上面做了分析，在此重点介绍AN与PCF之间的A8/A9链路，PCF与PDSN之间的A10/A11链路的交互过程，以及AT与PDSN之间的交互过程。对于PPP层的处理流程图如下： A8/A9与A10/A11链路状态分析在完成了AriLink层和RLP层相关的通讯后，还需要建立相关的A8/A9与A10/A11链路才能保障PPP层的正常通讯，A8/A9与A10/A11链路在以下三个流程中会遇到。i. PPP拨号阶段A8/A10建立过程ii. PDSN释放PPP连接的过程BSC跟踪信令：iii. 跨AN切换A8/A10释放和连接过程 在上面的三个流程中，都涉及到A8/A10链路的建立和释放，通过对PPP掉线问题的分析，在A8建立和释放阶段没有出现问题，在A10建建立和释放过程中有时候会存在异常。那么A10建立过程中异常问题分析如下： 问题分析判断问题出现的阶段，由于A10建立和释放的三个阶段在上面的章节已经给出，那么我们根据A10连接在不同阶段的流程，判断出A10在建立的过程中是否存在异常。进而找到处理方法。如下图从上图看，registration request消息发送了两次，但PDSN只回复了一次，并且在此后不久就释放了A8，因此判断此次A10连接建立存在问题。 问题定位通过对对PDSN的回复Reply消息可以看出在PDSN回复的Reply消息中携带了reason-unspecified，导致本次A10建立失败。如下图： 处理方法 在处理这类问题的时候，我们首先关注流程是否正常，其次我们再对每个消息的原因值进行分析。流程的匹配我们可以根据上面的流程进行分析，在原因值的分析上我们要重点关注A11-Registration Reply消息中的ucCode。下图给出了ucCode的常见原因值此类原因的分析，因为涉及到PDSN侧，我们需要核心网工程师来协助解决。 PPP链路状态分析 AT与PDSN之间的交互，在PPP建立或者PPP层重配置的过程中AT与PDSN之间都要进行相关配置协商，这些过程包括LCP阶段的配置协商，CHAP阶段的鉴权认证，IPCP阶段的配置协商。如果这三个阶段均为问题接下来就可以进入数据传输阶段，也就是可以进行正常的业务状态。 三个阶段流程图三个阶段抓包图(一) LCP阶段LCP负责创建链路。在这个阶段，将对基本的通讯方式进行选择。链路两端设备通过LCP向对方发送配置信息报文（Configure Packets）。一旦一个配置成功信息包（Configure-Ack packet）被发送且被接收，就完成了交换，进入了LCP开启状态。问题分析： 在LCP阶段正常的流程都是Configure-Request与Configure-Ack消息成对出现，消息的双方对配置参数进行协商的过程。如下图： 在以上流程中，如果存在以下2种情况我们即认为LCP协商失败，并且可能会导致PPP连接中断，引起掉线。1、 PDSN侧回复Configure-Nak消息。2、 PDSN侧回复Configure-Reject消息。当PDSN回复Configure-Ack以外的其中任何一种消息时，我们就可以判断在AT与PDSN的交互中存在某些参数不被认可或者不被认知。在LCP协商阶段, MS和PDSN之间会协商如下参数（Configure-Request消息携带）:Maximum Receive Unit (MRU) 最大接收单元Asynchronism Control Code Mapping (ACCM) 异步控制字Authentication protocol鉴权协议类型Magic number魔术字Protocol compression协议压缩Address control compression地址控制压缩如果其中任意一个参数协商失败, 都会导致LCP阶段协商失败。问题定位:1、 通过采用不同的终端进行测试验证排除AT问题。2、 如果不同的终端均有此类问题，问题就出在PDSN侧。问题处理：如是AT问题，更换AT即可，如不是AT问题，核心网工程师对该阶段的问题进行分析处理。(二) CHAP阶段在这个阶段，客户端会将自己的身份发送给远端的接入服务器。该阶段使用一种安全验证方式避免第三方窃取数据或冒充远程客户接管与客户端的连接。在认证完成之前，禁止从认证阶段前进到网络层协议阶段。如果认证失败，认证者应该跃迁到链路终止阶段。问题分析:CHAP过程主要涉及的网元为AT、PDSN、AAA，在PDSN发起CHAP Chellenage以后AT会回复CHAP Response消息，在PDSN收到CHAP Response后，会向AAA发送Access Request消息，如果AAA通过本次接入请求，则下发Access Accept消息给PDSN，PDSN收到该消息后发送CHAP Success消息给AT，此时一次完整的CHAP流程结束。如下图： 根据上面的流程分析，在CHAP阶段可能出现问题的阶段有4处，下面对每一处可能存在的问题进行分析问题1、AT没有响应PDSN的CHAP Chellenage消息。问题2、PDSN没有发送Access Request消息。问题3、PDSN没有收到Access Accept消息。问题4、PDSN没有发送CHAP Success消息。 问题定位:问题1原因定位： AT不对某些CHAP Chellenage参数不认可，导致AT不发送CHAP Response消息。 无线侧上行链路质量差，导致CHAP Response发送失败。问题2原因定位：u PDSN没有收到AT发送的CHAP Response消息。u PDSN侧异常导致没有发出Access Request消息。u PDSN与AAA之间的链路存在异常。问题3原因定位：l PDSN发出Access Request消息携带的某些属性异常，导致AAA拒绝此次接入。l PDSN与AAA之间的链路存在异常。问题4原因定位： PDSN没有收到AAA发送的Access Accept消息。 PDSN收到的Access Accept消息携带的某些属性异常。 无线下线链路存在异常，导致系统下发的CHAP Success消息没被收到。问题处理:无线侧问题：建议对PPP掉线区域的无线进行RF优化或者参数优化改善空口质量。核心侧问题：建议核心网工程师对相关的PDSN与AAA的交互信令进行分析。(三) IPCP阶段认证阶段完成之后，PPP将调用在链路创建阶段（LCP阶段）选定的各种网络控制协议（NCP）。选定的NCP解决PPP链路之上的高层协议问题，在该阶段IP控制协议（IPCP）可以向拨入用户分配动态地址。问题分析： 与LCP阶段类似，在IPCP阶段正常的流程都是Configure-Request与Configure-Ack消息成对出现，消息的双方对配置参数进行协商的过程。如下图： 在以上流程中，如果存在以下2种情况我们即认为IPCP协商失败，并且可能会导致PPP连接中断，引起掉线。1、 PDSN侧回复Configure-Nak消息。2、 PDSN侧回复Configure-Reject消息。当PDSN回复Configure-Ack以外的其中任何一种消息时，我们就可以判断在AT与PDSN的交互中存在某些参数不被认可或者不被认知，这种情况下就容易导致PPP失败。 在IPCP阶段AT与PDSN之间会协商如下信息：1. 协商终端IP地址。2. 协商主用和备用DNS服务器。3. 协商TCP/IP头压缩方式. 问题定位：1、 通过采用不同的终端进行测试验证排除AT问题。2、 如果不同的终端均有此类问题，问题就出在PDSN侧。问题处理： 如是AT问题，更换AT即可，如不是AT问题，核心网工程师对该阶段的问题进行分析处理。 6.2 PPP掉线分析关键数据由于PPP掉线需要端到端的分析，因此在判断PPP掉线的时候，我们必须有足够多的数据才能够保障对PPP掉线的全流程分析。那么在一次完整的PPP分析流程中，我们至少需要获取到以下数据：1、测试LOG，借助测试LOG分析AT的空口质量和AT在掉线前的一些行为。从而判断无线环境是否正常，并判断出AT是否存在问题。2、空口抓包数据，借助空口抓包数据，我们可以分析出PPP掉线是在哪个阶段出现了问题，如LCP阶段、CHAP阶段、IPCP阶段等。从而可以指导我们对出现的问题进步一步分析。3、B侧跟踪信令，结合B侧的跟踪信令我们可以判断出AT于PCF的交互是否存在异常，也可以判断出PCF与PSDN之间的信令是否正常。4、PDSN侧的跟踪信令，结合PDSN与AAA之间的信令以及PDSN与PCF之间的信令我们可以一进步判断问题是否出现在核心侧，从而让核心侧工程师协助解决。5、其他信息收集，由于端到端的分析涉及到的因素在上面我们都做了分析，那么除了上述因素外，我们还需要对如下的信息进行分析： 测试卡类型，如果MS是一个预付费用户, 需要检查如下2点:A. AAA是否支持预付费.B. MS是否还有可用余额. PDSN配置中,IP资源池是否可用，如果IP资源池使用门限超过设定最大值，则可能导致在IPC