问题标签 [onem2m]

如果 IN-AE 使用 ADN-AE1 和 ADN-AE2 创建一组灯光，只使用一个请求来控制它们会怎样。该图显示，它使用一个请求来控制它们，但是当我单击请求示例时，它会一一创建 <contentInstances>。是否有任何示例可以仅通过一个请求来控制一组资源，或者这不在 oneM2M 的范围内？

多灯控制的调用流程如下图所示，顺序如下：

当用户在她/他的智能手机上更新一组灯光状态时，IN-AE 会创建一个新的 contentInstance，以托管在 MN-CSE 上的一组 Light ADN-AE 容器资源为目标。此处显示的请求

对于每个成功创建的 contentInstances，MN-CSE 都会向相应的 Light ADN-AE 发送通知。

---------------------- --------- 已编辑 ------------------ -------------

我们可以在表 9.6.35-1(TS-0001)中看到<flexcontainer>具有[customAttribute]和<semanticDescriptor>属性。[customAttribute]属性可以保存<flexcontainer>的值。

<semanticDescriptor>保存了一些具有关系和值的 RDF，但是我们也可以将这些值存储在[CustomAttribute]属性上，对吗？那么，为什么我们需要<flexcontainer>中的<semanticDescriptor>属性？

我们正在一个开源嵌入式操作系统（即 Mbed OS）中实施 oneM2M 标准。我们使用 Nucleo Boards 作为我们的应用程序专用节点和中间节点。由于我们需要在 MN 实现 DMR，并且由于我们使用的是受限设备，因此本地 DB 不是一个选项。是否有任何规定如何按照 OneM2M 的建议实施 DMR 功能。目前，我们正在通过 HTTP get/post 命令选择远程数据库（远程 DMR）解决方案。

在对服务订阅进行了详细研究之后，我决定开发配置应用程序来创建 CSE 和 M2MServiceSubscriptionProfile。在此应用程序中，客户可以创建自己的 CSE，其中包括支持的资源类型和 M2MServiceSubscriptionProfile，其中包括允许的 AE。

根据付款标准，将根据资源类型检查传入请求以允许或拒绝。我认为，只有一种方法可以做到这一点，M2MServiceSubscriptionProfile 将使用存储在 CSEBase 类的 SupportedResourceType 属性中的特定资源类型。这是默认方案。

但是 ServiceSubscribedNode 不必像 xsd 文档中所述包含 CSE-ID。

这意味着无需与客户 CSE 集成，AE 也可以与系统连接。例如，Web 应用程序 (AE) 可以与系统集成以使用服务提供者上的特定 API。在这种情况下，该客户没有 CSEBase，客户的 AE 可以直接与 Service Provider 连接，因此没有 SupportedResourceType 属性。

对于这种情况，我如何决定允许/拒绝特定的资源类型？

我已经在这个主题上讨论了如何在 OneM2M 中管理设备，但我注意到我仍然存在一些误解。

1. MgmtObj和MgmtCmd之间的关系。它们之间的确切相关性是什么？MgmtObj 似乎保留了当前软件或固件、电池、设备信息等状态。ObjectIds 和 ObjectPaths 用于将这些信息映射到 LWM2M、TR-0069 等设备管理标准。这是对的吗 ？

2. 我不明白为什么Node中有多个重启对象？

3. 假设我们在一个节点上有多个不同的固件。每个固件控制硬件的不同部分。然后我想我应该为每个固件创建一个 MgmtCmd，但是 MgmtCmd 如何知道它与哪个固件（MgmtObj）相关？当我们查看 OneM2M 中的资源定义时，它们之间没有联系。实际上，这指向了我的第一个问题，即 MgmtObj 和 MgmtCmd 之间的关系，因为不知何故，当 MgmtCmd 运行并完成其工作时，相关的固件应该在相关的 Node.js 中更新。

4. 假设我不打算实施任何设备管理标准，如 TR-0069、LWM2M 等。我们使用的是具有自己专有设备管理方式的 nonOneM2M 设备。那么最简单的方法是什么？

我们的想法是，我们应该将一些设备管理逻辑放到 IPE（Inter proxy entity）中，它可以订阅任何相关 MgmtCmds 中发生的所有事件，例如更新其 ExecEnabled 状态和创建 ExecInstance 等设备。然后我们应该用那个 ExecInstance 通知 IPE，然后 IPE 管理所有的过程。是否适合使用订阅/通知机制进行设备管理？

mgmtCmd资源代表一种执行管理程序或对现有管理协议（例如 BBF TR-069 [i.4]）所需的命令和远程程序调用 (RPC)建模的方法，并使 AE 能够请求在其上执行管理程序一个远程实体。它还可以取消可取消和已启动但未完成的管理程序或命令。

mgmtObj资源包含启用单个 M2M 管理功能的管理数据。它提供了映射到外部管理技术的通用结构，例如 OMA DM [i.5]、BBF TR-069 [i.4] 和 LWM2M [i.6] 数据模型。mgmtObj资源的每个实例 都应映射到单一的外部管理技术。

-------------------------------- 澄清 ----------------- ---------------

当我们查看节点的 xsd 时，它包含子资源，例如

• 固件列表
• 软件列表
• 重启列表
• ETC...

其实我只是做了一个例子，它不是真实世界的场景。我还试图理解为什么节点有多个资源，比如重启、软件，即使 deviceinfo 看起来很奇怪。他们指的是什么？

------------------------ 更多说明 ------------------------- ----

顺便说一句，关于 deviceinfo 的讨论已经有。然后我认为他们选择了每个节点多个 deviceInfo 的方式，因为当前版本的 OneM2M 支持每个节点多个 deviceInfo。我也很好奇每个节点多次重启或固件的含义是什么？

timeSeries 资源表示数据实例的容器，timeSeriesInstance 资源表示资源中的数据实例。

与 container 和 contentInstance 的主要区别在于将时间信息与数据一起保存并能够检测丢失的数据。

使用 timeSeries 和 timeSeriesInstance 资源而不是容器和 contentInstance 资源可以实现任何其他优势吗？

它是否也有助于节省数据冗余，例如，如果我的一个应用程序实例每 30 秒发送一次数据，那么在一天内将创建 24*120 contentInstance。

如果正在使用 timeSeries 和 timeSeriesInstance 资源，那么对于上述情况，是否会在一天内创建相同数量的 timeSeriesInstance（即 24*120）？

此外，是否有任何特定目的将 contentInfo 属性保留在 timeSeries 而不是 timeSeriesInstance 中（就像我们在 contentInstance 资源中有 contentInfo ）

在订阅资源中有一个名为expireCounter的属性，在 TS-0001 中有以下详细信息：“此属性（通知策略）表示订阅者希望将此订阅的生命周期设置为最大通知数的限制。当发送的通知达到此计数器的计数，订阅资源将被删除，无论任何其他策略。"

expireCounter 是否应该减少等于订阅中存在的notificationURI的数量以及接收者成功接收到通知的次数？

例如：a 有 4 个notificationURI，expirationCounter设置为 100。当事件发生时，2 个 URI 成功接收到通知，而 2 个notificationURI无法到达。

在这种情况下， expirationCounter的值是多少？

我的用例如下：我有数百个（如果不是数千个）AE 订阅了其他 1 个在容器上发布传感器数据的 AE。这些 AE 中的每一个都具有相同的 POA。问题在于，对于每个传感器数据，相同的通知在 MQTT 中仅发送给一个订阅者：1 个新 CIN 触发 1000 个通知。在 oneM2M 规范中是否可以将所有这些通知聚合为一个，并且每个订阅的 AE 都可以收听相同的主题并接收相同的通知？

它看起来像组和“notificationForwardingURI”可能是我正在寻找的；但在阅读了 TS0001 10.2.7.11 和 10.2.7.12 之后；和表 9.6.8-2 我不确定它是否能回答我的问题。

oneM2M 中有许多具有嵌套属性的复杂资源，例如订阅、组等。

如果发送 UPDATE 请求来更新资源的嵌套属性eventNotificationCriteria>missingData>number，subscription那么所有其他现有的 eventNotificationCriteria（如果存在）应该保持不变，包括durationinmissingData并且只number应该更新。

这是应该如何处理嵌套属性 UPDATE 吗？

在 TS-0001 第 12 章“信息元素记录”中描述了触发器（例如 Mcc/Mca 或任何其他接口上的请求）。在第 12.2.2 节“离线计费记录信息的过滤”中，描述了如何从记录信息中获取计费信息，这意味着计费数据是从 IER 中获取的。

在第 10.2.11.14 节中，描述了“服务统计收集记录”。

有3个问题：

首先， 和 之间是否存在相关Service Statistics Collection record性IER？看起来服务统计收集记录是 IER 的子集，基于资源eventConfig和statsCollect资源。如果它是一个子集，则 IER 中没有映射到“collectingEntityID”的字段，因为它Service Statistics Collection Record是对应于“collectingEntityID”的派生的。

其次，没有关于计费数据记录（CDR）的描述。它被描述为 IER 的子集。结果statsCollect，Service Statistics Collection Records生成。何时会生成 CDR？

第三，和CDR之间没有链接Service Statistics Collection record，都需要在Mch接口上传输。