In the context of oneM2M spec, is there a way to 'discover' the IP of the MN-CSE?

34 views Asked by At

Following the standard architecture:

ADN --- MN-CSE -- IN-CSE

and when programming the App in the ADN and using the HTTP/REST interface of MN-CSE, does the oneM2M provides any mean to get/discovery the IP of the MN-CSE? Should we "burn" the MN-CSE's IP in the app code? What if MN-CSE IP changes?

During the test stage I have been using static IP but it seems not a good option. Should we create or use out-of-oneM2M mechanism to get the MN-CSE IP or does the oneM2M spec provides it? To the best of my knowledge, it does not provide that mechanism.

1

There are 1 answers

0
Andreas Kraft On

For the registration of an entity (ie. a registree) with another entity (ie. a registrar), e.g. an MN-CSE to an IN-CSE or an ADN / AE to an MN-CSE, the registree needs to know the IP address of the registrar in advance. Unfortunately, there is no build-in discovery mechanism in oneM2M itself. This is not an oversight, because discovery really depends on individual deployments, and there are also many discovery technologies and other possibilities one may install and use.

Some of the options are:

  • Pre-shared address, identity and credentials, e.g. via configuration or smart card / SIM
  • Central directory service
  • Network provided address information, e.g. via an APN or RADIUS server

In general, pre-shared information are easy, but one need to consider the security implications here as well, such as leaking of auth informations etc. The more network-based options are also supported through the network reference point (Mcn).

You also may have a look at TS-0003 (Security Solutions) for the authentication procedures necessary and TS-0022 (Field Device Configuration) for further configuration options.

Should we "burn" the MN-CSE's IP in the app code? What if MN-CSE IP changes?

If possible you may use host and domain names instead. This way, you are independent from IP-address changes. Or again, use a (for example, RADIUS) server that provides your device with current informations.

One more thought: Another possibility is to not use direct (http) communication, but decouple this a bit by using MQTT as a transport protocol. Sure, the device needs to know the address and credentials in advance as well (using one of the above methods), but at least it can be expected that the address of a broker changes less often.