# A Performance Analysis of Internet of Things Networking Protocols: Evaluating MQTT, CoAP, OPC UA
## 3 An Overview on IoT Communication Protocols and Frameworks
### OPC UA: Open Platform Communications--Unified Architecture  
The _Open Platform Communications Unified Architecture (OPC UA)_[16; 17; 18] started in 1996 as a concept for automation industry, where the purpose was to have a standard for interacting with control hardware and field-level devices. OPC would shield client applications from the details of the automation equipment, and would provide standardised interfaces to interact with control hardware and field-devices.  
The original OPC specification derives from _OLE, COM_ and _DCOM_ technologies, tying it exclusively to the Microsoft platform.  
With the extinction of DCOM in 2002 by Microsoft, the OPC community started the definition of a new OPC Data Access standard over _SOAP/XML_. While these new standard addressed portability, the overhead introduced by SOAP/XML was not compatible with several industrial use cases. This led to the beginning of the OPC UA initiative, which delivered the 1.0 version of the standard in 2009. As part of this process, the acronym OPC was changed to be \"Open Platform Communication\" and the new standard was called OPC UA (OPC Unified Architecture).  
Today, OPC UA is a platform-independent standard via which various systems and devices can communicate, by sending messages between clients and servers over various networks. It supports robust, secure communication that assures the identity of clients and servers, and is claimed to resist several types of attacks.  
These qualities make OPC UA one of the most promising candidates for unified communication in the context of Industrial IoT, in particular for critical and close environments, such as industrial plants, as it provides in-plant resilient and robust communication.  
However, there are a few drawbacks. A major drawback of OPC UA is that it cannot ensure the complete isolation of the plant network when connecting IIoT infrastructures. To access data from a _UA_ server, an OPC client outside the plant network needs an open firewall port. The answer currently provided to this issue is to keep OPC UA for the in-plant communication, and to provide interoperability with other IP-based messaging approaches, for instance OPC UA to MQTT, to support the articulation of communication to the network (Edge-Cloud).  
One possible way to increase the relevancy of OPC UA as a possible candidate to unify the communications in IoT, is to consider a push communication model thus allowing the server to make an outbound connection to a client. These are aspects being worked upon by the OPC UA working group which are currently extending the OPC UA client/server model into a publisher/subscriber model, thus allowing the server to take the role of Publisher and to publish data towards an arbitrary number of clients (Subscribers). Two methods are under discussion:  
* **Publisher/subscriber over fast, local communication media**. With this method data are sent once (long-lived) and sent to any number of clients over _UDP_ (_secure multicast UDP_). This model supports 1 to N communication and is relying on UDP directives for _Time Sensitive Networks_ (_TSNs_).
* **Publisher/subscriber for message exchange in global networks (e.g., Cloud)**. With this method data are sent between OPC UA applications residing in different networks or where data shall be published to clients that reside in the cloud, as well as to relays; brokers; hubs. This model supports N to M communication based on AMQP.