鎮江聯通CS掉話率提升專項鎮江聯通CS掉話率一直是網絡主要短板，指標排名也一直徘徊于全省下游，且從2013年9月初開始CS掉話率開始出現惡化，受到省公司高度重視。從10月中下旬我們開始了CS掉話率專項優化提升工作，經過兩個多月不懈努力，取得了顯著進展。鎮江聯通CS掉話率專項提升成果簡介鎮江聯通CS掉話率趨勢介紹由上圖我們可以看出，從9月初開始我們的CS掉話率開始出現惡化，在0.5%上下波動；到了10月份指標已經惡化到0.5%以上。從10月中下旬開始，我們開始了CS掉話率提升專項，從基礎工作做起，經過1個月左右努力，指標開始穩定在0.45%上下。通過我們的進一步優化，目前我們的CS掉話率指標已經穩定在0.4%上下。鎮江CS掉話率在愛立信區域排名由上圖我們可以看出，從9月份至11月中旬左右，我們鎮江聯通CS掉話率在愛立信區域排名仍然是墊底位置；經過我們持續的CS掉話率專項提升優化，目前我們鎮江聯通CS掉話率在愛立信區域已經在中游水平。鎮江CS掉話率在全省區域排名由上圖我們可以看出，從9月份至11月中旬左右，我們鎮江聯通CS掉話率在全省排名仍然是墊底位置；經過我們持續的CS掉話率專項提升優化，目前我們鎮江聯通CS掉話率在全省已經在中游水平。鎮江聯通CS掉話率專項工作內容鑒于CS掉話率指標不斷惡化，我們通過對鎮江聯通網絡現狀以及掉話特點進行分析，成立了CS掉話率提升專項。結合日常投訴、BO話統打點、GPEH分析以及日常TOP小區處理，我們總結分析了鎮江聯通掉話率原因分類占比如下圖所示：根據以上分析，現網由于鄰區問題導致掉話最嚴重，其次是覆蓋問題，擁塞導致的掉話主要集中在高鐵小區的突發話務擁塞。我們的專項主要從鄰區優化、參數優化、覆蓋提升、高鐵優化和故障推動排查五方面展開，通過一系列基礎優化，力圖先穩定住指標，繼而提升指標。鄰區核查鄰區是切換的基礎，對接入、切換、掉話有直接影響。經過我們核查發現，我們網絡鄰區配置存在很大的問題，大量的掉話由于鄰區產生，以2013年11月6日ZJRNC3晚忙時BO統計為例：由上圖可以看出，由于鄰區漏配導致的掉話占總掉話次數的50%左右，需要重點優化。我們鄰區核查的思路是根據網絡配置、話統、GPEH以及工參文件按優先級依次進行全網同頻鄰區核查、異頻鄰區核查以及異系統鄰區核查；鄰區核查主要分三種情況，一是共站非鄰小區和單向鄰區核查，二是鄰區漏配核查，三是無切換的冗余鄰區刪除。情中共站非鄰小區和單向鄰區以及鄰區漏配都會導致掉話，冗余鄰區過多會使新鄰區無法加入并且對鄰區測量產生影響，不能及時切換到較好目標小區。目前我們鄰區核查的手段主要有：根據GPEHParser解析的GPEH427鄰區漏配模塊進行進行鄰區檢查；根據網絡配置以及工參信息利用SmartRNO進行鄰區核查；服務器平臺SonMaster和NastarMV都能提供鄰區核查功能；通過BO平臺Counter進行鄰區優化。共站非鄰小區完善提取全網鄰區關系，統計共站但是未配置鄰區關系的小區和單向鄰區。共站非鄰小區的依據為經緯度相同但是無鄰區關系的小區，現網鄰區的反向關系在現網不存在則為單向鄰區，目前已完善共站非鄰和單向鄰區5062條。如：統計發現ZJSWo2117（菊花山路）基站連續多天出現在TOP小區里，提取其鄰區關系，發現其鄰區漏配嚴重，共站鄰區和近處鄰區均未配置，導致掉話嚴重，完善鄰區后掉話消失（紅色為菊花山路小區，藍色為已配鄰區）(下圖使用工具為SmartRNO)。菊花山路ZJSWo2117A1小區鄰區菊花山路ZJSWo2117B1小區鄰區鄰區漏配核查鄰區漏配核查我們可以根據GPEH文件，通過GPEHParser解析提取GPEH的427鄰區模塊進行分析。通過訂閱GPEH，GPEHParser解析的427模塊文件如下表：其中已經明確了原小區的CI和擾碼，統計出了目標小區的擾碼和信號強度，以及兩個小區直接嘗試切換的次數，我們在SmartRNO上找到目標擾碼代表的小區，根據嘗試次數和信號強度就可以來完善鄰區關系。截止目前全網已完善鄰區10015條：如：根據晚忙時GPEH數據，分析ZJJWo1507A1（句容廣電）小區與目標小區（PSC=205）鄰區漏配，二者嘗試切換1389次，且目標小區信號非常好（RSCP為-77dBm，Ec/Io為-8dB）。打開SmartRNO，找到原小區，發現目標小區距離原小區約400米，且不存在鄰區關系，需要添加鄰區。冗余鄰區刪除冗余鄰區過多會使新鄰區無法加入并且對鄰區測量產生影響，不能及時切換到較好目標小區，根據BO統計的兩兩小區切換關系，并結合拓撲關系我們進行冗余鄰區的刪除。根據BO提取出的鄰區切換表如下：截止目前，全網已刪除6483條冗余鄰區：如：在添加鄰區時，ZJSWo2113A1小區提示鄰區超過31條未能繼續添加鄰區，如下：提取該小區的7天切換表，發現有4條鄰區無切換關系，且目標小區均是正常工作狀態，可將其鄰區關系刪除。如下：周期性鄰區完善目前通過服務器平臺SonMaster，我們可以周期對全網的鄰區關系進行核查，目前SonMaster核查出的數據，我們仍是通過手動檢查后在下發修改，后期SonMaster平臺會實現鄰區的自動優化，屆時可以解放出人力以投入到其他優化工作中。參數核查根據我們的分析，我們現網掉話率主要是由于鄰區和覆蓋引起，故前期我們的CS掉話率的優化主要是以鄰區優化和覆蓋優化為主，參數優化為輔。我們參數優化主要分為參數一致性核查以及對高掉話小區分場景優化為主。參數一致性核查我們通過SmartRNO工具定期對現網RNC級以及小區級參數進行核查，并對明顯異常的參數設置進行修改。以2/3G參數一致性核查為例：WCDMA網絡覆蓋遠小于GSM網絡，在WCDMA弱覆蓋甚至無覆蓋區域必然切換到GSM網絡，因此23G參數一致性核查是一項基礎工作。工作內容就是定期核查3G側定義的異系統鄰小區的BCCH、BSIC、LAC等信息準確，才能順利切換到GSM。參數修改記錄表RNC號網元MOClass參數名稱CurrentvalueNewvalue修改原因ZJRNC03CELLExternalGsmCell=Z528Ancc05參數一致性核查ZJRNC03CELLExternalGsmCell=Z528Abcc16參數一致性核查ZJRNC06CELLExternalGsmCell=Z754Ancc24參數一致性核查ZJRNC06CELLExternalGsmCell=Z754Abcc07參數一致性核查ZJRNC07CELLExternalGsmCell=ZD4134BLAC4134641342參數一致性核查ZJRNC08CELLExternalGsmCell=ZD4134ALAC4134541341參數一致性核查ZJRNC08CELLExternalGsmCell=ZD4134BLAC4134641342參數一致性核查分場景參數優化調整針對目前網絡高掉話小區，我們分場景進行參數優化：功率控制隨著3G用戶的滲透慮的增加，話務逐步提升的情況下，需要優化相關的功率控制參數來適應網絡容量干擾的變化。ulInitSirTargetExtraHigh70ulInitSirTargetHigh70ulInitSirTargetLow30ulInitSirTargetSrb40cNbifho15sirMax1002．并發業務優化隨著智能手機滲透率的提升，并發業務的掉話占到整個網絡掉話率的75％以上。我們針對并發業務做了如下優化，限制并發業務中的數據業務速率，降低并發業務中數據部分對語音的影響。RABcombination019offRABcombination036offRABcombination038offRABcombination076off覆蓋提升覆蓋提升優化是網絡優化的基礎，我們網絡覆蓋的優化主要以路測RF優化結合MRR提升為主。經過我們持續性優化，最近兩次拉網指標如下：日期區域電平（RSCP）話質（Ec/Io)接通率（%）掉話率（%）2013年12月鎮江91.84%98.90%95.58%0%2014年01月鎮江94.91%99.04%99.90%0%RF優化以鎮江主城區為例，通過我們的拉網發現，鎮江主城區的覆蓋良好，如下圖所示：1、聯通WCDMA場強圖RSCP：2、聯通WCDMAEC/IO分布 無論從RSCP和ECIO來看，鎮江主城區覆蓋問題都不是很嚴重，但是我們將鎮江主城區的導頻污染圖打開會發現鎮江導頻污染嚴重，是影響指標的嚴重隱患： 我們看待覆蓋主要是以RSCP和ECIO為主，而只看這兩個指標很難發現網絡深層次的問題以及網絡隱患。導頻污染的優化相比于弱覆蓋的優化天饋調整工作量更大，對人員技能水平要求更高，目前我們正在持續性的優化中。如：丁卯橋路經十二路附近區域尚東國際A1小區越區覆蓋RF優化效果前后對比：丁卯橋路經十二路十字路口附近區域導頻污染丁卯橋路經十二路十字路口附近區域導頻污染 該區域尚東國際A1小區RSCP在-74dBm左右，ECIO為-9dB左右，尚東國際站點據該處2Km左右，屬于越區覆蓋。調整尚東國際A1小區電子下傾角8°->12°后，該區域尚東國際A1小區RSCP在-85dBm左右。丁卯橋路經十二路十字路口附近區域尚東國際A1小區RSCP截圖調整尚東國際A1小區電子下傾角后，該區域尚東國際A1小區RSCP在-85dBm左右，ECIO為-24dB左右，與最強小區RSCP相差20dB左右。調整丁卯大樓B1小區機械下傾角3°->6°，丁卯大樓D1小區機械下傾角6°->9°后，復測效果如下：調整后導頻污染截圖MRR覆蓋分析MRR工具可以跟蹤小區覆蓋，以小區為單位，統計一段時間內的覆蓋信號強度，時間越長越精確。以我們定義的ZJRNC03的小區為例：如上圖所示，導出MRR文件，統計所有小區的RSCP和Ec/Io值，以-90/-10為判斷值，發現ZJSWo2202C1小區的RSCP值低于-90dBm的采樣點為20889，大于-90dBm的采樣點為5348，相差15541，是為弱覆蓋。打開OSS－MRR實時跟蹤數據圖，找到UtranCellZJSWo2202C1小區，如下所示：由上圖可知，該小區的RSCP值主要分布于-91dBm～-99dBm，是為弱覆蓋。據此，我們可對該小區進行天饋調整，提升其覆蓋?？偨Y：MRR可以準確定位弱覆蓋小區，為我們發現問題節省大量時間，應成為日常使用工具。處理問題小區時，應首先查看MRR，確定其覆蓋。排除覆蓋因素后，可直接進行后臺參數優化。高鐵優化專項鎮江城市不大，但地形卻很復雜，一水橫陳，連岡三面，更有滬寧和京滬高鐵穿城而過，給我們的優化工作造成不小困難。同時京滬高鐵以及滬寧高鐵的高掉話小區對全網指標也造成了不小的影響。京滬高鐵優化鎮江RNC08掉話率一直在1%以上，主要是京滬高鐵覆蓋小區影響： 由下表可知，京滬高鐵小區對整網指標影響在0.07%左右，對RNC08指標影響在0.5%左右。 對于京滬高鐵的優化我們還是從鄰區、參數、TOP小區處理和覆蓋等基礎優化入手，根據我們的分析，京滬高鐵主要問題是覆蓋問題和擁塞問題導致；覆蓋問題的優化以天饋調整和推動建站擴容處理；而擁塞問題除了推動擴容處理外，我們發現京滬高鐵小區碼字擁塞嚴重，主要是小區越區覆蓋導致。上圖為晚忙時全網碼字擁塞情況，可以看到全網碼字擁塞小區集中在高鐵沿線。這些小區平時話務量不高，但是動車經過時截面流量特別大，容易造成擁塞。上圖是采集ZJJWo1911C1(電信南棚隧道西處H桿)瞬時資源利用率情況，圖中顯示dlCode（碼字利用率）為93.3%，ulint（上行干擾）-84.2dBm，HScnt（HSDPA用戶數）實際接入32個，允許接入32個。鎮江RNC08規模較小高鐵小區比例高，掉話率隨著高鐵小區擁塞情況而波動。如上圖，25日20點忙時擁塞2213次，系統統計到掉話原因的有28次,其中擁塞掉話24次,掉話率2.1%。因此擁塞對掉話影響很大。高鐵小區越區覆蓋統計如下：后臺分析高鐵小區propagationdelay打點,發現相當一部分高鐵小區覆蓋過遠，需要做RF優化控制覆蓋。如以下黃山掉話為例：統計高掉話小區ZJSWo1261A1（下黃山）掉話情況，擁塞掉話占比較高。DateRNCUCellIdpmNoFailedRabEstAttemptLackDlChnlCodepmNoSysRelSpeechSoHopmNoSysRelSpeechNeighbrpmNoSysRelSpeechUlSynchpmNoOfTermSpeechCongDCR(Speech)[%]20131023ZJRNC08ZJSWo1261A1119001913.19%20131025ZJRNC08ZJSWo1261A111110058.45%20131025ZJRNC08ZJSWo1261A115800048.70%后臺統計發現，高鐵小區ZJSWo1261A1（下黃山）存在高掉話。通過調整hsdpaUsersAdm、maxNumHsdpaUsers、sf16Adm、sf8Adm、dlCodeAdm、numHsPdschCodes等參數。優化碼字資源利用。同時通過后臺統計該小區的覆蓋發現該小區存在越區現象:Sector=1,Carrier=1,Prach=1pmPropagationDelay

3576,197,912,2384,25817,145033,161,239,136,76,8,128,89,30,55,101,21,9,2,3,0,31,0,1,0,60,1,1,1,0,0,0,0,0,0,10,1,0,0,0,0需要壓天線控制覆蓋在兩公里以內。通過天饋調整以及參數優化后，擁塞得到緩解，掉話率下降：通過我們的持續性優化，目前京滬高鐵鎮江段語音掉話率在3.0%以下：滬寧高鐵專項優化滬寧高鐵是專網組網，且其RNC05指標一直在2%左右波動，有時會達到3%左右。由于RNC5去年4月份轉維后，就一直沒有維護，故滬寧高鐵專網參數始終保持建網初期設置，但隨著周圍大網環境、參數的變化，部分鄰區、參數設置之間均存在問題。由上表可知，專網對大網指標影響在0.08%左右，通過對專網鄰區以及專網配置進行核查，重新修改異常配置參數以及完善外部鄰區，CS掉話指標已經得到很大提升。對于滬寧高鐵的優化我們同樣還是從鄰區、參數、TOP小區處理和覆蓋等基礎優化入手，根據我們對滬寧高鐵掉話TOP小區進行分析，發現主要掉話原因為隧道內弱覆蓋問題、過渡帶策略問題、火車站專網與大網遷移問題、鎮江專網RNC1636無法與南京RNC1540遷移問題、切換不及時問題、專網與大網同頻干擾問題導致，如下表：高掉話小區原因分析W-高家門北+電信武警中隊+林隱路隧道CHR分析發現釋放前覆蓋較差，最終由于無線流程處理失敗導致掉話；分析路測數據，由于林隱路隧道內未建設室內分布系統，隧道內覆蓋較弱，建議新建泄漏電纜增強林隱路隧道內覆蓋；W-郵政樞紐無線流程處理失敗導致掉話，釋放時覆蓋較差，鎮江火車站存在兩個問題：1.過渡帶通過宏站過渡，覆蓋無法精確控制，帶來非高鐵用戶占用專網問題，建議在火車站內新建室內分布，精確控制過渡帶；2.專網與大網遷移問題，目前已經通過優化遷移參數，CS業務可以進行遷移，有效減少了CS掉話；W-跑馬山無線流程處理失敗導致掉話，釋放時覆蓋較差，鎮江火車站存在兩個問題：1.過渡帶通過宏站過渡，覆蓋無法精確控制，帶來非高鐵用戶占用專網問題，建議在火車站內新建室內分布；2.專網與大網遷移問題，目前通過優化遷移參數，CS業務已可以進行遷移，有效減少了CS掉話；W-移動寶華河沖釋放前覆蓋較差，無線流程處理失敗導致掉話，結合路測數據分析發現正盤山隧道內覆蓋較差，建議1.處理正盤山隧道RRU故障；2.故障處理后測試隧道內覆蓋，如覆蓋依舊較弱則需要新建隧道泄漏電纜提升隧道內覆蓋；W-電信寶華胡院兩個問題導致掉話偏多：1.覆蓋偏弱：W-電信寶華胡院小區和W-移動寶華河沖小區在隧道內的覆蓋偏弱；2.W-移動寶華河沖與W-電信寶華胡院切換不及時：CHR分析存在切換不及時現象，結合路測數據發現這兩個小區的切換帶位于桐山隧道內部區域，由于進出隧道信號突變，切換和重選不及時導致未接通和掉話風險較大，目前雙向CIO已經調整值10，已無參數優化空間，建議1.解決正盤山隧道RRU故障，提升隧道內部覆蓋；2.建議將移動寶華河沖+正盤山隧道+兩隧道間+桐山隧道東4個站點6RRU合并，將切換帶延長至桐山隧道東側，避免切換不及時；W-江大繼續教育學院覆蓋原因導致掉話，掉話位置主要由于林隱路隧道弱覆蓋導致，建議1.新建泄漏電纜增強林隱路隧道內覆蓋；2.建議將高家們北RRU0、電信武警中隊RRU0、林隱路隧道RRU0、江大繼續教育學院RRU0和江大繼續教育學院RRU1進行小區合并，減少隧道內切換不及時導致的掉話；W-木材倉庫林隱路隧道弱覆蓋，建議新建泄漏電纜增強林隱路隧道內覆蓋；W-寶華移動天龍1.頻點為10713，與大網小區同頻干擾嚴重；2.鎮江RNC1636無法遷移至南京RNC1540，UE上報南京RNC1540，CI：20742和CI：NJ9603的1A事件，且由于RNC1636與RNC1540無IUR口，需要進行遷移，但在CN向RNC發送RANAP_RELOCATION_COMMAND后，RNC發起RANAP_RELOCATION_CANCEL，最終由于無線信道惡化導致掉話。進行小區跟蹤發現RANAP_RELOCATION_CANCEL原因為Iu-Transport-Connection-Failed-To-Establish（即IU傳輸連接建立失?。?，已經通過添加IPPATH解決；W-石榴園火車站1.頻點為10713，與大網小區同頻干擾嚴重；2.鎮江RNC1636無法遷移至南京RNC1540，UE上報南京RNC1540，CI：20742和CI：NJ9603的1A事件，且由于RNC1636與RNC1540無IUR口，需要進行遷移，但在CN向RNC發送RANAP_RELOCATION_COMMAND后，RNC發起RANAP_RELOCATION_CANCEL，最終由于無線信道惡化導致掉話。進行小區跟蹤發現RANAP_RELOCATION_CANCEL原因為Iu-Transport-Connection-Failed-To-Establish（即IU傳輸連接建立失?。?，已經通過添加IPPATH解決；W-釜用機械無線流程處理失敗導致掉話，釋放時覆蓋較差，該小區位于丹陽火車站周邊，火車站存在兩個問題：1.過渡帶通過宏站過渡，覆蓋無法精確控制，非高鐵用戶占用專網問題，建議在火車站內新建室內分布，精確控制過渡帶；2.專網與大網無法遷移，通過優化專網與大網遷移參數，CS業務已經可以進行遷移；W-華陽大酒店無線鏈路失敗導致掉話，弱覆蓋導致掉話，目前丹陽火車站存在兩個問題：1.過渡帶通過宏站過渡，覆蓋無法精確控制，非高鐵用戶占用專網，增加掉話風險，建議在火車站內新建室內分布；2.專網與大網無法遷移，通過優化專網與大網遷移參數，CS業務已經可以進行遷移；W-青陽空口處理失敗導致掉話，呼叫釋放前十幾秒無信令交互，分析路測數據，普善五金與電信丁家莊之間切換帶偏小，修改雙向CIO2至5，加快切換；W-寶華倉頭釋放前覆蓋較差，無線流程處理失敗導致掉話，結合路測數據分析發現正盤山隧道內覆蓋較差，建議1.處理正盤山隧道RRU故障；2.故障處理后測試隧道內覆蓋，如覆蓋依舊較弱則需要新建隧道泄漏電纜提升隧道內覆蓋；以鎮江與南京PS業務和并發業務硬切換伴隨SRNS遷移失敗導致掉話率偏高處理為例：統計晚忙指標發現發現W-寶華移動天龍(歸屬：鎮江,LAC:53620,RNC:1636,CI:30372)掉話率偏高,分析PCHR發現掉話前多次上報W_UQX龍潭4（網建）_B_1(歸屬:南京,LAC:53508,RNC:1540,CI:20742)的1A事件，在CN往RNC下發RelocationCommand消息后，CN向RNC發送RelocationCancel消息，最終由于W-寶華移動天龍Ec/Io持續惡化導致掉話。鎮江與南京RNC側均為華為設備，鎮江RNC與南京RNC之間無IUR口，目前鎮江RNC參數設置為硬切換伴隨SRNS遷移策略，判決策略如下：

硬切換遷移流程如下：首先通過告警檢查，鄰區檢查，參數檢查等基礎檢查為例，未發現問題；對W-寶華移動天龍小區進行IOS跟蹤，分析發現并發業務硬切換伴隨SRNS遷移失敗返回原因為iu-transport-connection-failed-to-establish，如下圖：通過指標分析和IOS信令跟蹤，發現在鎮江與南京邊界CS語音業務硬切換遷移基本成功，而PS和并發業務硬切換全部失敗，原因值都為iu-transport-connection-failed-to-establish，由于源RNC鎮江RNC1636與目標RNC南京RNC1540之間無IUR口，所以遷移相關的消息都需要通過SGSN來轉發。分析SGSN下發的RelocationCommand消息，其中攜帶了目標南京RNC1540的傳輸層地址：0AF2C099，轉換為十進制為：10.242.192.153。檢查源RNC的配置數據，發現沒有定義該地址的IUPSIPPATH。從硬切換遷移流程來看，第9個流程是源RNC與目標RNC之間進行交互，我們認為雖然兩個RNC之間沒有IUR接口，但通過添加目標RNC的IUPSIPPATH，可以實現邏輯上RNC之間的數據交互。該遷移失敗問題應該是與沒有配置IPPATH相關。數據側添加IPPATH，添加后的IPPATH如下圖：添加后RNC1636與RNC1540PS域可以遷移成功，PS業務和并發業務導致掉話得到有效改善，如下表：硬件故障排查為避免設備硬件故障對掉話的影響，我們對全網設備故障問題進行分類處理，并提交代維處理。華為工具對E優化貢獻GPEHparser解析功能系統Speech掉話打點除了4個counter以外,其他均可認為是other掉話。如果需要分析具體的掉話原因，需要解析GPEH日志文件獲取詳細的掉話信息。目前HUAWEI公司開發的GPEHparserversion1.0可以對W12B的GPEH進行解析，目前鎮江聯通針對網絡優化比較關鍵的427和438模塊進掉話原因的分析和同頻鄰區的優化工作。步驟如下：1:定制并提取相關時段的GPEH日志，放在Input文件夾中。2:運行run_W12.bat。3:運行輸出轉換宏輸出掉話事件相關的信息。分析出來的掉話原因如下：如果需要更清楚的定位問題，需要在GPEHParser的統計信息上使用Decoder來解析詳細信令-原始文件解析在cygwin環境下運行如下命令:decoder/decoder.pl--force--w12b--gpeh*.bin|teexxx.txt實現GPEH原始的二進制文件轉換為文本文件轉換完成后同樣在cygwin環境下運行如下命令:catxxx.txt|decoder/decoder.pl--w12b|decoder/flow.pl|teecallflow-xxx.log在UltraEdit中打開callflow-xxx.log文件，根據GPEHPaser中的掉話事件相關的信息找到掉話點。根據掉話的UeCt來過濾本次掉話的相信信令流程。NASTAR網優功能NASTAR是HUAWEI公司開發成熟的性能優化平臺，基于MR和CHR有基礎網絡優化、地理化顯示、終端分析、用戶關懷四個模塊，從而達到提高網絡性能，提升用戶感知的目的。目前HUAWEI公司針對愛立信的數據格式，開發支持愛立信網絡地理化顯示和鄰區優化模塊。本預計1月份來鎮江驗證但是由于需要部署服務器目前還未發揮NASTAR的網絡優化功能。iManagerMaster智能網優實現iManagerMaster是HUAWEI公司開發以實現智能網優為目的的網絡性能優化軟件。主要功能有有多運營商的鄰區優化，容量覆蓋優化，移動魯棒性優化，負載均衡優化，擾碼沖突檢測與自優化等?；贛R（GPEH）的鄰區優化功能，對于網絡的日常運維，網絡的新建、搬遷、擴容，都可以做到無需人工干預，快速自動完成鄰區關系的優化，包括自動增加漏配鄰區，自動刪除冗余鄰區，自動調整鄰區優先級等。并可以實現了策略設置、直觀呈現和自動回退等功能，比如策略設置，提供了黑白名單精細化控制，下方方式可以選擇自動人