vicinity d1 6 architectural design 1.0

VICINITYArchitecturalDesign 1

Public

ProjectAcronym: VICINITY

ProjectFullTitle: Open virtual neighbourhood network to connect intelligentbuildingsandsmartobjects

GrantAgreement: 688467

ProjectDuration: 48months(01/01/2016-31/12/2019)

DeliverableD1.6

VICINITYArchitecturalDesign

WorkPackage: WP1 – VICINITY concept Requirements, Barriers, Specification andArchitecture

Task(s): T1.4–Functional&TechnicalSpecification,Architecturaldesign

LeadBeneficiary: BVR

DueDate: 31March2017

SubmissionDate: 31March2017

DeliverableStatus: Final

DeliverableType: R

DisseminationLevel: PU

FileName: VICINITY_D1_6_Architectural_Design_1.0.pdf


Public

VICINITYConsortium

No Beneficiary Country

1. TUKaiserslautern(Coordinator) UNIKL Germany

2. ATOSSPAINSA ATOS Spain

3. CentreforResearchandTechnologyHellas CERTH Greece

4. AalborgUniversity AAU Denmark

5. GORENJEGOSPODINJSKIAPARATID.D. GRN Slovenia

6. HellenicTelecommunicationsOrganizationS.A. OTE Greece

7. bAvenirs.r.o. BVR Slovakia

8. ClimateAssociatesLtd CAL UnitedKingdom

9. InterSoftA.S. IS Slovakia

10. UniversidadPolitécnicadeMadrid UPM Spain

11. GnomonInformaticsS.A. GNOMON Greece

12. TinyMeshAS TINYM Norway

13. HAFENSTROMAS HITS Norway

14. Enercoutim–AssociaçãoEmpresarialdeEnergiaSolardeAlcoutim

ENERC Portugal

15. MunicipalityofPylaia-Hortiatis MPH Greece

AuthorsList

LeadingAuthor(Editor)

Surname FirstName Beneficiary Contactemail

Oravec Viktor BVR [email protected]

Co-authors(inalphabeticorder)

No Surname FirstName Beneficiary Contactemail

1. Heinz Christopher UNIKL [email protected]

2. Hovstø Asbjørn HITS [email protected]

3. Kaggelides Kostis GNOMON [email protected]

4. Karkaletsis Kostas GNOMON [email protected]


Public

5. Karageorgopoulou Anastasia CERTH [email protected]

6. Kostelnik Peter IS [email protected]

7. Margariti Katerina CERTH [email protected]

8. MollNilsen Rolv TINYM [email protected]

9. Mynzhasova Aida UNIKL [email protected]

10. Poveda Maria UPM [email protected]

11. Serena Fernando UPM [email protected]

12. Sveen Flemming HITS [email protected]

13. Tryferidis Athanasios CERTH [email protected]

14. Zandes Dimitrios GNOMON [email protected]

ReviewersList

ListofReviewers(inalphabeticorder)

No Surname FirstName Beneficiary Contactemail

1. Dickerson Keith CAL [email protected]

2. Koelsch Johannes UNIKL [email protected]

3. Raúl García-Castro UPM [email protected]

4. Tryferidis Athanasios CERTH [email protected]

5. Vinkovic Saso GRN [email protected]


Public

RevisionControl

Version Date Status Modificationsmadeby

0.1 17.June2016 InitialDraft Oravec(BVR)

0.1.1 1.July2016 UpdatebasedonGA01 Oravec(BVR)

0.1.2 12.October2016 UpdatebasedonPilotsitevisits Oravec(BVR)

0.1.3 11. November2016

Update based on preliminaryVICINITYReview

Oravec(BVR)

0.1.4 22.December UpdatebasedonD1.5QaRreview Oravec(BVR)

0.1.5 17.February2017 ContributionsfromIS Kostelnik(BVR)

0.1.6 23.February2017 ContributionsfromUPM Serena(BVR)

0.1.7 24.February2017 ContributionsfromHITS Hovstø(BVR)

0.2 5.March2017 Deliverable version uploaded forQualityCheck

Oravec(BVR)

0.3 30.March2017 Qualitycheckedfinalversion Oravec(BVR)

0.4 31.March2017 FinalDraftreviewed Oravec(BVR)

1.0 31.March2017 SubmissiontotheEC Oravec(BVR)


Public

TableofContentsExecutive Summary ........................................................................................................................... 11

Introduction ................................................................................................................................. 14 Deliverable objectives .................................................................................................. 14 Deliverable structure .................................................................................................... 14 Relation to other Tasks and Deliverables .................................................................. 15

Overall architecture design of VICINITY ................................................................................... 16 VICINITY architecture concept .................................................................................... 16 VICINITY Architecture use case scenarios ................................................................ 18

Logical VICINITY architecture ................................................................................................... 22 VICINITY Cloud ............................................................................................................. 22 VICINITY Node .............................................................................................................. 23 How interoperability works in VICINITY ..................................................................... 23

Information view ......................................................................................................................... 29 VICINITY Cloud ............................................................................................................. 30 VICINITY Node .............................................................................................................. 31 Data storages ................................................................................................................ 33

Process view ............................................................................................................................... 39 Interfaces View ........................................................................................................................... 55

VICINITY Cloud ............................................................................................................. 55 Deployment view ........................................................................................................................ 59

VICINITY deployment of VICINITY Cloud ................................................................... 59 VICINITY deployment of VICINITY Node .................................................................... 60 Components monitoring .............................................................................................. 61

Detail architecture design of VICINITY components ............................................................... 62 VICINITY Neighbourhood Manager ............................................................................. 62 VICINITY Communication Server and Node .............................................................. 64 Semantic discovery & dynamic configuration agent platform (IS) .......................... 68 VICINITY Gateway API ................................................................................................. 70 VICINITY Agent / Adapter ............................................................................................ 75 VICINITY Gateway API Services .................................................................................. 77

Quality considerations ............................................................................................................... 80 Usability ........................................................................................................................ 80 Reliability ...................................................................................................................... 80 Scalability & Performance ........................................................................................... 82


Public

Maintenance .................................................................................................................. 82 Security & Privacy ........................................................................................................ 83

Conclusions ................................................................................................................................ 92 Appendix A. Deployment of VICINITY Node on VICINITY Gateway ............................................. 94 Appendix B. Reference architecture ............................................................................................... 95 Appendix C. Register ................................................................................................................. 112


Public

ListofTablesTable1InformationflowfromVICINITYNeighbourhoodmanager......................................................................30 Table2InformationflowfromSemanticdiscoveryandagentconfiguration.......................................................30 Table3InformationflowfromVICINITYGatewayAPIServices............................................................................31 Table4InformationflowfromVICINITYCommunicationServer..........................................................................31 Table5InformationflowfromVICINITYCommunicationNode...........................................................................31 Table6InformationflowfromVICINITYGatewayAPI..........................................................................................32 Table7InformationflowfromVICINITYAgent/Adapter.....................................................................................32 Table8MappingofVICINITYFunctionalitiestoVICINITYArchitectureprocesses................................................53 Table9InterfacesprovidedbyVICINITYNeighbourhoodmanager......................................................................55 Table10InterfacesprovidedbySemanticdiscoveryanddynamicconfigurationagentplatform.......................56 Table11InterfacesprovidedbyVICINITYGatewayAPIServices..........................................................................56 Table12InterfaceprovidedbyVICINITYCommunicationServer.........................................................................56 Table13InterfaceprovidedbyVICINITYCommunicationNode...........................................................................57 Table14InterfaceprovidedbyVICINITYGatewayAPI.........................................................................................57 Table15InterfaceprovidedbyVICINITYAgent/Adapter.....................................................................................58 Table16VICINITYSecurityfeaturesmappedtoAIOTIrecommendations...........................................................84 Table17VICINITYPrivacyfeaturesmappedtoAIOTIrecommendations............................................................86

ListofFiguresFigure1High-levellogicalVICINITYarchitecture..................................................................................................11 Figure2VICINITYConcept.....................................................................................................................................16 Figure3High-levellogicalVICINITYarchitecture..................................................................................................17 Figure4LocalapplicationaccessingIoTobjectsconnectedtosmarthubofdifferentVendor............................19 Figure 5 Local application accessing IoT objects connected to smart hub of different Vendor through Cloudservices..................................................................................................................................................................20 Figure6Remoteapplicationprovidedby value-added service accessing IoTobjects connected to smartHUBand/orcloudservice..............................................................................................................................................21 Figure7SemanticinteroperabilityapproachforDiscovery..................................................................................25 Figure8SemanticinteroperabilityapproachforAccessing..................................................................................27 Figure9VICINITYArchitectureinformationflow..................................................................................................29 Figure10VICINITYDatastorages..........................................................................................................................33 Figure11VICINITYontologynetworkdesign........................................................................................................38 Figure12ManualVICINITYNoderegistrationprocess.........................................................................................41 Figure13ManualVICINITYNoderemoval............................................................................................................41 Figure14Auto-configurationofVICINITYNode....................................................................................................42 Figure15VICINITYNodeconfigurationdistributionprocess................................................................................43


Public

Figure16SemanticsearchofIoTobjectsfromVICINITYNeighbourhoodManager.............................................45 Figure17SemanticsearchofIoTobjectsfromVICINITYGatewayAPI.................................................................45 Figure18ManualchangeofIoTobject.................................................................................................................46 Figure19AutomaticregistrationofIoTobjectinVICINITY...................................................................................46 Figure20Crawlingexternalrepositoriesprocess.................................................................................................47 Figure21“Getting”propertyofconsumedIoTobject..........................................................................................48 Figure22“Setting”propertyofconsumedIoTobject..........................................................................................49 Figure23CallingactionofconsumedIoTobject..................................................................................................49 Figure24ReceivingeventfromconsumedIoTobject..........................................................................................50 Figure25“Getting”propertyofexposedIoTobject.............................................................................................51 Figure26"Setting"propertyofexposedIoTobject..............................................................................................52 Figure27ReceivingactionofexposedIoTobject.................................................................................................52 Figure28EmittingeventofexposedIoTobject....................................................................................................53 Figure29VICINITYInterfaceview.........................................................................................................................55 Figure30VICINITYClouddeploymentstrategy....................................................................................................59 Figure31VICINITYNodedeploymentstrategy.....................................................................................................60 Figure32ComponentdiagramofVICINITYNeighbourhoodManager.................................................................62 Figure33FunctionalblocksofVICINITYCommunicationServerandNode..........................................................65 Figure34SecuritycontextofVICINITY..................................................................................................................83 Figure35Securityarchitecture.............................................................................................................................84 Figure36Deployment-ScenarioofaVICINITYNodeonVICINITYGateway..........................................................94 Figure37IoTReferencearchitectureinrelationtoVICINITYArchitecture...........................................................95 Figure38ContextofIoTarchitectures..................................................................................................................96 Figure39ConceptualmodelofIoTreferencearchitecture..................................................................................96 Figure40Relationbetweenoverallmodelandarchitectureconcepts................................................................96 Figure41IoTarchitecturereferencemodelofArchitectureviews......................................................................97


Public

ListofDefinitions&Abbreviations

Abbreviation Definition

5Vs Volume,Velocity,Veracity,Variability,andVariety

6LoWPAN IPv6overLowPowerWirelessPersonalAreaNetwork

API ApplicationProgrammingInterface

CM ConceptualModel

CoAP ConstrainedApplicationProtocol

CPU Centralprocessingunit

DEVOPS softwareDEVelopmentandinformationtechnologyOPerationS

EC EuropeanCommission

EU EuropeanUnion

GDPR GeneralDataProtectionRegulation

HDD Harddiskdrive

ICU InternationalComponentsforUnicode

IG InterestGroup

IoT InternetofThings

IoTRA InternetofThingsReferenceArchitecture

JMX JavaManagementExtensions

MQTT MessageQueueTelemetryTransport

OWL W3CWebOntologyLanguage

PII PersonallyIdentifiableInformation

P2P PeertoPeer

RA ReferenceArchitecture

RAID RedundantArrayofIndependentDisks

RAM RandomAccessMemory

RDF ResourceDescriptionFramework

REST Representationalstatetransfer

RM ReferenceModel

SNMP SimpleNetworkManagementProtocol

SPARQL SPARQLProtocolandRDFQueryLanguage

TD ThingDescription

TED ThingEcosystemDescription

UML UniversalModellingLanguage


Public

Abbreviation Definition

VTED VirtualTED

XMPP ExtensibleMessagingandPresenceProtocol

WoT WebofThings


Public

ExecutiveSummary

This document, referred as “D1.6 VICINITY Architectural design”, is a deliverable of the VICINITYproject, fundedbytheEuropeanCommission(EC)Directorate-General forResearchandInnovation(DGRTD),underitsHorizon2020ResearchandInnovationProgramme(H2020).VICINITYisbuildingadeviceandstandardindependentplatformforIoTinfrastructuresthatoffers„InteroperabilityasaService“. They aim of the VICINITY is to solve the interoperability problem with a virtualneighbourhoodconceptwhichisadecentralized,user-centricapproachthatallows transparencyandfullcontroloverexchangeddata. ThisdeliverabledirectlyaddressestheObjective2.4“VICINITYTechnical requirementsandsolutionarchitecture specified“, in terms of describing architectural decisions which shape the VICINITYinteroperability platform. The selected architectural options anddecisions arebasedon functionaland quality requirements extracted from D1.5 VICINITY Technical requirement specificationdocumentandcanbesummarizedinthefollowingFigure1.

Figure 1 High-level logical VICINITY architecture TheVICINITYarchitectureisdividedintothefollowingprincipalcomponents:

• VICINITYCloudprovidingsetofservicestosetuppeer-to-peer interoperabilitybetween IoTenvironments(furtherreferredasvirtualneighbourhoods),thatareincluding:

o accesscontroltotheVICINITY-connectedIoTobjects,o servicesfordevicediscoveryandregistration,o deployment of value added services over VICINITY-connected IoT objects and

environments,o andsettingupconnectiontoVICINITY(e.g.gettingintegratedtoVICINITY);

• VICINITY Node, integrating IoT infrastructures and value-added services to the VICINITYinteroperabilitynetwork.TheVICINITYNodeincludes:


Public

o VICINITYCommunicationNodewhichhandlesthesecureandpeer-to-peerexchangeofIoTdata(IoTevents,actionsaswellasIoTproperties)andconfigurationdatawithotherintegratedinfrastructures,valueaddedservicesandtheVICINITYCloud;

o VICINITY Gateway API providing semantic interoperability interface for VICINITYAdapters/AgentstoregisterIoTobjects,toaccesssharedIoTobjectsortodiscoverandqueryIoTobjects;

o VICINITYAdaptersandAgentsadaptingVICINITYintolocalinfrastructures.

The VICINITY Cloud and set of VICINITY Nodes are creating secure peer-to-peer communicationnetwork. This network of loosely coupled peers copying geographically distribution of integratedinfrastructures and value-added service thus user data exchange load is distributed accordingly.Moreover, any performance, availability and system failure issues originated in integratedinfrastructuresandvalue-addedservicesoreveninVICINITYCloudcanbelocalisedinthepeer(i.e.spreadofissuescanbekeptundercontrolinthecertainpartofthepeer-to-peernetwork).

TheVICINITYCloudcomponentssuchasVICINITYNeighbourhoodmanager(providinguserinterfaceto VICINITY Users), Semantic discovery and dynamic configuration agent platform (providingsemantic platform) and VICINITY Communication Server (providing control of communicationbetweenintegratedinfrastructures)shallbedeployedashighavailablesoftwarecomponentsbeingto scale in/out VICINITY cloud to current needs to the integrated infrastructures and value addedservices.

The distributed infrastructure of VICINITY is enhanced by interoperability approach to provide astandardwaytobothDiscoverandAccessheterogeneous IoTobjectsdistributedamongsparse IoTinfrastructures based on thework being done by theW3CWeb of Things (WoT)WG1. Therefore,VICINITYshallrelyonThingdescription(TD)introducedbyWoTtodescribeeveryIoTobject(whichcan represent either physical or abstract Things) that belong to any integrated IoT infrastructure,which in turn shall be described as an ecosystem of IoT objects (Things ecosystem descriptions –TEDs).Accordingly,eachinterestedpartintakingadvantageofthesemanticinteroperabilitysolutionprovidedbyVICINITYmustonlybeabletounderstandsuchdescriptionframesaswellastheWebofThingsontologythroughtheVICINITYGatewayAPIinterface.

TheVICINITYtrust,privacyandsecurityfeaturesaremainlycovered:

• VerificationofVICINITYusersthroughVICINITYNeighbourhoodManagerandverificationandvalidation of IoT objects (value-added services and devices) through the VICINITYcommunicationserversecurityservices;

• End-to-endsecurityandauthenticityofexchangeddatathroughpeer-to-peernetworkusingencryption and data integrity services of VICINITY communication Server and Nodecomponents;

• Controlledregistrationandaccesstovalue-addedservicesandIoTobjectsproperties,actionand events based on sharing access rules with private data processing consents2throughVICINITYNeighbourhoodmanagersetbydeviceownerorserviceprovided;

1https://www.w3.org/WoT/IG/2Regulation(EU)2016/679oftheEuropeanParliamentandoftheCouncilof27April2016ontheprotectionofnaturalpersonswithregardtotheprocessingofpersonaldataandonthefreemovementofsuchdata,andrepealingDirective95/46/EC(GeneralDataProtectionRegulation)


Public

• Exchanging of private user data only through VICINITY Nodes and Peer-to-peer networkwithoutstoringdatainVICINITYCloud3;

The VICINITY Architectural design together with VICINITY Technical requirements specificationdefines the base line for the following implementation of VICINITY core components, SemanticDiscoveryandDynamicConfigurationservicesinWP3andVICINITYGatewayAdaptersandVICINITYAgentandAuto-DiscoveryplatforminWP4.

3VICINITY Cloud stores only meta-data necessary to manage access to devices, value-added services andfacilitate exchanged information. Meta-data stored in VICINITY Cloud can be accessed by VICINITYNeighborhoodmanageruserinterfacebyappropriateusers.


Public

IntroductionThis document provides the architectural design as developed within “Task 1.4 – Functional &TechnicalSpecification,Architecturaldesign”.

Therelevanttasks(fromwhicharchitecturedesignisderived)areasfollows:

• Task1.1–ElicitationofuserrequirementsandbarriersrelatedtoIoTinteroperability;• Task1.2–PilotSitesSurveysandextractionofUseCaserequirements;• Task1.3–VICINITYPlatformUserandBusinessRequirementDefinition;• Task2.1–Analysisofavailableplatforms,IoTinfrastructures,IoTontologiesandstandards.

Thus, it is suggested that readers should be familiar with and have access to the followingdeliverables:

• D1.1VICINITYrequirementcaptureframework;• D1.2ReportonbusinessdriversandbarriersofIoTinteroperabilityandvalueaddedservices;• D1.3Reportonpilotsitesandoperationalrequirements;• D1.4ReportonVICINITYbusinessrequirements;• D1.6Technicalrequirementsspecification;• D2.1AnalysisofStandardisationContextandRecommendationsforStandardsInvolvement.

This document is prepared as a starting point for technical audience to understand the overallarchitecturedesignanddecisionof theVICINITYsolution.However, thedocumentwillnotprovidecomprehensive and detailed documentation with all the technical information. It should helptechnicalpartnerswithinconsortiumduringthedevelopmentoftheVICINITYsolution.Consequently,themostimportantsourceofinformationwillbetheactualsourcecodeanditsdocumentation(e.g.usermanuals,installationguidesandsourcecodecomments).

Thesystemwillbedevelopedthroughrepeatedcycles(iterative)andinsmallerportionsatatime(incremental),whatmeansthateachiterationwillcontainpartoftheanalysis,implementationandtesting.Thistechnicaldocumentationwillbealsocontinuouslyupdatedthroughouttheproject.

DeliverableobjectivesTheobjectivesofthisdeliverableareasfollows:

• todefineVICINITYarchitecturedesignofcoreVICINITYcomponentsandconcepts;• todefineimplementationofusability,reliability,efficiency,maintenance.

DeliverablestructureThedeliverableisdividedintothefollowingsections:

• Section1includesexecutivesummaryofthisdeliverable;• Section2providestodeliverable(thissection);• Section3coinsanoverallVICINITYArchitectureandprincipaluse-casesofthearchitecture;• Section4presentsalogicalviewoftheVICINITYinteroperabilityplatform;• Section5definestheinformationflowandimportantVICINITYdatastorages;• Section6encompassescrosscomponents’processesinVICINITY;• Section7summarizestheinterfacesbetweenVICINITYcomponents;• Section 8 presents the conceptual deployment scenarios of VICINITY Cloud and VICINITY

Node;


Public

• Section9proposesimportantconceptsofeachVICINITYArchitecturalcomponent;• Section10providesSecurityfeaturesofVICINITY;• Section11:Conclusions;• AppendixA:DeploymentofVICINITYNodeonVICINITYGateway;• AppendixB:InternetofThingsReferenceArchitecture(IoTRA);• AppendixC:Registerofimportantterms.

RelationtootherTasksandDeliverablesThefollowingdocumentshavebeenusedtoderivedetaildesign:

• D1.1VICINITYrequirementcaptureframework–defineshowtherequirementsaremanagedinVICINITYproject;

• D1.2ReportonbusinessdriversandbarriersofIoTinteroperabilityandvalueaddedservices–definesconstraintsforfunctionalspecificationbasedonstakeholders’driversandbarriers;

• D1.3 Report on pilot sites and operational requirements – defines constraints deploymentandenvironmentconstraintsforfunctionalspecification;

• D1.4 Report on VICINITY business requirements – provides inputs on desired VICINITYfunctionality;

• D1.5VICINITY technical requirements specification – provides non-functional requirementstoshapethearchitecturedesign.

Thefollowingtasksutilizethearchitecturedesignreportedinthisdocument:

• Task3.1,Task3.2andTask3.3todetaildesignandimplementofVICINITYcorecomponents,SemanticDiscoveryandDynamicConfigurationservices;

• Task 4.1, Task 4.2 and Task 4.3 to detail design and to implement of VICINITY Clientcomponentsandsecurityservices.


Public

OverallarchitecturedesignofVICINITYTheVICINITY is built around the concept of connecting different IoT ecosystems throughVICINITY(interoperability as a services) which enable to interact with IoT objects from other differentecosystems as if theywere their own. The interoperability services create an environmentwherevalue-added services can be deployed and processes cross-domain exchanged information acrossdifferentdomains(Figure2).

Figure 2 VICINITY Concept In presented figure two separate ecosystems are presented intelligent building and energyecosystem.EachoftheseecosystemsareintegratedtoVICINITYbyitsVICINITYAdapterthroughtheVICINITYgateway.BasedonthesetupofvirtualneighbourhoodinVICINITYNeighbourhoodmanager,VICINITYAdaptersmayaccessremoteIoTobjects,forexampleabatteryinanEnergyecosystem,andsimulateitasapartoftheirecosystem.Moreover,IoTobjectssharedbyVICINITYAdapterwithinavirtual neighbourhoodmay be accessed by value-added services to provide cross-domain servicesusingcommonaVICINITYontology.

VICINITYarchitectureconceptThe objective of VICINITY architecture is to build-up a decentralised interoperability betweenintegrated IoT infrastructures and value-added services (called virtual neighbourhood) through apeer-to-peer (P2P) network of VICINITY Nodes. VICINITY Nodes integrates infrastructures in toVICINITY. The infrastructures’ managers can setup the sharing access of their IoT objects withoutlosingthecontroloverthemusingVICINITYCloud.

TheVICINITYNodescreateaclosedandsecureVICINITYP2PNetworkfortheexchangeofuserdata.TheVICINITYP2PNetwork is configuredvia theVICINITYCloud,basedona virtualneighbourhoodconfigurationdata–sharingaccessrulesofIoTobjectswithintheVICINITYwithsecurityproperties(suchasencryption,dataintegrity,etc.)toensuresecurityandprivacyofexchangedusedata.

The VICINITY Nodes are configured based on a semantic & dynamic configuration data (semanticdescriptions of IoT objects) from the VICINITY Cloud to ensure semantic interoperability betweenintegratedinfrastructuresandvalueaddedservices.


Public

Figure 3 High-level logical VICINITY architecture

On the top of the VICINITY Cloud and VICINITY Nodes the following VICINITY functionality areexecuted(seeD1.5fordetaileddescription):

• Interoperabilitysetup;• Deviceregisteranddiscovery;• Deployvalueaddedservice;• ConnectingVICINITY.

VICINITYCloud

TheVICINITYCloudprovidesthesetofthefollowingservicestosupportVICINITYfunctionality:

• Configure a virtual neighbourhood of integrated infrastructures and value-added servicesincludingthesetupofsharingaccessrulesofany IoTobjectvisible inVICINITYthroughtheuser-friendlyinterface(9.1);

• SemanticsearchofIoTobjectsinVICINITYvirtualneighbourhood;• SemanticmappingandnormalizationofnewIoTobjectstoVICINITYIoTontology;• ConfigurationofVICINITYNodesbasedon:

o IoTobjectdescription(suchasdata-integrationandprivacyservices),o sharingaccessrules(configuringofaccesstoIoTobjectsinP2Pnetwork)ando configuration of the communication with integrated infrastructure or value-added

services(suchasencryptionanddataintegrityfeatures);• Auditingandusernotificationservicesofchangesandeventsinvirtualneighbourhood(such

as new integrated infrastructure request, change of sharing access rules, new device orserviceinvirtualneighbourhoodevents).

VICINITYNode

AVICINITYNode is the setof software componentsproviding the following setof services for theintegrationoftheIoTinfrastructureand/orvalue-addedserviceintoVICINITY:


Public

• Remote IoTobject semanticdiscovery service to look-up for theobjectsprovidedbyotherintegratedinfrastructuresand/orvalue-addedservicesintegratedwithVICINITY;

• UserdataannotationfollowingasemanticformatderivedfromtheVICINITYIoTontology.• UserdataforwardingwithintheP2Pnetworkaccordingtheshareaccessrulesdefinedinthe

VICINITYCloud;• Encryption and data-integration services for forwarded user data to ensure secure

transmissionofthedatawithinVICINITYP2Pnetwork(9.5);• Configurableofauditingandloggingofexchangeduserdata.

VICINITYP2Pnetwork

The VICINITY P2P network represents the distributed application architecture composed of allVICINITYNodesthatareregisteredinVICINITY.Theconnectionsbetweensuchnodesareestablishedon-demand and facilitated by the VICINITY Cloud. That is, whenever a Node requires informationfromtheNetwork,VICINITYCloudinformsaboutthecandidatepeers(Nodes)thatmayberelevantto establish connection with, in the context of specific information requests. The VICINITY P2Pnetwork provides scalable (9.3), closed and secure common communication network for VICINITYNodesandVICINITYCloud(i.e.node-to-nodeandcloud-to-nodecommunication)toexchange:

• UserdatabetweenVICINITYNodesbasedontheshareaccessrulesdefinedinVICINITYCloudservices;

• Control and configuration (such as encryption and privacy features mechanism, controlcommunication channels within P2P network, configure communication between VICINITYNodes and integration infrastructures) messages between VICINITY Nodes and VICINITYCloud.

VICINITYArchitectureusecasescenariosThissectiondescribesthedifferentarchitecturalscenariosonhowVICINITYsupportsinteroperabilitybetweendifferentIoTinfrastructuresandvalue-addedservices.

LocalapplicationaccessingIoTobjectsconnectedtosmarthubofdifferentIoTinfrastructure

This architecture use case scenario interconnects two IoT infrastructures through VICINITY usingVICINITY Nodes. Both infrastructures are integrated to the VICINITY through respective VICINITYNodes. Regardless of the locationof integrated IoT infrastructures (i.e. sameor different building,samecommunicationnetwork),theyarecommunicatingthroughtheVICINITYP2Pnetwork.VICINITYNodecommunicateswithSmart infrastructureswithSmartHUB (suchopen-M2Mplatforms)or IoTdevices(dependingonimplementation).

Goalofusecase:ApplicationrunninginSmartInfrastructureAcanaccessIoTobjectsconnectedtoSmartinfrastructureBaspartofitsowninfrastructure.


Public

Figure 4 Local application accessing IoT objects connected to smart hub of different Vendor

Discovery: Browser application discovers IoT objects connected to Smart Infrastructure A locally.BrowserapplicationdiscoversIoTobjectsconnectedtoSmartInfrastructureBlocally(usingVICINITYdiscoverysemanticservicesprovidedbyVICINITYNode).

Data access: Browser application accesses data streams from IoT objects connected to SmartInfrastructureAlocally(withoutVICINITYNode).BrowserapplicationaccessesdatastreamsfromIoTobjectsconnectedtoSmartInfrastructureBlocally(usingVICINITYNodeandVICINITYP2Pnetwork).

LocalapplicationaccessingIoTobjectsconnectedtosmarthubofdifferentIoTinfrastructurethroughCloudservices

This architecture use case scenario interconnects two IoT infrastructures through VICINITY usingVICINITYNodes.OneoftheinfrastructuresisintegratedonlevelofSmartHUB,otherisintegratedonthe level of cloud services4. Regardless of location of integrated IoT infrastructures (like same ordifferent building, same communication network) they are communicating through VICINITY P2Pnetwork.

Goalofusecase:ApplicationrunninginSmartInfrastructureAcanaccessIoTobjectsconnectedtoSmartInfrastructureBthroughitscloudservicesaspartofitsowninfrastructure.

4Cloudservicescanbedeployedaspublic,privateorhybridcloudservices.


Public

Figure 5 Local application accessing IoT objects connected to smart hub of different Vendor through Cloud services

Discovery: Browser application discovers IoT objects connected to Smart Infrastructure A locally(using infrastructure A discovery services). Browser application discovers IoT objects connected toSmartInfrastructureBlocally(usingVICINITYdiscoverysemanticservicesprovidedbyVICINITYNode,VICINITYNodediscoversIoTobjectsusingcloudservicesonly).

Data access: Browser application accesses data streams from IoT objects connected to SmartInfrastructureAlocally(withoutVICINITYNode),BrowserapplicationaccessesdatastreamsfromIoTobjects connected to Smart Infrastructure B remotely (using VICINITY Node and VICINITY P2Pnetwork,VICINITYNodeofSmartInfrastructureBaccessdatausingcloudservicesonly).

Remote application provided by value-added service accessing IoT objectsconnectedtoSmartHUBand/orcloudservice

This architecture use case scenario interconnects two IoT infrastructures and Value-added servicethroughVICINITYusingVICINITYNodes.IoTinfrastructuresareintegratedonleveloftheSmartHUBandtheCloudservice.

Goal of use case: Browser application runningon value-added serviceneeds access to IoTobjectsconnectedSmartInfrastructureAandSmartInfrastructureB.


Public

Figure 6 Remote application provided by value-added service accessing IoT objects connected to smart HUB and/or cloud service

Discovery: Browser application discovers IoT objects connected to Smart Infrastructure A and Bremotely (using VICINITY Node). Applications running in Smart Infrastructure A or B discover onlytheirIoTobjects.

Data access: Browser application accesses data streams from IoT objects connected to SmartInfrastructureAandBremotely(usingVICINITYNodeandunderlyingVICINITYP2Pnetwork).


Public

LogicalVICINITYarchitectureBased on VICINITY architecture concept and VICINITY Functionality (see Deliverable D1.5) logicalVICINITYarchitectureisdecomposedintofollowingcomponents:

• VICINITYCloud:o VICINITYNeighbourhoodManager;o Semanticdiscoveryandagentconfigurationplatform;o VICINITYCommunicationServer;o VICINITYGatewayAPIServices;

• VICINITYNode:o VICINITYCommunicationNode;o VICINITYGatewayAPI;o VICINITYAgent/Adapter.

VICINITYCloud

VICINITYNeighbourhoodManager

TheVICINITYNeighbourhoodmanagershallprovidefollowingservice:

• VirtualneighbourhoodsearchforIoTobjects,users,organizations;• IoTobjectsmanagement;• Sharingaccessrulesmanagement;• VICINITYNodeconfigurationmanagement;• Consentandtermsofconditionmanagement;• Userandorganizationmanagement;• Userimportantnotificationservices;• Useractivityauditing.

Semanticdiscoveryandagentconfiguration

TheSemanticdiscoveryandagentconfigurationplatformshallprovide:

• Semanticsearchservices;• IoTobjectssemanticnormalizationtoVICINITYIoTontology;• IoTobjectsregistryservices;• ExternalIoTobjecttemplaterepositorycrawlinganddownloading;• SemanticmappingofIoTobjectstemplatestoVICINITYIoTontology;• Semanticdatachangesprovision;• VICINITYAgentconfigurationprovision.

VICINITYGatewayAPIServices

TheVICINITYGatewayAPIServicesshallprovidesupportingservicesforVICINITYGatewayAPI:

• SemanticsearchofIoTobjectsinVICINITYneighbourhoodservices.

VICINITYCommunicationServer

TheVICINITYCommunicationservershallprovidefollowing:

• communicationchannelsetup;


Public

• transactionservicesbetweenVICINITYCloudcomponents;• securityservicesforIoTdeviceauthentication• VICINITYCloudservicesforwardingto/fromVICINITYP2Pnetwork:

o IoTObjectsdescriptions;o VICINITYNode(auto-)configurationmessages.

VICINITYNode

VICINITYCommunicationNode

TheVICINITYCommunicationNodeshallprovidethefollowingfunctionality:

• dataforwardinginVICINITYP2Pnetwork;• dataaccessauthorizationservices;• dataintegrityandencryptionservices;• privacyfilteringservices(see8.2.2);• VICINITYConfigurationservice(forwardedfromVICINITYCloud);• IoTobjectsregistryservice(forwardedfromVICINITYCloud).

VICINITYGatewayAPI

TheVICINITYGatewayAPIshallprovidethefollowingfunctionality:

• Consume Things API service (i.e. to access properties, actions and events of IoT objectsthroughVICINITY);

• ExposeThingsAPIservice(toexposethingsfromintegratedinfrastructureintoVICINITY);• GatewayAPIconfigurationservicetoconfigureconsumeandexposethingsAPIs;• IoTobjectsregistryservice(fromVICINITYAdapter/Agent).

VICINITYAgent/Adapter

TheVICINITYAgent/Adaptershallprovidethefollowingfunctionality:

• Integration of IoT Infrastructure or value-added service into VICINITY through VICINITYGatewayAPIbyexposinglocalIoTobjectsintoVICINITYandsimulatesupportedtypeofIoTobjectsfromneighbourhoodinintegratedinfrastructure;

• VICINITYAgent/Adapterconfigurationservice;• SemanticmatchingbetweenparametrizeddemandsandavailableIoTnodedescriptors.

HowinteroperabilityworksinVICINITYThe VICINITY architecture follows an interoperability approach whose main goal is to provide astandardwaytobothDiscoverandAccessheterogeneous IoTobjectsdistributedamongsparse IoTinfrastructures. Theapproach is basedon theworkbeingdoneby theWebof Things (WoT)WG5,whereaproposal fordescribing, exposingand consumingweb things by leveraging SemanticWebtechnologies is indevelopment.SuchwebthingsarethingsthatcanbeaccessedthroughtheWeb,eitherphysicalorabstract.

5https://www.w3.org/WoT/IG/


Public

OneofthepillarsoftheW3CWoTistheThingDescription(TD),whichaimstobeastandardframetosupportdescribingwebthingssemanticallytomaketheminteroperable.Thus,TDsareexpectedtocoverthefollowingaspects:

• Semanticmeta-data,sotoexplicitlyspecifythesemanticsofawebthing;• Thing’sinteractionresources:property,actionandevent;• Securityincludingconcreteprerequisitestoaccessthingsarestated;• Communications,i.e.,whatkindofprotocolsanddataexchangeformatsaresupported,and

whichendpoints are exposed to give access to the existing interaction resources of awebthing.

VICINITY builds on this standard frame rather to define a brand new one: Thing EcosystemDescription (TED). The purpose of bringing the TED frame into the VICINITY’s interoperabilityscenario is to supportdescribingecosystems ofThings, i.e., setsofThings thatcoexist in the sameenvironment. In VICINITY, an IoT infrastructure makes up an ecosystem of IoT objects whosegroundingenvironment isthe infrastructure itself.However,theVICINITY interoperabilityapproachalsoconsidersasecosystemsthosesetsofIoTobjectswhosecommonenvironmentisdefinedbythescopeofaquerycontextfordiscoveryand/oraccessing.Suchecosystemsmadeupofquery-relevantIoTobjectsshallbedescribedinwhatwecallVirtualTEDs(VTEDs).

Therefore, VICINITY shall rely on TDs to describe every IoT object (which can represent eitherphysicalorabstractThings) thatbelong toany integrated IoT infrastructure,which in turnshallbedescribed in TEDs. Accordingly, each interested part in taking advantage of the semanticinteroperabilitysolutionprovidedbyVICINITYmustat leastbeabletounderstandsuchdescriptionframesaswellastheWebofThingsontology(seesection4.3.2).

IoTobjects’discovery

One of the main challenges of implementing interoperability in the IoT context is to enableconsumerstodiscover,inadistributedanddynamicscenario,thoseIoTobjectsthatarerelevanttotheir needs but without having any prior knowledge about them. The VICINITY interoperabilityapproachmakesthefollowingassumptionssothatdiscoveryworks:

1. ThereisacommonandabstractinformationmodeltosemanticallydescribeThings;2. AsemanticrepositoryofThingdescriptionsisavailableforconsumerstosearchforThings;3. Only those Things whose description is included in the semantic repository can be

discovered;4. Consumerslearnandleveragethecommonmodelandareawareofthesemanticrepository;5. Consumers specify their discovery needs as a search criteria that makes use of both the

semanticmodelandtheTDframe.

Thus,thesameassumptionsinVICINITY’stermsareasfollows:

1. TheVICINITYOntology(seesection4.3.2)isthecommonandabstractinformationmodeltobeused;

2. The Semantic discovery & dynamic configuration agent platform (3.1.2) is the semanticrepository.TheW3CWebofThingsTDistheframetobeusedfordescribinganyIoTobjectintegratedinVICINITY.

3. EachtimeanIoTobjectistobeproperlyintegratedinVICINITY,eitheratregistrationtimeorafter any change in its configuration, a TD must be inserted or updated in the semanticrepository.


Public

4. Gateway APIs (section 3.2.2) of VICINITY Nodes are the semantic mediators between theactual consumers, e.g., Adapters, and the repository of TDs. Therefore, they provide aninterfaceforDiscoveryrequests.

5. Gateway APIs must be able to specify discovery needs as semantic-based search criteria(SPARQLquery).

Figure 7 Semantic interoperability approach for Discovery

As described in section 2 and represented in Figure 7, the VICINITY is based on secure P2PcommunicationsbetweenVICINITYNodes foruserdata transfers.Further, theP2PNetwork isalsothe secure channel that supports the discovery information flow between Gateway APIs and theGatewayAPIServices,throughtheVICINITYCommunicationServer.Consequently,VICINITYprotectsIoT objects from being discovered by those Nodes that are out of their owner’s Neighbourhood,implicitlyincludingpotentialconsumersthatarenotpartofVICINITY.

In order to illustrate how discovery works in VICINITY, Figure 5 shows the following sequence ofinteractions:

1. With the aim of keeping actual consumers agnostic of semantics and ontology details,GatewayAPIs shallprovidean interface thatworksat syntactic level,utilizing thecommonVICINITY format tospecifya schema-basedsearchcriteria. It is theGatewayAPIwhomusttransformsuchrequestintoitscorrespondingSPARQLquery.

2. The newly created SPARQL query that represents the given search criteria is securelytransmittedtotheGatewayAPIServicesthroughtheP2PNetwork.

3. OncetheGatewayAPIservicescomponentreceivesasearchcriteriaintheformofaSPARQLquery, it is forwarded to the Neighbourhood Manager, which is responsible of applyingneighbourhood-filteringtoallmatchingTDsobtainedfromtheTDRepository;keepingonlythoseTDsthatrepresentIoTobjectsthatbelongtoconsumer’svirtualneighbourhood.


Public

4. As the Gateway API Services component receives the filtered TDsmentioned in step 3, itencapsulatesthemintoaVirtualTED.SuchVTEDdescribesthevirtualecosystemthatputsinconjunctiontheTDsthatmatchestheunderlyingsearchcriteria.

5. The Gateway API Services component sends the newly created VTED to the requesterthroughtheP2PNetwork.

6. After the VTED is intercepted by the Gateway API and properly processed, the set ofdiscovered IoT objects along with all relevant identifiers and meta-data is extracted andreturned,inthecommonVICINITYformat,totheactualconsumer.

IoTobjects’access

As mentioned at very beginning of this section, the second goal of semantic interoperability inVICINITY is to enable accessing to heterogeneous IoT objects in such a way that any of theirinteractionresourcescanbeeffectivelyconsumed.Here,effectiveness impliesthatthe informationprovided and/or required by these interaction resources must not only be collected but alsounderstood.

ThepresentinteroperabilityapproachforconsumingIoTobjectsassumesthefollowing:

1. Allendpoint declarations that are included in TDs for accessing interaction resourcesmustuse schema-based representations (syntactic interoperability) for the data theyprovide/require;

2. TDsshouldcontaintherequiredaccessmappingstoexplicitlyspecifythesemanticsofdatatobeexchangedwiththeendpoints.Byapplyingsuchaccessmappings,schema-baseddatabecomessemanticdata(datalifting6);

3. Context enrichment of TDsmay include concepts and predicates from vocabularies to beusedtospecifysemanticsinthoseaccessmappings.

Again,inVICINITY’sterms:

1. ThecommonVICINITYformatshallbeusedastheschematorepresentthedataprovided/requiredbyendpoints.

2. TDsofIoTobjectsmayincludepredefinedaccessmappingsforeachdeclaredendpointthatgivesaccesstothecorrespondingIoTobject’sdata.Ifnecessary,atthetimeofthediscoveryprocess, theGatewayAPIServicesmaydynamicallyattachquery-relevantaccessmappingsforeachTDincludedintheresultingVirtualTED.

3. SincetheVICINITYOntologyaimstocoverdifferentlevelofabstractions(e.g.,core,domain-specific,etc.),anyconceptorpredicate,atanyabstractionlevel,maybeusedtoenrichthecontextoftheTDs.

6Liftingofschema-baseddatatoreachsemanticallystructuredand interlinkeddata,e.g., fromplainJSONtoRDF.


Public

Figure 8 Semantic interoperability approach for Accessing

Figure 8 illustrates an example of how VICINITY shall support semantic interoperability forconsumptionof IoTobjects,concretely, forgettingpropertyvalues.Similarly,tohowdiscoverywasillustrated inFigure7, thisdiagramdescribeshow theapproachworksbymeansofa sequenceofinteractions:

1. TheGatewayAPI shall offer a dedicated interface for Consumption requests,which in theexample,receivestwogetPropertyValuecommandspointingatdifferentIoTobjects(TCandTD). It is assumed that the Gateway API was previously given a Virtual TED through adiscovery request (step 0). Thanks to this, the consumer can use the correspondingidentifiersofeach IoTobjectand theirpropertiesat the timeof invokingbothcommands.Again,theConsumptioninterfaceallowsconsumerstobeagnosticofontologies.

2. TheGatewayAPIprocessesthefirstcommandandsendsamessagetotheNodethathoststhe referenced IoTobject. In this case, theP2P communication canbedirectly establishedbetweenthetwoinvolvedNodes.

3. Asinthepreviousstep,theGatewayAPIprocessesthereceivedcommand,butinthiscase,therecipientNodeisnotdirectlyreachableduetosomenetworkconstraintin-between.TheCommunication Server takes care of the issue and makes sure that the message finallyreachesitsaddressedNode.

4. OncethecorrespondingGatewayAPIoftherecipientNodegetsthemessage,itqueriestheTEDthatdescribes itsown infrastructure todeterminethespecificendpoints thatmustbeinvoked. Having all raw data collected from its underlying infrastructure, the recipient


Public

GatewayAPIcomposesaresponsemessageandsendsitbacktotherequester(throughtheCommunicationServer).

5. Sameprocessasdescribedinstep4,exceptfortheP2Pcommunicationdoesnotrequireanintermediary.

The Gateway API processes both incoming response messages separately and applies thecorrespondingaccessmappingsspecifiedinthepreviouslygivenVirtualTED.Foreachresponseandafterthedataliftingprocessiscompleted,theGatewayAPIextractsthepropertyvaluebyqueryingthejustliftedsemanticdata.Finally,theGatewayAPIreturnseachresultobtainedandrepresentedinthecommonVICINITYformat.


Public

InformationviewThissectiondescribestheflowofinformationbetweenVICINITYcomponentsassummarizedonthefollowingFigure9.Theinformationflowscanbegroupedinfollowinggroups:

• Semanticdataflowsincludingsemanticdiscoveryandquery,IoTobjectdescriptions,virtualIoTobjectdescriptionsandtemplates;

• ConfigurationdataflowsincludingIoTobjectmeta-dataandvariousVICINITYconfigurations;• Syntacticdataflowsfortransmissionofuserdata.

Figure 9 VICINITY Architecture information flow


Public

VICINITYCloud

VICINITYNeighbourhoodmanager

TheVICINITYNeighbourhoodmanagershallfacilitatethefollowinginformationflows:

Table 1 Information flow from VICINITY Neighbourhood manager

Informationflow Destination Reason

Discoveryquery Semanticdiscoveryanddynamicconfigurationplatform

VirtualneighbourhoodmanagerusesDiscoveryquerytosearchforThingsinneighbourhood.

IoTobjectsdescriptions(TDs) Semanticdiscoveryanddynamicconfigurationplatform

SemanticdiscoveryanddynamicconfigurationplatformneedsIoTobjectdescriptiontoperformsemanticliftingonIoTobjectdescription.

IoTobjectsdescriptions(TDs) VICINITYGatewayAPIServices VICINITYGatewayAPIServicesneedssetofIoTobjectsdescription(asresultofDiscoveryquery)constrainedbyvirtualneighbourhoodsharingaccessrules.

VICINITYNodeconfigurations VICINITYCommunicationServer

VICINITYCommunicationServerdistributesconfigurationtorespectiveVICINITYNodes.

Semanticdiscoveryandagentconfiguration

Semanticdiscoveryandagentconfigurationshallfacilitatethefollowinginformationflows:

Table 2 Information flow from Semantic discovery and agent configuration


IoTobjectstemplates VICINITYNeighbourhoodManager

VICINITYNeighbourhoodManagerenablestoconfigureIoTobjectsmanuallybyuser.

IoTobjectsdescriptions(TDs) VICINITYNeighbourhoodManager

VICINITYNeighbourhoodManagerneedsTDsasresultofthediscoveryqueriesandsemanticlifting.

VICINITYAgentconfigurations VICINITYNeighbourhoodManager

VICINITYNeighbourhoodManagershallforwardanAgentconfigurationtoVICINITYNode.


Public


VICINITYGatewayAPIServicesshallfacilitatethefollowinginformationflows:

Table 3 Information flow from VICINITY Gateway API Services


Discoveryquery VICINITYNeighbourhoodManager

VICINITYNeighbourhoodManagerforwardsthediscoveryquerytosemanticplatform.

VirtualIoTobjectsdescription(VTEDs)


VICINITYCommunicationServerforwardsVTEDtoVICINITYGatewayAPI.


TheVICINITYCommunicationservershallfacilitatethefollowinginformationflows:

Table 4 Information flow from VICINITY Communication Server


Discoveryquery VICINITYGatewayAPIServices

VICINITYCommunicationServerforwardsDiscoveryquerytoVICINITYGatewayAPIServices.

VICINITYNodeconfigurations


VICINITYCommunicationServershallforwardVICINITYNodeconfigurationtorelevantVICINITYNodes.

VICINITYNodeauto-configurations


VICINITYCommunicationServershallforwardauto-configurationofVICINITYNodeforVICINITYUseracknowledgement.

IoTobjectmeta-data VICINITYNeighbourhoodManager

VICINITYCommunicationServershallforwardtoVICINITYNeighbourhoodManagernewIoTobjectdescriptionreceivedfromVICINITYNodes.

VICINITYNode


TheVICINITYCommunicationNodeshallfacilitatethefollowinginformationflows:

Table 5 Information flow from VICINITY Communication Node


Userdata VICINITYCommunicationNode,VICINITYGatewayAPI

ToexchangeofuserdatathroughP2PNetwork


VICINITYGatewayAPI ToforwardsAgentandGatewayAPIconfigurationupdates


Public




Toforwardauto-configurationtoVICINITYNeighbourhoodManagerforprocessing

IoTobjectmeta-data VICINITYCommunicationServer

Toforwarddescriptionforsemanticmapping

IoTobjectdescriptions(VTED)

VICINITYGatewayAPI ToforwardVTEDStoconfigureAPIs

VICINITYGatewayAPI

TheVICINITYGatewayAPIshallfacilitatefollowinginformationflows:

Table 6 Information flow from VICINITY Gateway API


Discoveryquery VICINITYCommunicationServer

ToforwarddiscoveryquerytoVICINITYNeighbourhoodManager.

Userdata VICINITYCommunicationNode,VICINITYAgent/Adapter

ToforwarduserdatathroughP2PNetwork.

VICINITYAgent&GatewayAPIauto-configurations


ToforwardAgentandGatewayAPIconfigurationtoVICINITYNeighbourhoodManagertosetupinteroperabilityduringinitializationprocess.

VICINITYAgentconfiguration

VICINITYAgent ToforwardAgentconfigurationupdatestoVICINITYAgent.

IoTobjectmeta-data VICINITYCommunicationNode

ToforwardnewIoTobjectdescriptionforsemanticmappinginsemanticplatform.


TheVICINITYAgent/Adaptershallfacilitatethefollowinginformationflows:

Table 7 Information flow from VICINITY Agent/ Adapter


Discoveryquery VICINITYGatewayAPI Todiscoverthevirtualneighbourhood.

Userdata VICINITYGatewayAPI ToforwarduserdatathroughP2PNetwork.


Public


VICINITYAgentauto-configurations

VICINITYGatewayAPI ToforwardinitialAgentconfigurationtoVICINITYNeighbourhoodManagertoinitializeinteroperabilitysetup.

IoTobjectmeta-data VICINITYGatewayAPI ToforwardnewIoTobjectdescriptionforsemanticmappinginsemanticplatform.

DatastoragesThissectiondescribestheconceptofinformationmanagementintheVICINITY.Thefollowingtypeofstorageshasbeenidentified:

• Globalneighbourhoodstoragestoringvirtualneighbourhooddataincludingsocialnetworkoforganizations,users,IoTobjectsincludingsharingrulesandprofile7s.ThisstorageincludesVICINITYNodecomponentsconfigurationaswell;

• SemanticModelandAgentConfigurationStorageencompassessemanticdescriptionofeachIoTobjectsandtheirrelationships.

ThesestoragesaremaintainedbytwocoreVICINITYcomponents:

• VICINITYNeighbourhoodManagermastersglobalneighbourhoodstorage;• Semanticdiscovery&dynamicconfigurationagentplatformmasterssemanticmodel&

agentconfigurations.

Figure 10 VICINITY Data storages

7Theprofile issetofentity (IoTobject,user,organization)propertiesconfigurable inVICINITYNeighborhoodmanager.SubsetofIoTobjectprofileisIoTobjectdescription.


Public

Data from storages aredistributedwith theVICINITY architecturebyexecutingVICINITYprocessesdescribedinsection5throughdefinedinformationflowsdefinedin4.1and4.2.

Globalneighbourhoodstorage

TheGlobalneighbourhoodstoragemanagedbyVICINITYNeighbourhoodManagerincludesfollowingitems:

• UserandOrganization;• IoTobjectsreferences(devicesandvalue-addedservices)andGroupofIoTobjects;• SecurityAccessRules;• VICINITYNodeconfigurations;

UserandOrganization

VICINITY-ARCH-INF-010 UserandOrganizationentities

GlobalneighbourhoodstorageshallincludeOrganizationwithassignedUsersregisteredinVICINITY.

Users(humanandnon-human)entityincludes:

• Identifier,• credentials,• profile,• setofroleswithinrelatedorganization.

Organizationentityincludes:

• organizationprofile,• setofreferencestoassignedusers,• setofreferencestoownedVICINITYNodes,• setofreferencestoownedgroupsofIoTObjects,• setofreferencestoassignedsharingaccessrules.

Consideredrequirements:

VICINITY-NFUNC-PRV010

SharingAccessRulesVICINITY-ARCH-INF-030 SharingAccessRules

Global neighbourhood storage shall include Sharing Access Rules which defines single sharingdecisionofIoTobjectvirtualneighbourhood.

SharingAccessEntryshallreference:

• ReferencetoOrganizationtowhichsharingaccessisgranted;• Sharingaccessprivilege;• ReferencetoIoTobject(includingproperty,actionandevent)orGroupofIoTobjects.


VICINITY-NFUNC-PRV010,VICINITY-FUNC-UCR020,VICINITY-FUNC-UCR070,


Public

VICINITYNodeConfigurations

VICINITY-ARCH-INF-040 VICINITYNodesConfigurations

GlobalneighbourhoodstorageshallincludeeachVICINITYNode,whichisreferencedtoorganizationandIoTObjects.

VICINITYNodesshallincludesetofactualconfigurationsof:

• VICINITYCommunicationNode;• VICINITYGatewayAPI;• VICINITYAgent/Adapter.

Configurationshallinclude:

• Identity of the configuration’s source (e.g. VICINITY Neighbourhood Manager, Semanticdiscoveryandagentconfigurationplatform);

• Identityoftheconfiguration’sdestination;• Configurationidentifier;• Configurationdata;• Dataintegrityattributes(optionally).



VICINITY-ARCH-INF-045 VICINITYNodeconfigurationacknowledgement

Theconfigurationupdateacknowledgementshallinclude:

• Identityoftheconfiguration’ssource;• Identityoftheconfiguration’sdestination;• Configurationidentifier;• ConfigurationACK;• Dataintegrityparameters(optionally).


VICINITY-NFUNC-SEC050

SemanticModelandAgentConfigurationStorage

The storage includes themodelsof all objects able to interactwithVICINITY agents/adapters. Thepurpose of this storage is to provide the semantic descriptions of stored items to enable themachine-readablesemanticinterpretation.Semanticenhancementofobjectdescriptionsalsoenabletoperformseveralqueryingandlookupsinsemanticway.

The storage will be implemented as high-performance semantic triplestore providing standardsemanticsearchservices,suchasSPARQLendpoint.

Generally,thestorageincludestwobasicitems:semanticmeta-modelsandsemanticrepresentationofIoTobjects(TEDs).


Public

VICINITY-ARCH-INF-050 Semanticmeta-models

Semanticmeta-models:theupperontologies,hierarchiesofobjects,types,domainspecificmodels.Generally, themodels providing basic semantic context of IoT objects. All semantic instances aremapped to these meta-models to enable common automatic interpretation of semanticinformation.


VICINITY-FUNC-UCR080,VICINITY-FUNC-UCR120

Semantic description of objects, which reside in infrastructures, that are integrated into VICINITYplatform.Usually,theIoTobjectprovidesthesetofservicesforinteraction.Itcanbephysicaldeviceorsensor,butintermsofVICINITY,itcanbealsothevalue-addedservice.Thepurposeofsemanticenrichmentistoenableperformancesemanticqueries/lookups,butalsoautomaticinterpretationofobjectpropertiesandservices.

VICINITY-ARCH-INF-060 IoTobjectdescription

TheIoTobjectdescriptionofIoTobjectcontains:

• theidentifierofIoTobject;• descriptionofinteractionwithIoTobject:thesetofservices,actionsoreventsprovidedby

device;• description of grounding information of device interaction possibilities (e.g. endpoints,

protocols,input/outputparameterdescription);• additional properties enabling more precise semantic interpretation, such as capabilities

(e.g.hasdisplayormeasurestemperature);• themanufacturerandmodelinformationincaseifIoTobjectisphysicaldevice.



TherearetwotypesofIoTobjectinstances:

• IoT object templates: preconfigured models for each specific IoT object types, generallydescribingtheobjects(e.g.specificdevicemodel).Thesetemplatesareusedindiscoveryandconfiguration process to create mapping between physical IoT objects and correspondingmodels.ForeachspecificIoTobjectthereexiststhegenericIoTobjecttemplate.ForeachIoTobject,thediscoveryprocessfindsthetemplate,which isusedtocreatespecific IoTobjectinstance.

• IoTobjectdescription:theroleofdiscoveryprocessistofindtheproperobjecttemplateforeachphysicalIoTobject.Oncethismatchingissuccessful,thenewuniqueinstanceforeachphysicalIoTobjectiscreatedfromidentifiedtemplateandmappingiscreated.Thus,foreachphysicalIoTobjectthereexistsitsowncorrespondinginstanceinsemanticrepository.

Generally,therearetwodifferentdescriptorsofIoTobjects:• the IoT objectmeta-data: provided by VICINITY Agent, containing basic information about

theobjectusedtofindthecorrespondingIoTobjecttemplate


Public

• IoT object template: representing genericmodel of specific IoT object type (e.g.model ofconcretesensor).

VICINITYsemanticmodels

Intheinformationtechnologiescontext,ontologiescanbedefinedas“formal,explicitspecificationsof a shared conceptualisation”. The VICINITY ontologies will be formal in the sense of followingDescriptionLogicsandbeingimplementedintheW3CWebOntologyLanguagestandardOWL8.Theconceptualization to be shared among the VICINITY components and plugged systems will coverdifferent domains of interest ranging from horizontal domains like time and space to specificdefinitionsneedwithintheVICINITYecosystem.Forthisreason,asshowninFigure11,theVICINITYapproach is based on a modular ontology network in which existing standard ontologies will bereusedwheneverpossible.

In summary, the ontology network will be composed by: 1) cross-domain ontologies (horizontaldomains)addressingthemodellingofgeneralconcepts liketime,space,webthings, thatwouldbereusedandprobablyextendedby2)theVICINITYplatformorientedontologythatwillrepresenttheinformationneededtoexchangeIoTdescriptordatabetweenpeersandthatwouldbeextendedby3)domainorientedontologiesthatwouldcoververticaldomainssuchashealth,transport,buildings,etc.

8https://www.w3.org/TR/owl-ref/


Public

Figure 11 VICINITY ontology network design

As it isalsoshown in theFigure11,VICINITYontologicalmodulesmightbereusedbyexternalusecasesorapplications.Asdepictedintheleftsideofthefigure,theontologicalrequirementsthatwillguide the ontology development will come from VICINITY partners needs and VICINITYdocumentation.

Apart from the domain-specific ontological requirements, the VICINITY ontologies development isbasedonthefollowingnon-functionalrequirements:

• Reuse: existing ontologies or standard models will be reused when possible increasinginteroperabilitywithexternalsystemsthatmightbealreadyusingsuchontologies.Thispointisalsoappliedatameta-levelbyusingstandard technologies to implement theontologiesthemselves.

• Modularity: the ontology should be designed as a network in which modules might beinterconnectedandrefertoothers.

• Extensibility:theontologiesshouldallowthedevelopmentofthird-partyextensions.

Finally,theontologieswillbedevelopedfollowingmethodologiesandbestpracticescommonlyusedin ontological engineering to address ontology development activities such as design,implementation,evaluation,publication,anddocumentation,amongothers.

Legend

Document

Document

health

building

transport

VICINITYDomainOntologies

VICINITYCrossdomain Ontologies

SpaceWeb of ThingsTime

Upper Level

time

space Vicinitycore ontology

Service

VICINITYUse caseOntologies

ExternalUse caseOntologies

VICINITYRequirements

Health Transport Building

Use case 2Use case 1

Use case N Use case M Use case O

Usab

ility

Reus

abilit

y

-+

+-

drives

is reused by

is extended byconcept


Public

ProcessviewThis chapter defines the set of processes driving interaction between VICINITY componentssupportingthefollowingfunctionalityprovidedbyVICINITYdescribedinD1.5.

• Deviceregisteranddiscovery;• Deployvalue-addedservices;• Interoperabilitysetup;• ConnectingIoTinfrastructureintoVICINITY;• VICINITYSecurity&privacyfeatures;• VICINITYUsernotification;

VICINITY-ARCH-PRC-010 VICINITYCrosscomponentprocesses:

TheVICINITYshallsupportfunctionalitiesbythefollowingcrosscomponentprocesses:

• ConnectingVICINITY (5.1.1) supports setupof communicationchannelsbetweenVICINITYNodes’componentsandVICINITYCloud;

• VICINITYNodeconfigurationdistribution(5.1.2)managesdistributionofanyconfigurationchange(suchasIoTobjectlifecyclechangeinVICINITY,sharingaccessrulechange,securityand privacy configuration change, agent configuration change) originated in the VICINITYCloudtorelevantVICINITYNodescomponents;

• SemanticdiscoveryofIoTObjects(5.1.3)providesIoTobjectsregistrationprocesseswithinVICINITY, including IoT objects semantic normalization and IoT objects search withinVICINITYneighbourhood;

• User data exchange facilitation (5.1.4) provides processes to exchange data betweenVICINITYNodesutilizingthesemanticinteroperability.


VICINITY-FUNC-UCR060, VICINITY-FUNC-UCR090, VICINITY-FUNC-UCR100, VICINITY-FUNC-UCR130,VICINITY-FUNC-UCR140,VICINITY-FUNC-UCR145

Thischapterfocusesonlyonprocessesspanningacrossmorethanonecomponent.Significantsinglecomponentprocesses(functions)aresubjectofdetaildesign.

ConnectingVICINITY

The Connecting VICINITY process goal is to setup communication between the VICINITY Nodecomponents and VICINITY Cloud component including configuration of virtual neighbourhood andagent platform model. The communication is setup manually with optional automatic pre-configuration.

VICINITY-ARCH-PRC-020 VICINITYNodecommunicationsetup

TheVICINITYshall supportmanual setupcommunication interfacesofVICINITYNodecomponentswithVICINITYCloudcomponents:

• VICINITYCommunicationNode,• VICINITYGatewayAPI,• VICINITYAgent/Adapter.

bySystemintegrator.


Public


VICINITY-FUNC-UCR140

VICINITY-ARCH-PRC-030 VICINITYNodeauto-configuration

The VICINITY shall support automatic auto-configuration of communication interfaces setup ofVICINITYNodecomponents:

• VICINITYCommunicationNode,• VICINITYGatewayAPI,• VICINITYAgent/Adapter

bySystemintegrator.



VICINITY-ARCH-PRC-040 VICINITYNodeconfigurationstore

The VICINITY shall store VICINITY Node components identities and its configuration in virtualneighbourhoodandagentplatform.


VICINITY-FUNC-UCR140,VICINITY-NFUNC-PER050

VICINITY-ARCH-PRC-050 VICINITYNoderegistrationrequest

TheVICINITYNoderegistrationrequestshouldinclude:

• Identityoftheregistrationrequest;• Identityofuserunderwhichregistrationisperformed;• IdentityofVICINITYCommunicationNode;• IdentityofVICINITYGatewayAPI;• IdentityofVICINITYAgent/Adapter;• Initialconfigurationofeachcomponentincludingatleast:

o Componentidentifier(ifavailable);o Identifierofcomponent’sinterfaces.



ManualVICINITYNoderegistration

The manual registration of VICINITY Node is performed by System integrator through VICINITYNeighbourhoodManager(Figure12).VICINITYNeighbourhoodManagerregistersVICINITYNodesinagentplatformandperformsVICINITYNodeconfigurationchangeprocesstodistributeconfigurationtoVICINITYNodescomponents.


Public

Figure 12 Manual VICINITY Node registration process

ManualVICINITYNoderemoval

The manual removal of VICINITY Node is performed by IoT Operator through VICINITYNeighbourhoodManager (Figure 13). VICINITYNeighbourhoodManager sends removal request toVICINITYNode.WhentheremovalofVICINITYNodefromP2PnetworkisacknowledgedbyVICINITYCommunication Server then VICINITY Node is removed from the Semantic discovery and agentconfigurationplatform.

Figure 13 Manual VICINITY Node removal

Auto-configurationofVICINITYNode

The auto-configuration of VICINITY Node initiates registration process of VICINITY Nodes fromVICINITYAgent,throughVICINITYGatewayAPItoVICINITYCommunicationNode(Figure14).Afterarequest arrives in VICINITY Neighbourhood Manager the manual registration process shall beexecuted after acknowledgement of a System integrator, where System integrator can validateand/orupdateVICNITYNodeconfigurations. Theauto-configurationprocess is anextensionof themanualregistrationprocess.


Public

Figure 14 Auto-configuration of VICINITY Node

VICINITYNodeconfigurationdistribution

TheVICINITY goal ofVICINITYNode configurationdistributionprocess is todistribute theVICINITYconfiguration changes to relevant VICINITY Node. Every configuration change needs to beacknowledgedbytheconfigurationdestinationcomponent.

VICINITY-ARCH-PRC-060 VICINITYNodeconfigurationdistribution

TheVICINITYshallsupportdistributionoftheVICINITYNodeconfiguration(4.3.1.3)to:

• VICINITYCommunicationNode,• VICINITYGatewayAPI,• VICINITYAgents

throughVICINITYCommunicationserver.


VICINITY-FUNC-UCR060, VICINITY-FUNC-UCR090, VICINITY-FUNC-UCR100, VICINITY-FUNC-UCR130,VICINITY-FUNC-UCR140

VICINITY-ARCH-PRC-090 VICINITYNodeconfigurationprocessing

TheVICINITYNode’sComponentshallvalidateVICINITYNodeconfigurationbeforeitsprocessing.

The VICINITY Node’s Component forwards only configuration attributes relevant for destinationcomponent.

Each VICINITY Node’s component shall send VICINITY Node configuration updatedacknowledgementaftersuccessfulprocessingofconfigurationupdate.



Configurationupdatedistribution

ThisprocesstransmitstheIoTobjectconfigurationupdatefromVICINITYNeighbourhoodManagertoVICINITYCommunicationNode,andoptionallytoVICINITYAgent/AdapterandVICINITYGatewayAPI.The Configuration is distributed through VICINITY’s P2P Network to VICINITY Node components.Afterwards,itisprocessedbyVICINITYNode’scomponentsincascademanner.EachVICINITYNode’s


Public

component acknowledges the process of its configuration separately in case of configurationwasprovidedthroughtheconfigurationdistributionprocess.

Figure 15 VICINITY Node configuration distribution process

SemanticdiscoveryofIoTobjects

ThegoaloftheSemanticdiscoveryofIoTobjectsistwofold:

• to search of IoT objects in the VICINITY neighbourhood manager with support of thesemanticdatastoredinSemanticdiscoveryandAgentconfigurationplatform;

• to maintain semantic data of VICINITY neighbourhood manager including agentconfiguration.

VICINITY-ARCH-PRC-110 SearchofVICINITYNeighbourhood

TheVICINITYshallprovidesearchinvicinityneighbourhoodmanagertodiscoverIoTobjectsbasedonrequestfrom:

• VICINITYNeighbourhoodmanagerrequestedbyVICINITYUsers;• VICINITYGatewayAPIrequestedbyVICINITYAdapterorVICINITYAgent.

TheVICINITY shall constrain searchby applyingof sharing access rulesbasedon identity resultedfromdiscoverysearch.


VICINITY-FUNC-UCR080,VICINITY-FUNC-UCR120,VICINITY-FUNC-UCR160

VICINITY-ARCH-PRC-120 ManualIoTobjectregistration

TheVICINITYshallsupportregistrationofnewIoTobjectsbasedonrequestfrom:

• VICINITYNeighbourhoodmanagerrequestedbyVICINITYUsers.


Public

VICINITY-ARCH-PRC-120 ManualIoTobjectregistration

ThenewIoTobjectrequestedfromVICINITYGatewayAPIshallbeacknowledgedbyVICINITYUser.

VICINITY shall store IoT object description (TD) in semantic model and distribute IoT objectconfigurationtoVICINITYNodecomponents.


VICINITY-FUNC-UCR060,VICINITY-FUNC-UCR080,VICINITY-FUNC-UCR100,VICINITY-FUNC-UCR120

VICINITY-ARCH-PRC-130 IoTobjectregistrationfromVICINITYAdapter/Agent

TheVICINITYshalloptionallysupportregistrationofnewIoTobjectsbasedonrequestfrom:

• VICINITYGatewayAPIrequestedbyVICINITYAdapterorVICINITYAgent.

ThenewIoTobjectrequestedfromVICINITYGatewayAPIshallbeacknowledgedbyVICINITYUser.



VICINITY-ARCH-PRC-140 IoTobjectdescriptors

The VICINITY shall support periodically search of external IoT descriptors repository for new IoTobjectdescriptors.

EachnewIoTobjectdescriptorshallbemappedtoVICINITYOntologyandrelevantVICINITYAgentshouldbeconfiguredtobeabletodiscoverIoTobjectsimplementingthedescriptor.


N/A

SearchforIoTobjectsinVICINITY

TheseprocessesperformthesearchofIoTobjectsbasedonrequestfrom:

• VICINITYNeighbourhoodManagerperformedbyVICINITYUsers(Figure15);• VICINITYGatewayAPIperformedbyVICINITYAgentsand/orVICINITYAdapter(Figure16).

Search for IoT objects can be performed by VICINITY User directly in VICINITY NeighbourhoodManagerwhichutilizessemanticdatasearchrequestandreturnsthesetof IoTobjectdescriptions(Figure15).


Public

Figure 16 Semantic search of IoT objects from VICINITY Neighbourhood Manager However, VICINITY Gateway API provides discovery service for VICINITY Agents / Adapters. TheVICINITY Gateway API utilizes VICINITY Gateway API Services through VICINITY CommunicationServer.TheVICINITYCommunicationServeractsascommunicationborderbetweenVICINITYNodecomponentsandVICINITYCloud.Afterwards,requestisforwardedthroughVICINITYNeighbourhoodManager,whichappliessharingaccessrulestoresultofthesemanticdatasearchresults(ListofTDs)basedoncontextofidentityunderwhichsearchisperformed.

Figure 17 Semantic search of IoT objects from VICINITY Gateway API

ManualIoTObjectregistration,changeofconfigurationandremoval

Any manual change of IoT object (registration, configuration change, removal) is performed byVICINITYUser throughVICINITYNeighbourhoodManager.VICINITYNeighbourhoodManagersendsan IoT Object change in Semantic discovery platform and update relevant VICINITY Nodes withsharingaccessrulesutilizingVICINITYNodeconfigurationchangeprocess.


Public

Figure 18 Manual change of IoT object

AutomaticregistrationofnewIoTObjects

ThisprocessenablestoregisternewIoTobjectsbyVICINITYAgent/Adapter.RequestsfornewIoTobjects are sent to VICINITY NeighbourhoodManager for configuration and approval by VICINITYUser(DeviceownerorServiceprovider). IoTobjectsdescriptionsshallbestoredinsemanticmodelandIoTobjectconfigurationshouldbeforwardedtoVICINITYNodecomponents.

Figure 19 Automatic registration of IoT object in VICINITY

The same process is applied in case of any automatic device configuration change, howeverautomaticdeviceremovalcannotbeperformed.

CrawlingofexternalrepositoriesofIoTobjecttemplates

Thisprocessperformscrawlingofexternalrepositoriesof IoTobjectstemplates(seesection4.3.2).Each new IoT object template is mapped to VICINITY Ontology. IoT normalized description isprovided to VICINITY Neighbourhood manager for manual IoT object registration functionality.Moreover,therelevantVICINITYAgentsareupdatedbeingabletodiscovernewIoTobjects.


Public

Figure 20 Crawling external repositories process

Userdataexchangefacilitation

TheUser data exchange facilitation processes enable to consume and expose IoT objects throughVICINITY, thusVICINITYNodes can have the role of clients (consuming IoT objects) and/or servers(exposingIoTobjects)ofVICINITYP2Pnetwork.

VICINITY-ARCH-PRC-150 IoTobjectsinteractionpatterns

VICINITY shall support the following interactionpatterns toexchangeuserdatabetweenVICINITYNodethroughVICINITYP2Pnetwork:

• GettingIoTobjectproperty;• SettingIoTobjectproperty;• CallingactionofIoTobject;• ReceivingofeventfromIoTobject.



ConsumingofThingsthroughtheVICINITY

This section defines the user data exchange processes from the point of view of VICINITY Agent/Adapter(A),whichconsumesIoTobjectsthroughtheVICINITYfromVICINITYCommunicationNode(B).TheVICINITYAgent/Adapter(A)consumesIoTobjectsby:

• “getting”IoTobject’sproperty;• “setting”IoTobject’sproperty;• callingactionofIoTobject;• receivingofeventfromIoTobject.


Public

5.1.4.1.1. “Getting”propertyofconsumedIoTobject

ThisprocessenablesVICINITYAgent/Adapter(A)togetpropertyofconsumedIoTobject.Thegetproperty request and response are communicated through the VICINITY P2P network applyingmessageen/decryption(basedonconsumedIoTobjectconfiguration)andauthorizationcheckbasedonsharingaccessrulesconsideringcontextofVICINITYAgent/Adapter(A)identity.

Figure 21 “Getting” property of consumed IoT object

5.1.4.1.2. “Setting”propertyofconsumedIoTobject

ThisprocessenablesVICINITYAgent/Adapter (A) tosetpropertyofconsumed IoTobject.Thesetproperty request and response are communicated through the VICINITY P2P network applyingmessageen/decryption(basedonconsumedIoTobjectconfiguration)andauthorizationcheckbasedonsharingaccessrulesconsideringcontextofVICINITYAgent/Adapter(A)identity.


Public

Figure 22 “Setting” property of consumed IoT object

5.1.4.1.3. CallingactionofconsumedIoTobject

ThisprocessenablesVICINITYAgent/Adapter(A)tocallactionofconsumedIoTobject.Theactionrequest and response are communicated through the VICINITY P2P network applying messageen/decryption (based on consumed IoT object configuration) and authorization check based onsharingaccessrulesconsideringcontextofVICINITYAgent/Adapter(A)identity.

Figure 23 Calling action of consumed IoT object


Public

5.1.4.1.4. ReceivingeventfromconsumedIoTobject

This process enables VICINITY Agent / Adapter (A) to receive consumed IoT object. The eventmessage and optionally event acknowledgement are communicated through the VICINITY P2Pnetwork applying message en/decryption (based on consumed IoT object configuration) andauthorizationcheckbasedonsharingaccessrulesconsideringcontextofVICINITYAgent/Adapter(A)identity.

Figure 24 Receiving event from consumed IoT object

ExposingofthingsthroughtheVICINITY

This section defines the user data exchange processes from the point of view of VICINITY Agent/Adapter(B),whichexposesIoTobjectsthroughtheVICINITYforVICINITYCommunicationNode(A).TheVICINITYAgent/Adapter(B)exposesIoTobjectsby:

• “getting”IoTobject’sproperty;• “setting”IoTobject’sproperty;• receivingactionofIoTobject;• emittingofeventfromIoTobject.


Public

5.1.4.2.1. “Getting”propertyofexposedIoTobject

ThisprocessenablesVICINITYAgent/Adapter(B)toreceiverequestforgetpropertyofexposedIoTobjectincludingprovisionofpropertyvalueforVICINITYCommunicationNode(A).Thegetpropertyrequest and response are communicated through the VICINITY P2P network applying messageen/decryption (based on consumed IoT object configuration) and authorization check based onsharingaccessrulesconsideringcontextofVICINITYAgent/Adapter(A)identity.

Figure 25 “Getting” property of exposed IoT object

5.1.4.2.2. “Setting”propertyofexposedIoTobject

ThisprocessenablesVICINITYAgent/Adapter(B)toreceiverequesttosetpropertyofexposedIoTobjectincludingprovisionofpropertyvalueforVICINITYCommunicationNode(A).Thesetpropertyrequest and response are communicated through the VICINITY P2P network applying messageen/decryption (based on consumed IoT object configuration) and authorization check based onsharingaccessrulesconsideringcontextofVICINITYCommunicationNode(A)identity.


Public

Figure 26 "Setting" property of exposed IoT object

5.1.4.2.3. ReceivingactionofexposedIoTobject

ThisprocessenablesVICINITYAgent/Adapter(B)toreceiveactionofexposedIoTobject.Theactionrequest and response are communicated through the VICINITY P2P network applying messageen/decryption (based on consumed IoT object configuration) and authorization check based onsharingaccessrulesconsideringcontextofVICINITAgent/Adapter(A)identity.

Figure 27 Receiving action of exposed IoT object


Public

5.1.4.2.4. EmittingeventofexposedIoTobject

This process enablesVICINITYAgent /Adapter (B) to emit eventof exposed IoTobject. Theeventmessage and optionally event acknowledgement are communicated through the VICINITY P2Pnetwork applying message en/decryption (based on consumed IoT object configuration) andauthorization check basedon sharing access rules considering context of VICINITY CommunicationNode(A)identity.

Figure 28 Emitting event of exposed IoT object

MappingofVICINITYFunctionalitiestoVICINITYArchitectureprocesses

TheseprocessescanbemappedtotheVICINITYfunctionalitiesdefinedinD1.5asfollows:

Table 8 Mapping of VICINITY Functionalities to VICINITY Architecture processes

Mainfunctionality Detailedfunctions Process

Connecting IoT infrastructureintoVICINITY

VICINITY Nodesregistration andderegistration

ConnectingVICINITY

Data exchangefacilitation

Consuming of things through theVICINITY;


Public

Mainfunctionality Detailedfunctions Process

ExposingofthingsthroughtheVICINITY;

Deviceregisteranddiscovery Registernewdevice RegistrationofnewIoTobject;

VICINITYNodeconfigurationdistribution;

Crawlingofexternalrepositories

ConfigureIoTdevice VICINITYNodeconfigurationdistribution

RemoveIoTdevice VICINITYNodeconfigurationdistribution

Deployvalue-addedservices Register new value-addedservice

RegistrationofnewIoTobject;


Crawlingofexternalrepositories

ConfigureValue-addedservice


Remove value-addedservice


Interoperabilitysetup Changeinorganizationpartnership;


Change in IoT Devicesharingaccessrules;


ChangeinValue-addedservice sharing accessrules;


VICINITY Security & privacyfeatures

Updating access rulestoIoTobjects


VICINITYUsernotification;

Updating security &privacyconfiguration


VICINITYUsernotifications VICINITYUsernotification;


Public

InterfacesViewThis sectiondefines setof interfacesbetweenVICINITYComponents summarized in Figure29.Theinterfaces are specified by name, component providing interface, component using interfacesintegrationpatternandconceptualdataexchangedthroughtheinterface.

Figure 29 VICINITY Interface view

VICINITYCloud

VICINITYNeighbourhoodmanager

TheVICINITYNeighbourhoodmanagershallprovidefollowinginterfaces:

Table 9 Interfaces provided by VICINITY Neighbourhood manager

NameofInterface Usedby Integrationpattern

DataExchanged

Authenticationservice VICINITYCommunicationNode,VICINITYGatewayAPI,VICINITYAgent

Tokenrequestandvalidation

Usercredentials,Securitytokens


Public


DataExchanged

Neighbourhooddiscoveryservice

VICINITYGatewayAPIServices Request/Response Discoveryquery,IoTObjectdescriptions(TEDs)

Registryservice VICINITYCommunicationServer Request/Response IoTObjectsmeta-data

Semanticmodelchangenotifications

SemanticPlatform Request/Response IoTObjectstemplates

Semanticdiscoveryanddynamicconfigurationagentplatform

Semanticdiscoveryandagentconfigurationshallprovidethefollowinginterfaces:

Table 10 Interfaces provided by Semantic discovery and dynamic configuration agent platform


DataExchanged

Semanticdiscoveryservice


Request/Response Discoveryquery,IoTObjectsdescriptions(TEDs)

RegistryService VICINITYNeighbourhoodManager

Request/Response IoTObjectmeta-data,IoTObjectdescription(TD)


VICINITYGatewayAPIServicesshallprovidefollowinginterfaces:

Table 11 Interfaces provided by VICINITY Gateway API Services


TheVICINITYCommunicationservershallprovidefollowinginterfaces:

Table 12 Interface provided by VICINITY Communication Server

NameofInterface Usedby Integrationpattern DataExchanged

Discoveryservice VICINITYGatewayAPI

Request/Response Discoveryquery,VirtualIoTObjectsdescriptions(VTEDs)


Discoveryservice VICINITYCommunicationserver

Request/Response Discoveryquery,VirtualIoTobjectsdescriptions(VTEDs)


Public


VICINITYNodeConfigurationService


MessageDelivery VICINITYNodeConfiguration

RegistryService VICINITYCommunicationNode

MessageDelivery IoTObjectmeta-data,VICINITYNodeauto-configurations

VICINITYNode

TheVICINITYNodeencompassesfollowingcomponents:

• VICINITYCommunicationNode;• VICINITYGatewayAPI;• VICINITYAgent/Adapter.


TheVICINITYCommunicationNodeshallprovidethefollowinginterfaces:

Table 13 Interface provided by VICINITY Communication Node


DataforwardingAPI VICINITYGatewayAPI MessageDelivery Userdata



MessageDelivery VICINITYNodeConfiguration

RegistryService VICINITYCommunicationServer

MessageDelivery IoTObjectmeta-data,VICINITYNodeauto-configurations

DataforwardingP2P VICINITYCommunicationNode

MessageDelivery Userdata

VICINITYGatewayAPI

TheVICINITYGatewayAPIshallprovidethefollowinginterfaces:

Table 14 Interface provided by VICINITY Gateway API


Discoveryandqueryservice

VICINITYAgent/Adapter Request/Response Discoveryquery,VirtualIoTObjectsdescriptions(VTEDs)

Consumingservice VICINITYAgent/Adapter Request/Response Userdata


VICINITYAgent/Adapter MessageDelivery VICINITYNodeConfiguration


Public


RegistryService VICINITYAgent/Adapter MessageDelivery IoTObjectmeta-data,VICINITYNodeauto-configurations


TheVICINITYAdapter/Agentshallprovidethefollowinginterfaces:

Table 15 Interface provided by VICINITY Agent/ Adapter



VICINITYGatewayAPI MessageDelivery VICINITYConfigurationmessages

Exposingservice VICINITYGatewayAPI Request/Response Userdata


Public

DeploymentviewAs described in architecture concept section 2, the VICINITY is broken down into two mainarchitecturecomponentsVICINITYCloudandVICINITYNode.TheVICINITYCloudandVICINITYNodeinstances (One VICINITY Node instance per integrated infrastructure and Value-added serviceplatform)areconnectedtobuilddistributedVICINITYP2Pnetwork.

TheVICINITYP2Pnetwork is in linewithgeographicaldistributionof integrated IoT infrastructuresandvalueaddedserviceplatform.Thus,VICINITYP2Pnetworkby itsnatureenablesdistributionofdataexchangeandcomputationloadaccordingtocurrentneedsofintegratedinfrastructures.

Moreover, loosely coupledVICINITYP2Pnetworkpromotes localisationof the single failureof theVICINITYNodeorVICINITYCloud.

VICINITYdeploymentofVICINITYCloud

Figure 30 VICINITY Cloud deployment strategy

TheVICINITYCloudencompassesof four scalablecomponentsdeployedonplatformenablinghighavailability.Thehighavailabilityplatformshallprovidefeaturestomanagelife-cycleoftheVICINITYCloudcomponentsonthelevelof“virtualizedoperatingservice”.

VICINITY-ARCH-DEP010 VICINITYCloudcomponentsscalability

VICINITY Cloud components (including subcomponents and underlying technology) shall supporthorizontal (scale in/out) and vertical (scale up/down) scaling independently in each layer such asuser,service(includingintegrationservices)anddata.


VICINITY-NFUNC-AVL010, VICINITY-NFUNC-AVL020, VICINITY-NFUNC-PER010, VICINITY-NFUNC-PER020

Scalein/outorhorizontalscalingenablestoexecuteseveralinstancesofthesamecomponent(oritssubcomponents). Number of executed instances can be adjusted to serve necessary amount ofexecution requests. Components need to support load-balancing of their interfaces to othercomponentsoruserstransparently.


Public

Scaleup/downorverticalscalingenablesoptimizetheusageofhighavailabilityplatformresources(suchasCPU,Memory,Storagespace)assignedtoinstancesofcomponents.

DetaileddeploymentstrategyofeachVICINITYCloudcomponentispartoftheirdetaileddesign.

VICINITY-ARCH-DEP020 VICINITYCloudcomponents’deploymentindependence

VICINITY Cloud components’ detailed deployment designs shall not influence of designs of otherVICINITYCloudcomponents.

AnyVICINITYCloudcomponentdeploymentshallnotinfluenceofdeploymentofothercomponents.


VICINITY-NFUNC-AVL020

VICINITYdeploymentofVICINITYNodeTo enable communication between IoT devices via the VICINITY P2P Network, the VICINITY Nodeneedstoactasa“gateway”.Thus,itneedsto“translate”nativecommunicationandsemanticsofitsattacheddevicesintoVICINITYontologyandexposeitviatheVICINITYGatewayAPItootherVICINITYNodesthroughtheVICINITYP2Pnetwork.

Figure 31 VICINITY Node deployment strategy

VICINITYNodes is the“virtual” componenthostedon theGatewayHWorSWHostplatform.Eachcomponent of VICINITY Node such as VICINITY Agent, VICINITY Gateway API and VICINITYCommunicationNodeactsasindependentlooselycoupleddeployableunit.

VICINITY-ARCH-DEP030 VICINITYNodecomponentsflexibledeployment

VICINITY Node components shall support loosely coupling enabling flexible deployment setupaccordingtohostplatformabilities.



Public

VICINITY-NFUNC-MNT007,VICINITY-NFUNC-MNT020

ComponentsmonitoringVICINITY-ARCH-DEP040 VICINITYcomponents’deploymentmonitoring

VICINITY components shall provide means to support standard protocols for monitoring ofresourcesandendpointsandservices(suchasJMX,SNMP,etc.).

AnyVICINITYcomponentdeploymentshallnotinfluenceofdeploymentsofothercomponents.


VICINITY-NFUNC-MNT010


Public

DetailarchitecturedesignofVICINITYcomponents


Purpose

The goal of VICINITY Neighbourhood Manager is to provide user interface for VICINITY Users tomanagevirtualneighbourhoodandinteroperabilityasservice.

Functions

TheVICINITYNeighbourhoodmanagershallhavethefollowingcomponents:

• User interface providing searching and virtual neighbourhood management includingVICINITYNodeconfiguration;

• VirtualNeighbourhoodmanagerprovidinginternalservicessuchas:o Socialnetworkmanagementincludingsharingaccessrulessetup;o VICINITYNodeconfigurationupdateservices;o Usernotificationservices.

• Authentication and authorization module shall authenticate users and technical usersincludingVICINITYcomponents;

• IntegrationmoduleshallsupportintegrationtootherVICINITYcomponentssuchasVICINITYCommunication Server, Gateway API Services and Semantic discovery & dynamicconfigurationagentplatform;

• Router component for management of communication within VICINITY Neighbourhoodmanagement;

• Storagesfor:o Userauthenticationandauthorization,o Globalneighbourhoodstorage,o Consentandtermsofconditionstorage,o Auditingstorage.

Figure 32 Component diagram of VICINITY Neighbourhood Manager VICINITY-ARCH-DD-010 VICINITYNeighbourhoodmanagerfunctions

TheVICINITYNeighbourhoodManagershallsupportVICINITYUserthroughuserinterfaceto:

• tosearchforIoTobjects,users,organizationsthrough;• tomanagesocialnetworkoforganizationsandIoTobjects;


Public

VICINITY-ARCH-DD-010 VICINITYNeighbourhoodmanagerfunctions

• tomanagesharingaccessrules;• toconfigureVICINITYNodes;• tomanageconsentsandtermsofconditions;• tomanageusersandorganizations;• toprocessusernotifications;• tostoreuserauditing;• toauthenticateandauthorizeusers.


VICINITY-NFUNC-SEC060, VICINITY-NFUNC-SEC070, VICINITY-NFUNC-PRV020, VICINITY-NFUNC-PRV030,VICINITY-NFUNC-PRV040,VICINITY-FUNC-UCR010,VICINITY-FUNC-UCR020,VICINITY-FUNC-UCR030, VICINITY-FUNC-UCR040, VICINITY-FUNC-UCR050, VICINITY-FUNC-UCR060, VICINITY-FUNC-UCR070, VICINITY-FUNC-UCR090, VICINITY-FUNC-UCR100, VICINITY-FUNC-UCR110, VICINITY-FUNC-UCR130, VICINITY-FUNC-UCR140, VICINITY-FUNC-UCR150, VICINITY-FUNC-UCR160, VICINITY-FUNC-UCR165,VICINITY-FUNC-UCR170,VICINITY-FUNC-UCR190

Dependencies

The VICINITY Neighbourhood manager has the following dependencies to other VICINITY Corecomponents:

• Semanticdiscovery&dynamicconfigurationagentplatform;• GatewayAPIServices;• VICINITYCommunicationServer;

Interfaces

InterfacesofVICINITYNeighbourhoodmanagerareidentifiedanddescribedinsections6.1.1.

VICINITY-ARCH-DD-020 VICINITYNeighbourhoodManagerUserInterfaceperformance

VICINITY NeighbourhoodManager shall provide user interface response time up to 5s in routineoperationssuchas:authentication,simplesearch,listofIoTobjects,exploringownneighbourhood.


VICINITY-FUNC-UCR180,VICINITY-NFUNC-PER010

Resources

TheVICINITYNeighbourhoodmanagermanagesfollowingresources:

• Userauthenticationandauthorization,• Globalneighbourhoodstorage,• Consentandtermsofconditionstorage,• Auditingstorage.

VICINITY-ARCH-DD-030 VICINITYNeighbourhoodManagerStorageperformance

VICINITYNeighbourhoodManagershallprovidemeanstorecoverofthefollowingstoragesincase


Public

VICINITY-ARCH-DD-030 VICINITYNeighbourhoodManagerStorageperformance

ofcomponentfailure:

• Userauthenticationandauthorizationstorage;• Globalneighbourhoodstorage;• Consentandtermsofconditionstorage;• Auditingstorage.



Data

ThedatamanagedbyVICINITYNeighbourhoodmanageraredescribedin4.3.1.

VICINITYCommunicationServerandNode

Purpose

TheobjectiveoftheVICINITYCommunicationserverandNode:

• Setupcommunicationchannels;• DataforwardingbetweenpeersinP2Pnetwork;• ProvidingVICINITYsecurityservicesincludingend-to-endencryptionanddeviceverification.

Functions

The VICINITY Communication Server and VICINITYNode are surrounding components for VICINITYP2Pnetwork.Thesecomponentscanbebrokeninthefollowingfunctionalblocks.

VICINITY-ARCH-DD-040 VICINITYCommunicationServerfunctionalblocks

TheVICINITYCommunicationServershallconsistofthefollowingfunctionalblocks:

• Transaction Module – support communication to Discovery services, Registry andConfiguration service to Gateway API, Gateway API Services and Virtual NeighbourhoodManagementitconsistsofthreecomponents:

o Discovery processor as simple discovery of things service forwarder betweenGatewayAPIandGatewayAPIService;

o VICINITYConfigurationprocessorasconfigurationsplittertoVICINITYNode;o RegistrationprocessorasvalidatorofIoTobjectregistrationservices.

• P2P Network Manager – manages the P2P peer network including in P2P networkauthenticationandglobalwhite/blacklistmanagement;

• P2PNetworkServerEndpoint–messagebrokerfortheP2PNetwork;• Configurationstorage.




Public

VICINITY-ARCH-DD-040 VICINITYCommunicationNodefunctionalblocks

TheVICINITYCommunicationNodeshallconsistofthefollowingfunctionalblocks:

• P2PNetworkEndpoint asmessagebroker for theP2PNetwork transmittingP2PNetworkMessagesincludinglocalwhiteandblacklistofpeers;

• AuthorizationServicesfilteringoutunauthorizedmessagesfromP2PNetwork;• EncryptionServicesperformingencryptionordecryptionofthemessages;• MessageRouterperforminginnerVICINITYNodeRoutingofthemessages;• GatewayAPIEndpointtranslatesGatewayAPIrequestandresponsesto/fromP2PNetwork

messagesandprovidesprivacyfiltering(seefollowingnote);• NodeConfigurationstoresallVICINTIYCommunicationNoderelatedconfiguration.


VICINITY-FUNC-UCR145Notethat,privacy filterservice filtersoutunnecessaryuserdata fromchangedmessagesbasedonIoT object interface description, to ensure that only requested data are transmitted. Softwareintegratorsusuallyprovidemoregenericuserdataservicesthannecessarytosimplifyinterfacesandimplementation,whichmightresultinprivacyissues.Privacyfiltersimpleerasesanyuserdatawhichshouldnotbetransmittedforselecteduserdataformats(suchasJSONorXML).

Figure 33 Functional blocks of VICINITY Communication Server and Node

VICINITY-ARCH-DD-040 VICINITYP2Pnetworksecurity

VICINITY shall support following security services on VICINITY Communication Node based onconfigurationandserviceavailabilityontheIoTobjects:

• P2PmessagepayloadencryptionsanddecryptionsbasedonIoTobjectdescriptions;• AuthorizationchecksofP2Pmessagesbasedonsharingaccessrules.



Public

VICINITY-NFUNC-SEC020

VICINITY-ARCH-DD-050 VICINITYP2Pnetworkprotection

VICINITYshallprovidemeanstosupportprotectionofVICINITYP2Pagainst:

• MessagefloodingincaseofVICINITYCommunicationNodereconnectionintoP2Pnetwork;• VICINITYCommunicationNodemessagefloodinginVICINITYP2PNetwork.

VICINITY Communication Node shall support to block or unblock other VICINITY CommunicationNodes.


VICINITY-NFUNC-SEC020,VICINITY-NFUNC-SEC030

VICINITY-ARCH-DD-060 VICINITYP2Pnetworkperformance

VICINITY P2P Network shall support near to real-time VICINITY P2P message delivery betweenVICINITYCommunicationNodes.

VICINITYP2PNetworkshallprovidemeanstosupportprioritizationoftheP2Pmessages.


VICINITY-NFUNC-MNT020, VICINITY-NFUNC-PER010, VICINITY-NFUNC-PER020, VICINITY-NFUNC-PER030

NotethatVICINITYCommunicationServerandNodeprovidingandconsuminginterfacesin-linewithintegrationview(6.1.1.3,6.1.2.1).

Dependencies

TheVICINITYCommunicationServerdependson:

• VICINITYNeighbourhoodmanager;• VICINITYGatewayAPIServices;• Semanticdiscovery&dynamicconfigurationplatform.

TheVICINITYCommunicationNode:

• VICINITYNeighbourhoodmanager;• VICINITYCommunicationServer.

Interfaces

InterfacesofVICINITYCommunicationServerandVICINITYCommunicationNodeare identifiedanddescribedinsections6.16.1.1.3and6.1.2.1.


Public

Resources

TheVICINITYCommunicationServerandNodemanagesfollowingresources:

• StorageofIoTobjectdescriptions;• StorageofIoTobjectsharingrules;• StorageofVICINITYCommunicationServerandNodeconfiguration;

VICINITY-ARCH-DD-070 VICINITYCommunicationServerandNodestorageperformance

VICINITYCommunicationServerandNodeshallprovidemeanstorecoverofthefollowingstoragesincaseofcomponentfailure:

• StorageofIoTobjectdescriptions;• StorageofIoTobjectsharingrules;• StorageofVICINITYCommunicationServerandNodeconfiguration.


VICINITY-NFUNC-PER040

Data

TheVICINITYCommunicationServermaintainsfollowinginformation:

• VICINITYConfigurationsplittingrules;• P2PNetworkServerEndpointconfiguration• P2PNetworkconfiguration;• RegistryandDiscoveryofThingsserviceconfiguration;

TheVICINITYCommunicationNodemaintainsfollowinginformation:

• IoTobjectdescriptions(TDs)includingencryptionservicesconfiguration(4.3.2);• Setofsharingaccessentriesforauthorizationservices(4.3.1.2);• GatewayAPIendpointconfiguration;• VICINITYCommunicationNodecredentials;• Messagerouterconfiguration;• P2PNetworkendpointconfiguration;

VICINITY-ARCH-DD-080 VICINITYP2Pnetworkmessages

VICINITYP2PnetworkmessagestransmittedinP2Pnetworkshallinclude:

• Messageidentitycontext;• Sourceofmessage;• Destinationofmessage;• Messageidentifier;• Messagetype;• Messagecontents;• Dataintegrityattributes.


Public


VICINITY-FUNC-UCR145,VICINITY-NFUNC-SEC040

VICINITY-ARCH-DD-090 VICINITYCommunicationNodedataavailability

VICINITY Communication Node shall support serialization of exchanged messages (VICINITY P2PNetworkandGatewayAPImessages)includingabilitytorecoveryfromfailurebehaviour.



Semanticdiscovery&dynamicconfigurationagentplatform(IS)

Purpose

GeneralpurposeofthiscomponentistoprovidethesemanticinteroperabilitywhenhandlingtheIoTobjects.Therearefollowingmainpurposesofthiscomponent:

• toperformsemanticdiscoveryofIoTobjects;• toperformdynamicconfigurationofagents;• tostoresemanticinformationandtoprovidesearch/lookupservicesforIoTobjects;• tomanagealistofexternalIoTdescriptorrepositories.

Function

ThecoreofautomaticsemanticdiscoveryanddynamicagentconfigurationistheprocessofmappingofphysicalIoTobjectintoitssemanticrepresentation.Eachtime,thenewIoTobjectis introduced,discoveryplatformwillmatchthesemantictemplatecorrespondingtothisobject(e.g.specificdevicemodel) and create the new unique instance with persistent identifier shared across VICINITYplatform. The new instance (the semantic description - TED) will be mapped to the physical IoTobjectandwillbeusedas its semantic representation.Semanticsearchwillbe thenperformedonsemantic representationsof IoTobjectsandmatching instanceswillbe returned togetherwith themapping to corresponding physical IoT devices and their location (identifier of VICINITY noderesponsible for interaction with IoT object). The process of semantic discovery and configurationenables to automatically introduce the set of IoT objects for corresponding VICINITY node. ThisconfigurationcanbefurthermanuallyupdatedviaNeighbourhoodmanager.Once,theconfigurationischanged, it isupdatedandsharedwithcorrespondingVICINITYagent,responsiblefor interactionwiththisIoTobject.

VICINITY-ARCH-DD-100 Discoveryrelatedfunctionality

• RegistrationdiscoveryofIoTobjects:automaticandbyrequest;• UpdateofIoTobjectsandagentconfiguration(enable/disableIoTobject,enable/disableIoT

objectservice/action,etc.);• AutomaticcreationofIoTobjectmodeltemplatesfromspecifiedexternalrepositoriesofIoT

objectdescriptors.




Public

VICINITY-ARCH-DD-110 Handlingsemanticmodels

• providingcommonsemanticvocabularytodescribeIoTobjects;• performingCRUDoperationsonIoTobjectmodelsandagentconfiguration;• executingsemanticqueriesandlook-ups;• serialization of semantic information into common machine-readable format (e.g. JSON,

XML).



Dependencies

Based on architectural design, this component interacts only with the Neighbourhood manager.Generally, any VICINITY component (mainly the Node Gateway API), may request the semanticinformationviaGatewayAPIServicesandNeighbourhoodmanager.

Interfaces

VICINITY-ARCH-DD-120 DiscoveryAPI

• Discovery request: given list of IoT object meta-data from VICINITY agent, semanticdiscoveryplatformwillcreatesemanticmodelsofcorrespondingIoTobjects,mapthemtophysicalIoTobjectsandstoreinrepository.TheresultofthisprocessisthecreationofTEDsforprovidedIoTobjectmeta-data.

• Get TEDs – IoT object instances: given list of IoT object identifiers, semantic discoveryplatformwillreturnthesemanticinstancesofcorrespondingIoTobjects.

• GetAgentConfiguration:returnstheactualconfigurationofrequestedagent;

• SetAgentConfiguration:updatestheactualconfigurationforrequestedagent;



VICINITY-ARCH-DD-130 QueryAPI

• Execute Query: performs the semantic search by executing the query and returns thematches;



Resources

Semanticdiscovery&dynamicconfigurationagentplatformshallmanagethefollowingresource:


Public

• semantic repositorywhich is populated in advancewith semanticmeta-data– thedomainontologiesandIoTobjecttemplates,whichareusedasthebasisforsemanticdiscovery.

Semantic repository is a semantic storage and reasoner used for manipulation and querying thesemanticdata.

Semanticrepositoryisimplementedashigh-performancesemanticstoragesavailabletoscaleuptobillions of statements. These storages are optimized to execute semantic queries andmanipulatedatainreal-timeresponsescomparabletoperformanceofcommonSQLdatabases.

VICINITY-ARCH-DD-140 Semanticrepositoryperformance

Semanticdiscovery&dynamicconfigurationagentplatformshallsupporthigh-performancesearchand CRUD operation on semantic data to support performance requirements of componentsaccessingsemanticrepository.



Data

IoT object models are described in more details in section 4.5.2 Semantic Model and AgentConfigurationStorage.

VICINITYGatewayAPI

Purpose

ThegoaloftheVICINITYGatewayAPIistoenablesemanticinteroperabilitywithinVICINITYNodessothattheycaneasilyexposetheirownIoTobjects,aswellasdiscoverandinteractwithanyIoTobjectknowntoVICINITYwithintheirVICINITYNeighbourhood.

Functions

MostfunctionsoftheVICINITYGatewayAPIcanbedirectlyinvokedthroughitsavailableinterfaces.However,tosupport incomingP2Pcommunications,thereareadditionalrelatedfunctionsthatareindirectly triggered by a message-queue consumption mechanism provided by the VICINITYCommunicationNodeinterface,e.g.receivingamessagethatrequeststogetthepropertyvalueofanexposedIoTobject.

ForallthosefunctionslistedbelowthatinvolveinteractionwithanIoTobject,itisassumedthattheyareinscopeofVICINITYNode’sneighbourhood.

VICINITY-ARCH-DD-150 VICINITYGatewayAPIfunctions

TheVICINITYGatewayAPIshallsupportthefollowingfunctionsto:

• RequestauthenticationinVICINITY;• RegisterasVICINITYGatewayAPI;• Register/ExposenewIoTobjectstoVICINITYAgent/Adapter;• DiscoverIoTobjectsthatmatcharequiredsearchpattern;


Public

• GetthecurrentvalueofaspecificpropertyofanIoTobject;• SetthevalueofaspecificpropertyofanIoTobject;• PerformaspecificactiononanIoTobject;• Getthestatusofon-goingspecificactionsonanIoTobject;• Subscribe/Unsubscribe/ListentoeventsissuedbyanIoTobject;• Getthe listofavailable interactionpatterns (i.e.,properties,actionsandevents)ofan IoT

objectalongwitheachvalueconstraintsandunits;• GetthevalueofaspecificpropertyofanexposedIoTobject;• SetthevalueofaspecificpropertyofanexposedIoTobject;• PerformaspecificactiononanexposedIoTobject;• Getthestatusofon-goingspecificactionsonanexposedIoTobject;• Subscribe/Unsubscribe/ListentoeventsissuedbyexposedIoTobject;• ProcessconfigurationupdatesofexposedIoTobjectsfromVICINITYCloud;• Query the VICINITY P2P Network by means of a combination of discovery and access

functions,byusingSPARQL9andtheVICINITYOntology.


VICINITY-NFUNC-PRV040,VICINITY-FUNC-UCR145

Interfaces

Tosupport functions listed insection8.4.2, theVICINITYGatewayAPIshallbedivided intospecificgroupsofsub-interfacesforRegistry,Discovery,ConsumptionandQuerying.

AllinterfaceswillrequireworkingunderanauthenticationcontextwithVICINITY.

VICINITY-ARCH-DD-160 VICINITYGatewayAPIforRegistry

TheRegistryinterfaceshallsupportregistrationofIoTobjectswithinaNodeintwoways:

• AggregatedregistrationofasetofIoTobjects;• IndividualregistrationofeachIoTobject.

Supportedfunctions:

• RegisterasVICINITYNode;• Register/ExposenewIoTobjects.



IndividualregistrationscanhappenatanytimeaftertheNodeissuccessfullyregisteredinVICINITY;itsupportsautomaticdiscoveryanddynamicintegrationofIoTobjectsinthenetwork.

When it comes to invoke a registration, the Registry interface expects to receive IoT objectdescriptionsrepresentedinthecommonVICINITYformat(seesection8.5.6).Internally,theGateway

9https://www.w3.org/TR/sparql11-query/


Public

APIshallvalidatethereceiveddescriptionsagainsttheschemabeforesendingitasamessagetotheVICINITYCloud(thoughtheP2PNetwork).

Once the described process is successfully completed, the Gateway API gets prepared toasynchronously receive feedback from the VICINITY Cloud (Semantic discovery & dynamicconfiguration agent platform, see section 8.3) in the form of enriched versions of such semanticdescriptions (TED). SuchTEDwill provide theGatewayAPI a better knowledgeabout its underlinginfrastructureofIoTobjects.

VICINITY-ARCH-DD-170 VICINITYGatewayAPIforDiscovery

TheDiscovery interfacewill allow todiscover those IoTobjects thatmatcha fixed searchpatternwithinVICINITYNeighbourhood.Thesearchpattern(alignedtothecommonVICINITYformatforIoTobjectdescriptions)shallatleastsupportthefollowingcriteria:

• TypeofIoTobject;• RegardingIoTobjectproperties,

o Type;o Dataformat;o Units.

• RegardingIoTobjectactions,o Type;

• RegardingIoTobjectevents,o Type;o Throughput.

InordertosupportmoreexpressivesearchpatternsandtakeadvantageoftheVICINITYOntology,theDiscoveryinterfaceshalloptionallysupportconstrainedSPARQLqueriesfordiscoveryrequests.

Supportedfunctions:

• DiscoverIoTobjectsthatmatcharequiredsearchpattern.



Oncethesearchcriteriaarevalidated,thediscoveryprocessshallcontinueasfollows:

1. Generate thecorrespondingSPARQLquery (using theVICINITYOntology) tobesent to theVICINITYGatewayAPIServiceswithintheVICINITYCloud.

2. Wait until a response is received. The result shall be a VTED (Virtual Things EcosystemDescription)thatcontainsthesetofTDsofthespecificIoTobjectsthatmatchtheprovidedsearchcriteria.

3. TransformallTDsintothecommonVICINITYformat(seesection8.5.6).

TheresponsesprovidedbyDiscoveryinterfacewillconsistofasetoftuples(builtfromoutputofstep3 of the discovery process) which identify the matching IoT objects by specifying identifiers andrelevant meta-data so that they can be addressable afterwards, e.g., the Node, IoT object andpropertyIDs.


Public

VICINITY-ARCH-DD-180 VICINITYGatewayAPIforConsumption

TheConsumptioninterfaceoftheGatewayAPIaimsat:

• Providing access methods to IoT objects that belong to integrated infrastructures withinVICINITYNeighbourhood.

Theaccessoperationsofferedbythisinterfacetakesatupleofidentifiersasinput,e.g.oneoftheresultsprovidedbyaDiscoveryoperation,whichshallserveaspointertoaspecific IoTobjectandeventooneofitsproperties,actionsorevents.

Supportedfunctions:

• GetthecurrentvalueofaspecificpropertyofanIoTobject;• SetthevalueofaspecificpropertyofanIoTobject;• PerformaspecificactiononanIoTobject;• Getthestatusofon-goingspecificactionsonanIoTobject;• Subscribe/Unsubscribe/ListentoeventsissuedbyanIoTobject;• Getthe listofavailable interactionpatterns (i.e.,properties,actionsandevents)ofan IoT

objectalongwitheachvalueconstraintsandunits.



TheGatewayAPI it leverages theVICINITY P2PNetwork as a distributed transportmechanism forrequestingandreceivinguserdatafromtherelevantandaddressableVICINITYNode.

Onceatupleofidentifiersisprovided,thefollowingConsumptionprocesstakesplace:

1. RequestaVTED (Virtual ThingsEcosystemDescription) to theVICINITYCloud (if itwasnotalreadycached intheGatewayAPI) thatstrictly,semanticallyandcompletelydescribesthereferencedIoTobject.ThisVTEDshouldcontaineverythingthatVICINITYknowssofaraboutsuchIoTobject.

2. QuerytheVTEDto:o IdentifytheVICINITYNodethatprovidessecureaccesstothereferencedIoTobject;o Extract specific security and privacy constraints and any further meta-data that is

requiredtoestablishcommunicationproperly.3. Prepare, serializeandsendamessage to theVICINITYCommunicationNode.Thismessage

must unequivocally describe the intended operation plus the identifiers that address theinteraction resource of the IoT object to be consumed. Due to P2P communications areasynchronous,therequestwillbegivenauniqueidentifiersothatitsexpectedresponsecanbecorrectlyidentified.

As a response is received through the VICINITY Communication Node, it is de-serialized andprocessed to extract the corresponding result of the operation.When such result encapsulates avaluethatmayrequiresometransformation,e.g.,unitconversion,theGatewayAPIshalloptionallyperformitjustbeforereturningtheresult.

From the recipientGatewayAPI point of view, at the time a consumption request is received thefollowingprocessistriggered:

1. Query the TED that describes the underlying IoT infrastructure (see Registry interface) todetermine which are the required endpoints that need to be invoked to satisfy the


Public

consumptionrequest.Suchqueryshallconsidertheidentifiersprovidedintherequestthatrefersto:

o SpecificIoTobject;o Specificinteraction(property,actionorevent);o Requiredoperation(get,set,subscribe,etc.).

2. Invoke the extracted endpoints (that should be offered by the correspondingAgent/Adapter).

3. Once all endpoints’ responses are gathered, the Gateway API shall process, unify andserializetheminauniquemessageasresponsetotherequester.

VICINITY-ARCH-DD-190 VICINITYGatewayAPIforQuerying

ThegoaloftheQueryinginterfaceisto:

• Provide full support toSPARQLquerieswhose intention isnotonly todiscover things butalsotoaccessandconsumetheirdatainone-stepinteraction;

• BecomeastandardSPARQLendpointforconsumingVICINITYIoTobjects.TheinterfaceshallimplementtheSPARQL1.1Protocol10.

Supportedfunctions:

• Query the VICINITY P2P Network by means of a combination of discovery and accessfunctions,byusingSPARQLandtheVICINITYOntology.



Therefore,givenaSPARQLquery,theclientsofthisinterfacewillrelyontheGatewayAPItodothefollowing:

1. Discover those IoT objects that are relevant for the given query. This process shall besupportedby theVICINITYGatewayAPI Services (see section6.6), concretely forprovidingtheVTED(VirtualThingsEcosystem)thatfullydescribetheinvolvedthings.

2. Createaqueryplanthatdescribeswhattocollectandwherefromaswellashowthequeryshallbeevaluated(steps3and4).

3. Collect all relevant information from the IoT objects by establishing communication withtheircorrespondingVICINITYNodes(asexplainedintheConsumptioninterfacetable).

4. Evaluate the query against the collected triples (RDF graph) and generate the existingsolutions.

Resources

TheGatewayAPIshallmakeuseofagraphdatabase(triplestore)forstoringandcachingdifferentsemanticdata.

10https://www.w3.org/TR/sparql11-protocol/


Public

VICINITY-ARCH-DD-200 VICINITYGatewayAPIperformance

VICINITYGatewayAPIshallprovidemeanstosupportcachingoftheexchangeduserdata.

Consideredrequirements:VICINITY-NFUNC-PER050

Data

AllthedifferentinteractionsandprocessesthattakeplacewithinVICINITYGatewayAPIwillinvolvetheusageoftwodifferentkindsofdata:syntacticandsemantic.

Syntactic data refers to the datawhich theGateway APIwill exchangewith its surroundingNodecomponents; simple schema-based information that is not semantically described, thus allowingthesedataexchangestobeagnosticofsemanticsdefinedintheVICINITYOntology.

• Syntacticdatao IoTobjectdescriptionsinVICINITYcommonformat(seesection6.5);o VICINITYP2Pnetworkmessages(seesection6.2.2).

SemanticdatarepresentsalldatathatisdescribedusingtheVICINITYOntology.

• Semanticdatao ThingDescriptions(TD)ofIoTobjects;o ThingsEcosystemDescription(TED)oftheunderlyingIoTinfrastructure;o VirtualTEDfordiscoveryprocessesandqueryingrequests.


Purpose

ThemaingoalofVICINITYAgentistoprovideaccesstoIoTobjectsofunderlyinginfrastructure(e.g.specificmiddleware)orvalue-addedservicesinuniformway.

Function

Themain functionalityofVICINITYAgent is to integrateexisting solution,whichprovidesaccess toIoT objects (specific middleware, application, value-added services), into VICINITY. The role ofVICINITYAgentistomapallIoTobjectsavailableviaunderlyinginfrastructureintocommonVICINITYform,toenableuniformaccesstoallintegratedinfrastructures.

ThemostimportantpartofVICINITYAgentistheVICINITYAdaptersubcomponent.Adapterservesasthe proxy between common VICINITY services and underlying infrastructure. For each specificinfrastructuretobeintegrated,theremustexistspecificVICINITYAdapter.TheroleofAdapteristotranslate VICINITY services into infrastructure specific services. VICINITY Adapter provides the API,whichmustbeimplemented,whenintegratingnewinfrastructure.


Public

VICINITY-ARCH-DD-210 Adapterfunctionality

Adaptermustbeableto:

• ReaddescriptionsofincludedIoTobjectsandtranslateitintocommonVICINITYformat.Acquireddescriptorsareusedforautomaticdiscovery,creatingcorrespondingsemanticmodelsof IoTobjectsandmappingbetweensemanticmodelsandphysical IoTobjectsininfrastructure.

• Interact with specific IoT objects in infrastructure: read/write data from specific IoTobjectserviceorperformactions.



VICINITY-ARCH-DD-220 Agentfunctionality

TheVICINITYAgent is the logical componentusingassignedAdapter toperformVICINITYservicesforinteractionwithunderlyingIoTobjects.ThemainfunctionalitiesofVICINITYAgentare:

• TodiscoverandregisterIoTobjectsinunderlyingarchitecture:AllavailabledescriptionsofIoTobjectsaremappedintoVICINITYsemanticrepresentation.IoTobjectsdiscoverycan be performed by request, by it can be performed also automatically, when theVICINITYnodeisfirsttimeintroducedintoplatform;

• To interact with IoT objects: Given identifier of IoT objects and its service, theread/writedataoperations canbeperformedbyprocessingget/setproperty,executeactionorreadeventservices.Dataservicesmaybefurtherparametrized, forexamplebyaddingtimeinterval,orderingandnumberofresultsrequest;

• TosimulatesupportedtypeofIoTobjectsfromneighbourhoodinunderlyingintegratedinfrastructure;

• ToactualizeAgentconfigurationupdatedviaNeighbourhoodmanager.



Dependencies

Basedonarchitecturaldesign,thiscomponentinteractsonlywiththeGatewayAPI.

Interfaces

ExecutionofallinterfaceservicesalwaysconsiderstheactualconfigurationofAgent.

VICINITY-ARCH-DD-230 AdapterAPI

• ExposeIoTobjects:returnsthelistofavailableIoTobjectmeta-data(tobediscovered)incommonVICINITYformat.

• ExecuteRequest:givenidentifierofIoTobjectanditsservice(optionallywithadditionalparameters),thecorrespondingserviceofunderlyinginfrastructureisexecutedandresultsarereturned.TheVICINITYget/setproperty,performactionorreadeventservicesaretranslatedinfoformofunderlyinginfrastructure.


Public



VICINITY-ARCH-DD-240 AgentAPI

• DiscoveryRequest:allIoTobjectsinunderlyinginfrastructurearepassedintosemanticdiscoverycomponentandregistration/discoveryisperformed

• Get/Setproperty,performaction,readevent:IoTobjectinteractionservices• Updateconfiguration:theconfigurationisupdated



Resources

VICINITYAgentandAdapteroperateabovetheexistinginfrastructureofIoTobjects.

Data

• IoTobjectdescriptions inVICINITYcommonformatprovidedbyAdapter:used indiscoveryandregistrationprocess;

• TheresultofIoTobjectinteractions:readdataresultsoroperationsuccess,bothprovidedincommonVICINITYformat;


Purpose

ThegoaloftheVICINITYGatewayAPIServicesistosupportdiscoveryinVICINITY,beingtheVICINITYCloudentrypointfortheP2PNetworkthattreatsallincomingdiscoveryrequests.

Functions

All functionsdescribedbelowshall onlybe invoked through theVICINITYP2PNetwork. Thus, theywillonlyworkforauthenticatedVICINITYNodesinasecurecommunicationcontext.

VICINITY-ARCH-DD-250 VICINITYGatewayAPIServices’functions

TheVICINITYGatewayAPIServicesshallsupportthefollowingfunctionsto:

• Generatesemanticdescriptionsofthings’ecosystems(VirtualThingsEcosystemDescription-VTED)thatarerelevantfordiscoveryrequests;

• Generatediscoveryandconsumptionplans (queryplans) forqueries issued fromVICINITYNodes.




Public

Dependencies

In order to correctly perform its task, the Gateway API Services shall only require the VICINITYNeighbourhood Manager to be available. The VNM will be required to discover relevant andaccessible(withinNeighbourhood)IoTobjectsforbothdiscoveryandqueryingrequests.

Interfaces

TheVICINITYGatewayAPIServicesshalldefineadedicatedinterfacepereachfunctiondescribedinsection6.6.2,namelytheDiscoveryandQueryinginterfaces.

VICINITY-ARCH-DD-260 VICINITYGatewayAPIServicesforDiscovery

TheDiscoveryinterfacewillhaveaveryconcretepurpose:toprovidetheVTEDthatdescribessofar,thesetofthingsthatmatchesasearchcriteriagivenintheformofaconstrainedSPARQLquery.TheGatewayAPIswillbetheactualclientsofthisinterface,thusresponsibleforcreatingandissuingthecorrespondingquery(seesection6.4.3).

ThesupportedSPARQLqueriesarethosewhosepatternonlyreferstoconceptsandpropertiesthatareinscopeofthesemanticsofsearchpatternsdefinedinsection6.4.3,i.e.,onlyIoTobjectmeta-datawillbeinvolved.

Clients of the Discovery interface shall not be returned with the intuitive result of the queryevaluation (setof solutions as tuples), but a graph (semanticdata) thatdescribeseverything thatVICINITYknowsaboutallinvolvedIoTobjects(VTED).

Supportedfunctions:

• Generatesemanticdescriptionsofthings’ecosystems(VirtualThingsEcosystemDescription-VTED)thatarerelevantfordiscoveryrequests.



VICINITY-ARCH-DD-270 VICINITYGatewayAPIServicesforQuerying

TheQueryinginterfacecanbeconsideredasanextensionoftheDiscoveryinterface.ItspurposeistosupportSPARQLqueriesthatusestheVICINITYOntologynotonlyfordiscoverypurposesbutalsoforconsumption.

Itsmainpurpose is toreducetheworkloadofGatewayAPIs,specifically totheirqueryingprocess(seeGatewayAPIforQueryinginsection6.4.3).

Supportedfunctions:

• Generatediscoveryandconsumptionplans (queryplans) forqueries issued fromVICINITYNodes.



From theGateway APIs point of view, theywill receive a query plan thatwill prevent them fromhavingto:


Public

1. Prepare a constrained SPARQL query from the given one, just to discover the things thatmayberelevanttoobtainresults.

2. Process and analyse the result of a discovery request for such constrained SPARQL query(VTED) to identify all IoTobjects and their access configuration (address, security aspects,endpoints,etc.)

3. Finally,createaqueryplanthemselves.

Therefore, those lightweight Gateway APIs that rely on this interface shall have just to followstraightforwardlytheprovidedqueryplanforagivenSPARQLquery.

Resources

TheGatewayAPIServicesshallmakeuseofagraphdatabase (triplestore) forstoringandcachingdifferentsemanticdata.

Data

Both discovery and querying processes work with semantic data (TD, VTED) and the VICINITYOntology.


Public

QualityconsiderationsThe section deal with quality considerations in VICINITY architecture. It focuses on the followingqualityissues:

• Usability,• Reliability,• ScalabilityandPerformance,• Maintenance,• Security&Privacy.

UsabilityLocalization: user interface provided by VICINITY components (such as VICINITY NeighbourhoodManager) shall provide tools to support localization of text, navigation, date, time and currencythrough ICU (InternationalComponents forUnicode) standards. Localizedmessagesand formattedtexts shall not be integral part of VICINITY components’ source code (“hard coded”) and shall beconfigurableseparately.

Accessibility:userinterfaceprovidedbyVICINITYcomponentsshallsupportdifferenttypeofdevicessuchasdesktopscreens,laptops,tablesandsmartphonethroughuserinterfaceresponsivedesign.

User interface shall provide layer of technical services (user interface service layer) which can beusedbycurrentorfuturedevices(wearables,smartwatches,augmentedrealitydevices)andcustomapplicationtofacilitateusers’interactionwithVICINITY.

Responsiveness of user interface:user interface shall react tousers requestswithout causinganydiscomforttouser.Activitieswithlongerprocessingtimeshallprovide“progressbarorwaitingicon”forusers.Userinterfaceservicelayershallprovidestatusforlongprocesstimeactivities.

Reliability

Availability

Availability of VICINITY Cloud components provide common interoperability services for theintegrated infrastructures and value-added services deployed on high-availability platform (seeSection7).High-availabilityplatformshallsupportavailabilityonhardwarelayer(forsoftwarelayerseescalabilitysection9.3)including:

• Redundantinternetconnectionstoprotectinfrastructurefromloosingofconnectivity,• InfrastructurelayerprotectionagainstDDoSattackstoprotectservicesfromoverloading,• RAIDsupportfordatastoragestosupportprotectionagainststoragehardwarefailure,• Operating system virtualized environment to protect running components from failure of

underlyingphysical infrastructureandoptimizeavailableresources(CPU,RAMandHDDforoperatingsystems),

• Support of infrastructure load balancing to protect components from overloading ofunderlyingphysicalinfrastructure.

AvailabilityofVICINITYNodecomponentsaredeployedinintegratedinfrastructuresandthustheiravailabilityisdirectlyinfluencedbytheavailabilityofunderlyinghardwareinfrastructure.

VICINITYCloudandNodecomponentsshall respect independence fromphysical infrastructureandlifecycleofoperatingsystemmaintenance(suchasrestart,migrationwithinvirtualizedenvironment


Public

etc.).Componentsshallprovidemeanstosupporthealth-checkmechanismofitsservices’alivenessand functioning (9.4). Components shall provide means to support secure runtime upgrades ofcomponents, however VICINITY user or administrator shall be notified through user interface ifphysicalinterventionisnecessary.

Faulttolerance

Fault tolerance against VICINITY Communication Server is criticalwhile the server manages P2Pnetwork and facilitates all communications between VICINITY Cloud components and VICINITYNodes. Unavailable VICINITY Communication Server will suspend any communication betweenVICINITYNodes.VICINITYNodesandshallbeabletosecurelyreconnecttoVICINITYCommunicationServeronceavailable.WhileVICINITYCommunicationServerisunavailable:

• VICINITYNeighbourhoodmanagershallbufferanyVICINITYConfigurationchanges;• VICINITY Nodes shall buffer any P2Pmessages or refuse any request on the gateway API

interfacewithanappropriatestatuscode.

FaulttoleranceagainstVICINITYNodecomponents–failureofVICINITYNodemighthaveinfluenceon VICINITY Cloud components and another VICINITY Nodes. VICINITY Node and Communicationserver are aware of availability11of any VICINITY Node in P2P network, thus they shall decidewhether to send messages to the unavailable node. P2P messages already sent to unavailableVICINITYNodesshallbebufferedintheVICINITYCommunicationServer’sP2PNetworkmanagerforlaterdelivery.

Fault tolerance against VICINITY Neighbourhood manager – failure of VICINITY NeighbourhoodManagerresultsinunavailabilityofVICINITYUserinterfaces,i.e.itwillnotbepossibletoperformanyconfigurationchangeinvicinityneighbourhoodanddiscoveryandqueryserviceinopengatewayAPI.UserdataexchangewithinP2Pnetwork is constrainedbyunavailability toperformanychanges inexistingVICINITYConfigurationandsharingaccessrules.

Fault toleranceagainst integrated infrastructures services–assumingVICINITYNodecomponentsare alive and functioning, the node (VICINITY Agent or Adapter) shall resolve any request forinteractionwith(temporaryorpermanent)unavailableIoTobjectbyanappropriatestatuscodes.

Fault tolerance against Semantic platform – unavailability of semantic platform constraintsdiscovery and query services of VICINITY Gateway API. VICINITY Neighbourhood Manager shallresend any request to Semantic platform once available to complete IoT objects registration anddiscoverysearchrequests.WhileconfigurationofthesemanticinteroperabilityisdistributedamongVICINITY Nodes, user data exchange between nodes is constrained by missing latest updates insemanticmodelanddata.

FaulttoleranceagainstVICINITYGatewayAPIServices–unavailableVICINITYGatewayAPIServicestemporarilyconstraintsdiscoveryandqueryingservicesofVICINITYGatewayAPIonly,theseservicesshallreturnanappropriatestatuscodes.

11visibilityofVICINITYNodeavailabilityissubjectofsecurityimposedbysharingaccessrules.


Public

Scalability&Performance

Latency

Latency of exchanged user data: requirements for latency of exchanged user data varies fromapplication to application. Latency cannot be lower that latency introduced by integratedinfrastructure, thus VICINITY should focus on minimisation of additional latency in VICNITY NodecomponentssuchasVICINITYOpenGatewayAPI,VICINITYCommunicationNodeandVICINITYPeer-to-Peernetwork.

VICINITYOpenGatewayAPIprovidesinteroperabilityserviceswithdifferentcomplexity(8.4.3)fromConsuming serviceswith lowest latency up to semantic discovery and querying serviceswith highcomplexity and highest latency. VICINITY Adapter can choose a set of services to use based onlatencyrequirements.

VICINITYCommunicationNodepre-processesexchangeduserdatawithprivacy filteringorend-to-end security, these privacy and security services add another latency in the communication.However,thesefeaturesmaybebypassedbyconfigurationinIoTobjectdescription.

VICINITY Peer-to-peer network shall be built on implementation of XMPP protocol which enablesnear to real-time message exchange between nodes. In certain cases, it is possible to prioritizeexchangedmessagestosuiteneedsofapplication.

Capacity

ThroughoutarchitecturedesignofVICINITY,thefollowingcapacityissueshavebeenidentified,thesecapacity issueswillbeaddressed in followingscalability section.Usersand IoTobjectsgrowth rateinfluences the size and the complexity of the semantic model, semantic data storage (4.3.2) andglobal neighbourhood storage (4.3.1) which might constraint comfortability of VICINITY usage,performanceofdiscoveryqueries,raiseofuserdataexchangerate.

Scalability

ScalabilityofVICINITYCloudcomponents:asdescribedindeploymentview(Section7.1)allVICINITYCloud components are deployed on high-availability platform. High-availability platform will dealwith vertical scalability of the components (such as assigning necessary CPU, RAM and HDD) andhardware/ infrastructure level failovers. However, VICINITY Cloud components shall support ahorizontal scalabilityondifferent layers (data storage clusters, application server farm,web serverfarm,etc.), i.e.provided their servicesacrossmultiplemachines inparallel,beingable to responseevenhighcomputationvolumesand storage loadsand response toVICINITYusersand IoTobjectsgrowthrate.

GeographicaldistributionofPeer-to-Peernetwork:thenatureoftheP2Pnetworkisitsgeographicaldistribution according to geographical distribution of the peers – VICINITY Nodes. Thus, thecomputation volumes performed by peers is distributed and not concentrated in one location.Moreover,P2Pnetworkislooselycoupledthusoverloadingonenodeinfluenceindirectlyonlynodeswith active communication. Note that, high user data exchange rate in P2P network can result inhigherloadofonP2Pnetworkmanagercomponent(8.2.1),thisissueshallbeaddressedbymultipleinstancesofthemanagergeographicallydistributedaccordingtoP2Pnetworkload.

MaintenanceConfiguration of VICINITY components: configurationof static andbehavioural propertiesof eachcomponent is necessary to customize components to changes of their environment (such as


Public

communication interfaces configuration, logging mechanism, etc.). Each component shall includeconfiguration separated from compiled and linked source code. Configuration parameters can beonline and offline. Online configuration parameters can be changed without restarting ofcomponent. Offline needs restart of the component. VICINITY Node components shall promoteonlineconfigurationparametersoveroffline.ImportantconfigurationchangeswithpotentialimpactonsecurityandprivacyshouldbeapprovedbyVICINITYUser(seeprocessesin5.1.1,5.1.2,5.1.3).

InstallabilityofVICINITYNodecomponents:VICINITYNodecomponentsshallsupportdeploymentindifferentenvironments(7.2),thusVICINITYNodecomponentsshouldusetechnologywhichsupportsdifferent type of software packaging (such asWAR file for java based application servers, DockercontainerforMicrosoftAzureorAmazonAWS,OSvirtualmachines).

Monitoring of VICINITY components: to keep VICINITY components running for long time in theproduction it is important to monitor hardware resources allocation and VICINITY componentsperformancebehaviour.SelectedtechnologyusedinVICINITYcomponentsshallsupportmonitoringof these resources through standard protocols and frameworks (such as SNMP, JMX, etc.), thusindustry standard DEVOPS monitoring tools like Nagios or Microsoft System Center can be used.While VICINITY Nodes components might be unreachable by DEVOPS monitoring tools, loggingmechanismshallbeimplementedtocollectlogs.

Security&PrivacySecurity architecture of the VICINITY platform will define the security services and mechanismsenabling those services to run and provide the necessary protection and safe operation of theplatform in the security context of VICINITY (Figure 34). This document gives an overview of theenablingsecurityservicesoftheplannedarchitecturalmodelandtheenablingsecuritymechanisms.

Figure 34 Security context of VICINITY

The security context of VICINITY Solutions focuses on VICINITY Cloud components, security ofVICINITY P2P Network and VICINITY Node components including VICINITY Communication Node,VICINITY Gateway API and VICINITY Agent. The security service considers of IoT integratedinfrastructures, proximity network, and devices indirectly through VICINITY Agent and VICINITYGatewayAPIinsituationwheretheycanposerelevantsecurityrisk.


Public

Theselectedsetofservicesproposedcomesfrombestpracticesandisadaptedtotherequirementssetwithin theVICINITY project. However, the final selection of the security component should bebased on the requirements and the VICINITY solution implemented procedures for informationexchange.ThefinalselectionandthesecuritycomponentswillbeprovidedinD4.3VICINITYSecurityserviceofWP4.

ThesecurityarchitecturalmodelwithsuggestedsecuritycomponentsisillustratedinFigure35.Thesecurity services are implemented through the security mechanism. This mechanism impliesselection of the logical security architectures and provision technology solutions and standards.SelectionofthemechanismandprovisionoftechnologysolutionsandstandardswillbepartofthesecurityserviceimplementationTask4.3.

Figure 35 Security architecture ThesecurityservicescanbemappedtoAIOTIWG0412securitypolicyrecommendationsasfollows:

Table 16 VICINITY Security features mapped to AIOTI recommendations

AIOTI WG04 Security policyrecommendation

VICINITYPosition`

Embed ‘safe and secure software’design and developmentmethodologies across all levels ofdevice/ application design anddevelopment and implementsecurity into that life cycle at thesametime.

VICINITY security has been analysed from technicalspecification(D1.5)andarchitecturedesign(9.5)pointofview.Set of security requirements and security service has beenidentified and will be implemented in the WP4 – Task 4.3,securitywillbeevaluatedinWP6–Task6.4.

Design, deliver and operate VICINITYshallprovidefollowingadaptiveanddynamicend-to-

12www.aioti.org/wp-content/uploads/2016/10/AIOTIWG04Report2015.pdf


Public


VICINITYPosition`

adaptive and dynamic end–to-endsecurity overheterogeneousinfrastructures integrating IoT,networks and cloudinfrastructures. We recommendunderlying standardised OS andhardware security features wherearchitecture permits. Thedeployment shouldnotbe specificor propose a modification ofexisting OS and hardware alreadyintegratedbyIoT.

endsecurityfeatures:

• controlling access to share objects (devices, value-added services)within VICINITY through sharing rulesinvirtualneighbourhood(D1.5–UC0100,3.1.1,5.1.2);

• notificationandapprovalmechanismforanyimportantchange in virtual neighbourhood such as devicesregistration, request for data sharing (D1.5 – UCNTF010,5.1.2);

• adaptation to heterogeneous security features ininfrastructuresthroughagentsandadapters.

Develop best practices confirmingminimum requirements forprovisionofsecure,encryptedandintegrity-protected channel,mutual authentication processesbetween devices and measuressecuring that only authorisedagents can change settings oncommunicationandfunctionality.

VICINITYshallprovidessetofstateoftheartsecurityserviceswithensures:

• end-to-end encryption and data integrity services ofexchanging of the user-data between integratedinfrastructure(9.5.1.6,9.5.1.8);

• verificationandcredentialmanagementofthedevices,application and VICINITY users identities (9.5.1.1,9.5.1.2);

• secure communication channel between VICINITYcomponentsandenvironment;

Developa‘NewidentityforThings’– To date, Identity and AccessManagement (IAM) processes andinfrastructure have been primarilyfocusedonmanagingtheidentitiesof people. IAM processes andinfrastructure must now be re-envisioned to encompass theamazing variety of the virtualizedinfrastructure components. Forexample, authentication andauthorization functions will beexpanded and enhanced toaddress people, software anddevices as a single convergedframework.

VICINITYwill rely on existing identitymanagement of devicesof integrated infrastructures and their adaptation throughadapters and agents supportedby interoperability services ofVICINITYGatewayAPI(3.3).

DevelopaCommonAuthenticationarchitecture – WG4 recommendsinvestigation of a Secure Identityand Trusted Authenticationmechanism,forexampleonewhichtakes into account different

VICINITY shall rely on current authentication of value addedservices and services of integrated infrastructure throughVICINITY Adapters on VICINITY Gateway API (9.5.1.1, 9.5.1.2,9.5.1.3).


Public


VICINITYPosition`

authentication standards and willprovide a single-sign-on solutionfor IoT applications movingbetweendifferentsystems.

Certification – the certificationframework and self-certificationsolutions for IoT applications havenot been developed yet. Thechallenge will be to have genericand common framework, whiledeveloping business specificprovisions. This framework shouldprovideevaluationassurancelevelssimilar to theCommonCriteria forInformation Technology SecurityEvaluation (IS0/IEC 15408), whichshouldserveasthereference.

VICINITY shall rely on device, value-added services andorganizationprofilesincludinginformationaboutdevice,value-added services andorganization. Theseprofilesmight includesecurityandprivacy claimsprovidedbydeviceowner, serviceprovider and organization. Profiles are accessible thoroughVICINITY Neighbourhood manager and can be used duringevaluationvicinityneighbourhoodsharingrules.

The privacy concepts introduced in VICINITY can be mapped to AIOTI WG04 13 privacyrecommendationsasfollows:

Table 17 VICINITY Privacy features mapped to AIOTI recommendations

AIOTI WG04 Privacyrecommendation

VICINITYPosition`

PrivacyImpactAssessmentsshouldbe performed before any new IoTapplicationsarelaunched.

VICINITY shall rely on Privacy Impact Assessments oforganizationandserviceprovided.Resultoftheprivacyimpactshallbeincludedinorganizationandserviceprofiles.

Stakeholdersmustdeleterawdataassoonastheyhaveextractedthedata required for their dataprocessing.

VICINITY shall not store any user data from integratedinfrastructure, devices and service. VICINITY only facilitatesexchange of the user data. Any private data stored in user,organization, device and service profiles can be updated byuser and removed when not used any more if possible14(deviceremoved,serviceremoved,usersignout,organizationsignout).

EveryIoTstakeholdershouldapplytheprinciplesofPrivacybyDesign.

VICINITYprivacyhasbeenanalysedfromtechnicalspecification(D1.5) and architecture design (9.5) point of view. Set of

13www.aioti.org/wp-content/uploads/2016/10/AIOTIWG04Report2015.pdf14legalandsecuritymeasurescanpreventtoremoveaprivatedataifnotactivelyusedanymore.


Public

AIOTI WG04 Privacyrecommendation

VICINITYPosition`

privacy requirements and privacy functions (mostly derivedfromGDPR15) hasbeen identifiedandwill be implemented intheWP3 – Task 3.1, privacywill be evaluated inWP6 – Task6.4.

Data subjects and users must beabletoexercisetheirrightsandbe“in control” of their data at anytime.

VICINITYenablesVICINITYusertorevokeaccesstodeviceandservices at any time using VICINITY Neighbourhood manager(D1.5–UC0100).

The methods for givinginformation, offering a right torefuse consent shouldbemadeasuser-friendlyaspossible.

VICINITY shall provide features to manage private dataprocessing consent for device and service in VICINITYNeighbourhoodManager(D1.5–UCPRV000).

Devices and applications shouldalso be designed so as to informusersandnon-userdata-subjects.

VICINITY shall notify by VICINITY user (device owner, serviceprovider,IoToperator)aboutanyimportantchangesoractionrequired (accepting access to device or service) (D1.5 – UCNTF010).

Enablingsecurityservicesandmechanism

ThissectionlistthefollowingpotentialsecurityservicesaspartoftheVICINITYarchitecture:

• CredentialManagement;• Authentication;• AccessControl;• PrivilegeManagement;• AuditTrails;• DataIntegrity;• DataConfidentiality;• SecureCommunicationChannel;• Accountability;• Non-Repudiation;• ConfirmationofReceipt.

ThesetofsecurityservicesandtheirsecuritymechanismisnotfinalandwillbeadjustedthroughoutofthelifecycleprojectandVICINITYsolutionbasedonprojectprogressandneeds.

Within each of the security service description short conceptual description of the securitymechanismisprovided.

15Regulation(EU)2016/679oftheEuropeanParliamentandoftheCouncilof27April2016ontheprotectionofnaturalpersonswithregardtotheprocessingofpersonaldataandonthefreemovementofsuchdata,andrepealingDirective95/46/EC(GeneralDataProtectionRegulation)


Public

Authentication

The security serviceauthentication shouldensure thatentity (application,person)has the claimedforprovidedidentity.

Inauthenticationentitiesareconsidered:

• Usersandtechnicalusers(softwarecomponents,services,storages,applications);• IoTobjectssharedwithintheVICINITYNeighbourhood.

VICINITY-ARCH-SEC-010 Authentication

The VICINITY shall support only standard based authentication mechanism. The VICINITY shallsupporthethefollowing(oneormore)mechanism:

• Usernameandpasswordauthentication;• Digitalcertificate-basedauthentication(suchasX.509certificates);• OAuth2.0;• JSONWebToken;• SAML2.0.

Allentitiesshouldbesubjectoftheauthentication.

Consideredrequirements:VICINITY-NFUNC-SEC010,VICINITY-NFUNC-SEC050

CredentialManagement

The credential management service shall manage the life cycle of entity credentials used inauthenticationandaccesscontrol(authorization).

The credential management service shall include credential generation, registration, change,recovery,revocationanddeletion.

VICINITY-ARCH-SEC-020 CredentialManagement

TheVICINITY shall store and transmit passwords, tokens and keys in irreversible encrypted form.Passwordshouldhavenotbeendisplayedondevicedisplay.

Thepasswordpolicyshouldbeappliedincludingatleastfollowingrules:

• Minimumlengthspecification;• Requiredcharacterset;• Passwordlifetimeexpiry;• Listofpreviouspasswords;• Passwordsmustbechangedafterinitiallogin.

Consideredrequirements:VICINITY-NFUNC-SEC010

Thecredentialmanagement service shall continuously revise requirements for securityparametersofdigitalcertificatesandtokensbasedonthecurrentbestpractice.


Public

Access(authorization)control

Theaccesscontrol(authorization)serviceshallensurethattheentityhasaccesstoresourcesifandonlyifitispermitted.

VICINITY-ARCH-SEC030 Access(authorization)control

Theaccesscontrolmechanismshallsupportauthorizationbasedon:

• Identity–useraccesstoVICINITYneighbourhoodmanageuserinterfacesandentitiesaccesstoVICINITYinternalservicesandresources(suchasstorageservices,etc.);

• Role – entity authorization to functions of VICINITY Neighbourhood Manager based onusers’roles;

• Context–suchasentityauthorizationtoIoTobjectproperties,actionsandevents.


The access control mechanism shall support distribute sharing access rules within P2P Network(5.1.2.1).

Theaccesscontrolmechanismshallsecurefallbackscenariowhenauthenticationmechanismisnottemporaryunavailable.

PrivilegeManagement

Theprivilegemanagement service shall support consistent and controlledmechanism to associateaccessrulestoentities.

Theprivilegemanagementshalldefine:

• Dedicatedowner–eachsubjectoftheaccesscontrolshouldhaveitsowner;• Reasonable defaults – default privileges should be selected sensible (e.g. organisation

managerhasprivilegetoaddusertoorganisation);• Explicitgrant–implicitgrantingshouldbereducedtominimum;• Privilegegrantingonlybytheowner;• Privilege recovery – in case of the software component recovery the privileges should be

recovered(i.e.recoverytopreviousstateormostsecurelevel);

Audittrails

VICINITY-ARCH-SEC040 Audittrails

The VICINIT shall providemeans to support auditing in for important (whichmight be subject ofrelevantdispute)actionstakeninVICINITY:

• VICINITYCloudcomponents;• VICINITYP2Pcomponents;• VICINITYNodecomponents.

Consideredrequirements:VICINITY-NFUNC-SEC060,VICINITY-NFUNC-SEC050,VICINITY-NFUNC-SEC070


Public

Dataintegrity

VICINITY-ARCH-SEC050 Dataintegrity

TheVICINITshallprovidemeanstosecuredataintegrityof:

• Exchangeofuserdatafromdataorigintodatadestination;• Metadataexchangebetweencomponents;• Andauditlogs;


Accountability

VICINITY-ARCH-SEC060 Accountability

Eachaction (suchasservicecall,messageexchange)performedshouldbeperceived incontextoftheactionoriginatedentity.


Dataconfidentiality

Thedataconfidentialityserviceshallensurethatdataisnotdisclosedtosystementitiesunlesstheyhavebeenauthorizedtoknowthedata.

VICINITY-ARCH-SEC070 Dataconfidentiality

The VICINITY shall apply strong encryption algorithms (publicly available and subjected of publicreview)toensuredataconfidentiallymainonexchangeoftheuserdata.

Theencryptionalgorithmparametersshallbeconfigurabletosupportalignmentwithcurrentbestpractice.

The encryption algorithm should be basedon symmetric all asymmetric encryption schemas. Keymanagementmechanismshouldensurethatdatakeyisstoredsecureandreliable.

Keys should be cryptographically strong and generated by well understood algorithms withsufficientrandomnessonly.

Consideredrequirements:VICINITY-NFUNC-SEC030sa

Securedcommunicationchannel

The secured communication channel service is to ensure confidentiality, integrity, availability,authenticity and accountability of exchanged data between peers (architecture components, userandcomponents).


Public

VICINITY-ARCH-SEC080 Securedcommunicationchannel

The VICINITY shall support secured communication channels between architecture components,userandcomponentsincluding:

• mutualauthenticationofpeers;• adequateprotectionofexchangeddataagainsteavesdroppinganddatatempering;


Non-repudiations

The non-repudiation service shall provide protection against false denial of involvement in anassociation.

The VICINIT shall provide means to support of non-repudiation for critical actions (such as: dataprocessing consents, setting privilege, etc.) performed by (technical) user or user data exchangethroughtheVICINITYNodes(suchasperformingaction,eventreception,etc.).


Public

ConclusionsThe goal of the VICINITY Architecture includes description of VICINITY components and conceptsfrom static and behavioural point of view. Architecture design encompasses specifications ofcomponents functions and interactions, implementation and deployment. VICINITY ArchitecturedesignshouldbeinterpretedtogetherwithD1.5VICINITYTechnicalrequirementsspecification.

TheVICINITYArchitecturehasbeenbrokendown intoseveralarchitecturecomponentsgrouped inVICINITYCloudcomponentstoinclude:

• VICINITYNeighbourhoodmanager;• Semanticdiscovery&dynamicconfigurationagentplatform;• VICINITYCommunicationServer;• VICINITYGatewayAPIServices;

andVICINITYNodecomponents:

• VICINITYCommunicationNode;• VICINITYGatewayAPI;• VICINITYAgentandAdapter.

Eachcomponentwasdefinedbysetofprincipalfunctionsandinformationflowsneededtoprovidethese functions. These all information flows together define processes executed between thesecomponents.Theprocessesdefinesetofinternalandexternalinterfacesofeachcomponent.

Detailarchitecturedesignofthesecomponentselaborateconceptsoftheirfeaturesfocusingon:

• UserinterfacefunctionalityinVICINITYNeighbourhoodManager;• ManagingofsemanticmodelinSemanticdiscovery&dynamicconfigurationagentplatform;• ControllingofVICINITYP2PnetworkbyVICINITYCommunicationServer;• CreatingVirtualThingEcosystemDescriptioninVICINITYGatewayAPIServices;• Securing data forwarding between integrated infrastructures by VICINITY Communication

Node;• IntegrationofinfrastructuresintoVICINITYbyVICINITYAgentandAdapter.

The VICINITY architecture is supported by security, privacy, performance and availability conceptsuchas:

• security transparently protects VICINITY itself and exchanged data, including role based

access to data, data integrity and end-to-end security on VICINITY Communication Node

supportedbyIoTobjectsdescriptionandsharingaccessrules;

• privacybydesigntoprotectprivacyofexchangeddatabetweenpeersutilizingtheVICINITY

conceptof end-to-endencryptionbetweenVICINITYCommunicationNodesdefinedby IoT

object descriptions and authorization based on sharing access rules provided by device

ownersandserviceproviders;

• performanceaddressedbyneartoreal-timemessageexchangeinpeer-to-peernetwork;

• availability of components deployed in high available scale out VICINITY cloud and loosely

coupledP2PnetworkofVICINITYNodessupportingoflocalisationofcomponentavailability

andperformanceissues.


Public

VICINITYTechnicalrequirementsspecificationisaninputforWP3andWP4tobreakdownVICINITYsolutionintothesmallermanageablesoftwarecomponentfordetaildesignandimplementation.


Public

AppendixA. DeploymentofVICINITYNodeonVICINITYGateway

Asshownin7.2,theVICINITYAgent,runningoneachVICINITYNode,abstractsfromdevicebundles(thatisactualhardwarecomponentsofIoTdevicesaswellastheirpotentiallyclosed-sourcedrivers).ThisononehandgivestheopportunitytomanufacturerstoconnecttheirdevicestotheVICINITYbysimplyprovidingadapters/driversfortheirhardwaretotheVICINITYagent,withoutrevealingdetailsabouttheirinternalimplementation(Figure36).Ontheotherhand,thisofferssoftwaredevelopersauniformaccesstotheattachedhardware.Devicediscovery,offeredbyanysoftwareframework,maythen takeplaceamongst thesedevicebundles.Thecommunicationbetweenattacheddevicesandtheusedsoftwareframeworkcanuseanyarbitrarymessagingprotocolslikee.g.CoAP,MQTT,REST,etc.

Finally, aVICINITYNodeoffers theVICINITYGatewayAPI for communication to/from theVICINITYCloud. It also acts as a VICINITY communication Node to enable P2P communication amongstVICINITYNodes.Tothisend,theVICINITYAgentultimatelyneedstomapthesemanticsoftheusedSoftwareframeworkontotheVICINITYontology.

Software andHardware Frameworks are used to provide the necessaryGateway functionality. Anoverview on potential Hardware and Software platforms is given in VICINITY Deliverable D2.1 -Analysisof StandardisationContext andRecommendations for Standards Involvement -Chapter2,whichwassubmittedinSeptember2016.

Figure 36 Deployment-Scenario of a VICINITY Node on VICINITY Gateway


Public

AppendixB. Referencearchitecture

ISO/IEC is the standardisation body responsible for developing international standards. The sub-committee SC41 is responsible for Internet of Things, Sensor networks and Wearables. Astandardised IoT reference architecture has been drafted in ISO/IEC 30141:2017 using a commonvocabulary, reusable designs and industry best practices. It uses a top down approach, beginningwith collecting the most important characteristics of IoT, abstracting those into a generic IoTconceptualmodel,derivingfromtheconceptualmodeltoahigh-levelsystembasedreferencemodeland then breaking down from reference model to the five architecture views (functional view,systemview,userview,informationviewandcommunicationview)fromdifferentperspectives.ThecontentofthisappendixcomesfromtheISO/IECstandard(notfromVICINITY)andthedocumentisstillunderdevelopment(i.e.,subjecttochanges).

AppendixB.1. IoTReferencearchitectureinrelationtoVICINITYArchitecture

Figure 37 IoT Reference architecture in relation to VICINITY Architecture

From the IoT Reference architecture point of view, VICINITY interactswith the following domainsthroughVICINITYAgentsorAdaptersinVICINITYNodes:

• IoT Resource Interchange domain to access resources of integrated IoT infrastructure orvalueaddedservice;

• Sensing & controlling domain to access or virtualize devices by VICINITY Agents andAdapters.


Public

AppendixB.2. IntroductiontoIoTReferencearchitectureThedraftedstandardcoversthegeneralisedReferencearchitectureofIoT,whichistoserveasbasewhentodevelop(specify)contextspecificIoTarchitecturesandthentoactualsystems.Thecontextscan be of different kinds, e.g., industry verticals or national specific requirement sets, see figurebelow.

Figure 38 Context of IoT architectures

TheIoTReferenceArchitecture(RA)describesaConceptualModel(CM)containingcommonentitiesandtheirrelations,andaReferenceModel(RM)anddifferentarchitectureviews.

Figure 39 Conceptual model of IoT reference architecture CMcontainsthefollowingelements

Figure 40 Relation between overall model and architecture concepts

Clause structure

Conceptual model Reference model

Characteristics

Architecture view

are abstracted and generalized to build

develops

creates

Conceptual model

The overall modelConceptsbuild


Public

TheRMcontainsthefollowingparts:

Figure 41 IoT architecture reference model of Architecture views

AnIoTsystemisinteroperabletootherIoTsystems.Forthispurpose,functionsbasedonallorapartofthesecharacteristicscanbeimplementedinIoTsystemsaccordingtoservicesandoperations.ThecharacteristicsofIoTsystemsistakenfromISO/IEC30141:2017anddefinedas

Auto-configuration is the automatic configuration of devices based on the interworking ofpredefinedrules(associatedalgorithmsbasedondatainputs).Auto-configurationincludesautomaticnetworking,automaticserviceprovisioningandplug&play.Auto-configurationallowsanIoTsystemtoreactonconditionsandtheadditionandremovalofcomponentssuchasdevicesandnetworks.Auto-configurationneedssecurityandauthenticationmechanismstomakesurethatonlyauthorisedcomponents can be auto-configured into the system. Security mechanism need to be organizedappropriatelyforeachmarketsegment.

Auto-configurationisusefulforIoTsystemswheretherearemanyandvariedcomponentsthatcanchangeovertimeanditbenefitsthoseuserswhoexpectrobustsystemsbecauseauto-configurationcanallowautomaticeliminationoffaultycomponentsandmaintenanceofaworkingsystem.

Examples of auto-configuring devices and protocols include DHCP, Zero Configuration Networking(Zeroconf),Bonjour,UPnPISO/IEC29341seriesetc.

Separation of functional and management capabilities means that the functional interfaces andcapabilitiesofanIoTcomponent,suchasanIoTdevice,arecleanlyseparatedfromthemanagementinterfacesandcapabilitiesofthatcomponent.Thistypicallymeansthatthemanagementinterfaceisonadifferentendpoint fromthatof the functional interfaceand themanagementcapabilitiesarehandledbydifferentsoftwarecomponentsthanthefunctionalinterfaces.

Managementcapabilitiesandfunctionalcapabilitieshavelogicallydifferent

• purposes(execution/actionvsinformation/description),

• userroles(controlandmodifybehaviourvstransferorconsumefactsandinformation),

• classificationandtypesofdata(technicalorsystemspecificvspersonal/sensitive/public),


Public

• access(e.g.anoperatormayaccesssystemconfiguration,butnotgatheredpersonaldata;whiletheusercanaccessthepersonaldatabutnotaccessandmodifysystemconfiguration)

• protocols,formatsandlifecycle(e.g.supportmultiplecontrolprotocolsvsmeta-data/structureofthetransferredinformation,whichisparticularlyimportantconsideringinteroperabilityandco-existenceofmultipleversionsandvariantsofmanagementcapabilities)

Usually, the differences have associated specific risks and require special security (and other)controls,e.g.retentionpolicyisapplicablewhiledealingwithfunctionaldata,butmightnotapplytomanagementdata;accesscontrolmaybeweakerforauserandstrongerforanadministrator).

Ubiquitouspenetrationof IoT intovirtuallyallareasof life increasestheattacksurface,multiplyingthe number of potential attack targets and often making ineffective measures such as physicalsecuritycontrols.ThekeyvalueofIoT–theconnectionofnumerousedgecomponentstoeachotherand to IoT service components – increases the security concerns, since adding aweak linkmakeswholechainweak.Applicationsandsystemspreviouslyrunning inwell-protecteddatacentresmaybecomeexposedtoadditionalthreatsviaconnectedIoTcomponents.

Separationofmanagement from functional capabilities enables or strengthens the ability to applydifferentauthorization,authenticationandprotectionmechanismsorconstraintstomanagementasopposed to functional capabilities. Broad sharing of data from an IoT system might be useful ordesirable, and yet there are many circumstances where it is necessary to limit control of an IoTsystemor component toonlya subsetof theentitieswithwhich thedata from that IoT system isshared.

If an IoT system is used to provide sensors and data for HVAC or other building managementsystems,itmightbedesirabletosharedatawithotherinter-relatedsystems(alarms,accesscontrol,power management or auxiliary power, etc.), while still retaining management of the system toensuresystemconstraintsarerespected.

Distributed systems are the systems which, while being functionally integrated, consists of sub-systems which may be physically separated and remotely located from one another. These sub-systemsarenormallyconnectedbyacommunicationlink(e.g.databus).(ISO3511-4)

IoTsystemscanspanwholebuildings,spanwholecities,andevenspantheglobe.Widedistributioncan also apply to data –which can be stored at the edge of the network or stored centrally or acombination of the two. Distribution can also apply to processing – but processing can also takesplacecentrally(incloudservices),butprocessingcantakeplaceattheedgeofthenetwork,eitherinthe IoT gateways or even within (more capable types of) sensors and actuators. Today there areofficiallymoremobiledevicesthanpeopleintheworld.

For industry 4.0, manufacturing can be done using smart manufactory systems which havedistributed assembly lines across many factories and closely integrated with 3rd party suppliers,logistics companies, market providers and customers etc. all located far away from the assemblyline"after.

Network communications – IoT systems depend on network communications of a number ofdifferent types. There are often limited range, low power networks collectively termed proximitynetworks that form the local connections for IoT devices. There are thewide area networks thatconnecttheproximitynetworkstotheinternet,whichcantakewiredandwirelessformsandwhichmaybededicatedtotheIoTsystemorwhichmaybesharedgeneralpurposenetworks.


Public

Communication protocols used can vary between the different network types. It is common forproximitynetworkstousespecializedprotocolssuitedtothespecializednatureofthesenetworks.IPismoretypicallyusedforthewideareanetworks,althoughthehigherlevelsintheprotocolstackcanvary,withHTTPbeingusedinsomecases,andmessagingprotocolsbeingusedinothercases.Somenetworksaredeliberatelyintermittentinnatureandtheprotocolsusedforsuchnetworksreflecttheintermittenttransmissionpattern.

IoT systems rely on the ability to exchange information units in a structuredmanner based upondifferentbut interoperablekindsofnetworktypes.Devicesneedtobothtransmitandreceivedataandneedtocommunicatewithsoftwareservicesthatmaybelocatednearbyorinaremotelocation.

Gatewaysmaybeemployedtoconnectnetworksofdifferenttypes,typicallybetweentheproximitynetworks and the wide area. Network structure may need to be dynamic and needs to considerpropertiessuchasQoS,resilience,securityandmanagementcapabilities.

Inaproximitynetwork,IoTdevicescanbeconnectedbywirelesstechnology,e.g.,IEEE802.15.4andIEEE802.11incommunicationprotocolsonphysicalanddatalinklayers.Datamaybetransportedby6LowPANwhich is IoT specific IP andUDP. The IoT devices are then connected to a dedicated orgeneral purposewide area network via area aGatewaywhich routes data between the proximitynetworkandthewideareanetworkasnecessary.

Network management - IoT systems require network management. The form and purpose ofnetworkmanagementandoperationdependonthenetworktypeandnetworkownershipandthetypeofcommunicationtakingplaceoverthenetwork.Managementisrequiredduringthesettingupofanetwork, including thehandlingofdevice identityandaddresses,profiles for theusageof thenetwork and the inclusion of dynamic management capabilities. Management of the networksinvolvescontroloverQoS,dynamicextensionofthenetworks(forneworupdatedIoTdevices),faulthandlingandsecuritycontrol.Networksmustalsohandledynamicandtransitorymembershipofthenetworkbymobiledevicesasthosedevicesmoveintooroutoftherangeofthenetwork.

Some networks are managed as part of the IoT system – particularly the proximity networksconnecting the IoT devices. Other networks, particularly the wide area networks, may not bemanaged as part of the IoT system, since they are general purpose networks often run by otherorganizations(e.g.mobilephonenetworks).

IoTnetworkmanagementhas to spanbothkindsofnetworksandassemble them intoa coherentsystemthatcanserve thepurposesof the IoTsystem.Where IoTsystemsmakeuseof thirdpartygeneral purpose communication networks, their management and operational interfaces can beused,whereavailable.

Energy monitoring by smart meters is an example of a context where strict operation andmanagementwillbe likely,sincethere isacommercial interest insuchan IoTsystembeingfreeofunauthorized activity. In such a context, all of the IoT devices, communication networks andinformationprocessingplatformsaremanaged.

On the other hand, in case of home energy management, it is not necessary that the individualdevicebemanagedstrictly.Themanagementofthenetworksandinformationprocessingplatformsofthevendor’ssupportinfrastructurewillbedonemoreasameansofsellingmoredevicesthanasaprofit-generatingserviceinitself.

Real time capability is pertaining to a system or mode of operation in which computation isperformed during the actual time that an external process occurs, in order that the computationresults can be used to control, monitor, or respond in a timely manner to the external process.(ISO/IEC/IEEE24765).


Public

IoTsystemsoftenfunctioninrealtime;dataflowsincontinuallyabouteventsinprogressandtherecan be a need to produce timely responses to that stream of events. This may involve streamprocessing; acting on the event data as it arrives, comparing it against previous events and alsoagainststaticdatainordertoreactinthemostappropriateway.

In process control systems, process parameters like temperature, flow, or pressure or status of adevicearecontinuouslymonitoredbysensorsandinstantactionsareinitiated.

Self-descriptionisprocessbywhichcomponentsofanIoTsystemdefinetheircapabilitiesinordertoinform other IoT components or other IoT systems for the purposes of composition andinteroperability. Self-description includes interface specification, the capabilities of the IoTcomponent, what types of devices can be connected to an IoT system, what kinds of service aremadeavailablebytheIoTsystem,andthecurrentstateoftheIoTsystem.

Self-description is needed for composability and interoperability for IoT systems and IoT devices.Self-description is of most benefit for those use cases where an IoT system needs to beinterconnectedwithotherIoTsystemsorthoseusecaseswhereanIoTsystembenefitsfrombeingextendedby the additionof new IoTdevices.Self-description is alsonecessary formobiledevicesandalsofordevicesthathibernate–bothofwhichjoinandleavenetworksonaregularbasis.

Exampleof self-description for an IoT systemandprotocols:A systemwhichusesBluetooth in itsproximitynetworksprovidesdevicenameandsupportedservicelisttoeachotherwhenconnecting.

WifiaccesspointsbroadcasttheSSID.Wi-FidevicessendpasswordsandMACaddressestoanaccesspointwhenconnectingtoit.

Servicesubscription–ItisoftenthecasethatIoTuserssubscribetoIoTservicesmadeavailablebyIoTserviceproviders.Inthiscase,theIoTserviceprovidersmakeavailableasubscriptionprocessbywhich the IoTusers can subscribe to aparticular IoT service. The subscriptionprocess can includepayments,plusaclearstatementofanypre-requisitesthatapplytotheIoTuser.ItcanbethecasethattheIoTservice involvesthe installationof IoTdevicesandtheinstallationandconfigurationofsoftwarecomponents–thesearetypicallyprovidedorspecifiedbytheIoTserviceprovider.

In somealternativecases, the IoTusercanestablish theirown IoTservice,but in this case the IoTuser has the burden of acquiring the necessary equipment and software and has the subsequentresponsibilitiesforoperatingandmaintainingtheIoTservice.

SomeIoTsystemsareestablishedonthebasisofasubscriptionmodelwheretheIoTuserspayfortheiruseoftheIoTsystem–inthesecases,theIoTserviceprovidermustestablishclearmechanismsforestablishingandmaintainingthesubscriptions.

An example of a subscription-oriented IoT service is the provision of personal fitnessmonitoring,wheretheIoTusermustpurchaseawearableIoTdevicethatisthenconnectedtoanIoTservicethatmonitorstheiractivityusingthecollecteddataandprovidesanalysisandadviceonhowtheiractivityishelpingtheuserachievelifegoals.

Content-Awareness is the property of having sufficient knowledge of the information in an IoTcomponentand itsassociatedmeta-data.Devicesandserviceswithcontent-awarenessareable toadaptinterfaces,abstractapplicationdata,improveinformationretrievalprecision,discoverservices,andenableappropriateuserinteractions.

Content-Awareness facilitates appropriate functional operations, such as data routing, speed ofdelivery,securitycapabilitiessuchasencryption,basedonfactorssuchaslocation,qualityofservicerequirementsandsensitivityofdata.


Public

This capability can be essential in many applications including health services, broadcasting,surveillance systemsandemergency serviceswhere some typesof informationordata flowshavespecificrequirementswithrespecttotimeliness,securityandprivacy.

Context-Awareness is the property of an IoT device, service or system being able tomonitor theenvironmentinwhichitisoperatingenvironmentandeventswithinthatenvironmenttodetermineinformation such as when (time awareness), where (location awareness), or in what order(awarenessofsequenceofevents)oneormoreobservationsoccurredinthephysicalworld.

Context-Awarenessenables flexible,user-customizedandautonomicservicesbasedontherelatedcontextofIoTcomponentsand/orusers.Contextinformationisusedasthebasisfortakingactionsinresponse to observations, possibly through the use of sensor information and actuators. To fullyutilizeanobservationandeffectanaction,theunderstandingofcontextisoftencritical.

An example of context awareness would be location-based services, such as a system in whichdifferentservicesarepresentedaccordingtothelocationofause

Incasesofanemergencylikeafire,thearrivalofthefireservicerequiresthatthedoorstoabuildingshallbeunlocked.Thesecuritypolicythatgovernsthedoor’saccesscanbeenhancedwithcontext.The context here is that an emergency situation is currently happening and that the emergencyservicesareinthevicinity.Basedonthesetwocontextualinputsthepolicycouldenablethesystemtounlockthedoorautomaticallyandprovideaccesswithouttheneedforfurtherauthorisation.

Timeliness isthepropertyofperforminganaction,function,orservicewithinaspecifiedperiodoftime,whichsupportsdeterministicoperations.

AsIoTsystemsactonthephysicalworld,someeventsinitiatedbytheIoTsystemsneedtooccuratcertain times, or within certain intervals of time, or in a particular sequence in relation to otherevents.Toachievethis,theactions,functions,andservicesthatleadtosucheventsneedtohappenwithinspecifictimeconstraints.TimelinessinIoTincludesnotonlylatencyrelatedissues,butotheraspectssuchasjitter,frequency/samplingrate,andphase.

Anexample inan industrialmanufacturingprocesscontextmight involvesomesensorsmonitoringthequalityofitemsflowingdownanautomatedproductionline

Inanindustrialmanufacturingprocess,anexampleiswheresomesensorsaremonitoringthequalityof items flowing down an automated production line. Any itemswhich are considered below therequiredqualitymustberemovedfromthe line.Theremoval isperformedbysomeactuatorsthatdiverttherelevantitemsofftheline.Toachievethis,thereisastricttimelimitoncommandingtheactuatorstoperformthediversion–alltheprocessingofsensorinformationandotherrelevantdatamust be completedwithin the time limit.Where IoT entities are part of any kind of control loop,overallprocessingtimefortheloopiscritical.

ComposabilityistheabilitytocombinediscreteIoTcomponentsintoanIoTsystemtoachieveasetofgoalsandobjectives.

Systemintegration,interoperabilityandcomposabilitydealwithhowthefunctionalcomponentsareassembledtoformacompleteIoTsystemandhowthefunctionalcomponentsconnecttoeachotherand the binding mechanisms which are used (e.g. dynamic or static, agent-based or P2P).Interoperability and composability are important topics in both the cyber and physical spaces.Composability imposesastrongerrequirementthan interoperability inthat itrequirescomponentsnot only compatible in their interfaces but exchangeable with other components. At a minimumshare similar components and provide improvements on any of the characteristics such as timingbehaviours,performance,scalabilityandsecurity.Whenacomponentisreplacedbyanotherofthesamekindthat iscompostableandcompatible theoverall systemfunctionsshould,ataminimum,


Public

remainunchangedbutconsiderationcanbegiventopermitting improvements insystemfunctionsandcharacteristics.

Anexampleofcomposabilitymightbetheabilitytoswapoutsensorcomponentsfromonevendorand replace themwith sensor componentsproducedbyadifferent vendor. In this example, theremightbetwolevelsofcomposability.

Firstwouldbecompleteinterchangeabilityof“commodity”functionality,suchasanIoTdevicefromVendorAbeingfullyreplaceablewithonefromVendorB.

Asecondlevelofcomposability(orpossiblyinteroperability)mightbeanIoTcontrolthatisvendor-specificattheinterfacebetweentheIoTcomponentandaphysicalprocessdevicebeingcontrolled(avalve,motor,switch,pumporfan,forexample),but isstill fully interchangeableattheinterfacebetweentheIoTdeviceandtherestoftheIoTsystem.Inthissortofexample,theIoTdevicewouldserve as a kind of “middleware” between the vendor-agnostic IoT infrastructure, and the vendor-specificphysicaldevicesormechanismsbeingcontrolled.

Discoverabilityallowsusers,services,andotherdevices,tofindnotonlydevicesonthenetworkbutalsothecapabilitiesandservicestheyofferatanyparticulartime.DiscoveryservicesallowIoTusers,services,devicesanddatafromdevicestobelocated,identified,andaccessedaccordingtodifferentcriteria,suchasgeographiclocation,criteria,suchascapabilitiesandgeographiclocation.

Services connected with an IoT system can indicate what information can be found by aDiscovery/Lookup service in accordance with predefined rules for each market segment.Discovery/Lookupservicesallow IoT systems to locateotherdevices, servicesor systemsbasedonparameters such as geographical location, capabilities, interfaces, accessibility, ownership, securitypolicy,operationalconfiguration,dataprovided,dataconsumed,orotherrelevantfactors.

IoTsystemswhichsupportdynamicconfiguration,suchastheadditionofnewdevicesandservicesto the IoT system, have a requirement for some form of discoverability, since there is a need toidentify and characterize new components added to the system. So the addition of a newtemperaturesensorinabuildingmonitoringIoTsystemisanexample,whereitisnecessarytobringthe new sensor into the existing system with minimum effort. Various protocols and softwaresolutionsexisttoprovidediscoveryinIoTsystems,withavarietyofarchitectures,someserverbasedothersbeingP2P.ExamplesincludeHypercat,AlljoynandConsul.

Modularity iswhenacomponentisadistinctunitthatcanbecombinedwithothercomponentsorremovedcleanlyfromthesystemandreplacedwithanothermodulewhichoccupiesthesamespaceandconformstothesamephysicalandlogicalinterfaces.

Modularity allows components to be combined in different configurations to form systems asneeded. By focusing on standardized interfaces and not specifying the internal workings of eachcomponent,implementershaveflexibilityinthedesignofcomponentsandIoTsystems.

AnexampleofModularityinanIoTsystemmightbeasmartthermostat.BecausetheinterfacetoanHVAC systemand the interface to a larger IoT infrastructure could both be defined in compliancewith open interface standards, there is nothing to prevent a thermostat from Vendor A beingreplacedbyonefromVendorB.Furthermore,itisnotimportanthowthefunctionalityofthedeviceisimplemented.VendorAmightprovidethecapabilityintheformofanASIC-basedstatemachine,whileVendorB’sdesignmightbebasedonamicrocontroller.As longasbothdevicesperformthesame functions in response to the same inputs, and they are both compliantwith open standardinterfaceswithoutimposinganyproprietaryconstraints,thereisnothingtopreventonefrombeingreplacedbytheother.


Public

Network connectivity– In IoTsystems,componentscommunicatewitheachotheracrossnetworklinks. The connections between components are established using eitherwired orwirelessmedia.Networked IoT devices that originate, route and terminate communications are described as(network)nodes.Endpointnetworkdevicesarethesourceordestinationofanykindofinformation.AnyIoTrelatednetworkingcommunicationsprotocolislayeredontomorespecificormoregeneralcommunications protocols, down to the physical layer that directly deals with the transmissionmediaateverynetworknode.

IoTsystemsrelyontheabilitytoexchangeinformationinastructuredmannerbaseduponmultipledifferentbutinterworkablenetworktopologies–allwithinaphysical,wiredorwirelessnetwork.IoTdevicesarecalled“networked”whenonedeviceisabletoexchangeinformationwithotherdeviceswhetherornottheyhaveadirectconnectiontoeachother. IoTnetworkstructurecanbestaticordynamic and may have capabilities such as QoS, resilience, encryption, authentication andauthorisation.

The scale of an IoT network can vary substantially, from local proximity networks connecting ahandfulofdevicesovera limiteddistance,toglobalscalenetworksoperatingat Internetscaleandconnectingverylargenumbersofdevicesandservicecomponents.

It is typical for thenetworks in IoT systems tobeheterogeneousandconnected toeachotherviagatewaysorequivalentcomponents.

Shareability is the ability to share the use of an individual component between multipleinterconnectedsystems.

Many IoT components are underutilized since a single system often uses only a fraction of acomponent’scapabilities.Resourcescanbeusedmoreefficientlyifthefunctionalitiesoroutputsofcomponentscanbesharedamongmultiplesystems.

Themotion detection capabilities of a lighting control system could be leveraged by the securitysystemtoincreasethesecuritysystemscapability.

Temperaturesensingforheatingcontrolcouldbeusedbythesecuritysystemforfiredetection.

Unique identification is the characteristic of an IoT system to unambiguously and repeatedlyassociate theentitieswithin thesystemwithan individualname,code, symbol,ornumber,andtointeractwiththeentities,ortraceorcontroltheiractivities,byreferencingthatname,code,symbolor number. These entities include the components of the IoT system itself, such as the softwarecomponents,thesensorsandactuatorsandthenetworkcomponents.

It isessential that theentities inan IoTsystemcanbedistinguished fromeachother.ThisenablesinteroperabilityandglobalservicesacrossheterogeneousIoTsystems.Itisimportantforentitiestobeuniquely identifiablesothat IoTsystemscanmonitorandcommunicatewithspecificentities.Avariety of identification schemesmay be supported in specific implementations of IoT systems tomeettheapplicationrequirements.

IPv4,IPv6,URI,andFQDNsareusedasunique,unambiguousidentificationofnetworkendpointsininternet applications. Individual hardware devices, software etc.may have uniquemanufacturer’sIDs,OIDs,UUIDsorother identifiers,which similarlyallowunique,unambiguous identificationandcanbeusedtotagdatafromthoseentitiesordirectcommandstothem.

PhysicalentitiesareoftengivenuniqueidentifiersintheformofRFIDtags,barcodesandequivalentlabelling technologies. For humans, biometric information can be used to provide uniqueidentification.


Public

Ownership – Asset management, according to ISO 55000, is the "coordinated activity of anorganizationtorealisevaluefromassets”,whereanassetisdefinedtobe“…anitem,thingorentitythat has potential or actual value to an organization.” Management implies responsibility andownership.

From ISO17799: “The asset owner is the personor group of peoplewhohavebeen identified bymanagement as having responsibility for the maintenance of the confidentiality, availability andintegrityofthatasset.Theassetownermaychangeduringthelifecycleoftheasset.Theownerdoesnotnormallyornecessarilypersonallyowntheasset. Inmostcasestheemployingorganisation, itscustomersorsupplierswillbetheentitywithpropertyrightstotheasset.”

Ownership is also compassable. For example, an operational assetmay incorporate assemblies orsubassemblies that have different owners, but work in conjunction with each other. Using theconceptofdomain, ISO27001:2005states that the“…typicalobjectivesof theassetmanagementdomain is to identify and create an inventory of all assets, establish an ownership on all assetsidentified, establish a set of rules for the acceptable use of assets, establish a framework forclassification of assets, establish an asset labelling and handling guideline.” An assetmanagementdomainrepresentsaboundarywhereresponsibilitymaytransferfromoneownertoanother.

Legacy support is the concept that an IoT system might need to incorporate existing installedcomponents even where these components embody technologies that are no longer standard orapproved. A service, a protocol, a device, system, component, technology, or standard that isoutdatedbutwhichisstillincurrentuse,mayneedtobeincorporatedintoanIoTsystem.

Supportoflegacycomponentintegrationandmigrationcanbeimportant,althoughwhensupportinglegacycomponents, it isalso importanttoensurethatthedesignofnewcomponentsandsystemsdoes not unnecessarily limit future system evolution. To prevent prematurely stranding legacyinvestment, a plan for adaptation andmigration of legacy systems is important. Care ought to betakenwhenintegratinglegacycomponentstoensurethatsecurityandotheressentialperformanceandfunctionalrequirementsaremet.Legacycomponentsmayincreaseriskandvulnerabilities.Sincecurrenttechnologybecomeslegacytechnologyinthefutureitisimportanttohaveaprocessinplacefor managing legacy aspects of IoT. The different lifecycles of physical systems and informationsystemsalsocreatesadditionalchallengesformanaginglegacyaspectsinIoT.

OneexampleoftransitionfromlegacytofuturecompatibilityisthecurrentslowrolloverfromIPv4compliance to IPv6 compliance. The limits of the IPv4 address space and of the IPv4 protocol areknown, and the transition to IPv6 is clearly the way of the future, but the varying pace of thetransition,dependingonthecontext,makesitatopicwhichcanbeverycomplex.

ManyexistingstandardsandapplicationenvironmentsstillassumeanddependonIPv4,andyetit’sclearthatcontinuingtouseIPv4foreverisnotaviablestrategysincethereareinsufficientaddressesandrunningmultipledevicesbehindasingleIPaddressisnotalwaysappropriate.Decidinghowandwhentomakethetransition,however,isatopicthatnobodyhasauniversalanswerto.

Well-defined components – IoT entities are deemed to be well-defined when an accuratedescription of their capabilities and characteristics is available, including any associateduncertainties. Capability information includes not only information about the specific componentfunctionality,butconfiguration,communication,security,reliabilityandotherrelevantinformation.

Many components are used to assemble an IoT system. They are typically discovered through aninformationsystem interface. Withoutunderstanding thecapabilitiesofeachcomponent thatwillbeusedwithinasystemitisdifficulttounderstandwhetherthesystemmeetsitsdesigngoals.

An example of an implementation of awell-defined component is: A particular IoT component isavailablewith varying amounts ofmemory or support for various RF frequencies, waveforms and


Public

protocols.Suchadevicehasabaseline information interfacewhichall thevariantsmakeuseof toinformother IoT componentsof the listof capabilitiespossessedby thedevice.Once thedevices’respectiveconfigurationshavebeenexchanged,eachdevice’ssoftwareorapplicationscanthenself-adjusttotakeintoaccountthecapabilitiesoftheotherdevices.

Flexibility isthecapabilityofanIoTsystem,service,deviceorothercomponenttoprovideavariedrangeoffunctionality,dependingonneedorcontext.

Historyandexperience tellus thatwhile thereareexceptions, theeconomicand functional sweetspot for flexibility isusuallysomewhere inthemiddle,betweentheextremesofadedicatedsinglepurpose component on one end of the spectrum, and a massively capable, programmable,extensible,“allthingstoallpeople”generalpurposecomponentattheotherend.

It is possible to break down the general concept of flexibility into different sub-categories ordimensions.

OnedimensionofflexibilityisthedistinctionbetweenIoTcapabilitieshostedonaplatformpoweredby a general purpose computing core and a similar capability implemented in the form of statemachines implemented using discrete components, programmable FPGAs, or a purpose-specificASIC. The statemachine versions tend to be smaller, faster,morepower efficient, andpotentiallymore secure (due to a more limited range of capability). The general purpose version trades offspeed,size,powerconsumptionandothertraitstogainmoregeneralizedcapabilities,andagreaterabilitytoadapttomeetunanticipatedfuturerequirements.

A second dimension of flexibility is illustrated by the distinction between the following kinds ofdevice:

1) A device which has fixed, nonprogrammable, non-extensible functionality – “hard wired,singlepurpose”.

2) AdevicewhichhasfixedH/Wcapability,butwhichprovidessomeamountofconfigurabilitywithinthesingleavailableformat.

3) A devicewhich is both programmable and expandable in the hardware domain – such asaddingmemory,addingmorecomputationalcapabilityoraddingRFchannelcapability.

4) Afamilyofdevices,eachofwhichmightfallintocategories1-3,fromwhichanintegratorcanselecttheones)whichareappropriateforagivencontext.

5) A family of devices such as in 4,where someof the options provide different amounts ofcomposabilityormodularity,atdifferentlevelsofabstraction.

A third dimension of flexibility might involve the range of standards, protocols, formats, andinterfaces which an IoT component is designed to support, where that support might then bedesignedandimplementedtakingthefactorsaboveintoaccount.

Aside from the IoT component, there is another dimension of flexibility that involves the overalldesign of the IoT system. As in other domains, there will likely be open IoT ecosystems, andproprietaryIoTecosystems,withvaryingamountsofoverlapbetweenthetwo.

An example of differences regarding flexibility in the context of a sensor device is such as athermostat. The simplest devices may only offer simple temperature control and reporting oftemperature.Moresophisticatedandflexiblethermostatsallowforremotecontrolviasmartphone,canbeconnectedtootherIoTdevicesinthebuildingtodetectoccupancy,togaininformationabout


Public

theweatherandsoon–andthesemorecapabledevicestypicallyhavesoftwarecomponentsthatcanthemselvesbeupgradedtooffernewercapabilities.

ManageabilityaddressesaspectsofIoTsystemssuchasdevicemanagement,networkmanagement,systemmanagement,andinterfacemaintenanceandalerts.ManageabilityisimportanttomeetIoTsystem requirements. Components capable ofmonitoring the system and changing configurationsareneededformanageabilityoftheIoTdevice,networkandsystem.

ManyIoTdevices,networks,andsystemsareunmannedandrunautomatically.Specialcaremustbetakentoensurethatsuchsystemsremainmanageableevenwhenpartsofthesystemmalfunction,become unstable or mis-calibrated in the course of operation. Even in circumstances whereindividual IoTentitiesareaccessible,thepotentially largescaleandgeographicspanofIoTsystemsargues for the ability tomanage IoT entities remotely to the greatest extent possible, to increasebothconvenienceandoperationaleffectiveness.

IoTdevicessuchassmokesensorsaredeployedinvarious locations inbuildings.Thesedevicesareoftenhardtomaintainbecauseoftheir locations.Anytypeofmalfunctioncouldcauseundesirableeventsandconsequences.Thus,remotemanageabilityshouldbeasystemdesignconsiderationandgoal from the beginning of specification, and throughout the development, and deployment, andoperationallifecycleoftheIoTsystem.

Additionally, software updates are necessary to ensure that devices and systems maintainfunctionalityandthelatestsecurityvulnerabilitiesarepatched.ThemanageabilitycapabilitiesofanIoT entity might include device state monitoring capability, the link monitoring, calibration, etc.Update servers should be able to authenticate the IoT component and vice versa (i.e., mutualauthentication).Updatesshouldbedigitallysignedtoensureitsauthenticityandintegrity.Updatesshouldbetransmittedoverasecurechannel,wherepossible

Inthecontextofreliability,accuracy isthecapabilityofanIoTdevice,serviceorsystemtoprovidesensoroutputcalculationsoractionswithintheexpectedrangeofacceptableprecision inabsoluteterms,relativeterms,orboth.

An appropriate level of accuracy is essential to some IoT system deployments and applications.Dependingonthecontext,differingdegreesofaccuracymightberequired.

Inamedicalormanufacturingcontext, itmightbecritical foran IoTDevice,applicationor systemproviding temperature information or control to be accurate to within a tenth of a degreeFahrenheit, while in a home HVAC context, accuracy to plus or minus two degrees might beadequate.

Reliability is the trait of a system exhibiting consistent behaviour – preferably the intendedbehaviour.Anappropriatelevelofreliabilityincapabilitiessuchascommunication,serviceanddatamanagementcapabilitiesisimportanttomeetsystemrequirements.

An appropriate level of reliability is essential in diverse IoT systemdeployments and applications.Reliability can be highly critical in some applications, e.g. for specific health related applications,industrialmanufacturingoperationsandtime-criticalapplications.

Reliabilityofdataisofgreatimportanceforthedecision-makingprocessesofmanyIoTsystems.Theabsenceofdataordatacorruptioncanleadto incorrectdecisionsorthefailuretomakedecisions.Reliability of communications networks is important for ensuring the availability and correctoperationofIoTsystems,particularlyinmission-criticalusecases.


Public

Medical devices are one potential IoT application area where the specifications for mean timebetween failuremightbequite stringent,due to thepossibilityof injuryordeath if an IoTdevice,applicationorsystemprovidingmedicalcapabilityweretofailwhileapatientisbeingtreated.

Resilience is the ability of an IoT systemor its components to continue to perform their requiredfunctioninthepresenceoffaultsandfailures.

Communication, device or software component failures are to be expected in IoT systems andwithout appropriatedesign, they can escalatequickly causing the global failure of the system. IoTsystemsneedtobedesignedforresilience,incorporatingself-monitoringandself-healingtechniquestoimprovethesystemresilience.

An IoT system has to be resilient to gateway failures to ensure continuing communications pathsbetweensoftwarecomponentsandIoTdevices.

One approach to resiliency is to adopt amaster-slavedesignwhere if themaster unit fails then aredundantdeviceisavailabletoassumethemasterrole.

Fornetworks,ameshnetworkdesignisresilienttothefailureofonelinkoronenode-datacanstillflowfromsourcetosinkthroughanalternativeroute.

Security – Availability is the ability of a system to be accessible and usable on demand by anauthorizedentity.IoTsystemscanincludebothhumanusersandservicecomponentsas"authorizedentities".

InIoTsystemsavailabilitycanbeseenintermsofdevices,dataandservices.Availabilityofadeviceisrelated both to its inherent properties of operating correctly over time and to the networkconnectivity of the device. Availability of data is related to the ability of the system to get therequesteddatatoandfromasystemcomponent.Availabilityofservicesisrelatedtotheabilityofthesystemtoprovidetherequestedservicetouserswithapre-definedQoS.

Insomecriticalapplications,e.g.healthmonitoringorintrusiondetection,devicesanddatahavetobe always available so that alarms can be sent to the system immediately when raised. In thesecases, system design must take into account potential failure modes and provide means ofcontinuing operations, such as power supply backups, redundant devices, multiple instances of aservice.

Confidentiality istheproperty,that informationisnotmadeavailableordisclosedtounauthorizedindividuals,entities,orprocesses.

Inan IoTsystemconfidentialityprotectionpoliciesandmechanismsare responsible forprohibitingpeopleorsystemsfromreadingdataorcontrolmessageswhentheyarenotauthorizedtodoso.

Confidentiality isapre-requisiteforasecureoperationespeciallywhenthedatatobetransmittedcontains secret tokens, e.g. for access control. Confidentiality is also required to protect sensitivedata,whichmayincludePII(e.g.financialinformation)orpersonaldata(seetheclauseonPrivacy).

Many itemsofdataflowingan IoTsystemneedtobetreatedasconfidential– inthehandsofthewrongrecipientthedatacouldbeusedforcriminalactsorrepresentinappropriateuseofpersonaldata.Forexample,IoTmotiondetectionsensorscouldrevealwhetherapropertyisoccupiedornot–whichcouldbeusedbythievestotargettheproperty.

Similar concerns relate to IoT smartmeters –where even the frequency ofmessages transmittedshould not depend on the rate of electricity use, since this could reveal whether a property isoccupiedornot.


Public

Data integrity is theproperty thatdatahasnotbeenalteredordestroyed inanunauthorizedandundetected manner. [ISO_19790:2012, 3.58] Given that data is the basis on which IoT systemsoperate, tampering or destruction of data flowing or stored in the system could compromise theoperationofthesystemandleadtohighlyundesirableoutcomes.

Dataintegrity isvitalforIoTsystemstoensurethatthedatausedfordecision-makingprocessesinthe systemandexecutable softwarehas not been alteredby faulty or unauthorizeddevices or bymalicious actors. The protection of the integrity of the data and the executable software is a keyrequirementtoensurethesecurityoftheIoTsystem.

In IoT deployments that comprise of multi-hop wireless sensor networks there is a risk thatintermediatenodesmayalter thedataandthiscanhave impactonthe functioningof thesystem.Forexample, an intermediatenodemay increase thevalueof the temperatureof a roombut thisshouldnotcausetheair-conditioningsystemtoincreasetheamountofcooling.

Safety is the freedom from risk which is not tolerable. Risk is the combination of probability ofoccurrenceofharmandtheseverityofthatharm.Harmincludesinjuryordamagetothehealthofpeople, or damage to property or the environment. Harm can be due to malfunction, failure, oraccident.Whilepriortraitsdescribethedesiredbehaviourofthesystemwhenoperatingcorrectly,Safety includes the consideration of failure modes with the intent of preventing, reducing ormitigatingthepotentialforundesiredoutcomes;specifically,damage,harmorloss.

ManyIoTsystemsaredeployedincontextsoroperationalenvironmentswheredamage,loss,injuryordeathmightresult if failuremodesarenotadequatelyaddressed. Inmanyoperationalcontexts,approvaltooperateorapprovaltoconnectwillnotbegrantedifsafetyrequirementsarenotmet.

Even in contexts where compliance with safety standards is optional or voluntary rather thanmandatory,proper considerationof safety factorsmayhave significant impactonaspects suchas:continuityofoperations,reductionofloss,preventionofinjuryordeath,insurancepremiums,tortsandliability,andotherissues.

IoTcontextswheresafetystandardsorrequirementsmightneedtobeconsideredincludemedicalorhealthcareapplications,transportsuchasaviationandautomotiveapplications,consumerproducts,buildings,andenvironmentmonitoring.Manycountrieswillhavespecificregulationsrelatedtosuchapplications.

Protectionofpersonally identifiable information (PII) isa legalor regulatory requirement inmostjurisdictions whenever an IoT system involves personally identifiable information anywhere in itsoperation.

Privacy is the rightof individuals tocontrolor influencewhat information related to themmaybecollected and stored and by whom and to whom that information may be disclosed. (Based onISO/TS17574:2009, 3.16) The conceptof privacyoverlaps, but doesnot completely coincide,withtheconceptofdata.WithrespecttodataprotectionitensuresthatPIIisnotprocessedwithouttheinformed consent of the, individual, unless otherwise permitted by law, and is not and is notdisclosed to unauthorized entities. For IoT systems, entities include both people, machines andprocesses.

TheprincipleofdataminimisationappliestoPII:thequantityofPIIcollectedistheminimalnecessarytosupporttheapplication.ThePIIwhichisnecessarilypresentshouldbesecurelydeletedwhennolongerneeded.ThisprotectstheindividualandminimizeslegalrisktotheorganizationusingthePII.If PII is disclosed it must be based on prior informed consent given by the PII principal for theintendedpurpose.


Public

Meta-datamay includePII. Assuch,organizationsprocessingsuchdatamust takesteps toensurethat any such processing conforms to applicable privacy/data protection legislation or regulation.Thisincludestakingstepstoensurethatallsuchdataisadequatelysafeguarded

Many IoT systems do not collect or interchange PII. However, any IoT systemwhich does collect,receive and/or interchange personal information needs to ensure that such IoT systems and theirinteractions with other IoT systems (or IT systems in general) are in full compliance with privacyprotectionrequirementsofapplicablejurisdictionsdomains.

OneaspectofIoTsystemsisthatthenatureofthedatahandledbythesystemcanbeunclear.Forexample,ahomeautomationIoTsystemmayappeartobedealingindatathatisnotPII,butif(say)theelectrical usagedataof ahouse is present in the system, if thedata canbe connectedwith aspecifichouse,itislikelythatthedataisconnectedwithspecificpeopleandcanberegardedasPII.

IoTsystemsneedcarefulanalysistounderstandifanyofthedatatheyhandleisorispotentiallyPII.If PII is present, then the IoT system must be designed to meet appropriate data protectionregulationsandlawsintherelevantjurisdiction(s).

Many IoT applications involve end-users and the collection of specific data relating to them. Forexample,trafficspeedcamerasrecordanumberplateandoftenanimageofthedriver’sface.Thisinformation is correlated with licensing records to allow fines to be levied. However, such datacannotberetainedbeyondapre-definedtimeandshouldnotbemadeavailableforotherpurposes.Mobilephonelocationcanbetrackedandwhilethiscanbeusefulforausertoreceiveinformationaboutfacilities inthearea,accesstosuch informationshouldbecontrolled; itmayberequiredforpoliceinvestigationsbutusersmaynotwanttoreceiveadvertsforlocalvenues.

Inparticular,withhealthcaremonitoringandothersuchmonitoringofspecificindividualsthereisaneedforthedatatobeprovidedonlyfortheagreedpurposeforexampletoupdateaGPorpersonalhealthcarerecordandnotforusebyotherinstitutionssuchasinsurancecompanies.

Driver may be providing data for traffic monitoring systems (location and speed) allowing trafficcongestiontobereportedbutwouldnotnecessarilyexpectthisdatatobelinkedtoanemployer’ssystem.Similarly,trackingpeoplemovement inofficesmaybepossiblewithabuildingsurveillanceandaccesssystembutnotingtimesofrestbreaksetc.,maynothavebeenpartofthepurposeofthedatacollection.

Smartmeteringapplicationsareanotherexamplewhereanindividualmaygrantaccesstodataforaparticularpurpose.Thesmartmeteriscollectingreal-timeinformationaboutelectricityusageinthehomeand transmitting it to theelectricityutility,whomayuse thedata foravarietyofpurposes,includingdemandmanagementanddifferentialpricing.Itisclearthatthedatarelatestothepeopleliving in that home and may reveal significant details about their lives. It is necessary for theelectricityutilityorganizationtoinformthehouseholderaboutthePIItheyaregatheringandtobeclearaboutitsuse.Theelectricityutilityalsoneedstoapplyappropriateprotectiontothedata(e.g.encryptdatastreamsflowingfromthesmartmeter),andapplyprivacyprinciplestotheprocessingof thedata, includingminimising thedata, anonymizing thedataanddeleting thedataas soonaspossible.

SeveralgovernmentsandgroupofstateshasissueslawsbasedontheEuropeandirective2016/680onPrivacy,especiallytoprotectcitizensfromtheincreasingexposuresoftheirPIIinthedailydigitallifeonthenet.AsetoflawstobeimplementedtoproviderulesforthebusinesshowtohandlePIIandmakeitcertainthatPIIisnotexposedmorethanthebusinessrelationrequires.

Other characteristics – The "Data 5Vs" of volume, velocity, veracity, variability and variety oftenapplyto IoTsystems.TheData5VsderivefromBigDatasystems–but it isoftenthecasethat IoT


Public

systems are the source of datawhich is large in volume, delivered at speed across network links,whoseveracityneedstobevalidated(e.g.duetomalfunctioningsensors),whichcanvaryovertimeandcancontainawidevarietyofdifferentdatatypesfromdifferentIoTcomponents.

IoTSystemsarealsoexpected togenerate largeamountsofdata fromdiverse locations.Thedatamaybeaggregatedintocentralizedlocationsoritmaybestoredindistributedlocations(dependingon the nature of the data, the processing required on the data and the communication linkcharacteristics),whichgeneratesaneedtoappropriatelyindex,store,processandsecurethedata.

A logisticscompanyusesbigdataanalytics foranOn-Road IntegratedOptimizationandNavigationservice.Thesystemusesnumerousaddressdatapoints,plusotherdatacollectedduringdeliveries,tooptimizedeliveryroutes.

Heterogeneity –An IoT system typically is composedof a diverse set of components andphysicalentitiesthatinteractinvariousways.

IoT is typically cross-system, cross-product, and cross-domain. Realizing the full potential of IoTrequires interoperability between heterogeneous components and systems. This heterogeneitycreatesnumerouschallengesfortheresultingIoTsystems.

AsmartcontainerusingRFIDtagsfor identityandrelatedRFIDsensorsneeds interworkingofRFIDsystemsandsensornetworksystems.

Regulatory compliance – IoT systems, services, components and applications can be deployed incircumstanceswhich require adherence to a variety of laws, policies or regulations. Such supportmightbeinherentintheIoTdeviceorsystem,ormightrequirespecificconfiguration,programming,modificationorextensiontoensurecompliance.

Additionally, theremight be a range of different granularity or levels of abstraction at which theregulationsareappliedorenforced.

Regulations of relevance to IoT systems might take many forms, including regulations to assureinteroperability, tomandateor constrain functionalityor capability, toassess theabilityof the IoTdeviceorsystemto function inacertainusagecontextwithoutcausingdamage,andto imposeatleastminimalbalancebetweencontribution to the collectivegoodand self-intereston thepartofsystemownersoroperators.

RegulationswhichmightapplytoanIoTcontextincludeoneormoreofthefollowingcategories:

1) Safetyregulations–Thesemight includeflightsafetystandardsforIoTdevicesoperatinginaircraft,orregulationscoveringthemanufactureandsaleofdevicesintendedforconsumeruse inthehome,regulations forautomotivesystems,orregulations fordevicesorsystemsusedinamedicalcontext.

2) RF related regulations – This category might include national or international regulationsgoverning RF emanations, adherence to frequency band restrictions, signal strength,spurioussignals(suchassidechannels,noise,orharmonicsproducedoutsideofthedevice’snominalfrequencyallocation),etc.

3) Consumerprotectionregulations–ThesemightincludenationalandinternationalregulationsinvokedwheneveranIoTsysteminvolvesaconsumeranywhereinitsoperation.

In some IoT contexts, suchashomeautomation,HVAC,etc. another layerof regulationsmightbeimposedintheformofbuildingcodesinvariousjurisdictions.


Public

While the area is still developing, it is quite possible that at somepoint, therewill be regulationsimposedor referencedby insurancecompaniesaspartof their riskmodels forpricingcoverageofstructures,vehicles,systems,orbusinessesincorporatingIoTsystemsanddevices.

Scalabilityisthecharacteristicofasystemtocontinuetoworkeffectivelyasthesizeofthesystem,itscomplexityorthevolumeofworkperformedbythesystemisincreased.

IoTsystemsinvolvevariouselementssuchasdevices,networks,services,applications,users,storeddata,datatraffic,eventreports.TheamountofeachoftheseelementscanchangeovertimeanditisimportantthattheIoTsystemcontinuestofunctioneffectivelywhentheamountsincrease.

One example of scalability is when the number of sensor devices attached to an IoT system isincreased. If a system changes from monitoring temperature sensors in a single building tomonitoring temperature sensorsonall buildings ina city therewill bea significant increase in thevolumeofsensordataflowinginthesystem,inthevolumeofdatabeingstoredindatabases,inthenumberofdeviceshandledbythemanagementsystem,andinthenumberoftemperaturereadingsprocessedbyservicesandapplications.

Trustworthinessisthedegreetowhichauserorotherstakeholderhasconfidencethataproductorsystemwillbehaveasintended.

Device,dataandservicetrustworthinessisofutmostimportanceforIoTsystemstoensurethatonlytrusteddevicesparticipateinthedecision-makingprocessofthesystem,resultingintheprovisionoftrustworthyapplications.Deviceexecutableprocessesanddatamustbetrustedtoensurethatthedevice/systemoperatesasintended.

Devices may become untrusted due to compromise, outdated software or firmware, or otherreasons. IoT systems must be able to identify untrusted devices and must implement policies,processes, procedures and/or mechanisms (e.g., quarantine) to address the issue of untrusteddevicesonthesystem

Where an IoT system that monitors the averagemeasurement of a room taking the mean valuereportedbyxsensors, ifysensorsreportfalsevalues,duetoafaultormaliciousprogrammingtheresulting mean measurement will be false. Detection, assessment and potential exclusion ofanomalousreadingsisnecessarytoensuretrustworthydata.


Public

AppendixC. Register

Auto-configurationofVICINITYNode,40

Configurationdataflows,28

Globalneighbourhoodstorage,32

High-availabilityplatform,78

IoTobjectdescription,35

IoTobjectmetadata,36

IoTobjecttemplates,36

IoTobjects’access,25

IoTobjects’discovery,23

privacyfilter,64

profile,32

Semanticdataflows,28

Semantic discovery and agent configurationplatform,21

SemanticdiscoveryofIoTobjects,42

Semanticmeta-models,35

Semantic Model and Agent ConfigurationStorage,32

SharingAccessRules,34

Syntacticdataflows,28

ThingDescription,23

ThingEcosystemDescription,23

VICINITYCloud,16,17

VICINITYCommunicationNode,22

VICINITYCommunicationserver,21

VICINITYGatewayAPI,22

VICINITYGatewayAPIServices,21

VICINITYNeighbourhoodmanager,21

VICINITYNode,17

VICINITYNodeconfigurationdistribution,41

VICINITYNodes,16

VICINITYNodesConfigurations,34

VICINITYP2Pnetwork,18

VICINITYsemanticmodel,36

virtualneighbourhood,16

VirtualTED,23

vicinity d1 6 architectural design 1.0

Documents