CCC联盟数字车钥匙（四）——UWB MAC协议-编程知识

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

5、MAC协议

5.1 测距交换序列

本节介绍DK MAC层协议，针对双边双向测距方法（DS-TWR），协调器和Responder之间的数据交换方式。
MAC协议消息流
图中关于SP0、SP3数据帧已经在前文中进行介绍,RFRAME为Ranging Frame的简写，测距帧。
对于测距过程中，每个信息对应的时隙按照下表方式定义：
在这里插入图片描述
若 $N^k_{Slot\_per\_Round}$ 数量大于实际需要发送的数据包的数量，对于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^k_{Chap\_per\_Slot}=8$ 是一个强制值，所有的设备都应该能够支持（约2.64ms周期，可能相对来说是比较宽裕的一个时隙长度）。通过设置强制值，也避免了设备之间达不成共识，即无法统一时隙长度。

5.3 MAC控制通道

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

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