1、北京移動北京移動TD精英營專題培訓精英營專題培訓案例分析案例分析1： PS掉線率優化掉線率優化應提前具備或了解的相關知識：應提前具備或了解的相關知識：HSDPA技術相關知識技術相關知識UE連接態的四種狀態連接態的四種狀態 （四種狀態（四種狀態/遷徙機制遷徙機制/目前網絡側及終端支持情況）目前網絡側及終端支持情況）PS業務特性及常見業務特性及常見KPI定義定義信令流程及碼流解碼分析能力信令流程及碼流解碼分析能力重配機制與信令重配機制與信令 （物理信道重配（物理信道重配/傳輸信道重配傳輸信道重配/RB重配）重配）小區更新與無線鏈路失敗小區更新與無線鏈路失敗 （七種情況（七種情況/小區更新的標準流程

2、）小區更新的標準流程）RBC算法與算法與4A/4B事件事件三個常用協議三個常用協議 TS 25.331 / TS25.433 / TS 25.413內部公開問題描述問題描述n目前，北京某區域TD網絡各項指標均基本正常，但PS掉線率最近一直居高不下。對比同樣采用我司設備的其他區域及其他城市的TD網絡的指標，不難發現PS掉線率遠高其他地區及城市，最嚴重的時候日平均達到53%。但從小區指標來看，全網沒有掉線次數特別突出的小區，屬普遍存在現象。內部公開PS掉線率計算公式：掉線率計算公式：nCMCC集團公司公布的PS掉線率公式如下：n由PS掉線率統計公式可知，RNC請求釋放分組域的RAB一次記為掉線一次

3、，而RNC請求釋放的分組域RAB的原因就可以理解為PS掉線的原因。n思考思考：1. 在在TD中，什么是掉話？中，什么是掉話？ 在網絡側以及路測端，又是在網絡側以及路測端，又是如何定義掉話的？如何定義掉話的？ 2. “只要只要UE開始讀廣播消息了開始讀廣播消息了”，就是掉，就是掉話話 此種說法是否正確？此種說法是否正確？總數目指派建立成功的分組域總數目請求釋放的分組域RABRABRABRNC內部公開PS掉線原因統計掉線原因統計 n從上圖指標看，問題區域RNC請求釋放的分組域RAB（即PS掉線）次數達到181次，其中：l原因值為Ue_Operate_TimeOut的釋放次數達到123次，占掉線總數

4、的68%;l原因值為Radio link failure的次釋放次數達到31次，占總掉線次數的17%。n這兩種原因引起的釋放次數占了全網掉線總次數的85%，是引起問題區域PS掉線率高的主要原因。內部公開原因分析原因分析n由以上分析可知，Ue_Operate_TimeOut（UE響應超時）和Radio link failure（無線鏈路失敗）是導致PS掉線率的兩個主要原因。n如果能將這兩類問題解決，那么PS掉線率高的問題就迎刃而解了。內部公開無線鏈路失敗（無線鏈路失敗（Radio link failure）n系統出現無線鏈路失敗的原因可以分為三類： la）終端側出現異常）終端側出現異常n當終端發

5、生異常，沒有上發信號，導致基站側檢測不到上行信號而報無線鏈路失敗。終端側的異常包括： 終端本身出現異常，比如死機。 終端與電腦的連接出現異常，比如因為連接線、USB插口、插槽松動而斷線，或終端在電腦上的驅動程序出現異常。 終端在電腦上的應用程序出現異常。 電腦出現異常導致終端方面異常。n思考思考：如果終端側出現異常，用戶一般如何行為？：如果終端側出現異常，用戶一般如何行為？（提示：一般用戶會對終端進行重啟，數據卡重插拔或者電腦關（提示：一般用戶會對終端進行重啟，數據卡重插拔或者電腦關開機等（關機再開機也相當于終端重啟）。終端重啟之后，初開機等（關機再開機也相當于終端重啟）。終端重啟之后，初始化

6、過程中，將會進行一次始化過程中，將會進行一次Location Update過程，這從系統過程，這從系統側后臺信令上可以觀察到，并且從上次側后臺信令上可以觀察到，并且從上次RL Failure導致掉話到導致掉話到下次重新作起業務來也將會有較大的時延，通常要超過下次重新作起業務來也將會有較大的時延，通常要超過30秒。）秒。）內部公開無線鏈路失敗（無線鏈路失敗（Radio link failure）nb）無線信道環境出現深衰落或者強干擾）無線信道環境出現深衰落或者強干擾l無線信道環境出現深衰落或強干擾時，會導致基站沒有正確解釋終端發出的上行信號而報RL Failure，如果是出現深衰落，一般情況下，

7、下行鏈路的無線信道環境跟上行鏈路一樣，信道質量變差，下行功率會抬升得比較高，并且UE極有可能會上報Cell Update。l思考思考：幾個問題需要大家深入思考并確認（功課平時要做足：幾個問題需要大家深入思考并確認（功課平時要做足）l1. Cell Update 與與 radio link failure indication ？l2. TDD制式上下行鏈路的互易性？制式上下行鏈路的互易性？l3. 上行鏈路失步的判決機制？下行鏈路的判決機制？上行鏈路失步的判決機制？下行鏈路的判決機制？l4.相關的定時器與計數器？相關的定時器與計數器？內部公開無線鏈路失敗（無線鏈路失敗（Radio link fa

8、ilure）nc) 基站側出現異常基站側出現異常l基站解錯上行信號或接收不到上行信號而報無線鏈路失敗。此時基站應該會相關告警，且基本上不能接入和保持住包括PS在內的任何業務或終端了。n從其他商用城市的采樣數據來看，前面三種原因的比例是8：1：1。目前引起無線鏈路失敗主要還是終端問題和用戶插拔卡或者是撥號軟件響應造成。這些原因屬于不可控的范圍，只能從逐步改善終端性能解決。內部公開手機操作超時（手機操作超時（ Ue_Operate_TimeOut ）n系統出現Ue_Operate_TimeOut引起的掉線主要是因為物理信道重配置超時或RB重配置超時，而引起物理信道重配置超時或RB重配置超時的常見原

9、因有：la）存在UPPCH的干擾，如果是硬切換的情況下會造成上行同步過程的失敗，從而造成物理信道重配置失敗lb) 虛假的鄰小區關系造成物理信道重配置超時lc）RB重配置參數設置不合理造成RB重配置超時ld）功率參數配置不合理造成RB或物理信道重配置超時le) HS業務與R4業務之間的切換失敗，包括從R4到R5的切換和從R5到R4的切換，這種原因主要表現為RB重配置超時。 內部公開問題分析問題分析n鄰區關系前期經過認真核查，應不存在普遍問題。鄰區個數也不多。鄰區關系基本不會影響到Ue_Operate_TimeOut。n檢查HSDPA的功率參數設置，也未發現整體的異常。這方面的原因也可以排除。nU

10、e_Operate_TimeOut的原因很可能是終端問題和R5與R4業務之間的切換問題。內部公開問題重現及優化問題重現及優化n由上面的分析，終端問題導致的掉線不在我們可控范圍之內，Ue_Operate_TimeOut存在網絡的因素，也是最主要的PS掉線原因，我們只能從解決這個因素著手優化。n為此，選擇在某小區下，撥測重現問題，讓數據卡撥號后不斷使用各種業務，同時后臺對該數據卡IMSI進行信令追蹤。內部公開問題重現及優化問題重現及優化n在連續跟蹤2個多小時后，后臺發現Ue_Operate_TimeOut導致PS掉線的信令。n從采集的前后臺信令看，用戶在連續發了5個4B（降速）的測量報告后，開始進

11、行降速，從頻點為10071的HSDPA信道，切換到主頻點10055的DCH信道，如下圖所示。n這是典型的HSDPA信道和DCH信道的切換。內部公開問題重現及優化問題重現及優化內部公開問題重現及優化問題重現及優化n在這過程之后RNC接下來進行物理信道重配置（或RB重配置），從物理信道重配置信令解碼中可以看到，系統指示終端的連接狀態從原來的Cell_DCH躍遷到URA_PCH。n終端上報了物理信道重配置完成后，由于處于URA_PCH狀態，網絡側并不知道終端的具體位置（cell），當終端要發送上行數據時，根據TS25.331協議描述，必須通過CellUpdate過程躍遷回Cell_DCH狀態。內部公

12、開RRC States and State Transitions 內部公開目前行業里對四種狀態的支持情況目前行業里對四種狀態的支持情況n我司設備（RNC）早已經實現并支持所有的狀態。 但終端側，對URA_PCH狀態的支持效果都不好。在狀態的遷徙過程中，極易引起Ue_Operate_TimeOut造成釋放。n本次追蹤的信令也可以看出，在CellUpdate后，RNC下發小區更新確認消息，但隨后UE物理信道重配置超時，導致IuReleaseRequest（PS掉線）。掉線原因就是我們所關注的Ue_Operate_TimeOut。內部公開問題分析問題分析內部公開問題分析問題分析n在仔細分析和排查之

13、后，問題的關鍵點基本定位明晰。n在UE無法很好的支持PCH狀態的現狀下，我司網絡側能否做些修改，減少或者屏蔽掉此類問題、提高用戶感知？n換個角度想，為什么在別的地方并未大規模出現此類問題？后臺參數設置上到底有何不同？n思考思考：UE對對PCH態普遍支持不好，所以會出現：能從態普遍支持不好，所以會出現：能從CELL-DCH狀態躍遷至狀態躍遷至URA-PCH，但從，但從URA-PCH狀態躍遷回狀態躍遷回CELL-DCH態時，出現重配超時，導致態時，出現重配超時，導致PS掉話。掉話。 如果事先就考慮到這一如果事先就考慮到這一點，不讓點，不讓UE進入到進入到PCH態，是不是這個問題就不會出現了呢？態，

14、是不是這個問題就不會出現了呢？內部公開協議中對重配過程的說明：協議中對重配過程的說明：內部公開協議中對重配過程的說明：協議中對重配過程的說明：內部公開優化優化n重新認真復查網絡側與此相關的參數配置。n檢查RNC參數配置，發現RNC打開了RNC支持URA_PCH指示的開關。這有可能造成RNC在做信道分配、重配置等判決的時候，將終端在R5到R4信道轉換中躍遷到了URA_PCH狀態，直接造成狀態轉化時，手機操作超時，而PS掉話。n我們嘗試將其關閉，如下圖所示，觀察效果。內部公開優化優化內部公開驗證驗證n關閉URA_PCH后，從系統側統計的指標對比，問題區域全天PS掉線率從關閉當天開始，由原來的40%到60%，下降到10%以下。n而從優化之后的掉話原因來看，Ue_Operate_TimeOut原因的釋放次數從原來的100多次下降到十幾次，占總掉線次數的比例也從85%下降到18.75%，Ue_Operate_TimeOut的掉線原因已成為次要原因，如下表所示是優化前后一周同期的數據。內部公開總結n通過分析掉線的各種原因，找出PS掉線的主要原因是Ue_Operate_TimeOut，從撥測和網絡側信令追蹤證實Ue_Operate_TimeOut產生的原因是UE進入URA_PCH狀態后，從PCH態遷徙到