This Clause discusses how QoS monitoring information can be used for assurance purposes. For background information on assurance see [19] and Appendix A.3 in [20]. Assurance consists of four major steps (see Figure F.1-1 and [18]):

• Customer's QoS requirements
  These state the level of quality required by the customer of a service. This information is divulged to the provider.
• Service provider's offerings of QoS (or planned/targeted QoS)
  This is a statement of the level of quality expected to be offered to the customer by the service provider.
• QoS achieved/delivered
  This is the level of quality achieved and delivered to the customer. Monitoring information is divulged to the customer.
• Customer rating of QoS

The customer can compare the QoS achieved by the provider with the QoS requirements (see above) and its own experience of the QoS. This is a crucial step for establishing assurance about the fulfillment of the customer's requirements.

The start time and the duration of the QoS monitoring is specified in the parameter observation time interval, which is exchanged between the customer, for instance an application consuming a communication service, and the provider (for instance a private 5G network providing a communication service). The observation time interval is the time interval during which a series of measurements is conducted. In the context of QoS monitoring, these are the measurements necessary for assessing the QoS of communication services, for instance the measurement of end-to-end latencies. Examples of parameters to be monitored by the provider are given in Annex C in reference [36].

Network diagnostics helps with scanning, diagnosing and identifying problems within a network. Diagnostics includes gathering data and continuously providing sufficient performance parameters that characterize the quality of the network connection. This includes data of the physical connection as well as of logical links and sub-networks. Exposure of relevant (and possibly aggregated) performance parameters ensures a quick reaction in case of failure as well as identifying network connectivity, performance and other related problems. Network diagnostic should be able to:

• be proactive (to early detect failures) and not only reactive (to deal with faults that have already occurred).
• accurately differentiate malfunctions/failures and evaluate their impact on the service/network.
• provide clear explanations about what happened.
• suggest corrective actions, and possibly perform them automatically.

Furthermore, specific connectivity information is also of interest as well as usage information (e.g. traffic load) of the node (e.g. RAN). Network diagnostic information needs to be generated automatically and, in case of a hosted or virtual network deployment, be made available to the tenant of the network via a suitable API.