MBK 00302

AN INTRODUCTION TO
INTERNET OF THINGS (IoT)
IN BUSINESS
CHAPTER 5
M2M AND IOT TECHNOLOGY
FUNDAMENTALS

PREPARED BY:
NASHRAN HARITH BIN NAZREE
 DEVICES AND GATEWAYS

Embedded processing is evolving, not only towards higher capabilities and processing
speeds, but also towards allowing the smallest of applications to run on them.

There is a growing market for small-scale embedded processing such as 8-, 16-, and 32-bit
microcontrollers with on-chip RAM and flash memory, I/O capabilities, and networking
interfaces such as IEEE 802.15.4 that are integrated on tiny System-on-a-Chip (SoC)
solutions.

Such devices enable very constrained devices with a small footprint and with a very low
power consumption but which are capable of hosting an entire Transmission Control
Protocol/Internet Protocol (TCP/IP) stack, including a small web server.
 DEVICE CHARACTERISTICS

A device is a hardware unit that can sense aspects of it’s environment and/or actuate, i.e.
perform tasks in its environment.

A device can be characterized as having several properties, including:

Microcontroller: 8-, 16-, or 32-bit working memory and storage.
Power Source: Fixed, battery, energy harvesting, or hybrid.
Sensors and Actuators: Onboard sensors and actuators, or circuitry that allows them to be
connected, sampled, conditioned, and controlled.
Communication: Cellular, wireless, or wired for LAN and WAN communication.
Operating System (OS): Main-loop, event-based, real-time, or full featured OS.
Applications: Simple sensor sampling or more advanced applications.
User Interface: Display, buttons, or other functions for user interaction.
Device Management (DM): Provisioning, firmware, bootstrapping, and monitoring.
Execution Environment (EE): Application lifecycle management and Application
Programming Interface (API).
DEVICE CHARACTERISTICS
 DEVICE TYPES
Devices are categorized into two groups;

• Basic Devices: Devices that only provide the basic services of sensor readings and/or actuation
tasks, and in some cases limited support for user interaction. LAN communication is supported
via wired or wireless technology, thus a gateway is needed to provide the WAN connection.

• Advanced Devices: In this case the devices also host the application logic and a WAN
connection. They may also feature device management and an execution environment for hosting
multiple applications. Gateway devices are most likely to fall into this category.
 DEPLOYMENT SCENARIOS FOR DEVICES
Deployment can differ for basic and advanced deployment scenarios. Example deployment scenarios for
basic devices include:

▪ Home Alarms: Such devices typically include motion detectors, magnetic sensors, and smoke detectors. A
central unit takes care of the application logic that calls security and sounds an alarm if a sensor is activated
when the alarm is armed. The central unit also handles the WAN connection towards the alarm central.
These systems are currently often based on proprietary radio protocols.

▪ Smart Meters: The meters are installed in the households and measure consumption of, for example,
electricity and gas. A concentrator gateway collects data from the meters, performs aggregation, and
periodically transmits the aggregated data to an application server over a cellular connection. By using a
capillary network technology (e.g. 802.15.4), it’s possible to extend the range of the concentrator gateway by
allowing meters in the periphery to use other meters as extenders, and interface with handheld devices on
the Home Area Network side.
• Building Automation Systems (BASs): Such devices include thermostats, fans, motion
detectors, and boilers, which are controlled by local facilities, but can also be remotely operated.

• Standalone Smart Thermostats: These use Wi-Fi to communicate with web services.

• Onboard units in cars that perform remote monitoring and configuration over a cellular
connection.

• Robots and autonomous vehicles such as unmanned aerial vehicles that can work both
autonomously or by remote control using a cellular connection.

• Video cameras for remote monitoring over 3G and LTE.

• Oil well monitoring and collection of data points from remote devices.

• Connected printers that can be upgraded and serviced remotely.

 GATEWAYS
• A gateway serves as a translator between different protocols, e.g. between IEEE 802.15.4 or IEEE 802.11, to
Ethernet or cellular.
• There are many different types of gateways, which can work on different levels in the protocol layers. Most
often a gateway refers to a device that performs translation of the physical and link layer, but application
layer gateways (ALGs) are also common.
• The latter is preferably avoided because it adds complexity and is a common source of error in deployments.
• Some examples of ALGs include the ZigBee Gateway Device (ZigBee Alliance 2011), which translates from
ZigBee to SOAP and IP, or gateways that translate from Constrained Application Protocol (CoAP) to HyperText
Transfer Protocol/Representational State Transfer (HTTP/REST).
• For some LAN technologies, such as 802.11 and Z-Wave, the gateway is used for inclusion and exclusion of
devices.
• This typically works by activating the gateway into inclusion or exclusion mode and by pressing a button on
the device to be added or removed from the network.
 GATEWAYS - DATA MANAGEMENT

• Typical functions for data management include performing sensor

readings and caching this data, as well as filtering, concentrating, and
aggregating the data before transmitting it to back-end servers.
 GATEWAYS – LOCAL APPLICATIONS
• Examples of local applications that can be hosted on a gateway include home alarm logic, and
ventilation control, or the data management function.
• The benefit of hosting this logic on the gateway instead of in the network is to avoid downtime in
case of WAN connection failure, minimize usage of costly cellular data, and reduce latency.
• To facilitate efficient management of applications on the gateway, it’s necessary to include an
execution environment.
• The execution environment is responsible for the lifecycle management of the applications,
including installation, pausing, stopping, configuration, and uninstallation of the applications.
• A common example of an execution environment for embedded environments is OSGi, which is
based on Java: applications are built as one or more Bundles, which are packaged as Java JAR
files and installed using a so-called Management Agent.
• The Management Agent can be controlled from, for example, a terminal shell or via a protocol
such as CPE WAN Management Protocol (CWMP).
• Bundle packages can be retrieved from the local file system or over HTTP, for example. OSGi also
provides security and versioning for Bundles, which means that communication between Bundles
is controlled, and several versions of them can exist.
• The benefit of versioning and the lifecycle management functions is that the OSGi environment
never needs to be shut down when upgrading, thus avoiding downtime in the system.
• Also, Linux can be used as an execution environment.
 GATEWAYS - DEVICE MANAGEMENT
• Device management (DM) is an essential part of the IoT and provides efficient
means to perform many of the management tasks for devices:
• Provisioning: Initialization (or activation) of devices in regards to configuration and features
to be enabled.
• Device Configuration: Management of device settings and parameters.
• Software Upgrades: Installation of firmware, system software, and applications on the
device.
• Fault Management: Enables error reporting and access to device status.
• Examples of device management standards include TR069 and OMA-DM.
• In the simplest deployment, the devices communicate directly with the DM
server.
• This is, however, not always optimal or even possible due to network or protocol
constraints, e.g. due to a firewall or mismatching protocols.
LOCAL AND WIDE AREA NETWORKING
 THE NEED FOR NETWORKING
• A network is created when two or more computing devices exchange data or
information.
• The ability to exchange pieces of information using telecommunications technologies
has changed the world, and will continue to do so for the foreseeable future, with
applications emerging in nearly all contexts of contemporary and future living.
• Typically, devices are known as “nodes” of the network, and they communicate over
“links.”
• In modern computing, nodes range from personal computers, servers, and dedicated
packet switching hardware, to smartphones, games consoles, television sets and,
increasingly, heterogeneous devices that are generally characterized by limited
resources and functionalities.
• Limitations typically include computation, energy, memory, communication (range,
bandwidth, reliability, etc.) and application specificity (e.g. specific sensors, actuators,
tasks), etc.
• Such devices are typically dedicated to specific tasks, such as sensing, monitoring, and
control Network links rely upon a physical medium, such as electrical wires, air, and
optical fibers, over which data can be sent from one network node to the next.
• It is not uncommon for these media to be grouped either as wired or wireless
 LOCAL AREA NETWORK (LAN)

• A Local Area Network (LAN) was traditionally distinguishable from a Wide Area Network (WAN) based on the
geographic coverage requirements of the network, and the need for third party, or leased, communication
infrastructure.
• In the case of the LAN, a smaller geographic region is covered, such as a commercial building, an office
block, or a home, and does not require any leased communications infrastructure.
• WANs provide communication links that cover longer distances, such as across metropolitan, regional, or
by textbook definition, global geographic areas.
In practice, WANs are often used to link LANs and MetropolitanArea Networks (MAN) where LAN technologies
cannot provide the communications ranges to otherwise interconnect and commonly to link LANs and devices
(including smart phones, Wi-Fi routers that support LANs, tablets, and M2M devices) to the Internet.
Quantitatively, LANs tended to cover distances of tens to hundreds of meters, whereas WAN links spanned
tens to hundreds of kilometers.

There are differences between the technologies that enable LANs and WANs.
• In the simplest case for each, these can be grouped as wired or wireless. The most popular wired LAN
technology is Ethernet. Wi-Fi is the most prevalent wireless LAN (WLAN) technology.
• Wireless WAN (WWAN), as a descriptor, covers cellular mobile telecommunication networks, a significant
departure from WLAN in terms of technology, coverage, network infrastructure, and architecture.
• The current generation of WWAN technology includes LTE (or 4G) and WiMAX.
 WIDE AREA NETWORKING
• WANs are typically required to bridge the M2M Device Domain to the backhaul network,
thus providing a proxy that allows information (data, commands, etc.) to traverse
heterogeneous networks.
• This is seen as a core requirement to provide communications services between the
M2M service enablement and the physical deployments of devices in the field.
• Thus, the WAN is capable of providing the bi-directional communications links between
services and devices.
• This, however, must be achieved by means of physical and logical proxy.
• The proxy is achieved using an M2M Gateway Device.
• The M2M Gateway Device is typically an integrated microsystem with multiple
communications interfaces and computational capabilities.
• It is a critical component in the functional architecture, as it must be capable of handling
all of the necessary interfacing to the M2M Service Capabilities and Management
Functions.
• The Access and Core Network in the ETSI M2M Functional Architecture are foreseen to
be operated by a Mobile Network Operator (MNO), and can be thought of simply as the
“WAN” for the purposes of interconnecting devices and backhaul networks (Internet),
thus, M2M Applications, Service Capabilities, Management Functions, and Network
Management Functions.
ETSI M2M Functional Architecture
 WIDE AREA NETWORKING
In the M2M context, important functions of the WAN include:
• The main function of the WAN is to establish connectivity between capillary networks, hosting sensors, and
actuators, and the M2M service enablement. The default connectivity mode is packet based using the IP family of
technologies.
• Use of identity management techniques (primarily of M2M devices) in cellular and non-cellular domains to grant
right-of-use of the WAN resource.
The following techniques are used for these purposes:
▪ MCIM (Machine Communications Identity Module) for remote provisioning of SIM targeting M2M devices. xSIM (x-
Subscription Identity Module), like SIM, USIM, ISIM.
▪ Interface identifiers, an example of which is the MAC address of the device, typically stored in hardware.
▪ Authentication/registration type of functions (device focused).
▪ Authentication, Authorization, and Accounting (AAA), such as RADIUS services.
▪ Dynamic Host Configuration Protocol (DHCP), e.g. employing deploymentspecific configuration parameters
specified by device, user, or applicationspecific parameters residing in a directory.
▪ Subscription services (device-focused).
▪ Directory services, e.g. containing user profiles and various device (s) parameter(s), setting(s), and combinations
thereof.
M2M-specific considerations include, in particular:
▪ MCIM (cf. 3GPP SA3 work).
▪ User Data Management (e.g. subscription management).
 LOCAL AREA NETWORKING

• Capillary networks are typically autonomous, selfcontained systems of M2M devices that may be connected
to the cloud via an appropriate Gateway.
• They are often deployed in controlled environments such as vehicles, buildings, apartments, factories,
bodies, etc. in order to collect sensor measurements, generate events should sensing thresholds be
breached, and sometimes control specific features of interest (e.g. heart rate of a patient, environmental
data on a factory floor, car speed, air conditioning appliances, etc.).
• There will exist numerous capillary networks that will employ short-range wired and wireless communication
and networking technologies.
• For certain application areas, there is a need for autonomous local operation of the capillary network.
• That is, not everything needs to be sent to, or potentially be controlled via, the cloud.
• In the event that application-level logic is enforceable via the cloud, some will still need to be managed
locally.
• The complexity of the local application logic varies by application. For example, a building automation
network may need local control loop functionality for autonomous operation, but can rely on external
communication for configuration of control schemas and parameters.
• The M2M devices in a capillary network are typically thought to be lowcapability nodes (e.g. battery
operated, with limited security capabilities) for cost reasons, and should operate autonomously.
• For this reason, a GW/application server will naturally also be part of the architected solution for capillary
networks.
• More and more (currently closed) capillary networks will open up for integration with the enterprise back end
systems.
• For capillary networks that expose devices to the cloud/Internet, IP is envisioned to be the common waist.
IPv6 will be the protocol of choice for M2M devices that operate a 6LoWPAN-based stack.
DATA MANAGEMENT
 INTRODUCTION
• Modern enterprises need to be agile and dynamically support multiple decision-making processes taken at
several levels. In order to achieve this, critical information needs to be available at the right point in a timely
manner, and in the right form.
• Some of the key characteristics of M2M data include:
• Big Data: Huge amounts of data are generated, capturing detailed aspects of the processes where devices are
involved.
• Heterogeneous Data: The data is produced by a huge variety of devices and is itself highly heterogeneous, differing
on sampling rate, quality of captured values, etc.
• Real-World Data: The overwhelming majority of the M2M data relates to real-world processes and is dependent on
the environment they interact with.
• Real-Time Data: M2M data is generated in real-time and overwhelmingly can be communicated also in a very timely
manner. The latter is of pivotal importance since many times their business value depends on the real-time
processing of the info they convey.
• Temporal Data: The overwhelming majority of M2M data is of temporal nature, measuring the environment over
time.
• Spatial Data: Increasingly, the data generated by M2M interactions are not only captured by mobile devices, but also
coupled to interactions in specific locations, and their assessment may dynamically vary depending on the location.
• Polymorphic Data: The data acquired and used by M2M processes may be complex and involve various data, which
can also obtain different meanings depending on the semantics applied and the process they participate in.
• Proprietary Data: Up to now, due to monolithic(unified) application development, a significant amount of M2M data
is stored and captured in proprietary formats. However, increasingly due to the interactions with heterogeneous
devices and stakeholders, open approaches for data storage and exchange are used.
• Security and Privacy Data Aspects: Due to the detailed capturing of interactions by M2M, analysis of the obtained
data has a high risk of leaking private information and usage patterns, as well as compromising security.
 MANAGING M2M DATA

The data flow from the moment it is sensed (e.g. by a wireless sensor node) up to the moment it reaches
the backend system has been processed manifold (and often redundantly), either to adjust its
representation in order to be easily integrated by the diverse applications, or to compute on it in order to
extract and associate it with respective business intelligence (e.g. business process affected, etc.)

Dealing with M2M data may be decomposed into several stages:

• Data generation
• Data acquisition
• Data validation
• Data storage
• Data processing
• Data remanence
• Data analysis
 MANAGING M2M DATA

• Data generation
Data generation is the first stage within which data is generated actively or passively from the device, system, or as a
result of its interactions. The sampling of data generation depends on the device and its capabilities as well as
potentially the application needs.
• Data acquisition
Data acquisition deals with the collection of data (actively or passively) from the device, system, or as a result of its
interactions. The data acquisition systems usually communicate with distributed devices over wired or wireless links to
acquire the needed data, and need to respect security, protocol, and application requirements. The nature of acquisition
varies, e.g. it could be continuous monitoring, interval-poll, event-based, etc.
• Data validation
Data acquired must be checked for correctness and meaningfulness within the specific operating context. The latter is
usually done based on rules, semantic annotations, or other logic. Data validation in the era of M2M, where the acquired
data may not conform to expectations, is a must as data may be intentionally or unintentionally corrupted during
transmission, altered, or not make sense in the business context. Failure to validate may result in security breaches.
• Data storage
The data generated by M2M interactions is what is commonly referred to as “Big Data.” Machines generate an incredible
amount of information that is captured and needs to be stored for further processing. As this is proving challenging
due to the size of information, a balance between its business usage vs. storage needs to be considered; that is, only the
fraction of the data relevant to a business need may be stored for future reference.
 MANAGING M2M DATA
• Data processing
Data processing enables working with the data that is either at rest (already stored) or is in-motion (e.g. stream data). The
scope of this processing is to operate on the data at a low level and “enhance” them for future needs. Typical
examples include data adjustment during which it might be necessary to normalize data, introduce an estimate for a value
that is missing, re-order incoming data by adjusting timestamps, etc. Another example is the transformation of incoming
data; for example, a stream can be converted on the fly (e.g. temperature values are converted from Fahrenheit to
Centigrade), or repackaged in another data model, etc.
• Data remanence
As already discussed, M2M data may reveal critical business aspects, and hence their lifecycle management should
include not only the acquisition and usage, but also the end-of-life of data. However, even if the data is erased or
removed, residues may still remain in electronic media, and may be easily recovered by third parties - often referred to
as data remanence. Several techniques have been developed to deal with this, such as overwriting, degaussing,
encryption, and physical destruction. In light of the lack of cross industry M2M policy-driven data management, it also
might be difficult to not only control how the M2M data is used, but also to revoke/cancel access to it and “delete” them
from the Internet once shared.
• Data analysis
Data available in the repositories can be subjected to analysis with the aim to obtain the information they
encapsulate(summarize) and use it for supporting decision making processes. This stage is the basis for any
sophisticated applications that take advantage of the information hidden directly or indirectly on the data, and can be
used, for example, for business insights, etc.
BUSINESS PROCESSES IN IOT
 INTRODUCTION

• A business process refers to a series of activities, often a collection of interrelated processes in a logical
sequence, within an enterprise, leading to a specific result.
• There are several types of business processes such as management, operational, and supporting, all of
which aim at achieving a specific mission objective.
• As business processes usually span several systems and may get very complex, several methods and
techniques have been developed for their modeling, such as the Business Process Model and Notation
(BPMN), which graphically represents business processes in a business process model.
• Managers and business analysts model an enterprise’s processes in an effort to show the real way an
enterprise operates and subsequently to improve efficiency and quality.
• Several key business processes in modern enterprise systems heavily rely on interaction with real-world
processes, largely for monitoring, but also for some control (management), in order to take business-
critical decisions and optimize actions across the enterprise.
• The introduction of modern ICT has significantly changed the way enterprises (and therefore business
processes) interact with the real world.
• As depicted in the Figure, Initially all these interactions were human-based (e.g. via a keyboard) or human-
assisted (e.g. via a barcode scanner); however, with the prevalence of RFID, WSNs, and advanced networked
embedded devices, all information exchange between the real-world and enterprise systems can be
done automatically without any human intervention and at blazing speeds.
• In the M2M era, connected devices can be clearly identified, and with the help of services, this integration
leads to active participation of the devices to the business processes.
• This direct integration is changing the way business processes are modeled and executed today as new
requirements come into play.
• To this direction, the existence of SOA-ready devices (i.e. devices that offer their functionalities as a web
service) simplifies the integration and interaction as they can be considered as a traditional web service
that runs on a specific device.
• The industrial adoption of IoT (e.g. of wireless sensor networks) is disadvantaged by the lack of integration of
WSNs with business process modeling languages and back-end systems.
 IOT INTEGRATION WITH ENTERPRISE SYSTEMS

• M2M communication and the vision of the IoT pose a new era where billions of devices will need to interact
with each other and exchange information in order to fulfill their purpose.
• Much of this communication is expected to happen over Internet technologies and tap into the extensive
experience acquired with architectures and experiences in the Internet/Web over the last several
decades.
• More sophisticated, though still overwhelmingly experimental, approaches go beyond simple integration and
target more complex interactions where collaboration of devices and systems is taking place.
• In cross-layer interaction cooperation can be pursued:
• at the M2M level, where the machines cooperate with each other (machine-focused interactions), as well as
• at the machine-to-business (M2B) layer, where machines cooperate also with network-based services, business
systems (business service focus), and applications.
• As depicted in previous Figure, we can see several devices in the lowest layer.
• These can communicate with each other over short-range protocols (e.g. over ZigBee, Bluetooth), or even
longer distances (e.g. over Wi-Fi, etc.).
• Some of them may host services (e.g. REST services), and even have dynamic discovery capabilities based
on the communication protocol or other capabilities (e.g. WS-Eventing in DPWS- Devices Profile for Web
Services).
• Some of them may be very resource constrained, which means that auxiliary gateways could provide
additional support such as mediation of communication, protocol translation, etc.
• Independent of whether the devices are able to discover and interact with other devices and systems
directly or via the support of the infrastructure, the M2M interactions enable them to empower several
applications and interact with each other in order to fulfill their goals.
 THE CLOUD OF THINGS AS AN ENABLER FOR NEW
VALUE ADDED SERVICES & APPS

• Promising real-world integration is done using a service-oriented approach by interacting

directly with the respective physical elements, for example, via web services running on
devices (if supported) or via more lightweight approaches such as REST.
• Many of the services that will interact with the devices are expected to be available, for
example, in the cloud.
• The main motivation for enterprise services is to take advantage of the cloud
characteristics such as virtualization, scalability, multi-tenancy, performance, lifecycle
management, etc.
• Similarly, we expect to see that a large number of devices, and generally cyber-physical
systems, will make their functionality available on the cloud.
• As such, we are moving towards an infrastructure where the cloud and its services take a
prominent position towards empowering modern enterprises and their business
processes.
A key motivator is the minimization of
communication overhead with multiple
endpoints by, for example, transmission
of data to a single or limited number of
points in the network, and letting the
cloud do the load balancing and further
mediation of communication.

For instance, as depicted in the figure

above, a Content Delivery Network (CDN)
can be used in order to get access to the
generated data from locations that are far
away from the M2M infrastructure
(geographically, network-wise, etc.)
DISTRIBUTED BUSINESS PROCESSES IN IOT
 DISTRIBUTED BUSINESS PROCESSES IN IOT

• as seen on the left part of Figure, the integration of devices in business processes merely implies the
acquisition of data from the device layer, its transportation to the backend systems, its assessment, and
once a decision is made, potentially the control (management) of the device, which adjusts its behavior.
• However, in the future, due to the large scale of IoT, as well as the huge data that it will generate, such
approaches are not viable.
• Transportation of data from the “point of action” where the device collects or generates them, all the way to
the backend system to then evaluate their usefulness, will not be practical for communication reasons, as
well as due to the processing load that it will incur at the enterprise side; this is something that the current
systems were not designed for.
• Enterprise systems trying to process such a high rate of non- or minor-relevancy data will be overloaded. As
such, the first strategic step is to minimize communication with enterprise systems to only what is relevant
for business.
• With the increase in resources (e.g. computational capabilities) in the network, and especially on the
devices themselves (more memory, multi-core CPUs, etc.), it makes sense not to host the intelligence and
the computation required for it only on the enterprise side, but actually distribute it on the network, and even
on the edge nodes (i.e. the devices themselves), as depicted on the right side of Figure.