pre_engineer

UNIVERSITE DE YAOUNDE I
------------------------------
ECOLE NATIONALE SUPERIEURE
POLYTECHINQUE
-------------------------
DEPARTEMENT DES GENIES
ELECTRIQUES ET DES
TELECOMMUNICATIONS
UNIVERSITY OF YAOUNDE I
-----------------------------------
NATIONAL ADVANCED SCHOOL OF
ENGINNERING
--------------------------------
DEPARTMENT OF ELECTRICAL AND
TELECOMMUNICATIONS
ENGINEERING
REPORT OF END OF PRE-ENGINEERING INTERNSHIP
4th
Year Telecommunications Engineering
Internship Undertaken By: Biami Epenetus Kum
Under the Professional Guidance of: Mr. KEMAYOU Anicet
And of: Mr. ZAMBOU Charlse
Academic Year: 2015/2016
DEVELOPMENT OF A DASH BOARD FOR OCM SMC
MONITORING USING QLIKVIEW
AND
FEASIBILITY STUDIES OF THE MOBILE ROBOT; EQUAL
ONE.
THE CASE OF ORANGE CAMEROUN S.A

DEVELOPMENT OF A DASH BOARD FOR OCM SMC MONITORING USING
QLIKVIEW AND FEASIBILITY STUDIES ON THE MOBILE ROBOT EQUAL ONE:
THE CASE OF ORANGE CAMEROUN S.A.
BIAMI Epenetus KUM Page 2
DEDICATIONS
I dedicate this piece of work to all
those who have unfailing confidence in
me and who continue to encourage me
in my trying moments.

ACKNOWLEDGEMENTS
To GOD ALMIGHTY for his love and abundant grace he has shown towards me, especially
during my stay in school for these past four years. I pray that he continue to give the
grace and wisdom to continue to move onward in his glory.
Thanks goes to everyone who in one way or the other helped in the completion of this
work. They include:
 Mr. KEMAYOU Anicet, chief of service of Real Time Monitoring for accepting to be
my professional supervisor during this internship.
 Mr. ZAMBOU Charlse, former chief of Core Network who took upon himself to co-
supervise me during this internship.
 Mr. TCHOUGONG Edouard, technician at RTM who have assisted me in
understanding the monitoring tools throughout this period of my internship.
 Mr. NYAMNDING Paulin, assistant chief of service of RTM who have assisted me
throughout my internship.
 Mr. METO’O Cyrille and Mr. ESSOMBA Victor for their remarks during my
internship which poised me to work harder.
 All the technicians of Real Time Monitoring for the professional guidance they gave
me throughout my internship.
Thanks also go to:
 My Mother Mrs. Bridget Kum for her countless support.
 My aunt and uncle Mr. Alang George and Mrs. Alang Adeline for their kindness and
support towards me during this period of internship
 My sister Miss. Becky Kum and brother Robert Kum for the assistance they gave
me during this period.
 To my friends Jean Gabin and Mukam Aubry whom we worked in the same service
during this period.
 To my friends Tindjou Tatodji Stefan and Christian Nankang For the support they
gave to me in developing my project during this internship period.

LIST OF ABBREVIATIONS
Abbreviation Meaning
DQA Device Quality Agent
FTP File Transfer Protocol
GSM Global System for Mobile Communication
GPRS General Packet for Radio Services
HTTP HyperText Transfer Protocol
HTML HyperText Markup Language
IMEI International Mobile Equipment Identity
IMSI International Mobile Subscriber Identity
KPI Key Performance Indicator
LAN Local Area Network
MTTR Moyen Temp de Traitement Reussite.
OCM Orange Cameroon
ocm On Click Monitoring
OTA Over The Air
OTT Over The Top
PHP Personal Home Page
QoS Quality of Service

QoE Quality of Experience
RTM Real Time Monitoring
SLM Silent Live Monitoring
SMC Service Management Center
SMS Short Message Service
SSM Silent Script Monitoring
SFTP Secure File Transfer Protocol
TEC Temp de Traitement En Cours
TTR Temp de Traitement Reussite
V3D Vision 360°
WCDMA Wideband Coded Division Multiple Access
WiMAX Worldwide Interoperability for Microwave
Access

Table of Contents
DEDICATIONS .......................................................................................................................................... 2
ACKNOWLEDGEMENTS.................................................................................................................... 3
LIST OF ABBREVIATIONS................................................................................................................ 4
Table of Contents .......................................................................................................................................... 6
LIST OF FIGURES..................................................................................................................................... 9
ABSTRACT................................................................................................................................................. 10
RESUME.......................................................................................................................................................11
INTRODUCTION......................................................................................................................................... 12
1. CHAPTER I: CONTEXT AND PROBLEM STATEMENT .......................................................... 14
1.1 The Society ORANGE CAMEROUN S.A. ............................................................................. 15
1.1.1 Presentation of the Network Operator........................................................................... 15
1.1.2 The services offered by the operator......................................................................... 15
1.1.3 The Administrative Organization................................................................................... 16
Problem Statement .................................................................................................................................20
2. CHAPTER II: STATE OF ART AND METHODOLOGY............................................................22
2.1 State of Art .......................................................................................................................................23
2.2 Analysis On the Development of a Dash Board.......................................................................25
2.2.1 The Platform QlikView......................................................................................................26
2.2.2 Key Performance Indicator..............................................................................................27
2.2.3 Web Connection with the Server...................................................................................28
2.3 Conception......................................................................................................................................29
2.3.1 Ticket Count:........................................................................................................................29
2.3.2 Time of Successfully Treating a Ticket (TTR): ........................................................29
2.3.3 Average Time of Sucessfully Treating a Ticket (MTTR):......................................29
2.3.4 Time of Treating a Ticket in Course (TEC): ...............................................................29

2.3.5 Delay in Ticket Creation:..................................................................................................30
2.3.6 Delay in Ticket Closure: ....................................................................................................30
2.4 Technologies Used ......................................................................................................................30
2.4.1 Wamp Server........................................................................................................................30
2.4.2 PHPExcel................................................................................................................................30
2.4.3 PHP EWS................................................................................................................................ 31
3. CHAPTER III: RESULTS AND IMPLEMENTATION..............................................................32
TOPIC 1: DEVELOPMENT OF A DASH BOARD FOR OCM SMC MONITORING USING
QLIKVIEW.....................................................................................................................................................33
3.1 Presentation of the Dash Board for OCM SMC Monitoring................................................33
3.2 The Reloading QlikView.........................................................................................................34
3.3 Displaying the Various KPI. ..................................................................................................35
3.3.1 Number of Tickets created per priority.....................................................................36
3.3.2 Number of Tickets created per Product Type..........................................................37
3.3.3 Time of Successfully treating a ticket (TTR). ..........................................................38
3.3.4 The Time Taken for the Treatment of Tickets in Course (TEC).........................39
3.3.5 Number of Tickets created per busy and non-busy hour. .....................................40
3.3.6 Delay in ticket creation and ticket closure. ............................................................... 41
3.3.7 Personnel Statistics...........................................................................................................43
TOPIC 2: FEASIBILITY STUDIES ON THE MOBILE ROBOT EQUAL ONE.........................45
3.4 Notion of EQUAL ONE...................................................................................................................45
3.5 DQA.....................................................................................................................................................45
3.5.1 Operation Modes .......................................................................................................................45
3.5.2 Mobile Agent Requirements ..................................................................................................47
3.6 KPI COLLECTION............................................................................................................................48
3.7 EQual One Server ............................................................................................................................48

3.7.1 One Trend .............................................................................................................................49
3.7.2 One Network ........................................................................................................................50
3.7.3 One Customer....................................................................................................................... 51
3.8 One Admin...........................................................................................................................................52
3.8.1 Agent Configuration..................................................................................................................52
3.8.2 Running a Scenario....................................................................................................................54
3.8.3 Dashboard & Reports...............................................................................................................56
3.9 EQUAL ONE SERVER ARCHITECTURE ...................................................................................59
3.9.1 System Overview.......................................................................................................................60
3.9.2 Requirements.............................................................................................................................. 61
GENERAL CONCLUSION..........................................................................................................................62
I. Reminder of the Problem Statement ........................................................................................63
II. A Summary of the Solution put in Place...............................................................................63
III. Difficulties Encountered ..........................................................................................................64
Bibliography ...................................................................................................................................................64

LIST OF FIGURES
Figure 1 : The Hierarchy of the administrative division of ORANGE CAMEROUN S.A. ...... 17
Figure 2: Hierarchy of “Direction Technique et Informatique” ................................................... 18
Figure 3: Flow chart showing the End To End monitoring and flow of services....................... 19
Figure 4: An exported Excel File showing the Ticket number, the state of the ticket and
many other information..............................................................................................................................24
Figure 5: QlikView Environment..............................................................................................................26
Figure 6: Imported excel file into QlikView. ......................................................................................27
Figure 7: The web page for downloading and importing the excel file. ......................................33
Figure 8: Reloading QlikView....................................................................................................................34
Figure 9: Main Sheet showing details of the imported file............................................................35
Figure 10: Number of Tickets per Priority, month and Severity. ................................................36
Figure 12: Tickets created per Product. ..............................................................................................37
Figure 13: Number of Tickets created for Service AMEA............................................................38
Figure 14: TTR and MTTR per Priority .................................................................................................39
Figure 15: TEC per Ticket Count............................................................................................................40
Figure 16: Number of ticket created per hour within the day...................................................... 41
Figure 17: Delay in ticket creation and closure..................................................................................42
Figure 18: personnel details......................................................................................................................43
Figure 19: Comparing the output of two technician ..........................................................................44
Figure 20: One Trend Server...................................................................................................................49
Figure 21: One Network Server..............................................................................................................50
Figure 22: One customer server ............................................................................................................. 51
Figure 23: Dimensioning scenarios..........................................................................................................55
Figure 24: Chart Showing Distribution of Voice Call........................................................................57
Figure 25: Map showing mobile agents of EQual One ......................................................................59
Figure 26: EQual One Server Architecture........................................................................................60

ABSTRACT
In today’s world, technology is evolving at an astonishing rate particularly in the
domain of telecommunications. Steve Jobs the founder of Apple declared that to bring any
meaningful technology, you have to stay hungry and foolish. With the evolution in
telecommunications, there is need for network operators to catchup with this constant
development by improving the quality of their network and the services they offer to their
users. While trying to catchup with these advancements, the network operators have to
ensure a constant functioning of their existing network especially the 2G (2nd
Generation)
and 3G (3rd
Generation) which is commonly used by most network operators. This can be a
function of the reactivity of the operator when certain incidents or alarms occur that
must be maintained.
The work at hand is to develop a dash board which displays all the activities related
to the creation of tickets and the respective actors. Also, the feasibility studies of a
mobile robot; EQual One which will assist in the monitoring of orange services.
In order for us to arrive at our goal, we will use the QlikView application for our
dash board while the EQual One application for our mobile robot.

RESUME
Dans le monde d’aujourd’hui, la technologie évolue à un taux étonnant en particulier
dans le domaine des télécommunications. Stève Jobs, le fondateur d’Apple ont déclaré
cela : pour apporter n'importe quelle technologie significative, tu dois rester affamé et
idiot. Avec l'évolution dans les télécommunications, il y a besoin d'opérateurs de réseau à
suivre ce développement constant en améliorant la qualité de leur réseau et les services
qu'ils offrent à leurs utilisateurs. Tout en essayant de suivre ces avancements. Les
opérateurs de réseau doivent assurer à un fonctionnement constant de leur réseau
existant particulièrement le 2G (2ème génération) et 3G (3ème génération) qui est
généralement employé par la plupart des opérateurs de réseau. Ceci peut être une fonction
de la réactivité de l'opérateur quand les certains incidents ou alarmes se produisent qui
doivent être maintenus.
Le travail effectue est de développer un tableau de bord qui montre toutes les
activités liées à la création des tickets et des acteurs respectifs ; cas, le ticket est crée
quand il y a un incident sur le réseau. En outre, les études de faisabilité d'un robot mobile ;
EQual One qui aidera à la surveillance des services oranges.
Afin que nous puissions pour arriver à notre but, nous emploient l'application de
QlikView pour notre développement d’un tableau de bord tandis que l'application EQual
One pour notre robot mobile.

INTRODUCTION
INTRODUCTION

In trying to meet up with the daily demands of clients who expect the best from their
mobile operator, most of the equipment and services offered by this telecommunication
operators are under constant maintenance.
To respond to this demands, most operators have partners who are in charge of
specific parts of their network and who are been alerted in case of any incidence.
Monitoring the partners and the services is of primordial interest if the client is to
receive the best of services.
The objective of this work, is to develop a Dash Board which analysis all the alerts
created, with respect to a given problem with a service or an equipment, as well as get
statistics of all those who intervened in this incident.
Also, to increase the monitoring of services, there is a need for a mobile monitoring robot
which is to be deployed in the user's mobile. This robot regularly gets vital information
from the user's mobile and communicates it to the operator who based on the results can
deduce if there is any malfunctioning with the said service or not.
My work therefore is to develop a Dash Board as well as to dimension use cases for
my mobile robot EQual One.
Before we enter into our subject matter for the pre-engineering internship at
ORANGE CAMEROON S.A, we would first give a description of the Structure and the
hierarchy which is set in place.

1. CHAPTER I: CONTEXT AND PROBLEM STATEMENT
CHAPTER 1: CONTEXT AND
PROBLEM STATEMENT
Chapter 1

Many network operators invest in various countries today. Cameroon is no exception
to these countries as we speak today. Cameroon harbors many network operators today in
which we can list the following: MTN, ORANGE, NEXTTEL, and CAMTEL.
Amongst these operators, ORANGE CAMEROUN S.A. was kind enough to welcome us into
their structure through their major partnership with the NATIONAL ADVANCED
SCHOOL OF ENGINEERING YAOUNDE (ENSP). This structure apart from telephony
deploys a multiple number of services. The basic service deployed by ORANGE
CAMEROUN S.A. is that of traffic on voice. We may also take note of other services such
as internet, VPN through links, WIMAX, GPRS and so on.
1.1 The Enterprise ORANGE CAMEROUN S.A.
1.1.1 Presentation of the Network Operator
Orange was born in Great Brittany in the year 1994. It was then bought by France
Telecom in May 2000. France Telecom then decided to regroup all its activities of
telephony under the denomination ORANGE S.A. As from this moment, a process known as
“rebranding” was launched across the world in order to enable the different mobile
telephone branches under France Telecom to become ORANGE S.A. Later, SCM (Société
Camerounaise des Mobiles) known as Mobilis, became ORANGE S.A. on the 4th
June 2002
during the African nations cup in which Cameroon emerged victorious.
1.1.2 The services offered by the operator
ORANGE CAMEROUN S.A., in order to satisfy its customers has put in their disposition a
large number and a variety of offers which depend on the type of customer or subscriber.
The services deployed by ORANGE CAMEROUN S.A. include:

 Voice and Traffic
 Short messages (SMS) and MMS (Multimedia Messaging services)
 Data through GPRS
 WIMAX
 Roaming
Internet services can be used by all mobile stations in the network that are capable of
supporting this type of service. Through the GSM network, Orange ensures traffic for
the voice, which is the fundamental role of any telecommunication operator.
1.1.3 The Administrative Organization
Unlike every business structure, ORANGE has at its disposal, a very sophisticated
administrative organization. The flow charts presented in the upcoming sections will show
the various head offices as well as those in charge of these offices. The screen shots
presented is an extract of the official document of ORANGE CAMEOUN S.A. showing
the organization of the various head offices.
1.1.3.1 General View of the Administrative Division
At the head of the Company is the General Director of ORANGE CAMEOUN S.A. Mrs.
Elisabeth MEDOU BADANG who started her duties as the General Director on the 2nd
of
December 2013. A screen shot of the hierarchy of the administrative division is shown
below:

Figure 1 : The Hierarchy of the administrative division of ORANGE CAMEROUN S.A.
1.1.3.2 The Hierarchy of “Direction Technique et Informatique”
The Hierarchy of this administrative branch is shown in the screen shot below:

Figure 2: Hierarchy of “Direction Technique et Informatique”
Under this administrative division is the department of Operations which is Headed by Mr.
Abeny NKEMBE.
1.1.3.5 The Different Services under Service Management Center (SMC)
The department is divided into 3 services as shown by the figure below:

Figure 3: Flow chart showing the End To End monitoring and flow of services

Problem Statement
So the question at this level will be to know on what is based this pre-engineering
report. And which particular and pertinent problem outlined here is solved and the manner
in which it is solved.
The intern was engaged in two different Research Topics. The various problem
statements will be established shortly.
1.Dash board Development.
Files been extracted from the database has thousands of lines and
columns. In order to get vital information on the alerts that were made in
the course of a period of time, I was expected to use an application known as
QlikView to develop a dash board considering some key performance
indicators.
Some of the questions to be answered are thus:
 How do you get to know the service which had the highest alert for the past
week?
 How many alerts (tickets) did a technician detect and what was the
severity?
 Which entity in Orange resolve the highest incident on time?
2.Feasibility studies of EQual One.
From the multitudes of robots that test the voice and data quality, all of
these robots are static. The need we have here is to integrate a robot in the
mobile phones so that the operator can tap out vital information about the
state of her services from her multiple mobile robots any time anywhere.
Some of the pertinent questions here are thus:
 How will the mobile robot be connected to the mobile phone?
 How will the mobile operator tap out vital information from this
mobile robot?

 Will this action require internet connection or will it be free of
charge?
The upcoming sections would be dealing with this problem and the methodology
used in solving this problem. But before we enter the methodology used, we will
first have to talk about the state of art and the existing solutions if any to the
questions listed above.

2. CHAPTER II: STATE OF ART AND METHODOLOGYCHAPTER II: STATE OF ART
AND METHODOLOGY
Chapter 2

In this section or this chapter, we will explain our methodology and our method of
approach in solving the problem stated in the chapter one above, but before doing so, will
first have to talk about the state of art and the existing solutions for our problem stated
in the previous chapter.
2.1 State of Art
The Cambridge advanced learners dictionary defines the state of art to a particular
problem as a solution which is very modern and using the most recent ideas and methods to
solve a particular problem.
1. Dash Board Development using QlikView.
Concerning what has recently been done over the years, when the files are exported from
the database, they are managed using the Microsoft office pack and most especially,
Microsoft Excel in order to get vital information about the monitoring of services.
The information is generally treated in Excel and with the use of Charts, they are
been displayed for easy comprehension. A screen shot of this excel sheet is shown in the
figure below;

Figure 4: An exported Excel File showing the Ticket number, the state of the
ticket and many other information.
As shown in the figure above, the file contains the Ticket number that were created based
on one malfunctioning of the service or another and the associated information.
In details, the file contains the following fields;
 The Ticket number which is unique and it’s been created when there is an incident.
 The state of the ticket, the priority of the ticket and the EDS piloting the
creation.
 The date when the incident occurred, the date when the ticket was created, the
date when reparations were made and the date when the ticket was closed.
 The EDS which was Activated due to the incident
 The Severity of the incident.
 The Product Type or service that is malfunctioning
 Details of the problem as well as the location.

The existing solutions used to solve the problem was to use excel tools in sorting
and applying conditions and restriction in order to get a satisfied response.
We will now have to enter into the analysis and the conception of our solution
towards the problem stated in the previous chapter.
2. Feasibility Studies of the Mobile Robot Equal One:
Orange Cameroon has many tools which observe the services they deploy to clients. Some
of these tools are;
 DashOtarie: it is used to monitor the traffic of Data
 CACTI: It is used to monitor the flow of data from Camtel (distributor of data) to
Orange Cameroon.
 Daset: It is used to check the quality of data used by a client. It monitors if the
download time of a web page is within the normal range or not.
 Voset: It is a voice checking robot. It monitors if the quality of calls is the best as
well as other vocal interactions in the network.
 OSIRI: It monitors the Radio Access Network of Orange; the RNC, BTS, nodeB...
EQual One is an embodiment of many robots which are mobile. Thus her advantage.
This robot has not yet been deployed, so I will be presenting the studies we have made
so far in the next chapter.
2.2 Analysis On the Development of a Dash Board
To analyze means to study or examine something in detail, in order to discover more
about it. I will be presenting QlikView, the application I will be working on. Also, I will
highlight the KPI that I was expected to develop. Finally, I will present the other software
which help me in this development

2.2.1 The Platform QlikView
QlikView is a software that enables all kinds of users from beginners to experts to
retrieve and assimilate data easily from any source: databases like SQL Server or Oracle
as well as Excel, XML or text files.
The software can be downloaded for free from www.qlik.com. To access the download
page, you must register, or log in to your QlikView account if you are already registered.
If you have purchased a QlikView license, you can enter the license number when starting
the program for the first time. You can use QlikViewPersonal Edition without a license.
Figure 5: QlikView Environment.
Files from the database can be imported directly into this platform before analysis of the
file begins.

When our Excel file is imported, all the columns of the Excel sheet are represented as
tables as shown in the figure below.
Figure 6: Imported excel file into QlikView.
2.2.2 Key Performance Indicator
The OCM SMC Monitoring is a service in Orange as seen under the organogram of orange.
It deals expressively in the monitoring of orange services as well as equipment. She
responds to an incident by creating tickets to the various EDS.
All the activity carried out within the entire period is stored in a database powered by
Oceane. The activities carried out so far in the company is been exported daily from this
database.

I am responsible to get this exported file and treat it with respect to the various KPI
which have been listed below.
Number of Tickets created per priority taking into consideration their state,
criticality, Year, Month and day of creation.
Number of Tickets created per product type taking into consideration the
identifier 1 product, identifier 2 product, identifier 3 product and identifier 4
product.
The Time of Successfully treating a Ticket (TTR) per priority, EDS active and
product type.
The Time Taken for the Treatment of Tickets in Course (TEC) per priority, EDS
Active and Product Type.
Number of Tickets created during busy hours (7h-18h) and non-busy hours (19h-6h)
per criticality, State of the Ticket and Ticket Type.
Delay in Ticket creation: Time interval between the start of an incident and the
creation of Ticket; which is evaluated per Total Ticket created, Priority and
criticality
Delay in Ticket closure: Time interval between the Last date of reparation and the
date of Ticket Closure; which is evaluated per Priority, Product Type, Criticality and
State.
2.2.3 Web Connection with the Server.
For the development of the dash board, the files to be imported is been sent by mails to
the monitoring service. So the need of scripts which downloads, unzips and change the file
extension before importation into Qlikview.
The development of this interface was done using PHP, HTML and CSS which run in a local
Wamp server.

2.3 Conception
Conception corresponds to the phase in the construction of the software solution
with the help of models and methods. We will be presenting here the different means used
in formalizing our solution. Before doing so, we are going to write out the set analysis
needed to develop some of the KPI.
2.3.1 Ticket Count:
Each ticket has a unique number, In case of an incident, many EDS are been activated.
Thus Ticket count is distinct so as to eliminate double counting
2.3.2 Time of Successfully Treating a Ticket (TTR):
This is the interval of time from the creation of ticket to the closing of that ticket.
It is gotten by taking the difference in days and hours from the date of creation to the
date of closing.
2.3.3 Average Time of Sucessfully Treating a Ticket (MTTR):
This is the time given to treat tickets based on their priority. Each ticket has a unique
number as well as a priority which ranges from P1 to P4.
 Tickets created with priority P1 has as MTTR 4 hours
These are standard time allocated to resolve malfunctioning in services created with the
said priority.
2.3.4 Time of Treating a Ticket in Course (TEC):
This is the interval of time from the day the ticket was created to the day the file was
exported. TEC is applied only for Tickets which are still in course; they have not yet been
closed.

2.3.5 Delay in Ticket Creation:
Before any ticket is created, there must be the start of an incident. Here, I am expected
to get the difference in time from when the incident started to when the ticket was
created.
In cases where the interval of time is greater than 1 hour, it is considered as a delay in
the creation of the said ticket but when the interval is less than 1 hour, it is
recommendable.
2.3.6 Delay in Ticket Closure:
Before any ticket is closed, there has to be sufficient proof that the situation or the
incident has been controlled. This proof is gotten when the malfunctioning is repaired.
Thus there is a date for reparation. After reparation, the ticket is supposed to be closed
within 1 hour. After this time, it is considered as a delay in ticket closure.
Therefore, here, we get the interval of time from the last date of reparation to the date
of closure.
2.4 Technologies Used
2.4.1 Wamp Server
It stands for Windows Apache MySQL PHP. It is a sever that contains all the
modules necessary for the development of a web application. It contains the following
characteristics:
 It functions only on the windows operating system.
 It contains the server Apache of version 2.2.8
 It supports PHP 5 and of version 5.2.6
 It uses MySQL as an RDBMS and supports the version 5.0.51b
2.4.2 PHPExcel
It is a very useful PHP library that is capable of creating dynamic Microsoft excel
documents. It is also capable of loading existing Microsoft excel documents in order to
modify cells and change their extension.

2.4.3 PHP EWS
It is a PHP library that enables the downloading of files from an email address and
deposits it where necessary on the PC.
Having presented the different technologies used, we would now enter our next
chapter in which we would present the results of our solution.

3. CHAPTER III: RESULTS AND IMPLEMENTATION
CHAPTER III: RESULTS AND
IMPLEMENTATION
Chapter 3

In this chapter, we would present the solution which was proposed, conceived and
implemented during the internship. The state of art of the application and the subsequent
modifications in the future will also be discussed.
I will start by presenting the Dash Board project then the Mobile Robot.
TOPIC 1: DEVELOPMENT OF A DASH BOARD FOR OCM SMC MONITORING USING QLIKVIEW
3.1 Presentation of the Dash Board for OCM SMC Monitoring.
Early in the morning each day, the file to be treated is exported from the database and
sent by mail to OCM SMC Monitoring. The mail is been downloaded and unzipped on the
desktop (bureau). Next, that excel file in the unzipped folder on the desktop has to be
imported into QlikView; this is done by clicking on the button Import_to_Qlikview.
Figure 7: The web page for downloading and importing the excel file.
Importing this file takes about 5 to 10 minutes. Once that is down, we can open our
QlikView document and analyze our KPIs for the newly imported file.

3.2 The Reloading QlikView.
After having imported the file into QlikView, the QlikView document is to be reloaded so
as to take into consideration the newly imported file.
For this to be achieved, the document is reloaded by clicking on the reload button in the
tool bar. Next, the reload time is automatically shown on the environment as the Last
update time.
Figure 8: Reloading QlikView.
This welcome Sheet contains a recap of all the KPIs I am to develop. Also, each KPI was
developed in a new sheet.
Reload

3.3 Displaying the Various KPI.
With the help of QlikView all the KPI were gotten without much problems. The Main Sheet
shown below, displays general statistics of all the tickets that were created before the
extraction date.
A permanent selection have been made on OCM SMC Monitoring. This is because, the dash
board is meant to analyze activities of this service.
It equally displays only the names of those who work in that service as it can be seen on
the “Initiateur-Nom Utilisateur”.
Also, we get to see the number of tickets created per priority, State, Warning and
severity.
Finally, this sheet also display the year, months, weeks and days corresponding to the
creation of ticket.
Figure 9: Main Sheet showing details of the imported file.

3.3.1 Number of Tickets created per priority.
For this KPI, the number of tickets created per priority, per severity, per state, per
month, week and days.
This will enable the supervisors to get the minute by minute analysis of ticket creation.
Figure 10: Number of Tickets per Priority, month and Severity.

3.3.2 Number of Tickets created per Product Type.
The interest here is to get the number of tickets created per each product or service.
The figure below shows all the default product and the number of tickets created for
each.
Figure 11: Tickets created per Product.
With the various identifiers like the identifier 1 product, identifier 2 product and
identifier 3 product, they give a detail specification of where the fault is coming from. For
example Taking Reference Services AMEA we can actually get the various identifiers.
This can actually help Orange to know exactly which product is frequently malfunctioning
and thus try to remedy the situation.

Figure 12: Number of Tickets created for Service AMEA
With this KPI, it is possible to know exactly the default product as well as to know the
product is from. The identifier 1 gives a broader specification which is made more precise
by the identifier 2 product
3.3.3 Time of Successfully treating a ticket (TTR).
On the right hand side of the figure below, we have a table of tickets with the ticket
numbers and their TTR in days and hours. We can deduce from there that there is a ticket
that took 110 days before it was closed.
The chart 5 shows the tickets which are closed with respect to their priority.

As stated in the conception phase in the previous chapter, each priority has its own MTTR.
On the left of this figure, it shows several tables: the first is a table of priority P1.
Out of the 89 tickets that have been successfully treated, 35 where treated on or before
4 hours after activation while 54 where treated at a time greater than 4 hours. This gives
a delay of 60.7% for the closing of tickets of priority P1.
Similarly, we can get this details for tickets of different priorities as well as the product
type on which this tickets were written and the EDS that was activated.
Figure 13: TTR and MTTR per Priority
With this KPI, we can get details of the EDS who always resolve incidents late and the
percentage of lateness for tickets of various priorities.
3.3.4 The Time Taken for the Treatment of Tickets in Course (TEC).
It is important to know whether the ticket in course have exceeded their MTTR or not.
TEC is gotten by getting the interval of time between date of creation and date of
extraction.

From the figure below, we have tables showing the priorities, the ticket number, TEC and
the corresponding ticket count.
Here, we can see that all the tickets of priority P1 have exceeded their MTTR.
Figure 14: TEC per Ticket Count
TEC permits us know the identity of tickets which are overdue and also the priority with
the highest overdue tickets.
.
3.3.5 Number of Tickets created per busy and non-busy hour.
It is primordial to know the number of tickets created per hour of the day. Busy hours is the
period of the day where traffic data and voice are generally high. It is from 7h to 18h of the day.
On the other hand, non-busy hours are period of the day when network activities are generally
low. It is from 19h to 6h.

The figure below shows the number of tickets created per busy and non-busy hour. This KPI also
permits us to know the Severity, State and Warning on all the tickets created per hour
Figure 15: Number of ticket created per hour within the day.
From the above figure, more tickets were created in the busy hours than in the non-busy
hours.
This KPI is thus very important as it permits the network operator to know exactly at
what period of the day there is malfunctioning in the system.
3.3.6 Delay in ticket creation and ticket closure.
From the start of an incident to the creation of tickets, a maximum of 60 minutes is
permisible. After this time, the creation of ticket is considered to be late. It can be seen

from the figure below that 347 tickets were created on time while 96 tickets were
created late ; this gives a percentage delay of 21.7%.
Also, from the last date of reparation to the date closure of a ticket, a maximum of 60
minutes is permisible. After this time, the closure of ticket is considered to be late. It
can be seen from the figure below that 212 tickets were created on time while 117
tickets were created late ; this gives a percentage delay of35.5%.
We can deduce from the above stated statistics the delay in ticket closure is greater than
that of ticket creation
Figure 16: Delay in ticket creation and closure.
The chart 8 and Chart 9 shows the products whose tickets were created and closed after
the permissible time.
With this KPI, it is possible evaluate the various technicians base on their time for the
creation and closure of tickets.

3.3.7 Personnel Statistics.
The contribution and activities of all personnel of OCM SMC Monitoring are been seen on
the figure below. The number of tickets that each personnel have created over a given
period of time is in chart 10. Also, chart 11 shows the percentage a technician contribute
to the entire process. In addition the table gives the state of all the tickets created by a
technician alongside the number.
Figure 17: personnel details

Figure 18: Comparing the output of two technician
The above figure enables two personnel to compare their output over a given period. This
will enable them to evaluate themselves with respect to their colleagues.

TOPIC 2: FEASIBILITY STUDIES ON THE MOBILE ROBOT EQUAL ONE.
3.4 Notion of EQUAL ONE
EQual One is a software solution for monitoring and testing interactions between a
mobile device and network infrastructures. Smart, flexible, easy to handle and efficient.
The solution is divided in two modules that communicate over the network.
1. EQual One Device Quality Agent (DQA):
A mobile application on the end-user device that collects, computes and uploads Key
Quality and Key Performance Indicators (KQI & KPI). This solution can be installed
directly Over-the-air (OTA) on commercial smartphones and has a low impact on the
battery life.
2. EQual One Server:
A server interface that controls the DQAs, stores, transforms, aggregates and displays
the information gathered by the DQAs. As a reporting tool, it displays meaningful
information on easy to understand charts and dashboards. As a configuration tool, it
enables OTA configuration of the DQA’s for all available services.
3.5 DQA
The EQual One Device Quality Agent is a mobile application installed on the end-user
mobile device (e.g. smartphone) which extracts real-life information as they happen on
the device. Associated with the GPS location of the user, it allows the analysis and
anticipation of the device behavior on the operator network. EQual One DQA is available
today, offering quality and value by supporting the standard smartphone operating
systems:
Today, it supports all major wireless technologies used worldwide including GSM,
GPRS, EDGE, WCDMA, HSDPA, HSPA+, HSUPA, LTE and LTE+, but also Wi-Fi.
3.5.1 Operation Modes
The Device Quality Agent is used for many professional applications such as mobile
network performance test, service benchmarking, coverage, proactive customer care,

network smart monitoring… The use cases are varied and unlimited. The DQA has three
operation modes.
 OCM | ON CLICK MONITORING
In this mode, the end-user launches the service test themselves, based on a specific
scenario provisioned by the EQual One server. With its user-friendly interface, the OCM
mode is a quick and easy-to-use tool to perform sporadic tests when needed. It performs
service tests, displays information in real time and records the main KPI’s.
The KPI’S are then uploaded through HTTP/HTTPS to the EQual One Server for post
processing analysis. The available OCM services are HTTP/FTP Throughput, Web and
Video Streaming.
 Data HTTP
It launches a download or upload transfer on one or several sockets using the
HTTP protocol. It monitors the average throughput during the transfer, but
also other QoS oriented indicators such as minimum, average and maximum
latency.
 Data FTP
It launches a download or upload transfer on a single socket using the FTP protocol.
It monitors the average throughput during the transfer, but also other QoS
oriented indicators such as minimum, average and maximum latency.
 Web
It launches a web page loading test on one or several URL’s, using the phone
Webview component. It monitors the time needed to load a webpage.
 Video Streaming
It launches a video test on a YouTube video. It monitors the different states of
the video and QoE indicators including number of stalls (rebufferings), time to
launch the video, time spent in stall (rebuffering) as well as the throughput in each
of these states.

 SSM | SILENT SCRIPT MONITORING
In this mode, the application is running in the background as a service. It performs tests
automatically, without any end-user action. This mode provides a pro-active and always-on
automated monitoring solution. Services, information and test scenarios are defined
remotely on the server side. The scenario administrator defines the number of tests
they want to execute and the time between each iteration of the test. The time
between tests can either be:
 Fixed to execute tests at regular time intervals
 Adapted to the current user speed, triggering tests more frequently as the
user speed increases.
 SLM| SILENT LIVE MODE
In this mode, the application is running in the background as a service. It monitors the real
customer experience as end-users live it. It records key information on a service as it is
being used. This mode provides information on the everyday usage of the end-user,
monitoring the quality of service in a real-life context.
For instance, when the end-user receives a call, all network and voice service
KPI’s such as but not limited to call duration, setup time, and call event (drop, fail) are
recorded and sent to the EQual One Server.
In addition, a customer experience survey can be displayed at the end of a
service session (voice, web browsing). Thus, it will provide an overview of the real customer
experience, on how your subscribers perceive the quality of your network services, in
addition to the technical data gathered with the KPI’s.
3.5.2 Mobile Agent Requirements
The EQual One mobile agent is available for Android and iOS.
 Android 4. 0. 3* and above
 OS 7 and above*

3.6 KPI COLLECTION
The DQA permanently monitors the mobile OS events. Here is a list of some data
gathered on Android:
 Changes in the radio stack (CI, LAC, MNC, MCC, BEARER, RSSI …)
 Changes of the phone battery status
 Applications running in foreground or background
 Wi-Fi usage
 GSM data usage
 Voice call events
 Incoming/outgoing messaging (SMS / MMS / Email)
The EQual One DQA uses the memory and CPU of the device to compute the results from
the KPI collection and decrease the weight of the data being transferred between the
device and the server. Depending on the mode (OCM, SSM, SLM), the KPI computation
time differs to have as little impact on the user experience as possible.
3.7 EQual One Server
The EQual One Server has been designed to be part of the SQM (Service Quality
Management) and CEM (Customer Experience Management) approach introducing the
customer experience and data device metrics within the global reporting system of the
Mobile Operator.
EQual One Server acts in two main capacities.
 Manage and pilot the fleet of DQA’s using Over-The-Air configuration.
 Provide comprehensive reports on the data collected by the DQA’s.
EQual One Modules
To provide the most value out of the data collected by the DQA, V3D has developed three
independent server modules that can best respond to the MNO’s use cases.

3.7.1 One Trend
Figure 19: One Trend Server
One Trend is a Business Intelligence module that provides insightful dashboards that
presents the evolution and trends over time of the main KPI’s, with advanced
breakdown capabilities allowing for a multi-axis analysis.
One Trend is most relevant to LOB managers, QoE teams and strategic analysts.
The main features of ONE Trend are:
o Configurable dashboards
Define dashboard with selected reports and time aggregation: day, week, month, and year.
o Pre-calculated reports
Reports are continuously calculated on large amount of agent measurements, available for
instant access.
o Trend evolution
KPI’s are presented over time to evaluate the trend at a glance.
o Easy analysis

Main KPI’s are compared to configurable thresholds, for easy evaluation against target.
Breakdown analysis on user-defined axis (Technology, Scenario, OS, Operators).
3.7.2 One Network
Figure 20: One Network Server.
One Network is a real time network analysis module that provides a complete toolset to
analyze in real time all of the agent measurements, with drill down and geo-mapping
capabilities, allowing for the investigation of issues correlated to the network inventory.
One Network is most relevant to network engineers, support teams and QoE/QoS
teams. One Network module is only available on a low deployment environment.
Over a thousand agents, this module is disabled and only the investigation tool remains
available.
The main features of One Network are:
o Comprehensive set of reports based on the DQA data

The reports are available per functional area (Voice, Data, Coverage, Video streaming) and
provide advanced multi-select filters and export capabilities.
o All-in-one investigation tool
The investigation tool allows for multidimensional investigation and advanced filtering
capabilities. Making extensive use of the network inventory (cell, azimuth, beam width,
distance to site) and the creation of personalized multi-layer maps
3.7.3 One Customer
Figure 21: One customer server
One Customer is a customer centric module that provides a comprehensive dashboard
focused on a single customer for residential or corporate customer support, customer
complaints management and issue investigation. One Customer is most relevant to customer
care and corporate support teams.
The main features of One Customer are:
o Comprehensive customer QoE dashboard
360° degrees view of the customer experience, widget based reporting, compare to
thresholds and targets, customer score.

o Ticket management tool
Allows a one or two-way communication with the customer on their reported issues.
o Investigation tool
All-in-one tool on for root cause investigation.
o Easy customer management
Grant or revoke licenses to customers. Send personalized messages.
3.8 One Admin
One Admin enables the configuration of Scenarios, the follow-up of Customers and
Licenses, the creation of Messages and Surveys.
3.8.1 Agent Configuration
 Scenarios: create scenarios, import/export scenarios. In each scenario, specific
settings can be added/modified by service (voice, data, application …) and operation
mode (OCM, SLM and SSM). For more information on how to use and configure
scenarios, please refer to paragraph Running a Scenario.
 Surveys: design, modify, consult and delete surveys. Manage the questions, their
answers, and the flow of the survey and save surveys as templates to be used in
Scenarios, or in a particular service or on the Time Based Questionnaire. The
Ticket feature also uses the Survey mechanism.
 Coupons: manage coupons. A coupon is a short code that can be entered on the
device to select a specific scenario. Once entered on the device, the DQA will be
automatically moved to the corresponding scenario by the server.
A. Customers
 Search: search customers using a wide variety of filters (operator, device, OS,
installation date…). A customer has a unique EQual One identifier, the DQA ID. In
normal mode, customers can also be identified by either their IMEI or MSISDN
(availability depending on the SIM). In Anonymous mode, this feature is not

available. From that search menu, it is also possible to move customers between
scenarios.
 Messages: communication module aimed towards anonymous users: select targeted
customers according to a set of criterions, write and send messages using the OS
notification system.
 Top 10 Customers: a report showing the 10 most active customers on the server.
B. Agents Management
 License Installation: install the encrypted license file on the server. To get a
license file, please contact V3D.
 Overview: provides comprehensive information on the number of the DQA licenses
with a drill down per OS. Helps to keep track of licenses.
 Agent Upgrades: allows administrators to manage, create and deploy new versions
of the DQA.

C. Solution Settings
 One Customer: manage settings for the One Customer module, such as the default
dashboard layout, categories of scenarios and thresholds.
 One Trend: manage settings for the One Trend module, the breakdown editor or
the map settings.
 Data Enrichment: manage the data enrichment that can be done on the server for
every measurement. A measurement can be enriched with two type of information:
 Customer enrichment: specific attributes attached to the customer that generated
the measurement o Cell ref enrichment: information coming from the cell ref
inventory, based on the CI and LAC values of the measurement
 Misc.: a set of options for the server, such as North Bound Interface (NBI)
configuration or email alerts.

3.8.2 Running a Scenario
A. Design a Scenario
In a scenario, the administrator defines which services are activated on the device, in
which service mode (OCM, SLM, SSM) and the settings for each of those services.
The configuration of the scenario really drives the behaviour of the DQA and it has a
serious impact on the end user experience of their device. A scenario with very few
services activated and a sparse measurement frequency will have little to no impact on the
device and will fit a massive deployment scenario. On the other side, an aggressive
scenario with many services activated and a high measurement frequency will gather a lot
of data and is more fitted to a customer care investigation, but its impact on the device
will be more drastic (rapidly draining battery, high CPU usage).
In this step, the creation of a measurement scenario and all the required settings will be
explained. The following steps are required: - Define a name, a description, the global
settings (configuration URL, log activation, roaming activation…), - Define the scenario
transitions (based on date, duration or location), - Activate and configure the services
required in the scenario.
Before launching a scenario to real customers or to a mass deployment, it is advised to
follow the following process to check the scenario configuration:
1. Check the availability of the DQA’s at the correct URL for each Operating System.
Make sure the latest version of the DQA is deployed.
2. Create a new scenario from scratch. Configure the global settings, the activated
services and their settings.
3. Check if the DQA behaves accordingly to the settings defined in the scenario, on each
service and on each device if possible.
4. If all is correct, deploy the scenario to the target customers
Note that scenarios can be imported and exported for easy transfer over different
servers or duplication of scenarios.

Figure 22: Dimensioning scenarios
B. Deploy & Capture
As a user starts the application for the first time, they will be placed in the default
scenario. If they have a coupon, they may input it at this stage.
The server is always configured with a default scenario. The default scenario is the one
that new DQA’s connecting for the first time will receive after validation of their license.
To route new users to a specific scenario, the server administrator can create coupons.
These are short codes that the user can enter on their DQA and that will move the
customer to a specified scenario.
A customer can be moved between scenarios. This can be done from the One Customer
module or in One Admin. The process can be manual and applied to one or several
customers, or it can occur automatically using scenario transitions

It is possible to define transitions between scenarios. A transition will occur either after
a pre-defined duration, at a specific date or based on the customer location. All those
options are defined in the settings of the scenario.
Transitions have been designed to prevent a user to remain indefinitely in a very
demanding care scenario that could degrade the user experience of their device. Using
transitions, the customer will automatically be switched after a pre-defined duration,
typically a few days, the duration necessary to gather enough measurements for an
investigation.
It is also possible to transition users at a specific date. This can be useful to gather data
during a fixed period of time and automatically stop the collect after a specific date.
Finally, customers can transition between scenarios based on the device location. This
allows for instance the targeted monitoring of pre-defined locations (e.g. a city or a
region).
The transitions can also have license rules attached (e.g. grant/revoke a license to the
customer at the time of the transition).
Activity periods; It is possible to define periods of time during which the agents are
allowed to run. The activity periods can be defined per slots of 1 hour minimum for each
day of the week. For instance, it is possible to activate the agents only during the
weekdays, or define shorter periods of activity during the weekend.
3.8.3 Dashboard & Reports
EQual One uses a set of dashboards and dynamic reports to display the results of the data
collection on the devices. The frontend is web-based, with a simple but effective layout
supported by Ajax, to create a responsive web application working well across platforms.
Administrators can customize the layout or use the data export features to export the
reports in the format best suited for the business.
 Reports

The EQual One reports consist of tables, charts or maps displaying the results of the data
collection by the DQA in a comprehensive and interactive way. The results can be filtered
for deeper analysis and drill-down into the data.
The server stores all the collected KPI’s for a year by default (up
to 3 year on request and server load capabilities) and the raw data for a period of 3
months.
On the EQual One server, each report provides a tooltip that leads to a complete
description of the report.
 Charts
The charts displayed in EQual One are drawn in SVG (Scalable Vector Graphics). The
library used for drawing charts is Highcharts.
Figure 23: Chart Showing Distribution of Voice Call
Highcharts is a library written in pure JavaScript, offering an easy way of creating
interactive charts. Highcharts currently supports line, spline, area, area spline, column,
bar, pie and scatter chart types. It works in all modern browsers including the iPhone/iPad

and Internet Explorer from version 6. Standard browsers use SVG for the graphics
rendering. In legacy Internet Explorer graphics are drawn using VML.
SVG is a mark-up language for describing two-dimensional graphics applications and images,
and a set of related graphics script interfaces. The chart object is an object representing
a single chart in the web page. The Series object is the representation of each line, area
series, pie etc. A chart can have from 0 axes (pie chart) to
multiples. In a normal, single series Cartesian chart, there is one X-axis and one Y-axis.
The legend is a box containing a symbol and name for each series item or point item in the
chart.
 Maps
The measurements can be displayed on a map if the location of the handset is active. In
case the location is not active, the agent collects automatically some radio measurements
(Cell ID/LAC/Mobile Network Code/Mobile Country Code).
These measurements will be display only if the network inventory has been integrated into
the system, in this case, the measurement is place at the cell location.

Figure 24: Map showing mobile agents of EQual One
3.9 EQUAL ONE SERVER ARCHITECTURE
The EQual One server provides a rich featured web application with reporting and
dashboard functionalities. It is 100% plug-in free with the highest usability levels and
maximum customization capabilities.
The architecture is based on open standards such as Apache, MySQL, Perl, PHP and HTML.
It leverages Ajax and Web 2.0 technologies to provide lightning speed screens and
information loading. The architecture uses Hazelcast and Elastic Search to provide the
necessary horizontal scalability to support large volumes of data processing and storing.
The EQual One server is pre-configured with common functionalities (user management,
multi languages support, logging activities) while coming with pre-defined dashboard and
reports.

The EQual One server is based on the Drupal CMS platform.
3.9.1 System Overview
Figure 25: EQual One Server Architecture
The EQual One server solution is based on a three-tier architecture:
 Webserver: this layer exposes the web services required to communicate
with the DQA’s as well as hosting the front-end for the EQual One server
users. It is using Apache and Drupal.
 Mediation: this layer is responsible for the processing and indexing of the
data collected by the agents. It is based on Elastic Search and Hazelcast.

 Database: this layer is responsible for storing all of the standard ORM data.
Any measurements such as services KPIs or raw data information are directly sent through
HTTP or HTTPS to the mediation layer.
3.9.2 Requirements
One of the following OS is recommended:
 Linux server RedHat (third party licence is not included in the product)
 Linux Debian

GENERAL CONCLUSION
GENERAL CONCLUSION

I. Reminder of the Problem Statement
Our goal throughout this pre-engineering internship was to develop a dash board for
OCM SMC Monitoring. This dash board has the following function.
 Ease the monitoring of personnel’s who intervene in ticket creation.
 Enable the monitoring of defective products and services.
 Enable the monitoring of all activated EDS.
 Permits us to know the time taken to successfully resolve a fault.
Also, the EQual One robot which is to be installed in the MS of a subscriber seeks to:
 Get the time needed to effectively download a webpage and video.
 Enable the testing of voice quality during calls.
 Get the Call Success rate and details on missed calls.
In order to achieve our goal, a solution was put in place based on well-known concepts
and well adapted towards the deliverables and the functional needs of the tool.
II. A Summary of the Solution put in Place
Our dash board which was implemented and put in place had the following advantages
 Saves time require to study an extracted excel file having information of ticket
creation.
 Serve as a platform to treat subsequent extracted files having the same format.
 It displays concrete and easy to comprehend solutions.
The EQual One mobile robot is not executable as of now in Cameroon.

III. Difficulties Encountered
Throughout this project, I faced a lot of difficulties in coming out with adequate
expression in QlikView. Also, the database could not be accessed directly by QlikView;
thus there was the need for manual importation of the file into QlikView.
In addition, downloading the mails containing the extracted file was not evident;
reasons being that there were a lot of security constraints in downloading mails from the
internal address.
Bibliography
apache php web application. August 2016.
www. qlikview.com
www.wikiocm.orange.cm
loading a file in php - Recherche Google. march 2015.
https://www.google.com/search?q=loading+a+file+in+php&ie=utf-8&oe=utf-
8#q=uploading+a+document+to+a+specific+folder+in+php (accessed August 2016).
Organigrammes OCM. Yaounde, August 2015.
EGBENCHONG Joseph Ayuk. "CONCEPTION AND REALIZATION OF A TOOL TO HELP IN THE
FOLLOW UP OF THE DAILY ACTIVITIES OF TECHNICIANS: THE CASE OF ORANGE CAMEROUN
S.A" REPORT OF END OF PRE-ENGINEERING INTERNSHIP
4th
Year Telecommunications Engineering, yaounde, 2015.

pre_engineer

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (7)

Similar to pre_engineer

Similar to pre_engineer (20)

pre_engineer