Upload
antonio-alberti
View
326
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Palestra dada na QCon RIo 2014.
Citation preview
© 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/
‣ 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
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ 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)
‣ Message Queue Telemetry Transport (MQTT)
‣ “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.
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ Message Queue Telemetry Transport (MQTT)
Current Internet of Things Technologies
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.
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ 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.
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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).
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ 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.
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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.
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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.
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ 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).
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ 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.
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ IETF: Constrained Application Protocol (CoAP)
‣ How it integrates to the IETF IoT stack?
Current Internet of Things Technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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
© Antônio M. Alberti 2014
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!!!
© Antônio M. Alberti 2014
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).
© Antônio M. Alberti 2014
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.
(c) Antonio Alberti 2014, Inatel - All rights reserved.
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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
(c) Antonio Alberti 2014, Inatel - All rights reserved.
ü 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
(c) Antonio Alberti 2014, Inatel - All rights reserved.
© Antônio M. Alberti 2013
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.
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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.
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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.
(c) Antonio Alberti 2014, Inatel - All rights reserved.
Information-centrismü Name-based search and discovery of network-enabled devices
and information helps on IoT services’ life-cycle.
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ 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
(c) Antonio Alberti 2014, Inatel - All rights reserved.
‣ 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.
NovaGenesis Overview
(c) Antonio Alberti 2014, Inatel - All rights reserved.
- 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).
NovaGenesis Overview
(c) Antonio Alberti 2014, Inatel - All rights reserved.
(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 Overview
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 Overview
‣ 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 !!!
(c) Antonio Alberti 2014, Inatel - All rights reserved.
Developing a NovaGenesis IoT
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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.
(c) Antonio Alberti 2014, Inatel - All rights reserved.
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
(c) Antonio Alberti 2014, Inatel - All rights reserved.
LPC1769
XBee Wi-Fi Modules
‣ Dynamic firmware replacement on LPC 1769
Experimenting with current IoT technologies
(c) Antonio Alberti 2014, Inatel - All rights reserved.
Bootloader(NovaGenesis)
Aplicação
Troca de Informação
GatewayNovaGenesis
Dispositivos / Roteadores
Comunicação sem fio