Slides of the second part of the presentation of the IoT Agents in Madrid's Fiware Developers Week.

1. IoT Agents (Advanced)
OMA Lightweight M2M
Contact email
daniel.moranjimenez@telefonica.com
(Reference Orion Context Broker version: 0.19.0)

2. • IOT Agents
• Interaction models
• Provisioning APIs
• IOT Agent development
Outline

3. IOT Agents
• IoT Architecture
http://bit.ly/iotArchitecture
• Motivation:
– Modular approach
– Deployment flexibility
– Custom IOT Agents
• NGSI Bridge
– Constrained set of interactions
– One entity per device
• Provisioning of devices and group of devices
• Additional services (e.g.: security, device registration,
stats)

4. Interaction models: Active Attributes
IOT Agent
DB
Device
Protocol
NGSI
Entity information
Interaction
begins

5. Interaction models: Lazy Attributes
IOT Agent
Device
Protocol
NGSI
Entity
information
Interaction
begins
Requires the IOT Agent to be
registered as a Context Provider
Completely synchronous model

6. Interaction models: Commands
IOT Agent
Device
Protocol
NGSI
Command
Execution
Interaction
begins
Result Information
Requires the IOT Agent to be
registered as a Context Provider

7. Device Provisioning: Models
7
Context Broker
IoT Agent
Thinking Things
NGSI
HTTP (2G)
IoT Agent
Thinking Things
Context BrokerApp Backend
Configuration APIDevice Provisioning API

8. Device Provisioning: Device Provisioning API
{
"name": "Light1",
"entity_name": "TheFirstLight",
"entity_type": "TheLightType",
"attributes": [
{
"name": "attr_name",
"type": "string"
}
],
"lazy": [
{
"name": "luminance",
"type": "lumens"
}
],
"commands": [
{
"name": "commandAttr",
"type": "commandType"
}
]
}
• /iot/devices/:deviceId
• REST CRUD:
– POST
– GET
– DELETE
– PUT
• Service headers:
– Fiware-service
– Fiware-servicepath
• Mandatory
– Name
– Entity_type
• Internal_attributes

9. Device Provisioning: Configuration API
{
services: [
{
resource: '/deviceTest',
apikey: '801230BJKL23Y24HV8732',
type: 'Light',
trust: '8970A9078A803HAMS’,
commands: [],
lazy: [
{
name: 'luminescence',
type: 'Lumens'
}
],
active: [
{
name: 'status',
type: 'Boolean'
}
]
}
]
}
• /iot/agents/default/servi
ces
• Not exactly REST (check
doc)
• Service headers:
– Fiware-service
– Fiware-servicepath
• Mandatory
– Resource
– Api_key
– Type

10. Security
• North bound: using PEP Proxies
• South bound: IOTAgent specific
• Use of trust tokens for communicating with other GEs
IOT Agent
PEP Proxy
PEPProxy
Keystone

11. Building an IoT Agent: Overview
• Frameworks: Node.js and C++
• North bound features provided by the platform:
– NGSI Context Provision server
– NGSI Client
– Device Provisioning API
– Configuration API
• All South bound features are protocol specific
– External library
– Ad-hoc development

12. IOT Agent
Building an IoT Agent: Node.js
• Device registry (in-memory or MongoDB)
• Group Registry (in-memory or MongoDB)
• Module provided in NPM Registry:
– Add it to your package.json
– Require it as any other module
Context Server
NGSI Client
Device
Protocol
Device
Regitry
Group
Regitry
Provision Server

13. Building an IoT Agent: Node.js
• Handlers
– setDataQueryHandler()
– setDataUpdateHandler()
– setConfigurationHandler()
– setCommandHandler()
• API Operations (most important)
– Activate()
– Deactivate()
– Register()
– Update()
• Registry operations
– listDevices()
– getDeviceByName()

14. Building an IoT Agent: Node.js
• Available IoT Agents
– OMA Lightweight M2M
– Sigfox
– Thinking Things Closed

15. Exercises
• Suggestion: deploy your local IOT Agent.
• Alternative: workshop IOTAgent
– IP: 130.206.80.48
– Port: 9500
• Exercise descriptions (and this presentation) in SlideShare
• Prerequisites:
– Rest clients
– Node.js (environment)
• Nice to have:
– Node.js programming skills

16. Resources
• Github Projects:
– Node.js IOT Agent framework
https://github.com/telefonicaid/iotagent-node-lib
– C++ IOT Agent framework
https://github.com/telefonicaid/fiware-IoTAgent-Cplusplus
– Node.js LWM2M Library
https://github.com/telefonicaid/lwm2m-node-lib
– LWM2M IOT Agent
https://github.com/telefonicaid/lightweightm2m-iotagent
• IoT Architecture
http://bit.ly/iotArchitecture
• COAP
https://tools.ietf.org/html/rfc7252
• Lightweight M2M
http://openmobilealliance.org/about-oma/work-program/m2m-enablers/

17. BACKUP SLIDES
Backup slides
17

18. OMA Lightweight M2M
• Based on COAP:
– UDP
– Lightweight payload
– REST Oriented
• Interfaces:
– Bootstrapping
– Client registration
– Device management
– Information reporting
• Object model
– Based on Object and Resource hierarchy (e.g.: /1/12/3)
– OMA Registry

19. OMA Lightweight M2M: operations
LWM2M
Client
LWM2M
Server
Register (host, port, endpoint, url)
Read /3304/0/5
Write/3304/0/5
Observe /3304/0/5
Notify /3304/0/5

20. Lightweight M2M IOT Agent
• Github project
https://github.com/telefonicaid/lightweightm2m-iotagent
• Work in progress
• Quickstart guides
• OMA Registry mapping
– Default lazy mapping for attributes not declared
– Attributes can be declared as active using the resource name
– Custom mappings by type using Device Provisioning API:
"internal_attributes": {
"lwm2mResourceMapping": {
"TheTemperature" : {
"objectType": 34000,
"objectInstance": 0,
"objectResource": 5
} }