When it comes to the management of a wireless network, there is a natural and logical tendency for engineers to focus on engineering matters. This often means disregarding the implementation of sound practices for network planning database management. Unfortunately, the cost of loose data management practices is not immediately noticeable and it often takes years before an operator truly realizes the gravity of the situation. Often, it is a new initiative that makes it obvious that the network planning database is inaccurate or inconsistent. In any case, the cost for an operator can be very substantial, ranging from a lack of efficiency, to errors in the network database, which can lead to expensive mistakes such as erroneous network build outs.
From our experience, there are several types of problems that exist with network planning databases. The gravity of the problems will vary greatly from one operator to another and even within a single operator who is regionally divided (which is typically the case for large operators). Here are the three primary types of errors we see in network planning databases:
Erroneous site locations — The antennas of the majority of operators are not correctly geo-referenced (within 3m of absolute accuracy). One of the classic issues we see frequently is that all antennas at a site are using the same geo-location while in reality, the antennas are actually installed at a corner of a building. The impact of such inaccuracy in the network database is multi-fold, from incorrect optimizations to the inability to perform accurate predictions.
Inconsistent naming conventions — All operators have naming conventions for network elements. The question is really how well it is applied and whether it applies to all the data that it should. For example, an operator might have a good cell and site naming convention but lacks a proper naming convention for other data such as antennas, propagation models, flags, frequency plans and so forth. The impact of a poor naming convention is typically that it makes it harder to find the right data, leading to inefficiencies and mistakes.
Data duplication — A classic example of duplication is the use of data duplication as a means to perform “what-if scenarios.” This is most common with network planning tools that do not offer sand-boxes for engineers or teams of engineers to collaborate on a scenario. The impact of data duplication is the uncontrolled expansion of the site database size and all the issues associated with that — ranging from extensive data manipulation to the risk of introducing data errors.
Operators who successfully manage their network planning database are generally doing two things very well: First, they adopt rigorous practices for managing their network planning database and second, they use network planning software capabilities to implement those practices. An example of this is the use of permission management to ensure that only the people who should, can actually make modifications to specific types of data.
The Mentum Planet Data Manager, a fully access-right driven multi-user data collaboration platform for network planning engineers, provides the kind of capabilities required to support best practices. This is also true for Mentum Planet and its unmatched support for scenario-based planning, which provides engineers and teams with sand boxes for them to work on. The Mentum Planet Data Manager is included with Mentum Planet Enterprise, the reference network planning tool from Mentum.