IPv6 UDP Encapsulation

Packets originating and destined for an XBee network can be encapsulated in an IPv6 UDP packet. In order to send and receive XBee packets encapsulated in IPv6 UDP packet various elements must be placed into the packet, such as the Address of the XBee module, the type of data contained the in the payload and the payload itself.

In an XBee network, IEEE 802.15.4 packets are used to configure and maintain the wireless network and to transport ZigBee packets between XBee modules. Configuration and maintenance of the wireless network is performed by the XBee modules based on their parameters, such as PAN ID, operating channel and role in the network. ZigBee packets are used to exchange information between modules which are commands, and notifications. Notifications can either be generated automatically by the module or in response to a command. Access to notifications and commands is provided by a structured packet format used with the serial interface, known as the XBee API.

There are two basic types of API packets that are produced by an XBee coordinator, which are notification and command. Notification packets consist of network status messages, command response messages, and messages containing digital and analogue samples. Command packets consist of commands to get information from an XBee module or set a modules’ parameters. Command

pg. 111

packets therefore generate a response from the XBee module in the form of a notification message. Notification and command messages can be encapsulated into an IPv6 UDP packet.

An IPv6 UDP packet contains a number of parameters to facilitate the transport of a payload from application to application over a network. Table 11 shows the size and organisation of parameters contained in an IPv6 header and UDP header. The first parameter indicates which version of the IP protocol is used. The Traffic Class and Flow Label parameters are not used as the deal with the quality of service which is not needed for XBee API packet encapsulation. The payload length is the number of bytes in the UDP header and payload. The next header parameter dictates the type of header following the IP header, which is a UDP header. The Hop limit parameter determines the number of hops the packet can pass through. The source address contains the 128 bit IPv6 address of the source of the UDP packet, and the destination contains the 128 bit IPv6 address of the destination. The next four parameters belong to the UDP header. The source and destination port are used to multiplex the payload to the required application. The length field is the length of the payload in bytes. The checksum parameter is a 2's complement sum of the payload and pseudo header. The payload of a UDP packet follows after the checksum.

Table 11 IPv6 and UDP header structure

Section Bytes 1 2 3 4

IPv6

0 Version Traffic Class Flow Label

4 Payload Length Next Header Hop Limit

8 Source Address 12 16 20 24 Destination Address 28 32 36 UDP

40 Source Port Destination Port

44 Length Checksum

Payload 49

to1280 UDP Payload

The IPv6 source and destination addresses in the IPv6 UDP headers are determined by the type of API packet. For an XBee command API packet the IPv6 source address is the IPv6 address of the network device issuing the command, and the IPv6 destination address is the IPv6 address of the XBee module (determined using the method described in the previous section). For an XBee notification API packet the source address is the XBee modules IPv6 address (using the method described in the previous section) and the destination address is the predetermined IPv6 address of a server. The source and

pg. 112

destination port of the UDP header are used to store the type of XBee packet, and the UDP payload contains the XBee packet payload.

When an XBee end device takes a sample it sends the sample to the coordinator, and the coordinator then produces an XBee S2 API packet that contains the sample information and the source address of the module that produced the sample. This API packet is then received on the serial port of the IoT gateway (WRT54GL) and is translated to an IPv6 UDP packet. The IoT gateway then sends this IPv6 UDP packet to the server, where a program listening for the packets decodes and stores the sample information in a database. The flow of information from the XBee end device to the Server is show in Figure 112.

Figure 112 Flow of sample information from XBee end device to Server

To achieve this flow of information the IoT gateway is required to convert XBee S2 API packets to IPv6 UDP packets. The placement of information from the XBee S2 packet into the IPv6 UDP packet is shown in Figure 113.

Figure 113 Converting an XBee S2 API packet to an IPv6 UDP packet

Control of XBee modules can be achieved from the server, and this requires data to flow from the server to the XBee module as shown in Figure 114. XBee S2 API command messages are used to

pg. 113

change parameters of the XBee module such as pin assignments and sampling rates. These commands can be encapsulated into an IPV6 UDP packet that is sent from the server to the IoT gateway. The UDP packet is then translated to an XBee API command packet by the IoT gateway and sent to the XBee coordinator attached to the IoT Gateway.

Figure 114 Flow of information from Server to XBee Module

The IoT Gateway must convert IPv6 UDP packets to XBee API command packets in order for the information to flow from the server to the XBee module. The placement of information in an IPv6 UDP packet to contain an XBee API command packet is shown in Figure 115.

Figure 115 Converting an IPv6 UDP command packet to an XBee API command packet

The software components involved in the data flow between the XBee module and server are shown in Figure 116. The blue coloured blocks are software elements that were custom developed for the IoT integrated platform.

pg. 114

Server

IoT Gateway XBee S2

Coordinator

XBee S2 End Device

UDP

IPv6 IPv6

UDP to XBee API XBee API

ZigBee Device Object

802.15.4 MAC 802.15.4 PHY

802.15.4 MAC 802.15.4 PHY XBee API to UDP

UDP

Application Support Sublayer and Application

Framework Network 802.2 802.3 802.2 802.3

ZigBee Device Object Application Support Sublayer and Application

Framework Network XBee API

Application RS232 RS232 Application

Figure 116 Flow of information through software and hardware elements between XBee module and Server

The techniques to obtain information from XBee sensor modules, and set parameters of the XBee modules from a server over the internet have been defined in this section. The next section shows how these techniques are used in the software implementation on the IoT gateway to allow information to flow between the server and XBee modules.