Aleksandar Antonic, M. Marjanović, Pavle Skocir, Ivana Podnar Žarko
{"title":"Comparison of the CUPUS middleware and MQTT protocol for smart city services","authors":"Aleksandar Antonic, M. Marjanović, Pavle Skocir, Ivana Podnar Žarko","doi":"10.1109/ConTEL.2015.7231225","DOIUrl":null,"url":null,"abstract":"Publish/subscribe messaging pattern is often used as a communication mechanism in data-oriented applications and is becoming wide-spread, especially due to the expansion of the Internet of Things (IoT) services and applications. In addition to MQTT, which is one of the commonly used publish/subscribe protocols in the context of IoT, there are a number of other message queuing solutions, either open or proprietary. We have designed a CloUd-based PUblish/Subscribe (CUPUS) middleware solution within the framework of the FP7 project OpenIoT1 that has developed an open-source cloud platform for the IoT. CUPUS is one of the core OpenIoT components which enables flexible integration of wearable sensors and mobile devices as data sources within the OpenIoT platform. In this paper we compare MQTT and CUPUS in the context of smart city application scenarios. Smart city services pose different key-requirements on IoT publish/subscribe solutions and thus we propose a taxonomy to identify vital features of IoT publish/subscribe middleware. The comparison shows that CUPUS is more appropriate for mobile environments with frequent context changes, while it can filter out unrequired data on devices prior to being reported to backend cloud servers. The MQTT protocol proves to be suitable for Wireless Sensor Networks (WSNs) and heterogeneous environments due to its small code footprint, low bandwidth usage and standardized interfaces. Finally we evaluate the two solutions in terms of message footprint in a real-world scenario, latency and delivery semantics.","PeriodicalId":134613,"journal":{"name":"2015 13th International Conference on Telecommunications (ConTEL)","volume":"6 1","pages":"0"},"PeriodicalIF":0.0000,"publicationDate":"2015-07-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"31","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"2015 13th International Conference on Telecommunications (ConTEL)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ConTEL.2015.7231225","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 31
Abstract
Publish/subscribe messaging pattern is often used as a communication mechanism in data-oriented applications and is becoming wide-spread, especially due to the expansion of the Internet of Things (IoT) services and applications. In addition to MQTT, which is one of the commonly used publish/subscribe protocols in the context of IoT, there are a number of other message queuing solutions, either open or proprietary. We have designed a CloUd-based PUblish/Subscribe (CUPUS) middleware solution within the framework of the FP7 project OpenIoT1 that has developed an open-source cloud platform for the IoT. CUPUS is one of the core OpenIoT components which enables flexible integration of wearable sensors and mobile devices as data sources within the OpenIoT platform. In this paper we compare MQTT and CUPUS in the context of smart city application scenarios. Smart city services pose different key-requirements on IoT publish/subscribe solutions and thus we propose a taxonomy to identify vital features of IoT publish/subscribe middleware. The comparison shows that CUPUS is more appropriate for mobile environments with frequent context changes, while it can filter out unrequired data on devices prior to being reported to backend cloud servers. The MQTT protocol proves to be suitable for Wireless Sensor Networks (WSNs) and heterogeneous environments due to its small code footprint, low bandwidth usage and standardized interfaces. Finally we evaluate the two solutions in terms of message footprint in a real-world scenario, latency and delivery semantics.