1. Tx Network High-Level Design Introduction

The Tx Network High-Level Design (HLD) module provides the NaaS operator with background information and methodologies to elaborate a HLD for a Tx network. It provides guidelines about how to design the transport network that interconnects disparate networks, including a radio access network (RAN) and data centers. It further provides instruction about how to transform guidelines into actual design parameters that is necessary for Tx network HLD development.

The main output of this module is the Tx network HLD that includes, among others, the transport design that specifies physical and logical topology, the transport solution to be implemented, and a high-level bill of quantities (BOQ). The business case can be analyzed with this information. This module will guide the NaaS operator through the process of generating a technically compliant HLD to speed decision-making and the related deployment process.

1.1 Module Objectives

This module will enable a NaaS operator to standup, run, and manage a Tx network HLD initiative. The specific objectives of this module are to:

1. Provide an information base and fundamentals to perform tasks associated with Tx network HLD.
2. Provide detailed how-to instruction regarding key HLD engineering tasks.
3. Provide an overview of the end-to-end Tx network HLD process, with instructions for tailoring it to specific NaaS environments.
4. Provide guidelines to develop a formal Tx network HLD recommendation.

1.2 Module Framework

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

Strategic plan and scope, along with high-level network architecture drive the strategic decisions to forthcoming phases. Network design is the first step in an implementation strategy supported by supply chain management.

The Tx network HLD module is included within the network design area and has direct relation with RAN HLD and mobile core HLD. The generated output of this module will serve as a required input for the Tx network LLD module.

Figure 1 &#8210 Module framework

Figure 2 presents the Tx network HLD functional view, where the main functional components are exhibited. Critical module inputs are further described and examined in Section 2.2. In addition, guidance and methodologies to execute the tasks included within each function are described in Section 3.

Figure 2 &#8210 Module functional view

The remainder of this module is structured as follows: Section 2 is a high-level overview of the Tx network fundamentals involved in its design. Once such knowledge is acquired, Section 3 focuses on showing a hands-on view of the involved design tasks. Section 4 organizes the tasks on an end-to-end process flow that can be used as-is, or be adapted by NaaS operators to match their particular conditions. To conclude, Section 5 illustrates how to integrate previous elements in a comprehensive HLD recommendation.

Review of fundamental transport technologies are found in the Learning Repository and is a useful prerequisite to this module.

2 HLD Fundamentals

General overview of the baseline concepts to develop a Tx network design.

2.1 Tx Network Environment

In a mobile environment, the transport network interconnects disparate networks, including the RAN, data centers, and external networks. Figure 3 displays the architecture of a typical transport network.

Figure 3 &#8210 Typical transport network

Mobile networks are ubiquitous and support a mix of traffic types originating from and terminating to mobile devices. All of this traffic must be conveyed between the mobile cellular base stations and transport network. For this reason, a number of aggregation levels exist on the transport network that for most NaaS operators can be classified as either: last-mile or aggregation level.

The implementation of 4G long-term evolution (LTE) imposes some requirements on transport networks, such as more network capacity and latency reduction. These are better served through terrestrial technologies (fiber optic and microwave). But in rural areas this becomes a challenge because satellite transport is usually the only feasible technology. For this reason, transport network infrastructure is an essential component of the NaaS operator network; its design must be performed with optimal processes and techniques.

2.1.1 Requirements for Transport Network

Capacity: Compared to 2G and 3G, LTE base stations support a considerable amount of traffic. In addition to user traffic, control, management, and synchronization traffic must be considered. A detailed explanation regarding traffic models is provided in Section 3.4.

Latency: In addition to capacity increase, latency reduction is one of the key goals of LTE deployments. The delay requirements for the transport depend on the end-to-end delay of end customer applications and on the delay budget given to the transport. Latency requirements can be an important limitation for some transport technologies such as satellite and can directly affect its feasibility.

Availability: The availability requirements of the transport network are derived from the those of the end-user service. A typical requirement for a transport network in a rural environment could be an availability value of 99.95%. In most cases availability is dominated by the last-mile link.

2.2 Network Design Inputs Description

This section analyzes the module input data and their respective candidate sources, as presented in Table 1. In addition, the impact of module inputs on the design process is examined.

Input Required	Description	Candidate Source	Impact
RAN HLD Design	Describes parameters related with RAN solution (site location, RAN equipment, covered population)	RAN HLD Module	– The total number of RAN sites determines tool selection to perform the transport feasibility analysis (details in following sections)
Tx & IP Architecture	Includes the technologies, equipment, and protocols to be considered in the design	Tx & IP Architecture Module	– Establishes the available transport technologies to be evaluated during the feasibility analysis and their respective technical considerations
Operator Network Data	Consists on consolidated information regarding operating data network (e.g., existing network elements, implemented protocols)	– Network operators tools (e.g., inventory, OSSs) – Transport provided network data	– Contains the existing transport nodes and technologies to be considered during feasibility analysis
Offered Service Catalogue	Contains a list of services to be provided and is an output from Tx & IP Architecture Module	Tx & IP Architecture Module	– Offered services determine the service level requirements for the transport network
Commercial Criteria	Guideline criteria to follow during design process	Commercial area	– Establishes guidelines to prioritize use of one transport provider over others during the feasibility analysis – Establishes the budget to acquire design tools during feasibility analysis

Table 1 &#8210 Module inputs analysis

2.3 Transport Solution Feasibility Analysis

This section describes the feasibility considerations for different transport technologies to be used on the transport network. When it comes to technical transport solutions, mobile operators have several at their disposal. Mobile operators prefer fiber optic where available &#8210 especially in city centers &#8210 but microwave is the mainstay for last-mile traffic. Satellite transport is mainly deployed where existing transport infrastructure isn’t available.

2.3.1 Fiber Optic Technology

Fiber optic is the mainstay wired transport in mobile operator networks when its available because of its significant, inherent bandwidth-carrying ability. Several other techniques can be used to offset any bandwidth constraints and essentially render fiber assets future-proof.

While fiber optic has tremendous operational capacity, its main limitation is its cost and deployment logistics. Moreover, it can take several months to provision each cell site with fiber optic transport.

The fundamental aspects of fiber optic technology design are discussed in the Primer on Fiber Optic Technologies Principles.

2.3.2 Microwave Technology

Most operators heavily rely on microwave transport solutions in the 5 GHz – 80 GHz bands (in rural environments, frequencies above 15GHz are not generally feasible). Microwave is a low-cost option for mobile transport, as it can be deployed in a matter of days and support a range of up to several tens of kilometers.

The main limitation of microwave links is its line of sight (LOS) requirement between transmitter and receiver. This represents a drawback for its implementation, especially in rural areas due to steep terrain conditions that often exist. In addition, in many cases microwave requires a license to be obtained. And in high frequencies, microwave links are subject to atmospheric effects or rain fade, which can attenuate the signal and limit its range.

The fundamental aspects of microwave technology design are discussed in the Primer on Microwave Technologies Principles..

2.3.3 Satellite Technology

Satellite technology is deployed in fringe network areas, usually in rural locations within emerging markets. It may be deployed as a temporary measure as an operator waits for regulatory microwave licenses to be approved. Coverage is determined by satellite footprint. More details are provided in Section 3.

Table 2 presents a comparison of satellite orbits.

Orbit	GEO	MEO	LEO
Distance	35,800 km	2,000km-35,000km	160km-2,000km
Latency	250-500 ms	60-250 ms	30-50 ms
Throughput	Up to 500 Mbps	Up to 800 Mbps	1Gbps+ *(See NOTE)
Handover Periodicity	No HO	2-3 hours	15-20 min

Table 2 &#8210 Satellite orbit comparison

*NOTE: As LEO systems have not been commercially launched, the 1Gbps value is used as a theoretical reference.

The cost of satellite terminal equipment located at the base station is in line with microwave equipment. However, the OPEX burden generated by the satellite service fee can impact the business case.

The fundamental aspects of satellite technology design are discussed in the Primer on Satellite Technologies Principles.

2.4 Physical Topology Design

As stated in Section 2.1, a typical transport network consists of two domains: Last-mile and aggregation. In most cases there might exist a connection provided by a third party network to connect to core elements. Domain borders are mostly defined by the technology and topology used within the domain. Domain characteristics in terms of physical topology are:

• The last-mile and aggregation domains provide connectivity to the eNodeB at the cell sites and is predominantly based on tree and chain topologies built with microwave radios and fiber optic links.
• The third-party network domain is used to transport the network traffic to the core elements (EPC core) &#8210 an IP/MPLS routed network in nearly all cases. These networks belong to telco/fiber providers and can also be used where a NaaS operator doesnt have network presence.

Figure 4 displays the transport network structure:

Figure 4 &#8210 Basic structure of a mobile transport network

The depicted structure considers various physical technologies and topologies. From left to right, the last-mile connects a demarcation device (usually deployed at the cell site) to a first stage of traffic grooming and concentration. In turn, the aggregation network further aggregates traffic, adapts any technology change, and provides the hand over point to a higher level of aggregation network.

Physical connectivity represents any technology that can be used to connect nodes (details in section 3). In addition, a networking layer is implemented on top of the physical layer; it embraces all possible logical architectures needed to steer LTE traffic and applications. Details on network topology design are covered in the Tx LLD Module.

2.5 Capacity Planning Process

In simple terms, the transport network should be dimensioned to provide reliable service to users. They should be able to connect to the network and use subscribed services anytime inside the coverage area &#8210 where service outages or connectivity problems should be rare. To achieve this, a capacity planning analysis must be performed to determine the traffic the transport network must support.

2.6 Transport Solution Definition

An assessment of implementing a transport network or link is dependent on feasible transport solutions and capacity requirements, as well as the following implications.

Feasible Transport Solutions Feasibility analysis is an essential step in defining the transport solution to be deployed, for not all the solutions are appropriate in rural areas. Thus, feasibility might be the most important constraint in selecting a transport technology.

Capacity Requirements In wireless-based solutions (MW and satellite), it’s essential to validate that sufficient capacity exists to satisfy traffic requirements. Capacity planning assesses how much traffic can be supported by transport technologies.

Deployment Cost Deployment cost can be a essential criterion when a network operator is faced with deploying several cell sites in one year.

Time to Deploy and Licensing Network operators are often under pressure to get a cell site operational as quickly as possible. Having to wait several months for a fiber optic connection to be provisioned to a cell site can prevent its selection in the near term.

Table 3 presents a high-level comparison of technology parameters to be implemented on the transport network.

Parameter	Fiber Optic	Microwave	Satellite
Future-proof Available Bandwidth	High	Medium	Low
Deployment Cost	High	Low	Medium
Interference Immunity	Very-high	Medium	Medium
Range (km)	<80	<30* (5-15GHz)	Subject to satellite footprint
Time to Deploy	Months	Weeks	Weeks
Licensed Required	No	Both (Licensed/Unlicensed)	No

Table 3 &#8210 Transport technologies high-level comparison

*Note: Typical value; however, microwave links can be engineered to reach larger distances.

3 Functions & Methodologies

This section presents recommended methodologies to perform critical tasks/subtasks involved in the Tx network design process.

3.1 Fiber Optic Path Design

3.1.1 Right of Way Definition

An actual fiber route will be determined by the physical locations along the way, local building codes or laws, and other considerations involved in the design. Laying fiber optic cable may cross long lengths of open fields; run along paved rural or urban roads; cross roads, ravines, rivers, or lakes; or &#8210 more likely &#8210 some combination thereof. It could require buried, aerial, or underwater cables. Cable may be in conduit, innerduct, or direct-buried; aerial cables can be self-supporting or lashed to a messenger. In rural areas, aerial cable is the most common deployment due to its low cost and fast implementation.

For this reason, a NaaS operator must define a set of rules (i.e., rights of way) that specify criteria to follow during fiber optic laying design. This set of rules prioritize the previously mentioned characteristics according to the operators requirements.

3.1.2 Geospatial Database

A geospatial database must be consolidated by the operator during the design process. It should contain road information, topographical data, and sometimes satellite images overlaid on roads (when available).

Other kinds of data to be considered are existing conduit, property boundaries, easements, gas pipelines, and areas of special interest. Each provides extra information that can be used to generate a fiber laying designeither things to avoid (e.g., gas pipes) or ways to save cost (e.g., existing conduit).

Streets and addresses are available as open source data in many places in the world (e.g., OpenStreetMap), but the remainder usually has to be sourced from local government councils or companies. A key step in using geospatial data is to confirm its quality, structure, and format so it can be useful for design.

3.1.3 Fiber Path Design

An identification of multiple paths to link origin and destination must be performed in designing the fiber optic path. These alternatives will likely include a combination of multiple rights of ways and have various optical lengths.

Although the specific steps can vary depending on the selected GIS tool, general steps in performing fiber path design are:

1. Load the locations of origin and destination nodes in a GIS tool.
2. Identify available routes linking the origin and destination nodes. Draw the path using the options provided by the GIS tool. Figure 5 shows an example of multiple path alternatives (A, B, C) from origin to destination nodes.

Figure 5 &#8210 Example of fiber path design

3. Using the GIS tool options, measure lengths of the alternatives; these represent the optical length of each path. Typically 20% is added as a margin to each measurement. Figure 5 shows each path length, with option A being the longest.
4. Rank the alternatives to prioritize those that better comply with defined rights of ways having minimum length. A higher-ranked alternative will be selected as the final route.

3.1.4 Fiber Path Reporting

Once the fiber route is designed, create a path design report that includes:

• Nodes involved: Origin node, destination node (name, coordinates)
• FO route parameters: Total optical distance, utilized rights of way, laying classification (new/existing), laying type (aerial/buried/underwater).

3.2 Microwave Line of Sight (LOS) Verification

A microwave LOS analysis determines whether a signal path is available between transmitting and receiving antennas. This assures that a clearance of the first Fresnel ellipsoid is achieved.

The absence of relevant obstacles along the path to ensure LOS clearance is based on geometrical calculations. These require topographical databases used for path profile extraction. Profiles are to be drawn in a path profile diagram, along with the expected path taken by a radio signal. The diagram will enable comparison of both plots (profile and radio signal path) to analyze possible diffraction or reflection effects of the terrain.

3.2.1 Digital Terrain Databases

In general, most propagation predictions are based on detailed topographical information. This information is provided by digital terrain elevation (DTE) models composed by digital terrain topographical databases and represented in the form of digital terrain maps. The models provide accurate information that can be used to evaluate path clearance and potential loss associated with diffraction. They’ll also be used in the algorithm required for determining interference to/from other stations of the link, or arriving to/from other radio systems sharing the same bands.

Depending on the tool selected to perform the design, DTE models are often included. If not, some DTEs are available as open source data in many places in the world (e.g., Google Maps Elevation API).

3.2.2 Profile Extraction, Clearance, and Obstructions

The LOS clearance analysis is based on studying terrain heights between stations of the hop and along the path profile; comparing these with the expected path followed by the radio signal (first Fresnel ellipsoid).

Although specific steps can vary depending on the selected verification tool, the general steps to perform microwave LOS verification are:

1. Load the locations of the origin and destination nodes in the tool. Figure 6 displays the analysis for one site when two transport nodes are considered.

Figure 6 &#8210 Example of microwave link design

2. Load tower height information for each of the sites. As a margin, typically each height is considered to be 3m below actual to account for space to implement the MW antennas.
3. Using options provided by the selected tool, measure the distance between the sites; this represents the microwave link length. Figure 6 shows two links, with option A having the longest length.
4. Select the frequency to be used based on link length (11GHz in Figure 6).
5. Generate the microwave link profile using options provided by the selected tool.
6. Verify that the first Fresnel zone is obstacle free (LOS is validated when there are none). Figure 7 depicts profiles generated for the example, where LOS is only validated for link B.

Figure 7 &#8210 LOS validation during microwave link design

3.2.3 Microwave LOS Validation Reporting

Once LOS clearance has been validated, create a link design report that includes the following information:

• Nodes involved origin node, destination node (name, coordinates)
• MW link parameters link distance, transmission frequency, antenna heights, antenna azimuths
• MW profile link an image that validates link LOS status

3.3 Satellite Link Validation

3.3.1 Satellite Coverage Verification

The satellite footprint &#8210 the ground area covered by its radiation &#8210 should be obtained to validate satellite coverage. Footprint size depends on satellite location within its orbit, the shape and size of beam produced, and its distance from Earth. Footprints usually show estimated signal strength in each area as measured in decibel watts (dBW).

The majority of commercial satellites provide their footprint in respective documentation, or you can access it from satellite footprint databases (e.g., Satbeams at satbeams.com/footprints).

To establish a satellite link according to service level requirements, the minimum signal strength on reception must be defined based on satellite service provider specifications. Given this data, coverage validation for a specific site location can be performed using GIS operations. The aim is to determine whether the location is inside the polygon defined by the footprint and has the minimum level of strength required for the implementation. Depending on the selected tool using methodology in section 4, these operations can be processed in batch mode.

3.3.2 Satellite Parameter Calculation

The methodology presented in this section helps determine parameters for geostationary satellites. Azimuth and elevation angles are referred to as the look angles from the earth station (EA) to the satellite. Figure 8 shows the geometry and definitions of look angles with respect to the earth station reference.

Figure 8 &#8210 Look angles with respect to ES reference

The azimuth angle, ϕ, is measured from true north in an eastward direction to the projection of the satellite path onto the local horizontal plane. The elevation angle, θ, is the angular distance between the satellite and the observers local horizon or the observers local vertical plane.

Look angles from an earth station to a satellite are determined from:

Where:

S = Satellite longitude in degrees

N = Site longitude in degrees

L = Site latitude in degrees

3.3.3 Satellite Coverage Validation Reporting

Once satellite coverage is validated and look angles calculated, create a link design report that includes the following information:

• Nodes involved: Origen node (coordinates), elevation above sea level, terrestrial station (coordinates).
• Satellite link parameters: pointed satellite, frequency satellite band antenna elevation and azimuth.

3.4 Capacity Forecast Analysis

This section presents a methodology to obtain the total amount of traffic the transport network needs to support. It can be summarized as:

• Transport traffic is predominantly user data, so an analysis considers this first, adding other components such as overhead and signaling later. This approach provides figures for the total transport traffic per eNodeB, representing the provisioning needed in the last mile of the transport network.
• Provisioning for the aggregation domain is then derived by combining traffic from multiple eNodeBs, using simple assumptions for statistical multiplexing gains.

3.4.1 Sector Throughput

In a typical LTE cell, throughput varies due to the averaging effect of much user equipment (UEs) using the network. It’s during quiet times that peak (and thus last-mile link) throughputs occur, when one UE with a good link has the entire cell to itself. Last-mile provisioning should ensure that advertised peak rates are at least feasible. Figure 9 shows sector throughput variations.

Figure 9 &#8210 Illustration of cell throughput variations

Define the following inputs to model traffic behavior presented in Figure 9:

• &#8210 average capacity used by eNodeB, calculated by Eq. 1)
• &#8210 the relation between peak and average capacity. For an LTE downlink, peak is around 4 &#8210 6 times average throughput
• &#8210 required peak capacity, calculated by multiplying average capacity by the peak-to-average-ratio
• &#8210 is a parameter an operator can obtain from the existing network or previous deployment. If not available, the typical values of an LTE system can be considered. Table 4 displays cell average throughput for various scenarios and bandwidths.

Bandwidth	Scenario	Sector Average Throughput
		DL (Mbps)	UL (Mbps)
5	Urban	8	5
	Suburban	6	3
10	Urban	17	10
	Suburban	13	7
15	Urban	25	15
	Suburban	20	10
20	Urban	33	20
	Suburban	26	14

Table 4 &#8210 Typical average sector throughput for LTE-FDD (considering MIMO 2×2)

3.4.2 Cell Throughput

In an LTE network, UEs are served by one of many sectors in the coverage area. A macro LTE base station (eNodeB) typically manages three sectors; micro and pico eNodeBs typically only control one sector. Transport traffic per eNodeB is the total traffic generated by all sectors and controlled by it. In real scenarios, its highly unlikely that the peaks of multiple sectors occur at the same time; however, the average capacity occurs in all sectors simultaneously. Equation 1 displays a common approach to calculate the transport capacity for multiple sectors:

(Eq. 1)

Where:

#Sectors_4G is the total number of sectors (3 in macro, 1 in micro/pico)

3.4.3 Last-Mile Link Capacity

In addition to user plane traffic, transport traffic comprises a number of additional components:

• X2 Traffic &#8210 X2 interface is predominantly user traffic forwarded during UE handover between eNodeBs. X2 traffic volume is often expressed as a volume of S1 traffic, with 4% being a cautious average of these figures
• Control Plane, OAM, and Synchronization Signaling &#8210 Control plane signaling on both S1 (eNodeB to core) and X2 (eNodeB to eNodeB) is considered to be negligible in comparison with associated user plane traffic; it can be ignored. The same is true for OAM (operations, administration, and maintenance) and synchronization signaling.
• Transport Protocol Overhead &#8210 Transport traffic is carried through the evolved packet core in tunnels, which enable the UE to maintain the same IP address as it moves between eNodeBs and gateways. LTE uses either GTP (GPRS tunneling protocol)also used in GSM and UMTS coresor mobile IP tunnels. The relative size of tunnel overhead depends on end user packet size distribution. The NGMN backhaul group assumes an overhead of 10% represents the general case.
• IPsec &#8210 User plane data on the S1-U interface between the eNodeB and serving gateway is not secure and could be exposed if the transport network is not physically protected. In many cases, the operator owns their transport network and additional security isnt needed. But if user traffic were to traverse a third party untrusted network, then it should be protected. Here, 3GPP specifies IPsec Encapsulating Security Payload (ESP) in tunnel mode should be used. Unfortunately, this adds further overhead to the user data. The NGMN backhaul group assumes ESP adds an additional 14% on top of the transport protocol overhead.

Equation 2 displays a high-level approach to calculate last-mile transport capacity for a single eNodeB:

(Eq. 2)

3.4.4 Aggregation Link Capacity

Peak cell throughput is mainly applicable to the last mile of the transport network, or when aggregating a small number of eNodeBs. Toward the core, traffic of many cells is aggregated and the average capacity is the dominant factor.

Moreover, when multiple eNodeBs are aggregated, a statistical gain can be applied as eNodeBs wont likely use all available capacity at the same time. This gain is represented by the overbooking factor (OBF). Equation 3 displays the approach to calculate transport capacity required for a link that aggregates multiple eNodeBs:

(Eq. 3)

Where:

• is the overbooking factor reflecting the statistical gain
• is the number of aggregated eNodeBs using the same link

Capacity forecast analysis can be performed using the Tx Network Capacity Forecast Widget.

3.5 Availability Calculation

This section describes a methodology to perform a generic availability calculation that can be used to compare network topologies. This calculation must consider failures due to a link, equipment, power outage, or weather conditions. In rural environments, additional considerations must be considered due to environmental phenomenon (e.g., fiber cuts, equipment failure due to storms).

Availability is calculated using commonly known formulas for mean time between failures (MTBF) and mean time to repair (MTTR). Equipment vendors provide MTBF values for equipment and hardware modules. MTTR is the time taken to repair a failed system. Systems may recover from failures automatically or by manual repair. MTTR varies from operator to operator, depending (for example) on replacement hardware availability and the time it takes to deliver it to the site and change it out.

Availability (A) is calculated from the MTBF and MTTR, as presented in Equation 4:

(Eq. 4)

Table 5 shows the downtime period per year according to different values of availability.

Availability	Downtime per year
99%	3.65 days
99.9%	8.76 hr
99.99%	52 min
99.999%	5 min

Table 5 &#8210 Availability and corresponding downtime per year

3.5.1 Availability of a Serial System

A single transport link can be seen as an array of elements connected in a serial manner. Redundancy is considered by raising the probability of failure to a power equal to the number of redundant elements. The mathematical expression to calculate availability is given in Equation 5:

(Eq. 5)

Availability of each element () can be calculated with (Eq. 4). If data is not available, generic values can be used according to equipment and link type.

3.5.2 Availability Calculation Example

Again, availability calculations can be performed to compare network topologies. In this example, the availability of a single MW link (Figure 10) is calculated.

Figure 10 &#8210 Availability calculation for a MW link

The first step is to calculate availability of the different equipment taking into account its replacement time. MTBF values vary depending on vendor, with the Table 6 values used in this example:

Equipment	MTBF(years)	MTTR (hours)	Availability
Microwave outdoor unit	80	6	99,9991%
Microwave indoor unit, 1+0	60	4	99,9992%
Microwave outdoor unit, hot stand-by	–	–	100,0000%
Microwave indoor unit, 1+1	–	–	100,0000%

Table 6 &#8210 Availability calculations for various hardware configurations

Use of redundancy is a simple technique to leverage link availability. In this example, hardware protection options are considered to implement redundancy. For the outdoor unit, a hot standby configuration is considered. For the indoor unit, a 1+1 configuration is considered. The availability calculations for these configurations are included in Table 6.

Using equation 5 (presented in Table 7) to calculate total MW link availability considering different equipment, indoor and outdoor units, as well as availability due to climatic factors. In this example, MW link availability of 99.999% due to climatic factors is considered.

Equipment and link configuration	Calculation
Non hot standby + (1 + 0) indoor unit	99,9958%
Hot standby + (1 + 0) indoor unit	99,9975%
Hot standby + (1 + 1) indoor unit	99,9990%

Table 7 &#8210 Availability calculations for a MW link with various redundancy options

From Table 7 it can be seen that the total availability calculation is governed by the smallest system availability value.

Availability of a microwave link chain can be calculated considering the number of hops (displayed in Figure 11).

Figure 11 &#8210 Availability calculation for a MW chain

Table 8 displays the result calculated for the Figure 11 scenarios and different redundancy types.

# Links	Non hot standby	Hot standby	Hot standby, 1 + 1 indoor unit
1	99,9958%	99,9975%	99,9990%
2	99,9923%	99,9957%	99,9980%
3	99,9888%	99,9940%	99,9970%

Table 8 &#8210 Availability comparison for MW chain types

Methodology presented in this section can be used to calculate a microwave link by considering the equipment involved and link characteristics.

Availability calculations can be performed using the Tx Network Availability Calculation Widget.

4 E2E Process Flow

This section presents a generic yet customizable end-to-end process flow to design a transport network.

4.1 End-to-End Process Overview

The generic end-to-end (E2E) process flow displayed in Figure 12 shows general tasks to perform a transport network HLD in a logical and well-structured sequence.

Figure 12 &#8210 Generic E2E process flow

• Service Level Requirements &#8210 Establishes transport network parameters to comply with various service levels.
• Design Tool Selection &#8210 Selects the most suitable tool set and level of automation to be implemented during the design phase.
• Transport Solution Feasibility &#8210 Obtains technically feasible options by evaluating available transport technologies using tools defined in Design Tool Selection.
• Physical Topology Design &#8210 Determines the physical topology of the transport network based on the feasible transport technologies.
• Capacity Planning &#8210 Estimates the total amount of traffic the transport network needs to support considering the physical topology.
• Transport Solution Definition &#8210 Determines the final transport technology to be implemented for each transport link, considering feasible technologies and forecasted traffic.
• Tx Standard Configurations &#8210 Standardizes the possible transport equipment configurations.
• Tx Equipment BOQ Generation &#8210 Determines equipment required to implement the transport solution.

Step details and customization options are reviewed in the following sections. In addition, a Tx HLD Process Flow Designer is provided as part of the methods of engagement.

4.2 Step-by-Step Analysis

Based on NaaS operator requirements and constraints, this section examines each process step to identify, isolate, and describe the range of implementation options on the path toward customization. Dependencies among tasks are addressed in the corresponding subsection.

Design Example

To demonstrate a practical exercise in implementing design flow, each process step was followed to create a HLD from the scenario presented in Figure 13.

Figure 13 &#8210 HLD example

This scenario comprises eight RAN sites to be analyzed in performing the transport HLD. It considers three available transport nodes that provide connection to the core network. Technologies to be evaluated are: Fiber Optic, Microwave, and Satellite. The total availability target for the transport network is 99.5%.

4.2.1 Service Level Requirements Definition

Operators must define levels of service according to network domains (last-mile/aggregation). Satellite transport links must be considered as a special case. In the transport network, the main parameters that must be defined are: latency, packet loss ratio, and availability.

Table 9 shows a definition example for three LTE deployment service levels.

Service Level	Latency – RTT (ms)	Packet Loss Ratio (%)	Availability (%)
Last-mile Link	40	0,1	99,9
Aggregation Link	20	0,01	99,99
Satellite Link	200	0,1	99,9

Table 9 &#8210 Service requirement definition example

Design Example

Table 9 values will be considered in the design example.

Dependencies with other tasks

The Service Level Requirements Definition presents the following dependencies:

Prerequisites

• Offered Service Catalogue &#8210 A list of offered services must be provided to specify service levels that cover them.

Outputs

• Transport Solution Definition &#8210 Service Level Requirements Definitions are used during this process (details in section 4.2.7).

4.2.2 Tx Standard Configurations Definition

This definition is to standardize possible transport equipment configurations to be implemented. By doing this, design options are constrained (simplifying the overall process).

The detail level for possible scenarios must be defined in creating the configurations. Possible alternatives to be used are: Transport Technologies, Tx Equipment Vendor, RAN Equipment, and Transport Vendor. Its highly recommended that available transport technologies be selected to minimize the number of possible alternatives and simplify the design process.

First perform a detailed identification of all possible scenarios. Next, identify general transport equipment characteristics for each scenario.

Figure 14 displays a brief example of the Standard Configurations Generation considering the available transport technologies and RAN configuration. A NaaS operator can use this example to customize its own definition process.

Figure 14 &#8210 Example of Tx Standard Configurations Definition

Design Example

Available transport technologies will be considered in creating the standard configurations. Table 10 shows the standard configuration considered in the design example for fiber optic equipment.

Table 10 &#8210 Standard fiber optic configurations considered

Table 11 lists standard microwave equipment configurations considered in the HLD example.

Table 11 &#8210 Standard microwave configurations considered

Table 12 shows standard satellite equipment configurations considered in the example.

Table 12 &#8210 Standard satellite configurations considered

Dependencies with other tasks

The Transport Standard Configurations Definition presents the following dependencies:

Prerequisites

• Tx Architecture &#8210 Available transport technologies will determine possible scenarios.

Outputs

• Transport Solution Definition &#8210 Standard configurations are used during Transport Solution Definition (details in section 4.2.7).

4.2.3 Design Tool Selection

This section provides general criteria for selecting the most suitable tool set and level of automation to be implemented during the design phase.

A classification of available tools is required to select the appropriate design tools to perform the transport HLD. Table 13 displays a generic tool type classification to serve as a base in performing the selection.

Tool Type	Implementation type	Type of License	Automation	Customization	Support Type
Tier 1	Commercial tool	License cost	High/Medium: Batch mode usually based on scripts	High: Customization options provided by developer	Dedicated support (extra charges can apply)
Tier 2	Open-source code	Free	High/Medium: Batch mode usually based on scripts	Medium/High: Customization options implemented by users	Wiki + Community Groups
Tier 3	Web-based, APIs	Free (sometimes usage limited per day)	Low: Usually, one by one approach	Low: Usually only proprietary parameters are defined	Limited support
Tier 4	Home-grown (e.g Spreadsheet)	Free	Medium: Automation options requires high cycle times	Medium: Customization options requires high cycle times	No support

Table 13 &#8210 Tool type classification

Specific classifications for each transport solution are addressed in corresponding subsections.

Dependencies with other tasks:

Design Tool Selection presents the following dependencies:

Prerequisites

• RAN HLD Design &#8210 Total number of sites will determine the number of calculations to be performed.
• Available Budget from Commercial Area &#8210 Determines the available budget to acquire a design tool.

Outputs

• Transport Solution Feasibility Analysis Selected tools from this section are used during a feasibility analysis.

Transport Solution Feasibility Analysis &#8210 Selected tools from this section are used during a feasibility analysis.

4.2.3.1 Tool Selection Process

The selection process must consider different aspects regarding project scope and NaaS operator characteristics. A list of examples follows:

• Number of elements to design &#8210 Each element implies an operation a design tool must perform (e.g., one fiber optic path design, one LOS validation calculation) that is directly related to the number of sites. The number of potential design elements has a direct repercussion on the level of automation to be implemented.
• Available budget for tools from the Commercial Area.
• Team skill sets &#8210 Coding abilities, Linux/Unix, database management, etc.

Figure 15 displays a generic process to perform tool selection. A NaaS operator can use this process as a basis in defining its own version according its own priorities.

Figure 15 &#8210 Tool selection process

4.2.3.2 Fiber Path Design Tool Selection

Tools used to perform fiber path design are listed in Table 14 according to defined parameters.

Tool Type	Name	Description
Tier 2	QGIS	Free and open-source cross-platform desktop geographic information system application that supports viewing, editing, and analysis of geospatial data
Tier 3	Google Earth	Google Earth is a computer program that maps the Earth by superimposing satellite images, aerial photography, and GIS data onto a 3D globe, allowing users to see cities and landscapes from various angles.

Table 14 &#8210 Tool classification for fiber optic path design

Following section 4.2.3 methodology, a NaaS operator can select a fiber path design tool.

Design Example

Google Earth will be the GIS tool used to perform the Fiber Path Design.

4.2.3.3 Microwave LOS Verification Tool Selection

Tools used to perform the microwave LOS verification are shown in Table 15 according to defined parameters.

Tool Type	Name	Description
Tier 3	Google Elevation API	The Elevation API provides elevation data for all locations on the surface of the earth
	airLink	LoS Evaluator to verify and validate LoS in MW Links. The tool is available through a web-based interface

Table 15 &#8210 Tool classification for microwave LOS verification

Following methodology presented in 4.2.3, the NaaS operator can select a microwave LOS verification tool.

Design Example

airLink will be used to perform the LOS validation in the HLD example.

4.2.3.4 Satellite Coverage Verification Tool Selection Process

Tools used to perform Satellite Coverage Verification are classified in Table 16 according to defined parameters. A QGIS tool must be selected to validate satellite coverage. An additional tool can be used to calculate satellite parameters (e.g., look angles).

Tool Type	Name	Description
Tier 2	QGIS	Free and open source, cross-platform desktop geographic information system application that supports viewing, editing, and geospatial data analysis
Tier 3	Satbeams	Provides satellite footprint from commercial satellites

Table 16 &#8210 Tool classification for satellite coverage verification

Following methodology presented in 4.2.3, a NaaS operator can select a satellite coverage verification tool.

Design Example

Satbeams will be used as the satellite coverage verification tool in the design example.

4.2.4 Transport Solution Feasibility Analysis

A Technology Feasibility Analysis helps determine feasible alternatives considering an operators available technologies. An operator can select one of the following approaches to perform the analysis:

• Approach 1 &#8210 Evaluate available transport technologies in parallel and compare/select based on defined criteria. All technologies must be analyzed independently of attractiveness.
• Approach 2 &#8210 Rank available technologies based on attractiveness to operator and evaluate in a serial manner. When a higher-ranked technology is feasible, lower-ranked technologies are not evaluated. Some resources can be optimized following this approach by reducing the required time to evaluate all technologies.

Depending on characteristics of selected tools to perform technology evaluations, the analysis can be done in batch mode or in a one-by-one fashion.

Figure 16 displays a high-level view of approaches to perform the Transport Solution Feasibility Analysis.

Figure 16 &#8210 Transport solution feasibility approaches

Design Example

The design example used Approach 2. Analysis for a specific node will stop when a transport technology is feasible. The technology ranking becomes: fiber optic, microwave, then satellite.

Dependencies with other tasks

Transport Solution Feasibility Analysis presents the following dependencies:

Prerequisites:

• RAN HLD Provide RAN solution information (site name, location, RAN equipment).
• Design Tool Selection Provides selected tools to be used to perform design operations.
• Operator Network Database Information regarding RAN and transport nodes.

Outputs

• Transport Solution Definition Transport Solution Feasibility Analysis is used during Transport Solution Definition (details in section 4.2.7).

4.2.4.1 Fiber Optic (FO) Technology Evaluation

1. Based on the origin node, select a list of candidate transport nodes within a radius equal to FO Maximum Distance defined in the Architecture Module. FO Maximum Distance is a design parameter based on the maximum cost permissible to deploy fiber optic.
2. For each candidate node, apply the methodology presented in section 2 to define the fiber path to candidate transport nodes. The candidate transport node list will only contain nodes with a FO path length less than FO Maximum Distance.
3. Define FO Tx Node as the most suitable candidate considering commercial criteria.

Figure 17 displays the FO Solution Evaluation process.

Figure 17 &#8210 FO solution evaluation process

Design Example

Section 3.1 methodology is applied to evaluate FO technology using Google Earth as a GIS tool. Figure 18 shows the analysis results, where four nodes are feasible to use a fiber optic link according to the requirements.

Figure 18 &#8210 FO technology evaluation in design example

Analysis results are recorded in the TX HLD Report Template.

4.2.4.2 MW Technology Evaluation

1. Based on the origin node, select a list of candidate transport nodes within a radius equal to MW Maximum Distance defined in the Architecture Module. MW Maximum Distance is a design parameter based on the maximum link distance covered by MW equipment.
2. For each candidate transport node, apply the methodology presented in section 2 to evaluate LOS for candidate transport nodes. This transport node list will only contain nodes with a MW link distance less than MW Maximum Distance.
3. Define MW Tx Node as the most suitable candidate considering commercial criteria.

Figure 19 displays MW Solution Evaluation process.

Figure 19 &#8210 MW solution evaluation process

Design Example

Using AirLink as a LOS validation tool, section 3.2 methodology is applied to perform the MW technology evaluation. Figure 20 displays the analysis results, where three nodes are feasible to use a microwave link according to requirements. The remaining three links present path obstruction, so a microwave link isn’t feasible.

Figure 20 &#8210 MW technology evaluation into design example

Analysis results are recorded in the TX HLD Report Template.

4.2.4.3 Satellite Technology Evaluation

1. Based on the origin node, apply section 2 methodology to evaluate satellite coverage in all available solutions.
2. Define Satellite Tx Solution as the most suitable candidate considering commercial criteria.

Figure 21 displays the Satellite Solution Evaluation process.

Figure 21 &#8210 Satellite solution evaluation process

Design Example

Section 3.3 methodology is applied to perform the satellite link validation using footprints available on Satbeams. According to the requirements, Figure 22 shows its feasible to implement a satellite link using the node undergoing analysis.

Figure 22 &#8210 Satellite technology evaluation

Look angles for the sites are displayed in Table 17.

Table 17 &#8210 Look angles calculated for the design example

The results of the analysis are recorded in the TX HLD Report Template.

4.2.5 Physical Topology Design

Depending on available transport solutions and how theyre combined during the feasibility analysis, a few transport network topologies are possible. Figure 23 presents some examples.

Figure 23 &#8210 Examples of transport network topologies

The following set of tasks must be performed for each transport link to create the physical transport design:

• Establish the physical topology of each transport network link, identifying the domain classification (last-mile/aggregation) based on the feasibility analysis.
• Apply section 3 methodology to verify the presented scenario complies with the target availability requirement according to domain classification. The maximum number of chain links is based on availability targets set for the transport network domains. Additionally, some type of redundancy can be selected to increase availability.

Design Example

Figure 24 presents the three physical topologies identified for the design example.

Figure 24 &#8210 Topology scenarios presented in the design example

Table 18 displays corresponding availability calculations for each scenario, as well as the total availability for the transport network. The transport network design complies with the availability requirement of 99.5%.

Table 18 &#8210 Availability calculations for design example

Data presented in Table 18 were calculated using the Tx Network Availability Calculation Widget.

Dependencies with other tasks

Physical Topology Design presents the following dependencies:

Prerequisites

• RAN HLD &#8210 Provide information regarding RAN solution (site name, location,
  RAN equipment).

Outputs

• Capacity Planning &#8210 The physical topology establishes the number of sites to be aggregated on each transport link.
• Transport Solution Definition &#8210 Physical Topology Design is used during Transport Solution Definition (details in section 4.2.7).

4.2.6 Capacity Planning

Once the physical topology is defined, the capacity of each transport link can be dimensioned to calculate the traffic that needs to be supported. Section 3.4 methodology can be applied in considering the total of RAN site traffic each link is aggregating.

Design Example

Table 19 displays capacity calculations for each transport link in the design example. All links comply with requirements established in Section 4.2.1.

Table 19 &#8210 Capacity Analysis in Design Example

Data presented in Table 19 were calculated using the Tx Network Capacity Forecast Widget.

Dependencies with other tasks

Capacity planning presents the following dependencies:

Prerequisites

• RAN HLD &#8210 Provide RAN solution information (site name, location, RAN equipment).

Outputs

• Transport Solution Definition &#8210 Capacity planning is used during Transport Solution Definition (details in Section 4.2.7).

4.2.7 Transport Solution Definition

The Transport Solution Definition helps determine the final transport technology to be implemented in a specific node. The operator must consider the following solution characteristics in performing the selection:

• Feasible Technologies &#8210 As discussed in Section 1, some technologies are preferable for implementing transport solution. An operator can rank available technologies in making the selection.
• Capacity Requirements &#8210 Forecasted capacity must be validated against the transport solution offer.
• Transport Node Attractiveness/Preferences &#8210 Transport nodes can be constrained by commercial criteria that vary their attractiveness for use.

Figure 25 is an example of a Transport Solution Definition Process that can be adapted by operators based on available technologies and commercial criteria.

Figure 25 &#8210 Transport solution definition process

To select Tx equipment selection, create a mapping among defined transport solution characteristics and transport standard configurations. Task results will determine the total number and type of transport equipment required in the deployment.

Design Example

Methodology presented in the above section is applied to define the transport solution definition in the design example. Figure 26 displays the selected transport technology for each node.

Figure 26 &#8210 Transport solution definition in design example

Analysis results are recorded in the Tx HLD Report Template.

Dependencies with other tasks

Transport Solution Definition presents the following dependencies:

Prerequisites

• RAN HLD &#8210 Provide RAN solution information (site name, location, RAN equipment).
• Service Level Requirements &#8210 Required to perform allocation of service levels to Transport Solution.
• Transport Solution Feasibility Analysis &#8210 Result of feasible technologies.
• Capacity Planning &#8210 Forecast of expected traffic.

Outputs

• Bill of Quantities &#8210 The transport network design determines the total number and type of equipment required in the deployment.

4.2.8 Tx Equipment Bill of Quantities (BOQ) Generation

A BOQ is a comprehensive registry of transport solutions to be implemented during the deployment phase. The following is a high-level list of information to include in the BOQ record:

• Equipment Type &#8210 General description of the required transport equipment to implement the Tx Network Design.
• Description &#8210 Provide a detailed description of each part to distinguish between similar parts and identify all more easily.
• Quantity &#8210 Record of the number of parts to be used in deployment phase; helps guide purchasing and activities.
• Unit of Measure &#8210 Measurement in which a part will be used or purchased. Consistency across similar part types is important; such information helps ensure the right quantities are procured and delivered to deployment teams.

4.2.8.1 BOQ Best Practices

Following are key requirements that BOQ management should address to optimize the process:

• Apply a centralized control of the BOQ.
• Implementation of secure access and accountability for internal and external teams.
• Maintain the updated BOQ document.

A NaaS operator can use the Tx HLD Report Template, which includes a section for the BOQ, as a base in creating their own version.

Design Example

Methodology from the above section defines the transport equipment BOQ. Table 20 shows the fiber optic equipment BOQ

Table 20 &#8210 Fiber Optic Equipment BOQ

Table 21 shows the microwave equipment BOQ

Table 21 &#8210 BoQ of microwave equipment

Table 22 details the satellite equipment BOQ

Table 22 &#8210 BOQ of satellite equipment.

4.3 NaaS operator End-to-End Process Definition

A NaaS operator can use the generic process design as a basis to develop its version according to its own limitations and constraints. A deeper analysis can be performed in adapting the generic process.

Analyzing the generic process design, activities can be classified into two groups:

• One-time activities &#8210 Tasks to be done one time only during the design process. They only require resource consumption at the beginning of the process. In the provided process, one-time activities are: Service Level Requirements Definition, Transport Standard Configurations Definition, and Design Tool Selection.
• Continuous activities &#8210 Tasks continuously performed during the design process and consuming the majority of resources. In the provided process, continuous activities are: Transport Solution Feasibility Analysis, Capacity Planning, Transport Solution Definition, and Tx Equipment BOQ Generation.

The approach presented in this section focuses on continuous activities, as they consume the majority of the resources. Following are some guidelines the NaaS operator should consider in customizing its own process:

• Preprocessing of one-time activities &#8210 One-time activities should be done at the beginning of the process to free up resources for later tasks.
• Parallelization and merging of activities &#8210 Some continuous activities can be merged to optimize process cycle times. For instance, Transport Solution Definition can be performed during Feasibility Analysis.

Its highly recommended that the NaaS operator execute a critical path analysis of its process version to further its optimization.

5 HLD Recommendation

Methodology to consolidate and generate a final HLD recommendation.

5.1.1 HLD Recommendation Format & Structure Generation

The main deliverable is the HLD recommendation. It contains the overall technical solution, basic design rules, and technologies and concepts required to describe the transport network. The HLD recommendation should contain the following aspects:

• Overview &#8210 High-level description summarizing the transport network design.
• Fundamentals &#8210 A brief description of fundamental concepts to serve as recommendation references.
• Transport Solution Design &#8210 Describe main scenarios to be implemented during the deployment phase.
• Tx Equipment BOQ &#8210 The primary input for TX equipment purchase order generation.

5.1.2 HLD Recommendation Generation

Generation of the HLD recommendation following the format and structure established. A NaaS operator can use the TX HLD Report Template as a reference to create its own version.

---

1. TX Network LLD

The Tx Network Low-level Design (LLD) module provides NaaS operators with background information and methodologies to elaborate a detailed design that includes the required information to implement the solution of the transport network. It provides methodologies and instructions to determine actual low-level design parameters necessary for the development of the Tx Network LLD.

Since the Tx Network LLD is required for the installation and commissioning of the transport equipment, it has a major impact on the transport network deployment. Therefore, a precise LLD is required to avoid delays in the deployment phase.

NaaS Operators span a range of size, geographies and network architectures. That is, there is not a one size fits all methodology. For this reason, a generic end-to-end process flow to perform the Tx Network LLD is presented along with proper guidelines to be tailored to match NaaS requirements methods for best in class LLDs.

The main output of the module is the Tx Network LLD Design which includes, among others, the Transport Datafills that integrate the required information to implement the transport solution and the Bill of Materials. In addition, this module will guide the NaaS Operator through the process of generating technically compliant LLD reports.

1.1 Module Objectives

This module will enable a NaaS Operator to stand-up, run, and manage a Tx Network LLD initiative. The specific objectives of this module are to:

1. Provide an information base and fundamentals to perform the tasks associated with Tx Network LLD.
2. Provide detailed how-to instruction on the key LLD engineering tasks.
3. Provide an overview of the end-to-end Tx Network LLD process with instructions for tailoring to specific NaaS environments.
4. Provide guidelines to develop a formal Tx Network LLD design.

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 drive the strategic decisions to forthcoming phases. Network Design is the first step into implementation strategy which is supported by Supply Chain Management.

The Tx Network LLD module is included within the Network Design Area and has direct relation with Tx Network. The generated output of this module will serve as a required input for the Civil & Power Design module.

Figure 1. Module Framework

Figure 2 presents the Tx Network LLD functional view where the main functional components are exhibited. Critical module inputs are further described and examined in Section 2.2. In addition, guidance and methodologies to execute the tasks included within each function are described in Section 3.

Figure 2. Module Functional View

The rest of the module is divided into four sections. Section 2 is a birds-eye view of the Tx network fundamentals involved on its design. Once fundamental knowledge is acquired, Section 3 focuses in showing a hands-on view of the tasks involved on the design. Section 4 organizes functional tasks on an end-to-end process flow that can be used as-is or be adapted by NaaS operators to match with their particular conditions. Finally, Section 5 illustrates how to integrate previous elements into a comprehensive Low-level Design (LLD) recommendation.

2 LLD Fundamentals

This section provides a general overview of the baseline concepts to develop a Tx Network Low-level Design.

2.1 Tx Network Environment

In a mobile environment, the Transport Network interconnects different networks including the RAN (Radio Access Network), data centers and external networks. Figure 3 displays the architecture of a typical transport network.

Figure 3. Typical Transport Network

Mobile networks are ubiquitous and support a mix of different types of traffic originating from and terminating to mobile devices. All this traffic must be conveyed between the mobile cellular base stations through the transport network up to the Mobile Core. For this reason, different aggregation levels exist on the transport network which for most of NaaS Operators can be classified as: last-mile and aggregation level.

The implementation of 4G Long-Term Evolution (LTE) imposes some requirements on transport networks such as more network capacity and latency reduction. These requirements are better served through terrestrial technologies (fiber optic and microwave). However, in rural areas, this becomes a challenge because satellite transport is usually the only feasible technology. For this reason, transport network infrastructure is an essential component of the NaaS Operator network and its design must be performed with optimal processes and techniques

2.2 Tx Network Low-level Design Inputs Description

This section analyzes the module input data and their respective candidate sources, which is presented in Table 1. Furthermore, the impact of module inputs on the design process is examined.

Input Required	Description	Candidate Source	Impact
Tx & IP Architecture	Includes the technologies and protocols to be considered on the design	Tx & IP Architecture Module	– Establishes the available transport technologies to be designed and their respective design guidelines. – Defines the transport protocols to be configured on the equipment.
Tx HLD Design	Describes the High-level Tx solution (transport technology, transport nodes)	Tx HLD Module	– The type and total number of Tx Links to be designed determines the selection of the tool to perform the Tx Link Design.
RAN HLD Design	Describes the parameters related to RAN solution (site location, RAN equipment, covered population)	RAN HLD Module	– The RAN equipment model has a direct impact on the Model Site Catalogue generation – The IP Addressing is directly related to the RAN equipment.
Transport Provider Network Data	Contains specific information regarding Tx nodes (name, IP addresses, Port, S-VLAN)	Transport Provided Network Database	– The specific data of the Transport Node is used during the Datafill generation process.
Tx Equipment Technical Data	Contains a List of candidate Tx equipment for all involved vendors.	Tx Equipment Vendor	– Establishes the Transport (Transmission and IP) Equipment to be evaluated. This has a direct impact on Transport Equipment Selection and Model Site Catalogue generation.
General IP Address Distribution	Defines the general segments for transport equipment and services.	Tx & IP Architecture Module	– The General IP Address Distribution is used on IP Planning and Tx Network Resources Allocation steps.

Table 1. Tx LLD Module inputs analysis

2.3 Tx Link Design

Transport links are subject to multiple phenomena (e.g. meteorological) that have a direct impact on the link performance. Therefore, an accurate Tx Link Design must be performed to ensure that the transport link will behave within the performance thresholds under different conditions.

This process must be performed individually for each transport link according to the engineering guidelines from Transport & IP Architecture. Furthermore, this process uses specialized link design tools (See Section 4.2.3 for further details) that consider additional parameters (e.g. weather conditions) and their impact on the transport link performance. Each transport technology has its particular parameters that must be calculated in order to maintain the transport link operating in optimal conditions.

Tx Link Design for Fiber and Microwave technologies is perform within this module to validate the site feasibility, and confirm physical and logical parameters. In, contrast, for Satellite technology, the most common implementation scenario is to use a Satellite Service provider and this validation is determined by the satellite footprint. Furthermore, the detailed Satellite Link Design is performed by the Satellite Service provider and is included as part of the equipment delivery.

2.4 Network Design

The most common implementation scenario implemented in the transport network is displayed in Figure 4:

Figure 4. Transport network scenario based on Carrier Ethernet with L3VPNs

In order to support the scenario presented in Figure 5, NaaS operators must define the different protocols and technologies to be used at different layers.

Figure 5. 3GPP Logical Interfaces Protocol Stack

The definition of the stack protocols to be implemented is an input from the Transport & IP Architecture Module. The scope of the LLD process is to define the main configurations parameters for each of them.

2.5 IP Planning

In order to simplify the IP address management of the overall network, support several technologies and be able to perform an efficient troubleshooting, an IP Address Distribution Plan must be defined. An IP Address Distribution Plan is a document developed by the NaaS Operator that displays how the universe of available IP addresses will be distributed in a way that supports the required services. This plan should satisfy the following conditions:

• It should be simple and follow logical rules.
• It should be scalable up to the forecasted number of eNodeBs and network elements to be deployed in the network considering an additional margin for future expansions.
• It should allow simple routing configurations and efficient route summarization.

Section 3.3 details the methodology to generate the Detailed IP Distribution Plan and the IP Address Allocation process using IPv4 version. A similar process can be performed when using IPv6 version considering that 16 octets are available. A broader view on the fundamentals of this process can be found on the Primer on IP Planning Principles.

3 Functions & Methodologies

Methodologies to perform critical tasks/subtasks involved in the Tx Network Low-level design process.

3.1 Fiber Optic Link Design

This section provides general methodologies to perform the Passive Fiber Optic Link Design. The inclusion of active elements in the fiber path (e.g. amplifiers) is out of the scope of this module.

3.1.1 Fiber Optic Link Design Process

A Fiber Optic Link Design must be developed for each of the fiber paths defined by the Tx High-Level Design in order to complete the Tx information. The principal analysis is the Fiber Optic Link Budget, which is the verification of a fiber optic link operating characteristics. This encompasses items such as routing, circuit length, fiber type, number of connectors and splices and wavelengths of operation.

Although the specific steps can vary depending on the selected Fiber Optic Link Design Tool, the general steps to perform the Fiber Optic Link Budget are presented in the following subsections.

Step 1. Load Fiber Optic Equipment Characteristics

The information regarding the Fiber Optic Equipment that can be included depends on the selected tool characteristics. However, the following elements are the most relevant in the Fiber Optic Link Design:

• Transmission Power: The optical transmission power is the signal level transmitted to the fiber optic by the transport equipment.
• Receiver Sensitivity: Minimum signal power level in the receiver, in which decoding errors begin to occur.
• Saturation in Reception: Maximum signal power level tolerated by the receiver, which begins to produce reception errors, or the detector can be damaged.
• Wavelength: Wavelength used in the transmission, which is mainly defined by the selected interface. The most common wavelengths actually used in fiber optics are 1310 nm, and 1550 nm.

Figure 6 shows an example of the configuration of the Fiber Optic Equipment Characteristics in the Fiber Optic Link Design Tool.

Figure 6. Example of Fiber Optic Equipment Characteristics in Fiber Optic Link Design Tool.

Step 2. Calculate the Losses in the Fiber Path

The information regarding multiple losses in the fiber path that can be included depends on the selected tool. However, the following elements are the most relevant in the Fiber Optic Link Design:

• Fiber Loss: This value varies according to the type of available fiber (e.g. monomode, multimode) and in some extreme weather scenarios, the type of fiber laying (e.g. aerial, buried). This value is commonly known as Fiber Optic Cable Grade and is represented in [dB/km] units.
• Insertion Loss: Every passive component (e.g. connectors, attenuators) introduces a loss of power to the optical signal that passes through it.
• Splice Loss: Fusion splicing is a technique to join two fibers ends. Optical power loss at the splicing point is known as splice loss.

In absence of specific values, the use of conservative defaults is advisable, as noted in Table 2:

Wavelength	Fiber Loss / km	Connector Loss	Splice Loss
1310 nm	0.35 dB	0.75 dB	0.3 dB
1550 nm	0.22 dB	0.75 dB	0.3 dB

Table 2. Default values for Link Budget Calculations

The total loss in the optical link is thus computed, using a typical safety margin or 3dB, as:

(Eq. 1)

Figure 7 shows an example of the configuration of the Fiber Losses in the Fiber Optic Link Design Tool.

Figure 7. Example of Fiber Losses in Fiber Optic Link Design Tool.

Step 3. Fiber Optic Link Budget Generation.

A link budget is a calculation that considers the transmitted power with all the gains and losses in the Tx link in order to estimate the strength of the received signal. This calculation provides, for a link Loss Budget and a given dynamic range (the difference between the transmitter power and the receiver sensitivity) the adjustment margin for that configuration as:

(Eq. 2)

Per design, the power margin should be greater than 3dB. The Fiber Optic Link budget is calculated by using the options provided by the selected tool.

Step 4. Fiber Optic Link Requirements Validation

In order to validate the Fiber Optic link design, the Link Budget must be fulfilled (i.e. it must confirm that the power margin is greater than 3dB).

In case the Link Budget is not fulfilled, a change in the link parameters can be modified (e.g. change the transmission power) as long as the link still complies with design directives.

3.1.2 Fiber Optic Link Design Report

After generating the Fiber Optic Link Design, a report that contains information of the designed link must be constructed including the following information:

• Nodes involved: Origin node, destination node (name, coordinates)
• FO Link Parameters: optical link distance, type of fiber, connectors characteristics.
• FO Link Budget Result: Power Margin, Throughput (just in some tools).

3.2 MW Link Design

This section provides general methodologies to perform the Tx Link Design for each available MW Link identified in the High-Level Design based on the established requirements.

3.2.1 MW Link Design Process

Although the specific steps can vary depending on the selected Microwave Link Design Tool, the general steps to perform the Microwave Link Design are presented in the following subsections. It is worth to note that the illustrative images along the process belong to Pathloss Tool.

Step 1. Digital Terrain Databases Selection

In general, most propagation predictions are based on detailed topographical information. The topographical information is provided by Digital Terrain Elevation (DTE) Models that is composed by digital terrain topographical databases and represented in the form of digital terrain maps. These models provide accurate information that will be used to evaluate the path clearance and the potential loss associated with diffraction.

Depending on the selected tool to perform the design operations, these DTEs models can be included as part of the tool. If they are not included, some DTEs are available as open source data for many places in the world (e.g Google Maps Elevation API).

Figure 8 shows an example of the configuration of the Digital Terrain Database in the MW link Design Tool.

Figure 8. Example of Digital Terrain Database Configuration on MW Link Design Tool.

Step 2. Load Site Information

The site information must be introduced to the tool, including:

• Geographical information: Geographical coordinates.
• Infrastructure information: Tower height of each of the sites. Typically, during the analysis it is considered a height of 3m below the total Tower Height as a margin to include the space requirement to implement the MW antennas.

Figure 9 shows an example of the configuration of the Site Information in the MW link Design Tool.

Figure 9. Example of Site Information Configuration on MW Link Design Tool.

Step 3. Load MW Equipment Specifications

The information regarding the MW equipment that can be included depends on the selected tool features. However, the following elements are the most relevant in the MW Link Design:

• Radio Equipment Specifications (e.g. Transmission Power, Receiver sensitivity, Supported Bandwidth, Supported Modulation Schemes).
• Frequency Band: The frequency band is an input defined in the Tx High-level Design.
• Antenna Specifications (e.g. antenna diameter, antenna gain)

Furthermore, depending on the tool, this information may be entered via a user interface or equipment files (e.g. MRS files in Pathloss). Figure 10 shows an example of the configuration of the MW Equipment in the MW link Design Tool.

Figure 10. Example of MW Equipment Configuration on MW Link Design Tool.

Step 4. Additional MW Link Model Characteristics Setting

Depending on the selected tool features, additional Microwave Link Model Characteristics can be configured, such as:

• Rain Model. The attenuation caused by rainfall along the link path may be calculated using a Precipitation Model developed specific for the geographic zone. This source of additional attenuation has a bigger impact in higher frequencies (> about 10 GHz).

Step 5. MW Link Budget and Profile Generation

Generate the Microwave Link budget and profile using the options provided by the selected tool. Figure 11 displays an example of a MW Link Profile.

Figure 11. MW Profile Example

Step 6. MW Link Requirements Validation

All the MW links must comply with the general requirements established in the Tx & IP Architecture module as well as with the specific MW link parameters (e.g. availability, throughput). In case one of the requirements is not fulfilled change in the link parameters can be applied as long as the link still complies with the design directives.

For instance, if the received signal strength do not surpass the radio sensitivity, a lower modulation scheme can be selected. This change, inherently increase the radio sensitivity, allowing to receive weaker signals. However, a change in the modulation scheme may impact in the link throughput.

Furthermore, in case the link is not feasible due to lack of Line of Sight (e.g. no Line of Sight due to an insuperable obstacle), the methodology presented in Section 3.2 of Tx HLD Module must be applied to re-design the MW Link.

3.2.2 Microwave Link Design Report

After generating the MW Link Design, a report that contains information of the designed link must be constructed including the following information:

• Nodes involved: Origin node, destination node (name, coordinates).
• MW profile link: An image that validates the status of the actual link LoS.
• MW link parameters: link distance, transmission frequency, antenna heights, antenna azimuths.
• MW Link Budget Results: Availability, Received Signal Strength, Fading Margin, Throughput (just in some tools).

Figure 12 displays an example of the Microwave Link Design Report generated by the Pathloss tool.

Figure 12. MW Link Report Example

3.3 IP Address Subnetting Process

IP Subnetting is the process used to partition a network address space into smaller segments (e.g. divide one segment /8 into 16 segments /12). This process is important in the context of the NaaS operator because it allows to logically divide the network traffic type for different uses (e.g. separate the traffic of the eNodeBs from the Core elements). Furthermore, IP Subnetting allows to use different masks for each subnet, and thereby use address space efficiently. Finally, subnetted networks are much easier to manage and troubleshoot.

In order to illustrate the process, a practical Example is followed along each of the processes steps. In this particular example, the process to divide the segment 10.0.0.0/16 in appropriate network subnets that can allocate the number of IP addresses in Table 3 is presented.

Subnet	Number of required IP addresses
Subnet 1	20,000
Subnet 2	10,000
Subnet 3	15,000

Table 3. IP Address Requirements in Subnetting Example

Step 1. Calculate the required block sizes

In order to calculate the length mask (i.e. block size) required to support the number of required IP addresses, the following formula is used:

(Eq. 3)

Using Eq. 3 in the example, the results presented in Table 4 are obtained. In practice, the assign block size must be greater than the actual requirement. A Web-based IP address Calculator tool can be used to simplify the planning on network subnets.

Subnet	Required Mask Length	Mask Notation	Block Size
Subnet 1	/17	255.255.128.0	32,768
Subnet 2	/18	255.255.192.0	16,384
Subnet 3	/18	255.255.192.0	16,384

Table 4. Block size Requirements in Subnetting Example

Step 2. Subnet Sorting

The next step is to sort the resulting network segments based on the block size in descending order. In this way, the IP address space is used efficiently. In some cases, it is possible that the sum of the calculated block for the required subnets, does not make complete use of the available IP segment. These additional IP addresses can be reserved for future expansion.

It is important to note that the subnetting definition process must consider future additional network elements. Further changes in the existing subnets definition are difficult and can result in the modification of the IP Distribution Plan. It is recommended to be conservative in the calculation of the required block sizes to reduce the likelihood of having to re-work on the IP subnetting process.

Step 3. Subnets Assignment

Finally, assign the first resulting network segment to the first available segment from the original segment and continue following the ordering. The Example Result is displayed in Table 5.

Subnet	Required Mask Length
Subnet 1	10.0.0.0 / 17
Subnet 2	10.0.128.0 / 18
Subnet 3	10.0.192.0 / 18

Table 5. IP Subnetting Result in Subnetting Example

Additionally, Naas operators can use the High Level IP Distribution Plan Widget as support in the generation of the IP Distribution Plan.

3.4 IP Address Allocation

IP Address Management is the collection of procedures for organizing, tracking and adjusting the information related to the IP addressing space. It supports the network designers and operators to guarantee that the IP addresses remain updated. Furthermore, given the possible thousands of IP addresses in the network, this process also helps the operations team when debugging / troubleshooting issues.

Although the specific steps can vary depending on the selected IP Address Management Tool, the general steps to perform the IP Address Allocation are presented in the following subsections. It is worth to note that the illustrative images along the process belong to the free phpIPAM Tool.

Step 1. Define Network Segments

Introduce the main network segments included in the General IP Distribution Plan in descending order of block size. Then introduce all the network segments included in the Detailed IP Distribution Plan.

Step 2. Allocate IP Network Addresses

To allocate a specific IP address (e.g. for eNodeB services or transport equipment), identify the segment that corresponds to the scenario in the Detailed IP Distribution Plan.

Once the specific segment is identified, the first available IP address within the segment is selected, and the specific information is introduced to describe the segment purpose. Following the basic information that must be registered for all the IP addresses within the IPAM Tool:

• Subnet: Specific subnet that is used, specifying the block size.
• Description: Self-explanatory description of the network segment purpose.
• VLAN: Assigned VLAN number (when required).
• Site ID: The Site ID of the RAN site where the transport link will be deployed.

Figure 13 displays an example of the IP Allocation in the phpIPAM tool.

Figure 13. Subnet Allocation Example

4 E2E Process Flow

This section presents a generic yet customizable end-to-end process flow to perform the transport design for the transport network.

4.1 End-to-end Process Overview

The generic end-to-end (E2E) process flow displayed in Figure 14 orchestrates general tasks to perform the Transport Network LLD in a logical and well-structured sequence.

Figure 14. Generic E2E Process Flow.

Details and customization options of each step are reviewed in the following sections. In addition, a Tx LLD Process Flow Designer is provided as part of the Methods of Engagement.

4.2 Step-by-step Analysis

This section presents an examination of each of the steps involved in the Low-level Tx Design process to identify, isolate and describe the range of implementation options on the path towards customization based on NaaS operator requirements and constraints.

In order to demonstrate a practical exercise to implement the process design flow, a Design Example is followed along each of the process steps.

Design Example

In this particular example, the process to generate the LLD Design for the scenario in Figure 15 is presented. It must be noted that this is the continuation of the Example presented in the Tx HLD Design.

Figure 15. Design Example Scenario.

The scenario is composed of eight RAN sites that will be analyzed to perform the Transport LLD Design. The example considers two geographical regions (North and South), where all the RAN sites presented are located in the North Region.

The distribution of transport technologies is the following: Four nodes use Fiber Optic, three nodes use Microwave and one site uses Satellite Link. The details on the transport technologies selection can be found in the Tx HLD Module.

The General IP Distribution Plan is presented in Table 6. The General IP Distribution Plan is presented in Table 6, and it describes the general segments defined by each of the different network elements. The details on the General IP Distribution Plan generation can be found in the Tx & IP Architecture Module.

Table 6. General IP Plan Distribution for the Example Scenario.

The VLAN Definition to be used to separate the traffic for different planes is presented in the Table 7. The details on the VLAN Definition can be found in the Tx & IP Architecture Module.

Table 7. VLAN Definition in Design Example.

Whereas this Design Example only focuses on the eight RAN sites presented in Figure 15, the total number of expected RAN sites and Tx links to be deployed are presented in Table 8. These numbers already consider the future growth of the network.

Table 8. Total number of elements for the Example Scenario

Even if the number of required IP addresses for the number of elements does not cover in totality the corresponding IP segment, the methodology presented in Section 3.3 must be performed to enhance the network management and support future expansions.

4.2.1 Transport Equipment Selection

NaaS operators must perform the selection of the Tx Equipment from multiple vendor alternatives. The complete process to select the Tx Equipment is included within the Procurement Module (RFx Process Module). This section focuses on the technical aspects to perform the evaluation of transport equipment from different vendors.

From the technical perspective, Table 9 displays the typical requirements that the transport equipment must satisfy which must be defined according to the required network segment (e.g., last-mile or aggregation link implementation scenario).

	Evaluated Characteristics
Supported Protocols	Support for the protocols defined in Tx & IP Architecture Module
Availability	Reliability and uptime
	Time-to-Repair
	Time-to-Deploy
Performance	Throughput performance under normal and stressing conditions
	Maximum number of active connections
Dimensions	Standard dimensions compliance
Power Requirements	Type of energy required (AD/DC) and power consumption profile
Security	Implemented security mechanisms
Cost	Cost of the equipment.

Table 9. Typical specifications to be evaluated in transport equipment.

>

The decision to select the Tx Equipment is also affected by the financial constraints of the project. The final selection of the Tx Equipment is performed during the RFx process and in conjunction with the Procurement Team.

Design Example

In the Design Example, there are two Tx equipment provided by different vendors (Vendor A and Vendor B) that are evaluated for selection. The characteristics of the Tx equipment are shown in Table 10.

Table 10. Tx Equipment Specification for Design Example.

From Table 10, it can be seen that both options comply with the required protocol stack and security features; they also have a similar value of the availability figure and both require a standardized unit rack for installation. Vendor A offers more system throughput, but it also has more power requirements and the price is considerably higher.

Therefore, Vendor B is the selected option in the Design Example since it complies with the required protocol stack, security features, system throughput (it fully complies with the architecture requirement). Furthermore, the power requirements are low (a critical aspect in rural environments) and the price is the most accessible.

>

4.2.2 Model Site Catalogue Definition

The aim of Model Site Catalogue Definition is to standardize and document the possible Tx Site equipment configurations to be implemented. By doing this, the design options are constrained which simplifies the overall process.

4.2.2.1 Model Site Granularity Definition

In order to create the catalogue, the granularity to be used must be defined. Granularity is the level of detail present in the scenarios included in the catalogue and will dictate the different variations to be included in the catalogue. The possible alternatives to be used to establish the granularity are:

• Transport Technologies: Fiber Optic, Microwave, Satellite.
• RAN Equipment: Macro Cell, Small Cell.
• Tx Equipment Vendor.
• Transport Vendor.

NaaS operator should select the appropriate level of granularity that better suits its requirements. However, it is highly recommended that a high level of granularity is chosen in order to minimize the number of possible alternatives and simplify the design process.

4.2.2.2 Model Site Catalogue Generation

Based on selected granularity, an identification of all possible scenarios is performed. Then, a high-level description of each scenario solution must be described. Following, a list of characteristics that must be identified for each scenario:

• Network elements specifications: (physical specifications, power requirements, )
• Site topology: Illustrative diagram that reflects the topology to be implemented on site.
• Interconnection schemes (Interconnection matrix, interface description, cable type)
• Configuration features. (Protocols, VLAN configuration)

Figure 16 displays a brief example of the Model Site Catalogue Generation considering Available Transport Technologies and Tx Equipment Vendor as granularity. NaaS operators can take this example to customize its own catalogue generation process.

Figure 16. Example of Model Site Catalogue Generation

The NaaS Operator can use the Model Site Catalogue Template as a base to create its own version.

Design Example

In order to generate the Model Site Catalog Standard Configurations for the transport equipment on the Design Example, the following scenarios are identified:

Table 11. Model Site Catalogue Scenarios for Design Example.

Figure 17 illustrates the site topology of the scenario: Microwave Macro Cell.

Figure 17. Site Topology Scenario for Design Example

4.2.3 Design Tool Selection

This section provides general criteria for the selection of the most suitable set of tools and level of automation to be implemented during the design phase.

In order to select the appropriate design tools to perform the Transport LLD, a classification of available tools is required. Table 12 displays a generic tool type classification that will serve as a base to perform the selection.

Tool Type	Implementation type	Type of License	Automation	Customization	Support Type
Tier 1	Commercial tool	License cost	High/Medium: Batch mode usually based on scripts	High: Customization options provided by developer	Dedicated support (extra charges can apply)
Tier 2	Open-source code	Free	High/Medium: Batch mode usually based on scripts	Medium/High: Customization options implemented by users	Wiki + Community Groups
Tier 3	Web-based, APIs	Free (sometimes usage limited per day)	Low: Usually, one by one approach	Low: Usually only proprietary parameters are defined	Limited support
Tier 4	Home-grown (e.g Spreadsheet)	Free	Medium: Automation options requires high cycle times	Medium: Customization options requires high cycle times	No support

Table 12. Tool Type Classification

>

For each type of design tool consider in the design process, there are multiple available options that are examined in the following subsections.

4.2.3.1 Tool Selection Process

The selection process must consider different aspects regarding the scope of the project and the characteristics of the NaaS operator, following a list of examples:

• Number of elements to design: Each design element implies an operation that a design tool must perform (e.g. one Fiber Link Design, one MW Link) which is directly related to the number of transport links. The number of potential design elements has a direct repercussion on the level of automation to be implemented.
• Available budget for tools from the Commercial Area.
• Team Skill Sets: Abilities for Coding, Linux/Unix, Database Management, etc.

Figure 18 displays a generic process to perform the Tool Selection. NaaS operators can use this process as a base to define its own version according to operators priorities.

Figure 18. Tool Selection Process

4.2.3.2 Fiber Link Design Tool Selection

The tools utilized to perform the Fiber Link Design are classified in Table 13 according to the parameters defined.

Tool Type	Name	Description
Tier 1	VPItransmissionMaker – VPIphotonics	Fiber Link Design Tool based on graphical interface, a robust simulation scheduler and realistic simulation models
Tier 3	Optical Power Budget Calculator – Evert	Optical Power Budget Calculator available through a web-based interface.

Table 13. Tool Classification for Fiber Optic Link Design

>

Following the methodology presented in Section 4.2.3.1, the NaaS operator can perform the selection of the Fiber Link Design Tool.

Design Example

The tool Optical Power Budget Calculator – Evert will be used as GIS Tool to perform the Fiber Path Design in the Design Example.

>

4.2.3.3 Microwave Link Design Selection

The tools utilized to perform the Microwave Link Design are classified in Table 14 according to the parameters defined.

Tool Type	Name	Description
Tier 1	Pathloss	The Pathloss program is a comprehensive Microwave Radio Link Design and Planning Software for radio links operating in the frequency range from 30 MHz to 100 GHz.
Tier 3	Link Budget Calculator – Radwin	MW Link Design Tool available through a web-based interface. It only uses proprietary equipment.

Table 14. Tool Classification for Microwave Link Design

>

Following the methodology presented in Section 4.2.3.1, the NaaS operator can perform the selection of the Microwave Link Design Tool.

Design Example

The tool Pathloss will be used as a Microwave Link Design Tool to perform the link budget generation in the Design Example.

>

4.2.3.4 IP Address Management

The tools utilized as IP Address Management are classified in Table 15 according to the parameters defined.

Tool Type	Name	Description
Tier 1	IP Address Manager – Solarwinds	IPAM Tools with integrated DHCP, DNS, and IP address management.
Tier 2	phpIPAM	Open-source web IPAM Tool. It is php-based application with MySQL database backend, using jQuery libraries, ajax and HTML5/CSS3 features.
Tier 4	Excel-based IPAM	Home-grown IPAM bases on Excel spreadsheets.

Table 15. Tool Classification for IP Address Management

>

Following the methodology presented in Section 4.2.3.1, the NaaS operator can perform the selection of the IP Address Management Tool.

Design Example

The tool phpIPAM will be used as an IP Address Management Tool in the Design Example.

>

4.2.4 Network Design

The configuration process for each network protocol varies depending on the equipment vendor. However, it is important that all network elements have its parameters set with the same guidelines to avoid inconsistencies that may potentially cause service degradation.

The different characteristics that need to be defined for each layer are examined in the following subsections.

4.2.4.1 L1 / Physical Interfaces

This layer is concerned with the transmission and reception of the unstructured raw bit stream over a physical medium. Therefore, it defines the characteristics of the physical interfaces that will be consider in the deployment phase.

It is highly recommended that all the transport equipment support transceiver modules based on small form-factor pluggable (SFP). In this way, the interface port can be equipped with any suitable type of transceiver as needed.

Ethernet supports both electrical (twisted-pair cable) and optical fiber interfaces for physical connection. The electrical interfaces are recommended for connections between co-located equipment, this means equipment that are physically on the same Location (e.g in the same site, equipment room). In this case, the maximum distance allowed for electric interfaces is 100m.

Table 16 displays the typical selection for the physical interfaces to be implemented in transport networks:

Interface Capacity	Transceiver Module	Media	Interface Type	Distance Range
1G	SPF	Electrical	1000BASE-T	100m
		Optical	1000BASE -LX10	10km
10G		Electrical	10GBASE-T	75m (100m with cable Cat6a)
		Optical	10GBASE -LR	10km

Table 16. Typical values for physical interfaces.

>

4.2.4.2 L2 / Data Link Layer

For the L2 Layer, the majority of LTE mobile equipment utilize Ethernet interfaces for transport, therefore, Ethernet based services are most suitable to be implemented in the transport network.

Table 17 displays the basic configuration information to implement the Ethernet protocol in the network.

Parameter	Description	Criticality	Comments
Maximum transmission unit (MTU)	Largest size packet that can be processed by nodes within the transport network.	Mandatory	Configure the MTU definition from Architecture module consistently in all network equipment
Group Member	Group of interfaces in LAG	Optional	Only in LAG configuration.
Description	Includes information regarding the use of the interface	Optional	Must contain self-explanatory information

Table 17. Ethernet Protocol Basic Configuration

>

Finally, Table 18 displays the typical configuration for the VLAN parameters.

Plane	VLAN Tag
Control Plane (CP)	101
User Plane (UP)	102
Management (OAM)	103
Synchronization (SYN)	104

Table 18. Typical VLAN configuration

>

4.2.4.3 L3 / Routing Layer

The L3 Routing layer controls the physical path the data should take based on network conditions and other factors. Figure 19 displays a typical implementation for L3 Routing protocols. More detail regarding the selection of these protocols can be found in the Transport & IP Architecture Module.

Figure 19. Typical L3 Routing Protocol Implementation

The following subsections examine the basic configuration parameters to implement the displayed network routing mechanisms. However, the required transport protocols are defined in the Transport & IP Architecture Module.

Static Routing

Static routes define explicit paths between two routers and cannot be automatically updated. Its configuration is simple as for each static route it is only needed to specify the egress interface and optionally, the next-hop address.

The static route is only recommended to be used on endpoints where a single connection is available. For instance, in a scenario where only one Cell Site Router is deployed, the eNodeB can only send the traffic to this element.

OSPF Protocol

The Open Shortest Path First (OSPF) protocol is a link-state routing protocol that uses a hierarchical routing model where a centralized routing domain is defined within an autonomous system. OSPF can be used in the aggregation domain when more complex topologies are presented.

Table 19 displays the basic configuration information to implement the OSPF protocol in the network.

Parameter	Description	Criticality	Comments
Process ID	Used to differentiate multiple OSPF processes on the same router.	Mandatory	Any number from 1 to 65,535
Interface	Specify the interfaces included in the OSPF process.	Mandatory	According to device configuration (See Model Catalogue)
Area	Limit the scope of route information distribution.	Mandatory	The default area is 0.0.0.0
Network	Identify which device interface will be included within the OSPF process.	Mandatory	Should be configured based on the IP Distribution Plan for each network device
Retransmit interval	Specifies the interval between link-state advertisement (LSA) retransmissions for adjacencies belonging to an OSPF interface	Optional	5 sec
Authentication Method	Used to protect the router from unauthorized OSPF peering connection.	Mandatory	Security will be use MD5 password.

Table 19. OSPF Protocol Basic Configuration

>

BGP Protocol

The Border Gateway Protocol (BGP) is a distance vector that is used to advertise the route prefixes outside the organizational boundary without revealing the internal routing characteristics. BGP is commonly used to exchange prefixes assigned to mobile subscribers to the providers Internet peer.

Table 20 displays the basic configuration information to implement the BGP protocol in the network.

Parameter	Description	Criticality	Comments
AS Number	Identified the AS domain.	Mandatory	Deploy BGP under Private AS number 65535
Router ID	Used to identify BGP-speaking peers.	Mandatory	Set the BGP router ID with loopback 0.
Neighbor	Configure the relationships between BGP speakers.	Mandatory	Should be configured based on the IP Distribution Plan for each network device
Authentication Method	Protect the router from unauthorized connection.	Mandatory	Security MD5 authentication will be implemented in all sessions.

Table 20. BGP Protocol Basic Configuration

>

4.2.4.4 L4 / Transport Layer

The most commonly used transport layer protocols are:

• User Datagram Protocol (UDP)
• Stream Control Transmission Protocol (SCTP)
• Transmission Control Protocol (TCP)

These protocols do not need additional configuration to be used.

Design Example

The Basic Configuration presented for each of the network layers is considered in the Design Example.

In particular, for Layer 3 protocols, the configuration used in the Design Example is presented in Table 21

Table 21. L3 Protocol Configuration in Design Example.

>

4.2.5 IP Planning

This section describes the guidelines to perform the calculation of the required IP resources to implement the Transport LLD Design and generate the Detailed IP Distribution Plan. The General IP Distribution Plan is an input provided by the Tx & IP Architecture Module.

The Detailed IP Distribution Plan should cover the anticipated growth in the number of network elements in order to avoid frequent changes. Furthermore, it should allow summarizing routes in the network. This optimizes routing performance and avoids a large memory consumption in the routers.

Step 1. Scenarios Identification

For each of the main segments in the General IP Distribution Plan, an identification of all of the possible segmentation criteria must be performed. In order to maintain the IP distribution Plan simple, it is recommended to only consider the essential scenarios.

Following, a list of characteristics that may be considered to generate the possible scenarios:

• eNodeB:
• Equipment Vendor: eNodeB Vendor.
• RAN Type: Macrocell, SmallCell
• Tx Type: Terrestrial, Satellite
• Service Type: User Plane, Control Plane, Management, Synchronization.
• Router:
• Equipment Vendor: Routers Vendor.
• Tx Provider: Transport Provider (In case 3^rd party is used).
• MW Equipment:
• Equipment Vendor: Microwave Radio Vendor.
• Type of radio band: Unlicensed / Licensed.
• Tx Provider: Transport Provider (In case 3^rd party is used).

Step 2. IP Address Calculation

Additionally, for each of the identified scenarios, a calculation of the required IP addresses must be performed. The total number of IP addresses required to deploy the overall solution can be calculated by multiplying the total number of elements by the number of IPs required for each element:

(Eq. 4)

Table 22 displays the typical IP Ranges and number of ranges required for the Tx network elements.

Type of element	IP Subnet	Number of usable IP Addresses	Number of required blocks
eNodeB – User Plane	/30	2	1 per eNodeB
eNodeB – Control Plane	/30	2
eNodeB – Sync	/30	2
eNodeB – Management	/30	2
Router Loopback	/32	2	2 per Router
MW O&M	/29	6	1 per MW Link

Table 22. Typical IP Ranges for Tx Elements

>

Step 3. IP Subnetting

Finally, each of the main network segments must be partitioned using the methodology presented in Section 3.3 to generate the Detailed IP Distribution Plan. This plan considers all the identified scenarios and the required number of IP addresses.

Design Example

The Design Example follows the methodology presented in this section.

Step 1 & 2. Scenarios Identification & IP Address Calculation

For the eNodeB segment, a further subnetting is performed to consider the following elements: RAN Type (Macrocell, SmallCell) and Service Type (User Plane, Control Plane, Management, Synchronization). Table 23 displays the identified scenarios along with the total number of required IP addresses for the eNodeB segment. The typical IP Ranges in Table 22 and Eq. 4 were used to calculate the total number of IP addresses.

Table 23. IP Requirements for eNodeB Segment in Design Example

For the Router and MW O&M segments, no further subnetting is required. Table 24 displays the identified scenarios along with the total number of required IP addresses for each of these segments. The typical IP Ranges in Table 22 were used to calculate the total number of IP addresses.

Table 24. IP Requirements for Router and MW O&M segments in Design Example

Step 3. IP Subnetting

Table 25 displays the Detailed IP Distribution Plan for the eNodeB segment obtained by applying the methodology in Section 3.3.

Table 25. Detailed IP Distribution Plan for eNodeB Segment in Design Example

Table 22 displays the Detailed IP Distribution Plan for the Router and MW O&M segments obtained by applying the methodology in Section 3.3.

Table 26. Detailed IP Distribution Plan for Router and MW O&M segments in Design Example

>

4.2.6 Site Tx Equipment Definition

To simplify the design process, the Site Tx Equipment Definition is performed based on the scenarios generated in the Tx Model Site Catalog. For each site, the transport site data is mapped to one of the scenarios in the Model Site Catalog.

Design Example

Table 27 displays the Tx Equipment Definition for the Design Example using the Model Sites defined in Table 11.

Table 27. Tx Equipment Definition for Design Example

>

4.2.7 Tx Network Resources Allocation

This section describes the methodology to perform the IP Address allocations tasks for LTE eNodeB planes and transport equipment and 4G services.

The IP addresses allocated to the network elements must be unique, this means that the same address must not be used for another element, even if the elements are in isolated areas.

IP Address Allocation

In the eNodeB, IP addresses need to be assigned for the user, control, management and synchronization plane. These elements must follow the Detailed IP Distribution Plan.

The IP address allocation process must be performed following the methodology presented in Section 3.4 and considering the typical IP Ranges presented in Table 22.

Tx Equipment Resources Allocation

Besides IP addresses, the transport equipment requires the following information to completely define the network resources:

• Physical Port: Connector or outlet on networking device where the media is connected to an end device or another networking device. In some cases, the connections among equipment are done using an optical distribution frame (ODF). However, the information of the physical port must be included for documentation purposes.

Furthermore, in case a 3^rd party is used, the following information is required:

• 3^rd Party Tx equipment information: Equipment Name and Physical port that will deliver the traffic.
• Service VLAN: In some scenarios, the Transport Provider provides a Service VLAN (S-VLAN) that is used to transport the traffic over the 3^rd party network.

Design Example

The allocation of the IP addresses for the eNodeB planes is done following the methodology presented in Section 3.3 using the Detailed IP Distribution Plan defined in Table 25. Table 28 displays the final IP address allocation for eNodeBs planes.

Table 28. eNodeB IP Address and VLAN Allocation for Design Example

All the /30 segments in Table 28 comply with the following definition. The segment 10.0.16.0/30 is taken as example for better explanation:

• The first IP address (i.e. 10.0.16.0) is used as the subnet address.
• The second IP address (i.e. 10.0.16.1) is used for the Gateway Router address.
• The third IP address (i.e. 10.0.16.2) is used for the Service (e.g. UP, CP, Sync, Management) address.
• The fourth IP address (i.e. 10.0.16.3) is used as the broadcast address.

Similarly, Table 29 displays the IP address allocation for Routers & MW Radios.

Table 29. Tx Equipment IP Address Allocation for Design Example

>

4.2.8 Tx Link Design

The Tx Link Design tasks for the available transport technologies must be performed following the methodologies presented in Section 3.

The level of automation implemented depends on the characteristics of the selected tools to perform the design tasks. Furthermore, the analysis can be done in batch mode or in a one by one fashion.

Finally, it is important to maintain a repository with the reports for all the transport links analyzed that can be accessed for all the team members, in particular, the deployment team.

4.2.8.1 Fiber Optic Link Design Guidelines

Table 30 displays the Fiber Optic Link Design Guidelines to be considered in the Link Design.

Characteristic	Engineering Guideline
Fiber Optic Interfaces	– 1G interface per Last-mile Links
	– 10G interface per Aggregation Links
	*Capacity Safety Margin of 20% of interface capacity
Length wave	-1310 nm for 1000BASE-LSX -1310 nm for 10GBASE – LW
Fiber Loss	0.35 dB/km

Table 30. Guidelines for Fiber Optic Link Design

>

4.2.8.2 Microwave Link Design Guidelines

Table 31 displays the Microwave Link Design Guidelines to be considered in the Link Design.

Characteristic	Engineering Guideline
Availability	-Last-mile Link: 99,9% -Aggregation Link: 99,99%
Frequency Band Selection	– Unlicensed 5GHz for distances < 5km
	– Licensed 15GHz for distances in the range of 5km-15km
	– Licensed 7GHz for distances in the range of 10km-25km
Microwave Link Capacity	– 50Mbps – 100Mbps per Last-mile Links
	– 100Mbps – 250Mbps per Aggregation Links
	*Capacity Safety Margin of 20% of link capacity
Terrain Database	The terrain database must have a resolution of at least 500m.
Rain Attenuation Calculation	ITU method Recommendation ITU-R P.530-7 / 8

Table 31. Guidelines for Microwave Link Design

>

Design Example

Fiber Optic Link Design

The methodology presented in Section 3.1 is applied to generate the Fiber Optic Link Design following the guidelines in Table 30. The results are displayed in Table 32.

Table 32. Fiber Optic Link Designs for Design Example

Microwave Link Design

The methodology presented in Section 3.2 is applied to generate the Microwave Link Design following the guidelines in Table 31. Figure 20 displays the MW link profiles for Design Example.

Figure 20. MW Link Profiles for Design Example

The results of the Link Budget are displayed in shown in Table 33.

Table 33. Microwave Link Designs for Design Example

In addition, NaaS Operator can use the Tx LLD Report Template as a base to create their own version.

>

4.2.9 DF Generation

The Transport Datafill is a document that consolidates the required information to implement the transport solution in a site. The following subsections describe procedures to perform the Datafill Generation.

To simplify the overall process and standardize the Datafill generation, a Template that contains the consolidated transport information must be defined and adopted by the NaaS operator. It is highly recommended that the Datafill Template is divided in the following sections:

• LTE Services: Consolidated information to deploy the 4G Services (User, control, management and synch IP addresses and VLAN definition).
• MW Information: Consolidated information to deploy the microwave transport technology (e.g. Tx Link design, Tx Equipment Resources)
• Router Information: Consolidated information to deploy the fiber optic transport technology (e.g. Tx Link design, Tx Equipment Resources)
• Additional Information: Additional information to deploy the transport solution (e.g. Quality of Service Definition, Security Mechanisms)

Furthermore, there are two main approaches to consolidate the Datafill Generation Process:

• Per-site Datafill: This approach consolidates all the information to define the overall transport solution for a specific site. Following this approach, bigger control over the information of the transport solution for a site is achieved. However, this process is only recommended in small network (e.g. less than 50 sites) because the generation of individual Datafills is time consuming and the file management becomes complex.
• Per-Technology Datafill: This approach consolidates all the information regarding the different technologies into a Master document that can be consulted by any team member. However, the consolidated document may become complex as the number of sites increases.

The recommended approach for small networks (e.g. 50 sites) is the Per-site Datafill approach. For more complex networks, the Per-Technology Datafill.

Design Example

For space considerations, the transport Datafill for the transport links in the Design Example are included as part of the Tx LLD Report Template.

>

4.2.10 BoM Generation

A bill of materials (also known as a BOM) is a comprehensive list of parts, items, assemblies and other materials required to implement the transport solution during the deployment phase. Following is a high level list of information to include into BOM record:

• Part Name – Unique name of each element that helps to identify parts more easily.
• Description – Provide a detailed description of each part that will help to distinguish between similar parts and identify specific parts more easily.
• Quantity – Record of the number of parts to be used in deployment phase to help guide purchasing and activities.
• Unit of Measure – Measurement in which a part will be used or purchased. Consistency across similar part types is important because the information will help make sure the right quantities are procured and delivered to deployment teams.

Following are key requirements that BoM management should address to optimize the process:

• Centralize control of the BOM
• Secure access and accountability for internal and external teams

Design Example

The Bill of Materials that considers the equipment required for all the scenarios in the Design Example is displayed in Table 34.

Table 34. Bill of Materials for the scenarios in Design Example

In addition, NaaS Operator can use the Tx LLD Report Template as a base to create their own version.

>

4.3 NaaS Operator End-to-End Process Definition

NaaS operators can use the generic process design as a base to develop its own version according to its limitations and constraints. In order to adapt the generic process a deeper analysis of the process can be performed.

Analyzing the provided generic process design, activities can be classified into two groups:

• One-time activities: Tasks that will be done only one time during the design process. These activities only require resource consumption at the beginning of the process. In the provided process, one-time activities are: Transport Equipment Selection, Model Site Catalogue Definition, Design Tool Selection and IP Planning.
• Continuous Activities: Tasks that are continuously performed during the design process. These activities will consume the majority of resources during the design phase. In the provided process, continuous activities are: Site Tx Equipment Definition, Tx Network Resources Allocation, Tx Link design, DF Generation and BoM Generation.

The approach presented on this section will focus on continuous activities as they consume the majority of the resources. Following some guidelines that NaaS operator should consider in order to customize its own process:

• Pre-processing of one-time activities: One-time activities should be done at the beginning of the process in order to not keep consuming resources.
• Parallelization and merging of activities: Some continuous activities can be merged in order to optimize the cycle times of the process. For instance, Tx Network Resources Allocation can be performed in parallel with Tx Link Design.

Finally, it is highly recommended that NaaS operators execute a Critical Path Analysis over its process version to further optimization.

5 LLD Recommendation

Methodology to consolidate and generate a final LLD recommendation.

5.1 LLD Recommendation Format & Structure

The main deliverable is the LLD Recommendation which contains the overall technical solution description and basic configuration parameters required to implement the Tx Transport network. The LLD Recommendation shall contain the following aspects that should be consolidated into a single location that is accessible by all the members of the team (e.g. an Excel Workbook in a shared repository):

• Tx Solution Overview: Description that summarizes the Tx Solution.
• Model Site: Description of the Tx Solution to be implemented in the site (e.g. Network equipment, connection diagram).
• Transport Technology Datafill: Consolidated information to deploy the transport technology (e.g. Tx Link design, Tx Equipment Resources)
• 4G Services Datafill: Consolidated information to deploy the 4G Services (User, control, management and synch IP addresses and VLAN definition).
• Stack Protocol Definition: Basic configuration parameters for network protocols.
• Additional Considerations: Additional information to deploy the transport solution (e.g. Quality of Service Definition, Security Mechanisms)

5.2 LLD Recommendation Generation

Generation of the Reference Architecture following the format and structure established. NaaS Operator can use the Tx LLD Report Template as a reference to create their own version.

1. RAN Network HLD

A RAN High Level Design (HLD) is a critical engineering first step in expanding coverage into a new market, community, or area&#8210whether by deploying a brand new network for a greenfield project or by integrating a new radio access technology (RAT) on an existing network in an overlay initiative. It typically follows a business commitment to deploy but can also be used to inform the business case to establish or expand coverage.

Two scenarios can be identified: greenfield and overlay. The key characteristic of greenfield scenarios is the lack of existing infrastructure while in an overlay scenario there is a preexisting network. The greenfield scenario creates a higher CAPEX burden and focuses on reaching new market shares. On the other hand, the overlay scenario focuses on offering new services and improving end users quality of service (QoS) while leveraging existing infrastructure that implies a much lower CAPEX.

NaaS playbooks framework shown in Figure 1 displays the playbook modules and their relationship to the RAN HLD.

The Strategic Plan & Scope and High-Level Network Architecture modules provide the business and technical context for the NaaS operator and have direct impact and influence on many aspects of the network design.

This RAN HLD module is included within the network design area and has direct relation with TX backhaul HLD, backbone HLD, and mobile core HLD. The generated output of this module will serve as a required input for the RAN LLD module.

Figure 2 presents the RAN HLD functional view where the main functional components are exhibited. Critical module inputs are further described and examined in section 2.2. In addition, guidance and methodologies to execute the tasks included within each function are described in Section 3.

Figure 1 Network deployment and management framework

Figure 2 RAN HLD module functional view

2 HLD Fundamentals

This section presents a general overview of the baseline concepts to develop a RAN network design.

2.1 Radio Access Network Environment

A RAN design refers to the engineering process of integrating new mobile services on a previously uncovered area (greenfield scenario) or enhancing the existing ones on an already live network (overlay scenario). The RAN HLD process needs extensive RF dimensioning accompanied by iterations of radio planning (in the greenfield scenario for the selection of the final site locations).

The investment made for a deployment generally depends on the scope and radio technology of the design. Cellular base stations and RF equipment are expensive long-term investments for the operator and, as such, any operator will prefer to deploy the minimum number of sites to provide the optimal required coverage. The ideal site maximizes coverage in the intended area while minimizing interference.

Accurate design minimizes the need to add additional sites or relocate existing ones to meet the coverage and capacity needs.

2.2 Radio Access Network Design Inputs Description

Table 1 presents a description of module input data and candidate sources required for a RAN HLD. Furthermore, the impact of each input on the design process is examined.

Input Required	Description	Impact	Source
Network Architecture	High level view of the overall network	Will help to define the required site configuration	High Level Network Architecture Module
Operators Network Database*	Information regarding deployed network (e.g., physical site configuration and location, number of sectors and cells per site, and site and cell logical identifiers)	An updated database will clearly display each sites characteristics that will boost the overlay design	Operator Network Data
Site Survey Reports*	Reports of inspections of physical sites to gather relevant information (e.g. equipment inventory, photographic documentation)	Will significantly reduce rework when any difference is present between operators network database and physical installation	Site Survey Module
RF Equipment Generic Specifications	Specifications of the RF equipment regarding frequency, channel bandwidth and capacity	Accurate configuration for radio planning	High Level Network Architecture Module
Geodemographic Data Layers	Digital terrain maps with geographic information:         ●Clutter         ●Terrain ●Population distribution maps	Accurate dimensioning	Operator Network Data
Quality Objectives	Provides QoS requirements to be met in the network dimensioning exercise	Define coverage dimensioning	Engineering Specifications Module
Traffic Model*	Summary of the number of subscribers in the network, their demanded services and subscriber usage level.	Define capacity dimensioning	Operator Network Data
* Inputs required only for Overlay RAN initiatives

Table 1 Module input data

2.3 Coverage Dimensioning

The objective of coverage dimensioning is to find the minimum number of sites to achieve the required coverage and establish the coverage area provided by each site. Coverage area refers to the area where the energy radiated by the base station can be received by the end users equipment (UE) with an acceptable level and determines the maximum area that can be covered by a base station.

A dimensioning exercise gives an estimate that is then used for detailed planning of the network.

Various factors must be considered during network coverage dimensioning and setting of these parameters will affect coverage radius and the quantity of base stations. Factors such as the propagation environment and equipment characteristics will influence overall coverage dimensioning. Deeper insights into the coverage dimensioning process will be given in sections 3.4 and 3.5.

2.4 Capacity Dimensioning

Capacity dimensioning is used to determine the maximum data throughput and number of simultaneous users supported by a single cell and eventually the required number of base stations to meet the traffic demands in the desired area.

System capacity can be defined as the maximum aggregated data rate supported while meeting quality of service targets. The greater a sites capacity, the higher amount of data is supported, and more mobile subscribers can be connected to that base station at a given time, thereby reducing the amount of base stations that are required. This reduction would lead to capital and operational efficiencies for the network operator.

The technical aspects of coverage dimensioning are discussed in Primer on Dimensioning Principles.

2.5 Site Evaluation

Site evaluation is the process performed to select the final location to deploy a new base station based on the site survey result and transport solution criteria. Figure 3 displays a graphical summary of the site evaluation criteria points that are explained below.

Figure 3 Site evaluation criteria point

a) Presence of obstacles:

Obstacles such as foliage or buildings that could attenuate the antenna beam must be clearly identified as this will represent a major coverage degradation. Upcoming obstructions, such as new buildings planned or under construction should also be considered.

As far as possible, the path between the antenna and the area to be covered should be clear of man-made obstructions and foliage.

b) Height evaluation

Height of a proposed new site (nominal site) is an important parameter as it directly impacts its coverage. Site height must be compared with the surrounding environment (buildings, trees, and any other possible obstruction). Natural high-elevation locations (such as hills) can be leveraged for the installation of new sites to get better coverage compared with floor level installations. By placing the transmitter on a high tower or leveraging terrain elevation, the transmitter will be able to achieve a greater coverage than by placing it on lower heights. The higher the transmitter is from the floor, the following mechanisms are improved:

• Better line-of-sight (LOS) from the transmitter to the desired area.
• Fewer obstacles (such as trees or buildings) the signal will need to go through.

c) Co-existence

Radio transmitters near the location candidate or at the same site location can add interference levels to the new site that will impact service quality of the new cell. Interference can be caused by any electric equipment operating near the base station (even if operating on different frequencies) as equipment can introduce spurious harmonics that translate in the degradation of the desired signal. Major sources of interference are usually other base stations operating at different frequencies and power equipment.

Acceptable interference levels can be taken based on equipment specifications. However, measuring interference levels can be impractical. A rule of thumb for LTE deployments is that the system requires 40 dB of isolation. If the antennas have a vertical separation, there should be at least 0.2 m between the base of one antenna and the top of the other antenna. If antennas have a horizontal physical separation and a beamwidth of 65, there should be at least 0.5 m between them. These separations are shown in Figure 4.

Figure 4 Vertical and horizontal separation to achieve isolation

d) Feasibility for backhaul solution deployment

The transport team will need to validate the site location according to transport solution criteria. Criteria will depend on the transport solution selected for the site. Transport solutions and their corresponding criteria are briefly summarized in Table 2.

Transport Solution	Feasibility Criteria
Fiber Optic	Available path/road for the deployment of the fiber
Microwave	LOS between the site and a transport node
Satellite	Base station within the satellite footprint

Table 2 Feasibility criteria for backhaul solutions

If the site location doesnt comply with such criteria, it must be relocated.

Site selection may also consider other non-RF related criteria such as availability of power supply and space for equipment. These points will be covered in the Deployment module.

3 Functions & Methodologies

Methodologies to perform critical tasks/subtasks involved in the RAN design process.

3.1 Current Network Audit (Overlay Design)

This section applies only for overlay projects, the user interested in greenfield only, can skip directly to Section 3.3. In overlay RAN projects, the NaaS operator will deploy a new RAT on top of its current network. To have a feasible source of information about the existing RATs and the new one, an audit of the current network is required. The audit process comprises data collection from the OSS tools and from operators database/inventory. Information gathered from these two sources will be consolidated into one single document that will present the current state of the overall RAN. The process is detailed in the following sections.

3.1.1 Operations Support Systems Tools Data Collection

RAN vendors implement OSS tools, through them NaaS operators monitor and manage their network (e.g., Ericssons OSS Common Explorer, Huaweis U2000, Nokias NetAct). OSS tools provide data from the live network and must be considered as the most reliable source to identify the status (on-air, off-air) and logical configuration of each site in the network.

Furthermore, OSS tools are the vehicle to obtain the information required in the audit process: Site and cell names, site and cell logical identifiers per RAT such as physical cell identity (PCI) for LTE, primary scrambling code (PSC) for 3G and base station identity code (BSIC) for 2G. With this information, designers can determine the number of sectors and carriers per RAT of each sitethe first step in the candidate selection. The basic principle of a network audit process is to collect all the available OSS networks information. Table 3 and Table 4 display the network information required for the network audit. These parameters are necessary to identify each site and its RF configuration. Its important to notice that some identifier names can vary from vendor to vendor.

Basic Site and Cell Name per Technology
LTE	WCDMA	GSM
Site Name Site Code eNodeB Code Cell Name Cell Code Site status Cell status	Site Name Site Code Cell Name Cell Code Cell Name Site status Cell status	Site Name Site Code Cell Name Cell Code TRX Name TRX Code Site status Cell status

Table 3 Site and cell names

Basic Logical Site and Cell Identifiers per Technology
LTE	WCDMA	GSM
PCI PRACH Bandwidth TAC RAC EARFCN MME Code	PSC UARFC (UTRA Absolute Radio Frequency Channel Number) URA LAC RAC SAC RNC Name RNC Code	BSC Name BSC Code BSIC (NCC+BCC) TRX No. BCCH HSS LAC RAC

Table 4 Site and cell logical identifiers

In addition, some physical site configuration such as azimuth, latitude and longitude can be collected from the OSS tool (depends on each vendor tools limitations). Nevertheless, Site Survey report is the most accurate source to obtain physical information (as will be described in section 3.2). Table 5 displays required physical information.

Basic Physical Site Parameters for All technologies.

Type of Site Frequency Band Latitude & Longitude Ground Height Antenna Tilt (Electrical +Mechanical)

Table 5 Physical site parameters

OSS tools allow NaaS operators to export the network data in different formats. The default choice is to extract network information in Excel spreadsheets. Exportable information makes data analysis and collection easier for NaaS operators.

The source of the data varies based on the technology: In GSM-2G and UMTS-3G, RAN information sources are network controllers (base station controller for 2G and radio network controller for 3G) while for LTE-4G sources are base stations themselves; they can be organized in groups defined by the operator (e.g., by region, by MME). Network designers must download information from the whole network.

All network information collected should be unified in one file, preferably in an Excel format, one sheet or workbook per RAT. An Excel file enables NaaS operator to manage, update and filter information easily.

3.1.2 Naas Operators Network Database Analysis

Besides OSS information, NaaS operators have their own network database that is the as-built database for all physical configurations. Frequently, an operators database is out of date mainly because some network changes arent always reflected in it. Nevertheless, this database is always relied on for physical site configuration coming from previous RAT deployments. Physical information to be obtained from operators database is: longitude, latitude, azimuth, electrical tilt, mechanical tilt, and antenna or tower height.

If the NaaS operators have more than one network database, its necessary to consolidate the information in one. The consolidation process is composed by three steps:

1. Define number of sites and sectors No site shall be discarded, even when the number of sites differs between databases. The consolidated one must contain all sites. The same approach must be applied to define the number of sectors per site.
2. Define physical site configuration Physical site configuration must be aligned with the more recent database; if one site or sector is not included, the data can be taken from a previous one that contains the information.
3. Database file building Site information should be unified in one Excel file, one sheet per RAT.

Its important to clarify that the process must be applied per RAT since the objective is built to a database with the physical configuration per technology of each site in the network.

3.1.3 OSS Information and Operators Database Consolidation

To finalize the current network audit, the information collected from the OSS tools (site and cell names, logical identifiers) should be complemented with the consolidated operators database. (site physical configuration).

Since the OSS information is the most accurate source of data, sites and sectors contained in the consolidated database that dont appear in the OSS tools should be removed; NaaS operators must define the action points to clarify their status.

If there are sites and sectors from OSS tools missing in the consolidated database, NaaS operators should evaluate the possibility to do a site survey.

The physical site configuration obtained through OSS tools should be compared with the consolidated database; the Naas operator must evaluate its relevance. Physical information from OSS tools could be not updated or be accurate since theyre mainly used to manage logical configuration in contrast with consolidated database that comes from site surveys made in previous RAT deployments.

The information should be on a single point of consultation. This point can go from a web-shared spreadsheet (Google Sheet, Office365) to an inventory management solution. Table 6 shows a summary of some open source inventory management tools.

Feature	Kuwaiba	AssetTiger	ManageEngine AssetExplorer	Snipe-IT
Upgrade Cost	Free	$100/year	$955/year	$399.9/year
Free Usage Limit	Unlimited objects and users	N/A	N/A	N/A
Mobile App	No	Yes	Yes	Yes

Table 6 Inventory management tools

A NaaS operator can use the Network Information Management and Inventory for the creation of its consolidated database.

3.2 Site Survey Analysis (Overlay Design)

The current network audit (section 3.1) focuses on consolidating information available in existing databases (OSS tools and operators database). However, regarding physical information, the most reliable source of information is existing site survey reports. An SSR contains extensive physical information about the sites in the network. During the HLD phase for overlay scenarios, NaaS operators should be focused on information regarding geographical site position, physical configuration, and hardware installed.

During the analysis of SSRs, designers must validate or update physical site configuration defined in the database created after the current network audit. The final audit database must be aligned with SSR information.

By extracting information about installed RF equipment per site, NaaS operators can identify candidate site configurations. This information will be useful to define the standard configurations.

Through the SSR analysis, RF hardware already installed is examined to evaluate the necessity to update the existing equipment or reuse it (that may reduce the deployment investment). Installed equipment can be reused if it has enough capacity and/or equipment capabilities (radio units and antennas operating band) to support the new overlay technology

Under the scope of an overlay RAN HLD, reusable hardware can be composed of antennas, radio units (RRUs), and baseband units (BBUs). More details are in section 4.2.4

3.3 Master Database Creation

The master database consolidates information obtained from the current network audit and site survey analysis and must be the source of truth for network information containing information from all sites in the network. Collection of the information in only one source is the Master Databases objective. furthermore, its essential to obtain accurate coverage plots and one of the main inputs for the deployment phase.

The master database creation process is divided in three steps:

1. Network Current Audit Consolidation between OSS tools information (logical site configuration) and operators database (physical configuration) to generate final audit database.
2. Site Survey Analysis Since the SSRs contain the most accurate physical site configuration, the final audit database must be updated with the available reports.
3. Site Categorization All sites in the network must be categorized as candidate or non-candidate and each candidate must be associated with one standard configuration (section 3.9). An existing site can be considered as a candidate if it complies with basic criteria such as: available tower space, available power supply, and acceptable rental costs, among others. A NaaS operator can use the Site Location Validation Questionnaire template to evaluate a site as a candidate or non-candidate.

Basic information to be contained in the master database is:

• Physical site configuration (e.g., height, number of sectors and cells, azimuth, and tilts)
• Site and cell names
• Site and cell logical identifiers
• Site category (candidates, non-candidates)

Note: Site category can be defined based on the Site Location Validation Questionnaire template

For greenfield projects, a master database or inventory is to be created as well to keep track of the designs and register sites on-air as deployment progresses.

NaaS Operator can make use of the Master Database Template to work on its own version or use one of the Inventory Tools described in section 3.2.

3.4 Link Budget

Radio link budget (RLB) is the first step to estimate the required number of sites to cover a certain area. RLB computes the power received by the user equipment (UE) given a specific transmit power from the base station.

Received power is obtained by adding transmit power to both base stations and UEs antenna gains and subtracting feeder losses, path loss, body loss, shadowing and interference margins. Eq 1 summarizes the RLB process. Figure 5 displays a representation of the RBL process in a mobile system.

(Eq. 1)

Where:

● – Received Power

● – Transmitter Power

● – Gain of the base station antenna

● – Gain of the User Equipment antenna

● – Feeder Loss

Indicates the signal loss caused by various devices (e.g., jumpers, cables) located in the path from the transmitter to the antenna

● – Path Loss

● – Body Loss

Indicates loss generated due to signal blocking and absorption when the user’s equipment is close to the person’s body.

● – Shadow Margin

An extra “loss” is considered to account for obstacle absorption of the radio signal.

● – Interference Margin

An extra “loss” is considered to account for degradation in the received signal due to interference from other base stations.

Figure 5. Radio Link Budget representation.

Eq. 1 must be rearranged to perform coverage dimensioning using RBL. UE received power can be substituted with its sensitivity (minimum required power for the signal to be decoded at the UE). Considering this, the designer will be able to estimate the maximum loss that the signal can suffer for the UE to work properly. As the main loss present in the mobile system is due to the path loss, a maximum allowed path loss (MAPL) can be estimated as shown in Eq. 2:

(Eq. 2)

Where:

● – Sensitivity of the user equipment

Once the MAPL is known, the cell radius can be obtained using a propagation model. Propagation models are used to estimate the attenuation of the radio wave as it traverses its path. A variety of propagation models exist, and their application is determined by two main factors:

1. Operating frequency.
2. Morphology (clutter) under consideration. Clutters can be classified as follows:
1. Urban This environment consists mainly of large buildings (that produce major attenuation) and small density of foliage.
2. Suburban This environment presents wide-ranging housing areas that includes some vegetation. Suburban environments are mostly found at the border of urban areas, spreading outward from the city centers.
3. Rural This environment represents wide areas with a small density of buildings and large density of foliage. Major attenuation is due to the foliage present on the terrain.

The designer can follow these criteria to quickly choose a propagation model:

• For frequencies up to 1500 MHz, Okumura-Hata should be considered.
• When using a frequency greater than 1500MHz and up to 2000 MHz, COST-231 model should be considered.

The technical aspects of propagation models are discussed in the Primer on Propagation Models..

Okumura-Hata and COST-231 models require the height of the base station as an input for the loss prediction. Network designers must consider the fact that the selection of a transmitters height represents a trade-off between coverage, number of sites, and financial investment.

Higher base stations represent better coverage per site, requiring fewer sites per region. However, higher sites cost more to build and cost goes up exponentially with tower height. Network designers must find a balance between the number of sites per region and the financial constraints involving site height. Further guidance and a design example are provided in section 4.2.8.

If path loss is known (shown in Eq. 2), then cell radius can be computed by solving the propagation models equation for d (see Primer); this can be done practically using the Widget for Coverage-Based Site Count.

Table 7 shows examples for 700MHz and 1800MHz:

Frequency	Transmitter Height	Transmit Power	Cell Radius
700 MHz	15 m	20 W	4.70 Km
		30 W	5.24 Km
700 MHz	20 m	20 W	5.43 Km
		30 W	6.07 Km
700 MHz	30 m	20 W	6.73 Km
		30 W	7.55 Km
1800 MHz	15 m	20 W	0.84 Km
		30 W	0.94 Km
1800 MHz	20 m	20 W	0.94 Km
		30 W	1.05 Km
1800 MHz	30 m	20 W	1.10 Km
		30 W	1.23 Km

Table 7 Cell radius calculation

Cell radius based on link budget should be taken as the best case as its based on average calculations and doesnt take into account all obstacles and propagation mechanisms of the signal.

3.5 Coverage-Based Site Count

Once cell radius is estimated, it can be used to calculate the number of sites required to cover the whole area with respect to the cell radius d. By convention, cell coverage area is assumed to be hexagonal as shown in Figure 6.

Figure 6 Coverage area of a radio site

For a hexagonal site, coverage area can be calculated as follows:

(Eq. 3)

The number of sites to be deployed can be calculated from the coverage area and the required area to be covered (deployment area) as follows:

(Eq. 4)

Even the link budget is based entirely on mathematical equations; a complete RAN HLD can be achieved by only applying it. A more detailed planning can be done by using a radio planning tool (RPT) thanks to the use of terrain information. However, the use of an RPT is optional in uncovered rural environments.

A NaaS operator can use the Widget for Coverage-Based Site Count for this task.

3.6 Radio Planning Tool Selection

When a RAN design project is to be performed, RPTs can be used for simulations and location of new sites. These make use of sophisticated and detailed terrain maps: terrain elevation maps, demographic distribution maps, and clutters that make the design more detailed. Thanks to this, RPTs can use several more complex propagation models that account the terrains profile (e.g., mountains) into the loss prediction (details about RPT configuration are out of the scope of this module).

However, the use of an RPT in the RAN HLD is optional for uncovered rural areas. As will be shown later, location of new sites and coverage planning can be done following the link budget procedure.

There is a wide variety of RPTs that can be classified in several manners: licensed and unlicensed, carrier and WISP grade, and web-based. To simplify RPT selection, Table 8 displays a summarized description of some RPTs.

Table 8 Summary of radio planning tools

A first step in selecting an RPT is to always consider the budget of the operator.

The next step is to define which tool features will be required. For the creation of the RAN HLD, at a minimum a designer needs to be able to estimate the transmitter height, transmitter power, number of sites, and sectors per siteas well as be able to locate the site in the desired location (described in section 3.10). Site planning will be a desired feature to speed the HLD process but not a mandatory one. Additional features such as frequency planning, neighbor planning, physical optimization, and database management will impact the low-level design (LLD). An operator can selecting an RPT just for the HLD process, which translates in selecting a WISP grade tool.

Table 9 summarizes features of the tools listed above. An operator can choose an appropriate RPT based on it.

		Carrier Grade Tools		WISP Grade Tools
Planning Tool		Atoll	Mentum Planet	Radio Mobile	Xirio Online Planning Tool
Estimation of Sites Azimuth & Tilts		Yes	Yes	Yes	Yes
Support for Detailed Map information		Yes	Yes	Yes	Yes
Site Planning		Yes	Yes	Yes	Yes
Frequency Planning		Yes	Yes	No	Yes
Neighbor Planning		Yes	Yes	No	No
Physical Optimization		Yes	Yes	No	No
Database Management		Yes	Yes	No	No
Price		High	High	Free	Medium

Table 9 Summary of radio planning tools and features

3.7 Capacity Based Dimensioning

Radio equipment has capacity limitations driven by two main factors:

1. The maximum number of simultaneous active users that a single base station can serve.
2. The maximum throughput supported.

These two factors must be analyzed separately and their results compared to compute the required number of radio units based on capacity requirements.

3.7.1 User-Based Capacity Dimensioning

This is defined as the maximum number of simultaneous active users varies from one equipment to another. To have the exact value, network designers must identify it from the product description of the specific equipment. However, a good approximation is to consider that 100 simultaneous active users are supported per radio equipment. The following steps must be followed for the user-based capacity dimensioning.

Subscriber Forecast:

Network designers must obtain the total number of subscribers that will be served in the required area. This value is calculated by the following equation:

(Eq. 5)

Where

• – Population Target: Reflects the total number of inhabitants in the area. This quantity exclusively depends on the target area defined by the NaaS operator.
• – Service Penetration: Percentage of the overall population that will be covered. This quantity is based on the NaaS operators business case. Values between 40% and 60% are commonly used for rural environments with no competition.

Active Users Forecast

Not all subscribers will always be served simultaneously. The percentage of active users in the busy hour (the time where a peak in the service exists) is considered to dimension the number of active users in a network.

(Eq. 6)

Where

• Is the percentage of subscribers who are active in the busy hour of the day. This input can be Provided by the NaaS operator. However, 5% can be taken as a starting value.

Equipment Dimensioning

Finally, the number of active users must be compared with the maximum active users supported by the radio equipment.

(Eq. 7)

Where

• Is the maximum concurrent users per eNB.

3.7.2 Throughput-Based Capacity Dimensioning

In a similar way that the base station supports a determined number of simultaneous active users, it also has a limited downlink (DL) and uplink (UL) throughput. For this reason, an evaluation of the overall DL and UL throughput must be done to evaluate the required number of sites.

The first step is to compute the overall DL and UL traffic that will be generated by the active subscribers during the busy hour (time frame of one day where the maximum amount of traffic is carried in the network.). Eq.8 and Eq.9 show how to compute these figures for DL and UL respectively.

(Eq. 8)

(Eq. 9)

Where:

• & – Average DL & UL throughput that the network carries during the busiest hour of the day. Depending on the specific environment, typical values go from 16 kbps to 128 kbps.
• (Peak-to-Average Ratio) Is the relation between the peak throughput and the average throughput. As bursty traffic is common, values between 6 and 10 can be used if no previous data is available.
• (Overprovisioning Factor) Is a percentage of the total eNB capacity that will be used for the dimensioning, leaving the rest percentage of the capacity as a backup for special events or future network expansion. Typical values are between 70% and 90%.
• Is the relation between maximum throughput and subscriber throughput in the busy hour.

The next step is to compare the calculated DL and UL traffic with radio equipments average throughput capacity as shown in Eq. 10 and Eq. 11. If equipment average throughput data is not available, the typical values of an LTE system can be considered. Table 10 displays cell average throughput for different scenarios and bandwidths.

Cell Average Throughput
Bandwidth	DL (Mbps)	UL (Mbps)
5	8	5
10	17	10
15	25	15
20	33	20

Table 10 Typical average sector throughput for LTE-FDD (considering MIMO 2×2)

The comparison between overall DL and UL throughput and equipment average throughput capacity will result in the required number of radio equipment to support the DL and UL demand.

(Eq. 10)

(Eq. 11)

Where:

• & eNodeBs average DL and UL throughput
• & Maximum allowed DL and UL rate per subscriber.

The required number of eNodeBs is calculated as the maximum between and :

(Eq. 12)

3.7.3 RAN Equipment Count

Final eNodeB count will be obtained from the comparison of the user-based vs. the throughput-based capacity dimensioning. The maximum between and will give as result the final eNodeB count.

(Eq. 13)

This calculation can be easily done through the Widget for Capacity-Based Site Count.

3.8 Standard Configurations Definition

High-level site configuration is a combination of the following parameters: operating frequency, antenna height, transmitter power, number of sectors, and type of antenna. Based on the combination of these parameters, network designers can create specific configurations, simulate them and finally select that one performs better in terms of coverage, site count and cost. Deeper insight into the selection of the best configuration is made in section 4.2.8.

Based on RF specifications from RAN architecture module, standard configurations must be defined and registered.

The following are the steps to define standard configurations:

1. Various combinations of antenna height, transmitter power and number of sectors should be considered. At least one macro cell and one small cell configuration should be considered based on Table 11 below.

2. For each combination, cell radius can be calculated and a quick dimensioning to obtain the number of sites can be performed as indicated in section 3.5.

3. Based on cell radius and feasible options regarding tower height and transmit power, select standard configurations to be used for nominal site location estimation.

Base Station Type	Antenna Height	# of Sectors	Transmitter Power
Macro Cell	> 10m	1 to 3	>10W
Small Cell	< 10m	1	< 10W

Table 11. Base Station categorization.

Cfg. ID	Base Station Type	Cell Bandwidth	Operating Frequency	Antenna Height	# of Sectors	Tx Power	Cell Radius (Km)
Config. 1
Config. 2
Config. n

Table 12. Sites Configuration.

3.9 Nominal Site Location Estimation

After computing the number of base stations to cover the target area, the initial locations for those sites (referred to as nominal sites) must be defined. In a greenfield scenario, network designer must follow these next steps to establish the nominal site locations:

1. Introduce third-party infrastructure locations (e.g., existing towers) to a GIS tool (e.g., Google Earth) as shown in Figure 7. The set of third-party infrastructures is an input to the network designer. If no third-party infrastructure is available, go to step 3.
2. Create a hexagonal polygon, considering the location of existing towers as the hexagons center, as shown in Figure 8. The radius of the hexagon must be set using the Widget Coverage-Based Site Count using the height of the existing tower. Its a convention to consider the sites coverage area as having a hexagonal shape (when the real coverage region can have an irregular form). This is made to facilitate the filling of the coverage.

Figure 7. Location of existing infrastructure on the map.

Figure 8. Hexagonal coverage for existing infrastructure.

3. Uncovered areas of the desired region must be filled with hexagonal shapes until the whole region is covered. The center of each new hexagon will be considered as the sites location. Figure 9 displays this process.

Figure 9 Filling of the remaining area

4. The designer must verify that the sites defined in step 3 are located in valid locations:
   
   • Valid Locations: Rooftops or vacant sites
   • Non-valid locations: Water bodies, the middle of the street, dense foliage locations, countrys regulations.

Further discussion about valid and non-valid locations must be taken by NaaS operators
strategy team.

The network designer must notice that nominal locations can be changed due to external RF factors such as: transport solution feasibility, countrys regulations, or any point considered in the site evaluation criteria.

3.10 RF Site Configuration Definition

RF site configuration refers to the physical parameters in a radio base station: base station type, antenna height, number of sectors, and transmitting power. Standard configurations were previously defined in section 3.9.

Based on the site count (coverage and capacity), standard configurations, and nominal locations, the network designer is able to select the standard configuration(s) that best suit the coverage and capacity requirement.

Table 13 can help the designer to summarize site configurations.

Cfg. ID	Number of Sites
Cfg. 1	1 Site
Cfg. 2	2 Sites
Cfg. n	n Sites

Table 13. RF Sites Configuration distribution.

This represents an iterative process where several configurations must be analyzed to define which sites maximize the coverage region with the smaller number of base stations while keeping the CAPEX low. Implementation considerations are analyzed in section 4.2.8.

3.11 Site Location Validation

Once that nominal site locations have been estimated, location feasibility must be validated.

This can be done through satellite imagery or using existing information from the site; however,
in most cases a site survey must be performed.

The Site Location Validation Questionnaire is provided to the NaaS operator to evaluate all sites and candidate sites based on points previously discussed in section 2.5. Clauses in the questionnaire are considered as critical points. Thus, if a clause is not compliant, the site must be relocated or the candidate site dismissed.

Further guidance to perform site survey can be found in the Site Survey Module of the Playbook.

4E2E Process Flow

Generic yet customizable E2E process flowto perform the radio access design for the RAN. Through this section, a designexample for a greenfield scenario will be shown to display the application ofeach step of the E2E process.

4.1E2E ProcessOverview

Figure 10 displays ageneric E2E process to perform a greenfield RAN HLD. In addition, Figure 11displays the generic E2E process for an overlay RAN HLD.

For the greenfield scenario, locations tobe considered in the dimensioning process are initially defined in the CoverageObjectives Definition section. Service level requirement establishesradio access parameters that must be experienced by end users. Once the servicerequirements are established, a capacity demand forecast is performed to estimatetraffic growth in the future. The coverage and capacity dimensioning processpresents a methodology to compute the number of required sites based on bothcoverage and capacity constraints.

Standard radio configurations standardizeall possible radio base stations configurations to be used. RF configurationguides the designer into the selection of an optional radio planning tool; itis also a guidance for the selection of an optimal RF configuration and theestablishment of the adequate nominal site locations for radio sites. Site locationvalidation presents a methodology for the selection of the finallocations of the radio sites based on site evaluation criteria and transportsolution feasibility. Then a RF equipment BOQ determines the required equipmentto implement the RAN.

Figure 10 Greenfield RAN generic E2Eprocess description

In the case of an overlay scenario, someactivities are added due to the fact that this scenario considers an upgrade toan existing RAN. A coverage objectives definition and service levelrequirements are also defined in the overlay. However, this scenariorequires an infrastructure and equipment requirements analysis toidentify that equipment will be kept and that one should be changed for a newone. Also, a prework and data collection step is required to have anupdated view of the current network. Standard radio configurations arealso required to the new configurations. The candidate site definition processis analogous to the site location validation for greenfield, in that theexisting sites are assessed to define which ones will be upgraded with a newRAT. The remainder of activities will be the same, ending in an RF equipment BOQ.

Figure 11 Overlay RAN generic E2E process description

4.2Step-by-StepAnalysis

4.2.1Coverage ObjectivesDefinition

Analyzing and understanding coveragerequirements is the first step for the design process. Its essential to have awell-defined area to be covered. General requirements for the deployment of aRAN will generally be concerned with cost and time to market, so it can beinfluenced by the NaaS operators business strategy or predefined agreementswith MNOs. A simple process to define coverage objectives is described below:

1. Identify the area to be covered Search for geographic areas with no 4G coverage, as uncovered areas will represent higher revenue opportunities.
2. Identify Special locations Some special locations should be considered to have mandatory coverage (e.g., schools, hospitals, government buildings). Any location with strategic importance for the NaaS operator should be considered a special location.
3. Identify covered population distribution How people are distributed in the selected area must be addressed to define that specific portion of the overall region.

DesignExample

In our example,the coverage objectives shown in Figure 12 have been defined by drawing apolygon in Google Earth and identifying populated areas in a rural town. Inaddition, two special locations are definedthe town hall and aschool.

Using Google Earth,the total area of the target polygon was calculated having as a result 0.8km².

Population information wasobtained from census data &#8210 3683 total inhabitants.

Figure 12 Coverage objective definition example

Dependencieswith other tasks

Service level requirementspresent the following dependencies:

Prerequisites

• Geodemographic Data Layers This information is required to have a clear image of the overall areatowns, population distribution, special locations, terrain characteristics that need to be known for the definition of the coverage objectives.

Outputs

• Coverage and Capacity Dimensioning Network designers must consider the defined coverage objectives during network dimensioning to know where the radio base station must be located to cover such objectives (details in Section 4.2.7).

4.2.2Service LevelRequirements

Mobile networks will support a variety ofsubscriber services. Some may be a key differentiating factor in the operatorsservice offering. Hence, the operator must define service level requirements interms of downlink (DL) and uplink (UL) throughput. Table 14 shows typicalservice requirements that can be considered by the NaaS operator.

Service Level	Service Throughput (DL/UL)
	(Mbps)
Service level A	6 / 1.5
Service level B	4 / 1
Service level C	2 / 0.5

Table 14. Service Requirements Definition Example.

The NaaS operator can use the Widget for Capacity-based Site Count to evaluate theimpact on the number of sites for different t service level requirements.

Design Example

For the example case, we will consider servicelevel B for the capacity demand forecast estimation: DL throughput: 4 Mbps, ULthroughput: 1 Mbps.

Dependencies withother tasks

The definition of service levelrequirements is related with other tasks as detailed below.:

Outputs

• Capacity Demand Forecast: Service levels will be used toestimate capacity growth. Details on section 4.2.3.

4.2.3Capacity DemandForecast

Traffic forecast plays a major role incellular planning as its results must be considered for the dimensioning of thenetwork to overcome future capacity growth.

First, capacity at year 0 is estimatedusing one of two approaches:

1. Apply the capacity dimensioning methodology shown in 3.8.
2. For overlay initiatives, it can be taken from the sites current capacity.

Then capacity isforecasted based on a growth percentage per unit of time. Eq. 14 displays a formula for the estimation of a capacityforecast.

(Eq. 14)

Where n represents a planning horizon in thefuture and x is the growing factor. Initial capacity is considered asthe network overall number of users and DL and UL throughput.

Considering n as years is aconventional time frame for most calculations. Considering it as months willrepresent a very aggressive and unpractical consideration.

Standard values for x can be takenfrom 10% to 15%. Selection of a capacity growing factor will depend on how muchthe NaaS operator is expecting a growth on its network demand. However, aconservative expectation is often chosen in most scenarios that includesuburban and rural environments, considering years as a time frame and a growthfactor of 10%.

Dependencieswith other tasks

Prerequisites

• Service Level Requirements Service level must be known to make the traffic forecast calculation.
• Quality Objectives & Traffic Profile Data needed as an input to estimate future capacity growth. Number of subscribers must be shared as part of the traffic profile.

Outputs:

• Coverage and Capacity Dimensioning Network designers must consider the forecasted capacity during network dimensioning to have a network that wont suffer from capacity constraints in the future. Details in section 4.2.7.

Design Example

The starting point of the capacity demandforecast is to calculate the networks initial capacity. Steps for itsobtentions are as follows:

First you need to know how many activesubscribers will be requesting for service in the busy hour. For this end,subscriber forecast and active users forecast must be obtained followingmethodology shown in section 3.7.1.

Required inputs are:

• Population targe t= 3683 inhabitants
• Service penetration= 40%
• Percentage of activesubscribers in the busy hour = 5%

Using the Widget for Capacity-Based Site Count, we get the following result:

• Subscriber forecast = 1474Subscribers
• Active Users forecast = 74Subscribers

Next, compute the overall DLand UL throughput that will be carried by the network in the busy hour asdescribed in section 3.7.2.

Required inputs are:

• Average DL & UL throughput during busy hour = 0.064 Mbps DL / 0.016 Mbps UL
• Peak-to-average ratio = 6
• Overprovisioning factor (u) = 80%

Using the Widget for Capacity-Based Site Count, you get the following result:

• Overall DL throughput: 35.52 Mbps
• Overall UL throughput: 8.88 Mbps

For the design example, a forecast for three yearswith an annual growth of 10% will be considered. By using the Widget for Capacity-Based Site Count, user and throughput capacity forecasts areobtained:

Active user forecast at busy hour: 99 Subscribers

Throughput forecast at busy hour: 47.27 Mbps DL / 11.82Mbps UL

In overlay projects, its possible to reuse radio equipment orinfrastructure in existing sites. However, a procedure is required to identify thatelements can be reused and the cases for that new equipment must be installed.On the other hand, a NaaS operator can choose to deploy the overlay RAT on newdedicated equipment (e.g., dedicated new vendor). The following steps willguide the NaaS operator to decide when the RAN equipment and infrastructure canbe reused:

1. Radio Equipment Reuse: Network designer mustreview technical specifications of existing equipment used to provide 2G and/or3G to check if it can support a 4G expansion or if it can be upgraded tosupport it (e.g. through new baseband unit card, new radio or new antenna).Common RF equipment that can be reused is listed below:
• Antennas. When deploying 4G on the same frequency than legacy technologies, antennas can be reused. If a new Radio unit is going to be used, there must be available ports on the antenna in order to be reused.
• Radio Units When deploying 4G on the same frequency as legacy technologies and the existing radio unit has available power to be allocated to 4G, it can be reused.
• BBU If available capacity (both RF and backhaul capacity) for the new RAT is available on the BBU, it can be reused. If there is no available capacity left but it can be expanded, its up to the NaaS operator to decide to deploy a new BBU or acquire a capacity expansion for the existing one.
2. Infrastructure reuse: Existing infrastructure can be reused under twoscenarios:
• Radio and Base band units being reused for the new deployment.
• If the existing site has tower space and power capacity available to permit the installation of new equipment.

Design Example

As the example case dealswith a greenfield scenario, this step is not considered for it.

Dependencies with other tasks

Prerequisites

• RAN Architecture Module The designer must consider the RAN Architecture Module as a guideline since it defines RAN scenarios and vendor selection for new installations.

4.2.4Prework and DataCollection

To obtain an organizedand feasible source of information about existing sites on the network andsites that will be deployed, a NaaS operator must work on a unified database thatwill contain the most important data regarding every site in the network. Amaster database or networkinventory should be the result of this process. The creation of the finalmaster database considers the following steps:

1. Current Network Audit The NaaS operator must share all its available information about the operating network. The designer must at least have access to the OSS tools to download all basic information of the current network. See section 3.1 for further details.
2. Site Survey Analysis Information coming from the current network audit consists of logical site parameters. However, physical data such as coordinates, azimuths and tilts, and current number of radios onsite must be also considered into the master database. In this case, the most feasible source to get this data is a physical site survey. A site survey can mean an extra investment for the NaaS operator and isnt a mandatory task, but its highly recommended as it can mean a reduction of rework due to inconsistencies between the NaaS operators database and OSS collected information.
3. Master Database Creation Both logical and physical information must be consolidated into a single document. This document must be built considering points shown in Table 15 (each parameter must be accommodated in its own column).

Site and Cell Names	Sites Physical Parameters	Logical Site and Cell Identifiers.

Table 15 Minimum fields to be contained in themaster database

The master database can be implemented in a format that best suits the NaaS operator.Below are a couple of formats to beconsidered.

• A spreadsheet that can be cloud stored and managed. This is the most straightforward way of implementing a quick database. By using a cloud application such as Google Sheets or Microsoft 365, several people can have access to the spreadsheet, that will facilitate teams work.
• An open source inventory management software (such as the ones shown in Table 6) will bring professional management of the database, allowing (some of them) extra functionalities than a spreadsheet.

Design Example

As the example case dealswith a greenfield scenario, this step is not considered for it.

Dependencies with other tasks

Service level requirements present the followingdependencies:

Prerequisites

• OSS Tool Access &#8210 The network designer must have access to the networks OSS tool to harvest all required information from the operating network.
• NaaS operator Network Database &#8210 The NaaS operator can have a previously worked database that will be compared with the information obtained from the OSS tool.
• RAN LLD &#8210 An accurate and updated database will boost the work in the low-level design process for the RAN.

Outputs

• RAN LLD &#8210 An accurate and updated database will boost the work in the low-level design process for the RAN.

4.2.5Standard RadioConfigurations

Based on the range of parameters consideredin the RAN Architecture module, network designer must build a set (orsets) of possible radio configurations. Its recommended to define more thanone set of configurations to evaluate them in terms of number of sites andCAPEX per configuration.

Design Example

Standard configurations in this design examplewill be built considering the two most common base station types to highlightthe differences between them: macro cell site and small cell site.

Operating frequency is assumed to be 700MHz asthis band is commonly used in rural deployments due to its good propagationcharacteristics in open areas, together with a 10 MHz cell bandwidth.

Since the coverage region is a relatively smalltown, there is no need to build a high tower (30m to 40m). For this smallcoverage area, a 15m tall tower is enough for the macro site configuration.while for the small cell a 10m height is considered (small cell installation isntas complex as a macro cell site).

In rural areas, macro cell sites are (almostalways) configured with three sectors, so this option is considered for thedesign example. On the other hand, small cell sites are equipped with only oneomni sector.

Regarding transmitter power, 20W is usually theminimum configurable power for a macro cell and this option is usuallyconfigured for rural areas. Regarding small cells, maximum power for an outdoormodel is often 5W.

Finally, estimated cost per site is an averageof the deployment cost for each base station type and can be estimated based oninitial quotes from vendors or simply use high level estimates: 60k USD formacro and 20k USD for small cells.

Table 16 displays a summary with thediscussed configurations. Cell radius was obtained using the widget for Coverage-basedsite count.

Table 16. Design Example Standard site configurations.

Dependencies withother tasks

Prerequisites

• RAN Architecture Defined Parameters RAN architecture module establishes the range of values that must be considered for each parameter to build the standard configuration.

Outputs:

• RF Site Configuration Each configuration set performance must be evaluated directly on the map based on the results received from the coverage and dimensioning section. Details in section 4.2.8.

4.2.6Coverage and Capacity Dimensioning

The target of the network dimensioning isto estimate the required number of sites for each configuration to cover thetarget area. First, link budget calculations are used to determine the requirednumber of sites based on the maximum allowed path loss and propagationprediction. Then capacity planning determines the number of required sitesbased on the capacity forecast calculations. Both estimates are compared, with thehighest number of sites being taken to perform the design.

Figure 13 showsa methodology for estimating the number of radio sites applying both coverageand capacity dimensioning:

Figure 13 Dimensioning process

Design Example

As explained in this section, the dimensioning process is composed by the coverage and the capacity procedures. Start with the coverage analysis (number of sites required to cover the coverage area) followed by the capacity analysis (number of sites required to serve the subscribers traffic demand).

a) Coverage-based Dimensioning:

For coverage-based site count, we need to know the area to be covered. As described in section 4.2.1, total area for the coverage area is 0.8 Km².

Then, we need to identify the cell radius for each configuration as displayed in Table 16.

Finally, site count is obtained for each configuration dividing the regions area by the coverage area of each configuration (as described in section 3.5).

Table 17 summarizes the results obtained by using the widget Coverage-based site count:

Table 17. Summary of Coverage-based site count.

b) Capacity-based Site Count:

• User-based Capacity Dimensioning

First step is to determine the number of required eNodeBs based on the User Capacity Forecast obtained in section 4.2.3. Required inputs for the user-based capacity dimensioning are listed below:

• Simultaneous Users Forecast at busy hour = 48
• Maximum concurrent users per eNB = 100

Following the methodology described in section 3.7.1, the User-Based Capacity Dimensioning is obtained and shown in Table 18:

Table 18. User-based capacity dimensioning.

– Throughput-based Capacity Dimensioning

Next step in the capacity-based site count is to determine the number of required eNodeBs based on the Throughput Capacity Forecast obtained in section 4.2.3. To compute the throughput-based site count, the following inputs are required:

1. Number of sectors per site:
• Config.1 = 3 Sectors
• Config. 2 = 1 Sector (Omni)
2. Forecasted Capacity (as done in section 4.2.3):
• Simultaneous Users Forecast at busy hour: 99
• Throughput Forecast at busy hour: 47.27 Mbps DL / 11.82 Mbps UL
3. eNBs average DL and UL throughput (from Table 6):
• eNB average DL throughput: 17 Mbps
• eNB Average UL throughput: 10 Mbps
4. Service DL and UL throughput (as defined in section 4.2.2):
• Service throughput: 4 Mbps
• Service throughput: 1 Mbps
5. Average Busy Hour DL and UL throughput (from Section 4.2.2):
• Average DL throughput: 0.064 Mbps
• Average UL throughput: 0.016 Mbps

First, the throughput forecast at busy hour is compared with eNodeB average capacity following the methodology presented in section 3.7.3. Using the widget for Capacity-based site count, radio equipment count is shown in Table 19:

Table 19. eNodeB Dimensioning.

Both quantities are compared and the maximum of both is taken as the throughput-based site count shown in Table 20.

Table 20. Throughput-based eNodeB Dimensioning.

Then, the max between user-based and throughput-based dimensioning is taken as the final eNodeB dimensioning based on capacity, having 4 eNodeBs as the result, which would require 2 sites for Config 1, and 4 sites for Config 2.

c) Final Site Count:

Last step is to compare the coverage-based and the capacity-based site count as shown in Figure 14. Table 21 summarizes the Coverage and Dimensioning results.

Table 21. Coverage and Dimensioning Final Site Count.

Dependencies with other tasks

Prerequisites

• Coverage Objectives Definition &#8210 Coverage objectives must be defined to make the coverage dimensioning.
• Capacity Demand Forecast &#8210 Capacity dimensioning must be done considering the forecasted capacity for the network to support future capacity growth.
• Geodemographic Data Layers &#8210 Geographic information of the terrain and demographic distribution on it are required for an accurate dimensioning.

4.2.7RF Site Configuration

The network designer must leverage theresults obtained from the coverage and dimensioning process to select the onethat best performs in terms of number of sites, coverage area, and CAPEX. Table22 the trade-offs among these factors.

Criteria	Description
Coverage: Coverage area & Number of sites	A determined region can be covered with a small number of high macro sites vs a relatively larger number of short small cells. Network designer can evaluate, based on coverage area / population per site and cost per site, and select the option that best suits into NaaS Operator CAPEX.
CAPEX	Deployment of a RAN site always represents a huge investment that grows exponentially with the sites height. Even when using third party infrastructure, CAPEX is always higher for a macro site than for a small cell. In this regard, in some scenarios it will be more efficient (from financial point of view) to deploy some small cells sites rather than only one Macro Site.

Table 22.Transmitter height vs financial tradeoffs

Nominal SiteLocation Selection

Locations for new base stations can be established by following thesteps in section 3.10.

Design Example

Based on results displayed in Table 21, Table 23 shows the overall cost for each configuration considering cost per site (section 4.2.6).

Table 23. Standard Configuration summary.

The most straightforward approach is to select the Config. 2 option (four small cell sites) as this means a $40k saving. In this way, Table 24 displays the final configuration for the design example.

Table 24. Selected standard configuration for the design example.

Figure 14 shows the initial location for the four sites considering the calculated cell radius of 1.574 km. As can be seen, there is an important coverage overlap.

Figure 14. Example case initial site location.

To reduce overlap while covering the desired area, the cell radius can be reduced, which will imply a power reduction to be defined during the LLD. Figure 15 shows the corresponding result.

Figure 15. Example case final site location

Dependencies with other tasks

Prerequisites

• Standard Configuration RF standard configurations and configuration sets must be defined.

Outputs:

• BOQ Once the number of sites and each related configuration is defined, the network designer will have a clear image of models and quantities for RF sites. Details in section 4.2.10.

4.2.8Site LocationValidation

Figure 16displays a generic methodology to validate per-site location in terms of siteevaluation criteria points.

Figure16 Site location validation methodology

1. The first step is to validate site evaluation criteria points (addressed in section 2.5 and summarized in Site Location Validation Questionnaire). If any of those dont comply, a new site location must be selected for the studied site.
2. If site evaluation is successful, the transport team needs to validate the site location in terms of the transport solution feasibility. If site location is not feasible (due to any reason given by the transport team) a new location must be selected.

If the studied site location is compliantwith both site survey and transport evaluation, then it will be considered asthe final location for that site. This process must be followed for all plannedsites.

It must be noticed that if nominal sitelocations are based on previously defined locations, nominal locations areconsidered as the final ones.

Design Example

This step is not considered for the example asthe site survey wont be done.

Dependencies with other tasks

Prerequisites

• Nominal Site Locations All sites must be location defined. They must be classified between those that location was previously defined and those that not.

4.2.9RF Equipment BOQGeneration

A RF equipment BOQlists all necessary RF equipment required to deploy a radio site. Its fed withthe overall equipment needed to deploy the network. Some items the RF equipmentBOQ must address are shown below:

• Based on the RF configurations to be considered:
• Required number of radio units
• Required Number of antennas.

A NaaS operator can use the RAN HLD Template thatcontains a BOQ format to create its own.

Design Example

The final step in the RAN HLD process is to generate a BOQ that summarizes the required radio equipment based on the selected configuration.

Following the final configuration displayed in Table 24, a BOQ for the design example is shown in Table 25. This initial BOQ doesnt consider backhaul equipment, power supplies, and installation miscellaneous that would be part of the low-level design.

Table 25 Design example bill of quantities

Dependencies with other tasks

Prerequisites

• RF Configuration The overall number of sites and configuration of each site are required to calculate the total quantity of RF equipment.

4.3NaaS Operator E2EProcess Definition

The NaaS operatorcan use the generic process design as a base to develop its own versionaccording to its limitations and constraints. A deep analysis of the processcan be performed to adapt the generic process.

Analyzing the provided generic processdesign, activities can be classified into two groups:

One-time activities Tasks tobe done only one time during the design process. These only require resourceconsumption at the beginning of the process. In the provided process, one-timeactivities are all activities except for RF configuration and site locationvalidation, which are part of the feedback activities.

Feedback Activities Tasks that can be made more than one time due tofeedback received from other modules. These will consume most resources duringthe design phase. In the provided process, feedbackactivities are RF configuration and site validation. External modules thatinteract with these processes are: site survey and transport HLD.

The approach presented in this section willfocus on continuous activities as they consume the majority of the resources. Someguidelines follow that the NaaS operator should consider to customize its ownprocess:

Preprocessing of one-time activities One-timeactivities should be done at the beginning of the process to refrain fromconsuming resources.

Its highly recommended that the NaaSoperator execute a critical path analysis over its process version to furtheroptimization. The methodology to perform a critical path analysis can be foundin the corresponding module.

5HLD Recommendation

Methodology to consolidate and generate afinal HLD recommendation.

5.1HLD RecommendationFormat & Structure

The main deliverable is the HLDrecommendation that contains the overall technical solution, basic designrules, technologies, and concepts required to describe RAN. The HLDrecommendation must contain the following aspects:

Overview A high-leveldescription that summarizes the RAN design.

RAN Solution Design Presentthe description of main scenarios to be implemented duringthe deployment phase.

RF Equipment BOQ Primary input for RF equipmentpurchase order generation.

5.2HLD RecommendationGeneration

Generation of the HLD recommendationfollowing the format and structure established. The NaaS operator can use the HLD Report Template asa reference to create its own version.

1. RAN Network LLD Introduction

Low-Level Design (LLD) for the Radio Access Network (RAN) refers to RAN equipment and antenna selection, detailed design of the base station configuration (setting azimuth and tilt values) and the parametrization of the Radio Access Technology (RAT). The RAN LLD impacts on the overall performance of the access network and is the last engineering step before deployment. This raises the necessity for the development of an LLD that efficiently integrates HLD inputs and NaaS Operator requirements into a cost-effective design.

The RAN LLD Module provides the NaaS Operator with instructions for RAN equipment evaluation and selection as well as background information and methodologies to elaborate a detailed design and parametrization of new base stations to be integrated into an existing network or in a region without existing sites. This module focuses on providing a generic end-to-end process flow that can be tailored to match the specific NaaS environment.

Main deliverables that the NaaS Operator will be able to generate through the use of this module are site Data Fills and Configuration Baseline, which are basic documents for the commissioning and integration of new radio sites. In addition, this module will guide NaaS Operator through the process of generating an LLD report to facilitate future network re-configuration and optimization.

1.1 Module Objectives

This module will enable a NaaS Operator to stand-up, run and manage a RAN LLD initiative. The specific objectives of this module are to:

1. Provide an information base and fundamentals to perform the tasks associated with RAN LLDs.
2. Provide detailed how-to instruction on the key RAN LLD engineering tasks.
3. Provide an overview of the end-to-end RAN LLD process with instructions for tailoring to specific NaaS environments.
4. Provide guidelines to develop a formal RAN LLD recommendation.

1.2 Module Framework

NaaS Runbooks Framework shown in Figure 1 displays the PlayBook Modules and their relationship to the RAN LLD.

The Strategic Plan & Scope and High-Level Network Architecture modules provide the business and technical context for the NaaS Operator and have direct impact and influence on many aspects of the Network Design.

The RAN LLD Module is included within the Network Design Area. It takes inputs from the RAN HLD and the output generated serves as the required input for the Civil & Power Design module.

Figure 1. PlayBook Framework.

Figure 2 presents the RAN LLD functional view where the main functional components are exhibited. Critical module inputs are further described and examined in section 2.2. In addition, guidance and methodologies to execute the tasks included within each function are described in Section 3.

Figure 2. Overlay RAN LLD Module Functional view.

2 LLD Fundamentals

This section provides a general overview of the baseline concepts to develop an LLD RAN Design.

2.1 Low Level Radio Access Network Environment

Once the High-Level Design (HLD) process is carried out, the NaaS operator will have a general overview of the overall Deployment: number of sites and their configurations. The RAN Low-Level Design (LLD) process focuses on refining the RAN HLD proposed configurations and analyzing their performance by obtaining plots that will help the designer in finding opportunity areas to improve the performance of each site’s network. These analyses may involve certain iterations until the designer finds the configuration that maximizes performance results.

Additionally, during the LLD, the NaaS operator must select the equipment and establish the basic parameter to commission a RAN site. Such parameters will be introduced in section 2.3. These parameters will be consolidated in the Data Fill and Network Baseline, whose elaboration will be presented in sections 4.2.6 and 4.2.7 respectively.

RAN LLD is a crucial part of the design process as it sets the final configuration values of the RAN elements. A correct RAN LLD shall minimize optimization tasks and provide a quick time to market of the NaaS initiative, providing a good user experience from network launch.

2.2 Low-Level Radio Access Network Design Inputs Description

Table 1 presents a description of module input data and candidate sources required for a RAN LLD. Furthermore, the impact of each input on the design process is examined.

Table 1. Low-Level Design process inputs summary.

2.3 LTE Air Interface Fundamentals

Long Term Evolution (LTE) air interface is heavily influenced by the requirements for achieving high peak transmission rates, spectral efficiency, and being able to support multiple channel bandwidths (1.4, 3, 5, 10, 15, and-20 MHz) across several operational bands. For a complete table with 3GPP defined frequency bands, please refer to Annex A of the RAN Architecture Module. Figure 3 summarizes carrier bandwidths and spectrum bands used from a coverage and capacity point of view.

Figure 3.Characteristics of spectrum bands and carrier bandwidths.

The specific center frequency for each carrier is not pre-defined within each band. Thus, it is necessary to restrict the locations of the carrier centers for management purposes. With this objective, each carrier in an LTE network is identified within its own frequency band by an attribute called E-UTRAN Absolute Radio Frequency Number (EARFCN).

EARFCN is used to determine the exact frequencies for downlink (DL) and uplink (UL) transmission.

Estimation of the Downlink and Uplink frequencies ( and , respectively) is made through the following equations:

(Eq. 1)

(Eq. 2)

Where:

• Downlink EARFCN
• Uplink EARFCN
• Low part of the downlink band
• Low part of the uplink band
• Offset used to calculate downlink EARFCN
• Offset used to calculate uplink EARFCN

Table 15 in Annex A displays values required for and computation.

Equations 1 and 2 can be used to obtain the EARFCN from NaaS Operator DL and UL frequencies. The following steps can be used to determine the EARFCN of a given operating band and operating cell bandwidth (both defined in the RAN Architecture Module).

1. Considering cell bandwidth, locate the center of the spectrum block available. Two cases can rise from this step:
1. Cell bandwidth is exactly the bandwidth available in the available block.
   In this case, the cells center frequency must be located exactly at the middle of the available bandwidth as shown in Figure 4.



Figure 4. Frequency center location when cell bandwidth and spectrum block bandwidth are equal.

2. Cell bandwidth is smaller than the available bandwidth.
   In this case, the cell center must be placed in such a way that the end of the cell bandwidth meets the end of the operating band bandwidth as shown in Figure 5.



Figure 5. Frequency center location when cell bandwidth and operating band are different.

2. Once cell centers are known, the EARFCN calculator widget can be used to compute the corresponding EARFCN for both DL and UL frequencies.

The LTE air interface implements several techniques to fulfill the high transmission rates and high spectral efficiency requirements, among which, the most important are:

• Orthogonal Frequency Division Multiplex (OFDM) as the basis for access techniques.
• Multiple Input Multiple Output (MIMO) technique for transmitting and receiving multiple data streams simultaneously.

These techniques have a major impact in how radio resources are distributed among the air interface. Deeper insight into the specifics of the LTE air interface can be found on the LTE Air Interface basics primer.

Finally, there is an important aspect of the air interface that is used to achieve user equipment (UE) synchronization to the eNodeB or base station: synchronization signals which are the Primary Synchronization Signal (PSS) and the Secondary Synchronization Signal (SSS).

A User Equipment (UE) wishing to access the LTE system follows a cell search procedure that includes a series of synchronization stages by which the UE determines the time and frequency parameters that are necessary to demodulate downlink signals, to transmit with correct timing and to acquire some critical system parameters. The detection of the PSS and the SSS allows the UE to complete time and frequency synchronization and to acquire basic system information such as Cell Identity, decode broadcast channel, etc.).

The combination of the different values of PSS and SSS produce a parameter named Physical Cell Identity (PCI) which is a cell identifier. There are 504 unique PCIs available. These identities are organized in 168 groups of 3. A PCI is thus uniquely defined by the number in the range of 0 to 167 (PCI group) and the number in the range of 0 to 2. Then, a PCI is built following the next equation:

(Eq. 3)

PCI parameter is a key part during LTE planning as it uniquely identifies between cells in the network and collision between cells with the same PCI will be reflected in service degradation. Instructions for its planned allocation will be given in section 3.1.2.

There exist other Low-Level parameters that are part of the configuration of the RAN equipment. However, these parameters are out of the scope of this section as the general recommendation for NaaS operators in the early stages is to follow the default recommendation provided by the RAN equipment vendor.

2.4 Antenna Basics

Antennas are one of the main building blocks of a base station as they transform electrical signals into electromagnetic waves and vice versa allowing for wireless communication. Antennas are considered to have a reciprocity property, which means that an antenna will maintain the same characteristics regardless if it is transmitting or receiving. Main antenna characteristics to be considered during a mobile network deployment are:

• Antenna Directivity and Gain

Directivity is the ability of an antenna to focus energy on a particular direction when transmitting, or to receive energy better from a particular direction when receiving. This means that it is possible to use a directive antenna to concentrate the radiated signal in the wanted direction. Antennas can be classified into two types regarding their directivity:

1. Omnidirectional antennas: These antennas radiate in all directions (360 coverage) in the horizontal plane. Omni directional antennas are most used in small cell deployments for indoor or low coverage/capacity scenarios. Representation of an omni directional antenna is shown in Figure 6.



Figure 6. Omnidirectional Antenna. a) Side View, b) Top View.

2. Directional antennas: These antennas concentrate their energy on a single direction, making them ideal when coverage is required on a specific area of the whole region. Representation of an omni directional antenna is shown in Figure 7.



Figure 7. Directional Antenna. a) Side View, b) Top View.

The gain of an antenna is a rather complex concept that can be summarized as the amount of energy radiated in an specific direction compared to the energy that an ideal isotropic antenna would radiate in the same direction when driven with the same input power. Antenna gain results in an increase in the radiated power due to energy focusing.

Therefore, a relationship between antenna directivity and gain can be observed: the more directive the antenna is, the higher its gain, thus, the greater distance it will be able to achieve in a particular direction. On the other hand, an antenna with low directivity (omnidirectional) will have a lower gain.

• Radiation Pattern and Antenna Beamwidth

Radiation pattern describes how the strength of the radiated energy is distributed across all antenna directions. The radiation pattern is also a reception pattern, due to the reciprocity principle of antennas.

As can be assumed, the radiation pattern is a three-dimensional representation of the radiated energy, however, the two must useful views are the vertical view (like if seen the antenna from one side) and horizontal view (like if seen from top of the antenna). Figure 8 shows radiation partners for an omnidirectional antenna while Figure 9 shows radiation pattern for a directional antenna.



Figure 8. Omni Directional Antenna radiation pattern. a) Horizontal pattern, b) Vertical pattern.



Figure 9. Directional Antenna radiation pattern. a) Horizontal pattern, b) Vertical pattern.

Size of the horizontal and vertical views are measured in degrees and are called Horizontal and vertical beamwidth. Commonly, horizontal beamwidth can span from 45 to 85, depending on the deployment scenario: 75 to 85 antennas for two sector sites and 65 antennas for three sector sites.

Regarding vertical beamwidth, 15 is a common value used for most mobile networks.

• Antenna Tilt

Antenna tilt represents the inclination of its vertical radiation pattern with respect to its axis. There are two types of Tilt:

• Mechanical tilt: This tilting is achieved through specific antenna accessories (like mounting brackets) to physically modify antenna inclination. Figure 10a shows the principles of mechanical tilt.
• Electrical tilt: This tilt is achieved by changing (using electronic components inside the antenna) signal phase of each element of the antenna. Figure 10b shows the principles of electrical tilt.



Figure 10. Antenna Tilting. a) Mechanical Tilt, b) Electrical Tilt

Final value for antenna tilt is the addition of both mechanical an electrical tilt.

3 Functions & Methodologies

This section presents various methodologies to perform critical tasks/subtasks involved in the RAN LLD process. Once NaaS operators have gone through these methodologies, they will be able to perform all activities in the End-to-end process flow.

3.1 Configuration Refinement

In order to have a radio configuration completely defined, it is required to define sector azimuth, tilt, and Physical Cell Identity (PCI) for each cell. This section will provide a methodology to define these parameters.

3.1.1 Azimuth and Tilt Definition

Setting antenna parameters such as azimuth and tilt is a key step in the network design as they will impact on the RF coverage and signal quality at a user equipment (UE). The azimuth of an antenna refers to the orientation (in degrees) of the antenna where the radiation lobe is pointing to. On the other hand, antenna tilt refers to the inclination of the antenna in order to get the desired coverage radius. These parameters are shown in Figure 11.

Figure 11. RF Configuration. a) Antenna Tilt, b) Antenna Azimuth.

As a result of the RAN HLD process, a high-level network dimensioning is obtained. This dimensioning provides the number of required sites and their configuration to cover an area: location, transmitter height, transmitter power and number of sectors per site. This HLD RAN configuration can be modified during the Site Configuration Refinement step (discussed in section 4.2.2) to achieve or improve network performance based on final selection of RAN equipment which is addressed in in Section 4.2.1.

However, to analyze RAN configuration performance, additional parameters are required. These parameters are antenna azimuth and tilt.

The process to establish these parameters is shown in the following steps.

• Antenna Azimuth: If the site has an omnidirectional antenna, it is not necessary to assign an azimuth as the antenna provides 360 coverage by definition. For sector antennas, the azimuth must be established in such a way as to cover the areas and coverage objectives established in the HLD: schools, hospitals, government buildings, etc.

To set the azimuth of a site, the site needs to be located in the GIS tool (e.g. Google Earth). Then, identify the coverage area or the specific coverage objective as shown in Figure 12.



Figure 12. Coverage area example.

Designer must take care not to overlap antenna azimuths of antennas in the same site. Separation between antenna azimuths must be of at least equal to the horizontal beamwidth.

Finally, using the distance tool, measure the direction from the site to the center of the coverage area and take note of the required degrees as shown in Figure 13. This value will be the azimuth required for the antenna.



Figure 13. Establishment of the antenna azimuth using Google Earth.

• Antenna Tilt: Based on the coverage radius calculated in the HLD, it is possible to determine the antenna inclination required to achieve the target coverage. Typical tilt values range from 0 to 5 and its definition can be done following two recommendations:
1. An antenna can be given a 0 tilt if the site or the sector is isolated, this means, it has no other site or sector near to it. In this way, coverage can be maximized. In particular, 0 tilts are commonly used in rural environments to expand coverage as much as possible.
2. When the site or sector is not isolated or is placed on a very high location, tilt must be > 0 so it doesnt interfere with neighbors coverage. However, tilts should be kept below 5 to preserve some coverage overlap for handover.

Using the HLD results, selected equipment characteristics and the GIS tool, antenna mechanical tilt can be computed as displayed in Figure 14.



Figure 14. Required information for antenna tilt calculation.

Where:

• h Antenna Height from the ground (obtained from the HLD configuration).
• H Terrain Elevation at base station location (obtained from the GIS tool).
• ha Area Elevation: Elevation of the target coverage area (obtained from the GIS tool).
• C Cell Coverage Radius (obtained from the HLD configuration).
• aBW Antenna Vertical Beamwidth: will depend on the antenna model characteristics. However, most sectorial antennas are built with 15 vertical beamwidth. This value can be used in a first iteration.
• A Angle of incidence.

First step is to compute total antenna height (TH) as follows:

(Eq. 4)

Next, difference between Total Height and area height is computed:

(Eq. 5)

Angle of incidence can be obtained from:

(Eq. 6)

In order to obtain the result in degrees, the angle of incidence must be converted from radian as shown:

(Eq. 7)

Finally, antenna tilt is obtained using the following equation:

(Eq. 8)

Where:

Is the antenna electrical tilt.

NaaS Operator can use the Antenna Tilt Calculator widget for this task. If computed tilt is > 5, it is recommended to low it down to 5.

Overlapping areas between adjacent sites is required for mobility purposes (handovers). However, overlapping must not be grater that 20% of the cell coverage area in order to avoid too much interference and the ping-pong effect in the UE.

3.1.2 Physical Cell Identity Planning

LTE considers 504 unique physical cell identities (PCIs) organized in 168 groups, each one containing up to 3 PCIs.

Cells with the same PCI must be isolated as much as possible (distance between two cells with the same PCI must be maximized) in order to ensure that the UE never simultaneously receives the same identity from more than a single cell.

There are several ways and algorithms to distribute the PCIs in a network, however, in rural environments that require few sites to provide coverage and / or the distances between sites are very large, the allocation of PCI can be simplified to comply with the following recommendations:

• Maximize distance between cells with the same PCI.
• Cells belonging to the same eNodeB (not omnidirectional sites) should be allocated identities from the same group (modulo 3 rule).
• Reserve a group of PCIs to allow for future network expansion.
• NaaS Operators should achieve some level of coordination across international borders when allocating physical layer cell identities on sites near country borders.

Figure 15 displays an example of PCI allocation.

Figure 15. PCI Allocation example.

3.2 Radio Planning Tool Configuration

A Radio Planning Tool (RPT) helps the NaaS operators to generate the required performance plots (coverage, throughput, and signal quality) required to analyze the performance of the network and see which areas can be enhanced. Plots will also allow to define neighbor cells by showing which sites present overlapping coverage. If at this point, the NaaS Operator has not selected an RPT, please refer to Section 3.6 of the RAN HLD module.

Budget constraint NaaS Operators may not have access to an RPT. In such cases, the NaaS Operator can work only with HLD link budget results and refined configurations which will be enough to deploy the site but with the risk of sub-optimal performance.

Each RPT will have its own steps for project configuration. However, a generic process for RPT configuration is described below:

• Set the existing terrain and network information: Load to the RPT the following information:
1. Terrain Clutter. Clutters are commonly provided by a 3rd party company specializing in GIS/mapping. If not available or considered too expensive, height maps will be enough.
2. Height maps from 3^rd Party companies or open source data from geological institutes (e.g. USGS/NASA SRTM data)
3. Existing Network configuration: location, antennas height, number of sectors, transmitter power, azimuths, and tilts.
• Set radio parameters for each site: Operating frequency, cell bandwidth and the highest available Modulation and Coding Scheme (as defined in the RAN Architecture Module and RAN Equipment Datasheets).
• Set site gains and losses: antennas gain (from vendor specifications) and equipment losses (cables, fibers, etc.).
• Set the region or boundary to perform the calculation. RPT needs to have a delimited area where to simulate the required calculation.
• Set new sites configurations (obtained from the HLD): new site coordinates, antennas height, number of sectors, transmitter power, azimuths, and tilts (as computed in section 3.3).

3.3 Coverage, Throughput, SINR and Best Server Plots Generation

Radio Planning Tools can generate several performance plots (depending on the RPT). However, there are some plots that are recommended to be generated in order to have an overall view of the network performance:

• Coverage plots: These plots show the signal strength across the target coverage area. LTE Reference Signal Received Power (RSRP) is the indicator to be plotted to analyze coverage.

As a reference, Table 2 displays a relation between RSRP ranges and signal strength.

RSRP	Signal Strength
>-80 dBm	Excellent
-80 dBm to -90 dBm	Good
-90 dBm to -100 dBm	Fair
-100 dBm to -110 dBm	Poor
<-115 dBm	No Signal

Table 2. LTE RSRP reference values.

Figure 16 displays an example of a coverage (RSRP) plot.



Figure 16. LTE Coverage (RSRP) plot example (values in dBm).

• Throughput Plot: RPT can simulate the throughput that can be achieved throughout the coverage area, enabling the identification of areas that will struggle in terms of user experience. Figure 17 displays an example of a Throughput plot.



Figure 17. LTE Throughput Plot (values in Mbps).

• Signal Quality Plot: Sometimes an area may appear to be correctly covered by the base station, however, the users may experience bad signal quality, which reflects on connection drops due to interference from other cells. For this reason, it is important to analyze the Signal to Interference plus Noise Ratio (SINR).

As a reference, Table 3 displays a relation between RSRQ ranges and signal quality.

RSRQ	Signal Quality
>-10 dBm	Excellent
-10 dBm to -15 dBm	Good
-15 dBm to -20 dBm	Fair to Poor
<-20 dBm	No Signal

Table 3. LTE RSRQ reference values.

Figure 18 displays an example of an SINR plot.



Figure 18. LTE Signal Quality (SINR) example (values in dB).

• Best Server (Overlapping) Plot: Sometimes, the area which is intended to be covered by one cell may be covered by another cell too (interfered). In such cases, SINR is low in the desired region. Best Server plot shows the region for which each cell provides the highest SINR. This plot is useful to study overlapping between cells of the same site or from other sites. Figure 19 displays an example of a Best Server plot.



Figure 19. LTE Best Server Plot (values are PCIs).

Performance plots are useful as they serve to find areas where the configuration can be improved. For instance: a region covered by a single site can present acceptable coverage values, but it can suffer low SINR due to interference with adjacent sites. This will be displayed as an unwanted overlapping between two sites that can degrade user experience. In such cases, site configuration must be modified to reduce the overlapping. The following steps are recommended to be followed until performance plots provide an acceptable result:

1. Electrical Tilt
2. Mechanical Tilt
3. Transmitter Power
4. Antenna Height
5. Site Location

Deeper plot analysis will be done as part of the design example shown in section 4.2.1.

Each RPT will have its own steps for plot generation. However, a generic process for the generation of the performance plots is shown below:

1. Every RPT shall have a menu to select a plot type. The required plot to be generated in this step must be selected.
2. Generate a Baseline plot of the existing network (in an overlay scenario). This will show a before and after state of the network.
3. Set the color patterns and thresholds required for each plot.
4. Use the options provided by the RPT tool to generate the configured plot.
5. Once the simulation is finished, the result can be exported in a format such as image (jpg), table (xml) or GIS document (kml).

3.4 Neighbor Planning Definition

Neighbor planning involves the identification of the adjacent cells for a specific radio element. These adjacencies are used to inform the UE the cells to search for when completing handovers and cell reselections. In general, UEs are limited to the mobility routes defined by the neighbor list and missing neighbors can cause connections to drop.

This section provides instructions for manual neighbor management. However, some equipment models provide Self Organizing Network (SON) functions for an automatic neighbor management like the Automatic Neighbor Relationship (ANR) functionality. The importance of SON functionalities increases when the deployment involves a high number of sites which are close to each other. However, in rural environments, where sites tend to be far from each other or completely isolated, the manual procedure is enough for the neighbor planning task.

Each cell neighbors must be defined by following the next steps:

1. Assign a number (1,2 or 3) clockwise to each sector (in case it is an omnidirectional site, only number 1 will be assigned) as summarized in Figure 20.



Figure 20. Cell numbering.

2. Co-site: Assign co-site neighborhood (on the same site) within the same site following an ascending order. Figure 21 displays an example of Co-site neighbor definition.



Figure 21. Co-site neighborhood definition.

3. Inter-RAT Scenario: In the case that other RATs exist at the same site, NaaS operators must review how priority is being made on the existing RATs. Then, new cells must be configured for Inter-RAT relations. Figure 22 shows an example of inter-RAT relations definitions in a 3G +LTE RATs in the same site.



Figure 22. Inter-RAT co-site neighborhood definition.

4. Adjacent Sites: In case there is overlapping coverage of two or more adjacent sites, those overlapping cells must be registered as neighbors. Overlapping coverages are obtained after the best server plot analysis.

3.5 Mobility Management Definition

Mobility is an important procedure to ensure that users can move freely within a network while keeping connectivity. The LTE mobility can be divided in:

• Intra-LTE mobility:
  This applies for mobility between LTE cells whether operating in the same frequency (Intra-frequency) or in different frequencies (Inter-frequency). However, the use of several frequencies in rural scenarios is not usual, thus Inter-frequency mobility management is out of the scope of this module.
• Inter-RAT mobility:
  This applies when LTE cells will be interacting directly with other Radio Access Technologies such as 2G-GSM or 3G-UMTS. This interaction is present in scenarios where LTE is deployed over existing 2G or 3G sites (overlay). In such scenarios interaction is required if the NaaS Operator plans to provide voice services via Circuit Switched FallBack (CSFB) or when LTE coverage is poor and the User Equipment (UE) may switch to a lower Radio Access Technology (RAT).

Figure 23 summarizes LTE mobility scenarios.

Figure 23. LTE Mobility scenarios summary.

The main task of mobility management is to establish priority values for each cell. Priority ranking method is used in mobility management to assign each carrier a number (ranking) which helps the UE to select an adequate cell to attach to. Ranking logic may vary from vendor to vendor; however, they usually follow the same logic: lower ranking means lower priority and higher number means higher priority. Most cases, ranking goes from 0 to 9.

The following subsections will provide guidelines to define priority rankings for mobility management for both Intra-LTE and Inter-RAT strategies based on NaaS Deployment scenarios.

3.5.1 Intra-LTE Mobility Rules Definition

Intra-LTE mobility can be classified in two:

• Intra-frequency: Mobility between cells with the same frequency in the same site or in different sites.
• Inter-frequency: Mobility between cells with different frequency. To have extra frequencies in the same network allows for capacity and/or coverage expansion. However, this case is out of the scope of this module as it is not usual to use two frequency bands in a NaaS Deployment for rural environments.

Most rural environments are deployed with one cell per sector, in consequence, all cells must have the same priority in order to guarantee a smooth mobility between cells (in the same site or in different sites). As a best practice, it is recommended to set a priority lower than the maximum allowed (i.e. 7) in order to leave space for capacity expansions.

3.5.2 Inter-RAT Mobility Rules Definition

In the cases where CSFB is enabled, it is necessary that the UE returns to LTE once the voice connection with 2G or 3G has ended. In order to achieve this behavior, a low priority must be set in the 2G / 3G cells and a high priority for LTE cells. In such cases, priority ranking is used to ensure that devices reconnect to LTE (highest priority) from 2G or 3G (lowest priority) when LTE coverage becomes available.

Table 4 shows how to set priorities in an Inter-LTE scenario.

System Cell	Value	Comment
LTE EUTRAN	7	LTE shall be the highest priority RAT
3G UMTS UTRAN	6	UMTS shall be the middle priority
2G GSM GERAN	5	GSM shall be lowest priority

Table 4. Priority ranking for Inter-LTE mobility.

3.6 Features Parametrization

Feature parametrization for NaaS deployments, should follow recommendations and guidelines provided by RAN equipment vendors as the details may vary from one vendor to another. However, in order to get a site on air, all the basic parameters can be set to the recommended value (as shown in each vendor documentation). This will assure that the network will be operating according to vendors best practices and recommendations, improving the time to get each site on air.

In addition, the steps below must be followed in order to assure that the network will be working as defined in the RAN Architecture module:

1. Check that all the features that are part of the basic package provided by the vendor are activated.
2. Activate all the features required as per RAN Architecture module: CSFB, VoLTE, additional Modulation schemes, RAN Sharing, etc.
3. CSFB, handover parameters and SON functionalities must be set based on mobility and neighboring configurations (section 3.1 and 3.2 respectively).

4 E2E Process Flow

This section presents a generic yet customizable end-to-end process flow to perform the Radio Access Low-Level design for the RAN.

4.1 End-to-end Process Overview

A generic end-to-end (E2E) process flow is shown in Figure 24. This process flow orchestrates general tasks and subtasks to perform the RAN LLD in a logical and well-structured sequence.

Figure 24. RAN LLD Generic E2E Process Flow.

RAN Low-Level Design starts with the RAN Equipment Selection is performed to evaluate between multiple vendor alternatives to define which options fits best in the NaaS Deployment, including eNodeBs (RRU and BBU) and antennas. Then, Site Configuration Refinement of the radio configurations proposed in the RAN HLD. Once configuration has been done, Performance plots are generated and analyzed to study network performance and, if required, modify radio configurations. After the analysis of the performance plots, the RF Planning Strategy for PCI allocation, Neighbor Strategy and a Mobility Strategy for each site and cell in the network can be defined. Naming Convention Establishment defines naming rules (nomenclature) to uniquely identify each eNodeB and each cell in the network.

Data Fill Generation will create a document containing eNodeBs basic information required for its integration. Network Parametrization focuses on the generation of a baseline that will be used to configure all sites in the network. Master Database Update will add the values resulting from the overall process to the existing Master Database built during the HLD process. Finally, HLD Bill of Quantity (BoQ) will be updated into a final Bill of Materials (BoM) containing the final equipment to be deployed at each site.

4.2 Step-by-Step Analysis

This section presents an examination of each of the steps involved in the E2E process to identify, isolate, and describe the range of implementation options on the path towards customization based on NaaS Operator requirements and constraints. Dependencies among tasks are addressed in the corresponding subsection.

4.2.1 RAN Equipment Selection

NaaS operators must perform the selection of the RAN Equipment from multiple vendor alternatives. The complete process to select the RAN Equipment is included within the Procurement Module (RFx Process Module). This section focuses on the technical aspects to perform the evaluation of transport equipment from different vendors.

From the technical perspective, Table 5 displays the typical requirements that the RAN equipment must satisfy which must be defined according to the final radio configuration.

	Evaluated Characteristics
Antenna	Gain
	Electrical Tilt
	Horizontal beam width
	Vertical beam width
	Mounting Options
Radio unit	Transmitter power
	Operating Band
	Mounting Options
	Maximum number of supported sectors with a single Radio unit
	Operational Bandwidth
	MIMO Scheme
Baseband	Maximum Supported users (simultaneous RRC connections)
	Maximum supported throughput
	Maximum number of supported sectors
Features support	CSFB, VoLTE, C-RAN support
Dimensions	Equipment Dimensions and physical characteristics
Power Requirements	Power consumption profile
Environmental Protection	IP (Ingress Protection) certification
Price	Equipment price

Table 5.Typical specifications to be evaluated in RAN equipment.

The decision to select the RAN Equipment is also affected by the financial constraints of the project. The final selection of the RAN Equipment is performed during the RFx process and in conjunction with the Procurement Team.

Additionally, the Naas operator can use the RAN Equipment Evaluation Matrix Template to support in the technical evaluation of different RAN equipment.

Design Example

Table 6 displays a comparison of two generic vendors as a matter of example (power consumption and prices are an assumption):

Table 6. Design Example RAN Equipment evaluation.

Based on the data above, vendor 1 has better performance in both Radio and Baseband units than vendor 2. However, these enhanced capabilities come with a higher price. In addition, as the NaaS Deployment is taking place on a rural environment, performance provided by vendor 1 is unnecessary and will not be exploited as it can be.

From this analysis it is concluded that configuration offered by vendor 2 suits better with the design example deployment.

4.2.2 Site Configuration Refinement

Refinement of the proposed configurations in the RAN HLD process is required to be done during the RAN Low-Level Design as it adds the required values for antenna azimuth and tilt of each site. The required data to compute these values, such as maximum transmitter power, antennas vertical beamwidth and electrical tilt is obtained from the specifications of the selected equipment in the previous step..

These values together with the ones obtained during the RAN HLD process (such as site coordinates, site height and transmitter power) are required to generate the performance plots. As mentioned in section 3.3, these plots will be used to analyze the site’s performance and make any required modifications if poor coverage, low quality or bad throughput are present.

Figure 25 displays the process to be followed for the generation of the performance plots and final site configurations.

Figure 25. Performance Plots generation process.

With the proposed site configurations from the RAN HLD process, each site azimuths and tilts must be estimated following the methodology presented in section 3.1. Then, the RPT must be configured as sketched in section 3.2. Finally, performance plots must be generated to validate network performance.

However, as mentioned in section 3.2, NaaS Operatory may not have access to an RPT. If the deployment area is in a rural environment or no overlapping zones coverage are defined (sites close to each other), then NaaS Operator may work only with the defined azimuths and tilts using the GIS tool.

After plot analysis, the designer may decide to change site parameters (azimuth, tilts, height, etc.) if the current configuration is failing to deliver appropriate results. Bad performance results can be:

• Lack of coverage on the desired area
• Bad throughput distribution
• Poor signal quality (poor SINR).

In such cases, new configurations must be proposed generating new performance plots until acceptable results are obtained. This process may represent a huge time investment but is of vital importance as these results will represent the final site configurations and the results must be good as possible in order to maximize network performance.

In order to show the implementation of the network design process, a Design Example is developed throughout all the steps of the process.

Design Example

Input for this example is composed by the three target coverage areas shown in Figure 26.

Figure 26. Design Example Coverage Areas and Proposed Sites Location.

As part of the inputs, the RAN HLD defines two sites to cover the desired areas. Table 7 displays HLD configurations of each site.

Table 7. Design Example Site Configurations.

Azimuth Definition:

Using Google Earth, azimuth for each site is obtained as depicted in section 3.1.1. Figure 27, Figure 28, and Figure 29 display the results for the Design Example.

Figure 27. Sector 1 / Site 1 Azimuth definition for first coverage area.

Figure 28. Sector 2 / Site 1 Azimuth definition for second coverage area.

Figure 29. Sector 1 / Site 2 Azimuth definition for the third coverage area.

Azimuth values for each site are shown in Table 8.

Table 8. Design Example Azimuth values.

Tilt Definition:

1) Site 1 has the following values:

• Sector 1:
• Antenna Height: 20m
• Terrain Elevation: 75m
• Area Elevation: 74m (average)
• Cell Coverage Radius: As this sector does not has any other sector nearby, coverage shall not be limited to a certain radius.
• Antenna Vertical Beamwidth: 15
• Antenna Horizontal Beamwidth: 65
• Antenna Electrical Tilt: 2
• As coverage is not limited, Sector 1 can have a 0 tilt.
• Sector 2:
• Antenna Height: 20m
• Terrain Elevation: 75m
• Area Elevation: 70m (average)
• Cell Coverage Radius: 500m
• Antenna Vertical Beamwidth: 15
• Antenna Horizontal Beamwidth: 65
• Antenna Electrical Tilt: 2
• Using the Antenna Tilt Calculator widget, Site 1 mechanical tilt results in: 8.3. Thus, assigned tilt will be 5.

2) Site 2 has the following values:

• Antenna Height: 20m
• Terrain Elevation: 46m
• Area Elevation: 50m (average)
• Cell Coverage Radius: 500m
• Antenna Vertical Beamwidth: 15
• Antenna Horizontal Beamwidth: 65
• Antenna Electrical Tilt: 2
• As coverage is not limited, Sector 1 can have a 0 tilt.
• Using the Antenna Tilt Calculator widget, Site 2 mechanical tilt results in: 7.3. Thus, assigned tilt will be 5.

Complete site configuration is shown in Table 9.

Table 9. Design Example complete site configurations.

For the design example, Atoll was used for the generation of the performance plots. Atoll was configured using a clutter and a heights map corresponding to the area under study (El Salvador) obtained from a specialized GIS company. Figure 30 displays the location of the design examples sites on Atolls configured project map.

Figure 30. Design Example on the configured RPT.

Performance Plots Generation:

1) Coverage plots:

– Site 1, Sector 1:

Figure 31 displays the coverage plot for sector 1 of site 1. It can be noticed that with refined configuration, the region of interest is covered with good coverage values.

Figure 31. Coverage plot for Sector 1 of Site 1.

– Site 1, Sector 2

Figure 32 displays the coverage plot for sector 2 of site 1. As in sector 1, it can be noticed that sector 2 refined configuration good coverage values are obtained withing the required region.

Figure 32. Coverage plot for Sector 2 of Site 1.

– Site 2, Sector 1

Figure 33 displays the coverage plot for sector 1 of site 2. This case also presents good coverage among the required coverage zone.

Figure 33. Coverage plot of Sector 1, Site 2.

Figure 34 displays a before and after of the three coverage areas.

Figure 34. Design Example Coverage Plot comparison.

2) Throughput plot:

Figure 35 displays the throughput plot for the design example.

Figure 35. Design Example Throughput plot.

Overall throughput distribution on the desired areas appears to be well distributed among all the desired areas based on the throughput plot.

3) SINR and Best Server (Overlapping plots):

SINR plot for the design example is displayed in Figure 36.

Figure 36. Design Example SINR Plot.

It can be noticed that SINR is high between sectors of site 1 (upper part of the image). However, poor SINR values are visualized inside Area 3, which lead to a bad overlapping as displayed in Figure 37.

As discussed in section 3.3, overlapping areas are required for mobility to be possible between sector. However, overlapping areas must be out of the main coverage area to avoid ping-pong effect in the UE.

Figure 37. Design Example Best Server (Overlapping) plot.

It can be noticed that overlapping is happening across Area 3, which is an unacceptable result. A way of improving this situation is by modifying Sector1/Site2 electrical tilt by augmenting its tilt in order to mitigate impact from Sector2/Site1 into Area 3.

For this design example, electrical tilt was augmented from 2 to 4. Resultant coverage is shown in Figure 38.

Figure 38. Modified Design Example Best Server (Overlapping) plot.

It can be noticed that, with the refined configuration, overlapping between Site1 and Site2 occurs almost out of both Area 2 and Area 3, which is an expected good result as each area will be covered by its corresponding site.

Final configuration for each site is shown in Table 10.

Table 10. Design Example final configuration results.

4.2.3 RF Planning Strategy Definition

PCI allocation may seem to be a random process due to the low number of sites/cells and the fact that in a NaaS Deployment sites tend to be isolated between them. However, it is highly recommended to always keep an order on the allocation of PCIs in order to have a management of used PCIs and available ones for any future expansion in the network.

Designer can follow the next steps for the allocation of the PCIs for each cell:

1. Assigning each eNodeB in the network a group (PCI groups start in 0 and finish in 167) even if the eNodeB is planned to have only an omnidirectional sector.
2. Assign a number between 0 and 2 to each cell. In a NaaS deployment, a site may only have up to three cells, so modulo 3 is enough for PCI allocation.
3. PCI group numbering shall start with group 0 and go in ascending order. This way, good management can be kept on how the allocation will be done for the subsequent eNodeBs.

NaaS Operators can use the PCI Allocation Widget to generate and keep track of the used and available PCIs on its network.

Next step is to estimate cell EARFCN following the steps discussed in section 2.3.

Design Example

The example sites will be assumed to be the first in the network. Therefore, the first available groups will be chosen: group 0 and group 1.

The distribution of PCIs is shown in Figure 39.

Figure 39. Design Example PCI Allocation.

EARFCN calculation:

– Band 8 (900 MHz)

• DL frequency range: 925 to 960 MHz
• UL frequency range: 880 to 915 MHz

– Cell Bandwidth: 10 MHz

Assuming that the whole band is empty, frequency centers will be located at the following locations:

• DL center: 955 MHz
• UL center: 885 MHz

Using the EARFCN calculator widget, the following EARFCN are obtained:

• DL EARFCN: 3750
• UL EARFCN: 21500

4.2.4 Neighbor Strategy Definition

The mobility strategy is defined based on the characteristics of the NaaS Deployment in terms of site adjacencies (how close are sites between them). From these characteristics, two cases can be defined:

• The case where two or more sites will be required to cover a region.
• The case where isolated sites cover an entire coverage region.

Figure 40 shows an example of both cases.

Figure 40. NaaS Deployment cases for Neighbor definition. a) More than 2 sites for a single region, b) One site for a single region.

Based on the defined cases, the methodology shown in Figure 41 may be followed to define the Neighbor strategy per site.

Figure 41. Neighbor Strategy methodology.

Design Example

Neighbor definition for the sites in the Design example is shown in Figure 42:

Figure 42. Design Example Neighborhood representation.

1) Site 1: As shown in Figure 43. Co-site neighborhood was defined between cells 1 and 2. In addition, cell 2 has an interaction between cell 1 of site 2, so this neighbor must be noted as well.

Figure 43. Design Example Neighborhood definition for Site1.

1) Site 2: As shown in Figure 44. Co-site is not present in this case; however, an adjacent neighborhood must be defined (now form site 2 perspective) between cell 1 of site 2 and cell 2 of site 1.

Figure 44. Design Example Neighborhood definition for Site 2.

4.2.5 Mobility Strategy Definition

The definition of mobility priorities will depend on the services to be offered and on network characteristics:

• If circuit switching technologies (2G, 3G) in the network are planned to be used to provide voice services instead of VoLTE, mobility between technologies (Inter-RAT) must be configured in those sites that comply with this characteristic.
• If a NaaS operator plans to offer voice services entirely via LTE, then mobility will only be defined within the same LTE system (intra-LTE).

Design Example

Design example sites operate on a single frequency in the LTE System; thus, it is necessary to define only intra-LTE and intra-frequency interactions. Priority ranking for the design example will be set to 7 (below maximum value) as discussed in section 3.5.1.

4.2.6 Naming Convention Establishment

Every network requires that its main network elements (eNodeB and Cells) have unique names and identifiers for the maintenance, organization, and management of the network. The NaaS Operator needs to establish a Naming Convention (nomenclature) to define the following parameters (these parameters are generic, and the real name will depend on each vendor):

• eNodeB ID
• eNodeB Name
• Cell ID
• Cell Name

The creation of a nomenclature depends on the following two factors:

• Equipment Vendor: Each vendor defines the number and type of characters that are allowed for each of the parameters. Therefore, it is necessary to review vendors documentation to see the restrictions in the nomenclature. For example, a vendor can define the following rules:
• eNodeB ID Six digits between 0 and 9.
• eNodeB Name 20 characters, including only digits, letters (differentiating between upper and lower case) and underscore(_).
• Cell ID Six digits between 0 and 9.
• Cell Name 20 characters, including only digits, letters (differentiating between upper and lower case) and underscore (_).
• NaaS Operator specific rules: NaaS Operator may build its own nomenclature based on the attributes NaaS Operator wants to reflect. It is recommended that the nomenclature integrated different attributes or characteristics of each site. Some of the attributes that can be considered are:
• Region: NaaS Operators can have its territory divided into areas; thus, each region can be assigned a different number.
• Operating Frequency: NaaS Operator can assign different numbers to each frequency to be used. Even if you plan to only use one frequency, it is recommended to define a digit for the operating frequency.
• Base Station type: NaaS Operator may define one digit to identify a Macro Cell and another digit for a Small Cell.
• Sector number (for Cell Name parameter): A number can be assigned to each sector (1, 2 or 3).

It is recommended that the nomenclature for the eNodeB Name and the Cell Name be similar and that they differ from each other by indicating in the Cell Name the sector number to which the cell corresponds. For example:

• eNodeB Name: 4G_Region1_SiteName
• Cell 1 Cell Name: 4G_Region1_SiteName_1
• Cell 2 Cell Name: 4G_Region1_Site Name_2

Design Example

For the design example, the following Naming Convention is defined for each of the parameters:

• eNodeB ID: 1+[X1]+[X2]+[X3]+[XX4]
• eNodeB Name: 4G_[Town Name]_[X1]+[X2]+[X3]
• Cell ID: [X1]+[X2]+[X3]+ [XX4] +[XX5]
• Cell Name: 4G_[eNodeB Name]_[X1]+[X2]+[X3]_[Sector Number]

Where:

• [X1] One digit to differentiate between regions
• [X2] One digit to differentiate between operating frequencies
• [X3] One digit to differentiate between base station types
• [XX4] Two digits to number each eNodeB on the network.
• [XX5] Two digits (first one to be always zero) to number each configured on an eNodeB.

Table 11 displays nomenclature values to be used for naming.

Table 11. Nomenclature values.

For the design example case, Naming for each element results as follows:

Site1:

• eNodeB ID: 122101
• eNodeB Name: 4G_RafaelLazo_221
• Cell 1 ID: 2210101
• Cell 1 Name: 4G_RafaelLazo_221_1
• Cell 2 ID: 2210102
• Cell 2 Name: 4G_RafaelLazo_221_2

Site2:

• eNodeB ID: 122102
• eNodeB Name: 4G_SanDionisio_221
• Cell 1 ID: 2210201
• Cell 1 Name: 4G_SanDionisio_221_1

4.2.7 Data Fill Generation

Data Fill (DF) of a RAN site consolidates all the basic information of an eNodeB that will serve for its integration and turning up process. The basic information that a RAN DF must contain can be divided into the following sections:

• Configuration: All information relevant to site configuration, such as:
• Network Element Naming
• RF Configuration: number of sectors, radio unit model, base band unit model, antenna height, radiated power, azimuth, tilts, etc.
• Neighborhood configuration
• Transport information: Every eNodeB must be configured with information obtained during the TX LLD process. This information is vital for the communication between the RAN and the core network

A Data Fill can be built following two approaches:

• Per-Site DF: This means that each Data Fill will contain information regarding a single site. This approach is useful to have an organized management of the Network Configuration. In addition, it allows any modification to a Site Configuration to be done individually.
• DF for a group of Sites: In this case, one single DF document will contain basic information of multiple sites which can be useful when the network is composed by a large number of sites (above 50) and managing one DF per site will be a complex task.

NaaS Operator can use the Data Fill Template to generate its own version of a Data Fill.

Design Example

The final version of the Data Fill for the Design Example is included as part of the Data Fill Template.

4.2.8 Network Parametrization

Before turning on a site, multiple parameters must be configured (the amount of these depends on the seller). However, most of these parameters can be configured using the default values suggested by the vendor.

Parameters that must be considered with a special value depending on the network configuration are:

• Feature parameters: To be configured based on RAN Architecture feature requirements.
• Mobility parameters: Configured based on mobility rules.

All the basic parameters and features to be activated are consolidated into a single Baseline Document. This Baseline is intended to serve as a base for the integration of all sites in the network.

NaaS Operator can build its own version of the baseline with the Baseline Template.

Design Example

The final version of the Network Parametrization for the Design Example is included as part of the Baseline Template.

4.2.9 Master Database Update

During the HLD process, a master database was generated, which contained the following parameters:

• Physical site configuration: height, number of sectors and transmitter power
• Site Location: Coordinates

This master database must be updated with the results obtained through the LLD process:

• Site and Cell Names
• eNodeB ID
• eNodeB Name
• Cell ID
• Cell Name
• Sector number
• Site Physical Parameters
• Type of Site
• Frequency Band
• Latitude & Longitude
• Operational Bandwidth
• Antenna Height
• Azimuth
• Electrical and Mechanical Tilt
• Logical Cell Identifiers
• Allocated PCI
• DL & UL EARFCN

NaaS Operators can use the same Master Database built during the HLD process and that was built using the Master Database Template.

Design Example

The final version of the Master Database for the Design Example is included as part of the Master Database Template.

Table 12, Table 13, and Table 14 display sections of the Master Database

Table 12. Design example Site and Cell Identification section in Master Database.

Table 13. Design example Site Physical Parameters section in Master Database.

Table 14. Design example Cell Identifiers section in Master Database.

4.2.10 Bill of Materials Generation

As a result of the RAN HLD process, an initial Bill of Quantities (BoQ) must have been generated. Such BoQ should contain a high-level list of the required equipment based on the calculations made during the RAN HLD process:

• Number of baseband units
• Number of radio units
• Number of antennas
• Required number of jumpers
• Required number of mounting brackets
• Fronthaul fibers
• Backhaul communication: ethernet, fiber, etc.

In some occasions, the configuration proposed by the RAN HLD process can be modified once the RAN LLD process results are ready, i.e. a site initially considered with 2 sectors can be modified to only one sector after analysis of performance plots, etc.

In addition, once the RAN Equipment selection process is finished, a final BoM with the equipment to be used during the deployment phase can be built following the results from the RAN LLD process.

NaaS Operators can use the Bill of Materials Template as a base to create its own version.

Design Example

Figure 45 displays a snapshot of the bill of materials required for the design example configuration.

Figure 45. Bill of Materials snapshot for the Design Example.

For the design example, the following assumptions were made:

• Two jumpers for each radio unit for antenna connection.
• One fiber per radio unit for fronthaul.
• Two SFPs per fronthaul fiber.

4.3 NaaS Operator End-to-End Process Definition

NaaS operators can use the generic process design as a base to develop its own version according to its limitations and constraints. In order to adapt the generic process a deep analysis of the process can be performed.

Analyzing the provided generic process design, activities can be classified into two groups:

• One-time activities: Tasks that will be done only one time during the design process. These activities only require resource consumption at the beginning of the process. In the provided process, one-time activities are all activities except for Site Configuration Refinement and Data Fill Generation.
• Continuous Activities: Tasks that are continuously carried out during the design process. These activities will consume most resources during the design phase. In the provided process, continuous activities are Site Configuration Refinement and Data Fill generation.

The approach presented on this section will focus on continuous activities as they consume the majority of the resources. Following some guidelines that NaaS operator should consider in order to customize its own process:

• Pre-processing of one-time activities: One-time activities should be done at the beginning of the process in order to not keep consuming resources.

Finally, it is highly recommended that NaaS operators execute a Critical Path Analysis over its process version for further optimization.

5 LLD Recommendation

This section presents a methodology to consolidate and generate a final LLD recommendation.

5.1 LLD Recommendation Format & Structure

The main deliverable from the RAN LLD process is the LLD recommendation which contains the overall technical solution, complete Radio Configuration, analysis conclusions and basic information for RAN implementation. The RAN LLD recommendation shall contain the following aspects:

• Performance Plots Analysis: Presentation and discussion of the obtained performance plots and how they impact in the refinement of Radio Configurations.
• RAN Configuration Overview: High-level description summarizing the RAN configurations.
• Parameter Summary: Summary of the most important parameters required for the correct operation of the network.
• Defined Naming Convention: Description of the established nomenclature.

5.2 LLD Recommendation Generation

Generation of the RAN LLD Recommendation following the format and structure established. NaaS Operators can use the RAN LLD Report Template as a reference to create its own version.

nbps;

RAN Civil and Power Design Introduction

Power and Civil Design for RAN Sites refers to the process performed to design a proper Power Solution and Sites Equipment Layout, considering as inputs the Site Characteristics, Network Equipment power requirements, RAN and Transmission LLD. An accurate Power and Civil design will achieve economically efficient Power Feed Solution and will facilitate forthcoming Installation and Maintenance Tasks.

The RAN Power Design assesses the Power Supply Options that suit the site scenario, which can be Grid or Solar. When the Power supply option has been established, the next step is to match the selected network components requirements with power systems capabilities, optimizing cost and protecting the NaaS Operator Hardware Investment. Once the Power Hardware is established, a Site Layout must be performed; the site layout indicates where the hardware must be installed, facilitating the forthcoming installation, maintenance, and future network upgrades.

The RAN Civil and Power Module provides the NaaS Operator with background information to aid in the selection and design of a customized Power System for their sites and guides NaaS Operators to prepare their Site Layouts that will define the position of all RAN & Power components in blueprints.

Main deliverables that the NaaS Operator will be able to generate through the use of this module are Power Equipment Bill of quantities and Blueprints for the Site Layout Equipment Component,

1.1 Module Objectives

This module will guide the NaaS Operator to accurately assess and dimension the Power Equipment for the RAN site and develop the Site Layouts that will define the equipment location, ensuring their right operation, and the installation of the equipment. The specific objectives of this module are to:

1. Provide an information base and fundamentals to perform the tasks associated with Civil & Power Design.
2. Guide NaaS Operators to accurately evaluate and dimension the power system to be installed at each RAN site, optimizing the required Hardware for each Scenario.
3. Provide guidelines for the NaaS Operator to prepare their Site Layouts that will define the Equipment Position and Installation standards.

1.2 Module Framework

NaaS PlayBooks Framework shown in Figure 1 displays the PlayBook modules and their relationship to the Civil & Power Design for RAN sites Module.

The Strategic Plan & Scope and High-Level Network Architecture streams provide the business and technical context for the NaaS Operator and have a direct impact and influence on many aspects of the Deployment Stream.

The Civil & Power Design for RAN sites Module is included within the Network Design Stream. It takes inputs from the Mobile Core Architecture, the output generated serves as Guidelines for Core Equipment Installation.

Figure 1. Network Design Framework.

Figure 2 presents the Civil & Power Design functional view where the main functional content of the module is exhibited.

Figure 2 Civil & Power Design Functional View.

The rest of the module is divided into three sections. Section 2 is an introductory section, containing a high-level view of the power systems used for RAN sites, their main characteristics, and functions. Section 3 contains the key considerations used to design a power solution that properly fits the requirements for each site. Section 4 provides hands-on guidance for the Equipment Sites Layouts, including the Antenna System, Rack or Cabinet and Cabling.

2 Civil & Power Design Fundamentals

This section presents a description of the Civil & Power Design process including an analysis of the benefits to perform the Power System Design and Site Layout, the main tasks and inputs of the process and the description of the two most common types of power systems in rural deployments: Solar & Grid.

2.1 Civil & Power Design Overview

The purpose of Civil & Power Design is to select and size the Power System depending on the RAN Site Power requirements, and to define the position of all the RAN equipment through a Site Layout. An optimal sizing of the power system and a properly performed Site Layout will protect the NaaS Operator investment as follows:

1. Minimize Initial Investment: Avoid Over-dimensioning of unnecessary hardware, reducing NaaS Operator expenses.
2. Maximize Service Continuity: Allows NaaS Operators to deploy a more reliable network that will ultimately impact their profit.
3. Enhance the Electrical Efficiency (Minimum Operating Costs): Selecting equipment, considering their electrical efficiency will significantly lower the electrical bill from the Power company thus NaaS Operator OPEX.
4. Facilitate Installation and Maintenance process: properly designed RAN Site Layout will facilitate enormously forthcoming Installation & Maintenance tasks

Figure 3 depicts the Civil & Power Design Process. The first step is to calculate the Power Consumption of the RAN site equipment, considering that each equipment has its own load characteristics. Then various types of power systems are assessed; for this module Grid and Solar systems are considered, as these are the most common for NaaS deployments.

The first option is to consider Grid power which is the commercial AC power network. The feasibility of this option will depend on the general availability and reliability of the Grid service and the compliance with engineering requirements. In case that the Grid service is not available or not reliable, Solar Power Systems will be considered, which is sized according to the power consumption and autonomy requirements. Solar Power System may result unfeasible under high load conditions; in this case, the RAN/TX design must be reviewed to reduce the power load of the site.

The outcome of a properly designed power system is a reliable and optimized solution that will feed the RAN sites with minimum service outage.

Once the power system and the RAN LLD has been established, the site layout can be defined. It will determine the equipments position at the site, following the RAN and Transport LLDs as well as engineering standards.

Figure 3. Civil & Power Process overview

2.2 Civil & Power Design Inputs Description

There is a wide variety of options to perform a Civil and Power Design, so to narrow them, some inputs have to be defined at the beginning of the design process. Table 1 below list the inputs of Civil & Power Design, show the impact on the overall process and its possible sources.

Input Required	Description	Impact	Source
Equipment Power consumption (W), Average Load or Maximum Load	Power Consumption of RAN Site Equipment including RRU, Baseband, and transport equipment.	Required to determine the total load to be supported by Power System Elements	Network Equipment Vendor Specifications
Grid Power Equipment Specifications	Specifications of all Power Equipment: AC INPUT: ● Voltage Range ● Frequency ● Maximum Current DC OUTPUT: ● Voltage Range ● Maximum Power ● Maximum Current ● Peak Efficiency	Required to properly size and select the Power System Elements	Vendor Specifications
Battery Specifications	Specifications of the batteries for the Power System: ● Capacity (Ah) ● Self discharge time in % ● Battery Operative Voltage	Required to properly size and select the batteries in the Grid or Solar Power System	Vendor Specifications
Solar Power Equipment Specifications	● Solar Panel Nominal Power ● Output Voltage The Peak Power of a Solar Panel, regardless of the location	Required to properly size and select the Solar Panels in the Solar Power System Elements	Vendor Specifications
Solar Irradiation	Solar Irradiation received in Sites location.	Used to dimension the number of solar panels.	https://globalsolaratlas.info/map
RF Equipment Dimensions & Weight	Dimensions and weight of the RF equipment: ● Base Band ● RF Unit ● Antenna	Required to define the Site Layout	Vendor Specifications
Site Survey Reports	Inspections of physical sites to gather relevant information (e.g. equipment inventory, photographic documentation).	Required to define the Site Layout for existing sites	Vendor Specifications
Site Engineering	Contains detailed blueprints corresponding to each specific Site deployment of tower and bird eye view of the site.	Required to define the Site Layout for greenfield sites.	Site Construction Contactor

Table 1 Input description of Civil and Power Design for RAN sites

2.3 Grid Power System Overview

A Grid power system is the set of equipment that takes electric energy from the public alternating current (AC) network and transforms it to direct current (DC) which is required to power the equipment at RAN sites. Modern grid networks are a reliable source of power, offer less outage duration and few power quality disturbance therefore when it is available the grid network is the preferred option to feed a RAN site as it ensures network service continuity at an acceptable cost.

A Grid Power System for a RAN site consists of four basic elements, shown in the schematic of Figure 4:

• Rectifier system
• Battery system
• Power distribution system
• Monitoring and control system

Figure 4 Simplified Schematic of the Grid Power System for RAN sites

Components in Figure 4 are described in the following paragraphs while further guidance for the sizing and selection of the various system components is provided in Section 3.

1. Rectifiers. Elements in charge of converting the prime power source AC voltage to direct current (DC). Rectifiers serve three main purposes:
1. Power the loads when commercial AC power is available.
2. Supply float charge to the battery to overcome battery internal losses.
3. Recharge the battery after an AC power supply failure and restoration while simultaneously supplying the normal equipment load.
2. Batteries. Energy storage devices that power the loads during AC power supply outages. Batteries are always connected to a busbar that connects the batteries from the load so there is no switchover time or interruption when the primary power source (and standby source, if equipped) fails or if the rectifier system fails.
3. Power Distribution Units. Elements that provide central locations for feeding loads and for protecting circuit wiring. The distribution systems also provide a convenient way to isolate individual loads from each other during fault conditions. The primary distribution system has the first overcurrent protective device (either fuse or circuit breaker) between the discharge bus and the load. There are several solutions that Naas Operators may consider for their power system, commonly in low power rural scenarios, the PDU is installed within a Power Cabinet.
   

   

   Figure 5 Sample of Power Distribution Units from different vendors

   Although the primary distribution system can directly feed loads if desired, a secondary distribution system may be used for larger Scenarios.

4. Monitoring and control system. Component that includes alarm collection, processing and metering. Control systems include rectifier float/equalize control and timing, parametric recorders, local area network (LAN), serial port, with modem interfaces. In some solutions it is embedded in the PDU or rectifiers.

In addition to the components above, NaaS Operators may consider a Standby AC Power Source that provides standby power through an engine-generator set fueled by diesel, propane (liquefied petroleum gas, or LPG) or liquefied natural gas. This architecture is shown in Figure 6.

Figure 6 Simplified on-site AC power distribution system with a standby generator.

There are pre assembled Grid Power Systems available for RAN and Transmission equipment used in Low power consumption scenarios. Some vendors offer their DC power system for indoor or outdoor locations embedded in IP65 cabinets including a cooling system. The size of the system is customizable depending on RAN Equipment Power Consumption and Engineering requirements. The Figure 7 below shows a Power system commonly used in rural environments:

Figure 7 Outdoor DC Power System

2.4 Solar System Overview

Base stations need to provide 24/7 operations. They are not only installed in urban areas, but also widely distributed in various environments such as deserts, islands, mountain tops. They are unattended and have high demands on the reliability and lifespan of power supply.

Many rural locations do not have a grid line that is readily available from the RAN site. As an alternative, the recommended choice is the Solar Power System. Its cheaper than the cost to add utility poles on the RAN site.

In the Solar Power Systems, the energy conversion is static and needs much less maintenance compared to generators relying on physical movements of mechanical parts. It is most suitable for a remote area power supply system when the base station site load is less than 2kW.

However, solar is only produced during the day so energy storage is required for these systems. Energy storage is what makes a solar system more expensive than grid power in rural areas. However, a cost-benefit analysis should be performed by the NaaS Operator to decide between Grid and Solar when both options are available. Table 2 lists the pros and cons of Solar Power Systems.

Pros	Cons
Renewable Energy Source	Higher CapEx
Reduces Electricity Bills	Weather Dependent
Low Maintenance Costs	More Batteries are required
Safer than traditional electric current	Higher Space Requirements

Table 2. Advantage and Disadvantages of Solar systems

2.5 Solar System Description

The Solar power system consists of electricity generation, energy storage, energy conversion, and management equipment. Energy generation equipment includes a photovoltaic array. Storage equipment includes a battery pack. Energy conversion and management equipment comprises in Charge controllers with DC converter and in some cases an inverter switch.

1. Solar Photo Voltaic Panels: Solar photovoltaic array converts sunlight directly into electricity; powers base station equipment with 48V voltage through serial as well as parallel interconnection of photovoltaic modules.
2. Solar Charge Controller: Key element in the solar power system that manages and controls the power flow of the different elements in the solar power system to meet the demands of the RAN site load, in some systems is part of the Solar regulator.
3. Batteries: Elements that store excess energy from solar panels, to provide it at night or when the power output of the solar panels is not sufficient to cover the RAN site load.

Figure 8 Basic Elements of a Solar Power System

2.6 Site Layout Overview

The Site Layout is an important part of RAN site engineering. Site Layout refers to the technical drawings that show information about power and network equipment at RAN sites.

The Site Layouts are created and used by engineers, builders, field technicians, etc. for the electrical, and RAN systems of different buildings, towers, or data centers. They consist of lines, special symbols, dimensions, and notations used to clearly show the RAN and Transport equipment location and the scheme of electric wiring within.

Site Layout will help installation technicians to locate the equipment within the site facility, including the antennas and RRUs in the tower, which will help to protect the equipment during the installation avoiding damage to the equipment due to wrong installation protecting NaaS operators investments.

This Module suggest the following layouts for the NaaS Operator procedures:

• Electrical wiring diagrams: Indicates the electrical layout of power cabling, this is especially useful to protect the equipment during installation procedures. Figure 9 shows the electrical wiring diagram for a base station cabinet. Please note that grounding cabling is detailed in the Site Construction Module.

Figure 9 Sample of electrical wiring layout in a cabinet

• Antenna System Layout: Shows the orientation and position of the mounting hardware such as poles, masts and sectors frames where the Antenna and RRUs will be installed, Additionally shows the orientation of the antennas in relation with the north following the RAN LLD Figure 10 shows a sample of an Antenna System Layout

Figure 10 Sample of Antenna System Layout

• Base Station Rack/Cabinet Layout: Indicates the position of the RAN and Transmission equipment in the rack or cabinet. Defining the position of all the equipment before installation takes place will improve the overall installation quality and timelines.

Figure 11 Sample of Cabinet Layout including Power, Transmission and RAN equipment

• General Site Layout: Indicates the position and distribution of all RAN and transmission elements within a site, Figure 12 shows a General Site Layout with two sectors, indicating the height of antennas and radios, the expected DC cabling route, a general view of the cabling in the antenna system, and the cabinet position taking the tower as a reference.

Figure 12. General Site Layout Sample

2.7 Power Connections: Power Over Ethernet

Power over Ethernet is, generally speaking, a technology that allows sending power and data over UTP cables used for data transmission, at a range of up to 100m (333ft). The operating voltage for energy transmission is always under 60V, power is always under 100W, and the power source is protected against short circuits. With that, PoE is safe for people and for equipment. PoEs major advantages over using a local AC power adaptor are:

1. The Powered Device (PD) can be located anywhere in a radius of 100m from the Power Source Equipment (PSE)
2. The PD can be remotely reset, without the need to access it physically (with a managed PSE)
3. All the PDs connected to a single PSE can be backed up with a single Uninterrupted Power Supply (UPS), instead of having a UPS per device
4. The RJ45 connector is universal, the same in every country
5. PoE PD devices can be shut down remotely for extended periods of time (with a managed PSE)

There are two ways to deploy PoE technology: using a PoE switch, or by installing PoE injectors in the existing networking infrastructure. PoE-capable switches offer the advantage of an integrated solution that requires only one cable for the network connection. PoE injectors are a power source that can be used in combination with a non-PoE Switch.

Use Cases for PoE in Outdoor Small cells

Outdoor cells are located in places without easy access to electricity and have the added disadvantage of requiring IP66 or IP67 weather protection, which means that minimizing the number of input ports is critical. PoE can be used to deliver power, either:

1. Using an outdoor-rated PoE hub connecting and powering Small Cell + Backhaul as shown in Figure 13

Figure 13 Small Cell + Backhaul Deployment using a PoE HUB

2. A managed PoE switch, which would connect between the multiple outdoor PoE Small Cells as it shows in Figure 14

Figure 14 Switch with PoE capabilities feeding 2 small cells

2.8 Electrical Protection

Most of the power systems include mechanisms to protect the power equipment and the connected load of electrical disturbance. The set of recommended protections are listed below:

• Input overvoltage/undervoltage protection
• Input overcurrent protection
• Output overvoltage protection
• Output short-circuit protection
• Output current-limiting protection
• Overtemperature protection

However not all power system include these protections, Naas operators must be aware of which kind of protection their chosen power system includes, this information can be found in the power equipment datasheet. If it is detected that any of the recommended protection is missing, NaaS Operators should add the missing protection with additional devices as required. Some devices used in RAN sites are shown in Figure 15, and described below:

1. AC Surge Protection Device: Installed near to the main electrical panel to suppress lightning and switching overvoltage. Is used to protect the Power Equipment.
2. DC Indoor Arresters: Or Type 1 DC arresters have a low voltage protection level for RRH/RRUs, are installed in a DC indoor box near the Power supply unit.
3. DC Outdoor Box: Are Installed in the mast. The box Includes DC arresters for additional protection in case nominal load currents up to 2000A.
4. Surge Arrester for PV Systems: Used in Photovoltaic (PV) facilities, provides additional protection against lighting in the solar power system.
5. Ethernet Arrester: It’s a Surge Arrester for Gigabit POE (Power over Ethernet) to protect against overcurrent and over-voltage.

Figure 15 RAN site electrical Protection

3 Power System Design

This section describes guidelines to size and select the basic components of the DC power system that feeds a RAN site. The Sizing and design of AC Power solutions used for external HVAC systems (heating, ventilation, and air conditioning), lights or any other AC equipment at the site is out of the scope of the PlayBook.

3.1 Power System Design Process

A DC power system must provide the specified voltage range and current to the equipment and batteries when the primary power source is available. The batteries must provide reserve power for a certain amount of time giving autonomy from the main source when it fails. The objective of Power System Design is to ensure the power requirements are met with a proper autonomy for each site optimizing the system. As depicted in Figure 3 in Section 2.2 the design process includes calculation of the RAN site power consumption, development of the system requirements and sizing of the system based on those requirements.

New systems are the easiest to design because there are no constraints caused by existing and many times inadequate infrastructure. The new infrastructure is built to accommodate the new systems and is possible to use a wide variety of new equipment. Expansion or retrofit of existing systems, particularly older systems, usually is more difficult because of the physical and electrical limitations.

3.2 Load Calculation

The Load calculation of the RAN site is determined by the power consumption of all the elements of the site, measured in Watts(W), and it is used to properly size the power equipment. Most of the Equipment to be powered at RAN sites consists of:

• Radio Units
• Base Band Unit (for Macro Cells)
• Transmission Equipment. This may integrate one or more of the following
• Routers & Switches
• Microwave Radios
• VSAT

The DC load caused by transmission equipment such as switches and routers, for practical calculation can be considered constant regardless of traffic, In the same way the power consumption of radio Baseband or Microwave IDU can be considered constant.

In case for in-built cooling system within power cabinets or other cabinets, the vendors mention the power consumption at certain temperature commonly at 25C and is the one used for load calculations.

The load characteristics of the Radio Unit equipment are quite different from switching systems. there is a relatively small fixed (static) load component and a large variable load component. The variable component depends on traffic (each active channel contributes to the load), and daily variations are fairly predictablemidmorning, midafternoon, and evening.

So, the mathematical equation for the power consumption of a RAN site is:

(Eq. 1)

Where:

• RANpwr is the power consumption of the RAN equipment, it may include Baseband and RRUs/RRH
• TXpwr is the power consumption of the transmission equipment indicated by the vendors
• Coolpower is the power consumption of a DC cooling system

The best way to obtain the power consumption of the RAN site elements is from the vendor documentation. Commonly can be found in the equipment datasheet or the environmental product declaration.

Below is an example of a Load Calculation in a Grid AC-DC Power System :

Example: Table 3 is an example of the power consumption in watts of a radio baseband for different configurations:

Configuration	Total Power Consumption (W)	Total energy consumption (kWh/ year)
1 transport board + 1 capacity board	160	1402

Table 3 Example of a Radio Baseband Power Consumption

An example of Radio Units power consumption is showed in Table 4 In this sample the vendor indicates the Radio Unit typical power consumption in Watts for 48VDC input, at 25C, with +/- 10% margin. The average power consumption detailed in Table 4 considers 6h low hour load, 10h medium hour load and 8h busy hour load / 24h.

Configuration	Output Power per carrier (W)	Power consumption (W), ETSI 202706 average load PRRH, static	Power consumption (W), ETSI 202706 busy hour load PBH RRH, static	Power consumption (W), 100% RF power load P100% RRH
1/1/1 4Tx	4×40	879	1076	1557
1/1/1 4Tx	4×20	657	755	965
1/1/1 2Tx	2×40	540	637	874
1/1/1 2Tx	2×20	430	479	581

Table 4 Power Consumption of a Radio Configuration

An example of a Microwave in Split-Mount configuration is showed in Table 5.

Microwave Split-Mount Solution
Power consumption per carrier	55W outdoor radio 15W indoor baseband

Table 5 Power Consumption of Microwave transmission equipment

Table 6 is an example of a Cooling System power consumption embedded within an Outdoor Cabinet in these cooling systems the power consumption varies according to the temperature.

Cooling System in Outdoor Cabinet

30 W idle +23C (+73.4F)

50 W typical +55C (+131F)

150 W max. ambient

500 W cold start (heater active)

Table 6 Outdoor Cabinet Cooling System Power Consumption

Calculate the total power consumption of a RAN site using the power consumption showed in Table 3, Table 6, Table 4 and Table 5 using the following assumptions:

a) A Macro site with 1 baseband and 3 Radio Units in (1/1/1 2Tx) with 20W RF Output Power configuration.

b) Use Microwave transmission in Split-Mount configuration with a single carrier.

c) The deployment location has a max temperature of 25C and a Minimum of 13C constant during all year.

Solution

1. Baseband Load Consumption

In this example it is indicated in Table 3 that the baseband power consumption is 160 W. The Radio Units use a (1/1/1 2Tx) with 20W RF Output Power configuration the safe assumption is to take the average power consumptions (6h low hour load, 10h medium hour load and 8h busy hour load / 24h) adding a 10% margin in this case the Table 5 indicates 430 W(1.1)=473W. The Macro Base-Station consumes a total of 160W +473W=633W.

2. Split-Mount Microwave Transmission Equipment

The DC load caused by this type of equipment is constant regardless of traffic. The sample indicates: 55W for the outdoor radio and 15W for indoor microwave baseband a total of 70 W

3. Cooling System Consumption

In this example it is indicated that the ambient temperature is a maximum of 25C and a Minimum of 13C constant during all year. Table 4 indicates 50 W typical +55C (+131F).

So, from Equation 1:

(Eq. 1)

= 633W+70W+50W = 753W

3.3 Grid Power System Dimensioning

There are two basic components of the Grid AC-DC Power System that should be sized to feed the DC load: The rectifiers, which converts AC current to usable DC current, and the batteries that assume the load when external power is interrupted. This section includes guidelines to size Rectifiers and Batteries accurately, based on load calculation and the autonomy requirements.

3.3.1 System Operating Voltages and Ranges

To properly size the batteries is required to obtain the Operative Voltage of the RAN site. The equipment with the highest minimum voltage (VME) and lowest maximum voltage (VLM) generally will set the operating range of the power system in a RAN Site.

Example.

All the equipment used in a RAN site has a nominal power of 48VDC. One equipment has a permitted operating voltage of 36.0 to 60.0 VDC. Other equipment operative voltage range of 42 to 56 VDC.

Therefore, the high limit for the power system must be set to 56.0 V even when other equipment in the same site operates satisfactorily at 60VDC. It should be noted that prolonged operation at higher voltages almost always reduces equipment reliability even when the equipment is rated for the higher voltage. The minimum operating voltage is 42V even when there is equipment in the same RAN site that can operate at 36V.

3.3.2 Battery System Design

A battery system consists of a set of industrial batteries with enough power to feed the RAN site, this section will provide guidance to choose a battery technology that suits NaaS operator needs and engineering guidelines to properly size the battery bank that fits the equipment power requirements and provide enough autonomy.

The results of the battery system design are:

• Choice of technology, valve-regulated lead-acid (VRLA) or Lithium Battery (Li-ion)
• Number of Batteries to power up the required voltage
• Number of battery strings required to provide the total capacity.

3.3.2.1 Battery Technology:

There are two battery technologies used in RAN sites: VRLA and Lithium batteries. A comparison between both is analyzed in Table 7.

VRLA	Lithium ION
Requires More Recharging	Faster Charging and Discharging
Maintenance at least once a year	Maintenance at least once a year
Lifespan of 5-7 years	Lifespan of more than 10 years
Least expensive	More expensive

Table 7 VRLA vs- LI-ION

Currently, VRLA batteries are predominantly adopted in RAN sites, however, the use of Li-ion batteries is increasing in commercial deployments. This module will consider VRLA batteries to calculate the bank sizing in the Power system.

3.3.2.2 Battery Bank Capacity

The Battery Bank consists of two main characteristics: the number of batteries and strings. Commonly for a 48 V system a string is an array of 4 x 12V batteries connected in series. Additional arrays increment the autonomy of the system.

The factors used to calculate the required battery capacity in ampere-hours (Ah) consists in the following inputs:

a) Equipment load current in Amperes (A):

The total equipment load can be calculated with the power consumption and nominal voltage of the RAN site:

(Eq. 2)

b) Autonomy requirements in hours (H):

Autonomy requirements is the reserved time that the battery bank will provide energy to the site in case a power outage from the main power source. The recommended range is between 8 to 12 h reserve time.

c) Battery required capacity (Ah):

To determine the required capacity battery firstly is needed to calculate the battery final voltage (VBF), which is the minimum voltage to which the battery can discharge and still maintain equipment operation. The battery final voltage must be greater than the minimum equipment operating voltage (VME) by an amount equal to the voltage drop from the battery terminals to the equipment terminals and includes all circuit conductors and connections in between(usually considered to be 2.0 V for -48V systems). So VBF is defined by the equation below:

(Eq. 3)

To calculate the discharge factor is required to calculate the required final cell voltage (VCF) of the batteries defined by :

(Eq. 4)

Where:

= 24cells for 4 (12V) VRLA batteries in 48V systems

Example If the minimum operating voltage of a RAN system is 38VDC :

The final cell voltage (VCF) equals the battery final voltage (VBF) divided by the number

of cells (NCell) :

VRLA batteries used in the RAN sites provide 12 Volts, so for a 48V system, 4 batteries are required to be connected in series. VRLA batteries are built from 6 electric cells, each cell provides 2 Volt (nominal voltage) to the battery system. Battery manufacturers provide their discharge characteristics based on the constant current to the load within a certain period of time until the battery cells reach a final voltage Figure 16 shows a sample of the discharge characteristics of a battery with 12V 91Ah (8Hour/25C) up to final discharge voltage of VCF of 1.75V.

Figure 16 Sample of constant current discharge data units: (Amperes) at 25C

The required capacity is defined by

(Eq. 5)

Where:

C= The required Capacity of the Battery Bank in (Ah)

= Nominal Capacity of the battery as is indicated in the vendor documentation (Ah).

= Constant Discharge Current during a certain time up to reach a specified VCF (A) .

At= Total Current of the RAN site equipment (A).

Example A RAN Site with minimum equipment voltage of 38V and a power consumption of 753W, requires 10 hours of autonomy. Determine the required capacity of the battery bank taking as a reference the sample of constant current discharge of Figure 16

Solution. From previous examples :

1.-Calculate At From Eq. 2 :

2.-From the sample of constant current discharge of Figure 16 the available current for 10 hours is 9.5 A the From Eq. 5 :

3.3.2.3 Number of Batteries and Strings

The arrangement of the batteries in series determines the voltage polarity. Just as the voltage of a battery system is increased by connecting the batteries in series, the ampere-hours and kilowatt capacity of the systems can be increased by connecting strings of series-connected batteries, in parallel.

If each of the 12 V batteries shown in Figure 17 is rated for 91 amp-hours, each series string of batteries could be expected to produce 91 amps of current for one hour.

Capacity is directly related to the size of the battery; but, rather than spending more on larger batteries, it is possible to achieve the same boost to capacity by adding more strings of batteries to the system in parallel as opposed to adding them in series.

This option also provides safeguards against the failure of an individual battery, which would remove its string from the system altogether. By connecting in parallel, the spare capacity is already online and ready to maintain the current for its rated length of time. A diagram of a parallel battery strings rated at 182 amp-hours is showed in Figure 17. Note that, if a battery failed in any of the two series strings, the remaining string would continue to supply steady power at 91 amp-hours as indicated in Figure 17.

Figure 17 VRLA multi-string battery configuration offering additional redundancy

After calculating the total battery capacity, it is necessary to determine the number of battery strings. As a general rule, the number of battery strings should be the minimum necessary.

If the total required battery system capacity is to be divided equally across two or more strings, the required number of strings is determined from:

(Eq. 6)

where

= number of battery strings in parallel

= individual battery string capacity (AH)

= The required Capacity of the Battery Bank in (AH)

There is no technical limit on the number of battery strings that may be connected in parallel but there are practical limits. As a general rule, the battery manufacturer should be contacted if more than five strings are to be paralleled. Some manufacturers do not recommend more than four or five parallel strings.

The widget $$link widget$$power system sizing contain a tool to size the battery bank for a RAN site will help NaaS Operators to calculate the required capacity of the battery bank and a recommended Battery Array.

3.3.3 Rectifier System Design

The rectifier system capacity must be large enough to not only operate the load equipment but simultaneously recharge the batteries at the desired time. Rectifiers used in telecommunications applications consist of modular rectifiers commonly equipped for N + 1 redundancy, operated in parallel, and almost always set up for load sharing.

With modular rectifiers, it is relatively simple to adjust the capacity by unplugging unneeded rectifier modules or using modern controllers that can be programmed to activate only the necessary rectifiers. The controllers on some rectifier systems can be set up to automatically shut down unneeded rectifiers during float operation and to bring them back online when needed for battery recharge. For RAN site applications there is several options for rectifiers, commonly are embedded with the power controller in 1 Rack Unit, Figure 18 shows a rectifier modular system with 2 rectifiers.

Figure 18 Common Rectifier Modular System for RAN sites

There is Two considerations to decide the rectifiers system:

1.-Input Power: Switch mode rectifiers are the preferred choice RAN sites since they can support multiple AC inputs and have a broader operating rangefrom single-phase to three-phase inputs. This flexibility means fewer rectifiers are requiredsaving money, space and maintenance.

2.-Output Power: The output power of rectifiers for RAN sites are available in a wide range commonly from 110W to 4.4kw. There is no technical limit to the number of rectifiers, but a simple economic analysis may reveal that a small number of large rectifiers is cheaper than a large number of small rectifiers.

The Rectifier system design requires the selection of

● Capacity

● Quantity

3.3.3.1 Capacity and quantity of rectifiers

Even the smallest system will have at least two rectifiersone to carry the load and recharge the battery and another configured for hot-standby operation.

Industry baseline requirements specify that the rectifier system should be designed to recharge a fully discharged battery to 95% of its nameplate capacity rating within at least 24 h while simultaneously operating all load equipment. This requirement should be met when the equipment is operating at its busy hour load (normal condition).

The total normal condition load current is one parameter used to calculate the required rectifier system capacity. Note that normal condition load current is used here instead of peak.

The rectifier system capacity is calculated from:

(Eq. 8)

Where

● tRecharge = battery recharge time (h)

● Cnom= battery nameplate capacity at 25C and 8-h rate to 1.75 V/cell (Ah)

● IRS = rectifier system capacity with N rectifiers (A)

● IEQ = normal condition equipment load current (A)

● FBatLoss = battery loss factor (typically 1.10 to 1.15 for VRLA batteries)

Where modular rectifiers are to be used, the total number of modular rectifiers (NRM) is determined from the rectifier module current rating (IRM) from:

(Eq. 9)

rounded up to the next higher integer value. This assumes that all rectifier modules have the same rating, which would be true in new installations and replacements. Where additional rectifier capacity is added to an existing installation, the redundant rectifier (or rectifiers) must be at least as large as the largest rectifier in the system. For example, if an installation has two 50-A and one 100-A rectifiers for the load and battery recharge, redundancy would be provided by adding a second 100-A rectifier or two additional 50-A rectifiers. This protects the system from the failure of any rectifier in the system

Example:

A battery system of 182Ah is used in a system where the equipment load current is 15.68 A. Determine the total rectifier system capacity and number of rectifier modules if each module is rated 50A.

Solution

From (Eq. 8)

From (Eq. 9)

As a result, for this vendor, the required Rectifiers Sum Up 2 Rectifier of 50A with a redundancy configuration (N+1)

The widget $$link widget$$power system sizing contain a tool to size the rectifiers for a RAN site based on the content on this section

3.4 Solar Power System Design

This section outlines the main features of a typical remote-area, stand-alone, all-DC Photo Voltaic-powered system with reference to design features, installation, and sizing.

Defining the system load is the first step to Solar Power System Design. Method in Section 3.2 shows the general methodology to calculate the load of a RAN site suitable for any power system.

The total load of the RAN site along with the average solar irradiation and PV Panels efficiency is used to size the Photo Voltaic Panels array which must be capable of producing power to supply the load current for 24 hr/day and to supply the battery charging current for the daily peak sun hours at the site location.

The sizing of the battery bank is different from the Grid power system since the autonomy requirements for a solar power system are greater and are estimated in days. The size and cost of a Solar system is proportional to the energy consumed by the load. Reducing the electrical load by selecting energy-efficient equipment will result in a corresponding reduction in the system cost.

Figure 19 shows the design process for a Solar Power System:

Figure 19 Solar Power System Design Process

3.4.1 Sizing Photo Voltaic (PV) Panels

In order to size the PV panels required to power a RAN site is required to know the Nominal Power of the PV Panel. The maximum electric or nominal power of the PV panel can be defined as its Peak Power (in Watt Peak). The Peak Power of solar panels is registered under the following Standard Test Conditions:

● a light intensity of 1.000 W/m

● sunlight hitting the positioned solar cells perpendicularly

● a temperature of 25C at the solar cells

The Nominal Power is a specific feature of the PV panel, regardless of the location where it is tested. Under these standard conditions, the nominal power of solar panels can be compared with each other. A solar panel with a Peak Power of 5 kW in Peru is for example exactly the same as such a panel in the USA.

The real electric power of the PV panels is primarily dependent on the number of hours of sunshine to which they are exposed. Sun hours vary greatly depending on the site location and local climate. To determine the average solar Irradiation go to $$link$$https://globalsolaratlas.info/map. Figure 20 shows the global horizontal irradiation pattern

Figure 20 Global Horizontal Irradiation Map

The number of solar panels depends on the average solar irradiation in the place of interest and nominal power (P_nom) of the solar cells. The nominal power is obtained assuming that solar irradiation is 1000 W/m2. Equation 10 shows the expression to calculate the number of solar panels:

(Eq. 10)

Where

● TDLoad is the daily total energy required by the systems in Wh,

● Ƞg denotes the losses due to the inefficiency of the solar cells (around 10%)

● Fc is a correction factor (Fc=1.3) introduced as the solar cells have to generate energy for the system and for the batteries that are accumulating the energy.

● G_dm is taken as the average daily solar irradiation during the worst month of the year (for example in the Loreto region in Peru, the solar radiation is 4270 Wh/m²).

Example: Size the Solar Panels for a solar system if batteries and panels have the following specifications:

Solar cell: Solar World (Pnom = 300 W per panel)

Consider the same load as the one in the example of section 3.2

Consider the solar radiation of the Loreto region in Peru

Solution:

The number of solar panels and batteries will be obtained from equations (10)

Solar Panel Calculation:

TDLoad of RAN Site equipment = 753Wh X 24h = 18,072Wh

Pnom = 300W

Gdm = 4270 Wh/m²

PV Solar Cell Inefficiency Ƞg = 10%

Solar Cell correction factor fc = 1.3

=

The widget $$link widget$$power system sizing contains a tool to size the solar panel for a RAN site based on the content on this section.

3.4.2 Battery Bank Capacity Estimation

The methodology to used in Section 3.3.2 uses the Discharge capability of batteries, vendor expresses it by the 20-hour rate. The autonomy requirements for a solar power system are greater and are estimated in days therefore is required another method.

The capacity of the batteries (in Wh) should be enough to provide electrical energy to the system to be up to without any charging procedure. For VRLA batteries the capacity must satisfy:

(Eq. 11)

where

● Is the capacity required of the battery bank (Wh)

● TDLoad is the daily total energy required by the systems in Wh,

● Ƞg denotes the losses due to the inefficiency of the solar cells (around 10%)

● P_dmax = A parameter to impose that a battery should have at least 20% of its maximum capacity (P_dmax =0.8).

Batteries sizing Calculate the required capacity for a Battery Bank used in a solar system with the following parameters

Assume N_days = 1 days of autonomy without any battery charging, as the worst case.

Consider the same load as the one in the example of section 3.2

Solution

The required capacity will be obtained from equation (11).

From section 3.2 TDLoad 753Wh X 24h = 18,072Wh

The widget $$link widget$$power system sizing contains a tool to calculate the required capacity for a Solar Power System Battery Bank, please note that after calculating the required capacity, the battery bank should be designed accordingly, the Section 3.3.2.3 indicates the required batteries and strings needed.

3.4.3 Design Considerations, Panel Array: Position and Tilt

If the RAN site deployment location is in the north of the equator, the sun leans south as the Earth orbits. Facing the PV array to the south will capture the most daylight and produce more energy. However, if the RAN site deployment location its the south of the equator, it would be more efficient to face the PV array to the North.

Figure 21 The relationship between the sun and earth. The declination angle (δ), the latitude (ϕ), and the solar time angle (t) are also shown on it.

Tilt from horizontal is required to achieve a better angle at the sun and help keep the solar modules clean by shedding rain or snow. The optimal tilt angle is the latitude 15. In summer months, the optimal tilt angle is usually 15 less than the latitude, whilst in winter months; it is 15 more than the latitude.

Additionally, NaaS Operator may consider the following guidelines to mount the PV array:

● PV modules are very sensitive to shading; once a solar cell or a portion of a cell is shaded, it becomes a load and draws power instead of producing it. Thus, PV modules should never be shaded by nearby trees or structures.

● Temperature at the back of the modules can rise to 80C if they are poorly ventilated. Installing the solar array in an area with natural ventilation will improve system performance and extend its life.

● The mounting option must allow for safe maintenance and possible replacement of individual modules.

4 Core Site Layout

Core Site Layout consists of the design considerations of the room and the layout of the Core equipment in the Room and the rack.

A Core site layout has two components: the structural layout of the empty room which may be obtained from the site engineering in the form of blueprints and the equipment layout of what will go in the room. Note that in the case where NaaS Operators decide to lease a space in a data center, the room is pre-existing, and the only option is to layout the equipment in their cabinet.

The equipment layout shows the footprint of IT equipment and the footprint of power and cooling equipment. In order to protect the IT equipment from overheating the layout should consider an airflow path. The following subsections provide guidelines to layout the rack in a room considering the airflow of the equipment, the equipment layout within the rack as well as key considerations for the cabling layout.

4.1 Control of airflow using hot-aisle/cold-aisle rack layout

The use of the hot-aisle/cold-aisle rack layout method is well known and commonly used in a data room layout. The basic principle is to maximize the separation between IT equipment exhaust air and intake air by establishing cold aisles where only equipment intakes are present and establishing hot aisles where only equipment hot exhaust air is present. The goal is to reduce the amount of hot exhaust air that is drawn into the equipment air intakes. The basic hot-aisle/cold-aisle concept is shown in Figure 17.

Figure 17. Basic hot-aisle/cold-aisle layout plan

In Figure 17, the rows represent the IT equipment enclosures (racks). The racks are arranged such that the adjacent rows face back to back, forming the hot aisles. The benefits of the hot-aisle/cold-aisle arrangement become dramatic as the power density increases. When compared to random arrangements or arrangements where racks are all lined up in the same direction, the hot-aisle/cold-aisle approach allows for a power density increase up to 100% or more, without hot spots, Decreasing greatly the power consumption of the cooling system.

4.2 Server Rack Layout

In terms of layout, rack density should be considered. The more free-space within a server rack, the greater the room for airflow. Vertical space can be left between servers and IT devices to help cooling. Heat sensitive devices, including UPS batteries, can be placed towards the bottom of a server rack. Heavier devices are also best placed towards the bottom of a rack.

Hardware should ideally be logically grouped for ease of management and access to sockets, outlets and ports, whether for power or networking. Ideally within the middle to higher-level area of the rack.

Some manufacturers have an online free to use tool to elaborate a rack layout with their products and generic boxes, NaaS operators may consider this option to organize their rack layouts, additionally, there are several free web-based tools to elaborate a rack layout some others has to be purchased but have additional features that consider ventilation and PDUs.

Figure 18. Rack Layout

NaaS Operators may use an asset list for each device within a server rack including each model SKU and serial number. These three pieces of information along with a description, date of installation and service dates can be recorded onto a rack management spreadsheet.

Other additional columns recommended include power draw and heat dissipation or efficiency, UPS (uninterruptible power supply) and PDU (power distribution unit) connections. The document is then maintained when equipment is added or removed and/or maintained. The spreadsheet should cover the entire server room installation and each rack or cabinet within it.

NaaS Operators may use the Rack Management spreadsheet to organize their assets and their port connections.

4.3 Layer 1 and Layer 2 diagram

The Core layout design considers the High-level & Low-level design, this subsection considers some of the outcomes of previous phases to create the physical interconnection

A Layer 1 diagram shows the physical connections between the critical pieces of network infrastructure. It includes link speeds and cabling types. Additionally, show individual port numbers or designations. Some considerations to elaborate a Layer 1 & Layer 2 diagram are listed below:

• The speed of the link is represented by the width of the line.
• Different colors represent fiber and copper cables.
• Layer 2 features include VLAN numbers, link aggregation, and trunk connections.
• Layer 2 diagram includes spanning-tree information such as the root bridge and any bridge and link priorities that have been changed from their defaults.

The required VLAN numbers and port connections are indicated in the Core LLD the purpose of L1 and L2 diagram is to map the physical ports with the logical design.

Figure 19 illustrates the L1 & L2 Diagram:

Figure 19. Layer 1 & Layer 2 diagram

NaaS Operators may consider the tools depicted in Table 5 to create an L1& L2 diagram:

Tool	Top Features			Description
CADE	Free Tool	Multiple export formats	Support for multiple diagrams	Free network design tool with predefined blocks and multiple export formats
DIA	Free Tool	Large library of objects	Open Source	Simple open-source programmed with a large library of objects
Visio	AutoCAD support	Automatic chart generator	Support community	Highly flexible popular network design with support from multiple communities and AutoCAD tech support
EDraw	15-days trial	Multiple export formats	Web Version	All in one application for rack and floor layout include L1&L2 Diagrams

Table 5. Network Design Tools that include physical connections

4.4 Cabling Layout

The lack of organization can lead to accidental disruption of service. An organized rack decreases human errors, increases efficiency, and improves equipment protection by increasing effective airflow. By using the correct cable management accessories to organize, route and remove unnecessary stress on the cables, data integrity is ensured.

Racks and enclosures can become disorganized quickly if cable management does not remain an ongoing priority. The Core site is a critical point of interconnection, NaaS operators may consider following recommendations to organize and document their connections to ensure optimal performance in the critical equipment, as detailed in the subsections below.

4.4.1 Using Color to Identify Cables

Color provides quick visual identification. Color-coding simplifies management and can save time when its required to trace cables. Color coding can be applied to ports on a patch panel. Patch panels come with different color jacks or have colored inserts surrounding the jack. Cables are available in many colors (The color palette depends on the cable manufacturer). Figure 20 shows an initial recommendation of colors to identify the role/function of a cable type of connection.

Figure 20. Color Scheme for patch cables

4.4.2 Horizontal Cable Management

Horizontal cable management allows a neat and proper routing of the patch cables from equipment in racks and protect the cables from damage. These cable managers take up the space in racks, so a careful balance between cable manager height and cable density supported is important. 1U and 2U horizontal cable managers are the most common varieties. The density supported varies with the depth of the manager. When choosing cable managers, the NaaS Operator must ensure that the cable bend radius is properly accommodated.

Please note that proper planning should allow a 30% space in the cable managers for future growth.

Figure 21 shows 2 switches using horizontal cable managers.

Figure 21. Horizontal Cable Management

4.4.3 Vertical cable managers

For vertical cable managers, there should be additional space required to manage the slack from patch cords and ensure that they can easily route the largest cable diameter. The most convenient cable managers available in the market have hinged doors on both sides of the manager for pivoting the door from either side and allow a complete removal of the door for unobstructed access. A best practice is to allow for 50% for the growth of cables when planning the width. Figure 22 shows three racks using vertical cable managers

Figure 22. Vertical Cable Management

4.4.4 Overhead Cable Pathways

Overhead cable pathways or trays allow placement of additional cables for interconnecting devices between racks. In order to select the Overhead cable pathways, it must be considered the cable bend radius, weight allowance, aging points for cables and flexibility in installing the pathways. In addition, ensure that pathways allow cable drop points where needed. Figure 23 show overhead cable pathways routing different types of cables.

Figure 23. Overhead Cable Pathways

4.4.5 Documentation

The documentation is perhaps the most critical task for cable management. A best practice is to keep the information easily accessible to data center staff on a share drive or internet web service. Naas Operators must assign updates to one or more staff members and make sure it is part of their job assignment to keep the documentation up to date. Furthermore, NaaS Operators may consider creating a training guide, which documents guidelines for installing new cables, cable management components and routing cables. A port mapping spreadsheet is useful for keeping track of used/available ports on the network equipment. It must include the remote device to which each port is connected. NaaS Operators may consider using the Network documentation spreadsheet to document their equipment, cable mapping, and IPV4 usage.

1. Mobile Core HLD Introduction

The Mobile Core High-Level Design (HLD) defines the Evolved Packet Core (EPC) deployment model, features and functionalities which the entire network has to meet. Since the EPC is a centralized element it has a major impact on the entire network performance. Therefore, a precise HLD will provide economic insights on the most suitable deployment approach and plan.

Its important to mention that based on the overall strategy, business case and agreements with Multiple Network Operators (MNOs), not all NaaS Operators will deploy a Mobile Core. Thus, this module applies only to initiatives that require a Mobile Core. More details can be found on the Mobile Core Architecture Module.

The Mobile Core HLD module provides the NaaS Operator background information and methodologies to elaborate a High-Level Design for the Mobile Core Network. It provides guidelines on how to design the mobile core network that interconnects with the Radio Access Network (RAN) to offer security, signaling, authentication and access to end user services.

NaaS Operators span a range of sizes, geographies, and network architectures. That is, there is no one size fits all methodology. For this reason, a generic end-to-end process flow to perform the Mobile Core HLD is presented along with proper guidelines to be tailored to match NaaS Operators requirements and constraints.

The main output of the module is the Mobile Core HLD Design, which includes the Interconnection Assessment, Capacity Planning, and Requirements for Virtual Network Function (VNF) entities, Redundancy Assessment and Bill of Quantities Generation.

1.1 Module Objectives

This module will enable a NaaS Operator to stand-up, run and manage a Mobile Core HLD initiative. The specific objectives of this module are to:

1. Provide an information base and fundamentals to perform the tasks associated with Mobile Core HLD.
2. Provide detailed how-to instruction on the key HLD engineering tasks.
3. Provide an overview of the end-to-end Mobile Core HLD process with instructions for tailoring to specific NaaS environments.
4. Provide guidelines to develop a formal Mobile Core HLD recommendation.

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 drive the strategic decisions to forthcoming phases. Network Design is the first step into implementation strategy which is supported by Supply Chain Management.

The Mobile Core HLD module is included within the Network Design Area and has a direct relation with Transport and RAN HLDs. The generated output of this module will serve as a required input for the Mobile Core LLD module.

Figure 1 Module Framework.

Figure 2 presents the Mobile Core HLD functional view, where the main functional components are exhibited. Critical module inputs are further described and examined in Section 2.3. In addition, guidance and methodologies to execute the tasks included within each function are described in Section 3.

Figure 2 Module Functional View.

The remainder of the module is divided into four sections. Section 2 is a birds-eye view of the Mobile Core fundamentals involved in its design. Once fundamental knowledge is acquired, Section 3 focuses on showing a hands-on view of the tasks involved in the design. Section 4 organizes functional tasks on an end-to-end process flow that can be used as-is or be adapted by NaaS operators to match with their particular conditions. Finally, Section 5 illustrates how to integrate previous elements into a comprehensive High-level Design (HLD) recommendation.

2 HLD Fundamentals

This section presents a general overview of the baseline concepts to develop a Mobile Core Network Design.

2.1 EPC Overview

There are a variety of scenarios when designing a Mobile Core Network depending on the preexisting conditions and the target of the NaaS Operator. The most predominant decision is whether to deploy Mobile Core Infrastructure which is addressed by the Mobile Core Architecture Module. For NaaS Operators deploying an Evolved Packet Core (EPC), the Mobile Core Architecture Module provides a guide to define the logical topology, necessary network elements, interconnection requirements, and virtualized architecture requirements.

Figure 3 depicts the typical EPC Architecture showing the Mobility Management Entity (MME), Serving and Packet Data Network (PDN) Gateways (SGW & PGW), the Home Subscriber Server (HSS) and the Policy and Charging Rules Function (PCRF). Furthermore, it also depicts the interconnection to the RAN network and IP Networks (e.g. Internet)

Connections to external networks are required to offer services to other MNOs that share the RAN network. The number of these connections will depend on the roaming agreements & defined interconnection approach, voice solution requirements, existing Packet Switched (PS) infrastructure and Multiple Network Operator (MNO) strategy.

Figure 3 Evolved Packet Core Basic Architecture.

The Mobile Core Architecture Module. provides the overall EPC logical topology and the strategy and requirements for interconnection with other networks (existing 2G/3G infrastructure, customer MNOs, Internet). From these inputs, the Mobile Core HLD Module defines the minimum requirements for the EPC related to Capacity Planning, VNF specifications, the networking protocols architecture and the redundancy mechanisms to appropriately assess available solutions in the market.

2.2 Mobile Core Environment

This section addresses the topics that require attention when developing a Mobile Core High-Level Design.

2.2.1 Multiple Mobile Network Operator (MNO) Design

The NaaS Operator business model requires that multiple Mobile Network Operator (MNO) share the same RAN equipment as seen in Figure 4. Different approaches and solutions to address this issue are available and the choice will depend on the agreement with the customer/partner MNOs.

Figure 4 Multiple MNOs sharing the same NaaS Operator RAN.

As discussed in the Mobile Core Architecture Module, the first approach is when the NaaS Operator only implements an MME and SGW entities to minimize the investment, but still getting the control of the RAN. The MME and SGW are shared between operators while user databases (HSS), policy and authentication entities (e.g. PCRF, OCS, OFCS) will remain independent across operators, as seen in Figure 5.

Figure 5 MME-SGW Deployment.

The second strategy consists in deploying all the EPC and PCC elements in a centralized manner as seen in Figure 6. This will allow the NaaS Operator to broaden its market by providing services to MNOs and all types of MVNOs.

Figure 6 Full deployment of centralized EPC

Finally, in addition to the full EPC deployment, a roaming strategy for interconnection with multiple operators needs to be defined. Guidelines and necessary details to define this strategy are provided in the Mobile Core Architecture Module.

From the HLD point of view, these architectural options impact the Interconnection Assessment and Capacity Planning. For Interconnection, the choice of architecture impacts the number of external connections and protocols to be used on roaming interfaces), while for Capacity Planning it drives the traffic and users dimensioning based on the roaming agreements

2.2.2 Interconnection and Networking Considerations

The Architecture module defines the approach to interconnect to other networks, however, the Interconnection and Networking mechanisms must be defined as part of the HLD. These mechanisms are directly impacted by the number of customer MNOs using the NaaS Operator network to provide service.

Based on roaming agreements and strategy contained in the Architecture module, the number of connections to external MNOs (partners and customers) can be determined, as well as the expected number of roaming users and the number of logical interfaces to match the required strategy.

The number of MNO partners will drive the number of Mobile Core interconnections required, consequently impacting the HLD design. Furthermore, for the virtualized scenario, the networking solution must take into account capacity requirements and the number of logical interfaces to/from all the MNOs using the shared RAN. Even the choice of networking protocols will be influenced by the number of interconnections to external networks as described in section 3.1.

2.2.3 Capacity Planning and Forecasting Estimation Challenges

RAN and Tx HLDs provide the subscriber and throughput forecast for Capacity Planning. In the Mobile Core HLD, the challenges consist of estimating capacity requirements for core elements and interface dimensioning based on the inputs from RAN and TX HLD.

The metrics to be taken into account are:

• Throughput for each external interface
• Number of subscriber connections
• Signaling load (transactions per second)

Additionally, each external interface will have an expected number of subscribers corresponding to all the MNOs sharing the RAN network. The throughput of each external interface is calculated considering its number of roaming subscribers, the type of signaling and the traffic model of those subscribers. The total number of roaming subscribers will also affect the subscriber connection quantity and the signaling load within the NaaS Operator EPC.

2.3 Mobile Core HLD Inputs Description

There is a wide variety of options involved in the mobile core design, so to narrow them, some inputs have to be defined at the beginning of the design process. Identifying the most important inputs and how these inputs impact the overall process is a key step towards an optimized Mobile Core HLD.

The following table contains the most important inputs to develop the Mobile Core High Level Design:

Input Required	Description	Impact	Source
Mobile Core Architecture	Architecture of the overall Mobile Core Solution, Service Definition and its required Network Elements.	Architecture will drive the overall HLD.	Mobile Core Architecture Module
Roaming Strategy	Roaming agreements with other MNOs and its approach to interconnection (Local breakout or Home routed).	It will impact on the Equipment and Interface Capacity.	Mobile Core Architecture Module
Interconnection Requirements	Requirements and approach for interconnection to other MNOs and to existing 2G/3G core infrastructure.	Interconnection Assessment and Capacity Planning are tightly related to the existing infrastructure.	Mobile Core Architecture Module, Existing Operator Data
High Availability Mechanisms	Mechanisms to assure the Service Level Agreement, defined as part of the architecture.	Redundancy techniques are based on this premise.	Mobile Core Architecture Module
Operator Network Data	Information related to existing infrastructure (Transport, RAN, Mobile Core).	Accurate information of existing networks will help Interconnection and Networking Considerations as well as Capacity Planning.	Operator Network Data, Existing Operator Network
Transmission HLD	Document containing a high-level view of the transport solution.	Interconnection and Networking Considerations are based on transport information.	Transmission HLD Module
RAN HLD	Document containing a high-level view of the RAN solution, including the expected and forecasted users.	Capacity planning and forecast are based on user information.	RAN HLD Module

Table 1 Inputs for the Mobile Core HLD Module

2.4 EPC Core Networking

The interfaces within the EPC and to external networks use a combination of Layer 2 (L2), Layer 3 (L3) and upper-layer protocols to communicate. Many of the EPC interfaces have specific protocol requirements; however, for other interfaces, the NaaS Operator must select the protocols to be used as part of the HLD. The following sections contain a quick overview of L2 & L3 protocols.

2.4.1 Layer 2 Interworking: Ethernet Switching

Layer 2 switching is the easiest way to provide connectivity in a network and it is used to connect all the servers in a virtualized environment. This mechanism will enable NaaS operators to build networks whose hosts can communicate with each other within the same physical network. However, the NaaS Operator may need to separate certain elements or type of traffic which can be done through VLANs

Virtual Local Area Networks (VLAN) are switched networks that are logically segmented on a functional basis, instead of an actual physical basis. It is used extensively in order to deploy logically independent Ethernet networks over the same Ethernet infrastructure. For example, members of the same Ethernet network should be able to communicate with each other. If the switch implements VLANs, the devices within the network can be segmented and separated logically so the communication only happens between members of the same logical network. Further guidance for VLAN design is provided in section 3.1.1.

2.4.2 Layer 3 Interworking: Dynamic Routing Mechanisms

Routing is needed for the NaaS operator to support inter-VLAN communication and to connect to other network domains such as external networks or the Internet. If we take the previous VLAN example, we would be able to communicate between logical networks (VLANs) by adding a router to the Ethernet infrastructure and configure it with a routing mechanism. It is important to note that the VLAN intercommunication can be selectively done. For the EPC implementation, we can administratively communicate two or more logical interfaces by enabling the communication on the router side (e.g. all O&M interfaces across different network segments).

There are two types of routing mechanisms: static and dynamic. Static routing refers that the routing information does not change and it is configured and updated manually on each equipment. Static routes are only used when managing one or two routes and no changes in the network are expected. On the other hand, dynamic routing refers to the routing information being updated automatically on each equipment according to the network changes (e.g. new connections) and conditions (e.g. delay, throughput). It is strongly recommended to always implement dynamic routing because it eases the management and adapts to network growth.

In the following review, only dynamic routing is revised due to the aforementioned capabilities. Figure 7, shows the different classification of dynamic routing protocols, which is reviewed in the section below.

Figure 7 Routing Protocols Classification

2.4.2.1 Dynamic Routing Protocols

Interior Gateway Protocols (IGP)

An Autonomous System (AS) or routing domain is the unit of the router policy. It refers to a single network or a group of networks controlled by a common network administrator (e.g. the NaaS Operator EPC network). The IGP enables automatic routing for networks within the same AS, which is also referred to as intra-AS routing. IGPs include Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), and Intermediate System to Intermediate System (IS-IS); and can be classified in two main categories based on the information they provide to route: Distance Vector and Link-State routing protocols.

The choice of the routing protocol to be implemented is generally based on the network operator capabilities and network size. For the NaaS Operator environment, OSPF and IS-IS are the recommended protocols. Further discussion of the protocols, pros and cons can be found in the Transport & IP Architecture Module.

Exterior Gateway Protocols (EGP)

EGPs are used for routing between autonomous systems, which is also referred to as inter-AS routing. Interconnection between service providers and large companies is performed using an EGP.

The Border Gateway Protocol (BGP) is the de-facto EGP and is the official routing protocol used on the Internet. Even though BGP is an inter-AS protocol, it can still be used inside an AS as a pipe to exchange BGP updates among gateway routers belonging to the same AS, thats why BGP always requires an IGP to operate. BGP connections inside an AS are called Internal BGP (IBGP), whereas BGP connections between ASs are called External BGP (EBGP).

Figure 8 shows a BGP example where router R2 is receiving routing advertisements from R1, since the AS between R1 & R2 are different, R2 registers the routes into his routing table. When R3 receives the routing advertisements from R2, it discards the ones that belong to the same AS (AS-2) and only forwards the routes from AS-1 (acting as a pipe for routing advertisements).

Figure 8 EBGP and IBGP application diagram

BGP allows for easy traffic manipulation, so the NaaS operator will use it when connecting to networks in domains out of the control of its own administration, for example, to an Internet Service Provider (ISP) and to customer MNOs. These external networks cannot be trusted so the exchanged information should be carefully controlled with routing policies. However, if the NaaS operator only has one connection to an external domain (e.g. ISP), BGP is not needed and the use of static routes can be an option to provide connectivity (not recommended).

2.5 Network Element (NE) Capacity Planning Guidelines

Capacity Planning is a process that estimates the requirements of the network according to the expected services, subscribers and number of connections to external networks. The NaaS Operator must execute a Capacity Planning process in order to dimension the equipment and interfaces according to its needs. To facilitate capacity planning the following sections will be explored:

• Capacity Dimensioning: General procedure for the estimation of traffic and signaling loads according to the expected subscribers. It includes the sizing of the interfaces to external networks.
• Network Elements Dimensioning: Calculation of the most common parameters to dimension the number of EPC and PCC elements that will be required in the network.

2.5.1 Capacity Dimensioning

Capacity forecasting is the network planning stage aimed to calculate the network needs to obtain an effective network, both in terms of cost and performance. The steps of the dimensioning stage are:

1. Estimate the traffic that will be generated by all subscribers.
2. Estimate the capacity demand for every network element.
3. Calculate the number of network elements.

It should be noted that the total traffic generated consists of the user plane traffic and the signaling generated by every connection/session.

Step 1. The services offered by the network and the number of subscribers will directly drive the total traffic that the network needs to handle. To ease the capacity planning process, it is strongly recommended to separate Control Plane (CP), and User Plane (UP) traffic.

The User Plane (UP) is deeply correlated to the number of subscribers, the to-be-offered services, service penetration and the service profile.

The Control Plane (CP) is driven from user behavior in terms of mobility, service usage frequency and durations of active and idle behavior.

Specific methodology for calculation is provided in section 3.2.

Step 2. The capacity estimation for every network element is linked through a direct relation of the maximum number of users at busy hours (peak rates) and the role of each mobile core element. For logical entities with control plane functionality (e.g. MME), the number of signaling operation requests will be the main driver. In contrast, the ones with user plane functionality (SGW, PGW), the session establishment and data forwarding will have a major impact. The methodology to estimate the capacity demand for network elements is presented in section 3.2.

Step 3. To calculate the number of required network elements (NE), it is necessary to run a quick survey of commercially available equipment to know an average capacity for each metric. Once the average metrics are known, the required network element quantity is calculated as shown in the following equation:

(Eq. 1)

Where is the NE quantity, is the n-th metric for one NE estimated in Step 3, is the n-th average metric for one NE and is the number of metrics one NE has (see Table 2).

The most common dimensioning parameters for the EPC and PCC elements are shown in Table 2. It is important to mention that for some vendors the metrics can be simplified to number of active users and total subscribers. The next table contains the metrics for each EPC logical element:

Network Element	Metric	Units
MME	Simultaneously Attached Users (SAU)	Subscribers
	Idle to active transition/second	Transactions per second (Tps)
	Tracking Area Update Requests	Tps
	Handover requests	Tps
SGW/PGW-C	Number of Active Bearers/Sessions	Bearers/Sessions
	Number of transactions completed in one second	Tps
SGW/PGW-U	Data Forwarding Capacity	Gbps
HSS	Number of Users Supported	Subscribers
PCRF	Operation Capacity	Tps
OCS	Number of subscribers to be record	Subscribers
	Number of transactions completed in one second	Tps
OFCS	Number of subscribers to be record	Subscribers
	Number of transactions completed in one second	Tps

Table 2. EPC/PCC Dimensioning parameters

3 Functions & Methodologies (How-To)

This section discusses the methodologies to perform critical tasks/subtasks involved in the Mobile Core design process, such as Interconnection Requirements, Capacity Forecast, and VNF Dimensioning. These critical tasks will help in the E2E process to reach a successful HLD recommendation.

3.1 Interconnection Requirements Definition

The Tx & IP Architecture Module establishes the protocols to be used in each of the network domains (last-mile and aggregation). Additionally, this module examines the alternatives to implement connections within the core elements and connections to external networks.

Most of the requirements and, consequently, the networking protocols are given by the network that is required to interconnect. The Mobile Core Architecture Module defines the connections to other networks (e.g. Internet) and through roaming agreements (to other MNOs). In this section, networking protocols for those interconnections are defined.

It is strongly recommended that the NaaS Operator implements the most common L2 & L3 protocols since this will facilitate interconnection. However, when interconnecting to legacy 2G/3G networks, some legacy protocols may be required.

The networking protocols can be subdivided into the following groups:

• Layer 2 Protocols
• Layer 3 Protocols
• Layer 4 Protocols
• Upper Layer Protocols

3.1.1 Layer 2 Recommendation

For Layer 2 (L2), even though there are several options to choose, the most conventional protocol is Ethernet and it can be over copper or fiber optic. It is always recommended to use Ethernet, thus avoiding interoperability issues.

In terms of VLAN segmentation, it is recommended to allocate VLANs for specific purposes such as O&M, or EPC interfaces. The recommendation should look as follows:

• One VLAN for all O&M Interfaces so they can be isolated from the rest of the traffic.
• One for each EPC interface (e.g. S1-U, S1-MME, S11, S5/S8) so a per-interface isolation is achieved.

It is also recommended that the VLAN assignment for the MME follow the guidelines of the Tx HLD Module.

3.1.2 Layer 3 Recommendation

In terms of Layer 3 (L3), the most standardized protocol is Internet Protocol (IP). Routing protocols Open Shortest Path First (OSPF), Border Gateway Protocol (BGP) and Intermediate System to Intermediate System (IS-IS) operate at this layer together with IP. As stated in section 2.4.2, OSPF is recommended for Mobile Core internal routing in the NaaS environment due to its adaptability, flexibility and easiness of management. In addition, BGP should be considered by NaaS operators for boundary routing such as connection to other MNOs and to the Internet.

For example, for the EPC, the SGi interface is a 3GPP standardized point of connection between the Packet Data Network Gateway (PGW) and external networks (e.g Internet or IP Multimedia Subsystem, IMS). The SGi logical interface is based on Ethernet + IP protocols + BGP routing mechanism. In contrast, the connection between (Serving Gateway) SGW and PGW is the 3GPP-standardized interface S5/S8. The S5/S8 logical interface is based on Ethernet + IP protocols + IGP routing mechanism. Please refer to Figure 9.

Figure 9 Layer 3 Recommendation for inner and outer EPC interfaces.

L3 Security Recommendation

Security and privacy have always been a concern for all the networks and the EPC is not the exception. For connections within the EPC, it can be guaranteed that a certain degree of security and privacy is met because the infrastructure will be owned by the NaaS Operator. On the other hand, the connections to external networks will go through domains out of the control of the NaaS Operator so it is necessary to implement mechanisms to provide security to these outer connections.

Layer 3 Virtual Private Network (L3VPN) and IP Security (IPSec) are mechanisms to provide authentication and encryption of data packets between two network elements over the IP protocol. The advantages and disadvantages of L3VPN and IPSec are contained in the following table.

	Pros	Cons
IPSec	● Transparent to applications. ● No impact on higher layers. ● Can Apply to real-time traffic. ● IPSec offers encryption to: payload, header and routing information.	● Since IPSec establishes a tunnel between two networks, the security breaches at IP level on the remote network are shared to the local network and vice versa. ● ISPs might consider anything IPSec-encrypted to be a "business-class" transmission and rate it at higher costs. ● Increased bandwidth and latency due to authentication and encryption process plus the IPSec overhead addition. ● NAT and Firewall might cause problems when IPSec is used.
L3VPN	● Extremely scalable VPN architecture. ● Allows the NaaS Operator to simplify its WAN routing by allowing direct routing information sharing between the equipment (router) on the edge of its own AS to the edge equipment of external networks or AS. ● Supports QoS and real-time traffic. ● Support tight SLAs with fast failover and guaranteed bandwidth.	● Only IP traffic is supported which will result in lack of legacy protocol/ application support. ● Customers do not have complete control of their WAN IP routing. ● Customers must share the routing responsibility with the service provider. ● Do not natively (by default) offer the strong authentication and encryption of secure VPNs such as IPsec.

Table 3. IPSec and L3VPN Pros and Con

In terms of security IPSec or L3VPN are largely supported and recommended, especially when connecting to external networks.

Further details of L3 routing mechanisms can be found in section 2.4.2.

3.1.3 Layer 4 Recommendation

There are only a few Layer 4 (L4) protocols commonly used. Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and Stream Control Transmission Protocol (SCTP)

User traffic usually makes use of TCP or UDP and this should be transparent to the Mobile Core Network.

On the other hand, protocols to be used for signaling traffic may be defined by 3GPP standards and the NaaS Operator cant change them. Here, its important to note that some signaling interfaces by standard, require the use of Stream Control Transmission Protocol (SCTP). Whenever the NaaS Operator can choose the L4 protocol in a signaling interface, SCTP should be selected over TCP, because it has the same functionality plus enhanced capabilities.

3.1.4 Upper Layers Recommendation

GPRS Tunnel Protocol (GTP) and Diameter protocols are specified by 3GPP standards to be used in several Mobile Core interfaces on top of Layer 4. GTP is used for general communication and signaling (Control/User Plane), whereas Diameter is mainly used for authentication, authorization and accounting (AAA).

One of the most important scenarios where these protocols are required is for roaming. In home routed scenarios S6a (Diameter-based) and S8 (GTP-based) interfaces are required while in local breakout S6a and S9 (Diameter-based) are needed.

Diameter-based Interfaces

Diameter Edge Agent (DEA)/ Diameter Routing Agent (DRA) is an entity with routing capabilities at the Diameter layer. DEA/DRAs are required for diameter-based equipment for successful roaming interconnection since it will forward the diameter messages to the correct equipment. In other words, it means that for all external connections that are based on the diameter protocol, it is recommended to implement a single DRA.

Figure 10 shows the typical protocol stack for diameter-based interfaces such as S9 (Home to Visitor PCRF), S6a (MME to HSS) and Gx (PGW to PCRF) with an intermediate DRA.

Figure 10 Typical Networking with a DRA.

GTP-based Interfaces

For GTP, no requirements are needed since GTP is ready to cope with external and internal networks. For further configuration details, please refer to Mobile Core LLD Module.

Figure 11 and Figure 12 shows the typical protocol stacks for external and roaming interfaces where GTP is used.

Figure 11 Protocol Stacks for an eNB connection to the EPC (MME and SGW).

Figure 12 Protocol Stacks for external networks.

3.2 Capacity Forecast Analysis

Capacity forecasting is a process that uses subscriber forecasts from the RAN & Tx HLD Modules to estimate EPC Core interface and equipment dimensioning.

The inputs to perform capacity forecast are shown in Table 4. These inputs can be obtained from the RAN & TX HLD Modules and, in most cases, from other networks or estimates shared by the customer MNOs. If these are not available, values in the example presented throughout section 4.2 can be used.

Input	Description
	Total number of users in the network, including those from customer MNOs [users]
	Percentage of the overall users that are users of a specific service [%]
	Percentage of active users during the busy hour [%] (can be applied to specific scenarios, e.g. active subscribers due to voice or data service).
	Percentage of Simultaneous Attached Users (SAU) during the busy hour [%] (SAU have at least one active/idle session established)
	Average data transmitted in a session at busy hour for a given service [MB/session]
	Number of sessions per user at busy hour [sessions]
	Average number of attach attempts per user at busy hour [transaction/user]
	Average number of detach attempts per user at busy hour [transaction/user]
	Average number of bearer activation/deactivation operations per user at the busy hour [transaction/user]
	Average number of idle/active transitions per user at the busy hour[transaction/user]
	Average number of Tracking Area Updates (TAU) procedures per user at busy hour [transaction/user]
	Average number of HO procedures attempted per user at busy hour [transaction/user]

Table 4. Inputs for Capacity Forecast Analysis

Often, Mobile Core Solution Providers only require the total Number of Users and Number of active users during the busy hour to dimension the solution. However, for more detailed dimensioning, the NaaS operator can follow the process described in the subsequent sections, which addresses the dimensioning of traffic, signaling, Mobile Core NEs and interfaces. As a complement, the Mobile Core Capacity Forecast Widget is provided to NaaS Operators to facilitate all the calculations related to Capacity Forecasting.

3.2.1 Traffic Dimensioning

Traffic Dimensioning estimates the total traffic generated by the total expected users. It is the input to calculate the forwarding capacity of the SGW and PGW entities and, additionally, S1-U, SGi and S5/S8 Interfaces.

Step 1. Users per service.

Capacity planning must begin with the user forecast from RAN HLD Module and penetration for each service such as data and voice. For a given service, the relationship to the estimated users is given by the following formula:

(Eq. 2)

Where: is the number of users for a given service in the network [users].

Step 2. Service Profile.

Each service will have a specific traffic model, it will depend on the frequency of usage () and the amount of data transferred in every session (). The next equation shows this relationship:

(Eq. 3)

Where: is the amount of data per service per user at busy hour [MB].

After calculating the total amount for each service, it is necessary to translate into bandwidth by the next equation:

(Eq. 4)

Where: is the bandwidth per user for a specific offered service at busy hour [Mbps].

Step 2. Data Traffic.

The total data traffic () is calculated by the sum of the products of the service bandwidth () and the active users per service () at the busy hour. This calculation will help the NaaS Operator to estimate the traffic that will go through interfaces such as S1-U, S5/S8 and SGi.

First, the active users per service at busy hour are calculated as follows:

(Eq. 5)

Then the total data traffic ():

(Eq. 6)

Where is measured in Mbps.

3.2.2 Signaling Dimensioning

The Signaling dimensioning estimates the total amount of signaling load generated by the users due to registration, mobility, security and session establishment procedures. The first step is to calculate the number of simultaneous attached users ()

(Eq. 7)

Then, the signaling calculation (number of transactions per second) must be based on this number of simultaneous attached users multiplied by the number of attempts for a given signaling procedure at peak hours. For Attach procedures:

(Eq. 8)

Where: is the average number of attach attempts per user at busy hour [transaction/user] and is the total number of attach procedures [transaction/hr].

For Detach procedures:

(Eq. 9)

Where: is the average number of detach attempts per user at busy hour [transaction/user] and is the total number of detach procedures [transaction/hr].

For Bearer establishment and termination procedures:

(Eq. 10)

Where: is the average number of Bearer establishment attempts per user at busy hour [transaction/user] and is the total number of Bearer establishment procedures [transaction/hr].

For Bearer Modification and termination procedures:

(Eq. 11)

Where: is the average number of Bearer modification attempts per user at busy hour [transaction/user] and is the total number of Bearer modification procedures [transaction/hr].

For Tracking Area Update procedures:

(Eq. 12)

Where: is the average number of TAU attempts per user at busy hour [transaction/user] and is the total number of TAU procedures [transaction/hr].

For Handover procedures:

(Eq. 13)

Where: is the average number of handover attempts per user at busy hour [transaction/user] and is the total number of handover procedures [transaction/hr].

For Idle to Active state transition procedures:

(Eq. 14)

Where: is the average number of active/idle state transition attempts per user at busy hour [transaction/user] and is the total number of active/idle state transition procedures [transaction/hr].

In the end, the sum of all the procedures that occur at the busy hour per logical entity will drive the dimensioning and these procedures must not surpass the 80% capacity of each logical entity. For example, for the MME, the following equation applies:

(Eq. 15)

Where is the total number of procedures at busy hour at a specific interface or logical entity [transaction/hr]. Guidance to modify the equation above for other logical entities is provided in the example in section 4.2

Finally, the only method to know the number of occurrences is to measure in live network these average numbers, but considering the EPC is a new deployment, a good estimation of occurrences per user at busy hour is contained in Table 5. It is based on user behavior from other networks.

Type of Signaling Procedure	Average number of Occurrence per user per hour
Attach ()	1
Detach ()	1
Idle to active transition ()	5
Bearer Establishment ()	0.5
Bearer Modification ()	0.1
Tracking Area Update ()	0.3
Handover ()	0.2

Table 5 Occurrences for every type of signaling procedure

3.2.3 Interface Dimensioning

Interface Dimensioning calculates the total amount of traffic of each EPC logical interface according to the corresponding signaling procedures and data forwarding (CP+UP).

Control Plane (CP):

The CP is where all the signaling procedures are carried out so for the traffic load calculation it is assumed that for every procedure attempt 100 KB are used. Under this premise, we can calculate the bandwidth that the signaling is generating in every external interface. The interfaces are characterized by the type of signaling procedures they support:

For S1-MME Interface:

• Attach
• Detach
• Bearer Establishment
• Bearer Modification
• Idle to active state change
• TAU
• Handover

For S6a Interface:

• Bearer Establishment
• TAU

For S8 Interface:

• Bearer Establishment
• Bearer Modification
• Data Traffic

For S9 Interface:

• Bearer Establishment
• Bearer Modification

The equation for calculating the amount of signaling traffic is the same for all the above interfaces.

(Eq. 16)

Where: is the Interface Control Plane [kbps], are the Signaling Messages per subscriber at busy hour at a given interface [messages/subscriber/hour].

For example, for S1-MME interface assuming a of 50% for 10k users.

S1-MME will have Attach, Detach, Idle to active state change, TAU & Handover procedures so based on Table 5.

User Plane (UP):

The only interfaces who carry UP traffic are: S1-U, S5/S8 and SGi. These interfaces will carry the data from all the users towards the Internet so the user traffic load will be the same in non-roaming scenarios.

(Eq. 17)

For roaming scenarios, there are two possible options:

1 Local Breakout:

The interfaces that will be connected to other MNOs networks are S6a and S9 as shown in Figure 13. This will have no impact on the previous equation.

Figure 13 Local breakout architecture.

2 Home Routed:

The interfaces that will be connected to other MNOs networks are S6a and S8 as shown in Figure 14.

Figure 14 Home Routed Roaming Architecture.

For this scenario, the S8 interface will carry the user traffic and signaling to other MNO networks and it should be calculated based on the roaming subscribers:

(Eq. 18)

Where: is the number of active users which correspond to roaming.

The load of the S5 and SGi interfaces on the NaaS Operator EPC will decrease due the S8 traffic redirection to the corresponding MNOs. The equation (16) will transform into:

(Eq. 19)

Where: is the total traffic throughput corresponding to the S5 and SGi interfaces in the home-routed roaming scenario.

3.3 VNF Dimensioning

After Capacity Dimensioning is done, the following step is mapping these requirements to VNFs. There are three steps for VNF Dimensioning. First, the minimum VNF requirements according to each type of VNF need to be defined. Second, the selection of the VNF Mapping option (if possible) according to vendors offering and NaaS Operator requirements. Third, the VNF/NE mapping where it is defined the number of VNFs or NEs.

3.3.1 VNF Requirements definition

The EPC elements are needed to be mapped to VNFs, but the type of VNFs (CP, UP or Database) is assigned according to the type of NE is serving. For example, UP VNFs can be mapped to logical entities such as SGW or PGW. The VNFs for the EPC are divided into the following categories:

• User Plane VNFs: Cover all NE related to packet handling in an end-to-end communication between edge applications. These tasks are expected to be very intensive in I/O operations and memory R/W operations. For example: S/PGW-U. The specific features needed are:
• Hyperthreading support
• Control plane VNFs: Cover any other Network Functionality that is not directly related
  to the end-to-end data communication between edge applications and involve signaling processing. These are expected to be very intensive in CPU processing and memory R/W operations. For example: MME/SGSN, S/PGW-C, PCRF. The specific features needed are:
• Hyperthreading support
• SR-IOV / DPDK usage
• Database VNFs: Cover all NE related to repositories, they involve disk storage and are very I/O storage intensive. For example: HSS. The specific features needed are:
• High IOPS

Where:

• Hyperthreading support: This refers to enabling a second execution thread to a processor core, to increase efficiency.
• SR-IOV / DPDK usage: Use of acceleration technologies to reduce the delay imposed by the virtualization layer.
• High IOPS: It means that the application will need to support a high number of read and write operations.

3.3.2 VNF Mapping

Once the traffic estimation for all planes in the logical equipment is done, the mapping into Virtual Network Functions (VNF) can be performed. There are several approaches when doing it:

Mapping Type [VNF:NE]	Description	Advantages	Disadvantages
1:1	Each VNF will contain 1 NE.	Easy Capacity match Mid level of reliability	Less Flexible
1:N	1 VNF will handle several NE. The capacity of the VNF must meet all the NE requirements.	Less Number of VNFs	Reduced Flexibility & Adaptiveness Limited Scaling capacity Low level of reliability due to single point of failure
N:1	1 NE will be divided into N VNF. The division can be in terms of networking, processing or data forwarding capacities.	Improved Flexibility & Performance Resource Efficient VNF per service Granularity High level of reliability	Greater number of VNFs to handle

Table 6. VNF to NE Mapping Available Options

Most of the time, this mapping is not offered by the vendors as a selection since they may have already defined one beforehand. For the options which the NaaS Operator can select a type of mapping, it is recommended to choose one in the following order: N:1, 1:1 and 1:N.

3.3.3 VNF/Network Element Dimensioning

After the calculation of the user traffic amount and signaling, it is mandatory to map the corresponding metrics into logical entities such as MME, HSS, SGW, PGW (or VNFs representing them). If the solution is a core-in-a-box type, the calculation must be based on the metrics the solution provides, but the logic is the same for quantity calculation.

For logical entity quantification, it is necessary to know the specification from vendors of the maximum load that an entity can bear in terms of simultaneous attached users () and signaling handling load (). Below, formulas used to estimate the amount of logical entities are presented.

The signaling procedures that the logical entities must cope with are given by the following relationships:

For HSS , it must be considered:

• Attach
• Detach
• TAU

For MME , it must be considered:

• Attach
• Detach
• Bearer Establishment
• Bearer Modification
• Idle to active state change
• TAU
• Handover

For SPGW , it must be considered:

• Bearer Establishment
• Bearer Modification
• Idle to active state change

HSS dimensioning:

(Eq. 20)

Where: is the Subscriber Capacity of the HSS [users/HSS] and is the maximum capacity for signaling handling of the HSS [trans/sec/HSS].

MME Dimensioning:

(Eq. 21)

Where: is the Simultaneous Attached Users Capacity of the MME [users/MME] and is the maximum capacity for signaling handling of the MME [trans/sec/MME].

SGW/PGW Dimensioning:

(Eq. 22)

Where: is the Maximum Bearer handling capacity of the S/PGW [bearer/SGW or PGW] and is the maximum capacity for signaling handling of the S/PGW [trans/sec/ SGW or PGW].

4 E2E Process Flow

This section presents an end-to-end process to perform a High-Level Design for the Mobile Core Network. This process is generic and it will suit most of the requirements of the NaaS Operator, further customization can be added to deliver a better design to each NaaS Operator scenario. The steps of the E2E flow will be discussed in the upcoming sections.

4.1 End-to-end Process Overview

As presented in Figure 15, the end-to-end process consists of four main steps.

Figure 15 Module Functional View

The first step is the Interconnection Assessment, in which the NaaS Operator selects the best networking protocols and entities when connecting to external networks. As this step defines the general network description and function, it is the strongest input-dependent and its output provides significant insights to the next processes.

Capacity Planning consists of the calculation of the forecasted traffic on the interfaces and logical elements of the mobile core network based on the RAN HLD forecasted users and traffic information combined with the mobile core architecture input.

VNF High Level Design comprises the estimation of the VNF dimensioning and the Bill of Quantities (BoQ) corresponding to the mapping into logical entities.

Finally, the redundancy assessment primarily involves the evaluation and guide to select the redundancy and availability mechanisms.

4.2 Step-by-step Analysis

In this section, each of the steps in the E2E process are examined to provide practical guidance for NaaS Operators, describing the range of implementation options. The steps can be further customized according to the NaaS Operator requirements and constraints.

In order to facilitate understanding of the process design flow, a Design Example is followed along each of the process steps. Before getting into the details of the process, an overview of the design example scenario is presented.

Design Example: Scenario Definition

In this example, the process to generate the HLD Design for a NaaS Operator which will initially own 500k subscribers and will provide service to one MNO through a home-routed roaming scheme. EPC architecture is shown in Figure 16.

Figure 16. Design Example Scenario.

Inputs for this scenario are detailed below:

-Elements to be deployed: MME, SGW, PCRF, PGW, HSS and DRA (yellow equipment).

-Home-routed Roaming scenario

-Voice service: VoIP-only.

-Subscriber Forecast (NaaS) (): 500,000 users + 100,000 forecasted over the next two years.

-Subscriber Forecast (MNO #1) ( for roaming): 50,000 users.

-Percentage of Simultaneous Attached Users (): 50 %.

Service Details:

-Data Service Penetration ( for Data): 100 % of the users

-Voice Service Penetration ( for Voice): 100 % of the users

–User behavior ():

50% Data Usage at peak hours.

20% Voice Usage at peak hours

Based on other networks traffic models, the following traffic model is assumed for Voice and Data Services:

After a quick survey from vendors:

– NE Capacity Characteristics:

4.2.1 Interconnection Assessment

The steps will help to select the best networking protocols and entities when connecting to external networks towards a successful interconnection.

Step 1. Select the most appropriate Networking protocols.

For L2, the most commonly used protocol is Ethernet.

For L3, we have a variety of internal routing protocols such as IS-IS, OSPF. The operator should select one from section 2.4.2 according to the needs and the capabilities of the NaaS Operator. In the case of exterior routing protocols, we only have BGP which will be used when connecting to external networks such as the Internet.

For L4, the selection between TCP, UDP and SCTP is simple since most of the standardized interfaces already define the L4 protocol to be used, see section 3.1.3.

Step 2. Selection of Upper Layer protocols for interconnection.

As stated in section 3.1, there are two groups of interfaces depending on the protocol they use: GTP and Diameter. When connecting to external networks only diameter has an impact on the design.

For Diameter-based external interconnections the use of DRA is always recommended and must be implemented. For internal diameter connections, the use of DRA is optional.

Design Example

Step 1. Since there is no special requirement from the Mobile Core Architecture to support legacy protocols nor limitations on routing and switching, the selection of networking protocols is:

L2 Protocols: Ethernet

L3 Protocols: IP (OSPF + BGP)

L4 Protocols: Given by interface specification.

SCTP: S1-MME & S6a.

TCP/UDP: S1-U & S8.

Step 2. From the topology, it can be seen that it will need a S8 interface between the home SGW to Visitor PGW. Additionally, a diameter-based S6a from the home MME to the Visitor HSS.

For GTP:

S8 interface is GTP and it does not need any special requirement

For Diameter:

Implementation of DRA for S6a signaling messages between MME and two HSS (local and visitor).

Finally, SGi:

Since the L3 protocol is already selected, no need to further selection on the SGi interface.

4.2.2 Capacity Planning

The objective of this step is to perform the capacity calculation for each element and interface based on the user traffic model.

Step 1. Traffic Dimensioning

Traffic Dimensioning estimates the total traffic generated by the total expected users. It will be used for interface and logical entities dimensioning. Through these steps, the following metrics are calculated following the methodology in section 3.2.1:

• Total number of users and per service
• Total user traffic load
• Total signaling traffic load

Step 2. Signaling Dimensioning

The Signaling dimensioning estimates the total amount of signaling load the users are generating due to registration, mobility, security and session establishment procedures. Based on the methodology presented in section 3.2.2, the following metrics are the output for this step:

• Calculation of total signaling procedures
• Calculation of signaling procedures per interface

Step 3. Interface Dimensioning

Interface Dimensioning calculates the total amount of traffic of each EPC logical interface according to the corresponding signaling procedures and data forwarding (CP+UP). It will be used for interface and logical entities dimensioning. The following metrics are the output for this step, which are calculated as described in section 3.2.3:

• Calculation of every traffic load for external interfaces (Control Plane + User Plane) (e.g. S8, S6a, S1-MME, S1-U, S9, SGi)

A useful widget for all the calculations related to Capacity Planning can be found on the Mobile Core Capacity Forecast Widget.

Design Example

Step 1. Traffic Dimensioning

The first step is to calculate the total number of users. The following formula considers the expected users, the forecasted users and the roaming expected users as well.

The next step is to calculate the number of users per service. The total users for Data Services:

The total users for Voice Services:

Number of active users at peak hours for data and voice, respectively:

For Voice and Data Services, the following traffic model is used. It is based on the average user behavior on other live networks.

The traffic types of Web Browsing, Streaming, Email and Gaming correspond to Data services while Voice Calls corresponds to Voice services. So the bandwidths are:

Total bandwidth usage for the internet connection:

Step 2. Signaling Dimensioning

The first step is calculating the Simultaneous Attached Users for calculating the number of signaling procedures. To calculate the Simultaneous Attached Users:

From table 1 we can get the average number of occurrences for each connected subscriber. The calculation is it done to the following signaling procedures and then calculated on transactions per second:

Step 3. Interface Dimensioning

For Control Plane interfaces (S1-MME and S5/S8) since we already calculated the operations per second in step 3:

For S1-MME:

For S5/S8:

For User Plane interfaces (S1-U, S5/S8 and SGi):

For S1-U:

Since it is a Home Routed scheme for roaming:

For S8:

So the total traffic for the S8 user plane is:

For S5 & SGi (Since it is home routed roaming scenario):

Summary:

Finally, for interfaces which have a UP and CP, the total loads must be summed up:

For S5:

For S8:

The following table summarizes for all the external interfaces and expresses the capacities in Mbps:

4.2.3 VNF High Level Design

For the VNF High Level Design, three aspects must be defined: VNF Requirements, Type of VNF Mapping and VNF/NE Dimensioning.

VNF Requirements: From section 3.3.1, the mandatory specifications for each VNF is contained. These mandatory characteristics should be matched when it is possible to select from the vendors options. In the case that core-in-a-box option or 1:1 Mapping option is going to be implemented, the collective mandatory requirements should be matched by the solution.

Type of VNF Mapping: As seen in section 3.3.2, the advantages and disadvantages should drive the decision. For the options which the NaaS Operator can select a type of mapping, it is recommended to choose one in the following order: N:1, 1:1 and 1:N.

If several options are available for one mapping selection, a VNF/NE dimension can be performed before this decision is made.

VNF/NE Dimensioning: The section 3.3.3 indicated how is the process to follow to calculate the number of VNF or NE (depending on the mapping option). If the mapping option is not already chosen, a VNF dimensioning can be performed to help deciding.

Design Example

VNF Requirements:

From section 3.2, it is recommended to match these mandatory requirements to the VNF from available vendors when selecting a virtualized solution.

The VNFs for the User Plane must have Hyperthreading support and SR-IOV/DPDK. The VNFs that include the User Plane type are the SGW and PGW VNFs.

The VNFs for the Control Plane must have Hyperthreading support. The VNFs that include the Control Plane type are the MME and PCRF VNFs.

Finally, the VNFs for Database must have High IOPS features. The VNFs that include the Database type are the HSS VNFs.

VNF Mapping:

As the vendor in this example does not allow to select the VNF Mapping and states in 1:1, this mapping option is selected.

VNF/NE Dimensioning: Logical Entities or VNFs Quantity Calculation. In this example, the only option is 1:1 so VNF and NE Quantity are the same.

For the logical entities modeling, the vendor provides the following metrics:

From section 3.3.3, the quantity calculation is based on the metric capacity at 80% (Operating Capacity) considering the total amount of user traffic and signaling loads:

For the HSS:

For the MME:

For the SGW & PGW:

In the end, the numbers of required elements are:

4.2.4 Redundancy Assessment

Redundancy on Mobile Core can be implemented on different levels and they can all be employed at the same time. Although this requirement comes from the Mobile Architecture Module, it can vary in the implementation approach. For all the available mechanisms, the major categories are:

1. Hardware Level Resilience
2. Application Level Resilience

Step 1. Selection of Hardware Level Resilience.

For the Mobile Core HLD, the only option that can be selected related to redundancy mechanisms is the networking characteristics. The reason is that at this point, no hardware has been selected and consequently, no storage scheme is defined.

For Network high availability: bonding mechanisms and physical redundancy schemes can be implemented (2N, N+M and N+1).

It is strongly recommended to implement a N+1 as a minimum for any non-crucial (S6a, Gx) interfaces and 2N scheme for the most important ones (e.g. S1-MME, S1-U, S5/S8, SGi).

Bonding mechanism is desired to act a group of physical interfaces as one.

Step 2. Selection of Application Level Resilience.

At the application layer, 2N, N+1 and N+M Redundancy are the options for VNF/NE redundancy and it can be applied in active/active and active/standby. For a small operator it might look excessive to deploy 2N or M+N models and prefer to develop a N+1. For further details, please refer to the Mobile Core Architecture Module.

It is recommended for the most important VNF to have 2N redundancy scheme (MME, SGW, PGW), whereas less crucial VNF can have N+1 application level redundancy.

Design Example

Step 1. Selection of Hardware Level Resilience.

For Network:

For each red interface (S1-MME, S1-U, S5, S8 and SGi), there will be a 2N redundancy since those are considered the most critical interfaces whereas the black ones (S11, S6a) can be implemented through N+1.

Based on 10 Gbps physical interfaces, it becomes clear that for S1-U (8,470 Mbps), S5 (7,862 Mbps) and SGi (7,819 Mpbs), a bonding mechanism is needed to make at least two physical interfaces to work in load sharing mode.

As a summary:

Step 2. Selection of Application Level Resilience

The MME, SGW and PGW will have 2N redundancy mechanisms. The HSS and DRA will have N+1 redundancy mechanism.

In summary:

5 HLD Recommendation

This section presents a methodology to consolidate and generate a final HLD recommendation.

5.1 HLD Recommendation Format & Structure

The main deliverable of this module is the HLD recommendation which contains the overall technical solution, basic design rules, technologies and concepts required to describe Mobile Core Network. The HLD recommendation shall contain the following aspects:

• Overview: High-level description that summarizes the Mobile Core design.
• Fundamentals: A brief description of fundamental concepts to be references on recommendation.
• EPC HLD Requirements:
• Series of specifications or metrics related to Interconnection (protocols, number of connections, roaming scenarios).
• Capacity Planning (Number of users, amount of equipment, Matching Strategy).
• VNF High Level Design: VNF Requirements (VNF hardware requirements), VNF Mapping and VNF/NE Dimensioning.
• Redundancy Assessment (Mechanisms and its implementation across the EPC).
• Mobile Core Equipment Bill of Quantities (BoQ): primary input for Mobile Core LLD in order to generate equipment Purchase Order generation.

5.2 HLD Recommendation Generation

The outputs of the end-to-end process will result in the generation HLD Recommendation. The BoQ can be generated according to the quantity outputs of the VNF High Level Design and the Redundancy Assessment processes.

The NaaS Operator can use the HLD Report Template as a reference for the format and structure of the final document. Further customization can be applied by the NaaS Operator in order to have a better and more personalized result.