Investigation and development of a verification protocol test tool for LTE

(1)

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Investigation and development of a verification

protocol test tool for LTE

by

Jolian Georgis

LIU-IDA/LITH-EX-G--10/024--SE

2010-11-07

(2)

(3)

Linköpings universitet

Institutionen för datavetenskap

Final thesis

Investigation and development of a

verification protocol test tool for LTE

by

Jolian Georgis

LIU-IDA/LITH-EX-G--10/024--SE

2010-11-07

Handledare: Rani Iskender, Solutions Verification Engineer, Ericsson AB Examinator: Peter Danelius, IDA, Linköpings universitet

(4)

(5)

Rapporttyp Report category __ Licentiatavhandling X Examensarbete __ C-uppsats __ D-uppsats __ Övrig rapport _ ________________ Språk Language __ Svenska/Swedish X Engelska/English Annat ________________ Antal sidor 25 Sammanfattning Abstract

This thesis was held at Ericsson in Linköping at IoDT test department as final year project, BSc IN COMPUTER ENGINEERING at Linköping University in Sweden. This thesis equals 15hp.

At Ericsson IoDT test department testing tools are used to control the traffics between the EU and the eNB to check the typical problems issues. By storing these problems in a log file will help mobile vendors to eliminate the mentioned problems by developing solutions for more significant products.

The IoDT needed to develop the testing results even further for more specific results. The purpose of this thesis is to developing the LogTool to make it easier for the IoDT testing group to read the log files, whereas the implemented results from the log files simplifies for the testing group.

To make this happens; the LogTool was developed by creating a new Analyzer that analyses the log file and presents the results in a way which makes it easier to be read. The Analyzer was created using Eclipce program as RCP plug-in, in Java programming language.

The new Analyzer managed to print the results in a simpler way for the CQI and MCS test.

Basically, the new Analyzer was created and implemented in standardized way that make it possible to be developed even further in the future without losing its’ functionality.

ISBN (Licentiatavhandling)

____________________________________________ _________

ISRN LIU-IDA/LITH-EX-G—10/024

_________________________________________________________________

Serietitel och serienummer ISSN (Licentiatavhandling)

Title of series, numbering ____________________________________

URL för elektronisk version

http://urn.kb.se/resolve?urn=urn:nbn:se:liu:div a-66946 Presentationsdatum 2011-10-29 Publiceringsdatum (elektronisk version) 2011-03-22 Titel Title

Investigation and development of a verification protocol test tool for LTE

Författare

Author Joian Georgis

Institution och avdelning

Department of Computer and Information Systems

Division of Artificial Intelligence

and Integrated Computer

(6)

(7)

På svenska

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/

In English

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

(8)

(9)

Abstract

This thesis was held at Ericsson in Linköping at IoDT test department as final year project, BSc IN COMPUTER ENGINEERING at Linköping University in Sweden. This thesis equals 15hp.

At Ericsson IoDT test department testing tools are used to control the traffics between the EU and the eNB to check the typical problems issues. By storing these problems in a log file will help mobile vendors to eliminate the mentioned problems by developing solutions for more significant products.

The IoDT needed to develop the testing results even further for more specific results. The purpose of this thesis is to developing the LogTool to make it easier for the IoDT testing group to read the log files, whereas the implemented results from the log files simplifies for the testing group.

To make this happens; the LogTool was developed by creating a new Analyzer that analyses the log file and presents the results in a way which makes it easier to be read. The Analyzer was created using Eclipce program as RCP plug-in, in Java programming language.

The new Analyzer managed to print the results in a simpler way for the CQI and MCS test.

Basically, the new Analyzer was created and implemented in standardized way that make it possible to be developed even further in the future without losing its’ functionality.

This procedure was achieved regarding the needed requirements of Ericsson and Linköping University. This document will guide the reader through the steps that used to accomplish the project with illustrating figures, methods and code examples in order to give a closer vision of the work.

(10)

(11)

Acknowledgements

I would like to thank everyone at Ericsson in Linköping, Sweden; especially my supervisors Rani Iskender and Ankur Sharma for their constant supports and guidance throughout the thesis work. And I would like to thank Jens Vevstad and Henrik Johansson for their help with the implementation of the new Analyzer. I would like to thank Salah Alazawi also for his acting as a supervisor when Rani and Ankur were not available.

In Addition, I would like to thank my examiner, Peter Danelius, and my opponent Remmy Rutaganda

Jolian Georgis Linköping 2010

(12)

(13)

Figure and tables

Figur 2.1 Overall Architecture... 4

Figur 2.2 S1 Interface architecture ... 5

Figur 2.3 X2 Interface User plane Figur 2.4 X2 Interface Control Plane ... 5

Figur 3.1 Scope of the Interoperability Testing at LTE ... 8

Figur 3.2 A test case for the physical channels ... 9

Figur 4.1 Japy parsing principles. ... 13

Figur 4.2 screen shot of LogTool. ... 14

(16)

(17)

Acronyms

3GPP Third Generation Partnership Project

CQI Channel Quality Indicator

eNB Evolved Universal Terrestrial Radio Access Network Node B

EPC Evolved Packet Core

E-UTRAN Evolved Universal Terrestrial Radio Access Network

FDD Frequency Division Duplexing

HSPA High Speed Packet Access

IoDT Interoperability Development Test

LTE Long Term Evolution

MCS Modulation and Coding Scheme

MIMO Multiple-Input Multiple-Output

MME Mobility Management Entity

OFDMA Orthogonal Frequency Division Multiple Access

PAPR Peak to Average Power Ratio

RAN Radio Access Network

RTT Round trip time

S1-U S1 User Plane Interface S1-MME

S1-MME S1 Control Plane Interface

S-GW Serving Gateway

SC-FDMA Single Carrier FDMA

TDD Time Division Duplex

UE User Equipment

PBCH Physical broadcast channel

PCFICH Physical control format indicator channel

PDCCH Physical downlink control channel

PDSCH Physical downlink shared channel

PHICH Physical hybrid-ARQ indicator channel

(18)

(19)

Chapter 1 Introduction

This thesis was performed in order to develop LogTool that will be used by IoDT testing group at Ericsson. LogTool is a tool used to capture the traffic between the UE and the eNB. It is also used to analyses the traffic or a log file and presents the result in a many way e.g. tables, pure text, graphs and in socket. The IoDT test is the last test scenario in the whole test process. The Tests are conducted for new updates and development for both Ericsson network and the mobile vendors in LTE.

Basically the IoDT testing performed their tests within the design phase with a selected number of mobile vendors, to find the errors on a simpler way before cell phones goes on sale. These Tests are performed in a complete network target environment.

The IoDT needed to develop the testing results even further for more specific results. To achieve such results, it requires new tools. The used tool (LogTool) needs to be developed and adapt even further to clarify the targeted results.

The LogTool was developed by creating a new Analyzer that analyses the log file and presents the results in a way that make it easier to be read.

LogTool is Eclipse plug-in based and this allows for a very flexible handling of the tool. Creating an analyzer simply means developing and adding a new plug-in. The analyzer is a set of java classes that performs the actual analysis. The Analyzer class doses the analysis and stores the data in the LayoutManager which determines the layout. The View takes the values from the LayoutManager and presents the result in a table.

A couple of tests were used in order to control the new tools behavior, whereas the log files consist of two separate tests. The new Analyzer works as expected and is implemented in a standard way, which makes it easier for future developments and improvements.

1.1 Background

This work has been performed at Ericsson in Linkoping. There the IoDT testing wants to use LogTool in order to sort the amount of data to interpret the result. The tests are performed in a complete network target environment. For this work I have Rani Iskender and Ankur Sharma as supervisor and Peter Danelius as examiner.

(20)

2 Introduction

1.2 Aim

The aim of this work is to develop and adapt LogTool to IoDT (Interoperability Development Test). IoDT testing consists of a network of many protocols that need to be verified. The system that is used today to get the information from the logs is complex and time consuming. Ericsson has developed an internal tool (Japy / LogTool) to check the various log files that are both in ASCI code and binary code. Basically the mentioned tolls should be fitted and developed to be adapted by IoDT

1.3 Limitations

Since the objective of the project was to add new functionality to LogTool, some limitations have to be made. LogTool and Japy are written in Java programming language and therefore the implementation of the new features also should be provided in the same programming language. By keeping main standards for example programming in the same language, this makes it easier to add new functions or edit the functionality if needed.

1.4 Thesis report outline

This thesis report has been divided into six chapters.

Chapter one: chapter one provides a general introduction to the thesis work scope

and outlines the contents of the thesis report.

Chapter two: this chapter contains an overview description of the LTE architecture. Chapter three: illustration of IoDT functionality and the available testing methods. Chapter four: brief description of Japy and LogTool topology and working area. Chapter five: analyzer verification of selective tests.

(21)

Chapter 2 Long Term Evolution (LTE)

Long Term Evolution (LTE) is the next big step in mobile radio communications. LTE meets the requirement for the next generation network with a peak speed of 100 Mbps for downlink, and 50 Mbps for the uplink. It has a round-trip-time of up to 30ms (i.e. the time it takes for a signal to go from a terminal across radio network to a server and back.).

The main benefit of LTE is increased transmission capacity and reduced delays in the network [3,14].

2.1 An Overview of LTE technique

LTE (Long Term Evolution) is the next evolution of the RAN (Radio Access Network). LTE is sometimes also called eUTRAN (Evolved Universal Terrestrial Radio Access Network). LTE is defined to support flexible bandwidths from 1.4MHz up to 20MHz. Conventional OFDM with data transmitted over several parallel narrowband sub carriers lies at the core of LTE downlink radio transmission. OFDM meets the LTE requirement for spectrum flexibility and enables cost-efficient solutions for very wide carriers with high peak rates. In the uplink, LTE uses a pre-coded version of OFDM called Single Carrier Frequency Division Multiple Access (SC-FDMA). This is to compensate for a drawback with normal OFDM, which has a very high Peak to Average Power Ratio (PAPR). LTE also supports both FDD (Frequency Division Duplex) and TDD (Time Division Duplex). LTE is specified to, for example, provide downlink peak rates of over 150Mbps, RAN round trip time of less than 10ms and three times higher spectral efficiency than HSPA (High Speed Packet Access) in 3GPP Release 6 [1].

2.2 An Overview of LTE Architecture

The figure below shows an overall architecture for LTE (Long Term Evolution), which consists of eNBs, providing the E-UTRA User Plane (UP) and Control Plane (CP) protocol terminations towards the UE. The eNBs are interconnected with each other through X2-interface. The eNBs are also connected to the SGW and MME using the S1 interface that supports many-to-many relationships [2].

(22)

4 Long Term Evolution (LTE) eNB MME / S-GW MME / S-GW eNB eNB S 1 S1 S 1 S1 X2 X2 X 2 E-UTRAN

Figur 2.1 Overall Architecture

2.3 Evolved NodeB (eNB)

The eNB is the interface between the UE and the EPC, it acts as a gateway to forward the communication between User Equipment and the Evolved Packet Core. To archive the function to handle all the communication between the UE and the core network (EPC), the eNB use the related radio protocols to communicate toward the UE and using the IP based connectivity to forward the radio connection to the core network (EPC) [3].

2.4 S1 interface

The interface between EPC and E_UTRAN is specified as the S1 interface. The S1 interface is used to interconnect the E-UTRAN to the EPC, in other words to interconnect the access point in E-UTRAN which is the eNB to the access point in EPC which are the Mobility Management Entity (MME logical node) or the Serving Gateway (S-GW logical node).

There are two types of S1 interface defined depending on the EPC-access point. The first one is the S1-MME which is the interface between eNB and MME, and the second one is the U which is the interfacing between eNB and S-GW. Several S1-MME interfaces could be established between eNB and EPC (to multiple S1-MME). It could be several S1-U interfaces between EPC (multiple S-GW) and the eNB though. Figure 2 depicts the logical division of the S1 interface [4].

(23)

2.5 X2 interface 5 EPC EUTRAN eNode B “S1-U” “S1-MME” S-GTW MME eNode B S-GTW MME

Figur 2.2 S1 Interface architecture

2.5 X2 interface

The interface between the eNBs is the X2-interface which connects the eNBs together. The X2 user plane interface (X2-CP) uses the application protocol for control signaling purposes between the eNBs. The X2 user plane (X2-U) uses the GPRS tunneling protocol user plane (GTP-U) for user’s data tunneling between eNBs. X2 is an IP-based interface and can therefore be considered as a point of Multi-point interface (eNB can communicate with all other eNB) [5].

GTP-U UDP

IP Data link layer User plane PDUs

SCTP IP Data link layer

(24)

6 Long Term Evolution (LTE)

2.6 Mobility Management Entity (MME)

As mentioned earlier the MME is connected to E-UTRAN (eNB) via the S1-MME interface. The MME is responsible for managing mobility and security procedures, such as network Attach /Detach, Paging, Tracking area updates, authentication and allocation of temporary identities, although it is only available in Control plane.

The MME is connected to the SGW via the S11-interface. This interface is used for paging initiation (SGW to MME), handover/re-routing indications and establishment of the EPC bearers (MME o SGW) [3,6].

2.7 Serving Gateway (S-GW)

The SGW connects to the E-UTRAN (eNB) via the S1-interfaces and is presented solely in the User Plane. Its prime responsibility is routing and forwarding of user IP-packets. SGW also acts as the mobility anchor for the user plane during eNB handovers, and as the anchor for mobility between LTE and other 3GPP technologies [3].

(25)

Chapter 3 Interoperability Design Testing

(IoDT)

IoDT testing is a phase out of the test process for a network in Ericsson. In that particular phase to be tested Interoperability together with real phones. Any standard misinterpretation processed within this test.

Out of the operators' perspective IoDT is strongly interesting when testing shown that Ericsson Network and mobile working and can handle all requirements for LTE [7].

3.1 Interoperability Design Testing (IoDT)

Interoperability design testing is performed during the design phase with a selected number of mobile vendors, to find the errors on a simpler way before the cell phones goes on sale. These tests are performed in a complete network target environment, which is of highly importance when the 3GPP specifications can be interpreted differently by different companies. During the development phase must all protocols be verified for both mobile devices and network infrastructures. Before cell phones and networks are released to customers, they must also operate on commercial operator's networks [7].

(26)

8 Interoperability Design Testing (IoDT)

Figur 3.1 Scope of the Interoperability Testing at LTE

3.2 Physical test case

A brief description of the physical channels used in physical testing. The figure below shows how the channels in the physical layer are used to send data and signals between eNB and UE [7].

 Physical broadcast channel (PBCH)

The physical broadcast channel carries the Master Information block (MIB) from the DCH transport channel. The MIB carries information such as system bandwidth, number of eNB antennas for MIMO operation and the transmit power used for the downlink reference signals [2,8].

 Physical control format indicator channel (PCFICH)

The purpose of this channel is to indicate the used format for the PDCCH transmission in the same sub-frame [2,8].

 Physical Hybrid ARQ Indicator Channel (PHICH)

This channel carries hybrid ARQ ACK/NACK which is related to the uplink transmissions on the PUSCH [2,8].

(27)

3.3 Full stack test case 9

 Physical downlink control channel (PDCCH)

The downlink control channel is used for indication of downlink transmission on PDSCH, and to inform the UE about the allocations of uplink resource on PUSCH/PUCCH. It also carries the uplink grant [2,8].

 Physical downlink shared channel (PDSCH)

PDSCH is the main downlink radio resource in a cell, carrying data and/or higher layer signaling [2,8].

 Physical random access channel (PRACH)

The physical random access channel carries the random access preambles during the random access procedure [2,8].

 Physical uplink shared channel (PUSCH)

This channel is the main uplink radio resource in a cell, carrying data and/or higher layer signaling application [2,8].

 Physical uplink control channel (PUCCH)

The PUCCH convery uplink control information in the form of channel quality indicator (CQI), uplink scheduling requests and ACK/NACK for data received in the PDSCH [2,8].

(28)

10 Interoperability Design Testing (IoDT)

 Attach and detach

Cell synchronization, the MIB and SIB acquisition, Time alignment, NAS Security. NW Initiated Detach, Ue initiated.

 Basic user data transfer (RTT, TCP and UDP)

 Idle mode (cell reselection, TAU, RRC Connection release, paging, Service Request)

 Mobility (S1HO, X2HO)  Dedicated bearer

 Link adaptation

 HARQ

3.4 Used tools at IODT

IoDT use different tools to perform their tests. Some of the most widely used tools are [7].

 Sun Ray workstation  Wireshark

Wireshark is a protocol analyzer that is used to capture the traffic between the eNB and the core network, i.e. the S1 traffic both for user plane and control plane.

 Air Interface tool

The air interface tool is used to log the traffic between the eNB and the UE.  Network Mobility tool

This tool is used to move the UE between several cells to manage Handover testing.

 MIMO box

The MIMO box redirects the RF phase signal before broadcasting it to the UE.

 Attenuators

Attenuator is used to reduce the amplitude or power of a signal without appreciably distorting.

(29)

3.4 Used tools at IODT 11

 LogTool

LogTool is the new tool which needs to be verified, developed and adapted to IoDT to be able to use it. LogTool will be used to facilitate the reading of log file and to present the results in a simpler way

(30)

(31)

Chapter 4 Japy and LogTool

4.1 Japy

Japy is an in house developed Java protocol parser where all protocol parameters are available for automatic analysis. Its strength features are good performance, simple to add new file formats, protocols and simple to extract and study specific protocol layers. It also has a flexible protocol stack binding. LogTool Uses Japy as protocol parser, and to decode the events [9].

Figur 4.1 Japy parsing principles.

4.2 LogTool

LogTool is an Ericsson open source multi platform protocol analyzer framework. It is java based analyzer tool and it is build using eclipse RCP and Plug-in technology. As mentioned above LogTool is Eclipse plug-in based and this allows for a very flexible handling of the tool. An example to add a new protocol parser or analyzer simply means developing and adding a new plug-in. The Eclipse update manger is an efficient way to spread updates and new functionality. LogTool can be configured to

(32)

14 Japy and LogTool

LogTool consists of three main parts, A Reader, Analyzer and Protocol Parsers [10,11].

 The Reader reads raw data, and it can read PCAP files, NethawkM5, GMLOG, binary files, CPP T&E text files and PM event files (ROP files), it can also be connected directly to eNB or TE Router and performs online real time analysis [10].

 The Analyzer analyses the data and presents the results. It can present data in tables, pure text, graphs and in socket. The analyzer are “simple to write” and can be developed by a tester with good protocol knowledge and basic java knowledge [10].

 The Protocol Parser parses the data into Japy packets (A chain of instances of where each instance represents a protocol message with all parameters) [10]. These three parts works together, an Analyzer selects a Reader (data source) and Protocol Parsers (by selecting a protocol stack). The Analyzer receives ready parsed events from the Reader and performs some analyze and presents the result [10].

Figur 4.2 screen shot of LogTool.

4.3 Overview descriptions about how to create an analyzers

Creating LTE analyzers can be divided into the following main tasks.

Creating a plug-in project to encapsulate the analyzer. A plug-in in Eclipse is a functional unit that implements functionality. A plug-in is a set of description files most of them in xml format. Eclipse has special editors that makes creating plug-ins and features simpler [9,12].

(33)

4.4 Creating the analyzer 15

 Creating a feature that makes the analyzer plug-in available for LogTool. The Eclipse update manager manages features but not plug-ins, the plug-ins by its turn therefore encapsulated into features. A feature can consist of many plug-ins. It will specify requirements and dependencies between plug-plug-ins. A feature is a set of description files most of them in xml format. Eclipse has special editors that makes creating plug-ins and features simpler [9,12].

 Creating the analyzer. An analyzer is a set of java classes that performs the actual analysis. To create the simplest analyzer type, it requires at least one class extending the AbstractEventAnalyzer. This class is normally named Analyser.java [9,12].

 Creating an html help file describing the analyzer. LogTool has a great built in help system. Analyzer specific help files are automatically merged into the main help file and made available from the tool explorer. It is therefore essential that all analyzers have a HTML file that describes the analyzers functionality [9,12].

4.4

Creating the analyzer

As we mentioned before the analyzer is a set of java classes that performs the actual analysis. To continue to create an analyzer we need a source folder and a package. The source folder shall be in the plug-in project folder. When this is done we create the java classes. More information about the analyzer, see the next chapter [9].

(34)

.

(35)

Chapter 5 Creating the analyzer for the CQI

& MCS

5.1 Developing a new Analyzer

My contribution was to develop a new Analyzer to analysis a log file and presents the result in a table. The log file contains of different of traces, the CQI (Channel Quality Indicator) and MCS (Modulation and Coding Scheme). These values are needed to calculate the quality of a channel to control the speed facing stability. CQI is reporting from the Mobile depending on the quality of the channel, as a response the eNB sends the MCS, which means how big the data blocks that can be scheduled and sent to the EU (mobile).

IoDT performs these tests and saves the results in a log file. The analyzer makes it available to read from the log file in a simpler way, this means that the results will be shown in the table.

When the plug-in, source folder and package are created, it is time to create the java classes to perform the analysis of these tests. Five java classes are needed for this analyzer [7].

 Activator.java

The activator class controls the plug-in life cycle. It is used for starting and stopping the plug-ins in eclipse.

 Analyzer.java

The analyzer class performs the analysis.  LayoutManager.java

This class works like a “database” between the Analyzer class and the View class, it stores the data and determines the layout.

 ResultObject.java

A help class that encapsulates the information into array lists.  View.java

The View class Present the result in a table.

The main classes are Analyzer, LayoutManager, and View classes where the work is carried out. The Analyzer doses the analysis and forwards the data to LayoutManager

(36)

18 Creating the analyzer for the CQI & MCS

5.2 Analyzer class

This class performs the analysis and sorts the data in a hash map using the Japy methods for interrogating data. Most of the methods work on both Packet level and Structure level. Some of the used methods are:

 hasAttributeStructure checks if attributes exists in structure  hasAttributePacket checks if attributes exists in Packet  getAttributeStructure fetches an attributes from the Structure  getAttributePacket fetches an attributes from the Package  hasStructure checks if a struct exists in Packet  getStructure fetches a structure from a packet

A Packet is a chain of Structures. The working method of a Packet always starts at given Structure and runs down to the end of the chain. A method that works in a Structure limits its own working in the mentioned Structure. The method above is used to run down in the chain to get the values for the CQI and MCS test. The example below show how this is working.

Using the methods to get all the values for the CQI and MCS tests and encapsulate the information using the ResultObject class and put it in the hash map in the LayoutManager class. A brief example is shown below.

Public void analyse(Structure analysePkt) {

if (analysePkt.hasStructure("******************"))

{

try

{

Structure value = analysePkt.getStructure("Value");

long value2 = value.getAttributeStructure("Value2").getBitArray();

} }

(37)

5.3 LayoutManager class 19

The CQI and the MCS test are logged in the same log file but they are not in the same packet. Each of CQI and MCS values belongs to each others. The ResultObject class contains two arrays, one for the CQI info and the other one for the MCS info. The key is the value that makes sure that the CQI and MCS belong to each others.

5.3 LayoutManager class

The LayoutManager class stores the data and determines the layout. The data is encapsulated in a class with two arrays and stored in a hash map. When all the data is in the hash map it is time to determine the layout. The idea is to get the values from the hash map and put them in a new array. The new array is used in the viewer to print out one line data in the table. The functions below demonstrate how this is done.

private LayoutManager lm;

ResultObject obj = new ResultObject();

if(!lm.gethMap().containsKey(key))

{

obj.setCqiValues(cqi_info); // encapsulate the CQI

information.

lm.gethMap().put(key, obj); // put it in the hash map with

aspecific key. } else { lm.gethMap().get(key).setCqiValues(cqi_info); }

public String[] buildOneLineDatahash(String

key,LinkedHashMap<String, ResultObject> hashmap) // the function

that build one line data.

{

List <Object> hashlist_cqi = new ArrayList<Object>(); //array to

store the CQI values

List <Object> hashlist_mcs = new ArrayList<Object>(); //array to

store the MCS values

if(!hashmap.get(key).getCqiValues().isEmpty())

{

hashlist_cqi = hashmap.get(key).getCqiValues(); //

storing the values

}

(38)

When the data are stored in the new arrays it is time to build the data line that later will be presented in the table.

In this case there is data from the CQI and MCS. In other cases there is data from only CQI or MCS. In that case print only a “--”. An example result.add("-");// MCS SFN. When all the controls are done and the data is stored in the result list, return the result list which contains the data for one line in the table.

5.4 View class

This is the class that presents the result. When the LayoutManager has created the layout, the Viewer presents the result in a table.

The table was created using SWT designer.

SWT Designer (also part of WindowBuilder Pro) is a powerful and easy too use for bi-directional Java GUI designer that supports Eclipse SWT technology. It is quite straight forward to create Java GUI and Eclipse RCP applications [13].

By using the visual designer to create a figure, Java code will be generated automatically for the chosen figure.

List <String> result= new ArrayList<String>();

if(hashlist_cqi.size()!=0 && hashlist_mcs.size()!=0)

{ result.add(hashlist_cqi.get(0).toString()); //time result.add(hashlist_cqi.get(1).toString()); //type result.add(hashlist_cqi.get(2).toString()); //RI result.add(hashlist_cqi.get(3).toString()); //CQI result.add(hashlist_cqi.get(4).toString()); //CQI SFN result.add(hashlist_mcs.get(8).toString());// MCS SFN result.add(hashlist_mcs.get(0).toString() +"-"+ hashlist_mcs.get(1).toString()); //MCS result.add(hashlist_mcs.get(2).toString() +"-"+ hashlist_mcs.get(3).toString()); //TBS result.add(hashlist_mcs.get(4).toString() +"-"+ hashlist_mcs.get(5).toString()); //RV result.add(hashlist_mcs.get(6).toString() +"-"+ hashlist_mcs.get(7).toString()); //NDI }

(39)

5.5 Problems and challenges during the development of the new Analyzer 21

Figur 5.1 A screen shot of the table.

When the table is created it is time to fill the table with the results. That is done using an Iterator and iterate over the hash map. The code below shows how the iterating is done and how the View works with LayoutManager. This code runs when the CQI/MCS button is clicked.

5.5 Problems and challenges during the development of the

new Analyzer

As usually troubles and challenges comes across under the work. . The biggest challenge under the project was to learn how Japy methods work and how to calls for these methods and what these functions return. With a little help and guidance it went well, and when I had understood all the details it became much easier to use the methods and continue to work.

Iterator it = lm.gethMap().keySet().iterator();

while(it.hasNext())

{

String key = it.next().toString();

String[] onelinedata = lm.buildOneLineDatahash(key, lm.gethMap());

TableItem item = new TableItem(table, SWT.NONE);

item.setText(onelinedata); }

(40)

When the data was too big it took time for the analyzer to analyze the log file and present data in the table. To prevent this problem I used a hash map. the main advantage of a hash map over other data structures is speed.

One of the things that I learned under this thesis was that the program should always be structured for further development. Thinking long term and trying to implement everything in a simple and standardized way which facilitates the development both for the issuer and for the other editors.

(41)

Chapter 6 Conclusion

The new Analyzer works as expected, and to check the functionality some tests were performed. One of the testers in IoDT ran some tests that checks for the CQI and MCS values and log the test in different log files. The log files decoded and the results presented in the usual way that testers do in the lab and with LogTool using the new Analyzer and later the results were compared to each other. The results of these tests have shown that the new analysis works and that it is much easier and more practical to read CQI and MCS values. The testers in IoDT were satisfied with the results but unfortunately the new Analyzer couldn’t be used due the fact that it is only capable of a particular test case.

LogTool is an important tool for IoDT, it facilitates the reading of log files. LogTool have other Analyzer that can be used for other test cases. A major advantage of LogTool is that the tester can connect LogTool directly to an ENB to perform online real-time analysis and present the information at the same time and save a logfile, unlike the classic ways that testers do today, there they need to run the tests, save all data in a logfile, decode the file and then read the results from the file.

Other advantage of LogTool is that it is simple to use LogTool and it can read events from various files, The Analyzer is “simple to write” and can by developed by testers with good protocol and java knowledge. Analyzer can present the data in several ways for example as a text, graphs in GUI, files, socket, and database.

The Analyzer implemented in a standard way, which makes it easier for future developments and improvements. As mentioned before, the results are presented in a table where columns can be moved to facilitate the reading of the result.

A future plan for LogTool in IoDT is to develop the new Analyzer in order to make it possible to apply other test case. Where results can be presented in different ways and that simplifies the result reading from the log files.

(42)

(43)

References

[1] 3rd Generation Partnership Project

(3GPP)ftp://ftp.3gpp.org/Inbox/2008_web_files/LTA_Paper.pdf. Accessed 2010-08.02.

[2] 3rd Generation Partnership Project (3GPP) http://www.3gpp.org/ftp/Specs/html-info/36300.htm, Event RP-48 version 10.0.0 available 06-18, Accessed 2010-08.02.

[3] Motorola

http://www.motorola.com/staticfiles/Business/Solutions/Industry%20Solutions/Servic e%20Providers/Wireless%20Operators/LTE/_Document/Static%20Files/6834_MotD oc_New.pdf. Accessed 2010-08.03.

[4] 3rd Generation Partnership Project (3GPP) http://www.3gpp.org/ftp/Specs/html-info/36411.htm, Event SP-46 version 9.0.0 available 2009-12-18, Accessed 2010-08.04.

[5] 3rd Generation Partnership Project (3GPP) http://www.3gpp.org/ftp/Specs/html-info/36420.htm Event SP-46 version 9.0.0 available 2009-12-18. Accessed 2010-08.12.

[6] 3rd Generation Partnership Project (3GPP)

http://www.quintillion.co.jp/3GPP/Specs/23401-800.pdf, Accessed 2010-08.12. [7] Interoperability design testing, internal document.

[8] 3rd Generation Partnership Project (3GPP) http://www.3gpp.org/ftp/Specs/html-info/36201.htm Event RP-47 version 9.1.0 available 03-30, Accessed

2010-08.13.

[9] LogTool http://www.lmera.ericsson.se/ltett/logtool/presentations/Japy.ppt, Accessed 2010-08.16.

[10] LogTool http://www.lmera.ericsson.se/ltett/logtool/. Accessed 2010-08.18. [11] LogTool http://www.lmera.ericsson.se/ltett/logtool/presentations/LogToolforManagment. Accessed 2010-08.20. [12] LogTool http://www.lmera.ericsson.se/ltett/logtool/doc/creatinganalyzers/introduction.html. Accessed 2010-08.20.

(44)

Investigation and development of a verification protocol test tool for LTE

Institutionen för datavetenskap

Department of Computer and Information Science

Final thesis

Investigation and development of a verification

protocol test tool for LTE

Jolian Georgis

LIU-IDA/LITH-EX-G--10/024--SE

2010-11-07

Final thesis

Investigation and development of a

verification protocol test tool for LTE

Jolian Georgis

LIU-IDA/LITH-EX-G--10/024--SE

2010-11-07

Abstract

Acknowledgements

Contents

Figure and tables

Acronyms

Chapter 1

Introduction

1.1 Background

1.2 Aim

1.3 Limitations

1.4 Thesis report outline

Chapter 2

Long Term Evolution (LTE)

2.1 An Overview of LTE technique

2.2 An Overview of LTE Architecture

2.3 Evolved NodeB (eNB)

2.4 S1 interface

2.5 X2 interface

2.6 Mobility Management Entity (MME)

2.7 Serving Gateway (S-GW)

Chapter 3

Interoperability Design Testing

(IoDT)

3.1 Interoperability Design Testing (IoDT)

3.2 Physical test case

3.4 Used tools at IODT

Chapter 4

Japy and LogTool

4.1 Japy

4.2 LogTool

4.3 Overview descriptions about how to create an analyzers

Creating the analyzer

Chapter 5

Creating the analyzer for the CQI

& MCS

5.1 Developing a new Analyzer

5.2 Analyzer class

5.3 LayoutManager class

5.4 View class

5.5 Problems and challenges during the development of the

new Analyzer

Chapter 6

Conclusion

References