ZigBee

• ZigBee is a new wireless technology.

• Technological Standard Created for Control and Sensor Networks.
• Based on the IEEE 802.15.4 Standard.
• Created by the ZigBee Alliance Philips, Motorola, Intel,HP are all members of the alliance.
• Designed for low power consumption allowing batteries to essentially last for ever.
• ZigBee makes possible completely networked homes where all devices are able to
communicate and be controlled by a single unit.
• It provides network security and application support services operating on the top of IEEE.

ZigBee has continued to evolve over time as evidenced by the release of

Zigbee IP and is representative of how IEEE 802.15.4 can be leveraged at the
PHY and MAC layers, independent of the protocol layers above. The Zigbee
Alliance is an industry group formed to certify interoperability between
vendors and it is committed to driving and evolving ZigBee as an IoT
solution for interconnecting smart objects. ZigBee solutions are aimed at
smart objects and sensors that have low bandwidth and low power needs.
Furthermore, products that are ZigBee compliant and certified by the ZigBee
Alliance should interoperate even though different vendors may manufacture
them. The ZigBee specification has undergone several revisions.
The main areas where ZigBee is the most well-known include automation
for commercial, retail, and home applications and smart energy. In the
industrial and commercial automation space, ZigBee-based devices can
handle various functions, from measuring temperature and humidity to
tracking assets. For home automation, ZigBee can control lighting,
thermostats, and security functions. ZigBee Smart Energy brings together a
variety of interoperable products, such as smart meters, that can monitor and
control the use and delivery of utilities, such as electricity and water. These
ZigBee products are controlled by
the utility provider and can help coordinate usage between homes and
businesses and the utility provider itself to provide more efficient operations.
The traditional ZigBee stack is illustrated in Figure 2.1. As mentioned
previously, ZigBee utilizes the IEEE 802.15.4 Standard at the lower PHY
and MAC layers. ZigBee specifies the network and security layer and
application support layer that sit on top of the lower layers.

Figure 2.1 High Level ZigBee Protocol Stack

The ZigBee network and security layer provides mechanisms for network
startup, configuration, routing, and securing communications. This includes
calculating routing paths in what is often a changing topology, discovering
neighbors, and managing the routing tables as devices join for the first time.
The network layer is also responsible for forming the appropriate topology,
which is often a mesh but could be a star or tree as well. From a security
perspective, ZigBee utilizes 802.15.4 for security at the MAC layer, using
the Advanced Encryption Standard (AES) with a 128-bit key and also
provides security at the network and application layers.

The application support layer in Figure 2.1 interfaces the lower portion of the
stack dealing with the networking of ZigBee devices with the higher-layer
applications. ZigBee predefines many application profiles for certain
industries, and vendors can optionally create their own custom ones at this
layer.

ZigBee is one of the most well-known protocols built on an IEEE 802.15.4

foundation. On top of the 802.15.4 PHY and MAC layers, ZigBee specifies
its own network and security layer and application profiles. While this
structure has provided a fair degree of interoperability for vendors with
membership in the ZigBee Alliance, it has not provided interoperability with
other IoT solutions. However, this has started to change with the release of
ZigBee IP
ZigBee IP

With the introduction of ZigBee IP, the support of IEEE 802.15.4

continues, but the IP and TCP/UDP protocols and various other open
standards are now supported at the network and transport layers. The
ZigBee-specific layers are now found only at the top of the protocol stack
for the applications. ZigBee IP was created to embrace the open standards
coming from the IETF’s work on LLNs, such as IPv6, 6LoWPAN, and
RPL. They
provide for low-bandwidth, low-power, and cost-effective communications
when connecting smart objects.

ZigBee IP is a critical part of the Smart Energy (SE) Profile 2.0 specification
from the ZigBee Alliance. SE 2.0 is aimed at smart metering and residential
energy management systems. In fact, ZigBee IP was designed specifically
for SE 2.0 but it is not limited to this use case. Any other applications that
need a standards based IoT stack can utilize Zigbee IP. The ZigBee IP stack
is shown in Figure 2.2

Figure 2.2 ZigBee IP protocol stack

Unlike traditional ZigBee, ZigBee IP supports 6LoWPAN as an adaptation

layer. The 6LoWPAN mesh addressing header is not required as ZigBee IP
utilizes the mesh-over or route-over method for forwarding packets.
ZigBee IP requires the support of 6LoWPAN’s fragmentation and header
compression schemes. At the network layer, all ZigBee IP nodes support
IPv6, ICMPv6, and 6LoWPAN Neighbor Discovery (ND), and utilize RPL
for the routing of packets across the mesh network. Both TCP and UDP are
also supported, to provide both connection-oriented and connectionless
service.

As you can see, ZigBee IP is a compelling protocol stack offering because it

is based on current IoT standards at every layer under the application layer.
This opens up opportunities for ZigBee IP to integrate and interoperate on
just about any 802.15.4 network with other solutions built on these open IoT
standards.
 Advantages and Disadvantages of ZigBee:
Advantages:
 Wireless nodes that are capable of multi-year battery lives.
 Direct communication
 It is less complex than Bluetooth.
 Low-power consumption
 Wireless
 Mesh-networking
Disadvantages:
 Working on small distance with low speed
Application of ZigBee:
• Road map products-tracking
• Consumer electronics
• Personal and healthcare
• Commercial and residential control
• Industrial and government markets worldwide
• Home networking
• Industrial control and management

Zigbee Smart Energy

ZigBee smart energy is designed for a large range of IoT applications including
smart homes, remote controls and healthcare systems. It supports a wide range of
network topologies including star, peer-to-peer, or cluster-tree. A coordinator
controls the network and is the central node in a star topology, the root in a tree or
cluster topology and may be located anywhere in peer-to-peer. ZigBee standard
defines two stack profiles: ZigBee and ZigBee Pro. These stack profiles support
full mesh networking and work with different applications allowing
implementations with low memory and processing power. ZigBee Pro offers more
features including security using symmetric-key exchange, scalability using
stochastic address assignment, and better performance using efficient many-to-one
routing mechanisms

Bluetooth Low Energy

Bluetooth low energy or Bluetooth smart is a short range communication

protocol with PHY and MAC layer widely used for in-vehicle networking. Its
low energy can reach ten times less than the classic Bluetooth while its latency can
reach 15 times. Its access control uses a contention-less MAC with low latency and
fast transmission. It follows master/slave architecture and offers two types of
frames: adverting and data frames. The Advertising frame is used for discovery
and is sent by slaves on one or more of dedicated advertisement channels. Master
nodes sense advertisement channels to find slaves and connect them. After
connection, the master tells the slave it’s waking cycle and scheduling sequence.
Nodes are usually awake only when they are communicating and they go to sleep
otherwise to save their power
• Open standard for development of personal area network (PAN)

Features:

• low cost, low power and short range typically about 10 meters
• It can exchange information with other Bluetooth device over a radio.
• It creating a small network of devices that are close to one another.
• Support IEEE802.15.4
• 2.4GHz frequency range

Advantages and Disadvantages of Bluetooth:

Advantages :

• It is cheap
• Easy to install
• It makes connecting to different devices convenient
• It is wireless
• It is free to use if the device is installed with it

Disadvantages:

• It can be hacked into

• If installed on a cell phone it is prone to receiving cell phone viruses
• It only allows short range communication between devices
• It can only connect two devices at once
• It can lose connection in certain conditions

Applications of Bluetooth technology:

• Wireless networking between laptops and desktop computers, or desktops that are
in a confined space and little bandwidth is needed.
• The transfer of files, images and MP3, between mobile phones.
• Bluetooth technology headsets for smart phones and cell phones.
• Data logging equipment that transmits data to a computer via Bluetooth
technology.
IPv4 Header vs IPv6 Header

IPv6 is using two main types of headers: Main IPv6 Header and the new IPv6 Extension
Headers. The main IPv6 header is equivalent to the IPv4 one with some field differences
introduced for better efficiency. Figure 1 compares both headers.
Figure 1. Comparing IPv4 and IPv6 headers

Note that the IPv6 header has fewer fields which makes it more efficient and faster to
process. Another big advantage is that the header length is fixed size 40 bytes, comparing to
the variable length size of the IPv4 header.

Version
The Version field is a 4-bit long identifier of the IP protocol version. Needles to say, it is set
to 4 in IPv4 and 6 in IPv6.
Figure 2. IPv6 Version field

However, in the most common case where IP is encapsulated in Ethernet, identification of

the IP protocol happens at the data-link layer through a 16-bit field in the frames called
EtherType. Each frame has an EtherType field that identifies the upper-layer protocol in the
payload portion. When IPv6 is encapsulated in Ethernet II, the value used is 0x86dd, where
0x means that the digits are hexadecimal values. When IPv4 is encapsulated in Ethernet II,
the value used is 0x800.

Figure 3. IPv6 Packet in Ethernet Frame

Traffic Class
The Traffic Class field is an 8-bit long identifier of the packet’s class or priority. It is the
same concept as the Type of Service field in the IPv4 header. The first 6 bits of the Traffic
Class field represents the DSCP field as defined in RFC 2474, and the last 2 bits are used for
ECN as defined in RFC 3168.
Figure 4. IPv6 Traffic Class Field

Originally, in IPv4 only the first 3 bits were used as QoS value called IP Precedence. Later it
was superseded by the Diffserv technology that uses the first 6 bits and the value is
called Differentiated Services Code Point or just DSCP.

Flow Label
The Flow Label is a 20-bit long field that indicates to intermediate devices that a packet
belongs to a specific sequence of packets between a source and a destination. IPv6 routers
use this field to distinguish different traffic flow between the same source and destination, for
example, different TCP sessions between the same endpoints. When the Flow label value is
set to 0 means that the packet is not associated with any specific flow.
Figure 5. IPv6 Flow Label field

Payload Length
The IPv6 Payload field is a 16-bit identifier of the length in bytes of the data portion of a
packet including any IPv6 Extension headers. The length does not include the main IPv6
header. As you can see in Figure 3, any extension headers are considered part of the payload
portion. In contrast, the IPv4 Total Length field measures the length of the entire IP packet
including the IPv4 header.
Figure 6. IPv6 Payload-Length Field

Both the IPv4 Total-Length and IPv6 Payload-length fields are 16-bit long, therefore
allowing for up to 65,355 byte-long packets. In reality, most IP packets (both v4 and v6) are
1500 byte-long due to a technology called Maximum Transmission Unit (MTU), which
defines the maximum size of a packet that can pass through the link. However, IPv6 can
carry larger payloads than 65,355 bytes using the Jumbo Payload option in the Hop-by-hop
extension header. These larger packets are called jumbograms and are defined in RFC 2675.
Jumbograms IPv6 packets can carry payloads between 65,536 and 4,294,967,295 bytes. They
are used inside very-high-speed datacenters and supercomputers.

Next Header
The Next Header is an 8-bit field that specifies either the type of the first extension header (if
any) or the upper-layer protocol in the payload such as TCP, UDP, or ICMPv6. The field is
similar to the IPv4 Protocol field but with some additional options. When indicating an
upper-layer protocol, the IPv6 Next Header field uses the same values that are used in the
IPv4 Protocol.
Figure 7. IPv6 Next Header Field

Some of the most common values are shown in the table below.

Table 1. IPv6 Next Header field common values

Next Header value (in hex) Description

6 Transmission Control Protocol (TCP)

11 User Datagram Protocol (UDP)

2F Generic Routing Encapsulation (GRE)

32 Encapsulating Security Payload (ESP)

3A Internet Control Message Protocol version 6 (ICMPv6)

3B No Next Header for IPv6

59 Open Shortest Path First (OSPF)

IPv4 Checksum Field

In the IPv4 header, there is a Checksum field that is used to verify and discard corrupted
packets. It is a 16-bit cyclic redundancy check (CRC) that is validated and recomputed at
each hop along the network path.
In IPv6, there is no Checksum field. To make the header more efficient and easier to
process, the protocol creators decided to not include this CRC check in the Layer 3 header.
At this point, you may be wondering whether this makes IPv6 less reliable than IPv4? The
answer is no because upper-layer protocols such as TCP and UDP have their own checksum
fields as shown in Figure 5. Also, there is a CRC validation at the Ethernet layer and
therefore in the IPv6, the checksum is unnecessary.

Figure 8. TCP and UDP Checksum field

In UDP, the checksum field is optional, but since there is no checksum field in the IPv6
header when UDP is carried by IPv6, the checksum field is mandatory.

IPv4 Time to Live (TTL) vs IPv6 Hop Limit

In IPv4, the TTL field ensures a packet won't circulate the network indefinitely in case of a
routing loop. Each time a packet passes through a layer 3 device, the TTL value is
decremented by one. When the value becomes 0, the packet is discarded. By default, the TTL
value is set to 255.
Figure 9. IPv6 Hop Limit Field

In IPv6, the Hop Limit field is basically the same thing, just the name has been changed to
more precisely describe the function of the field.

Fragmentation in IPv4 and IPv6

If you look closely at the IPv4 header fields, you will note three fields that are not present in
the IPv6 Header - the Identification, Flags, and Fragmentation Offset fields. They have
been removed in version 6 because of the difference in the way fragmentation is handled in
both protocols.

In IPv4, all network layer devices are allowed to fragment packets if the DF-bit (don't
fragment) is not set. For example, if a router receives a packet that is larger than the MTU of
the outgoing interface, the router divides the packet into multiple packets and send them out.
The final destination is then responsible to reassemble the fragments into the original IP
packet. Such an example is shown in figure 9.

Figure 10. IPv4 Fragmentation is done by a router

The three IPv4 fields Identification, Flags, and Fragmentation Offset are used in this
fragmentation handling process.

In IPv6, routers do not fragment packets. When an IPv6 router receives a packet larger than
the MTU of the outgoing interface, the router discards the packet and sends an ICMPv6
"Packet Too Big" message back to the sender. The message includes the MTU value of the
egress link, so the source can adjust the packet size and retransmit. This process is called
Path MTU Discovery and is described in RFC 1981, Path MTU Discovery for IP Version 6.
An example is shown in figure 10.

There are two important points to clarify:

 Typically, when a source starts sending packets to a destination, it is not a single

packet but a series of multiple ones. This process of adjusting the MTU is happening
only with the first packet and after that, the entire flow is being transmitted with the
proper packet size.
 Obviously, IMCPv6 messages have to be able to reach the sender for PMTU to work.
Oftentimes, ICMPv6 is filtered out on firewalls or other security devices, and the
PMTU process breaks.
Figure 11. IPv6 Fragmentation is done by the source

Example
Here is an example of an ICMPv6 Echo Request packet that uses the default Traffic Class,
Flow Label, and a Hop Limit of 128. It is sent between two nodes using link-local addresses.

Frame:
+ Ethernet: Etype = IPv6
- Ipv6: Next Protocol = ICMPv6, Payload Length = 40
- Versions: IPv6, Internet Protocol, DSCP 0
Version: (0110............................) IPv6, Internet Protocol, 6(0x6)
DSCP: (....000000......................) DSCP 0
ECT: (..........0.....................) ECN-Capable Transport not set
CE: (...........0....................) ECN-CE not set
FlowLabel: (............00000000000000000000) 0
PayloadLength: 40 (0x28)
NextProtocol: ICMPv6, 58(0x3a)
HopLimit: 128 (0x80)
SourceAddress: FE80:0:0:0:0:0:11FA:3BF1
DestinationAddress: FE80:0:0:0:135A:BFFF:D313:D427
+ Icmpv6: Echo request, ID = 0x0, Seq = 0x18
Summary
Let's quickly summarize what we have learned in this lesson in the following table:

Table 2. Comparing IPv4 and IPv6 Header fields

IPv4 Field IPv6 Field Function

Fields that have the same functionality and the same name in IPv4 and IPv6

Version Version Indicates the version of the IP protocol in use.

Source Address Source The network layer identifier of the sender of the packet. 32-bit in IPv4 and is
Address increased to 128-bit in IPv6.
Table 2. Comparing IPv4 and IPv6 Header fields

IPv4 Field IPv6 Field Function

Destination Address Destination The network layer identifier of the receiver of the packet. 32-bit in IPv4 and is
Address increased to 128-bit in IPv6.

Fields that have the same functionality but their names were changed

Type of Service Traffic Class Used for traffic classification and marking. Nowadays, both protocols use the 6-
bit Differentiated Services technique (DSCP).

Total Length Payload Indicates the length of the IP packet. In IPv4 the length includes both the IP
Length header and the data. In IPv6, the length includes the data plus any extension
headers but does not include the main IP header.

Time to Live Hop Limit Both fields have the same function. They ensure that packets do not loop around
the network indefinitely.

Protocol Next Header Indicates the protocol being transported in the payload portion. In IPv6, it could
also indicate the existence of an extension header.

Fields that exist in IPv4 and have been removed from IPv6

Internet Header In IPv4, this field is used in cases when the header is variable length. It is not
Length needed in IPv6, because the v6 header is a fixed-length - 40 bytes.

Identification, Flags, In IPv4, these fields are used when doing fragmentation. In IPv6, only the source
Fragment Offset of the packet is performing fragmentation using the Fragmentation extension
header.

Header Checksum After many years of experience, the designers of IPv6 decided that this field is
redundant and not necessary anymore because there are checksum fields in the
upper layer protocols.

Options Options are now handled using the extension headers in IPv6, so this field is not
necessary.

Padding Because IPv6 is fixed-sized, padding is not necessary.

Fields that are new in IPv6 and do not exist in IPv4

Flow Label A new field in IPv6 that is used for identifying that a packet is part of a sequence
and has to be handled the same way as the entire traffic flow.
6LoWPAN

While the Internet Protocol is key for a successful Internet of Things,

constrained nodes and constrained networks mandate optimization at various
layers and on multiple protocols of the IP architecture. Some optimizations
are already available from the market or under development by the IETF.
Figure 2.12 highlights the TCP/IP layers where optimization is applied.

Figure 2.12: Optimizing IP for IoT Using an Adaptation Layer

In the IP architecture, the transport of IP packets over any given

Layer 1 (PHY) and Layer 2 (MAC) protocol must be defined and
documented. The model for packaging IP into lower-layer protocols is often
referred to as an adaptation layer.

Unless the technology is proprietary, IP adaptation layers are

typically defined by an IETF working group and released as a Request for
Comments (RFC). An RFC is a publication from the IETF that officially
documents Internet standards, specifications, protocols, procedures, and
events. For example, RFC 864 describes how an IPv4 packet gets
encapsulated over an Ethernet frame, and RFC 2464 describes how the same
function is performed for an IPv6 packet.

IoT-related protocols follow a similar process. The main difference is

that an adaptation layer designed for IoT may include some optimizations to
deal with constrained nodes and networks. The main examples of adaptation
layers optimized for constrained nodes or “things” are the ones under the
6LoWPAN working group and its successor, the 6Lo working group.
 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. Figure 2.13 shows an example of an IoT protocol stack using the
6LoWPAN adaptation layer beside the well- known IP protocol stack for
reference.

Figure 2.13: Comparison of an IoT Protocol Stack Utilizing 6LoWPAN and

an IP Protocol Stack

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 2.14 shows some
examples of typical 6LoWPAN header stacks.

Figure 2.14 6LoWPAN Header Stack

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. Note that header
compression for 6LoWPAN is only defined for an IPv6 header and not IPv4.
The 6LoWPAN protocol does not support IPv4, and, in fact, there is
no standardized IPv4 adaptation layer for IEEE 802.15.4. 6LoWPAN header
compression is stateless, and conceptually it is not too complicated.
However, a number of factors affect the amount of compression, such as
implementation of RFC 4944 versus RFC 6922, whether UDP is included,
and various IPv6 addressing scenarios.

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 2.15 highlights an example that shows the amount of reduction that is
possible with 6LoWPAN header compression.

Figure 2.15 6LoWPAN Header Compression

At the top of Figure 2.15, 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.

The bottom half of Figure 2.15 shows a frame where header

compression has been enabled for a best-case scenario. 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. Note that the 2-
byte header compression applies to intra-cell communications, while
communications external to the cell may require some field of the header to
not be compressed.

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. 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 2.16 provides an overview of a 6LoWPAN fragmentation
header.

Figure 2.16 6LoWPAN Fragmentation Header

In Figure 2.16, 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 packets over multiple hops. Three fields are defined for this header:
Hop Limit, Source Address, and Destination Address. Analogous to the IPv6
hop limit field, 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.
The Source Address and Destination Address fields for mesh addressing are
IEEE
802.15.4 addresses indicating the endpoints of an IP hop. Figure 2.17
details the 6LoWPAN mesh addressing header fields.

Figure 2.17: 6LoWPAN Mesh Addressing Header

Note that the mesh addressing header is used in a single IP subnet and
is a Layer 2 type of routing known as mesh-under. RFC 4944 only provisions
the function in this case as the definition of Layer 2 mesh routing
specifications was outside the scope of the 6LoWPAN working group, and
the IETF doesn’t define “Layer 2 routing.” An implementation performing
Layer 3 IP routing does not need to implement a mesh addressing header
unless required by a given technology profile.