Design of Applicative Quality Testing System for Data Services in Mobile Networks Toni Janevski Aleksandar Tudzarov Pero Latkoski Marko Porjazoski Ilija Efnushev Gjorgji Madzarov Dejan Gjorgjiev University “Sv. Kiril i Metodij” Faculty of Electrical Engineering and Information Technologies Karpos 2 bb, 1000 Skopje, Macedonia Email:
[email protected] Abstract Mobile operators nowadays have plenty of data services and this number is increasing towards future 3G LTE mobile networks. There are IP-based services which were migrated from wired to mobile networks, such as HTTP, FTP and E-mail. But, also mobile specific services were created such as WAP and MMS. On the other side, behavior of mobile services is influenced from the environment, the terrain, interference, from protocols on different OSI layers, from user behavior, etc. Therefore, mobile operators need to examine their network and be assured that services are performing well. In this paper we describe an applicative solution for Service Quality Testing System (SQTS), which provides efficient way for testing of all data services, including bearer as well as IPbased services in mobile networks from the user point of view, through a defined set of Key Performance Indicators. We define all SQTS functionalities as well as all needed networks nodes for its functioning. The proposed system is robust and scalable regarding definition of new services that will appear in future. Introduction GSM mobile networks have dominated the world since their introduction at beginning of the 1990s. Main service was circuit-switched voice, while data services were limited to SMS (Short Message Service) and dial-up modem connection with data rates as low as 9600 bits/s. On the other side, another technology was gaining momentum at the beginning of 1990s – the Internet technology, especially with the development of World Wide Web application. The dominant technologies on two different markets were destined to integrate in so-called 2.5G mobile networks introducing GPRS (General Packet Radio Service), which provided IP functionality over the same GSM radio access network. That paved the way for introduction of new services to mobile networks, which were dedicated to wired or at-least non-mobile networks,
services such as WWW (i.e. HTTP), FTP or electronic mail (e-mail), common for the Internet in the past several decades. Also, this integration of IP (Internet Protocol) and GSM inspired development of new services, which were mixing of ideas, services like WAP (Wireless Application Protocol) and MMS (Multimedia Messaging Service). Afterwards, EDGE (Enhanced Data rates for GSM Evolution) provided even higher bit rates than GSM/GPRS radio network by adding more efficient modulation schemes in the radio part. The battle for higher data rates in the mobile network continues with next generations of mobile networks i.e. 3G and its successors such as HSPA (High Speed Packet Access) and in future 3G LTE (Long Term Evolution). So, now we have mobile operators with plenty of data services. Packet-switched services in GSM/GPRS are mixed on the same physical resources (timeslots on radio frequencies) with traditional circuit switched services such as voice. Additionally, the behaviour of the mobile network is influenced from the environment, the terrain, interference from other cells in the network or from other wireless technologies, etc. Also, protocols on different OSI layers have their influence on the behaviour of the services. Therefore, mobile operators, which are also service providers at the same time nowadays, want to examine their networks and be assured that their networks are performing well. For that purpose there is a need of system that will do quality testing of data services [1-10]. To ensure that one has a system that does this in an appropriate way, one must ensure that the system is based on testing the right key performance indicators for relevant services. Such services may be popular services like WAP or MMS, Web or Email. In this paper we have described in details the SQTS (Service Quality Testing System). First, our goal is to define which key performance indicators are affecting the network’s performance at different network layers and for different services. Then, the goal is to provide algorithms for measurements of the parameters. Finally, there are
needed software applications and network elements that will perform such task. This paper is organized as follows. In the next section we discuss in general service quality testing in GPRS/EDGE mobile networks. In Section 3 is described the central SQTS server. SQTS database is subject in Section 4. We define SQTS user interface in Section 5. Probe Stations are described in Section 6. Section 7 discusses network architecture for the SQTS. Finally, Section 8 concludes the paper. GSM/GPRS/EDGE mobile network of T-mobile
GPRS/EDGE modem Probe-station service
Although all the measurements in SQTS are performed at the Probe Stations, for the purpose of measurement data processing, management of the Probe Stations, configuration settings, definitions of test cases, alarming, general configuration settings, and graphical and numerical presentation of the measured parameters, there are necessary the SQTS network elements listed above. Interactions among different SQTS network elements are shown in Figure 1. According to this, the central position in the SQTS architecture is SQTS server. It is a mediator between the Probe Stations, which are placed on different locations in the mobile network, and SQTS database.
D GE RS/E o r GP GSM onnection c
Read measurements Record configuration parameters into file
SQTS Server
SQTS Server application
Users of SQTS (human) Reports, configuration, administration, etc.
Read configuration paarmeters
Record measurements
SQTS Database
Read measurements Write/change configuration parameters
Test data collector module
Configuration updater module
Test cases scheduler module SQTS Server Application main software module
Remote control for Probe Stations module
SQTS Web application
Interface module to Probe Stations
Interface module to SQTS database
Figure 1: Interactions among different SQTS elements
SQTS architecture Key performance indicators, or simply KPI, are indicators which are particularly important for a services performance. First, one has to define the KPIs associated to a service, and then one has to determine how to measure the KPIs. In this paper we refer to KPIs in packet-switched mobile networks for bearer mobile services (GPRS/EDGE, USSD, SMS, CSD) and application services: MMS, WAP, HTTP (web), FTP, Email protocols (SMTP and POP3) and ICMP. Due to the size limit of the paper we will assume that KPIs are defined for all mentioned services, classified by: accessibility, retainability and quality (losses, delay, jitter and throughput). In the following part we define Service Quality Testing System (SQTS) which will provide service quality testing regarding KPIs associated with each service. The SQTS is consisted of the following system elements: SQTS server, SQTS database, SQTS user interface, and SQTS probe stations. Additionally, the SQTS for its functionality requires usage of commercial servers for different Internet based services: Web (HTTP), FTP and e-mail servers.
Figure 2: SQTS server software architecture
SQTS server The SQTS server is central server of the SQTS. In Figure 2 are shown main components of this server, which refer to main functionalities of the SQTS server. These are functionalities include, but are not limited to: •
Configuration changes (updates) to configuration files in Probe Stations
•
Definition and update of test cases (test case scheduling)
•
Management of Probe Stations (remote control)
• Collection of measurements results The SQTS server has two logical interfaces: one interface to Probe Stations, and second interface towards SQTS database. However, the machine that will host SQTS server needs only one physical interface (Ethernet network interface card) to the intranet IP backbone network of the mobile operator. Test case scheduler module periodically updates the file with test case definitions.
Remote control for the Probe Stations performs periodical control for each Probe Station whether the station is up and running, by using request/response on e given port over UDP/IP for the Probe Application and by using ICMP request/response for the Internet network interface card (on the side of the IP intranet). Configuration updater module updates configuration files at the Probe Station. This module reads the configuration data from the SQTS database, then connects to the Probe Station via the interface module and updates the confirmation settings kept into the Probe configuration file. Data Collector software module of the SQTS server is started after a given time period from the start of the SQTS server. Each Probe Station has its ID within the SQTS and all results from the measurements will be collected in Round-Robin fashion. Starting with the Probe Station with lowest ID (e.g. ID = 1), the Data Collector module of the SQTS server connects with the Probe Station using the interface module. If the connect is successful, then it first copies the log file with measurements results into a backup directory locally on the Probe Station machine. Then, it performs remote copy to a directory on the hard drive of SQTS server. It parses the data from the log file, row by row, and stores values of the measured parameters into appropriate data tables in the SQTS database. Then, Data collector module continues with next Probe Station (with the next ID) until it finishes with all Probe Stations in one Round-Robin cycle. In all activities of all software modules of the SQTS failure of the connection phase to any Probe Station will generate error record, which may trigger alarm. The alarm notification can be sent via email or via SMS to targeted employees. SQTS database structure All information about the SQTS shall be stored in a central database, the SQTS database. Hence, the SQTS database will store different types of information, such as: Configuration data for the SQTS network elements, Test cases for the Probe Stations, Schedules for test cases executions, Measurement data (per service), Error logs (per SQTS element), Statistical data, obtained from calculation of statistics over the measurements data, Information about users that can use SQTS system, user types, Alarm levels and thresholds, Alarming algorithm (when to send alarm indication and to whom), History of events (change of configuration settings or test cases). Besides for data storage, the SQTS database will perform much functionality, which is shown in Figure 3.
SQTS Database SQTS Configuration Module
Statistical Graphical User Interface
SQTS Error Reports CSD measurement data
Probe Station Information
SQTS System Users FTP measurement data
USSD measurement data
SQTS Alarming Module
Probe Stations Configuration Settings SQTS Statistics Processing
Interface to SQTS Server
SQTS History of Events
WAP measurement data
E-mail measurement data
SMS measurement data
Probe Stations Test Schedules PDP context measurement data
MMS measurement data
Probe Stations Test Case Definitions Module
HTTP measurement data
GPRS attach measurement data
Figure 3: SQTS Database structure
The functions of the SQTS Database will include, but are not limited to the following: • SQTS statistics processing for KPIs on different time scales: daily, monthly, and yearly statistics. • SQTS configuration module for management of configuration data regarding all network elements • SQTS test cases definitions database module • SQTS alarming module SQTS Statistics processing module consists of multiple modules for calculation of statistics per service. So, we will have in the SQTS Database statistics module for GPRS attach, for GPRS PDP context activation time, for SMS, for USSD bearer, for Circuit Switched Data, for application services specific for mobile environment i.e. WAP and MMS, as well as for IP-based data services HTTP, FTP, Email services and ICMP. The statistics will be calculated by defined jobs in the SQTS database for each day, each week, each month and each year. After calculation of the statistics, the results will be stored into SQTS Database. SQTS configuration module will be consisted of a set of database functions that will provide interface to the web-based SQTS Manager functionality for SQTS configuration parameters definitions and changing. The SQTS server will periodically retrieve the configuration data. SQTS test cases definition module will be consisted of database function that will provide interface to the webbased SQTS Manager functionality for SQTS test case
definitions. Because there will be separate test cases for each service and separate scheduling for each test case, there will be separate function per defined service.
shown in Figure 4. SQTS Probe Application
API for TCP/IP and UDP/IP protocol stack on Windows XP
Test cases definitions file
Configuration script for Probe Application
File for storage of results from test cases
Emulated WAP protocol stack
SQTS Probe Station WTP protocol module
HTTP client management module
POP3 client management module
SMTP client management module
WSP protocol module
Probe Application main module
WAP application module
Probe Application
FTP client management module
MMS client module
RS 232 Interface
GSM/GPRS/EDGE modem
GPRS attach module
PDP context management module
SMS module
USSD module
CSD module
RS 232 Interface software module for AT communication with GSM/GPRS/EDGE modem
Figure 5: Probe Application software structure
GSM/GRPS/EDGE mobile network
Figure 4: Components of the SQTS Probe Stations
User interface SQTS user interface will be web-based GUI (Graphical User Interface). The user will interact only with this user interface, which is referred to as SQTS manager. It will consist of web pages and applets that should complete the requirements for graphical presentation of all results from the SQTS measurements as well as for graphical interface for all settings in the system. Probe stations The Probe Station is an integral part of the SQTS system for the service quality testing in GPRS/EDGE mobile network. According to the architecture of the SQTS, which will be described in the next section, main measurements will be done by the Probe Station and particular software modules that will be developed and run on the PC (Personal Computers) that will act as Probe Stations. Organizational architecture of individual Probe Station is shown in Figure 4. Each Probe Station will be connected with GSM/GPRS/EDGE modem via RS232 interface. The Probe Application will use files stored locally on the hard disk of the Probe Station, which should store configuration settings for the Probe Application, Results from measurements according to defined test cases as well as test cases definition file with test schedule, as it is
The Probe Stations will have implemented protocol stack which is not included into an ordinary operating system neither into the GPRS modem. Such protocol stack is the WAP (Wireless Application Protocol) stack, which is used for accessing web content via WAP gateway of WAP content, but it is also used for MMS service. Each Probe Station will have its own Probe Application. Detailed software modules, which incorporate separate functionalities and/or protocols, are shown in Figure 5. According to the Figure 5, the Probe Application has two main external interfaces, one with GPRS/EDGE modem via RS232 standard interface, and second towards the OS and its Internet protocol stack. The latter software interface will be used also for access to the wired Internet connection of the Probe Station. In fact, every Probe Station will have at least two Internet physical Internet connections. One connection will be established via the GPRS/EDGE modem over the GPRS/EDGE IP-based network, and the second one will be established via the Network Interface Card for the Ethernet. Network architecture Finally, we discuss the SQTS network infrastructure i.e. how are connected and where are placed different network nodes that are needed for proper functioning of the SQTS. General architecture for testing Internet services, as well as terrestrial infrastructure of the GSM/GRPS network is given in Figure 6. In this scenario IP-based communication is established between a mobile node in mobile network and external web sites or FTP sites etc. The usual path of the information for data services (except
SMS, which is not IP-based and goes via MSC towards SMS Center) goes from mobile station via BTS, BSC, towards SGSN and GGSN. In such scenario there are different influences on the performance of the services from different legs of the transmission path, such as influence of the GSM/GPRS network, influence of the Internet data rates and congestion on the way towards final destination etc. In the case of SQTS the service quality testing refers to the GPRS/GSM/EDGE mobile network, which include radio mobile network and terrestrial mobile network. Therefore, SQTS should have the network architecture shown in Figure 6. The network architecture is consisted of several network nodes as it was stated at the beginning of this chapter: SQTS Manager, SQTS database, SQTS server and SQTS Probe Stations. For the purpose of SMS notifications from the SQTS database, firewall between SMS gateway and SQTS database should be set to allow SMS traffic between these two network elements. The SQTS network architecture provides possibility to use any number of Probe Stations connected to the SQTS DMZ as shown in Figure 6. Each location with a Probe Station shall have Ethernet LAN (Local Area Network) which will be connected via router and point-to-point connection to SQTS DMZ within the IP-backbone network of the mobile operator. The SQTS architecture is a robust one providing Probe Stations to perform measurements even in a case of interruption on the communication link between the Probe Station and SQTS DMZ. Such architecture provides SQTS to be robust to link failures and to continue working. Conclusion In this paper we have described an applicative solution for service quality testing in mobile networks. Why the issues regarding the service quality in mobile networks are important? Because one needs to know the potential performance degradation via measurements of the Key Performance Indicator for different data services that are used in the mobile network and hence needs system for quality testing of those services. For such purpose, in this paper we described the Service Quality Testing System (SQTS). The system will provide possibility for quality testing on different service types via KPI measurements: Radio Access Network (RAN) bearers, IP services, as well as Portal content and commercial services (such as pay per event services). The SQTS system provides management tool for presentation, statistical post-processing and analyses of the measurements data regarding the KPIs as well as associated parameters with the service and with the mobile
networks (Location Area, MSC, BSC, Service type, Postpaid, Prepaid, GPRS/EDGE etc.). Also, alarming system is very important, because automatic quality system testing provided by the SQTS should result in raising certain alarms when certain services show misbehavior.
Internet (corporate data)
DNS
Web-server
Internet (customer data, GPRS...)
Perimeter Firewall Perimeter router
DMZ
WAP Gateway
Sec. Zone
SMS O&M Firewall
SQTS Infrastructure Network
SQTS DMZ SQTS E-mail server
SQTS server SQTS FTP server
router
OpenSMS/SMS gateway SQTS Database SQTS Web server
router
router
switch
switch
SQTS Probe Station
SQTS Probe Station
Figure 6: SQTS network infrastructure
Finally, robust architecture and robust logical connection model between SQTS network elements is very important for successful functioning of the system for service quality testing. References [1]
[2]
[3]
[4]
R. Chakravorty, S. Banerjee, P. Rodriguez, J. Chesterfield, I. Pratt, “Performance Optimizations for Wireless Wide-area Networks: Comparative Study and Experimental Evaluation”, 2004. G.Gomez et al, “End-to-end Quality of Service over Cellular Networks”, England, John Wiley and Sons, 2005. Linderback, F., “PCRF Information Contributions to Service Assurance and Dimensioning”, Master’s thesis, Linkopings University, October 2006. Gozdecki, J., Jajszczyk, A., Stankiewicz, R., “Quality of Service Terminology in IP Networks”, IEEE Communications Magazine, March 2003.
[5]
[6]
[7]
P. Hakalin et. al., “Cellular Wireless Technologies in End-to-end Quality of Service over Cellular Networks”, Wiley, 2005, pp. 13-49. R. Sanchez, G. Gomez, P. Ameigeiras, J. Navarro and G. Ramos, “End-to-end Service Performance Analysis” in “End-to-end Quality of Service over Cellular Networks”, Wiley, 2005, pp. 139-185 K. Premkumar and A. Chockalingam, “Performance Analysis of RLC/MAC and LLC Layers in a GPRS Protocol Stack”, IEEE Transactions on Vehicular Technology, vol 53, NO. 5, September 2004.
[8]
[9]
[10]
R. Ludwig, A. Konrad, A. D. Joseph, R. H. Katz, “Optimizing the End-to-End Performance of Reliable Flows over Wireless Links,” Wireless Networks, vol. 8, No. 2-3, March-May 2002. 3G Partnership Project, 3GPP TS 27.007 v6.8.0, “AT command set for User Equipment”, March 2005. R. Sanchez, M. Martinez, S. Hierrezuelo, J. Guerrero and J. Torreblanca, “Service Performance Verification and Benchmarking” in “End-to-end Quality of Service over Cellular Networks”, England, Wiley, 2005, pp. 186-242.
