مقاله انگلیسی رایگان در مورد بهبودبخشی IoT میان افزاری از طریق مکانیسم مدیریت کیفیت – الزویر 2018

The Internet of Things, its application and their QoS requirements. The future Internet will include not only usual terminals but more generally any form of connected objects (or things) authorizing the development of new business activities, in various domains such as remote supervision, personal assistance, or urban transport. This IoT will also have to meet non-functional needs (e.g. quality of service – QoS, security) of these new applications. The interactions between the underlying application software(s) and the connected objects will be based on heterogeneous networks and on middleware layers. Indeed, from 2010, a major standardization effort has been conducted, notably via the ETSI and the oneM2M consortium1, 2 . The resulting frameworks are aimed at abstracting applications from complexity of the underlying technologies (networks and objects); they are also aimed at avoiding vertical fragmentation of currently developed IoT solutions thanks to a generic middleware layer. Based on the REST architectural style (http, CoAP, …), this framework makes them appear what can be called Middleware (MW) nodes, named gateway and server in the ETSI vision, and mn-cse and in-cse in the oneM2M vision (Fig. 1). Both visions make also appear two major bottlenecks with regard to QoS considerations (service availability, bounded response time, etc.): within the connected objects and IP networks, and within the MW nodes. In this context, several attempts have already been done to face (among other) the QoS requirements at the middleware level. Those attempts are based, for instance, on the deployment of QoS-oriented mechanisms within the MW nodes, with the aim to manage the application traffic (e.g. delaying less priority http requests in case of congestion) and / or allocated resources of the underlying machines3 . Those propositions have also shown the benefits that can be induced by a deployment of such mechanisms “outside” of the data path, for instance thanks to intermediate proxies configured (for instance) as traffic load balancer / shaper / dropper (Fig. 2).