LE Channel Sounding记录

wfzlry

已于 2024-11-01 17:29:44 修改

阅读量622

点赞数 3

文章标签：蓝牙测距

于 2024-10-30 16:57:26 首次发布

本文链接：https://blog.youkuaiyun.com/wfzlry/article/details/143369480

版权

本文内容会不定时更新

LE channel sounding的指标

LE channel sounding的指标

评判LE channel sounding的指标有：准确性、安全性、延迟和功耗

LE CS应用程序可能会对准确性、安全性、延迟和功耗等问题给予不同程度的优先考虑。

准确性和安全性提升了，会导致延迟变大。

准确性方面，影响测量精度的因素有很多

生成信号频率的准确性和稳定性
内部时钟的稳定性以及时间戳的准确性和分辨率

等等

在CS中为提升测量精度，

使用Mode 0 Step和 Mode-0 FAE计算FFO

在接收到Reflector发出的响应信号后，Initiator会计算一个称为分数频率偏移（FFO）的值。FFO 的计算涉及从Reflector接收到的CS Tone的频率和Reflector的Mode-0 FAE 表。随后在计算中使用 FFO 来补偿两个设备之间的差异，提高结果的准确性。

虽然只通过一个CS Subevent的结果就能计算出距离，但是采用多个CS Subevent执行多次step交互，肯定是可以提升准确性的，因为一次计算的结果有可能是因为误差引起。
采用不同的RTT方法，可以带来不同的测量精度；在CS_Sync包中增加Random Sequence或者Sounding Sequence可以提升测量精度和安全。
测距算法的优劣对于展示给上层应用的测距结果的影响也是非常大的。

安全性方面

在https://www.bluetooth.com/channel-sounding-tech-overview/#security章节有详细介绍

延迟方面

应用的另一个考虑因素是延迟。每次信号交换都需要时间。根据天线路径的数量，模式-1 RTT 交换有时比模式-2 PBR 交换耗时更长。鉴于 RTT 的作用是通过使整个Bluetooth Channel Sounding 流程更加安全来补充 PBR，因此需要将延迟保持在一定阈值以下的应用可能会选择在Bluetooth Channel Sounding 流程中包含较低比例的 RTT 交换。要做到这一点，可以选择模式-2（PBR）作为主模式，模式-1（RTT）作为子模式，并将 Min_Main_Mode_Steps 和 Max_Main_Mode_Steps 参数设置为合适的值，以便达到所需的主模式与子模式步骤的最小比例。

在两个设备都支持模式 3 的情况下，延迟和 PBR 与 RTT 交换的比例仍然是应用需要考虑的问题。模式-3 中的所有交换都包括与 PBR 相关的 CS Tones 和与 RTT 相关的 CS_Sync 数据包，两者的比例相同。对于某些应用来说，这可能是次优的。

功耗方面

个人认为，采用PBR方法时在多天线时会增加设备的功耗；

另外，CS的App连上LE设备，开启测距功能后，App采用什么机制进行测距，如果需要不间断地展示和LE设备间的距离，则需要不间断地发起和执行CS procedure，这对于LE设备的功耗会带来很大的影响。

关于CS_SYNC包中的AA

Access Address (AA) 的作用很清楚，那就是接受者使用特定的LE PHY、在正确的时间、正确的Physical Channel会收到很多Packets，如何确定收到的packet是不是自己预期要接收的，就是根据AA。
在Advertising，使用固定的AA；在LE Connection状态和CIS连线状态，使用的是连线过程中协商好的AA；在BIG中，使用的AA是通过BIGInfo中的SeedAccessAddress的计算得出的AA。

而在CS的Step交互中，Mode为0、1和3的Step 都是开始于CS_SYNC包的发送。
Initiator和Reflector也是基于LE link之上，创建CS Procedure的PDU交互中(LL_CS_REQ、LL_CS_RSP、LL_CS_IND)并未协商CS_SYNC包中的AA。
那么CS_SYNC包中AA是怎样的机制？答案如下：

In the case of Channel Sounding, each device changes its Access Address {eld in CS_Sync packets at every mode-0, mode-1 and mode-3 CS step. As such, each device has a unique Access Address at every step. New Access Address values are generated using selection rules that involve the DRBG and both devices know the Access Address that will be used by the other. Receiving devices check the Access Address value and report any issues to the host.
在Bluetooth Channel Sounding 的情况下，每个设备在每个模式-0、模式-1 和模式-3 CS 步骤中都会更改 CS_Sync 数据包中的访问地址字段。因此，每个设备在每一步都有一个唯一的访问地址。新的访问地址值是通过涉及 DRBG 的选择规则生成的，两个设备都知道对方将使用的访问地址。接收设备会检查访问地址值，并向主机报告任何问题。

RTT测距原理

图 13中往返时间 (RTT)可以表示如下：

设备 A 要计算 RTT，需要知道设备 B 的周转时间（即(ToDB)-(ToAB)）。从理论上讲，有多种方法可以做到这一点。在实践中，最简单的解决方案是设备 A 和设备 B 事先商定一个固定的周转时间。然后，设备 B 必须保证完成其处理，并在周转期结束时准确地传输其响应。然后，设备 A 使用事先商定的值((ToDB-)(ToAB))。

Mode-1 Step采用RTT的方式进行测距。

其中，

T_SY花费的时间(即CS_SYNC包自身的时间)，由CS_SYNC包使用的LE PHY、是否包含Random Sequence或者Sounding Sequence以及Sequence的大小来决定；通过CS配置参数可以确定。

T_RD、T_IP1也可以通过CS配置参数来确定。

在HCI_LE_CS_Subevent_Result Event中，

ToA_ToD_Initiator表示在一个CS Step期间，Initiator对于CS_SYNC包的到达时间(ToA)和出发时间(ToD)的时间差,单位为0.5微秒。需要注意的是，这个时间差是已经排除了名义上的偏差(比如包自身的时间、T_IP1等)之后的。

那么Controller是怎么计算出ToA_ToD_Initiator的呢？

Initiator可以测算出CS_SYNC包发出的时间、以及经reflector后到达Initiator的时间；这期间reflector何时收到CS_SYNC包、何时开始处理CS_SYNC包，Initiator并不知道。

但是，根据上面的Figure 26我们可以知道，Initiator是可以算出Reflector发送包的时间的，即从Initiator开始发送CS_SYNC包的时间点算起，经过CS_SYNC包自身的时间 + T_RD + T_IP1时间之后，就是Reflector发送包的时间。

有了Reflector发送包的时间，Initiator收到包的时间，这个时间差就是CS_SYNC包从Reflector传输到Initiator的时间。估计Controller为了方便上层应用，把这中间的计算过程帮忙做好了，然后将计算好的值ToA_ToD_Initiator发给Host，这个ToA_ToD_Initiator是往返时间，除于2才是单程的时间。

关于PHY

实施Channel Sounding使用的LE PHY可以是：LE 1M 或 LE 2M PHY，或者LE 2M 2BT PHY。

LE 2M 2BT PHY只能用于Channel Sounding。

现存的蓝牙产品是否可以通过软件升级的方式来支持LE CS, BT SIG给出了回答。

Can existing products be upgraded to add support for Bluetooth(®) Channel Sounding?

This is manufacturer dependent. Bluetooth(®) Channel Sounding introduces an entirely new protocol stack, including a Physical Layer (PHY) which may require a Bluetooth Low Energy (LE) integrated circuit (IC) upgrade to enable support for the feature. However, you should check with your device and/or product manufacturers to ultimately make this determination.

如果说必需得LE 2M 2BT PHY，那么在没有LE 2M 2BT PHY的蓝牙设备中肯定是不能通过软件升级的方式来支持LE CS的，因为LE PHY属于物理层了，只改软件肯定不行。另外，LE CS使用的physical channel有72个，CS协议规范出来之前LE channel只有40个，如果仅直接使用LE 1M/2M PHY而对硬件不做任何改变的话，似乎在physical channel支持层面也会有问题。

虽说支持LE CS不一定非要使用LE 2M 2BT PHY，但LE CS对于精度要求很高，对蓝牙设备中的LE芯片的性能要求很高，需要对生成的时间戳有很高的准确性和分辨率。1微妙的偏差，对应于约300米的距离偏差。

所以说还是得看芯片厂商。

关于CS测量结果的上报

The HCI_LE_CS_Subevent_Result event shall be generated when the local Controller
has results to report for a CS subevent during the CS procedure. Depending on
the number of CS steps in the CS subevent, the Controller may choose to report
complete or partial results. When the number of CS steps exceeds the maximum HCI
event size, the Controller may report further results for the CS subevent using the
HCI_LE_CS_Subevent_Result_Continue event。

以CS subevent为单位，当一个CS subevent的交互有测量结果了就可以上报。

reflector能获取到测距结果吗？

下图展示的是，在Central设备中以Initiator角色发起CS测量。

Initiator发起channel sounding流程后在CS procedure过程中，Initiator和reflector的controller都会上报HCI_LE_CS_Subevent_Result Event给各自的Host。

Initiator作为发起方，肯定是能通过测距算法获得精确的距离的；那reflector呢，它能计算出和Initiator之间的距离吗？

从reflector的Host收到的Mode_Role_Specific_Info可以看出，reflector似乎也能通过自身的测距算法计算出它和Initiator之间的距离

（存疑，如果reflector能获取到测距结果，原理是什么；如果reflector不能获取到测距结果，那么reflector的Controller为何发送HCI_LE_CS_Subevent_Result 事件给reflector的Host呢？）。

比如下面这中场景中，假设main mode为1，没有sub mode， reflector只从ToD_ToA_Reflector这个信息中得不出CS_SYNC包的飞行时间，那它怎么算出RTT呢？

RAP和RAS

Ranging Profile 和 Ranging Service，分别简称为RAP和RAS，目前尚未但即将发布。

RAS Server可将自身的Ranging Data发送给RAS Client。而Ranging Data是RAS Server执行Channel Sounding Procedure的结果，由Controller通过HCI CS Subevent Result event和HCI CS Subevent Continue Result event发给Host。RAS Client从RAS Server获取到Ranging Data之后，可以用来运行距离估算。

RAS Server可以是CS Initiator，也可以是CS Reflector。

所以CS Reflector通过RAP就可以获取到CS Reflector的Ranging Data, 再通过自身的测距算法计算出它和Initiator之间的距离。