6 要求（Requirements）
6.1 前提条件（Prerequisites）
设备能力（Device capabilities）宜在测距之前在对等设备之间进行交换。
6.1.1 UWB 配置参数（UWB configuration parameters）
FiRa 设备宜按照表 52 中的 UWB 配置参数进行配置（例如经由上层）。
表 52 - UWB 配置参数（UWB Configuration Parameters）
| Parameter | Notes |
|---|---|
| Session ID | UWB 会话标识符，作为头部 IE 的一部分传输的 32 位整数。 |
| Ranging Round Usage | 参见 [UCI] 中的 RANGING_ROUND_USAGE |
| Multi-Node Mode | 参见 [UCI] 中的 MULTI_NODE_MODE |
| Device Role | 参见 [UCI] 中的 DEVICE_ROLE |
| Device Type | 参见 [UCI] 中的 DEVICE_TYPE |
| RFRAME Configuration | 参见 [UCI] 中的 RFRAME_CONFIG |
| ToF Report | UWB 消息 RRR Type1 中 ToF 报告的存在性：无可用 ToF 报告 / ToF 报告可用。参见 [UCI] 中的 RESULT_REPORT_CONFIG |
| AoA Azimuth Report | UWB 消息 RRR Type 1 中 AoA 方位角报告的存在性：无 AoA 方位角报告 / AoA 方位角报告。参见 [UCI] 中的 RESULT_REPORT_CONFIG |
| AoA Elevation Report | UWB 消息 RRR Type 1 中 AoA 俯仰角报告的存在性：无 AoA 俯仰角报告 / AoA 俯仰角报告。参见 [UCI] 中的 RESULT_REPORT_CONFIG |
| AoA FoM Report | UWB 消息 RRR Type 1 中 AoA FoM 报告的存在性：无 AoA FoM 报告 / AoA FoM 报告。参见 [UCI] 中的 RESULT_REPORT_CONFIG |
| Round Hopping | 参见 [UCI] 中的 HOPPING_MODE |
| Block Striding | 参见 [UCI] 中的 BLOCKING_STRIDE_LENGTH |
| Block Skipping | 参见 [UCI] 中的 DL_TDOA_BLOCK_SKIPPING |
| Block Duration | 无符号整数，以 1200 RSTU（=1ms）为单位指定测距块的持续时间。默认块持续时间为 200 个单位（200ms）。参见 [UCI] 中的 RANGING_DURATION |
| Round Duration | 无符号整数，以时隙持续时间（Slot Duration）为单位指定测距轮的持续时间，由应用根据测距轮使用（Ranging Round Usage）进行配置。由 [UCI] 中的 SLOTS_PER_RR 配置，但以下情况除外：- 专用数据传输（轮持续时间等于块持续时间）。- 用于 AoA 测量的 OWR（不进行配置）。 |
| Slot Duration | 参见 [UCI] 中的 SLOT_DURATION |
| Channel Number | 参见 [UCI] 中的 CHANNEL_NUMBER |
| Preamble Code Index | 参见 [UCI] 中的 PREAMBLE_CODE_INDEX |
| PRF Mode | 参见 [UCI] 中的 PRF_MODE |
| Max RR Retry | 参见 [UCI] 中的 MAX_RR_RETRY |
| BPRF PHR Data Rate | 参见 [UCI] 中的 BPRF_PHR_DATA_RATE |
| UWB Initiation Time | 启动时间可能具有 +/-10% 的误差，具体取决于主处理器的运行状况和服务部署。参见 [UCI] 中的 UWB_INITIATION_TIME |
| Key Rotation | 参见 [UCI] 中的 KEY_ROTATION |
| Key Rotation Rate | 参见 [UCI] 中的 KEY_ROTATION_RATE |
| MAC FCS Type | 选择 MAC 帧尾中帧校验序列的类型。可能配置：MAC 帧尾中 FCS 使用 2 字节 CRC 为强制性；使用 4 字节 CRC 为可选。参见 [UCI] 中的 MAC_FCS_TYPE |
| MAC Address Mode | 参见 [UCI] 中的 MAC_ADDRESS_RMODEATE |
| Device MAC Address | 经由 UCI 接口配置的设备 MAC 地址。参见 [UCI] 中的 DEVICE_MAC_ADDRESS |
| Number of Controlees | 参见 [UCI] 中的 NUMBER_OF_CONTROLEES |
| DST MAC Addresses | 参见 [UCI] 中的 DST_MAC_ADDRESS |
| STS Config | 参见 [UCI] 中的 STS_CONFIG |
| TX Interval | 参见 [UCI] 中的 UL_TDOA_TX_INTERVAL |
| Random Window | 参见 [UCI] 中的 UL_TDOA_RANDOM_WINDOW |
| UL-TDoA Device ID | 参见 [UCI] 中的 UL_TDOA_DEVICE_ID |
| UL-TDoA TX Timestamp | 参见 [UCI] 中的 UL_TDOA_TX_TIMESTAMP |
| CAP Size Range | 该参数包含由上层配置的最小和最大 CAP 大小（参见 [UCI] 中的 CAP_SIZE_RANGE）。实际 CAP 大小不应超过所配置的最大 CAP 大小，且不应小于所配置的最小 CAP 大小。 |
| Data Repetition Count | 参见 [UCI] 中的 DATA_REPETITION_COUNT |
| Inter-Frame Interval | 参见 [UCI] 中的 INTER_FRAME_INTERVAL |
| MTU Size | 在单个数据消息内传输的最大传输单元的大小（以字节为单位）。MTU 大小的值应与所选的 PRF 模式和 IFI 兼容。参见 [UCI] 中的 MTU_SIZE_RATE |
| Minimum Frames Per RR | 参见 [UCI] 中的 MIN_FRAMES_PER_RR |
| Tx Jitter Window Size | 该窗口大小加上最大发送时间不应与从下一个允许的 Tx Offset 开始的可能传输重叠，且不应超过时隙持续时间。参见 [UCI] 中的 TX_JITTER_WINDOW_SIZE |
| Schedule Mode | 参见 [UCI] 中的 SCHEDULE_MODE |
| Suspend Ranging Round | 参见 [UCI] 中的 SUSPEND_RANGING_ROUNDS |
短 MAC 地址用于指示 UWB 消息的目的设备和/或源设备。扩展 MAC 地址用作 CCM*（计数器模式加密和密文块链接消息认证的扩展）的 nonce 的一部分，如 6.4.5 节所述。
（空白）（Blank）
本节有意留空。
6.2 MAC 层要求（MAC Layer Requirements）
FiRa 设备可为调度模式及相应的测距方法选择 MAC 特性集。为认证如下表所规定的合规性，选择合适的设备类型（Device Type）与设备角色（Device Role）组合，或仅选择适用的设备角色是重要的。
下表提供了强制性和可选 MAC 特性的概述，确保使用相同特性集的设备之间的互操作性。
表 53 - 表 54 和表 55 中所用的图例（Legends as used in Table 54 and Table 55）
| Symbol | Meaning |
|---|---|
| — | 不适用（Not Applicable） |
| I | 发起方（Initiator） |
| R | 响应方（Responder） |
| CTR | 控制器（Controller） |
| CL | 受控器（Controlee） |
| O | 可选（Optional） |
| M | 强制（Mandatory） |
| M* | 仅适用于观察者（Observer）设备 |
| O* | 仅对 DT 标签设备可选适用（Applicable optionally for DT-Tag device only） |
| CM | 条件强制（Conditionally Mandatory） |
| CM* | 条件强制，若支持该模式则至少须选择一项（Conditionally Mandatory, at least one must be selected if the mode is supported） |
| C | 以 CFP/CAP 调度模式的特性支持为条件（Conditional to the features support for the CFP/CAP schedule mode） |
| OWR UT | OWR UL-TDoA |
| OWR DT | OWR DL-TDoA |
| OWR AM | 用于 AoA 测量的 OWR（OWR for AoA Measurement） |
表 54 - 作为所选测距模式函数的特性集适用性定义（Feature set applicability definition as a function of the selected ranging mode）
表 54 - 作为所选测距模式函数的特性集适用性定义
源文档第 88 页
表 55 - 设备类型与设备角色互操作性（Device Type and Device Role interoperability）
表 55 - 设备类型与设备角色互操作性
源文档第 89 页
除非另有说明，以下要求均指带内通信。
6.3.1 MAC 帧格式（MAC Frame Format）
如图 45 所示，SP0 或 SP1 帧的通用 MAC 帧格式（MAC Frame Format）应由 MAC 头部（MAC Header）和 MAC 帧尾（MAC Footer）组成。更多信息请参考 [IEEE_802_15_4z_2020] 中的第 7 节。
图 45 - FiRa 中的通用 MAC 帧格式，改编自 [IEEE_802_15_4_2020] 的图 7-1（General MAC Frame Format in FiRa adapted from Figure 7-1 of [IEEE_802_15_4_2020]）
源文档第 90 页（本页同时含图 46 和图 47）
.png)
图 46 - MAC 头部终止 IE。该图改编自 [IEEE_802_15_4_2020] 的图 7-21。（MAC Header Termination IE. Figure adapted from Figure 7-21 of [IEEE_802_15_4_2020].）
源文档第 90 页
.png)
图 47 - 载荷终止 IE。该图改编自 [IEEE_802_15_4_2020] 的图 7-47。（Payload Termination IE. Figure adapted from Figure 7-47 of [IEEE_802_15_4_2020].）
源文档第 90 页
帧控制（Frame Control）字段定义特定的 MAC 头部字段是否存在。此配置取决于 5.9 节中定义的 UWB 消息类型，并在后续章节中进一步规定。
MAC 头部使用具有零长度内容字段的头部终止 IE（Header Termination IE）来终止，如 [IEEE_802_15_4_2020] 标准中所规定。图 46 展示了该 IE 的内容。
载荷 IE（Payload IE）使用具有零长度内容字段的载荷终止 IE（Payload Termination IE）来终止，如 [IEEE_802_15_4_2020] 中所规定。图 47 展示了该 IE 的内容。如果数据载荷不存在，则可省略载荷终止 IE。
终止 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 头部（MAC header）
6.3.1.1.1 帧控制字段应按表 56 所示格式化。
表 56 - 数据帧的帧控制字段（Frame Control Field of Data Frame）
| Field | Size (bits) | Notes |
|---|---|---|
| Frame Type | 3 | 0b001: Data（数据） |
| Security Enabled | 1 | 0b1: 辅助安全头部存在（Auxiliary Security Header is present） |
| Frame Pending | 1 | 0b0: 无针对接收方的挂起帧 0b1: 将有更多帧跟随给接收方 |
| AR | 1 | 0b0: 不需要 ACK 帧 |
| PAN ID Compression | 1 | 1: 目的 PAN ID 字段和源 PAN ID 字段不存在 |
| Reserved | 1 | 0b0 |
| Sequence Number Suppression | 1 | 0b1: 序列号字段不存在 |
| IE Present | 1 | 0b1: 帧中包含头部 IE 和载荷 IE |
| Destination Addressing Mode | 2 | 0b10: 目的地址字段包含短地址 |
| Frame Version | 2 | 0b10: [IEEE_802_15_4_2020] |
| Source Addressing Mode | 2 | 0b00: 源地址字段不存在 |
注：目的地址和源地址应遵循 [IEEE_802_15_4_2020] 中规定的 PAN ID 压缩规则。
表 57 - 多用途帧的帧控制字段（Frame Control Field for Multipurpose frame）
| Field | Size (bits) | Notes |
|---|---|---|
| Frame Type | 3 | 0b101: Multipurpose（多用途） |
| Long Frame Control | 1 | 0b1: Multipurpose long frame（多用途长帧） |
| Destination Addressing Mode | 2 | 0b00: PAN ID 和地址字段不存在 0b10: 地址字段包含短地址（16 位） 0b11: 地址字段包含扩展地址（64 位） |
| Source Addressing Mode | 2 | 0b00: PAN ID 和地址字段不存在 0b10: 地址字段包含短地址（16 位） 0b11: 地址字段包含扩展地址（64 位） |
| PAN ID Present | 1 | 0b0: MHR 中不存在 PAN ID |
| Security Enabled | 1 | 0b0: 帧未受保护 0b1: 帧受 MAC 安全要求保护 |
| Sequence Number Suppression | 1 | 0b0: 序列号字段包含在 MHR 中 0b1: 序列号字段不包含在 MHR 中 |
| Frame Pending | 1 | 0b0: 无待发送的挂起帧 0b1: UWBS 有更多挂起数据或尾随帧 |
| Frame Version | 2 | 0b00 |
| Ack Request | 1 | 0b0: 不需要接收方确认 0b1: 需要接收方确认 |
| IE Present | 1 | 0b0: 帧不包含头部 IE 或载荷 IE 0b1: 帧包含头部 IE 或载荷 IE |
当所使用的帧类型为数据帧时，帧控制目的寻址模式字段应指示使用短地址，且源地址不应存在。
当所使用的帧类型为多用途帧时，在用于竞争接入模式或 OWR 模式（OWR AoA 测量和 DL-TDoA）时，它应包含源地址字段。对于 MAC 数据传输模式，6.3.3.3.6 节定义了源地址字段何时应存在。
当所使用的帧类型为多用途帧时，它可包含目的地址字段。
当多用途帧中不存在目的地址字段时，则应将其视为广播帧。
6.3.1.1.2 目的地址（Destination Address）
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 辅助安全头部（Auxiliary Security Header）字段应按表 58 所示格式化。
表 58 - 辅助安全头部字段格式（Auxiliary Security Header Field Format）
| Field | Size (bits) | Notes |
|---|---|---|
| Security Level | 3 | 0b110 = ENC-MIC-64 |
| Key identifier mode | 2 | 0b00 = 隐式密钥（Implicit key） |
| Frame counter suppression | 1 | 0b1 = 共享全局帧计数器（phyStsIndex） |
| ASN in nonce | 1 | 0b0 = 使用帧计数器生成 nonce |
| Reserved | 1 | 0b0 |
6.3.1.1.4 头部 IE 字段应包含厂商特定头部 IE（Vendor Specific Header IE）。头部 IE 字段的格式请参见 5.9 节。
6.3.1.2 MAC 载荷（MAC payload）
6.3.1.2.1 载荷 IE 字段应包含厂商特定嵌套 IE（Vendor Specific Nested IE）。载荷 IE 字段的格式请参见 5.9 节。
6.3.1.3 MAC 帧尾（MAC footer）
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 基于块的模式要求（Block-based Mode Requirements）
测距块（ranging block）是用于测距的一段时间，由整数个测距轮组成 [IEEE_802_15_4z_2020]。图 48 展示了一个启用轮跳频且具有五个测距轮的示例测距块结构。此示例中的每个测距轮包含 10 个时隙，编号从 0 到 9。
图 48 - 每块五个测距轮且每测距轮十个时隙的示例测距块结构（Example ranging block structure with five ranging rounds per block and ten slots per ranging round）
源文档第 93 页
用于指定测距块、测距轮和时隙持续时间的时间单位是 RSTU。FiRa 设备应实现测距块结构，使得测距块持续时间相对于 PHY 时钟的容差应在 ±100 ppm 以内。图 49 展示了该要求，下文将进一步详细描述：
|(Ti − Ti−1) − Block Duration| < 100ppm * Block Duration，其中 Ti 为块 i 的开始时间。
|(Ti,j − Ti,1) − j ∗ Round Duration| < 100ppm * j * Round Duration，其中 Ti,j 为块 i 的轮 j 的开始时间。
|(Ti,j,k − Ti,j,1) − k ∗ Slot Duration| < 100ppm * k * Slot Duration，其中 Ti,j,k 为块 i 的轮 j 的时隙 k 的开始时间。
图 49 - 测距块与轮同步的时序要求（Timing requirements for Ranging Block and Round synchronization）
源文档第 94 页
上述时序要求适用于必须与块结构同步的 FiRa 设备。当块/轮同步尚未建立时，受控器设备应在第一个测距块中等待至少一个测距持续时间（Ranging Duration），以等待由测距轮的控制器发送的第一条消息。假设 M1 为测距轮的第一条消息，这些 FiRa 设备应从最后接收到的 M1（以下称为用于块/轮同步的帧）导出上述时序。更具体地说：
- FiRa 设备应准备好接收新测距轮的即将到来的消息，其依据是先前测距轮中用于同步的最后一个适用 M1 的开始时间，容差为 +/-100 ppm。
- FiRa 设备应将 M1 前导码的起始作为相应测距时隙的起始，并作为当前测距轮的即将到来的测距时隙的参考时间。
请注意，给定时隙内消息传输的时序精度在 [PHY] 的要求 [PHY-TIM-0050] 中定义。
测距块中测距轮的数量通过以下方式导出：
每块时隙数（Number of Slots per Block）= ⌊(Block Duration / Slot Duration)⌋
测距轮数（Number of Ranging Rounds）= ⌊(Number of Slots per Block / Slots per Ranging Round)⌋
其中 ⌊ ⌋ 表示向下取整函数（floor function）。
在计算每块的测距时隙数和轮数时，适用以下规则：
- 当应用向下取整运算时，未达到所配置时隙持续时间的剩余小数时间持续时间不应被视为一个时隙。因此，不应针对该小数时间递增 STS 索引。
- 不属于测距轮的剩余时隙应被考虑用于递增 STS 索引。
- 剩余时隙和余下的小数时间应被考虑用于测距块持续时间。
图 50 - 考虑块持续时间中小数时间的示例块表示（Example block representation with fractional time considered for the Block Duration）
源文档第 95 页
块持续时间（Block Duration）、时隙持续时间（Slot Duration）和轮持续时间（Round Duration）由应用按表 52 中的规定进行配置。
6.3.2.1 时间调度模式的控制器要求（Time-scheduled mode Controller Requirements）
6.3.2.1.1 控制器应充当发起方或响应方。
6.3.2.1.2 充当发起方的控制器应在控制消息中存在 RDML 时，通过将每个设备的测距角色（Ranging Role）字段设置为 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 当使用 SP1 RFRAME 对非延迟 TWR 执行动态 STS、针对响应方特定子会话密钥的动态 STS、预配置 STS 或针对响应方特定子会话密钥的预配置 STS 生成时，控制器应包含 RCP。
6.3.2.1.4.2 当 STS 配置设置为针对响应方特定子会话密钥的动态 STS，或设置为针对响应方特定子会话密钥的预配置 STS 时，控制器应为发起方。
表 59 - 时隙调度顺序（Order of slot scheduling）
| 顺序（Order） | UWB 消息或 RFRAME | SP 配置：带 SP3 的延迟模式 | SP 配置：不带 RCP 的非延迟模式 | SP 配置：带 RCP 的非延迟模式 | SP 配置：带 SP1 的延迟模式 |
|---|---|---|---|---|---|
| 1 | 控制消息（CM） | SP0 | 未使用 | SP0 包含 CM Type 1 作为 RCM | SP0 包含 CM Type 1 作为 RCM |
| 2 | 测距发起消息（RIM） | SP3 | SP1 包含 CM Type 1 作为 RIM | SP1* | SP1* |
| 3 | 测距响应消息（RRM） | SP3 | SP1 包含 MRM type 2 作为 RRM（在 DS-TWR 模式下 Reply Time 不存在且 Round-Trip Time List 为空） | SP1 包含 MRM type 2 作为 RRM（在 DS-TWR 模式下 Reply Time 不存在且 Round-Trip Time List 为空） | SP1* |
| 4 | 测距终结消息（RFM） | SP3 | SP1 包含 MRM type 1 作为 RFM | SP1 包含 MRM type 1 作为 RFM | SP1* |
| 5 | 测量报告消息（MRM） | SP0 | 未使用 | 未使用 | SP0 包含 MRM type 1 作为 RFM |
| 6 | 测距结果报告消息（RRRM）— 可选消息 | SP0（可选） | SP0（可选） | SP0（可选） | SP0（可选） |
注：SP1* 表示在延迟测距中未包含 DM 载荷 IE 时，SP1 帧应以零 PSDU 大小传输；仅当 SP1 RFRAME 包含 DM 载荷 IE 时，它才应携带消息 ID 0x8 和头部 IE。隐式时隙排序指示相应的测距消息。
6.3.2.1.5 控制器应在每个测距测量周期中发送控制消息。
6.3.2.1.6 当使用 SS-TWR 时，控制器应调度测距发起消息和测距响应消息。
6.3.2.1.7 当使用 DS-TWR 时，控制器应调度测距发起消息、测距响应消息和测距终结消息。
6.3.2.1.8 当 SP3 用于 RFRAME 时，控制器应调度至少一个测距测量报告消息。
6.3.2.1.9 控制器可调度测距结果报告消息。
6.3.2.1.10 控制器应支持轮跳频（Round Hopping）。
6.3.2.1.10.1 如果为会话启用了跳频模式（即测量报告消息中的跳频模式字段在该会话的整个生命周期内设置为 0b1），则控制器应在下一个测距块中使用基于跳频序列的测距轮。
6.3.2.1.11 控制器可支持块跨步（Block Striding）。
6.3.2.1.11.1 如果控制器和受控器支持块跨步，则控制器可将控制消息的跨步长度（Stride Length）字段设置为非零值，以便为受控器跳过测距块。
6.3.2.1.11.2 如果控制器和/或受控器不支持块跨步，则控制器应将控制消息的跨步长度字段设置为 0x00。
6.3.2.1.12 控制器可支持暂停测距（Suspend Ranging）。
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 时间调度模式的受控器要求（Time-scheduled mode Controlee Requirements）
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 发起方要求（Initiator Requirements）
6.3.2.3.1 带 SP3 RFRAME 的 O2O SS-TWR（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 测距（O2M ranging）
6.3.2.3.3.1 发起方应满足 6.3.2.3.1 节中的要求。
6.3.2.3.4 ToF 报告（ToF Report）
6.3.2.3.4.1 发起方应满足 6.3.2.3.1 节中的要求。
6.3.2.3.5 AoA 报告（AoA Report）
6.3.2.3.5.1 发起方应满足 6.3.2.3.1 节中的要求。
6.3.2.4 响应方要求（Responder Requirements）
6.3.2.4.1 带 SP3 RFRAME 的 O2O SS-TWR（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 测距（O2M ranging）
6.3.2.4.3.1 响应方应满足 6.3.2.4.1 节中的要求。
6.3.2.4.4 ToF 报告（ToF Report）
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 报告（AoA Report）
6.3.2.4.5.1 响应方应满足 6.3.2.4.1 节中的要求。
6.3.2.4.5.2 响应方应在所调度的时隙中传输带有 AoA 结果的测距结果报告消息。
6.3.2.4.6 时钟频率补偿（Clock Frequency Compensation）
6.3.2.4.6.1 在 SS-TWR 的情况下，响应方设备应对发起方与响应方之间的 CFO 进行补偿，即 MRM Type 2 和 Type 3 消息中包含的 Reply Time 应对所测量的 CFO 进行补偿。发起方设备不应应用任何 CFO 补偿。
6.3.2.5 竞争接入模式要求（Contention-based Mode Requirements）
6.3.2.5.1 UWB 消息应以帧类型设置为多用途（Multipurpose）进行传输。多用途帧格式应符合 [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 - 竞争接入测距帧控制字段定义（Contention-based ranging Frame Control field definition）
| Bits: | 0-2 | 3 | 4-5 | 6-7 | 8 | 9 | 10 | 11 | 12-13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Field | 帧类型（Frame Type） | 长帧控制（Long Frame Control） | 目的寻址模式（Destination Addressing mode） | 源寻址模式（Source Addressing mode） | PAN ID 存在（PAN ID Present） | 安全使能（Security Enabled） | 序列号抑制（Sequence Number Suppression） | 帧挂起（Frame Pending） | 帧版本（Frame Version） | 确认请求（Ack Request） | IE 存在（IE Present） |
| Value | 0b101 | 0b1 | 0b10 | 0b10 | 0b0 | 0b1 | 0b1 | 0b0 or 0b1 | 0b00 | 0b0 | 0b1 |
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 如果 Reply Time List 中元素的数量使得 MRM Type 1 超过 RFM 测距时隙中的整体 PSDU 大小，则 RFM 的帧挂起位应设置为 '1'，以指示随后的时隙在该测距轮的 RFP 中包含带有 MRM Type 1 消息的 RFM。当帧挂起位设置为 '1' 时，RFP 中随后的测距时隙应包含 MRM Type 1 消息，其带有未出现在当前及先前在该测距轮 RFP 中所传输的 MRM 消息中的设备的 Reply Time List。如果在该测距轮的 RFP 中没有待传输的 Reply Time List，则帧挂起位应设置为 '0'。
6.3.2.5.13.5 MRP 中时隙的数量应与 MRM Type 1 消息的 Reply Time List Length 值相同。
6.3.2.5.13.6 Reply Time List 的第 N 个元素应对应 MRP 的第 N 个测距时隙。
6.3.2.5.13.7 MRM Type 1 消息中的第一个往返时间应对应在 Reply Time List 中最先列出的响应方。
6.3.2.5.13.8 如果响应方的 MAC 地址未在 MRM Type 1 消息的 Reply Time List 中找到，则它不应在 MRP 中响应。
6.3.2.5.13.9 响应方应在 MRP 中使用 RRRM SP0 数据帧。
6.3.2.5.13.10 响应方可在 MRP 中包含附加的载荷 IE，作为厂商特定嵌套 IE。
6.3.2.5.14 源地址和目的地址（Source and Destination Addresses）
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 的 Reply Time Present 字段应设置为 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 控制器应通过将停止测距（Stop Ranging）字段设置为 '1' 来指示测距会话的关闭。
6.3.2.5.22 6.1.1 节中规定的 UWB 受控器信息参数表不应适用。
6.3.2.5.23 Tx offset 特性支持（Tx offset feature support）
6.3.2.5.23.1 控制器/发起方可支持 Tx offset 特性。
6.3.2.5.23.1.1 如果发起方支持 Tx offset 特性，则它应始终在 Allowed Tx Offsets 字段中启用 Tx offset 0。
6.3.2.5.23.2 响应方可支持 Tx offset 特性。
6.3.2.5.23.2.1 如果响应方不支持 Tx offset 特性，则它应在测距时隙的起始处传输其响应消息。
6.3.2.5.24 Tx 抖动窗口特性支持（Tx jitter window feature support）
6.3.2.5.24.1 FiRa 设备可支持 Tx 抖动窗口特性。
6.3.2.5.24.2 如果控制器/发起方启用了 Tx 抖动窗口，而响应方不支持 Tx 抖动窗口特性，则响应方应在测距时隙的起始处传输其响应消息。
6.3.3 数据传输要求（Data Transfer Requirements）
6.3.3.1 通用数据传输要求（Generic data transfer requirements）
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 测距期间数据传输的数据传输要求（Data transfer requirements for data transfer during ranging）
6.3.3.2.1 FiRa 设备可在测距轮中与任何 UWB 消息一起传输 DM 载荷 IE。
6.3.3.2.2 当 DM 载荷 IE 包含在测距消息中时，它应放置在 UWB 消息载荷 IE 之后。
6.3.3.3 专用数据传输的数据传输要求（Data transfer requirements for dedicated data transfer）
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 会话期间的数据传输要求（Data Transfer requirements during HUS session）
6.3.3.3.7.1 为开始数据传输，控制器应在 CFP 的第一个测距时隙中传输 DTPCM，如 5.9.12 节中所定义。
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 专用数据传输会话要求（Dedicated Data Transfer Session Requirements）
6.3.3.3.8.1 为开始专用数据传输，控制器应在时间调度模式的第一个测距时隙中发送 DTPCM，如 5.6.1 节中所定义。
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 受控器应忽略时隙位图（Slot Bitmap）中与超出当前测距轮最后一个时隙的时隙相关联的任何比特。
6.3.3.3.13 如果时隙位图中的某比特被设置为值 0b1，则具有此元素 MAC 地址的 FiRa 设备可在对应于此比特位置的测距时隙中发送其 DM。
6.3.3.3.14 FiRa 设备绝不应在未分配给自己的测距时隙中发送消息。
6.3.3.3.15 当停止数据传输（Stop Data Transfer）字段的值为 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 被分配新时隙位图（接收到进一步的 DTPCM）的 FiRa 设备应使用此新时隙位图替换现有的时隙位图（覆盖）。
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 Requirements）
OWR 消息（UTM、DTM 和 AoA 测量消息）应是使用 6.3.1 节中所定义的 MAC 帧格式的 SP1 多用途 RFRAME。帧控制字段在后续章节中针对每种 OWR 消息类型进行定义。OWR RFRAME 不应包含头部 IE。MHR 和载荷 IE 分别使用头部终止 IE 和载荷终止 IE 终止，如 6.3.1 节中所规定。
以下小节定义了每种 OWR 用例的特定要求。
6.3.4.1 DL-TDoA 要求（DL-TDoA Requirements）
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 锚点要求（DT-Anchor Requirements）
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）的帧控制字段定义（Frame Control field definition for DL-TDoA Messages (DTMs)）
| Bits: | 0-2 | 3 | 4-5 | 6-7 | 8 | 9 | 10 | 11 | 12-13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Field | 帧类型（Frame Type） | 长帧控制（Long Frame Control） | 目的寻址模式（Destination Addressing mode） | 源寻址模式（Source Addressing mode） | PAN ID 存在（PAN ID Present） | 安全使能（Security Enabled） | 序列号抑制（Sequence Number Suppression） | 帧挂起（Frame Pending） | 帧版本（Frame Version） | 确认请求（Ack Request） | IE 存在（IE Present） |
| Value | 0b101 | 0b1 | 0b10 or 0b11 | 0b10 or 0b11 | 0b0 | 0b1 | 0b1 | 0b0 | 0b00 | 0b0 | 0b1 |
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 Timestamp Type 字段被设置为 1（即公共时间基准），则响应方 DT 锚点应包含转换为该测距轮发起方 DT 锚点时间域的 Response DTM 的 TX Timestamp。
6.3.4.1.1.11 响应方 DT 锚点应在由 Poll DTM 中包含的响应方 DT 锚点管理列表（Responder DT-Anchor Management List）字段所分配的测距时隙中传输其 Response DTM。
6.3.4.1.1.12 关于 6.3.4.1.1.11，如果响应方 DT 锚点管理列表字段包含 Ranging Slot Index 字段，则响应方 DT 锚点应在与其 MAC 地址相关联并在 Ranging Slot Index 字段中指定的测距时隙中传输其 Response DTM。
6.3.4.1.1.13 关于 6.3.4.1.1.11，如果响应方 DT 锚点管理列表字段不包含 Ranging Slot Index 字段，则响应方 DT 锚点应基于响应方 DT 锚点管理列表中 MAC 地址的顺序来获取其应传输 Response DTM 的时隙索引。换言之，在响应方 DT 锚点管理列表中具有第 k 个 MAC 地址的响应方 DT 锚点应在测距轮的第 k 个时隙中传输。例如，列表中的第一个响应方 DT 锚点应在测距轮的时隙 1 中传输其 Response DTM。
6.3.4.1.1.14 如果 Poll DTM 中消息控制字段的 DL-TDoA Message Exchange 比特被设置为零（SS-TWR 交换），则发起方 DT 锚点应在其 Poll DTM 的响应方 DT 锚点管理列表中包含 ToF Result 字段。如果到给定响应方 DT 锚点的 ToF 未知，则其对应的 ToF Result 应被设置为无效值 0x0000。请注意，DT 标签可使用 ToF Result 来计算 TDoA 估计。
6.3.4.1.1.15 DT 锚点可在捎带于 Poll DTM、Final DTM 或 Response DTM 的 DM 载荷 IE 内传输 MDSDU。
6.3.4.1.2 引导和簇间同步期间的 DT 锚点要求（DT-Anchor Requirements during Bootstrap and Inter-cluster Synchronization）
6.3.4.1.2.1 在 DL-TDoA 网络中应至少有一个参考 DT 锚点（Reference DT-Anchor）提供公共的测距块结构。
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 如果包含 Hop Count 字段，则由参考 DT 锚点传输的 Poll DTM 中所包含的 Hop Count 字段的值应为零（0x00）。
6.3.4.1.2.5 如果根据 G.2 节中的机制 2 将 Hop Count 字段用于簇间同步，则除参考 DT 锚点之外的所有 DT 锚点最初可将其 Hop Count 设置为值 0xFF，这表明它们尚未与网络的公共块结构对齐，因此无法参与（即发送 DTM）。
6.3.4.1.2.6 根据 G.2 节中的机制 2，如果将 Hop Count 字段用于簇间同步，则 Hop Count 字段应随着将给定发起方 DT 锚点与参考 DT 锚点分隔开的无线通信跳数而单调递增 1。因此，处于参考 DT 锚点通信可达范围内（即邻居）的发起方 DT 锚点应在 Poll DTM 中报告 1 跳的 Hop Count 值。距离参考两跳的发起方 DT 锚点应报告 2 的 Hop Count 值，依此类推。请注意，网络在引导时可能需要一些时间才能稳定到合适的 Hop Count 值。这也可能在网络动态变化（即网络中的变化）下发生。
6.3.4.1.3 DT 标签要求（DT-Tag Requirements）
6.3.4.1.3.1 DT 标签应支持接收和处理 DTM。
6.3.4.1.3.2 DT 标签不应在通过块跳过（Block Skipping）特性所配置的被跳过测距块中侦听 DTM。
6.3.4.1.3.3 DT 标签仅侦听由上层所配置的测距块的活跃测距轮。
6.3.4.2 AoA 测量要求（AoA Measurement Requirements）
对于 OWR AoA 测量测距方法，应使用 AoA 测量消息。
6.3.4.2.1 AoA 测量消息的帧控制字段应具有表 62 中所示的以下字段。
表 62 - AoA 测量消息的帧控制字段（Frame Control field for AoA Measurement Messages）
| Bits: | 0-2 | 3 | 4-5 | 6-7 | 8 | 9 | 10 | 11 | 12-13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Field | 帧类型（Frame Type） | 长帧控制（Long Frame Control） | 目的寻址模式（Destination Addressing mode） | 源寻址模式（Source Addressing mode） | PAN ID 存在（PAN ID Present） | 安全使能（Security Enabled） | 序列号抑制（Sequence Number Suppression） | 帧挂起（Frame Pending） | 帧版本（Frame Version） | 确认请求（Ack Request） | IE 存在（IE Present） |
| Value | 0b101 | 0b1 | 0b10 or 0b11 | 0b10 or 0b11 | 0b0 | 0b1 | 0b0 | 0b0 / 0b1 | 0b00 | 0b0 | 0b1 |
6.3.4.2.2 源地址和目的地址（Source and Destination Addresses）
6.3.4.2.2.1 AoA 测量消息的 MAC 头部中所包含的源地址和目的地址应为短地址模式或扩展地址模式。
6.3.4.2.2.2 目的地址应设置为广播地址。
6.3.4.2.3 序列号字段要求（Sequence Number field requirement）
6.3.4.2.3.1 序列号字段应在每个测距块重置为 '0'。
6.3.4.2.4 帧挂起位要求（Frame Pending bit requirement）
6.3.4.2.4.1 如果 AoA 测量消息的 Number of RFRAMEs 字段为 1，则此 AoA 测量消息的帧挂起位应设置为 0。
6.3.4.2.4.2 如果 AoA 测量消息的 Number of RFRAMEs 字段大于 1，则除最后一个 RFRAME 外，RFRAME 的帧挂起位应设置为 1，最后一个 RFRAME 的帧挂起位应设置为 0。
6.3.4.2.5 头部 IE 和载荷 IE 要求（Header IE and Payload IE requirement）
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 大小。
• 帧开销大小（Frame overhead Size）= MHR + FCS + Header IE + Payload IE Header + 8 octets ENC-MIC-64 + 1 octet Auxiliary
6.3.4.2.5.3.1 MTU = PSDU size - 帧开销大小
6.3.4.2.6 STS 要求
6.3.4.2.6.1 测距块中的所有测距帧（RFRAME）应具有相同的 STS 值，该值应使用静态 STS 生成模式以时隙索引 0 生成。为计算配置摘要（Configuration Digest），SLOT_DURATION 字段应设置为 0x0000。
6.3.4.2.7 用作 Advertiser 或 Observer 的 FiRa 设备应支持 HPRF（高脉冲重复频率）模式。
6.3.4.2.8 用作 Advertiser 或 Observer 的 FiRa 设备可支持 BPRF（基础脉冲重复频率）模式。
6.3.4.2.9 基于 AoA 测量测距方法的 OWR 数据传输
6.3.4.2.9.1 如果 Advertiser 发送未分段的 MDSDU，则应将该 MDSDU 包含在测距轮中第一条 AoA 测量消息的 DM 载荷 IE 中。如果 RFRAME 数量大于 1，则其余 AoA 测量消息不应包含 DM 载荷 IE。
6.3.4.2.9.2 如果 Advertiser 将 MDSDU 分段为多个段（“MDSDU 段”），则应将第一段放在第一条 AoA 测量消息的 DM 载荷 IE 中传输。其余段应依次在随后的 AoA 测量消息中传输。
6.3.4.2.9.3 关于 6.3.4.2.9.2，Advertiser 可发送具有不同大小 MDSDU 段的 AoA 测量消息。
6.3.4.2.10 OWR AoA 测量的时序要求
6.3.4.2.10.1 Advertiser 应在测距块起始处发送 AoA 测量测距轮的第一条 RFRAME。
6.3.4.2.10.2 当 Advertiser 在一条 AoA 测量测距轮中发送多条 RFRAME 时，两条连续 RFRAME 之间的发送间隔应等于表 38 中定义的帧间间隔（Inter-Frame-Interval，即 Advertiser 在 IFI 起始处发送 RFRAME）。
6.3.4.2.10.3 Advertiser 在发送属于同一 AoA 测量测距轮的新 RFRAME 前，应至少等待 IFI_GT_MIN。
6.3.4.2.10.4 Observer 在 IFI_GT_MIN 之后应准备好接收属于同一 AoA 测量测距轮的下一条 RFRAME。
6.3.4.2.10.5 Advertiser 在发送开始下一个测距块的 RFRAME 前，应至少等待 IFI_BGT_MIN。
6.3.4.2.10.6 Observer 在 IFI_BGT_MIN 之后应准备好接收开始下一个测距块的 RFRAME。
6.3.4.2.10.7 Advertiser 应按如下方式设置块时长：
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 - 上行 TDoA 消息（UTM）的帧控制内容字段（Frame Control Content Field for UL-TDoA messages (UTMs)）
| 位 | 0-2 | 3 | 4-5 | 6-7 | 8 | 9 | 10 | 11 | 12-13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 字段 | 帧类型 Frame Type | 长帧控制 Long Frame Control | 目的地址模式 Destination Addressing mode | 源地址模式 Source Addressing mode | PAN ID 存在 PAN ID Present | 安全使能 Security Enabled | 序列号抑制 Sequence Number Suppression | 帧挂起 Frame Pending | 帧版本 Frame Version | 确认请求 Ack Request | IE 存在 IE Present |
| 值 | 0b101 | 0b1 | 0b00 | 0b10 或 0b11 | 0b0 | 0b1 | 0b1 | 0b0 | 0b00 | 0b0 | 0b1 |
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 上行 TDoA 发送间隔应以最小时间粒度（即 1 ms）为单位进行配置。
6.3.4.3.6 UTM 的发送可在指定的上行 TDoA 随机窗口内以随机时间偏移进行。上行 TDoA 随机窗口应小于或等于配置的上行 TDoA 发送间隔。上行 TDoA 随机窗口的值应以 1200 RSTU 为单位。
6.3.4.3.7 UT-Tag 和 UT-同步锚点应分别根据配置的上行 TDoA 发送间隔和上行 TDoA 随机窗口参数发送 Blink UTM 和同步 UTM。
6.3.4.3.8 为简化处理，当支持时，UL-TDoA 设备在 DM 载荷 IE 中传输 MDSDU（例如，搭载在 Blink DTM 或同步 DTM 上）时，应不进行分段。
6.3.5 混合 UWB 调度（HUS）模式要求
本节包含基于混合模式的要求。
6.3.5.1 对于 HUS 会话，应采用 6.3.2 节定义的基于块模式的要求。
6.3.5.2 HUS 测距阶段的时隙时长应为 HUS 会话配置时隙时长的整数倍。HUS 测距阶段内的时隙数量应使用 CM Type 3 的 RRML 中包含的 Slot Index Start、Slot Index End 以及 HUS 会话时隙时长按如下方式计算：
- HUS 测距阶段时长 = （Slot Index End - Slot Index Start + 1）× Slot DurationHUS Session。
- HUS 测距阶段时隙数 = ⌊HUS 测距阶段时长 / Slot DurationHUS Ranging Phase⌋，其中 ⌊ ⌋ 表示向下取整函数。
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 控制器应使用帧挂起位（Frame Pending bit）功能，如 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 帧控制字段（RMM Frame Control fields）
| 位 | 0-2 | 3 | 4-5 | 6-7 | 8 | 9 | 10 | 11 | 12-13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 字段 | 帧类型 Frame Type | 长帧控制 Long Frame Control | 目的地址模式 Dst Addressing mode | 源地址模式 Src Addressing mode | PAN ID 存在 PAN ID Present | 安全使能 Security Enabled | 序列号抑制 Sequence Number Suppression | 帧挂起 Frame Pending | 帧版本 Frame Version | 确认请求 Ack Request | IE 存在 IE Present |
| 值 | 0b101 | 0b1 | 0b00 | 0b10 或 0b11 | 0b0 | 0b0 | 0b1 | 0b0 或 0b1 | 0b00 | 0b0 | 0b1 |
6.3.5.11 HUS 受控器应在 HUS 测距轮的第一个时隙监听 CM Type 3。如果使用帧挂起功能，则 HUS 受控器应准备好接收跨多个时隙分段的 CM Type 3。
6.3.5.12 如果 FiRa 设备的 MAC 地址列在 CM Type 3 中，则该设备应作为 HUS 测距阶段的控制器。
6.3.5.13 HUS 测距阶段的控制器应在该 HUS 测距阶段的第一个时隙中发送与该 HUS 测距阶段中配置的次级会话相对应的控制消息（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 如果启用块跨步（Block striding），则其应作为整个 HUS 测距轮应用于所有 HUS 测距阶段。
6.3.5.18 HUS 控制器和 HUS 受控器应支持 6.4 节指定的 HUS 会话静态 STS 生成方法，但有一个例外：在测距块索引“0”中，phyStsIndexInit 应设置为值 ‘0’，并在此后每个测距时隙递增 phyStsIndex 值，贯穿整个 HUS 会话。
6.3.5.19 参与 HUS 测距阶段的 FiRa 设备应支持 6.4 节指定的静态 STS 生成方法。phyStsIndex 和 CryptoStsIndex 的递增与计算应在 HUS 测距阶段的上下文中进行，遵循 6.4 节的定义。CryptoStsIndex 索引在 HUS 阶段的第一个时隙处重置。
6.3.5.20 参与 HUS 测距阶段的 FiRa 设备可支持 6.4 节指定的动态或预配置 STS 生成方法。phyStsIndex 和 CryptoStsIndex 的递增与计算应在 HUS 测距阶段的上下文中进行，遵循 6.4 节的定义，即对于某个 HUS 次级会话和给定控制器，phyStsIndex 和 CryptoStsIndex 计数器在 HUS 测距阶段结束时停止，并在该 HUS 次级会话和控制器的 HUS 测距阶段再次出现时恢复。如果在 HUS 测距阶段充当控制器的设备未在该阶段的第一个时隙发送相应的控制消息，则该次级会话的 phyStsIndex 和 CryptoStsIndex 计数器不在相应测距块中递增。
6.3.5.22 对于控制消息类型 3，头部 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 停止会话（Stop Session）：指示 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 CM Type 3 的传输应使用头部 IE。供应商 OUI、会话 ID 应保持不变，STS 索引应递增。
6.3.5.30.2 CM Type 3 载荷 IE 应以相同的供应商 OUI、UWB 消息 ID、停止会话、跨步长度（Stride Length）和测距轮索引（Round Index）值传输。
6.3.5.30.3 RRML 大小应包含该时隙中传输的元素数量对应的值。
6.3.5.30.4 如果没有待处理的 RRML 传输，则 FP 位值应设置为 ‘0b0’，表示该测距块中 CM Type 3 传输的结束。
6.4 安全要求（Security Requirements）
本节描述密钥推导与加密过程及其原理。
本节描述动态（Dynamic）、预配置（Provisioned）和静态（Static）STS 的生成。这三种模式之间的选择通过 UCI 完成。
动态 STS 和预配置 STS 在 MAC 层的操作方式类似，主要区别在于会话密钥（Session Key）的提供方式。在动态 STS 模式下，用于生成 STS 的会话密钥由安全元件提供。在预配置 STS 模式下，会话密钥由安全元件提供或通过主机接口（UCI）提供。它们的共同目标是确保：
- 通过确保没有可识别信息以明文传输来保护用户隐私；
- 保护通过 UWB 传输的数据（时间戳、应用载荷）的机密性、完整性和真实性；
- 确保每个时隙都能生成不同的 STS；
- 确保能够检测到重放攻击；
- 允许受控器在单个控制消息上实现与发送方的同步；
- 限制开销以优化链路预算；
- 限制侧信道攻击的风险。
与预配置 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 在密钥推导过程中生成。
图 51 - 动态和预配置 STS 生成模式的密钥推导方案（Key derivation scheme for Dynamic and Provisioned STS generation mode）
源文档第 117 页
为防止侧信道攻击，可定期轮换推导密钥，以确保攻击者只能收集有限数量的样本。轮换或重密钥速率将是初始配置的一部分。它需要在安全性和开销之间权衡。注意，密钥轮换不应过快，否则密钥推导过程本身可能受到攻击。
对于静态 STS 生成模式，目标是确保：
- 通过每轮的每个时隙生成不同的 STS 来确保可靠测距；
- 允许低成本和高性能实现；
- 确保即时重新同步。
对于静态 STS 生成模式，一轮中的每个给定时隙将使用与上一轮和下一轮相同时隙相同的 STS。这确保了快速同步，因为受控器无需知道 phyStsIndex，且允许预先计算 AES 模式。
为实现这一点，cryptoStsIndex 不像动态 STS 生成模式那样是 phyStsIndex 的副本，而是在每轮开始时重置为 0。此外，STS 种子的一部分，即 phyVUpper64，将通过 UCI 设置，而不是作为密钥推导的一部分。
图 52 - 静态 STS 生成模式的密钥推导方案（Key derivation scheme for Static STS generation mode）
源文档第 118 页
6.4.1 密钥生成与管理（Key Generation and Management）
对于密钥推导，CMAC 将用作伪随机函数，AES 用作分组密码。密钥推导的输入数据如下所述，并在图 51 中显示。
- 32 位计数器（Counter）：如果要生成 256 位密钥，则使用两轮 CMAC。第一轮中，计数器值为
0x00000001；第二轮中，计数器值为0x00000002。两轮结果将进行拼接。 - 64 位标签（Label）：描述推导密钥的用途。
- 128 位上下文（Context）：确保密钥生成与当前上下文相关联，例如
cryptoStsIndex和/或为会话商定的配置摘要。 - 32 位长度（Length）：表示推导密钥的长度，即 256 位密钥为
0x00000100，128 位密钥为0x00000080。
该推导数据应作为输入数据提供给以根密钥作为 CMAC 密钥的 CMAC 伪随机函数。CMAC 轮次的输出即为推导密钥。
图 53 - 密钥推导（Key Derivation）
源文档第 120 页
6.4.1.1 密钥推导原语（Key derivation primitives）
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 标签（Label，对密钥用途的描述）应为 64 位长。
6.4.1.1.8 上下文（Context，包含上下文信息的二进制字符串）应为 128 位长。
6.4.1.1.9 密钥的位长度应编码为 32 位。
6.4.1.1.10 推导数据应为计数器、标签、上下文和长度的按顺序拼接。
6.4.1.2 密钥推导标签（Key derivation labels）
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 密钥推导上下文（Key derivation Context）
6.4.1.3.1 第 6.4.1.4 节所述的配置摘要（Configuration digest），在图 51 中也称为 "Config digest"，应按照图 51 所示用作 128 位 Context 字段，以生成 secPrivacyKey、secDataProtectionKey 和 phyStsIndexInit。
6.4.1.3.2 "Config digest" 的最低有效 96 位（lsb）与 32 位 cryptoStsIndex 的拼接应按照图 51 所示用作 128 位 Context 字段，以生成 secDerivedPayloadKey、secDerivedAuthenticationIv 和 secDerivedAuthenticationKey。
6.4.1.3.3 在动态 STS 或预置 STS 模式下，第一次推导时，cryptoStsIndex 的初始值应设置为 phyStsIndexInit。
6.4.1.3.4 在静态 STS 模式下，第一次推导时，cryptoStsIndex 的初始值应设置为 0x00000000。
6.4.1.4 配置摘要（Configuration digest）
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_USAGESTS_CONFIGMULTI_NODE_MODECHANNEL_NUMBERSLOT_DURATION(*)MAC_FCS_TYPERFRAME_CONFIGPREAMBLE_CODE_INDEXSFD_ID（帧起始定界符标识，Start of Frame Delimiter ID）PSDU_DATA_RATEPREAMBLE_DURATION- 常量 =
0x03 SESSION_ID
(*) 以 RSTU 为单位的测距时隙长度按以下公式转换为微秒：
SLOT_DURATION = ⌊(Slot Duration in RSTU × 416) ÷ 499.2⌋
其中 ⌊⌋ 表示向下取整函数。此以微秒为单位的 SLOT_DURATION 用于构成推导数据，如附录 D 所示。
6.4.1.4.5 参数的值应对应于会话 UCI 应用配置命令中发送的值，其位宽如该命令所定义。
6.4.1.5 密钥推导根密钥（Key derivation root key）
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 密钥长度（Key length）
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 密钥轮换（Key rotation）
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 的幂次方，即表示为 2n，其中 n 由表 52 中定义的轮换速率参数设置。
6.4.1.7.8 如果启用了密钥轮换，当 BlockIndex 的第 n 位翻转时应发生密钥轮换。
6.4.1.7.9 （空白）本小节有意留空。
6.4.1.7.10 发生密钥轮换时，应使用密钥轮换时刻的 phyStsIndex 值（即该块的第一个轮次时的值）重新计算 secDerivedPayloadKey、secDerivedAuthenticationIV 和 secDerivedAuthenticationKey。
6.4.1.7.11 发生密钥轮换时，应遵循第 6.4.4.2 节描述的过程。
6.4.2 phyStsIndex 加密（phyStsIndex encryption）
6.4.2.1.1 控制器应使用厂商特定报头 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 位填充字段、会话 ID 和 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 解密（phyStsIndex decryption）
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 索引管理（STS Generation and STS Index Management）
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 计数器达到其最大值（0xFFFFFFFF）时，会话应终止。
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 计数器达到其最大值（0xFFFFFFFF）时，会话应终止。
6.4.4.3 STS 生成 DRBG（The STS Generation DRBG）
6.4.4.3.1 STS 应使用 [IEEE_802_15_4z_2020] 第 15.2.9.1 节规定的确定性随机比特发生器（DRBG）生成。
6.4.4.3.2 参考性文字：从 PHY 个域网信息库（PIB）属性到 [IEEE_802_15_4z_2020] 中 PIB 属性的 DRBG 输入字段映射定义于表 65：
表 65 - DRBG 输入字段到 [IEEE_802_15_4z_2020] PIB 属性的映射（Mapping of DRBG input fields to [IEEE_802_15_4z_2020] PIB attributes）
| PHY 参数 （PHY Parameter） |
IEEE 802.15.4z 参数 （IEEE 802.15.4z Parameter） |
|---|---|
phyStsVCounter[31:0] |
phyHrpUwbStsVCounter[31:0] |
cryptoStsIndex[31:0] |
phyHrpUwbStsVUpper96[31:0] |
phyVUpper64[63:0] |
phyHrpUwbStsVUpper96[95:32] |
secDerivedAuthenticationKey[127:0] |
phyHrpUwbStsKey[127:0] |
该映射如图 54 所示。
图 54 - 映射图（Mapping diagram）
源文档第 127 页
6.4.4.4 DRBG 初始化过程（DRBG Initialization Procedure）
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 参数。如果在 n 次 phyStsIndex 增量后发生密钥轮换，PHY 参数的值将按下表更新。phyStsIndex 的值将在每个时隙后持续更新。
表 66 - 每 2n 个时隙启用密钥轮换的动态 STS 生成模式下，密钥轮换 2n 个时隙后 secDerivedAuthenticationIv 和 phyStsIndexInit 到 DRBG 输入字段的映射（Mapping of secDerivedAuthenticationIv and phyStsIndexInit on DRBG input fields after 2n slots in Dynamic STS generation mode with key rotation enabled every 2n slots）
| PHY 参数 （PHY Parameter） |
初始密钥推导 （Initial key derivation） |
后续密钥推导（2n 次 phyStsIndex 增量后） （Further key derivation） |
|---|---|---|
phyStsVCounter[31:0] |
secDerivedAuthenticationIv0[31:0] & 0x7FFFFFFF |
secDerivedAuthenticationIv2n[31:0] & 0x7FFFFFFF |
cryptoStsIndex[31:0] |
phyStsIndexInit[31:0] & 0x7FFFFFFF |
(phyStsIndexInit[31:0] & 0x7FFFFFFF) + 2n |
phyVUpper64[63:0] |
secDerivedAuthenticationIv0[127:64] |
secDerivedAuthenticationIv2n[127:64] |
6.4.4.5 DRBG 更新过程（DRBG Update Procedure）
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 认证加密（Authenticated encryption）
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）构建 nonce。
6.4.5.1.1.9 CCM 的 nonce 应构造如下：
表 67 - CCM* nonce 映射（Mapping of CCM* nonce）
| Nonce | 参数名称 （Parameter name） |
PHY 参数 （PHY parameter） |
|---|---|---|
Nonce[7:0] |
Nonce 安全级别 （Nonce security level） |
0x06 |
Nonce[39:8] |
帧计数器 （Frame Counter） |
cryptoStsIndex |
Nonce[103:40] |
源地址 （Source Address） |
扩展源地址 （Extended source address） |
6.4.5.1.1.10 如果目的端不知道扩展源地址，则扩展源地址应为左侧补 "0" 的短源地址。
6.4.5.1.1.11 如果在解密过程中认证标签不正确，则应丢弃密文。
6.4.6 使用响应方特定子会话密钥的动态 STS 或预置 STS 的多播操作（Multicast operation with Dynamic STS or Provisioned STS with Responder Specific Sub-session Key）
在使用响应方特定子会话密钥的多播预置 STS 和动态 STS 模式中，每个受控器通过并行的专用子会话参与会话。每个受控器分配一个（子会话密钥，子会话 ID）对。根据消息类型，控制器或受控器使用从会话密钥或子会话密钥推导的密钥来加密 MAC 载荷或生成 STS。
表 68 描述了为配置了使用响应方特定子会话密钥的动态 STS 的延迟 DS-TWR 测距轮推导加密密钥和 STS 生成密钥所使用的材料。
表 68 - 在时间调度模式 TWR 中使用响应方特定子会话密钥的动态（或预置）STS 中的密钥推导材料（Materials for key derivation in Dynamic (or Provisioned) STS with Responder Specific Sub-session Key in the time-scheduled mode TWR）
| UWB 消息 （UWB Message） |
根密钥 （Root Key） |
摘要 ID （ID for Digest） |
|---|---|---|
| CM | UWB 会话密钥 （UWB Session key） |
会话 ID （Session ID） |
| RIM | UWB 会话密钥 （UWB Session key） |
会话 ID （Session ID） |
| RRM（响应方 n） （Responder n） |
子会话密钥(n) （Sub-session Key(n)） |
子会话 ID(n) （Sub-session ID(n)） |
| RFM | UWB 会话密钥 （UWB Session key） |
会话 ID （Session ID） |
| MRM | UWB 会话密钥 （UWB Session key） |
会话 ID （Session ID） |
| RRRM（响应方 n） （Responder n） |
子会话密钥(n) （Sub-session Key(n)） |
子会话 ID(n) （Sub-session ID(n)） |
当响应方发送 RRM 或 RRRM 时，应使用其子会话密钥作为 secSessionKey，使用其子会话 ID 作为摘要，执行如图 51 所述的 KDF。在 RCM 中传输的 STS 索引用作参考，即所有子会话应使用与主会话相同的 STS 索引。