arXiv:1803.06854v2 [cs.NI] 15 May 2018 favrial nertd n-oedITsno applicat sensor te IoT field end-to-end C (on-going) integrated, the recent vertically on by a insights activities of provide SmartCity and third on Hamburg And report of architecture. event platform case-study IoT inner-city a its we provide public, on Second, at overview environment. an deployments give City IoT demonstratio Smart for large-scale aims a which of MONICA foster project standar EU to the network introduce help and technologies can platforms, that IoT of number a iygvrigatvte.I mr iy h integration the city, smart a supp In to activities. interact practices that governing information policies, city represent and people, norms instance, social technologies, processe for sources, of decisions Governance, optimise collection Smart will intelligent a [2]. that more results actions make and and people alternatives advanced help and about world IT-systems to physical the provide analytics of that awareness real-time hardware technologies integrated with network of and generation new software smart a (ICT): to Technology refers Communication computing and Information find is to plannin liveable. sustainably urban need cities for projects future e.g., make City solutions, that Smart innovative and and end, economic advanced that to To space; integration. scar living resource instability, and price unemployment, transport societal: specific [1], of he waste, The populations lack and phenomenon. pollution issues, urban air wide physical: the from world range of a challenges is increase urbanisation rapid this the is century ehooiswl ea nerlpr n e nbe oachi vision. to City enabler Io key Smart Thus, and the (IoT). part of Things objectives integral of many an Internet be the numero will as integrate known technologies – widely infrastructure and city also deploy the is throughout to actuators inter-con also and to sensors but communication network authorities; utilise public to are infrastruct ideas and mea administration Key by urban i effects improve City to their Smart ICT mitigate modern a and of problems goal these primary counteract The threats. urb century security chan to and climate engagement, ning, 21st t citizen from by and range the transportation, standards challenges pollution, living in These on population. demands challenges urban increasing management to due new primarily face world n ftekyscesfcoso mr iymissions City Smart of factors success key the of One twenty-first the in cities modern of problem general A h otiuin fti ae r sflos efis exami first We follows. as are paper this of contributions The Abstract eata Meiling Sebastian ag-cl o elyet naSatCity Smart a in Deployments IoT Large-Scale Mdr iisadmtooia ra l vrthe over all areas metropolitan and cities —Modern ‡ gnyfrGonomto n uvyn,Fe n Hanseati and Free Surveying, and Geoinformation for Agency ∗ { .I I. eata.eln,t.schmidt sebastian.meiling, ∗ OIAi abr:Towards Hamburg: in MONICA oohaPurnomo Dorothea , NTRODUCTION † eaeCacley readHnetcCt abr,Germa Hamburg, City Hanseatic and Free Chancellery, Senate ∗ NTR,HmugUiest fApidSine,Germany Sciences, Applied of University Hamburg RG, iNET ‡ { oohaproo michael.fischer1 dorothea.purnomo, ‡ ui-n Shiraishi Julia-Ann , } @haw-hamburg.de, nplan- an iyand city ion. which and s sof ns re- , nect we , ure. alth to s eve ort ge, sts ity ne he ds us of g, T n s s , .ITAcietrsadPlatforms and Architectures also IoT that A. robustness. be but and environments, to scalability constraint for designed allow such specifically with technologies compliant dedicat requires and IoT the architectures Hence, wireless standards. uti on radio devices low-power based constraint communication resource machine-to-machine embedded, ising of world the into opnnst mlmn etclyitgae,satIoT smart integrated, vertically The implement services. softwar to and APIs originated standardised components on EU based cloud- platform an enable source open is to FIWARE middleware “Sensing-as-a-Service”. source based open an provides which ltom n etesudracmo ontology. common a existing under federates testbeds and and platforms experiments IoT for infrastructure u—o h iyo abr.I eto erpr on report we work. Hamburg, V ongoing in Section is performed also In tests data which integration Hamburg. large- open and of central deployment for City —the Smart IoT the platform Platform on of Urban overview IoT the hub— an and open gives efforts IV an City Section of deployments. architecture objective scale its the MONICA, project EU and the technologi introduces and III platforms IoT Section enabling City Smart of variety challenges. aforementioned the wil address and to innov vision enable solutions to City infrastructures Smart urban existing the complement into such fit As generally applications. technologies and sensor services new i.e., enable devices, to actuators, inter-connected with real-world the administratio energy, of security. fields and mobility the health, city’s bas in the a is solutions infrastructures innovative into and systems technologies technical different communication and information P)i obidassanbeITeoytmi uoeand Europe in instance, IoT-ecosystem For platforms. sustainable of a interoperability for build aims to is EPI) 1 h nento hns(o)etnstetaiinlIntern traditional the extends (IoT) Things of Internet The h olo the of goal The h ae ssrcue sflos nScinI erve a review we II Section in follows: as structured is paper The enhance to is [3] (IoT) Things of Internet the of idea key A http://www.openiot.eu † † ihe Fischer Michael , [email protected], } @gv.hamburg.de I B II. FIESTA-IoT CGON AND ACKGROUND iyHmug Germany Hamburg, City c o-uoenPafrsInitiative Platforms IoT-European 8 Upoetpoie middleware provides project EU [8] ‡ n hmsC Schmidt C. Thomas and , ny R ELATED W ORK Open-IoT and s sfor is ∗ (IoT- ative IoT IoT es. ed n, et l- e 1 s l , The AIOTI High-Level Architecture (HLA) [4] is a function IoT (NB-IoT). These standards typically provide only limited model for an IoT architecture composed of three main layers: bandwidth compared for instance to WiFi, i.e., an IEEE application, IoT, and network layer. The HLA describes func- 802.15.4 frame has a size of up to 127 bytes. To transparently tions and interfaces for entities within a layer, but also the inter-connect the IoT with the common Internet, it needs interaction between layers. However, the AIOTI HLA does to utilise the Internet Protocol on the network layer. With not stipulate details on implementation or deployment. The hundreds of thousands (even millions) devices in the IoT, Open Geospatial Consortium (OGC) defined the SensorThings IPv6 is the only option, but is also challenging considering API [5] which is an open standard and geospatial-enabled 128 bit addresses and a minimal MTU of 1280 bytes. To that framework to interconnect IoT devices, applications and data; end 6LoWPAN combines several techniques, such as generic addressing syntactic and semantic interoperability. Besides header compression and fragmentation to transparently cope a RESTful request/response architecture based on HTTP, with the IPv6 MTU, into an adaption layer to support IPv6 on the API also supports a publish/subscribe architecture using constraint networks and embedded IoT devices. To distribute MQTT. That may yield lower latency and allows for many- data in large wireless IoT networks it further requires a routing many distribution of sensor data similar to IP multicast. The protocol like RPL [13] to allow for multi-hop communication. OneM2M Functional Architecture (FA) [6] describes end-to- On the application layer CoAP [14] allows to implement end services based on functional entities and reference points. RESTful data transfer and services using a requests-response It is primarily service oriented, but remains independent of scheme similar to HTTP. CoAP supports a variety of data the underlying network layers. While it shares the overall formats (MIME) to encode message payloads, possible formats layered view of the AIOTI HLA, the oneM2M FA also are plain text, CBOR [15], JSON, and SenML [16], to name specifies distinct service functions for device management only a few. Unlike HTTP in the traditional Internet, CoAP and dedicated interfaces. The Web of Things Architecture uses UDP on the transport layer instead of TCP, which is not (WoT) [7] is an upcoming standard by the World Wide suited for constraint IoT networks due to its overhead. Web Consortium (W3C) that aims for interoperability across III. THE MONICA PROJECT IoT platforms. The W3C WoT specifies (RESTful) interfaces 3 to enable communication between devices and services in The MONICA project is part of the IoT European Large- 4 the IoT, independent of implementation and communication Scale Pilots Programme (LSP) and as such aims for large technologies. scale demonstration of an IoT ecosystem based on multiple To implement innovative IoT applications on a wide range existing and new IoT technologies for Smarter Living. of embedded devices and platforms it requires IoT operating A. Objectives and Scenarios systems [9]. The iNET research group co-founded and core- The focus of MONICA is on a key aspect of the European develops RIOT [10], a widely popular free open source oper- society: the cultural performances in open-air settings which ating system for the IoT. RIOT-OS2 is an open platform and create challenges in terms of crowd safety, security, and noise ecosystem for tiny devices [11], very similar to what Linux pollution. To that end MONICA utilises innovative wearables, is for standard computers. This ultra-lean OS supports most sensors and actuators with closed-loop back-end services inte- embedded, low-power devices, platforms, and various micro- grated into an interoperable, cloud-based IoT platform capable controller architectures (from 8 to 32-bit). Its key features are: of offering a variety of simultaneous, targeted applications (a) low memory footprint (few kBs), (b) tick-less scheduling to thousands of users. The MONICA IoT platform will be for near realtime and energy efficiency; (c) reduced hardware demonstrated by IoT applications addressing environmental dependent code combined with high level APIs; complemented and safety issues associated with large open-air events held in by (d) multithreading and (e) a flexible network stack. RIOT inner cities (e.g., concerts, funfairs or sports matches). Two aims to implement all relevant open standards —with focus main ecosystems will be implemented at large-scale: (a) a on network protocols— supporting an Internet of Things that Security Ecosystem and (b) an Acoustic Ecosystem. is connected, secure, durable, and privacy-friendly [12]. The The first will show how a multitude of innovative applica- development is driven by a growing international community tions for managing public security and safety can be seam- gathering companies, academia, and inventors. lessly integrated with numerous IoT sensors and actuators. B. IoT Technologies, Standards, and Protocols Major security and safety challenges at large inner-city events are the handling and mitigation of unforeseen incidents. This Besides architectures and platforms, there is also a need for includes personal violence, threats of terrorist attacks, panic network stacks that vertically combine protocols suitable for scenes, and severe illness of individuals in the middle of a the IoT. Over the last years many protocols were developed crowd. The MONICA IoT platform will collect and analyse and standardised that are specifically designed to cope with sensor data to enable decision support systems (DSS) and a constraint devices and low-power networks. On the physical common operational picture (COP). The Acoustic Ecosystem and link layer there are several low-power radio standards will demonstrate smart applications for managing open-air such as IEEE 802.15.4, LoRa, SigFox, and 5G Narrowband- 3https://www.monica-project.eu 2https://riot-os.org 4https://european-iot-pilots.eu music performances in urban spaces by seamlessly integrating MONICAArchitecture AIOTI IoT devices using the MONICA platform. The system will consist of a series of large and small applications that, in MONICA APIs Layer Application combination, can be used to monitor and manage the sound Services Layer Layer before, during, and after a performance. The main objectives are to demonstrate how the IoT platform supports closed loop Middleware (LinkSmart) solutions that address real-life environmental challenges such IoT Platform Connectors IoT Layer as the reduction of noise in public spaces close to open-air Adaption Layer (SCRAL) events. The two ecosystems are also connected; for instance an Edge Layer Network acoustic-based module may detect security related events such Network Layer Layer

as gunshot, scream, breaking glasses and approaching vehicles. Deployment + Monitoring Tools Security and Privacy Framework Moreover, the MONICA platform can be integrated with IoT Device Layer applications and resources from other Smart City platforms (e.g., the Hamburg Urban Platform) and external open data Fig. 1. Overview on layers of the MONICA Architecture and corresponding layers in the AIOTI high-level architecture specification. portals. To than end, MONICA aims for interoperability with other EU research projects and initiatives, such as AIOTI, IoT- EPI, FIWARE, Fiesta-IoT, Open-IoT, CRYSTAL and SOFIA. for services above. Moreover, it goes beyond the AIOTI specification by defining additional vertical layers, to ensure B. IoT Platform Architecture security and privacy but also to allow for monitoring. And The MONICA architecture comprises of the following sub- allows for dedicated IoT platform connectors to integrate the systems and layers, starting from bottom: MONICA IoT environment with external third parties and • Device Layer: includes all fixed and mobile IoT appli- services, for instance with existing platforms at a MONICA ances, such as wearables, sensors and actuators. pilot side (see also IV-B). • Network Layer: support heterogeneous IoT devices with different access networks standards, e.g., Wi-Fi, cellular IV. HAMBURG – SMART CITY AND MONICA PILOT SITE (3/4/5G), and low-power WAN (IEEE 802.15.4). With more than 1.8 million citizens the Free and Hanseatic • Edge Layer: consists of gateways to connect devices with City Hamburg is the second largest city in Germany, and the the MONICA backend and processing nodes for real-time heart of a flourishing metropolitan area in northern Germany. data. Within the MONICA project Hamburg and its local partners • Adaption Layer: provides technology independent man- participate as a pilot site to demonstrate large-scale IoT agement of resources and uniform mapping of data into deployments at popular inner-city events, namely the DOM standard representations, implemented by SCRAL. funfair and the annual Port Anniversary. • IoT Platform Connectors: handles communication and A. Overview on Smart City Activities data integration with external IoT platforms, e.g., exposes IoT data according to the OneM2M standard. It has been recognised that the digital transformation cannot • Middleware: provides storage and directory service for be outsourced or delegated. Instead, the transformation process registered resources; is implemented by LinkSmart. has to be exemplified by the city, the administrative body • Services Layer: provides service-specific data processing itself. The main goals of Hamburg’s development strategy are and sensor fusion, a common knowledge base, and deci- to improve the quality of life and to drive economic growth sion support tools. and the city’s economic attractiveness. To achieve these and • MONICA APIs Layer: comprises of distinct APIs for to address many of the city’s challenges, Hamburg pursues a public and professional (security) applications. clear strategy that is based on government-driven policies; one • Cyber Security and Privacy Framework: enables and of these is the 2015 Digital City Strategy. The main objective ensures trust-based communication, secure data flow and of this is to support and promote innovation that is based on storage across all components of the MONICA platform. technology and digitisation. In the framework of this strategy, • Deployment and Monitoring Tools: check and verify de- the exchange of data between municipal bodies, city systems, ployment of MONICA platform components periodically; and open data users plays a significant role, which is reflected also enable for performance measurements. by the Hamburg Urban Platform (cf. IV-B). From a Smart City perspective there are two focus areas Figure I shows the mapping of layers and components of the 5 MONICA platform and the corresponding layers in the AIOTI in Hamburg, namely: (a) Intelligent Transport Systems (ITS) , high level architecture. While the latter is independent of any which takes into account that environmental pollution, climate implementation, the MONICA architecture on the other hand change and sustainability initiatives are inherently linked to defines distinct software components that implement certain traffic. Hence, green traffic and ITS are among of the main functions of the platform, e.g., the LinkSmart middleware that 5The city of Hamburg will host the ITS World Congress in 2021 handles data storage, resource catalogues, and data provision http://www.its2021.hamburg . . e

7 rg or ve

ity, ral, ra ltomCore Platform Urban mat tform. Sensor B Authorization Management Sensor Management Interoperability is cru- Open Data Portal Sensor A ... and a system-of-systems approach to Adaptors 3rd Parties Applications 6 The open Hamburg Urban Platform fol- IoT Access Networks IELDTESTSANDEXPERIMENTS Web Services Modules CSV System B Connectivity – Standard APIs Data Warehouse Storage Espresso V. F XML sensors eGovernance Applications processing System A JSON data http://espresso-project.eu cf. Deliverable D2.16 of the EU H2020 project mySMARTLife. Fig. 3. Overview of the architecture of the Hamburg Urban Pla Parallel to the design process of the MONICA IoT platform 3) Interoperability and open APIs: 2) Architecture: 6 7 architecture, we starteddeploy at experimental an IoT early setupsbehind in stage this Hamburg. to The wastechnologies implement motivation to for and usage examineworld within scenarios, and and the how verify to MONICAUrban realise IoT project integration Platform of in and protocols the Hambu the real- and MONICA platform, later on. This allows dataopen consumers data for intoPlatform an uses their standard easy WebGIS Server systems integrationrequirements. Software to and of This fulfil thes applications. makes the choice the The to SensorThings handle Urban standard and API APIs provide a are real based suitable JSON time on data REST (spatial) formats and data. using SOAP These HTTP with or XML MQTT. and cial for the success of any Smart City infrastructure in gene and hence foritself. the The Urban Urban Platformdata Platform using of provides standardised the easy datadesign City ensuring formats access a of and reusable, to manufacturer-independent Hamburg APIs for existing with an open modules are substantiateddata by is the stored Data and Warehouse extracted where for the all different services. allow integration withThe heterogeneous core of systems thein data or five management platforms layer modules: (see DataProcessing Fig. Web 3) Services, Web is Metadata Services, divided WebServices. Services, Data While Analyticsextended the and regularly), former the Sensor latter Web four is under are development. The fully fi deployed (and lows the commonEU architectural Project framework developed in the availability of cityavailability of bikes parking at slots on the parking specific decks. bike stations, and also started to providedata near e.g. real time occupation information of from charging sens stations for electro mobil s d ia and 18, blic oud a to port. form e de- Datasets Usage cross opment internal , respectively. f millions web into , which include Year 850.000 request per day). Fig. 2 ≈ External Internal Public As of 2017 the Urban Platform provides more 2013 2014 2015 2016 2017 e-governance and citizen services 0 0

, i.e., web requests from city authorities and third parties 300 200 100

3000 2000 1000 on [#] Count 1) Dataset: The Urban Platform of the City of Hamburg is a conceptual more than 400 distinctmillion services requests which per receive year more ( than 310 than 3300 datasets, 93 applications in form of geo portals an measures to improve public information, electronic servic livery, citizen engagement, video crime monitoring, and pu security. The goal istransparent, to cost make effective the and city’s citizen-friendly. administration As more of 20 and planning, environment,standardised traffic. web These services are —withforming distributed APIs to and v OGC data specifications, e.g.,for models WFS, viewing, con- WMS downloading and and GML— processing of data. approach whichPlatforms follows [17] the andlogical EIP-SCC the architecture that initiative DIN integrates data SPEC of flows within 91357. and Urban a It implements a B. The Hamburg Urban Platform Hamburg established the Departmentwhich for is IT dedicated andsegregated topics to Digitisation in these theunder field efforts one of and authority. e-governance and combines Smart formerly City city systems and exploits modernservices, technologies mobile (sensors, devices, cl analytics, etc.). The Urban Plat of engaging andand serving non-open city data stakeholders.third of parties. It different It contains public holdsseveral open geospatial authorities categories, information e.g., as on education, well culture, urban urban as dat devel enables the Citydata silos of while Hamburgclusive, shifting to predictive, from and break fragmented efficient up operations operations the to and in- monolithic novel way shows the growth inmillions number per of datasets year) and over user the requests last (in 5 years. The urban platform Fig. 2.requests Available per public year) over datasets the and last 5 their years. Usage usage is (in broken down terms o topics of interestits around future. which Urban theparking, mobility City intelligent includes of trafficAnd concepts Hamburg management, plans (b) such integrated trans as smart external CoAP HTTP POST POST

Sensor App CoAP-to-HTTP Proxy RESTful API CoAP CoAP HTTP HTTP UDP UDP TCP TCP IPv6 IPv6 IPv4 IPv6 IPv4 IPv6 6LoWPAN 6LoWPAN IEEE 802.15.4 IEEE 802.15.4 Ethernet Ethernet

Fig. 4. End-to-end data flow of a vertically integrated IoT sensor application transmitting measurement data to an OGC Sensorthings RESTful API backend.

A. Overview on Setup and Deployment to the OGC specification as follows: (a) a Thing, representing The deployment consists of 3 components: (a) an IoT sensor the IoT node (Listing 1), (b) a Sensor, describing the sensor node based on RIOT-OS, (b) a simple gateway node running hardware used, (c) a Property, specifying what is measured, a CoAP-to-HTTP proxy software, and (c) a HTTP server and (d) a Datastream, representing the data endpoint. providing a RESTful API backend that conforms to the OGC Listing 1 SensorThings specification. DEFINITION OF AN IOT NODE AS AN OGCTHING IN JSON.

Figure 4 shows the end-to-end data flow as well as the 1 { specific network protocols involved. On the left-hand side is 2 "name": "RIOT Alpha", 3 "description": "IoT sensor node", the sensor application that is based on RIOT-OS and runs 4 "properties": { on an embedded, constrained IoT node with a low-power 5 "owner": "iNET RG, HAW Hamburg", 6 "device": "Phytec phyNODE", radio interface (namely IEEE 802.15.4). For this reason a 7 "operating system": "RIOT-OS" network protocol stack specifically tailored for constrained 8 }, 9 "Locations": [{ environments is used, the stack consists of CoAP, UDP, and 10 "name": "BT7-R580A", IPv6 with the 6LoWPAN adaption layer. 11 "description": "Office", 12 "encodingType": "application/vnd.geo+json", The JSON encoded sensor data is send (pushed) using a 13 "location": { CoAP POST request to the RESTful API backend server via 14 "type": "Point", 15 "coordinates": [10.022993, 53.557189] a gateway node, which runs a CoAP-to-HTTP proxy software. 16 } From an end-to-end perspective on the application layer the 17 }] 18 } gateway node is a (nearly) transparent proxy, but is needed for two reasons: (a) forward data from constrained network to The sensor application periodically (every 10s) sends tem- the Internet, and (b) provide proxy functionality to translate perature values (observations) to the OGC SensorThingsServer between CoAP and HTTP. using the URL of the OGC datastream endpoint. As the latter It should be noted that in this setup the IoT node has an is linked to all required metadata, i.e., Thing, ObservedProp- IPv6 address assigned, hence it would also be possible to erty, and Sensor, which completely describe a sensor reading receive (pull) data directly from the IoT sensor node using (observation), the JSON encoded payload of the CoAP/HTTP a RESTful GET request. Physical network communication POST request is relatively short: {"result":2143}9. This between the sensor and gateway node was realised using a results in small message sizes per observation, which in turn wireless, low-power IEEE 802.15.4 radio transceiver. Both reduces the required bandwidth and avoids retransmissions due nodes were deployed within close proximity to establish a to collisions when using wireless low-power radio. direct (one-hop) wireless communication link. The gateway Fig. 5 shows a comparison of the message size for a forwards sensor data over the Internet to the remote backend RESTful POST request using an IoT network stack with CoAP server (cloud) using a wired ethernet connection. and a standard Internet stack with HTTP. The total message sizes to transmit a JSON encoded sensor value as described B. OGC SensorThings Integration above is 236 Bytes for HTTP compared to 67 Bytes for For the integration of sensor and real time data to the CoAP with 6LoWPAN and UDP header compression (HC), Hamburg Urban Platform an implementation of the OGC that means the HTTP POST is more than 3.5 times larger. SensorThings API based on the Fraunhofer Open Source The uncompressed CoAP message —as send by the sensor SensorThings API Server (FROST Server)8 is used. Before application— has a size of 106 Bytes. Header compression is sending any data from the IoT sensor node to the Sensor- applied within the network stack, this process is completely ThingsServer, we setup endpoints and handles that conform transparent to any application. While the size of the JSON

8https://github.com/FraunhoferIOSB/SensorThingsServer 9The phenomenon time is omitted to further reduce the payload size. compare the performance of IoT network protocols such as 250 JSON (15B) CoAP and MQTT in a large real-world deployment. We aim to establish this extended test setup on an upcoming Hamburger 200 DOM funfair in 2018.

150 HTTP (153B) ACKNOWLEDGMENT This work is co-funded by the European Union (EU) 100 JSON (15B) within the MONICA project under grant agreement number Size [Bytes] CoAP (22B) 732350. The MONICA project is part of the EU Framework JSON (15B) UDP (8B) 50 TCP (32B) CoAP (22B) IPv6 (40B) Programme for Research and Innovation Horizon 2020 and 6LoWPAN (9B) IPv4 (20B) the IoT European Large-Scale Pilots Programme. 802.15.4 (21B) 802.15.4 (21B) Ethernet (16B) 0 REFERENCES CoAPHC CoAP HTTP [1] T. Nam and T. A. Pardo, “Conceptualizing Smart City with Dimensions Network Stack of Technology, People, and Institutions,” in 12th Annual Int. Digital Government Research Conference: Digital Government Innovation in Fig. 5. Size comparison of a RESTful POST message using CoAP and HTTP. Challenging Times, ser. dg.o ’11. ACM, 2011, pp. 282–291. As CoAP utilises IEEE 802.15.4 and 6LoWPAN with header compression [2] H. Chourabi, T. Nam, S. Walker, J. R. Gil-Garciaand, S. Mellouli, (HC), the actual message size transmitted is smaller than the (uncompressed) K. Nahon, T. A. Pardo, and H. J. Scholl, “Understanding Smart Cities: message send by the sensor application, compare CoAP HC and CoAP. An Integrative Framework,” in 45th Hawaii International Conference on System Sciences, Jan 2012, pp. 2289–2297. [3] L. Atzori, A. Iera, and G. Morabito, “The Internet of Things: A survey,” Computer Networks, vol. 54, no. 15, pp. 2787–2805, 2010. encoded sensor data (message payload) is 15 Bytes in all [4] AIOTI WG03 – loT Standardisation, “High Level Architecture,” AIOTI, cases, the major difference in size is caused by HTTP which Proposal Release 3.0, June 2017. [5] S. Liang, C.-Y. Huang, and T. Khalafbeigi, “OGC SensorThings API is 153B compared to 22B for CoAP. It is noteworthy, that in Part I:Sensing,” OGC, Implementation Standard 1.0, July 2016. our test deployment the CoAP-to-HTTP proxy also translates [6] oneM2M Partners Type 1, “Functional Architecture,” OneM2M, Tech- from IPv6 to IPv4 when passing data from the IoT network nical Specification 2.10.0, August 2016. [7] K. Kajimoto, M. Kovatsch, and U. Davuluru, “Web of Things (WoT) to the Internet, saving 20B for HTTP. As of April 2018 we Architecture,” World Wide Web Consortium WD, September 2017. collected more than 2.8 million observations over a period of [8] A. Gyrard and M. Serrano, “FIESTA-IoT: Federated Interoperable 11 months, while the experiment is still running. Semantic Internet of Things (IoT) Testbeds and Applications,” in 13th European Semantic Web Conference, EU Project Networking Session, ser. ESWC 2016, June. VI. CONCLUSION AND OUTLOOK [9] O. Hahm, E. Baccelli, H. Petersen, and N. Tsiftes, “Operating Systems for Low-End Devices in the Internet of Things: a Survey,” IEEE Internet In this paper, we introduced the EU project MONICA of Things Journal, vol. 3, no. 1, 2016. and its platform architecture for large-scale IoT deployments. [10] E. Baccelli, O. Hahm, M. G¨unes, M. W¨ahlisch, and T. C. Schmidt, Further, we gave an overview on Smart City activities in “RIOT OS: Towards an OS for the Internet of Things,” in Proc. of the 32nd IEEE INFOCOM. Poster. Piscataway, NJ, USA: IEEE Press, Hamburg, which is a MONICA pilot site. We reported on 2013. first field tests with an end-to-end sensor application that [11] E. Baccelli, C. G¨undogan, O. Hahm, P. Kietzmann, M. Lenders, integrates dedicated IoT technologies and utilises a wide H. Petersen, K. Schleiser, T. C. Schmidt, and M. W¨ahlisch, “RIOT: an Open Source Operating System for Low-end Embedded Devices in the range of open standards and protocols. Our work is based IoT,” The IEEE Internet of Things Journal, 2018. [Online]. Available: on the IoT operating system RIOT which has been already http://dx.doi.org/10.1109/JIOT.2018.2815038 established in industrial IoT settings [18]. It deploys a tailored [12] M. Lenders, P. Kietzmann, O. Hahm, H. Petersen, C. G¨undogan, E. Baccelli, K. Schleiser, T. C. Schmidt, and M. W¨ahlisch, “Connecting network stack for constraint environments based on CoAP, the World of Embedded Mobiles: The RIOT Approach to Ubiquitous UDP, IPV6 + 6LoWPAN, and IEEE 802.15.4, and a RESTful Networking for the Internet of Things,” Open Archive: arXiv.org, backend service based on the OGC SensorThings API. In this Technical Report arXiv:1801.02833, January 2018. [Online]. Available: https://arxiv.org/abs/1801.02833 experimental setup, we showed how to connect a constraint [13] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, IoT network with the common Internet by using a CoAP-to- R. Struik, J. Vasseur, and R. Alexander, “RPL: IPv6 Routing Protocol HTTP proxy to enable transparent, end-to-end data flow from for Low-Power and Lossy Networks,” IETF, RFC 6550, March 2012. [14] Z. Shelby, K. Hartke, and C. Bormann, “The Constrained Application an embedded IoT sensor to the Hamburg Urban Platform. Protocol (CoAP),” IETF, RFC 7252, June 2014. These field tests and experiments are ongoing work, and [15] C. Bormann and P. Hoffman, “Concise Binary Object Representation will be continued and updated iteratively in accordance to (CBOR),” IETF, RFC 7049, October 2013. [16] C. Jennings, Z. Shelby, J. Arkko, A. Keranen, and C. Bormann, “Media the progress within the MONICA project. For 2018, we also Types for Sensor Measurement Lists (SenML),” IETF, Internet-Draft – plan to deploy other IoT application together with MONICA work in progress 13, March 2018. partners. We also work on extending the current test setup by [17] L. Heuser, J. Scheer, P. den Hamer, and B. de Lathouwer, “Reference Architecture & Design Principles,” EIP-SCC Work Stream 2, technical adding a variety of different IoT nodes and collect additional report 1.00, September 2017. sensor readings. With that the IoT network will change from [18] C. G¨undogan, P. Kietzmann, T. C. Schmidt, M. Lenders, H. Petersen, a homogeneous, single-hop to a heterogeneous, multi-hop M. W¨ahlisch, M. Frey, and F. Shzu-Juraschek, “Information-Centric Networking for the Industrial IoT,” in Proc. of 4th ACM Conference topology, hence requiring a routing protocol such as RPL. This on Information-Centric Networking (ICN), Demo Session. New York, setup will also allow for experiments to study, measure, and NY, USA: ACM, September 2017, pp. 214–215.