|
| Re: DA subscribe DATA on another GSCL [message #1690551 is a reply to message #1690295] |
Sat, 28 March 2015 16:39   |
 Mahdi Ben Alaya
Messages: 229
Registered: November 2013 |
Senior Member |
|
|
Hello Yi-Lan,
First of all, I recommend you to download or clone the last version of OM2M. (All third libraries are now validated by Eclipse)
There is 3 solutions to enable a device under GW2 to subscribe DATA registered on GW1:
Solution 1:
Create the subscription using the public IP address of GW2.
Solution 2:
Create the subscription using an Application Point of Contact (APoC) URI.
Let's suppose that your device is listening at http://192.168.20.3:1400/dev-path
a) Create an application resource for your device under GW2 with "http://192.168.20.3:1400" as APoC (without the "/dev-path" portion).
Application representation example:
<om2m:application xmlns:om2m="http://uri.etsi.org/m2m" appId="DEV_ID">
<om2m:aPoCPaths>
<om2m:aPoCPath>
<om2m:path>http://192.168.20.3:1400</om2m:path>
</om2m:aPoCPath>
</om2m:aPoCPaths>
</om2m:application>
b) Subscribe your device Application to the DATA under GW1. Use the relative URI of the Application + /dev-path portion as Contact URI (e.g. please contact /GW2_ID/applications/DEV_ID/dev-path) .
Now, once a new data is created under GW1, it will be dynamically re-targeted from GW1 to NSCL, then from NSCL to GW2, then from GW2 to your device at http://192.168.20.3:1400/dev-path.
Solution 3:
Create the subscription using a container relative URI as follows:
a) Create a local container called "NOTIF" under GW2.
b) Subscribe your device, which is under GW2, to this local "NOTIF" container (e.g. please contact http://192.168.20.3:1400/dev-path)
c) Subscribe the "NOTIF" container to the DATA under GW1. Use the relative URI of the "NOTIF" container as Contact URI (e.g. please contact /GW2_ID/applications/DEV_ID/containers/NOTIF/contentInstances) .
Now, once a new data is created under GW1, it will be re-targeted from GW1 to NSCL, then from NSCL to GW2. This latter will create the data under NOTIF container, and so your device will be notified.
You can use the http server example (monitor) available on the following tutorial to test your scenario: https://wiki.eclipse.org/OM2M/REST_API#Subscribe_to_MY_SENSOR_data
Hope this can help.
[Updated on: Sun, 29 March 2015 00:24] Report message to a moderator |
|
|
|
| Re: DA subscribe DATA on another GSCL [message #1691655 is a reply to message #1691395] |
Wed, 08 April 2015 18:32 |
Mahdi Ben Alaya
Messages: 229
Registered: November 2013 |
Senior Member |
|
|
Hello David,
No, this is not a significant difference between SmartM2M and OneM2M architectures. In fact, solution 1 is not explicitly defined in SmartM2M, but we decided to tolerate it in OM2M to offer more flexibility and choices to developers.
Main differences between the two architectures are:
OneM2M defined a new node called MN-CSE (Middle Node CSE) also called Transit-CSE for multi-hop communications. So, a more advanced routing mechanism is required here to re-target the request from a node to another.
In addition, OneM2M introduced two new types of requests called "Non blocking Synchronous Request" and "Non Blocking Asynchronous Request".
A new interface called mcn is also defined to handle the communication between a CSE and an Underlying Network.
MQTT communication binding is provided.
LightweightM2M device management is supported as well.
Have a good day
[Updated on: Wed, 08 April 2015 18:33] Report message to a moderator |
|
|
| Re: DA subscribe DATA on another GSCL [message #1691671 is a reply to message #1691655] |
Wed, 08 April 2015 22:59 |
David Antliff
Messages: 10
Registered: April 2015 |
Junior Member |
|
|
Mahdi Ben Alaya wrote on Wed, 08 April 2015 18:32No, this is not a significant difference between SmartM2M and OneM2M architectures. In fact, solution 1 is not explicitly defined in SmartM2M, but we decided to tolerate it in OM2M to offer more flexibility and choices to developers.
Main differences between the two architectures are:
OneM2M defined a new node called MN-CSE (Middle Node CSE) also called Transit-CSE for multi-hop communications. So, a more advanced routing mechanism is required here to re-target the request from a node to another.
In addition, OneM2M introduced two new types of requests called "Non blocking Synchronous Request" and "Non Blocking Asynchronous Request".
A new interface called mcn is also defined to handle the communication between a CSE and an Underlying Network.
MQTT communication binding is provided.
LightweightM2M device management is supported as well.
Thanks for your response, Mahdi. In one routing experiment, we attempted to register a GSCL with another GSCL to create a longer chain, but ran into problems with this - I suppose this is explained by the lack of multi-hop support as you say.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03769 seconds
] 
Search
Help
Register
Login
Home
