# A Trustworthy Communication Hub for Cyber-Physical Systems
## 2 Related Works
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Technology** & **Forum(s), References** & **Main Contribution** \\ \hline \multirow{6}{*}{Extensible Messaging and Presence Protocol (AMPP)} & - Core XMPP protocols defined in Internet Engineering Task Force (IETF) Requests for comments (RPCs) 6120, and 6121 and 6122. & - XMPP provides capabilities for instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of E. E.g., Sensor-over-XMPP, XMPP extension [15] & Extensible markup language (XML) data \\ \cline{1-1}  & - XMPP Standards Foundation (XSP), [[http://xmpp.org/](http://xmpp.org/)]([http://xmpp.org/](http://xmpp.org/)), & - Sensor-over-XMPP is a payload format for communicating sensor and actuation information \\ \cline{1-1}  & - EETF RFC 3261 [16] & Establish and control of multimedia sessions over the Internet \\ \cline{1-1}  & - IETF RFC 7231 [17] & \\ \cline{1-1}  & Hypertext Transfer Protocol (HTTP) & - IETF RFC 7231 [17] & \\ \cline{1-1}  & - RESTful architectural style & Protocol for transferring hypertext information \\ \cline{1-1} \cline{1-1}  & WebSocket protocol & - IETF RFC 6455 & Two-way communications with low-overhead transport (single transmission control protocol (TCP) connection) \\ \cline{1-1} \cline{1-1}  & Simple Mail Transfer Protocol (SMTP) & - IETF RFC 7504 & Transfer of emails in a reliable and efficient way \\ \cline{1-1} \cline{1-1}  & MQT Delivery Transport (MQT) & MQT Eclipse Machine-to-Machine (M2M)Industry Working Group & Lightweight publish/subscribe binary messaging protocol \\ \cline{1-1} \cline{1-1}  & Advanced Message Queuing Protocol (AMQP) & OASAS AMQP standard & Broker-based messaging, publish/subscribe \\ \cline{1-1} \cline{1-1}  & STOMP & [[https://stomp.github.io/](https://stomp.github.io/)]([https://stomp.github.io/](https://stomp.github.io/)) & Simple text oriented messaging protocol \\ \hline \multirow{6}{*}{ZeroMQ} & \multirow{2}{*}{ZeroMQ protocol} & A lightweight publish/subscribe type of messaging protocol \\ \cline{1-1}  & & designed for constrained devices and low-bandwidth, \\ \cline{1-1}  & & high-latency, or unreliable networks \\ \cline{1-1} \cline{1-1}  & & Middleware protocol and application programming interface \\ \cline{1-1}  & & (API) standard for data-centric connectivity for Internet of Things \\ \cline{1-1}  & & (IoT) applications \\ \hline \multirow{2}{*}{CoAP} & \multirow{2}{*}{IETF’s constrained RESTful environments (CoRE) working group RFC [18]} & An application layer protocol designed for constrained devices \\ \cline{1-1}  & & allowing them to communicate over the Internet \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Review of communication overlay technologies. The other required feature is related to naming and identification of the owners. A very natural way to name the source and destination of messaging is provided by the electronic mail systems with protocols such as Simple Mail Transfer Protocol (SMTP, RFC 5321 and 5322), Post Office Protocol (POP), and Internet Message Access Protocol (IMAP). XMPP and session initiation protocol (SIP)/SIMPLE have also such capabilities to name the owner, and they also support the naming of the resources of the owner. Naming and identification of the physical resources (devices) that belong to an owner is an essential feature in CPS systems. However, this is not enough because there is the need for dynamically defining and maintaining the relationships of owners, which is supported by XMPP in the form of the contact \"Buddy\" list management feature. The capability to support maintaining the presence of physical resources (devices) so that the system knows whether the resource is available or not. This kind of feature is supported by, for example, XMPP and SIP/SIMPLE. Accordingly, there is the need for simple clients and rapid'real-time' messaging between resources that are present in the system.