HiCap settings for Ericsson LTE
Pre VoLTE
RAN Performance Standards & Best Practices
© 2012 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T
Intellectual Property.
Guiding Principles for HiCap Settings


Reduce Idle and Connected Mode Mobility
o
Keep LTE capable UEs on the LTE network – further
consideration next slide
o
Limit InterRat (Release with Redirect) from LTE
o
Limit Cell Reselection from LTE
o
Strongly favor Cell Reselection from UMTS to LTE
o
Leverage reactive Load Balancing algorithms as fallback
Conserve Resources
o
Prioritize Accessibility over Throughput and Retainability
o
Reduce signaling due to Mobility and Dropped calls and CSFB
recovery
o
Direct traffic through Idle Mode procedures (Multi eARFCN)
Further consideration for keeping UEs
on LTE
Maximize UEs on LTE.

Pro
o

Expectation of LTE UE being on LTE is satisfied.
Con
o
Possibility of better experience on UMTS is not available.
Distribute across technologies.


Pro
o
Potential for better experience
o
Potential for improved KPIs across technologies
Con
o
Implementation not currently available
Properties of HiCap Settings
HiCap Settings have the following properties:



Communicated via the Gold Standard
o
HiCap parameters are distinguished through the use of the “HiCap”
suffix
o
Can be used with or without a DAS
Optimized for use in Venue Sites
o
HiCap settings are optimized for use during large events
o
Specific values are optimized for specific events e.g. concert vs.
baseball game
o
Not meant for non-venue sites (rule suspended for now)
o
HiCap is preemptive as opposed to Overload management
(separate initiative)
Trade-offs are leveraged
Trial Timelines



LSU Football game – System Constants
LSU_1103GAMES
o
Implement Ericsson System Constant changes 3rd Nov.
o
See MAC and RLC layer changes with “Ericsson” prefix is
subsequent slides
Subsequent trial (phase 1)
Trial Summary
o
Phase I activities are denoted with a
o
Consult with V&E to target event locations and times
Summary of trials
o
4 SON Related
o
1 RACH
o
2 Admission / Congestion
Control
o
6 Cell Selection/Reselection
o
3 Handover
o
6 Scheduler
o
o
3 MAC Layer
3 Design / Core
o
1 License
o
Specific HiCap Initiatives

Cell Selection & Reselection
o
Lower qRxLevMin to keep LTE capable UEs on LTE
 Reduce EUtranCellFDD:qRxLevMin from -122 (GS) to -140.
o
Raise qRxLevMin to allow for a higher effective sIntraSearch
 Increase EUtranCellFDD:qRxLevMin from -122 (GS) to -112 Where
EUtranCellFDD:systemInformationBlock3.sIntraSearch = 62 (max value)
 Begin intrafrequency measurement would move from -60 to -50 keeping UEs
on best server
o
Implement Speed Dependant Scaling to reduce Cell Reselection
ping pong
 Parameters in MO EUtranCellFDD.
systemInformaionBlock3.nCellChangeHigh, .nCellChangeMedium,
.qHystSfHigh, .qHystSfMedium, .tReselectionUtraSfHigh,
.tReselectionUtraSfMedium.
o
Set sNonIntraSearch (intraLTE) to 0 to keep LTE capable UEs on
LTE
 EUtranCellFDD:systemInformationBlock3.sNonIntraSearch from 6 (GS) to 0.
Assumes single EARFCN environment
o
Limit cell radius through RS attenuation and/or antenna
modification
Specific HiCap Initiatives

Handover
o
Reduce frequency of Events Ax and Bx to reduce signaling & eNb
processor load
 Increase ReportConfigEUtraBadCovPrim:timeToTriggerA2Prim from 640 (GS) to
1280 ms.
 Increase ReportConfigEUtraBestCell:timeToTriggerA3 from 640 (GS) to 1280
ms.
o
InterFrequncy Load Balancing (new in L12B)
 Implement FAJ 121 3009 in venues with multi EARFCN support.
 Activate feature
InterFrequencyLoadBalancing:featureStateInterFrequencyLoadBalancing = 1
 Turn on capability EUtranCellRelation:loadBalancing = 1
 Consider appropriate values for cellSubscriptionCapacity,
o
Ericsson - Load Control Trigger
 Adjust the maximum number of initial accesses and incoming handovers that
are allowed during a time window without triggering the load control
mechanism.
 System Constant 556.
 Ericsson is working on final recommendation with PDU.
Specific HiCap Initiatives

Scheduler (1 of 2)
o
Increase number of users per TTI
 This needs to be discussed more with Ericsson. Could be software support
dependant or could be System Constants.
o
Favor users with better CQI in order to increase the utilization of
less robust (more efficient) MCS values.
 Change QciProfilePredefined.schedulingAlgorithm from 4
(PROPORTIONAL_FAIR_LOW) to 5 (MAXIMUM_C_OVER_I) in order to maximize
cell throughput. Consider SON for this.
 Move poorest quality users to UMTS.
 Look at CQI distribution as an indication of how bad it would be for poor C/I
users.
o
Adjust SIR (CQI) to favor throughput over robustness
 This is possible in ALU, not sure about Ericsson. Need to discuss further.
Specific HiCap Initiatives

Scheduler (2 of 2)
o
Increase number of concurrent RRC Connected users.
 Upgrade eNb from L12A (up to 700 users) to L12B (up to 1500 connected
users). Make sure EUtranCellFDD:noOfPucchSrUsers has been increased to
590 (GS) and EUtranCellFDD:noOfPucchCqiUsers to 320 (GS).
 Network deployment of L12A began 29 Oct. with early deployment to Venue
sites.
 Ericsson - Change System Constant commonSrPeriodicity from 10 to 20 ms.
This parameter determines how often the Scheduler allows the UE to make a
Schedule Request on the PUCCH.
o
Ericsson - Reduce tInactivityTimer.
 Reduce tInactivityTimer from 10 seconds to 4 seconds.
 Will allow releasing resources quickly and allow for handling of more traffic.
 Reducing value requires implementation through Special Purpose Package
and needs to be discussed as potential improvement in L12B.
o
Increase inactivity timer to reduce RRC Connection attempts
 Increase Rcs:tInactivityTimer from 10 seconds to 20 seconds.
 Be careful to avoid exceeding the supported maximum of concurrent RRC
Connected users.
Specific HiCap Initiatives

HARQ Retransmissions (MAC layer)
o
Ericsson - Extend poll time
 Extend the time for new poll if no status report is received from 80 ms to 160
ms for both Signaling Radio Bearer and Data Radio Bearer.
 Will reduce SE/TTI usage for retransmissions, allowing more SE/TTI to serve
traffic.
 System Constants tPollRetransmitUl and tPollRetransmitDl.
o
Ericsson - Reduce max RLC Retransmissions
 Reduce the number of RLC retransmissions for Signaling Radio Bearer and
Data Radio Bearer to 8.
 Will reduce SE/TTI usage for retransmissions allowing more SE/TTI to serve
traffic.
 Might cause Retainability degradation.
 System Constants dlMaxRetxThreshold and ulMaxRetxThreshold
o
Ericsson - Reduce PDCCH link adaption algorithm from 10db to 6
db.
 System constant 220 to be changed to 60.
 More detail needed from Ericsson.
Specific HiCap Initiatives

Timers (RLC layer)
o
Ericsson - Extend poll time
 Change System Constant Timer t302 from 5 to 16 seconds.
 Defines the amount of time the UE needs to wait to access the site when RRC
Connection Reject is received.
 Will extend the time until UEs can perform a reattempt.
 Will influence only UEs that are compliant with this timer.
Specific HiCap Initiatives

SON related
o
Adjust InterRat Cell Reselection parameters on both networks to
balance load
 A SON algorithm that would monitor consumable utilization on the UMTS and
LTE networks and would adjust “S” and “H” parameters to balance load and
reduce blocking on both networks.
 Disable Cell Reselection from UMTS to LTE when LTE is in overload.
o
CSFB target prioritization based on UMTS load
 A SON algorithm that actively adjusts the priority of the UARFCN used in the
Release with Redirect message associated with CSFB
(UtranFreqRelation:csFallbackPrio) to actively balance the load among the
UMTS UARFCNs serving within the LTE EARFCN.
 Consider GSM as an option as well.
o
Consideration for pathloss differences between RATs (LTE
sparsing)
 A SON algorithm that balances the utilization of resources between UMTS and
LTE servers considering the pathloss difference between the technologies.
 For example, UMTS might be considered for low pathloss connections given
power is a consumable resource.
Specific HiCap Initiatives

RACH and Open Loop Power
o
Reduce initial power with greater incremental steps.
 Lower initial power with greater incremental steps in order to take advantage
of lower Path Loss in venues.
 The greater step size addresses the increased noise due to high user density.
 There are currently no power related Operator Configurable parameters for
RACH.

Decrease maximum UE Transmitt Power
o
Reduce EUtranCellFDD:pMaxServingCell from 23 dBm (GS) to 21
dBm
 Could reduce total UL Noise + Interference.
Specific HiCap Initiatives

Admission / Congestion Control
o
Adjust Admission Control to allow all access attempts
 Make sure AdmissionControl:dlTransNwBandwidth = 1000 Mbps (GS) does not
block users.
 Make sure AdmissionControl:ulTransNwBandwidth = 1000 Mbps (GS) does not
block users.
o
Add consideration for additional parameters with introduction of
VoLTE
 dlNonGbrRatio, ulNonGbrRatio, resourceType, paArpOverride, absPrioOverride
Specific HiCap Initiatives

Design / Core
o
Avoid TAC border in venue
 Consider use of Metrocell (different TAC).
o
Split 10MHz eARFCN into two 5MHz eARFCNs
 Idea floating around
 Doubles capacity lost to Control Plane
o
Distribute multiple eNbs equally among users
 The objective is to balance the number of RRC Connected users among eNbs
thereby reducing the amount of blocking that occurs due to the maximum
number of concurrent RRC Connected users being exceeded.
o
Spread paging over time to avoid paging channel overload
 Focus on MME configurable Parameters related to paging.
 Also consider Paging:maxNoOfPagingRecords
Specific HiCap Initiatives

Licenses
o
Audit Parameter values
 Ensure license related values are set to maximum values.