接通率是指電話交換機接通呼叫次數與用戶呼叫總次數的百分比值。它是衡量電話交換系統服務質量好壞的指標之一。
基本介紹
- 中文名：接通率
- 外文名：Connection rate
- 領域：通信
簡介,測試方法,影響因素,提升方案,
簡介
用戶希望用手機撥打電話時，在被叫正常情況下，要一打就通，而不應是需要多次撥打才能接通。因此無線接通率是一項衡量GSM系統性能的重要指標，它反映系統的可接入性，並且直接影響系統的接通率。因此如何提高呼叫建立成功率也就成為系統最佳化的一項重要上作內容。
當移動用戶準備接入網路時最先向交換機傳送的是隨機接入請求，很高的隨機接入失敗會影響網路的接入性，因此隨機接入成功率直接影響網路的接入性能。
測試方法
一般話局在日常稚護中最常用的測試方法有兩種：一種是利用服務觀察設備進行觀察；一種是利用裝有擬似電路與電容的話機進行撥號測試。前者稱為服務觀察法，後者稱為撥號測試法或擬似呼叫法。利用服務觀察設備可以對用戶使用電話過程作全面觀察，能夠反映用戶使用電秸的真實情況，包括用戶使用不當等情況在內，是一種此較理想的接通率測試方法。可是目前裝設服務觀察設備的地方並不多，還不能普遍套用這種投備來觀察用戶使用電括的情況，各局大都採用撥號測試法進行接通率測試。為便於比較各地的接通率情況，目前郵電部電信總局規定各地統一以撥號測試所得的接通率上報，因而某些有服務觀察設備的話局在進行服務觀察的同時，也進行撥號測試。
影響因素
接通率是考核網路運行整體性能的的指標，影響接通率的因素很多，但歸納起來主要是以下幾個方面：尋呼逾時；用戶忙；被叫關機；用戶無應答；通信鏈路建立失敗（電路忙、TCH信道忙或TCH分配失敗）；由於BSC，MSC中參數定義問題導致接續和PAGING時間過長；撥號不全。
尋呼逾時
尋呼逾時是指從MSC成功的發出尋呼訊息後，在規定的時間內MSC未收到MS返回的尋呼回響。尋呼逾時是影響接通率重要的因素，導致尋呼逾時的原因有很多種。
尋呼處理共分兩級，一級在MSC，一級在BTS。MSC負責形成尋呼訊息，並且為了防止MS此時的無線情況較差，MSC將組織重發，它的尋呼重發訊息的間隔較長，大約十秒。移動用戶進入盲區或手機掉電。若此時交換機的周期性位置更新的時間未到（MSC將定時對IMSI ATTACH的用戶進行查詢，它將把這～段時間內未與系統聯繫的MS置為隱含關機狀態），MSC仍會對該用戶發出尋呼訊息，但顯然這只能白白的浪費系統資源，最後不可避免的造成尋呼逾時。
通信鏈路建立失敗
這指的是在移動台和網路之間的RR連線已經建立起來之後，卻由於鑒權失敗、無線呼損、TCH信道的擁塞、TCH信道的指配失敗、A接口或Abis接口的地面資源缺乏的原因，最終導致呼叫無法正常的接續。
主叫用戶過早掛機
主叫用戶過早掛機時指，在被叫用戶尚未應答前，主叫用戶主動掛機拆線。信令流程表現為TuP訊息IAI，ACM發出後，主叫用戶主動掛機拆線，主叫端向被叫端傳送CLF訊息。用戶早釋主要是指主叫在撥號中放棄呼叫或是在被叫振鈴時主叫（或被叫）早釋，例如，在被叫振鈴或主叫聽錄音通知時（如被叫無應答、被叫電話正在轉移等）發生的早釋。
有時是由於MSC與BSC的一些參數設定不合理導致接續時間比較長，而使一些沒有耐心的用戶掛機重撥，導致呼叫前向釋放。如果通過話務統計及撥打測試發現此現象比較多時，可適當調整參數加快接續時間。
其他原因
（1）撥號不全
在MSC解碼表中可適當的進行細分，攔截一些撥號不全的呼叫出局。
（2）對於被叫掛機、久叫不應這種用戶行為，無法從網路質量上解決，只有通過優惠政策和多做宣傳解決，從而降低其對接通率的影響。
不管如何，我們除了對以上因素進行最佳化外。還應大力宣傳新業務的使用。如向用戶開放遇忙轉移，對於具有多種通信工具（如CALL機、宅電）的用戶，可以設定遇忙轉移業務，將遇忙的呼叫轉移到語音信箱、中文秘書台或其他通信工具。
提升方案
以下是針對隨機接入成功率提出的指標提升方案：
（1）結合故障現象的起始時間和持續時間調查小區周圍是否有新增射頻發射裝置。檢查頻率分配方案確認有無同頻或臨頻干擾，如果有，可改動BCCH頻率或BSIC，觀察統計結果和解碼的RACH電平是否有變化。可以使用OSS上RNO的功能，如FAS和MRR進一步確定故障小區的干擾情況和統計特徵，必要時可進進行路測。最後可利用頻譜分析儀或射頻接收機檢查干擾信號的特徵，確定是否為寬頻直放站或干擾機引起的上行干擾等等。
（2）如果隨機接入失敗持續存在，檢查是硬體問題還是干擾問題。查看ERROR LOG 看有無硬體告警，同時檢查下列運行狀況：TCH話務統計情況、SDCCH話務統計情況、切換統計情況，小區內切換情況，以及空閒信道測量統計等確定有無BCCH上行干擾或弱信號接入、路徑損耗過大等。
（3）如果上行有硬體故障，那就會導致網路對MS信道請求無法進行信道指配，甚至無法收到MS信道請求。出現這種情況時應檢查基站硬體，特別是上行部分（TRX、天線、饋線）。若無法確認應作Abis口掛表分析，檢查鏈路預算，以確認問題所在。
