ICT LAB OVERVIEW
Antonio M. Alberti, Professor & Researcher
CYBERINFRASTRUCTURE NFV, SDN, CLOUD/FOG COMPUTING 7 PROJECTS
SMART PLACES IOT, SOA, CONTROL, MNGT, MIDDLEWARE 7 PROJECTS
FUTURE INTERNET ARCHITECTURES NOVAGENESIS, XIA, GIN, RINA, CCN, NDN 4 PROJECTS
GOVERNANCE, METHODOLOGIES, TOOLS QUEUING THEORY, NS3, COOJA, PROJECT 3 PROJECTS
PROJECT MANAGEMENT OFFICE PMI, ITIL, E-TOM, COBIT 2 PROJECTS
CYBERINFRASTRUCTURE NFV, SDN, CLOUD/FOG COMPUTING
ú NOVAGENESIS OVER FIBRE ú NOVAGENESIS X INTERNET DNS ú KEYFLOW OVER 10 GBPS ú NOVAGENESIS OVER DOCKER ú NOVAGENESIS AS A SOFTWARE-
DEFINED NETWORK ú NAMED-CONTENT WITH NOVAGENESIS ú NOVAGENESIS CONTROL AND MNGT.
SMART PLACES IOT, SOA, CONTROL, MNGT, MIDDLEWARE
ú SMART CAMPUS INATEL ú MIDDLEWARE FOR SMART CITIES ú SMART GRID: CEMIG OPERATIVE
NETWORK ú POSTURAL PROBLEM PREVENTION (E-
HEALTH) ú SENSOR NETWORK ACTIVITY LEVEL
PLANNING ú COGNITIVE RADIO FOR IOT WITH
NOVAGENESIS (CRIOTNG) ú FUTURE INTERNET OF THINGS (FIOT)
• NOVAGENESIS EMBEDDED PROXY GATEWAY SERVICE (EPGS)
• HARDWARE/FIRMWARE
FUTURE INTERNET ARCHITECTURES NOVAGENESIS, XIA, GIN, RINA, CCN, NDN
ú NOVAGENESIS SOCIAL-DRIVEN ARCHITECTURE
ú XIA FOR IOT (XIOT) ú CCN, CCNX, NDN E CCN LITE ú NG-WEB
GOVERNANCE, METHODOLOGIES, TOOLS QUEUING THEORY, NS3, COOJA, PROJECT
ú PROJECT MANAGEMENT ú TOOLS: QUEUING THEORY, SIMULATION,
EMULATION, DEMONSTRATION, EXPERIMENTATION.
ú METHODOLOGIES: SCIENTIFIC, RELATION TO COMPANIES, GOVERNMENT.
PROJECT MANAGEMENT OFFICE PMI, ITIL, E-TOM, COBIT
ú PORTFOLIO, PROJECTS, TEAMS, ETC. ú PARTNERSHIPS AND BUSINESS
RELATED.
Networks Clouds+Big Data= +
Telecom & Internet
IT & Web
“Things” +
Machine to machine& Internet ofThings
+
Identity,Credentials,Biometrics
OUR MODEL
User-centric
Self-*, Context
Information-centricService-centric
Software-Defined
SecurityPriva
cy
Nam
ing
Name R
esolu
tionVirtualization
Internet of Things
Exposition, Orchestration
Self-Certifying
Life-Cycling
Prot
ocol
Dev
elop
men
t
Mobility ID
/Loc
Spl
ittin
g
Mngt. a
nd Con
trol
Design Space
(2015)
Prototype
LIVE DEMO @ SAO PAULO
CAMPUS PARTY JAN. 2015
SCALABILITY@ INATEL AUG. 2015
FIRST TEST@ GENI
SEPT. 2015
Sensing CellController
Sensing InformationStorage and Analysis
Sensing Cell
Sensing CellController
Sensing Cell
Sensing CellController
Sensing Cell
TCP/IP
Internet
TCP/IP
TCP/IP
...
...
Radio M2 Internet
Radio M1
IoT NetworkBoundary
Sensing CellBoundary
BorderRouter
Sensing Cell SC1
Sensing Cell SC2
Mint
SCC1
SCC2
SISA
InterfererRange
Interferer
(a) (b)
Figure 1: Cognitive Radio blocks in the context of IoT.
2.2.1. Sensing Cell (SC)The RF spectrum may be sensed by more than one sensing
cell (SC), which includes a RF receiver, an antenna and a com-putational processing board. The SC hardware is constructedusing low-cost commercial hardware based on Raspberry PI2 [24] processing board and a digital video broadcasting-terrestrial (DVB-T) receiver acting as a RF receiver. The lat-ter one has becoming popular for software defined radio (SDR)applications [25, 26]. SCs may be deployed over di↵erent lo-cations in order to cover a wide geographic area, characterizinga cooperative network scenario. More than one source of spec-trum sensing information may be used to provide informationfor a real-time RF spectrum allocation. This proposed coop-erative network reduces the hidden node problem e↵ect [27],providing information to discover distinct sectors , thereforeimproving the RF spectrum usage e�ciency [28].
Traditional CR implementations defines a radio that is ableto sense the spectrum, while performing its usual communica-tion functionality [2, 29]. Since the objective is to employ lowresource devices that may not have enough processing capac-ity to run a spectrum sensing algorithm, the SCs may be usedas a support system to existent fixed frequency systems. Forthis reason, in the proposes system, the SCs are sensing onlydevices. It is feasible to implement the sensing algorithm overmore powerful IoT devices. In context of IoT, a network com-monly has its own border router or gateway that act as a net-work coordinator and interface to the Internet. The SC acquiressamples from RF spectrum, demodulating them to a basebanddigital signal. The digital signal is delivered to the process-ing board, which encapsulates the RF information into TCP/IPpackets to be sent to a SCC.
2.2.2. Sensing Cell Controller (SCC)The sensing cell controller (SCC) has two important roles
in the proposed system: (i) it configures the SC receiver pa-rameters; (ii) it performs the energy detector computation to
be sent to SISA. The SCC runs on standard desktop computerand all energy detection algorithm is performed by applyingpreviously-developed GNU Radio framework [30], which is afree software tool that provides a set of processing blocks withfocus on SDR usage. By controlling the SC parameters, such asradio central frequency and radio bandwidth, it allows to sense awide RF spectrum. This is important since the low-cost receiverused in this work has only 2 MHz of reception bandwidth. Thecomputed RF spectrum energy information is then sent to theSISA block.
2.2.3. Sensing Information Storage and Analysis (SISA)The SISA block relies on a specific algorithm that in able to
collect data from many SCCs and store this information in adatabase. Another algorithm may consult this database in orderto set up a customized and broader information database on theRF spectrum usage. The SISA information may be based on aspecific region, a specific RF spectrum band or some calendarrange. SISA provides a database information on the RF spec-trum utilization divided in hours of a day, based on each SCCconnected to it. The SISA has an API that allows some CR in-terested on its sensing information to put queries on spectruminformation usage statistics.
2.2.4. Spectrum Sensing Based on Energy DetectionEnergy detectors stands for a suboptiomal very lightweight
algorithm and is considered the most simple spectrum sensingtechnique [31]. It has been chosen to enable the use of low-costcomponents. Additionally, it is the most appropriate techniquewhen the transmitted signal is unknown [32].
The energy for N received RF signal X may be calculated asfollows and the resultant value defines the test statistic variableT :
T =1N
NX
n=1
���X(n)2��� (1)
3
Cognitive Radio in the Context of IoT using a Novel Future Internet Architecture Called NovaGenesis
ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.cellcontroller_latitude > < 1 s -22.257360 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.cellcontroller_longitude > < 1 s -45.696651 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.cellcontroller_id > < 1 s a65faefc-56f7-11e5a483-001dbaefa596 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_sectors > < 1 s 1 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_freq_min > < 1 s 100000000 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_bw_max > < 1 s 2048000 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_bw_min > < 1 s 1024000 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_direction > < 1 s 0 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_freq_max > < 1 s 1800000000 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_freq_stop > < 2 s 930000000 -1 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_freq_start > < 2 s 900000000 -1 > ]ng -sr --b 0.1 [ < 1 s 17 > < 1 s SSS01.sensing_bw > < 1 s 1000000 > ]
Figure 9: SSS o↵er in NovaGenesis format to RMS.
SCC SSS NRS RMS
a a
b b
ccde
e
ff
gghh
ii
i
jj
kkll
m
Figure 10: Example of two applications in a simple link scenario.
TCP/IP
Ethernet
SCC IO
TCP/IP
SCPUSH/ PULL IA DAO
Ethernet
SISA DB
CLIENT/SERVER CLIENT/SERVER
EthernetEthernet
PUSH/PULL
Figure 11: Stack for cooperative spectrum sensing based on TCP/IP andZeroMQ (ZMQ) push/pull.
Naming: Content and services are accessed using their self-verifying names (SVNes). Message forwarding/routing also
Table 1: Comparison between scenarios with and without NovaGenesis.Aspect ZMQ and TCP/IP NovaGenesisNaming TCP socket names
(ports) and IP ad-dresses
Host, operating system,services, and content nat-ural language and self-verifying names
Name resolution Domain name service(DNS)
PSS, GIRS and HTS
Comm. model Receiver accepts all Publish/subscribeService-orienteddesign
Only on the WWW Applied to all software
Life-cycling Service-orientedarchitecture, e.g.RESTful
For all services and con-tents
Contract-basedoperation
Not typical For all services
Protocol imple-mentation
As Linux kernel com-ponents
As services that followSOD. User space for now
employs SVNes. In contrast, ZMQ and TCP/IP only allowsstructured natural language names, which do not have the in-trinsic security characteristics of SVNes [21].
Name Resolution: In current Internet it is provided by DNS.In NovaGenesis, the NRS does a similar role, but using pub/subof domain name records.
Limited Service-Orientation: In ZMQ/Internet, theservice-oriented design (SOD) is employed only on the WWW,while in NovaGenesis it is for all services, including network-ing ones.
Life-cycling: It encompasses the dynamic composition ofservices and their contents. In the Internet architecture it ispresent only at WWW. In NovaGenesis, life-cycling is intrin-sic to any entity: content, services, operating systems, hosts,etc. The same pattern happens for contract-based operation.
Deployment in Hosts: Internet protocols are implemented atthe core of operating systems. NovaGenesis protocols in hostsare implemented as services that follow SOD paradigm.
3.6. Next Steps and Open ChallengesWe plan to implement the complete Figure 1 scenario in
NovaGenesis, with the aim of extending NG services to con-trol Wi-Fi access points based on RMS decisions. In addition,we have already applied NovaGenesis implementation for SDN[45]. We are also extending our name resolution service to hi-erarchical domains, as an alternative to DNS. We have already
9
< n type E1 E2 E3 E4 ... En >
where
n is the number of elements in the argument vector.type is the type of the elements in the argument vector.E1 E2 E3 E4 ... En are the elements of the argument vector.
3.4. Representing a Spectrum Cell Controller inside Nova-Genesis
In this Subsection, we describe two new services developedfor NovaGenesis to interoperate and manage the low cost col-laborative sensing approach presented in Section 2. The aim isto converge the spectrum sensing approach for IoT with NG“clean slate” FIA, taking advantage from the benefits of allthese research areas. The section presents an extension of ourprevious work on CRN with NovaGenesis [15].
3.4.1. Spectrum Sensing ServiceThe spectrum sensing service (SSS) has been developed to
expose dedicated spectrum sensing hardware or a software-defined radio (SDR) to other NG services. It exposes devicefeatures, capabilities, configurations, and details of availablespectrum sampling procedures. Other NG services can dis-cover, negotiate and contract spectrum sensing functionality viatheir SSS representatives. This process is also a gateway for: (i)dedicated spectrum sensing hardware or SDR, translating NGcommand lines to non NG configurations, e.g. JSON; and for(ii) interconnection of TCP/IP and NG stacks, as illustrated inFigure 4. Messages coming from the SCC are encapsulatedover TCP/IP using ZeroMQ2 (ZMQ) push/pull sockets [41] anddelivered to the SSS. Inside NovaGenesis, the SSS changes topublish/subscribe (pub/sub) model instead of ZMQ’s push/pull,publishing and subscribing name bindings and information ob-jects (like SLAs or spectrum samples) to/from name resolutionservice (NRS3).
NG
Ethernet
SCC SSS
PUB/SUB
PGCS
NG
Ethernet
PGCSNRS RMS
TCP/IP
SC
EthernetEthernet
CLIENT/SERVER PUSH/ PULL
Figure 4: Stack for NovaGenesis interoperability with SCC. SSS provides theinterconnection between TCP/IP and NG stacks. SCC sends spectrum samplesto SSS using ZMQ. Inside NG, the communication model is pub/sub.
2ZeroMQ is a library for asynchronous exchanging of messages. In thepush/pull communication model, a push socket distributes a message to one ormore pull sockets, which read the message delivered over TCP/IP.
3NRS is a short term for the set PSS, GIRS and HTS.
In Figure 4, the SSS communicates with the SCC throughthree ZMQ push/pull socket connections, which form two com-munication channels, one for data and another for software-control settings. The data channel carries the spectral sensinginformation obtained by the components SC (Section 2.2.1) andSCC (Section 2.2.2). The setup channel is formed by the sec-ond and third connections and it is used by the NovaGenesis toobtain and send settings for these SC and SCC blocks.
The information exchanged between SSS and SCC are struc-tured in strings in JSON format. It is encoded in key/value pairs,in which the key field identifies the name of a parameter orcommand, tied to its value. The configuration channel to Nova-Genesis can perform two operations: the commands get infoand set config.
{"get_info": ""
}
Figure 5: get info command in JSON format.
get info: The get info command (Figure 5) is sent by SSSto SCC in order to request the spectral sensing available func-tionalities, identifying information of the sensing cell and theparameters of the current configuration of spectral sensing. Anexample of a get info answer is shown in Figure 6. In this ex-ample, the answer contains: (i) the sensing capabilities of theSCC in the key capacities; (ii) the cell identification informa-tion in the key cell info; and (iii) the current spectrum sensingconfiguration on key current config.
set config: This command is sent from SSS to SCC to adjustspectrum sensing parameters according to RMS. The parame-ters that can be adjusted are shown in the Figure 7. They arethe start and end sampling frequencies in Hz, respectively. Thesampling bandwidth is also in Hz.
data: The spectrum energy data is continuously transmittedfrom SCC to SSS. The Figure 8 illustrates the format of this
{"capacities": {
"sensing_freq_min": "100000000","sensing_freq_max": "1800000000","sensing_bw_min": "1024000","sensing_bw_max": "2048000","sensing_sectors": "1","sensing_direction": "0"
},"cell_info": {
"scc_id": "5adc8dfc-66a0-11e5-a257-001dbaef596","scc_location": "-22.257360, -45.696651"
},"current_config": {
"sensing_freq_start": ["900000000", "-1" ],"sensing_freq_stop": ["930000000", "-1"],"sensing_bw": "2048000"
}}
Figure 6: Answer transmitted from SCC to SSS.
7
a result similar to the previous ones obtained over TCP/IP. Fi-nally, in Figure 21 it is plotted the mean round trip time (RTT)spend by the RMS to subscribe spectrum sensing objects fromPSS/GIRS/HTS. In the first 9 hours, approximately, the RTTremained linear about 5.2 ms. After, it su↵ered a small increaseprobably due to the large amount of sample files stored at theHTS. All the samples have been stored. As a conclusion, wehave successfully demonstrated a straightforward and innova-tive convergence of IoT, FI and cognitive radio.
Figure 18: Fragment of a TCP segment transporting a spectrum sample in JSONformat from SCC to SSS.
5. Conclusions
This paper presented, for the first time, a successful conver-gence of cognitive radio network (CRN), Internet of Things(IoT) and a future Internet architecture (FIA) called Nova-Genesis. We first report the concept and implementation of alow-cost embedded cooperative sensing and cognitive radio ar-chitecture for IoT applications. The proposed technology solu-tion can be considered potential for wireless sensor networks, inwhich software-control is provided using current Internet tech-nology. Moreover, we have experimentally demonstrated theuse of cooperative spectrum sensing based on energy detectionhas overcome the hidden node problem, which is very com-mon in cooperative cognitive radio networks and for sure willbe present on IoT scenarios. An experimental performance in-vestigation based on packet error rate as a function of RSSI hasdemonstrated the e�ciency and applicability of the proposedCRN approach.
Our second contribution relies on the extension of Nova-Genesis with novel services to interoperate with the aforemen-tioned embedded spectrum sensing and software-control ap-proach. In this sense, we reported implementation of two newfuture Internet services: spectrum sensing service (SSS) andresource management service (RMS). SSS interoperates witha sensing cell controller (SCC), which has a GNU radio im-plementation for determining energy level at channels on 915MHz ISM band. The SCC spectrum samples are sent to theSSS using TCP/IP. SSS translates the data objects from JSONformat to NovaGenesis and publishes them to the RMS (with-out TCP/IP). RMS subscribes the data objects according to theirself-verifying names (SVNes). The data objects are transferred
Figure 19: Fragment of a NovaGenesis message transporting a spectrum sampledirectly over Ethernet.
Figure 20: Spectrum sensing output obtained using NovaGenesis as transportnetwork instead of TCP/IP.
Figure 21: Mean spectrum sample subscription RTT from RMS.
in NovaGenesis messages directly over Ethernet. We demon-strated that NovaGenesis provides an equivalent spectrum sens-ing data objects transport service for IoT.
Our experimental proof-of-concept demonstrates severalnovelties that are typically found only in future Internet re-search: (i) exposition and discovery of next generation wire-less services; (ii) contract-based operation with SLA establish-
13
Amostras((transportadas((sem(TCP/IP,((Somente(NG((sobre(Ethernet(
TCP/IP NG TCP/IP
SCC SSS PGCS
NG
PGCSHTS GIRS PSS RMS
SCC - Sensing Cell Controller SSS - Spectrum Sensing Service HTS - Hash Table Service GIRS - Generic Indirection Resolution Service PSS - Publish/Subscribe Service PGCS - Proxy/Gateway/Controller Service RMS - Resource Management Service
LEGEND:
Figure 14: Experimental scenario for the interoperability test of collaborative spectrum sensing with NovaGenesis.
ng -m --cl 0.1 [ < 1 s ... > < 4 s 0BD95286 ED12F3ED 342DD4C5 B8101939 > < 4 s 0BD95286 ED12F3ED 449B0B0C 6FDF0A76 > ]...ng -p --b 0.1 [ < 1 s 2 > < 1 s 19656CF3 > < 1 s 342DD4C5 > ]ng -p --b 0.1 [ < 1 s 1 > < 1 s 19656CF3 > < 1 s Wi-Fi > ]...ng -message --type 0.1 [ < 1 s 1 > ]ng -message --seq 0.1 [ < 1 s 28 > ]ng -scn --seq 0.1 [ < 1 s 78A8DC70 > ]
Figure 15: Exposition of SSS keywords and self-verifying names.
ng -m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 0BD95286 ED12F3ED 342DD4C5 B8101939 > < 4 s 0BD95286 ED12F3ED 449B0B0C 6FDF0A76 > ]ng -p --notify 0.1 [ < 1 s 18 > < 1 s 3182F342 > < 1 s Service_Offer_2026721035.txt > < 5 s pub FC0AF0EB 1449F6D8 1C873D85 6D6CEA2B > ]ng -info --payload 0.1 [ < 1 s Service_Offer_2026721035.txt > ]ng -p --b 0.1 [ < 1 s 2 > < 1 s 3182F342 > < 1 s B8101939 > ]ng -p --b 0.1 [ < 1 s 2 > < 1 s 3182F342 > < 1 s 342DD4C5 > ]ng -p --b 0.1 [ < 1 s 2 > < 1 s 3182F342 > < 1 s ED12F3ED > ]ng -p --b 0.1 [ < 1 s 9 > < 1 s 3182F342 > < 1 s 0BD95286 > ]ng -message --type 0.1 [ < 1 s 1 > ]ng -message --seq 0.1 [ < 1 s 56 > ]ng -scn --seq 0.1 [ < 1 s 63FEFE81 > ]
There is a payload of 971 bytes
Figure 16: Service o↵er from SSS to RMS.
ng -m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 0BD95286 ED12F3ED 342DD4C5 B8101939 > < 4 s 0BD95286 ED12F3ED 449B0B0C 6FDF0A76 > ]ng -p --notify 0.1 [ < 1 s 18 > < 1 s EDD33B4D > < 1 s SSSFile_7.txt > < 5 s pub FC0AF0EB 1449F6D8 1C873D85 6D6CEA2B > ]ng -info --payload 0.1 [ < 1 s SSSFile_7.txt > ]...ng -scn --seq 0.1 [ < 1 s A65E7906 > ]
There is a payload of 446 bytes
Figure 17: Spectrum sensing data being carried in the payload of a publish/notify message.
12
Serviços)desenvolvidos)para)o)protó1po.)
Cognitive Radio in the Context of IoT using a Novel Future Internet Architecture Called NovaGenesis
Services developed for prototype
Spectrum sensing samples transported over NG/Ethernet
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.910−4
10−3
10−2
10−1
100 Name Resolution Server Utilization (log)
Probability a name record is on a resolver cache (pi,o)
Mea
n U
tiliz
atio
n (U
)
DNS RootDNS TLDsDNS SLDsDNS ResolversNG RootNG TLDsNG SLDsNG ResolversMDHT RootMDHT TLDsMDHT SLDsMDHT Resolversi
App
γ0,0
o
AppApp
o
AppApp
o
App
γ0,N γ1,0 γ1,N γR,NγR,0
i i i0 1 R
o inatel hufsio io
io io
io
br kr
io
s = 0 … Sunisinos
SLDs
r = 0 … RResolvers
i = 0 … NApplications
t = 0 … TTLDs
z=0 …Zroot
pi,o
ps,t
1 1
pt,z
pi,o pi,o pr,s
ps,s
NG
Nó#de#Internet#das#coisas##medindo#temperatura#da#sala#
Amostras##de#temperatura#transportadas#sem#TCP/IP,##somente#NG##sobre#Wi<Fi#
Fig. 8. Experimental scenario with: (i) NovaGenesis core services and IoT client application in the left; (ii) the NovaGenesis
embedded proxy/gateway (EPGS) on NXP’s LPC1769 device in the middle; and (iii) a computer with LPCXpressoTM to compile
and deploy the EPGS (plus EventOSTM) image on LPC.
ng -m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 0BD95286 ED12F3ED 7E764DC1 4D623F20 > < 4 s empty empty empty empty > ]
ng -hello --ihc 0.2 [ < 6 s A4324A2D AB9B70B4 57ECEB4F Wi-Fi wlan0 ac:22:0b:c9:df:3b > < 4 s 0BD95286 ED12F3ED
8E8B52EC 7EA46815 > ]
ng -scn --seq 0.1 [ < 1 s 1A81A5E3 > ]
Fig. 9. A “hello” message sent by the PGCS to the EPGS.
ng -m --cl 0.1 [ < 1 s 28FD4420 > < 4 s 4C7CF9B2 5F472DA7 1A53F830 NULL > < 4 s empty empty empty empty > ]
ng -hello --ihc 0.1 [ < 5 s NULL NULL Wi-Fi wlan0 ac:22:0b:13:01:34 > ]
ng -scn --seq 0.1 [ < 1 s 604007EC > ]
Fig. 10. A “hello” message sent by EPGS to PGCS.
5.2. Exposition and Discovery
In this step, both PGCS and client application expose a set of keywords and SVNs to facilitate discovery. Fig.
11 contains a PGCS log capture with an “exposition” message. The target of this message is the PSS, identified
by the tuple 0BD95286 ED12F3ED 8E8B52EC 7EA46815. Every ng –p –b 0.1 command line publishes a name
Future Internet of “Things”: The NovaGenesis Model
Temperature samples transported over NG/Wi-Fi
Internet of things node with embedded NG
© Antônio M. Alberti 2015© Antônio M. Alberti 2014
Obrigado!
WWW.INATEL.BR/ NOVAGENESIS
WWW.INATEL.BR/ ICTLAB