TS-SRAN-SW-0077_P5

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 Version 5.0 Confidential

© Nokia 2017

Table of Contents 1. 2. 3. 4. 5. 6.

Validity.................................................................................................................................. 3 Keywords ............................................................................................................................. 3 Executive Summary.............................................................................................................. 3 Detailed description .............................................................................................................. 3 Solution / Instructions ........................................................................................................... 4 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 29-Sep-2015

1.0 2.0

27-Sep-2016

3.0

11-Oct-2016

4.0

27-Jul-2017

5.0

TS-SRAN-SW-0077- Page 2/11 Version 5.0 Confidential

Approved Approved. Information concerning preventive actions improved. Load balancing feature recommendations added. Approved. Information about FSME added. Load balancing features for LTE16 and LTE16A added. Approved. Information about LTE1130 feature has been added. Approved version. Information about AirScale has been added. Information about SRAN validity has been added. Information about LTE2505 feature has been added.

© Nokia 2017

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 NOKIA’s eNBs, as well as generic recommendation for preventive measures to ensure stable operation TS-SRAN-SW-0077- Page 3/11 Version 5.0 Confidential

© Nokia 2017

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 Version 5.0 Confidential

© Nokia 2017

•

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 trafficdriven 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 Version 5.0 Confidential

© Nokia 2017

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 Version 5.0 Confidential

© Nokia 2017

•

• •

•

•

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 Version 5.0 Confidential

© Nokia 2017

•

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 operator’s 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 Version 5.0 Confidential

© Nokia 2017

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 TDLTE15A, 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 TDLTE15A, 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 Version 5.0 Confidential

© Nokia 2017

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 TDLTE16, 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 TDLTE16, 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 TDLTE16A, Feature Descriptions and Instructions respectively in the Operating Documentation.

7. NOTES N/A

8. REFERENCES N/A TS-SRAN-SW-0077- Page 10/11 Version 5.0 Confidential

© Nokia 2017

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 Version 5.0 Confidential

© Nokia 2017