2. 列车注册与会话管理相关协议栈概览

要理解列车注册与会话管理，不能只盯着“注册成功”或“会话建立”这两个结果，而要先看清它们发生在哪一层、依赖哪些协议、各层之间如何分工。CTCS-3级系统是一个典型的“地面集中控制 + 车地无线闭环”的安全相关系统，列车注册与会话管理横跨车载设备、无线传输网络和地面无线闭塞中心（RBC），其协议栈可以概括为：安全通信协议负责“可信通道”，应用层协议负责“业务语义”，二者叠加在CTCS-3系统架构之上共同支撑注册与会话。

一、CTCS-3级系统架构中的通信角色

CTCS-3级系统由车载子系统和地面子系统两大部分构成。车载侧核心设备是车载安全计算机（ATP主机），它通过应答器接收线路静态数据，通过轨道电路或应答器获取列车占用与位置信息，并通过无线通信单元（通常经GSM-R或铁路专用无线网络）与地面RBC建立双向数据连接。地面侧核心是RBC，它掌握管辖范围内的进路、临时限速、线路状态等信息，向车载设备发送行车许可（MA）。此外还有联锁、调度集中（CTC）、临时限速服务器（TSRS）等系统，它们通过信号安全数据网与RBC交互，但不直接参与车地会话。

从注册与会话的角度看，真正需要关注的是三个角色：车载ATP（发起注册与会话建立的一方）、RBC（接受注册、管理会话的一方）、以及无线传输通道（承载数据但本身不保证安全完整性）。理解这一点很关键：无线网络只负责“把字节送到”，而“这些字节是否可信、是否被篡改、是否重复”由安全通信协议解决；“这些字节代表什么业务含义、在什么状态下允许发送”由应用层协议解决。

二、RBC与车载设备的通信接口

车地之间的通信接口在逻辑上是一个双向、面向连接的数据通道。车载侧由无线通信单元完成空中接口接入，经铁路专用网络到达RBC的通信接口设备，再进入RBC的应用处理。这个接口有几个工程上必须注意的特征。

第一，连接是有状态的。列车注册本质上是在RBC侧建立一条与该列车标识（如车次号、车载设备编号）绑定的会话记录，记录中保存列车位置、运行方向、通信地址、安全层密钥上下文等信息。会话建立后，RBC才能向该列车发送行车许可；会话一旦中断或超时，RBC必须停止向该列车发送新的MA，避免对“失联列车”继续授权。

第二，接口地址与端口是配置项。车载侧需要配置目标RBC的IP地址和端口号，RBC侧需要配置可接受的车载标识范围。实际工程中常见的问题是：车载配置的RBC地址与列车当前所在管辖区的RBC不一致，导致注册请求发到了错误的RBC，表现为“注册无响应”。因此注册前必须确认列车位置与RBC管辖边界的关系。

第三，接口对时延和丢包敏感但可容忍一定波动。安全通信协议通常带有超时重传和序列号机制，短时丢包可以通过重传恢复；但若无线链路频繁切换或长时间中断，会话会因超时被判定失效，需要重新注册。这也是为什么注册与会话管理必须与“通信状态监视”联动，而不能一次性建立后就不管。

三、安全通信协议与应用层协议的关系

这是本节最容易被混淆的地方。可以用一句话概括：安全通信协议是“信封和封条”，应用层协议是“信的内容”。

安全通信协议工作在应用层消息之下、传输层之上，典型职责包括：通信双方的身份认证（确认对端确实是合法的RBC或车载设备）、消息加密（防止窃听）、消息完整性校验（防止篡改）、序列号与防重放（防止旧消息被重复注入）。它不关心消息里写的是“注册请求”还是“行车许可”，只保证这段字节从一端到另一端是可信的、未被篡改的、新鲜的。

应用层协议则定义业务消息的类型、字段、交互顺序和状态约束。例如注册过程中，车载发送注册请求，RBC返回注册确认或拒绝；会话建立后，RBC周期性发送状态信息，车载回复确认；列车越过RBC管辖边界时，还要进行RBC切换（交接）相关的会话迁移。这些“谁先发、谁后发、什么状态下允许发”的规则，全部属于应用层。

二者的协作关系可以这样理解：应用层产生一条业务消息，交给安全层封装成安全数据单元，再经传输层发送；接收端先由安全层解封、校验、解密，确认可信后才把业务消息交给应用层处理。如果安全层校验失败，应用层根本看不到这条消息，也就不会产生任何业务动作。因此，注册失败有时是应用层原因（如标识不合法、RBC拒绝），有时是安全层原因（如认证失败、密钥不匹配），排障时必须先分层定位。

四、一次注册与会话建立的协议栈视角

把上述分层落到一次典型注册过程上，可以看到协议栈各层的分工。以下参数为教学示例，用于说明流程与判断依据，不代表实际线路配置。

示例场景（教学假设）：
车载标识：T-1001    目标RBC：RBC-A（IP 10.20.1.10，端口 5000）
无线链路：正常，往返时延约 80 ms

步骤1  传输层：车载与 RBC-A 建立 TCP 连接（三次握手成功）
步骤2  安全层：双方交换认证信息，协商会话密钥，认证通过
步骤3  应用层：车载发送“注册请求”，携带车载标识与当前位置
步骤4  应用层：RBC-A 校验标识与管辖范围，返回“注册确认”
步骤5  应用层：会话进入激活状态，RBC 开始周期性发送状态/MA
判断依据：车载显示注册成功且能持续收到 RBC 消息，即会话正常

在这个示例中，如果步骤1失败，问题在无线网络或地址配置；如果步骤2失败，问题在证书、密钥或安全层参数；如果步骤3、4失败，问题在应用层标识或RBC管辖逻辑。分层定位的价值就在这里：同一句“注册不上”，背后的原因可能分布在三个完全不同的层次。

五、需要建立的几个基本认识

• 注册不等于会话持续有效。注册成功只是建立了会话的起点，后续还需要周期性消息维持会话；超时未收到对端消息，会话会被判定失效。
• 安全层不替代应用层。安全层保证消息可信，但不能保证业务逻辑正确；应用层必须自己做状态检查和参数校验。
• RBC管辖边界影响注册目标。列车位置决定应向哪个RBC注册，跨边界时涉及会话迁移，不能简单理解为“重新注册一次”。
• 协议栈是排障的地图。遇到注册或会话异常，按传输层、安全层、应用层自下而上逐层确认，比盲目重启设备更有效。

掌握这一协议栈分层关系，是后续学习注册消息具体字段、会话状态机以及RBC切换流程的基础。只有先分清“哪一层负责什么”，才能在面对实际车地通信问题时，快速判断问题出在链路、安全还是业务逻辑上。