internet of things (iot) in 5 days -...
TRANSCRIPT
Internet of ThingsIN 5 DAYS
Antonio Liñán Colina Alvaro Vives Antoine BagulaMarco Zennaro Ermanno Pietrosemoli
iii
Table of ContentsAbout the Release ....................................................................................................... ixAbout the Book ........................................................................................................... xiThe Internet of Things (IoT) ........................................................................................ xiii1. Introduction to IPv6 .................................................................................................. 1
1.1. A little bit of History ....................................................................................... 11.2. IPv6 Concepts .............................................................................................. 2
1.2.1. IPv6 packet ........................................................................................ 31.2.2. IPv6 addressing ................................................................................. 61.2.3. IPv6 network prefix ............................................................................. 8
1.3. What is IPv6 used for? ................................................................................ 101.4. Network Example ........................................................................................ 121.5. Short intro to Wireshark ............................................................................... 131.6. IPv6 Exercises ............................................................................................ 171.7. Addressing Exercises .................................................................................. 191.8. Connecting our IPv6 Network to the Internet ................................................. 20
2. Introduction to 6LoWPAN ....................................................................................... 272.1. Overview of LoWPANs ................................................................................ 282.2. About the use of IP on LoWPANs ................................................................ 292.3. 6LoWPAN ................................................................................................... 312.4. IPv6 Interface Identifier (IID) ........................................................................ 332.5. Header Compression ................................................................................... 342.6. NDP optimization ......................................................................................... 38
3. Introduction to Contiki ............................................................................................. 413.1. Install Contiki .............................................................................................. 41
3.1.1. Install from sources .......................................................................... 423.1.2. Instant Contiki Virtual Machine .......................................................... 43
3.2. Test Contiki installation ................................................................................ 443.3. Contiki structure .......................................................................................... 453.4. Run Contiki on real hardware ....................................................................... 45
3.4.1. Zolertia Zoul module and the RE-Mote development platform ............... 463.4.2. Zolertia Z1 mote ............................................................................... 473.4.3. What are the differences between the RE-Mote and the Z1 platforms? ... 48
3.5. Start with Contiki! ........................................................................................ 483.5.1. Hello world explained ........................................................................ 493.5.2. Makefile explained ............................................................................ 503.5.3. Adding an LED to the example .......................................................... 51
Internet of Things (IoT) in 5 days
iv
3.5.4. Printing messages to the console ...................................................... 533.5.5. Adding button events ........................................................................ 543.5.6. Timers .............................................................................................. 553.5.7. Sensors ............................................................................................ 56
3.6. Emulate Contiki with Cooja .......................................................................... 673.7. Create a new simulation .............................................................................. 683.8. Add motes to the simulation ......................................................................... 68
4. Wireless with Contiki .............................................................................................. 694.1. Preparing your device .................................................................................. 69
4.1.1. Device addressing ............................................................................ 704.1.2. Set the bandwidth and channel ......................................................... 724.1.3. Set the transmission power ............................................................... 764.1.4. Checking the wireless link ................................................................. 81
4.2. Configure the MAC layer ............................................................................. 854.2.1. MAC driver ....................................................................................... 874.2.2. RDC driver ....................................................................................... 884.2.3. Framer driver ................................................................................... 89
4.3. IPv6 and Routing ........................................................................................ 904.3.1. IPv6 ................................................................................................. 904.3.2. RPL ................................................................................................. 914.3.3. Set up a sniffer ................................................................................ 944.3.4. The Border Router ............................................................................ 98
4.4. UDP and TCP basics ................................................................................ 1004.4.1. The UDP API ................................................................................. 1014.4.2. Hands on: UDP example ................................................................. 1044.4.3. Hands on: connecting an IPv6 UDP network to our host .................... 1084.4.4. What is TCP? ................................................................................. 112
5. CoAP, MQTT and HTTP ....................................................................................... 1215.1. CoAP example .......................................................................................... 121
5.1.1. CoAP API ....................................................................................... 1225.1.2. Hands on: CoAP server and Copper ................................................ 125
5.2. MQTT example ......................................................................................... 1335.2.1. MQTT API ...................................................................................... 1345.2.2. Hands on: MQTT and mosquitto ...................................................... 138
5.3. Hands on: connecting to a real world IoT platform (HTTP-based) .................. 1465.4. Ubidots IPv6 example in native Contiki ....................................................... 146
ACRONYMS ............................................................................................................ 151Bibliography ............................................................................................................. 153
v
List of Figures1. Internet-connected devices and the future evolution (Source: Cisco, 2011) ................. xiii2. IoT Layered Architecture (Source: ITU-T) ................................................................ xiv3. IoT 3_Dimensional View (Source: [IoT]) ................................................................... xv1.1. Internet Protocol stack ........................................................................................... 31.2. Data flow in the protocol stack ............................................................................... 41.3. IPv6 Header ......................................................................................................... 51.4. IPv6 Extension headers ......................................................................................... 61.5. IPv6 address ......................................................................................................... 71.6. Network and Interface ID ....................................................................................... 91.7. Packet exchange in IPv6 ..................................................................................... 111.8. Simple IPv6 network ............................................................................................ 121.9. Wireshark logo .................................................................................................... 131.10. Wireshark Screenshot ........................................................................................ 141.11. Ethernet packet ................................................................................................. 151.12. IPv6 packet ....................................................................................................... 151.13. Wireshark Filter ................................................................................................. 151.14. Wireshark Captured packets .............................................................................. 161.15. Wireshark statistics ............................................................................................ 161.16. Wireshark charts ............................................................................................... 171.17. LAN Example .................................................................................................... 191.18. IPv6 Connectivity ............................................................................................... 211.19. Native IPv6 ....................................................................................................... 221.20. IPv4 tunneled IPv6 ............................................................................................ 231.21. Local router does not support IPv6 ..................................................................... 241.22. Simplified Scenario ............................................................................................ 252.1. 6LoWPAN in the protocol stack ............................................................................ 312.2. 6LoWPAN headers .............................................................................................. 332.3. EUI-64 derived IID ............................................................................................... 342.4. IPv6IID ................................................................................................................ 342.5. Header compression ............................................................................................ 352.6. LoWPAN header ................................................................................................. 373.1. Zolertia Zoul module and the RE-Mote platform ..................................................... 463.2. Zolertia Z1 mote .................................................................................................. 473.3. Analogue sensors ................................................................................................ 583.4. Pin assignement .................................................................................................. 603.5. Light sensor ........................................................................................................ 61
Internet of Things (IoT) in 5 days
vi
3.6. Connecting sensor .............................................................................................. 633.7. Temperature and humidity sensor ........................................................................ 664.1. IEEE 802.15.4 2.4 GHz regulation requirements (electronicdesign.com, 2013) ......... 734.2. Thread layers and standards (Thread group, 2015) ............................................... 744.3. Channel assignment ............................................................................................ 754.4. Link quality estimation process ............................................................................. 814.5. Packet rejection rate versus received signal strenght indicator ................................ 834.6. Packet rejection rate versus link quality indicator ................................................... 854.7. Contiki MAC stack ............................................................................................... 874.8. RPL in the protocol stack .................................................................................... 924.9. Sniffer packet capture .......................................................................................... 944.10. Capture options ................................................................................................. 964.11. Interface settings ............................................................................................... 974.12. Captured frames ................................................................................................ 974.13. Wireshark filters ................................................................................................. 984.14. The border router .............................................................................................. 984.15. Z1 mote talking to the PC host ......................................................................... 1125.1. Copper CoAP plugin Screenshot ........................................................................ 1335.2. MQTT publish/suscribe ...................................................................................... 1335.3. MQTT with Mosquitto ......................................................................................... 1385.4. Ubidots endpoint IPv4/IPv6 addresses ................................................................ 1475.5. Ubidots graphs .................................................................................................. 149
vii
List of Tables4.1. CC2538 Transmission power recommended values (from SmartRF Studio) ............. 774.2. CC2420 Transmission power (CC2420 datasheet, page 51) ................................... 784.3. CC1200 Transmission power recommended values (from SmartRF Studio) ............. 79
viii
ix
About the ReleaseThis "IoT in five days" release version correspond to:
Version: 1.0
Date: 7th February 2016
This book and sources are distributed under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)1 .
1 https://creativecommons.org/licenses/by-nc-sa/4.0/
x
xi
About the BookThe "IoT in five days" book is in active development by a joint effort from both academiaand industrial collaborators, acknowledging that the Internet of Things of the future will bebuilt on top of scalable and mature protocols, such as IPv6, 6LoWPAN and IEEE 802.15.4.Open Source Operating Systems as Contiki, with more than 10 years of history and activelysupported by universities and research centers, have been paving the Internet of Things roadsince the early beginnings of Wireless Sensor Networks and M2M communication, enablingthe new IoT paradigm.
The content of the book are Open Source as well, feedback and contribution is more thanwelcome! Please engage visiting IoT in five days GitHub repository1
The book has been developed in asciidoc, and it can be compiled from its sources to produceHTML, PDF, eBook and others formats.
The following are the authors who contributed to this book:
Antonio Liñán defines himself as "an engineer at day, maker at night" (he would do bothfor free). He has more than 8 years of experience,having worked in over than 20 projectsof in Wireless Sensor Networks (WSN), Internet of Things (IoT) applications and embeddedfirmware development; employed at Zolertia as both senior R+D engineer and CTO, buf ifyou ask him he just "makes things blink and chat". In his free time he’s normally engaged inCoursera, collecting hardware platforms, dwelling in hackathons or preaching about GIT. Hehas a Master at the University of Los Andes (Colombia), has worked in European Projectsrelated to Smart Cities, Internet of Things and Security, and currently is a prominent contributorin severals Open Source communities, like the one focusing on Contiki.
Alvaro Vives loves technology, problem solving, learning and teaching. Doing these things hehas become a consultant, a network and systems engineer, and a trainer. As a consultant, hehas worked on projects in several countries, at ISPs, content providers, public organizationsand enterprises. As a trainer, since 2006 has lectured at more than 46 workshops in 18countries directed to ISPs, content providers, public organizations, enterprises as well asin events like LACNIC/LACNOG, SANOG, WALC, and ESNOG. As network and systemsadministrator he has been in charge of production networks and services in several companiesusing different technologies from a variety of vendors. At present, he is working with WSN andIoT as a consequence of the convergence of IPv6 and IoT.
1 https://github.com/marcozennaro/IPv6-WSN-book
xii
Antoine Bagula obtained his doctoral degree in 2006 from the KTH-Royal Institute ofTechnology in Sweden. He held lecturing positions at StellenboschUniversity (SUN) andthe University of Cape Town (UCT) before joining the Computer Science department atthe University of the Western Cape in January 2014. Since 2006, He has been a frequentconsultant of the UNESCO through its International Centre for Theoretical Physics in Trieste,Italy, the World Bank and other international organizations on different telecommunicationprojects. His research interest lies on the Internet-of-Things, Big Data and Cloud Computing,Network security and Network protocols for wireless, wired and hybrid networks.
Marco Zennaro received his M.Sc. degree in Electronic Engineering from University ofTrieste in Italy. He defended his PhD thesis on “Wireless Sensor Networks for Development:Potentials and Open Issues” at KTH-Royal Institute of Technology, Stockholm, Sweden. Hisresearch interest is in ICT4D, the use of ICT for development. In particular, he is interestedin Wireless Networks and in Wireless Sensor Networks in developing countries. He has beengiving lectures on Wireless technologies in more than 20 countries.
When not traveling, he is the editor of the wsnblog.com2 . He is coauthor of the book “WirelessNetworking for the Developing World”.
Ermanno Pietrosemoli is currently a researcher at the Telecommunications/ICT forDevelopment Lab of the International Centre for Theoretical Physics in Trieste, Italy,and President of Fundación Escuela Latinoamericana de Redes, “EsLaRed”, a non-profitorganization that promotes ICT in Latin America through training and development projects.EsLaRed was awarded the 2008 Jonathan B.Postel Service Award by the Internet Society.
Ermanno has been deploying wireless data communication networks focusing on low costtechnology, participating in the planning and building of wireless data networks in Argentina,Colombia, Ecuador, Italy, Lesotho, Malawi, Mexico, Micronesia, Morocco, Mozambique,Nicaragua, Peru, Trinidad, U.S.A., Venezuela and Zambia. He has presented in manyconferences, published several papers related to wireless data communication, and iscoauthor and technical reviewer of the (freely available) book “Wireless Networking for theDeveloping World”3 . Ermanno holds a Master’s degree from Stanford University and wasProfessor of Telecommunications at Universidad de los Andes in Venezuela from 1970 to2000.
2 http://wsnblog.com3 http://wndw.net
xiii
The Internet of Things (IoT)Building upon a complex network connecting billions of devices and humans into a multi-technology, multi-protocol and multi-platform infrastructure, the Internet-of-Things (IoT) mainvision is to create an intelligent world where the physical, the digital and the virtual areconverging to create smart environments that provide more intelligence to the energy, health,transport, cities, industry, buildings and many other areas of our daily life.
The expectation is that of interconnecting millions of islands of smart networks enabling accessto the information not only “anytime” and “anywhere” but also using “anything” and “anyone”ideally through any “path”, “network” and “any service”. This will be achieved by having theobjects that we manipulate daily to be outfitted with sensing, identification and positioningdevices and endowed with an IP address to become smart objects, capable of communicatingwith not only other smart objects but also with humans with the expectation of reachingareas that we could never reach without the advances made in the sensing, identification andpositioning technologies.
While being globally discoverable and queried, these smart objects can similarly discover andinteract with external entities by querying humans, computers and other smart objects. Thesmart objects can also obtain intelligence by making or enabling context related decisionstaking advantage of the available communication channels to provide information aboutthemselves while also accessing information that has been aggregated by other smart objects.
Figure 1. Internet-connected devices andthe future evolution (Source: Cisco, 2011)
As revealed by Figure 1, the IoT is the new essential infrastructure which is predicted toconnect 50 billion of smart objects in 2020 when the world population will reach 7.6 billion.
xiv
As suggested by the ITU, such essential infrastructure will be built around a multi-layeredarchitecture where the smart objects will be used to deliver different services through the fourmain layers depicted by Figure 2: a device layer, a network layer, a support layer and theapplication layer.
In the device layer lie devices (sensors, actuators, RFID devices) and gateways used to collectthe sensor readings for further processing while the network layer provides the necessarytransport and networking capabilities for routing the IoT data to processing places. The supportlayer is a middleware layer that serves to hide the complexity of the lower layers to theapplication layer and provide specific and generic services such as storage in different forms(database management systems and/or cloud computing systems) and many other servicessuch as translation.
Figure 2. IoT Layered Architecture (Source: ITU-T)
As depicted in Figure 3, the IoT can be perceived as an infrastructure driving a number ofapplications services which are enabled by a number of technologies. Its application servicesexpand across many domains such as smart cities, smart transport, smart buildings, smartenergy, smart industry and smart health while it is enabled by different technologies suchas sensing, nanoeletronics, wireless sensor network (WSN), radio frequency identification(RFID), localization, storage and cloud. The IoT systems and applications are designed toprovide security, privacy, safety, integrity, trust, dependability, transparency, anonymity andare bound by ethics constraints.
xv
Figure 3. IoT 3_Dimensional View (Source: [IoT])
Experts say we are heading towards what can be called a "ubiquitous network society",one in which networks and networked devices are omnipresent. RFID and wireless sensorspromise a world of networked and interconnected devices that provide relevant content andinformation whatever the location of the user. Everything from tires to toothbrushes will be incommunications range, heralding the dawn of a new era, one in which today’s Internet (of dataand people) gives way to tomorrow’s Internet of Things.
At the dawn of the Internet revolution, users were amazed at the possibility of contacting peopleand information across the world and across time zones. The next step in this technologicalrevolution (connecting people any-time, anywhere) is to connect inanimate objects to acommunication network. This vision underlying the Internet of things will allow the informationto be accessed not only "anytime" and "anywhere" but also by "anything". This will be facilitatedby using WSNs and RFID tags to extend the communication and monitoring potential of thenetwork of networks, as well as the introduction of computing power in everyday items suchas razors, shoes and packaging.
WSNs are an early form of ubiquitous information and communication networks. They are oneof building blocks of the Internet of things.
Wireless Sensor Networks
A Wireless Sensor Network (WSN) is a self-configuring network of small sensor nodes (so-called motes) communicating among them using radio signals, and deployed in quantity tosense the physical world. Sensor nodes are essentially small computers with extremely basicfunctionality. They consist of a processing unit with limited computational power and limitedmemory, a radio communication device, a power source and one or more sensors.
Motes come in different sizes and shapes, depending on their foreseen use. They can be verysmall, if they are to be deployed in big numbers and need to have little visual impact. They can
xvi
have a rechargeable battery power source if they are to be used in a lab. The integration ofthese tiny, ubiquitous electronic devices in the most diverse scenarios ensures a wide range ofapplications. Some of the application areas are environmental monitoring, agriculture, healthand security.
In a typical application, a WSN is scattered in a region where it is meant to collect data throughits sensor nodes. These networks provide a bridge between the physical world and the virtualworld. They promise unprecedented abilities to observe and understand large scale, real-world phenomena at a fine spatio-temporal resolution. This is so because one deploys sensornodes in large numbers directly in the field, where the experiments take place. All motes arecomposed of five main elements as shown below:
1. Processor: the task of this unit is to process locally sensed information and informationsensed by other devices. At present the processors are limited in terms of computationalpower, but given Moore’s law, future devices will come in smaller sizes, will be morepowerful and consume less energy. The processor can run in different modes: sleep isused most of the time to save power, idle is used when data can arrive from other motes,and active is used when data is sensed or sent to / received from other motes.
2. Power source: motes are meant to be deployed in various environments, including remoteand hostile regions so they must use little power. Sensor nodes typically have little energystorage, so networking protocols must emphasize power conservation. They also musthave built-in mechanisms that allow the end user the option of prolonging network lifetimeat the cost of lower throughput. Sensor nodes may be equipped with effective powerscavenging methods, such as solar cells, so they may be left unattended for months, oryears. Common sources of power are rechargeable batteries, solar panels and capacitors.
3. Memory: it is used to store both programs (instructions executed by the processor) anddata (raw and processed sensor measurements).
4. Radio: WSN devices include a low-rate, short-range wireless radio. Typical rates are10-100 kbps, and range is less than 100 meters. Radio communication is often the mostpower-intensive task, so it is a must to incorporate energy-efficient techniques such aswake-up modes. Sophisticated algorithms and protocols are employed to address theissues of lifetime maximization, robustness and fault tolerance.
5. Sensors: sensor networks may consist of many different types of sensors capableof monitoring a wide variety of ambient conditions. Table 1 classifies the three maincategories of sensors based on field-readiness and scalability. While scalability reveals ifthe sensors are small and inexpensive enough to scale up to many distributed systems,the field-readiness describes the sensor’s engineering efficiency with relation to field
xvii
deployment. In terms of the engineering efficiency, Table 1 reveals high field-readiness formost physical sensors and for a few chemical sensors since most chemical sensors lie inthe medium and low levels, while biological sensors have low field-readiness.
Sensor Category Parameter Field-Readiness Scalability
Physical Temperature High High
Moisture Content High High
Flow rate, Flowvelocity
High Med-High
Pressure High High
Light Transmission(Turb)
High High
Chemical Dissolved Oxygen High High
ElectricalConductivity
High High
pH High High
Oxydation ReductionPotential
Medium High
Major Ionic Species(Cl-, Na+)
Low-Medium High
Nutrientsa (Nitrate,Ammonium)
Low-Medium Low-High
Heavy metals Low Low
Small OrganicCompounds
Low Low
Large OrganicCompounds
Low Low
Biological Microorganisms Low Low
Biologically activecontaminants
Low Low
Common applications include the sensing of temperature, humidity, light, pressure, noiselevels, acceleration, soil moisture, etc. Due to bandwidth and power constraints, devicesprimarily support low-data-units with limited computational power and limited rate of sensing.
xviii
Some applications require multi-mode sensing, so each device may have several sensors onboard.
Following is a short description of the technical characteristics of WSNs that make thistechnology attractive.
1. Wireless Networking: motes communicate with each other via radio in order to exchangeand process data collected by their sensing unit. In some cases, they can use other nodesas relays, in which case the network is said to be multi-hop. If nodes communicate onlydirectly with each other or with the gateway, the network is said to be single-hop. Wirelessconnectivity allows to retrieve data in real-time from locations that are difficult to access. Italso makes the monitoring system less intrusive in places where wires would disturb thenormal operation of the environment to monitor. It reduces the costs of installation: it hasbeen estimated that wireless technology could eliminate up to 80 % of this cost.
2. Self-organization: motes organize themselves into an ad-hoc network, which means theydo not need any pre-existing infrastructure. In WSNs, each mote is programmed to run adiscovery of its neighborhood, to recognize which are the nodes that it can hear and talkto over its radio. The capacity of organizing spontaneously in a network makes them easyto deploy, expand and maintain, as well as resilient to the failure of individual points.
3. Low-power: WSNs can be installed in remote locations where power sources are notavailable. They must therefore rely on power given by batteries or obtained by energyharvesting techniques such as solar panels. In order to run for several months of years,motes must use low-power radios and processors and implement power efficient schemes.The processor must go to sleep mode as long as possible, and the Medium-Access layermust be designed accordingly. Thanks to these techniques, WSNs allow for long-lastingdeployments in remote locations.
Applications of Wireless Sensor Networks
The integration of these tiny, ubiquitous electronic devices in the most diverse scenariosensures a wide range of applications. Some of the most common application areas areenvironmental monitoring, agriculture, health and security. In a typical application, a WSNinclude:
1. Tracking the movement of animals. A large sensor network has been deployed to studythe effect of micro climate factors in habitat selection of sea birds on Great Duck Islandin Maine, USA. Researchers placed their sensors in burrows and used heat to detectthe presence of nesting birds, providing invaluable data to biological researchers. Thedeployment was heterogeneous in that it employed burrow nodes and weather nodes.
xix
2. Forest fire detection. Since sensor nodes can be strategically deployed in a forest, sensornodes can relay the exact origin of the fire to the end users before the fire is spreaduncontrollable. Researchers from the University of California, Berkeley, demonstrated thefeasibility of sensor network technology in a fire environment with their FireBug application.
3. Flood detection. An example is the ALERT system deployed in the US. It uses sensorsthat detect rainfall, water level and weather conditions. These sensors supply informationto a centralized database system.
4. Geophysical research. A group of researchers from Harvard deployed a sensor networkon an active volcano in South America to monitor seismic activity and similar conditionsrelated to volcanic eruptions.
5. Agricultural applications of WSN include precision agriculture and monitoring conditionsthat affect crops and livestock. Many of the problems in managing farms to maximizeproduction while achieving environmental goals can only be solved with appropriate data.WSN can also be used in retail control, particularly in goods that require being maintainedunder controlled conditions (temperature, humidity, light intensity, etc) [SusAgri].
6. An application of WSN in security is predictive maintenance. BP’s Loch Rannoch projectdeveloped a commercial system to be used in refineries. This system monitors criticalrotating machinery to evaluate operation conditions and report when wear and tear isdetected. Thus one can understand how a machine is wearing and perform predictivemaintenance. Sensor networks can be used to detect chemical agents in the air and water.They can also help to identify the type, concentration and location of pollutants.
7. An example of the use of WSN in health applications is the Bi-Fi, embedded systemarchitecture for patient monitoring in hospitals and out-patient care. It has been conceivedat UCLA and is based on the SunSPOT architecture by Sun. The motes measure high-rate biological data such as neural signals, pulse oximetry and electrocardiographs. Thedata is then interpreted, filtered, and transmitted by the motes to enable early warnings.
Roles in a Wireless Sensor Network
Nodes in a WSN can play different roles.
1. Sensor nodes are used to sense their surroundings and transmit the sensor readings toa sink node, also called "base station". They are typically equipped with different kinds ofsensors. A mote is endowed with on-board processing, communication capabilities andsensing capabilities.
2. Sink nodes or "base stations" are tasked to collect the sensor readings of the othernodes and pass these readings to a gateway to which they are directly connected for
xx
further processing/analysis. A sink node is endowed with minimal on-board processingand communication capabilities but does not have sensing capabilities.
3. Actuators are devices which are used to control the environment, based on triggersrevealed by the sensor readings or by other inputs. An actuator may have the sameconfiguration as a mote but it is also endowed with controlling capabilities, for example toswitch a light on under low luminosity.
Gateways often connected to sink nodes and are usually fed by a stable power supplysince they consume considerable energy. These entities are normal computing devices suchas laptops, notebooks, desktops, mobile phones or other emerging devices which are ableto store, process and route the sensor readings to the processing place. However, theymay not be endowed with sensing capabilities. Being range-limited, sensor motes requiremulti-hop communication capabilities to allow: 1) spanning distances much larger than thetransmission range of a single node through localized communication between neighbor nodes2) adaptation to network changes, for example, by routing around a failed node using adifferent path in order to improve performance and 3) using less transmitter power as a resultof the shorter distance to be spanned by each node. They are deployed in three forms : (1)Sensor node used to sense the environment (2) Relay node used as relay for the sensorreadings received from other nodes and (3) Sink node also often called base station whichis connected to a gateway (laptop, tablet, iPod, Smart phone, desktop) with higher energybudget capable of either processing the sensor readings locally or to transmit these readingsto remote processing places.
1
Chapter 1. Introduction to IPv6IPv6 stands for Internet Protocol version 6, so the importance of IPv6 is implicit in its name,it’s as important as the Internet! The Internet Protocol (IP from now on) was intended as asolution to the need to interconnect different data networks, and has become the “de facto”standard for all kinds of digital communications. Nowadays IP is present in most devices thatare able to send and receive digital information, not only the Internet.
IP is standardized by the IETF (Internet Engineering Task Force), the organization in chargeof all the Internet standards, guaranteeing the interoperability among software from differentvendors. The fact that IP is a standard is of vital importance, because today everything isgetting connected to the Internet using IP. All common Operating Systems and networkinglibraries support IP to send and receive data. As part of this "everything-connected-to-Internet"is the IoT, so now you know why you are reading this chapter about IPv6, the last version ofthe Internet Protocol. In other words, today, the easiest way to send and receive data is bymeans of the standards used in the Internet, including IP.
The objectives of this chapter are:
• Briefly describe the history of the Internet Protocol.
• Find out what IPv6 is used for.
• Get the IPv6 related concepts needed to understand the rest of the book.
• Provide a practical overview of IPv6, including addresses and a glimpse of how an IPv6network looks like.
1.1. A little bit of History
ARPAnet was the first attempt of the US Department of Defense (DoD) to devise adecentralized network more resilient to an attack, while able to interconnect completelydifferent systems. ARPAnet was created in the seventies, but it was in 1983 when a brandnew protocol stack was introduced, TCP/IP. The first widely used network protocol versionwas IPv4 (Internet Protocol version 4) which paved the way to the civilian Internet. Initiallyonly research centers and universities were connected, supported by the NSF (NationalScience Foundation), and commercial applications where not allowed, but when the networkstarted growing exponentially the NSF decided to transfer its operation and funding to privateoperators, lifting the restrictions to commercial traffic. While the main applications were email
IPv6 Concepts
2
and file transfer, it was with the development of the World Wide Web based on the HTMLprotocol and specifically with the MOSAIC graphic interface browser and its successors thatthe traffic really exploded and the Internet began to be used by the masses. As a consequencethere was a rapid depletion in the number of IP addresses available under IPv4, which wasnot designed to scale to these levels.
In order to allow for more addresses, you need a longer IP address space (greater numberof bits to specify the address), which means a new architecture, which means changes tomost of the routing and network software. After examining a number of proposals, the IETFsettled on IPv6, described in the January 1995 RFC (Request for Comment, the official IETFdocumentation naming) 1752, sometimes also referred to as the Next Generation InternetProtocol, or IPng. The IETF updated the IPv6 standard in 1998 with the current definitioncovered in RFC 2460. By 2004, IPv6 was widely available from industry and supported bymost new network equipment. Today IPv6 coexists with IPv4 in the Internet and the amountof IPv6 traffic is quickly growing as more and more ISPs and content providers have startedsupporting IPv6.
As you can see, the history of IP and Internet are almost the same, and because of this thegrowth of Internet is been hampered by the limitations of IPv4, and has led to the developmentof a new version of IP, IPv6, as the protocol to be used to interconnect all sorts of devices tosend and/or receive information. There are even some technologies that are being developedonly with IPv6 in mind, a good example in the context of the IoT is 6LowPAN.
From now on we will only center on IPv6. If you know something about IPv4, then you havehalf the way done, if not, don’t worry we will cover the main concepts briefly and gently.
1.2. IPv6 Concepts
We will cover the the minimum you need to know about the last version of the Internet Protocolto understand why it’s so useful for the IoT and how it’s related with other protocols like6LowPAN discussed later. We will assume that you are familiar with bits, bytes, networkingstack, network layer, packets, IP header, etc. You should understand that IPv6 is a differentprotocol, non-compatible with IPv4.
In the following figure we represent the layered model used in the Internet.
IPv6 packet
3
Figure 1.1. Internet Protocol stack
IPv6 sits in layer 3, called network layer. The pieces of data handled by layer 3 are calledpackets. Devices connected to the Internet can be hosts or routers. A host can be a PC, alaptop or a sensor board, sending and/or receiving data packets. Hosts will be the sourceor destination of the packets. Routers instead are in charge of packet forwarding, and areresponsible of choosing the next router that will forward them towards the final destination.Internet is composed of a lot of interconnected routers, which receive data packets inone interface and send then as quick as possible using another interface towards anotherforwarding router.
1.2.1. IPv6 packet
The first thing you should know is what an IPv6 packet looks like. In the layered model we sawbefore, each layer introduces its own information in the packet, and this information is intendedfor, and can only be processed by the same layer in another IP device. This "conversation"between layers at the same level on different devices must follow a protocol.
The Internet layers are:
• Application: Here resides the software developed by programmers, that will use networkservices offered by the network stack. An example is the web browser that opens a networkconnection towards a web server. Another example is the web server software that runsin a server somewhere in the Internet waiting to answer request from client’s browsers.Examples of application protocols are HTTP and DNS.
• Transport: Is a layer above the network layer that offers additional to it, for example,retransmission of lost packets or guaranteeing that the packets are received in the sameorder they were sent. This layer will be the one that shows a "network service" to theapplication layer, a service they can use to send or receive data. TCP and UDP are themost common transport protocols used in Internet.
IPv6 packet
4
• Network: This is the layer in charge of the correct delivery of the data received from thetransport layer to its destination, as well as the reception of the received data from thelink layer at the data destination. Internet uses only one protocol in this layer, namely IP.Source and destination are identified by means of the IP addresses.
• Link: Link layer is in charge of sending and receiving frames, a collection of bytes sent fromthe network layer, in the realm of a local area network or LAN. It specifies the mecanismused to share the medim among diffrent nodes. This layer has its own addresses, whichdepend on the technology deployed.
• Physical: This layer is in charge of the details of the electromagnetic signal, codifications,etc. needed for the digital information to go from one node to another. All physical mediaare included, both wired and wireless.
The following figure illustrates the idea that each of the layers described receive some bytesfrom the layer above and adds some specific information pertaining that layer to be processedin the receiving host. In the figure data originating at the application layer is sent to the physicallayer of another node.
Figure 1.2. Data flow in the protocol stack
The bytes sent and received in the IP packet follow a standard format. The following figureshows the basic IPv6 header:
IPv6 packet
5
Figure 1.3. IPv6 Header
First you have the basic IPv6 header with a fixed size of 40 bytes, followed by upper layerdata and optionally by some extension headers, which will be described later. As you can seethere are several fields in the packet header, providing some improvements as compared withIPv4 header:
• The number of fields has been reduced from 12 to 8.
• The basic IPv6 header has a fixed size of 40 bytes and is aligned with 64 bits, allowing afaster hardware-based packet forwarding on routers.
• The size of addresses increased from 32 to 128 bits.
The most important fields are the source and destination addresses. As you already know,every IP device has a unique IP address that identifies it in the Internet. This IP address isused by routers to take their forwarding decisions.
IPv6 header has 128 bits for each IPv6 address, this allows for 2128 addresses (approximately3.4×1038,i.e., 3.4 followed by 38 zeroes), whereas IPv4 uses 32 bits to encode each of the232 addresses (4,294,967,296) allowed.
We have seen the basic IPv6 header, and mentioned the extension headers. To keep thebasic header simple and of a fixed size, additional features are added to IPv6 by means ofextension headers.
IPv6 addressing
6
Figure 1.4. IPv6 Extension headers
Several extension headers have been defined, as you can see in the previous figure, and theyhave to follow the order shown. Extensions headers:
• Provide flexibility, for example, to enable security by ciphering the data in the packet.
• Optimize the processing of the packet, because with the exception of the hop by hopheader, extensions are processed only by end nodes, (source and final destination of thepacket), not by every router in the path.
• They are located as a "chain of headers" starting always in the basic IPv6 header, that usethe field next header to point to the following extension header.
1.2.2. IPv6 addressing
1. The use of 128 bits for addresses brings some benefits:
• Provides many more addresses, to satisfy current and future needs, with ample spacefor innovation.
• Simplifies address auto-configuration mechanisms.
• Easier address management/delegation.
• Room for more levels of hierarchy and for route aggregation.
• Ability to do end-to-end IPsec.
IPv6 addresses are classified into the following categories (which also exist in IPv4):
IPv6 addressing
7
• Unicast (one-to-one): used to send a packet from the source to a single destination. Theyare the commonest ones and we will talk more about them and their sub-classes.
• Multicast (one-to-many): used to send a packet from the source to several destinations.This is possible by means of multicast routing that enable packets to replicate in someplaces.
• Anycast (one-to-nearest): used to send a packet from the source to the nearest destinationfrom a set of them.
• Reserved: Addresses or groups of them for special uses, for example addresses to beused on documentation and examples.
Before entering into more detail about IPv6 addresses and the types of unicast addresses,let’s see how do they look like and what are the notation rules. You need to have them clearbecause probably the first problem you will find in practice when using IPv6 is how to writean address.
Figure 1.5. IPv6 address
IPv6 addresses notation rules are:
• 8 Groups of 16 bits separated by “:”.
• Hexadecimal notation of each nibble (4 bits).
• Non case sensitive.
• Network Prefixes (group of addresses) are written Prefix / Prefix Length, i.e., prefix lengthindicate the number of bits of the address that are common for the group.
• Leftmost zeroes within each group can be eliminated.
• One or more all-zero-groups can be substituted by “::”. This can be done only once.
The first three rules tell you the basis of IPv6 address notation. They use hexadecimal notation,i.e., numbers are represented by sixteen symbols between 0 and F. You will have eight groups
IPv6 network prefix
8
of four hexadecimal symbols, each group separated by a colon ":". The last two rules are foraddress notation compression, we will see how this works in the following.
Let’s see some examples:
1) If we represent all the address bits we have the preferred form, for example:2001:0db8:4004:0010:0000:0000:6543:0ffd
2) If we use squared brackets around the address we have the literal form of the address:[2001:0db8:4004:0010:0000:0000:6543:0ffd]
3) If we apply the fourth rule, allowing compression within each group by eliminating leftmostzeroes, we have: 2001:db8:4004:10:0:0:6543:ffd
4) If we apply the fifth rule, allowing compression of one or more consecutive groups of zeroesusing "::", we have: 2001:db8:4004:10::6543:ffd
Care should be taken when compressing and decompressing IPv6 addresses. The processshould be reversible. It’s very common to have some mistakes. For example, the followingaddress 2001:db8:A:0:0:12:0:80 could be compressed even more using "::". we havetwo options:
a) 2001:db8:A::12:0:80 b) 2001:db8:A:0:0:12::80
Both are correct IPv6 addresses. But the address 2001:db8:A::12::80 is wrong, sinceit does not follow the last compression rule we saw above. The problem with this badlycompressed address is that we can’t be sure how to expand it, its ambiguous. We can’t knowif it expands to 2001:db8:A:0:12:0:0:80 or to 2001:db8:A:0:0:12:0:80 .
1.2.3. IPv6 network prefix
Last but not least you have to understand the concept of a network prefix, that indicatessome fixed bits and some non-defined bits that could be used to create new sub-prefixes orto define complete IPv6 addresses assigned to hosts.
Let’s see some examples:
1) The network prefix 2001:db8:1::/48 (the compressed form of2001:0db8:0001:0000:0000:0000:0000:0000 ) indicates that the first 48 bits willalways be the same ( 2001:0db8:0001 ) but that we can play with the other80 bits, for example, to obtain two smaller prefixes: 2001:db8:1:a::/64 and2001:db8:1:b::/64 .
IPv6 network prefix
9
2) If we take one of the smaller prefixes defined above, 2001:db8:1:b::/64 , where thefirst 64 bits are fixed we have the rightmost 64 bits to assign, for example, to an IPv6 interfacein a host: 2001:db8:1:b:1:2:3:4 . This last example allow us to introduce a basic conceptin IPv6: * A /64 prefix is always used in a LAN (Local Area Network) . *The rightmost 64 bits,are called the interface identifier (IID) because they uniquely identify a host’s interfacein the local network defined by the /64 prefix. The following figure illustrates this statement:
Figure 1.6. Network and Interface ID
Now that you have seen your first IPv6 addresses we can enter into more detail about twotypes of addresses you will find when you start working with IPv6: reserved and unicast.
• The unspecified address, used as a placeholder when no address is available:0:0:0:0:0:0:0:0 (::/128)
• The loopback address, is used by a node to send an IPv6 packet to itself:0:0:0:0:0:0:0:1 (::1/128)
• Documentation Prefix: 2001:db8::/32 . This prefix is reserved to be used in examplesand documentation, you have already seen it in this chapter.
As specified in [RFC6890] IANA maintains a registry of special purpose IPv6 addresses [IANA-IPV6-SPEC].
The following are some other types of unicast addresses [RFC4291]:
• Link-local: Link-local addresses are always present in an IPv6 interface that is connectedto a network. They all start with the prefix FE80::/10 and can be used to communicatewith other hosts on the same local network, i.e., all hosts connected to the same switch.They cannot be used to communicate with other networks, i.e., to send or receive packetsthrough a router.
• ULA (Unique Local Address) [RFC4193]: All ULA addresses start with the prefix FC00::/7,which in practice means that you could see FC00::/8 or FD00::/8 . Intended for localcommunications, usually inside a single site, they are not expected to be routable on theglobal Internet butused only inside a more limited environment.
• Global Unicast: Equivalent to the IPv4 public addresses, they are unique in the wholeInternet and can be used to send a packet from one site to any destination in Internet.
What is IPv6 used for?
10
1.3. What is IPv6 used for?
As we have seen IPv6 has some features that facilitates things like global addressing andhost’s address autoconfiguration. Because IPv6 provides as many addresses as we mayneed for some hundreds of years, we can put a global unicast IPv6 address on almostanything we may think of. This brings back the initial Internet paradigm that every IP devicecould communicate with every IP device. This end-to-end communication allows bidirectionalcommunication all over the Internet and between any IP device, which could result incollaborative applications and new ways of storing, sending and accessing the information.
In the context of this book we can, for example, contemplate IPv6 sensors all around the worldcollecting, sending and being accessed from different places to create a world-wide mesh ofphysical values measured, stored and processed.
The availability of a huge amount of addresses has allowed a new mechanism called statelessaddress autoconfiguration (SLAAC) that didn’t exist with IPv4. Here is a brief summary ofdifferent ways to configure an address on an IPv6 interface:
• Statically: You can decide which address you will give to your IP device and then manuallyconfigure it into the device using any kind of interface: web, command line, etc. Normallyyou also have to configure other network parameters like the gateway to use to sendpackets out of your network.
• DHCPv6 (Dynamic Host Configuration Protocol for IPv6) [RFC3315]: A porting of thesimilar mechanism already available in IPv4. You need to configure a dedicated serverthat after a brief negotiation with the device assigns an IP address to it. DHCPv6allows IP devices to be configured automatically, this is why it is named stateful addressautoconfiguration, because the DHCPv6 server maintains a state of assigned addresses.
• SLAAC: Stateless address autoconfiguration [RFC4862] is a new mechanism introducedwith IPv6 that allows to configure automatically all network parameters on an IP deviceusing the router that gives connectivity to a network.
The advantage of SLAAC is that it simplifies the configuration of "dumb" devices, like sensors,cameras or any other device with low processing power. You don’t need to use any interfacein the IP device to configure anything, just "plug and net". It also simplifies the networkinfrastructure needed to build a basic IPv6 network, because you don’t need additional device/server, you use the same router you need to send packets outside your network to configurethe IP devices. We are not going to enter into details, but you just need to know that ina LAN (Local Area Network), connected to Internet by means of a router, this router is in
What is IPv6 used for?
11
charge of sending all the configuration information needed to its hosts using an RA (RouterAdvertisement) message. The router will send RAs periodically, but in order to expeditethe process a host can send an RS (Router Solicitation) message when its interface getsconnected to the network. The router will send an RA immediately in response to the RS.
The following figure show the packet exchange between a host that has just connected to alocal network and some IPv6 destination in the Internet:
Figure 1.7. Packet exchange in IPv6
1) R1 is the router that gives connectivity to the host in the LAN and is periodically sending RAs.
2) Both R1 and Host have a link-local address in their interfaces connected to the host’s LAN,this address is configured automatically when the interface is ready. Our host creates it’s link-local address by combining the 64 leftmost bits of the link-local’s prefix ( fe80::/64 ) andthe 64 rightmost bits of a locally generated IID ( :3432:7ff1:c001:c2a1 ). These link-localaddresses can be used in the LAN to exchange packets, but not to send packets outside theLAN.
3) The hosts needs two basic things to be able to send packets to other networks: a globalIPv6 address and the address of a gateway, i.e., a router to which send the packets it wantsto get routed outside its network.
4) Although R1 is sending RAs periodically (usually every several seconds) when the host getconnected and has configured its link-local address, it sends an RS to which R1 respondsimmediately with an RA containing two things:
1. A global prefix of length 64 bits that is intended for SLAAC. The host takes thereceived prefix and adds to it a locally generated IID, usually the same one used for link-
Network Example
12
local address. This way a global IPv6 address is configured in the host and now cancommunicate with the IPv6 Internet
2. Implicitly included is the link-local address of R1, because it is the source address of theRA. Our host can use this address to configure the default gateway, the place to whichsend the packets by default, to reach an IPv6 host somewhere in Internet.
5) Once both the gateway and global IPv6 address are configured, the host can receive orsend information. In the figure it has something to send (Tx Data) to a host in Internet, soit creates an IPv6 packet with the destination address of the recipient host and as sourceaddress the just autoconfigured global address, which is sent to its gateway, R1’s link-localaddress. The destination host can answer with some data (Rx Data).
1.4. Network ExampleFollowing we show how a simple IPv6 network looks like, displaying IPv6 addresses for allthe networking devices.
Figure 1.8. Simple IPv6 network
We have four hosts, (sensors, or other devices), and we want to put a pair of them in twodifferent places, for example two floors in a building. We are dealing with four IP devices butyou can have up to 264 (18,446,744,073,709,551,616) devices connected on the same LAN.
We create two LANs with a router on each one, both routers connected to acentral router (R1) that provides connectivity to Internet. LAN1 is served by R2(with link-local address fe80::2c:f3f4:1214:a on that LAN) and uses the prefix2001:db8:1:2::/64 announced by SLAAC. LAN2 is served by R3 (with link-local address
Short intro to Wireshark
13
fe80::1b:fff4:3344:b on that LAN) and uses the prefix 2001:db8:1:3::/64
announced by SLAAC.
All hosts have both a link-local IPv6 address and a global IPv6 address autoconfigured usingthe prefix provided by the corresponding router by means of RAs. In addition, remember thateach host also configures the gateway using the link-local address used by the router for theRA. Link-local address can be used for communication among hosts inside a LAN, but forcommunicating with hosts in other LANs or any other network outside its own LAN a globalIPv6 address is needed.
1.5. Short intro to Wireshark
What is Wireshark?
Figure 1.9. Wireshark logo
Wireshark is a free and open-source packet analyzer, which allows packet traces tobe sniffed, captured, and analyzed.
A packet trace is a record of traffic at some location on the network, as if a snapshotwas taken of all the bits that passed across a particular wire. The packet trace recordsa timestamp for each packet, along with the bits that make up the packet, from thelow-layer headers to the higher-layer contents.
Wireshark runs on most operating systems, including Windows, MAC and Linux. Itprovides a graphical user interface that shows the sequence of packets and themeaning of the bits when interpreted as protocol headers and data. The packets arecolor-coded to convey their meaning, and Wireshark includes various ways to filterand analyze them to let you investigate different aspects of behavior. It is widely usedto troubleshoot networks.
A common usage scenario is when a person wants to troubleshoot network problemsor look at the internal workings of a network protocol. A user could, for example,
Short intro to Wireshark
14
see exactly what happens when he or she opens up a website or sets up a wirelesssensor network. It is also possible to filter and search for given packet attributes, whichfacilitates the debugging process.
More information and installation instructions are available at Wireshark site1 .
Figure 1.10. Wireshark Screenshot
When you open Wireshark, there are four main areas, from top to bottom: menus and filters, listof captured packets, detailed information about the selected packet, including its full content inhexadecimal and ASCII. Online directly links you to the Wiresharks site, where you can find ahandy user guide and information on the security of Wireshark. Under Files, you’ll find Open,which lets you open previously captured files,, and Sample Captures. You can download anyof the sample captures through this website, and study the data. This will help you understandwhat kind of packets Wireshark can capture.
The Capture section let you choose your Interface from the available ones. It’ll also show youwhich ones are active. Clicking details will show you some pretty generic information aboutthat interface.
Under Start, you can choose one or more interfaces to check out. Capture Options allowsyou to customize what information you see during a capture. Here you can choose a filter, acapture file, and more. Under Capture Help, you can read up on how to capture, and you cancheck info on Network Media about which interfaces work on which platforms.
Let’s select an interface and click Start. To stop a capture, press the red square in the toptoolbar. If you want to start a new capture, hit the green triangle which looks like a shark fin
1 https://www.wireshark.org/
Short intro to Wireshark
15
next to it. Now that you have got a finished capture, you can click File, and save, open, ormerge the capture. You can print it, you can quit the program, and you can export your packetcapture in a variety of ways.
You can find a certain packet, copy packets, mark (highlight) any specific packet or all thepackets. Another interesting thing you can do under Edit, is resetting the time value. You’llnotice that the time is in seconds incrementing. You can reset it from the packet you’ve clickedon. You can add a comment to a packet, configure profiles and preferences.
When we select a packet from the list of captured ones, Wireshark shows detailed informationof the different protocols used by that packet, for example Ethernet:
Figure 1.11. Ethernet packet
Or IPv6, where we can see the fields we mentioned before: Version, Traffic class, flowlabel,payload length, next header, etc.:
Figure 1.12. IPv6 packet
There are two methods to apply filters to the list of captured packets:
• Write a filter expression on the specific box and then apply it. Protocols can bespecified (ip,ipv6, icmp, icmpv6), fields of a protocol (ipv6.dst, ipv6.src) and even complexexpressions can be created using operators like AND (&&), OR (||) or the negation (|).
Figure 1.13. Wireshark Filter
• Another option to create filters is to right click in one filed of a captured packet, in the listof captured packets. There will appear a menu option "Apply as filter", with several optionson how to use that field.
Short intro to Wireshark
16
Figure 1.14. Wireshark Captured packets
Another useful and interesting option of Wireshark is the possibility to see statistics about thecaptured traffic. If we have applied filters, the statistics will be about the filtered traffic. Just goto the Statistics menu and select, for example, Protocol Hierarchy:
Figure 1.15. Wireshark statistics
Other interesting options are:
• Conversation List → IPv6
• Statistics → Endpoint List → IPv6
• Statistics → IO Graph
This last option allow to create graphs with different lines for different types of traffic and savethe image:
IPv6 Exercises
17
Figure 1.16. Wireshark charts
1.6. IPv6 ExercisesLet’s test your IPv6 knowledge with the following exercises:
1) What is the size of IPv4 and IPv6 addresses?
a. 32-bits, 128-bits
b. 32-bits, 64-bits
c. 32-bits, 112-bits
d. 32-bits, 96-bits
e. none of these
2) Which of the following is a valid IPv6 address notation rule?
a. Zeroes on the right inside a group of 16 bits can be eliminated
b. The address is divided in 5 groups of 16 bits separated by ":"
c. The address is divided in 8 groups of 16 bits separated by "."
d. One or more groups of all zeroes could be substituted by "::"
e. Decimal notation is used grouping bits in 4 (nibbles)
3) Interface Identifiers (IID) or the rightmost bits of an IPv6 address used on a LAN will be64 bits long.
a. True
b. False
4) Which of the following is a correct IPv6 address?
IPv6 Exercises
18
a. 2001:db8:A:B:C:D::1
b. 2001:db8:000A:B00::1:3:2:F
c. 2001:db8:G1A:A:FF3E::D
d. 2001:0db8::F:A::B
5) Which ones of the following sub-prefixes belong to the prefix 2001:db8:0A00::/48 ?(Choose all that apply)
a. 2001:db9:0A00:0200::/56
b. 2001:db8:0A00:A10::/64
c. 2001:db8:0A:F:E::/64
d. 2001:db8:0A00::/64
6) IPv6 has a basic header with more fields than IPv4 header
a. True
b. False
7) Extension headers can be added in any order
a. True
b. False
8) Autoconfiguration of IP devices is the same in IPv4 and IPv6
a. True
b. False
9) Which one is not an option for configuring an IPv6 address in an interface?
a. DHCPv6
b. Fixed address configured by vendor
c. Manually
d. SLAAC (Stateless Address Autoconfiguration)
10) Which packets are used by SLAAC to autoconfigure an IPv6 host?
a. NS/NA (Neighbor Solicitation / Neighbor Advertisement)
b. RS/RA (Router Solicitation / Router Advertisement)
Addressing Exercises
19
c. Redirect messages
d. NS / RA (Neighbor Solicitation / Router Advertisement)
1.7. Addressing ExercisesA) Use the two compression rules for the utmost compression of the following addresses:
1. 2001:0db8:00A0:7200:0fe0:000B:0000:0005
2. 2001:0db8::DEFE:0000:C000
3. 2001:db8:DAC0:0FED:0000:0000:0B00:12
B) Apply maximum decompression (representing all the 32 nibbles in hexadecimal) to thefollowing addresses:
1. 2001:db8:0:50::A:123
2. 2001:db8:5::1
3. 2001:db8:C00::222:0CC0
C) You receive the following IPv6 prefix for your network: 2001:db8:A:0100::/56 , shownin the following figure:
Figure 1.17. LAN Example
Connecting our IPv6 Network to the Internet
20
Please determine:
a. IPv6 prefix for LAN1, a /64 prefix taken from the /56 you have.
b. IPv6 prefix for LAN2, a /64 prefix taken from the /56 you have.
c. IPv6 prefix for LAN3, a /64 prefix taken from the /56 you have.
d. A global IPv6 address using the LAN1 prefix for H1 host (added to the link-local addressalready used).
e. A global IPv6 address using the LAN2 prefix for H2 host (added to the link-local addressalready used).
f. A global IPv6 address using the LAN3 prefix for H3 host (added to the link-local addressalready used).
Hint: To divide the /56 prefix into /64 prefixes, you have tochange the value of the bits 57 to 64, i.e., the XY values in2001:db8:A:01XY::/64 .
1.8. Connecting our IPv6 Network to the Internet
As said in the introduction of this book, network communications is one of the four basicelements of an IoT system. We already have seen that IPv6 brings the possibility of giving anIP address to almost anything we can think of, and can do this making it easy to autoconfoigurenetwork parameters on our devices.
Once we have all our "things" connected using IPv6, they can use it to communicate amongthem locally or with any other "thing" on the IPv6 Internet. In this chapter we will focus on theInternet side of the communication of the "things" composing the Internet of Things.
As we will see in this book, the capability of connecting our devices to the Internet allowsnew possibilities and services. For example, we can connect our wireless sensors networksto a centralized repository, where all the sensed information can be processed and stored forhistorical records, which will uncover underlying patterns and maybe predict future events.This basic idea is what nowadays is called "Big Data" and has a whole set of its own conceptsand techniques.
Connecting our IPv6 Network to the Internet
21
Figure 1.18. IPv6 Connectivity
Getting back to the network connectivity domain, our objective is to connect IoT devices tothe Internet using IPv6, allowing communication with other IoT devices, collecting servers oreven with people.
Related with the IPv6 connectivity to Internet is an important idea: communication betweenIoT devices and the IPv6 Internet could be bidirectional. This is important to remarkbecause with IPv4, connectivity is oftentimes designed as a one direction channel between aclient and a server. This changes with IPv6.
Having a bidirectional communication with the IoT devices allows useful possibilities, becauseits not just that the device can send information to somewhere in the Internet, but that anybodyin the Internet could be able to send information, requests or commands to the IoT device.This can be used in different scenarios:
• Management: To manage the IoT device performing some status tests, updating someparameters/configuration/firmware remotely allowing for a better and efficient use of thehardware platform and improving the infrastructure security.
• Control: Send commands or control actuators to make the IoT device perform an action.
• Communication: Send information to the IoT device, that can be displayed using somekind of interface.
IIPv6 is still being deployed all over the different networks that compose the Internet, whichmeans that different scenarios can be found when deciding how to connect our network to
Connecting our IPv6 Network to the Internet
22
the IPv6 Internet. Following are the three most common scenarios, in preferred order, beingNative IPv6 connectivity the best choice.
• Native IPv6 Connectivity: This scenario applies when both the ISP providing connectivityto the Internet and the router(s) and networks devices used in our network support ofIPv6. Native IPv6 means that the IPv6 packets will flow without being changed or tunnelledanywhere in its path from origin to destination. It is common to find what is called dual-stack networks, where both native IPv6 and native IPv4 are being used at the same timein the same interfaces and devices. This native IPv6 scenario covers both cases: IPv6-only and dual-stack.
Figure 1.19. Native IPv6
As seen in the figure, our IoT devices cloud is connected to a router (R2) that provides thema prefix creating a LAN (LAN2). The router that provides connectivity to the IPv6 Internet (R1)will also be in charge of autoconfiguring IPv6 devices in LAN1 (including R2), by sending RAs(Router Advertisements) as detailed when SLAAC was explained.
• No IPv6 connectivity: In this scenario we face a common problem nowadays, the lack ofIPv6 connectivity from an ISP. Although we have IPv6 support on the router that connectsour network to Internet, the ISP supports only IPv4. The solution is to use one of the socalled IPv6 Transition Mechanism. The most simple and useful in this case would be the6in4 tunnel, based on creating a point-to-point static tunnel that encapsulates IPv6 packetsinto IPv4.
Connecting our IPv6 Network to the Internet
23
Figure 1.20. IPv4 tunneled IPv6
The figure shows this solution created by making a tunnel from R1 to a "remote tunnel endpoint" where the IPv4 meets the IPv6 Internet. This will be a router having connectivity to boththe IPv4 and IPv6 Internet. The native IPv6 traffic from our networks (LAN1 and LAN2) willreach R1, which will take the whole IPv6 packet with its data, and put it inside a new IPv4packet with the IPv4 destination address corresponding to the tunnel end router. The tunnelend router will grab the IPv6 packet and convey it as native IPv6 traffic into the IPv6 Internet.Similar encapsulation is applied with the IPv6 traffic sent over Ipv4 from the IPv6 Internet toour networks
• No IPv6 connectivity and no IPv6 capable router: This scenario covers the case wherethere is no IPv6 connectivity from the ISP, nor IPv6 support on the router connecting ournetwork to the Internet. As seen before, to solve the lack of IPv6 connectivity from the ISPwe can use a 6in4 tunnel, but in this scenario we also have to face the lack of IPv6 supporton the router which prevents the creation of the tunnel. The solution is to add a new routerthat supports both IPv6 and IPv4, and create a 6in4 tunnel from this router to a tunnel endrouter somewhere on the IPv4 Internet.
Connecting our IPv6 Network to the Internet
24
Figure 1.21. Local router does not support IPv6
In this scenario a new router (R3) is added to create a 6in4 tunnel towards the tunnel endrouter, which also serves as an IPv6 gateway to our networks, sending RAs to autoconfigureIPv6 devices in LAN1. The encapsulation/decapsulation process will work exactly the sameas in the previous scenario. The main difference here is that the 6in4 tunnel needs a publicIPv4 address, so R3 will need to have a public IPv4 besides the IPv6 address. This is easyto get in routers connected to ISPs, but not so common inside our network where we mighthave only private addresses using NAT.
The scenarios showed above are based on a good infrastructure, where we have at least tworouters and a couple of LANs. All three scenarios could be simplified into a just one routerscenario shown in the following figure:
Connecting our IPv6 Network to the Internet
25
Figure 1.22. Simplified Scenario
Considerations about lack of IPv6 connectivity from the ISP and IPv6 support on the routerare the same as in the previous case, although for the latter the solution is to change the R1router by one that supports also IPv6.
The last case is common because IoT or WSN could be deployed anywhere, including inremote networks connected using some sort of wireless technology. In this scenario there aresevere restrictions on the number of devices, power consumption, etc. For example, a cloudof sensors could be deployed in the country to sense temperature and moisture, all of themgetting connectivity through just one router connected using an IPv6 mobile phone network(GPRS, 3G or LTE).
26
27
Chapter 2. Introduction to 6LoWPANOne of the drivers of the IoT, where anything can be connected, is the use of wirelesstechnologies to create a communication channel to send and receive information. This wideadoption of wireless technologies allows increasing the number of connected devices butresults in limitations in terms of cost, battery life, power consumption, and communicationdistance for the devices. New technologies and protocols should tackle a new environment,usually called Low power and Lossy networks (LLNs), with the following characteristics:
1. Significantly more devices than those on current local area networks.
2. Severely limited code and ram space in devices.
3. Networks with limited communications distance (range), power and processing resources.
4. All elements should work together to optimize energy consumption and bandwidth usage.
Another factor that is being widely adopted within IoT is the use of IP as the network protocol.The use of IP provides several advantages, because it is an open standard that is widelyavailable, allowing for easy and cheap adoption, good interoperability and easy applicationlayer development. The use of a common standard like an end-to-end IP-based solution avoidsthe problem of non-interoperable networks.
For wireless communication technology, the IEEE 802.15.4 standard [IEEE802.15.4] is verypromising for the lower (link and physical) layers, although others are also being consideredas good options like Low Power WiFi, Bluetooth ® Low Energy, DECT Ultra Low Energy, ITU-T G.9959 networks, and NFC (Near Field Communication).
One component of the IoT that has received significant support from vendors andstandardization organizations is that of WSN (Wireless Sensor Networks).
The IETF has different working groups (WGs) developing standards to be used by WSN:
1. 6lowpan: IPv6 over Low-power Wireless Personal Area Networks [sixlowpan], definesthe standards for IPv6 communication over the IEEE 802.15.4 wireless communicationtechnology. 6lowpan acts as an adaptation layer between the standard IPv6 world and thelow power and lossy wireless communications medium offered by IEEE 802.15.4. Notethat this standard is only defined with IPv6 in mind, no IPv4 support is available.
2. roll: Routing Over Low power and Lossy networks [roll]. LLNs have specific routingrequirements that could not be satisfied with existing routing protocols. This WG focuses onrouting solutions for a subset of all possible application areas of LLNs (industrial, connected
Overview of LoWPANs
28
home, building and urban sensor networks), and protocols are designed to satisfy theirapplication-specific routing requirements. Here again the WG focuses only on the IPv6routing architectural framework.
3. 6lo: IPv6 over Networks of Resource-constrained Nodes [sixlo]. This WG deals with IPv6connectivity over constrained node networks. It extends the work of the 6lowpan WG,defining IPv6-over-foo adaptation layer specifications using 6LoWPAN for link layer inconstrained node networks.
As seen, 6LoWPAN is the basis of the work carried out in standardization at IETF tocommunicate constrained resources nodes in LLNs using IPv6. The work on 6LoWPAN hasbeen completed and is being further complemented by the roll WG to satisfy routing needsand the 6lo WG to extend the 6lowpan standards to any other link layer technology. Followingare more details about 6LoWPAN, as the first step into the IPv6 based WSN/IoT. 6LoWPANand related standards are concerned about providing IP connectivity to devices, irrelevantlyof the upper layers, except for the UDP transport layer protocol that is specifically considered.
2.1. Overview of LoWPANs
Low-power and lossy networks (LLNs) is the term commonly used to refer to networks made ofhighly constrained nodes (limited CPU, memory, power) interconnected by a variety of "lossy"links (low-power radio links). They are characterized by low speed, low performance, low cost,and unstable connectivity.
A LoWPAN is a particular instance of an LLN, formed by devices complying with the IEEE802.15.4 standard.
The typical characteristics of devices in a LoWPAN are:
1. Limited Processing Capability: Different types and clock speeds processors, starting at8-bits.
2. Small Memory Capacity: From few kilobytes of RAM with a few dozen kilobytes of ROM/flash memory, it’s expected to grow in the future, but always trying to keep at the minimumnecessary.
3. Low Power: In the order of tens of milliamperes.
4. Short Range: The Personal Operating Space (POS) defined by IEEE 802.15.4 impliesa range of 10 meters. For real implementations it can reach over 100 meters in line-of-sight situations.
5. Low Cost: This drives some of the other characteristics such as low processing, lowmemory, etc.
About the use of IP on LoWPANs
29
All this constraints on the nodes are expected to change as technology evolves, but comparedto other fields it’s expected that the LoWPANs will always try to use very restricted devices toallow for low prices and long life which implies hard restrictions in all other features.
A LoWPAN typically includes devices that work together to connect the physical environmentto real-world applications, e.g., wireless sensors, although a LoWPAN is not necessarilycomprised of sensor nodes only, since it may also contain actuators.
It’s also important to identify the characteristics of LoWPANs, because they will be theconstraints guiding all the technical work:
1. Small packet size: Given that the maximum physical layer frame is 127 bytes, the resultingmaximum frame size at the media access control layer is 102 octets. Link-layer securityimposes further overhead, which leaves a maximum of 81 octets for data packets.
2. IEEE 802.15.4 defines several addressing modes: It allows the use of either IEEE 64-bit extended addresses or (after an association event) 16-bit addresses unique within thePAN (Personal Area Network).
3. Low bandwidth: Data rates of 250 kbps, 40 kbps, and 20 kbps for each of the currentlydefined physical layers (2.4GHz, 915MHz, and 868MHz, respectively).
4. Topologies include star and mesh.
5. Large number of devices expected to be deployed during the lifetime of the technology.Location of the devices is typically not predefined, as they tend to be deployed in an ad-hoc fashion. Sometimes the location of these devices may not be easily accessible or theymay move to new locations.
6. Devices within LoWPANs tend to be unreliable due to variety of reasons: uncertain radioconnectivity, battery drain, device lockups, physical tampering, etc.
7. Sleeping mode: Devices may sleep for long periods of time in order to conserve energy,and are unable to communicate during these sleep periods.
2.2. About the use of IP on LoWPANs
As said before, it seems that the use of IP, and specifically IPv6, is being widely adoptedbecause it offers several advantages. 6LoWPANs are IPv6-based LoWPAN networks.
In this section we will see these advantages as well as some problems raised by the use ofIP over LoWPANs.
The application of IP technology and, in particular, IPv6 networking is assumed to provide thefollowing benefits to LoWPANs:
About the use of IP on LoWPANs
30
a. The pervasive nature of IP networks allows leveraging existing infrastructure.
b. IP-based technologies already exist, are well-known, proven to be working and widelyavailable. This allows for an easier and cheaper adoption, good interoperability and easierapplication layer development.
c. IP networking technology is specified in open and freely available specifications, which isable to be better understood by a wider audience than proprietary solutions.
d. Tools for IP networks already exist.
e. IP-based devices can be connected readily to other IP-based networks, without the needfor intermediate entities like protocol translation gateways or proxies.
f. The use of IPv6, specifically, allows for a huge amount of addresses and provides for easynetwork parameters autoconfiguration (SLAAC). This is paramount for 6LoWPANs wherelarge number of devices should be supported.
On the counter side using IP communication in LoWPANs raise some issues that should betaken into account:
a. IP Connectivity: One of the characteristics of 6LoWPANs is the limited packet size, whichimplies that headers for IPv6 and layers above must be compressed whenever possible.
b. Topologies: LoWPANs must support various topologies including mesh and star: Meshtopologies imply multi-hop routing to a desired destination. In this case, intermediatedevices act as packet forwarders at the link layer. Star topologies include provisioninga subset of devices with packet forwarding functionality. If, in addition to IEEE 802.15.4,these devices use other kinds of network interfaces such as Ethernet or IEEE 802.11, thegoal is to seamlessly integrate the networks built over those different technologies. This,of course, is a primary motivation to use IP to begin with.
c. Limited Packet Size: Applications within LoWPANs are expected to originate smallpackets. Adding all layers for IP connectivity should still allow transmission in one frame,without incurring excessive fragmentation and reassembly. Furthermore, protocols mustbe designed or chosen so that the individual "control/protocol packets" fit within a single802.15.4 frame.
d. Limited Configuration and Management: Devices within LoWPANs are expected to bedeployed in exceedingly large numbers. Additionally, they are expected to have limiteddisplay and input capabilities. Furthermore, the location of some of these devicesmay be hard to reach. Accordingly, protocols used in LoWPANs should have minimalconfiguration, preferably work "out of the box", be easy to bootstrap, and enable thenetwork to self heal given the inherent unreliable characteristic of these devices.
6LoWPAN
31
e. Service Discovery: LoWPANs require simple service discovery network protocols todiscover, control and maintain services provided by devices.
f. Security: IEEE 802.15.4 mandates link-layer security based on AES, but it omits any detailsabout topics like bootstrapping, key management, and security at higher layers. Of course,a complete security solution for LoWPAN devices must consider application needs verycarefully.
2.3. 6LoWPAN
We have seen that there is a lower layer (physical and link layers on TCP/IP stack model) thatprovide connectivity to devices in what is called a LoWPAN. Also that using IPv6 over this layerwould bring several benefits. The main reason for developing the IETF standards mentionedin the introduction is that between the IP (network layer) and the lower layer there are someimportant issues that need to be solved by means of an adaptation layer, the 6lowpan.
Figure 2.1. 6LoWPAN in the protocol stack
6LoWPAN
32
The main goals of 6lowpan are:
1. Fragmentation and Reassembly layer: IPv6 specification [RFC2460] establishes that theminimum MTU that a link layer should offer to the IPv6 layer is 1280 bytes. The protocoldata units may be as small as 81 bytes in IEEE 802.15.4. To solve this difference afragmentation and reassembly adaptation layer must be provided at the layer below IP.
2. Header Compression: Given that in the worst case the maximum size available fortransmitting IP packets over an IEEE 802.15.4 frame is 81 octets, and that the IPv6 headeris 40 octets long, (without optional extension headers), this leaves only 41 octets for upper-layer protocols, like UDP and TCP. UDP uses 8 octets in the header and TCP uses20 octets. This leaves 33 octets for data over UDP and 21 octets for data over TCP.Additionally, as pointed above, there is also a need for a fragmentation and reassemblylayer, which will use even more octets leaving very few octets for data. Thus, if onewere to use the protocols as is, it would lead to excessive fragmentation and reassembly,even when data packets are just 10s of octets long. This points to the need for headercompression.
3. Address Autoconfiguration: specifies methods for creating IPv6 stateless address autoconfiguration (in contrast to stateful) that is attractive for 6LoWPANs, because it reducesthe configuration overhead on the hosts. There is a need for a method to generate theIPv6 IID (Interface Identifier) from the EUI-64 assigned to the IEEE 802.15.4 device.
4. Mesh Routing Protocol: A routing protocol to support a multi-hop mesh network isnecessary. Care should be taken when using existing routing protocols (or designing newones) so that the routing packets fit within a single IEEE 802.15.4 frame. The mechanismsdefined by 6lowpan IETF WG are based on some requirements for the IEEE 802.15.4layer:
5. IEEE 802.15.4 defines four types of frames: beacon frames, MAC command frames,acknowledgement frames and data frames. IPv6 packets must be carried on data frames.
6. Data frames may optionally request that they be acknowledged. It is recommended thatIPv6 packets be carried in frames for which acknowledgements are requested so as toaid link-layer recovery.
7. The specification allows for frames in which either the source or destination addresses (orboth) are elided. Both source and destination addresses are required to be included in theIEEE 802.15.4 frame header.
8. The source or destination PAN ID fields may also be included. 6LoWPAN standardassumes that a PAN maps to a specific IPv6 link.
IPv6 Interface Identifier (IID)
33
9. Both 64-bit extended addresses and 16-bit short addresses are supported, althoughadditional constraints are imposed on the format of the 16-bit short addresses.
10.Multicast is not supported natively in IEEE 802.15.4. Hence, IPv6 level multicast packetsmust be carried as link-layer broadcast frames in IEEE 802.15.4 networks. This must bedone such that the broadcast frames are only heeded by devices within the specific PANof the link in question.
The 6LoWPAN adaptation format was specified to carry IPv6 datagrams over constrainedlinks, taking into account limited bandwidth, memory, or energy resources that are expectedin applications such as wireless sensor networks. For each of these goals and requirementsthere is a solution provided by the 6lowpan specification:
1. A Mesh Addressing header to support sub-IP forwarding.
2. A Fragmentation header to support the IPv6 minimum MTU requirement.
3. A Broadcast Header to be used when IPv6 multicast packets must be sent over the IEEE802.15.4 network.
4. Stateless header compression for IPv6 datagrams to reduce the relatively large IPv6 andUDP headers down to (in the best case) several bytes. These header are used as theLoWPAN encapsulation, and could be used at the same time forming what is called theheader stack. Each header in the header stack contains a header type followed by zeroor more header fields. When more than one LoWPAN header is used in the same packet,they must appear in the following order: Mesh Addressing Header, Broadcast Header, andFragmentation Header.
Figure 2.2. 6LoWPAN headers
2.4. IPv6 Interface Identifier (IID)
As already said an IEEE 802.15.4 device could have two types of addresses. For each onethere is a different way of generating the IPv6 IID.
1. IEEE EUI-64 address: All devices have this one. In this case, the Interface Identifier isformed from the EUI-64, complementing the "Universal/Local" (U/L) bit, which is the next-
Header Compression
34
to-lowest order bit of the first octet of the EUI-64. Complementing this bit will generallychange a 0 value to a 1.
Figure 2.3. EUI-64 derived IID
1. 16-bit short addresses: Possible but not always used. The IPv6 IID is formed using thePAN (or zeroes in case of not knowing the PAN) and the 16 bit short address as in thefigure below.
Figure 2.4. IPv6IID
2.5. Header Compression
Two encoding formats are defined for compression of IPv6 packets: LOWPAN_IPHC andLOWPAN_NHC, an encoding format for arbitrary next headers.
Header Compression
35
To enable effective compression, LOWPAN_IPHC relies on information pertaining to the entire6LoWPAN. LOWPAN_IPHC assumes the following will be the common case for 6LoWPANcommunication:
1. Version is 6.
2. Traffic Class and Flow Label are both zero.
3. Payload Length can be inferred from lower layers from either the 6LoWPAN Fragmentationheader or the IEEE 802.15.4 header.
4. Hop Limit will be set to a well-known value by the source.
5. Addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or asmall set of routable prefixes assigned to the entire 6LoWPAN.
6. Addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly fromeither the 64-bit extended or the 16-bit short IEEE 802.15.4 addresses. Depending on howclosely the packet matches this common case, different fields may not be compressiblethus needing to be carried "in-line" as well. The base format used in LOWPAN_IPHCencoding is shown in the figure below.
Figure 2.5. Header compression
Where:
• TF: Traffic Class, Flow Label.
• NH: Next Header.
• HLIM: Hop Limit.
• CID: Context Identifier Extension.
• SAC: Source Address Compression.
• SAM: Source Address Mode.
• M: Multicast Compression.
Header Compression
36
• DAC: Destination Address Compression.
• DAM: Destination Address Mode.
Not going into details, it’s important to understand how 6LoWPAN compression works. To thisend, let’s see two examples:
1. HLIM (Hop Limit): Is a two bits field that can have four values, three of them make the hoplimit field to be compressed from 8 to 2 bits:
a. 00: Hop Limit field carried in-line. There is no compression and the whole field is carriedin-line after the LOWPAN_IPHC.
b. 01: Hop Limit field compressed and the hop limit is 1.
c. 10: Hop Limit field compressed and the hop limit is 64.
d. 11: Hop Limit field compressed and the hop limit is 255.
2. SAC/DAC used for the source IPv6 address compression. SAC indicates which addresscompression is used, stateless (SAC=0) or stateful context-based (SAC=1). Dependingon SAC, DAC is used in the following way:
a. If SAC=0, then SAM:
• 00: 128 bits. Full address is carried in-line. No compression.
• 01: 64 bits. First 64-bits of the address are elided, the link-local prefix. The remaining64 bits are carried in-line.
• 10: 16 bits. First 112 bits of the address are elided. First 64 bits is the link-localprefix. The following 64 bits are 0000:00ff:fe00:XXXX, where XXXX are the 16 bitscarried in-line.
• 11: 0 bits. Address is fully elided. First 64 bits of the address are the link-local prefix.The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4or IPv6 source address).
b. If SAC=1, then SAM:
• 00: 0 bits. The unspecified address (::).
• 01: 64 bits. The address is derived using context information and the 64 bits carriedin-line. Bits covered by context information are always used. Any IID bits not coveredby context information are taken directly from the corresponding bits carried in-line.
• 10: 16 bits. The address is derived using context information and the 16 bits carriedin-line. Bits covered by context information are always used. Any IID bits not coveredby context information are taken directly from their corresponding bits in the 16-bit
Header Compression
37
to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carriedin-line.
• 11: 0 bits. The address is fully elided and it is derived using context information andthe encapsulating header (e.g., 802.15.4 or IPv6 source address). Bits covered bycontext information are always used. Any IID bits not covered by context informationare computed from the encapsulating header.
The base format is two bytes (16 bits) long. If the CID (Context Identifier Extension) field hasa value of 1, it means that an additional 8-bit Context Identifier Extension field immediatelyfollows the Destination Address Mode (DAM) field. This would make the length be 24 bits orthree bytes.
This additional octet identifies the pair of contexts to be used when the IPv6 source and/ordestination address is compressed. The context identifier is 4 bits for each address, supportingup to 16 contexts. Context 0 is the default context. The two fields on the Context IdentifierExtension are:
• SCI: Source Context Identifier. Identifies the prefix that is used when the IPv6 sourceaddress is statefully compressed.
• DCI: Destination Context Identifier. Identifies the prefix that is used when the IPv6destination address is statefully compressed.
The Next Header field in the IPv6 header is treated in two different ways, depending on thevalues indicated in the NH (Next Header) field of the LOWPAN_IPHC enconding shown above.
If NH = 0, then this field is not compressed and all the 8 bits are carried in-line after theLOWPAN_IPHC.
If NH = 1, then the Next Header field is compressed and the next header is encoded usingLOWPAN_NHC encoding. This results in the structure shown in the figure below.
Figure 2.6. LoWPAN header
For IPv6 Extension headers the LOWPAN_NHC has the format shown in the figure, where:
• EID: IPv6 Extension Header ID:
NDP optimization
38
◦ 0: IPv6 Hop-by-Hop Options Header.
◦ 1: IPv6 Routing Header.
◦ 2: IPv6 Fragment Header.
◦ 3: IPv6 Destination Options Header.
◦ 4: IPv6 Mobility Header.
◦ 5: Reserved.
◦ 6: Reserved.
◦ 7: IPv6 Header.
• NH: Next Header
◦ 0: Full 8 bits for Next Header are carried in-line.
◦ 1: Next Header field is elided and is encoded using LOWPAN_NHC. For the most part,the IPv6 Extension Header is carried unmodified in the bytes immediately following theLOWPAN_NHC octet.
2.6. NDP optimization
IEEE 802.15.4 and other similar link technologies have limited or no usage of multicastsignalling due to energy conservation. In addition, the wireless network may not strictly followthe traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designedfor non-transitive wireless links, since its reliance on the traditional IPv6 link concept and itsheavy use of multicast make it inefficient and sometimes impractical in a low-power and lossynetwork.
For this reasons, some simple optimizations have been defined for IPv6 Neighbor Discovery,its addressing mechanisms and duplicate address detection for LoWPANs [RFC6775]:
1. Host-initiated interactions to allow for sleeping hosts.
2. Elimination of multicast-based address resolution for hosts.
3. A host address registration feature using a new option in unicast Neighbor Solicitation (NS)and Neighbor Advertisement (NA) messages.
4. A new Neighbor Discovery option to distribute 6LoWPAN header compression context tohosts.
5. Multihop distribution of prefix and 6LoWPAN header compression context.
NDP optimization
39
6. Multihop Duplicate Address Detection (DAD), which uses two new ICMPv6 messagetypes.
The two multihop items can be substituted by a routing protocol mechanism if that is desired.
Three new ICMPv6 message options are defined:
1. The Address Registration Option (ARO).
2. The Authoritative Border Router Option (ABRO).
3. The 6LoWPAN Context Option (6CO)
Also two new ICMPv6 message types are defined:
1. The Duplicate Address Request (DAR).
2. The Duplicate Address Confirmation (DAC)
40
41
Chapter 3. Introduction to ContikiContiki is an open source operating system for the Internet of Things, it connects tiny low-cost,low-power microcontrollers to the Internet.
Contiki provides powerful low-consumption Internet communication, it supports fully standardIPv6 and IPv4, along with the recent low-power wireless standards: 6lowpan, RPL, CoAP.With Contiki’s ContikiMAC and sleepy routers, even wireless routers can be battery-operated.
With Contiki, development is easy and fast: Contiki applications are written in standard C,with the Cooja simulator Contiki networks can be emulated before burned into hardware, andInstant Contiki provides an entire development environment in a single download.
Visit the Contiki OS site1 for more information.
The remainder of the chapter intends to be a thoughtful introduction to Contiki 3.0, its corecomponents and features. The following references are the must-go places to search fordetailed information:
• The Contiki wiki page2
• The Contiki mailing list3
• Zolertia Wiki page4
3.1. Install ContikiThere are several ways to install Contiki, from scratch by installing from sources or using virtualenvironments, depending on the flavour and time availability.
To work with Contiki you will need three items:
• The Contiki source code.
• A target platform (virtual platform or a real hardware one).
• A toolchain to compile the source code for such target platform.
The remainder of the book assumes Contiki will run in an Unix environment, as the virtualizedenvironments run on Ubuntu.
1 http://contiki-os.org2 https://github.com/contiki-os/contiki/wiki3 http://sourceforge.net/p/contiki/mailman/contiki-developers4 https://github.com/Zolertia/Resources/wiki
Install from sources
42
3.1.1. Install from sources
Contiki source code is actively supported by contributors from universities, research centersand developers from all over the world.
The source code is hosted at Contiki GitHub repository5 :
To grab the source code open a terminal and execute the following:
sudo apt-get -y install git
git clone --recursive https://github.com/contiki-os/contiki.git
What is git?
Git is a free and open source distributed version control system, designed for speedand efficiency.
The main difference with other change control tools is the possibility to work locallysince your local copy is a repository, and you can commit to it and get all benefits ofsource control.
There are some great tutorials online to learn more about git:
• Code School & GitHub "try Git"6
• Roger Dudler’s Git simple guide7
GitHub is a GIT repository web-based hosting service, which offers all of thedistributed revision control and source code management (SCM) functionality of Gitas well as adding its own features. GitHub provides a web-based graphical interfaceand desktop as well as mobile integration. It also provides access control and severalcollaboration features such as wikis, task management, bug tracking and featurerequests for every project.
The advantage of using GIT and hosting the code at github is that of allowing people tofork the code, further develop it, and then contribute back to share their improvements.
5 https://github.com/contiki-os/contiki6 http://try.github.io7 http://rogerdudler.github.io/git-guide/
Instant Contiki Virtual Machine
43
To install the toolchain and required dependencies, run in a terminal the following:
sudo echo "deb http://ppa.launchpad.net/terry.guo/gcc-arm-embedded/ubuntu trusty
main" > /etc/apt/sources.list.d/gcc-arm-embedded.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key
FE324A81C208C89497EFC6246D1D8367A3421AFB
sudo apt-get update
sudo apt-get -y install build-essential automake gettext
sudo apt-get -y install gcc-arm-none-eabi curl graphviz unzip wget
sudo apt-get -y install gcc gcc-msp430
sudo apt-get -y install openjdk-7-jdk openjdk-7-jre ant
This will install support for the ARM Cortex-M3 and MSP430 platforms, as well as support forCooja, the Contiki’s emulator to be discussed in the next sections.
3.1.2. Instant Contiki Virtual Machine
Instant Contiki is an entire Contiki development environment in a single download. It is anUbuntu Linux virtual machine and has Contiki OS and all the development tools, compilers,and simulators required already pre-installed.
Grab Instant Contiki from the Contiki website:
http://www.contiki-os.org/start.html
The latest Instant Contiki release is 3.0, following the Contiki 3.0 source code release.
This book is heavily based on this release, the use of earlier versions is not recommended.
The release tag is available at:
https://github.com/contiki-os/contiki/tree/release-3-0
Nevertheless you should use the latest commit available, as Contiki releases are producedon a yearly base. Many bug fixes, new features and improved support is normally present onthe latest master branch.
At the moment of this release, the current Contiki commit correspondsto the daa83ee3ef32f5b48f647e1c614fe6523ab440bb HASH.You can use the following GIT command to place yourself on thiscommit:
git checkout
daa83ee3ef32f5b48f647e1c614fe6523ab440bb
Test Contiki installation
44
As Contiki ensures the platform and application support by using a strictcode revision procedure and regression tests, this is a safe point if youencounter any problem. Be sure to update your Contiki local repositoryif using Instant Contiki !
Download VMWare player for Windowws and Linux8 to run Contiki’s virtual machine, it is freeand widely used.
In OSX you can download VMWare Fusion9
Using VMWare just open the Instant_Contiki_Ubuntu_12.04_32-bit.vmx file, ifprompted about the VM source just choose I copied it then wait for the virtual UbuntuLinux boot up.
Log into Instant Contiki. The password and user name is user . Don’t upgrade right now.
Remember to update the Contiki repository and get the latest upgrades:
cd /home/user/contiki
git fetch origin
git pull origin master
3.2. Test Contiki installation
Let us first check the toolchain installation. The MSP430 toolchain can be tested with:
msp430-gcc --version
msp430-gcc (GCC) 4.7.0 20120322 (mspgcc dev 20120716)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And for the ARM Cortex-M3 toolchain:
arm-gcc-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release)
[ARM/embedded-4_9-branch revision 224288]
8 https://my.vmware.com/web/vmware/free#desktop_end_user_computing/vmware_player/6_09 http://www.vmware.com/products/fusion
Contiki structure
45
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
3.3. Contiki structure
Contiki has the following file structure:
Folder Description Zolertia files
examples Ready to build examples examples/zolertia,examples/cc2538-common
app Contiki applications -
cpu Specific MCU files msp430, cc2538
dev External chip and devices cc2420, cc1200
platform Specific files and platformdrivers
z1, zoul
core Contiki core files andlibraries
-
tools Tools for flashing, debuging,simulating, etc.
zolertia, sky
doc Self-generated doxygendocumentation
-
regression-tests nightly regression tests -
In the following sections we will cover the examples and specific platform files for the Zolertiaplatforms.
3.4. Run Contiki on real hardware
For the remainder of the book we will use Zolertia Z1 and RE-Mote hardware developmentplatforms. Other platforms can be used as well, but are out of the scope of this book.
Contiki drivers and libraries are (normally) platform independent, most examples can be runin both Z1 and RE-Mote platforms by taking into consideration specific platform settings.
There are platform-specific examples for the Z1 platform at examples/zolertia/z1 , andat examples/zolertia/zoul for the RE-Mote. Additionaly CC2538 specific examples
Zolertia Zoul module and theRE-Mote development platform
46
can be found at examples/cc2538-common . This folder has CC2538 ARM Cortex-M3related examples and applications.
More information about both platforms and updates guides can be found at:
• Zolertia website10
• Zolertia RE-Mote wiki page11
• Zolertia Z1 wiki page12
3.4.1. Zolertia Zoul module and the RE-Mote developmentplatform
The Zoul is a module based in the CC2538 ARM Cortex-M3 system on chip (SoC), withan on-board 2.4 GHz IEEE 802.15.4 RF interface, running at up to 32 MHz with 512 kB ofprogrammable flash and 32 kB of RAM, bundled with a CC1200 868/915 MHz RF transceiverto allow dual band operation.
The Zoul allows fast reusability on designs and quick scaling from prototyping to production.
Figure 3.1. Zolertia Zoul module and the RE-Mote platform
The RE-Mote has a Zoul on board and also packs:
• ISM 2.4-GHz IEEE 802.15.4 & Zigbee compliant radio.
• ISM 863-950-MHz ISM/SRD band radio.
10 http://www.zolertia11 https://github.com/Zolertia/Resources/wiki/RE-Mote12 https://github.com/Zolertia/Resources/wiki#the-z1-mote
Zolertia Z1 mote
47
• AES-128/256, SHA2 Hardware Encryption Engine.
• ECC-128/256, RSA Hardware Acceleration Engine for Secure Key Exchange.
• Consumption down to 150 nA using the shutdown mode.
• Programming over BSL without requiring to press any button to enter bootloader mode.
• Built-in battery charger (500 mA), facilitating Energy Harvesting and direct connection toSolar Panels and to standards LiPo batteries.
• Wide range DC Power input: 2-16 V.
• Small form-factor.
• MicroSD over SPI.
• On board RTC (programmable real time clock) and external watchdog timer (WDT).
• Programmable RF switch to connect an external antenna either to the 2.4 GHz or to theSub 1 GHz RF interface through the RP-SMA connector.
The RE-Mote has been developed jointly with universities and industrial partners in the frameof the European research project RERUM(RERUM: REliable, Resilient and secUre IoT forsMart city applications).
3.4.2. Zolertia Z1 mote
The Z1 mote features a second generation MSP430F2617 low power 16-bit RISC CPU @16 MHz MCU, 8 kB RAM and a 92 kB Flash memory. It includes the well known CC2420transceiver, IEEE 802.15.4 compliant, which operates at 2.4 GHz with an effective data rateof 250 kbps.
Figure 3.2. Zolertia Z1 mote
What are the differences betweenthe RE-Mote and the Z1 platforms?
48
The Zolertia Z1 mote can run TinyOS, Contiki OS, OpenWSN and RIOT, and has been usedactively for over 5 years in universities, research and development centers and in commercialproducts in more than 43 countries, being featured in more than 50 scientific publications.
The Z1 mote is fully emulated in both MSPSIM and Cooja.
3.4.3. What are the differences between the RE-Mote and the Z1platforms?
In a nutshell: power and coolness.
The RE-Mote has 4 times more RAM than the Z1 mote, 5 times more flash memory, twicethe frequency of operation and 120 times less power consumption in its lowest power mode(shutdown mode).
Another major difference is that (at the time of writing this book) the Z1 mote is supported byCooja, the Contiki emulator, while the RE-Mote is not. However efforts are on going to provideemulation framework support in the EMUL813 project.
To check in depth the differences between the RE-Mote and the Z1 mote, and also obtainguidelines to port applications developed for the Z1 to the RE-Mote, visit the "Migrate fromZ1 to RE-Mote" wiki page14 .
3.5. Start with Contiki!Let’s compile our first Contiki example! Open a terminal and write:
cd examples/hello-world
make TARGET=zoul savetarget
This will tell Contiki to compile the hello world example for the RE-Mote platform from now on.Alternatively, to use the Z1 mote instead, just run:
make TARGET=z1 savetarget
You need to do this only once per application. Not let’s compile the application:
make hello-world
13 http://emul8.org/14 https://github.com/Zolertia/Resources/wiki/Migrate-From-Z1-to-RE-Mote
Hello world explained
49
To start compiling the code (ignore the warnings), if everything works OK you should seesomething like:
CC symbols.c
AR contiki-z1.a
CC hello-world.c
CC ../../platform/z1/./contiki-z1-main.c
LD hello-world.z1
rm obj_z1/contiki-z1-main.o hello-world.co
The hello-world.z1 file should have been created and we are ready to flash theapplication to the device.
At any given point you can override the saved target and redefine at compilation time byrunning instead:
make TARGET=zoul hello-world
CC hello-world.c
LD hello-world.elf
arm-none-eabi-objcopy -O binary --gap-fill 0xff hello-world.elf hello-world.bin
This will ignore the saved Makefile.target file and use the target zoul instead.
In the following sections and chapters the examples can be compiled for both the Z1 and RE-Mote platform, unless specified otherwise.
The RE-Mote takes two arguments: TARGET and BOARD , while theZ1 mote only uses the first one with the z1 string as noted before.For the RE-Mote, TARGET is always zoul and BOARD is remote ,but when compiling, if the BOARD flag is not explicitly defined, it willdefault to remote . This approach is because there are other Zoulbased platforms which share the same code base and modules, but theRE-Mote has its own specific platform files and definitions.
3.5.1. Hello world explained
Let’s see the main components of the Hello World example. Browse the code with:
gedit hello-world.c
Or your preferred text editor.
Makefile explained
50
When starting Contiki, you declare processes with a name. In each code you can have severalprocesses. You declare the process like this:
PROCESS(hello_world_process, "Hello world process");
AUTOSTART_PROCESSES(&hello_world_process);
hello_world_process is the name of the process and "Hello world process"is the readable name of the process when you print it to the terminal.The AUTOSTART_PROCESSES(&hello_world_process) tells Contiki to start thatprocess when it finishes booting.
/*-------------------------------------------------*/
PROCESS(hello_world_process, "Hello world process");
AUTOSTART_PROCESSES(&hello_world_process);
/*-------------------------------------------------*/
PROCESS_THREAD(hello_world_process, ev, data)
{
PROCESS_BEGIN();
printf("Hello, world\n");
PROCESS_END();
}
You declare the content of the process in the process thread. You have the name of theprocess and callback functions (event handler and data handler).Inside the thread you begin the process,
do what you want and
finally end the process.
3.5.2. Makefile explained
Applications require a Makefile to compile, let us take a look at the hello-world Makefile:
CONTIKI_PROJECT = hello-world
all: $(CONTIKI_PROJECT)
CONTIKI = ../..
include $(CONTIKI)/Makefile.include
Tells the build system which application to compile
If using make all it will compile the defined applications
Adding an LED to the example
51
Specify our indentation level respect to Contiki root folder
The system-wide Contiki Makefile, also points out to the platform’s Makefile
We can define specific compilation flags in the Makefile, although the recommended waywould be to add a project-conf.h header, and define there any compilation flag or value.This is done by adding this to the Makefile:
DEFINES+=PROJECT_CONF_H=\"project-conf.h\"
And then creating a project-conf.h header file in the example location.
Before you embark in Contiki, it is useful to remember that normally thedrivers have a switch like:
#define DEBUG 0
#if DEBUG
#define PRINTF(...) printf(__VA_ARGS__)
#else
#define PRINTF(...)
#endif
Enable the DEBUG by changing to 1 or DEBUG_PRINT , this will printdebug information to the console. Normally you should do it in everydriver file you wish to debug.
3.5.3. Adding an LED to the example
The next step is adding an LED (light emitting diode) to interact with our application.
You have to add the dev/leds.h which is the library to manage the LEDs. To check theavailable functions go to core/dev/leds.h .
Available LEDs commands:
unsigned char leds_get(void);
void leds_set(unsigned char leds);
void leds_on(unsigned char leds);
void leds_off(unsigned char leds);
void leds_toggle(unsigned char leds);
Normally all platforms comply to the following available LEDs:
Adding an LED to the example
52
LEDS_GREEN
LEDS_RED
LEDS_BLUE
LEDS_ALL
In the Z1 mote these LEDs are defined in platform/z1/platform-conf.h , as well asother hardware definitions.
The RE-Mote uses an RGB LED, basically 3-channel LEDs in a single device, allowing toshow any color by the proper combination of Blue, Red and Green. In platforms/zoul/remote/board.h header the following are defined:
LEDS_LIGHT_BLUE
LEDS_YELLOW
LEDS_PURPLE
LEDS_WHITE
Now try to turn on only the red LED and see what happens, create a new example namedtest-leds.c :
#include "contiki.h"
#include "dev/leds.h"
#include <stdio.h>
/*-------------------------------------------------*/
PROCESS(test_leds_process, "Test LEDs");
AUTOSTART_PROCESSES(&test_leds_process);
/*-------------------------------------------------*/
PROCESS_THREAD(test_leds_process, ev, data)
{
PROCESS_BEGIN();
leds_on(LEDS_RED);
PROCESS_END();
}
Now let’s compile and upload the new project with:
make clean && make test-leds.upload
The make clean command is used to erase previously compiled objects.
Now the red LED should be on!
Printing messages to the console
53
If you make changes to the source code, you must rebuild the files,otherwise your change might not be pulled in. It is always recommendedto do a make clean command before compiling.
Exercise: try to switch on the other LEDs.
3.5.4. Printing messages to the console
You can use printf to visualize on the console what is happening in your application. It is reallyuseful to debug your code, as you can print values of variables, when certain block of codeis being executed, etc.
Let’s try to print the status of the LED, using the unsigned char leds_get(void);function that is available in the documented functions (see above).
Get the LED status and print it on the screen, modify the current test-leds.c file as follows:
#include "contiki.h"
#include "dev/leds.h"
#include <stdio.h>
char hello[] = "hello from the mote!";
/*-------------------------------------------------*/
PROCESS(test_leds_process, "Test LEDs");
AUTOSTART_PROCESSES(&test_leds_process);
/*-------------------------------------------------*/
PROCESS_THREAD(test_leds_process, ev, data)
{
PROCESS_BEGIN();
leds_on(LEDS_RED);
printf("%s\n", hello);
printf("The LED %u is %u\n", LEDS_RED, leds_get());
PROCESS_END();
}
If one LED is on, you will get the LED number, which is defined by each platform in itsplatform-conf.h or board.h header.
Exercise: what happens when you turn on more than one LED? Whatnumber do you get? are these the same numbers for the Z1 and theRE-Mote?
Adding button events
54
3.5.5. Adding button events
We now want to detect if the user button has been pressed.
The button in Contiki is regarded as a sensor. We are going to use the core/dev/button-sensor.h library.
The RE-Mote platform has extra button functionalities, such as detectlong-press sequences, enabling to further expand the events thatcan be triggered using the button. Check platform/zoul/dev/button-sensor.c for more details, and examples/zolertia/zoul/zoul-demo.c for an example.
Create a new example called test-button.c and add the dev/button-sensor.hheader and button event as follows:
#include "contiki.h"
#include "dev/leds.h"
#include "dev/button-sensor.h"
#include <stdio.h>
/*-------------------------------------------------*/
PROCESS(test_button_process, "Test button");
AUTOSTART_PROCESSES(&test_button_process);
/*-------------------------------------------------*/
PROCESS_THREAD(test_button_process, ev, data)
{
PROCESS_BEGIN();
SENSORS_ACTIVATE(button_sensor);
while(1) {
PROCESS_WAIT_EVENT_UNTIL((ev==sensors_event) &&
(data == &button_sensor));
printf("I pushed the button!\n");
}
PROCESS_END();
}
This process has an infinite loop, given by the wait() , to wait for the button the be pressed.The two conditions have to be met (event from a sensor and that event is the button beingpressed), as soon as you press the button, you get the string printed.
Exercise: switch on the LED when the button is pressed. Switch off theLED when the button is pressed again.
Timers
55
3.5.6. Timers
Using timers will allow us to trigger events at a given time, speeding up the transition from onestate to another and automating a given process or task, for example blinking an LED every5 seconds, without the user having to press the button each time.
Contiki OS provides 4 kind of timers:
• Simple timer: A simple ticker, the application should check manually if the timer has expired.More information at core/sys/timer.h .
• Callback timer: When a timer expires it can callback a given function. More information atcore/sys/ctimer.h .
• Event timer: Same as above, but instead of calling a function, when the timer expires itposts an event signalling its expiration. More information at core/sys/etimer.h .
• Real time timer: The real-time module handles the scheduling and execution of real-timetasks, there’s only 1 timer available at the moment. More information at core/sys/rtimer.h
For our implementation we are going to choose the event timer, because we want to changethe application behavior when the timer expires every given period.
We create a timer structure and set the timer to expire after a given number of seconds. Whenthe timer expires we execute the code and restart the timer.
Create an example called test-timer.c as follows:
#include "contiki.h"
#include "dev/leds.h"
#include <stdio.h>
/*-------------------------------------------------*/
#define SECONDS 2
/*-------------------------------------------------*/
PROCESS(test_timer_process, "Test timer");
AUTOSTART_PROCESSES(&test_timer_process);
/*-------------------------------------------------*/
PROCESS_THREAD(test_timer_process, ev, data)
{
PROCESS_BEGIN();
static struct etimer et;
while(1) {
etimer_set(&et, CLOCK_SECOND*SECONDS);
PROCESS_WAIT_EVENT();
Sensors
56
if(etimer_expired(&et)) {
printf("Hello world!\n");
etimer_reset(&et);
}
}
PROCESS_END();
}
CLOCK_SECOND is a value related to the number of the microcontroller’s ticks persecond. As Contiki runs on different platforms with different hardware, the value ofCLOCK_SECOND also differs.PROCESS_WAIT_EVENT() waits for any event to happen.
Exercise: can you print the value of CLOCK_SECOND to count howmany ticks you have in one second? Try to blink the LED for a certainnumber of seconds. Make a new application that starts only when thebutton is pressed and stops when the button is pressed again.
3.5.7. Sensors
A sensor is a transducer whose purpose is to sense or detect a characteristic of itsenvironment, providing a corresponding output, generally as an electrical or optical signal,related to the quantity of the measured variable.
Sensors in Contiki are implemented as follow:
SENSORS_SENSOR (sensor, SENSOR_NAME, value, configure, status);
This means that a method to configure the sensor, poll the sensor status and request avalue have to be implemented. The sensor structure contains pointers to these functions.The arguments for each function are shown below.
struct sensors_sensor {
char * type;
int (* value) (int type);
int (* configure) (int type, int value);
int (* status) (int type);
};
To better understand please refer to the platform/zoul/dev/adc-sensors.c , for anexample of how analogue external sensors can be implemented (to be further discussed inthe next sections).
Sensors
57
The following functions and macros can be used to work with the sensor:
SENSORS_ACTIVATE(sensor)
SENSORS_DEACTIVATE(sensor)
sensor.value(type);
Enable the sensor, typically configures and turns the sensor on
Disables the sensor, it is useful to save power
Request a value to the sensor. As one sensor chip might have different types of readings(temperature, humidity, etc.), this is used to specify which measure to take.
Although this is the default way to implement sensors in Contiki, theremight be alternatives, depending on the sensor and developer. Alwayscheck the specific sensor driver implementation for details. Normallysensors are provided in the same location as the example, in the devfolder, or in the platform/zoul/dev directory for example.
The SENSORS macro provides external linkage to the sensors defined for the platform andapplication, allowing to iterate between the available sensors. The following are the sensorsdefined as default for the RE-Mote platform:
SENSORS (&button_sensor, &vdd3_sensor, &cc2538_temp_sensor, &adc_sensors);
The button is considered a sensor in Contiki, and it shares the samesensor implementation
This macro extends to:
const struct sensors_sensor *sensors[] = {
&button_sensor,
&vdd3_sensor,
&cc2538_temp_sensor,
&adc_sensors,
((void *)0)
};
The number of sensors can be found with the SENSORS_NUM macro:
#define SENSORS_NUM (sizeof(sensors) / sizeof(struct sensors_sensor *))
Sensors
58
Sensors can be of two types: analogue or digital. In the following sections examples will beshown for both types, detailing how to connect and use both the platform’s internal sensorsas well as the external ones.
Analogue Sensors
Analogue sensors typically require being connected to an ADC (analogue to digitalconverter) to translate the analogue (continuous) reading to an equivalent digital valuein millivolts. The quality and resolution of the measure depends on both the ADCresolution (up to 12 bits in the Z1 and RE-Mote) and the sampling frequency.
As a rule of thumb, the sampling frequency must be at least twice that of thephenomenon you are measuring. As an example, if you want to sample humanspeech (which may contain frequencies up to 8 kHz) you need to sample at twice thatfrequency (16 kHz).
The Z1 mote has a built-in voltage sensor provided as an ADC input channel, as well as ageneric implementation to read external analogue sensors.
Analogue sensors can be connected to both the Z1 and the RE-Mote over phidget ports, which are basically 3-pin connectors (Ground,VCC and signal) with 2.54 mm spacing. This is a legacy name fromthe Z1 release, as these ports were meant for the commerciallyavailable Phidget sensors. Nowadays there are also sensors from otherproviders, such as seeedstudio that have the same pin-out but with adifferent pin spacing (2 mm). This is not a problem, as there are cablesto adapt the pin spacing.
Figure 3.3. Analogue sensors
The ADC results in the RE-Mote returns the reading in voltage.
Sensors
59
For the Z1 mote the ADC output must be converted by means of the following formula: Wemultiply the measured value by the voltage reference and divide the product by the ADC’smaximum output. As the resolution of the ADC is 12 bits (212 = 4096), we get:
Voltage, mV = (units * Vref) / 4096;
The voltage reference limits the range of our measure, meaning if we use a Vref of 2.5 V,the sensor will saturate when reading a higher voltage. The reference can be chosen whileconfiguring the ADC, for both the Z1 and RE-Mote normally 3.3 V is used.
Both the Z1 and the RE-Mote allow up to 6 analogue sensors to be connected, but only twophidget connectors can be soldered at the same time.
For the RE-Mote it is possible to have one phidget connector for a 3.3 V analogue sensor(ADC1) and another for 5 V sensors (ADC3).
The RE-Mote is based on an ARM Cortex-M3, this allows to map anygiven pin to a controller (as opposite to the MSP430, for which a pin haspredefined functions other than GPIO), but only pins in the PA port canbe used as ADC.
For the Z1 mote is possible to have the following combinations (see Figure below):
• Two phidget connectors for 3.3 V sensors.
• Two phidget connectors for 5 V sensors.
• Two phidget connectors, one for 3.3 V and one for 5 V sensors.
Sensors
60
Figure 3.4. Pin assignement
In the snippet below the ADC channels ADC0 (5V1), ADC3 (5V2), ADC1 (3V1) and ADC7(3V2) are mapped by default to be used as input for external analogue sensors.
/* MemReg6 == P6.0/A0 == 5V 1 */
ADC12MCTL0 = (INCH_0 + SREF_0);
/* MemReg7 == P6.3/A3 == 5V 2 */
ADC12MCTL1 = (INCH_3 + SREF_0);
/* MemReg8 == P6.1/A1 == 3V 1 */
ADC12MCTL2 = (INCH_1 + SREF_0);
/* MemReg9 == P6.7/A7 == 3V_2 */
ADC12MCTL3 = (INCH_7 + SREF_0);
To read from a sensor connected to the ADC7 channel of the Z1 mote, in my code I wouldneed to make the following steps:
#include "dev/z1-phidgets.h"
SENSORS_ACTIVATE(phidgets);
printf("Phidget 5V 1:%d\n", phidgets.value(PHIDGET3V_2));
Sensors
61
Include the driver header
Enable the ADC sensors, as default all 4 ADC channels are enabled
Request a reading
The Z1 is powered at 3.3 V, but when connected over the USB (standard voltage 5 V) it allowsto connect 5 V sensors to the phidget ports, namely 5V1 (ADC3) and 5V2 (ADC0) as there isa voltage divider in the input to adapt the reading from 5 V to 3.3 V.
Details about the Z1 implementation of the analogue sensors driver are available atplatform/z1/dev/z1-phidgets.c .There is also a driver for the MSP430 internalvoltage sensor at platform/z1/dev/battery-sensor.c , with an example atexamples/zolertia/z1/test-battery.c .
to see the ADC implementation with an example, let’s connect the Phidget 1142 precisionLight Sensor.
Figure 3.5. Light sensor
The example called test-phidgets.c in examples/zolertia/z1 will read valuesfrom an analog sensor and print them to the terminal.
Connect the light sensor to the 3V2 Phidget connector and compile the example:
make clean && make test-phidgets.upload && make z1-reset && make login
Sensors
62
You can pipeline commands to be executed one after another, in thiscase the make z1-reset restarts the mote after flashed, then makelogin prints to console the output of any printf command in ourcode. You may need to use the argument MOTES=/dev/ttyUSB[0…9] to specify a mote over a particular USB port.
This is the result:
Starting 'Test Button & Phidgets'
Please press the User Button
Phidget 5V 1:123
Phidget 5V 2:301
Phidget 3V 1:1710
Phidget 3V 2:2202
The light sensor is connected to the 3V2 connector, so the raw value is 2202. Try to illuminatethe sensor with a flashlight (from your mobile phone, for example) and then cover it with yourhand so that no light can reach it.
From the Phidget website we have the following information about the sensor:
Parameter Value
Sensor type Light
Light level min 1 lux
Supply Voltage Min 2.4 V
Supply Voltage Max 5.5 V
Max current consumption 5mA
Light level max (3.3 V) 660 lux
Light level max (5 V) 1000 lux
As you can see, the light sensor can be connected to either the 5 V or the 3.3 V Phidgetconnector. The max measurable value depends on where you connect it.
The formula to translate SensorValue into luminosity is: Luminosity(lux)=SensorValue
The RE-Mote platform also allows to connect 5 V sensors to the ADC3 port, using the samevoltage divider as the Z1 mote. As seen in the next snippet, the ADC3 port is mapped to thePA2 pin.
Sensors
63
/*
* This driver supports analogue sensors connected to ADC1, ADC2 and AND3 inputs
* This is controlled by the type argument of the value() function. Possible
* choices are:
* - REMOTE_SENSORS_ADC1 (channel 5)
* - REMOTE_SENSORS_ADC2 (channel 4)
* - REMOTE_SENSORS_ADC3 (channel 2)
*/
Figure 3.6. Connecting sensor
Then to read data from an attached sensor (as we did in the previous example):
#include "dev/zoul-sensors.h"
adc_sensors.configure(SENSORS_HW_INIT, REMOTE_SENSORS_ADC_ALL);
printf("Phidget ADC2 = %d raw\n", adc_sensors.value(REMOTE_SENSORS_ADC2));
printf("Phidget ADC3 = %d raw\n", adc_sensors.value(REMOTE_SENSORS_ADC3));
Include the ADC driver header
Enable and configure the ADC channels (can selectively choose which to enable)
Request a reading
Check the RE-Mote example at example/zolertia/zoul/zoul-demo.c for moredetails.
Exercise: make the sensor take readings as fast as possible. Print to thescreen the ADC raw values and the millivolts (as this sensor is linear,
Sensors
64
the voltage corresponds to the luxes). What are the max and min valuesyou can get? What is the average light value of the room? Create anapplication that turns the red LED on when it is dark and the green LEDon when the room is bright. In between, all the LEDs should be off. Adda timer and measure the light every 10 seconds.
Digital Sensors
Digital sensors are normally interfaced over a digital communication protocol suchas I2C, SPI, 1-Wire, Serial or depending on the manufacturer, a proprietary protocolnormally on a ticking clock.
Digital sensors allow a more extended set of commands (turn on, turn off, configureinterrupts). With a digital light sensor for example, you could set a threshold value andlet the sensor send an interrupt when reached, without the need for continuous polling.
Remember to check the specific sensor information and data sheet for moreinformation.
The Z1 mote has two built in digital sensors: temperature and 3-axis accelerometer. Let usstart with the latter, there is an example called test-adxl345.c available for testing.
The ADXL345 is an I2C ultra-low power sensor able to read up to 16g, well suited for mobiledevice applications. It measures the static acceleration of gravity in tilt-sensing applications,as well as dynamic acceleration resulting from motion or shock. Its high resolution (3.9mg/LSB) enables measurement of inclination changes smaller than 1.0°.
[37] DoubleTap detected! (0xE3) -- DoubleTap Tap
x: -1 y: 12 z: 223
[38] Tap detected! (0xC3) -- Tap
x: -2 y: 8 z: 220
x: 2 y: 4 z: 221
x: 3 y: 5 z: 221
x: 4 y: 5 z: 222
The accelerometer can read data in the x, y and z axis and has three types of interrupts: asingle tap, a double tap and a free-fall (be careful to not damage the mote!).
The code has two threads, one for the interruptions and the other for the LEDs. When Contikistarts, it triggers both processes.
Sensors
65
The led_process thread triggers a timer that waits before turning off the LEDs. This ismostly done to filter the rapid signal coming from the accelerometer. The other process is theacceleration. It assigns the callback for the led_off event. Interrupts can happen at anygiven time, are non periodic and totally asynchronous.
Interrupts can be triggered by external sources (sensors, GPIOs, Watchdog Timer, etc) andshould be cleared as soon as possible. When an interrupts happens, the interrupt handler(which is a process that checks the interrupt registers to find out which is the interrupt source)manages it and forwards it to the subscribed callback.
In this example, the accelerometer is initialized and then the interrupts are mapped to a specificcallback functions. Interrupt source 1 is mapped to the free fall callback handler and the tapinterrupts are mapped to the interrupt source 2.
/*
* Start and setup the accelerometer with default
* values, _i.e_ no interrupts enabled.
*/
accm_init();
/* Register the callback functions */
ACCM_REGISTER_INT1_CB(accm_ff_cb);
ACCM_REGISTER_INT2_CB(accm_tap_cb);
We then need to enable the interrupts like this:
accm_set_irq(ADXL345_INT_FREEFALL,
ADXL345_INT_TAP +
ADXL345_INT_DOUBLETAP);
In the while loop we read the values from each axis every second. If there are no interrupts,this will be the only thing shown in the terminal.
Exercise: put the mote in different positions and check the values ofthe accelerometer. Try to understand which is x, y and z. Measure themaximum acceleration by shaking the mote. Turn on and off the LEDaccording to the acceleration on one axis.
For the next example we will use the ZIG-SHT25, an I2C digital temperature and humiditysensor based on the SHT25 sensor from Sensirion.
Sensors
66
Figure 3.7. Temperature and humidity sensor
Parameter Value
Sensor type Temperature and Humidity
Supply Voltage [V] 2.1 - 3.6
Energy Consumption 3.2 uW (at 8 bit, 1 measurement / s)
Data range 0-100 % RH (humidity), -40-125ºC(temperature)
Max resolution 14 bits (temperature), 12 bits (humidity)
Max current consumption 300 uA
The ZIG-SHT25 sensor example is available in both examples/zolertia/zoul/test-sht25.c and examples/zolertia/z1/test-sht25.c , an output example is givenbelow:
Starting 'SHT25 test'
Temperature 23.71 ºC
Humidity 42.95 % RH
Temperature 23.71 ºC
Humidity 42.95 % RH
Temperature 23.71 ºC
Humidity 42.95 % RH
Emulate Contiki with Cooja
67
Temperature 23.71 ºC
Humidity 42.98 %RH
As usual you can check the driver implementation at the platform/z1/dev andplatform/zoul/dev directories. Check out these locations for other sensors andexamples to guide you to implement your own.
Exercise: convert the temperature to Fahrenheit. Try to get thetemperature and humidity as high as possible (without damaging themote!). Try to print only “possible” values (if you disconnect the sensor,you should not print anything, or print an error message!).
3.6. Emulate Contiki with Cooja
Cooja is the Contiki network emulator. Cooja allows large and small networks of Contiki motesto be emulated at the hardware level, which is slower but allows precise inspection of thesystem behavior, or at a less detailed level, which is faster and allows simulation of largernetworks.
Cooja is a highly useful tool for Contiki development as it allows developers to test their codeand systems long before running it on the target hardware. Developers regularly set up newsimulations both to debug their software and to verify the behavior of their systems.
Most of the examples below can be emulated in Cooja as well (except the sensor ones).
In the terminal window go to the Cooja directory:
cd contiki/tools/cooja
Start Cooja with the command:
ant run
When Cooja is compiled, it will show a blue empty window. Now that Cooja is up and running,we can try it out with an example simulation.
Go to File , Open Simulation , Browse then navigate to the examples/hello-world and select the hello-world-example.csc . This will load the previously savedhello world example.
Create a new simulation
68
If you want to edit an example (for istance, to use a different type of platform), instead ofchoosing the Browse option, select Open and Reconfigure , this will walk you throughthe steps to configure the example.
3.7. Create a new simulation
Click the File menu and click New simulation . Cooja now opens up the Create newsimulation dialog. In this dialog, we may choose to give our simulation a new name, butfor this example, we’ll just stick with My simulation . Leave the other options at defaultvalues. Click the Create button.
Cooja brings up the new simulation. You can choose what you want to visualize by using theTools menu. The Network window shows all the motes in the simulated network, it shouldbe empty now since we have no motes in our simulation. The Timeline window shows allcommunication events in the simulation over time - very handy for understanding what goes onin the network. The Mote output window shows all serial port printouts from all the motes.The Notes window is where we can put notes for our simulation. And the Simulationcontrol window is where we start, pause, and reload our simulation.
3.8. Add motes to the simulation
Before we can simulate our network, we must add one or more motes. We do this via theMotes menu, where we click on Add motes . Since this is the first mote we add, we mustfirst create a mote type to add. Click Create new mote type and select one of the availablemote types. For this example, we click Z1 mote to create an emulated Z1 mote type. Coojaopens the Create Mote Type dialog, in which we can choose a name for our mote typeas well as the Contiki application that our mote type will run.
For this example, we stick with the suggested name, and click on the Browse button on theright hand side to choose our Contiki application.
69
Chapter 4. Wireless with ContikiIn the previous section we covered some of the core features of Contiki, basics of sensors anda general overview of how the applications are built, programmed and simulated in Contiki.This section introduces the wireless communication, details about radios, and basics ideasabout configuring our platforms.
4.1. Preparing your device
The very first step is understanding how our platform is configured.
Each platform implements its own set of default values and configurations, to be used byunderlying modules like the radio, the serial port, etc.
The places to visit for the Zolertia platform are the following:
• Specific hardware settings: parameters such as the default I2C pins, ADC channels,module-specific pin assignment and platform information can be found at platform/zoul/remote/dev/board.h and platform/z1/platform-conf.h .
• Specific Contiki settings: UART settings, MAC driver, radio channel, IPv6, RIME andnetwork buffer configuration, among others, can be found at platform/zoul/contiki-conf.h and platform/z1/contiki-conf.h .
As a general good practice, user configurable parameters are normally allowed to beoverridden by the applications, this also serves as a guideline to discern which values can bechanged by the casual user, from those meant to be changed only if you really know what youare doing. Below is an example:
#ifndef UART0_CONF_BAUD_RATE
#define UART0_CONF_BAUD_RATE 115200
#endif
By defining UART0_CONF_BAUD_RATE in our application’s project-conf.h , we canchange the default 115200 baud rate. Notice that generally it is a good practice to add CONFto the user configurable parameters.
One of the most used tools is probably grep , a handy command tosearch for a text string in any document or location. One way to run thiscommand is grep -lr "alinan . , if executed at the root of our
Device addressing
70
Contiki installation, it will list recursively all the files authored by AntonioLinan. This is a good way to check the location of a specific definition,if you are not using an IDE like Eclipse. Check man grep for moreinformation.
For windows Astrogrep1 is a good option.
In the next section we will review the most notable parameters to configure, but as usualdepending on your application and setup, the best way to ensure everything is properly set isby reviewing the specific platform configuration files, and modify or redefine accordingly.
4.1.1. Device addressing
To start working you must first define the Node ID of each node, this will be used to generatethe mote’s MAC address and the IPv6 addresses (link-local and global).
RE-Mote addresses
The RE-Mote platform comes with two pre-loaded MAC addresses stored in its internalflash memory, but the user can instead choose a hardcoded one. The following switches atplatform/zoul/contiki-conf.h selects the chosen one.
/** * \name IEEE address configuration * * Used to generate our RIME & IPv6 address * @{ *//** * \brief Location of the IEEE address * 0 => Read from InfoPage, * 1 => Use a hardcoded address, configured by IEEE_ADDR_CONF_ADDRESS */#ifndef IEEE_ADDR_CONF_HARDCODED
#define IEEE_ADDR_CONF_HARDCODED 0
#endif
/** * \brief Location of the IEEE address in the InfoPage when * IEEE_ADDR_CONF_HARDCODED is defined as 0 * 0 => Use the primary address location
1 http://astrogrep.sourceforge.net/
Device addressing
71
* 1 => Use the secondary address location */#ifndef IEEE_ADDR_CONF_USE_SECONDARY_LOCATION
#define IEEE_ADDR_CONF_USE_SECONDARY_LOCATION 0
#endif
If using your own hardcoded address, the following define can be overridden by the application:
#ifndef IEEE_ADDR_CONF_ADDRESS
#define IEEE_ADDR_CONF_ADDRESS { 0x00, 0x12, 0x4B, 0x00, 0x89, 0xAB, 0xCD, 0xEF }
#endif
Z1 mote addresses
Let’s use the ID from the mote list:
Reference Device Description
--------------------------------------------------
Z1RC3301 /dev/ttyUSB0 Silicon Labs Zolertia Z1
The node ID should be 3301 (decimal) if no previously saved node ID is found in the flashmemory.
Let’s see how Contiki uses this to derive a full IPv6 and MAC address. At platforms/z1/contiki-z1-main.c
#ifdef SERIALNUM
if(!node_id) {
PRINTF("Node id is not set, using Z1 product ID\n");
node_id = SERIALNUM;
}
#endif
node_mac[0] = 0xc1; /* Hardcoded for Z1 */
node_mac[1] = 0x0c; /* Hardcoded for Revision C */
node_mac[2] = 0x00; /* Hardcoded to arbitrary even number so that the 802.15.4 MAC
address is compatible with an Ethernet MAC address - byte 0 (byte 2 in the DS ID)
*/
node_mac[3] = 0x00; /* Hardcoded */
node_mac[4] = 0x00; /* Hardcoded */
node_mac[5] = 0x00; /* Hardcoded */
node_mac[6] = node_id >> 8;
node_mac[7] = node_id & 0xff;
}
Set the bandwidth and channel
72
So the mote should have the following addresses:
MAC c1:0c:00:00:00:00:0c:e5
Node id is set to 3301.
Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:0ce5
Where 0xce5 is the hex value corresponding to 3301 . The global address is only set whenan IPv6 prefix is assigned (by now you should know this from earlier sections).
If instead you wish to have your own addressing scheme, you can edit the node_mac values atcontiki-z1-main.c file. If you wish to replace the node id value obtained from the productid, you need to store a new one in the flash memory, luckily there is already an applicationto do so:
Go to examples/zolertia/z1 location and replace the 158 for your own required value:
make clean && make burn-nodeid.upload nodeid=158 nodemac=158 && make z1-reset &&
make login
You should see the following:
MAC c1:0c:00:00:00:00:0c:e5 Ref ID: 3301
Contiki-2.6-1803-g03f57ae started. Node id is set to 3301.
CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:0ce5
Starting 'Burn node id'
Burning node id 158
Restored node id 158
As you can see, now the node ID has been changed to 158, when you restart the mote youshould see that the changes have been applied:
MAC c1:0c:00:00:00:00:00:9e Ref ID: 3301
Contiki-2.6-1803-g03f57ae started. Node id is set to 158.
CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:009e
4.1.2. Set the bandwidth and channel
The bandwidth and allowed channels depend on the operating frequency band. They will bedetermined by the spectrum regulation agency of the country, along with maximum transmittedpower allowable. .The IEEE 802.15.4 standard
Set the bandwidth and channel
73
The IEEE 802.15.4 is a standard for wireless communication, it specifies the physicaland media access control layers for low-rate wireless personal area networks (LR-WPANs).
The standard specifies the use of the 868-868.8 MHz (in Europe and many othercountries), the 902-928 MHz (in United States, Canada, and some Latin Americacountries), or the world-wide 2.400-2.4835 GHz band part of the Industrial Scientificand Medical applications (ISM).
Figure 4.1. IEEE 802.15.4 2.4 GHz regulationrequirements (electronicdesign.com, 20132)
In practice the 2.4 GHz band is being heavily used due to its world-wide availability.The ZigBee proprietary protocol by the ZigBee alliance was one of the early adoptersof IEEE 802.15.4. It did so leveraging the physical and MAC layer of IEEE 802.15.4,specifying on top additional routing and networking functionality to build meshnetworks.
Quite recently the Thread Group3 has proposed its own simplified IPv6-based meshnetworking protocol for connecting products around the home to each other, to theInternet and to the cloud. This will surely boost the adoption of IEEE 802.15.4 and IPv6.
2 http://electronicdesign.com/what-s-difference-between/what-s-difference-between-ieee-802154-and-zigbee-wireless3 http://threadgroup.org/
Set the bandwidth and channel
74
Figure 4.2. Thread layers and standards (Thread group, 20154)
Working at 2.4 GHz
As the 2.4 GHz band is also used by other technologies like WiFi and Bluetooth, this spectrumis shared and overlaps might occur. The Figure below shows the channel allocation of the2.4 GHz IEEE 802.15.4, and the recommended channels to avoid interferences with other co-located devices. With the rise of the Bluetooth Low Energy, and the ubiquitous WiFi presentin our lives, the selection of a proper operating channel is crucial in any deployment.
4 http://threadgroup.org/
Set the bandwidth and channel
75
Figure 4.3. Channel assignment
The default channel of the RE-Mote is defined as follows:
#ifndef CC2538_RF_CONF_CHANNEL
#define CC2538_RF_CONF_CHANNEL 26
#endif /* CC2538_RF_CONF_CHANNEL */
The Z1 mote defines its default channel as:
#ifdef RF_CHANNEL
#define CC2420_CONF_CHANNEL RF_CHANNEL
#endif
#ifndef CC2420_CONF_CHANNEL
#define CC2420_CONF_CHANNEL 26
#endif /* CC2420_CONF_CHANNEL */
The radio channel can be defined from the application’s project-conf.h or theMakefile .
The radio drivers in Contiki are implemented to comply with the struct radio_driver incore/dev/radio.h . This abstraction allows to interact with the radio using a standardizedAPI, independently of the radio hardware. The functions to set and read radio parameters areexplained below.
/** Get a radio parameter value. */radio_result_t (* get_value)(radio_param_t param, radio_value_t *value);
Set the transmission power
76
/** Set a radio parameter value. */radio_result_t (* set_value)(radio_param_t param, radio_value_t value);
To change the channel from the application use RADIO_PARAM_CHANNEL as follows:
rd = NETSTACK_RADIO.set_value(RADIO_PARAM_CHANNEL, value);
Where value can be any value from 11 to 26, and rd will be eitherRADIO_RESULT_INVALID_VALUE or RADIO_RESULT_OK .
Working at 863-950 MHz
The RE-Mote has a dual 2.4 GHz and 863-950 MHz RF interface, which can be selectedalternatively, or used simultaneously (the latter currently not supported in Contiki at themoment).
As default the RE-Mote uses the IEEE 802.15.4g mandatory mode for the 868 MHz band,configured for 2-GFSK modulation, 50 kbps data rate and with 33 channels available.
The RE-Mote uses the Texas Instruments CC1200 RF transceiver, referred to inContiki as dev/cc1200 . The default configuration file is located in dev/cc1200/
cc1200-802154g-863-870-fsk-50kbps.c .
To change channels from the application we use the RF API:
rd = NETSTACK_RADIO.set_value(RADIO_PARAM_CHANNEL, value);
Where value can be any value from 11 to 26, and rd it will be eitherRADIO_RESULT_INVALID_VALUE or RADIO_RESULT_OK .
4.1.3. Set the transmission power
The radio frequency power transmission is that at the output of the transmitter before reachingthe antenna. The higher the transmission power the higher the wireless range, but the powerconsumption usually increases as well. The range is heavily dependent on the frequency, theantenna used and its height above the ground.
Set the transmission power
77
Changing the transmission power for the Z1 (CC2420) and the RE-Mote (CC2538)
The RE-Mote platform uses the CC2538 built-in 2.4 GHz radio. As default the transmissionpower is set to 3 dBm (2 mW) in the cpu/cc2538/cc2538-rf.h header as shown below.
CC2538_RF_TX_POWER_RECOMMENDED 0xD5
This recommended value is taken from the SmartRF Studio5 .
Other values and its corresponding output power levels are shown in the next table.
Table 4.1. CC2538 Transmission power recommended values (fromSmartRF Studio6)
TX Power (dBm) Value
+7 0xFF
+5 0xED
+3 0xD5
+1 0xC5
0 0xB6
-1 0xB0
-3 0xA1
-5 0x91
-7 0x88
-9 0x72
-11 0x62
-13 0x58
-15 0x42
-24 0x00
5 http://www.ti.com/tool/smartrftm-studio&DCMP=hpa_rf_general&HQS=Other+OT+smartrfstudio6 http://www.ti.com/tool/smartrftm-studio&DCMP=hpa_rf_general&HQS=Other+OT+smartrfstudio
Set the transmission power
78
As illogical as it may sound, there might be some reasons to reducetransmission power:
• To reduce the power consumption.
• To test a multi-hop network without placing the nodes too far (toomuch power can saturate the receiver).
• To avoid interference among co-located networks in the same area.
The current consumption can go from 24 mA to 34 mA when changing the transmission powerfrom 0 dBm to 7 dBm (AN1257 ).
The Z1 mote uses the Texas Instrument CC2420 RF transceiver. As default the transmissionpower is set to 0 dBm (1 mW), which is the maximum allowed by the radio.
The available output power and its corresponding configuration values are listed in the tablebelow, as well as the current consumption at each level.
Table 4.2. CC2420 Transmission power (CC2420 datasheet, page 518)
TX Power(dBm)
Value mA
0 31 17.4
-1 27 16.5
-3 23 15.2
-5 19 13.9
-7 15 12.5
-10 11 11.2
-15 7 9.9
-25 3 8.5
For both platforms the transmission power can be changed with:
rd = NETSTACK_RADIO.set_value(RADIO_PARAM_TXPOWER, value);
7 http://www.ti.com/lit/an/swra437/swra437.pdf8 http://www.ti.com/lit/ds/symlink/cc2420.pdf
Set the transmission power
79
Where value can be any value from the above table, and rd it will be eitherRADIO_RESULT_INVALID_VALUE or RADIO_RESULT_OK .
Changing the transmission power for the RE-Mote (CC1200)
As mentioned earlier, the RE-Mote has an on-board sub-1 GHz interface based on theCC1120 radio transceiver, configured to operate in the 863-950 MHz bands. The maximumtransmission power allowed depends on the specific band and regulations in place, which canalso impose limits on the maximum antenna gain, be sure to check the local regulations beforechanging the output power.
The regulations are country specific and out of the scope of this section.
The following values are taken from the SmartRF Studio9 , using default IEEE 802.15.4g ETSIcompliant configuration.
Table 4.3. CC1200 Transmission power recommended values (fromSmartRF Studio10)
TX Power (dBm) Value
+14 0x7F
+13 0x7C
+12 0x7A
+11 0x78
+8 0x71
+6 0x6C
+4 0x68
+3 0x66
+2 0x63
+1 0x61
0 0x5F
-3 0x58
-40 0x41
9 http://www.ti.com/tool/smartrftm-studio&DCMP=hpa_rf_general&HQS=Other+OT+smartrfstudio10 http://www.ti.com/tool/smartrftm-studio&DCMP=hpa_rf_general&HQS=Other+OT+smartrfstudio
Set the transmission power
80
TX Power (dBm) Value
-6 0x51
-11 0x46
-24 0x42
-40 0x41
These values correspond to the CC1200_PA_CFG1 register.
As default the CC1200 driver11 in Contiki starts with the maximum transmission power,defined as follows:
/* The maximum output power in dBm */
#define RF_CFG_MAX_TXPOWER CC1200_CONST_TX_POWER_MAX
The minimum and maximum allowed values are set in dev/cc1200/cc1200-const.h asshown below.
/* Output power in dBm */
/* Up to now we don't handle the special power levels PA_POWER_RAMP < 3, hence
* the minimum tx power is -16. See update_txpower().
*/
#define CC1200_CONST_TX_POWER_MIN (-16)
/*
* Maximum output power will probably depend on the band we use due to
* regulation issues
*/
#define CC1200_CONST_TX_POWER_MAX 14
The CC1200 driver calculates the proper CC1200_PA_CFG1 register value, so we need topass as value argument the required transmission power.
rd = NETSTACK_RADIO.set_value(RADIO_PARAM_TXPOWER, value);
Where value can be any value from -14 to 16, and rd will be eitherRADIO_RESULT_INVALID_VALUE or RADIO_RESULT_OK .
11 https://github.com/contiki-os/contiki/blob/master/dev/cc1200/cc1200.c
Checking the wireless link
81
4.1.4. Checking the wireless link
Due to the changing environment conditions that normally affect the wireless systems, suchas rain, interferences, obstacles, reflections, etc., measuring the wireless medium and linksquality is important.
Checking the wireless medium should be done in three stages: before deploying your network,at deployment phase and later at network runtime, to ensure that the nodes create and selectthe best available routes.
Link Quality Estimation
Link Quality Estimation is an integral part of assuring reliability in wireless networks.Various link estimation metrics have been proposed to effectively measure the qualityof wireless links.
Figure 4.4. Link quality estimation process
The ETX metric, or expected transmission count, is a measure of the quality of a pathbetween two nodes in a wireless packet data network. ETX is the number of expectedtransmissions of a packet necessary for it to be received without error at its destination.This number varies from one to infinity. An ETX of one indicates a perfect transmissionmedium, where an ETX of infinity represents a completely non-functional link. Note
Checking the wireless link
82
that ETX is an expected transmission count for a future event, as opposed to an actualcount of a past events. It is hence a real number, generally not an integer.
ETX can be used as the routing metric. Routes with a lower metric are preferred. Ina route that includes multiple hops, the metric is the sum of the ETX of the individualhops.
Below we describe how to read the LQI and RSSI to have a first approximation of the linkconditions.
What is RSSI?
RSSI (Received Signal Strenght Indicator) is a generic radio receiver technologymetric used internally in a wireless networking device to determine the amount of radioenergy received in a given channel. The end-user will likely observe an RSSI valuewhen measuring the signal strength of a wireless network through the use of a wirelessnetwork monitoring tool like Wireshark, Kismet or Inssider.
The image below shows how the Packet Reception Rate (PRR) dramaticallydecreases as the CC2420 RSSI values worsen.
Checking the wireless link
83
Figure 4.5. Packet rejection rate versusreceived signal strenght indicator
There is no standardized relationship of any particular physical parameter to the RSSIreading, Vendors and chipset makers provide their own accuracy, granularity, andrange for the actual power (measured in mW or dBm) and the corresponding RSSIvalues.
There are 2 different types of RSSI readings available:
• The first one is an indication of the amount of power present in the wireless medium atthe given frequency and at given time. In the absence of any packet in the air, this willbe the noise floor. This measurement is also used to decide if the medium is free, andavailable to send a packet. A high value could be due to interference or to the presenceof a packet in the air.
• The second measurement is performed only after a packet has been correctly decoded,and gives the strength of the packet received from a specific node.
The first measurement can be read using the radio API as follows:
rd = NETSTACK_RADIO.get_value(RADIO_PARAM_RSSI, value);
Checking the wireless link
84
Where value is a variable passed as a pointer to store the RSSI value, and rd it will be eitherRADIO_RESULT_INVALID_VALUE or RADIO_RESULT_OK .
To read the RSSI value of a correctly decoded received packet, at the receive callback:
packetbuf_attr(PACKETBUF_ATTR_RSSI);
More information about the packetbuf attributes is available in core/net/
packetbuf.h .
For the CC2420 radio frequency transceiver on the Z1 mote, the RSSI can range from 0 to-100, values close to 0 mean good links while values close to -100 are indicators of a bad link,which could be due to multiple factors such as distance, environment, obstacles, interferences,etc.
What is LQI?
LQI (Link Quality Indicator) is a digital value often provide by Chipset vendors as anindicator of how well a signal is demodulated, in terms of the strength and quality ofthe received packet, thus indicating a good or bad wireless medium.
The example below shows how the Packet Reception Rate decreases as the LQIdecreases.
Configure the MAC layer
85
Figure 4.6. Packet rejection rate versus link quality indicator
To read the LQI value we use the Radio API:
rd = NETSTACK_RADIO.get_value(PACKETBUF_ATTR_LINK_QUALITY, value);
Where value is a variable passed as a pointer to store the LQI value, and rd it will be eitherRADIO_RESULT_INVALID_VALUE or RADIO_RESULT_OK .
The CC2420 radio used by the Z1 mote typically ranges from 110 (indicates a maximum qualityframe) to 50 (typically the lowest quality frames detectable by the transceiver).
Detailed information about the CC2538 LQI calculation is found in the CC2538 user guide12 .
4.2. Configure the MAC layer
MAC protocols
Medium Access Control (MAC) protocols describe the medium access adopted in anetwork, by establishing the rules that specify when a given node is allowed to transmitpackets.
12 http://www.ti.com/lit/ug/swru319c/swru319c.pdf
Configure the MAC layer
86
Protocols can be classified as contention-based or reservation-based protocols.
The first are based on Carrier Sensing for detecting medium activity and are proneto collisions and lower efficiency at heavy loads, but are easy to implement. Thesecond group is efficient in terms of throughput and energy, but require precisesynchronization and is less adaptable to dynamic traffic.
The medium access implementation in Contiki has 3 different layers: Framer, Radio Duty-Cycle (RDC) and Medium Access Control (MAC).
MAC driver
87
Figure 4.7. Contiki MAC stack13
The network layer can be accessed through the global variables NETSTACK_FRAMER ,NETSTACK_RDC and NETSTACK_MAC , which are defined at compilation time.
The variables are located in core/net/netstack.h , and can be defined by each platformas default and overridden by applications.
4.2.1. MAC driver
Contiki provides two MAC drivers: CSMA and NullMAC
13 http://anrg.usc.edu/contiki/index.php/MAC_protocols_in_ContikiOS
RDC driver
88
CSMA (Carrier-Sense Multiple Access) receives incoming packets from the RDC layer anduses the RDC layer to transmit packets. If the RDC layer or the radio layer detects that themedium is busy, the MAC layer may retransmit the packet at a later point in time. CSMAprotocol keeps a list of packets sent to each of the neighbors and calculate statistics such asnumber of retransmissions, collisions, deferrals, etc. The medium access check is performedby the RDC driver.
NullMAC is a simple pass-through protocol. It calls the appropriate RDC functions.
As default both Z1 mote and RE-Mote uses the CSMA driver.
#ifndef NETSTACK_CONF_MAC
#define NETSTACK_CONF_MAC csma_driver
#endif
Alternatively, a user can choose NullMAC as follow:
#define NETSTACK_CONF_MAC nullmac_driver
4.2.2. RDC driver
Radio Duty-Cycle (RDC) layer handles the sleep period of nodes. This layer decides whenpackets will be transmitted and ensures that nodes are awake when packets are to bereceived.
The implementation of Contiki’s RDC protocols are available in core/net/mac . Thefollowing RDC drivers are implemented: contikimac , xmac , lpp , nullrdc andsicslowmac . The implementation and details of the aforementioned RDC drivers are outof the scope of this chapter. The most commonly used is ContikiMAC. NullRDC is a pass-through layer that never switches the radio off.
#ifndef NETSTACK_CONF_RDC
#define NETSTACK_CONF_RDC contikimac_driver
#endif
RDC drivers try to keep the radio off as much as possible, periodically checking the wirelessmedium for radio activity. When activity is detected, the radio is kept on to check if it has toreceive the packet, or it can go back to sleep.
Framer driver
89
The channel check rate is given in Hz, specifying the number of times the channel is checkedper second, and the default channel check rate is 8 Hz. Channel check rates are given inpowers of two and typical settings are 2, 4, 8, and 16 Hz.
#ifndef NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE
#define NETSTACK_CONF_RDC_CHANNEL_CHECK_RATE 8
#endif
A packet must generally be retransmitted or "strobed" until the receiver is on and receives it.This increments the power consumption of the transmitter and increases the radio traffic, butthe power savings at the receiver compensates for this and there is a net overall power saving.
One alternative to optimize the RDC is to enable "phase optimization", which delays strobinguntil just before the receiver is expected to be awake. This however requires a goodtime synchronization between the transmitter and the receiver (more details in RDC PhaseOptimization14 ). To enable phase optimization change the 0 below to one.
#define CONTIKIMAC_CONF_WITH_PHASE_OPTIMIZATION 0
#define WITH_FAST_SLEEP 1
4.2.3. Framer driver
The Framer driver is actually a set of functions to frame the data to be transmitted, and to parsethe received data. The Framer implementations are located in core/net/mac , of which themost noticeable ones are framer-802154 and framer-nullmac .
In the RE-Mote platform the following configuration is the default:
#ifndef NETSTACK_CONF_FRAMER
#if NETSTACK_CONF_WITH_IPV6
#define NETSTACK_CONF_FRAMER framer_802154
#else /* NETSTACK_CONF_WITH_IPV6 */
#define NETSTACK_CONF_FRAMER contikimac_framer
#endif /* NETSTACK_CONF_WITH_IPV6 */
#endif /* NETSTACK_CONF_FRAMER */
Meaning that when IPv6 is used, the framer-802154 is selected, else thecontikimac_framer is used (default one for the contikimac_driver ).
14 https://github.com/contiki-os/contiki/wiki/RDC-Phase-optimization
IPv6 and Routing
90
The framer-nullmac framer should be used together with nullmac_driver (MAClayer). This simply fills in the 2 fields of nullmac_hdr , which are: receiver address andsender address.
The framer-802154 is implemented in core/net/mac/framer-802154.c . The driverframes the data in compliance to the IEEE 802.15.4 (2003) standard. The framer insert andextracts the data to the packetbuf structure.
4.3. IPv6 and Routing
One of Contiki’s most prominent feature is the support of IP protocols, being one of the firstembedded operating systems to provide IPv6 support.
Alternatively Contiki also supports IPv4 and non-IP communication (Rime)15 , however theremainder of this book will focus in IPv6. There is a good set of rime examples availableat examples/rime . The RE-Mote zoul-demo.c most basic example at examples/zolertia/zoul uses rime as well.
4.3.1. IPv6
The uIP is an Open Source TCP/IP stack designed to be used even with tiny 8 and 16 bitmicrocontrollers. It was initially developed by Adam Dunkels16 while at the Swedish Instituteof Computer Science (SICS)17 , licensed under a BSD style license, and further developed bya wide group of developers.
The implementation details of the uIP/uIPv6 is out of the scope of this section. The remainderof this section explains the basic configurations at the platform and application level.
To enable IPv6 the following has to be defined, either in the application’s Makefile or inits project-conf.h file:
#define UIP_CONF_IPV6 1
#ifndef NBR_TABLE_CONF_MAX_NEIGHBORS
#define NBR_TABLE_CONF_MAX_NEIGHBORS 20
15 https://github.com/alignan/contiki/tree/master/core/net/rime16 http://dunkels.com/adam/17 https://en.wikipedia.org/wiki/Swedish_Institute_of_Computer_Science
RPL
91
#endif
#ifndef UIP_CONF_MAX_ROUTES
#define UIP_CONF_MAX_ROUTES 20
#endif
/* uIP */
#ifndef UIP_CONF_BUFFER_SIZE
#define UIP_CONF_BUFFER_SIZE 1300
#endif
#define UIP_CONF_IPV6_QUEUE_PKT 0
#define UIP_CONF_IPV6_CHECKS 1
#define UIP_CONF_IPV6_REASSEMBLY 0
#define UIP_CONF_MAX_LISTENPORTS 8
4.3.2. RPL
There are several routing flavors to chose, but ultimately all do the same thing: ensure thatpackets arrive at the right destination. This is done in different ways depending on factors suchas the routing metric (how a route is qualified as better than others), whether the routing isdone dynamically or statically, etc.
In Contiki the default routing protocol is RPL. Other protocols such as Ad hoc On-DemandDistance Vector (AODV) are out of the scope of this section.
The specifics of the RPL implementation are out of the scope of this section, we merelydescribe the common configurations and provide a brief introduction to RPL. For more details,check the RPL implementation at core/net/rpl .
What is RPL?
RPL is an IPv6 routing protocol for low power and lossy networks designed by theIETF Routing Over Low power and Lossy network (ROLL) group, used as the de factorouting protocol in Contiki. RPL is a proactive distance vector protocol, it starts findingthe routes as soon as the RPL network is initialized.
RPL
92
Figure 4.8. RPL in the protocol stack
It supports three traffic patterns:
• Multipoint-to-point (MP2P)
• Point-to-multipoint (P2MP)
• Point-to-point (P2P)
RPL builds Destination Oriented DAGs (DODAGs) rooted towards one sink (DAGROOT) identified by a unique identifier DODAGID. The DODAGs are optimized usingan Objective Function (OF) metric identified by an Objective Code Point (OCP), whichindicates the dynamic constraints and the metrics such as hop count, latency, expectedtransmission count, parents selection, energy consumption, etc. A rank number isassigned to each node which can be used to determine its relative position anddistance to the root in the DODAG.
Within a given network, there may be multiple, logically independent RPL instances.An RPL node may belong to multiple RPL instances, and may act as a router in someand as a leaf in others. A set of multiple DODAGs can be in an RPL INSTANCE anda node can be a member of multiple RPL INSTANCEs, but can belong to at most oneDODAG per DAG INSTANCE.
A trickle timer mechanism regulates DODAG Information Object (DIO) messagetransmissions, which are used to build and maintain upwards routes of the DODAG,advertising its RPL instance, DODAG ID, RANK and DODAG version number.
RPL
93
A node can request DODAG information by sending DODAG Information Solicitationmessages (DIS), soliciting DIO messages from its neighborhoods to update its routinginformation and join an instance.
Nodes have to monitor DIO messages before joining a DODAG, and then join aDODAG by selecting a parent Node from its neighbors using its advertised latency, OFand RANK. Destination Advertisement Object (DAO) messages are used to maintaindownward routes by selecting the preferred parent with lower rank and sending apacket to the DAG ROOT through each of the intermediate Nodes.
RPL has two mechanisms to repair the topology of the DODAG, one to avoid loopingand allow nodes to join/rejoin, and other called global repair. Global repair is initiatedat the DODAG ROOT by incrementing the DODAG Version Number to create a newDODAG Version.
More information about RPL can be found in RFC655018 .
Routing support is enabled as default in the Z1 mote and RE-Mote platform. To enable routingthe following has to be enabled:
#ifndef UIP_CONF_ROUTER
#define UIP_CONF_ROUTER 1
#endif
To enable RPL add the following to your application’s Makefile or its project-conf.hfile.
#define UIP_CONF_IPV6_RPL 1
The following is the default configuration done in the RE-Mote:
/* ND and Routing */
#define UIP_CONF_ND6_SEND_RA 0
#define UIP_CONF_IP_FORWARD 0
#define RPL_CONF_STATS 0
Disable sending routing advertisements
18 https://tools.ietf.org/html/rfc6550
Set up a sniffer
94
Disable IP forwarding
RPL Configuration statistics are disabled
The RPL_CONF_OF parameter configures the RPL objective function. The Minimum Rankwith Hysteresis Objective Function (MRHOF) uses ETX as routing metric and it also has stubsfor energy metric.
#ifndef RPL_CONF_OF
#define RPL_CONF_OF rpl_mrhof
#endif
The Expected Transmissions metric (ETX) measure how many tries it takes to receive anacknowledgment (ACK) of a sent packet, keeping a moving average for each neighbor,computing the sum of all ETXs to build the routes.
As default Contiki uses storing mode for RPL downward routes. Basically all nodes storein a routing table the addresses of their child nodes.
4.3.3. Set up a sniffer
A packet sniffer is a must-have tool for any wireless network application, it allows to see whatyou are transmitting over the air, verifying both that the transmissions are taking place, theframes/packets are properly formatted, and that the communication is happening on a givenchannel.
There are commercial options available, such as the Texas Instruments SmartRF packetSniffer19 , which can be used with a CC2531 USB dongle20 to capture packets like the onebelow.
Figure 4.9. Sniffer packet capture
19 http://www.ti.com/tool/packet-sniffer20 http://www.ti.com/tool/CC2531EMK
Set up a sniffer
95
We will use for this exercise the SenSniff21 application, paired with a RE-Mote and Wireshark(already installed in instant Contiki). This setup will allow us to understand how the wirelesscommunication is done in Contiki.
To program the RE-Mote as a packet Sniffer:
cd examples/cc2538-common/sniffer
Compile and program:
make TARGET=zoul sniffer.upload
At the moment of writing this section the Z1 sniffer wasnot officially included in Contiki, however a branch with theimplementation is available at: https://github.com/alignan/contiki/tree/z1_sniffer/examples/z1/sniffer
Open a new terminal, and clone the sensniff project in your home folder:
cd $HOME
git clone https://github.com/g-oikonomou/sensniff
cd sensniff/host
Then launch the sensniff application with the following command:
python sensniff.py --non-interactive -d /dev/ttyUSB0 -b 115200
Sensniff will read data from the mote over the serial port, dissect the frames and pipe to /tmp/sensniff by default, now we need to connect the other extreme of the pipe to wireshark,else you will get the following warning:
"Remote end not reading"
Which is not worrisome, it only means that the other pipe endpoint is not connected. You canalso save the sniffed frames for later opening with wireshark, adding the following argument tothe above command -p name.pcap , which will save the session output in a name.pcapfile. Change the naming and location for storing the file accordingly.
21 https://github.com/g-oikonomou/sensniff
Set up a sniffer
96
At the moment of writing this tutorial changing channels from theSensniff application was not implemented but proposed as a feature,check the Sensniff’s README.md for changes and current status.
Open another terminal and launch wireshark with the following command, which will add thepipe as a capture interface:
sudo wireshark -i /tmp/sensniff
Select the /tmp/sensniff interface from the droplist and click Start just above.
Figure 4.10. Capture options
Make sure that the pipe is configured to capture packets in promiscuous mode, if needed youcan increase the buffer size, but 1 MB is normally enough.
Set up a sniffer
97
Figure 4.11. Interface settings
Now the captured frames should start to appear on screen.
Figure 4.12. Captured frames
You can add specific filters to limit the frames being shown on screen, for this example click atthe Expression button and a list of available attributes per protocol are listed, scroll downto IEEE 802.15.4 and check the available filters. You can also chain different filter argumentsusing the Filter box, in this case we only wanted to check the frames belonging to thePAN 0xABCD and coming from node c1:0c::0309 , so we used the wpan.dst_pan andwpan.src64 attributes.
The Border Router
98
Figure 4.13. Wireshark filters
When closing the Sensniff python application, a session information is provided reporting thefollowing statistics:
Frame Stats:
Non-Frame: 6
Not Piped: 377
Dumped to PCAP: 8086
Piped: 7709
Captured: 8086
Exercise: sniff the traffic! try to filter outgoing and incoming data packetsusing your own rules.
4.3.4. The Border Router
The border router or edge router is typically a device sitting at the edge of our network, whichallow us to talk to outside networks using its built-in network interfaces, such as WiFi, Ethernet,Serial, etc.
Figure 4.14. The border router
The Border Router
99
In Contiki the current and most used border router application implements a serial-basedinterface called SLIP, it allows to connect a given mote to a host using scripts like tunslip6in tools/tunslip6 over the serial port, creating a tunnelled network interface, which canbe given an IPv6 prefix to set the network global IPv6 addresses.
The border router application is located at examples/ipv6/rpl-border-router , thefollowing code snippets are the most relevant:
/* Request prefix until it has been received */
while(!prefix_set) {
etimer_set(&et, CLOCK_SECOND);
request_prefix();
PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et));
}
dag = rpl_set_root(RPL_DEFAULT_INSTANCE,(uip_ip6addr_t *)dag_id);
if(dag != NULL) {
rpl_set_prefix(dag, &prefix, 64);
PRINTF("created a new RPL dag\n");
}
The snippet above bootstraps until a valid prefix has been given. Once the prefix has beenassigned, the node will set the prefix and convert itself in the root node (DODAG).
Normally it is preferable to configure the border router as a non-sleeping device, so that theradio receiver is always on. You can configure the border router settings using the project-conf.h file.
#undef NETSTACK_CONF_RDC
#define NETSTACK_CONF_RDC nullrdc_driver
By default the border-router applications includes a built-in web server, displaying informationabout the network, such as the immediate neighbors (1-hop away) and the known routes tonodes in their networks. To enable the web server, the WITH_WEBSERVER flag should beenabled, and by default it will add the httpd-simple.c application.
Hands on: installing the border router
The following assumes to use a RE-Mote platform, but the Z1 mote can be used as well.
make TARGET=zoul savetarget
UDP and TCP basics
100
To compile, flash the mote and connect the border router to your host; run:
make border-router.upload && make connect-router
By default it will try to connect to a mote at port /dev/ttyUSB0 using the following serialsettings: 115200 baud rate, 8 bits, No parity and 1 bit stop. If you do not state an IPv6 prefix itwill use the default aaaa::1/64 , to specify a different one run the tunslip tool instead usingthe following:
make connect-router PREFIX=2001:abcd:dead:beef::1/64
You can also compile and run the tunslip6 tool directly from the tools location, to compilejust type:
cd tools
cc tunslip6.c -o tunslip6
And to run with specific arguments, i.e. connect to a specific serial port, name your tunnelconnection with a specific name, or proxify to a given address and port, use the following:
./tunslip -s /dev/ttyUSB0 -t tun0 2001:abcd:dead:beef::1/64
Run tunslip -H for more information.
6lbr22 is a deployment-ready 6LoWPAN border router solution basedon Contiki, it has support for the Z1 mote and in short time will have alsofor the RE-Mote platform (the CC2538dk is already supported, portingis trivial). To take your border router to the next level, this is the tool youhave been looking for.
4.4. UDP and TCP basics
Now that we have covered the mote configurations and the MAC and routing layers, let usset up a UDP network.
22 http://cetic.github.io/6lbr/
The UDP API
101
What is UDP?
UDP (User Datagram Protocol) is a communications protocol that offers a limitedamount of services for messages exchanged among devices in a network that usesthe Internet Protocol (IP).
UDP is an alternative to the Transmission Control Protocol (TCP) and, together withIP, is sometimes referred to as UDP/IP. Like the Transmission Control Protocol, UDPuses the Internet Protocol to actually get a data unit (called a datagram) from onecomputer to another.
Unlike TCP, UDP does not provide message fragmentation and reassembling at theother end, this means that the application must be able to make sure that the entiremessage has arrived and is in the right order.
Network applications that want to save processing time because they have very smalldata units to exchange (and therefore very little message reassembling to do) mayprefer UDP to TCP
The UDP implementation is Contiki resides in core/net/ip . The remainder of the sectionwill focus on describing the UDP available functions.
4.4.1. The UDP API
We need to create a socket for the connection, this is done using the udp_socket structure,which has the following elements:
struct udp_socket {
udp_socket_input_callback_t input_callback;
void *ptr;
struct process *p;
struct uip_udp_conn *udp_conn;
};
After creating the UDP socket structure, we need to register the UDP socket. This is done withthe udp_socket_register .
/**
The UDP API
102
* \brief Register a UDP socket * \param c A pointer to the struct udp_socket that should be registered * \param ptr An opaque pointer that will be passed to callbacks * \param receive_callback A function pointer to the callback function that will be called when data arrives * \retval -1 The registration failed * \retval 1 The registration succeeded */int udp_socket_register(struct udp_socket *c,
void *ptr,
udp_socket_input_callback_t receive_callback);
As the UDP socket has been created and registered, let us listen on a given port. Theudp_socket_bind function binds the UDP socket to a local port so it will begin to receivedata that arrives on the specified port. A UDP socket will receive data addressed to thespecified port number on any IP address of the host. A UDP socket bound to a local port willuse this port number as source port for outgoing UDP messages.
* \brief Bind a UDP socket to a local port
* \param c A pointer to the struct udp_socket that should be bound to a local
port
* \param local_port The UDP port number, in host byte order, to bind the UDP
socket to
* \retval -1 Binding the UDP socket to the local port failed
* \retval 1 Binding the UDP socket to the local port succeeded
*/
int udp_socket_bind(struct udp_socket *c,
uint16_t local_port);
The udp_socket_connect function connects the UDP socket to a specific remote port andoptional remote IP address. When a UDP socket is connected to a remote port and address, itwill only receive packets that are sent from that remote port and address. When sending dataover a connected UDP socket, the data will be sent to the connected remote address.
A UDP socket can be connected to a remote port, but not to a remote IP address, by providinga NULL parameter as the remote_addr parameter. This lets the UDP socket receive datafrom any IP address on the specified port.
/** * \brief Bind a UDP socket to a remote address and port * \param c A pointer to the struct udp_socket that should be connected * \param remote_addr The IP address of the remote host, or NULL if the UDP socket should only be connected to a specific port
The UDP API
103
* \param remote_port The UDP port number, in host byte order, to which the UDP socket should be connected * \retval -1 Connecting the UDP socket failed * \retval 1 Connecting the UDP socket succeeded */int udp_socket_connect(struct udp_socket *c,
uip_ipaddr_t *remote_addr,
uint16_t remote_port);
To send data over a connected UDP socket it must have been connected to a remote addressand port with udp_socket_connect .
/** * \brief Send data on a UDP socket * \param c A pointer to the struct udp_socket on which the data should be sent * \param data A pointer to the data that should be sent * \param datalen The length of the data to be sent * \return The number of bytes sent, or -1 if an error occurred */int udp_socket_send(struct udp_socket *c,
const void *data, uint16_t datalen);
To send data over a UDP socket without being connected we use the functionudp_socket_sendto instead.
/** * \brief Send data on a UDP socket to a specific address and port * \param c A pointer to the struct udp_socket on which the data should be sent * \param data A pointer to the data that should be sent * \param datalen The length of the data to be sent * \param addr The IP address to which the data should be sent * \param port The UDP port number, in host byte order, to which the data should be sent * \return The number of bytes sent, or -1 if an error occurred */int udp_socket_sendto(struct udp_socket *c,
const void *data, uint16_t datalen,
const uip_ipaddr_t *addr, uint16_t port);
To close a UDP socket previously registered with udp_socket_register the functionbelow is used. All registered UDP sockets must be closed before exiting the process thatregistered them, or undefined behavior may occur.
/**
Hands on: UDP example
104
* \brief Close a UDP socket * \param c A pointer to the struct udp_socket to be closed * \retval -1 If closing the UDP socket failed * \retval 1 If closing the UDP socket succeeded */int udp_socket_close(struct udp_socket *c);
Each UDP socket has a callback function that is registered as part of the call toudp_socket_register . The callback function gets called every time a UDP packet isreceived.
/** * \brief A UDP socket callback function * \param c A pointer to the struct udp_socket that received the data * \param ptr An opaque pointer that was specified when the UDP socket was registered with udp_socket_register() * \param source_addr The IP address from which the datagram was sent * \param source_port The UDP port number, in host byte order, from which the datagram was sent * \param dest_addr The IP address that this datagram was sent to * \param dest_port The UDP port number, in host byte order, that the datagram was sent to * \param data A pointer to the data contents of the UDP datagram * \param datalen The length of the data being pointed to by the data pointer */typedef void (* udp_socket_input_callback_t)(struct udp_socket *c,
void *ptr,
const uip_ipaddr_t *source_addr,
uint16_t source_port,
const uip_ipaddr_t *dest_addr,
uint16_t dest_port,
const uint8_t *data,
uint16_t datalen);
Alternatively there is another UDP library called simple-udp , which simplifies the UDP APIto fewer functions. The library is located in core/net/ip/simple-udp.c . For the nextexample we are going to use the simple-udp library, to show how to create a very firstbasic broadcast example. In a later example we will come back to the full-fledged UDP API.
4.4.2. Hands on: UDP example
The objective of this example is to grasp the concepts shown in the preceding sections. Wewill create a UDP broadcast application using the simple-udp .
There is a UDP broadcast example which uses RPL at:
Hands on: UDP example
105
cd examples/ipv6/simple-udp-rpl
Open the broadcast-example.c and the Makefile . Let’s see the contents of theMakefile :
UIP_CONF_IPV6=1
CFLAGS+= -DUIP_CONF_IPV6_RPL
The above adds the IPv6 stack and RPL routing protocol to our application.
The broadcast-example.c contains:
#include "net/ip/uip.h"
This is the main uIP library.
/* Network interface and stateless autoconfiguration */
#include "net/ipv6/uip-ds6.h"
/* Use simple-udp library, at core/net/ip/ */
/* The simple-udp module provides a significantly simpler API. */
#include "simple-udp.h"
static struct simple_udp_connection broadcast_connection;
This structure allows storing the UDP connection information and mapped callback in whichto process any received message. It is initialized in the following call:
simple_udp_register(&broadcast_connection, UDP_PORT, NULL, UDP_PORT, receiver);
This passes to the simple-udp application the ports from/to in charge of handling thebroadcasts, and the callback function to handle received broadcasts. We pass the NULLparameter as the destination address to allow packets from any address.
The receiver callback function is shown below:
receiver(struct simple_udp_connection *c,
const uip_ipaddr_t *sender_addr,
uint16_t sender_port,
const uip_ipaddr_t *receiver_addr,
uint16_t receiver_port,
const uint8_t *data,
Hands on: UDP example
106
uint16_t datalen);
This application first sets a timer and when the timer expires triggers a randomly generatednew timer interval (between 1 and the sending interval) to avoid flooding the network. Then itsets the IP address to the link local all-nodes multicast address as follows:
uip_create_linklocal_allnodes_mcast(&addr);
And then use the broadcast_connection structure (with the values passed at register)and send our data over UDP.
simple_udp_sendto(&broadcast_connection, "Test", 4, &addr);
To extend the available address information, there is a library which allows to print the IPv6addresses in a friendlier way, add this to the top of the file:
#include "debug.h"
#define DEBUG DEBUG_PRINT
#include "net/ip/uip-debug.h"
So we can now print the multicast address, add this before the simple_udp_sendto(… )
call:
PRINT6ADDR(&addr);
printf("\n");
Now let’s modify our receiver callback and print more information about the incoming message,replace the existing receiver code with the following:
static void
receiver(struct simple_udp_connection *c,
const uip_ipaddr_t *sender_addr,
uint16_t sender_port,
const uip_ipaddr_t *receiver_addr,
uint16_t receiver_port,
const uint8_t *data,
uint16_t datalen)
{
/* Modified to print extended information */
printf("\nData received from: ");
PRINT6ADDR(sender_addr);
Hands on: UDP example
107
printf("\nAt port %d from port %d with length %d\n",
receiver_port, sender_port, datalen);
printf("Data Rx: %s\n", data);
}
Before uploading your code, override the default target by writing in the terminal:
make TARGET=zoul savetarget
Remember you can also use the Z1 mote as target.
Now clean any previous compiled code, compile, upload your code, restart the mote and printthe serial output to screen (all in one command!):
make clean && make broadcast-example.upload && make login
Upload this code to at least 2 motes and send/receive messages fromtheir neighbors. If you have more than 1 mote connected in your PC,remember to use the PORT=/dev/ttyUSBx argument in the upload,reset and login commands!
You will see the following result:
Rime started with address 193.12.0.0.0.0.0.158
MAC c1:0c:00:00:00:00:00:9e Ref ID: 3301
Contiki-2.6-1803-g03f57ae started. Node id is set to 158.
CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:009e
Starting 'UDP broadcast example process'
Sending broadcast to -> ff02::1
Data received from: fe80::c30c:0:0:309
At port 1234 from port 1234 with length 4
Data Rx: Test
Sending broadcast to -> ff02::1
Exercise: Write down the node ID of other motes. This will be usefullater. At this point you should also use the Sniffer and capture data overWireshark.
To change the sending interval you can also modify the values at:
#define SEND_INTERVAL (20 * CLOCK_SECOND)
Hands on: connecting anIPv6 UDP network to our host
108
#define SEND_TIME (random_rand() % (SEND_INTERVAL))
4.4.3. Hands on: connecting an IPv6 UDP network to our host
In the udp-client.c file at examples/ipv6/rpl-udp . set the server address to beaaaa::1 (the host address), replace the options there (Mode 2 is default) and add:
uip_ip6addr(&server_ipaddr, 0xaaaa, 0, 0, 0, 0, 0, 0, 1);
To verify that we have set the address correctly let’s print the server address, in theprint_local_addresses function add this to the end:
PRINTF("Server address: ");
PRINT6ADDR(&server_ipaddr);
PRINTF("\n");
The UDP connection is created in the following block:
/* new connection with remote host */
client_conn = udp_new(NULL, UIP_HTONS(UDP_SERVER_PORT), NULL);
if(client_conn == NULL) {
PRINTF("No UDP connection available, exiting the process!\n");
PROCESS_EXIT();
}
udp_bind(client_conn, UIP_HTONS(UDP_CLIENT_PORT));
And upon receiving a message the tcpip_handler is called to process the incoming data:
static void
tcpip_handler(void)
{
char *str;
if(uip_newdata()) {
str = uip_appdata;
str[uip_datalen()] = '\0';
printf("DATA recv '%s'\n", str);
}
}
Compile and program the mote:
Hands on: connecting anIPv6 UDP network to our host
109
cd examples/ipv6/rpl-udp
make TARGET=z1 savetarget
make udp-client.upload && make z1-reset && make login
Rime started with address 193.12.0.0.0.0.0.158
MAC c1:0c:00:00:00:00:00:9e Ref ID: 158
Contiki-2.6-2071-gc169b3e started. Node id is set to 158.
CSMA ContikiMAC, channel check rate 8 Hz, radio channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:009e
Starting 'UDP client process'
UDP client process started
Client IPv6 addresses: aaaa::c30c:0:0:9e
fe80::c30c:0:0:9e
Server address: aaaa::1
Created a connection with the server :: local/remote port 8765/5678
DATA send to 1 'Hello 1'
DATA send to 1 'Hello 2'
DATA send to 1 'Hello 3'
DATA send to 1 'Hello 4'
Remember that you can also compile for the RE-Mote platform.
UDP Server
The UDP server is a python script that echoes any incoming data back to the client, useful totest the bi-directional communication between the host and the network.
The UDP6.py script can be executed as a single-shot UDP client or as a UDP Server boundto a specific address and port, for this example we are to bind to address aaaa::1 and port5678 .
The script content is below:
#! /usr/bin/env python
import sys
from socket import *
from socket import error
PORT = 5678
BUFSIZE = 1024
#------------------------------------------------------------#
# Start a client or server application for testing
#------------------------------------------------------------#
Hands on: connecting anIPv6 UDP network to our host
110
def main():
if len(sys.argv) < 2:
usage()
if sys.argv[1] == '-s':
server()
elif sys.argv[1] == '-c':
client()
else:
usage()
#------------------------------------------------------------#
# Prints the instructions
#------------------------------------------------------------#
def usage():
sys.stdout = sys.stderr
print 'Usage: udpecho -s [port] (server)'
print 'or: udpecho -c host [port] <file (client)'
sys.exit(2)
#------------------------------------------------------------#
# Creates a server, echoes the message back to the client
#------------------------------------------------------------#
def server():
if len(sys.argv) > 2:
port = eval(sys.argv[2])
else:
port = PORT
try:
s = socket(AF_INET6, SOCK_DGRAM)
s.bind(('aaaa::1', port))
except Exception:
print "ERROR: Server Port Binding Failed"
return
print 'udp echo server ready: %s' % port
while 1:
data, addr = s.recvfrom(BUFSIZE)
print 'server received', `data`, 'from', `addr`
s.sendto(data, addr)
#------------------------------------------------------------#
# Creates a client that sends an UDP message to a server
#------------------------------------------------------------#
def client():
if len(sys.argv) < 3:
usage()
host = sys.argv[2]
if len(sys.argv) > 3:
Hands on: connecting anIPv6 UDP network to our host
111
port = eval(sys.argv[3])
else:
port = PORT
addr = host, port
s = socket(AF_INET6, SOCK_DGRAM)
s.bind(('', 0))
print 'udp echo client ready, reading stdin'
try:
s.sendto("hello", addr)
except error as msg:
print msg
data, fromaddr = s.recvfrom(BUFSIZE)
print 'client received', `data`, 'from', `fromaddr`
#------------------------------------------------------------#
# MAIN APP
#------------------------------------------------------------#
main()
To execute the UDP6.py script just run:
python UDP6.py -s 5678
This is the expected output when running and receiving a UDP packet:
udp echo server ready: 5678
server received 'Hello 198 from the client' from ('aaaa::c30c:0:0:9e', 8765, 0, 0)
The Server then echoes back the message to the UDP client to the given 8765 port, this isthe expected output from the mote:
DATA send to 1 'Hello 198'
DATA recv 'Hello 198 from the client'
What is TCP?
112
Figure 4.15. Z1 mote talking to the PC host
4.4.4. What is TCP?
What is TCP?
The Transmission Control Protocol (TCP) is a core protocol of the Internet Protocol(IP).
TCP is a reliable stream delivery service that ensures that all bytes received willbe in the correct order. It uses a technique known as positive acknowledgment withretransmission to guarantee reliability of packet transfer. TCP handles the receivedfragments and reorders the data.
Applications that do not require reliable data stream service may use the UserDatagram Protocol (UDP), which provides a connectionless datagram service thatemphasizes reduced latency over reliability.
TCP is commonly used by HTTP, FTP, email and any connection-oriented service.
The TCP implementation is Contiki resides in core/net/ip . The remainder of the sectionwill focus on describing the TCP available functions.
The TCP API
We need to create a socket for the connection, this is done using the tcp_socket structure,which has the following elements:
What is TCP?
113
struct tcp_socket {
struct tcp_socket *next;
tcp_socket_data_callback_t input_callback;
tcp_socket_event_callback_t event_callback;
void *ptr;
struct process *p;
uint8_t *input_data_ptr;
uint8_t *output_data_ptr;
uint16_t input_data_maxlen;
uint16_t input_data_len;
uint16_t output_data_maxlen;
uint16_t output_data_len;
uint16_t output_data_send_nxt;
uint16_t output_senddata_len;
uint16_t output_data_max_seg;
uint8_t flags;
uint16_t listen_port;
struct uip_conn *c;
};
Socket status:
enum {
TCP_SOCKET_FLAGS_NONE = 0x00,
TCP_SOCKET_FLAGS_LISTENING = 0x01,
TCP_SOCKET_FLAGS_CLOSING = 0x02,
};
After creating the TCP socket structure, we need to register the TCP socket. This is done withthe tcp_socket_register , which takes as arguments the TCP socket, and input/outputbuffers to use for sending and receiving data. Be sure to dimension these buffers accordingto the expected amount of data to be sent and received.
/** * \brief Register a TCP socket * \param s A pointer to a TCP socket * \param ptr A user-defined pointer that will be sent to callbacks for this socket * \param input_databuf A pointer to a memory area this socket will use for input data * \param input_databuf_len The size of the input data buffer
What is TCP?
114
* \param output_databuf A pointer to a memory area this socket will use for outgoing data * \param output_databuf_len The size of the output data buffer * \param data_callback A pointer to the data callback function for this socket * \param event_callback A pointer to the event callback function for this socket * \retval -1 If an error occurs * \retval 1 If the operation succeeds. */int tcp_socket_register(struct tcp_socket *s, void *ptr,
uint8_t *input_databuf, int input_databuf_len,
uint8_t *output_databuf, int output_databuf_len,
tcp_socket_data_callback_t data_callback,
tcp_socket_event_callback_t event_callback);
As the TCP socket has been created and registered, let us listen on a given port.When a remote host connects to the port, the event callback will be called with theTCP_SOCKET_CONNECTED event. When the connection closes, the socket will go back tolistening.
/** * \brief Start listening on a specific port * \param s A pointer to a TCP socket that must have been previously registered with tcp_socket_register() * \param port The TCP port number, in host byte order, of the remote host * \retval -1 If an error occurs * \retval 1 If the operation succeeds. */int tcp_socket_listen(struct tcp_socket *s,
uint16_t port);
To stop listening on a given TCP port, just call the following function:
/** * \brief Stop listening for new connections * \param s A pointer to a TCP socket that must have been previously registered with tcp_socket_register() * \retval -1 If an error occurs * \retval 1 If the operation succeeds. */int tcp_socket_unlisten(struct tcp_socket *s);
We can connect the TCP socket to a remote host. When the socket has connected, the eventcallback will get called with the TCP_SOCKET_CONNECTED event. If the remote host doesnot accept the connection, the TCP_SOCKET_ABORTED will be sent to the callback. If the
What is TCP?
115
connection times out before conecting to the remote host, the TCP_SOCKET_TIMEDOUTevent is sent to the callback.
/** * \brief Connect a TCP socket to a remote host * \param s A pointer to a TCP socket that must have been previously registered with tcp_socket_register() * \param ipaddr The IP address of the remote host * \param port The TCP port number, in host byte order, of the remote host * \retval -1 If an error occurs * \retval 1 If the operation succeeds. */int tcp_socket_connect(struct tcp_socket *s,
const uip_ipaddr_t *ipaddr,
uint16_t port);
As we are using an output buffer to send data over the TCP socket, a good practice is to querythe TCP socket and check the number of bytes available.
/** * \brief The maximum amount of data that could currently be sent * \param s A pointer to a TCP socket * \return The number of bytes available in the output buffer */int tcp_socket_max_sendlen(struct tcp_socket *s);
To send data over a connected TCP socket the data is placed in the output buffer. Whenthe data has been acknowledged by the remote host, the event callback is sent with theTCP_SOCKET_DATA_SENT event.
/** * \brief Send data on a connected TCP socket * \param s A pointer to a TCP socket that must have been previously registered with tcp_socket_register() * \param dataptr A pointer to the data to be sent * \param datalen The length of the data to be sent * \retval -1 If an error occurs * \return The number of bytes that were successfully sent */int tcp_socket_send(struct tcp_socket *s,
const uint8_t *dataptr,
int datalen);
What is TCP?
116
Alternatively we can send a string over a TCP socket as follows:
/** * \brief Send a string on a connected TCP socket * \param s A pointer to a TCP socket that must have been previously registered with tcp_socket_register() * \param strptr A pointer to the string to be sent * \retval -1 If an error occurs * \return The number of bytes that were successfully sent */int tcp_socket_send_str(struct tcp_socket *s,
const char *strptr);
To close a connected TCP socket the function below is used. The event callback is called withthe TCP_SOCKET_CLOSED event.
/** * \brief Close a connected TCP socket * \param s A pointer to a TCP socket that must have been previously registered with tcp_socket_register() * \retval -1 If an error occurs * \retval 1 If the operation succeeds. */int tcp_socket_close(struct tcp_socket *s);
And to unregister a TCP socket the tpc_socket_unregister function is used. Thisfunction can also be used to reset a connected TCP socket.
/** * \brief Unregister a registered socket * \param s A pointer to a TCP socket that must have been previously registered with tcp_socket_register() * \retval -1 If an error occurs * \retval 1 If the operation succeeds. * * This function unregisters a previously registered * socket. This must be done if the process will be * unloaded from memory. If the TCP socket is connected, * the connection will be reset. * */int tcp_socket_unregister(struct tcp_socket *s);
What is TCP?
117
The TCP socket event callback function gets called whenever there is an event on a socket,such as the socket getting connected or closed.
/** * \brief TCP event callback function * \param s A pointer to a TCP socket * \param ptr A user-defined pointer * \param event The event number */typedef void (* tcp_socket_event_callback_t)(struct tcp_socket *s,
void *ptr,
tcp_socket_event_t event);
The TCP data callback function has to be added to the application, it will get called wheneverthere is new data on the socket:
/** * \brief TCP data callback function * \param s A pointer to a TCP socket * \param ptr A user-defined pointer * \param input_data_ptr A pointer to the incoming data * \param input_data_len The length of the incoming data * \return The function should return the number of bytes to leave in the input buffer */typedef int (* tcp_socket_data_callback_t)(struct tcp_socket *s,
void *ptr,
const uint8_t *input_data_ptr,
int input_data_len);
Hands on: TCP example
Now let us put to practice the TCP API described before and browse a TCP application.The tpc-socket example is located in examples/tcp-socket . The TCP server simplyechoes back the request done on port 80.
The Makefile enables as default the IPv4 stack, change it to IPv6:
UIP_CONF_IPV6=1
CFLAGS+= -DUIP_CONF_IPV6_RPL
Then let us open the tcp-server.c example and browse the implementation.
What is TCP?
118
The port 80 will be used for the TCP server to receive remote connections. As shown earlierwe need to create a tcp_socket structure, and use two separate input/output buffers tosend and receive data.
#define SERVER_PORT 80
static struct tcp_socket socket;
#define INPUTBUFSIZE 400
static uint8_t inputbuf[INPUTBUFSIZE];
#define OUTPUTBUFSIZE 400
static uint8_t outputbuf[OUTPUTBUFSIZE];
These two variables will be used to count the number of bytes received, and the bytes to besent.
static uint8_t get_received;
static int bytes_to_send;
As commented earlier, we need to include a tcp_socket_event_callback_t to handleevents.
static void
event(struct tcp_socket *s, void *ptr,
tcp_socket_event_t ev)
{
printf("event %d\n", ev);
}
We register the TCP socket and pass as a pointer the tcp_socket structure, the data buffersand our callback handlers. Next we start listening for connections on port 80.
tcp_socket_register(&socket, NULL,
inputbuf, sizeof(inputbuf),
outputbuf, sizeof(outputbuf),
input, event);
tcp_socket_listen(&socket, SERVER_PORT);
The input callback handler receives the data, prints the string and its length, then ifthe received string is a complete request we save the number of bytes received into
What is TCP?
119
bytes_to_send (the atoi function converts string numbers into integers). If the receivedstring is not complete, we return the number of bytes received to the driver to keep the datain the input buffer.
static int
input(struct tcp_socket *s, void *ptr,
const uint8_t *inputptr, int inputdatalen)
{
printf("input %d bytes '%s'\n", inputdatalen, inputptr);
if(!get_received) {
/* See if we have a full GET request in the buffer. */
if(strncmp((char *)inputptr, "GET /", 5) == 0 &&
atoi((char *)&inputptr[5]) != 0) {
bytes_to_send = atoi((char *)&inputptr[5]);
printf("bytes_to_send %d\n", bytes_to_send);
return 0;
}
printf("inputptr '%.*s'\n", inputdatalen, inputptr);
/* Return the number of data bytes we received, to keep them all
in the buffer. */
return inputdatalen;
} else {
/* Discard everything */
return 0; /* all data consumed */
}
}
The application will wait for an event to happen, in this case the incoming connectionfrom above. After the event is handled, the code inside the while() loop and after thePROCESS_PAUSE() will be executed.
while(1) {
PROCESS_PAUSE();
If we have previously received a complete request, we echo it back over the TCP socket. Weuse the tcp_socket_send_str function to send the header of the response as a string.The remainder of the data is sent until the bytes_to_send counter is empty.
if(bytes_to_send > 0) {
/* Send header */
printf("sending header\n");
tcp_socket_send_str(&socket, "HTTP/1.0 200 ok\r\nServer: Contiki tcp-socket
example\r\n\r\n");
What is TCP?
120
/* Send data */
printf("sending data\n");
while(bytes_to_send > 0) {
PROCESS_PAUSE();
int len, tosend;
tosend = MIN(bytes_to_send, sizeof(outputbuf));
len = tcp_socket_send(&socket, (uint8_t *)"", tosend);
bytes_to_send -= len;
}
tcp_socket_close(&socket);
}
}
PROCESS_END();
}
When all the data is echoed back, the TCP socket is closed.
121
Chapter 5. CoAP, MQTT and HTTPIn the previous section we covered some of the wireless basic, we should now have a goodidea about working with Contiki. This section introduces two widely used protocols for the IoT:CoAP and MQTT. We will explain the basics and wrap up with ready to use examples.
5.1. CoAP exampleThe CoAP implementation in Contiki is based on Erbium (Er), a low-power REST Engine forContiki. The REST Engine includes a comprehensive embedded CoAP implementation, whichbecame the official one in Contiki.
More information about its implementation and author is available in the Erbium site1 .
What are REST and CoAP?
The Representational State Transfer (REST) relies on a stateless, client-server,cacheable communications protocol - and in virtually all cases, the HTTP protocol canbe used.
The key abstraction of a RESTful web service is the resource, not a service. Sensors,actuators and control systems in general can be elegantly represented as resourcesand their service exposed through a RESTful web service.
RESTful applications use HTTP-like requests to post data (create and/or update), readdata (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD(Create/Read/Update/Delete) operations.
Despite being simple, REST is fully-featured; there’s basically nothing you can do inweb services that can’t be done with a RESTful architecture. REST is not a standard.
The Constrained Application Protocol (CoAP) is a software intended to be usedin very simple electronics devices that allows them to communicate interactively overthe Internet. It is particularly targeted for small, low power sensors, switches, valvesand similar components that need to be controlled or supervised remotely, throughstandard Internet networks. CoAP is an application layer protocol that is intended foruse in resource-constrained internet devices, such as WSN nodes. CoAP is designed
1 http://people.inf.ethz.ch/mkovatsc/erbium.php
CoAP API
122
to easily translate to HTTP for simplified integration with the web, while also meetingspecialized requirements such as multicast support, very low overhead and simplicity.
CoAP can run on most devices that support UDP. CoAP makes use of two messagetypes, requests and responses, using a simple binary base header format. The baseheader may be followed by options in an optimized Type-Length-Value format. CoAP isby default bound to UDP and optionally to DTLS (Datagram Transport Layer Security),providing a high level of communications security.
Any bytes after the headers in the packet are considered the message body (if any ispresent). The length of the message body is implied by the datagram length. Whenbound to UDP the entire message MUST fit within a single datagram. When used with6LoWPAN as defined in RFC 4944, messages should fit into a single IEEE 802.15.4frame to minimize fragmentation.
5.1.1. CoAP API
The CoAP implementation in Contiki is located in apps/er-coap . The Erbium REST engineis implemented in apps/rest-engine .
The coap engine (currently the CoAP-18 version) is implemented in er-coap-engine.c .The engine interface is provided by the following structure:
const struct rest_implementation coap_rest_implementation = {
coap_init_engine,
coap_set_service_callback,
coap_get_header_uri_path,
(...)
}
It is possible then to invoke the CoAP engine as follows:
REST.get_query_variable();
Web services are viewed as resources, and can be uniquely identified by their URLs. Thebasic REST design uses the HTTP or COAP protocol methods for typical CRUD operations(create, read, update, delete):
• POST: Create a resource
• GET: Retrieve a resource
CoAP API
123
• PUT: Update a resource
• DELETE: Delete a resource
There are various resources that are available at the server. Each resource at the server hasa handler function which the REST layer calls to serve the client’s request. The REST serversends the response back to the client with the contents of the resource requested.
The following macros are available in apps/rest-engine , recommended when creatinga new CoAP resource.
A normal resource is defined by a static Uri-Path that is associated with a resource handlerfunction. This is the basis for all other resource types.
#define RESOURCE(name, attributes, get_handler, post_handler, put_handler,
delete_handler) \
resource_t name = { NULL, NULL, NO_FLAGS, attributes, get_handler, post_handler,
put_handler, delete_handler, { NULL } }
A parent resource manages several sub-resources by evaluating the Uri-Path, which maybe longer than the parent resource.
#define PARENT_RESOURCE(name, attributes, get_handler, post_handler, put_handler,
delete_handler) \
resource_t name = { NULL, NULL, HAS_SUB_RESOURCES, attributes, get_handler,
post_handler, put_handler, delete_handler, { NULL } }
If the server is not able to respond immediately to a CON request, it simply responds withan empty ACK message so that the client can stop re-transmitting the request. After a while,when the server is ready with the response, it sends the response as a CON message. Thefollowing macro allows to create a CoAP resource with separate response:
#define SEPARATE_RESOURCE(name, attributes, get_handler, post_handler, put_handler,
delete_handler, resume_handler) \
resource_t name = { NULL, NULL, IS_SEPARATE, attributes, get_handler,
post_handler, put_handler, delete_handler, { .resume = resume_handler } }
An event resource is similar to a periodic resource, but the second handler is called by a nonperiodic event such as the pressing of a button.
#define EVENT_RESOURCE(name, attributes, get_handler, post_handler, put_handler,
delete_handler, event_handler) \
CoAP API
124
resource_t name = { NULL, NULL, IS_OBSERVABLE, attributes, get_handler,
post_handler, put_handler, delete_handler, { .trigger = event_handler } }
If we need to declare a periodic resource, for example to poll a sensor and publish a changedvalue to subscribed clients, then we should use:
#define PERIODIC_RESOURCE(name, attributes, get_handler, post_handler, put_handler,
delete_handler, period, periodic_handler) \
periodic_resource_t periodic_##name; \
resource_t name = { NULL, NULL, IS_OBSERVABLE | IS_PERIODIC, attributes,
get_handler, post_handler, put_handler, delete_handler, { .periodic =
&periodic_##name } }; \
periodic_resource_t periodic_##name = { NULL, &name, period, { { 0 } },
periodic_handler };
Notice that the PERIODIC_RESOURCE and EVENT_RESOURCE can be observable, meaninga client can be notified of any change in a given resource.
Once we declare and implement the resources (we will get to that in the Hands On section),we need to initialize the REST framework and start the HTTP or CoAP process. This is doneusing:
void rest_init_engine(void);
Then for each declared resource we want to be accessible, we need to call:
void rest_activate_resource(resource_t *resource, char *path);
So assume we have created a hello-world resource in res-hello.c , declared asfollows:
RESOURCE(res_hello,
"title=\"Hello world: ?len=0..\";rt=\"Text\"",
res_get_handler,
NULL,
NULL,
NULL);
To enable the resource we would do:
rest_activate_resource(&res_hello, "test/hello");
Hands on: CoAP server and Copper
125
Which means the resource would be available at test/hello uri-Path.
The function above stores the resources into a list. To list the available resources, therest_get_resources function is used. This will return a list with the resources with thefollowing:
rest_get_resources();
Remember that the mandatory CoAP port is 5683 .
Now let us put the above to work in the following hands on example.
5.1.2. Hands on: CoAP server and Copper
First get the Copper (Cu) CoAP user-agent2 .
Copper is a generic browser for the Internet of Things based on the Constrained ApplicationProtocol (CoAP), a user-friendly management tool for networked embedded devices. As it isintegrated into web browsers, it allows an intuitive interaction at the presentation layer makingit easier to debug existing CoAP devices.
More information available at Copper page3
For this exercise we will use 2 motes: a Border Router and a CoAP server.
If you are using the Z1 motes, ensure that the motes you will be using totest this (border router, server, client) have been flashed with a node IDto generate the MAC/IPv6 addresses as done in previous sessions, besure to write down the addresses! Another thing, if you get an error likethe following, go to platform/z1/contiki-conf.h and changeUIP_CONF_BUFFER_SIZE to 240:
#error "UIP_CONF_BUFFER_SIZE too small for REST_MAX_CHUNK_SIZE"
make: *** [obj_z1/er-coap-07-engine.o] Error 1
In the Makefile we can notice two things: the resources folder is included as a projectdirectory, and all the resources files are added in the compilation.
2 https://addons.mozilla.org/en-US/firefox/addon/copper-270430/3 http://people.inf.ethz.ch/mkovatsc/copper.php
Hands on: CoAP server and Copper
126
REST_RESOURCES_DIR = ./resources
REST_RESOURCES_FILES = $(notdir $(shell find $(REST_RESOURCES_DIR) -name '*.c' ! -
name 'res-plugtest*'))
PROJECTDIRS += $(REST_RESOURCES_DIR)
PROJECT_SOURCEFILES += $(REST_RESOURCES_FILES)
We are including the er-coap and rest-engine applications.
# REST Engine shall use Erbium CoAP implementation
APPS += er-coap
APPS += rest-engine
Remove the following to avoid collisions as much as possible:
#undef NETSTACK_CONF_MAC
#define NETSTACK_CONF_MAC nullmac_driver
Next, let us check the project-conf.h relevant configuration. First we make sure TCP isdisabled, as CoAP is based on UDP.
/* Disabling TCP on CoAP nodes. */
#undef UIP_CONF_TCP
#define UIP_CONF_TCP 0
The REST_MAX_CHUNK_SIZE is the maximum buffer size that is provided for resourceresponses. Larger data should be handled by the resource and be sent in CoAP blocks. TheCOAP_MAX_OPEN_TRANSACTIONS is the number of maximum open transactions the nodeis able to handle.
/* Increase rpl-border-router IP-buffer when using more than 64. */
#undef REST_MAX_CHUNK_SIZE
#define REST_MAX_CHUNK_SIZE 48
/* Multiplies with chunk size, be aware of memory constraints. */
#undef COAP_MAX_OPEN_TRANSACTIONS
#define COAP_MAX_OPEN_TRANSACTIONS 4
/* Filtering .well-known/core per query can be disabled to save space. */
#undef COAP_LINK_FORMAT_FILTERING
#define COAP_LINK_FORMAT_FILTERING 0
#undef COAP_PROXY_OPTION_PROCESSING
Hands on: CoAP server and Copper
127
#define COAP_PROXY_OPTION_PROCESSING 0
/* Enable client-side support for COAP observe */
#define COAP_OBSERVE_CLIENT 1
CoAP Server:
Let us walk through the er-example-server.c example and understand itsimplementation. The first thing we notice is the presence of a folder called resources. Tofacilitate debugging and maintenance the resources are implemented in a different file.
The resources to be included in the CoAP server are defined in the following declaration:
extern resource_t
res_hello,
res_mirror,
res_chunks,
res_separate,
res_push,
res_event,
res_sub,
res_b1_sep_b2;
#if PLATFORM_HAS_LEDS
extern resource_t res_leds, res_toggle;
#endif
#if PLATFORM_HAS_BATTERY
#include "dev/battery-sensor.h"
extern resource_t res_battery;
#endif
#if PLATFORM_HAS_RADIO
#include "dev/radio-sensor.h"
extern resource_t res_radio;
#endif
The resources wrapped inside the PLATFORM_HAS_X are dependant on the target platform,and will get pulled-in if the platform has those enabled.
Then the REST engine is initialized by calling the rest_init_engine() , and the enabledresources are bound:
/* Initialize the REST engine. */
rest_init_engine();
/*
Hands on: CoAP server and Copper
128
* Bind the resources to their Uri-Path.
* WARNING: Activating twice only means alternate path, not two instances!
* All static variables are the same for each URI path.
*/
rest_activate_resource(&res_hello, "test/hello");
rest_activate_resource(&res_push, "test/push");
rest_activate_resource(&res_event, "sensors/button"); */
#if PLATFORM_HAS_LEDS
rest_activate_resource(&res_toggle, "actuators/toggle");
#endif
(...)
Now let us take a look at the res-hello.c resource, which implements a "hello world" fortesting.
As shown before resources are defined using the RESOURCE macro, for this particularimplementation we specify the resource name as res_hello , the link-formatted attributesand the GET callback handler. The POST , PUT , and DELETE methods are not supportedby this resource, so a NULL parameter is used as argument.
RESOURCE(res_hello,
"title=\"Hello world: ?len=0..\";rt=\"Text\"",
res_get_handler,
NULL,
NULL,
NULL);
The res_get_handler is the event callback for GET requests:
static void
res_get_handler(void *request, void *response, uint8_t *buffer, uint16_t
preferred_size, int32_t *offset)
{
const char *len = NULL;
/* Some data that has the length up to REST_MAX_CHUNK_SIZE. For more, see the
chunk resource. */
char const *const message = "Hello World!
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxy";
int length = 12;
/* The query string can be retrieved by rest_get_query() or parsed for its key-
value pairs. */
if(REST.get_query_variable(request, "len", &len)) {
length = atoi(len);
Hands on: CoAP server and Copper
129
if(length < 0) {
length = 0;
}
if(length > REST_MAX_CHUNK_SIZE) {
length = REST_MAX_CHUNK_SIZE;
}
memcpy(buffer, message, length);
} else {
memcpy(buffer, message, length);
/* text/plain is the default, hence this option could be omitted. */
} REST.set_header_content_type(response, REST.type.TEXT_PLAIN);
REST.set_header_etag(response, (uint8_t *)&length, 1);
REST.set_response_payload(response, buffer, length);
}
The default lenght of the reply, in this case from the complete string, only HelloWorld! will be sentIf the len option is specified, then a number of len bytes of the message string willbe sentIf the value is a negative one, send an empty string
If len is higher than the maximum allowed, then we only send the maximum lenght valueCopy the default
Set the response content type as Content-Type:text/plainAttach the header to the response, set the payload lenght field
Attach the payload to the response
Be sure that the settings are consistent with the ones of the border router
In the project-conf.h file add the following for this purpose:
#undef NETSTACK_CONF_RDC
#define NETSTACK_CONF_RDC nullrdc_driver
Then compile and upload:
cd examples/er-rest-example/
make TARGET=zoul savetarget
Hands on: CoAP server and Copper
130
make er-example-server.upload && make login
Write down the IPv6 server address.
Disconnect the mote, connect another one to be used as border-router:
Border-Router:
cd ../ipv6/rpl-border-router/
make TARGET=z1 savetarget
make border-router.upload && make connect-router
Or use also:
make TARGET=zoul savetarget && make border-router.upload && make connect-router
Don’t close this window! leave the mote connected, now you will be seeing something like this:
SLIP started on ``/dev/ttyUSB0''
opened tun device ``/dev/tun0''
ifconfig tun0 inet `hostname` up
ifconfig tun0 add aaaa::1/64
ifconfig tun0 add fe80::0:0:0:1/64
ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:127.0.1.1 P-t-P:127.0.1.1 Mask:255.255.255.255
inet6 addr: fe80::1/64 Scope:Link
inet6 addr: aaaa::1/64 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Rime started with address 193.12.0.0.0.0.3.229
MAC c1:0c:00:00:00:00:03:e5 Contiki-2.5-release-681-gc5e9d68 started. Node id
is set to 997.
CSMA nullrdc, channel check rate 128 Hz, radio channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:03e5
Starting 'Border router process' 'Web server'
Address:aaaa::1 => aaaa:0000:0000:0000
Got configuration message of type P
Setting prefix aaaa::
Hands on: CoAP server and Copper
131
Server IPv6 addresses:
aaaa::c30c:0:0:3e5
fe80::c30c:0:0:3e5
Let’s ping the border router:
ping6 aaaa:0000:0000:0000:c30c:0000:0000:03e5
PING aaaa:0000:0000:0000:c30c:0000:0000:03e5(aaaa::c30c:0:0:3e5) 56 data bytes
64 bytes from aaaa::c30c:0:0:3e5: icmp_seq=1 ttl=64 time=21.0 ms
64 bytes from aaaa::c30c:0:0:3e5: icmp_seq=2 ttl=64 time=19.8 ms
64 bytes from aaaa::c30c:0:0:3e5: icmp_seq=3 ttl=64 time=22.2 ms
64 bytes from aaaa::c30c:0:0:3e5: icmp_seq=4 ttl=64 time=20.7 ms
Now connect the server mote, ping it too:
ping6 aaaa:0000:0000:0000:c30c:0000:0000:0001
PING aaaa:0000:0000:0000:c30c:0000:0000:0001(aaaa::c30c:0:0:1) 56 data bytes
64 bytes from aaaa::c30c:0:0:1: icmp_seq=1 ttl=63 time=40.3 ms
64 bytes from aaaa::c30c:0:0:1: icmp_seq=2 ttl=63 time=34.2 ms
64 bytes from aaaa::c30c:0:0:1: icmp_seq=3 ttl=63 time=35.7 ms
We can start discovering the server resources, open Firefox and type the server address:
coap://[aaaa::c30c:0000:0000:0001]:5683/
Start discovering the available resources, press DISCOVER and the page will be populatedin the left side
If you select the toggle resource and use POST you can see how the red LED of the servermote will toggle
If you do the same with the Hello resource, the server will answer you back with aneighbourly well-known message
If, instead, you select the Sensors → Button event and click OBSERVE , each time youpress the user button an event will be triggered and reported back
Finally if you go to the er-example-server.c file and enable the following defines, youshould have more resources available:
#define REST_RES_HELLO 1
Hands on: CoAP server and Copper
132
#define REST_RES_SEPARATE 1
#define REST_RES_PUSHING 1
#define REST_RES_EVENT 1
#define REST_RES_SUB 1
#define REST_RES_LEDS 1
#define REST_RES_TOGGLE 1
#define REST_RES_BATTERY 1
#define REST_RES_RADIO 1
And now to get the current RSSI level on the transceiver:
coap://[aaaa::c30c:0000:0000:0001]:5683/sensor/radio?p=rssi
Do the same to get the battery level readings:
coap://[aaaa::c30c:0000:0000:0001]:5683/sensors/battery
This last case returns the ADC units when the mote is connected to the USB, the actual valuein millivolts would be:
V [mV] = (units * 5000)/4096
Let’s say you want to turn the green LED on, in the URL type:
coap://[aaaa::c30c:0000:0000:0001]:5683/actuators/leds?color=g
And then in the payload (the ongoing tab) write:
mode="on"
And press POST or PUT (hover with the mouse over the actuators/leds to see the descriptionand methods allowed).
MQTT example
133
Figure 5.1. Copper CoAP plugin Screenshot
5.2. MQTT example
What is MQTT?
MQTT (formerly MQ Telemetry Transport) is a publish-subscribe based messagingprotocol on top of the TCP/IP protocol. It is designed for connections with remotelocations where a "small code footprint" is required or where the network bandwidthis limited.
The publish-subscribe messaging pattern requires a message broker. The broker isresponsible for distributing messages to interested clients based on the topic of amessage.
Figure 5.2. MQTT publish/suscribe
MQTT API
134
MQTT has defined three levels of Quality of Service (QoS):
• QoS 0: The broker/client will deliver the message once, with no confirmation (fireand forget)
• QoS 1: The broker/client will deliver the message at least once, with confirmationrequired.
• QoS 3: The broker/client will deliver the message exactly once by using a four-stephandshake.
Other features of MQTT are:
• Keep-Alive message (PINGREQ, PINGRESP).
• A broker can detect client disconnection, even without an explicit DISCONNECTmessage.
• “Last Will and Testament” message: specified in CONNECT message with topic,QoS and retain. On unexpected client disconnection, the “Last Will and Testament”message is sent to subscribed clients.
• “Retain” message: a PUBLISH message on a topic is kept on the broker whichallows a new connected subscriber on the same topic to receive this message (lastknown good message).
• “Durable” subscription: on client disconnection, all subscriptions are kept on thebroker and recovered on client reconnection.
MQTT reserves TCP/IP port 1883 and 8883, the later for using MQTT over SSL.
For more complete information visit the MQTT page4 .
5.2.1. MQTT API
MQTT is implemented in Contiki in apps/mqtt . It makes use of the tcp-socket librarydiscussed in an earlier section.
The current MQTT version implemented in Contiki supports QoS levels 0 and 1.
The MQTT available functions are described next. A hands on example in the next sectionwill help to clarify its use and suggest a state-machine approach to maintain the connectionstate and device operation.
4 http://mqtt.org/
MQTT API
135
This function initializes the MQTT engine and shall be called before any other MQTT function.
/** * \brief Initializes the MQTT engine. * \param conn A pointer to the MQTT connection. * \param app_process A pointer to the application process handling the MQTT * connection. * \param client_id A pointer to the MQTT client ID. * \param event_callback Callback function responsible for handling the * callback from MQTT engine. * \param max_segment_size The TCP segment size to use for this MQTT/TCP * connection. * \return MQTT_STATUS_OK or MQTT_STATUS_INVALID_ARGS_ERROR */mqtt_status_t mqtt_register(struct mqtt_connection *conn,
struct process *app_process,
char *client_id,
mqtt_event_callback_t event_callback,
uint16_t max_segment_size);
This function connects to an MQTT broker.
/** * \brief Connects to a MQTT broker. * \param conn A pointer to the MQTT connection. * \param host IP address of the broker to connect to. * \param port Port of the broker to connect to, default is MQTT port is 1883. * \param keep_alive Keep alive timer in seconds. Used by broker to handle * client disc. Defines the maximum time interval between two messages * from the client. Shall be min 1.5 x report interval. * \return MQTT_STATUS_OK or an error status */mqtt_status_t mqtt_connect(struct mqtt_connection *conn,
char *host,
uint16_t port,
uint16_t keep_alive);
This function disconnects from an MQTT broker.
/** * \brief Disconnects from a MQTT broker. * \param conn A pointer to the MQTT connection. */void mqtt_disconnect(struct mqtt_connection *conn);
MQTT API
136
This function subscribes to a topic on an MQTT broker.
/** * \brief Subscribes to a MQTT topic. * \param conn A pointer to the MQTT connection. * \param mid A pointer to message ID. * \param topic A pointer to the topic to subscribe to. * \param qos_level Quality Of Service level to use. Currently supports 0, 1. * \return MQTT_STATUS_OK or some error status */mqtt_status_t mqtt_subscribe(struct mqtt_connection *conn,
uint16_t *mid,
char *topic,
mqtt_qos_level_t qos_level);
This function unsubscribes from a topic on an MQTT broker.
/** * \brief Unsubscribes from a MQTT topic. * \param conn A pointer to the MQTT connection. * \param mid A pointer to message ID. * \param topic A pointer to the topic to unsubscribe from. * \return MQTT_STATUS_OK or some error status */mqtt_status_t mqtt_unsubscribe(struct mqtt_connection *conn,
uint16_t *mid,
char *topic);
This function publishes to a topic on an MQTT broker.
/** * \brief Publish to a MQTT topic. * \param conn A pointer to the MQTT connection. * \param mid A pointer to message ID. * \param topic A pointer to the topic to subscribe to. * \param payload A pointer to the topic payload. * \param payload_size Payload size. * \param qos_level Quality Of Service level to use. Currently supports 0, 1. * \param retain If the RETAIN flag is set to 1, in a PUBLISH Packet sent by a * Client to a Server, the Server MUST store the Application Message * and its QoS, so that it can be delivered to future subscribers whose * subscriptions match its topic name * \return MQTT_STATUS_OK or some error status */
MQTT API
137
mqtt_status_t mqtt_publish(struct mqtt_connection *conn,
uint16_t *mid,
char *topic,
uint8_t *payload,
uint32_t payload_size,
mqtt_qos_level_t qos_level,
mqtt_retain_t retain);
This function sets clients user name and password to use when connecting to an MQTT broker.
/** * \brief Set the user name and password for a MQTT client. * \param conn A pointer to the MQTT connection. * \param username A pointer to the user name. * \param password A pointer to the password. */void mqtt_set_username_password(struct mqtt_connection *conn,
char *username,
char *password);
This function sets clients Last Will topic and message (payload). If the Will Flag is set to 1(using the function) this indicates that, if the Connect request is accepted, a Will MessageMUST be stored on the server and associated with the Network Connection. The Will MessageMUST be published when the Network Connection is subsequently closed
This functionality can be used to get notified that a device has disconnected from the broker.
/** * \brief Set the last will topic and message for a MQTT client. * \param conn A pointer to the MQTT connection. * \param topic A pointer to the Last Will topic. * \param message A pointer to the Last Will message (payload). * \param qos The desired QoS level. */void mqtt_set_last_will(struct mqtt_connection *conn,
char *topic,
char *message,
mqtt_qos_level_t qos);
The following helper functions can be ussed to assert the MQTT connection status, to checkif the mote is connected to the broker with mqtt_connected , and with mqtt_ready if theconnection is estabished and there is space in the buffer to publish.
Hands on: MQTT and mosquitto
138
#define mqtt_connected(conn) \
((conn)->state == MQTT_CONN_STATE_CONNECTED_TO_BROKER ? 1 : 0)
#define mqtt_ready(conn) \
(!(conn)->out_queue_full && mqtt_connected((conn)))
5.2.2. Hands on: MQTT and mosquitto
Now let’s build a simple example using mosquitto5 MQTT broker v.3.1 running in our host asan MQTT Broker, in the following setup:
Figure 5.3. MQTT with Mosquitto
The mosquitto installation is quite straightforward, the installation instructions are available inthe mosquitto website6 . For this example we use the default configurations.
Instructions to compile the Border Router are available in previous sections.
We will use the example available at examples/cc2538dk/mqtt-demo . With minortweaks (like removing the cc2538-specific code) it should also work for the Z1 mote.
The example is heavily based on the IBM quickstart format. For more information about thischeck out the README file, or read the IBM MQTT doc7 .
In the project-conf.h file the IPv6 broker address is defined as follows:
#define MQTT_DEMO_BROKER_IP_ADDR "aaaa::1"
5 http://mosquitto.org/6 http://mosquitto.org/2013/01/mosquitto-debian-repository/7 https://docs.internetofthings.ibmcloud.com/messaging/applications.html
Hands on: MQTT and mosquitto
139
As default the mosquitto broker binds to the IPv4//IPv6 address of the host, ifusing the tunslip6 script with the aaaa::1/64 address, it should match theMQTT_DEMO_BROKER_IP_ADDR definition.
Remember that some examples are platform specific, so you shouldcheck if there is a Makefile.target predefined, or if the TARGETis defined elsewhere.
The example does the following:
• Publish information to an MQTT broker.
• Subscribe to a topic and receive commands from an MQTT broker.
Note also that the PUBLISH_TRIGGER is mapped to the user button, so it can be used totrigger a publish event.
The data structure for the MQTT client configuration is declared as:
typedef struct mqtt_client_config {
char org_id[CONFIG_ORG_ID_LEN];
char type_id[CONFIG_TYPE_ID_LEN];
char auth_token[CONFIG_AUTH_TOKEN_LEN];
char event_type_id[CONFIG_EVENT_TYPE_ID_LEN];
char broker_ip[CONFIG_IP_ADDR_STR_LEN];
char cmd_type[CONFIG_CMD_TYPE_LEN];
clock_time_t pub_interval;
int def_rt_ping_interval;
uint16_t broker_port;
} mqtt_client_config_t;
Unique organization ID
Device type
Authorization token (if required)
Default event type
Broker IPv6 address
Default command type
Publish interval period
Periodically ping the parent and retrieve RSSI value
Broker default port, default is 1883
Hands on: MQTT and mosquitto
140
Later defined and populate as follows:
static mqtt_client_config_t conf;
static int
init_config()
{
/* Populate configuration with default values */
memset(&conf, 0, sizeof(mqtt_client_config_t));
memcpy(conf.org_id, DEFAULT_ORG_ID, strlen(DEFAULT_ORG_ID));
memcpy(conf.type_id, DEFAULT_TYPE_ID, strlen(DEFAULT_TYPE_ID));
memcpy(conf.auth_token, DEFAULT_AUTH_TOKEN, strlen(DEFAULT_AUTH_TOKEN));
memcpy(conf.event_type_id, DEFAULT_EVENT_TYPE_ID,
strlen(DEFAULT_EVENT_TYPE_ID));
memcpy(conf.broker_ip, broker_ip, strlen(broker_ip));
memcpy(conf.cmd_type, DEFAULT_SUBSCRIBE_CMD_TYPE, 1);
conf.broker_port = DEFAULT_BROKER_PORT;
conf.pub_interval = DEFAULT_PUBLISH_INTERVAL;
conf.def_rt_ping_interval = DEFAULT_RSSI_MEAS_INTERVAL;
return 1;
}
The application example itself can be understood as a finite state machine, although it seemscomplicated it is actually very straightforward. The mqtt_demo_process starts as follows:
PROCESS_THREAD(mqtt_demo_process, ev, data)
{
PROCESS_BEGIN();
if(init_config() != 1) {
PROCESS_EXIT();
}
update_config();
uip_icmp6_echo_reply_callback_add(&echo_reply_notification,
echo_reply_handler);
etimer_set(&echo_request_timer, conf.def_rt_ping_interval);
while(1) {
PROCESS_YIELD();
if(ev == sensors_event && data == PUBLISH_TRIGGER) {
if(state == STATE_ERROR) {
Hands on: MQTT and mosquitto
141
connect_attempt = 1;
state = STATE_REGISTERED;
}
}
if((ev == PROCESS_EVENT_TIMER && data == &publish_periodic_timer) ||
ev == PROCESS_EVENT_POLL ||
(ev == sensors_event && data == PUBLISH_TRIGGER)) {
state_machine();
}
if(ev == PROCESS_EVENT_TIMER && data == &echo_request_timer) {
ping_parent();
etimer_set(&echo_request_timer, conf.def_rt_ping_interval);
}
}
PROCESS_END();
}
Initial configuration values, as described earlier
Creates the client ID, publish and subscribe topics. The initial state STATE_INIT is setand the publish_periodic_timer event is scheduledRegisters the event callback used when a ping event occurs
Starts the periodic ping timer
Allows to try and recover from STATE_ERROR by pressing the user button
Handles the publish_periodic_timer and button events, this is where theapplication actually startsWhen the periodic ping timer expires, pings the parent
When the construct_client_id is first called with the STATE_INIT , thestate_machine is called. A brief walkthrough of the state machine is shown next. Noticehow in some events (like STATE_INIT ) immediately the driver jumps to the next events asthere is not a break statement.
static void
state_machine(void)
{
switch(state) {
case STATE_INIT:
/* If we have just been configured register MQTT connection */
mqtt_register(&conn, &mqtt_demo_process, client_id, mqtt_event,
Hands on: MQTT and mosquitto
142
MAX_TCP_SEGMENT_SIZE);
state = STATE_REGISTERED;
case STATE_REGISTERED:
if(uip_ds6_get_global(ADDR_PREFERRED) != NULL) {
connect_to_broker();
} else {
leds_on(STATUS_LED);
ctimer_set(&ct, NO_NET_LED_DURATION, publish_led_off, NULL);
}
etimer_set(&publish_periodic_timer, NET_CONNECT_PERIODIC);
return;
break;
case STATE_CONNECTING:
leds_on(STATUS_LED);
ctimer_set(&ct, CONNECTING_LED_DURATION, publish_led_off, NULL);
/* Not connected yet. Wait */
DBG("Connecting (%u)\n", connect_attempt);
break;
case STATE_CONNECTED:
/* Don't subscribe unless we are a registered device */
if(strncasecmp(conf.org_id, QUICKSTART, strlen(conf.org_id)) == 0) {
DBG("Using 'quickstart': Skipping subscribe\n");
state = STATE_PUBLISHING;
}
case STATE_PUBLISHING:
/* If the timer expired, the connection is stable. */
if(timer_expired(&connection_life)) {
/*
* Intentionally using 0 here instead of 1: We want RECONNECT_ATTEMPTS
* attempts if we disconnect after a successful connect
*/
connect_attempt = 0;
}
if(mqtt_ready(&conn) && conn.out_buffer_sent) {
/* Connected. Publish */
if(state == STATE_CONNECTED) {
subscribe();
state = STATE_PUBLISHING;
} else {
leds_on(STATUS_LED);
ctimer_set(&ct, PUBLISH_LED_ON_DURATION, publish_led_off, NULL);
publish();
Hands on: MQTT and mosquitto
143
}
etimer_set(&publish_periodic_timer, conf.pub_interval);
return;
} else {
/*
* Our publish timer fired, but some MQTT packet is already in flight
* (either not sent at all, or sent but not fully ACKd).
*
* This can mean that we have lost connectivity to our broker or that
* simply there is some network delay. In both cases, we refuse to
* trigger a new message and we wait for TCP to either ACK the entire
* packet after retries, or to timeout and notify us.
*/
}
break;
case STATE_DISCONNECTED:
DBG("Disconnected\n");
if(connect_attempt < RECONNECT_ATTEMPTS ||
RECONNECT_ATTEMPTS == RETRY_FOREVER) {
/* Disconnect and backoff */
clock_time_t interval;
mqtt_disconnect(&conn);
connect_attempt++;
interval = connect_attempt < 3 ? RECONNECT_INTERVAL << connect_attempt :
RECONNECT_INTERVAL << 3;
DBG("Disconnected. Attempt %u in %lu ticks\n", connect_attempt, interval);
etimer_set(&publish_periodic_timer, interval);
state = STATE_REGISTERED;
return;
} else {
/* Max reconnect attempts reached. Enter error state */
state = STATE_ERROR;
DBG("Aborting connection after %u attempts\n", connect_attempt - 1);
}
break;
case STATE_CONFIG_ERROR:
/* Idle away. The only way out is a new config */
printf("Bad configuration.\n");
return;
case STATE_ERROR:
Hands on: MQTT and mosquitto
144
default:
leds_on(STATUS_LED);
/*
* 'default' should never happen.
*
* If we enter here it's because of some error. Stop timers. The only thing
* that can bring us out is a new config event
*/
printf("Default case: State=0x%02x\n", state);
return;
}
/* If we didn't return so far, reschedule ourselves */
etimer_set(&publish_periodic_timer, STATE_MACHINE_PERIODIC);
}
Entry point, register the mqtt connection and move to the STATE_REGISTERED eventAttempts to connect to the broker. If the node has not joined the network (doesn’t havea valid IPv6 global address) it retries later. If the node has a valid address, then callsthe mqtt_connect function and sets the state to STATE_CONNECTING , then sets thepublish_periodic_timer with a faster paceThis event just informs the user about the connection attempts. When the MQTTconnection to the broker has been made, the MQTT_EVENT_CONNECTED is triggered atthe mqtt_event callback handlerAs we are connected now, proceed and publish. Since we should not be using IBM’squickstart, we skip changing the state to STATE_PUBLISHING and just go aheadChecks if the MQTT connection is OK in mqtt_ready , then subscribe and publish
Handles any disconnection event triggered from MQTT_EVENT_DISCONNECTEDHalts the application, only allows valid configuration values
Default event handler, stops the timer and do nothing
The publish function create the string data to be published. Below is a snippet of thefunction highlighting only the most relevant parts. The example publishes periodically thefollowing:
• Device name.
• An incremental sequence number.
• Device uptime (in seconds).
• On-chip temperature.
• Battery value.
Hands on: MQTT and mosquitto
145
static void
publish(void)
{
len = snprintf(buf_ptr, remaining,
"{"
"\"d\":{"
"\"myName\":\"%s\","
"\"Seq #\":%d,"
"\"Uptime (sec)\":%lu",
BOARD_STRING, seq_nr_value, clock_seconds());
len = snprintf(buf_ptr, remaining, ",\"Def Route\":\"%s\",\"RSSI (dBm)\":%d",
def_rt_str, def_rt_rssi);
len = snprintf(buf_ptr, remaining, ",\"On-Chip Temp (mC)\":%d",
cc2538_temp_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED));
len = snprintf(buf_ptr, remaining, ",\"VDD3 (mV)\":%d",
vdd3_sensor.value(CC2538_SENSORS_VALUE_TYPE_CONVERTED));
mqtt_publish(&conn, NULL, pub_topic, (uint8_t *)app_buffer,
strlen(app_buffer), MQTT_QOS_LEVEL_0, MQTT_RETAIN_OFF);
DBG("APP - Publish!\n");
}
The mqtt_publish updates the MQTT broker with the new values, publishing to thespecified pub_topic . The default topic is iot-2/evt/status/fmt/json as done in theconstruct_pub_topic function. This topic follows IBM’s format but it can be otherwisechanged accordingly.
When receiving an event from a topic we are subscribed to, the MQTT_EVENT_PUBLISHevent is triggered and the pub_handler is called. The example allows to turn the red LEDon and off alternatively.
The default topic the example subscribe to is iot-2/cmd/+/fmt/json , specifically tochange the LED status we would need to publish to the iot-2/cmd/leds/fmt/json topicwith value 1 to turn the LED on, and 0 otherwise.
static void
pub_handler(const char *topic, uint16_t topic_len, const uint8_t *chunk,
uint16_t chunk_len)
{
if(strncmp(&topic[10], "leds", 4) == 0) {
Hands on: connecting to a realworld IoT platform (HTTP-based)
146
if(chunk[0] == '1') {
leds_on(LEDS_RED);
} else if(chunk[0] == '0') {
leds_off(LEDS_RED);
}
return;
}
}
Note the + in the subscribed topic, this allows to have different subsets of topics, such asleds .
5.3. Hands on: connecting to a real world IoT platform(HTTP-based)
Ubidots8 is an IoT cloud platform that helps you create applications that capture real-worlddata and turn it into meaningful actions and insights.
5.4. Ubidots IPv6 example in native Contiki
The example will demonstrate the basic functionality of Contiki’s Ubidots library:
• How to use the library to POST to a variable.
• How to use the library to POST to a collection.
• How to receive (parts of) the HTTP reply.
At the present time the Ubidots example was to be merged to Contiki, however the functionalexample can be browsed and copied from George Oikonomou repository9
The Contiki’s Ubidots Library was written by George Oikonomou.
The Ubidots example is located at examples/ipv6/ubidots .
Ubidots application is implemented at apps/ubidots .
Ubidots application uses TCP sockets to connect to the host things.ubidots.com , whichhas the following IPv4 and IPv6 endpoints:
8 http://www.ubidots.com9 https://github.com/g-oikonomou/contiki/tree/ubidots-demo
Ubidots IPv6 example in native Contiki
147
Figure 5.4. Ubidots endpoint IPv4/IPv6 addresses
To check what’s going on enable the debug print statements in the ubidots.c file, searchfor #define DEBUG DEBUG_NONE and replace with:
#define DEBUG DEBUG_PRINT
As default the ubidots application uses the things.ubidots.com remote host, howeverif no NAT/NAT64 service is available to resolve the host address, the IPv6 endpoint can beexplicitly defined as:
#define UBIDOTS_CONF_REMOTE_HOST "2607:f0d0:2101:39::2"
If you don’t have a local IPv6 connection, services like gogo610 andhurricane electric11 provides IPv6 tunnels over IPv4 connections. Otheroptions like wrapsix12 use NAT64 to translate IPv6/IPv4 addresses.
The Ubidots demo posts every 30 seconds the Z1 mote’s uptime and sequence number,so as done before in the previous sections we need to create these two variables at Ubidots.
10 http://www.gogo6.com/11 https://ipv6.he.net/12 http://www.wrapsix.org/
Ubidots IPv6 example in native Contiki
148
Create the data source and its variables, then open the project-conf.h file and replacethe following accordingly:
#define UBIDOTS_DEMO_CONF_UPTIME "XXXX"
#define UBIDOTS_DEMO_CONF_SEQUENCE "XXXX"
The last step is to assign an Ubidot’s fixed Short Token so we don’t have to request one whenit expires, get one and add this to the Makefile , the file should look like this:
DEFINES+=PROJECT_CONF_H=\"project-conf.h\"
CONTIKI_PROJECT = ubidots-demo
APPS = ubidots
UBIDOTS_WITH_AUTH_TOKEN=XXXXXXXX
ifdef UBIDOTS_WITH_AUTH_TOKEN
DEFINES+=UBIDOTS_CONF_AUTH_TOKEN=\"$(UBIDOTS_WITH_AUTH_TOKEN)\"
endif
all: $(CONTIKI_PROJECT)
CONTIKI_WITH_IPV6 = 1
CONTIKI = ../../..
include $(CONTIKI)/Makefile.include
Note that you should replace the UBIDOTS_WITH_AUTH_TOKEN without using "" quotes.
Now everything should be set, let’s compile and program a Z1 mote!
make TARGET=z1 savetarget
make clean && make ubidots-demo.upload && make z1-reset && make login
You should see the following output:
connecting to /dev/ttyUSB0 (115200) [OK]
Rime started with address 193.12.0.0.0.0.0.158
MAC c1:0c:00:00:00:00:00:9e Ref ID: 158
Contiki-d368451 started. Node id is set to 158.
nullmac nullrdc, channel check rate 128 Hz, radio channel 26
Tentative link-local IPv6 address fe80:0000:0000:0000:c30c:0000:0000:009e
Starting 'Ubidots demo process'
Ubidots client: STATE_ERROR_NO_NET
Ubidots client: STATE_ERROR_NO_NET
Ubidots client: STATE_ERROR_NO_NET
Ubidots client: STATE_STARTING
Ubidots client: Checking 64:ff9b::3217:7c44
Ubidots client: 'Host: [64:ff9b::3217:7c44]' (remaining 44)
Ubidots client: STATE_TCP_CONNECT (1)
Ubidots IPv6 example in native Contiki
149
Ubidots client: Connect 64:ff9b::3217:7c44 port 80
event_callback: connected
Ubidots client: STATE_TCP_CONNECTED
Ubidots client: Prepare POST: Buffer at 199
Ubidots client: Enqueue value: Buffer at 210
Ubidots client: POST: Buffer at 211, content-length 13 (2), at 143
Ubidots client: POST: Buffer at 208
Ubidots client: STATE_POSTING (176)
Ubidots client: STATE_POSTING (176)
Ubidots client: STATE_POSTING (144)
Ubidots client: STATE_POSTING (112)
Ubidots client: STATE_POSTING (80)
Ubidots client: STATE_POSTING (48)
Ubidots client: STATE_POSTING (16)
Ubidots client: STATE_POSTING (0)
Ubidots client: HTTP Reply 200
HTTP Status: 200
Ubidots client: New header: <Server: nginx>
Ubidots client: New header: <Date: Fri, 13 Mar 2015 09:35:08 GMT>
Ubidots client: New header: <Content-Type: application/json>
Ubidots client: New header: <Transfer-Encoding: chunked>
Ubidots client: New header: <Connection: keep-alive>
Ubidots client: New header: <Vary: Accept-Encoding>
Ubidots client: Client wants header 'Vary'
H: 'Vary: Accept-Encoding'
Ubidots client: New header: <Vary: Accept>
Ubidots client: Client wants header 'Vary'
H: 'Vary: Accept'
Ubidots client: New header: <Allow: GET, POST, HEAD, OPTIONS>
Ubidots client: Chunk, len 22: <[{"status_code": 201}]> (counter = 22)
Ubidots client: Chunk, len 0: <(End of Reply)> (Payload Length 22 bytes)
P: '[{"status_code": 201}]'
Figure 5.5. Ubidots graphs
Ubidots IPv6 example in native Contiki
150
The values are displayed using a Multi-line chart and a Table-Values dashboard.
151
ACRONYMSCoAP
Constrained Application Protocol
DHCPv6Dynamic Host Configuration Protocol for IPv6
IANAInternet Assigned Numbers Authority
IETFInternet Engineering Task Force
IIDInterface Identifier (in an IPv6 address)
IPInternet Protocol
IPv4Internet Protocol version 4
IPv6Internet Protocol version 6
LANLocal Area Network
MACMedium Access Control
MQTTMessage Queuing Telemetry Transport
NATNetwork Address Translation
SLAACStateless Address Autoconfiguration
TCPTransmission Control Protocol
UDPUser Datagram Protocol
152
WSNWireless Sensor Network
153
Bibliography
References[IoT] Ovidiu Vermesan & Peter Fress, “Internet of Things –From Research and
Innovation to Market Deployment”, River Publishers Series in Communication, ISBN:87-93102-94-1, 2014.
[SusAgri] Rodriguez de la Concepcion, A.; Stefanelli, R.; Trinchero, D. "Adaptive wirelesssensor networks for high-definition monitoring in sustainable agriculture", WirelessSensors and Sensor Networks (WiSNet), 2014
[sixlo] IETF WG 6Lo: http://datatracker.ietf.org/wg/6lo/charter/
[sixlowpan] IETF WG 6LoWPAN: http://datatracker.ietf.org/wg/6lowpan/charter/
[IANA-IPV6-SPEC] IANA IPv6 Special-Purpose Address Registry: http://www.iana.org/assignments/iana-ipv6-special-registry/
[IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003
[RFC2460] S. Deering, R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”,December 1998, RFC 2460, Draft Standard
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "DynamicHost Configuration Protocol for IPv6 (DHCPv6)", July 2003
[RFC4193] R. Hinden, B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC4193,October 2005
[RFC4291] R. Hinden, S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291,February 2006
[RFC4862] S. Thomson, T. Narten, T. Jinmei, "IPv6 Stateless Address Autoconfiguration",September 2007
[RFC6775] Z. Shelby, Ed., S. Chakrabarti, E. Nordmark, C. Bormann, “NeighborDiscovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks(6LoWPANs)”, November 2012, RFC 6775, Proposed Standard
[RFC6890] M. Cotton, L. Vegoda, R. Bonica, Ed., B. Haberman, "Special-Purpose IP AddressRegistries", RFC 6890 / BCP 153, April 2013
154
[roll] roll IETF WG: http://datatracker.ietf.org/wg/roll/charter
[I802154r] L. Frenzel, "What’s The Difference Between IEEE 802.15.4 AndZigBee Wireless?" [Online] Available: http://electronicdesign.com/what-s-difference-between/what-s-difference-between-ieee-802154-and-zigbee-wireless.
