Figure 5 - available via license: Creative Commons Attribution 4.0 International
Content may be subject to copyright.
WebSocket protocol. The WebSocket communication consists of an opening handshake, a data transfer and a closing handshake.
Source publication
In this paper, we present the design of a Constrained Application Protocol (CoAP) proxy able to interconnect Web applications based on Hypertext Transfer Protocol (HTTP) and WebSocket with CoAP based Wireless Sensor Networks. Sensor networks are commonly used to monitor and control physical objects or environments. Smart Cities represent applicatio...
Context in source publication
Context 1
... the closing handshake, the endpoints close the TCP connection. Figure 5 shows the messages interchanged between a client and a server to establish a communication using the WebSocket protocol. In short-lived communications, HTTP long-polling may have better performance than WebSocket. ...
Similar publications
In 6LoWPAN networks, several mobility management schemes have been proposed based on Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6). However, the existing schemes are centralized, and thus they have many serious drawbacks such as nonoptimal data route, injection of unwanted data traffics into core networks, increased cost of network engineering...
As the IoT continues to grow over the coming years, resource-constrained devices and networks will see an increase in traffic as everything is connected in an open Web of Things. The performance- and function-enhancing features are difficult to provide in resource-constrained environments, but will gain importance if the WoT is to be scaled up succ...
Citations
... Mi and Wei [34] provide an architecture for using smartphones as CoAP translation proxies in health care environments as a mean of interaction between the patient's physical condition, remote clinicians, and hospitals. Ludovici and Calveras [35] also propose the design of a cross-proxy CoAP server for the interaction between a CoAP-based sensor network and HTTP-based web applications. Authors also explore observe communication pattern between the server and the CoAP devices to reduce the number of interactions. ...
Proxy servers are widely used in many contexts since they can enhance performance, security, and access control for production networks. The Constrained Application Protocol (CoAP), the de facto standard of Internet of Things (IoT) communications, specifies mechanisms and semantics to applications based on RESTful approach similar to HTTP. The CoAP standard defines an additional operation mode for proxying request, which is supported by several programming languages and platforms. However, there is no current implementation of a CoAP proxy for embedded systems, namely for devices supporting the Contiki-NG operating system. This paper discusses the design, implementation, and evaluation of a forward CoAP Proxy server for 6LoWPAN embedded systems with cache capabilities. We perform simulation and experimental evaluations with topologies involving up to three hops from the proxy to study performance in terms of response times and the number of exchanged packets. In simulation environments results show a 48.03%, 85.39%, and 134.21% in response time reduction at one, two, and three hops away. In experimental environments, results show that the use of our embedded CoAP Proxy server reduces response times in 7.46%, 30.67%, and 37.43% when requests are targeted to servers at one, two, and three hops away from the proxy respectively. In both scenarios, a reduction in the number of exchanged packets of 71.42%, 125%, and 166.66% for requests at each hop is achieved.
... Another typical function of an IoT gateway is reducing the number of exchanged messages for energy conservation and congestion avoidance. So, authors of [13] propose a CoAP proxy to provide support to applications that need to continuously retrieve data from the Wireless Sensor Network (WSN) using WebSocket. The CoAP proxy uses the observe protocol to receive status notifications from the device; so, the proxy is the only observer, reducing the WSN traffic. ...
The Internet of Things (IoT) brings Internet connectivity to devices and everyday objects. This huge volume of connected devices has to be managed taking into account the severe energy, memory, processing, and communication constraints of IoT devices and networks. In this context, the OMA LightweightM2M (LWM2M) protocol is designed for remote management of constrained devices, and related service enablement, through a management server usually deployed in a distant cloud data center. Following the Edge Computing paradigm, we propose in this work the introduction of a LWM2M Proxy that is deployed at the network edge, in between IoT devices and management servers. On one hand, the LWM2M Proxy improves various LWM2M management procedures whereas, on the other hand, it enables the support of QoS-aware services provided by IoT devices by allowing the implementation of advanced policies to efficiently use network, computing, and storage (i.e., cache) resources at the edge, thus providing benefits in terms of reduced and more predictable end-to-end latency. We evaluate the proposed solution both by simulation and experimentally, showing that it can strongly improve the LWM2M performance and the QoS of the system.
... It was designed with two main goals: 1) to be efficient for large deployments of constrained devices communicating over constrained networks and 2) to integrate easily with existing Representational State Transfer (REST) [23] protocols, such as HTTP [22,45,20]. One of the strategies that CoAP uses to achieve these goals is to leverage proxy software executed on middle boxes, such as the border routers connecting the constrained IoT networks and the non-constrained networks, e.g., the Internet [46,31]. For example, a proxy may serve incoming requests from a cache containing previously received data that is still valid in order to save the constrained § A short version of this paper will appear on CODASPY 2021. ...
Many modern IoT applications rely on the Constrained Application Protocol (CoAP) because of its efficiency and seamless integrability in the existing Internet infrastructure. One of the strategies that CoAP leverages to achieve these characteristics is the usage of proxies. Unfortunately, in order for a proxy to operate, it needs to terminate the (D)TLS channels between clients and servers. Therefore, end-to-end confidentiality, integrity and authenticity of the exchanged data cannot be achieved. In order to overcome this problem, an alternative to (D)TLS was recently proposed by the Internet Engineering Task Force (IETF). This alternative consists of two novel protocols: 1) Object Security for Constrained RESTful Environments (OSCORE) providing authenticated encryption for the payload data and 2) Ephemeral Diffie-Hellman Over COSE (EDHOC) providing the symmetric session keys required for OSCORE. In this paper, we present the design of four firmware libraries for these protocols especially targeted for constrained microcontrollers and their detailed evaluation. More precisely, we present the design of uOSCORE and uEDHOC libraries for regular microcontrollers and uOSCORE-TEE and uEDHOC-TEE libraries for microcontrollers with a Trusted Execution Environment (TEE), such as microcontrollers featuring ARM TrustZone-M. Our firmware design for the later class of devices concerns the fact that attackers may exploit common software vulnerabilities, e.g., buffer overflows in the protocol logic, OS or application to compromise the protocol security. uOSCORE-TEE and uEDHOC-TEE achieve separation of the cryptographic operations and keys from the remainder of the firmware, which could be vulnerable. We present an evaluation of our implementations in terms of RAM/FLASH requirements, execution speed and energy on a broad range of microcontrollers.
... The tool functions as a proxy that supports messages from multiple IoT application layer protocols (CoAP, MQTT, HTTP) and can be used by developers to implement a multi-protocol transport module for their application. Ludovici et al. [40] designed an HTTP-CoAP proxy that facilitates the integration of a CoAP-based WoT environment with existing Web services. Their tool can be coupled with existing Web benchmarks to enable performance evaluation of WoT applications. ...
... Common denominator of some of these proposals, e.g., [33,40,41], is the abstraction of low-level functionalities provided by embedded devices (e.g., connectivity and communication over low-level protocols like ZigBee, Z-Wave, Wi/IP/UPnP, etc.). Smart gateways are used also to translate (or integrate) CoAP into HTTP [42,43,44] and to integrate both CoAP and MQTT by means of specic middlewares [45]. Eclipse IoT [46] is an IoT integration framework proposed by the Eclipse IoT Working Group. ...
The Internet of Things (IoT) advocates for multi-layered platforms—from edge devices to Cloud nodes—where each layer adopts its own communication standards (media and data formats). While this freedom is optimal for in-layer communication, it puzzles cross-layer integration due to incompatibilities among standards. Also enforcing a unique communication stack within the same IoT platform is not a solution, as it leads to the current phenomenon of “IoT islands”, where disparate platforms hardly interact with each other. In this paper we tackle the problem of IoT cross-layer and cross-platform integration following a language-based approach. We build on the Jolie programming language, which provides uniform linguistic abstractions to exploit heterogeneous communication stacks, allowing the programmer to specify in a declarative way the desired stack, and to easily change it, even at runtime. Jolie currently supports the main technologies from Service-Oriented Computing, such as TCP/IP, Bluetooth, and RMI at transport level, and HTTP and SOAP at application level. We integrate in Jolie the two most adopted protocols for IoT communication, i.e., CoAP and MQTT. We report our experience on a case study on Cloud-based home automation, and we present high-level concepts valuable both for the general implementation of interoperable systems and for the development of other language-based solutions.
... Common denominator of some of these proposals, e.g., [33,40,41], is the abstraction of low-level functionalities provided by embedded devices (e.g., connectivity and communication over low-level protocols like ZigBee, Z-Wave, Wi/IP/UPnP, etc.). Smart gateways are used also to translate (or integrate) CoAP into HTTP [42,43,44] and to integrate both CoAP and MQTT by means of specic middlewares [45]. Eclipse IoT [46] is an IoT integration framework proposed by the Eclipse IoT Working Group. ...
... Oliveira et al. presented a security framework to enhance the 6LoWPAN model [39]. Finally, another study showed a model to interconnect CoAP with web applications using a web socket in CoAP [40]. ...
Different protocols have been developed for the Internet of things (IoT), such as the constrained application protocol (CoAP) for the application layer of the IPv6 over low-power wireless personal area networks (6LoWPAN) stack model. Data transmitted over 6LoWPAN are limited by the throughput and the frame size defined by IEEE 805.14.5 standards. Choosing the best configuration for data transmission involves a tradeoff between the application requirements, the constrained network configuration, the constrained device specifications and IoT application protocols. This paper provides an analysis of message size and structure recommendations for the 6LoWPAN stack model for different network topologies using CoAP. CoAP is a promising application protocol for the 6LoWPAN stack model because it can effectively manage the transmission required functionality in small header UDP packets compared to TCP packets. However, a data model is also required to realize an effective IoT model. While fragmentation and reassembly are supported by CoAP, they should be avoided for this type of model. As for any conceptual model, a high configuration between layers is mandatory. Additionally, the proposed message format is useful for semantic web of things application development and for WSN design and management.
... CoAP utilizes the same Representational State Transfer (REST) architecture, where a client and server can transfer resources by using familiar GET, PUT, POST, and DELETE commands. As the study conducted in [131] shows, CoAP interoperability with HTTP bridges IoT and the Web through transparent CoAP proxies. CoAP relies on 6LoWPAN for IPv6 compatibility, which not only facilitates Internet access for IoT nodes but also improves interoperability with HTTP. ...
Deployments of Cyber Physical Systems (CPSs) in smart cities are poised to significantly improve healthcare, transportation services, utilities, safety, and environmental health. However, these efficiencies and service improvements will come at a price: increased vulnerability and risk. Smart city deployments have already begun to proliferate, as have the upsides, efficiencies, and cost-savings they can facilitate. There are, however, proliferating challenges and costs as well. These challenges include important technical questions, but equally important policy and organizational questions. It is important to understand that these policy and technical implementation hurdles are perhaps equally likely to slow or disable smart city implementation efforts. In this paper, a survey of the theoretical and practical challenges and opportunities are enumerated not only in terms of their technical aspects, but also in terms of policy and governance issues of concern.
... This case demonstrates the delayed response communication scenario. 10: if request_type = = Con f irmable then 11: 12: send empty ACK to requesting client 13: 14: request_type ← Non − con f irmable 15 ...
... The CoRE working group has developed CoAP to extend the HTTP web services for the LLN. Recent efforts [15,16] have been performed on proxy based CoAP observe in Wireless Sensor Network (WSNs). However, such IP-based IoT solutions could inherit some of the limitations of IP when dealing with intermittent connectivity and challenged networks [8]. ...
... Recent efforts [15,16] have been performed on proxy based CoAP observe in Wireless Sensor Network (WSNs). Alessandro et al. [15] includes WebSocket protocol in the design of the CoAP proxy for HTTP based web applications. ...
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol which is intended to be used for the constrained networks and devices. CoAP and its extensions (e.g., CoAP observe and group communication) provide the potential for developing novel applications in the Internet of Things (IoT). However, a full-fledged CoAP-based application may require significant computing capability, power, and storage capacity in IoT devices. To address these challenges, we present the design, implementation, and experimentation with the CoAP Handler, which provides transparent CoAP services through the ICN core network. In addition, we demonstrate how the CoAP traffic over an ICN network can unleash the full potential of the CoAP, shifting both overhead and complexity from the (constrained) endpoints to the ICN network. The experiments prove that the CoAP handler helps to decrease the required computation complexity, communication overhead, and state management of the CoAP server.
... CoAP is a specialized Web transfer protocol for use with constrained nodes and networks. A CoAP proxy is designed by Ludovici and Calveras [17], which enables Web applications to transparently access the resources hosted in IoT devices. Castro et al. [1] propose a flexible and scalable CoAP solution for Web applications and offer full integration with Web clients. ...
One of the noticeable characteristics of the Internet-of-Things (IoT) devices is that they are resource-constrained, which makes them incompatible with the standard Internet protocols, e.g., HTTP. Nevertheless, IoT offers the Constrained Application Protocol (CoAP) as an alternative protocol for IoT devices where it is considered to be lightweight in regard to power consumption, network traffic, and so on. The main challenges associated with CoAP, however, still remain unsolved where most of the state-of-the-art approaches group servers manually and return the exact matches only. To address these issues, we propose a novel Semantically Enhanced CoAP Gateway (SECoG) for complex service mashups. SECoG enables users to create a simple or complex CoAP service mashup via a single HTTP request. Furthermore, a prototype implementation of SECoG was deployed on a real-world testbed to evaluate the proposed approach in terms of the reliability, execution time, network traffic, and accuracy.
