中国移动TD网络性能研究报告.doc

《中国移动TD网络性能研究报告.doc》由会员分享，可在线阅读，更多相关《中国移动TD网络性能研究报告.doc（92页珍藏版）》请在三一办公上搜索。

1、TD网络性能科研报告1 网络接入性能1.1 寻呼成功率1.1.1 公共信道特性描述1.1.1.1 传输信道1)广播信道(BCH)下行传输信道，用于广播系统和小区的特有信息。用来周期性发送系统广播信息，信道上传输的数据块大小固定为246bit，物理层不能复用BCH传输信道，承载于PCCPCH。2)寻呼信道(PCH)下行传输信道，当系统不知道移动台所在的小区时，用于发送给移动台的控制信息。物理层可以把PCH和FACH复用成CCTrCH，承载于SCCPCH。3)前向接入信道(FACH)前向接入信道(FACH)是下行传输信道，当系统知道移动台所在的小区时，用于发送给移动台的控制信息。一般用于网络响应从

2、RACH信道接收到的信息。该信道也可以能够来传送一些短的用户数据。网络端的物理层可以把该信道的数据与来自寻呼信道的数据进行复用。承载于SCCPCH。目前，FACH用于RRC连接建立过程中承载下行信令，若RRC连接建立在CELL_DCH上，RRC连接建立之后停止使用；若RRC连接建立在CELL_FACH上，SRB能够承载短消息以及位置更新业务等。4)随机接入信道(RACH)随机接入信道是上行传输信道，用于承载来自移动台的控制信息。UE使用RACH来完成上行同步的建立和传输一些数据量有限的用户数据。RACH传输信道的典型特征是信道所映射到的物理信道是一个竞争信道。由于竞争性的存在，RACH上的数据

3、不存在着物理层复用，信道上仅存在着单一的传输格式，因而不需要TFCI来标识当前的传输格式。承载于PRACH。目前，RACH用于RRC连接建立过程中承载上行信令。1.1.1.2 物理信道1)主公共控制物理信道(P-CCPCH)传输信道BCH在物理层映射到P-CCPCH。在TD-SCDMA中，P-CCPCH的位置(时隙/码)是固定的(Ts0)。P-CCPCH采用固定扩频因子SF=16，总采用TS#0的信道化码CQ=16(k=1)和CQ=16(k=2)。P-CCPCH需要覆盖整个区域，不进行波束赋形。辅助公共控制物理信道(S-CCPCH)PCH和FACH可以映射到一个或多个辅助公共控制物理信道(S-

4、CCPCH)，这种方法使PCH和FACH的数量可以满足不同的需要。S-CCPCHs采用固定扩频因子SF=16,S-CCPCH的配置即所使用的码和时隙在小区系统信息中广播。2个S-CCPCH码道配置采用TS#0的信道化码CQ=16(k=3)和CQ=16(k=4)5个S-CCPCH码道配置采用TS#0的信道化码CQ=16(k=3)、CQ=16(k=4) CQ=16(k=5) CQ=16(k=6)和)CQ=16(k=7)物理随机接入信道(PRACH)RACH映射到一个或多个物理随机接入信道，可以根据运营者的需要，灵活确定RACH容量。PRACH可以采用扩频因子SF=16, SF=8 或 SF=4。其

5、配置(使用的时隙和码道)通过小区系统信息广播。快速物理接入信道(FPACH)这个物理信道是TD-SCDMA系统所独有的,它作为对UE发出的UpPTS信号的应答,用于支持建立上行同步。NodeB 使用FPACH传送对检测到的UE的上行同步信号的应答。FPACH上的内容包括定时调整、功率调整等，是一单burst信息。FPACH使用扩频因子SF=16，其配置(使用的时隙和码道)通过小区系统信息广播。寻呼指示信道（PICH）寻呼指示信道用来承载寻呼指示信息，PICH的扩频因子为16。与传输信道PCH配对使用，用以指示特定的UE是否要解读其后PCH信道。1.1.1.3 传输信道与物理信道的映射传输信道与

6、物理信道映射传输信道物理信道占用时隙/码道上行RACHPRACHTs1/SF16*2Ts1/SF8*1UpPCHUpPTS/128chip 下行BCHP-CCPCHTs0/SF16*2PCH，FACHS-CCPCHTs0/SF16*5 or 2PICHTs0/SF16FPACHTs0/SF16*1DwPCHDwPTS/64chip1.1.1.4 公共信道设备实现码道参数配置和功率参数配置如下表。公共信道现网参数实现公共信道名称所处时隙码道个数扩频因子传输块TTI发射功率DwPchDwPTS36UpPchUpPTSBCHTS02SF16246, 1块20ms33PCHTS02SF1680*1/2

7、40*120ms30/33FACHTS02SF16171*1/171*2 20ms30/33FPACHTS01SF1632，1块5ms30PRACHTS11SF8170,1块10ms其中，寻呼信道PCH子信道个数配置可为28个，现网中配置8个。1.1.2 寻呼原理TD-SCDMA RAN系统具有一种机制，可以寻找并呼叫那些分布在不同位置区中自由移动的注册用户终端，从而响应并完成网络侧发起的信令或业务过程。UMTS系统定义UE有5种RRC状态：RRC IDLE、CELL_DCH、CELL_FACH、CELL_PCH、URA_PCH。对于不同的状态，UE采用不同的方式维持与网络联系，或直接与网络保

8、持着信令连接，网络记录UE的位置或路由信息，一旦需要随时向UE发起寻呼过程。 寻呼的主要作用包括： 1. CN呼叫空闲模式的UE，完成接入并建立呼叫连接； 2. CN呼叫通话模式下的UE，告知来自网络侧的一个新呼叫； 3. UTRAN呼叫空闲或寻呼模式的UE，告知系统消息更新； 4. UTRAN呼叫寻呼模式下UE，通知其完成RRC状态切换。 寻呼有如下四种方式：1. CN利用RANAP过程向RNC发起针对指定UE寻呼消息，如果该UE正处于空闲状态或寻呼状态，RNC会自动计算UE的寻呼时机，正确的利用FP PCH发送寻呼指示和RRC Paging Type 1消息。UE接收寻呼消息后，建立RRC

9、连接完成接入过程。 2. 当CN利用RANAP过程向RNC发起针对某个UE寻呼消息，如果该UE正处于信令连接状态（CELL_FACH或CELL_DCH），RNC通过该信令连接直接向UE发送RRC Paging Type 2消息。UE接收寻呼消息并根据自身的状态，完成进一步的信令过程。 3. 当CN对处于寻呼状态（CELL_PCH或URA_PCH）的UE发起NAS信令过程或因为其他RRC过程触发（如：需要释放RRC连接）时，RNC自动识别UE的标识并计算寻呼时机，正确的发送寻呼指示和Paging Type 1消息。UE接收到寻呼消息，切换到CELL_FACH状态，完成NAS信令过程或RRC信令过

10、程。 4. RNC完成系统消息更新过程后，将通知所有处于空闲状态或寻呼状态的UE发起系统消息更新，选择全部寻呼时机发寻呼指示，向所有寻呼信道上发送RRC Paging Type 1消息，告知UE系统消息已经更新。UE接收到寻呼消息后，判断是系统消息更新通知，完成系统消息读取和更新过程。 1.1.3 寻呼能力计算话务模型参数忙时每用户寻呼次数：1.5次忙时每用户呼叫次数：1.5次，平均通话时长60秒，则语音单用户忙时话务量0.025Erlang业务服务质量参数序号业务类型Gos要求BLER1语音业务（12.2k/12.2k）2%阻塞率1%单小区支持的语音用户数序号业务类型平均会话时长单小区单载波

11、按BRU等效信道个数单小区单载波话务量单小区单载波用户数单小区三载波按BRU等效信道个数单小区三载波话务量单小区三载波用户数1语音业务（12.2k/12.2k）602315.766306958.182327TD系统寻呼的理论指标理论计算公式寻呼数/秒/小区 = (TB-Size 20)/50 *NPCH)/PBP，其中(TB-Size 20)/50的结果向下取整；PBP = 64帧，TB size = 80bit，最大寻呼数 = 12.5/秒/小区；对应的LA用户数=12.5*3600/1.5=30000；对应的单载波小区数=30000/630=47个；对应的三载波小区数=30000/2327

12、=12个。1.1.4 寻呼成功率对于网络的寻呼性能一般采用寻呼成功率进行衡量，寻呼成功率定义如下： 寻呼成功率 =寻呼成功总次数/寻呼请求总次数*100% 其中，寻呼成功总次数，指所有MSC收到的被叫用户寻呼响应的总次数，统计消息为MSC 收到 “PAGING RESPONSE”(含二次寻呼的响应)。 寻呼请求总次数：指所有MSC发出寻呼被叫的总次数，统计消息为MSC发出对被叫用户的 “PAGING REQUEST” (不包含二次寻呼的次数)。 造成寻呼成功功率低主要有两方面的原因，一个是UE没有收到寻呼消息，另一个是UE收到寻呼消息后，由于随后的RRC信令连接建立、鉴权等过程失败也会导致CN

13、无法收到寻呼响应。常见的导致UE无法收到寻呼的原因主要包括： 1.1.4.1 寻呼容量不够，RNC没有下发寻呼 由于网络寻呼移动台的同一寻呼消息会在LA所有小区中发送，因此寻呼区域覆盖范围过大，会导致寻呼信道负荷过重，同时增加Iub接口上的信令流量。另外，过载的寻呼消息如果在RNC的重发次数内仍没有发出将被丢弃，这样会导致在服务区内的开机用户不能被寻呼到（用户不在服务区）问题。寻呼区域的上限（区域能支持的最多小区数）主要受到寻呼信道的带宽限制，随着区域的话务量变化，位置区大小也是变化的，位置区大小配置根据寻呼区估算结果来定。 1.1.4.2 由于功率设置不合适，导致UE没有收到寻呼消息 和寻呼

14、相关的有PICH和PCH两个信道，当这两个信道的功率配置偏低不能满足UE对信号解调的要求时，UE不能正确的接收寻呼消息。 1. PICH信道的发射功率 该参数设置过小，会使得小区边缘UE无法正确接收寻呼指示信息，导致呼叫时延增加，也有可能进行读取PCH信道的误操作，浪费UE电池，并影响下行公共信道覆盖，从而最终影响小区覆盖。 2. PCH信道的发射功率 该参数设置过小，会使得小区边缘UE无法正确接收寻呼信息，增加寻呼的时延，导致寻呼成功率低，从而影响接入成功率。 1.1.4.3 UE频繁进行小区重选或位置区更新没有收到寻呼消息 UE在小区重选过程将读取系统信息，从而无法收到对于该UE的寻呼消息

15、。 对于UE的寻呼会在位置区内所有小区中发送，如果这时UE发生位置区更新，则这条寻呼消息会发送到错误的位置区，导致UE无法收到引起寻呼失败。 1.1.4.4 覆盖或干扰问题导致的寻呼消息接收失败 由于弱覆盖或由于干扰原因，UE无法正确解析寻呼消息。需对覆盖和干扰进行优化。 1.1.4.5 优化方法 针对不同的问题原因，建议采用不同的优化方法解决寻呼成功率低的问题： 1. 对于寻呼容量不足导致RNC没有下发寻呼的问题，建议优化方式如下： 1) 合理规划LA和路由区范围，减少由于范围不合理引起的寻呼信道过载的现象； 位置区的划分应尽量使LA边缘的位置更新成本最低：城郊与市区不连续覆盖时，有可能会出

16、现手机在周期性位置更新时间到达时作不了位置更新，超过保护时间后（一般在MSC中设定），系统认为IMSI 隐式分离，假如此时进入市区，市区与郊区的LAC一致，有些手机不会立即做正常的位置更新，就会出现有信号却不在服务区的现象。所以在位置区的分配上，一般郊区（县）使用单独的位置区，即和城区的位置区不一样，此时的位置区分布类似于一个同心圆（内圆城区也可能由于容量因素设置几个位置区，圆内可以采取分片方式或另一个内外圆环方式或混合方式），可以有效避免以上现象的发生。实践证明，这样划分LAC不仅可以减少用户不在服务区现象，并且接通率和呼通率也能有较大改善。另外，在高话务的大城市，如果存在两个以上的位置区，

17、可以利用市区中山体、河流等地形因素来作为位置区的边界，减少两个位置区下不同小区的交叠深度。如果不存在这样的地理环境，位置区的划分尽量不要以街道为界，边界不要放在话务量很高的地方（比如商场）。一般要求位置区边界不与街道平行或垂直，而是斜交。在市区和城郊交界区域，一般将位置区的边界放在郊区外围一线的基站处，而不是放在话务密集的城郊结合部，避免结合部用户频繁位置更新。位置区尽量不要跨越MSC和RNC：虽然在根据协议规定，当几个MSC共用一个VLR时，位置区可以跨MSC区的。但是在具体实现中，大都采用一个MSC捆绑一个VLR的方式，因此LA可以跨RNC区，但不可以跨MSC区。但在实际网络应用中，如果位

18、置区/路由区跨多个RNC时，会造成寻呼时在多个RNC下发，这样会增加了信令的流量及处理的难度，抬高了寻呼消息阻塞和丢弃的概率。2) 增加寻呼信道容量。 2. 对于功率设置不合适导致UE没有收到寻呼消息的建议提高PCH和PICH信道的发射功率，但功率的提高必须适度，否则将浪费功率，并增大下行干扰。 3. 如果UE在某一区域小区重选频繁的话，可以通过调整上诸如提高测量门限、提高小区重选偏移值或者减小UE最小接收电平等手段来降低小区重选的频率。对于由于UE位置区更新导致的未收到寻呼，需要对位置区边界进行专题优化，主要是找出位置区边界的高话务小区，尽量减少位置区边界高话务小区的位置更新次数，从而减少由

19、于位置更新造成的寻呼损失。此外还可增大周期位置更新定时器T3212的取值。 4. 对于覆盖或干扰问题导致的寻呼成功率低，需要首先解决覆盖及干扰的问题。1.2 无线资源控制RRC连接建立成功率1.2.1 概述1.2.1.1 指标定义根据集团规范定义，RRC连接建立成功率= RRC连接建立成功次数/ RRC连接建立请求次数*100%。其中主要包含：1) 指标编码RNP1701：RRC连接建立请求次数l 名称：4.3.3.1按原因分RRC连接请求次数l 定义： 统计小区中RRC连接请求的次数，应该按请求原因分类统计。单位：次；l 触发点：RNC接收到UE发来 的“RRC连接请求”（RRC CONNE

20、CTION REQUEST）消息，不计重发，每个原因对应一个子测量项，所有原因之和用“.sum”表示。（3GPP TS 25.331）2) 指标编码RNP1702：RRC连接建立成功次数l 名称：4.3.3.2按原因分RRC连接建立成功次数l 定义：统计RRC连接建立成功次数，应该按建立原因分类统计。单位：次；l 触发点：RNC接收到UE发来的“RRC连接建立完成”（RRC CONNECTION SETUP COMPLETE）消息，每个原因对应一个子测量项，所有原因之和用“.sum”表示。（3GPP TS 25.331）3) 指标编码RNP1703：RRC连接建立失败次数，l 名称：4.3.3

21、.3按原因分RRC连接失败次数l 定义： 统计小区中RRC连接失败次数，应该按失败原因分类统计。单位：次；l 触发点： 【1】RNC向UE发送“RRC连接建立拒绝”（RRC CONNECTION REJECT ）消息。（3GPP TS 25.331）。【2】RNC未接收到预期的UE发来的“RRC连接建立完成”（RRC CONNECT SETUP COMPLETE）消息，此时失败原因归为“NO REPLY”。（3GPP TS 25.331）。每个原因对应一个子测量项；以上3项指标编码又都包含了8个子测量项，分别对应8类业务：l Originating Conversational Call（CS

22、业务）l Originating Streaming Call（PS业务）l Originating Interactive Call（PS业务）l Originating Background Call（PS业务）l Terminating Conversational Call（CS业务）l Terminating Streaming Call（PS业务）l Terminating Interactive Call（PS业务）l Terminating Background Call（PS业务）1.2.1.2 现网情况从近段时间的统计来看，目前现网的RRC接通率已趋于稳定（集团对于RRC接

23、通率指标不进行单独考核），近段时期上海网络的业务RRC接通率达到了98.50%，处于一个较好的水平上，如3月31日至4月2日的统计如下：时间CS域RRC建立尝试次数（业务相关）CS域RRC建立成功次数（业务相关）CS域RRC建立成功率PS域RRC连接建立尝试次数（业务相关）PS域RRC连接建立成功次数（业务相关）PS域RRC建立成功率RRC总建立成功率2009-3-3164255 6326998.47%678186667198.31%98.38%2009-4-166246 6523198.47%10856710708198.63%98.57%2009-4-265878 6503698.72%5

24、24365153798.29%98.53%总计196379 193536 98.55%228821 225289 98.46%98.50%但之前的RRC接通水平则一直不太理想，如3月25日到3月27日的统计显示，总的RRC接通率只有95.46%，较现在低了近3个百分点。具体如下：时间CS域RRC建立尝试次数（业务相关）CS域RRC建立成功次数（业务相关）CS域RRC建立成功率PS域RRC连接建立尝试次数（业务相关）PS域RRC连接建立成功次数（业务相关）PS域RRC建立成功率RRC总建立成功率2009-3-25577575596196.89%577025372893.11%95.00%2009

25、-3-26639196192696.88%548855151593.86%95.49%2009-3-27599665846697.50%589115552294.25%95.89%总计18164217635397.09%17149816076593.74%95.46%对于RRC接通率指标的提升，主要依赖于现网拥塞率的下降和入网新站的FACH赋形开启，主要优化手段就是开启全网的PS调度和开启部分新站的FACH赋形开关（部分新站的FACH赋形之前未开启）。通过近期的集中优化调整，虽然目前的指标情况比较好，但还存在一些提升的空间，从具体的指标分析结果来看，影响网络RRC接通率的主要原因有3类：l 设

26、备原因l 终端原因l 网络原因主要包含：拥塞、覆盖原因、基站偶发故障、终端原因和干扰等。以现网4个RNC的全天4个忙时（8：0012：00）的RRC接通率进行分析，共采集了未接通点654个，相应的各未接通现象所占的比例如下： 失败原因次数比例备注1次RRC CONNECTION SETUP无响应12318.81%RRC完成消息网络侧未收到2次RRC CONNECTION SETUP无响应304.59%3次RRC CONNECTION SETUP无响应345.20%4次RRC CONNECTION SETUP无响应27742.35%RRC完成消息网络侧未收到或RRC CONNECTION SET

27、UP消息终端未接收到上行判决码失败17226.30%拥塞下行判决码失败182.75%总计654其中，1次RRC CONNECTION SETUP无响应可能为无线原因，也有可能是终端原因（发现过一例），但具体比例无法得知。另外，考虑到采样的随机性，本次采集的失败原因并没有包括终端和设备问题，这主要是因为终端问题和设备问题基本以坏小区的形式出现，偶然性比较大，但这并不代表现网没有这些问题。如前期发现了几例设备问题，其现象就是RNC向Node B发送了Radio link Setup Request消息进行无线链路的建立的同时，RNC下发了Radio link Deletion Request消息进

28、行无线链路的删除，具体可参加1.2.2.3章节描述。具体各类失败原因的相关描述及解决建议如下：1.2.2 现象描述及解决建议1.2.2.1 终端问题终端原因是导致未接通的另一类原因，其现象类似无线环境原因导致的未接通，通过CDL数据分析发现其现象如下图1-2所示，在UE向RNC发送RRC Connection Request消息，RNC向UE回复了RRC Connection Setup消息，在RRC Connection Setup保护定时器5秒超时后，RNC下发无线链路删除请求，最终导致了未接通的发生。图 11 终端原因导致的未接通情况示意图分析这种情况主要集中在同一个用户上（同一小区上，

29、一段时间内RRC Connection Request中的TMSI相同），现象是RNC收到了UE上报的RRC Connection Request消息并下发了RRC Connection Setup消息，但UE并没有完成RRC建立过程。由于没有RRC Connection Request消息重发，初步判断是由于UE在收到RRC Connection Setup消息后没有上发RRC Connection Setup Complete消息所致，结合RRC建立请求阶段RACH所带的Measurement Report解析发现，当时UE所处的无线环境较好，PCCPCH-RSCP一般都在-80dBm以上

30、，因此，判断为终端原因。当然，有时上行无线环境问题同样也会导致这种现象发生，要排除上行问题，除了问题点和问题小区的上行干扰分析外，也可以到现场进行测试确认。但要判断是否是终端问题，就相对比较困难，我们也是近期进行用户投诉处理时才发现有终端问题和上述现象的关联性。当时用户投诉漕宝路和桂平路交界区域无法进行呼叫，到现场后，发现用户使用的是多普达S700手机，一直无法进行拨叫，但同一地点测试手机DTM8120却可以正常呼叫，让机房跟踪小区级call trace，发现现象和前述现象一致，因此我们让用户将其手机进行开关机一次，重新开机后即可正常进行呼叫，问题定位为终端的莫名故障或软件吊死。对于终端问题的

31、确定，首先可以分析是否是同一用户在同一小区下的集中行为，然后再进行问题点的覆盖分析和问题小区的上行干扰情况分析，确认不是因为无线环境的原因，当然，最终问题的确认还是要结合用户投诉来进行。一旦发现是用户终端问题，可以进行合理的引导解释，以提高用户网络体验的感知度。1.2.2.2 网络问题 无线环境问题弱覆盖导致的RRC建立阶段的未接通现象与终端原因导致的未接通现象基本一致，具体情况如图1-2所示。现象即在UE向RNC发送RRC Connection Request消息，RNC向UE回复了RRC Connection Setup消息，但随后由于UE未能收到RRC Connection Setup消

32、息，继续进行RRC Connection Request消息重发，达到最大重发次后，且RRC Connection Setup保护定时器5秒超时，RNC下发无线链路删除请求，最终导致了未接通的发生。同时，上行覆盖问题也同样会导致这些问题的发生，与下行覆盖原因的区别就是UE已经收到了RRC Connection Setup（可能是多次RRC请求之后），然后再回发RRC建立完成消息给网络，但由于上行覆盖原因，网络侧并没有收到RRC SETUP完成消息，同样会导致RRC Connection Setup保护定时器5秒超时失败。同理，对于是否是覆盖问题的定位，还要结合RRC建立请求阶段RACH所带的M

33、easurement Report，如果UE所处的无线环境较差，相应的PCCPCH-RSCP都会比较差。由此，基本可以判断为弱覆盖原因导致UE没有收到RNC下发的RRC Connection Setup消息或RRC建立完成消息网络侧并没有收到。反之，则有可能是由于干扰引起的上、下行消息丢失。图 12 覆盖原因导致的未接通情况示意图对于覆盖问题的解决建议：a) 真正弱覆盖的，还是要通过加站或小区天馈调整来解决；b) 由于基站功率设置问题，可以通过基站功率的提升来解决；c) 由于是上、下行链路不平衡导致的上、下行覆盖差异，则需要通过参数调整或更换基站硬件来解决。对于干扰问题的解决建议：a) 合理规

34、划频点、扰码，降低网内干扰；b) 合理调整相邻小区间的覆盖范围；c) 如果是外来干扰，需要查找排除；d) 如果是基站故障引起的干扰，需要更换模块解决。 网络拥塞通过CDL数据分析发现，UE在向RNC发送RRC Connection Request消息后，HSPS回复一条RRM_ALLOCATE_RESOURCES_FAILURE（消息IE所携带原因：下行码判决失败/上行码判决失败），随后RNC向UE发送一条RRC Connection Reject消息(消息IE所携带原因：Congestion)。具体情况如图1-3所示：图 13 拥塞导致的RRC建立失败情况示意图由于我们目前现网配置中的DCA

35、算法参数“1、2、3类业务默认的上下行承载速率”设置均为0，及不限制初始接入速率。目前很多用户在初始接入时都是以下行384K速率接入，如果一个没有配置H资源的宏站（假设按上下行时隙3：3配置）一个小区最多可以承载3个384K用户；同时，目前除了H数据卡，大多数用户使用的终端都不支持H业务，因此，即使基站小区配置了H资源，这部分用也不会使用H的共享资源，而依然会占用普通的R4资源，很容易出现拥塞的现象。对于拥塞，目前比较有效的解决方法就是：a) 开启全网的PS调度算法，这样就能最大限度的降低网络拥塞。PS调度算法原理就是：根据用户实际需求来分配无线资源，如用户处于高速下载时分配其尽可能的最大资源

36、；用户进行低速业务时，仅分配其相应的无线资源；当用户上、下行均无速率时，则让UE直接回到cell_pch状态，从而使网络容量最大化。b) 同时对于SDCA算法参数要进行必要的优化设置：【1】允许降速接入：非实时业务接入时，如果用户申请的资源不能够得到满足，则允许其按现有资源对应的速率接入；【2】等效方案开启：举例来说，用户申请的是128k业务，需要占用一个SF=1的码道（即整个时隙），如果服务小区已没有一个完整的空闲时隙供其接入，则可以使用2个SF=2的码道接入（即2个1/2时隙，可以在不同时隙上）；现在全网已经按照这种思路进行了全面优化，因此全网的拥塞率下降明显。当然，也有些小区在开启了PS

37、调度算法还是存在拥塞，这些小区基本为室内基站，载频配置一般较少，如斜土路营业厅，就经常出现拥塞现象，因此最根本的解决方法是进行载频扩容。1.2.2.3 网络设备故障通过大量CDL数据分析发现， 有一部分未接通发生现象为：在UE向RNC发送RRC建立请求后，RNC向Node B发送了Radio link Setup Request消息进行无线链路的建立，但几乎同时，RNC下发了Radio link Deletion Request消息进行无线链路的删除，发生RRC建立连接失败，导致未接通发生。具体情况如图1-4所示：图 14 BBU故障导致未接通情况示意图通过现场测试和UE_TRACE信令分析发

38、现，无线链路建立时，RNC主动删除无线链路的原因为在建立RRC连接的过程中，RNC发送节点同步消息，但是基站没有响应或者RNC在底层因为异常丢弃了节 点同步帧，初步怀疑为Node B侧设备存在硬件故障。后续与RNC机房及工程部配合定位，最终确认该现象是由于问题小区BBU存在故障导致。当然这种主要集中在一个小区中发生的异常现象基本可以确定是单个小区的故障，但如果某个RNC下很多小区都发生有这种情况，则还是要通过这些小区在RNC端的收敛性来定位是否是RNC相关板卡的故障。如在3月中旬，烽火RNC410下的很多小区就出现了上述异常的Radio link Deletion Request情况，分析发现

39、这些小区都同属一个机架、机框下：RNCRNC内的小区标识RRC失败次数CSDU机架号CSDU机框号41076924124107706124107712124109142124109155612410104149124101042141241010437012410107381241010744312410116929124101170161241011711312410134518124101346831241013471212410137714124101857212410185941241088192124108834211241090253012410904161241090421311

40、2410980964124109810251241098114712410100813124101008320124101011331124101011473124101011526124101013141241010257212通过核查，发现是这个2机架、2机框下的一块DSDU出现了故障，更换后RRC接通指标即恢复正常。对于故障小区或故障RNC板卡的处理关键在于及时的发现和定位，目前主要通过TOP10坏小区或某个RNC突然出现异常的处理来发现，一旦发现异常就需及时给予处理，避免指标长时间恶化。当然，维护人员对于设备问题的及时发现处理也很重要，这实际也是优化工作的一部分。1.2.3 小结通过前

41、面的分析描述，发现现网的RRC接通问题主要还是和拥塞和无线环境相关，同时偶发的故障小区或用户终端问题同样会加剧RRC接通率的下降。因此，相应的优化手段也主要从参数优化、故障小区处理、扩容、加强覆盖等方面来着手，只有不断的进行网络监控和分析优化，才能持续提升网络的接通指标。1.3 无线接入承载RAB指派建立成功率1.3.1 概述1.3.1.1 指标定义根据集团规范定义，RRC连接建立成功率= RAB连接建立成功次数/ RAB连接建立请求次数*100%。其中主要包含：1) 指标编码RNP1601：CS域RAB连接建立请求次数l 名称：4.3.2.1电路域RAB指配建立请求的RAB 数目；l 定义：

42、统计电路域RAB指配建立请求的RAB数目，应该按根据业务速率细分的业务类型分类统计。单位： 个；l 触发点：RNC接收到电路域CN发来的“RAB指配请求”（RAB ASSIGNMENT REQUEST）消息，消息中包含需要建立的RAB。每个根据业务速率细分的业务类型对应一个子测量项，业务类型定义参见3GPP TS 23.107。2) 指标编码RNP1602：CS域RAB连接建立成功次数l 名称：4.3.2.2电路域RAB指配建立成功的RAB 数目；l 定义：统计电路域RAB指配建立成功的RAB数目，应该按根据业务速率细分的业务类型分类统计。单位： 个；l 触发点：RNC向电路域CN发送“RAB

43、指配响应”（RAB ASSIGNMENT RESPONSE）消息，其中包含建立成功的RAB数目。每个根据业务速率细分的业务类型对应一个子测量项，业务类型定义参见3GPP TS 23.107。3) 指标编码RNP1604：PS域RAB连接建立请求次数l 名称：4.3.2.4分组域RAB指配请求建立的RAB 数目；l 定义：统计分组域RAB指配请求建立的RAB数目，应该按根据业务速率细分的业务类型分类统计。单位： 个；l 触发点：RNC接收到分组域CN发来的“RAB指配请求”（RAB ASSIGNMENT REQUEST）消息,消息中包含需要建立的RAB。每个根据业务速率细分的业务类型对应一个子测

44、量项，业务类型；4) 指标编码RNP1605：PS域RAB连接建立成功次数l 名称：4.3.2.5分组域RAB指配建立成功的RAB 数目；l 定义：统计分组域RAB指配建立成功的RAB数目，应该按根据业务速率细分的业务类型分类统计。单位：个；l 触发点：RNC向分组域CN发送“RAB指配响应”（RAB ASSIGNMENT RESPONSE）消息，其中包含建立成功的RAB数目。每个根据业务速率细分的业务类型对应一个子测量项，业务类型；以上各项指标编码又都包含了一些子测量项，分别对应不同的业务：l CS域的子测量项有：英文名称(A.B.C)英文名称(A.B.C.D)RAB.AttRabAssig

45、nEstabCS.ConvRAB.AttRabAssignEstabCS.Conv.RAB.AttRabAssignEstabCS.Conv.RAB.AttRabAssignEstabCS.Conv.RAB.AttRabAssignEstabCS.Conv.RAB.AttRabAssignEstabCS.StrmRAB.AttRabAssignEstabCS.IntactRAB.AttRabAssignEstabCS.Bgrd；l PS域的子测量项有：英文名称(A.B.C)英文名称(A.B.C.D)RAB.AttRabAssignEstabPS.ConvRAB.AttRabAssignEstabPS.StrmRAB.AttRabAssignEstabPS.Strm.RAB.AttRabAssignEstabPS.Strm.待添加的隐藏文字内容1RAB.AttRabAssignEstabPS.Strm.RAB.AttRabAssignEstabPS.IntactRAB.AttRabAssignEstabPS.Int