CCC联盟数字车钥匙（四）——UWB MAC协议

本篇文章介绍CCC协议中关于UWB消息流，以及相关会话设置及控制消息的配置。

5、MAC协议

5.1 测距交换序列

本节介绍DK MAC层协议，针对双边双向测距方法（DS-TWR），协调器和Responder之间的数据交换方式。

图中关于SP0、SP3数据帧已经在前文中进行介绍,RFRAME为Ranging Frame的简写，测距帧。
对于测距过程中，每个信息对应的时隙按照下表方式定义：

若$N_{Slot\_per\_Round}^k$数量大于实际需要发送的数据包的数量，对于Final_Data后的时隙暂不使用。

MAC协议序列在正常的操作模式下（发起者和响应者设备都工作在一个活跃的测距会话中）。
关于SP0的Pre-POLL与Final-Data帧相关数据结构示意如下。

typedef struct
{
    uint32_t uwb_session_id;
    uint32_t poll_sts_index;
    uint16_t ranging_block;
    uint8_t  hop_flag;
    uint16_t round_index;
}uwb_msg_pre_poll_t;

typedef struct 
{
    uint8_t responder_index;
    uint32_t ranging_ts_resp_rstu; /* timestamp between POLL and RESPONSE */
    uint8_t ts_uncertainty;  /* range of values from 1.5cm-3.6m various confidences */
    uint8_t status;
}uwb_msg_responder_final_t;

#define FINAL_RESPONDER_MAX  (10)

typedef struct
{
    uint32_t uwb_session_id;
    uint16_t ranging_block;
    uint8_t hop_flag;
    uint16_t round_index;
    uint32_t final_sts_index;
    uint32_t ranging_ts_final_tx_rstu;
    uint8_t responder_num;
    usb_msg_responder_final_t responder_list[FINAL_RESPONDER_MAX];
}uwb_msg_final_data_t;

上述代码只是简单对PRE-POLL以及FINAL-DATA数据帧的封装，其中关于时间戳均为相对于POLL的时间长度，所以整个时间长度只用了4个字节，同时这里时间戳均用’*_rstu’结尾，表示为测距时间单位，时间戳单位为15.65ps。

具体数据帧则还需要按照IEEE 802.15.4a/z的数据传输格式进行封装，相关Payload段还需要进行加密处理。

在测距过程中，若协调器没有收到任何应答帧，那么Final Message和Final_Data包将忽略。
同时，协调器和responder都应该触发hopping（如果使用adaptive hopping模式）。
Frame Counter不应该增加，由于忽略了Final Data包。

如果没有收到有效响应，但是又为该响应添加了时间戳数据，那么时间戳数据的值应为0。

对于Final_Data消息的最大长度为127字节，Final_Data帧的Payload字段数据量 = 18 + 7*N_responder。
技术规范中，最大支持Responder数量为10。如果车辆的responders数量超过10，则车辆应将参与每个测距轮次的响应者数量设置为小于9或等于10的值，在测距会话设置的流程中。具体哪些responder参与测距，由车辆来决定（responder-device）。
在实现中，超过最大支持Responder数量时，还可以增加额外的Final_Data帧，传后续的Responder的信息。（当然，CCC规范中，并未如此支持）。

5.2 测距会话设置

本节介绍了如何在发起方和响应方设备之间执行MAC参数协商的流程：

首先，应答设备和协调器应通过BLE链路执行测距能力交换，responder-device发送RC-RQ（测距能力请求消息）到协调器，协调器应答RC-RS。一旦信息交换成功，接下来的协商步骤将通过BLE控制来设置测距会话。

部分流程以及实现可以结合CCC规范《第19章 BLE接口》一起来实现（部分略）。

另外，在CCC规范中，$N_{Chap\_per\_Slot}^k=8$是一个强制值，所有的设备都应该能够支持（约2.64ms周期，可能相对来说是比较宽裕的一个时隙长度）。通过设置强制值，也避免了设备之间达不成共识，即无法统一时隙长度。

5.3 MAC控制通道

MAC控制信道（通过BLE）的实现应符合以下要求：

1. 控制信道应科用于协商或重新协商UWB参数（如测距会话设置）。
2. 控制信道应是会话特定的，应在会话开始之前、会话的整个生命周期、以及测距会话终止之后。
3. RAN应具有与其响应器设备一样多的UWB控制信道。
4. 控制信道应通过BLE连接进行传输。
5. 关于第k个测距会话的控制业务应当用$UWB\_Session\_I{D}^k$。
6. 在一个活跃测距会话的时序，应通过该测距会话的适当时间网络切片（如block index，round index， slot index或 mapped STS切片）来参考。
7. 控制信道应由BLE L2CAP信道的Channel ID触发。协调器或响应者设备可以触发控制信道，并且可以请求UWB参数的变更。

5.4 UWB MAC配置

所有发送的SP0类型的包都需要根据MAC层协议，包含MAC Header（MHR），MAC Payload以及MAC Footer（MFR）字段。本节描述了SP0包的构成。

MHR(23 Octets)	MAC Payload	MFR (2 Octets)

其中，MAC Payload除包含有效载荷外，还需要增加8字节的MIC，因而Final_Data仅支持10个Responder信息。

关于MHR相关字段定义如下：

其中，关于辅助安全报头（Auxiliary Security Header）定义如下：

需要注意，辅助安全报头与SP3包（POLL与Final消息）无关，因为SP3包没有携带MAC数据帧（没有物理层载荷），没有payload、MHR和MFR。（均为小端格式）

关于供应商特定的Header IE如下：

可以看到，供应商自定义信息中，用1个字节来表明数据帧的类型，0x1为Pre-POLL消息，0x2为Final Data消息。

---

持续更新，系列教程，收藏关注吧！

1、CCC联盟——UWB PHY
2、CCC联盟（一）——UWB MAC概述
3、CCC联盟数字车钥匙（二）——UWB MAC时间网格
4、CCC联盟数字车钥匙（三）——UWB MAC时间网格同步及Hopping