theory hermes

Theory Specification for HERMES v3.0 Date: Sept. 2011

Version 1.0

.

Theory Specification for HERMES Ver.3.0

MOTiV Research Co., Ltd.


Version 1.0

.

Revision History

Date Rev. Editor Summary of Change

1 Sep. 2011 1.0 Kwangrok Chang First version

Copyright © MOTiV Research 2011 (28)


Version 1.0

.

Table of Contents

1. Objectives....................................................................................................................5

2. New Feature...............................................................................................................52.1 Paging Traffic Monitoring..........................................................................................................5

2.1.1Objective of the study...............................................................................................................5

2.1.2Methodology...............................................................................................................................7

2.1.3Input & Output............................................................................................................................72.1.3.1 Paging Load Monitoring..............................................................................................7

2.1.3.2 Paging Block Monitoring.............................................................................................7

2.1.3.3 Input...............................................................................................................................82.1.4Test & Verification.....................................................................................................................8

2.2 HSDPA Throughput Monitoring & Throughput Congestion Detection..............................8

2.2.1Objective of the study...............................................................................................................8

2.2.2Methodology...............................................................................................................................9

2.2.2.1................................................................................................................................HSDPA Throughput Monitoring....................................................................................................................................................9

2.2.2.2...................................................................................................................................................................................TTI Usage..................................................................................................................................................13

2.2.2.3...........................................................................................................................................................HSDPA Congestion..................................................................................................................................................13

2.2.2.4...............................................................................................................................HSDPA Throughput Congestion..................................................................................................................................................14

2.2.3Input & Output..........................................................................................................................14

2.2.4Test & Verification...................................................................................................................14

3. Feature Upgrade.....................................................................................................153.1 RRC Connected Mode Users Monitoring..............................................................................15

3.1.1Objective of the study.............................................................................................................15

3.1.2Methodology.............................................................................................................................15

3.1.3Input & Output..........................................................................................................................18


3.2 Signaling load in WBTS for Congestion Detection.............................................................18


3.2.2Methodology.............................................................................................................................19

5.2.2.1..........................................................................................................................Revision of Congestion Detection..................................................................................................................................................19

5.2.2.2..............................Implementation of M5004 counters (too many simultaneous signaling)..................................................................................................................................................23



Version 1.0

.

3.2.3Input & Output..........................................................................................................................26


3.3 DC-HSDPA Monitoring & Simulation.....................................................................................26


3.3.2Methodology.............................................................................................................................26

3.3.3Input & Output..........................................................................................................................26


3.4 Baseband Dimensioning Differences in RU30....................................................................26


3.4.2Methodology.............................................................................................................................26

3.4.3Input & Output..........................................................................................................................26


6. Reference...................................................................................................................27



Version 1.0

.

1. OBJECTIVES

The objective of this document is to describe the specifications of the theoretical studies of

HERMES ph3.0 implementation items. The specifications described in this document covers

the following areas of HERMES ph3.0:

New Feature

Paging traffic monitoring.

HSDPA throughput monitoring and the throughput congestion detection.

Feature Upgrade

RRC Connected mode users monitoring.

Baseband dimensioning differences in RU30.

DC-HSDPA monitoring and the study of DC-HSDPA simulation.

In the following sections the study items above will be explained in a way that:

Objective of the study

Methodology

Input & Output

Processing

Test & Verification

2. NEW FEATURE

2.1 Paging Traffic Monitoring

2.1.1Objective of the study

It is well known global trend that the smart phones’ packet data traffic increases across

the mobile network operators’ network resources, e.g. DL power, Iub transmission and

WBTS resources. Not only the packet data traffic, signaling traffic caused by push

messages sent by SNS (social network services) servers to the subscribers imposes

significant traffic load to mobile network. When the push messages sent by SNS servers



Version 1.0

.

reaches subscribers, mobile network has to send paging message to awake UE from the

DRX cycle so that the UE can receive the push message without missing. The paging load

handling capacity of the mobile network is limited by paging channel’s bit rate and

therefore, if the paging load has reached its maximum capacity, the mobile network

operator needs to bring the solutions to reduce the paging loads. The solutions could be:

Introducing 24kbps paging channel, which increases the paging load handling

capacity by 3 times more. (without this feature, paging channel’s bit rate is 8kbps only)

Chopping LA/RA into smaller areas. By dividing the Location Areas and

Routing Areas into several smaller geographical areas where less

subscribers exist. However, this method may require more RNCs or more

location/routing area updates, which may cause deteriorated service

performances perceived at UE side.

Using Cell_PCH or URA_PCH mode. In PCH mode, the location of the UE is

known to the core network in cell level (Cell_PCH) or URA level so that the

amount of paging messages that the core network has to send will be

reduced remarkable compared to LA/RA level.

Since the usage of the solutions remarked above is not so simple task because they may

require the re-design of the mobile network topology and UE’s supportiveness towards

the features above, it is necessary to know when would be the right time to adapt the

solution by moniotirng the paging load of the mobile network. SBM is also keen to

monitor the paging load in their 3G mobile network.

In this study, MOTiV will provide the paging load relevent KPIs so that SBM can detech

the paging load condition with the reliable range of accuracy.

The paging load KPIs to be covered in this service are:

Overall Paging load for 8kbps and 24kbps cases

Paging load for different paging types

Paging load in case URA_PCH and Cell_PCH are used

Paging block rate: Actually NSN doesn’t have this KPIs or counters but

MOTiV will work on the workaround or alternative solution of it.



Version 1.0

.

By monitoring the paging load KPIs listed above, SBM will become capable of

having the paging load & performance information in their hands almost

completely.

2.1.2Methodology

The study will be done by the sequence described below.

a. To collect the counters and CM data to build up paging KPIs

b. To calculate the paging KPIs using the developed KPIs on the sample RNCs

(1-2 RNCs)

c. To verify the accuracy and reliability of the developed KPIs

d. To report

Once the KPI formulation has been completed, the criteria of paging

congestion need to be decided. The criteria

2.1.3 Input & Output

The output of the paging load monitoring study comprises of two parts: paging load

monitoring and paging block monitoring.

2.1.3.1 Paging Load Monitoring

Paging loads, which attribute to paging types and paging channel’s bit rates, will be

covered in this study. The followings are the target KPIs to study and to formulate as the

output.

Average paging load for 8kbps and 24kbps paging channel in cell/WBTS/RNC/Region

level.

Average paging channel throughput for 8kbps and 24kbps paging channel in

cell/WBTS/RNC/Region level.

# of paging type1 attempts in cell/WBTS/RNC/Region level.

# of paging type2 attempts in cell/WBTS/RNC/Region level.



Version 1.0

.

2.1.3.2 Paging Block Monitoring

Currently there are no direct KPIs in NSN system reporting the paging success rate or

paging blocking rate however, in this study, MOTiV will search for an alternative KPI

formulation which depicts the paging performance KPI. The target output of the study is:

# of successful pages (or paging messages)

# of failed pages (or paging messages)

# of blocked pages (or paging messages)

Paging success rate

Paging failure rate (= 1 – Paging success rate)

2.1.3.3 Input

The input counters used for bulding up the paging counters are:

Paging Load Monitoring

M1000 counters

M1006 counters

Paging Block Monitoring

counters

CM data

However, during the project period, the input counters or CM could be varied or added.

2.1.4Test & Verification

2.2 HSDPA Throughput Monitoring & Throughput Congestion Detection


Mobile network’s congestions conventionally attribute to not enough resources in WBTS,

Iub transmission and air interface capacity. However, when it comes to packet data

service, the packet data throughput perceived at UE is as much important as service

accessibility. Especially HSDPA connection is not subject to the admission control but

rather stays in a standby condition in the queue or switched to R99 RAB and therefore

even if the HSDPA performance felt by end user is not so good, the deteriorated



Version 1.0

.

throughput will not be well described by congestion detection algorithms currently

implemented.

In Hermes v3.0, a new congestion terminology called HSDPA throughput congestion is

introduced to address the end user perception regarding HSDPA throughput performances.

The HSDPA throughput performance will be monitored and calculated. If HSDPA

throughput is detected as congestion (low throughput) in accordance with the criteria

defined and agreed with SBM, the cause of the congestion throughput will be also

monitored and reported in the main table, map and report.

The study of this section consists of the following two parts:

HSDPA throughput monitoring and congestion detection

Cause of HSDPA throughput congestion

By using HSDPA congestion detection feature, SBM can fully understand the causes of low

throughput or deteriorated end user perception if exists and address the issues relevant to

HSDPA throughput much quicker than before.

2.2.2Methodology

1.1.1.1 HSDPA Throughput Monitoring

Low HSDPA throughput peformances interpreted as throughput congestion in this service

is not necessarily caused by radio coverage problem (low CQI) but can be due to several

other factors. In this study, KPIs to monitor the HSDPA throughput performances is

formulated so that the deterioration of HSDPA throughput can be captured without delay.

One of the metric to describe the HSDPA throughput performance is the ‘average HSDPA

throughput per user, which is expressed by the equation below until HERMES ver. 2.0:

Average HSDPA Throughput per User =HS_DSCH_DATA_VOL⋅8kbps⋅hr2sec⋅Ave_Sim_HS_Users for C-Iub site (1)

Where kbps = 1000, converting bits to kbps and hr2sec = 3600 converting 1 hour to

seconds.

For ex-Nokia sites, the Average HSDPA throughput per user can be expressed by the

equation below:



Version 1.0

.

Average HSDPA Throughput per User =Act_HS_MacD_Thrput_NW Ave_Act_Sim_HS_Users (2)

Where, Act_HS_MacD_Thrput_NW is the HSDPA throughput per TTI (kbps) and given by:

Act_HS_MacD_Thrput_NW=(RECEIVED_HS_MACD_BITS-DISCARDED_HS_MACD_BITS )⋅500 HSDPA_BUFF_WITH_DATA_PER_TTI

Ave_Act_Sim_HS_Users=(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*DUR_HSDPA_USERS_17_TO_20 ¿+22 . 5*DUR_HSDPA_USERS_21_TO_24+26 . 5*DUR_HSDPA_USERS_25_TO_28 +30 . 5*DUR_HSDPA_USERS_29_TO_32 ¿¿ +34 . 5*DUR_HSDPA_USERS_33_TO_36 +38 . 5*DUR_HSDPA_USERS_37_TO_40+42 .5*DUR_HSDPA_USERS_41_TO_44 ¿¿¿+46 . 5*DUR_HSDPA_USERS_45_TO_48 ) ¿¿¿¿¿ (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 ¿+DUR_HSDPA_USERS_17_TO_20+DUR_HSDPA_USERS_21_TO_24+DUR_HSDPA_USERS_25_TO_28+DUR_HSDPA_USERS_29_TO_32 ¿¿¿+DUR_HSDPA_USERS_33_TO_36+DUR_HSDPA_USERS_37_TO_40 +DUR_HSDPA_USERS_41_TO_44+DUR_HSDPA_USERS_45_TO_48 ) ¿¿¿¿¿ ¿¿

If we look into the HSDPA throughput per user KPI formulas in more detail, it can be found

that ex-Siemens site’ throughput per user is calculated only using RNC counters however

for ex-Nokia, the calculation was done using both RNC and WBTS counters (M5000

counters). Actually it is believed that WBTS counter is more accurate than RNC level

counter but unfortunately ex-Siemens site does not support M5000 counters so only RNC

counters are used to obtain the HSDPA throughput per user for ex-Simens site.

Even if M5000 counters were used for ex-Nokia site, there are still RNC counters used to

calculate the denominator part of HSDPA throughput per user formula, which is

Ave_Act_Sim_HS_Users. The Ave_Act_Sim_HS_Users is not exactly the simultaneous HS

users during TTI but the active number of HSDPA users simultaneously allocated during

the measurement period, e.g. 1 hour. As a result, the calculation does not look accurate

enough since it is mixed with TTI level KPI and measurement period level KPI. However, it

is the best estimation in HERMES ver.2.0 where the simultaneous number of HSDPA users



Version 1.0

.

in TTI level is not available. In RU20, it has been improved and the active simultaneous

HSDPA users (the denominator part) can be calculated using WBTS (M5000) counters as

well.

Ave_Act_Sim_HS_Users in TTI (from RU20) =

{(HSDPA_USERS_0_1_IN_CELLS+HSDPA_USERS_1_0_IN_CELLS)

+2*(HSDPA_USERS_0_2_IN_CELLS+HSDPA_USERS_1_1_IN_CELLS+HSDPA_USERS_2_0_IN_CELLS)

+3*(HSDPA_USERS_0_3_IN_CELLS+HSDPA_USERS_1_2_IN_CELLS+HSDPA_USERS_2_1_IN_CELLS+HSDPA_USERS_3_0_IN_CELLS)

+4*(HSDPA_USERS_0_4_IN_CELLS+HSDPA_USERS_1_3_IN_CELLS+HSDPA_USERS_2_2_IN_CELLS+HSDPA_USERS_3_1_IN_CELLS+HSDPA_USERS

_4_0_IN_CELLS)


_4_1_IN_CELLS)


_4_2_IN_CELLS)


_4_3_IN_CELLS)


_4_4_IN_CELLS)

+9*(HSDPA_USERS_3_6_IN_CELLS+HSDPA_USERS_1_8_IN_CELLS+HSDPA_USERS_2_7_IN_CELLS+HSDPA_USERS_4_5_IN_CELLS)} /

(HSDPA_USERS_0_1_IN_CELLS+HSDPA_USERS_1_0_IN_CELLS+HSDPA_USERS_0_2_IN_CELLS+HSDPA_USERS_1_1_IN_CELLS+HSDPA_USERS_2_

0_IN_CELLS+HSDPA_USERS_0_3_IN_CELLS+HSDPA_USERS_1_2_IN_CELLS+HSDPA_USERS_2_1_IN_CELLS+HSDPA_USERS_3_0_IN_CELLS+HSDP

A_USERS_0_4_IN_CELLS+HSDPA_USERS_1_3_IN_CELLS+HSDPA_USERS_2_2_IN_CELLS+HSDPA_USERS_3_1_IN_CELLS+HSDPA_USERS_4_0_IN_C

ELLS+HSDPA_USERS_0_5_IN_CELLS+HSDPA_USERS_1_4_IN_CELLS+HSDPA_USERS_2_3_IN_CELLS+HSDPA_USERS_3_2_IN_CELLS+HSDPA_USE

RS_4_1_IN_CELLS+HSDPA_USERS_0_6_IN_CELLS+HSDPA_USERS_1_5_IN_CELLS+HSDPA_USERS_2_4_IN_CELLS+HSDPA_USERS_3_3_IN_CELLS+

HSDPA_USERS_4_2_IN_CELLS+HSDPA_USERS_1_6_IN_CELLS+HSDPA_USERS_2_5_IN_CELLS+HSDPA_USERS_3_4_IN_CELLS+HSDPA_USERS_0_7

_IN_CELLS+HSDPA_USERS_4_3_IN_CELLS+HSDPA_USERS_2_6_IN_CELLS+HSDPA_USERS_3_5_IN_CELLS+HSDPA_USERS_0_8_IN_CELLS+HSDPA

_USERS_1_7_IN_CELLS+HSDPA_USERS_4_4_IN_CELLS+HSDPA_USERS_3_6_IN_CELLS+HSDPA_USERS_1_8_IN_CELLS+HSDPA_USERS_2_7_IN_CE

LLS+HSDPA_USERS_4_5_IN_CELLS)

Actually since this formula gives the average simultaneous HSDPS users per scheduler in

TTI level, if the HSDPA throughput per users is calculated using this formula, the accurate

name of HSDPA throughput per user will be “HSDPA throughput per user per scheduler”.

This formula works well if there is only one HSDPA scheduler in a WBTS since it gives the

result in TTI level. However, if there are more than one HS schedule activated, e.g. RF3

and RF4 are HS activated carriers in a WBTS, this formula will be no longer reliable.

The average HSDPA throughput per user per scheduler in TTI level in RU20 is expressed

by the following KPI.

Average HSDPA Throughput per User (TTI level )=∑ Act_HS_MacD_Thrput_NW

Ave_Act_Sim_HS_Users in TTI⋅HSDPAMachs

Efficiency (3)



Version 1.0

.

Where HSDPA_Mac_hs_Efficiency is HSDPA Successful transmission ratio i.e. efficiency of

HSDPA data transmission between BTS and HSDPA UEs done by MAC-hs based on

successfully sent MAC-hs PDUs divided by totally sent MAC-hs PDUs. (Total number of all

successful sent MAC-hs PDUs divided by total number of all transmitted MAC-hs PDUs

including retransmissions). The equation is expressed by:

HSDPA_Mac_hs_Efficiency = (MAC_HS_PDU_RETR_DIST_CL_0+MAC_HS_PDU_RETR_DIST_CL_1+MAC_HS_PDU_RETR_DIST_CL_2+MAC_HS_PDU_RETR_DIST_CL_3+MAC_HS_P

DU_RETR_DIST_CL_4+MAC_HS_PDU_RETR_DIST_CL_5) /

(ORIG_TRANS_1_CODE_QPSK+ORIG_TRANS_2_CODE_QPSK+ORIG_TRANS_3_CODE_QPSK+ORIG_TRANS_4_CODE_QPSK+ORIG_TRANS_5_CODE_

QPSK+ORIG_TRANS_6_CODE_QPSK+ORIG_TRANS_7_CODE_QPSK+ORIG_TRANS_8_CODE_QPSK+ORIG_TRANS_9_CODE_QPSK+ORIG_TRANS_10

_CODE_QPSK+ORIG_TRANS_11_CODE_QPSK+ORIG_TRANS_12_CODE_QPSK+ORIG_TRANS_13_CODE_QPSK+ORIG_TRANS_14_CODE_QPSK+ORI

G_TRANS_15_CODE_QPSK+ORIG_TRANS_1_CODE_16QAM+ORIG_TRANS_2_CODE_16QAM+ORIG_TRANS_3_CODE_16QAM+ORIG_TRANS_4_COD

E_16QAM+ORIG_TRANS_5_CODE_16QAM+ORIG_TRANS_6_CODE_16QAM+ORIG_TRANS_7_CODE_16QAM+ORIG_TRANS_8_CODE_16QAM+ORIG

_TRANS_9_CODE_16QAM+ORIG_TRANS_10_CODE_16QAM+ORIG_TRANS_11_CODE_16QAM+ORIG_TRANS_12_CODE_16QAM+ORIG_TRANS_13_

CODE_16QAM+ORIG_TRANS_14_CODE_16QAM+ORIG_TRANS_15_CODE_16QAM+RETRANS_1_CODE_QPSK+RETRANS_2_CODE_QPSK+RETRAN

S_3_CODE_QPSK+RETRANS_4_CODE_QPSK+RETRANS_5_CODE_QPSK+RETRANS_6_CODE_QPSK+RETRANS_7_CODE_QPSK+RETRANS_8_CODE

_QPSK+RETRANS_9_CODE_QPSK+RETRANS_10_CODE_QPSK+RETRANS_11_CODE_QPSK+RETRANS_12_CODE_QPSK+RETRANS_13_CODE_QPS

K+RETRANS_14_CODE_QPSK+RETRANS_15_CODE_QPSK+RETRANS_1_CODE_16QAM+RETRANS_2_CODE_16QAM+RETRANS_3_CODE_16QAM+

RETRANS_4_CODE_16QAM+RETRANS_5_CODE_16QAM+RETRANS_6_CODE_16QAM+RETRANS_7_CODE_16QAM+RETRANS_8_CODE_16QAM+R

ETRANS_9_CODE_16QAM+RETRANS_10_CODE_16QAM+RETRANS_11_CODE_16QAM+RETRANS_12_CODE_16QAM+RETRANS_13_CODE_16QAM

+RETRANS_14_CODE_16QAM+RETRANS_15_CODE_16QAM)

Since eq. (3) works only with WBTS having one HS scheduler, it is required to generalize

the formula to beworking with multiple HS scheduler case by re-writing it as below.

Average HSDPA Throughput per User per cell (TTI level )=Act_HS_MacD_Thrput_NWAve_Act_Sim_HS_Users per cell per TTI

⋅HSDPAMachsEfficiency

(4)

Where,

Ave_Act_Sim_HS_Users per cell per TTI (RU20) = ((HSDPA_USERS_1_0_IN_CELLS+HSDPA_USERS_1_1_IN_CELLS+HSDPA_USERS_1_2_IN_CELLS+HSDPA_USERS_1_3_IN_CELLS+HSDPA_USERS_1_

4_IN_CELLS+HSDPA_USERS_1_5_IN_CELLS+HSDPA_USERS_1_6_IN_CELLS+HSDPA_USERS_1_7_IN_CELLS+HSDPA_USERS_1_8_IN_CELLS)


_2_4_IN_CELLS+HSDPA_USERS_2_5_IN_CELLS+HSDPA_USERS_2_6_IN_CELLS+HSDPA_USERS_2_7_IN_CELLS)


_3_4_IN_CELLS+HSDPA_USERS_3_5_IN_CELLS+HSDPA_USERS_3_6_IN_CELLS)


_4_4_IN_CELLS+HSDPA_USERS_4_5_IN_CELLS) /

(HSDPA_USERS_1_0_IN_CELLS+HSDPA_USERS_1_1_IN_CELLS+HSDPA_USERS_2_0_IN_CELLS

+HSDPA_USERS_1_2_IN_CELLS+HSDPA_USERS_2_1_IN_CELLS+HSDPA_USERS_3_0_IN_CELLS



Version 1.0

.

+HSDPA_USERS_1_3_IN_CELLS+HSDPA_USERS_2_2_IN_CELLS+HSDPA_USERS_3_1_IN_CELLS+HSDPA_USERS_4_0_IN_CELLS





+HSDPA_USERS_3_6_IN_CELLS+HSDPA_USERS_1_8_IN_CELLS+HSDPA_USERS_2_7_IN_CELLS+HSDPA_USERS_4_5_IN_CELLS)

At the moment, eq.(4) is not verified so it is recommend to compare all the three

euqations, eq.(1), eq.(2) and eq.(4) to decide which formula should be used for ex-Nokia

site.

1.1.1.2 TTI Usage

TTI usage is one of metric to indicate the HSDPA traffic congestion. The TTI usage can expressed by the following equation.

TTI Usage=¿ (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) ¿ ¿ (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_NOT_SCHED_DATA_IN_BUFF ) ¿¿¿¿¿¿

Since HS_SCCH_PWR_DIST_CLASS_0 + … + HS_SCCH_PWR_DIST_CLASS_5 = HSDPA_BUFF_WITH_DATA_PER_TTI, the formula above can be re-written as:

TTI Usage=HSDPA_BUFF_WITH_DATA_PER_TTI(HSDPA_BUFF_WITH_DATA_PER_TTI+ TTI_NOT_SCHED_DATA_IN_BUFF)

The TTI usage level which causes the low HSDPA throughput can be defined by comparing the

following KPIs.

a. HSDPA throughput per user

b. TTI usage

c. Active Simultaneous HSDPA users

As TTI usage increases, the number of Active Simultaneous HSDPA users grows and vice versa. This

will result in lower HSDPA throughput per user in natural. Since the HSDPA throughput congestion

threshold is defined as 250kbps by SBM, it is possible to find out the TTI usage when HSDPA



Version 1.0

.

throughput becomes below 250kbps statistically. It is desirable that this statistical comparison

needs to be done in 1.5GHz network because Iub bandwidth (IP Iub) is big enough and the R99

traffic is smaller than that of 2GHz. It is easier to identify the TTI usage threshold in 1.5GHz

network. As a reference, SBM defines TTI usage threshold as 50%.

1.1.1.3 HSDPA Congestion

One of the critical causes of the HSDPA accessibility congestion is the lack of HSDPA user license.

SBM wants to monitor the HSDPA congestions caused by the lack of HSDPA user license in terms of

two metrics:

a. The number of hours that the HSDPA accessibility failure became higher than the congestion

threshold.

b. Average HSDPA accessibility failures caused by HSDPA user license during the sum of the

congestion hours.

In order to provide the suitable monitoring output, it is desirable to define the threshold for the

HSDPA accessibility failure ratio due to HSDPA user license. In HERMES ver.3.0, the default

threshold is given to ‘0’, which means as long as there is HSDPA accessibility failure happened due

to the lack of HSDPA user license and it will be reported and considered into the number of

congestion hours.

The KPI of HSDPA accessibility failure (HSDPA congestion) due to HSDPA user licenase is:

HSDPA Congestion due to HSDPA User License = M1002C475 DCH_SEL_MAX_HSDPA_USERS_INT

+ M1002C476 DCH_SEL_MAX_HSDPA_USERS_BGR

We need to confirm the KPI above is matching to SBM’s requirement regarding HSDPA congestion.

1.1.1.4 HSDPA Throughput Congestion

HSDPA throughput congestion is defined that the average HSDPA throughput per user is

lower than the HSDPA throughput threshold value configured by SBM for a given hourly

period. The KPI of the average HSDPA throughput per user is already defined in sec.

2.2.2.1. In this section, the causes of the low HSDPA throughput per user is investigated

and clarified by identifying where the bottle-neck of the HSDPA throughput deterioration

exists and based on it the reporting of the causes can be implemented. The causes of

HSDPA throughput congestion attribute to the followings:



Version 1.0

.

Lack of DL power for HSDPA

Lack of Channelization code

Lack of Iub resources (U-plane and/or CID in case of ATM Iub)

Low CQI



3. FEATURE UPGRADE

3.1 RRC Connected Mode Users Monitoring


Softbank Mobile considers the activation of URA_PCH and Cell_PCH modes into their 3G

network in both 1.5GHz and 2.1GHz bands to improve the UE battery lift time, packet data

accessibility (shorter setup time) and to reduce the signaling loads. While Cell_PCH and

URA_PCH brings benefits to 3G network, operator needs to supervise the capacity of RRC

connectivity per RNC because the time duration when UE stays in PCH mode is 30minutes

by default and this will increase the number of RRC connections per RNC drastically. In

this study, the capacity of RNC in terms of RRC connectivity and the number of RRC

connections (RRC connected mode) per RNC will be investigated.

3.1.2Methodology

In HERMES ph.3, which will be implemented on RU20 level, the new counter, RNC Capacity

Usage measurement (802/322H) will be used to provide the information on the amount of

simultaneous number of users in different RRC connected mode states. The 2 most

important counters for monitoring simultaneous RRC connected mode are:

M802C17 AVE_RRC_CONN_MODE_USERS

M802C18 MAX_RRC_CONN_MODE_USERS



Version 1.0

.

The RNC capacity usage measurement provides the information on the amount of

simultaneous AMR calls, Iu-PS throughput and the number of users in different RRC

connected mode states. The object of the measurement is the RNC itself. When capacity

licensing is used, the Iu-PS throughput and AMR amount distribution counters can be used

to evaluate how close to the licensed limit the RNC is running, and thus predict the need

for capacity upgrade.

The updating of some counters of this measurement is based on a sampling method. The

sampling timer is approximately 1 second, but it must be noted that the timer is not

absolutely accurate and thus the sample amount during one hour measurement interval

does not match exactly 3600 seconds but slightly less, for example 3560.

Some counters in this measurement are supported only in certain RNC HW configurations.

The support of counters is presented in table shown below.

PI ID NameRNC196&450

without IP-upgrade

RNC196&450 with IP-upgrade

(NPS1/NPGE)

RNC2600 RNC196 step8

M802C0 AMR_AVERAGE X X XM802C1 AMR_MAX X X XM802C2 AMR_DISTR_CLASS_0 XM802C3 AMR_DISTR_CLASS_1 XM802C4 AMR_DISTR_CLASS_2 XM802C5 AMR_DISTR_CLASS_3 XM802C6 AMR_DISTR_CLASS_4 XM802C7 AMR_LIC_CAPACITY XM802C8 IU_PS_THR_AVERAGE X XM802C9 IU_PS_THR_PEAK X XM802C10 IUB_PS_THR_DISTR_CLASS_0 (X)* XM802C11 IUB_PS_THR_DISTR_CLASS_1 (X)* XM802C12 IUB_PS_THR_DISTR_CLASS_2 (X)* XM802C13 IUB_PS_THR_DISTR_CLASS_3 (X)* XM802C14 IUB_PS_THR_DISTR_CLASS_4 (X)* XM802C15 IUB_PS_THR_LIC_CAPACITY (X)* XM802C16 IU_PS_THR_LIMIT_DURATION (X)* XM802C17 AVE_RRC_CONN_MODE_USERS X X XM802C18 MAX_RRC_CONN_MODE_USERS X X XM802C19 AVE_USERS_CELL_DCH X X XM802C20 AVE_USERS_CELL_FACH X X X



Version 1.0

.

PI ID NameRNC196&450

without IP-upgrade

RNC196&450 with IP-upgrade

(NPS1/NPGE)

RNC2600 RNC196 step8

M802C21 AVE_USERS_CELL_PCH X X XM802C22 AVE_USERS_URA_PCH X X XM802C23 AMR_OVER_HSPA_AVERAGE X X XM802C24 AMR_OVER_HSPA_MAX X X X

*) Updated only if the Iu-PS capacity license is installed, which is not mandatory except in

RNC2600 and RNC196 step8.

There are many counters under M802 counter group however in this service, only

M802C17 and M802C18 will be implemented into HERMES ph3. The

RRC Connected Mode Users Load can be expressed by the following KPI formula:

RRC Connected Mode Users Load=AVE_RRC_CONN_MODE_USERSMax RRC Con . Mode Users (Capa )* TH_RRC_Users

≤1

The maximum RRC connected mode users per RNC type and step configuration are

presented in the table below.

RNC196

Step1 Step2 Step3 Step4 Step5 Step6 Step7 Step8 20,

000 30,

000 40,

000 50,

000 60,

000 70,

000 100,

000 100,

000RNC450

RNC450/150 default

RNC450/300 RNC450/450

35,000

70,000

100,000

RNC2600

Step1 Step2 Step3 100,

000 152,

000 200,

000

The following charts shows examples of the RRC connected mode users load calculated

using the formula above on an area network level in SBM.



Version 1.0

.

In this chart where SBM hasn’t activated URA and Cell PCH modes yet, only DCH and FACH

modes were taken into the calculation.

TH_RRC_Users stands for the threshold value for RRC connected mode users per RNC.

After taken the threshold into account the RRC connected mode users load must be less

than one. Otherwise, the RNC capacity upgrade or rehosting shall be considered.



3.2 Signaling load in WBTS for Congestion Detection


User data traffic congestion and signaling load congestion have been implemented in

HERMES ph2. Not only the congestion and load levels, the cause of the congestion has

been also presented. There are various causes in principle existing when the congestions

took place however, in HERMES ph2, the cause having the highest occurring frequency is

displayed throughout the complicated congestion categorizing process to pick up the

most congesting cause.

In HERMES ph3.0 this process will not be used any longer and instead, all the congestion

causes with their frequencies will be presented in accordance with SBM’s requirement.

The time period when the congestion detection algorithm is running based on will be

changed as well in a way of a fixed week basis rather than last 7 days basis.

In RU20 EP1, a new group of counters, M5004C0~C3 reporting the RL setup congestions

has been added. It is requested by SBM to implement these counters into HERMES ph3.



Version 1.0

.

The major tasks belong to Signaling load in WBTS congestion detection eventually

comprise of the followings:

Revise the current Congestion detection algorithm to present multiple causes of

the congestion.

Implement M5004C0~C3 counters (Signaling Load in WBTS Measurement)

3.2.2Methodology

1.1.1.5Revision of Congestion Detection

SBM introduces the concept of RF gap, which stands for the BTS resource congestion due

to load unbalancing between RF carriers or sectors. There are three types of RF gaps

depending on where the traffic unbalancing takes place.

a. Gap type1: Traffic unbalancing between difference cells in the same sector.

b. Gap type2: Traffic unbalancing between different scheduling in the same BTS.

c. Gap type3: Traffic unbalancing between different LCG in the same BTS.

F4 HS

F3 R99 CongestionLoading Unbalance!

Each of the gap types results in different congestions in different network nodes.

RF Gap Gap Type1 Gap Type2 Gap Type3

Congestion

s

Too many simultaneous signaling

HS Congestion due to RET channel reject

DL CH code shortage

DL Power shortage

UL Interference

HSDPA Max Users CE shortage



Version 1.0

.

Congestion detection process is the process to identify the network resource congestion

and categorise it into the right congestion type.

Congestion Detection

Cell Availability

Too many simultaneous

signalling

End

HSDPA Max Users

CE shortage

DL Code Shortage

HS congest due to RET Channel Reject

UL Interference

DL Power Shortage

Iub Shortage

1.1.1.5.1 Cell Availability

It is required that the cell availability should be in the valid range (e.g. >= 95%) in order

to get the reliable KPI for the resource congestion detection. If cell availability is worse

than the threshold, HERMES will ignore the KPI data in this hour of this cell from the

congestion detection counting process.



Version 1.0

.

Cell AvailabilityCell

Availability > 95%?

No

Yes

Ignore the KPI data for that hour

Continue

Start

The cell availability KPI is expressed by the following formula:

Cell Availability= 100*sum( AVAIL_WCELL_IN_WO_STATE) / sum( AVAIL_WCELL_EXISTS_IN_RNW_DB )= 100* sum( M1000C178) / sum(M1000C180 )

Once cell availability value is higher than 95% threshold value, which is configurable by

user, the congestion detection procedure for each congestion category is initiated.

1.1.1.5.2 Too Many Simultaneous Signaling (RRC Rejection)

The traffic congestion due to too many simultaneous signaling could take place when

huge number of subscribers executes the location area update or registration request, e.g.

in a train in the dense urban area during the rush hour or Shinkansen crossing the LAC

border.



Version 1.0

.

Too Many Simultaneous

Signaling Module

RRC Rejection rate

> 1% and RRC Attempts

>500

CNBAP CongestionContributed by M1006C203

Contributed by M1006C204


ICSU Congestion( Max reg)

RSMU Overload

No

Yes

Continue

Contributed by M1006C206 ICSU Overload

Contributed by M1006C208 RNC Restart

Contributed by RRC_CONN_STP_FAIL_

BTS


AC


TRANS

**Contributed by Others

Check CE Resource

Check DL Power, DL code,

Interference

Check Iub

Others


Inte

rnal

Rej

ectio

n

RL Setup Congestion


Signalling


Signalling


Signalling

TagToo many

simultaneous Signalling

TagToo many

simultaneous Signalling

Detail cause

The purpose of signaling congestion detection module is to identify ‘RRC Reject BTS (RF

resource congestion BTS)’. (RRC Reject 発生局 - 無線リソース枯渇局) by using:

i) Clarify the seriousness of the signaling congestion in terms of occurrence

frequency (number of hours) and the average RRC rejection rate during all of

the congestion hours (over one week).

ii) Classify the BTS having the RRC rejection due to location update and low

number of usres (traffic) into “Exclusion BTS”.

The signaling (RRC) rejection rate and the number of signaling rejection are examined if

they are higher than the threshold value, which is configurable by user. The threshold is

defined as below.

For a given hour, a cell is regarded as signaling congestion during the hour, if RRC

rejection rate >= 1% AND RRC Attempts >= 500.



Version 1.0

.

When the total number of congetion hours of the cell over one week (24hours×7days) is

>= 5 hours, the cell is labeled as congestion cell. If the congestion hours are more than 20

hours, the cell is ‘heavy congestion cell’ and the congestion hours are between 5 hours

and 20 hours, the cell is ‘light congestion cell’.

Signaling rejection rate is presented by:

Signaling rejection rate = RRC_CONN_REJECT / RRC Attempts >= 0.01

= M1006C21 / RRC Attempts >= 0.01

RRC Attempts = sum(CONN_REQ_MOC_ESTAB_CONV_CALL +

CONN_REQ_MTC_ESTAB_CONV_CALL + CONN_REQ_MOC_ESTAB_STRM_CALL +

CONN_REQ_MTC_ESTAB_STRM_CALL + CONN_REQ_MOC_ESTAB_INT_CALL+

CONN_REQ_MTC_ESTAB_INT_CALL+ CONN_REQ_MOC_ESTAB_BACKGR+

CONN_REQ_MTC_ESTAB_BACKGR + RRC_CONN_REQ_FOR_EMERG_CALL +

RRC_CONN_REQ_INT_CELL_RE_SEL + RRC_CONN_REQ_INT_CELL_CH_ORD +

RRC_CONN_REQ_FOR_REG + RRC_CONN_REQ_FOR_DETACH +

RRC_CON_REQ_OR_HI_PRI_SIGN + RRC_CON_REQ_OR_LO_PRI_SIGN +

RRC_CON_REQ_TE_HI_PRI_SIGN + RRC_CON_REQ_TE_LO_PRI_SIGN +

RRC_CO_RE_TERM_CU + RRC_CO_RE_ORIG_SUB_TRAF +

RRC_CONN_REQ_CALL_RE_ESTAB - RRC_CONN_REJ_RNC_RESTART) >= 500

= (M1006C0+M1006C1+M1006C2+M1006C3+M1006C4+M1006C5+M1006C6+M1

006C7+

M1006C8+M1006C9+M1006C10+M1006C11+M1006C12+M1006C13+M1006C14+

M1006C15+M1006C16+M1006C17+M1006C18+M1006C19 - M1006C208) >= 500

If neither of KPI or counter is higher than the threshold value, the signaling congestion

detection module for the cell will be skipped and moves to the next cell. If either of the KPI

and the counter is higher than the threshold value, the detail categorization process is

triggered to identify the cause of the signaling congestion.



Version 1.0

.

1.1.1.5.3 HSDPA Max Users

1.1.1.5.4 HSDPA Congestion due to RET Channel Reject

1.1.1.5.5 CE Shortage

1.1.1.5.6 DL CH Code Shortage

1.1.1.5.7 DL Power Shortage

1.1.1.5.8 UL Interference

1.1.1.5.9 Iub Shortage

1.1.1.6Implementation of M5004 counters (too many simultaneous signaling)

The new counters, M5004C0~M5004C3, under NBAP Radio Link procedures used for monitoring

radiolink setups per second, queuing time and rejections of setups due to congestion. The detection

of congestion in the BTS is based on internal messaging queueing times, simultaneous radio link

operations and mesurement report queueing times.

Counter ID

Counter Name NetAct Name Description Updated Unit

M5004C0

NUMBER OF REJECTED RL SETUPS DUE TO CONGESTION

REJECT_RL_SETUPS_CONGESTION

# of rejected RL setup requests due to congestion on MCU. (signaling load too high) MCU is responsible for local management and telecom.

Updated over the measurement period.

Integer number



Version 1.0

.

M5004C1PEAK RL SETUPS PER SECOND

PEAK_RL_SETUPS_PER_SECOND

Peak RL setup messages handled per second, where handled means setups that are not rejected because of congestion.

Peak value from all the samples during the measurement period.

Events/s

M5004C2PEAK RL OPERATIONS PER SECOND

PEAK_RL_OPER_PER_SECOND

Peak RL operations handled per second, where handled means operations that are not rejected because of congestion.

Peak value from all the samples during the measurement period.

Events/s

M5004C3AVERAGE RL SETUP MESSAGE QUEUING TIME

AVG_RL_SETUP_QUEUING_TIMEAverage RL setup request message queuing time before taken into handling in msec.

Average value from all the samples during the measurement period.

msec

The number of RL setups and operations varies in accordance with WBTS types, which is called

Signaling BTS capacity [1]. In extremely heavy load cases, it might be noticed that some network

KPIs are downgraded because there is not enough signaling capacity. Typically the reason for

signaling capacity overload is a bottleneck in some other capacity for example, if the Iub transport

and/or BTS baseband are badly under-dimensioned, signaling load grows rapidly because of

repeated and blocked radio link setup attempts.

KPI degradations because of excessive load may be encountered when a very high number of Radio

Link (RL) setup and RL reconfiguration messages are sent to the BTS. RL operations, that is RL

Setup, RL-reconfiguration (prepare, commit), RLaddition, RLdelete messages are generated by the

following events:

Call establishment (typically three RL operations)

SMS (typically two RL operations)

Location updates (typically two RL operations)

Soft handover branch addition (typically two RL operations)

KPI degradation is experienced in high traffic conditions, for example, RRC setup failures increase.

During normal operation, the number of RL setup messages for all cases except SHO, even for sites

carrying high traffic, is comparatively low.

The difference between RL operations and RL setups needs to be understood. RL operations cover

all RL activities such as setups, reconfigurations, deletions, and additions using C-NBAP and D-

NBAP. The number of operations depends on the traffic profile. RL setups cover only the setup part

of all RL operations using only C-NBAP. The reference traffic profile used for the RL setup

performance table is:

Voice:

90s Mean Holding Time (MHT), 1 call attempt per Busy Hour (BH)



Version 1.0

.

Data:

2 call attempts per BH

FTP, HTTP, streaming

- MHT depending on the application

- different speeds

- bursts with WEB surfing

mobility:

- SHO-overhead 40%

- Active Set Update (ASU) period for Real Time (RT) applications 11-23s

- ASU period for Non-Real Time (NRT) applications 40-50s

- 23% of ASU updates for softer handover (rest for SHO)

subscriber- related:

- 1.5 SMS per BH

- 2 Location Update (LU) per BH

No

.

BTS Type Max BB capacity Max RL Setup/sec Max RL Setup/CE

1 Supreme 1152CE 40 RL Setup/sec 0.035 RL Setup/sec/CE

2 Optima

Compact

768CE 30 RL Setup/sec 0.039 RL Setup/sec/CE

3 FSMB 240CE 20 RL Setup/sec 0.083 RL Setup/sec/CE

4 FSMB+FSMB 480CE 20 RL Setup/sec 0.042 RL Setup/sec/CE

5 FSMB+FSMD 636CE 90 RL Setup/sec 0.142 RL Setup/sec/CE



Version 1.0

.

6 FSMD 396CE 140 RL Setup/sec 0.354 RL Setup/sec/CE

7 FSME 612CE 140 RL Setup/sec 0.229 RL Setup/sec/CE

8 FSME+FSME 1224CE 140 RL Setup/sec 0.125 RL Setup/sec/CE

Based on M5004 counters and the RL setup capacity of WBTS, it will be developed the RL handling

performance and congestion detection KPIs.



3.3 DC-HSDPA Monitoring & Simulation


3.3.2Methodology



3.4 Baseband Dimensioning Differences in RU30


3.4.2Methodology





Version 1.0

.

2. REFERENCE[1] NED6.0 Dimensioning WCDMA RAN, Sec.4.9 Signaling BTS Capacity


theory hermes

Documents