INTERNET OF THINGS

Software Architectures for Collaborative Systems

THOMAS TYTECA & SIMON VANDEPUTTE

2021-2022
Business and Information Systems Engineering
Table of contents
1. Introduction ............................................................................................................................................. 2

2. What is the Internet of Things? ................................................................................................................ 2

3. Importance of 5G for the IoT.................................................................................................................... 5

a. Why 5G....................................................................................................................................................... 5
b. Usage scenarios for 5G .............................................................................................................................. 7
c. NFV and SDN .............................................................................................................................................. 8

4. Resource discovery ................................................................................................................................ 10

a. Message Queuing Telemetry Transport (MQTT) ...................................................................................... 10
b. Universal Plug and Play (UPnP) ................................................................................................................ 12
c. Constrained Application Protocol (CoAP) ................................................................................................. 15

5. Link with other topics ............................................................................................................................ 16

a. Topic 35: Blockchain ................................................................................................................................. 16
b. Topic 24: Cluster computing - Hadoop ..................................................................................................... 16
c. Topic 25: Cluster computing - Spark......................................................................................................... 16
d. Topic 9: Streaming data - Kafka ............................................................................................................... 16
e. Topic 3: JavaScript - Node.js..................................................................................................................... 17
f. Topic 1: Web protocols - HTTP/2 .............................................................................................................. 17

6. Conclusion ............................................................................................................................................. 17

7. Appendix ............................................................................................................................................... 18

8. Bibliography........................................................................................................................................... 20

1
 1. Introduction
The Internet of Things (IoT) is everywhere in our lives: in our homes, in retail shopping, public
transportation, etc. However, not everyone knows precisely how it works. According to recent
estimates, there are approximately 15 billion IoT devices in the world today, which is almost double of
the human population.1 Going forward, IoT devices are expected to continue to grow much faster than
the quasi-saturated market of non-IoT devices. The current forecast is that there will be 30.9 billion
connected IoT devices by 2025, further driven by new technology standards like 5G.2 This enormous
number of devices illustrates the impact IoT has on the modern world and how this impact will only
get bigger over time. So, understanding the IoT is key to keep up with the modern-day world.

The goal of this paper is to, first, give a brief introduction to what the IoT is and how it is different from
the Web of Things. Secondly, the importance of 5G to the IoT will be made clearer. The subsequent
section will take a closer look at resource discovery in the IoT network, and lastly, links to various other
topics will be made.

2. What is the Internet of Things?

The Internet of Things can be defined as a system of physical objects that can be discovered,
monitored, controlled, or interacted with by electronic devices that communicate over various
networking interfaces, and eventually can be connected to the wider Internet.3 Hence, it enables
communication between internetworking devices and applications, whereby physical objects or
‘Things’ communicate through the Internet (or other communication technologies).4

A smart thing, which is also referred to as a Thing with a capital T, is a physical object that’s digitally
augmented with one or more of the following:3
• Sensors (temperature, light, motion, etc.)
• Actuators (displays, sound, motors, etc.)
• Computation (can run programs and logic)
• Communication interfaces (wired or wireless)

The Internet is a vast global network of connected servers, computers, tablets, and mobiles that is
governed by standard protocols for connected systems.4 In the IoT definition, the Internet part means
that the Thing (or at least its services or data) can be accessed and processed by other applications
through the existing Internet infrastructure. Note that this does not imply that the Thing itself must be
directly connected to the Internet.3

However, most IoT solutions on the market today have little in common with the Internet—a unique,
open, global network where everything is interconnected. That is because early IoT systems were
designed to operate in isolation. It is essentially a growing collection of isolated Intranets that can’t be
connected to each other and should therefore rather be called the Intranets of Things, which can be
considered as a set of isolated islands of functionality that weren’t designed to talk to each other.3

Opposed to the fragmented IoT, The Web of Things (WoT) is different, because it doesn’t care about
underlying networking protocols or standards, only about how to weave various isolated systems and
devices into a single, web-based ecosystem. Rather than inventing yet another protocol from scratch
(as many IoT projects do), the WoT reuses something that is already widely used to build scalable and
interactive applications, namely the web itself. In the Internet of Things, hundreds of incompatible
protocols coexist today, which makes the integration of data and services from various devices
extremely complex and costly. In the Web of Things, any device can be accessed using standard web

2
protocols. It uses readily available and widely popular web protocols, standards, and blueprints to
make data and services offered by Things more accessible to a larger pool of developers. The WoT
allows developers and applications to exchange data with any physical object or device using standard
HTTP requests, regardless of how the device is connected. Therefore, connecting heterogeneous
devices to the web makes the integration across systems and applications much simpler.3

The WoT is thus a specialization of the IoT that uses what made the web so successful, and applies it
to embedded devices to make the latest developments in the Internet of Things accessible to as many
developers as possible. This becomes clearer when considering the Open Systems Interconnection
(OSI) model, which can be seen on the left of Figure 2. Mapping any device into a web mindset makes
the Web of Things agnostic to the Physical and Transport Layer protocols used by devices. It is only
concerned with the highest OSI layer, the Application Layer, which handles applications, services, and
data. This is illustrated in Figure 1.3 5

Figure 1: Internet of Things versus Web of Things 3

Working with such a high level of abstraction makes it possible to connect data and services from many
devices regardless of the actual transport protocols they use. In contrast, the Internet of Things doesn’t
advocate a single Application-level protocol and usually focuses on the lower layers of the OSI stack.
The good news is that pretty much any custom IoT protocol or standard can be linked to the web
thanks to software or hardware bridges called gateways.3

The seven-layer OSI model is a standard model that gives the basic outline for designing a
communication network. In the same way, there are also models for the IoT domain. Several
international organisations have taken action for IoT design standardisation. One of them is the
Internet Engineering Task Force (IETF), a large open international community of network designers,
operators, vendors, and researchers concerned with the evolution of the Internet architecture and the
smooth operation of the Internet.6 The IETF initiated actions for addressing and working on
recommendations for the engineering specifications for the Internet of Things. They suggest
specifications for the layers and engineering aspects for the IoT communication, networks, and
applications. In order to obtain the resulting framework, IETF made modifications to the OSI model.4

Figure 2 shows this modified six-layer model proposed by IETF (in the middle), a classical seven-layer
OSI model (on the left), and the similarity with a conceptual framework (equation) for the actions and
communication of data across the different levels in IoT (on the right). Data communicates from
physical device end to application end. When data is transferred from a sensor, functional units create
a stack for data communication to an application or service. Each layer processes the received data
and creates a new header, which it then transfers to the next layer. The processing thus takes place at
the in-between layers, i.e. between the bottom functional-layer and the top layer. Device end also

3
receives data from an application/service after processing at the in-between layers, hence data is
communicated in both ways (as indicated by the arrows on the very right of Figure 2).4

Figure 2: Generalised OSI model (on the left), IETF modified OSI model for IoT (in the middle), and the equation as a
conceptual framework for IoT applications and services (on the right) 4

This comparison with the generalised OSI model shows how the Internet of Things focuses strongly on
the lower layers of the communication network (how data can be transmitted between actors) and
much less on how to facilitate the development of new applications (how data can be collected,
visualized, or processed). In particular, limited effort has been devoted to enable ad hoc
interoperability. The majority of IoT systems paid little attention to the issues of an open and large-
scale system of heterogeneous devices talking to each other, and consequently it is still difficult to
build scalable applications on top of these different devices. This is in clear contrast to the simple
integration across different systems and devices provided by the Web of Things.3

Besides the IoT’s interoperability issues, for which the web-based WoT proposes an alternative, there
are some other recurring concerns.

In terms of security and privacy, a largely connected system will always be more vulnerable than an
isolated one. But a system connected using open standards is usually better off than one based on
custom security mechanisms. Our computers, for example, could be isolated, but this would reduce
their range of applications. The IoT and WoT are no exceptions and we, as citizens, have a choice and
should weigh each of these new technologies on the balance between risks and benefits.3

And then there is of course the issue of the enormous increase in the number of Things connected to
the Internet. For any byte of data that is sent over the Internet, the Internet Protocol (IP) is used.
Currently, IP version 4 (IPv4) is the most widely used version of the protocol and offers approximately
4.3 billion unique IP addresses. When IPv4 was invented back in 1974, this seemed more than enough
to cater all the machines that would be connected to the Internet. However, Cisco estimates that there
are more than 15 billion things connected to the Internet today. In other words, we have been running
short of IPv4 addresses for quite some time.3 5

With the Internet of Things, this shortage has become a major hurdle. The first countermeasure was
the idea of Network Address Translation (NAT). Most routers and firewalls can perform NAT, and it has
become a cornerstone of today’s Internet of Things. But NAT is merely a patch because it adds lots of
complexity to the network. This led to the design of a longer-term solution: IPv6. This newer version
of the Internet Protocol allows 2128 unique addresses. So, it is safe to say that IPv6 will be instrumental

4
to IoT’s success at scale. But upgrading the whole Internet to IPv6 is no small matter, because this
requires upgrading pretty much anything that is connected to the Internet.3 5

Another issue that emerges due to this immense increase in the number of Things connected to the
Internet, is that 4G will not be able to support the whole network anymore. Therefore, the evolution
of 5G is so important for the IoT. Along with this increase in devices comes the additional storm of
data, for which technologies like NFV and SDN can provide a solution. These topics will be discussed
later on.

Furthermore, resource discovery in the Internet of Things is something that needs a closer look as well.
We already discussed WoT as an alternative to solve the difficult interoperability of heterogeneous
devices, but the issue of how to find devices and services within the IoT will also be considered in what
follows.

3. Importance of 5G for the IoT

Most of the IoT devices currently use the 4G network, but with the number of devices and connections
growing rapidly, it becomes clear that 4G is not capable of supporting this evolution. Hence, the
importance of 5G for the IoT. 5G is not only relevant in the context of the possibility to support more
devices and connections, but also to increase speed, to decrease latency and to be more reliable.

a. Why 5G

The 5G network has a lot of advantages, but also bring some challenges with it. We consider the most
important ones.

There are three different types of 5G spectrum bands. First, there is low band 5G that transmits on the
600 MHz frequency. One low band 5G tower can serve customers within hundreds of square miles, so
this enables nationwide coverage. Low band 5G peaks at a speed somewhere near 225 Mbps, which is
six to seven times faster than common 4G. In practice, a lower speed will be measured, but the worst-
case scenario for low band 5G is still better than 4G.7

Secondly, mid band 5G can be considered. Mid band 5G is also called “sub-6GHz”, because it includes
radio frequencies ranging from 2GHz to 6GHz, all of which have similar speed and distance
characteristics but may or may not be available for cellular use in certain countries. Regardless, towers
built with mid band radios can offer service within several-mile radiuses, so they can be used in
metropolitan and suburban regions. In the USA, the speed is at an average around as fast as low band
5G at its best, with the prospect of reaching 600-700 Mbps peaks in some markets. Outside the USA,
carriers are delivering 600-900 Mbps peaks and are expecting to deliver roughly 5 Gbps speeds over
mid band.7

Lastly, there is high band 5G. It represents high band mmWave 5G, which can reportedly reach peaks
of 7 Gbps. In practice, speeds between 1 and 3 Gbps can be measured, which is 30-80 times faster than
a typical 4G connection. The problem here is that the maximum range of such high band 5G antennas
is just around one mile and that buildings, trees or other obstructions can knock that distance down
or can snuff out mmWave signals altogether.7

So, high band 5G covers only a very small range, but the idea is to create a dense network of these
cells to provide appropriate coverage. This seems like a both cost- and labour-intensive idea, but a

5
bigger number of cells offers benefits as well. Every device in a cell (whether it be a micro- or a macro-
cell) communicates with the antenna on a dedicated channel. Therefore, considering that the number
of channels available is limited, deploying smaller cells with a shorter range pays off in an increased
number of channels available. Thus, smaller cells can accommodate more devices. In this way, 5G can
support up to a million devices per square kilometre, which is ten times more than 4G.8

To achieve more reliability, 5G makes use of network slicing (see Figure 3 for an example). This is a
type of network architecture that makes it possible to create completely independent, end-to-end,
virtual “slices” within the physical network, each of which caters to particular needs. All IoT projects
are understandably network-intensive overall. However, not all elements of the project have the same
network requirements, especially since IoT projects tend to be very broad and diverse, encompassing
a lot of different devices and applications. With network slicing, it is possible to “customize” network
parameters for different applications to allocate resources more effectively. Essential operations will
have steeper service level requirements and always take priority, even in critical conditions.8 This is
important for example for remote robot-assisted surgeries that demand perfect precision.

Figure 3: Example of network slicing 9

In the current 4G architecture, a device on a network is connected to the cloud, a setup that has
unexpected latency. But this is changing now with 5G. To fully realize 5G’s potential, the industry is
shifting to a decentralized model. In this new paradigm, intelligence is not just associated with a central
cloud but instead is distributed to the different parts that form the wireless edge: edge devices and
the edge cloud. With this distributed intelligence, on-device capabilities are required, including the
need to move, control, and augment content processing to the edge cloud, which is closer to the end-
devices. This will help realize low latency for certain applications. Alternatively, it could be distributed
deeper in the network, farther from the devices for latency tolerant services. This can be seen in Figure
4.

With the introduction of the edge cloud, on-device AI can work together with the advanced 5G network
and the edge cloud to deliver even more low latency benefits, and thus new capabilities and
experiences. Edge computing reduces latency because the processing happens closer to the user,
eliminating the need to send the data to the cloud and back.10

6
 Figure 4: A decentralised 5G architecture 10

The golden standard for latency for 4G is 10 milliseconds, while for 5G it is as little as 1 ms. For 5G IoT,
it might be a difference between life and death, if you consider its applications in autonomous cars
that need to make split (milli)second decisions in emergency situations.8

b. Usage scenarios for 5G

The three main usage scenarios for 5G, as defined by ITU-R (the International Telecommunication
Union Radiocommunications sector), are ultra-reliable low latency communications (URLLC),
enhanced mobile broadband (eMBB), and massive machine-type communications (mMTC).8

URLLC is a set of features that ensures the network will both have low latency and ultra-reliability at
the same time. This has applications in the life-or-death situations that already have been discussed.
In these scenarios, any network failure or lags would have catastrophic consequences, but URLLC is no
less important in mission critical operations. Examples of such mission critical operations are managing
electric power grids, first responder communication systems, or even online banking systems. All these
will increasingly rely on 5G IoT and will therefore need it to provide air-tight network conditions.8 The
main goal of URLLC is to minimize the latency down to 1ms and guarantee at least 99.999% reliability,
which are essential requirements in applications such as IoT, virtual reality and autonomous vehicles.
The key enablers to achieve this are network slicing and edge computing. Both of these concepts have
already been explained (cfr. supra).11

eMBB is a promise of handling massive amounts of data across large areas with low latency. It is
supposed to ensure perfect coverage in densely populated public spaces (for example at stadiums
during sporting events), as well as fully immersive VR. The latter one can put a heavy strain on the
network, as it requires very high resolutions and streams double the volume (separately to each lens).
But eMBB would have business applications too, allowing for high-speed data transfer (including data
upload) in smart offices, during virtual meetings, or real-time long-distance interpreting, always
ensuring high quality of experience.8

Finally, mMTC ensures that devices connected to the 5G IoT network can have both low power and
low data consumption. This is particularly important for all smart things that are connected into giant
networks: smart cities, smart factories, etc.8 Typical applications of mMTC are logging, metering,
tagging, and measuring.12

7
 c. NFV and SDN

Software Defined Networking (SDN) and Network Function Virtualization (NFV) are two of the most
prominent technologies to serve as key enablers for the IoT networks of the near future and are
needed to actualise the huge promises of the 5G network. Although they share many common
elements and the terms are often used interchangeably, they are distinct technologies that may work
in combination.13

Figure 5: Illustration of Software Defined Networking 13

The main idea behind SDN is to separate the control plane, where the logical procedures supporting
the networking protocols are executed and all the relevant decisions are taken, from the data plane,
where the forwarding of packets on the most suitable interface towards the intended destination is
executed. As illustrated in Figure 5, the main entity behind this separation is the controller, which
communicates with the network applications through the so-called northbound interface and
translates their requirements into appropriate network decisions. The controller also communicates
with the network switches that forward packets according to the controller-installed rules. This way,
SDN provides increased possibilities to smartly route traffic, for example to balance the load over the
network or to exploit underutilized network resources in an optimal way. It thereby alleviates the
burden on the network caused by the data storm of IoT.13

The SDN controllers control not only data forwarding, but also processing of data. The different
functions of SDN controllers are shown in Figure 6.

8
 Figure 6: Different functions of SDN controllers 14

SDN can be considered in the context of an SDN-based IoT architecture as well. The lowest layer in this
architecture is the Device Layer, which contains sensors collecting a large amount of data in different
formats and potentially for different IoT application domains. Some devices can also act as actuators
receiving commands from the network and performing tasks. The Communication Layer is comprised
of SDN gateways and routers, which can forward data under the control of an SDN controller. The
Computing Layer contains SDN controllers and the accounting and billing mechanisms. They control
the forwarding of data according to the requirements of applications. The service developers and
operators build IoT services at the Service Layer by programming the SDN controllers. This architecture
is illustrated below, in Figure 7.14

Figure 7: An SDN-based IoT architecture 14

9
For NFV, the rise of powerful general-purpose hardware, cloud computing technology, and flexible
software defined networks, led to the first idea of virtualizing classical network functions, such as
routers, firewalls, and evolved packet cores. These network functions, which have been executed on
dedicated and often specialized hardware before, now run as software applications in virtual machines
on top of cloud infrastructure. NFV aims at creating an architecture that builds failure management
into every part of the system and horizontally partitions it to limit single points of failure.9

So, the difference between NFV and SDN is that NFV is more targeted at service providers and
operators and helps them to virtualize functions like load balancing, routing, and policy management
by transferring network functions from dedicated appliances to virtual servers. SDN, on the contrary,
focuses mainly on data centres and helps them to separate the control plane and the data forwarding
plane by centralizing the control and programmability of a network.15

4. Resource discovery

The high diversity of IoT objects, along with their different properties and capabilities, pose significant
challenges on the realization of open and interoperable IoT platforms. Resource discovery is a key
concept that enables smarter interactions and communications between different IoT artifacts. The
ultimate objective of resource discovery in IoT environments is to find devices and services of interest
for the requesting entity.16

Many protocols have been introduced to meet the challenges of discovery: dedicated discovery
protocols like Universal Plug and Play (UPnP), but also messaging protocols like Advanced Message
Queuing Protocol (AMQP) or Message Queuing Telemetry Transport (MQTT), and communication
protocols like Constrained Application Protocol (CoAP). These four are the most important ones. Here,
MQTT, UPnP and CoAP will be discussed.16

a. Message Queuing Telemetry Transport (MQTT)

Message Queuing Telemetry Transport is a lightweight M2M pub/sub messaging protocol, most
suitable for constrained networks. MQTT primarily uses the TCP/IP stack, but there is an extension
implementation called “MQTT-S” for non-TCP/IP stacks. In MQTT, every sensor subscribes to a broker
over TCP as shown below in Figure 8. An MQTT user publishes a message to the broker and interested
users subscribe to topics announced by the server (broker) to receive updates. Topics are published by
messages to unique addresses. Users can subscribe to multiple topics and in this way receive messages
that were published to these topics. A topic is a UTF-8 string that consist of one or more topic levels
separated by a forward slash “/” to create a defined hierarchy of information. The MQTT message
format has a 2-bytes fixed header and a payload message up to 256 MB. MQTT uses TLS/SSL as a
security protocol.

MQTT can support large networks with devices that require to be controlled or monitored from the
back-end server on the Internet. It also supports device-to-device communication or multicasting to
many recipients. Although MQTT is a great IoT messaging protocol, it has a several limitations
including: (1) an always-on connection which limits the sleep time mode of devices; (2) lack of support
for message labelling which makes it difficult for clients to understand the meaning of the messages.
All devices connected through the MQTT protocol must subscribe to the broker, so they can be looked
up for discovery requests. Therefore, MQTT can be considered for resource discovery.16

10
 Figure 8: Illustration of MQTT 16

Now, the MQTT protocol will be illustrated by a very simple example. The goal is to let a client subscribe
to the broker $SYS topic tree, capture the MQTT messages via Wireshark, and then interpret them.
The $SYS topic tree is a reserved topic and is used by most MQTT brokers to publish information about
themselves. They are read-only topics for the MQTT clients.17

First, the client is created in Python, for the code see Figure 14 in the appendix. After this is done,
Wireshark should start capturing packages on the Wi-Fi that is currently used, and next, the client
should be run. The client will subscribe to the broker $SYS topic tree, which means that it will make a
TCP connection, via a three-way handshake, with the broker. In this way, the client can receive
published messages to these topics.

We now interpret the different MQTT messages captured by Wireshark, shown below in Figure 9.

Figure 9: Wireshark capture of MQTT

The first MQTT package that is captured, shows the connect command from the client to the broker.
The IPv4 address of the source, the client, is 192.168.1.16, which means that it is a private address (this
can be seen in Figure 15 in the appendix); whereas the IPv4 address of the destination, the broker, is
137.135.83.217, which means that it is an address owned by Microsoft (this can be seen in Figure 16
in the appendix). The second package shows then that the broker acknowledges the connection. The
output that appears on the screen can be seen in Figure 17 in the appendix. The result code “0” means
that the connection is accepted.
In the third package can be seen that the client sends a request to subscribe to the broker $SYS topic
tree. In the next line, this request is acknowledged by the broker.
Packages 5,6,9,10,11 and 12 can be interpreted in the same way: the broker publishes messages about
certain topics from the $SYS topic tree. This topic tree consists of multiple levels that are separated by
a forward slash “/” to create a defined hierarchy of information. So, the client receives messages from
all the topics part of the $SYS topic tree, because of its subscription to the whole tree. In line 5, the
client receives a package that includes different messages (this can be seen in Figure 18 in the

11
appendix), the meaning of the different messages will not be discussed further. By including different
messages in one package, bandwidth is saved, so this is an advantage of MQTT. Packages 6,9,10,11
and 12 should be interpreted in the same way as line 5, with the exception that they handle different
messages.
Packages 7, 8, 13 and 14 can be interpreted in the same way as well. In packages 7 and 13, the client
sends a regular Ping Request message to the broker; the broker then responds back with a Ping
Response (package 8 and 14). This mechanism will allow both sides to determine if the other one is
still alive and reachable.18 The Ping Request and Response interaction happens every 5 seconds,
because it is programmed this way, see line 18 in Figure 14 in the appendix.

b. Universal Plug and Play (UPnP)

Universal Plug and Play is a set of networking protocols that enable communication between
networking devices. The foundation for UPnP networking is IP addressing. Each UPnP-enabled device
must implement a Dynamic Host Configuration Protocol (DHCP) client to connect to the DHCP server
in the network in which the device is joining. If no DHCP server is available, the device must assign itself
an address, using the UPnP built-in feature which is called AutoIP.16 19
Once a device has established an IP address, the next step in UPnP networking is discovery. The UPnP
discovery protocol is known as the Simple Service Discovery Protocol (SSDP). When a device is added
to the network, SSDP allows that device to advertise its existence to control points in the network. This
is achieved by sending SSDP alive messages. The data exchanged between the device and the control
point is restricted to discovery messages that provide essential information about the device and its
services (e.g. its type, identifier, a pointer to more detailed information, etc.).16 19
The control point retrieves the device's description from the location (URL) provided by the device in
the discovery message. The description is expressed in XML and includes information like the model
name and number, serial number, manufacturer name, a list of any embedded services, etc. For each
service, the device description document lists the URLs for control, eventing, and service description.
Each service description includes a list of the commands to which the service responds, parameters for
each command, and a list of variables that model the state of the service at run time.19
Having retrieved a description of the device, the control point can send actions to a device's service by
sending a suitable control message to the control URL for the service. Control messages are also
expressed in XML using the Simple Object Access Protocol (SOAP). Much like function calls, the service
returns any action-specific values in response to the control message. The effects of the action, if any,
are modelled by changes in the variables that describe the run-time state of the service.19
Let us take a closer look at SSDP, which is the backbone of the UPnP architecture. It is a zero-
configuration networking protocol that allows to easily interconnect home devices that work within
the same small network or are connected to the same Wi-Fi point. Using SSDP, devices communicate
information about themselves and the services they provide to any other UPnP client. Besides learning
about each other, they also get the opportunity to interact in some way (exchange data, launch
functions and services on another device, etc.).20 To do so, SSDP uses two different kinds of HTTP
methods:
- The method NOTIFY (alive or byebye message) is used to announce the establishment or
withdrawal of services to the multicast group.
- The method M-SEARCH (discovery message) is used to discover available services on a
network.21

12
Responses to the search requests are sent via unicast addressing to the originating address and port
number of the multicast request.21
Hence, in its most general form, the connection of a new device looks like this. To find out which
devices are already present on the network, a device added to it with SSDP enabled sends a search
request to other devices to the reserved (IPv4) address (239.255.255.250) and UDP port (1900), using
multicasting. In the request, the device specifies a template or target corresponding to its type. In
response to the request, each of the devices on the network that supports SSDP sends a UDP message
with information about itself to the source IP address and port from which the request was sent.20
To illustrate this protocol, we look at an application of SSDP in an IoT setting. In 2013, music streaming
platform Spotify introduced Spotify Connect. With this tool, people can use one device to remotely
control listening on another.22 It enables users to stream their favourite music and podcasts across
many devices at home and on the go.23 The screenshots in appendix Figure 19 and Figure 20 show the
Spotify interface with Spotify Connect on a desktop and a smartphone.
To inspect how these devices interoperate over the Internet, we connect a laptop and a smartphone
to a Wi-Fi network. With Wireshark, we can then capture the network traffic. Because we are not
interested in all traffic that is transmitted across the network, the "enable promiscuous mode on all
interfaces" box in the Capture Options window is unticked. This way, we will capture only the packets
the laptop is sending, packets which others send solely to it, and broadcast/multicast packets.

Figure 10: Wireshark capture of Spotify Connect session

Figure 10 shows the packages captured during a session where Spotify was playing music on the laptop
at first, after which it shifted to continuing the music on the smartphone by using Spotify Connect. In
the figure, the packages coming from the smartphone (both the IPv4 and the IPv6 address) are
indicated in dark blue and the ones coming from the laptop (also IPv4 and IPv6) in light blue. The
display filter is just a UDP filter because SSDP (and mDNS, cf. infra) uses UDP as underlying transport
protocol.
When analysing the Wireshark capture, we notice a couple of things. First of all, we see that the SSDP
M-SEARCH method is sent from the laptop as well as from the smartphone to the SSDP multicast
address24 239.255.255.250, and that this happens every two seconds. That is because SSDP uses the

13
unreliable UDP transportation protocol (because UDP supports multicasting). UDP is unreliable
because there is no acknowledgement if a message made it to its destination. This means there is no
way of knowing if a service has not responded because the message was dropped along the way or
because the service is no longer available. While not fool proof, it is possible to increase the reliability
of an SSDP-based discovery service by sending multiple M-Search messages. Sending multiple M-
Search messages will increase the chances that at least one message makes it to each device on the
network.25
When dissecting these SSDP packages, we observe the package information shown in Figure 11.

Figure 11: SSDP package in Wireshark

The search target (ST), which refers to the service, the search request is attempting to discover,
dictates urn:dial-multiscreen-org:service:dial:1\r\n.25 DIAL (for DIscovery And Launch) is a simple
protocol that second-screen devices can use to discover and launch apps on first-screen devices. For
example, suppose you discover a video on your mobile app and want to play it on your connected TV.26
This explains Spotify Connect’s use of SSDP: the laptop and the smartphone search for other Spotify
Connect-enabled devices where they can launch the Spotify app on by using multicast.
Secondly, we notice another protocol besides SSDP, namely the multicast Domain Name Service
(mDNS). Apparently, Spotify Connect uses both SSDP and mDNS. The latter is a zero-configuration
service, using essentially the same programming interfaces, packet formats and operating semantics
as unicast Domain Name Service (DNS). It resolves hostnames to IP addresses within small networks
that do not include a local name server. To do so, it sends an IP multicast query message that asks the
host having that name to identify itself.27
In Figure 10, we can see that mDNS packages are being sent via both IPv4 and IPv6 with the respective
mDNS multicast addresses 224.0.0.251 and ff02::fb.24 As was the case for SSDP, the mDNS queries are
also retransmitted every two seconds, due to the same reason. Taking a closer look at such an mDNS
package (as shown in Figure 12), we can say a few things about the queries.

Figure 12: mDNS package in Wireshark

14
Firstly, the name of the node to which the query pertains, ends in “.local”, which means it only has
local significance and therefore must be sent to the multicast addresses. Furthermore, the “QM
question”, also indicated as “QU question: False”, requests that the question receives a multicast, and
not a unicast, response. The target device then multicasts a message that includes its IP address, and
all devices in that subnet can then use that information to update their mDNS caches.28 27
This might explain the UDP packages in frame 248 and 249 of Figure 10, where the laptop and the
smartphone both broadcast a UDP message over the network: they are probably responses to the
mDNS queries. These two packages, together with the UDP package in frame 250 going from the laptop
to the smartphone, are always captured when switching the Spotify music from playing on the laptop
to playing on the smartphone. Unfortunately, Wireshark cannot interpret the data of these packages,
so we cannot be entirely sure that this is their meaning.

c. Constrained Application Protocol (CoAP)

The IETF proposed the Constrained Application Protocol to provide an efficient and flexible protocol
based on the RESTful web service architecture in constrained environments. CoAP is used to
manipulate or discover resources by using the basic HTTP verbs: GET, POST, DELETE, and PUT. CoAP
uses a binary message format and requires 4-bytes of a fixed header with a payload message up to a
maximum size, depending on the programming technology or the web server. CoAP uses UDP as a
Transport Layer protocol, and Datagram Transport Layer Security (DTLS) for security.16

For an endpoint to find the Resource Directory (RD), it must send a multicast or unicast GET request (a
service discovery request) to the default entry point, which is at /.well-known/core, where the RD
presents a RESTful web service. The goal of this request is for the CoAP user to receive back a list of
links about the available resources, attributes of the resources, etc.

After the RD is found, the CoAP user can manipulate or discover specific resource types by using the
basic HTTP verbs. An example of a request/response message exchange in CoAP using the GET method
is shown in Figure 13. This example shows a GET request to a temperature sensor. The server then
sends the response (temperature value) to the user. The response code is 2.02, which means a success
response. In general, 2.xx code indicates success, 4.xx code indicates a user error, and 5.xx code
indicates a server error.16

Figure 13: Illustration GET method 16

The main drawback of CoAP is that it is a one-to-one protocol, so broadcast capabilities are not allowed
by the protocol. However, CoAP supports multicast over UDP.16

Normally, CoAP can be illustrated in Wireshark as well, but due to errors in the programming and
running of the CoAP client, we were not able to include this in the paper. The errors are shown in
Figure 21 and 22 in the appendix.

15
 5. Link with other topics

a. Topic 35: Blockchain

A blockchain is a distributed and decentralized ledger that contains connected blocks of transactions.
Unlike other ledger approaches, blockchain guarantees tamper proof storage of approved
transactions. Due to its distributed and decentralized organization, blockchain is being used within IoT
to e.g. manage device configuration, store sensor data and enable micropayments.29 Blockchain can
enrich the IoT by providing a trusted sharing service, where information is reliable and traceable. Data
sources can be identified at any time and data itself remains immutable over time, increasing its
security. In the cases where the IoT information should be securely shared between many participants
this integration would represent a key revolution. Blockchain technology is being identified as the key
to solve scalability, privacy, and reliability problems related to the IoT paradigm.30

b. Topic 24: Cluster computing - Hadoop

Apache Hadoop is a powerful open-source framework being utilized by several organizations for
analysing and processing data gathered by the IoT with the help of a concept known as cluster
computing. Various correlations can be made between distinct types of unstructured data, hereby
providing an enterprise a level of competitive advantage in the industry. Large enterprises like Amazon,
Walmart, and Macy’s are leveraging IoT data using Hadoop and streaming analytics to find actionable
big data insights from various IoT data sources.31

c. Topic 25: Cluster computing - Spark

Apache Spark is a big data technology used to process data on a large scale by means of cluster
computing. Apache Spark can be termed as an updated version of Apache Hadoop. The advantage of
Spark over Hadoop is that Spark performs the same actions as in Hadoop 10 to 100 times faster. It
provides the benefit of easy programming, which makes it much more preferable for amateur
programmers over Hadoop. The issue of big and complex connected data that is to be stored and
processed can be easily resolved in Spark. When dealing with real-time data feeds, Spark Streaming, a
fundamental in Apache Spark, is used to stream and process the data.32

d. Topic 9: Streaming data - Kafka

Apache Kafka is a distributed stream processing platform for big data systems. Working similarly to
enterprise messaging systems, Kafka stores streams of records, so that developers don’t have to code
data pipelines manually for each source-destination pair. Amongst Kafka’s most prominent features
are its scalability, speed, and fault-tolerance. One common use case for Kafka has become real-time
analytics, due to the platform’s handling of multiple live data feeds.33

Through Kafka, it is possible to take up a vast amount of data for both real-time analytics and batch
processing. For instance, data pertaining to ambient temperature would be more suitable to follow
the real-time route, as immediate adjustments to your heating system would be desired, based on
current readings. In contrast, data corresponding to light usage or power consumption for efficiency
analysis may require a more prolonged monitoring for more accurate results. Whatever the case may
be, Kafka can streamline data delivery and maintain the robustness of the data processing pipeline.

16
This is because it is platform independent. So, for large-scale data sets, Kafka will lead to optimal results
in real-time.33

e. Topic 3: JavaScript - Node.js

There are numerous programming languages available like Python, C++, Ruby, etc. These languages
can assist in the building of IoT platforms, but JavaScript is the one that works best in the development
of IoT platforms. Node.js has fast data synchronization abilities that minimize the time needed to send
and receive data from the servers. The transfer happens in real-time, which ultimately makes IoT
devices responsive and efficient. Moreover, the security of IoT devices lies in code architecture and
user authenticity, and Node.js is able to deliver these needs without fail. Additionally, Node.js supports
MQTT and WebSockets protocols. These protocols are used in IoT applications for interaction with
each other in a network. So, Node.js gives a base for the application to connect with a third party and
independent services as well.34

f. Topic 1: Web protocols - HTTP/2

HTTP/2 aims at enabling a more efficient use of network and server resources, and a reduced
perception of latency by introducing a header field compression facility and allowing multiple
concurrent exchanges on the single connection from browsers to a website. Furthermore, it introduces
the notion of streams as well: each client request is assigned to a particular stream, and all streams
are multiplexed over a single TCP connection. Therefore, requests do not influence each other and can
be simultaneously answered by the server. Hence, HTTP/2 solves the head of line blocking issue while
at the same time reducing the number of TCP connections to be handled on the server side. So, this
certainly has a positive impact on the handling of the data from the IoT.35

6. Conclusion
At the current moment, there is already an enormous number of IoT devices, and it is expected that
this will keep increasing in a spectacular way. Therefore, this paper tried to help understand the IoT,
as this is key to keep up with the modern-day world. First, the difference between the IoT and the Web
of Things was explained, as well as a brief explanation about the IoT itself. Next, the importance of 5G
to the IoT was made clear. In the part about 5G, the concepts of SDN and NFV were handled as well.
After this, resource discovery was covered, with illustrations for MQTT, a message protocol, and UPnP,
a dedicated discovery protocol. Lastly, some links with other topics were made.

17
7. Appendix

Figure 14: Python code implementation MQTT 36

Figure 15: IPv4 address 192.168.1.16 37

Figure 16: IPv4 address 137.135.83.217 37

Figure 17: Python program output 1

18
 Figure 18: Python program output 2

Figure 19: Spotify interface on a desktop with the Spotify Connect feature at the bottom right

Figure 20: Spotify interface on a smartphone with the Spotify Connect feature at the bottom left

19
Figure 21: CoAP error 1

Figure 22: CoAP error 2

20
 8. Bibliography
1
12 Fun Facts About IoT - 2021 [Internet]. Digi.com. 2021 [cited 12 December 2021]. Available from:
https://www.digi.com/blog/post/12-fun-facts-about-iot-2021
2
State of the IoT 2020: 12 billion IoT connections, surpassing non-IoT for the first time [Internet]. IoT
Analytics. 2021 [cited 12 December 2021]. Available from: https://iot-analytics.com/state-of-the-iot-
2020-12-billion-iot-connections-surpassing-non-iot-for-the-first-time/
3
Guinard D, Trifa V. Building the web of things. Shelter Island, NY: Manning; 2016.
4
Kamal R. Internet of Things: Architecture and Design Principles. New Dehli: McGraw Hill Education
(India) Private Limited; 2017.
5
Peterson L, Davie B. Computer Networks: A Systems Approach. 6th ed. 2019.
6
Who we are [Internet]. IETF. 2021 [cited 12 December 2021]. Available from:
https://www.ietf.org/about/who/
7
Horwitz J. The definitive guide to 5G low, mid, and high band speeds [Internet]. VentureBeat. 2019
[cited 12 December 2021]. Available from: https://venturebeat.com/2019/12/10/the-definitive-
guide-to-5g-low-mid-and-high-band-speeds/
8
5G IoT: What does 5G mean for IoT? [Internet]. Avsystem.com. 2021 [cited 12 December 2021].
Available from: https://www.avsystem.com/blog/5g-iot/
9
11. Yousaf F, Bredel M, Schaller S, Schneider F. NFV and SDN—Key Technology Enablers for 5G
Networks [Internet]. Ieeexplore.ieee.org. 2017 [cited 12 December 2021]. Available from:
https://ieeexplore.ieee.org/abstract/document/8060513?casa_token=fe_UtQcrJbUAAAAA:0H3aIa63
KwAtvfF_ tXeazKuy7M9Rl0IyRE-m8XK7V_qXV32o-OpgGVRvh9-pleox2Tea_bawQbn2
10
How 5G low latency improves your mobile experiences [Internet]. Qualcomm. 2019 [cited 12
December 2021]. Available from: https://www.qualcomm.com/news/onq/2019/05/13/how-5g-low-
latency-improves-your-mobile-experiences
11
Parisa N, Alves H, Uusitalo M, López O, Latva-aho M. Machine-type wireless communications
enablers for beyond 5G: Enabling URLLC via diversity under hard deadlines [Internet]. Elsevier; 2020
[cited 12 December 2021]. Available from:
https://www.sciencedirect.com/science/article/pii/S1389128619315361
12
Hyoungju J, Younsun K. Introduction to Ultra Reliable and Low Latency Communications in 5G
[Internet]. ResearchGate. 2017 [cited 12 December 2021]. Available from:
https://www.researchgate.net/profile/Hyoungju-
Ji/publication/316269999_Introduction_to_Ultra_Reliable_and_Low_Latency_Communications_in_5
G/links/58f94a714585152edecb1bff/Introduction-to-Ultra-Reliable-and-Low-Latency-
Communications-in-5G.pdf
13
Bizanis N, Kuipers F. SDN and Virtualization Solutions for the Internet of Things: A Survey [Internet].
Ieeexplore.ieee.org. 2016 [cited 12 December 2021]. Available from:
https://ieeexplore.ieee.org/abstract/document/7563828
14
Li Y, Su X, Riekki J, Kanter T, Rahmani R. A SDN-based architecture for horizontal Internet of Things
services [Internet]. Ieeexplore.ieee.org. 2016 [cited 12 December 2021]. Available from:
https://ieeexplore.ieee.org/abstract/document/7511053
15
Difference between SDN and NFV - GeeksforGeeks [Internet]. GeeksforGeeks. 2020 [cited 12
December 2021]. Available from: https://www.geeksforgeeks.org/difference-between-sdn-and-nfv/
16
Khalil K, Elgazzar K, Seliem M, Bayoumi M. Resource discovery techniques in the internet of things:
A review [Internet]. Elsevier; 2020 [cited 12 December 2021]. Available from:
https://www.sciencedirect.com/science/article/pii/S2542660520301256
17
Understanding MQTT Topics [Internet]. |. 2020 [cited 12 December 2021]. Available from:
http://www.steves-internet-guide.com/understanding-mqtt-topics/
18
Singh P. Capturing and Analysing MQTT Packets [Internet]. IoT Bytes. 2016 [cited 12 December
2021]. Available from: https://iotbytes.wordpress.com/capturing-and-analysing-mqtt-packets/

21
19
Universal Plug and Play - Wikipedia [Internet]. En.wikipedia.org. 2021 [cited 12 December 2021].
Available from: https://en.wikipedia.org/wiki/Universal_Plug_and_Play
20
What is SSDP and how it is used for DDoS-attacks [Internet]. StormWall. 2021 [cited 12 December
2021]. Available from: https://stormwall.network/knowledge-base/protocol/ssdp
21
Simple Service Discovery Protocol - Wikipedia [Internet]. En.wikipedia.org. 2021 [cited 12
December 2021]. Available from: https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
22
Spotify Connect - Spotify [Internet]. Spotify. 2021 [cited 12 December 2021]. Available from:
https://support.spotify.com/uk/article/spotify-connect/
23
Seven Years With Spotify Connect, Your Ultimate Listening Remote — Spotify [Internet]. Spotify.
2021 [cited 12 December 2021]. Available from: https://newsroom.spotify.com/2020-06-18/seven-
years-with-spotify-connect-your-ultimate-listening-remote/
24
Multicast address - Wikipedia [Internet]. En.wikipedia.org. 2021 [cited 12 December 2021].
Available from: https://en.wikipedia.org/wiki/Multicast_address
25
Boles W. Discovering what's out there [Internet]. William Boles. 2019 [cited 12 December 2021].
Available from: https://williamboles.me/discovering-whats-out-there-with-ssdp/
26
DIAL [Internet]. Dial-multiscreen.org. 2021 [cited 12 December 2021]. Available from:
http://www.dial-multiscreen.org/
27
Multicast DNS - Wikipedia [Internet]. En.wikipedia.org. 2021 [cited 12 December 2021]. Available
from: https://en.wikipedia.org/wiki/Multicast_DNS
28
Atlasis A. Mutlticast DNS (mDNS) [Internet]. [cited 12 December 2021]. Available from:
https://sfc6326dbff511243.jimcontent.com
29
Samaniego M, Jamsrandorj U, Deters R. Blockchain as a Service for IoT [Internet].
Ieeexplore.ieee.org. 2017 [cited 12 December 2021]. Available from:
https://ieeexplore.ieee.org/abstract/document/7917130
30
Reyna A, Martín C, Chen J, Soler E, Díaz M. On blockchain and its integration with IoT. Challenges
and opportunities [Internet]. Elsevier; 2018 [cited 12 December 2021]. Available from:
https://www.sciencedirect.com/science/article/pii/S0167739X17329205#sec3
31
Industry Interview Series-How IoT leverages Hadoop? [Internet]. ProjectPro. 2021 [cited 12
December 2021]. Available from: https://www.projectpro.io/article/industry-interview-series-how-
iot-leverages-hadoop/110
32
12. D'silva G, Khan A, Bari S. Real-time processing of IoT events with historic data using Apache
Kafka and Apache Spark with dashing framework [Internet]. Ieeexplore.ieee.org. 2017 [cited 12
December 2021]. Available from:
https://ieeexplore.ieee.org/abstract/document/8256910?casa_token=KvyZhTkn_bUAAAAA:4a6s3E3f
gFChs5fUfSa0UDqxumTfszKlflh1sWM5DOdicsbjvC8cucOWAb3FB5QgcYrqjmre6A
33
IoT and Apache Kafka - CloudKarafka, Apache Kafka Message streaming as a Service [Internet].
Cloudkarafka.com. 2017 [cited 12 December 2021]. Available from:
https://www.cloudkarafka.com/blog/apache-kafka-iot.html
34
Kundariya H. Node.js - Why is it the Future of IoT Platforms? [Internet]. ITChronicles. 2021 [cited 12
December 2021]. Available from: https://itchronicles.com/iot/node-js-why-is-it-the-future-of-iot-
platforms/
35
Elmangoush A. [Internet]. ResearchGate. 2017 [cited 12 December 2021]. Available from:
https://www.researchgate.net/publication/320453832_Evaluating_the_Features_of_HTTP2_for_the
_Internet_of_Things
36
Craggs I. Eclipse Paho | The Eclipse Foundation [Internet]. Eclipse.org. 2021 [cited 12 December
2021]. Available from: https://www.eclipse.org/paho/index.php?page=clients/python/index.php
37
Whois-RWS [Internet]. Whois.arin.net. 2021 [cited 12 December 2021]. Available from:
https://whois.arin.net/ui/

22