Saturday, January 14, 2017

Growing to like Linux

My first experience I had with Linux was when I bought those micro laptops way back in 2008 or 2009, the ASUS EEE PC.  I didn't have enough money to buy the cheapest Windows laptop back then but I needed to have one as I was aiming to finish a set of lengthy documents that I needed to submit to complete my visa application to Australia.  I didn't want to use the laptops the company gave me as they were shared resource and I didn't want anyone to know that I was planning to leave at that time.

Then one day, I saw them advertise these affordable ASUS EEE PC laptops but they come with a Linux operating system. I've never touched an OS before outside of DOS and Windows but I thought I'll just have to learn this as this is the only way I can finish the documents on time.  At that time, I was the unofficial lead of my small rag-tag of smart RF engineers, and my job involved a whole lot of traveling.  I had to travel to Manila almost monthly for a day or two to report to my Makati-based superiors and I had to travel  monthly for a week or 2 to do regular drive test activities (mostly benchmarking drive tests) within the Visayas region. 

So it was a bit of a struggle at first as everything was different from Windows.  There were no .exe files and the CLI commands are different.  Thank God for Google as it helped me a whole lot.  At the time, the concept of repos were alien to me and I had to look into google everytime I had to install a new program or if I wanted to do something using the CLI.

At that time, the only thing that mattered to was that it had a working word processor and one that is compatible with Microsoft Office.  I was able to know Libre Office and managed to install one on my EEE PC. As I used my EEE PC, I began to like using Linux and have developed an interest to it.

After a few years, when I was able to buy my very first laptop, I tried to find a way to have it dual-booted. This time I used a more familiar variant of Linux which was Ubuntu.  But I had to admit, because of all the technical jargon, I gave on up Linux at one point and decided to just use Windows and maybe, if I have enough money, buy a MAC OS, which has OSX, a Linux-based environment as well.

When I took care of ActixOne like two years ago,  the application ran on multiple Windows servers and a single AIX server.  Since I lacked admin rights to all these servers, I didn't really have much visibility of how the hardware performed.  After a year or so, a new set applications came our way and they ran on Linux servers and since we were given full admin rights to these servers, my interest with Linux was again rekindled.  Now I am looking forward to try and get myself at least an RHCSA.

Sunday, December 27, 2015

Being an OSS Support Application Engineer

During my RF Optimization days, we had to do a lot of stuff and I was forced to resort to look into automation as doing things manually wouldn't suffice.  One thing led into another: first it was learning VB6, then MS Access and MS Access VBA.

And when I migrated to Australia, I got a chance to play around Oracle SQL, then someone introduced me to Perl and then without knowing my job and my interests had shifted from the RF optimization side to the world of computers.

One year ago, I got a chance to work for OSS Support and I thought, why not.  Most of the things I have done for the past years have always involved automation and I thought maybe this was really destiny.  Now I get a chance to look into million-dollar enterprise solutions and get to understand them in a deeper level that I've never had a chance to.   

The first application I got assigned to was ActixOne. Wow, for me it was perfect. I had good RF experience and I understood what exactly the users wanted.  I had to adjust a bit with the OSS part but I was blessed enough to have a good manager and some good teammates and the transition wasn't a problem at all.  Also, the guys from Actix are a bunch of good guys so I got to learn ActixOne without too much hassle.    

I kind of like doing this OSS Support gig as the objectives are clear. Your application is either broken, fixed or has limitations and that's it.   Incidents come in, you fix them then investigate further to find the problems causing these incidents to occur, of course being part of the ITIL V3 practices that is being observed. 

So far, I have learned a lot and this fills up my hunger to learn anything new.  I got myself ITIL V3 Foundation certified, I learned Python 2.7 and now learning other stuff like Centos 6.5, Solaris 10, and many more.

Sunday, February 1, 2015

Being an RF Optimisation Engineer :)

I used to work for a telco where the RF planners and the RF optimisers work in different groups, and as my old colleagues used to joke,  RF Optimisation exists because of bad RF planning.  Doesn't sound too good to the RF planners but there may be some truth to that in some areas of the world. Well, in their defense, their analysis of things are limited to the prediction tools that they have and there are telcos that don't really spend money on tuning their prediction models at all.  But then again, no matter how tuned the prediction model and no matter how updated the clutter information, prediction will remain as that and the RF optimisation engineer comes to save the day by analysing actual performance measurements, L3 messages from drive test logs and so forth (assuming that all these things are accurate which isn't the case all the time).

Anyways, the good thing about being an RF optimisation engineer is the travel. You get to see many places and get to stay in fancy hotels. How fancy you ask? Well, it depends on how much your employer allows you to and sometimes its really not that fancy.  But I'm easy to please, as long as there is free buffet breakfast, well that is fancy enough for me, thank you. :)

The worst thing about it is too much travel. Imagine endless hours of driving around the city operating a drive test kit and collecting data only to find out in the middle of your activity that the whole drive test log has been corrupted because of malfunctioned drive test equipment.  I got so sick of the long driving that I had to sing to myself just to keep me sane at times and trust me, hearing me sing is not good at all. Take my word for it.  

One bad experience I had about drive testing was when we were doing it on rebel infested areas and a group of people with high powered guns signaled our vehicle to stop. Of course, there was no other option but to stop as the road will not allow you to accelerate faster than their bullets. One guy approached us and asked us what we were doing.  I tried to be very courteous in explaining that we work for this telco and we were drive testing. If he had said, get off the car, you are all coming with us, I would have told him.."Take this guys, he is rich" while pointing to my passenger. I admit that was very bad of me even if it was something I just thought of as a joke. So, after hearing my explanation, we were lucky that he just told us to not pass by there again as we entered a private road and was trespassing. 

After the drive test and data collection, the RF optimisation engineer then post processes the logs and analyses the results, correlates performance measurements from tools like Nokia reporting suite or NPM or Huawei's PRS.  Depending on the data gathered, the RF optimiser can then suggest changes on the network. Changes would involve parameter changes and/or physical changes in the antenna azimuth, tilt, etc. hoping to improve KPI's that upper management understands (or doesn't understand) as measures of customer satisfaction.

Well, the experience will vary from engineer to engineer working in different telco's and in different parts of the world.  Aside from drive tests, there are tasks of preparating for high traffic events such as Christmas, New Year's Eve or a Justin Bieber concert.  Sometimes, you get to be tasked to optimise capacity like reallocation of resources, etc. and a whole lot more.  There are even some that are both planners and optimisers.  

Based on my experience, TEMS was solid as a drive test tool.  Actix was a good post-processing tool and I found PRS to be a better performance management reporting system. 

Being an RF optimisation engineer was a great experience during my earlier days in telco. One that I will always cherish...til next.

Monday, February 17, 2014

Nokia Performance Management (NPM) versus Huawei's Performance Reporting System (PRS)

Today, I'll compare two of the performance reporting tools that I have good some experience with. In my more than 10 years working in the mobile telecoms area, mostly handling radio cell performance, I was fortunate enough to use two good vendor tools, NSN's NPM and Huawei's PRS. 

In my experience, Huawei's PRS dominates NSN's reporting suite on a whole lot of things but just recently, with the emergence of NPM, the gap has become closer and NPM even has some cool features that PRS doesn't. We'll try to summarize everything up in this article and try to categorize each feature. 


I've worked for 3 different operators and it always seems that PRS is faster than the web-based NPM. Selection of objects, changing of objects, creating cell groups, reports customisation, KPI customisation, etc are also way faster when done in PRS compared to NPM. PRS has a clear dominance over NPM in this category. 

Data Presentation: 

Both vendor tools have limited flexibility with regards to capability on changing the pre-defined charts but NPM has the prettier looking charts compared to PRS. What NPM lacks in speed, is made up for aesthetically. NPM also has the capability to show multiple charts at one time, a feature that PRS lacks. Also, I've noticed that some engineers don't often opt to use PRS charts directly in making presentations and would rather export the data and use excel charts in their presentation. NPM wins this category over PRS. Score 1-1 with 4 more categories to go. 

Data Aggregation: 

Cell level to Site level to Area level aggregation (and vice versa) and time level aggregation is faster in PRS compared to NPM. Day busy hour and week busy hour are easily configurable in PRS as well. PRS wins this category. Score 2-1 PRS leading with 3 more categories to go. 

Data Exporting: 

Both performance reporting tools have capability to send reports via email and send them regularly via a scheduled reports feature. Both can export data in excel and in csv formats. PRS however edges NPM when considering the easiness of how a user customises a report and its schedule. Another, advantage of PRS is that users can easily opt to send the exported data via FTP server transfer while I'm not sure if this is possible with NPM. PRS 3 - NPM 1. 

Multi-vendor capability: 

Straight on, NPM wins this category as it has a multi-vendor capability while PRS doesn't. This just means the NPM can process and present data other than NSN's own if the operator chooses to. 3-2 NPM lagging behind a point with one category to go. 


Summing up all each tool's features, PRS stands better and faster compared to NPM. Meaning when comparing two engineers of the same level, the one using PRS will have looked at a lot more problems compared to the one using NPM. Accuracy and details of the performance counters may matter but its a whole different story to tackle. For this post, we'll assume that both vendor counters are equally reliable. 

So that's it. NPM comes close but PRS still wins 4 categories to 2. Excited to use the new versions of both tools though as they come. Will the new NPM eventually close the gap or eventually overtake PRS? Or will the new PRS, leave NPM to eat its dust again? We'll see if we are still fortunate to be there when that time comes... 

In the end though both are good enough tools to use for analysis and reporting. The effectivity of these tools are still limited by the skill of the engineer using it and as they say, a sword is only as deadly as the skill of the one using it. 

Please don't hesitate to let me know if you have any disagreements or any comments...til next time....