據統計，我國目前電信網的業務接通率只有45%左右，若接通率提高一個百分點，收益可達10億元，同時可以顯著改善我國目前交換機的超負荷情況，所以說提高電信網的業務接通率是一項非常重要的工作。

隨著我國電信技術的發展，電信運行維護的工作重點已經從片面地追求來話接通率轉移到如何提高網絡的接通率。在采用七號信令中繼的情況下，網絡的接通率可通過如下公式來表達：100%×(ACM+SLB+STB)/(IAM+IAI)，從公式可以看出，網絡接通率主要用于分析呼叫失敗的網絡側原因，即設備原因;而對于被叫用戶忙和久叫不應所造成的未接通呼叫不再列為呼損，使考核結果更趨合理，從而準確地反映出交換設備的維護水平。

合理配置維護交換機數據庫數據

C&C08交換機數據庫中存在三個主要關系表：用戶索引表、用戶數據表和設備表，在配置數據時，應保持數據參數的一致性和合理性，從而避免空錯號的呼損、擁塞信號的產生和信號配合的錯誤情況的出現。

入中繼呼叫時，表格缺數據記錄的影響

對02版或03B等版本，由于各個表格之間數據的正確關系通常要由填表人來保證，因此常常會發生數據短缺或表格之間數據不一致，這些都會導致檢索表格失敗，造成呼叫失敗。03I版及其以后版本由于采用存儲過程封裝處理，表格之間的一致性由程序保證，避免了表格之間數據的不一致，減少了上述現象的發生。

 與中繼相關的字冠等數據的設定

如果本局是端局，一定要要求上級局將至本局的字冠做詳細，否則，會因為字冠不對導致入中繼來的號碼出現空、錯號的呼損。并盡可能地將上級局局向的中繼群呼叫源與本局用戶的呼叫源分開，將上級送來的呼叫做落地處理，避免字冠死循環的發生。特別是在C3及C3以上的市話網中，是不允許端局做字冠的匯接處理的。

對于字冠數據的設定，注意如下原則：若本局是端局時，對入中繼來的呼叫，預收號長可以設定為等于本局號長，這樣，減少了內部消息包數量及號碼分析次數。對于出局呼叫，預收號長及最小號長也要盡可能設置大，中繼承載的電路占用點也要設置大，最好是成組發碼，這些數據設置大的好處不僅提高了交換機的處理效率，提高電路利用率，而且能最大限度降低信號配合的錯誤。

對于TUP出局呼叫，最好主動發送主叫號碼，以減少局間消息包數目。新國標已作這方面的規定，全網開通主叫顯示功能，發端局須發帶主叫信息的IAI前向消息。03I版中軟件參數“TUP運行保留參數4”BIT1=0 時，TUP將主動發送主叫號碼，而無需作補充信令表，非常方便;對ISUP，軟件參數“ISUP運行保留參數10”BIT10=1時，也具有同樣效果。

匯接局到落地局的發碼方式應該為“成組發碼”，但是現在從匯接局MS3來的呼叫中有少部分是采用“重疊發碼”，當發號不全時容易造成“撥號中放棄”的呼損，此問題應讓局方協同解決。

合理配置光路、中繼及組網的網絡參數

網絡參數配置原則

中繼模塊配置原則。在多中繼模塊情況下，通常一個AM32或AM128下掛多個TSM模塊，為了保證單模塊故障不影響全局與其它局向之間的聯系，必須將去同一局向的電路分配到不同的中繼模塊。同理，去同一局向的鏈路也必須分布在不同中繼模塊的七號信令板上，即使只有一個中繼模塊，也應將去同一局向的鏈路分布在不同的七號信令板上，避免由于一塊七號信令板的損壞造成某一局向出現全阻故障。此外，七號鏈路所配置的話路時隙也應分配在不同的DT板上，避免由于一塊DT板的損壞造成多條鏈路的中斷。

鏈路選擇原則。盡量保持話路與其對應的優選鏈路在同一模塊，避免出現諸如話路選擇TSM1，而鏈路選擇TSM2或TSM3等現象，減少模塊間的消息包。

例如， 某局的一個管理模塊下帶4個中繼模塊，4個中繼模塊下掛24個RSMⅡ，只有一個S1240出口局，與S1240對開的七號電路分布在4個中繼模塊上。通過如表1、2、3所示的數據修改過程，可以實現不同呼叫源碼的用戶撥打出局電話時，固定占用某個中繼模塊，從而減少模塊間的消息包，降低交換機的擁塞率。在ST用戶表中，將4個中繼模塊所帶的RSMⅡ用戶呼叫源碼分別定義為1、2、3、4。

合理配置網絡參數的途徑

合理配置字冠數據。若本局為端局，對于入中繼呼叫(對入中繼群單獨設置呼叫源碼5)，在呼叫源表中，該呼叫源碼5對應的預收號長設定為等于本局號長，減少內部消息包的數量和號碼分析次數。對于出局呼叫，尤其是長途、自動尋呼和移動電話等要求主叫號碼的字冠，在被叫分析表中，該字冠對應的"補充信令標志" 設置為"是"。在補充信令表中，各字冠對應的"是否發主叫號碼"設置為"是"(發IAI)，以減少局間的消息包數量。另外，預收號長(呼叫源表)和最小號長(被叫分析表)應盡可能配置大些，中繼承載的電路占用點也應配置大一些，最好配置為成組發碼，以提高交換機的處理效率和電路利用率，最大限度地降低信號的配合錯誤。

設定中繼電路選線方式。對于七號信令電路，國標規定了兩種選線方式：大小/小大、主控/非主控(LIFO/FIFO)，優先使用主控/非主控方式。有些交換機，如5ESS等，可能會采用大小/小大方式，這時要注意：對接的兩個局，一方從CIC最大的電路開始選擇，另一方從CIC小的電路開始選擇，但08機的電路選擇則是根據中繼內碼來實現的，要注意CIC與中繼內碼的映射關系，做出正確的數據。由于七號電路是雙向電路，電路可能會發生同搶，為此，預先規定對接的兩個交換機各自主控一半的電路，當發生同搶時，非主控方釋放對電路的占用，并在另外一條空閑電路上重新發起呼叫。在兩個交換機間，信令點編碼大的一方主控CIC為偶數的電路，信令點編碼小的一方主控CIC為奇數的電路，若雙方主控同一方向的電路則影響更大，可能會引起電路吊死，應注意。話務量較大時，同搶對接通率有一定影響，應注意避免。

對于模塊間中繼選線方式，建議在配SM和RSMII(或SMII)之間的中繼選線方式時最好配為“最小”、“最大”或“主控/非主控”。

合理分配話務流量。在數據配置時，有時很難預見哪些用戶屬于高話務量用戶，當某用戶框(或RSA框)集中了過多的"網蟲"或熱線用戶(傳呼臺、熱線服務和股評等)時，會造成系統的話務量過于集中，從而引起呼損。通過C&C08交換機的話務統計功能，可以及時發現數據配置中的不合理成分，繼而進行數據配置優化處理。主要的統計方法有：

· 用戶線群統計。通過分析模塊、用戶框和RSA框的用戶呼叫分布情況，找出話務量最大或最小的用戶框和模塊，采取相應改善措施。

·局向目的地話務分布統計。分析經過某個局向到各個目的地的去話話務分布情況，找出話務量較大的部分，并通過在被叫分析表中調整相應字冠的路由選擇碼，均衡話務。

·模塊通信狀態和流量統計。統計各模塊之間的話務流量分布，如果發現某些鏈路流量特別大，而某些鏈路的流量又特別小，則必須對數據重新進行配置，減少模塊間的呼叫。

·模塊內部電路群統計。通過對OPT、IDT、E16等話務進行統計，確認是否存在話務過重，擁塞時長過長等情況，進一步采取改善措施。

合理分配模塊間的消息流量。通常是由于中繼電路和信令鏈路安排不合理造成的，如某模塊只有話路，沒有鏈路，每次出局呼叫均要走模塊間光路，就會造成模塊間的消息流量過大，造成一定的OPT網絡資源緊張。

減少CGC信號的發生，合理配置中繼數據。一般來說，當路由表、路由分析表、中繼群表和中繼群/子路由表數據配置有誤時，容易導致CGC信號的發生。

用戶硬件、狀態方面的原因

最常見的是外線故障。用戶外線故障的情況主要有斷線、混線、單線地氣、用戶鎖定等情況。外線斷線時，每次撥打該用戶，能夠聽到回鈴音，但總是無人接聽，與久叫不應用戶很相似;當出現單線地氣時，會導致上報誤摘機、亂撥號等現象，這些都會影響接通率;用戶端口鎖定時，會造成撥打聽忙音，與用戶忙很相似 。因為斷線、鎖定與“久叫不應”、“被叫忙”相似，需要注意與“真久叫不應”、“真忙”用戶區分開，區別處理。上述情況往往是一些C4、C5局接通率低最直接、最根本的原因。

少部分為ASL、DRV板故障。話務統計失敗原因是“終點故障”。撥打該用戶，多為“嘟、嘟”故障音;跟蹤，多為鎖定、自動撥號、反復摘掛機、摘機后雙方聽不到聲音(單線地氣);測試，多為線間絕緣差、碰其他用戶線、單線地氣等。

另外還有ONU用戶停電、無模塊間話路時隙(CTN控存吊死)、用戶久叫不應等。對于ONU用戶停電，話務統計失敗原因是“臨時故障”。觀察均為V5ST 用戶，事件告警中有V5ST用戶端口閉塞告警，經查為停電ONU的用戶。處理方法：對停電ONU字冠作號首處理送擁塞音;對于無模塊間話路時隙(CTN控存吊死)，如用戶框的62個時隙(RSA遠端為56個)已用完等，話統失敗原因是“無可用資源”。對于用戶久叫不應，采用下述方法解決：向用戶增加"無應答轉語音郵箱"新業務：MOD ST：DN=PQABCB，NS=CFNRAVM-1;修改本局信息表，如直接索引號設定0，久叫不應轉語音郵箱設定1423;改變久叫不應轉語音郵箱的定時器時長：MOD REALTIMER：PID=13，定時器組號=0，組內索引=25，NVL=30。

值得注意的是，久叫不應定時器時長缺省值為20s，即約振鈴5次左右開始轉入語音郵箱。為了防止被叫在振鈴5次后接聽時，呼叫已經轉移的情況經常發生，一般將久叫不應轉語音郵箱的定時器時長設置到30s。對于久叫不應送CFL的情況，還可通過呼叫前轉功能進行改善，但若呼叫前轉仍不成功，則仍宜回送CFL。此外，對于ISDN用戶來說，由于外線停電等原因造成設備處于未激活狀態，當其作為被叫時也回送CFL，可視具體情況具體解決。

總結

總之，影響交換機接通率的因素多種多樣，我們在日常維護過程中，通過分析數據一致性、合理配置網絡參數及分析用戶故障，采取了相應的解決途徑，明顯提高了網絡接通率，從而顯著提高了系統的運行維護質量。

博客原文：http://blog.163.com/xutong_hust/blog/static/15818372008513112757702/