当前位置:首页 >> 信息与通信 >>

TD-SCDMA PS域问题定位分析


PS域问题定位分析

1. PS域接通率问题定位分析
首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问 题等五方面来分析PS接通率。

产品问题 从实际网络运营情况观察来看,目前未发现产品问题严重影响PS接通率。
TOP小区问题 从话统数据来看,PS的RRC建立成功率较高;而PS的RAB建立成功率则较低。查

看每 天PS RAB建立失败的TOP15小区,其失败次数占总失败次数的55%,因此,可针对TOP 小区进行问题处理,提升网络KPI。 终端问题 通过PCHR数据分析来看,IMEI为86010300的终端,PS RAB建立失败率较高,且失败 次数较多。 无线环境和干扰 针对TOP小区,排查现网的无线环境,查看其是否是由于过覆盖、弱覆盖、信号泄露、 干扰等无线环境原因造成的。该项目H频点采用单频点组网,因此,H频点干扰对于PS的 接通率影响较大。 除以上分析方法外,PS接通率指标提升还包括DCCC、载波扩容、调整H频点、减少弱覆 盖、永久在线定时器这几个主要措施。

1.1 具体问题定位措施
1.1.1 问题小区处理 通过对PS域RRC建立失败的TOP小区和PS域RAB建立失败的TOP小区的处理,在网络业 务量不断增加的情况下,PS接入坏小区数目从6月末的62个减少到9月末的9个,减少 了85.48%,如果考虑业务量增加这一原因(从6月末的423GByte增加到了9月末的 462GByte),业务量坏小区比例从6.8GB/个提升到51.3GB/个,如下图所示:

PS无线接入坏小区趋势图

1.1.2 DCCC算法
目前该TD项目的时隙比为2:4配置,H载波的两个上行时隙中有一个需 要配置HS-SICH信道;用户的PS开户速率通常为上行128kbps,下行2048kbps。 因此,如果没有打开DCCC算法的,一个H载波只能接进一个上行128kbps的H 用户,很容易造成H载波的拥塞。

PS域接通率趋势图

从话统数据来看,7月13日网络侧关闭整网的DCCC算法,PS接通率迅速由97%下跌 到92%,7月28日网络侧打开DCCC算法后,PS接通率重新恢复到97%。

RRC的建立成功率指标始终维持在99%,PS接通率主要与PS域RAB建立成功率强相关; DCCC算法关闭后,PS域RAB建立失败是由于网络拥塞造成的,话统上可以看到“分组 域RAB 指配建立失败的RAB 数目<最大速率不支持>”大幅增加。
分组域RAB 指配建立失 败的RAB 数目<最大速率 不支持> <最大速率不支持>导致 的RAB建立失败占RAB 总失败次数比例

PS域RAB指派建立 成功RAB数目

PS域RAB建立请求 的RAB数目

PS域RAB建立成功率

时间 7 100488 97840 113740 123861 116958 120599 103180 7 100595 2504 121652 4263 135558 3755 127653 3936 131627 35.69% 91.62 35.11% 91.62 36.45% 91.37 31.65% 93.50 0.25% 97.26 0.26% 97.39

1.1.3 载波扩容
随着数据业务用户的增多,DCCC算法的打开已不能解决网络中小区PS拥塞的现象, 针对8月17日至8月23日的话统数据来看,“分组域RAB 指配建立失败的RAB 数目< 最大速率不支持>”已经占PS RAB建立失败总次数的5%~10%。以下是这段期间PS业 务拥塞小区列表。 PS业务拥塞小区列表
20090823 求水山T2 石厦文化T3 沙尾二T2 食品行T2 投资T2 管理大厦F2 大梅沙二T2 20090822 石厦文化T3 石厦文化T2 书城高层T3 华泰T2 横岭T1 福田T3 儿童公园T2 龙府F1 20090821 香径T1 石厦文化T3 皇岗公园T2 邮电枢纽T3 滨中T3 安华T2 石厦文化T1 山姆T1 地王大厦F2 石厦文化T2 电器T1 龙城鹏飞T1 新世界广场F3 墩埔T1 华泰T2 龙城T1 供电局T3 20090820 香径T1 滨中T3 新世界广场F3 地王大厦F1 地王大厦F2 市民西T3 皇岗公园T3 龙溪村T3 华强北T3 石厦文化T3 水库新村T1 邮电枢纽T3 上李朗T2 龙岗创业T2 福田T2 李通T3 华强北T2 20090819 邮电枢纽T3 新世界广场F3 香径T1 深大村T3 石厦文化T3 滨中T3 梅林东T1 发展大厦F1 市民西T3 华强北T3 下沙二T1 建艺T1 百仕达T1 书城T1 世贸广场F1 皇岗公园T2 水库新村T1 20090818 市民西T3 香径T1 邮电枢纽T3 石厦文化T3 新世界广场F3 艺丰T2 华泰T2 华强北T3 地王大厦F1 万佳T1 地铁总站T1 中级法院T1 四季花城T2 名士酒店T2 福运T1 地铁世界之窗站F1 20090817 市民西T3 香径T1 邮电枢纽T3 华强北T3 地王大厦F1 新世界广场F3 二办T2 求水山T2 艺丰T3 下沙二T1 人民银行F1 石厦南T3 上沙T1 福运T1 地王大厦F2 赤尾T1 银河T3

建艺T1
百仕达T1 市民西T3 田面T1 艺丰T3 梅观库坑T3

地税局F1
地铁总站T1

东座酒店T2

香蜜湖T1
文华T1 民治T3 墩埔T3 深铁T1

从上表可以看出,周末小区拥塞较少,其中以下小区在一周内拥塞次数超过3天
小区名 石厦文化T3 市民西T3 香径T1 新世界广场F3 邮电枢纽T3 华强北T3 滨中T3 地王大厦F1 地王大厦F2 华泰T2 拥塞天 数 6 5 5 5 5 4 3 3 3 3

连续拥塞多天的小区

为了减少由于小区拥塞导致的RAB建立失败,可在该小区增加一个H载波。因为, HS-PSSCH是没有功控的,所以新增的H载波可能对周边与其同频的小区造成同频干 扰,导致CS/PS接入失败或掉话,因此在H载波扩容时,还需要关注扩容对周边小区 的影响。随着H载波的扩容,小区拥塞造成的RAB建立失败已明显下降。

PS域RAB指 派建立成功 RAB数目

PS域RAB建立 请求的RAB数 目

分组域RAB 指 配建立失败的 RAB 数目<最 大速率不支持 >

<最大速率不 支持>导致的 RAB建立失败 占RAB总失败 次数比例

PS域RAB建立 成功率

时间

317
124470 127291

11.24%
97.78

280
128296 131101

9.98%
97.86

176
124766 127664

6.07%
97.73

18
121658 123633

0.91%
98.40

16
127311 129092

0.90%
98.62

37
122020 123614

2.32%
98.71

小区扩容对RAB建立成功率的影响

1.1.4 H载波调整 从话统数据来看,由于最大速率不支持造成RAB建立失败只占RAB建立失败总次数的 5%~10%,其它原因未知。CS的RB建立成功率基本上都在99.9%,而为什么PS的RB建立 成功率只有98%左右,两者的应用场景有什么区别? 从PCHR的分析来看,PS的RB建立失败除了网络拥塞,最大速率不支持之外,其它的建 立失败的原因值基本上都是 “RR_ERR_RNCAP_RB_WAIT_UE_RB_CFG_TIMEOUT(185468904)”,请求的下行速率绝大 部分为2048kbps,从信令上来看表现为RNC给UE发送RB SETUP信令后,始终收不到UE回 的RB SETUP CMP,导致RB建立失败。

RB SETUP超时消息流程

从UE的接入电平来看,RB建立失败的主要电平分布在-89~-85,信号质量一般,到 小区的该信号质量区域进行测试,RB建立也没有什么问题。 分析PS业务建立的流程,首先是RRC建立,然后RNC会在H载波分配好资源,并下发 RB SETUP给UE,UE会尝试在H载波上进行信道建立。RRC建立成功了,为什么RB建立 不起来,同样的小区为什么CS基本没问题? 该城市H频点规划只有1个频点,推测与单频点干扰相关。
PS RB建立失败在各RSCP的分布次数

-84~-80 10%

>-80 8%

<-95 -94~-90 6% 11% <-95 -94~-90 -89~-85 -84~-80 >-80

-89~-85 65%

PS RB建立失败在各RSCP的分布 为了验证RB建立失败与H单频点干扰的相关性,在RNC 1T选择TOP小区调整频点, 并对这些小区进行簇跟踪。从话统数据来看,H频点更改后,该簇PS的RB建立成 功率由96%提升到了99.5%,掉话率也有显著的改善。

日期

HSDPA RAB分配 成功次数

HSDPA RAB分配 请求次数

HSDPA 掉 话次数

PS RAB 分配成功 次数

PS RAB 分配请求 次数

PS 掉话次数 HSDPA (含HSDPA) 掉话率

PS RAB 分配成 功率

PS掉话率( 含 HSDPA)

备注

1089 1302 1986 1432

1147 1336 2073 1522

364 361 468 522

1459 1606 2315 2047

1523 1642 2405 2138

376 372 484 544

33.43% 27.73% 23.56% 36.45%

95.80% 97.81% 96.26% 95.74%

25.77% 23.16% 20.91% 26.58%

1573
965 1197 759 1392 1445

1677
968 1203 773 1395 1446

349
62 68 90 107 38

2071
1203 1459 990 1561 1636

2176
1207 1465 1005 1564 1638

357
62 73 111 156 43

22.19%
6.42% 5.68% 11.86% 7.69% 2.63%

95.17%
99.67% 99.59% 98.51% 99.81% 99.88%

17.24%
5.15% 5.00% 11.21% 9.99% 2.63%

26号凌 晨0点修 改,数 据都是 只统计 修改的 10个小 区;

H频点更改对PS RB建立成功率的影响

减少弱覆盖
H频点干扰较大,弱覆盖区域的PS用户容易RB建立失败而接入失败,也比较容 易掉话,为了减少弱覆盖造成的PS接入失败和掉话,可调整小区覆盖,后修改 最小接入电平和异系统启动门限,让用户尽量在2G网络使用业务。以下表用户 为例,其接入电平平均在-97左右,如果可以调整H频点可考虑优先修改H频点, 如果不行,可考虑将最小接入电平修改为-98或-95,同时注意修改异系统启动 门限。
接入时间 IMSI 接入小区 晨晖花园T2 晨晖花园T2 晨晖花园T2 晨晖花园T2 晨晖花园T2 晨晖花园T2 晨晖花园T2 RACH测量报告接入小区PCCPCH RSCP -99(17) -98(18) -98(18) -97(19) -97(19) -94(22) -94(22) 22:30:46 460077119551XXX 22:29:43 460077119551XXX 22:30:14 460077119551XXX 22:25:59 460077119551XXX 23:51:35 460077119551XXX 18:39:07 460077119551XXX 18:39:33 460077119551XXX

缩短“PS永久在线定时器”
"PS永久在线定时器"的含义为:当PS业务的用户在超过该定时器时长的一段时间内无 数据传输,则RNC会发起RRC释放请求释放该业务。 将"PS永久在线定时器"的时间改短后,RNC会更快在用户空闲没有业务流量的情况下 将用户的资源释放,也可以减少用户在空闲状态保持连接导致的掉话。 以定时器长为1小时和1分钟为例。假设测试场景周期为2小时,期间有6次是用户的空 闲时间超过1分钟(但是没有空闲时间超过1小时)的,45分钟时会有一次网外的强干扰 (会导致用户掉话和1次RAB建立失败)。

如果定时器时长为1小时,那么用户在测试开始时有一次RAB建立,45分钟掉话后再 有2次RAB建立(假设一次失败,一次成功),总共有3次RAB建立;45分钟时有1次掉话, 所以该用户的接通率为2/3=66.6%,掉话率为1/3=33.3%。 如果定时器时长为1分钟,那么用户在测试开始时有一次RAB建立,45分钟掉话后再有 2次RAB建立(假设一次失败,一次成功),加上6次定时器超时导致的RAB释放和建立, 总共有9次RAB建立;45分钟时有1次掉话,所以该用户的接通率为8/9=88.9%,掉话率为 1/9=11.1%。

所以,将"PS永久在线定时器"的时间该短后,PS的RAB建立尝试次数会增加,RAB建 立成功次数也会正向增加,从而可以优化接通率和掉话率。 从话统可以看出,23日修改7个RNC的“PS永久在线定时器”由之前的60S到45S后, PS的RAB建立成功率由之前的98.6%上升到98.8%。
PS域 RAB 指派 建立 成功 RAB 数目 11434 4 12043 0 12701 6 14924 2

PS域 PS域 PS域 RAB建 RRC连 RAB建 立请求 接建立 立成功 的RAB 成功次 率 数目 数

PS域 RRC连 接建立 尝试次 数

时间

PS域 RRC连 接建立 成功率 (呼叫 相关)

RNC请 PS域无 求释放 线接通 的分组 率 域RAB 数目

分组域 RAB指 PS域无 派建立 线掉线 成功的 率 RAB数 目

115944 122236 128664 151063

98.62 98.52

94546 99331

95152 99868 106176 128678

99.36 99.46 99.44 99.45

97.99 97.99 98.17 98.25

12611 12265 12003 10787

114344 120430 127016 149242

11.03 10.18 9.45 7.23

98.72 105585 98.79 127969

PS域掉话率问题定位分析
从PCHR的数据分析来看,现网CS的平均呼叫时长为87S,PS R4业务平均呼叫时长为 243S,PS H业务的平均呼叫时长为792S。根据华为CDMA/UMTS系统经验,在一个成熟 的网络中,基于相同的无线环境,不同业务的中断概率与业务保持时间成比例增长。 从下表来看,PS的掉话率仍有提升的空间
业务类型 平均呼叫时长 当前掉线率 PS经验推算掉线率 CS 87.08s 0.85% PS R4 243.22s 6.12% 2.37% PS H 792.84s 20.83% 7.7%

针对5T的掉话率分析,发现PS掉话绝大部分为H掉话,因此,工作重心应该 放在H优化上面。 首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问题等五方 面来分析PS掉话率。

产品问题 从实际网络运营情况观察来看,目前未发现产品问题严重影响PS掉话率。

TOP小区问题 从话统数据来看,黎光T1等小区连续多天出现在TOP小区,因此,可针对TOP 小区进行问题处理,提升网络KPI。
RNC级TOP小区一周 7 6 5 4 3 2 1 0 800 700 600 500 400 300 200 100 0

房 T1 机 田 坂

T 布 1 尾 T 滨 2 书 中 城 T3 高 层 下 T3 沙 二 大 T1 浪 村 T 福 3 福 田 田 T3 区 委 T 湖 1 贝 华 T3 强 景 北 田 T3 布 尾 T 罗 1 湖 木 T1 头 龙 T 山 2 姆 T 塘 1 尾 T 眼 2 宇 科 龙 T3 西 丽 F1
出现天数 总失败次数









终端问题 从统计看出,目前现网终端活跃度较高的终端,其掉线率较为平均,均处于较高水平
IMEI_TAC 86006200 86003900 86007900 35303602 86001600 86007300 86008600 业务次数 1791 1319 1081 766 527 558 749 终端活跃 度 16.31% 12.01% 9.84% 6.98% 4.80% 5.08% 6.82% 掉线次数 505 406 328 217 112 104 101 掉线率 终端型号

28.20% 中兴MU350 30.78% 华为ET128 30.34% 28.33% #N/A #N/A

21.25% 中兴U980 18.64% 13.48% 大唐 AirCard901 #N/A

无线环境和干扰 针对TOP小区,排查现网的无线环境,查看其是否是由于过覆盖、弱覆盖、信 号泄露、干扰等无线环境原因造成的。该城市H频点采用单频点组网,因此,H 频点干扰对于PS的掉话率影响较大。 除以上分析方法外,PS掉话率指标还包括DCCC、调整H频点、减少弱覆盖、HSPDSCH功率与PCCPCH功率对齐、调整永久在线定时器这几个主要措施。

2.1 具体问题定位措施
2.1.1 问题小区处理 通过对PS域掉话率的TOP小区的处理,在网络业务量不断增加的情况下,PS掉话坏 小区数目从6月末到9月末显著减少。 2.1.2 DCCC算法优化 现网在没有DCCC算法的情况下,1个H载波只能接进一个H用户,随着PS业务的不断 增长,需打开DCCC算法以满足用户需求。

从全网的PS掉话趋势图来看,7月13日关闭DCCC时,整网的PS掉话率在14%~16%波 动。7月28日打开DCCC后,整网的PS掉话率上升到17%。
默认的DCCC算法参数容易造成用户信道的频繁重配,从而加大了掉话的可能性。8 月5日,通过DCCC算法调整,解决频繁信道重配导致的掉话,PS掉话率下降到 14%~15%,与关闭DCCC算法时持平。

全网PS域掉线趋势图
25000 22500 20000 17500 15000 12500 10000 7500 5000 2500 0 30.00 28.00 26.00 22.00 20.00 18.00 16.00 14.00 12.00 10.00 24.00

PS域掉线次数

RNC请求释放的分组域RAB数目

PS域无线掉线率

PS域掉线趋势图

PS域掉线率(%)

7月1日

7月3日

7月5日

7月7日

7月9日

7月11日

7月13日

7月15日

7月17日

7月19日

7月21日

7月23日

7月25日

7月27日

7月29日

7月31日

8月2日

8月4日

8月6日

8月8日

8月10日

8月12日

8月14日

8月16日

2.1.3 H频点调整
从UE的接入电平来看,PS掉话对应的电平信号质量一般,跟弱电平没有强相关性, 到小区的该信号质量区域进行测试,PS业务也正常。 该城市H频点规划只有1个频点,推测与单频点干扰相关。
PS掉话在各RSCP的分布

10% 36% 16% <-95 -94~-90 -89~-85 -84~-80 >-80

20% 18%

PS掉话在各RSCP的分布

为了验证PS掉话与H单频点干扰的相关性,在RNC 1T选择TOP小区调整频点,并对 这些小区进行簇跟踪。从话统数据来看,H频点更改后,该簇PS的掉话率由25%下 降到了5%,掉话率改善明显。

日期

HSDP A RAB 分配 成功 次数

HSDP A RAB 分配 请求 次数

PS HSDP RAB A掉 分配 话次 成功 数 次数

PS RAB 分配 请求 次数

PS PS 掉 HSDP RAB 话次数 A掉话 分配 (含 率 成功 HSDPA) 率

PS掉 话率( 备注 含 HSDP A)

1089 1302 1986 1432 1573 965 1197 759 1392 1445

1147 1336 2073 1522 1677 968 1203 773 1395 1446

364 361 468 522 349 62 68 90 107 38

1459 1606 2315 2047 2071 1203 1459 990 1561 1636

1523 1642 2405 2138 2176 1207 1465 1005 1564 1638

376 372 484 544 357 62 73 111 156 43

33.43 % 27.73 % 23.56 % 36.45 % 22.19 % 6.42% 5.68% 11.86 % 7.69% 2.63%

95.80 % 97.81 % 96.26 % 95.74 % 95.17 % 99.67 % 99.59 % 98.51 % 99.81 % 99.88 %

25.77 % 23.16 % 20.91 % 26.58 % 17.24 % 5.15% 5.00% 11.21 % 9.99% 2.63%

26号 凌晨0 点修 改, 数据 都是 只统 计修 改的 10个 小区;

2.1.4 减少弱覆盖 H频点干扰较大,弱覆盖区域的PS用户比较容易掉话,为了减少弱覆盖造成的PS接 入失败和掉话,可调整小区覆盖,后修改最小接入电平和异系统启动门限,让用户 尽量在2G网络使用业务。以下表用户为例,其接入电平平均在-96左右,如果可以 调整H频点可考虑优先修改H频点,如果不行,可考虑将最小接入电平修改为-98或95,同时注意修改异系统启动门限。

接入时间

IMSI

接入小区
东方半岛T2 东方半岛T2 东方半岛T2 东方半岛T2 东方半岛T2 东方半岛T2 东方半岛T2

RACH测量报告接入小区 PCCPCH RSCP -91(25) -94(22) -96(20) -99(17) -95(21) -94(22) -98(18)

10:26:34 46007711954XXXX 10:27:15 46007711954XXXX 10:53:45 46007711954XXXX 10:54:08 46007711954XXXX 10:54:40 46007711954XXXX 10:56:16 46007711954XXXX 20:58:21 46007711954XXXX

2.1.5 HS-PDSCH功率与PCCPCH功率对齐
对于弱覆盖、过覆盖、信号泄露的区域,通常需要通过修改PCCPCH的功率来调 整小区覆盖。之前的PCCPCH功率调整,没有考虑HS-PDSCH功率的响应调整,HSPDSCH功率与PCCPCH功率相差较大,从而造成HS-PDSCH相对于PCCPCH过覆盖、 弱覆盖。9月25日对1T、2T、4T、5T、6T下PCCPCH与HS-PDSCH功率相差较大的 小区进行功率对齐,PS掉话率由之前的8%下降到6.5%。
日期
RNC请求 释放的分 组域 RAB数 目 4408 2977 3423 4656 4317 4298 3928 分组域 RAB指派 建立成功 的RAB数 目 46666 42365 42855 46617 49295 48496 50142 PS域无线 掉线率

9.45% 7.03% 7.99% 9.99% 8.76% 8.86% 7.83% 16点,修改全网DSCH 功率,原则PCCPCHDSCH不在0-30范围进 行修改,保持和 PCCPCH一致;

3716
2605 2848 3470 3493

50359
43560 44807 50676 49295

7.38%
5.98% 6.36% 6.85% 7.09%

PCCPCH与HS-PDSCH功率对齐对PS掉话的影响

2.1.6 缩短“PS永久在线定时器”
当UE的PS业务没有流量时,尽快将其RB释放,一方面可以降低掉话的机率,另一 方面UE当有业务需求时会再次发起RRC建立和业务请求,可再次进行RB建立,增加 了RAB建立次数,从而降低PS掉话率。 从话统可以看出,23日修改7个RNC的“PS永久在线定时器”由之前的60S到45S后, PS掉话率由之前的11%下降到7%。
PS域 RAB 指派 建立 成功 RAB 数目 时间 11434 4 12043 0 12701 6 14924 2 11594 4 12223 6 12866 4 15106 3 98.62 94546 98.52 99331 10558 98.72 5 12796 98.79 9 95152 99868 10617 6 12867 8 PS域 RAB 建立 请求 的 RAB 数目 PS域 RRC 连接 建立 成功 次数 PS域 RRC 连接 建立 尝试 次数 PS域 RRC 连接 建立 成功 率 (呼 叫相 关) 99.36 99.46 99.44 99.45 RNC请 求释 放的 分组 域 RAB 数目 分组 域 RAB 指派 建立 成功 的 RAB 数目 11434 4 12043 0 12701 6 14924 2

PS域 RAB 建立 成功 率

PS域 无线 接通 率

PS域 无线 掉线 率

97.99 12611 97.99 12265 98.17 12003 98.25 10787

11.03 10.18 9.45 7.23

PS永久在线定时器对PS掉话的影响

3 PS异系统切换成功率问题定位分析
首先从为产品问题、TOP小区问题、终端问题、无线环境及干扰问题等五方面来分析 PS接通率。 产品问题 通过话统数据发现,每天TOP小区通常为1个UE连续切换失败造成的。在RNC4.0.1 SP100版本,依靠惩罚机制,减少的异常切换失败次数可以将PS的切换成功率提升 10个百分点左右。 TOP小区问题 通过话统数据发现,每天TOP 10的小区造成了超过总切换失败次数的一半以上,因 此,可针对TOP小区进行问题处理,提升网络KPI。

终端问题 通过PCHR数据分析和问题验证,推测三星手机在DCCC流程与切换流程冲突时,容 易造成异系统切换失败,所以可从DCCC策略入手,优化参数减少频繁升降速。 无线环境和干扰 针对TOP小区,排查现网的无线环境,查看其是否是由于过覆盖、弱覆盖、信号泄 露、干扰等无线环境原因造成的。RNC上配置的2G邻区存在同频组网时,容易造成 异系统切换失败,因此,应尽量避免。

3.1 具体问题定位措施
3.1.1 问题小区处理 PS23G切换坏小区选取需同时满足条件1和条件2: 条件1:{ PS域3G-2G切换尝试次数(小区)- PS域3G-2G切换成功次数(小区)}>=3 条件2:{ PS域3G切换2G成功率(小区)}<=0.85; 通过对PS23G切换TOP小区的处理,在网络业务量不断增加的情况下,CS23G切换坏小区 数目从6月末的83个减少到9月末的22个,减少了73.49%,9月末的坏小区比8月末的坏小 区略多主要是因为切换次数从2419次增加到5461次,整体基数上升导致。如下图所示:

PS异系统切换坏小区趋势图

3.1.2 单用户频繁上报3A导致大量切换失败
网络优化调整前全网PS切换成功率维持在78%左右,PS切换失败统计的原因值90%以 上为”物理信道失败”。通过话统数据发现,每天TOP 10的小区造成了超过总切换失 败次数的一半以上, 而每个小区的大量切换失败,通常为1个UE连续切换失败造成的。 下表为统计数据: 单用户造成连续切换失败统计
全网->切换请求 次数 7.22日 7.23日 7.24日 7.25日 7.26日 7.27日 2735 2903 2974 1841 1937 2879 全网->切换成功次 全网->切换失败次 数 数 2040 2295 2269 1529 1601 2065 695 608 705 312 336 814 TOP10小区单用户造成 的切换失败次数 349 179 344 129 129 434

7.28日

2738

1922

816

453

根据上述统计结果,理论分析,如果使用RNC4.0.1 SP100,依靠惩罚机制,减少的 异常切换失败次数可以将PS的切换成功率提升10个百分点左右 RNC4.0.1 SP100版本解决了单用户重复上报3A导致大量切换的问题,升级后PS切换 成功率大幅提升到88%左右,与我们的理论分析一致。

时间 (升级前) (升级前) (升级前) (升级前) (升级前) (升级前) (升级前) (升级前) (升级后) (升级后) (升级后) (升级后) (升级后) (升级后) (升级后)

PS域3Gto 切 换请求次数
2115 2219 2268 2616 2585 2735 2903 2974 2212 2357 1907 1640 1334 1550 1638

PS域3Gto 切 换成功次数
1851 1684 1753 2108 2081 2040 2295 2269 1916 2073 1694 1458 1200 1389 1451

PS域3Gto 切 换成功率
87.52 75.89 77.29 80.58 80.50 74.59 79.06 76.29 86.62 87.95 88.83 88.90 89.96 89.61 88.58

SP100版本前后指标对比

3.1.3 话统切换请求总数不等于切换失败与切换成功次数的和
话统中统计的数据,从下表可以看出,占总切换次数的约4%的PS系统间切换既没 有被统计为切换成功也没有被统计为切换失败。
2009-09-19话统数据(成功次数+失败次数不等于总切换次数) 起始时间 PS 域系统间切换 出请求次数(>GPRS) PS 域系统间切换 出成功次数(>GPRS) 分组域系统间切换出 失败次数 (->GPRS) 既没有统计为切换成功 也没有统计为切换失败 的次数

4990

4645

242

103

那么这103次切换到底是成功还是失败呢?接下来我们对PCHR的统计数据进行了分析。
UE_LOST( 46) 92 信 道 配 置 超 时 切换超时 (185468901) (无响应) 27 8 分组域系统间切换 出失败次数 (物理信道 >GPRS)<不可知 失败 错误> 18 175 RNC异常释 放导致的切 换失败 11

总计

331

2009-09-19PCHR切换失败统计数据

对比PCHR和话统中的按切换失败原因分项进行的统计我们可以看到,PCHR统计到 的切换失败次数为331次,则说明表2-3中既没有统计为切换成功也没有统计为切换 失败的103次切换,基本上为切换失败。 而分析信令可以看出如果在PS进行系统间切换失败时,如果UE通过Cell update返回 3G,则RNC对于这个呼叫将漏统计,也就是既不统计为切换失败也不统计为切换成 功。 其典型信令流程如下:

Cell update导致切换不被统计的信令流程图

如果要真实体现PS的系统间切换成功率,应该在PS系统间切换流程中,考虑收到 Cell update的影响,将这种流程统计为切换失败

3.1.4 PS系统间切换超时释放
其典型信令流程如下

PS系统间切换超时信令流程

PCHR和话统中都统计到8次超时释放的切换失败,与话统数据一致。该问题集 中于联芯系终端。

3.1.5 pS系统间切换发生“不可知错误原因的失败”
对比发生该原因切换失败的分时话统和PCHR数据,我们得到以下的统计数 据和PCHR信令。这18次不可知原因的切换失败都是由于三星系终端造成
三星报不可知错误的切换失败次数 终端类型 三星i688 三星L288 发生不可知错误的切换失败次数 15 3

发生这种切换失败的典型信令流程图如下:

PS切换失败原因值为“不可知错误

从信令流程上看到,DCCC触发了下行频繁升降速。“RB recfg cmp”与PS 异系统切换命令“cell change order from UTRAN”间隔10ms,随后UE上报 “cell change order from UTRAN fail”。此现象多次发生,信令流程及时间 间隔基本一致。 导致以上现象的原因是:由于下行DCCC策略没有经过优化,现网中采用 的默认参数比较极端,相当于“快升快降”,如下行64k对应的4A门限为 1024,触发时间为240ms,4B门限为256,触发时间为1280ms。这样的参 数导致下行频繁升降速。 RB重配流程与PS异系统切换流程间隔(10ms)太短,可能导致三星系UE 的处理出现问题,目前发现三星系终端此现象比较突出,其他终端暂未发 现该现象。

从现象上看,由于怀疑是DCCC流程与切换流程冲突导致三星系手机切换 失败,所以从DCCC策略入手,优化参数减少频繁升降速。通过信令分析, 发现重配主要发生在16k、32k、64k三档速率之间。RAB指派业务类型为 交互类,上下行对称128k。RB建立上行16k,下行64k,业务建立不久容易 发生降速。经测试,UE发起wap浏览业务表现为以上现象。 现网默认的下行DCCC策略见下表。

参数 升降速级别 中间速率的计算

参数值 三降 自动

下行BE业务初始接入速率
16k 32k

128k
1k 640ms 4k 2560ms 4B 64 640ms

64k

修改前的DCCC策略

4B 256 1280ms

将以上参数策略修改为下表所示。
参数
升降速级别 中间速率的计算 下行BE业务初始接入速率

参数值
三降 自动 128k

16k
32k

1k 5000ms
4k 2560ms 4B 16 2560ms 4000ms(pending time)

64k

4B 16 2560ms 4000ms(pending time)

CORRMSOFTPARAINDEX=26, 修改后的DCCC策略 37

修改后的参数策略相当于“慢升慢降”。对于26号软参,根据资阳的经验,设置为 32k降速需要5个4B报告(至少16s),64k降速需要2个4B报告(至少4s)。 分析参数修改后的话统,发现流程冲突的现象得到一定程度的缓解。26号软参对下 行DCCC起作用,降速过程明显变慢。 我们对比了参数修改前后5日的话统指标:
修改前的不可知错误的次数(日) 26 30 24 33 27

修改后的不可知错误的次数(日)

11

21

21

18

15

DCCC算法优化对不可知错误PS切换失败的影响

这种不可知错误的切换失败从之前的30次左右下降到20次左 右,有明显的改善,但没有完全消除。

3.1.6 物理信道失败 的原因
对于物理信道类的切换失败,网络侧并没有更多的办法可以进行优化,这种切换失 败通常是由于终端和无线环境的原因造成的,只能通过调整参数改善无线环境以及 要求终端改善无线性能进行提高。 网络侧只能通过减少不必要的切换尝试来减少切 换失败。 在完成RNC4.0.1 SP100升级后,从PCHR中可以看到,单用户造成的切换失败次数大 幅度降低,指标也得到极大的改善,但仍然可以看到单用户超过3次以上的连续切 换失败。 这是因为在该版本中系统间切换最大允许次数默认为16,而由于单次呼叫中,第一 次呼叫的切换成功率最高,依次递减,因此为了确定最佳的参数设定,限制后面不 必要的切换尝试失败,我们进行了以下的数据分析。 我们选取了约一个礼拜的PS切换的统计分析,如下表,我们以每呼叫进行的切换次 数做为纵坐标,进行了如下的统计。

异系统切换发起次数 (每呼叫) 1 2 3 4 5 6 15 总计

异系统切换失败次数 1413 298 56 25 17 10 15 1834 PS切换统计

异系统切换次 数 13880 476 69 28 20 12 15 14500

异系统切换 成功次数 12744 181 13 3 3 2 12946

异系统切换 的呼叫次数 13880 238 23 7 4 2 1 14155

对于上表,我们以第一行为例,该行表示统计的是呼叫中只发生了一次切换的所 有呼叫所产生的总的切换失败次数(1413),总的切换次数(13880),总的切换 成功次数(12744),只发生过一次切换的所有呼叫共13880次 下表是如果我们将系统间切换次数从15减小到1或2,对各KPI造成的影响如下:例如减 小到2,即只允许呼叫发起2次系统间切换尝试,那么超过2次的所有切换将被禁止, 不再发生,从下表我们可以看出,将减少124次切换失败和21次切换成功。 如果我们 假设这21次本来能成功的切换由于被禁止而导致掉话(实际上也许会发生系统内切换 而不会掉话),则我们将提高0.8%个百分点的切换成功率,对掉话率的影响将远小于 0.14%(因为我们这里用发生过切换的PS切换次数作为分母,而实际的PS呼叫次数肯定 是大于发生过切换的PS呼叫次数的)。

超过N 次切 换的 呼叫 次数 系统间 切换次 数设为 2 系统间 切换次 数设为 1

超过N次切 减少的 换能切换成 失败次 功的呼叫次 数 数

减少的 成功次 数

对切 换指 标改 善的 影响

对掉 话率 的影 响

37

21

123

21

0.80%

<0.14 %

275

202

421

202

3%

<1.4%

异系统最大切换次数配置分析

从上表我们可以得出结论,但系统间切换最大切换次数配置为2时,将提高 切换成功率0.8个百分点,而几乎不会造成掉话等负面影响。 因此全网按此 参数进行了设置。

3.1.7 切换过程中由于RNC异常释放导致的切换失败 我们统计分析发现,PS切换存在下列典型的异常信令流程:

UE收到Cell change order命令后,进行切换
RNC收到RANAP_SRNS_CONTEXT_REQ,说明UE已经成功完成了在 2G的物理接 入,2G SGSN收到UE的RAU更新请求。 RNC也及时的回应了 RANAP_SRNS_CONTEXT_RESP 由于由以下参数配置: NOUTSYNCIND=20, TRLFAILURE=200

表示NodeB将在无线链路失步后23.2秒上报RL FAIL IND,
然后按NodeB和维护部同事给出的解释,NodeB的RECCTT定时器将决定在上 报RL FAIL IND后,什么时候上报NBAP_RESET_REQ,而RNC收到该消息后,将 发送IU release request给核心网,导致该次切换失败。 但目前现网的RECCTT参数设置为60,按NODEB给出的解释,说明NODEB 将 在发送RL FAIL IND 6秒后,上报释放消息NBAP_RESET_REQ。 但根据PCHR抓 到的信令看,NodeB应该是在固定的17秒后(也即RNC发起切换后40秒)上 报的NBAP_RESET_REQ,释放呼叫,与NodeB的解释不一致。目前NODEB没 有给出进一步的解释。

目前RNC通常在40秒左右超时,发送IU_Release_Req对这个呼叫进行了释放,导致切 换失败。

RNC异常释放导致的切换失败

为了提高切换成功率,我们进行了以下的2个方案的修改尝试。 发生此种切换的关键问题是由于PS系统间切换所需的流程较长,甚至长于1分钟。要减 少因这种原因导致的PS系统间切换失败,只能提高定时器超时的时间。

尝试的规避方案一:

基于NODEB给出的解释,我们修改了RECCTT定时器,从60修改为250,表 示NODEB应该在发送RL RAIL IND后25秒上报NBAP_RESET_REQ释放呼叫。 但从PCHR中的信令看,RNC在PS业务中,收到RL RAIL IND后17秒发起释 放,与修改前一致,没有任何改善。
但对于CS业务,我们可以看到以下的信令流程图

RECCTT=250时 CS释放时间

RECCTT=60时 CS释放时间

但RECCTT=60时,CS在收到无线链路失败后2秒释放,而RECCTT=250时,CS在17秒后释 放。 但对于PS业务,在修改前后没有任何变化,这让人比较费解,已经提单,等待 NODEB给出解释。

结论:修改RECCTT定时器不能改变PS的释放时间

尝试的规避方案二: 为了延长释放时间,我们尝试延长无线链路失败定时器,从而获得更多的时间来提高PS的 切换成功率。 从修改后的现象和信令看,延长无线链路定时器后,原来在话统中既不统计为切换成功 也不统计为切换失败的更多的切换失败(PCHR中统计为”UE Lost”的切换失败)转化为话 统中可见的“切换超时”的切换失败,导致表面上的切换成功率反而下降了。 修改参数前,按切换失败次数计算的切换成功率比真实的切换成功率虚高约2个百分点 以上,修改参数后,按切换失败次数计算的切换成功率比真实的切换成功率高约不到1 个百分点。 因此,修改无线链路失败定时器也不能提高按切换失败次数计算的切换成功率。 由于规避尝试失败,因此只能考虑通过网络侧修改处理流程来改善这种流程。通过PCHR, 我们统计到225次这种RNC异常释放的流程,占全部切换次数的1.6%。 也就是说,如果网 络侧修改流程解决这种异常释放,最大可以减少真正的切换失败率1.6个百分点。 对于这 种异常流程,我们可以考虑以下解决思路: 在已经收到SRNS CONTEXT REQ的情况下,如果RNC收到NODEB的NBAP_RESET_REQ, 则进行 本地释放,释放无线资源和链路,但保留呼叫控制块,与核心网交互,完成该呼叫的切换 流程,然后释放。 我们系统目前本身有“Iu PS信令释放保护定时器” 其缺省值为300秒, 可以借鉴此流程。


相关文章:
TD-SCDMAPS域问题定位分析
如要投诉违规内容,请到百度文库投诉中心;如要提出功能问题或意见建议,请点击此处进行反馈。 TD-SCDMAPS域问题定位分析 TD-SCDMAPS域问题定位分析TD-SCDMAPS域问题...
TD-SCDMA PS域问题定位分析
TD-SCDMA PS域问题定位分析_互联网_IT/计算机_专业资料 暂无评价|0人阅读|0次下载|举报文档 TD-SCDMA PS域问题定位分析_互联网_IT/计算机_专业资料。...
TD-SCDMA CS域问题定位分析
TD-SCDMA CS域问题定位分析_互联网_IT/计算机_专业资料。产品名称 Product name...共 34 页 CS 域问题定位分析 文档密级: 内部公开 语音和 PS业务掉话率 (%)...
差小区处理方法
TD-SCDMA PS域问题定位分析... 30页 1财富值 最坏小区处理经验 3页 免费如要投诉违规内容,请到百度文库投诉中心;如要提出功能问题或意见建议,请点击此处进行反馈...
CS域讲解
CS域系统间切换出成功率... 4页 免费 CS域无线掉话分析处理 12页 1下载券 TD-SCDMA CS域问题定位分... 34页 4下载券 喜欢此文档的还喜欢 PS域简介 21页...
组合域业务中PS业务处理方法分析
TD-SCDMA PS域问题定位分... 30页 1下载券组​合​域​业​务​中...应用层各类软件太多,恢复机制也不清楚,不好分析。 (四)限制 PS 业务速率与 ...
CS域掉话分析
CS掉话TOPN小区分析 6页 1下载券 TD-SCDMA PS域问题定位分... 30页 1下载...CS 域掉话分析 中兴通讯学院 目 录 第 1 章 概述 ......
PS域异系统切换成功率研究与优化
TD-SCDMA PS域问题定位分... 30页 1下载券 PS异系统切换成功率的分... 19...14 3.3 PS 域异系统切换出成功率优化前后分析: ... 15 2 1 概述从 TD...
切换优化手册
6页 免费 TD-SCDMA PS域问题定位分析... 30页 1财富值如要投诉违规内容,请到百度文库投诉中心;如要提出功能问题或意见建议,请点击此处进行反馈。 ...
PS域互操作双向切换失败问题的分析解决案例
互操作双向切换失败的典型问题,介绍了 从无线侧到核心网详细的分析定位过程,并...关键词: TD-SCDMA、GSM、互操作、PS 域 1 前言 TD 网建设是一种创新性的...
更多相关标签:
td scdma | td scdma是什么意思 | td scdma gsm | td scdma是什么网络 | lte td scdma gsm | tdscdma频段划分 | tdscdma频段 | 红米td scdma gsm |