目录

前言部分（封面、目录、修订历史）

技术规范

版本 4.0.0

FiRa® 联盟

利用本标准进行开源实施开发的开源项目应在适用开源项目的顶级目录中包含以下法律声明。

修订历史

注：各版本均为FiRa联盟董事会批准版本。版本1.0最初作为单一MAC/PHY文档批准。

目录

FiRa MAC技术要求与[IEEE_802_15_4_2020]的映射关系 ...

（目录内容省略，详见原文档第5-9页完整目录结构）

（目录续）

• 6.4.6 使用动态STS或带有响应端特定子...的预置STS的多播操作
• 附录A、附录B、附录C（C.1-C.4）、附录D（D.1-D.3）、附录E（E.1-E.3）、附录F
• 附录G：G.1 机制1（Poll DTM中无跳数字段的簇间同步算法）；G.2 机制2（基于跳数的簇间同步树构建）；G.3
• 附录H、附录I、附录J

表格清单

• 表12 - 带有RCP和RRRM的O2M延迟DS-TWR测距轮次中RDML示例
• 表13 - 不带RCP但带有...的O2M非延迟DS-TWR测距轮次中RDML示例
• 表14 - 带有RCP和RRRM的O2M非延迟DS-TWR测距轮次中RDML示例
• 表38 - 当坐标系类型字段值为0x00时的类型相关坐标字段 ... 77
• 表39 - 当坐标系类型字段值为0x01、0x03时的类型相关坐标字段 ...

第1章 概述 / 第2章 参考文献

表格清单（续）

• 表66 - secDerivedAuthenticationIv和phyStsIndexInit在2^n之后的DRBG输入字段上的映射
• 表68 - 动态（或预置）STS中带有响应端特定子...的密钥派生材料

插图清单

• 图1 - 测距控制端、被控端、发起端和响应端设备类型和角色。此图...
• 图3 - 单向双程测距(SS-TWR)。此图灵感来自...中的图6-47a
• 图5 - 双向双程测距(DS-TWR)三消息交换。此图灵感来自...
• 图12 - 发送AoA的FiRa设备使用的测距块结构示例
• 图16 - 基于竞争的测距与测量报告阶段示例（非延迟DS-TWR）

• 图41 - 用于向三个被控端和一个控制端分配测距时隙的单个DTPCM示例 ... 93
• 图43 - 将FiRa设备添加到数据传输会话并重新分配测距时隙的示例 .... 94
• 图45 - FiRa中的一般MAC帧格式，改编自[IEEE_802_15_4_2020]的图7-1 ... 101
• 图46 - MAC头终止IE。图改编自[IEEE_802_15_4_2020]的图7-21 ... 101
• 图47 - 有效载荷终止IE。图改编自[IEEE_802_15_4_2020]的图7-47 ...... 101
• 图48 - 每个块五个测距轮次、每个测距轮次十个时隙的测距块结构示例
• 图50 - 考虑块持续时间的分数时间的块表示示例 ........ 106
• 图64 - 机制1适用的DL-TDoA拓扑示例。标记为4（锚点4）的发起端DT锚点只能听到锚点3和锚点5，因此仅使用轮询...
• 图65 - 步骤1的图示。假设参考DT锚点被配置为在第(k+1)个测距轮次中运行。参考DT锚点在第(k+1)个测距轮次的第一个测距时隙中发送其第一个轮询DTM
• 图66 - 步骤2的图示。与参考DT锚点同一簇中的响应端DT锚点在接收到参考DT锚点发送的第一个轮询DTM后开始发送其响应DTM

• 图67 - 步骤3的图示。能够监听参考DT锚点轮询DTM的发起端DT锚点从下一个测距块（即测距块...）开始发送其轮询DTM
• 图68 - 步骤4的图示。无法监听参考DT锚点轮询DTM的发起端DT锚点在接收到其邻居的任何轮询DTM后开始发送其轮询DTM
• 图69 - 步骤5的图示。开始轮询DTM发送后，发起端DT锚点可根据在先前...接收到的轮询DTM的接收时间戳调整其轮询DTM发送时间
• 图70 - 使用机制2基于成本指标的DL-TDoA时间同步树状结构简化示例。蓝色圆圈表示在至少一个测距轮次中担任发起端DT锚点角色的DT锚点，灰色圆圈表示仅作为响应端DT...参与的DT锚点
• 图71 - DL-TDoA簇间同步树适应网络变化的示例 ....... 176
• 图76 - 使用分布在2个...的5个发起端DT锚点进行跨簇同步的示例

1 概述

本文档规定了参与超宽带(UWB)会话的设备所需满足的FiRa®介质访问控制(MAC)要求。FiRa MAC基于IEEE开发的802.15.4测距增强功能，并包含FiRa联盟技术工作组(TWG)开发的附加要求。本文档描述：

• 设备类型和设备角色
• 飞行时间(ToF)报告
• STS数据包配置
• 测距方法
• 多节点模式
• 调度模式
• 延迟和非延迟模式
• 基于块的模式
• UWB消息
• MAC数据传输模式
• MAC要求

本文档可与[PHY]、[UCI]、[LL]和[SUS_API]结合使用，构成FiRa设备的UWB子系统(UWBS)。

FiRa MAC技术要求与[IEEE_802_15_4_2020]和[IEEE_802_15_4z_2020]规范的映射

FiRa联盟感谢IEEE，因为本规范中部分信息引用自和/或衍生自[IEEE_802_15_4_2020]和[IEEE_802_15_4z_2020]规范，这些规范可从 https://www.ieee.org/ 直接获取。

本文档中提到的FiRa MAC技术要求映射到[IEEE_802_15_4_2020]和[IEEE_802_15_4z_2020]技术规范的各个章节。具体而言，本文档第5章描述的MAC功能映射到[IEEE_802_15_4z_2020]的第6、7和15章以及[IEEE_802_15_4_2020]的第7.4节。FiRa设备基于[IEEE_802_15_4z_2020]中定义的增强型测距能力设备(ERDEV)。

• 第5.1节描述的设备类型如[IEEE_802_15_4z_2020]第6.9.7节所规定。
• 第5.3节描述的STS数据包配置如[IEEE_802_15_4z_2020]第15.2.1节所规定。

• 第5.4节描述的多节点模式如[IEEE_802_15_4z_2020]第6.9.7节所规定。
• 本文档详述单播和O2M测距。单播在本文档中称为O2O测距。多对多测距模式的描述不在本文档范围内。
• [IEEE_802_15_4z_2020]第6.9.7.2节规定了测距块和轮次结构，FiRa设备在测距时遵循该结构。
• 在FiRa中，测距块是测距的最小时间周期，通过块跨步，可以在某些测距块中跳过测距。
• [IEEE_802_15_4z_2020]第6.9.7.3节规定了两种测距模式 -- 基于间隔的模式和基于块的模式。然而，FiRa仅使用基于块的模式，基于间隔的测距模式不在本文档范围内。
• 附录A和附录B展示了FiRa用于SS-TWR和DS-TWR的测距消息序列
• 第5.6节描述的调度测距如[IEEE_802_15_4z_2020]第6.9.7.1节所规定。
• 第5.7节描述的延迟和非延迟测距过程模式如[IEEE_802_15_4z_2020]第6.9.6.3节和第6.9.6.6节所规定。
• 本文档第5.9节规定的UWB消息格式基于[IEEE_802_15_4_2020]的厂商专用IE（第7.4.2.2节）和厂商专用嵌套IE（第7.4.4.30节）。本规范不使用[IEEE_802_15_4_2020]中定义的任何IE。相反，所有消息格式均使用[IEEE_802_15_4_2020]中描述的厂商专用头IE和厂商专用嵌套IE。
• 第5.8节描述的基于块模式的功能如[IEEE_802_15_4z_2020]第6.9.7.3.3节所规定。
• 第5.8.1节描述了一种称为轮次跳频的可选功能。
• 第5.8.2节描述了启用轮次跳频时FiRa设备应遵循的跳频序列，如[IEEE_802_15_4z_2020]第6.9.7.3.3节中为基于块模式所规定。
• 第5.8.3节描述了基于块测距模式中一种称为块跨步的可选功能，该功能在[IEEE_802_15_4z_2020]中未作规定。

第6.4节描述了FiRa设备的安全要求。它规定了密钥派生（针对[IEEE_802_15_4z_2020]中规定的各种密钥）和加密过程。各种密钥从FiRa到[IEEE_802_15_4z_2020]的映射在描述密钥派生的相应章节中提供。

2 参考文献

第3章 术语表 / 第4章 约定

参考文献（续）

3 术语表

以下缩略语、缩写和术语适用于本文档。

术语和定义

表1 - 术语

（表1 术语续完；表2 缩略语和缩写开始）

表2 - 缩略语和缩写

（表2 缩略语和缩写 续）

（表2 缩略语和缩写 续）

（表2 缩略语和缩写 续）

4 约定

本文档中的关键词"MUST（必须）"、"MUST NOT（不得）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（建议）"、"SHOULD NOT（不建议）"、"RECOMMENDED（推荐）"、"MAY（可以）"和"OPTIONAL（可选）"应按照[RFC_2119]中的描述进行解释。

标记为"已分配(Assigned)"的参数值表示该值已为特定未来用例分配，其使用将在未来版本中规定。"RFU"表示保留供未来使用，用于表示在本文档发布时没有指定用途但保留供未来使用。

任何保留字段中的每个比特在发送时应设置为零，在接收时应忽略。FiRa设备的行为不应根据任何保留字段的内容而改变。

以下编码约定适用：

• 每个八位组由比特b0至b7表示，其中b7是最高有效位(msb)，b0是最低有效位(lsb)。在所有表示中，最左边的比特是msb。当在单个表格条目中描述多个比特时，编号应从最低有效位(b0)开始。在每个八位组内，msb在时间上先发送。
• 所有数字以小端格式(Little Endian)发送和接收，即最低有效八位组（小端格式中编号为0的八位组）在时间上先发送。
• 八位组数组必须从八位组0开始按递增顺序逐个八位组发送。
• 本文档对数字使用以下表示法：

• 数字以十进制(nnn)、二进制(0bnnn)或十六进制(0xnnn；使用大写字母)表示法表示，指明了数字的位数。例如，0b001是值为1的3位二进制数，0x001是值为1的3位十六进制数。除非另有明确定义，字段中编码的数字为有符号或无符号整数。其他格式（例如包含浮点数的字段）在适用时在字段定义中说明。
• 除非在字段定义中另有说明，字段中的值应视为无符号值。
• 二进制值不应有分隔符。

• 小于或等于4个八位组的十六进制值不应有分隔符。大于4个八位组的十六进制值可使用"_"（下划线）作为分隔符以提高可读性。

• Octet[x] 指八位组数组中索引x处的值。
• Octet[m:n] 指值范围。
• {x, y, z ..} 指其中任意一个可能的值。

5 功能描述

5.1 设备类型与设备角色

5.1.1 TWR方法的设备类型

对于基于TWR的测距方法，设备类型和设备角色均有定义。图1表明设备类型和设备角色可以灵活组合。需要注意的是，设备类型仅适用于基于TWR的测距方法，而不适用于基于单向测距（OWR）的测距方法。

图1 - 测距控制端、被控端、发起端和响应端设备类型与角色。本图受[IEEE_802_15_4z_2020]图6-48i启发

5.1.1.1 控制端

通过发送控制消息来控制测距或数据传输并定义控制参数的FiRa设备。

5.1.1.2 被控端

利用从控制端控制消息中接收到的控制参数的FiRa设备。

5.1.2 设备角色

设备角色定义适用于TWR和OWR测距方法。

5.1.2.1 发起端

通过发送第一个测距帧（RFRAME），即测距发起消息（RIM），来发起测距交换的FiRa设备。

5.1.2.2 响应端

对从发起端接收到的测距发起消息（RIM）进行响应的FiRa设备。

5.1.2.3 下行到达时间差锚点（DT-Anchor）

下行到达时间差锚点（DT-Anchor）是一种FiRa设备，它发送下行到达时间差（DL-TDoA）消息（DTM），DT标签可利用这些消息基于TDoA

定位来计算自身位置。DT锚点可以作为发起端DT锚点或响应端DT锚点参与测距轮次。

5.1.2.3.1 发起端DT锚点

发起端DT锚点是通过发送轮询DTM来发起TDoA测距轮次的DT锚点，并可调度其响应端DT锚点的传输时间。

在DL-TDoA测距轮次中，同一集群（参见第5.4.3.2.1节）中所有响应端DT锚点发送各自的响应DTM之后，发起端DT锚点可进一步发送最终DTM。

在DL-TDoA网络中，应至少有一个参考DT锚点。参考DT锚点是一个发起端DT锚点，它作为集群间同步的全局时间参考，并设定DL-TDoA网络运行的公共测距块结构。

5.1.2.3.2 响应端DT锚点

响应端DT锚点是在所调度的测距时隙中以响应DTM对发起端DT锚点进行响应的DT锚点。发起端DT锚点在轮询DTM中为每个响应端DT锚点分配测距时隙。

5.1.2.4 下行到达时间差标签（DT-Tag）

DT标签是一种FiRa设备，能够利用基于DT锚点发送的DTM的TDoA测量值以及已知的DT锚点位置信息来估计自身位置（如地理坐标）。DT标签接收并测量DT锚点发送消息的接收时间。DT标签预期通过带内或带外（OOB）方法获取DT锚点的地理坐标。OOB方法的详细信息超出本规范的范围。

当DT标签所需的位置更新速率低于DL-TDoA网络支持的速率时，DT标签可以跳过测距块。例如，使用200ms的测距块持续时间，DL-TDoA网络提供5个位置/秒（= 1/200ms）的位置更新速率。如果DT标签只需1个位置/秒的更新速率，DT标签可以每5个测距块跳过4个测距块，在满足所需位置更新速率的同时降低能耗。为此，DT标签应使用第5.8.5节所述的块跳过功能来跳过测距块。

5.1.2.5 广播端

广播端是发送到达角（AoA）测量消息的FiRa设备，如第5.9.11.3节所定义。广播端可通过使用第5.9.12节定义的数据消息（DM），将应用载荷数据作为AoA测量消息MAC载荷的一部分包含在内。应用载荷数据由上层（UL）设置。

5.1.2.6 观察端

观察端是接收AoA测量消息并对每条消息测量AoA的FiRa设备。观察端应将测量的AoA发送给上层。如果AoA测量消息的MAC载荷中包含应用载荷数据，观察端可将其发送给上层。

5.1.2.7 上行到达时间差设备

UL-TDoA设备有三种类型，即UT标签、UT锚点和UT同步锚点，定义如下。表6（UWB消息的UWB消息ID）规定了UT标签和UT同步锚点发送的消息类型。

5.1.2.7.1 UT标签

UT标签是发送闪烁UTM以便被UT锚点基础设施定位的FiRa设备。

5.1.2.7.2 UT锚点

UT锚点是监听来自UT标签的闪烁UTM和来自UT同步锚点的同步UTM，并向后端RTLS实时定位系统（RTLS）引擎报告所接收消息的接收时间戳，用于位置估计或时间同步的FiRa设备。

5.1.2.7.3 UT同步锚点

UT同步锚点可周期性发送同步UTM以实现带内无线时钟同步。此外，UT同步锚点还监听来自UT标签的闪烁UTM和来自其他UT同步锚点的同步UTM，并报告所接收消息的接收时间戳。

5.2 飞行时间（ToF）报告

飞行时间（ToF）是发射端与接收端之间超宽带（UWB）信号的传播时间。通过精确的消息时间戳，ToF可以非常精确地估计两个设备之间的相对距离。应支持发起端与响应端之间通过信令方案交换此信息。

设备可以保留负的ToF值（由测量误差引起），而不是将其截断为0。

ToF值的应用超出本文档的范围。

5.3 STS数据包配置

物理层（PHY）包含可选模式，可减少空中传输时间以实现更高密度/更低功耗的操作，其中帧包含一个加密序列，称为加扰时间戳序列（STS），以提高测距测量时间戳的完整性和准确性。有关所支持的PHY数据包配置的详细定义，请参见[PHY]第5.1节。

5.4 测距方法

如[IEEE_802_15_4z_2020]第6.9.7.2节所述，完成涉及一组FiRa设备的分阶段测距测量周期所需的时间段称为测距轮次。每个阶段由一个或多个测距时隙组成——测距时隙是指一个设备向另一个设备发送一条完整消息的期间。

以下章节详细介绍了测距轮次结构以及不同调度方法中不同测距阶段所使用的消息。

如图2所示，测距轮次可由测距控制期（RCP）、测距阶段（RP）和测量报告阶段（MRP）组成，每个阶段包含一个或多个测距时隙，在测距时隙中发送指定的UWB消息。当适用于测距方法时，各阶段可以合并为单一阶段（例如，当控制端和发起端是同一FiRa设备时，RCP和测距发起阶段（RIP）可以合并）。

图2 - 具有不同阶段的测距轮次

• 测距阶段（RP）应包含测距发起阶段（RIP）、测距响应阶段（RRP），以及（在双边双向测距（DS-TWR）方法中的）测距最终阶段（RFP）。
  • 测距控制期（RCP）是控制端发送控制消息（CM）的阶段。
  • 测距发起阶段（RIP）是发起端向响应端发送测距发起消息（RIM）的阶段。
  • 测距响应阶段（RRP）是响应端向发起端发送测距响应消息（RRM）的阶段。
• 测距最终阶段（RFP）是发起端向响应端发送测距最终消息（RFM）的阶段，该阶段仅适用于DS-TWR测距。
• 测量报告阶段（MRP）是参与的FiRa设备交换测距信息及相关服务信息的阶段（即测量报告消息（MRM）、测距结果报告消息（RRRM）或控制更新消息（CRUM））。

已定义以下UWB消息：

• 控制消息（CM）是控制端在测距轮次时隙0中发送的消息。
• 测距发起消息（RIM）是发起端向响应端发送的消息。
• 测距响应消息（RRM）是响应端向发起端发送的消息。
• 测距最终消息（RFM）是发起端向响应端发送的消息。
• 测量报告消息（MRM）是FiRa设备为交换测量信息而发送的消息。
• 测距结果报告消息（RRRM）是响应端在MRP中向发起端发送的消息。
• 控制更新消息（CRUM）是控制端在MRP中发送的消息。当存在时，该消息应位于测距轮次的最后一个测距时隙。

每个测距轮次可由RCP、RP和MRP组成，其中每个阶段可包含多个测距时隙。对于某些测距轮次用途，某些阶段可以合并。当控制端和发起端在测距轮次中是同一FiRa设备时，RCP和RIP可以合并为单一阶段。

测距轮次的MRP可用于通过MRM、RRRM或CRUM等专用消息传送测距相关信息。

5.4.1 单边双向测距（SS-TWR）

单边双向测距（SS-TWR）涉及对从发起端设备到响应端设备的单条消息的往返延迟及其返回响应的简单测量。

图3 - 单边双向测距（SS-TWR）。本图受[IEEE_802_15_4z_2020]图6-47a启发

图3说明了SS-TWR的操作。发起端设备通过发送轮询消息发起交换，响应端对此回复以完成交换。每个设备精确记录消息帧的发送和接收时间，因此可以通过简单的减法计算出Tround和Treply时间。因此，传播时间或飞行时间Tprop可由以下公式估计：

T̂prop = (1/2)(Tround - Treply)

Tprop的准确性取决于应答时间Treply以及发起端和响应端设备之间的时钟频率偏移（CFO）。因此，一个FiRa设备（且仅一个）应对CFO进行补偿，以达到[PHY]（第5.4.1节）规定的测距精度。

5.4.1.1 增强型单边双向测距（eSS-TWR）

在SS-TWR事务中，由于飞行时间测量误差与Treply之间的线性关系，较长的应答时间会导致较大的测距误差。为了解除应答时间与测量误差之间的线性依赖关系，增强型单边双向测距（eSS-TWR）涉及对一个FiRa设备到另一个FiRa设备的单条消息及两个返回响应的两次往返

延迟的测量。eSS-TWR的操作如图4所示，其中设备A发起交换，设备B响应两次以完成交换。

图4 - 增强型单边双向测距（eSS-TWR）

飞行时间Tprop可由以下公式估计：

T̂prop = (1/2)[Tround1 - Treply1(1 + δ)]

其中，1 + δ = (Tround2 - Tround1) / (Treply2 - Treply1) 是应用于设备B应答时间测量的校正因子。

5.4.2 双边双向测距（DS-TWR）

双边双向测距（DS-TWR）是基本单边双向测距的扩展，

使用两次往返时间测量和两次应答时间测量并对其进行组合，即使在长响应延迟下也能提供误差减小的飞行时间结果。

图5 - 双边双向测距（DS-TWR）三次消息交换。本图受[IEEE_802_15_4z_2020]图6-47c启发

图5说明了DS-TWR操作。发起端设备向响应端设备发起第一次往返测量，然后响应端回复并发起第二次往返测量，发起端对此响应以完成完整的DS-TWR交换。每个设备精确记录消息的发送和接收时间，飞行时间估计值Tprop可由以下表达式计算：

T̂prop = (Tround1 × Tround2 - Treply1 × Treply2) / (Tround1 + Tround2 + Treply1 + Treply2)

5.4.3 单向测距（OWR）

OWR是一种测距方法，依赖于根据使用场景在一个FiRa设备与一个或多个其他FiRa设备之间单向传输的消息。OWR用于到达时间差（TDoA）和到达角（AoA）测量。

TDoA分为上行TDoA（UL-TDoA）和下行TDoA（DL-TDoA）。

在UL-TDoA中，FiRa设备（即UT标签）向部署在基础设施中的多个同步FiRa设备（即UT锚点和UT同步锚点）发送周期性闪烁消息。

在下行TDoA（DL-TDoA）中，多个FiRa设备（DT锚点）广播消息，而其他FiRa设备（DT标签）监听这些消息。基于接收到的消息及其接收时间戳，DT标签计算与发送消息的不同DT锚点对相关的多个TDoA测量值。然后，DT标签可以将这些TDoA作为定位算法的输入来估计自身位置。计算DT标签位置所需的最小TDoA数量取决于预期是二维（2D）还是三维（3D）定位。

在AoA测量中，涉及一对FiRa设备（一个广播端和一个观察端）。在这种情况下，无法测量TDoA，但可以在接收端测量到达角（AoA）。

5.4.3.1 上行到达时间差

上行到达时间差（UL-TDoA）是一种基于单条消息传输（单向测距）以节能方式在锚点基础设施中确定移动设备或UT标签位置的技术。为此，UT标签周期性发送称为闪烁上行TDoA消息（UTM）的UL-TDoA消息。这些消息被一组时间同步的锚点（UT锚点）接收，即位置已知的固定FiRa设备，

UT锚点测量每个闪烁UTM的接收时间戳，表示消息的到达时间（ToA）。基于到达时间差（TDoA），锚点基础设施可以利用双曲线定位从单次传输中估计UT标签的位置。每个TDoA估计值代表UT标签所在的一个双曲面。基于三个或更多双曲面的交点，可以准确确定UT标签的位置。

该UL-TDoA方法是一种尽力而为的方法，不保证通信可靠性，确实可能发生碰撞，特别是当参与UL-TDoA会话的FiRa设备（如UT标签）数量增加时。

5.4.3.1.1 时间同步

要使用UL-TDoA确定位置，UT锚点基础设施必须实现时间同步，这通过实现相关机制来完成，可以依赖带内无线时钟同步或有线同步。为支持前者，UT同步锚点可周期性发送同步UTM，并可在载荷中包含其本地发送时间戳。范围内的其他UT锚点可以接收这些消息，并向RTLS引擎报告测量的接收时间戳以及接收到的发送时间戳（如果包含在UL-TDoA载荷中），用于时钟同步和时间戳转换以推导TDoA。

5.4.3.1.2 位置更新速率与冲突避免

UT标签和UT同步锚点应基于可配置的发送间隔（表52，UWB配置参数）周期性发送UTM（分别为闪烁UTM和同步UTM）。对于UT标签，该间隔对应于两次连续闪烁UTM之间经过的时间，这定义了UT标签可被定位的TDoA位置更新速率。对于UT同步锚点，该间隔定义了接收UT锚点的时钟可与发送UT同步锚点的时钟同步的同步频率，用于带内无线时钟同步。发送间隔是可配置的，以适应不同的应用需求。

如果位于同一区域中的两个或更多UT标签以相同的发送间隔发送UTM，它们的数据包可能会持续碰撞，从而降低UT锚点基础设施定位和跟踪受影响UT标签的能力。同样，两个或更多UT同步锚点的同步UTM也可能发生这种情况，可能破坏可达的同步性能。为应对此问题并降低持续碰撞的可能性，不同的UT设备可以直接或通过带外方法配置，在不同时间发送其UTM，从而避免与其他UTM或同一信道上的其他UWB流量碰撞。另外或此外，UT设备可以在随机窗口内发送其UTM，如图7所示。该随机时间窗口在表52中称为随机窗口参数。该随机时间窗口是可配置的，允许UL-TDoA设备随机化传输时间。

图6 - 无随机窗口的UTM传输

图7 - 带随机窗口的UTM传输

UT标签和UT同步锚点内部维护一个持续时间等于发送间隔的时间网格，如图6和图7中蓝色方框所示。

如果不使用随机窗口，则UT标签和UT同步锚点按照发送间隔在规律的时间周期发送UTM，如图6所示。

如果使用随机窗口，则UT标签和UT同步锚点在从"发送间隔时间网格"起始到"发送间隔时间网格 + 随机窗口"结束的时间窗口内的随机时间发送UTM，如图7所示。

发送间隔值为每个UT标签和每个UT同步锚点独立配置。例如，静止或缓慢移动的UT标签可以将其间隔配置为大于其他移动UT标签。同样，UT同步锚点可以具有比UT标签更短的间隔，以确保精确的无线时钟同步。为降低碰撞的可能性并避免UL-TDoA设备占用共享无线信道，建议发送间隔不低于100ms。

UT锚点应始终处于接收模式，以接收任何闪烁UTM以及（如果支持）同步UTM。UT同步锚点应始终处于接收模式以接收任何闪烁UTM和同步UTM，发送同步UTM时除外。

5.4.3.1.3 UL-TDoA中的数据传输

UT标签可以在闪烁UTM中发送MAC数据服务数据单元（MDSDU）。该MDSDU不应被分段，应在一个DM载荷信息元素（IE）中承载，如第5.9.12节所定义。

5.4.3.2 用于DL-TDoA的OWR

DL-TDoA是一种定位方法，使DT标签能够基于从DT锚点接收的DTM来估计自身位置。在DL-TDoA中，DT锚点发送DTM，而DT标签被动接收，这防止了任何DT标签位置的暴露。

每个DT锚点精确测量其自身DTM的发送时间和所接收DTM的接收时间。每个DT锚点应在DTM中包含其DTM的发送时间。DT标签精确测量其接收的每个DTM的接收时间，并利用接收时间戳以及获取的DL-TDoA锚点坐标来估计自身位置。

图8 - DL-TDoA测距轮次中的下行TDoA消息交换过程

图8所示的TDoA测距轮次中的DL-TDoA消息交换过程描述如下：

1. 发起端DT锚点通过发送广播轮询DTM来发起DL-TDoA轮次，该消息被集群（如第5.4.3.2.1节所定义）中的响应端DT锚点接收。轮询DTM应包含每个响应端DT锚点在所分配测距时隙发送响应DTM的调度信息。
2. 接收到轮询DTM后，每个响应端DT锚点在其分配的测距时隙向发起端DT锚点回复响应DTM。
3. 从响应端DT锚点接收到响应DTM后，发起端DT锚点可进一步向响应端DT锚点发送最终DTM。

DT标签接收上述交换的轮询DTM、响应DTM和最终DTM，并根据消息的接收时间戳和其中包含的信息计算TDoA值。

5.4.3.2.1 DL-TDoA网络结构

DL-TDoA网络由组织为集群并分布在可能较大部署区域内的多个DT锚点组成。

集群是一组DT锚点（图9），它们交换DTM以向集群覆盖的特定区域内的DT标签提供定位服务。集群由一个发起端DT锚点和一个或多个响应端DT锚点组成。在单个响应端DT锚点的情况下，集群也可称为锚点对。在图9中，灰色矩形代表同一集群中四个DT锚点覆盖的地理空间。对于能够接收如图9所示四个DT锚点之间交换的DTM的DT标签，该DT标签可以估计三个TDoA值。

一个DT锚点可以在多个集群中作为发起端或响应端DT锚点运行。例如，在一个集群中作为发起端DT锚点运行的DT锚点可以在其他集群中作为响应端DT锚点运行。这有助于集群间同步实现块对齐，在第5.4.3.2.4节中有更详细的描述。

图9 - 集群示例图示

为了在大面积范围内提供定位服务，可能需要部署多个集群，如图10所示。此外，一个集群覆盖的区域可以与相邻集群覆盖的区域重叠，以减小（改善）精度衰减因子（DOP）的影响。

图10 - 多集群锚点部署示例

5.4.3.2.2 测距块结构

每个测距块由多个测距轮次组成。在测距轮次中，集群中的DT锚点交换至少一个轮询DTM、一个或多个响应DTM，以及可选的最终DTM，如第5.4.3.2节所定义。一个测距轮次可被多个互不干扰的远距离集群使用。换言之，如果不同集群中的DT锚点互不干扰，则可以配置为在相同的测距轮次中运行。这样，可以减少部署中用于DL-TDoA的活动测距轮次总数。例如，两个互不可听的集群中的DT锚点可以

配置为使用相同的第k个测距轮次。因此，这两个集群中的发起端DT锚点将在第k个测距轮次的测距时隙0中同时发送其轮询DTM。

图11 - 每个集群使用一个测距轮次的示例

5.4.3.2.3 集群内同步（实现公共时间）

集群内的DT锚点可以执行集群内同步，使该集群内的响应端DT锚点能够将其本地发送时间戳转换到测距轮次发起端DT锚点的（公共）时间域。这反过来使DT标签能够基于接收到的发送时间戳和测量的接收时间戳推导TDoA估计值。

在给定测距轮次的第一个时隙中，发起端DT锚点发送轮询DTM。如果给定响应端DT锚点启用了集群内同步，则该响应端DT锚点可以将其本地发送时间戳转换为发起端DT锚点的公共时间，并在响应DTM中包含转换后的发送时间戳，将消息控制字段中的发送时间戳类型字段设置为1（即公共时间基准）。

5.4.3.2.4 集群间同步

集群间同步的目标是对齐多集群DL-TDoA网络中发起端DT锚点的测距块结构，并避免集群之间的干扰。

在DL-TDoA网络中，应至少有一个发起端DT锚点作为时间参考（即参考DT锚点）。参考DT锚点通过在其配置的活动测距轮次的第一个测距时隙（即测距时隙索引0）中发送轮询DTM来生成测距块。参考DT锚点可配置为在第一个测距轮次中运行，使参考DT锚点在测距块的第一个测距轮次的第一个测距时隙中发送其轮询DTM。其他发起端DT锚点在开始发送其轮询DTM之前，应通过监听DTM与参考DT锚点生成的测距块同步。附录G描述了两种实现集群间同步的机制。

这些集群间同步机制并非用于使DT标签准确计算跨集群TDoA估计值，例如来自不同集群中两个DT锚点的TDoA。

相邻集群中的DT锚点可以使用额外/其他方法更精确地同步（例如，达到亚纳秒级精度），使DT标签能够准确计算跨集群TDoA。但是，考虑这些额外/其他方法超出本规范的范围。此类方法的示例见附录J。

5.4.3.2.5 DL-TDoA中的数据传输

发起端或响应端DT锚点可以发送MDSDU。MDSDU包含在DM载荷IE中，如第5.9.12节所定义。MDSDU的发送和接收应遵循第5.10.1节定义的要求。

5.4.3.3 用于AoA测量的OWR

用于AoA测量的OWR是一种测距方法，使观察端能够接收来自广播端的OWR消息并测量AoA，以估计或预测观察端用户的意图、动作或运动。例如，控制特定广播端的用户意图可以通过对该广播端的OWR消息进行多次AoA测量的结果来确定。

图12 - 当MIN_FRAMES_PER_RR设置为4时，发送AoA测量消息的FiRa设备（即作为广播端）所使用的测距块结构示例

图12说明了单个广播端在测距块中发送的RFRAME。在此类测距块中，应仅存在一个AoA测量测距轮次。AoA测量测距轮次不包含测距时隙。在测距轮次中，可以发送多个AoA测量消息，每个消息在单独的SP1 RFRAME中发送，如图所示，第一个RFRAME应在测距轮次开始时发送。要发送的RFRAME数量应包含在AoA测量消息的消息控制字段（见表43）中，如第5.9.11.3节所定义。

广播端应根据表52规定的UWB配置中的每轮次最小帧数（即MIN_FRAMES_PER_RR）和帧间间隔配置参数来配置AoA测量消息。MIN_FRAMES_PER_RR表示广播端在测距块中应发送的AoA测量消息的最小数量。广播端在测距轮次中发送的AoA测量消息的实际数量（即等于表43中规定的参数"RFRAME数量"的值）应作为AoA测量消息的字段之一包含在内。RFRAME数量应等于或大于在广播端配置的MIN_FRAMES_PER_RR。当广播端在测距轮次中发送多个AoA测量消息时，两个连续AoA测量消息之间的发送间隔应等于帧间间隔参数。帧间间隔也应作为AoA测量消息的字段之一包含在内。当观察端在测距轮次中接收到AoA测量消息时，观察端可以根据AoA测量消息中包含的RFRAME数量和帧间间隔参数，确定广播端在测距轮次中正在/将要发送的AoA测量消息数量及其发送间隔。

5.4.3.3.1 AoA测量OWR中的数据传输

广播端可以在AoA测量消息中发送MDSDU。如果存在，MDSDU应在一个或多个DM载荷IE中承载，如第5.9.12节所定义。DM载荷IE应按第6.3.4.2.5.2节的规定与AoA测量消息一起搭载传输。第一个DM载荷IE应在第一个RFRAME中发送。

广播端应根据表52规定的MTU大小来配置AoA测量消息中DM载荷IE的最大大小。AoA测量消息中DM载荷IE的最大大小应受MTU大小限制，MTU大小应在考虑PHY模式和帧间间隔的情况下确定。如果广播端将MDSDU分段为N个分段，则RFRAME数量应等于或大于N。如果RFRAME数量大于N，则前N个RFRAME应包含DM载荷IE。前N个RFRAME之后的其余RFRAME不应包含任何DM载荷IE。注意，测距轮次中的DM载荷IE可以包含不同大小的分段。

5.4.3.3.2 OWR AoA测量的时序要求

帧间间隔保护时间（IFI_GT）是一个AoA测量测距轮次中两个连续RFRAME发送之间的时间。广播端在发送下一个RFRAME之前至少等待最小IFI_GT，记为IFI_GT_MIN。广播端选择其最大RFRAME大小，使其在每个IFI的开始时刻发送RFRAME（包含在OWR消息中，见表42），同时满足最小IFI_GT。最小IFI_GT确保观察端有足够的时间检测RFRAME的结束并准备检测和接收下一个RFRAME。

帧间间隔块保护时间（IFI_BGT）是一个AoA测量测距轮次的最后一个RFRAME与下一个测距块开始之间的时间。广播端在开始下一个测距块的帧发送之前至少等待最小IFI_BGT，记为IFI_BGT_MIN。

图13显示了一个AoA测量测距轮次，每个测距轮次包含四个帧（MIN_FRAMES_PER_RR），以及一个RFRAME结束与后续RFRAME开始之间的IFI_GT。IFI_BGT显示为AoA测量测距轮次的最后一个RFRAME结束与开始下一个测距块的帧（例如，开始下一个AoA测量测距轮次）之间的时间持续时间。

图13 - OWR AoA测量的帧间间隔保护时间

以下时序要求适用于OWR AoA测量：

• 广播端应在测距块开始时发送AoA测量测距轮次的第一个RFRAME。
• 当广播端在AoA测量测距轮次中发送多个RFRAME时，两个连续RFRAME之间的发送间隔应等于表42定义的帧间间隔（即广播端在IFI开始时发送RFRAME）。
• IFI保护时间（IFI_GT）定义为属于同一AoA测量测距轮次的一个RFRAME结束与后续RFRAME开始之间的时间。
• IFI_GT_MIN定义为240个测距调度时间单元（RSTU）（200µs）。
• 广播端在发送属于同一AoA测量测距轮次的新RFRAME之前应至少等待IFI_GT_MIN。
• 观察端应在IFI_GT_MIN之后准备好接收属于同一AoA测量测距轮次的下一个RFRAME。
• 帧间间隔块保护时间（IFI_BGT）是当前测距块的一个AoA测量测距轮次的最后一个RFRAME结束与下一个测距块的第一个RFRAME开始之间的时间。
• IFI_BGT_MIN定义为1200个RSTU（1ms）。
• 广播端在发送表示下一个测距块开始的RFRAME之前应至少等待IFI_BGT_MIN。
• 观察端应在IFI_BGT_MIN之后准备好接收表示下一个测距块开始的RFRAME。
• 广播端应按如下方式设置块持续时间：
  • block_duration >= IFI * MIN_FRAMES_PER_RR - IFI_GT_MIN + IFI_BGT_MIN

5.5 多节点模式

5.5.1 一对一（O2O）

O2O模式表示只有一个测距发起端和一个测距响应端参与测距轮次，这是O2M模式的特例。

5.5.2 一对多（O2M）

O2M模式表示一个发起端和多个响应端参与测距或数据传输轮次，其中发起端与所有响应端执行测距或数据交换。

5.6 调度模式

5.6.1 时间调度模式

时间调度测距用于控制端调度被控端在不同测距时隙中发送RFRAME/测量报告的测距轮次。在此模式下，测距时隙由控制端在无竞争期（CFP）中为特定FiRa设备调度。

DL-TDoA采用时间调度模式，其中发起端DT锚点为响应端DT锚点调度时隙，使其在测距轮次的所分配时隙中发送DTM。

5.6.2 基于竞争的模式

当控制端不了解将参与UWB会话的FiRa设备时，通常使用基于竞争的测距。在此模式下，控制端应始终承担发起端角色，被控端应始终承担响应端角色。此模式适用于TWR会话。

在每个基于竞争的测距轮次中，控制端在CM中决定并通知竞争接入期（CAP）大小。在此模式下，RCP和RIP应合并为RIP。RP中CAP大小的分配确定了参与测距轮次的响应端的CAP持续时间（以测距时隙计）。每个响应端应在CAP内随机选择一个测距时隙来发送其RRM。用于选择测距时隙的随机化函数应确保CAP的每个测距时隙被选中的概率相等。

控制端应在测距轮次的第一个测距时隙（标识为测距轮次的时隙0）中发送RIM，即基于竞争测距的控制消息类型2。FiRa设备在基于竞争测距的RP中发送的每条消息应使用SP1作为RFRAME配置，采用多用途帧类型。

CAP包含"M"个测距时隙，响应端可以在其中发送其RRM。

CAP测距时隙紧接RIM测距时隙之后开始。

图14 - 紧接RIM之后的CAP（SS-TWR）

控制端设置的CAP大小应小于或等于CAP大小范围的配置最大值。CAP大小不应小于CAP大小范围的最小值。当响应端在CAP期间竞争测距时隙时，可能会发生碰撞。控制端可以基于检测到的碰撞数量或响应端数量决定调整后续测距轮次的CAP大小。碰撞检测和动态更改CAP大小的决定由厂商特定实现决定。

5.6.2.1 SS-TWR测距方法

参与基于竞争测距的FiRa设备应支持非延迟SS-TWR测距方法（参见第5.7节）。非延迟SS-TWR基于竞争测距的RRP从RIM之后的测距时隙开始，到CAP的最后一个测距时隙结束。响应端应发送测量报告消息（MRM）类型3消息作为RRM。响应端可以决定不在MRM类型3中发送AoA相关信息。

当使用SS-TWR测距方法时，由于响应端和发起端之间的CFO，应答时间越长测距误差越大。因此，响应端设备应在其MRM类型3消息中包含的应答时间中补偿其CFO。

5.6.2.2 eSS-TWR测距方法

可以使用eSS-TWR测距方法来减轻误差因素。当使用eSS-TWR测距方法时，控制端设置的CAP大小M应为偶数。每个响应端随机选择一个数k，使得0≤k≤M/2-1，并在测距时隙2k+1和2k+2中发送其RRM。

图15 - 基于竞争测距中的非延迟eSS-TWR测距方法

5.6.2.3 DS-TWR测距方法

基于竞争调度模式还可以支持非延迟DS-TWR测距方法。在此方法中，响应端的RRP占用连续时隙，随后是所有响应端共用的单个RFP和MRP。

RRP应紧接RIP之后开始，RFP应紧接RRP的最后一个测距时隙之后开始。发起端应在RIP中发送CM类型2作为RIM。响应端应在RRP中发送MRM类型3作为RRM，其中应答时间设置为0。发起端应在RFP中发送一条或多条MRM类型1消息作为RFM。当应答时间列表超出消息的MAC载荷大小时，测距轮次的RFP应包含多条MRM类型1。MRP的CFP紧接RFP的最后一条消息之后开始。MRM类型1消息中的第一个往返时间应对应于应答时间列表中列出的第一个响应端。在MRP期间，响应端应在MRP的第j个测距时隙中回复其RRRM，对应于其在应答时间列表中的位置。在这种情况下，应答时间列表的第一个元素对应于MRP的第一个测距时隙，应答时间列表的第j个元素对应于

MRP的第j个测距时隙。在应答时间列表中未找到条目的响应端不应参与MRP。MRP的大小应为RFP中发送的所有MRM类型1消息的应答时间列表长度之和。

图16 - 带测量报告阶段的基于竞争测距示例（非延迟DS-TWR）

5.6.2.4 替代双边双向测距（aDS-TWR）测距方法

基于竞争调度模式还可以支持替代双边双向测距（aDS-TWR）测距方法。

在aDS-TWR中，RFP和MRP紧随每个响应端的RRP之后。如果不存在MRP，CAP大小M应为偶数。响应端随机选择一个数k，使得0≤k≤M/2，并在时隙2k+1中发送其RRM。如果存在MRP，CAP大小M应为3的倍数。响应端随机选择一个数k，使得0≤k≤M/3，并在时隙3k+1中发送其RRM，随后在时隙3k+2中发送其RRRM。图17显示了无MRP的aDS-TWR测距示例。

图17 - 无MRP的基于竞争测距示例（非延迟aDS-TWR）

5.6.2.5 Tx偏移、Tx抖动和响应端管理列表的处理（适用于所有测距方法）

在测距轮次的CAP期间，为降低碰撞概率，响应端可以在测距时隙内允许的Tx偏移处发送其响应消息。

控制端应为发送RRM选择每个测距时隙的Tx偏移数量，使RRM帧的发送不超过测距时隙边界。控制端应在CM类型2中指示响应端可选的允许Tx偏移列表。响应端可以随机选择一个允许的Tx偏移。

从测距时隙开始处算起，第k个发送偏移（以RSTU为单位）的计算公式为：

Tx Offset k = (k * Slot Duration) / (Number of Tx Offsets)

Tx偏移0从时隙开始处起始。在图18中，Tx偏移数量为4，允许的Tx偏移仅为Tx偏移0和Tx偏移2。响应端只能选择Tx偏移0或Tx偏移2来发送其RRM。控制端理想情况下应配置Tx偏移数量和允许Tx偏移列表，以避免在两个连续允许Tx偏移中发送的RRM发生任何重叠。控制端在配置Tx偏移数量和允许Tx偏移列表时还应考虑CAP大小，因为CAP大小和Tx偏移数量相互关联以最小化RRM碰撞。

图18 - Tx偏移表示示例

如果响应端不支持Tx偏移功能，则应在Tx偏移0处发送其响应消息。

为了进一步提高在碰撞事件中其中一个RRM被正确接收的机会，控制端为响应端指定Tx抖动窗口是有益的，使每个响应端在发送RRM时引入一个受指定Tx抖动窗口约束的随机偏移，控制端可以在Tx抖动窗口期间继续检测传入的RRM。示例见图19。

图19 - Tx抖动窗口示例

在基于竞争的测距会话期间，控制端获知响应端的身份。当控制端获知响应端的身份后，可以在CM类型2消息中包含响应端管理列表（RML）。当RML存在时，RRP的CAP的前N个时隙为RML中存在的J个响应端预留。RML的每个元素对应于一个已知响应端的设备MAC地址。响应端在RML中的第j个位置对应于RRP中CAP的第j个测距时隙。在CM类型2的RML中未找到设备MAC地址的响应端应使用RRP中预留测距时隙之后CAP中的任意随机测距时隙。

图20 - 非延迟SS-TWR中CAP内设备识别示例

在上述使用非延迟SS-TWR的示例中，在第一个测距轮次中，RRP中有4个不同的响应端。然后控制端执行距离测量，这些响应端为控制端所知。控制端用这些已知响应端构建RML，并在下一个测距轮次的测距时隙0中发送CM类型2。

图21 - 非延迟SS-TWR为RML设备预留CAP的示例

响应端检查RML，如果找到其设备MAC地址，则应在RML中对应其位置的测距时隙中发送RRM。在RML中未找到设备MAC地址的响应端应使用可用CAP中的任意随机测距时隙。响应端在预留测距时隙中响应时应忽略CM类型2中配置的Tx偏移信息。

图22 - 非延迟eSS-TWR为RML设备预留CAP的测距

如果使用eSS-TWR测距方法且CM类型2中存在RML（如图22所示），则前R个时隙为RML中指示的响应端预留，其中R也应为偶数。响应端可以随机选择的CAP中的测距时隙数量为M-R。每个响应端随机选择一个数k，使得0≤k≤(M-R)/2-1，并在测距时隙R+2k+1和R+2k+2中发送其RRM。

5.6.3 混合UWB调度

混合UWB调度（HUS）是一种功能，允许将以时间调度模式或基于竞争模式配置的UWB会话以彼此固定的时序关系进行调度，使其在HUS测距轮次中以确定性的时间序列发生。当需要实现更复杂的使用场景，需要顺序且可能重叠地执行多个UWB会话时，这非常有意义。

HUS结构由测距控制期（RCP）和可能的HUS测距阶段组成。HUS测距阶段可以是竞争接入期（CAP）或无竞争期（CFP），如图23所示。RCP始终从HUS测距轮次的第一个时隙开始，可以延伸到后续时隙。HUS测距阶段的开始和结束时隙索引在RCP中为每个测距轮次配置。HUS测距阶段按顺序发生但可以重叠，即下一个HUS测距

阶段可以在前一个结束之前开始。在每个HUS测距阶段内执行一个UWB会话，称为HUS从会话。特别是，在CAP内执行基于竞争的TWR会话，在CFP内可以执行基于时间调度的TWR会话或专用数据传输会话。

图23 - 由RCP和HUS测距阶段组成的HUS结构

FiRa设备可以作为HUS控制端或HUS被控端参与HUS会话。HUS控制端通过在RCP中发送控制消息类型3（CM类型3）来调度整个HUS测距轮次，如第5.9.13节所定义。所有HUS被控端应监听HUS控制端的CM类型3。CM类型3为每个HUS测距阶段包含一个数据元素，存储HUS测距阶段是CAP还是CFP的信息、其开始和结束时隙索引、哪个设备将作为该HUS测距阶段的控制端/发起端以及阶段会话ID。CM类型3的所有元素定义了该测距轮次中所有活动HUS测距阶段的序列。HUS控制端或HUS被控端都可以在特定HUS测距阶段中承担控制端/发起端角色。

HUS会话和每个HUS测距阶段使用的UWB PHY和MAC参数可以单独配置，但在一个完整的HUS测距轮次期间不应更改。与STS生成方法相关的UWB PHY配置在不同HUS测距阶段之间可以不同。

对于HUS会话，第6.3.2节定义的基于块的模式要求应适用。HUS测距轮次的长度定义为时隙0开始到所有HUS测距阶段中最大结束索引对应时隙结束之间的持续时间。

HUS测距阶段的时隙持续时间应为HUS会话配置的时隙持续时间的整数倍。

HUS测距阶段内的时隙数量应使用CM类型3的测距轮次管理列表（RRML）中包含的时隙索引起始、时隙索引结束以及HUS会话时隙持续时间按如下方式计算：

1. HUS测距阶段持续时间 = (时隙索引结束 - 时隙索引起始 + 1) * 时隙持续时间_HUS会话。
2. HUS测距阶段中的时隙数 = ⌊HUS测距阶段持续时间 / 时隙持续时间_HUS测距阶段⌋，其中⌊⌋表示向下取整函数。

每个HUS测距阶段内的时隙索引处理应针对每个HUS测距阶段独立进行。

注意：HUS会话时隙索引的目的是定义每个HUS测距阶段的开始和结束时间。

每个测距块应只有一个活动的HUS测距轮次。

HUS测距阶段应按顺序发生但可以重叠，即下一个HUS测距阶段在前一个结束之前开始。

HUS控制端不应将重叠HUS测距阶段的控制端角色分配给同一FiRa设备。

以下规则适用于参与重叠HUS阶段的控制端或被控端：

• 被分配为两个或多个重叠HUS测距阶段控制端的FiRa设备应选择并执行其中任一（仅一个）HUS测距阶段。
• 被分配为一个HUS测距阶段控制端并在重叠HUS测距阶段中作为被控端的FiRa设备，应作为控制端执行该HUS测距阶段，且不应作为被控端参与重叠的HUS测距阶段。
• 被分配为多个HUS测距阶段被控端的FiRa设备，当参与的HUS测距阶段与另一个阶段的CM重叠时，可以跳过与该HUS测距阶段CM的同步。

HUS控制端应在HUS测距轮次的第一个时隙中发送第5.9.13节定义格式的CM类型3的开始部分。

CM类型3可能超过一个时隙持续时间，因此可以延伸到后续时隙。在这种情况下，HUS控制端应使用帧待续位功能（例如第5.4.3.3节中定义的）来通告CM类型3帧分段。

如果CM类型3被分段，则包含分段的所有时隙应在RCP中发送。RCP不得与后续HUS测距阶段重叠。

HUS被控端应在HUS测距轮次的第一个时隙中接收CM类型3。如果使用帧待续功能，则HUS被控端应准备好在多个时隙上接收分段的CM类型3。

如果FiRa设备的MAC地址列在CM类型3中，则该设备应作为HUS测距阶段的控制端。

HUS测距阶段的控制端应在该HUS测距阶段的第一个时隙中发送与该HUS测距阶段中调度的配置从会话相对应的CM（CM类型1、CM类型2或数据传输协议控制消息（DTPCM））。此外，配置测距方法和角色所定义的相同要求应适用于控制端和被控端。

如果FiRa设备被配置为CFP HUS测距阶段的被控端，则应参与该阶段对应CM的测距或数据传输。

如果FiRa设备被配置为CAP HUS测距阶段的被控端，则应监听CM类型2并参与HUS测距阶段，但以下情况除外：如果被控端参与CFP HUS测距阶段，则在其之后由同一控制端控制的CAP中，该被控端不应参与。

如果启用跳频模式，则它适用于作为整体HUS测距轮次的所有HUS测距阶段。

如果启用块跨步，则它适用于作为整体HUS测距轮次的所有HUS测距阶段。

图24显示了一个HUS测距轮次的示例，由三个HUS测距阶段组成：一个使用时间调度TWR的CFP、一个CAP和一个使用时间调度数据传输的CFP。

图24 - 示例：HUS测距轮次

附录I中展示了一个可能的HUS测距轮次配置示例。

5.7 延迟模式与非延迟模式

5.7.1 延迟模式

延迟测距轮次应包含交换应答时间和往返时间的MRP。

5.7.2 非延迟模式

非延迟测距轮次在RP中包含测量报告消息，其中交换应答时间和/或往返时间。

5.8 基于块的模式机制

在基于块的模式中，连续测距轮次之间的平均时间假定为常数。

控制端应在第一个测距块（块索引0）的第一个测距轮次（轮次索引0）中启动测距会话。

5.8.1 轮次跳频

轮次跳频是FiRa设备跳到下一个测距块的不同测距轮次索引以执行测距测量的功能。FiRa设备在下一个测距块中使用的测距轮次由跳频序列确定。所选跳频模式适用于会话的整个生命周期。

5.8.2 跳频序列

对于轮次跳频，测距会话中的每个测距设备应使用相同的跳频序列。以下函数应用于生成跳频序列：

S(BlockIndex, SessionID, N_Round) = ((AES(BlockIndex, SessionID) & 0xFFFF) ^ N_Round) >> 16

其中N_Round表示测距块中的测距轮次数，>>表示按位右移运算符。

AES函数应使用AES-128（高级加密标准-128）的ECB模式。BlockIndex和SessionID均左侧填充零以达到AES块大小，分别用作明文和密钥。

跳频序列确定了启用跳频模式时应使用的测距轮次的轮次索引。

BlockIndex 0（即测距会话中的第一个测距块）的轮次索引应始终为0，无论是否启用轮次跳频。这意味着轮次跳频可能直到BlockIndex 1才开始。

示例参见附录H。

5.8.3 块跨步

块跨步功能可用于跳过测距块。当不需要频繁测距时，测距设备可以通过跳过测距块来降低功耗。

步长指示在下次测距之前将跳过多少个测距块。如果步长值为N且当前块索引为M，则下一个使用的测距块索引为M+N+1。

5.8.4 UWB启动时间

UWB启动时间是"UWBS时间"域中的绝对时间，在该时间应在测距会话启动后发送第一条消息（例如，TWR情况下的第一条CM或合并的CM和RIM）。"UWBS时间"是UWBS的系统时间，UWBS的MAC实现使用它来建立测距轮次。

5.8.5 块跳过

块跳过功能可由DT标签用于在DL-TDoA期间通过自主决定跳过测距块来降低功耗。DT标签不会通过带内或任何带外机制与DT锚点协商来决定是否启用或禁用块跳过功能。此功能仅适用于DT标签，不适用于DT锚点。

5.9 UWB消息

UWB消息是FiRa设备在测距轮次中发送的载荷IE。

接收到载荷IE的FiRa设备应忽略该载荷IE中的未知字段，并继续正常操作。

本节详细介绍了测距轮次中不同测距阶段所使用的UWB消息。

测距轮次中使用的帧可以是SP0（STS数据包配置0）、SP1或SP3数据包（详见[PHY]）。

用于RP中测距测量的帧称为测距帧（RFRAME）。RFRAME通过PHY头部（PHR）中设置的测距字段位来指示。没有PHR的SP3数据包应始终被视为RFRAME。

FiRa设备在测距轮次的RCP或MRP中发送的消息应为数据帧。数据帧通过PHR中未设置的测距字段位来指示。

RFRAME可以包含多个UWB消息作为嵌套载荷IE，如[IEEE_802_15_4_2020]第7.2.9节所规定。当RFRAME传送多个UWB消息时，发送的第一个载荷IE的UWB消息ID字段应指示测距轮次RP中的阶段（RIP/RRP/RFP）。如果RFRAME包含DM载荷IE，则应使用其自身的消息ID（0x8）发送。

当RIP RFRAME传送CM信息时，CM应为第一个嵌套载荷IE，CM的UWB消息ID为0x0（即RIM的UWB消息ID）。当RRP RFRAME传送MRM信息时，MRM应为第一个载荷IE，MRM的UWB消息ID为0x1（即RRM的UWB消息ID）。当RFP RFRAME传送MRM信息时，MRM应为第一个载荷IE，MRM的UWB消息ID为0x2（即RFM的UWB消息ID）。

图25 - 测距阶段的颜色编码

以下消息详情适用于延迟和非延迟测距轮次结构。

图26 - 延迟SS-TWR测距轮次

在延迟SS-TWR测距中，应发送CM类型1作为CM。当使用SP3帧作为RFRAME时，SS-TWR的时隙排序应隐式指示RP消息。可选地，当不承载其他载荷IE时，SP1可用作RP中的RFRAME，PSDU（PHY服务数据单元）大小为零。可以在SP1 RFRAME中发送DM载荷IE，在这种情况下，DM载荷IE应具有其自身的消息ID（0x8）。在此测距轮次中，MRM消息应由发起端或响应端发送，并应使用MRM类型2作为MRM。

图27 - 无RCP的非延迟SS-TWR测距轮次

在非延迟SS-TWR测距中，RCP是可选的。当不包含RCP时，CM由发起端作为RP中的RIM消息发送。在时间调度测距中，响应端应在RP中发送MRM类型2消息作为RRM；在基于竞争测距的情况下，响应端应发送MRM类型3作为RRM。

图28 - 带RCP的非延迟SS-TWR测距轮次

当非延迟SS-TWR测距中包含RCP时，应使用CM类型1作为CM。当不承载其他载荷IE时，RIM应以SP1作为RFRAME且PSDU为零，并应使用MRM类型2作为RRM。

图29 - 无RCP的非延迟eSS-TWR测距轮次

对于eSS-TWR测距，适用于延迟和非延迟测距轮次结构的消息详情与SS-TWR测距类似，不同之处在于每个测距轮次有两个RRM。无RCP的非延迟eSS-TWR测距轮次示例见图29。

图30 - 延迟DS-TWR测距轮次

在延迟DS-TWR测距中，发起端应在测距轮次的MRP中发送MRM类型1消息。当使用SP3帧作为RFRAME时，DS-TWR的时隙排序应隐式指示RP消息。可选地，当不承载其他载荷IE时，SP1可用作RP中的RFRAME，PSDU大小为零。可以在SP1 RFRAME中发送DM载荷IE，在这种情况下，DM载荷IE应具有其自身的消息ID（0x8）。

图31 - 无RCP的非延迟DS-TWR测距轮次

在非延迟DS-TWR测距中，RCP是可选的。当不包含RCP时，控制端应在RP中发送控制消息类型1作为RIM消息。响应端应使用SP1作为RFRAME，以MRM类型2（不存在应答时间且往返时间列表为空）作为RRM。RFM应使用SP1作为RFRAME，以MRM类型1消息作为RFM。

图32 - 带RCP的非延迟DS-TWR测距轮次

当非延迟DS-TWR测距轮次中存在RCP时，控制端应使用控制消息类型1，UWB消息ID指示该消息为CM。发起端应以PSDU大小为零的SP1 RFRAME发送RIM。响应端应使用SP1作为RFRAME，以MRM类型2（不存在应答时间且往返时间列表为空）作为RRM。发起端应以SP1 RFRAME发送MRM类型1消息作为RFM。

如果发起端FiRa设备未从响应端接收到调度的UWB消息，则以下要求适用：

• MRM类型1的第一个往返时间字段应包含第一个接收到的RRM的往返时间。
• MRM类型1的应答时间列表字段应仅包含与接收到的RRM对应的应答时间列表元素。
• 如果未接收到对应响应端的RRM，发起端设备可以忽略该响应端的调度RRRM消息。
• 如果启用跳频，则发起端应在下一个测距块中继续跳频。

如果响应端FiRa设备未从发起端接收到调度的UWB消息，则以下要求适用：

• 如果未接收到RIM，则响应端应跳过在测距轮次中的进一步参与，并移至下一个测距块。
• 如果未接收到MRM，则响应端可以跳过在调度测距时隙中发送RRRM。
  • 如果在未接收到MRM的情况下仍发送RRRM，载荷IE中的"ToF结果"应省略，消息控制字段中的"ToF结果存在"应设置为0。
• 如果启用跳频，则响应端应移至下一个测距块，并参与跳频序列对应的轮次索引。

UWB消息可以包含头部IE和/或载荷IE。头部IE和载荷IE应分别按照[IEEE_802_15_4_2020]表（第7.4.2.1节）和表（第7.4.3.1节）格式化。

Header IE的Content字段应按表4构造。

Vendor OUI（组织唯一标识符）字段的值应为0x5A18FF。如果Vendor OUI字段的值不为0x5A18FF，FiRa设备将忽略该消息。

Padding字段传送用于完整性校验的已知填充位。

Session ID的值是每个会话每个控制端的32位随机数。Session ID的生成超出本文档的范围。

STS index字段指示当前测距时隙的STS索引值，由phyStsIndex参数（第6.4.4.1节）表示。STS索引值用于STS同步和MAC载荷解密。

Padding字段、Session ID字段和STS index字段在动态STS和预配置STS的情况下应使用ECB模式加密。

STS索引用于按以下方式计算块索引和轮次索引：

Block index = ⌊(current STS index - initial STS index) / Number of slots per block⌋

Round index = ⌊((current STS index - initial STS index) % Number of slots per block) / Number of slots per round⌋

其中⌊⌋表示向下取整函数，%表示取模运算。

根据以上公式，第一个测距块的块索引为0，每后续一个测距块递增1。测距块中第一个测距轮次的轮次索引为0，每后续一个测距轮次递增1，然后在下一个测距块开始时重置为0。

每个UWB消息的UWB消息ID在表6中定义。每个UWB消息可以有多种类型，每个UWB消息使用的类型应通过通用服务与管理（CSM）层指定。

6 消息格式

6.1 消息格式概述

本章定义了FiRa MAC层中使用的各种消息格式，包括头部IE（Header IE）格式、有效载荷IE（Payload IE）格式以及各类UWB消息的内容字段。

表3 - 头部IE格式

头部IE（Header IE）的Content字段应按照表4定义构建。

表4 - 头部IE内容字段

表5 - 有效载荷IE格式

表6定义了各UWB消息的UWB消息ID。

表6 - UWB消息的UWB消息ID

6.2 UWB消息格式详述

6.2.1 测距发起消息（RIM）

在延迟测距中，携带SP3或SP1帧的RIP时隙承载RIM。

在非延迟测距中，在RRP时隙的SP1帧中承载的、UWB消息ID设置为0x0的控制消息类型1/类型2（CM Type 1/Type 2）承载RIM。

6.2.2 测距响应消息（RRM）

在延迟测距中，携带SP3或SP1帧的RRP时隙承载RRM。

在非延迟测距中，在RRP时隙的SP1帧中承载的、UWB消息ID设置为0x1的测量报告消息类型1/类型2（MRM Type 1/Type 2）承载RRM。

6.2.3 测距最终消息（RFM）

在延迟测距中，携带SP3或SP1帧的RFP时隙承载RFM。

在非延迟测距中，在RFP时隙的SP1帧中承载的、UWB消息ID设置为0x2的测量报告消息类型1/类型2（MRM Type 1/Type 2）承载RFM。

6.2.4 控制消息类型1

对于控制消息类型1，头部IE的Content字段应按照表4定义构建。此消息仅适用于时间调度测距。

对于控制消息类型1，有效载荷IE的Content字段应按表7构建。

表7 - 控制消息类型1的有效载荷IE内容字段

除非此消息作为RFRAME传输，否则UWB消息ID应为0x3以指示此消息为控制消息。

消息控制字段应按表8所示格式化。

表8 - 控制消息类型1的消息控制字段

RDML长度字段指示RDML字段中的元素数量。RDML长度字段的值应与RDML元素的数量相同。如果调度信息未发生变化，控制器可以省略RDML字段。如果省略RDML字段，RDML长度字段应为零。

步长（Stride length）字段指示跳过到下一次测距的块数。如果步长字段的值为N且当前块索引为M，则块索引为M+N+1的测距块应用于下一次测距。通过为步长字段设置较大的值，控制器可以降低测距频率以减少功耗。

暂停测距（Suspend Ranging）功能是一个可选功能，用于指示测距块已同步但参与同步块测距轮次的FiRa设备不应参与该测距轮次的RP或MRP以执行测距测量。

以下要求适用于控制器：

• 如果应用层在测距块中配置了暂停测距条件，则控制器应在不超过2个测距块内设置暂停测距条件的配置值。
  • 如果配置为进入暂停测距条件，则控制器应发送暂停测距位设置为'1'的控制消息类型1，只要它被配置为处于暂停测距条件。
  • 控制器应存储进入暂停测距条件之前使用的RDML内容。
  • 在暂停测距条件下，控制消息类型1不应包含RDML字段，并应将RDML长度值设置为0。
  • 如果配置为退出暂停测距条件，则控制器应发送暂停测距位设置为'0'的控制消息类型1，并应包含进入暂停测距条件之前存储的RDML内容。
• 当控制器处于暂停测距条件时，不应在RP和MRP中发送任何消息。

以下要求适用于受控器：

• 当暂停测距位设置为'1'时，受控器不应进一步参与同一测距轮次，并进入该测距轮次的暂停测距条件。
• 受控器应在后续的测距块中继续与控制消息类型1同步。
• 处于暂停测距条件的受控器在接收到暂停测距位设置为'0'的控制消息类型1时，应退出暂停测距条件，并根据控制消息类型1中存在的RDML参与同一测距轮次的RP和MRP。

以下要求适用于控制器和受控器双方：

• 控制器/受控器设备在进入或退出暂停测距条件时应通知应用层。
• 控制器/受控器应按照静态STS、预配置STS和动态STS的情况递增phyStsIndex。
• 在暂停测距条件下，步长字段应适用。
• 在暂停测距条件下，跳频适用。
  • 对于FiRa定义的跳频（参见第5.8.2节）：
    • 当控制器进入暂停测距条件时，控制器和受控器应遵循第5.8.2节定义的跳频方案来确定每个测距块中的活动测距轮次。
  • 对于厂商特定的跳频：
    • 在暂停测距条件下，控制器应包含控制更新消息类型1（CRUM Type 1），跳频模式应设置为'1'并包含轮次索引值。
    • 当在测距块M中禁用跳频时，不应包含CRUM类型1消息。
    • 当在测距块M中退出暂停测距条件时，不应包含CRUM类型1，跳频模式应在MRM类型1消息中指示。

RDML中的每个元素（如果存在）应按表9格式化。

表9 - RDML元素格式

测距角色（Ranging Role）字段指定所选设备是发起端还是响应端。当测距角色字段的值为零时，所选设备为响应端。当测距角色字段的值为一时，所选设备为发起端。

测距时隙索引（Ranging Slot Index）字段指示分配给由地址字段标识的设备的时隙索引。

地址字段标识每个参与设备。

调度的UWB消息（Scheduled UWB Message）字段指定将在测距时隙中承载的UWB消息。

停止测距（Stop Ranging）字段指定受控器的测距将继续还是停止。当停止测距字段的值为零时，受控器的测距应继续。当停止测距字段的值为一时，受控器的测距应停止，受控器不应在UWB会话中发送更多消息。

如果控制器要为所有受控器结束UWB会话，RDML应仅包含等于受控器数量的元素。每个元素应包含一个受控器的地址，且停止测距位应设置为1。每个元素中的其他参数（即测距角色、测距时隙索引、调度的UWB消息和保留字段）均不相关，应被受控器忽略。此外，步长字段不相关，应被受控器忽略。

如果控制器要为部分但非全部受控器结束UWB会话，RDML应包含UWB会话中所有已调度消息的元素（例如，测距发起消息、测距响应消息等）。对于不再参与UWB会话的每个受控器，RDML应包含一个具有该受控器地址且停止测距位设置为1的元素；其他参数均不相关，应被受控器忽略。

作为控制器为两个受控器结束UWB会话时的示例，RDML如表10所示。

表10 - 控制器为两个受控器结束UWB会话的RDML示例

作为控制器在带ToF报告的SS-TWR中为其中一个受控器结束UWB会话时的示例，RDML如表11所示。

表11 - 控制器为其中一个受控器结束UWB会话的RDML示例

控制消息类型1在测距控制阶段（RCP）中传输，参见图56。

表12 - O2M延迟DS-TWR测距轮次中带RCP和RRRM且涉及两个响应端（使用SP1 RFRAME）的RDML示例

在表12中，每个SP1 RFRAME的PSDU长度为零（称为SP1*）。但是，如果发起端或响应端在RFRAME中传输数据消息（DM）有效载荷IE，则应传输消息ID为0x8的DM有效载荷IE，并应使用表56规定的帧控制字段的数据帧类型。在这种情况下，RDML中调度的UWB消息ID仍为RP的消息ID（即RIM、RRM或RFM）。

表13 - O2M非延迟DS-TWR测距轮次中不带RCP但带RRRM且涉及两个响应端的RDML示例

在表13的示例中，如果发起端或响应端在RFRAME中传输DM有效载荷IE，则应在第一个UWB消息（即控制消息类型1、MRM类型2或MRM类型1）之后传输消息ID为0x8的DM有效载荷IE。

表14 - O2M非延迟DS-TWR测距轮次中带RCP和RRRM且涉及两个响应端的RDML示例

在表14的示例中，如果发起端或响应端在RFRAME中传输DM有效载荷IE，则应在第一个UWB消息（即MRM类型2或MRM类型1）之后传输消息ID为0x8的DM有效载荷IE。

6.2.5 测量报告消息类型1

测量报告消息类型1应用于DS-TWR。

对于测量报告消息类型1，头部IE的Content字段应按照表4定义构建。

对于测量报告消息类型1，有效载荷IE的Content字段应按表15构建。

表15 - 测量报告消息类型1的有效载荷IE内容字段

除非此消息作为RFRAME传输，否则UWB消息ID应为0x4以指示此消息为测量报告消息。

消息控制字段应按表16所示格式化。

表16 - 测量报告消息类型1的消息控制字段

跳频模式（Hopping mode）字段指示下一个测距块是否启用跳频模式。

轮次索引存在（Round Index Present）字段指示轮次索引字段是否存在。如果测量报告消息由控制器发送，控制器应将轮次索引存在设置为1。当测量报告消息的发送方为受控器时，轮次索引字段可以省略。如果启用跳频模式且轮次索引存在且配置了FiRa跳频，则轮次索引字段应按第5.8.2节的跳频序列计算。

应答时间列表长度（Reply time list length）字段指示应答时间列表字段中的元素数量。

轮次索引字段指示将在下一个测距块中使用的测距轮次的轮次索引。轮次索引字段仅在测量报告消息由控制器传输时有效。

如果测量报告消息的发送方为发起端，首次往返时间（First round-trip time）字段指示发起端的测距发起消息与第一个响应端的首次测距响应消息之间的时间差。如果测量报告消息的发送方为响应端，首次往返时间字段指示该响应端的测距响应消息与发起端的测距最终消息之间的时间差。单位为499.2 MHz切片周期的2^-7，约为15.65 ps。

应答时间列表中的每个元素应按表17格式化。

表17 - 应答时间列表元素格式

地址字段指示以下应答时间字段所关联的响应端。

如果测量报告消息的发送方为发起端，应答时间字段指示前一个地址字段所指示的响应端的测距响应消息与发起端的测距最终消息之间的时间差。如果测量报告消息的发送方为响应端，应答时间字段指示发起端的测距发起消息与该响应端的测距响应消息之间的时间差。单位为499.2 MHz切片周期的2^-7，约为15.65 ps。

第一个响应端的应答时间列表元素应位于应答时间列表字段的开头。

第一个响应端通过首次往返时间字段接收发起端的往返时间测量值。其他响应端通过从第一个响应端的往返时间和应答时间之和中减去自身的应答时间来计算其在发起端的往返时间测量值，即：

RTT(k) = (Reply Time(1) + RTT(1)) - Reply Time(k)

其中k表示响应端索引。

图33 - 每个响应端的首次往返时间和应答时间

测量报告消息类型1在MRP中传输，参见图56。

6.2.6 测量报告消息类型2

测量报告消息类型2应用于时间调度延迟SS-TWR、非延迟SS-TWR和非延迟DS-TWR。

对于测量报告消息类型2，头部IE的Content字段应按照表4定义构建。

对于测量报告消息类型2，有效载荷IE的Content字段应按表18构建。

表18 - 测量报告消息类型2的有效载荷IE内容字段

除非此消息作为RFRAME传输，否则UWB消息ID应为0x4以指示此消息为测量报告消息。

消息控制字段应按表19所示格式化。

表19 - 测量报告消息类型2的消息控制字段

跳频模式字段指示下一次测距是否启用跳频模式。

轮次索引存在字段指示轮次索引字段是否存在。如果测量报告消息由控制器发送，控制器应将轮次索引存在设置为1。当测量报告消息的发送方为受控器时，轮次索引字段可以省略。如果启用跳频模式且轮次索引存在且配置了FiRa跳频，则下一个测距轮次的轮次索引字段应遵循第5.8.2节的跳频序列。

往返时间列表长度（Round-trip Time List Length）字段指示往返时间列表字段中的元素数量。当测量报告消息类型2的发送方为响应端时，往返时间列表长度字段的值可以为零。

应答时间存在（Reply Time Present）字段指示应答时间字段是否存在。当测量报告消息类型2的发送方为发起端时，应答时间字段可以省略。

轮次索引字段指示将在下一个测距块中使用的测距轮次的轮次索引。轮次索引字段仅在测量报告消息由控制器传输时有效。

应答时间字段指示响应端接收测距发起消息的时间与发送测距响应消息的时间之间的时间差，以测距节拍（~15.65 ps）为单位。响应端在此消息中发送的应答时间应经过CFO补偿。

往返时间列表中的每个元素应按表20格式化。

表20 - 往返时间列表元素格式

地址字段指示以下往返时间字段所关联的响应端。

往返时间字段指示发起端发送测距发起消息的时间与接收到前一个地址字段所指示的响应端的测距响应消息的时间之间的时间差，以测距节拍（~15.65 ps）为单位。

测量报告消息类型2在MRP中传输，参见图55。

6.2.7 测距结果报告消息类型1

对于测距结果报告消息类型1，头部IE的Content字段应按照表4定义构建。

对于测距结果报告消息类型1，有效载荷IE的Content字段应按表21构建。

表21 - 测距结果报告消息类型1的有效载荷IE内容字段

UWB消息ID应为0x5以指示此消息为测距结果报告消息。

ToF结果和负ToF结果均以测距节拍（~15.65 ps）报告。

AoA方位角结果（AoA azimuth result）字段是一个有符号整数，报告方位角中估计的AoA。单位为360° × 2^-16，0°表示正对发送设备的方向。该字段表示的角值范围为-180°至+180°。

AoA俯仰角结果（AoA elevation result）字段是一个有符号整数，报告俯仰角中估计的AoA。单位为180° × 2^-16，0°表示在发送设备的水平面中。该字段表示的角值范围为-90°至+90°。

AoA方位角品质因数（AoA azimuth Figure of Merit, FoM）字段是一个无符号整数，传达方位角中估计AoA的置信度。

AoA俯仰角品质因数（AoA elevation FoM）字段是一个无符号整数，传达俯仰角中估计AoA的置信度。

测距结果报告消息类型1在MRP中传输，参见图56。

ToF结果字段和负ToF结果字段应按以下方式处理：

如果ToF计算值 ≥ 0：

• ToF结果存在（ToF result Present）字段应设置为1。
• 负ToF存在（Negative ToF present）字段应设置为0（适用于支持负测距值的设备）。
• ToF结果字段应包含ToF值。
• 负ToF结果字段不存在。

如果ToF计算值 < 0：

• ToF结果存在字段应设置为1。
• 负ToF存在字段应设置为1（适用于支持负测距值的设备）。
• ToF结果字段应设置为0。

如果响应端由于测距配置无法计算ToF：

• ToF结果存在字段应设置为0。
• 负ToF存在字段应设置为0。

负ToF结果字段应包含ToF绝对值（适用于支持负测距值的设备）。

消息控制字段应按表22所示格式化。

表22 - 测距结果报告消息类型1的消息控制字段

ToF结果存在字段为1时指示ToF结果字段存在，为0时表示不存在。

AoA方位角结果存在字段为1时指示AoA方位角结果字段存在，为0时表示不存在。

AoA俯仰角结果存在字段为1时指示AoA俯仰角结果字段存在，为0时表示不存在。

AoA品质因数存在（AoA FoM present）字段为1时指示：

• 如果AoA方位角结果字段存在，则AoA方位角品质因数字段存在
• 如果AoA俯仰角结果字段存在，则AoA俯仰角品质因数字段存在

AoA品质因数是一个指标，提供对测量AoA值（方位角或俯仰角）的预期精度或置信度的估计，取决于实现精度和接收信号质量。AoA品质因数字段范围从0到100（0b00000000到0b01100100），0表示对估计的AoA值无置信度（即无效的AoA估计），100表示对提供的AoA值有非常高的置信度。AoA品质因数值越高，对AoA测量的置信度越高。AoA品质因数值的计算取决于厂商，超出本文档范围。

ToF结果字段指示以测距节拍（~15.65 ps）为单位的ToF结果。

6.2.8 控制更新消息类型1

对于控制更新消息类型1，头部IE的Content字段应按照表4定义构建。

对于控制更新消息类型1，有效载荷IE的Content字段应按表23构建。

表23 - 控制更新消息类型1的有效载荷IE内容字段

UWB消息ID应为0x6以指示此消息为控制更新消息。

跳频模式字段指示下一个测距块是否启用跳频模式。

轮次索引字段指示将在下一个测距块中使用的测距轮次的轮次索引。

6.2.9 控制消息类型2

对于控制消息类型2，头部IE的Content字段应按照表4定义构建。

控制消息类型2的有效载荷IE内容应按表24规定构建。此消息仅适用于基于竞争的测距。

表24 - 控制消息类型2的有效载荷IE

在基于竞争的测距中，由于RIM包含控制消息，应使用0x0作为UWB消息ID值。

步长字段应指示跳过的块数。

RML大小字段指示RML的大小（以字节为单位）。RML中的元素数量由（RML大小 /（短地址模式））确定。

RML字段包含已知响应端的设备MAC地址列表。设备MAC地址应为短MAC地址。

控制消息类型2的消息控制字段如表25所示。

表25 - 控制消息类型2的消息控制字段

CAP大小（CAP Size）字段表示CAP中可用的测距时隙数量。该大小值可能因测距轮次而异，但不得超过配置的最大CAP大小范围，且不得小于最小CAP大小范围。

测量报告阶段控制（Measurement Report Phase Control）字段指示基于竞争的测距轮次中是否存在MRP。如果存在MRP，则发起端应在测距阶段之后立即传输测量报告。

发送抖动窗口控制（Tx Jitter Window Control）字段指示响应端在发送消息（例如RRM）时是否可以应用随机抖动时间。

发送偏移数量（Number of Tx Offsets）字段应指示响应端可以发送消息的测距时隙的等分数。

发送偏移数量和允许的发送偏移值仅适用于CAP。

当跳频模式设置为'1'时，控制更新消息类型1的有效载荷IE应跟随在控制消息类型2有效载荷IE之后。

停止测距字段指示控制器是否决定停止UWB会话或继续UWB会话。当停止测距设置为值'1'时，已参与UWB会话或已与发起端的RIM同步的响应端应停止进一步参与UWB会话。

RML配置（RML Config）字段指示RML的存在或不存在。

允许的发送偏移字段应指示响应端发送消息时在测距时隙内允许的发送偏移。

表26 - 响应端管理列表（RML元素）

6.2.10 测量报告消息类型3

对于测量报告消息类型3，头部IE的Content字段应按照表4定义构建。

对于测量报告消息类型3，有效载荷IE的Content字段应按表27规定构建。

表27 - 测量报告消息类型3的有效载荷IE内容字段

应答时间字段指示发起端的RIM与响应端的RRM之间的时间差，以测距节拍（~15.65 ps）为单位。响应端在此消息中发送的应答时间应经过CFO补偿。

消息控制字段应按表28所示格式化。

表28 - 测量报告消息类型3的消息控制字段

AoA方位角结果存在字段为1时指示AoA方位角结果字段存在，为0时表示不存在。

AoA俯仰角结果存在字段为1时指示AoA俯仰角结果字段存在，为0时表示不存在。

应答时间存在字段为1时指示应答时间字段存在，为0时表示不存在。

AoA品质因数存在字段为1时指示：

• 如果AoA方位角结果字段存在，则AoA方位角品质因数字段存在
• 如果AoA俯仰角结果字段存在，则AoA俯仰角品质因数字段存在

AoA品质因数是一个指标，提供对测量AoA值（方位角或俯仰角）的预期精度或置信度的估计，取决于实现精度和接收信号质量。AoA品质因数字段范围从0到100（0b00000000到0b01100100），0表示对估计的AoA值无置信度（即无效的AoA估计），100表示对提供的AoA值有非常高的置信度。AoA品质因数值越高，对AoA测量的置信度越高。AoA品质因数值的计算取决于厂商，超出本文档范围。

AoA方位角结果字段是一个有符号整数，报告方位角中估计的AoA。单位为360° × 2^-16，0°表示正对发送设备的方向。

AoA俯仰角结果字段是一个有符号整数，报告俯仰角中估计的AoA。单位为180° × 2^-16，0°表示在发送设备的水平面中。

AoA方位角品质因数字段是一个无符号整数，传达方位角中估计AoA的置信度。

AoA俯仰角品质因数字段是一个无符号整数，传达俯仰角中估计AoA的置信度。

6.2.11 OWR消息

所有OWR消息应包含三个公共字段（厂商OUI、UWB消息ID和OWR消息类型），后跟一组取决于OWR消息类型的特定有效载荷IE字段。表29定义了所有OWR消息的公共字段。

表29 - 所有OWR消息的有效载荷IE内容字段公共部分

厂商OUI字段的值应为0x5A18FF。如果厂商OUI字段的值不是0x5A18FF，FiRa设备应忽略该消息。

OWR消息类型使接收FiRa设备能够了解接收到的数据包是用于上行TDoA（0x0-0x1）用例以跟踪UT标签，还是用于下行TDoA（0x2-0x4）以实现非跟踪导航，或用于AoA测量（0x5）。在UL-TDoA情况下，OWR消息类型还使消息接收方能够区分发送方是UT标签（0x0 - Blink UTM）还是UT同步锚点（0x1 - Synchronization UTM）。

OWR消息类型相关有效载荷取决于所选的OWR消息类型。该字段包含支持每个用例和消息类型所需的信息。因此内容是可变的，应按第5.9.11.1节（UL-TDoA）、第5.9.11.2节（下行TDoA消息）和第5.9.11.3节（AoA测量消息的OWR）中的规定执行。

6.2.11.1 上行TDoA消息（UTM）

有两种类型的UTM：

1. Blink UTM由UT标签传输，使UT锚点基础设施能够估计UT标签位置；
2. 同步UTM由UT同步锚点传输，用于带内无线时钟同步。

注意，这两种消息类型共享相同的有效载荷IE字段，如"上行TDoA消息的OWR消息类型相关有效载荷IE"中所规定。

表30 - 上行TDoA消息的OWR消息类型相关有效载荷IE

消息控制字段指示不同消息字段（设备ID和TX时间戳）的存在和长度。表31显示了消息控制字段的格式。

帧号（Frame Number）字段指示本地UTM帧号，发送方UT标签或UT同步锚点应在每次UTM传输后单调递增该值。

当非零时，UL-TDoA设备ID字段应包含分配给消息发送方的唯一ID。UL-TDoA设备ID字段的存在和长度应在消息控制字段中规定。唯一性在本地有效，由设备所有者或管理者分配。设备ID生成超出本文档范围。

TX时间戳字段指示UTM的本地发送时间。TX时间戳应以测距节拍（~15.65 ps）报告。TX时间戳字段的存在和长度应在消息控制字段中规定。

表31 - UTM的消息控制字段

6.2.11.2 下行TDoA消息

对于DL-TDoA，根据表52中指示的用途，OWR消息类型可以是0x2、0x3或0x4，OWR消息类型相关有效载荷字段应按表33定义构建。表32定义了哪些参数适用于各OWR消息类型。

表32 - OWR消息类型相关有效载荷参数

表33 - DL-TDoA的OWR消息类型相关有效载荷

消息控制字段应按表34所示格式化。

表34 - 消息控制字段

响应端DT锚点管理列表长度字段指示响应端DT锚点管理列表字段中的元素数量。Poll DTM中的响应端DT锚点管理列表长度字段应具有非零值。

测距时隙索引存在（Ranging Slot Index Present）字段指示Poll DTM是否包含每个Response DTM的分配时隙索引。测距时隙索引字段的存在指示时隙调度是隐式还是显式的。

• 隐式调度：如果测距时隙索引不存在，则与每个响应端DT锚点关联的测距时隙索引从响应端DT锚点管理列表中响应端MAC地址的顺序隐式获得。在这种情况下，第一个响应端地址分配给时隙1，第二个响应端地址分配给时隙2，以此类推。注意，时隙0保留用于传输Poll DTM。
• 显式调度：如果消息控制字段指示测距时隙索引存在，则时隙被显式分配，每个响应端地址应分配给响应端DT锚点管理列表每个元素中包含的特定测距时隙索引。

无论使用隐式还是显式调度，如果消息控制字段中的DL-TDoA消息交换位设置为0b1（DS-TWR），则Final DTM应在测距轮次中最后一个Response DTM之后的时隙中发送。

应答时间列表长度字段指示应答时间列表字段中的元素数量。在Final DTM中，除非发起端DT锚点在测距轮次期间未能接收到任何Response DTM，否则该字段应为非零值。

DL-TDoA消息交换字段指示测距轮次中要执行的消息交换类型（SS-TWR或DS-TWR）。发起端DT锚点应根据其配置为DL-TDoA使用SS-TWR还是DS-TWR在Poll DTM中设置该位。在Final DTM中，该位应始终设置为1。响应端DT锚点应按照测距轮次中Poll DTM中接收到的值设置该位，即将位值0/1复制到其Response DTM中。

TX时间戳长度字段指示DTM中包含的TX时间戳的长度40位或64位。发起端DT锚点应根据其配置设置该字段。响应端DT锚点应使用测距轮次中发起端DT锚点发送的Poll DTM中指定的相同值设置该字段，并包含相应长度的TX时间戳字段。

TX时间戳类型字段指示TX时间戳是以本地时间基准还是公共时间基准报告。发起端DT锚点应根据其配置设置该位；或者在使用超簇同步的情况下，当发起端DT锚点能够将其时间戳转换为超簇公共时间时，应将该位设置为0b1（并在失去与超簇的同步后将其恢复为0b0，例如当不再从附近簇接收Poll DTM时）。响应端DT锚点如果配置为使用公共时间且能够将其时间戳转换为发起端DT锚点的公共时间，则应将该位设置为0b1。

响应端CFO存在字段指示响应端CFO字段是否存在。响应端DT锚点可以包含响应端CFO字段以使DT标签能够补偿其相对于公共时间基准（即发起端DT锚点的时钟）的时钟频率偏移。

响应端ToF结果存在字段指示发送Response DTM的响应端DT锚点是否包含基于DS-TWR测量的响应端ToF结果。该字段只能在DL-TDoA消息交换设置为0b1（DS-TWR）时设置为0b1。

跳数存在（Hop Count Present）字段指示Poll DTM中是否存在跳数字段。

锚点位置存在（Anchor Location Present）字段指示锚点位置字段是否存在。

活动测距轮次信息存在指示Poll或Response DTM中是否存在活动测距轮次列表长度和活动测距轮次列表字段。

块索引字段指示当前测距块的块索引。

轮次索引字段指示当前测距轮次的轮次索引。

TX时间戳字段以本地或公共时间基准时间戳的形式表示DTM的发送时间，以测距节拍（~15.65 ps）为增量，在包含时间戳的数据包发送时，表示天线处发送方时间参考。时间参考是帧的RMARKER。TX时间戳是相对时间，持续递增直到达到最大值，当达到最大值时，应从值0x0重新开始。如果TX时间戳的长度为L，则TX时间戳的最大值为2^L-1。为使DT标签能够使用DTM中包含的TX时间戳来计算TDoA值，TX时间戳应在簇的公共时间基准中。为此，DT锚点应使用相对于簇中发起端DT锚点的估计时钟偏移和时钟频率偏移，将其本地TX时间戳转换为公共时间基准的时间戳。如果响应端DT锚点尚未与其发起端DT锚点同步，则可能无法将其本地TX时间戳转换为公共时间基准。在这种情况下，响应端DT锚点应在Response DTM中包含其本地TX时间戳，并在消息控制字段中将TX时间戳类型位设置为零。

TX时间戳公共时间基准类型字段指示DTM中包含的TX时间戳用于公共时间转换的时间基准类型。当DT锚点配置为使用超簇公共时间时，该位应设置为0b1。否则，该位应设置为0b0。

当TX时间戳公共时间基准类型字段设置为0b1时，Poll DTM中应存在超簇同步相关信息字段。超簇同步相关信息字段为超簇ID字段和发起端CFO字段。超簇ID字段指示发送此消息的发起端DT锚点所属的超簇。发起端CFO字段包含发送此消息的发起端DT锚点的本地时钟频率与超簇频率之间的时钟频率偏移。它使其他发起端DT锚点或DT标签能够补偿其相对于超簇公共时间基准的时钟频率偏移。

响应端DT锚点管理列表字段包含簇中DT锚点的调度信息。响应端DT锚点管理列表字段中的每个元素应按表35定义格式化。

表35 - 响应端DT锚点管理列表元素

测距时隙索引字段指示分配给由响应端地址字段标识的响应端DT锚点的时隙索引。

ToF结果字段指示发起端DT锚点在上一个测距块中基于SS-TWR测量的、由响应端地址字段标识的响应端DT锚点之间的ToF。值0x0000表示未知的ToF结果。

响应端地址字段指示要在测距时隙索引字段中调度的响应端DT锚点的源MAC地址。

响应端CFO字段指示相对于发起端DT锚点的时钟频率偏移，单位为ppm。该值应以Q6.10格式报告（1位符号位、5位整数部分和10位小数部分），提供约0.00097 ppm的分辨率和[-32 ppm, 32 ppm)的范围。当发送方（即发起端DT锚点发送需要进行CFO计算的DTM）的振荡器频率高于接收方（即发送包含此字段的Response DTM的响应端DT锚点）的振荡器频率时，该值应为正；当发送方的振荡器频率低于接收方的振荡器频率时，该值应为负（[IEEE_802_15_4z_2020]，第6.9.1.6.2节）。

应答时间列表字段包含一个发起端应答时间列表，表示Final DTM的发送时间与接收到的每个Response DTM的接收时间之间的时间差。除非发起端DT锚点在测距轮次期间未能接收到任何Response DTM，否则该字段应包含在Final DTM中。应答时间列表字段中的每个元素应按表36所示格式化。

表36 - Final DTM中包含的应答时间列表元素

响应端地址字段指示以下发起端应答时间字段所关联的响应端DT锚点的源MAC地址。

发起端应答时间字段指示接收由响应端地址标识的响应端DT锚点发送的Response DTM与发送Final DTM之间经过的时间，以测距节拍（~15.65 ps）为单位。

响应端应答时间字段指示接收Poll DTM与发送Response DTM之间经过的时间。Response DTM应包含由响应端DT锚点测量的响应端应答时间。

响应端ToF结果字段指示响应端DT锚点在上一个测距块中基于DS-TWR测量的发起端DT锚点与响应端DT锚点之间的ToF。当使用DS-TWR进行DL-TDoA时，该字段可以选择性地包含在Response DTM中。

跳数字段是一个可选的无符号整数值，指示从发送Poll DTM的发起端DT锚点到设置公共时间基准且跳数值为零的参考DT锚点的无线跳数。初始时，所有其他DT锚点的跳数值为0xFF，表示它们未与公共块结构同步，无法参与。随时间推移，参考DT锚点通信范围内的DT锚点（即参考DT锚点的无线邻居）应达到跳数值1，表示它们距参考DT锚点仅一跳。类似地，距参考DT锚点两跳的DT锚点应获得跳数值2。该字段用于为簇间同步构建时间同步树状结构。跳数字段如何被DT锚点使用的详细说明参见第G.2节。

锚点位置字段指示发送DTM的DT锚点的地理位置。该字段的第一个字节指示锚点位置所表示的坐标系统类型。每种坐标系统以不同格式指示锚点位置。

表37 - Poll或Response DTM中包含的锚点位置

如果坐标系统类型为0x00，则锚点位置以WGS-84坐标系统表示，包括表示锚点位置的纬度、经度和海拔。

锚点纬度和经度值为33位长，使用Q9.24格式编码，包含1位符号位、8位整数部分和24位小数部分，如图34所示。符号也是二进制补码表示的一部分。

锚点纬度字段指示DT锚点地理位置的纬度值。该值的范围为[-90, 90]，分辨率约为6.66 mm。

锚点经度字段指示DT锚点地理位置的经度值。该值的范围为[-180, 180]，分辨率与锚点纬度相同。

图34 - WGS-84坐标系统中锚点位置纬度和经度的位格式

如果坐标系统类型为0x01、0x03、0x04和0x05，则锚点位置以笛卡尔坐标系中的相对坐标系表示，包括锚点的x、y和z位置。

图35 - WGS-84坐标系统中锚点位置海拔的位格式

锚点海拔字段指示DT锚点地理位置的海拔值。该字段为30位长，使用Q9.21格式编码，包含1位符号位、8位整数部分和21位小数部分，如图35所示。符号也是二进制补码表示的一部分。锚点海拔的单位为千米，该值的分辨率约为0.476 mm。

表38 - 坐标系统类型字段值为0x00时的类型相关坐标字段

锚点X字段指示DT锚点的X坐标值，单位为毫米。1位指示符号，27位表示整数部分值，采用二进制补码表示。

锚点Y字段指示DT锚点的Y坐标值，单位为毫米。1位指示符号，27位表示整数部分值，采用二进制补码表示。

锚点Z字段指示DT锚点的Z坐标值，单位为毫米。1位指示符号，23位表示整数部分值，采用二进制补码表示。如果坐标系统类型为0x04、0x05，Z坐标值应与重力对齐。

简而言之，Q28.0用于编码X和Y坐标的毫米值，Q24.0用于编码Z坐标的毫米值。

坐标系统0x02、0x03和0x05分别以WGS-84和相对坐标系报告锚点位置，但包含关于部署锚点高度（即Z元素）的扩展信息。因此，这些坐标系统分别遵循表38和表39，但额外包含表40中所示的Z元素信息。

表39 - 坐标系统类型字段值为0x01、0x03、0x04和0x05时的类型相关坐标字段

表40 - 坐标系统0x02、0x03或0x05的Z元素扩展

锚点楼层号（Anchor Floor Number）字段指示锚点的楼层号。值越大表示楼层越高，整数值近似于场地中使用的楼层号标签（例如，楼梯间和电梯中的楼层号，如果存在）。该字段以Q10.4格式报告（1位符号位、9位整数部分和4位小数部分），每个位增量代表1/16层，因此覆盖范围(-512 m, 512 m)。十进制值-8192表示未知的楼层号。十进制值8191表示锚点楼层为8191/16层或更多（511.9375 m或更多）。十进制值-8191表示锚点楼层为-8191/16层或更少（-511.9375 m或更少）。

预计移动（Expected to Move）字段指示锚点位置是否预计会改变。值0表示锚点位置预计不会改变，值1表示锚点位置预计会改变。值2表示锚点的移动模式未知。值3为保留值。

锚点楼层以上高度（Anchor Height Above Floor）字段指示锚点在楼层以上的高度。该字段以Q12.12格式报告（1位符号位、11位整数部分和12位小数部分），每个位增量代表1/4096 m（0.24 mm），因此覆盖范围(-2048 m, 2048 m)。十进制值-8388608表示未知的锚点楼层以上高度。十进制值-8388607表示锚点楼层以上高度为-2048 m（舍入到最接近的整数）或更少。值8388607表示锚点楼层以上高度为2048 m（舍入到最接近的整数）或更多。

锚点楼层以上高度不确定度值为0表示未知的锚点楼层以上高度不确定度。值25或更高为保留值。1到24的值表示实际锚点楼层以上高度a按以下方式界定：

h - 2¹¹ - u ≤ a ≤ h + 2¹¹ - u

其中h为锚点楼层以上高度字段的值（单位为1/4096 m），u为锚点楼层以上高度不确定度字段的值。

如果锚点楼层以上高度字段指示未知的锚点楼层以上高度，则锚点楼层以上高度不确定度字段设置为0。

可选的活动测距轮次信息字段（表41）通知接收方DT锚点或DT标签关于DT锚点作为发起端或响应端DT锚点参与的测距轮次。

表41 - DTM中包含的活动测距轮次信息字段

活动测距轮次列表长度字段指示以下活动测距轮次列表字段的元素数量。该值表示发送此字段的DT锚点除当前测距轮次外参与的簇数量。

活动测距轮次列表字段指示发送此字段的DT锚点参与的测距轮次的轮次索引值列表。发送此字段的当前测距轮次的轮次索引不包含在此列表中。DT标签可以使用此字段通过识别相邻簇使用的测距轮次的轮次索引值来更新活动测距轮次列表。

6.2.11.3 AoA测量消息

对于AoA测量，OWR消息类型为0x5，OWR消息类型相关有效载荷字段应按表42定义构建。

表42 - AoA测量消息的OWR消息类型相关有效载荷

消息控制字段应按表43所示格式化。

表43 - AoA测量消息的消息控制字段

RFRAME数量（Number of RFRAMEs）字段指示在同一测距轮次中发送的RFRAME数量，以减少FiRa设备测量的AoA值的偏差。该字段的值应大于或等于MIN_FRAMES_PER_RR的值，且在同一测距轮次内的每个AoA测量消息中该值不应改变。

发送此AoA测量消息的FiRa设备应发送由此参数指定数量的RFRAME。两个连续RFRAME之间的间隔由帧间间隔（Inter-Frame Interval）确定。

接收AoA测量消息的FiRa设备通过测距轮次中第一个AoA测量消息中包含的该字段值获知后续RFRAME的数量。测距轮次中的多个RFRAME用于减少FiRa设备测量的AoA测量值的偏差。

帧间间隔字段指示测距块中发送的RFRAME之间的间隔，单位为1200 RSTU（=1ms）。

块索引指示当前测距块的索引。在同一个测距块中发送的RFRAME应具有相同的值。块索引的值应每个测距块递增。

块持续时间字段指示测距块的持续时间，单位为1200 RSTU（=1ms）。

6.2.12 数据消息（DM）

对于数据消息（DM），头部IE的Content字段应按照表4定义构建。

DM有效载荷IE也可以搭载在表6中定义的任何消息上。在这种情况下，应仅使用一个头部IE，后跟主消息（例如RIM、RRM）的有效载荷IE，再后跟DM的有效载荷IE。

DM有效载荷IE应按表44规定构建。

表44 - DM的有效载荷IE

厂商OUI字段的值应为0x5A18FF。如果厂商OUI字段的值不是0x5A18FF，FiRa设备应忽略该消息。

UWB消息ID字段应设置为0x8以指示DM。

控制器应仅在启动或管理专用数据传输时将DM类型设置为0x1，参见第5.9.12.2节的DTPCM类型。

DM类型字段指定数据消息的类型，从而分类Content字段中包含的有效载荷。

Content字段大小可变，其格式和内容取决于DM类型。Content字段的可变字段在第5.9.12.1节中针对有效载荷类型进行规定。

6.2.12.1 DM类型有效载荷的Content字段格式

如果DM类型为0x0（有效载荷），则Content字段应使用表45中规定的长度和值编码构建。

表45 - DM类型有效载荷的Content字段格式

有效载荷大小编码以下有效载荷字段的大小，应包含以下有效载荷字段的实际大小（以字节为单位）。因此，有效载荷大小可在0到65535字节之间变化。

有效载荷字段包含MDSDU或其一部分。

6.2.12.2 DM类型数据传输协议控制消息的Content字段格式

DM类型DTPCM（参见表45）的Content字段格式和内容应按表46规定构建。

要启动数据传输，控制器应传输DTPCM（另参见第5.9.12节）。DTPCM包含用于管理参与FiRa设备、测距时隙分配和停止数据传输的数据传输协议管理列表（DTPML）。

表46 - 数据传输协议控制消息内容字段

数据传输控制字段分为三个子字段：

• 位0编码这是启动数据传输的首个DTPCM，还是正在进行的数据传输期间传输的后续DTPCM。
• 位1编码每个元素中包含的MAC地址大小为16位还是64位。
• 位2-4编码使用的测距时隙数量。可以从定义的大小中选择一个，以适应涉及的受控器数量并根据用例进行调整。
• 位5至7为RFU

DTPML元素大小字段编码DTPML中一个元素的大小（以字节为单位）。

DTPML长度字段指示DTPML中的元素数量N。

DTPML包含N个大小为DTPML元素大小的元素。元素格式应按表47定义。

控制器不应在表47定义的DTPML元素内添加任何额外字节。受控器应忽略表47定义的DTPML元素内的任何额外字节。

表47 - 数据传输协议管理列表（DTPML）格式

MAC地址字段：包含MAC地址。其大小为16或64位，如数据传输控制字节的位1中所声明。元素中的所有其他参数适用于具有此MAC地址的FiRa设备。

时隙位图（Slot Bitmap）字段：时隙位图包含由该元素的MAC地址标识的FiRa设备的测距时隙分配。时隙位图中的每一位代表一个测距时隙。时隙位图的第一位对应紧接在包含DTPCM的测距时隙之后的测距时隙。例如，如果DTPCM在测距时隙x中发送，则时隙位图的第一位对应测距时隙x+1。如果某位设置为0b1，则相应的测距时隙分配给该元素的FiRa设备用于数据传输。如果某位设置为0b0，则相应的测距时隙不分配给该元素的FiRa设备用于数据传输。FiRa设备不应在未分配给自身的测距时隙中发送消息。

停止数据传输（Stop Data Transfer）字段：指定该元素的FiRa设备的数据传输是否将继续或停止。当停止数据传输字段的值为0b0时，该元素FiRa设备的数据传输应继续。当停止数据传输字段的值为0b1时，该元素FiRa设备的数据传输应停止。在这种情况下，控制器应将时隙位图的每一位设置为0b0。停止数据传输字段设置为0b1的元素中MAC地址对应的FiRa设备应忽略时隙位图字段，并应停止在此数据传输中的通信。

控制器和受控器应支持SP0和SP1 PPDU（PHY协议数据单元）配置。如果选择SP1 PPDU配置，则每个块的首个DTPCM应在SP0 PPDU格式中传输，CFP的所有剩余帧（包括任何额外的DTPCM）应在SP1 PPDU格式中传输。

6.2.13 控制消息类型3

对于控制消息类型3，头部IE的Content字段应按照表4定义构建。此消息仅适用于HUS模式。

控制消息类型3的有效载荷IE内容字段应按表48规定构建。

表48 - 控制消息类型3的有效载荷IE内容字段

厂商OUI：应设置为值0x5A18FF。

UWB消息ID：应设置为0x3以指示此消息为控制消息。

停止会话（Stop Session）：指示HUS控制器是否停止HUS会话。如果停止会话位设置为0b0，则会话继续。如果设置为0b1，则HUS会话停止。所有参与此HUS测距轮次的设备（即接收到控制消息类型3的设备）应停止参与HUS会话。

版本字段：此字段包含此功能的主版本号。本规范中定义的此功能的当前版本为1。HUS控制器应将版本字段的值设置为0b001。实现此版本功能的HUS受控器应接受版本字段值0b001。

步长字段：指示跳过的块数。

消息控制字段：参见表49。

轮次索引字段：指示将在下一个测距块中使用的测距轮次的轮次索引。

RRML字段：此列表包含此HUS测距轮次的每个HUS测距阶段的一个元素。RRML的每个元素包含该HUS测距阶段的时隙分配，如表50定义。HUS控制器可以在不同测距轮次之间添加、删除或修改HUS测距阶段。

表49 - 控制消息类型3的消息控制字段

跳频模式字段：指示下一个测距轮次是否启用跳频模式。

RRML大小字段：指示RRML的大小（以字节为单位）。

RRML一个元素的结构和字段定义在表50中定义。

表50 - 测距轮次管理列表一个元素的结构

阶段指示器（Phase Indicator）：如果设置为0b0则为CFP，如果设置为0b1则为CAP。受控器可以使用阶段指示器位设置来确定是否参与同一控制器的CAP。

MAC地址模式：定义以下设备MAC地址字段是短地址还是扩展地址大小，即16或64位。

时隙索引起始（Slot Index Start）字段：包含该HUS测距阶段在此测距轮次中的起始时隙索引。

时隙索引结束（Slot Index End）字段：包含该HUS测距阶段在此测距轮次中的结束时隙索引。

时隙索引起始和时隙索引结束表示HUS测距阶段的总持续时间。

阶段会话ID（Phase Session ID）：包含与该HUS测距阶段关联的HUS辅助会话的32位标识符。

设备MAC地址：包含被指定为该HUS测距阶段中执行的HUS辅助会话控制器的FiRa设备的MAC地址。该字段的大小如MAC地址模式字段中所声明。

如果RRML中的元素数量导致超过测距管理消息（RMM）（控制消息类型3）测距时隙中的总体PSDU大小，则该时隙中RMM帧的帧待处理（Frame Pending, FP）位应设置为'1'，以指示以下时隙包含配置了该块的额外RRML元素的RMM。如果没有待处理的阶段信息要在该测距块的RMM中传输，则帧待处理位应设置为'0'。

以下规则适用于RMM传输中FP位的使用：

• 应使用头部IE传输RMM段。厂商OUI、会话ID应对所有RMM段保持相同；STS索引应递增。
• RMM段的有效载荷IE应以相同的厂商OUI、UWB消息ID、停止会话、步长和轮次索引值传输。
  • RRML大小应包含与该时隙中传输的元素数量相对应的值。
• 如果没有待处理的RRML传输，则FP位值应设置为'0b0'，指示该测距块的RMM传输结束。

图36 - HUS测距块中RMM的FP位使用示例

6.3 MAC数据传输模式

FiRa定义了使用所有测距模式在FiRa设备之间进行数据传输。MAC层从上层接收MDSDU用于数据传输，并在接收数据时将MDSDU发送到上层。MDSDU包含上层数据，在一个或多个数据消息（DM）有效载荷IE（DM PIE）中传输。MDSDU的内容超出本规范范围。

MDSDU可以由以下设备传输：

• 控制器或受控器在时间调度或基于竞争的测距中（参见第5.10.1节）。
• UL-TDoA设备（参见第5.4.3.1节）。
• 控制器或受控器在专用数据传输中（参见第5.10.2节）。
• OWR AoA测量中的广播方（参见第5.4.3.3节）。
• DL-TDoA中的DT锚点（参见第5.4.3.2.5节）。

6.3.1 测距期间的数据传输

在此模式下，MDSDU的内容可以机会性地搭载在现有UWB消息上。MDSDU承载在专用DM有效载荷IE中，该IE应跟随在UWB消息的有效载荷IE之后。包括MHR、MAC有效载荷和MFR在内的组合消息大小不得超过最大PSDU大小。

发送应用数据后，进行中测距轮次内后续UWB消息的接收可用作隐式数据接收确认（ACK）。

MDSDU传输可以是双向的，即发起端和响应端在同一个测距轮次中发送各自的MDSDU。

隐式确认是否可用取决于底层使用的测距方法。

表51 - 用于数据传输和确认的测距消息

表51显示了可用于附加DM的主要UWB消息（针对不同测距方法）。表的第三列指示可用作隐式ACK的UWB消息。

对于延迟模式，如果需要测距期间的数据传输，RFRAME配置应设置为SP1。

图37中的示例序列图说明了使用非延迟DS-TWR在测距期间进行MDSDU传输。在上一个测距轮次中，发起端使用RIM消息将其MDSDU发送给响应端。通过发送RRM，响应端隐式确认了接收。

在后续测距轮次中，响应端将MDSDU随RRM消息一起发送，然后通过成功接收来自发起端的RFM进行隐式确认。

图37 - 非延迟DS-TWR测距期间数据传输示例

在OWR测距轮次中，应使用"数据重复计数"配置来配置在连续测距轮次中多次发送相同MDSDU。

图38显示了一个短MDSDU如何放入单个DM中并在单个帧（可以是CM或RIM等）中发送。图39显示了一个长MDSDU如何必须分段为2个DM。注意，图38和图39假设无安全。这些图中也未详细说明其他PIE。

图38 - MSDU包含在单个UWB帧中且不分段的示例

图39 - MDSDU拆分为两个DM并在两个UWB帧中传输的示例

FiRa设备应每个测距轮次仅传输一个MDSDU。整个MDSDU应在该测距轮次内传输。

如果MDSDU无法放入单个DM有效载荷IE，FiRa设备应将其分段到多个DM有效载荷IE中。

即使MDSDU可以放入单个DM有效载荷IE，FiRa设备也可以将其分段到多个DM有效载荷IE中。

使用MDSDU分段时，适用以下规则：

• MDSDU的每个分段应作为DM有效载荷IE传输。
• 分段应按递增顺序传输（即先传输分段1，然后传输分段2，以此类推）。
• 所有分段应在一个测距轮次内传输。
• 从同一发送FiRa设备接收的所有MDSDU分段应在测距轮次结束时重新组装并作为MDSDU转发。
• 同一分段不应在同一个测距轮次内重传。

6.3.2 专用数据传输

为减少两个端点之间应用数据交换的时间，可能需要将应用数据的传输与测距解耦。为此，测距时隙被分配用于专用数据传输。数据传输在每隔一个测距轮次中使用第5.9.12.2节定义的数据传输协议控制消息（DTPCM）启动。DTPCM包含用于管理参与FiRa设备和时隙分配的数据传输协议管理列表（DTPML）。在数据传输期间，所有消息应具有0x8的UWB消息ID（即数据消息），如第5.9.12.1节定义。所有帧应在多用途帧中传输，MAC头如第6.3.1.1节定义。

数据传输的启动：

• 要启动数据传输，控制器应在CFP的第一个测距时隙中传输DTPCM，如第5.6.3节对混合UWB会话的定义或第5.6.1节对时间调度模式的定义。
• 受控器应接受作为混合UWB会话或时间调度模式一部分的CFP第一个测距时隙中的DTPCM。

图40说明了数据交换的消息流。控制器使用DTPCM启动数据传输。在根据DTPCM分配给控制器的第一个测距时隙中，传输从上层（UL）接收的完整MDSDU（MDSDU1）。受控器接收MDSDU1并将其转发到自身的UL。下一步，在分配给控制器的下一个测距时隙中传输MDSDU2。受控器将接收包含MDSDU2的DM帧并将其转发到其UL。最后，受控器也可以在分配给该受控器的测距时隙中发送从UL接收的自身MDSDU。控制器接收该消息并将MDSDU3转发到UL。

图40 - 数据传输示例

控制器可以发送进一步的DTPCM以动态扩展或修改（例如，更改测距时隙分配或甚至添加额外的受控器）数据传输。当当前分配用于数据传输的测距时隙结束时或当轮次结束时（轮次定义参见第1.1节），数据传输结束。控制器不应将数据传输扩展到超过当前轮次持续时间。

如第5.9.12.2节定义的DTPML是DTPCM的一部分，包含一个或多个FiRa设备的测距时隙分配信息。DTPCM的配置和测距时隙分配超出本规范范围。

以下规则适用于数据传输的管理：

• DTPML的第一个元素应包含控制器的MAC地址。因此，它包含控制器的测距时隙分配。
• 控制器应为每个FiRa设备在DTPML中添加最多一个元素。
• 控制器应将一个测距时隙仅分配给一个FiRa设备。
• 在测距轮次期间，控制器可以通过在先前DTPCM分配给控制器的测距时隙中发送进一步的DTPCM来更新测距时隙分配。
  • FiRa设备的任何测距时隙分配变更应由控制器发送包含该FiRa设备DTPML条目的更新DTPML来执行。
  • 获得新时隙位图（接收进一步DTPCM）的FiRa设备应用此新时隙位图替换现有时隙位图（覆盖）。
  • 未包含在DTPML中的FiRa设备应根据其当前分配的时隙位图继续操作。
• 每个受控器应至少读取与其自身MAC地址匹配的DTPML条目以及控制器的DTPML条目。
  • 受控器应准备好接收分配给控制器的测距时隙中包含的帧。

图41至图44显示了16个测距时隙位图大小的不同测距时隙分配示例。图41中的示例显示了测距时隙分配的基本功能原理。顶部显示了一个控制器和三个受控器的完整测距时隙分配。每个单元格包含相应FiRa设备的颜色和字母。空白白色单元格对应未分配的测距时隙。底部可视化了DTPML中包含的各个时隙位图的构建方式。值为"1"的单元格表示该测距时隙分配给相应的参与FiRa设备。空单元格表示相应的测距时隙未分配给相应的参与FiRa设备。这对应于实际时隙位图字段中相应位位置的值0b0。

图41 - 三个受控器和一个控制器的测距时隙分配单个DTPCM示例

另一个示例是向正在进行的传输中添加新的受控器。原因可能是MAC有效载荷大小不足以寻址所有受控器。在图42的示例中，控制器通过在索引为5的测距时隙中发送另一个DTPCM将受控器Z添加到数据传输中。控制器负责仅将尚未分配给其他FiRa设备的测距时隙分配给受控器Z。控制器还必须为此数据传输会话的新添加测距时隙分配新的测距时隙（时隙17至21）。

图42 - 多个DTPCM向数据传输会话添加更多FiRa设备的示例

图43显示了另一个示例，如何向数据传输中添加更多受控器并更新已参与数据传输的受控器的测距时隙分配。在此示例中，更新了受控器X的测距时隙分配，并在第一次测距时隙分配结束之后添加了更多测距时隙。此外，受控器Z被添加到数据传输中。控制器将尚未分配的测距时隙分配给受控器Z（索引为9的时隙），并将先前分配给受控器X和控制器自身的测距时隙重新分配给受控器Z（索引为14和16的时隙）。

图43 - 向数据传输会话添加FiRa设备并重新分配测距时隙的示例

图44显示了另一个示例，在数据传输会话期间对受控器X的测距时隙分配进行了更新，并将先前分配给受控器Y和控制器自身的时隙重新分配给受控器Z。

图44 - 数据传输会话期间测距时隙分配更新和重新分配的示例

7 测距块与轮次结构 / 帧格式

6 需求

6.1 前提条件

在测距之前，对端设备之间应交换设备能力。

6.1.1 UWB配置参数

FiRa设备应按照表52中的UWB配置参数进行配置（例如，通过上层）。

表52 - UWB配置参数

短MAC地址用于指示UWB消息的目标设备和/或源设备。扩展MAC地址用作CCM*（计数器模式加密和密码块链接消息认证码的扩展）的nonce的一部分，如第6.4.5节所述。

（空白）
本节有意留空。

6.2 MAC层需求

FiRa设备可以为调度模式和相应的测距方法选择一个MAC功能集。选择设备类型和设备角色的组合，或仅选择设备角色（如适用）以认证合规性非常重要，如下表所述。

下表提供了强制和可选MAC功能的概述，以确保使用相同功能集的设备之间的互操作性。

表53 - 表54和表55中使用的图例

表54 - 作为所选测距模式函数的功能集适用性定义

表55 - 设备类型与设备角色互操作性

除另有说明外，以下需求均指带内通信。

6.3.1 MAC帧格式

SP0或SP1帧的通用MAC帧格式应由MAC头和MAC尾组成，如图45所示。更多信息请参见[IEEE_802_15_4z_2020]第7节。

图45 - FiRa中的通用MAC帧格式（改编自[IEEE_802_15_4_2020]图7-1）

帧控制字段定义了特定MAC头字段是否存在。此配置取决于第5.9节定义的UWB消息类型，并在后续章节中进一步规定。

MAC头使用零长度内容字段的Header Termination IE终止，如[IEEE_802_15_4_2020]标准所规定。图46显示了该IE的内容。

图46 - MAC头终止IE（改编自[IEEE_802_15_4_2020]图7-21）

有效载荷IE使用零长度内容字段的Payload Termination IE终止，如[IEEE_802_15_4_2020]所规定。图47显示了该IE的内容。如果数据有效载荷不存在，则可以省略Payload Termination IE。

图47 - 有效载荷终止IE（改编自[IEEE_802_15_4_2020]图7-47）

终止IE应按照[IEEE_802_15_4_2020]规范表7-6的要求包含。

TWR的MAC帧格式详细信息定义在第6.3.1.1节和第6.3.2节。OWR的MAC帧格式详细信息定义在第6.3.4节。

6.3.1.1 MAC头

6.3.1.1.1 帧控制

帧控制字段的格式应如表56所示。

表56 - 数据帧的帧控制字段

表57 - 多用途帧的帧控制字段

当使用的帧类型为数据帧时，帧控制目标地址模式字段应指示使用短地址，且源地址不应存在。

当使用的帧类型为多用途帧时，在竞争模式或OWR模式（OWR AoA测量和DL-TDoA）中使用时应包含源地址字段。对于MAC数据传输模式，第6.3.3.3.6节定义了何时应存在源地址字段。

当使用的帧类型为多用途帧时，可以包含目标地址字段。

当多用途帧中不存在目标地址字段时，应将其视为广播帧。

6.3.1.1.2 目标地址

6.3.1.1.2.1 目标地址字段包含接收方的短地址或扩展地址，在O2O测距情况下需遵循以下说明：

• 对于O2O测距，控制器应在控制消息中使用受控器的短地址。
• 对于O2O测距，发起方应在报告消息（例如，测量报告消息）中使用响应方的短地址。
• 响应方应在所有响应中使用发起方的短地址。

6.3.1.1.2.2 目标地址字段包含广播短地址或扩展地址（即0xffff或0xffff ffff ffff ffff，如[IEEE_802_15_4_2020]第6.1节所定义），在O2M测距情况下需遵循以下说明：

• 对于O2M测距，控制器应在控制消息中使用广播短地址。
• 对于O2M测距，发起方应在报告消息（例如，测量报告消息）中使用广播短地址。

6.3.1.1.2.3 源地址永远不应设置为0xFFFF或0xFFFF_FFFF_FFFF_FFFF。

6.3.1.1.3 辅助安全头

辅助安全头字段的格式应如表58所示。

表58 - 辅助安全头字段格式

6.3.1.1.4 Header IE

Header IE字段应包含厂商专有Header IE。Header IE字段的格式请参见第5.9节。

6.3.1.2 MAC有效载荷

6.3.1.2.1 有效载荷IE字段应包含厂商专有嵌套IE。有效载荷IE字段的格式请参见第5.9节。

6.3.1.3 MAC尾

6.3.1.3.1 FCS字段包含16位循环冗余校验（CRC）或32位CRC。CRC大小是一个配置参数。FCS计算应使用[IEEE_802_15_4_2020]第7.2.10节描述的算法。默认FCS为16位CRC。

6.3.2 基于块的模式需求

测距块是一个用于测距的时间段，由整数个测距轮次组成[IEEE_802_15_4z_2020]。图48展示了一个包含五个测距轮次并启用轮次跳频的示例测距块结构。此示例中的每个测距轮次包含10个时隙，编号从0到9。

图48 - 示例测距块结构（每块五个测距轮次，每测距轮次十个时隙）

用于指定测距块、轮次和时隙持续时间的时间单位为RSTU。FiRa设备应实现测距块结构，使得相对于PHY时钟的测距块持续时间容差在±100 ppm以内。图49说明了此要求，下面进行更详细的描述：

图49 - 测距块与轮次同步的时序要求

上述时序要求适用于需要与块结构同步的FiRa设备。当块/轮次同步尚未建立时，受控器设备应至少等待一个测距持续时间，以接收第一个测距块中测距轮次由控制器发送的第一条消息。假设M1为测距轮次的第一条消息，这些FiRa设备应从最后接收到的M1推导上述时序，该M1在下文中称为用于块/轮次同步的帧。更具体地：

• FiRa设备应基于前一个测距轮次中用于同步的最后一个适用M1的开始时间，以±100 ppm的容差准备接收新测距轮次的即将到来的消息。
• FiRa设备应将M1前导码的开始作为相应测距时隙的开始，并作为当前测距轮次即将到来的测距时隙的参考时间。

注意，给定 时隙中消息传输的时序精度在[PHY]的需求[PHY-TIM-0050]中定义。

测距块中测距轮次数量的推导公式如下：

其中 ⌊⌋ 表示向下取整函数。

计算每块测距时隙和轮次数时，适用以下规则：

• 当应用向下取整操作时，不足配置时隙持续时间的剩余分数时间持续时间不应被视为一个时隙。因此，该分数时间的STS索引不应递增。
• 不属于测距轮次的剩余时隙应被计入STS索引递增。
• 剩余时隙和剩余分数时间应被计入测距块持续时间。

图50 - 考虑分数时间计入块持续时间的示例块表示

块持续时间、时隙持续时间和轮次持续时间由应用按照表52的规定进行配置。

6.3.2.1 时间调度模式控制器需求

6.3.2.1.1 控制器应充当发起方或响应方。

6.3.2.1.2 当控制消息中存在RDML时，充当发起方的控制器应通过将每个设备的测距角色字段设置为0，将所有对端设备配置为响应方。

6.3.2.1.3 当控制消息中存在RDML时，充当响应方的控制器应通过将该设备的测距角色字段设置为1，将一个对端设备配置为发起方。所有其他设备应通过将测距角色字段设置为0配置为响应方。

6.3.2.1.4 控制器应按照表59中规定的顺序调度UWB消息和RFRAME。表59中的某些UWB消息和/或RFRAME可能并非在所有测距场景中都使用。

6.3.2.1.4.1 当为非延迟TWR的SP1 RFRAME执行动态STS、响应方专有子会话密钥的动态STS、预配置STS或预配置STS的响应方专有子会话密钥生成时，控制器应包含RCP。

6.3.2.1.4.2 当STS配置设置为响应方专有子会话密钥的动态STS或设置为响应方专有子会话密钥的预配置STS时，控制器应为发起方。

表59 - 时隙调度顺序

6.3.2.1.5 控制器应在每个测距测量周期中发送控制消息。

6.3.2.1.6 当使用SS-TWR时，控制器应调度测距发起消息和测距响应消息。

6.3.2.1.7 当使用DS-TWR时，控制器应调度测距发起消息、测距响应消息和测距最终消息。

6.3.2.1.8 当RFRAME使用SP3时，控制器应至少调度一个测距测量报告消息。

6.3.2.1.9 控制器可以调度测距结果报告消息。

6.3.2.1.10 控制器应支持轮次跳频。

6.3.2.1.10.1 如果会话启用了跳频模式（即在会话的整个生命周期内，测量报告消息中的跳频模式字段设置为0b1），控制器应在下一个测距块中使用基于跳频序列的测距轮次。

6.3.2.1.11 控制器可以支持块跨步。

6.3.2.1.11.1 如果控制器和受控器支持块跨步，控制器可以将控制消息的跨步长度字段设置为非零值，以为受控器跳过测距块。

6.3.2.1.11.2 如果控制器和/或受控器不支持块跨步，控制器应将控制消息的跨步长度字段设置为0x00。

6.3.2.1.12 控制器可以支持暂停测距。

6.3.2.1.12.1 如果应用层在测距块中配置了暂停测距条件，控制器进入/退出暂停测距条件不应超过2个测距块。

6.3.2.1.12.2 只要配置为处于暂停测距条件，控制器应发送暂停测距位设置为'1'的CM Type 1。

6.3.2.1.12.3 控制器应存储进入暂停测距条件之前使用的RDML内容。

6.3.2.1.12.4 在暂停测距条件下，CM Type 1不应包含RDML字段，并应将RMDL长度值设置为0。

6.3.2.1.12.5 如果配置为退出暂停测距条件，控制器应发送暂停测距位设置为'0'的CM Type 1，并应包含进入暂停测距条件之前存储的RDML内容。

6.3.2.1.12.6 当控制器处于暂停测距条件时，控制器不应在RP和MRP中发送任何消息。

6.3.2.1.12.7 控制器设备应在进入或退出暂停测距条件时通知应用层。

6.3.2.1.12.8 控制器应按照静态STS、预配置STS和动态STS的情况递增phyStsIndex。

6.3.2.1.12.9 在暂停测距条件下，跨步长度字段应适用。

6.3.2.1.12.10 当启用FiRa跳频且控制器进入暂停测距条件时，控制器应遵循第5.8.2节定义的跳频方案来确定每个测距块中的活动测距轮次。

6.3.2.2 时间调度模式受控器需求

6.3.2.2.1 当控制器配置受控器为响应方时，受控器应充当响应方。

6.3.2.2.2 当控制器配置受控器为发起方时，受控器可以充当发起方。

6.3.2.2.3 受控器应使用控制器通过控制消息分配的时隙。

6.3.2.2.4 受控器应支持轮次跳频。

6.3.2.2.4.1 当从控制器接收到跳频模式字段设置为0b0（即禁用跳频模式）的测量报告消息时，受控器应将接收到的消息的当前测距轮次索引用作下一个测距块的测距轮次索引。否则，受控器应在下一个测距块中使用遵循跳频序列的测距轮次。

6.3.2.2.5 受控器可以支持块跨步。

6.3.2.2.5.1 当支持块跨步时，受控器应跳过控制消息中跨步长度字段指定的测距块数量；值为0表示不跳过任何测距块。

6.3.2.2.6 受控器可以支持暂停测距。

6.3.2.2.6.1 当暂停测距位设置为'1'时，受控器不应进一步参与同一测距轮次，并进入该测距轮次的暂停测距条件。

6.3.2.2.6.2 受控器应在后续测距块中继续与CM Type 1同步。

6.3.2.2.6.3 处于暂停测距条件的受控器在接收到暂停测距位设置为'0'的CM Type 1后，应退出暂停测距条件，并根据CM Type 1消息中存在的RDML参与同一测距轮次的RP和MRP。

6.3.2.2.6.4 受控器设备应在进入或退出暂停测距条件时通知应用层。

6.3.2.2.6.5 受控器应按照静态STS、预配置STS和动态STS的情况递增phyStsIndex。

6.3.2.2.6.6 在暂停测距条件下，跨步长度字段应适用。

6.3.2.2.6.7 当启用FiRa跳频且控制器进入暂停测距条件时，受控器应遵循第5.8.2节定义的跳频方案来确定每个测距块中的活动测距轮次。

6.3.2.3 发起方需求

6.3.2.3.1 O2O SS-TWR with SP3 RFRAME

6.3.2.3.1.1 发起方应在调度的时隙中发送测距发起消息。

6.3.2.3.1.2 当控制器配置时，发起方应在调度的时隙中发送测量报告消息。

6.3.2.3.2 DS-TWR

6.3.2.3.2.1 发起方应满足第6.3.2.3.1节中的需求。

6.3.2.3.2.2 发起方应在调度的时隙中发送测距最终消息。

6.3.2.3.3 O2M测距

6.3.2.3.3.1 发起方应满足第6.3.2.3.1节中的需求。

6.3.2.3.4 ToF报告

6.3.2.3.4.1 发起方应满足第6.3.2.3.1节中的需求。

6.3.2.3.5 AoA报告

6.3.2.3.5.1 发起方应满足第6.3.2.3.1节中的需求。

6.3.2.4 响应方需求

6.3.2.4.1 O2O SS-TWR with SP3 RFRAME

6.3.2.4.1.1 响应方应在调度的时隙中发送测距响应消息。

6.3.2.4.2 DS-TWR

6.3.2.4.2.1 响应方应满足第6.3.2.4.1节中的需求。

6.3.2.4.3 O2M测距

6.3.2.4.3.1 响应方应满足第6.3.2.4.1节中的需求。

6.3.2.4.4 ToF报告

6.3.2.4.4.1 响应方应满足第6.3.2.4.1节中的需求。

6.3.2.4.4.2 响应方应在调度的时隙中发送包含ToF结果的测距结果报告消息。如果响应方由于测距配置而无法计算ToF，则消息中不应存在ToF结果。

6.3.2.4.5 AoA报告

6.3.2.4.5.1 响应方应满足第6.3.2.4.1节中的需求。

6.3.2.4.5.2 响应方应在调度的时隙中发送包含AoA结果的测距结果报告消息。

6.3.2.4.6 时钟频率补偿

6.3.2.4.6.1 在SS-TWR情况下，响应方设备应补偿发起方和响应方之间的CFO，即MRM Type 2和Type 3消息中包含的回复时间应根据测量的CFO进行补偿。发起方设备不应应用任何CFO补偿。

6.3.2.5 竞争模式需求

6.3.2.5.1 UWB消息应以帧类型设置为多用途进行传输。多用途帧格式应符合[IEEE_802_15_4_2020]第7.3.5节。

6.3.2.5.2 FiRa设备应支持SS-TWR。

6.3.2.5.3 FiRa设备可以支持eSS-TWR。

6.3.2.5.4 控制器应充当发起方，并应在测距轮次的测距时隙0中发送CM Type 2作为RIM。

6.3.2.5.5 FiRa设备可以支持aDS-TWR。

6.3.2.5.5.1 控制器可以在CM Type 2有效载荷IE之后包含额外的有效载荷IE作为厂商专有嵌套IE。

6.3.2.5.6 受控器应充当响应方，并应在RP中发送MRM Type 3作为RRM。

6.3.2.5.6.1 受控器可以在MRM Type 3有效载荷IE之后包含额外的有效载荷IE作为厂商专有嵌套IE。

6.3.2.5.7 无法计算AoA的受控器不应在MRM Type 3中包含AoA相关信息。

6.3.2.5.8 参与竞争测距的受控器应支持RML功能。

6.3.2.5.9 以下是使用CM Type 2的RML字段的需求：

6.3.2.5.9.1 控制器可以以其偏好的顺序构造RML。

6.3.2.5.9.2 响应方的MAC地址应为短MAC地址。

6.3.2.5.9.3 RML的大小不应超过CM的可用MAC有效载荷大小。

6.3.2.5.9.4 RML中的元素数量不应超过RRP中的CAP。

6.3.2.5.9.5 当使用RML时，CAP中的可用测距时隙数（CAP大小 - RML大小）不应小于RRP的配置最小CAP值。

6.3.2.5.9.6 在RML中未找到设备MAC地址的响应方应使用RRP的CAP中的可用测距时隙在该测距轮次中发送RRM。

6.3.2.5.10 FiRa设备可以支持非延迟DS-TWR。

6.3.2.5.11 测距会话中CAP大小参数的动态变化取决于实现。

6.3.2.5.12 测距轮次持续时间应在整个测距会话中保持固定。

6.3.2.5.13 多用途帧的帧控制字段应具有表60中定义的以下字段。

表60 - 竞争测距帧控制字段定义

6.3.2.5.13.1 RP中的所有消息应将帧待处理位设置为'0'。

6.3.2.5.13.2 在非延迟DS-TWR测距的RFP阶段中，MRM Type 1应作为RFM发送。

6.3.2.5.13.3 控制器可以在MRM Type 1有效载荷IE之后包含额外的有效载荷IE作为厂商专有嵌套IE。

6.3.2.5.13.4 如果回复时间列表中的元素数量使得MRM Type 1超过RFM测距时隙中的总体PSDU大小，则RFM的帧待处理位应设置为'1'，以指示以下时隙包含该测距轮次RFP中的MRM Type 1消息的RFM。当帧待处理位设置为'1'时，RFP中的以下测距时隙应包含MRM Type 1消息，其回复时间列表包含在当前和之前MRM消息中未出现的设备（该MRM消息在该测距轮次的RFP中传输）。如果该测距轮次RFP中没有待传输的回复时间列表，则帧待处理位应设置为'0'。

6.3.2.5.13.5 MRP中的时隙数应与MRM Type 1消息的回复时间列表长度值相同。

6.3.2.5.13.6 回复时间列表的第N个元素应对应MRP的第N个测距时隙。

6.3.2.5.13.7 MRM Type 1消息中的第一个往返时间应对应回复时间列表中列出的第一个响应方。

6.3.2.5.13.8 如果响应方的MAC地址在MRM Type 1消息的回复时间列表中未找到，则该响应方不应在MRP中响应。

6.3.2.5.13.9 响应方应在MRP中使用RRRM SP0数据帧。

6.3.2.5.13.10 响应方可以在MRP中包含额外的有效载荷IE作为厂商专有嵌套IE。

6.3.2.5.14 源地址和目标地址

6.3.2.5.14.1 UWB消息应同时包含源地址和目标地址。

6.3.2.5.14.2 测距轮次中使用的所有消息的地址模式应为短地址模式。

6.3.2.5.14.3 发起方应使用其MAC地址作为源地址，广播地址作为目标地址。

6.3.2.5.14.4 发起方应支持短源地址和目标地址。

6.3.2.5.14.5 响应方应使用其MAC地址作为源地址，发起方的MAC地址作为目标地址。

6.3.2.5.14.6 响应方应支持短源地址和目标地址。

6.3.2.5.15 （空白）本节有意留空。

6.3.2.5.16 在DS-TWR模式中，作为RRM的MRM Type 3的回复时间存在字段值应设置为0（不存在）。

6.3.2.5.17 测距轮次应使用静态STS方法进行STS生成。

6.3.2.5.18 测距轮次的RFRAME应使用SP1作为RFRAME配置。

6.3.2.5.19 控制器可以使用块跨步功能。

6.3.2.5.20 控制器可以使用跳频模式功能。

6.3.2.5.21 控制器应通过将停止测距字段设置为'1'来指示测距会话的关闭。

6.3.2.5.22 第6.1.1节中规定的UWB受控器信息参数表不适用。

6.3.2.5.23 Tx偏移功能支持

6.3.2.5.23.1 控制器/发起方可以支持Tx偏移功能。

6.3.2.5.23.1.1 如果发起方支持Tx偏移功能，则应始终在允许的Tx偏移字段中启用Tx偏移0。

6.3.2.5.23.2 响应方可以支持Tx偏移功能。

6.3.2.5.23.2.1 如果响应方不支持Tx偏移功能，则应在测距时隙的开始处发送其响应消息。

6.3.2.5.24 Tx抖动窗口功能支持

6.3.2.5.24.1 FiRa设备可以支持Tx抖动窗口功能。

6.3.2.5.24.2 如果控制器/发起方启用Tx抖动窗口而响应方不支持Tx抖动窗口功能，则响应方应在测距时隙的开始处发送其响应消息。

6.3.3 数据传输需求

6.3.3.1 通用数据传输需求

6.3.3.1.1 当发送DM有效载荷IE时，DM有效载荷IE应携带其自身的消息ID（即0x8）。

6.3.3.1.2 FiRa设备应按照第6.4.5节的规定对DM有效载荷IE使用认证加密方法。

6.3.3.1.3 当在同一测距轮次中使用CFP测距阶段和CFP专用数据传输时（即混合模式），两个阶段可以具有相同的STS生成方法和认证加密方法。

6.3.3.2 测距期间数据传输需求

6.3.3.2.1 FiRa设备可以连同测距轮次的任何UWB消息一起发送DM有效载荷IE。

6.3.3.2.2 当测距消息中包含DM有效载荷IE时，应放置在UWB消息有效载荷IE之后。

6.3.3.3 专用数据传输需求

6.3.3.3.1 FiRa设备应使用第6.4.4节规定的STS生成模式和STS索引管理。

6.3.3.3.2 CFP专用数据传输阶段仅包含单个测距轮次。使用静态STS生成的FiRa设备不应在CFP专用数据传输阶段期间重置phyStsIndex。

6.3.3.3.3 控制器和受控器应支持SP0和SP1 PPDU配置。

6.3.3.3.4 如果选择SP0 PPDU配置，则CFP的所有帧（包括DTPCM）应在SP0 PPDU内传输。

6.3.3.3.5 如果选择SP1 PPDU配置，则每个块的第一个DTPCM应在SP0 PPDU内传输，CFP的所有剩余帧（包括任何额外的DTPCM）应在SP1 PPDU内传输。

6.3.3.3.6 控制器和受控器应以帧类型设置为多用途发送UWB消息。帧控制字段应遵循第6.3.1.1.1节中的定义。

6.3.3.3.6.1 当发送MDSDU（有效载荷）时，控制器和受控器应将MAC头中的源地址模式字段设置为0b00（不存在），详见第6.3.1.1.1节。

6.3.3.3.6.2 当接收MDSDU（有效载荷）时，控制器或受控器应使用DTPCM的DTPML中为该时隙定义的MAC地址来解密MAC有效载荷。注意，帧MAC头中的源地址字段不被使用。

6.3.3.3.6.3 当发送DTPCM时，控制器应将MAC头的源地址模式字段设置为0b10或0b11（存在短地址或扩展地址），详见第6.3.1.1.1节。

因此，控制器应在源地址字段中发送其MAC地址。

6.3.3.3.6.4 当接收DTPCM时，受控器应使用帧MAC头中的源地址（如第6.3.1.1.1节所定义）作为输入来解密MAC有效载荷。

6.3.3.3.7 HUS会话期间的数据传输需求：

6.3.3.3.7.1 要开始数据传输，控制器应按照第5.9.12节的定义在CFP的第一个测距时隙中发送DTPCM。

6.3.3.3.7.2 受控器应在CFP的第一个测距时隙中接受DTPCM。

6.3.3.3.7.3 当接收DTPCM时，受控器应将CM Type 3的RRML中为HUS测距阶段定义的设备MAC地址（如第5.9.13节所定义）与帧MAC头中的源地址进行比较。如果两者相同，则受控器应继续正常操作。如果地址不同，受控器不应参与此HUS测距阶段。

6.3.3.3.8 专用数据传输会话需求：

6.3.3.3.8.1 要开始专用数据传输，控制器应按照第5.6.1节的定义在时间调度模式的第一个测距时隙中发送DTPCM。

6.3.3.3.8.2 受控器应在时间调度模式的第一个测距时隙中接受DTPCM。

6.3.3.3.9 控制器可以发送更多的DTPCM来动态扩展或修改（例如，更改测距时隙分配或甚至添加额外的受控器）数据传输。控制器不应将数据传输扩展到超过当前测距轮次持续时间。

6.3.3.3.10 控制器不应在表47定义的DTPML元素内添加任何额外的字节。

6.3.3.3.11 受控器应忽略表47定义的DTPML元素内的任何额外字节。

6.3.3.3.12 受控器应忽略与当前测距轮次最后一个时隙之后的时隙相关联的时隙位图中的任何位。

6.3.3.3.13 如果时隙位图中的某位设置为值0b1，则具有该元素MAC地址的FiRa设备可以在对应于该位位置的测距时隙中发送其DM。

6.3.3.3.14 FiRa设备永远不应在未分配给自己的测距时隙中发送消息。

6.3.3.3.15 当停止数据传输字段的值为0b1时，应停止该元素对应的FiRa设备的数据传输。在这种情况下，控制器应将时隙位图的每一位设置为0b0。

6.3.3.3.16 停止数据传输字段设置为0b1的元素的MAC地址对应的FiRa设备应忽略时隙位图字段，并不再参与此会话。

6.3.3.3.17 以下规则适用于数据传输的管理：

6.3.3.3.17.1 DTPML的第一个元素应包含控制器的MAC地址。因此，它包含控制器的测距时隙分配。

6.3.3.3.17.2 控制器应为每个参与的FiRa设备在DTPML中添加且仅添加一个元素。

6.3.3.3.17.3 控制器应将一个测距时隙仅分配给一个FiRa设备。

6.3.3.3.17.4 在测距轮次期间，控制器可以通过在先前DTPCM中分配给控制器的测距时隙中发送更多的DTPCM来更新测距时隙分配。

6.3.3.3.17.4.1 对FiRa设备的任何测距时隙分配变更应由控制器发送包含该FiRa设备DTPML条目的更新DTPML来执行。

6.3.3.3.17.4.2 获得新时隙位图分配的FiRa设备（接收到更多DTPCM）应将现有时隙位图替换为此新时隙位图（覆盖）。

6.3.3.3.17.4.3 未包含在更新DTPML中的FiRa设备应根据其当前分配的时隙位图继续操作。

6.3.3.3.17.5 每个受控器应至少读取匹配其自身MAC地址的DTPML条目以及控制器的DTPML条目。

6.3.3.3.17.6 受控器应准备接收分配给控制器的测距时隙中包含的帧。

6.3.4 OWR需求

OWR消息（UTM、DTM和AoA测量消息）应为使用第6.3.1节定义的MAC帧格式的SP1多用途RFRAME。帧控制字段在后续章节中针对每种OWR消息类型进行定义。OWR RFRAME不应包含Header IE。MHR和有效载荷IE分别按照第6.3.1节的规定使用Header Termination IE和Payload Termination IE终止。

以下小节定义了每个OWR用例的具体需求。

6.3.4.1 DL-TDoA需求

DL-TDoA需求根据设备角色分为：DT-锚点（第6.3.4.1.1节）和DT-标签（第6.3.4.1.3节）。此外，第6.3.4.1.2节定义了DT-锚点在引导时间和簇间同步期间的具体需求。

6.3.4.1.1 DT-锚点需求

6.3.4.1.1.1 DT-锚点应支持发起方和响应方角色。

6.3.4.1.1.1.1 DT-锚点应允许在同一个测距块的一个测距轮次中配置为发起方，在另一个测距轮次中配置为响应方。

6.3.4.1.1.2 DT-锚点应发送帧控制字段格式如表61所示的DTM。

表61 - DL-TDoA消息（DTM）的帧控制字段定义

6.3.4.1.1.3 DT-锚点应发送同时包含源地址和目标地址字段的DTM。

6.3.4.1.1.4 DT-锚点应支持短地址模式。

6.3.4.1.1.5 DT-锚点可以支持扩展地址模式。

6.3.4.1.1.6 发起方DT-锚点应在其Poll或Final DTM中将目标地址设置为广播地址（例如，短地址模式中的0xFFFF）。

6.3.4.1.1.7 响应方DT-锚点应在Response DTM中将发起方DT-锚点的MAC地址设置为目标地址。

6.3.4.1.1.8 DT-锚点应发送不超过配置PRF模式支持的最大有效载荷大小的DTM。

6.3.4.1.1.9 DT-锚点应使用静态STS生成模式发送DTM。

6.3.4.1.1.10 如果Response DTM的消息控制字段中的TX时间戳类型字段设置为1（即公共时间基准），则响应方DT-锚点应包含转换到测距轮次发起方DT-锚点时间域的Response DTM的TX时间戳。

6.3.4.1.1.11 响应方DT-锚点应在Poll DTM中包含的响应方DT-锚点管理列表字段分配的测距时隙中发送其Response DTM。

6.3.4.1.1.12 关于6.3.4.1.1.11，如果响应方DT-锚点管理列表字段包含测距时隙索引字段，响应方DT-锚点应在其MAC地址关联的、测距时隙索引字段中指定的测距时隙中发送其Response DTM。

6.3.4.1.1.13 关于6.3.4.1.1.11，如果响应方DT-锚点管理列表字段不包含测距时隙索引字段，响应方DT-锚点应根据响应方DT-锚点管理列表中MAC地址的顺序获取其应发送Response DTM的时隙索引。换言之，响应方DT-锚点管理列表中第k个MAC地址的响应方DT-锚点应在测距轮次的第k个时隙中发送。

例如，列表中的第一个响应方DT-锚点应在测距轮次的时隙1中发送其Response DTM。

6.3.4.1.1.14 如果Poll DTM中消息控制字段的DL-TDoA消息交换位设置为零（SS-TWR交换），则发起方DT-锚点应在其Poll DTM的响应方DT-锚点管理列表中包含ToF结果字段。如果到给定响应方DT-锚点的ToF未知，则其对应的ToF结果应设置为无效值0x0000。注意，DT-标签可以使用ToF结果来计算TDoA估计值。

6.3.4.1.1.15 DT-锚点可以在搭载于Poll DTM、Final DTM或Response DTM的DM有效载荷IE中发送MDSDU。

6.3.4.1.2 引导和簇间同步期间DT-锚点需求

6.3.4.1.2.1 DL-TDoA网络中应至少有一个参考DT-锚点提供公共测距块结构。

6.3.4.1.2.2 参考DT-锚点应在其DL-TDoA会话开始后按照配置的活动测距轮次开始发送Poll DTM。

6.3.4.1.2.3 除参考DT-锚点之外的发起方DT-锚点在未与参考DT-锚点生成的测距块结构同步之前，不应开始发送Poll DTM。

6.3.4.1.2.4 参考DT-锚点发送的Poll DTM中包含的跳计数字段值应为零（0x00）（如果包含）。

6.3.4.1.2.5 如果根据第G.2节中的机制2将跳计数字段用于簇间同步，除参考DT-锚点外的所有DT-锚点可以初始将其跳计数设置为值0xFF，表示它们尚未对齐到网络的公共块结构，因此无法参与（即发送DTM）。

6.3.4.1.2.6 根据第G.2节中的机制2，如果跳计数字段用于簇间同步，跳计数字段应随给定发起方DT-锚点与参考DT-锚点之间无线通信跳数的增加而单调递增1。因此，在参考DT-锚点通信范围内（即邻居）的发起方DT-锚点应在Poll DTM中报告跳计数值为1跳。距离参考DT-锚点两跳的发起方DT-锚点应报告跳计数值为2，依此类推。注意，网络在引导时可能需要一些时间来稳定到适当的跳计数值。在网络动态变化（即网络中的变化）下也可能发生这种情况。

6.3.4.1.3 DT-标签需求

6.3.4.1.3.1 DT-标签应支持接收和处理DTM。

6.3.4.1.3.2 DT-标签不应在由块跳过功能配置的跳过测距块中监听DTM。

6.3.4.1.3.3 DT-标签仅监听上层配置的测距块中的活动测距轮次。

6.3.4.2 AoA测量需求

对于OWR AoA测量测距方法，应使用AoA测量消息。

6.3.4.2.1 AoA测量消息的帧控制字段应具有表62中所示的以下字段。

表62 - AoA测量消息的帧控制字段

6.3.4.2.2 源地址和目标地址

6.3.4.2.2.1 AoA测量消息MAC头中包含的源地址和目标地址应为短地址或扩展地址模式。

6.3.4.2.2.2 目标地址应设置为广播地址。

6.3.4.2.3 序列号字段需求

6.3.4.2.3.1 序列号字段应在每个测距块重置为'0'。

6.3.4.2.4 帧待处理位需求

6.3.4.2.4.1 如果AoA测量消息的RFRAME数量字段为1，则该AoA测量消息的帧待处理位应设置为0。

6.3.4.2.4.2 如果AoA测量消息的RFRAME数量字段大于1，则RFRAME的帧待处理位应设置为1，但最后一个RFRAME的帧待处理位应设置为0。

6.3.4.2.5 Header IE和有效载荷IE需求

6.3.4.2.5.1 测距块中的每个RFRAME应包含第5.9.11节定义的有效载荷IE。

6.3.4.2.5.2 如果数据消息IE搭载在AoA测量消息上，则数据消息IE应跟随在AoA测量消息的有效载荷IE之后。

6.3.4.2.5.3 如果数据消息IE搭载在AoA测量消息上，则数据消息IE的大小不应超过MTU大小。

• 帧开销大小 = MHR + FCS + Header IE + 有效载荷IE头 + 8字节ENC-MIC-64 + 1字节辅助安全头

6.3.4.2.5.3.1 MTU = PSDU大小 - 帧开销大小

6.3.4.2.6 STS需求

6.3.4.2.6.1 测距块中的所有RFRAME应具有相同的STS值，该值由时隙索引0的静态STS生成模式生成。出于配置摘要计算的目的，SLOT_DURATION字段应设置为0x0000。

6.3.4.2.7 充当广播者或观察者的FiRa设备应支持HPRF（高脉冲重复频率）模式。注意：HPRF允许最大PSDU大小为4095字节。一个有效载荷IE长度的最大大小为2047字节（[IEEE_802_15_4_2020]图7-47）。一个PSDU可以包含多个有效载荷IE。

6.3.4.2.8 充当广播者或观察者的FiRa设备可以支持BPRF（基础脉冲重复频率）模式。

6.3.4.2.9 OWR AoA测量测距方法中的数据传输

6.3.4.2.9.1 如果广播者在不分段的情况下发送MDSDU，则应将MDSDU包含在测距轮次中第一个AoA测量消息的DM有效载荷IE中。如果RFRAME数量大于1，则除第一个AoA测量消息外的其余AoA测量消息不应包含DM有效载荷IE。

6.3.4.2.9.2 如果广播者将MDSDU分段为多个段（"MDSDU段"），则应在第一个AoA测量消息的DM有效载荷IE中发送第一段。其余段应在后续的AoA测量消息中连续发送。

6.3.4.2.9.3 关于6.3.4.2.9.2，广播者可以发送具有不同大小MDSDU段的AoA测量消息。

6.3.4.2.10 OWR AoA测量的时序需求

6.3.4.2.10.1 广播者应在测距块开始时发送AoA测量测距轮次的第一个RFRAME。

6.3.4.2.10.2 当广播者在AoA测量测距轮次中发送多个RFRAME时，两个连续RFRAME之间的发送间隔应等于表38定义的帧间间隔（即广播者在IFI开始时发送RFRAME）。

6.3.4.2.10.3 广播者在发送属于同一AoA测量测距轮次的新RFRAME之前应至少等待IFI_GT_MIN。

6.3.4.2.10.4 观察者应在IFI_GT_MIN后准备接收属于同一AoA测量测距轮次的下一个RFRAME。

6.3.4.2.10.5 广播者在发送开始下一个测距块的RFRAME之前应至少等待IFI_BGT_MIN。

6.3.4.2.10.6 观察者应在IFI_BGT_MIN后准备接收开始下一个测距块的RFRAME。

6.3.4.2.10.7 广播者应按如下方式设置块持续时间：

• block_duration >= IFI × MIN_FRAMES_PER_RR - IFI_GT_MIN + IFI_BGT_MIN

6.3.4.3 上行TDoA需求

6.3.4.3.1 UTM应遵循表63中规定的帧控制字段。

表63 - UL-TDoA消息（UTM）的帧控制内容字段

6.3.4.3.2 UTM不应包含目标地址，即UTM帧是隐式广播帧。

6.3.4.3.3 UTM应包含MAC源地址，可以是短地址或扩展地址模式。

6.3.4.3.4 UTM应使用静态STS生成方法。出于配置摘要计算的目的，时隙持续时间字段应设置为0x0000。

6.3.4.3.5 UL-TDoA发送间隔应以最小时间粒度（即1 ms）的分辨率进行配置。

6.3.4.3.6 UTM的发送可以在指定的UL-TDoA随机窗口内的随机时间偏移处进行。UL-TDoA随机窗口应小于或等于配置的UL-TDoA发送间隔。UL-TDoA随机窗口的值应以1200 RSTU为单位。

6.3.4.3.7 UT-标签和UT-同步锚点应分别基于配置的UL-TDoA发送间隔和UL-TDoA随机窗口参数的值发送Blink UTM和同步UTM。

6.3.4.3.8 为简便起见，当支持时，UL-TDoA设备在DM有效载荷IE中发送MDSDU（例如搭载在Blink DTM或同步DTM上）时，应不分段地执行。

6.3.5 混合UWB调度模式需求

本节包含混合模式的需求。

6.3.5.1 对于HUS会话，应适用第6.3.2节定义的基于块的模式需求。

6.3.5.2 HUS测距阶段的时隙持续时间应为HUS会话配置的时隙持续时间的整数倍。HUS测距阶段内的时隙数应使用CM Type 3的RRML中包含的时隙索引起始、时隙索引结束以及HUS会话时隙持续时间计算如下：

1. HUS测距阶段持续时间 = (时隙索引结束 - 时隙索引起始 + 1) × 时隙持续时间_HUS会话
2. HUS测距阶段中的时隙数 = ⌊HUS测距阶段持续时间 / 时隙持续时间_{HUS测距阶段}⌋，其中 ⌊⌋ 表示向下取整函数。

6.3.5.3 每个测距块中应只有一个活动的HUS测距轮次。

6.3.5.4 HUS测距阶段应按顺序出现，但可以重叠，即下一个HUS测距阶段在前一个结束之前开始。

6.3.5.4.1 HUS控制器不应将重叠HUS测距阶段的控制器角色分配给同一个FiRa设备。

6.3.5.4.2 被分配为两个或更多重叠HUS测距阶段控制器的FiRa设备应选择并执行其中一个HUS测距阶段。

6.3.5.4.3 被分配为一个HUS测距阶段控制器且为重叠HUS测距阶段受控器的FiRa设备，应以控制器身份执行HUS测距阶段，不应以受控器身份参与HUS测距阶段。

6.3.5.4.4 被分配为多个HUS测距阶段受控器的FiRa设备，当参与的HUS测距阶段与另一个阶段的CM重叠时，可以跳过与HUS测距阶段CM的同步。

6.3.5.5 HUS测距轮次应包含RCP，并可以包含一个或多个HUS测距阶段。

6.3.5.6 HUS控制器应在HUS测距轮次的第一个时隙中发送第5.9.13节定义格式的CM Type 3的开始。

6.3.5.7 CM Type 3可以超过一个时隙持续时间，因此可以延伸到后续时隙。在这种情况下，HUS控制器应使用帧待处理位功能（例如第5.4.3.3节中定义的）来通告CM Type 3帧分段。

6.3.5.8 如果CM Type 3被分段，则包含段的所有时隙应在RCP中传输。RCP和后续HUS测距阶段永远不应重叠。

6.3.5.9 CM Type 3应使用IEEE多用途帧作为帧类型。

6.3.5.10 CM Type 3应包含表64中规定的以下帧控制字段，并应为广播帧。

表64 - RMM帧控制字段

6.3.5.11 HUS受控器应在HUS测距轮次的第一个时隙中监听CM Type 3。如果使用帧待处理功能，则HUS受控器应准备接收跨越多个时隙分段的CM Type 3。

6.3.5.12 如果FiRa设备的MAC地址列在CM Type 3中，则该FiRa设备应充当HUS测距阶段的控制器。

6.3.5.13 HUS测距阶段的控制器应在该HUS测距阶段的第一个时隙中发送对应于该HUS测距阶段中调度的配置辅助会话的CM（CM Type 1、CM Type 2或DTPCM）。此外，对于配置的测距方法和角色，控制器和受控器均应适用相同的需求定义。

6.3.5.14 如果FiRa设备被配置为CFP HUS测距阶段的受控器，则应参与该阶段对应CM的测距或数据传输。

6.3.5.15 如果FiRa设备被配置为CAP HUS测距阶段的受控器，则应监听CM Type 2并参与HUS测距阶段，但以下情况除外：如果受控器参与了CFP HUS测距阶段，则在该CFP之后由同一控制器控制的CAP中，该受控器不应参与。

6.3.5.16 如果启用跳频模式，应将所有HUS测距阶段作为一个整体HUS测距轮次适用。

6.3.5.17 如果启用块跨步，应将所有HUS测距阶段作为一个整体HUS测距轮次适用。

6.3.5.18 HUS控制器和HUS受控器应支持第6.4节规定的HUS会话静态STS生成方法，但例外是phyStsIndexInit在测距块索引'0'中应设置为值'0'，此后在整个HUS会话中每个测距时隙递增phyStsIndex值1。

6.3.5.19 STS生成和MAC有效载荷加密应按照各个HUS测距阶段的配置，遵循第6.4节中规定的需求执行。

6.3.5.20 参与HUS测距阶段的FiRa设备应支持第6.4节规定的静态STS生成方法。phyStsIndex和CryptoStsIndex的递增和计算应在HUS测距阶段的上下文中完成，遵循第6.4节中的定义。CryptoStsIndex索引在HUS阶段的第1个时隙重置。

6.3.5.21 参与HUS测距阶段的FiRa设备可以支持第6.4节规定的动态或预配置STS生成方法。phyStsIndex和CryptoStsIndex的递增和计算应在HUS测距阶段的上下文中完成，遵循第6.4节中的定义，即对于HUS辅助会话和给定控制器，phyStsIndex和CryptoStsIndex计数器在HUS测距阶段结束时停止，当该HUS辅助会话和控制器的HUS测距阶段再次出现时恢复。如果作为HUS测距阶段控制器的设备在该阶段的第一个时隙中未发送对应的控制消息，则该辅助会话的phyStsIndex和CryptoStsIndex计数器在对应块中不递增。

6.3.5.22 对于控制消息类型3，Header IE的内容字段应按照表4中的定义构造。

6.3.5.23 控制消息类型3的有效载荷IE内容字段应按照表48中的规定构造。

6.3.5.24 厂商OUI：应设置为值0x5A18FF。

6.3.5.25 UWB消息ID：应设置为0x3以指示此消息为控制消息。

6.3.5.26 停止会话：指示HUS控制器是否停止HUS会话。如果停止会话位设置为0b0，则会话继续。如果设置为0b1，则HUS会话停止。所有参与此HUS测距轮次的设备，即接收到CM Type 3的设备，应停止参与HUS会话。

6.3.5.27 HUS控制器应将版本字段的值设置为0b001。实现此功能版本的HUS受控器应接受版本字段值0b001。

6.3.5.28 用于HUS模式和每个HUS测距阶段的UWB PHY和MAC参数可以单独配置，但在一个完整的HUS测距轮次期间不应更改。与STS生成方法相关的UWB PHY配置可以在HUS测距阶段之间不同。

6.3.5.29 CM Type 3应使用SP0 PPDU配置。

以下6.3.5.30规则适用于CM Type 3传输中FP位的使用：

6.3.5.30.1 Header IE应用于CM Type 3的传输。厂商OUI、会话ID应保持不变，STS索引应递增。

6.3.5.30.2 CM Type 3有效载荷IE应以相同的厂商OUI、UWB消息ID、停止会话、跨步长度和轮次索引值传输。

6.3.5.30.3 RRML大小应包含对应于该时隙中传输元素数量的值。

6.3.5.30.4 如果没有待处理的RRML传输，则FP位值应设置为'0b0'，指示测距块CM Type 3传输的结束。

第8章 安全机制 / 测距模式

8 安全机制 / 测距模式

安全要求

本节描述密钥派生与加密过程及其原理。

本节描述动态（Dynamic）、预配置（Provisioned）和静态（Static）STS的生成。这三种模式之间的选择通过UCI完成。

动态STS与预配置STS在MAC层的工作方式相似，主要区别在于会话密钥（Session Key）的提供方式。在动态STS模式下，用于生成STS的会话密钥由安全组件提供。在预配置STS模式下，会话密钥由安全组件或通过主机接口（UCI）提供。它们的共同目标是确保：

• 通过确保不传输任何明文形式的可识别信息来保护用户隐私
• 保护通过UWB传输的数据（时间戳、应用载荷）的机密性、完整性和真实性
• 确保在每个时隙都能生成不同的STS
• 确保能够检测到重放攻击
• 允许受控端（Controlee）在单条控制消息上同步到发射机
• 限制开销以优化链路预算
• 限制侧信道攻击的风险

动态STS相比预配置STS提供以下额外益处：

• 防范物理侧信道攻击
• 防范对设备的物理篡改和克隆

首先考虑的是允许在IE头中传输phyStsIndex，因为cryptoStsIndex（phyStsIndex的一个副本）被用作在每个时隙生成不同STS的种子的一部分。使用递增计数器使得重放可以被轻松检测。其机密性必须受到保护，否则就有可能通过跟踪递增的phyStsIndex来追踪特定用户。其完整性也必须受到保护，以避免被攻击者篡改。

为了对其进行加密，使用ECB模式，因为可以利用phyStsIndex作为递增计数器的特性。这确保了包含SessionID和phyStsIndex的128位密文始终不同。由于phyStsIndex和SessionID仅为32位字段，密文中剩余的64位可用于保护完整性以存储已知填充。在ECB模式下，密文位的任何修改都会对所有明文位产生雪崩效应，因此可用于检测修改。此ECB加密使用特定的密钥。该密钥在整个会话期间相同，因为受控端应该能够随时同步。

secPrivacyKey由会话密钥派生。

对于STS生成，使用[IEEE_802_15_4z_2020]中描述的确定性随机比特生成器（DRBG）。cryptoStsIndex附加到一个32位计数器之后，该计数器在每个时隙开始时复位，确保无论先前时隙中STS的长度如何，只要知道cryptoStsIndex和当前配置即可生成STS。

phyStsIndex的初始值phyStsIndexInit在密钥派生过程中生成。

对于数据加密，无法对其内容做出任何假设，因此将使用认证加密（Authenticated Encryption, AE）。由于AE基于计数器模式加密，因此需要向AE提供一个随机数（Nonce）。该随机数可以在每个加密数据包的前端传输，但这会增加开销。因此cryptoStsIndex将用作随机数的变化部分。由于已同步的受控端始终知道不重复的cryptoStsIndex，只要会话足够短以确保cryptoStsIndex永不重复，它即可用于此目的。为了便于实现，当cryptoStsIndex或phyStsIndex计数器回绕时（即达到最大值时），应终止会话。

所有密钥和初始化向量（IV）均由中间密钥派生，而中间密钥本身又由会话密钥派生。会话密钥的生成不在本文档的范围内。

图51 - 动态和预配置STS生成模式的密钥派生方案

注意：尽管图51中未显示，CCM*还覆盖MHR（包括头部厂商IE）以进行认证。

为了防范侧信道攻击，可以定期轮换派生密钥，以确保攻击者只能收集到有限数量的样本。轮换或重新生成密钥的速率将是初始配置的一部分。这将是安全性与开销之间的权衡。注意，密钥轮换不应过快，否则密钥派生过程本身可能受到攻击。

对于静态STS生成模式，目标是确保：

• 通过在一个轮次的每个时隙生成不同的STS来确保可靠测距
• 允许低成本和高性能的实现
• 确保立即重新同步

对于静态STS生成模式，一个轮次中每个给定时隙将使用与前一轮次和后一轮次相同时隙相同的STS。这确保了快速同步，因为受控端无需知道phyStsIndex，并允许预计算AES模式。

为此，cryptoStsIndex不再是phyStsIndex的副本（不同于动态STS生成模式），而是将在轮次开始时复位为0。此外，STS种子的一部分，即phyVUpper64，将由UCI设置，而不是作为密钥派生的一部分。

图52 - 静态STS生成模式的密钥派生方案

注意：尽管图52中未显示，CCM*还覆盖MHR（包括头部厂商IE）以进行认证。

6.4.1 密钥生成与管理

对于密钥派生，CMAC将用作伪随机函数，AES用作分组密码。密钥派生的输入数据如下所述，并如图51所示。

• 32位计数器：如果要生成256位密钥，则将使用两轮CMAC。在第一轮中，计数器值为0x00000001，在第二轮中为0x00000002。两轮的结果将被拼接。
• 64位标签（Label）：描述派生密钥的用途。
• 128位上下文（Context）：确保密钥生成与当前上下文关联，例如cryptoStsIndex和/或为会话约定的配置摘要。
• 32位长度（Length）：表示派生密钥的长度，即256位密钥为0x00000100，128位密钥为0x00000080。

该派生数据应作为CMAC伪随机函数的输入数据，根密钥用作CMAC的密钥。CMAC轮次的输出即为派生密钥。

图53 - 密钥派生

6.4.1.1 密钥派生原语

6.4.1.1.1 所有密钥派生均应使用[NIST_SP_800_108]第5.1节中描述的计数器模式执行。

6.4.1.1.2 应使用[NIST_SP_800_38B]中描述的CMAC作为伪随机函数（PRF）。

6.4.1.1.3 应使用[FIPS_197]中描述的AES作为CMAC的分组密码。

6.4.1.1.4 PRF输出长度应为128或256位。

6.4.1.1.5 派生密钥长度应为128或256位。

6.4.1.1.6 计数器长度应编码为32位。

6.4.1.1.7 标签（密钥用途的描述）应为64位。

6.4.1.1.8 上下文（包含上下文信息的二进制字符串）应为128位。

6.4.1.1.9 密钥长度（以位为单位）应编码为32位。

6.4.1.1.10 派生数据应为计数器、标签、上下文和长度的拼接，顺序依次为上述顺序。

6.4.1.2 密钥派生标签

6.4.1.2.1 要生成phyStsIndexInit，应使用标签0x537473496e64496e（ASCII为"StsIndIn"）。

6.4.1.2.2 要生成secPrivacyKey，应使用标签0x507269766163794b（ASCII为"PrivacyK"）。

6.4.1.2.3 要生成secDataProtectionKey，应使用标签0x446174615072744b（ASCII为"DataPrtK"）。

6.4.1.2.4 要生成secDerivedPayloadKey，应使用标签0x4465725061796c4b（ASCII为"DerPaylK"）。

6.4.1.2.5 要生成secDerivedAuthenticationIv，应使用标签0x4465724175746849（ASCII为"DerAuthI"）。

6.4.1.2.6 要生成secDerivedAuthenticationKey，应使用标签0x446572417574684b（ASCII为"DerAuthK"）。

6.4.1.3 密钥派生上下文

6.4.1.3.1 第6.4.1.4节中描述的配置摘要（在图51中也称为"Config digest"）应作为128位上下文字段（如图51所示），用于生成secPrivacyKey、secDataProtectionKey和phyStsIndexInit。

6.4.1.3.2 "Config digest"的96个最低有效位（lsb）与32位cryptoStsIndex的拼接应作为128位上下文字段（如图51所示），用于生成secDerivedPayloadKey、secDerivedAuthenticationIv和secDerivedAuthenticationKey。

6.4.1.3.3 对于首次派生，在动态STS或预配置STS模式下，cryptoStsIndex的初始值应设置为phyStsIndexInit。

6.4.1.3.4 对于首次派生，在静态STS模式下，cryptoStsIndex的初始值应设置为0x00000000。

6.4.1.4 配置摘要

6.4.1.4.1 应使用[NIST_SP_800_38B]中描述的CMAC生成配置摘要。

6.4.1.4.2 应使用[FIPS_197]中描述的AES作为CMAC的分组密码。

6.4.1.4.3 用于CMAC的密钥应为128位。

6.4.1.4.4 用于CMAC的消息应包含以下按给定顺序拼接的参数：

• RANGING_ROUND_USAGE
• STS_CONFIG
• MULTI_NODE_MODE
• CHANNEL_NUMBER
• SLOT_DURATION (*)
• MAC_FCS_TYPE
• RFRAME_CONFIG
• PREAMBLE_CODE_INDEX
• SFD_ID（帧起始定界符ID）
• PSDU_DATA_RATE
• PREAMBLE_DURATION
• 常量 = 0x03
• SESSION_ID

(*) RSTU中的测距时隙长度转换为µs，公式为：

𝑆𝐿𝑂𝑇_𝐷𝑈𝑅𝐴𝑇𝐼𝑂𝑁 = ⌊(𝑆𝑙𝑜𝑡 𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛 𝑖𝑛 𝑅𝑆𝑇𝑈 × 416) ÷ 499.2⌋

其中 ⌊ ⌋ 表示向下取整函数。

此以微秒为单位的SLOT_DURATION用于形成派生数据，如附录D所示。

6.4.1.4.5 参数的值应对应于会话UCI应用配置命令中发送的值，位宽按该命令中的定义。

6.4.1.5 密钥派生根密钥

6.4.1.5.1 在静态STS生成模式情况下，secSessionKey应设置为固定值0x53746174696354535374617469635453（"StaticTSStaticTS"的ASCII值）。

6.4.1.5.2 要生成secPrivacyKey，应使用secSessionKey作为根密钥。

6.4.1.5.3 要生成secDataProtectionKey，应使用secSessionKey作为根密钥。

6.4.1.5.4 应使用secDataProtectionKey作为根密钥来生成phyStsIndexInit、secDerivedPayloadKey、secDerivedAuthenticationIv、secDerivedAuthenticationKey。

6.4.1.6 密钥长度

6.4.1.6.1 应支持128位长度的secSessionKey。

6.4.1.6.2 可以支持256位长度的secSessionKey。

6.4.1.6.3 secSessionKey长度应在从安全组件获取密钥时确定。

6.4.1.6.4 secDataProtectionKey应与secSessionKey具有相同长度。

6.4.1.6.5 secDerivedPayloadKey、secDerivedAuthenticationIv、secDerivedAuthenticationKey、secPrivacyKey应为128位长。

6.4.1.7 密钥轮换

6.4.1.7.1 信息性文本：为提高对侧信道攻击和密码分析的抵抗力，可以执行定期密钥轮换，其中用于STS生成和载荷加密的密钥被设置为新值。轮换速率将在会话建立期间约定或为默认值。当密钥轮换发生时，secDerivedPayloadKey、secDerivedAuthenticationIv、secDerivedAuthenticationKey将被重新计算。phyStsIndex值不会被重新初始化，因为设备在任何时候都能检查phyStsIndex的一致性这一点很重要。

6.4.1.7.2 信息性文本：密钥轮换速率将由块增量的2的幂次定义，例如每256次增量。在这种情况下，每当BlockIndex的第8位翻转时。

6.4.1.7.3 如果设备支持动态或预配置STS，则它还应支持密钥轮换。

6.4.1.7.4 在会话建立时，应在动态或预配置STS生成模式下启用或禁用密钥轮换。

6.4.1.7.5 密钥轮换不适用于静态STS生成模式。

6.4.1.7.6 如果启用密钥轮换，密钥轮换速率应在高层会话协商期间约定。

6.4.1.7.7 如果启用密钥轮换，密钥轮换速率应为2的幂，即表示为2^n，其中n由表52中定义的轮换速率参数设置。

6.4.1.7.8 如果启用密钥轮换，密钥轮换应在BlockIndex的第n位翻转时发生。

6.4.1.7.9 （空白）本节有意留空。

6.4.1.7.10 当密钥轮换发生时，secDerivedPayloadKey、secDerivedAuthenticationIV、secDerivedAuthenticationKey应使用密钥轮换时的phyStsIndex值（即块的第一个轮次的值）重新计算。

6.4.1.7.11 当密钥轮换发生时，应遵循第6.4.4.2节中描述的过程。

6.4.2 phyStsIndex加密

6.4.2.1.1 控制器（Controller）应使用厂商特定头IE向受控端传输phyStsIndex。

6.4.2.1.2 在静态STS生成模式下，厂商特定头IE载荷不应被加密。

6.4.2.1.3 在动态或预配置STS生成模式下，应使用[NIST_SP_800_38A]中描述的电子密码本（ECB）模式对厂商特定头IE载荷进行加密。

6.4.2.1.4 应使用[FIPS_197]中描述的AES作为ECB加密的分组密码。

6.4.2.1.5 应使用secPrivacyKey作为密钥。

6.4.2.1.6 待加密的明文应从最高有效位到最低有效位拼接64位填充字段、SessionID和phyStsIndex值。

6.4.2.1.7 （空白）本节有意留空。

6.4.2.1.8 （空白）本节有意留空。

6.4.2.1.9 （空白）本节有意留空。

6.4.2.1.10 填充应如[RFC_5652]第6.3节所述，即字节0x08应重复八次。

6.4.2.1.11 厂商特定头IE载荷加密（如果需要）应在对接收MAC帧应用第6.4.5节中描述的认证加密过程之前进行。

6.4.3 phyStsIndex解密

6.4.3.1.1 当受控端接收到包含phyStsIndex的加密厂商特定头IE时，受控端应使用其secPrivacyKey对其进行解密。

6.4.3.1.2 受控端应检查填充。如果填充不正确或与预期长度不对应，则应丢弃该IE。

6.4.3.1.3 受控端应检查phyStsIndex具有连贯的值，至少实施以下检查：

6.4.3.1.3.1 接收到的phyStsIndex大于前一个值。

6.4.3.1.3.2 如果接收到的phyStsIndex小于前一个值，受控端应终止会话。

6.4.3.1.4 受控端可以检查phyStsIndex具有连贯的值，至少实施以下检查：

6.4.3.1.4.1 接收到的phyStsIndex相对于前一个值的增量与自前一个接收值以来经过的时间相一致。

6.4.3.1.4.2 接收到的phyStsIndex小于初始值加上会话最大预期长度对应的预期增量。

6.4.4 STS生成与STS索引管理

6.4.4.1 phyStsIndex

6.4.4.1.1 phyStsIndex应用于同步。

6.4.4.1.2 phyStsIndex是一个32位值，初始值设置为phyStsIndexInit [31:0] & 0x7FFFFFFF。此操作仅在测距会话开始时执行，不在密钥轮换时执行。

6.4.4.1.3 phyStsIndex应在每个时隙后递增1。

6.4.4.1.4 当phyStsIndex计数器达到其最大值（0xFFFF FFFF）时，应终止会话。

6.4.4.1.5 信息性文本：如第6.4.2节所述，phyStsIndex通过厂商特定头IE传输。

6.4.4.2 cryptoStsIndex

6.4.4.2.1 cryptoStsIndex应用作STS生成以及MAC头和载荷认证加密的随机数（Nonce）。

6.4.4.2.2 cryptoStsIndex是一个32位值。

6.4.4.2.3 在动态和预配置STS生成模式下，cryptoStsIndex应设置为初始值PhyStsIndexInit [31:0] & 0x7FFFFFFF。此操作应在测距会话开始时执行。

6.4.4.2.4 在静态STS生成模式下，cryptoStsIndex将在每个轮次开始时设置为0x00000000。

6.4.4.2.5 cryptoStsIndex应在每个时隙后递增1。

6.4.4.2.6 当cryptoStsIndex计数器达到其最大值（0xFFFF FFFF）时，应终止会话。

6.4.4.3 STS生成DRBG

6.4.4.3.1 STS应使用[IEEE_802_15_4z_2020]第15.2.9.1节中规定的确定性随机比特生成器（DRBG）生成。

6.4.4.3.2 信息性文本：从PHY PAN信息库（PIB）属性到[IEEE_802_15_4z_2020] PIB属性的DRBG输入字段映射在表65中定义：

表65 - DRBG输入字段到IEEE 802.15.4z-2020 PIB属性的映射

该映射如图54所示。

图54 - 映射图

6.4.4.4 DRBG初始化过程

6.4.4.4.1 在测距会话开始时，或在密钥轮换过程结束时，DRBG属性应设置如下：

6.4.4.4.1.1 phyHrpUwbStsKey[127:0]应设置为在第6.4.1.1节中定义的密钥派生过程中生成的secDerivedAuthenticationKey。

6.4.4.4.1.2 在静态STS生成模式下，phyVUpper64应设置为在会话UCI应用配置命令中设置的STATIC_STS_IV和VENDOR_ID字段的拼接（从最高有效位开始的顺序）。

6.4.4.4.1.3 在动态和预配置STS生成模式下，phyVUpper64应设置为在最后一次密钥派生过程中生成的secDerivedAuthenticationIv[127:64]。

6.4.4.4.1.4 phyStsVCounter设置为在最后一次密钥派生过程中生成的secDerivedAuthenticationIv[31:0] & 0x7FFF_FFFF。

6.4.4.4.1.5 信息性章节：例如，假设定期执行密钥轮换。在初始密钥派生时，secDerivedAuthenticationIv0将作为密钥派生的一部分进行计算，并按下表映射到不同的PHY参数。如果在phyStsIndex递增n次后发生密钥轮换，PHY参数将具有表中所述的更新值。phyStsIndex将在每个时隙后持续更新其值。

表66 - 在每2^n个时隙启用密钥轮换的动态STS生成模式下，2^n个时隙后secDerivedAuthenticationIv和phyStsIndexInit到DRBG输入字段的映射

6.4.4.5 DRBG更新过程

6.4.4.5.1 对于测距会话内的每个时隙，DRBG属性更新如下：

6.4.4.5.1.1 phyHrpUwbStsKey[127:0]应保持其在会话开始时或密钥轮换过程后设置的值。

6.4.4.5.1.2 phyHrpUwbStsVUpper96应设置为phyVUpper64和cryptoStsIndex的拼接。

6.4.4.5.1.3 phyStsVCounter应设置为secDerivedAuthenticationIv [31:0] & 0x7FFFFFFF。

6.4.5 认证加密

6.4.5.1.1.1 应使用认证加密来加密载荷并保护整个帧的真实性。

6.4.5.1.1.2 应使用[IEEE_802_15_4_2020]第9.3.4节中描述的CCM*作为认证加密。

6.4.5.1.1.3 应使用secDerivedPayloadKey作为认证加密密钥。

6.4.5.1.1.4 如果传输MAC载荷，应使用辅助安全头。

6.4.5.1.1.5 辅助安全头的安全控制字节的安全级别字段应设置为6，即ENC-MIC-64。

6.4.5.1.1.6 辅助安全头的安全控制字节的密钥标识符模式字段应设置为0x00，即密钥隐式确定。

6.4.5.1.1.7 辅助安全头的安全控制字节的帧计数器抑制字段应设置为'1'，即帧计数器是一个递增的共享全局帧计数器，即cryptoStsIndex。

6.4.5.1.1.8 辅助安全头的安全控制字节的ASN字段应设置为'0'，即帧计数器（即cryptoStsIndex）用于构建随机数。

6.4.5.1.1.9 CCM的随机数应按如下方式构造：

表67 - CCM*随机数的映射

6.4.5.1.1.10 如果目的地不知道扩展源地址，扩展源地址应为短源地址左侧填充"0"。

6.4.5.1.1.11 如果在解密期间认证标签不正确，则应丢弃密文。

6.4.6 带响应方特定子会话密钥的动态STS或预配置STS组播操作

在带响应方特定子会话密钥的组播预配置STS和动态STS模式下，每个受控端并行地以专用子会话参与会话。每对（子会话密钥，子会话ID）被分配给每个受控端。根据消息类型，控制器或受控端使用从会话密钥或子会话密钥派生的密钥来加密MAC载荷或生成STS。

表68描述了在配置了带响应方特定子会话密钥的动态STS的延迟、DS-TWR测距轮次中，用于派生加密密钥和STS生成密钥的材料。

表68 - 时分调度模式TWR中带响应方特定子会话密钥的动态（或预配置）STS密钥派生材料

当响应方传输RRM或RRRM时，它应执行如图51中所述的KDF，使用其子会话密钥作为secSessionKey，并使用其子会话ID用于摘要。RCM中传输的STS索引应用作参考，即所有子会话应使用与主会话相同的STS索引。

附录A 基于块模式的SS-TWR流程示例

提供了O2M SS-TWR的示例，其中一个安全测距设备1（FiRa设备1）作为控制器和发起方，而其他FiRa设备（FiRa设备2到FiRa设备N）作为受控端和响应方。此处，数据帧和RFRAME分别考虑HRP UWB PPDU SP0和HRP UWB PPDU SP3，这是FiRa认证的FiRa设备的强制选项。本附录中指定的术语定义见[IEEE_802_15_4_2020]和[IEEE_802_15_4z_2020]。

图55 - 基于块模式的SS-TWR示例流程

<步骤1：测距控制阶段（RCP）>

• 在FiRa设备之间交换UWB参数以进行UWB设置后，它们以协商的信道和前导码开启UWB无线电。
• FiRa设备1发送一种控制消息类型（UWB消息ID = 0x00）。
• 时隙调度可通过RDML字段完成。

<步骤2：测距发起阶段（RIP）>

• FiRa设备1在RIP中发送第一条测距发起消息。

<步骤3：测距响应阶段（RRP）>

• RIP之后，响应方FiRa设备在RRP中发送测距响应消息。
• 测距响应消息的总数与响应方FiRa设备的数量相同。

<步骤4：发起方FiRa设备（FiRa设备1）的测量报告阶段（MRP）>

• 在MRP中，FiRa设备1通过一种测量报告消息类型（UWB消息ID = 0x10）将FiRa设备1的回复时间传输给响应方FiRa设备。

<步骤5：响应方FiRa设备（FiRa设备2到FiRa设备𝑵）的MRP>

• 响应方FiRa设备根据从FiRa设备1的测量报告消息中接收到的回复时间，计算ToF作为测距结果。
• 响应方FiRa设备可通过一种测距结果报告消息类型（UWB消息ID = 0x20）将其自身的测距结果传输给FiRa设备1。
• 测距结果报告消息的总数与响应方FiRa设备的数量相同。

附录B 基于块模式的DS-TWR流程示例

提供了O2M DS-TWR的示例，其中一个安全测距设备1（FiRa设备1）作为控制器和发起方，而其他FiRa设备（FiRa设备2到FiRa设备𝑁）作为受控端和响应方。此处，数据帧和RFRAME分别考虑HRP UWB PPDU SP0和HRP UWB PPDU SP3，这是FiRa认证的FiRa设备的强制选项。本附录中指定的术语定义见[IEEE_802_15_4_2020]和[IEEE_802_15_4z_2020]。

图56 - 基于块模式的DS-TWR示例流程

<步骤1：测距控制阶段（RCP）>

• 在FiRa设备之间交换UWB参数以进行UWB设置后，它们以协商的信道和前导码开启UWB无线电。
• FiRa设备1发送一种控制消息类型（UWB消息ID = 0x00）。
• 时隙调度可通过RDML字段完成。

<步骤2：测距发起阶段（RIP）>

• FiRa设备1在RIP中发送第一条测距发起消息。

<步骤3：测距响应阶段（RRP）>

• RIP之后，响应方FiRa设备在RRP中发送测距响应消息。
• 测距响应消息的总数与响应方FiRa设备的数量相同。

<步骤4：测距最终阶段（RFP）和发起方FiRa设备（FiRa设备1）的测量报告阶段（MRP）>

• 在RFP中，FiRa设备1传输测距最终消息。
• 在MRP中，FiRa设备1通过一种测量报告消息类型（UWB消息ID = 0x10）将FiRa设备1的回复时间和往返时间传输给响应方FiRa设备。

<步骤5：响应方FiRa设备（FiRa设备2到FiRa设备𝑵）的MRP>

• 响应方FiRa设备根据从FiRa设备1的测量报告消息中接收到的回复时间和往返时间测量，计算ToF作为测距结果。
• 响应方FiRa设备可通过一种测距结果报告消息类型（UWB消息ID = 0x20）将其自身的测距结果传输给FiRa设备1。
• 测距结果报告消息的总数与响应方FiRa设备的数量相同。

附录C HRP UWB FiRa设备的完整性检查示例

在本附录中，提供了HRP UWB FiRa设备完整性检查的示例，允许用户构建安全系统。注意，本附录中介绍的方法是可选示例。由于HRP UWB FiRa设备的测距安全完整性检查取决于实现，因此除了以下示例外，还可以考虑各种方式。以下完整性检查可以同时应用。

C.1 （空白）

本节有意留空。

C.2 基于前导码的完整性检查

HRP UWB FiRa设备的基于前导码的完整性检查是将前导码以及STS用于基于首路径检测的测距测量，然后比较两个测距结果。图57提供了基于前导码的完整性检查流程图。

图57 - 基于前导码的完整性检查流程图

C.3 基于STS分段的完整性检查

HRP UWB FiRa设备的基于STS分段的完整性检查是将多个STS分段用于基于首路径检测的测距测量，然后比较测距结果。图58提供了基于STS分段的完整性检查流程图。由于多个STS分段仅在HRPF模式下考虑，因此此完整性检查可应用于具有HPRF模式的HRP UWB FiRa设备。

图58 - 基于STS分段的完整性检查流程图

C.4 DS-TWR的完整性检查

由两次SS-TWR测量组成的DS-TWR测距方法的HRP UWB FiRa设备完整性检查，可通过测量从SS-TWR测量获得的测距结果，然后比较两个测距结果来考虑。图59提供了DS-TWR完整性检查示例的流程图。

图59 - DS-TWR完整性检查示例流程图

附录D 密钥派生参考

D.1 静态STS

本节提供参考值以检查静态STS的密钥派生实现，遵循图52中描述的密钥派生的不同步骤。

注意：尽管图52中未显示，CCM*还覆盖MHR（包括头部厂商IE）以进行认证。

D.1.1 DerivedConfigDigest

本节描述DerivedConfigDigest的计算，基于下表中描述的配置。

表69 - 静态会话配置

(*) 注意，SLOT_DURATION按照第6.4.1.4节从RSTU转换为微秒，并用于派生数据。

DerivedConfigDigest[127:0] = CMAC(Key, Derivation data) = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3 Key[127:0] = 0x00000000_00000000_00000000_00000000 Derivation data = 02|00|00|09|07D0|00|03|0a|02|00|01|03|01234567 = 0x02000009_07D00003_0a020001_03012345_67

会话密钥

对于静态STS，会话密钥是常数并在MAC规范中定义。

secSessionKey[127:0] = ascii value of "StaticTSStaticTS" = 0x53746174_69635453_53746174_69635453

D.1.2 secDataProtectionKey

secDataProtectionKey[127:0] = CMAC(SessionKey, Derivation data) = 0xf3216c87_d0c6932e_3957b481_fab8b209 Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (128b) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "DataPrtK" = 0x44617461_5072744B • Configuration digest = value computed at previous step = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3 • Key length[31:0] = 0d128 = 0x00000080

D.1.3 phyStsIndexInit

phyStsIndexInit = (CMAC(secDataProtectionKey, Derivation data))[31:0] & 0x7FFFFFFF = 0x0b9bbe78 Derivation data = Counter (32b) | Label (64b) | Configuration digest (128) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "StsIndIn" = 0x53747349_6e64496e • Configuration digest[95:0] = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3 • Key length[31:0] = 0d128 = 0x00000080

D.1.4 secDerivedAuthenticationIV

secDerivedAuthenticationIV = CMAC(secDataProtectionKey, Derivation data) = 0x8b54376e_7cd7a5d6_6bd12000_97274119 Derivation data = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "DerAuthI" = 0x44657241_75746849 • Configuration digest[95:0] = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3 • cryptoStsIndex[31:0] = 0x00000000 • Key length[31:0] = 0d128 = 0x00000080

D.1.5 secDerivedAuthenticationKey

secDerivedAuthenticationKey = CMAC(secDataProtectionKey, Derivation data) = 0xdd9897f2_b85c9dc8_a7dec01c_ca5b61db Derivation data = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "DerAuthK" = 0x44657241_7574684b • Configuration digest[95:0] = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3 • cryptoStsIndex[31:0] = 0x00000000 • Key length[31:0] = 0d128 = 0x00000080

D.1.6 secDerivedPayloadKey

secDerivedPayloadKey = CMAC(secDataProtectionKey, Derivation data) = 0xa55fab83_b620f9f6_a47cdb72_917c738a Derivation data = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "DerPaylK" = 0x44657250_61796c4b • Configuration digest[95:0] = 0x8a33f6eb_7e2fc378_87b6b2a3

• cryptoStsIndex[31:0] = 0x00000000 • Key length[31:0] = 0d128 = 0x00000080

D.1.7 STS

通常，STS不会在每个时隙都发送，例如，slot0通常用于发送RCM。不过，为了参考，提供了前四个时隙的STS值。

图60 - STS生成映射图

StaticStsIv和VendorID通过UCI传输。

phyVupper64[63:0] = StaticStsIv | VendorID = 0x000102030405| 0x0607 = 0x00010203_04050607 At beginning of every round cryptoStsIndex[31:0] = 0x00000000 phyStsVCounter[31:0] = secDerivedAuthenticationIv[31:0] & 0x7FFFFFFF = (0x8b54376e_7cd7a5d6_6bd12000_97274119)[31:0] & 0x7FFFFFF = 0x97274119 & 0x7FFFFFF = 0x17274119 secDerivedAuthenticationKey = 0xdd9897f2_b85c9dc8_a7dec01c_ca5b61db

D.1.7.1. slot 0的STS

phyHrpUwbStsVupper96[95:0] = phyVupper64 | cryptoStsIndex = 0x00010203_04050607_00000000 phyHrpUwbStsVCounter[31:0] = phyStsVCounter = 0x17274119 phySts: 0xf26e3940_a825db92_f9082f06_5a49e9ce_f6cd6841_9787e8c6_0744768c_843c891f_f35d156d_5896d5cc_5c07f6ca_07dfe9ec_4f14bf46_12d02761_8cac2e28_cfcaa56b_7a90d8ae_5a8a794d_1d2897d5_238ed567_265f4f12_1a7dc2a1 _...

D.1.7.2. slot 1的STS

phyHrpUwbStsVupper96[95:0] = phyVupper64 | cryptoStsIndex = 0x00010203_04050607_00000001

phyHrpUwbStsVCounter[31:0] = phyStsVCounter = 0x17274119 phySts: 0xfe208ffe_a3443146_716c762d_879ecec5_31cce34f_39cf71a4_b6fe5734_8e47abf0_52615382_f959df24_6d18f36c_a1f6bac2_8b4fa6fa_f9d621e4_8bcfbcc7_80a9f441_42eeb255_f178392e_913c544b_ef3552fd_8b9f7f89_90693287_28d43ae6_6728fb17 _...

D.1.7.3. slot 2的STS

phyHrpUwbStsVupper96[95:0] = phyVupper64 | cryptoStsIndex = 0x02030405_06070001_00000002 phyHrpUwbStsVCounter[31:0] = phyStsVCounter = 0x17274119 phySts: = 0xa47dcc6b_f917c49d_94dce327_408f6bdb_21b08429_94b1fe8d_d9c3600c_6d9f31ca_5f9410e5_9832c06d_4223a020_904f8c2a_42dafab1_322a8ddd_2e8dad4f_4c6c65d2_92cb9a76_717f9642_6ce0731f_792e3a26_268266e1 _...

D.1.7.4. slot 3的STS

phyHrpUwbStsVupper96[95:0] = phyVupper64 | cryptoStsIndex = 0x02030405_06070001_00000003 phyHrpUwbStsVCounter[31:0] = phyStsVCounter = 0x17274119 phySts: 0xa906438e_948c2de0_fc5058ef_d983b6cb_d72ca4fb_005f7144_a6336787_59dadb7c_7bd821e3_a3a19d48_9c989d73_e8baf3cd_68ce158d_f260b10f_8cf23e42_515866c1_400ddfc8_205db7cc_25a8c125_43ffbc22_233cacd9 _...

D.1.8 RCM帧

给出了slot 0的典型RCM帧（带专有厂商IE）。注意，应用了IEEE字节序，且未显示FCS字段。源地址为0xaaa1，目的地址为0xaaa2。

Vendor header IE: Padding | SessionID | phyStsIndex = 0x08080808_08080808_67452301_78be9b0b Header: 0x492ba2aa_261300ff_185a0808_08080808_08086745_230178be_9b0b003f Payload plaintext: 0x1b90ff18_5a030500_00034255_01044455_03074255_05094255_090a4455_0b CCM* nonce: 0x00000000_0000aaa1_00000000_06

Payload ciphertext: 0xcba4fd37_d1994488_7c2bec2e_1a998e80_617c44b5_e8e3f335_3ab9f229_1b Authenticity tag: 0x804bbae1_a92a2028 Full IEEE packet (Not including FCS): 0x492ba2aa_261300ff_185a0808_08080808_08086745_230178be_9b0b003f_cba4fd37_d1994488_7c2bec2e_1a998e80_617c44b5_e8e3f335_3ab9f229_1b804bba_e1a92a20_28

D.2 动态STS和预配置STS（128位密钥，无密钥轮换）

图61 - 动态和预配置STS生成模式的密钥派生方案

注意：尽管图61中未显示，CCM*还覆盖MHR（包括头部厂商IE）以进行认证。

D.2.1 DerivedConfigDigest

本节描述DerivedConfigDigest的计算，基于下表中描述的配置。

表70 - 动态会话配置

(*) 注意，SLOT_DURATION按照第6.4.1.4节从RSTU转换为微秒，并用于派生数据。

DerivedConfigDigest[127:0] = CMAC(Key, Derivation data) = 0x089366ba_fb3b24bf_d2933377_61b88fc3 Key[127:0] = 0x00000000_00000000_00000000_00000000 Derivation data = 02|01|00|09|07D0|00|03|0a|02|00|01|03|01234567 = 0x02010009_07D00003_0a020001_03012345_67

D.2.2 会话密钥

对于动态和预配置STS，会话密钥的生成不在MAC规范的范围内。对于本参考文档，secSessionKey[127:0] = "DynamicSTSNoRot0"的ASCII值。

= 0x44796e61_6d696353_54534e6f_526f7430

D.2.3 secDataPrivacyKey

secDataPrivacyKey[127:0] = CMAC(SessionKey, Derivation data) = 0x3a4bab18_744aee93_8650f1a0_3f585a49 Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (128) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "PrivacyK" = 0x50726976_6163794b • Configuration digest[127:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc3 • Key length[31:0] = 0d128 = 0x00000080

D.2.4 secDataProtectionKey

secDataProtectionKey = CMAC(SessionKey, Derivation data) = 0x67f7027e_a62d84a5_e1a8d7b8_b8acaeaf Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (128) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "DataPrtK" = 0x44617461_5072744B • Configuration digest[127:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc3 • Key length[31:0] = 0d128 = 0x00000080

D.2.5 phyStsIndexInit

phyStsIndexInit[31:0] = (CMAC(secDataProtectionKey, Derivation data))[31:0] = 041F3bA0 cryptoStsIndex = phyStsIndexInit[31:0] & 0x7FFFFFFF = 0x041F3BA0 Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (128) | key length (32b) • Counter[31:0] = 0x00000001

• Label[63:0] = "StsIndIn" = 0x53747349_6e64496e • Configuration digest[127:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc3 • Key length[31:0] = 0d128 = 0x00000080

D.2.6 secDerivedAuthenticationIV

secDerivedAuthenticationIV[127:0] = CMAC(secDataProtectionKey, Derivation data) = 0xfa326fed_87d2ef7e_b680b2d6_d119a9b8 Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b) • Counter[31:0] = 0x0001 • Label[63:0] = "DerAuthI" = 0x4465724175746849 • Configuration digest[95:0] = 0xfb3b24bf_d2933377_61b88fc3 • cryptoStsIndex[31:0] = 0x041f3ba0 • Key length[31:0] = 0d128 = 0x00000080

D.2.7 secDerivedAuthenticationKey

secDerivedAuthenticationKey = CMAC(secDataProtectionKey, Derivation data) = 0x91a2de58_ff3b5e85_153358d6_156464ff Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "DerAuthK " = 0x446572417574684b • Configuration digest[95:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc30 • cryptoStsIndex[31:0] = 0x041f3ba0 • Key length[31:0] = 0d128 = 0x00000080

D.2.8 secDerivedPayloadKey

secDerivedPayloadKey = CMAC(secDataProtectionKey, Derivation data) = 0x97e4ab69_6177bb39_9277b835_9fa55d19

Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b) • Counter[31:0] = 0x0001 • Label[63:0] = "DerPaylK" = 0x4465725061796c4b • Configuration digest[95:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc30 • cryptoStsIndex[31:0] = 0x041f3ba0 • Key length[31:0] = 0d128 = 0x00000080

D.2.9 STS

图62 - STS生成映射图

phyVupper64[63:0] = secDerivedAuthenticationIv[127:64] = 0xfa326fed_87d2ef7e phyStsVCounter[31:0] = secDerivedAuthenticationIv[31:0] & 0x7FFFFFFF = 0x5119a9b8

D.2.9.1. slot 0的STS

cryptoStsIndex[31:0] = 0x041f3ba phySts = 0x2e55ab08_1fc3dd8c_8dcbc4aa_f6173288_3ce03f40_772756e0_76111a4a_eda59dec_55b54fc0_c4a245a6_f6e1684e_22fc13fc_888bf19b_520e63f5_218b1155_eb69643a_699aed99_9098cabc_641d4f9d_241b8963_df9a690f_...

D.2.9.2. slot 1的STS

cryptoStsIndex[31:0] = 0x041f3ba1 phySts = 0x133b2859_b8567a35_3b9f519b_30fac311_3b4d30bd_442498b4_8d9e0f28_107a6711_5b343e89_7b996d7c_0da01fe5_3f0b4070_37a56aaf_393c2308_8c0bca32_70f085ad_ba07c715_9d3e89e2_84cae79a_c0c8d023 ….

D.2.9.3. slot 2的STS

cryptoStsIndex[31:0] = 0x041f3ba2 phySts = 0xd50c6c19_376b130b_c963c0d7_c4d0b440_034aec37_faee1fba_882fa38b_302620df_dad0203d_2e332486_58317d45_3c280205_c50e8aa2_b70d38a7_2111186b_ …

D.2.9.4. slot 3的STS

cryptoStsIndex[31:0] = 0x041f3ba3 phySts = 0x 0xa5a9cc8a_5cc049e9_569eef6c_bffa0e01_88dc9a88_fd31791d_211ae603_98897300_6b9abc62_6941daf6_040cc7ae_7f102de0_40df0ce7_03af84ec_ …

D.2.10 RCM帧

给出了slot 0的典型RCM帧（带专有厂商IE）。注意，应用了IEEE字节序，且未显示FCS字段。源地址为0xaaa1，目的地址为0xaaa2。

Plaintext Vendor IE: 0x08080808_08080808_67452301_a03b1f04 Proprietary Vendor IE: 0x846ca43c_52fbb02b_56a9879d_b04e4e03 Header: 0x492ba2aa_261300ff_185a846c_a43c52fb_b02b56a9_879db04e_4e03003f Plaintext: 0x1b90ff18_5a030500_00034255_01044455_03074255_05094255_090a4455_0b Ciphertext: 0x8276e044_f378abbe_d239867e_d2fe5c9d_cd131d1f_6338f1f7_9db18471_72 Tag: 0x7a10fc80_047edb0f CCM* nonce: 0x00000000_0000aaa1_041f3ba0_06 Full IEEE packet (not including FCS): 0x492ba2aa_261300ff_185a846c_a43c52fb_b02b56a9_879db04e_4e03003f_8276e044_f378abbe_d239867e_d2fe5c9d_cd131d1f_6338f1f7_9db18471_727a10fc_80047edb_0f

D.3 动态STS和预配置STS（256位密钥，无密钥轮换）

D.3.1 DerivedConfigDigest

与第D.2.1节相同。

D.3.2 会话密钥

对于动态和预配置STS，会话密钥的生成不在MAC规范的范围内。对于本参考文档，secSessionKey[255:0] = "DynamicSTSNoRot0DynamicSTSNoRot0"的ASCII值。

= 0x44796E61_6D696353_54534E6F_526F7430_44796E61_6D696353_54534E6F_526F7430

D.3.3 secDataPrivacyKey

secDataPrivacyKey[127:0] = CMAC(SessionKey, Derivation data) = 0x139CE684_4DC672E4_97EE3745_7870A392 Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (128) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "PrivacyK" = 0x50726976_6163794B • Configuration digest[127:0] = 0x089366BA_FB3B24BF_D2933377_61B88FC3 • Key length[31:0] = 0d128 = 0x00000080

D.3.4 secDataProtectionKey

secDataProtectionKey = CMAC(SessionKey, Derivation data) = 0xC339F2DA_5DE35443_CB6EC23F_ADD804C5_AB49282E_32C91343_2116BAE1_B87F9F58 Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (128) | key length (32b) • Counter [31:0] • 第一轮: Counter [31:0] = 0x00000001 • 第二轮: Counter[31:0] = 0x00000002 • 以此类推。 • Label[63:0] = "DataPrtK" = 0x44617461_5072744B

• Configuration digest[127:0] = 0x089366BA_FB3B24BF_D2933377_61B88FC3 • Key length[31:0] = 0d256 = 0x000000100

D.3.5 phyStsIndexInit

phyStsIndexInit[31:0] = (CMAC(secDataProtectionKey, Derivation data))[31:0] = 0x9369DBEE cryptoStsIndex = phyStsIndexInit[31:0] & 0x7FFFFFFF = 0x1369DBEE Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (128) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "StsIndIn" = 0x53747349_6E64496E • Configuration digest[127:0] = 0x089366BA_FB3B24BF_D2933377_61B88FC3 • Key length[31:0] = 0d128 = 0x00000080

D.3.6 secDerivedAuthenticationIV

secDerivedAuthenticationIV[127:0] = CMAC(secDataProtectionKey, Derivation data) = 0xE2D7DAB2_D95DF4DD_CF933F7B_0C80DF3A Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b) • Counter[31:0] = 0x00000001 • Label[63:0] = "DerAuthI" = 0x4465724175746849 • Configuration digest[95:0] = 0xFB3B24BF_D2933377_61B88FC3 • cryptoStsIndex[31:0] = 0x1369DBEE • Key length[31:0] = 0d128 = 0x00000080

D.3.7 secDerivedAuthenticationKey

secDerivedAuthenticationKey = CMAC(secDataProtectionKey, Derivation data) = 0xE9E1F718_0CFE4874_EDD83997_A87D45B6 Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b)

• Counter[31:0] = 0x00000001 • Label[63:0] = "DerAuthK " = 0x446572417574684B • Configuration digest[95:0] = 0xFB3B24BF_D2933377_61B88FC3 • cryptoStsIndex[31:0] = 0x1369DBEE • Key length[31:0] = 0d128 = 0x00000080

D.3.8 secDerivedPayloadKey

secDerivedPayloadKey = CMAC(secDataProtectionKey, Derivation data) = 0x8F328A0D_BA0E0487_F45D4962_9D0AAE76 Derivation data[255:0] = Counter (32b) | Label (64b) | Configuration digest (96) | cryptoStsIndex (32b) | key length (32b) • Counter[31:0] = 0x0001 • Label[63:0] = "DerPaylK" = 0x4465725061796C4B • Configuration digest[95:0] = 0xFB3B24BF_D2933377_61B88FC3 • cryptoStsIndex[31:0] = 0x1369DBEE • Key length[31:0] = 0d128 = 0x00000080

D.3.9 STS

有关STS生成图，请参见第D.2.9节和图55。

phyVupper64[63:0] = secDerivedAuthenticationIv[127:64] = 0xE2D7DAB2_D95DF4DD phyStsVCounter[31:0] = secDerivedAuthenticationIv[31:0] & 0x7FFFFFFF = 0x0C80DF3A

D.3.9.1. slot 0的STS

cryptoStsIndex[31:0] = 0x1369DBEE phySts = 0x41F1BE09_68031FC9_E58CC4E1_251573A4_21E73320_788105AF_2B77D748_97228869_DAC33933_2214FFBC_8C43211F_DDFD2D78_D79240B0_360A7108_C555BA4D_73D9F02E_...

D.3.9.2. slot 1的STS

cryptoStsIndex[31:0] = 0x1369DBEF phySts = 0x7CA5A909_328E5D4B_D5079AFB_CD12931A_8D7C996D_1271ED6E_BE527CAB_633BD4A4_A2BFC1AE_74A4455F_7B217CF7_E0B01FC5_50E7E456_0C2AF64D_EAB47E71_9C1D4070_….

D.3.9.3. slot 2的STS

CryptoStsIndex[31:0] = 0x1369DBF0 phySts = 0xD97AE091_487C055E_0E3E0A87_E4676BD8_3BECA68B_1AB3C18B_04971548_EE78867F_E8ABD49B_179A5E94_73FD72A0_BE70287B_9A6E9E4D_D07762BE_F0CAB869_32257945_…

D.3.9.4. slot 3的STS

CryptoStsIndex[31:0] = 0x1369DBF1 phySts = 0x3338FBB2_65080293_22C84BAB_72BAE443_9147EF59_C68AA76A_BA6C11D4_6092A605_90E1A486_5E700EF9_A1AD3E8A_3AB9B506_4704C524_A5B55EAC_4DDCEEFC_C434FA93_ …

D.3.10 RCM帧

给出了slot 0的典型RCM帧（带专有厂商IE）。注意，应用了IEEE字节序，且未显示FCS字段。源地址为0xAAA1，目的地址为0xAAA2。

Plaintext Vendor IE: 0x08080808_08080808_67452301_EEDB6913 Proprietary Vendor IE: 0xC14737EE_8DCAF41F_31D62105_9CE5D23C Header: 0x492BA2AA_261300FF_185AC147_37EE8DCA_F41F31D6_21059CE5_D23C003F Plaintext: 0x1B90FF18_5A030500_00034255_01044455_03074255_05094255_090A4455_0B Ciphertext: 0x34D57E6F_7F30AB15_8CD700EA_C152590D_E0078BF8_1B4067E7_76587BC1_DC Tag: 0xA836FAD4_51859283 CCM* nonce: 0x00000000_0000AAA1_1369DBEE_06

Full IEEE packet (not including FCS): 0x492BA2AA_261300FF_185AC147_37EE8DCA_F41F31D6_21059CE5_D23C003F_34D57E6F_7F30AB15_8CD700EA_C152590D_E0078BF8_1B4067E7_76587BC1_DCA836FA_D4518592_83

附录E AoA方位角和俯仰角测量

范围

E.1 三维平面上的到达角确定参考

图63 - 三维平面上的到达角确定参考

• 方位角和俯仰角测量始终相对于测量设备，而不是相对于天线。
• 如果设备旋转，参考轴也会随之旋转。
• Y轴是手机的垂直显示轴。
• X轴是手机的水平显示轴。
• Z轴是与手机显示正交的轴（后置摄像头视角方向）。

E.2 AoA俯仰角

AoA俯仰角是XZ平面与入射信号之间的相对角度。

E.2.1 在发起方处的测量

发起方上的厂商实现可以测量在RRM上完成的俯仰角和FoM，并将其作为UCI通知消息的一部分发送。

E.2.2 在响应方处的测量

响应方上的厂商实现可以测量在RIM上完成的俯仰角和FoM，并将其作为RRRM的一部分发送。

E.3 AoA方位角

AoA方位角是Z轴与投影到XZ平面上的入射信号之间的相对角度。在Z轴上为0，朝X轴顺时针方向为正，朝X轴逆时针方向为负。

E.3.1 在发起方处的测量

发起方上的厂商实现可以在RRM上测量方位角和FoM，并将其作为UCI通知消息的一部分发送。

E.3.2 在响应方处的测量

响应方上的厂商实现可以测量在RIM上完成的方位角和FoM，并将其作为RRRM的一部分发送。

附录

附录F　允许的操作参数集对

[PHY]定义了SFD#或SYNC PSR在测距轮次期间不应改变。因此，可使用的操作参数集数量有限。表71列出了延迟模式带数据和无数据RFRAME以及非延迟模式的这些集对。注意，在一个测距轮次期间仅使用SP0和SP3或SP0和SP1。集合在[PHY]表2（BPRF）和表3（HPRF）中定义。注意，集合32、33、34和35是FiRa特定的。

表71 - 允许的操作参数集对

附录G　DL-TDoA集群间同步

本资料性附录描述了一种DL-TDoA集群间同步方法，为DL-TDoA网络中的DT锚点提供了一种对齐其测距块结构并协调共享介质访问的手段，以避免集群间干扰。

DL-TDoA网络的公共测距块结构由参考DT锚点生成，参考DT锚点由DL-TDoA服务提供商通过UCI选择。其他DT锚点同步并将其测距块结构与参考DT锚点对齐。为简化说明，本附录假设只有一个参考DT锚点。然而，在大型DL-TDoA网络中，可能存在相互之间不连接的独立隔离区域及相应的锚点集合。在这种情况下，每个网络区域可以有一个参考DT锚点。

本附录描述了两种可选机制（在G.1和G.2节中）来实现集群间同步，并提供了DT锚点的UWBS操作指南（G.3节）：

• 机制1（G.1节）提供了一种简单算法，可在DL-TDoA网络的简单拓扑（例如，由一个或多个集群组成的DL-TDoA网络）或静态拓扑（很少添加新DT锚点且很少移除现有DT锚点）中运行。机制1为DT锚点供应商提供了更大的灵活性，使其可以在不要求DTM中增加任何额外字段的情况下实现DT锚点与公共测距块结构的同步。机制1适用于简单的DL-TDoA网络，其中集群例如在一个方向上成排部署，使得发起DT锚点只有少数可听到的相邻发起DT锚点（例如，每侧仅两个），如图64所示。

图64 - 机制1适用的DL-TDoA拓扑示例说明。标记为4的发起DT锚点（锚点4）只能听到锚点3和锚点5，因此它仅使用锚点3和锚点5的轮询DTM进行集群间同步

• 机制2（G.2节）提供了另一种算法，使DT锚点能够形成以参考DT锚点为树根的时间同步树状结构。为此，发起DT锚点需要适当计算其与参考DT锚点之间的无线通信跳数（Hop Count），并在其轮询DTM中包含跳数字段。机制2适用于复杂的DL-TDoA网络，其中DT锚点被多个集群环绕，选择其中一个或多个集群进行同步是有益的。

对于两种机制，DL-TDoA网络中的DT锚点都配置有与测距块结构相关的相同参数（即时隙持续时间、轮次持续时间和块持续时间）。此外，假设DL-TDoA服务提供商已在DT锚点开始DL-TDoA会话之前为每个DT锚点设定了具体的角色和操作测距轮次。

G.1　机制1（轮询DTM中不含跳数字段的集群间同步算法）

本节描述了一个满足第6.3.4.1.2节中规定的引导和集群间同步相关要求的实现示例。

前提条件：DT锚点已上电并启动DL-TDoA会话，但尚未开始发送DTM。存在一个参考DT锚点。分配给参考DT锚点的测距轮次的轮次索引为k（0≤k<N，其中N为一个测距块中的测距轮次数量）。所有DT锚点持续监听轮询DTM。

• 步骤1（测距块初始化）：参考DT锚点根据其本地时钟在第(k+1)个测距轮次的第一个测距时隙开始发送轮询DTM。测距块的第一个测距时隙由参考DT锚点确定。通过发送第一个轮询DTM，参考DT锚点生成了网络中所有DT锚点所依赖的测距块。

  参考发起DT锚点将此时间纪元视为第(k+1)个测距轮次的第一个测距时隙。

图65 - 步骤1的说明。假设参考DT锚点被配置在第(k+1)个测距轮次中工作。参考DT锚点在第(k+1)个测距轮次的第一个测距时隙中发送其第一个轮询DTM

• 步骤2（参考DT锚点的集群开始工作）：与参考DT锚点同一集群的响应DT锚点通过接收来自参考DT锚点的轮询DTM开始运行。响应DT锚点在轮询DTM分配的测距时隙中发送响应DTM。同步行为类似于TWR中控制器和控制受控者的行为。此时，参考DT锚点所在的集群开始运行。此外，任何能够接收参考DT锚点第一个轮询DTM的DT锚点都可以与公共测距块同步，并准备从下一个测距块开始在适当的时间发送其DTM。

图66 - 步骤2的说明。与参考DT锚点同一集群的响应DT锚点在接收到来自参考DT锚点的第一个轮询DTM后开始发送其响应DTM

• 步骤3（参考DT锚点的相邻集群开始工作）：除参考DT锚点以外的发起DT锚点尝试监听在不同测距轮次上运行的相邻发起DT锚点的轮询DTM。初始时，参考DT锚点是网络上唯一运行的发起DT锚点，因此连接到（换言之，能监听到来自参考DT锚点的轮询DTM）参考DT锚点的发起DT锚点可以使用来自参考发起DT锚点的第一个轮询DTM与参考DT锚点的测距块对齐后开始发送其轮询DTM。此时，连接到参考DT锚点的发起DT锚点的集群开始运行。此处，如果某集群中的发起DT锚点能够监听到参考DT锚点的大多数轮询DTM，则认为该集群连接到参考DT锚点。

图67 - 步骤3的说明。能够监听到参考DT锚点轮询DTM的发起DT锚点从下一个测距块（即块索引为1的测距块）开始发送其轮询DTM

• 步骤4（未直接连接到参考DT锚点的集群开始工作）：随着步骤3被DL-TDoA网络中的发起DT锚点反复执行，未直接连接到参考DT锚点（但通过一个或多个其他发起DT锚点连接到参考DT锚点）的集群将能够工作。

图68 - 步骤4的说明。无法接收到参考DT锚点轮询DTM的发起DT锚点在接收到已与参考DT锚点同步的相邻发起DT锚点的任意轮询DTM后开始发送其轮询DTM

• 步骤5（运行时块对齐）：发起DT锚点可以使用接收到的DTM来调整其可能因时钟漂移而抖动的块结构。例如，通过监听前一个测距块中的所有DTM，发起DT锚点可以根据接收到的DTM中包含的发送时间戳和这些DTM的接收时间戳来确定下一个测距块中其轮询DTM的发送时间。

图69 - 步骤5的说明。在开始轮询DTM发送后，发起DT锚点可以基于其在先前测距块中接收到的轮询DTM的接收时间戳来调整其轮询DTM的发送时间

如图69所示，第4个测距轮次的发起DT锚点（称为第4发起DT锚点）可以基于先前测距块（即块索引n-1）中接收到的轮询DTM的接收时间戳来调整第(n+1)个测距块（即块索引n）中轮询DTM的发送时间。假设第4发起DT锚点接收到来自第2、第3、第5和第N发起DT锚点的轮询DTM，其接收时间戳分别为t_Rx(2, n)、t_Rx(3, n)、t_Rx(5, n)和t_Rx(N, n)。则第4发起DT锚点在第(n+1)个测距块中轮询DTM的发送时间可以确定为t_Rx(2, n)、t_Rx(3, n)、t_Rx(5, n)、t_Rx(N, n)和轮次持续时间的函数输出。

注意，调整轮询DTM发送时间戳的计算函数细节（例如，使用多少个接收时间戳、每个时间戳的权重以及使用多少个最近的测距块来收集接收时间戳）是实现特定的。

当新的发起DT锚点加入DL-TDoA网络时，该发起DT锚点会在一段时间内（例如，块持续时间）接收来自其他发起DT锚点的轮询DTM，并基于这些接收到的轮询DTM的接收时间戳，通过类似于步骤5的操作开始在其测距轮次中发送轮询DTM。

当某个发起DT锚点因某种问题停止运行时，与该故障发起DT锚点同一集群的响应DT锚点由于缺少轮询DTM而无法发送其响应DTM。

G.2　机制2（基于跳数的集群间同步树构建）

该机制构建一种时间同步树状结构，使每个发起DT锚点与参考DT锚点（树根）之间的代价度量¹（跳数）最小化。为此，机制2在轮询DTM中包含额外信息（跳数字段）。与机制1相比，该机制对可选择用于同步和对齐公共块结构的发起DT锚点施加了一些限制。换言之，使用该机制时，DT锚点只能与代价比其本地代价度量更低的发起DT锚点进行同步。

¹ 在本附录中，术语"代价度量"和"跳数"可互换使用。

跳数反映了每个DT锚点与参考DT锚点同步的路径代价，以DT锚点与参考DT锚点之间的无线通信跳数来衡量。代价度量在网络中单调递增。参考DT锚点具有最低度量h_reference = 0，而其他DT锚点初始将其代价度量设置为最大值h = 0xFF，表示它们尚未与公共时间基准对齐且未连接到网络（图4a）。使用跳数作为路径代价度量有利于简化实现，但可能导致选择更长、可能不太可靠的链路进行时间同步。供应商在选择同步树中的时间同步父节点时可以引入额外的约束，例如丢弃或降低权重较差或不可靠的无线链路。

当参考DT锚点启动其DL-TDoA测距会话并在其作为发起者参与的活动测距轮次中发送包含跳数字段（h_reference = 0）的第一个轮询DTM时，树的形成开始。通信范围内的活动DT锚点接收这些轮询DTM，选择参考DT锚点作为其父节点，将其度量设置为h = h_reference + 1 = 1，并与公共块结构对齐（详见G.3节）。对齐后，这些DT锚点可以开始参与其活动测距轮次，发送包含其本地跳数字段的轮询DTM，使距离树根更远的DT锚点能够加入网络。经过几个块后，这应有助于每个活动DT锚点在树中选择一个父节点（或一组父节点），并在由参考DT锚点最初设置的公共块结构上运行。G.2.1节通过示例网络拓扑说明了引导时的树形成过程。

为了选择父节点，DT锚点通常会比较其本地代价值h_local与接收到轮询DTM的发起DT锚点的代价值h_sender。如果h_sender + 1 < h_local，DT锚点可以选择该发送方发起者作为其新父节点或时间源，将本地度量设置为h_local = h_sender + 1。在这种情况下，DT锚点可以与所选父节点同步并与其块结构对齐。每次DT锚点从所选父节点接收到轮询DTM时，可以重新同步以减少同步误差和微小的块失准。如果h_sender + 1 = h_local，发送方发起DT锚点与当前所选父节点到参考DT锚点的跳数相同。在这种情况下，选择该发送方发起DT锚点在同步方面可能不会带来太多益处，DT锚点可以保持当前所选父节点。或者，它可以将该发起DT锚点添加到可用于改善同步的选定父节点集合中。最后，如果h_sender + 1 > h_local，这意味着发送方比接收DT锚点距离参考DT锚点更远，因此接收到的轮询DTM可以出于同步目的被丢弃。

为了提高该机制的鲁棒性，DT锚点不仅可以考虑一个父节点，还可以考虑一组具有相同代价度量的父节点。这意味着，例如，如果代价度量为h = 3的发起DT锚点有三个相同度量h = 2的父节点，它可以存储来自这三个父节点的信息，并使用其聚合信息来改善其同步性能和与块结构的对齐。然而，DT锚点不能直接利用代价度量高于或等于其当前值的锚点，因为这些锚点距离参考DT锚点更远，因此可能存在更高的时钟同步误差。

为了应对网络变化，DT锚点可以移除或丢弃过时的父节点，例如，在多个块中未从其接收到轮询DTM的父节点。移除这些父节点后，DT锚点重新计算其度量并选择另一个父节点，以保持与公共块结构的对齐并能够参与其活动测距轮次。G.2.2节说明了链路故障后树结构如何适应的示例。

G.2.1　集群间同步树形成示例

本节通过示例网络拓扑说明了在DL-TDoA会话开始时DT锚点如何使用代价度量形成同步树。

图70a显示了初始DL-TDoA网络状态。DL-TDoA网络处于断开状态，因为DT锚点不知道可用的无线链路，也不知道由参考DT锚点设置的公共测距块结构的时间。因此，DT锚点尚不能参与其活动测距轮次，只能继续监听轮询DTM以进行同步。在此状态下，普通DT锚点将其代价度量或跳数设置为最大值0xFF，而参考DT锚点将其度量设置为0。

一旦参考DT锚点（图70中的节点#1）的DL-TDoA测距会话开始，参考DT锚点可以开始在其以发起者角色参与的活动测距轮次中发送包含跳数字段（h_reference = 0）的轮询DTM，使通信范围内的活动DT锚点能够加入网络。注意，参考DT锚点也可以在其他测距轮次中作为响应者参与——为简化说明此处未显示。接收到参考DT锚点轮询DTM的DT锚点可以直接选择参考DT锚点作为其时间源，并将其跳数更新为h = h_reference + 1 = 1，表示它们距离参考DT锚点一个同步跳。此行为如图70b所示，其中节点#2接收到来自#1的轮询DTM，选择#1作为其父节点，加入网络，并与参考DT锚点（#1）设置的公共块结构对齐。

树构建在图70c中继续，节点#2在其被配置为发起DT锚点的活动测距轮次中发送轮询DTM。注意，根据实现和通过设置每个DT锚点的活动测距轮次而配置的调度，#2可以在接收到来自#1的轮询DTM的同一块索引中（图70b）或在下一个块中发送其轮询DTM。在图70c中，节点#1、#3和#4接收到来自#2的轮询DTM。参考DT锚点（#1）可以安全地丢弃该轮询DTM用于集群间同步，因为它是树的根节点，因此其度量h₁ < h₂。#3和#4则可以选择#2作为其父节点，因为h₂ + 1 = 2 < 0xFF（初始度量）。因此，它们将度量设置为h₃ = h₄ = 2，基于从#2获得的信息与公共块结构对齐，并开始参与其配置的测距轮次，如图70d和图70e所示。

图70 - 使用机制2的代价度量构建DL-TDoA时间同步树状结构的简化示例。蓝色圆圈表示在至少一个测距轮次中承担发起DT锚点角色的DT锚点，灰色圆圈表示仅作为响应DT锚点参与的DT锚点

在图70d中，节点#4加入网络后发送其自己的轮询DTM。该轮询DTM可能被#2、#3和#5接收。在此特定情况下，#2可以安全地丢弃来自#4的轮询DTM用于集群间同步，因为h₂ < h₄。类似地，#3观察到选择#4作为父节点没有实际益处，保持#2作为其时间源，后者提供更低的代价度量或跳数。然而，#3可以将来自#4的信息存储为用于同步的备份父节点。相反，当#5接收到来自#4的轮询DTM时，它选择#4作为同步树中的父节点，加入网络，与公共块结构对齐，并将其跳数设置为h₅ = h₄ + 1 = 3。

在图70e中，节点#3发送的轮询DTM可能被#2、#4和#5接收。节点#2可以丢弃该轮询DTM用于同步。#4的行为与图70d中#3的行为相同，最后#5观察到选择#3作为父节点产生与选择#4相同的代价h₅ = h₃ + 1 = 3跳。在这种情况下，#5可以决定保持#4作为其父节点，选择#3作为其新的首选父节点，或以某种方式使用两个父节点来改善同步性能。为做出此决定，供应商可以使用此处未规定的额外逻辑。注意，为提高稳定性，节点不应更改父节点，除非从中获得实际益处（例如，跳数减少、可靠性提升或修复度量不一致）。然而，供应商也可以考虑对所选父节点进行老化处理，以避免DT锚点固守可能不再提供可靠或一致跳数值的旧链路。

最后，在图70f中，#5发送轮询DTM。由于h₅大于所有接收节点（#3和#4）的度量，这些节点可以出于集群间同步的目的丢弃来自#5的轮询DTM。

在图70f之后，树状结构形成，节点可以基于从所选父节点接收到的轮询DTM定期（例如，在每个块中）重新同步。

注意，在本示例中，仅作为响应DT锚点行为的DT锚点（在图70中以灰色圆圈表示）也可以使用从轮询DTM接收到的跳数字段来选择首选父节点/时间源（或一组父节点/时间源），以与上述发起DT锚点相同的方式遵循调度。然而，仅作为响应者行为的DT锚点不发送轮询DTM，因此不能成为其他DT锚点的父节点或时间源。

G.2.2　DL-TDoA网络变化的适应

无线链路是动态的，节点可能被移动、发生故障、被添加到网络或被移除。这可能导致网络拓扑的变化，需要机制2适应已构建的树状结构。图71说明了该机制如何基于前述示例处理链路故障。

在图71a中，节点4和2之间的链路消失，使#4无法重新同步到最初由参考DT锚点（#1）设置的DL-TDoA网络的公共块结构。经过一段时间后，节点#4可能意识到其与#2的链路不再存在，因此决定移除或丢弃#2作为父节点。例如，如果#4在多个块中无法听到#2的消息，则可能发生这种情况。何时丢弃父节点的决定是供应商和实现特定的，因为它可能取决于例如DT锚点在不接收来自所选父节点消息的情况下保持其时钟与网络同步的能力。一旦#4决定丢弃#2作为其父节点，#4有以下几种选项来应对网络变化：

1. 节点#4可以使用备份父节点（如果可用），例如本例中的节点#3，将其度量更新为h₄ = h₃ + 1 = 3，如图71b所示。然而，这将在树中造成不一致，因为#5之前已选择#4作为其父节点，此时两个节点都有h₄ = h₅ = 3。节点#5可以在下次从#4接收到轮询DTM时检测到不一致，通过检查h₄ < h₅不再成立，从而不再将#4作为父节点，并选择另一个具有更优度量的可达节点（#3）作为首选父节点。此最终变化反映在图71c中。

2. 或者，节点#4可以断开与网络的连接，将其度量设置为0xFF一段时间（实现特定），并重启其UWBS接收器以持续监听轮询DTM，从而重新对齐到公共块结构（参见G.3节）。然后#4可以接收来自#3和#5的轮询DTM，最终达到与图71c相同的网络状态。根据#4断开连接的时间以及#5认为其与#4的链路过时所需的时间，网络也可能经过不一致状态（图71b）或更直接地达到最终状态（图71c）。

图71 - DL-TDoA集群间同步树适应网络变化的示例

G.3　集群间同步的UWBS行为示例

本节详细说明了DT锚点如何操作其UWBS无线电以加入DL-TDoA网络，基于所选的集群间同步机制与公共块结构对齐，并参与（发送DTM）配置的活动测距轮次。注意，本节仅说明了一种可能的UWBS行为，供应商可以自由地进一步优化其UWBS的操作方式，例如以降低功耗或提高同步性能。

当DT锚点的DL-TDoA测距会话开始时，DT锚点初始时打开发送器，监听来自发起DT锚点的轮询DTM（可能包含集群间同步信息），如图72所示。注意，DL-TDoA使用静态STS机制。因此，尚未同步的DT锚点只能监听并成功接收在测距轮次第一个测距时隙中发送的、cryptoStsIndex设置为零的轮询DTM。DT锚点持续此行为直到成功接收到轮询DTM，使其能够将其块结构与DL-TDoA网络（由参考DT锚点建立）的块结构进行首次对齐。如果选择了机制2（G.2节），这也允许DT锚点选择第一个父节点（时间源）并获得第一个有效的代价度量值。

图72 - 普通发起DT锚点的无线电行为

当DT锚点接收到其第一个轮询DTM时，它可以从轮询DTM的有效载荷中提取当前的测距块和轮次索引（即块索引和轮次索引）。基于此信息以及对块、轮次和时隙持续时间的预定义知识，DT锚点可以估计当前测距轮次何时结束以及下一个何时开始。类似地，使用通过UCI指定的配置活动测距轮次，DT锚点可以规划其下一个活动测距轮次何时开始。为了估计下一个测距轮次的开始时间，DT锚点可以首先近似当前测距轮次i的开始时间t^start_i。这可以通过以下公式获得：

t^start_i = t^RX_Poll,i − t_SHR

其中t^RX_Poll,i是指DT锚点测量的接收到的轮询DTM的接收时间戳，t_SHR表示发送UWB帧的前导码和SFD部分所需的时间（DT锚点已知）。然而注意，DT锚点可能会在预期时间t^start_i之前略微提前启动其接收器，以便有足够的提前量醒来，从而能够在存在时钟伪影（例如时钟漂移或块失准）的情况下接收到帧。

基于确定的t^start_i，下一个测距轮次的开始时间已知为t^start_i + T_ROUND，其中T_ROUND是基于配置的DL-TDoA块、轮次和时隙结构的测距轮次持续时间。类似地，可以基于当前测距轮次、轮次持续时间T_ROUND和每个块的轮次数来估计下一个块的开始时间。

通过接收第一个轮询DTM并确定每个测距轮次的开始和结束时间，DT锚点可以将其块结构与DL-TDoA网络使用的公共块结构（最初由参考DT锚点设置）进行首次对齐。此后，它可以通过在每个测距轮次的第一个时隙打开发送器来持续重新同步和重新对齐块结构，如图72所示，使DT锚点能够接收范围内发起DT锚点的轮询DTM，并选择适当的时间源（或时间源集合）以避免时间同步环路或不希望的集群间干扰。然而，替代实现可以仅每隔几个块监听轮询DTM以降低能耗，或考虑其他技术（此处未规定）以提高DT锚点的整体性能。

如果选择了机制2，父节点或时间源的选择基于轮询DTM中包含的跳数字段，详见G.2节。DT锚点只能基于所选父节点（或父节点集合）的轮询DTM进行重新同步，从而重新对齐其块结构。

DT锚点可能失去同步，例如，如果在多个块中未能接收到轮询DTM。在这种情况下，DT锚点可能无法确保其测距块结构与参考DT锚点的块结构充分对齐，并且可能需要重启其状态，打开发送器直到接收到另一个轮询DTM，使其能够重新对齐到公共块结构。DT锚点决定其失去同步的实际时间是供应商和实现特定的。

附录H　跳频序列示例

作为示例，假设BlockIndex为0x0001（即当前测距会话中的第二个测距块），SessionID为0x10203，一个测距块中有4个测距轮次。由于这些值用零填充，AES函数的输入为：

• BlockIndex：0x0000_0000_0000_0000_0000_0000_0000_0001（即三十一个0后跟1）。

• SessionID：0x0000_0000_0000_0000_0000_0000_0001_0203（即二十七个0后跟0x10203）

AES函数的输出为：

• 0x3170_1ba5_ee72_4e1b_5fbf_d519_1c3d_77de

将该值与0xFFFF执行AND运算得到：

• 0x0000_0000_0000_0000_0000_0000_0000_77de

将该数乘以4（N_Round）得到：

• 0x0001_df78

向右移16位得到BlockIndex 1的S值：

• 0x1（即1）

继续对BlockIndex值为2、3和4的序列，S的值分别为0、3和1。这意味着对于测距块0、1、2、3和4，测距轮次的轮次索引将分别为0、1、0、3和1。本示例中每个测距块中使用的测距轮次如图73所示。

图73 - 跳频序列示例

测距轮次索引、块索引和时隙索引的值按照[IEEE_802_15_4z_2020]中的定义引用。

附录I　HUS测距轮次动态视图

图74 - HUS测距轮次的动态视图

1. 测距轮次1中的HUS控制器创建CAP阶段，并识别响应者A和B（在本附录章节中，HUS受控者/响应者被称为设备A/B/C/D/E）。

2. 控制器在测距轮次M的CFP阶段中添加设备A，并创建CAP阶段供其他响应者参与。

   1. 在测距轮次M的CAP阶段中，控制器识别出设备C、D和E。

   2. 参与测距轮次M的设备A发现其配置的会话ID与RMML的阶段会话ID匹配。此外，它能够在测距轮次M的第一个CFP中发送的CM类型1消息的RDML中找到其设备MAC地址。参与测距轮次的第一个CFP阶段后，设备A将不再进一步参与该测距轮次。

   3. 参与测距轮次M的设备B发现其配置的会话ID与RMML的阶段会话ID匹配。当设备B在测距轮次M的第一个CFP中发送的CM类型1消息的RDML中找不到其设备MAC地址时，它随后同步到测距轮次的即将到来的CAP阶段，并在CAP阶段中发送RRM。

3. 在HUS过程中，在测距轮次N中，控制器创建2个具有相同会话ID和RF配置的CFP阶段，以在同一测距轮次中容纳超过8个受控者/响应者。同时还创建2个具有相同会话ID和RF配置的CAP阶段。

   1. 参与测距轮次M的设备A、B、C、D和E发现其配置的会话ID与RMML中CFP和CAP阶段对应的阶段会话ID匹配。

   2. 设备A、B和D参与测距轮次的第一个CFP阶段，因为它们在第一个CFP中发送的CM类型1消息的RDML中找到了其MAC地址匹配。

   3. 设备C在第一个CFP阶段的CM类型1的RDML中找不到其MAC地址。它随后同步到即将到来的CFP，在第二个CFP中发送的CM类型1消息的RDML中找到其MAC地址，并参与测距轮次N的该CFP阶段。

   4. 设备E在第一个和第二个CFP阶段的CM类型1的RDML中均找不到其MAC地址。它随后参与测距轮次N即将到来的CAP阶段并发送RRM。

附录J　DL-TDoA跨集群同步

本资料性附录描述了一种DL-TDoA跨集群同步方法，以实现发起DT锚点之间亚纳秒精度的同步。此附加同步功能提高了定位稳定性和精度，因为来自不同集群的DTM可以更灵活地组合，容忍更高比例的消息丢失或非视距（NLOS）影响的消息到达DT标签。这有助于在集群边界之间对齐发送时间戳，从而允许使用来自超级集群内不同集群的DTM进行DT标签定位。

跨集群同步旨在区域性地限制在具有良好无线电传播特性的区域，如展览馆。它维护一个由属于同一超级集群的发起DT锚点共享的公共时间。超级集群由标识符（超级集群ID）指示。使用相同标识符的DL-TDoA锚点被允许彼此之间执行跨集群同步。

跨集群同步是一种可选的特性方法。它可以作为集群内同步和集群间同步的补充使用。

发起DT锚点和响应DT锚点之间的集群内同步保持向后兼容，因为响应DT锚点可以被配置为使用集群内公共时间基准。跨集群同步将公共时间基准从单个集群扩展到形成超级集群的多个集群。属于超级集群的每个发起DT锚点在更新其超级集群公共时间基准时，会考虑来自使用相同超级集群ID的可达范围内的其他发起DT锚点的轮询DTM。

跨集群同步利用发起DT锚点之间跨多跳的公共时间交换。公共时间由一组3个值表示：

• 发送时间戳（txTs），表示公共时间中的一个tick精度时间点。

• 时钟频率偏移（CFO），表示设备本地时钟频率与公共时间频率之间的频率偏移。

• 超级集群ID（scID），指示超级集群的成员资格，即具有良好视距条件、允许tick精度时间同步的区域。

图75通过两个发起DT锚点的示例说明了公共时间更新过程。

图75 - 跨集群同步更新过程示例

发起DT锚点A发送一个轮询DTM，其中包含公共时间基准中的发送时间戳txTsA、其相对于公共时间频率的时钟频率偏移cfoA以及超级集群标识字段scIDA。如果发起DT锚点A正在启动公共时间提供过程，它将提供txTsA和cfoA的初始值。在没有先验知识的情况下，两个值都可以初始化为零。scIDA值表示配置给发起DT锚点A的超级集群ID值。

当发起DT锚点B接收到来自发起DT锚点A的轮询DTM时，它首先检查发起DT锚点B的超级集群ID是否与发起DT锚点A的超级集群ID匹配。如果它们相同（两个发起DT锚点属于同一超级集群），则来自锚点A的轮询DTM将用于更新发起DT锚点B的公共时间，使用发送的TX时间戳txTsA和发送的CFO值cfoA。这包含以下步骤：

1. 确定DT锚点B处的公共时间

   通过测量或已知发起DT锚点A与发起DT锚点B之间的距离，可以使用发送的TX时间戳txTsA并校正发起DT锚点A与发起DT锚点B之间的飞行时间tofAB来确定DT锚点B处的公共时间。

   txTsB = txTsA + tofAB * nominal-tick-frequency * (1+cfoA)

2. 确定发起DT锚点B处相对于公共时间频率的频率偏移

   通过测量发起DT锚点A与发起DT锚点B本地频率之间的时钟频率偏移cfoAB，可以使用来自发起DT锚点A的发送CFO值cfoA并校正cfoAB的值来确定DT锚点B处相对于公共时间的频率偏移cfoB。

   1+cfoB = (1+cfoA)(1+cfoAB)

3. 更新DT锚点B处的时钟频率偏移和公共时间

   基于从步骤1和2获取的信息，DT锚点B处的公共时间信息将被更新。为处理飞行时间确定和CFO测量中涉及的误差，发起DT锚点B处的公共时间信息可以在多个DTM上进行跟踪。在这种情况下，步骤1和2的值可以在更新过程中部分考虑，同时也考虑历史定时信息。一种示例方法可以在实际信息和历史信息之间使用恒定加权因子k。

更新后的CFO值和公共时间随后可用于发起DT锚点B处DTM的组装和调度。

此过程可以应用于共享相同超级集群ID的多个发起DT锚点。图76说明了一个示例设置，其中5个发起DT锚点分布在2个超级集群上。发起DT锚点A、B、C属于超级集群1。发起DT锚点D、E属于超级集群2，该集群通过一堵墙与超级集群1分隔。

图76 - 使用分布在2个超级集群中的5个发起DT锚点进行跨集群同步的示例

该墙可能在发起DT锚点C与发起DT锚点D之间的消息交换中引入显著的飞行时间误差。由于发起DT锚点D接收到来自发起DT锚点C的轮询DTM时使用不同的超级集群ID，因此该轮询DTM不会用于跨集群同步。