This document discusses IoT Agents and their role in the IoT architecture. It covers interaction models like active attributes, lazy attributes, and commands. It also covers device and group provisioning APIs. The document outlines how to build an IoT Agent using Node.js or C++ and interfaces with the Context Broker and device protocols like OMA Lightweight M2M. It provides resources for IoT Agent frameworks and libraries.

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
} }