LTE投诉故障问题总结

第一篇：LTE投诉故障问题总结

维护部

近期LTE故障投诉问题汇总

维护部近期多次接到4G网络故障投诉，故障现象多为反映信号时有时无、上不了网等。现场测试发现投诉人所在地均已做LTE网络覆盖，已通过验收，且日常巡检测试覆盖区域网络信号强度均正常，以中关村大厦，融科资源大厦以及清华同方科技大厦,为例：

后台查询，该站点设备无告警、无驻波、小区配置正常、发射功率均正常，现场去测试，2G信号，TD信号都没有问题，分布完好。

现场使用电脑终端测试，发现投诉和其他站点投诉类型相同，均由如下两种情况导致：

1）:现场确实测不到LTE信号，或者时有时无，可能接收到室外大站信号。如图通过后台，要求将该站点所有RU重启，15分钟之后，信号都恢复，手机使用也正常。

编写部门：维护部

第1页

共3页

日期：2014-7-16

维护部

编写部门：维护部

第2页

共3页

日期：2014-7-16

维护部

2）现场用LTE终端测试，信号，场强，速率都正常，但是投诉人的手机在3G或2G网络上面，一直切不到4G网络。将投诉人手机重启之后，恢复正常。手动选择网络-China Mobile.移动4G现处于建设期，目前的完善程度并不是很高，在正常通话时，网络会切换到2G网络，来完成语音通信，通话结束后，再次恢复到4G网络，但并不是直接就恢复到4G，而是先会跳转至2G网，再恢复3G，最后跳至4G，整个过程基本需要2-3分钟，或者更久，甚至直接一直保持在2G或3G网络上面，从而造成客户通话后使用不了LTE网络，最后导致用户的投诉。

编写部门：维护部

第3页

共3页

日期：2014-7-16

第二篇：LTE常见故障总结

LTE-FZHA（RL25）常见故障总结

目录

LTE-FZHA（RL25）常见故障总结............................................................................................1

1.System module failure(0010)........................................................................................3 2.BTS reference clock missing(1898)................................................................................3 3.Configuration error: Unit initialization failure(0012).....................................................3 4.Configuration error: Not enough HW for LCR(1868).....................................................4 5.Configuration error: Power level not supported(4008).................................................4 6.Cell configuration data distribution failed(6253)..........................................................4 7.Failure in optical RP3 interface(4064)...........................................................................5 8.Failure in optical RP3 interface(0010)...........................................................................5 9.Baseband bus failure(3020,1906).................................................................................5 10.RF module failure(6259，1911、1711、1712)..........................................................5 11.Cell power failure(4090)..............................................................................................6 12.GPS Receiver alarm: Control Interface not available（4011）..................................6 13.X2 interface setup failure（6304）.............................................................................6 14.Transport layer connection failure in X2 interface.......................................................6 15.Failure in replaceable baseband unit...........................................................................7 16.Temperature alarm(0002)............................................................................................7

17.VSWR（1838）............................................................................................................7 18.Failure in optical RP3 interface(2004).........................................................................8 19.GPS时钟盒闪断，时钟信号不正常，无法识别RRU...............................................8 20.Failure in optical RP3 interface（2000）.....................................................................8 21.光纤交叉连接..............................................................................................................8 22.基站始终无法建立S1连接，只到configed状态....................................................9 23.GPS时钟盒闪断，时钟信号不正常，无法识别RRU...............................................9 24.某一个小区的RRU无法识别.....................................................................................9 25.BBU版本无法识别....................................................................................................10 26.校准初步排查............................................................................................................10 27.本地IP地址和路由正常，ping不通MME和网关................................................11 28.TRS文件始终无法生效.............................................................................................11 29.三种疑难告警............................................................................................................12 30.远程ping不通基站...................................................................................................12 31.风扇告警....................................................................................................................12 32.BTSlog有link消息，但是pinger始终不亮............................................................12 33.驻波问题....................................................................................................................13 34.pinger正常，但是SM里小区显示橙黄色告警.....................................................13 35.几个特列....................................................................................................................13 36.FOSI 和FOSN的光功率范围....................................................................................13 37.不同频段RRU类型...................................................................................................13 1 38.MAC绑定及载波冲突...............................................................................................14 39.传输不通....................................................................................................................14 40.升级完成后出现驻波告警........................................................................................14 1.System module failure(0010)引起原因：

由于天气温度过高或者机房温度过高，导致BBU的热量散发不出去，引起的告警，一般表现是第三小区挂死，严重的可能会整站挂死，甚至会烧坏BBU。抑或是光模块出现问题导致出现此告警。处理方法：

1、由于是高温引起，基站要降温并重启BBU.若是BBU长期处于高温状态，会导致BBU内部的芯片烧坏，到最后只能替换BBU

2、若是因为光模块导致，则可以更换光模块，则可以解决此问题。

2.BTS reference clock missing(1898)引起原因：一般导致此故障有两个原因：

1、高温导致比较常见，由于高温时间过长，光模块过热，导致BBU和RRU失去连接，而后会出现此告警。

2、时钟盒出现故障。

3、时钟线与GPS头的连接线接头（避雷器接口）没有做好，接收不到时钟信号。

4、时钟线和时钟盒的连接不好。处理方法：

1、高温引起，基站要降温，等待一段时间后并重启BBU.2、时钟盒故障，更换时钟盒；

3、GPS线头没有接好，重新做一下从GPS引下来的馈线到避雷器的头子，使其能够正常接触。

4、若是时钟线损坏，则更换时钟线；若是时钟线和时钟盒接头没有接好，则接好接头。

3.Configuration error: Unit initialization failure(0012)引起原因：

1、高温导致小区挂死，软重启后会出现此告警

2、高温导致基站自动重启出现此告警 处理发法：

1、高温引起，基站要降温并重启BBU。

2、重新COMISSION基站，即重新把基站的集成文件（SCFC）和传输文件（Config）重新传入BBU内，重启后一般可以恢复正常。4.Configuration error: Not enough HW for LCR(1868)引起原因：以3小区基站配置来说明，由于集成文件已经配置好了，若是某一小区丢失或两个、三个小区的RRU都识别不到，则会出现此告警。

1、高温导致光模块过热，跟光纤的连接中断

2、光纤没有插好

3、光纤断了

4、RRU坏了

5、SCFC文件配置有问题 处理方法：

1、高温引起，基站要降温并重启BBU。

2、将光纤拔下来，重新插好

3、更换损坏的光纤

4、更换RRU

5、重新配置SCFC文件，如果是二小区的基站，不能将SCFC文件做成三小区的配置，否则也会出此告警。

5.Configuration error: Power level not supported(4008)引起原因：

1、BBU上的FSMF到FBBA之间的电源连接线没有插好，导致供电不足

2、BBU自身的问题 处理方法：

1、重新拔插这些电源线，使之接触正常

2、说是BBU自身的问题，则是有些可以不用拔插，直接重启基站就可以解决此问题。

6.Cell configuration data distribution failed(6253)引起原因：

基站运行一段时间由于自身问题导致，在此也说不清楚为什么会出现此问题，最大的可能性就是BBU加载好的文件一般存储在它的FLASH芯片里面，运行一段时间后文件出错，未能成功读取到SCFC文件，导致基站出现此告警

处理方法：

由于重启基站后此问题即可消失，所以一般处理的方式为重启基站，在重启的过程中，基站会重新读取索引目录Filedirectory，重新加载基站的配置文件，此过程会擦除原先在Flasn里面的数据，这样基站就能正常工作了。7.Failure in optical RP3 interface(4064)引起原因：

1、光模块损坏导致辅口读不到光纤消息

2、温度过高，导致辅口光模块故障，读取不到光纤消息

3、辅口的光纤断了 处理方法：

1、更换辅口的光模块，问题得到解决

2、下电直接重启，或是下电后将光模块拔出，冷却一阵再插入卡槽内，加好光纤，加电起来后此告警消失

3、光纤损坏导致此问题，需要更换光纤，此问题最为麻烦，需要工程队配合，一般更换光纤后都能好（前提是把1、2都做过一遍了，告警得不到解决的情况下，更换光纤）。

8.Failure in optical RP3 interface(0010)引起原因：

1、高温导致小区两光纤传输中断，BBU读不到RRU消息

2、高温导致小区两光模块出现问题

处理方法：

此问题处理的方法一般为下点重启，问题都可以得到解决，但是如果机房或者综合柜的温度还是很高的话，过不了多久，大概10分钟左右，此告警还会出现，所以需要做的是打开综合柜的门，进行散热处理，或是增加空调设备，降低室内温度，如果基站在室外，则没有什么好的办法，只能将BBU拿出来，放在综合柜外面。

9.Baseband bus failure(3020,1906)引起原因：

1、BUS线没有插好

2、BBU内部主板的问题 处理方法：

1、重新拔插BUS线，使之连接正常

2、BBU内部主板的问题有的可以通过下电重启解决此问题，但是有的只能更换BBU，此问题才能得到解决。

10.RF module failure(6259，1911、1711、1712)引起原因：

1、光模块损坏导致

2、RRU出现故障导致

处理方法：

1、若是告警号为1711（主）或1712（辅），则分别更换主辅侧的光模块即可解决问题。

2、告警号为1911或者是6259的时候，则需要更换RRU，一般都可以解决此类故障。

11.Cell power failure(4090)引起原因：

1、高温导致供给FBBA的电流减少，导致功率不足

2、Vendor文件不匹配 处理方法：

1、高温引起，基站要降温并重启BBU

2、更换跟天线匹配的正确的Vendor文件

12.GPS Receiver alarm: Control Interface not available（4011）

引起原因：

GPS时钟盒工作不正常

处理方法：

1、重启时钟盒

2、拔插连接BBU和时钟盒的时钟线

13.X2 interface setup failure（6304）

引起原因：

X2链路连接建立失败，需要建立X2链路连接

处理方法：

1、如果邻基站存在，则邻基站好了以后，此告警自然消失

2、如果邻基站不存在，则需要在邻区关系表里面讲此链路的连接配置删除，既可以消除此告警。

14.Transport layer connection failure in X2 interface 引起原因：

邻小区没有Onair,即基站未能正常起来工作 处理方法：

1、删除邻区关系

2、是邻小区正常工作

15.Failure in replaceable baseband unit 引起原因：

1、FSMF和FBBA之间连接不好导致

2、FBBA硬件问题 处理方法：

1、重启BBU

2、检查FSMF和FBBA之间的连线

3、更换FBBA板件

16.Temperature alarm(0002)引起原因：

1、机房或者综合柜温度过高

2、BBU风扇转速过快或者过慢

处理方法：

1、检查机房空调是否正常工作，温度是否正常。

2、检查综合柜是否散热良好

3、检查BBU的风扇转速是否正常，一般可以看到此类告警，若是不正常，则需要更换风扇。

17.VSWR（1838）

引起原因：

1、RRU内部的耦合器脱落，倒是发射端口出现驻波

2、天线跟BBU内的Vendor文件不匹配，出现驻波

3、馈线头子没有做好，进水了，出现驻波

4、馈线有问题，出现驻波

5、光模块也会导致驻波（很少见，我没见过，但是听说过）处理方法：

1、对于RRU损坏导致的驻波，则更换RRU，只能如此解决

2、若是天线和Vendor文件不匹配导致的告警，则更换相对应的Vendor文件

3、进水了则需要晾干或者更换馈线

4、馈线有问题则直接更换

5、光模块有问题，可以通过更换光模块来解决。

18.Failure in optical RP3 interface(2004)引起原因：

1、软件问题

2、硬件问题

处理方法：

1、更换软件版本，此告警有的基站可以消失

2、更换硬件，此告警可以消失

对于此告警，实在是难以有一个定论，曾经研发的人为此告警一天打了5个补丁还是解决不了，到现在也不知道怎么办，只有不停的更换软件包，更换硬件，更换光模块来消除此告警。

19.GPS时钟盒闪断，时钟信号不正常，无法识别RRU 正常情况下，小的时钟盒信号灯为常绿，如果出现绿色指示灯不断闪烁则GPS信号不正常。

如果灯闪的情况为一长二短，则为GPS馈线短路，如果灯闪的情况为一长一短，则为GPS馈线开路。

20.Failure in optical RP3 interface（2000）

引起原因：此告警基本是因为温度过高，但是光模块还能工作，但又受到影响，出现的告警，或者是光模块故障导致

解决办法：

1、更换光模块

2、下电重启，若是基站处于正常温度下，则可以保持正常，不再出此告警。

21.光纤交叉连接

对于室外型宏基站（FZHA，s111），开通后正常的FZHA的框号为1.1.1、1.3.1、1.4.1(normal FZHA rack no.png)。已发现有部分基站开通后的FZHA的框号为1.1.1、1.2.1、1.3.1(abnormal FZHA rack no.png)。

对于这种情况，基站无告警，但对于第一、二小区的业务测试会造成影响。原因可能是第一小区的辅光纤与第二小区的主光纤交叉错接。1、3、4代表主光口

22.基站始终无法建立S1连接，只到configed状态

这种情况一般是基站发了S1连接请求，但是核心网侧没有回，在SM里面会有6308的告警（S1 interface setup failure），这个时候我们会误认为是核心网侧没有配这个站的数据或没配对，其实核心网侧不需要配置任何数据。所有的information都由ENB上报。下面是MME的输出：

MCC MNCENB ID ENB IP S1 CONN AMOUNT === === ===== ======================================= 460 08 13 172.16.2.16 3 460 08 106 172.16.2.137 0 460 08 108 172.16.2.139 16 S1口通了之后，ENB正常接入网络，MME侧就能看见有关的信息。所以，基站侧开通时，不外乎2个问题：

1.传输不通：需要核对传输侧数据是否配对。比如：ENB IP地址，网关，S1-C控制地址，VLAN ID等。

2.传输通了，S1口不通：需要核对ENB侧 MCC,MNC,ENBID是否正确。特别是ENBID，不能与其它站冲突。截止到现在，99%的ENB S1口不通，是由于ENBID冲突造成的。SCTP的端口号36412如果都是诺西的设备，就不会出问题。

总之，在ENB接入EPC的过程中，MME只是起着等待接入，接入确认的作用。

23.GPS时钟盒闪断，时钟信号不正常，无法识别RRU 正常情况下，时钟盒信号灯为常绿，如果出现绿色指示灯不断闪烁则GPS信号不正常。如果灯闪的情况为一长二短，则为GPS馈线短路；如果灯闪的情况为一长一短，则为GPS馈线开路。这两种情况一般只需重做GPS头子就行。

还有一种情况是灯闪的时间间隔相同，则为时钟盒模式选择错误，只需把时钟盒上的模式开关拨到GNSS就行。

24.某一个小区的RRU无法识别

现象是：该小区的RRU能ping通，但是在BTSlog里面无法读出RRU的版本，SiteManger里面也无法识别RRU。

既然小区光纤同步没问题，而BTSlog和SM却又同时识别不到RRU的版本，按照RL15时的经验只可能是RRU的productCode丢失，所以从RRU里面，通过log –a提取RRU的log（F01_startup.zip和F01_runtime.zip），从该RRU的启动log里面，可以看到如图1-1显示的信息：

图1-1 该小区RRU启动log 而正常RRU启动log里面，应为如图1-2所示的信息：

图1-2 正常RRU启动log 对比可以看出，原因应该是productCode和Serial number丢失造成。在RRU里面，使用eeprom命令，手动写入productCode和Serial number，重启基站后，小区恢复正常。

25.BBU版本无法识别

BBU版本无法识别主要表现在SM读到的版本为“?”，这个问题也是在1800之后出现的，主要是因为往BBU里传文件时出错引起系统切换，重启后就识别不到版本了。

对此尝试过很多手段，包括重升PS、重传fs1、重灌基站包和重刷flash都不行。既然这个问题是系统切换时造成的那能不能再让它切换一次？于是问研发要了一条关于切换的命令，具体步骤如下：

1)通过将FileDirectory里面的“?”写回版本号，再放回flash里面 2)保证备区的FileDirectory里版本号不是“?” 3)在FCTB里执行命令：uboot_env get，查看正在运行的区域，如果是fs1，则执行命令: uboot_env set active_partition=2，将系统切换至fs2 4)重启BBU，重启后一般情况下能恢复正常版本，不行的话可以再次尝试以上方法。

26.校准初步排查

如果发现某个小区的校准有问题，比如说2小区的校准有问题，那么我们更换小区110 和小区2的光纤位置（也就是OptIF1和OptIF3更换，OptIF2和OptIF6更换），看看校准不好的小区是否有变化：

（1）如果校准不好的小区变到了第1小区，那么可能是RRU或者射频连线的问题（2）如果校准不好的小区还是第2小区，那么可能就是eNB的问题 对于(1)类问题，我们要继续看看是哪个path有问题，如下面的log：

AntIdx(7)值偏大，则须检查对应第8通道的跳线是否接好。如果所有path都不好的话，则可以尝试sitemanager block、unblock这个小区，看是否恢复正常，如果没有校准打印，则直接重启。以下是各个参数的定义：

Timeoff 波动不要太大，能稳定就可以

Ampratio 是原始天线信号计算出的天线x对参考天线的幅度比 Finalampratio 是最后ULPHY给出的调整幅度比，不会>1 Maxtxantampratio 是7组幅度比中最大值，代表了RRU 8个通道之间幅度的差异

27.本地IP地址和路由正常，ping不通MME和网关

先检查光电转换器上面是否有5个绿灯。如果电口灯未亮，检查eNB到光电转换器的网线；

如果光口灯未亮，检查光电转换器到PTN的光纤是否连接正确； 如果1000M灯未亮，检查网线的质量；

如果指示灯都正常的话，则致电PTN工程师核对PTN的端口和传输数据，尤其是VLAN和容量。

28.TRS文件始终无法生效

当传完fs1文件或升完级后，TRS文件在SM里始终无法sending出去，将其上传至runfs1trs_datadb根目录下重启基站也不生效；

此时可以尝试重刷PS来解决，生效后BBU上的传输指示灯会变绿！29.三种疑难告警

（1）Cell power failure 原因：RF received low power from BTS 解决方法：1.Check Pmax and txPowerScaling value 2.Check vendor file 3.Replace FSMF or FBBA（2）RF module failure 原因：LNA burned 解决方法：Replace RRU HW或BBU HW或FBBA（3）Baseband bus failure 原因：基带总线配置被硬件，软件，DSP或LTX拒绝 解决方法：更换BBU到两块FBBA的数据线或直接更换BBU 30.远程ping不通基站

远程ping不通有以下几种可能：（1）网管IP没配或配错

（2）该站之前正常，但是后来上站发现vlan数据又被做到PTN2-5口，导致远程ping不通；

（3）光电转换器到BBU的网线有问题，诺西采购的这批网线还不如地摊上卖的靠谱，运行一段时间后，竟然会导致传输中断

（4）PTN上的光模块突然之间出问题了

（5）基站正常运行一段时间后TRS文件丢失（6）PTN被托管了

（7）机房断电、BBU或光电转换器被下电

以上可能大多数都需去现场结合实际情况来判断，并采取相应的解决方法！

31.风扇告警

风扇告警可能是风扇过速、低速或不转，一半是风扇本身的问题，可以通过更换风扇来解决，一半是由于BBU出了问题，而不转也可能是因为风扇电源未插好。

另外有些风扇告警时有时无，需结合实际情况来判断。

32.BTSlog有link消息，但是pinger始终不亮

这个问题在18630版本下很常见，据说是因为该版本对光口质量要求高，因为我试过将版本降到16200时问题就消失了，升上来后又复现了，解决方法如下：

（1）整站下电（2）更换光模块

（3）单独上电问题小区

（4）将问题小区一根光纤拔掉 33.驻波问题

驻波问题很常见，主要有以下几种：

（1）跳线未插或未插好

（2）RRU耦合器脱落，导致驻波固定在RRU某一通道（3）天线问题

（4）Vendor文件没有和天线型号对应

SM里面显示的某通道驻波比告警是指RRU上对应的某通道，不是天线的，而校准+1则和RRU对应！

34.pinger正常，但是SM里小区显示橙黄色告警

岳峰镇台中这个站之前很正常，运行一段时间后二小区无法识别，远程重启基站后该小区报4064告警。

上站下电重启基站后该小区光纤同步正常，但是SM里小区显示橙黄色告警，更换BBU侧光模块后问题依旧，最后更换RRU侧光模块问题解决。

35.几个特列

（1）金榜食府->温度告警->整站挂掉 :温度过高会导致光口异常，小区退服；

（2）传输数据做好后，PTN网管确认vlan、ip也添加了，但是就是ping不通网关：后来才知道对应的网关没添加；

（3）有个小区始终不报link消息：后来发现是RRU侧光纤未插；

（4）琅岐便携->将BBU下电6-8分钟后，pinger能正常识别，但是SM识别不到该小区->重启几次后SM能识别，但是报RP3-2000:更换光模块后问题解决。

36.FOSI 和FOSN的光功率范围

（1）RTXM228-601 输出光功率:-8.2dBm~+0.5dBm（FOSN）输入光功率：-14.4dBm~+0.5dBm（2）RTXM228-618 输出光功率:-5.2dBm~+0.5dBm（FOSI）输入光功率：-14.4dBm~+0.5dBm 37.不同频段RRU类型

室分只有一种频段：

E频段，2.3G(6通道FZNC 和2通道FZND)宏站有两种频段：

F频段，1.9G(8通道FZFA和8通道FZFD)13 D频段，2.6G(8通道FZHA)38.MAC绑定及载波冲突

更换BBU后传输需在网管做一个MAC地址的绑定

铁路旅社：TD第三小区11个载波，所以LTE的第三小区只能到configing状态，到不了configed的状态，也ONair不了！

39.传输不通

1，网管IP没配或配错，按规划重新做数据； 2，该站之前正常，但是后来上站发现vlan数据又被做到PTN2-5口，导致远程ping不通，将PTN尾纤插到正确位置；

3，光电转换器到BBU的网线有问题，直接更换； 4，PTN上的光模块出问题，直接更换；

5，基站正常运行一段时间后TRS文件丢失，重做数据； 6，PTN被托管，联系PTN侧处理；

7，机房断电、BBU或光电转换器被下电、空开跳闸，上电或联系移动处理；

40.升级完成后出现驻波告警

此故障出现在最新升级的版本247_16，升级完成后，由于Vendor文件未能同步更新名称，导致出现驻波，这时候就需要通过Fileziler登陆到BBU里面，将Vendor文件的后面几位改成升级以后版本的名称，比如说升级前，Vendor名称为vendor_GZ818630，这时候就需要该为vendor_GZ824716。

第三篇：LTE填空题总结

3.UE通过E-UTRAN广播消息获取AS和NAS系统消息。

4、随机接入实现的基本功能：申请上行资源、与eNodeB间的上行时间同步。

5、RLC实体传输数据有三种模式：透明模式（TM）、无确认模式（UM）、确认模式（AM）。

6、LTE测量分为3类：同频测量(Intra frequency measurement，不需要改变收发频率）、异频测量(Inter frequency measurement，需要改变收发频率）、异技术测量(Inter-RAT measurement，需要改变收发频率）

1、室内覆盖指标要求_90_%的区域达到_-105__dBm以上。

2、室内单点测试中好点下行测试要求TM3达到_50__Mbps，TM1达到__35__Mbps。

3、室内信号泄漏到室外指标要求为__建筑物外10m要求满足室外室内信号

比>10dB,或者室内信号<-110dBm __。

4、室内小区基本参数核查包括__PCI、频点、BW、子帧配置、天线间距、CELL ID、eNB ID、TAC等____。

5、子帧配置1的上下行时隙配置为__DSUUD___。

1.CMCC测试规范规定，计算赋型增益时需要用到的数据有CRS RSRP和DRS RSRP

2.中移动TD-LTE试验局要求默认采用上下行配置 1，特殊子帧配置 7

3.目前TD-LTE所用的频段为 Band 38 和Band 40。

1.无线网络规划结束后应输出文档

2.OFDMA从频域对载波资源划分成多个正交的载波，小区内间无干扰，同频组网时，不同小区使用相同时频资源，存在小区间干扰。

3.影响小区吞吐量主要因素有，发射功率，其它

4.链路预算包括上下链路的发射机的各项和损耗，接收机的各项增益和损耗，以及各项增益和最大路径损耗

5.PDSCH信道的TM3模式在信道质量好的时候为，信道质量差的时

候回落到单流波束赋型。

6.LTE组网中，如果采用室外D频段组网，一般使用的时隙配比为，特

殊时隙配比为10:2:2；如果采用室外F频段组网，一般使用的时隙配比为3:1:1，特殊时隙配比为3:9:2。

第四篇：LTE学习总结-速率问题定位(前台)

速率不达标问题分析（前台）

测试中问题定位

测试时发现下载速率不达标需关注项：

1、RSRP（参考信号接收功率）

在LTE中表示接收信号强度，测试时一般要求达到-75dBm.如达不到需重新找点，则要求RSRP尽量大于-85dBm。找点时最好在天线主打方向无阻挡位置。

主要用来衡量下行参考信号的功率，和WCDMA中CPICH的RSCP作用类似，可以用来衡量下行的覆盖。区别在于协议规定RSRP指的是每RE的能量，这点和RSCP指的是全带宽能量有些差别。

2、SINR（信干噪比）

表示LTE中的信号质量，好点要求大于22。是对速率影响最大的因素。

若RSRP大于-85dBm而SINR不达标，则看邻区列表内邻区信息，看是否有较强邻区信号干扰，若有的话，可以通知后台闭塞邻区或本站其他小区后测试。

3、Transmission传输模式

传输模式现在用的有TM2（发射分集）、TM3（开环空间复用）、TM7（单流波束赋形）、TM8（双流波束赋形）。一般测试时好点都为TM3.如果在TM2可能为无线环境不好，在TM7或TM8可能虽然RSRP和SINR都好但不在天线主打方向（站下小区背后或小区副瓣方向）。

4、PDCCH ULDL Grant Count（上下调度次数）

LTE每秒调度次数，由于调度周期为1MS，所以调度次数为每秒1000次，正常情况下单用户调度次数都要在900以上。

5、BLER（误码率）

正常情况下为10%以下，如果RSRP大于80dBm并且SINR大于22情况下BLER大于10%，则很有可能是外部干扰，可以让后台看一下底噪和上下行干扰。

6、Rank Indication（秩指示）

正常情况下好点都应该为Rank2（双流）状态。如果RSRP大于80dBm并且SINR大于22还在Rank1（单流）状态，有可能是天线问题（天线不支持双流）或传输问题。

7、PDSCHPUSCH RB Number(下上行可用RB数)

8、Antenna Measurement（天线端口测量）

9、MCS（调制阶数）

9、MIMO（多发多收）

第五篇：重大故障及用户投诉处理办法

项目重大故障及用户投诉处理办法

北京神州泰岳软件股份有限公司

项目重大故障及用户投诉处理办法 总则

为加大管理力度，提高项目实施与维护工作的流程化和规范化，控制和减少各类项目事故和用户投诉的发生，保证项目质量，提升用户满意度，树立公司良好的用户形象，公司决定下发项目重大故障及用户投诉处罚管理办法，要求公司各事业部、各大区与分公司学习和贯彻执行。关于项目故障和用户投诉的级别

关于项目故障和用户投诉的级别，分为以下五级：

1.用户通报：指在用户内部公司层面进行公开通报。

2.重大投诉：指用户内部虽未公开通报，但用户向公司领导层进行书面或口头投诉、或者用户向销售、项目管理部和大区总经理进行书面投诉。

3.一般投诉：指用户内部虽未公开通报，但用户直接向销售、项目管理部和大区总经理进行口头投诉。

4.内部一级故障：指用户虽未投诉，但造成用户核心业务受到影响30分钟以上（含30分钟），包括用户业务中断、计费损失、重大保障不力和重大财产损失等。

5.内部二级故障：指用户虽未投诉，但造成用户业务受到影响而影响范围在30分钟以下或用户业务虽未受到影响但自身系统宕机或中断服务2小时以上的（含2小时）或公司资产受到重大损失或者项目上线后系统中重复发生宕机、中断服务不足2小时的重大故障。关于项目故障的责任认定

关于项目故障的责任认定，分为以下五种 项目重大故障及用户投诉处理办法

北京神州泰岳软件股份有限公司

1.低级失误：造成项目故障的原因在于责任人的操作失误或过失。2.管理问题：造成项目故障的原因在于责任人不遵守公司、部门和项目组的各类管理规范。

3.实施设计问题：造成项目故障的原因在于项目组的实施或设计方案（合同方案存在问题暂不属于项目组责任，但项目组有识别合同技术方案是否存在问题的责任和义务）。

4.产品问题：造成项目故障的原因在于项目中公司产品或第三方产品、设备自身存在问题，但当事人响应处理不及时、不到位。5.第三方因素：造成项目故障原因的在于第三方，但当事人响应处理不及时、不到位。关于用户投诉的原因

关于用户投诉的原因，分为以下五种：

1.项目故障：由于项目出现故障导致用户投诉，而故障的责任认定见第三部分的四类责任定义。

2.项目进度：由于项目进度存在问题导致用户投诉。3.项目质量：由于项目质量存在问题导致用户投诉。

4.项目管理能力和水平：由于项目管理能力和水平的问题导致用户投诉。

5.项目组服务态度和水平：由于项目组服务态度和水平的问题导致用户投诉。关于项目故障和用户投诉的通报机制

1.责任人（或第一知晓人）应在发现后第一时间立即通知项目经理（或维护类项目维护负责人，本办法中提到的项目经理统指项目经理或维护类项目维护负责人）。

2.项目经理在得知事件后应第一时间立即口头通知主管销售和事业部技术 项目重大故障及用户投诉处理办法

北京神州泰岳软件股份有限公司

总监或项目总监，在4个小时内负责向主管销售、行业经理、部门经理、技术总监、公司项目总监、大区项目总监、项目管理部、大区技术总监、大区总经理和事业部总经理进行邮件通报事故概况，并电话通知部门经理和行业经理。

3.对于除内部一般事故外的其他性质的项目事故，由技术总监或项目总监负责立即向公司CSO和CTO进行口头和邮件上报。

4.由销售受理的用户投诉，需及时通知项目经理进行跟进处理，并通知事业部主管项目领导和项目管理部。

5.由项目管理部受理的用户投诉，需及时通知项目经理、销售和事业部主管项目领导，由项目经理跟进处理。

6.由大区总经理受理的用户投诉，需及时通知主管销售，由主管销售及时通知项目经理、销售和事业部主管项目领导，由项目经理跟进处理，处理结果要上报大区总经理。

7.由公司领导层受理的用户投诉，可由公司领导层通知项目管理部，由项目管理部负责通知项目经理、主管销售和事业部总经理进行跟踪处理，处理结果要上报公司领导。关于项目故障和用户投诉的处理机制

1.项目经理为事故处理的第一责任人，由项目经理组织协调相关人员进行跟踪处理：控制事故影响，恢复受损系统和业务，最后进行事故分析、处理、汇报和总结。

2.项目经理需要会同项目组和事业部分析事故原因，给出解决办法、后续避免措施和本次事故的处理决定，生成故障分析报告。

3.故障分析报告报主管销售和项目总监（技术总监）协商确定；对于用户通报类事故和重大投诉，向用户提交的故障分析报告，需邮件向事业部总经理和公司CTO报批，并同时口头通知。

4.项目故障分析报告经审批后，由项目经理和主管销售向用户进行书面回复和正式口头汇报。项目重大故障及用户投诉处理办法

北京神州泰岳软件股份有限公司

5.由项目经理协调项目组总结故障原因与处理过程，形成项目事故案例库，上报给事业部质管部门。

6.事业部质管部门审定后向事业部内部进行全员发布，并把事故案例上报项目管理部。

7.项目管理部根据案例特点选择定向或向公司范围进行事故案例发布（发布案例的用户名、责任人等匿名处理），并由项目管理部整理汇总形成公司事故案例库。其中对于涉及公司产品问题，由项目管理部向产品管理及公共研发部进行通报。关于项目故障和用户投诉的处罚办法

7.1 处罚原则

1.差异化原则：依据故障级别和责任认定、投诉内容进行差异化处罚。其中：针对投诉内容不是“项目故障”的用户一般投诉，如果用户不做处罚的明确要求，第一次公司内部不做罚款处理，如果同一项目组再发生同类投诉则进行罚款处理。

2.责任共担原则：与项目事故和用户投诉相关的项目组和事业部人员或大区人员责任共担，依当事责任人归属技术事业部或大区进行责任共担，涉及人员包括：

1)相关当事人（归属事业部）→项目经理→事业部部二级部门经理（含行业经理）→部门技术总监（含项目总监）

2)相关当事人（归属大区）→项目经理→大区技术经理。

3.同类事故性质加罚原则：对于在公司事故案例库内发布的事故，如果重复发生处罚力度加罚一倍。

4.瞒报或不及时上报加重处罚原则：对于事故责任人和项目经理发生瞒报或不及时上报事故的，按照最高处罚标准进行处罚（即故障等级认定为由于低级错误导致的用户通报）。

5.项目经理岗位津贴罚没原则：依据故障级别和责任认定、投诉内容，决 项目重大故障及用户投诉处理办法

北京神州泰岳软件股份有限公司

定事故或用户投诉发生当月项目经理津贴是否罚没，如果需要罚没但当月已发的，则下月项目经理岗位津贴罚没（属于补罚）。

6.当事人与项目经理当期绩效降级或限级原则：依据故障级别和责任认定、投诉内容，对当事人及项目经理的当期绩效进行降级或限级。7.降低项目奖金标准原则：依据故障级别和责任认定、投诉内容，降低该项目项目奖金的标准。

8.累加原则：罚款和降低项目奖金标准的额度按照事故和用户投诉发生次数进行累加计算。

7.2 处罚标准

依据故障级别和责任认定、用户投诉内容决定责任人、项目经理、二级部门经理（含行业经理或大区技术经理）、部门技术总监（含项目总监）的处罚决定以及项目经理岗位津贴是否罚没、项目奖金基准折扣、当事人的绩效评定和事故通报范围等，具体处罚标准详见下表（附件：项目重大故障及用户投诉处罚标准.xlsx）。项目重大故障及用户投诉处理办法

北京神州泰岳软件股份有限公司

7.3 处罚执行机构

1.罚款：由事业部、大区和项目管理部联合执行。

1)由主管项目的事业部领导制定事业部内受罚当事人的罚款结果，涉及用户通报和重大投诉的处罚决定事业部需要与主管销售、公司CTO进行沟通确定，然后邮件通知当事人和项目管理部；由大区技术总监制定大区内受罚当事人的罚款结果，涉及用户通报和重大投诉的处罚决定需要与主管销售、公司CTO进行沟通确定，然后邮件通知当事人和项目管理部。

2)当事人到项目管理部进行书面签字或对处罚结果进行邮件确认（如果事业部或大区发出处罚邮件通知单后7个工作日内当事人不做邮件回复视作同意处罚决定），如果当事人不接受，可向事业部、大区或项目管理部提出邮件上诉，由事业部主管领导、大区技术总监和项目管理部协调处理。

3)项目管理部按月把处罚结果汇总报人力资源部执行。

2.通报：公司范围由项目管理部负责；事业部范围由事业部主管项目副总负责。项目重大故障及用户投诉处理办法

北京神州泰岳软件股份有限公司 名词释义

1.第一时间：含义为“从时间序列看为知道情况后的下一个动作（除非下一个动作能够立即避免故障影响扩大化）”。例如故障发生在凌晨2:00，甚至2:01就应该上报，而不是要等到上班时间（9:00）再上报。2.瞒报：含义是“知道故障发生，并且故障危害的容忍时间和规定的上报时限已过，而在公司知道前项目组还未上报”。

3.不及时：含义是“没有在规定和容许的时限内上报、响应或处理”。其中：不及时上报是指：“虽在公司知道前上报，但没有在规定和容许的时限内上报”。生效日期

本办法自发布之日起生效。

北京神州泰岳软件股份有限公司

2011年