中興TD-SCDMA深圳無線網絡KPI提升優(yōu)化案例(doc 20頁).doc

中興TD-SCDMA深圳無線網絡KPI提升優(yōu)化報告第1章 TOPN重點小區(qū)分析和優(yōu)化針對重點小區(qū)跟蹤其信令，通過信令分析查找PS業(yè)務無線接入失敗和掉線的原因，提出解決方案進行優(yōu)化，以及進行優(yōu)化驗證；并對失敗原因進行分類統(tǒng)計，提取共性問題解決無線網絡同樣的問題。下面針對造成PS域呼通率、掉線率差的問題的主要原因進行分析。1.1 PS域呼通率低通過對各重點小區(qū)的信令進行分析，對造成PS域接入失敗的原因進行規(guī)類統(tǒng)計得到，影響PS域無線接通率較差的主要原因是：SIM卡上下行簽約速率為2.24Mbps，目前TD-SCDMA系統(tǒng)不支持該上下行速率導致接入失??；網絡中的終端廠家測試量非常大、話務量大，導致終端廠家所在的幾個小區(qū)系統(tǒng)無線資源緊張，引起RAB建立排隊等待超時而接入失??；RAB建立過程中無線鏈路失敗導致的接入失敗，這主要是由于用戶在室內進行呼叫，而室內信號強度弱引起的。1.1.1 SIM卡簽約問題SIM卡簽約過大，系統(tǒng)沒有卡所需的資源，從而被RNC發(fā)出RabAssignmentFail造成的接入失敗。1.1.1.1 采取的措施和計劃該問題的解決需要協(xié)調移動，更改SIM的簽約，避免因簽約過大造成大量的接入失敗。1.1.1.2 案例分析IMSI：460077107501317用戶在50992小區(qū)接入失敗，具體信令如下：從上面信令可以看出（RabAssignmentRequest），用戶申請的上下行速率均為2.24Mbps速率，因此RNC直接給CN返回 RabAssignmentFail信令。從目前TD-SCDMA系統(tǒng)支持的上行速率來看，2.24Mbps的速率是肯定不支持的；而且從系統(tǒng)資源來看，在不支持HSUPA的情況下，系統(tǒng)無法提供下行2.24Mbps所需的資源。從而導致接入失敗。根據(jù)上圖RabAssignmentFail的解碼消息，可以看出RabAssignmentFail的原因是radioNetwork = TRANAP_requested_maximum_bit_rate_for_ul_not_available，也可以說明主要是因為無法滿足要求的上行最大速率導致的接入失敗。1.1.2 系統(tǒng)資源問題系統(tǒng)資源問題主要表現(xiàn)在無線資源不足，引起RAB排隊等待超時，從而導致RAB指配失敗。具體表現(xiàn)為：CN向RNC發(fā)起RabAssignmentRequest 后，由于無線資源不足導致RNC很快回RabAssignmentQueued消息；當?shù)却?秒鐘后，達到最大的等待時間而無線資源仍然不足時，RNC回消息RabAssignmentFail給CN，最終導致接入失敗。1.1.2.1 采取的措施和計劃對于系統(tǒng)資源不足的問題，可以通過擴容解決；也可以打開RBC算法，這樣系統(tǒng)會在無線資源緊張的時候根據(jù)用戶的實際情況進行資源調整，降低用戶速率空出資源以接納新的用戶，提高PS域的無線接通率。1.1.2.2 案例分析問題描述：IMSI：460077107700719用戶在50992小區(qū)接入失敗。問題分析：跟蹤該小區(qū)的接入失敗信令，具體信令如下：從上面信令中RabAssignmentRequest的解碼消息可以看出，用戶申請的上下行速率為128K/384Kbps速率，目前TD-SCDMA系統(tǒng)滿足該上下行速率的業(yè)務接納。對上面小區(qū)信令分析發(fā)現(xiàn)，在11：14：49秒RNC收到CN的RabAssignmentRequest消息后，RNC很快會回RabAssignmentQueued消息；表明由于系統(tǒng)無線資源不足，RAB請求進入隊列等待；當?shù)却?秒鐘后，達到最大的等待延時而無線資源仍然不足時，RNC即回消息RabAssignmentFail給CN，導致接入失??；并且由于接入失敗導致網絡側釋放IU連接。在現(xiàn)場進行驗證測試時，發(fā)現(xiàn)IMSI：460077107502074在50922小區(qū)進行PS384業(yè)務后，始終無法切換到50992小區(qū)（主頻點10088、擾碼63），此時50992小區(qū)的PCCPCH RSCP已經比50922信號強20dB了，具體見下圖。從下圖信令中RabAssignmentRequest的解碼消息可以看出，用戶申請的上下行速率為64K/384Kbps速率，從下面后臺跟蹤的信令上看，11：02：47秒RNC收到測量報告后接著又重新下發(fā)了測量控制消息。檢查相關配置無誤，因此判斷目標小區(qū)50992存在資源不足從而造成RNC沒有判決切換，從之前的信令分析當中也可以看到50992小區(qū)資源不足。為此，通過后臺查看碼道分配情況。從碼道分配情況可以看出，已經沒有足夠的資源接納1個PS384業(yè)務，因為10080為HSDPA的頻點，下行大部分碼道分配給了PDSCH使用；10096頻點已經被1個PS384K的業(yè)務占用了；10088頻點已經有1個PS128K的業(yè)務使用，也沒有足夠的資源分配給新的PS384K業(yè)務。碼道分配情況具體見下圖：因此，即使RNC收到了切換測量報告，但是由于目標小區(qū)50992沒有足夠的資源，所以RNC沒有判決切換，從而沒有發(fā)起切換操作，而是接著RNC又重新下發(fā)了測量控制消息。同時，從上圖IMSI：460077107502074進行切換的時間看，測試手機到11：17：43秒還在發(fā)出切換請求，但RNC始終沒有判決切換。結合50992小區(qū)的碼道分配情況，可以看出IMSI：460077107700719用戶的確是因為50992小區(qū)系統(tǒng)無線資源不足導致了接入失敗。如上圖所示，在9月18日3個小時內總共有12次RabAssignmentQueued、由于系統(tǒng)資源不足導致了接入失敗，其中IMSI：460077107700719用戶就達10次，從而直接導致了PS域無線接通降差。解決方案：由于通過擴容來解決系統(tǒng)資源不足的問題不能馬上實現(xiàn)，以及避免其他小區(qū)相同接入失敗的問題，快速的提升PS域的無線接通率指標，因此通過打開RBC算法來解決RAB排隊超時導致接入失敗的問題。優(yōu)化結果：RBC算法開關是2008-9-19打開，下面是后臺匯總的2008-9-12008-9-7和2008-9-202008-9-22每天PS域的無線接通率指標。時間分組域業(yè)務流量PS域RAB指派建立成功RAB數(shù)目PS域RAB建立請求的RAB數(shù)目PS域RAB建立成功率PS域RRC連接建立成功次數(shù)PS域RRC連接建立嘗試次數(shù)（業(yè)務相關）PS域RRC連接建立成功率（呼叫相關）PS域無線接通率KBYTE%2008-9-12165678.26 1686176195.74 1181119099.24 95.02 2008-9-23742936.27 3551392490.49 2910296498.18 88.85 2008-9-33982711.80 5768633990.99 4016406098.92 90.01 2008-9-44896351.13 5328569393.59 4119417698.64 92.31 2008-9-53575283.35 5329588790.52 4076413998.48 89.14 2008-9-64887054.18 5986647892.41 3868413693.52 86.42 2008-9-73816851.32 5110538894.84 3553370295.98 91.02 2008-9-204692675.28 6010622696.53 4191425598.50 95.08 2008-9-216589536.37 6892712496.74 4852489899.06 95.83 2008-9-226584091.93 8390859997.57 6193622299.53 97.11 從RBC算法開關打開前后PS域無線接通率的對比情況來看，RBC算法開關打開后，PS域無線接通率明顯的改善了。1.1.3 參數(shù)配置問題可能由于部分系統(tǒng)參數(shù)設置存在問題或前后臺配置不一致，可以導致PS域無線接入失敗。1.1.3.1 采取的措施和計劃定期進行后臺參數(shù)的核查，保證參數(shù)配置的準確和合理性，避免由于參數(shù)配置導致的無線接入失敗現(xiàn)象。1.1.3.2 案例分析問題描述：由后臺KPI發(fā)現(xiàn)南園村2扇和3扇PS域的無線接通率很差。無線接通率較低的原因主要是在用戶進行PS業(yè)務時RAB建立成功率很低。問題分析：對該問題進行定點和DT現(xiàn)場復現(xiàn)。測試數(shù)據(jù)如下：通過路測數(shù)據(jù)和現(xiàn)場的情況來看，定點測試位置的PCCPCH RSCP和PCCPCH C/I良好。從路測采集的信令來看，南園村2扇和3扇在進行PDP激活時被拒絕了，從而導致了接入失敗。具體的信令如下：從Activate PDP ContextReject的解碼消息來看，拒絕的原因Protocol error, unspecified 。Activate PDP ContextReject具體的解碼消息圖如下：從后臺跟蹤的信令來看，UE在發(fā)起Activate PDP ContextRequest后的RAB建立過程中，NodeB向RNC上報RadioLinkReconfigurationReady后，RNC立即向NodeB下發(fā)了一條RadioLinkReconfigurationCancel，從而導致了RAB建立失敗和PDP激活失敗。具體的后臺信令如下圖所示：RadioLinkReconfigurationCancel信令的下發(fā)是RNC和NodeB之間的事情，涉及Iub口。通過查看后臺的參數(shù)配置，發(fā)現(xiàn)RNC和NodeB的ALL2配置不一致。解決方案：在后臺進行整表同步，保證RNC和NodeB的ALL2配置一致。優(yōu)化結果：這2個小區(qū)PDP激活正常和PS業(yè)務接入正常。1.1.4 網絡中存在的干擾問題來自系統(tǒng)內或系統(tǒng)外的干擾能導致接入失敗和掉話現(xiàn)象。1.1.4.1 采取的措施和計劃通過路測和后臺測量確定是否存在干擾，排查干擾產生的原因和干擾源，并進行針對性的優(yōu)化。1.1.4.2 案例分析問題描述：后臺KPI表明南山鉅建2扇PS域的無線接通率很差。無線接通率較低的原因主要是在用戶進行PS業(yè)務時RAB建立成功率很低。問題分析：對該問題進行定點和DT現(xiàn)場復現(xiàn)。測試數(shù)據(jù)如下：通過路測數(shù)據(jù)和現(xiàn)場的情況來看，在上圖的紅色圓圈內PCCPCH C/I部分區(qū)域較差，并且掉線一次。在該區(qū)域還出現(xiàn)PS域下載速率下降和不穩(wěn)定的現(xiàn)象。而南山鉅建2扇覆蓋的其他區(qū)域的下載速率能達到業(yè)務的要求速率、并且速率穩(wěn)定。從路測現(xiàn)場數(shù)據(jù)來看，在上述區(qū)域的BLER比較高，下行SIR很差，下行時隙的ISCP也比較高、并且大于同時隙的RSCP。因此確定該區(qū)域存在下行干擾。具體情況見下圖。由于附近沒有室內的站點，因此把南山鉅建2扇的頻點修改為10071，并進行驗證測試。從路測數(shù)據(jù)和現(xiàn)場情況來看，BLER和下行時隙的ISCP已經正常了，下載速率也穩(wěn)定和達到業(yè)務的要求了。具體情況見下圖。因此分析確定該區(qū)域的下行干擾是系統(tǒng)內部產生的干擾。解決方案：結合周邊區(qū)域站點使用的頻點情況，最終修改南山鉅建2扇的頻點為10096，并進行驗證測試。優(yōu)化結果：從路測數(shù)據(jù)和現(xiàn)場情況來看，BLER和下行時隙的ISCP同樣正常，下載速率同樣滿足業(yè)務的要求。具體情況見下圖。1.2 PS域掉線率高PS域無線掉線率指標普遍偏高，其原因首先與PS業(yè)務的特點相符合，PS用戶相對于CS用戶來說保持時間較長，并且呼叫的次數(shù)比較少，這樣一來會造成PS業(yè)務的掉話率相對于CS業(yè)務的掉話率來說要高些；其次，PS用戶一般分布在室內或車內，而這些地方覆蓋較差，這也是影響到PS業(yè)務掉話率較高的一個主要原因；第三，目前終端不成熟，長時間的PS業(yè)務會由于終端原因造成掉話；第四，無線鏈路失敗導致PS業(yè)務掉線。1.2.1 終端問題終端的性能是影響到PS業(yè)務掉話率較高的一個重要原因，特別是長時間的PS業(yè)務會由于終端異常引起掉話。1.2.1.1 采取的措施和計劃更換南山展示廳因終端原因造成大量掉話的宇龍酷派演示終端；有待終端廠家改善商用終端的性能；對引起大量掉話現(xiàn)象的個別終端或個別類型終端進行處理，以改善其性能。1.2.1.2 案例分析問題描述：從后臺KPI指標發(fā)現(xiàn)深圳移動TD-SCDMA南山展示廳PS業(yè)務的無線掉話率較差。該處為TD業(yè)務演示場所，用戶發(fā)起業(yè)務次數(shù)較多、話務量占全網比重較大，對整體網絡指標影響很大。初步判斷號碼終端掉線頻繁，該號碼占用52082小區(qū)（主頻點10096、擾碼93）。問題分析：深圳移動TD-SCDMA南山展示廳建設了室內分析系統(tǒng)，配置2個小區(qū)、2個小區(qū)配置5M異頻頻點；室外周邊小區(qū)沒有和南山展示廳室內系統(tǒng)5M同頻的小區(qū)；在南山展示廳室內進行測試，室外小區(qū)信號相對室內信號很弱，相差20dB左右，室內覆蓋良好。測試結果見下圖。為了解決南山展示廳PS業(yè)務掉線的問題，在展示廳進行觀察和測試。找到號碼終端，該終端為做流媒體演示的酷派手機。通過了解，流媒體演示由工作人員自己操作，用戶不能直接操作。直接對號碼酷派手機進行反復操作，發(fā)現(xiàn)該手機掉線問題比較明顯，從后臺跟蹤信令發(fā)現(xiàn)該終端經常會發(fā)起小區(qū)更新；繼續(xù)操作發(fā)現(xiàn)該手機經常在重開機后還是做不了業(yè)務，現(xiàn)場工作人員也反映該終端掉線比較頻繁；多次操作后，該終端出現(xiàn)搜不到卡和沒有網絡的情況，宇龍酷派工作人員也反饋可能終端長時間工作過熱導致終端主板線路故障而使手機收不到網絡，因此判斷掉線可能是由該終端問題造成的。為了驗證該酷派終端問題，在演示廳內端外其他終端業(yè)務正常展示的情況下，更換終端進行測試。采用凱明測試手機連接RNT路測軟件，占用52082小區(qū)進行流媒體業(yè)務測試，測試40分鐘沒有掉線；之后每5分鐘一次斷開重新?lián)芴枩y試，在第6次時一段時間后速率會明顯下降，但并不影響流媒體業(yè)務。采用商用終端ZTE U980、ZTEU85在同一小區(qū)進行流媒體業(yè)務，演示廳內其他終端業(yè)務正常展示，測試5次共90分鐘左右，沒有掉線情況發(fā)生。由上判碼使用的酷派終端性能問題導致了PS業(yè)務掉線頻繁。因此建議更換該號碼使用終端，避免因終端問題引起的掉線。1.2.2 無線鏈路失敗問題弱覆蓋和網絡中存在的干擾都可以引起無線鏈路失敗，從而導致PS業(yè)務掉線。1.2.2.1 采取的措施和計劃對于室外弱覆蓋區(qū)域進行覆蓋優(yōu)化調整或增補站點改善覆蓋；對于室內弱覆蓋區(qū)域通過建設室內分布系統(tǒng)改善覆蓋；對于網絡中存在的干擾，通過路測和后臺測量確定是否存在干擾，排查干擾產生的原因和干擾源，并進行針對性的優(yōu)化。1.2.2.2 案例分析問題描述：從后臺KPI指標發(fā)現(xiàn)朗山北T_1、朗山二T_3小區(qū)的PS業(yè)務的無線掉話率較差。問題分析：通過現(xiàn)場DT測試數(shù)據(jù)來看，朗山北T_1、朗山二T_3覆蓋區(qū)域的PCCPCH RSCP和PCCPCH C/I良好。下面是測試的PCCPCH RSCP和PCCPCH C/I結果圖。從這2個小區(qū)跟蹤的信令分析來看，發(fā)生PS業(yè)務掉話的呼叫主要集中在5個號碼上，分別是IMSI:460077107900285、460077107902711、460077107902713、460077107902841、460077107903318。通過用戶回訪得知這幾個用戶是宇龍酷派的測試號碼，宇龍酷派終端測試主要是在辦公室內進行的，由于宇龍酷派信息港所在樓宇沒有建設室內分布系統(tǒng)，從而只能采用室外站點信號進行覆蓋。同時，從下面的宇龍酷派信息港位置示意圖可以看出，其所在位置處于多個小區(qū)的邊緣中心（通過宇龍酷派信息港室內測試，主要由朗山北T_1、朗山二T_3這2個小區(qū)進行覆蓋）。由于室內墻體穿透損耗的影響，覆蓋宇龍酷派信息港辦公大樓的室外信號較弱，沒有較強的主服務小區(qū)，切換頻繁；由于宇龍酷派測試量大、話務量大，所以這2個小區(qū)的每個載波負荷重，而朗山北T_1主頻點是10080、朗山二T_3主頻點是10096，屬于5M同頻，在沒有主服務小區(qū)的情況下業(yè)務信道有一定的同頻干擾。這都容易導致無線鏈路失敗的情況，從而引起掉話。宇龍酷派信息港的位置示意圖：解決方案：在宇龍酷派信息港辦公樓建設室內分部系統(tǒng)，徹底解決因室內覆蓋信號弱、小區(qū)容量不足導致的接入失敗和掉話問題。在室內分布系統(tǒng)建設開通之前，可以通過調整朗山北T_1、朗山二T_3的頻點使其為5M異頻，避免2個小區(qū)之間的同