Search code examples
iotonem2m

Communication with resources on a remote CSE - OneM2M

We are trying to implement the oneM2M standard and have a question regarding the communication process between Remote CSE and IN-CSE. I wrote what I understood from the documentation step by step in below. Some of the issues are not so clear for us so before doing any implementation, I need to make sure everything is crystal clear.

I going to ask the question before telling everything we understand from the documentation. Then I am going to write step by step what is the solution we think. The question is, the request which is sent by an IN-AE, is for MN-CSE which the IN-CSE should going to redirect the request to MN-CSE or it should handle it itself.

Before anything else, we have two absolutely separated CSEs. One is IN-CSE, the other one is MN-CSE almost like below.

IN-CSE has a resource tree

/in-cse61
   /in-cse61/csr-34
      /in-cse61/ae-1234

MN-CSE has a resource tree

/mn-cse34
   /mn-cse34/csr-61
   /mn-cse34/ae-123456
      /mn-cse34/cnt-1
         /mn-cse34/cin-01
         /mn-cse34/cin-02
         /mn-cse34/cin-03
      /mn-cse34/cnt-2

We skipped any security concern for now. Let’s say IN-AE wants to communicate with MN-CSE as we told in question above.

1- IN-AE should send a discovery or retrieve request to IN-CSE saying that get me all the child resources Remote CSE.

2- What is the exact difference between sending discovery or sending retrieve request? We thought that discovery request returns just resource uri but retrieve request returns whole data of exact resource. Is this approach correct?

3- After getting all the remoteCSEs, now I know ids of the remoteCSEs'. Then I can send a discovery request to the MN-CSE to get AEs in it. We think two options:

a. ~/in-cse61/csr-34?fu=1&rty=2
b. ~/mn-cse34?fu=1&rty=2

Option a : If IN-AE only wants to make a discovery request for IN-CSE’s resource tree, IN-CSE should take care of it without redirecting it to the MN-CSE. Because IN-CSE already knows that /in-cse61/csr-34 is kind of a valid RemoteCSE for it but the request path starts with ~/in-cse61 then it should be handled by IN-CSE.

Option b: If IN-AE wants to make a discovery request for MN-CSE’s resource tree then IN-CSE can understand it is related a RemoteCSE by looking at the /mn-cse34 part of the Request path because it doesn’t startwith IN-CSE’s resourceid.

So IN-AE(ex. Smartphone) somehow should decide which CSE should handle the request ? Is there anything we think wrong ?

---------------------EDITED--------------------------------------

enter image description here

I have inspected architecture of Application Developer Guide TR-0025 http://www.onem2m.org/application-developer-guide/architecture

According to this sample, a smartphone (IN-AE) can control Light#1(ADN-AE-1) through IN-CSE.

After Registration and Initial Resource Creation processes are completed, system is ready to discover and then control the lights.

GET /~/mn-cse/home_gateway?fu=1&rty=3&drt=2 HTTP/1.1
Host: in.provider.com:8080

Although Middle Node CSE-ID and Middle Node CSEBase name is used at HTTP Request url, host is addressed to IN-CSE. It means, the discovery request sent from IN-AE, handled by IN-CSE first then it redirects it to mn-cse. However you told me the opposite by saying “The retrieval or discovery normally is only limited to the resources of the hosting CSE, and does not traverse to the remote CSEs automatically.”.

At TR-0025 the given example is shown as common scenario. And also at TR-0034, Actually it is traversing the request as you see on the diagram.

enter image description here

Solution

  • There are many points in your question that needs to be addressed.

    First of all, there is no special entity in oneM2M named "IN-AE". This is just the name that is used for the AE that connects to the IN-CSE in oneM2M's TR-0025 : Light control using HTTP binding developer guide. An Application Entity can actually be connected to an IN-CSE or an MN-CSE by the same protocol (mca), though there might be AEs that are especially designed to work on one particular CSE.

    Regarding your point 2, the difference between a retrieve and a discovery request:
    The retrieve request is targeted at a resource to retrieve it. For example, a retrieve request sent to the Container resource /mn-cse34/cnt-1 (from your example) would retrieve the Container resource itself and its attributes.
    A discovery request is also be targeted at a resource, and technically it very much looks like a normal retrieve request. But in addition you provide filter criteria and discovery result type. For example, a discovery request sent to the same Container resource /mn-cse34/cnt-1 might return all the references to the ContentInstances from that Container resource. Depending on the filter and result type you can either get the full resources or only references to them.

    Please have a look at oneM2M's specification TS-0001 Functional Architecture, sections 10.2.6 Discovery and 8.1.2 Request for a full explanation and the list of possible parameters for the discovery request.

    Regarding points 1 and 3 of your question: I don't know what your AE wants to solve, but it should have a notion of the data structure build in. It is a good idea to organise the data in a structured and uniform way, e.g. by using Containers, FlexContainers, Groups etc. This way the application doesn't need to browse the whole resource tree of a CSE, which could become really big over time. Of course, it might be that it is a general application that needs to traverse over a bigger and prior unknown structure. In that case the application could use a discovery request to get the relevant resources. Please note, that you can also do discovery over meta-data of resources, e.g. labels, date and time etc. This might be helpful to reduce the result set.

    The retrieval or discovery normally is only limited to the resources of the hosting CSE, and does not traverse to the remote CSEs automatically. An exception are announced resources. Those resources are announced to a remote CSE where they get a kind of "shadow" counterpart, and they provide your application some information about the state of the resources as well as to how to retrieve them (via a link attribute). But if you really want to access a remote CSE and your application has permissions to do so, the pointOfAccess attribute provides you with the address of the remote CSE.

    But as said before, in general you application (AE) is connected to a single CSE. On that CSE all the resources of the AE, or the resources the AE has access to, are hosted. Also keep in mind that the AE needs to have permission (via an AccessControlPolicy) on the CSE to access the resource.

    Update

    Perhaps I need to elaborate a bit more on how to work with a remote CSE. Ignoring announced resource for now, there are two possibilities that your "IN-AE" can access a resource on the remote CSE:

    • You can send requests such as retrieve, update etc to the remote CSE resource in the IN-CSE. These requests are then forwarded to the real "mn-cse" instance by the Mcc connection between the IN-CSE and the MN-CSE. This has the advantage that the "IN-AE" doesn't need to care on how to connect to the MN-CSE "mn-cse" directly (e.g. there might be firewalls etc in place to protect the MN-CSE).
      You can see this if you look at the HTTP Request in the example of TR-0025 (http://www.onem2m.org/application-developer-guide/implementation/content-instance-retrieve)
      GET /~/mn-cse/home_gateway/light_ae1/light/la HTTP/1.1
      This receiver of the http request is the IN-CSE. But, as you can see it targets a ContentInstance at the remote CSE mn-cse.
    • If you really need to access the remote CSE directly, for example for performance reasons, then your "IN-AE" can retrieve the pointOfAccess attribute and directly access the remote CSE "mn-cse". In that case the "IN-AE" actually becomes an AE of the remote CSE "mn-cse" and needs to know how to connect to it.