任夢溪



摘要:本文針對某局××高鐵BSC接入新設MSC后出現(xiàn)的跨三個MSC切換概率性切換失敗導致CTCS-3無線連接超時問題進行深入分析,找到問題根因并提出解決方案。XX高鐵在列車運行期間,列車通過NSC切換區(qū)域,偶爾發(fā)生跨區(qū)MSC切換失敗,造成車-地通信中斷,CTCS-3級列控系統(tǒng)失效降級運行。通過數(shù)據(jù)收集和故障分析,確定故障為通信鏈接響應超時所致,針對故障原因提出解決方案,排除列車跨區(qū)運行切換失敗的故障現(xiàn)象。
關鍵詞:MSC切換;CTCS-3無線連接超時;T7定時器
中圖分類號:TP391.41? ? ?文獻標識碼:A ? ? ? 文章編號:1007-9416(2018)10-0000-00
CTCS-3級列控系統(tǒng)基于GSM-R無線通信實現(xiàn)車-地信息雙向傳輸,無線閉塞中心(RBC)生成行車許可,軌道電路實現(xiàn)列車占用檢查,應答器實現(xiàn)列車定位,并具備CTCS-2級功能的列車運行控制系統(tǒng)。
CTCS-3中文名稱是:中國列車控制系統(tǒng)-3級[1]列控系統(tǒng),應用在時速大于300km的客運專線和高速鐵路中。CTCS-3級列控系統(tǒng)包括:地面控制設備、車載控制設備、GSM-R無線通信網(wǎng)絡、信號數(shù)據(jù)傳輸網(wǎng)絡四部分組成。CTCS-3級列控系統(tǒng)在CTCS-2級列控系統(tǒng)的基礎上,軌旁增加無線閉塞中心RBC設備,車-地增加GSM-R無線電臺,車載增加無線接口模塊,實現(xiàn)基于GSM-R無線網(wǎng)線的車-地雙向信息傳輸。車載控制設備通過GSM-R無線通信網(wǎng)絡向軌旁發(fā)送列車位置和列車參數(shù)信息,軌旁無線閉塞中心RBC設備通過GSM-R向車載發(fā)送行車許可、線路參數(shù)和臨時限速信息,實現(xiàn)連續(xù)列車運行控制功能。GSM-R網(wǎng)絡作為車-地之間信息交互承載通道,傳遞車載控制設備(ATP)和地面控制設備(RBC[2])的列控信息。如果車-地通信中斷,列車將降級至CTCS-2級運行。CTCS-3系統(tǒng)如圖1所示。
1 問題描述
某局于某日0:15-1:50完成了××[3]高鐵BSC接入新設華為MSC,施工結束后,該路局通信段根據(jù)施工方案組織了相關撥測并添乘DJ8723、DJ8724動檢車進行撥測驗證,語音通信、進路預告、調度命令、299組呼、210組呼、跨局路由更新、C3列控等業(yè)務均正常。隨后,利用接口監(jiān)測網(wǎng)管和DMS網(wǎng)管繼續(xù)觀察××高鐵列車運行情況,6:21發(fā)現(xiàn)DJ8722次列車運行發(fā)生列車CTCS-3無線連接超時,但不影響列車運行速度。后續(xù)陸續(xù)發(fā)現(xiàn)G1971、G1964次等陸續(xù)降級,當天××高鐵共運行列車75趟,其中降級23趟,降級現(xiàn)象如下:
(1)XXD往ZZ方向:ATP在XXD(某局諾基亞MSC)切換ZZ-XZD19(鄰局MSC)成功,ZZ-XZD19切換ZZ-XZD18 成功,ZZ-XZD18(鄰局MSC)切換TSXLS01A(某局華為MSC)失敗,ATP發(fā)生C3降級。
(2)ZZ往XXD方向:ATP在TSXLS01A(某局華為MSC)切換ZZ-XZD18(鄰局MSC)成功,ZZ-XZD18切換ZZ-XZD19 成功,ZZ-XZD19(鄰局MSC)切換XZD(某局華為MSC)失敗,ATP發(fā)生C3降級。
現(xiàn)象總結:當行車路線為某局華為MSC<—>鄰局MSC<—>某局諾基亞MSC 時,ATP將發(fā)生跨3個MSC切換場景,在此場景下,鄰局MSC概率性出現(xiàn)切換失敗,車-地通信中斷,造成列車降級運行。
2 問題排查
為查找原因,我們針對可能的原因進行分析,按照“分類查找、縮小范圍”的原則,分別對傳輸電路質量、現(xiàn)場電磁環(huán)境、GSM-R無線側設備、GSM-R交換側設備和互聯(lián)數(shù)據(jù)進行分析。
2.1傳輸電路質量排查
為確保傳輸電路質量,對本次施工涉及的27條電路和既有某局華為MSC與某局諾基亞MSC、鄰局MSC之間的14條互聯(lián)電路進行性能分析,定時分析電路是否有誤碼、指針調整等異常事件,分析結果顯示,所有電路性能均正常。
2.2現(xiàn)場電磁環(huán)境排查
為確保××高鐵在發(fā)生降級的區(qū)間電磁環(huán)境滿足GSM-R網(wǎng)絡要求,一方面由專業(yè)工程師到現(xiàn)場進行電磁環(huán)境測試,沒有發(fā)現(xiàn)無線干擾;另一方面,調看近10天的接口監(jiān)測數(shù)據(jù)和DMS網(wǎng)管數(shù)據(jù),該區(qū)間未發(fā)生因無線干擾引起的C3降級。
2.3 GSM-R無線側和GSM-R交換側排查
為確保GSM-R無線側設備和GSM-R交換側設備數(shù)據(jù)準確,對當天××高鐵BSC割接涉及的數(shù)據(jù)腳本共計1052條命令進行逐一分析,發(fā)現(xiàn)施工涉及的數(shù)據(jù)腳本正確無誤。為核對施工時的操作準確性,從新設華為MSC網(wǎng)管導出施工當天的所有操作記錄和保存的腳本,與施工方案的腳本進行核對,均無誤。
2.4互聯(lián)數(shù)據(jù)排查
為核實××高鐵BSC至新設華為MSC之間的通信正常,對××高鐵BSC至新設華為MSC之間的PRI口、A口、Ater鏈路進行數(shù)據(jù)分析,確認物理鏈路狀態(tài)正常。
為核實某局諾基亞MSC和某局華為MSC之間的信令是否正常,用網(wǎng)絡信令測試儀對兩者之間的E口信令進行掛表測試,均未發(fā)現(xiàn)異常[4]。
無線鏈路超時造成車-載信息傳輸中斷,意味著CTCS-3系統(tǒng)失效,為保障運行安全,列車只能降速運行。
3 問題分析
3.1 ZZ到某局方向華為MSC分析(G1914)
3.1.1 E接口信令分析
某局華為MSC在10:22:55收到鄰局的后續(xù)切換請求消息,攜帶目的小區(qū)LAC 0X410b以及目的MSC號碼8614900411(某局諾基亞MSC)。某局華為MSC向某局諾基亞MSC發(fā)起切換消息,某局諾基亞MSC返回切換響應消息。局間連接建立完成后,10:22:57某局華為MSC給鄰局MSC回后續(xù)切換響應消息,此時某局華為MSC進入等待切換檢測消息狀態(tài)。7秒后某局華為MSC未收到某局諾基亞MSC發(fā)送的切換檢測消息,定時器超時,主動發(fā)出ABORT消息,拆除呼叫。整個切換過程如圖2所示。
3.1.2原因分析綜述
某局諾基亞MSC沒有發(fā)送切換檢測消息(HO_DETECT) 給某局華為MSC,最終導致某局華為MSC等待切換檢測消息(HO_DETECT)定時器超時,拆除呼叫。
3.2某局到ZZ方向華為MSC分析(G1879)
3.2.1 E接口信令分析
08:39:48某局華為MSC接收到來自某局諾基亞MSC的切換請求消息,某局華為MSC回切換響應消息給某局諾基亞MSC如圖3所示。
3.2.2 A接口信令分析
對應08:39:48某局華為MSC收到某局諾基亞MSC發(fā)送的切換請求消息后如圖4所示,某局華為MSC 08:39:48向某局BSC發(fā)送HO_Request, 某局BSC返回HO_Request_ack給某局華為MSC。某局華為MSC回切換響應消息給某局諾基亞MSC。但是之后未收到某局××高鐵BSC發(fā)送的切換檢測消息HO_DETECT消息。08:39:56某局華為MSC發(fā)clear_command 消息拆除呼叫。
3.2.3到武漢STP信令分析
08:39:49某局諾基亞MSC給某局華為發(fā)IAM消息,進行局間連接建立。如圖5所示,08:39:49某局華為MSC給某局諾基亞MSC回ACM消息,但是由于某局××高鐵BSC未發(fā)送切換檢測消息給華為MSC,導致某局華為MSC未發(fā)切換檢測消息給某局諾基亞MSC,約7秒后08:39:56某局華為MSC等待切換檢測定時器超時,華為MSC向某局諾基亞MSC發(fā)REL(拆線)消息,同時收到了某局諾基亞MSC發(fā)送的REL消息,拆除呼叫。
3.2.4原因分析綜述
某局××高鐵諾基亞BSC沒有給某局華為MSC發(fā)切換檢測消息HO_DETECT,最終導致某局華為MSC及某局諾基亞MSC定時器超時,同時向對端拆除呼叫。
3.3諾基亞MSC分析
在某局MSC和北京武漢STP之間跟蹤信令,追蹤到一個切換失敗的記錄,大致失敗流程如圖6所示。
呼叫記錄:1:40用戶14984073341(信令表時間和交換機時間差8個小時)。從上面流程中可見,系統(tǒng)等待華為MSC發(fā)送切換檢測消息,等待7秒送后收到華為的發(fā)REL消息,后面的切換流程中斷。
3.4三接口檢測數(shù)據(jù)分析
通過對三接口檢測分析A接口和Abis接口數(shù)據(jù),如圖7所示,發(fā)現(xiàn)鄰局的MSC給BSC下發(fā)了HandOver Command(切換命令),但是BSC收到該消息后并沒有將該消息發(fā)給BTS。
3.5深入分析
綜合華為、諾基亞和接口檢測的三方面數(shù)據(jù)分析,得出以下初步結論:(1)華為MSC作為主控MSC時,沒有收到某局諾基亞MSC發(fā)送的切換檢測消息(HO_DETECT);(2)諾基亞MSC作為主控MSC時,也沒有收到某局華為MSC發(fā)送的切換檢測消息(HO_DETECT),而華為MSC沒有發(fā)該消息,是因為沒有收到××高鐵BSC發(fā)送的切換檢測消息HO_DETECT消息;(3)從三接口檢測數(shù)據(jù)看,鄰局BSC沒有發(fā)HandOver Command給BTS,因此可以很自然的推測出:鄰局收到某局回的 “切換響應”消息后,BSC沒有將“切換命令”下發(fā)給ATP,導致ATP沒有在某局的小區(qū)下發(fā)送“HO ACCESS”消息,某局側網(wǎng)元等待消息超時,拆除切換流程,切換失敗。
因此問題的關鍵節(jié)點指向鄰局MSC和BSS之間。對所有降級車次的信令進行反復的分析,發(fā)現(xiàn)華為MSC從收到鄰局切換請求,到往鄰局方向發(fā)出切換響應消息,至少需要1.4秒以上(不含到武漢到鄰局的回程傳輸時間以及武漢STP和鄰局MSC的消息處理時間),同時降級車的時長基本在1.5秒以上見表1。
最后鎖定鄰局京滬高BSC的T7計時器,并結合接口檢測看到的時長數(shù)據(jù)(切換失敗的時長都大于2秒),并初步推斷該計時器設置的時長很可能為2秒。
找到了問題的方向,經(jīng)與鄰局核查京滬高BSC T7定時器的設置,該BSC的設置為4*500毫秒,也就是2秒,驗證了我們的推測。
4 問題解決
與鄰局溝通后,建議將鄰局京滬高BSC T7定時器設定為3.5秒[5]。鄰局修改完該參數(shù),經(jīng)過5天的驗證,××高鐵未再出現(xiàn)C3降級,問題完滿解決!
5 結語
該問題的解決,不僅確保了××高鐵的正常運行,更是成功的攻克了跨三個MSC切換的難題,解決了京滬高鐵達速期間發(fā)現(xiàn)但一直沒有解決的北京與某局間長呼失敗的問題,為下一步全路范圍內的GSM-R 網(wǎng)絡改造提供了參考經(jīng)驗。
參考文獻
[1]劉人鵬,袁煥靖.基于GSM-R無線網(wǎng)絡實現(xiàn)車-地通信的CTCS-3級列控系統(tǒng)分析[J].鐵道通信信號,2010,46(10):9-12.
[2]中華人民共和國鐵道部,CTCS-3級列控系統(tǒng)總體技術方案[M].北京:中國鐵道出版社,2011.
Research on Cross three MSC handover leads to probabilistic degradation
REN Meng-xi
(Shanghai communication section of China Railway Shanghai Bureau Group Co., Ltd. Shanghai 200071)
Abstract: In this paper, the problem of CTCS-3 wireless connection timeout caused by probabilistic handover failure across three MSCs after a bureau * high-speed railway BSC access to the newly established MSC is analyzed in depth, and the root causes of the problem are found and the solutions are proposed. During the operation of XX high-speed railway, when the train passes through the NSC switching area, the MSC switching failure occasionally occurs across the area, resulting in the interruption of vehicle-ground communication and the failure of CTCS-3 train control system. Through data collection and fault analysis, it is determined that the fault is caused by communication link response timeout. Solutions are put forward for the cause of the fault to eliminate the failure of train inter-zone operation switching.
Keywords: MSC switch;CTCS-3 wireless connection timeout;T7 timer