theory hermes
DESCRIPTION
theory hermesTRANSCRIPT
Theory Specification for HERMES v3.0 Date: Sept. 2011
Version 1.0
.
Theory Specification for HERMES Ver.3.0
MOTiV Research Co., Ltd.
Theory Specification for HERMES v3.0 Date: Sept. 2011
Version 1.0
.
Revision History
Date Rev. Editor Summary of Change
1 Sep. 2011 1.0 Kwangrok Chang First version
Copyright © MOTiV Research 2011 Page 2 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.1.4Test & Verification...................................................................................................................18
3.2 Signaling load in WBTS for Congestion Detection.............................................................18
3.2.1Objective of the study.............................................................................................................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
Copyright © MOTiV Research 2011 Page 3 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
Version 1.0
.
3.2.3Input & Output..........................................................................................................................26
3.2.4Test & Verification...................................................................................................................26
3.3 DC-HSDPA Monitoring & Simulation.....................................................................................26
3.3.1Objective of the study.............................................................................................................26
3.3.2Methodology.............................................................................................................................26
3.3.3Input & Output..........................................................................................................................26
3.3.4Test & Verification...................................................................................................................26
3.4 Baseband Dimensioning Differences in RU30....................................................................26
3.4.1Objective of the study.............................................................................................................26
3.4.2Methodology.............................................................................................................................26
3.4.3Input & Output..........................................................................................................................26
3.4.4Test & Verification...................................................................................................................26
6. Reference...................................................................................................................27
Copyright © MOTiV Research 2011 Page 4 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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
Copyright © MOTiV Research 2011 Page 5 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.
Copyright © MOTiV Research 2011 Page 6 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.
Copyright © MOTiV Research 2011 Page 7 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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
2.2.1Objective of the study
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
Copyright © MOTiV Research 2011 Page 8 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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:
Copyright © MOTiV Research 2011 Page 9 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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
Copyright © MOTiV Research 2011 Page 10 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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)
+5*(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_USERS
_4_1_IN_CELLS)
+6*(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)
+7*(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)
+8*(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)
+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)
Copyright © MOTiV Research 2011 Page 11 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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*(HSDPA_USERS_2_0_IN_CELLS+HSDPA_USERS_2_1_IN_CELLS+HSDPA_USERS_2_2_IN_CELLS+HSDPA_USERS_2_3_IN_CELLS+HSDPA_USERS
_2_4_IN_CELLS+HSDPA_USERS_2_5_IN_CELLS+HSDPA_USERS_2_6_IN_CELLS+HSDPA_USERS_2_7_IN_CELLS)
+3*(HSDPA_USERS_3_0_IN_CELLS+HSDPA_USERS_3_1_IN_CELLS+HSDPA_USERS_3_2_IN_CELLS+HSDPA_USERS_3_3_IN_CELLS+HSDPA_USERS
_3_4_IN_CELLS+HSDPA_USERS_3_5_IN_CELLS+HSDPA_USERS_3_6_IN_CELLS)
+4*(HSDPA_USERS_4_0_IN_CELLS+HSDPA_USERS_4_1_IN_CELLS+HSDPA_USERS_4_2_IN_CELLS+HSDPA_USERS_4_3_IN_CELLS+HSDPA_USERS
_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
Copyright © MOTiV Research 2011 Page 12 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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_1_4_IN_CELLS+HSDPA_USERS_2_3_IN_CELLS+HSDPA_USERS_3_2_IN_CELLS+HSDPA_USERS_4_1_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_4_3_IN_CELLS
+HSDPA_USERS_2_6_IN_CELLS+HSDPA_USERS_3_5_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_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
Copyright © MOTiV Research 2011 Page 13 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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:
Copyright © MOTiV Research 2011 Page 14 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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
2.2.3 Input & Output
2.2.4Test & Verification
3. FEATURE UPGRADE
3.1 RRC Connected Mode Users Monitoring
3.1.1Objective of the study
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
Copyright © MOTiV Research 2011 Page 15 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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
Copyright © MOTiV Research 2011 Page 16 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.
Copyright © MOTiV Research 2011 Page 17 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.1.3 Input & Output
3.1.4Test & Verification
3.2 Signaling load in WBTS for Congestion Detection
3.2.1Objective of the study
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.
Copyright © MOTiV Research 2011 Page 18 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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
Copyright © MOTiV Research 2011 Page 19 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.
Copyright © MOTiV Research 2011 Page 20 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.
Copyright © MOTiV Research 2011 Page 21 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
Version 1.0
.
Too Many Simultaneous
Signaling Module
RRC Rejection rate
> 1% and RRC Attempts
>500
CNBAP CongestionContributed by M1006C203
Contributed by M1006C204
Contributed by M1006C205
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
Contributed by RRC_CONN_STP_FAIL_
AC
Contributed by RRC_CONN_STP_FAIL_
TRANS
**Contributed by Others
Check CE Resource
Check DL Power, DL code,
Interference
Check Iub
Others
Contributed by M5004C0
Inte
rnal
Rej
ectio
n
RL Setup Congestion
Too many simultaneous
Signalling
Too many simultaneous
Signalling
Too many simultaneous
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.
Copyright © MOTiV Research 2011 Page 22 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.
Copyright © MOTiV Research 2011 Page 23 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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
Copyright © MOTiV Research 2011 Page 24 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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)
Copyright © MOTiV Research 2011 Page 25 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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
Copyright © MOTiV Research 2011 Page 26 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
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.2.3 Input & Output
3.2.4Test & Verification
3.3 DC-HSDPA Monitoring & Simulation
3.3.1Objective of the study
3.3.2Methodology
3.3.3 Input & Output
3.3.4Test & Verification
3.4 Baseband Dimensioning Differences in RU30
3.4.1Objective of the study
3.4.2Methodology
3.4.3 Input & Output
3.4.4Test & Verification
Copyright © MOTiV Research 2011 Page 27 (28)
Theory Specification for HERMES v3.0 Date: Sept. 2011
Version 1.0
.
2. REFERENCE[1] NED6.0 Dimensioning WCDMA RAN, Sec.4.9 Signaling BTS Capacity
Copyright © MOTiV Research 2011 Page 28 (28)