幀逆序觸發幀拒絕引起無線超時簡析

梅 靖

（中國鐵路上海局集團有限公司上海通信段, 上海 200080）

1 概述

隨著C3無線超時分析工作的不斷深入，加之車載空口、基站空口、接口監測業務信令流程監測的普及，之前部分無法明確分析的C3無線超時已經能夠準確分析原因并準確定位故障點。本文以一次RBC側發送Z=1的FRMR幀導致的C3無線超時為例，對C3無線超時故障分析流程進行說明。

2 C3無線超時分類及幀拒絕說明

2.1 C3無線超時分類

C3無線超時故障目前主要以故障發生點進行分類，主要分為車載側、地面側及原因不明等。分析不同故障時所需要的數據及分析方法不同，本文將重點介紹車載側或RBC側發送FRMR導致C3無線超時故障的分析方法及分析流程。

2.2 FRMR幀結構

C3列控系統車載設備與RBC通過HDLC幀進行數據交互，HDLC幀包括S幀、U幀和I幀3類。HDLC幀由頭尾標志序列、地址位、控制位、信息和幀校驗序列等字段組成。HDLC幀基本結構如表1所示。

表1 HDLC幀格式-擴充（模128）操作Tab.1 HDLC frame format-Expanded (mode 128) operation

FRMR幀屬于U幀，其信息字段的具體組成如表2所示。

表2 FRMR幀信息字段-擴充（模128）操作Tab.2 FRMR frame information field-expanded (mode 128) operation

各字段意義如下：

1）“被拒絕幀的控制字段”是所接收到的引起拒絕幀的控制字段。當被拒絕幀為無編號幀時，被拒絕幀的控制字段應位于比特 1～8，而比特9～16置為“0”；

2）“N(S)”是報告拒絕狀態的DCE或DTE的當前發送狀態變量值（比特18為低階比特）；

3）“C/R”置為“1”表示被拒絕的幀是響應幀，C/R 置為“0”表示被拒絕的幀是命令幀；

4）“N(R)”是報告拒絕狀態的DCE或 DTE的當前接收狀態變量值（比特26為低階比特）；

5）“W”置“1”表示所接收到的并在比特1～16內送回的控制字段沒有定義或不能實現；

6）“X”置“1”表示所接收到的并在比特1～16內送回的控制字段被認為是無效的，因為該幀包括不允許的信息字段，或該幀是具有不正確長度（包含長度32～39 Bit的幀）的監控幀。W比特與該比特一起置“1”；

7）“Y”置“1”表示所接收到的信息字段超過了報告拒絕狀態的DTE或 DCE最大設定容量；

8）“Z”置“1”表示所接收到的并在比特1～16內送回的控制字段包括無效的N(R)；

9）17和37～40 Bit應置成“0”。

FRMR響應的信息字段中W、X、Y和Z比特可都置成“0”，用以指示上面未列出的一種或多種狀態所引起的幀拒絕。

2.3 FRMR類異常基本分析流程

當在接口監測數據中發現RBC側或車載側發送FRMR時，需根據W、X、Y、Z字段判斷FRMR的原因指示來逐步分析。

1)當W、X為1時，表示在發送FRMR之前，本端收到了對端發送的包含無效或未實現的控制字段且能通過CRC校驗的數據幀。此種情況一般是對端發送的數據在傳送過程中因某些因素發生變化，導致數據的控制字段不符合C3通信要求。

2)當Y為1時，表示在發送FRMR之前，本端收到了對端發送的超過最大長度且能通過CRC校驗的數據幀。此種情況一般是對端發送的數據在傳送過程中因某些因素發生變化，導致接收端接收不到尾部標志序列。接收端持續等待接收到尾部標志序列后才停止接收，從而出現超長數據幀。

3)當Z為1時，表示在發送FRMR之前，本端收到了對端發送的包含無效N(R)且能通過CRC校驗的數據幀，無效N(R)包括序號逆序或者序號跳變兩種情況。

其中W、X、Y為1時，需要結合ISDN日志數據或車載側Igsm-r接口的數據來判斷RBC或車載側發送FRMR之前收到的數據（由于電臺、接口監測設備和ISDN服務器針對亂碼數據的接收及處理機制不同，每個位置呈現出來的數據效果可能有所不同）；當Z為1時，需要通過Abis、A及PRI接口的業務數據來判斷產生逆序或跳變N(R)的位置。

下面以滬杭高鐵一次RBC發送Z=1的FRMR幀為例，詳細介紹該類故障的分析流程。

3 FRMR典型案例分析說明

3.1 故障基本描述

2021年8月27日管內某高鐵某次列車因RBC收到逆序RR幀發送FRMR，導致列車發生C3無線超時。

3.2 某高鐵接口監測系統結構

某高鐵接口監測系統包含Abis、A、PRI及Um接口監測設備，系統結構示意如圖1所示。

圖1 接口監測系統結構Fig.1 Interface monitoring system structure

與傳統的C3接口監測系統相比，滬杭高鐵的接口監測系統增加了Abis及A接口C3業務監測功能。之前在沒有Abis及A接口業務監測功能時，當出現逆序幀或跳變幀觸發FRMR造成C3無線超時的故障均無法準確定位。本次故障發生時，Abis及A接口均監測到了完整的業務數據，為本次故障的分析、定位提供充分的支撐。

3.3 分析流程

3.3.1 Abis接口數據分析

1）Abis接口信令及切換

根據本次列車接口監測數據顯示，11:01:01.700，在SHHQ-CSXLS03小區發起切換，切換原因為Better Cell；11:01:02.281， 完 成 SHHQ-CSXLS03到SHHQ-CSXLS02小區的切換；11:01:03.146，BSC發送Disconnect發起拆鏈，拆鏈原因正常。

2）Abis接口測量報告

根據本次列車測量報告，11:00:52至11:01:03，在SHHQ-CSXLS03及SHHQ-CSXLS02小區（含切換前后），測量報告的上下行電平、上下行質量、TA及鄰區電平均正常。

3）Abis接口業務數據

滬杭高鐵Abis接口采用環頭、環尾雙通道同時傳送數據的方式，因此業務數據包括環頭及環尾雙份數據。環頭業務數據如圖2所示。尾業務數據如圖3所示。

圖2 Abis接口環頭業務數據截圖Fig.2 Screenshot of service data of Abis interface ring head

圖3 Abis接口環尾業務數據截圖Fig.3 Screenshot of service data of Abis interface ring tail

由環頭及環尾業務數據截圖可知，Abis接口環頭、環尾的業務數據情況完全一致。

在11:01:01.780到11:01:02.017車載側依次發送了N(R)=81～N(R)=84的響應幀；在11:01:02.407 RBC側發送了FRMR拒絕幀，拒絕幀中指示被拒絕的幀號為83，拒絕幀類型為Z=1（表示收到了無效的NR），但在Abis接口的業務數據中未出現逆序數據。

3.3.2 A接口數據分析

1）A接口信令及切換

根據接口監測數據顯示，11:01:02.316，完成SHHQ-CSXLS03到SHHQ-CSXLS02小區的切換；11:01:03.090，MSC發送Disconnect發起拆鏈，拆鏈原因正常。

2）A接口業務數據

A接口業務數據如圖4所示。

圖4 A接口業務數據截圖Fig.4 Screenshot of the A interface service data

在11:01:01.818到11:01:02.055車載側依次發送了N(R)=81～N(R)=84的響應幀。

在11:01:02.074和11:01:02.116車載側兩次重復發送了N(R)=83的RR幀。

在11:01:02.360 RBC側發送了FRMR拒絕幀，拒絕幀中指示的幀號為83，拒絕幀類型為Z=1（表示收到無效的N(R)）。

3.3.3 PRI接口數據分析

PRI接口數據如圖5、6所示。

圖5 PRI接口第一部分數據截圖Fig.5 Screenshot of the first part of the PRI interface data

在11:01:01.952到11:01:02.155車載側依次發送了N(R)=81～N(R)=84的響應幀。

在11:01.02.171和11:01:02.218車載側兩次重復發送了N(R)=83的RR幀。

圖6 PRI接口第二部分數據截圖Fig.6 Screenshot of the second part of the PRI interface data

在11:01.02.405 RBC側發送了FRMR拒絕幀，拒絕幀中指示的幀號為83，拒絕幀類型為Z=1（表示收到無效的N(R)）。

在11:01:03.077，RBC側發送Discconnect拆鏈，拆鏈原因為16（正常拆鏈）。

3.3.4 綜合分析

綜合Abis、A及PRI接口的信令及業務數據情況，SHHQ-CSXLS03到SHHQ-CSXLS02的小區切換正常、切換前后測量報告正常，Abis、A及PRI接口信令層面拆鏈原因正常。

Abis、A及PRI接口均收到車載側發送的N(R)=81～N(R)=84的RR幀以及RBC側發送的拒絕N(R)=83號幀的FRMR幀。

Abis接口沒有收到重復發送的N(R)=83的RR幀，A及PRI接口收到了重復發送的N(R)=83的RR幀。

3.4 分析結論

根據綜合分析結果可知，本次RBC側發送FRMR是因為RBC側收到了重復發送的N(R)=83的RR幀，重復的RR幀只在A接口及PRI出現，在Abis接口的環頭、環尾均未出現，因此判斷本次重復發送的N(R)=83的RR幀是切換過程中BSC/TRAU導致的。結合設備廠家底層數據分析，初步判斷BSC/TRAU重發數據的原因如下。

1）在切換過程中，TRAU需要與新基站重新校對TRAU消息。如果相鄰基站的時鐘精度存在較大差異，使得TRAU與新基站之間的TRAU幀ALIGNMENT的時間較長。

2）當TRAU側發送完“N（R）=83”數據后，在既定時間內，沒有收到或無法解析出下一組的TRAU幀信息，TRAU不得不將緩存中保留的上一幀業務填充到當前業務信道中，從而導致故障現象表現為：TRAU重發了兩次“N（R）=83”的數據。

4 總結及建議

C3列控系統車地間無線通信由GSM-R網絡承載，在數據傳輸過程中涉及的接口較多，為了能準確分析、定位每一件C3無線超時故障，還需不斷完善監測手段，以便為C3無線超時分析提供支撐。同時，為了進一步提高故障分析效率，各路局及相關廠家也在逐步完善監測及分析系統的功能，使故障分析工作逐步向智能化、自動化方向發展，且故障分析的準確率也在日益提升。

C3列控系統車地間業務數據交互遵循的是20世紀90年代制定的標準規范，其部分條款與國內高鐵的實際情況不甚相符，對國內高鐵的運行效率有一定影響。后續還需各設備廠家針對國內的實際情況，對車地間C3無線通信機制進行完善，以確保能夠盡快實現強基達標的可持續發展目標。