3G RAN Capacity

Telcel – Nokia Siemens Networks confidential1 © Nokia Siemens Networks 3G RAN Capacity / Poul Larsen / March 2009

3G RAN Capacity Management workshop

Telcel, Mexico City, March 2009Poul Larsen

2 © Nokia Siemens Networks 3G RAN Capacity / Poul Larsen / March 2009Telcel – Nokia Siemens Networks confidential

Agenda

• What is capacity management and why is it needed?• Brief introduction to RAS06 performance monitoring• How to monitor

– Air Interface– BTS– Iub– RNC– Iu-CS, Iu-PS, Iur

Not covered:- HSUPA- Advanced Iub configurations- Core network- IP BB- Etc.


What is capacity management and why is it needed?


Traffic volumes going up

5 TB/day

10 TB/day

“Worst case”: from 5 TB to 10 TB in 4 months


Traffic volumes going up

~20x traffic growth in only 9 months

HSDPA Subs:• 1Q08: 34,000• 2Q08: 75,000• = +119% in 3 mths

WCDMA total in 2Q08:• 1.9 M with 33% quarterly growth

=> Where will the quality of Mobile BB service go without well planned capacity expansion?

Even with sufficient network capacity today, there could be serious congestion within a few months• Does the operator know the situation today?• Does the operator know how to monitor all the possible capacity bottlenecks?• Does the operator have long-term strategies for how to expand capacity?


0

2000000

4000000

6000000

8000000

10000000

12000000

14000000

04/10

/2006

09/10

/2006

14/10

/2006

19/10

/2006

24/10

/2006

29/10

/2006

03/11

/2006

08/11

/2006

13/11

/2006

18/11

/2006

23/11

/2006

28/11

/2006

03/12

/2006

08/12

/2006

13/12

/2006

18/12

/2006

23/12

/2006

28/12

/2006

02/01

/2007

07/01

/2007

12/01

/2007

17/01

/2007

22/01

/2007

27/01

/2007

01/02

/2007

06/02

/2007

11/02

/2007

16/02

/2007

21/02

/2007

26/02

/2007

03/03

/2007

08/03

/2007

13/03

/2007

18/03

/2007

23/03

/2007

28/03

/2007

02/04

/2007

06/04

/2007

11/04

/2007

16/04

/2007

21/04

/2007

26/04

/2007

01/05

/2007

06/05

/2007

11/05

/2007

16/05

/2007

Dat

a Vo

lum

e (M

bits

)

0

400000

800000

1200000

1600000

2000000

2400000

2800000

HS-

DSC

H S

elec

tions

HS-DSCH selections/RNC_614A HSDPA data volume (MAC-d) at Iub/RNC_608A

Badly timed capacity upgrade – case example

This operator lost the Mobile Broadband business leading position and 36% of data revenues in 2 yrs monitoring period

Capacity bottlenecks found and necessary upgrades done -> normal growth again

Connection atte

mpts going up when new subscribers sign in, but...

...overall data volume is not growing -> end users have

s l o w e r services

1Q07 2Q07 1Q08 2Q08

Our caseCompetitor 1Competitor 2

HSDPA Subscriber growth

Source: InformaOctober 15, 2008

From 62% market share to 25% in 1

year


Why capacity management is needed

• Identify real bottlenecks in the network and address most serious issues first, keeping in mind that the network is a system

• Ensure efficient utilization of existing capacity• Employ new features in the most efficient way• Identify areas where capacity expansion is needed


Identify bottlenecks in the network

• The entire RAN network needs to be analysed

• If e.g. the DSP capacity isreached, itdoesn't help to add more carriers!

• Packet Core, IP backbone etc. should not be forgotten

User Plane

RNCUE WBTS

DNBAP

AAL2SIG

CNBAPPRACHFACH-c&u

DCH

AIR Interface IuB Interface

User Plane

Iur Interface

IuCS Interface

User Plane

SS7 (RANAP)

IuPS Interface

User Plane

User Plane

SS7 (RANAP)

PCH

CEResource

CodeCapacity

Throughput

Connectivity

Unit Load

DSP Usage

Scheduling capacity


Ensure efficient utilization of existing resources

• Network resources are not always used in the most efficient manner, so before investingin more resources, the utilization of existing resources should be optimised

• For example, shortage of UL channel elements or UL Iub capacity can be caused by badutilization of the UL radio bearer

• Rather than installing more capacity, features such as "Throughput Based Optimization" or “16 kbps UL return channel” should be used

UL return channel utilization

0%

5%

10%

15%

20%

25%

30%

35%

40%

1 week


Employ new features in most efficient way

• Activating new features are often associated with increased cost for the operator, eitherdirectly in terms of license fees or indirectly e.g. if more channel elements are needed

• In such cases, the features should only be activated where a performance gain can beexpected

• In the above example, activating the "HSDPA shared scheduler for basedband efficiency" will increase the air interface capacity dramatically, but that doesn't help so much if theIub instead becomes the bottleneck

Ratio of empty TTIs

0%

10%

20%

30%

40%

50%

60%

70%

Average DL Iub utilization

0%

20%

40%

60%

80%

100%

5 days


Identify areas where capacity expansion is needed

• Eventually, capacity expansions will be needed• Necessary to prioritise sites with regular usage rather than the occasional

traffic peak• KPI definitions and thresholds needed• Tools and processes to be established• Decide if all the requested traffic needs to be carried


<5% of users take 90% of the bandwidth

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Cluster size Volume share

100 GB - 1 TB10 GB - 100 GB1 GB - 10 GB100 MB - 1 GB<100 MB

<5% of the users…

…take 90% of the bandwidth

85% of users transfer data

less than 100MB/ month

Their share of the overall

data volume is less than 2%

You don’t want to give 90% of your capacity to a single user segment without differentiating in charging and QoS

Statistics from commercial HSDPA networks

You don’t want low value users/services to degrade performance for high value users/services


What is the traffic?

58%28%

14%

P2PWebOthers

• P2P: mainly adult entertainment and illegal video content• Web: browsing, gaming,...• Others: streaming, VoIP,...

Should we control P2P traffic so that it would not cause blocking?


Possible activities during a Capacity Managementservice• Parameter audit• Capacity KPI analysis

– Air interface, BTS, Iub, RNC, Iu-xx• Basic tuning of capacity related features/parameters

– For example Throughput Based Optimization, Transport Bearer Tuning etc.• Analysis of need for new features• Activation and follow up on new features• Advice to expand capacity where needed


Agenda




Available measurementsId MeasurementM1000 Cell resourceM1001 Service levelM1002 TrafficM1003 L3 signalling at IuM1004 L3 signalling at IurM1005 L3 signalling at IubM1006 RRC signallingM1007 Soft handoverM1008 Intra-system hard handoverM1009 L3 relocation signallingM1010 Inter-system handoverM1011 Location servicesM1012 Service area broadcastM1013 Autodef SHOM1014 Autodef IFHOM1015 Autodef ISHOM1016 RCPM OLPCM1017 RCPM RLCM1018 RCPM UEQM1020 A-GPS Server InterfaceM1021 Iupc InterfaceM1022 Packet CallM1023 Cell Throughput

RNW measurementsId MeasurementM5000 HSDPA in WBTSM5001 WBTS HW ResourceM5101 FTM PDH InterfaceM5102 FTM SDH InterfaceM5105 FTM ATM InterfaceM5106 FTM ATM VC ConnectionM5107 FTM ATM VP ConnectionM5110 FTM Ethernet LinkM5113 FTM Pseudowire MPLSM5114 FTM PSN Tunnel IP

WBTS measurements

Id MeasurementM5201 AXC PDHM5202 AXC SDHM5203 AXC IMA groupM5205 AXC ATMM5206 AXC ATM VC ConnectionM5207 AXC ATM VP ConnectionM5210 AXC EthernetM5212 AXC ATM PerformanceM5214 AXC PSN Tunnel IP

AXC measurements

Id MeasurementM512 Interface-specific TC M513 STM-1 interface M514 IMA logical interface M516 SONET/SDH Protection Group M528 ATM layer performance M529 ATM Virtual Path Connection M530 ATM Virtual Channel ConnectionM531 ATM Route LoadM532 ATM InterfaceM545 AAL2 signalling protocol at NNI M546 SAAL signalling at UNI M547 AAL5 protocol in DMXM548 AAL2 signalling protocol at UNI M549 AAL5 protocol in chorusM550 AAL2 path CAC resourceM552 AAL2 signalling at NNIM553 AAL2 Scheduling Performance in RNCM563 TCP/IP ProtocolM592 Unit load M594 WAC overload controlM608 Availability performance M613 DSP performance M800 AAL2 Resource Reservation M801 Iu-PS Performance

Platform measurements


Measurement activation

• By using theApplication Launcher, the measurements canbe started

– RNW and BTS measurements are started with the"RNW MeasurementManagement"

– Platformmeasurements are started with the "NE MeasurementExplorer"



List of available measurements

Measurement settings



Select themeasurement to be started/edited Not all interfaces

need to be includedin measurement

Start time can be specifiedwith minute-resolution


Measurement activation• RNW/BTS measurements will in general automatically include all possible objects

– For example, if M1000 (Cell Resource) measurement is started in one RNC, all cells willbe measured. If a new cell is created after the measurement is started, the new cell willautomatically be included in measurement

• Some platform measurements (e.g. M530, M550, M800 which are related to transport performance) do not automatically include all objects (all interfaces)

– When starting the measurements, "Add all" can be used to include all interfaces– When a new interface is taken into use (e.g. because a new BTS site is ready), the

measurement must be stopped, the new object added and the measurement startedagain

• By comparing the platform measurements with the RNW measurements orconfiguration tables, it is possible to check if platform measurements include allinterfaces


Measurement activation• RNW/BTS measurements are running in fixed measurement periods

– Starting the M1000 (Cell Resource) at 09:52 with 1 hour reporting interval means that themeasurement really starts at 10:00 and the first results are available at 11:00

• Platform measurements are by default started right away– Starting the M530 (ATM VCC) at 09:52 with 1 hour reporting interval means that the

measurement really starts at 09:52 and the first results are available at 10:52– This gives some practical problems when using counters from different measurements -

for example by comparing Iub rejections from M550 with Iub utilization from M530– Also possible to specify exact starting time (e.g. 10:00) for the platform measurements,

but this is not always done

VCC id Day Hour Minute EG_TOT_CELLS_VC1-23-40 20080905 12 6 21923891-23-40 20080905 12 21 23084051-23-40 20080905 12 36 22700421-23-40 20080905 12 51 25711771-23-40 20080905 13 6 26312581-23-40 20080905 13 21 30701101-23-40 20080905 13 36 32482741-23-40 20080905 13 51 26719001-23-40 20080905 14 6 27875781-23-40 20080905 14 21 3220564

VCC id Day Hour Minute AAL2_CAC_REJECTED1-23-40 20080905 12 9 61-23-40 20080905 12 24 421-23-40 20080905 12 39 31-23-40 20080905 12 54 181-23-40 20080905 13 9 271-23-40 20080905 13 24 01-23-40 20080905 13 39 421-23-40 20080905 13 54 421-23-40 20080905 14 9 151-23-40 20080905 14 24 0

M530: M550:


Missing data in the OSS DB

• It can happen that measurements are missing in OSS DB– Under dimensioned OSS?– Wrong setup?– RNC issues?

• Absolute KPIs like HSDPA payload pr day is very sensitive to missing data

• Relative KPIs like drop ratio not that sensitive - unless the missingdata tends to be e.g. in the busy hour

• Not always obvious that data is missing if looking at daily or busyhour values

• It is good to at least be aware if this happens in the network

M1001Day RNC1 RNC2 RNC320080901 23 24 2420080902 21 24 2420080903 24 24 2320080904 20 24 2420080905 18 24 2320080906 23 24 2420080907 24 24 2320080908 24 24 2420080909 24 24 2420080910 24 24 2120080911 23 24 1320080912 23 24 1220080913 24 24 1320080914 24 24 8

M1000Day RNC1 RNC2 RNC3

20080901 23 24 2420080902 21 24 2420080903 24 24 2320080904 20 24 2420080905 18 24 2320080906 23 24 2420080907 24 24 2320080908 24 24 2420080909 24 24 2420080910 24 24 2120080911 23 24 1320080912 23 24 1220080913 24 24 1320080914 24 24 8

M5000Day RNC1 RNC2 RNC320080901 24 24 2420080902 24 24 2420080903 24 24 2420080904 24 24 2420080905 24 24 2420080906 24 24 2420080907 24 24 2420080908 24 24 2420080909 24 24 2420080910 24 24 2420080911 24 24 2420080912 23 24 2420080913 24 24 2420080914 24 24 24

AMR Erlang, UMMT1

0

50

100

150

200

250

Sep 1 - Sep 9

Erla

ngs

RNC3, average UL power(averaged directly in dBm over the cells)

-104.0-103.5-103.0-102.5-102.0-101.5-101.0-100.5-100.0

Sep 1 - Sep 23


Traffica – Real-Time Traffic Monitoring and TroubleshootingLogging of events, e.g.• RRC establishments• RAB establishments• Soft HandoverDetailed information about each event, e.g.:• Timestamp• IMSI• UE capability• Wcell• Failure reasons• Call Phase• RANAP causes


Traffica – Real-Time Traffic Monitoring and TroubleshootingPeriodic reports that are produced with 60 second interval:• External AAL2 transport resource report for Resource use cases.• Internal AAL2 transport resource report for Resource use cases. With this report it is

possible to see for example the number of HSPA users per DMPG.• ATM VC Traffic report provides information on the transferred data on RNC external

ATM interfaces. This is related to Throughput use cases.• Call resource handling report. This report can be used for example to view the number

of services (SRB, RT, NRT, HSPA) in each ICSU• Call resource error code report. This report shows the number of most common error

codes related to call resource allocations, the reasons for errors can be for example DMPG resource shortage or Iub congestion.

Information is provided on both transport and radio layer:• For example external ATM VC counter, AAL2 path CAC statistics, Internal CAC

statistics• For example call handling counters.


Areas to monitor

• WCDMA network interfaces and internal resources which should be monitored

• But also areasoutside the RAN (IP backbone, PS Core etc.) can be a bottleneck

User Plane

RNCUE WBTS

DNBAP

AAL2SIG

CNBAPPRACHFACH-c&u

DCH

AIR Interface IuB Interface

User Plane

Iur Interface

IuCS Interface

User Plane

SS7 (RANAP)

IuPS Interface

User Plane

User Plane

SS7 (RANAP)

PCH

CEResource

CodeCapacity

Throughput

Connectivity

Unit Load

DSP Usage

Scheduling capacity


Proactive vs Reactive KPIs

• Capacity KPIs can generally be grouped into– Proactive KPIs: How much of the resource is utilised (e.g. code utilization)– Reactive KPIs: How often is there blocking, packet drops etc (e.g. code

blocking)

Capacity limit


Trendlining

• In order to expand the capacity before the network becomes congested, it's common practice to predict future traffic based on the previous traffic growth

• This requires at least a couple of months of reference data• Also, analysing the impact of network changes may require more than a couple of weeks' data

• => The 1 to 2 weeks' data in standard NetAct DB is not enough, some other solution is needed

0.0%

5.0%

10.0%

15.0%

20.0%

25.0%

30.0%

35.0%

40.0%

45.0%

50.0%

03.0

8.20

08 0

0:00

05.0

8.20

08 2

1:00

08.0

8.20

08 1

8:00

11.0

8.20

08 1

5:00

14.0

8.20

08 1

2:00

17.0

8.20

08 0

9:00

20.0

8.20

08 0

6:00

23.0

8.20

08 0

3:00

26.0

8.20

08 0

0:00

28.0

8.20

08 2

1:00

31.0

8.20

08 1

8:00

03.0

9.20

08 1

5:00

06.0

9.20

08 1

2:00

09.0

9.20

08 0

9:00

12.0

9.20

08 0

6:00

15.0

9.20

08 0

3:00

18.0

9.20

08 0

0:00

20.0

9.20

08 2

1:00

23.0

9.20

08 1

8:00

26.0

9.20

08 1

5:00

29.0

9.20

08 1

2:00

02.1

0.20

08 0

9:00

05.1

0.20

08 0

6:00

V CC Ut ilisat ionW eekDay M axLinear (W eekDay M ax )


The busy hour question (I)

• If counters/KPIs are stored in off-line databases, the time aggregation needs to be decided

– Store all hours. Good visibility but requires lots of disk space– Daily. Limited storage space needed, but pretty useless for capacity

monitoring– Busy hour. Limited storage space needed, but how to define busy hour? Also

some loss of visibility


The busy hour question (II)The NetAct approach• NetAct can be configured so it automatically generates a series of summary tables

– Smaller size than original data, so can be kept longer in DB– Easier to dump to text files in case detailed analysis of counters is needed

• For example for Service Level (M1001) measurements:– NOKRWW_PS_SERVLEV_MNC1_RAW has object level = WCELL and time resolution =

measurement period, e.g. 1 hour– The following summary tables can be configured

▪ NOKRWW_PS_SERVLEV_WCEL_DAY▪ NOKRWW_PS_SERVLEV_WCEL_WEEK▪ NOKRWW_PS_SERVLEV_WCEL_BH▪ NOKRWW_PS_SERVLEV_WCEL_WEEKBH▪ NOKRWW_PS_SERVLEV_RNC_DAY▪ NOKRWW_PS_SERVLEV_RNC_WEEK▪ NOKRWW_PS_SERVLEV_RNC_BH▪ NOKRWW_PS_SERVLEV_RNC_WEEKBH


• Different busy hour criterias depending on the measurement– Described in "Database Description for RNC Measurements: Summary Tables"=> Hassle when trying to combine counters

• For most measurements, the criteria is the hour with the highest DL R99 traffic– Not suitable in 3G networks where majority of traffic is HSDPA (in some networks in

LAM, more than 99% of the carried traffic is HSDPA)

The busy hour question (III)The NetAct approach

Hourly traffic distribution, cell X, 1 day

0

50

100

150

200

250

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

MBy

te/h

our

DL R99DL HSDPA

NetAct BH


The busy hour question (IV)The need for hourly data• Often, it is useful to have hourly data available

– Check if resources are released in low traffic hours– Interference behaviour– Etc.

• In the example below, BTS x behaves normally, i.e. the CE usage in night timefalls down to 106 (Common channels + Shared scheduler) - BTS y uses at least186 CEs all the time

BTS x

0

50

100

150

200

250

Nov 16 - 17

AVG_AVAIL_CEMAX_USED_CE_DLMAX_USED_CE_ULMIN_USED_CE_DLMIN_USED_CE_UL

BTS y

0

50

100

150

200

250

Nov 16 - 17

MIN_AVAIL_CEAVG_AVAIL_CEMAX_USED_CE_DLMAX_USED_CE_ULMIN_USED_CE_DLMIN_USED_CE_UL


Agenda




Air interface

The following items should be monitored:• Control channels - not included in this workshop

– RACH-c and RACH-u– FACH-c and FACH-u– PCH– SCCPCH power load

• R99 DCH– Tx Power - not included in this workshop– Received noise– DL spreading codes

• HS-DSCH– Radio link quality (CQI)– Radio link utilization (TTIs)– HSDPA cell throughput

• E-DCH (HSUPA) - not included in this workshop


Air interface - Release 99 traffic channels


• BTS reports total UL interference (RSSI) with a resolution of 0.1 dB with the range [-112, ...,-50] dBm

• The counters are already average value (no need to divide by the denom) in Watt

• The value in dBm can be obtained by formula: -112.0dBm + (RSSI_LEV)/10

UL DCH - PrxTotal measurements

X = collected sample of PrxTotal measurement


Available counters




• The Time in class X KPI is the percentage of time the cell has been in class X .

• The KPI is dependent on the parameters PrxTarget and PrxOffset• KPI pretty much useless if UL Admission Control has been disabled by

setting PrxTarget = 30 dB

[ ]%100__

__

_

×∑

= ClassesAllkkDENOMPRXTOT

XDENOMPRXTOT



The Average PrxTotal KPI is the average UL received interference power in absolute terms.

This KPI may be used to identify sites which are experiencing:• high uplink traffic load, • high background interference, • high uplink intercell interference

[ ]dBmkDENOMPRXTOT

kDENOMPRXTOTkCLASSPRXTOTAVEdBm) (in Load UL AverageRNC_101b

ClassesAllk

ClassesAllk

∑∑

=

=

×==

_

_

__

_____

Average done in Watt scale and then convert to dBm



• The AVE_PRX_NOISE counter results represent the uplink interference when the cell is unloaded.

• PrxNoise KPI is meaningful only when PrxNoise auto-tuning is enabled and counter results reflect the tuned value. Increases in uplink interference are calculated relative to PrxNoise, e.g. PrxTarget is defined relative to PrxNoise.

RNC_136a = AVE_PRX_NOISE (M1000C10)

• Message and AVE_PRX_NOISE gets the previous unloaded value in case coming PrxTotal value does NOT fulfill the unloaded conditions


UL noise rise• Based on the Prx counters in the Cell Resource measurement, the noise rise (in dB) can

be calculated as Noise rise = Prx - Noise Floor

= rnc_101b - rnc_136a

• This can be converted to fractional load (%) by the following formulaLoad = 1 - 10-Noise rise/10

• For example, noise rise of 3 (dB) corresponds to UL load of 50%• Also other things than traffic can increase the noise rise, such as external interference,

HW problem, UE power control problems, missing neighbours etc. An example with onecell is shown below

• However, even if the noise rise is caused by something else than traffic, it is still a problem for Admission Control!

Example of noise rise caused by something else than traffic

0

5

10

15

20

25

June 16 - June 22, hourly resolution

Noi

se r

ise

(dB

)


UL noise rise

• The chart below shows the UL load of the cells in the busy hour of a network• In the example below, it can be expected that the "load" of many of the cells to the right

side of the chart is in fact caused by something else than traffic• This analysis method will therefore tend to overestimate the UL load• Further analysis needed to determine if the proper solution is to hunt for interference

sources or add more carriers

Example of Load calculation based on noise rise

0%

10%

20%

30%

40%

50%

60%

0%

20%

40%

60%

80%

100%


Load Estimation

• To avoid the problems with power spikes, an alternative way to estimate the UL load is to use the RNC's internal load estimation - this is available in the Lrt and Lnrt counters

• In most LAM networks, the data traffic is dominant (in several networks >99% of thedownlink traffic is HSDPA), and it can therefore be expected that the utilization (the"Activity Factor") of the UL R99 radio channels is small

• The RNC does not take the activity factor into account when estimating the load, this hasto be done manually in the postprocessing

• The activity factor from one LAM network has been estimated to 20% by comparing theduration counters in M1002 with the payload counters in M1017

• The difference between the fractional load provided by the counters (assuming 100% activity factor) and the real fractional load assuming a 20% activity factor is shown in thetable

Load provided by

counters

Actual load assuming AF

of 20%11.4% 2.5%20.8% 5.0%28.8% 7.5%35.7% 10.0%41.7% 12.5%46.9% 15.0%51.5% 17.5%55.6% 20.0%59.2% 22.5%62.5% 25.0%65.5% 27.5%68.2% 30.0%70.7% 32.5%72.9% 35.0%75.0% 37.5%76.9% 40.0%78.7% 42.5%80.4% 45.0%81.9% 47.5%83.3% 50.0%84.7% 52.5%85.9% 55.0%87.1% 57.5%88.2% 60.0%89.3% 62.5%90.3% 65.0%91.2% 67.5%92.1% 70.0%92.9% 72.5%93.8% 75.0%94.5% 77.5%95.2% 80.0%95.9% 82.5%96.6% 85.0%97.2% 87.5%97.8% 90.0%98.4% 92.5%99.0% 95.0%99.5% 97.5%WR

RL fractional +=

ρρ Where:

•ρ is the received Eb/No•R is the service bit rate•W is 3.84 Mbps

M1000C24 AVE_LRT_CLASS_0 M1000C25 LRT_DENOM_0 M1000C26 AVE_LRT_CLASS_1 M1000C27 LRT_DENOM_1 M1000C28 AVE_LRT_CLASS_2 M1000C29 LRT_DENOM_2 M1000C30 AVE_LRT_CLASS_3 M1000C31 LRT_DENOM_3 M1000C32 AVE_LRT_CLASS_4 M1000C33 LRT_DENOM_4 M1000C34 AVE_LNRT_CLASS_0 M1000C35 LNRT_DENOM_0 M1000C36 AVE_LNRT_CLASS_1 M1000C37 LNRT_DENOM_1 M1000C38 AVE_LNRT_CLASS_2 M1000C39 LNRT_DENOM_2 M1000C40 AVE_LNRT_CLASS_3 M1000C41 LNRT_DENOM_3 M1000C42 AVE_LNRT_CLASS_4 M1000C43 LNRT_DENOM_4


Noise Rise vs Load Estimation

• If the noise rise triggers an investigation, the "load estimation" KPI can be a way to check if the noise rise is caused by traffic or by something else

Load based on noise rise, 20:00 - 21:00

0%

10%

20%

30%

40%

50%

60%

0%

20%

40%

60%

80%

100%

Load estimation incl. AF, 20:00 - 21:00

0%10%20%30%40%50%60%70%80%90%

0%

20%

40%

60%

80%

100%


Radio interface KPIs – DL Code reservationA single downlink scrambling code supports an OVSF code tree containing 1020 codes (based upon spreading factors from 4 to 512)

SF = 128

SF = 256

SF = 64

SF = 32

SF = 8

SF = 16

SF = 4

SF = 2

SF = 1

Codes for the cell common channels

Code for oneHS-SCCH

Codes for 5HS-PDSCH's

4 codes (SF 128) reserved for the common channels without HSDPAAt least 45 codes (SF 128) reserved for the common channels and HSDPA⇒ Introduction of HSDPA increase possibility of code blocking⇒ Codes are reserved for HSDPA always when HSDPA is enabled in the cell


Radio interface KPIs - DL Code reservation• Code tree occupancy KPI can be used for code blocking. KPI provides an indication of the percentage of codes

which are either used or blocked. Channelisation codes assigned to both the common and dedicated downlink channels are included for the KPI

• Both counters are updated every 1 s• Also counters for min and max occupancy

• Code Blocking KPI formula could be calculated from counters which are triggered when no codes of SF X (X=4,8,…256) are available and from counter which is incremented when the code is successfully allocated

• Code blocking pr spreading factor, e.g. for SF128:

NO_CODES_AVAILABLE_SF128 / CHAN_CODE_SF128_REQUEST

Note: These counters are triggered by initial RB setup as well as RB reconfiguration!

( )( ) [%]100

______113_ x

CAPACITYCODEDENOMsumCAPACITYCODEsumoccupancyTreeCodeaRNC =

[ ]%100_______

____ 256

4

256

4 ×+

=

∑

∑

=

=

x

x

SFxAVAILABLECODESNOALLOTREECODESUCCNBR

SFxAVAILABLECODESNOBlockingCode


Case study: Low HS-DSCH accessibility leads to DL code blocking (more details in the BTS section)

• Low HS-DSCH accessibility in the site meant that many UEshad to use R99 channels, and this lead to spreading code congestion

• Shared HSDPA Scheduler introduced on Oct 13 improved HS-DSCH accessibility and therefore less R99 channels were needed

• Despite the use of 10 codes for HS-DSCH, overall code blocking almost disappeared

=> Better to push traffic to HS-DSCH than start to worry about code blocking

Requests for DL spreading codes, BTS x

0

10000

20000

30000

40000

50000

60000

70000

Oct 6 - Oct 19

CHAN_CODE_SF256_REQUESTCHAN_CODE_SF128_REQUESTCHAN_CODE_SF64_REQUESTCHAN_CODE_SF32_REQUESTCHAN_CODE_SF16_REQUESTCHAN_CODE_SF8_REQUEST

Code reservations, BTS x

0%

20%

40%

60%

80%

100%

Oct 6 - Oct 19

NO_CODES_AVAILABLE_SF256NO_CODES_AVAILABLE_SF128NO_CODES_AVAILABLE_SF64NO_CODES_AVAILABLE_SF32NO_CODES_AVAILABLE_SF16NO_CODES_AVAILABLE_SF8NBR_SUCC_CODE_TREE_ALLO

HS-DSCH code availability, BTS x

0%

20%

40%

60%

80%

100%

Oct 6 - Oct 19

DURA_HSDPA_10_CODEDURA_HSDPA_9_CODEDURA_HSDPA_8_CODEDURA_HSDPA_7_CODEDURA_HSDPA_6_CODEDURA_HSDPA_5_CODE

HS-DSCH accessibility, BTS x

0%

20%

40%

60%

80%

100%

Oct 6 - Oct 19

Max usersIub 384 kbpsIub 128 kbpsIub 64 kbpsIub 16 kbpsBTSUEDL IubRNCAC (UL)Success

Max code blocking, w37

0%10%20%30%40%50%60%70%80%90%

Cells


Setup failures due to Admission Control• Admission Control rejects the establishment of a new RRC connection• Due to

– UL power– DL power– DL codes

• Formula:RRC_CONN_STP_FAIL_AC / RRC_CONN_STP_ATT

RRC setup failures due to AC

0.0004%0.0059%

0.0750%

0.00%

0.01%

0.02%

0.03%

0.04%

0.05%

0.06%

0.07%

0.08%

Network 1 Network 2 Network 3


Setup failures due to Admission Control• Admission Control rejects the establishment of a new voice RAB connection• Due to

– UL power– DL power– DL codes

• Formula:RAB_STP_FAIL_CS_VOICE_AC / RAB_STP_ATT_CS_VOICE

Voice RAB setup failures due to AC

0.0014%

0.0034%

0.0000%0.0000%

0.0005%

0.0010%

0.0015%

0.0020%

0.0025%

0.0030%

0.0035%

0.0040%



Setup failures due to Admission Control• Admission Control rejects the establishment of a new HS-DSCH connection (the UL return

channel is rejected)• Due to

– UL power• Formula:

REJ_HS_DSCH_RET_INT + REJ_HS_DSCH_RET_BGR--------------------------------------------------------------------------------------------------------------------------------------------------------ALLO_HS_DSCH_FLOW_INT + ALLO_HS_DSCH_FLOW_BGR + DCH_SEL_MAX_HSDPA_USERS_INTDCH_SEL_MAX_HSDPA_USERS_BGR + REJ_HS_DSCH_RET_INT + REJ_HS_DSCH_RET_BGRSETUP_FAIL_RNC_HS_DSCH_INT + SETUP_FAIL_IUB_HS_TOTAL_INT + SETUP_FAIL_UE_HS_DSCH_INTSETUP_FAIL_BTS_HS_DSCH_INT + SETUP_FAIL_RNC_HS_DSCH_BGR + SETUP_FAIL_IUB_HS_TOTAL_BGRSETUP_FAIL_UE_HS_DSCH_BGR + SETUP_FAIL_BTS_HS_DSCH_BGR

HS-DSCH setup failures due to AC

0.0021%

1.6355%

0.0496%0.0%0.2%0.4%0.6%0.8%1.0%1.2%1.4%1.6%1.8%



Setup failures due to Admission Control• Admission Control rejects the establishment of a new PS radio bearer• Request may be for HSUPA, HSDPA or R99. Outcome is nothing• Due to

– UL power– DL power– DL codes– Too many users in scheduler

• Formula:PS_SETUP_FAIL_AC_INT + PS_SETUP_FAIL_AC_BGR

-----------------------------------------------------------------------------------------------------------------------------------------PS_ATT_HSDSCH_EDCH_INT + PS_ATT_HSDSCH_EDCH_BGR + PS_ATT_HSDSCH_DCH_INTPS_ATT_HSDSCH_DCH_BGR + PS_ATT_DCH_DCH_INT + PS_ATT_DCH_DCH_BGR

PS setup failures due to AC

8%

0%1%2%3%4%5%6%7%8%9%



Air interface - HS-DSCH


HSDPA considerations

• Whenever HSDPA is used, the maximum available power for HSDPA will be used (in RAS06, RU10 will have power control for HS-DSCH)

• This means that a KPI like "Average used HSDPA power" is a bit meaningless

• Instead the following methods can be used– TTI (Transmission Time Interval) utilization: Tells if the traffic is so high that the

available cell capacity is being used in the time domain– CQI: Tells about the DL radio link quality and therefore how much payload that

potentially can be transmitted in a TTI– HSDPA Cell throughput: Tells how payload there actually is transmitted in a

TTI


TTI utilization

• During 1 hour, there are 500 * 3600 = 1800000 TTIs (Transmission Time Intervals) available for each carrier

• Number of used TTIs:

HS_SCCH_PWR_DIST_CLASS_0 + HS_SCCH_PWR_DIST_CLASS_1 +HS_SCCH_PWR_DIST_CLASS_2 + HS_SCCH_PWR_DIST_CLASS_3 +HS_SCCH_PWR_DIST_CLASS_4 + HS_SCCH_PWR_DIST_CLASS_5


TTI utilization

In case of high TTI utilization:• Increase available TTIs

– New carrier– New sector– New site

• Use existing TTIs more efficiently

– 10/15 codes – Code multiplexing– Improve CQI – Remove other bottlenecks, e.g.

Iub or HLR restrictions, such that the transport blocks can be filled up

Used TTIs, cell x

0200000400000600000800000

10000001200000140000016000001800000

Sep 1 - Sep 14

Max TTI utilization, RNC2, Sep 1 - Sep 7

0200000400000600000800000

10000001200000140000016000001800000

Cells


CQI mapping (Cat 7/8) (NSN implementation)

• CQI in table is "compensated" CQI• TTI duration is 2 ms, so 500 TTIs

pr second• Physical layer throughput is

roughly TB size * 500• DIfference between measured and

compensated CQI is ~2 to 3 dB in RAS06

• Depends also on UE capability (equalizer, 2 receivers)


0.00%

2.00%

4.00%

6.00%

8.00%

10.00%

12.00%

14.00%

16.00%

18.00%

CQI_DIST_C

L_0 (

Hsdpa

w)

CQI_DIST_CL_

1 (Hsd

paw)

CQI_DIST_C

L_2 (H

sdpa

w)

CQI_DIST_C

L_3 (H

sdpa

w)

CQI_DIST_C

L_4 (

Hsdpa

w)

CQI_DIST_CL_

5 (Hsd

paw)

CQI_DIST_C

L_6 (H

sdpa

w)

CQI_DIST_CL_

7 (Hsd

paw)

CQI_DIST_C

L_8 (H

sdpa

w)

CQI_DIST_C

L_9 (H

sdpa

w)

CQI_DIST_C

L_10

(Hsd

paw)

CQI_DIST_CL_

11 (Hsd

paw)

CQI_DIST_C

L_12

(Hsd

paw)

CQI_DIST_CL_

13 (Hsd

paw)

CQI_DIST_C

L_14 (

Hsdpa

w)

CQI_DIST_C

L_15

(Hsd

paw)

CQI_DIST_C

L_16

(Hsd

paw)

CQI_DIST_CL_

17 (Hsd

paw)

CQI_DIST_C

L_18 (

Hsdpa

w)

CQI_DIST_C

L_19

(Hsd

paw)

CQI_DIST_C

L_20 (

Hsdpa

w)

CQI_DIST_C

L_21

(Hsd

paw)

CQI_DIST_C

L_22 (

Hsdpa

w)

CQI_DIST_CL_

23 (Hsd

paw)

CQI_DIST_C

L_24 (

Hsdpa

w)

CQI_DIST_C

L_25

(Hsd

paw)

CQI_DIST_CL_

26 (Hsd

paw)

CQI_DIST_C

L_27 (

Hsdpa

w)

CQI_DIST_C

L_28 (

Hsdpa

w)

CQI_DIST_C

L_29

(Hsd

paw)

CQI_DIST_C

L_30 (

Hsdpa

w)

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

%CDF

Median CQI (of reported values) = 18, which indicates relatively good quality HSDPA network

CQI distribution


CQI distributionScaled CQI Distribution by +4 dB for 1-rx Equalizer Terminals

0.00%

2.00%

4.00%

6.00%

8.00%

10.00%

12.00%

14.00%

16.00%

18.00%

CQI_DIST_C

L_0 (

Hsdpa

w)

CQI_DIST_C

L_1 (

Hsdpa

w)

CQI_DIST_C

L_2 (

Hsdpa

w)

CQI_DIST_C

L_3 (

Hsdpa

w)

CQI_DIST_C

L_4 (

Hsdpa

w)

CQI_DIST_C

L_5 (

Hsdpa

w)

CQI_DIST_C

L_6 (

Hsdpa

w)

CQI_DIST_C

L_7 (

Hsdpa

w)

CQI_DIST_C

L_8 (

Hsdpa

w)

CQI_DIST_C

L_9 (

Hsdpa

w)

CQI_DIST_C

L_10

(Hsd

paw)

CQI_DIST_C

L_11

(Hsd

paw)

CQI_DIST_C

L_12

(Hsd

paw)

CQI_DIST_C

L_13

(Hsd

paw)

CQI_DIST_C

L_14

(Hsd

paw)

CQI_DIST_C

L_15

(Hsd

paw)

CQI_DIST_C

L_16

(Hsd

paw)

CQI_DIST_C

L_17

(Hsd

paw)

CQI_DIST_C

L_18

(Hsd

paw)

CQI_DIST_C

L_19

(Hsd

paw)

CQI_DIST_C

L_20

(Hsd

paw)

CQI_DIST_C

L_21

(Hsd

paw)

CQI_DIST_C

L_22

(Hsd

paw)

CQI_DIST_C

L_23

(Hsd

paw)

CQI_DIST_C

L_24

(Hsd

paw)

CQI_DIST_C

L_25

(Hsd

paw)

CQI_DIST_C

L_26

(Hsd

paw)

CQI_DIST_C

L_27

(Hsd

paw)

CQI_DIST_C

L_28

(Hsd

paw)

CQI_DIST_C

L_29

(Hsd

paw)

CQI_DIST_C

L_30

(Hsd

paw)

Should the Iub support 50% throughput probability or 70% or 90%? Depends how much is the Iub cost and how much there is traffic that generates revenue


CQI distribution

• Higher CQI means higher throughput– Increased cell capacity– Increased end-user perception

• Low CQI can be caused by– Site is not close to the UEs– UEs are in bad radio coverage– High interference in the area– Etc.

CQI distribution

0%5%

10%15%20%25%

30%35%

RNC1Worst cellBest cell


UE impact on CQI distribution

• The UE is calculating the CQI it sends to the network• Some differences between UEs - in above chart, the N95 reports ~2 dB better

CQI than the datacard• Better RF implementation or just different CQI reporting?


Code/modulation counters• M5000 family has counters for how the PDUs are sent to the UEs

– Initial transmission, QPSK, 1 - 15 codes (M5000C49 - M5000C53, M5000C86 - M5000C95)– Initial transmission, 16QAM, 1 - 15 codes (M5000C54 - M5000C58, M5000C96 - M5000C105)– Retransmissions, QPSK, 1 - 15 codes (M5000C59 - M5000C63, M5000C106 - M5000C115)– Retransmissions, 16QAM, 1 - 15 codes (M5000C64 - M5000C68, M5000C116 - M5000C125)

• Not impacted by code multiplexing– For example, sending to 2 x Cat 1/6 UEs (UE capability is 5 codes) within same TTI

(therefore using 10 codes) will update the 5-code counter twice– Activating code multiplexing will not change these counters

• The 6 - 10 code counters will only be pegged in case of cat 7/8 UEs• The 11 - 15 code counters will only be pegged in case of cat 9/10 UEs• Can be compared with the CQI counters to show how well the quality of the

radio interface is used


Code/modulation counters vs CQI distribution• From CQI counters and the mapping table between CQI and Transport Block

Size, it can be predicted which combination of codes/modulation that will be used

• This can then be verified against the actual counters

• In this case, the radio link quality is not fully used (Iub congestion, HLR limitations, applications?)

CQI vs actual code usage - cell x

0%10%20%30%40%50%60%70%80%90%

1 - Q

PS

K

2 - Q

PS

K

3 - Q

PS

K

4 - Q

PS

K

5 - Q

PS

K

6 - Q

PS

K

7 - Q

PS

K

8 - Q

PS

K

9 - Q

PS

K

10 -

QP

SK

10 -

16Q

AM

CQI - no compensationCQI - 3 dB compensationActual


HSDPA cell throughput

• The cell throughput can also be directly measured with rnc_722b– Some relationship with the code/modulation distribution– This formula takes code multiplexing into account

• Same issues as with the code/modulation distributions– If data is not arriving fast enough to the BTS buffers, lower number of codes will be

used and throughput will be smaller

RNC_722b [kbps] =( )

500SS_5)R_DIST_CLAHS_SCCH_PW M5000C74SS_4R_DIST_CLAHS_SCCH_PW M5000C73SS_R_DIST_CLAHS_SCCH_PW M5000C72SS_2R_DIST_CLAHS_SCCH_PW M5000C71SS_1R_DIST_CLAHS_SCCH_PW M5000C70SS_0R_DIST_CLAHS_SCCH_PW M5000C69

1000

TSHS_MACD_BIDISCARDED_ M5000C127 -SS_MACD_BITRECEIVED_H M5000C126

∑∑

++

+++

⋅3

Application rnc_722bFTP DL 5838FTP UL 420HTTP Browsing 3558WAP Browsing 1213Streaming 160 kbps 2816

• Some dependency between rnc_722b and the applications which are being used


Summary

• High TTI utilization => Find more TTIs– New carrier– New sector– New site

• Bad CQI (DL radio link quality) => Improve radio link quality– More power (e.g. 20W => 40W)– Better coverage (new site, antenna adjustments, etc.)– Reduce interference (antenna adjustments)

• Bad usage of radio link quality => Improve usage– 10/15 codes– Code multiplexing– Remove other bottlenecks


Agenda




BTS resource issues

• Are there enough Channel Elements?• Does the HSDPA scheduler have enough capacity?


WBTS KPI – CE Availability• CE Availability Example - FlexiBTS• The FlexBTS with 1+1+1 configuration has licensed capacity 160 CE + 32 CE basic

capacity.• Example 1: The configured situation is stable over the measurement period.

▪ M5001C0 MAX_AVAIL_CE= 192▪ M5001C1 MIN_AVAIL_CE = 192▪ M5001C2 AVE_AVAIL_CE = 192

If there are WSPC cards e.g added or blocked during measurement period,

it can be seen hereCE Availability Example

Available Capacity means Licensed CE’s not free CE or installed CE

Sampling periodis 20 seconds!


WBTS KPIs – CE Availability KPI

Average ratio of utilized CE for DL/UL can be used to monitor Channel Element Utilization separately for UL and DL.RNC_730a calculates DL CE utilization

RNC_731a calculates UL CE utilization

( )( )CEAVAILAVEsum

DLCEUSEDAVEsumaRNC__

___*100BTSin DLfor CE utilized of ratio Average_730_ =

( )( )CEAVAILAVEsum

ULCEUSEDAVEsumaRNC__

___*100BTSin for UL CE utilized of ratio Average_731_ =


Use of channel elements

• Cell Resource measurement (M1000) has counters for what the channelelements are used for

• M1000 is on cell level, while CE use only makes sense on BTS level– Each cell within one BTS has same value in the counters listed below– If e.g. aggregation on RNC level is needed: First average cell level to BTS level, then

sum to RNC level• M1000 counters are based on the RNC estimation of used CEs. Not as accurate

as M5001 countersCounter id Counter name Counter id Counter name Counter id Counter nameM1000C181 CE_SAMPLE_AMOUNT M1000C196 AVE_CE_USED_PS_STR_256_DL M1000C211 AVE_CE_USED_PS_INT_384_DL M1000C182 AVE_CE_USED_AMR M1000C197 AVE_CE_USED_PS_STR_384_DL M1000C212 AVE_CE_USED_PS_BGR_8_UL M1000C183 AVE_CE_USED_CS_CONV_64 M1000C198 AVE_CE_USED_PS_INT_8_UL M1000C213 AVE_CE_USED_PS_BGR_16_UL M1000C184 AVE_CE_USED_CS_STR_14_4 M1000C199 AVE_CE_USED_PS_INT_16_UL M1000C214 AVE_CE_USED_PS_BGR_32_UL M1000C185 AVE_CE_USED_CS_STR_57_6 M1000C200 AVE_CE_USED_PS_INT_32_UL M1000C215 AVE_CE_USED_PS_BGR_64_UL M1000C186 AVE_CE_USED_PS_STR_8_UL M1000C201 AVE_CE_USED_PS_INT_64_UL M1000C216 AVE_CE_USED_PS_BGR_128_UL M1000C187 AVE_CE_USED_PS_STR_16_UL M1000C202 AVE_CE_USED_PS_INT_128_UL M1000C217 AVE_CE_USED_PS_BGR_256_UL M1000C188 AVE_CE_USED_PS_STR_32_UL M1000C203 AVE_CE_USED_PS_INT_256_UL M1000C218 AVE_CE_USED_PS_BGR_384_UL M1000C189 AVE_CE_USED_PS_STR_64_UL M1000C204 AVE_CE_USED_PS_INT_384_UL M1000C219 AVE_CE_USED_PS_BGR_8_DL M1000C190 AVE_CE_USED_PS_STR_128_UL M1000C205 AVE_CE_USED_PS_INT_8_DL M1000C220 AVE_CE_USED_PS_BGR_16_DL M1000C191 AVE_CE_USED_PS_STR_8_DL M1000C206 AVE_CE_USED_PS_INT_16_DL M1000C221 AVE_CE_USED_PS_BGR_32_DL M1000C192 AVE_CE_USED_PS_STR_16_DL M1000C207 AVE_CE_USED_PS_INT_32_DL M1000C222 AVE_CE_USED_PS_BGR_64_DL M1000C193 AVE_CE_USED_PS_STR_32_DL M1000C208 AVE_CE_USED_PS_INT_64_DL M1000C223 AVE_CE_USED_PS_BGR_128_DL M1000C194 AVE_CE_USED_PS_STR_64_DL M1000C209 AVE_CE_USED_PS_INT_128_DL M1000C224 AVE_CE_USED_PS_BGR_256_DL M1000C195 AVE_CE_USED_PS_STR_128_DL M1000C210 AVE_CE_USED_PS_INT_256_DL M1000C225 AVE_CE_USED_PS_BGR_384_DL



• As normal for HSDPA-dominated networks, it is usually the UL channel elements that is the bottleneck (due to the UL returnchannel)

• Permanently reserved CEs in this BTS:– Control channels (3 sectors, no extended cell) 26– Shared HSDPA Baseband Scheduler 80

BTS x, DL CE usage (M5001 counters)

0

50

100

150

200

250

300

350

Nov 3 - Nov 9

AVG_AVAIL_CEMAX_USED_CE_DLMIN_USED_CE_DLAVG_USED_CE_DL

BTS x, UL CE usage (M5001 counters)

0

50

100

150

200

250

300

350

Nov 3 - Nov 9

AVG_AVAIL_CEMAX_USED_CE_ULMIN_USED_CE_ULAVG_USED_CE_UL



• Some CE usage cannot be seen with M1000 counters– Common channels (e.g. 26 in UL & DL)– HSDPA scheduler (e.g. 32 or 80 in UL & DL)– HSDPA signalling channels (1 pr HSDPA user in DL)– CEs reserved for HSUPA

DL CE usage (M1000 counters)

0

2040

6080

100

120140

160

Nov 3 - Nov 9

AVE_CE_USED_PS_INT_384_DLAVE_CE_USED_PS_INT_256_DLAVE_CE_USED_PS_INT_128_DLAVE_CE_USED_PS_INT_64_DLAVE_CE_USED_PS_INT_32_DLAVE_CE_USED_PS_INT_16_DLAVE_CE_USED_PS_INT_8_DLAVE_CE_USED_AMR

UL CE usage (M1000 counters)

0

2040

6080

100

120140

160

Nov 3 - Nov 9

AVE_CE_USED_PS_INT_64_ULAVE_CE_USED_PS_INT_32_ULAVE_CE_USED_PS_INT_16_ULAVE_CE_USED_AMR


M1000 vs M5001• By adding 106 CEs to M1000 counters, they can be compared with M5001

– Good match in UL– In DL, M5001 shows significantly larger values than M1000 - because the CEs used

for HSDPA SRBs are not included in M1000=> By comparing UL counters, the number of CEs used "permanently" can be estimated

M1000 vs M5001 counters

0

50

100

150

200

250

300

Nov 3 - Nov 9

M1000 DLM5001 DLM1000 ULM5001 UL



• In HSDPA-dominated networks, it is usually the UL channelelements that is the bottleneck (due to the UL return channel)

• However, if R99 traffic is high, the bottleneck can also be in the DL• Before starting to install more CEs, check the utilization - maybe

something can be improved

UL return channel utilization

0%

5%

10%

15%

20%

25%

30%35%

40%

1 week


WBTS KPI – RRC/RAB Setup Failure RateThe Service level measurements can provide the first indication of BTS HW limitations The relevant KPIs to monitor are• RRC connection setup failure rate resulting from BTS• RAB setup failure rate resulting from BTS

• Also setup failure ratio of UL return channel is relevant to look at

SETUP_FAIL_BTS_HS_DSCH_INT + SETUP_FAIL_BTS_HS_DSCH_BGR------------------------------------------------------------------------------------------------------------ALLO_HS_DSCH_FLOW_INT + ALLO_HS_DSCH_FLOW_BGR + DCH_SEL_MAX_HSDPA_USERS_INT + DCH_SEL_MAX_HSDPA_USERS_BGR + REJ_HS_DSCH_RET_INT + REJ_HS_DSCH_RET_BGR + SETUP_FAIL_RNC_HS_DSCH_INT + SETUP_FAIL_UE_HS_DSCH_INT + SETUP_FAIL_BTS_HS_DSCH_INT + SETUP_FAIL_IUB_HS_TOTAL_INT + SETUP_FAIL_RNC_HS_DSCH_BGR + SETUP_FAIL_UE_HS_DSCH_BGR + SETUP_FAIL_BTS_HS_DSCH_BGR + SETUP_FAIL_IUB_HS_TOTAL_BGR

PI ExpressionThreshold to Trigger

detailed blocking analysisTime

Resolution

RRC Connection Setup Failure Rate resulting from BTS

100*(RRC_CONN_STP_FAIL_BTS/ RRC_CONN_STP_ATT)

1% 1 hour

RAB Setup Failure Rate resulting from BTS

100*(RAB_STP_FAIL_X_BTS/ RAB_STP_ATT_X)

1% 1 hour


Software bugs?

• Note that BTS failures can be caused by lack of CEs as well as many other reasons, e.g. sw bugs

• Just a few malfunctioning cells can impact the whole network statistics• Always correlate BTS failures with e.g. maximum used CEs to confirm if it is

capacity problems

Site Day RRC_CONN_STP_ATT RRC_CONN_STP_FAIL_BTSBTS x 20080901 2326 0BTS x 20080902 2238 0BTS x 20080903 2272 0BTS x 20080904 1663 0BTS x 20080908 6736 3370BTS x 20080909 73993 38659BTS x 20080910 67148 35618BTS x 20080911 54342 28048BTS x 20080912 25696 13646BTS x 20080913 2170 0BTS x 20080914 2029 0


Setup failures due to BTS, case 1

• In this case, the number of used channel elements are far below the capacity

=> Try site restart!

BTS failures vs CE usage, BTS x

0

1000

2000

3000

4000

5000

Sep 1 - Sep 14

RR

C a

ttem

pts

0

50

100

150

200

250

300

CEs

RRC_CONN_STP_ATTRRC_CONN_STP_FAIL_BTSAVG_AVAIL_CEMAX_USED_CE_DLMAX_USED_CE_UL



• In this case, BTS setup failures only happen when the CE usage is high=> Try optimizating CE usage, otherwise add more!

BTS failures vs CE usage

0

200

400

600

800

1000

1200

1400

Nov 3 - Nov 9

Setu

p fa

ilure

s

0

50100

150

200

250

300350

400

CEs

SETUP_FAIL_BTS_HS_DSCH_INTAVG_AVAIL_CEMAX_USED_CE_DLMAX_USED_CE_UL



• In this network, having higher CE utilization than 90% on average starts to produce problems

CE utilization vs HS-DSCH BTS setup failures192 CEs, Initial bitrate = 128 kbps

0%

20%

40%

60%

80%

100%

0% 20% 40% 60% 80% 100% 120%

Average UL CE utilization

Setu

p fa

ilure

s du

e to

BTS


Scheduler capacitySeveral types of HSDPA schedulers available• Basic scheduler in Node B

– 16 users pr Node B– Consumes 32 channel elements pr Node B– Only 5 codes can be used

• 16 users pr cell– Consumes 32 channel elements pr cell = 96 for a 3-sector Node B– Only 5 codes can be used

• Shared HSDPA scheduler for baseband efficiency in Node B (RAN1034)– Can serve up to 3 simultaneous users– 48 users pr Node B (16 or 48 users pr cell, depending on the "48 users pr cell feature" -

RAN1033)– Consumes 80 channel elements in Node B– 15 codes can be used (if RAN852 is enabled)

• Dedicated Scheduler (e.g. 1 for each cell)– 48 users pr scheduler– Consumes 80 channel elements pr scheduler = 240 for a 3-sector Node B– 15 codes can be used (if RAN852 is enabled)


Simultaneous users

Number of users with HS-DSCH radio bearer is given by:1.5 * DUR_HSDPA_USERS_1_OR_2 + 3.5 * DUR_HSDPA_USERS_3_OR_4 + 5.5 * DUR_HSDPA_USERS_5_OR_6

+ 7.5 * DUR_HSDPA_USERS_7_OR_8 + 9.5 * DUR_HSDPA_USERS_9_OR_10 + 11.5 * DUR_HSDPA_USERS_11_OR_12

+ 13.5 * DUR_HSDPA_USERS_13_OR_14 + 15.5 * DUR_HSDPA_USERS_15_OR_16 + 18.5 * DURA_HSDPA_USERS_17_TO_20

+ 22.5 * DURA_HSDPA_USERS_21_TO_24 + 26.5 * DURA_HSDPA_USERS_25_TO_28 + 30.5 * DURA_HSDPA_USERS_29_TO_32

+ 34.5 * DURA_HSDPA_USERS_33_TO_36 + 38.5 * DURA_HSDPA_USERS_37_TO_40 + 42.5 * DURA_HSDPA_USERS_41_TO_44

+ 46.5 * DURA_HSDPA_USERS_45_TO_48

rnc_645b = -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

DUR_HSDPA_NO_USERS + DUR_HSDPA_USERS_1_OR_2 + DUR_HSDPA_USERS_3_OR_4

+ DUR_HSDPA_USERS_5_OR_6 + DUR_HSDPA_USERS_7_OR_8 + DUR_HSDPA_USERS_9_OR_10

+ DUR_HSDPA_USERS_11_OR_12 + DUR_HSDPA_USERS_13_OR_14 + DUR_HSDPA_USERS_15_OR_16

+ DURA_HSDPA_USERS_17_TO_20 + DURA_HSDPA_USERS_21_TO_24 + DURA_HSDPA_USERS_25_TO_28

+ DURA_HSDPA_USERS_29_TO_32 + DURA_HSDPA_USERS_33_TO_36 + DURA_HSDPA_USERS_37_TO_40

+ DURA_HSDPA_USERS_41_TO_44 + DURA_HSDPA_USERS_45_TO_48


Rejection due to too many users

If there is no room for more HS-DSCH users, a DCH will be allocated instead:

rnc_614a = ALLO_HS_DSCH_FLOW_INT + ALLO_HS_DSCH_FLOW_BGR + DCH_SEL_MAX_HSDPA_USERS_INT + DCH_SEL_MAX_HSDPA_USERS_BGR + REJ_HS_DSCH_RET_INT + REJ_HS_DSCH_RET_BGR + SETUP_FAIL_RNC_HS_DSCH_INT + SETUP_FAIL_UE_HS_DSCH_INT + SETUP_FAIL_BTS_HS_DSCH_INT + SETUP_FAIL_IUB_HS_TOTAL_INT + SETUP_FAIL_RNC_HS_DSCH_BGR + SETUP_FAIL_UE_HS_DSCH_BGR + SETUP_FAIL_BTS_HS_DSCH_BGR + SETUP_FAIL_IUB_HS_TOTAL_BGR)

)614_(_ )__________(660_

aRNCALLOCTIONSHSDPABGRUSERSHSDPAMAXSELDCHINTUSERSHSDPAMAXSELDCHsumaRNC +

=

Note: the DCH_cel_max_HSDPA_users_int/bgr didn't work correctly inRN3.0 CD1.0: In case the basic scheduler was used (16 users pr BTS), thecounters would only be incremented if there were 16 users in one of thesectors, which naturally is an extremely rare event. From CD2.0, thesecounters work correctly


Nbr of users vs rejections

• Basic scheduler (16 users pr BTS)– Almost no rejections when number of users pr BTS is less than 10– When number of users reach ~12 (75% of capacity), the rejections starts to

increase dramatically• Shared Scheduler (48 users pr BTS, 48 users pr cell)

– Not so much reference data yet– Seems the rejections starts to increase at around 38 users (80% of

capacity)

Nbr of HS-DSCH users and rejections summarised over all the sectors of a BTSEach dot is one BTS in one hour1 RNC, 12 days


Case study: Shared HSDPA Scheduler

Expanding from basic scheduler to Shared Scheduler means:• Number of users increased from 16 pr cell/16 pr BTS to 16 pr cell/48 pr BTS• Feature "48 users pr cell" still needed to have more than 16 users pr cell• All 15 codes can be used instead of just 5• Up to 3 UEs can be served simultaneously instead of just 1• Needs 80 CEs instead of 32

The following slides show first a single site to better observe the effects on HS-DSCH accessibility, and then a group of 21 sites which got the Shared Scheduler installed


Shared HSDPA Scheduler in one high-traffic site

• BTS is heavily congested before Shared Scheduler is installed• CD2.0 brings correction to DCH_SEL_MAX_HSDPA_USERS_INT• Even the Shared Scheduler (16 users pr cell, 48 users pr BTS) is not enough to remove congestion. "48 users pr

cell" feature (48 users pr cell, 48 users pr BTS) is the next step

Nbr of HS-DSCH RBs, BTS x

0

10

20

30

40

Oct 13 - Nov 2

BTSSector 1Sector 2Sector 3


0%

20%

40%

60%

80%

100%

Oct 13 - Nov 2


CD1.0 => CD2.4 Shared Scheduler, PrxTarget set to 30 dB


Average nbr of HS-DSCH RBs pr BTS

0

10

20

30

40

Oct 13 - Nov 2

Shared HSDPA Scheduler in 21 high-traffic sites

• Before Oct 24, HS-DSCH setup failures are mainly too many users in the scheduler and UL admission control (for the return channel)• After Oct 24, UL AC rejections have virtually disappeared and the "too many users" cause has decreased significantly• Still, there are cases (>10% of the time in BH) where the 16 users/cell limit is reached => 48 users pr cell is needed• Some UL Iub blocking starts to appear => 16 kbps UL return channel is needed

CD1.0 => CD2.4 Shared Scheduler, PrxTarget set to 30 dB

HS-DSCH accessibility

0%

20%

40%

60%

80%

100%

O c t 13 - No v 2

Max usersIub 384 kbpsIub 128 kbpsIub 64 kbpsIub 16 kbpsBTSUEDL IubRNCAC (UL)SuccessNbr of HS-DSCH RBs pr cell

0%

20%

40%

60%

80%

100%

Oct 13 - Nov 2

15 or 1613 or 1411 or 129 or 107 or 85 or 63 or 41 or 2No users


Shared HSDPA Scheduler in 21 high-traffic sites

• Before the Shared Scheduler, only a bit less than 33% ofthe TTIs were used in BH, indicating that it is quite common that there are active UEs in all 3 sectors - afterthe installation of the Shared Scheduler, there will almostalways be transmission if any of the UEs in the cell hasdata waiting

• After the Shared Scheduler is installed, it transmits to all 3 sectors simultaneously in about 40% of the time in BH

• 60% of the time, the Shared Scheduler is not transmittingto 3 UEs - introduction of code multiplexing will have some benefits

TTI usage

0%10%20%30%40%50%60%70%80%90%

Oct 13 - Nov 2

Ratio of active TTIsRatio of missed TTIs

Simultaneous transmissions

0%

20%

40%

60%

80%

100%

Oct 13 - Nov 2

3 sectors2 sectors1 sector

Nbr of active HS-DSCH RBs(average pr cell)

0

0.5

1

1.5

2

2.5

3

3.5

Oct 13 - Nov 2


Case study: HSDPA 48 users pr cell

• RNC-level feature - requires license• Does not consume more Channel Elements• Increases capacity from "16 users pr cell/48 users pr BTS" to "48 users pr cell/48 users pr

BTS"• Does not require 16 kbps UL return channel


HSDPA 48 users pr cell - single BTS

• Shared Scheduler removed most serious bottleneck• 48 users pr cell took care of the rest - but soon 2nd scheduler will be needed


0%

20%

40%

60%

80%

100%

Oct 6 - Nov 9


Sharedscheduler 48 users pr cell

16 kbps UL ret

Number of HS-DSCH RBs, BTS x

0

10

20

30

40

50

Oct 6 - Oct 19

BTSSector 1Sector 2Sector 3


Agenda




• Both M530 and M5106 contain counters that allow us to calculate the usage of the Iub links

– M530 is optional– M530 covers Iub, Iur, Iu-CS, Iu-PS. M5106 covers Iub only– M530 also has counters that enable us to calculate cell loss in the ATM interfaces– Maximum 1024 VCCs can be monitored by M530

• AAL2 UP, AAL2 SIG, C-NBAP, D-NBAP, O&M VCCs are included in bothmeasurements

• Both measurements are needed to investigate Iub from both ends• For M530, separate mapping table between BTS/cell id and interface id is

needed

Usage - M530 vs M5106

Counter_id Counter nameperiod_start_timewbts_idftm_idvptt_idvcct_idperiod_duration

M5106C0 totCellsIngressVCM5106C1 totCellsEgressVC

Counter_id Counter namernc_idif_idvpi_idvci_idperiod_start_timeperiod_duration

M530C0 IN_TOT_CELLS_VCM530C1 EG_TOT_CELLS_VCM530C2 IN_REC_CELLS_VCM530C3 IN_QUEUED_CELLS_VCM530C4 IN_CAP_VCM530C5 EG_REC_CELLS_VCM530C6 EG_QUEUED_CELLS_VCM530C7 EG_CAP_VC


PI Name: Average VCC Load / Average VCC Utilization

Counter Table: ATM VCC Measurement

PI Expression: IN_TOT_CELLS_VC/ MEASUREMENT DURATIONEG_TOT_CELLS_VC/ MEASUREMENT DURATION 100 * IN_TOT_CELLS_VC/ MEASUREMENT DURATION / IN_CAP_VC100* EG_TOT_CELLS_VC/ MEASUREMENT DURATION / EG_CAP_VC

Units/Level: cps and %

Note: Iu-cs, Iu-ps and Iur VCCs can be measured as well.

PI DescriptionThis measurement reports the cells per VCC during measurement period. VCC measurements enable monitoring of ATM traffic for DNBAP, CNBAP, O&M and user plane VCCs on Iub. Average load in ingress and egress direction can be calculated dividing counter values by the measurement period. VCC Utilization level [%] can be calculated in RAS6 with new counters reporting VCC size.Note: the capacity counters are showing the MDCR in case of UBR+

Monitoring Type: Proactive

Iub Interface usage


AAL2 User Plane

• M530 can be used to monitor signalling (C-NBAP, D-NBAP, AAL2SIG, O&M) VCCs as well as User Plane VCCs

• This workshop only cover the user plane VCCs• In HSDPA networks, normal that DL utilization is higher than UL• There can still be plenty of failed Iub reservations due to UL congestion!

Max Iub utilization, w36, UP = 3706

0%

20%

40%

60%

80%

100%

Interface

DL utilisationUL utilisation

Max Iub utilization, w36, UP = 8197

0%

20%

40%

60%

80%

100%

Interface

DL utilisationUL utilisation


Iub utilisation thresholds

• M530/M529 measurement can be set up with measurement interval of• 15 minutes • 60 minutes

• Usually the used interval is 60 minutes • 15 minutes interval produces quite high amount of measurement

data• The VCC load can have quite a lot of variance during the

measurement period• The slides below show the variance of minute level data compared to

the hourly measurement result



SHARED CBR VCC PCR 10371 cpsHighest Average Load (hour)

0.000%

10.000%

20.000%

30.000%

40.000%

50.000%

60.000%

70.000%

80.000%

90.000%

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61

EGR

ESS

0.00000%

0.20000%

0.40000%

0.60000%

0.80000%

1.00000%

1.20000%

1.40000%

ING

RES

S

EGR Load/MinuteEGR Load/HourING Load/MinuteING Load/Hour

• The minute level load can be more than double of the hourly load• The UL Load is low (< 1.5% ) at all times

• The traffic is likely HSDPA• This VCC had the highest average load (M530) of all the Iub VCCs• The minute level results obtained by special arrangements



• The graph shows the peak to average ratio of 71 highest minute ATM load samples to the respective hourly ATM load.

• Less than 25% have a value higher than 2.5=> If the hourly average load is 40%, it is unlikely that the minute average load reaches 100%

Iub Egress Peak to Ave for sites which have > 50% minute level utilisation

0.000%

20.000%

40.000%

60.000%

80.000%

100.000%

1 234 56 78 91011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071

ATM

Loa

d

0

1

2

3

4

5

6

Min

ute

/ Hou

r Lo

ad R

atio

EGRLoad/MinuteEGRLoad/HourEGR Minute to Hour Ratio


Iub User Plane: AAL2 Path CAC Resource Measurement (M550)

• AAL2 connections are allocated and released by ATM Resource Management which will check AAL2 reservation using CAC.

• M550 measurement reports RNC CAC resource usage for Iub AAL2 user plane traffic downlink

– There can be more than one user plane VCC, this measurement is per VCC– Dedicated counters also for HSDPA

• RNC CAC controls resources in downlink direction from RNC to WBTS– Uplink CAC functionality is located in the BTS and in the case of AAL2 multiplexing in AXC– Rejected capacity requests may be followed to certain extend with M800 measurement

• Useful for monitoring Iub (DL) and Iucs (UL) and Iur load– The VCC counters for HSDPA show zero for VCCs on the Iucs or Iur

• Maximum of 1600 VCC objects can be measured at the same time• The measurements must be configured as per VCI, VPI and ATM interface ID -> statistics

are also given for the same combination i.e. NOT as per BTS id or cell id (translation from VPI, VDI and ATM interface ID to BTS/Cell ID is needed - unless optional feature RAN868 "ATM Transport Statistics Reporting in RAN" is available)


Iub User Plane: AAL2 Path CAC Resource Measurement (M550) Counter_id Counter name

rnc_idif_idvpi_idvci_idperiod_start_timeperiod_duration

M550C0 AAL2_PATH_GUAR_CELL_RATEM550C1 SUM_RESERVED_CELL_RATEM550C2 MIN_RESERVED_CELL_RATEM550C3 MAX_RESERVED_CELL_RATEM550C4 SUM_AAL2_CONNECTIONSM550C5 MIN_AAL2_CONNECTIONSM550C6 MAX_AAL2_CONNECTIONSM550C7 NBR_SAMPLESM550C8 AAL2_RM_SUCCEEDEDM550C9 AAL2_CAC_REJECTEDM550C10 AAL2_HW_REJECTEDM550C11 SUM_AAL2_CONNECTIONS_HSDPAM550C12 MIN_AAL2_CONNECTION_HSDPAM550C13 MAX_AAL2_CONNECTIONS_HSDPAM550C14 AAL2_CAC_REJECTED_HSDPAM550C15 AAL2_HW_REJECTED_HSDPAM550C16 SHARED_HSDPA_AAL2_ALLOCATIONM550C17 AAL2_RM_SUCCEEDED_HSDPAM550C18 MIN_SHARED_HSDPA_AAL2_ALLOCM550C19 MAX_SHARED_HSDPA_AAL2_ALLOC

Reserved capacity

Connections

Reservationsuccesses/failures

HSDPA


Capacity bottleneck: Iub capacityM550 counters

Time /sec

traffic rate [cells/sec.]

Configured PCR of VCC

VCC load estimated by CAC

Shared HSDPA AAL2 allocation size

= sampled value (once per second)

Real traffic load of ATM VCC


M550 - reserved capacity

Reserved capacity

0100020003000400050006000700080009000

Nov 3 - Nov 9

cps

AAL2_PATH_GUAR_CELL_RATEMIN_RESERVED_CELL_RATEMAX_RESERVED_CELL_RATESHARED_HSDPA_AAL2_ALLOCATIONAverage reserved cell rate


M550: CAC reservation successes/failures

• Counters are only related to RNC CAC, i.e. downlink reservations on Iub (or uplink on Iu-CS or outgoing on Iur)

• Failure ratio can be calculated as

AAL2_CAC_REJECTED + AAL2_HW_REJECTED----------------------------------------------------------------------------------------------------------AAL2_RM_SUCCEEDED + AAL2_CAC_REJECTED + AAL2_HW_REJECTED

Counter id Counter name DescriptionM550C8 AAL2_RM_SUCCEEDED The number of successful AAL2 resource reservations. The connection

has successfullypassed the AAL2 connection resource reservation stage, but may still fail in the DMPG/TPG resourcereservation or in the signalling phase.

M550C9 AAL2_CAC_REJECTED The total number of rejected connections due to CAC.M550C10 AAL2_HW_REJECTED The number of connection establishments, which are rejected due to

failed HW request.This failure can occur after successful CAC resource reservation.


M550 - reserved capacity

Reservations vs failure ratio

0

2000

4000

6000

8000

10000

Nov 3 - Nov 9

cps

0%

10%

20%

30%

40%

50%

Failure ratio

MAX_RESERVED_CELL_RATEAverage reserved cell rateReservation failure ratio


• Highest average utilization ~70%• Highest average reservation ~90%• Reservation failures start to appear at ~50% utilization

M530/M550 - utilization vs reservationsUtilization vs Reservation

0%

20%

40%

60%

80%

100%

Nov 3 - Nov 9

Reservation failure ratioMax reservation ratioAverage reservation ratioDL utilization


M550: Connection ID Usage

Max number of CIDs available for connections per VCC is 248• A single call requires 2 connections, 2 CIDs (e.g. SRB + AMR or SRB + NRT PS)• A multi-RAB call requires one CID per connected RAB in addition to the SRB CID• Per each HSDPA user 3 CIDs (SRB + MAC-d Flow + UL Return Channel)Common channels (four per cell) require their own connections and CIDs as wellMeasurements for number of connections• Average number of AAL2 connections - includes R99, SRB, HSDPA and return channels

SUM_AAL2_CONNECTIONS / NBR_SAMPLES = C4/C7• Max number of AAL2 connections during measurement period (R99, SRB, HSDPA and return channel)

MAX_AAL2_CONNECTIONS = C6 (and MIN_AAL2_CONNECTIONS = C5)• Average number of AAL2 connections used by HSDPA i.e. number of MAC-d flows (note this does not

include SharedHSDPAAllocation reservation)SUM_AAL2_CONNECTIONS_HSDPA / NBR_SAMPLES = C11/C7

• Max number of simultaneous HSDPA connections during the measurement period ( this tells the maximum amount of HSDPA users from Iub VCC point of view)

MAX_AAL2_CONNECTIONS_HSDPA = C13 (and MIN_AAL2_CONNECTIONS_HSDPA = C12)


M550: Connection ID Usage

• Peak number of AAL2 connections was ~150 in the worst link in the most busy hour of theweek => no concern about this KPI

• If the peak number of AAL2 connections is high, the VCC can be split into two parts

Max nbr of AAL2 connections, w36

0

50

100

150

200

250

Interface


AAL2 Resource Reservation (M800)

Ø M800 is useful for monitoring success of the resource reservation requestsØ M800 collects the statistics per AAL2 user plane VCC object, note that there can be several UP

VCCsØ The object of the measurement is the AAL2 path selected with ATM interface ID/VPI/VCI identifiersØ Max 500 UP VCCs can be monitored at the same timeØ There are dedicated counters for HSDPA resource reservations when shared user plane VCC is

usedØ User Plane on Iub, IuCS and Iur can be monitoredØ Measurement is optional (bundled with M550)

Performance indicators

Measurement is able to count differenttype of failures, such as• Lack of Iub bandwidth• Lack of RNC capacity• AAL2 signaling failure

AAL2 Reservation Success rateHSDPA Reservation Success Rate



Reservationsuccesses/failures

Reservation andrelease ofHSDPA resources

Counter ID Counter namernc_idif_idvpi_idvci_idperiod_start_timeperiod_duration

M800C0 RES_SUCCEEDEDM800C1 RES_EXT_CAPM800C2 RES_INT_CAPM800C3 RES_OTHERM800C4 AAL2_SUCCEEDEDM800C5 AAL2_REJECTEDM800C6 AAL2_SUCCEEDED_HSDPAM800C7 TRANSPORT_REJECTED_EXT_HSDPAM800C8 TRANSPORT_REJECTED_INT_HSDPAM800C9 OTHER_REJECTED_HSDPAM800C10 ACTIVE_HSDPA_RES_TIMEM800C11 WAITING_HSDPA_RES_TIMEM800C12 RELEASE_TIMER_LENGTHM800C13 RESERV_REL_DUE_TO_TIMERM800C14 RESERV_REL_TIMER_STARTEDM800C15 RESERV_REL_TIMER_STOPPEDM800C16 RESERV_REL_DUE_TO_OTHERM800C17 ACTIVE_TIME_CUMULATIVEM800C18 WAITING_TIME_CUMULATIVEM800C19 REJECT_HSDPA_TOO_MANY_USERS

HSDPA reservationsuccesses/failures


Capacity bottleneck: Iub capacityM800 counters

RNCBTS UE AAL2 SIG CAC CAC AAL2SIG ATM RM

RRC: connection request

AAL2 connection establishment ERQ (SUGR)

Response to ERQ; ECF or RLC (cause)

AAL2 conn. estab. confirmation

RRC:connection setup

RRC

RNC internal transport resource reservation

WBTS internal transport resource reservation



Downlink reservation failure ratio:

RES_EXT_CAP + RES_INT_CAP + RES_OTHER------------------------------------------------------------------------------------------------RES_SUCCEEDED + RES_EXT_CAP + RES_INT_CAP + RES_OTHER

Uplink reservation failure ratio:

AAL2_REJECTED---------------------------------------------------------AAL2_SUCCEEDED + AAL2_REJECTED

Counter RNC1 RNC2 RNC3RES_SUCCEEDED 171513316 106300722 30524518RES_EXT_CAP 74010 321017 3394RES_INT_CAP 0 0 0RES_OTHER 11871 31108 133AAL2_SUCCEEDED 171209452 106264467 30510232AAL2_REJECTED 303864 36255 14286DL failure ratio 0.05% 0.33% 0.01%UL failure ratio 0.18% 0.03% 0.05%Overall failure ratio 0.23% 0.36% 0.06%

One week aggregated data:


Uplink AAL2 CAC Reservation Load and Failures

• Uplink AAL2 CAC reservation levels are not directly visible through counters• It can be calculated by calculating average loading per bearer type by

looking at allocation duration counters in M1002 for different types of DCH

• Uplink AAL2 CAC failures can be seen in M800C5 • there are some other causes included in the counter but main reason is UL

CAC • Can be cross checked against M548C5. • As we can only see the failures the monitoring method is reactive.


Case study: Using Shared HSDPA Scheduler for baseband efficiency

• Reduction of R99 traffic leads to significant reduction in DL Iubreservation

• But still Iub problems in the PS accessibility => Check M800 counters

Downlink Iub reservations, BTS x

0%

20%

40%

60%

80%

100%

Oct 6 - Oct 19

ReservationFailure ratio

Overall PS accessibility

0%

20%

40%

60%

80%

100%

Oct 6 - Oct 19

PS_SETUP_FAIL_OTHER_INTPS_SETUP_FAIL_UE_INTPS_SETUP_FAIL_TRANS_INTPS_SETUP_FAIL_DMCU_INTPS_SETUP_FAIL_BTS_INTPS_SETUP_FAIL_AC_INTSuccess


Case study: Using Shared HSDPA Scheduler for baseband efficiency

• M800 counters confirm that DL reservation failures have disappeared when the Shared Scheduler was activated on Oct 13

• Instead, UL has become the bottleneck (increased HS-DSCH availability leads to less DL R99 traffic, but probably more or less the samereservations in UL direction)

• Try Transport Bearer Tuning or 16 kbps UL return channel

Iub reservation failures, BTS x

0%

10%

20%

30%

40%

50%

60%

Oct 6 - Oct 19

DownlinkUplink


Case study: 16 kbps UL return channel

• Exisiting bit rates for UL return channel are 64 kbps, 128 kbps, 384 kbps

• This feature allows to use 16 kbps as well• As the UL return channel normally does not carry much data, it is

expected that 16 kbps in many cases will be enough– Less CE usage– Less Iub reservations

• In this network, used together with Throughput Based Optimization and Flexible Upgrade

• Initial bitrate set to 64 kbps



• Some of the sites which had the Shared Baseband Scheduler installed started to suffer from UL Iub congestion

• 16 kbps UL return channel activated on RNC level on Oct 20


0%

20%

40%

60%

80%

100%

Oct 6 - Oct 19




• Some of the sites which had the Shared Baseband Scheduler installed started to suffer from UL Iub congestion

• 16 kbps UL return channel activated on RNC level on Oct 20– Iub failures disappear– Due to RNC s/w instability, Oct 24 - 28 is removed from the following slides


0%

20%

40%

60%

80%

100%

Oct 6 - Nov 9


Sharedscheduler 48 users pr cell

16 kbps UL ret



• Before activation of the 16 kbps UL return channel, 100% of the UL return channel duration was 64 kbps

• 16 kbps is now used in about 60% of the time in the site

Relative duration of UL return channels, BTS x

0%

20%

40%

60%

80%

100%

Oct 6 - Oct 23 + Oct 29 - Nov 8

64 kbps16 kbps



• 16 kbps return channel lead to virtual disappearence of the Iubreservation failures

• Iub utilization not impacted

Iub reservation failures, BTS x

0%

10%

20%

30%

40%

50%

60%

Oct 6 - Oct 23 + Oct 29 - Nov 8

DownlinkUplink

Iub utilization

0%

20%

40%

60%

80%

100%

Oct 6 - Oct 23 + Oct 29 - Nov 8

DL Iub utilizationUL Iub utilization



• 16 kbps return channel reduces maximum CE usage from ~300 to ~270

CE usage, BTS x

0

50

100

150

200

250

300

350

Oct 6 - Oct 23 + Oct 29 - Nov 8

AVG_AVAIL_CEMAX_USED_CE_DLMAX_USED_CE_UL


Iub flow control

• Standard 3GPP flow control (between RLC layers in RNC and UE) doesn't take Iubcapacity into account

• If several active UEs in a Node B, the AAL2 buffers in the A2SUs may overflow, leadingto packet losses

– This leads to retransmissions on RLC and maybe even on TCP/IP layers• The parameter "InternalHSDPAFCMethodBTS" determines which type of flow control is

used– 0: No flow control– 1: Static Flow Control– 2: Dynamic Flow Control (optional feature, RAN324)


Iub flow controlWith 1*E1 and 3 simultaneous HSDPA users the Iub can get overloaded causing RLC layer retransmissions with No Flow Control when the #simultaneous users increases• The end result is fluctuating when

#simultaneous users increases as shown in figures on the right

• Cell throughput (3 user) throughputs is ~400-600kbps

• SHFCA is set close to the VCC UP Size

1 user 2 users 3 users

Thousands of dropped AAL2 packets and RLC retransmission rate ~1.95 and very large amount of PDUs going through with 5 or more retransmissions

M1017 is optional


Iub flow controlWhen same test case is done with Static Flow Control the results show very stable throughput as shown on the right and RLC retransmissions and dropped AAL2 packets below • The cell throughput (3 user) is

~900-950kbpsAverage #transmissions per PDU is 1.000045 and no AAL2 packet drops were detected 1 user 2 users 3 users


Iub flow controlWhen same test case is done with Dynamic Flow Control the results show very stable throughput as shown on the right and RLC retransmissions and dropped AAL2 packets are shown below • The cell throughput (3 user) is

~1.3mbps showing clearly that with Dynamic Flow Control the end user throughput can be maximized i.e. Iub can be utilised more (higher utilisation)

• SHFCA is set close to the VCC UP Size

Average #transmissions per PDU is 1.000057 and no AAL2 packet drops were detected

1 user 2 users 3 users


Case study: Activation of Dynamic Flow Control- PDU retransmission ratio

PDUperPDU

0.94

0.96

0.98

1

1.02

1.04

1.06

1.08

1.1

1.12

1.14

22 9

20

23 9

12

24 9

6

25 9

1

26 9

0

26 9

6

26 9

21

27 9

9

28 9

3

28 9

18

29 9

12

30 9

2

30 9

17

30 9

23

1 10

21

2 10

11

2 10

19

3 10

0

3 10

5

3 10

10

3 10

15

3 10

22

4 10

3

4 10

8

4 10

13

4 10

18

4 10

23

5 10

4

5 10

9

5 10

14

5 10

19

6 10

0

6 10

6

6 10

11

Date

PDU

perP

DU

PDUperPDU


RNCLCN1 - RNC_608a/HSDPA data volume (MAC-d) at Iub Mbit

0.00

50000.00

100000.00

150000.00

200000.00

250000.00

300000.00

350000.0020

08/0

9/29

00

2008

/09/

29 0

4

2008

/09/

29 0

8

2008

/09/

29 1

2

2008

/09/

29 1

6

2008

/09/

29 2

0

2008

/09/

30 0

0

2008

/09/

30 0

4

2008

/09/

30 0

8

2008

/09/

30 1

2

2008

/09/

30 1

6

2008

/09/

30 2

0

2008

/10/

01 0

0

2008

/10/

01 0

4

2008

/10/

01 0

8

2008

/10/

01 1

2

2008

/10/

01 1

6

2008

/10/

01 2

0

2008

/10/

02 0

0

2008

/10/

02 0

4

2008

/10/

02 0

8

2008

/10/

02 1

2

2008

/10/

02 1

6

2008

/10/

02 2

0

2008

/10/

03 0

0

2008

/10/

03 0

4

2008

/10/

03 0

8

2008

/10/

03 1

2

2008

/10/

03 1

6

2008

/10/

03 2

0

2008

/10/

04 0

0

2008

/10/

04 0

4

2008

/10/

04 0

8

2008

/10/

04 1

2

2008

/10/

04 1

6

2008

/10/

04 2

0

2008

/10/

05 0

0

2008

/10/

05 0

4

2008

/10/

05 0

8

2008

/10/

05 1

2

2008

/10/

05 1

6

2008

/10/

05 2

0

Date

Mbi

t

RNC_608a/HSDPA data volume (MAC-d) at Iub Mbit

Case study: Activation of Dynamic Flow ControlFeature ActivationRNC


Case study: Activation of Dynamic Flow Control- Drive test throughput before change

Maximum throughput that the WBTS can give (air interface).

Actual throughput

In some instants the user throughput variation was quite high.


Case study: Activation of Dynamic Flow Control- Drive test throughput after change

Maximum throughput that the WBTS can give (air interface).

Actual throughput

After activating the feature the user throughput variation is much less than before. Iub congestion prevents throughput from reaching acceptable values


Service level monitoringRelevant counters for high-level monitoring of transmission performance:• RRC connection:

– RRC_CONN_STP_FAIL_TRANS– RRC_CONN_STP_FAIL_IUB_AAL2

• RAB establishment (Voice, video, streaming - NOT interactive and background)– RAB_STP_FAIL_CS_VOICE_TRANS– RAB_STP_FAIL_CS_V_IUB_AAL2

• HS-DSCH establishment (counters for interactive and background)– SETUP_FAIL_IUB_HS_TOTAL_INT– SETUP_FAIL_IUB_MAC_D_INT– SETUP_FAIL_16_IUB_HSDSCH_INT– SETUP_FAIL_64_IUB_HSDSCH_INT– SETUP_FAIL_128_IUB_HSDSCH_IN– SETUP_FAIL_384_IUB_HSDSCH_IN

• PS RB establishment (counters for interactive and background)– PS_SETUP_FAIL_TRANS_INT


Case study: Impact on Iub congestion on radio KPIs

• For HSDPA networks with the traditional Iub transport network (X x E1s), it is quite common to have high usage of the DL Iub capacity

• This means that the buffers in the BTS cannot be fed as quickly as the BTS can send the data over the radio interface

• This in turn means the BTS will select lower modulation/codes thanwhat the radio interface allows in order to avoid padding

• The following slides examines how this can look in practice– Basic scheduler is in use (so no more than 5 codes can be used)– Proportional Fair scheduler– Static Flow Control is in use– RAS06, RN3.0 CD1.0, WN4.0 CD1.0



• All the statistics come from one BTS that initially only used 1 x E1 and was suffering from slight congestion (the utilization exceededthe 40% threshold every day in the busy hour)

• On October 1st, the capacity was expanded to 2 x E1• The following split between signalling and user plane traffic was

used

1 x E1 2 x E1CNBAP 158 158DNBAP 316 316AAL2 SIG 158 158UP 3706 8197

Iub UP utilization

0%

20%

40%

60%

80%

100%

Sep 22 - Oct 1

DownlinkUplink



• After expansion, peak traffic increased from ~2000 cps to ~3000 cps

• Peak average utilization is now at 40%

Iub traffic

0100020003000400050006000700080009000

Sep 22 - Oct 12

cps

VCC capacityDownlinkUplink

Iub UP utilization

0%

20%

40%

60%

80%

100%

Sep 22 - Oct 12

DownlinkUplink



Both the HSDPA cell throughput and the efficiency KPIs changedafter the expansion• Average HSDPA cell throughput in the 7 days prior to the

expansion was 414 kbps. In the 7 days following the expansion, the average throughput went up to 837 kbps

• Average efficiency decreased from 97% to 93%– Still above the target of 90%, so still congestion somewhere

Cell throughput (rnc_722b)

0

500

1000

1500

2000

2500

Sep 22 - Oct 12

kbps

Efficiency (rnc_607c)

75%

80%

85%

90%

95%

100%

Sep 22 - Oct 12


Case study: Impact on Iub congestion onradio KPIs

• With the help of the CQI mapping table, the modulation/code use can be predicted from theCQI values

• The counters show reported CQI while the mapping table uses compensated CQI• In the charts, the prediction is done both based on the reported CQI and on the

compensated CQI (assuming 3 dB compensation)• Charts show average values from previous 7-day period vs following 7-day period• Before the Iub expansion, the actual modulation/code use is much lower than predicted

from CQI. After expansion, at least the lower code use is more aligned with the prediction– On average, 96% of the UEs in the BTS support 16QAM

Actual code usage vs CQI based, before

0%

10%

20%

30%

40%

50%

60%

70%

1-QPSK 2-QPSK 3-QPSK 4-QPSK 5-QPSK 5-16QAM

ActualReported CQICompensated CQI

Actual code usage vs CQI based, after

0%

10%

20%

30%

40%

50%

60%

70%

1-QPSK 2-QPSK 3-QPSK 4-QPSK 5-QPSK 5-16QAM

ActualReported CQICompensated CQI

CQI TBS codes M ∆ (dB)1 137 1 QPSK 02 173 1 QPSK 03 233 1 QPSK 04 317 1 QPSK 05 377 1 QPSK 06 461 1 QPSK 07 650 2 QPSK 08 792 2 QPSK 09 931 2 QPSK 010 1262 3 QPSK 011 1483 3 QPSK 012 1742 3 QPSK 013 2279 4 QPSK 014 2583 4 QPSK 015 3319 5 QPSK 016 3565 5 16QAM 017 4189 5 16QAM 018 4664 5 16QAM 019 5287 5 16QAM 020 5887 5 16QAM 021 6554 5 16QAM 022 7168 5 16QAM 023 7168 5 16QAM -124 7168 5 16QAM -225 7168 5 16QAM -326 7168 5 16QAM -427 7168 5 16QAM -528 7168 5 16QAM -629 7168 5 16QAM -730 7168 5 16QAM -8

Share of 16QAM capable UEs

0%

20%

40%

60%

80%

100%

Sep 22 - Oct 12



Summary• Moderate level of DL Iub congestion was solved with E1 expansion• This resulted in the use of higher modulation/code combinations• In turn, the higher modulation/code combinations doubled the

HSDPA cell throughput from 414 kbps to 837 kbps and brought theefficiency closer to the target (97% to 93%)


Agenda




Overview of KPIsThe following KPIs are normally investigated in order to assess RNC capacity

issues• Connectivity

– Nbr of WCELLs– Nbr of BTSs– AAL2 User Plane

• Traffic– Carried AMR Erlang– Carried PS data– Allocated capacity for PS data ("DMCU load factor")– RRC connected mode users– Nbr of HSDPA users

• CPU load– Average load

• DSP performance– Call setup success ratio


Connectivity• The "Cell Resource" table starts to contain the cell id as soon as the cell is

defined in the RNC configuration database• RNC1:

– 657 cells (57% of the capacity)– 232 BTSs (45% of the capacity)

• The AAL2 User Plane connectivity (Iub, Iur, Iu-CS) can be taken fromM550C0 AAL2_PATH_GUAR_CELL_RATE

• UP connectivity (Mbps) = M550C0 * 53 * 8 / 1000000• RNC1:

– AAL2 UP connectivity = 784 Mbps (22%)

Note: Same RNC/same periodused throughout this section. RNC configuration: RNC450/450


AMR ErlangsAverage AMR Erlangs in the measurement period can be measured

with the following formula:

Where the SHO overhead is given by

The Erlang capacity (8000 for RNC450/450) can be multiplied with0.8 to take peak-to-average ratio into account

OHSHO [s] period tmeasuremen100

_IN_DRNCMR_12_2_DLDURA_FOR_AIN_SRNCR_12_2_DL_DUR_FOR_AM

Usage(E) AMR

RNCover cells All

⋅

+

=

∑

∑

∑=

RNC in Cells All

RNC in Cells All

3ET_RTS_IN_ACT_STHREE_CELL +

2_FOR_RTIN_ACT_SETTWO_CELLS_ +FOR_RTN_ACT_SET_ONE_CELL_I

ET_RTS_IN_ACT_STHREE_CELL +_FOR_RTIN_ACT_SETTWO_CELLS_ +FOR_RTN_ACT_SET_ONE_CELL_IRT OHSHO


AMR Erlangs

• The RNC is very far from reaching the capacity limit

AMR Erlang, UMMT1

0

50

100

150

200

250

Sep 1 - Sep 9

Erla

ngs

AMR Erlang, UMMT1

0

10002000

30004000

5000

60007000

8000

Sep 1 - Sep 9

Erla

ngs


Iub throughput• Iub throughput is calculated as the PS + CS data throughput• Total throughput is found by using M530 counters and the CS voice contribution

is then subtracted– Note that softer HO overhead for CS voice does not appear on Iub, therefore it should

not be subtracted

• Where Softer HO overhead is

• The Iub capacity (450 Mbps for RNC450/450) is normally multiplied with 0.8 to take peak-to-average ratio into account

• Additionally 30 % Dedicated Channel (DCH) traffic in the uplink direction is supported– If UL share of the traffic is higher, more complex formulas are needed

VAF16.4kbps[s] period tmeasuremen

OHHO Softer * 100_IN_DRNCMR_12_2_DLDURA_FOR_A

IN_SRNCR_12_2_DL_DUR_FOR_AM

100010008b44B

[s] period tmeasuremen

M530C1DataCSPS

RNCover cells All

RNC in VCCs UP Iub All ⋅⋅

+

−⋅⋅

⋅=

∑∑

1000___&

1+=∑

∑

RNC in Cells All

RNC in Cells All

ET_RTS_IN_ACT_STHREE_CELL +_FORIN_ACT_SETTWO_CELLS_ +FOR_RTN_ACT_SET_ONE_CELL_I

C_FOR_RTDUR_ON_SRNSOFTER_HO_


Iub Throughput, PS + CS data, UMMT1

050

100150200250300350400450

Sep 1 - Sep 9

Mbp

s

Iub throughput

• The Iub throughput is not yet a capacity problem


Iub load factor• In addition to meeting the Erlang and the Iub throughput limit

individually, the following equation must also be satisfied

• Calculation of the numerators is done as shown in previous slides and the denominators are taken from the capacity statement

• Again, 0.8 is used to take peak-to-average ratios into account• In addition, the CS data traffic must follow this rule:

1≤++(Mbps) throughput Iub max

(Mbps)data CS(Mbps) throughput Iub max

(Mbps)data PS(Erl) AMR Max

(Erl) AMR

throughput Iub max %25 (Mbps) data CS ≤


Iub throughput load factor, UMMT1

0

0.2

0.4

0.6

0.8

1

Sep 1 - Sep 9

Iub load factor

• The Iub load factor is not yet a capacity problem


DMCU allocation load• The DMCUs (Diversity and Macro Combining Units) provides RNC

related user and control plane functions• The following equation must be valid

• The numerators are calculated based on counter statistics usingthe formulas shown on the next slides

• The denominators come from the RNC capacity statement

1≤++++(Mbps) HSDPA max

(Mbps) HSDPA(Mbps) PS384 DMCUmax

(Mbps) 384 PS(Mbps) PS256 DMCUmax



(Mbps) PS64


DMCU allocation load

( )

1000[s] period 100

5.69___64_____64___]64[__1065_

⋅⋅

⋅+=

∑tmeasuremen

kbpsDRNCINDLFORDURASRNCINDLBACKGPSDURDLMbpsLoadPSaRNC erRNCAllCellsOv

( )1000[s] period 100

7.136___128_____128___]128[__1066_

⋅⋅

⋅+∑=

tmeasuremen


( )

1000[s] period 100

3.273___256_____256___]256[__1067_

⋅⋅

⋅+=

∑tmeasuremen


( )

1000[s] period 100

7.407___384_____384___]384[__1068_

⋅⋅

⋅+=

∑tmeasuremen

kbpsDRINDLFORDURASRNCINDLBACKGPSDURDLMbpsLoadPSaRNC erRNCAllCellsOv

[s] period tmeasuremenTOTPDUDMAC[Mbps] SDPAH

⋅⋅⋅

=10001000

320___

Also the "Interactive" counters should be added to these formulas


DMCU allocation load

• Table (taken from RNC capacity statement) shows the max DMCU capacity for different R99 bearers

• The max HSDPA capacity is the same as the Iu capacity• Again, 0.8 is used to take peak-to-average ratios into account


DMCU load factor

• The DMCU load factor is not yet a capacity problem• Note that in this RNC, a large part of the DMCU load is caused by R99 NRT

bearers

DMCU allocation load factor, UMMT1

0

0.2

0.4

0.6

0.8

1

Sep 1 - Sep 9

HSDPA load factorPS384 load factorPS256 load factorPS128 load factorPS64 load factor


Number of RRC connected mode users

• Number of RRC connected mode users can be calculated by:

SUM_OPER_TIME_CELL_DCH + SUM_OPER_TIME_CELL_FACH + 10 * SUM_OPER_TIME_CELL_PCH------------------------------------------------------------------------------------------------------------------------------------------------

period_duration * 60

• Current usage is very far from the RNC450/450 limit of 100.000 users

Users in RRC connected mode, UMMT1

0500

10001500200025003000350040004500

Sep 1 - Sep 9

Nbr

of u

sers

cell_PCHcell_FACHcell_DCH


RNC CPU loadOverview of RNC units:

A2SUL (AAL2 Switching Unit)– Packet multiplexing and demultiplexing at the

ATM levelDMCU (Data and Macro Diversity CombiningUnit)

– Provides RNC related user and control plane functions incl. FP processing

ICSU (Interface and Control Signalling Unit)– Handles the signalling over the interfaces– Participates in distributed RRM related tasks

RRMU (Radio Resource Management Unit)– Centralized RRM and call management

RSMU (Resource and Switch ManagementUnit)

– Centralized resource management within RNC e.g. DSP resources

– Performs connGPTU (GPRS Tunneling Protocol Unit)

– Performs UP functions at the Iu-PSSFU (Switching Fabric Unit)MXU (Multiplexer Unit)OMU (Operations and Maintenance Unit)NIS/NIP (Network Interface Unit)


Counters to monitor CPU load

• The M592 family has counters to measure average and peak CPU load

• The unit type ids are according to thefollowing table

• Unit ids is a running sequence from 0 up to the amount of units in the RNC capacity step

• Units can reach 100% load and stillprovide stable operation – operatorshould start to consider expansionwhen the values in the table below isreached

utype_idunitid_id

M592C0 AVERAGE_LOADM592C1 PEAK_LOAD

1/1 Document Type Author Unit/Dept.

Document Title Date, Version For internal use

Unit type Unit name Unit type code in report

OMU Operation and maintenance unit 2

MXU Multiplexer Unit 268

NIU Network Interface Unit 301

NIP1 Network Interface Unit PDH 325

NIS1 Network Interface Unit STM-1 326

NIS1P Protected Network Interface Unit STM-1 271

RSMU Resource and Switch Management Unit 327

RRMU Radio Resource Management Unit 328

ICSU Interface Control and Signalling Unit 329

GTPU GPRS Tunneling Protocol Unit 330

SFU Switching Fabric Unit 337

A2SU AAL2 Switching Unit 1484

DMCU Data and Macro Diversity Combining Unit 1488

A2SP AAL2 Switching Processor 324

DMPG Data and Macro Diversity Processor Group 331


ICSU load

• High signalling load (e.g. caused by many SMSs) will increase theICSU load

ICSU average load

0

5

10

15

20

25

Sep 8 - Sep 14

ICSU peak load

0

5

10

15

20

25

30

35

Sep 8 - Sep 14


DMPG load

• In addition to CPU load, the DSP counters can be checked (note: M592 counters are for the Central Processing Unit, not the DSPs inside the DMPG)


DMPG load

• Each DMPG is either dedicated to R99 traffic or can handle both HSDPA and R99 traffic

• Some analysis should be done separately for each type• MML command ZWPI tells what each DMPG is doing

– Mapping changes after a restart!

WPI:U:UNIT=ALL:;

UNIT INFORMATION

UNIT DMPG POOL SETUP NAME---------------------------------------------------------------DMCU-0 DMPG-0 DCH DMPG DMCU-0 DMPG-1 HS DMPG DMCU-0 DMPG-2 DCH DMPG DMCU-0 DMPG-3 HS DMPG DMCU-1 DMPG-4 DCH DMPG DMCU-1 DMPG-5 DCH DMPG DMCU-1 DMPG-6 HS DMPG DMCU-1 DMPG-7 DCH DMPG DMCU-2 DMPG-8 DCH DMPG Etc.

DMPG load, RNC1Maximum average value during Sep 8 - Sep 14

01020304050607080

DMPGs

DCH DMPGsHS DMPGs


MXU and SFU load

• Load is not a concern

Average MXU load

0

0.5

1

1.5

2

2.5

Sep 8 - Sep 14

Peak MXU load

00.5

11.5

22.5

33.5

44.5

Sep 8 - Sep 14

Average SFU load, UMMT1

0

0.5

1

1.5

2

2.5

3

3.5

Sep 8 - Sep 14

Peak SFU load, UMMT1

00.5

11.5

22.5

33.5

44.5

Sep 8 - Sep 14


GTPU and A2SP load


Average GTPU load

0

24

68

10

1214

16

Sep 8 - Sep 14

Peak GTPU load

0

5

10

15

20

Sep 8 - Sep 14

Average A2SP load

0

510

1520

25

3035

40

Sep 8 - Sep 14

Peak A2SP load

0

10

20

30

40

50

60

Sep 8 - Sep 14


RRMU and RSMU load


Average RRMU load

0

1

2

3

4

5

6

Sep 8 - Sep 14

Peak RRMU load

0

24

68

10

1214

16

Sep 8 - Sep 14

Average RSMU load

0

2

4

6

8

10

12

Sep 8 - Sep 14

Peak RSMU load

0

10

20

30

40

50

60

70

Sep 8 - Sep 14


OMU and NIP1 load


Average OMU load

02468

1012141618

Sep 8 - Sep 14

Peak OMU load

0

20

40

60

80

100

Sep 8 - Sep 14

Average NIP1 load

0

2

4

6

8

10

Sep 8 - Sep 14

Peak NIP1 load

0

2

4

6

8

10

12

Sep 8 - Sep 14


NIS1 and NIS1P load


Average NIS1 load

00.5

11.5

22.5

33.5

44.5

Sep 8 - Sep 14

Peak NIS1 load

0

2

4

6

8

10

12

Sep 8 - Sep 14

Average NIS1P load

0

1

2

3

4

5

6

Sep 8 - Sep 14

Peak NIS1P load

0

2

4

6

8

10

Sep 8 - Sep 14


DMPG Load & DSP Allocation

DMPG Load/Occupancy

DSP Allocation => DSP Allocation and DSP Reservation Success Rates Measurements

PPC or PQ2 Load => Unit Load Measurements

In RAS06, alsoRLC AM is in DSP


DSP Performance Measurements in RNC (613/265H)

XX_ALLOCATED_CAPACITYXX_CURRENT_CALLSXX_PEAK_CALLSXX_TOTAL_CALLSXX_FAILED_CALLS

CC - Common channel

SC - Dedicated control channel

RTD - Real-time data

NRTD - Non real-time data

RTS - Real-time speech

RT_PS - Packet switched real-time data

HSDPA_COMMON - HSDPA common channel

HSDPA_NRTD - HSDPA non-real-time data

XX =


KPI formulas for DSP performance

DSP allocation failure ratio:

XX_FAILED_CALLS-----------------------------------------------------------XX_FAILED_CALLS + XX_TOTAL_CALLS


DSP Performance

• Only failures related to R99 NRT and HSDPA were occuring in this RNC• HSDPA failures seems not to be related to traffic....RNC s/w or h/w problems?• R99 NRT failures follows more regular pattern• Note that the DSP counters include both initial radio bearer establishment and radio

bearer reconfiguration (e.g. upgrade of UL return channel from 64 kbps to 384 kbps)• Check M1022 counters to see if there are any failures in the initial radio bearer

establishment:M1022C13 PS_SETUP_FAIL_DMCU_INTM1022C14 PS_SETUP_FAIL_DMCU_BGR

DSP allocation failures, RNC1

0%

1%

2%

3%

4%

5%

6%

7%

Sep 1 - Sep 14

NRT failure ratioHSDPA failure ratio

HSDPA calls, RNC1

0

500

1000

1500

2000

2500

Sep 1 - Sep 14

Peak

nbr

of c

alls

0

10

20

30

40

50

60

70

Allo

cate

d ca

paci

ty &

fa

ilure

rat

io

Peak callsAllocated capacityFailure ratio x 10


DSP Performance

• In this case, very, very few (0.003%) radio bearer establishments wereprevented due to DMCU issues

=> The DSP failures shown in previous slide only affects radio bearerreconfigurations

DMPG load vs setup failures

0

10

20

30

40

50

60

Oct 20 - Oct 27

DMPG

load

(%)

0.000%

0.001%

0.001%

0.002%

0.002%

0.003%

0.003%

0.004%

DM

CU

failu

re ra

tio

Average DMPG loadDMCU failure ratio


DSP Performance Measurements in RNC (613/265H)

RAS06:• M613C2 CC_PEAK_CALLS = Common Channel Services, creation of the cell(s)• M613C7 SC_PEAK_CALLS = Dedicated Control Channel services, number of

SRBs• M613C12 RTD_PEAK_CALLS = Real time data service, CS

streaming/conversational, incremented once pr call• M613C17 RTS_PEAK_CALLS = Real time speech service (AMR), incremented

once pr call• M613C22 NRTD_PEAK_CALLS = Non-real time data, NRT PS, does not include

HSDPA uplink, incremented twice pr call• M613C42 RT_PS_PEAK_CALLS = RT PS, same logic as previous• M613C57 HSDPA_NRTD_PEAK_CALLS = Non-real time data, NRT PS using

HS-DSCH, incremented twice per call (in RAS05.1: three times per call). Includes HSDPA UL R99 and HSUPA return channel


Peak number of simultaneous users

• Number of HSDPA users comfortably below current RNC capacity• ED2.1 will further increase RNC capacity• However, if all R99 NRT users start to use HSDPA (by solving other HS-

DSCH accessibility problems), there may be capacity problems• Exceeding the threshold for the number of simultaneous users is one of the

reasons why SETUP_FAIL_RNC_HS_DSCH_INT/BGR might peg

Peak nbr of HSDPA users in RNCUMMT1, RNC450/450

0

1000

2000

3000

4000

5000

6000

Sep 1 - Sep 9

Use

rs Peak no of HSDPA callsCD2 capacity (64 kbps)ED2.0 Capacity (64 kbps)

Peak nbr of calls, RNC1

0

500

1000

1500

2000

2500

Sep 1 - Sep 14

AMRNRT PSHSDPA


Peak number of simultaneous users

• Nice correlation between SETUP_FAIL_RNC_HS_DSCH_INT/BGR andnumber of HSDPA users in RNC

=> Capacity issue

HSDSCH rejections due to RNC

0

200

400

600

800

1000

March 20 - 28

Nbr

of u

sers

0.0%

20.0%

40.0%

60.0%

80.0%

100.0%

Rej

ectio

n ra

tio

Peak number of users RNC ratio

RNC expansion (RNC450/150 to RNC450/450)


HS-DSCH setup failure due to RNC - software stability

• SETUP_FAIL_RNC_HS_DSCH_INT/BGR disappears after RNC restart=> Not capacity issue!

HS-DSCH setup failures due to RNC

0

10000

20000

30000

40000

50000

60000

2008

0922

2008

0923

2008

0925

2008

0926

2008

0928

2008

0929

2008

1001

2008

1002

2008

1004

2008

1005

2008

1007

2008

1008

2008

1010

2008

1011

2008

1013

2008

1014

2008

1016

2008

1017

2008

1019

CD1.0 CD2.0 CD2.4


Agenda




• Both M530 and M5106 contain counters that allow us to calculate the usage of the Iub links

– M530 is optional– M530 covers Iub, Iur, Iu-CS, Iu-PS. M5106 covers Iub only– M530 also has counters that enable us to calculate cell loss in the ATM interfaces– Maximum 1024 VCCs can be monitored by M530

• AAL2 UP, AAL2 SIG, C-NBAP, D-NBAP, O&M VCCs are included in bothmeasurements

• For M530, separate mapping table between BTS/cell id and interface id isneeded

Usage - M530 vs M5106

Counter_id Counter namernc_idif_idvpi_idvci_idperiod_start_timeperiod_duration

M530C0 IN_TOT_CELLS_VCM530C1 EG_TOT_CELLS_VCM530C2 IN_REC_CELLS_VCM530C3 IN_QUEUED_CELLS_VCM530C4 IN_CAP_VCM530C5 EG_REC_CELLS_VCM530C6 EG_QUEUED_CELLS_VCM530C7 EG_CAP_VC


Iur utilization

Ingress utilization =

IN_TOT_CELLS_VC/(period_duration*60)---------------------------------------------------------

IN_CAP_VC

Iur utilization, RNC1 => RNC2

0%

10%

20%

30%

40%

50%

60%

Sep 16 - Sep 29

IngressEgress


Iur reservation/CAC rejectionsCounters from M550: M550C0 AAL2_PATH_GUAR_CELL_RATE

M550C1 SUM_RESERVED_CELL_RATEM550C7 NBR_SAMPLESM550C8 AAL2_RM_SUCCEEDEDM550C9 AAL2_CAC_REJECTEDM550C10 AAL2_HW_REJECTED

Iur reservation, RNC1 => RNC2

0%

20%

40%

60%

80%

100%

Sep 16 - Sep 29

ReservationCAC rejection

Iur reservations vs. CAC rejectionsSep 16 - Sep 29

0%

10%

20%

30%

40%

50%

60%

0% 20% 40% 60% 80% 100%

Average Iur reservation

CA

C r

ejec

tion

Iur utilization vs reservationSep 16 - Sep 29

0%

20%

40%

60%

80%

100%

0% 20% 40% 60% 80% 100%

Average Iur utilization

Aver

age

Iur

rese

rvat

ion

• When NRT PS calls go through the CAC reservation in Iur, activity factor of 1 is used

– In networks with high share of PS traffic, reservation much higher than utilization

– In this particular network, reservation about twicethe utilization

– Depends on network parameters, e.g. 16 kbps UL return channel usage, Throughput BasedOptimization etc.

• Once average reservation reaches ~60%, CAC rejections starts to occur


Iur CAC rejections vs SHO failures

• If there is congestion on the Iur interface, Soft Handovers across RNC borders will suffer• By analysing M1013 counters, SHO failure ratio pr adjacency can be calculated, and from

this the Drift SHO failure ratio can be found• Good correlation between Iur congestion and Drift SHO failure ratio

RNC1 => RNC2

0%

10%20%

30%40%

50%

60%70%

80%

Sep 16 - Sep 29

Iur reservation failureratioDrift SHO failure ratio

RNC1 => RNC2, Sep 16 - Sep 29

0%10%20%30%40%50%60%70%80%

0% 10% 20% 30% 40% 50%

Iur reservation failure ratio

Drift

SHO

failu

re ra

tio


Iur CAC rejections vs SHO failures

• Sites rehomed from RNC1 to RNC 2 on Oct 30 and on Nov 5– Less Iur traffic– CAC rejections are now zero– SHO failures across the RNC border reduced significantly

Iur reservation & failures, RNC1 => RNC2

0%

20%

40%

60%

80%

100%

Oct 20 - Nov 9

ReservationCAC rejectionDrift SHO failures


Iur, nbr of connection ids

Counters from M550:M550C4 SUM_AAL2_CONNECTIONSM550C6 MAX_AAL2_CONNECTIONSM550C7 NBR_SAMPLES

Nbr of Iur connections, RNC1

0

50

100

150

200

250

Sep 16 - Sep 26

PeakAverage


Iu-CS user plane

• Pretty good match between utilization and reservation• No failures in this case as the reservation is low• Evenly distribution of load between multiple VCCs

Iu-CS user plane utilization, PCR = 3 x 12000 cps

0%

5%

10%

15%

20%

25%

Sep 9 - Sep 14

Ingress 1Ingress 2Ingress 3Egress 1Egress 2Egress 3

Iu-CS User plane reservation, PCR = 3 x 12000 cps

0%

5%

10%

15%

20%

25%

30%

Sep 5 - Sep 14

Reservation, VCC1Reservation, VCC2Reservation, VCC3Failure ratio


Iu_CS user plane utilization vs reservations

When comparing the Utilisation (M530) and CAC reservation (M550) it can be seen that the usage is ~7/8 from reservationThe CAC reservation for Iu_CS is a lot closer to the actual usage compared to the Iub, this is due to no PS calls and high concentration of traffic

ATM_Utilisation vs CAC_Reservation

0.00%

10.00%

20.00%

30.00%

40.00%

50.00%

60.00%

70.00%

0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00% 80.00%


Iu-CS user plane & Cid

•In this case, clearly below the limit of 248 connections pr VCC• But if only one VCC, the capacity limit would have been reached

Iu-CS, number of connections

0

50

100

150

200

250

Sep 9 - Sep 14

Max, VCC1Max, VCC2Max, VCC3Average, VCC1Average, VCC2Average, VCC3


The Iu-CS Control Plane size should be around 6% of the User Plane and general rule is that the Control Plane load should notexceed 20% (higher load can mean delayed RANAP messages and SMSs)• There are two alarms that indicate the status of the control plane

load– 0026 SIGNALING LINK LOAD OVER THRESHOLD

▪ If the load is higher than the defined threshold (200 mErl by default) during 5 min measurement period then the alarm is generated (this means that teh alarm is generated in case the load is more than 20%)

– 0016 SIGNALLING LINK CONGESTION LEVEL EXCEEDED▪ The congestion level defined for the signalling link has been exceeded▪ Alarm is triggered immediately when certain congestion level has been exceeded

(there are three different congestion levels that can be defined)

Iu-CS control plane


Iu-CS control plane

• In this case utilization comfortably lower than the 20% threshold

Iu-CS signalling utilization, PCR = 4500 cps

0%

1%

2%

3%

4%

5%

6%

Sep 9 - Sep 14

IngressEgress


Iu-PS

• Iu-PS is IP-over-ATM interface, so no need to worry about over-reservation like in Iur

• Iu-PS utilization can be monitored from M530 or from M801 counters

Counter_id Counter name Releasernc_idutype_idunitid_idperiod_start_timeperiod_durationperiod_duration_sum

M801C0 INPUT_BYTES_TOTAL_UDP RN2.2EDM801C1 INPUT_IP_PACKETS_TOTAL RN2.2EDM801C2 INPUT_TRAF_BYTES_TC_CONV not supportedM801C3 INPUT_TRAF_BYTES_TC_STREAM RN2.2EDM801C4 INPUT_TRAF_BYTES_TC_INTERAC RN2.2EDM801C5 INPUT_TRAF_BYTES_TC_BACKGR RN2.2EDM801C6 OUTPUT_BYTES_TOTAL_UDP RN2.2EDM801C7 OUTPUT_IP_PACKETS_TOTAL RN2.2EDM801C8 OUTPUT_TRAF_BYTES_TC_CONV not supportedM801C9 OUTPUT_TRAF_BYTES_TC_STREAM RN2.2EDM801C10 OUTPUT_TRAF_BYTES_TC_INTERAC RN2.2EDM801C11 OUTPUT_TRAF_BYTES_TC_BACKGR RN2.2EDM801C12 ECHO_REQUEST_RECEIVED RN2.2EDM801C13 ECHO_RESPONSE_RECEIVED RN2.2EDM801C14 ECHO_RESPONSE_SENT RN2.2EDM801C15 ERROR_INDICATIONS_RECEIVED RN2.2EDM801C16 ERROR_INDICATIONS_SENT RN2.2EDM801C17 EXTENS_HEAD_NOTIF_RECEIVED RN2.2EDM801C18 AVERAGE_NBR_OF_GTP_TUNNELS RN2.2EDM801C19 MAX_NBR_OF_GTP_TUNNELS RN2.2ED

M801 family:• M530 measures both User Plane and Control Plane, M801 measures only User Plane

• M530 measures ATM cells, M801 measures bytes (IP/UDP/GTP headers are excluded)

• Both measurements are optional


Iu-PS UP usage threshold

The peak to average ratio should be taken into account when setting the limits for Iu-PS max usage• Typically average usage of 80% is enough to guerantee peak

performance• Peak to average ratio 1.25


Iu-PSIu-PS user plane throughput (M530, 53 bytes/cell), GTPU-1

0

5

10

15

20

25

Sep 15 - Sep 25

Mbp

s Downlink (Mbps)Uplink (Mbps)

Iu-PS user plane throughput (M801, excl. headers), GTPU-1

0

5

10

15

20

25

Sep 15 - Sep 25

Mbp

s Downlink (Mbps)Uplink (Mbps)

Iu-PS RANAP utilization (M530), ICSU-4

0%

1%

2%

3%

4%

5%

6%

7%

Sep 15 - Sep 25

DL loadUL load


Thank you!

Date post:	24-Jan-2016
Category:	Documents
Upload:	xbakht
View:	105 times
Download:	12 times

3G RAN Capacity

Documents