You are on page 1of 36

L114538 – Enhanced Load Balancing Criteria

LR13.3 ORF Workshop

Gianina TATAR - Network Engineering & Assurance/ Wireless Features


October 8th 2013
STANDARD CONTENTS

1 | FEATURE DESCRIPTION

2 | UPGRADE RULES

3 | FEATURE ACTIVATION STRATEGY

4 | PERFORMANCE EVALUATION

5 | CONCLUSION
1
Feature Overview
Feature Overview 1/2

• Prior to LR13.1, load balancing is triggered by Callp based on UL/DL PRB


consumption per cell. The PRB consumption used to trigger load
balancing is the same as the one used for admission control, based on a
calculated average PRB/s cost of 1kbps over the air, as well as GBR and
MIM parameter minBitRateForBE (for non-GBR bearers). This is referred
to as “semi-static” PRB consumption.
• In addition to the current load balancing implementation, LR13.1 feature
L114538 adds the following new enhancements for load balancing /
preventive offload:
 Load equalization triggering;
 Allowing inter-frequency preventive offloading without neighbor
load information, controlled via activation flag.

4
Offloading mechanism in LR13.1
• Step 1: Load equalization threshold is reached:
 Compare the load of the target with the load of the serving  decide
to invoke or not offloading;
 Select the UEs to offload;
 Trigger load equalization offloading.
• Step 2: Preventive offload threshold is reached:
 Compare the load of the target with the load of the serving (note that
the delta for preventive is in the code)  decide to invoke or not
offloading;
 Select the UEs to offload;
 Trigger preventive offloading.
The main difference between load equalization & preventive offloading:
 starting earlier for load equalization
 customer can decide to monitor only certain carriers for load equalization

5
Feature Benefit
• The enhanced LoB feature brings the following benefits:
 Possibility to equalize load between two LTE carriers early when
there is a large load difference, resulting in better usage of spectrum
resources;
 Possibility to perform blind preventive offload, i.e. offloading
towards a cell for which no load information is available (e.g.
because there is no X2 link);
 Avoid the ping-pong effect between the two bands that can
appear when the load on both bands exceeds the threshold and the
UE is offloaded between bands - by introducing parameter
ThresholdRelativePreventiveOffload (now offloading based on load
equalization will only be triggered when the load delta between target and
serving cell is above this threshold);
 Filtering out neighbors with similar load – due to parameter
ThresholdRelativePreventiveOffload, cells with similar load as the
serving one will not be taken into account as a possible candidate for
offloading based on load equalization.

6
Feature Description
Load equalization
• Load equalization is an early form of preventive offload. The aim is to
provide consistent user QoS in different LTE carriers by correcting load
imbalances very early. The only criteria for triggering load equalization in
LR13.1 is semi-static PRB consumption. When this serving cell threshold
is met, Callp will ask UEs to measure cells on other LTE carriers.
• In order to avoid triggering load equalization too often, one condition is
that there is a sufficient gap in load between the cells on different
carriers. Upon receiving a UE measurement report for load equalization,
Callp will need to check that there is a sufficient delta between source
and target cell load. If a target cell does not satisfy this criterion, load
equalization will not be triggered towards this cell.
• UE selection for load equalization will be the same as for preventive
offload triggered by semi-static PRB usage, meaning the number of UEs
selected will be based on the PRB usage deficit compared with the load
equalization threshold. The eNB will stop offloading UEs to a cell when
the load between the two cells has reached equal levels in terms of semi-
static PRB usage.

7
Feature Description
Blind Preventive Offloading 1/2
• Up to LR13.1, preventive offloading can only be triggered towards a cell
which is considered not loaded, which implies prior knowledge of loading.
This is to avoid performing load balancing towards a cell that is itself
performing load balancing.
• As preventive offloading between eNBs will be performed and in some
cases there will be no X2 link (or no X2 load exchange)  the need to
allow inter-frequency preventive offload towards a neighbor cell for which
there is no load information available.
• Upon receiving a UE measurement report for preventive offload (IF A4
event) where there is no load information available for the best cell,
when performing target cell capacity filtering for preventive offloading,
the following behavior will apply:
 If eNB::spare15 bit0 = 1 (True), trigger handover towards the best cell;
 If eNB::spare15 bit0 = 0 (False), ignore the UE measurement report.
• If the load of the neighbor cell is known, the eNB behavior remains the
same and does not depend on the spare setting.

8
Feature Description
Blind Preventive Offloading 2/2
• Blind preventive offloading is introduced to cover the cases where X2
load exchange is not supported;
• Without allowing blind offloading, there wouldn’t be any offloading at all;
• There is a risk that the new cell is more congested than the serving one;
• This capability should be switched off by the customers for which X2 load
exchange is available.

9
Feature Description
• When receiving a UE A4 measurement report for preventive offload, the
eNB will compare the load of the target cell with the load of the serving
cell in order to ensure there is a minimum configurable delta between the
two cells (i.e. serving cell load needs to be higher than target cell by a
delta).
• For semi-static PRB per cell usage trigger, this is done by comparing
semi-static PRB usage between serving and target cell:
 Target cells (intra-eNB or inter-eNB) for which the semi-static PRB usage per
cell is within a pre-determined threshold of the serving cell’s PRB usage will
be filtered out;
 For existing preventive offload, this threshold will be hard-coded;
 For early preventive offload / load equalization, this threshold is
configurable (based on thresholdRelativePreventiveOffload);
 Intra-eNB target cells for which preventive offload is being triggered (based
on any of the possible criteria) are filtered out.
• If a neighbor cell’s load is unknown, then preventive offload may not
triggered, depending on eNB spare 15 bit0 setting.

10
Preventive Load Control 1/2

• Preventive Load Control


will be triggered if PRB
usage falls in the “yellow”
region.
<xx> PreventiveLoadControlThresholdOnStaticPrb • Radio CAC will select
Rejection or reactive
load control may
enough UEs to offload to
appear stay in the “green” region.

• Only after the request is admitted


• Preventive offload will not reject any request

<xx> PreventiveLoadControlThresholdOnStaticPrb – LoadEqualizationDeltaThreshold


 load equalization triggered

11
Preventive Load Control 2/2

• The eNB will take into account as many UEs required for PRB consumption to go
below the preventive offload threshold TH0 after offload is completed.

Example:

• TH0 = 70% 4 UEs will be selected for offloading


• current PRB consumption = 80% for current PRB consumption to get
• each UE has PRB consumption of 3% below 70%

• The only restriction is that the number of UEs selected must be less or equal to
maxNbrOfUsersImpactedByPreventiveLoadControl parameter.

12
UE Selection Logic 1/2

• UE must support inter-frequency handover and event A4.


• UE must support the carrier of at least one configured LTE neighbor.
• UE must have at least one established eRAB.

• UE’s aggregate priority ≥ arpThresholdForPreventiveLoadControl,


where aggregate priority is defined as the lowest ARP level amongst all of the
UE’s radio bearers.
• UE is not in an ongoing procedure, including release, handover, CCO and ANR
procedure.
• UE is not a CSFB call.
• UE is not in coverage alarm (i.e. no event A2 for Entering-Coverage-Alarm has
been received).

13
UE Selection Logic 2/2
For UEs with the same ARP priority level:
• UE supporting more configured LTE neighbor carriers is selected ahead of
one supporting less LTE neighbor carriers. However, if they also support an
equal number of neighbor carriers, then:
• UE with higher aggregate DL+UL PRB cost is selected ahead of one with
lower aggregate DL+UL PRB cost. However, if the UEs have the same
characteristics (same ARP, same number of neighbors, same agg cost), the UEs
will be sorted based on UE context ID.

14
Feature Dependencies or Interactions 1/2

• L115223 Inter-frequency Load Balancing (LA6.0): The enhancement of


allowing preventive offload towards neighbor cells with unknown load is applicable
to L115223 preventive offloading.

• L115644 Bearer Characteristics online modifications (LA5.0): Any change


to ARP shall be taken into account for future preventive offloading decisions.

• L155912 – Target cell load consideration for iRAT mobility to WCDMA


(LR13.1): New triggers introduced should also be used for load balancing to
UTRAN: real PRB consumption, average Qos degradation.

15
Feature Dependencies or Interactions 2/2

• L163172 – Traffic Management Evolution & L171232 – nGBR QoS based


Load balancing (LR13.3): 163172 Epic 1 is for preventive load balance and
therefore depends on L115223/L114538 capability to filter neighbor carriers based
on cell load information. Preventive offload (to LTE and/or WCDMA) must be
enabled in order for 163172 Epic 1 to be used.
When 163172 Epic 1 is activated, the per carrier preventive offload threshold
parameters are used instead of the parameters defined in L115223/L114538.
Existing parameters used for preventive load control that do not have per carrier
equivalents added by this feature (such as
maxNbrOfUsersImpactedByPreventiveLoadControl) shall apply to per carrier
preventive load control.
171232 is Former EPIC#1 of L114538.
If preventive offloading is enabled and 163172 Epic 1 is activated then the
thresholds defined in 163172 Epic 1 will be used for preventive offloading.
163172 Epic 9 (when activated) modifies existing load balancing and load
equalization to avoid offloading VoIP calls by selecting non-QCI1 bearers/UEs
before selecting QCI1 bearers/UEs.
16
2
Upgrade Rules
First Upgrade Using the Feature

• To ensure the same level of functionality and performance after the upgrade than
before (ISO-functionality, feature disabled), the following flags should be set:

isLoadEqualizationEnabled = FALSE
isFddTddRedirectionForPreventiveOffloadEnabled = FALSE
eNB::spare15 bit0 = FALSE

18
3
Feature Activation Strategy
Activation Strategy

• Feature activation flags:

isLoadEqualizationEnabled = TRUE
Introduced
isFddTddRedirectionForPreventiveOffloadEnabled = FALSE by L114538
(LR13.1)
eNB::spare15 bit0 = TRUE

isInterFreqLoadBalancingFeatureEnabled = TRUE Introduced by


L115223 (LA6)
isPreventiveLoadControlAllowed = TRUE

isStaticPrbBasedPreventiveLoadControlEnabled = TRUE

20
Activation Strategy
Parameter settings 1/2

Default Recommended
Parameter Object
Value Value
isLoadEqualizationEnabled LteNeighboringFreqConf False True

isFddTddRedirectionForPreventiveOffloadEnabled ActivationService False False

spare15 bit0 eNB False False

dlPreventiveLoadControlThresholdOnStaticPrb RadioCacCell 80% 15%


800
ulPreventiveLoadControlThresholdOnStaticPrb RadioCacCell 80% 20%

dlPreventiveLoadControlThresholdOnStaticPrb RadioCacCell 80% 80%


2.6
ulPreventiveLoadControlThresholdOnStaticPrb RadioCacCell 80% 80%

LoadEqualizationDeltaThreshold RadioCacCell 0% 5%

ThresholdRelativePreventiveOffload RadioCacEnb 20% 1%

* The parameters from this table are introduced in LR13.1 by feature L114538

21
Activation Strategy
Parameter settings 2/2

Default Recommended
Parameter Object
Value Value
isInterFreqLoadBalancingFeatureEnabled ActivationService False True

isPreventiveLoadControlAllowed ActivationService False True

dlCellLoadedThreshold Enb 15% 40%

ulCellLoadedThreshold Enb 15% 40%

preventiveLoadControlHysteresisTimer RadioCacEnb 3000 ms 3000 ms

tMeasWaitForOffload Enb 2000 ms 2000 ms

cellCapacityClass RadioCacCell 100% 100%

thresholdEutraRsrp (event A4) ReportConfigEUTRA -100 dBm -110 dBm

* The parameters from this table are introduced by feature L115223 (LA6)

22
Activation Strategy

Offloading example based on parameter settings

• dlPreventiveLoadControlThresholdOnStaticPrb = 15%
• LoadEqualizationDeltaThreshold = 5%
• ThresholdRelativePreventiveOffload = 1%

• Load equalization starts at (15-5)% = 10% serving cell load and the
source eNB will offload UEs as long as its loading is above 10%.
• Requires 1% delta between source and target eNBs.

• Preventive offload starts at 15% serving cell load.

23
4
Performance Evaluation
4. Performance Evaluation
• The KPIs to be measured are:
 HO interruption time (Cplane and Uplane)
 HO success rate
 Nb of RRC connection release/reject
 Nb of bearers release/reject
 Traffic per cell/carrier
 Throughput per cell/carrier (average and distribution)
 RRC Connections per cell/carrier
 RSRP distribution per cell
 PRB consumption per cell
 Connection setup failure rate
 Call drop rate
 Number of HOs

25
4. Performance Evaluation
• Counters 1/8 – Direct KPIs impacted:
Counter Name Counter Counter Description
ID
Evolved multi-carrier traffic allocation 12794 – 1 This counter provides the number of times eMCTA is triggered to off-load a call to
trigger solve eNodeB congestion. This screening is used when congestion is detected by
eNodeB reactive load control function.
Evolved multi-carrier traffic allocation 12794 -2 eMCTA is triggered by preventive load control to off-load a call based on
trigger semi-static PRB usage.
Off-loading success 12891 - 1 Off-loading was triggered by preventive load control based on semi-static
PRB usage.
Off-loading failure 12892 Off-loading was triggered by preventive load control.

Outgoing inter-eNodeB X2 handover 12893 X2 Handover was triggered for off-loading reason upon eNodeB reactive load
abort per handover reason control decision.
Outgoing inter-eNodeB X2 handover 12893 X2 Handover was triggered for off-loading reason upon eNodeB preventive load
abort per handover reason control decision.
Outgoing inter-eNodeB S1 handover 12890 S1 Handover was triggered for off-loading reason upon eNodeB reactive load
abort per handover reason control decision.
Outgoing inter-eNodeB S1 handover 12890 S1 Handover was triggered for off-loading reason upon eNodeB
abort per handover reason preventive load control decision.
Total intra-eNodeB handover failure 12704 This counter provides the number of times an intra-eNodeB handover procedure
towards the target cell has been failed.
Total outgoing inter-eNodeB X2 12708 This counter provides the number of times an outgoing inter-eNodeB X2 handover
handover failure procedure has been failed from the cell.
Total incoming inter-eNodeB X2 12712 This counter provides the number of times that an incoming inter-eNodeB X2
handover failure handover procedure has been failed to the cell.

26
4. Performance Evaluation
• Counters 2/8 – Direct KPIs impacted:

Counter Name Counter Counter Description


ID
Reported cells not selected 12701 This counter is triggered when a Measurement Report is received. This
report includes measId configured for mobility trigger. No cell can be
selected for mobility procedure.
CellLoaded is used when the neighbor cell is not selected for offloading
(reactive of preventive), either because it is considered loaded, or
because the load delta with the serving cell is not sufficient.
Evolved multi-carrier traffic allocation 12794 -3 eMCTA is triggered by preventive load control to off-load a call, when the
trigger preventive offload trigger is based on real PRB consumption and DL non-
GBR throughput.
Evolved multi-carrier traffic allocation 12794 -4 eMCTA is triggered by load equalization for a call.
trigger
Off-loading success 12891 - 2 Off-loading was triggered by preventive load control based on real PRB
usage and DL non-GBR throughput.
Off-loading success 12891 - 3 Off-loading was triggered by load equalization.

Off-loading failure 12892 - 1 Off-loading was triggered by preventive load control based on semi-static
PRB usage.
Off-loading failure 12892 - 3 Off-loading was triggered by load equalization.

Intra-LTE off-loading attempt per 12855 This counter provides the number of times reactive and preventive offloading
handover type outgoing handovers were attempted per handover type (IntraeNodeB
HO, X2 HO, S1 HO). This counter is pegged on the source cell.

27
4. Performance Evaluation
• Counters 3/8 – Direct KPIs impacted:

Counter Name Counter Counter Description


ID
Intra-LTE off-loading attempt per 12855 - 0 Intra-eNodeB inter-frequency handover triggered for reactive offload.
handover type
Intra-LTE off-loading attempt per 12855 - 1 X2 inter-frequency handover triggered for reactive offload.
handover type
Intra-LTE off-loading attempt per 12855 - 2 S1 inter-frequency handover triggered for reactive offload.
handover type
Intra-LTE off-loading attempt per 12855 - 3 Intra-eNodeB inter-frequency handover triggered for preventive offload (all
handover type possible triggers).
Intra-LTE off-loading attempt per 12855 - 4 X2 inter-frequency handover triggered for preventive offload.
handover type
Intra-LTE off-loading attempt per 12855 - 5 S1 inter-frequency handover triggered for preventive offload.
handover type
Intra-LTE off-loading attempt per 12855 - 6 Intra-eNodeB inter-frequency handover triggered for load equalization.
handover type
Intra-LTE off-loading attempt per 12855 - 7 X2 inter-frequency handover triggered for load equalization.
handover type
Intra-LTE off-loading attempt per 12855 - 8 S1 inter-frequency handover triggered for load equalization.
handover type
Intra-LTE off-loading success per 12856 This counter provides the number of times reactive and preventive offloading
handover type outgoing handovers were successful, per handover type (IntraeNodeB
HO, X2 HO, S1 HO). This counter is pegged on the source cell.

28
4. Performance Evaluation
• Counters 4/8 – Direct KPIs impacted:

Counter Name Counter Counter Description


ID
Intra-LTE off-loading success per 12856- 0 Intra-eNodeB inter-frequency handover successfully for reactive offload.
handover type
Intra-LTE off-loading success per 12856 - 1 X2 inter-frequency handover successfully completed for reactive offload.
handover type
Intra-LTE off-loading success per 12856- 2 S1 inter-frequency handover successfully completed for reactive offload.
handover type
Intra-LTE off-loading success per 12856 - 3 Intra-eNodeB inter-frequency handover successfully completed for preventive
handover type offload (all possible triggers).
Intra-LTE off-loading success per 12856 - 4 X2 inter-frequency handover successfully completed for preventive offload.
handover type
Intra-LTE off-loading success per 12856 - 5 S1 inter-frequency handover successfully completed for preventive offload.
handover type
Intra-LTE off-loading success per 12856 - 6 Intra-eNodeB inter-frequency handover successfully completed for load
handover type equalization.
Intra-LTE off-loading success per 12856 - 7 X2 inter-frequency handover successfully completed for load equalization.
handover type
Intra-LTE off-loading success per 12856 - 8 S1 inter-frequency handover successfully completed for load equalization.
handover type
Intra-LTE off-loading failure per 12857 This counter provides the number of times reactive and preventive offloading
handover type outgoing handovers failed, per handover type (Intra-eNodeB HO,
X2 HO, S1 HO). This counter is pegged on the source cell.

29
4. Performance Evaluation
• Counters 5/8 – Direct KPIs impacted:

Counter Name Counter Counter Description


ID
Intra-LTE off-loading failure per 12857- 0 Intra-eNodeB inter-frequency fails for reactive offload.
handover type
Intra-LTE off-loading failure per 12857- 1 X2 inter-frequency handover fails for reactive offload.
handover type
Intra-LTE off-loading failure per 12857- 2 S1 inter-frequency handover fails for reactive offload.
handover type
Intra-LTE off-loading failure per 12857 - 3 Intra-eNodeB inter-frequency handover fails for preventive offload (all possible
handover type triggers).
Intra-LTE off-loading failure per 12857 - 4 X2 inter-frequency handover fails for preventive offload.
handover type
Intra-LTE off-loading failure per 12857 - 5 S1 inter-frequency handover fails for preventive offload.
handover type
Intra-LTE off-loading failure per 12857 - 6 Intra-eNodeB inter-frequency handover fails for load equalization.
handover type
Intra-LTE off-loading failure per 12857 - 7 X2 inter-frequency handover fails for load equalization.
handover type
Intra-LTE off-loading failure per 12857- 8 S1 inter-frequency handover fails for load equalization.
handover type
Outgoing inter-eNodeB X2 handover 12893 - 3 Inter-frequency X2 Handover was triggered for off-loading reason upon
abort per handover reason eNodeB load equalization decision.

30
4. Performance Evaluation
• Counters 6/8 – Direct KPIs impacted:

Counter Name Counter Counter Description


ID
Outgoing inter-eNodeB S1 handover 12890 - 2 Inter-frequency S1 Handover was triggered for off-loading reason upon
abort per handover reason eNodeB preventive load control decision, for all possible triggering
conditions.
Outgoing inter-eNodeB S1 handover 12890 - 3 Inter-frequency S1 Handover was triggered for off-loading reason upon
abort per handover reason eNodeB load equalization decision.
Redirection to inter-frequency other 12871 - 4 RRC inter-frequency redirection triggered due to preventive offload. The
frame structure redirection is measurement-based, using A4 event.

31
4. Performance Evaluation
• Counters 7/8 – Indirect KPIs impacted:
Counter Name Counter Counter Description
ID
X2 received throughput 12909 This counter provides the throughput received on the X2 interfaces of the
eNodeB equipment (including Ethernet headers).
X2 received packets 12910 This counter provides the total number of packets received on the X2
interfaces of the eNodeB equipment.
X2 sent throughput 12911 This counter provides the throughput sent on the X2 interfaces of the
eNodeB equipment (including Ethernet headers).
X2 sent packets 12912 This counter provides the total number of packets sent on the X2
interfaces of the eNodeB equipment.
Downlink PRB used 12032 This counter provides the average, maximum and minimum number of
downlink PRBs that have been assigned by the downlink scheduler in the
cell.
Downlink total PRB usage 12029 This counter provides percentage of DL Physical Resource Block usage.

Downlink PRB allocated 12037 This counter provides the average, maximum and minimum number of
downlink PRBs that have been allocated by the PRB allocator to the cell.
Uplink PRB used 12033 This counter provides the average, maximum and minimum number of
uplink PRBs that have been assigned by the uplink scheduler in the cell.
Uplink total PRB usage 12028 This counter provides percentage of UL Physical Resource Block usage.

Uplink PRB allocated 12038 This counter provides the average, maximum and minimum number of
uplink PRBs that have been allocated by the PRB allocator to the cell.

32
4. Performance Evaluation
• Counters 8/8 – Indirect KPIs impacted:

Counter Name Counter Counter Description


ID
Downlink PRB usage 12035 Downlink PRB usage other GBR, non-GBR

Uplink PRB usage 12034 Uplink PRB usage other GBR, non-GBR

User distribution 13247 This counter allows to have a distribution of the number of UE that are in
or transitioning into RRC_CONNECTED state in the cell for the concerned
PLMN.
Number of UEs in or transitioning into 13201 This counter allows to have the averaged (by dividing the cumulated value
RRC_CONNECTED state by the elapsed time), maximum and minimum number of UE that are in or
transitioning into RRC_CONNECTED state in the cell for the concerned
PLMN.
RRC connection request 12311 This counter provides the number for RRC connection requests received
from UE in the cell.
Total RRC connection success 12302 This counter provides the number for RRC connection procedures
successfully completed.
Total RRC connection failure 12303 This counter provides the number for RRC connection procedures that
have been failed.
Total initial context setup failed 12502 This counter provides the number of Initial Context Setup procedures that
12503 have been failed.

33
5
Conclusion
Conclusion

• This feature aims at providing a new trigger point for load balancing upon
radio congestion, as well as introducing enhancements to the LA6.0 load
balancing solution requested by customers.

• For the current status of the ORF’s network (low numbers of users/ low
traffic), it’s not expected to see many improvements compared with the
existing LA6 load balancing feature.

35

You might also like