Optimizing IP 36

for IoT From

6LoWPAN to
6Lo
• In the IP architecture, the transport of IP packets over any given
Layer 1 (PHY) and Layer 2 (MAC) protocol must be defined.
• The initial focus of the 6LoWPAN working group was to optimize
the transmission of IPv6 packets over constrained networks such
as IEEE 802.15.4.
Optimizing IP 37

for IoT From

6LoWPAN to
6Lo
 Optimizing IP 38

for IoT From

6LoWPAN to
6Lo
• The 6LoWPAN working group published several RFCs (Request
for Comments by IETF), but RFC defines frame headers for the
capabilities of
• Header compression,
• Fragmentation,
• Mesh addressing.
Optimizing IP 39

for IoT From

6LoWPAN to
6Lo
 Optimizing IP 40

for IoT From

6LoWPAN to
6Lo
• Header Compression:
• 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.
• Header compression for 6LoWPAN is only defined for an IPv6 header and
not for IPv4.
• However, a number of factors affect the amount of compression, such as
implementation of RFC, whether UDP is included, and various IPv6 addressing
scenarios.
• 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.
Optimizing IP 41

for IoT From

6LoWPAN to
6Lo
Optimizing IP 42

for IoT From

6LoWPAN to
• At the top of, a 6LoWPAN frame without any header
6Lo
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.
• 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.
• The bottom half of shows a frame where header compression
enabled:
• The 6LoWPAN header increases to 2 bytes to accommodate the
compressed IPv6 header, and UDP has been reduced in half, to 4 bytes
from 8.
• Most importantly, the header compression has allowed the payload to
more than double, from 53 bytes to 108 bytes, which is obviously much
more efficient.
 Optimizing IP 43

for IoT From

6LoWPAN to
• Fragmentation:
6Lo
• 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.
• A problem because of 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.
Optimizing IP 44

for IoT From

6LoWPAN to
6Lo
Optimizing IP 45

for IoT From

6LoWPAN to
• The fragment header utilized by 6LoWPANis composed of
6Lo
three
primary fields:
• Datagram Size: The 1-byte field specifies the total size of the
unfragmented payload
• Datagram Tag: identifies the set of fragments for a payload.
• Datagram Offset: field delineates how far into a payload a
particular
fragment occurs.

• 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.
• In the first fragment, the Datagram Offset field is not present
because
it would simply be set to 0.
 Optimizing IP 46

for IoT From

6LoWPAN to
• Mesh Addressing:
•6Lo
The purpose of the 6LoWPAN mesh addressing function is to forward
packets over multiple hops.
• Three fields are defined for this header:
• Hop Limit: The hop limit for mesh addressing also provides an
upper limit on how many times the frame can be forwarded. Each hop
decrements this value by 1 as it is forwarded. Once the value hits 0, it
is dropped and no longer forwarded.
• Source Address, and Destination Address: Source Address
The
Destination Address fields for mesh are IEE
and 802.15.4
addressing indicating the endpoints of an IP
addresses E
hop.
Optimizing IP 47

for IoT From

6LoWPAN to
6Lo
 Optimizing IP 48

for IoT From

6LoWPAN to
• Mesh-Under Versus Mesh-Over Routing:
•6Lo
IEEE 802.15.4, IEEE 802.15.4g, and IEEE 1901.2a that support
mesh topologies and operate at the physical and data link
layers, two main options exist for establishing reachability
and forwarding packets.
• “Mesh-under”: the routing of packets is handled at the
6LoWPAN adaptation layer.
• “Mesh-over” or “route-over”: utilizes IP routing for getting
packets to their destination.
 Optimizing IP 49

for IoT From

6LoWPAN to
• Mesh-under routing,
6Lo
• the routing of IP packets leverages the 6LoWPAN mesh addressing
header to route and forward packets at the link layer.
• The term mesh-under is used because multiple link layer hops can
be used to complete a single IP hop.
• Nodes have a Layer 2 forwarding table that they consult to
route the
• packets to their final destination within the mesh.
• An edge gateway terminates the mesh-under domain.
• The edge gateway must also implement a mechanism to translate between
the configured Layer 2 protocol and any IP routing mechanism
implemented on other Layer 3 IP interfaces.
 Optimizing IP 50

for IoT From

6LoWPAN to
• Mesh-over or route-over scenarios,
6Lo
• IP Layer 3 routing is utilized for computing reachability and then
getting packets forwarded to their destination, either inside or outside
the mesh domain.
• Each full-functioning node acts as an IP router, so each link layer
hop is an
• IP hop.
• When a LoWPAN has been implemented using different link layer
technologies, a mesh-over routing setup is useful.
• While traditional IP routing protocols can be used, a
specialized routing protocol for smart objects, such as RPL
 Optimizing IP 51

for IoT From

6LoWPAN to
• 6Lo Working Group:
•6Lo
The 6Lo working group seeks to expand on this completed
work with a focus on IPv6 connectivity over constraine dnode
networks.
• While the 6LoWPAN working group initially focused its optimizations on
IEEE 802.15.4 LLNs,
Optimizing IP 52

for IoT From

6LoWPAN to
• 6Lo working group is focused on the following:

6Lo
• IPv6-over-foo adaptation layer specifications using 6LoWPAN technologies
(RFC4944,
RFC6282, RFC6775) for link layer technologies:
• For example, this includes:
• IPv6 over Bluetooth Low Energy
• Transmission of IPv6 packets over near-field communication
• IPv6 over 802.11ah
• Transmission of IPv6 packets over DECT Ultra Low Energy
• Transmission of IPv6 packets on WIA-PA (Wireless Networks for Industrial Automation–Process
Automation)
• Transmission of IPv6 over Master Slave/Token Passing (MS/TP)
• Information and data models such as MIB modules:
• One example is RFC 7388, “Definition of Managed Objects for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs).”
• Optimizations that are applicable to more than one adaptation layer specification:
• For example, this includes RFC 7400, “6LoWPAN-GHC: Generic Header Compression for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs).”
• Informational and maintenance publications needed for the IETF specifications in
this area
 53

Optimizing IP for IoT 6TiSCH

• IEEE 802.15.4e, Time-Slotted Channel Hopping (TSCH), is an add-on
to the Media Access Control (MAC) portion of the IEEE 802.15.4
standard,
• Devices implementing IEEE 802.15.4e TSCH communicate by
following a Time Division Multiple Access (TDMA) schedule.
• An allocation of a unit of bandwidth or time slot is scheduled between
neighbor nodes.
• This allows the programming of predictable transmissions and
enables
deterministic, industrial-type applications.
• Not like other IEEE 802.15.4
• To standardize IPv6 over the TSCH mode of IEEE 802.15.4e (known as
6TiSCH)
• The IEEE 802.15.4e standard defines a time slot structure, but it
does
not mandate a scheduling algorithm for how the time slots are utilized.
• This is left to higher-level protocols like 6TiSCH.
• Scheduling is critical because it can affect throughput, latency, and power
 54

Optimizing IP for IoT 6TiSCH

 55

Optimizing IP for IoT 6TiSCH

• Schedules in 6TiSCH are broken down into cells.
• A cell is simply a single element in the TSCH schedule that can be
allocated for unidirectional or bidirectional communications between
specific nodes.
• Nodes only transmit when the schedule dictates that their cell is open
for communication.
• The 6TiSCH architecture defines four schedule
management
mechanisms:
• Static scheduling
• Neighbor-to-neighbor scheduling
• Remote monitoring and scheduling management
• Hop-by-hop scheduling
 56

Optimizing IP for IoT 6TiSCH

• Static scheduling:
• All nodes in the constrained network share a fixed schedule.
• Cells are shared, and nodes contend for slot access in a slotted aloha
manner.
• Slotted aloha is a basic protocol for sending data using time slot boundaries when
communicating over a shared medium.
• Static scheduling is a simple scheduling mechanism that can be used upon
initial implementation or as a fall back in the case of network malfunction.
• The drawback with static scheduling is that nodes may expect a packet at
any cell in the schedule.
• Therefore, energy is wasted idly listening across all cells.
• Neighbor-to-neighbor scheduling:
• A schedule is established that correlates with the observed
number of transmissions between nodes.
• Cells in this schedule can be added or deleted as traffic requirements and
bandwidth needs change.
 57

Optimizing IP for IoT 6TiSCH

• Remote monitoring and scheduling management:
• Time slots and other resource allocation are handled by a
management entity that can be multiple hops away.
• The scheduling mechanism leverages 6top and even CoAP
in some scenarios.
• This scheduling mechanism provides quite a bit of flexibility and
control in
• allocating cells for communication between nodes.
• Hop-by-hop scheduling:
• A node reserves a path to a destination node multiple hops away by
requesting the allocation of cells in a schedule at each intermediate
node hop in the path.
• The protocol that is used by a node to trigger this scheduling
mechanism is not defined at this point.
 58

Optimizing IP for IoT 6TiSCH

• In addition to schedule management functions, the 6TiSCH architecture
also defines three different forwarding models.
• Forwarding is the operation performed on each packet by a node that
allows it to be delivered to a next hop or an upper- layer protocol.
• The forwarding decision is based on a pre existing state that was
learned from a routing computation.
• There are three 6TiSCH forwarding models:
• Track Forwarding (TF)
• Fragment forwarding (FF)
• IPv6 Forwarding (6F)
 59

Optimizing IP for IoT 6TiSCH

• Track Forwarding (TF):
• This is the simplest and fastest forwarding model.
• A “track” in this model is a unidirectional path between a source and a
destination.
• This track is constructed by pairing bundles of receive cells in a schedule with a
bundle of receive cells set to transmit. So, a frame received within a particular
cell or cell bundle is switched to another cell or cell bundle.
• This forwarding occurs regardless of the network layer protocol.
• IPv6 Forwarding (6F):
• This model forwards traffic based on its IPv6 routing table.
• Flows of packets shouldbe prioritized by traditional QoS
(quality of service) and RED (random early detection) operations.
• QoS is a classification scheme for flows based on their priority, and RED is a
common congestion avoidance mechanism.
 60

Optimizing IP for IoT 6TiSCH

• Fragment forwarding (FF):
• This model takes advantage of 6LoWPAN fragmentation to build a
Layer
2 forwarding table.
• Fragmentation within the 6LoWPAN protocol.
• IPv6 packets can get fragmented at the 6LoWPAN sublayer to handle
the differences between IEEE 802.15.4 payload size and IPv6 MTU.
• Additional headers for RPL source route information can further
contribute
to the need for fragmentation.
• However, with FF, a mechanism is defined where the first fragment is routed
based on the IPv6 header present.
• The 6LoWPAN sublayer learns the next-hop selection of this first fragment,
which is then applied to all subsequent fragments of that packet.
Otherwise, IPv6 packets undergo hop-by-hop reassembly.
• This increases latency and can be power- and CPU-intensive for a
constrained node.