全行业优质文档下载与分享平台
欢迎来到万可派!
帮助中心

FDD-TE案例解析-常见问题

上传人:老白 IP属地:西安 文档编号:5613015 上传时间:2024-08-07 格式:DOCX 页数:15 大小:2.42MB
收藏 版权申诉 举报 下载
FDD-TE案例解析-常见问题_第1页
第1页 / 共15页
FDD-TE案例解析-常见问题_第2页
第2页 / 共15页
FDD-TE案例解析-常见问题_第3页
第3页 / 共15页
FDD-TE案例解析-常见问题_第4页
第4页 / 共15页
FDD-TE案例解析-常见问题_第5页
第5页 / 共15页
本文描述:

《FDD-TE案例解析-常见问题》由西安网友“老白”于2024年08月07日分享,文档编号为5613015,全文共计15页,更多相关《FDD-TE案例解析-常见问题(DOCX珍藏版)》请在万可派上搜索。

1、电信LTE案例解析集1、服务器使用人数多无法满调度下载【产品族】LTE FDD【现象描述】LTE-FDD新建站项目单验阶段,在FDD-LTE单站验证过程中,出现RSRP约为-70dBm左右,SINR为25-30dB,下行速率只有88-89Mbps,且稳定在该数值范围,无法达到下行90Mbps以上,影响单站验证的进度和效率。【告警信息】无【原因分析】由于每天新开站均比较多,每天都会有多组人员同时进行单站验证工作,同时由于每个地市服务器资源有限,且电信、移动开站进度类似,单验和簇优化同时进行,导致服务器使用时间集中。由于LTE网络下行上行速率均比较大,导致在多组人员同时测试情况下,服务器不稳定。【

2、处理过程】1、 检查发现,测试电脑可以满足测试要求,下载上传均正常,不存在电脑故障。2、 测试终端能力为CAT3,满足测试要求,测试终端未连续使用过长时间,可以达到88-89Mbps下载速度,不存在吊死情况。3、 服务使用客户提供的服务器,下载地址和端口均正常,且是十线程下载。4、 测试地点位于站点下近点好点,RSRP在-70dBm左右,SINR在25左右,且换至其他好点,下载速度仍然不能超过90Mbps。5、 下载测试速率软件DU Meter经过和Probe自带速度统计对比显示,DU Meter速率显示正常。6、 开启2组FileZilla Client下载软件,选择2组相同下载路径,在指定

3、服务器内下载,发现下载速度改善不明显,不能达到验收要求,于是选择2组不同路径下载,即一组服务器在下载路径进行下载,另一组再上传路径里进行下载,如下图,发现速率由88-89Mbps提升至96-100Mbps,问题得以解决。【建议与总结】在新建网络单验和簇优化阶段,由于很多人同时集中同时使用服务器进行下载,导致服务器下载目录,造成用户无法从服务器下载目录里获得满RB的调度,导致形成非网络原因的速率无法达到峰值,造成单验时找点困难,速率达标困难等,通过同时开启2组FileZilla Client下载软件进行下载,一组在下载目录里进行下载,以获取绝大部分的RB调度,同时由于使用下载目录的人比较多,基本

4、上下载目录调度不满。另一组FileZilla Client下载软件在上传目录里选择文件进行下载,由于使用上传目录下载的人很少,基本上可以和第一组FileZilla Client下载软件形成互补,从而保证整个下载过程基本上都是950以上的调度次数,从而可以达到下载速率提升且稳定的目的。2、多用户测试上传服务器中断线程问题【产品族】LTE FDD【现象描述】该问题发生于单站验证和拉网测试等过程中的上传测试,测试网络为LTE试验网;测试要求同时上传线程为10个,以达到测试网络的峰值速率;当多用户(两个及以上)在服务器同样路径下,上传相同文件名的文件时,服务器会拒绝后接入者请求,断开此上传线程,导致在

5、较好的RSRP,SINR条件下,上传调度数不足,速率达不到理想值。【告警信息】下图1为FTP软件问题告警信息:图 1红色标注部分为中断线程提示,但是在多文件上传时,并不容易关注到这个告警提示。【原因分析】该问题常出现在单站验证和拉网测试等过程中的上传测试过程中,一般测试要求指定路径及上传的标准文件名,相同文件名的实现覆盖,目的是便于服务器管理,以免服务器文件过多,浪费容量。图2为测试时常见的覆盖选项:图 2服务器端及本地端文件及路径如图3和图4所示:图 3图 4但是当多个测试队伍进行相同文件名文件上传测试时,服务器并不支持多用户对相同路径,相同文件名的文件进行写操作,而测试要求则要求指定目录,

6、指定标准文件名,这时候就会冲突,中断第一个用户之外的其他用户该线程。由于上传测试时,上传线程为10个,且测试人员并不容易关注到某个线程被中断,导致在测试RSRP,SINR指标较好时,调度数不足(L网测试中调度数应接近1000或者保持1000),速率未达到峰值,影响测试结果。【处理过程】发现此问题后,和同事多次测试验证,都得到相同结果,且结合之前的测试实践,尝试改变文件名或者上传文件路径,均可以解决这个问题,即在相同目录下,服务器支持多用户对多文件同时进行写操作,也支持不同文件路径下相同文件名的多用户写操作。【建议与总结】结合测试实践和实验,针对之后的多用户网络上传测试,建议:1、 在用户有创建

7、和删除服务器文件路径的权限情况下,可在做上传测试时,每次创建独立文件目录作为上传路径,在测试完成后,及时删除所创建的文件目录;2、 如果用户没有创建和删除服务器文件目录时,项目可允许测试工程师(用户)上传不同文件名文件,命名方式参照标准文件名,如标准文件为1G_01,则每个测试工程师可加后缀,如1G_01_测试工程师姓名缩写。上传测试完成后,及时删除文件。3、 同时,测试工程师需要关注FTP上传过程中上传失败提示,包括命令窗口提示文件传输 结果提示和Probe参数中上行调度参数,及时调整,以免对测试结果造成影响。通过以上方式,既可以避免因为上传问题导致的对测试结果的影响,又可以提高服务器存储空

8、间的利用,方便测试服务器的管理。3、IBLER误码率高导致下行速率低【产品族】LTE FDD【现象描述】带宽为20M,CAT3测试终端,东门电信宿舍站1小区下载速率只能达到60M左右,不能达到90M以上。【告警信息】无【原因分析】1、 查看选点是否存在问题。RSRP-80dB,SINR25dBm,选点不存在问题。2、 调度次数PDCCH DL Grant Count维持在950以上,满足要求。3、 RB number也在90以上,满足要求,后台只有一个用户。4、MCS阶数的判断:已达到最高阶数28阶。4、 基站参数排查,发现存在问题站的参数和正常站的参数配置一致。5、 后台灌包,验证灌包操作,

9、下载速率能够达到90M以上,排除传输问题6、 判断IBLER是否偏高:测试要求在峰值区域,误码率需要为0或很小,而现在误码率持续在10%左右,偏高,根据前台测试软件显示如下图红色区域所示:【处理过程】由于该选点的误码较大,所以必须要满足IBLER保持在0左右,重新选点后点后下载速率达到90M以上,因此确认第一次选点的局部区域存在外部干扰。【建议与总结】1、 在定位业务速率问题时,经过基本参数及告警排查,且排除TCP类问题时,可以根据问题具体现象做进一步定位,吞吐率问题可以概括为如下四个现象:调度次数不足、调度RB数不足、MCS阶数偏低及IBLER不收敛。 2、 总的来说,要先确定问题现象后,然

10、后根据不同的问题现象采取不同的步骤进行定位。 4、单站做ping业务发现ping值过高【产品族】LTE FDD【现象描述】该问题发生于单站验证(SSV),问题发生时软件使用情况为: Genex Probe 3.5 ;测试网络为LTE试验网;测试要求ping值低于30以下,以达到较低的网络时延。测试中发现RSRP、SINR值都是达标,比较好的,但是ping值却很高(高于30,甚至达到100多)。【告警信息】无【原因分析】由上述分析可知道,此问题出现在单站验证(SSV)。在测试的时候发现RSRP、SINR值都是比较好的,但是ping值却很高,这时候我们发现停掉业务重新做ping业务的时候发现仍是这

11、样,针对这个问题我们从以下几个方面分析。1、 核查做ping业务时候,是ping服务器还是外网,如果ping外网经过网关较多,需要重新选择ping服务器,这样可以减少ping业务时的路由,从而满足ping值低于30ms。2、 发现该问题首先后台做ping业务,发现设备ping服务器是正常的,如下图所示:上图显示证明终端-基站-核心网-服务器该路由ping时延是正常的,因此排除路由时延问题。3、 查看之前做上传下载时FTP是否仍然在上传或下载大文件,因为FTP在上传或下载大文件的时候,做ping业务,会发现ping值很高,有时候在单站验证时,由于个人原因,忘记停掉FTP了,然后做ping业务,发

12、现ping值很高,排除人为操作原因导致测试不达标。4、 由于软件不知明原因,做ping业务时ping值可能会呈现较高状态,此时需要关闭软件重新打开,等待一段时间后再做ping业务。5、 周围环境原因也可导致ping很高,此时需要重新换一个或多个位置,重新做ping业务。【处理过程】按照原因分析步骤一一核查,发现是点位选择问题,重新选择点位后发现ping值低于30ms,正常。【建议与总结】结合测试实践和实验,针对之后的单站验证ping业务测试,建议:测试之前先检查FTP中是否有大文件上传或下载,再进行测试,如若ping值仍然很高,首先后台做ping业务,确保ping传输通路是正常的,然后建议换一

13、个或多个测试位置,或者关闭软件,过一段时间重新打开,再进行ping业务测试。5、核心网未配TAC导致Attach业务失败【产品族】LTE FDD【现象描述】LTE-FDD新建站项目,带宽为20M,在单验的过程中,新建站初期,同一天出现部分站点存在Mobile Partner不显示有信号,但连上测试软件Probe后,无线参数显示正常,如图左侧红色区域所示,但是却无法连接到LTE网络,如下图底部红色区域显示:【告警信息】无【原因分析】1、 由于之前有站点单验均可成功接入网络,因此怀疑是终端的问题,检查终端设置发现没有解决问题,更换测试电脑也没有解决问题,终端在其他站点验证能够正常接入,因此排除终端

14、的问题。2、 怀疑数据卡的问题,用测试同一SIM验证其他站点发现能够正常接入网络,排除SIM卡的问题。3、 怀疑基站配置问题,导出基站配置文件导进行核查,发现配置的TAC值与规划值是一致的,核查其他参数,也未发现异常。4、 将前台的测试Log分析后,在L3信令中发现RRC连接建立、鉴权、加密成功,而Attach 被拒绝,原因值为:network failure 。双击Attach Reject的信令解析为:5、 Attach reject的消息是由核心网直接透传给UE的,eNodeB不会处理这条消息,所以怀疑核心网侧出现问题,将出现此现象的站TAC和核心网侧确认是否添加。核查后发现核心网漏配了

15、一部分站点的TAC,与核心网确认重新配置TAC后。【处理过程】由于核心网属于异厂家,与核心网侧确认,发现的确漏配部分TAC,待核心网将漏配TAC添加后,再次验证,配置成功显示结果如下图所示:TAC配置成功后,终端能够成功接入网络,如图红色区域信号所示:【建议与总结】在新建网络中,比较容易出现核心网漏配TAC而导致不能接入网络的现象,特别在无线和核心网属于异厂家设备上的情况下,一定要确保TAC的添加,不然容易造成人力物力的浪费。新建站中如果出现不能接入网络在发现Attach reject消息时,能看到拒绝原因,一般处理情况为如下:1、 首先查看是否硬件存在问题,终端、PC机。2、 查看SIM卡是

16、否存在异常以及开户是否有问题。3、 查看信令,出现network failure 都是和核心网相关,直接找核心网侧确认。6、天馈系统接口问题导致上传速率低【产品族】LTE FDD【现象描述】测试网络为LTE试验网,该问题发生于单站验证定海金塘沥港联通站,单站单小区测试时,测试中发现RSRP、SINR值都是达标,下载速率也比达标,但是在做上传业务时,上传速率在30M左右,不能达到40M以上。【告警信息】无【原因分析】在测试的时候发现RSRP、SINR值都是比较好的,但是上传速率不达标,这时候我们发现停掉业务重新做上传业务的时候发现仍然这样,针对这个问题我们从以下几个方面分析。1、 查看FTP服务

17、器是否10线层上传,如果做FTP业务时,不是满线程做业务,达不到高速率。2、 考了软件和测试终端会影响速率,这时候我们就要关闭软件,重启电脑后再重新打开软件,再重新做上传业务。3、 怀疑可能是周围环境原因导致上传速率较低,这时候我们就要重新换一个或多个位置,重新测上传业务。4、 是否其他测试组单站测试均出现同样问题。5、 通过灌包测试,检测传输是否存在问题。6、 后台跟踪RSSI查看是否有干扰导致速率较低。【处理过程】按照原因分析里面的步骤,首先确认都是满线程做上传和下载业务,设备重启以及重新选点后测试上传速率仍然较低,其他单站测试组未发现该问题,通过上行灌包发现,上行灌包速率能够达到40M以上,排除传输问题,最后跟踪RSSI时发现,空载时RSSI正常,但是加载后RSSI较高,如下两图所示:图1 空载时RSSI跟踪值图2 加载时RSSI跟踪值所以判断为天馈系统接口问题导致上传速率较低,最后经过施工队对天馈接口的重新处理后,重新测试上传速率恢复40M以上。【建议与总结】在做单站验证业务时,首先保证设备、操作方法以及选点准确,另外需要排查传输是否正常,以上信息准确后,通过后台跟踪干扰检测,定位速率问题。结合测试实践和实验,针对之后的单站验证上传业务测试出现不达标时,建议按照原因分析里面的步骤逐步排除分析问题即可。

展开阅读全文
收起
展开