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) • U date after L. Ve as’ comments

• Version 1.3 – Standard 29 April 2013 • Typo correction: slide 42, 50.

2 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

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 :


• [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.alcatellucent.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, UMT/BTS/DD/037084 3


•

htt s://wcdma-ll.a

.alcatel-lucent.com/livelink/livelink.exe?func=ll&ob Id=65977722

References (2/2) • [R10] User defined max capacity indicators (xml) •

https://wcdma-ll.app.alcatellucent.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) •

https://wcdma-ll.app.alcatellucent.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 •



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 eng’g 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 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

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 o 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: it’s 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 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

Agenda

1 | CCM monitoring 2 | CEM R99 monitoring 3 | CEM “general” failures monitoring 4 | CEM HSDPA resources monitoring 5 | CEM EDCH resources monitoring


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 eng’g limit = 65% & call reject)

•

xCCM/ECCM CPU eng’g limit



risk if threshold crossed = CCM trap and reset NodeB. Degraded KPI (de

•

70% before UA7.1.3.6 (no backpressure mechanism) egrae e ay c a ee c

•

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])



risk if threshold crossed = risk of CCM trap and NodeB rese 

•

Rejects incoming RL Set Up Request while xCCM in overload condition (=CCM Manager’s mailbox msg size > 200

•

Increased Call Reject (degraded RLSet Up Success Rate

•

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 observation period (1h granularity). For these specific cases, avg over 1 hour is not enough granularity ; 15 min wou be more accurate.



impact CallSetUpSuccessRate, RRCCnxSuccessRate


CCM CPU load background (2/3) • Background on CCM CPU load (followed) • xCCM/eCCM CPU eng’g 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-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 Mailbo size threshold is crossed. • Hysteresis provided for the two resources being monitored to avoid ping-pong effect. 9 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

CCM CPU load background (3/3) • High unwanted contributor to CCM CPU • •

NodeB avg CCM CPU load = f(# NBAP transactions/hr)

Incorrect NodeB config (traces left active) increases the CCM CPU load (critical for a loaded NodeB) It’s recommended to check traces are off (and Flight Recorder “FLR” and BLOG should be standard)

•

Note: incorrect default FLR configuration before UA713 (FLR are ON by default) causing high CCM CPU

•

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

Avg CCM CPU (before FLR Avg CCM CPU (after FL

100 ) % ( U P C M C C g v a

80 60 40 20 0 16

58

0 21

40

8 23

76

3 26

27

2 29

33

3 32

20

4 39

18

1 46

88

4 55

85

2 68

44

2 78

01

9 86

0 97 04 77 45 53 91 39 64 83 9 8 8 5 4 1 8 4 5 6 2 3 5 2 0 2 7 1 8 10 17 20 25 28 29 30 31 33 33

86

# of NBAP transactions pe r hour

Blog should be configured with Type as follow : Type : - - ERR – T e : IN OUT ERR PSG should be avoided

In UA813

If pltf.bci is present, it should be removed


CCM CPU load monitoring (1/5) • Operational method • Observation period: 1 week (5 or 7 days), hourly data (Granularity Period=1 hour • With only one day data, you may be in a specific bursty case • Make an average over a week on max daily values for U10403_CCM_Avg (if week ends ar less loaded, then average on the Monday to Friday week)

• This method can apply to all metrics in decision trees CCM CPU load (GUYANCOURT _BOUVIERS)

120 100

Behaviour below ’ (non loaded week)

CCM CPU avg below eng’g limit (60% for xCCM from UA7136)

U 80 P C f 60 o %

40 20 0 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 000 00 0000 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 0 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 000 00 0000 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 000 00 00 00 00 00 00 000 00 00 00 00 00 0 : :: :: :: : : : : : :: :: :: :: : : : : : : : : : : : :: :: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :: : : : : : : : : : : : :: :: :: : : : : : : : : : :: :: :: :: :: : : : :: :: :: :: :: :: :: : :: : : :: :: :: :: : :: :: :: :: :: :: :: : : : :: :: : : :: :: : :: :: :: :: :: :: :: : :: :: : : :: :: : : 01 23 45 678 90 12 34 56 78 901 23 01 23 45 67 89 012 34 56 78 90 12 301 23 4567 89 01 23 456 78 90 12 30 12 345 67 89 01 23 45 67 890 12 30 12 34 56 789 01 23 45 67 89 01 230 12 34 56 78 90 123 45 67 89 01 23 01 234 56 78 90 12 34 567 89 01 23 01 23 45 678 90 12 34 56 78 9 1 11 11 11 11 122 22 111 11 11 11 12 22 2 11 11 111 11 12 22 2 11 11 11 11 112 22 2 11 11 11 11 11 22 22 1 111 11 11 11 22 22 1 11 11 111 11 22 22 1 11 11 11 11 1

24-févr.

25-févr.

26-févr.

27-févr.

28-févr.

CCM CPU avg

29-févr.

1-mars

2-mars

CCM CPU max

Failure leve l (GUYANCOURT_BOUVIERS)

Behaviour above eng’g limit (loaded week)

s v te s u q e R S L R b N

300 000

120

250 000 0 200 000

100 80

_ 8 150 000 3 U

60

100 000

40

50 000

20

0

0 0 0 : 0

0 0 : 4

0 0 : 8

0 0 : 2 1

0 0 : 6 1

0 0 : 0 2

Nb of RL Set Up Request

0 0 : 0

0 0 : 4

0 0 : 8

0 0 : 2 1

0 0 : 6 1

0 0 : 0 2

0 0 : 0

0 0 : 4

0 0 : 8

0 0 : 2 1

0 0 : 6 1

0 0 : 0 2

0 0 : 0

0 0 : 4

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

0 0 : 8

0 0 : 2 1

0 0 : 6 1

0 0 : 0 2

0 0 : 0

0 0 : 4

0 0 : 8

0 0 : 2 1

0 0 : 6 1

0 0 : 0 2

0 0 : 0

0 0 : 4

0 0 : 8

Total Nb of RL Setup Failures (URL001)


0 0 : 2 1

0 0 : 6 1

0 0 : 0 2

CCM CPU av

CCM CPU load monitoring (2/5) Check backpressure level?

Look at CCM Control Plane load

(one hour GP)

CCM CPU load level ? VS_cpuLoad_CCM_Avg(%) ≤ 50% U10403_CCM_Avg(%) ≤ 50% yes

RLSetUpFailure due to backpressure > 50% of total failure ?

no no

RL Set Up Request Failure Rate ? RLSetUpFail_Rate < 2%

yes

yes Backpressure launched too often CCM limitation suspected optional Perform full NodeB capa study to check if other user plane resources shortage (Iub, CEM…) Is there another

No CCM limitation

Continue Regular monitoring (once a month to capture growing pace)

No CCM limitation

Perform close monitoring

no

yes

no

Upgrade CCM Hw : - Macro: iCCM  xCCM

Other resources shortage contributes to CCM CPU load Remove if possible bottleneck - Capacity param increase

- d2U: iCCM  xCCM or eCCM - else add NodeB or d4U

- Add PCM - Migrate to hubrid Iub …

CCM limitation

Look again to CCM CPU load Periodicity of monitoring While U10403_CCM_Avg < 50% regular monitoring (every month) to capture growing pace If 50%
CCM CPU load monitoring (3 /5) • 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 use retries) • Same for Codes or DL power issues

• CCM Capacity may be impacted by change of Iub backhaul ac p ane con gura on:

• •

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 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

CCM CPU load monitoring (4 /5) • Recommendation / upgrade path if CCM CPU is above eng’g 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) •

ens ca on

w

e

-uor o e a

on


CCM CPU load monitoring (5/5) • 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 back ressure mechanism but not onl from call traces it includes “CEM rocessor 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%


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 Prepare

« Msg RL reconf ready ok » received Peg RadioLinkReconfigurationPrepareSuccess_RL011_CR

Radio Link reconfiguration Ready Radio Link reconfiguration Ready Radio Link Reconfiguration Commit Radio Link Reconfiguration Commit

Peg

RadioLinkReconfigurationCommit_RL052_CR

Node B Unsuccessful case

Node B

RNC

Radio Link Reconfiguration Prepare Radio Link Reconfiguration Prepare Radio Link reconfiguration Failure Radio Link reconfiguration Ready Radio Link Reconfiguration Cancel

Msg RL reconf failure received or timeout Peg RadioLinkReconfigurationPrepareUnsuccess_RL012_CR Msg RL reconf cancel sent peg u26


Agenda 1 | CCM monitoring 2 | CEM CPU monitoring 3 | CEM R99 monitoring 4 | CEM “general” failures monitoring 5 | CEM HSDPA resources monitoring 6 | CEM EDCH resources monitoring


CEM CPU load monitoring (1/5) Isolate xCEM or eCEM among all boards monitored

(One hour GP, at board level)

Is board monitored a xCEM or eCEM? VS_cpuLoad_CEM_NbEvt(U10403_CEM_NbEvt)(Event) ~ 12

Yes

Check avg CEM CPU at BH ? VS_cpuLoad_CEM_Avg(U10403_CEM_Avg(%) U10403_CEM_Avg≤50% Low CPU

No

50% < U10403_CEM_Avg<70% Medium CPU 70% ≤ U10403_CEM_Avg High CPU

Ignore the board

U10403_CEM_NbEvt ~ 3600  iCEM = N/A  other boards (CCM, RRH, TRM)

No x/eCEM limitation

No x/eCEM limitation

Continue regular monitoring

Perform close monitoring

x/eCEM limitation yes Max CEM CPU at BH VS_cpuLoad_CEM_Max(U10403_CEM_Max(%) > 80% no High load

Very high load (CEM trap possible)

Check all CEMs from NodeB: If iCEM boards present  replace iCEM by xCEM or eCEM If only x/eCEM  check if their load is balanced. 1) If balanced, then add xCEM/eCEM (if not possible d4U or NodeB densification ) 2) If not balanced, check param setting (activate HSxPA resources o 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) COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

Periodicity of monitoring Regular monitoring (every month, or every 3 months) to capture growing pace Close monitoring (every 2 weeks) to anticipate action ≥ eng’g limit  urgent action

ALCATEL-LUCENT — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

CEM CPU load monitoring (2/5) icem:

• Since UA7138 and in UA81:

x/ecem:

U10403_CEM_Avg VS_cpuLoad_CEM_Avg U10403_CEM_Max VS_cpuLoad_CEM_Max U10403_CEM_Avg VS_cpuLoad_CEM_Avg U10403_CEM_Max VS_cpuLoad_CEM_Max

• 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)



• Eng’g limit for avg x/eCEM PQ3 CPU = 70% • PQ3 mainly impacted by nb of users (R99+HSDPA ) and HSDPA throughput

• Double check : eng’g 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%. 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

CEM CPU load monitoring (3/5) • Eng’g limit for iCEM PQ2 CPU ? • No eng’g 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 it’s 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


CEM CPU load monitoring (4/5) • 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, w t ate n co umn, oar s n 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) 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

CEM CPU load monitoring (5/5) • 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) 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

x/eCEM CPU: behaviour in high load • x/eCEM CPU behaviour in high load • Degraded KPI (HSxPA throughput mainly)

by courtesy of 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) : •

. . overload during SKT pilot in UA8.1.3

• UA8.1.4 - CR796866 : LGE test results : xCEM traps due to PQ3 blocked in overlo 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 isn’t 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 prior (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) 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

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 d


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


Agenda 1 | CCM monitoring 2 | CEM CPU monitoring 3 | CEM R99 monitoring 4 | CEM “general” failures monitoring 5 | CEM HSDPA resources monitoring 6 | CEM EDCH resources monitoring


R99 CE monitoring decision tree At iub level: % of R99 CE used (worst UL, DL) > x% Warning = 50%, red = 70% ?

R99 CE load

no

yes

Check burstiness: max R99 CE load (from UA81 only)

High average R99 CE load (CE R99 near resource exhaustion) In case of proactive monitoring:

yes

add directly R99 CE resources

At iub level: Max % of R99 CE load > y% (warning = 75%, red= no

R99 CE CAC failure check Check R99 CE failure rate ? % of R99 CE allocation failure > 0% Red > 5% - 0.5% < Yellow < 5% - green <0.5%

Green or 0%

Red or yellow Case capa licensing (finite value Case no capa licensing r99NumberCECapacityLicensing) HW fail: make sure (UL&DL) CEM load in iRM is activated (isCEMColourCalculationEnabled= true) and tune iRM thresholds (more aggressive to decrease the nb of high data rate RB UL & DL) – If still blocking: add add CEM Hw SW fail: in case of xCEM presence, check value of r99MaxNumberCeXcem parameter (must be either =0 (R99 on iCEM only) or can be increas ed (commercial agreement) so that r99MaxNumberCeXcem ≥ 256 * Nb_xCEM. If still blocking; add CEM Hw

R99 CE failures

Green = Small R99 CE failure rate

Close monitoring recommended

Increase R99 license (D token) :  r99NumberCECapacityLicensing and readapt iRM CEM load thresholds accordingly

“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. ALCATEL-LUCENT — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION densification

0% = No R99 CE failure rate

R99 CE resource OK

Look for HSxPA Resource shortage

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 . . . . 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


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 migration descoped from UA8.1) • On CEM hosting the EDCH part, 1 CE UL consumed for ‘silent-DCH’ (UL HSDPCCH), 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)


R99 CE load (1/9)

New in UA8.1

• CE usage (at NodeB or Iub level): • Counter U10317 adapted • Applicable to cap acity 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: , • = “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 see some failure (U10317_5) whereas the U10317_10 < availableR99CEcapa 31


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 additional D token



increase r99NumberCECapacityLicensing via

• 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 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

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). is defined R99CEUsedAvgActiveEvt_R99CECpty004r_B_CEM(UR99CECpty004r_B_CEM)(Event) 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 _ _ _ _ _ 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 UR99CECpty003_B_CEM UR99CECpty004_B_CEM

R99CELicenseUsed_R99CECpty002_B_CEM R99CEMaxHW_R99CECpty003_B_CEM R99CEUsed_R99CECpty004_B_CEM

VS_R99CECapacity_CumLicensing/VS_R99CECapacity_NbEvt VS_R99CECapacity_CumHWcapacity/VS_R99CECapacity_NbEvt VS_R99CECapacity_CumUsed/VS_R99CECapacity_NbEvt


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 it’s "split" into 2 different screenings #8 and #9, that can both fit in a 32bit integer. • Check if working ? 2

• σ

= std_dev =

2 CumUsed CumUsed −( ) NbEvtActive NbEvtActive

(finite population with equal probabilities at all points)

• 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 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

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.

•

u ere are o er coun ers ava a e per ce or per oca ce group a helps to complement the picture in that case (e.g 10318 or 10309).


R99 CE load (6/9) • R99 CE used (UL and DL details ; per LCG)

Data currently reported by U10310 are not fully reliable and 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 U10310_3_Max U10310_0_Min U10310_2_Min

VS_LocalCellGroupLoad_UsedUL_Max VS_LocalCellGroupLoad_UsedDL_Max VS_LocalCellGroupLoad_FreeUL_Min VS_LocalCellGroupLoad_FreeDL_Min

• This allows to s ot R99 carrier strate

and une ual 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 U10310_0_Cum U10310_0_Max U10310_0_Min U10310_0_NbEvt

VS_LocalCellGroupLoad_FreeUL_Avg VS_LocalCellGroupLoad_FreeUL_Cum VS_LocalCellGroupLoad_FreeUL_Max VS_LocalCellGroupLoad_FreeUL_Min VS_LocalCellGroupLoad_FreeUL_NbEvt

U10310_2_Avg U10310_2_Cum U10310_2_Max U10310_2_Min U10310_2_NbEvt

VS_LocalCellGroupLoad_FreeDL_Avg VS_LocalCellGroupLoad_FreeDL_Cum VS_LocalCellGroupLoad_FreeDL_Max VS_LocalCellGroupLoad_FreeDL_Min VS_LocalCellGroupLoad_FreeDL_NbEvt

U10310_1_Avg U10310_1_Cum U10310_1_Max U10310_1_Min U10310_1_NbEvt

VS_LocalCellGroupLoad_UsedUL_Avg U10310_3_Avg VS_LocalCellGroupLoad_UsedDL_Avg VS_LocalCellGroupLoad_UsedUL_Cum U10310_3_Cum VS_LocalCellGroupLoad_UsedDL_Cum VS_LocalCellGroupLoad_UsedUL_Max U10310_3_Max VS_LocalCellGroupLoad_UsedDL_Max 36 VS_LocalCellGroupLoad_UsedUL_Min U10310_3_Min VS_LocalCellGroupLoad_UsedDL_Min COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. VS_LocalCellGroupLoad_UsedUL_NbEvt U10310_3_NbEvt VS_LocalCellGroupLoad_UsedDL_NbEvt ALCATEL-LUCENT — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

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 •

er

,

ere s no cons s ency e ween sum use + ree vs o a

-

• Per LCG, risk of erroneous value at LCG level in case of sev eral 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 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

R99 CE load (8/9) • U10301 (VS_CEMUsed_DCH) – unit = %, at NodeB

U10301_Avg VS_CEMUsedDCH_Avg U10301_Cum VS_CEMUsedDCH_Cu U10301_Max VS_CEMUsedDCH_Ma U10301_Min VS_CEMUsedDCH_Mi level U10301_NbEvt VS_CEMUsedDCH_NbE

• 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. Ind U10301_avg does not take into account R99 capacity licensing (r99NumberCECapacityLicensing)

value (r99MaxNumberCeXcem ) it refers only to the HW capacity, the cumulation of the maxim • 1) nor In case there are no xCEMs then 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 ”, . • 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 •

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 case A : case B : Capacity Licensing infinite (deactivated) VS_CEMUsedDCH --> CE load R99NumberCECapacityLicensing = infinite VS_CEMUsedDCH --> DSP load 38 Capacity Licensing finite (activated) case C : 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 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 . – .

R99 CE load e stimation by N odeB

BTS counter : U10301_x = VS_CEMUsedDCH_x Domain : NodeB level

R99 CE load e stimation by R NC BTS counter : U10310_x (VS_LocalCellGroupLoad_x) Domain : to be aggregated at NodeB level (else erroneous) RNC counter : U1177_x = VS_QosDlCemLdClrYellow_x U1178_x = VS_QosDlCemLdClrRed_x U1153_x = VS_QosDLCemLdClrBlack_x U1180_x = VS_QosUlCemLdClrYellow_x U1181_x = VS_QosUlCemLdClrRed_x U1201_x =VS_QosUlCemLdClrBlck_x U1179_x = VS_QosDlCemLdCellPreemptClrCngstd_x Domain : cell level

Algo : both iCEM & xCEM CE mod Algo : only iCEM model (pessimisti view)


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 (%) – 1 st 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 UA • 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)


R99 CE failures (3/8) • 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’ srcin. It’s always related to the DCH part U10318_0 U10318_1 U10318_2 U10318_3 U10318_4 U10318_5

VS_CEMAllocDCH_AllocSuccessDCH VS_CEMAllocDCH_AllocFailDCH VS_CEMAllocDCH_AllocSuccessHSDPA VS_CEMAllocDCH_AllocFailHSDPA VS_CEMAllocDCH_AllocSuccessEDCH VS_CEMAllocDCH_AllocFailEDCH

• U10318 : to confirm R99 traffic has increased (higher due to more HSxPA fallback) • In phase with VS_Edch2msTtiTo10msTtiFallbackSuccess(U2895) & _

• 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 : it’s 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 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

R99 CE failures (4/8) • 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 a oca on a ure or e or • 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


R99 CE failures (5/8)

Verifier les métriques

• 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 CE totally consumed: at EDCHU10318_1 call setup (regardless UL SRB is over DCH or EDCH) : only theand DCHR99 specific failures will be pegged (VS_CEMAllocDCH_AllocFailDCH)

• R99 CE failure rate (%) – 2 nd metric: [VS_CEMAllocDCH_AllocFailDCH(U10318_1) + _ _ _ _ _ sum(all screenings of U10318) • Normally, this metric should be aligned withR99 CE failure rate (%) – 1 st metric


_

R99 CE failures (6/8) • R99 CE CAC failure (LCG level counter #10309) • Nb of times CE R99 resources allocation succeeds or fails • R99 CE failure rate (%) – 3 rd 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 withR99 CE failure rate (%) – 1 st metric

U10309_0 U10309_2

VS_CEMAlloc_Success VS_CEMAlloc_FailSetup

U10309_3 U10309_4 U10309_5

VS_CEMAlloc_FailReconf VS_CEMAlloc_FailSetupLock VS_CEMAlloc_FailReconfLock

CEM resources HW blocking CEM resources software blocking


R99 CE failures (7/8) • R99 CE load seen by RNC (cell level counters)

U1180_avg, U1181_avg Not accurate (icem model, pessim view)Not reliable U1180_Avg U1180_Cum U1180_Max U1180_Min U1180_NbEvt

VS_QosUlCemLdClrYellow_Avg VS_QosUlCemLdClrYellow_Cum VS_QosUlCemLdClrYellow_Max VS_QosUlCemLdClrYellow_Min VS_QosUlCemLdClrYellow_NbE

U1181_Avg U1181_Cum U1181_Max U1181_Min

VS_QosUlCemLdClrRed_Avg VS_QosUlCemLdClrRed_Cum VS_QosUlCemLdClrRed_Max VS_QosUlCemLdClrRed_Min

U1181_NbEvt U1201_Avg U1201_Cum U1201_Max U1201_Min U1201_NbEvt

VS_QosUlCemLdClrRed_NbEvt VS_QosUlCemLdClrBlack_Avg VS_QosUlCemLdClrBlack_Cum VS_QosUlCemLdClrBlack_Max VS_QosUlCemLdClrBlack_Min VS_QosUlCemLdClrBlack_NbEvt

U1177_Avg U1177_Cum U1177_Max U1177_Min U1177_NbEvt

VS_QosDlCemLdClrYellow_Avg VS_QosDlCemLdClrYellow_Cum VS_QosDlCemLdClrYellow_Max VS_QosDlCemLdClrYellow_Min VS_QosDlCemLdClrYellow_NbE

• avg % of time spent in yellow DL = U1177_avg

U1178_Avg U1178_Cum U1178_Max

VS_QosDlCemLdClrRed_Avg VS_QosDlCemLdClrRed_Cum VS_QosDlCemLdClrRed_Max

• avg % of time spent in red DL = U1178_avg

U1178_Min U1178_NbEvt VS_QosDlCemLdClrRed_Min VS_QosDlCemLdClrRed_NbEvt

• % of time the cell is black, red or yellow due to CEM UL load • Test = avg % of time spent in yellow UL = U1180_avg •

Threshold yellow = 10% , Threshold red = 50%

• Test = avg % of time spent in red U L = U1181_avg •

Threshold yellow = 10% , Threshold red = 50%

• Test = avg % of time spent in black UL (new in UA81) = U1201_avg •

=

,

=

• % of time the cell is black, red or yellow due to CEM DL load • Note: with bidirectional CE cost in CEM, the UL is more loaded than the DL. It’s no use looking at the DL way.

• avg % of time spent in black DL (new in UA81) = U1153_avg U1153_Avg U1153_Cum

VS_QosDlCemLdClrBlack_Avg VS_QosDlCemLdClrBlack_Cum U1153_Max VS_QosDlCemLdClrBlack_Max U1153_Min VS_QosDlCemLdClrBlack_Min U1153_NbEvt VS_QosDlCemLdClrBlack_NbEvt


R99 CE failures (8/8) • 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 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 U1179_Avg U1179_Cum U1179_Max U1179_Min U1179_NbEvt

VS_QosDlCemLdCellPreemptClrCngstd_Avg VS_QosDlCemLdCellPreemptClrCngstd_Cum VS_QosDlCemLdCellPreemptClrCngstd_Max VS_QosDlCemLdCellPreemptClrCngstd_Min VS_QosDlCemLdCellPreemptClrCngstd_NbEvt


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.


Agenda



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 ressou 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 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)

Other general failures (2/4) • 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 (can’t be allocated properly for given UE)  drop • Observe recommendation from HPUG “Tuning of maxNrOfErg chEhich (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 13045602 / 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 (channels) 1 2 3 4

# RL EDCH (per cell)

12

3 4 56 18 36 54 72 90 108xCEM 18 18 36 54 72 90 108eCEM 36 72 108 144 180 216xCEM 36 36 72 108 144 180 216eCEM 54 108 162 216 256 256xCEM 54 54 108 162 216 270 324eCEM 51 72COPYRIGHT 144© 2011 ALCATEL-LUCENT. 216ALL RIGHTS RESERVED. 256 256 256xCEM 72 ALCATEL-LUCENT — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION 72 144 216 288 360 384eCEM

Other general failures (3/4) 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


Other general failures (4/4)

• 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 U39_4 U40_4

VS_RadioLinkSetupUnsuccess_NodeBCEMLackL1Rsrc VS_RadioLinkAdditionUnsuccess_NodeBCEMLackL1Rsrc VS_RadioLinkReconfigurationPrepareUnsuccess_NodeBCEMLackL1Rsrc 53


Agenda



HSDPA resource monitoring decision trees • We have 2 decision trees for HSDPA • One decision tree for HSDPA Users • One decision tree for HSDPA Throughput


HSDPA users monitoring decision tree At iub level: Avg % of HSDPA connections load > x% (e.g.70%) ? yes

no

Check burstiness: max HSDPA UE connection load

High average HSDPA UE load (HSDPA UE near to resource exhaustion) In case of proactive monitoring: add directly HSDPA UE resources

HSDPA users load

yes

At iub level: max % of HSDPA connections load > 95 % no

HSDPA users CAC failure check Check HSDPA Users failure rate ? % of HSDPA users allocation success rate < 100% Red < 98% - 98% ≤ Yellow < 100% - green = 100% Case no capa licensing

Red or yellow

HSDPA users failure

Green

Case capa licensing (finite value hsdpaNumberUserCapacityLicensing)

100% = No HSDPA UE failure rate

HW fail : upgrade iCEM to x/eCEM or add Increase HSDPA UE license (H1 token – x/eCEM. If not enough, d4U, NodeB step is 8 users) :  hsdpaNumberUserCapacityLicensing densification SW fail : increase If not enough, upgrade iCEM to x/eCEM hsdpaMaxNumberUserxCEM up to 128. or add x/eCEM If not enough, upgrade iCEM to x/eCEM or If not enough, d4U, NodeB densification add x/eCEM. If not enough, d4U, NodeB densification Note: DualCell HSDPA capacity increase (4 to 56 COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. 15) will increase the level—of failure ALCATEL-LUCENT CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

HSDPA capacity OK

HSDPA throughput decison tre

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)


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)


HSDPA users load (2/6) • 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 (HsdpaUsersLicense_UsersCpty002_B_HSDPA_xCEM;HsdpaUsersMaxHW_UsersCpty006_B_HSDPA_xCEM) • 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) ? • n erna cp ser ac.e u ser um er s en o users oa e . su p a e eac mea 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 reall (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 (HsdpaUsersLicense_UsersCpty002_B_HSDPA_xCEM;HsdpaUsersMaxHW_UsersCpty006_B_HSDPA_xCEM) • 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 • •


H S D P A u s e rs l o a d ( 3 / 6 ) • HSDPA Users (at Iub level) : U10835_HSDPA_1 U10835_HSDPA_2 U10835_HSDPA_3 U10835_HSDPA_4 U10835_HSDPA_5 U10835_HSDPA_6 U10835_HSDPA_NbEvt U10835_HSDPA_7 U10835_HSDPA_8 U10835_HSDPA_9 U10835_HSDPA_10

VS_HsdpaUsersCapacity_HSDPA_CumHWcapacity VS_HsdpaUsersCapacity_HSDPA_CumLicensing VS_HsdpaUsersCapacity_HSDPA_CumUsed VS_HsdpaUsersCapacity_HSDPA_AllocSuccess VS_HsdpaUsersCapacity_HSDPA_AllocLicensingRefusal VS_HsdpaUsersCapacity_HSDPA_AllocHWfail VS_HsdpaUsersCapacity_HSDPA_NbEvt VS_HsdpaUsersCapacity_HSDPA_NbEvtActive VS_HsdpaUsersCapacity_HSDPA_CumSqUsedLow64 VS_HsdpaUsersCapacity_HSDPA_CumSqUsedHigh64 VS_HsdpaUsersCapacity_HSDPA_MaxUsed

U10835_HSXPA_1 U10835_HSXPA_2 U10835_HSXPA_3 U10835_HSXPA_4 U10835_HSXPA_5 U10835_HSXPA_6 U10835_HSXPA_NbEvt _ _ U10835_HSXPA_7 U10835_HSXPA_8 U10835_HSXPA_9

VS_HsdpaUsersCapacity_HSXPA_CumHWcapacity VS_HsdpaUsersCapacity_HSXPA_CumLicensing VS_HsdpaUsersCapacity_HSXPA_CumUsed VS_HsdpaUsersCapacity_HSXPA_AllocSuccess VS_HsdpaUsersCapacity_HSXPA_AllocLicensingRefusal VS_HsdpaUsersCapacity_HSXPA_AllocHWfail VS_HsdpaUsersCapacity_HSXPA_NbEvt _ s pa sers apac y_ _ ax se VS_HsdpaUsersCapacity_HSXPA_NbEvtActive VS_HsdpaUsersCapacity_HSXPA_CumSqUsedLow64 VS_HsdpaUsersCapacity_HSXPA_CumSqUsedHigh64

NodeB with iCEM

New in UA8, but not applicable (the screenings report 0)

NodeB with x/eCEM

New in UA8

• 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 = U10835_HSXPA_2/U10835_HSXPA_NbEvt • 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 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

H S D P A u s e rs l o a d ( 4 / 6 ) • 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)) •

ote : cum quare se cou somet mes e > exp w ereas screen ng s co e on t integers), therefore it’s "split" into 2 different screenings #8 and #9, that can both fit in a 32bit integer.

• Std_dev = HsdpaUsersCapacityStddeviation_UserCpt001sd_B_HSDPA_xCEM

σ

= std_dev =

2 CumUsed CumUsed −( ) NbEvtActiv e NbEvtActiv e

2


• 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 samp

that should not be counted (not to penalize the customer). 61 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

H S D P A u s e rs l o a d ( 5 / 6 ) • # 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 mor e 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 U10821_Max U10821_Min U10821_NbEvt

VS_HsdpaUEsPerLCG_Cum VS_HsdpaUEsPerLCG_Max VS_HsdpaUEsPerLCG_Min VS_HsdpaUEsPerLCG_NbEvt

• For iCEM only : # of HSDPA UE per HBBU (at HSDPA level) U10820_Avg U10820_Cum U10820_Max U10820_Min U10820_NbEvt

VS_HsdpaUEsPerHBBU_Avg VS_HsdpaUEsPerHBBU_Cum VS_HsdpaUEsPerHBBU_Max VS_HsdpaUEsPerHBBU_Min 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 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 U10828_NbEvt VS_HsdpaNbUserWithDataTTI_NbEvt

H S D P A u s e rs l o a d ( 6 / 6 ) • 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 12830=98 legacy HSDPA users

• Impact of Dual Cell user on counter , • 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)


HSDPA users failure (1/4) • HSDPA users (at Iub level) U10835_HSDPA_1 U10835_HSDPA_2 U10835_HSDPA_3 U10835_HSDPA_4 U10835_HSDPA_5 U10835_HSDPA_6 U10835_HSDPA_NbEvt U10835_HSDPA_7 U10835_HSDPA_8 U10835_HSDPA_9 U10835_HSDPA_10

VS_HsdpaUsersCapacity_HSDPA_CumHWcapacity VS_HsdpaUsersCapacity_HSDPA_CumLicensing VS_HsdpaUsersCapacity_HSDPA_CumUsed VS_HsdpaUsersCapacity_HSDPA_AllocSuccess VS_HsdpaUsersCapacity_HSDPA_AllocLicensingRefusal VS_HsdpaUsersCapacity_HSDPA_AllocHWfail VS_HsdpaUsersCapacity_HSDPA_NbEvt VS_HsdpaUsersCapacity_HSDPA_NbEvtActive VS_HsdpaUsersCapacity_HSDPA_CumSqUsedLow64 VS_HsdpaUsersCapacity_HSDPA_CumSqUsedHigh64 VS_HsdpaUsersCapacity_HSDPA_MaxUsed

U10835_HSXPA_1 U10835_HSXPA_2 U10835_HSXPA_3 U10835_HSXPA_4 U10835_HSXPA_5 U10835_HSXPA_6 U10835_HSXPA_NbEvt U10835_HSXPA _10 U10835_HSXPA_7 U10835_HSXPA_8 U10835_HSXPA_9

VS_HsdpaUsersCapacity_HSXPA_CumHWcapacity VS_HsdpaUsersCapacity_HSXPA_CumLicensing VS_HsdpaUsersCapacity_HSXPA_CumUsed VS_HsdpaUsersCapacity_HSXPA_AllocSuccess VS_HsdpaUsersCapacity_HSXPA_AllocLicensingRefusal VS_HsdpaUsersCapacity_HSXPA_AllocHWfail VS_HsdpaUsersCapacity_HSXPA_NbEvt VS _Hsd aUsersCa acit _HSXPA _ MaxUsed VS_HsdpaUsersCapacity_HSXPA_NbEvtActive VS_HsdpaUsersCapacity_HSXPA_CumSqUsedLow64 VS_HsdpaUsersCapacity_HSXPA_CumSqUsedHigh64

NodeB with iCEM


NodeB with x/eCEM

ew n UA8

• Indicators for x/eCEM (also exist for iCEM): • % 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 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

HSDPA users failure (2/4) • 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)

=

• • 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)


HSDPA users failure (3/4) • 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

_ _ _

_ _

• But fallback can occur not only at RB Set Up, but after mobility, Always ON 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 U1601_1 U1601_2

VS_SucHspaToDchFallbackCell_HsdpaDchToDchDch VS_SucHspaToDchFallbackCell_HsdpaEdchToHsdpaDch VS_SucHspaToDchFallbackCell_HsdpaEdchToDchDch

66 U1603_0 VS_UnsucHspaToDchFallbackCell_DlHsdpaUlDch 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 U1603_1 VS_UnsucHspaToDchFallbackCell_DlHsdpaUlEdch

HSDPA users failure (4/4) • Other metrics: Nb of HSDPA RB blocked could be representative of HSDP users capacity shortage… but not only (to be handled with care)

• Based on counters


HSDPA throughput monitoring decision tree HSDPA throughput

no

At iub level: max % of HSDPA throughput load > 95% yes In case of proactive monitoring: add directly HSDPA throughput resources

Check HSDPA throughput failure rate ? % of HSDPA throughput allocation success rate < 100% Red < 90% - 90% ≤ Yellow < 98% - green = 100% Red or yellow Case no capa licensing

Case capa licensing (finite value hsdpaThroughputCapacityLicensing)

HW fail : upgrade iCEM to x/eCEM or add x/eCEM. If not enough, D4U, NodeB densification. SW fail : increase hsdpaMaxThroughputXcem or hsdpaMaxThroughputEcem up to max value. If not enough, upgrade iCEM to x/eCEM or add x/eCEM If not enough, d4U, NodeB densification

Green

HSDPA throughp ut failures

100% = No HSDPA throughput failure rate

Increase HSDPA throughput license (H2

HSDPA throughpu resource OK

token – step is 1800 kbps) :  hsdpaThroughputCapacityLicensing If not enough, upgrade iCEM to x/eCEM or add x/eCEM If not enough, d4U, odeB densification

Look for EDCH Resources Shortage


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) • •

[MaxUsedtemporal aggreg=Max]/ [min(CumLicensing, CumHWcapacity)/NbEvt] = _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 u defined indicator (with proper aggregation rule) to import to NPO (in xml) – for more information, pleas 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) •

Min(Avg+3*Std_deviation,maxUsed)/[min(CumLicensing, CumHWcapacity)/NbEvt]

•

= HsdpaThroughputCptyIndicator_ThgptCpty002indic_B_HSDPA_xCEM / min


Min(Avg+3*Std_deviation,maxUsed) = HsdpaThroughputCptyIndicator_ThgptCpty002indic_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 •


HSDPA throughput load (2/4) • HSDPA throughput (at Iub level) : U10836_HSDPA_1 U10836_HSDPA_2 U10836_HSDPA_3 U10836_HSDPA_4 U10836_HSDPA_5 U10836_HSDPA_6 U10836_HSDPA_NbEvt U10836_HSDPA_7 U10836_HSDPA_8 U10836_HSDPA_9 U10836_HSDPA_10

VS_HsdpaThroughputCapacity_HSDPA_CumHWcapacity VS_HsdpaThroughputCapacity_HSDPA_CumLicensing VS_HsdpaThroughputCapacity_HSDPA_CumUsed VS_HsdpaThroughputCapacity_HSDPA_AllocSuccess VS_HsdpaThroughputCapacity_HSDPA_AllocLicensingRefusal VS_HsdpaThroughputCapacity_HSDPA_AllocHWfail VS_HsdpaThroughputCapacity_HSDPA_NbEvt VS_HsdpaThroughputCapacity_HSDPA_NbEvtActive VS_HsdpaThroughputCapacity_HSDPA_CumSqUsedLow64 VS_HsdpaThroughputCapacity_HSDPA_CumSqUsedHigh64 VS_HsdpaThroughputCapacity_HSDPA_MaxUsed

U10836_HSXPA_1 U10836_HSXPA_2 U10836_HSXPA_3 U10836_HSXPA_4 U10836_HSXPA_5 U10836_HSXPA_6 U10836_HSXPA_NbEvt U10836_HSXPA_7 U10836_HSXPA_8 U10836_HSXPA_9 U10836_HSXPA_10

VS_HsdpaThroughputCapacity_HSXPA_CumHWcapacity VS_HsdpaThroughputCapacity_HSXPA_CumLicensing VS_HsdpaThroughputCapacity_HSXPA_CumUsed VS_HsdpaThroughputCapacity_HSXPA_AllocSuccess VS_HsdpaThroughputCapacity_HSXPA_AllocLicensingRefusal VS_HsdpaThroughputCapacity_HSXPA_AllocHWfail VS_HsdpaThroughputCapacity_HSXPA_NbEvt VS_HSXPAThroughputCapacity_HSXPA_NbEvtActive VS_HSXPAThroughputCapacity_HSXPA_CumSqUsedLow64 VS_HSXPAThroughputCapacity_HSXPA_CumSqUsedHigh64 VS_HSXPAThroughputCapacity_HSXPA_MaxUsed

NodeB with iCEM


NodeB with x/eCEM

New in UA8

• Indicators for x/eCEM (also exist for iCEM): • HW HSDPA throughput capa: HsdpaThroughputMaxHW_ThgptCpty010_B_HSDPA_xCEM = U10836_HSXPA_1/U10836_HSXPA_NbEvt • xCEM= 42000 kbps & eCEM = 61200 kbps

• SW HSDPA throughput Capa: HsdpaThroughputLicense_ThgptCpty009_B_HSDPA_xCEM = U10836_HSXPA_2/U10836_HSXPA_NbEvt • 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 = U10836_HSXPA_3/U10836_HSXPA_NbEvt 70 COPYRIGHT © 2011 ALCATEL-LUCENT. ALL which RIGHTS RESERVED. Note: Scr_5 & Scr_6 are in fact the nb of TTI periods (2ms for HSDPA) during the scheduler restricted the throughput because the license or — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION HW throughput limitALCATEL-LUCENT was reached.

HSDPA throughput load (3/4) Avg + 3*σ ~ 99% of samp

• 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 : MaxUsed is not « a real max » tbc – see comments for HSDPA user • 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 • Based on CumSquareUsed = (cum used)² = U10836_HSXPA_8 +2^32 * U10836_HSXPA_9 with 2^32=exp(32ln(2)) • Note : cumSquareUsed" could sometimes be > 2exp32 (whereas screening is coded on 32 bit integers), therefore it’s "split" into 2 different screenings #8 and #9, that can both fit in a 32bit integer 2

σ

= std_dev =

2 CumUsed CumUsed −( ) NbEvtActive NbEvtActive

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 of max_used (and very seldom) that should not 71 COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. be countedALCATEL-LUCENT (not to— CONFIDENTIAL penalize the customer) — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

HSDPA throughput load (4/4) • 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) • • = 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 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

HSDPA throughput failures • HSDPA throughput allocation failures (at Iub level) U10836_HSDPA_1 U10836_HSDPA_2 U10836_HSDPA_3 U10836_HSDPA_4 U10836_HSDPA_5 U10836_HSDPA_6 U10836_HSDPA_NbEvt U10836_HSDPA_7 U10836_HSDPA_8 U10836_HSDPA_9 U10836_HSDPA_10

VS_HsdpaThroughputCapacity_HSDPA_CumHWcapacity VS_HsdpaThroughputCapacity_HSDPA_CumLicensing VS_HsdpaThroughputCapacity_HSDPA_CumUsed VS_HsdpaThroughputCapacity_HSDPA_AllocSuccess VS_HsdpaThroughputCapacity_HSDPA_AllocLicensingRefusal VS_HsdpaThroughputCapacity_HSDPA_AllocHWfail VS_HsdpaThroughputCapacity_HSDPA_NbEvt VS_HsdpaThroughputCapacity_HSDPA_NbEvtActive VS_HsdpaThroughputCapacity_HSDPA_CumSqUsedLow64 VS_HsdpaThroughputCapacity_HSDPA_CumSqUsedHigh64 VS_HsdpaThroughputCapacity_HSDPA_MaxUsed

U10836_HSXPA_1 U10836_HSXPA_2 U10836_HSXPA_3 U10836_HSXPA_4 U10836_HSXPA_5 U10836_HSXPA_6 _ _ U10836_HSXPA_7 U10836_HSXPA_8 U10836_HSXPA_9 U10836_HSXPA_10

VS_HsdpaThroughputCapacity_HSXPA_CumHWcapacity VS_HsdpaThroughputCapacity_HSXPA_CumLicensing VS_HsdpaThroughputCapacity_HSXPA_CumUsed VS_HsdpaThroughputCapacity_HSXPA_AllocSuccess VS_HsdpaThroughputCapacity_HSXPA_AllocLicensingRefusal VS_HsdpaThroughputCapacity_HSXPA_AllocHWfail _ _ _ VS_HSXPAThroughputCapacity_HSXPA_NbEvtActive VS_HSXPAThroughputCapacity_HSXPA_CumSqUsedLow64 VS_HSXPAThroughputCapacity_HSXPA_CumSqUsedHigh64 VS_HSXPAThroughputCapacity_HSXPA_MaxUsed

NodeB with iCEM


NodeB with x/eCEM

New in UA8

• Indicators for x/eCEM (also exist for iCEM): • % 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 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

Agenda



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


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 of UEs increases

>

cell throughput drops when number

• 2ms from retainability (call drop) in bad RFimpact conditions. This can impact PS calls suffer retainability, but also CS+PS, thenissues indirectly it can the CS retainability.

• 10 ms TTI offers higher cell throughput in a loaded network • Please See [R11] for more details 76 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

Reminder on EDCH users capacity (2/7)

• 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] [eCEM] m10ms m10ms + + 1*n2ms 1*n2ms ≤ > 128 128 2msEDCH to UL DCH

 

CAC EDCH not call Available ” and fallback CAC OK fails,, establish “UL radio2ms resources

• 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)


Reminder on EDCH users capacity (3/7)

• (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 processing resources” , fallback 2msEDCH to 10msEDCH



CAC fails, “Not enough user plane

• [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 perform enhanced EDCH CAC. If CAC fails, “UL radio resources not Available ”



CAC OK,

• Alternative RNC EDCH CAC (feature 34441.1) - not preferred one •

arame ere c ax sers er e = xmax r rgc c eac rgc handle 18 EDCH calls, hence the choice for edchMaxUsersPerCell)

c perce can

• Parameter edchMaxLegs2msPerCell controls the RNC’s 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 COPYRIGHT to reconfigure firstALLinto HSDPA (and then into DCH in case of HSDP © 2011 ALCATEL-LUCENT. RIGHTS RESERVED. ALCATEL-LUCENT — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION CAC failure

Reminder on EDCH users capacity (4/7) • Reminder on EDCH RLS and EDCH RL

Non serving EDCH RL

Primary cell = EDCH serving cell

Non serving EDCH RL

Serving EDCH RL

EDCH Non Serving RLSet

EDCH Serving RLSet

• -

=

• 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 what ever 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. 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

Reminder on EDCH users capacity (5/7) • 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 Counteda s 1 user RLS = 1 serving RL + 1 non serving RL  on same xCEM

Counteda s 1 user

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 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

Reminder on EDCH users capacity (6/7) • xCEM or eCEM supports up to “128 EDCH users” • 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 TB’s 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 •+

“

”

_

• 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 =128–G-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 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

Reminder on EDCH users capacity (7/7) • xCEM or eCEM supports up to “128 EDCH users” • 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


Serving EDCH RL Multi RAB : N PS EDCH + SRB over DCH

Counted as1 user

Counted as 1 user


Serving EDCH RL Multi RAB : N PS EDCH + SRB over EDCH


EDCH users monitoring decision tree At iub level: Avg % of EDCH connections load >70%)? yes High average EDCH UE load (EDCH UE near to resource exhaustion)

no

Check max nb of 2 ms vs 10 ms TTI EDCH users per board

Check burstiness: max EDCH UE connection load yes

In case of proactive monitoring: add directly EDCH UE resources

At iub level: max % of EDCH connections load > 90% no

EDCH users CAC failure check Check EDCH Users failure rate ?

green

Red < 98% - 98% ≤ Yellow < 100% - green = 100%

EDCH 2ms users CAC failure check

EDCH Users failures

Check EDCH 2ms Users failure ? U38_11 > 0 ? yes

red or yellow Case no capa licensing

Case capa licensing (finite value EdchNumberUserCapacityLicensing)

HW fail : upgrade iCEM to x/eCEM or add x/eCEM. If not enough, d4U, NodeB densification. SW fail : increase EdchMaxNumberUserxCEM up to 128. If not enough see Hw

EDCH use

Increase EDCH UE license (E1 token – step=8 users):  edchNumberUserCapacityLi censing If not enough, see Hw fail

Some EDCH 2ms UE CAC failure

EDCH UE resource OK

no Is fall back to 10ms successful ? no Fallbackto 10ms success rate >98% ?

yes

“More edch2ms capa needed” Compromise : add credit or “see Hw 83 fail” COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

“More edch 2ms+10ms capa needed”: See Hw fail

ALCATEL-LUCENT — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

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)


EDCH users load (2/10) • Max % of EDCH connection used> 90% (at Iub level, only available for x/eCEM) • Max % of EDCH connections = •

[MaxUsedtemporal aggreg=Max]/ [min(CumLicensing, CumHWcapacity)/NbEvt]

•

= _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 •

•

at HSXPA level (upper aggregation rule may not work)

Alternative: replace Min(Avg+3*Std_deviation,maxUsed) by Avg+3*Std_deviation 85 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

EDCH users load (3/10) • EDCH Users (at Iub level) : U10909_EDCH_1 U10909_EDCH_2 U10909_EDCH_3 U10909_EDCH_4 U10909_EDCH_5 U10909_EDCH_6 U10909_EDCH_NbEvt U10909_EDCH_7 U10909_EDCH_8 U10909_EDCH_9 U10909_EDCH_10

VS_eDCHUsersCapacity_EDCH_CumHWcapacity VS_eDCHUsersCapacity_EDCH_CumLicensing VS_eDCHUsersCapacity_EDCH_CumUsed VS_eDCHUsersCapacity_EDCH_AllocSuccess VS_eDCHUsersCapacity_EDCH_AllocLicensingRefusal VS_eDCHUsersCapacity_EDCH_AllocHWfail VS_eDCHUsersCapacity_EDCH_NbEvt VS_eDCHUsersCapacity_EDCH_NbEvtActive VS_eDCHUsersCapacity_EDCH_CumSqUsedLow64 VS_eDCHUsersCapacity_EDCH_CumSqUsedHigh64 VS_eDCHUsersCapacity_EDCH_MaxUsed


VS_eDCHUsersCapacity_HSXPA_CumHWcapacity VS_eDCHUsersCapacity_HSXPA_CumLicensing VS_eDCHUsersCapacity_HSXPA_CumUsed VS_eDCHUsersCapacity_HSXPA_AllocSuccess VS_eDCHUsersCapacity_HSXPA_AllocLicensingRefusal VS_eDCHUsersCapacity_HSXPA_AllocHWfail VS_eDCHUsersCapacity_HSXPA_NbEvt _ _ _ VS_HSXPAUsersCapacity_HSXPA_CumSqUsedLow64 VS_HSXPAUsersCapacity_HSXPA_CumSqUsedHigh64 VS_HSXPAUsersCapacity_HSXPA_MaxUsed

NodeB with iCEM


NodeB with x/eCEM

New in UA8

• Indicators for x/eCEM (also exist for iCEM): • HW capa in EDCH users on x/eCEM: HsupaUsersMaxHW_UsersCpty006_B_HSUPA_xCEM = U10909_HSXPA_1/U10909_HSXPA_NbEvt • SW capa in EDCH users on x/eCEM: HsupaUsersLicense_UsersCpty002_B_HSUPA_xCEM = U10909_HSXPA_2/U10909_HSXPA_NbEvt • 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 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

EDCH users load (4/10) • 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, it’s difficult to deduce Max EDCH users per CEM. • # of EDCH users standard deviation (during active events): • Based on CumS uareUsed = 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 it’s "split" into 2 different screenings #8 and #9, that can both fit in a 32bit integer. Avg + 3*σ ~ 99% of sa • Std_dev = HsupaUsersCapacityStddeviation_UserCpt001sd_B_HSUPA_xCEM

σ

= std_dev =

2 CumUsed CumUsed NbEvtActiv e − ( NbEvtActiv e )

2


• 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. ALCATEL-LUCENT — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

EDCH users load (5/10) • 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 don’t have necessarily 1 LCG = 1xCEM but it’s 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

in the past • U52_12_Max (VS_RadioLinkEstablishedPerCell_PsHSPAwithoutFdpch_Max) issues (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. It’s a number)


EDCH users load (6/10) • Nb of 2ms & 10ms EDCH ACTIVE users (at cell level, only for serving cell) • Active user= user who has received a grant and is curren tly transmitting an eDPDCH part • Not a good indicator for CEM capa: • indeed, U10905 does not reflect inacti ve eDCH (macrodiversity)  we may observe edch users limi (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 sl • 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 is reached at the same moment.


EDCH users load (7/10) • 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 can’t 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


EDCH users load (8/10) • 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_xxxxare & _EDCH_2MS_USERS_MAX_xxxx «stored» indicators. They give value after their installation (no backward value). Aggregation (temporal or spatial) possible _ _xxxx, are « calculated » indicator. But no aggregation (neither temporal nor spatial) possible


EDCH users load (9/10) • 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)


EDCH users load (10/10) • Counters impact

Counteda s 1 user

A

Counteda s 1 user


B

Serving EDCH RL

Color legend: RNC counter – NodeB counter At Iub level NodeB_A: VS_RadioLinkEstablishedPerCell_PsHSPAwithoutFdpch_Max= U52_12_Max= 2 « VS_eDCHUsersCapacity_HSXPA_MaxUsed » = 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

2ms call (single or multi RAB)

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 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

EDCH u sers failure (1/8) • EDCH users (at Iub level) U10909_EDCH_1 U10909_EDCH_2 U10909_EDCH_3 U10909_EDCH_4 U10909_EDCH_5 U10909_EDCH_6 U10909_EDCH_NbEvt U10909_EDCH_7 U10909_EDCH_8 U10909_EDCH_9 U10909_EDCH_10

VS_eDCHUsersCapacity_EDCH_CumHWcapacity VS_eDCHUsersCapacity_EDCH_CumLicensing VS_eDCHUsersCapacity_EDCH_CumUsed VS_eDCHUsersCapacity_EDCH_AllocSuccess VS_eDCHUsersCapacity_EDCH_AllocLicensingRefusal VS_eDCHUsersCapacity_EDCH_AllocHWfail VS_eDCHUsersCapacity_EDCH_NbEvt VS_eDCHUsersCapacity_EDCH_NbEvtActive VS_eDCHUsersCapacity_EDCH_CumSqUsedLow64 VS_eDCHUsersCapacity_EDCH_CumSqUsedHigh64 VS_eDCHUsersCapacity_EDCH_MaxUsed


VS_eDCHUsersCapacity_HSXPA_CumHWcapacity VS_eDCHUsersCapacity_HSXPA_CumLicensing VS_eDCHUsersCapacity_HSXPA_CumUsed VS_eDCHUsersCapacity_HSXPA_AllocSuccess VS_eDCHUsersCapacity_HSXPA_AllocLicensingRefusal VS_eDCHUsersCapacity_HSXPA_AllocHWfail VS_eDCHUsersCapacity_HSXPA_NbEvt _ _ _ VS_HSXPAUsersCapacity_HSXPA_CumSqUsedLow64 VS_HSXPAUsersCapacity_HSXPA_CumSqUsedHigh64 VS_HSXPAUsersCapacity_HSXPA_MaxUsed

NodeB with iCEM


NodeB with x/eCEM

ew n UA8

• Indicators for x/eCEM (also exist for iCEM): • % 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 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

EDCH u sers failure (2/8) • VS_eDCHUsersCapacity_HSXPA_AllocHWfail (U10909_HSXPA_6) • (impacts also: HsupaUsersAllocFail_HW_UsersCpty005_B_HSUPA_xCEM & HsupaUsersAllocSuccess_UsersCpty003_B_HSUPA_xCEM) • Behaviour’s 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) –

“

”

•

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


EDCH u sers failure (3/8) • VS_eDCHUsersCapacity_HSXPA_AllocHWfail (U10909_HSXPA_6) • 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)

, 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)


EDCH u sers failure (4/8) • 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 lev • 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) •


EDCH u sers failure (5/8) • Enhanced EDCH NodeB CAC failures leading to fallbacks HSDPA/2msEDCH U2897

U2895

U1601_1

U1603_1

U1601_2

HSDPA/10msEDCH U1603_1

U1603_1 U1601_1 U1603_1

HSDPA/DCH U1603_0

U1601_2

U1601_0

DCH/DCH


EDCH u sers failure (6/8) • 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)

• Enhanced EDCH NodeB CAC failures leading to fallbacks • 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)

•

VS_eDCHUsersCapacity_HSXPA_AllocHWfail (U10909_HSXPA_6)

• 2ms only CAC failure will peg counters “not enough User Plane Processing Resources” U38_11 U41_11 U39_9 U40_10 •

VS_RadioLinkSetupUnsuccess_NotEnoughUserPlaneProcessingResources VS_RadioLinkFirstSetupFailure_NotEnoughUserPlaneProcessingResources VS_RadioLinkAdditionUnsuccess_NotEnoughUserPlaneProcessingResources VS_RadioLinkReconfigurationPrepareUnsuccess_NotEnoughUserPlaneProcessingResources Note: this screening is also used by feature 82602/R3 when (configurable) limit of decoding ressou is reached (but this is not a matter of number of users) 99 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

EDCH u sers failure (7/8) • EDCH RNC CAC failure (at cell level) • See [R11] for more details • Limit of x EDCH UE per cell is reached (parameter :

)

U1090_0 U1090_1 VS_HsupaCACUnsuccess_NumHsupaPSIbStrUsers VS_HsupaCACUnsuccess_NumHsupaConvUsers • Limit of y EDCH legs per cell is reached

• 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 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

EDCH users failure (8/8) • 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) • Proposed criteria (tbc): • •

U10321_0_NbEvt VS_CEMCongestionEdch2mstti_NbEvt U10321_1_Cum VS_CEMCongestionEdch2mstti_Cum

Congestion duration (U10321_1_cum): green=0 s, 0 s
mes conges on occur

_ _

v : : green = ,

ye ow

; re


EDCH throughput monitoring decision tree EDCH throughput load

no

At iub level: max % of EDCH throughput load > 95% yes In case of proactive monitoring: add directly EDCH throughput resources

Check EDCH throughput failure rate ? % of EDCH throughput allocation success rate < 100% Red < 90% - 90% ≤ Yellow < 98% - green = 100% Red or yellow Case no capa licensing

Case capa licensing (finite value hsdpaThroughputCapacityLicensing)

HW fail : upgrade iCEM to x/eCEM or add x/eCEM. If not enough, D4U, NodeB densification. SW fail : increase EdchMaxThroughputXcem or EdchMaxThroughputEcem up to max value. If not enough, upgrade iCEM to x/eCEM or add x/eCEM If not enough, d4U, NodeB densification

Green

EDCH throughput failures

100% = No EDCH throughput failure rate

Increase EDCH throughput license (H2 token – step is 480 kbps) :  EdchThroughputCapacityLicensing If not enough, upgrade iCEM to x/eCEM or add x/eCEM If not enough, d4U, odeB densification


EDCH throughput resource OK

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) • •

[MaxUsedtemporal aggreg=Max]/ [min(CumLicensing, CumHWcapacity)/NbEvt] = _ 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 u defined indicator (with proper aggregation rule) to import to NPO (in xml) – for more information, pleas see (R10] • Note : MaxUsed is not « a real max » (tbc) – see comments for HSDPA user •

• 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 • at HSXPA level (upper aggregation rule may not work) • Alternative: replace Min(Avg+3*Std_deviation,maxUsed) by Avg+3*Std_deviation •


EDCH throughput load (2/4) • EDCH throughput (at Iub level) : U10910_EDCH_1 U10910_EDCH_2 U10910_EDCH_3 U10910_EDCH_4 U10910_EDCH_5 U10910_EDCH_6 U10910_EDCH_NbEvt U10910_EDCH_7 U10910_EDCH_8 U10910_EDCH_9 U10910_EDCH_10

VS_eDCHThroughputCapacity_EDCH_CumHWcapacity VS_eDCHThroughputCapacity_EDCH_CumLicensing VS_eDCHThroughputCapacity_EDCH_CumUsed VS_eDCHThroughputCapacity_EDCH_AllocSuccess VS_eDCHThroughputCapacity_EDCH_AllocLicensingRefusal VS_eDCHThroughputCapacity_EDCH_AllocHWfail VS_eDCHThroughputCapacity_EDCH_NbEvt VS_eDCHThroughputCapacity_EDCH_NbEvtActive VS_eDCHThroughputCapacity_EDCH_CumSqUsedLow64 VS_eDCHThroughputCapacity_EDCH_CumSqUsedHigh64 VS_eDCHThroughputCapacity_eDCH_MaxUsed

U10910_HSXPA_1

VS_eDCHThroughputCapacity_HSXPA_CumHWcapacity

U10910_HSXPA_2 U10910_HSXPA_3 U10910_HSXPA_4 U10910_HSXPA_5 U10910_HSXPA_6 U10910_HSXPA_NbEvt U10910_HSXPA_7 U10910_HSXPA_8 _ _ U10910_HSXPA_10

VS_eDCHThroughputCapacity_HSXPA_CumLicensing VS_eDCHThroughputCapacity_HSXPA_CumUsed VS_eDCHThroughputCapacity_HSXPA_AllocSuccess VS_eDCHThroughputCapacity_HSXPA_AllocLicensingRefusal VS_eDCHThroughputCapacity_HSXPA_AllocHWfail VS_eDCHThroughputCapacity_HSXPA_NbEvt VS_eDCHThroughputCapacity_HSXPA_NbEvtActive VS_eDCHThroughputCapacity_HSXPA_CumSqUsedLow64 _ _ _ VS_eDCHThroughputCapacity_HSXPA_MaxUsed

NodeB with iCEM


NodeB with x/eCEM

New in

• Indicators for x/eCEM (also exist for iCEM): • HW EDCH throughput capa: HsupaThroughputMaxHW_ThgptCpty010_B_HSUPA_xCEM = U10910_HSXPA_1/U10910_HSXPA_NbEvt • xCEM : 10 080 kbps UL (MAC-e level) whereas eCEM: 33120 kbps

• SW EDCH throughput Capa: HsupaThroughputLicense_ThgptCpty009_B_HSUPA_xCEM =

U10910_HSXPA_2/U10910_HSXPA_NbEvt •

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 = U10910_HSXPA_3/U10910_HSXPA_NbEvt 104


EDCH throughput load (3/4) Avg + 3*σ ~ 99% of samp

• 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 • Based on CumSquareUsed = (cum used)² = U10910_HSXPA_8 +2^32 * U10910_HSXPA_9 with 2^32=exp(32ln(2)) • Note : cumSquareUsed" be > 2exp32 (whereas is coded integers), therefore it’s could "split"sometimes into 2 different screenings #8 andscreening #9, that can both on fit 32 in abit 32bit integer 2 2 σ

= std_dev =

CumUsed CumUsed −( ) NbEvtActive NbEvtActive

finite population with equal probabilities at all points)

• Indicator for monitoring = Min (max_used , 3*σ + average_active) : HsupaThroughputCptyIndicator_ThgtCpt002in_B_HSUPA_xCEM 105 • is a “real max” as it excludes some very high value of max_used (and very seldom) that should not COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. be countedALCATEL-LUCENT (not to— CONFIDENTIAL penalize the — SOLELY FOR customer) AUTHORIZED PERSONS HAVING A NEED TO KNOW — PROPRIETARY — USE PURSUANT TO COMPANY INSTRUCTION

EDCH throughput load (4/4) • Other counters • Maximum instantaneous throughput per cell (including retransmission) - baseline UHSUPA034_CR_Max

E_DCHMAC_eCellThroughput_Max_HSUPA034_CR

U10904_Avg VS_eDCHdataBitRec_Avg U10904_Cum VS_eDCHdataBitRec_Cum U10904_Max VS_eDCHdataBitRec_Max U10904_Min VS_eDCHdataBitRec_Min U10904_NbEvt VS_eDCHdataBitRec_NbEvt

•

UHSUPA034_CR_Max = 500*VS_eDCHdataBitRec_Max

•

Based on U10904_Max (includes retransmission)

•

Note: at Iub level, aggregation may be overestimated (max of max at cells, is not necessarily 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 pe user (Kbps)

•

They give slightly different values 106 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

EDCH throughput failures (1/2) • EDCH throughput allocation failures (at Iub level) U10910_EDCH_1 U10910_EDCH_2 U10910_EDCH_3 U10910_EDCH_4 U10910_EDCH_5 U10910_EDCH_6 U10910_EDCH_NbEvt U10910_EDCH_7 U10910_EDCH_8 U10910_EDCH_9 U10910_EDCH_10 U10910_HSXPA_1 U10910_HSXPA_2 U10910_HSXPA_3 U10910_HSXPA_4 U10910_HSXPA_5 U10910_HSXPA_6 U10910_HSXPA_NbEvt U10910_HSXPA_7 U10910_HSXPA_8 U10910_HSXPA_9 U10910_HSXPA_10

VS_eDCHThroughputCapacity_EDCH_CumHWcapacity VS_eDCHThroughputCapacity_EDCH_CumLicensing VS_eDCHThroughputCapacity_EDCH_CumUsed VS_eDCHThroughputCapacity_EDCH_AllocSuccess VS_eDCHThroughputCapacity_EDCH_AllocLicensingRefusal VS_eDCHThroughputCapacity_EDCH_AllocHWfail VS_eDCHThroughputCapacity_EDCH_NbEvt VS_eDCHThroughputCapacity_EDCH_NbEvtActive VS_eDCHThroughputCapacity_EDCH_CumSqUsedLow64 VS_eDCHThroughputCapacity_EDCH_CumSqUsedHigh64 VS_eDCHThroughputCapacity_eDCH_MaxUsed VS_eDCHThroughputCapacity_HSXPA_CumHWcapacity VS_eDCHThroughputCapacity_HSXPA_CumLicensing VS_eDCHThroughputCapacity_HSXPA_CumUsed VS_eDCHThroughputCapacity_HSXPA_AllocSuccess VS_eDCHThroughputCapacity_HSXPA_AllocLicensingRefusal VS_eDCHThroughputCapacity_HSXPA_AllocHWfail VS_eDCHThroughputCapacity_HSXPA_NbEvt VS_eDCHThroughputCapacity_HSXPA_NbEvtActive VS_eDCHThroughputCapacity_HSXPA_CumSqUsedLow64 VS_eDCHThroughputCapacity_HSXPA_CumSqUsedHigh64 VS_eDCHThroughputCapacity_HSXPA_MaxUsed

NodeB with iCEM


NodeB with x/eCEM

New in UA8

• Indicators for x/eCEM (also exist for iCEM): • % 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 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

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.



Nb Event – NbActiveEvent not working ? • Different behaviours… • NodeB with 1 eCEM-u:

• NodeB with 1eCEM:


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 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

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 doesn’t reach the licence (eg for

On the field, we see refusa ls whereas the maxUs ed doesn’t reach the licence (licence is 48 on that site – 7 refusals for a MaxUsed being 46 at 00:00):


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., ).


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.

•

“

”

• “MBBU_preferred” is hard coded: xCEM is preferred over iCEM  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)) considered equally



iCEM and xCEM are

• 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 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

BBU R99 Load Balancing Algorithm • 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”

CAS 1E

Call

CAS 2E

Call

50% load

50% load

xCEM

iCEM128

Check pseudo CAC r99MaxNumberCeXcem (see next slide)

xCEM

iCEM128

Check pseudo CAC r99MaxNumberCeXcem (see next slide) 115


BBU R99 Load Balancing Algorithm • Case 1 : xCEM load is below 50% CASE 1a

pseudo CAC fails

50% load r99MaxNumber CeXcem

50% load r99MaxNumber CeXcem

xCEM

CASE 1b

Call will be (tried to be) establis on iCEM128

Call

iCEM128

xCEM

Call

Call will be established on xCEM

r99MaxNumber

pseudo CAC

CeXcem 50% load

OK

xCEM

iCEM128

iCEM128

r99MaxNumber CeXcem

50% load

116

xCEM

iCEM128


BBU R99 Load Balancing Algorithm • Case 2 : xCEM load is above 50% CASE 2a

Call will be (tried to be) establishe on iCEM128

Call pseudo CAC fails

r99MaxNumber CeXcem

r99MaxNumber CeXcem 50% load

50% load

xCEM

xCEM

iCEM128

iCEM128

Call

CASE 2b r99MaxNumber CeXcem 50% load

xCEM

Call is balanc pseudo CAC

r99MaxNumber

OK

CeXcem 50% load

iCEM128

117

xCEM


iCEM128

BBU R99 Load Balancing Algorithm • AR1-4115585/DCTPD00809552 load balancing in UA81 • Fixed in UA813 EP4, with a propagation of DCTPD00359725 • R99 call set up schematic (srb placed on xcem): SRB RL Set Up Request Case 1b or Case 2b Enough R99 CE resource on xCEM (pseudo cac

CASE 1b Without CR359725

CASE 2b

SRB ok SRB+TRB reconf fails

E C x

8 2 1 M E C i



SRB on xCEM RL reconfiguration (SRB



SRB+TRB)

on r99MaxNumberCeXcem fails) Without CR359725: RL reconf fails on xCEM « ul radio resources not available » VS_R99CECapacity_AllocLicensingRefusal(U10317_5)

SRB

M E C x

8 2 1 M E iC

SRB+TRB reconf OK

With CR359725, CAC on RL Reconf removed: Even if pseudo cac resources on r99MaxNumberCeXcem If enough total R99 on iCEM + xCEM fails, (CAC on r99MaxNumberCeXcem+64*#D-BBU succeeds)  RL Reconf OK  R99 call is spread out over iCEM

With CR359725 118 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

BBU R99 Load Balancing Algorithm • AR1-4115585/DCTPD00809552 load balancing in UA81 • Fixed in UA813 EP4, with a propagation of DCTPD00359725 • R99 call set up schematic (srb placed on icem): SRB RL Set Up Request Case 2b (xCEM load is above 50%) Enough R99 CE resource on xCEM (pseudo cac

CASE 2b SRB+TRB reconf fails

M E C x



SRB ok

SRB on iCEM (load balancing) RL reconfiguration (SRB  SRB+TRB)

8 2 1

Not enou h R99 CE resource on iCEM to acce t T Without CR359725: RL reconf fails on iCEM VS_R99CECapacity_AllocHWfail(U10317_6)

E C i

Without CR359725

SRB ok

SRB+TRB reconf OK

M E C x

8 2 1 M E iC

With CR359725, CAC on RL Reconf removed: Even if not enough resources on iCEM If enough total R99 resources on iCEM + xCEM (CAC on r99MaxNumberCeXcem+64*#D-BBU succeeds)  RL Reconf OK  R99 call is spread out over xCEM (?)

With CR359725 119 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

BBU R99 Load Balancing Algorithm • AR1-4115585/DCTPD00809552 load balancing in UA81 • Fixed in UA813 EP4, with a propagation of DCTPD00359725 • HSXPA (2ms EDCH) call set up schematic (srb placed on icem): SRB RL Set Up Request TRB EDCH2ms fails Fallback to 10ms fails Fallback to UL DCH fails

SRB ok

CASE 2b

Case 2b (xCEM load is above 50%) Enough R99 CE resource on xCEM (pseudo cac 

SRB on iCEM (load balancing) RL reconfiguration (SRB  SRB+TRB HSxPA) M E x

8 2 1 M E C i

Without CR359725

TRB EDCH2ms fails Fallback to 10ms fails Fallback to HSDPA-UL DCH ok

SRB ok

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 iCE Not enough R99 CE resources on xCEM (pseudo CAC nok) Without CR359725: Fall back to R99 RL reconf fails on xCEM « ul radio resources not available » ?  VS_R99CECapacity_AllocLicensingRefusal(U10317_5)?

With CR359725, CAC on RL Reconf removed: Even if not enough resources on xCEM for UL DCH M E If enough total R99 resources on iCEM + xCEM TRB OK C x (CAC on r99MaxNumberCeXcem+64*#D-BBU succeeds)  RL Reconf OK With CR359725  R99 call is tried over iCEM (?) but iCEM does not 120 support HSDPA part  call fails on xCEM or iCEM (?) COPYRIGHT © 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. ALCATEL-LUCENT — CONFIDENTIAL — SOLELY FOR AUTHORIZED PERSONS HAVING A NEED TO CEM KNOW — PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION which holds— the failure? 8 2 1 M E C i

xCEM hardware • A view of xCEM architecture


xCEM Hardware

Source : iBTS KPI UA9 https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=60227404

• 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 • • •

•

•

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 •

•

6 R99 cells (up to 256 users)

Major bottleneck in the xCEM

Onechip 0..3: 4 Onechip ASICs each is handling R99 L1 processing for 64 users


Other

Source : KTS UA813 UTRAN Upgrade Bulletin, Capacity and Feature Licensing V01.03 November 2012 https://wcdma-ll.app.alcatel-lucent.com/livelink/livelink.exe?func=ll&objId=65730678

• 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, ) =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 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

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 add’l 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: nb of call migrations on a RL reconfiguration with HSPA addition

•

U10320: nb of call migrations on a RL reconf with a serving cell change

•

•

Purpose : •

assess avg nb of add’l DCH required for Call migration

•

track contribution of the Call migration to the overall nb of RL Reconf failure.

Proposed metrics (available at cell level, but to be taken at Iub level)

•

•

% 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 •

A = 1−

U 10319 _ 0

i =0

U10320_0 U10320_1 U10320_2 U10320_3 U10320_4

VS_dchMigrationHspaAddition_NotReq VS_dchMigrationHspaAddition_Succ VS_dchMigrationHspaAddition_FailAlloc VS_dchMigrationHspaAddition_FailTargetDch VS_dchMigrationHspaAddition_FailOther

VS_dchMigrationServingCellChange_NotReq VS_dchMigrationServingCellChange_Succ VS_dchMigrationServingCellChange_FailAlloc VS_dchMigrationServingCellChange_FailTargetDch VS_dchMigrationServingCellChange_FailOther

Based on # of RL reconf failures = RadioLinkReconfigurationPrepareUnsuccess_RL012_CR(URL012_CR)(Event)

4

∑

U10319_0 U10319_1 U10319_2 U10319_3 U10319_4

U 10319 _ i

B = 1−

U 10320 _ 0 C = 1−

4

∑ i =0

U 10320 _ i

4

U 10319 _ 0 + U 10320 _ 0 D=

4

∑

(U 10319 _ i + U 10320 _ i)

∑ i =2

4 U 10319 _ i +

∑

U 10320 _ i

i =2

i =0 125


E =

D URL 012 _ CR

CEM Capacity Monitoring Guide UA8.1 Internal Standard

Recommend Documents