Ericsson Full Stack Development

During my years with Ericsson I’ve developed many tools to automate my work, making it more efficient and less sensitive to human error. To help with deployment, I developed my own build pipeline (since there was none in place at the time). There was a leading development version of each of these tools, with an automated build procedure at the click of a button. When any network engineer opened their outdated personal copy of a tool, they were prompted to upgrade to the latest version. Upon accepting, the tool automatically retrieved the latest version for them.

The names of these tools may seem a little silly. They are a bit tongue-in-cheek; I have no regrets.

EWS Pro — Near-real-time Early Warning System

Tech stack: SQL Server, MySQL, JavaScript, PHP, WordPress

EWS Pro report page

EWS Pro report page displaying data of latest ROP

As part of a new 24/7 service for our biggest customer, we had to upgrade our existing Early Warning System to be more responsive and real-time. I was selected to perform the upgrade to EWS Pro, while ensuring that the current service delivery was uninterrupted.

EWS Pro processed several million records every 15 minutes and displayed the reports in a continuously self-refreshing website. Using EWS Pro, performance engineers were able to quickly identify problems in their early stages, and act accordingly to relieve the network before the problem would become noticeable by end-users. The raw data retrieved from the network (so-called performance counter data) was imported into an SQL Server database. The database would feed these 15-minute ROP (report output period) data sets into formulas that calculated all sorts of Key Performance Indicators. These KPIs were then displayed in a WordPress website, where the performance engineers could review the history of each KPI up to 72 hours. Needless to say, there was an enormous amount of data being crunched every 15 minutes, and an even larger amount of data being kept for history purposes (like spotting trends).

Some important requested features of EWS Pro were to:

  • display a summary of KPI breaches, grouped by network (2G, 3G, and 4G);
  • allow editors to change the KPI formulas without service interruption;
  • automatically validate KPI formulas before running them through the data, in order to prevent system crashes (for example, to prevent engineers from specifying non-existing database column names causing division by zero errors);
  • generate beautiful charts, suitable for sharing with our client without the need of additional graphics software;
  • export data to other formats (such as CSV, Excel, and JSON);
  • use different thresholds for KPI breaches depending on the time of day and day of the week, which allowed performance engineers to create so-called business hours, off-hours, and special event profiles.

Harmony — Radio network consistency check

Tech stack: SQL Server, MS Access, Visual Basic, Transact-SQL, AWK, MoShell

The Harmony GUI

Harmony v3 front-end (MS Access 2003)

With the introduction of 4G (LTE) in The Netherlands for one of its largest telecom operators, new tooling was needed to maintain this network, and ensure interoperability between 4G and the existing 2G and 3G networks. One of the most important programs that came forth out of this need was Harmony. The front-end was developed in Microsoft Access 2003. Making use of Visual Basic to tie it into a backend SQL Server, where much of the grunt-work was performed by stored procedures. With the launch of version 3 of Harmony, nearly every aspect of the tool was automated, and — save for a sanity-check performed by one the team’s network engineers — functioning autonomously.

To summarize the flow of data in and out of Harmony, these steps were performed every day:

  1. At 01:00 every night, a scheduled task on the Windows Server hosting Harmony launched to performs today’s tasks.
  2. Harmony connects to a Linux machine via SSH, where it starts processing all network events of the last 24 hours (roughly 5 GB).
  3. The network nodes with changes are identified, and queried for fresh network data.
  4. Network data of all nodes (including refreshed ones) is processed into text files suitable for importing into SQL Server.
  5. Harmony downloads all files onto the Windows Server, where it’s inserted into the SQL Server backend.
  6. Finally, Harmony loads a dataset with key-value “rules” which is compared with the network data. Inconsistencies are identified and saved.
  7. A network engineer starts their day with Harmony already having done all the work, and merely needs to do sanity-checks on its output. With the click of a few buttons, corrective scripts can be produced and uploaded to the network nodes to re-align their settings with the intended Radio Access Network design.

The Compass GUI

Compass v3 front-end (MS Access 2003)

Compass — Neighbour relations for Circuit-Switched Fallback

Tech stack: SQL Server, MS Access, Visual Basic, Transact-SQL, AWK, MoShell

When independent radio networks need to interoperate, additional configuration is needed to point out certain “entry and exit points” for those networks. When receiving a voice call while your phone is connected to 4G, it needs to revert from a packet-switched network to a circuit-switched one. In my situation, this so-called Circuit-Switched Fallback (CSFB) needed to occur from 4G to both 3G and 2G networks. The operator provided the input for Compass, which identified which 4G nodes needed which 3G and 2G neighbour relationships for CSFB. Compass then compared the current network configuration with this desired configuration, and produced corrective scripts.

The Megawatt GUI

Megawatt v1 front-end (MS Access 2003)

Megawatt — Antenna output power and bandwidth

Tech stack: SQL Server, MS Access, Visual Basic, Transact-SQL, AWK, MoShell

4G introduced a number of “layers” on which phones can connect to the network. Each layer has its own frequency and bandwidth — generally, the wider the band, the faster your connection is. A wider band also requires more output power from the transmitting antenna to cover the same geographical area. Unfortunately, it’s not as simple as setting a fixed output power for each layer, because software licensing or the hardware equipment used can influence and limit the available power and bandwidth configuration. Because of the amount of variables for each network node that came into play, I developed a tool to assist with these settings. Megawatt checked the licensed state of each node, looked at the hardware setup, and then compared the network configuration with the design values. When licenses were upgraded, hardware was replaced or the intended design for any node in the network changed, Megawatt would detect it and create a corrective script for those nodes.

2G Autoplanner — Mass frequency retuning

Tech stack: C++

2G Autoplanner in operation

Autoplanner displays the progress of a single retune, the overall progress, and shows the results of the previously retuned transmitter.

I wrote this program to speed up my work for a major nation-wide GSM 900 and 1800 frequency-band overhaul between all mobile telephony operators in The Netherlands in 2013 and 2014. Frequency bands are auctioned by the Dutch government to be used by operators for a fixed period of time. After this period, frequencies are re-auctioned. So it’s possible that every couple of years, operators win the auction to a different frequency band than they were using before. When that happens, all operators must carefully shuffle around their bands until everyone is in their newly assigned bands. This required very careful coordination between all operators, and involves a lot of work for the engineers, as they need to retune all transmitters in the network to accommodate to the new frequency design. Instead of doing this by hand, I wrote a C++ program that took an existing state of the network for any given day of the week, and combined this with an interference matrix – a data set containing information about how strong a frequency is interfered at any location in The Netherlands compared to that location’s surroundings. It sounds complicated (it is!), but isn’t a very difficult concept when you are performing the retuning by hand. However, I needed to teach a computer to calculate the best results for hundreds of transmitters each day. While it’s arguably not the most efficient code I’ve ever written (not very DRY at all, in fact), I’m happy with the program’s performance. It was both a lesson in C++ and creating specialised algorithms.