Editorial updates to Chapter 4 from Huawei

For the purposes of the present document, the terms given in Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1), prEN 40000-1-1 [\[i.4\]](#_ref_i.4) and the following apply:

1. **Service Requesting Users (<span name="_term_.SRU">SRU</span>):** users relying on the correct functioning of the network element

2. **product user:** person having the credentials to login to the NMS to operate administrative actions to control and maintain the managed element

2. **product user:** person having the credentials to login to the product to operate administrative actions to control and maintain the managed element

3. **machine user:** virtual user used to access the system programming interfaces

4. **subject:** a product user, machine user, or a process being authenticated by the identity provider

5. **component:** software or hardware intended for integration into an electronic information system

* [Enterprise network](#4621-enterprise-network)

* [Telecom network](#4622-telecom-network)

Network function management needs grow with how many Service Requesting Users [SRU] are connected to the network and what the network is used for.

The Network Functions Management typically grows in dependency of the number of the connected Service Requesting Users [SRU] and of the network purpose.

Complexity and the number of supported functions in the product is proportional to the risk level of the network.

While home networks can tolerate loss of connectivity to various streaming services, telecom networks can not stop serving critical infrastructure without a large impact to society.

## 4.2 Product Architecture

Network management systems are commonly deployed using centralized management services that provide command, control, monitoring, and administration functions.

Depending on the design and autonomy of the managed elements, some elements may continue limited operation when connectivity to the network management system is unavailable.

### 4.2.1 Network architecture

What kind of network architecture is designed and deployed with the product are interests of this document when evaluating the risk likelihood and impact.

The network architecture operating with the NMS is in scope of the present standard when evaluating the threats, risks and their impact on the network.

The network can be large with multiple managed devices or there can be multiple networks, with varying degrees of inter- and intra-connections.

The product can be deployed into the network it controls, or it can be outside of the managed network.

This virtual infrastructure has been a digital copy of the physical world.

All of these virtual devices can be independent instances of virtual machines running OS with a linux kernel because over the years, linux kernel modules have grown to support even the niche use-cases.

Only after a few iterations of cluster based application development in scale, the network requirements and how the virtual environment is implemented have started to evolve.

The paradigm shift happens, when the application design takes more responsibility from the High-Availability and the application is already expecting faults to happen.

In a fluid, often container based, environment where computational nodes can be dropped un-announced, the application execution context vanishes without warning.

It is often expected, when cluster changes are made, the application can resume its task only with minimal overhead and loss of progress when it is relaunched elsewhere.

This elsewhere can be a new node added into the pool, or the old one rejoining to the cluster after a forced reboot.

Just a few development iterations of scaled cluster based applications evolved the network requirements and the implementation of the virtual environment.

The evolvement is needed when applications increase their impact on the high availability of services and first faults become likely.

That occurs in a fluid-like, often container based environment, where computational nodes can terminate or cease operation without a warning.

This of course, impacts or terminates the application context without warning. In such a cluster-changing scenario, the operators often expect that applications resume with minimal overhead and loss of progress in their new virtual environment.

The new virtual environment can be a new node added into the pool, or the previous node rejoins the present cluster after a reboot.

With this robust foundation, where application state can be preserved over interruptions, where the state can be shared between atomical execution instances, containers, and these instances can write changes back to the state, protocol like DHCP is not needed anymore.

The container does not necessarily request an IP for the OS running as the container, but is launched with a preconfigured veth-interface where the connectivity is already available.

Where applications are able to preserve their statuses despite their changing virtual environment, and where these applications can share their statuses with atomical execution containers, these instances can change the application statuses.

These exchanges do not need the DHCP, and, the hosting OS container even does not need to request an IP address, as the OS container operates a preconfigured veth-interface ensuring the connectivity.

##### Application in a SDN

Throughout the multiple possible links in the RAN backhaul, it is possible that the traffic traverses unencrypted.

For example, routing a remote site traffic through satellites can end up in a situation, where trunk traffic is broadcasted to the ground station and near areas of it.

Considering these and similar scenarios, it is next to impossible to verify how the underlying network is configured when the traffic exits the control region of the product. This is noted later in [REQ-GEN-4] under [General requirements](#51-general).

Considering these and similar scenarios, the configuration verification of the underlying network traffic exiting the product's control region is not practical. This is noted later in [REQ-GEN-4] under [General requirements](#51-general)

### 4.2.4 Inventory, device and subjects management

#### 4.2.4.3 Device management

The connected device design can be very simplistic, where the device relies on the system to push for configurations and even update the device firmware.

The connected device’s design can be simple if there is support by the NMS with pushed configuration and firmware update services.

On the other end of the spectrum, the device can be designed to operate as an autonomous agent that requires little or no input from the NMS to manage its functions to run the workload.

NMS is defined through the need to manage the device.

The devices themselves are outside the scope of this document when the devices facing API's are not.

How the trust is established in the connected network operative security can be evaluated with the product is core components of this document.

The NMS receives its definition through the management needs of the connected devices.

The connected devices are outside the scope of the present document, but the NMS APIs communicating with them are included.

This communication needs a trusted relation which needs to be established and maintained to ensure operational network security.

This trust establishment with the connected elements is a core part of the NMS.

#### 4.2.4.2 Inventory management

### 4.3.2 Physical/Hardware environment

<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>

The product can be engineered to work in a cluster which provides required redundancy and maintenance needs.

The deliverable cluster is often composed from multiple nodes and designed to fit the customer operational environment.

The cluster the product is hosted at is often composed out of multiple nodes and scaled to fit into the operator’s operational environment.

The number of nodes and the composition of the hardware is designed to handle the expected load from the management function the product is performing.

**Table 4.8.x-1: Logical separation of duties adjacent to RFC1122**

| Capacity                  | HW engineers         | Application requests towards HW                         |

| Networking and facilities | Site manager         | Is it on? Can I walk into the premises?                 |

Above duties in the table can be organised differently depending on the delivery context.

Large deliveries often come with a support contract ensuring the product operation and continuity throughout changes in the industry, network and in the business the product is serving.

The product requirement can be defined with the abstraction layers as given in the table above, but the product is required to support the architectural design and conditions of the concrete operational environment.

There is a variety of structures and responsibility separations supporting the actual use case possible.

Also the product’s shipment and delivery procedures usually follow the system users’s needs and may also need to be conformant with critical infrastructure rules and requirements.

These responsibilities can be implemented with varying degrees of third party involvement in respected layers.

Local delivery integration customisations could be also explored as an East-West integration plane, but for the purpose of this document, all integration targets, apart from the managed devices, are addressed as RDPS.

The physical deployment planning includes, but is not limited to:

- Always available basic services the product requires for operation: power supply, climate control, environmental impact protection against weather, fire, earthquake, other physical impact

- Available network connections to the digital services the product requires or can require for operation: certificate and signature validation, backup server, logging server, timestamp server

- Physical access control to ensure access by authorized staff only

* Always available basic services the product requires for operation: power supply, climate control, environmental impact protection against weather, fire, earthquake, other physical impact

* Available network connections to the digital services the product requires or can require for operation: certificate and signature validation, backup server, logging server, timestamp server

* Physical connectivity of the networks: optical, wired or radio based

* Physical access control to ensure access by authorized staff only

When designing an on-site delivery, the customer might have to understand the following:

- EMP protection of the installation facility

- Facility location in respect to other points of interest

- Distribution and redundancy

* EMP protection of the installation facility

* Facility location in respect to other points of interest

* Distribution and redundancy

The site design is often guided by the national legislation and it varies between the EU countries.

### 4.3.x Trust initialisation

To initialize trust between the elements of the network, this type of NMS multiple can use multiple methods including but not limited to: identity confirming certificates, unique serial numbers, or stored credentials, usually in the form of pre-installed keys.

These credentials are used during initialisation to create the trust between the NMS, the networked devices and, if present, with the IoT device business logic.

Credential or key initialisation and enrollment limit the NMS's ability to establish trust between the intended devices, as does any requirement for physical access or close proximity to the IoT device to perform these actions.

For example, an IoT device user can pair the IoT device and establish a trust with the NMS through Bluetooth(tm) pairing mechanisms or with a physical cable connection.

Secure network communication needs trust establishment among the communicating entities.

The NMS initiates and establishes that trust and can operate multiple methods for this, including but not limited to: identity confirming certificates, unique serial numbers or stored credentials, usually in the form of pre-installed keys.

These methods comprise credentials assigned to each entity, and those are used during the initialization to create the trust relation between the NMS, the managed devices, and, if present, with the IoT business logic.

Secure procedures to generate and enroll the credentials enable the NMS to initialize the trust relations.

These procedures usually require physical access or proximity to the managed device, as, for instance, the human user of an IoT device can pair his device with the NMS through a wireless pairing mechanisms or with a plugged-in wired connection.

As an alternative to preconfigured devices the manufacturer may provide devices with a single DNS address that the device queries for configuration on device startup to launch a chain of events that registers the device to the correct network.

Methods of device enrollment — execution, maintenance, and how the system responds to changes, is one of the key aspects of the NMS.

With trust established the NMS can provide cryptographically protected configuration and update services to the devices at the runtime.

Depending on the NMS architectural design and configuration of the managed elements, the device can either request configuration from the NMS, or the NMS can push the configuration to the device.

On the basis of trusted relationships the NMS can provide cryptographically protected configuration and update services to the managed devices at runtime.

In dependency of the NMS capabilities and the managed devices configurations, the configuration can reach the managed element either with a pull-request to the NMS, or the NMS can push the configurations to the managed devices.

Once configured, the same channel and trusted status is used for secured identification, authentication, and communication with other applications on a device.

Independent of any of the host system's capabilities, the NMS can also be remotely accessible.