EFLAG濟南TD項目組外場未接通事件處理經驗總結濟南移動TD網絡Sniper225LYL2010-11-29如何處理好平時路測中的未接通問題，是我們日常優化中一直關注的重點，本文將就濟南TD網絡外場日常優化、測試過程中遇到的各類典型未接通案例進行分析歸類，并總結相應的優化經驗和手段目 錄概 述2一、未接通基本分析21導致未接通事件的原因分類22未接通事件分析流程簡述33不同類型未接通基本描述及分析3二、典型案例81覆蓋問題導致的未接通82干擾導致的未接通123參數問題導致的未接通154終端/軟件問題導致的未接通185站點/核心網問題導致的未接通286位置區規劃不合理33三、經驗總結38概 述在日常的外場DT中，我們經常會遇到各種原因導致的未接通事件，而接通率不但與集團考核成績息息相關，與用戶實際使用感受也有密切的關系，因此如何處理好平時路測中的未接通問題，是我們日常優化中一直關注的重點，本文將就濟南TD網絡日常優化過程中遇到的各類典型未接通案例進行分析歸類，并總結相應的優化經驗和手段。一、 未接通基本分析1 導致未接通事件的原因分類目前我們在測試中經常遇到各種不同原因導致的未接通事件，我們根據原因的種類對未接通事件做了簡單的分類如下：（1） 覆蓋問題導致的未接通；（2） 干擾導致的未接通；（3） 參數問題導致的未接通；（4） 終端/軟件問題導致的未接通；（5） 站點/核心網問題導致的未接通；（6） 位置區規劃不合理；（7） 容量問題導致的未接通；以上是我們平時在日常拉網測試、CQT測試時遇到未接通事件的主要原因，但在實際分析過程中，我們會發現每種原因之間均存在不同程度的聯系，以覆蓋問題為例，在覆蓋重疊較為嚴重的區域容易形成到頻污染，而到頻污染區域的干擾通常會比較嚴重；又比如參數問題，當相鄰小區的功率或者重選參數配置不合理時，在未接通事件點表象上會體現出較為嚴重的干擾或者弱覆蓋（重選參數設置不合理，導致UE拖死），因此我們在實際的分析處理過程中應當充分利用所有信息，包括各種無線信號質量測量值、前臺測試軟件信令、后臺CT、小區后臺各類指標等，通過對各種信息的綜合考量得出最準確的判斷，并指定最高效的優化方案。2 未接通事件分析流程簡述我們通過平時對各類未接通事件的處理，積累了大量的分析優化經驗，特別是當拿到一個未接通事件時，從何著手進行分析，如何利用測試數據提供的信息，后臺指標又可以提供哪些判斷依據等，我們總結了基本的分析判斷流程主要分為4步，其中多數未接通事件通過前兩步的工作即可得到結果，但對于現象較為異常的事件，我們還需要進行隨后的兩步工作，以前后臺結合，無線參數測量值與信令分析、參數檢查相配合等綜合手段進行分析判斷，并最終的出準確的事件原因與高效合理的優化方案，具體流程如下：3 不同類型未接通基本描述及分析對于各種不同類型的未接通問題，我們在上文已經提到其之間大多存在著關聯，并且通常情況下一個未接通事件的發生是由多個原因共同作用所導致的，因此我們在對每種未接通現象進行描述時，大家需要聯系其他類型的原因及優化方案綜合分析。（1） 覆蓋問題導致的未接通； 弱覆蓋導致的未接通，在現象上主要表現為無線信號質量主要是PCCPCH RSCP值較低，并且在鄰區表中也沒有PCCPCH RSCP值更好的小區，此時UE_Txpower通常也會升高。對于這種現象我們首先應該查看服務小區是否存在越區孤島、以及鄰區漏配情況，如果沒有才能說這是弱覆蓋區域，由于覆蓋是保證網絡服務的基礎能力，所以添加新站點事解決此類未接通的最有效方案，但往往由于周期較長因此我們處理提出新站需求外，還要對附近的小區進行功率的抬升，或者天線方位角、方向角的調整。另外一種手段是增加小區FPACH信道、PRACH信道的發射功率，以及上/下行干擾余量，從功率的角度對問題進行優化。 重疊覆蓋導致的未接通，通常情況下在重疊覆蓋而沒有主導小區進行覆蓋的區域，會發生頻繁的重選，在位置區邊界則會造成頻繁的位置區更新，導致被叫收到尋呼消息的概率大大下降，對于這種情況我們主要通過控制覆蓋，使問題區域由一個較強的主導小區單獨進行覆蓋，主要采用天線調整的手段進行整改，另外可以有條件的結合重選、功率參數等，也可以使終端在重疊區域穩定占用某個小區。 越區覆蓋導致的未接通，其在現象上與弱覆蓋問題產生的事件較為相似都表現為服務小區及鄰區表小區PCCPCH RSCP值較低，但最主要的區別在于，越區覆蓋的小區其鄰區表中的各個小區均距離問題路段較遠，且距離問題路段較近的小區沒有出現在鄰區列表中（如使用DX188手機進行測試，則直接可以通過鄰區表判斷是否存在鄰區漏配，因為該型號手機有鄰區測量功能，即使與周邊小區沒有配置鄰區關系仍然可以進行測量），而弱覆蓋區域中我們可以發現，即使覆蓋問題路段的小區均出現在鄰區表中，但其PCCPCH RSCP值都很低。解決越區覆蓋的有效手段即對天線下傾角進行優化，當遇到天線調整困難時，比如：美化天線、上不了天面等，我們還可以臨時采取功率調整的手段進行覆蓋控制，另外還要對其鄰區配置做合理添加，盡量避免在覆蓋沒有得到完全控制前出現孤島的概率。（2） 干擾導致的未接通 UP干擾導致的未接通，當UP時隙存在干擾時會導致終端的RRC連接成功率嚴重下降， 從發生接入困難，UP時隙的干擾理論上均是來自其他小區的DWPCH信道的上下行時隙交叉干擾，導致這種干擾的主要原因是由于遠處小區的DWPCH信道由于傳輸時延落在了問題小區的UPPCH信道上，另外當某小區存在故障時，也可能會導致其周邊小區的UP干擾集體上升。通常解決UP干擾的方法是修改UP偏移，在默認設置下，可以將UP偏移由目前的POS16修改為POS53，這樣就可以將UPPCH信道落在TS1的末端，同時我們需要修改PRACH信道及SICH信道的配置，在UpPCH移到TS1或TS2 上之前，必須把PRACH信道和HS-SICH信道先移到TS2或TS3上，因為PRACH信道、SICH信道與UPPCH信道不能共時隙。當我們檢查各個POS位的干擾時，如果發現TS1由于干擾過高已經不能滿足優化效果時，可以嘗試修改頻點或者進一步做UP偏移至70。 同頻干擾導致的未接通，由于與RRC過程相關的FPACH信道、PCH信道、FACH信道均配置在主頻點的TS0，因此當測試結果反映服務小區PCCPCH RSCP值較高而PCCPCH C/I較差時，其接通率通常會有比較明顯的下降。另外當RRC連接建立后，終端會根據網絡側的相關判決占用主載波/輔載波的DPCH信道進行RB建立及其它直傳消息，此時如果出現較為嚴重的干擾會導致DPCH C/I惡化，這也會使接通率降低。針對以上兩種問題我們最常用的手段是嚴格按照頻點規劃方案，修改服務小區或者干擾小區的頻點、擾碼，以減輕或避免干擾。 上行干擾導致的未接通，當存在上行干擾時，從測試軟件中我們會發現UE_Txpower值會抬升，而上行干擾源除了網內其它用戶終端外，外部干擾源也會造成非常強的上行干擾，著點可以通過后臺指標提取并結合實際區域周圍的建筑物場所進行判斷，通常存在上行干擾的區域，周邊小區的所有上行時隙均會有較高的干擾電平，并且會存在一定的時間規律，在特定的時間段里周邊小區的KPI指標均會較平時有較大幅度的下降，而且這樣的區域多集中在考場、黨政機關駐地等（濟南市區內各類軍事駐地和辦公場所眾多，容易發生上行干擾）。對于上行干擾導致的未接通，如果是個別小區存在我們可以嘗試修改頻點或擾碼，而對于外部干擾源，則應該當盡量掌握其規律，在測試路線的選取或測試路過時采取合理的規避手段。（3） 參數問題導致的未接通； 重選參數設置不合理導致未接通，重選參數設置不合理會導致UE在非最優小區發起呼叫，在嚴重時甚至會發生終端遲遲不重選而造成孤島假象，最終以終端拖死起呼失敗而告終，另外在位置區邊界區域由于為了避免終端頻繁的進行跨LAC區重選，在部分場景情況下我們會特別設置小區的重選參數，但在制定修改方案時要周全考慮到終端要在兩個小區間雙向進行重選的問題，而不能只顧及其中一側。 鄰區漏配導致的未接通，從現象上來看與前面提到的越區孤島、弱覆蓋均有相似之處，當使用聯芯8142/8130進行測試時，如果出現終端PCCPCH RSCP值降低，并且在鄰區表中沒有較好小區時，應該首先排查的就是是否存在鄰區漏配，我們可以通過對基站數據庫及站點地理位置分布圖相結合，查看終端在未接通點時其鄰區表中的是否有更合理的小區沒有出現，并可以通過后臺或者系統消息11來檢查鄰區關系是否配置。當發現鄰區關系漏配后應當立即補全。 2/3G參數設置不合理導致的未接通，對于部分場景我們可能會由于種種原因對2/3G參數進行相關的調整，使終端重選/切換至2G側的條件降低，重選/切換至2G側的概率與次數大大增加，但相應的2G側對3G側的重選參數沒有進行相對應的調整，使得部分區域存在較頻繁2/3G重選，而重選后進行的位置區更新使被叫UE被尋呼到的概率大大降低，接通率隨之下降。（4） 終端/軟件問題導致的未接通 終端問題導致的未接通，測試終端由于經常每天連續工作數個小時，特別是在夏天容易發熱影響終端性能，甚至會出現一些異常事件，另外終端自身的功能設置有時與網絡的匹配存在一定的問題，也會造成頻繁的未接通。對于終端問題造成的未接通在現象上多種多樣，難點在于我們要通過各種技術手段去排除無線環境、站點等網絡自身問題，而最終定位終端存在問題不但需要我們能提出強有力的證據，還需要終端廠家的技術人員提供相關的專業軟件和工具，并且在確定為終端問題后應當與廠家人員及時溝通解決問題。 軟件問題導致的未接通，在實際測試中經常遇到，并且表現形式很多，例如被叫UE自行掛機；終端在上發CM服務請求后，立刻上發CM服務中止消息等，對于軟件問題導致的未接通需要我們在測試時就要及時的注意到，并且立刻采取合理的規避手段，例如軟件重啟，設備重連等。（5） 站點/核心網問題導致的未接通 站點故障導致的未接通，目前現網測試時經常會遇到由于站點故障導致的未接通，特別是一些經常斷站的小區，當測試車輛經過時往往由于信號過差，而終端又無法重選至斷站小區導致起呼失敗，為此我們應當對經常出現故障的站點，配置其周邊站點的鄰區關系，使該站點發生故障時，終端仍然能夠順利的切換到其它較好的小區以保持業務連續性。 室分站點問題導致的未接通，主要有兩個方面，一方面是由于室內泄漏至道路，導致終端經過此處時重選至該室分小區，當測試車輛逐漸開遠時終端又不能及時重選回室外宏站而導致拖死。另一方面是由于室分站點設計不合理，特別是在寫字樓等建筑結構相對復雜的場景下，會在部分區域形成覆蓋漏洞或者隔離度考慮不周而造成干擾。對于室分站點的問題我們均建議要盡快實施整改。 天線方位角、下傾角問題導致的未接通，隨著城市化進程的加快以及經濟的高速發展，部分小區按照當初的規劃預案建設開通后，其覆蓋方向上的無線環境可能出現了較大的變化，典型的情況如在覆蓋方向上出現了新的建筑物，會在一定程度上影響到小區的覆蓋水平，甚至信號完全被遮擋，這種情況我們就需要及時評估新的無線環境并對天線方位角、下傾角做出調整。 核心網問題導致的未接通，核心網問題導致的未接通發生的較少，但往往發生時經常伴隨著一些較為異常的現象，例如我們在測試時曾經遇到過主叫UE由于干擾、覆蓋等問題沒有正常的接收到被叫UE發送的connect以及alerting消息，因此也就沒有上發ConnectAcknowage消息給網絡，而被叫UE收到核心網由于完整性保護而自行下發的ConnectAcknowage消息，該問題的根本原因還是無線質量問題，但核心網自身的某些功能可能會對我們的分析判斷造成影響，因此還需要多加注意。（6） 位置區規劃不合理導致的未接通 位置區規劃不合理導致的未接通，大家知道位置區邊界的分布對網絡的接通率有著直接的影響，從測試情況來看，被叫UE由于在做位置區更新而導致的無法接收尋呼消息進而引發起呼失敗的案例比比皆是，因此合理的規劃位置區邊界、并通過多種手段避免在位置區邊界發生頻繁重選/切換，是我們日常優化過程中需要注意的重點之一，關于位置區如何做到合理規劃有著統一的標準，這里不再贅述，我們所要說明的重點在于根據實際測試情況來了解各個站點的覆蓋范圍和特點，因為實際覆蓋場景是規劃軟件無法準確預測的，因此就需要外場測試人員在測試時細致的分析排查LAC區邊界各個小區的覆蓋特點，以及重選帶、切換帶的分布，根據實際的情況進行參數優化或者提出合理的割接需求。 正常位置區更新導致的未接通，在測試過程中測試車輛不可避免的會發生跨位置區重選/切換，除了上面說所的位置區規劃不合理導致的未接通，在正常情況下由于合理的位置區更新導致未接通事件是難免會發生的，因此我們在測試路線的選取及規劃上需要注意盡可能的避免使測試車輛順著位置區邊界行進，減少車輛橫穿或跨越位置區邊界的次數，這樣即可有效的避免不必要的位置區更新而帶來的未接通風險，保障拉網測試指標。 位置區更新不及時導致的未接通，此類未接通事件我們在路測中時有遇到，但由于終端在空閑狀態下跨位置區重選后位置區更新不及時導致的未接通事件實際上很少，絕大都數都是在前一次呼叫過程中，被叫UE由于無線環境惡化發生小區更新，但小區更新后占用的新小區與源小區分屬于不同的LAC區，而主叫UE在被叫無線質量下降而發生掉話、小區更新的過程中已經轉為空閑狀態，并在軟件設置的呼叫間隔到時后發起了新的呼叫，而被叫UE此時占用新的小區還沒來得及進行位置區更新當然無法響應尋呼。同理，如果主叫UE在前一次呼叫過程中發生跨LAC小區更新，而按照軟件設置開始新的呼叫時，由于沒有位置區更新因此會收到網絡下發的CM service reject消息，原因為VLR中的IMSI號未被識別。（7） 容量問題導致的未接通 容量問題導致的未接通，這種情況在路測時遇到的并不多，但作為影響接通率的重要因素還是需要提到，當終端發起RRC連接請求試圖接入網絡并進行相關業務時，如果此時網絡通過RRM算法的相關流程，發現此時服務小區的無線資源已不滿足新用戶的接入，便會向終端回復RRC連接拒絕消息，原因值為擁塞，針對這種問題最好的手段是對有條件的小區進行擴容，對于已經配置為6/6/6的站點，我們還可以考慮采用多重手段進行話務分擔等。二、 典型案例上文我們主要介紹了外場測試時所遇到的未接通事件的分類及各類未接通事件的基本現象和處理手段，下面我們將重點列舉一些我們在平時工作當中遇到的比較典型的未接通事件，通過詳細的現象描述、嚴謹的分析過程最終得出高效合理的優化方案。需要說明的是，大多數事件并不是由于一種原因而導致的，經常都是有由于多種因素共同作用最后才發生未接通，并且在表象上的表現可能以覆蓋差、干擾嚴重的現象居多，但實際上這只是種種原因共同作用后的實際表現，而并不一定是覆蓋問題或干擾問題，因此請在審閱以下案例時注意區別。1覆蓋問題導致的未接通案例1問題描述：當測試車輛由北向南行駛在將軍路高架路靠近高墻王莊站點附近時，此時車速較快，主叫UE先占用蓋家莊2小區，而后切換至高墻王莊1小區，結束通過話后重選至山東新世紀1小區，并在該小區上發起呼叫，且順利完成了起呼的流程，等待被叫側回應振鈴消息，可在等待時間超時后發起了釋放。被叫側UE首先也占用蓋家莊2小區做通話業務，但并沒有從蓋家莊2小區切換到正常順序的高墻王莊1小區，而是切換到了北方汽車3小區，且在結束通話后也沒有能夠重選至高墻王莊站點的小區，同時車速較快，導致最后被叫側UE的接收信號質量極差，無法正常的收到網絡下發的尋呼消息而重選至2G網絡。主叫UE 被叫UE問題分析：通過對測試數據的回放分析，我們認為導致以上異常事件的原因主要是由于北方汽車3小區存在一定的越區覆蓋問題，致使在問題路段當車速較快時容易發生重選或者切換的問題。同時高墻王莊2小區與現代黃臺東2（主頻均為10112）存在一定的同頻干擾情況，如下圖所示：主叫UE調整方案：調整北方汽車3小區的PCCPCH發生功率由目前的33調整為27，高墻王莊2小區的主頻點由目前的10112調整為10063。案例2問題描述：當測試車輛行駛至經四路緯六路附近時，主叫UE在無線環境很好的情況下發起呼叫，并順利完成RRC建立與RB建立過程，隨后進入PROGESS狀態，在定時器超時后釋放，計為一次未接通，觀察被叫信令，發現被叫未收到尋呼消息，但在主叫釋放后被叫收到短信息提示有未接來電，如下圖所示：主被叫信令問題分析：通過上面對測試數據的初步分析，我們認為既然被叫能夠在隨后收到網絡下發的未接來電提示，則主叫于網絡側的交互已經順利完成，問題有可能處在被叫側，通過對被叫UE相關時刻的信令分析我們發現，在主叫UE發送call proceeding時，被叫UE正在進行小區重選，由緯六路1小區重選至客服二中心宿舍2小區，而在小區重選而尚未收全系統消息時，UE是無法正常接收尋呼消息的，故此時被叫無法被尋呼到，如下圖所示：被叫UE小區重選過于頻繁整改方案：建議根據現場情況適當調整客服中心二宿舍2小區的天線方位角或下傾角，減輕問題路段信號雜亂的情況，或者根據測試情況調整緯六路1小區對客服中心二宿舍2小區的Qofficet由目前的0改為2，避免在該路段UE由緯六路1小區意外重選至客服中心二宿舍2小區的概率。2干擾導致的未接通案例1問題描述：測試車輛由西向東行駛至解放路歷山東路附近時，主叫UE占用機械廳（地質學校）1小區開始嘗試建立RRC鏈接以完成一次呼叫，但主叫UE在連續多次發送RRC連接請求后沒有得到網絡側回復的RRC鏈接建立消息，當超出N300計數器的限定范圍后，計為一次未接通。 主叫UE問題分析：通過對測試數據的分析，我們人為這是典型的由于干擾導致無線鏈路質量惡化，UE上發的RRC連接請求網絡側沒有收到，或者網絡側下發的RRC建立消息UE沒有收到，致使UE在發送RRC連接請求的次數超過N300后，計為一次未接通。如上圖所示。調整方案： 修改中心醫院（室分站點）的主頻點由10055改為10063（實際上就是將主輔載波對調），同時修改機械廳（地質學校）1的主頻點由目前的10104調整為10063案例2問題描述：當測試車輛由北向南高速行駛到二環東路高架靠近輕騎路交界處附近時，此時主叫UE占用甸柳集團2小區，并且無線信號質量均不錯，PCCPCH-RSCP達到-70dBm左右，PCCPCH-C/I達到10左右，主叫UE順利的完成了起呼的相關流程，并且進入progress流程等待CN回復Alerting消息超時后，釋放相關的鏈接。被叫UE先占用甸柳集團2小區，但隨后重選到甸柳集團3小區，并且在重選過后出現了PCCPCH-RSCP值較高，但PCCPCH-C/I較差的現象，而且始終沒有收到主叫UE的尋呼1消息，而是在主叫UE釋放前后收到了網絡的未接來電的短信提示。主叫UE信令被叫UE信令問題分析：通過對測試數據的分析，我們認為造成該問題的原因有可能是由于被叫UE由于占用甸柳集團3小區時下行干擾較大，導致沒能正確的收到尋呼消息1而產生的未接通，結合數據庫以及測試軟件分析，干擾可能是陶然亭3小區（主頻10120）與甸柳集團3小區同頻造成的。整改方案：修改陶然亭3小區的主頻點擁有目前的10120調整為10080。3參數問題導致的未接通案例1問題描述：當測試出車輛由東向西行駛至二環東路與山大北路交界處時，主被叫均占用省圖書館1小區，并且此時的無線環境良好，主被叫PCCPCH RSCP值在-70dBm左右，PCCPCH C/I保持在18dB左右，但當車輛由二環東路向西拐進山大北路后，PCCPCH RSCP值下降，此時UE也開始進行新的呼叫，但由于此時無線信號的質量嚴重下降，導致在切換的過程中與目標小區下行失步，最終造成了本次起呼的失敗。如下圖所示：問題分析：通過對測試數據的分析，我們發現導致該問題的主要原因是由于省圖書館1小區與藝術研究所1、藝術研究所2小區鄰區漏配導致，同時我們發現由于基站數據庫的錯誤（經緯度錯誤）導致在鄰區核查的過程中為省圖書館配置了錯誤的鄰區，并且有可能誤刪了部分必要的鄰區，因此我們建議將該小區的鄰區重新配置。調整建議：為省圖書館1小區配置以下雙向鄰區：藝術研究所1、藝術研究所2、陶然亭1、百花小區3刪除省圖書館1小區與陶然亭2、甸柳集團3小區的雙向鄰區關系案例2問題描述：當測試車輛由南向北行駛至濟濼路與提口路交界處時（車輛已經行駛到天政賓館-天橋北站點下方），主叫UE占用天政賓館-天橋北2小區，開始進行起呼，然而在RRC建立完成UE分配到DPCH信道后，主叫UE的DPCH C/I發生嚴重惡化，并且距離站點越近DPCH ISCP值越高，最終生未接通。被叫UE在整改過程中表現正常，如下圖所示：主叫UE主叫UE問題分析：通過對測試數據的詳細分析，我們發現本次未接通應該是由于主叫UE沒有及時從天政賓館2小區重選或切換到天政賓館1小區，而天政賓館1小區的R4載波也只有10104，從上面的截圖中我們可以發現，在主叫UE呼叫前幾秒占用天政賓館-天橋北2小區相同業務載波（10104頻點）進行位置區更新時，其DPCH C/I和DPCH ISCP值就很正常，而行駛到問題點時，天政賓館1小區的PCCPCH RSCP值為-40dbm，遠高于天政賓館2小區的-60dbm，由此也可以解釋為何此時主叫UE的DPCH ISCP值非常高的原因， 并且該站點查無告警。被叫UE在問題點占用天政賓館1小區整改方案：修改天政賓館2小區的輔載波10104為10112案例3問題描述及分析：當測試車輛由北向南行駛至順河高架靠近絲綢廠站點時，主叫UE占用絲綢廠3小區發起呼叫，由于周圍無線環境的因素以及起呼的時機問題，導致主叫UE在完成RRC連接后絲綢廠3小區的信號出現快速衰落，而人民商場1小區的信號變強，使DPCH C/I惡化，UE上發測量報告后無法在下行收到網絡側發送的RB重配置消息，最終導致未接通。如下圖所示：主叫UE 問題分析：通過對測試數據的分析并結合后臺告警與指標的檢查， 我們發現本次未接通事件的主要原因是由于在切換帶附近絲綢廠3小區與人民商場1小區的信號變化過于陡峭，因此我們認為應該通過參數調整來，使切換帶的分布更加合理。整改方案：調整絲綢廠3小區對人民商場1小區的Qofficet由目前的0改為-4，同時建議修改人民商場1小區的10120頻點為10071，并設置該載波為H載波。4終端/軟件問題導致的未接通案例1問題描述：當測試車輛由西向東行駛至共青團路與普利街交界處附近靠近長話大樓站點時，主叫UE占用長話大樓1小區在無線信號質量較好的情況下發起一次呼叫，在呼叫的過程中切換至長話大樓2小區，隨后完成RB建立進入PROGESS狀態，等到被叫響應超時后釋放，被叫占用長話大樓1小區接收到尋呼消息，并發起RRC連接請求，但在第一條RRC連接請求發送后進行了小區重選，占用新的長話大樓2小區每隔兩秒連續2次發送RRC連接請求沒有得到網絡的響應，而后3秒再次接到網絡的 尋呼消息1，再次每隔兩秒連續3次發送RRC連接請求均沒得到網絡的回應，之后計數器/計時器滿，計為一次未接通事件，如下圖所示：主叫UE被叫 UE問題分析：通過對測試數據的分析我們發現，在被叫第二次接收尋呼消息并觸發RRC連接請求的時間段內主叫UE的上行發射功率較低（-15dB左右），切被叫UE的下行PCCPCH RSCP以及PCCPCH C/I均價較好但仍然沒有收到網絡下發的RRC連接建立消息，同時我們提取了長話大樓2小區7月18日的RRC連接相關指標，發現全天共發生RRC連接失敗5次（原因均為NO REPLY），且5次均為非業務相關，在本次事件的時間段（10：04：36） 沒有發生RRC連接失敗，因此認定被叫UE占用長話大樓2小區發送的RRC連接請求消息網絡沒有收到，且提取長話大樓2小區全天TS1、TS2的時隙干擾統計以及UPPCH干擾統計（時間粒度15分鐘）在事件時間段的情況均正常，因此懷疑是否由于8142型號的手機在支持RRC建立階段的重選方面機制是否存在問題。 開始時間服務小區RRC連接失敗計數器congestionRRC連接失敗計數器unspecifiedRRC連接失敗計數器，NO REPLY2010-07-18 00:45:00長話大樓0012010-07-18 10:15:00長話大樓0012010-07-18 14:15:00長話大樓0012010-07-18 15:15:00長話大樓0012010-07-18 18:15:00長話大樓001長話大樓2小區7月18日全天RRC連接失敗次數統計（全天共次）開始時間服務小區 ID載頻 ID時隙 ID時隙時隙間平均干擾時隙間最大干擾2010-07-18 09:45:00100622022.41時隙 ID:1-108.8889-89.52010-07-18 09:45:00100622022.42時隙 ID:2-108.8756-1002010-07-18 10:00:00100622022.41時隙 ID:1-108.3978-962010-07-18 10:00:00100622022.42時隙 ID:2-108.88-97.52010-07-18 10:15:00100622022.41時隙 ID:1-108.4544-93.52010-07-18 10:15:00100622022.42時隙 ID:2-108.4556-902010-07-18 10:30:00100622022.41時隙 ID:1-108.5389-103.52010-07-18 10:30:00100622022.42時隙 ID:2-108.5656-93.5 長話大樓2小區發生未接通時間段內的上行時隙干擾統計開始時間服務小區小區UPPCH測量值POS6小區UPPCH測量值POS7小區UPPCH測量值POS8小區UPPCH測量值POS9小區UPPCH測量值POS10小區UPPCH測量值POS11小區UPPCH測量值POS12小區UPPCH測量值POS13小區UPPCH測量值POS14()小區UPPCH測量值POS15()09:45長話大樓2-101.833-102.833-103-106.333-107.667-108.167-108.5-108.667-108.833-108.66710:00長話大樓2-102-102.667-103.333-106.333-107.833-108.333-108.5-108.833-108.833-108.83310:15長話大樓2-101.667-102.167-101.333-103.833-106.833-108-108.167-108.333-108.5-108.510:30長話大樓2-101.5-102.833-102.833-106-107-108-108.5-108.5-108.667-108.5長話大樓2小區發生未接通時間段內的UPPCH干擾統計詳細指標情況如下：問題分析與結論：通過對上述在RRC連接過程中觸發小區重選，從而導致隨后的RRC連接建立成功或失敗案例的簡要描述分析，我們發現在RRC建立失敗的案例中，由于無線信號質量問題導致失敗的可能性基本可以排除，同時由于源小區或者重選后的目標小區站點故障原因也可排除（后臺告警查詢均為發現異常，并且這些小區的RRC連接建立成功率指標較好），那么是什么原因在無線環境、參數配置、站點工作狀態均沒有問題時，而導致RRC建立失敗的呢？為此我們進一步提取了測試時的后臺CT，如下圖所示：7月18日長話大樓1小區被叫UE起呼失敗CT截圖通過上面測試CT截圖，我們可以發現在失敗的案例中，UE在源小區上發送的第一條RRC連接請求RNC均成功收到，網絡側不但進行了RL的建立，而且向UE回復了RRC連接建立消息，但此時UE已經占用到新的小區，因此無法收到網絡側發送的RRC連接建立消息，當然就無法進行后續的RRC建立流程，問題到這一步還比較好理解，然而繼續分析，我們發現當UE成功的重選至目標小區后，在新的小區上發送的RRC連接請求竟然也發送到了源小區。通過上面的描述我們初步推斷，由于小區重選造成RRC流程失敗的主要原因應該是，UE進行小區重選時，由于自身性能限制或處理時間過短，下行鏈路雖然已經轉移到新的小區，但上行鏈路卻仍然保持在源小區，從而導致雖然監聽到新小區PCCPCH信道的系統消息，但發送的RRC連接請求仍然使用的是源小區的PRACH信道。那么為什會產生這樣的情況呢？我們查看并分析對比了成功案例與失敗案例的事件列表，在提到事件列表時，我們應該明確測試軟件與測試手機行為之間的關系，測試軟件在測試過程中的任務，應該是控制手機何時開始發起呼叫，何時掛機，并記錄手機在測試過程中的各種行為，因此事件列表中手機在RRC連接建立或者起呼過程中的行為，均應該是手機自身的行為，而非軟件控制，事件列表如下圖所示：成功案例與失敗案例的事件列表對比從上圖中我們發現成功案例中，手機在vioce dial開始起呼流程，之后被記錄到發送了RRC連接請求消息，隨后開始小區重選，但在失敗案例中，手機在vioce dial后并沒有RRC連接請求消息的記錄，而是直接開始小區重選（實際上手機也發送了RRC連接請求）。失敗案例中事件列表與信令流程對應圖成功案例中事件列表與信令流程對應圖通過對RRC連接過程中，小區重選導致的起呼失敗及成功案例的測試數據分析，并結后臺CT的分析，我們認為產生這種現象的原因由于8142手機自身性能問題引起的可能性較大，因為失敗案例無論從當時的無線環境、站點工作狀態、主要參數設置（定時器/計數器）來看， 均比較合理，特別是參數設置與成功案例無異，唯一的區別在于第一條RRC連接請求消息發送后，失敗案例中的UE小區重選時，下行鏈路接入到目標小區，但上行鏈路仍然保持在源小區，由此導致隨后在新小區上發送的兩次RRC連接請求均發送給源小區，而源小區下發的RRC連接建立UE卻無法收到，因為此時UE正在監聽新小區的下行鏈路，由此導致一次RRC連接失敗，進而引發未接通的產生。我們將盡快聯系8142手機廠家，共同核實我們的結論案例2問題描述：主/被叫UE完成RRC連接過程后，開始進行初始值傳消息的傳送，在發送完CMservice request后，又馬上（通常間隔1秒左右）發送CM service abort給網絡，由此導致初始值傳流程中斷，造成未接通。并且出現該問題后，通常測試軟件不會再控制手機發起新的呼叫 ，使測試無法繼續進行，直至測試人員將軟件重啟或者重新錄制測試LOG為止。該問題在LC8142以及DX188上均有出現，并且出現該現象時無線信號質量通常沒有較大的波動或異常，而且復測從未復現，因此我們認為該問題應該為軟件問題所致。主叫UE 11:51:25.083起呼失敗信令被叫UE 14:00:44 起呼失敗信令案例3問題描述：當測試車輛由北向南行駛至山大路靠近經十路附近時，主被叫UE均占用千佛山醫院1小區，而且無線信號質量良好，隨后主叫UE發起一次呼叫，被叫UE正常響應尋呼并順利完成RRC連接，但在進行初始值傳消息的發送后，被叫UE突然上發disconnect消息，原因解碼為user busy，由此導致呼叫中斷，軟件統計為一次未接通，如下圖所示：主被叫UE聯合信令截圖被叫UE主叫UE問題分析與結論：通過對測試數據的分析并結合千佛山醫院1小區指標和告警信息的提取，我們認為由于測試過程中手機終端的行為（起呼，掛機），主要是受測試軟件的控制，而本例中主被叫UE掛機均是上行發起，即主被叫UE幾乎同時主動通知網絡掛機，而不是由其中一方引起，因此本次未接通異常事件由測試軟件不穩定引起的可能性較大。測試人員曾經在測試過程中直接觀察到該類型未接通，當時在主叫發起呼叫后，被叫側已經聽到振鈴，但在振鈴剛響起后馬上停止，觀察被叫手機會發現提示有未接來電。另外，一般網絡問題導致被叫未收到尋呼而產生的未接通，通常會有漏接來電短信提示。由于類似案例中，大多數發生在RRC連接完成后，出現問題主要在RAB建立過程（空口體現在RB建立），或者RB建立完成后Alerting消息發送過程中，而后臺指標的接通率反映的是RRC連接成功率*RAB建立成功率，因此只要RRC連接過程以及RAB建立過程順利完成，后臺即統計為一次成功的呼叫，導致前臺測試軟件統計結果與后臺結果不統一案例4問題描述：當測試車輛由西向東行駛至大明湖路與縣東巷交界處時，主被叫UE均剛從GSM網絡重選回TD網絡，由此觸發了一次位置去更新，此時主叫UE占用明湖南門2小區且無線信號質量很好，當主叫順利完成了位置區更新的主要流程，開始進行RRC連接釋放時，突然上行發送CM Service request消息，導致軟件統計為未接通事件，如下圖所示：主叫UE主叫rrcConnect Request消息解碼主叫UE CM service request 消息解碼問題分析及結論：通過對測試數據的分析，我們認為主叫UE在位置區更新的過程中出現的CM service request信令應該是手機自身由于某種原因觸發的異常信令，因為從上面的描述及分析中我們可以看到，本次RRC連接請求的原因時異系統重選無誤，而相隔3秒后上發的CM service request消息的原因為主叫，上下矛盾，因此該問題為手機自身問題。5站點/核心網問題導致的未接通案例1問題描述：當測試車輛由西向東行駛到二環北路萬通物流站點附近附近時，此時主被叫UE均占用萬通物流2小區，PCCPCH RSCP保持在-60dBm左右，PCCPCH C/I保持在18dB左右，同時主叫開始進行起呼，整個起呼流程正常，但由于該路段位于位置區邊界，導致主被叫UE均在起呼的過程執行了RB重配置，并且觸發了路由區更新，最終由于在起呼的流程中嵌套內容過多，導致主叫等待超時而計為一次未接通：主叫信令問題分析：通過對測試數據的分析并與中興的同事進行了溝通，我們發現該問題主要是由于目前中興的設備自身存在一定的漏洞，導致主叫側在起呼的過程中由于進行了路由區更新，而使連接時間過長導致未接通，而被叫處于完整性保護的原因，雖然收到了CN下發的Alerting、Connect等消息，但實際并沒有建立起完整的呼叫。如下圖所示： 被叫信令主叫釋放信令調整方案：中興的同事已經提出了針對此問題的修改方案，主要是通過為系統打補丁來進行案例2問題描述：當測試車輛由東向西行駛到濟濼路北園大街附近時，主被叫UE一直占用紡織市場1小區，隨著車輛的行駛，信號質量開始不斷下降，但在鄰區表中一直沒有合適的小區可以重選或切換，最終導致在主叫UE發起呼叫的時候信號質量已經很差，無法正常的進行起呼流程。 主叫UE問題分析：通過對測試數據的回放，我們認為中恒商城站點可能存在故障，因為該小區在已經與紡織市場1小區配置鄰區關系，但一直沒有出現在鄰區表中，通過后臺的告警查詢最終證實了這一點，在6月27日至6月29日（本次測試第二天）該小區突然出現大量重要以及嚴重告警，告警信息如下所示：告警信息詳情：調整方案：排除中恒商城站點的故障案例3問題描述：當測試出車輛由西東向西行駛至經四路緯三路交界處時，此時主叫UE占用大觀園2小區并發起呼叫，呼叫流程進行至Call Proceeding后，由于超時沒有收到網絡下發的RB建立消息而釋放，發生一次未接通，此時主叫UE的PCCPCH C/I以及DPCH C/I已經較差。同時間被叫UE占用宏順服裝2小區，信號質量良好。如下圖所示：主叫UE被叫UE問題分析：通過對測試數據的分析我們發現，在主叫UE進行起呼之前由濟南文物店1小區重選至大觀園2小區，由于大觀園2小區的覆蓋方向與行駛方向相反，并且該小區的天線方向角有可能存在問題（也有可能是1、2小區天線接反），導致其背向信號覆蓋至問題路段，并且在很短的時間內確實高于正常重選順序的宏順服裝 2小區，使主叫UE重選至大觀園2小區并發生了隨后的問題。如下圖所