快速休眠策略在解决信令风暴中的 · 2016/07/dtpt 括以下3 个步骤。 a）扩容sccpch。开启fd，会将大量用户承载在 fach 及pch，为缓解fach 拥塞，实施信令风暴解决

2016/07/DTPT

——————————

收稿日期：2016-04-26

1 概述

随着3G技术的日趋成熟，智能终端的渗透率迅速

增加。智能终端内置软件频繁地与 Internet服务器同

步通信，带来了大量的小数据传输 PS业务，对 CN、

RNC和NodeB造成了信令冲击。这些小数据传输业

务本身不会给运营商带来收益，因此如何减少智能终

端与网络的信令交互，降低CN、RNC SPU板、PIU板和

NodeB基带板的CPU负荷，成为信令风暴解决方案关

注的焦点，简单地说，智能终端解决方案就是通过使

智能终端永久在线的方法，来减少用户反复接入和释

放过程中的信令交互，因此，可以应用快速休眠（FD）功能来解决这个问题。

2 基本原理介绍

FD的状态转化如图1所示。

在日常应用中，当网络侧未开通FD功能时，用户

手机在没有数据传送时，为了省电，智能终端发送

SCRI（SIGNALLING CONNCETION RELEASE INDICA⁃TION）消息给RNC，同时发起RRC连接释放，UE迁移

到 Idle状态。此后，当UE再次发送心跳消息时，将导

致RRC连接建立、鉴权、加密和RAB建立，这样就增加

了RNC的信令处理负荷。

针对以上情况，在FD方案中，R5到R8 的终端在

快速休眠策略在解决信令风暴中的研究及应用

关键词：WCDMA；快速休眠；高校；基站信令负载；优化

doi：10.16463/j.cnki.issn1007-3043.2016.07.016中图分类号：TN929.5

文献标识码：A

文章编号：1007-3043（2016）07-0078-07

摘要：针对中国联通福州分公司在日常优化过程中3G网络用户迅速增加和智能终

端不断普及带来的信令风暴对RNC、NodeB等网络设备造成较大冲击、导致

用户感知下降问题，通过对WCDMA快速休眠功能进行研究，在网络侧开通

终端的快速休眠功能，对终端迁移策略进行优化调整，并在高负荷区域进行

方案验证及效果评估，摸索出一套行之有效的优化方法，缓解信令风暴对网

络的冲击，有效降低网络设备负荷，解决热点区域拥塞问题，提升用户感知。

Abstract：In the daily optimization of China Unicom Fuzhou Branch，the fast growing of 3G users and the constant popularity of intelligent

terminals cause signaling storm，which impacts RNC and NodeB and leads the decline of user perception. The fast dormancy is

researched and the fast dormancy function of terminals is realized in network side. The terminal migration scheme is adjusted，

the solution verification and effects evaluation are made on high load area. Based on the above，an effective optimization meth-

od is gotten to relieve the impact of signaling storm on the network，to effectively decrease the load of network equipment and

solve the congestion of hot area to improve user perception.

Keywords：WCDMA；Fast dormancy；University area；Signaling load；Optimization

陈锋（中国联通福州分公司，福建福州 350001）Chen Feng（China Unicom Fuzhou Branch，Fuzhou 350001，China）

Research and Application of Fast DormancyStrategy to Solving Signaling Storm

无线通信Radio Communication

陈锋快速休眠策略在解决信令风暴中的研究及应用

78

邮电设计技术/2016/07

SCRI 消息中会携带 cause 为“UE Requested PS Datasession end”的信元，网络侧根据这条信息，将这些终

端迁移到Cell_FACH或者Cell_PCH状态，当UE再次

有数据传输需求时通过P2F2D或者P2F的方式来完成

数据传输，从而减少信令开销，节约系统资源。对于

SCRI消息中携带其他 cause或者不带 cause的终端，将

直接释放，UE回到 Idle状态。

从以上可以看出，通过将UE的驻留状态从专用

信道迁移到公共信道，可以节省信令面资源。

下面从UE的各个驻留状态介绍终端发起一次数

据传输在网络侧产生的信令流程。

a）对于 Idle状态的用户，从发起RRC连接到RNC收到 SCRI后释放RRC连接回到 Idle状态，总共需要

31条消息（见图2）。b）由于大量数据传输，处于 Cell_PCH状态的用

户迁移到 Cell_DCH 状态，数据传输结束后再回到

Cell_PCH状态，需要20条消息（见图3）。c）P2F2P 信令流程：由于少量数据传输，处于

Cell_PCH状态的用户迁移到Cell_FACH状态，数据传

输结束后再回到Cell_PCH状态，只需要 6条消息（见

图4）。从上面流程图可以看出，对于大数据传输需求，

采用 P2F2D2F2P方案，UE接入产生的信令流程为 20条信令，对于小数据传输需求，P2F2P方案，UE发起一

次数据传输产生了 6条信令，相比于以前空闲态的方

案，增益最大可以达到80％（见表1）。综上所述，FD功能能够较好地节省信令面的信令

数量，从而大幅降低RNC的信令负荷，能够较好地解

决目前存在的信令风暴问题，具备一定的推广价值。

3 具体方案实施

福州FZRNC1413下辖基站处于福州大学城区域，

日常话务量流量很高，用户活跃，信令风暴问题比较

严重，使用该RNC进行验证工作，整体方案实施共包

图1 FD的状态转化图

图2 Idle状态下的数据传输流程图

CELL_DCH CELL_FACH4BSCRITime out4A

CELL_PCH

IDLERRC release switchis turned on

D2F failure due toFACH congestion

Time outSCRI CS paging

（FACH congestion）4B 4BTime out

SCRIHeartbeat

Time out

31 Signall

ing messag

es

SGSNRNCNode BUERRC CONNE CTION REQUESTRADIO LINK SETUP REQUESTRADIO LINK SETUP RESPONSERADION LINK RESTORE INOICATIONRRC CONNE CTION SETUPRRC CONNE CTION SETUP COMPLETEDEDICATED MEASUREMENT INITLATION REQUESTDEDICATED MEASUREMENT INITLATION REQUESTDEDICATED MEASUREMENT INITLATION RESPONSEDEDICATED MEASUREMENT INITLATION RESPONSEMEASUREMENT CONTROLINITIAL DIRECT TRANSFER（Service request）COMMONIDSECURITY MODE COMMANDSECURITY MODE COMPLETERAB ASSIGMMENT REQUESTRADIO LINK RECONFIGURATION PREPARERADIO LINK RECONFIGURATION READYRADIO LINK RECONFIGURATION COMMITRADIO BEARERSETUPRADIO BEARER SETUP COMPLETERAB ASSIGNMENT RESPONSEMEASUREMENT CONTROLUSERDATASIGNALLING COMMECTION RELEASE INOICATION（or motrggerpsinsctive）IU RELEASE REQUESTIURELEASE COMMANDIU RELEASE COMPLETERRC CONNE CTION RELEASERRC CONNE CTION RELEASE COMPLETERADIO LINK DELETION REQUESTRADIO LINK DELETION RESPONSE

DCH



79

2016/07/DTPT

括以下3个步骤。

a）扩容SCCPCH。开启FD，会将大量用户承载在

FACH及PCH，为缓解FACH拥塞，实施信令风暴解决

方案之前必须添加1条SCCPCH，PCH和FACH分别承

载在不同 SCCPCH上。扩容 SCCPCH还需注意以下 3点。

（a）如需要增加第 2条 SCCPCH来缓解 FACH拥

塞，则需要对该 RNC 下所有小区都增加第 2 条 SC⁃

CPCH，避免从 1条 SCCPCH到 2条 SCCPCH的重选。

后续新建的站点也不例外，需要配置2条SCCPCH。

（b）由于终端系统消息更新不及时，添加第 2条

SCCPCH后小区RRC建立成功率会暂时下降，重新读

取系统消息后指标会逐渐恢复。协议规定UE最长6 h读取一次系统消息，系统消息更新后指标恢复，因此

建议扩容操作应在夜间执行。

（c）配置 2条 SCCPCH会额外消耗资源：满负荷

时，1条 SCCPCH消耗小区下行功率的 10%。2条 SC⁃CPCH同时发送数据时，RRC连接和CS业务下行可用

功率略微减少。经验显示，小区平均消耗功率在60%以下时，添加第 2条 SCCPCH效果较好。另外会额外

消耗1个SF128的码。

表1 不同流程信令数目对比

图3 P2F2D2F2P流程图

图4 P2F2P信令流程

方案

Idle2DCH2IdleP2F2D2F2PP2F2P

信令数目/条31206

增益比例/%-3580

UE NodeB RNC SGSN

DCH20 Signa

llingmess

ages

FACH

CELL UPDATECELL UPDATE COMPLETEPHYSICAL CHANNEL RECONFIGURATION COMPLETEMEASUREMENT CONTROLUSER DATARADIO LINK SETUP REQUESTRADIO LINK SETUP RESPONSERADIO LINK RESTORE INDICATIONRADIO BEAR RECONFIGURATIONRADIO BEAR RECONFIGURATION COMPLETEMEASUREMENT CONTROLDEDICATED MEASUREMENT INITIATION REQUESTDEDICATED MEASUREMENT INITIATION REQUESTDEDICATED MEASUREMENT INITIATION RESPONSEDEDICATED MEASUREMENT INITIATION RESPONSEUSER DATARADIO BEAR RECONFIGURATION（ps inactive）RADIO BEAR RECONFIGURATION COMPLETERADIO LINK DELETION REQUESTRADIO LINK DELETION RESPONSERADIO BEAR RECONFIGURATION（ps inactive）RADIO BEAR RECONFIGURATION COMPLETE

UE NodeB RNC SGSN

6 Signalli

ng messa

ges

FACH

CELL UPDATECELL UPDATE COMPLETEPHYSICAL CHANNEL RECONFIGURATION COMPLETEMEASUREMENT CONTROLUSER DATARADIO BEAR RECONFIGURATION（ps inactive）RADIO BEAR RECONFIGURATION COMPLETE



80


b）修改Iu-PS激活因子。由于Cell_PCH/URA_PCH状态用户即使没有数据传输，也会占用 Iu-PS准入带

宽。因此，为了避免Iu-PS口准入失败，实施Cell_PCH、R8FD或EFD前，必须修改 Iu-PS口邻节点激活因子。激

活因子的推荐值为10%，如果设置值已经小于10%，则

维持已有配置不变。

c）多载波配置。在原有倾向驻留业务分层基础

上，针对FACH态进行偏置设置。需要先开启F2/F3小区的 SIB4和 SIB12开关，其次在本小区设置 FACH态

迟滞，针对同频邻区和异频邻区设置Qoffset。

4 实施效果评估

4.1 话统KPI效果评估

由于2014年4月5日—7日为清明节，因此效果评

估选择对比时间点：实施前 4月 1日—4月 2日与实施

后4月8日—4月9日。

4.1.1 话务及流量变化

方案实施前后，语音话务量、HSDPA/HSUPA、PS上下行流量正常波动，具体情况见表2。4.1.2 RRC连接成功率及RAB连接成功率

表6 FD实施前后PS域掉话率对比

时间

2014-04-012014-04-022014-04-082014-04-09

PS掉话率分子/次33 23337 35932 75534 092

PS掉话率分母/次

25 673 78826 664 10437 694 81738 605 398

PS掉话率/%0.13

0.14

0.09

0.09

HSDPA掉话分子/次27 95131 31124 05224 758

HSDPA掉话分母/次25 350 14126 334 54317 384 90217 822 669

HSDPA掉话率/%0.11

0.12

0.14

0.14

HSUPA掉话分子/次21 53424 12918 76319 356

HSUPA掉话分母/次23 987 12624 862 20916 566 28616 965 022

HSUPA掉话率/%0.09

0.10

0.11

0.11

R99掉话分子/次4 0104 6357 9238 617

R99掉话分母/次566 718569 055

25 555 84326 120 275

R99掉话率/%0.71

0.81

0.03

0.03

表2 FD实施前后话务量及流量情况对比

表3 FD实施前后RRC建立成功率对比

表4 FD实施前后CS域RAB建立成功率对比

时间

2014-04-012014-04-022014-04-082014-04-09涨幅/%

语音/Erl15 659.3415 588.4115 568.6716 134.16

1.46

下行流量/MB1 773 561.271 771 782.161 810 392.951 928 134.83

5.45

上行流量/MB321 457.79319 555.50313 738.06316 381.40

-1.70

HSDPA流量/MB1 685 973.971 684 649.081 720 252.551 832 899.61

5.42

HSUPA流量/MB291 162.41289 399.58285 023.33287 937.94

-1.31

时间

2014-04-012014-04-022014-04-082014-04-09涨幅/%

RRC建立成功率/%

98.544 398.622 099.770 299.705 61.17

RRC连接建立请求次数/次

28 423 64529 143 32310 710 85510 979 420-62.32

RRC连接建立成功的次数/次28 009 88628 741 73810 686 24610 947 100-61.88

时间

2014-04-012014-04-022014-04-082014-04-09涨幅/%

CS域RAB指配建立成功的AMR业务

RAB个数/个427 641391 732384 763409 771-3.03

CS域RAB指配请求建立语音业务的RAB个数/个

429 502393 308386 680412 049-2.93

CS域RAB建立成功

率/%99.5799.6099.5099.45-0.11

表5 FD实施前后PS域RAB建立成功率对比

时间

2014-04-012014-04-022014-04-082014-04-09涨幅/%

PS域RAB指配建立成功的AMR业务

RAB个数/个25 704 90526 693 5779 268 4489 467 272-64.24

PS域RAB指配请求建立语音业务的RAB个数/个25 839 41526 821 5599 302 1159 508 936-64.28

PS域RAB建立成功

率/%99.4899.5299.6499.560.10

4.1.2.1 RRC建立成功率

RRC连接请求次数下降了62.32%，平均每天下降

1 783万次，RRC连接建立成功率在FD方案实施后指

标有所好转，涨幅为1.17%（见表3）。

4.1.2.2 RAB建立成功率

CS RAB建立请求次数下降了 3%，平均每天下降

1.2万次，语音RAB建立成功率基本保持平稳（见表

4）。PS RAB建立请求次数下降了 64.28%，平均每天

下降1 692万次，PS RAB建立成功率基本保持平稳（见

表5）。4.1.3 PS域掉话率

如表 6所示，PS掉话率在快速休眠功能实施后下

降了 0.04%；HSDPA 及 HSUPA 的掉话率均上升了

0.02%，R99的掉话率由0.75%下降至0.03%左右。

4.1.4 用户数



81

2016/07/DTPT

FD 功能实施后 DCH 状态用户数均明显下降，

FACH用户及PCH状态用户数明显增加。DCH态用户

平均每天下降了1 892个，FACH态用户增加了 1 870个，PCH态用户增加了15 221个（见表7）。

4.1.5 CE使用数

上行 CE 数每小时平均下降 7 941 个，下降

18.56%，下行 CE 数每小时平均下降 2 202 个，下降

19.73%（见表8）。

4.1.6 RTWP及功率

平均上行负荷下降了 0.2 dB，小区下行平均功率

下降0.14 dB，功率利用率下降0.81%（见表9）。

4.1.7 寻呼

4.1.7.1 RNC1413收到及下发寻呼量

UTRAN寻呼消息1每小时平均增加了37万次、寻

呼消息2每小时平均降低了806次（见表10）。寻呼空闲用户的寻呼消息数量较功能开通前每

小时平均下降了 12万次，下降比例为 35.52%（见表

11）。4.1.7.2 RNC1413小区寻呼消息数量变化

如表12所示，小区空口寻呼消息每小时平均下降

24万次左右，下降比例为 34.6%。寻呼消息拥塞导致

丢弃次数每小时下降了 598次，下降比例达 89.2%（按

照RNC下所有小区寻呼消息平均值）。

4.1.7.3 SCCPCH扩容后对接入时延的影响

FACH 与 PCH 分离后，可将 RRC 建立时延降低

8 ms左右（见表13）。

4.1.8 基站信令负载

基站信令负载：VS.IUB.AttRLSetup+VS.IUB.AttR⁃

时间

2014-04-012014-04-022014-04-082014-04-09下降次数

下降比例/%

小区寻呼消息拥塞次数/（次/h）627.12715.3169.6875.12

598.8289.21

小区寻呼消息次数/（万次/h）695 332.67713 157.22458 549.59462 414.21243 763.04

34.61

时间

2014-04-012014-04-022014-04-082014-04-09下降幅度

下降比例/%

Cell_FACH状态RRC连接建立时延/ms

592.42603.67586.62593.18

8.141.36

Cell_DCH状态RRC连接建立时延/ms

480.16482.42469.70474.91

8.991.87

表12 FD实施前后小区寻呼量变化情况

表13 SCCPCH扩容后对接入时延的影响

表7 FD实施前后不同状态用户数变化情况

表8 FD实施前后CE使用数变化情况

表9 FD实施前后RTWP及功率变化情况

表10 FD实施前后RNC寻呼量变化情况

表11 FD实施前后空闲用户寻呼量变化情况

时间

2014-04-012014-04-022014-04-082014-04-09

PCH用户数/个0.000.00

14 969.0715 474.59

FACH用户数/个23.9417.41

1 867.711 914.16

DCH用户数/个8 773.508 921.516 882.927 028.01

时间

2014-04-012014-04-022014-04-082014-04-09下降个数

下降比例/%

上行CE使用数最大值/个

129 325131 651114 578115 26815 56511.93

上行CE使用数平均值/个42 523.4343 074.5734 455.9735 258.957 941.5418.56

下行CE使用数最大值/个

30 13430 71225 45925 4254 98116.37

下行CE使用数平均值/个11 084.0711 242.828 858.159 063.122 202.8119.73

时间

2014-04-012014-04-022014-04-082014-04-09涨幅 /%

平均RTWP/dBm-103.52-103.39-103.65-103.69-0.21

下行平均功率/dBm37.9237.9337.7637.81-0.14

下行平均功率（非HS）/dBm

37.5137.5337.3537.37-0.16

时间

2014-04-012014-04-022014-04-082014-04-09下降次数

下降比例/%

寻呼消息1/（万次/h）0.000.00

366 684.67376 453.58

-371 569.13-

寻呼消息2/（万次/h）7 767.137 029.426 448.886 734.08806.7910.91

时间

2014-04-012014-04-022014-04-082014-04-09下降次数

下降比例/%

空闲用户寻呼次数/（万次/h）353 533.25360 760.04229 183.71231 428.25126 840.6735.52%

CS寻呼次数/（万次/

h）47 796.0041 072.2138 739.5839 328.425 400.1012.15%

CS寻呼丢失次数/

（万次/h）6.38

260.710.000.00

133.54100.00%

PS寻呼次数/（万次/

h）313 626.96327 085.88202 778.42205 080.46116 426.9836.34%

PS寻呼丢失次数/

（万次/h）3.46

14.210.000.008.83

100.00%



82


LAdd+VS.IUB.AttRLRecfg×2，针对20：00（忙时）指标进

行对比，整体基站信令负载次数每小时平均下降 284万次，下降幅度为27.62%（见表14）。

4.1.9 XPU负荷

RNC1413的XPU平均利用率下降了 6.16%，下降

比例为17.71%（见表15）。

4.2 路测指标对比

4.2.1 测试环境

系统配置如表16所示。

4.2.2 PING测试对比

Ping包大小使用 256 B，每次 Ping测试时长 10 s，Ping测试时间间隔 20 s，循环测试 500次，测试指标对

比如表17所示。从测试结果来看，FD打开后，Ping时延有所改善，小于 100 ms的比例由 10%提升到 30%，

平均时延下降20 ms左右。

4.3 状态转化情况

4.3.1 DCH→PCH如图 5所示，01：41：04 UE发送 SCRI后UE收到

RB RECFG至PCH态。

4.3.2 PCH→Idle如图 6所示，01：41：16后UE进行PCH态，30 min

后UE无数据传输，在 02：11：16 RNC往CN发送RAB释放请求，原因值为User inactivity。5 结论

综上所述，总结FD的增益主要包括以下几点。

a）FD由于不再释放RRC，因此RRC连接次数下

降了 62%，从而节省了RRC连接建立所需要的资源，

大大提升了RRC建立成功率。

b）由于大量手机承载在CELL-PCH模式下，因此

该模式下的寻呼消息大量增加，而空闲态下的寻呼消

息明显减少，由于RRC建立成功率提升，使得空口寻

呼拥塞导致的寻呼丢弃次数下降89.2%。

c）基站上下行 CE 均有明显下降，降幅大约为

20%。

d）RNC的XPU单板的负荷下降了17.71%。

e）整体基站信令负载次数（RL建立请求次数）每

小时平均下降284万次，下降幅度为27.62%。

从上面罗列的FD增益可以看出，FD策略从用户

应用实际出发，通过用户行为的研究，采用类似于状

态迁移的策略，有效改善基站整体信令负载，节省无

线资源，成功解决了信令风暴带来的问题，为解决业

FR实施前XPU平均利用率/%2014-04-01

34.462014-04-02

35.12

FR实施后XPU平均利用率/%2014-04-08

28.632014-04-09

28.63

表16 系统配置表

PING测试

FR关闭

FR打开

平均值/ms140120

最大值/ms297172

最小值/ms7878

≤100/%10.0030.00

（100~120］/%10.0020.00

（120~140］/%30.0025.00

>140/%50.0025.00

表17 FD实施前后PING时延变化情况

参数名

Fast Dormancy功能开关

4A/4B状态迁移开关

定时器323

TAC匹配算法开关

Fast Dormancy用户是否做信令连接释放开关

FD用户D2P开关

Fast Dormancy用户CELL_DCH状态T1Fast Dormancy用户CELL_FACH状态T1Fast Dormancy用户CELL_PCH状态T1Fast Dormancy用户FACH/E_FACH2DCH/HSPA 4A门限

备注

打开FD总开关

保证 DRA_PS_BE_STATE_TRANS_SWITCH设置为1设置 T323为D0，根据现网经验意味着很多终端在一次RRC连接过程中只发一次SCRIFD_TAC_MATCH_SWITCH（TAC 匹配算法开关）开关打开时，RNC通过TAC匹配识别终端是否应用 FAST DORMANCY功能。开关关闭时，RNC 对 R5 以上所有终端应用FAST DORMANCY功能

RNC_FD_SCRI_FORCE_REL_SWITCH（FastDormancy用户是否做信令连接释放开关）开关打开，RNC收到UE的信令连接释放指示如果携带释放原因“UE Requested PSData session end”，进行状态迁移，否则直接发起信令连接释放。开关关闭，RNC收到UE的信令连接释放指示，进行状态迁移

RNC级别 FAST DORMANCY用户D2F流程控制开关。0：表示打开，开关打开时，FASTDORMANCY用户触发D2F流程；1：表示关闭，开关关闭时，FAST DORMANCY用户触发D2P流程

设置PDCP不活动性检测机制的H2F定时器为4 s设置PDCP不活动性检测机制的F2P定时器为5 s设置CELL_PCH状态的FD用户的不活动性定时器为1 800 s

设置FD用户的F2D和F2H的4A门限为512B

表14 FD实施前后基站信令负载变化情况

时间

2014-04-01T20：002014-04-02T20：002014-04-08T20：002014-04-09T20：00下降次数

下降幅度/%

基站信令负载

9 964 99010 606 7547 318 9697 571 5432 840 61627.62

Iub接口RL增加请求次数

531 680548 447421 833453 806

--

Iub接口RL重配置尝试次数

2 865 5713 051 7322 219 8872 299 850

--

Iub接口RL建立请求次数

3 702 1683 954 8432 457 3622 518 037

--

表15 FD实施前后XPU平均利用率变化情况



83

2016/07/DTPT

务热点区域无线网络拥塞，提升用户感知，提供了可

行的解决方案。

参考文献：

［1］武奕峰 . 小流量数据业务时延分析与优化［J］. 信息通信，2014（12）：246.

［2］陈锋，陈腾林 . WCDMA手机状态迁移策略优化［J］. 闽江学院学

报，2015（2）：54-62.［3］周飞，王建春 . WCDMA网络RNC信令风暴研究［J］. 邮电设计技

术，2013（8）：62-66.［4］周晓龙，邸青玥，吕文琪 . 智能移动终端对移动网络流量影响研究

［J］. 信息通信技术，2013（4）：38-43.［5］何万欣 . 3G（WCDMA系统）移动终端设备协议栈接入层RRC协

议的软件实现［D］. 上海：上海交通大学，2007.［6］窦海波，张功耀，乔普 . 智能手机产生的信令风暴解决方案研究

［J］. 移动通信，2012（17）：76-79.［7］付昱霖 . 智能手机数据业务对典型3G移动通信系统性能影响的

研究［D］.北京：北京邮电大学，2014.［8］付皓，卢尹超，肖海 . 快速休眠时间对长在线终端待机功耗的影响

研究［J］. 移动通信，2015（9）：87-90.［9］苏小文，柯利忠，唐志超 . 智能终端对WCDMA网络的挑战及解决

方案［J］. 移动通信，2012（13）：12-16.［10］杨波 . 智能手机信令风暴探析［J］. 数字通信，2012（4）：81-83.［11］王宜科，刘亚柯，梁松柏，等 . Cell_FACH功能对W网的影响研究

［J］. 邮电设计技术，2014（8）：36-40.

图5 DCH状态到PCH状态

图6 PCH状态到 Idle状态

作者简介：

陈锋，毕业于福州农林大学，工程师，学士，主要从事无线网

优工作。



84

Documents

快速休眠策略在解决信令风暴中的 · 2016/07/dtpt 括以下3 个步骤。 a）扩容sccpch。开启fd，会将大量用户承载在 fach 及pch，为缓解fach 拥塞，实施信令风暴解决