Design and Evaluation of a Mobile Management System

A Prototype design and Evaluation of Automatically collection of configuration data

Master of Science Thesis December 2005

Johan Wirn Telecommunication Systems Laboratory Royal Institute of Technology Stockholm, Sweden

Supervisor and examiner: Johan Montelius <jm@imit.kth.se> Principal: Patrik Bjrkander <patrik.bjorkander@ericsson.com> Advisors: Richard Persson <Richard.persson@ericsson.com>

Acknowledgements
This report is part of a Master of Science degree project conducted at the Telecommunication Systems Laboratory of the Royal Institute of Technology (KTH). The principal of the project has been the Network configuration & Integration unit (UG/I) at Ericsson in Kista. Ericsson specified the objectives of this project as part of the CCR-tool Used Case 2, and the work was conducted at Ericsson between June and December 2005. I would like to thank Ericsson for the opportunity of working with this project which has strengthen my confidence and throughout all the appreciation and comments Im sure that this will be a future coming product that Im pleased to have a part in. I would like to express my sincere gratitude to the following people who made this project possible: Johan Montelius, KTH, for his supervision and management during this project. Patrik Bjrkander, Ericsson, for giving me the opportunity to work with this project, great interest and support during the whole project. Richard Persson, Ericsson, for the supervision, support, knowledge and inspiration during the project. Roger Berg, Ericsson, for his interest and knowledge during the full duration of this project. Roger Dahln, Ericsson, for his support and great discussions regarding RSG. Mario Landreville, Ericsson Canada, for his help and supervision with the Ericsson SSG script. Mats Wrang, for his support, Visual Basic and database knowledge.

Johan Wirn December 2005

Abstract
The mobile telephone system is getting more and more services that have to been taken under considerations and together with the complexity within the system the demands is increasingly high on the support requirements of the network. The demand on network availability, quality and reliability are almost always close to 100 percent and applies to both the contents of the support and how fast it is delivered. The configuration of the network has to been taken out from the network to be able to solve the more complex problems that occur. The product experts of today are managing the handling of the configuration data of the system manually. This requires both time and knowledge on how to connect to the Operator to how the network is setup. During this final degree project, developments of a prototype for pointing out the possibilities of collecting the configurations from the network have been built. The prototype has then been used to evaluate and demonstrate important issues and possibilities related to the collection of configuration data. The second part of the project have been an evaluation of the possibilities on how to make the collection of the configuration data in an automatically way and collect the configuration to a centralised database.

Executive summary
There is a need for automatically collection of configuration data from the nodes within the mobile telephone system. The automatically collection and handling of configuration data from the Media gateway (MGw) has under this thesis project been taken under investigation. To prove the requested system functionality to handle the collect configuration, a Prototype has been build. The Prototype has proven that the necessary comparison of two selected configurations can be done and that it can be stored in such a way that users can select and browse stored configurations. There are 3 problems that have been taken under consideration. 1) Take out the configuration from the node. Is it or how will it be possible to take out the configuration from the node? 2) Automatically collection of the configuration data from the MGw How will we transport the configuration data out of the Operators network to our destination? 3) System design of storing and displaying collected data How will it be possible to compare two configurations, store them and displaying configuration data from the MGw?

Problem 2 SSG Problem 1 db.dat EGW

Data Base

Problem 3

Problem 1
How to take out the configuration has been solved in such a matter that there is a file located on the MGw that has to been taken out from the node through SFTP (Secure File Transport Protocol). The file is moved automatically throughout script to the SSG (Secure Support Gateway).

Problem 2
Automatically collection has been solved through a new but existing Ericsson system called Remote Support Gateway (RSG). Although this is primary used for remote access today this has been modified to include data transport of the configuration file from the MGw.

Problem 3
The potential of a system that will be able to store, display and compare different configurations from the MGw has been proven in a Prototype. Although the Prototype cant function and directly be a part of the whole automatically collection solution the Prototype shows the potential and pointing out that this functionality is really possible to build in a fullscaled solution. There is still however a lot of work that needs to be done before taken this to commercial use but the platform and the answers presented in this thesis is although a good investigation and answer lot of the questions regarding how and if this is possible to fulfill.

Conclusions
This thesis project has been an important step towards the realization of a system that will have the availability to automatically collect configuration data out of the Operator networks. This study has not only investigated if and how this will be possible it has also been proven with a Prototype that the collected information can be used for displaying and comparing different configurations. The project has also created a foundation for the upcoming system development and implementation process. Another important thing is the positive effects generated by this project. An example of this is the fact that the Prototype and the investigation has lead to that several important step has been taken towards the vision on automatically collecting data. For the technical side of the process of automatically collecting the configuration data this project has come to the conclusion that this could be implemented and there will not be any technically obstacle although all the services must be tested This thesis project has been an important step towards the realization of the automatically collecting process and the system developed during this project has pushed the decision process forward. The project has also created a foundation for the upcoming system development process to be able to automatically collect the configuration data from the nodes within the mobile telephone system.

Abbreviations
Explanation ACE-Server CLI DMZ ECGW ECN EGW FTP GUI IP ISDN MGw MMS RADM RDT RSG SFTP SMS SSG SSH TCP/IP UDP XML An Authentication Server from RSA Security Command Line Interface Demilitarized Zone Ericsson Corporate Gateway. Ericsson Corporate Network Ericsson Gateway File Transport Protocol Graphical User Interface Internet Protocol Integrated Service Digital Network Media Gateway Multimedia Messaging System Remote Administration Remote Data Transport Remote Support Gateway Secure file transfer protocol Short Message Service Secure Support Gateway Secure Shell Transport Control Protocol / Internet Protocol User Datagram Protocol Extensible Markup Language

Table of Contents
CHAPTER 1 INTRODUCTION ................................................................1 1.1 1.2 1.3 1.4 GENERAL OVERVIEW.........................................................................1 PROBLEM STATEMENT .......................................................................2 PARTICULARS OF THE PROJECT ..........................................................3 RELATED WORK .................................................................................3

CHAPTER 2 SYSTEM DESIGN OF REMOTE SUPPORT GATEWAY ..5 2.1 WHY REMOTE SUPPORT GATEWAY ....................................................5 2.2 THE FUNDAMENTALS OF REMOTE SUPPORT GATEWAY ......................6 2.2.1 Secure Support Gateway ............................................................6 2.2.2 Ericsson Gateway .......................................................................7 2.2.3 Remote Data Transfer ................................................................7 2.2.4 Remote Administration ...............................................................7 2.3 SECURITY ...........................................................................................8 2.3.1 Approved connection ..................................................................8 2.3.2 Firewall ......................................................................................8 2.3.3 IP security...................................................................................9 2.3.4 Secure Shell ..............................................................................10 CHAPTER 3 CONFIGURATION OF AUTOMATIC REMOTE COLL .11 3.1 THREE COLLECTION PHASES .............................................................11 3.2 COLLECT CONFIGURATION DATA FROM THE MGW ...........................12 3.3 TRANSPORT THE COLLECTED DATA FROM THE MGW........................13 3.3.1 Data Collection Scripts ............................................................13 3.3.2 The Configuration file(s) .........................................14 3.3.2.1 Example of the MGw configuration File .................18 3.3.2.2 Running the main script.........................................................19 3.3.2.3 The Shell Script......................................................................19 3.3.3 The SCRON file ........................................................................20 3.3.3.1 Example of the Scron file.......................................................20 3.4 REMOTE DATA TRANSFER CONFIGURATION .....................................21 3.4.1 RSGrdt user account.................................................................21 3.4.2 RADM user account..................................................................21 CHAPTER 4 THE PROTOTYPE ............................................................23 4.1 CONDITIONS .....................................................................................23 4.2 LAYOUT ............................................................................................24 4.2.1 Visual Basic ..............................................................................24 4.2.2 Browsing module ......................................................................25 4.2.3 Comparing module ...................................................................26 4.2.4 Uploading module ....................................................................28 4.3 SYSTEM DESIGN ...............................................................................29 4.3.1 The Database............................................................................30 4.3.2 The Polyhedra tool ...................................................................30

CHAPTER 5 CONCLUSIONS .................................................................31 5.1 THE VISION OF THE AUTOMATICALLY COLLECTION PROCESS ............31 5.2 SYSTEM DESIGN OF AUTOMATICALLY COLLECTION .........................32 5.3 THE PROTOTYPE ...............................................................................32 5.4 TECHNICAL CONCLUSIONS ................................................................32 5.5 FUTURE WORK ..................................................................................33 REFERENCES ........................................................................................34

10

Chapter 1 Introduction
1.1 General Overview
People have a need for mobility and have an on-line mentality that has driven the research and development for mobile phones system forward. Mobile telephone systems of today are all the time in an updating and upgrading mode and new features and services are requested and developed constantly [1]. The mobile telephone system will not longer only be used to setup a call between different subscribers it must handle all the services like call forwarding, voicemail, SMS, MMS, data traffic handling, billing, logging, authentication, encryption and many more services [2]. This complexity of todays mobile telephone- and datacom networks is putting increasingly high demands on the support requirements of such networks. The demands on network availability, quality and reliability are almost always close to 100 percent [1]. Each node in the mobile telephone system has a very specific role but because of the services it performs, partnership and interaction with other nodes within the system, the system itself becomes very complex and hard-to-grasp. Hard-to-grasp in a way that one or many changes can affect the overall performance in the system and the reason, that of cause is somewhere in the configuration of the system, can be hard to find. As pointed out the partnership and interaction between nodes within the mobile telephone system are affecting the overall performance but this will also affect the number of parameters within the node. For example there are 20-30.000 node specific parameters to set on a single Media Gateway (Node within the mobile telephone system) [4]. These parameters are not only specific for the Operator, they are specific for the node itself which means that if there are, let say 3 Media Gateways within the mobile system, there are 60-90.000 node specific parameters to set. This can be hard or even impossible to get an overview over even for the most advanced expert. Each mobile telephone system node has its own configuration and complexity and because of the interaction between the different nodes they can effect each other and in the end the overall performance of the network. Therefore there will be an extreme advantage to be able to go back and see how the configuration has change over time. Not only see the current configuration but to be able to get the perspective and compare different configurations [4].

1.2 Problem statement

Today there is no system that supports the availability for automatically collecting and comparing configuration data from nodes within the mobile telephone system. The outline is to investigate how to collect, store and compare configuration data from the node Media gateway. The assignment is divided in two parts. Investigate if and how there would be possible to create a system for automatically collection of configuration data with existing technologies, i.e. existing equipment at Operators system today. Create a prototype that compares and store collected configuration data.

The prototype will be configured in 4 parts: 1 - Interface An interface must be configured towards Polyhedra to be able to convert the Media Gateways (MGw) configuration information. 2 - Database All the configuration of the MGw shall be stored in a structured end easy manner. The database shall be easy to browse for Meta-data (i.e. nodenamn, hardware- and software type, country, operator etc). 3 - GUI/Browser functions Throughout a GUI or a CLI prompt it shall be possible to browse the database after given parameters with help of Meta-data. 4 - Report function A Comparison report that displays all the differences between two selected configuration files shall be generated. The report function shall not draw any conclusions.

1.3 Particulars of the project

The main goal for the investigation is to investigate how to automatically collect the configuration data out of the Operator network. The solution is aimed to work in today or tomorrows network solution of a general existing Operator. The investigation shall take in considerations new development issues of products/application to make such a system to work as described. The investigation shall point out the weakness that has to been taken under further investigation and shall not focus on the security part of the solution. It shall more develop a detailed theory on how automatically collection of configuration data can be solved [4]. The prototype function is to show the potential of collecting the configuration data from a node within the network. It shall show how the differences within configurations can be highlighted and in an easy way compared with each other [5]. It shall prove that it is possible to convert the configuration information, store it and display the differences in a report. This written report is the main part of the official examination at KTH and will also act as a reference guide for Ericsson employees. Throughout the time of this thesis at Ericsson there has also been a produced document for supporting this theory within Ericsson.

1.4 Related work

An investigation at the start showed that this hasnt been done within Ericsson before and no such project has to our knowledge been found that has the focus on automatically collection and building a Prototype. The most related work that has been found is the Ibase project within Ericsson that looks at the possibility to have a centralized database but there not aiming for the parameters or configuration information and most of all not for a automatically collection from the Operator network itself. As for future investigation the Ibase project can be integrated with this solution and act as the centralized database where configuration data collected from the Operator will be sent to and where the Prototype will collect the information for the comparison, browsing and report functions.

Chapter 2 System design of Remote Support Gateway

This chapter will describe the fundamentals of RSG (Remote Support Gateway). RSG is a system to get remote access to the Operators network in a secure and cost efficient way. The RSG system is therefore integrated in the solution of automatically collecting configuration information from the Media Gateway (MGw) within the Operator network.

2.1 Why Remote Support Gateway

Local engineers cant always solve the problem that occurs and a product expert from Ericsson is needed. To save time and without travelling around the world the Operator give the product expert a remote access to the network [6]. This is very common scenario but is it a secure connection to work with? With Internet and modern technology a secure remote access may not be the most difficult problem to solve but this easiness has also become a big security problem. What happens with the account and password that open up the remote access? Is the account terminated? Is there any limitation in the access to the network? How secure is the connection with standard modern technology, like a SSH client? Throughout a standardized secure communication where all remote access aspects has been taken cared off RSG (Remote Support Gateway) let the product expert access the Operators network without physically be there but in a secured and controlled way. The concept of RSG, as described, is remote connectivity but the Automatic Collecting procedure will use this system for getting the configuration files out of the Operators network.

2.2 The fundamentals of Remote Support Gateway

To get the requested configuration information from the MGw automatically collected an understanding of the fundamentals within the RSG (Remote Support Gateway) solution is needed. The automatically collecting procedure will not be able to change the fundamentals of RSG, just ad functionality and the way they handle the work procedure involved. The fundamentals are showed in the picture below as devices of the RSG solution.

The nodes within the RSG solution. On the left the Ericsson NW and to the right the Operator NW. IPSec is protecting the communication over the unsecured channel.

2.2.1 Secure Support Gateway

The Secure Support Gateway (SSG) is an Ericsson product that is used for secure connectivity from the Operator towards the rest of the world. It can for example be the endpoint for the subscribers GPRS/UMTS traffic (APN-session) toward the Internet or be used for remote connectivity [7]. Within the RSG solution the SSG is used for remote connectivity and for collecting data from the different network nodes of the Operator network. The data is then stored on the SSG until the data is requested and transported to the RDT (Remote Data Transport). The data is collected in a way specified in the data collection script (See chapter 3.1.1, Data Collection Scripts). All collected data will be stored on the SSG until the data is initiated and transferred by the RDT (Remote Data Transfer). All access from Ericsson must although be approved by the Operator and all access rights must be configured in the SSG. Authentication on the SSG is always using static passwords as default but one-time password systems can also be implemented. For security the communication is build up with IPSec and SSH. 6

2.2.2 Ericsson Gateway

The EGW (Ericsson Gateway) together with an appropriate router is the end point of the Ericsson network towards the Operator network. EGW act as a gateway towards one or several customers, which makes it easy for local and global support to assist Ericsson customers in a fast and efficient way. The connection between Ericsson and the Operator is highly protected throw IPSec and SSH and can be established over Internet, ISDN, Leased line, Frame Relay etc. The authentication is based on RSA SecurID onetime passwords, which is a strong protection against spoofing [8]. The EGW can either be a locally installed EGW or using a central EGW called ECGW, Ericsson Corporate gateway. A local EGW is installed by the local company while the central EGW (ECGW) is installed at central sites in the Ericsson Corporate Network (ECN).

2.2.3 Remote Data Transfer

The RDT (Remote Data Transfer) is used for automatic transfer of data and must be enabled in the SSG. The RDT initiate the transfer of defined data from the operator side (SSG) to the Ericsson server. After data has been transferred to the RDT, the receiver of this data can be any defined server or database on the Ericsson side.

2.2.4 Remote Administration

To be able to distribute security patches and software updates to all the RSG nodes the system uses the RADM (Remote Administration) node. The node distribute the necessary software updates when there is one available and is also used to push out the Data collection script to the SSG. RADM can also perform services like central backup, central log storage and collecting node contact information.

2.3 Security
In a security concept, one of the keys of RSG is to protect both the Operator and the Ericsson network. One vital part for achieving this is by handling the user authentication and authorization at both ends. The security aspect involves advanced authentication configuration through ACE-server and one-time password. [8]

2.3.1 Approved connection

Both Ericsson and the operator will have an approved and secure connection between each other. This connection will involve both parties in the decision because they both need to configure a proper users authentication and authorization in there system. This will keep both sides involved in the decision process. Every remote access connection has a specific owner, which ensures that there is someone responsible for each connection. One connection can be provided full access to several nodes in the operator network while other could be restricted to only access a certain TCP-port for a specific IPaddress within a specific time span.

2.3.2 Firewall
The RSG concept is built with enough security for a stand-alone installation. However, in almost all cases an existing firewall infrastructure is in place at the Operator side, and the RSG nodes could then be installed into the existing DMZ network with the following rules applied in the Operator Firewall [1]: ESP (IP Encapsulating Security Payload) for IPSec (protocol 50) UDP port 500 for IPSec ICMP 0, Internet control message protocol for echo reply ICMP 8, Internet control message protocol for echo ICMP 3, Internet control message protocol for destination unreachable

The below picture shows the solution where there is no DMZ firewalls existing. The SSG itself act as a fully configurable secure firewall, which makes the connection into the network safe. To protect the communication over the unsecured network the traffic is encapsulated inside IPSec (IP security) and SSH (Secure Shell).

Picture shows the RSG solution without an existing DMZ. The traffic is encapsulated inside IPSec and SSH.

2.3.3 IP security
IPSec (IP security) is a standard for securing IP communications and is used for securing the communications by encrypting and authenticating all IP packets. IPSec provides security at the OSI 3rd layer, network layer, and is in the RSG solution used to construct a Virtual Private Networks (VPN) tunnel between the Operator and Ericsson over the unsecured network. RSG is also always used together with SSH (Secure Shell) for secure login and file transport of the configuration data. IPSec is a set of cryptographic protocols for securing packet flows and key exchange. For securing packets there are two different types of protection or techniques. One, and the one that RSG is used, is the Encapsulating Security Payload (ESP) that provides authentication, data confidentiality and message integrity. The second, Authentication Header (AH) provides authentication and message integrity, but does not offer confidentiality. Originally AH was only used for integrity and ESP was used only for encryption. The authentication functionality was added subsequently to ESP [9]. The IPSec protocol protects the IP packet on a lower level than other Internet security protocols in widespread use, such as SSL and TLS. These operate from the transport layer up (OSI layers 4 - 7). This makes IPSec more flexible, as it can be used for protecting both TCP and UDP-based protocols, but increases its complexity and processing overhead, as it cant rely on TCP to manage reliability and fragmentation. IPSec was intended to provide either tunnel mode, portal-to-portal communications security, in which security of packet traffic is provided to several machines (even to whole LANs) by a single node, or in transport mode. Transport mode secure the end-to-end security of packet traffic in which the end-point computers do the security processing [9]. Both the tunnel and the transport mode can be used to construct Virtual Private Networks (VPN) and RSG is not depending on which mode to use however the tunnel mode is the dominated one. Note however, that the security implications are quite different between the two operational modes.

2.3.4 Secure Shell

As definition, the Secure Shell (SSH) is both a computer program and an associated network protocol designed for logging into and executing commands on a networked computer. The designers of SSH aimed to replace the earlier rlogin, TELNET and rsh protocols to develop a protocol that provides secure encrypted communications between two untrusted hosts over an insecure network [10]. To provide a secure transport of the configuration files out from the Operator the SSH is used for tunneling and for transfer files using the associated SFTP (Secure File Transfer Protocol).

10

Chapter 3 Configuration of Automatic Remote Collection

This chapter is describing how to configure the RSG (Remote Support Gateway) system to achieve an automatically remote collection of configuration data from the MGw (Media Gateway). To be able to automatically collect the required data through the RSG solution we must first make sure that the operator are using the fundamental devices that are described in previous chapter (Chapter 2).

3.1 Three collection phases

For the collection of the configuration file there are several steps to take under consideration. Each step is a step forward to be able to perform the automatic transport from the MGw to its destination. The collecting process is divided into to three phases. First we need to get the configuration file out of the node. This is described in the chapter 3.2, collecting configuration data from the MGw. Secondly, the configuration data must be transported internally from the MGw to the SSG where it will be stored. Explained in chapter 3.3, Transport the collected data from the MGw. The third part is to transport the configuration file to the destination in the Ericsson network. Initiated by the RDT the configuration file will be taken from the SSG to its destination inside the Ericsson network. Outlined in chapter 3.4, Remote Data Transfer configuration.

11

3.2 Collect configuration data from the MGw

To be able to collect the configuration data from the operators MGw the first step is that there must be a way to get the configuration out of the node. This is although not an easy task because there is no command or readable file consisting of this information on the node. There is although within the MGw a crash-dump that is manually created every time that the configuration is changed. The file is named db.dat and is stored on the node at D:\configuration\cv\db.dat [4]. This file will although not be readable in its format and to be able to get the information out of the db.dat-file a converting tool must be used, Polyhedra. After a complex way of converting and processing the Prototype will take out the information requested in a readable format. To be able to take out the latest configuration setup of the MGw a script has to be configured and stored on the MGw to periodically and automatically create a new db.dat file. This will be done with help of a Cron job. (Cron job is a definition for crontab commands used for scheduling commands to be executed periodically. The crontab uses the crond daemon found in Unix or Unix-like operating systems.)

12

3.3 Transport the collected data from the MGw

For the second part, to collect the configuration data internally from the MGw to the SSG there is a collection of script on the SSG that will describe the collection procedure. These scripts are called Data collection Script and specify how to collect, what to collect and when to automatically collect the configuration data.

3.3.1 Data Collection Scripts

Data collection script is a package of scripts that has been written in Perl. They will have the task of collecting the configuration data from the MGw periodically and specifies what to collect. The package is distributed through the RADM via a patch packaged for the SSG node. The patch installs the scripts under an organized environment that contains of the following directories located in /usr/local/nidc [1]. bin perl lib sql Contains the Shell script to invoke data collection. Contains the main module. Contains the data collection library modules. Contains the predefined SQL query for the data collection to Sybase SQL Server.

The following directories are created in /var/rdt/nidc. tmp Used as a temporary location during the execution of the data collection script. etc Contains the configuration file(s). log Contains the log file. transfer Contains sub-directories and is used as temporary location for collected data. The package is included a whole environment for taking care of the internal transport of the data to the SSG. Because this environment will act automatically and with no interference of the human factor the whole environment is controlled by the script scron. Scron define when to start the collection procedure this can be seen as a chain reaction: The Scron calls the Shell script with the proper configuration file. Within the configuration file there will be a set of Operator and node specific parameters that defines how and what to collect within the network. The Shell script calls the main script that is a standardized perl script that takes care of the transport defined in the configuration
file.

Configuration file will include the information - How and

What
Scron script will contain the information - When

This script will be explained in details in chapter 3.3.2, The Configuration file(s) and chapter 3.3.3, The Scron file.

13

To automatically collect the requested data (db.dat) from the MGw and transport it to the SSG the Data Collection Scripts connects the MGw using FTP. In this case it is suitable because we want to collect a file and have access to a FTP-server on MGw. Except from the fact that we are using FTP for the transport there are otherwise three different types of protocols to choose from: TELNET, FTP and SYBASE. Each protocol is identified in the collection type of the configuration file. FTP Collects date using file transfer protocol by transferring files. Collects data using a Sybase client for direct connectivity to SQL server by sending queries. Collects data using TELNET

SYBASE

PRINTOUT

3.3.2 The Configuration file(s)

To be able to get the preferred data from the MGw two things has to been taken under consideration. What will be collected from the MGw and how will it be collected. The configuration file includes the specific Operator data for this automatically collection and will be used by the main perl script to collect the required data. There can be several configuration file depending on, if data shall be taken out from other nodes or if different data shall be taken out within different timeframes from the same node. The configuration file has mainly 5 sections. Each section is composed of a list of properties regarding to that section. The 5 sections of a configuration are: Site info Data Collection Logger Network element Collection type

Within each section a list of properties are declared. The property is composed of a section name, followed by an attribute. A dot is used as a separator for each word and last a value of the attribute is set. Example: siteInfo.country = Canada.

14

Of cause this properties could have entered directly into the main script but to have a flexible environment, and the fact that it would be a proper way to in the future reuse this for contact with other nodes within the operator network, the need to have this entries separated from the main script is obvious. The configuration file will then be used by the main script to identify node and operator specific properties for the automatically collection. Site info The first section of the configuration file is called site info. This section is used to describe the market and all the information regarding to this. The siteInfo is very Operator specific.
Property SiteInfo.operator Description

siteInfo.market siteInfo.systemName SiteInfo.country siteInfo.countryCode SiteInfo.market_id SiteInfo.region

String that identifies the operator name. String that identifies the market name String that identifies the system name (UMTS, GSM) Identify the country Characters string that identifies the country code String that identifies the market id. String that identifies the region.

Data Collection The data collection section is used to indicate different directory locations, script version, etc.
Property dataCollection.workingDir Description Directory location that identifies the root directory of the data collection. Default: /usr/local/rdt/nidc Directory location that identifies the temporary directory. This directory shall be used only by data collection. Default : /var/rtd/nidc/tmp Directory location that identifies the directory location for the collected files Identify the version of data collection package Debug flag. Default: 0. Can be one of the following: MSC, RXI, RNC, RANOS, GSN, HLR or MGW.

dataCollection.tmpDir

dataCollection.destinationDir dataCollection.version DataCollection.debug DataCollection.networkElementType . .

15

Logger The logger section is used to define the log property required by the logger module.
Property log.filename log.path log.rootLogger log.mode log.size Description String that identifies the name of the log file Directory location that identifies the path of the log file String that represents the logger properties String to Identify the mode. Default: append Digits string to indicate the size in bytes.

Network Element The network element section is used to identify which network element to collect information from. This structure is repetitive, that means that one or many network element can be identified. It has one index to guarantee that each network element will be unique. Therefore, each property of a network element is starting with the identifier NetworkElement followed by an index of the network element to guarantee the uniqueness. Example: NetworkElement.0.NodeName = MGw1 Its also possible to set more than one collection for a same network element. Therefore, the collection attributes are followed by an index. See the example below: NetworkElement.0.CollectionType.0 The properties bellows are required by each network element.
Property NetworkElement.(index).nodeName NetworkElement.(index).nodeType NetworkElement.(Index).ipAddress NetworkElement.(index).url NetworkElement.(index).bdd Description String that identifies the network element String that identifies the node type String that identifies the ip address String that identifies the url String that identifies the database name Digits string that identifies y the SYBASE NetworkElement.(index).sybasePort port. String that identifies the node standard. NetworkElement.(index).nodeStandard Accepted values are : tdma, gsm, umts. Digit string that indicate the NetworkElement.(index).nbCollection number of collections String that identifies collection type. Accepted values are: NetworkElement.(index)..collectionType.(index) FTP, PRINTOUT, SYBASE String that identifies the collection mode. There are 2 NetworkElement.(index).collectionMode.(index) modes. CURRENT or DAY_BEFORE. String that identifies the NetworkElement.(Index).collectionVersion.(index) collection version.

16

NetworkElement.(index).userName.(index)

NetworkElement.(index).userName.(index) NetworkElement.(index).receivers.(index)

String that identifies the user name identification for a particular collection String that identifies the password identification for a particular collection String that identifies the file receivers

Collection Type The collection type section is used to define the properties of a particular collection. For example, it identifies, in case of FTP, which file to retrieve and the directory where it will be located. The property of a collection type is composed of a collection type identifier followed by a collection type version followed by the attribute name identifies each collection type property. For example: FTP.1.0.nbFile Except from the fact that we are using FTP for the transport there are otherwise three different types of protocols to choose from: TELNET, FTP and SYBASE. Each protocol is identified in the collection type of the configuration file. FTP SYBASE PRINTOUT Collects date using file transfer protocol by transferring files. Collects data using a Sybase client for direct connectivity to SQL server by sending queries. Collects data using TELNET

FTP Collection Type properties The FTP collection type is transferring files or/and an entire directory. It uses the File Transfer Protocol. The table below contains the properties required by the FTP collection type.
Property NbFile FileType Dir.(index) Filename(index) Description Digit String that indicate the number of iteration. (See Note) Character string that identifies the file type. For example, txt, log, xml. Directory location where to retrieve the file from. String that Identifies a file name. It can be an absolute name or a file mask where wildcard can be used.

Note: The nbFile property is the number of file name you can get within the same fetch. For example, you might want to retrieve different log files located in 2 different directories and have them in the same output file. Date Tag The filename can also include a date tag as <YYYY><MM><DD>. This tag will be replaced by a date. The date is determined by the collection mode of each collection type.

17

3.3.2.1 Example of the MGw configuration File

# site Information siteInfo.operator = operator1 siteInfo.market = SWEDEN_440001 siteInfo.siteName = STOCKHOLM siteInfo.systemName = UMTS siteInfo.countryCode = SE siteInfo.country = SWEDEN siteInfo.region = Europe siteInfo.market_id = 440001 # software general setting dataCollection.workingDir = /usr/local/rdt/nidc dataCollection.tmpDir = /var/rdt/nidc/tmp dataCollection.version = 1.00 dataCollection.debug = 1 dataCollection.email = dataCollection.diskSpace = 10000 # Logger log.filename = logfile.txt log.path = /usr/local/rdt/nidc/log log.rootLogger = INFO, LOGFILE log.mode = append log.size = 10000000 # 10 megs # Network Element Information NetworkElement.number = 2 NetworkElement.0.nodeName = MGW103_910008 NetworkElement.0.nodeType = MGW NetworkElement.0.ipAddress = 10.40.8.24 NetworkElement.0.url = NA NetworkElement.0.bdd = NA NetworkElement.0.sybasePort = NA NetworkElement.0.nodeStandard = NA NetworkElement.0.nbCollection = 1 NetworkElement.0.collectionMode.0 = CURRENT NetworkElement.0.collectionType.0 = FTP NetworkElement.0.collectionVersion.0 = 1.0 NetworkElement.0.userName.0 = mgw NetworkElement.0.password.0 = mgw NetworkElement.0.receivers.0 = prototype NetworkElement.1.nodeName = MGW201_910008 NetworkElement.1.nodeType = MGW NetworkElement.1.ipAddress = 10.40.97.2 NetworkElement.1.url = NA NetworkElement.1.bdd = NA NetworkElement.1.sybasePort = NA NetworkElement.1.nodeStandard = NA NetworkElement.1.nbCollection = 1 NetworkElement.1.collectionMode.0 = CURRENT NetworkElement.1.collectionType.0 = FTP NetworkElement.1.collectionVersion.0 = 1.0 NetworkElement.1.userName.0 = mgw NetworkElement.1.password.0 = mgw NetworkElement.1.receivers.0 = prototype

18

# Collection type Section. FTP.1.0.nbFile = 1 FTP.1.0.dir.0 = /d/configuring/cv/ FTP.1.0.fileName.0 = db.dat FTP.1.0.fileType = dat

3.3.2.2 Running the main script

The main script of the data collection is located in the /perl directory of the installation. The name of the file is dataCollection.pl and is evoked by the Shell script. The command line to call the data collection script is:
perl dataCollection.pl file name> h /usr/local/rdt/nidc c <configuration

The h argument is used to indicate the directory location of the installation. The c argument is used to indicate the file name (with no directory location) of configuration file to use. The script expects to find the file name in the /etc directory of the installation.

3.3.2.3 The Shell Script

The standard installation provides a shell script that calls the Perl interpreter with the appropriate agreements. The shell script also sets the required environment variable defined in the configuration file. The command line to call the shell script is: ./nidc.sh <configuration file name> The only argument required is the file name (with no directory location). The script expects to find the configuration file in /etc directory of the installation. The shell script is located in the bin directory of the installation.

19

3.3.3 The SCRON file

If the configuration file answer to the question What and How, the Scron file identifies when this collection shall take place and makes the collection start automatically. The command line within the Scron file (/usr/local/rdt/nidc/bin/nidc.sh mgw.conf) will invoke the shell script (described in above chapter) that needs the configuration file as an argument. The exact location of the shell script must be declared although this is not necessary for the configuration file, where only the name will be stated. The input of the Scron file consists of six fields, separated by blanks. They give a date and time for the collection. Example of a Scron file:
# minute hour day month dayofweek year command 0 0 * 11 * 2005 /usr/local/rdt/nidc/bin/nidc.sh mgw.conf

A minute, expressed as a number from 0 through 59. An hour, expressed as a number from 0 through 23. A day of the month, expressed as a number from 1 through 31. A month of the year, expressed as a number from 1 through 12. A day of the week, expressed as a number from 0 through 6 (with 0 standing for Sunday). A year, expressed as a number from year 2005 and forward Any of these fields may contain an asterisk * standing for all possible values. For example, if you have an * as the day of the month, the job runs every day of the month. A field can also contain a set of numbers separated by commas, or a range of numbers, with the first number followed by a minus sign - followed by the second number. Here are some examples. 00**** - Midnight every day 0 0 * * 1-5 * - Midnight every weekday 0 0 1,15 * * * - Midnight on 1st and 15th of each month 001*5* - Midnight on 1st of each month and every Friday Note: The Scron file's rows are similar to the crontab-syntax, but have some add on and differences. Empty lines are allowed, comments are allowed (# at beginning of line) and it has one extra field for year.

3.3.3.1 Example of the Scron file

# minute hour day month dayofweek year command 45 19 * * * * /usr/local/rdt/nidc/bin/nidc.sh mgw.conf 15 19 * * * * /usr/local/rdt/nidc/bin/nidc.sh mgw.conf 00 20 * * * * /usr/local/rdt/nidc/bin/nidc.sh mgw.conf

20

3.4 Remote Data Transfer configuration

The third and last step to make this automatically collection of the requested configuration file to its destination in the Ericsson network initiate the traffic between the SSG and the RDT. As part of the first to steps the configuration file is collected and stored on the SSG. To be able to initiate the traffic the RDT has to logon to both the EGW and the SSG. This is done by a user account RSGrdt.

3.4.1 RSGrdt user account

To be able to automatically transfer data from the Operators SSG to its destination within Ericsson this must be enabled in the SSG. The RDT is using a built-user account called RSGrdt. The user RSGrdt has limited rights and cant do anything else than collect data from a predefined directory within the SSG. This user account is created by the installation procedure and is by default deactivated.

3.4.2 RADM user account

The RADM stands for Remote Administration and is used for security and software updates. To be able to perform its task the RADM node requires a user account on the SSG, named RSGradm. This user is created by the installation procedure and is by default deactivated.

21

22

Chapter 4 The Prototype

This chapter will describe the Prototype in which the system design of storing, comparing and displaying the configuration of the MGw has been taken under consideration.

4.1 Conditions
There are different conditions involved building the prototype that will show the potential and benefits of collecting the configuration data. The prototype should not been seen as a application on how to display this information in the best user friendly way it shall more been seen as prove of how this information can be readable and used in help of solving and prevent problems. The prototype is structured from three different conditions The availability of storing configuration data, collected from the MGw. This will be presented in how the database is structured and how to make the collected configuration readable. A browsing functionality of the collected information and a GUI interface for presenting it to the user. The browsing information will be taken out of the database and include information to sort out different markets, i.e. Country, Operator etc. The last part is that there must be a way to compare different configurations to each other and the result will be presented in a report function. This will not only limit the user to compare different configurations from the same node. The user will also be able to compare different MGw and also different operators MGw.

The prototype will point out the availability on how to handle the configuration collected from the MGw. The prototype shall not be seen as an extension or part of the automatic remote collection. It will be a standalone application where uploading of new configuration data will be handled manually. The prototype itself will not make any decision or changes of the information in any way. That is up to an expert within the area to manually come to a conclusion based on the material presented by the prototype.

23

4.2 Layout
The layout of the Prototype is presented in a well-known format because of the choice off programming languish Visual Basic and will be based on three different modules. Browsing module Comparing module Upload module

The browsing module will take care of browsing the database out of information regarding to the choices the user makes on which markets that shall be displayed. Out of the choices the comparing module, compare the differences within the selected configurations and display them to the user. The differences can also be generated in a report for later use. Because of the chosen system design, the Prototype will act as a stand-alone application and the uploading of new data must be done manually throughout the uploading module. This module will ask the user several questions regarding the market associated to the new data. All this information will be placed in the database for use by the browsing module. Because of the chose of Visual Basic for the programming language the layout of the program is very familiar to the windows user. The tools for designing Visual Basic is a graphical tool and the visual effects are very fast developed and adjustable In fact this graphical design will affect the appearance of the program, because of the well-known designed, to be very professional.

4.2.1 Visual Basic

Visual Basic is a unique language in nearly all aspects and different interface, a different style, and a different method of doing things must be learned. A good understanding of the procedures and modular programming will be of use in learning Visual Basic. Unlike other languages, Visual Basic is completely graphically oriented and in great use of when the Windows processes can be taken benefits of [13]. Because that almost all the organisation within Ericsson uses windows as maybe not the preferred but the company selected OS to use for the employees the choice of Visual Basic was easy. Easy also because of my small experience of other languishes like Java and because of the easy way of building up a graphical interface in a short time. The major disadvantage of Visual Basic is that it will only work at Windows platforms. Visual Basic is although also a fun and practical language because all the slavery and hard work of coding is minimized with it's easy to use graphical interface. Its primary purpose is to create custom databases, but it is fully functional for creating other applications like games, modem terminals and many more. Almost any windows program can be created with Visual Basic, and it is to my opinion the easiest language out there for the power it has [14]. Because Visual Basic application will be executed on a windows terminal it has the advantage of reusing some of the settings for windows. For example it can reuse the colour settings and 24

the visual settings of the graphically interface so the executed program will be familiar to the user because it looks like all his other windows programs. With Visual Basic it will be easy to create a professional interface in just a few keystrokes.

4.2.2 Browsing module

The prototype is built on a platform called the main module. This is the framework of the program and if this module will be closed the Prototype it self is terminated. In the field of the main module the Browsing module is located.

Picture shows the Prototype with the browsing module activated. It is in a very well-known format for the Windows user.

With the browsing function the user have a selected way of sorting out different markets and also a way to just browse the database for information. The information showed in the GUI of the Prototype is filtered out from the database so only relevant information is showed. For example, if the user wants to see configuration data from just one country, operators within that country is showed and not operators located somewhere else. The main reason for the browsing function is to choose two configurations to compare. To do this the proper configuration has to be selected and chosen by the Add button. This will cause that the configuration data that has been chosen by its appearance in the Sites Added field of the screen.

25

4.2.3 Comparing module

To be able to comparing the configuration files (db.dat) collected, the Prototype must convert the db.dat file to 63 readable files. This is done in the Polyhedra tool and is explained in detail in chapter X, Throughout the browsing procedure, where two configurations have been chosen, the user will end up in the Comparing module after pressing the Compare button. The Comparing module will compare the different configurations to each other and present the differences within four new windows that will appear. The Result, Detailed information (3:2) and two windows showing the whole selected configuration files (3:1).

Picture of the comparison module within the Prototype.

In the Result window the result of the comparison, initiated by the user will be showed. Because of the conversion made by the Polyhedra tool there is now 63 different files regarding to each configuration that has to be compared to each other. The result is presented with the number of differences within each file. When selecting one of these 63 files showed in the Result window detailed information regarding to the differences in this file will end up in the detailed information window to the right. Here detailed information of differences within selected file will be showed. Further down the completed file will be showed for manually browsing. Within the comparing module you will also find the report function.

26

Report function The report function will in an easy way show the differences between the configurations and is consisting of an overviewed specification and a detailed list of all the differences between the two configurations. Within the report all the difference throughout the comparison in the Comparing module will be displayed.

Picture shows the Report function of the Prototype. An overview of number of differences is presented and below a more detailed specification on the differences.

The report function has turned out to be a very popular and the most satisfied function within the Prototype. This is because of the easy and functional way the differences between the configurations are presented. The user will without any effort have a good overview of the differences and wont have to go through all the 63 files manually, which is very time consuming. The report will also be able to print or stored for future use throughout the menu of the Prototype.

27

4.2.4 Uploading module

The Prototype is acting as a stand-alone application and the uploading module is there to be the module for the manually upload of new configurations (db.dat-files) to the database. To store the configurations correctly more information must be added to sort out questions regarding the belonging market of the configuration. Of cause help to point out where the configuration that has been taken out of the MGw in form of the db.dat-file is located. The Upload module can be found in the programs menu <File/Upload db.dat to DB>, or through the toolbar located at the top of the Prototype.

The Prototype and its Upload module. The user will add some market information associated with the configuration selected.

To upload new configurations to the database knowledge of the market is needed such as Country, Operator, Site, Node, Software version, Node type and Node configuration. This will be sorted out and placed in the database but not confirmed that the correct information has been added to the configuration. Although, one of the parameters is checked and that is because without the right Software version the converting tool, Polyhedra, will not be able to convert the information required and therefore the configuration cant be readable and therefore within no use. For further details please see next chapter 4.2, System Design.

28

4.3 System Design

The system design of the Prototype is showed in the below picture and is built on the platform of the MS Access database. There are basically two scenarios that the system designed is aimed to do, one is the browsing scenario where information is taken out of the database to be able to sort out what kind of configuration that is available in the database, this scenario is also including the Comparing module. The other is the manually upload scenario where the configuration, taken out of the MGw (db.dat-file), must be converted into a readable format through the Polyhedra tool.

Upload scenario

Browsing scenario
MS Access

Polyhedra

63 files

The browsing module of the Prototype has an interface towards the database to filter out the different choices made by the user. For example if the user selecting on the country Sweden only the operators placed in that country will be showed in the Prototype. This filtering and interface is forming the Browsing scenario. For more details regarding the browsing module please see chapter 4.1.2, Browsing module. To be able to show the configuration to the user of the Prototype the configuration has to be converted into 63 readable files [17]. The converting process made by the Polyhedra tool and the market information associated to the new configuration collected is forming the upload scenario.

29

4.3.1 The Database

The system design of the Prototype has its bas in a MS Access database. From the database the Prototype is able to present all the necessary information to the user. The information to show will be select by different parameters in the Browsing module within the so called main module of the Prototype. The user will then be able to select information in a efficient and scaleable way where the user are not stacked on just comparing the same MGw but to be able to see the differences between the MGws within the Operator and also the between Operators. The database MS Access is chosen because of the interaction with Visual Basic. The MS Access is also part of the license of the OS Windows Pro, which is the selected version to the employees within Ericsson. The design of the Prototype is although not depending on which database that is handling the information just as it follows the database design showed below.

The database design of the MS Access database. As showed the database is a relationship database with relations between the different tables.

4.3.2 The Polyhedra tool

The collected configuration is not readable in the form collected from the MGw but with help of the Polyhedra tool the Prototype will convert the collected configuration and store it in a readable way. Convert the information The configuration file collected (db.dat) must be converted into a readable format throughout converting it to 63 different configuration files, where each of the file is a part of the whole configuration of the database. These configuration file is in plain text and will also be the proper way when configure the node MGw. The converting tool that is used is Polyhedra that is developed by Enea AB to take care of big database dumps from a SQL database and to convert them to a readable format. 30

Chapter 5 Conclusions
During this thesis an evaluation of the automatically collection process and a designed of a Prototype for taking care of the collected data from the node Media Gateway has been done. This chapter concludes this thesis project by summarizing the most important insights gained.

5.1 The vision of the automatically collection process

The vision of the automatic collecting and the thought of having a centralized database within Ericsson that collects all the necessary configuration data from all the nodes within the network has come several steps closer with help of this project. With help of a centralized system that will be placed within Ericsson, the expert will have an easy and secure access to the data requested. Engineers can work on problems regardless of the time of day or location. The data will always be in the latest version because collecting will be periodically scheduled. With help of the Prototype several solutions, possibilities and benefits of comparing the configuration has been pointed out. The possibilities for saving time and work for the engineers with automatic collecting data in a centralized database will be just endless but to mention a few important ones. When upgrading nodes to see what has effect the configurations. Statistics, when taken out statistics on parameter level and look for how parameters will change over time or as feedback to R&D on parameters that never are changed. To prevent upcoming problem though looking for relations between configuration settings and problems that occur.

This thesis project has been an important step towards the realization of the automatically collecting process and the system developed during this project has pushed the decision process forward. The project has also created a foundation for the upcoming system development process to be able to automatically collect the configuration data from the nodes within the mobile telephone system.

31

5.2 System design of Automatically Collection

The general system of the Automatically Collection is basted on the Remote Support Gateway system that has been proved to be a secure system for remote access. The system has although also been proven to be a good concept for collecting configuration out of the networks. It can therefore be recommended to future automatically implementations. The use however with the automatically collection is depending on how the collecting information should been taken care of and displayed to the user.

5.3 The Prototype

This thesis project has been an important step towards the realization of a system that will have the availability to automatically collect configuration data out of the Operator networks. This study has not only investigated if and how this will be possible it has also been proven with a Prototype that the collected information can be used for displaying and comparing different configurations. The concept of building the prototype has been to evaluate the possibilities of comparing different configurations to each other and to work out a system for displaying them. The process has although involved the complexity of processing the configuration data to a readable format and store it. The project of the Prototype has created a foundation for the upcoming system development and implementation process. Another important thing is the positive effects generated by this project. An example of this is the fact that the Prototype has been the reason to that several important steps have been taken towards the vision on automatically collecting data.

5.4 Technical conclusions

For the technical side of the process of automatically collecting the configuration data, this project has come to the conclusion that this could be implemented and there will not be any technically obstacle although all the services must be tested. The system design of the Prototype can not as of today be implemented in an automatically collecting process but the Prototype has visualised the benefits of comparing the configurations and pointed out possibilities of automatically comparing the configurations. The system design should although with some modifications be able to be part of such system and automatically process configuration data incoming to a specific folder. This is although not in the scope of this Thesis and will be left to future works.

32

5.5 Future work

This thesis project has been an important step towards the realization of the automatically collecting process and the system developed during this project has pushed the decision process forward. The project has also created a foundation for the upcoming system development process to be able to automatically collect the configuration data from the nodes within the mobile telephone system. As part of this study there has only been one node, the Media Gateway, within focus when solving the automatic collection problem. As for later studies there will be of interest to look into how the presented automatically collection will act as a barrier for the rest of the nodes. How to take care of the collected configuration information from the MGw must also be further investigated. This can be done within the scope of making an XML-file out of the configuration and with parsing be able to convert all the parameters into the database. As for future investigation a closer look at the Ibase project within Ericsson, a project looking for how to store information within a centralized database, and how this can be integrated and act as the centralized database where configuration data automatically will be sent to and where applications like the Prototype can access data for further use must be investigated.

33

References
[1] Ericsson Internal Document (2004), RSG Product Description, 1551HSD 103 36 Uen Rev: F Ericsson Internal Document, Fred Erson (2005)- Performance data collection process, EAB/RN-04:0337, fred.erson@ericsson.com Ericsson Internal Document (2004) - SSG Administration Guide Release 3.2, 2/154 31-HSD 103 36 Rev: D Richard Persson, Ericsson Kista, Interview (November 2005), richard.person@ericsson.com Stefan Griph, RSG Product Manager, Stefan.Griph@ericsson.com Roger Dahlen, Ericsson Lule, RSG Support Discussions and interviews (October 2005), roger.dahlen@ericsson.com Mario Landreville, Ericsson Canada, SSG script handling and interviews (October 2005), mario.landreville@ericsson.com SecureID from RSA, ACE-servers are a system to provide strong authentication through RSA SecurID one-time passwords [www], www.rsasecurity.com, November 2005 N.Doraswamy, Dan Harkins (1999), IPSec The new security standard for Internet, Intranets, and Virutal Private Networks, ISBN 0-13-011898-2 Daniel J. Barrett, Richard E. Silverman, and Robert G. Byrnes SSH: The Secure Shell (The Definitive Guide), O'Reilly 2005 (2nd edition). ISBN 0-596-00895-3 Forouzan, B. (2003). TCP/IP Protocol Suite, 2nd Edition. McGraw-Hill. ISBN 0-07-296772-2. Forouzan, B. (2004). Data Communications and Networking, McGrawHill. ISBN 0-07-123241-9. Greg Perry (1999) - Lr dig Visual Basic 6 p 3 veckor, [versttning: Jerker Thorell] ISBN 91-636-0523-6 Torsten Jonsson (2002)- Visual Basic i fokus : grundlggande applikationsutveckling och programmering version 6. ISBN 91-44-02427-4: [2]

[3]

[4]

[5] [6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15] [16]

Jan Friberg (1992) - Visual BASIC: Handboken, ISBN 91-86201-28-1 Redmond, Wash.: Microsoft Press, cop. 1998 - Microsoft Visual Basic 6.0 programmer's guide. ISBN 1-57231-863-5 Enea AB (January 2005), Real-Time Relational Database Version 6.2.0 [www], www.polyhedra.com, November 2005 Enea AB (October 2005), SQL Client Version 6.2.0 [www], www.polyhedra.com, November 2005

[17]

[18]

35