APP下载

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

2022-02-11

铁路通信信号工程技术 2022年1期
关键词:字段车载比特

梅 靖

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

猜你喜欢

字段车载比特
一种车载可折叠宿营住房
带钩或不带钩选择方框批量自动换
捷豹I-PACE纯电动汽车高压蓄电池充电系统(三)
浅谈台湾原版中文图书的编目经验
奔驰S级48V车载电气系统(下)
比特币还能投资吗
比特币分裂
SA2型76毫米车载高炮多视图
比特币一年涨135%重回5530元
无正题名文献著录方法评述