TD无线链路失步详解Word文件下载.docx
- 文档编号:16994514
- 上传时间:2022-11-27
- 格式:DOCX
- 页数:17
- 大小:221.47KB
TD无线链路失步详解Word文件下载.docx
《TD无线链路失步详解Word文件下载.docx》由会员分享,可在线阅读,更多相关《TD无线链路失步详解Word文件下载.docx(17页珍藏版)》请在冰豆网上搜索。
ABNORMRETRIEVTMR
Rlfailure+T_RLRESTORE+T302*N302超时后,NODEB删除RL连接的等待时间,如果ABNORMRETRIEVTMR也超时,RNC释放IU连接,也就是掉话。
秒
上行失步过程的定时器设置如下:
0.16*N_OUTSYNC+Rlfail*0.1+T_RLRESTORE*0.001+T302*0.001*N302+ABNORMRETRIEVTMR
A——NodeB连续检测到NOUTSYNCIND次失步指示(每次检测的时间间隔是0.16s),(NOUTSYNCIND:
NodeB启动T_RLFAILURE定时器前连续检测到out-of-sync指示的数目);
达到A点后,NODEB会进入TRLFAILURE定时器。
B——经过TRLFAILURE的时间,NodeB如果仍未检测到连续NINSYNCIND个同步指示,NodeB则向RNC发出RLFailureIndication,表示RL链路已经失步。
(TRLFAILURE:
NodeB连续收到NOUTSYNCIND个失步指示到触发无线链路失败流程之间的时长;
如果TRLFAILURE期间,连续收到NINSYNCIND个同步指示,那么无线链路回复正常。
)
C——NodeB则向RNC发出RLFailure后,经过RLRSTRTMR+T302*N302的时间。
如果RNC未收到RLRestoreIndication(无线链路恢复指示)。
在CR373机制开启的情况下,RNC向NodeB发送RLDel(无线链路删除),要求NodeB关闭下行链路功率,以强迫UE进行CellUpdate;
(华为目前机制中在RLRSTRTMR+T302*N302时间中都等待上行自己的恢复,也就是收到RLRestoreIndication)。
网络侧等待UE上报CELLUPDATE。
D——如果经过ABNORMRETRIEVTMR的时间,没有收到UE上报的CELLUPDATE,RNC就判断UE进行CellUpdate不成功,向核心网上报IURELREQ释放连接,计为掉话。
RNC4.5版本开启CR373机制与RNC4.1版本没有CR373机制的比较
差别之处是在C点之后要求NodeB关闭下行链路,并启动ABNORMRETRIEVTMR定时器,以强迫UE自身通过CellUpdate进行掉话挽救;
之前的机制,在C点处RNC即释放链路,并记录掉话一次。
也就是说为了保证总时等于16秒,开启CR373机制,会增加一个ABNORMRETRIEVTMR定时器,因此:
【0.16*N_OUTSYNC+Rlfail*0.1+T_RLRESTORE*0.001+T302*0.001*N302】的总时间相比没有CR373机制的设置,要缩短,给ABNORMRETRIEVTMR定时器空出时间出来。
1.2下行失步机制
图2下行失步机制
下行链路失步定时器:
0.16s+0.01*(N313-1)+T313+T314
(1)UE判断下行失步总时间0.16+(N313-1)*0.01(连续N313-1次没有检测到下行同步指示);
——0.25秒
(2)步骤
(1)达到之后,等待T313的时间。
T313通常设置为3秒。
当UE从L1检测到连续N313个失步指示后启动T313定时器。
在T313的时间内如果UE从L1检测到连续N315个同步指示则停止T313定时器,UE判断无线链路恢复。
如果UE没有连续监测到N315个同步指示,T313一旦超时,则无线链路失败。
此时,UE开始进行小区搜索,并启动T314;
(3)完成小区搜索后,UE发起CellUpdate;
--------------小区搜索时间
(4)对于CS业务,在T314的时间内。
若CellUpdate没有成功,则UE放弃该呼叫;
(当处于CELL_DCH的用户发生了无线链路失败,则启动T314,并发送CELLUPDATE信令。
在业务对应的T314超时之前,如果由CELLUPDATECONFIRM配置的无线链路重配置不成功,则还可以重发CELLUPDATE信令,进行无线链路的重配置(与T302和N302有关),给无线链路重配置以机会,基于此目的,配置T314>
T302×
N302。
在T314超时后,则相应定时器对应的业务RB就被删除。
(5)T302表示每次UE每次上发Cellupdate后,等待收到CellupdateConfirm的时间。
N302表示UE上报Cellupdate的次数。
1.3CR373挽救机制强迫UE发Cellupdate的分析
结合上行,假设上行失步后下行一直好,下行一直没有失步,就不可能发CellUpdate。
直到C点开始删除RL后,下行才开始检测到下行失步。
(这是最极端的一种情况,TD是上下行基本平衡的系统,如果上行失步了,下行也不会太好,可能在C点之前下行开始失步(还有可能在上行失步之前失步),但一旦过了C点,删去RL,则必然会失步)
图3极端情况ABNORMRETRIEVTMR定时器与CellUpdate关系
UE判断下行失步总时间0.16+(N313-1)*0.01=0.25秒,之后等待T313=3s,若没有检测到下行链路恢复,则UE开始进行小区搜索,并启动T314;
也就是说ABNORMRETRIEVTMR定时器6S的情况下,删除RL后一定是需要3.25秒的,那么留给UE进行小区搜索和上报Cellupdate的时间总和最多有约2.75秒,如果超过这个时间,则无法挽救。
T=ABNORMRETRIEVTMR-(0.16+(N313-1)*0.01+T313)=6-3.25=2.75s
1.3.1小区搜索时长分析
分析2011-02-28RNC691的PCHR数据,筛选存在RL_FAIL且进行Cellupdate的数据。
当NODEB上报RL_FAIL之后,RNC会通知NODEB删除掉RL链路。
UE最迟也是从这个时间点开始失步。
所以计算NODEB删除RL链路到RNC收到Cellupdate的时间M:
M=0.16+(N313-1)*0.01+T313+小区搜索时间(S)
一共统计了472次记录,平均的RL链路删除到RNC收到Cellupdate的时间为4.0s
RL删除到RNC收到Cellupdate散点图
但这些时间里面包含两种Cellupdate:
1、是在RL链路删除导致UE下行失步而上报的Cellupdate;
2、是上行失步不就后下行也跟着失步,这种情况下下行失步的时间起点肯定在RL链路删除之前。
我们只计算第一种情况所产生的Cellupdate,以计算出小区搜索时间。
这种情况下:
Cellupdate用时——3.25+小区搜索时间。
所以我们计算时间大于3.25s的记录。
(从RL链路删除到Cellupdate上来的时间一定大于3.25s)。
RL删除到CELLUPDATE的时间值计算大于3.25的CELLUPDATE平均时间:
4.5s
RNC691终端进行小区搜索时间=4.5-3.25=1.25s
●Cellupdate终端分布分析
分析完终端进行小区搜索所需平均时间之后,我们可以进一步对ABNORMAL定时器内,能够成功上报Cellupdate的终端分布进行分析:
472条呼叫记录中,上报Cellupdate的终端分布情况如下表(未知类型为终端产品库中没有找到该IMEI号所对应的终端类型)统计出来的终端类型有82款:
终端型号
IMEI号
计数
占比
DopodA6388
86016388
2
0.42%
HAIERH-U55T
35318404
3
0.64%
HUAWEIFP515H
86021600
5
1.06%
KONKAV60S
35239104
1
0.21%
LenovoLenovoTD105
86005600
LGGW880
86018600
LGTB200
86103495
LGTM300
86103498
MotorolaMT810
35155304
7
1.49%
NkiaC5-01
35268904
SamsungGT-B7702
35189204
SamsungGT-I9008
35228404
SamsungGT-S5680
35996103
ZTEZTE-TU232
35257504
4
0.85%
ZTEZTE-TU236
35218904
ZTEZTE-TU260
35219004
ZTE中兴/TCL通讯设备(惠州)有限公司U110/TD100
86901300
21
4.46%
ZTE中兴U110
35187304
18
3.82%
大唐电信/大唐电信TDW810/TDW810H
86902500
大唐电信/中启创TDW800/PX700
86901400
戴尔Mini3T1
35196404
多普达A8188
86012300
多普达S700
86002400
多普达T8388
86017400
海尔H-U66T
35209104
海尔H-U90T
86021100
华为ETS5623
86007500
6
1.27%
华为FC5121
86017500
华为HUAWEIT1600
86026100
华为HUAWEIT2211
86022400
23
4.88%
华为HUAWEIT552
86019400
康佳/KONKAV903+/V901
86018100
联想TD30T
86291300
摩托罗拉L800T
86002300
摩托罗拉MT710
86203098
摩托罗拉MT720
86204098
诺基亚(NKIA)6788i(X5-00)
35151004
10
2.12%
诺基亚6788
86011300
普众/威海卡尔P100P/KT3000
86015300
三星(三星)GT-S3930C(GT-S5630C)
86014000
20
4.25%
三星GT-C3630C
35861603
33
7.01%
三星GT-C3730C
35920203
46
9.77%
三星GT-I6320C
86013900
12
2.55%
三星GT-I6330C
86014900
三星GT-I7680
35995203
三星GT-I8180C
86019300
三星GT-S3930C
35958803
深圳泰丰HWCD888(6)
86903000
深圳通则ZLT2818(2000)
35913703
天语E500
86013300
天语T590
35615501
新邮通信(新邮通)N330(N311)
86000800
星网锐捷FP1X-T1
86025000
宇龙/宇龙CoolPad6268/F61
86800100
8
1.70%
宇龙6268H
86800800
宇龙CoolPad6168
86005400
宇龙CoolPad6260
86800000
宇龙CoolPadF600
86024400
宇龙CoolPadF620
86050200
宇龙F603
35992301
宇龙F608
86019900
中兴U110
35209004
中兴U862
86007600
中兴ZTE-TU218
35212804
中兴ZTE-TU230
86021900
未知类型
94
19.96%
总计
471
100.00%
(未知类型终端的IMEI号:
440101、440110、35269004、35333404、35352304、35467004、35948503、86000200、86005800、86008900、86025600、86028000、86031800、86034300、86050700)
1.4挽救机制无法生效的场景
挽救机制也是针对部分场景的,在下面几种场景中无法挽救
1.4.1上行定时器超时,CellUpdate无法挽救
如上节所述,在极端情况,也就是下行失步是从删除RL后,在Abnormarl配置为6s的情况下,如果CellUpdate的时间超过2.75s,则无法挽救。
1.4.2下行覆盖差,不满足TD小区选择条件,UE不发CellUpdate
小区选择标准如下:
一个小区的无线参数是否满足小区驻留的标准(包括正常小区驻留和任意小区驻留)可由下面的不等式来判断:
在上式中:
:
小区选择的接收值(dB),由该参数来判断小区是否可选。
UE在P-CCPCH信道上接收的信号码功率(dBm)。
小区要求的最小接收功率,该参数由系统信息广播(dBm)。
UE在随机接入信道RACH上允许使用的最大发射功率,该参数由系统信息广播UE_TXPWR_MAX_RACH(dBm)。
UE的最大射频发射功率(dBm)。
目前
和
配的是一样的,所以起作用的是最小接入电平和接收PCCPCH。
当下行失步以后,UE会进行小区搜索,如果搜不到满足条件的小区,则不会发起CellUpdate。
可以用下面的事例证明,最终由于终端小区重选失败,没有发起小区更新。
也就是说是UE先走完下行失步流程放弃链路以后,NodeB才检测到上行失步,进入上行失步流程。
最终导致网络侧检测到上行失步导致的掉话
1.4.3上行链路由于持续干扰或者覆盖不足
CellUpdate时公共信道上行持续干扰或者覆盖不足,此时UE虽然发了CellUpdate,但是网络侧无法收到,无法挽救掉话。
因此,对于覆盖差(包括上行和下行),以及上行持续强干扰,挽救机制是无法起挽救作用的,挽救机制最有效的场景是上行的突发干扰。
对于覆盖差的场景,即使拯救成功第一次,由于链路质量无法得到改善,最终还是会掉话,如下实例:
此时CellUpdate所带的PCCPCHRSCP为-92,基本属于弱覆盖区域,因此,虽然第一次拯救成功,由于无线环境还是弱覆盖,没有改善,虽然后面尝试挽救,但是由于无线环境恶劣,最终导致掉话。
2、RNC691和RNC722关闭挽救机制对比
RNC722中的小区是从RNC691中割接来的,因此可以认为RNC722和RNC691的场景类似,且RNC722在爱立信核心网下,RNC691在华为核心网下。
3月4日在RNC722和RNC691同时关闭挽救机制,观察指标变化。
表1挽救机制打开关闭后指标对比
RNC
RAB建立成功次数
掉话次数
CS掉话率
挽救机制关闭
RNC722
41319
259
0.63%
RNC691
277390
1746
挽救机制打开
40584
221
0.54%
265905
1241
0.47%
可以看出挽救机制关闭后,爱立信核心网下的RNC722掉话率恶化了0.09%,华为核心网下的RNC691恶化了0.16%。
说明挽救机制在RNC722和RNC691同时有效,只是效果有所差异。
挽救机制关闭后,RNC691掉话次数增加了505次,增加了28.92%,RAB建立成功次数增加11485次,增加了4.32%。
RNC722掉话次数增加了38次,增加了17.19%,RAB建立成功次数增加11485次,增加了1.82%。
从同时恶化的比例可以看出,挽救机制在RNC691应该有0.16%的增益,在RNC722应该有0.09%的增益。
只要拯救了RLFail原因的掉话,掉话率就会有所好转,因此分析两个RNC发生RLFail后,CellUpdate拯救的情况
表2RNC691和RNC722发生RLFail和CellUpdate拯救的情况
RLFail次数
RLFail后有CellUpdate拯救次数
RLFail后发生CellUpdate比例
CellUpdate成功次数
CellUpdate成功率
691
1844
2.49%
32
69.57%
722
263
2.28%
83.33%
2070
604
29.18%
513
84.93%
350
62
17.71%
52
83.87%
可以看出关闭挽救机制后,RLFail后有CellUpdate次数明显减少,RNC691RLFail后有CellUpdate次数减少了558次,RNC722减少了56次,与掉话的次数基本成正比。
关闭后CellUpdate拯救的概率也减小很多,同样也说明在RNC691和RNC722,挽救机制同样有效
3、挽救机制在深圳不明显的原因
由上面一节可以得出结论,挽救机制无法挽救由于深度覆盖不足的场景。
通过下面2节的MR评估表明,深圳的深度覆盖明显差于东莞。
第2章
第3章
3.1深圳RNC680掉话前MR覆盖分析评估
深圳RNC680是掉话项目分析与优化的试点RNC。
在进行掉话专项中,首先需要对该RNC语音业务的掉话原因分布有所认识,方可制定有效措施。
本文依据RNC680下某一天的PCHR话单与MR记录分析掉话前的无线链路状况。
按照目前中国移动拉网测试定义,PCCPCHRSCP小于-95dBm即判断“弱覆盖”。
表3是掉话前PCCPCHRSCP的统计分布。
表3掉话前本小区PCCPCHRSCP分布
本小区PCCPCHRSCP分布
次数
比例
(-116,-95]
142
60%
(-95,-90]
14%
(-90,-85]
25
11%
(-85,0)
37
16%
可以看到,典型的弱覆盖占比为60%。
除此之外,对于(-95,-90]之间的32次掉话,其电平质量本身也不乐观。
进一步分析掉话前相邻小区的中PCCPCHRSCP最强值的分布,如表4所示,73%的掉话发生前,其邻小区最强的PCCPCHRSCP也低于-95dBm。
表4掉话前邻小区最强PCCPCHRSCP分布
邻小区PCCPCHRSCP分布
170
73%
8%
13
6%
无记录
15
再进一步,掉话前“本小区公共信道覆盖不足,邻小区公共信道覆盖也不足”的分析结果如表5所示。
有54%的语音掉话,其发生前本小区与邻小区公共信道电平均低于-95dBm。
表5掉话前本小区与邻小区PCCPCHRSCP分布
本小区电平分布
邻小区电平分布
小于等于-95dBm
128
54%
大于-95dBm
2%
42
18%
47
20%
其它
有以下结论:
(1)RNC680有60%的掉话,是发生在“本小区PCCPCHRSCP小于-95dBm”的情况下,属于弱覆盖场景
(2)RNC680有54%的掉话,是发生在“本小区和邻小区PCCPCHRSCP均小于-95dBm”的情况下,这是深度覆盖极度不足的场景。
3.2东莞掉话前MR覆盖评估
PCCPCHRSCP小于-95dBm即判断“弱覆盖”。
表6是东莞掉话前PCCPCHRSCP的统计分布。
表6东莞PCCPCHRSCP状况比较
本小区PCCPCHRSCP分
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- TD 无线 链路失步 详解