Introducing the IPSO Alliance – IP Smart Objects

The IPSO Smart Object:

Currently, OMA LWM2M is a common device management mechanism provided by Open Mobile Alliance. The object model in OMA LWM2M is reused to define application level IPSO Smart Object. An IPSO Smart Object is a collection of reusable resources that has a well-known object ID and represents a particular type of physical sensor, actuator, connected object or other data source.

The IPSO Application Framework:

The IPSO Application Framework specifies a simple and efficient RESTful design model for IP smart objects to represent its available resource under HTTP, REST, XML, JSON, COAP mechanisms. The most important advantage of this framework is to increase interoperability among a number of devices.

1. Function Sets:

Function set is groups of resource type. Each function set has:

• Path template: is the path to access resources on webserver. The index {#} allows for multiple instances of this type of resource (e.g. a GET on /sen would return a SENML payload with the value of all the sub-resources of /sen)
• Resource Type: define the value in “rt=” field of the CoRE Link Format when describing a link to this resource. This value make resoures possible to discover.
• Interface Description: This parameter defines the REST interface for type of resource. It may be elided from link description of resource types.
• Data Type: The Data Type field defines the type of value that is returned in response to a GET of that resource and accepted with a PUT

2. Interaction Model:

Each smart object acts as a simple webserver (HTTP or CoAP) and provides resources that conform to this framework. Other smart objects or backend service can act as a client to interact with those smart object. Observation method is highly recommended when there is a need for continuous readings from a resource.

3. Discovery:

Those resources are discovered by accessing on the path /.well-known/core as defined in [I-D.ietf-core-link-format]

4. Example:

The following examples make use of this resource design.

</dev/mfg>;rt=”ipso.dev.mfg”,

</dev/ser>;rt=”ipso.dev.ser”,

</dev/mdl>;rt=”ipso.dev.mod”,

</pwr/0/w>;rt=”ipso.pwr.w”,

</pwr/0/kwh>;rt=”ipso.pwr.kwh”,

</pwr/0/rel>;rt=”ipso.pwr.rel”,

</pwr/1/w>;rt=”ipso.pwr.w”,

</pwr/1/kwh>;rt=”ipso.pwr.kwh”,

</pwr/1/rel>;rt=”ipso.pwr.rel”,

</gpio/btn/0>;rt=”ipso.gpio.btn”,

</lt/led0/on>;rt=”ipso.lt.on”,

</sen/temp>;rt=”ucum.Cel”;obs,

</sen/co2>;rt=”ucum.ppm”

We perform some execution on this resources:

• Get manufacture of device

Req: GET /dev/mfg (Accept: text/plain)

Res: 2.05 Content (text/plain)

Body: IPSO Alliance

• Get device serial number

Req: GET /dev/ser (Accept: text/plain)

Res: 2.05 Content (text/plain)

Body: 3450232

• Get device model.

Req: GET /dev/mdl (Accept: text/plain)

Res: 2.05 Content (text/plain)

Body: SuperPlug300

• Observe to push a new value of temperature sensor from the server to client whenever resource changes.

Req: GET /sen/temp (Accept: text/plain) (Observe:0)

Res: 2.05 Content (text/plain) (Observe:0)

Body: 23

Res: 2.05 Content (text/plain) (Observe:1)

Body: 23.5

Res: 2.05 Content (text/plain) (Observe:2)

Body: 24

Res: 2.05 Content (text/plain) (Observe:3)

Body: 24.6