案例宁波水表厂NBIoT业务附着失败问题研究案例文档格式.docx
《案例宁波水表厂NBIoT业务附着失败问题研究案例文档格式.docx》由会员分享，可在线阅读，更多相关《案例宁波水表厂NBIoT业务附着失败问题研究案例文档格式.docx（14页珍藏版）》请在冰豆网上搜索。
1.干扰排查
由于用户数增加带来底噪的抬升，现场使用扫频仪在水表厂进行的扫频，扫频结果显示扫频仪扫到信号的中心频率和NB终端上行信号的中心频率（834.6Mhz）是一致的，且是窄带信号（200K以内），可以排除外部干扰，确认底噪抬升是由于NB上行信号导致。
3个主服小区都设置为2506时的扫频结果：
3个主服小区中2个设置2506频点1个设置为2509频点的扫频结果。
2.话统根因分析
RRC建立成功率分析：
RRC建立失败原因主要是NoReply：
标口日志分析：
在高话务量（上下行资源占用率）场景下，终端RRC接入过程中因为资源分配受限而失败。
RRCNoReply分析：
统计调度失败错误码分布，TOP2原因：
下行PDCCH资源不足、上行UCI资源不足
下图中横轴表示调度失败错误码，纵轴表示失败次数
以15:
13:
46s调度失败的Rnti15724用户为例：
在这一秒中PDCCH资源调度需求为1283次：
其中因为PDCCH资源不足（325/s），同时也因为部分PDSCH资源不足，从而最终196个PDCCH资源被分配。
从这个过程可以看到，PDCCH资源在1s内最大被累计调度了1283次（已经远超过325的容量了），因此调度失败概率很高。
3.容量理论评估
对水表厂的容量评估：
一、上报频次统计
涉及到数据上报的操作工序有四步：
1、线路板调试：
每一位工装一分钟最多有两个表在触发测试，最多有五个进行，一分钟最多上报10个表；
2、参数设置：
每一位工装一分钟最多触发两个表，最多有五个进行，一分钟最多上报10个表。
与网络无交互。
3、测计数性能：
一分钟内最多触发10个表。
----无网络交互。
正常情况下一分钟内最多10+10+10=30个表。
4、通讯功能测试：
一次性激活50个水表，每分钟估计有30~40个；
然后查看是否有通信记录。
也就说，极端情况下，最多同时在线80~90个水表。
二、通讯机制
1、表进行触发，发送数据之后，若模组无应答，则20分钟后重发，最多可重发三次。
2、设好表地址，时间戳同步后，表的上报时间在0点-8点，通讯时间是离散的；
如果时间戳没有同步，则全天都有可能会上报。
宁波水表在生产线测试时，终端并未完成附着流程，所以每次均需要重新附着到网络，然后进行上下行数传，业务流程如下。
图1宁波水表生产测试信令流程
容量评估：
覆盖等级用户分布（0;
1;
2）
开始时间
结束时间
每日次数
业务类型
每分钟小区容量（最大成功次数）
备注
100%：
0%：
0%
1
低频业务
154.5
极端模型
50%：
40%：
10%
43.4
常见模型
5%：
39%：
56%
9.6
12月5日状态
上述模型为纯理论模型，考虑到如下因素，实际情况下，终端可能从多个覆盖等级接入：
（1）理论模型中用户接入可以认为是均匀接入，实际测试时很难做到，存在瞬间并发的波动情况。
（2）由于无线信道的干扰和衰落，导致终端可能从覆盖等级1或者2接入。
（3）终端接收能力个体差异和测试位置点个体差异，可能导致终端从不同覆盖等级接入。
【问题处理】
1.无线侧优化
参数优化：
优化目标：
降低水表厂区域资源消耗，降低干扰
针对Prach资源优化：
降低Preamble并发导致的覆盖等级抬升、干扰抬升问题，同时降低资源消耗。
MODCELLALGOSWITCH:
LOCALCELLID=10,NBCELLALGOSWITCH=COVERAGE_EXTENSION_SWITCH-1;
MODCELLRACHCECFG:
LocalCellId=xx,CoverageLevel=0,MaxNumPreambleAttempt=REP_4;
MODRACHCFG:
LocalCellId=xx,PreambleTransMax=N4_PREMB_TRANS_MAX;
LocalCellId=xx,RachAlgoSwitch=BackOffSwitch-1;
下行资源优化：
降低覆盖等级2上用户的重复次数，降低资源消耗：
MODCELLPDCCHCECFG:
LocalCellId=1,CoverageLevel=COVERAGE_LEVEL_2,PdcchMaxRepetitionCnt=REP_32;
MODNBCELLDLSCHCEALGO:
LocalCellId=1,CoverageLevel=COVERAGE_LEVEL_2,DlInitialTransRptCount=REP_4;
LocalCellId=xx,CoverageLevel=COVERAGE_LEVEL_0,PdcchMaxRepetitionCnt=REP_8,PdcchPeriodFactor=G_2;
上行功率：
降低上行重传次数，减少终端功率抬升的次数，降低干扰抬升和资源消耗。
MODNBCELLULSCHCEALGO:
LocalCellId=1,CoverageLevel=COVERAGE_LEVEL_0,AckNackTransRptCount=REP_1,AckNackTransRptCountMsg4=REP_1;
LocalCellId=1,CoverageLevel=COVERAGE_LEVEL_1,AckNackTransRptCount=REP_2,AckNackTransRptCountMsg4=REP_2;
LocalCellId=1,CoverageLevel=COVERAGE_LEVEL_2,AckNackTransRptCount=REP_16,AckNackTransRptCountMsg4=REP_16;
组网优化：
提升水表厂区域整体网络资源，降低干扰
对宁波水表厂区域进行异频组网，保持LF_H_JB水表新厂-NB_82频点为2506不变，修改另一主服LF_H_JB甬东邵村-NB_82频点为2059。
同时关闭周围6公里内其它非主服NB小区，降低干扰。
优化效果：
水表厂区域的RRC连接成功率由优化前30%提升至80%以上，但是无法满足水表厂用户测试需求。
2.核心网优化
从核心网提取12月28日10个小时左右的水表厂区域终端与核心网交互次数发现，共有4837个终端（IMSI）和核心网有交互。
其中超过10次交互的终端比例高达26.73%。
个别TOP终端的交互次数达到300次以上，与实际水表厂的业务模型（每天做1次数据上报和2次TAU更新）不符合。
NB终端和核心网交互次数次数占比统计
日期
终端个数
交互次数10次以内终端个数
交互次数10次以内终端个数占比
交互次数11-100次终端个数
交互次数11-100次终端个数占比
12月28日
4837
3544
73.27%
1270
26.26%
终端与核心网交互次数Top5统计
IMSI
交互次数
公司名称
460111173868980
353
宁波水表股份有限公司（拉分）
460111116898279
268
宁波水表股份有限公司
460111175150383
170
460111175140245
148
460111175148324
147
水表厂对部分异常终端进行串口通信数据监控在终端串口日志中发现有频繁触发TAU的现象，且在tauaccept消息中解析出tau定时器是30分钟（实际物联网平台中配置为10小时）。
NB异常终端频繁触发TAU
TAU定时器解析30分钟
12月30号核心网修改了TAU相关参数，目的拉长部分异常终端的TAU定时器至10小时。
话统指标显示：
RRC连接请求次数由每天270000次下降至每天110000次，mt-Access原因的RRC连接建立请求次数恢复由100000次/天骤降至2000次/天左右，大大减轻了网络负荷。
3.综合优化
在核心网参数修改完成后水表厂客户反馈生产车间内NB通信测试已经满足测试要求，但是水表厂研究院内NB通信测试成功率不高，需要继续优化。
现场测试发现研究院位置处于NB覆盖小区的边缘。
怀疑其成功率低是由于在关掉了覆盖扩展开关后上下行覆盖差导致。
1月8号打开覆盖扩展开关之后，再对PDCCH复用周期和竞争解决定时器进行优化。
增强下行覆盖，扩展竞争解决定时器时长，增加PDCCH复用周期
LocalCellId=10,CoverageLevel=COVERAGE_LEVEL_0,PdcchTransRptCntFactor=ONER_EIGHTR;
LocalCellId=10,CoverageLevel=COVERAGE_LEVEL_0,ContentionResolutionTimer=PP_64;
除了0点和16点，其余时段RRC成功率优化至95%左右，0点、16点两个时段由于上报水表太多（宁波厂前期没有做错峰机制在这2个时段触发的水表较多），成功率在75%左右。
宁波水表厂客户反馈测试车间和研究院可以到达测试标准，问题闭环。
综合优化后RRC成功率趋势
【问题总结】
该案例中问题主要由2个方面触发：
一方面是大量终端并发接入导致覆盖等级提升、上行发射功率抬升，最终造成上行干扰恶化，小区业务量上升，上下行资源利用率过高，导致RRC接入过程中资源受限而接入失败。
另一方面是核心网和部分NB终端的TAU定时器协商存在问题，导致部分终端采用TAU短周期30分钟（正常10小时）进行TAU更新，大大加重了网络的负荷。
升级会员 