# A Modular Web-Based Software Solution for Mobile Networks Planning, Operation and Optimization
## 5 Implementation
### Network Overview  
In general, the overview of the network encompasses two stages. Firstly, the data of interest should be selected via filters available in the interface. That is the case, for example, of cells that must satisfy requirements such as frequency, technology, operator, whether the cell is indoor or outdoor, or specific cells via ID; or DIs related to particular technology, frequency, time interval, and so on. Then, the data collected from the database will be shown over a correspondent geographical map. Figure 5 highlights the kind of view we expect once we start grasping the state of the network.  
Figure 5: System overview, zoom and details.  
For example, after selecting cells and DTs of interest, a user can see the fetched information superimposed over a map and then he or she can interact with. In the end, it follows the classic information visualization mantra: overview first, zoom and filter, then details-on-demand [28]. Hence, if there is too much information to be visualized at once, the solution will cluster the visual objects and show them as zoom in progresses. Then, at some point, the user will use visual functionalities to explore further the information of interest. For example, to display a panel with information about a particular cell, as depicted in Figure 6.  
On the other hand, users are also entitled to collect and visualize metrics about the status of the network, the so-called KPIs. These are mostly shown via graphs.  
**Cells and sites representation.** Once we reach a point of zoom in over a map where we can interact with cells and sites they are in, let us say over a particular street, the visual representation of those entities and interactivity available is critical to provide a good user experience and so understanding the network. On that basis, we introduce a novel visual representation of cells in a site, as depicted in Figure 7.  
It works as follows: for a particular site, which holds a latitude and longitude, we represent a cell as a 4-side polygon within a _flat cone_ whose pointed vertex is the location of the site and it points towards the direction of the correspondent azimuth. The opening angle is restricted to up to 180\({}^{\circ}\). Furthermore, because we may have various technologies at once--2G, 3G, 4G and 5G--there will be concentric rings, one after the other, for each technology and colored accordingly, and where cells will be drawn in. The _flat cone_, mostly defined by latitude, longitude and azimuth, is somehow filled in, first by technology and then by the cells of that technology. In order to differentiate cells within each _flat cone_/ring, we use two opacity levels set in an on-off mode.  
The case for indoors is treated similarly but now there is no azimuth so cones have 360\({}^{\circ}\) opening compulsory.  
It is worth noting that, if for some reason there are too many cells in a particular site, that is, it was expected to graphically represent them just in one particular geographical location, the solution sorts out the overcrowd problem by representing various sets of cells in a spiral fashion so they will not be overdrawn one on top of each other. In the end, cell interactivity is always guaranteed.  
Figure 6: Panel with cell information.  
**Workspaces.** In order to improve productivity, the solution allows users to record settings of filters they are using at some point in time, when they are looking for information of interest, so they can use them later on. We call these recordings as workspaces. Hence, users are entitled to create as many workspaces as they want, and to manage them. Later on, probably in a new working session, they may delete, update or upload them, one at the time.