UAFX defines the use of different kinds of communications. For example, the exchange of control data via OPC UA PubSub, connection establishment via OPC UA Client  Server, link-local communication, e.g., LLDP (see 7.3) and gPTP (see 7.4), and remote management with NETCONF (see 7.2). To support the UAFX system operation, these kinds of communications may demand different Quality of Service (QoS) in the network.

This clause provides an overview of how the definitions in this specification can be applied to a network containing UAFX  Stations (see 6.4.3) and other IA-stations (see 6.4) such that Connections can be handled with appropriate QoS. UAFX Stations can use Best-Effort or priority-based QoS for OPC UA PubSub traffic with this release. In addition, enhanced priority-based QoS can be achieved in the network using the TSN mechanisms selected in this specification.

To decouple the QoS specification for applications created during the application engineering phase from the actual QoS configuration in a given network, Controls Engineers define the application's QoS needs in the form of abstract QoS categories and labels. Similarly, Controls Engineers can use abstract network interface names to allow the use of VLANs as needed, e.g., for priority-based QoS at the Ethernet layer. The OPC UA Communication Stack then uses a PriorityMappingTable (see OPC 1000022) to translate the abstract QoS category and label of a Connection to concrete priority values in the message. Similarly, the UA Communication Stack can use the representation of VLAN interfaces in the OPC UA Information Model to resolve abstract VLAN interface names to VLAN IDs in the transmitted packets.

Table 1 defines a recommended usage of priorities for various types of traffic in networks containing UAFX Stations. Combined with the traffic class mapping priority defined in 6.4.3, these recommendations provide consistent, system-wide behaviour for networks that do not currently use the recommended priority values for other purposes.

Table 1 – Recommended PCP/DSCP usage

PCP	DSCP	Recommended usage
7	–1	Reserved
6	–1	Reserved
5	48	Network control2 (gPTP, LLDP, loop prevention)
4	46	Green4 (UA PubSub, see 6.5.4)
3	–1	Reserved
2	16	Connection establishment (UA Client Server3), remote management2 (NETCONF)
0	0	Best Effort
1	8	Background
NOTE 1 The order of the entries in the table are in the order of effective priority of the packets on the network and not in the order of priority values (PCP and DSCP). NOTE 2 IEEE Std 802.1Q2018, I.4 explains the rationale for inverting PCP 0 and 1. PCP of 0 is used for default priority and Best Effort. Tagging a frame with PCP 1 allows explicit indication of traffic that can be treated with a lower priority than Best Effort. This same rationale applies to the default Priority to Traffic Class Mapping in 6.4.3. NOTE 3 The DSCP values for Network Control, Best Effort, and Background have been selected from IETF RFC 4594, Figure 3. NOTE 4 The DSCP value for GREEN is selected from the IANA DSCP Pool 1 Codepoints registry value for Expedited Forwarding defined in IETF RFC 3246. NOTE 5 The default PCP and DSCP values for any type of traffic without explicit priority configuration are equal to Best Effort.
1 Additional DSCP values may be defined in a future release of this specification. 2 Currently, there is no OPC UA means for the assignment of priority information for these services. This is expected to be added in a future release, e.g., through IEC/IEEE 60802. 3 The OPC UA Information Model currently does not allow the assignment of priority information for UA Client Server messages. A future release is expected to allow UA Client Server QoS configuration in addition to UA PubSub. 4 “Green” corresponds to the OPC UA PriorityLabel opc.qos.lbl://green, which this release of the specification supports for OPC UA PubSub-based exchange of control data with UAFX.

Following the concept of decoupling the application from the network configuration and in concert with the PCP values defined in Table 1, 6.5.3 specifies a default, abstract VLAN interface name and associated VLAN ID value. In deployments intended to use priority-based QoS at the Ethernet layer, this abstract VLAN interface name can be used for ease of use during Connection engineering if the VLAN interface name has not explicitly been adapted. Moreover, the mapping from the abstract VLAN interface name to a concrete VLAN ID can still be adapted prior to connection establishment (see 5.2.5). This decoupling allows for any necessary adjustments, e.g., if the default VLAN ID is already in use or deployment-specific requirements demand the use of a different VLAN ID.

Priority-based QoS at the Ethernet layer also relies on the consistent support and configuration of VLANs in the network containing UAFX Stations. Therefore, it is recommended that all Bridge Components (see 6.2) in such networks are configured to forward VLAN-tagged Ethernet frames with the VLAN IDs used by the attached UAFX Station. The overall configuration results in tagged and untagged traffic originating from a UAFX Station.

NOTE: If an End Station Component cannot receive both tagged and untagged frames on the same network interface, VLAN stripping on egress at the connected Bridge Component port or local means, e.g., ignoring the VLAN tag in the network stack, allow reception of frames that were originally sent with a VLAN tag.

Figure 2 shows an example of an application running on two Controllers using different priorities on a network. One priority carries OPC UA PubSub messages with an elevation to PCP 4, and another carries all other messages in the same lower priority, including OPC UA Client Server.

Figure 2 – UAFX example application with QoS

The following subclauses describe an example workflow to achieve the configuration and operation shown in Figure 2. As mentioned in 1, with this release, vendor-specific means are required for all networking-related End Station and Bridge Component configurations, including VLAN configuration, time synchronization, and QoS.