FAQs on the NCSC’s advice on the use of equipment from high risk vendors in UK telecoms networks

‘Equipment’ refers to any telecommunications function, or group of functions, that read, modify or otherwise process data in support of a telecommunications network. This includes all components that are used to perform the function(s), be they software, firmware or hardware.

Equipment is ‘from an HRV’ or ‘has HRV involvement’ if the HRV is in any way involved in the supply or install of the equipment into the operator’s network.

The NCSC has stated that operators should be able to comply with the advice within 3 years. Hence by 28th Jan 2023.

This advice applies to all operators of public telecommunications networks and services for the UK.

The advice applies to network equipment or functions which provide telecommunications services to the UK, regardless of where this infrastructure is hosted.

Yes. Operators should also consider that successfully managing the presence of an HRV requires active risk management on the part of the operator.  

No. The 35% cap is to minimise national dependency and applies to operators individually. The 35% cap should be assessed, based upon the operator’s own sites/network functions, not those of other operators. Operators should, where appropriate, seek to minimise their dependency on any vendor or supplier through active management of their supply chain.

Our advice is that the 35% cap applies to each UK entity individually, based upon the operator’s own sites, infrastructure and network functions. The cap calculation should not include the sites, infrastructure or network functions of other operators.

This advice does not apply to private networks, except where these networks are safety-related or safety-critical. Where networks are safety-related or safety-critical, HRVs should be excluded from involvement in the networks. See Section 8 for further details.

If HRV equipment is being deployed within other critical sectors, we recommend that government is informed at the earliest opportunity. Government will continue to monitor the use of HRVs in other critical sectors and will keep this position under review.

In the telecommunications sector, it is common for operators to use third parties to provide managed services, and for the equipment vendor to provide third-line support. These require very different types of access. Managed services involve daily access to the network to monitor or modify network behaviour. Third-line support involves infrequent access to the network to fix a significant equipment fault that could not be resolved through a configuration change.

It is rare for companies to have a managed service contract with an HRV. In these cases, we recommend that operators speak to us directly.

However, HRVs can continue to provide third-line support for the equipment they supply, where this access is properly managed and overseen.

The advice only applies to infrastructure/equipment/functions that read, modify or otherwise process data in support of the telecommunications network.

The scope of this definition includes equipment that may not be seen as ‘within’ the network, but that reads, modifies or otherwise processes data in an essential support function, such as the power control systems and cooling management systems that support telecommunications infrastructure.

The advice does not apply to physical masts/poles, cabinets, passive antennas, optical cables, power cables or fans.

At the present time Huawei and ZTE have been assessed as HRVs. Operators should use the factors set out in NCSC’s HRV advice to consider whether they have any other vendors that may be considered as high risk. If operators identify companies of potential concern, we recommend that operators notify the NCSC and we will aim to provide advice on risk.

HRV element managers (e.g. Huawei EMS) are permitted within a secure management architecture. It is essential that element managers can only communicate with the HRV devices that they manage, and no network infrastructure provided by other vendors. Additionally, admin access to element managers must only be permitted via administration infrastructure (e.g. jump box).

Our advice also states that HRVs should not provide hypervisors or NFVI, hence where virtualised, these functions will need to run on another vendor’s NFVI.

Element managers can involve orchestration and automation, provided they only interact with the HRV devices they manage.

The IP Core includes any functions which perform IP/MPLS switching or routing across the core of an operator’s network. Generally, it does not include edge devices or routers, such as gNB, OLT or BNG functions, provided that these functions cannot impact IP Core routing/switching (for example, do not act as a PE-node for an MPLS network). 

Operators should determine the size of two sets:

P: The premises passed by the operator using gigabit and higher capable access networks. Typically, each premise will have a unique customer termination point (e.g. ONTs) attached to the network.

P(HRV): the subset of premises within ‘P’, where a non-passive function of the access connection (e.g. OLT) is provided with HRV involvement.

Based on these sets, operators should ensure that the following equation is true¹:

As an example, if an operator provides a fibre service to 20m homes, presumably with the potential to support 20m active ONTs, then:

Meaning that at most 7m homes may be served by equipment where there is some HRV involvement.

Operators should also ensure that equipment quantities are also within the cap as described in Q5.4.

^{1 Where ‘#P’ is used to denote the size of the set ‘P’.}

Firstly, operators should classify their sites based upon type (e.g. small cells, macrocells). For example, the ITU has defined five basestation classes within ITU-T K.100. These classes (E0, E2, E10, E100, E+) determine where and how the equipment should be deployed.

Secondly, for each class, operators should determine the size of two sets:

S_[class]: the set of sites supported by the operator of a particular ‘class’ that are providing Rel-15 or later features or functionality to handsets/UEs. Note that this could include upgraded 4G sites.

S_[class](HRV): the subset of sites within ‘S_[class]’ where a non-passive function of the basestation is provided with HRV involvement.

Based upon these sets, operators should ensure that, for every class, the following equation is true²:

In other words, our advice is that for each class, the percentage of HRV-supported sites is at most 35%. Correspondingly, at most 35% of small cells and at most 35% of macro cell functions may be from an HRV.

Only the sites operated by the operator should be included in this calculation. Consequently, RAN-sharing agreements do not impact this calculation.

For the avoidance of doubt, the cap applies to any sites which are offering ‘5G’ (3GPP Rel-15 or later) features or functionality to handsets. Hence if a site offers any 5G functionality, it is a ‘5G site’ and is included in the cap. ‘Dynamic Spectrum Sharing’ across 4G and 5G is a 5G feature and hence sites with this capability are included in the cap. However, if it is capable of offering 5G functionality, but these features are disabled, it is not included in the cap.

As an example, if an operator has 20K macro cell sites (class E+) and has updated or upgraded 6K of them to support Rel-15 or later features (#S_E+ = 6000). If additionally, the operator has 2K small cells (class E10) and installed or upgraded 1K of them to Rel-15 or later features (#S_E10 = 1000). Then:

And:

Hence, the operator may have up to 2100 Rel-15 or later macro cell sites with non-passive components from an HRV, and at most 350 Rel-15 or later small cell sites with non-passive components from an HRV.

Operators should also ensure that traffic quantities and equipment quantities are also within the cap, as described in Q5.3 and Q5.4.

_{2 Where ‘#S’ is used to notate the size of the set ‘S’.}

The traffic cap should be calculated based on the total traffic passing through ‘5G’ sites over a year. It is based on the traffic routed over the network from UEs within the following two sets:

U: The set of UEs where the operator’s RAN is offering features or functionality defined in 3GPP Rel-15 or later.

U(HRV): The subset of UEs within ‘U’ where some non-passive aspect of basestation connectivity has HRV involvement. To be clear, where a UE is supported by multiple basestations, HRV involvement in either function would cause the UE to be within the set. In the case of 5G Option 3A, this would apply if the HRV is involved in either the eNB signalling anchor, or the gNB carrying 5G traffic.

Based on these sets, operators should ensure that the following equation is true³:

The advice applies to traffic going over the operator’s RAN regardless of the destination core network, or the customer relationship. Traffic from another operator’s RAN is not included in the calculation, but MVNO or RAN-share traffic going over the operator’s own RAN is included.

For the avoidance of doubt, the traffic quantities are only calculated for handsets offered any 5G (Rel-15 or later) functionality, regardless of whether the handset uses that offered functionality. Hence, it will generally be calculated based on the amount of traffic going through the ‘5G sites’ identified in Q5.2. However, if a UE is passing traffic through both 4G and 5G sites (e.g. 5G’s Non-Stand Alone Option 3), that UE has been offered a ‘5G’ feature and all that UE’s traffic should be included in the cap, regardless of whether the traffic is routed through a 4G or 5G basestation.

As an example, if the operator routes 10PB of data over a year, from UEs which are being offered Rel-15 or later features by the network, then ∑year|U|=10PB. In this case:

Consequently, over the course of that year, the operator may route up to 3.5PB from UEs offered Rel-15 or later functionality, where the support of a HRV function is utilised.

Where the precise traffic quantities cannot be calculated, then the use of reasonable, unbiased estimates of traffic quantities over network elements may be sufficient.

Operators should also ensure that site numbers and equipment quantities are also within the cap, as described in Q5.2 and Q5.4.

_{3 Using the notation that |U| is the traffic routed over the network from UEs within the set U, and ∑year|U| is the traffic routed over the network throughout a year from UEs within the set U.}

This cap is intended to apply to physical quantities of equipment. Operators should determine the size of two sets:

E_[class]: the set of the operator’s physical equipment of a particular ‘class’ performing a function within the 5G access network or the FTTP and other gigabit or higher capable fixed access networks.

E_[class](HRV): the subset of physical equipment within ‘E[class]’ where a non-passive function of the equipment is provided with HRV involvement.

Based upon these values, operators should ensure that, for every class, the following equation is true⁴:

Only the operator’s equipment should be included in this calculation. Other operator’s equipment should not be included, even if the operator uses this equipment to support part of their network.

Classes of equipment are deployment dependent, but as an example, the following may be appropriate equipment classes:

5G: gNB DU, gNB CU, gNB small cell, etc.

GPON: ONT/ONU, OLT

Operators of fixed networks should also ensure that premises passed are also within the cap as described in Q5.1. Operators of 5G networks should also ensure that site numbers and equipment quantities are also within the cap, as described in Q5.2 and Q5.3.

_{4 Where ‘#E’ is used to notate the size of the set ‘E’.}

When functions are virtualised, HRVs are excluded from providing NFVI and hence the 35% cap is not relevant to the physical infrastructure or hypervisor.

The use of virtual HRV functions should then be limited based on number of premises (for fixed access networks as described in Question 5.1), and number of sites and traffic quantities (for 5G networks as described in Question 5.2 and 5.3).

No. See Section 6 below.

Regardless of the technology, where operators are making a significant access deployment, they should use at least two suppliers, aiming for a relatively even split. Operators should also consider whether the use of the equipment will be safety-related or safety-critical.

Government will continue to monitor the market share of HRVs in other access technologies and will keep this position under review.

The NCSC views ‘transmission equipment’ as a function which transmits or receives data over a physical medium (such as optical fibre or microwave RF) in support of a single network link. Transmission equipment only interacts with the data to the extent necessary to support the transmission of data (e.g. at OSI Layer 1). Transmission equipment does not support IP/MPLS switching or routing.

Under this definition, the HRV advice does not apply to transmission equipment where this equipment used to move data around the access network, or to backhaul data from the access network towards the core.

As with all aspects of the position on high risk vendors, the Government will keep this position under review.

The HRV advice does not apply to routing equipment in the access network, so long as this routing equipment cannot influence routing across the core network (e.g. the access routers are not part of the IP Core and do not apply MPLS, or equivalent, tags that determine core routing).

Yes. The HRV advice does apply to high data rate transmission and routing equipment used to connect core data centres (e.g. core-layer OTN), for peering used to connect operator networks or used over international connections (e.g. long-haul OTN). These are viewed as core/interconnection equipment and our advice states that HRVs should not be used to provide this equipment. 

Sensitive sites are locations where traffic metadata, such as number of connected devices and quantity of traffic, is unavoidably sensitive. For the most part, this applies in rural locations which host particularly sensitive operations. Provision of telecommunications services to these locations needs to be carefully managed.

Details of sensitive sites will be shared in due course. We anticipate that the number of sites will be small.

It includes mobile access and supporting transport links. It does not apply to fixed networks.

The advice applies up to the point where traffic metadata is no longer sensitive, due to the aggregation of traffic. This will often be up to a major network aggregation point. 

This does not apply to fixed networks. However, sensitive customers may have their own specific requirements when procuring telecommunications services. 

No.

Yes, we would advise that operators speak to us when deploying RF equipment that covers sensitive sites.

These terms are defined in IEC/BS/EN 61508. Specifically, the following definition of ‘safety-related’ is extracted from the document:

The term safety-related is used to describe systems that are required to perform a specific function or functions to ensure risks are kept at an accepted level. Such functions are, by definition, safety functions. Two types of requirements are necessary to achieve functional safety:

• safety function requirements (what the function does) and
• safety integrity requirements (the likelihood of a safety function being performed satisfactorily).

The safety function requirements are derived from the hazard analysis and the safety integrity requirements are derived from a risk assessment. The higher the level of safety integrity, the lower the likelihood of dangerous failure.

Typical safety-critical and safety-related systems include:

• Transport systems such as railway signalling systems and aircraft operations.
• Power systems, such as power grid control systems.
• Civil Nuclear systems, including industrial control systems.
• Chemical process control and similar systems.

Assuming that once outside of your control these communications are both securely encrypted and resilient (e.g. using diverse links), then it is not necessary to ensure that the links do not contain HRV-supplied equipment.

Our advice is that the presence of an HRV in the UK market should be contingent on the existence of a mitigation strategy as defined by government. Where there is no agreed mitigation, we would advise against use of the HRV in UK networks, and that the equipment is replaced.