通过 WiFi 信标进行基于边缘的被动人群监控

Posted 2022-09-08 AI浩

文章目录

• 摘要
• 2、相关工作
• 3、 初步和主要观察
• • 3.1、 WiFi 探测请求
  • 3.2、 MAC 随机化
• 4、 室内人群监控：公交车上的人数
• • 4.1、 硬件描述
  • 4.2. 捕获过程和探测请求分析
  • 4.3、系统参数调整
  • 4.4、 绩效评估
  • 4.5、使用蓝牙拍摄
• 5、户外人群监控
• • 5.1、 测试平台架构
  • 5.2. 移动应用
  • • 5.2.1、 移动虚拟化网络
    • 5.2.2、可视化 VNF
  • 5.3、 数据分析
• 6、追踪移动性
• • 6.1、 我们的方法
• 7、结论

摘要

跟踪人流已变得至关重要，不仅对于安全和保障，而且对于许多实际的商业应用以及更好地管理城市空间、设施和服务。在本文中，我们提出了利用部署在网络边缘的物联网技术的方法，可以分析人们在城市环境中的运动，包括室外和室内。特别是，利用移动人员携带的智能设备发送的 WiFi 探测数据包，我们首先描述了我们的方法的实现，该方法使用现成的硬件来计算乘坐公共交通工具的人数。然后，我们使用连接到边缘的商用 WiFi 扫描仪并利用适当部署的虚拟网络功能来处理 OneM2M 物联网平台收集的数据，提出了一种替代实施方案，还提出了一种可应用于商业 WiFi 扫描仪提供的匿名数据的移动跟踪程序.我们的实验结果表明，所提出的人数统计和移动检测方法可以达到良好的准确度，同时总体价格低廉。

2018 年 11 月，意大利国家统计局 (ISTAT) 发表了一项关于日常通勤者及其交通工具的研究 [1]。分析中使用了上一年全国人口普查的数据。根据本次调查的结果，超过 40% 的意大利人口不喜欢定期使用私人交通工具进行日常旅行，19% 的意大利人口更喜欢步行或骑自行车，而 23% 的人更喜欢使用公共交通工具，例如公共汽车、电车、火车、校车或地铁。总体而言，这代表了相当一部分依赖非私人交通工具的全国通勤者。为了定期上下班或上学，这部分城市人口依赖于市政交通机构提供的充足基础设施和服务。很明显，从普查中获得的基本数据不足以实现这一目标。为了保持高水平的服务，需要定期精确监控公共交通的用户数量。如果当地交通当局在每个站点收集到公交车乘客的实时数据，他们将能够适当地扩展服务。此外，在各国政府为阻止 COVID-19 大流行的蔓延而实施的全球封锁之后，运力在公共场所设立了限制措施，以限制聚集的人数。例如，意大利制定了公共交通车辆可运送的最大人数限制。因此很明显，设计一个有效的人流监控系统变得至关重要。然而，以值得信赖的方式满足这一需求是极具挑战性的，因为在设计的监控系统的每个部分都应保护所涉及的每个人的数据隐私。

重要的是，对于为移动用户设计的许多安全应用程序和便利服务，必须检测人们在一天/一周的不同时间所采取的模式。 实现这一目标的关键技术之一是物联网 (IoT) [2,3]，因为物联网设备正变得无处不在，其中大多数都配备了无线电接口，例如 WiFi、LoRaWan 或 5G， 可以方便地将它们与其他设备以及通信网络基础设施连接起来。 此外，物联网设备通常消耗很少的能源，因此它们有助于创建可持续的通信系统，成本低，并且比其他设备（如智能城市摄像机）造成的隐私问题更少。

在这项工作中，我们利用物联网技术解决了描述人们的轨迹和流量包含的人数的问题，同时保护了用户的隐私。 特别是，我们专注于城市环境，并利用商业传感器和配备 WiFi 接口的 Raspberry PI 等简单设备。 此类设备可以扫描 WiFi 频谱以查找探测请求，即由用户手持设备向附近接入点传输的数据包。 使用这些频谱扫描仪提供的日志，我们开发了提高数据收集和处理隐私级别的技术。 重要的是，我们的目标是开发一种解决方案，以应对商业或基于 Raspberry PI 的扫描仪的严重限制，这需要相对于现有技术中提出的新方法。

与现有工作不同，我们开发的机制可以有效地 (i) 应对商业传感器以及简单、低成本的临时设计设备，用于扫描 WiFi 探测器的频谱，以及 (ii) 提高用户的隐私保护水平。 此外，应用基于 ML 的方案，我们展示了如何使用通过我们的隐私保护技术收集的数据来表征人们的流动。 然后，我们的方法通过我们开发的概念验证测试平台和我们在意大利都灵市 GTT [4] 运营的公共巴士上进行的测量活动得到验证。

本文的其余部分安排如下。 在第 2 节讨论了一些相关的相关工作之后，在第 3 节中，我们描述了 WiFi 技术的一些特性，这些特性与我们的人流检测隐私保护解决方案的设计相关。 然后第 4 节提出了一种室内人数统计方法，以公共巴士为例，说明可以部署监控系统的室内公共场所。 我们在室外空间使用的方法在第 5 节中介绍。在第 6 节中介绍了人们移动跟踪的方法。最后，第 7 节得出了一些结论。

2、相关工作

近年来，在室内和室外场景中，已经使用了几种不同的方法来应对城市区域中的人员检测和计数问题。 红外传感器、相机、压力传感器、可见光传感器、RFID、UWB 和音频处理是其中的一部分，但是，上述技术有时在实施成本方面并不能提供令人满意的结果，而在其他时候它们 获得不足的性能[5]。

一些方法基于电磁方法，该方法在空间和时间上分析接收到的信号，该信号受该地区人员的存在影响。所有这些方法都适用于小型室内环境，并且需要特定的射频发射器。例如，[6] 中的工作提出对利用 WiFi 信号的人数进行计数，假设人体的运动会影响无线信号反射，从而导致 CSI（信道状态信息）发生变化。该方法在同一个房间内的准静态室内场景中效果很好（例如，会议室中的人或办公室中的工作人员），但在人们开车移动的非常动态的环境中很难实施，自行车，或步行。另一项工作 [7] 通过利用无线信号在人体上的反射并安装处理反射信号的特殊接收器，专注于使用现成的 WiFi 设备计算穿过门口的人数。这种方法需要一个以上的设备来覆盖所有可能的访问，例如，在总线上，显着增加了部署成本。事实上，它不能应用于在交通信号灯顶部安装传感器（如我们的例子）的户外城市场景。

另一种方法（尽管非常昂贵）是使用摄像机和高级算法进行视频图像处理来计算人数。 例如，最先进的 YOLO_V3 库 [8] 可以实时识别和计算 30 FPS 视频中的人头，但它需要高级 GPU 和高度配备的服务器，导致基于视频的 对于大规模使用来说过于昂贵的检测平台，尤其是在网络边缘。

最后，值得一提的是，这项工作的某些部分的初步版本已经出现在我们的会议论文 [9-11] 中。具体来说，[9,10] 概述了我们在考虑用户隐私的同时跟踪人员流动的解决方案。 [11] 相反，介绍了我们实现的两个虚拟网络功能 (NFV) 以及相关脚本，根据当时收集的数据提供了一些关于人流检测的初步结果。 在这项工作中，我们将这两种方法结合起来，从而产生了一种高效且有效的解决方案和实施方案，并且我们使用在我们部署的扫描仪所覆盖的区域中收集的超过两年半的数据，提供了广泛、更有洞察力的结果。

3、 初步和主要观察

如前所述，我们使用 WiFi 信号接收和处理来估计智能设备（例如智能手机、平板电脑、笔记本电脑、智能手表等）的数量。 因此，我们的方法包括扫描 WiFi 频谱，尝试捕获智能手机发送的 WiFi 数据包。当智能手机的 WiFi 接口打开时，它会发送一连串广播消息以发现附近的接入点 (AP) 和智能手机。 为了将记录的 WiFi 信号与智能手机链接，我们检查了收集的数据包上的 MAC（媒体访问控制）地址信息。

在下文中，我们总结了 WiFi 的一些重要特性，我们稍后会利用这些特性以保护隐私的方式从传输的消息集合中提取有用信息。

3.1、 WiFi 探测请求

根据扫描模式是主动还是被动，智能手机可以主动在信道上发送探测请求，也可以通过接收 AP 发送的 Beacon 帧来触发。 智能手机通常能够支持两种扫描模式并在它们之间来回切换。 在我们的实验中，嗅探器主要捕获智能手机在主动扫描期间主动生成的探测请求。

3.2、 MAC 随机化

探测请求是管理类型的帧，与在关联操作期间传输到 WiFi AP 的所有其他帧一样。 它们是创建加密通道所必需的，用户将来将利用该通道发送数据。 结果，包含在任何这些管理帧中的任何字段都以明文形式广播。 通过从 WiFi 通道收集探测请求，可以以纯文本形式检索其中的所有信息以及发送者的 MAC 地址。 根据 [12]，知道设备的 MAC 地址是一条非常敏感的信息，可能会被用于许多网络攻击以及监控人们的活动。

因此，几乎所有智能手机制造商都会随机化探测请求帧中的 MAC 地址。 事实上，软件供应商已经发现在这个过程中广播初始 MAC 地址是不必要的，因为绝大多数探测请求数据包不会导致与 AP 的实际连接，而是仅用于扫描原因。 在这种情况下，通用/本地位设置为 1，从而生成随机 MAC 地址。

MAC 随机化方法是专有的并且取决于制造商。 2014 年，Apple 率先为运行 ios 8 [13] 的智能手机采用 MAC 随机化，随后是同年采用 Linux Kernel 3.18 的 Linux，以及次年采用 android 6.0 [14] 的 Android。 尽管所有操作系统都支持 MAC 随机化选项，但许多设备（尤其是运行 Android 操作系统的设备）默认情况下并未启用 MAC 随机化选项。 在一些逆向工程调查中，观察到每次发出大量探测请求时，所有操作系统 (OS) 都会更改其 MAC 地址。 此外，[5] 揭示了 iOS 10.1.1 设备如何根据某些用户行为随机化其 MAC 地址。 对于运行此软件版本的智能手机，每次设备被锁定或解锁、启用或禁用其 WiFi 接口或尝试与不同 AP 的连接时，都会发出一个新的随机 MAC 地址。

MAC 随机化解决方案虽然有助于减少通过通道广播的潜在敏感数据问题，但并不能完全消除它。 这些实现包含各种问题和缺点，包括利用探测请求帧中给出的附加信息或其时序，即使它们的 MAC 地址是随机的，这也可能导致对设备的监控 [15]。事实上，去随机化过程可以 被用来大大降低随机化算法的影响。

4、 室内人群监控：公交车上的人数

在本节中，我们将重点统计都灵市乘坐公共巴士的人数。 得益于成本极低的 Raspberry Pi 3B，我们应用去随机化算法实时计算机上乘客数量，使用乘客设备通过 WiFi 网络广播的探测请求。

4.1、 硬件描述

我们工作的主要目标之一是通过创建可以轻松安装在公共巴士或其他公共场所的廉价传感器系统，为人们的运动跟踪提供可持续、低成本的解决方案。出于这个原因，我们的目标是使我们使用的硬件组件的成本保持在较低水平，同时仍然拥有足够的处理能力来进行动态分析。最好的解决方案是使用 Raspberry Pi (RP) 硬件。我们选择了 RP 3 Model B，它有一个 1.2 GHz 64 位四核 ARM CortexA53 CPU、板载 802.11n WiFi、蓝牙、1 GB RAM、一个以太网连接和四个 USB 端口，它运行 Linux操作系统。由于 RP 3 Model B 的 WiFi 接口默认不支持监控模式，我们购买了一个基本的 USB 加密狗天线，用于在监控模式下捕获 WiFi 通道上的帧。我们使用了一个移动 USB 调制解调器，它可以使用 SIM 卡连接到 3G 和 4G/LTE 网络，以便从不同网络访问我们的 RP。最后，对于电源和以太网连接，使用 PoE 分路器将我们的 RP 连接到 PoE 电缆。我们的整个硬件设置如图 1 所示，这导致所有组件的总成本低于 50欧。

4.2. 捕获过程和探测请求分析

为了避免存储敏感信息，我们的 RP 记录的探测请求被实时检查，通过在两个接口上流水线化网络嗅探器的输出（WiFi 显示探测请求数据包，以太网显示总线内部信息 门的状态）到用于分析收集的消息的处理脚本。 如下所述，分析包括四个主要步骤，每个步骤都通过一个单独的脚本文件执行。 脚本在管道中一个接一个地执行，因此我们可以以模块化的方式对同一个输入实例执行多个操作。

时间窗口采样：由于来自智能手机的探测请求是突发广播的，因此对单帧信息进行详细分析是不切实际的。分析一致的帧集合对于深入了解在任何给定时刻乘坐公共汽车的乘客数量是必要的。为此，脚本会跟踪门状态，通过 UDP 从总线网络检索到门状态，以及记录在捕获程序输出的文件中的探测请求。当总线门关闭时，新的探测请求帧被添加到时间窗口的最终位置，并检查由此创建的样本以进行进一步处理。当公交车站的门状态指示门正在打开时，一旦门关闭，采样的窗户就会被清除并从头开始重建。因此，我们可以确信我们的样本涵盖了两次连续开门之间的整个时间间隔，即两个连续的公交车站之间。

MAC 地址分析：在我们的示例窗口中识别出多次出现具有相同 MAC 地址的探测请求帧，因为探测请求帧是突发广播的。 为了压缩来自单个 MAC 源地址的帧，脚本会在刚刚过去的时间窗口中获取所有样本并扫描所有记录的帧。 出现在采样时间窗口内的每个单独的 MAC 地址都由应用程序单独记录，以及创建的每条记录的一些额外信息。 在该过程结束时，单个记录将包括与相同 MAC 地址的突发相关的所有数据。 之后，新鲜样品将在下一阶段的分析中进一步处理。

探测请求过滤：由于我们只对检测船上人员的设备感兴趣，因此需要进行一些过滤以将我们的捕获范围仅限于总线。事实上，我们的传感器收集的一些探测请求帧很可能不是由车载设备发送的，而是由车外的设备发送的。这主要发生在公交车停在红绿灯处并被其他车辆包围时，但也可能在任何时候发生。为了解决这个问题，我们定义了一个功率水平阈值$P_l$，以及一个发生水平阈值$Q_l$，定义为样本窗口内 MAC 地址的最小出现次数。突发中较短的帧数可以表明设备在总线附近经过了很短的一段时间，而平均功率水平可用于推断发射器和传感器之间的距离。如果一个 Probe Requests 突发的平均功率小于 $P_l$或突发包含的帧数少于$Q_l$ 帧，则删除相应的输入记录。假设未删除的数据属于车载设备，并将其发送到去随机化算法。 $P_l$ 和 $Q_l$ 是必须充分设置的两个参数，并且对于每个环境都是独一无二的，即它们应该在不同的总线中重新校准。正如本节末尾所讨论的，为了找到最合适的参数选择，我们进行了广泛的测试，并将我们的结果与通过人工计数会议确定的实际船上乘客人数进行了比较。

MAC 去随机化：MAC 去随机化是我们探测请求计数过程的核心方法。 它尝试根据从管道接收到的信息来确定具有不同随机 MAC 地址的两个探测请求突发是否可能属于同一设备。 输入数据是一系列探测请求帧，每个帧都有一个相同的 MAC 地址。 iABACUS 方法 [16]，即一种对 MAC 随机化方法进行逆向工程的递归机制，是我们去随机化操作的基础。 当使用 iABACUS 方法时，它会生成一组列表，每个列表都携带不同的随机 MAC 地址，这些地址假定与单个设备相关联，试图掩盖其真实的 MAC 地址。 最后，我们通过计算去随机化过程形成的不同列表的数量来计算板上识别的单独设备的数量。

结果，船上的人数与检测时间戳一起被计算出来，并作为 UDP 数据报通过我们的 LTE 加密狗传输到我们自己的服务器，在那里使用 Grafana 仪表板进行详细查看。

4.3、系统参数调整

为了正确建立对我们系统性能至关重要的所有标准，我们需要将计数过程的结果与基本事实进行比较。 在遥感系统中，地面实况的概念用于描述现场收集的数据，这些数据用于校准获取的数据并帮助解释和分析已检测到的数据。 因此，我们安排了几次手动计数会议，以确定在我们的系统运行时公共巴士上的确切人数。 只有将人工计数结果与传感器同时检测到的值进行比较，才能正确设置系统参数，以反映采集环境。

我们计算了每个公交车站的地面实况数字与我们软件系统中的相应值之间的差异。 通过对手动计数过程中的所有误差进行平均，我们能够计算出一组特定参数的平均相对误差。 我们方法中使用的主要参数是功率水平阈值$P_l$和发生水平阈值$Q_l$，它们都根据获得的实验结果进行了调整。 图 2 显示了功率和发生阈值的各种组合的平均相对误差。 使用 $Q_l$ = 1 和$P_l$ = −75 dBm 的值作为阈值，我们可以滤除虚假检测事件，从而最大限度地减少我们几乎所有比较中的平均相对误差，正如从所呈现的图中可以看到的那样。

4.4、 绩效评估

由于上述过程，我们现在可以相当精确地估计公共汽车上的乘客数量。 为了更准确地评估我们的系统，公交车上的人数被分为三类：“绿色区域”表示车上乘客人数较少，即少于公交车最大容量的 20%（ 即，在我们的例子中是 16 个）； “黄色区域”，载客人数占巴士最大载客量的 20% 至近 40%（即 16 至 28 人）； “红色区域”占总容量的 40% 以上（即 28 名乘客或更多），这意味着公交车上的安全人际距离无法再得到保证。

总的来说，我们的研究结果表明，对于所有有基本事实可用的场景，我们可以高度准确地预测船上的实际人数。 图 3(a) 描绘了我们的计数预测与 2020 年 10 月 16 日进行的人工计数之间的比较。如果我们估计这种情况下的总体相对误差，则全天的准确度达到 85%。 2020 年 10 月 19 日记录的基本事实与人工计数之间的差异如图 3(b) 所示。 在这种情况下，整体准确率相当高，即 90%。 最后，图 3© 显示了与 2020 年 10 月 30 日记录的地面实况的差异，总体准确率为 91%，而图 3(d) 描绘了与 2020 年 10 月 30 日记录的地面实况的差异。 2020 年 11 月 2 日，总体准确率为 88%。

4.5、使用蓝牙拍摄

此处为 WiFi 提供的整个分析可以以类似的方式复制到蓝牙或蓝牙低功耗 (BLE)。 事实上，文献中有许多通过蓝牙接口进行类似分析的例子 [17,18]，取得了可喜的结果。

在该项目开始时，我们将传感器配置为并行分析 WiFi 和 BLE。 与 WiFi 捕获方法类似，BLE 程序具有时间窗 MAC 地址分析、过滤和去随机化功能。 对于 WiFi，BLE 以非常高的频率发送尺寸小得多的广播数据包。 实际上，BLE 捕获可以轻松达到大约 80-90 个数据包/秒，所有这些都只有几个字节大小。 很明显，从 CPU 负载的角度来看，对 BLE 等高频介质进行动态分析是如何产生很大影响的。 出于这个原因，考虑到我们硬件的有限计算能力，我们决定让整个捕获过程仅基于 WiFi 探测请求。

5、户外人群监控

我们现在处理一个户外场景，重点是检测和计算在意大利都灵特定区域使用任何交通工具移动的人数。 在这个试验台上，几台商用扫描仪安装在都灵理工大学校园和 Porta Susa 火车站之间的一英里处，该火车站是意大利都灵市的主要交通火车站。 在这个区域，我们能够检测到每天步行到我们校园的人，以及使用不同交通工具（例如，自行车、电动滑板车、汽车、摩托车）的大量人员流入和流出。

关于第 4 节中描述的场景，这里我们考虑更广泛的区域、各种交通工具和非常高的动态环境。 在这种情况下，我们选择使用黑盒商业 WiFi 扫描仪 (Libelium Meshlium)：所有捕获的 MAC 地址都立即通过 SHA-224 哈希函数匿名化。

5.1、 测试平台架构

图 5 描绘了我们为解决户外用例而部署的测试平台的架构。 它包括一个边缘云，其中通过组合多个 VNF 来实现两个应用程序。 所有 WiFi 扫描仪都通过无线电接入网络 (RAN) 连接到 OneM2M 服务器 [19]，这是一种用于提供物联网服务的开放式架构。 MQTT 代理允许通过边缘云连接到 OneM2M 服务器，边缘云托管在都灵理工大学的专用数据中心。 由于使用了边缘范例，所提出的架构可以随着安装的扫描仪数量水平扩展。 此外，使用 VNF 来实现整个移动应用程序在所需的硬件资源方面提供了高度的灵活性。

通过 MQTT 连接，存储在 OneM2M 服务器中的所有数据都由 MOB（“MOBility tracking”）VNF 检索并保存在本地 mysql 数据库中，以便在未来的数据分析中获得更好的性能。 最后，用户/实验者可以通过开发基于 Web 的可视化工具的 VIS（“可视化”）VNF 实时查看扫描仪收集的所有数据。

如图 4 所示，安装了六个 Libelium Meshlium WiFi 扫描仪 [20]，其中两个在校园入口旁边的入口处，另一个在交通灯杆的顶部。 扫描仪被配置为被动捕获 2.4 GHz 和 5 GHz ISM 频段上的“探测请求”，由移动设备在搜索已知 WiFi 网络时定期发送，如第 3 节所述。每个扫描仪都连接到我们的平台 通过蜂窝连接在 5G EVE EU 项目 [21] 中开发。 扫描仪每 51 秒 1 将有关在最后一个采样期间检测到的所有设备的信息分组一次，并且每两分钟将收集到的数据上传到 OneM2M 服务器 [19]。 与第 4 节中开发的 ad-hoc 解决方案不同，扫描仪提供的处理数据不允许运行任何去随机化技术。

5.2. 移动应用

我们现在详细介绍我们开发的移动应用程序，描述其中的每个 VNF。

5.2.1、 移动虚拟化网络

MOB VNF 负责通过 MQTT（消息队列遥测传输）客户端从 OneM2M 平台检索数据。 MQTT 是一个非常轻量级的开放式传输协议，基于发布-订阅范式。 该协议运行在 TCP/IP 之上，因此它是可靠的并且可以防止数据的乱序传递。

当扫描器向远程平台上传一条新消息时，它会保存在服务器的本地数据库中，然后也会发送到 MQTT 客户端，在客户端对消息进行解析、分析并存储在 MOB 的 MySQL 数据库中。 在将数据保存到 MOB 数据库之前，依次进行两个操作：(i) 地址摘要，和 (ii) 固定设备移除。 第一个操作允许减少数据库上数据的大小，而第二个操作允许消除所有那些作为固定对象（例如，AP、个人计算机等）被视为异常值的设备。

5.2.2、可视化 VNF

VIS VNF通过Grafana[22]工具上实现的交互式实时可视化仪表板和链接到python脚本的简单动态网页，提供了通过标准web浏览器收集和分析的所有数据的聚合视图。

Grafana 是一个多平台、开源分析和交互式可视化 Web 应用程序。 它支持使用数据库上的交互式查询构建器创建复杂的监控仪表板，并提供交互式图表、图形和警报。 也可以设置高于或低于生成警报的阈值。

值得一提的是，我们将 MOB 和 VIS VNF 部署在位于同一本地网络上的两个虚拟机 (VM) 中。 这允许两个 VM 通过使用集成的 Grafana API 和 SQL 查询相互通信，因为 MOB 数据库与 Grafana 数据源一致。

5.3、 数据分析

我们现在描述我们使用通过我们的测试平台获得的大量数据获得的结果之一。截至 2019 年 10 月，检测事件总数为 97,728,830，对应于 51,255,486 个不同的 MAC 地址。由于 MAC 随机化，后者表示检测到的设备数量的上限。2 更详细，图图 6 和图 7 显示了连续三年（2020 年、2021 年和 2022 年）3 月份捕获的数据的比较。图 6 通过对数标度的热图描绘了每个扫描仪在不同时间的检测发生情况的一天。我们省略了扫描仪 7 中的数据，因为由于扫描仪中断而缺少一些数据。可以看到不同年份 COVID-19 限制的影响。 2020 年 3 月，严格的封锁禁止人们在户外活动，这反映在智能设备数量少上。 2021 年 3 月，限制虽然仍然存在，但变得更加宽松，因此检测到了更多设备。最后，在 2022 年 3 月，所有学校、大学和公司几乎都恢复正常，因此该图显示，试验台区域的人数增加了两倍。

图 7 显示了与以前相同的趋势，但以更综合的方式显示了在所考虑的三年中，每个扫描仪在 3 月份的总体检测情况。 正如预期的那样，这三条曲线没有重叠，但彼此之间存在差距，唯一的异常值是与扫描仪 6 相关的数据，即在 Porta Susa 火车站附近的那条，它在 2020 年检测到相同数量的设备，并且 2021 年，与 2022 年的其他扫描仪相比更多。

6、追踪移动性

在本节中，我们将介绍一种用于检测和跟踪智能设备的方法，该方法可以应用于第 5 节中描述的测试台场景。这种方法很容易应用于使用黑盒扫描仪的计数过程，就像前面提到的那样 部分，但也可以使用第 4 节中描述的自己动手解决方案。

6.1、 我们的方法

使用探测请求模式是为了将时间序列$\tau$精确定位到前面描述的扫描仪附近街道上的实际步行路径。 因此，我们的移动跟踪系统的目的是将移动设备传输并由 WiFi 扫描仪检测到的探针与最可能的路径相关联，跨越该区域中已监控的一组给定的预定义路径。 路径分类基于一些初步实验来构建真实信息，从而为每个可能的路径生成指纹向量目录。 由于该目录，新移动设备发送并由扫描仪检测到的探测序列与所有已知指纹进行比较，并选择具有最相似指纹的路径作为移动跟踪的输出，如在 下列的。

令 $P$ 是所考虑区域中要监控的一组预定义路径，并且让 𝑝 ∈ $P$ 是通用路径。 为了计算路径 𝑝 的指纹 𝑓𝑝，我们让扫描仪通过让一个人携带一个设备沿着 𝑝 走 k 步来收集探针样本。 在下文中，我们将这种设备称为“ground-truth device”，并将每次沿着𝑝行走称为“run”。

考虑以下示例（假设所有时间都以秒表示）：
$$\begin{array}{rl}& \mathcal{T}=[(0,X),(30,X),(60,X),(90,X),(100,Y),\\ & (120,X),(130,Y),(160,Y),(190,Y),(220,X)]\end{array}$$

其中 $\tau$ 可以表示如下： $\tau$ = [(𝑡_𝑖, 𝑠_𝑖)]𝑖，对于增加 $t_i$ 的值，𝑖 = 0, 1, 2…。 $\tau$ 中的通用对表示根据哪个传感器 $s_i$ 的事件 在时间𝑡𝑖检测到真实设备，$s_i\in X,Y$。 上面的表达式可以解释如下：扫描仪𝑋在时间 0、30、60、90、120、210 和扫描仪𝑌在时间 100、130、160、190 检测到地面实况设备。请注意，事件检测 以 30 秒的倍数发生，即周期性地发生在所考虑的现成扫描仪中，并且采样事件在扫描仪之间具有 10 秒的偏移。 现在，从 $\tau$ 我们设置一个路径图，定义如下：如果 $s_i=X$，\\gamma(𝑡𝑖) = 2$，如果$𝑠_𝑖= 𝑌, 𝛾(𝑡_𝑖) = 1$。 这两个值是任意选择的，完全不影响最终的分类结果。 图 8 显示了所考虑的玩具场景的路径图。

允许$\delta$是观测周期，即检测到地面实况设备的总时间间隔，$\delta =ma{x}_i{t}_i-mi{n}_i{t}_i$. 现在让我们将观察期划分为：𝑁 时间子间隔，每个持续时间𝛿∕𝑁. 尤其是𝑁 是唯一应根据建议方案进行调整的参数，稍后我们将展示𝑁 = 4产生了已经很好的结果。在玩具示例中，𝛿 = 210秒，每个子间隔持续52.5秒𝑁 = 4。

有了上面的数据，我们现在可以计算指纹$f_p$。 我们注意到这只是可以设计用于路径识别的可能指纹之一。 我们使用的指纹由 2𝑁 实数的向量表示，形式为 f p