My Journey into The Cloud (2)
In the last installment we took a look at the multitude of possible protocols. The diagram here shows the different protocol layers. A common feature built into the IoT concept is that a node can communicate with another node using...
In the last installment we took a look at the multitude of possible protocols. The diagram here shows the different protocol layers. A common feature built into the IoT concept is that a node can communicate with another node using IP; and for this an IP address is used (sub-nodes with sensors and actuator functions can be connected to these nodes using ZigBee or Bluetooth etc. but we won’t delve too far into this at the moment). With any luck there should be enough addresses available: The most recent IP variant, IPv6 has a 128-bit address field, allowing around 340,000,000,000,000,000,000,000,000,000,000,000,000 unique addresses to be defined.
Below the IP are communication channels such as WLAN (Wi-Fi), Ethernet and the cellular mobile phone network, which transfer the IP packets. The 6LoWPAN standard allows IPv6 packets to be sent and received over IEEE 802.15.4 based radio networks and is used, for example, by the ZigBee wireless personal area network. Compared to the classic Internet communication channel this network has a very low power requirement, making it ideal for use in battery-powered applications or for nodes powered by harvested energy.
Most application developers are only really interested with protocols operating above the IP layer. The elegance of protocol stack implementation means that we really need little knowledge of what’s actually going on in the lower layers. The main thing is reliable transfer of IP data packets. On smaller controllers we can, for example, use a pre-installed network module included in the standard firmware. Larger controllers/systems such as the Raspberry Pi use operating systems which already have the necessary functions integrated. These methods can be considered mature because they were originally developed and are used for classic Internet communication.
TCP and UDP are two well established main protocols used to establish a connection and exchange information in the IP. Internet data transfers for emails, web page information with browsers and file transfers, for example, will use TCP/IP. The transfer occurs between two clients known as endpoints or sockets. Each socket has an IP address and port number to identify it. An ingenious process of requests and acknowledgements between the sender and destination sockets ensures that the channel is established before any data packets are sent. In contrast UDP is a protocol with fewer overheads and no acknowledgment handshakes, making it more suitable for applications such as audio and video streaming.
It’s generally not necessary for developers to grapple with the intricacies of TCP and UDP. All of the popular programming languages already have (free) library routines for socket programming. Using these tools it’s relatively easy to transfer data such as sensor values or control information over the Internet. We can build a simple home brew application protocol without much difficulty when only two nodes are involved and we just need to send simple information such as an ON/OFF command or a number value contained in a TCP/IP message over the network. Two examples of such implementations can be found in the upcoming 1-2/2016 edition of Elektor: The ‘WLAN for Microcontroller’ uses a smartphone to send simple ON/OFF commands to control some LEDs on a PCB and ‘Windows on the Raspberry Pi (2)’ shows how a value can be sent over the network and displayed on a seven segment display hooked up to a Raspberry Pi.
For applications such as home automation there will generally be far more than just one subscriber hooked up to the network and information will be supplied by different sensors running on various microcontroller platforms. So how do we ensure the data ends up at the correct destination? Apart from that it’s necessary to think how individual sensors and other nodes can be addressed without the need to remember a list of long IP addresses. From the point of view of energy saving and overall system reliability it is also desirable that sensor messages are available to the user even when the sensor is offline. Fortunately protocols based on TCP and UDP provide additional features to solve the problems.
More on that topic in the next installment!
Below the IP are communication channels such as WLAN (Wi-Fi), Ethernet and the cellular mobile phone network, which transfer the IP packets. The 6LoWPAN standard allows IPv6 packets to be sent and received over IEEE 802.15.4 based radio networks and is used, for example, by the ZigBee wireless personal area network. Compared to the classic Internet communication channel this network has a very low power requirement, making it ideal for use in battery-powered applications or for nodes powered by harvested energy.
Subscribe
Tag alert: Subscribe to the tag Journey into the Cloud - Article series and you will receive an e-mail as soon as a new item about it is published on our website! Most application developers are only really interested with protocols operating above the IP layer. The elegance of protocol stack implementation means that we really need little knowledge of what’s actually going on in the lower layers. The main thing is reliable transfer of IP data packets. On smaller controllers we can, for example, use a pre-installed network module included in the standard firmware. Larger controllers/systems such as the Raspberry Pi use operating systems which already have the necessary functions integrated. These methods can be considered mature because they were originally developed and are used for classic Internet communication.
TCP and UDP are two well established main protocols used to establish a connection and exchange information in the IP. Internet data transfers for emails, web page information with browsers and file transfers, for example, will use TCP/IP. The transfer occurs between two clients known as endpoints or sockets. Each socket has an IP address and port number to identify it. An ingenious process of requests and acknowledgements between the sender and destination sockets ensures that the channel is established before any data packets are sent. In contrast UDP is a protocol with fewer overheads and no acknowledgment handshakes, making it more suitable for applications such as audio and video streaming.
It’s generally not necessary for developers to grapple with the intricacies of TCP and UDP. All of the popular programming languages already have (free) library routines for socket programming. Using these tools it’s relatively easy to transfer data such as sensor values or control information over the Internet. We can build a simple home brew application protocol without much difficulty when only two nodes are involved and we just need to send simple information such as an ON/OFF command or a number value contained in a TCP/IP message over the network. Two examples of such implementations can be found in the upcoming 1-2/2016 edition of Elektor: The ‘WLAN for Microcontroller’ uses a smartphone to send simple ON/OFF commands to control some LEDs on a PCB and ‘Windows on the Raspberry Pi (2)’ shows how a value can be sent over the network and displayed on a seven segment display hooked up to a Raspberry Pi.
For applications such as home automation there will generally be far more than just one subscriber hooked up to the network and information will be supplied by different sensors running on various microcontroller platforms. So how do we ensure the data ends up at the correct destination? Apart from that it’s necessary to think how individual sensors and other nodes can be addressed without the need to remember a list of long IP addresses. From the point of view of energy saving and overall system reliability it is also desirable that sensor messages are available to the user even when the sensor is offline. Fortunately protocols based on TCP and UDP provide additional features to solve the problems.
More on that topic in the next installment!
