第四章 MAC层与RLC层:逻辑信道与传输信道映射、MAC PDU格式解析、RLC分段与重组机制、ARQ重传流程

各位好,我是老张。今天咱们聊聊V2X协议栈里最核心的两个层——MAC层和RLC层。说实话,我刚开始做V2X测试那会儿,最头疼的就是这两个层。逻辑信道和传输信道怎么映射?MAC PDU长什么样?RLC分段又是怎么回事?

嗯,别急。咱们一个一个来拆解。

4.1 逻辑信道与传输信道映射

先问个问题:为什么要有逻辑信道和传输信道的区分?

我个人习惯这么理解——逻辑信道是“上层想要什么”,传输信道是“物理层能传什么”。MAC层夹在中间,就是个翻译官。

在V2X里,逻辑信道主要分两类:

  • 控制信道(CCCH/DCCH):传RRC信令,比如连接建立、资源分配
  • 业务信道(DTCH):传真正的V2X数据,比如BSM、CAM、DENM

传输信道呢?V2X场景下主要用SL-SCH(直连链路共享信道)。

映射关系其实很简单:

逻辑信道类型 映射到传输信道 典型用途
DTCH(直连业务信道) SL-SCH V2X应用数据
DCCH(直连控制信道) SL-SCH RRC信令
STCH(直连流量信道) SL-SCH V2X专用短消息
我的经验: 测试时最容易出问题的是逻辑信道优先级。V2X里安全消息优先级高,但有些设备会把控制信令和业务信道混在一起调度。我曾经遇到过一台设备,BSM消息被RRC信令堵在队列里,延迟直接飙到200ms以上。后来查出来是MAC调度器没按逻辑信道优先级处理。

4.2 MAC PDU格式解析

MAC PDU,说白了就是MAC层打包后的数据单元。你想想看,上层下来的RLC PDU到了MAC层,MAC得给它加个头,告诉接收方“这是谁的数据、优先级多高、要不要重传”。

标准格式长这样:

MAC PDU = MAC头 + MAC SDU(来自RLC层)

MAC头结构:
- SL-SCH子头(每个逻辑信道一个)
  - LCID(逻辑信道ID):5 bits
  - L(长度字段):8/16 bits
  - F(格式指示):1 bit
  - E(扩展指示):1 bit
- 可选:MAC CE(控制元素)

这里有个坑——LCID的分配。V2X里LCID 0-3是保留给控制信令的,4-10给V2X业务信道。我见过有厂商把BSM消息配到LCID=1上,结果接收端解析时当成RRC信令处理,直接丢包。

避坑指南: 我曾经在测试中发现,某款OBU的MAC PDU里L字段长度算错了。它传了一个1500字节的SDU,但L字段只写了1024。接收端解析到一半就截断了,数据全乱码。后来定位到是MAC层没考虑RLC头部的开销。记住:L字段是SDU的实际长度,不是PDU总长度。

4.3 RLC分段与重组机制

RLC层,我习惯叫它“裁缝”。上层下来的数据包可能很大(比如一个完整的BSM消息可能超过1500字节),但物理层一次只能传有限的数据。RLC就得把大包切成小段,接收端再拼回去。

V2X里RLC工作在UM模式(非确认模式)或AM模式(确认模式)。安全消息一般用UM,因为延迟要求高,重传来不及。文件传输类用AM,保证完整性。

分段流程:

  1. RLC收到上层SDU,检查大小
  2. 如果SDU > 当前可用的传输块大小,就切分
  3. 每个分段加上RLC头(包含SN序号、分段偏移、是否最后一个分段标志)
  4. 发送给MAC层

重组流程:

  1. 接收端收到RLC PDU,检查SN序号
  2. 根据分段偏移和标志位,判断是否完整
  3. 所有分段到齐后,按顺序拼接成完整SDU
  4. 递交给上层
关键参数: - SN长度:UM模式用6 bits(0-63),AM模式用10 bits(0-1023) - 分段偏移:以字节为单位,指示该分段在原始SDU中的起始位置 - 轮询位(P bit):AM模式下,发送端请求接收端反馈状态报告

我记得有一次测试,发现接收端总是重组失败。查了半天,原来是发送端的分段偏移算错了。它把第一个分段偏移设为0,第二个设为100,但实际第一个分段只有80字节。第二个分段应该从80开始才对。这种低级错误,说白了就是代码里没处理好边界条件。

4.4 ARQ重传流程

ARQ,自动重传请求。V2X里主要用RLC层的ARQ,不是MAC层的HARQ。为什么?因为HARQ是物理层快速重传,延迟低但只能纠一次错。RLC ARQ是端到端的,可以多次重传,保证数据最终到达。

流程其实不复杂:

  • 发送端:发送RLC PDU后,启动重传定时器(t-PollRetransmit)。如果定时器超时还没收到确认,就重传。
  • 接收端:收到PDU后,检查SN序号。如果发现丢包(比如收到SN=5,但没收到SN=4),就发送状态报告,告诉发送端“我缺了4号包”。
  • 发送端:收到状态报告后,重传缺失的PDU。

这里有个细节——状态报告触发条件

  1. 收到发送端的轮询请求(P bit=1)
  2. 检测到接收窗口内的丢包
  3. 定时器t-StatusProhibit超时(防止频繁发送状态报告)
我的建议: 测试ARQ时,重点关注两个定时器:t-PollRetransmit和t-StatusProhibit。前者设太短会导致频繁重传,浪费资源;设太长又会影响延迟。V2X场景下,我一般建议t-PollRetransmit设50ms,t-StatusProhibit设20ms。当然,具体要看你的应用场景。

你可能会问:ARQ重传会不会导致数据乱序?会的。所以RLC层有重排序机制。接收端维护一个接收窗口,收到的PDU按SN序号排序,只有连续的PDU才能递交给上层。不连续的PDU先缓存,等缺失的包到了再一起递交。

嗯,这里要特别注意——接收窗口大小。UM模式下窗口大小是SN空间的一半(比如SN=6 bits,窗口大小32)。AM模式下可以配置,但一般不超过SN空间的一半。窗口设太大,接收端缓存压力大;设太小,容易触发不必要的重传。

最后说一句:MAC层和RLC层是V2X协议栈的“腰”,腰不好,上层再好的应用也白搭。我见过太多设备,应用层写得花里胡哨,但MAC/RLC层一测就崩。所以,测试时一定要把这两层的参数调透,尤其是逻辑信道优先级、分段大小、重传定时器这些。

好了,今天就到这儿。下一章咱们聊PDCP层和SDAP层,看看数据是怎么加密和QoS映射的。