电信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以上。

【建议与总结】

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180307A04KQ500?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券