亚马逊云科技 上的下一代 CPE 命令和控制架构

通信服务提供商 (CSP) 管理数百万个 CPE（客户驻地设备），例如宽带路由器、Wi-Fi 网关等。传统上，这些设备中的大多数都是按照宽带论坛的 TR-069（CPE WAN 管理协议或 CWMP）等标准进行管理的。但是，尽管 TR-069 对基本管理和配置有效，但它在反馈速度和可扩展性方面存在缺陷。鉴于这些限制以及对增强型实时设备管理的需求不断增长，许多 CSP 正在迁移到宽带论坛的 用户服务平台 (USP) 或 TR-369。 USP 是一种更现代的标准，具有更快的反馈回路、更高的可扩展性以适应激增的连接设备、改进的安全机制以及通过其多控制器支持灵活支持下一代服务和应用程序等优势。随着CPE生态系统的扩展和客户需求的发展，采用USP等标准对于CSP确保最佳的服务交付和客户体验至关重要。

传统上，通信服务提供商在其 CPE 中加入 TR-069 代理，而向更新 TR-369 (USP) 的迁移路径并不统一。尽管某些提供商热衷于完全过渡到 TR-369 堆栈，但其他提供商认为在 CPE 上维护其 TR-069 代理是有价值的，尤其是对于特定的命令和控制用例。值得注意的是，这些用例通常与固件升级和速度测试等任务有关。采用这种双重方法的一个主要原因是，TR-069 在这些特定功能上具有坚固耐用性和久经考验的可靠性。另一个重要的考虑因素是 TR-069 ACS（自动配置服务器）与现有运营支持系统 (OSS) 和业务支持系统 (BSS) 的深层集成，这会使迁移变得既耗时又昂贵。通过保留特定的 TR-069 功能，CSP 可以确保更顺畅的过渡期，在采用 TR-369 功能的同时，利用久经考验的方法。尽管这些标准为CPE管理奠定了基础，但云技术的出现也为CPE管理提供了全新的视角。

在这篇文章中，我深入探讨了多种类型的命令和控制架构的细节，重点是利用 亚马逊云科技 IoT Core 优于 MQTT 的强大功能 来有效 管理 CPE 设备。我将探索各种配置，从 TR-069 和 TR-369 代理和谐共存的 CPE 到采用成熟 USP CPE 的设置。此外，我还谈到了通过 亚马逊云科技 IoT Gre engrass 利用边缘处理的高级架构。这同时将控制器放置在边缘设备和 亚马逊云科技 区域 ，展示了当代设备管理固有的活力和灵活性。

架构

在本节中，我列出了一些可能的 CPE 命令和控制架构，并讨论了它们的设计原理以及它们如何与上述工具和标准进行交互。

架构 1：CPE 上的自定义代理

图 1 — CPE 上的自定义代理

在此架构中（如上图所示），驻留在 亚马逊云科技 云中的应用程序使用 亚马逊云科技 IoT 开发工具包与 亚马逊云科技 IoT Device Shad ow 服务 进行通信 。 阴影充当设备的虚拟表现形式或 “影子”，可捕获其所需状态和报告状态。应用程序可以修改该影子中的所需状态，而实际设备（或其代理）与此状态同步，相应地更新影子的报告状态。该框架不仅促进了对分散的 CPE 的集中指挥和监控机制，而且还减少了应用程序等待有关其当前状态的 CPE 响应的需求。尤其是在处理较慢的 CPE 时，等待这些响应可能会对应用程序的用户体验产生不利影响。与阴影交互提供了一个快速的替代方案。尽管最终达到了所实现的一致性，但对于一定程度的数据过时性是可以接受的，这还是有好处的。因此，这种安排可确保更具响应性的交互，从而使众多用例受益。

CPE 数据模型的复杂性质要求分段表示。因此，设备的全部详细信息并未记录在单个影子文档中。取而代之的是，数据被分成不同的命名影子，例如 IP、以太网和 Wi-Fi。这些阴影与 TR-181 框架中的特定模块或部分相似，例如 “WiFi 数据模型” 或 “以太网数据模型”。其中每一个都代表一个专门的职能领域，确保采用符合宽带论坛指导方针的标准化方法。

CPE 元数据管理

除了阴影，每台 CPE 设备都被抽象为 亚马逊云科技 IoT Core 中的 “事物” 对象。该对象错综复杂地链接到设备的 X.509 证书及其相应的影子，并以事物类型和属性的形式存储有关 CPE 的元数据。上图显示了选择 CPE 序列号作为事物名称的示例配置。

设备端架构和数据流

在 CPE 设备中，自定义代理与传统 CWMP 代理协同工作。该代理通过利用 亚马逊云科技 IoT 设备软件开发工具包 和 亚马逊云科技 IoT Core 为其相关 “事物” 提供的证书，充当设备和云之间的桥梁。它的主要作用是确保设备与其阴影中指定的所需状态保持一致。

在幕后，代理订阅了保留的影子话题，以随时了解三角洲事件。亚马逊云科技 IoT Device Shadow 服务持续监控影子的预期状态和报告状态之间的差异（并非相反）。检测到差异后，该服务会计算出差值并将其广播到订阅设备代理的保留主题。该设备在收到此增量后，会通过直接的低级通信或使用诸如RDK-B之类的中间件来整合变化。在此配置更新之后，设备使用 MQTT 将其报告的状态传达给另一个保留主题。

必须强调的是，尽管 亚马逊云科技 设备开发工具包有助于管理连接并提供影子交互方法，但自定义代理必须确保影子文档符合 亚马逊云科技 IoT 规定的结构。

架构 2：CPE 上的 USP 代理

图 2 — CPE 上的 USP 代理

在前面详述的 “CPE 上的自定义代理” 架构建立的基础上，该架构引入了一种独特的设备端方法，同时保留了应用程序与 亚马逊云科技 IoT Shadows 的交互。

此模型在 CPE 设备上使用原生 USP 代理。与之前的设置不同，这种安排在设备上没有任何直接的 亚马逊云科技 组件，除非设备证书由 亚马逊云科技 IoT Core 生成。尽管在上图所示的架构图中可能不明显，但必须注意的是，这个 USP 代理仍然可以与传统的 TR-069 代理共存。USP代理的开发主要有两种方式：从头开始开发，遵守USP标准，或者利用宽带论坛的 开放宽带用户服务平台代理（OB-USP-Agent） 作为基础层，随后在其之上构建其他功能。

设备端架构和数据流

与第一个架构类似，亚马逊云科技 云中的应用程序与 亚马逊云科技 IoT Device Shadow 服务进行交互。这样可以保持设备的期望状态和报告状态。

影子发生变化或更新时，亚马逊云科技 IoT 会计算增量，这实质上描述了所需状态和报告状态之间的差异。此计算出的增量被分派到保留的增量主题。持续监控此主题的 亚马逊云科技 IoT 规则拦截增量信息并调用指定的 亚马逊云科技 Lambda 函数，向其提供影子 增量数据。

然后，Lambda 函数的责任是提取负载，将其转换为 USP 设置消息，然后使用 USP 的协议缓冲区 (Protobuf) 架构对其进行编码。编码为 Protobuf 后，Lambda 函数会将 USP 有效负载分发到 CPE 订阅的命令主题。

收到命令后，CPE 使用前面讨论的机制进行配置更改，并以 SetResp 消息对指定的响应主题进行响应。此 SetResp 消息会立即被另一条 亚马逊云科技 IoT 规则拦截，该规则将其引导到关联的 Lambda 函数。

在此架构中， 还使用了 亚马逊云科技 IoT Core 规则引擎 的一项新功能 。该功能没有将 Protobuf 解码任务强加给 Lambda 函数，而是授权规则引擎对 USP Protobuf 进行解码。因此，Lambda 函数仅接收封装 setResp 消息的 JSON 负载。此负载更易于处理，兼容性更好。Lambda 的主要角色过渡到将此 JSON 消息转换为所需的影子文档格式，然后更新相关的影子对象。这种经过重新设计的程序提高了效率，为更灵活的设备管理系统铺平了道路。

架构 3：实时 RPC（远程过程调用）

对于需要实时响应的操作，例如当操作人员诊断连接问题时，当紧急安全补丁需要立即应用时，或者对于其他特定的应用程序用例，影子机制提供的最终一致性可能不足。在这些情况下，实时 RPC 架构介入，提供了一种更直接、更直接的与 CPE 设备的交互方式。

在实时 RPC 架构中，亚马逊云科技 IoT Core 充当中央代理。亚马逊云科技 IoT Core 的规则引擎使用前面提到的高级功能转换传入的 Protobuf 消息，将其转换为 U SB 的 JSON 格式，然后将其发布到应用程序主题。这可确保运营团队或任何与 CPE 交互的应用程序以熟悉且易于解释的格式接收数据。

另一方面，当必须向CPE设备发送指令时，应用程序只需要制定获取和设置USP负载即可。然后，指定的 Lambda 函数负责将其转换为适合设备的 Protobuf 格式。应用程序将继续关注 GetResp 和 SetResp 的响应，确保无缝的双向通信。

在增强这种直接架构时，可以集成其他功能，例如 “允许的操作” 检查。在将命令转发到设备之前，可以在云端进行验证，以确定控制应用程序是否拥有执行该特定操作的必要权限。可以在不增加设备负担的情况下强制执行其他标准，例如时间限制或应用程序用户 ID 验证，从而确保稳健而安全的操作。

架构 4：边缘和 亚马逊云科技 区域的 USP 控制器

到目前为止，我们的讨论都集中在区域架构上，控制器（和相关应用程序）位于亚马逊云科技区域内。尽管该模型可以有效解决大多数用例并且具有成本效益，但某些场景需要边缘处理。以下是突出边缘处理需求的说明性情况：

1。设备断开连接的情况： 如果互联网连接 中断，亚马逊云科技 区域中依赖控制器业务逻辑的操作就会停止。这给家庭安全或紧急医疗警报等关键用例带来了挑战，在这些用例中，即时通信至关重要。

2。高数据量和低延迟场景： 考虑诸如Wi-Fi优化之类的用例。为了优化本地网络，需要在短时间内收集大量的遥测数据，因此需要快速调整网络参数以保持最佳的用户体验。由于延迟敏感的命令和控制场景，通过互联网传输命令可能不可行，而在该地区收集精细的遥测数据在财务上可能不切实际。

3。低速设备场景： 在 CPE 端带宽受到限制的情况下，边缘处理可以降低非用户流量导致的带宽利用率。

为了应对这些挑战，可以战略性地在边缘设备上部署 亚马逊云科技 IoT Greengrass。

亚马逊云科技 IoT Greengrass 是一款将云功能扩展到本地设备的软件。这使设备能够在更接近信息源的地方收集和分析数据，自动对本地事件做出反应，并在本地网络上安全地相互通信。

在此架构设计中，亚马逊云科技 IoT Greengrass 安装在 CPE 设备上，其 MQTT 代理和 MQTT 桥接器组件均安装在 CPE 设备上。边缘 MQTT 代理可促进设备到设备和设备到边缘的应用程序通信。这意味着边缘控制器可以与任何链接到 MQTT 代理的设备通信。重要的是，USP Agent 是连接到该本地代理的设备之一，它允许在边缘创建简化的应用程序。然后，这些应用程序可以绕过复杂的低级设备通信或中间件互动，例如使用 RDK-B 的通信或中间件，转而通过 USP 代理通过 MQTT 进行通信。

利用 亚马逊云科技 IoT Greengrass 平台，控制器，无论是设计为容器还是 Lambda 函数，都可以直接部署在边缘。此外，他们的整个生命周期管理可以从该地区进行协调。

有了本地 MQTT 通信，这些边缘控制器可以选择通过 USP 标准定义的 “批量数据收集” 机制从 USP 代理本地收集遥测数据。这样就无需在设备外传输大量数据。然后，这既可以实现快速处理，又可以提高成本效益。

由于代理商通过 MQTT Bridge 组件与 亚马逊云科技 云的连接，区域控制器应用程序保留了通过 MQTT 与边缘控制器（或直接与 USP 代理）通信的能力。这种二元性为应用程序开发人员提供了极大的灵活性，使他们能够根据特定的用例放置应用程序，如下图所示。

图 3-边缘和 亚马逊云科技 区域的 USP 控制器

尽管该架构本身并不依赖影子组件，但请注意，如果特定用例需要，可以对其进行无缝扩展以纳入阴影功能。

请注意，亚马逊云科技 IoT Greengrass 平台带来了额外的系统要求，这些要求可以在 亚马逊云科技 文档中找到。 在实施全舰队实施之前，您应该检查 CPE 上的可用系统资源。

结论

在这篇文章中，我展示了可以在 亚马逊云科技 上无缝实施的各种 CPE 命令和控制架构。此外，我还探讨了 TR-069 和 TR-369 架构如何在混合环境中共存，以适应不同的代理部署选项。

亚马逊云科技 使您能够根据您的 CPE 机群的独特要求创建自己的命令和控制架构。此外，亚马逊云科技 IoT Core 提供的灵活性允许您设计和部署本文中可能未明确讨论的定制架构。除此之外，亚马逊云科技 还简化了构建强大的遥测数据收集架构的过程。要深入了解如何使用 亚马逊云科技 将 TR-069 批量数据转换为切实可行的见解，您可以阅读以下文章： “使用 亚马逊云科技 上的 亚马逊云科技 IoT Core 和分析服务将 TR-069 批量数据转化为见解”。

您也可以访问 亚马逊云科技 for Telecom ，了解 CSP 如何重塑与 亚马逊云科技 的通信。