Sie sind auf Seite 1von 11

Technical Support Note

TS-SRAN-SW-0077

Preventive actions to avoid cell outage


due to overload during Mass Call Events

Radi o Network
Fl exi Multi radio BTS LTE
Fl exi Multi radio BTS TD-LTE
Singl e RAN

This document contains following


type of information
Informative
Preventive X
Corrective
Additional categorization
Urgent
Security
Release Upgrade
SW Update
Parameterization
Information is classified as
Internal
Public X
Customer Specific

TS-SRAN-SW-0077- Page 1/11 Nokia 2017


Version 5.0
Confidential
Table of Contents
1. Validity.................................................................................................................................. 3
2. Keywords ............................................................................................................................. 3
3. Executive Summary.............................................................................................................. 3
4. Detailed description .............................................................................................................. 3
5. Solution / Instructions ........................................................................................................... 4
6. Overload Handling Features ................................................................................................. 8
6.1 LTE1047: C-plane Overload Handling ............................................................................... 8
6.2 LTE2023: U-plane Overload Handling ............................................................................... 9
6.3 LTE1788: Automatic Access Class Barring ....................................................................... 9
6.4 LTE1536: RRC Connection Rejection with Deprioritization ............................................... 9
6.5 LTE2505: Access Class Barring Skip .............................................................................. 10
6.6 LTE2460: Automatic Access Class Barring with PLMN Disabling .................................... 10
7. Notes .................................................................................................................................. 10
8. References ......................................................................................................................... 10

Contact:

Contact your local Nokia support

Summary of changes:

20-Oct-2014 1.0 Approved


29-Sep-2015 2.0 Approved. Information concerning preventive actions
improved. Load balancing feature recommendations
added.
27-Sep-2016 3.0 Approved. Information about FSME added. Load
balancing features for LTE16 and LTE16A added.
11-Oct-2016 4.0 Approved. Information about LTE1130 feature has
been added.
27-Jul-2017 5.0 Approved version.
Information about AirScale has been added.
Information about SRAN validity has been added.
Information about LTE2505 feature has been added.

TS-SRAN-SW-0077- Page 2/11 Nokia 2017


Version 5.0
Confidential
Purpose
This document contains generic information about products. These can be instructions that
explain problem situations in the field, instructions on how to prevent or how to recover from
problem situations, announcements about changes or preliminary information as requirements
for new features or releases.

1. VALIDITY

Product Release
Flexi Multiradio BTS LTE FL16, FL16A
Flexi Multiradio BTS TD-LTE TL16, TL16A
Single RAN SRAN 16.10, SRAN 16.2 1.0

2. KEYWORDS

Overload, Mass Call Events, HW replacement, cell split

The following terminology is used in this document


FSME - Flexi Multiradio System Module (rel. 2)
FSMF - Flexi Multiradio System Module (rel. 3)
AirScale - System Module (rel. 4)

3. EXECUTIVE SUMMARY

This TN provides NOKIA recommendation how to prepare the network for Mass Call Events.
This includes parameter adaptation, HW replacement/addition, Cell Split etc.

4. DETAILED DESCRIPTION

On several opportunities and in different deployment scenarios NOKIA eNBs have proven to
flawlessly handle high load situations. This is also valid for eNBs which, on various
opportunities, gracefully served around 600 UEs per cell (with AirScale and also FSMF +
FBBA approximate 9-24 cells per eNB).
However, in case of mass events such as Festivals, Open-air Concerts, Sport events etc. huge
bursts of traffic can occur. The type and shape of the traffic to be handled during such mass
events is typically different from the traffic type used for capacity estimations under normal
conditions. If traffic is not rejected in a controlled way or limited by suitable measures during
predictable overload situations, the operator may face cell outages when the offered traffic
loads the eNB processor boards to or even above its physical limits.
In previously experienced cases of mass event coverage, overload situations have occurred
and have lead to processor unit resets causing the alarm Not enough HW for LCR to be
raised. As a result, cells have been out of service during the impacted time periods.
If such a situation occurs, the only way to recover is to reset the eNB.
Note: The Not enough HW for LCR alarm is not supported by SRAN 16.10, SRAN 16.2 1.0.
The plan is to support it starting from SRAN 17A release.

The first feature to gracefully handle signaling traffic peaks during mass call events (LTE1047:
C-plane Overload Handling) is available starting from RL60/RL45. Further features for
improved overload handling and peak traffic robustness have been designed and are planned
for future releases. Considering the still evolving overload handling capabilities of the NOKIAs
eNBs, as well as generic recommendation for preventive measures to ensure stable operation

TS-SRAN-SW-0077- Page 3/11 Nokia 2017


Version 5.0
Confidential
of eNBs during mass events (with correspondingly huge traffic peaks), NOKIA recommends
suitable preventive measures to be taken by the operator to avoid service impacts or even
outages of the eNBs serving the mass event area.
The purpose of this technical note is to describe which options the operator has to make sure
that the eNBs continue to provide service even in case of huge traffic demands.
Note!
The recommendations in this Technical Support Note are of general validity they should be
considered irrespective of the available and activated overload handling features at a given
point of time.
Within the document there is an additional remark if feature is supported or is not supported in
Single RAN.

5. SOLUTION / INSTRUCTIONS

Overload situations can be caused by short temporary traffic peaks or by significant


sustainable traffic increase that lasts for longer period of time. During mass events the RAN
load can drastically increase in a limited geographical area. The capacity of the involved cells
is limited and may not have been optimized for such a specific use case (and the related traffic
volume) and can thus be considerably exceeded.
If the operator prepares a particular LTE radio coverage area for a forthcoming mass call event
it is recommended to take all or some of the following preventive measures to make sure that
the expected traffic bursts can be properly handled.

Note!
The presented order of the recommended measures listed below correlates with their
importance (i.e. the first-listed measures are strongly recommended, while the lower-listed
ones may be optional or measures for consideration in medium or long-terms):

1. Add new eNBs


(classification: strongly recommended)
Provide additional system capacity in the event area by adding new eNBs.
This can be achieved by a suitable balancing of the load through temporarily
adding additional eNBs for the duration of the mass event, e.g. portable,
mobile eNBs (eNB cell on wheels). Obviously, addition and configuration of
these additional eNBs has to take place prior to the event to avoid any cell
resets or optimization actions during the event. As a mandatory first step,
mobility configuration of the new cells must be correctly set up (e.g. through
the use of ANR (LTE782, LTE556)); only afterwards, as a second step, the
parameterization of these new cells may be adapted to high load (capacity
cell configuration).
(Remark: see also recommendation points: 6, 7, and 4.
Note: The LTE782 and LTE556 features are not supported by Single RAN.

2. Replace FSME by FSMF or AirScale


(classification: strongly recommended)
In those eNBs that serve the (predicted) high load cells, it is strongly
recommended to install FSMF or AirScale (AirScale is supported starting from
FL16A). FSMF and AirScale are the new-generation Flexi System Module,
comprising increased connectivity and processing capabilities in the same
volume as FSME. FSMF and AirScale components provide higher efficiency

TS-SRAN-SW-0077- Page 4/11 Nokia 2017


Version 5.0
Confidential
and processing power with higher number of available processors compared
to FSME.
In Flexi Multiradio FDD-LTE, the FSME system modules are now under phase
out process. The FL15A is the last release handling FSME corrections.
The FSME system module is still supported by the FL16 and FL16A main
releases, however, FL15A contains the encapsulated SW for FSME. Hence
for FSME the feature status is limited to FL15A level even if the network has
been upgraded to a higher LTE main release.

Note!
This recommendation is not applicable for Flexi Multiradio TD-LTE.
In Single RAN solution there is no support for FSME.

3. AirScale
(recommendations for AirScale configuration)
In FL16A AirScale can be configured only without baseband pooling feature
activated, while in FL17A AirScale it will be possible to configure it with and
without baseband pooling.
In any case, it is recommended to use AirScale with baseband pooling, to
have a more flexible allocation of the baseband processing resources to the
cells.
Check that sufficient HW licenses are available to operate both baseband
pools on the ABIA, and check that cells connected to the ABIAs are distributed
equally to the baseband pools and both baseband pools are powered up.
Distribute high loaded cells equally to the baseband pools and ABIAs, and try
to avoid to allocate all high loaded cells to the same baseband pool.
Note!
In SRAN 16.10 and SRAN 16.2 1.0 releases AirScale is not supported. AirScale will be
supported starting from SRAN 17A release.

4. Reduce processing load generated by traffic-driven O&M features


(classification: strongly recommended)
It is strongly recommended to considerably reduce or even switch off traffic-
driven O&M features during the expected high load period to make sure that
the maximum processing power is available to handle the call processing load.
Such features are
Cell Trace
IMSI tracing
SON-ANR
PCMD
The Performance Measurement data reporting granularity should be not lower
than 1 hour. Moreover, it is recommended to a keep number of neighbor
objects low.

Note!
Experience has shown that Cell Tracing/IMSI Tracing considerably increases
a risk of an eNB outage. The operator is therefore advised to categorically
disable these features before the mass event starts.

It is also recommended to avoid snapshot fetching during the mass events. In


case snapshot are configured to be taken periodically this should be omitted
during the duration of the mass event.

TS-SRAN-SW-0077- Page 5/11 Nokia 2017


Version 5.0
Confidential
5. Optimize the cells for the high load event
(classification: recommended)
If recommendation #1 is not used, as a general rule, the cells deployed in
mass event zones should be explicitly optimized for the high load use case
rather than for their often long time low load situation. In other words, the
configuration should be adequate for a capacity cell and not a general macro
cell (see also recommendation #1).
The configuration for a high number of an active UE should be reflected in an
adequate PUCCH and Radio Admission Control setup. The PUCCH
configuration should be in line with the Radio Admission Control settings,
however tuned for max. PUSCH PRBs.
As alternative for manual PUCCH configuration it is recommended to use
LTE1130: Dynamic PUCCH Allocation and LTE2664 Load based PUCCH
region. With this features activated the PUCCH area is kept as small as
possible and thus PUSCH area is maximized, however in case of high load
PUCCH is expanding in an automatic way to serve the request traffic.

Note!
If the LTE1130: Dynamic PUCCH Allocation feature is not activated, then the
setting of RI and CQI on separate TTI (mandatory when DRX is active) requires a
light oversizing of PUCCH region to reach desired maximum RRC_Connected
users.
This can be obtained by configuring the PUCCH bandwidth for CQI (nCqiRb)
parameter for a number of RRC_Connected users 10% larger than the actual
number of RRC_Connected users desired.
Example: to configure CQI and RI settings for 720 UE assume a configuration
equivalent of 792 UE when calculating the nCqiRb parameter.

Note: The LTE1130 and LTE2664 features are not supported by Single RAN

6. Adjust parameters to balance traffic in high loaded area


(classification: recommended)
In terms of parameter planning for the impacted cells, balancing the traffic load in
the cell, the following parameters should be considered:
pMax: Maximum output power
pMax can be reduced to only serve the users in the planned cell
coverage area. The RRC_Idle and RRC_Connected users in the cell
will be reduced by changing this parameter.
dlCellPwrRed: Cell power reduce
dlCellPwrRed can be reduced only or together with pMax. This
change should be considered with cell coverage planning. The
RRC_Idle and RRC_Connected users will be reduced by changing
this parameters.
dlRsBoost: Downlink reference signals transmission power boost
dlRsBoost should be set to 0 for those high loaded cells to reduce the
coverage and limit the no. of active users in the cells.
a3Offset: Handover A3 Offset
The processing of Handover procedures will consume much more
resources than other signaling setup procedures inside eNB. So
configuring a higher a3Offset will suppress the Handover attempts, as
a result more active users can be served with same eNB resource.
However, the side effects should be considered as well since higher

TS-SRAN-SW-0077- Page 6/11 Nokia 2017


Version 5.0
Confidential
a3Offset will increase the cells overlapping area at the cell edge, the
downlink channel condition will get worse duo to DL interference.
ocAcBarAC, ocAcBarTime, ocAcProbFac: Access Class
If the estimated no. of users exceeds the planned cell capacity but
additional eNBs/Cells cannot be set up duo to some reason, the
3GPP Access Class function should be utilized. In this case
ocAcProbFac (Access probability factor for originating calls) should be
reduced and ocAcBarTime (Access class barring time for originating
calls) should be increased to reduce the originating calls from users.
raSmallVolUl: Small size random access data volume in uplink
raSmallVolUl should be equal or bigger than 144bits to avoid bad UL
channel quality users accessing the radio network from the cell edge.
t302: Timer T302
t302 should be set to a bigger value so that UE will retry to attach
network with bigger interval when the Radio Admission Control
algorithm starts to reject users duo to exceeding the maximum setting.
t300: Timer T300
t300 should be set to a bigger value so that UE will wait for
RRCConnectionSetup or RRCConnectionReject message longer,
which will reduce the re-access to radio network by UE.
Paging and UL power control parameters shall be adapted for mass events.

Note!
The above list is only an overview. Concrete parameter values cannot be
given here, because careful cell-individual parameter planning by experts is
required to achieve the best possible results.

7. Reduce the number of cells per eNB


(classification: recommended if applicable)
In case of FSMF, 6-cell-configuration can be changed to 3-cell-configuration.
This will result in the eNB only handling the traffic load from 3-cells - assuming
that the covered area and thus offered traffic per (potentially overloaded) cell
remains the same.

Note!
To make sure that the required capacity is still in place, the cells previously
covered by one eNB may have to be migrated to additional eNBs (see
recommendation 1).

8. Interworking with Load Balancing


(classification: recommended)
The deployment of the features for Mobility Load Balancing for mass events
needs careful analysis of the actual situation and network deployment.
Connected mode MLB should be avoided while idle mode inter-frequency/RAT
MLB (e.g. during RRC release) is preferred solution. In addition UE traffic
control in idle mode should be considered to move UEs to capable neighbor
carriers and RAT in case of re-connection.

9. Double check Radio Admission Control parameters


(classification: to be considered in exceptional cases)
It is recommended to double-check if Radio Admission Control parameters are
suitably adjusted; these parameters can be used to limit the amount of

TS-SRAN-SW-0077- Page 7/11 Nokia 2017


Version 5.0
Confidential
incoming traffic the adjustment should be done depending on the number of
cells per eNB.
Especially if none of the recommendations measures 1 to 5 is followed (that is:
neither FSMF deployed nor Tracing features disabled etc.) the operator may
want to consider to reduce the Maximum number of active users per LNCEL,
managed by the parameters
LNCEL: maxNumActUE
LNCEL: maxNumRrc

Note!
This measure may not be regarded as suitable for mass events, since
basically the operators intention is to handle the upcoming traffic to the best
possible extent and provide a good end user experience (by avoiding service
rejections). Therefore, this option should only be considered in exceptional
cases.

10. Interworking with narrowband functions


As narrowband functions, such as inband NB-IoT and/or LTE-M reduce the air
capacity of the hosting wideband cell, it is recommended to switch off such
features for the cells carrying the traffic from mass events.

The abovementioned measures limit the amount of signaling and prevent single processor unit
from overloading. Taking less load on single cells avoids cells crash in critical situations that
could impact further cells in the neighborhood.

6. OVERLOAD HANDLING FEATURES

This section gives an overview over the available features for overload handling.
Further overload handling features are under preparation or development and will be added to
this document once available. For feature roadmap questions please contact NOKIA Product
Management.

6.1 LTE1047: C-plane Overload Handling

The LTE1047: C-plane Overload Handling feature has been introduced in the RL60/RL45
release.
Note: The LTE1047 feature is supported by Single RAN.

The LTE1047 feature has been introduced to deal with control plane overload resulting from
signaling messages on Uu (RRC), S1-MME (S1AP) and X2 (X2AP) interfaces.

The LTE1047 feature provides the following benefits to the operator:


It helps to maintain reasonable control plane throughput during overload
scenarios and prevents the eNB from crashing.
Provides countermeasures to regulate the control plane load.

Note!
The LTE1047 feature has to be explicitly enabled by a flag Activation of C-plane
overload handling (actCplaneOvlHandling) (it is not enabled by default).

For more details, refer to the LTE RL60, Feature Descriptions and Instructions or the LTE
RL45TD, Feature Descriptions and Instructions respectively in the Operating Documentation.

TS-SRAN-SW-0077- Page 8/11 Nokia 2017


Version 5.0
Confidential
6.2 LTE2023: U-plane Overload Handling

The LTE2023: U-plane Overload Handling feature has been introduced in the FL15A/TL15A
release.
Note: The LTE2023 feature is supported by Single RAN.

The LTE2023 feature is one of a series of features to handle overload situations within the
eNB and to avoid unstable operation of the eNB due to high load.
The main goal of the LTE2023 feature can be outlined as follows:
Handling of a U-plane based high load and overload situations within the eNB
by avoiding allocation of additional traffic
Avoiding unstable operation of the eNB due to high U-plane load or U-plane
overload by avoiding allocation of additional traffic
Handling of as many U-plane traffic/load as possible even in case U-plane
load is near or above limits
U-plane overload shall not happen in case the eNB is operated within its limits
and the related traffic profiles are used. However it can happen in case the
actual traffic is different from the traffic profile used for evaluation of the KPIs,
even if the total amount of active UEs is within the allowed range.
For more details, refer to the FDD-LTE15A, Feature Descriptions and Instructions or the TD-
LTE15A, Feature Descriptions and Instructions respectively in the Operating Documentation.

6.3 LTE1788: Automatic Access Class Barring

The LTE1788: Automatic Access Class Barring feature has been introduced in the
FL15A/TL15A release.
Note: The LTE1788 feature is supported by Single RAN.

The operator can reduce the number of the rejected RRC connection requests
during persistent high C-plane load.
Additional countermeasure for the LTE1047.
An eNB initiates an automatic access class barring for the access classes 0 to
9 if the control plane overload level 2 is active for an operator configurable
time.
There are two new features planned (most probably for FL17A/TL17A) which will enhance the
LTE1788 feature functionality:
- The first one will introduce new event/trigger for automatic ACB which is based on the
percentage of maximum allowed number of RRC Connected UEs in the LTE cell.
- The second one will introduce new event/trigger for automatic ACB algorithm which is
based on the number of RRC Connection Requests received within operator configurable
sliding window.

For more details, refer to the FDD-LTE15A, Feature Descriptions and Instructions or the TD-
LTE15A, Feature Descriptions and Instructions respectively in the Operating Documentation.

6.4 LTE1536: RRC Connection Rejection with Deprioritization

The LTE1536: RRC Connection Rejection with Deprioritization feature has been introduced in
the FL16/TL16 release.
Note: The LTE1536 feature is supported by Single RAN.

The LTE1536 feature supports the load handling of a radio resource control (RRC) connection
request. It introduces an enhancement mechanism for the RRC connection rejection. The

TS-SRAN-SW-0077- Page 9/11 Nokia 2017


Version 5.0
Confidential
feature's aim is to move all UEs that try to establish the RRC connection to a cell at a high load
to other frequency layers or RATs.

For more details, refer to the FDD-LTE16, Feature Descriptions and Instructions or the TD-
LTE16, Feature Descriptions and Instructions respectively in the Operating Documentation.

6.5 LTE2505: Access Class Barring Skip

The LTE2505: Access Class Barring Skip feature has been introduced in the FL16/TL16
release.
Note: LTE2505 feature is not supported by Single RAN.

The Flexi Multiradio BTS supports a cell wide Access Class Barring (ACB) skip. The benefit
of this feature is to have service selective access class barring can for non VoLTE, non
Video or non SMS services.
For more details, refer to the FDD-LTE16, Feature Descriptions and Instructions or the TD-
LTE16, Feature Descriptions and Instructions respectively in the Operating Documentation.

6.6 LTE2460: Automatic Access Class Barring with PLMN Disabling

The LTE2460: Automatic Access Class Barring with PLMN Disabling feature has been
introduced in the FL16A/TL16A release.
Note: LTE2460 feature is not supported by Single RAN.

The LTE2460: Automatic Access Class Barring with PLMN Disabling feature enhances the
LTE1047: Control Plane Overload Handling feature with a possibility to disable the broadcast
of further public land mobile network (PLMN) IDs from the SystemInformationBlockType 1
(SIB1). Consequently, if the PLMN ID is not broadcasted, the cell becomes invisible for the
user equipment (UE).
The automatic removal of a PLMN ID takes place if both of the following conditions are fulfilled:
A control plane overload level 2 defined in the LTE1047 feature is active.
An eNB runs the access class barring operation in an overloaded cell according to the
LTE1788 feature.

The LTE2460 feature provides the following benefits:


automatic limitation of signalling during a high control plane load
monitoring the time that passed when the PLMN IDs are removed
planning the potential improvements for the network's capacity

Note!
Public safety user equipment (PS UE) is allowed to access the cell even if the LTE2460
feature is enabled.

For more details, refer to the FDD-LTE16A, Feature Descriptions and Instructions or the TD-
LTE16A, Feature Descriptions and Instructions respectively in the Operating Documentation.

7. NOTES

N/A

8. REFERENCES

N/A

TS-SRAN-SW-0077- Page 10/11 Nokia 2017


Version 5.0
Confidential
Disclaimer
The information in this document applies solely to the hardware/software product (Product) specified herein, and only as specified
herein. Reference to Nokia later in this document shall mean the respective company within Nokia Group of Companies with whom
you have entered into the Agreement (as defined below).

This document is intended for use by Nokia's customers (You) only, and it may not be used except for the purposes defined in the
agreement between You and Nokia (Agreement) under which this document is distributed. No part of this document may be used,
copied, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia. If You have not
entered into an Agreement applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this
document in any manner and You are obliged to return it to Nokia and destroy or delete any copies thereof.

The document has been prepared to be used by professional and properly trained personnel, and You assume full responsibility
when using it. Nokia welcomes your comments as part of the process of continuous development and improvement of the
documentation.

This document and its contents are provided as a convenience to You. Any information or statements concerning the suitability,
capacity, fitness for purpose or performance of the Product are given solely on an as is and as available basis in this document,
and Nokia reserves the right to change any such information and statements without notice. Nokia has made all reasonable efforts to
ensure that the content of this document is adequate and free of material errors and omissions, and Nokia will correct errors that You
identify in this document. Nokia's total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia
does not warrant that the use of the software in the Product will be uninterrupted or error-free.

NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF
AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE, IS MADE IN RELATION TO THE CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA BE
LIABLE FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR
CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS
INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE
INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT.

This document is Nokia proprietary and confidential information, which may not be distributed or disclosed to any third parties without
the prior written consent of Nokia.

Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their
respective owners.

Copyright 2017 Nokia. All rights reserved.

Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.

Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having
carefully read the safety information applicable to this product.

The safety information is provided in the Safety Information section in the Legal, Safety and Environmental Information
part of this document or documentation set.

Nokia is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you
as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow
the recommendations for power use and proper disposal of our products and their components.

If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at
Nokia for any additional information.

TS-SRAN-SW-0077- Page 11/11 Nokia 2017


Version 5.0
Confidential