Mobile Radio Network

Contents

• Introduction and background• Literature review:

• Architecture of Mobile Radio Access Networks• State of the art in management of mobile networks as defined by 3GPP• Performance management data• Functionality scenarios in UTRAN

• Methods of the practical study• Results:

• Results (I/IX): Current PM and FM organisation and process• Results (II/IX): Example on current PM and FM process (1/3)• Results (III/IX): Example on current PM and FM process (2/3)• Results (IV/IX): Example on current PM and FM process (3/3)• Results (V/IX): Analysis of the current organisation and process• Results (VI/IX): Problems in current PM and FM process, Interrelationship- and why-why-diagrams

of the process problems • Results (VII/IX): Summary of the analysis• Results (VIII/IX): Solution for automated investigation• Results (IX/IX): Implementation of the solution

• Conclusions of the thesis• References

Key concepts

• 3GPP = Project that aims to develop GSM and UMTS specifications in cooperation with the vendors, operators and standardisation organisations. The acronym 3GPP stands for Third Generation Partnership Project.

• Fault management = Functions that enable the detection and location of failures in the network and scheduling of repairs. 3GPP specifies the requirements of the concept.

• Mobile radio access network = a network that provides wireless access to users through radio interface and allows the mobile users to move between coverage areas without losing connection, i.e. handover.

• Performance management = Functions that enable the performance measurements of network services. 3GPP specifies the requirements of the concept.

Introduction and background

• Research area: Mobile Radio Network Performance and Fault Management

• Research questions:• What is a mobile radio access network and how it is managed?

• What is the current performance management set-up in the organisation under study?

• What is the organisation and communication structure?

• What is the process to tackle performance problems in UTRAN?

• What are the problems of the current set-up?

• What could be solutions to the root-problems found from the current setup?

• Scope:• Limited to European 3G mobile radio network = UTRAN (UMTS Terrestrial Radio

Access Network)

• Other major mobile radio network technologies are: GERAN (GSM radio network), Wimax (WMAN) and WiFi (WLAN)

How to enhance the productivity of the

UTRAN performance management

investigations?

Architecture of Mobile Radio Access Networks

• General architecture• UE – User Equipment

• Consists of Mobile Equipment (ME) and Subscriber Identity Module (SIM) for the end-user to access the mobile network

• RAN – Radio Access Network• Currently the most popular mobile RANs are UTRAN and GERAN

• Other radio access technologies are LTE, WiMAX and WiFi

• CN – Core Network• All RANs are attached to a CN that provides switching and access to

services in PSTN and any IP network

• OSS – Operations Support System• All parts of the mobile network may be managed by a centralised

system

• UTRAN architecture• Network elements

• RNC – Radio Network Controller

• Node B aka. BTS – Base Transceiver Station

• A – ATM transmission nodes

• Interfaces• IuCS: RNC to Circuit Switched Core Network (voice and video calls)

• IuPS: RNC to Packet Switched Core Network (data calls)

• Iur: RNC to RNC

• Iub: RNC to BTS

• Uu: BTS to UE

• O&M: OSS to any network element: RNC, BTS, ATM-nodes and CN elements (MSC, HLR, SGSN, GGSN etc.))

Mobile network

RAN

UTRAN

GERANUE

X

CN

PSTN

IP

OSS

Iu / A /Gb / ..Uu / Um / ..

O&M

UE

Mobile network

UTRAN

RNC

CN

OSS

Iu (CS/PS)Uu

RNC

B

B

B AB

CS

PS

Iub

Iur

O&M

State of the art in management of mobile networks as defined by 3GPP• Network management areas relevant to RAN technical support

• Performance Management (PM)• Keeps track on the network performance status and analyses the effects of configuration changes in the network

[3GPP TS 32.101]• Bases on measurements that are continuously recorded in the network elements

• Fault Management (FM)• Consists of fault detection, fault localisation, fault reporting, fault correction and fault repair [3GPP TS 32.111-1] • Bases mainly on alarms and system logs that the network elements produce

• Software management (SWM)• Covers software request management, installation, customer feedback and software fault management, i.e.

detection of software faults and finding resolution to the problems. This duty is close to and overlapping with fault management (FM) [3GPP TS 32.101]

• Configuration management (CM) • Controls the operational parameters of network elements [3GPP TS 32.600]

1. PM 2. FM param or software?

3a. CM

3b. SWM

• Process of applying the network management:

1. Performance monitored2. Faults localisedDepending on the type of failure:

3a. Configuration changedor3b. Software defect(s) corrected

4. Monitor the performance (step 1)

Functionality scenarios in UTRAN

• Control plane, i.e. signaling, on RRC connection (Radio Resource Control)• Major purpose: setup and release a call

• User plane, i.e. the traffic, on RAB connections (Radio Access Bearer):• Major purpose: define the QoS class of the call:

• Conversational class, RT (Real Time), applications: CS voice and video calls• Streaming class, RT, applications: CS streaming video• Interactive class, NRT (Non RT), applications: PS (Packet Switched) web browsing• Background class, NRT, applications: emails, MMS (Multimedia Messaging Service)

• Signaling scenarios:• MTC (Mobile Terminated Call) scenario

1. Paging: RNC sends an “RRC Paging Type 1” message to the Uu interface2. RRC connection setup: The paged UE responses by starting the radio control connection establishment procedure by (1.)

sending an “RRC Connection Request” message to RNC (“RRC Connection Setup Attempt” counter is updated). (2.) RNC tries to allocate radio resources (BTS) and if successful, it responses with “RRC: Connection Setup” message (“RRC Connection Setup Complete” counter is updated). (3.) Finally the UE responses with “RRC: Connection Setup Complete” message (“RRC Access Complete” counter is updated).

3. Transaction reasoning: RNC and CN negotiate on the transaction type4. Authentication and Security procedure: UMTS subscriber and network authenticate each other, and other security

mechanism are activated5. RAB setup for transaction: Actual communication resources for the transaction are allocated. 6. Transaction: UE has an active user plane bearer connection across the whole UMTS network7. RAB release for transaction clearing: Network resources related to the transaction are released, i.e. all the RAB active

connections for an UE are released 8. RRC connection release: Radio control connection between the UE and the UTRAN is released

• Mobility (handover scenario):1. Measurement: the UE sends a radio-link measurement report to the RNC2. Decision: the final decision to make a handover is done in RNC by the RRM handover control algorithms. Decision bases on

the handover criteria and algorithm parameters3. Execution: handover signalling between e.g. UE and RNC, and radio resource allocation e.g. in BTS

Performance management data

• Performance counters• UTRAN collects thousands of counters that measure the amount of specific

events

• E.g. RRC Setup Attempts, RRC Setup Completes, RRC Setup Attempt Failure RNC, RRC Setup Attempt Failure BTS etc.

• KPI (Key Performance Indicator)

Calculated most often from performance counters to relative %-values • Relative% KPIs are comparable between networks of different sizes,

absolute values are not, because the amount of traffic varies

• Form: KPI = (a formula of performance counters)

Examples:• RRC_Acc% = “RRC access complete ratio” = “RRC Access Completes” / “RRC Setup Attempts”

• CSSR, Call Setup Success Rate (voice call) = RRC_Acc% * (RAB_voice_attempts-RAB_voice_failures) / RAB_attempts

• CCSR, Call Completion Success Rate (voice call) = (RAB_active_voice_failures) / (RAB_active_voice_failures +

RAB_active_voice_succesful_completes)

Methods of the practical study

• Based on UCD (User Centered Design) process and framework

• Chronologically the practical study had three phases:I. Study and define the current process and organisation

a. Study: interview

b. Study: focus group

c. Study: contextual enquiry

II. Analyse the current set-upa. Analysis: brainstorming

b. Analysis: affinity diagram

c. Analysis: double teams

d. Analysis: interrelationship diagram

e. Analysis: why-why-analysis

III. Develop an enhanced processa. Solution: brainstorming

b. Solution: SWOT analysis

c. Solution: UML diagrams

Results (I/IX): Current PM and FM organisation and process

• Organisation-wise Technical support is the communicator between the local customer contact teams and product line R&D organisation. 1. Local teams communicate the performance

status of the customer networks to the technical support.

2. Technical support investigates and analyses the performance degradations and makes decisions to fix them with the co-operation of R&D.

3. R&D’s responsibility is to develop corrections to the system, if no other solution is effective.

• The process follows the three phases of the root-cause analysis methodology:

• Investigation (maps to PM [3GPP])

• Analysis (maps to FM [3GPP])

• Decision (maps to SWM and CM [3GPP])

• Each phase of the process has deliverables that are utilised in the later phases.

R&D

Local team A

Local team B

Customer A

Customer B

Customer C

Technical Support

Investigation ~ PMInvestigation ~ PM

1. Get top level PM data

2. Find performance dips

3. Get detail level PM data

4. Find problematic sites

5. Gather logs, alarms etc.

Analysis~ FMAnalysis~ FM

6. Analyse the logs and other detail level data

that was gathered during the investigation

Decision~ CM ~ SMDecision~ CM ~ SM

7. Generate solutions

Results (II/IX): Example on current PM and FM process (1/3)1. Get KPIs and failure counters for the

required top object (i.e. RNC)• Achieved by using a reporting tool that

collects the needed counters from the OSS measurement database and calculates the KPI values based on the counters. By manual post-processing the data, the graphical output

2. Find measurement periods where there is a dip in performance:

• Call setup performance: at 11 the CSSR KPI has had poor values. The phenomenon has been partly ongoing during the next hour

• Retainability: high drop call ratio at 16. Counter diagram verifies that the drop in CCSR is due to high number of RAB active failures.

60.00

65.00

70.00

75.00

80.00

85.00

90.00

95.00

100.00

105.00

KP

I [%

]

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

RR

C C

on

nec

tio

n S

etu

p A

ttem

pts

RRC setup attempts CSSR CCSR

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

2006

/12/

23 0

0

2006

/12/

23 0

1

2006

/12/

23 0

2

2006

/12/

23 0

3

2006

/12/

23 0

4

2006

/12/

23 0

5

2006

/12/

23 0

6

2006

/12/

23 0

7

2006

/12/

23 0

8

2006

/12/

23 0

9

2006

/12/

23 1

0

2006

/12/

23 1

1

2006

/12/

23 1

2

2006

/12/

23 1

3

2006

/12/

23 1

4

2006

/12/

23 1

5

2006

/12/

23 1

6

2006

/12/

23 1

7

2006

/12/

23 1

8

2006

/12/

23 1

9

2006

/12/

23 2

0

2006

/12/

23 2

1

2006

/12/

23 2

2

2006

/12/

23 2

3

0

50

100

150

200

250

300

350

400

450

500

RRC setup failures RRC access failures RAB setup failures RAB access failures

RAB active failures RRC active failures RRC setup attempts

KPIs: Failure counters:

Results (III/IX): Example on current PM and FM process (2/3)• 3. Get the KPIs and failure counters on BTS level.

• It can be achieved using the same reporting tool than in the first phase. The output is extensive list of all the BTS under one RNC, all measurement periods and counters per each BTS.

• 4. Find the network elements that are causing the performance dip. • After post-processing the data, the results are lists of BTS that are the

main contributors to the performance dips

time

RN

C id

BT

S id

Cel

l id

CS

SR

CC

SR

RR

C s

etup

atte

mpt

s

RR

C s

etup

failu

res

RR

C a

cces

s fa

ilure

s

RA

B s

etup

failu

res

RA

B a

cces

s fa

ilure

s

RA

B a

ctiv

e fa

ilure

s

RR

C a

ctiv

e fa

ilure

s

2006/12/23 11 1 104 1041 15.02 99.01 1345 1132 4 3 4 2 42006/12/23 11 1 104 1042 19.19 96.97 1032 820 4 5 5 6 52006/12/23 11 1 104 1043 22.26 97.76 602 452 7 8 1 3 42006/12/23 11 1 69 691 56.76 99.05 185 69 6 2 3 1 22006/12/23 11 1 69 693 59.60 96.61 99 24 7 8 1 2 22006/12/23 11 1 201 2011 64.29 96.30 84 19 6 3 2 2 3

time RN

C id

BT

S id

Cel

l id

CS

SR

CC

SR

RR

C s

etu

p a

ttem

pts

RR

C s

etu

p fa

ilure

s

RR

C a

cces

s fa

ilure

s

RA

B s

etu

p fa

ilure

s

RA

B a

cces

s fa

ilure

s

RA

B a

ctiv

e fa

ilure

s

RR

C a

ctiv

e fa

ilure

s

2006/12/23 16 1 123 1231 98.46 15.80 1234 8 4 3 4 1023 42006/12/23 16 1 123 1232 98.45 24.70 1032 3 4 4 5 765 52006/12/23 16 1 123 1233 97.51 45.32 602 4 7 3 1 321 42006/12/23 16 1 69 691 96.62 91.40 385 2 6 2 3 32 22006/12/23 16 1 69 693 97.66 91.62 342 1 3 3 1 28 2

Results (IV/IX): Example on current PM and FM process (3/3)5. Gather the system logs for those network elements that are main contributors of the

RNC performance dip. • Achieved by connecting to the network element’s O&M unit either by manual command

procedures or using a tool that automates the procedure. The log files are usually in binary format, so they need to be opened by a parser or converted to textual format before the analysis can take place.

6. Analyse the detailed data. • The format of the data is vendor specific, i.e. not defined in public specifications

=> no general guidance can be set for the analysis itself.

• Highly dependant on the individual system specialists that can handle the versatile analysis and can produce reliable results The analysis can be in this context treated as a black box, which has the input of system data, i.e. logs, parameters, alarms, counters and KPIs, and output of set of root-causes for the occurred performance problem.

• 7. Generate a solution to the root-cause. • Needs the presence of a skilled system specialist. Depending on the type of solution, finding a

working solution might need trial and error approach. • Before applying the solution to a live network, it is tested in a test bed of the vendor. Some

network operators have also test beds of their own, on which they verify the solutions, e.g. SW corrections, before they are installed to the live network.

Results (V/IX): Analysis of the current organisation and process• Main problems:

• Problems in current organisation operation• 7.2.1 High travel costs

• 7.2.2 Troubleshooting poorly controlled

• Problems in current PM and FM process• 7.3.2 NE logs not available for performance dips

• 7.3.3 Alarms not mapped to performance dips

• 7.3.4 Configuration data not available for performance dips

• 7.3.5 Internal failures not distinguished from external causes

• 7.3.6 Investigation is time consuming

Results (VI/IX): Problems in current PM and FM process,Interrelationship- and why-why-diagrams of the process problems

Why-whyInterrelationship

CM data not available

NE logs not available

Alarms not mapped

Investigation

is timeconsuming

Internal failures not

distinguished from

external

Manual work

Too much traffic per RNC CPU and memory capacity for continuous monitoring

No consistent set of tools for performance management and troubleshooting available

RNC CPU/MEM capacity too smallfor monitoring

Alarms not collected

Lack of competence

No reference points

Performance data is not available to base decision to gather logs

NE logs are too large to be saved continuously for a long time

Results (VII/IX): Summary of the analysis

• Analysis set two general requirements for the solution:• Support fault management analysis conducted by system

specialists. The solution should be able to collect relevant fault management (FM) data, i.e. NE logs, configuration data and alarms, for troubleshooting. The evaluation of the FM data relevance bases on the performance measurement data, which may be collected either from OSS or from RNC.

• Support general reporting of performance conducted by operator and vendor performance management bodies.The solution should produce scalable reports of the performance measurement data. Reports should represent the performance data both on whole network and individual network element level down to the level of a single cell. Other statistical requirements are: timely aggregation and that the data can be averaged.

Results (VIII/IX): Solution for automated investigation

Connection to a

live network

System log files for the failures

that have occurred in the

live network

Overview report of the live network performance

Investigation ~ PM

“the solution”:

Automated investigation

of the network performance

Investigation ~ PM

“the solution”:

Automated investigation

of the network performance

Analysis~ FMAnalysis~ FM

Decision~ CM ~ SMDecision~ CM ~ SM

INPUT: •“Connection to a live network”. The requirement of the developed solution is either a working remote or on-site connection to the network. This prevents limitations on from which specific parts of the network the data is gathered, i.e. the OSS, NEs or some other databases in the network.

OUTPUT:•System log files and other detail data for the failures that have occurred in the live network. The root-cause analysis phase utilises this data to make decisions.

•Overview reporting of the network performance that can be utilised in reporting the status of the network to company management and to customer, i.e. the network operator.

Results (IX/IX): Implementation of the solution

• The distributed system consists of five separate applications:• RNC monitor

• RNC static performance data fetcher

• OSS data fetcher

• Processor & Report (application)

• Report (server)

O&M

Sol2: RNC monitor/data fetcher

Sol2: RNC monitor/data fetcher

Mobile network

UTRAN

RNC

CN

Iu (CS/PS)

RNC

B

B

B AB

CS

PS

Iub

Iur

OSS

Sol1: Oss data fetcher

Sol1: Oss data fetcher

Sol3: Log&alarmfetcher

Sol3: Log&alarmfetcher

Sol4: Processor

Sol4: Processor

Sol5: Report

Sol5: Report

Conclusions of the thesis

• Summary of the thesis, Thesis studied practical problems of mobile radio network management: • Conclusion: UTRAN vendor technical support requires a distributed system of troubleshooting tools

to enhance its troubleshooting processes• Purpose of the troubleshooting tools is to enhance the performance investigation by automating gathering of

the performance and other relevant network behaviour data for the time periods where network suffers from low performance

• The reasoning of the solution bases on • Current troubleshooting set-up study:

• Organisation: vendor home base technical support that is a link between local teams, which are located by the operated networks, and the vendor R&D. During special occasions, e.g. a new product release or emergency situation in network, the organisation may adjust itself by transferring temporarily system specialist to work locally by the operated network.

• Process: The practical performance and fault management process consists of three phases: investigation, analysis and decision.

• The analysis of the current set-up: • currently the main problem is the inefficiency of the first, i.e. investigation, phase in the performance and fault management

process.

• Generalisation of the results• Same principles are applicable to other radio network (e.g. GERAN) performance and fault

management• Utilization of an OSS in data gathering makes the solution more portable to other radio network systems

• Typically OSS uses relational SQL databases. Different radio networks have different performance indicators. Then the same tools may be used after modifying SQL-queries, which is a straightforward process

• Future work• Scope was limited to investigation. Also the complex analysis-phase has demanding development

needs.• Technical support organization requires product-processes to manage the development and

maintanance of the troubleshooting tools.

References

• Standards and Technical Specifications• 3GPP: GSM, 3G and LTE• IEEE: WiFi and WiMAX

• Commercial material• Nokia Multiradio: http://www.nokia.com/NOKIA_COM_1/Microsites/NokiaWorld/Press/Multiradio_Press_Backgrounder.pdf

• Cisco WiMAX: http://www.cisco.com/en/US/netsol/ns616/networking_solutions_customer_profile0900aecd80334a23.html

• Previous thesis’• Kujala, Kimmo (2006) Expert System for Mobile Network Troubleshooting. Thesis.

Diplomityö, TKK / Sähkö- ja tietoliikennetekniikan osasto, 2006. 72p.• An attempt to build automated fault analysis tool system. The result in the thesis was that

automated analysis is still unreliable!• Utriainen, Juha (2004) UTRAN Operation System Security. Thesis. Diplomityö, TKK /

Sähkö- ja tietoliikennetekniikan osasto, 2004. 64p.• Gives a good overview on the UTRAN O&M (Operation and Maintenance)

• Handbooks• Kaaranen, Heikki (2005) UMTS Networks – Architecture, Mobility and Services.

Second Edition. JOHN WILEY & SONS. ISBN: 0470011033 • Nielsen, Jakob (1993) Usability Engineering. Boston: Academic Press, 1993.