Chapter 7:

IoT Ser vices Platfor m

Prof. Moussa Ayyash

26 October 2015
 Chapter 7

IoT Services Platform Functions

Traditional Application Application Application

Management Management Development Services
• Fault • Software/firmware • Data • Business Rule
Management & installation Management Support
Troubleshooting • Patching • Temporary • Complex Event
• Configuring & • Starting/stopping Caching Processing
Deploying • Debugging • Permanent • Data Analytics
• Accounting & • Monitoring Storage • Closed Loop
Billing • Data Control.
• Performance Normalization, • Subscriptions &
Monitoring • Policy-based Notifications
• Security Access Control & • Service
Management Exposure Discovery

© 2017 Copyright . All rights reserved. 2

 Chapter 7
Services Platform Functions
FCAPS still apply to IoT, However, the overall management functions of IoT solutions are more
multifaceted than traditional networks. This is due to the following factors:
• IoT solutions include new devices (e.g. sensors, white-label gateways, and white-label
switches). Some of these devices are inexpensive and generally lack the type or level of
instrumentation required for traditional management functions.
• IoT solutions utilize relatively recent technologies (e.g. tracking exact location of IoT device
using GPS triangulation) that were not considered by traditional management solutions.
• IoT solutions support more than two dozen access protocols (Chapters 4-5). The network
management for each protocol may vary.
• IoT solutions support multiple verticals, each of which has different sets of management, quality
of service and grade of service requirements.
• IoT solutions utilize a new Fog layer with new and challenging network, compute and storage
management requirements.
• Many enterprises and service providers are expected to outsource and, in many cases,
multisource key parts of the network and/or management functions. This requires additional,
mostly new, capabilities such as secure integration that spans connecting workflows between
multiple services provides. © 2017 Copyright . All rights reserved. 3
 Chapter 7

IoT Services Platform Functions

IoT Applications

Chapter 7
IoT Services Platform Area of Focus

IoT Network
IoT Gateway

IoT Devices

© 2017 Copyright . All rights reserved. 4

 Chapter 7

IoT Services Platform Functions

IoT Applications

IoT Service
IoT Services Platform Platform
Functions

IoT Network

IoT Devices

© 2017 Copyright . All rights reserved. 5

 Chapter 7
IoT Layers and Services Platform Functions (1/2)
• IoT Device Entities:
 IoT devices include sensing devices, actuators, and gateways.
 The main functions of the gateways are
1. collecting and aggregating information from devices,
2. on-site filtering and simple correlation of collected information,
3. transferring correlated data to the network layer and
4. taking action on the devices (e.g. shutting power off) based on commands
from higher layers.

• IoT Network Entities:

 Network Entities include, super gateways, access routers, switches, and
possibly element management servers with specific network management
functions.
 Provide services from the underlying network Services platform.

© 2017 Copyright . All rights reserved. 6

 Chapter 7
IoT Layers and Services Platform Functions (2/2)
• IoT Services Platform Entity:
 Allows the creation of direct integration between IoT devices and computer-based
application systems.
 Responsible for monitoring and controlling elements at Device and Network
Layers.
 Receives information from IoT Device and Network Entities, and provides services
to the Application Entities.
 Provides network-level and often service-level management functions as will be
discussed in this chapter.
• IoT Application Entities:
 Receive info from Services Platform and provide services and business level
functions (typically vertical dependent).
 Examples of Application Entities include an IoT-based Automated Parking
application, an IoT-based Hurricane Alert System application, etc.
© 2017 Copyright . All rights reserved. 7
 Chapter 7
Services Platform Functions

API Manager

Platform Discovery & Communication

Manager Registration Manager

Data Firmware Topology

Manager Manager Manager

Group Billing & Subscription &

Manager Accounting Notification

Element Manager: Configuration, Fault, Performance and Security

© 2017 Copyright . All rights reserved. 8

 Chapter 7
1. IoT Platform Manager

• Performance Monitoring & Fault Management of the Services Platform functions:

Continuous monitoring, troubleshooting, fault identification, fault correction and
diagnostics. This requires constant collection of logs, performance and fault
parameters from the platform functions (e.g. system logs, alarms).
• Lifecycle software management allowing the IoT Platform Manager to manage any
software packages related to the above Services Platform functions: Upgrading,
updating, installing, uninstalling/removing and downloading software packages.
Complete configuration backups with roll-back capabilities must be supported
• Configuring any of the platform functions when they’re first installed. This includes the
configuration of the services offered to Application Entities.
• Supporting multiple levels of IoT Platform Managers operating in a hierarchical
environment. For instance, supporting two Platform Managers, representing two
separate networks, and a third “Supper Platform Manager” with full read and write
access to the first two. Consequence, Platform Managers should have the ability to
establish relationships among each other including establishing parent-child and
Read-Write relationships. © 2017 Copyright . All rights reserved. 9
 Chapter 7
2. Discovery: Entities, Services and Location

• Discovery is the process of identifying and transferring information regarding

existing IoT entities and/or resources with their locations.
• Accurate discovery is essential for most IoT management tasks such as asset
management, network monitoring, network diagnostics and fault analysis, network
planning, capacity expansion, high availability and others.
• One of the key discovery requirements is for IoT entities (e.g. sensors, gateways,
routers) to uniquely identify themselves via a common registration process. Hence,
each entity needs to be uniquely identifiable through its embedded computing
system.
• An essential requirement for discovery is entity registration.

© 2017 Copyright . All rights reserved. 10

2. Discovery: Entities, Services and Location Chapter 7
A. Registration

• IoT device Registration is the process of delivering device info to the Management Entity in order
for IoT devices to communicate and exchange information.
• Most IoT devices will be identified and tracked by their IP addresses but not always.
• IoT devices must have the capability to register to an associated Platform Manager.
• This procedure may be self-registration (preferred solution) where a new IoT device identifies itself
to the management entity as soon as it joins the network, or discovery-based registration where a
device identifies itself during the discovery process.
• The registration requirements must be addressed in all IoT domains, i.e.
• Ability for new sensors and actuators to register themselves with their associated gateways.
• Ability for new gateways to register themselves with their associated Platform Manager
entities.
• Ability for Platform Managers to register themselves with a super (or another) Platform
Manager(s) as defined by the network administrator.

© 2017 Copyright . All rights reserved. 11

2. Discovery: Entities, Services and Location Chapter 7
A. Registration (con’t)

Once the registration is complete,

• The IoT Platform Manager must be able to access the IoT gateway and retrieve
information. Hence, IoT gateways must grant access privilege to the associated IoT
Platform Manager(s).
• The IoT gateways must be able to access their associated sensors and actuators
and retrieve information. In this case, sensors and actuators resource information
must available to the associated IoT gateway(s).
• Super IoT Platform Manager(s), if present, must be able to access their
corresponding IoT Platform Managers and retrieve information.
• Resource information must be available to the super management entities where
applicable.

© 2017 Copyright . All rights reserved. 12

2. Discovery: Entities, Services and Location Chapter 7
B. Discovery

• The discovery function is responsible for discovering, identifying and

retuning matching information regarding entities and/or resources.
• The discovery function sends matching information to the requester’s
system.
• The discovery request may include the IP or MAC address (obtained from
device registration), set of addresses or range of IP addresses of the
resource where the discovery is to be performed.
• Full discovery, without any specified addresses, may also be supported. In
such case, all entities (based on some filtering criteria in the discovery
request) are discovered. Example: Discover all entities in a given enterprise
network.

© 2017 Copyright . All rights reserved. 13

2. Discovery: Entities, Services and Location Chapter 7
B. Discovery (con’t)

• Location of the physical entities (e.g. sensors, gateways) is essential. IoT

entities should have the capability of identifying, storing and updating their
geographical location information.
 This may be accomplished with a GPS module in the entity, a location
server responsible for tracking and storing location information, or
information for inferring location stored in other nodes.
 The location technology (e.g. Cell-ID, assisted-GPS, and fingerprint)
used by the underlying network depends on its capabilities. Sensors
with no geo-locations are identified by their corresponding gateways.

© 2017 Copyright . All rights reserved. 14

2. Discovery: Entities, Services and Location Chapter 7
B. Discovery (con’t)
CoAP Constrained Application Protocol) Example:

Discovery Request: Assume the IP Address of the Management Server is 192.15.10.5. Also assume the
Management Server is interested in discovering sensors within 500 meters from the location of
(37.76724070774898, -122.37890839576721) GPS Coordinates. The management server will send a CoAP GET
request to

Coap://192.15.10.5:5784/.well-known/core?
& ro=SSN-XG-IRI&sd=yyyyyy=&at30004&lg=-122.37890839576721
&lt=37.76724070774898&md=500&st=2&sr=70

Discovery Reply: Upon receiving the request, the CoAP server will start a matching process comparing the request
with all stored information in its local data store. Let’s assume that the returned set consists of two sensors matching
the request. The CoAP server response payload will be:

</Hts2030HumidSens>;ct=41; at30004; lg=-122.37890839576721; lt=37.76724070774898&md=310; ro=SSN-XG-

IRI; sd=aaaaaa; tittle=”Humidity-Sensor-2030”,
</BitLineAnemomSens>;ct=0; ct=41;at=30004; lg=-122.37890839576721; lt=37.76724070774898&md=276;
ro=SSN-XG-IRI; sd=bbbbbb; tittle=”Anemometer-Sensor-111”,

Note: (37.76724070774898, -122.37890839576721) are the GPS Coordinate for a northern California area .
© 2017 Copyright . All rights reserved. 15
Summary of IoT Registration & Discovery Requirements Chapter 7

Function Responsibility Results/Outputs

Identify IoT sensors, actuators, gateways IoT entities, gateways, sensors
and devices via attributes & search and actuators based on filtering
protocols criteria (e.g. Address, Type,
Firmware)
Identify the location of physical entities GPS location
Identify access control policies across Access Control Policy
Discovery management servers and clients (Section
7.3)
information.

Identify IoT services via attributes & IoT configured services

collected data (outside the scope of this book)

The process of delivering IoT device Ability for IoT device (sensors,
information (sensors, actuators, actuators, gateways and IoT
gateways and IoT entities) to the entities) to register with their
Management Entity in order for IoT associated gateways
Registration devices to communicate and exchange
information.

© 2017 Copyright . All rights reserved. 16

 Chapter 7

2. Discovery: Entities, Services and Location

IoT software services may also be discovered by collecting configuration and operational parameters
(e.g. using YANG, SNMP MIBs, CLI Outputs). IETF defined a set of requirements for standard-based
device (configuration and operational data) management. Key functionalities include:
• Ability to collect configuration and operation data from all IoT devices (e.g. running configuration files).
• Ability to extract and then structure / model data from configuration and operation files via an information model
• Ability to distinguish between configuration data and operational data (i.e. data that describes operational state and
statistics).
• Ability for operators to configure the entire network and not just individual devices.
• Ability to check configurations consistency between devices in the network.
• Ability to use text processing tools such as diff and version management tools such as CVS.
• Ability to distinguish between the distribution of configurations and the activation of a certain configuration.

Note: YANG is a tree-structured data modeling language (defined by IETF) used to model
configuration and state data. © 2017 Copyright . All rights reserved. 17
 Chapter 7
3. Communication Manager

The Communication Manager is responsible for providing communications with other

platform functions, applications and devices. This includes supporting the following
functionality:

• Ability to provide a global view of the state of the entire underlying platform network.
• Ability to determine the optimal time to establish the communication connection to deliver
information between at least two platform entities. Such decision is based on the source delivery
request as well as traffic / congestion control optimization techniques within the platform. Data
may be stored / buffered for future delivery time per the provisioned Communication Manager
policies.
• Ability to deliver required information within the delivery request time.
• Ability to publish its own polices to external systems.
• Ability to provide information to external systems to drive policies describing details of the usage
of network resources (i.e. 5% of bandwidth on link X at time T was utilized for service Y).
• Ability to communicate, select paths for a given amount of time and manage buffers based on
communication manager polices. © 2017 Copyright . All rights reserved. 18
 Chapter 7
4. Data Management and Repository
Collecting, storing and exchanging information among various platform entities, is one
of the key requirements for the IoT Service Platform. Data Storage and Mediation
functionalities must include:
• Data Retrieval: Data may be retrieved from various sources including IoT devices (e.g. sensors
and getaways), IoT network elements (e.g. super-gateways and switches), IoT subscribers or
IoT applications. IoT device and network element data is assumed to be collected by collection
systems or by collection agents.
• Data Aggregation: Data aggregation implies grouping data from similar or diverse sources for
further processes. Typically, data from various IoT sources need to be grouped together based
on a well-defined data model (e.g. physical locations, device types, subscribers with their
assigned devices, etc.). The aggregation syntax should be defined by the data model. Also, data
from multiple data collection systems (for the same IoT entity) need to be filtered and
aggregated accordingly.
• Data Parsing: Data parsing normally implies reading the data, using software, and extracting
useful information. Stages of data parsing are hard to define without a concrete use-case but
typically include running code to extract specific parameters and writing the extracted data to a
database.
© 2017 Copyright . All rights reserved. 19
 Chapter 7
4. Data Management and Repository (Con’t)
• Data Storing: The Data Storage and Mediation Function supports taking data from various
sources and storing it based on predefined policy.
• Raw data, aggregated data and parsed data may be stored with different polices (e.g.
store raw data for 6 months, store parsed data for 2 years).
• Associated contextual information is also stored with the data.
• Examples of contextual information include: data type (e.g. Temperature), data format (e.g.
-100 C to +100 C) data source (e.g. Sensor ID and Associated Gateway ID), retrieval time
and date (e.g. 03:45:00 PM EST on 12/12/2016), retrieval location (e.g. lg=-
122.37890839576721; lt=37.76724070774898).

• Access to data based on defined access control policy: The Data Storage and Mediation
needs to have the capability of providing local or remote data access based on a well-defined
access control policy. The policy, which is typically defined by the network administrator, needs
to capture what types of functions a specific user or application can perform on the data (read-
only write-only, read/write). The policy may include temporal access restrictions, and may be
role-based (e.g. administrator vs. user, etc.).

© 2017 Copyright . All rights reserved. 20

 Chapter 7
5. Element Manager
• The element management function is expected
to manage IoT sensors, actuators, gateways as
well as other devices residing within the platform
Management
boundaries. Server
Server
• The element management function utilizes the
client-server distributed model where a single
management server may manage multiple
management clients. Management
IoT Gateway
• In this model, tasks are partitioned between the Client
management server (provider of the service) and
the management client (service requester). IoT Sensor
• The management client establishes a connection
to the management server over the network to
accomplish a particular task (e.g. sending
performance results of the last 5 minutes).
• Once the management client’s task is fulfilled, by
the management server, the connection is
terminated.
© 2017 Copyright . All rights reserved. 21
 Chapter 7
5. Element Manager Functions
• Ability for the management client and server to communicate at any time. Hence, real-time
communication is required to send time-sensitive data.
• While it is recommended to use a standardized protocol so that any management server can
communicate with any management client, any existing client-server communication protocol may
be utilized. E.g. TR-069 and LWM2M (Lightweight Machine-to-Machine) .
• Ability for the management servers to receive and understand (based on an agreed upon protocol)
management client requests and/or notifications. For example, air pressure measurements of the
oil rig vale.
• Ability for the management clients to receive requests and/or notifications from the management
servers. The management client should have the ability to deliver server’s commands to targeted
sensors, actuators or device as required. For example, requesting the actuator to shut down a
valve.
• Ability for the management server and management clients to address the security requirements as
defined later in this chapter and in Chapter 8.

© 2017 Copyright . All rights reserved. 22

 Chapter 7
5. Element Manager Functions (con’t)
• Ability for the super management server to assign different levels of access control privileges when
multiple management servers and/or clients exist.
• Ability for the super management server to provide read access (with the appropriate access
control requirement) to the discovery or other functions to discover access control policy
information.
• Ability for the management server to provide read access (with the appropriate access control
requirement) to the discovery or other functions to discover managed elements with their latest
collected information (e.g. metadata, values) including gateways, sensors, and actuators.
• Ability for the management server to create a new element to be managed (e.g. gateway, sensor),
delete an existing element, update any parameters of any existing elements, update the firmware of
any element, and to retrieve information of any existing elements.

© 2017 Copyright . All rights reserved. 23

 Chapter 7
5. Element Manager Functions
A. Configuration and Provisioning
• Provisioning is concerned with the basic process of
preparing and equipping an IoT network to provide M2M App
proper and effective services.
• Configuration is concerned with the actual enablement
or disablement of an IoT service.
• Provisioning is often equated to initiation of a service or LW M2M
capability, whereas configuration is the final set of Server
touches to deliver the actual service to a customer.
• Hence, an IoT network is first generically provisioned
(e.g. by installing libraries or services on servers) to LW M2M
Client
provide a set of services to any customers. Such
provisioning does not imply that a service can simply be
launched without additional instructions on which
IoT Sensor
particular server to use, which specific set of already
provisioned parameter to employ, how to distribute the
load when demand increase, etc.

© 2017 Copyright . All rights reserved. 24

 Chapter 7
5. Element Manager Functions
A. Configuration and Provisioning (Con’t)

Key configuration requirements include: M2M App

• Ability to identify IoT devices and their associated

management objects and attributes.
LW M2M
• Ability to enable or disable a device capability. Server
• Ability to update device parameters.
• Ability to roll-back applied changes in the configuration
LW M2M
• Ability to reset IoT device parameters to original factory Client
values.

IoT Sensor

© 2017 Copyright . All rights reserved. 25

 Chapter 7
5. Element Manager Functions
B. Fault Management
• At the minimum, IoT service providers need to be able to configure & provision a service
(turn-on a service for a customer) and then identify problems and have the tools to fix
them quickly.
• Fault management is among the most challenging and important management function
of IoT networks. This is due to:
 Large-scale deployment of inexpensive sensors (i.e. with very limited processing
capability, storage capacity and limited energy) means that failures from various
defects will not be uncommon.
 Managing IoT devices in remote locations and often harsh environments will be
demanding, especially when dealing with various IoT topologies and verticals.
• Fault Management typically consists of three main functions:
 Fault detection
 Fault isolation (or diagnostic)
 Fault correction. © 2017 Copyright . All rights reserved. 26
 Chapter 7
5. Element Manager Functions
B. Fault Management (Con’t)

• Fault Detection is the process of identifying error (or potential error) of an IoT element, often by
using collected statistics.
• Collected data/ statistics may be time-based (e.g. collected from an IoT element by the fault manager
function every t seconds) or event-based (e.g. IoT element notifies the fault manager only if
predefined fault-related conditions are met). Advantages?
• When a fault or event occurs in the event-based case, an IoT element will send an alarm or
notification to the fault manger (and often notify the network administrator) immediately.
• An alarm is a persistent indication of a fault that clears only when the triggering condition has been
resolved. © 2017 Copyright . All rights reserved. 27
 Chapter 7
5. Element Manager Functions
B. Fault Management (Con’t) - Example
• An example of fault-related data is the Simple Network Management Protocol (SNMP) Entity
Sensor Management Information Base (MIB) as described by IETF RFC 3433.
• The Entity Sensor MIB provides generalized access to information related to sensors (see
Table next slide). One of the key variables of the Entity Sensor MIB is “Entity Sensor Status”
with three defined possible values:
- Entity Sensor Status = 1: the sensor data value can be obtained (normal operation)
- Entity Sensor Status = 2: the sensor data value is unavailable (operational but no
data was collected)
- Entity Sensor Status = 3: the sensor is broken and cannot collect data (failure).
- Once the failure status is received by the element manager (or network administrator)
needs to investigate the issue further to determine if the failure is due to disconnected
wire, out-of-range, or something else.
• Fault detection will be triggered if the value of “Entity Sensor Status” variable is 3.

© 2017 Copyright . All rights reserved. 28

 Chapter 7
5. Element Manager Functions
B. Fault Management (Con’t) - Example
MIB Variable Description Examples of Potential Value

EntitySensorDataType Entity Sensor measurement data 3 = Volts AC

type associated with a physical 4 = Volts DC
sensor value. 5 = Ampres
6 = Watts
7 = Hertz
8 = Celsius
EntitySensorDataScale A data scaling factor, represented 6 = Nano
with an International System of 10 = Kilo
Units prefix. 11 = Mega
12 = Giga
13 = Tera
14 = Exa
EntitySensorPrecision Sensors Precision Range 1 = One decimal place in the
fractional part
2 = Two decimal place in the
fractional part
EntitySensorValue Sensor Value From -999,999,999
To +999,999,999.
EntitySensorStatus Operational Status of Physical 1 = Ok
Sensor 2 = Unavailable
3 = Nonoperational
TimeStamp The time the status and/or value 10:00:00 AM PST
of this sensor was last obtained.
© 2017 Copyright . All rights reserved. 29
 Chapter 7
5. Element Manager Functions
B. Fault Management (Con’t)
• Fault Diagnostic and Isolation (also referred to as Fault Root Cause Analysis) is the process of
hierarchal filtering and correlating of fault messages to pinpoint the faulty element to a stage where
corrective action can be taken.
• Such process is often based on artificial intelligence, pattern recognition combined with models of
abnormal behavior and/or intelligent rule-based systems.
• Pattern recognition with abnormal behavior models is frequently used in the industry to construct
the so-called “Diagnostic Signatures” as a form of accumulated and documented
knowledge. Fault Diagnostic and Isolation will then take place at run-time based on matching
observed information to the nearest Diagnostic Signature.
• Fault managers may use complex filtering systems to assign alarms to severity levels.
Alternatively, they could use the ITU X.733 Alarm Reporting Function's perceived severity field:
cleared, indeterminate, critical, major, minor or warning.
• Fault Isolation (or Fault Diagnostic) in IoT-based network is a challenging problem because of the
interactions between different network entities (e.g. wireless sensors, gateways) and protocols.

© 2017 Copyright . All rights reserved. 30

 Chapter 7
5. Element Manager Functions
B. Fault Management (Con’t)
• Fault Correction is the process of fixing the error/fault problem, often remotely.
• A fault manager allows a network administrator to monitor events and perform actions
based on received information.
• Ideally, the fault manger system should be able to not only correctly identify faults but
also to automatically take corrective action,e.g. launch a program or script to take
corrective action.
• Critical IoT systems should be designed around the concept of fault tolerance: they
must be able to continue working at least to some acceptable level in the presence of
faults.
• Network element redundancy (e.g. multiple sensors performing identical tasks, dual
modular sensing engines in the same sensor, fail-over power supply) is common fault-
tolerance example that is designed to prevent failures due to hardware components.

© 2017 Copyright . All rights reserved. 31

 Chapter 7

5. Element Manager Functions

B. Fault Management Functions
• Ability to connect and uniquely identify any device in the network including sensors, actuators,
gateways, etc. Sensors and actuators are often identified by their corresponding gateways.
• Once the connection is established, the Fault Manager should have the ability to retrieve device
information that identifies a device, its model and manufacturer. E.g. Device Universal ID, Device
Product ID, Device Serial Number, SKU.
• Ability to retrieve device information for the software and firmware installed on the device, e.g.
embedded software version.
• Ability to retrieve information related to a battery embedded within the device.
• Ability to retrieve information related to memory in use by a device.
• Ability to reconfigure / change (Write option) device specific parameters to diagnose or fix an
identified problem.
• Ability to compare results from main system and backup system (if backup system is deployed and
operational) and provide error messages for different results.
© 2017 Copyright . All rights reserved. 32
 Chapter 7

5. Element Manager Functions

B. Fault Management Functions (Con’t)
• Ability to provide the current list of problems occurring on the network to network management
systems / system administrator. Such list is cleared only when the triggering condition has been
resolved or cleared by the network administrator.
• Ability to retrieve the event logs from any IoT device.
• Ability to allow a system administrator to monitor events from multiple systems/locations and
perform actions.
• Ability to assign alarms to severity levels. E.g. cleared, indeterminate, critical, major, minor or
warning.
• Ability to notify administrators of critical and/or other alarms (based on pre-defined rule-based list)
via e-mails, text message, call to mobile phones.
• Ability to launch a program or script to take corrective action for critical and/or other alarm types.
• Ability to reboot diagnostic operation.
• Ability to roll-back any changes at any stage.
© 2017 Copyright . All rights reserved. 33

• Ability to rest IoT device parameters to original factory values.

 Chapter 7

5. Element Manager Functions

C. Performance Management Functions
• The Performance Management function can be defined as a mechanism to quantity “how the
underlying IoT infrastructure (e.g. IoT network and device layers) is doing?”
• E.g. Is the infrastructure operating under heavy load and about to run out of bandwidth or is there
substantial extra free capacity so a service provider can offer discounted services?
• Formal Definition: Performance Management is a set of processes to measure and monitor the
quality and grade of the services that are offered to customers.
• Quality of Service (QoS) typically refers to performance measures from one element (e.g. delay of
one link) whereas Grades of Service (GoS) typically refers to a performance measure of the end-to-
end service (e.g. delay of the end-to-end path that a service is taking).

© 2017 Copyright . All rights reserved. 34

5. Element Manager Functions Chapter 7

C. Performance Management Functions Main Elements

1. What to measure? Determining what to measure is the most critical question for IoT
management. Smart performance algorithms are useless unless required measurements that
drive such algorithms can be collected.
• In Chapter 3 (Things in IoT), we have identified over a dozen sensor types. Knowing that these sensors
are performing correctly is important. Key sensor performance measures include:
• Operating range of Input-to-output signals
• Acceptable noise level produced by sensors
• Acceptable resolution and acceptable response time to instantaneous change in input signal.
• Examples of Perf Measures:
• Device utilization (based on available bandwidth and capacity),
• End-to-end delay and jitter
• Packet lost ratios, packet error rates, and parameters that impact services carried on the network.
2. Where to measure? Theoretically performance should be measured through the network at all
time. Practically, performance should be measured at least between the network end points
where the service is delivered. E.g. sensor to gateway, gateway to platform and platform to
application.
© 2017 Copyright . All rights reserved. 35

3. How to measure & Construct QoS and GoS measures to perform the actual minoring?
 Chapter 7

5. Element Manager Functions

C. Performance Management Functions (Con’t)
• Ability to connect and identify any device in the network. Sensors and actuators are often identified
by their corresponding gateways.
• Once the connection is established, Performance Management function needs to have the ability to
ID the device by retrieving device information.
• Ability to retrieve device information for the software and firmware installed on the device, e.g.
embedded software version.
• Ability to retrieve information to measure the performance of a device or a module within the device
(e.g. battery).
• Ability to measure any performance related parameter, e.g., utilization, delay, jitter, packet lost,
packet arrives with error, amount of memory in use by a device.
• Ability to allow a system administrator to monitor events from multiple systems/locations.
• Ability to notify administrators of critical and/or other performance related activities.

© 2017 Copyright . All rights reserved. 36

 Chapter 7

5. Element Manager Functions

D. Performance Measures for Sensors
• IoT Sensor’s Transfer Function should be plotted (e.g. testing the various ranges of inputs) to
ensure it meets the specific IoT solution requirements. The Transfer Function represents the
functional relationship between input signal (physical signal captured by the sensor) and output
signal (electrical signal converted by the sensor).
• IoT Sensors’ Sensitivity should be evaluated and within the minimum acceptable range for the
specific IoT solution (e.g. 0.1 variation in temperature sensors may be acceptable for smart homes
but not for critical solutions). Sensitivity = the ratio between a small change in electrical output
signal to a small change in physical signal. It may be expressed as the derivative of the transfer
function with respect to physical signal.
• IoT Sensor’s Dynamic Range should be established and documented. Dynamic range is defined
as the range of input signals which may be converted to electrical signals by the sensor. Outside of
this range, signals cause unsatisfactory accuracy in output.
• IoT Sensor’s Accuracy should be established and documented. Accuracy is defined as the
maximum expected error between measured (actual) and ideal output signals. Manufacturers often
provide the accuracy in the datasheet, e.g. 1% error may be acceptable for some IoT solutions.
© 2017 Copyright . All rights reserved. 37
 Chapter 7

5. Element Manager Functions

D. Perf Measures for Sensors (Con’t)
• IoT Sensor’s Noise Level should be established and documented. A sensor’s noise is an issue if it impacts the
performance of the IoT system. Smarter sensors must filter out unwanted noise and be programmed to produce
alerts on their own when critical limits are reached.
• IoT Sensor’s Resolution should be established and documented. The resolution of a sensor is defined as the
smallest detectable signal fluctuation. It is the smallest change in the input that the device can detect.
• IoT Sensor’s Bandwidth (the frequency range) should be established and documented. Some sensors do not
operate properly outside their defined bandwidth range.
• IoT Sensor should produce a performance alert and notify its IoT gateway once service issues is detected outside
its normal operational range (e.g. outside the defined bandwidth, resolution).
• IoT Sensors should have some ability (depending on the sensors’ sophistication level) to work with its IoT gateway
to measure the Throughput (actual rate at which the information is transferred), Latency (the delay between the
sender and the receiver), Jitter (variation in packet delay at the receiver of the information) and Error Rate (the
number of corrupted bits expressed as a percentage of the total sent) during a specific period of time (e.g. 1 Hour).

© 2017 Copyright . All rights reserved. 38

 Chapter 7

5. Element Manager Functions

E. Security Management
• Data Confidentiality: ensures that the exchanged messages can be understood only by the intended entities.
• Data Integrity: Ensures that the exchanged messages were not altered/tampered by a third party.
• Secure Authentication: Ensures that the entities involved in any operation are who they claim to be. A masquerade
attack or an impersonation attack usually targets this requirement where an entity claims to be another entity.
• Availability: Ensures that the service is not interrupted. Denial of Service attacks target this requirement as they
cause service disruption.
• Secure Authorization: Ensures that entities have the required control permissions to perform the operation they
request to perform.
• Freshness: Ensures that the data is fresh. Replay attacks target this requirement where an old message is replayed
in order to return an entity into an old state.
• Non Repudiation: Ensures that an entity can’t deny an action that it has performed.
• Forward and Backward Secrecy: Forward secrecy ensures that when an entity leaves the network, it will not
understand the communications that are exchanged after its departure. Backward secrecy ensures that any new
entity that joins the network will not be able to understand the communications that were exchanged prior to joining
the network.
© 2017 Copyright . All rights reserved. 39