UNIT III

Communication in the IoT: Internet Communications: An Overview, IP Addresses, MAC

Addresses, TCP and UDP Ports, Application Layer Protocols

Prototyping Online Components: Getting Started with an API, Writing a New API, Real-Time
Reactions, Other Protocols Protocol
_________________________________________________________________________________

3.1 An Overview

IP : The preceding scenario describes how the Internet Protocol (IP) works. Data is sent from
one machine to another in a packet, with a destination address and a source address in a
standardised format (a ―protocol‖). Just like the original sender of the message in the example,
the sending machine doesn‘t always know the best route to the destination in advance. Most of
the time, the packets of data have to go through a number of intermediary machines, called
routers, to reach their destination. The underlying networks aren‘t always the same: just as we
used the phone, the postal service, and delivery by hand, so data packets can be sent over wired
or wireless networks, through the phone system, or over satellite links.

TCP : That is basically how the Transmission Control Protocol (TCP) works. The simplest
transport protocol on the Internet, TCP is built on top of the basic IP protocol and adds sequence
numbers, acknowledgements, and retransmissions. This means that a message sent with TCP can
be arbitrarily long and give the sender some assurance that it actually arrived at the destination
intact.

Because the combination of TCP and IP is so useful, many services are built on it in turn, such as
email and the HTTP protocol that transmits information across the World Wide Web.

THE IP PROTOCOL SUITE (TCP/IP) : The combination of TCP and IP is so ubiquitous that
we often refer simply to ―TCP/IP‖ to describe a whole suite or stack of protocols layered on top
of each other, each layer building on the capabilities of the one below.

◾ The low-level protocols at the link layer manage the transfer of bits of information across a
network link. This could be by an Ethernet cable, by WiFi, or across a telephone network, or
even by short-range radio standards such as IEEE 802.15.4 designed to carry data over the
Personal Area Network (PAN), that is to say between devices carried by an individual.

◾ The Internet layer then sits on top of these various links and abstracts away the gory details in
favour of a simple destination address.

◾ Then TCP, which lives in the transport layer, sits on top of IP and extends it with more
sophisticated control of the messages passed.

◾ Finally, the application layer contains the protocols that deal with fetching web pages,
sending emails, and Internet telephony. Of these, HTTP is the most ubiquitous for the web, and
indeed for communication between Internet of Things devices.

UDP : As you can see, TCP is not the only protocol in the transport layer. Unlike TCP, but as
with IP itself, in UDP each message may or may not arrive. No handshake or retransmission
occurs, nor is there any delay to wait for messages in sequence. These limitations make TCP
preferable for many of the tasks that Internet of Things devices will be used for.
3.2 IP Addresses

IP address is an address having information about how to reach a specific host, especially outside
the LAN. An IP address is a 32 bit unique address having an address space of 232. Generally,
there are two notations in which IP address is written, dotted decimal notation and hexadecimal
notation.

Dotted Decimal Notation

Hexadecimal Notation

Some points to be noted about dotted decimal notation :

1. The value of any segment (byte) is between 0 and 255 (both included).
2. There are no zeroes preceding the value in any segment (054 is wrong, 54 is correct).
Classful Addressing
The 32 bit IP address is divided into five sub-classes. These are:
 Class A
 Class B
 Class C
 Class D
 Class E
Each of these classes has a valid range of IP addresses. Classes D and E are reserved for
multicast and experimental purposes respectively. The order of bits in the first octet determine
the classes of IP address.

IPv4 address is divided into two parts:

 Network ID
 Host ID
The class of IP address is used to determine the bits used for network ID and host ID and the
number of total networks and hosts possible in that particular class. Each ISP or network
administrator assigns IP address to each device that is connected to its network.

Note: IP addresses are globally managed by Internet Assigned Numbers Authority(IANA) and
regional Internet registries(RIR).

Note: While finding the total number of host IP addresses, 2 IP addresses are not counted and are
therefore, decreased from the total count because the first IP address of any network is the
network number and whereas the last IP address is reserved for broadcast IP.

Class A:
IP address belonging to class A are assigned to the networks that contain a large number of hosts.
 The network ID is 8 bits long.
 The host ID is 24 bits long.
The higher order bit of the first octet in class A is always set to 0. The remaining 7 bits in first
octet are used to determine network ID. The 24 bits of host ID are used to determine the host in
any network. The default subnet mask for class A is 255.x.x.x. Therefore, class A has a total of:
 2^7-2= 126 network ID(Here 2 address is subracted because 0.0.0.0 and 127.x.y.z are special
address. )
 2^24 – 2 = 16,777,214 host ID
IP addresses belonging to class A ranges from 1.x.x.x – 126.x.x.x
 Class B:
IP address belonging to class B are assigned to the networks that ranges from medium-sized to
large-sized networks.
 The network ID is 16 bits long.
 The host ID is 16 bits long.
The higher order bits of the first octet of IP addresses of class B are always set to 10. The
remaining 14 bits are used to determine network ID. The 16 bits of host ID is used to determine
the host in any network. The default sub-net mask for class B is 255.255.x.x. Class B has a total
of:
 2^14 = 16384 network address
 2^16 – 2 = 65534 host address
IP addresses belonging to class B ranges from 128.0.x.x – 191.255.x.x.

Class C:
IP address belonging to class C are assigned to small-sized networks.
o The network ID is 24 bits long.
o The host ID is 8 bits long.
The higher order bits of the first octet of IP addresses of class C are always set to 110. The
remaining 21 bits are used to determine network ID. The 8 bits of host ID is used to determine
the host in any network. The default sub-net mask for class C is 255.255.255.x. Class C has a
total of:
o 2^21 = 2097152 network address
o 2^8 – 2 = 254 host address
IP addresses belonging to class C ranges from 192.0.0.x – 223.255.255.x.

Class D:

IP address belonging to class D are reserved for multi-casting. The higher order bits of the first
octet of IP addresses belonging to class D are always set to 1110. The remaining bits are for the
address that interested hosts recognize.
Class D does not posses any sub-net mask. IP addresses belonging to class D ranges from
224.0.0.0 – 239.255.255.255.

Class E:
IP addresses belonging to class E are reserved for experimental and research purposes. IP
addresses of class E ranges from 240.0.0.0 – 255.255.255.254. This class doesn‘t have any sub-
net mask. The higher order bits of first octet of class E are always set to 1111.
 Range of special IP addresses:
169.254.0.0 – 169.254.0.16 : Link local addresses
127.0.0.0 – 127.0.0.8 : Loop-back addresses
0.0.0.0 – 0.0.0.8 : used to communicate within the current network.
Rules for assigning Host ID:
Host ID‘s are used to identify a host within a network. The host ID are assigned based on the
following rules:
o Within any network, the host ID must be unique to that network.
o Host ID in which all bits are set to 0 cannot be assigned because this host ID is used to represent
the network ID of the IP address.
o Host ID in which all bits are set to 1 cannot be assigned because this host ID is reserved as a
broadcast address to send packets to all the hosts present on that particular network.
Rules for assigning Network ID:
Hosts that are located on the same physical network are identified by the network ID, as all host
on the same physical network is assigned the same network ID. The network ID is assigned
based on the following rules:
o The network ID cannot start with 127 because 127 belongs to class A address and is reserved for
internal loop-back functions.
o All bits of network ID set to 1 are reserved for use as an IP broadcast address and therefore,
cannot be used.
o All bits of network ID set to 0 are used to denote a specific host on the local network and are not
routed and therefore, aren‘t used.

Summary of Classful addressing :

Problems with Classful Addressing:

The problem with this classful addressing method is that millions of class A address are wasted,
many of the class B address are wasted, whereas, number of addresses available in class C is so
small that it cannot cater the needs of organizations. Class D addresses are used for multicast
routing and are therefore available as a single block only. Class E addresses are reserved.
Since there are these problems, Classful networking was replaced by Classless Inter-Domain
Routing (CIDR) in 1993.
3.3 MAC Addresses
The medium access control (MAC) is a sublayer of the data link layer of the open system
interconnections (OSI) reference model for data transmission. It is responsible for flow control
and multiplexing for transmission medium. It controls the transmission of data packets via
remotely shared channels. It sends data over the network interface card.
MAC Layer in the OSI Model
The Open System Interconnections (OSI) model is a layered networking framework that
conceptualizes how communications should be done between heterogeneous systems. The data
link layer is the second lowest layer. It is divided into two sublayers −
 The logical link control (LLC) sublayer
 The medium access control (MAC) sublayer
The following diagram depicts the position of the MAC layer −

Functions of MAC Layer

 It provides an abstraction of the physical layer to the LLC and upper layers of the OSI
network.
 It is responsible for encapsulating frames so that they are suitable for transmission via the
physical medium.
 It resolves the addressing of source station as well as the destination station, or groups of
destination stations.
 It performs multiple access resolutions when more than one data frame is to be
transmitted. It determines the channel access methods for transmission.
 It also performs collision resolution and initiating retransmission in case of collisions.
 It generates the frame check sequences and thus contributes to protection against
transmission errors.
MAC Addresses
MAC address or media access control address is a unique identifier allotted to a network
interface controller (NIC) of a device. It is used as a network address for data transmission
within a network segment like Ethernet, Wi-Fi, and Bluetooth.
MAC address is assigned to a network adapter at the time of manufacturing. It is hardwired or
hard-coded in the network interface card (NIC). A MAC address comprises of six groups of two
hexadecimal digits, separated by hyphens, colons, or no separators. An example of a MAC
address is 00:0A:89:5B:F0:11.

3.4 TCP and UDP Ports

As we know that both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol)
are the most widely used Internet protocols among which TCP is connection oriented − once a
connection is established, data can be sent bidirectional. UDP is a simpler, connectionless
Internet protocol. Multiple messages are sent as packets in chunks using UDP. Now on the basis
of features of attributes we can distinguish between TCP and UDP
Following are the important differences between TCP and UDP.

Sr. Key TCP (Transmission Control UDP (User Datagram Protocol)

No. Protocol)

1 Definition It is a communications protocol, using It is same as the TCP protocol except

which the data is transmitted between
systems over the network.
In this, the data is transmitted into the
form of packets.
It includes error-checking, guarantees
the delivery and preserves the order of
the data packets.
this doesn‘t guarantee the error-checking
and data recovery.
If you use this protocol, the data will be
sent continuously, irrespective of the
issues in the receiving end.

2 Design TCP is a connection oriented protocol. UDP is a connection less protocol.

3 Reliable As TCP provides error checking
support and also guarantees delivery of
data to the destination router this make
it more reliable as compared to UDP.
While on other hand UDP does provided
only basic error checking support using
checksum so the delivery of data to the
destination cannot be guaranteed in
UDP as compared to that in case of
TCP.

4 Data In TCP the data is transmitted in a On other hand there is no sequencing of

transmission particular sequence which means that data in UDP in order to implement
packets arrive in-order at the receiver. ordering it has to be managed by the
application layer.

5 Performance TCP is slower and less efficient in On other hand UDP is faster and more
performance as compared to UDP. efficient than TCP.
Also TCP is heavy-weight as
compared to UDP.

6 Retransmission Retransmission of data packets is On other hand retransmission of packets

possible in TCP in case packet get lost is not possible in UDP.
or need to resend.
3.5 Application Layer Protocols

Application layer is the top most layer in OSI and TCP/IP layered model. This layer exists in
both layered Models because of its significance, of interacting with user and user applications.
This layer is for applications which are involved in communication system.
A user may or may not directly interacts with the applications. Application layer is where the
actual communication is initiated and reflects. Because this layer is on the top of the layer stack,
it does not serve any other layers. Application layer takes the help of Transport and all layers
below it to communicate or transfer its data to the remote host.
When an application layer protocol wants to communicate with its peer application layer
protocol on remote host, it hands over the data or information to the Transport layer. The
transport layer does the rest with the help of all the layers below it.

There‘is an ambiguity in understanding Application Layer and its protocol. Not every user
application can be put into Application Layer. except those applications which interact with the
communication system. For example, designing software or text-editor cannot be considered as
application layer programs.
On the other hand, when we use a Web Browser, which is actually using Hyper Text Transfer
Protocol (HTTP) to interact with the network. HTTP is Application Layer protocol.
Another example is File Transfer Protocol, which helps a user to transfer text based or binary
files across the network. A user can use this protocol in either GUI based software like FileZilla
or CuteFTP and the same user can use FTP in Command Line mode.
Hence, irrespective of which software you use, it is the protocol which is considered at
Application Layer used by that software. DNS is a protocol which helps user application
protocols such as HTTP to accomplish its work.

3.6 Getting Started with an API

The most important part of a web service, with regards to an Internet of Things device, is the
Application Programming Interface, or API. An API is a way of accessing a service that is
targeted at machines rather than people.
MASHING UP APIS: The idea of ―mashing up‖ multiple APIs to get a result has taken off and
can be used to powerful effect. For example:

◾ Using a mapping API to plot properties to rent or buy—for example, Google Maps to
visualise properties to rent via Craigslist, or Foxtons in London showing its properties using
Mapumental.

◾ Showing Twitter trends on a global map or in a timeline or a charting API.

◾ Fetching Flickr images that are related to the top headlines retrieved from The Guardian
newspaper‘s API.

SCRAPING : In many cases, companies or institutions have access to fantastic data but don‘t
want to or don‘t have the resources or knowledge to make them available as an API. While you
saw in the Flickr example above that getting a computer to pretend to be a browser and navigate
it by looking for UI elements was fragile, that doesn‘t mean that doing so is impossible. In
general, we refer to this, perhaps a little pejoratively, as ―screen-scraping‖.

Here are a few examples:

◾ Adrian has scraped the Ship AIS system (www.shipais.com/, whose data is semi-manually
plotted by shipping enthusiasts) to get data about ships on the river Mersey, and this information
is then tweeted by the @merseyshipping account (www.mcqn.com/weblog/
connecting_river_mersey_twitter). He says of the project that it is a way to ―connect the river to
the Internet‖, so although this doesn‘t have an Internet-connected ―thing‖ as such, it arguably
enters into the realm of the Internet of Things.

LEGALITIES : Screen-scraping may break the terms and conditions of a website. For
example, Google doesn‘t allow you to screen-scrape its search pages but does provide an API.
Even if you don‘t think about legal sanctions, breaking the terms and conditions for a company
like Google might lead to its denying you its other services, which would be at the very least
inconvenient.

3.7 Writing a New API

Although the process of designing a web application to be used on a browser can mix up the
actions that users will accomplish with the flows they will take to navigate through the
application, writing the back-end API makes you think much more in terms of the data that you
want to process.

The best news is, if you start designing an API in this way, you can easily add a website
afterwards, as you will see in the upcoming ―Going Further‖ section.

CLOCKODILLO : As we saw earlier, Clockodillo is an Internet-connected task timer. The user

can set a dial to a number of minutes, and the timer ticks down until completed. It also sends
messages to an API server to let it know that a task has been started, completed, or cancelled.

A number of API interactions deal precisely with those features of the physical device:
◾ Start a new timer
◾ Change the duration of an existing timer
◾ Mark a timer completed
◾ Cancel a timer
Some interactions with a timer data structure are too complicated to be displayed on a device
consisting mostly of a dial—for example, anything that might require a display or a keyboard!
Those could be done through an app on your computer or phone instead.
◾ View and edit the timer‘s name/description And, naturally, the user may want to be able to see
historical data:
◾ Previous timers, in a list
• Their name/description
• Their total time and whether they were cancelled Assuming you plan to build more than just
one device, you need to have some form of identifying the device.

For now, assume that each device will send some identifying token, such as a MAC address.

SECURITY: For Clockodillo, perhaps a boss might want to double-check that employees are
using the timer. Or a competitor might want to check the descriptions of tasks to spy what your
company is working on. Or a (more disreputable) competitor might want to disrupt and discredit
the service by entering fake data.

Someone who is targeting a specific user and has access to that person’s wired or
(unencrypted) wireless network. This attacker could read the details and use them (to create
fake timers or get information about the user).

◾ Someone who has access to one of the intermediate nodes. This person won‘t be targeting a
specific device but may be looking to see what unencrypted data passes by, to see what will be a
tempting target.

IMPLEMENTING THE API :

An API defines the messages that are sent from client to server and from server to client.
Ultimately, you can send data in whatever format you want, but it is almost always better to use
an existing standard because convenient libraries will exist for both client and server to produce
and understand the required messages.

Here are a few of the most common standards that you should consider:
◾ Representational State Transfer (REST): Access a set of web URLs like
http://timer.roomofthings.com/timers/ or http:://timer.roomofthings.com/timers/1234 using
HTTP methods such as GET and POST, but also PUT and DELETE. The result is often XML or
JSON but can often depend on the HTTP content-type negotiation mechanisms.

◾ JSON-RPC: Access a single web URL like http://timer. roomofthings.com/api/, passing a

JSON string such as {‗method‘:‘update‘, ‗params‘: [{‗timer-id‘:1234, ‗description‘:‘Writing API
chapter for book‘}], ‗id‘:12}. The return value would also be in JSON, like {‗result‘:‘OK‘,
‗error‘:null, ‗id‘:12}.

◾ XML-RPC: This standard is just like JSON-RPC but uses XML instead of JSON.
◾ Simple Object Access Protocol (SOAP): This standard uses XML for transport like XML-
RPC but provides additional layers of functionality, which may be useful for very complicated
systems.

3.8 Real-Time Reactions

HTTP request to the server and receive a response. This method has some disadvantages if you
want a very responsive system. To establish an HTTP request requires several round-trips to the
server. There is the TCP ―three-step handshake‖ consisting of a SYN (synchronise) request from
the client, a SYN-ACK from the server to ―acknowledge‖ the request, and finally an ACK from
the client.

Although this process can be near instantaneous, it could also take a noticeable amount of time.
If you want to perform an action the instant that something happens on your board, you may
have to factor in the connection time. If the server has to perform an action immediately, that
―immediately‖ could be nearly a minute later, depending on the connection time.

We look at two options here: polling and the so-called ―Comet‖ technologies. And then, in the
section on non-HTTP protocols, MQTT, XMPP, and CoAP offer alternative solutions.

POLLING If you want the device or another client to respond immediately, how do you do that?
You don‘t know when the event you want to respond to will happen, so you can‘t make the
request to coincide with the data becoming available.

Consider these two cases:

◾ The WhereDial should start to turn to ―Work‖ the moment that the user has checked into his
office.
◾ The moment that the task timer starts, the client on the user‘s computer should respond,
offering the opportunity to type a description of the task.

The traditional way of handling this situation using HTTP API requests was to make requests at
regular intervals. This is called polling. You might make a call every minute to check whether
new data is available for you.

The server: If the device takes off, and there are thousands of devices, each of them polling
regularly, you will have to scale up to that load.

◾ The client: This is especially important if, as per the earlier Arduino example, the
microcontroller blocks during each connect!

COMET Comet is an umbrella name for a set of technologies developed to get around the
inefficiencies of polling. As with many technologies, many of them were developed before the
―brand‖ of Comet was invented; however, having a name to express the ideas is useful to help
discuss and exchange ideas and push the technology forward.

Long Polling (Unidirectional) The first important development was ―long polling‖, which starts
off with the client making a polling request as usual. However, unlike a normal poll request, in
which the server immediately responds with an answer, even if that answer is ―nothing to
report‖, the long poll waits until there is something to say. This means that the server must
regularly send a keep-alive to the client to prevent the Internet of Things device or web page
from concluding that the server has simply timed out.

Multipart XMLHttpRequest (MXHR) (Unidirectional) When building web applications, it is

common to use a JavaScript API called XMLHttpRequest to communicate with the web server
without requiring a full new page load.

HTML5 WebSockets (Bidirectional) In Chapter 3 you saw how the HTTP protocol used in
web services sits atop the TCP protocol. Traditionally, the API used to talk directly to the TCP
layer is known as the sockets API. When the web community was looking to provide similar
capabilities at the HTTP layer, they called the solution WebSockets.

Scaling An important consideration is that all these Comet techniques require the client to have a
long-term connection with the server. For a single client, this is trivial. But if there are many
clients, the server has to maintain a connection with each of them.
3.9 Other Protocols Protocol

There are plenty of protocols to choose from, but we will give a brief rundown of some of the
options better suited to Internet of Things applications.

MQ TELEMETRY TRANSPORT : MQTT (http://mqtt.org) is a lightweight messaging

protocol, designed specifically for scenarios where network bandwidth is limited or a small code
footprint is desired. It was developed initially by IBM but has since been published as an open
standard, and a number of implementations, both open and closed source, are available, together
with libraries for many different languages.

EXTENSIBLE MESSAGING AND PRESENCE PROTOCOL Another messaging solution

is the Extensible Messaging and Presence Protocol, or XMPP (http://xmpp.org). XMPP grew
from the Jabber instant messaging system and so has broad support as a general protocol on the
Internet. This is both a blessing and a curse: it is well understood and widely deployed, but
because it wasn‘t designed explicitly for use in embedded applications, it uses XML to format
the messages. This choice of XML makes the messaging relatively verbose, which could
preclude it as an option for RAM-constrained microcontrollers.

CONSTRAINED APPLICATION PROTOCOL The Constrained Application Protocol

(CoAP) is designed to solve the same classes of problems as HTTP but, like MQTT-S, for
networks without TCP. There are proposals for running CoAP over UDP, SMS mobile phone
messaging, and integration with 6LoWPAN. CoAP draws many of its design features from
HTTP and has a defined mechanism to proxies to allow mapping from one protocol to the other.
At the time of this writing, the protocol is going through final stages of becoming a defined
standard, with the work being coordinated by the Internet Engineering Task Force Constrained
RESTful Environments Working Group.