Consultation: Resilience guidance

We have updated footnote 34 on p27 of the draft guidance document so that it links to the correct version of the NICC ND1643 standard.

We received a question for clarification regarding how the proposals in this consultation relate to DAB, SSDAB and FM broadcast.

In order to ensure that all parties have the same information, we are providing a response to the question publicly.

The security duties in s105A-D Communications Act 2003 apply to all providers of Public Electronic Communications Networks (PECN) and Public Electronic Communications Services (PECS). These duties therefore apply to DAB, SSDAB and FM broadcast providers, insofar as they are providing a PECS and/or PECN.

The draft guidance focuses on telecoms networks and services, as the main aim of the guidance is to secure the provision of networks and services which are robust, available and working well, both in the provision of voice calls and the provision of internet access services generally, given these are critical to both individual consumers and the wider economy. However, as per footnote 24 (p18), terrestrial broadcast TV/radio are listed as examples of additional access network types that fall within scope of s105A-D, and the guidance would apply to them insofar as it is relevant to the provision of these networks and services.

We received a question for clarification referring to paragraph 3 of section 4.5.3 (Resilience Mechanisms and approaches) of the Draft Guidance about: when we refer to the testing or optimisation of failover mechanisms ‘under load’, whether the ‘load’ referred to includes all subscribers or only a representative level of subscribers for a given network component.

In order to ensure that all parties have the same information, we are providing a response to the question publicly.

The relevant technical criteria or parameters for ‘load’ can vary significantly for each different network device, function, or type of function within a network. Subscriber numbers may be a relevant load metric for some network functions, but less relevant for others. Very broadly, examples of other relevant ‘load’ metrics might include: routing or forwarding table sizes, connections-per-second, messages-per-second, traffic mix (e.g. packet size distribution or distribution of QoS markings), throughput, memory usage, CPU usage, etc. This is not an exhaustive list.

For the testing of a given network device or function to be valid, appropriate testing needs to be performed with representative hardware, software, and surrounding environment with the relevant ‘load metrics’ for that given network device or function. As stated above, the relevant ‘load’ metrics for a given network device or function may vary significantly. Network architecture varies from operator to operator, and while it may not be necessary to test every network device or function under the load of all subscribers, there may be instances where it is appropriate to do.

It is often when a system or network function is ‘under load’ that it is most important to ensure that the resilience mechanisms continue to work correctly, as per the design intent.

We received a question for clarification about the application of paragraphs 4.5.2 and 4.5.3 in relation to "CP-managed" services, as per section 4.5 of the proposed new Resilience Guidance. The question asked about the relationship with 'Specialised Services' which were mentioned as an example of CP-managed services.

In order to ensure that all parties have the same information, we are providing a response to the question publicly.

In section 4.5 of the proposed Resilience Guidance, we set out what we mean by a 'CP-managed' service. Essentially, this includes all those services that a communications provider has full design and operational control of and are built within their network estate.

We point out that:

• Some of these services may be consumed by the communications provider's customers.
• Some of these services may be internally consumed by other functions within the communication provider's network, giving an example of "the authentication/authorisation and control plane aggregation/distribution functions can be seen as critical internal network-related services."

In section 4.5 and subsections 4.5.1 to 4.5.3, we indicate where we expect CPs to implement various different technical mechanisms to enhance reliability of some types of services as appropriate. We give examples as to why some of these mechanisms may be considered appropriate, including service obligations that a communications provider may have or where there are technical requirements of a given technology to ensure that the network or services work appropriately reliably.

The reference to "internal network-related services" in section 4.5 was not intended to be interpreted to in any way restrict the definition of “CP-managed service” to include only those “specialised services“ which are relevant in the context of our Net Neutrality Guidance.

We make a reference to Net Neutrality “specialised services” merely to demonstrate how our Resilience guidance sits alongside our Net Neutrality Guidance, regarding the use of these mechanisms as part of the design and implementation of “specialised services”.

The proposed Resilience Guidance should therefore not be interpreted to indicate that the types of reliability enhancements we expect communications providers to consider and implement as appropriate should only be used for 'specialised services', but are potentially relevant for all CP-managed services, including “specialised services”.