REPUBLIQUE DU CAMEROUN REPUBLIC OF CAMEROON

Paix - Travail - Patrie Peace - Work - Fatherland

MINISTEREDEL’ENSEIGNMENT MINISTRY OF HIGHER
SUPERRIEUR EDUCATION
UNIVERSITE DE BUEA UNIVERSITY OF BUEA

FACULTY OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF ELECTRICAL AND ELECTRONICS
ENGINEERING

DESIGN AND IMPLEMENTATION OF A SOFTWARE TOOL TO DO

COVERAGE AND CAPACITY PLANNING FOR 2G(GSM), 3G(UMTS) AND
4G(LTE) NETWORK GENERATIONS

A dissertation submitted to the Department of Electrical and Electronics Engineering, Faculty

of Engineering and Technology, University of Buea, in Partial Fulfillments of the Requirements
for the Award of Bachelor of Engineering (B.Eng.) Degree in Computer Engineering.

By:
NESTOR ABIANGANG ABIAWUH
Matriculation Number: FE15A151
nestorabiawuh@gmail.com
Option: Telecommunication Engineering

Supervisor:Mr. Serge Nouadjep Narcisse 1

2018/2019
DESIGN AND IMPLEMENTATION OF A SOFTWARE TOOL TO DO
COVERAGE AND CAPACITY PLANNING FOR 2G(GSM), 3G(UMTS)
AND 4G(LTE) NETWORK GENERATIONS

NESTOR ABIANGANG ABIAWUH

Matriculation Number: FE15A151

nestorabiawuh@gmail.com

Academic Year: 2018/2019

Dissertation submitted in partial fulfillment of the Requirements for the award of Bachelor
of Engineering (B.Eng.) Degree in Computer Engineering.

Department of Electrical and Electronics Engineering

Faculty of Engineering and Technology
University of Buea

i
 Certification of Originality

I the undersigned, hereby certify that this dissertation entitled “DESIGN AND
IMPLEMENTATION OF A SOFTWARE TOOL TO DO COVERAGE AND
CAPACITY PLANNING FOR 2G(GSM), 3G(UMTS) AND 4G(LTE) NETWORK
GENERATIONS” presented by NESTOR ABIANGANG ABIAWUH Matriculation
number FE15A151 has been carried out by me in the Department of Computer
Engineering, Faculty of Engineering and Technology, University of Buea under the
supervision of Mr. Serge Nouadjep Narcisse.

This dissertation is authentic and represents the fruits of my own research and efforts.

Date :

Student Supervisor

Head of Department

ii
 Dedication
This work is dedicated to my family most especially my parents Late Mr. Abiawuh Richard
Umeno and Mrs. Margret Negeba Abiawuh for their constant love and support in seeing me
through my entire academic life up till now.

iii
 Acknowledgements
First of all I thank the dean of the faculty of engineering and technology, Prof. Tanyi in
particular and the faculty of engineering and technology in general who took confidence in
me and gave me the wonderful opportunity to come and study computer engineering in the
University of Buea. I had a great and valuable experience being part of this prestigious
institution academically and in other domains. I also appreciate Mr. Serge Nouadjep, my
academic supervisor for his constant guidance and support and encouragement throughout
this period.

Also a big thanks to my lecturers who through not only their lectures but numerous advices of
how to make the best out of ourselves as students using our skills and knowledge. Not
leaving out my friends in school, home, cite and over the world, I say thank you for you all
were a source of inspiration in my life academically or socially.

In a most special way, my gratitude goes to my parents, Mr. and Mrs. Abiawuh, brothers,
sisters and every other member of my family for their constant guidance, love and support.
You all made a very big contribution as you have always done throughout my study here in
the university.

Finally, I give thanks to the ultimate giver of life and success, the Almighty God for his
spiritual grace throughout this degree program.

iv
Table of Contents
Certification of Originality ..................................................................................................................... ii
Dedication .............................................................................................................................................. iii
Acknowledgements ................................................................................................................................ iv
Table of Figures .................................................................................................................................... vii
List of Abbreviations ............................................................................................................................. ix
ABSTRACT........................................................................................................................................... xi
CHAPTER 1: INTRODUCTION ........................................................................................................... 1
1.1 Problem Statement .................................................................................................................. 1
1.2 Aim of the project ................................................................................................................... 1
1.2.1 Primary Objective .................................................................................................................. 2
1.2.2 Secondary Objective .............................................................................................................. 2
1.3 Scope of Project ...................................................................................................................... 2
1.4 Project Requirement................................................................................................................ 2
1.6 Project Hypothesis ........................................................................................................................ 3
1.7 Dependent and Independent variables ...................................................................................... 3
CHAPTER 2: LITERATURE REVIEW ................................................................................................ 4
2.1 Radio Planning Process................................................................................................................. 4
2.1.1 Coverage Dimensioning ......................................................................................................... 5
2.1.2 Radio Wave Propagation ....................................................................................................... 5
2.1.3 Propagation Models ............................................................................................................... 7
2.1.4 Link Budget ............................................................................................................................. 10
2.1.5 Calculation of Coverage Radius and Coverage Area .................................................... 11
2.1.6 Number of Cells ............................................................................................................ 12
2.1.7 Important Components of Link Budget Calculations ................................................... 12
2.2 Capacity Planning ............................................................................................................. 17
2.2.1 Capacity planning over a certain area .................................................................................. 18
2.3 Traffic Models ...................................................................................................................... 20
2.3.1 Key definitions for trunked radio systems ........................................................................... 20
2.3.2 Traffic concepts.................................................................................................................... 21
2.3.3 Trunking and Grade of Service ............................................................................................ 22
2.3.4 Blocked calls cleared systems (Erlang B) ............................................................................ 22
CHAPTER 3: METHODOLOGY ........................................................................................................ 26
3.1 Sequential Phases in the Waterfall Model .............................................................................. 27

v
 3.2 Requirement Analysis ................................................................................................................. 27
3.1 Functional Requirements ............................................................................................................ 28
3.1.1 Input Requirements .............................................................................................................. 28
3.1.2 Operational Requirements.................................................................................................... 28
3.1.3 Output Requirements ........................................................................................................... 28
3.2 Non-Functional Requirements .................................................................................................... 29
3.2.1 Software Requirements ........................................................................................................ 29
3.2.2 Secondary Requirements...................................................................................................... 29
3.3 Feasibility Analysis ..................................................................................................................... 30
3.3.1 Economic Feasibility............................................................................................................ 30
3.3.2 Technical Feasibility ............................................................................................................ 30
3.3.3 Operational Feasibility ......................................................................................................... 30
CHAPTER 4: SYSTEM DESIGN AND IMPLEMENTATION.......................................................... 31
4.1 Architectural Review .................................................................................................................. 31
4.1.1 Client tier ............................................................................................................................. 31
4.1.2 Logic / Controller tier .......................................................................................................... 31
4.1.3 Data tier ................................................................................................................................ 31
4.1.4 Model View Controller paradigm ........................................................................................ 32
4.2 System Design ............................................................................................................................ 32
4.2.1 Use Case Diagram................................................................................................................ 32
4.2.2 Process Flow Diagram ......................................................................................................... 33
4.3 Radio Plannex Design and Implementation ................................................................................ 35
4.3.1 Design View of the tool ........................................................................................................... 35
4.3.2 Design of Radio Plannex tool ....................................................................................... 36
4.3.2 Implementation of the Radio Plannex tool .............................................................................. 39
4.3.3 System Parameters Tab: ....................................................................................................... 42
4.3.4 Transmitter side parameter tab:............................................................................................ 42
4.3.5 Receiver side parameters: .................................................................................................... 43
4.3.6 Locate site map tab: ............................................................................................................. 44
4.3.7 Final budget output tab: ....................................................................................................... 44
4.4 Database design: ......................................................................................................................... 45
CHAPTER 5: RESULTS AND CONCLUSION .................................................................................. 46
5.1 Results ......................................................................................................................................... 46
5.2 Conclusion .................................................................................................................................. 49

vi
 5.3 Future work to be done ............................................................................................................... 50
REFERENCES ..................................................................................................................................... 52

Table of Figures
Figure 1 [1]: Radio network planning process ........................................................................... 4
Figure 2[ 9]: Coverage planning procedure ............................................................................... 5
Figure 4 [9] :(a)Image showing Uplink budget calculation flow with parameters (b)Downlink
budget calculation with some parameters ................................................................................ 11
Figure 5[9 ]: Type of sites ........................................................................................................ 12
Figure 10 [2:] High Level Summary of Critical Capacity Affecting Factors ......................... 18
Figure 12 [8 ]: pictorial view of Base station sites display ...................................................... 19
Figure 13[8 ] : Erlang B graph showing channel number against traffic................................. 24
Figure 14: Water fall model of system developement life cycle ............................................. 26
Figure 15 [5]: Image showing MVC architecture and interaction ........................................... 32
Figure 16: Radio Plannex Use case diagram from starUML tool ............................................ 33
Figure 17: 4G LTE coverage planning flowchart diagram from starUML tool ...................... 34
Figure 18: Scene Builder design view with Radio Plannex under design ............................... 36
Figure 19: project creation scene ............................................................................................. 37
Figure 20: select project to open scene .................................................................................... 37
Figure 21: coverage planner view ............................................................................................ 38
Figure 22: Load report view .................................................................................................... 38
Figure 23: sample.controller package showing classes in the package ................................... 39
Figure 24 : Controller class with methods in the IDE ............................................................. 40
Figure 25: Propagation model class ......................................................................................... 41
Figure 26: fxml codes in the IDE ............................................................................................. 41
Figure 27: System Parameter tab ............................................................................................. 42
Figure 28: Transmitter side parameters tab ............................................................................. 43
Figure 29: Receiver side parameters tab .................................................................................. 43
Figure 30: Final budget parameter tab ..................................................................................... 44
Figure 31: project database tables design and relationship structure ....................................... 45
Figure 32: create project .......................................................................................................... 46
Figure 33: results of coverage planner ..................................................................................... 47
Figure 34: site display on Google Maps satellite view ............................................................ 47

vii
Figure 35: Capacity planning ................................................................................................... 48
Figure 36: Market Estimate ..................................................................................................... 48
Figure 37: Print Preview of generated report from project ...................................................... 49

Table 1 [8] : Different terrains propagation model and their formulas .................................... 10
Table 2 [8]: GSM MS transmission power at 900 MHz .......................................................... 13
Table 3[8]: Typical combiner losses in different BTS configurations .................................... 15
Table 4[8] : comparison of different antenna parameter values per terrain type ..................... 16
Table 5[8] : Attenuations of the ½’’, 7/8’’, 1 5/8’’ and jumper cables types of 100 m at
900MHz ................................................................................................................................... 17
Table 6 [8]: Erlang B table with GOS ..................................................................................... 25

viii
List of Abbreviations
2G --------------------------------------------- Second Generation

3G --------------------------------------------- Third Generation

4G --------------------------------------------- Fourth Generation

LTE --------------------------------------------- Long Term Evolution

GSM --------------------------------------------- Global System for Mobile Communication

UMTS --------------------------------------------- Universal Mobile Telecommunication System

UL --------------------------------------------- Uplink

DL --------------------------------------------- Downlink

MAPL --------------------------------------------- Maximum Allowable Path Loss

PL --------------------------------------------- Path Loss

UI --------------------------------------------- User Interface

SDLC --------------------------------------------- system Development Life Cycle

UE --------------------------------------------- User Equipment

BW --------------------------------------------- Bandwidth

DM --------------------------------------------- Duplex Mode

FB --------------------------------------------- Frequency Band

TM --------------------------------------------- Terrain Morphology

MHz --------------------------------------------- Megahertz

KHz --------------------------------------------- Kilohertz

GHz --------------------------------------------- Gigahertz

EIRP --------------------------------------------- Effective Isotropic Radiated Power

ST --------------------------------------------- Site Type

dB --------------------------------------------- decibels

dBm --------------------------------------------- mill decibels

QPSK --------------------------------------------- Quadrature Phase Shift Keying

QAM --------------------------------------------- Quadrature Amplitude Modulation

ix
FDD --------------------------------------------- Frequency Division Duplexing

TDD --------------------------------------------- Time Division Duplexing

FDMA --------------------------------------------- Frequency Division Multiple Access

TDMA --------------------------------------------- Time Division Multiple Access

GUI --------------------------------------------- Graphical User Interface

UML --------------------------------------------- Universal Modeling Language

IDE --------------------------------------------- Integrated Development Environment

PDF --------------------------------------------- Portable Document Format

SQL --------------------------------------------- Structure Query Language

MS --------------------------------------------- Mobile Station

BTS --------------------------------------------- Base Transceiver Station

BS --------------------------------------------- Base Station

x
 ABSTRACT
This project is focuses on the design and implementation of a software tool to do radio
network coverage and capacity planning for 2G(GSM), 3G(UMTS) and 4G(LTE) based
mobile technologies. Thus the importance of coverage and capacity planning cannot be
overemphasized in mobile telecommunication as mobile telecom operators needs to embark
on effective planning of their network with the available resources in order to ensure an
almost perfect way of delivering their services to the public thus ensuring a better quality of
service and profit. To achieve the objectives of this project, a lot of research was done on the
way some similar tools functions and the steps needed to follow to carryout tasks when using
them. We used the waterfall model of system development life cycle. This model provides a
way of solving a particular problem using steps that depicts a “waterfall-like” nature that is
we began by requirements analysis which entails the research of all the parameters and things
that will be needed by the tool to function and till the researching phase was done, and then
precedes the next step. The next step which is better explained in chapter 4 of the text is the
system design and implementation. This phase involve the use of conceptual software design
approaches such as flow chart and use case diagram to design the tool which is then followed
by the implementation by the use of JavaFX scene builder and intelliJ IDE to do the actual
physical design and programming of the tool. This step was followed by the testing of each
module built with sample data obtained from textbooks and internet to obtain the results and
then compares the solutions to the theoretical calculations to be sure that the mathematical
functions were properly implemented during their programming. Deployment and
maintenance was carried out by running the tool and examining it using different parameter
values per generation and if any error were met, corrective measures were taken to solve the
problem in the programming of the software.

xi
 CHAPTER 1: INTRODUCTION
Radio or Wireless communication is one of the emerging technologies that are advancing as
well as getting more challenging. Effectiveness and optimized solution for radio
communication can be achieved with proper planning before deployment. Radio network
planning is designing of network structure and determining network elements subjected to
various design requirements. With increasing radio frequencies shortage, radio planning jobs
are getting tougher as well as deploying process of large radio networks is very expensive.
Hence, for achieving high resource utilization cautious planning is necessary. Moreover,
maintaining high degree of accuracy and better optimization in manual designing and
planning of network is getting hard. This fact triggers the need of a computerized planning
tool for future and current networks. Radio Plannex is one example of such a tool that will be
used to better manage the handling of the process of coverage and capacity planning in
mobile network planning.

In this project, a desktop-based system is developed which makes users able to carry out
coverage and capacity planning of a complex mobile radio network through his personal
computer using a light weight install application without any stress or difficulty.

1.1 Problem Statement

After analyzing the entire processes involved in radio network planning, I was able to
understand and came up with the setting up of the problem statements before I began the
design of the tool. The problem statements include:

 To build a desktop based tool to carryout coverage and capacity planning for GSM,
UMTS and LTE mobile network technologies.
 To load and display the coverage of a particular site project based on calculation
results on a map
 To print a PDF report at the end of every planning project performed on the tool.

1.2 Aim of the project

The aim of this project can be divided into two; primary and secondary objectives.

1
1.2.1 Primary Objective
 To better understand the radio network planning and optimization process as well as
get acquainted in the Java programming language for desktop application
development.

1.2.2 Secondary Objective

 To design and implement a software tool to carryout radio network planning
(coverage and Capacity planning) for GSM(2G), UMTS(3G) and LTE(4G) mobile
technologies.
 Display a coverage map on the application to show the various site locations for a
specified location.
 Print a PDF report for printing at the end of each project..

1.3 Scope of Project

This project is developed based on the ideas below and is targeted for students, lecturers,
engineers and researches for use to facilitate their work during this process of radio network
planning. Some of its scope is:
 Only one project can be carried out at a time.
 Data can be saved and upgraded during a project into a light weight database
(SQLite).
 Projects can be saved and later worked on.
 You can either load an existing saved map or load it directly from the internet to get
the area of interest.
 Users will be able to print a pdf copy of a report consisting of the entire parameters
used in the project and derived parameters from calculations performed by the tool at
the end of each project.

1.4 Project Requirement

The requirements of this project are:

1) IDE (Integrated Development Environment): intelliJ idea IDE by JetBrains

foundation is the ideal choice for the project.
2) Scene Builder application: An open source java GUI builder from Oracle foundation.
3) JasperStudio : Application used to create and design the pdf report template.
4) starUML application for creating the conceptual system interaction and flow charts.
5) Internet connection.

2
 6) Prototype parameter values for testing during development.

1.6 Project Hypothesis

This project will be helpful for educational purpose as well as real implementation for
personal use in our schools, personal use at home or even in the companies dealing in
network planning process. Also, this project is light weight and does not require any license
for use and is open and available free of charge for upgrading to a particular specification of
interest by the users. The project will also reduce the high cost incurred in purchasing a
license for such tools just to do the basics of the network planning process and also will
eliminate the time waste in setting up a traditional tool on spreadsheets.

1.7 Dependent and Independent variables

Independent variable is cost effectiveness, need, reliability and security effectiveness.

3
 CHAPTER 2: LITERATURE REVIEW
Radio network planning is a process that defines the stages i.e. visits in the area,
measurements, planning, documentation required to provide a desired radio network plan for
a certain geographical area. Moreover, the radio network planning process has to be defined
carefully and carried out in different phases in order to manage the strong influences
between:

 Coverage
 Capacity
 Quality (interference probability)

These three areas must all be optimized in order to achieve a cost-efficient and overall high
Quality of Service (containing good speech quality, minimum radio network congestion, and
minimum number of drop calls or handover failures) radio network.

2.1 Radio Planning Process

Planning of radio network is a very challenging task. However, an organization can minimize
problems that may rise during deployment of network, with properly planned radio network.
The process of Radio network planning is shown in Figure 1. The network planning process
follows steps like requirement specification, dimensioning, planning and optimization. With
this steps taken into account, to begin the process on a planning tool such as Radio Plannex,
the operator has to have all the requirements pertaining to coverage, capacity and quality.

Figure 1 [1]: Radio network planning process

4
2.1.1 Coverage Dimensioning
The aim of coverage dimensioning is to determine the number of base stations needed to
cover a specific area. For that, the dimensioning will include:

 To obtain the cell radius

 To estimate the number of base stations for coverage requirement

The diagram below displays the coverage dimensioning flow

Figure 2[ 9]: Coverage planning procedure

2.1.2 Radio Wave Propagation

Propagation models have been developed to be able to estimate the radio wave propagation as
accurately as possible. Models have been created for different environments to predict the
path loss between the transmitter and receiver[9]. How much power needs to be transmitted
using the BTS to be able to receive a certain power level at the MS? The complexity of the
model affects the applicability as well as the accuracy. Two well-known models are those of
Okumura–Hata and Walfish–Ikegqami. The first mentioned is created for large cells, i.e. for
rural and suburban areas, while the Walfish–Ikegami model is used for small cells, i.e. for
urban areas[9]. The basic electromagnetic wave propagation mechanisms are free space loss,
reflection, diffraction and scattering. Free space loss describes the ideal situation, where the
transmitter and receiver have line-of-sight and no obstacles are around to create reflection,
diffraction or scattering. In this ideal case the attenuation of the radio wave signal is

5
equivalent to the square of the distance from the transmitter. When the signal has been
transmitted in the free space towards the receiver antenna, the power density S at the distance
d from the transmitter can be written as:

Where Pt is the transmitted power and Gt is the gain of the transmission antenna. The
effective area A of the receiver antenna, which affects the received power, can be expressed
as

Where λ is the wavelength and Gr is the gain of the receiver (RX) antenna. The received
power density can also be written as

Combining these equations, previous the format for the received power is

The free space path loss is the ratio of transmitted and received power. Here is the equation in
simplified format, when the antenna gains are excluded:

and the free space loss converted in decibels

6
Where f is the frequency in megahertz and d is the distance in kilometers.

In reality the radio wave propagation path is normally a non-line-of-sight situation with
surrounding obstacles like buildings and trees. Therefore, the applicability of the free space
propagation loss is limited. The received signal actually consists of several components,
which have been travelling through different paths facing reflection, diffraction and
scattering. This effect is called multipath and one component represents one propagation
path. The different components, signal vectors, are summarized as one signal considering the
vector phases and amplitudes.

The attenuation of the radio wave signal power depends on the frequency band and terrain
types between the transmitting and receiving antenna. When estimating the total path loss of
the radio signal, the travelled path can be split into sections according to terrain types. As the
propagation varies according to the area type, this has to be taken into account in the
propagation model. The difference can be explained using the measured correction factor for
each terrain type.

One more phenomenon of the mobile environment is the different fading types. Slow fading
happens when the radio wave signal is diffracted due to buildings or other big obstacles in the
signal path. The receiver, the mobile phone, is in a way in the shadow of these obstacles.
Slow fading is log-normal fading and therefore modeled with a Gaussian distribution.

The previously mentioned multipath propagation causes short term fades, which can be
relatively deep, in the received signal due to the summarized signal vectors, which are having
different phases and amplitudes. This fading is known as fast fading or Rayleigh fading. As
the second name implies, fast fading can be modeled using the Rayleigh distribution.

The third fading type is a combination of the previous two and is called Rician fading. When
speaking about fast fading only the scattered components are taken into account, but in this
case a line-of-sight component also exists. Supposedly this fading can be modeled using the
Rician distribution.

2.1.3 Propagation Models

2.1.3.1 Macro level models

The propagation models which are commonly used for macro cells are Okumura–Hata, and
COST231-Hata. These models are developed by combining propagation theory and extensive

7
measurement campaigns. The models take several parameters like effective antenna height,
terrain type (morphology), and terrain height (topography), frequency, EIRP, etc. These two
models are macro cell models which have limitations in terms of frequency, calculation
ranges, and base station antenna height.

1. Okumura-Hata Model

The Okumura model was intended for manual use. Hata, in 1980, derived semi-empirical
formulas from Okumura’s curves for computational use. The Okumura–Hata model applies
well for large cells. In the configuration of large cells, the antenna of the base station is
usually higher than the surrounding buildings or obstacles.

The main propagation loss for the Okumura–Hata model is the diffraction and scattering over
rooftops near the mobile station. This model can be applied to the following scenario:

a) Frequency range 400–1500 MHz

b) Terrain morphologies (DU, U, SU, and RU)
c) Mobile antenna height from 1 to 10 m
d) BTS antenna height from 30 to 200 m
e) Cell radius 1–20 km (macro sites)

The standard formula for empirical path loss in urban areas under the Okumura-Hata model is

The parameters in this model are same as in the Okumura model, and a(hr) is a correction
factor for the mobile antenna height based on the size of coverage area. For small to medium
sized cities this factor is given by

and for larger cities at a frequency fc>300MHz by

else it is

corrections for the urban model are made for the suburban and is by

8
For the rural, it is given by

2. COST231-Hata Model

The European Co-operative for Scientific and Technical Research (EURO-COST) formed the
COST 231 working committee to develop and extended version of the Hata mode. COST-231
proposed the following formula to extend Hata’s model to 2 GHZ (known as the PCS
extension of the Hata model, or COST-231 model). The proposed model for path loss is

The terms a(hUE) and CM are used to account for different terrains.

In both models, the term [44.9 − 6.55 log(hBS)] is the slope in dB/decade. The slope is a
factor indicating how severe the loss becomes as a function of distance from the base station.
Therefore, the path loss can be defined in a general form as follows:

where PL0 is the intercept, s is the slope, MAPL is the maximum allowable pathloss and R is
the coverage radius. The table below illustrates the expressions of the slope and intercept for
the different terrains for both the Okumura-Hata and COST231-Hata models.

9
Table 1 [8] : Different terrains propagation model and their formulas

2.1.4 Link Budget

The aim of the link budget (LB) is to identify the maximum allowable path loss (MAPL)
between the transmitter and receiver for the UL and DL. Therefore, the cell radius can be
calculated for different terrain. The link budget is calculated under the certain conditions.

10
Figure 3 [9] :(a)Image showing Uplink budget calculation flow with parameters (b)Downlink
budget calculation with some parameters

2.1.4.1 Link Budget Parameters

1. Equipment/System Parameter
Frequency, Spread spectrum bandwidth, Transmit power, receiver sensitivity, noise
factor, demodulation threshold, antenna gain, background noise, feeder loss and so on.
2. Service Parameter
Service type, information rate and so on
3. Environment Parameter
Shadow fading, fading margin, clutter(penetration) loss, body loss and so on.
4. Technical Parameter
Handoff gain, interference margin, power control margin and so on

2.1.5 Calculation of Coverage Radius and Coverage Area

Calculation area is very important for coverage calculation but also for frequency planning,
interference analysis, etc. When defining calculation regions for cells one must make
compromises between calculation time and accuracy. If calculation regions are too large the
calculation of coverage takes a long time. On the other hand, too small a calculation region
cuts the coverage and influence of the results of, for example, frequency planning.
Calculation regions should be selected in such a way that C/I or C/N ratios will not be

11
affected by too small a calculation region. But the calculation regions do not have to be any
larger than necessary to fulfill the criteria. From the value of the maximum allowable path
loss (MAPL) obtained from the link budget calculation, together with the propagation model
equation, the coverage radius of a site is calculated using the formula

There are two types of sites, which include:

1. The 3-sectors- site with coverage area given by: √

2. The omni-site with coverage area given by: √

Figure 4[9 ]: Type of sites

2.1.6 Number of Cells
The number of cells is given by the ratio of the total coverage area to the cell coverage area.

2.1.7 Important Components of Link Budget Calculations

These components are taken with respect to the GSM 900 system specifications.

2.1.7.1 Base station and mobile station transmission power

GSM specification 05.05 says that the BTS transmission RF peak power can, for example, be
20–40 W (TRX power class 5) at the 900 MHz frequency band. The GSM manufacturers
typically have a few macro BTS types with maximum power (typically in the power class 5)
and also some special BTS types for transmitting lower peak powers. As different suppliers

12
have different BTS types with transmission power from 1.0 to 50 W, the nominal peak power
of each BTS type has to be carefully checked. Note that transmission peak powers can vary
between the frequency bands 900/1800/1900MHz.

There are five different mobile classes for the GSM900 system (see Table 2.1). Classes 1–3
are vehicle mounted and are something of a rarity, whereas handhelds, the mobile classes 4
and 5, are the mainstay of the GSM system, specifically the handheld with 2 W transmission
peak power. Handhelds of 0.8W have been discussed but they are not widely supported at
present.

Table 2 [8]: GSM MS transmission power at 900 MHz

MS Class TX power(W)

1 _

2 8.0

3 5.0

4 2.0

5 0.8

2.1.7.2 Base station and mobile station sensitivities

GSM specification 05.05 defines the base-line minimum reception levels (without diversity
reception), as – 104 dBm and – 102 dBm (900 MHz) for the BTS and MS, respectively.
However, manufacturers have started to improve base station sensitivity levels and to indicate
values lower than – 104 dBm, even as low as – 108 dBm. The environment for these values is
not revealed, nor is whether diversity reception was applied. When sensitivity levels are
discussed, the environment and the number of reception branches should be indicated so as to
confirm the base-line.

Diversity reception is also sometimes connected to BTS sensitivity and leads to discussion
about receiving system sensitivity. Depending on the diversity technique and environment the
typical two branch diversity reception gain is 3–6 dB. Therefore, BTS sensitivity is also 3–6
dB better if the diversity reception is included in the sensitivity values. Sensitivity
measurements are typically simulated in an optimum condition using zero correlation for the
different reception branches. In reality the signal correlations of the different receiving
branches are not even close to the zero and the signal levels are not equal.

13
Mobile station sensitivity covers the same parameters as the base station but diversity
reception is not typically used at the mobile station receiving end. Mobile station suppliers
have also improved sensitivity: the value of – 104dBm, or better, has been frequently
recorded. However, nominal values of different mobile station types have to be measured in
different environments. Typically values from – 102 dBm to – 105 dBm have been safely
used in radio planning.

2.1.7.3 Combiner and receiving multicoupler losses

Combiners in the downlink direction and receiving multicouplers in the uplink direction are
needed in the base stations if more than one tranceivers are assigned to the same antenna line.
The combiners merge the frequencies to the same antenna line in the downlink direction and
simultaneously cause attenuation. The receiving multicouplers separate the frequencies in the
uplink direction but their attenuation is negligible. Combiner attenuation is related to the
combiners’ performance. Combiners can be narrowband and thus tuned to a certain frequency
band so the attenuation can be minimised. Wideband combiners (of higher attenuation) are
typically needed if frequency hopping is used and frequencies are far away from each other.
Table 2.2 gives an idea of the different combiner types and attenuations. Wideband
combiners are, of course, meant for capacity areas where a maximum number of transceivers
are required over each coverage area. In these capacity areas many base stations are needed,
coverage is limited and thus minor higher combiner loss does not cause any serious difficulty
(however indoor coverage is reduced). Correspondingly, frequency band selective combiners
are used in the areas where maximum coverage is required and thus combiner loss is also
minimised. Combiner loss can be minimised when it is by-passed but then only one
frequency can be assigned to the antenna line (a new antenna line is required if capacity is
needed in the future for a second frequency).

14
Table 3[8]: Typical combiner losses in different BTS configurations

Combiner type Loss(dB)

By-passed 2-3
Narrowband 3-5
wideband 5-7

2.1.7.4 Base station antennas

“Antenna” typically describes an entire radiating element, connected via a line to the base
station equipment. Specifically, “antenna” can be a short piece of metal wire (a wire antenna,
as in a dipole antenna) or a metal plate (patch antenna). These examples are based only on
one element and therefore, “antenna” is often combined with some other word, as in “antenna
element.” When two or more of these elements are connected, they form an “antenna array.”
Antenna arrays achieve direction (also called gain) for the radiation.

Base station antennas, depending on their application, comprise either one antenna element
(small size, low gain and multi band antennas without diversity) for indoor applications, or an
antenna array (high gain and directional) for macro cell applications.

The essential base station antenna parameters are:

 Gain (low/medium/high)
 Beamwidth (horizontal and vertical)
 Size
 Polarisation
 Diversity technique
 Frequency band
 Tilting properties.

15
 Table 4[8] : comparison of different antenna parameter values per terrain type

Urban Macro Rural Macro Micro Indoor

Gain (dB) 12-18 16-18 7 7

Beamwidth 65-80 65-80 65-90 65-360
Horizontal

Beamwidth 7-10 7-10 <45 Not critical

Vertical

Diversity Polarization Polarization Polarization No

polarization Vertical Vertical Vertical Vertical/horizontal

Tilting Yes Yes/no no No

Frequency Single/dual Single/dual multi multi
Band
Size Large/Medium Large/Medium Small Small

*Tunnel Applications need different polarizations to maximize the radio propagation

2.1.7.5 Mobile station antennas

Mobile station antennas are typically omnidirectional or 180° (not radiating towards a head)
in the horizontal plane and very wide in the vertical plane. Antenna gain is assumed to be 0
dBi because mobile antennas are very small and because the power budget has to be
calculated by taking into account all antennas in the field. If some external antennas are used,
as in vehicle installations, antenna gain could be included if needed.

2.1.7.6 Base station cables and connectors

The base station antenna line also includes cables and connectors between the antenna and
base station. Cables can be thin (jumpers) with a high attenuation loss, or thick (1 5/8") with
quite a low attenuation. The attenuation of typical cables 1/2" or 7/8" at 100m (at 900 MHz
and 1800 MHz) are presented in Table 5 below.

16
 Table 5[8] : Attenuations of the ½’’, 7/8’’, 1 5/8’’ and jumper cables types of 100 m at
900MHz

Type 900 MHz (dB) 1800 MHz (dB)

1 /2’’ 7.7 12.0

7/8’’ 4.0 7.0

1 5/8’’ 3.0 5.0

Jumper 0.3 0.5

The number of cables can be reduced by connecting the transmitting and receiving branches
by using a duplexer and in multi band cases the frequency bands can be connected by using
diplexers. Both duplexers and diplexers cause less than 1.0 dB loss, including connector loss
in both directions.

2.1.7.7 Mobile station cables and connectors

Mobile station cable and connector losses are typically assumed to be 0 dB. If some external
antennas and cables are used, as in vehicle installations, some cable loss could be included in
the power budget if needed.

2.2 Capacity Planning

Capacity planning is typically done for the first time during the dimensioning phase and a
second time in parallel with the coverage planning. The aim of capacity planning is to define
the maximum and required number of transceivers at each base station or more over the
maximum and required capacity of the base station or base station site at each physical
location over a certain area. The exact capacity need can be defined based on the monitoring
of the radio network which gives the real information about traffic in the radio network.
Thus, the result of capacity planning is actually a specification for the frequency planning:
this specification defines the required input information—the number of transceivers and the
required base station site configurations to achieve capacity—for frequency planning at an
element level.

Capacity planning starts by specifying the target traffic (for example from monitoring results)
and the minimum average base station antenna height to cover the area. The other essential
parameter is the number of available frequencies (operator’s frequency band) which defines

17
the maximum number of transceivers at each base station. The figure below shows the
capacity planning flow;

Figure 5 [3] High Level Summary of Critical Capacity Affecting Factors

After examining the flow of the capacity and coverage planning process together with their
various parameters, I was able to follow it and transforms it into an algorithm which was later
implemented with a programming language to eliminate the complexity and longtime
duration involved in these processes so that users can use and carry out these calculations
involved with ease and reduction in the time that would be needed for the case of theoretical
and paper based analysis.

2.2.1 Capacity planning over a certain area

Let’s consider an example of an area where there is a very high traffic density area in an
urban area of surface area 5 km2 and four base station sites (BTS1 and BTS2 having three
sectors and BTS3 and BTS4 having two sectors) of antenna height 25 m are needed to
achieve good enough coverage for this area, see Figure 3.1.

18
 Figure 6 [8 ]: pictorial view of Base station sites display
The antennas are implemented at rooftop level and thus the propagation environment is of a
macro cellular type. The traffic need for this area is as high as 100 Erl per busy hour. The
frequency band is 6.0 MHz and this means 30 frequency channels in the GSM when the
channel bandwidth is 200 kHz. The maximum number of transceivers at each base station
depends on the frequency reuse factor that moreover depends on the propagation environment
and the software features. The value 15 (frequency reuse factor) can be used in this example
because it is a typical value for the radio network where antennas are implemented at rooftop
level or above and when there are no special software features implemented. When the
number of frequency channels and the frequency reuse factor are known, the maximum
number of transceivers at each base station can be calculated:

Maximum number of transceivers=frequency channels/frequency reuse factor=30/15=2.

These two transceivers represent a certain maximum traffic that has to be calculated in order
to be able to define the maximum traffic that can be provided by the ten base stations (each
having two transceivers). The calculation of the offered traffic by the two transceivers can be
done by using Erlang-B or Erlang-C formulas and tables.

19
The capacity requirement per user is different depending on the user profile. The
dimensioning can be simplified by having one user profile per area type; i.e. all the users
inside the same area type have a similar user profile. The user profiles define the average
usage as well as the busy hours. The capacity has to be planned based on the maximum
simultaneous usage.

In the capacity planning phase, a detailed capacity per cell level is estimated. The prior task
was to select the base station locations and calculate the coverage area using actual BTS
parameters. The capacity allocation is based on these coverage maps and traffic estimates,
which can be a separate layer on the map of the planning tool. The coverage dominance map
provides the information for the cell borders.

As mentioned, the maximum simultaneous usage is the main planning target for the network
capacity. The capacity peaks are momentary and therefore define a blocking probability,
which is the accepted level for unsuccessful call attempts due to lack of resources. This
parameter has already been defined by the customer at the beginning of the planning process.

2.3 Traffic Models

2.3.1 Key definitions for trunked radio systems

1) Erlang is the unit of telecommunications traffic measurement. Erlang represents the
continuous use of one voice path. It is used to describe the total traffic volume of one hour.A
channel kept busy for one hour is defined as having a load of one Erlang.

2. Setup Time: Time required to allocate a radio channel to a requesting user.

3. Blocked Call: A Call which cannot be completed at the time of request due to congestion
(lost call).

4. Holding Time: Average duration of a typical call. Denoted by H (in seconds).

5. Request Rate: The average number of call requests per unit time (λ)

6. Traffic Intensity: Measure of channel time utilization or the average channel occupancy
measured in Erlangs. This is dimensionless quantity denoted by A.

7. Load: Traffic intensity across the entire trunked radio system (Erlangs).

For 1 channel

20
  Min load = 0 Erlang (0% time utilization)
 Max load =1 Erlang (100% time utilization)

For example, if a group of 100 users made 30 calls in one hour, and each call had an average
callduration (holding time) of 5 minutes, then the number of Erlangs this represents is worked
out as follows:

Minutes of traffic in the hour = number of calls x duration

Minutes of traffic in the hour = 30 x 5 = 150

Hours of traffic in the hour = 150 / 60 = 2.5

Traffic Intensity= 2.5 Erlangs

Erlang traffic measurements are made in order to help telecommunications network designers
understand traffic patterns within their voice networks. This is essential if they are to
successfully design their network topology and establish the necessary trunk group sizes.

2.3.2 Traffic concepts

In tele-traffic we use the word traffic to denote the traffic intensity.

 Carried Traffic: Traffic carried by a group of servers (channels) during the time
interval T.
 A channel can carry at most 1 Erlang.
 The maximum possible carried traffic is the total number of channels C (in Erlangs).
 The income is often proportional to the carried traffic.
 Offered Traffic: The traffic that would be carried if no calls were rejected due to lack
of capacity. It is thus the traffic offered to the trunked system
 When offered traffic exceeds the maximum capacity of system, the carried traffic
becomes limited due to limited number of channels
 Lost or Rejected Traffic: The difference between offered and carried traffic.
 The rejected traffic can be reduced if the capacity of system is increased.
 Traffic Intensity offered by each user(Au): Equals average call arrival rate multiplied
by the holding time
Au = λH (Erlangs)
 Total Offered Traffic Intensity for a system of U users (A):

21
 A = UAu (Erlangs)
 Traffic Intensity per channel, in a C channel trunked system
Ac = UAu/C (Erlangs)

2.3.3 Trunking and Grade of Service

In a trunked radio system, when a particular user requests service and all the available radio
channels are already in use, the user is blocked or denied access to the system. In some
systems a queue may be used to hold the requesting users until a channel becomes available.

Trunking systems must be designed carefully in order to ensure that there is a low likelihood
that a user will be blocked or denied access. The likelihood that a call is blocked, or the
likelihood that a call experiences a delay greater than a certain queuing time is called “Grade
of Service” (GOS).

The grade of service refers to the proportion of unsuccessful calls relative to the total number
of calls. GOS is defined as the ratio of lost traffic to offered traffic.

Grade of Service (GOS), is a measure of ability of a user to access a trunked system during
the busiest hour. Measure of the congestion which is specified as a probability.

 The probability of a call being blocked

 Blocked calls cleared or Lost Call Cleared(LCC) or Erlang B systems
 The probability of a call being delayed beyond a certain amount of time before being
granted access
 Blocked call delayed or Lost Call Delayed(LCD) or Erlang C systems

2.3.4 Blocked calls cleared systems (Erlang B)

Queuing is not provided for call requests. When a user requests service, there is a minimal
call setup time and the user is given immediate access to a channel if one is available. If
channels are already in use and no new channels are available, the call is blocked without
access to the system.

The user does not receive service, but is free to try again later. All blocked calls are instantly
returned to the user pool. Mathematical modeling of such systems is done by Erlang B
formula.

The Erlang B model is based on following assumptions:

22
  Calls are assumed to arrive with a Poisson distribution.
 There are nearly an infinite number of users.
 Call requests are memory less, implying that all users, including blocked users, may
request a channel at any time.
 All free channels are fully available for servicing calls until all channels are occupied.
 The probability of a user occupying a channel (called holding time) is exponentially
distributed. Longer calls are less likely to happen.
 There are a finite number of channels available in the trunking pool.
 Inter-arrival times between call requests are exponential.
 Inter-arrival times of call requests are independent of each other.
 The model is accurate for a large system with many channel and many users with
similar calling patterns.

The previous assumptions to the Erlang B formula which determines the probability that a
call is blocked and is a measure of the GOS for a trunked system which provides no queuing
for blocked calls. The Erlang B formula is given by[8]

Where C is the number of trunked channels offered by a trunked radio system and A is the
total offered traffic.

23
 Figure 7[8 ] : Erlang B graph showing channel number against traffic
Given that the Erlang B formula is not readily used, calculations were made for different
values of the 3 main parameters. This resulted into the Erlang B table. These tables permit us
to define one factor amongst the following 3 factors: the number of channels, the traffic (in
erlang) and the bocking rate.

However, the erlang tables are not always available, thus planning may take place by the
approximation given in the equation below; where C is the number of channels, A is the
traffic (in Erlangs) and 10-k (written as k) is the desired quality of service (GOS or QoS).

24
Table 6 [8]: Erlang B table with GOS

Number of Capacity for GOS

Channels C =0.01 =0.005 =0.002 ==0.001

2 0.153 0.105 0.065 0.046

4 0.869 0.701 0.535 0.439
5 1.36 1.13 0.900 0.762
10 4.46 3.96 3.43 3.09
20 12.0 11.1 10.1 9.41
24 15.3 14.2 13.0 12.2
40 29.0 27.3 25.7 24.5
70 56.1 53.7 51.0 49.2
100 84.1 80.9 77.4 75.2

25
 CHAPTER 3: METHODOLOGY
This project was built based on the waterfall model of software development which is very
simple to understand and use. In a Waterfall model, each phase must be completed before the
next phase can begin and there is no overlapping in the phases. Waterfall model is the earliest
SDLC approach that was used for software development.

In “The Waterfall” approach, the whole process of software development is divided into
separate phases. The outcome of one phase acts as the input for the next phase
sequentially. This means that any phase in the development process begins only if the
previous phase is complete. The waterfall model is a sequential design process in which
progress is seen as flowing steadily downwards (like a waterfall) through the phases of
Conception, Initiation, Analysis, Design, Construction, Testing,
Production/Implementation and Maintenance. As the Waterfall Model illustrates the
software development process in a linear sequential flow; hence it is also referred to as a
Linear-Sequential Life Cycle Model.

Figure 8: Water fall model of system developement life cycle

26
3.1 Sequential Phases in the Waterfall Model

 Requirements: The first phase involves understanding what needs to design and what
is its function, purpose, etc. Here, the specifications of the input and output or the
final product are studied and marked.
 System Design: The requirement specifications from the first phase are studied in this
phase and system design is prepared. System Design helps in specifying hardware and
system requirements and also helps in defining overall system architecture. The
software code to be written in the next stage is created now.
 Implementation: With inputs from system design, the system is first developed in
small programs called units, which are integrated into the next phase. Each unit is
developed and tested for its functionality which is referred to as Unit Testing.
 Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. The software designed, needs to go
through constant software testing to find out if there are any flaw or errors. Testing is
done so that the client does not face any problem during the installation of the
software.
 Deployment of System: Once the functional and non-functional testing is done, the
product is deployed in the customer environment or released into the market.
 Maintenance: This step occurs after installation, and involves making modifications
to the system or an individual component to alter attributes or improve performance.
These modifications arise either due to change requests initiated by the customer, or
defects uncovered during live use of the system. The client is provided with regular
maintenance and support for the developed software.

All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the
defined set of goals are achieved for the previous phase and it is signed off, so the name
“Waterfall Model”.

3.2 Requirement Analysis

In software engineering, application developers need to clearly understand the problems to be
solved. It is therefore important for a developer to properly model the scenarios that can
influence the solution to the problem by collecting relevant information. This process is

27
called requirement analysis. The requirement analysis provides the opportunity for a
developer to get a better understanding of the problem in question. For effective design and
development of this project, the following requirements must be met. They can be divided
into functional requirements and non-functional requirements.

3.1 Functional Requirements

This section describes different requirements that are accomplished by the tool (Radio
Plannex). In order to achieve the desired goal of this project, the functional requirements
must be met. The following are the three major actions performed by Radio Plannex.

3.1.1 Input Requirements

Input requirements are the requirements a user must fulfill before being able to obtain the
final output of the application. A user can use the application by providing some inputs that
are needed in each section of the application which are later then used in calculation of
various parameters. After providing all the inputs needed for each section then calculated
output parameters is archived, he will then proceed to a new section where he/she carry out
the same process until the last section to obtain the results of desired output parameters.

3.1.2 Operational Requirements

The operations that the application performs are accepting inputs from users, perform some
calculations, import Google Maps, display the coverage of each site with available eNodeBs
then Print a report as a result of the parameter inputs and output calculated results saved in
the SQLite database. This application also validate user inputs to check if it is a number or
not and provides a graphical view of displaying the results of the calculated parameters
through the use of gauges as software UI.

3.1.3 Output Requirements

Output requirements ensure that the user is able to calculate and display the result of MAPL,
cell radius and the number of eNodeBs needed on the UI. It can also be able to print a pdf
report and also try to display the coverage indicating the various site antennas on the
Coverage map of interest.

28
3.2 Non-Functional Requirements
Non-functional requirements are requirements that do not affect the proper running of the
Radio Plannex tool. However, it is worthwhile to mention and consider these requirements
for the purpose of software quality and analysis.

3.2.1 Software Requirements

The Radio Plannex tool, like other software engineering projects, needs well defined
specifications that must meet the software environments needed to achieve the desired goal of
the project.

The software requirements considered in the development of this project are highlighted
below:

 This application runs on all machines running a JVM and a JRE on their operating
system.
 For windows users, you must have at least windows7 and %512 RAM and 3GB Hard
Disk space.
 You must have intelliJ IDE, Scene Builder installed, install all the necessary libraries
and system dependencies in case you want to improve and continue on the
development .
 You must have Sqlite browser application to be able to view the data manipulated
during development (in case you want to continue the development).

3.2.2 Secondary Requirements

Secondary requirements are future considerations that can be incorporated into the
application for further development:

 Ability to properly manipulate the Google Maps functionalities well.

 Ability to support other network types such as GSM, UMTS, Microwave, Optical and
5G networks.
 Ability to perform Monte Carlo simulations that is simulation of coverage by signal
level, and coverage by congestion of the network.
 Ability to do capacity planning and perform frequency planning.
 Ability to do Transmission network planning and Core network planning.

29
3.3 Feasibility Analysis
3.3.1 Economic Feasibility
This tool is not to be sold for it has to be served in the open source community so that
developers from around the corners of the globe may benefit from some of it functionalities
and will be provided free of charge to any person in need of it to solve some the problems
that it was made for. Though it will not be provided for free forever, after some years of
upgrade, it will be removed from the open source community where it development will
continue to enhance and improve it functionality to a level that it can be used to solve not
only the primary requirements but also it secondary requirements successfully thereby given
it an upper hand to be seen in the competing market with the other tools in existence.

3.3.2 Technical Feasibility

Development of this application requires tools like:

 IntelliJ IDEA 2018.1.2, a product from the Jetbrains foundation.

 JavaFX scene builder 2.0. An open source GUI builder from ORACLE opens source
foundation.
 JasperSoft studio for the report design.
 SQLite Expert Professional software to easily view the data manipulated by the Radio
Plannex tool.
 StarUML to design and produce the flow and use case diagrams.

All the licenses of these tools were purchased online from the official site of the
developers before use.

3.3.3 Operational Feasibility

The system provides better solution to the libraries by adding the typical requirement and
necessities. The solution provided by this system will be acceptable to ultimate solution for
the telecommunication industry.

30
 CHAPTER 4: SYSTEM DESIGN AND IMPLEMENTATION
This chapter describes the system design and implementation with the JavaFX framework
and also shows the flow of the design process using software defined procedures.

4.1 Architectural Review

This desktop based application is based on a 3-tier architecture of JavaFX framework. The 3-
tier includes the three hierarchy of the flow of programming logic from user interface to
database and again database to user interface with the desired information requested by the
clients. In between there involves the logic layer for effectively and correctly manipulating
the request. The 3-tier includes the following:

4.1.1 Client tier

The visual part is implemented using all kinds of JavaFX scene builder components, which
does not make database calls and perform calculations. The main function of this tier is to
display information to the user upon user’s request generated by user’s inputs such as firing
button events. For example, system parameter view will display when user begin coverage
planning as per the project selected and has buttons to save and update data into the database.
So this tier just gives a view of how the application will looks like at every instance the user
changes from one level to the next of the planning process.

4.1.2 Logic / Controller tier

The middle tier, logic/controller, is called by the client to make calculations based on the
parameters inputted and also to make secure database queries to retrieve data stored in the
database for use in calculations. It provides core function of the system as well as
connectivity to the data tier, which simplify tasks that were done by the clients tier.

4.1.3 Data tier

Data layer is also the class which gets the data from the logic tier and sends it to the database
or gets the data from the database and sends it to logic tier. This is the actual DBMS access
layer or object layer also called the business object. The database backend stores information
which can be retrieved by using the MySQL database Connectivity. MySQL database
connectivity is used to manage the communication between the middle tier and the backend
database by issuing complex database queries.

In general, this tool is based on the MVC (Model View Controller) paradigm of programming
approach.

31
4.1.4 Model View Controller paradigm
The Model-View-Controller paradigm is a predecessor of the MVVM paradigm. The main
difference is the MVC doesn't necessarily require a two-way-binding between the view and
the controller. Instead, the view sends user commands and user inputs to the controller, which
may update the model with the user input. After processing the business logic, the controller
choses the next dialog to present. The view layer reads the data to display directly from the
model.

Figure 9 [5]: Image showing MVC architecture and interaction

4.2 System Design

4.2.1 Use Case Diagram
Its purpose is to present a graphical overview of the functionality provided by a system in
terms of actors and their goals. The main purpose of a use case diagram is to show what
system functions are performed for which actors. The figure below is the use case diagram
for the 4G coverage planning module for our application.

32
 Figure 10: Radio Plannex Use case diagram from starUML tool

 Use Cases
A use case describes a sequence of actions that provide something of measurable
value to an actor and is drawn as a horizontal ellipse.
 Actor (User)
An actor is a person, organization or external system that plays a role in one or more
interactions with the system.
 System Boundary boxes
A rectangle is drawn around the use case called the system boundary box to indicate
scope of the system.

4.2.2 Process Flow Diagram

Process Flow Diagram or Flowchart is a diagram which uses geometric symbols and arrows
to define the relationships. It is a diagrammatic representation of the algorithm. The Process
flow Diagram for the 4G coverage planning module of the application is shown below:

33
Figure 11: 4G LTE coverage planning flowchart diagram from starUML tool

34
4.3 Radio Plannex Design and Implementation
Before discussing on the design and implementation of this tool, let me explain the structure
of a typical JavaFX FXML project created with intelliJ IDEA. A freshly created JavaFX
project on intelliJ has a project structure that begins with the project directory (folder). This
folder harbor all the files needed for the project to run and operate during development. This
folder initially contains 3 sub folders which are src, External libraries and scratches and
consoles. The src folder also referred to as the source folder harbors packages which define
the scope of classes, the external libraries folder contains external libraries imported into the
project by the developer for extending the functionality of the project and the consoles and
scratches and consoles folder saves all the error messages into log files which is been used by
the IDE for initialization purposes. The src folder contains a single package folder that is
having the same name as the project and also but in all lower cases. This package folder then
contains 3 files which are actually the classes for us to work on. This file is the Main class
file where the application begins running class file, Controller class file which handles the
actions performed on the GUI as well as the logic.

A Graphical User Interface (GUI) is a user-friendly interface, which allows a user to use
icons or other visual elements to interact with the application. In this section, the different
GUI elements and their implementations are analyzed in detail.

4.3.1 Design View of the tool

This tool was designed with the help of the JavaFX scene builder application which provided
us with the drag and drop capability of picking components to specified locations on the
scene where we want them to be. This builder has a generator that generates all the FXML
codes generated from the use of any component on your design. This design is linked to the
controller class “Link_Budget.java” which contains all our methods which can handle the
actions performed on the tool during running. This design is also associated to the FXML
class on the IDE which actually holds the generated codes from the designs. Below is a view
of the design

35
 Figure 12: Scene Builder design view with Radio Plannex under design

4.3.2 Design of Radio Plannex tool

This tool consists of several views with each performing different functions. These views in
order of access when a user creates a new project include;

a) Home Screen View: This is the first view that is seen when the application is run for the
first time. Also called the home screen of the application. It is made of menus and buttons
through which a user can select or click to call and access other views that are part of the
application tool. For example a user may want to create a project after launching the
application, so the user will click on the create project menu button on the menubar to call
the create project view that is controlled by the CreateProjectController class. This view
also have tabs that extend the functionality of the view such as the locate site tab to load
and locate a network site on Google maps, capacity tab to perform capacity planning and
the print report tab to generate and print reports per project. Below is a view of the Home
screen with the create project view

36
 Figure 13: project creation scene
b) Open Project View: This view is used to open an already saved project by selecting the
project then click the open button to load the project up. This view can be seen below

Figure 14: select project to open scene

c) Coverage Planner View: This view is the first view loaded after creating a fresh project
to begin with its calculations. This view consists of several tabs with each having
different parameters and calculations done based on a network generation chosen. Below
is an example of a figure of the coverage planner view.

37
 Figure 15: coverage planner view
d) Load report view: This view is responsible for generating and filling up a pdf report
format with the data of the project in a printable and more presentable format.

Figure 16: Load report view

38
The layout is a Relative Layout that consists of an AnchorPane component to act as a parent
node to hold all the other GUI components, an image view to display the logos, Labels to
hold the various descriptions of the parameter fields, buttons, a JTabbed Pane that is
toggleable to switch between the different sections involve in the application and some
gauges to display results of some calculations.

4.3.2 Implementation of the Radio Plannex tool

In this section, all the steps taken to implement the calculation logic of the Radio Plannex
Tool is explained.

The implementation of this tool using the JavaFX framework is carried out in several
controller classes with each performing particular functions to a particular user interface. The
following controller classes are found in the tool. All these files are arrange into packages.
For example the package that holds all the controller is sample.controller and that for the
model classes is sample.model, that for the views is sample.views and for the database file is
sample.entity.

Figure 17: sample.controller package showing classes in the package

a) Main Class: This is the class where the application begins its execution after being
launched or executed. It initializes the home view UI size and sets the entire scene
before usage.

39
b) Controller class: This class consist of several methods such as initialization,
marketEstimateView, capacityPlanning, calculateCapacity, saveCapacity, loadMap,
and generateReport methods. Each of these methods are tied to a particular actions of
method call performed by the user.

Figure 18 : Controller class with methods in the IDE

c) CreateProjectController: This controller controls the create project view during the
creation of a new project. It handles the create button action and cancel project
creation actions issued by the user.
d) GsmCoverageController: This controller is used to control the GSM coverage planner
view when the user is performing coverage planning for a 2G network.
e) UmtsCoverageController: This controller controls the UMTS view.
f) LoadCoveragePlanningController: This controller is responsible to control and
handles actions performed and methods calls during a 4G LTE coverage planning.
 sample.model package : This package holds classes that manipulates the database
that is access and modifies content in the database. It also holds classes that perform
all the complex calculations that are performed during coverage planning. Below is a
view of how the PropagationModelClass looks like.

40
 Figure 19: Propagation model class

 sample.view package: This package holds all the FXML files which are the GUI
codes generated from the use of each component in the GUI builder. It contain all the
view files from all the various scenes that we see as display on the screen. Below is a
typical example of how an fxml view file looks like.

Figure 20: fxml codes in the IDE

41
Let’s now discuss on some of the various views pertaining to a typical coverage planning
module.

4.3.3 System Parameters Tab:

This is the first view of the tool when it has been launched. It contains parameters which
considered to be setting up the system before moving to the next section where the actually
inputs are required. It contains parameter variables like system bandwidth, data channel type,
frequency band, terrain morphology and so on. This view can be seen below.

Figure 21: System Parameter tab

4.3.4 Transmitter side parameter tab:

This tab contains parameter inputs that are peculiar to the transmitter side of the link budget.
It contains parameters like maximum transmit power, allocated resource blocks, subcarrier
power, transmit antenna gain, transmit cable loss and so on. Each of this parameters is
accompanied by an input field to accept the input from the user which are going to be used
for the calculation of other parameters used in the budgeting process. This tab also contains a
button to save this data input and calculations to the database which will be used in the
feature for other parameter calculation and also an update button which provides the ability of
a data in any section to be updated if need be for every session when the application is in use.

42
 Figure 22: Transmitter side parameters tab

4.3.5 Receiver side parameters:

This section contains parameters which are peculiar to the receiver side(uplink) of the budget.
It contains parameters like the SINR, receiver noise figure, receiver antenna gain, receiver
cable loss, receiver body loss and so on. It view can be seen below.

Figure 23: Receiver side parameters tab

43
4.3.6 Locate site map tab:
This tab contains the view where the Google maps will be loaded if the application is
connected to the internet to display the selected area of interest where this coverage will be
carried out. This section is not fully implemented due to time constraint so I hope to continue
on the development of this section to make it better.

4.3.7 Final budget output tab:

This section contains the final parameters that are needed to produce the primary objectives
of the project (MAPL, cell radius and number of eNodeBs). Some of these parameters
include indoor penetration loss, shadow fading margin ,antenna heights(both user equipment
and eNodeB) site type, propagation model and total surface area of the specified area to carry
out the budget. This section also utilizes the calculated results from the other sections to do
its own calculations through the help of the database which helps to keep those data which
are then retrieved when needed in the calculation of any other parameter value. Below is a
final view of the tool which gives the specific objective of the application.

Figure 24: Final budget parameter tab

44
4.4 Database design:
I use SQLite database which is an inbuilt database that is design and integrated into most
desktop applications during their design for the purpose of storing data for that application
during execution. I use the database tool integrated into the IntelliJ IDE to create the database
and tables involve. Four tables where created to hold variable data as per project. A project
table was created which carries the project id, name and network generation as main
attributes. Then followed by the creation of three other tables to hold data for the different
network generations with each having its own attributes that are needed by such a project
involving that generation. Since each project is associated to a particular network generation,
the various generation tables are related to the project table using the project_id field in all
other tables. Below is the relationship established between the project table and the other
tables.

Figure 25: project database tables design and relationship structure

The parameter table stores the data on the parameter tab section of the GUI, the downlink
table stores the data on the transmitter side tab, the uplink saves those for receiver side
parameters and the budgetOutput table stores the ones for the last view on the application.
From the figure above, it is shown some arrows. These arrows indicates the relations of the
saved data to the other tables. The budgetOutput tables contain arrows from all the tables
because it utilizes data from all the other tables to perform its own calculations.

45
 CHAPTER 5: RESULTS AND CONCLUSION
5.1 Results
The results obtained is based on LTE planning parameters for Molyko - Buea. Firstly I created a new
4G/LTE project then proceeds coverage planning, display of sites on Google map, perform capacity
planning, do a market estimate and finally generate a pdf report of the project.

 Create a Project:

Figure 26: create project

 Perform Coverage Planning

46
 Figure 27: results of coverage planner
 Site Display on Google Maps

Figure 28: site display on Google Maps satellite view

 Perform Capacity Planning

47
 Figure 29: Capacity planning
 Do a market Prediction

Figure 30: Market Estimate

48
  Generate PDF report of the project

Figure 31: Print Preview of generated report from project

5.2 Conclusion
The project aimed TO DESIGN AND IMPLEMENT A SOFTWARE TOOL TO DO
COVERAGE AND CAPACITY PLANNING FOR 2G(GSM), 3G(LTE) and 4G(LTE). The
goals of this project were to:

1) Design and implementation of a software tool to do radio network planning (coverage

and capacity planning) for 2G(GSM), 3G(UMTS) and 4G(LTE). This tool is capable
of doing the following;
 Create a project
 Perform Link budget calculations for the various network generations stated based .
 Display coverage sites on a Google map.
 Carry out capacity calculations per project.
 Do a rough estimate of the market revenue based on the capacity parameters.
 Generate a printable pdf report of the project

49
The objectives of the project were achieved by observing software development procedures
and principles for software designs and implementation. In achieving the goals of this project,
two major parts were designed and implemented which is the research about the functional
requirements needed by tool and the design and implementation of the tool using the JavaFX
programming framework. The design of this tool was done in steps which are; Firstly the
designed with the JavaFX scene builder application which provides a UI is attractive,
intuitive, responsive and with good user experience in mind. Secondly, the design of the
SQLite database was realized, and the contents of the database can be easily accessed directly
by the application during execution instead of using a third party database management tool
.This database secure and easy to manage the data needed by the application in any
calculation. Furthermore, all required functionalities were implemented accordingly and,
hence, a fully operative and functional desktop application was developed. The application is
able to perform coverage and capacity planning for a chosen generation of interest(based on
the scope of the project title) and to add as a functionality display the sites on a Google maps
and generate a pdf format report that can be printed for use in the fields by engineers and
technicians.

5.3 Future work to be done

Due to the short time for development and deployment of this project, much was to be done
to increase and enhance the functionality of this tool which will actually boost it usage by
many researchers and firms involve in the process of radio network planning. Below is a list
of task which are to be perform to increase the functionality of this tool.

1. Project export and import. This is to be done so that a user can take a project to a
different computer running this application so that he or she can continue with a
project that was created at one computer.
2. Perform Monte Carlo simulation. This is needed because such a tool needs to be
able to use the parameter inputs together with the calculated values to do simulations
like signal degradation, signal fading margin, interference of signals from
neighboring cell sites, and so on.
3. Better look and feel. This tool should be able to have a better look and feel so as to
give a better and good user experience and to structure the flow of operations during
working on a project. Also we need to work more on the gauge components to be
able to give a better visualization of user data and calculated results.

50
4. Perform Automatic Frequency Planning and Market Estimation. This tool should
be able to do frequency planning using the available or preset value set by the user
during the project. Also more work have to be done on the market estimate section so
as to give a better visualization of a project during preplanning and detailed planning
of a project.

51
REFERENCES
1. Web-Based System for Radio Planning in WRAP by Nabin Raj Shakya.
2. www.lteencyclopedia.com/ LTE Radio Link Budgeting and RF Planning -
lteencyclopedia
3. Long Term Evolution (LTE) Radio Access Network Planning Guide by Huawei
4. 3GPP Release 10 and beyond IPv6 integration GSN-UMTS migration to 4G
5. https://www.credosystemz.com/training-in-chennai/asp-dot-net-mvc-training-
chennai/Mewer R. Professional Android 2 Application Development. Indianapolis:
Wiley Publishing, Inc.; 2010.
6. Lim J. Algorithms, Flowcharts, Data Types and Pseudo Code [online]. CA: scribed;
January 2011. URL: http://www.scribd.com/doc/46981114/Algorithms-Flowcharts-
DataTypes-and-Pseudo-Code. Accessed 13 November 2014.
7. Gilmore J. Beginning PHP and MySQL from Novice to Professional 4th edition.
NewYork: Apress; 2008.
8. Foundamentals of Cellular Network Planning and Optimization;
2G/2.5G/3G……Evolution to 4G; Ajah R. Mishra.
9. Indoor Radio Planning: A Practical guide for 2G, 3G and 4G by Morten Tolstrup
third edition

52