幀逆序觸發(fā)幀拒絕引起無(wú)線超時(shí)簡(jiǎn)析

梅 靖

（中國(guó)鐵路上海局集團(tuán)有限公司上海通信段, 上海 200080）

1 概述

隨著C3無(wú)線超時(shí)分析工作的不斷深入，加之車載空口、基站空口、接口監(jiān)測(cè)業(yè)務(wù)信令流程監(jiān)測(cè)的普及，之前部分無(wú)法明確分析的C3無(wú)線超時(shí)已經(jīng)能夠準(zhǔn)確分析原因并準(zhǔn)確定位故障點(diǎn)。本文以一次RBC側(cè)發(fā)送Z=1的FRMR幀導(dǎo)致的C3無(wú)線超時(shí)為例，對(duì)C3無(wú)線超時(shí)故障分析流程進(jìn)行說(shuō)明。

2 C3無(wú)線超時(shí)分類及幀拒絕說(shuō)明

2.1 C3無(wú)線超時(shí)分類

C3無(wú)線超時(shí)故障目前主要以故障發(fā)生點(diǎn)進(jìn)行分類，主要分為車載側(cè)、地面?zhèn)燃霸虿幻鞯取７治霾煌收蠒r(shí)所需要的數(shù)據(jù)及分析方法不同，本文將重點(diǎn)介紹車載側(cè)或RBC側(cè)發(fā)送FRMR導(dǎo)致C3無(wú)線超時(shí)故障的分析方法及分析流程。

2.2 FRMR幀結(jié)構(gòu)

C3列控系統(tǒng)車載設(shè)備與RBC通過(guò)HDLC幀進(jìn)行數(shù)據(jù)交互，HDLC幀包括S幀、U幀和I幀3類。HDLC幀由頭尾標(biāo)志序列、地址位、控制位、信息和幀校驗(yàn)序列等字段組成。HDLC幀基本結(jié)構(gòu)如表1所示。

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

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

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

各字段意義如下：

1）“被拒絕幀的控制字段”是所接收到的引起拒絕幀的控制字段。當(dāng)被拒絕幀為無(wú)編號(hào)幀時(shí)，被拒絕幀的控制字段應(yīng)位于比特 1～8，而比特9～16置為“0”；

2）“N(S)”是報(bào)告拒絕狀態(tài)的DCE或DTE的當(dāng)前發(fā)送狀態(tài)變量值（比特18為低階比特）；

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

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

5）“W”置“1”表示所接收到的并在比特1～16內(nèi)送回的控制字段沒(méi)有定義或不能實(shí)現(xiàn)；

6）“X”置“1”表示所接收到的并在比特1～16內(nèi)送回的控制字段被認(rèn)為是無(wú)效的，因?yàn)樵搸ú辉试S的信息字段，或該幀是具有不正確長(zhǎng)度（包含長(zhǎng)度32～39 Bit的幀）的監(jiān)控幀。W比特與該比特一起置“1”；

7）“Y”置“1”表示所接收到的信息字段超過(guò)了報(bào)告拒絕狀態(tài)的DTE或 DCE最大設(shè)定容量；

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

9）17和37～40 Bit應(yīng)置成“0”。

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

2.3 FRMR類異常基本分析流程

當(dāng)在接口監(jiān)測(cè)數(shù)據(jù)中發(fā)現(xiàn)RBC側(cè)或車載側(cè)發(fā)送FRMR時(shí)，需根據(jù)W、X、Y、Z字段判斷FRMR的原因指示來(lái)逐步分析。

1)當(dāng)W、X為1時(shí)，表示在發(fā)送FRMR之前，本端收到了對(duì)端發(fā)送的包含無(wú)效或未實(shí)現(xiàn)的控制字段且能通過(guò)CRC校驗(yàn)的數(shù)據(jù)幀。此種情況一般是對(duì)端發(fā)送的數(shù)據(jù)在傳送過(guò)程中因某些因素發(fā)生變化，導(dǎo)致數(shù)據(jù)的控制字段不符合C3通信要求。

2)當(dāng)Y為1時(shí)，表示在發(fā)送FRMR之前，本端收到了對(duì)端發(fā)送的超過(guò)最大長(zhǎng)度且能通過(guò)CRC校驗(yàn)的數(shù)據(jù)幀。此種情況一般是對(duì)端發(fā)送的數(shù)據(jù)在傳送過(guò)程中因某些因素發(fā)生變化，導(dǎo)致接收端接收不到尾部標(biāo)志序列。接收端持續(xù)等待接收到尾部標(biāo)志序列后才停止接收，從而出現(xiàn)超長(zhǎng)數(shù)據(jù)幀。

3)當(dāng)Z為1時(shí)，表示在發(fā)送FRMR之前，本端收到了對(duì)端發(fā)送的包含無(wú)效N(R)且能通過(guò)CRC校驗(yàn)的數(shù)據(jù)幀，無(wú)效N(R)包括序號(hào)逆序或者序號(hào)跳變兩種情況。

其中W、X、Y為1時(shí)，需要結(jié)合ISDN日志數(shù)據(jù)或車載側(cè)Igsm-r接口的數(shù)據(jù)來(lái)判斷RBC或車載側(cè)發(fā)送FRMR之前收到的數(shù)據(jù)（由于電臺(tái)、接口監(jiān)測(cè)設(shè)備和ISDN服務(wù)器針對(duì)亂碼數(shù)據(jù)的接收及處理機(jī)制不同，每個(gè)位置呈現(xiàn)出來(lái)的數(shù)據(jù)效果可能有所不同）；當(dāng)Z為1時(shí)，需要通過(guò)Abis、A及PRI接口的業(yè)務(wù)數(shù)據(jù)來(lái)判斷產(chǎn)生逆序或跳變N(R)的位置。

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

3 FRMR典型案例分析說(shuō)明

3.1 故障基本描述

2021年8月27日管內(nèi)某高鐵某次列車因RBC收到逆序RR幀發(fā)送FRMR，導(dǎo)致列車發(fā)生C3無(wú)線超時(shí)。

3.2 某高鐵接口監(jiān)測(cè)系統(tǒng)結(jié)構(gòu)

某高鐵接口監(jiān)測(cè)系統(tǒng)包含Abis、A、PRI及Um接口監(jiān)測(cè)設(shè)備，系統(tǒng)結(jié)構(gòu)示意如圖1所示。

圖1 接口監(jiān)測(cè)系統(tǒng)結(jié)構(gòu)Fig.1 Interface monitoring system structure

與傳統(tǒng)的C3接口監(jiān)測(cè)系統(tǒng)相比，滬杭高鐵的接口監(jiān)測(cè)系統(tǒng)增加了Abis及A接口C3業(yè)務(wù)監(jiān)測(cè)功能。之前在沒(méi)有Abis及A接口業(yè)務(wù)監(jiān)測(cè)功能時(shí)，當(dāng)出現(xiàn)逆序幀或跳變幀觸發(fā)FRMR造成C3無(wú)線超時(shí)的故障均無(wú)法準(zhǔn)確定位。本次故障發(fā)生時(shí)，Abis及A接口均監(jiān)測(cè)到了完整的業(yè)務(wù)數(shù)據(jù)，為本次故障的分析、定位提供充分的支撐。

3.3 分析流程

3.3.1 Abis接口數(shù)據(jù)分析

1）Abis接口信令及切換

根據(jù)本次列車接口監(jiān)測(cè)數(shù)據(jù)顯示，11:01:01.700，在SHHQ-CSXLS03小區(qū)發(fā)起切換，切換原因?yàn)锽etter Cell；11:01:02.281， 完 成 SHHQ-CSXLS03到SHHQ-CSXLS02小區(qū)的切換；11:01:03.146，BSC發(fā)送Disconnect發(fā)起拆鏈，拆鏈原因正常。

2）Abis接口測(cè)量報(bào)告

根據(jù)本次列車測(cè)量報(bào)告，11:00:52至11:01:03，在SHHQ-CSXLS03及SHHQ-CSXLS02小區(qū)（含切換前后），測(cè)量報(bào)告的上下行電平、上下行質(zhì)量、TA及鄰區(qū)電平均正常。

3）Abis接口業(yè)務(wù)數(shù)據(jù)

滬杭高鐵Abis接口采用環(huán)頭、環(huán)尾雙通道同時(shí)傳送數(shù)據(jù)的方式，因此業(yè)務(wù)數(shù)據(jù)包括環(huán)頭及環(huán)尾雙份數(shù)據(jù)。環(huán)頭業(yè)務(wù)數(shù)據(jù)如圖2所示。尾業(yè)務(wù)數(shù)據(jù)如圖3所示。

圖2 Abis接口環(huán)頭業(yè)務(wù)數(shù)據(jù)截圖Fig.2 Screenshot of service data of Abis interface ring head

圖3 Abis接口環(huán)尾業(yè)務(wù)數(shù)據(jù)截圖Fig.3 Screenshot of service data of Abis interface ring tail

由環(huán)頭及環(huán)尾業(yè)務(wù)數(shù)據(jù)截圖可知，Abis接口環(huán)頭、環(huán)尾的業(yè)務(wù)數(shù)據(jù)情況完全一致。

在11:01:01.780到11:01:02.017車載側(cè)依次發(fā)送了N(R)=81～N(R)=84的響應(yīng)幀；在11:01:02.407 RBC側(cè)發(fā)送了FRMR拒絕幀，拒絕幀中指示被拒絕的幀號(hào)為83，拒絕幀類型為Z=1（表示收到了無(wú)效的NR），但在Abis接口的業(yè)務(wù)數(shù)據(jù)中未出現(xiàn)逆序數(shù)據(jù)。

3.3.2 A接口數(shù)據(jù)分析

1）A接口信令及切換

根據(jù)接口監(jiān)測(cè)數(shù)據(jù)顯示，11:01:02.316，完成SHHQ-CSXLS03到SHHQ-CSXLS02小區(qū)的切換；11:01:03.090，MSC發(fā)送Disconnect發(fā)起拆鏈，拆鏈原因正常。

2）A接口業(yè)務(wù)數(shù)據(jù)

A接口業(yè)務(wù)數(shù)據(jù)如圖4所示。

圖4 A接口業(yè)務(wù)數(shù)據(jù)截圖Fig.4 Screenshot of the A interface service data

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

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

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

3.3.3 PRI接口數(shù)據(jù)分析

PRI接口數(shù)據(jù)如圖5、6所示。

圖5 PRI接口第一部分?jǐn)?shù)據(jù)截圖Fig.5 Screenshot of the first part of the PRI interface data

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

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

圖6 PRI接口第二部分?jǐn)?shù)據(jù)截圖Fig.6 Screenshot of the second part of the PRI interface data

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

在11:01:03.077，RBC側(cè)發(fā)送Discconnect拆鏈，拆鏈原因?yàn)?6（正常拆鏈）。

3.3.4 綜合分析

綜合Abis、A及PRI接口的信令及業(yè)務(wù)數(shù)據(jù)情況，SHHQ-CSXLS03到SHHQ-CSXLS02的小區(qū)切換正常、切換前后測(cè)量報(bào)告正常，Abis、A及PRI接口信令層面拆鏈原因正常。

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

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

3.4 分析結(jié)論

根據(jù)綜合分析結(jié)果可知，本次RBC側(cè)發(fā)送FRMR是因?yàn)镽BC側(cè)收到了重復(fù)發(fā)送的N(R)=83的RR幀，重復(fù)的RR幀只在A接口及PRI出現(xiàn)，在Abis接口的環(huán)頭、環(huán)尾均未出現(xiàn)，因此判斷本次重復(fù)發(fā)送的N(R)=83的RR幀是切換過(guò)程中BSC/TRAU導(dǎo)致的。結(jié)合設(shè)備廠家底層數(shù)據(jù)分析，初步判斷BSC/TRAU重發(fā)數(shù)據(jù)的原因如下。

1）在切換過(guò)程中，TRAU需要與新基站重新校對(duì)TRAU消息。如果相鄰基站的時(shí)鐘精度存在較大差異，使得TRAU與新基站之間的TRAU幀ALIGNMENT的時(shí)間較長(zhǎng)。

2）當(dāng)TRAU側(cè)發(fā)送完“N（R）=83”數(shù)據(jù)后，在既定時(shí)間內(nèi)，沒(méi)有收到或無(wú)法解析出下一組的TRAU幀信息，TRAU不得不將緩存中保留的上一幀業(yè)務(wù)填充到當(dāng)前業(yè)務(wù)信道中，從而導(dǎo)致故障現(xiàn)象表現(xiàn)為：TRAU重發(fā)了兩次“N（R）=83”的數(shù)據(jù)。

4 總結(jié)及建議

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

C3列控系統(tǒng)車地間業(yè)務(wù)數(shù)據(jù)交互遵循的是20世紀(jì)90年代制定的標(biāo)準(zhǔn)規(guī)范，其部分條款與國(guó)內(nèi)高鐵的實(shí)際情況不甚相符，對(duì)國(guó)內(nèi)高鐵的運(yùn)行效率有一定影響。后續(xù)還需各設(shè)備廠家針對(duì)國(guó)內(nèi)的實(shí)際情況，對(duì)車地間C3無(wú)線通信機(jī)制進(jìn)行完善，以確保能夠盡快實(shí)現(xiàn)強(qiáng)基達(dá)標(biāo)的可持續(xù)發(fā)展目標(biāo)。