Reading longer texts takes some time. A cup of tea (or coffee) might help. ☕ |
|
Some keywords:
Embedded systems COTS Virtualization Virtual machines Containerization Cloud-native applications Embedded software C C++ TTCN-3 Functional testing System testing CI/CD Continuous integration ClearCase Git Gerrit Jenkins Rhapsody PlantUML Software architecture UML Redmine Jira
During the master's thesis at Ericsson I got quite a few contacts – including managers. Therefore, it was not that surprising when I was offered a job soon afterwards. (Three months is considered "soon" in large corporations in Sweden.) The position was called "software developer", quite as expected. Perhaps, I should also mention that back then most of telecom systems were built on purpose-built hardware parts, which means a specific subgroup within the world of embedded systems. This approach changed over the years – first in shifting towards using COTS components instead of bespoke solutions. This migration was sometimes called virtualization since such new COTS hardware platforms were seen as virtual machines in comparison to native solutions. This shift continued over the years towards the logical next step – containerization. Today, quite many telecom products are developed as cloud-native applications. Nevertheless, in other products with much higher performance requirements it is still quite common to see embedded software. And back in 2012 embedded software solutions were the only choice.
The organization was completely new to me – Packet Core. For those who prefer to continue reading about portfolios in strong marketing terms I can only feel sorry. But for others I can still suggest checking out a couple of products. Skimming both pages quickly will be enough. These two:
Of course, I was involved in the development of a few other products too. Nevertheless, most of my time at Ericsson was spent on EPG and PCC.
|
|
Some people don't like complicated things. For them I have an extremely simple (almost primitive) explanation of the packet core. Every time one is using his smartphone, the smartphone "talks" to something. That "something" is usually a cellular base station that has a few antennas and can communicate via radio waves. Behind that base station is the "brain" of the network – it makes all important decisions. That "brain" is the packet core. There are quite a few decisions. For example, when one is moving and streaming some video, the network can perform a handover between base stations so that the user does not notice any interruption. Different users need to be handled differently – gold subscribers will receive higher connection speed than bronze subscribers. On the other hand, different devices need to be treated differently – vending machines do not require the same capacity as security drones, different traffic types need to be handled differently, some traffic might even need to be blocked or reported as suspicious. Planning and prioritization of limited resources in the network is yet another challenge. Besides, network statistics also need to be gathered and analysed to be able to make performance improvements. In other words, mobile networks are complex and the packet core is handling the central part of that complexity. That was the simplest explanation that I could come up with. I hope that it makes sense to you. To get slightly deeper into details one can read about the Evolved Packet Core (EPC) and its advanced counterpart 5G core network architecture. To those who like asking about programming languages I usually say that it depends on the concrete task. One could almost imagine that during my more than 12 years at the company my tasks were not always the same. (That part might seem obvious. Nevertheless, I have met people who were doing one and the same thing for much longer than 12 years. Perhaps, it is another way of how robotization might look like.) Most often, my tasks were about writing the production code with high performance requirements. Therefore, most often it was C and C++. Nevertheless, the situation was constantly changing. For example, quite quickly our team became involved in migration of the product to a new platform, which made all of us to learn some basics in TTCN-3 and functional testing in general – usually with 1-2 users. A few years later I got to learn how to test under heavy load with hundreds of thousands and even millions of users – typical system testing. Not sure if I need to mention memory management, debugging, unit tests and component tests – all of those should be obvious to everyone. But what certainly needs to be mentioned is the CI/CD transformation, where our team played the central part. One can see us as pioneers. Or as guinea pigs. Previously every delivery had to be coordinated manually by a project manager and other process people, which was usually quite long and highly inefficient. Instead, we became CI-pilots – the first team to start doing small and frequent deliveries under full responsibility to fix all issues if/when things go wrong. Today it is known as continuous integration. Later most teams (in turns) took the role of CI-nurse, being responsible for keeping the integrated codebase healthy and running. Somehow there was a coincidence with some changes in teams which made me being in CI-nurse teams several times – I was really having fun. As a side-effect, we needed to change from ClearCase (probably, no one really missed it) to Git, Gerrit and Jenkins. Complemented by some internal tools, of course. Besides, we had to migrate from Rhapsody to PlantUML – those who have ever tried merging models in Rhapsody will probably understand. But since the software architecture was quite complex, we still had to continue using UML to keep the shared understanding among all developers in the organization. Perhaps, I should also mention moving from ClearQuest first to Redmine and later to Jira. |