HSPA业务状态迁移策略评估报告.doc

状态迁移策略评估报告1. 背景当前使用的策略：l HSPA业务：永久在线策略，即对于HSPA业务只存在两种状态CELL_DCH和IDLE态，当20s内容检测到UE无数据传送则断开RRC和IU口连接，但PDP仍然保留l R99 BE业务：状态迁移，存在CELL_DCH、CELL_FACH和IDLE态，通过4A、4B等相关参数对这几种状态进行控制当前策略的缺点：对于HSPA业务来说，在永久在线定时器未达到之前一直占用上下行CE资源、码资源和功率资源，对资源是一种很大的浪费。新策略：打开HSPA业务到CELL_FACH状态的迁移新策略优点：l 节省无线资源l 对于小数据量的用户感受有所提升l 对于高流量需求的用户感受提升新策略问题：l FACH信道存在拥塞问题小区较少l 目前广州采用业务分层，倾向性驻留的双载波策略，采用状态迁移后对于F2小区的用户迁移到CELL_FACH后需驻留到F1小区，后续通过RB重配置到F2小区，反而影响用户的感受已解决l 用户在CELL_FACH状态下突发大包的话存在第一个包丢失问题已解决l HSPA掉线率存在恶化风险华为反馈目前PS掉线公式不合理，需更正2. PING测试结果开启状态迁移的测试结果对比：ping 包大小修改前修改后32151238660027011000丢包14001512丢包对于小包的PING时延改善比较明显，从1512ms减少到386ms,缩短1126ms。而对于PING大包，第一包PING超时，问题正在分析中。3. 信令流程在DCH状态下，因业务量低于门限，经过10S的时间后，UE进入FACH状态： UE在FACH状态下读取系统消息。30S后，再次发包进行PING，此时UE从FACH状态又迁移回DCH：从以上的流程可以看出，UE的状态迁移过程是符合预期的。4. 指标分析统计时间段为17-20点，三个小时的汇总统计。4.1 RNC处于FACH状态的用户数变化时间RNCRNC中处于CELL_FACH状态的UE个数08/27/2011GZRNC10928.362508/28/2011GZRNC10932.980608/29/2011GZRNC10872.111108/30/2011GZRNC10898.486108/31/2011GZRNC10847.830609/01/2011GZRNC10923.202809/02/2011GZRNC10991.302809/03/2011GZRNC10980.080609/04/2011GZRNC101021.481509/05/2011GZRNC10944.972209/06/2011GZRNC10968.213409/07/2011GZRNC101035.834709/08/2011GZRNC101071.047209/09/2011GZRNC1012406.855609/10/2011GZRNC10768.2509/11/2011GZRNC10726.983309/12/2011GZRNC10828.7修改后处于CELL_FACH状态的用户增长明显。4.2话务量流量变化情况时间RNCVS.AMR.RB.Erlang.SumVS.VP.RB.Erlang.SumVS.CS.RB.Erlang.Sum小区中HSDPA MAC-d flow发送字节数小区中HSUPA MAC-d flow接收字节数VS.R99PSLoad.ULThruput.MBVS.R99PSLoad.DLThruput.MB08/27/2011GZRNC103609.58333.07783621.89451.1112E+11172548271366874.18041653.512108/28/2011GZRNC103364.23.72223379.08891.08881E+11156167494886062.50362143.155308/29/2011GZRNC103694.70831.35563700.130689104939194114117040084975.09251928.54108/30/2011GZRNC103717.54172.14313726.113996601032218152512936645236.78061502.624908/31/2011GZRNC103842.7233.49443856.700898526763504127871310966306.10061792.301809/01/2011GZRNC103787.78332.33796.983389937245856111001923765155.57552068.828609/02/2011GZRNC103866.84171.40693872.469494980265911124846499045227.56961957.202209/03/2011GZRNC103655.252.52363665.34441.12208E+11129014920006431.51472048.735509/04/2011GZRNC103417.34172.77923428.45831.11775E+11143565722886152.91221634.138809/05/2011GZRNC103860.24.15143876.805683351436208108669442086368.06741805.956809/06/2011GZRNC103837.93334.98063857.855684019190888123427798565150.22082296.807809/07/2011GZRNC104029.453.36954042.928190134356191118234842405303.54141806.769709/08/2011GZRNC103885.05832.29863894.252888996431674125140140325432.65031864.411109/09/2011GZRNC104212.99492.09314221.367191840272663126410254086416.13882143.984609/10/2011GZRNC103810.00833.03333822.14171.03974E+11146645081527063.79052086.166709/11/2011GZRNC103597.99173.60423612.40831.12241E+11170237584165525.1681591.797709/12/2011GZRNC104231.75835.34314253.13061.07544E+11149743171767978.38411521.1065修改后话务量、流量处于正常波动范围，话务量相对之前有所抬升，数据流量稍有下降。4.3HSPA吞吐率变化情况时间RNC小区中HSDPA用户数平均值小区中HSDPA单MAC-d flow平均吞吐率小区中HSUPA用户数平均值VS.HSUPA.MeanChThroughput08/27/2011GZRNC103228.2691759.89982459.053549.005208/28/2011GZRNC103219.0639767.63762456.341244.08308/29/2011GZRNC102968.5319776.842232.661638.399108/30/2011GZRNC102937.6991821.57782166.953750.29608/31/2011GZRNC102934.0453792.81692190.829642.1709/01/2011GZRNC103127.0556743.67162292.780636.812909/02/2011GZRNC103302.0863718.86582410.96337.972709/03/2011GZRNC103421.3278793.05282510.177337.6509/04/2011GZRNC103460.7414747.84052565.882339.788709/05/2011GZRNC103189.9106738.8712268.038438.202709/06/2011GZRNC103293.5792724.22422340.607940.910909/07/2011GZRNC103307.8939741.28742363.299539.85609/08/2011GZRNC103392.6681699.55032434.273639.010409/09/2011GZRNC101935.9471842.90761473.157842.958109/10/2011GZRNC103238.8347714.34332402.240.341209/11/2011GZRNC103157.9639777.62732338.50645.918109/12/2011GZRNC103157.5769.32472376.258341.8399修改后在线的HSPA用户数明显减少，但是HSDPA的吞吐率明显抬升，HSDPA吞吐率提升幅度17.25%，HSUPA提升幅度13.14%。4.4资源占用情况时间RNCVS.ULCEUsed.MeanVS.DLCEUsed.Mean小区中整个码树的平均占用情况08/27/2011GZRNC1014113.53155760.337139263.482908/28/2011GZRNC1014003.52135687.825939075.000908/29/2011GZRNC1013098.60395425.142138740.575908/30/2011GZRNC1012925.59935349.481938516.66208/31/2011GZRNC1012945.82485369.115438683.096909/01/2011GZRNC1013607.48035610.165338985.820409/02/2011GZRNC1014358.49595900.464240117.104409/03/2011GZRNC1014662.64355964.987540141.003209/04/2011GZRNC1014777.12195947.113739972.181409/05/2011GZRNC1013790.43315689.011139910.268509/06/2011GZRNC1014209.16345851.015740225.303209/07/2011GZRNC1014422.64375961.704740364.417909/08/2011GZRNC1014731.37486062.772740767.363409/09/2011GZRNC109567.27364251.507738451.284909/10/2011GZRNC1014333.9475875.763440235.949109/11/2011GZRNC1013850.33225648.241239703.210209/12/2011GZRNC1014114.05585814.225540009.1338修改后小区上下行CE资源和码资源的利用率明显下降，其中上行CE利用率下降幅度达35%，下行CE利用率下降29%，码资源利用率下降4%。4.5FACH信道利用率时间RNCVS.FACH.Utilization.Cell.Rate小区中承载在FACH传输信道上的DCCH拥塞时长小区中承载在FACH传输信道上的DTCH拥塞时长08/27/2011GZRNC101.54702008/28/2011GZRNC101.54140508/29/2011GZRNC101.449301508/30/2011GZRNC101.5006011508/31/2011GZRNC101.448607009/01/2011GZRNC101.571901509/02/2011GZRNC101.569704009/03/2011GZRNC101.624702509/04/2011GZRNC101.659101509/05/2011GZRNC101.520602509/06/2011GZRNC101.5635406509/07/2011GZRNC101.686818525409/08/2011GZRNC101.639704409/09/2011GZRNC106.450920601909/10/2011GZRNC101.818107009/11/2011GZRNC101.7999013509/12/2011GZRNC101.9280489修改后FACH信道带宽利用率有明显抬升，但还处于相对较低水平，但是承载DCCH和DTCH的FACH信道有明显拥塞，后续需通过参数优化或FACH扩容调整。4.6RNC资源占用情况修改后XPU负荷并没有抬升，反而稍有下降。4.7掉话率指标对比时间RNCPS掉话率 - HSDPA(V2)PS掉话率 - HSUPA小区中承载在HSDPA上的RAB异常释放次数小区中由RNC发起承载在HSUPA上的RAB异常释放的个数08/27/2011GZRNC100.36580.41153481203908/28/2011GZRNC100.33370.35843210183308/29/2011GZRNC100.32370.36782885170408/30/2011GZRNC100.33680.37622975172608/31/2011GZRNC100.34590.38962999174209/01/2011GZRNC100.35530.41083284195009/02/2011GZRNC100.34530.41623354204309/03/2011GZRNC100.32220.37963270198009/04/2011GZRNC100.35110.39023540204009/05/2011GZRNC100.32630.3833065181709/06/2011GZRNC100.3160.3813038185409/07/2011GZRNC100.36130.42183510207609/08/2011GZRNC100.39320.47633799233209/09/2011GZRNC100.40310.43084849266009/10/2011GZRNC100.27860.32813398204009/11/2011GZRNC100.26240.32733200202109/12/2011GZRNC100.28950.364335232264HSDPA掉线率相对之前有17%的抬升，HSUPA掉线率相对之前有3.5%的抬升。4.8状态迁移成功率4.8.1HSUPA_FACH转换成功率时间RNCVS.HSUPA.E2F.Att:小区内信道类型从EDCH切换到FACH的请求次数VS.HSUPA.E2F.Succ:小区内信道类型从EDCH切换到FACH的成功次数EDCH迁移到FACH成功率VS.HSUPA.F2E.Att:小区内信道类型从FACH切换到EDCH的请求次数VS.HSUPA.F2E.Succ:小区内信道类型从FACH切换到EDCH的成功次数FACH迁移到EDCH成功率09/09/2011 15:00GZRNC106176614799.53%2239221698.97%09/09/2011 16:00GZRNC10194091934399.66%6972688798.78%09/09/2011 17:00GZRNC10875828723199.60%338523337598.59%09/09/2011 18:00GZRNC1010137610063199.27%396063905998.62%09/09/2011 19:00GZRNC1010075510029999.55%411534061798.70%09/09/2011 20:00GZRNC101297112991100.15%8440836499.10%09/09/2011 21:00GZRNC101238123599.76%1192118999.75%09/09/2011 22:00GZRNC10543544100.18%523523100.00%09/09/2011 23:00GZRNC10332332100.00%30130099.67%09/10/2011 00:00GZRNC10166166100.00%163163100.00%09/10/2011 01:00GZRNC107878100.00%7575100.00%从EDCH迁移到FACH状态成功率相对较高，在99%以上，但是FACH迁移到EDCH状态成功率较低。但是为何关闭HSPA与FACH的状态迁移之后仍有小量的状态迁移发生需确认。4.8.2HSDPA_FACH转换成功率时间RNCF2H信道切换尝试次数F2H信道切换成功次数F2H信道切换成功率H2F信道切换尝试次数H2F信道切换成功次数H2F信道切换成功次率09/09/2011 15:00GZRNC104436437398.58%130241298299.68%09/09/2011 16:00GZRNC10128011263698.71%393653923399.66%09/09/2011 17:00GZRNC10634876259498.59%18012017947199.64%09/09/2011 18:00GZRNC10746307364098.67%20784820619599.20%09/09/2011 19:00GZRNC10753907440598.69%20368620282999.58%09/09/2011 20:00GZRNC10141831403998.98%2403824042100.02%09/09/2011 21:00GZRNC101840183699.78%2029198998.03%09/09/2011 22:00GZRNC10838838100.00%849851100.24%09/09/2011 23:00GZRNC1040540499.75%428428100.00%09/10/2011 00:00GZRNC10248248100.00%24924899.60%09/10/2011 01:00GZRNC10121121100.00%125126100.80%09/10/2011 02:00GZRNC10403997.50%4141100.00%从HS-PDSCH迁移到FACH状态成功率相对较高，在99%以上，但是FACH迁移到HS-PDSCH状态成功率较低。5. 通过打开SIB4解决H2F时UE驻留在Barred掉的F2小区如何才能即实现业务分层，又能让UE在从HSPA回落到CELL_FACH状态时仍然停留在f2载波？有两种可能方案：1、 修改倾向性驻留实现方法，用极端小区重选偏置参数替代 Cell barred。这种方法存在的问题是： 需要为idle态和连接态配置两套不同的小区重选偏置参数，使得UE在idle态尽量选择f1，而在连接态尽量选择f2。 部分终端不“听从”极端小区重选偏置参数命令，仍然按照没有设置偏置的情况来选择驻留小区，此外，还有一些终端，比如IPHONE，据说异频重选的失败率较高。也就是说可能有部分终端留在f2小区发起R99业务，达不到业务分层的目的；2、 在f2小区下发系统消息4（简称SIB4），并在SIB4中设置cell not barred，即允许连接态UE驻留在f2小区。根据协议，如果SIB4不存在，连接态和空闲态的UE均通过读取SIB3来判断该小区是否允许驻留，如果SIB4存在，则空闲态的UE通过读取SIB3来判断该小区是否允许驻留，连接态的UE通过读取SIB4来判断该小区是否允许驻留。因此，将SIB3设置为Cell barred，而将SIB4设置为Cell not barred，就可以实现f2小区禁止空闲态UE驻留，但允许CELL_FACH状态UE驻留的目的。10月9日下午14点，挑选RNC1和RNC2进行SIB4参数验证，效果如下：5.1NEWCALL资源准入修改后NEW CALL资源申请成功率明显提升，因HSUPA用户数达到门限和上行CE资源导致资源申请失败次数明显下降。5.2SHO切换准入修改后因HSUPA用户数达到门限和上行CE资源导致资源申请失败次数明显下降。5.3DCCC资源申请修改后因上行CE资源导致资源申请失败次数明显下降。5.4Trch信道转换修改后因HSUPA用户数达到门限和上行CE资源导致资源申请失败次数明显下降。5.5HSPA掉线率修改后HSPA掉线率抬升明显，主要的掉线原因为上行失步及层2配置失败：从上述统计可以看出，采用状态迁移策略后，因HSUPA用户数限制以及上行CE资源不足导致新建呼叫、软切换、DCCC和Trch信道转换的资源申请失败次数明显下降，但是同时也带来了HSPA业务高掉线问题。5.6通过调整IDLETBARRED改善HSPA掉线率问题RNC1的HSPA业务掉线率：通过调整IDLETBARRED由320秒调整为10秒后，HSPA的掉线率相对之前的4.5%下降到0.8%左右，但是相对未采用状态迁移策略的0.4%仍有明显恶化。但是，对于非双载波区域，采用状态迁移策略后，HSPA掉线率并未有明显恶化：6. 用户在CELL_FACH状态下突发大包的话存在第一个包丢失问题6.1问题描述采用状态迁移后，在进行Ping测试时，发现ping1460的大包，从CELL_FACH状态到CELL_DCH(HSDPA 7.2M)第一个包出现超时现象。6.2处理过程图 1对应QXDM在22：30.25.022下发了RB 重配，到FACH；图 1 RB重配置到FACH图 2在22：30：38.9964171时PC 在FACH状态又下发了ping request，此时没有收到reply；图 2 FACH下ping超时对应此时QXDM：22：30：38.964把RLC 窗口重配（seq=0），这次重配是因为H到FACH状态RLC窗口清空，从Seq=0开始，因为是FACH状态所以是一个一个包传的，一共传了4个包；图 3 RLC窗重配图 4 RNC返回的状态包RNC只给UE回到seq=4；图 5 UE发送第5个包如图 6，UE上报了4a后，RNC下发RB重配，转到H；图 6 UE上报了4a事件重配到H之后，从QXDM上看UE并没有将上一个ping包剩余的RLC PDU上发，而PC在H下22：30.44.090882，又发了下一个ping包；图 7 在22：30.44.090882时发起了下一次ping包以上通过Ethereal抓包和QXDM抓包分析PC侧ping包和UE发包的情况。可以发现，1个明显的特征就是FACHHSDPA 7.2M之后，先前的ping包（序号171）在RLC并没有继续发送。我们再来看一下协议上描述。在目前的测试中，测试条件与之前分析数据是一样的：当在CELL_FACH状态下Ping 1460包后，由于UE到达了4a门限，所以网络侧将进行F2D的状态迁移。由于使用的终端为CAT8终端且开户满足7.2Mbps，所以在状态迁移的目的状态为HSDPA7.2Mbps。根据我司目前的默认参数，FACH下的 RLC PDU size为336bits，而HSDPA 7.2Mbps的典型业务中RLC PDU size为656bits。根据协议25.322中8.2章节一段描述： AM RLC entities are always re-established if any of the uplink or downlink AMD PDU size is changed. The modification of other protocol parameters does not require a re-establishment.由此可知，现场进行的ping测试由于涉及到了RLC PDU size的变化，导致RLC实体需要重建，但是协议里并没有指明RLC PDU size，一定要RLC双边重建或单边重建。目前有3种类型的RLC重建： RLC_RECFG_REESTABLISH_TYPE_RECEIVER RLC_RECFG_REESTABLISH_TYPE_TRANSMITTER RLC_RECFG_REESTABLISH_TYPE_BOTHSIDE在之前的版本中，RLC重建的策略为RLC_RECFG_REESTABLISH_TYPE_BOTHSIDE，即RNC和UE中RLC发送实体和接受实体同时进行重建。根据协议25.322中9.7.7章节：If the receiving side of the RLC entity is re-established:- discard the AMD PDUs in the receiving side.If the transmitting side of the RLC entity is re-established:-discard SDUs in the transmitting side that have been completely transmitted (the AMD PDUs containing segments of the SDU and the Length Indicator indicating the end of the SDU have been transmitted);-The UE may also discard partially transmitted SDUs (at least one AMD PDU containing a segment of the SDU has been transmitted).可以得知，如果是RLC接收实体被重建，那么接受端的AMD PDUs都会被删除；而如果是RLC发送实体被重建，当UE已经发送了某个SDU所包含的至少1个AMD PDU，那么UE就会删除这个SDU。由于之前在FACH收到的AMD PDU不足以组成1个SDU， RLC 接收端重建时还被删除了，而且UE认为第1个ping包组成的SDU已经发送了部分AMD PDU，又把该SDU给删除了，导致这个ping包不可能以RLC重传的方式进行重传，所以Ping FACH 1460就超时了。从测试log分析结果和协议分析来看，两方面的分析结果是统一的。由于RLC PDU size变化导致RLC实体双边重建，触发了这个问题。7. F2 UNBARRED指标情况7.1 修改方案 打开HSDPA/HSUPA状态迁移开关 将多载波F2、F3小区的SIB4开关打开 将多载波F2、F3小区的空闲态禁止重选时间修改为10s 将F2、F3小区UNBARRED 将F2、F3小区的异频重选启动门限修改为-2 将F2、F3小区的重选偏置设置为-50 修改FACH策略指示，将其由” INTER_FREQ_AND_INTER_RAT”改为” INTER_RAT”7.2 话务量流量变化情况时间AMR话务量PS R99上行话务量(MB)PS R99下行话务量(MB)HSUPA流量(MB)HSDPA流量(MB)12/03/20111099.227813376.572424888.38671920014.7188166795.95712/04/20111055.459713187.6812548889744170770.599912/05/20111147.136112738.236055224.40257818632.5344152907.023612/06/20111136.148612875.570555717.66351620235.9454154530.985112/07/20111155.562513230.471414744.58039120363.4667156284.594812/08/20111243.20412894.015435395.32097718864.2642160719.087912/09/20111269.548613326.079885602.04695320812.8513154003.933712/10/20111166.498614258.820084809.67613319197.6716175701.286412/11/20111100.956913201.88435126.79027319580.2862168196.803612/12/20111180.634713379.378444879.72007819390.424164055.075712/13/20111169.680612658.09025313.55377323597.9631156905.312612/14/20111182.505614558.834286442.22079723543.7875169292.8177同期增幅2.33%10.04%35.78%15.62%8.32%修改后话务量无异常，但是流量方面均有所增长。时间HSDPA单MAC-d flow平均吞吐率HSUPA单MAC-d flow上行平均吞吐率12/03/2011678.248439.193312/04/2011665.826344.097812/05/2011620.493435.061212/06/2011575.476738.185612/07/2011565.692136.956212/08/2011602.38733.058412/09/2011627.76937.94212/10/2011665.049133.738812/11/2011670.1834.991412/12/2011638.592632.849512/13/2011665.57243.274612/14/2011749.233743.3688同期增幅32.45%32.45%修改后HSPA的平均吞吐率均有明显提升。7.3 接入性能时间服务类RRC建立成功率非服务类RRC建立成功率AMR业务RAB指配成功率PS业务指配成功率HSDPA业务RAB指配成功率HSUPA业务RAB指配成功率12/03/201199.801698.965899.829899.806399.801199.899512/04/201199.802298.967899.803399.798599.793999.902812/05/201199.817799.09799.842399.807499.802799.904212/06/201199.787198.97399.765699.507499.509199.66312/07/201199.772898.951399.793799.658599.650699.714512/08/201199.795198.892299.787799.768899.763799.851912/09/201199.761298.88999.772899.752299.749599.843812/10/201199.769798.83899.80999.799599.795999.898712/11/201199.766598.974499.763499.812199.807599.897812/12/201199.72998.890799.612699.811699.811199.895512/13/201199.776998.97599.790399.815499.811699.905212/14/201199.751798.952199.781399.835399.831999.9132同期增幅-0.02%0.00%-0.01%0.18%0.18%0.20%接入指标正常。7.4 切换性能时间软切换成功率异频应切换成功率CS域异系统切换成功率PS域异系统切换成功率12/03/201199.967295.529197.991473.056812/04/201199.968896.524798.349774.083412/05/201199.972496.449998.051774.011812/06/201199.968796.49898.205275.408412/07/201199.955295.411298.558875.103312/08/201199.970396.215597.800474.790912/09/201199.971696.140998.18874.58112/10/201199.972495.779498.279873.577212/11/201199.968296.529498.560173.819112/12/201199.970996.346697.815874.165512/13/201199.969496.80498.22373.890512/14/201199.965796.445598.282272.9677同期增幅0.01%1.08%-0.28%-2.84%切换指标正常。7.5 保持性能时间AMR业务掉话率PS业务掉线率HSDPA业务掉线率HSUPA业务掉线率12/03/20110.30520.24350.2360.228812/04/20110.30290.24740.24090.227312/05/20110.27840.23140.2240.222512/06/20110.31070.25140.24140.248112/07/20110.34060.25380.23950.221712/08/20110.30390.23460.22610.220112/09/20110.31060.22990.22240.206912/10/20110.3030.2430.23380.215412/11/20110.3190.23730.2290.22112/12/20110.32950.21640.20730.194512/13/20110.32220.36830.34980.351712/14/20110.31020.39340.29380.2962同期增幅-8.93%55.00%22.67%33.60%在保持性方面，AMR业务掉话率并无异常，但是PS业务掉线率有明显恶化，但是相对前期F2/3小区BARRED状态时的掉线率有明显好转。 启用状态迁移时掉线率（2011-10-09） 调整空闲态禁止时间为10s时掉线率（2011-11-8） F2/3小区UNBARRED时掉线率（2011-12-14）下一步继续分析掉线恶化原因。7.6 资源准入统计 NEW CALL资源准入时间NEWCALL资源申请失败-码资源NEWCALL资源申请失败-下行功率NEWCALL资源申请失败-HSDPA用户数NEWCALL资源申请失败-HSUPA用户数NEWCALL资源申请失败-上行CE12/03/201114103801460630112/04/201141284018364120112/05/2011151179014771143612/06/2011511762814168108812/07/20113513452021460228112/08/201121344317878131012/09/2011216874219350211112/10/2011612483426844176612/11/2011171