CCC联盟——UWB MAC（一）

本文主要是介绍CCC联盟——UWB MAC（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本文在前面已经介绍了相关UWB的PHY之后，重点介绍数字钥匙（Digital Key）中关于MAC层的相关实现规范。由于MAC层相应涉及内容比较多，本文首先从介绍UWB MAC的整体框架，后续陆续介绍相关的网络、协议等内容。

1、UWB MAC架构

1、测距角色定义

在Digital Key UWB测距服务中，测距设备（Ranging Device, RD)的角色基于由哪个设备开启测距的流程以及对设定测距交换过程负责。

以下角色定义仅应用到UWB层：
1）负责启动UWB测距包交换（UWB ranging packet exchange）的实体，通过发送一个UWB POLL包，也被叫做“initiator”。在DK的应用中就是移动设备。
2）一个实体响应UWB POLL包，称作“responder”。在DK应用中，即车上的锚点Anchor。
3）包含一定数量responder的实体叫做“responder-device”。在DK应用中，即为车辆。
4）控制通过发送Pre-POLL包控制ranging流程的实体叫做控制器，在DK应用中，为移动设备本身，即设备即是发起者也是控制器。

注意：以上的定义在Bluetooth LE层可能并不相同。

在CCC的规范中规定，Controller的角色为Initiator，Controlee对应角色为Responder，也就是说CCC中的设备配置类型少于FiRa。

1.2 逻辑和物理响应者

1）responder可以是逻辑上的应答者也可以是物理实体。
2）物理实体响应者，需要有一个UWB模块和至少一个物理天线。
3）一个逻辑响应者对应于一个响应者角色，比如，一个特定的UWB模块和一个特定的物理天线。因此，一个物理响应者可以构成一个或多个逻辑响应者。
4）响应者设备（responder-device）需要协调逻辑响应者发送，保证在此时刻是没有其他的逻辑响应者也在发射信号，即需要避免发生干扰。

1.3 DK测距局域网

数字钥匙测距局域网，Digital Key Ranging Area Network, RAN，是CCC规范中，数字钥匙测距的一个最小分组。
1）发起者与响应者设备从事一个连续的测距流程，通过一组特定的参数，称为测距会话。
2）一个发起者和测距会话（1个或多个）形成一个所谓的测距局域网。每个RAN的典型特征是通过发起者建立的时间基准来进行。
3）所有在同一个RAN中的响应者设备均需要匹配发起者的时间线（此处没有假设全局同步），只需匹配对应发起者的时间线即可。
4）每个响应者设备可能拥有不同数量的逻辑响应者。
5）一个响应者设备可以同时处于两个不同的RAN中。

1.4 RAN之间冲突与资源管理

每个响应者设备中的响应者可以相对准确的预测允许其发送的窗口，这样就与其他的响应者不会发生冲突。然而，根据上面的定义，有三种可能的场景：

1. Inter-RAN干扰

• 从不同RAN而来的空中数据包干扰；
• 由于不同的RAN之间没有协调，不同RAN之间的干扰是不可避免的，因此在MAC的实现中，需要考虑通过hopping等策略来减轻。

2. Intra-RAN资源冲突

• 当协调器必须同时服务两个不同的测距交换时，资源冲突将会发生。
• 在实现中，可以在协调器处对所涉及的测距会话进行优先级排序。测距优先的会话优先进行测距，较低优先级的设备则跳到其他轮次进行。

3. Inter-RAN资源冲突

• 响应者需要同时服务于两个以上不同的RAN时，将会发生资源冲突。
• 此种场景下，只能通过优先级来解决，优先服务于最优的RAN，而忽略其他RAN。优先级有响应者设备来决定。
• 对于发起者忽略的RAN，将会出现如接受失败、响应者设备hop到其他测距轮。

这篇关于CCC联盟——UWB MAC（一）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---