internet das coisas: tecnologias atuais e futuras, e o papel do software

© Antônio M. Alberti 2014

Internet das Coisas: Tecnologias Atuais e Futuras, e o Papel do Software

Antônio Marcos Alberti !

[email protected] www.inatel.br/novagenesis/

mailto:[email protected]

http://www.inatel.br/novagenesis/

‣ Internet of Things (IoT) Definitions

‣ Current Internet of Things Technologies

‣ The Current Internet Status

‣ Future Internet (FI) and Internet of Things

‣ European IoT Initiatives

‣ Interrelationships Among IoT and FI Ingredients

‣ NovaGenesis: Convergent Information Architecture

Outline

‣ To make an Internet build of physical “Things”.

‣ To bring the Internet to the “Things”.

‣ To put the “Things” on the Internet.

Internet of Things (IoT) Definitions

(c) Antonio Alberti 2014, Inatel - All rights reserved.

‣ Message Queue Telemetry Transport (MQTT)

‣ IEEE 802.15.4:

‣ IEEE 802.15.4e (Time Synchronized Channel Hopping)

‣ ZigBee

‣ Wireless Highway Addressable Remote Transducer Protocol (WirelessHART)

Current Internet of Things Technologies


‣ IETF:

‣ IPv6 over Low Power Personal Area Network (6LoWPAN)

‣ IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH).

‣ 6TiSCH Operation Sublayer (6top)

‣ IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL)

‣ Constrained Application Protocol (CoAP)


‣ “Light weight” messaging protocol to run over TCP/IP.

‣ “MQ” comes from IBM's message queuing.

‣ It is not real time - delay of seconds.

‣ Focused on Machine to Server (M2S) scenario.

‣ Follows a publish/subscribe hub-and-spoke paradigm.

‣ MQTT for Sensor Networks (MQTT-SN) is TCP/IP independent.

‣ Operations: Connect, Subscribe, Publish, Unsubscribe, Disconnect.

‣ Provides agnostic binary payload.





Picture Credits: MQTT: A practical protocol for the Internet of Things, Bryan Boyd, IBM, 2014.

MQTT bi-directional, async “push” communication

MQTT!Broker

CONNECT to MQTT broker SUBSCRIBE to thing3/data

CONNECT to MQTT broker PUBLISH to thing3/data

recv

recv

pub

thing #3

thing #1

thing #2

TCP/IP

WebSocket

‣ IEEE 802.15.4:

‣ It is a wireless communication standard for low-power, low-data rate, and short distance radio coverage.

‣ Developed within IEEE 802.15 Personal Area Network (PAN) group.

‣ Typical data rate is 250 kb/s with maximum packet size of 127 bytes - Available payload is about 86 up to 116 bytes.

‣ Defines physical layer (16 channels with direct sequence spread spectrum) and MAC layer.

‣ Can go multi-hop, but requires to keep the radio on all the time.

‣ Employs single channel operation, which suffers with multi-path fading and shadowing.



‣ IEEE 802.15.4e:

‣ Employs a Time Synchronized Channel Hopping (TSCH) technique to avoid interferences, shadowing, and multi-path fading.

!!!!!

‣ Redesigned MAC protocol to support centralized or distributed scheduling, channel hoping, and network formation.



PALATTELLA et al.: STANDARDIZED PROTOCOL STACK FOR THE INTERNET OF (IMPORTANT) THINGS 1393

Fig. 1. A 4-slot slotframe and timeslot diagram of an acknowledged transmission.

same: synchronize the motes for energy efficiency, channelhop for reliability.

A. Slotframe StructureIn TSCH, motes synchronize on a slotframe structure. A

slotframe is a group of slots which repeat over time. Eachmote follows a schedule which tells it what to do in eachslot. In a given slot, a mote can either transmit, receive,or sleep. In a sleeping slot, the mote does not turn on itsradio. For each active slot, the schedule indicates with whichneighbor to transmit or receive, and on which channel offset(see Sec. III-C).

As shown in Fig. 1, a single slot is long enough for thetransmitter to send a maximum length packet, and for thereceiver to send back an acknowledgment indicating goodreception. While the duration of a slot is implement-specific,10 ms is a possible value suggested in [40].

When an upper layer generates a packet, it sends it to theMAC layer which stores the packet in a transmit queue. Ateach transmission slot, the MAC layer checks whether it hasa packet in its queue destined to the neighbor associated withthat slot. If not, it goes back to sleep without turning its radioon. If yes, it transmits the packet and waits for the ACK. Ifan ACK is received, it removes the packet from the queue.Otherwise, it keeps the packet in the queue for future re-transmission. A number of retransmissions is kept for everypacket to avoid staleness.

At each reception slot, a mote turns on its radio right beforethe time it expects to receive the packet. If it receives a packetdestined for it, it sends an acknowledgment, turns off its radio,and forwards the packet to the upper layer for processing. Ifit does not receive anything after some timeout, it returns tosleep. This means that either the transmitter had nothing tosay, or that the packet got lost due to interference or fading.

Fig. 2 shows an example topology and the associatedschedule. Here, the slotframe is 5 slots long, and there are6 channel offsets (the concept of channel offset is presentedin Sec. III-D). Each mote in the network only cares about thecells it participates in. For example, when G has a packet tosend to D, it waits for slot 3, and sends it on channel offset0. It will stay off for the other cells. If a packet needs to gofrom G to A, it will first be sent from G to D, be bufferedat D, then sent from D to A in the next frame. Note that, asdepicted in Fig. 2, while most cells are dedicated, some canbe shared between different links (e.g. D → A and C → A).IEEE802.15.4e defines a simple backoff scheme for sharedcells in case a collision occurs.

Fig. 2. Dedicated and shared links.

B. Scheduling

IEEE802.15.4e defines how the MAC layer executes aschedule (as described in Sec. III-A). It does not specifyhow such as schedule is built. A schedule needs to be builtcarefully so that, when mote A has a transmit slot to moteB, B is actually listening for packets from A. Similarly, ifA is no longer a neighbor of B (e.g. it moved or switchedoff), B should not be listening anymore for packets fromA. While all these rules are intuitive, they also illustrate thatthe network’s schedule needs to be both carefully built, andconstantly refreshed as links come and go in the network.Scheduling can either happen in a centralized or a distributedway:

• In a centralized approach, a specific “manager” moteis responsible for building and maintaining the networkschedule. Every mote in the network regularly updatesthe manager with the list of other motes it can hear, andthe amount of data it is generating. From that neighborinformation, the manager draws the connectivity graph.From the data generation demands, it assigns slots tothe different links in the connectivity graph. Once thisschedule is built, the manager informs each mote aboutthe links in the schedule it is participating in. The motesthen simply follow these instructions. When there is achange in the connectivity (i.e., a mote lost a neighbor),the manager updates its schedule and informs the affectedmotes.In practice, networks often have a gateway mote whichconnects it to the Internet (see Section IV). In a cen-tralized approach, that mote often also manages theIEEE802.15.4e schedule. This type of approach has beencommercially available since TSMP, and tens of thousandsuch networks have been deployed.A centralized approach builds very efficient schedules.Since the manager knows exactly what the network looks

Picture Credits: Standardized Protocol Stack for the Internet of (Important) Things, Palattella et al., IEEE Comm. Surveys and Tutorials, 2013.

‣ ZigBee

‣ Industry standard based on IEEE 802.15.4.

!

‣ Wireless Highway Addressable Remote Transducer Protocol (WirelessHART)

‣ Industry standard based on IEEE 802.15.4 and TSCH (also employed on 802.15.4e).



‣ IETF: IPv6 over Low Power Personal Area Network (6LoWPAN)

‣ IPv6 packets are too big for IEEE 802.15.4.

‣ Provides an adaptation layer to segment and reassembly IPv6 datagrams.

‣ Provides IPv6 header compression.



IEEE 802.15.4 MAC

IEEE 802.15.4 PHY

IETF 6LoWPAN

IETF IPv6

IETF TCP/UDP

IEEE 802.15.4 MAC

IEEE 802.15.4 PHY

IETF 6LoWPAN

IETF IPv6

IETF TCP/UDP

‣ IETF: IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH)

‣ “It defines the 6top sublayer and a set of protocols (in particular, for setting up a schedule with a centralized or distributed approach, managing the resource allocation), as well as the architecture to bind them together, for use in IPv6 TSCH based networks,” from Internet Draft, July 2014.



IEEE 802.15.4e MAC

IEEE 802.15.4 PHY

IETF 6LoWPAN

IETF IPv6

IETF TCP/UDP

IEEE 802.15.4e MAC

IEEE 802.15.4 PHY

IETF 6LoWPAN

IETF IPv6

IETF TCP/UDP

IETF 6top IETF 6top

‣ IETF: 6TiSCH Operation Sublayer (6top)

‣ “6top offers a set of commands so control mechanisms can be introduced on top of TSCH to configure nodes to join a specific node and obtain a unique 16-bit identifier from the network. Once a network is formed, 6top maintains the network’s health, allowing for nodes to stay synchronized,” from Internet Draft, July 2014.



‣ IETF: IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL)

‣ Provides a routing approach for Low-Power and Lossy Networks (LLNs).

‣ Employs a distance-vector approach were nodes construct a Destination-Oriented Acyclic Graph (DODAG).

‣ The destination is the root node (usually the IoT gateway).



‣ IETF: Constrained Application Protocol (CoAP)

‣ Provides a specialized web transfer protocol for LLNs that conforms to the REST style.

‣ There is an URI for every “Thing”.

‣ Contrary to HTTP, it employs UDP instead of TCP.

‣ Enables asynchronous message exchange with low complexity parsing.

‣ HTTP-CoAP mapping is standardized.



‣ IETF: Constrained Application Protocol (CoAP)

‣ How it integrates to the IETF IoT stack?



IEEE 802.15.4e MAC

IEEE 802.15.4 PHY

IETF 6LoWPAN

IETF IPv6

IETF TCP/UDP

IEEE 802.15.4e MAC

IEEE 802.15.4 PHY

IETF 6LoWPAN

IETF IPv6

IETF UDP/TCP

IETF 6top IETF 6top

IETF CoAP IETF CoAP


The Current Internet Statusü The main protocols in the stack were designed in an era where

technological development was completely different from today. !

ü There was not enough capacity to support sophisticated networking services - the solution was to design a simple, but robust network. !

ü The terminals were fixed, inside secure university/government environment - there were not attackers!! !

ü During decades, it was incrementally developed and deployed, achieving impressive scales!!!


The Current Internet Statusü The result is a complex agglomerate of incremental protocols

that inherits the grown legacies of decades of patchwork solutions. !

ü New protocols must live with the limitations of the preceding. !

ü Intermediary layers have been added to overcome unplanned situations, reducing network efficiency. !

ü While at the physical layer we are approaching to the theoretic Shannon’s limit of channels, at network level, lots of bytes are lost on inefficient stacking. !

ü Interoperability of dual stacking for IoT (traditional vs LLN).


The Current Internet Statusü Other limitations of the current stack are:

ú The dual semantics of IP addresses (identifier and locator). ú The lack of unique addresses and transparency. ú The inefficient support for host mobility. ú The inexistent support for service mobility. ú The incomplete naming approach, which do not name applications

and other important entities in architecture. ú The weak support for security, privacy, and trust. ú The weak support for multicast. ú The weak support for quality of service. ú The problematic support for inter autonomous system routing. ú The inexistent support for multihoming. ú The scalability issues of client/server model.

‣ Since 2000, several initiatives to rethink the Internet appeared under the banner of the so called Future Internet Architecture (FIA) design. !

‣ They can be classified as: ú Clean slate - Aim at redesigning from “scratch" the Internet

architecture using the state-of-the-art of contemporary information and communications technologies. !

ú Evolutionary - Aim at continuing evolving TCP/IP Internet. !‣ Since 2008, I am designing a new convergent information

architecture called NovaGenesis.

Future Internet and Internet of Things

Future Internet and Internet of Things‣ A branch of FIA design is the Internet of Things (IoT), or more

generally the Internet of Everything (IoE). !

‣ The IoE can be defined as to make everything belong to the Internet. !

‣ The clean slate advocates wonder if the current Internet can support such a challenge, i.e. scalability, naming, identification, mobility, addressing for billions of nodes.



European IoT Initiatives

IoT-‐A Partner List

Produtos de

Mercado

FP7

ARM Architecture Reference Model

FIA – RWI – IoT-‐I Projetos orientados a IoT: SENSEI, ASPIRE, AUTOI SMARTSANTANDER

WISEBED

Projetos tocantes a IoT: INSTANT MOBILITY

OUTSMART, SAFECITY SMARTAGRIFOOD

FI-‐PPP Partners

Serviços e Soluções

de Mercado

FIA Partners: EFIA FI-‐EC

Serviços e Soluções

de Mercado

FIA-‐FP7 -‐ EU’s Seventh Framework Programme RWI -‐ Real World Internet FIA – Future Internet Assembly IoT-‐I – Internet of Things Initiative

FI-‐PPP – Future Internet Public Private Partnership IoT-‐A – Internet of Things Architecture EFIA – European Future Internet Alliance FI-‐EC – Future Internet at European Commission

IoT

Capacity/Ubiquity/Scalability

Real-Virtual

Exposition/Service-centrism

SDN

Management/Autonomicity

Information-centrism

Naming/Identification/Mobility/Multihoming

Interrelationships Among IoT and FI Ingredients


ü IoT and FI resources need be exposed to software orchestration frameworks, allowing the dynamic and integrated composition of real and virtual existences.

Resources Exposition and Service-Centrism

Software Orchestration



Resources Exposition and Service-Centrismü Entire services’ life-cycles can be orchestrated involving such

exposed resources. !

ü The life-cycle can include devices description, search, selection, negotiation, admission, installation, monitoring, failure handling, and all the other management functionalities. !

ü In short, IoT capabilities can be seen as a service (IoT-as-a-service). !

ü This view approximates the IoT to the so-called Internet of Services (IoS).

Management and Autonomicityü IoT will manage itself or at least reduce considerably the degree

of the human intervention required.


We already have self-driven cars. Why not to have a self-driven FIA?

ü We cannot expect that the IoT will be managed in the same way as the telecom operator’s networks today.

Management and Autonomicityü The autonomic technology appears to be a natural candidate for

the IoT management. !

ü However, the IoT provides the information necessary to feed the autonomic cycle of other FI architectural components. !

ü Thus, IoT appears to be a natural candidate to implement some of the phases of the autonomic cycle for FI components.


Information-centrismü Node-centrism is perhaps the most common approach for

designing WSANs. !

ü IoT can take great advantage of the precepts behind the Internet of Information (IoI). !

ü Self-certifiable names (hash codes) can be used to name data in a persistent and verifiable way. !

ü The integrity, provenance, and non-repudiation of sensing and actuating data can be checked based on such names.


Information-centrismü Name-based search and discovery of network-enabled devices

and information helps on IoT services’ life-cycle.


IEEE Wireless Communications • December 2013 97

reducing the device cost for CCN-based IoTsolutions as well. In particular, a device usingthe protocol stack in Fig. 6b can further elimi-nate the IP address management procedure.Power saving can easily be achieved in the CCNarchitecture. Given the request arrival, therouter can respond with the cached data withoutwaiting for the activation of the target. More-over, by introducing resource subscription, theIoT device can only keep the subscription mes-sage from the router serving the request with thecached data to enable timely reaction to theaccess request even if it is in sleep mode forpower saving.

FUTURE RESEARCH CHALLENGESSo far, we have introduced the IETF effort ondeveloping the global communication solutionfor WSN and summarized some of the criticalopportunities and challenges of bringing the cur-rent IoT standards into reality. From the techni-cal perspective, the Internet of Things relies notonly on industry efforts to promote network con-vergency, but also academic innovations at a fun-damental level to improve engineering designs.For a long-term vision, we identify some inter-esting research opportunities and challenges forfuture IoTs:1. Convergent networks: Future IoT infrastruc-

tures may exist everywhere, in home, industry,cities, and so on. Considering that the emerg-ing number of IoT standards (e.g., ZigBee)and different communication technologies(e.g., power line communications [PLC], WiFi)coexist, it is necessary to develop heteroge-neous technologies to enable convergent net-works. For instance, ZigBee has officiallyreleased its ZigBee IPv6 specification to con-sider its compatibility with the IETF stan-dards. By taking advantage of possible radioresources nearby, different communicationtechnologies can cooperate together to deliverhighly efficient and green communications.

2. Hybrid communication paradigm: Current IoTsolutions focus on a multihop short-rangecommunication paradigm, which is limited bypoor end-to-end throughput and the high costof large-scale deployment. Alternatively, sen-sor data can also be forwarded to the Internetusing opportunistic (i.e., carry-and-forward)[18] or one-hop long-range (e.g., third/fourthgeneration [3/4G] cellular) communications.Seamlessly combining these communicationparadigms could result in more cost-effectiveIoT solutions.

3. Joint data processing and networking: It isexpensive to transmit huge volumes of rawdata produced by numerous smart things tothe Internet. Fortunately, sensor data process-ing techniques such as compressive sensingand data fusion can significantly reduce thesensor data volume. Consequently, designing acommunication paradigm with data processingawareness for future IoTs is highly desired.

4. Social and economic awareness: As sensors orsmart things are owned by the public, organi-zations, or individuals, social and economicbehaviors of users, network service providers,and sensor data providers should be consid-

ered in the IoT design [19], such as incentive,resource pricing, and social-aware privacy.

CONCLUSIONThis survey provides a brief overview of theIETF protocol suite proposed to support theInternet of Things. Taking each layer in the pro-tocol in turn, we have presented the technicalchallenges and opportunities that exist. That is,the physical layer, MAC layer, 6LowPAN, RPLprotocols, and CoAP standards have beenreviewed and critiqued. It is our view that thesestandards are a good start, but there are manyopen issues remaining. However, based on thecurrent trajectory of research combined withmore forward thinking, better solutions capableof combating radio unreliability and meetingfuture application requirements of high-speedand high-quality services with high energy effi-ciency can be developed. New insights regardingprotocol analysis could also provide preciseguidelines that will result in efficient designs ofpractical and reliable communications systems.The resulting ideas have the potential to have abroad impact across a range of areas, includingwireless communications, network protocols, andradio transceiver design.

REFERENCES[1] A. Garcia-Hernando et al., Problem Solving for Wireless

Sensor Networks, Springer, July 2008.[2] IETF Working Groups RoLL and Core,

http://datatracker.ietf.org/wg/.[3] IEEE Std 802.15.4-2003, IEEE Comp. Soc., 2003.[4] J. Song et al., “Wirelesshart: Applying Wireless Technol-

ogy in Real-Time Industrial Process Control,” Proc. IEEERTAS, 2008, pp. 377–86.

[5] A. Sridharan and B. Krishnamachari, “Explicit and Pre-cise Rate Control for Wireless Sensor Networks,” Proc.ACM SenSys, 2009, pp.29–42.

[6] X. Wang et al., “A Survey of Green Mobile Networks:Opportunities and Challenges,” Mobile Networks andApplications, vol. 17, no. 1, Feb. 2012.

[7] Y.-S. Shin, K.-W. Lee, and J.-S. Ahn, “Analytical Perfor-mance Evaluation of IEEE 802.15. 4 with MultipleTransmission Queues for Providing QoS under Non-Sat-urated Conditions,” Proc. 16th Asia-Pacific Conf. Com-mun., 2010, pp. 334–39.

Figure 6. Comparison of IP protocol stack and the proposed solution: a) IP-based stack; b) non-IP-based stack.

Content

UDP

Content

IEEE 802.15.4, WiFi,Ethernet,...

(b)

IPv6

6LoWPAN

IEEE 802.15.4

(a)

YANG_LAYOUT_Layout 12/20/13 1:00 PM Page 97

Picture Credits: A Survey on the IETF protocol suite for the Internet of Things - Standards, Challenges and Opportunities, Sheng et al., IEEE Wireless Comm., Dec. 2013.

Examples: !NDN - Named Data Networking or NovaGenesis

‣ It aims to create a “clean slate” architecture to the new new generation of converging information technologies.

‣ It is a set of distributed systems that cooperate each other towards self-organizing all architecture functionalities as on demand, contracted services.

‣ It employs a bottom-up approach where complex distributed systems are formed by the cooperation of simples ones.

‣ It aims to create a broad, flexible, sustainable, and evolvable digital business ecosystem (DBE).

‣ NovaGenesis provides an unique way of combining the same Future Internet ingredients adopted worldwide.

NovaGenesis Overview


‣ Adopted decision choices:

- Entities and content naming using natural language and self-certifiable names (hash codes).

- As functionalities are seen as services, including network protocols.

- Complex protocols like TCP are fragmented on a population of cooperating services - combined at runtime.

- Name bindings are stored on distributed hash tables, representing all kind of relationships among named-things.

- Name bindings are published and subscribed, enabling distributed search, discovery, negotiation, and contracting of services and content.



- Substrate resources are exposed to software by proxies, which represent them regarding resource life-cycling and orchestration.

- All the communication is done by message scheduling and exchanging, with dynamic headers.

- All the contracts can capture intrinsically the required quality, security, privacy, reputation, etc.

- The services will employ a decision cycle to meet objectives traced by human and machine operators.

- They compete each other to better satisfy contracts (evolutionary pressures) and optimize the usage of substrate resources (evolution environment).



(c) A

nton

io A

lber

ti 20

14, I

nate

l.

Physical Individual

Existences

Services!& Contents

Names

Bidwell Mansion

525 Esplanade, Chico, California

39°43′56.47″N 121°50′36.53″W

Raymond Kurzweil

Bugatti VeyronTM

iPADTM Nexus N5TM

OpenOfficeTM Readme.txt

1ABC234

Locators

525 Esplanade, Chico, California

Hash 1

IdentifierSerial #2, Hash 5

Bidwell Mansion 1ABC234

Raymond Kurzweil

../Readme.txt, Hash 7

PID = 321, Hash 6

Serial Number 1

Serial Number 2

PID = 321 /home/Readme.txt

Hash 2Hash 4,6

Hash 5,739°43′56.47″N 121°50′36.53″W

Hash 1Hash 2 Hash 3

Hash 4 Hash 5

Hash 6 Hash 7

Hash 1 Hash 2 Hash 3Serial #1, Hash 4


NovaGenesis

(c) A

nton

io A

lber

ti 20

14, I

nate

l.

PGS

GW HT

CLIPG

PSS

GW HT

CLIPS

HTS

GW HT

CLI

PGS

GW HT

CLIPG

GIRS

GW HT

CLIIR

HTS

GW

DHT CLI

MAC/PHY MAC/PHYEth/Wi-Fi

PHY Eth/Wi-Fi

PHY

HT

App

GW HT

CLICore

App

GW HT

CLICore


‣ NovaGenesis as an architecture to Adaptive and Cognitive Radio over Fiber (ACRoF) and Internet of Things (IoT)

From “H”RoF RoF

Splitter

Access Point

Spectrum Analyzer

Antenna Control Link

From “H”

To “E” To “E”

Optical Switch

Throughtput (Mbps)CINR (dB)

RF

Sa Freque

NovaGenesis Services for Proxy/Gateway/Control of: !-Spectrum Sensing -Optically

Controlled Antenna -Access Point -Wi-Fi VLAN !!!


Developing a NovaGenesis IoT


Social Devices

Window Sensor

Storm

Nobody at home

Towards a Trustable Fellowship of Self-Organizing “Things”

Open windowPresence Sensors

Weather Sensors

Close the window

Window !Representative

Presence Sensors !Representative

Weather Sensors !Representative

Smart !Assistant

Developing a NovaGenesis IoT Smart Future Internet Architecture

Physical World

Self-Organizing !Physical World Representatives

People!Policies, Rules, Regulations, etc.

Self-Organizing!Assistants, Controllers, Managers, etc.


Obrigado!Antônio Marcos Alberti

!www.inatel.br/novagenesis antonioalberti.blogspot.com

facebook.com/antoniomarcos.alberti researchgate.net/profile/Antonio_Alberti linkedin.com/profile/view?id=69752898

http://inatel.academia.edu/AntonioMarcosAlberti mendeley.com/profiles/antonio-marcos-alberti/

twitter.com/antoniomalberti

‣ Building a biometric classroom frequency control software

Experimenting with current IoT technologies


LPC1769

XBee Wi-Fi Modules

‣ Dynamic firmware replacement on LPC 1769

Experimenting with current IoT technologies


Bootloader(NovaGenesis)

Aplicação

Troca de Informação

GatewayNovaGenesis

Dispositivos / Roteadores

Comunicação sem fio

internet das coisas: tecnologias atuais e futuras, e o papel do software

Technology

internet of important

internet draft

e macieee

phyc antonio alberti

e time synchronizedchannel

ipv6 routing protocol

ipv6 tsch basednetworks

lowpan ipv6 packets