1

Suppose an AE uses CoAP to register with a CSE (AE Create request). The CSE receives the request, creates the AE resource, and sends the response in an ACK. The ACKs are lost, and the AE cancels its request by virtue of a timeout or restart, and then transmits a new Create request. Since a matching AE resource exists (assuming AE-ID or resourceName attributes are included in the request), should the CSE return CONFLICT? If so, the registering AE will only see a CONFLICT response, never having received a SUCCESS response to its registration request. Is there a better way? If the CSE considers the sender authenticated, should it simply send an CREATED response with the existing AE resource content?

bgreen0
  • 65
  • 6

2 Answers2

1

There are different strategies in oneM2M. The best practice in such a case (assuming that the AE runs on a constrained device and is using therefore CoAP) could be that not the AE registers itself but a management system does this for the AE, and perhaps create the whole data structure beneath it.

If, however, this is not possible or convenient to do, this might not be a big problem. Let's take the scenario you described:

  • The AE registers itself (not with "C", but with a fixed AE-ID), and the registration is successfully done by the CSE, but the response is lost. In this case the <AE> resource is present in the CSE's resource tree, but the AE doesn't know about this.
  • After some time the AE will send another registration request, but since an <AE> resource with this AE-ID is already present in the resource tree the CSE will respond with an "ORIGINATOR_HAS_ALREADY_REGISTERED" response (not CONFLICT). Let's assume this error response will be received this time by the AE.

So, is this really a problem? I think it is not because the used AE-ID is uniquely assigned/known to the AE (if running in a managed deployment). If an <AE> resource exists with this AE-ID it can safely assume that this is its "own" <AE> resource and continue with its normal operation.

Andreas Kraft
  • 3,754
  • 1
  • 30
  • 39
  • Thanks. Our initial implementation was based in v2.7 which did not yet have the ORIGINATOR_HAS_ALREADY_REGISTERED response code. I'm not sure what it would look like for the management system to perform registration on an AE's behalf. Since this is an MN-CSE, I think that would require a separate non-onem2m provisioning protocol? – bgreen0 Jul 03 '23 at 22:50
  • To clarify a specific use case, an example is an MN-CSE running on a device with network connectivity to the IN-CSE. A 3rd-party device with an ADN-AE joins a wireless network hosted by the MN-CSE and its ADN-AE registers with the MN-CSE. – bgreen0 Jul 03 '23 at 22:57
  • I agree that if the AE-ID is included in the AE Create request, then this is not such a problem. But what if it is not included? The spec only says that the response will be "ORIGINATOR_HAS_ALREADY_REGISTERED" if a matching AE-ID already exists. If the AE-ID is not included in request ('from' is empty or just 'C'), my impression is that the CSE would return CONFLICT if the request included a resourceName which conflicted with an existing one. But if resourceName is not included, it would register the same AE again, allocating a new AE-ID to it. A stale AE resource would be left behind. – bgreen0 Jul 03 '23 at 23:50
  • It is correct that if one doesn't provide a resourceName then the CSE assigns one. However, for an <AE> the resourceID is the same as the AE-ID, which means its "ri" is known and the <AE> resource can be detected and addressed. When one assigns an "rn" that already exists, then CONFLICT is the correct error status. However, an <AE> can only be registered once with the same AE-ID. If one does try to so again, then ORIGINATOR_HAS_ALREADY_REGISTERED is returned. – Andreas Kraft Jul 04 '23 at 07:49
  • Regarding pre-setup: Your scenario is a very typical one. But since CoAP could be more unreliable than others, one idea could be that the and its resource structure is created by another (management) on the MN-CSE. This removes the burden from the CoAP-connected AE from the registration and setup process. All it has to do is to, for example, send to the preconfigured structure. Also, this makes security much easier, because the originator can be associated with the correct credentials. – Andreas Kraft Jul 04 '23 at 07:54
  • This idea of pre-setup is an interesting one. Do you know if this is commonly done? Are there examples (implementation or simply descriptive) of an approach like this that you know of? – bgreen0 Jul 05 '23 at 18:16
  • Not yet, unfortunately. We have planned to write a blog post to explain this, but things got in the way so far. It is basically a template set-up that that a management system can do individually for devices. Usually field devices are very limited in their capabilities to determine the overall system state, so the responsibility of an initial setup should be with another entity that is more capable to make those decisions. – Andreas Kraft Jul 06 '23 at 07:11
0

That has been discussed in LwM2M years ago. If a server depends on the reliable transmission of the response, a piggybacked response isn't the best way. Using a a separate CON response does a better job but comes with more traffic.

Using a CON request with an piggybacked ACK response works only a very tiny bit less. Usually the CON request is retransmitted, if the ACK is missing. The reduced the issues to a very low probability.

Overall, the upper layer communication should not be designed without a way to do something again.

Achim Kraus
  • 729
  • 1
  • 7
  • 11
  • I edited my original post to clarify, the issue isn't specifically a missed ACK, since CoAP handles duplicate requests by matching the message ID. The issue is with the less common scenario where a client loses connectivity or otherwise loses its state and must initiate a new request – bgreen0 Jul 03 '23 at 23:02
  • Therefore I wrote, that an upper layer communication should not be designed without a way to do something again ;-). – Achim Kraus Jul 05 '23 at 04:44