CEM Capacity Monitoring Guide UA8.1 Internal Standard

CEM & CCM capacity monitoring guide UA8.
1
UMT/IRC/INF/025149
INTERNAL Standard V1.2
S. Bardey (TIPS/NEA/capacity)
29th April 2013
COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

ALCATEL-LUCENT CONFIDENTIAL SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
History
Version 1.0 preliminary 19 August 2011
Update for UA8 based on UA7 version3.5
Version 1.1 standard 20 December 2012

Update for UA8.1. More details
Version 1.2 standard 08 April 2013

Update : 1.6 s sampling period for PQ3 CEM CPU in LR13.1 (comment from JL Lescuyer)
Update after L. Vegas comments
Version 1.3 Standard 29 April 2013

Typo correction: slide 42, 50.
2
References (1/2)
[R1] CEM/CCM capacity Engineering Guide for UA8.1
UMT/IRC/APP/038992 V03.09/EN CEM/CCM Capacity Engineering Guide (internal)
https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objid=66538114&objAction=browse&sort=name
UMT/IRC/APP/025147 V03.09/EN CEM Capacity Engineering Guide (external)

[R2] NPO baseline and extended UA8.1 dictionaries :

https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=60316767&objAction=browse&viewType=1
[R3] Internal docs

iBTS OBS : https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=63219565&objAction=browse&sort=name
RNC OBS : https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=61969037&objAction=browse&viewType=1
[R4] External docs (RNC counters, BTS counters) :
[R5] UPUG & HPUG

https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=60317276&objAction=browse&sort=name
[R6] NodeB Call Model Monitoring Method (internal)

[R7] BTS configuration commands (internal)

https://wcdma-ll.app.alcatel-
lucent.com/livelink/livelink.exe?func=ll&objId=66416810&objAction=Open&nexturl=%2Flivelink%2Flivelink%2Eexe%3Ffunc%3Dll%26objId%3D66416628%26o
bjAction%3Dbrowse%26viewType%3D1
[R8] iBTS Performance in traffic - UA7.1.3 status (UMTS/BTS/DD/038527)

https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=66424673
[R9] iBTS UA8.1.3 : Traces assessment for High traffic conditions,

3
UMT/BTS/DD/037084 COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
References (2/2)
[R10] User defined max capacity indicators (xml)
lucent.com/livelink/livelink.exe?func=ll&objId=66488640&objAction=Open&nexturl=%2Flivelink%2Flivelink%2Eexe%3Ffunc%3Dll%26objid%3D65645192%26objAction
%3Dbrowse%26sort%3Dname
[R11] FSM for 125171-125567 - E-DCH Node B CAC new Standard version 01.04
[R12] Indicator xml for max 2ms & 10ms EDCH users per CEM board (by courtesy of
P. Cochois)
lucent.com/livelink/livelink.exe?func=ll&objId=66574768&objAction=Open&nexturl=%2Flivelink%2Flivelink%2Eexe%3Ffunc%3Dll%26objid%3D65645192%26objAction
%3Dbrowse%26sort%3Dname
[R13] FSM 118154 HSDPA-DC Capa increase

4
Introduction
Scope of this package:
UTRAN UA8.1
iBTS NodeB and Global Market
Purpose of this package: provide a method to determine CCM and CEM resources load and
blocking
List of counters, indicators or metrics to look at (through NPO tool)
Associated corrective action foreseen (ex tuning, resource addition)
Other UTRAN resources monitoring are not handled in this slide pack
Assumptions:
Network observed has right parameters settings, aligned with UPUG and HPUG [R5] and
CEM engg guide [R1] recommendations.
Recommendations
Regular monitoring : every month (or every 3 months)
Close monitoring for NodeBs with potential issues (high blocking rate, already resources
shortage identified) : every 2 weeks
5
CEM & CCM monitoring principles
Monitoring of CEM consists in :
Monitoring call admission blocking
Monitoring levels of CEM load (R99, HSDPA, EDCH resources, CPU) and failures
Taking into account Capacity Licensing deployed or not
Operational Method
Monitoring at NodeB User Plane Busy Hour (max traffic Iub UL+DL)
Threshold is considered crossed if several occurrences (eg 3 days/week, min 2 hours per day)
3 decision trees : CE R99, HSDPA, EDCH
Monitoring of CCM consists in :
Monitoring CPU load on CCM and failure rates
CCM handles the Load Balancing for CEM resources
CCM is impacted by Control Plane (NBAP procedures and NodeB configuration)
Operational Method
Monitoring at NodeB Control Plane Busy Hour (max RL Set Up request)
Threshold is considered crossed if several occurrences (eg 3 days/week, min 3 hours per day)
1 decision tree
Note: its important to monitor CCM CPU. Trend is evolving towards high signaling ratio and
short data calls networks, which are CCM CPU costly. See NodeB Call Model monitoring [R6]
6
Agenda
1 | CCM monitoring
2 | CEM R99 monitoring
3 | CEM general failures monitoring
4 | CEM HSDPA resources monitoring
5 | CEM EDCH resources monitoring
7
CCM CPU load background (1/3)
% of CCM CPU counters to be retrieved at Iub level:
U10403_CCM_Avg VS_cpuLoad_CCM_Avg
U10403_CCM_Max VS_cpuLoad_CCM_Max
Note : evaluated each second, and the .Min and .Max values are updated each 2 seconds
Note : U10403_CCM_Max may be 100%. Is not an issue (check 15 min details)
Background on CCM CPU load
iCCM CPU engg limit = 65% risk if threshold crossed = CCM trap and reset NodeB. Degraded KPI (delay
& call reject)
xCCM/ECCM CPU engg limit
70% before UA7.1.3.6 (no backpressure mechanism) risk if threshold crossed = risk of CCM trap and NodeB reset.
Degraded KPI (delay & call Reject)
60% in UA7.1.3.6 with backpressure mechanism enabled (CRE 139561, based on MailBox occupancy monitoring)
Backpressure mechanism protects the xCCM(-u)/eCCM-u.
65% in UA7138 (see [R8])
Rejects incoming RL Set Up Request while xCCM in overload condition (=CCM Managers mailbox msg size > 200)
Increased Call Reject (degraded RLSet Up Success Rate impact CallSetUpSuccessRate, RRCCnxSuccessRateH
Note1 : thanks to this backpressure mechanism, there is little risk that avg CCM CPU is above 60% (over one hour).
Note2 : Backpressure may start at avg CCM CPU < 60% : peak and burstiness of RLSetUpRequest (during a few min
or a few seconds) - eg registration storm. It can be also due to nb of RL Set Up Request increasing towards end of
observation period (1h granularity). For these specific cases, avg over 1 hour is not enough granularity ; 15 min would
be more accurate.
8
Background on CCM CPU load (followed)
xCCM/eCCM CPU engg limit
From UA814, overload protection feature available (BTSEquipment.reserved0)
If feature is not activated
Existing UA7.1.3 backpressure mechanism (only CCM Mailbox size (queue length) with a
threshold = 200 msg)
If feature is activated, xCCM(-u) & eCCM-u overload detection is based on
CCM Mailbox size (queue length) & CCM PQ3 CPU load
low threshold for CCM-MBOX = 300
low threshold for CCM-PQ3-PO = 75%
Check done
At every RLSetUp Request arrival (event)
Every 5 seconds (Periodic timer)
Corrective action:
Reject the new incoming RLset UpRequest when either of the low level of CPU or Mailbox
size threshold is crossed.
Hysteresis provided for the two resources being monitored to avoid ping-pong effect.
9
High unwanted contributor to CCM CPU NodeB Avg CCM CPU (before FLR patch)
avg CCM CPU load = f(# NBAP transactions/hr) Avg CCM CPU (after FLR patch)
Incorrect NodeB config (traces left active) increases 100
the CCM CPU load (critical for a loaded NodeB) 80
avg CCM CPU (%)

Its recommended to check traces are off (and Flight 60
Recorder FLR and BLOG should be standard) 40
Note: incorrect default FLR configuration before 20

UA713 (FLR are ON by default) causing high CCM CPU 0
Check traces ( see below extract from [R7] and [R8]):
17 97
20 04
25 77
28 45
29 3
30 91
31 9
33 64
33 3
35 21
5
0
8
3
2
3
4
1
4
2
2
9
10 6 0
45
83
58
75
58
40
76
27
33
20
18
88
85
44
01
9
8
8
7
8
6
2
3
5
2
0
2
7
1
8
4
16
21
23
26
29
32
39
46
55
68
78
86
# of NBAP transactions per hour
Blog should be configured with Type as follow :

Type : - - ERR
(Type : IN OUT ERR PSG should be avoided)
In UA813
If pltf.bci is present, it should be removed
10
above
below
week)
engg limit
Behaviour
engg limit
Behaviour
(non loaded
(loaded week)
Nb RLS Request vs % of CPU
U38_0
0
20
40
60
80
100
120
0:00
1:00
2:00
3:00
4:00
5:00
6:00
0
50 000
100 000
150 000
200 000
250 000
300 000
7:00
8:00
9:00
10:00
0:00 11:00
12:00
13:00
14:00
24-fvr.
4:00 15:00
16:00
17:00
18:00
19:00
20:00
8:00 21:00
Operational method
22:00
23:00
12:00 0:00
1:00
2:00
3:00
4:00
5:00
16:00 6:00
7:00
8:00
9:00
20:00 10:00
11:00
12:00
13:00
14:00
25-fvr.
Nb of RL Set Up Request
0:00 15:00
16:00
17:00
18:00
4:00 19:00
20:00
21:00
22:00
23:00
0:00
8:00 1:00
2:00
3:00
12:00 4:00
5:00
6:00
7:00
8:00
9:00
16:00 10:00
11:00
12:00
13:00
14:00
26-fvr.
20:00 15:00
16:00
17:00
18:00
0:00 19:00
20:00
21:00
22:00
4:00 23:00
0:00
1:00
2:00
3:00
4:00
8:00 5:00
11
6:00
7:00
12:00 8:00
9:00
10:00
11:00
12:00
13:00
16:00 14:00
27-fvr.
15:00
16:00
17:00
18:00
20:00 19:00
CCM CPU avg
20:00
21:00
0:00 22:00
23:00
0:00
1:00
2:00
3:00
4:00 4:00
5:00
Nb of RL Setup Failure (cause=0) (U38_0)

6:00
7:00

8:00 8:00
9:00
10:00
11:00
12:00 12:00
13:00
14:00
less loaded, then average on the Monday to Friday week)
28-fvr.
15:00
16:00
16:00 17:00
18:00
19:00
20:00
21:00
22:00
With only one day data, you may be in a specific bursty case
20:00
CCM CPU max
23:00
0:00
1:00
2:00
0:00 3:00
Failure level (GUYANCOURT_BOUVIERS)
4:00
CCM CPU load (GUYANCOURT_BOUVIERS)
CCM CPU load monitoring (1/5)
5:00
This method can apply to all metrics in decision trees
6:00
7:00
4:00
CCM CPU avg below engg limit (60% for xCCM from UA7136)
8:00
9:00
10:00
11:00
8:00 12:00
13:00
14:00
29-fvr.
15:00
16:00
12:00 17:00
18:00
19:00
20:00
16:00 21:00
22:00
23:00
0:00
20:00
1:00
2:00
3:00
4:00
5:00
6:00
0:00 7:00
8:00
9:00
10:00
4:00 11:00
12:00
13:00
14:00
1-mars
15:00
16:00
8:00 17:00
Total Nb of RL Setup Failures (URL001)
18:00
19:00
12:00 20:00
21:00
22:00
23:00
0:00
1:00
16:00 2:00
3:00
4:00
5:00
20:00 6:00
7:00
8:00
9:00
10:00
11:00
12:00
0
13:00
2-mars
14:00
20
40
60
80
15:00
16:00
100
120
17:00
18:00
19:00
CCM CPU avg
Avg CCM CPU load 20:00

21:00
Observation period: 1 week (5 or 7 days), hourly data (Granularity Period=1 hour)
22:00
Make an average over a week on max daily values for U10403_CCM_Avg (if week ends are
(%) 23:00
0:00
1:00
3-
2:00
mars
3:00
Check backpressure level?
Look at CCM Control Plane load (one hour GP) no
RLSetUpFailure due to backpressure
CCM CPU load level ? > 50% of total failure ?
VS_cpuLoad_CCM_Avg(%) 50% no
no yes
U10403_CCM_Avg(%) 50%
RL Set Up Request Failure Rate ?
yes Backpressure launched too often
RLSetUpFail_Rate < 2%
CCM limitation suspected
optional
yes Perform full NodeB capa study to
check if other user plane
resources shortage (Iub, CEM)
Is there another yes
resource bottleneck ?
No CCM limitation No CCM limitation
no
Other resources shortage
CCM limitation contributes to CCM CPU
Continue Regular Perform load
monitoring (once a month close Upgrade CCM Hw : Remove if possible bottleneck
to capture growing pace) monitoring - Macro: iCCM xCCM - Capacity param increase
- d2U: iCCM xCCM or eCCM - Add PCM
- else add NodeB or d4U - Migrate to hubrid Iub
Look again to CCM CPU load

Periodicity of monitoring
While U10403_CCM_Avg < 50% regular monitoring (every month) to capture growing pace
If 50%<U10403_CCM_Avg < engg limit (65% for xCCM12or eCCM-u ; 70% for iCCM) close monitoring
If U10403_CCM_Avg engg limit urgent action
COPYRIGHT neededALL RIGHTS RESERVED.
2011 ALCATEL-LUCENT.
CCM CPU depending indirectly on other resources (over)load or limitation
User Plane limitation creating indirect CCM CPU load
Resources shortage: increase NBAP transactions (RL Set Up Failures, RL reconf Failures,
Fallbacks which in turn increase RL Reconf)
Other NodeB resources limitation creating indirect CCM CPU load
Eg ATM Iub bandwidth shortage: increase NBAP transactions (increase RL Failures and user
retries)
Same for Codes or DL power issues
CCM Capacity may be impacted by change of Iub backhaul
ATM backplane configuration:
Hybrid Iub migration is OK (in UA713 in all cases ; in UA81 provided no centralized CCP(*))
Migration to NIP not recommended for loaded CCM NodeB (avg CCM CPU > 40%)
Native IP migration introduces 30% degradation on CCM capacity (both UA713 & UA8)
due to CCP relay
Migration to Ethernet backplane configuration (d2u or d4U only from UA814)
Ethernet backplane needed to support high throughput (60 Mbps DL with eCEM-u)
It introduces ~40% (tbc) degradation due to CCP relay + Ethernet backplane + CCP centralization
Not recommended for loaded NodeB (avg CCM CPU > 40%)
Centralization
13
Recommendation / upgrade path if CCM CPU is above engg threshold:

Remove any other bottleneck generating additional signalling load due to failures :
NodeB User Plane resource optimization or increase, Iub interface correctly
dimensioned
Check traces configuration and clean up if required: FLR, BLOG
HW upgrade: Macro NodeB (replace iCCM by xCCM), d2U NodeB (replace iCCM by
xCCM or eCCM-u)
Densification (d4U with eCCM-u or NodeB addition)
14
Main metrics to check (for decision tree)
Nb of RL Set Up request = RadioLinkSetupRequests_RL008_CR(URL008_CR)(Event)
Nb of RL Set Up Failures = RadioLinkSetupUnsuccess_RL001_CR(URL001_CR)(Event)
VS_RadioLinkSetupUnsuccess_RadioLinkSetupFailure(U38_0)(Event)
RLSR (Radio Link Set Up Request) Failure Rate
RLSetUpFail_Rate = URL001_CR/URL008_CR
CCM overload mechanism (backpressure)
No dedicated counter in UA81 for CCM overload mechanism
U38_0 includes backpressure mechanism, but not only (from call traces, it includes CEM processor
overload cause). Call Trace needed for exact NBAP cause mapping
U38_0 also includes CAC failures total EDCH users Hardware failures (nb10ms + 4*nb2ms 128
for xCEM or nb10ms + nb2ms 128 for eCEM). Indeed, there is no dedicated screening for this total
CAC failures (cause UL resources unavailable ). This case will generate a fallback to HSDPA-ULR99.
But there is no counter for RL failure due to EDCH CAC (fallbacks counter U1601_1+U1603_0 include
RL reconf failures also which over estimates the RL set up failure)
CCM is too often in overload when backpressure failures are more than 50% of total
failures...
U38_0 / URL001 > 50%
15
Other counters to monitor (1/2)
Nb of RL Set Up request = RadioLinkSetupRequests_RL008_CR(URL008_CR)(Event)
RL Set Up Failure rate = RadioLinkSetupUnsuccess_RL001_CR(URL001_CR)(Event)/URL008_CR)
Nb of RL addition Request = RadioLinkEstablishmentAttempts_RL028_CR_RLAddition(URL028_CR_RLAddition)(Event)
RL addition failure rate = RadioLinkAdditionUnsuccess_RL004_CR(URL004_CR)(Event) / URL028_CR_RLAddition
Nb of RL deletion Request = U5 +U6
VS_RadioLinkDeletionSuccess(U5)(Event)
VS_RadioLinkDeletionUnsuccess(U6)(Event)
RL deletion failure rate= U6/(U5+U6)
Nb of RL reconfiguration Prepare= URL011_CR +URL012_CR
RadioLinkReconfigurationPrepareSuccess_RL011_CR(URL011_CR)(Event)
RadioLinkReconfigurationPrepareUnsuccess_RL012_CR(URL012_CR)(Event)
RL reconf prepare failure rate = URL012_CR/(URL011_CR+URL012_CR)
Nb of RL reconfiguration Commit =
RadioLinkReconfigurationCommit_RL052_CR(URL052_CR)(Event)
Nb of RL reconfiguration Cancel =
VS_RadioLinkReconfigurationCancel(U26)(Event)
Nb of DL Power Control (SHO contribution) request =
Linked with Soft HO
RadioLinkSetupRequests_RL008_CR(URL008_CR)(Event)-FirstRadioLinkSetupRequest_RL051_CR(URL051_CR)(Event)
Nb of Compress Mode Request ~ umeas008*RL015_C/RL015_R
CompressedModeActivationSuccess_Meas008_R(UMeas008_R)(Event)
NumberOfActiveUsers_RL015_CR(URL015_CR)(nb) taken at RNC (RL015_R) and at NodeB (RL015_C) levels

Other counters to monitor (2/2)
NBAP RL Reconfiguration call flows
RL011+RL012 are equivalent to nb of RL Reconf Prepare sent to NodeB
Node B Successful case

Node B RNC
Radio Link Reconfiguration Prepare
Radio Link reconfiguration Ready Msg RL reconf ready ok received

Radio Link reconfiguration Ready Peg RadioLinkReconfigurationPrepareSuccess_RL011_CR
Radio Link Reconfiguration Commit

Radio Link Reconfiguration Commit
Msg RL reconf commit sent
Peg RadioLinkReconfigurationCommit_RL052_CR
Node B
Unsuccessful case
Node B RNC
Msg RL reconf failure received or timeout
Radio Link reconfiguration Failure
Peg RadioLinkReconfigurationPrepareUnsuccess_RL012_CR
Radio Link reconfiguration Ready
Radio Link Reconfiguration Cancel Msg RL reconf cancel sent

peg u26

Agenda
1 | CCM monitoring
2 | CEM CPU monitoring
18
CEM CPU load monitoring (1/5)
Isolate xCEM or eCEM among (One hour GP, at board level)
all boards monitored
Is board monitored a xCEM or eCEM? Yes Check avg CEM CPU at BH ?

VS_cpuLoad_CEM_NbEvt(U10403_CEM_NbEvt)(Event) ~ 12 VS_cpuLoad_CEM_Avg(U10403_CEM_Avg(%)
U10403_CEM_Avg50%
No Low CPU
50% < U10403_CEM_Avg<70%
Medium CPU
70% U10403_CEM_Avg
High CPU
Ignore the board No x/eCEM x/eCEM limitation

No x/eCEM
limitation limitation
Max CEM CPU at BH yes
VS_cpuLoad_CEM_Max(U10403_CEM_Max(%) > 80%
U10403_CEM_NbEvt Continue Perform
~ 3600 iCEM regular close no Very high load
= N/A other boards monitoring monitoring High load (CEM trap possible)
(CCM, RRH, TRM)
Periodicity of monitoring Check all CEMs from NodeB:

Regular monitoring (every month, or every 3 If iCEM boards present replace iCEM by xCEM or eCEM
If only x/eCEM check if their load is balanced.
months) to capture growing pace
1) If balanced, then add xCEM/eCEM (if not possible d4U or NodeB
Close monitoring (every 2 weeks) to anticipate densification )
action 2) If not balanced, check param setting (activate HSxPA resources on
engg limit urgent action all boards, check HSXPA cell distribution on CEM) for better HSxPA
traffic balance. If no optim possible, then replace xCEM by eCEM
19
or add xCEM/eCEM (if possible see case 1)
U10403_CEM_Avg VS_cpuLoad_CEM_Avg PQ2
icem: U10403_CEM_Max VS_cpuLoad_CEM_Max PQ2
U10403_CEM_Avg VS_cpuLoad_CEM_Avg PQ3

x/ecem:
Since UA7138 and in UA81: U10403_CEM_Max VS_cpuLoad_CEM_Max PQ3
eCEM and xCEM : U10403 is related to PQ3 (CR00513265.10.t01, FRS121456),

sampling period = every 5 min. Note: in LR13.1, the sampling period will be 1.6
second (FRS 125406)
iCEM : U10403 remains related to PQ2, sampling period = every 1 second
CEM CPU load becomes a good indicator for CEM processors occupancy only
for x/eCEM (most loaded processor - PQ3- load can be monitored)
CEM CPU monitoring at NodeB or Iub level is meaningless if NodeB has a mix
of iCEM and x/eCEM (they refer to different processor load)
Engg limit for avg x/eCEM PQ3 CPU = 70%
PQ3 mainly impacted by nb of users (R99+HSDPA ) and HSDPA throughput
Double check : engg limit for max x/eCEM PQ3 CPU = 80%
The sampling period being high (5 min), we recommend to look also at max
CEM CPU, to double check (burstiness, missing high loaded periods). Max CEM
CPU threshold can be set to 80%.

Engg limit for iCEM PQ2 CPU ?

No engg limit defined for avg PQ2 CPU
Field observation in UA7 shows that an avg CEM CPU PQ2 = 20% corresponds to high CEM
CPU PQ3 load (but its call model dependant)
NodeBs with iCEM board(s)

As no CPU can be monitored on iCEM boards, you need to rely on other resources load
(R99CE, HSxPA resources)
Note: in LR13.1, other x/eCEM processor CPU monitoring will be

introduced (PQ3, DSP, OC, mailbox)
Reminder:
PQ2 : mainly loaded by R99 traffic
PQ3 : mainly loaded by HSxPA traffic
21
Operational method
Thanks to different sampling period, we can differentiate e/xCEM for iCEM
simply relying on counter VS_cpuLoad_CEM_NbEvt(U10403_CEM_NbEvt)(Event)
at hourly level
~ 12 for e/xCEM (hourly)
~ 3600 for icem (hourly)
On NPO, retrieve 3 counters at BOARD level, hourly details. One sheet per
counter, with date in column, boards in row.
VS_cpuLoad_CEM_NbEvt(U10403_CEM_NbEvt)(Event)
VS_cpuLoad_CEM_Avg(U10403_CEM_Avg)(%)
VS_cpuLoad_CEM_Max(UC10403_CEM_Max)
Postprocessing method
Filter on excel, to focus only on CEM boards (not RRH, not CCM, not TRM)
Filter on excel, to focus on x/eCEM (only select NbEvt = 12)
(postprocessing tool available on demand)

Recommendations
Preventive monitoring recommended to avoid CEM PQ3 CPU overload
Note: overload control mechanism under study for UA91 / LR13
Actions
Check if HSxPA resources enabled on all xCEM of a NodeB (eg in ORF, some
xCEM are only configured with d resources)
Add xCEM if possible (with multiple xCEM per carrier activation)
Replace iCEM by xCEM, move to all xCEM NodeB configuration (with multiple
xCEM per carrier activation)
If not enough, upgrade xCEM to eCEM
If not enough, replace NodeB by d4U (up to 5 CEM in UA814) or add a NodeB
(NodeB densification). Note, in LR13.1, D4U will support up to 6 x/eCEM-u
supported with eCCM-u (or 5 x/eCEM-u if xCCM-u)

x/eCEM CPU: behaviour in high load
x/eCEM CPU behaviour in high load by courtesy of
Degraded KPI (HSxPA throughput mainly) R&D KPI prime
Risk of CEM trap or CEM flip/flop (due to CPU blocked in overload)
Impact on nb of Rach Nacks (tracked by counter VS_RachNack_Avg (U10303_Avg)):
no demodulation unit available to decode an incoming RACH. Observed on A1TA -
suspected to be correlated with high CEM load.
CR examples with trap when CPU load reaching 100% (CTR IS STUCK
failure) :
UA8.1.3 - CR798010 (duplicate CR796866) : xCEM traps due to PQ3 blocked in
overload during SKT pilot in UA8.1.3
UA8.1.4 - CR796866 : LGE test results : xCEM traps due to PQ3 blocked in overload
during Endurance Tests
Reason "PQ3 trap: tSwwdTask, CTRL IS STUCK
From IMT logs, in case of CEM CPU load = 100%, we observe that :
Task HsDataHdl uses approx. 45% CPU and idle task isnt present. It denotes a CPU usage at 100%.
Task UcuSanity (priority 200) generates message "CTRL IS STUCK when it doesn't have CPU time
during more than 72 sec. This is detected by tSwwdTask Task (watchdog task with the highest priority
(Prio 0) which wakes up periodically and monitors UCUSanity, TAppMonTask and TSysMonTask tasks)
Worked as design (normal behavior because we are over the maximum load of x/eCEM)

x/eCEM CPU some examples (1/2)
Example of NodeB with 4 xCEM only balanced load
Example of NodeB with 2 xCEM only unbalanced load (only one xCEM
provisionned with d+h+e)
d+h+e

x/eCEM CPU some examples (2/2)
Example of distributions CRITICAL on many networks

Agenda
1 | CCM monitoring
2 | CEM CPU monitoring
27
R99 CE monitoring decision tree
At iub level: R99 CE load
no
% of R99 CE used (worst UL, DL) > x%
Warning = 50%, red = 70% ?
yes Check burstiness:
High average R99 CE load max R99 CE load (from UA81 only)
(CE R99 near resource exhaustion)
yes At iub level:
In case of proactive monitoring:
add directly R99 CE resources Max % of R99 CE load > y% (warning = 75%, red= 90%)
no
R99 CE CAC failure check R99 CE failures
Check R99 CE failure rate ? Green or 0%
% of R99 CE allocation failure > 0%
Red > 5% - 0.5% < Yellow < 5% - green <0.5%
Red or yellow Green = Small R99 0% = No R99 CE
Case no capa licensing Case capa licensing (finite value CE failure rate failure rate
r99NumberCECapacityLicensing)
HW fail: make sure (UL&DL) CEM load in iRM is activated Close monitoring recommended R99 CE resource
(isCEMColourCalculationEnabled= true) and tune iRM
thresholds (more aggressive to decrease the nb of high OK
data rate RB UL & DL) If still blocking: add add CEM Hw
SW fail: in case of xCEM presence, check value of Increase R99 license (D token) :
r99MaxNumberCeXcem parameter (must be either =0
(R99 on iCEM only) or can be increased (commercial
r99NumberCECapacityLicensing
agreement) so that r99MaxNumberCeXcem 256 * and readapt iRM CEM load Look for HSxPA
Nb_xCEM. If still blocking; add CEM Hw thresholds accordingly Resource shortage
add R99 HW resources : add xCEM or upgrade iCEM to

28
x/eCEM. If not enough, replace NodeB by d4U COPYRIGHT or NodeB 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
densification
Reminder on R99 CE consumption (1/2)
R99 CE consumption for HSXPA calls (on x/eCEM)
Type of SRB supported
SRB over DL DCH/UL DCH (from forever)
SRB over DL DCH/UL EDCH (from ua6 onwards ; feature 33581 SRB on EDCH)
SRB over DL HSDPA/UL EDCH (from UA814, feature F-DPCH)
Single cell HSDPA calls

HSDPA call (UL R99), SRB over DCH N CE UL (for associated UL R99+SRB) and 0.3
or 0.5 CE DL (for associated SRB 3.4 or 13.6) . 1 HSDPA connection for TRB (among
128)
Dual Cell HSDPA calls

R99 CE consumed for Dual Cell call is same as single cell HSDPA call
But 1 Dual Cell HSDPA call consumes : 2 HSDPA connections for TRB (among 128) + 1
EDCH connection for TRB (among 128)
In ALU, DC-HSDPA call is mandatorily UL TRB EDCH
29
Reminder on R99 CE consumption (2/2)
R99 CE consumption for HSXPA calls (on x/eCEM)
EDCH calls 10ms (resp 2ms) call
EDCH call (SRB over DCH/DCH) 1 CE UL (for associated SRB) and 0.3 or 0.5 CE DL
(for associated SRB 3.4 or 13.6). 1 (resp 4) EDCH connection for TRB (among 128)
&1 HSDPA connection for TRB (among 128)
EDCH call (SRB over DCH/EDCH) 1 CE UL (to process UL HS-DPCCH) and 0.3 or 0.5
CE DL (for associated SRB 3.4 or 13.6). 1 (resp 4) EDCH connection for TRB (among
128) &1 HSDPA connection for TRB (among 128)
EDCH call (with SRB R99 part & EDCH part mapped onto different CEMs; this is the
case when SRB established on xCEM1 (no HSXPA resources) then TRB moved to
xCEM2 (having HSXPA resources)) Double decoding (feature 111451 inter-cem call
migration descoped from UA8.1)
On CEM hosting the EDCH part, 1 CE UL consumed for silent-DCH (UL HS-
DPCCH), 0 CE DL (?). 1 (resp 4) EDCH connection for TRB (among 128) &1 HSDPA
connection for TRB (among 128)
On CEM holding SRB R99, 1 CE UL (for SRB) and 0.3 or 0.5 CE DL (for SRB 3.4 or
13.6). 1 (resp 4) EDCH connection for TRB (among 128) &1 HSDPA connection for
TRB (among 128)
EDCH call, SRB over HSDPA/EDCH (from UA814) requires F_DPCH, 0.3 CE DL (for
F-DPCH in DL) and 1 CE UL (to process UL HS-DPCCH)
30
R99 CE load (1/9) New in
UA8.1
CE usage (at NodeB or Iub level):
Counter U10317 adapted
Applicable to capacity licensing deployed or not
Takes into account worst case between UL and DL load
Avg % of R99 CE used (worst UL, DL):
Threshold : warning = 50%, red = 70%
% of R99 CE used (worst UL, DL) = U10317_3/min(U10317_2; U10317_1)
Note: U10317_3 = max (CE UL Cum used, CE DL cum used)
Max % of R99 CE used (worst UL, DL) from UA81:
Threshold : warning = 75%, red = 90%
= U10317_10/availableR99CECapa = U10317_10/min(U10317_2/U10317_NbEvt;
U10317_1/U10317_NbEvt)
= UR99CECpty010_xCEM_C/min(U10317_2/U10317_NbEvt; U10317_1/U10317_NbEvt)
Note : U10317_10 to be taken with care. Default aggregation rule on NPO (temp= sum,
aggreg=sum) is false for temporal. Any daily aggregation (or greater aggregation than the
pmobservationperiod granularity) is false. You should use instead a user defined indicator
_R99CEMaxUsed_R99CECpty010_xCEM_C(UR99CECpty010_xCEM_C)(CE) (will be available
under user defined/capacity licensing if you load the xml available in [R10])
MaxUsed : report the maximum used value for every sampling period of 5 seconds.
At each triggering time (t) (i.e, every 5 seconds): if the CumUsed(t) is not 0 Then determine the
MaxUsed
MaxUsed is determined similar to the way it is done for the MAX field of a load counter i.e, comparing the
Max value stored with the CumUsed(t) value.
Note: because of this sampling period of 5sec, we may miss a real max value. Thus, we may
31
see some failure (U10317_5) whereas the U10317_10 < availableR99CEcapa
R99 CE load (2/9)
R99 CE limited by software (parameter) or hardware:
if U10317_2 < U10317_1 limitation due to parameter (software)
Else limitation due to hardware
If avg or max thresholds are reached, additional R99 capacity needs to be
added (software or hardware)
Case no capacity licensing :
if U10317_2 < U10317_1 (software limitation) : increase r99MaxNumberCeXcem up to
256*nb_x/eCEM, step by step (min step = 16). Note: normally this case should not happen as per
ALU recommendation (see [R1], r99MaxNumberCeXcem 256 * Nb_x/eCEM). However, ORF(for
example) does not observe ALU recommendation regarding this parameter. We need to proceed
step by step, in order to check the whole NodeB resources usage (to avoid an overload of
another resource)
Else (hardware limitation): additional CEM is needed or upgrade iCEM to xCEM/eCEM
If max slot capacity is reached (no more CEM can be added): d4U can be introduced to replace
macro or d2U iBTS (from UA814)
Case capacity licensing :
Current nb of D tokens = availableR99CECapa / 16 = min(U10317_2/U10317_NbEvt;
U10317_1/U10317_NbEvt) / 16
Max nb of D tokens = HWR99CECapa/16 = (U10317_1/U10317_NbEvt) / 16
If current nb of D token < Max nb of D tokens increase r99NumberCECapacityLicensing via
additional D token
Else (hardware limitation) : additional CEM is needed or upgrade iCEM to xCEM/eCEM
If max slot capacity is reached (no more CEM can be added): d4U can be introduced to
replace macro or d2U iBTS (from UA814)
32
R99 CE load (3/9)
Avg Nb of R99 CE used
New in UA81 : Nb of R99 CE used (unit CE)= U10317_3/U10317_7=
U10317_3/UR99CECpty004r_B_CEM = R99CEUsedAvgActiveEvt_R99CECpty004active_B_CEM
(based on active event)
Also valid before UA81 : Nb of R99 CE used (unit CE)= U10317_3/U10317_NbEvt =
VS_R99CECapacity_CumUsed/VS_R99CECapacity_NbEvt =
R99CEUsed_R99CECpty004_B_CEM(UR99CECpty004_B_CEM)(nb) (based on normal event)
Note1: the basic indicator U10317_7 does not have appropriate aggregation rule
(temp=sum, spatial=sum) whereas it should be (temporal= sum, spatial = avg).
R99CEUsedAvgActiveEvt_R99CECpty004r_B_CEM(UR99CECpty004r_B_CEM)(Event) is defined
as VS_R99CECapacity_NbEvtActive indicator with Spatial aggregation Avg
Note2: there is no big difference between Events and Active Events. Indeed
VS_R99CECapacity_NbEvt(U10317_NbEvt)(Event) and
R99CEUsedAvgActiveEvt_R99CECpty004r_B_CEM(UR99CECpty004r_B_CEM)(Event) have
similar value. U10317_NbEvt has appropriate aggregation rules (temp=sum, spatial=avg) in
UA81
Other indicators available under Extended/Capacity Licensing/Channel
Elements path (also in UA7):
HW installed R99 CEs: R99CEMaxHW_R99CECpty003_B_CEM(UR99CECpty003_B_CEM)(nb)
U10317_1/U10317_NbEvt
SW installed R99 CEs: R99CELicenseUsed_R99CECpty002_B_CEM(UR99CECpty002_B_CEM)(nb)
U10317_2/U10317_NbEvt
corresponds to either r99MaxNumberCeXcem or r99NumberCECapacityLicensing values
UR99CECpty002_B_CEM R99CELicenseUsed_R99CECpty002_B_CEM VS_R99CECapacity_CumLicensing/VS_R99CECapacity_NbEvt
UR99CECpty003_B_CEM R99CEMaxHW_R99CECpty003_B_CEM VS_R99CECapacity_CumHWcapacity/VS_R99CECapacity_NbEvt
UR99CECpty004_B_CEM R99CEUsed_R99CECpty004_B_CEM VS_R99CECapacity_CumUsed/VS_R99CECapacity_NbEvt
33
R99 CE load (4/9)
New in UA8.1 are :
R99 CE Used standard deviation (during active events): UR99CECpty004stddev_B_CEM
Based on CumSquareUsed = (cum used) =U10317_8 +2^32 * U10317_9 with
2^32=exp(32ln(2))
Note : cumSquareUsed" could sometimes be > 2exp32 (whereas screening is coded on 32
bit integers), therefore its "split" into 2 different screenings #8 and #9, that can both fit in a
32bit integer.
Check if working ?
2 2
CumUsed CumUsed
= std_dev = ( ) (finite population with equal probabilities at all points)
NbEvtActiv e NbEvtActiv e
R99CEUsedCptyIndicator_R99CECpty004indic_B_CEM = Min (max_used , 3* +

average_active) :
R99 CE Used Capacity indicator for pay as you use strategy (a real max as it excludes some
very high value of max_used (and very seldom) that should not be counted (not to penalize
the customer).
R99CEUsedCptyIndicator_R99CECpty004indic_B_CEM(UR99CECpty004indic_B_CEM)(nb)
Avg + 3* ~ 99% of samples

34
R99 CE load (5/9)
Note: VS_R99CECapacity _xxx(U10317_xxx) is at NodeB level
This is near the NodeB load balancing implementation (nodeb is supposed to
balance the R99Resource usage among all available boards on the BTSEquipment).
Adapted for capacity study in general
Exception: when some LCG uses different R99Resource object (see R99Resource
under LocalCellGroup in the Ran model). In that case the NodeB splits the R99
Resources into 2 R99 pools, while the counter still evaluate the overall capacity.
But there are other counters available per cell or per local cell group that
helps to complement the picture in that case (e.g 10318 or 10309).
35
R99 CE load (6/9) Data currently reported by U10310
are not fully reliable and
R99 CE used (UL and DL details ; per LCG) recommendation is to avoid using it
Unit = number of CE
Note: RTC/BCI menus on CCM through which UL and DL capacity can be dumped on
console. In these dumps, CallP prints the Free/Used DL/UL capacity in units of CE*10.
This may cause confusion. Real unit is CE
Most useful ones are listed below (complete list in next slide):
U10310_1_Max VS_LocalCellGroupLoad_UsedUL_Max
U10310_3_Max VS_LocalCellGroupLoad_UsedDL_Max
U10310_0_Min VS_LocalCellGroupLoad_FreeUL_Min
U10310_2_Min VS_LocalCellGroupLoad_FreeDL_Min
This allows to spot R99 carrier strategy and unequal load of carriers
It may happen that despite an average or max R99 CE usage at NodeB level below red
threshold, there are some failures observed: it may be due to unbalanced carriers
(LCG) R99 load, linked with operator traffic segmentation and redirection strategy
(iMCTA, iMCRA may be tuned).
However, as LCG can be shared on several CEM, counter values are only consistent at
NodeB level (not at LCG level)
U10310_0_Avg VS_LocalCellGroupLoad_FreeUL_Avg U10310_2_Avg VS_LocalCellGroupLoad_FreeDL_Avg

U10310_0_Cum VS_LocalCellGroupLoad_FreeUL_Cum U10310_2_Cum VS_LocalCellGroupLoad_FreeDL_Cum
U10310_0_Max VS_LocalCellGroupLoad_FreeUL_Max U10310_2_Max VS_LocalCellGroupLoad_FreeDL_Max
U10310_0_Min VS_LocalCellGroupLoad_FreeUL_Min U10310_2_Min VS_LocalCellGroupLoad_FreeDL_Min
U10310_0_NbEvt VS_LocalCellGroupLoad_FreeUL_NbEvt U10310_2_NbEvt VS_LocalCellGroupLoad_FreeDL_NbEvt
U10310_1_Avg VS_LocalCellGroupLoad_UsedUL_Avg U10310_3_Avg VS_LocalCellGroupLoad_UsedDL_Avg
U10310_1_Cum VS_LocalCellGroupLoad_UsedUL_Cum U10310_3_Cum VS_LocalCellGroupLoad_UsedDL_Cum
U10310_1_Max VS_LocalCellGroupLoad_UsedUL_Max U10310_3_Max VS_LocalCellGroupLoad_UsedDL_Max
U10310_1_Min VS_LocalCellGroupLoad_UsedUL_Min U10310_3_Min
36 VS_LocalCellGroupLoad_UsedDL_Min
U10310_1_NbEvt VS_LocalCellGroupLoad_UsedUL_NbEvt U10310_3_NbEvt VS_LocalCellGroupLoad_UsedDL_NbEvt
R99 CE load (7/9)
R99 CE used (UL and DL details ; per LCG) - followed
U10310: based on all the nb of R99 CE on all CEM within a BTS (icem+xcem CE
from UA7, see 1-3017153)
AR 1-301715: in UA7, in case of xCEM and iCEM mixity in a nodeB, all CE available for
DCH on iCEM + xCEM are counted. In UA6: in case of mixity of CEM cards, ONLY CE of
iCEM were counted. Number of CE in the xCEM was ignored.
Note: in case of capacity licensing deployed (r99NumberCECapacityLicensing
finite) or pseudo licensing (r99MaxNumberCeXcem), is the software CE capacity
taken into account (tbc)?
U10310 should not be used per LCG as LCG can be shared between several CEM
boards. Use at NodeB level instead
Per LCG, there is no consistency between sum(used+free) vs total (AR 1-3524842)
Per LCG, risk of erroneous value at LCG level in case of several LCG
At NodeB level, compare freemin + usedmax (tbc)
Note1: baseline CEDCHUsage_Board002_B(UBoard002_B)(%) is not significant, as
it averages UL & DL
UBoard002_B = (U10310_1_cum +U10310_3_cum) /(U10310_1_cum +U10310_3_cum +
U10310_0_cum +U10310_2_cum)
Note2 : several AR in previous releases
AR=1-3017153 : VS_LocalCellGroupLoad_FreeDL_Min ?
U10310_0_avg : AR 1-2685030 CR 289497 (+ load balancing) ?
U10310_1_Avg : AR Token leakage (1-26657321) CR289497 ?
37
U10301_Avg VS_CEMUsedDCH_Avg
R99 CE load (8/9) U10301_Cum
U10301_Max
VS_CEMUsedDCH_Cum
VS_CEMUsedDCH_Max
U10301_Min VS_CEMUsedDCH_Min
U10301 (VS_CEMUsed_DCH) unit = %, at NodeB level U10301_NbEvt VS_CEMUsedDCH_NbEvt
Def: ratio between the CEM capacity used and the total CEM capacity that was available at the
BTS startup, restricted to DCH
Not recommended for R99 CE load rather use U10317 (VS_R99CECapacity)
U10301_avg refers to HW or SW capa and does not take into account R99 capa licensing. Indeed
U10301_avg does not take into account R99 capacity licensing (r99NumberCECapacityLicensing)
value nor (r99MaxNumberCeXcem)
1) In case there are no xCEMs then it refers only to the HW capacity, the cumulation of the maximum
number of CEs supported for all the CEMs. Note: very few cases with only iCEM.
2) In case there is an xCEM and R99MaxNumberCeXcem = {0 or 1}, then it refers to the SW capacity.
Note: this special case of R99MaxNumberCeXcem = 1 happens when multiple LCG pools+xCEM
present + r99MaxNumberCeXcem=0, CCM-OAM internally sets R99MaxNumberCeXcem to 1.
3) In case there is an xCEM and R99MaxNumberCeXcem >1, then it refers also to the HW capacity.
U10301 refers to DSP load or CE load
Case B & C:
VS_CEMUsedDCH_Max = Max CE load = Max (max_Used_CE_UL; max_Used_CE_DL) / Avail_CEs
VS_CEMUsedDCH_Avg = Avg CE load = Max (Avg_Used_CE_UL; Avg_Used_CE_DL) / Avail_CEs
CaseB: Avail_CEs = Min(r99MaxNumberCeXcem; 256 * # xCEM)) + if ( ICEM present; 64*#iCEM_DBBU ; 0)
CaseC: avail_CEs = Min(r99NumberCECapacityLicensing; if(iCEM present; 64*# iCEM DBBUs;0) + 256*# xCEM)
However, min screening (during the day, probably at night) can be used to provide info on
Common Channels utilization R99 on iCEM only R99 on both iCEM & xCEM or on xCEM only
r99MaxNumberCeXcem=0 r99MaxNumberCeXcem 0
Capacity Licensing infinite (deactivated) case A : case B :
R99NumberCECapacityLicensing = infinite VS_CEMUsedDCH --> DSP load VS_CEMUsedDCH --> CE load
Capacity Licensing finite (activated) 38
case C :
R99NumberCECapacityLicensing = finite VS_CEMUsedDCH --> CE load
R99 CE load (9/9)
Not possible to compare U10301_x(VS_CEMUsedDCH_x) &

U10310_x(VS_LocalCellGroupLoad_x)
CEM board capacity & CEM capacity model at RNC slightly de-correlated
RNC estimation of R99 CE load
U10310_x (VS_LocalCellGroupLoad_x) and CEM color metrics should be in line (thanks to
CEM iRM thresholds configuration see UPUG)
However, in case of iCEM + xCEM mix, it is possible to have some mismatches (different
algo). But limited mismatches due to iRM threshold setting strategies see UPUG).
R99 CE load estimation by NodeB R99 CE load estimation by RNC

BTS counter : Algo :
U10310_x (VS_LocalCellGroupLoad_x)
Domain : to be aggregated at NodeB level (else erroneous)
both iCEM & xCEM CE models
RNC counter :
U1177_x = VS_QosDlCemLdClrYellow_x
BTS counter :
U10301_x = VS_CEMUsedDCH_x
U1178_x = VS_QosDlCemLdClrRed_x Algo :
U1153_x = VS_QosDLCemLdClrBlack_x
Domain : NodeB level
U1180_x = VS_QosUlCemLdClrYellow_x only iCEM model (pessimistic
U1181_x = VS_QosUlCemLdClrRed_x view)
U1201_x =VS_QosUlCemLdClrBlck_x
U1179_x = VS_QosDlCemLdCellPreemptClrCngstd_x
Domain : cell level
39
R99 CE failures (1/8) New in
UA8.1
R99 CE blocking (at Iub level)

Counters :
U10317_5 pegged: CE R99 blocking (parameter
or software limit)
U10317_6 pegged: CE R99 blocking (Hw limit)
R99 CE failure rate (%) 1st metric
= [VS_R99CECapacity_AllocHWfail(U10317_6)(CE) +
VS_R99CECapacity_AllocLicensingRefusal(U10317_5)(CE) ] /
[VS_R99CECapacity_AllocSuccess(U10317_4)(CE) + VS_R99CECapacity_AllocHWfail(U10317_6)(CE) +
VS_R99CECapacity_AllocLicensingRefusal(U10317_5)(CE) ]
Test = R99 CE failure rate > 0% (yellow threshold = 0.5%, red threshold = 5%)
If high R99 CE failure rate but low average R99 CE load : more investigation may be
done (eg per LCG, per SF .) or burstiness or board trap ?
If high R99 CE failure rate with high average R99 CE load : in phase, more CEM capacity
needed
U10317_5: CR359725 implemented in UA7 and in UA813 EP4 (not in early UA81)
CR359725 remove the xCEM CAC in RLReconf. When CapacityLicensing =0xFFFF (not activated) and
Nb iCEM <> 0, Nb xCEM<>0 and r99MaxNumberCeXcem <> 0, then r99MaxNumberCeNodeb =
r99MaxNumberCeXcem + 64*NbdBBU. NodeB shall only do the CAC on r99MaxNumberCeNodeb and
not on the r99MaxNumberCeXcem.
Without CR359725 we observe an increased VS_R99CECapacity_AllocLicensingRefusal(U10317_5)
40
R99 CE failures (2/8)
R99 CE CAC failure (UL and DL details, per SF details, LCG level counters) - continued
Note : counters only for DCH - HSxPA channels excluded (by definition)
which R99 RB data rates are blocking (UL or DL or both). Can help to tune the iRM thresholds if needed
CEMAllocFailxxx pegged for lack of CEM resources for RadioBearerEstablishmentUnsuccess & for RL Reconf Fail due to
transition failure for RbRate_Adapt or Irm_Sched or AO Upsize, for RL Setup on SHO too.
Note: in case of EDCH fallbacks (to R99 EDCH NodeB CAC) , more DCH are consumed, generating DCH resources shortage
U10311_0 VS_CEMAllocSuccessUL_SF4 U10312_0 VS_CEMAllocSuccessDL_SF4
U10311_3 VS_CEMAllocSuccessUL_SF32 U10311_x = U10312_y U10312_3 VS_CEMAllocSuccessDL_SF32
U10313_0 VS_CEMAllocFailedUL_SF4 U10314_0 VS_CEMAllocFailedDL_SF4
U10315_0 VS_CEMAllocFailedBothUL_SF4 U10316_0 VS_CEMAllocFailedBothDL_SF4
U10315_3 VS_CEMAllocFailedBothUL_SF32 U10315_x = U10316_y U10316_3 VS_CEMAllocFailedBothDL_SF32
U10315_4 VS_CEMAllocFailedBothUL_SF64 1 failure (UL & DL) pegs U10316_4 VS_CEMAllocFailedBothDL_SF64
U10315_5 VS_CEMAllocFailedBothUL_SF128 -- one counter U10315_x U10316_5 VS_CEMAllocFailedBothDL_SF128
U10315_6 VS_CEMAllocFailedBothUL_SF256 -- one counter U10316_y U10316_6 VS_CEMAllocFailedBothDL_SF256
1 success (UL & DL) pegs
-- one counter U10311_x
Equivalence between counters -- one counter U10312_y
CEM Allocation UL Success UL failure
U10311 (per UL SF)
CE success (both UL & DL) : 10311_x = 10312_y U10313 (per UL SF)
DL success U10312 (per DL SF)
CE Failure (both UL & DL ): 10315_x = 10316_y U10315 (per UL SF)
Total CE Failure (UL only, DL only, UL & DL) : U10314 (per DL SF)
DL failure U10316 (per DL SF)
10313_x + 10314_y + 10315_z = 10309_z (z 0) CEM Allocation UL Success UL failure
DL success U10309_0
U10309_x (x0)
DL failure
41
R99 CE CAC failure (cell level counter #10318):
At cell level, nb of times CE R99 resources allocation succeeds or fails (due to no CE R99
resource available) with different type of calls origin. Its always related to the DCH part
U10318_0 VS_CEMAllocDCH_AllocSuccessDCH
U10318_1 VS_CEMAllocDCH_AllocFailDCH
U10318_2 VS_CEMAllocDCH_AllocSuccessHSDPA
U10318_3 VS_CEMAllocDCH_AllocFailHSDPA
U10318_4 VS_CEMAllocDCH_AllocSuccessEDCH
U10318_5 VS_CEMAllocDCH_AllocFailEDCH
U10318 : to confirm R99 traffic has increased (higher due to more HSxPA fallback)
In phase with VS_Edch2msTtiTo10msTtiFallbackSuccess(U2895) &
VS_Edch2msTtiTo10msTtiFallbackUnsuccess(U2897)
Note: U10318_5 (CEMAllocDCH_AllocFailEDCH) behaviour changed with CR 649468
(from UA7138 EP10 and in UA813)
When a 2ms EDCH calls fails due to credits and is fallbacked to 10ms (with 125171, Node B
E-DCH CAC feature): U10318_5 is not pegged anymore (it was pegged before)
Rational : its not a HW bottleneck
[xCEM][eCEM in UA7138] nb10ms+4*nb2ms <= maxNbEdchCreditsForXcem
(BTSEquipment.reserved2.byte0)
[eCEM from UA81] nb10ms+nb2ms <= maxNbEdchCreditsForEcem (BTSEquipment.reserved2.byte1)
Note1: in the same manner, VS_eDCHUsersCapacity_HSXPA_AllocHWfail(U10909_6) is no more pegged
Note2: the associated NBAP failure cause is Not enough User Plane Processing Resources
42
R99 CE CAC failure (cell level counter #10318) followed
U10318_0: incremented when a r99 call [DCH in UL&DL] is setup (no HSD / HSU
component)
U10318_1: incremented when a R99 call (DCH in UL&DL) fails to setup or when an EDCH
call (regardless UL SRB over DCH or EDCH) fails to setup (and fallback to R99 fails too). In
this latter case, U10318_5 is not pegged (only U10318_1).
U10318_2: incremented when a HSDPA- UL R99 call is setup. This is related to 1 CE
allocation success for the UL DPCCH or FDPCH ?
U10318_3: incremented when a HSDPA- UL R99 call fails to set up. This is related to 1 CE
allocation failure for the UL DPCCH or FDPCH ?
U10318_4: incremented when a EDCH call (regardless UL SRB over DCH or EDCH) is setup.
This is related to 1 CE allocation success for the UL DPCCH
U10318_5: incremented when a EDCH call (regardless UL SRB over DCH or EDCH) fails to
setup and is fallback to R99 successfully. This is related to 1 CE allocation failure for the
UL DPCCH
43
R99 CE failures (5/8) Verifier les
mtriques
R99 CE CAC failure (cell level counter #10318) followed
Cases
EDCH CE totally consumed and R99 CE are still available: at EDCH call setup (regardless UL SRB is
over DCH or EDCH) : we peg U10318_5(VS_CEMAllocDCH_AllocFailEDCH) &
U10909_HSXPA_6(VS_eDCHUsersCapacity_HSXPA_AllocHWfail)
EDCH CE available and R99 CE totally consumed: at EDCH call setup (regardless UL SRB is over DCH
or EDCH) : only the DCH specific failures will be pegged U10318_1 (VS_CEMAllocDCH_AllocFailDCH)
R99 CE failure rate (%) 2nd metric: [VS_CEMAllocDCH_AllocFailDCH(U10318_1) +

VS_CEMAllocDCH_AllocFailHSDPA(U10318_3) + VS_CEMAllocDCH_AllocFailEDCH(U10318_5)] /
sum(all screenings of U10318)
Normally, this metric should be aligned with R99 CE failure rate (%) 1st metric
44
R99 CE CAC failure (LCG level counter #10309)
Nb of times CE R99 resources allocation succeeds or fails
R99 CE failure rate (%) 3rd metric : [VS_CEMAlloc_FailReconf(U10309_3)+
VS_CEMAlloc_FailReconfLock(U10309_5)+ VS_CEMAlloc_FailSetup(U10309_2)+
VS_CEMAlloc_FailSetupLock(U10309_4) ] / sum(all screenings of U10309)
Normally, this metric should be aligned with R99 CE failure rate (%) 1st metric
U10309_0 VS_CEMAlloc_Success
U10309_2 VS_CEMAlloc_FailSetup
CEM resources HW blocking
U10309_3 VS_CEMAlloc_FailReconf
U10309_4 VS_CEMAlloc_FailSetupLock
CEM resources software blocking
U10309_5 VS_CEMAlloc_FailReconfLock
45
R99 CE failures (7/8) U1180_avg, U1181_avg
Not accurate (icem model, pessimistic
view)HNot reliable
R99 CE load seen by RNC (cell level counters) U1180_Avg VS_QosUlCemLdClrYellow_Avg
U1180_Cum VS_QosUlCemLdClrYellow_Cum
% of time the cell is black, red or yellow due to CEM U1180_Max VS_QosUlCemLdClrYellow_Max
U1180_Min VS_QosUlCemLdClrYellow_Min
UL load U1180_NbEvt VS_QosUlCemLdClrYellow_NbEvt
U1181_Avg VS_QosUlCemLdClrRed_Avg
Test = avg % of time spent in yellow UL = U1180_avg U1181_Cum VS_QosUlCemLdClrRed_Cum
Threshold yellow = 10% , Threshold red = 50% U1181_Max VS_QosUlCemLdClrRed_Max
U1181_Min VS_QosUlCemLdClrRed_Min
Test = avg % of time spent in red UL = U1181_avg U1181_NbEvt VS_QosUlCemLdClrRed_NbEvt
U1201_Avg VS_QosUlCemLdClrBlack_Avg
Threshold yellow = 10% , Threshold red = 50%
U1201_Cum VS_QosUlCemLdClrBlack_Cum
Test = avg % of time spent in black UL (new in UA81) = U1201_Max VS_QosUlCemLdClrBlack_Max
U1201_Min VS_QosUlCemLdClrBlack_Min
U1201_avg U1201_NbEvt VS_QosUlCemLdClrBlack_NbEvt
Threshold yellow = 0%, Threshold red = 10%
% of time the cell is black, red or yellow due to CEM U1177_Avg VS_QosDlCemLdClrYellow_Avg
U1177_Cum VS_QosDlCemLdClrYellow_Cum
DL load U1177_Max VS_QosDlCemLdClrYellow_Max
U1177_Min VS_QosDlCemLdClrYellow_Min
Note: with bidirectional CE cost in CEM, the UL is more U1177_NbEvt VS_QosDlCemLdClrYellow_NbEvt
loaded than the DL. Its no use looking at the DL way. U1178_Avg VS_QosDlCemLdClrRed_Avg
U1178_Cum VS_QosDlCemLdClrRed_Cum
avg % of time spent in yellow DL = U1177_avg U1178_Max VS_QosDlCemLdClrRed_Max
U1178_Min VS_QosDlCemLdClrRed_Min
avg % of time spent in red DL = U1178_avg U1178_NbEvt VS_QosDlCemLdClrRed_NbEvt
U1153_Avg VS_QosDlCemLdClrBlack_Avg
avg % of time spent in black DL (new in UA81) = U1153_avg U1153_Cum VS_QosDlCemLdClrBlack_Cum
U1153_Max VS_QosDlCemLdClrBlack_Max
U1153_Min VS_QosDlCemLdClrBlack_Min
U1153_NbEvt VS_QosDlCemLdClrBlack_NbEvt
46
R99 CE load seen by RNC (cell level counters)
According to cell state (DL) : black, red or yellow due to CEM DL load
RB may be downsized
RB may be turned down (R99 CE CAC failure)
RB may be preempted (if feature activated) by high priority users : % of time the cell is
congested due to CEM DL color and leading to iRM preemption algo (which is only for DL) =
U1179_avg > 0
Thresholds for CEM color should be tuned (as per UPUG) to reflect NodeB CEM R99
CE configuration
U1179_Avg VS_QosDlCemLdCellPreemptClrCngstd_Avg
U1179_Cum VS_QosDlCemLdCellPreemptClrCngstd_Cum
U1179_Max VS_QosDlCemLdCellPreemptClrCngstd_Max
U1179_Min VS_QosDlCemLdCellPreemptClrCngstd_Min
U1179_NbEvt VS_QosDlCemLdCellPreemptClrCngstd_NbEvt
47
Reminder on R99 CE CAC
See CR DCTPD00359725 (AR 1-4115585) (remove the xCEMCAC in RLReconf)
When CapacityLicensing =0xFFFF (not activated) and Nb iCEM <> 0, Nb xCEM<>0 and
r99MaxNumberCeXcem <> 0, then r99MaxNumberCeNodeb = r99MaxNumberCeXcem +
64*NbdBBU
NodeB shall only do the CAC on r99MaxNumberCeNodeb and not on the
r99MaxNumberCeXcem .
VS_R99CECapacity_AllocLicensingRefusal(U10317_5) increase
In UA7, CR359725 : xCEM CAC check for RL-Reconf was removed
But in early 8.x release, xCEM CAC is still being done. CR will be implemented in UA813 EP4
Without the CR, RL-Reconf failing with xCEM CAC failure.
48
Agenda
1 | CCM monitoring
49
Other general failures (1/4)
Please refer to [R11] , CAC HSxPA SEQUENCE part (in annex) for full details.
In UA8.1: U38_11(VS_RadioLinkSetupUnsuccess_NotEnoughUserPlaneProcessingResources)
CAC failures 2ms EDCH users (based on credits)
xCEM: nb10ms+4*nb2ms <= maxNbEdchCreditsForXcem NOK (also eCEM in UA7138)
eCEM from UA8.1: nb10ms+nb2ms <= maxNbEdchCreditsForXcem NOK
Note: in UA7138, U38_4(VS_RadioLinkSetupUnsuccess_NodeBCEMLackL1Rsrc) was pegged instead
Note: this screening is also used by feature 82602/R3 when (configurable) limit of decoding ressources
is reached (but this is not a matter of number of users)
U38_0(VS_RadioLinkSetupUnsuccess_RadioLinkSetupFailure) NBAP cause UL resources not
available
CAC failures EDCH users (EDCH Hardware limit reached, eg 32 EDCH 2ms per xCEM) leading to
EDCH fallbacks to DCH
xCEM: nb10ms+4*nb2ms <= 128 NOK (also eCEM in UA7138)
eCEM from UA8.1: nb10ms+nb2ms <= 128 NOK
Possible CCM CPU overload (xCCM) and backpressure mechanism
Possible E-RGCH/E-HICH signature issue (NBAP cause UL Resources not available)
See further slide (investigation method)
Note : in UA7, U1629_7 (VS_RadioBearerEstablishmentUnsuccess_NodeBCEMLackofL1Resource)
and U1629_3(VS_RadioBearerEstablishmentUnsuccess_Unspecified). were pegged instead (tbc)
U38_2(VS_RadioLinkSetupUnsuccess_RrmRefusal)
internal cause related with CAC
failures when EDCH users reaching maxEdchUsersPerCell or maxEdch2msLegsPerCell (RNC EDCH CAC)
Possible Dual Cell issue (CR801606) , possible Code issue= Code (U404_1
(RRC_FailConnEstab_DLCodeRsrc ) )
Possible Power issue: RRM Refusal correlated with U404_2(RRC_FailConnEstab_DLPowRsrc)
U38_9(VS_RadioLinkSetupUnsuccess_MultiCellNotAvailable) 50
Linked with Dual Cell CAC reject (nb of HSDPA UE limitation)
VS_RadioBearerEstablishmentUnsuccess_x: U1629_4 (RlFailOrRlcErr) & U1629_3 (Unspecified)
Possible issue with RLC Polling Timer for SRB (160ms) see AR1-3743354
U1629_3 (unspecified) pegged but U1629_7 (CEMLackofL1resource) is not pegged:
Field (UA6 & UA7): NBAP fail cause UL Radio Resources not Available associated with unspecified (U1629_3)
Possible CE UL R99 resources shortage (or UL power ?)
U1629_7 (CEMLackofL1resource)
Field (UA7): possible issue with E-RGCH/E-HICH signature (cant be allocated properly for given UE) Call
drop
Observe recommendation from HPUG Tuning of maxNrOfErgchEhich (max nb of E-HICH/E-RGCH channels
reserved per cell) depending on E-DCH traffic for x/eCEM: [ONE_Bulletin] _110103#1: Tuning of
maxNrOfErgchEhich depending on E-DCH traffic
Check U52_12_Max (VS_RadioLinkEstablishedPerCell_PsHSPAwithoutFdpch_Max)
Note : In UA7.1, E-HICH/E-RGCH signatures not released if UE no more present: AR 1-2895160, AR 1-
3045602 / CR 00353879.02, AR 1-3181312 / CR 353879 (A1TA)
Reminder from HPUG : xCEM vs ECEM signature capacity (feature 89411, eCEM capacity)
xCEM = 256 EDCH dedicated signature pairs E-RGCH/E-HICH supported
eCEM = 384 EDCH dedicated signature pairs E-RGCH/E-HICH supported (designed to support 3 RL per user (Softer
HandOver): 128*3=384)
Nb of RL EDCH per CEM (according to nb of cells /CEM)
maxNrOfErgchEhich # RL EDCH
(channels) (per cell) 1 2 3 4 5 6
18 36 54 72 90 108 xCEM
1 18
18 36 54 72 90 108 eCEM
36 72 108 144 180 216 xCEM
2 36
36 72 108 144 180 216 eCEM
54 108 162 216 256 256 xCEM
3 54
54 108 162 216 270 324 eCEM
51
72COPYRIGHT
144 2011 ALCATEL-LUCENT. 216
ALL RIGHTS RESERVED. 256 256 256 xCEM
4 ALCATEL-LUCENT 72
CONFIDENTIAL SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
72 144 216 288 360 384 eCEM
HPUG extract
More details on maxNrOfErgchEhich
(see HPUG)
Value =4 was bugged (DCTPD00418367: AR
3097547 memory erased, RNC reset.) but
corrected in UA713. However, most of client
took value = 3 and did not change it .
Note : increasing value will impact UL load
52
Note : NBAP procedures (with following causes) associated with the screening
CEMLackofL1Resource in UA7 (maybe other causes since UA8)
Node B resources unavailable
Priority transport channel established
Cell synchronization not supported
Cell synchronization adjustment not supported
IPDL already activated
IPDL not supported
IPDL parameters not available
Frequency acquisition not supported
Requested type of bearer rearrangement not supported
Signalling bearer rearrangement not supported
Bearer re-arrangement needed
MICH not supported
U38_4 VS_RadioLinkSetupUnsuccess_NodeBCEMLackL1Rsrc
U39_4 VS_RadioLinkAdditionUnsuccess_NodeBCEMLackL1Rsrc
U40_4 VS_RadioLinkReconfigurationPrepareUnsuccess_NodeBCEMLackL1Rsrc
53
Agenda
1 | CCM monitoring
54
HSDPA resource monitoring decision trees
We have 2 decision trees for HSDPA

One decision tree for HSDPA Users
One decision tree for HSDPA Throughput
55
HSDPA users monitoring decision tree
At iub level: no HSDPA users load
Avg % of HSDPA connections load > x% (e.g.70%) ?
yes Check burstiness:
High average HSDPA UE load max HSDPA UE connection load
(HSDPA UE near to resource exhaustion)
In case of proactive monitoring: yes At iub level:

add directly HSDPA UE resources max % of HSDPA connections load > 95 %
no HSDPA users failures

HSDPA users CAC failure check
Check HSDPA Users failure rate ?
Green
% of HSDPA users allocation success rate < 100%
Red < 98% - 98% Yellow < 100% - green = 100%
Red or yellow
Case no capa licensing Case capa licensing (finite value 100% = No HSDPA UE failure rate
hsdpaNumberUserCapacityLicensing)
HSDPA capacity
HW fail : upgrade iCEM to x/eCEM or add Increase HSDPA UE license (H1 token
OK
x/eCEM. If not enough, d4U, NodeB step is 8 users) :
densification hsdpaNumberUserCapacityLicensing
SW fail : increase If not enough, upgrade iCEM to x/eCEM
hsdpaMaxNumberUserxCEM up to 128. or add x/eCEM HSDPA
If not enough, upgrade iCEM to x/eCEM or If not enough, d4U, NodeB densification throughput
add x/eCEM. If not enough, d4U, NodeB decison tree
densification
Note: DualCell HSDPA capacity increase (4 to 56
15) will increase the levelof

ALCATEL-LUCENT failure
CONFIDENTIAL
SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
Reminder on HSDPA users
Dual Cell HSDPA users

For more information, refer to [R13]
Market Trend : HSDPA-DC UEs increase significantly since the iPhone5 launch.
With feature 118154 HSDPA-DC Capa increase, more HSDPA-DC UE per board (from 4 to 15)
more HSDPA users used, more HSDPA users failures
increase HSDPA users capa (hsdpaMaxNumberUserXcem)
57
HSDPA users load (1/6)
Avg % of HSDPA connections > 70% (at Iub level, only available for x/eCEM)
Avg % of HSDPA connections during active period =
[CumUsed/NbEvtActivespatial aggreg=sum]/ [min(CumLicensing, CumHWcapacity)/ NbEvt]
= HsdpaUsersCapacityAvgActiveEvt_UserCpt001ac_B_HSDPA_xCEM / min
(HsdpaUsersLicense_UsersCpty002_B_HSDPA_xCEM;HsdpaUsersMaxHW_UsersCpty006_B_HSDPA_xCEM)
Conservative approach: x = 70% (allows better anticipation)
58
Max % of HSDPA connection used> 95% (at Iub level, only available for x/eCEM)
Max % of HSDPA connections =
[MaxUsedtemporal aggreg=Max]/ [min(CumLicensing, CumHWcapacity)/NbEvt]
= _HsdpaUsersMaxUsed_UserCpty010_HSDPA_xCEM_C / min
Where _HsdpaUsersMaxUsed_UserCpty010_HSDPA_xCEM_C is a user defined indicator (with proper
aggregation rule) to import to NPO (in xml) for more information, please see (R10]
Note : MaxUsed is not a real max (tbc)
MaxUsed screening shall report the maximum used value for every sampling period (5 sec)
Every 5 seconds, the MaxUsed is determined only if the resource is used at this time. At each triggering
time (t) (i.e, every 5 seconds): If the CumUsed(t) is not 0 Then Determine the MaxUsed.
CumUsed = internal cpUserCac.eBbuUserNumber when the counter is pegged (every 5sec) ?
Internal cpUserCac.eBbuUserNumber is the nb of HSDPA users loaded. Its updated each time a HSDPA
users is deleted or loaded.
Therefore, MaxUsed is not an absolut max (on the period), but a maximum over 5s period samples
(discrete). Thus, we may observed some failures (U10835_HSXPA_5 =
AllocLicensingRefusal ) without the MaxUsed reaching SW capa. MaxUsed is therefore not really
(many HSDPA users can be loaded or deleted in 5 sec)
Other metric for max % of HSDPA connections based on Avg+3*Std_deviation
Min(Avg+3*Std_deviation,maxUsed)/[min(CumLicensing, CumHWcapacity)/NbEvt]
= HsdpaUsersCptyIndicator_UserCpt001in_B_HSDPA_xCEM / min
Min(Avg+3*Std_deviation,maxUsed) = HsdpaUsersCptyIndicator_UserCpt001in_B_HSDPA_xCEM
at HSXPA level (upper aggregation rule may not work)
Alternative: replace Min(Avg+3*Std_deviation,maxUsed) by Avg+3*Std_deviation
59
HSDPA Users (at Iub level) :
U10835_HSDPA_1 VS_HsdpaUsersCapacity_HSDPA_CumHWcapacity
U10835_HSDPA_2 VS_HsdpaUsersCapacity_HSDPA_CumLicensing NodeB with iCEM
U10835_HSDPA_3 VS_HsdpaUsersCapacity_HSDPA_CumUsed
U10835_HSDPA_4 VS_HsdpaUsersCapacity_HSDPA_AllocSuccess
U10835_HSDPA_5 VS_HsdpaUsersCapacity_HSDPA_AllocLicensingRefusal
U10835_HSDPA_6 VS_HsdpaUsersCapacity_HSDPA_AllocHWfail
U10835_HSDPA_NbEvt VS_HsdpaUsersCapacity_HSDPA_NbEvt
U10835_HSDPA_7 VS_HsdpaUsersCapacity_HSDPA_NbEvtActive
U10835_HSDPA_8 VS_HsdpaUsersCapacity_HSDPA_CumSqUsedLow64 New in UA8, but not applicable
U10835_HSDPA_9 VS_HsdpaUsersCapacity_HSDPA_CumSqUsedHigh64 (the screenings report 0)
U10835_HSDPA_10 VS_HsdpaUsersCapacity_HSDPA_MaxUsed
U10835_HSXPA_1 VS_HsdpaUsersCapacity_HSXPA_CumHWcapacity
U10835_HSXPA_2 VS_HsdpaUsersCapacity_HSXPA_CumLicensing
U10835_HSXPA_3 VS_HsdpaUsersCapacity_HSXPA_CumUsed
U10835_HSXPA_4
U10835_HSXPA_5
VS_HsdpaUsersCapacity_HSXPA_AllocSuccess
VS_HsdpaUsersCapacity_HSXPA_AllocLicensingRefusal
NodeB with x/eCEM
U10835_HSXPA_6 VS_HsdpaUsersCapacity_HSXPA_AllocHWfail
U10835_HSXPA_NbEvt VS_HsdpaUsersCapacity_HSXPA_NbEvt
U10835_HSXPA_10 VS_HsdpaUsersCapacity_HSXPA_MaxUsed
U10835_HSXPA_7 VS_HsdpaUsersCapacity_HSXPA_NbEvtActive New in
U10835_HSXPA_8 VS_HsdpaUsersCapacity_HSXPA_CumSqUsedLow64 UA8
U10835_HSXPA_9 VS_HsdpaUsersCapacity_HSXPA_CumSqUsedHigh64
Indicators for x/eCEM (also exist for iCEM):

HW capa in HSDPA users on x/eCEM: HsdpaUsersMaxHW_UsersCpty006_B_HSDPA_xCEM =
U10835_HSXPA_1/U10835_HSXPA_NbEvt
SW capa in HSDPA users on x/eCEM: HsdpaUsersLicense_UsersCpty002_B_HSDPA_xCEM =
Note : SW capa <= HW capa
Average # of HSDPA users (over active and non active sampling period of 5 s) not a good
metric (underestimate the real avg load): HsdpaUsersCapacity_UsersCpty001_B_HSDPA_xCEM
(= U10835_HSXPA_3/U10835_HSXPA_NbEvt)
60
HSDPA Users (at Iub level) for x/eCEM only, new in UA8.1 :
Avg # of HSDPA users (over active sampling period of 5 s) : U10835_HSXPA_3/U10835_HSXPA_7 or ext
indicator HsdpaUsersCapacityAvgActiveEvt_UserCpt001ac_B_HSDPA_xCEM
Max # of HSDPA users (over sampling period of 5 s) on x/eCEM: U10835_HSXPA_10 (but improper
temporal aggregation). Please use instead _HsdpaUsersMaxUsed_UserCpty010_HSDPA_xCEM_C, which is
a user defined indicator (with proper aggregation rule) to import to NPO (in xml) for more
information, please see [R10]. Counter is per HSXPA_Resource: spatial aggregation at Iub level (sum of
max) may overestimate the real max.
# of HSDPA users standard deviation (during active events):
Based on CumSquareUsed = (cum used) = U10835_HSXPA_8 +2^32 * U10835_HSXPA_9 with
2^32=exp(32ln(2))
Note : cumSquareUsed" could sometimes be > 2exp32 (whereas screening is coded on 32 bit
integers), therefore its "split" into 2 different screenings #8 and #9, that can both fit in a 32bit
integer.
Std_dev = HsdpaUsersCapacityStddeviation_UserCpt001sd_B_HSDPA_xCEM
(finite population with
2 2
CumUsed equal probabilities at all
= std_dev = CumUsed ( )
NbEvtActiv e NbEvtActiv e points)
HsdpaUsersCptyIndicator_UserCpt001in_B_HSDPA_xCEM
= Min (max_used , 3* + average_active)
is a real max excluding some very high value of max_used (and seldom)
Avg + 3* ~ 99,73% of samples
that should not be counted (not to penalize the customer).
61
# of HSDPA users load (LCG level counters)
Nb of HSDPA UE per LCG = for both iCEM and xCEM (at LCG level)
Max screening is interesting. But a Dual Cell User is counted as 1, thus not adapted for capacity
monitoring (U10835 family is then more adapted). Avg screening is not accurate (average nb of
HSDPA UE over active and non active 5 s period)
U10821_Avg VS_HsdpaUEsPerLCG_Avg
U10821_Cum VS_HsdpaUEsPerLCG_Cum
U10821_Max VS_HsdpaUEsPerLCG_Max
U10821_Min VS_HsdpaUEsPerLCG_Min
U10821_NbEvt VS_HsdpaUEsPerLCG_NbEvt
For iCEM only : # of HSDPA UE per HBBU (at HSDPA level)
U10820_Avg VS_HsdpaUEsPerHBBU_Avg
U10820_Cum VS_HsdpaUEsPerHBBU_Cum
U10820_Max VS_HsdpaUEsPerHBBU_Max
U10820_Min VS_HsdpaUEsPerHBBU_Min
U10820_NbEvt VS_HsdpaUEsPerHBBU_NbEvt
# of HSDPA active UE (at Iub level, but available at cell level)
To monitor active HSDPA users.
Note: an HSPDA active user is a user who receives data on HS-PDSCH. A user with DPCCH and
associated DCH, but who does not receive data on HS-PDSCH (HSDPA connected user) is not
considered as an HSDPA active user.
U10828_Avg VS_HsdpaNbUserWithDataTTI_Avg
U10828_Cum VS_HsdpaNbUserWithDataTTI_Cum
U10828_Max VS_HsdpaNbUserWithDataTTI_Max
62
U10828_Min VS_HsdpaNbUserWithDataTTI_Min
U10828_NbEvt VS_HsdpaNbUserWithDataTTI_NbEvt
Warning regarding max # of HSDPA users in case of DC HSDPA users

Absolute max # of HSDPA users = 128 (hsdpaMaxNumberUserXcem)
Up to 15 Dual Cell HSDPA users for x/eCEM (dualCellHsdpaMaxNumberUserXcem and
dualCellHsdpaMimoMaxNumberUserEcem)
Note : 1 DC-HSDPA user = 2 HSDPA connections (out of 128), ie 15 connected DC users leaves 128-
30=98 legacy HSDPA users
Impact of Dual Cell user on counter

For example, with 4 Dual Cell HSDPA users and 80 single cell HSDPA users :
U10835_HSXPA_10(VS_HsdpaUsersCapacity_HSXPA_MaxUsed) = 88 (both legs are considered)
U10821_Max(VS_HsdpaUEsPerLCG_Max) = 84
Other counter (not tested, not used)

Number of high performance users (PDU size is 656 bits) (at cell level)
63
HSDPA users failure (1/4)
HSDPA users (at Iub level)
U10835_HSDPA_1 VS_HsdpaUsersCapacity_HSDPA_CumHWcapacity
U10835_HSDPA_2 VS_HsdpaUsersCapacity_HSDPA_CumLicensing NodeB with iCEM
U10835_HSDPA_3 VS_HsdpaUsersCapacity_HSDPA_CumUsed
U10835_HSDPA_4 VS_HsdpaUsersCapacity_HSDPA_AllocSuccess
U10835_HSDPA_5 VS_HsdpaUsersCapacity_HSDPA_AllocLicensingRefusal
U10835_HSDPA_6 VS_HsdpaUsersCapacity_HSDPA_AllocHWfail
U10835_HSDPA_NbEvt VS_HsdpaUsersCapacity_HSDPA_NbEvt
U10835_HSDPA_7 VS_HsdpaUsersCapacity_HSDPA_NbEvtActive
U10835_HSDPA_8 VS_HsdpaUsersCapacity_HSDPA_CumSqUsedLow64 New in UA8, but not applicable
U10835_HSDPA_9 VS_HsdpaUsersCapacity_HSDPA_CumSqUsedHigh64 (the screenings report 0)
U10835_HSDPA_10 VS_HsdpaUsersCapacity_HSDPA_MaxUsed
U10835_HSXPA_1 VS_HsdpaUsersCapacity_HSXPA_CumHWcapacity
U10835_HSXPA_2 VS_HsdpaUsersCapacity_HSXPA_CumLicensing
U10835_HSXPA_3 VS_HsdpaUsersCapacity_HSXPA_CumUsed
U10835_HSXPA_4
U10835_HSXPA_5
VS_HsdpaUsersCapacity_HSXPA_AllocSuccess
VS_HsdpaUsersCapacity_HSXPA_AllocLicensingRefusal
NodeB with x/eCEM
U10835_HSXPA_6 VS_HsdpaUsersCapacity_HSXPA_AllocHWfail
U10835_HSXPA_NbEvt VS_HsdpaUsersCapacity_HSXPA_NbEvt
U10835_HSXPA_10 VS_HsdpaUsersCapacity_HSXPA_MaxUsed
U10835_HSXPA_7 VS_HsdpaUsersCapacity_HSXPA_NbEvtActive New in
U10835_HSXPA_8 VS_HsdpaUsersCapacity_HSXPA_CumSqUsedLow64 UA8
U10835_HSXPA_9 VS_HsdpaUsersCapacity_HSXPA_CumSqUsedHigh64

% of HSDPA users allocation failures rate due to HW limitation:
HsdpaUsersAllocFail_HW_UsersCpty005_B_HSDPA_xCEM = U10835_HSXPA_6 /
(U10835_HSXPA_4+U10835_HSXPA_6)
% of HSDPA users allocation failures rate due to SW limitation:
HsdpaUsersAllocFailLicense_UsersCpty004_B_HSDPA_xCEM = U10835_HSXPA_5 /
(U10835_HSXPA_4+ U10835_HSXPA_5)
% of HSDPA users allocation success rate:
HsdpaUsersAllocSuccess_UsersCpty003_B_HSDPA_xCEM = U10835_HSXPA_4 /
(U10835_HSXPA_4+U10835_HSXPA_5+U10835_HSXPA_6)
64
Other metrics
RNC HSDPA CAC failure (at cell level) - only if Fair Sharing = OFF :
Limit of simultaneous HSDPA UE per cell (maximumNumberOfUsers ) is reached
HSDPA CAC fails, then both UL & DL are fall-backed to DCH.
Note: U958 is not pegged in case of EDCH CAC success (or not) ; fallback from 2ms to
10ms , from EDCH to DCH UL (success or fail) (see AR 1-3140030 / CR 434022)
Note: maximumNumberOfUsers = 100 means RNC CAC disable
If CAC EDCH is failed:
If not 2ms EDCH, then peg EDCH failure and peg HSDPA success
if Fair Sharing = ON, No CAC on Nb of HSDPA users

Note: field experience, U958 is pegged on some other cases (see AR1-2195315)
Code reservation KO
Power reservation KO
Other causes (reconfiguration KO)
65
Other metrics: HSDPA fallbacks to DL DCH representative of HSDPA users

shortage
Nb of HSDPA/DCH calls fallbacks to R99 (DCH/DCH) at cell level
Ref: RadioBearerSetupSuccess_RB011_C_HSDPA(URB011_C_HSDPA)(Event)
But fallback can occur not only at RB Set Up, but after mobility, Always ONH so ratio to
URB011_C_HSDPA is not exact, but can help
Nb of successful fallbacks from HSDPA/EDCH to R99(DCH-DCH) at cell level
Counters
U1601_0 VS_SucHspaToDchFallbackCell_HsdpaDchToDchDch
U1601_1 VS_SucHspaToDchFallbackCell_HsdpaEdchToHsdpaDch
U1601_2 VS_SucHspaToDchFallbackCell_HsdpaEdchToDchDch
U1603_0 VS_UnsucHspaToDchFallbackCell_DlHsdpaUlDch 66
U1603_1 VS_UnsucHspaToDchFallbackCell_DlHsdpaUlEdch
Other metrics: Nb of HSDPA RB blocked could be representative of HSDPA

users capacity shortage but not only (to be handled with care)
Based on counters
67
HSDPA throughput monitoring decision tree
At iub level: no HSDPA throughput load
max % of HSDPA throughput load > 95%
yes
add directly HSDPA throughput resources
Check HSDPA throughput failure rate ? HSDPA throughput failures

Green
% of HSDPA throughput allocation success rate < 100%
Red < 90% - 90% Yellow < 98% - green = 100%
Red or yellow
100% =
Case no capa licensing Case capa licensing (finite value No HSDPA throughput failure rate
hsdpaThroughputCapacityLicensing)
HW fail : upgrade iCEM to x/eCEM or add HSDPA throughput

x/eCEM. If not enough, D4U, NodeB Increase HSDPA throughput license (H2 resource OK
densification. token step is 1800 kbps) :
hsdpaThroughputCapacityLicensing
SW fail : increase hsdpaMaxThroughputXcem or If not enough, upgrade iCEM to Look for EDCH
Resources
hsdpaMaxThroughputEcem up to max value. x/eCEM or add x/eCEM Shortage
If not enough, upgrade iCEM to x/eCEM or add If not enough, d4U, odeB densification
x/eCEM
If not enough, d4U, NodeB densification
68
HSDPA throughput load (1/4)
Testing avg HSDPA throughput used not significant better check max or failure
Avg % of HSDPA throughput used > 70% (conservative approach, valid in UA7)
For information (not recommended method)
At Iub level, only available for x/eCEM
Avg % of HSDPA throughput used during active period =
(Cumused/NbEvtActive_ SpatialTemporalAggregationAvg) / [ min(CumLicensing ; CumHWcapacity) / NbEvt]
HsdpaThroughputCptyAvgActiveEvt_ThgtCpy002ac_B_HSDPA_xCEM /
min(HsdpaThroughputLicense_ThgptCpty009_B_HSDPA_xCEM;
HsdpaThroughputMaxHW_ThgptCpty010_B_HSDPA_xCEM)
Max % of HSDPA throughput used >95% (from UA81)
= _HsdpaTputMaxUsed_ThgtCpty010_HSDPA_xCEM_C(UThgtCpty010_HSDPA_xCEM_C / min
(HsdpaThroughputLicense_ThgptCpty009_B_HSDPA_xCEM; HsdpaThroughputMaxHW_ThgptCpty010_B_HSDPA_xCEM)
Where _HsdpaTputMaxUsed_ThgtCpty010_HSDPA_xCEM_C(UThgtCpty010_HSDPA_xCEM_C)(Kbit/s) is a user
defined indicator (with proper aggregation rule) to import to NPO (in xml) for more information, please
see (R10]
Note : MaxUsed is not a real max (tbc) see comments for HSDPA user
Other metric for max % of HSDPA thoughput based on Avg+3*Std_deviation (from UA81)
= HsdpaThroughputCptyIndicator_ThgptCpty002indic_B_HSDPA_xCEM / min
Min(Avg+3*Std_deviation,maxUsed) = HsdpaThroughputCptyIndicator_ThgptCpty002indic_B_HSDPA_xCEM
69
HSDPA throughput (at Iub level) :
U10836_HSDPA_1 VS_HsdpaThroughputCapacity_HSDPA_CumHWcapacity
U10836_HSDPA_2 VS_HsdpaThroughputCapacity_HSDPA_CumLicensing
NodeB with iCEM
U10836_HSDPA_3 VS_HsdpaThroughputCapacity_HSDPA_CumUsed
U10836_HSDPA_4 VS_HsdpaThroughputCapacity_HSDPA_AllocSuccess
U10836_HSDPA_5 VS_HsdpaThroughputCapacity_HSDPA_AllocLicensingRefusal
U10836_HSDPA_6 VS_HsdpaThroughputCapacity_HSDPA_AllocHWfail
U10836_HSDPA_NbEvt VS_HsdpaThroughputCapacity_HSDPA_NbEvt
U10836_HSDPA_7 VS_HsdpaThroughputCapacity_HSDPA_NbEvtActive New in UA8, but not applicable
U10836_HSDPA_8 VS_HsdpaThroughputCapacity_HSDPA_CumSqUsedLow64
U10836_HSDPA_9 VS_HsdpaThroughputCapacity_HSDPA_CumSqUsedHigh64 (the screenings report 0)
U10836_HSDPA_10 VS_HsdpaThroughputCapacity_HSDPA_MaxUsed
U10836_HSXPA_1 VS_HsdpaThroughputCapacity_HSXPA_CumHWcapacity
U10836_HSXPA_2 VS_HsdpaThroughputCapacity_HSXPA_CumLicensing
U10836_HSXPA_3 VS_HsdpaThroughputCapacity_HSXPA_CumUsed
U10836_HSXPA_4
U10836_HSXPA_5
VS_HsdpaThroughputCapacity_HSXPA_AllocSuccess
VS_HsdpaThroughputCapacity_HSXPA_AllocLicensingRefusal
NodeB with x/eCEM
U10836_HSXPA_6 VS_HsdpaThroughputCapacity_HSXPA_AllocHWfail
U10836_HSXPA_NbEvt VS_HsdpaThroughputCapacity_HSXPA_NbEvt
U10836_HSXPA_7 VS_HSXPAThroughputCapacity_HSXPA_NbEvtActive
U10836_HSXPA_8 VS_HSXPAThroughputCapacity_HSXPA_CumSqUsedLow64 New in
U10836_HSXPA_9 VS_HSXPAThroughputCapacity_HSXPA_CumSqUsedHigh64
U10836_HSXPA_10 VS_HSXPAThroughputCapacity_HSXPA_MaxUsed UA8
HW HSDPA throughput capa: HsdpaThroughputMaxHW_ThgptCpty010_B_HSDPA_xCEM =
xCEM= 42000 kbps & eCEM = 61200 kbps
SW HSDPA throughput Capa: HsdpaThroughputLicense_ThgptCpty009_B_HSDPA_xCEM =
Note : SW capa <= HW capa (if SW capa limited, parameter increase possible)
Average HSDPA throughput (over active and non active sampling period of 5 s) not a
good metric (underestimate the real avg load):
HsdpaThroughputCpty_ThgptCpty002_B_HSDPA_xCEM =
70
Note: Scr_5 & Scr_6 are in fact the nb of TTI periods (2ms for
COPYRIGHT HSDPA)
2011 during
ALCATEL-LUCENT. ALL which the scheduler restricted the throughput because the license or
RIGHTS RESERVED.
HW throughput limitALCATEL-LUCENT
was reached. CONFIDENTIAL SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
New indicators in UA8.1 (only for x/eCEM) :
Avg HSDPA throughput (over active sampling period of 5 s) :
HsdpaThroughputCptyAvgActiveEvt_ThgtCpy002ac_B_HSDPA_xCEM =
U10836_HSXPA_3/U10836_HSXPA_7with Spatial temporal aggregation Avg
Max HSDPA throughput (over sampling period of 5 s) :
_HsdpaTputMaxUsed_ThgtCpty010_HSDPA_xCEM_C = U10836_HSXPA_10 (with temporal
aggreg =max)
Where _HsdpaTputMaxUsed_ThgtCpty010_HSDPA_xCEM_C(UThgtCpty010_HSDPA_xCEM_C)(Kbit/s) is
a user defined indicator (with proper aggregation rule) to import to NPO (in xml) for more
information, please see [R10]. Counter is per HSXPA_Resource: spatial aggregation at Iub level (sum
of max) may overestimate the real max.
Note : counter is per HSXPA_Resource ; spatial aggregation at Iub level (sum of max) may
overestimate the real max
HSDPA throughput standard deviation (during active events) :
HsdpaThroughputCptyStddeviation_ThgtCpt002sd_B_HSDPA_xCEM
2^32=exp(32ln(2))
integer
2 2
= std_dev = CumUsed CumUsed finite population with equal probabilities at all points)
( )
Indicator for monitoring = Min (max_used , 3* + average_active) :
HsdpaThroughputCptyIndicator_ThgptCpty002indic_B_HSDPA_xCEM
is a real max as it excludes some very high value 71 of max_used (and very seldom) that should not
be countedALCATEL-LUCENT
(not to CONFIDENTIAL
penalize the customer)
SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
Other HSDPA throughput counters (for information, not used in method)
Max instantaneous throughput per cell (including retransmission) :
Based VS_HsdpaTxDataBitsSchedTotal_Max (U10809_Max ) (Kbit)
at cell level, to be aggregated at Iub level. Aggregation may be overestimated (max
of max at cells, is not necessarily the max at NodeB)
= 500* VS_HsdpaTxDataBitsSchedTotal_Max
Max instant throughput per cell without retransmission:
Based on VS_HsdpaMACdPDUAckBits_Max(U10806_Max)(Kbit)
at cell level, to be aggregated at Iub level
= 500* VS_HsdpaMACdPDUAckBits_Max (no indicateur created)
Average throughput per cell:
HSDPAcellthroughput_HSDPA035_CR(UHSDPA035_CR)(Kbit/s) at cell level
UHSDPA035_CR = (500*VS_HsdpaTxDataBitsSchedTotal_Cum)/VS_HsdpaTTIsUsed
Other QoS indicators
Average CQI: AverageCQI_HSDPA055_CR(UHSDPA055_CR)(nb)
Average HSDPA DL throughput per user:
AvgDLThroughputPerUser_HSDPA093_CR(UHSDPA093_CR)(Kbps)
72
HSDPA throughput failures
HSDPA throughput allocation failures (at Iub level)
U10836_HSDPA_1 VS_HsdpaThroughputCapacity_HSDPA_CumHWcapacity
U10836_HSDPA_2 VS_HsdpaThroughputCapacity_HSDPA_CumLicensing
NodeB with iCEM
U10836_HSDPA_3 VS_HsdpaThroughputCapacity_HSDPA_CumUsed
U10836_HSDPA_4 VS_HsdpaThroughputCapacity_HSDPA_AllocSuccess
U10836_HSDPA_5 VS_HsdpaThroughputCapacity_HSDPA_AllocLicensingRefusal
U10836_HSDPA_6 VS_HsdpaThroughputCapacity_HSDPA_AllocHWfail
U10836_HSDPA_NbEvt VS_HsdpaThroughputCapacity_HSDPA_NbEvt
U10836_HSDPA_7 VS_HsdpaThroughputCapacity_HSDPA_NbEvtActive New in UA8, but not applicable
U10836_HSDPA_8 VS_HsdpaThroughputCapacity_HSDPA_CumSqUsedLow64
U10836_HSDPA_9 VS_HsdpaThroughputCapacity_HSDPA_CumSqUsedHigh64 (the screenings report 0)
U10836_HSDPA_10 VS_HsdpaThroughputCapacity_HSDPA_MaxUsed
U10836_HSXPA_1 VS_HsdpaThroughputCapacity_HSXPA_CumHWcapacity
U10836_HSXPA_2 VS_HsdpaThroughputCapacity_HSXPA_CumLicensing
U10836_HSXPA_3 VS_HsdpaThroughputCapacity_HSXPA_CumUsed
U10836_HSXPA_4
U10836_HSXPA_5
VS_HsdpaThroughputCapacity_HSXPA_AllocSuccess
VS_HsdpaThroughputCapacity_HSXPA_AllocLicensingRefusal
NodeB with x/eCEM
U10836_HSXPA_6 VS_HsdpaThroughputCapacity_HSXPA_AllocHWfail
U10836_HSXPA_NbEvt VS_HsdpaThroughputCapacity_HSXPA_NbEvt
U10836_HSXPA_7 VS_HSXPAThroughputCapacity_HSXPA_NbEvtActive
U10836_HSXPA_8 VS_HSXPAThroughputCapacity_HSXPA_CumSqUsedLow64 New in
U10836_HSXPA_9 VS_HSXPAThroughputCapacity_HSXPA_CumSqUsedHigh64
U10836_HSXPA_10 VS_HSXPAThroughputCapacity_HSXPA_MaxUsed UA8

% of HSDPA throughput allocation failures rate due to HW limitation:
HsdpaThroughputAllocFailHw_ThgptCpty008_B_HSDPA_xCEM = U10836_HSXPA_6/(U10836_HSXPA_4+
U10836_HSXPA_6)
% of HSDPA throughput allocation failures rate due to SW limitation:
HsdpaThroughputAllocFailLicense_ThgptCpty007_B_HSDPA_xCEM = U10836_HSXPA_5/ (U10836_HSXPA_4+
U10836_HSXPA_5)
% of HSDPA throughput allocation success rate: HsdpaThroughputAllocSuccess_ThgptCpty006_B_HSDPA_xCEM
= U10836_HSXPA_4/(U10836_HSXPA_4+U10836_HSXPA_5+U10836_HSXPA_6)
73
Agenda
1 | CCM monitoring
74
EDCH resource monitoring decision trees
In this method, 2 decision trees for EDCH
One decision tree for EDCH Users
One decision tree for EDCH Throughput
75
Reminder on EDCH users capacity (1/7)
With feature 89411 eCEM HSPA aggregate throughput increase in UA81
For xCEM : 2ms TTI EDCH users = max 32
For eCEM : 2ms TTI EDCH users = max 128
For EDCH users, since UA7138, Enhanced NodeB CAC
Objective
Maximizes the usage of 2ms TTI in case of low to medium traffic while maximizing the
usage of 10ms TTI in case of heavy traffic
Allows a better balance EDCH user load (limit the number of 2ms EDCH users for better
CEM capacity usage)
Maximize cell throughput
2ms TTI offers higher user throughput in good radio conditions
2ms TTI is more demanding in term of decoding capacity
2ms TTI needs higher power for control channel > cell throughput drops when number
of UEs increases
2ms suffer from retainability (call drop) issues in bad RF conditions. This can impact PS
calls retainability, but also CS+PS, then indirectly it can impact the CS retainability.
10 ms TTI offers higher cell throughput in a loaded network
Please See [R11] for more details
76
EDCH enhanced NodeB CAC (125171/125567) see HPUG for more info [R5]
(1) For 10msTTI or 2msTTI user admission control
[xCEM] m10ms + 4*n2ms 128 CAC OK, establish 2ms EDCH call
[xCEM] m10ms + 4*n2ms > 128 (CR552741 in UA813)
if ((m+1)10ms + 4*(n-1)2ms <= 128 CAC fails but adapted thanks to CR, Not enough user
plane processing resources , fallback 2msEDCH to 10msEDCH
if ((m+1)10ms + 4*(n-1)2ms > 128 CAC fails, UL radio resources not Available and fallback
2msEDCH to UL DCH
[eCEM] m10ms + 1*n2ms 128 CAC OK , establish 2ms EDCH call
[eCEM] m10ms + 1*n2ms > 128 CAC fails, UL radio resources not Available and fallback
2msEDCH to UL DCH
CR552741: optimizes border cases when no room for 2ms but still room for 10ms
(i.e. the remaining credits (out of the 128 available credits) are less than 4 and
greater than 0)
32nd 2ms EDCH user incoming (while already 31 2ms + 1 10ms) the 32nd 2ms fallbacks to 10ms
31st 2ms EDCH user incoming (while already 30 2ms + 5 10ms) the 31th 2ms fallbacks to 10ms
Etc (a lot of combinations, see tables below)
77
(2) Only for 2msTTI user admission control (optional CAC, can be deactivated)
[xCEM] m10ms + 4*n2ms maxNbEdchCreditsForXcem CAC OK, establish 2ms EDCH call
[xCEM] m10ms + 4*n2ms > maxNbEdchCreditsForXcem CAC fails, Not enough user plane
processing resources , fallback 2msEDCH to 10msEDCH
[eCEM] m10ms + 1*n2ms maxNbEdchCreditsForEcem CAC OK, establish 2ms EDCH call
[eCEM] m10ms + 1*n2ms > maxNbEdchCreditsForEcem CAC fails, Not enough user plane
processing resources , fallback 2msEDCH to 10msEDCH
Other check: pseudo licensing CAC (run before enhanced EDCH CAC)
[xCEM or eCEM] Nb of edch users (regardless of tti) <= edchMaxNumberUserXcem CAC OK,
perform enhanced EDCH CAC. If CAC fails, UL radio resources not Available
Alternative RNC EDCH CAC (feature 34441.1) - not preferred one
Parameter edchMaxUsersPerCell = 18 x maxNrOfErgchEhich (each Ergch/Ehich per cell can
handle 18 EDCH calls, hence the choice for edchMaxUsersPerCell)
Parameter edchMaxLegs2msPerCell controls the RNCs 2ms EDCH CAC when reaching the 2ms
threshold, the RNC tries with 10ms.
Reaching one of the 2 parameters will peg the RRM_Refusal screening (
VS_RadioLinkReconfigurationPrepareUnsuccess_RrmRefusal (U40_2) or
VS_RadioLinkSetupUnsuccess_RrmRefusal(U38_2)
Whatever the feature (NodeB EDCH CAC or RNC EDCH CAC)
Counter VS_Edch2msTtiTo10msTtiFallbackSuccess(U2895) will be increased
In case of EDCH CAC failure, EDCH fallback to DCH can be monostep or multistep
(param: edchToDchFallbackSteps)
MonoStep: directly reconfigure HSUPA into DCH/DCH. This would consume more DL R99 CE.
78
MultiStep (recommended): try to reconfigure
COPYRIGHT firstALLinto
2011 ALCATEL-LUCENT. RIGHTS HSDPA
RESERVED. (and then into DCH in case of HSDPA
CAC failure)
Reminder on EDCH RLS and EDCH RL
Primary cell = Non serving Non serving

EDCH serving cell EDCH RL EDCH RL
Serving
EDCH RL EDCH Non Serving RLSet
EDCH Serving RLSet
E-DCH Active Set = max 4 cells (3GPP)

MaxNumberOfRlEdch = 3 (Max E-DCH AS size (i.e. max # of EDCH RLs allowed per UE).
iBTS behaviour
Only one RLS for a given UE. This RLS can contain up to 3 RL.
This UE (i.e. RLS) is instantiated on one x/eCEM and only one in any cases whatever the
number of RL in the RLS.
As soon as Node B receives a RL Setup (HSU) or a RL Reconf (add HSU) whatever the
number of RL in the RLS, the number of users per CEM is incremented by 1.
Adding a RL to the RLS for macro-diversity by RL Addition does not impact the number of
users.
79
The number of users per CEM is decremented when the RNC deletes the last RL of the RLS.
xCEM or eCEM supports up to 128 EDCH users
How are counted EDCH Radio Links ?
Extract from HPUG (related to RNC count per cell (tbc?))
For a NodeB which has the serving E-DCH radio link for this user, the user is counted as
one user whatever the number of non-serving E-DCH radio links this user has towards
this NodeB. This user is counted against the E-DCH serving cell.
For a NodeB which has only non-serving E-DCH radio link(s) for this user, the user is
counted as one user against the E-DCH non-serving cell having the highest EDCH CAC
threshold edchMaxUsersPerCell
Counted as 1 user Counted as 1 user
RLS = 1 serving RL
+ 1 non serving RL
on same xCEM Non Serving EDCH RLs RLS = 2 non Serving RL on same xCEM
Serving EDCH RL
Note: from a Node B perspective, having or not the serving EDCH link does not make
any difference. As soon as the RLS is created (RL Setup(HSU) or RL Reconf(Add HSU))
in the Node B, the number of users per x/eCEM is incremented
80
If users have multi-RAB PS or SRB over EDCH, the number of users goes down.
Supported : PS I/B (E-DCH) + PS I/B (E-DCH) + SRB (DCH or E-DCH)
Due internal limit (AAL2 VCC to carry EDCH): max 248 connections (CID) for EDCH RB
A E-DCH user needs L1 resources on x/eCEM and Transport Bearer (TB) resources from
RNC to x/eCEM to carry traffic for the different RAB combinations. Each time a E-DCH
user is setup associated TB resources are allocated in the pool of 248 TBs per x/eCEM.
When the maximum is reached new Setup or Reconf. are rejected.
Max # EDCH users = 248/(# EDCH RBs), where EDCH RB can be either SRB or TRB
EDCH RB + SRB over DCH 1 EDCH_RB used out of 248
If all EDCH UE have this type of call, Max 128 UE = min(128;248/#EDCH_RB) = min(128;248)
EDCH RB + SRB over EDCH 2 EDCH RB used out of 248
If all EDCH UE have this type of call, max 124 UE= min(128;248/#EDCH_RB) = min(128;124)
2 PS EDCH RB + SRB over DCH 2 EDCH RB used out of 248
2 PS EDCH RB + SRB on E-DCH 3 EDCH RB used out of 248
If all EDCH UE have this type of call, max 82 UE= min(128;248/#EDCH_RB)=min(128;82)
If G-rake feature (34393) is activated , replace 128 by 116 =128G-Rake UL
Cost(12). But G-rake activation is not recommended (no benefit observed on
field). Up to 3 UL users per x/eCEM can be demodulated by G-Rake (with or
without 16QAM)
81
If users have multi-RAB PS or SRB over EDCH same number of EDCH user
resources consumed (BUT max number of EDCH users is more limited due to
AAL2 limitation)
Counted as 1 user Counted as 1 user
Non Serving EDCH RLs
Serving EDCH RL
Multi RAB : N PS EDCH + SRB over DCH Counted as1 user Counted as 1 user
Non Serving EDCH RLs
Serving EDCH RL
Multi RAB : N PS EDCH + SRB over EDCH
82
EDCH users monitoring decision tree
At iub level: no Check max nb of 2 ms vs 10 ms EDCH users load
Avg % of EDCH connections load >70%)? TTI EDCH users per board
yes
High average EDCH UE load Check burstiness:
(EDCH UE near to resource exhaustion) max EDCH UE connection load
In case of proactive monitoring: yes At iub level:

add directly EDCH UE resources max % of EDCH connections load > 90%
no EDCH Users failures

EDCH users CAC failure check
Check EDCH Users failure rate ? green

EDCH 2ms users Check EDCH 2ms Users failure ? no
% of EDCH users allocation success rate < 100%
CAC failure check U38_11 > 0 ?
Red < 98% - 98% Yellow < 100% - green = 100% yes
red or yellow
Some EDCH 2ms UE CAC EDCH UE
failure resource
Case no capa licensing Case capa licensing (finite value OK
EdchNumberUserCapacityLicensing)
Is fall back to 10ms successful
no ? no
Fallbackto 10ms success rate >98% ?
HW fail : upgrade iCEM to Increase EDCH UE license yes
x/eCEM or add x/eCEM. If not (E1 token step=8 users):
enough, d4U, NodeB More edch2ms capa More edch
edchNumberUserCapacityLi
densification. needed 2ms+10ms capa
censing
SW fail : increase Compromise : add needed:
If not enough, see Hw fail
EdchMaxNumberUserxCEM up credit or see Hw See Hw fail
to 128. If not enough see Hw
83
fail
fail
EDCH users load (1/10)
Avg % of EDCH connections > 70% (at Iub level, only available for x/eCEM)
Avg % of EDCH connections during active period =
[CumUsed/NbEvtActivespatial aggreg=sum]/ [min(CumLicensing, CumHWcapacity)/ NbEvt]
= HsupaUsersCapacityAvgActiveEvt_UserCpt001ac_B_HSUPA_xCEM / min
(HsupaUsersLicense_UsersCpty002_B_HSUPA_xCEM;HsupaUsersMaxHW_UsersCpty006_B_HSUPA_xCEM)
Conservative approach: x = 70% (allows better anticipation)
84
Max % of EDCH connection used> 90% (at Iub level, only available for x/eCEM)
Max % of EDCH connections =
= _HsupaUsersMaxUsed_UserCpty010_HSUPA_xCEM_C/ min
(HsupaUsersLicense_UsersCpty002_B_HSUPA_xCEM;HsupaUsersMaxHW_UsersCpty006_B_HSUPA_xCEM)
Where _HsupaUsersMaxUsed_UserCpty010_HSUPA_xCEM_C is a user defined indicator (with proper
aggregation rule) to import to NPO (in xml) for more information, please see (R10]
Note : MaxUsed is not a real max - See remark on HSDPA users
Counter is per HSXPA_Resource. There is not necessarily a mapping 1 xCEM = 1

HSXPA_Resource (but this is the most frequent case however).
Other metric for max % of EDCH connections based on Avg+3*Std_deviation
= hsupaUsersCptyIndicator_UserCpt001in_B_hsupa_xCEM / min
(hsupaUsersLicense_UsersCpty002_B_hsupa_xCEM;hsupaUsersMaxHW_UsersCpty006_B_hsupa_xCEM)
Min(Avg+3*Std_deviation,maxUsed) = hsupaUsersCptyIndicator_UserCpt001in_B_hsupa_xCEM
85
EDCH Users (at Iub level) :
U10909_EDCH_1 VS_eDCHUsersCapacity_EDCH_CumHWcapacity
U10909_EDCH_2 VS_eDCHUsersCapacity_EDCH_CumLicensing NodeB with iCEM
U10909_EDCH_3 VS_eDCHUsersCapacity_EDCH_CumUsed
U10909_EDCH_4 VS_eDCHUsersCapacity_EDCH_AllocSuccess
U10909_EDCH_5 VS_eDCHUsersCapacity_EDCH_AllocLicensingRefusal
U10909_EDCH_6 VS_eDCHUsersCapacity_EDCH_AllocHWfail
U10909_EDCH_NbEvt VS_eDCHUsersCapacity_EDCH_NbEvt
U10909_EDCH_7 VS_eDCHUsersCapacity_EDCH_NbEvtActive
U10909_EDCH_8 VS_eDCHUsersCapacity_EDCH_CumSqUsedLow64 New in UA8, but not applicable
U10909_EDCH_9 VS_eDCHUsersCapacity_EDCH_CumSqUsedHigh64
U10909_EDCH_10 VS_eDCHUsersCapacity_EDCH_MaxUsed (the screenings report 0)
U10909_HSXPA_1 VS_eDCHUsersCapacity_HSXPA_CumHWcapacity
U10909_HSXPA_2 VS_eDCHUsersCapacity_HSXPA_CumLicensing
U10909_HSXPA_3 VS_eDCHUsersCapacity_HSXPA_CumUsed
U10909_HSXPA_4 VS_eDCHUsersCapacity_HSXPA_AllocSuccess
U10909_HSXPA_5 VS_eDCHUsersCapacity_HSXPA_AllocLicensingRefusal
NodeB with x/eCEM
U10909_HSXPA_6 VS_eDCHUsersCapacity_HSXPA_AllocHWfail
U10909_HSXPA_NbEvt VS_eDCHUsersCapacity_HSXPA_NbEvt
U10909_HSXPA_7 VS_HSXPAUsersCapacity_HSXPA_NbEvtActive
U10909_HSXPA_8 VS_HSXPAUsersCapacity_HSXPA_CumSqUsedLow64 New in
U10909_HSXPA_9 VS_HSXPAUsersCapacity_HSXPA_CumSqUsedHigh64 UA8
U10909_HSXPA_10 VS_HSXPAUsersCapacity_HSXPA_MaxUsed

HW capa in EDCH users on x/eCEM: HsupaUsersMaxHW_UsersCpty006_B_HSUPA_xCEM =
SW capa in EDCH users on x/eCEM: HsupaUsersLicense_UsersCpty002_B_HSUPA_xCEM =
Note : SW capa <= HW capa
Average # of HSUPA users (over active and non active sampling period of 5 s) not a good
metric (underestimate the real avg load): HsupaUsersCapacity_UsersCpty001_B_HSUPA_xCEM
(= U10909_HSXPA_3/U10909_HSXPA_NbEvt).
86
EDCH Users (at Iub level) for x/eCEM only, new in UA8.1 :
Avg # of EDCH users (over active sampling period of 5 s) : U10909_HSXPA_3/U10909_HSXPA_7 or ext
indicator HsupaUsersCapacityAvgActiveEvt_UserCpt001ac_B_HSUPA_xCEM
Max # of EDCH users (over sampling period of 5 s) on x/eCEM: U10909_HSXPA_10 (but improper
temporal aggregation). Please use instead _HsupaUsersMaxUsed_UserCpty010_HSUPA_xCEM_C ,
which is a user defined indicator (with proper aggregation rule) to import to NPO (in xml) for more
information, please see [R10].
Counter is per HSXPA_Resource. Spatial aggregation at Iub level (sum of max) may overestimate the
real max. Moreover, there is not necessarily a mapping 1 xCEM = 1 HSXPA_Resource (but this is the
most frequent case). Therefore, its difficult to deduce Max EDCH users per CEM.
# of EDCH users standard deviation (during active events):
2^32=exp(32ln(2))
Note: cumSquareUsed" could sometimes be > 2exp32 (whereas screening is coded on 32 bit
integer. Avg + 3* ~ 99% of samples
Std_dev = HsupaUsersCapacityStddeviation_UserCpt001sd_B_HSUPA_xCEM
(finite population with
2 2
CumUsed CumUsed equal probabilities at all
= std_dev = ( )
NbEvtActiv e NbEvtActiv e points)
HsupaUsersCptyIndicator_UserCpt001in_B_HSUPA_xCEM
= Min (max_used , 3* + average_active)
is a real max excluding some very high value of max_used (and seldom)
87
that should not be counted (not toCOPYRIGHT
penalize the customer).
2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
Nb of EDCH UE per LCG (at LCG level) Max screening
Warning: U10921_Avg is the average nb of
EDCH ue over active and non active 5 s
period.
Note: we dont have necessarily 1 LCG =
1xCEM but its the case in the majority of
NodeB. Then U10921_Max gives the max nb
of EDCH UE per CEM
Nb of EDCH fallbacks indicator for EDCH 2ms users capacity exhaustion
Nb of EDCH RL established (2ms+10ms) ( at cell level)

Warning: some
U52_12_Max (VS_RadioLinkEstablishedPerCell_PsHSPAwithoutFdpch_Max) issues in the past
(AR 1-3144315)
Nb of simultaneous EDCH RL established (2ms+10ms) (at cell level)
VS_UlAsConfIdAvgNbrEstablished_UlAsCnfHsupa_Max(U1667_16_Max)
Nb of 2ms & 10ms EDCH users (at cell level) : not working properly (CR766508
duplicate of CR731742)
Non used counter MBMS re-affected (unit is Event should be ignored. Its a number)
88
Nb of 2ms & 10ms EDCH ACTIVE users (at cell level, only for serving cell)
Active user= user who has received a grant and is currently transmitting an eDPDCH part
Not a good indicator for CEM capa:
indeed, U10905 does not reflect inactive eDCH (macrodiversity) we may observe edch users limitation
(DSP /PQ3) whereas this counter is within limit (see CR509264). Therefore, in UA7.1.3.8 and UA8.1,
counters for edch 2 ms and edch 10 ms max users are introduced (spare 11001-11005) see next slide
Moreover, it counts active users, while the xCEM capacity stands for EDCH users (connected but not
necessarily transmitting something in uplink)
VS_eDCHactiveUsers_10ms_users_Max or VS_eDCHactiveUsers_2ms_users_Max
Only accurate at cell level. Aggregation at NodeB level (or at CEM level) by doing a manual sum on the
max of the cells (default NPO spatial aggregation = MAX is not adapted) does not guaranteed that the
max is reached at the same moment.
89
Max nb of 2ms & 10ms EDCH users per CEM board
Spare BTS (from UA7138 & in UA81) to be used per cell
FRS 125171 (NodeB EDCH CAC) & CRs 516037, 509264
Emulate the max value of counter 10925 (introduced in UA9): edchNbOfUsersPerBoard
Unit = nb of users, applicable = per cell (in fact, per board), sampling = 5 s
Note in NPO UA81, unit is users whereas in NPO UA71, unit is Event (for screening 1 to 4).
Screening 5 unit remains Event
E.g.: in UA81: VS_SpareBTS_1(U11001)(users) and in UA71: VS_SpareBTS_1(U11001)(Event)
How to decode manually (in case xml cant be imported)? with table below
byte1=round( counter11001/16777216 )
byte2=round( (counter11001-byte1*16777216)/65536 )
byte3=round( (counter11001-byte1*16777216-byte2*65536)/256 )
byte4=counter11001-byte1*16777216-byte2*65536-byte3*256
90
Max nb of 2ms & 10ms EDCH users per CEM board (followed)
You can also import xml (user defined) that create a set of useful indicators,
created by Priscille Cochois (NEA/TIPS)
Available : see [R12]
Note:
_EDCH_10MS_USERS_MAX_xxxx &
_EDCH_2MS_USERS_MAX_xxxx are
stored indicators. They give value
after their installation (no backward
value). Aggregation (temporal or
spatial) possible
EDCH_BOARDID_xxxx, are
calculated indicator. But no
aggregation (neither temporal nor
spatial) possible
91
Average nb of active E-DCH users per cell
according to the traffic activity detection in U-Plane (82602/R2)
Before 82602/R2, an E-DCH user = active if an E-DCH radio link established and the UE is in CELL_DCH
state. This way of counting is not accurate to estimate the cell load.
With 82602/R2 in UA81, a new way of counting active users is implemented: a user is counted as active
if he exceeds a certain data rate. E-DCH user is "inactive" if measured throughput < given throughput
(32 kbps) for a given duration (1s) and the UE was in "active" state before
'active'/'inactive' reporting by U-Plane for E-DCH users in the cell
Avg & Max nb of EDCH users per cell

Users that have been received a grant. Counted only for the serving cell.
Regardless of edch TTI length (sampling = 100 ms, triggering event=every 40 ms
(mac-e scheduler run)
92
Counters impact Counted as 1 user Counted as 1 user
A Non Serving EDCH RLs B
Serving EDCH RL
Color legend: RNC counter NodeB counter 2ms call (single or multi RAB)
At Iub level NodeB_A:
VS_RadioLinkEstablishedPerCell_PsHSPAwithoutFdpch_Max= U52_12_Max = 2
VS_eDCHUsersCapacity_HSXPA_MaxUsed = 1
VS_eDCHUEsPerLCG_Max=1
VS_eDCHactiveUsers_2ms_users_Max =1
At cell level NodeB A :
VS_SpareBTSxxx Max 2ms users xCEM=1 (for xCEM holding the RLS)
VS_SpareBTSxxx Max 2ms users on all other xCEM=0
At Iub level NodeB_B:

VS_RadioLinkEstablishedPerCell_PsHSPAwithoutFdpch_Max = 2
VS_eDCHUsersCapacity_HSXPA_MaxUsed = 1
VS_eDCHUEsPerLCG_Max=1
VS_eDCHactiveUsers_2ms_users_Max =1
At cell level NodeB B :
VS_SpareBTSxxx Max 2ms users xCEM=1 (for xCEM holding the RLS)
VS_SpareBTSxxx Max 2ms users on all other xCEM=0
93
EDCH users failure (1/8)
EDCH users (at Iub level)
U10909_EDCH_1 VS_eDCHUsersCapacity_EDCH_CumHWcapacity
U10909_EDCH_2 VS_eDCHUsersCapacity_EDCH_CumLicensing NodeB with iCEM
U10909_EDCH_3 VS_eDCHUsersCapacity_EDCH_CumUsed
U10909_EDCH_4 VS_eDCHUsersCapacity_EDCH_AllocSuccess
U10909_EDCH_5 VS_eDCHUsersCapacity_EDCH_AllocLicensingRefusal
U10909_EDCH_6 VS_eDCHUsersCapacity_EDCH_AllocHWfail
U10909_EDCH_NbEvt VS_eDCHUsersCapacity_EDCH_NbEvt
U10909_EDCH_7 VS_eDCHUsersCapacity_EDCH_NbEvtActive
U10909_EDCH_8 VS_eDCHUsersCapacity_EDCH_CumSqUsedLow64 New in UA8, but not applicable
U10909_EDCH_9 VS_eDCHUsersCapacity_EDCH_CumSqUsedHigh64 (the screenings report 0)
U10909_EDCH_10 VS_eDCHUsersCapacity_EDCH_MaxUsed
U10909_HSXPA_1 VS_eDCHUsersCapacity_HSXPA_CumHWcapacity
U10909_HSXPA_2 VS_eDCHUsersCapacity_HSXPA_CumLicensing
U10909_HSXPA_3 VS_eDCHUsersCapacity_HSXPA_CumUsed
U10909_HSXPA_4 VS_eDCHUsersCapacity_HSXPA_AllocSuccess NodeB with x/eCEM
U10909_HSXPA_5 VS_eDCHUsersCapacity_HSXPA_AllocLicensingRefusal
U10909_HSXPA_6 VS_eDCHUsersCapacity_HSXPA_AllocHWfail
U10909_HSXPA_NbEvt VS_eDCHUsersCapacity_HSXPA_NbEvt
U10909_HSXPA_7 VS_HSXPAUsersCapacity_HSXPA_NbEvtActive
U10909_HSXPA_8 VS_HSXPAUsersCapacity_HSXPA_CumSqUsedLow64
New in
U10909_HSXPA_9 VS_HSXPAUsersCapacity_HSXPA_CumSqUsedHigh64 UA8
U10909_HSXPA_10 VS_HSXPAUsersCapacity_HSXPA_MaxUsed

% of EDCH users allocation failures rate due to HW limitation:
HsupaUsersAllocFail_HW_UsersCpty005_B_HSUPA_xCEM = U10909_HSXPA_6 /
(U10909_HSXPA_4+U10909_HSXPA_6)
% of EDCH users allocation failures rate due to SW limitation:
HsupaUsersAllocFailLicense_UsersCpty004_B_HSUPA_xCEM = U10909_HSXPA_5 /
(U10909_HSXPA_4+ U10909_HSXPA_5)
% of EDCH users allocation success rate:
HsupaUsersAllocSuccess_UsersCpty003_B_HSUPA_xCEM = U10909_HSXPA_4 /
(U10909_HSXPA_4+U10909_HSXPA_5+U10909_HSXPA_6)
94
VS_eDCHUsersCapacity_HSXPA_AllocHWfail (U10909_HSXPA_6)
(impacts also: HsupaUsersAllocFail_HW_UsersCpty005_B_HSUPA_xCEM &
HsupaUsersAllocSuccess_UsersCpty003_B_HSUPA_xCEM)
Behaviours change in case of CAC failure EDCH enhanced NodeB CAC
Case failure with UL radio resources not available: U10909_HSXPA_6 incremented
(as before)
CAC Failure case (1) max capacity of 128 reached (except the CR552741 case)
Reminder : CAC for both 2ms & 10ms this is a real HW bottleneck
Case failure with Not enough user plane processing resources: U10909_HSXPA_6 is
no more incremented (CR649468)
CAC Failure case (2) fails for a 2msTTI on the configurable capacity called credits
Reminder : CAC only for 2ms this is not a real HW bottleneck. Avoid confusion regarding max
H/W capacity reached or not
CR implemented in UA7138 EP10 (from UNB07D384A0), in UA813 (UNB08D13210) & in UA814
(UNB08D14300)
However, this counter can be a good indicator to increase the nb of CEM (as not
enough capa to handle the 2ms EDCH users)
Same logic for VS_CEMAllocDCH_AllocFailEDCH(U10318_5)
Case failure with Not enough user plane processing resources: U10318_5 is
no more incremented as for U10909_HSXPA_6
95
Is pegged for miscellaneous EDCH CAC failures
Extract from [R11]
HSxPA RAB Set Up: RL Reconf + RB Setup
HSxPA AO Upsize: RL (First) Setup + RB Reconf
HSxPA Intra-Freq Mobility (Primary RL change): RL Reconf + RB Reconf
HSxPA Intra-Freq Mobility (EDCH SHO non-serving) : RL Setup (inter-NodeB) or RL Addition
(intra-NodeB)
HSxPA Inter-Freq Mobility (HHO) : RL (First) Setup + RB Reconf
(reloc)
For example, mobility soft HO may correspond to many NBAP events compared to
HSXPA RAB Set Up. EDCH CAC may fails (U10909_HSXPA_6 is pegged) for the non
serving RL but the serving stays in 2ms and there is no fallback to 10 ms.
Therefore, U10909_HSXPA_6 >> # fallbacks
An EDCH call establishment fallbacked to UL DCH (CAC EDCH part 1, with
cause UL Radio resources not available).
Monostep (directly to DCH/DCH) :
VS_SucHspaToDchFallbackCell_HsdpaEdchToDchDch(U1601_2)
Multistep (to HSDPA/DCH first, if Nok to DCH/DCH):
VS_SucHspaToDchFallbackCell_HsdpaEdchToHsdpaDch (U1601_1)
96
Enhanced EDCH NodeB CAC failures leading to fallbacks
Nb of EDCH (2ms or 10 ms) calls successfully or unsucessfully fallbacked to UL DCH
(at cell level)
Nb of EDCH 2ms calls successfully or unsucessfully fallbacked to 10ms (at cell level)
Fallback : on RAB assignment, AO upsize, primary cell change, Incoming relocation or Hard
handover.
NPO Indicator ratio vs # EDCH RB successfully setup and successfully reconfigured (warning,
may not be accurate)
Other indicator :
EDCH2ms fallback to10ms success rate = U2895/(U2895+U2897) - proposed criteria =98 % (2% of
failure)
Ratio of EDCH unsuccess fall back calls from HSDPA/EDCH=U1603_1/(U1601_1+U1601_2+U1603_1)
97
HSDPA/2msEDCH
U2897 U2895 U1601_1
U1603_1
U1601_2
HSDPA/10msEDCH
U1603_1 U1603_1
U1601_1
U1603_1
HSDPA/DCH U1601_2
U1603_0
U1601_0
DCH/DCH
98
General EDCH CAC
If EDCH users per board > edchMaxNumberUserXcem (pseudo licensing)
Or if EDCH users per board> EdchNumberUserCapacityLicensing (licensing)
VS_eDCHUsersCapacity_HSXPA_AllocLicensingRefusal(U10909_HSXPA_5)

Nb of EDCH 2ms calls unsucessfully fallbacked to 10ms (at cell level)
For more information, please refer to [R11]
2ms + 10ms CAC failure will peg counters
UL Resources not available (most of cases):
VS_RadioLinkSetupUnsuccess_RadioLinkSetupFailure(U38_0)
NodeB Resources not available (if also DL issue):
VS_RadioLinkSetupUnsuccess_NodeBCEMLackL1Rsrc(U38_4)
2ms only CAC failure will peg counters not enough User Plane Processing Resources
U38_11 VS_RadioLinkSetupUnsuccess_NotEnoughUserPlaneProcessingResources
U41_11 VS_RadioLinkFirstSetupFailure_NotEnoughUserPlaneProcessingResources
U39_9 VS_RadioLinkAdditionUnsuccess_NotEnoughUserPlaneProcessingResources
U40_10 VS_RadioLinkReconfigurationPrepareUnsuccess_NotEnoughUserPlaneProcessingResources
Note: this screening is also used by feature 82602/R3 when (configurable) limit of decoding ressources
is reached (but this is not a matter of number of users)
99
EDCH RNC CAC failure (at cell level)

See [R11] for more details
Limit of x EDCH UE per cell is reached (parameter : edchMaxUsersPerCell )
U1090_0 VS_HsupaCACUnsuccess_NumHsupaPSIbStrUsers
U1090_1 VS_HsupaCACUnsuccess_NumHsupaConvUsers
Limit of y EDCH legs per cell is reached (param edchMaxLegs2msPerCell for EDCH2ms users only)
Note : EDCH RNC CAC success (at cell level) will peg
Metric
Ratio of success PS IB EDCH users allocation =U1089_0/(U1089_0+U1090_0)
100
Counter: U10321 - CEMCongestionEdch2mstti for 2ms users failures (not tested)
at CEM board level, but to be taken at Iub level
U10321_0 : nb of times the Block_2msTTI_users flag toggled over a time (unit=event)
U10321_1_cum : duration for which a particular CEM is in the Block_2msTTI_users flag = TRUE state
(unit=seconds)
U10321_0_NbEvt VS_CEMCongestionEdch2mstti_NbEvt
Proposed criteria (tbc): U10321_1_Cum VS_CEMCongestionEdch2mstti_Cum
Congestion duration (U10321_1_cum): green=0 s, 0 s<yellow<360 s (6 min=10% of 1 hour), Red 360 s
Nb of times congestion occur (U10321_0_NbEvt): : green = 0, 0<yellow<10; red 10
101
EDCH throughput monitoring decision tree
At iub level: no EDCH throughput load
max % of EDCH throughput load > 95%
yes
add directly EDCH throughput resources
Check EDCH throughput failure rate ? EDCH throughput failures

Green
% of EDCH throughput allocation success rate < 100%
Red < 90% - 90% Yellow < 98% - green = 100%
Red or yellow
100% =
Case no capa licensing Case capa licensing (finite value No EDCH throughput failure rate
hsdpaThroughputCapacityLicensing)
HW fail : upgrade iCEM to x/eCEM or add EDCH throughput

x/eCEM. If not enough, D4U, NodeB Increase EDCH throughput license (H2 resource OK
densification. token step is 480 kbps) :
EdchThroughputCapacityLicensing
SW fail : increase EdchMaxThroughputXcem or If not enough, upgrade iCEM to
EdchMaxThroughputEcem up to max value. x/eCEM or add x/eCEM
If not enough, upgrade iCEM to x/eCEM or add If not enough, d4U, odeB densification
x/eCEM
If not enough, d4U, NodeB densification
102
EDCH throughput load (1/4)
Testing avg EDCH throughput used not significant better check max or failure
Avg % of EDCH throughput used > 70% (conservative approach, valid in UA7)
For information (not recommended method)
At Iub level, only available for x/eCEM
Avg % of EDCH throughput used during active period =
(Cumused/NbEvtActive_ SpatialTemporalAggregationAvg) / [ min(CumLicensing ; CumHWcapacity) / NbEvt]
HsupaThroughputCptyAvgActiveEvt_ThgtCpt002ac_B_HSUPA_xCEM /
min(HsupaThroughputLicense_ThgptCpty009_B_HSUPA_xCEM;
HsupaThroughputMaxHW_ThgptCpty010_B_HSUPA_xCEM)
Max % of EDCH throughput used >95% (from UA81)
= _ HsupaTputMaxUsed_ThgtCpty010_HSUPA_xCEM_C(UThgtCpty010_HSUPA_xCEM_C) / min
(HsupaThroughputLicense_ThgptCpty009_B_HSUPA_xCEM; HsupaThroughputMaxHW_ThgptCpty010_B_HSUPA_xCEM)
Where _ HsupaTputMaxUsed_ThgtCpty010_HSUPA_xCEM_C(UThgtCpty010_HSUPA_xCEM_C(Kbit/s) is a user
defined indicator (with proper aggregation rule) to import to NPO (in xml) for more information, please
see (R10]
Other metric for max % of EDCH thoughput based on Avg+3*Std_deviation (from UA81)
= HsupaThroughputCptyIndicator_ThgtCpt002in_B_HSUPA_xCEM / min
Min(Avg+3*Std_deviation,maxUsed) = HsupaThroughputCptyIndicator_ThgtCpt002in_B_HSUPA_xCEM
103
EDCH throughput (at Iub level) :
U10910_EDCH_1 VS_eDCHThroughputCapacity_EDCH_CumHWcapacity
U10910_EDCH_2 VS_eDCHThroughputCapacity_EDCH_CumLicensing NodeB with iCEM
U10910_EDCH_3 VS_eDCHThroughputCapacity_EDCH_CumUsed
U10910_EDCH_4 VS_eDCHThroughputCapacity_EDCH_AllocSuccess
U10910_EDCH_5 VS_eDCHThroughputCapacity_EDCH_AllocLicensingRefusal
U10910_EDCH_6 VS_eDCHThroughputCapacity_EDCH_AllocHWfail
U10910_EDCH_NbEvt VS_eDCHThroughputCapacity_EDCH_NbEvt
U10910_EDCH_7
U10910_EDCH_8
VS_eDCHThroughputCapacity_EDCH_NbEvtActive
VS_eDCHThroughputCapacity_EDCH_CumSqUsedLow64
New in UA8, but not applicable
U10910_EDCH_9 VS_eDCHThroughputCapacity_EDCH_CumSqUsedHigh64 (the screenings report 0)
U10910_EDCH_10 VS_eDCHThroughputCapacity_eDCH_MaxUsed
U10910_HSXPA_1 VS_eDCHThroughputCapacity_HSXPA_CumHWcapacity
U10910_HSXPA_2 VS_eDCHThroughputCapacity_HSXPA_CumLicensing
U10910_HSXPA_3 VS_eDCHThroughputCapacity_HSXPA_CumUsed
U10910_HSXPA_4 VS_eDCHThroughputCapacity_HSXPA_AllocSuccess NodeB with x/eCEM
U10910_HSXPA_5 VS_eDCHThroughputCapacity_HSXPA_AllocLicensingRefusal
U10910_HSXPA_6 VS_eDCHThroughputCapacity_HSXPA_AllocHWfail
U10910_HSXPA_NbEvt VS_eDCHThroughputCapacity_HSXPA_NbEvt
U10910_HSXPA_7 VS_eDCHThroughputCapacity_HSXPA_NbEvtActive
U10910_HSXPA_8 VS_eDCHThroughputCapacity_HSXPA_CumSqUsedLow64
New in
U10910_HSXPA_9 VS_eDCHThroughputCapacity_HSXPA_CumSqUsedHigh64 UA8
U10910_HSXPA_10 VS_eDCHThroughputCapacity_HSXPA_MaxUsed

HW EDCH throughput capa: HsupaThroughputMaxHW_ThgptCpty010_B_HSUPA_xCEM =
xCEM : 10 080 kbps UL (MAC-e level) whereas eCEM: 33120 kbps
SW EDCH throughput Capa: HsupaThroughputLicense_ThgptCpty009_B_HSUPA_xCEM =
edchThroughputCapacityLicensing or edchMaxThroughputXcem & edchMaxThroughputEcem (default = set
to above max Hw values ie automatic, step:480 (kbps) )
Note : SW capa <= HW capa (if SW capa limited, parameter increase possible)
Average EDCH throughput (over active and non active sampling period of 5 s) not a good
metric (underestimate the real avg load):
HsupaThroughputCpty_ThgptCpty002_B_HSUPA_xCEM = 104
New indicators in UA8.1 (only for x/eCEM) :
Avg EDCH throughput (over active sampling period of 5 s) :
HsupaThroughputCptyAvgActiveEvt_ThgtCpt002ac_B_HSUPA_xCEM =
U10910_HSXPA_3/U10910_HSXPA_7with Spatial temporal aggregation Avg
Max EDCH throughput (over sampling period of 5 s) :
_HsupaTputMaxUsed_ThgtCpty010_HSUPA_xCEM_C= U10910HSXPA_10 (with temporal
aggreg =max)
Where _HsupaTputMaxUsed_ThgtCpty010_HSUPA_xCEM_C(UThgtCpty010_HSUPA_xCEM_C)(Kbit/s)
is a user defined indicator (with proper aggregation rule) to import to NPO (in xml) for more
information, please see [R10]. Counter is per HSXPA_Resource: spatial aggregation at Iub level (sum
of max) may overestimate the real max.
Note : counter is per HSXPA_Resource ; spatial aggregation at Iub level (sum of max) may
overestimate the real max
EDCH throughput standard deviation (during active events) :
HsupaThroughputCptyStddeviation_ThgtCpt002sd_B_HSUPA_xCEM
2^32=exp(32ln(2))
integer 2 2
= std_dev = CumUsed CumUsed finite population with equal probabilities at all points)
( )
Indicator for monitoring = Min (max_used , 3* + average_active) :
HsupaThroughputCptyIndicator_ThgtCpt002in_B_HSUPA_xCEM
is a real max as it excludes some very high value 105 of max_used (and very seldom) that should not
be countedALCATEL-LUCENT
(not to CONFIDENTIAL
penalize theFORcustomer)
SOLELY
AUTHORIZED PERSONS HAVING A NEED TO KNOW PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
Other counters
Maximum instantaneous throughput per cell (including retransmission) - baseline
U10904_Avg VS_eDCHdataBitRec_Avg
UHSUPA034_CR_Max E_DCHMAC_eCellThroughput_Max_HSUPA034_CR
U10904_Cum VS_eDCHdataBitRec_Cum
U10904_Max VS_eDCHdataBitRec_Max
UHSUPA034_CR_Max = 500*VS_eDCHdataBitRec_Max U10904_Min VS_eDCHdataBitRec_Min
U10904_NbEvt VS_eDCHdataBitRec_NbEvt
Based on U10904_Max (includes retransmission)
Note: at Iub level, aggregation may be overestimated (max of max at cells, is not necessarily the
max at NodeB)
Average throughput per cell (during ON period)
Average E-DCH MAC-e cell throughput in kbps (averaged over periods for which at least one E-DCH
UE is active in the considered cell)
= 500 * VS_eDCHdataBitRec_Cum / VS_eDCHdataBitRec_NbEvt
This is the most accurate to estimate the average ON UE EDCH throughput
Other indicators
E_DCHMAC_dCellThroughput_HSUPA015_CR(UHSUPA015_CR) : average E-DCH MAC-d cell
throughput in kbps (averaged over periods for which at least one E-DCH UE is active in the
considered cell)
EdchActiveCellThpt_HSUPA022_CR(UHSUPA022_CR) : E-DCH cell throughput over RAB activity
period
AvgULThroughputPerUser_HSUPA009_CR(UHSUPA009_CR) : average Uplink MACd Throughput per
user (Kbps)
They give slightly different values
106
EDCH throughput failures (1/2)
EDCH throughput allocation failures (at Iub level)
U10910_EDCH_1 VS_eDCHThroughputCapacity_EDCH_CumHWcapacity
U10910_EDCH_2 VS_eDCHThroughputCapacity_EDCH_CumLicensing NodeB with iCEM
U10910_EDCH_3 VS_eDCHThroughputCapacity_EDCH_CumUsed
U10910_EDCH_4 VS_eDCHThroughputCapacity_EDCH_AllocSuccess
U10910_EDCH_5 VS_eDCHThroughputCapacity_EDCH_AllocLicensingRefusal
U10910_EDCH_6 VS_eDCHThroughputCapacity_EDCH_AllocHWfail
U10910_EDCH_NbEvt VS_eDCHThroughputCapacity_EDCH_NbEvt
U10910_EDCH_7
U10910_EDCH_8
VS_eDCHThroughputCapacity_EDCH_NbEvtActive
VS_eDCHThroughputCapacity_EDCH_CumSqUsedLow64
New in UA8, but not applicable
U10910_EDCH_9 VS_eDCHThroughputCapacity_EDCH_CumSqUsedHigh64 (the screenings report 0)
U10910_EDCH_10 VS_eDCHThroughputCapacity_eDCH_MaxUsed
U10910_HSXPA_1 VS_eDCHThroughputCapacity_HSXPA_CumHWcapacity
U10910_HSXPA_2 VS_eDCHThroughputCapacity_HSXPA_CumLicensing
U10910_HSXPA_3 VS_eDCHThroughputCapacity_HSXPA_CumUsed
U10910_HSXPA_4 VS_eDCHThroughputCapacity_HSXPA_AllocSuccess NodeB with x/eCEM
U10910_HSXPA_5 VS_eDCHThroughputCapacity_HSXPA_AllocLicensingRefusal
U10910_HSXPA_6 VS_eDCHThroughputCapacity_HSXPA_AllocHWfail
U10910_HSXPA_NbEvt VS_eDCHThroughputCapacity_HSXPA_NbEvt
U10910_HSXPA_7 VS_eDCHThroughputCapacity_HSXPA_NbEvtActive
U10910_HSXPA_8 VS_eDCHThroughputCapacity_HSXPA_CumSqUsedLow64
New in
U10910_HSXPA_9 VS_eDCHThroughputCapacity_HSXPA_CumSqUsedHigh64 UA8
U10910_HSXPA_10 VS_eDCHThroughputCapacity_HSXPA_MaxUsed

% of EDCH throughput allocation failures rate due to HW limitation:
HsupaThroughputAllocFailHw_ThgptCpty008_B_HSUPA_xCEM = U10910_HSXPA_6/(U10910_HSXPA_4+
U10910_HSXPA_6)
% of EDCH throughput allocation failures rate due to SW limitation:
HsupaThroughputAllocFailLicense_ThgptCpty007_B_HSUPA_xCEM = U10910_HSXPA_5/ (U10910_HSXPA_4+
U10910_HSXPA_5)
% of EDCH throughput allocation success rate: HsupaThroughputAllocSuccess_ThgptCpty006_B_HSUPA_xCEM =
U10910_HSXPA_4/(U10910_HSXPA_4+U10910_HSXPA_5+U10910_HSXPA_6)
107
EDCH throughput failures (2/2)
What happens in case of failures ?
there is no fallback for throughput criteria but rather scheduler action to maintain the
throughput below the configured value
Clarifications U10910_HSXPA_5 and U10910_HSXPA_6
The 10910_HSXPA failures may be due to capa licensing issue or RotMax reached
Reminder on unhappy bit
iBTS allows a user to transmit or not, and the user reports if he wants more throughput (Happy /
Unhappy bit).
Each 10ms (to take in account equally the 2ms & 10 ms users):
no transmission: Alloc are unchanged
transmission for one user (or more), without any Unhappy bit received:#4 AllocSuccess++
transmission for one user (or more), with reception for at least one Unhappy bit: #5 or#6 alloc_failures++
some Unhappy bit : because Rot Max has been reached (and not only because of throughput limited by capacity
licensing). Indeed, when Rot max is reached, we may limit the UE throughput in UL and receive some unhappy bit.
108
109
Nb Event NbActiveEvent not working ?
Different behaviours
NodeB with 1 eCEM-u:
NodeB with 1eCEM:
110
Nb Event NbActiveEvent not working ?
CR: DCTPD00881162
Different behaviours
NodeB with 1 eCEM-u & 2 xCEM (+icem but not seen here):
The expected behaviour is:

At each triggering time (t) (i.e, every 5 seconds)
If the CumUsed(t) is not 0 Then
Increment CumUsed(Total)= CumUsed(Total)+CumUsed(t)
NbEvtActive(Total) ++
111
MaxUsed screening?
1-4225500, AR 1-3879163 /DCTPD00852962
maxUsed is the Max value of the CumUsed pegged every 5sec
CumUsed is the value contained in cpUserCac.eBbuUserNumber at the moment the
counter is pegged (ie each 5sec)
cpUserCac.eBbuUserNumber is the number of users that are currently set up. Its value is
updated each time a user is added or deleted.
maxUsed value is not relevant as we can have a burst of UE Setup/Delete between 2
pegging intervals
Eg, we can observe refusals whereas the maxUsed doesnt reach the licence (eg for
EDCH users)
On the field, we see refusals whereas the maxUsed doesnt reach the licence
(licence is 48 on that site 7 refusals for a MaxUsed being 46 at 00:00):
112
NbEvt screening?
1-4225500, NbEvt being less than 720 on xCCM cards and not getting compensated in the subsequent
cycle:
On xCCMs, only the NbEvt is capped to 720, all the other samples (CumUsed etc.) are stored &
reported to WMS.
But in reality, for a given reporting period, we could have NbEvt=720 reported (instead of 721 as it is
in reality) and for real, CumUsed computed, based on 721 samples ; ie the NbEvt displayed will be
less than the real NbEvt...
Note: for iCCM, we observe that the missing reports are reported in the next hours so that NbEvt is
always 720 per hour. (For eg: (719 & 721) ; (726 & 714) etc., ).
113
BBU R99 Load Balancing Algorithm
Load balancing algorithm principle
R99 Call Set Up (SRB over DCH):
RLSetUpRequest : SRB placed on least loaded BBU
RLReconf: SRB reconfigured to SRB+TRB and placed on the same BBU (because the 2
DCH (one for SRB, one for TRB) multiplexed on same physical channel DPDCH)
HSXPA call Set Up (with SRB over DCH)
RLSetUpRequest : SRB placed on least loaded BBU
RLReconf: SRB reconfigured to SRB+TRB and can be placed on a different CEM from
the one hosting the SRB DCH.
What is meant by leas loaded BBU ?
MBBU_preferred is hard coded: xCEM is preferred over iCEM H if xCEM not too
loaded:
If xCEM load < 128 used DCH (= 50% max HW capacity (256)) call is tried to be placed on
xCEM
If xCEM load >= 128 used DCH (= 50% max HW capacity (256)) iCEM and xCEM are
considered equally
Then pseudo CAC (vs r99MaxNumberCeXcem) applies
If xCEM DCH load <= r99MaxNumberCeXcem call placed on xCEM
If xCEM DCH load > r99MaxNumberCeXcem call tried to be placed on iCEM. If there is no
resources on iCEM, the call fails (reason UL or DL NodeB resource unavailable)
114
AR1-4115585/DCTPD00809552 load balancing in UA81
Fixed in UA813 EP4, with a propagation of DCTPD00359725
In case of iCEM + x/eCEM : RL Set Up or RL Reconf failures with cause UL Radio
Resources not Available
CASE 1 Call CASE 2 Call
50% load 50% load
xCEM iCEM128 xCEM iCEM128
Check pseudo CAC Check pseudo CAC

r99MaxNumberCeXcem r99MaxNumberCeXcem
(see next slide) (see next slide)
115
Case 1 : xCEM load is below 50%
Call will be (tried to be) established
Call on iCEM128
CASE 1a
pseudo CAC
50% load fails 50% load
r99MaxNumber r99MaxNumber
CeXcem CeXcem
xCEM iCEM128 xCEM iCEM128
Call Call will be established on xCEM

CASE 1b
r99MaxNumber pseudo CAC r99MaxNumber

CeXcem OK CeXcem
50% load 50% load
116
xCEM iCEM128 COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. xCEM iCEM128
Case 2 : xCEM load is above 50%
Call will be (tried to be) established
CASE 2a
Call on iCEM128
r99MaxNumber pseudo CAC r99MaxNumber

CeXcem fails CeXcem
50% load 50% load
xCEM xCEM iCEM128

iCEM128
Call
CASE 2b Call is balanced
r99MaxNumber
CeXcem
pseudo CAC r99MaxNumber
50% load OK CeXcem
50% load
xCEM iCEM128 117

xCEM iCEM128
R99 call set up schematic (srb placed on xcem):

SRB RL Set Up Request
Case 1b or Case 2b
CASE 1b Enough R99 CE resource on xCEM (pseudo cac OK)
Without CR359725 SRB on xCEM
CASE 2b
SRB ok
SRB+TRB reconf fails RL reconfiguration (SRB SRB+TRB)
iCEM128
Not enough R99 CE resource on xCEM (pseudo cac

xCEM
on r99MaxNumberCeXcem fails)
Without CR359725:
RL reconf fails on xCEM
ul radio resources not available
VS_R99CECapacity_AllocLicensingRefusal(U10317_5)
SRB
With CR359725, CAC on RL Reconf removed:
SRB+TRB Even if pseudo cac on r99MaxNumberCeXcem fails,
reconf OK
iCEM128
If enough total R99 resources on iCEM + xCEM

xCEM
(CAC on r99MaxNumberCeXcem+64*#D-BBU succeeds)

RL Reconf OK
R99 call is spread out over iCEM
With CR359725
118
R99 call set up schematic (srb placed on icem):

Case 2b (xCEM load is above 50%)
SRB ok SRB on iCEM (load balancing)
SRB+TRB reconf fails
RL reconfiguration (SRB SRB+TRB)
iCEM128
xCEM
Not enough R99 CE resource on iCEM to accept TRB

Without CR359725:
RL reconf fails on iCEM
VS_R99CECapacity_AllocHWfail(U10317_6)
Without CR359725
SRB ok With CR359725, CAC on RL Reconf removed:

Even if not enough resources on iCEM
If enough total R99 resources on iCEM + xCEM
SRB+TRB (CAC on r99MaxNumberCeXcem+64*#D-BBU succeeds)
iCEM128
xCEM
reconf OK RL Reconf OK
R99 call is spread out over xCEM (?)
With CR359725
119
HSXPA (2ms EDCH) call set up schematic (srb placed on icem):

Case 2b (xCEM load is above 50%)
TRB EDCH2ms fails SRB ok SRB on iCEM (load balancing)
Fallback to 10ms fails
Fallback to UL DCH fails RL reconfiguration (SRB SRB+TRB HSxPA)
iCEM128
xCEM
Not enough 2ms credit (2ms only cac based on credit)

on xCEM to accept EDCH 2ms call (nor to accept 10ms)
The call is tried on HSDPA UL DCH. SRB stays on iCEM.
Without CR359725 Not enough R99 CE resources on xCEM (pseudo CAC nok)
Without CR359725:
TRB EDCH2ms fails Fall back to R99 RL reconf fails on xCEM
SRB ok ul radio resources not available ?
Fallback to 10ms fails
Fallback to HSDPA-UL DCH ok VS_R99CECapacity_AllocLicensingRefusal(U10317_5)?
With CR359725, CAC on RL Reconf removed:

iCEM128
Even if not enough resources on xCEM for UL DCH

xCEM
TRB OK If enough total R99 resources on iCEM + xCEM

(CAC on r99MaxNumberCeXcem+64*#D-BBU succeeds)
RL Reconf OK
With CR359725
R99 call is tried over iCEM (?) but iCEM does not
support
120 HSDPA part call fails on xCEM or iCEM (?)
which
ALCATEL-LUCENT CONFIDENTIAL SOLELY FOR AUTHORIZED PERSONS HAVING CEM
A NEED TO holds the
KNOW PROPRIETARY failure?
USE PURSUANT TO COMPANY INSTRUCTION
xCEM hardware
A view of xCEM architecture
121
xCEM Hardware Source : iBTS KPI UA9
The xCEM board has 4 types of processor:

MCTL (PQ2), or main controller: handles CallP & i/f with CCM board and RNC, OAM
The MCTL handles the Dedicated NBAP processing, OA&M, it is not on user plane path.
No MCTL CPU load exceeding 15% have been measured under traffic so far, so there is no particular focus on it.
CECTL (PQ3), or CE controller: handles R99+HSD+HSU L2 processing

The Channel Element controller processor does the UMTS L2 processing for
6 R99 cells (up to 256 users)
6 HSD cells (up to 6 Mac-HS schedulers and 128 users)
3 HSU cells (up to 3 Mac-E schedulers and 128 users)
This processor is impacted by both the control and user planes loads, so it may be one of the major bottlenecks
in the xCEM.
OCP DSP: handles HSD+HSU L1 processing for 128 users

Major bottleneck in the xCEM
Onechip 0..3: 4 Onechip ASICs each is handling R99 L1 processing for 64 users
122
Other Source : KTS UA813
UTRAN Upgrade Bulletin, Capacity and Feature Licensing V01.03
November 2012
RRH
New radioCarrierCapacityLicensing parameter in UA81 (replacing former UA71 parameter
rrhCarrierCapacityLicensing which is removed)
radioCarrierCapacityLicensing defines the first carrier activation for MC-TRX. One token = 1 carrier.
Note: this is not a one-to-one replacement because the meaning of the two parameters is different in
the 2 releases). The feature 112779 : Unique carrier licensing scheme for RRH and CPRI based RF
modules gives complete information on this replacement.
UA71 : rrhCarrierCapacityLicensing = number of second or supplementary RX carriers allowed for
RRH or TRDU or MC-TRX. Value 0 means that all RRH and TRDU and MC-TRX are mono-carrier in
Reception.
UA813: radioCarrierCapacityLicensing (applies to ALL carriers: 1st, 2nd, 3rd, H) =number of carriers
allowed for RRH and CPRI-based RF modules. In other terms: number of FDDCells that are mapped
on Sectors not managed by (i/x)TRM or CMSR. Value Infinite means unlimited capacity.
xTRMCapacityLicensing defines the second carrier activation for MC-TRX. One token = 1
carrier.
Removed
rrhTrduThirdCarrierCapacityLicensing
additionalRadioPerSectorCapacityLicensing (removed from UA08.1 Licensing Model, but still kept in
UA08.1 RAN Model)
123
Inter Cem call migration (descoped from UA81)
FN 111451 Inter CEM call migration impacts NodeB performance (xCEM, CCM)
DCH migration applies to HSDPA and EDCH calls
DCH migration triggered at HSDPA or EDCH RL set up, RL reconf, serving cell change (except if initial DCH on iCEM)
DCH migration generates addl inter-CEM & CEM to CCM signaling impacts NodeB performance (xCEM & CCM)
Counters: U10319 & U10320 (VS_dchMigrationServingCellChange)
Screenings: 0=Migration not required, 1=Migration successful, 2=Migration allocation failure, 3=Migration failure on target DCH setup, 4=Other
migration failure
U10319_0 VS_dchMigrationHspaAddition_NotReq
U10319: nb of call migrations on a RL reconfiguration with HSPA addition U10319_1 VS_dchMigrationHspaAddition_Succ
U10319_2 VS_dchMigrationHspaAddition_FailAlloc
U10320: nb of call migrations on a RL reconf with a serving cell change U10319_3 VS_dchMigrationHspaAddition_FailTargetDch
Purpose : U10319_4 VS_dchMigrationHspaAddition_FailOther
assess avg nb of addl DCH required for Call migration U10320_0 VS_dchMigrationServingCellChange_NotReq
U10320_1 VS_dchMigrationServingCellChange_Succ
track contribution of the Call migration to the overall nb of RL Reconf failure. U10320_2 VS_dchMigrationServingCellChange_FailAlloc
U10320_3 VS_dchMigrationServingCellChange_FailTargetDch
Proposed metrics (available at cell level, but to be taken at Iub level) U10320_4 VS_dchMigrationServingCellChange_FailOther
% of HSPA calls requiring migration (HSPA addition)= A
% of HSPA calls requiring migration (RL reconf serving cell change) = B
% of HSPA calls requiring migration (all causes)= C
Nb of DCH migration failures = D
Contribution of DCH migration on RL reconf failure = E
Based on # of RL reconf failures = RadioLinkReconfigurationPrepareUnsuccess_RL012_CR(URL012_CR)(Event)
U 10319 _ 0 U 10320 _ 0 4 4
A = 1 U 10319 _ 0 + U 10320 _ 0 D
4
B = 1
4 C = 1
4 D=
U 10319 _ i +
U 10320 _ i E=
URL012 _ CR

i =0
U 10319 _ i
U 10320 _ i
(U 10319 _ i + U 10320 _ i ) i =2 i=2
i =0 i =0
125

CEM Capacity Monitoring Guide UA8.1 Internal Standard

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CEM Capacity Monitoring Guide UA8.1 Internal Standard

Uploaded by

Copyright:

Available Formats

CEM & CCM capacity monitoring guide UA8.

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

Version 1.1 standard 20 December 2012

Version 1.2 standard 08 April 2013

Version 1.3 Standard 29 April 2013

UMT/IRC/APP/025147 V03.09/EN CEM Capacity Engineering Guide (external)

[R2] NPO baseline and extended UA8.1 dictionaries :

[R3] Internal docs

[R5] UPUG & HPUG

[R6] NodeB Call Model Monitoring Method (internal)

[R7] BTS configuration commands (internal)

[R8] iBTS Performance in traffic - UA7.1.3 status (UMTS/BTS/DD/038527)

[R9] iBTS UA8.1.3 : Traces assessment for High traffic conditions,

[R13] FSM 118154 HSDPA-DC Capa increase

2 | CEM R99 monitoring

3 | CEM general failures monitoring

4 | CEM HSDPA resources monitoring

5 | CEM EDCH resources monitoring

Incorrect NodeB config (traces left active) increases 100

the CCM CPU load (critical for a loaded NodeB) 80

avg CCM CPU (%)

Recorder FLR and BLOG should be standard) 40

Note: incorrect default FLR configuration before 20

Check traces ( see below extract from [R7] and [R8]):

Blog should be configured with Type as follow :

If pltf.bci is present, it should be removed

Nb of RL Setup Failure (cause=0) (U38_0)

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

Avg CCM CPU load 20:00

Look again to CCM CPU load

Recommendation / upgrade path if CCM CPU is above engg threshold:

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

Node B Successful case

Radio Link reconfiguration Ready Msg RL reconf ready ok received

Radio Link Reconfiguration Commit

Radio Link Reconfiguration Cancel Msg RL reconf cancel sent

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

2 | CEM CPU monitoring

3 | CEM R99 monitoring

4 | CEM general failures monitoring

5 | CEM HSDPA resources monitoring

6 | CEM EDCH resources monitoring

Is board monitored a xCEM or eCEM? Yes Check avg CEM CPU at BH ?

Ignore the board No x/eCEM x/eCEM limitation

Periodicity of monitoring Check all CEMs from NodeB:

U10403_CEM_Avg VS_cpuLoad_CEM_Avg PQ3

eCEM and xCEM : U10403 is related to PQ3 (CR00513265.10.t01, FRS121456),

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

Engg limit for iCEM PQ2 CPU ?

NodeBs with iCEM board(s)

Note: in LR13.1, other x/eCEM processor CPU monitoring will be

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

2 | CEM CPU monitoring

3 | CEM R99 monitoring

4 | CEM general failures monitoring

5 | CEM HSDPA resources monitoring

6 | CEM EDCH resources monitoring

add R99 HW resources : add xCEM or upgrade iCEM to

Single cell HSDPA calls

Dual Cell HSDPA calls