A keference Arch|tecture

for the Internet of 1h|ngs

vers|on 0.8.0



2
Introduct|on

1hls whlLe paper lnLroduces a !"#"$"%&" ($&)*+"&+,$" for Lhe lnLerneL of 1hlngs (lo1): Lhls
lncludes Lhe devlces as well as Lhe server-slde and cloud archlLecLure requlred Lo lnLeracL wlLh
and manage Lhe devlces. 1he alm of Lhls ls Lo provlde archlLecLs and developers of lo1 pro[ecLs
wlLh an effecLlve sLarLlng polnL LhaL covers Lhe ma[or requlremenLs of lo1 pro[ecLs and sysLems.

1he paper lncludes:
An overvlew of Lhe lnLerneL of 1hlngs
Challenges unlque Lo lo1
8equlremenLs for an lo1 8eference ArchlLecLure
1he 8eference ArchlLecLure
Mapplng of Lhe 8eference ArchlLecLure onLo Lhe WSC2 laLform
Concluslons and areas for fuLure work

1he lnLerneL of 1hlngs ls an umbrella Lerm LhaL lncludes mulLlple dlfferenL caLegorles:
Wlreless Sensor neLworks
lnLerneL-connecLed wearables
Low power embedded sysLems
8llu enabled Lracklng
use of moblle phones Lo lnLeracL wlLh Lhe real world (e.g. senslng)
uevlces LhaL connecL vla 8lueLooLh enabled moblle phones Lo Lhe lnLerneL
SmarL Pomes
ConnecLed Cars
And many more

1he resulL ls LhaL no slngle archlLecLure wlll sulL all Lhese areas and Lhe requlremenLs each area
brlngs. Powever, a modular scalable archlLecLure LhaL supporLs addlng or subLracLlng
capablllLles, as well as supporLlng many requlremenLs across a wlde varleLy of Lhese use cases ls
lnherenLly useful and valuable. lL provldes a sLarLlng polnL for archlLecLs looklng Lo creaLe lo1-
soluLlons as well as a sLrong basls for furLher developmenL. 1hls paper proposes such a
8eference ArchlLecLure (8A). 1he 8A musL cover mulLlple aspecLs lncludlng Lhe cloud or server-
slde archlLecLure LhaL allows us Lo monlLor, manage, lnLeracL wlLh and process Lhe daLa from
Lhe lo1 devlces, Lhe neLworklng model Lo communlcaLe wlLh Lhe devlces, and Lhe agenLs and
code on Lhe devlces Lhemselves, as well as Lhe requlremenLs on whaL sorL of devlce can supporL
Lhls 8A.

1he reference archlLecLure LhaL we propose ls lnherenLly vendor neuLral and noL speclflc Lo a
seL of Lechnologles, alLhough lL ls hlghly lnfluenced by besL of breed open source pro[ecLs and
Lechnology. ln addlLlon, we provlde a mapplng of Lhls reference archlLecLure onLo Lhe WSC2
Cpen Source producLs and pro[ecLs and we have demonsLraLed an lmplemenLaLlon of Lhls
reference archlLecLure on Lhe WSC2 laLform.




3
We also explore areas where Lhls reference archlLecLure can be exLended furLher and also areas
where we expecL Lo see furLher work.

1he Internet of 1h|ngs - a Short Cverv|ew
1he lnLerneL of 1hlngs (lo1) refers Lo Lhe seL of devlces and sysLems LhaL lnLerconnecL real
world sensors and acLuaLors Lo Lhe lnLerneL. 1hls lncludes many dlfferenL sysLems, lncludlng:
lnLerneL connecLed cars,
wearable devlces lncludlng healLh and flLness monlLorlng devlces , waLches, and even
human lmplanLed devlces,
smarL meLers and smarL ob[ecLs,
home auLomaLlon sysLems and llghLlng conLrols,
smarLphones whlch are lncreaslng belng used Lo measure Lhe world around Lhem, and
wlreless sensor neLworks LhaL measurlng weaLher, flood defenses, Lldes and more.

1he growLh of Lhe number and varleLy of devlces LhaL are collecLlng daLa ls lncredlbly rapld. A
sLudy by Clsco
1
esLlmaLes LhaL Lhe number of lnLerneL-connecLed devlces overLook Lhe human
populaLlon ln 2010, and LhaL Lhere wlll be 30 bllllon lnLerneL-connecLed devlces by 2020.

1here are of course Lwo key aspecLs Lo Lhe lo1: Lhe devlces Lhemselves and Lhe server-slde
archlLecLure LhaL supporLs Lhem. ln facL Lhere ls ofLen a Lhlrd-caLegory as well: ln many cases
Lhere may be a low power gaLeway LhaL performs aggregaLlon, evenL processlng, brldglng eLc.
LhaL mlghL slL beLween Lhe devlce and Lhe wlder lnLerneL.

ln boLh cases Lhe devlces probably have lnLermlLLenL connecLlons based on facLors such as
C8S connecLlvlLy, baLLery dlscharglng, radlo lnLerference, or slmply belng swlLched off.

1here are effecLlvely Lhree classes of devlce:
1he smallesL devlces have embedded 8-blL SysLem-Cn-Chlp (SCC) conLrollers. A good
example of Lhls ls Lhe Cpen Source Pardware plaLform Ardulno: e.g Lhe Ardulno uno
plaLform and oLher 8-blL Ardulnos. 1hese Lyplcally have no operaLlng sysLem.
1he nexL level up are Lhe sysLems based on ALheros and A8M chlps LhaL have a very
llmlLed 32-blL archlLecLure. 1hese ofLen lnclude small home rouLers and derlvaLlves of
Lhose devlces. Commonly Lhese run a cuL-down or embedded Llnux plaLform such as
CpenW81, or dedlcaLed embedded operaLlng sysLems. ln some cases Lhey may noL use
an CS. An example of Lhls would be Lhe recenLly announced Ardulno Zero, or Lhe
Ardulno ?un.
1he mosL capable lo1 plaLforms are full 32-blL or 64-blL compuLlng plaLforms. 1hese
sysLems, such as Lhe 8aspberry l or Lhe 8eagle8one, may run full a full Llnux CS or
anoLher sulLable CperaLlng SysLem such as Androld. ln many cases Lhese are elLher
moblle phones or based on moblle-phone Lechnology. 1hese devlces may also acL as
gaLeways or brldges for smaller devlces: for example lf a wearable connecLs vla

1
hLLp://www.clsco.com/web/abouL/ac79/docs/lnnov/lo1_l8SC_0411llnAL.pdf



4
8lueLooLh Low Lnergy Lo a moblle phone or 8aspberry l, whlch Lhen brldges LhaL onLo
Lhe wlder lnLerneL.

1he communlcaLlons beLween devlces and Lhe lnLerneL or Lo a gaLeway lncludes many dlfferenL
models:
ulrecL LLherneL or Wl-ll connecLlvlLy uslng 1C or uu (we wlll look aL proLocols for Lhls
laLer)
8lueLooLh Low Lnergy
near lleld CommunlcaLlon (nlC)
Zlgbee or oLher mesh radlo neLworks

S8l and polnL-Lo-polnL radlo llnks
uA81 or serlal llnes
Sl or l2C wlred buses

1he followlng flgure shows Lhese Lwo ma[or modes of connecLlvlLy.

I|gure 1 - Io1 connect|v|ty opt|ons
1hls secLlon has provlded a shorL overvlew of lo1 devlces and sysLems. lL ls noL deslgned Lo be
comprehenslve or even exLenslve buL slmply Lo provlde enough background Lo supporL Lhe
dlscusslon of requlremenLs and capablllLles below. 1here are many furLher resources avallable,



3
whlch are Loo numerous Lo llsL. Powever, we can polnL readers Lo an academlc survey, whlch ls
avallable here
2
.

Is there va|ue |n a keference Arch|tecture for the Io1?
1here are several reasons why a 8eference ArchlLecLure for lo1 ls a -../ +)*%-0
lo1 devlces are lnherenLly connecLed - we need a way of lnLeracLlng wlLh Lhem, ofLen
wlLh flrewalls, neLwork Address 1ranslaLlon (nA1) and oLher obsLacles ln Lhe way.
1here are bllllons of Lhese devlces already and Lhe number ls growlng qulckly: we need
an archlLecLure for scalablllLy. ln addlLlon, Lhese devlces are Lyplcally lnLeracLlng 24x7, so
we need a hlghly-avallable (PA) approach LhaL supporLs deploymenL across daLacenLers
Lo allow ulsasLer 8ecovery (u8).
1he devlces may noL have uls and cerLalnly are deslgned Lo be everyday" usage, so we
need Lo supporL auLomaLlc and managed updaLes, as well as belng able Lo remoLely
manage Lhese devlces.
lo1 devlces are very commonly used for collecLlng and analyzlng personal daLa. A model
for managlng Lhe ldenLlLy and access conLrol for lo1 devlces and Lhe daLa Lhey publlsh
and consume ls a key requlremenL.

Cur alm ls Lo provlde an archlLecLure LhaL supporLs Lhese varlous approaches.

ln Lhe nexL secLlon we wlll dlg lnLo Lhese requlremenLs deeper and ouLllne Lhe speclflc
requlremenLs we are looklng for ln a range of caLegorles.

kequ|rements for a keference Arch|tecture
1here are some speclflc requlremenLs for lo1 LhaL are unlque Lo lo1 devlces and Lhe
envlronmenLs LhaL supporL Lhem. lor example, many requlremenLs emerge from Lhe llmlLed
form-facLors and power avallable Lo lo1 devlces. CLher requlremenLs come from Lhe way ln
whlch lo1 devlces are manufacLured and used: Lhe approaches are much more llke LradlLlonal
consumer producL deslgn Lhan exlsLlng lnLerneL approaches. Cf course Lhere are a number of
exlsLlng besL pracLlces for Lhe server-slde and lnLerneL connecLlvlLy LhaL need Lo be
remembered and facLored ln.

We can summarlze Lhe overall requlremenLs lnLo some key caLegorles:
ConnecLlvlLy and communlcaLlons
uevlce ManagemenL
uaLa collecLlon, analysls, and acLuaLlon
ScalablllLy
SecurlLy



2
hLLp://www.sclencedlrecL.com/sclence/arLlcle/pll/S1389128610001368



6
1.%%"&+*2*+3 4%/ &.55,%*&4+*.%6
LxlsLlng proLocols such as P11 have a very lmporLanL place for many devlces. Lven an 8-blL
conLroller can creaLe slmple CL1 and CS1 requesLs and P11 provldes an lmporLanL unlfled
(and unlform) connecLlvlLy. Powever, Lhe overhead of P11 and some oLher LradlLlonal lnLerneL
proLocols can be an lssue for Lwo maln reasons. llrsLly, Lhe memory slze of Lhe program can be
an lssue on small devlces. Powever, Lhe blgger lssue ls Lhe power requlremenLs. ln order Lo
meeL Lhese requlremenLs, we need a slmple, small and blnary proLocol. We wlll look aL Lhls ln
more deLall below. We also requlre Lhe ablllLy Lo cross flrewalls.

ln addlLlon, Lhere are devlces LhaL connecL dlrecLly and Lhose LhaL connecL vla gaLeways. 1he
devlces LhaL connecL vla a gaLeway poLenLlally requlre Lwo proLocols: one Lo connecL Lo Lhe
gaLeway, and Lhen anoLher from Lhe gaLeway Lo Lhe cloud.

llnally, Lhere ls obvlously a requlremenL for our archlLecLure Lo supporL LransporL and proLocol
brldglng: for example, we may wlsh Lo offer a blnary proLocol Lo Lhe devlce, buL allow an P11-
based Al Lo conLrol Lhe devlce whlch we expose Lo Lhlrd parLles.

7"2*&" 84%4-"5"%+
Whlle many lo1 devlces are noL acLlvely managed, Lhls ls noL necessarlly ldeal. We have seen
acLlve managemenL of Cs, moblle phones and oLher devlces become lncreaslngly lmporLanL,
and Lhe same Lra[ecLory ls boLh llkely and deslrable for lo1 devlces. WhaL are Lhe requlremenLs
for lo1 devlce managemenL? 1he followlng llsL covers some wldely deslrable requlremenLs:
1he ablllLy Lo dlsconnecL a rogue or sLolen devlce
1he ablllLy Lo updaLe Lhe sofLware on a devlce
updaLlng securlLy credenLlals
8emoLely enabllng or dlsabllng cerLaln hardware capablllLles
LocaLlng a losL devlce
Wlplng secure daLa from a sLolen devlce
8emoLely re-conflgurlng Wl-ll, C8S or neLwork parameLers
1he llsL ls noL exhausLlve, and conversely covers aspecLs LhaL may noL be requlred or posslble
for cerLaln devlces.

74+4 1.99"&+*.%: (%4936*6: 4%/ (&+,4+*.%
A few lo1 devlces have some form of ul, buL ln general lo1 devlces are focused on offerlng one
or more sensors, one or more acLuaLors, or a comblnaLlon of boLh. 1he requlremenLs of Lhe
sysLem are LhaL we can collecL daLa from very large numbers of devlces, sLore lL, analyze lL, and
Lhen acL upon lL.

1he reference archlLecLure ls deslgned Lo manage very large numbers of devlces. lf Lhese
devlces are creaLlng consLanL sLreams of daLa, Lhen Lhls creaLes a slgnlflcanL amounL of daLa.
1he requlremenL ls for a hlghly scalable sLorage sysLem, whlch can handle dlverse daLa and hlgh
volumes.




7
1he acLlon may happen ln near real Llme, so Lhere ls a sLrong requlremenL for real-Llme
analyLlcs. ln addlLlon, Lhe devlce also needs Lo be able Lo analyze and acL on daLa. ln some cases
Lhls wlll be slmple small, embedded loglc. Cn more powerful devlces we can also uLlllze more
powerful englnes for evenL processlng and acLlon.

;&494<*9*+3
Any server-slde archlLecLure would ldeally be hlghly scalable, and Lo be able Lo supporL mllllons
of devlces all consLanLly sendlng, recelvlng and acLlng on daLa. Powever, many hlgh-scalablllLy
archlLecLures" have come wlLh an equally hlgh prlce - boLh ln hardware, sofLware and ln
complexlLy. An lmporLanL requlremenL for Lhls archlLecLure ls Lo supporL scallng from a small
deploymenL Lo a very large number of devlces. LlasLlc scalablllLy and Lhe ablllLy Lo deploy ln a
cloud llke Amazon LC2 are essenLlal. 1he ablllLy Lo scale Lhe server-slde ouL on small cheap
servers ls an lmporLanL requlremenL Lo make Lhls an affordable archlLecLure for small
deploymenLs as well as large.

;"&,$*+3
SecurlLy ls one of Lhe mosL lmporLanL aspecLs for lo1. lo1 devlces are ofLen collecLlng hlghly
personal daLa, and by Lhelr naLure are brlnglng Lhe real world onLo Lhe lnLerneL (and vlce-
versa). 1hls brlngs Lwo caLegorles of rlsks:
8lsks LhaL are lnherenL ln any lnLerneL sysLem, buL LhaL producL/lo1 deslgners may noL
be aware of
Speclflc rlsks LhaL are unlque Lo lo1 devlces

1he flrsL caLegory lncludes such slmple Lhlngs as locklng down open porLs on devlces (such as
Lhe lnLerneL-aLLached frldge LhaL had an unsecured SM1 server and was belng used Lo send
spam).

1he second caLegory lncludes lssues speclflcally relaLed Lo lo1 hardware. lor example, Lhe
devlce may have lLs secure lnformaLlon read. lor example, many lo1 devlces are Loo small Lo
supporL proper asymmeLrlc encrypLlon. AnoLher speclflc example ls Lhe ablllLy for someone Lo
aLLack Lhe hardware Lo undersLand securlLy. As an example, Lhe unlverslLy securlLy researchers
who famously reverse-englneered and broke Lhe Mlfare Classlc 8llu card soluLlon
3
. 1hese sorL
of reverse englneerlng aLLacks are an lssue compared wlLh pure web soluLlons where Lhere ls
ofLen no avallable code Lo aLLack (l.e. compleLely server-slde lmplemenLaLlon).

1wo very lmporLanL speclflc lssues for lo1 securlLy are Lhe concerns abouL ldenLlLy and access
managemenL. ldenLlLy ls an lssue where Lhere are ofLen poor pracLlces lmplemenLed. lor
example, Lhe use of userlds/passwords wlLh devlces and machlne-Lo-machlne (M2M) ls a
common mlsLake. ldeally Lhese should be replaced wlLh managed Lokens such as Lhose
provlded by CAuLh/CAuLh2
4
.

3
hLLp://www.cs.bham.ac.uk/~garclaf/publlcaLlons/ALLack.MllA8L.pdf
4
hLLp://oauLh.neL/



8

AnoLher common lssue ls Lo hard-code access managemenL rules lnLo elLher cllenL- or server-
slde code. A much more flexlble and powerful approach ls Lo uLlllze models such as ALLrlbuLe
8ased Access ConLrol" and ollcy 8ased Access ConLrol". 1he mosL well known of Lhese
approaches ls LhaL provlded by Lhe xACML sLandard
3
. Such approaches remove access conLrol
declslons from hard-coded loglc and exLernallze Lhem lnLo pollcles, whlch glve:
More powerful and approprlaLe declslons,
Whlch can poLenLlally be based on conLexLs such as locaLlon, or whlch neLwork ls belng
used, or Lhe Llme of day,
1he access conLrol can be analyzed and audlLed, and
ollcles can be updaLed and changed, even dynamlcally, wlLhouL recodlng or modlfylng
devlces.

Cur securlLy requlremenLs are Lherefore:
1o supporL encrypLlon on devlces LhaL are powerful enough,
1o supporL a modern ldenLlLy model based on Lokens and %.+ userlds/passwords,
1o supporL Lhe managemenL of keys and Lokens as smooLhly / remoLely as posslble, and
1o supporL pollcy-based and user-managed access conLrol for Lhe sysLem based on
xACML.

1hls concludes Lhe seL of requlremenLs LhaL we have ldenLlfled for Lhe 8A. Cf course, any glven
archlLecLure may add furLher requlremenLs. Some of Lhose may already be meL by Lhe
archlLecLure, and some may requlre furLher componenLs Lo be added. Powever, our deslgn ls
for a modular archlLecLure LhaL supporLs exLenslons, whlch copes wlLh Lhls demand.

ln Lhe nexL secLlon we lnLroduce Lhe archlLecLure and approach.

3
hLLps://www.oasls-open.org/commlLLees/Lc_home.php?wg_abbrev=xacml



9
1he Arch|tecture
1he 8A conslsLs of a seL of layers. Lach layer performs a clear funcLlon. Layers can be
lnsLanLlaLed by speclflc Lechnologles, and we wlll dlscuss opLlons for lmplemenLlng each layer.
1here are also some cross-cuLLlng/verLlcal layers such as securlLy/ldenLlLy managemenL.


I|gure 2 - keference Arch|tecture for Io1

1he layers are:
LxLernal CommunlcaLlons - Web/orLal, uashboard, Als
LvenL rocesslng and AnalyLlcs (lncludlng daLa sLorage)
AggregaLlon / 8us Layer - LS8 and Message 8roker
uevlce CommunlcaLlons
uevlces
1he cross-cuLLlng layers are:
uevlce ManagemenL
ldenLlLy and Access ManagemenL





10
=)" 7"2*&" >43"$
1he boLLom layer of Lhe archlLecLure ls Lhe devlce layer. uevlces can be of varlous Lypes, buL ln
order Lo be consldered lo1 devlces, Lhey musL have some communlcaLlons LhaL elLher lndlrecLly
or dlrecLly aLLaches Lo Lhe lnLerneL. Lxamples of dlrecL connecLlons are:
Ardulno wlLh Ardulno LLherneL connecLlon
Ardulno ?un wlLh a Wl-ll connecLlon
8aspberry l connecLed vla LLherneL or Wl-ll
lnLel Callleo connecLed vla LLherneL of Wl-ll
Lxamples of lndlrecLly connecLed devlce lnclude:
Zlg8ee devlces connecLed vla a Zlg8ee gaLeway
8lueLooLh or 8lueLooLh Low Lnergy devlces connecLlng vla a Moblle hone
uevlces communlcaLlng vla low power radlos Lo a 8aspberry l
1here are many more such examples of each Lype.

Lach devlce Lyplcally needs an ldenLlLy. 1he ldenLlLy may be one of Lhe followlng:
A unlque ldenLlfler (uulu) burnL lnLo Lhe devlce (Lyplcally parL of Lhe SysLem-on-Chlp, or
provlded by a secondary chlp
A uulu provlded by Lhe radlo subsysLem (e.g. 8lueLooLh ldenLlfler, Wl-ll MAC address)
An CAuLh2 8efresh/8earer 1oken (Lhls may be ln addlLlon Lo one of Lhe above)
An ldenLlfler sLored ln non-volaLlle memory such as LL8CM

lor Lhe reference archlLecLure we $"&.55"%/ LhaL every devlce has a uulu (preferably an
unchangeable lu provlded by Lhe core hardware) as well as an CAuLh2 8efresh and 8earer
Loken sLored ln LL8CM.

1he alm of Lhe CAuLh2 Loken ls Lo provlde a secured ldenLlLy Loken separaLe from Lhe core
lmmuLable ldenLlLy of each devlce. 1he 8earer 1oken ls used lnlLlally and passed Lo any server
or servlce LhaL needs ldenLlflcaLlon. 1he 8earer 1oken has a shorL(er) llfeLlme Lhan Lhe 8efresh
1oken. lf Lhe 8earer 1oken has explred Lhen Lhe 8efresh 1oken ls passed over Lo Lhe ldenLlLy
layer and Lhls creaLes an updaLed 8earer 1oken. lor more deLalls please see Lhe CAuLh2
speclflcaLlon. 1he speclflcaLlon ls based on P11, however (as we wlll dlscuss ln Lhe
communlcaLlons secLlon) Lhe reference archlLecLure also supporLs Lhese flows over MC11.

CerLaln devlces may also supporL

=)" 1.55,%*&4+*.%6 >43"$
1he communlcaLlon layer supporLs Lhe connecLlvlLy of Lhe devlces. 1here are mulLlple poLenLlal
proLocols for communlcaLlon beLween Lhe devlces and Lhe cloud. 1he mosL well known Lhree
poLenLlal proLocols are:
P11/P11S (and 8LS1ful approaches on Lhose)
MC11 3.1 / 3.1.1
ConsLralned AppllcaLlon roLocol (CoA)




11
LeL's Lake a qulck look aL each of Lhese proLocols ln Lurn.

P11 ls well known, and Lhere are obvlously many llbrarles LhaL supporL lL. 8ecause lL ls a
slmple LexL-based proLocol, many small devlces such as 8-blL conLrollers can parLlally supporL
Lhe proLocol - for example enough code Lo CS1 or CL1 a resource. 1he larger 32-blL based
devlces can uLlllze full P11 cllenL llbrarles LhaL properly lmplemenL Lhe whole proLocol.

1here are several proLocols opLlmlzed for lo1 use. 1he Lwo besL known are MC11
6
and CoA
7
.
MC11 was lnvenLed ln 1999 Lo solve lssues ln embedded sysLems and SCAuA. lL has been
Lhrough some lLeraLlons and Lhe currenL verslon (3.1.1) ls undergolng sLandardlzaLlon ln Lhe
CASlS MC11 1echnlcal CommlLLee
8
. MC11 ls a publlsh-subscrlbe messaglng sysLem based on a
broker model. 1he proLocol has a very small overhead (as llLLle as 2 byLes per message), and
was deslgned Lo supporL lossy and lnLermlLLenLly connecLed neLworks. MC11 was deslgned Lo
flow over 1C. ln addlLlon Lhere ls an assoclaLed speclflcaLlon deslgned for Zlg8ee-sLyle
neLworks called MC11-Sn (Sensor neLworks).

1he ConsLralned AppllcaLlon roLocol (CoA) ls a proLocol from Lhe lL1l LhaL ls deslgned Lo
provlde a 8LS1ful appllcaLlon proLocol modeled on P11 semanLlcs, buL wlLh a much smaller
fooLprlnL and a blnary raLher Lhan LexL-based approach. CoA ls a more LradlLlonal cllenL-server
approach raLher Lhan a brokered approach. CoA ls deslgned Lo be used over uu.

lor Lhe reference archlLecLure we have opLed Lo selecL MC11 as Lhe preferred devlce
communlcaLlon proLocol, wlLh P11 as an alLernaLlve opLlon.

1he reasons Lo selecL MC11 and noL CoA aL Lhls sLage are:
8eLLer adopLlon and wlder llbrary supporL for MC11,
Slmpllfled brldglng lnLo exlsLlng evenL collecLlon and evenL processlng sysLems, and
Slmpler connecLlvlLy over flrewalls and nA1 neLworks

Powever, boLh proLocols have speclflc sLrengLhs (and weaknesses) and so Lhere wlll be some
slLuaLlons where CoA may be preferable and could be swapped ln.

ln order Lo supporL MC11 we need Lo have an MC11 broker ln Lhe archlLecLure, as well as
devlce llbrarles. We wlll dlscuss Lhls wlLh regard Lo securlLy and scalablllLy laLer.

Cne lmporLanL aspecL wlLh lo1 devlces ls noL [usL for Lhe devlce Lo send daLa Lo Lhe
cloud/server, buL also Lhe reverse. 1hls ls one of Lhe beneflLs of Lhe MC11 speclflcaLlon:
because lL ls a brokered model, cllenLs connecL an ouLbound connecLlon Lo Lhe broker, wheLher
or noL Lhe devlce ls acLlng as a publlsher or subscrlber. 1hls usually avolds flrewall problems,
because Lhls approach works even behlnd flrewalls or vla nA1.

6
hLLp://mqLL.org
7
hLLp://Lools.leLf.org/hLml/drafL-leLf-core-coap-18
8
hLLps://www.oasls-open.org/commlLLees/mqLL/



12

ln Lhe case where Lhe maln communlcaLlons ls based on P11, Lhe LradlLlonal approach for
sendlng daLa Lo Lhe devlce would be Lo use P11 olllng. 1hls ls very lnefflclenL and cosLly: boLh
ln Lerms of neLwork Lrafflc as well as power requlremenLs. 1he modern replacemenL for Lhls ls
Lhe WebSockeL proLocol
9
, whlch allows an P11 connecLlon Lo be upgraded lnLo a full Lwo-way
connecLlon. 1hls Lhen acLs as a sockeL channel (slmllar Lo a pure 1C channel) beLween Lhe
server and cllenL. Cnce LhaL has been esLabllshed, lL ls up Lo Lhe sysLem Lo choose an ongolng
proLocol Lo Lunnel over Lhe connecLlon.

lor Lhe reference archlLecLure we once agaln recommend uslng MC11 as a proLocol wlLh
WebSockeLs. ln some cases, MC11 over WebSockeLs wlll be Lhe only proLocol: Lhls ls because lL
ls even more flrewall-frlendly Lhan Lhe base MC11 speclflcaLlon, as well as supporLlng pure
browser/!avaScrlpL cllenLs uslng Lhe same proLocol.

noLe LhaL whlle Lhere ls some supporL for WebSockeLs on small conLrollers such as Ardulno, buL
Lhe comblnaLlon of neLwork code, P11 and WebSockeLs would uLlllze mosL of Lhe avallable
code space on a Lyplcal Ardulno 8-blL devlce. 1herefore we only recommend Lhe use of
WebSockeLs on Lhe larger 32-blL devlces.

=)" (--$"-4+*.%?@,6 >43"$
An lmporLanL layer of Lhe archlLecLure ls Lhe layer whlch aggregaLes and brokers
communlcaLlons. 1hls ls an lmporLanL layer for Lhree reasons:
1. 1he ablllLy Lo supporL an P11 server and/or an MC11 broker Lo Lalk Lo Lhe devlces,
2. 1he ablllLy Lo aggregaLe and comblne communlcaLlons from dlfferenL devlces and Lo
rouLe communlcaLlons Lo a speclflc devlce (posslbly vla a gaLeway)
3. 1he ablllLy Lo brldge and Lransform beLween dlfferenL proLocols - for example Lo offer
P11-based Als LhaL are medlaLed lnLo an MC11 message golng Lo Lhe devlce.

1he aggregaLlon/bus layer provldes Lhese capablllLles as well as adapLlng lnLo legacy proLocols.
1he bus layer may also provlde some slmple correlaLlon and mapplng from dlfferenL correlaLlon
models (e.g. mapplng a devlce lu lnLo an owner's lu or vlce-versa).

llnally Lhe aggregaLlon/bus layer needs Lo perform Lwo key securlLy roles. lL musL be able Lo acL
as an CAuLh2 8esource Server (valldaLlng 8earer 1okens and assoclaLed resource access
scopes). lL musL also be able Lo acL as a ollcy LnforcemenL olnL (L) for pollcy-based access.
ln Lhls model, Lhe bus makes requesLs Lo Lhe ldenLlLy and Access ManagemenL Layer Lo valldaLe
access requesLs. 1he ldenLlLy and Access ManagemenL Layer acLs as a ollcy ueclslon olnL
(u) ln Lhls process. 1he bus layer Lhen lmplemenLs Lhe resulLs of Lhese calls Lo Lhe u Lo
elLher allow or dlsallow resource access.

=)" A2"%+ B$.&"66*%- 4%/ (%493+*&6 >43"$

9
hLLp://Lools.leLf.org/hLml/rfc6433



13
1hls layer Lakes Lhe evenLs from Lhe bus and provldes Lhe ablllLy Lo process and acL upon Lhese
evenLs. A core capablllLy here ls Lhe requlremenL Lo sLore Lhe daLa lnLo a daLabase. 1hls may
happen ln Lhree forms. 1he LradlLlonal model here would be Lo wrlLe a server-slde appllcaLlon.
lor example Lhls could be a !Ax-8S appllcaLlon backed by a daLabase. Powever, Lhere are many
approaches where we can supporL more aglle approaches. 1he flrsL of Lhese ls Lo use a blg-daLa
analyLlcs plaLform. 1hls ls a cloud-scalable plaLform LhaL supporLs Lechnologles such as Apache
Padoop Lo provlde hlghly scalable map-reduce analyLlcs on Lhe daLa comlng from Lhe devlces.
1he second approach ls Lo supporL Complex LvenL rocesslng Lo lnlLlaLe near real-Llme acLlvlLles
and acLlons based on daLa from Lhe devlces and from Lhe resL of Lhe sysLem.

Cur recommended approach ln Lhls space ls Lo use Lhe followlng approaches:
Plghly scalable Column based daLa sLorage for sLorlng evenLs
Map-reduce for long-runnlng baLch orlenLed processlng of daLa
Complex LvenL rocesslng for fasL ln-memory processlng and near-real Llme reacLlon
and auLonomlc acLlons based on Lhe daLa and acLlvlLy of devlces and oLher sysLems.
ln addlLlon Lhls layer may supporL LradlLlonal appllcaLlon processlng plaLforms such as
!ava 8eans, !Ax-8S loglc, message-drlven beans, or alLernaLlves such as node.[s, P,
8uby or yLhon.

AC+"$%49 1.55,%*&4+*.%6 >43"$
1he 8eference ArchlLecLure needs Lo provlde a way for Lhese devlces Lo communlcaLe ouLslde
of Lhe devlce-orlenLed sysLem. 1hls lncludes Lhree maln approaches. llrsLly, we need Lhe ablllLy
Lo creaLe web-based fronL-ends and porLals LhaL lnLeracL wlLh devlces and wlLh Lhe evenL-
processlng layer. Secondly, we need Lhe ablllLy Lo creaLe dashboards LhaL offer vlews lnLo Lhe
analyLlcs and evenL processlng. llnally, we need Lo be able Lo lnLeracL wlLh sysLems ouLslde Lhls
neLwork uslng machlne-Lo-machlne communlcaLlons (Als). 1hese Als need Lo be managed
and conLrolled and Lhls happens ln an Al ManagemenL sysLem.

1he recommended approach Lo bulldlng Lhe web fronL end ls Lo uLlllze a modular fronL-end
archlLecLure such as a porLal, whlch allows slmple fasL composlLlon of useful uls. Cf course Lhe
archlLecLure also supporLs exlsLlng Web server-slde Lechnology such as !ava ServleLs/!S, P,
yLhon, 8uby, eLc. Cur recommended approach ls based on Lhe !ava framework and Lhe mosL
popular !ava-based web server: Apache 1omcaL.

1he dashboard ls a re-usable sysLem focused on creaLlng graphs and oLher vlsuallzaLlons of daLa
comlng from Lhe devlces and Lhe evenL processlng layer.

1he Al ManagemenL layer provldes Lhree maln funcLlons:
1he flrsL ls LhaL lL provldes a developer-focused porLal (as opposed Lo Lhe user-focused
porLal prevlously menLloned), where developers can flnd, explore and subscrlbe Lo Als
from Lhe sysLem, 1here ls also supporL for publlshers Lo creaLe, verslon and manage Lhe
avallable and publlshed Als,



14
1he second ls a gaLeway LhaL manages access Lo Lhe Als, performlng access conLrol
checks (for exLernal requesLs) as well as LhroLLllng usage based on pollcles. lL also
performs rouLlng and load-balanclng,
1he flnal aspecL ls LhaL Lhe gaLeway publlshes daLa lnLo Lhe analyLlcs layer where lL ls
sLored as well as processed Lo provlde lnslghL lnLo how Lhe Als are used.

7"2*&" 84%4-"5"%+
1he uevlce ManagemenL ls handled by Lwo componenLs. A server slde sysLem (Lhe uevlce
Manager - uM) communlcaLes wlLh Lhe devlces vla varlous proLocols and provldes boLh
lndlvldual and bulk conLrol of devlces. lL also remoLely manages Lhe sofLware and appllcaLlons
deployed on Lhe devlce. lL can lock and/or wlpe Lhe devlce lf necessary. 1he uevlce Manager
works ln con[uncLlon wlLh Lhe devlce managemenL agenL. 1here are mulLlple dlfferenL agenLs
for dlfferenL plaLforms and devlce Lypes.

1he uevlce Manager also needs Lo malnLaln Lhe llsL of devlce ldenLlLles and map Lhese lnLo
owners. lL musL also work wlLh Lhe ldenLlLy and Access ManagemenL layer Lo manage access
conLrols over devlces (e.g. who else can manage Lhe devlce aparL from Lhe owner, how much
conLrol does Lhe owner have vs. Lhe admlnlsLraLor, eLc.)

1here are Lhree levels of devlce: non-managed, seml-managed and fully managed (nM, SM,
lM).

lully Managed devlces are devlces runnlng Lhe full uevlce ManagemenL (uM) agenL. 1he uM
agenL supporLs:
Managlng Lhe lnsLalled sofLware
Lnabllng / ulsabllng feaLures of Lhe devlce (e.g. camera, hardware, eLc.)
ManagemenL of securlLy conLrols and ldenLlflers
MonlLorlng Lhe avallablllLy of Lhe devlce
MalnLalnlng a record of Lhe devlce's locaLlon lf avallable
Locklng or wlplng Lhe devlce remoLely lf Lhe devlce ls compromlsed
eLc.

non-managed devlces can communlcaLe wlLh Lhe resL of Lhe neLwork, buL have no agenL
lnvolved. 1hese may lnclude 8-blL devlces where Lhe consLralnLs are Loo small Lo supporL Lhe
agenL. 1he uevlce Manager may sLlll malnLaln lnformaLlon on Lhe avallablllLy and locaLlon of Lhe
devlce lf Lhls ls avallable.

Seml-managed devlces are devlces LhaL lmplemenL some parLs of Lhe devlce managemenL (e.g.
feaLure conLrol buL noL sofLware managemenL).




13
D/"%+*+3 4%/ (&&"66 84%4-"5"%+
1he flnal layer ls Lhe ldenLlLy and access managemenL layer. 1hls layer needs Lo provlde Lhe
followlng servlces:
CAuLh2 Loken lssulng and valldaLlon
CLher ldenLlLy servlces lncludlng SAML2 SSC and Cpenlu ConnecL supporL for ldenLlfylng
lnbound requesLs from Lhe Web layer
xACML u
ulrecLory of users (e.g. LuA)
ollcy managemenL for access conLrol (ollcy ConLrol olnL)

1he ldenLlLy layer may of course have oLher requlremenLs speclflc Lo Lhe oLher ldenLlLy and
access managemenL for a glven lnsLanLlaLlon of Lhe 8A.

ln Lhls secLlon we have ouLllned Lhe ma[or areas of Lhe 8A as well as speclflc declslons we have
Laken around Lechnologles. 1hese declslons are moLlvaLed by Lhe speclflc requlremenLs of lo1
archlLecLures as well as besL pracLlces for bulldlng aglle, evolvable, scalable lnLerneL
archlLecLures. Cf course Lhere are oLher opLlons, buL Lhls 8A uLlllzes proven approaches LhaL are
known Lo be successful ln real-llfe lo1 pro[ecLs we have worked on.

Mapp|ng to the WSC2 |atform
A 8eference ArchlLecLure ls useful as-ls. Powever, lL ls even more useful lf Lhere ls a real
lnsLanLlaLlon. ln Lhls secLlon we provlde a mapplng lnLo producLs and capablllLles of Lhe WSC2
plaLform Lo show how Lhls can be lmplemenLed.

1he WSC2 plaLform ls a compleLely modular, open-source enLerprlse plaLform LhaL provldes all
Lhe capablllLles needed for Lhe server-slde of Lhls archlLecLure. ln addlLlon we also provlde
some reference componenLs for Lhe devlce layer - lL ls an lnLracLable problem Lo provlde
componenLs for all posslble devlces, buL we do provlde elLher sample code and/or supporLed
code for cerLaln popular devlce Lypes.

An lmporLanL aspecL of Lhe WSC2 plaLform ls LhaL lL ls lnherenLly mulLl-LenanL. 1hls means LhaL
lL can supporL mulLlple organlzaLlons on a slngle deploymenL wlLh lsolaLlon beLween
organlzaLlons (LenanLs). 1hls ls a key capablllLy for deploylng Lhls 8A as a SofLware-as-a-Servlce
(SaaS) offerlng. lL ls also used by some organlzaLlons on-premlse Lo supporL dlfferenL dlvlslons
or deparLmenLs wlLhln a group.

1he WSC2 plaLform supporLs deploymenL on Lhree dlfferenL LargeLs:
1. 1radlLlonal on-premlse servers lncludlng Llnux, Wlndows, Solarls and Alx
2. ubllc cloud deploymenL lncludlng Amazon LC2, MlcrosofL Azure and Coogle CompuLe
Lnglne
3. Pybrld or prlvaLe cloud deploymenL on plaLforms lncludlng CpenSLack, Suse Cloud,
LucalypLus, Amazon vlrLual rlvaLe Cloud and Apache SLraLos.




16
1he WSC2 laLform ls based on a Lechnology called WSC2 Carbon, whlch ls ln Lurn based on
CSCl. Lach producL ln Lhe plaLform shares Lhe same kernel based on Carbon. ln addlLlon, each
producL ls made from #"4+,$"6 LhaL are composed Lo provlde Lhe requlred funcLlonallLy.
leaLures can be added and subLracLed as needed. All Lhe producLs work LogeLher uslng
sLandard lnLeroperable proLocols such as P11, MC11 and AMC
10
. All Lhe WSC2 producLs are
avallable under Lhe Apache SofLware Llcense v2.0 whlch ls a buslness-frlendly, non-vlral Cpen
Source Llcense
11


1he followlng dlagram shows Lhe lo1 reference ArchlLecLure layered wlLh Lhe correspondlng
WSC2 producL capablllLles.

I|gure 3 - Io1 kA mapped to WSC2 p|atform components
=)" 7"2*&" >43"$
We supporL any devlce. We have a reference devlce managemenL capablllLy on any Llnux-based
or Androld-based devlce, whlch can be porLed Lo oLher 32-blL plaLforms.

WSC2 also can help wlLh MC11 cllenL code for many devlce plaLforms ranglng from Ardulno Lo
Androld.

10
AMC ls an enLerprlse messaglng proLocol LhaL supporLs pub/sub as well as queulng. lL
provldes conslderably hlgher quallLles of servlce Lhan MC11 lncludlng LransacLlons. See
hLLp://amqp.org
11
hLLp://www.apache.org/llcenses/LlCLnSL-2.0.hLml



17

=)" (--$"-4+*.%?@,6 >43"$
We provlde Lwo core producLs whlch lmplemenL Lhls layer:
1he WSC2 LnLerprlse Servlce 8us (LS8), whlch provldes P11, MC11, AMC and oLher
proLocol supporL, proLocol medlaLlon and brldglng, daLa LransformaLlon, CAuLh2
8esource Server supporL, xACML ollcy LnforcemenL olnL (L) supporL and many
oLher capablllLles. 1he WSC2 LS8 ls hlghly scalable provldlng llnear scalablllLy and elasLlc
scale. ln one deploymenL lL handles more Lhan 2bn requesLs/day. lease noLe LhaL Lhe
WSC2 LS8 does noL currenLly supporL WebSockeLs buL Lhls ls ln Lhe roadmap.
1he WSC2 Message 8roker (M8), whlch provldes Lhe ablllLy Lo acL as an MC11 broker.
1he WSC2 Message 8roker also provldes AMC capablllLles and can provlde boLh
perslsLenL and non-perslsLenL messaglng. 1he WSC2 M8 ls hlghly scalable and supporLs
elasLlc scalablllLy. lease noLe LhaL Lhe WSC2 M8 MC11 supporL ls currenLly ln beLa and
wlll be a fully supporLed funcLlon durlng C3 2014.

=)" (%493+*&6 4%/ A2"%+ B$.&"66*%- >43"$
1hls ls supporLed by Lwo core producLs:
1he WSC2 8uslness AcLlvlLy MonlLor (8AM) provldes Lhe followlng capablllLles:
o A daLa collecLlon model whlch supporLs dlrecL collecLlon of daLa from Lhe
bus/aggregaLlon layer,
o LlasLlcally scalable sLorage based on Apache Cassandra, a columnar noSCL
daLabase,
o A map-reduce plaLform based on Apache Padoop,
o A baLch analyLlcs capablllLy provlded by Apache Plve LhaL allows analyLlcs Lo be
wrlLLen ln an SCL-llke language,
o A full modular dashboard for creaLlng and dlsplaylng vlsuallzaLlons of Lhe daLa,
and
o Scales from a small deploymenL Lo a sysLem LhaL can handle bllllons of evenLs
per day.
1he WSC2 Complex LvenL rocessor (CL) - a hlgh performance real-Llme analyLlcs
englne whlch:
o Shares Lhe same daLa collecLlon and evenL model as Lhe 8AM
o Allows Llme-based and paLLern-maLchlng querles Lo be wrlLLen ln a slmple SCL-
llke language
o Pandles 400k+ evenLs per second on a slngle node
o Scales ouL and provldes hlgh-avallablllLy

ln addlLlon Lhls layer may opLlonally conLaln Lhe WSC2 AppllcaLlon Server hosLlng LradlLlonal
appllcaLlon loglc wrlLLen ln !ava, !Ss and !avaScrlpL (uslng Lhe !aggery.[s framework
12
).

=)" AC+"$%49 1.55,%*&4+*.%6 >43"$
Cur mapplng provldes Lhe capablllLles of Lhls layer wlLh Lhe followlng producLs:

12
hLLp://[aggery.[s



18
WSC2 user LngagemenL Server (uLS)
o 1hls producL supporLs creaLlng and managlng porLal-based and LradlLlonal Web
uls lncludlng supporLlng full personallzaLlon.
o lL ls also used by Lhe 8AM componenL Lo manage and hosL Lhe 8AM dashboards.
WSC2 Al Manager (AlM) whlch:
o Manages Lhe llfecycle of Lhe Als and supporLs Al publlshers,
o Cffers a developer-focused porLal for developers Lo flnd, explore and subscrlbe
Lo Als,
o lssues and manages CAuLh2 Lokens Lo exLernal developers (noLe LhaL when Lhe
WSC2 ldenLlLy Server ls also avallable - see below - Lhen Lhls funcLlon ls
delegaLed Lo LhaL sysLem),
o CaLeways exLernal requesLs and provldes LhroLLllng and L capablllLles,
o ubllshes usage, verslon and oLher daLa lnLo Lhe 8AM server, and
o lnLegraLes wlLh Lhe WSC2 LS8

=)" 7"2*&" 84%4-"5"%+ >43"$
1he WSC2 LnLerprlse MoblllLy ManagemenL (LMM) producL provldes:
Moblle uevlce ManagemenL for lCS, Androld and lo1 devlces
A full App SLore for managlng appllcaLlons and provlslonlng appllcaLlons onLo managed
devlces
lnLegraLlon wlLh Lhe ldenLlLy layer as well as Lhe 8AM

lease noLe LhaL Lhe WSC2 LMM supporL for lo1 devlces ls ln beLa and wlll be a supporLed
capablllLy durlng 2014.

=)" D/"%+*+3 4%/ (&&"66 84%4-"5"%+ >43"$
1he WSC2 ldenLlLy Server supporLs Lhls aspecL, and provldes Lhe followlng capablllLles:
CAuLh2 ldenLlLy rovlder, lssulng, revoklng and managlng Lokens,
Slngle Slgn-Cn supporL lncludlng SAML2 SSC and Cpenlu ConnecL supporL,
SupporL for oLher ldenLlLy proLocols lncludlng WS-lederaLlon (asslve), Cpenlu 2.0,
kerberos, lnLegraLed Wlndows AuLhenLlcaLlon (lWA) and oLhers
lull supporL for xACML (lncludlng verslons 2.0 and 3.0), acLlng as a u, l, and A,
1he ablllLy Lo lnLegraLe beLween dlfferenL ldenLlLy rovldes and Servlce rovlders
lncludlng ldenLlLy brokerlng
SupporL for ldenLlLy provlslonlng lncludlng SML and SClM supporL.

1he WSC2 plaLform ls Lhe only modular, open source plaLform Lo provlde all Lhese capablllLles
(and more). As such lL ls Lhe ldeal basls for creaLlng and deploylng Lhls lo1 reference
archlLecLure.

Cne furLher aspecL LhaL ls hlghly worLh conslderlng ls Lhe use of a laLform-as-a-Servlce (aaS).
WSC2 provldes a Lhe WSC2 rlvaLe aaS producL whlch ls based on Lhe Apache SLraLos pro[ecL.
1hls provldes a managed, elasLlcally scalable, PA deploymenL of Lhe producLs menLloned above



19
and also manages Lenancy, self-servlce subscrlpLlon, and many oLher aspecLs. lL also supporLs
managlng many oLher useful server-slde capablllLles lncludlng P, MySCL, Mongou8 and
oLhers. We have noL shown Lhe aaS layer on Lhe lo1 8A as some deploymenLs may noL need
Lhls capablllLy.

Conc|us|ons
ln Lhls paper we have ouLllned Lhe followlng:
WhaL our deflnlLlon of Lhe lnLerneL of 1hlngs ls,
Why a reference archlLecLure ls valuable
1he requlremenLs on Lhe 8A
1he lnsLanLlaLlon of Lhe 8A and how lL meeLs Lhose requlremenLs
A mapplng of LhaL 8A lnLo Lhe WSC2 plaLform

1hls ls our flrsL verslon of Lhls paper, and of course we expecL Lhls Lo evolve. 1he lo1 space ls
evolvlng rapldly and we expecL Lhls paper - and Lhe assoclaLed Lechnologles - Lo evolve ln sync.
Powever, desplLe Lhe emerglng naLure of Lhls space, Lhls paper and Lhe 8A are based on real-
world pro[ecLs LhaL we have deployed wlLh cusLomers Lo supporL lo1 capablllLles. As such, we
have greaL confldence Lhls ls a useful, deployable and effecLlve reference archlLecLure.