帧逆序触发帧拒绝引起无线超时简析

梅 靖

（中国铁路上海局集团有限公司上海通信段, 上海 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无线通信机制进行完善，以确保能够尽快实现强基达标的可持续发展目标。