ict lab overview

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 Cell


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