Quality of Service (QoS) is a set of techniques to manage resources within a communications network. This page provides details of QoS implementation across HSCN.
Quality of Service (QoS) is a set of techniques to manage resources within a communications network. NHS Digital sets the QoS policy for the Health and Social Care Network (HSCN).
The required quality of service can be by achieved by managing the delay, delay variation (jitter), bandwidth, and packet loss parameters on a network. The HSCN utilises QoS to ensure that key traffic is prioritised over less important traffic during times of congestion.
The HSCN operates a 6-layer QoS model. The 6-layer model refers to the way in which QoS segments network traffic into different classes. A defined configuration, typically within the router at the egress point of a network, applies QoS 'markings' to data packets. These markings identify the class of service to be applied to that data in the event of network congestion. A QoS configuration can be applied to each point (also known as a 'hop') in a wide-area network. This enables a 'Per Hop Behaviour' (PHB) to be applied to traffic at each of these points so that key data is given the appropriate priority by the routing device.
The diagram below shows how QoS classes are configured. The grey pipe represents the overall bandwidth or Committed Data Rate (CDR) of the connection. Each QoS class has a priority and a guaranteed minimum bandwidth which is designed to ensure that application traffic can still be routed in the event of network congestion. The guaranteed minimum bandwidth is set for each QoS class as a percentage of the overall bandwidth (or CDR). It is represented in the diagram by the smaller coloured pipes. When network congestion occurs the QoS configuration determines how traffic is processed by the router.
Figure 1 - a graphical representation of how QoS classes are configured for HSCN
The HSCN QoS model uses a technique known as 'percentage-based policing' to determine the minimum amount of bandwidth that is reserved for each QoS class in the event of network congestion. This feature provides the ability to configure traffic policing and traffic shaping based on a percentage of the bandwidth available on an interface.
The 6 layer QoS model for HSCN will initially adopt the per-class percentages shown in the table below. Note that this configuration is under review and may be subject to change.
% of CDR
Traffic types for each QoS Class
The HSCN 6-layer QoS model is designed to support different types of network traffic. These classes are:
EF - Expedited Forwarding - Voice over IP (VoIP) telephony
EF is the highest priority class and provides a (normally) small amount of dedicated bandwidth with an assured performance for real-time applications such as IP telephony.
AF1 - Assured Forwarding 1 - bulk data transfer
AF1 is used for applications that move large volumes of data such as medical imaging transfer or backup traffic.
AF2 - Assured Forwarding 2 - local and community applications
AF2 is used within local or regional health and social care natural community networks for transactional/interactive applications.
AF3 - Assured Forwarding 3 - national transactional applications
AF3 is used only for transactional/interactive strategic 'National Applications'. National applications are those that are centrally hosted and/or contracted by NHS Digital.
AF4 - Assured Forwarding 4 - media streaming
AF4 is used for multimedia applications such as video conferencing, as well as Voice over Internet Protocol (VoIP) signalling.
DE - Discard Eligible (also referred to as Best Effort)
This is the 'default' class into which all traffic not assigned to an EF or AF QoS class is placed. DE is the lowest priority QoS class.
The QoS minimum guaranteed bandwidths are only enforced by the network device when an interface is congested. If there is no other traffic using the connection, traffic in the AF class or DE may burst to 'link speed', depending upon the particular QoS configuration. EF traffic cannot burst as it is configured with a hard limit. An example of how traffic can burst above its guaranteed minimum bandwidth is shown in the diagrams below. The diagrams assume the link is split between 3 QoS classes. Blue represents EF, purple is AF traffic, and yellow is DE.
Figure 2: Example of traffic bursting on a QoS-enabled framework
Where QoS markings are applied
The diagram below provides a high-level illustration of the points in the network at which QoS markings are added to packets and where those markings should be honoured. QoS markings are typically added to packets at the egress customer premises equipment (CPE) of the originating network. QoS markings are honoured, that is, preserved, and executed as required, as they traverse each CN-SP network.
QoS will not be implemented for the HSCN Peering Exchange but markings will be left unaltered on packets that traverse it.
Figure 3: High level view of where QoS markings are applied to data packets and where they are honoured
QoS configuration change requests
This section describes the processes to be followed by consumers of HSCN services and national application providers, to request a change to a QoS configuration.
The majority of requests for changes to QoS configurations will relate to a particular application, the source/destination IP addresses and/or the 'TCP/UDP Port Numbers' used to assign traffic to a specific QoS layer. The HSCN QoS policy document, and supporting guidance and forms refer to these requests as 'QoS Application Change Requests'.
Such change requests may include:
adding new IP addresses and/or port numbers to a specific QoS Class of Service for a new or existing application/service
removing or making changes to existing IP addresses and/or port numbers for an application
re-assigning an application (IP address and/or port number) to a different Class of Service
On the form, provide as much detail as you can, including: full contact details; information about the application and the reason for the configuration change; and the QoS class, IP address, and port/protocol (if applicable).
The request will be added to the NHS Digital Service Management system and a ticket will be raised and issued to the HSCN team who will assess the request. You will receive tracking notification from the NSD.
The HSCN team may require further information from you. This will be requested by the NSD.
It may take up to 20 business days to assess your request, though most should be processed more quickly.
Once the HSCN team have processed your request you will receive a response from the NSD team.
Figure 4: Process flow diagram for HSCN QoS configuration change requests.
QoS application change requests
The AF3 Class of Service is reserved for national transactional applications. National applications are those that are centrally hosted and/or contracted by NHS Digital. The term transactional refers to the way in which the application operates, for example, transaction-orientated applications are typically used for data entry and retrieval transaction processing on a database management system or similar software application.
All QoS application change requests to the AF3 class of service must be submitted to NHS Digital. To do this use the QoS change request form, and complete sections 1 and 2.
National applications are those that are centrally hosted and/or contracted by NHS Digital. There are a number of national applications that make use of QoS classes other than AF3.
All QoS application change requests from national application providers, applicable to any class of service, must be submitted to NHS Digital. To do this use the QoS change request form, and complete sections 1 and 2.
EF and non-protected AF QoS classes
The Expedited Forwarding (EF) QoS class is reserved solely for real-time applications and services such as VoIP. The Assured Forwarding QoS classes other than AF3 are designed to be used for different types of applications; AF1 for bulk transfer; AF2 for local/community applications; AF4 for voice signalling purposes and media streaming applications such as video conferencing.
All QoS application change requests applicable to these classes of service, from organisations that do not provide national applications, should be submitted to your HSCN CN-SP.
Other QoS change requests
To request a change to a QoS configuration that is not covered by the sections above please use the QoS Change Request Form and complete sections 1 and 3.
End-to-end QoS configuration
Following the approval of a QoS Application Change Request there are a number of important steps that the application provider and their customers must follow. This is to ensure that QoS markings are applied correctly to traffic originating at both the provider and customer end points. This will help ensure that data packets are marked correctly and the required minimum bandwidth for traffic in both directions is guaranteed in the event of network congestion.
National application providers and their customers
Following NHS Digital approval of a QoS application change request from a national application provider, the following steps must be completed:
The national application provider must submit a request to their CN-SP for the change to be applied to the customer premises equipment (CPE) at the site at which the application is hosted (such as a data centre)
The national application provider must inform all customers that the QoS configuration change has been actioned and provide details of that new configuration
Customer organisations are responsible for submitting a QoS application change request to the CN-SP for all sites at which users of the particular application are located. This is to ensure that the required QoS markings are applied to traffic from the end-user sites
NHS Digital will maintain a 'master' list of national application QoS configurations and upon approval of a change request this list will be updated and shared with all CN-SPs via the National Service Desk. The master list must be used by CN-SPs to configure their systems to honour/preserve QoS markings applied to traffic that passes between provider networks.
Other application providers and their customers
This section applies to change requests to classes other than AF3 (EF and non-protected AF QoS classes) from application suppliers and organisations that provide 'local' or regional applications. For these changes, the requesting organisation must submit the QoS application change request directly to their CN-SP. Once this has been approved by the CN-SP, the requester organisation must:
Inform all customer (end-user) organisations that the QoS configuration change has been actioned and provide details of that new configuration.
Customer organisations are responsible for submitting a QoS application change request to the CN-SP for all sites at which users of the particular application are located. This is to ensure that the required QoS markings are applied to traffic from the end-user sites.