1. O&M NOC Introduction

The network operation center (NOC) is a functional team that specializes in monitoring, troubleshooting and responding to undesired events on a network which have a direct or potential impact on the networks availability and performance, or affecting end users. NOC services and responsibilities include, amongst others:

• Registering all alarms and incidents as trouble tickets (TT) and assignment of each TT to the appropriate area or service responsible for their timely resolution.
• Undertaking appropriate actions in relation to any alarm from the network in order to identify, diagnose, isolate, contain, stop and resolve the event causing the alarm.
• Managing information regarding the execution of any activity that will or could impact/affect the network.
• Reporting the current network status to relevant stakeholders at any time.

This module presents an introduction to the functions, processes and tools that operate within a NOC, and establishes guidelines for the NaaS operators to define the structure of their own NOC, customize the processes that will be implemented, evaluate and select the tools that will support the operation, and define the implementation model to be followed along with the dimensioning of the NOC team and facilities.

1.1 Module Objectives

This module will immerse the NaaS operator into the functions and processes of the NOC and will provide the necessary directions to define processes and resources and identify required systems for the NaaS operators NOC. The specific objectives of this module are to:

1. Provide a generic overview of a network operation center, providing guidance to the NaaS Operator to define the NOC basic structure according to their requirements and capabilities.
2. Enable the NaaS operator to customize the core processes to be implemented at the NOC, including roles and responsibilities, and the corresponding process flows.
3. Provide a high-level view of the tools that support the processes of a NOC, enabling the NaaS operator to identify the required tools to be part of their solution.
4. Provide guidelines to assess the NOC implementation model, including the dimensioning of the team and determination of the NOC facility requirements.

1.2 Module Framework

The module framework in Figure 1 describes the structure, interactions and dependencies among different NaaS operator areas.

Strategic plan & scope and high-level network architecture streams drive the strategic decisions to forthcoming phases. Operations & maintenance stream comes after network deployment to oversee and support the on-going operation of the network, supported by supply chain management.

The NOC is the heart of the operations & maintenance stream as it coordinates with the service operation center (SOC) and triggers actions on the field maintenance stream.

Figure 1 — Module Framework

Figure 2 presents a functional view of the NOC module where the main functional components are exhibited.

Figure 2 — Network Operations Center Functional View

The rest of the module is structured as follows: overview of fundamental concepts of the NOC is addressed in section 2. Then, each function and its processes are discussed in sections 3 and 4 of this module. Section 5 provides a high-level view on systems. Finally, section 6 discusses implementation issues including staffing and facility dimensioning.

2. NOC Fundamentals

This section provides an overview of the NOC, including the organization structure and the scope for each team highlighting the relevance and potential impact for NaaS operators.

2.1 NOC Overview

The NOC is the entity responsible for monitoring and responding to any alarm or unwanted condition that may have an impact on the network, potentially affecting end customers. The NOC can be considered the first line of defense against any disruption on the network. The NOC enables centralized supervision, control and maintenance of all equipment and network domain elements on a NaaS operator network.

A NOC responds to deviations from a normal network status like:

• Electrical events — such as power outages
• Transmission events — such as backhaul, fronthaul or backbone failures
• Hardware events — such as component failures
• Software events — such as configuration changes
• External events — such as DOS attacks

The NOC will analyze the situation, perform troubleshooting, engage necessary fix agents, and follow up until the network has restored to the previous, normal condition.

The main responsibilities of the NOC may include:

• Monitoring of all critical network elements
• Identification of failures and network degradations with both a reactive and proactive approach
• Determination of network availability and performance
• Event and incident management including escalations to expedite failure restoral
• Change and configuration management
• Documentation of all failures and performance issues
• Reporting on possible optimization scenarios based on trends

The main responsibility of the NOC is to react as quickly as possible to any problem that may arise on the network, getting out in front of issues and fixing them before they impact their end customers or other MNO end customers. The benefits that a NOC organization brings to NaaS operators are:

• A NOC responds efficiently to network deviations on a 24×7 basis, improving customer experience and company brand.
• Provides a central location to communicate or get information about any incident on the network, acting as a central control for communications with the ability to deliver the status of the network as a whole or a portion of it at any given time.
• The NOC offers a solution that can guarantee service levels and availability for the network, since all deviations are detected in a timely manner and fixed as soon as possible, minimizing response times, and maximizing the element availability.
• On high impacting events, the NOC becomes the command and control center for the situation, including all the reporting and the knowledge of the event.

Additionally, the NaaS operators NOC must consider the implication of having as customers one or several MNOs, each of them with their respective NOCs. The coordination between the different NOCs will generate additional inputs and steps on the NOC processes, which will be discussed in section 4.

Coordination must be established between the NOC entities. The collaboration can be implemented at different levels such as:

1. Ticketing
2. Fault management
3. Billing / revenue reconciliation
4. Performance monitoring

These levels of collaboration need to be established between the NaaS operator and the customer MNOs to efficiently combine their efforts. The different interactions between the NaaS operator NOC and the NOCs from other MNOs will be explained in detail in section 6 and is graphically represented in Figure 3.

Figure 3 — Network Operation Center Functional View

It should be noted that the customer care from the NaaS Operator should only be present when the NaaS Operator manages their own end-users (i.e., subscribers). This approach is out of the scope of this module.

2.2 NOC Organization

From a functional view, the NOC includes the following services:

• Network surveillance
• Fault management (tier 1 and tier 2)
• Performance management
• OSS and tools management
• Access management
• Field dispatch

These functions will be covered in-depth on Section 3 of this module, where appropriate guidance will be provided for the NaaS operator to define the structure that best matches the intended scope of the organization.

The functions above are integrated into processes, which are executed by the NOC. From a process view, the NOC includes the following responsibilities:

1. Event management
2. Incident management
3. Problem management
4. Change management

These processes will be covered in Section 4 of this module. The NaaS operator will be presented with alternatives to customize the processes according to their requirements and capabilities. Its important to consider that the NaaS operator processes will have inputs and outputs from/to NOCs from customer MNOs. These collaborations imply variations to the processes, based on the business and operational model in addition to the responsibilitys division between the NaaS and other MNOs. Guidance to define the business and operational model along with the responsibility split is provided in section 6.

The diverse teams working within the NOC organization coordinate their efforts in order to prevent or minimize any unplanned interruption on the network, or a reduction/degradation in the quality of the service delivered to the end-user. The main roles and responsibilities are summarized below:

• Network surveillance is recorded by the fault management tier 1 team and escalated to the fault management tier 2 team if applicable to fix the event at hand.
• Access management is invoked when field assistance is needed and access to premises is required.
• Incident managers supervise all incident life cycles and follow up on high-impact incidents until resolution.
• Problem managers investigate the root cause of high impact or recurring incidents.
• Change managers are responsible for network configuration and the coordination and implementation of all changes in the network
• Performance managers overview performance or quality degradation problems in the network
• The OSS & tools team supervises all the tools used within the network

This module will enable NaaS operators to examine the different scenarios and to choose which functions could be merged in their operation according to their scope.

⇐ Previous

3. NOC Functions

This section defines the NOC from a functional level, focusing on its vital aspects and the configuration possibilities for the NaaS operator.

3.1 NOC Functions Overview

In the following subsections, the description for each function of the NOC is presented along with an analysis of the key metrics and the relevance/need for each function.

3.1.1 Network Surveillance

Network surveillance is the first and most vital function that is supported by a NOC. NOC staff performs continuous monitoring of all the network elements, using available tools like a network monitoring system (see Network Monitoring Architecture module) or via the different element management systems (EMS) provided by equipment vendors. In addition, the NaaS Operator must grant limited access to these systems to the MNO NOCs to monitor only the elements of the network related to their users.

For those network or performance alarms detected, NOC staff will conduct preliminary filtering (such as correlation, alarms due to planned work, etc.), open the corresponding trouble ticket (TT), monitor the alarm warnings, categorize/prioritize the alert severity and handle the problem escalation according to defined procedures. During this stage, a constant communication between the tenant NOCs and the NaaS operator NOC will lead to a better categorization, filtering and avoidance of unnecessary TT.

Network surveillance function typically includes the following activities:

1. Real-time alarm monitoring of the network health status
2. Real-time alarm monitoring of all alarms (available via EMS/UNMS)
3. Alarm monitoring of the network performance and the network service stability
4. Isolate network alarm or event to the appropriate group for resolution
5. Filter alarms resulting from scheduled events or maintenance work
6. Combine and group alarms (correlated alarms) with common fault reasons
7. Record and collect fault information and initiate trouble ticket request to fault management
8. Initiate recovery actions and notification procedures
9. Escalate TTs to NOC second level support or any other area involved, according to the defined service level
10. Other contractors and third-party escalation
11. Liaise with customer NOCs for fault- and performance-related problems reporting (for example, a problem may affect only one MNO so the combined reporting may lead to the isolation of the impact).
12. Interface with external service providers or interconnect carrier/operator (for example, leased line provider, fixed network or international signaling carrier) for fault-related reporting

Network surveillance is the most critical function in the NOC. Since this is the function that monitors incoming alarms and events on the network, it is the first-point entry for network status and enables responses in a timely manner which translates into an overall improvement of restoration times.

Typical metrics used to evaluate the performance of this function are:

• Percentage of acknowledged alarms vs total alarms — Measures the number of alarms the NOC receives and positively identifies.
• Percentage of alarms per MNO vs total alarms — Measures the number of alarms the NOC receives and only affects a specific MNO.
• Maintenance-related alarms positive identification — Measures that all alarms identified as being part of maintenance/planned work were correlated in a correct manner.
• Alarm response time — Measures the time it takes the NOC to identify and respond to an alarm, obtaining the percentage of alarms with response time within a targeted and predefined time.

3.1.2 Fault Management Tier 1

Fault management (tier 1) function includes fault analysis, first-level corrective maintenance, End-to-End (E2E) fault management and incident management. The purpose is to filter and solve most of the cases without on-site intervention or additional resources within the timeframe specified by service levels.

Fault management (Tier 1) functions include the following tasks:

1. Acknowledge tickets/reports from network surveillance, preventive maintenance, performance management
2. Classify the fault severity to meet the service level requirements. Severities may be defined as critical / major / medium / minor
3. Conduct tier 1 fault isolation, diagnosis and solution on the impacted equipment
4. TT correlation with the existing ones or creation of a new one
5. Escalate or assign the TT
6. Remote corrective actions if the problem can be tackled without on-site intervention
7. When on-site activities are required, escalate to field maintenance team to dispatch workforce
8. For complex faults, escalate the TT to second level support (tier 2)
9. Keep track of the TT status and perform management escalation if not resolved within the agreed time frame
10. Collaboration for alarm correlation, initial troubleshooting, and corrective activities with involved MNO customers (if applicable) besides national and international interconnection partners/carriers and external service providers

It is imperative that the NaaS operator NOC and the NOCs from customer MNOs have constant communication when issuing TT to avoid duplicity and waste of technical resources. The best approach is through a direct connection of the ticketing systems of the respective NOCs, but since compatibility may be an issue, a primitive method could be used such as phone calls to open TT from customer to NaaS Operator.

The fault management function is the second most vital function within a NOC. The group that executes this function assures that alarms that were acknowledged in the previous step are worked and eventually resolved, contributing to the overall network performance and as a result, having an impact on customer satisfaction.

The most common metrics used to evaluate this function are:

• Trouble ticket opening — Measures the time in which a ticket is opened, usually measured against each severity category (critical, major, medium, minor). This can also be categorized per MNO, depending on the opener.
• Effective fault severity identification — Measures that tickets are opened with the correct severity according to predefined definitions for categorization.
• Escalation time — Measures the average time spent by the fault management tier 1 team on initial fault isolation and diagnosis before escalating the ticket to the corresponding fix agent. This can also be categorized per MNO, depending on the TT opener.
• First time right — Measures the percentage of tickets that were resolved by the first fix agent the ticket was escalated to. This can also be categorized per MNO, depending on the TT opener.

Similarly, it is recommended that the fault management systems from the NaaS operator and customer MNOs work together or be interconnected to minimize communication time. One implementation option is to connect the fault management systems from the NaaS operator and customer MNOs using open interfaces. In this case, the NaaS operator must limit the MNOs access to prevent exposing the complete network metrics or KPIs due to privacy issues.

3.1.3 Fault Management Tier 2

Fault management tier 2 resolves the network faults escalated by fault management tier 1 or first-line maintenance teams also known as field technicians. If a fault cannot be solved by tier 2 staff, it will be escalated to tier 3 support which for most NaaS operators will consist of requesting direct support from equipment vendors.

As the tenant NOCs may have more significant experience in the troubleshooting for mobile networks, an alternative is to rely on the tier 2 and/or tier 3 from them. This would decrease the required budget for the NaaS operator NOC and shorten the implementation time. However, an agreement must be reached first with customer MNOs. This tactic will be further reviewed in sections 6.4 and 6.5.

The main activities are:

1. Provide multi-vendor second-level system support with product expertise to resolve fault issues escalated from the first level after the proper diagnosis
2. Carry out remote fault investigation and solution, if possible
3. Escalation of TTs to tier 3 support
4. Solution verification after a network problem is resolved to confirm that the network is back to normal status
5. Proactively identify chronic or potentially hazardous network conditions through its monitoring tools and propose actions to be taken to prevent future incidents
6. Constant communication with tenant NOCs to coordinate troubleshooting and corrective actions to resolve network incidents

This specific function is assigned to a group of people whose expertise is broader and deeper than the fault management tier 1 team. This team usually works on cases that the previous team was not able to diagnose, escalates cases to tier 3 support (vendor support) and supervises the diagnosis, troubleshooting and resolution of high severity scenarios.

Having a fault management tier 2 team helps the organization by lowering resolution times for complex cases. The absence of this team implies that cases need to be escalated to vendor support directly by the fault management tier 1 team, thus increasing the time and cost to resolve the incident.

Generally used metrics to evaluate this function are:

• Percentage of resolved tickets — Measures the number of tickets that were resolved within the team without escalating to a different fix agent. This should also be categorized per MNO.
• Ticket volume escalated to third level support — Measures the number of tickets that were escalated to vendor support for resolution. This can also be categorized per MNO.

3.1.4 Performance Management

This function consists of identifying performance-related issues for network elements and ensuring they are correctly prioritized and managed until proper resolution. Performance management includes the analysis and reporting of network quality measures.

The main activities include:

1. Collection and analysis of network performance data from the EMSes or any other applicable source
2. Creation of performance and traffic reports
3. Detection of problematic elements
4. Troubleshooting of those performance issues detected

The performance management team works on performance-related scenarios that are not related to break/fix cases. This function frequently works with engineering/optimization teams to verify, validate, and resolve performance-related issues. These issues are categorized and treated according to the SLA agreed with the affected MNOs (for example, response times, escalation times and priorities). When possible, it is a good practice to target the tightest agreed SLA in the network; in any case, network KPIs should be reported on a per-MNO basis.

The most common metrics used to evaluate this function are:

• Ticket volume — Measures the number of tickets that are being created over a specific pre-established period. This metric should also be categorized per MNO.
• Ticket categorization — Measures the percentage of tickets that are created against common categories: accessibility (RRC, ERAB), latency, retainability (dropped call, blocked call), mobility (handover)

3.1.5 OSS & Tools Management

OSS & tools team is the administrative entity for all OSS, EMS and NOC tools that are deployed for network management. OSS management includes the analysis and reporting of OSS quality measures.

The main activities include:

1. User management
2. Software and data management
3. OSS administration
4. OSS fault management
5. System backup management

The OSS & tools function aids the different functions of the NOC with daily tasks as user administration which includes account or permission details, access rights OSS management including routine maintenance, health checks, system backups, system upgrades (for all EMS being supervised on the network). These tasks are accomplished faster by having a local team versus opening tickets against the vendors for assistance.

According to the collaboration levels to be implemented (see section 6.2), privilege access to different files/systems may be granted to tenant NOCs. The first consideration should be based on the permissions that the NaaS operator will grant to the customer MNOs to access their systems. In a similar vein, the NaaS operator NOC would require permission to access the systems of the tenant NOCs so the level of access must be conceded accordingly. These considerations should be handled by the OSS & tools management team as coordinator.

The collaboration strategy covers four areas: ticketing, fault management, performance management and billing & revenue reconciliation (further details in section 6.2). For these areas, the degree of privileges can vary from one MNO to another. If systems are interconnected usually through APIs or standardized interfaces the OSS & Tools team will oversee the level of access of tenant NOCs to access only to network data or equipment related to a specific MNO or its customers. Customer MNOs must not be capable of accessing the complete information of the network since this may cause privacy issues.

The most often used metrics to evaluate this function are:

• User requests volume — Measures the number of requests received to add/change/delete users or modify rights/permissions
• Fault management ticket volume — Measures the number of tickets being resolved by the OSS & tools team
• Percentage of resolved tickets — Measures the number of tickets that were resolved within the team without escalating to the vendor or the tier 2 customer MNO NOC (depending on the business model). This metric should also be categorized per MNO.

3.1.6 Access Management

Access management is responsible for site access requests and follow up.

Activities performed by this team include:

1. Access request admission
2. Access submission to tower companies/landlords
3. Check-in and check-out validations
4. Access escalations

The access management function ensures that access to the different sites in the network will be ready when needed by the field technicians or service providers. This mitigates the burden for the field management team as this function is normally associated with them if the NOC does not have this team within their structure. In the case that the field technicians from the NaaS Operator need access to a customer MNO facility, the access management function will also be in charge of coordinating with tenant NOCs the access to those sites (e.g., installing equipment on an MNO facility for interconnection).

Typically used metrics to evaluate the performance of this function are:

• Site access requests — Measures the number of access requests managed by the team, often broken up by field tech requests and third-party requests (e.g., customer MNO requests).
• Access escalations — Measures the number and level of escalations performed by the team to gain access to sites.

3.1.7 Field Dispatch

Field dispatch covers the coordination for on-site interventions that are executed on the network.

Activities performed include:

1. Dispatch of the work order
2. Preparation of the field intervention – for example: spare parts collection and site access authorization
3. Execution of the work order
4. Reporting the outcome to the requestor (and the return of the spare parts, if applicable)

The field dispatch function is another critical function peripheral to a NOC as the team resolves all on-site interventions, including both corrective and preventive maintenance tasks. This specific function will be covered in far more detail in the Field Force Management module.

3.2 NOC Functions Selection & Customization.

This section examines the possible scenarios for the deployment of functions on the NOC organization, presenting alternatives to choose from, based on the NaaS operators scope and needs.

Below, the different options to customize the functions for each team in the NOC are examined.

3.2.1 NOC Tier 1 Setup

As stated before, the tier 1 team is the first point of contact when an issue in the network arises. However, the configuration of functions for this team can vary based on the NaaS operator requirements and constraints. The sections below, provide an overview and guidance for NaaS operators to select the option that best suits their needs.

3.2.1.1 Network Surveillance + Fault Management Scenario

The aggregation of network surveillance and fault management is one of the most common scenarios at the tier 1 level. Since network surveillance and fault management tier 1 go hand-by-hand, these two functions are usually met by one single instance which is accommodated into a NOC tier 1 level. This group of people will both perform real-time monitoring of all alarms, create trouble tickets, perform first-level analysis and diagnosis, and escalate the ticket to the corresponding fix agent if unable to resolve.

The group will also be responsible for all email and phone call communications regarding the tier 1 team, including exchanges for site conditions, active alarms, and network alarm status.

NaaS operators should select this option if a high volume of alarms/tickets is not expected, or if they wish to keep both functions tied to a single team in order for the tier 1 team to have a complete picture of both alarms and trouble tickets.

3.2.1.2 Region Segmentation Scenario

Another common setup revolves around aggregating the access management and field dispatch functions into the tier 1 team as well. This can prove effective when the NOC is monitoring a small network (or if network monitoring is broken up into different regions, each one covered by a small team of engineers).

In this scenario, the tier 1 team will also be in charge of executing field dispatches (if necessary) and making the necessary adjustments to make sure that there will be access to the site for the field technicians.

As mentioned before, this option is best suited for region-based monitoring or for small networks, as the increase in functions makes them aware of all details for their respective sites, but in turn, the overhead associated with this setup may challenge the team.

3.2.1.3 Domain Segmentation Scenario

Another common scenario is to have the NOC tier 1 team segmented into the different network domains, typically RAN, TX and CORE, especially if the alarm volume expected will be high. As such, each team monitors and creates trouble tickets for the alarms coming in from the different network elements in each domain.

For instance, the RAN tier 1 team monitoring a 4G network would receive alarms from the eNBs and the cell site routers, working closely with site-level fix agents, like field technicians covering such sites, tower companies, power companies and fiber companies. The TX tier 1 team would receive alarms from the IP aggregation and backbone routers, working with field technicians, power companies and fiber service providers. Finally, the CORE tier 1 team would receive alarms coming from the EPC network elements like the MME, SGW, PGW, etc.

This setup is more complex than the previous one, as all tier 1 teams must be in constant communication and coordination to successfully correlate alarms to incidents within the network. Some operators choose to have only two tier 1 teams: access (including all RAN and aggregation nodes) and CORE. These segmented scenarios make more sense to operators with medium-to-large site presence and can be combined with the previous region segmentation mentioned earlier for better results in larger, nation-wide networks.

3.2.1.4 Enhanced Tier 1 Scenario

Finally, one less common setup is incorporating fault management tier 2 functions to the NOC tier 1 team in addition to the previously mentioned functions. This is referred to as a tier 1.5 team, or enhanced tier 1 team.

This option may be taken for budget constraints as there would only be one team overseeing, analyzing, and processing all activities within the network, escalating complex cases directly to the vendors. This setup requires engineers with a higher level of expertise which must be taken into consideration. This can be an option for small networks with more relaxed service level agreements, as cases escalated to vendors may extend resolution times.

Table 1 below shows a summary of the scenarios that were covered in the previous sections:

NOC Tier 1 Setup Scenario	Functions						Applicability
	Network Surveillance	Fault Management Tier 1	Access Management	Field Dispatch	Domain Expertise	Fault Management Tier 2
Network surveillance + fault management	✔	✔					Small networks with a high volume of alarms/tickets not expected. Retain both functions for a complete picture of network status at the tier 1 level
Region segmentation	✔	✔	✔	✔			Small-to-medium network being monitored; tier 1 specializes in each region details
Domain segmentation	✔	✔			✔		Medium to large networks being monitored. Each team specializes in a specific domain requires coordination among teams
Enhanced tier 1 (tier 1.5)	✔	✔	✔	✔	✔	✔	Small-to-medium networks; used in budget constraint scenarios as one single team encompasses all functions

Table 1 — NOC Tier 1 Scenarios.

3.2.2 NOC Tier 2 Setup

As tier 2 teams are more specialized with equipment/technology, they are regularly set up within domains like RAN, TX and CORE. In addition, the following function bundles are assigned to the Tier 2 Team.

3.2.2.1 Fault + Performance Tier 2 Scenario

The most notable function aggregation scheme for tier 2 incorporates the performance management function into the tier 2 responsibilities (which as seen on section 3.1.4 comprises domain-specific expertise analysis and diagnosis, or escalations to vendor support for complex cases).

This option is adopted by NOCs in which Operators do not have network performance set as a priority. As such, Network Performance is not monitored in real-time and is only escalated to the NOC tier 2 team via end-customer reports. This setup is also considered if the operator does not have ample RF or Optimization resources available, as performance investigations are commonly referred to those groups as well.

3.2.2.2 Fault + Performance + OSS Tier 2 Scenario

On smaller NOC operations OSS & tools responsibilities are also aggregated to the NOC tier 2 team, as they are enabled to perform user/profile adjustments, take system backups, and become the point of contact for vendor engagement.

Table 2 summarizes the scenarios covered in the previous sections for tier 2:

Table 2 — NOC Tier 2 Scenarios

3.2.3 NOC Leadership

NOC leadership duties include NOC planning, controlling, steering, and reporting all aspects of NOC activities; management of NOC organization and NOC staffing; delegation and empowerment of NOC managers and team members. Within those duties, the following main activities are performed:

1. Key performance indicators (KPI) measurement
2. KPI and SLA reporting
3. Shift management

Figure 4 shows the most common structure for NOC Leadership, which will be explained in detail in the following paragraphs:

Figure 4 — Network Operations Leadership View

Each NOC group is usually supervised by a manager who delivers guidance to the entire team and serves as the point of contact (POC) for all those team requirements or escalations. Depending on the setup that has been chosen, leaders for network surveillance, fault management tier 1, fault management tier 2, performance management, OSS & tools management, access management, incident management and field dispatch may exist; or a manager for the aggregated teams may be in place (e.g., NOC tier 1 manager, NOC tier 2 manager). The entire team is supervised by a NOC head, who acts as the ultimate responsible for the NOC operations.

Another common practice in medium-to-large NOC organizations is to have a manager per domain, specifically at the tier 2 level. This decision is based on the expertise that is needed for such teams and to have a direct escalation path available for specific-domain scenarios that may be present on the network, thus aiding for faster resolutions since the leader can provide directions for the team and readjusting priorities as needed.

Since regardless of the grouping decisions the tier 1 team is always one of the biggest groups, team leaders are regularly set as part of the structure (having at least one team leader per shift). These people are trained engineers whose expertise and process knowledge, supported by leadership empowerment, enables them to make controlled operative decisions during their shift in absence of the teams manager.

Further guidance on the configuration of the NOC leadership team is provided in section 6.4.

4. NOC Processes

This section presents the core processes followed by the NOC including E2E process flows, key elements, roles and responsibilities and the most common metrics used to measure each process success. The section also presents guidance for the operators NOC processes customization.

4.1 NOC Processes Analysis

The following subsections analyze each process executed at the NOC, including rationale, common KPIs and roles associated with each process.

4.1.1 Event Management

An event is regarded as a change of state that has significance for the management of a resource or service. It can also mean an alert or notification created by any service, resource or monitoring tool.

Events typically require operations staff to take actions, and often lead to incidents being logged. The event is only recognized as an incident at the end of the event management process.

Figure 5 presents the high-level E2E process flow for event management which is also provided as a template for customization by NaaS Operators. The green dots on the left indicate input triggers to the process and the red dots are endpoints of the process.

Figure 5 — Event management high-level flowchart

Below, the process is described in detail:

1. Input triggers can come in the form of a network event or a customer MNO ticket. In the case of a network event, an alarm goes into a network monitoring system (NMS). At this stage, the alarm message is displayed in the EMS, and thus it appears on the screen of the fault management tier 1 engineer.
2. The engineer then starts to correlate planned work. In this phase the FM tier 1 engineer checks for a possible relationship between the generated alarm or event with other activities such as preventive maintenance, network change implementation, and rollout activities. Next, the FM tier 1 engineer would contact the person implementing the planned work to determine if the alarm is related to the activities. If it is, and if the activities were planned, the FM engineer will update the alarm and acknowledge it. This will remove the alarm from the current view.
3. If the alarm is not related to planned work, the engineer moves on to the next process step: correlate incident. In correlate incident, the engineer searches alarm criteria to correlate the alarm with any similar alarms already recorded in incident tickets. If the event is correlated, the engineer updates the incident ticket with the alarm or event that was just correlated.
4. If no correlation to another ongoing incident, FM tier 1 triggers incident ticket creation, updating the alarm message and acknowledging the alarm.

Event Management is typically measured by two KPIs:

• Correlation Accuracy — Measures the percentage of tickets where correlation has been performed correctly.
• Trouble Ticket Respond Time — Measures the percentage of tickets with response time within a targeted predefined response time. This KPI can be calculated per MNO to assure the response times are within the agreed SLAs.

4.1.2 Incident Management

To understand the incident management process, the following definitions are required:

1. Incident — Unplanned interruption to the NaaS operators service, or a reduction in the quality of their service. An incident can also include failure within a system that has not yet impacted the NaaS operators service. An example would be a loss of functionality that has switched over to a back-up system.
2. High impact, or potentially high impact incident — Incident that requires a response that is above and beyond what is given to normal incidents. Typically, these incidents require cross-function or cross-department coordination, management escalation, the mobilization of additional resources, and increased communications.
3. Extraordinary impact incident — Incident characterized as a crisis, emergency outage, or priority zero problem. It is an event in the operational phase of the network that has a severe impact on customer service and is assumed to be or has already been escalated within the NaaS operators organization.

The high level, end to end process flow for Incident Management is presented in Figure 6 below and provided as a template for NaaS operator customization.

Figure 6 — Incident management high-level flowchart.

The high-level E2E process flow for the incident management process is divided into 3 lanes, to address the role of each of the participants in the process. The upper portion shows process steps for the FM tier 1 engineers. The middle lane shows the activities performed by the FM tier 2 engineer. The bottom lane indicates the process steps executed by the incident manager. It is precise to remark that depending on the implementation model, the tier 2 NOC may belong to the customer MNO. The green dot on the left is an input trigger to the process. The red dots are endpoints of the process. Below a detailed description of this process is provided:

1. The scenario for the FM tier 1 engineer begins with the event input coming out of the event management process. The event requires an assessment of the impact before the incident TT can be created. Based on the assessment, which is commonly supported by a criticality matrix, the engineer determines whether the incident is a high impact incident or a normal incident.
2. If the incident is not deemed to be a high impact, the FM tier 1 engineer will execute the initial diagnosis of the incident. This initial diagnosis should be coordinated with tenant NOCs to facilitate the early solution. This collaboration should also be based on their own experience and skills, and consultation of the knowledge base if necessary or other engineers, the affected NOCs will look for a solution to restore the incident. Otherwise, if the incident is considered to have a high impact, go to step 9).
3. Whenever the fault is isolated outside the engineers capabilities the FM tier 1 engineer can engage the first line maintenance team (i.e., field technician) for onsite activities, a service provider if applicable, or the FM tier 1 from affected tenant NOCs. It is important to involve the corresponding MNOs if the FLM is required to visit an MNOs facility.
4. If the FM tier 1 engineer can resolve the alarm remotely, the incident can be closed successfully.
5. Restoration must then be confirmed, either by checking the clearance of the alarm or by contacting the customer in case a direct report triggered the investigation. With a positive confirmation, the incident trouble ticket can be closed.
6. If the FM tier 1 engineer cannot restore the service or is not qualified to find a solution, the ticket is escalated to FM tier 2. FM tier 2 will continue with further investigation and diagnosis of the incident. FM tier 2 will use their knowledge base to find a solution and coordinate efforts with other engineers from involved tenant tier 2 NOC teams. In this level of FM, it is more important to closely coordinate with NOC FM tier 2 of affected MNOs. Depending on the split of responsibilities, the FM tier 2 can belong to customer MNO or both, NaaS and MNO NOCs, can co-exist.
7. FM tier 2 can draw in additional resources if necessary. This may include FLM, a Service Provider, or the involvement of the vendors tier 3 support.
8. Once a solution is determined, the service will be restored. Again, restoration will be confirmed by clearing the alarms or by customer MNO contact.
9. If the FM tier 1 engineer assesses the incident as high impact according to already predefined standards (as a criticality matrix), the FM tier 1 contacts FM tier 2 directly to lose the least amount of valuable restoration time.
   FM tier 2 will start with the investigation of the incident, while in parallel the FM tier 1 engineer contacts the incident manager. The incident manager has overall responsibility to ensure that the high impact incident will be restored as quickly as possible. This includes:
   • The confirmation of the impact
   • Opening the technical conference bridge
   • Notifying all relevant parties during the incident (i.e., affected MNOs)
   • Coordinating diagnosis and restoration efforts
10. At the end of the high impact incident, the incident manager decides if a root cause analysis is required.
11. An incident report is commonly required on high impact incidents to end the incident management process.

The most common KPIs utilized for incident management are the following:

• Restore to service level agreement — Percent of tickets solved in time against each severitys SLA restore target. This KPI can be calculated per MNO to assure the agreed SLAs.
• Respond time to service level agreement — Percent of incident tickets created in time versus the predefined SLA target. This KPI can be done per MNO to assure the response times within the agreed SLAs.
• Cross technology incident — Percent of incidents that involved several technologies. An example would be a combined investigation effort required with engineers from RAN and CORE.
• Diagnosis Accuracy — Percent of tickets that were assigned to the correct team.

4.1.3 Problem Management

To understand the Incident Management process, the following definitions are required:

1. Problem — Underlying cause of one or more incidents, either existing or potential. Problems are sometimes identified because of multiple incidents that exhibit common symptoms. They can also be identified from a single significant incident for which the cause is unknown, but the impact is high.
2. Root cause analysis (RCA) — Process of analyzing and determining the underlying cause of an incident or series of incidents. Identifying the underlying cause helps to identify permanent solutions for problems in the network.
3. Workaround — Interim solution, that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available (e.g., restarting a failed network element). Workarounds for problems are commonly documented in known error records.
4. Problem solution — Long-term solution to a problem to prevent recurrence of incidents.
5. Known error — Condition identified by the successful diagnosis of the root cause of a problem. Successful diagnosis converts an unknown error to an error whose root cause is known. Problem management identifies and manages known errors throughout their lifecycle. Known errors may also be identified by developers or suppliers.
6. Known error database (KEDB) — Database that allows for storage of previous knowledge of incidents and problems and how they were overcome to allow quicker diagnosis and resolution if they reoccur.

Figure 7 introduces the high-level, E2E process flow for problem management which is also provided as a template for customization by the NaaS operator.

Figure 7 — Problem management high-level flowchart

The high-level E2E process flow for the problem management process is divided into 3 lanes to highlight the roles involved and activities to be taken by each role. The upper lane has process steps for the problem submitter. The middle lane shows the activities performed by the problem manager. The bottom lane shows the process steps executed by the problem assignee. The green dots at the beginning of the problem submitter lane show input triggers to the process. The red dot is the endpoint of the process. A detailed description of this process is provided below:

1. There are three common inputs for problem management:
   1. Customer request — If a problem is identified and raised by the customer MNO. This can be via a phone call, email, shared ticketing system with the MNO or other means. If the NaaS operator has their own end customers, this input will consider both (i.e., end users and MNOs).
   2. Incident closed — Input coming from incident management after an incident has been closed.
   3. Failed change — Failed change is an output from the change management process: any change request that has failed and requires further analysis.
2. Note that input may also come from the problem manager in the form of bulletins (e.g., bugs found on existing software) or analysis (e.g., based on trends). This is proactive problem identification, which means that even before an incident occurs, a problem can be identified based on some indicators highlighting its probability. The problem manager will send the details to the problem submitter to raise a ticket as per process.
3. The problem submitter, upon receiving any of the previously mentioned inputs will create a problem ticket and send it to the problem manager.
4. The problem manager will review the problem ticket and validate prioritization and categorization.
5. The problem manager will then check in the knowledge base to see if its a known error, which could end the problem management process as a previous investigation would be documented.
6. The problem assignee and the problem manager will investigate and diagnose the problem, creating in parallel an initial article on the knowledge base. Its possible that the problem found or reported isnt in the NaaS operator network, but in the network of a customer MNO. In this case, the problem manager will coordinate the communication with the corresponding MNO NOC to diagnose the issue and the steps 7 to 10 will happen at the MNOs network.
7. Once a solution or a workaround has been identified by the assignee, they will send the ticket to the problem manager to review and approve in consultation with management/customer.
8. Upon review of the solution/workaround and receiving approval, the solution or workaround is sent to the problem assignee to develop and test the solution.
9. From investigation, identification, to development and testing of the solution or workaround, other field engineers, external service providers, vendors or customer engineering may be involved as required.
10. Once development and testing are finished, a change request should be raised for implementation. This follows the change management process which requires the involvement of the change advisory board.
11. After implementation, the problem manager and the assignee must assess the results before closing the ticket.
12. The solution should be updated in the knowledge base for future reference.

The most common KPIs used to measure problem management are:

1. RCA delivered within SLA — Percentage of problems diagnosed, meaning the root cause has been found, within SLA targets.
2. Workaround or solution identified within SLA — Percentage of problems for which a workaround or solution is identified within SLA targets.
3. Workaround or solution implemented within SLA — Percentage of problems solved, meaning problems for which workaround or solution is implemented, within SLA targets.
4. Average resolution time — Average time taken to find a problem solution, broken down by category and priority level.
5. Total problems recorded per month — Total number of problems recorded in a one-month period as a control measure and trend analysis, broken down by originator type, category and priority.
6. Problems backlog — Backlog of outstanding problems and the trend – whether the backlog is static, reducing or increasing.

4.1.4 Change Management

A network change refers to the addition, modification, or removal of any network infrastructure network element. This includes changes to hardware, software, configuration, and database. First, some concepts that are important to the change management process are provided:

1. A change request is a request for a change on the network, which can be accepted or rejected.
2. Changes are often categorized by their nature:
   1. Standard change refers to change with low risk and no service impact. Standard changes are pre-authorized. The processes and methods of procedures (MOP) are clearly defined and are proven. The standard changes are often requested on a regular basis.
   2. Normal change refers to change requiring an approval. Normal change type encompasses all changes except the standard changes, the emergency changes and the planned works.
   3. An emergency change is used when immediate action is required in order to restore the customer services or to prevent imminent failures, without time to follow the normal change process.
   4. Planned work is any activity scheduled by a third party on equipment outside the NaaS operator network that could have an impact on services.
3. Changes are commonly categorized by their complexity as well:
   1. Single change is a change that is to be implemented by a single implementer or in a single place or in a single network equipment type. It requires minimal coordination.
   2. Complex change refers to change to be implemented by several implementers or in several places or several network equipment types. Synchronization between the implementation phases is mandatory.

The high-level, E2E process flow for change management is presented in Figure 8. This process flow is provided as a template for customization.

Figure 8 — Change management high-level flowchart

The blue boxes on the left are the primary roles of the process. Horizontal lanes, associate process steps with the respective roles. The green dots on the left are the input trigger to the process, and the red dots are the endpoints of the process. In the following paragraphs, a detailed description of the process is provided:

1. The change manager serves as one entry point for the work, who processes planned work information. The change manager performs a first review of this information and shares the details after completing the review.
2. The second entry point is through the change coordinator. The change coordinator performs the first analysis of the documentation, creates change tickets, or reviews a change ticket already created within another process.
3. The first decision point for the change coordinator is made based on whether a change is a normal change or a standard change.
4. The standard change is pre-approved and will go directly to the next process step: prepare change.
5. The normal change must first undergo an administrative review by the change coordinator (a), and a technical review by the subject matter expert (b) before it is authorized.
6. When the review process is complete, the change goes to the change advisory board (CAB) or the emergency change advisory board (E-CAB). These boards may consist of a group of people, or a single person.
   The CAB/E-CAB should be in constant communication with their customer MNOs that can be affected by the change. An additional coordination with the affected MNO may be required if the change will impact on the service provided by the NaaS operator.
   Reciprocally, the tenant NOCs must notify of changes in their networks that could lead to outages or any impact on the NaaS operator network or services. For changes with major impact a formal notification and coordination with the NaaS operator may be necessary as well.
   In parallel with the involved tenant NOC, the CAB/E-CAB performs their review and evaluates the planning details to determine if theres any conflict with other changes already approved and planned. The board renders a decision to either reject the change and stop the process or approve the change and pass it along to the next step: prepare change. The involved tenant NOCs may request a delay in the activities if the impact overlaps with their own activities.
7. In prepare change, both the change coordinator and the change implementer of NaaS NOC and tenant NOCs take care of the last preparations and adjust the timing between a normal change and a standard change. The next decision point is based on whether the change is a simple change or a complex change.
8. The simple change goes directly into the implementation and testing phase (a). The complex change requires coordination of NaaS and MNO NOCs (b), which is the responsibility of the change coordinator. As the change coordinator is working, the change implementer is operating in parallel to perform implementation and testing activities.
9. Throughout the implementation process, the change implementer needs to be in contact with the network monitoring team in the NOC. The network monitoring team should be in contact with their counterparts in the tenant NOCs. This contact is necessary to ask the fault management tier 1 engineer if change implementation can begin.
   During the change implementation activities, there is the possibility of an unforeseen issue, error, or incident that can have an impact on the planned work underway, or even an outage caused by the change itself. In any of these cases, the NOC is contacted for a go ahead, followed by implementation and testing.
   For example, if the change implementer loses track of time, the network monitoring team should contact the change implementer when there is only a predefined number of minutes left of the available maintenance window. They can discuss if the change implementation can finish on time or if a rollback is necessary to ensure the work remains within the requested maintenance window.
   The NOC does have the authority to recommend a rollback if there is a reason to prevent any further damage or service affecting issues in the network. Also, the NOC has the authority to request the status of the activities on customer MNOs networks to correlate with the status of its own network. If the impact if bigger than expected, the NaaS Operator NOC can make a formal rollback request to the corresponding tenant NOC.
10. The two possible conditions of change implementation and testing are: successful or not successful with a rollback. In either case, the results of the change are reviewed by the change manager, change coordinator and change implementer.
11. The next point is based on what kind of change took place. There may have been changes to the network, or new equipment may have been installed. There may have been no change except for replacing an existing card with the same type of card. In this case, the next step is reporting and closing.

Once the updates in documentation to the required system are performed (asset and configuration database), the process moves to the last step, which is preparing the implementation report and closing the change ticket.

Typical KPIs used to measure the change management process are:

• On-Time Change Complete — Percentage of change requests that are delivered against the planned or agreed-upon committed date.
• Change causing an incident — Percentage of changes that caused an incident. The incident in this case is any outage or service interruption that is not documented and approved by the change advisory board.
• Change volume — Total number of changes approved in each month. Its useful for monitoring the volume of changes implemented in a network.
• Emergency Change Rate. — Percentage of changes classified as emergency against the total changes implemented in the network. This is an important KPI for process performance measurements. A higher count of emergency changes represents a more unstable network, where incident restoration requires emergency change. This can also be a result of poor change management process leading to unplanned emergency changes.

4.2 NOC Process Selection & Configuration

Now that the NOC processes have been analyzed the NaaS Operator must select the processes to be implemented based on the NOC scope and NaaS operator capabilities or requirements.

Event management, incident management and change management are mandatory processes for a NOC operation. Still, there are three process adjustments that may be considered by the NaaS operator:

• Incident Management
  If budget constraints call for headcount reduction, or if the operator rules out coordination and communication activities as mandatory during high impact scenarios, the incident manager may be removed from the overall process.
  In this scenario, a member from the fault management tier 2 team will be in charge of the incident coordination and will serve as the POC for the duration of the event. The operator may decide that for escalations, awareness, and directions on high-impact incidents the shift leader (if applicable), or the domain manager, or even the NOC manager may be requested to attend.
  Consider that in the absence of an Incident Manager, communications during a high impact scenario may not formally exist, and as such, the different teams working the case must make a conscious effort to document the trouble ticket to the best of their abilities, as it is often required to review all actions taken during troubleshooting for improvement purposes.
• Problem Management
  A very common practice, at least at the early stages of NOC implementations, is to leave the problem management process out from the NOC set of processes.
  Problem management is a powerful process that enables the operator to reduce the number of recurring scenarios, to mitigate the impact for future events or to enhance the end-customer experience by optimizing the network in certain aspects. Still, operators may conclude that at early stages or in general focus will be set on network availability alone, and that scope will be limited to event detection and restoral, and not on enhancement opportunities.
  On such organizations, the closest existing approach to problem management is performed by the fault management tier 2 team, and usually triggered only by request, generally from a high-visibility escalation. The process may be executed at some extent, generally without a knowledge base properly set, and as such problems detected in the network may have longer resolution times compared to a fully implemented problem management organization.
• Change Management
  In the Change management process, the operator may judge that two different entities are not relevant for the process, as the change coordinator and the change manager may be comprised of a single entity within the NOC structure.
  On this setup, the coordinator or the manager will inherit the activities performed by the other entity within the change management process, leaving a single POC for all change-related queries.
  Another option followed by some operators is to leave out both the coordinator and the manager out of the equation, and as such assignment of responsibilities are set internally within the change engineers structure, or assigned to the NOC tier 2 team, in which case assignment per domain is executed for change request review, approval and follow up.

⇐ Previous

5. Systems & Tools Overview

This section provides an overview of the systems and the most common tools used to support the network operation, and aspects to consider for the NaaS operator evaluation and selection of tools to be incorporated into their NOC.

5.1 Tools High-Level View

There are several tools in place for a NOC to achieve its objectives. The most widely used are the service desk management tool, a network fault management system, a geographic information system, network performance management system and network configuration management systems. These will be reviewed in the following sections.

5.1.1 Service Desk Management Tool

This tool is used for the documentation of all incidents, problems and changes that are being worked on the network at any given time. It can be considered one of the main tools used by the NOC, as it enables all the team to have a proper mechanism to document all activities surrounding each incident, problem or change ticket.

A proper tool for documentation aids the team as they can know exactly what the status of any ticket is, what are the next items to be solved and what needs to be followed-up. It also enables reporting, which serves as the basis for governance activities: revision of the NOC performance, KPIs, and SLAs.

A full service desk management (SDM) tool is an immensely powerful tool that incorporates modules for incident management (incident tickets), problem management (problem tickets) and change management (change tickets). It also includes a Knowledge Base module (KB Articles) that serves as a repository for all the KB information used by all NOC teams, updated with key past experiences and lessons learned for future reference and improvements, as previously discussed on the problem management process section.

Another alternative to consider is to have a ticketing tool instead of an SDM tool if focus will be set on fault restoral and less on problem or change management. This will be further discussed in section 5.2.

When choosing the appropriate tool, one point to consider is the scheme of collaboration between the NaaS NOC with the tenant NOCs. An automated mode will require the SDM/ticketing tool to communicate to the tenant NOCs. In this scenario, the tool must support a standardized interface towards the tenant NOC for easier and automatic TT sharing.

Examples of commercial and free/open-source tools are provided in Table 3.

Table 3 — Commercial vs Free/Open Source Service Desk Management Tools

5.1.2 Network Fault Management System

A NOC needs a visible medium to monitor alarms which is accomplished by a network fault management system or network monitoring system as described in the Network Monitoring Architecture module. This tool, along with the service desk management tool covered earlier, are the heart of any NOC organization. This tool enables the network surveillance function, as alarms are monitored and observed by the NOC technicians, and therefore ticketed for resolution following event and incident management processes.

This tool provides the NOC tier 1 team basic alarm functionality to acknowledge alarms (i.e., mark an alarm as observed and being analyzed), journal alarms (i.e., introduce text to the alarm indicating trouble ticket opened, or change associated to alarm, or other information deemed necessary) and clear alarms (i.e., set an alarm as already worked and dismissible from further work).

There are two common options commonly available for NOCs regarding fault management tools: one of them is having an umbrella network management system. An umbrella system helps the NOC organization by having all alarms, regardless of the network element vendor, available for monitoring on a single tool. This type of tools can interact with the service desk management tool to create tickets directly from the alarming tool or to append alarms directly to an existing incident ticket.

The other option is to have the tier 1 teams monitoring the different EMSes directly. These EMS tools have all the basic functionalities needed for network surveillance (i.e., acknowledge alarms, journal alarms, clear alarms).

Like the previous section, the tools from network fault management should be capable of importing and exporting the alarms to synchronize the current faults of the networks (NaaS and MNOs). If customer MNOs and NaaS agreed to automate the process, the fault alarms should be shared automatically between systems by a directly connected interface. Its important to note that not all the fault alarms should be shared, but only those relevant to customer MNO service.

Examples of umbrella NMSes and EMSes are provided in Table 4.

Table 4 — Umbrella NMS vs EMS Tools

5.1.3 Geographic Information System (GIS)

The GIS tool serves as a one-stop-shop for all items needed for troubleshooting for a particular site. A GIS tool is a support tool for NOC technicians to have all information ready and available in a visible, fast way.

This tool is used to obtain all relevant information about a particular site, such as:

• Address
• Coordinates
• Network configuration
• TX information
• Tower company information
• Deployment information
• Acceptance details
• Site inventory and bill of materials

Sharing information between the NaaS operator NOC and tenant NOCs is crucial to solve problems quickly and effectively. If the agreements between NaaS operator and MNOs establish the need to have full access to GIS data, the GIS tool must support a standardized interface towards the tenant NOC for remote collaborative work. Besides, the NaaS Operator should grant access permission to certain GIS information (e.g., Tx information, coordinates, and network configurations relevant to a certain MNO) of the project so the tenant NOCs would only have access to the information important to them.

Examples of commercial and free/open-source tools are provided in Table 5.

Table 5 — Commercial vs. Free/Open Source GIS Tools

5.1.4 Network Performance Management System

This tool aids the NOC organization to monitor the performance of the network in a more accessible manner. This is strategic for teams focusing on network performance indicators or for teams investigating network degradations before they are reported by end-users. Network performance can be categorized into RAN/CORE KPIs and IP/TX KPIs.

Performance Management tools enable the teams to analyze trends on several pre-defined KPIs, and granularity is often offered from months down to hours perspective. Another useful feature is to enable teams to create their own KPIs based on the available metrics offered by each element in the network, or put in another way, to customize the indicators for a far more operator-coherent experience. Further details are provided in the Network Monitoring Architecture module.

Analogous to section 5.1.2, if the agreements with customer MNOs stipulates a certain degree of collaboration level, the connection through a direct standardized interface from NaaS operator NOC to tenant NOCs will be mandatory for the tool to share performance KPIs (the interface should work on both ways so involved parties are aware of the performance of one another). Its important to note that not all the KPIs should be shared, but only those relevant to a certain MNO.

Performance Management tools are usually classified based on the domain in RAN/Core and IP/Transport. Table 6 provides examples of commercial and free/open-source tools by domain.

Table 6 — Commercial vs Free/Open Source Network Performance Management Tools

5.1.5 Network Configuration Management System

This system helps the NOC to oversee the configurations of the network equipment in a centralized fashion. This is helpful for teams responsible for change management or for teams in charge of troubleshooting.

Configuration management tools have three main advantages: to help keep the network configuration consistent, to ease the problem solving, and to allow the automation of the network. These tools help to keep the consistency of the network since any difference in the configuration for similar equipment can be spotted and corrected more easily. It also aids the change management teams to monitor the changes on the equipment in near real-time. Regarding the problem-solving process, having the configuration files centralized and updated may reduce the time to provide a solution. Lastly, these tools allow a network to be partially or fully automated since having a centralized tool for configuration is the first step towards network orchestration and automation.

As stated in previous sections, the collaboration with tenant NOCs is key for effective work. Similarly, if agreed by the Naas and customer NOCs, it can be necessary the direct connection between the configuration management systems (e.g., through APIs, SNMP Traps, or standardized interfaces). It is important to note that not all the configurations should be shared, but only those relevant to a certain MNO.

Finally, it is important to note that the NMS tools from different vendors can act as network configuration management tools. The obvious limitation is that an NMS will only work for the equipment from that vendor (some vendors would require more than one NMS tool). If the NaaS Operator Network is built of equipment from several vendors, the number of NMS tools will increase accordingly.

Table 7 provides examples of commercial and free/open-source tools.

Table 7 — Commercial vs Free/Open Source Network Configuration Management Tools

5.2 Systems Selection

In the previous section several tools that are part of a NOC ecosystem were introduced. Now aspects to consider for tool evaluation and selection will be presented. First, critical operational tools will be discussed, followed by optional support tools.

5.2.1 Critical Operational Tools

There are a couple of tools that are critical and must be part of the NOC solution: the network fault management tool, the service desk management tool and configuration management tool. The first one is the key component of network surveillance and event management; the second one is vital for incident management and fault management teams; and the third is vital for change management and fault management teams. Below the recommendations and considerations to be taken into account by the NaaS operators for the selection of these tools are provided:

• Network Fault Management Tool
  An umbrella network fault management tool would be ideal for any NOC organization, as it would enable the NOC tier 1 team to monitor all network alarms from one single instance. However, there are two variables that need to be considered for this type of tool. The first variable is financial-oriented: budget constraints might prevent the operator from choosing this alternative as commercial tools are costly not only from an acquisition perspective but also from a maintenance perspective.
  The second variable is process-oriented: full implementation of this type of tools requires a heavy use of EMS configurations, and on top of that, the actual tool needs to be configured and optimized, along with training for its effective use.
  A simpler, more cost-effective solution is to have the NOC tier 1 team to monitor alarms directly from each of the EMSes on the network. This of course translates into a more complex scenario for the NOC engineer as multiple tools need to be opened at the same time, and multiple windows need to be monitored simultaneously. This also means that NOC technicians need to be trained in each tool separately to be familiarized with each tool.
• Service Desk Management Tool
  A full service desk management tool can be of great aid for the NOC team, as it would benefit from having all associated tickets in one single tool (incident management, problem management, change management). This translates into a more agile organization, as all teams speak the same language and know the same reference.
  As mentioned before there are free SDM tools available in the market, and some of them have open trials that can benefit a starting organization as the team can get used to the interface and the way of working before considering some of the commercial offerings surrounding such tools.
  One important factor to consider for the SDM tool incorporation is to review the actual processes that will be run by the NOC. While the NOC will adhere to some form of event, incident and change management, there is an area that needs to be reviewed like problem management.
  If the organization will not consider having this process in place, both problem tickets and the need for a knowledge base can be set aside, lessening the requirement for a full SDM tool. There are some organizations that use simpler tools like Microsoft Excel for change management (keeping records and control of all change activities), and incident management can be realized via a simpler ticketing system.
• Network Configuration Management Tool
  As previously stated, the use of tools for network management helps the NOC team to monitor the consistency of the configuration of the network. It delivers to the organization the fastest and smoothest transition to a full orchestrated network.
  These tools will enable a NaaS operator to react faster to changes in their network without impacting the agreed SLAs because it allows near real-time monitoring of the configuration. It also helps to have better documentation and organization in terms of change management and backup.

5.2.2 Support Tools

In the following paragraphs, the GIS and the network performance tools will be discussed, which are support tools that are optional depending on the needs of the NaaS operator.

• GIS Tool
  While a full-fledged GIS tool can bring several opportunities for an organization not only from an operational level, but also for network and capacity planning or deployment there are other options available that are less robust or that offer fewer features but still get the job done from a NOC perspective.
  While some of those options have been presented in the previous section, bear in mind a well-crafted spreadsheet can offer at some extent some of the benefits for a NOC tier 1 team without the costs associated to a GIS tool purchase and configuration.
• Network Performance Management Tool
  A network performance management system brings value to an organization that considers performance management and problem management into their core functions and processes.
  This type of tools can be greatly beneficial for a NOC team as they enable organizations to be aware of performance degradations as they occur, and often aid such investigations speeding up resolution times. Still, if the NaaS operator decides to start operations without such focus on performance management then the use of this tool becomes obsolete for the NOC.

6. NOC Implementation

This section presents a discussion of the different scenarios available to the NaaS operator regarding NOC implementation including staffing model, service levels, team dimensioning and facility sizing.

6.1 Staffing Model Assessment

There are two main models available for NOC staffing that can be considered by the NaaS operator: insourcing (i.e., building the NOC with internal resources as part of the NaaS organization) and outsourcing (i.e., reaching out to a third party to take control of operations), both of which will be covered in more detail in the next paragraphs.

An optional third alternative will also be presented, in which the NaaS operator may choose to outsource some tasks while retaining the majority of their operations. This option will also be covered after reviewing the first couple of models.

Regardless of the model to be chosen, there are several key aspects that the NaaS operator will have to bear in mind for the NOC implementation:

1. Establishing the organizational structure
2. Defining NOC policies and procedures
3. Aligning NOC scope & role to business and customer expectations
4. Selecting the correct system & tools environment

All these aspects have been outlined in this document in the previous sections, and the operator will have to define the implementation strategy that best fits their organization taking all these factors into consideration.

A closer examination of the implementation alternatives is presented below:

• Insourced Model
  The insourced model consists of the NaaS operator establishing their own NOC, taking full control of all operation and maintenance activities and functions for their network. An own consolidated and centralized hub for network control can transform the NOC into an engine for revenue growth and an area for competitive differentiation for an operator.
  In the insourced model, the NaaS operator sets all the structure, functions, processes and tools that will be incorporated into their NOC solution. All documentation, planning and reporting will be tackled by the organization as well.
  Insourcing implies that all NOC staff will be evaluated, selected, and onboarded by the NaaS operator, starting with the management team all the way down to the engineers performing each function at the NOC. This also means that the Naas operator will have to cope and plan for attrition as well as to plan and schedule for training needs (for network architecture, network technology and governing processes).
• Outsourced Model
  For the outsourced model, the NaaS operator brings a third party to perform all associated activities related to the operation & maintenance of the network. Looking for a NOC service provider means that the operator will need to find a company that has the capability to monitor their network environment. All the aspects that were mentioned in the previous section will now fall into the NOC providers hands.
  Outsourcing offers relief from the staffing and skills dilemma, allowing organizations to attain almost instant network expertise for maximizing network performance.
  When an operator chooses to outsource their NOC, along the contracts and agreements made between both companies, the operator can set the requirements for all aspects of the operation, such as the structure to be followed, the functions and processes to be put in place and a recommendation for the tools to be incorporated as part of the providers solution.
  Some of the questions that the NaaS Operator should make to the potential partners are:
  
  1. What is the location of their NOC? Potential considerations include communication/language/cultural difficulties, service lag times, outage response times that accompany hiring off-shore or near-shore providers.
  2. Can they scale to support the NaaS operator business? Major advantages of outsourcing include flexibility and scalability and these capabilities should be considered from the start.
  3. Is their staff on-call or on-site? What type of coverage solutions do they offer? If the NaaS operator decides to outsource network monitoring for full 24×7 coverage, they have to realize some providers support their customers via an on-call rotation, which may not suit the response times needed.
  4. How will their NOC access NaaS operators network? Seek for high-availability redundancy options as monitoring is crucial and the NaaS operator cannot afford to have gaps in coverage due to unforeseen circumstances.
  5. Is their platform flexible and customizable, or restricted to out-of-the-box functionality? The systems should have the advantage of being customizable, satisfying the NaaS operators specific needs.
  6. Does the NOC provider outsource any of the assigned tasks? Some outsourced providers may in turn outsource part of the tasks they have been contracted for. Subcontractors should follow the same obligations acquired by the service provider.
  7. How does the NOC alert and handle outage escalations? Flexibility could involve different modes of outage notification depending on when the event occurs: an email or SMS on normal working hours, and an emergency phone call after normal working hours.
  8. How long does it take to implement the outsourced solution? Once agreements are in place, will the provider need weeks or months before they can have the NOC up and running?
• Mixed Model
  A mixed solution can also be put in place by the NaaS operator and a third party. In this alternative, the NaaS operator chooses which tasks will have to be fulfilled by the external provider and which ones the NaaS operator will assume. This may make sense in an environment in which a multi-vendor distributed network may present difficulties for the operator to acquire the experienced personnel needed and chooses to outsource some parts of the network, therefore.

6.1.1 Staffing Model Selection Guidelines

The insourced model offers full control of the operations to the NaaS Operator, allowing for changes in process/functions to be completed according to the business needs as soon as possible. Compared to the costs associated with the outsourcing model, the insourced model offers a way to drive down costs as needed.

However, insourcing may render difficulties for the NaaS operator as all hiring and training must be performed by them. Because of this, the insourced model is recommended for mature organizations with good human resources practices in place and confidence in the tools/processes to be implemented or for NaaS operators with small networks and tight budget constraints.

The outsourced model is often a costly option, still it offers several benefits as the NaaS operator is liberated from all the HR burden, including training and retaining highly skilled professionals, as well as tool selection and implementation. This is often one of the most difficult scenarios, especially at the beginning of operations, as NOC engineers have to learn at first a networks architecture and technology, the entire range of processes built around the NOC, and tool utilization.

A NaaS operator should select the outsourced model if the costs associated with outsourcing outweigh the costs associated to having an operation that is not working properly or that is not mature enough.

The mixed schema is suitable for NaaS operators that have maturity in certain aspects of the operation but are struggling in other areas, or for operator facing a multi-vendor distributed network experiencing difficulties to hire personnel with the right skills and knowledge for such challenge, as the third party can assist the operator fulfilling such gaps while the company gains such knowledge and skills.

6.2 NaaS-MNO Interconnection & Collaboration Strategy

The operational model of the NaaS operator will always rely on a close relationship with other MNOs, mainly as customers. Under this assumption, the NOC needs to be in constant communication with NOCs from other MNOs (tenant NOCs). The collaboration strategy will focus on areas on which is critical to maintain a level of communication. There are basically four communication areas that need to be addressed by this strategy:

1. Ticketing (See section 5.1.1)
2. Fault management (See section 5.1.2)
3. Billing/revenue reconciliation
4. Performance monitoring (See section 5.1.4)

Figure 9 shows the possible NOC interaction areas (A-D, as previously stated) for the collaboration strategy:

Figure 9 — NaaS-MNO inter-domain collaboration diagram

The collaborative strategy for the NaaS operator and their customer MNOs begins with the cooperation on the event management process. In this process, any alert or notification raised by any service, resource or monitoring tool is reported in the form of TTs. These TTs are analyzed and solved or escalated by tier 1 NOC in later steps. Ticketing is the most crucial activity since it represents the main input that drives all the NOC activities.

The next task in the NOC overall process is the fault management on any anomaly reported by event management. In this phase, the communication is vital: the faster, the better. An earlier and clearer exchange of information between involved parties would lead to a quicker resolution. The tier 2 and tier 3 support following the fault management stage can be on the NaaS or MNO side (depending on the NOC implementation model).

The other two processes for which a lower degree of integration of systems is required are performance management and billing & revenue reconciliation. The first refers to the constant monitoring of the network looking for poor performance of the network or opportunity areas where to increase the performance. The integration of performance systems can lead to a better understanding of the network and cooperative measures or changes can be implemented more effectively.

The last process is the billing and revenue reconciliation. This stage is key towards a successful business partnership between the NaaS operator and their customer MNOs. The purpose of this task is to reach agreements on the periodic billing or revenue amounts based on the associated costs and profits of the network operation. Again, communication is the key to avoid misunderstandings and to efficient the overall process.

There are two generic modes for all the integration of the communication conduits mentioned above: the manual and the automated. The first is characterized by a minimum or non-existent integration of the involved systems and relying on basic and slow human one-to-one or one-to-many communication. The automated mode targets for almost full integration of the systems. The intercommunication of these systems is based on automatic request and replies which lead to a near-real-time interaction.

In subsequent sections, the method of systems integration and its implications are explained.

6.2.1 Ticketing

As previously stated, ticketing is one of the pillars for NOC activities, so it is a mandatory item in the collaboration strategy. The purpose of this system integration is the fast and clear exchange of information for any irregularity in the network or the service. For any NaaS operator, this is mandatory for a healthy relationship with their customer MNOs.

There are several advantages when implementing an efficient ticketing process: reduction in the response times when an abnormality in the services/network occurs and decreasing of the overhead for the MNOs when opening a ticket. The disadvantage would be that the integration of systems can be hard to achieve when the already implemented tools do not allow this option.

Manual Mode

This scheme avoids the system integration with ticketing from tenant NOCs. The tenant NOCs may have independent tools from NaaS operator, and no special feature or interface is needed. The collaboration is via phone calls or formal emails. When an email or phone call takes place to open a TT, the NaaS Operator NOC personnel must manually insert the details into their SDM/ticketing system. This method could lead to errors in capturing the details of the problem besides the long times for reporting.

Automated Mode

The SDM/ticketing systems are interconnected so the TT can be raised directly by the customer MNO and the NaaS operator NOC can initiate the process towards the solution. After the resolution of the problem, the NOC can close the created ticket and the tenant NOCs are informed of the outcome almost instantly. An example of this system is a web- or cloud-based ticketing.

6.2.2 Fault Management

Fault management is the second pillar of NOC functionality and mandatory in the collaborative strategy. The system integration objective is to reduce the necessary time for problem solving and escalation time towards the compliance of pre-agreed SLAs.

The advantages and disadvantages are quite like the ones of ticketing due to the closeness of these two processes. It reduces the time for problem-solving since it offers alarms and diagnostic elements almost instantaneously. Furthermore, it enables the operator to have a shared source of truth and optimizes the overall process by eliminating points of human failure. On the other side, although the integration of FM systems is more feasible (compared to the ticketing), it is not always possible due to lack of compatible interfaces. It is required that the interfaces for interconnection are compatible from system to system.

Manual Mode

In the manual mode, the fault management systems are not interconnected and the exchange of information such as alarms of network/service is done by sharing a compendium of alarms files if the tool allows it. These files can be shared by email or any other formal channel.

Automated Mode

When the systems are interconnected and the alarms & notifications are delivered automatically between the fault management tools, the information of the alarm is not modified, and the integrity is preserved. The update of the notification is in real-time and the analysis of the issue is done with no delays. The fault management tool uses a request/response paradigm to communicate through standardized interfaces (e.g., SNMP traps, API exposure, NETCONF protocol based). Examples of these are umbrella tools and the interconnection of EMS/OSS systems.

6.2.3 Performance Monitoring

Performance Monitoring has less criticality since it is an extended function of the NOC and can be considered as optional. Here, the purpose of the integration is to draw more attention on the performance KPIs so its easier to find areas of opportunity for enhancements of the network.

The advantages are that more people can analyze the performance KPIs and it is more likely to find a root problem or any improvement in the usage of the network. The disadvantage would be that the integration is more challenging to achieve than the previous systems since, in this case, the access should permit MNOs to only access their own KPIs. If access is not properly controlled, a privacy issue may be raised. In this case, the access management is more challenging since the permissions have more precise delimitations.

Manual Mode

When implementing a manual mode, the exposure of the KPIs may be done through periodic reports or presentations. Since it is not a mandatory requirement, these reports may not always be shared and should be requested via formal email or phone call. This process would require a certain degree of organization between the NaaS operator and the involved MNO. It also needs more human effort into generating these reports/presentations according to the total number of MNOs.

Automated Mode

In this method, the systems integration is achieved by connecting the system tools to share the appropriate KPIs to the corresponding MNOs. One MNO should only have permission to look into the KPIs that are relevant to it. The coordination between tools should be more precise, but the results are the monitoring of the network performance in real-time.

6.2.4 Billing and Revenue Reconciliation

On the business side, the collaboration strategy contemplates the reconciliation of billing and, when it applies, revenue. The purpose of the integration of this system is to assure the data integrity and provide clarity of the billing and revenue. This must be considered mandatory to the collaborative strategy since the heart of the relationship between the NaaS operator and their customer MNO is business-based.

The pros of having these systems integrated are that the data used for billing and revenue clarifications is unmodified as a unified source of truth. Moreover, continuous monitoring can lead to better business estimations without the need of waiting for the periodic reports. The con is that data must be selected before shared with MNOs to avoid any information leak to other MNOs. This would also involve the overseeing of access to the systems involved.

Manual Mode

In this mode, the billing and revenue reconciliation is done by periodic meetings with business areas from a specific MNO. The MNO and the NaaS operator need to have implemented independent tools to have a formal discussion if the processed billing data differ. In this scheme, the human effort is increased by the number of MNO, since a customized report and an isolated meeting should be carried out per MNO.

Automated Mode

The automated mode considers the integration of the billing systems at BSS level. The information is pre-processed only to select the pertinent information to be shared per MNO. A formal meeting is always a good practice when billing data differs. Here, the BSS has more standardized interfaces towards other BSS, so the integrations are easier.

6.2.5 Examples

The level of collaboration between the NaaS operator NOC and the tenant NOCs determines the required capabilities of the tools. In the next subsections, two examples are presented: firstly, one to show a scenario where every collaboration channel is manual and secondly, one with the most typical case for a NaaS Operator.

6.2.5.1 Rigid Organizational Model

In this type of organization, all the processes are done manually. This means that ticketing, fault & performance management, as well as billing and reconciliation are executed without any system integration. The communication channels are traditional (e.g., phone calls, email).

This organizational model is recommended as a starting point for operators who lack technical skills to integrate tools through standardized interfaces or when the operator has limited resources to implement the tools. It also helps reducing times for the NaaS operator NOC to begin to operate.

The main points of this model are contained in Table 8.

Level of system integration	None
Ticketing coordination level	Phone call
Fault management coordination level	Email
Performance management coordination level	Only by email or formal request
Billing and revenue reconciliation coordination level	Call Data Registries (CDRs) provided to the customer MNOs

Table 8 — Collaboration level for rigid organizational model.

This model carries the least effort in terms of integration, but it also requires more human effort.

6.2.5.2 Typical Organizational Model

In the typical model, some tasks are partially automated, and others are kept manually since the effort to integrate the systems overcome the advantages.

This organizational model is recommended as the NaaS operator NOC matures if the starting point was the rigid organizational model. The level of collaboration between the areas should always consider the effort of implementation versus the advantages that it implies when deciding. This scheme is also recommended to operators who have the necessary budget/human resources or technical skills to deploy such integration.

The main points of the typical model are as follows:

Level of system integration	Most crucial operational activities (ticketing and fault management) and the business one (Billing/revenue reconciliation)
Ticketing coordination level	Web-/cloud-based system from NaaS operator
Fault management coordination level	Standardized interface from NaaS operator and vice-versa.
Performance management coordination level	Periodic reports
Billing and revenue reconciliation coordination level	Connection at BSS level

Table 9 — Collaboration level for typical organizational model.

The web-based ticketing is an efficient way of enabling the NaaS operator to avoid the human point of error when issuing a TT; besides, it allows the NaaS operator for easy management of the TT. The FM is considered key to a combined work, so the systems are fully interconnected, and this interconnection makes the problem solving smoother. Since the performance management is optional, a standard periodic reporting is enough. Finally, the decision of billing/revenue reconciliation integration allows the NaaS operator to have a better relationship with their customer MNOs.

6.3 Service levels Definition

Service levels specify the way that an incident is treated and the expected times for response and restoration based on the severity of the incident. Therefore, the first thing that needs to be defined by the NaaS operator is a criticality matrix which specifies the classification of incidents into categories or severities.

There are typically four severities deployed in most NOC organizations: critical, major, medium and minor. The NaaS operator must decide which scenarios fit each category, for which an initial recommendation is provided below:

● CRITICAL

• Several sites out of service. This can be adjusted to a fixed number of sites, the number of end-customers being impacted, or a percentage of the sites in the region/cluster/market.
• Loss of visibility to a network element manager or system.
• Loss of a single equipment (core or aggregation).
• Loss of a regulatory requirement, such as emergency call handling.

● MAJOR

• Single site out of service, or below the number of sites defined for a critical event.
• Loss of redundancy (e.g., circuit, equipment)
• Reduction in trunking capacity
• Loss of card (core, aggregation).

● MEDIUM

• Sectors or carriers out of service on a single site.
• Alarms on core/aggregation equipment without service impact.
• Performance degradation on several sites.

● MINOR

• Events without service impact.
• Performance degradation on a single site.

After the criticality matrix is set, the NaaS operator must set two variables for each category:

• Response Time The time in which the NOC must respond with a trouble ticket to any alarm or report occurred
• Restoration Time The time in which all services/faults impacted must be restored

The first variable is strictly NOC dependent, and is usually expressed in minutes (X minutes from alarm to ticket creation). The second variable needs consideration of several factors, including the agreed contractual SLAs with other parties (power companies, fiber/copper companies, tower companies, field maintenance) and their escalation paths. For instance, an operator might set the following service levels shown in Table 10:

Table 10 — Service level setting example

In addition to response time and restoration time, there is another vital service level agreement that needs to be set in place, which is the network availability. Network availability targets are established throughout the high-level network architecture stream; however, as part of the NOC implementation, the NaaS operator needs to set the expectations in line with the relative maturity of the business and the network.

During NOC implementation, the NaaS operator must assess if the target availability can be reached, considering the factors below:

1. What is the acceptable outage window for the business?
2. What impact will the outage have on the business in terms of lost revenue, customer satisfaction, or business reputation?
3. What is the different providers average mean time to restore (MTTR) when an outage occurs?
4. Scheduled maintenance windows are not considered as unavailable time.
5. If for any reason, the target cannot be met, the NaaS operator should re-define the target to a reachable value that meets the need of the business, offers an appropriate level of maturity, and will not jeopardize key customer relationships.

6.4 Team Design & Dimensioning

Once that the staffing model and the service levels have been defined, the NaaS operator must design and dimension the NOC organization. The following subsections address the NOC organization design and dimensioning, respectively.

6.4.1 NOC Organization Design

Based on section 3.2, the NaaS operator can select a configuration for the NOC organization. Following recommendations on section 3.2, three typical configurations for a NOC organization can be identified:

● CONFIG 1

✔ Tier 1 performs network surveillance + fault management

✔ There are allocated resources for both performance management and access management + field dispatch

✔ Tier 2 is separated into domains (i.e., RAN, TX, and core)

✔ There is a focused resource for OSS & tools

✔ There is one team leader per shift

✔ On the management side, there is one leadership position for tier 1, one for TX, one for core, both a problem and a change manager, an incident manager per shift and a general NOC manager

● CONFIG 2

✔ Tier 1 performs network surveillance + fault management + access management + field dispatch

✔ Tier 2 performs fault management tier 2 activities across the board for all domains, plus performance management

✔ There is a focused resource for OSS & tools

✔ There is one team leader per shift

✔ On the management side, there is one leadership position for tier 1, one for tier 2, an incident manager per shift and a general NOC manager

● CONFIG 3

✔ Tier 1 performs network surveillance + fault management + access management + field dispatch + some tier 2 activities (i.e., enhanced tier 1)

✔ Tier 2 performs fault management tier 2 activities across the board for all domains, plus performance management plus OSS & tools activities

✔ There is one team leader per shift

✔ On the management side, there is an incident manager per shift and a general NOC manager

The NaaS operator can choose one of the above configurations or define a customized configuration based on their own organizational requirements and constraints. If thats the case, guidance in section 3.2 can be applied with such a purpose.

6.4.2 NOC Organization Dimensioning

To establish an organizational structure, several factors need to be taken into consideration:

1. Number of RAN sites
2. Number of regions to be considered
3. Number of core sites
4. Number of work shifts
5. Configuration type (based on the section above or custom configuration)
6. Number of customer MNOs

This information will aid the NaaS operator to estimate the dimensioning of the NOC team. For this purpose, the NOC dimensioning tool displayed in Figure 10 is provided.

Figure 10 — Playbook NOC dimensioning tool

Each of the inputs above must be inserted in the corresponding field. The first three fields (RAN sites, regions, and core sites) are open, as shown in Figure 11:

Figure 11 — Open fields in the playbook NOC dimensioning tool

The remaining two inputs (work shifts and configuration type) have combo boxes enabled to choose from the available options, as shown in Figure 12.

Figure 12 — Combo boxes in the Playbook NOC dimensioning tool.

Once all the fields have been completed, the tool will show a summary at the top showing the headcount of NOC staff to be considered, as shown in Figure 13:

Figure 13 — Staff summary

Then a complete list of all the resources will be presented, starting with the tier 1 and tier 2 teams as shown in Figure 14:

Figure 14 — Tier 1 and tier 2 resources

This is followed by the rest of the operators and the management team calculation, as shown in Figure 15:

Figure 15 — Miscellaneous operators and management team

It is important to note that the additional staff resources due to number of MNOs will not greatly impact on the overall quantity. An additional 10% per MNO should suffice to cope with the demands of the MNOs.

Finally, it is worth mentioning that the tool is provided in Excel format which enables the NaaS Operator to change the underlying dimensioning assumptions based on their own experience or estimates.

6.5 Facility Design & Sizing

To dimension the NOC facility the NaaS operator must consider the peak number of resources that will be working on the NOC premises, according to the dimensioning performed on the previous section.

Through facility sizing the NaaS operator will be able to estimate office space, office equipment and networking and switching infrastructure, including office space that will be occupied, number of meeting/situation rooms needed, number of restrooms, laptops, screens, desks, chairs, and routing and switching equipment/ports.

Regarding the office space, it is important to consider that access and security infrastructure will be needed, as well as proper electrical/power distribution to be analyzed to offer a high availability solution in case of a power outage.

The NOC dimensioning tool can be used for facility dimensioning based on the headcount for the NOC team, as shown in Figure 16:

Figure 16 — Playbook NOC dimensioning: tool facility sizing