附录 A - 基于块模式 SS-TWR 流程示例(Example of SS-TWR Flow for Block-based Mode)
给出了 O2M SS-TWR(单边双向测距)的示例,其中一个安全测距设备 1(FiRa 设备 1)充当控制器和发起方,而其他 FiRa 设备(FiRa 设备 2 至 FiRa 设备 N)充当受控器和响应方。此处,高脉冲速率(HRP)UWB PPDU SP0 和 HRP UWB PPDU SP3 分别用于数据帧和测距帧(RFRAME),这是经 FiRa 认证的 FiRa 设备的强制选项。本附录中规定的术语在 [IEEE_802_15_4_2020] 和 [IEEE_802_15_4z_2020] 中定义。
图 55 - 基于块模式 SS-TWR 的示例流程(An example flow of the SS-TWR for Block-based Mode)
源文档第 130 页
步骤 1:测距控制阶段(RCP)
- 在 FiRa 设备之间交换 UWB 参数以完成 UWB 设置后,它们使用协商的信道和前导码开启其 UWB 无线电。
- FiRa 设备 1 发送控制消息类型之一(UWB 消息 ID =
0x00)。 - 时隙调度可通过 RDML 字段完成。
步骤 2:测距发起阶段(RIP)
- FiRa 设备 1 在 RIP 中发送第一个测距发起消息(RIM)。
步骤 3:测距响应阶段(RRP)
- 在 RIP 之后,响应方 FiRa 设备在 RRP 中发送测距响应消息(RRM)。
- 测距响应消息的总数与响应方 FiRa 设备的数量相同。
步骤 4:针对发起方 FiRa 设备(FiRa 设备 1)的测量报告阶段(MRP)
- 在 MRP 中,FiRa 设备 1 通过测量报告消息(MRM)类型之一(UWB 消息 ID =
0x10)将 FiRa 设备 1 的应答时间发送给响应方 FiRa 设备。
步骤 5:针对响应方 FiRa 设备(FiRa 设备 2 至 FiRa 设备 N)的 MRP
- 响应方 FiRa 设备基于通过来自 FiRa 设备 1 的测量报告消息所接收的应答时间,计算飞行时间(ToF)作为测距结果。
- 响应方 FiRa 设备可通过测距结果报告消息(RRRM)类型之一(UWB 消息 ID =
0x20)将其自身的测距结果发送给 FiRa 设备 1。 - 测距结果报告消息的总数与响应方 FiRa 设备的数量相同。
附录 B - 基于块模式 DS-TWR 流程示例(Example of DS-TWR Flow for Block-based Mode)
给出了 O2M DS-TWR(双边双向测距)的示例,其中一个安全测距设备 1(FiRa 设备 1)充当控制器和发起方,而其他 FiRa 设备(FiRa 设备 2 至 FiRa 设备 N)充当受控器和响应方。此处,HRP UWB PPDU SP0 和 HRP UWB PPDU SP3 分别用于数据帧和测距帧(RFRAME),这是经 FiRa 认证的 FiRa 设备的强制选项。本附录中规定的术语在 [IEEE_802_15_4_2020] 和 [IEEE_802_15_4z_2020] 中定义。
图 56 - 基于块模式 DS-TWR 的示例流程(An example flow of the DS-TWR for Block-based Mode)
源文档第 132 页
步骤 1:测距控制阶段(RCP)
- 在 FiRa 设备之间交换 UWB 参数以完成 UWB 设置后,它们使用协商的信道和前导码开启其 UWB 无线电。
- FiRa 设备 1 发送控制消息类型之一(UWB 消息 ID =
0x00)。 - 时隙调度可通过 RDML 字段完成。
步骤 2:测距发起阶段(RIP)
- FiRa 设备 1 在 RIP 中发送第一个测距发起消息(RIM)。
步骤 3:测距响应阶段(RRP)
- 在 RIP 之后,响应方 FiRa 设备在 RRP 中发送测距响应消息(RRM)。
- 测距响应消息的总数与响应方 FiRa 设备的数量相同。
步骤 4:针对发起方 FiRa 设备(FiRa 设备 1)的测距终结阶段(RFP)和测量报告阶段(MRP)
- 在 RFP 中,FiRa 设备 1 发送测距终结消息(RFM)。
- 在 MRP 中,FiRa 设备 1 通过测量报告消息(MRM)类型之一(UWB 消息 ID =
0x10)将 FiRa 设备 1 的应答时间和往返时间发送给响应方 FiRa 设备。
步骤 5:针对响应方 FiRa 设备(FiRa 设备 2 至 FiRa 设备 N)的 MRP
- 响应方 FiRa 设备基于通过来自 FiRa 设备 1 的测量报告消息所接收的应答时间和往返时间测量值,计算飞行时间(ToF)作为测距结果。
- 响应方 FiRa 设备可通过测距结果报告消息(RRRM)类型之一(UWB 消息 ID =
0x20)将其自身的测距结果发送给 FiRa 设备 1。 - 测距结果报告消息的总数与响应方 FiRa 设备的数量相同。
附录 C - HRP UWB FiRa 设备完整性检查示例(Example of Integrity Check for HRP UWB FiRa Devices)
本附录提供了针对 HRP UWB FiRa 设备的完整性检查示例,使用户能够构建安全系统。请注意,本附录中介绍的方法为可选示例。由于 HRP UWB FiRa 设备测距安全性的完整性检查取决于具体实现,因此除以下示例外,还可以采用多种方式加以考虑。以下完整性检查可同时应用。
C.1 (留空)
本节有意留空。
C.2 基于前导的完整性检查(Preamble-based Integrity Check)
针对 HRP UWB FiRa 设备的基于前导的完整性检查,是指使用前导以及加扰时间戳序列(STS)进行基于首径检测的测距测量,然后比较两个测距结果。图 57 给出了基于前导的完整性检查的流程图。
图 57 - 基于前导的完整性检查流程图(Flow chart of preamble-based integrity check)
源文档第 135 页
C.3 基于 STS 段的完整性检查(STS Segment-based Integrity Check)
针对 HRP UWB FiRa 设备的基于 STS 段的完整性检查,是指使用多个 STS 段进行基于首径检测的测距测量,然后比较各测距结果。图 58 给出了基于 STS 段的完整性检查的流程图。由于仅在 HRPF 模式下才考虑多个 STS 段,因此该完整性检查可应用于采用 HPRF 模式的 HRP UWB FiRa 设备。
图 58 - 基于 STS 段的完整性检查流程图(Flow chart of STS segment-based integrity check)
源文档第 136 页
C.4 针对 DS-TWR 的完整性检查(Integrity Check for DS-TWR)
针对采用由两次 SS-TWR 测量组成的 DS-TWR 测距方法的 HRP UWB FiRa 设备,其完整性检查可通过测量从 SS-TWR 测量中获得的测距结果,然后比较这两个测距结果来实现。图 59 给出了针对 DS-TWR 的示例性完整性检查的流程图。
图 59 - 针对 DS-TWR 的示例完整性检查流程图(Flow chart of example integrity check for DS-TWR)
源文档第 137 页
附录 D - 密钥推导参考(Key derivation reference)
D.1 静态 STS(Static STS)
本节提供参考值,用于校验静态 STS 密钥推导的实现,遵循图 52 所描述的密钥推导各步骤。
注意,虽然图 52 中未显示,但 CCM* 也覆盖 MHR(包括 Header Vendor IE)以进行认证。
D.1.1 DerivedConfigDigest
本节描述基于下表所配置的 DerivedConfigDigest 的计算。
表 69 - 静态会话配置(Static session configuration)
| 参数(Parameter) | 长度(Length) | 值(Value) |
|---|---|---|
| RANGING_ROUND_USAGE | 1 | 0x02:DS-TWR |
| STS_CONFIG | 1 | 0x00:静态 STS(Static STS) |
| MULTI_NODE_MODE | 1 | 0x00:O2O |
| CHANNEL_NUMBER | 1 | 0x09:信道 9(Channel 9) |
| SLOT_DURATION(*) | 2 | 0x07D0:2000 µs |
| MAC_FCS_TYPE | 1 | 0x00:CRC16 |
| RFRAME_CONFIG | 1 | 0x03:SP3 测距 |
| PREAMBLE_CODE_INDEX | 1 | 0x0A:前导码 ID 10 |
| SFD_ID | 1 | 0x02:SFD ID 2 |
| PSDU_DATA_RATE | 1 | 0x00:6.81 Mbps |
| PREAMBLE_DURATION | 1 | 0x01:64 个符号 |
| Constant | 1 | 0x03:常量 |
| SESSION_ID | 4 | 0x01234567:会话 ID |
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
D.1.2 会话密钥(Session key)
对于静态 STS,会话密钥为常量,在 MAC 规范中定义。
secSessionKey[127:0] = ascii value of "StaticTSStaticTS"
= 0x53746174_69635453_53746174_69635453
D.1.3 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] = 0x00000001Label[63:0] = "DataPrtK" = 0x44617461_5072744BConfiguration digest = 上一步计算的值 = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3Key length[31:0] = 0d128 = 0x00000080
D.1.4 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] = 0x00000001Label[63:0] = "StsIndIn" = 0x53747349_6e64496eConfiguration digest[95:0] = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3Key length[31:0] = 0d128 = 0x00000080
D.1.5 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] = 0x00000001Label[63:0] = "DerAuthI" = 0x44657241_75746849Configuration digest[95:0] = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3cryptoStsIndex[31:0] = 0x00000000Key length[31:0] = 0d128 = 0x00000080
D.1.6 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] = 0x00000001Label[63:0] = "DerAuthK" = 0x44657241_7574684bConfiguration digest[95:0] = 0xa04390cf_8a33f6eb_7e2fc378_87b6b2a3cryptoStsIndex[31:0] = 0x00000000Key length[31:0] = 0d128 = 0x00000080
D.1.7 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] = 0x00000001Label[63:0] = "DerPaylK" = 0x44657250_61796c4bConfiguration digest[95:0] = 0x8a33f6eb_7e2fc378_87b6b2a3cryptoStsIndex[31:0] = 0x00000000Key length[31:0] = 0d128 = 0x00000080
D.1.8 STS(加扰时间戳序列)
通常,STS 并非在每个时隙都发送,例如 slot0 通常用于发送 RCM。但为了参考,此处提供前 4 个时隙的 STS 参考值。
图 60 - STS 生成映射图(STS generation mapping diagram)
源文档第 141 页
StaticStsIv 和 VendorID 通过 UCI 传输
phyVupper64[63:0] = StaticStsIv | VendorID = 0x00010203_0405| 0x0607 = 0x00010203_04050607
每轮开始时: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.8.1 时隙 0 的 STS(STS for slot 0)
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.8.2 时隙 1 的 STS(STS for slot 1)
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.8.3 时隙 2 的 STS(STS for slot 2)
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.8.4 时隙 3 的 STS(STS for slot 3)
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.9 RCM 帧(RCM frame)
给出一个典型的 RCM 帧,其中包含时隙 0 的专有厂商 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
完整 IEEE 数据包(不含 FCS):
0x492ba2aa_261300ff_185a0808_08080808_08086745_230178be_9b0b003f_cba4fd37_d1994488_7c2bec2e_1a998e80_617c44b5_e8e3f335_3ab9f229_1b804bba_e1a92a20_28
D.2 动态 STS 和预配置 STS(128 位密钥,无密钥轮转)
(Dynamic STS and Provisioned STS — 128 bits key, no key rotation)
图 61 - 动态和预配置 STS 生成模式的密钥推导方案(Key derivation scheme for Dynamic and Provisioned STS generation modes)
源文档第 143 页
注意,虽然图 61 中未显示,但 CCM* 也覆盖 MHR(包括 Header Vendor IE)以进行认证。
D.2.1 DerivedConfigDigest
本节描述基于下表所配置的 DerivedConfigDigest 的计算。
表 70 - 动态会话配置(Dynamic session configuration)
| 参数(Parameter) | 长度(Length) | 值(Value) |
|---|---|---|
| RANGING_ROUND_USAGE | 1 | 0x02:DS-TWR |
| STS_CONFIG | 1 | 0x01:动态 STS(Dynamic STS) 0x03:预配置 STS(Provisioned STS) |
| MULTI_NODE_MODE | 1 | 0x00:O2O |
| CHANNEL_NUMBER | 1 | 0x09:信道 9(Channel 9) |
| SLOT_DURATION (*) | 2 | 0x07D0:2000 µs |
| MAC_FCS_TYPE | 1 | 0x00:CRC16 |
| RFRAME_CONFIG | 1 | 0x03:SP3 测距 |
| PREAMBLE_CODE_INDEX | 1 | 0x0A:前导码 ID 10 |
| SFD_ID | 1 | 0x02:SFD ID 2 |
| PSDU_DATA_RATE | 1 | 0x00:6.81 Mbps |
| PREAMBLE_DURATION | 1 | 0x01:64 个符号 |
| Constant | 1 | 0x03:常量 |
| SESSION_ID | 4 | 0x01234567:会话 ID |
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 会话密钥(Session key)
对于动态 STS 和预配置 STS,会话密钥的生成超出了 MAC 规范的范围。在本参考文档中,secSessionKey[127:0] = ascii value of "DynamicSTSNoRot0"。
= 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] = 0x00000001Label[63:0] = "PrivacyK" = 0x50726976_6163794bConfiguration digest[127:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc3Key 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] = 0x00000001Label[63:0] = "DataPrtK" = 0x44617461_5072744BConfiguration digest[127:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc3Key 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] = 0x00000001Label[63:0] = "StsIndIn" = 0x53747349_6e64496eConfiguration digest[127:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc3Key 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] = 0x0001Label[63:0] = "DerAuthI" = 0x4465724175746849Configuration digest[95:0] = 0xfb3b24bf_d2933377_61b88fc3cryptoStsIndex[31:0] = 0x041f3ba0Key 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] = 0x00000001Label[63:0] = "DerAuthK" = 0x446572417574684bConfiguration digest[95:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc30cryptoStsIndex[31:0] = 0x041f3ba0Key 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] = 0x0001Label[63:0] = "DerPaylK" = 0x4465725061796c4bConfiguration digest[95:0] = 0x089366ba_fb3b24bf_d2933377_61b88fc30cryptoStsIndex[31:0] = 0x041f3ba0Key length[31:0] = 0d128 = 0x00000080
D.2.9 STS(加扰时间戳序列)
图 62 - STS 生成映射图(STS generation mapping diagram)
源文档第 147 页
phyVupper64[63:0] = secDerivedAuthenticationIv[127:64] = 0xfa326fed_87d2ef7e
phyStsVCounter[31:0] = secDerivedAuthenticationIv[31:0] & 0x7FFFFFFF = 0x5119a9b8
D.2.9.1 时隙 0 的 STS(STS for slot 0)
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 时隙 1 的 STS(STS for slot 1)
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 时隙 2 的 STS(STS for slot 2)
cryptoStsIndex[31:0] = 0x041f3ba2
phySts
= 0xd50c6c19_376b130b_c963c0d7_c4d0b440_034aec37_faee1fba_882fa38b_302620df_dad0203d_2e332486_58317d45_3c280205_c50e8aa2_b70d38a7_2111186b_ …
D.2.9.4 时隙 3 的 STS(STS for slot 3)
cryptoStsIndex[31:0] = 0x041f3ba3
phySts
= 0xa5a9cc8a_5cc049e9_569eef6c_bffa0e01_88dc9a88_fd31791d_211ae603_98897300_6b9abc62_6941daf6_040cc7ae_7f102de0_40df0ce7_03af84ec_ …
D.2.10 RCM 帧(RCM frame)
给出一个典型的 RCM 帧,其中包含时隙 0 的专有厂商 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
完整 IEEE 数据包(不含 FCS):
0x492ba2aa_261300ff_185a846c_a43c52fb_b02b56a9_879db04e_4e03003f_8276e044_f378abbe_d239867e_d2fe5c9d_cd131d1f_6338f1f7_9db18471_727a10fc_80047edb_0f
D.3 动态 STS 和预配置 STS(256 位密钥,无密钥轮转)
(Dynamic STS and Provisioned STS — 256 bits key, no key rotation)
D.3.1 DerivedConfigDigest
同第 D.2.1 节。
D.3.2 会话密钥(Session key)
对于动态 STS 和预配置 STS,会话密钥的生成超出了 MAC 规范的范围。在本参考文档中,secSessionKey[255:0] = ascii value of "DynamicSTSNoRot0DynamicSTSNoRot0"。
= 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] = 0x00000001Label[63:0] = "PrivacyK" = 0x50726976_6163794BConfiguration digest[127:0] = 0x089366BA_FB3B24BF_D2933377_61B88FC3Key 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]- 第一轮(First round):
Counter [31:0] = 0x00000001 - 第二轮(Second round):
Counter[31:0] = 0x00000002 - 以此类推(Etc.)
- 第一轮(First round):
Label[63:0] = "DataPrtK" = 0x44617461_5072744BConfiguration digest[127:0] = 0x089366BA_FB3B24BF_D2933377_61B88FC3Key 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] = 0x00000001Label[63:0] = "StsIndIn" = 0x53747349_6E64496EConfiguration digest[127:0] = 0x089366BA_FB3B24BF_D2933377_61B88FC3Key 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] = 0x00000001Label[63:0] = "DerAuthI" = 0x4465724175746849Configuration digest[95:0] = 0xFB3B24BF_D2933377_61B88FC3cryptoStsIndex[31:0] = 0x1369DBEEKey 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] = 0x00000001Label[63:0] = "DerAuthK" = 0x446572417574684BConfiguration digest[95:0] = 0xFB3B24BF_D2933377_61B88FC3cryptoStsIndex[31:0] = 0x1369DBEEKey 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] = 0x0001Label[63:0] = "DerPaylK" = 0x4465725061796C4BConfiguration digest[95:0] = 0xFB3B24BF_D2933377_61B88FC3cryptoStsIndex[31:0] = 0x1369DBEEKey length[31:0] = 0d128 = 0x00000080
D.3.9 STS(加扰时间戳序列)
请参阅第 D.2.9 节和图 55 了解 STS 生成示意图。
phyVupper64[63:0] = secDerivedAuthenticationIv[127:64] = 0xE2D7DAB2_D95DF4DD
phyStsVCounter[31:0] = secDerivedAuthenticationIv[31:0] & 0x7FFFFFFF = 0x0C80DF3A
D.3.9.1 时隙 0 的 STS(STS for slot 0)
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 时隙 1 的 STS(STS for slot 1)
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 时隙 2 的 STS(STS for slot 2)
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 时隙 3 的 STS(STS for slot 3)
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 帧(RCM Frame)
给出一个典型的 RCM 帧,其中包含时隙 0 的专有厂商 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
完整 IEEE 数据包(不含 FCS):
0x492BA2AA_261300FF_185AC147_37EE8DCA_F41F31D6_21059CE5_D23C003F_34D57E6F_7F30AB15_8CD700EA_C152590D_E0078BF8_1B4067E7_76587BC1_DCA836FA_D4518592_83
附录 E - AoA 方位角和俯仰角测量范围(AoA Azimuth and Elevation measurement scope)
E.1 三维平面上的到达角确定参考(Angle of Arrival determination reference on a 3D plane)
图 63 - 三维平面上的到达角确定参考(Angle of Arrival determination reference on a 3D plane)
源文档第 154 页
- 方位角和俯仰角测量始终相对于测量设备,而非相对于天线。
- 如果设备旋转,参考轴也随之旋转。
- Y 轴是手机的垂直显示轴。
- X 轴是手机的水平显示轴。
- Z 轴是正交于手机显示屏的轴(后置摄像头视角方向)。
E.2 AoA 俯仰角(AoA Elevation)
AoA 俯仰角是 XZ 平面与入射信号之间的相对夹角。
E.2.1 发起方处的测量(Measurement at the Initiator)
发起方侧的厂商实现可以测量在 RRM(测距响应消息)上完成的俯仰角和 FoM(品质因数),并将其作为 UCI 通知消息的一部分发送。
E.2.2 响应方处的测量(Measurement at the Responder)
响应方侧的厂商实现可以测量在 RIM(测距发起消息)上完成的俯仰角和 FoM,并将其作为 RRRM(测距结果报告消息)的一部分发送。
E.3 AoA 方位角(AoA Azimuth)
AoA 方位角是 Z 轴与投影到 XZ 平面上的入射信号之间的相对夹角。在 Z 轴上为 0,朝 X 轴顺时针方向为正,朝 X 轴逆时针方向为负。
E.3.1 发起方处的测量(Measurement at the Initiator)
发起方侧的厂商实现可以测量 RRM 上的方位角和 FoM,并将其作为 UCI 通知消息的一部分发送。
E.3.2 响应方处的测量(Measurement at the Responder)
响应方侧的厂商实现可以测量在 RIM 上完成的方位角和 FoM,并将其作为 RRRM 的一部分发送。
附录 F - 允许的操作参数集对(Allowed operating parameter set pairs)
[PHY] 规定,SFD# 或 SYNC PSR 在测距轮期间不宜改变。因此,可使用的操作参数集数量有限。表 71 列出了针对带数据和不带数据的延迟模式 RFRAME(测距帧)以及非延迟模式的这些集对。注意,在一个测距轮期间仅使用 SP0 和 SP3 或者 SP0 和 SP1。集合在 [PHY] 的表 2(针对 BPRF)和表 3(针对 HPRF)中定义。注意,集合 32、33、34 和 35 是 FiRa 专用的。
表 71 - 允许的操作参数集对(Allowed operating parameter set pairs)
| SP0 | 带数据的延迟模式 RFRAME(Deferred mode RFRAME with Data) | 不带数据的延迟模式 RFRAME(Deferred mode RFRAME without Data) | 非延迟模式(Non-deferred mode) | |
|---|---|---|---|---|
| SP1 | SP3 | SP1 | ||
| BPRF | 1 | 5 | 6 | 5 |
| 2 | 3 | 4 | 3 | |
| HPRF | 1 | 5 | 22 | 5 |
| 1 | 6 | 23 | 6 | |
| 1 | 7 | 24 | 7 | |
| 1 | 12 | 25 | 12 | |
| 1 | 13 | 35 | 13 | |
| 2 | 8 | 26 | 8 | |
| 2 | 9 | 27 | 9 | |
| 2 | 10 | 28 | 10 | |
| 2 | 11 | 29 | 11 | |
| 3 | 14 | 26 | 14 | |
| 3 | 15 | 27 | 15 | |
| 3 | 16 | 28 | 16 | |
| 3 | 17 | 29 | 17 | |
| 4 | 18 | 30 | 18 | |
| 4 | 19 | 31 | 19 | |
| 32 | 33 | 20 | 33 | |
| 32 | 34 | 21 | 34 |
附录 G - DL-TDoA 簇间同步(DL-TDoA Inter-cluster Synchronization)
本资料性附录描述了一种 DL-TDoA 簇间同步方法,它为 DL-TDoA 网络中的 DT 锚点(DT-Anchor)提供了一种手段,用以对齐其测距块结构并协调对共享介质的访问,从而避免簇间干扰。
DL-TDoA 网络的公共测距块结构由参考 DT 锚点(Reference DT-Anchor)生成,参考 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 锚点厂商提供了更大的灵活性来实现 DT 锚点与公共测距块结构同步的方式,而无需在 DTM(DL-TDoA 消息)中增加任何额外字段。机制 1 可适用于简单的 DL-TDoA 网络,其中各簇例如沿一个方向排成一行部署,使得发起方 DT 锚点仅有少数几个它能听到的相邻发起方 DT 锚点(例如,两侧各两个),如图 64 所示。
图 64 - 机制 1 适用的示例 DL-TDoA 拓扑示意图。标记为 4 的发起方 DT 锚点(锚点 4)只能听到锚点 3 和锚点 5,因此它仅使用来自锚点 3 和锚点 5 的 Poll DTM 进行簇间同步(Illustration of an example DL-TDoA topology for which Mechanism 1 is suitable. The Initiator DT-Anchor marked with 4 (Anchor 4) can only hear Anchor 3 and Anchor 5 so that it only uses the Poll DTMs from Anchor 3 and Anchor 5 for inter-cluster synchronization)
源文档第 157 页
- 机制 2(G.2 节)提供了另一种算法,使 DT 锚点能够形成以参考 DT 锚点为根的时间同步树状结构。为此,发起方 DT 锚点必须适当计算其与参考 DT 锚点之间的无线通信跳数(Hop Count),并在其 Poll DTM 中包含 Hop Count 字段。机制 2 可适用于复杂的 DL-TDoA 网络,其中一个 DT 锚点周围环绕着多个簇,选择其中一个或多个进行同步是有益的。
对于这两种机制,DL-TDoA 网络中的 DT 锚点都配置了与测距块结构相关的相同参数(即 Slot Duration(时隙时长)、Round Duration(轮时长)和 Block Duration(块时长))。此外,假设 DL-TDoA 服务提供者在 DT 锚点启动 DL-TDoA 会话之前,已经为每个 DT 锚点设置了特定的角色和运行的测距轮。
G.1 机制 1(Poll DTM 中不含 Hop Count 字段的簇间同步算法)(Mechanism 1 (Inter-cluster synchronization algorithm without Hop Count field in Poll DTMs))
本节描述了一个实现示例,它能满足 6.3.4.1.2 节中规定的与引导和簇间同步相关的要求。
前提条件:DT 锚点已上电并启动 DL-TDoA 会话,但尚未开始发送 DTM。存在一个参考 DT 锚点。分配给参考 DT 锚点的测距轮的 Round Index(轮索引)为 k(0<=k<N,其中 N 是一个测距块中的测距轮数量)。所有 DT 锚点持续侦听 Poll DTM。
- 步骤 1(测距块的初始化):参考 DT 锚点基于其本地时钟,在第 (k+1) 个测距轮的第一个测距时隙中开始发送 Poll DTM。测距块的第一个测距时隙由参考 DT 锚点确定。通过发送第一个 Poll DTM,参考 DT 锚点生成了网络中所有 DT 锚点所依赖的测距块。
图 65 - 步骤 1 示意图。假设参考 DT 锚点被配置为在第 (k+1) 个测距轮中运行。参考 DT 锚点在第 (k+1) 个测距轮的第一个测距时隙中发送其第一个 Poll DTM(Illustration of step 1. Assume that the Reference DT-Anchor is configured to operate in (k+1)th ranging round. The Reference DT-Anchor transmits its first Poll DTM in the first ranging slot of the (k+1)th ranging round.)
源文档第 158 页
- 步骤 2(参考 DT 锚点的簇开始工作):与参考 DT 锚点同簇的响应方 DT 锚点通过接收来自参考 DT 锚点的 Poll DTM 开始运行。响应方 DT 锚点在由 Poll DTM 分配的测距时隙中发送 Response DTM。该同步行为类似于 TWR(双向测距)情况下控制器和受控器的行为。此时,参考 DT 锚点的簇正在运行。此外,任何能够接收到来自参考 DT 锚点的第一个 Poll DTM 的 DT 锚点都可以与公共测距块同步,并准备从下一个测距块开始在适当的时间发送其 DTM。
图 66 - 步骤 2 示意图。与参考 DT 锚点同簇的响应方 DT 锚点在接收到来自参考 DT 锚点的第一个 Poll DTM 之后开始发送其 Response DTM(Illustration of step 2. The Responder DT-Anchors in the same cluster as the Reference DT-Anchor start transmitting their Response DTM after receiving the first Poll DTM from the Reference DT-Anchor)
源文档第 158 页
- 步骤 3(参考 DT 锚点的相邻簇开始工作):除参考 DT 锚点之外的发起方 DT 锚点尝试侦听来自运行在不同测距轮上的相邻发起方 DT 锚点的 Poll DTM。最初,参考 DT 锚点是网络上唯一运行的发起方 DT 锚点,因此连接到(换言之,侦听到其 Poll DTM)参考 DT 锚点的发起方 DT 锚点可以在使用来自参考发起方 DT 锚点的第一个 Poll DTM 与参考 DT 锚点的测距块对齐之后开始发送其 Poll DTM。此时,连接到参考 DT 锚点的发起方 DT 锚点所在的簇正在运行。在此,如果某个簇中的发起方 DT 锚点能够侦听到来自参考 DT 锚点的大部分 Poll DTM,则认为该簇已连接到参考 DT 锚点。
图 67 - 步骤 3 示意图。能够侦听到来自参考 DT 锚点的 Poll DTM 的发起方 DT 锚点从下一个测距块(即 Block Index 为 1 的测距块)开始发送其 Poll DTM(Illustration of step 3. The Initiator DT-Anchors that can listen to the Poll DTM from the Reference DT-Anchor start transmitting their Poll DTMs from the next ranging block (i.e., ranging block with Block Index 1).)
源文档第 159 页
- 步骤 4(未直接连接到参考 DT 锚点的簇开始工作):随着 DL-TDoA 网络中的发起方 DT 锚点反复执行步骤 3,那些未直接连接到参考 DT 锚点(但通过一个或多个其他发起方 DT 锚点连接到参考 DT 锚点)的簇将能够工作。
图 68 - 步骤 4 示意图。无法侦听到来自参考 DT 锚点的 Poll DTM 的发起方 DT 锚点,在从已与参考 DT 锚点同步的相邻发起方 DT 锚点接收到任意 Poll DTM 之后开始发送其 Poll DTM(Illustration of step 4. The Initiator DT-Anchors that cannot listen to the Poll DTM from the Reference DT-Anchor start transmitting their Poll DTMs after receiving any Poll DTM from their neighbor Initiator DT-Anchors which have been synchronized to the Reference DT-Anchor.)
源文档第 159 页
- 步骤 5(运行时块对齐):发起方 DT 锚点可以使用接收到的 DTM 来调整其可能因时钟漂移而抖动的块结构。例如,通过侦听上一个测距块中的所有 DTM,发起方 DT 锚点可以基于接收到的 DTM 中所含的 TX 时间戳以及这些 DTM 的 RX 时间戳来确定其在下一个测距块中的 Poll DTM 的发送时间。
图 69 - 步骤 5 示意图。在开始发送 Poll DTM 之后,发起方 DT 锚点可以基于其在上一测距块中接收到的 Poll DTM 的 Rx 时间戳来调整其 Poll DTM 的发送时间
源文档第 160 页
如图 69 所示,第 4 测距轮的发起方 DT 锚点(称为第 4 发起方 DT 锚点)可以基于在上一测距块(即 Block Index n-1)中接收到的 Poll DTM 的 RX 时间戳来调整第 (n+1) 个测距块(即 Block Index n)中 Poll DTM 的发送时间。假设第 4 发起方 DT 锚点接收到了来自第 2、第 3、第 5 和第 N 发起方 DT 锚点的 Poll DTM,它们的 RX 时间戳分别为 tRx(2, n)、tRx(3, n)、tRx(5, n) 和 tRx(N, n)。那么,第 4 发起方 DT 锚点在第 (n+1) 个测距块中 Poll DTM 的发送时间可被确定为 tRx(2, n)、tRx(3, n)、tRx(5, n)、tRx(N, n) 和 Round Duration 的函数的输出。
注意,用于调整 Poll DTM 的 TX 时间戳的计算函数的细节(例如,使用多少个 RX 时间戳、每个赋予多大权重、以及使用多少个近期测距块来收集 RX 时间戳)是具体实现相关的。
当新的发起方 DT 锚点加入 DL-TDoA 网络时,该发起方 DT 锚点在一定时间内(例如,Block Duration)接收来自其他发起方 DT 锚点的 Poll DTM,并基于这些接收到的 Poll DTM 的 RX 时间戳,通过与步骤 5 类似的操作,开始在其测距轮中发送 Poll DTM。
当某个发起方 DT 锚点因某种问题停止运行时,与该故障发起方 DT 锚点同簇的响应方 DT 锚点由于缺少 Poll DTM 而无法发送其 Response DTM。
G.2 机制 2(基于 Hop Count 的簇间同步树构建)(Mechanism 2 (Inter-cluster Synchronization Tree Construction based on the Hop Count))
该机制构建一个时间同步树状结构,使每个发起方 DT 锚点与参考 DT 锚点(树的根)之间的代价度量(Cost Metric)1(即 Hop Count)最小化。为此,机制 2 在 Poll DTM 中包含了额外信息(Hop Count 字段)。与机制 1 相比,该机制对被选择用于同步和对齐到公共块结构的发起方 DT 锚点施加了一些限制。换句话说,使用该机制时,DT 锚点只能与代价度量低于其本地代价度量的发起方 DT 锚点同步。
Hop Count 反映了每个 DT 锚点与参考 DT 锚点同步的路径代价,其度量方式是 DT 锚点与参考 DT 锚点之间的无线通信跳数。代价度量在整个网络中单调递增。参考 DT 锚点具有最低的度量 hreference = 0,而其他 DT 锚点最初将其代价度量设置为最大值 h=0xFF,表示它们尚未对齐到公共时间基准且与网络断开(图 4a)。使用 Hop Count 作为路径代价度量有利于简单性,但会导致为时间同步选择更长、可能更不可靠的链路。厂商在树中选择时间同步父节点时可以引入额外的约束,例如,丢弃或降低较差或不可靠无线链路的权重。
树的形成始于参考 DT 锚点发起其 DL-TDoA 测距会话,并在其作为发起方参与的活跃测距轮中发送其包含 Hop Count 字段(hreference = 0)的第一个 Poll DTM。通信范围内的活跃 DT 锚点接收这些 Poll DTM,选择参考 DT 锚点作为其父节点,将其度量设置为 h = hreference + 1 = 1,并对齐到公共块结构(在 G.3 节中进一步说明)。一旦对齐,这些 DT 锚点就可以开始参与其活跃测距轮,发送其 Poll DTM(包含其本地 Hop Count 字段),并使距根更远的 DT 锚点能够加入网络。经过几个块之后,这应当有助于每个活跃 DT 锚点在树中选择一个父节点(或一组父节点),并在参考 DT 锚点最初设置的公共块结构上运行。G.2.1 节通过一个示例网络拓扑说明了引导时的树形成。
为了选择父节点,DT 锚点通常可以将其本地代价度量值 hlocal 与所接收到其 Poll DTM 的发起方 DT 锚点的值(hsender)进行比较。如果 hsender + 1 < hlocal,则 DT 锚点可以选择发送方发起方作为其新父节点或时间源,将本地度量设置为 hlocal = hsender + 1。在这种情况下,DT 锚点可以与所选父节点同步并对齐到其块结构。每当 DT 锚点从所选父节点接收到一个 Poll DTM 时,它可以重新同步以减少同步误差和轻微的块失配。如果 hsender + 1 = hlocal,则发送方发起方 DT 锚点距参考 DT 锚点的跳数与当前所选父节点相同。在这种情况下,选择发送方发起方 DT 锚点在同步方面可能不会带来多大好处,DT 锚点可以保留其当前所选的父节点。或者,它可以把该发起方 DT 锚点添加到一组所选父节点中,用于改善同步。最后,如果 hsender + 1 > hlocal,这意味着发送方比接收 DT 锚点距参考 DT 锚点更远,因此接收到的 Poll DTM 可出于同步目的而被丢弃。
为了增强该机制的健壮性,DT 锚点可能不仅考虑一个父节点,而是考虑一组具有相同代价度量的父节点。这意味着,例如,如果一个代价度量 h = 3 的发起方 DT 锚点具有三个度量同为 h = 2 的父节点,它可以存储来自这三个父节点的信息,并使用它们的聚合信息来改善其同步性能以及与块结构的对齐。然而,DT 锚点可能不会直接利用代价度量高于或等于其当前值的锚点,因为这些锚点距参考 DT 锚点更远,因此可能遭受更高的时钟同步误差。
为了应对网络变化,DT 锚点可以移除或丢弃过时的父节点,例如,在几个块内未从其接收到 Poll DTM 的父节点。移除这些父节点后,DT 锚点重新计算其度量并选择另一个父节点,以保持与公共块结构的对齐并能够参与其活跃测距轮。G.2.2 节举例说明了链路故障后树结构可如何调整。
G.2.1 簇间同步树形成示例(Example Inter-Cluster Synchronization Tree Formation)
本节说明了在示例网络拓扑中,DT 锚点如何在 DL-TDoA 会话开始时使用代价度量形成同步树。
图 70a 显示了初始的 DL-TDoA 网络状态。由于 DT 锚点既不知道可用的无线链路,也不知道将由参考 DT 锚点设置的公共测距块结构的时序,因此 DL-TDoA 网络是断开的。结果是,DT 锚点尚不能参与其活跃测距轮,只能持续侦听 Poll DTM 以进行同步。在此状态下,普通 DT 锚点将其代价度量或 Hop Count 设置为最大值 0xFF,而参考 DT 锚点将其度量设置为 0。
一旦参考 DT 锚点的 DL-TDoA 测距会话开始(图 70 中的节点 #1),参考 DT 锚点就可以在其以发起方角色参与的活跃测距轮中开始发送包含 Hop Count 字段(hreference = 0)的 Poll DTM,使通信范围内的活跃 DT 锚点能够加入网络。注意,参考 DT 锚点也可以作为响应方参与其他测距轮——为简化起见此处未示出。接收到来自参考 DT 锚点的 Poll DTM 的 DT 锚点可以直接选择参考 DT 锚点作为其时间源,并将其 Hop Count 更新为 h = hreference + 1 = 1,表示它们距参考 DT 锚点一个同步跳。该行为如图 70b 所示,其中节点 #2 接收到来自 #1 的 Poll DTM,选择 #1 作为其父节点,加入网络,并对齐到由参考 DT 锚点(#1)设置的公共块结构。
树的构建在图 70c 中继续,其中节点 #2 在其被配置为发起方 DT 锚点的活跃测距轮中发送 Poll DTM。注意,取决于实现以及通过设置每个 DT 锚点的活跃测距轮所配置的调度,#2 可以在其接收到来自 #1 的 Poll DTM(图 70b)的同一个块索引中或在下一个块中发送其 Poll DTM。在图 70c 中,节点 #1、#3 和 #4 接收到来自 #2 的 Poll DTM。参考 DT 锚点(#1)可以安全地丢弃该 Poll DTM 以用于簇间同步目的,因为它是树的根,因此其度量 h1 < h2。而 #3 和 #4 可以选择 #2 作为其父节点,因为 h2 + 1 = 2 < 0xFF(初始度量)。结果是,它们将其度量设置为 h3 = h4 = 2,基于从 #2 获得的信息与公共块结构对齐,并开始参与其配置的测距轮,如图 70d 和图 70e 所示。
图 70 - 使用机制 2 代价度量的 DL-TDoA 时间同步树状形成的简化示例。蓝色圆圈表示在至少一个测距轮中担任发起方 DT 锚点角色的 DT 锚点,灰色圆圈表示仅作为响应方 DT 锚点参与的 DT 锚点(Simplified example of the DL-TDoA time synchronization tree-like formation using the cost metric with Mechanism 2. Blue circles denote DT-Anchors that take the Initiator DT-Anchor role in at least one ranging round, while grey circles represent DT-Anchors that solely participate as Responder DT-Anchors.)
源文档第 163 页
在图 70d 中,节点 #4 在加入网络后发送其自己的 Poll DTM。该 Poll DTM 可能被 #2、#3 和 #5 接收。在这种特定情况下,#2 可以安全地丢弃来自 #4 的 Poll DTM 以用于簇间同步,因为 h2 < h4。类似地,#3 观察到选择 #4 作为其父节点没有实际好处,于是保留 #2 作为其时间源,#2 提供更低的代价度量或跳数。不过,#3 可以存储来自 #4 的信息作为同步的备用父节点。相反,当 #5 接收到来自 #4 的 Poll DTM 时,它在同步树中选择 #4 作为其父节点,加入网络,对齐到公共块结构,并将其 Hop Count 设置为 h5 = h4 + 1 = 3。
在图 70e 中,节点 #3 发送一个可能被 #2、#4 和 #5 接收的 Poll DTM。节点 #2 可以丢弃该 Poll DTM 以用于同步。#4 的行为与图 70d 中的 #3 相同,最后 #5 观察到选择 #3 作为父节点产生与选择 #4 相同的代价 h5 = h3 + 1 = 3 跳。在这种情况下,#5 可以决定保留 #4 作为其父节点,选择 #3 作为其新的首选父节点,或者以某种方式同时使用两个父节点来改善同步性能。为做出这一决定,厂商可以使用此处未规定的额外逻辑。注意,为了增加稳定性,节点可能不会更改父节点,除非它们能从中获得实际好处(例如,减少跳数、提高可靠性或修正度量不一致)。然而,厂商也可以考虑对所选父节点进行老化处理,以避免 DT 锚点固守可能不再提供可靠或一致 Hop Count 值的旧链路。
最后,在图 70f 中,#5 发送一个 Poll DTM。由于 h5 大于所有接收节点(#3 和 #4)的度量,这些节点可以丢弃来自 #5 的 Poll DTM 以用于簇间同步目的。
在图 70f 之后,树状结构已形成,节点可以基于从其所选父节点接收到的 Poll DTM 周期性地(例如,在每个块中)重新同步。
注意,在此示例中,仅作为响应方 DT 锚点运行的 DT 锚点(在图 70 中以灰色圆圈表示)也可以使用从 Poll DTM 接收到的 Hop Count 字段,以上面针对发起方 DT 锚点所述的相同方式选择首选父节点/时间源(或一组父节点/时间源)来遵循调度。然而,仅作为响应方运行的 DT 锚点不发送 Poll DTM,因此不能成为其他 DT 锚点的父节点或时间源。
G.2.2 对 DL-TDoA 网络变化的适应(Adaptation to DL-TDoA Network Changes)
无线链路是动态的,节点可能被移动、发生故障、添加到网络或被移除。这会造成网络拓扑的变化,需要机制 2 调整所构建的树状结构。图 71 基于前面的示例说明了该机制如何应对链路故障。
在图 71a 中,4—2 之间的链路消失,使 #4 失去了重新同步到最初由参考 DT 锚点(#1)设置的 DL-TDoA 网络公共块结构的可能性。过一段时间后,节点 #4 可能意识到其到 #2 的链路不再存在,因此决定移除或丢弃 #2 作为父节点。例如,如果 #4 在几个块内无法听到 #2,就可能发生这种情况。何时丢弃父节点的决定是厂商和具体实现相关的,因为它可能取决于例如 DT 锚点在不接收所选父节点消息的情况下保持其时钟与网络同步的能力。一旦 #4 决定丢弃 #2 作为其父节点,#4 有几个选项来应对网络变化:
- 节点 #4 可以使用备用父节点(如果可用),例如本例中的节点 #3,如图 71b 所示将其度量更新为 h4 = h3 + 1 = 3。然而,这将在树中造成不一致,因为 #5 先前已选择 #4 作为其父节点,而此时两个节点都有 h4 = h5 = 3。节点 #5 可以在下一次接收到来自 #4 的 Poll DTM 时通过检查 h4 < h5 不再成立来检测该不一致,从而不再将 #4 视为父节点,并选择另一个具有更好度量(#3)的可达节点作为首选父节点。这一最终变化反映在图 71c 中。
- 或者,节点 #4 可以断开与网络的连接,将其度量设置为 0xFF 一段时间(具体实现相关),并重启其 UWBS 接收机以持续侦听 Poll DTM,从而重新对齐到公共块结构(见 G.3 节)。然后 #4 可能接收到来自 #3 和 #5 的 Poll DTM,最终达到与图 71c 相同的网络状态。取决于 #4 保持断开的时间以及 #5 需要多长时间才认为其到 #4 的链路已过时,网络也可能经过一个不一致状态(图 71b),或更直接地到达最终状态(图 71c)。
图 71 - DL-TDoA 簇间同步树对网络变化的适应示例(Example DL-TDoA Inter-cluster Synchronization tree adaptation to network changes.)
源文档第 165 页
G.3 用于簇间同步的 UWBS 行为示例(Example UWBS Behavior for Inter-cluster Synchronization)
本节详细说明 DT 锚点如何操作其 UWBS 无线电以加入 DL-TDoA 网络,基于所选的簇间同步机制与公共块结构对齐,并在配置的活跃测距轮中参与(发送 DTM)。注意,本节仅说明一种可能的 UWBS 行为,厂商可以自由地进一步优化其 UWBS 的运行方式,例如,以降低功耗或改善同步性能。
当 DT 锚点的 DL-TDoA 测距会话开始时,DT 锚点最初打开其接收机,如图 72 所示侦听来自发起方 DT 锚点的、可能包含簇间同步信息的 Poll DTM。注意,DL-TDoA 使用静态 STS(加扰时间戳序列)机制。因此,尚未同步的 DT 锚点只能侦听并成功接收在测距轮第一个测距时隙中发送的、cryptoStsIndex 设置为零的 Poll DTM。DT 锚点持续此行为直到成功接收到一个 Poll DTM,使其能够将其块结构与由参考 DT 锚点建立的 DL-TDoA 网络块结构进行首次对齐。如果选择了机制 2(G.2 节),这也使 DT 锚点能够选择第一个父节点(时间源)并获得第一个有效的代价度量值。
图 72 - 普通发起方 DT 锚点的无线电行为(Radio behavior of a common Initiator DT-Anchor.)
源文档第 165 页
当 DT 锚点接收到其第一个 Poll DTM 时,它可以从 Poll DTM 的载荷中提取当前的测距块和轮索引(即 Block Index 和 Round Index)。基于这些信息以及对块、轮和时隙时长的预定义知识,DT 锚点可以估计当前测距轮何时结束以及下一个测距轮何时开始。类似地,使用通过 UCI 指定的已配置活跃测距轮,DT 锚点可以规划其下一个活跃测距轮何时开始。为了估计后续测距轮的开始时间,DT 锚点可以首先近似当前测距轮 i 的开始 tstarti。这可以通过 tstarti = tRXPoll i − tSHR 获得,其中 tRXPoll i 指的是 DT 锚点测得的接收到的 Poll DTM 的 RX 时间戳,tSHR 表示发送 UWB 帧的前导码(Preamble)和 SFD 部分所花费的时间(DT 锚点已知)。不过注意,DT 锚点可能会比预期的 tstarti 略早启动其接收机,以便足够早地唤醒,从而尽管存在时钟伪影(例如时钟漂移或块失配)仍能接收到帧。
基于所确定的 tstarti,下一个测距轮已知在 tstarti + TROUND 开始,其中 TROUND 是基于已配置的 DL-TDoA 块、轮和时隙结构的测距轮时长。类似地,下一个块的开始可以基于当前测距轮、轮时长 TROUND 和每个块的轮数来估计。
通过接收第一个 Poll DTM 并确定每个测距轮的开始和结束时间,DT 锚点可以将其块结构与 DL-TDoA 网络所使用的、最初由参考 DT 锚点设置的公共块结构进行首次对齐。之后,它可以通过在每个测距轮的第一个时隙打开其接收机来持续重新同步和重新对齐块结构,如图 72 所示,使 DT 锚点能够接收来自范围内发起方 DT 锚点的 Poll DTM,并选择合适的时间源(或一组时间源)以避免时间同步环路或不期望的簇间干扰。不过,替代实现可能仅每隔几个块侦听一次 Poll DTM 以降低能耗,或考虑进一步的技术(此处未规定)来改善 DT 锚点的整体性能。
如果选择了机制 2,则父节点或时间源的选择基于 Poll DTM 中所含的 Hop Count 字段,如 G.2 节所详述。DT 锚点可以仅基于所选父节点(或父节点集合)的 Poll DTM 来重新同步并因此重新对齐其块结构。
DT 锚点可能失去同步,例如,如果它在若干个块内未能接收到 Poll DTM。在这种情况下,DT 锚点可能无法确保其测距块结构与参考 DT 锚点的测距块结构充分对齐,它可能不得不重启其状态,打开其接收机直到接收到另一个 Poll DTM,使其能够再次重新对齐到公共块结构。DT 锚点判定其失步的实际时间是厂商和具体实现相关的。
附录 H - 跳频序列示例(Example of Hopping Sequence)
作为一个示例,假设 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(NRound)得到:
0x0001_df78
右移 16 位得到 BlockIndex 1 的 S 值:
0x1(即 1)
继续 BlockIndex 值 2、3 和 4 的序列,S 的值分别为 0、3 和 1。这意味着对于测距块 0、1、2、3 和 4,测距轮的 Round Index 将分别为 0、1、0、3 和 1。本示例中每个测距块所使用的测距轮如图 73 所示。
图 73 - 跳频序列示例(Example hopping sequence)
源文档第 167 页
测距轮索引、块索引和时隙索引的值按照 [IEEE_802_15_4z_2020] 中的定义进行引用。
附录 I - HUS 测距轮动态视图(HUS Ranging rounds dynamic view)
图 74 - HUS 测距轮的动态视图(Dynamic view of a HUS Ranging round)
源文档第 168 页
- 测距轮 1 中的 HUS(混合 UWB 调度)控制器创建一个 CAP(竞争接入周期)阶段,并识别响应方 A 和 B(在本附录章节中,HUS 受控器/响应方被称为设备 A/B/C/D/E)。
- 控制器在测距轮 M 的 CFP(无竞争周期)阶段添加设备 A,并为其他响应方创建一个 CAP 阶段以供参与。
- 在测距轮 M 的 CAP 阶段中,控制器识别出设备 C、D 和 E。
- 参与测距轮 M 的设备 A 发现其配置的 Session ID 与 RMML(测距轮管理列表)的阶段 Session ID 之间存在匹配。此外,它能够在测距轮 M 的第一个 CFP 中发送的 CM Type 1(1 型控制消息)的 RDML(测距设备管理列表)中找到其设备 MAC 地址。在参与测距轮的第一个 CFP 阶段之后,设备 A 将不再进一步参与该测距轮。
- 参与测距轮 M 的设备 B 发现其配置的 Session ID 与 RMML 的阶段 Session ID 之间存在匹配。当设备 B 无法在测距轮 M 的第一个 CFP 中发送的 CM Type 1 消息的 RDML 中找到其设备 MAC 地址时,它随后同步到即将到来的测距轮 CAP 阶段,并在 CAP 阶段中发送 RRM(测距响应消息)。
- 在 HUS 的过程中,在测距轮 N 中,控制器创建 2 个具有相同 Session ID 和 RF 配置的 CFP 阶段,以在同一测距轮中容纳超过 8 个受控器/响应方。它还创建 2 个具有相同 Session ID 和 RF 配置的 CAP 阶段。
- 参与轮 M 的设备 A、B、C、D 和 E 发现其配置的 Session ID 与 RMML 中存在的 CFP 和 CAP 阶段所对应的阶段 Session ID 匹配。
- 设备 A、B 和 D 参与测距轮的第一个 CFP 阶段,因为它们在第一个 CFP 中发送的 CM Type 1 消息的 RDML 中找到了其 MAC 地址匹配。
- 设备 C 在第一个 CFP 阶段的 CM Type 1 的 RDML 中找不到其 MAC 地址。它随后同步到即将到来的 CFP,并在第二个 CFP 中发送的 CM Type 1 消息的 RDML 中找到其 MAC 地址,并参与测距轮 N 的那个 CFP 阶段。
- 设备 E 在第一个和第二个 CFP 阶段的 CM Type 1 的 RDML 中都找不到其 MAC 地址。它随后参与测距轮 N 即将到来的 CAP 阶段并发送 RRM。
附录 J - DL-TDoA 跨簇同步(DL-TDoA Cross-Cluster Synchronization)
本资料性附录描述了一种 DL-TDoA 跨簇同步方法,用于在发起方 DT 锚点之间实现亚纳秒精度的同步。这一额外的同步功能提高了定位的稳定性和准确性,因为来自不同簇的 DTM(DL-TDoA 消息)可以更灵活地组合,从而在 DT 标签(DT-Tag)处容忍更高程度的消息丢失或受非视距(NLOS)影响的消息。这有助于跨簇边界对齐它们的发送时间戳,从而允许使用来自超簇(supercluster)内不同簇的 DTM 进行 DT 标签定位。
跨簇同步旨在区域性地限于具有良好无线电传播特性的区域,例如展览厅。它在作为超簇一部分的发起方 DT 锚点之间维护一个共享的公共时间。超簇由一个标识符(Supercluster ID)指示。使用相同标识符的 DL-TDoA 锚点被允许彼此之间执行跨簇同步。
跨簇同步是一种可选功能方法。它可以与簇内同步和簇间同步一起额外使用。
发起方 DT 锚点与响应方 DT 锚点之间的簇内同步保持向后兼容,因为响应方 DT 锚点可以被配置为使用簇内公共时间基准。跨簇同步将公共时间基准从单个簇扩展到形成超簇的多个簇。作为超簇一部分的每个发起方 DT 锚点都在更新其超簇公共时间基准,同时考虑来自可达范围内、使用相同超簇 ID 的其他发起方 DT 锚点的 Poll DTM。
跨簇同步利用发起方 DT 锚点之间跨多个跳的公共时间交换。公共时间由一组 3 个值表示:
- 发送时间戳(txTs),表示公共时间中一个 tick 精度的时间点。
- 时钟频率偏移(CFO),表示设备本地时钟频率与公共时间频率之间的频率偏移。
- 超簇 ID(scID),标示对超簇的成员资格,即一个具有良好视距条件、允许 tick 精度时间同步的区域。
图 75 通过一个两个发起方 DT 锚点的示例说明了公共时间更新过程。
图 75 - 跨簇同步更新过程示例(Example of cross-cluster synchronization update process)
源文档第 170 页
发起方 DT 锚点 A 发送一个 Poll DTM,其中包含公共时间基准下的发送时间戳 txTsA、其相对于公共时间频率的时钟频率偏移 cfoA 以及超簇标识字段 scIDA。如果发起方 DT 锚点 A 正在启动公共时间配置过程,它将为 txTsA 和 cfoA 提供初始值。在没有先验知识的情况下,这两个值都可以初始化为零。scIDA 值表示配置给发起方 DT 锚点 A 的超簇 ID 值。
一旦发起方 DT 锚点 B 接收到来自发起方锚点 A 的 Poll DTM,它首先检查发起方锚点 B 的超簇 ID 是否与发起方锚点 A 的超簇 ID 匹配。如果它们相同(两个发起方 DT 锚点属于同一超簇),则来自锚点 A 的 Poll DTM 将用于使用所发送的 TX 时间戳 txTsA 和所发送的 CFO 值 cfoA 来更新发起方 DT 锚点 B 的公共时间。这包含以下步骤:
- 确定 DT 锚点 B 处的公共时间
通过测量或获知发起方 DT 锚点 A 与发起方 DT 锚点 B 之间的距离,可以使用所发送的 TX 时间戳 txTsA 加上发起方 DT 锚点 A 与发起方 DT 锚点 B 之间的飞行时间 tofAB 的修正来确定 DT 锚点 B 处的公共时间。
txTsB = txTsA + tofAB * nominal-tick-frequency * (1+cfoA) - 确定发起方 DT 锚点 B 处相对于公共时间频率的频率偏移
通过测量发起方 DT 锚点 A 与发起方 DT 锚点 B 本地频率之间的时钟频率偏移 cfoAB,可以使用来自发起方 DT 锚点 A 的所发送 CFO 值 cfoA 加上 cfoAB 值的修正来确定 DT 锚点 B 处相对于公共时间的频率偏移 cfoB。
1+cfoB = (1+cfoA) (1+cfoAB) - 更新 DT 锚点 B 处的时钟频率偏移和公共时间
基于从步骤 1 和 2 获得的信息,DT 锚点 B 处的公共时间信息将被更新。为了处理飞行时间和 CFO 测量中所涉及的误差,发起方 DT 锚点 B 处的公共时间信息可以在若干个 DTM 上进行跟踪。在这种情况下,步骤 1 和 2 中的值可以在更新过程中被部分考虑,同时考虑历史定时信息。一种示例方法可以在实际信息与历史信息之间使用恒定的加权因子 k。
更新后的 CFO 值和公共时间随后可用于发起方 DT 锚点 B 处 DTM 的组装和调度。
该过程可应用于共享相同超簇 ID 的多个发起方 DT 锚点。图 76 展示了一个具有分布在 2 个超簇上的 5 个发起方 DT 锚点的示例设置。发起方 DT 锚点 A、B、C 属于超簇 1。发起方 DT 锚点 D、E 属于超簇 2,超簇 2 与超簇 1 被一堵墙隔开。
图 76 - 使用分布在 2 个超簇上的 5 个发起方 DT 锚点的跨簇同步示例(Example of cross-cluster synchronization using 5 Initiator DT anchors distributed over 2 superclusters)
源文档第 172 页
该墙可能在发起方 DT 锚点 C 与发起方 DT 锚点 D 之间的消息交换上引入显著的飞行时间误差。由于发起方 DT 锚点 D 使用不同的超簇 ID 接收到来自发起方 DT 锚点 C 的 Poll DTM,该 Poll DTM 将不用于跨簇同步。