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.
Revision History
Date 1 Sep. 2011 Rev. 1.0 Editor Kwangrok Chang Summary of Change First version
Copyright MOTiV Research 2011
Page 2 (27)
Table of Contents
1. 2. Objectives ....................................................................................................................... 5 New Feature ................................................................................................................... 5
2.1 Paging Traffic Monitoring ......................................................................................................... 5 2.1.1 Objective of the study ................................................................................................................ 5 2.1.2 Methodology .............................................................................................................................. 7 2.1.3 Input & Output ......................................................................................................................... 7 2.1.3.1 Paging Load Monitoring .............................................................................................. 7 2.1.3.2 Paging Block Monitoring ............................................................................................. 7 2.1.3.3 Input ............................................................................................................................ 8 2.1.4 Test & Verification .................................................................................................................... 8 2.2 HSDPA Throughput Monitoring & Throughput Congestion Detection................................... 8 2.2.1 Objective of the study ................................................................................................................ 8 2.2.2 Methodology .............................................................................................................................. 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.3 Input & Output ....................................................................................................................... 14 2.2.4 Test & Verification .................................................................................................................. 14
3.
Feature Upgrade .......................................................................................................... 15
3.1 RRC Connected Mode Users Monitoring ................................................................................ 15 3.1.1 Objective of the study .............................................................................................................. 15 3.1.2 Methodology ............................................................................................................................ 15 3.1.3 Input & Output ....................................................................................................................... 18 3.1.4 Test & Verification .................................................................................................................. 18 3.2 Signaling load in WBTS for Congestion Detection ................................................................. 18 3.2.1 Objective of the study .............................................................................................................. 18 3.2.2 Methodology ............................................................................................................................ 19 5.2.2.1 Revision of Congestion Detection ......................................................................................... 19 5.2.2.2 Implementation of M5004 counters (too many simultaneous signaling) ............................ 23 3.2.3 Input & Output ....................................................................................................................... 26 3.2.4 Test & Verification .................................................................................................................. 26 3.3 DC-HSDPA Monitoring & Simulation .................................................................................... 26 3.3.1 Objective of the study .............................................................................................................. 26 3.3.2 Methodology ............................................................................................................................ 26
Copyright MOTiV Research 2011 Page 3 (27)
3.3.3 3.3.4 3.4 3.4.1 3.4.2 3.4.3 3.4.4
Input & Output ....................................................................................................................... 26 Test & Verification .................................................................................................................. 26 Baseband Dimensioning Differences in RU30 ........................................................................ 26 Objective of the study .............................................................................................................. 26 Methodology ............................................................................................................................ 26 Input & Output ....................................................................................................................... 26 Test & Verification .................................................................................................................. 26
6.
Reference ...................................................................................................................... 27
Page 4 (27)
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.1 Objective 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 reaches subscribers, mobile network has
Page 5 (27)
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 channels 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 channels 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 UEs 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 doesnt have this KPIs or counters but MOTiV will work on the workaround or alternative solution of it.
Page 6 (27)
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.2 Methodology
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 channels 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.
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 counters CM data
Paging Block Monitoring
However, during the project period, the input counters or CM could be varied or added.
2.1.4 Test & Verification
2.2
HSDPA Throughput Monitoring & Throughput Congestion Detection

Mobile networks 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 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.2 Methodology
2.2.2.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_DA TA_VOL 8 for C-Iub site (1) kbps hr2sec Ave_Sim_HS _Users
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:
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_H
S_MACD_BIT S - DISCARDED_ HS_MACD_BI TS 500 HSDPA_BUFF _WITH_DATA _PER_TTI
Page 9 (27)
Ave_Act_Sim_HS_Users
(1.5 * DUR_HSDP A_ USERS_1_OR + 3.5 * DUR_HSDP A_ _2 USERS_3_OR + 5.5 * DUR_HSDP A_ _4 USERS_5_OR _6 + 7.5 * DUR_HSDP A_ USERS_7_OR + 9.5 * DUR_HSDP A_ _8 USERS_9_OR + 11.5 * DUR_HSDP A_ _10 USERS_11_O R_12 + 13.5 * DUR_HSDP A_ USERS_13_O R_14 + 15.5 * DUR_HSDP A_ USERS_15_O R_16 + 18.5 * DUR_HSDP A_ USERS_17_T O_20 + 22.5 * DUR_HSDP A_ USERS_21_T O_24 + 26.5 * DUR_HSDP A_ USERS_25_T O_28+ 30.5 * DUR_HSDP A_ USERS_29_T O_32 + 34.5 * DUR_HSDP A_ USERS_33_T O_36+ 38.5 * DUR_HSDP A_ USERS_37_T O_40 + 42.5 * DUR_HSDP A_ USERS_41_T O_44 + 46.5 * DUR_HSDP A_ USERS_45_T O_48) (DUR_HSDP A _USERS_1_O R_2 + DUR_HSDP A_ USERS_3_OR + DUR_HSDP A_ _4 USERS_5_OR + DUR_HSDP A_ _6 USERS_7_OR _8 + DUR_HSDP A_ USERS_9_OR + DUR_HSDP A_ _10 USERS_11_O R_12 + DUR_HSDP A_ USERS_13_O R_14 + DUR_HSDP A_ USERS_15_O R_16 + DUR_HSDP A_ USERS_17_T O_20 + DUR_HSDP A_ USERS_21_T O_24 + DUR_HSDP A_ USERS_25_T O_28 + DUR_HSDP A_ USERS_29_T O_32 + DUR_HSDP A_ USERS_33_T O_36 + DUR_HSDP A_ USERS_37_T O_40+ DUR_HSDP A_ USERS_41_T O_44 + DUR_HSDP A_ USERS_45_T O_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 exSiemens 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 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_US ERS_4_0_IN_CELLS)
Page 10 (27)
+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_US ERS_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_US ERS_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_US ERS_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_US ERS_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_USER S_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_CELL S+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_USE RS_4_0_IN_CELLS+HSDPA_USERS_0_5_IN_CELLS+HSDPA_USERS_1_4_IN_CELLS+HSDPA_USERS_2_3_IN_CELLS+HSDPA_USERS_3_2_IN_CEL LS+HSDPA_USERS_4_1_IN_CELLS+HSDPA_USERS_0_6_IN_CELLS+HSDPA_USERS_1_5_IN_CELLS+HSDPA_USERS_2_4_IN_CELLS+HSDPA_US ERS_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_CE LLS+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_U SERS_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_C ELLS+HSDPA_USERS_2_7_IN_CELLS+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)
Ave_Act_Si m_HS_Users in TTI
HSDPA _ Mac _ hs _ Efficiency
(3)
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_PDU_RETR_DIST_CL_4+MAC_HS_PDU_RETR_DIST_CL_5) /
Page 11 (27)
(ORIG_TRANS_1_CODE_QPSK+ORIG_TRANS_2_CODE_QPSK+ORIG_TRANS_3_CODE_QPSK+ORIG_TRANS_4_CODE_QPSK+ORIG_TRANS_5_CO DE_QPSK+ORIG_TRANS_6_CODE_QPSK+ORIG_TRANS_7_CODE_QPSK+ORIG_TRANS_8_CODE_QPSK+ORIG_TRANS_9_CODE_QPSK+ORIG_TRA NS_10_CODE_QPSK+ORIG_TRANS_11_CODE_QPSK+ORIG_TRANS_12_CODE_QPSK+ORIG_TRANS_13_CODE_QPSK+ORIG_TRANS_14_CODE_QP SK+ORIG_TRANS_15_CODE_QPSK+ORIG_TRANS_1_CODE_16QAM+ORIG_TRANS_2_CODE_16QAM+ORIG_TRANS_3_CODE_16QAM+ORIG_TRAN S_4_CODE_16QAM+ORIG_TRANS_5_CODE_16QAM+ORIG_TRANS_6_CODE_16QAM+ORIG_TRANS_7_CODE_16QAM+ORIG_TRANS_8_CODE_16Q AM+ORIG_TRANS_9_CODE_16QAM+ORIG_TRANS_10_CODE_16QAM+ORIG_TRANS_11_CODE_16QAM+ORIG_TRANS_12_CODE_16QAM+ORIG_T RANS_13_CODE_16QAM+ORIG_TRANS_14_CODE_16QAM+ORIG_TRANS_15_CODE_16QAM+RETRANS_1_CODE_QPSK+RETRANS_2_CODE_QPS K+RETRANS_3_CODE_QPSK+RETRANS_4_CODE_QPSK+RETRANS_5_CODE_QPSK+RETRANS_6_CODE_QPSK+RETRANS_7_CODE_QPSK+RETR ANS_8_CODE_QPSK+RETRANS_9_CODE_QPSK+RETRANS_10_CODE_QPSK+RETRANS_11_CODE_QPSK+RETRANS_12_CODE_QPSK+RETRANS _13_CODE_QPSK+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+RETRANS_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)
Ave_Act_Si m_HS_Users per cell per TTI
HSDPA _ Mac _ hs _ Efficiency
(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_USER S_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_CELL S) +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_US ERS_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_US ERS_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_US ERS_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 +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.
2.2.2.2 TTI Usage TTI usage is one of metric to indicate the HSDPA traffic congestion. The TTI usage can expressed by the following equation.
(HS_SCCH_P WR_DIST_CLASS_0 HS_SCCH_PW R_DIST_CLASS_1 HS_SCCH_PW R_DIST_CLASS_2 TTI Usage HS_SCCH_PW R_DIST_CLASS_3 HS_SCCH_PW R_DIST_CLASS_4 HS_SCCH_PW R_DIST_CLASS_5) (HS_SCCH_P WR_DIST_CLASS_0 HS_SCCH_PW R_DIST_CLASS_1 HS_SCCH_PW R_DIST_CLASS_2 HS_SCCH_PW R_DIST_CLASS_3 HS_SCCH_PW R_DIST_CLASS_4 HS_SCCH_PW R_DIST_CLASS_5 TTI_NOT_SC HED_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_SC HED_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 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%.
2.2.2.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:
Page 13 (27)
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 SBMs requirement regarding HSDPA congestion.
2.2.2.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: 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.4 Test & Verification
Page 14 (27)
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.2 Methodology
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
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.
Page 15 (27)
Some counters in this measurement are supported only in certain RNC HW configurations. The support of counters is presented in table shown below. RNC196&450 with IPRNC2600 PI ID Name upgrade RNC196 step8 (NPS1/NPGE) M802C0 AMR_AVERAGE X X X M802C1 AMR_MAX X X X M802C2 AMR_DISTR_CLASS_0 X M802C3 AMR_DISTR_CLASS_1 X M802C4 AMR_DISTR_CLASS_2 X M802C5 AMR_DISTR_CLASS_3 X M802C6 AMR_DISTR_CLASS_4 X M802C7 AMR_LIC_CAPACITY X M802C8 IU_PS_THR_AVERAGE X X M802C9 IU_PS_THR_PEAK X X M802C10 IUB_PS_THR_DISTR_CLASS_0 (X)* X M802C11 IUB_PS_THR_DISTR_CLASS_1 (X)* X M802C12 IUB_PS_THR_DISTR_CLASS_2 (X)* X M802C13 IUB_PS_THR_DISTR_CLASS_3 (X)* X M802C14 IUB_PS_THR_DISTR_CLASS_4 (X)* X M802C15 IUB_PS_THR_LIC_CAPACITY (X)* X M802C16 IU_PS_THR_LIMIT_DURATION (X)* X M802C17 AVE_RRC_CONN_MODE_USERS X X X M802C18 MAX_RRC_CONN_MODE_USERS X X X M802C19 AVE_USERS_CELL_DCH X X X M802C20 AVE_USERS_CELL_FACH X X X M802C21 AVE_USERS_CELL_PCH X X X M802C22 AVE_USERS_URA_PCH X X X M802C23 AMR_OVER_HSPA_AVERAGE X X X M802C24 AMR_OVER_HSPA_MAX X X X *) Updated only if the Iu-PS capacity license is installed, which is not mandatory except in RNC196&450 without IPupgrade 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:
Page 16 (27)
RRC Connected Mode Users Load
AVE_RRC_CO NN_MODE_US ERS 1 Max RRC Con. Mode Users (Capa) * TH_RRC_Use rs
The maximum RRC connected mode users per RNC type and step configuration are presented in the table below.
RNC196 Step1 20,000 RNC450/150 default 35,000 Step1 100,000 Step2 30,000 Step3 40,000 Step4 50,000 RNC450 RNC450/300 70,000 Step2 152,000 RNC450/450 100,000 RNC2600 Step3 200,000 Step5 60,000 Step6 70,000 Step7 100,000 Step8 100,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.
In this chart where SBM hasnt 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.
Page 17 (27)
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 SBMs 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. 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)
Page 18 (27)
3.2.2
Methodology
5.2.2.1 Revision 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 Congestion Loading Unbalance!
Each of the gap types results in different congestions in different network nodes. RF Gap Congestions Gap Type1 Too many simultaneous signaling HS Congestion due to RET channel reject DL CH code shortage DL Power shortage UL Interference Gap Type2 HSDPA Max Users Gap Type3 CE shortage
Congestion detection process is the process to identify the network resource congestion and categorise it into the right congestion type.
Page 19 (27)
Congestion Detection
Cell Availability CE shortage
Too many simultaneous signalling
DL Code Shortage
HSDPA Max Users
DL Power Shortage
HS congest due to RET Channel Reject
UL Interference
Iub Shortage
End
5.2.2.1.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.
Start
Cell Availability
Yes
Cell Availabilit y > 95%?
No
Ignore the KPI data for that hour
Continue
The cell availability KPI is expressed by the following formula:
Cell Availabili ty 100 * sum(AVAIL_WCELL_IN_WO_STATE)/ sum(AVAIL_WCELL_EXISTS_IN_RNW_ DB) 100 * sum(M1000C 178) / sum(M1000C 180)
Page 20 (27)
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. 5.2.2.1.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.
Detail cause
Contributed by M1006C203
Too many simultaneous Signalling Too many simultaneous Signalling Tag Too many simultaneous Signalling Tag Too many simultaneous Signalling
CNBAP Congestion ICSU Congestion( Max reg) RSMU Overload
Internal Rejection
Too Many Simultaneous Signaling Module
Contributed by M1006C204 Contributed by M1006C205 Contributed by M1006C206 Contributed by M1006C208 Contributed by M5004C0 Contributed by RRC_CONN_STP_FAIL_ BTS Contributed by RRC_CONN_STP_FAIL_ AC
RRC Rejection rate > 1% and RRC Attempts >500
Yes
ICSU Overload
RNC Restart
Too many simultaneous Signalling
No
RL Setup Congestion
Check CE Resource Check DL Power, DL code, Interference Check Iub
Continue
Contributed by RRC_CONN_STP_FAIL_ TRANS **Contributed by Others
Others
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
Page 21 (27)
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. When the total number of congetion hours of the cell over one week (24hours7days) 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+M1006C7+ 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.
Page 22 (27)
5.2.2.1.3 HSDPA Max Users
5.2.2.1.4 HSDPA Congestion due to RET Channel Reject
5.2.2.1.5 CE Shortage
5.2.2.1.6 DL CH Code Shortage
5.2.2.1.7 DL Power Shortage
5.2.2.1.8 UL Interference
5.2.2.1.9 Iub Shortage
5.2.2.2 Implementation 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
Page 23 (27)
M5004C0
NUMBER OF REJECTED RL SETUPS DUE TO CONGESTION PEAK RL SETUPS PER SECOND PEAK RL OPERATIONS PER SECOND AVERAGE RL SETUP MESSAGE QUEUING TIME
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. Peak RL setup messages handled per second, where handled means setups that are not rejected because of congestion. Peak RL operations handled per second, where handled means operations that are not rejected because of congestion. Average RL setup request message queuing time before taken into handling in msec.
Updated over the measurement period. Peak value from all the samples during the measurement period. Peak value from all the samples during the measurement period. Average value from all the samples during the measurement period.
Integer number
M5004C1
PEAK_RL_SETUPS_PER_SECOND
Events/s
M5004C2
PEAK_RL_OPER_PER_SECOND
Events/s
M5004C3
AVG_RL_SETUP_QUEUING_TIME
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, RLreconfiguration (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:
Page 24 (27)
Data:
90s Mean Holding Time (MHT), 1 call attempt per Busy Hour (BH)
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
Supreme
1152CE
40 RL Setup/sec
0.035 RL Setup/sec/CE
Optima Compact
768CE
30 RL Setup/sec
FSMB
240CE
20 RL Setup/sec
FSMB+FSMB
480CE
20 RL Setup/sec
FSMB+FSMD
636CE
90 RL Setup/sec
Page 25 (27)
FSMD
396CE
140 RL Setup/sec
FSME
612CE
140 RL Setup/sec
FSME+FSME
1224CE
140 RL Setup/sec
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.1 Objective of the study 3.3.2 Methodology 3.3.3 Input & Output 3.3.4 Test & Verification
3.4
Baseband Dimensioning Differences in RU30
3.4.1 Objective of the study 3.4.2 Methodology 3.4.3 Input & Output 3.4.4 Test & Verification
Page 26 (27)
6. REFERENCE
[1] NED6.0 Dimensioning WCDMA RAN, Sec.4.9 Signaling BTS Capacity
Page 27 (27)

Theory Hermes

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Theory Hermes

Hochgeladen von

Copyright:

Verfügbare Formate

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

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

Feature Upgrade .......................................................................................................... 15

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

3.3.3 3.3.4 3.4 3.4.1 3.4.2 3.4.3 3.4.4

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

2.1.1 Objective of the study

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

2.1.3 Input & Output

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

Paging Block Monitoring

2.1.4 Test & Verification

HSDPA Throughput Monitoring & Throughput Congestion Detection

2.2.1 Objective of the study

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

Average HSDPA Throughput per User

Average HSDPA Throughput per User

S_MACD_BIT S - DISCARDED_ HS_MACD_BI TS 500 HSDPA_BUFF _WITH_DATA _PER_TTI

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

HSDPA _ Mac _ hs _ Efficiency

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

HSDPA _ Mac _ hs _ Efficiency

Where, Ave_Act_Sim_HS_Users per cell per TTI (RU20) =

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

HSDPA_BUFF _WITH_DATA _PER_TTI (HSDPA_BUFF _WITH_DATA _PER_TTI TTI_NOT_SC HED_DATA_IN_BUFF)

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

2.2.2.4 HSDPA Throughput Congestion

2.2.3 Input & Output 2.2.4 Test & Verification

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

3.1.1 Objective of the study

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .

Date: Sept. 2011 Version 1.0

Copyright MOTiV Research 2011

Theory Specification for HERMES v3.0 .