Module- 3 Solved
(IoT Network Layer) IP as the IoT Network Layer, The Business Case for IP, The need for Optimization, Optimizing IP
for IoT, Profiles and Compliances, Application Protocols for IoT, The Transport Layer, IoT Application Transport
Methods.
B.Tech Degree S8 (S) / S8 (PT) (S) Examination August 2024 (2019 Scheme)
1. With necessary sketches, write a short note on 6LoWPAN header stacks and header compression
(3marks)
The 6LoWPAN working group published several RFCs, but RFC 4994 is Foundational because it defines frame
headers for the capabilities of header compression, fragmentation, and mesh addressing. These headers can be
stacked in the adaptation layer to keep these concepts separate while enforcing a structured method for
expressing each capability. Depending on the implementation, all, none, or any combination of these capabilities
and their corresponding headers can be enabled. Figure 5-3 shows some examples of typical 6LoWPAN header
stacks.
Header Compression IPv6 header compression for 6LoWPAN was defined initially in RFC 4944 and
subsequently updated by RFC 6282. This capability shrinks the size of IPv6’s 40-byte headers and User
Datagram Protocol’s (UDP’s) 8-byte headers down as low as 6 bytes combined in some cases. At a high level,
6LoWPAN works by taking advantage of shared information known by all nodes from their participation in the
local network. In addition, it omits some standard header fields by assuming commonly used values. Figure 5-
4 highlights an example that shows the amount of reduction that is possible with 6LoWPAN header
compression.
At the top of Figure 5-4, you see a 6LoWPAN frame without any header compression enabled: The full 40-byte
IPv6 header and 8-byte UDP header are visible. The 6LoWPAN header is only a single byte in this case. Notice
that uncompressed IPv6 and UDP headers leave only 53 bytes of data payload out of the 127-byte maximum
frame size in the case of IEEE 802.15.4.2.
2. Differentiate between MQTT and CoAP. (3marks)
3. Illustrate the Constrained Application Protocol (CoAP) message format and explain about message fields.
(6 marks)
4.
CoAP Constrained Application Protocol (CoAP) resulted from the IETF Constrained RESTful Environments
(CoRE) working group’s efforts to develop a generic framework for resource oriented applications targeting
constrained nodes and networks. (For more information on the IETF CoRE working group,
The CoAP framework defines simple and flexible ways to manipulate sensors and actuators for data or device
management. The IETF CoRE working group has published multiple standards track specifications for CoAP,
including the following: RFC 6690: Constrained RESTful Environments (CoRE) Link Format RFC 7252: The
Constrained Application Protocol (CoAP) RFC 7641: Observing Resources in the Constrained Application
Protocol (CoAP) RFC 7959: Block-Wise Transfers in the Constrained Application Protocol (CoAP) RFC 8075:
Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
From a formatting perspective, a CoAP message is composed of a short fixed length Header field (4 bytes), a
variable-length but mandatory Token field (0–8 bytes), Options fields if necessary, and the Payload field. Figure
4 details the CoAP message format, which delivers low overhead while decreasing parsing complexity.
4. Describe about the schedule management mechanism and packet forwarding models in 6TiSCH.
(8marks)
The 6TiSCHarchitecture defines four schedule management mechanisms:
1. Static scheduling:All nodes in the constrained network share a fixed Schedule. Cells are shared, and nodes
contend for slot access in a slottedaloha manner. Slotted aloha is a basic protocol for sending data using timeslot
boundaries when communicating over a shared medium. Staticscheduling is a simple scheduling mechanism
that can be used upon initialimplementation or as a fallback in the case of network malfunction. Thedrawback
with static scheduling is that nodes may expect a packet at anycell in the schedule. Therefore, energy is wasted
idly listening across allcells.
2. Neighbor-to-neighbor scheduling: A schedule is established thatcorrelates with the observed number of
transmissions between nodes. Cellsin this schedule can be added or deleted as traffic requirements
andbandwidth needs change.
3. Remote monitoring and scheduling management: Time slots and otherresource allocation are handled by a
management entity that can bemultiple hops away. The scheduling mechanism leverages 6top and evenCoAP
in some scenarios.
4. Hop-by-hop scheduling: A node reserves a path to a destination nodemultiple hops away by requesting the
allocation of cells in a schedule ateach intermediate node hop in the path. The protocol that is used by a nodeto
trigger this scheduling mechanism is not defined at this point.
The forwarding decision is based on a preexistingstate that was learned from a routing computation. There are
three 6TiSCHforwarding models:
• Track Forwarding (TF): This is the simplest and fastest forwardingmodel. A “track” in this model is a
unidirectional path between a sourceand a destination. This track is constructed by pairing bundles of
receivecells in a schedule with a bundle of receive cells set to transmit. So, aframe received within a particular
cell or cell bundle is switched to anothercell or cell bundle. This forwarding occurs regardless of the network
layerprotocol.
• Fragment forwarding (FF): This model takes advantage of 6LoWPAN Fragmentation to build a Layer 2
forwarding table.The 6LoWPAN sublayer learns the next-hopselection of this first fragment, which is then
applied to all subsequentfragments of that packet. Otherwise, IPv6 packets undergo hop-by-hopreassembly. This
increases latency and can be power- and CPU-intensivefor a constrained node.
• IPv6 Forwarding (6F): This model forwards traffic based on its IPv6 Routing table. Flows of packets should
be prioritized by traditional QoS(Quality of service) and RED (random early detection) operations. QoS is
aclassification scheme for flows based on their priority, and RED is a Common congestion avoidance
mechanism.
5. Write a detailed description on Message Queuing Telemetry Transport (MQTT) (10marks)
At the end of the 1990s, engineers from IBM and Arcom (acquired in 2006 by Eurotech) were looking for a
reliable, lightweight, and cost-effective protocol to monitor and control a large number of sensors and their data
from a central server location, as typically used by the oil and gas industries. Their research resulted in the
development and implementation of the Message Queuing Telemetry Transport (MQTT) protocol that is now
standardized by the Organization for the Advancement of Structured Information Standards (OASIS).
Considering the harsh environments in the oil and gas industries, an extremely simple protocol with only a few
options was designed, with considerations for constrained nodes, unreliable WAN backhaul communications,
and bandwidth constraints with variable latencies. These were
some of the rationales for the selection of a client/server and publish/subscribe framework based on the TCP/IP
architecture, as shown in Figure 6.
An MQTT client can act as a publisher to send data (or resource information) to an MQTT server acting as an
MQTT message broker. In the example illustrated in Figure 6, the MQTT client on the left side is a temperature
(Temp) and relative humidity (RH) sensor that publishes its Temp/RH data. The MQTT server (or message
broker) accepts the network connection along with application messages, such as Temp/RH data, from the
publishers. It also handles the subscription and unsubscription process and pushes the application data to MQTT
clients acting as subscribers. The application on the right side of Figure 6, is an MQTT client that is a subscriber
to the Temp/RH data being generated by the publisher or sensor on the left. This model, where subscribers
express a desire to receive information from publishers, is well known. A great example is the collaboration and
social networking application Twitter.
MQTT message types are summarized in the below table 2.
The MQTT protocol offers three levels of quality of service (QoS). QoS for MQTT as in fig 8 is implemented
when exchanging application messages with publishers or subscribers, and it is different from the IP QoS that
most people are familiar with. The delivery protocol is symmetric. This means the client and server can each
take the role of either sender or receiver. The delivery protocol is concerned solely with the delivery of an
application message from a single sender to a single receiver. These are the three levels of MQTT QoS: QoS 0:
This is a best-effort and unacknowledged data service referred to as “at most once” delivery. The publisher sends
its message one time to a server, which transmits it once to the subscribers. No response is sent by the receiver,
and no retry is performed by the sender. The message arrives at the receiver either once or not at all. QoS 1:
This QoS level ensures that the message delivery between the publisher and server and then between the server
and subscribers occurs at least once. In PUBLISH and PUBACK packets, a packet identifier is included in the
variable header. If the message is not acknowledged by a PUBACK packet, it is sent again. This level guarantees
“at least once” delivery.
QoS 2: This is the highest QoS level, used when neither loss nor duplication of messages is acceptable. There
is an increased overhead associated with this QoS level because each packet contains an optional variable header
with a packet identifier. Confirming the receipt of a PUBLISH message requires a two-step acknowledgement
process. The first step is done through the PUBLISH/PUBREC packet pair, and the second is achieved with the
PUBREL/PUBCOMP packet pair. This level provides a “guaranteed service” known as “exactly once” delivery,
with no consideration for the number of retries as long as the message is delivered once.
6. Comment on fragmentation and mesh addressing in 6LoWPAN (4 marks)
Fragmentation The maximum transmission unit (MTU) for an IPv6 network must be at least 1280 bytes. The
term MTU defines the size of the largest protocol data unit that can be passed. For IEEE 802.15.4, 127 bytes
is the MTU. You can see that this is a problem because IPv6, with a much larger MTU, is carried inside the
802.15.4 frame with a much smaller one. To remedy this situation, large IPv6 packets must be fragmented
across multiple 802.15.4 frames at Layer 2.
The fragment header utilized by 6LoWPAN is composed of three primary fields: Datagram Size, Datagram
Tag, and Datagram Offset. The 1-byte Datagram Size field specifies the total size of the unfragmented payload.
Datagram Tag identifies the set of fragments for a payload. Finally, the Datagram Offset field delineates how
far into a payload a particular fragment occurs. Figure 5-5 provides an overview of a 6LoWPAN fragmentation
header.
In Figure 5-5, the 6LoWPAN fragmentation header field itself uses a unique bit value to identify that the
subsequent fields behind it are fragment fields as opposed to another capability, such as header compression.
Also, in the first fragment, the Datagram Offset field is not present because it would simply be set to 0. This
results in the first fragmentation header for an IPv6 payload being only 4 bytes long. The remainder of the
fragments have a 5-byte header field so that the appropriate offset can be specified. Mesh Addressing The
purpose of the 6LoWPAN mesh addressing function is to forward packetsover multiple hops. Three fields are
defined for this header: Hop Limit, SourceAddress, and Destination Address. Analogous to the IPv6 hop limit
field, thehop limit for mesh addressing also provides an upper limit on how many timesthe frame can be
forwarded. Each hop decrements this value by 1 as it isforwarded. Once the value hits 0, it is dropped and no
longer forwarded. The Source Address and Destination Address fields for mesh addressing areIEEE 802.15.4
addresses indicating the endpoints of an IP hop. Figure 5-6details the 6LoWPAN mesh addressing header fields.
Note that the mesh addressing header is used in a single IP subnet and is a Layer2 type of routing known as
mesh-under. The concept of mesh-under is discussedin the next section. Keep in mind that RFC 4944 only
provisions the function inthis case as the definition of Layer 2 mesh routing specifications was outside
thescope of the 6LoWPAN working group, and the IETF doesn’t define “Layer 2routing.” An implementation
performing Layer 3 IP routing does not need toimplement a mesh addressing header unless required by a given
technology profile.
