TD-SCDMA無線網絡優(yōu)化案例分析8/7/20251第六章：TD-SCDMA無線網絡優(yōu)化案例分析第四章：

TD-SCDMAKPI指標及問題分析第一章：

TD-SCDMA無線網絡優(yōu)化介紹第五章：

TD-SCDMA路測及分析軟件的使用第六章：

TD-SCDMA無線網絡優(yōu)化案例分析第三章：

TD-SCDMA無線資源管理第二章：TD-SCDMA信令根本流程8/7/20252本章目標:1：熟悉TD-SCDMA弱覆蓋引起掉話情況2：掌握TD-SCDMA乒乓切換引起掉話情況3：熟悉TD-SCDMA信號波動引起掉話情況4：掌握TD-SCDMA越區(qū)覆蓋引起掉話情況5：熟悉TD-SCDMA干擾引起掉話情況6：了解TD-SCDMA其他案例本章培訓目標8/7/20253本章內容:1：TD-SCDMA弱覆蓋引起掉話案例2：TD-SCDMA乒乓切換引起掉話案例3：TD-SCDMA信號波動引起掉話案例4：TD-SCDMA越區(qū)覆蓋引起掉話案例5：TD-SCDMA干擾引起掉話案例6：TD-SCDMA其他案例7:本章練習本章培訓內容8/7/20254案例1－弱覆蓋引起掉話

案例說明：此掉話點位于杏濱路的拐角處。杏濱站點的位置非常低，根本與水平面平行。所以對拐角點的覆蓋很弱。而相鄰小區(qū)杏林高浦2在此點方向上有遮擋。8/7/20255問題所在點圖中黑圈所示是易發(fā)生掉話的點。根據路測數據和實地勘查，分析發(fā)現，高浦2在測試路線方向上有遮擋，導致信號時強示弱，造成掉話。8/7/20256解決方案新杏林是個塔站，站高很高。在路線上視距傳輸，沒有遮擋，可以設計新杏林2作為此測試路線的主效勞小區(qū)。因此做如下調整：降低高浦2小區(qū)的功率，以減小高浦2對此測試路線的影響。調整杏濱2到新杏林2的CIO〔小區(qū)偏置〕為6，加快杏濱2到新杏林2的切換速度，防止?jié)撛诘牡粼?。提高杏濱2天線的高度。杏濱2和新杏林2之間路口信號覆蓋偏弱，可能會導致掉話，因此提高杏濱2天線的高度，加強該路口的覆蓋。刪去新杏林2與高浦1之間不合理鄰區(qū)關系，防止切換到高浦1的背瓣。8/7/20257效果評估調整后的路測結果如上圖所示。從結果可以看出調整后，掉話點消失，切換正常。注：來回路測屢次，故切換標識有多個。8/7/20258案例2－乒乓切換引起掉話案例說明：此點位于杏林南路、杏林北路、杏林東路、杏林西路的交叉口。周圍有杏西站，建行站，杏林信用社站，新杏林站。信號比較雜，干擾比較嚴重。8/7/20259問題所在點圖中紅色圈中是發(fā)生乒乓切換的區(qū)域，乒乓切換主要發(fā)生在杏林杏西2和建行2，信用社1以及新杏林3之間，尤其是在等紅綠燈的時候。分析發(fā)現，發(fā)生乒乓切換的主要原因是該十字路口南北向和東西向的主導小區(qū)不突出，導致了乒乓切換，同時在路口南北向，尤其是路口南邊，覆蓋在-90dBm左右，容易發(fā)生掉話。8/7/202510解決方案考慮到附近建行的站點比較高〔38m〕，而且距離路口不遠，所以可以讓建行2小區(qū)作為該十字路口的主效勞小區(qū)，杏西2、信用社3和新杏林3分別在路口以西、路口以南、路口以東約20m~50m的地方發(fā)生切換，這樣，車輛在南北和東西雙向行駛路過該路口時，只發(fā)生兩次切換，即使是等紅燈的時候，也不會有乒乓切換。因此做如下調整：建行2的方位角由120度調整為150度，下傾角由8度壓為10度。建行2的PCCPCH的功率調整為33dBm，DwPCH調整為36dBm。目的是加強十字路口的覆蓋，同時控制其覆蓋范圍不要太遠。建行2到杏西2的CIO調整為6。由于杏西2和建行2之間的切換帶比較窄，為了能夠從建行2快速切換到杏西2，調整該CIO為6。8/7/202511效果評估調整后的結果如上圖。從上圖可以看出，乒乓切換消除。由于在整個調試過程中，只存了一個log文件，而圖中顯示了調試過程中所有的切換，故在圖中所標示的切換帶之外還有一些切換。8/7/202512案例3－信號波動引起掉話案例說明：建行到特運站之間的路線上有個橋。從路測結果來看，在橋上，建行1的信號有較大波動，在波動前特運2和建行1的信號相當，不滿足切換條件。之后建行1突然有10db左右的衰減，信號變弱，造成切換困難，導致掉話。8/7/202513問題所在點8/7/202514問題所在點〔續(xù)〕8/7/202515解決方案從路測結果來看，在橋上，建行1的信號有較大波動，在波動前特運2和建行1的信號相當，不滿足切換條件。之后建行1突然有10db左右的衰減，信號變弱，造成切換困難，導致掉話。因此做如下調整：調整了建行1到特運2的CIO〔調為6〕，使其在建行1信號變差前，盡快由建行1切換到特運2。調整了特運2到建行1的CIO，將其調為－10，防止在其相反方向上由于建行1的信號波動導致誤切、乒乓切換等現象的發(fā)生。8/7/202516效果評估從調整后的路測結果來看，調整后，在建行1信號變弱之前，終端就由建行1切換到特運2，防止了因切換造成的掉話現象的產生。8/7/202517案例4－越區(qū)覆蓋引起掉話案例說明：在特運，正新到二化的測試路線上，建行1的信號有時候很強，造成誤切換到建行1導致掉話。實際上建行1到圖中所示點距離為1.5公里，而在此處建行1的信號為－72dbm，信號非常強，說明建行1越區(qū)覆蓋很嚴重。而且從路測結果上看，福太1的信號為－78dbm，福太2的信號為－72dbm，都非常強，會對此段測試路線造成很強干擾。

8/7/202518解決方案根據案例說明做如下調整：調整了特運2到建行1的CIO，將其調為－10，使其不容易切換到建行1。調整了建行1的方位角＆下傾角，降低建行1對此段路線上的干擾。壓低了福太1、福太2的下傾角，降低福太1、福太2對此測試路段上的干擾。8/7/202519效果評估從路測結果上看，建行1、福太1、福太2在此段測試路線上的功率有不同程度的降低，相比調整前降了20db左右，對此段路線上的干擾減小了。8/7/202520案例5－干擾引起掉話案例說明：廈門大橋的四周都是開闊的海面，信號的傳輸環(huán)境比較好，所以極易受到其他基站信號的干擾。在優(yōu)化前，可以檢測到誠毅學院、貨運樞紐、集美航院、集美大社、集美、神山等6個站將近10個小區(qū)的導頻信號，主導頻不明確，終端在大橋上頻繁發(fā)生切換，掉話率很高。8/7/202521解決方案覆蓋解決方案因為誠毅學院、貨運樞紐兩個站分別在廈門大橋的橋頭，而且傳播環(huán)境很好，所以決定以這兩個站作為廈門大橋的主要覆蓋小區(qū)。減小了誠毅學院2扇區(qū)和貨運樞紐3扇區(qū)的天線傾角，增大了覆蓋半徑。在不影響其他基站覆蓋的前提下，壓低了主要干擾基站天線的傾角，并降低了神山3扇區(qū)的發(fā)射功率，以減小對大橋的干擾。在采取了這些措施后，在大橋上能夠測到的主導頻根本上就是誠毅學院2扇區(qū)和貨運樞紐3扇區(qū)的信號。其他干擾信號明顯降低。切換解決方案由于廈門大橋的距離非常長，將近2.5公里，誠毅學院2和貨運樞紐3的信號在經過海面反射后，會形成越區(qū)覆蓋，在大橋上還是會在這兩個小區(qū)上有乒乓切換，為了平滑過渡，將誠毅學院2和貨運樞紐3對對方小區(qū)的切換小區(qū)獨立偏置CIO分別調整為－8和－6。目的是只有當目標小區(qū)的信號明顯強于效勞小區(qū)的信號后，網絡側才會發(fā)起切換。廈門大橋是廈門的交通樞紐，經常堵車，所以即使增大了切換的CIO，在堵車的情況下也經常發(fā)生乒乓切換，所以將切換觸發(fā)時間從1.28秒增大為2.56秒。調整后，在堵車的情況下乒乓切換次數有下降。8/7/202522效果評估采取了以上措施后，大橋的通話效果得到了很明顯的改善，乒乓切換次數大大降低。可以從優(yōu)化前后的圖例中看出優(yōu)化結果。8/7/202523案例6－測量方式影響連雨第1小區(qū)存在7個異頻鄰小區(qū)，在圖示紅方塊處6UE進行呼叫，UE上報測量報告狀況如下：460058031202190無異頻測量報告460058031202142正常460058031202176無異頻測量報告460058031202157正常460058031202179正常460059031200546正常問題現象：終端通過切換帶時因為沒有及時上報測量報告，沒有正常切換導致掉話。原因分析：從同頻網絡轉為N頻點網絡，鄰小區(qū)數量增加，由于UE的測量能力有限，500ms的周期性測量經常喪失異頻測量報告，網絡性能因此受到影響。解決方法：將上報周期延長至1s；或將周期性測量上報改為事件觸發(fā)上報。8/7/202524案例7－出RNC切換成功率問題正常流程異常流程問題現象：出RNC切換成功率低；問題分析及解決方法：出RNC切換成功率由低到高排名，發(fā)現國防大廈3的出RNC切換成功率只有60％；分析國防大廈3當天的Uu口trace，發(fā)現大局部失敗的信令流程是：原RNC在發(fā)送relocationrequest消息后，CN回復失敗信令：relocationpreparationfailure，原因是requestedinformationnotavailable。具體原因為位置更新中UE觸發(fā)了出RNC切換，CN拒絕位置更新中的出RNC切換請求，導致出RNC切換失敗。修改參數，使UE位置更新過程中的RRC連接進入FACH狀態(tài)。問題解決：未出現位置更新過程中的出RNC切換請求，出RNC切換成功率提高。8/7/202525案例8－局部終端PDP激活不成功異常流程問題現象：局部終端PDP激活不成功；問題分析及解決方法：跟蹤PDP激活不成功的單UEtrace；分析單UEtrace，發(fā)現PDP激活過程中RBsetup過程不成功，網絡側發(fā)送RBSETUPREQUEST消息后，終端未回復RBSETUPCOMPLETE消息，導致RABAS