This document provides an overview of IoT Agents and the OMA Lightweight M2M IoT Agent. It discusses interaction models between IoT Agents and the Context Broker, including active attributes, lazy attributes, and commands. It covers device and service provisioning APIs. It also outlines typical IoT scenarios and describes building custom IoT Agents using Node.js or C++ frameworks. Resources listed include Github projects for IoT Agent libraries and the Lightweight M2M IoT Agent.

1. IoT Agents (Advanced)
OMA Lightweight M2M
Contact email
daniel.moranjimenez@telefonica.com
(Reference Orion Context Broker version: 0.21.0)
http://bit.ly/fiware-iotAgents-lwm2m

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

3. FIWARE (IoT) Target: Developers
Context
Broker
App Logic
@FIWARE-Cloud
Desktop/Mobile/Tab
User Interface
Web 3D GE / Advanc
Wirecloud GE / Dash
OAuth2.0
SANTANDER
SMARTSPACES
SEVILLA 2) IoT Providers. Pretty Heterogeneous solutions/skills.
• An incremental approach. Public/Private instances.
• KISS philosophy for most (web)developers.
• Advanced IoT architecture, e.g. for IoT Advanced
Devel.
1) IoT Consumers. Normally not just IoT.
• A single point, API & Protocol for IoT, OpenData, etc.
• Context: Data Entities + Data Entities events.
• A Public & Secured Ecosystem at FIWARE Lab
MultiMedia
Events
Complex
Event
Processing
IoT GEis
Smartcities
OpenData
BigData
Analytics

4. IoT – Typical Scenario I (fully tested, most used so far)
• Simplest scenario at FIWARE Wiki IoT Architecture.
• Extensively tested with developers. Most Feedback Implemented.
• New features are required (Edge management, more Agents).

5. 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)

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

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

8. 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

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

10. 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

11. 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

12. 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

13. Simple Demo: Framework Node.js
• Installation
npm install –g iotagent-node-lib
• Command line interface for testing
– agentConsole
– iotAgentTester
• Testing of common IOTA features
– Service management
– Device management
– Context Provider registration

14. Lightweight M2M IoT Agent

15. 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

16. 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

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

18. Advanced Demo: Lightweight M2M
• Installation
npm install –g lwm2m-node-lib
• Command line interface for testing
– iotagent-lwm2m-server
– iotagent-lwm2m-client
• Test the protocol or the clients created

19. Advanced Demo: Lightweight M2M IOTA
• Installation
npm install –g lightweightm2m-iotagent
• Command line interfaces for testing
– In the LWM2M IOTA Project
• Testing of specific LWM2M IOTA features
– Client registering
– Message sending
– Context Providers

20. IoT Agent Development

21. 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

22. 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
Registry
Group
Registry
Provision Server

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

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

25. 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

26. 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/

27. BACKUP SLIDES
Backup slides
27