Chapter 16: Internet of Things

This chapter provides a brief introduction to the Internet of Things.

We will show you how the Internet evolved from the simple idea of
connection two machines, like we did in Chapter 11, to its current form
where millions of machines from mainframes, server farms,
desktops/laptops, tablets/phones, all the way down to little embedded
devices, seamlessly communicate with each other.

Learning Objectives:
 The Internet in a nutshell – The layered model
 The Internet is the Transport and Network layers (TCP/IP)
 Media Access Control (MAC) – Data-Link and Physical Layers
 The CC3100 Boosterpack for Launchpad
 Application Layer Client-Server protocols – SMTP, HTTP, FTP, POP,
IMAP.

16.1. The Internet in a nutshell

Much has been written about the Internet with the current buzz being the
so called “Internet of Things”. Let’s see how we got here.
Recall in Chapter 11, the simple notion of two LaunchPads communicating
with each other shown in Figure 16.1.

The Media Access Layer.

 Imagine this 3-wire cable (TxD line, RxD line, and Common Ground) being
extended to ten meters. We now have two machines that could possibly be
located in separate rooms connected to each other and exchanging
information.
Going a farther distance of a hundred meters, across buildings say, will
require some hardware to boost the signal. It is an obvious next step to want
more machines to connect with each other.

Rather than lay a separate cable for each pair, it makes sense to leverage a
single cable that each machine could tap into. The TM4C123 does have eight
UART ports, meaning we could connect nine LaunchPads together such that
there is a dedicated connection between each pair.

However, if we connect n computers together like this, the interconnection

scheme would require (n-1) UART ports and ½*n*(n-1) cables.
 The TM4C123 does have 8 UARTs, so you could create a network of 9
microcontrollers. However, this small network would require 36 cables.

You can see from Figure 16.2, the complexity of the network grows on
order n2, which we label as O(n2).

Figure 16.2 Network created with direct connections, or point-to-point communication,

using UARTs grows in complexity on O(n2).

This approach becomes impractical even for a small set of machines.

Also, the labor cost of laying cable dominates most network infrastructure.
To make it practical, we will need to connect multiple nodes into the same
cable.

Once you have multiple machines tapping into the same cable (we call this
the network) we will need the machines to adhere to a “protocol” that will
allow them to communicate with each other effectively.

Furthermore, each network interface will need a unique identity, its

hardware address. A simple protocol could be for each machine to get a turn
(say a token) during which it communicates with another machine that has
tapped into the same network.

One of the early implementations of this model was the IEEE 802.5 Token
Ring protocol where the cable was a loop (a ring), see Figure 16.3.
Figure 16.3 Network created by connecting to a ring. Each
node only requires one connection. In this figure node

An alternate “protocol” choice is for each machine to try to communicate

as a when it wants to, by sensing whether the network is idle.

If another machine attempted to communicate at the same then this

would cause a collision and the machines follow a pattern of reattempting to
communicate that reduces chances of further collisions.

An implementation of this model of communication was at the forefront of

the emergence of the Internet. This was the IEEE 802.3 Carrier Sense
Multiple Access-Collision Detection (CSMA/CD) protocol or popularly
recognized as Ethernet, see Figure 16.4.

Figure 16.4 Network created by using an Ethernet switch.

 When we use microwave transmission (instead of a cable) we have
wireless communication in the 2.4, 3.6, 5 and 6 GHz frequency bands, which
is standardized as the WiFi IEEE 802.11 and the Bluetooth IEEE 802.15
protocols, Figure 16.5.

These wireless standards use variations of the Carrier Sense Multiple

Access-Collision Avoidance (CSMA/CA) protocol.

Figure 16.5 Network created by using wifi, which

communicates wirelessly.

Once we configure machines to communicate with each to other as a

small local area network (LAN), the next logical challenge is to make multiple
such LANs to communicate with each other. This interconnection of
networks is the Internet.

The Network layer

The collective issues concerning the interconnection of networks are

addressed by what is called the Network layer.

The first issue is one of identities. For machines to learn identities of the
(possibly hundreds of) machines in other LANs , we need a naming
mechanism and accompanying discovery methods.

This naming mechanism gives each machine a “unique” identity called, its
IP (Internet Protocol) address.
 A more appropriate name for this identity would be Internet address, as it
is the address by which machines connected to the interconnection of
networks are identified.

The IP address is a 32-bit numerical identity that is written in a “dot”

format, for example, 128.83.40.146. Each of the four numbers can be 0 to
255, meaning each is an 8-bit byte.

Together, the four numbers represent a 32-bit IP address. It is easy for a

small set of machines in a LAN to learn the IP addresses of each other, there
is a protocol called Address Resolution Protocol (ARP) that accomplishes
this.
The ARP protocol’s target is to get every machine to learn the hardware
address (aka the MAC address) and the corresponding IP address of every
other machine in a LAN.

The 32-bit IP-address that is unique to each machine poses the problem of
being hard to remember, like phone numbers. A lookup service called
Domain Name Service (DNS), maps a symbolic name (like www.utexas.edu)
to its corresponding IP address.

The second issue that the Network layer addresses is routing. That is,
the movement of information (packaged in chunks called Datagrams) from
one machine to another in an optimal way.
Figure 16.6. The internet is a network of networks

The Transport layer

Now imagine Bob lives in New York city with a unique address and Mary
lives in Austin, and the two exchange communications with each other the
old-fashioned way by writing letters.

If little Bobby in Bob’s house wants to write to Little Suzy in Mary’s house,
then Bobby would write Suzy’s name on the letter sent to Mary’s household.
This way, multiple people in Mary’s household receive letters at the same
address but the letter is addressed to them individually.

The equivalent of this in the Internet is a port. Each machine has multiple
ports at which it can send and receive messages. Furthermore, these ports
fall into two categories, TCP ports and UDP ports. TCP ports provide reliable
communication (akin to say registered post) and UDP ports provide
unreliable best-effort communication.

The Transport layer is responsible for providing this abstraction of ports

and their related implementation. To stretch the analogy further, you may
think of TCP as being a guaranteed post (say registered mail that requires an
explicit acknowlegement of delivery) and UDP being normal post (a best-
effort delivery).

Therefore, an end-point of communication can be seen as containing a port

number, its type (TCP/UDP) and the IP address. A socket captures this end-
point from a programmer’s perspective.
Therefore, programming in the Internet is nothing but programming the
socket API, where different applications running on different machines
across the Internet, exchange information.

Not everybody fancies writing code using the socket API, so higher level
Application layer protocols, like HTTP, SMTP, FTP, have been developed
that serve a specific purposes of hyper-text transfer, mail-transfer, file-
transfer respectively.
 These Application layer protocols use sockets that are TCP-based for
reliability. Multimedia applications like VoIP use UDP sockets as the goal
there is speed and not reliability. So, the layered model that the Internet uses
can be seen as having four layers:

 the Application layer,

 the Transport layer,
 the Network layer and
 the Media Access Layer.

This is popularly referred to as the TCP/IP model. The OSI model, which
the TCP/IP model is said to be compliant with, defines more layers but the
correspondence between the two can be seen in Figure 16.7.

For an excellent description of the TCP/IP (Transmission Control

Protocol/Internet Protocol) protocol the reader is referred to W. Richard
Stevens, TCP/IP Illustrated, Volume 1: The Protocols.

Figure 16.7. The TCP/IP model has four layers.

 Note also that the layered model can clearly be perceived by looking at the
format of data at each layer as seen in Figure 16.8.

User data, which is application dependent, is tagged with an application

header that is specific to the application and serves to convey how the data
must be interpreted. Together this is a message.

The Transport layer tags the message with a TCP/UDP header that among
other things has the port information and checksum for integrity. This is
referred to as packet or segment.

The Network layer adds the IP address and routing information in the form
of an IP header, giving us an IP datagram.

The Data Link layer adds its own protocol specific header to form a frame.

Figure 16.8. Overview of message packets used at various layers.

16.2. Internet of Things
With the proliferation of embedded systems and the pervasiveness of the
Internet, it is only natural to connect the two.

The Internet of Things (IoT) is the combination of embedded systems, which

have sensors to collect data and actuators to affect the surrounding, and the
internet, which provides for ubiquitous remote and secure communication.

This section will not describe how the internet works, but rather we will
discuss both the general and specific approaches for connecting embedded
systems to the internet.
For a general description of the internet of things, see Vasseur and
Dunkels, Interconnecting Smart Objects with IP. This book provides a good
overview of network technologies used for connecting devices.

Figure 16.9. The internet of things places input, output and

processing at multiple locations connected together over the
internet.

Figure 16.9 illustrates the distributed approach taken with the internet of
things.
A distributed solution deploys multiple sensors and actuators connected
by the internet. Another name given for an embedded system connected to
the internet is smart object.
 Smart objects include sensors to collect data, processing to detect events
and make decisions, and actuators to manipulate the local environment.

There are many reasons to consider a distributed solution (network) over

a centralized solution. Often multiple simple microcontrollers can provide a
higher performance at lower cost compared to one computer powerful
enough to run the entire system.

Some embedded applications require input/output activities that are

physically distributed. For real-time operation there may not be enough time
to allow communication between a remote sensor and a central computer.

Another advantage of distributed system is improved debugging. For

example, we could use one node in a network to monitor and debug the
others.

Often, we do not know the level of complexity of our problem at design

time. Similarly, over time the complexity may increase or decrease.

A distributed system can often be deployed that supports scaling. For

example, as the complexity increases more nodes can be added, and if the
complexity were to decrease nodes could be removed. Table 16.1 lists some
existing applications and the things they sense or control.

Industrial Automation Factories, machines, shipping

Environment Weather, pollution, public safety
Smart Grid Electric power, energy delivery
Smart Cities Transportation, hazards, public services
Social Networks Ideas, politics, sales, and communication
Home Networks Lighting, heat, security, information
Building Networks Energy, hazards, security, maintenance
Structural Monitors Bridges, roads, building
Health Care Heart function, medical data, remote care
Law enforcement Crime, public safety
Table 16.1. Applications of smart objects.
Challenges. On a local scale, the design of smart objects faces the same
challenges existing in all embedded systems: power, size, reliability,
longevity, and cost.
Luckily the deployment of billions of microcontrollers into the market has
created a technology race to reduce power, size and cost while increasing the
performance.
At the microcontroller level things are getting smaller, but at the network
level, complexity is increasing and protocols are constantly changing as the
world’s thirst for information and communication rapidly grows.

Standardization. The existence of standards allows for a wide variety of

objects to communicate with each other. Adhering to a standard will increase
the acceptance of our device by customers, and allow our customers to apply
our device to solve problems we never envisioned.
uIP is a light-weight implementation of the IP stack specifically designed to
operate with the available memory resources of smart objects.
In this section we will start with a microcontroller with the hardware and
software to implement TCP/IP protocols, and build our application on top of
this standard.

Interoperability means our device can function with a wide range of other
devices made with different technologies, sold by different vendors, and
produced by different companies.

Evolution is process of how new technologies are introduced into the

market. If there is one constant in this world, it is that things will change.
Every thousand years, one big discovery fundamentally changes how we
operate (fire, language, metal tools).
More frequently, change is introduced gradually such that those
technologies that give us a competitive advantage survive.
If we build our business model on the premise evolutionary change, then
we can be nimble to deploy new technology when it provides lower cost
and/or better performance.

Stability. Even though technology will advance, our customers demand

products that work reliably, for a long time, and in a manner with which they
are comfortable.
Over the last 50 years automotive technology has drastically improved, but
the driving experience, how we drive, has remained almost constant.
Abstraction. You will notice the approach in this section differs widely from
the other examples in this book.
The rest of the book deploys a bottom up approach. With bottom-up
education, the details are first explained, so there is no magic, and then
abstraction occurs by encapsulating that we fully understand.
In this section we will purchase hardware and software with capabilities to
communicate with the internet, and use this abstraction without fully
understanding how some of the lower levels operate.

Scalability. ARM reports over 50 million devices with an ARM core have been
shipped from 1993 to 2013, and predicts another 50 billion before the end of
this decade. In order to be effective and profitable, we need to develop
systems that can scale.

Security. Because embedded systems are deployed in life-critical situations,

and because the quality of service affects our profits, we must protect the
system from a determined adversary.
A chain is only as strong as its weakest link. Security cannot be obtained
simply by operating in secret, because once the secret is out, the system will
be extremely vulnerable.
“Security by obscurity” is a very poor design method. Security involves
more than encrypting the data.
The first aspect of security is confidentiality. We must decide what it means
to view/change the data and who has the right to read/write.
Authentication is the means to ensure the identity of the sender is correct.
Confidentiality will require both logical and physical measures to protect
against an attack.
Encryption makes it harder for an unauthorized party to view a message.
The second aspect is data integrity. For most of the applications listed in
Table 16.1 it is important that data reach the rightful recipient in an
unaltered fashion.
To support network integrity we need techniques that support both
detection and prevention.
The third aspect is availability. A secure communication not only requires
the correct data arrive at the correct place, but also at the correct time.
A Denial of Service (DoS) attack attempts to breach the availability of the
network by sending a large amounts of simulated traffic to a server.
 The sole purpose of such traffic is to disrupt the service from being available
to actual customers.
There are several ways to thwart DoS attacks, for wired networks, we can
reroute traffic along multiple paths. With wireless networks, we can channel
hop by switching channels on a pseudorandom fashion, making it harder for
an attacker to jam.
For more information on security, see Frank Stajano, Security for
Ubiquitous Computing.

16.3. IP Addresses
IP-addresses being 32-bit numbers, we could potentially have 4 billion
addresses. With the emerging demand to connect embedded devices to the
Internet, it would seem inevitable that we run out of IP addresses.

Fortunately, the IETF envisioned this and set aside IP addresses that can be
used in private networks. These pool of private IP addresses are listed in
Table 16.2.

These IP addresses could be used for embedded devices within Intranets.

By using a technique called Network Address Translation (NAT), these
embedded devices inside Intranets can communicate (if needed) with other
entities in the Internet, by sharing one non-private IP address among a set of
devices. Figure 16.10 shows messages arriving at the public IP address are
routed by the NAT to the correct private IP. NAT modified the headers of
outgoing traffic from the machines in the Intranet, to appear like the traffic is
originating from the one machine which has a public IP address.

Start End Number of addresses

10.0.0.0 10.255.255.255 224
172.16.0.0 172.31.255.255 220
192.168.0.0 192.168.255.255 216
Table 16.2. Private IP addresses.
 Because of the growth of the internet, the 32-bit IP address (IPv4) is being
replaced with a 128-bit address (IPv6), which will provide for about 3∙1038
addresses

16.4. CC3100 Booster Pack

As described above, from an application programmer’s perspective writing

applications that involve communication over the Internet is quite simply
making calls to the socket API, to make a connection, transmit/receive
application data and close the connection.

However, this assumes that the software support (from the OS) and the
hardware support (from physical hardware and firmware) is available on the
machine.

In our case the hardware/firmware support comes from the CC3100

Booster Pack. The relevant software that implements the Data-Link layer, the
Network Layer and the Transport layer is made available through libraries
that we will link to our application.

Figure 16.11 shows the method most systems use to create a wifi
connection. In particular there is a small amount of hardware that manages
the physical layers of the connection and the remaining layers are
implemented in software on the host.

Figure 16.11. Typical manner for implementing wifi connections.

For most embedded microcontroller, there is not enough memory and

processor performance to implement all the layers of the internet stack.

Therefore the CC3100 solution, similar to other wifi solutions for

embedded systems, is to shift most of the internet layers onto firmware, as
shown in Figure 16.12. In this approach only a small footprint remains on
the host microcontroller.

Texas Instruments calls this footprint SimpleLink. When looking at the

software, the SimpleLink software driver functions begin with sl_. Figure
16.13 shows the CC3100 booster pack connected to the LaunchPad.
Figure 16.12. CC3100 solution for implementing wifi connections.