1、TD-LTE網絡優化指導書掉話優化責任部門：審核： 批準： 2013 -08發布 2013 -09實施 大唐移動通信設備有限公司 發 布目錄1引言32基礎知識32.1“連接”與“掉話”的概念32.2正常的連接釋放42.3異常的連接釋放（掉話）53DT/CQT常見掉話原因分析73.1弱覆蓋73.2切換失敗93.3鄰區漏配103.4越區覆蓋123.5系統設備異常143.6干擾153.7擁塞174話務統計掉話數據分析184.1掉話相關的KPI184.2全局掉話率偏高問題分析（Top N）184.3小區（簇）掉話率偏高問題分析195掉話問題的分析流程206典型掉話案例分析226.1弱覆蓋導致的掉話22

2、6.2切換失敗導致的掉話226.3鄰區漏配導致的掉話231引言編寫本文的目的：1.整理了與TD-LTE系統中與保持性（掉話）相關的基本概念、信令流程、所涉及的參數。2.指導TD-LTE網絡維護、優化過程中，與掉話相關的問題分析和定位（解決）。2基礎知識& 知識點：1、 掉話的定義2、 掉話后UE、eNodeB的操作2.1“連接”與“掉話”的概念本文所提及的“保持性”，指的是“連接”的“保持性”，更狹義地，是指“RRC連接”的“保持性”。因此，本文所稱的“掉話”，具體是指UE異常退出RRC_CONNECTED狀態導致的連接中斷。圖 01 NAS和AS的幾種狀態上圖給出了從開機到進入激活（

3、數據傳輸）狀態過程中，從不同角度來看的“狀態”的變化情況。從EPS移動性管理（EMM）的角度來看，在UE成功附著之前，都認為是未登記（Deregistered）狀態，直至UE發起、并成功登記。對于EPS連接管理（ECM）來說，只有在激活態時，UE才會跟EPS是連接的，其余時間，UE處于和EPS的空閑狀態。對于RRC來說，只要UE和網絡側（空口、EPS）有連接，即為RRC的連接狀態。從ECM_Idle態轉到ECM_Connected態，不僅涉及RRC連接建立、還涉及到S1連接建立。RRC連接的建立由NAS發起、并先于S1連接建立完成。RRC_Connected態的連接僅限于UE和E-UTRAN的

4、控制信息的交互。RRC連接的釋放由eNB發起、緊隨S1連接釋放之后。本文所稱的“連接”，通常指的是RRC_Connected狀態下的連接。因受目前理解能力和OMC統計數據分析能力的限制，本文暫時只考慮上圖中RRC_Connected狀態（激活態）、暫不考慮附著過程中的連接狀態。通常將在附著過程中發生的RRC連接中斷歸為“接入失敗”進行分析；本文所分析的“掉話”、僅限于RRC_Connected狀態下的連接異常中斷。& 知識點：掉話的定義本文所稱的“掉話”，具體是指UE異常退出RRC_CONNECTED狀態導致的連接中斷。2.2正常的連接釋放在了解“掉話”之前，需要先了解正常的“通話結束

5、”（即“連接釋放”）的過程。RRC連接釋放流程如下圖所示（見36.331協議的5.3.8小節RRC Connection Release）。圖 02 RRC連接釋放（正常）UE在接收到RRCConnectionRelease之后，應該：1、 從收到RRCConnectionRelease（或者下層指示收到RRCConnectionRelease消息）起，將下列操作延遲60ms；2、 如果RRCConnectionRelease消息中包含idleModeMobilityControlInfo，存儲其中的小區重選優先級信息；如果消息中包含t320，啟動該T320定時器（并將定時器取值為t320）；

6、如果沒有包含idleModeMobilityControlInfo，UE使用系統信息中廣播的小區重選優先級信息。3、 如果RRCConnectionRelease消息中的releaseCause為loadBalancingTAURequired，UE將在離開RRC_CONNECTED時執行操作，并帶上releaseCause為loadBalancingTAURequired；如果releaseCause為other，則在離開RRC_CONNECTED時執行操作，并帶上releaseCause為other。UE在離開RRC_CONNECTED時執行的操作：1、 重置MAC；2、 停止除T320以

7、外的所有定時器；3、 釋放全部無線資源，包括釋放全部已建立的RB的RLC實體、MAC配置和相關的PDCP實體；4、 告訴上層RRC連接釋放（帶上releaseCause）；5、 如果不是由于收到MobilityFromEUTRACommand消息而觸發的離開RRC_CONNECTED狀態，UE將（根據離開RRC_CONNECTED的原因）通過執行小區重選過程進入RRC_IDLE，具體見TS36.3044.通常情況下，以下情形會觸發EUTRAN下發RRCConnectionRelease消息：1、 UE發起Detach之后；2、 TAU之后3、 核心網觸發loadBalancingTAURequ

8、ired之后2.3異常的連接釋放（掉話）結合常見的掉話類型，從信令上來看，有以下幾種體現：1、 重建立失敗導致的掉話：信令上可以看到：圖 03 常見掉話的信令表現（1）重建立失敗導致的掉話1) 首先是UE在UL-CCCH上發送“rrcConnectionReestablishmentRequest; Cause = otherFailure”；2) 接著eNB在DL-CCCH上回復“rrcConnectionReestablishmentReject”；3) 隨后UE發生掉話、開始接收系統廣播消息（在BCCH-SCH上的SIB1）、直至UE發起下一次呼叫。2、 空口信號變差等原因導致的掉話：只

9、能看到信令不完整UE在沒有收到Release消息的情況下，直接從RRC-CONNECTED狀態轉到RRC-IDLE。此類掉話的一個典型表象為：UE發起了RRCConnectionReestablishmentRequest、但是沒有收到eNodeB發來的RRCConnectionReestablishment，而且 UE也沒有發出RRCConnectionReestablishmentComplete消息。圖 04 常見掉話的信令表現（2）空口信號變差等原因導致的掉話3、 狹義上來講，可以認為“只要UE發起了RRC重建立，就意味著RRC連接已斷、即產生了掉話”。在實際項目中，還會碰到這種情況：

10、由于切換失敗或其他原因導致的RRC連接重建立，而這種RRC連接重建立往往是成功的。因此，在項目運作的時候，這種RRC重建立是否算作掉話，需要特別關注、在必要時需要和客戶達成一致意見。圖 05 常見掉話的信令表現（3）其他原因導致的RRC重建立 注意: 項目執行過程中，需要明確“掉話”的具體定義在實際項目中，通常需要與客戶就掉話的定義達成共識。考慮到實際用戶的應用是以數據業務為主，因此項目組與客戶協商、達成共識：只要重建立時間在100ms之內（即從UE發起RRCConnectionReestablishmentRequest，到UE回復RRCConnectionReestablishmentCo

11、mplete的時間間隔小于100ms），都不計入掉話。（注：這僅僅是統計方法上的定義）3DT/CQT常見掉話原因分析3.1弱覆蓋現象由于弱覆蓋導致的掉話，通常有以下表現：1.掉話前服務小區的RSRP持續變差（低于弱覆蓋標準，如：小于-105dBm）、同時服務小區的SINR也一起持續變差（小于-5dB，甚至更低）；2.掉話后可能會有一段時間（數秒至數分鐘不等，取決于實際網絡覆蓋情況），UE無數據上報（類似于UE脫網）。圖 01 弱覆蓋導致的掉話示意圖分析方法采用路測數據分析法。步驟1、采集到相關路測數據，用路測數據分析軟件OUTUM進行分析；步驟2、定位到掉話時間點的數據，通過查看地理化顯示的圖

12、層（服務小區RSRP、SINR）確認以下特征：（1）掉話時，UE測得的服務小區RSRP低（如：< -105dBm）；（2）掉話時，UE測得的服務小區SINR低（如：< 0dB）（3）掉話時，UE沒有測到（上報）其他（如：強度 > -105dBm的）鄰區信號。解決方案總的來說，要解決此類掉話，需要改善覆蓋，具體的操作步驟和手段有：1.首先明確當前的弱覆蓋區域由哪些扇區的信號覆蓋；2.根據網絡拓撲結構和相關無線環境來確定最適合覆蓋該區域的扇區、并加強它的覆蓋：（1）排除主覆蓋小區的硬件故障（例如：基帶及射頻器件故障、天饋系統駐波比告警等）（2）上調主覆蓋小區的RS功率（3）上調主

13、覆蓋扇區的功率（4）調整主覆蓋扇區的天線下傾角（5）調整住覆蓋扇區的天線方位角（6）建議加站（并調整周邊基站天線的方位角和下傾角）3.開啟SON-CCO（Coverage & Capacity Optimization）功能（待實現）3.2切換失敗現象由于切換失敗導致的掉話，通常有以下表現：1.首先，在掉話前UE曾發出Measurement Report、并能收到eNB發來的RRCConnectionReconfiguration；2.但是UE收取目標小區的廣播消息之后、立即上報“RRC連接重建立請求”（rrcConnectionReestablishmentRequest; Caus

14、e = handoverFailure）；3.通常UE在切換失敗后，都會發起回到源小區的“RRC連接重建立請求” 、并且此類RRC連接重建立成功率大部分都是成功的、此類重建立通常也會在100ms內完成。圖 02 信令（由于切換失敗導致的掉話）分析方法采用信令分析法。步驟1、獲取采集到的掉話數據，使用路測數據分析軟件OUTUM進行分析；步驟2、打開路測數據的信令，定位到掉話時間點，確認以下幾個特征：（1）掉話前UE曾發起Measurement Report消息；（2）UE能夠收到eNB發來的帶有MobilityControlInfo內容的“RRC連接重配置”消息（3）UE切換到“RRC連接重配置

15、”消息所帶的目標小區后、在該小區的BCCH-SCH上接收到廣播消息（systemInformationBlockType1）；（4）UE收完廣播消息后、發起“RRC連接重建立（原因為切換失敗）”；（5）通常UE能夠在較短時間（200ms）內重建立成功、回到切換前的源小區。步驟3、進一步分析以下內容：（1）明確MR消息和RRC連接重配置消息中所提及的目標小區的PCI，確認該PCI所指小區；（2）分析UE在新的目標小區接收到的廣播消息，確認該小區是否就是MR消息上報的小區，用以排除鄰區錯配的情況；（3）在OMC中確認鄰區配置,檢查鄰區參數是否正確；（4）確認OMC中的切換類型（X2、S1）；（5）

16、確認目標小區的工作狀態（小區的功率輸出、小區負荷）、排除由于目標小區工作異常導致的切換失敗；（6）確認源小區和目標小區的切換參數（門限、TTT和遲滯等）配置與其他正常小區的相同。步驟4、如果上述分析無法得到明確結論，需要進一步確認該小區的切換成功率，如果該目標小區的切換成功率偏低，初步定為為基站故障（或者系統版本問題），需要進一步將問題反饋給后方技術支持。解決方案總的來說，解決此類掉話有以下方法：1.檢查源小區的鄰區配置情況，確認鄰區參數配置正確；2.確認目標小區的工作狀態正常（包括傳輸無誤碼、功率輸出正常、小區負荷不會導致拒絕切入）3.確認源小區和目標小區的軟件版本是否正確；4.了解切換失敗

17、的規律（是否配置了X2？是否集中在某個小區、該小區的切換成功率是否低？周邊是否有新開站點？是否處于不同的MME邊緣？是否處于不同頻率的基站交界處？）當無法定位問題時，需要總結規律、將歸納后的信息反饋給后方技術支持、以便提交系統開發人員作問題的最終定位。3.3鄰區漏配現象由于鄰區漏配導致的掉話，通常有以下現象：1.掉話前、后的下行覆蓋不差（通常大于-105dBm）；2.掉話前、后服務小區的SINR變差（因為受到鄰區信號的干擾）；3.（關鍵點）掉話前UE（可能會多次）上報測量報告（MR）、并且MR中上報的PCI，并沒有配置在當前服務小區的鄰區列表之中；4.掉話后UE通常會發起小區重選、并重選到一個

18、新的小區。圖 03 鄰區漏配導致的掉話示意圖分析方法采用信令分析法。步驟1、獲取采集到的掉話數據，使用路測數據分析軟件OUTUM進行分析；步驟2、打開路測數據的信令，定位到掉話時間點，確認以下幾個特征：（1）掉話前服務小區的RSRP 持續下降；（2）掉話前，UE（連續）上報MR消息；（目的是：確認鄰區信號足夠強、是由于鄰區漏配導致的服務小區信號變差、最終導致掉話）（3）MR消息中UE上報有符合A3（或者A5，取決于系統設置）事件的目標鄰區；（4）在當前服務小區下發的系統（鄰區）消息中，并沒有包含MR消息中UE上報的目標鄰區；（5）UE上報MR后，沒有收到eNB發來的用于指示切換的重配置消息。步

19、驟3、通過基站信息表（或者OMC導出的基站配置表）確認掉話時的主服務小區、MR消息中上報的不在鄰區中的PCI歸屬（即目標小區）；步驟4、在掉話前的服務小區的鄰區列表中添加相應的目標鄰區。解決方案通過OMC（可以使用界面提供的配置工具、或者批量導入功能），在掉話前的服務小區列表中，添加漏配的鄰區。開啟ANR功能，完善鄰區配置。（待驗證）3.4越區覆蓋現象在支持切換的移動通信網絡中，由于無法精確控制無線信號的傳播，因此或多或少都會存在越區覆蓋的情況。而由于越區覆蓋導致的掉話，通常表現為：1.越區覆蓋導致“導頻污染”：由于越區覆蓋的信號較多，導致在某些區域形成“導頻污染”在覆蓋區內，沒有穩定的強信號

20、作為主服務小區。服務小區信號的頻繁變化，是導致掉話的一個主要原因。2.越區覆蓋對主服務小區的干擾（包括鄰區漏配、越區信號的迅速變化等）：在某些區域，主服務小區受到越區信號的干擾、最終導致掉話。一方面是由于越區信號的出現，超出了網絡規劃設計的預期，初始設計的鄰區列表沒有加上越區覆蓋的小區；另一方面，在某些區域，越區覆蓋的小區信號并不穩定，即使配置了鄰區，也可能會出現由于越區信號的不穩定而無法及時加入鄰區的情況。圖 04 越區覆蓋造成導頻污染、并導致掉話示意圖分析方法路測數據分析法。步驟1、獲取采集到的掉話數據，使用路測數據分析軟件OUTUM進行分析；步驟2、打開路測數據的信令，定位到掉話時間點，

21、確認以下特征：（1）發生掉話的區域，服務小區或者搜索到的鄰區信號中有越區覆蓋信號（跨越3“層”或以上的小區）（2）判定掉話區域是否為“導頻污染區”（覆蓋該區域、RSRP > -110dBm 的小區個數超過3個，通常信號的SINR < 0dB）（3）判定是否存在鄰區漏配：檢查覆蓋該區域的小區鄰區列表、是否包含了越區覆蓋的小區步驟3、確認了存在越區覆蓋、以及越區覆蓋的具體影響之后，進一步明確覆蓋掉話區域的主服務小區、并通過RF優化、鄰區優化等手段，控制越區覆蓋信號。解決方案1.越區覆蓋的一般優化原則是：在區域中已有合理的穩定信號覆蓋的情況下、盡可能地控制越區覆蓋的信號：（1）下調越區覆

22、蓋信號的功率（2）增加越區覆蓋扇區的天線下傾角（3）在考慮了越區覆蓋扇區周邊的覆蓋情況、以及網絡拓撲結構的情況下，謹慎地調整越區覆蓋扇區的天線方位角2.如果越區覆蓋導致了導頻污染，根據網絡拓撲結構和相關無線環境來確定最適合覆蓋該區域的扇區、并加強它的覆蓋：（1）上調主覆蓋扇區的功率（2）調整主覆蓋扇區的天線下傾角（3）調整主覆蓋扇區的天線方位角（4）控制其他污染信號對該地區的覆蓋3.如果越區覆蓋未導致導頻污染、只是由于鄰區漏配而導致掉話，則只需要在掉話區域相關小區的鄰區列表中添加越區覆蓋小區即可。3.5系統設備異常現象此類問題的表象不一，總的來說，在確認系統的功率、切換、業務相關參數無誤、并排

23、除了無線環境（信號）的影響之后，掉話問題依舊存在，這時可以將問題考慮為系統設備（可能是硬件或軟件）異常。1.切換流程異常（在切換區、無法正常完成切換、而導致掉話）2.在業務進行到相對固定的一段時間內、發生掉話（并且可復現）3.在特定某（幾）個扇區、eNodeB下，發生可復現的掉話4.跨MME、或者跨TA等，在特殊區域進行業務時，發生可復現的掉話分析方法路測數據和OMC統計數據結合分析法。步驟1、采集掉話區域的路測數據和OMC性能統計數據；步驟2、分析發生掉話前后的數據，包括：（1）當時的無線環境（可借助Google Earth來查看）（確定不是由于建筑物阻擋、拐角等環境因素導致的弱覆蓋、快衰落

24、、陰影衰落等）（2）當時主服務小區和鄰區的RSRP、SINR（確認當時的信號覆蓋情況）（3）鄰區配置情況（確認鄰區都已配置）（4）小區對的切換、掉話次數統計（確認該扇區的切換是否都失敗、掉話率是否偏高）（5）掉話時，業務停留在什么地方（例如：在切換過程中掉話、需要確認切換流程進行到哪個步驟了）步驟3、排除掉話原因（無線環境、無線弱覆蓋和導頻污染、鄰區漏配等）之后，需要進一步查找掉話的規律性，包括查看：（1）掉話是否集中在某（幾）個有規律（新開站點、跨MME的邊界站點等特征）的扇區、eNodeB？（2）掉話是否集中在某種類型的切換上（例如經由X2口的切換）？（3）掉話是否在某次版本升級之后？解決

25、方案問題原因定位為系統設備異常之后，需要將問題轉交系統開發工程師、并配合抓取進一步分析問題所需的數據、跟蹤問題的進展并最終驗證該問題得到妥善解決。3.6干擾現象根據干擾的來源、種類、工作頻段等特性，我們可以將干擾分為：（1）外部干擾、內部干擾（2）帶外干擾、帶內干擾（3）窄帶干擾、寬帶干擾（4）長時干擾、瞬時干擾（5）上行干擾、下行干擾由于干擾分類依據較多，為了便于識別，本文著重從上、下行干擾的角度進行分析。系統中存在干擾，會有以下表象：1.上行干擾：當只有上行鏈路受到干擾的時候，可能下行鏈路并無異常表現；當上行鏈路受到干擾的時候，UE的發射功率通常較高（接近UE最大發射功率）、而且基站側測得

26、的RSSI偏高2.下行干擾：當只有下行鏈路受到干擾時，可能上行鏈路并無異常表現；當下行鏈路受到干擾的時候，UE測得的RSRP較好、但是SINR偏差。圖 05 上行干擾導致掉話示意圖圖 06 下行干擾導致掉話示意圖分析方法路測數據+OMC動態數據分析法。步驟1、采集掉話時的路測數據、后臺動態觀察（RSSI）數據。步驟2、判斷掉話時的數據特征：（1）基站側測得的RSSI是否偏高（如：-85dBm以上），如果偏高，說明存在上行干擾；（2）如果掉話前（幾秒內）UE發射功率維持在較高水平（> 20dBm）、而此時并非弱覆蓋區域，則說明存在上行干擾；（3）如果UE測得的服務小區（甚至包括鄰區）的RS

27、RP較好（-90dBm甚至更好）、而此時的SINR較差（< 0dB），則說明此時可能存在下行干擾。步驟3、定位了干擾的大致類型，采取相應的解決辦法進行處理。解決方案1.對于上行干擾的進一步確認和排查：（1）明確干擾所涉及的范圍（看路測數據、或者OMC上報的RSSI，明確有哪些小區存在此類現象、查看這些小區是否成片分布）、大致定位干擾區域（2）使用頻譜掃描儀（如YBT250等）+八木天線進行掃頻、以便進一步定位干擾源2.對于下行干擾的進一步確認和排查：（1）首先確認下行干擾并非系統內部干擾（需要排除越區覆蓋、鄰區漏配導致的“干擾”現象）（2）明確了是干擾源來自系統外，需要進一步使用頻譜掃描

28、儀+八木天線進行掃頻、以定位具體的干擾源。3.當確認存在有干擾的情況時，可以采取以下方法進行清除或規避：（1）確認干擾源、請客戶幫忙協調清除干擾源（2）如果干擾來自其他系統，需要增加我方和其他系統的天線隔離度（水平隔離、垂直隔離度）、或者在干擾源上加裝信號屏蔽裝置防止信號泄漏帶來的干擾（3）變更我方系統的工作頻點或者帶寬、避開干擾（4）開啟ICIC功能、并優化相關參數（待驗證）3.7擁塞現象當系統資源不足、而用戶數較多時，容易出現擁塞，現象包括：1.小區實時激活用戶數較多2.小區開始出現接納拒絕3.小區的發射功率接近飽和4.小區的呼叫建立成功率、掉話率指標惡化分析方法OMC性能統計數據分析法。

29、步驟1、采集忙時OMC性能統計數據（包括呼叫、切換和釋放數據）；步驟2、查看掉話時小區的用戶數、話務量等情況，確認小區處于高負荷狀態；步驟3、查看小區的呼叫建立成功率、切換成功率和掉話率、以及相應的失敗原因；步驟4、當出現由于小區資源不足而導致接納拒絕的情況時，可以判定為系統出現擁塞。解決方案解決擁塞的方法，從兩個大方面入手：1.增加系統容量（1）增加小區功率容量（2）壓縮開銷信道的功率、RB資源（3）功率控制（分配）相關參數的優化（4）增加基站、扇區、頻點（帶寬）2.改變網絡拓撲結構、均衡話務負荷（1）對于出現功率過載的小區，可以考慮適當收縮覆蓋（增大天線下傾角、減小扇區發射功率），使得基站

30、只服務距離較近的用戶、減小單用戶下行功率開支（2）改善話務熱點的拓撲結構（調整扇區天線方位角），3.開啟SON-CCO功能、及優化相關參數（待實現）4話務統計掉話數據分析4.1掉話相關的KPI1.RRC連接異常掉話率= RRC連接異常釋放次數 / RRC連接建立成功率次數X 100%2.E-RAB掉話率= E-RAB異常釋放次數 / E-RAB建立成功次數X 100%3.E-RAB掉話率（按QCI統計）= E-RAB異常釋放次數（按QCI統計，QCI 1-9） / E-RAB建立成功次數（按QCI統計，QCI 1-9） X 100%4.激活E-RAB掉話率= 激活E-RAB異常釋放次數 / E

31、-RAB建立成功次數X 100%4.2全局掉話率偏高問題分析（Top N）現象全局（整網）掉話率偏高，通常會在網絡建設初期、或者網絡重大操作（割接、拆分、升級）期間出現，表現如下：1.全局（大面積基站、小區）掉話率偏高2.往往會伴隨全局（大面積基站、小區）的切換成功率和呼叫建立成功率偏低分析方法全局掉話率指標偏高的問題定位，通常可以通過OMC統計指標來找到一些規律，可能的原因有：1.全網覆蓋受限、或者存在大量越區覆蓋的情況2.全網鄰區漏配、錯配情況嚴重3.全網切換參數（包括切換門限、遲滯、TTT、層三濾波系數等）配置有誤4.X2口配置有誤（X2口切換失敗率偏高）5.系統中存在干擾6.與其他設備

32、商的業務區交界7.系統版本有故障8.某些時段用戶數少、OMC性能數據不具備統計意義在具體分析的時候，通常采取OMC性能統計數據分析法。步驟1、采集OMC在一段時間（含系統忙時）內的切換、掉話、呼叫統計數據；步驟、分析系統忙時的掉話率指標、找出掉話率排名TopN的小區；步驟3、將掉話率Top N小區進行分簇，按照本小節、0小節的內容進行分析。解決方案針對上述不同原因，采取相應的解決辦法：1.覆蓋相關：具體優化手段見0、0小節。2.鄰區及切換參數相關：具體優化手段見0、0小節。3.系統相關：具體優化手段見0小節。4.干擾相關；具體優化手段見0小節。5.如果是存在與其他設備商的業務區有交界的情況，可

33、以考慮控制覆蓋、規避干擾的辦法，具體優化手段見0、0小節。4.3小區（簇）掉話率偏高問題分析現象在一個成熟、穩定的網絡中，通常不再出現全局大面積掉話率偏高的情況，只有個別（簇）扇區、基站的掉話率偏高（Top N小區），表現為：1.個別扇區、基站（簇）掉話率偏高2.問題基站與周邊基站的切換成功率偏低（往往表現為單向切換成功率偏低）分析方法OMC性能統計數據分析法。除了第3章、以及0小節提到掉話原因，具體到小區（簇）掉話分析時，還需要查看Top N小區（基站）的以下特征（的規律性）：1.掉話率偏高的小區（基站）是否新開站點？或該小區（基站）周邊有新開站點？（需要檢查該站及周邊站點的鄰區、切換參數）2.掉話率偏高的基站工作是否正常？（有無告警、功率輸出是否正常、基站運行的軟件版本是否正確？）3.掉話率偏高的扇區，天饋系統是否正常？（天線有無接反？有無駐波比告警？天線的增益、方位角和俯仰角是否與