电信FDD-LTE案例集

1、服务器使用人数多无法满调度下载（FDD）

【现象描述】

LTE-FDD新建站项目单验阶段，在FDD-LTE单站验证过程中，出现RSRP约为-70dBm左右，SINR为25-30dB,下行速率只有88-89Mbps,且稳定在该数值范围内，无法达到下行90Mbps以上，影响单站验证的进度和效率。

【告警信息】

无

【原因分析】

由于每天新开站均比较多，每天都会有多组人员同时进行单站验证工作，同时由于每个地市服务器资源有限，且电信、移动开站进度类似，单验和簇优化同时进行，导致服务器使用时间集中。由于LTE网络下行上行速率均比较大，导致在多组人员同时测试情况下，服务器不稳定。

【处理过程】

1、检查发现，测试电脑可以满足测试要求，下载上传均正常，不存在电脑故障。

2、测试终端能力为CAT3，满足测试要求，测试终端未连续使用过长时间，可以达到88-89Mbps下载速度，不存在吊死情况。

3、服务使用客户提供的服务器，下载地址和端口均正常，且是十线程下载。

4、测试地点位于站点下近点好点，RSRP在-70dBm左右，SINR在25左右，且换至其他好点，下载速度仍然不能超过90Mbps。

5、下载测试速率软件DU Meter经过和Probe自带速度统计对比显示，DU Meter速率显示正常。

6、开启2组FileZilla Client下载软件，选择2组相同下载路径，在指定服务器内下载，发现下载速度改善不明显，不能达到验收要求，于是选择2组不同路径下载，即一组服务器在下载路径进行下载，另一组再上传路径里进行下载，如下图，发现速率由88-89Mbps提升至96-100Mbps，问题得以解决。

【建议与总结】

在新建网络单验和簇优化阶段，由于很多人同时集中同时使用服务器进行下载，导致服务器下载目录，造成用户无法从服务器下载目录里获得满RB的调度，导致形成非网络原因的速率无法达到峰值，造成单验时找点困难，速率达标困难等，通过同时开启2组FileZilla Client下载软件进行下载，一组在下载目录里进行下载，以获取绝大部分的RB调度，同时由于使用下载目录的人比较多，基本上下载目录调度不满。另一组FileZilla Client下载软件在上传目录里选择文件进行下载，由于使用上传目录下载的人很少，基本上可以和第一组FileZilla Client下载软件形成互补，从而保证整个下载过程基本上都是950以上的调度次数，从而可以达到下载速率提升且稳定的目的。

2、多用户测试上传服务器中断线程问题（FDD）

【现象描述】

该问题发生于单站验证和拉网测试等过程中的上传测试，测试网络为LTE试验网；测试要求同时上传线程为10个，以达到测试网络的峰值速率；当多用户（两个及以上）在服务器同样路径下，上传相同文件名的文件时，服务器会拒绝后接入者请求，断开此上传线程，导致在较好的RSRP，SINR条件下，上传调度数不足，速率达不到理想值。

【告警信息】

下图1为FTP软件问题告警信息：

图 1

红色标注部分为中断线程提示，但是在多文件上传时，并不容易关注到这个告警提示。

【原因分析】

该问题常出现在单站验证和拉网测试等过程中的上传测试过程中，一般测试要求指定路径及上传的标准文件名，相同文件名的实现覆盖，目的是便于服务器管理，以免服务器文件过多，浪费容量。图2为测试时常见的覆盖选项：

图 2

服务器端及本地端文件及路径如图3和图4所示：

图 3

图 4

但是当多个测试队伍进行相同文件名文件上传测试时，服务器并不支持多用户对相同路径，相同文件名的文件进行写操作，而测试要求则要求指定目录，指定标准文件名，这时候就会冲突，中断第一个用户之外的其他用户该线程。由于上传测试时，上传线程为10个，且测试人员并不容易关注到某个线程被中断，导致在测试RSRP,SINR指标较好时，调度数不足（L网测试中调度数应接近1000或者保持1000），速率未达到峰值，影响测试结果。

【处理过程】

发现此问题后，和同事多次测试验证，都得到相同结果，且结合之前的测试实践，尝试改变文件名或者上传文件路径，均可以解决这个问题，即在相同目录下，服务器支持多用户对多文件同时进行写操作，也支持不同文件路径下相同文件名的多用户写操作。

【建议与总结】

结合测试实践和实验，针对之后的多用户网络上传测试，建议：

1、在用户有创建和删除服务器文件路径的权限情况下，可在做上传测试时，每次创建独立文件目录作为上传路径，在测试完成后，及时删除所创建的文件目录；

2、如果用户没有创建和删除服务器文件目录时，项目可允许测试工程师（用户）上传不同文件名文件，命名方式参照标准文件名，如标准文件为1G_01，则每个测试工程师可加后缀，如1G_01_测试工程师姓名缩写。上传测试完成后，及时删除文件。

3、同时，测试工程师需要关注FTP上传过程中上传失败提示，包括命令窗口提示文件传输

结果提示和Probe参数中上行调度参数，及时调整，以免对测试结果造成影响。通过以上方式，既可以避免因为上传问题导致的对测试结果的影响，又可以提高服务器存储空间的利用，方便测试服务器的管理。

3、IBLER误码率高导致下行速率低（FDD）

【现象描述】

带宽为20M，CAT3测试终端，东门电信宿舍站1小区下载速率只能达到60M左右，不能达到90M以上。

【告警信息】

无

【原因分析】

1、查看选点是否存在问题。RSRP>-80dB，SINR>25dBm，选点不存在问题。

2、调度次数PDCCH DL Grant Count维持在950以上，满足要求。

3、RB number也在90以上，满足要求，后台只有一个用户。

4、MCS阶数的判断：已达到最高阶数28阶。

5、基站参数排查，发现存在问题站的参数和正常站的参数配置一致。

6、后台灌包，验证灌包操作，下载速率能够达到90M以上，排除传输问题7、判断IBLER是否偏高：测试要求在峰值区域，误码率需要为或很小，而现在误码率持续在10%左右，偏高，根据前台测试软件显示如下图红色区域所示：

【处理过程】

由于该选点的误码较大，所以必须要满足IBLER保持在左右，重新选点后点后下载速率达到90M以上，因此确认第一次选点的局部区域存在外部干扰。

【建议与总结】

1、在定位业务速率问题时，经过基本参数及告警排查，且排除TCP类问题时，可以根据问题具体现象做进一步定位，吞吐率问题可以概括为如下四个现象：调度次数不足、调度RB数不足、MCS阶数偏低及IBLER不收敛。

2、总的来说，要先确定问题现象后，然后根据不同的问题现象采取不同的步骤进行定位。

4、单站做ping业务发现ping值过高（FDD）

【现象描述】

该问题发生于单站验证（SSV），问题发生时软件使用情况为:Genex Probe 3.5；测试网络为LTE试验网；测试要求ping值低于30以下，以达到较低的网络时延。测试中发现RSRP、SINR值都是达标，比较好的，但是ping值却很高（高于30，甚至达到100多）。

【告警信息】

无

【原因分析】

由上述分析可知道，此问题出现在单站验证（SSV）。在测试的时候发现RSRP、SINR值都是比较好的，但是ping值却很高，这时候我们发现停掉业务重新做ping业务的时候发现仍是这样，针对这个问题我们从以下几个方面分析。

1、核查做ping业务时候，是ping服务器还是外网，如果ping外网经过网关较多，需要重新选择ping服务器，这样可以减少ping业务时的路由，从而满足ping值低于30ms。

2、发现该问题首先后台做ping业务，发现设备ping服务器是正常的，如下图所示：

上图显示证明终端-基站-核心网-服务器该路由ping时延是正常的，因此排除路由时延问题。

3、查看之前做上传下载时FTP是否仍然在上传或下载大文件，因为FTP在上传或下载大文件的时候，做ping业务，会发现ping值很高，有时候在单站验证时，由于个人原因，忘记停掉FTP了，然后做ping业务，发现ping值很高，排除人为操作原因导致测试不达标。

4、由于软件不知明原因，做ping业务时ping值可能会呈现较高状态，此时需要关闭软件重新打开，等待一段时间后再做ping业务。

5、周围环境原因也可导致ping很高，此时需要重新换一个或多个位置，重新做ping业务。

【处理过程】

按照原因分析步骤一一核查，发现是点位选择问题，重新选择点位后发现ping值低于30ms，正常。

【建议与总结】

结合测试实践和实验，针对之后的单站验证ping业务测试，建议：测试之前先检查FTP中是否有大文件上传或下载，再进行测试，如若ping值仍然很高，首先后台做ping业务，确保ping传输通路是正常的，然后建议换一个或多个测试位置，或者关闭软件，过一段时间重新打开，再进行ping业务测试。

5、核心网未配TAC导致Attach业务失败（FDD）

【现象描述】

LTE-FDD新建站项目，带宽为20M，在单验的过程中，新建站初期，同一天出现部分站点存在Mobile Partner不显示有信号，但连上测试软件Probe后，无线参数显示正常，如图左侧红色区域所示，但是却无法连接到LTE网络，如下图底部红色区域显示：

【告警信息】

无

【原因分析】

1、由于之前有站点单验均可成功接入网络，因此怀疑是终端的问题，检查终端设置发现没有解决问题，更换测试电脑也没有解决问题，终端在其他站点验证能够正常接入，因此排除终端的问题。

2、怀疑数据卡的问题，用测试同一SIM验证其他站点发现能够正常接入网络，排除SIM卡的问题。

3、怀疑基站配置问题，导出基站配置文件导进行核查，发现配置的TAC值与规划值是一致的，核查其他参数，也未发现异常。

4、将前台的测试Log分析后，在L3信令中发现RRC连接建立、鉴权、加密成功，而Attach被拒绝，原因值为：network failure。

双击Attach Reject的信令解析为：

5、Attach reject的消息是由核心网直接透传给UE的，eNodeB不会处理这条消息，所以怀疑核心网侧出现问题，将出现此现象的站TAC和核心网侧确认是否添加。核查后发现核心网漏配了一部分站点的TAC,与核心网确认重新配置TAC后。

【处理过程】

由于核心网属于异厂家，与核心网侧确认，发现的确漏配部分TAC，待核心网将漏配TAC添加后，再次验证,配置成功显示结果如下图所示：

TAC配置成功后，终端能够成功接入网络，如图红色区域信号所示：

【建议与总结】

在新建网络中，比较容易出现核心网漏配TAC而导致不能接入网络的现象，特别在无线和核心网属于异厂家设备上的情况下，一定要确保TAC的添加，不然容易造成人力物力的浪费。新建站中如果出现不能接入网络在发现Attach reject消息时，能看到拒绝原因，一般处理情况为如下：

1、首先查看是否硬件存在问题，终端、PC机。

2、查看SIM卡是否存在异常以及开户是否有问题。

3、查看信令，出现network failure都是和核心网相关，直接找核心网侧确认。

6、天馈系统接口问题导致上传速率低（FDD）

【现象描述】

测试网络为LTE试验网，该问题发生于单站验证定海金塘沥港联通站，单站单小区测试时，测试中发现RSRP、SINR值都是达标，下载速率也比达标，但是在做上传业务时，上传速率在30M左右，不能达到40M以上。

【告警信息】

无

【原因分析】

在测试的时候发现RSRP、SINR值都是比较好的，但是上传速率不达标，这时候我们发现停掉业务重新做上传业务的时候发现仍然这样，针对这个问题我们从以下几个方面分析。

1、查看FTP服务器是否10线层上传，如果做FTP业务时，不是满线程做业务，达不到高速率。

2、考了软件和测试终端会影响速率，这时候我们就要关闭软件，重启电脑后再重新打开软件，再重新做上传业务。

3、怀疑可能是周围环境原因导致上传速率较低，这时候我们就要重新换一个或多个位置，重新测上传业务。

4、是否其他测试组单站测试均出现同样问题。

5、通过灌包测试，检测传输是否存在问题。

6、后台跟踪RSSI查看是否有干扰导致速率较低。

【处理过程】

按照原因分析里面的步骤，首先确认都是满线程做上传和下载业务，设备重启以及重新选点后测试上传速率仍然较低，其他单站测试组未发现该问题，通过上行灌包发现，上行灌包速率能够达到40M以上，排除传输问题，最后跟踪RSSI时发现，空载时RSSI正常，但是加载后RSSI较高，如下两图所示：

图1 空载时RSSI跟踪值

图2 加载时RSSI跟踪值

所以判断为天馈系统接口问题导致上传速率较低，最后经过施工队对天馈接口的重新处理后，重新测试上传速率恢复40M以上。

【建议与总结】

在做单站验证业务时，首先保证设备、操作方法以及选点准确，另外需要排查传输是否正常，以上信息准确后，通过后台跟踪干扰检测，定位速率问题。结合测试实践和实验，针对之后的单站验证上传业务测试出现不达标时，建议按照原因分析里面的步骤逐步排除分析问题即可。