Errata exists for this version of the document.

This clause lists the standard protocols that have been selected for this specification and their possible combinations with message mappings.

OPC UA UDP is a simple UDP based protocol that is used to transport UADP NetworkMessages.

The syntax of the UDP transporting protocol URL used in the Address parameter defined in 6.2.6.3 has the following form:

opc.udp://<host>[:<port>]

The host is either an IP address or a registered name like a hostname or domain name. IP addresses can be unicast, multicast or broadcast addresses. It is the destination of the UDP datagram.

The IANA registered OPC UA port for UDP communication is 4840. This is the default and recommended port for broadcast, multicast and unicast communication. Alternative ports may be used.

The transport of a UADP NetworkMessage in a UDP packet is defined in Table 94.

Table 94 – UADP message transported over UDP

Name	Description
Frame Header	The frame header.
IP Header	The IP header for the frame contains information like source IP address and destination IP address. The size of the IP header depends on the used version.
UDP Header	The UDP header for the frame contains the source port, destination port, length and checksum. Each field is two byte long. The total size of the UDP header is 8 byte.
UADP NetworkMessage	The UADP NetworkMessage is sent as UDP data.
Frame Footer	The frame footer.

For OPC UA UDP it is recommended to limit the MaxNetworkMessageSize plus additional headers to a MTU size. The number of frames used for a UADP NetworkMessage influences the probability that UADP NetworkMessages get lost.

For OPC UA UDP the MaxNetworkMessageSize plus additional headers shall be limited to 65535 Byte.

It is recommended to use switches with IGMP support to limit the distribution of multicast traffic to the interested participants. OPC UA Applications shall issue an IGMP membership report.

Note: The Internet Group Management Protocol (IGMP) is a standard protocol used by hosts to report their IP multicast group memberships and must be implemented by any host that wishes to receive IP multicast datagrams. IGMP messages are used by multicast routers to learn which multicast groups have members on their attached networks. IGMP messages are also used by switches capable of supporting “IGMP snooping” whereby the switch listens to IGMP messages and only sends the multicast NetworkMessages to ports that have joined the multicast group.There are three versions of IGMP: - IGMP V1 is defined in RFC1112. - IGMP V2 is defined in RFC2236. - IGMP V3 is defined in RFC3376.RFC2236 and RFC3376 discuss host and router requirements for interoperation with older IGMP versions.Since OPC UA devices make extensive use of IP multicast for UDP transport, consistent IGMP usage by OPC UA devices is essential in order to create well-functioning OPC UA Application networks.

IGMP Membership Report MessagesOPC UA devices shall issue a Membership Report message (V1, V2 or V3 as appropriate) when opening a UDP connection on which they will receive multicast NetworkMessages.

OPC UA Ethernet is a simple Ethernet based protocol using EtherType B62C that is used to transport UADP NetworkMessages as payload of the Ethernet II frame without IP or UDP headers.

The syntax of the Ethernet transporting protocol URL used in the Address parameter defined in 6.2.6.3 has the following form:

opc.eth://<host>[:<VID>[.PCP]]

The host is a MAC address, an IP address or a registered name like a hostname. The format of a MAC address is six groups of hexadecimal digits, separated by hyphens (e.g. 01-23-45-67-89-ab). A system may also accept hostnames and/or IP addresses if it provides means to resolve it to a MAC address (e.g. DNS and Reverse-ARP).

The VID is the VLAN ID as number.

The PCP is the Priority Code Point as one digit number.

The transport of a UADP NetworkMessage in an Ethernet II frame is defined in Table 95.

Table 95 – UADP message transported over Ethernet

Name	Description
Frame Header	The frame header with an EtherType of 0xB62C.
UADP NetworkMessage	The UADP NetworkMessage is sent as Ethernet payload.
Frame Footer	The frame footer.

For OPC UA Ethernet the MaxNetworkMessageSize plus additional headers shall be limited to an Ethernet frame size of 1522 Byte.

The IANA registered OPC UA EtherType for UADP communication is 0xB62C.

The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for Message Oriented Middleware. AMQP is often used with a Broker that relays messages between applications that cannot communicate directly.

Publishers send AMQP messages to AMQP endpoints. Subscribers listen to AMQP endpoints for incoming messages. If a Broker is involved it may persist messages so they can be delivered even if the subscriber is not online. Brokers may also allow messages to be sent to multiple Subscribers.

The AMQP protocol defines a binary encoding for all messages with a header and a body. The header allows applications to insert additional information as name-value pairs that are serialized using the AMQP binary encoding. The body is an opaque binary blob that can contain any data serialized using an encoding chosen by the application.

This specification defines two possible message mappings for the AMQP message body, the UADP message mapping defined in 7.2.2 and a JSON message mapping defined in 7.2.3. AMQP Brokers have an upper limit on message size. The mechanism for handling NetworkMessage that exceed the Broker limits depend on the encoding.

Security with AMQP is primary provided by a TLS connection between the Publisher or Subscriber and the AMQP Broker, however, this requires that the AMQP Broker be trusted. For that reason, it may be necessary to provide end-to-end security. Applications that require end-to-end security with AMQP need to use the UADP NetworkMessages and binary message encoding defined in 7.2.2.2. JSON encoded message bodies rely on the security mechanisms provided by AMQP and the AMQP Broker.

The syntax of the AMQP transporting protocol URL used in the Address parameter defined in 6.2.6.3 has the following form:

amqps://<domain name>[:<port>][/<path>]

The default port is 5671.

The syntax for an AMQP URL over Web Sockets has the following form:

wss://<domain name>[:<port>][/<path>]

The default port is 443.

Authentication shall be performed according to the configured AuthenticationProfileUri of the PubSubConnection, DataSetWriterGroup, DataSetWriter or DataSetReader entities.

If no authentication information is provided in the form of ResourceUri and AuthenticationProfileUri, SASL Anonymous is implied.

If the authentication profile specifies SASL PLAIN authentication, a separate connection for each new Authentication setting is required.

AMQP allows sending properties as part of opening the connection, session establishment and link attach.

The connection properties apply to any connection, session or link created as part of the PubSubConnection, or subordinate configuration entities, such as WriterGroup and DataSetWriter.

The properties are defined through the KeyValuePair array in the ConnectionProperties WriterGroupProperties and DataSetWriterProperties. The NamespaceIndex of the QualifiedName in the KeyValuePair shall be 0 for AMQP standard properties. The Name of the QualifiedName is constructed from a prefix and the AMQP property name with the following syntax.

Name = <target prefix>-<AMQP property name>

The target prefix can have the following values

• connection
• session
• link

The Value of the KeyValuePair is converted to an AMQP data type using the rules defined in Table 98. If there is no rule defined for a data type, the property shall not be included.

The connection properties are intended to be used sparingly to optimize interoperability with existing broker endpoints.

A writer negotiates the delivery guarantees for its link using the snd-settle-mode settlement policy (settled, unsettled, mixed) it will use, and the desired rcv-settle-mode (first, second) of the broker.

Vice versa, the reader negotiates delivery guarantees using its rcv-settle-mode (first, second) and the desired snd-settle-mode (settled, unsettled) of the broker.

This matches to the BrokerTransportQualityOfService values as follows:

• AtMostOnce_1 – messages are pre-settled at the sender endpoint and not sent again. Messages may be lost in transit.  This is the default setting.
• AtLeastOnce_2 – messages are received and settled at the receiver without waiting for the sender to settle.
• ExactlyOnce_3 – messages are received, the sender settles and then the receiver settles.

If the KeepAliveTime is set on a WriterGroup, a value slightly higher than the configured value of the group should be used as idle timeout of the connection ensuring that the connection is disconnected if the keep alive message was not sent by any writer. Otherwise, if no KeepAliveTime is specified, the implementation should set a reasonable default value.

When setting the maximum message sizes for the Link, the MaxNetworkMessageSize of the PubSubGroup shall be used. If this value is 0, the implementation chooses a reasonable maximum.

Other limits are up to the implementation and depend on the capabilities of the OS or or the capabilities of the device the Publisher or Subscriber is running on, and can be made configurable through configuration model extensions or by other means.

The AMQP message header has a number of standard fields. Table 96 describes how these fields shall be populated when an AMQP message is constructed.

Table 96 – AMQP Standard Header Fields

Field Name	Source
message-id	A globally unique value created by the DataSetWriter.
subject	Valid values are ua-data or ua-metadata.
content-type	The MIME type for the message body. The MIME types are specified in the message body subsections 7.3.4.8.1 and 7.3.4.8.2.

The subject defines the type of the message contained in the AMQP body. A value of “ua-data” specifies the body contains a UADP or JSON NetworkMessage. A value of “ua-metadata” specifies a body that contains a UA Binary or JSON encoded DataSetMetaData Message. The content-type specifies the whether the message is binary or JSON data.

The AMQP message header shall include additional fields defined on the WriterGroup or DataSetWriter through the KeyValuePair array in the WriterGroupProperties and DataSetWriterProperties. The NamespaceIndex of the QualifiedName in the KeyValuePair shall be 0 for AMQP standard message properties. The Name of the QualifiedName is constructed from a message prefix and the AMQP property name with the following syntax.

Name = message-<AMQP property name>

Table 97 defines the AMQP standard message properties.

Table 97 - OPC UA AMQP Standard Header QualifiedName Name mappings

AMQP standard property name	OPC UA DataType	AMQP data type
to	String	*
user-id	ByteString	binary
reply-to	String	string
correlation-id	ByteString	*
absolute-expiry-time	DateTime	timestamp
group-id	String	string
reply-to-group-id	String	string
creation-time	DateTime	timestamp
content-encoding	String	symbol

Any name not in the table is assumed to be an application property. In this case the namespace provided as part of the QualifiedName shall be the ApplicationUri.

The AMQP message header shall include additional promoted fields of the DataSet as list of name-value pairs. DataSet fields with the PromotedField flag set in the FieldMetaData fieldFlags are copied into the AMQP header. The FieldMetaData Structure is defined in 6.2.2.1.3. Promoted fields shall always be included in the header even if the DataSetMessage body is a delta frame and the DataSet field is not included in the delta frame. In this case the last known value is sent in the header.

When a field is added to the header it is converted to an AMQP data type using the rules defined in Table 98. If there is no rule defined for the data type, the field shall not be included.

Table 98 – OPC UA AMQP Header Field Conversion Rules

OPC UA DataType	Conversion Rules to AMQP data types.
Boolean	AMQP ‘boolean’ type.
SByte	AMQP ‘byte’ type.
Byte	AMQP ‘ubyte’ type.
Int16	AMQP ‘short’ type.
UInt16	AMQP ‘ushort’ type.
Int32	AMQP ‘int’ type.
UInt32	AMQP ‘uint’ type.
Int64	AMQP ‘long’ type.
UInt64	AMQP ‘ulong’ type.
Float	AMQP ‘float’ type.
Double	AMQP ‘double’ type.
String	AMQP ‘string’ type.
ByteString	AMQP ‘binary’ type.
DateTime	AMQP ‘timestamp’ type. This conversion may result in loss of precision on some platforms. The rules for dealing with the loss of precision are described in OPC 10000-6.
Guid	AMQP ‘uuid’ type.
QualifiedName	The QualifiedName is encoded as an AMQP ‘string’ type with the format <NamespaceUri>’#’<Name>.
LocalizedText	Not supported and the related field is discarded.
NodeId	If the NamespaceIndex is = 0 the value is encoded as an AMQP ‘string’ type using the format for a NodeId defined in OPC 10000-6. If the NamespaceIndex > 0 the value is converted to an ExpandedNodeId with a NamespaceUri and is encoded as an AMQP ‘string’ type using the format for an ExpandedNodeId defined in OPC 10000-6.
ExpandedNodeId	If the NamespaceUri is not provided the rules for the NodeId are used. If the NamespaceUri is provided the value is encoded as an AMQP ‘string’ type using the format for an ExpandedNodeId defined in OPC 10000-6.
StatusCode	AMQP ‘uint’ type.
Variant	If the value has a supported datatype it uses that conversion; otherwise it is not supported and the related field is discarded.
Structure	Not supported and the related field is discarded.
Structure with option fields	Not supported and the related field is discarded.
Array	Not supported and the related field is discarded.
Union	Not supported and the related field is discarded.

A JSON body is encoded as defined for the JSON message mapping defined in 7.2.3.

The corresponding MIME type is application/json.

A UADP body is encoded as defined for the UADP message mapping defined in 7.2.2.

The corresponding MIME type is application/opcua+uadp.

If the encoded AMQP message size exceeds the Broker limits it shall be broken into multiple chunks as described in 7.2.2.2.4.

It is recommended that the MetaDataQueueName as described in 6.4.2.3.6 is configured as a sub-topic of the related QueueName with the name $Metadata.

The Message Queue Telemetry Transport (MQTT) is an open standard application layer protocol for Message Oriented Middleware. MQTT is often used with a Broker that relays messages between applications that cannot communicate directly.

Publishers send MQTT messages to MQTT brokers. Subscribers subscribe to MQTT brokers for messages. A Broker may persist messages so they can be delivered even if the subscriber is not online. Brokers may also allow messages to be sent to multiple Subscribers.

The MQTT protocol defines a binary protocol used to send and receive messages from and to topics. The body is an opaque binary blob that can contain any data serialized using an encoding chosen by the application.

This specification defines two possible encodings for the message body: the binary encoded DataSetMessage defined in 7.2.2 and a JSON encoded DataSetMessage defined in 7.2.3. MQTT does not provide a mechanism for specifying the encoding of the MQTT message which means the Subscribers shall be configured in advance with knowledge of the expected encoding. Publishers should only publish NetworkMessages using a single encoding to a unique MQTT topic name.

Security with MQTT is primary provided by a TLS connection between the Publisher or Subscriber and the MQTT server, however, this requires that the MQTT server be trusted. For that reason, it may be necessary to provide end-to-end security. Applications that require end-to-end security with MQTT need to use the UADP NetworkMessages and binary message encoding defined in 7.2.2. JSON encoded message bodies must rely on the security mechanisms provided by MQTT and the MQTT server.

The syntax of the MQTT transporting protocol URL used in the Address parameter defined in 6.2.6.3 has the following form:

mqtts://<domain name>[:<port>][/<path>]

The default port is 8883.

The syntax for an MQTT URL over Web Sockets has the following form:

wss://<domain name>[:<port>][/<path>]

The default port is 443.

The current MQTT transport mapping only supports simple Username/Password authentication.

The current MQTT transport mapping does not support the concept of connection properties and any configured setting in the connection properties shall be silently discarded.

Implementations should attempt to reconnect to existing sessions (CleanSession=0) and attempt to resume message transfer at the specified QoS level.

The BrokerTransportQualityOfService values map to MQTT publish and subscribe QoS settings as follows:

• AtMostOnce_1 is mapped to MQTT QoS 0.
• AtLeastOnce_2 is mapped to MQTT QoS 1.
• ExactlyOnce_3 is mapped to MQTT Qos 2.

If the KeepAliveTime is set on a WriterGroup, a value slightly higher than the configured value of the group in seconds should be set as MQTT Keep Alive ensuring that the connection is disconnected if the keep alive message was not sent by any writer in the specified time.

The implmentation choses packet and message size limits depending on the capabilities of the OS or or the capabilities of the device the application is running on. They can be made configurable through configuration model extensions or by other means.

The current MQTT transport mapping does not support message headers. Any promoted field or additional fields defined on the WriterGroup or DataSetWriter shall be silently discarded. Implementations shall not set the MQTT RETAIN flag, except for meta data messages published to the MetaDataQueueName as described in 6.4.2.3.6.

A JSON body is encoded as defined for the JSON message mapping defined in 7.2.3.

A UADP body is encoded as defined for the UADP message mapping defined in 7.2.2.

It is expected that the software used to receive UADP NetworkMessage can process the body without needing to know how it was transported.

If the encoded MQTT message size exceeds the Broker limits it is broken into multiple chunks as described in 7.2.2.2.4.

It is recommended that the MetaDataQueueName as described in 6.4.2.3.6 is configured as a sub-topic of the related QueueName with the name $Metadata. The MQTT RETAIN flag shall be set for metadata messages.