LTE_RL70_1.2_Release_Documentation.pdf

© Nokia Solutions and Networks 2015 APPROVED 1.0 Confidential

Release Delivery: RL70 1.2 Product Family: Base Stations Product: Flexi Multiradio BTS LTE, Flexi Zone BTS Release: LN7.0 1.2, LNF7.0 1.2

Contact Contact your local Nokia Solutions and Networks support

Summary of changes:

2015-09-09 1.0 Approved version

Nokia Solutions and Networks 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 Solutions and Networks for additional information.

LTE_RL70 1.2 Installation Instructions

LTE_RL70 1.2 SW Update Verification Report

LTE_RL70 1.2 Release Summary and Impact

LTE_RL70 1.2 Change Note Forms

LTE_RL70_1.2 Release Summary and Impact - Page 1/13 © Nokia Solutions and Networks 2015 APPROVED 1.0 Confidential

Release Summary and Impact Id: LTE_RL70_1.2 Release Delivery: RL70 1.2 Product Family: Base Stations Product: Flexi Multiradio BTS LTE, Flexi Zone BTS Release: LN7.0 1.2, LNF7.0 1.2 Approved version: 09-Sep-2015



Table of Contents 1. Corrections .................................................................................................................................................... 3 2. New / Changed functionality.......................................................................................................................... 3

2.1 Released Features ................................................................................................................................................... 3 3. Restrictions .................................................................................................................................................... 3

3.1 Restricted Released Features.................................................................................................................................. 3 3.2 Other restrictions ...................................................................................................................................................... 3

4. Released objects ........................................................................................................................................... 4 4.1 Flexi Multiradio BTS LTE ......................................................................................................................................... 4 4.2 Flexi Zone BTS ........................................................................................................................................................ 4 4.3 LTE iOMS ................................................................................................................................................................ 5

5. SW download and activation times ............................................................................................................... 6 5.1 Flexi Multiradio BTS LTE ......................................................................................................................................... 6 5.2 Flexi Zone BTS ........................................................................................................................................................ 7

6. Effects on operator ........................................................................................................................................ 7 6.1 KPI changes............................................................................................................................................................. 7 6.1.1 Improvement on: E-RAB Accessibility ...................................................................................................................... 7 6.1.2 Improvement on: ETWS & Paging ........................................................................................................................... 7 6.1.3 Improvement on: VoLTE Success Ratio .................................................................................................................. 8 6.1.4 Increase on: UL Latency KPIs................................................................................................................................. 9 6.1.5 Corrected formula for KPI: (M8001C266/M8001C267)/(M8001C420/100) .............................................................. 9 6.1.6 Corrected M8014C17 counter ................................................................................................................................ 10 6.1.7 Corrected KPIs: LTE_5603a and LTE_5601a ........................................................................................................ 10 6.2 Alarm changes ....................................................................................................................................................... 11 6.2.1 “Antenna line failure (1836)” instead of “Antenna Line Device failure (3100)” when overcurrent is detected ......... 11 6.2.2 New scenario added to Fault ID 1868 .................................................................................................................... 11 6.2.3 Changed handling of Fault ID 6803 ....................................................................................................................... 12

7. Piloting ......................................................................................................................................................... 12 8. Appendices / References ............................................................................................................................ 12

Contact Contact your local Nokia Solutions and Networks support.

Summary of changes 09-Sep-2015 1.0 Approved version


Purpose The purpose of this document is to summarize the RL70 1.2 SW Delivery content and impact.

1. CORRECTIONS

List of corrections for LTE_RL70_1.2: Pronto ID Title

NA05823899 Functionality of ULCoMP on stations from FBBC at the 2nd slot cannot be activated

NA05814845 LTE2050 Wrong CAC calculation / Active Bearers measurement wrong NA05831781 UE stuck in OutOfSync NA05818149 eNB restarts during MP3.1 sw-downloads via sw- manager

PR074268 Tracking fix for - NA05829186 RL70 1.1 upgrade failure caused by TRS IPSec configuration lost

PR068687 WCDMA-LTE RF Sharing: LTE does not get onair after commissioning NA05804048 2 Sites out of service with FRMC RF module failure (1907)

NA05815362 After RL70 upgrade, BTS in RF sharing sites shows alarm 7744 Excessive TCH interference

PR070078 attach not possible with category 1 UE PR069186 [LTE430] PDCCH Power Boost missing from time to time PR058899 VoLTE calls DL data transfer stalls PR062199 MAC PS logging: too many SR or CQI requests per TTI

NA05831155 FOA - After RL70 Upgrade on Chicago FzM Sites - Alarm "6706 autonomous reset as recovery action" is Appearing

NA05829844 FZM crash again by autonomous FSP reset

NA05825759 Software failure reset occurred on FZM(eNB-148152) after rollback to RL70PP0.2.2

PR070573 LNF7.0 FZM LCID value detected! 0x10 MAC header corrupted crash during high load test

PR069722 LNF7.0 FZM; High load test causes L2 assert in PHR message NA05824923 BTS internal SW management problem occurred in eNB165301(FZM) NA05821517 Software failure reset occurred in FZM(LNF7.0_ENB_1407_138_02)

NA05819629 There is an alarm 7652 Base station notification (6803: EFaultId_GpsAntennaCurrentHighAl) at A101 PICO with RL70 P8 SW.

PR065078 FZM rolling reboots due to "BUG: soft lockup - CPU# stuck"

2. NEW / CHANGED FUNCTIONALITY

2.1 Released Features

N/A

3. RESTRICTIONS

3.1 Restricted Released Features

NA 3.2 Other restrictions

LTE1634 (Remote RF-diagnostics for Flexi Multiradio BTS) -> it was reported that after upgrade to RL70 SW, when the “Remote RF-diagnostics for Flexi Multiradio BTS” feature (LTE1634) is activated and the measurement report with RTWP/VSWR parameter out of range is received, the eNodeB commissioning is lost (except TRS configuration), the eNodeB is not operational and has to be commissioned again. There is no relation to any

https://online.portal.nsn.com/pic/infocenterproxy/RL70P8HTML/nav/1_6_1_5_8

https://online.portal.nsn.com/pic/infocenterproxy/RL70P8HTML/nav/1_6_1_5_8


specific HW configuration. The regular correction for the issue is targeted to RL70 2.0 (LE: open). Before the correction is available it is recommended NOT to activate the LTE1634 feature with RL70 SW.

4. RELEASED OBJECTS

4.1 Flexi Multiradio BTS LTE

SW update delivery Delivery date Software Item Software File Name

LN7.0 02-April-2015

BTS Site Manager LN7.0_BTSSM_1407_095_00.zip

Golden SCF Golden Config LN7.0_548-onwards 2015-03-05.zip

eNB LN7.0_ENB_1407_555_05_release_BTSSM_downloadable.zip

IDA2 Sacks LN7.0_ENV_1407_011_00.zip

LN7.0 0.1 30-April-2015




LN7.0 0.2 07-May-2015




LN7.0 1.0 10-July-2015




LN7.0 1.1 31-July-2015

BTS Site Manager BTS Site Manager (ltesdkroot)_LN7.0_BTSSM_1407_107_00.zip



LN7.0 1.2 09-September-2015




4.2 Flexi Zone BTS




LNF7.0 02-April-2015

BTS Site Manager LNF7.0_BTSSM_1407_060_00.zip

eNB LNF7.0_ENB_1407_136_03_release_BTSSM_downloadable.zip

Golden SCF Golden Config LNF7.0_136_03.zip

LNF7.0 0.2 07-May-2015



Golden SCF Golden Config_LNF7.0_136_03.zip

LNF7.0 1.0 10-July-2015



Golden SCF Golden Config_LNF7.0_136_03_onwards.zip

LNF7.0 1.2 09-September-2015




4.3 LTE iOMS


iOMS7.0 02-April-2015

USB install image USB_full_GOMS7_1.3.2.0.release_oms.corr26_2x146or2x147_HW.BLG6Gen8.zip

USB install image USB_full_GOMS7_1.3.2.0.release_oms.corr26_2x300_HW.BLG6Gen8.zip

USB boot FP_USBboot_v2.6.5.zip

MSU image MSU_GOMS6_1.113.1.0.c29_42orGOMS6_1.107.1.0.c24_45_to_GOMS7_1.3.2.0.c22.zip

iOMS7.0 Corrections

R_GOMS7_1.3.2corr23-29.zip

iOMS7.0 Corrections


iOMS7.0 Corrections


iOMS7.0 Corrections


iOMS7.0 1.0 10-July-2015






MSU image MSU_GOMS6_1.113.1.0.c29_44orGOMS6_1.107.1.0.c24_45_to_GOMS7_1.3.2.0.c27_HW.BLG6Gen8.zip

iOMS7.0 Corrections


iOMS7.0 Corrections


iOMS7.0 Corrections


iOMS7.0 1.1 31-July-2015




MSU image MSU_GOMS6_1.113.1.0.c29_44orGOMS6_1.107.1.0.c24_45_to_GOMS7_1.3.2.0.c27_HW.BLG6Gen8.zip

iOMS7.0 Corrections


iOMS7.0 Corrections


iOMS7.0 Corrections


iOMS7.0 Corrections


5. SW DOWNLOAD AND ACTIVATION TIMES

Note: There is limited number of simultaneous SW Management operations over the southbound interface on LTE iOMS:

- max 100 eNB SW downloads at a time (in one batch), - if the 2 hour duration of one batch is exceeded, then issues might appear and to

avoid them, the Customer need to decrease the number of simultaneous downloads accordingly.


LN7.0 1.2 can be background downloaded to the FCM prior to activation. Activation of the eNB software will cause momentary loss of service in the serving cells as the FCM will be reset. The rough SW download and activation times are:

The rough SW download and activation times

SW download eNB with FSME ~ 25 min eNB with FSMF ~ 15 min

SW activation (including eNB reset), causing temporary loss of service ~ 5 min


5.2 Flexi Zone BTS

LNF7.0 1.2 can be background downloaded to the FZM prior to activation. Activation of the software will cause momentary loss of service in the serving cells as the FZM will be reset.

The rough SW download and activation times:

SW download ~ 5 min SW activation (including eNB reset), causing temporary loss of service ~ 6 min

6. EFFECTS ON OPERATOR

6.1 KPI changes

6.1.1 Improvement on: E-RAB Accessibility

Release where the change will be introduced RL60 NE SW version RL60 3.0 Relation to features or corrections 152136ESPE02: 8-eps-bearer setup failure simultaneously LTE520: 8 EPS bearers per UE (RL60 feature)

Short description / Expected impact Probability of EPS establishment rejection with ‘Invalid QoS combination’ caused by Bearer Combination Control (BCC) is lowered due to additional bearer combinations introduced (only some subset from 3GPP defined bearer combinations have been allowed before). Reasoning why the change was made Problem observed during Field Verification Some correct bearer setups (coming from cisco MME) was rejected with cause 'invalid QOS combination' Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW UE dependency no Impacted counters/KPIs - Counter EPS_BEARER_SETUP_FAIL_RNL (M8006C2) is decreased

-> KPI LTE_1065c E-UTRAN Total E-RAB Accessibility is improved -> KPI LTE_5574c E-UTRAN Additional E-RAB Accessibility is improved -> KPI LTE_5086a E-UTRAN E-RAB Setup Failure Ratio per Cause is improved

- Average number of data radio bearers per Active UE is expected to increased with the traffic increase (LTE520 specific)

- UE power consumption increase is expected due to new bearer combinations introduction when all 8 bearers are established in compare to 6 bearers support at maximum (LTE520 specific)

6.1.2 Improvement on: ETWS & Paging

Release where the change will be introduced RL60


NE SW version RL60 3.0 Relation to features or corrections PR58862ESPE05: Paging message array elements not properly released LTE843: ETWS Broadcast

Short description / Expected impact Wrong behaviour before the fix has been committed: If a normal PCCH paging message is scheduled in the last TTI of a BCCH modification paging period, then the internal paging message bookkeeping may fail. Correction: Internal bookkeeping has been fixed.

Reasoning why the change was made Problem observed during Field Verification, paging was not sent over PCCH (user could not be reached or called) Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW UE dependency No Impacted counters/KPIs/Alarms None – not visible in PM Counter Number of raised alarms (BTS faults) 6112 “Phish Power Boost not applied “ is reduced (as fast workaround to indicate problems with paging to the customer, an existing Alarm was used )

6.1.3 Improvement on: VoLTE Success Ratio

Release where the change will be introduced RL60 NE SW version RL60 3.0 Relation to features or corrections LTE10 EPS Bearer for Conversational Voice 153320ESPE02: QCI1 release related counters are updated even when QCI1 setup was not successful 153409ESPE02: ENB_EPS_BEAR_REL_REQ_R_QCI1 is updated incorrectly when the QCI1 release initiated by EPC side Short description PM counter shall only count bearers for which E-RAB Setup Response was sent to MME. Expected impact Without correction in very rare interaction cases the VoLTE drop was unnecessarily counted. Reasoning why the change was made Problem observed during Field Verification Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW UE dependency No


Impacted counters/KPIs - Counter ENB_EPS_BEAR_REL_REQ_R_QCI1 (M8006C134) is decreased - Counter EPC_EPS_BEAR_REL_REQ_N_QCI1 (M8006C89) is unchanged

-> KPI LTE_1153a Average voice call duration is improved -> KPI LTE_5572a E-UTRAN E-RAB QCI1 Drop Ratio, RAN View is improved

6.1.4 Increase on: UL Latency KPIs

Release where the change will be introduced RL60 NE SW version RL60 C5 Relation to features or corrections TCP window optimization Short description / Expected impact This functionality is introduced as a countermeasure for TCP Auto Tuning Window Size. RTT time increase so that TCP window size is bigger. Reasoning why the change was made Achieving higher throughput rates. Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW UE dependency No Impacted counters/KPIs -> KPI LTE_5137a E-UTRAN Average Latency Uplink increased.

6.1.5 Corrected formula for KPI: (M8001C266/M8001C267)/(M8001C420/100)

Release where the change will be introduced RL70 1.1 NE SW version RL70 Relation to features or corrections PR053800: [LN70]Throughput 5MHz UL wrong KPI Short description / Expected impact Formula for KPI (M8001C266 / M8001C267) / (M8001C420 / 100) in case of 5MHz should be between [0.95; 1.05]. Reasoning why the change was made Incorrect KPI statistics about users with uplink buffered data: M8001C266 / M8001C267 and M8001C420 / 100. Sampling for average counters related to buffered UE data in uplink are counted incorrectly. Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW UE dependency


No Impacted counters/KPIs Formula for KPI: (M8001C266/M8001C267)/(M8001C420/100)

6.1.6 Corrected M8014C17 counter

Release where the change will be introduced RL70 1.1 NE SW version RL60 Relation to features or corrections NA05798920: S1 base handover counter update mismatch Short description / Expected impact Alignment between specification and implementation. The counter won’t be incremented. Reasoning why the change was made Mismatch between specification and implementation. M8014C17 "Failed Inter eNB S1-Handover preparations due to other reason” was wrongly updated after source eNB has already received “handover command”. Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW UE dependency No Impacted counters/KPIs M8014C17 "Failed Inter eNB S1-Handover preparations due to other reason”

6.1.7 Corrected KPIs: LTE_5603a and LTE_5601a

Release where the change will be introduced RL70 1.1 NE SW version RL70 Relation to features or corrections NA05803652: Abnormal KPI value in LTE_5603A and LTE_5601a Short description / Expected impact Replaced function which does not depend on eNB time synchronization to provide elapsed system time. Reasoning why the change was made Times of measured procedures were affected by eNB time synchronization. Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW UE dependency No Impacted counters/KPIs LTE_5603a - E-UTRAN Maximum RRC Connection Setup Time


LTE_5601a - E-UTRAN Maximum E-RAB Setup Time

6.2 Alarm changes

6.2.1 “Antenna line failure (1836)” instead of “Antenna Line Device failure (3100)” when overcurrent is detected

Release where the change will be introduced RL70 1.1 NE SW version RL70 Relation to features or corrections NA05811006: After upgrade some sites have Antenna Line failure Short description / Expected impact The alarm changed to Antenna line failure (1836) when overcurrent is detected, and the description of such has also updated to: “The Radio Module (60W RRH) or Filter (all others) has detected overcurrent on the antenna line. The antenna line might be damaged (short circuited) or some antenna line device is causing overload. All antenna line devices powered by the antenna line are out of order.” Reasoning why the change was made “Antenna Line Device failure (3100)” alarm wrongly shown when overcurrent is detected. Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW Impacted Fault ID 1836: EFaultId_ALOvercurrentAl 3100: EFaultId_AntennaLineFailure

6.2.2 New scenario added to Fault ID 1868

Release where the change will be introduced RL70 1.1 NE SW version RL70 Relation to features or corrections PR046004: 2 Cells are down after BW change of another cell Short description / Expected impact New scenario (cell disabled) is added to fault 1868 and alarm 7653 is enabled with additional info: “Detected hardware doesn’t allow to setup cell according to configuration”. Reasoning why the change was made No alarm is raised when cell is disabled. Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW Impacted Fault ID: 1868: EFaultId_NotEnoughHwForLcrAl

https://pronto.inside.nsn.com/pronto/problemReport.html?prid=NA05811006


6.2.3 Changed handling of Fault ID 6803

Release where the change will be introduced RL70 NE SW version RL70 1.2 Relation to features or corrections NA05819629 - There is an alarm 7652 Base station notification (6803: EFaultId_GpsAntennaCurrentHighAl) LTE1629- Integrated GPS Sync for Flexi Zone Micro BTS Short description / Expected impact The FZP GNSS receiver hardware does not support the ability to measure GNSS antenna LNA current so the 6803 fault should not be reportable by the FZP. The 6803 fault should be reported on the FZM only. Reasoning why the change was made The masking of 6803 fault reporting will prevent the false fault reporting. Type of change: generic in the SW, license-based or activated by PRFILE Generic in the SW Impacted Fault ID: 6803 - EFaultId_GpsAntennaCurrentHighAl Alarm ID: 7652 - BASE STATION NOTIFICATION

7. PILOTING

NA

8. APPENDICES / REFERENCES

The software for the released products is available in NOLS. The newly released software can be downloaded from the direct links:

• Flexi Multiradio BTS LTE: https://online.portal.nsn.com/SWD/?access_key=MTE1MDc2

• Flexi Zone BTS: https://online.portal.nsn.com/SWD/?access_key=MTE1MDc2

After downloading the software it is important to generate SH1 checksum for files and compare it with the one provided in the Installation Instructions document, this will ensure that the files were not corrupted during downloading. [1] LTE Customer Documentation: Nokia Long Term Evolution Information Center [2] Product Information Center (PIC): https://online.portal.nsn.com/pic/ [3] LTE internet web page: http://nsn.com/portfolio/products/mobile-broadband/long-term-evolution-lte

https://online.portal.nsn.com/

https://online.portal.nsn.com/SWD/?access_key=MTE1MDc2


https://online.portal.nsn.com/pic/com/nsn/extranet/pic/controller/productinfoview/pivdocumentation.do?productId=urn:nsn.com:mxpdm:133-047489&RId=urn:temp:Flexi-LBTS7.0

https://online.portal.nsn.com/pic/

http://nsn.com/portfolio/products/mobile-broadband/long-term-evolution-lte

http://nsn.com/portfolio/products/mobile-broadband/long-term-evolution-lte


Disclaimer The information in this document applies solely to the hardware/software product (“Product”) specified herein, and only as specified herein.

This document is intended for use by Nokia Solutions and Networks' customers (“You”) only, and it may not be used except for the purposes defined in the agreement between You and Nokia Solutions and Networks (“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 Solutions and Networks. 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 Solutions and Networks 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 Solutions and Networks welcome 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 Solutions and Networks reserves the right to change any such information and statements without notice. Nokia Solutions and Networks has made all reasonable efforts to ensure that the content of this document is adequate and free of material errors and omissions, and Nokia Solutions and Networks will correct errors that You identify in this document. But, Nokia Solutions and Networks' total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia Solutions and Networks 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 SOLUTIONS AND NETWORKS 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 Solutions and Networks’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the prior written consent of Nokia Solutions and Networks.

Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © 2015 Nokia Solutions and Networks. All rights reserved.

RL70 - LTE_RL70_1.2 Installation Instructions - Page 1/31 © Nokia Solutions and Networks 2015 APPROVED 1.0 Confidential

Installation Instructions Id: LTE_RL70_1.2 Release Delivery: RL70 1.2 Product Family: Base Stations Product: Flexi Multiradio BTS LTE, Flexi Zone BTS Release: LN7.0 1.2, LNF7.0 1.2 Approved version: 09-Sep-2015



Table of Contents 1 Purpose ......................................................................................................................................................... 4 2 Overview ........................................................................................................................................................ 4

2.1 Other Relevant Installation Instructions ................................................................................................................... 4 3 Preparations .................................................................................................................................................. 4 4 Making a safe copy of the active package .................................................................................................... 5 5 SW downloading instructions ........................................................................................................................ 5 6 Special conditions ......................................................................................................................................... 5

6.1 Flexi Multiradio BTS LTE ......................................................................................................................................... 5 6.2 Flexi Zone BTS ........................................................................................................................................................ 6

6.2.1 Supported Configurations for Flexi Zone BTS ................................................................................... 6 6.2.2 Supported Hardware ......................................................................................................................... 6

6.3 RF-Sharing............................................................................................................................................................... 6 6.3.1 LTE-GSM RF Sharing ....................................................................................................................... 6 6.3.2 WCDMA-LTE RF Sharing .................................................................................................................. 7

6.4 COMPATIBILITY MATRIX ....................................................................................................................................... 8 6.4.1 Flexi Multiradio BTS LTE ................................................................................................................... 8 6.4.2 Flexi Zone BTS .................................................................................................................................. 9

7 Data migration ............................................................................................................................................... 9 8 Release delivery upgrade instructions ........................................................................................................ 10

8.1 Flexi Multiradio BTS LTE ....................................................................................................................................... 10 8.1.1 First installation and commissioning ................................................................................................ 10 8.1.2 Project upgrade ............................................................................................................................... 10

8.2 Flexi Zone BTS ...................................................................................................................................................... 14 8.2.1 First installation and commissioning ................................................................................................ 14 8.2.2 Project Update/Upgrade .................................................................................................................. 14

8.3 SON ....................................................................................................................................................................... 16 9 General Operator Hints ............................................................................................................................... 16

9.1 Debug flags (R&D flags) in swconfig.txt ................................................................................................................. 16 9.2 Up to 3 resets excuted on FSMF Upgrade ............................................................................................................ 16 9.3 FSMx SW upgrade to RL70 1.2 with Factory SW .................................................................................................. 17 9.4 TRS commissioning ............................................................................................................................................... 18 9.5 Redirection to ultraFDD supported only ................................................................................................................. 18 9.6 Mast Head Amplifier FHLA: Validation error “Incorrect parameter: mhaGain” after upgrade to RL70.................... 18 9.7 Juniper SEC-GW ................................................................................................................................................... 18 9.8 Checkpoint SEC-GW ............................................................................................................................................. 19 9.9 Auto Connection and VLAN Scan Optimization ..................................................................................................... 19 9.10 LTE497 Smart Admission Control: Avoid GBR admission in empty cells fail ......................................................... 20 9.11 IPSec: MTU size in OMS, CA Server and LDAP Server to be reduced to 1400 Bytes .......................................... 20 9.12 IPSec PROTECT / BYPASS Policies Definition ..................................................................................................... 20 9.13 ICMP Rate Limiting ................................................................................................................................................ 20 9.14 LTE574 IP Transport Network Measurements: Configuration of UDP Port number of TWAMP Responder .......... 21 9.15 Date/Time in Transmission Alarms is misleading in BTS Site Manager ................................................................. 21 9.16 Import new MRBTS SW to NetAct ......................................................................................................................... 21 9.17 Automatic Synchronization with NetAct after Upgrade of eNB ............................................................................... 22 9.18 LTE523 Multi-layered Certificate Authorities: Slash character not supported as subject name element separator ............................................................................................................................................................................ 22 9.19 BTS booted due to TRS power on reset during FSMF upgrade ............................................................................ 23 9.20 TRS not commissioned, eNB Re-commissioning possible only after 12 Minutes after Start-Up ............................ 23 9.21 RF Sharing: Upgrade first the Master Technology ................................................................................................. 23 9.22 Recommendations for RF Sharing WCDMA-LTE dual band configurations .......................................................... 23 9.23 RF Sharing WCDMA-LTE Synchronization ............................................................................................................ 23 9.24 RF sharing WCDMA-LTE with FSMF on LTE side ................................................................................................. 23 9.25 Don’t configure WCDMA-LTE RF Sharing in use if shared BTS site doesn’t contain WCDMA System Module .... 27 9.26 MHA/RET settings - ReadOnly field ....................................................................................................................... 27 9.27 Change of RX level calculation procedure for Vegas and Reno RF Variants ........................................................ 27 9.28 BTS Site Browser behavior change for TRS parameters between RL60 and RL70 .............................................. 28


9.29 Workaround for alarm 1836: EFaultId_ALOvercurrentAl ........................................................................................ 28 9.30 Rules for commissioning of passive / virtual MHA ................................................................................................. 28 9.31 TRS becomes un-commissioned after adding address set for 2nd operator ......................................................... 29

10 Checking of the package consistency ......................................................................................................... 29 11 Fallback ....................................................................................................................................................... 29

11.1 Flexi Multiradio BTS LTE Operator Hints ............................................................................................................... 29 11.1.1 HW configuration changes .............................................................................................................. 29 11.1.2 New HW not supported by previous SW Version ............................................................................ 29

11.2 Flexi Zone BTS Operator Hints .............................................................................................................................. 29 11.2.1 Manual Rollback to factory load is not supported ............................................................................ 29

12 Appendices / References ............................................................................................................................ 29 Contact

Contact your local Nokia Solutions and Networks support

Summary of changes:

09-Sep-2015 1.0 Approved version


1 PURPOSE

The purpose of this document is to describe the actions needed for installing and or upgrading this Release Delivery into the customer’s network. It contains common Operator Hints that have to taken in account during and after installation/upgrade.

2 OVERVIEW

This document covers Installation Instruction Flexi Multiradio BTS LTE (eNB), Flexi Zone BTS (eNB) and LTE iOMS. Standard installation instructions are available in the Customer Documentation library accessible through NOLS [1] at: Nokia Long Term Evolution Information Center [4] It is required to carefully study content of the library and follow on detailed procedures described in the documents. It will be specified in this document which instruction should be used for installation of certain entity, all exceptions from base procedure will be listed in this document. During the execution of the procedure user will be asked to stop following the official Customer. Documentation and execute steps mentioned here. How to access Customer Documentation is described in point 2.1.

2.1 Other Relevant Installation Instructions

All LTE Customer Documentation, including standard installation procedures, is accessible through NOLS [1] in the section “Product Information Center” Nokia Long Term Evolution Information Center [4] It is very important to check if new Change Deliveries are available – they may contain newer version of the documents.

3 PREPARATIONS

1. Hardware used for the installation should be integrated according to the hardware installation guide and all necessary cabling should be already done. Necessary documents can be found in the section “Install and commission” in the Customer Documentation library

• For the Flexi Multiradio BTS LTE reference documents are named “Installing Flexi Multiradio BTS LTE…” [2]

• For the FlexiZone BTS reference document is named “Installing and Cabling Flexi Zone Micro BTS” [2]

2. To enable usage of SON features some preparation steps must be taken. It is described in Customer Documentation library in section “Functional Area Description-Operability-Configuration Management-SON management” chapter 4 “Functional description for SON management” [5].

https://online.portal.nsn.com/pic/gateway/finder


4 MAKING A SAFE COPY OF THE ACTIVE PACKAGE

N/A

5 SW DOWNLOADING INSTRUCTIONS

The software for the released products is available in NOLS.

• Flexi Multiradio BTS LTE:


Software Item Software File Name SHA1 check sum


8A6716FBB2C45C12A92E2B806108D72E73859266


1CFC9BB8DA9FD5B6D635D177B5CE0552604FBF2A


3471F00187450A960C6BF315A7006CFC74ACB49A

After downloading the software it is important to generate SH1 checksum for files and compare it with the one provided in the Summary of Corrections and Enhancements document, this will ensure that the files were not corrupted during downloading.

• Flexi Zone BTS:


Software Item Software File Name SHA1 check sum

BTS Site Manager LNF7.0_BTSSM_1407_072_00.ZIP

69a6f27505a92b21649887810f8e5c630dbc83ec


3DCF7F8BDB4918CB87F64917BC663271C186FCB2


3974C70381A4BFD0FF5120EB3AAE338BF5CB2DE5

After downloading the software it is important to generate SH1 checksum for files and compare it with the one provided in the Summary of Corrections and Enhancements document, this will ensure that the files were not corrupted during downloading.

6 SPECIAL CONDITIONS


iOMS7.0 has to be updated first to corr35 before eNB update to RL70 1.2 SW build will be done. FHCA 472169A.103 product (FPGA) should be used in max. 2*20W DL power. This firmware must only be used under the following conditions: 20W mode -40 to +50 degrees. FRGP should be used in 2*15W DL power.

https://online.portal.nsn.com/SWD/




6.2 Flexi Zone BTS

6.2.1 Supported Configurations for Flexi Zone BTS Parameter Value Comments Macro/Micro Frequency F1/F1 or F1/F2 Channel Bandwidth 5 MHz, 10 MHz, 15 MHz & 20 MHz Note that it is possible for the

macro and the Micro to be on different channel bandwidths at the same time. For example : It is possible for the macro to be on 10 MHz and Micro to be at 15 MHz.

Transmit Power 250 mW – 5 W Per Branch Antenna Type Omni or Directional It is expected that the Micro

networks will be a mix of OMNI and Directional antennas.

Mode FDD

6.2.2 Supported Hardware

Flexi Zone BTS supports two Hardware Versions: X22 and A101 and following frequency variants: FWEA BC3 Flexi Zone BTS FDD LTE 1800 MHz FWFA BC25 Flexi Zone BTS FDD LTE 1900 MHz FWGB BC1 Flexi Zone BTS FDD LTE 2100 MHz FWIB BC4 Flexi Zone BTS FDD LTE 1700/2100 MHz FWHA BC7 Flexi Zone BTS FDD LTE 2600 MHz Full Band FWHN BC7 Flexi Zone BTS FDD LTE 2600 MHz High Band FWHO BC7 Flexi Zone FDD LTE 2600 MHz Low Band FWHC Flexi Zone Enhanced BTS 2600 (Band 7, Low Band) FWHG Flexi Zone Indoor Pico BTS 2600 (Band 7) FWHH Flexi Zone Indoor Pico BTS 2600 (Band 7) with Integrated WiFi FWIC Flexi Zone Indoor Pico BTS AWS (Band 4) with Integrated WiFi

6.3 RF-Sharing

RL70 1.2 has the same RF-sharing compatibility as RL70 1.0 SW. 6.3.1 LTE-GSM RF Sharing

The released GSM BTS SW versions for RF Sharing with RL70 1.0 SW are EX5_2 (RG40) for ESMB/C and GF1 (RG40) for FSMF according to the table below. It is recommended to use the latest released GSM SW i.e. EX5_2 2.0/GF1 1.1.0 For GSM ESMB/C system module:

RG30 EP1

RG40

EX5.1 P8

EX5.1 1.0.1

EX5.1 2.0.0

EX5.1 3.0.0

EX5.1 3.1.0

EX5_2 P8

EX5_2 1.1

EX5_2 2.0


RL70 LN7.0 P8 NC NC NC NC NC NC REC. Rel.

LN7.0 1.0 NC NC NC NC NC NC Rel. REC.

For GSM FSMF system module:

RG40

GF1 P8

GF1 1.0.0

GF1 1.1.0

RL70 LN7.0 P8 NC NC NC

LN7.0 1.0 NC NC REC.

Rel. SW combination released REC. SW combination recommended NC not compatible For details on supported configurations, such as: power levels, antenna configuration types, requirements, bands, and so on, please see excel file "Flexi Multiradio BTS RF Sharing Released Configurations", DN09123381, latest issue in NOLS [9]. Release Upgrade Instructions - Project upgrade The following upgrade paths in case of GSM-LTE RF Sharing are recommended (for RL70): LN6.0 P8/EX5.1 2.0.0 to LN7.0 1.0/EX5_2 2.0 * LN6.0 1.0/EX5.1 3.0.0 to LN7.0 1.0/EX5_2 2.0 LN6.0 2.0/EX5.1 3.1.0 to LN7.0 1.0/EX5_2 2.0 LN6.0 3.0/EX5.1 3.1.0 to LN7.0 1.0/EX5_2 2.0 LN7.0/EX5_2 1.1 to LN7.0 1.0/EX5_2 2.0 NOTE: For upgrades to LN7.0 or higher, the GSM SW shall be first upgraded to EX5_2 1.1 or higher due to limitations in SW compatibility. NOTE: * due to SW compatibility limitations of RL70 and RG30 EP1 pair - 3 step upgrade needed (first LTE to RL60 MP1 or higher then GSM to RG40 and finally LTE to RL70) or both technologies need to be upgraded in the same maintenance window. For all other upgrade paths, it is recommended to first upgrade the master technology (i.e. LTE) as the SW management of Radio Modules in RF sharing is done via the master System Module only.

6.3.2 WCDMA-LTE RF Sharing

The released WCDMA BTS SW for RF Sharing with RL70 1.0 SW are WN8.0 (RU40) and WN9.1 (RU50 EP1) according to the table below. It is recommended to use the latest released WCDMA SW, i.e. WN9.1 2.0.

RL70

LN7.0 P8 LN7.0 1.0

RU40 WN8.0 1.0 NC NC

WN8.0 2.1 NC NC


WN8.0 3.0 NC NC

WN8.0 4.0 NC NC

WN8.0 5.0 NC NC

WN8.0 6.0 Rel. Rel.

RU50 WN9.0 P8 NC NC

RU50 EP1

WN9.1 P8 NC NC

WN9.1 1.0 REC. Rel.

WN9.1 2.0 Rel. REC.

Rel. SW combination released REC. SW combination recommended NC not compatible For details on supported configurations, such as: power levels, antenna configuration types, requirements, bands and so on, please see excel file "Flexi Multiradio BTS RF Sharing Released Configurations", DN09123381, latest issue in NOLS [9]. Release Upgrade Instructions - Project upgrade The following upgrade paths in case of WCDMA-LTE RF Sharing are recommended (for RL70 SW): WN8.0 1.0/LN5.0 to WN9.1 2.0/LN7.0 1.0 SW * WN8.0 2.1/LN5.0 to WN9.1 2.0/LN7.0 1.0 SW * WN8.0 3.0/LN5.0 2.0 to WN9.1 2.0/LN7.0 1.0 SW * WN8.0 4.0/LN6.0 1.0 to WN9.1 2.0/LN7.0 1.0 SW WN8.0 5.0/LN6.0 2.0 to WN9.1 2.0/LN7.0 1.0 SW WN8.0 6.0/LN6.0 3.0 to WN9.1 2.0/LN7.0 1.0 SW WN9.1 1.0/LN7.0 to WN9.1 2.0/LN7.0 1.0 SW NOTE: For upgrades to WN8.0 4.0 or higher, the LTE SW shall be first upgraded to LN6.0 due to limitations in SW compatibility. NOTE: * due to SW compatibility limitations of RL70 and RU40 pair - 3 step upgrade needed (first LTE to RL60 then WCDMA to RU50 EP1 and finally LTE to RL70) or both technologies need to be upgraded in the same maintenance window. For all other upgrade paths, it is recommended to first upgrade the master technology (i.e. WCDMA) as the SW management of Radio Modules in RF sharing is done via the master System Module only.

6.4 COMPATIBILITY MATRIX

6.4.1 Flexi Multiradio BTS LTE

SW delivery Flexi Multiradio BTS LTE BTSSM LTE iOMS

NetAct

Delivery/Release BTSSM in NetAct

RL70 LN7.0_ENB_1407_555_05

LN7.0_BTSSM_1407_095_00

R_GOMS7_1.3.2.0_corr29

NetAct 15.2 + PP317

LN7.0_BTSSM_1407_095_00


RL70 0.1 LN7.0_ENB_1407_556_54

LN7.0_BTSSM_1407_095_01


NetAct 15.2 + PP317

LN7.0_BTSSM_1407_095_00

RL70 0.2 LN7.0_ENB_1407_557_36

LN7.0_BTSSM_1407_095_02


NetAct 15.2 + PP317

LN7.0_BTSSM_1407_095_00

RL70 1.0 LN7.0_ENB_1407_563_13

LN7.0_BTSSM_1407_106_00


NetAct 15.2 + PP317

LN7.0_BTSSM_1407_095_00

RL70 1.1 LN7.0_ENB_1407_570_77

LN7.0_BTSSM_1407_107_00


NetAct 15.2 + PP317

LN7.0_BTSSM_1407_095_00

RL70 1.2 LN7.0_ENB_1407_572_04

LN7.0_BTSSM_1407_107_00


NetAct 15.2 + PP317

LN7.0_BTSSM_1407_095_00

6.4.2 Flexi Zone BTS

SW delivery Flexi Zone BTS BTSSM LTE iOMS

NetAct

Delivery/Release BTSSM in NetAct

RL70 LNF7.0_ENB_1407_136_03

LNF7.0_BTSSM_1407_060_

00


NetAct 15.2 + PP317

LNF7.0_BTSSM_1407_060_

00

RL70 0.2 LNF7.0_ENB_1407_137_11

LNF7.0_BTSSM_1407_063_

00


NetAct 15.2 + PP317

LNF7.0_BTSSM_1407_060_

00

RL70 1.0 LNF7.0_ENB_1407_145_06

LNF7.0_BTSSM_1407_068_

00


NetAct 15.2 + PP317

LNF7.0_BTSSM_1407_060_

00

RL70 1.2 LNF7.0_ENB_1407_150_14

LNF7.0_BTSSM_1407_072_

00

R_GOMS7_1.3.2.0_corr35 NetAct 15.5 MP1

LNF7.0_BTSSM_1407_072_

00

7 DATA MIGRATION

N/A


8 RELEASE DELIVERY UPGRADE INSTRUCTIONS


8.1.1 First installation and commissioning

The commissioning procedure of the Flexi Multiradio BTS LTE is described in the document “Commissioning Flexi Multiradio BTS LTE” [3]. Please be aware that BTS Site Manager shall be updated before the BTS SW.

8.1.2 Project upgrade

System upgrade is described in customer documentation "LTE System Upgrade" [7].

8.1.2.1 Supported Update/Upgrade Paths RL70 • RL70 1.1 (LN7.0_ENB_1407_570_77) -> RL70 1.2 (LN7.0_ENB_1407_572_04) • Customer specific RL70 0.2.6 (LN7.0_ENB_1407_558_27) -> RL70 1.2

(LN7.0_ENB_1407_572_04) • RL70 0.2 (LN7.0_ENB_1407_557_36) -> RL70 1.2 (LN7.0_ENB_1407_572_04)

RL60 • RL60 3.1 (LN6.0_ENB_1311_907_18) -> RL70 1.2 (LN7.0_ENB_1407_572_04) • RL60 3.0 SW (LN6.0_ENB_1311_905_12) -> RL70 1.2 (LN7.0_ENB_1407_572_04) • RL60 1.1 SW (LN6.0_ENB_1311_764_08) -> RL70 1.2 (LN7.0_ENB_1407_572_04) • RL60 1.0 SW (LN6.0_ENB_1311_731_01) -> RL70 1.2 (LN7.0_ENB_1407_572_04)

RL50 • RL50 2.3 (LN5.0_ENB_1304_797_00) -> RL70 1.2 (LN7.0_ENB_1407_572_04) • RL50 1.0 (LN5.0_ENB_1304_695_31) -> RL70 1.2 (LN7.0_ENB_1407_572_04)

8.1.2.2 Recommended pause between eNB startup and recommissioning

In case of sites with complex HW configurations (e.g. FSMF+2xFBBC+2xFRLB+3xFRIG, chaining + Carrier Aggregation) and with installed LN7.0 SW, it is recommended to wait after eNB startup (ON-AIR state) minimum one minute before the recommissioning (requiring eNB reset) is done. It will ensure that all procedures, operations and SW updates are finalized properly. Otherwise the ongoing postprocessing activities may be interrupted which may cause the eNB operability problems. In case of sites with FBBC modules and using EXT3 optical port, an additional automatic reset is needed during SW Upgrade from RL50/RL60 to RL70 SW. eNB startup will extend from around 8 min to 12 min due to reset of FBBC modules.

8.1.2.3 RL70 PUCCH Dimensioning Change before Upgrade

Due to changes introduced in RL70 and missing check implementation in RL60 following changes shall be done prior the upgrade of the SW from RL50/60 to RL70. What has been changed: During migration from RL50 or RL60 SW to a newer SW Release version, the parameter actCompChecks in class LNBTS is changed from value ‘true’ to ‘false’ What was wrong: (1) In RL60 only the description of the parameter maxNumActUE in the delivered RNL pdf-

parameter documentation included following limitation:


Dependencies: maxNumActUE + max(addAUeRrHo, addAUeTcHo) must be less than the margin values for the used bandwidth (see values above (480,600,1030,1200)) Starting with RL70 this is implemented as semantic check in maxNumActUE maxNumActUE + max(addEmergencySessions, addAUeRrHo, addAUeTcHo) value should be lesser/equals to upper bandwidth limit

(2) In RL60 the defined parameter relationship in parameter maxNumRrc (class LNCEL) which has been used in validation was to general: (1.3) if actHighRrc set to 'false', maxNumRrc value range is restricted to 0...840 This lead for a cell bandwidth of 15 MHz that an higher value is possible to be configured than should have been allowed. In RL70 the limitation is corrected as defined below if actHighRrc set to 'false' and - min(ulChBw,dlChBw) is '15 MHz', maxNumRrc value range is restricted to 0...720

(3) In RL60 the defined parameter relationship in parameter maxNumRrc (class LNCEL) which has been used in validation is extended due to LTE1803 and considers further separation for SRS and deltaPucchShift value definition: (4.1) applicable for riEnable set to 'true' - maxNumRrc + max (addAUeRrHo,addAUeTcHo) <= n1PucchAn * cellSrPeriod (4.2) applicable for riEnable set to 'true' AND riPerM set to '2' - maxNumRrc + max (addAUeRrHo,addAUeTcHo) <= (nCqiRb - blankedPucch) * 6 * cqiPerNp (4.3) applicable for riEnable set to 'true' AND riPerM set to '1' - maxNumRrc + max (addAUeRrHo,addAUeTcHo) <= (nCqiRb - blankedPucch) * 6 * cqiPerNp/2 Has been further split into SRS and MIMO aspects in the configuration in RL70 (4.1) applicable for deltaPucchShift=1 AND (4.1.1) ... srsConfiguration is configured to any value /*SRS support*/ - maxNumRrc + max (addAUeRrHo,addAUeTcHo) <= n1PucchAn * cellSrPeriod – 6*cellSrPeriod/5*n1PucchAn/36 (4.1.2) ... srsConfiguration is NOT configured /*no SRS support*/ - maxNumRrc + max (addAUeRrHo,addAUeTcHo) <= n1PucchAn * cellSrPeriod (4.2) applicable for deltaPucchShift<>1 - maxNumRrc + max (addAUeRrHo,addAUeTcHo) <= n1PucchAn * cellSrPeriod (5) MIMO mode related checks: (5.1) applicable for riEnable set to 'false' /*no MIMO support*/ - maxNumRrc + max (addAUeRrHo,addAUeTcHo) <= (nCqiRb - blankedPucch) * 6 * cqiPerNp (5.2) applicable for riEnable set to 'true' AND riPerM set to '2' /*MIMO support*/ - maxNumRrc + max (addAUeRrHo,addAUeTcHo) <= (nCqiRb - blankedPucch) * 6 * cqiPerNp (5.3) applicable for riEnable set to 'true' AND riPerM set to '1' /*MIMO support*/ - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= (nCqiRb - blankedPucch) * 6 * cqiPerNp/2

(4) In RL60 the defined parameter relationship in parameter maxNumRrc (class LNCEL) which has

been used in validation is extended due to LTE1803 and considers further separation for SRS and deltaPucchShift value definition as mentioned in the previous case for carrier aggregation configurations: (5.1) applicable for riEnable set to 'true' AND - n1PucchAn is not set to '10' : maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= min((nCqiRb - blankedPucch) * 6 * cqiPerNp/2, (n1PucchAn – 48) * cellSrPeriod)


- n1PucchAn is set to '10' : maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= min((nCqiRb - blankedPucch) * 6 * cqiPerNp/2, 2 * cellSrPeriod) (5.2) applicable for riEnable set to 'false' AND - n1PucchAn is not set to '10' : maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= min((nCqiRb - blankedPucch) * 6 * cqiPerNp, (n1PucchAn – 36) * cellSrPeriod) - n1PucchAn is set to '10' : maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= min((nCqiRb - blankedPucch) * 6 * cqiPerNp, 6 * cellSrPeriod) Has been further split into SRS and MIMO aspects in the configuration in RL70 (6.1) If riEnable is set to 'true' AND n1PucchAn <> 10 AND deltaPucchShift=1 AND (6.1.1) … srsConfiguration is configured to any value all of the following conditions must be fulfilled: - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= ((nCqiRb - blankedPucch) - (maxNumScells -1)) * 6 * cqiPerNp/2 - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= (n1PucchAn – 48) * cellSrPeriod – 6 * cellSrPeriod/5 * n1PucchAn/36 (6.1.2) … srsConfiguration is NOT configured all of the following conditions must be fulfilled: - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= ((nCqiRb - blankedPucch) - (maxNumScells -1)) * 6 * cqiPerNp/2 - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= (n1PucchAn – 48) * cellSrPeriod (6.2) If riEnable is set to 'true' AND n1PucchAn <> 10 AND deltaPucchShift<>1 all of the following conditions must be fulfilled: - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= ((nCqiRb - blankedPucch) - (maxNumScells -1)) * 6 * cqiPerNp/2 - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= (n1PucchAn – 48) * cellSrPeriod)

(6.3) If riEnable is set to 'true' AND n1PucchAn = 10 all of the following conditions must be

fulfilled: - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= ((nCqiRb - blankedPucch) - (maxNumScells -1)) * 6 * cqiPerNp/2 - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= (2 * cellSrPeriod) (6.4) If riEnable is set to 'false' AND n1PucchAn <> 10 AND deltaPucchShift=1 AND (6.4.1) … srsConfiguration is configured to any value all of the following conditions must be fulfilled: - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= ((nCqiRb - blankedPucch) - (maxNumScells -1)) * 6 * cqiPerNp - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= (n1PucchAn – 36) * cellSrPeriod) – 6 * cellSrPeriod/5 * n1PucchAn/36 (6.4.2) … srsConfiguration is NOT configured all of the following conditions must be fulfilled: - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= ((nCqiRb - blankedPucch) - (maxNumScells -1)) * 6 * cqiPerNp - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= (n1PucchAn – 36) * cellSrPeriod) (6.5) If riEnable is set to 'false' AND n1PucchAn <> 10 AND deltaPucchShift<>1 all of the following conditions must be fulfilled: - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= ((nCqiRb - blankedPucch) - (maxNumScells -1)) * 6 * cqiPerNp - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= (n1PucchAn – 36) * cellSrPeriod) (6.6) If riEnable is set to 'false' AND n1PucchAn = 10 all of the following conditions must be fulfilled: - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= ((nCqiRb - blankedPucch) - (maxNumScells -1)) * 6 * cqiPerNp - maxNumRrc + max(addAUeRrHo,addAUeTcHo) <= 6 * cellSrPeriod

What needs to be done:


1. In RL60 the configuration of the eNB shall be modified that all above mentioned conditions are fulfilled in RL60.

2. After the installation of the new SW release version, the parameter actCompChecks in class LNBTS shall be changed to ‘true’ to assure a semantically correct configuration. If validation error are displayed those shall be corrected based on the provided information.

8.1.2.4 No HW configurations changes during SW upgrade HW configuration changes should not be done during SW upgrade as this may lead to inconsistencies in the internal configuration files. Changes in configurations should either be executed before SW upgrade or after SW upgrade. In case the changes have been executed before SW upgrade a SW fallback will keep the configuration changes. In case the configuration change will be done directly after SW upgrade and then a SW fallback will be initiated, the changed configuration may lead to start up problems with former SW. Reason would be that the internal configuration file of pre-upgrade will be used and this may not match the changed configuration.

8.1.2.5 CM Upload must be executed after eNB upgrade in case Automatic Synchronization

with NetAct is not enabled After the upgrade of an eNB is executed a CM Upload with CM Operation Manager must be executed to synchronize the eNB database with NetAct in case Automatic Synchronization with NetAct is not enabled. For more information please see at chapter 8 “Operational Hints and Recommendations” the section “Automatic Synchronization with NetAct after upgrade of eNB“.

8.1.2.6 Double entries of LNADJG and LNHOIF in RL50 In RL50 it is not forbidden to have duplicated entries of LNADJG or LNHOIF. In RL70 there are stricter rules which doesn’t allow this anymore: LNADJG: “The combination of mcc, mnc, mncLength, gTargetLac and gTargetCi must be unique within all LNADJG instances of the eNB.” LNHOIF: “eutraCarrierInfo must be unique in scope of the LNCEL instance and it need to be different to the earfcnDL of the superior LNCEL”. When upgrading from RL50 to RL70 this duplicated entries are not deleted automatically, because the upgrade procedure cannot decide which of these duplicated entries should be deleted. After an upgrade the eNB is on Air but when the next commissioning via NetAct or BTSSM is executed, the system will detect this conflict and the commissioning will be rejected with a warning indicating to this conflict. After upgrade the operator has to delete the double entries via NetAct or BTSSM so LNADJG and LNHOIF is unique. Note: CM tool provides a rule for CM Analyzer which can be used in order to identify duplicate entries for deletion.

8.1.2.7 Recommended values for LNCEL/ Intra- and inter-frequency load balancing common load settings /targetLoadPdcch for Macro and Small Cell in eICIC mode

New Intra- and inter-frequency load balancing common load settings --targetLoadPdcch should be set to default=90% Old: targetLoadPdcch: 50% Reason: Smaller values cause unnecessary muting pattern changes towards MP0 in eICIC macro. In eICIC small cell it is recommended to set new default value 90% in order to avoid reporting the cell as overloaded due to lack of PDCCH resources.


8.1.2.8 phyCellIdRange must be empty before Upgrade

phyCellIdRange (blacklistHoL) ==noRange(14) is not supported in RL70 and migration rule is not implemented yet. Upgrade LTE BTS with this value phyCellIdRange (blacklistHoL) ==noRange(14) will cause a software fallback. Workaround: Before Upgrade set parameter phyCellIdRange (blacklistHoL) to an empty value.

8.1.2.9 SCF Validation failure If after upgrade BTSOM SCF Validation fails e.g. a mandatory parameter is missing system module of eNB will execute a fallback to previous build. An alarm SW fallback (4083) will be raised and additionally RF and transport module will have incompatible SW. Due to this incompatible SW NetAct will start an additional update to this previous SW to get RF and transport to the same SW as system module and after this eNB will be onAir.

8.1.2.10 Configurations with Base Band Extension Modules

• Make backup commissioning from complete RL60 configuration. • Upgrade eNB from RL60 to RL70. • In some cases it may be necessary that an additional manual reset by operator is necessary.

8.1.2.11 ‘actOTN Recovery’ to be set to ‘false’ before Upgrade to RL70 Parameter ‘actOTNRecovery’ has to be set to “false” in RL60 before upgrading to RL70.as functionality is not yet supported in RL70.

8.2 Flexi Zone BTS

8.2.1 First installation and commissioning The commissioning procedure of the FlexiZone BTS is described in the document “Commissioning Flexi Zone Micro BTS LTE” [3]. Please be aware that BTS Site Manager shall be updated before the BTS SW.

8.2.2 Project Update/Upgrade

Supported upgrade paths to RL70 1.2 (FZM is commissioned) RL50FZ:

• RL50FZ 2.1.1PD SW (LNF5.0_ENB_1304_161_01) → RL70 1.2 (LNF7.0_ENB_1407_150_14) • RL50FZ SW (LNF5.0_ENB_1304_163_00) → RL50FZ 0.1 SW (LNF5.0_ENB_1304_168_00) → RL50FZ 0.2

SW (LNF5.0_ENB_1304_174_00) → RL70 1.2 (LNF7.0_ENB_1407_150_14) • RL50FZ 0.1 SW (LNF5.0_ENB_1304_168_00):

if passive SW = RL50FZ (LNF5.0_ENB_1304_163_00) then upgrade path is RL50FZ 0.1 SW → RL50FZ 0.2 SW → RL70 1.2 LNF5.0_ENB_1304_168_00 → LNF5.0_ENB_1304_174_00 → LNF7.0_ENB_1407_150_14

if passive SW != RL50FZ (LNF5.0_ENB_1304_163_00) then upgrade path is RL50FZ 0.1 SW → RL70 1.2 LNF5.0_ENB_1304_168_00 → LNF7.0_ENB_1407_150_14

• RL50FZ 0.2 SW (LNF5.0_ENB_1304_174_00) → RL70 1.2 (LNF7.0_ENB_1407_150_14) RL70FZ:

• RL70 SW (LNF7.0_ENB_1407_136_03) → RL70 1.2 (LNF7.0_ENB_1407_150_14) • RL70 0.2 (LNF7.0_ENB_1407_137_11) → RL70 1.2 (LNF7.0_ENB_1407_150_14) • RL70 1.0 (LNF7.0_ENB_1407_145_06) → RL70 1.2 (LNF7.0_ENB_1407_150_14)


• Customer specific RL70 0.2.10 (LNF7.0_ENB_1407_139_06) → RL70 1.2 (LNF7.0_ENB_1407_150_14)

Supported Upgrade Paths from FACTORY LOADS (FZM is NOT commissioned) RL50FZ

• LNF5.0_ENB_1304_169_00 → RL70 1.2 (LNF7.0_ENB_1407_150_14) RL70FZ

• LNF7.0_ENB_1407_105_10 → RL70 1.2 (LNF7.0_ENB_1407_150_14) • LNF7.0_ENB_1407_140_20 → RL70 1.2 (LNF7.0_ENB_1407_150_14) • LNF7.0_ENB_1407_140_22 → RL70 1.2 (LNF7.0_ENB_1407_150_14)

IMPORTANT NOTE: Uncomissioned upgrade from RL50FZ factory-installed loads will fail if OMS IP is not properly

configured on the DHCP server

Uncomissioned upgrade from RL50FZ factory-installed loads will fail if OMS IP is not properly configured on the DHCP server. As the autoconnection is always toggling, TRSW is always busy in preparing a file download, hence a SW download request is rejected. BTSOM component receives AER message with Nackreason "busy". Workarounds:

• The DHCP server must be configured with IP of compatible and working dedicated OMS server during uncommisioned upgrade from RL50FZ factory-installed load.

Note that issue is not visible when: • DHCP server is turned OFF • FZM backhaul cable is disconnected from the rest of network (inc.DHCP)

There is an issue with transformation function in RL70 SW that transform IPSEC managed object. When

SW upgrade from RL50FZ to RL70 is performed then the remoteNetmask from RL50FZ is not adapted to remoteIpPrefixLength in RL70. In consequence the TRS become uncommissioned. Workaround: Use BTS SM for TRS reconfiguration after upgrade to RL70. Manually enter remoteNetmask into each IPsec policy. Reference: NA05785573: NPI RL70FZ: After RL70FZ upgrade netmask of remote network in each IPsec policies is missing (see CN-id: LNF7.0_00102)

Upgrade from RL50FZ P8 contains two intermediate steps which require RL50FZ 0.1 & RL50FZ 0.2 installation. Upgrade from RL50FZ 0.1 when passive SW= RL50FZ P8 also contains single intermediate step which requires RL50FZ 0.2 installation. This is a known issue related to RL50FZ P8 load and already fixed in the RL50FZ 0.2 and RL70 (and higher) load. Additional workarounds not needed.

Flexi Zone BTS may reset additional one time after upgrade from RL50FZ. It is caused by RL50FZ SW and may lengthen the time necessary for eNB to come into service about 60s. This is known issue fixed in RL70 (and higher). Additional workarounds not needed.

Flexi Zone BTS may reset additional one or two times after upgrade to intermediate load (when

upgrading from factory load LNF7.0_ENB_1407_059_00). This is known issue and no additional workarounds are needed.

When a site is in uncommissioned state and a user tries to upgrade using BTS Site Manager while

connected via the LMP, there is a small chance that site manager connectivity drops and the user has to attempt the upgrade again. Plug and Play procedure is not impacted. Once Transport is commissioned (auto-connection and/or auto-configuration triggered by NetAct), that problem goes away and the user can use the LMP for upgrades w/o issues.


NOTE: The issue is not visible while connected via Bluetooth.

Checking active/passive SW version:

Net Act: Software Manager Network Status MO type:”MRBTS” -> Select your MRBTS -> Synchronize

8.3 SON

SON is a set of features which enables operator to configure base station by connecting it to the network. To enable usage of SON facilities some preparation steps must be taken. It is described in Customer Documentation library in section “Functional Area Description-Operability-Configuration Management-SON management” chapter 4 “SON management” [5]. Descriptions and hints about SON feature usage can be found also in Customer Documentation for iSON Manager.

IMPORTANT NOTE: If operator is deploying the RL70 release using the auto connection/configuration process for FZM(s), which has RL50FZ SW active, the plan validation failure can be seen in the Netact CM Operations Manager during Auto configuration process. For more details & workaround instructions please refer to TSN: TS-BTS-SW-0007.

9 GENERAL OPERATOR HINTS

9.1 Debug flags (R&D flags) in swconfig.txt

Usually no R&D flags should be active in field eNBs. However, for those eNBs where R&D flags are necessary for logging, from eNB build LN7.0_ENB_1407_506_69 onwards the debug flag 0x010041 must be set to value 5 (instead of the previous value 1). This can be done either via modification of swconfig.txt (followed by an eNB reboot) or with the usual CLI commands (online modification). Background: Starting from load LN7.0_ENB_1407_506_69 the setting for flag 0x010041 = 1 has changed its meaning! This setting generates a flood of trace messages which results in poor eNB performance and in certain cases even makes O&M access impossible. Please check every eNB for 0x010041 = 1 before upgrading to RL70 SW and modify the value to 0x010041 = 5 or deactivate the flag.

9.2 Up to 3 resets excuted on FSMF Upgrade

After upgrade of FSMF up to 3 resets are executed. First reset is ApplicationReset. A second reset is necessary, because there is firmware update and this needs a reset. A third reset will be executed when the domain-id is changed. This results in an outage of about 10 minutes.


9.3 FSMx SW upgrade to RL70 1.2 with Factory SW

NOTE: The eNB needs to be uncommissioned with only iOMS connectivity. In other case the SW upgrade from factory SW to RL70 1.2 will fail. FSME with factory SW LN3.0_ENB_1103_771_02, what is the upgrade path here towards RL70? Direct upgrade to latest RL7.0 1.0 is possible. For example, LN3.0_ENB_1103_771_02 -> LN7.0_ENB_1407_572_04. Note: There may be issues with SSH(Ethernet security port) automatically enabled after startup; ping lost and no UDP print as a result. The workaround for this is to disable the Ethernet security port with flags (shown in Step 1) in swconfig.txt(see 0x30000F=1 flag below). The SW config file has to be created before SW upgrade is initiated. SW update:

Step 1: Add flags to swconfig.txt and FTP it to the folder /config under the active file system (fs) E.g. fs1/config/swconfig.txt (since it a new system, fs1 is most likely to be the active file system)

#FCT UDP logs enable(no SWDL print without these flags) 0x10041=2 #for FSMr2 0x10041=5 #for FSMr3 #Info model (IM) enabled 0x3A0001=1 #Port Security disabled (SSH) or can be disabled via BTS EM (flag will no longer needed when fix is available for PR 127786ESPE04: LBT2793 / CRL6008- BTS HW view cannot be generated with FTM(FTIB/FTLB) production SW) 0x30000F=1 #SCF validation switched off to prevent SW fallback – PR 121663ESPE04 0x300010=1

Step 2: After step 1, the eNB reset is necessary and afterwards the SW upgrade can be performed with RL7.0 1.2. After SW upgrade the swconfig.txt should be deleted. For R&N testing purposes, no need to delete swconfig.txt. FSMF HW version A.101 Some of these units (FSMF.101) still being delivered with older factory SW LN4.0_ENB_1202_475_03. This SW version (1202_475_03) does not have the supported uboot; therefore extra steps have to be taken in order to update to RL70 1.1. SW update path LN4.0_ENB_1202_475_03 -> LN4.0_ENB_1202_781_57 -> LN7.0_ENB_1407_572_04. Note: The exact update path must be followed or will result in a system crash. SW update steps: -If the FSMF.101 unit has SW version LN4.0_ENB_1202_475_03, 1-install BTS SITE Manager LTE4.0-1202_765_02 or any compatible BTSSM. 2-Disable “Ethernet security port” via BTSSM 3-perform SW update to LN4.0_ENB_1202_781_57. 4-From 1202_781_57, any newer SW build can be used; Hint RL70 can be used.


FSMF HW version A.102, A.103 ff: FSMF with current factory SW LN4.0_ENB_1202_781_57 The factory comes with the updated boot loader and can be upgraded directly to RL70. E.g. LN4.0_ENB_1202_781_57 -> LN7.0_ENB_1407_572_04. See technical note “TS-LTE_BTS_FDD-SW-0042_I1” FSMF with FDSW1.0 (boot-loader) can be upgraded directly to RL70 e.g. -> LN7.0_ENB_1407_572_04.

9.4 TRS commissioning

The delta plan file that is downloaded from NetAct side to eNB is in RAML2.1 format. eNB BTSOM expects unordered XML format, however TRS is requesting ordered XML format. BTS Site Manager for Transport configurations makes the ordering before the plan file is downloaded to eNB, however the parser in BTSOM does not consider the ordering and the file forwarded from BTSOM to TRS has a different ordering of MOCs. This leads to TRS commissioning errors. Dedicated MOCs must be in a special order, otherwise separate TRS delta plan files have to be used for recommissioning. Workaround: Operator shall configure problematic cases so that each plan file contains changes only for one MOC at a time and different plans are provisioned into network in correct order.

9.5 Redirection to ultraFDD supported only

Redirection is only supported to utraFDD. There is no feature ‘Redirection to utraTDD’. Nevertheless the value ‘utraTDD’ can be selected in instances of the managed object classes REDRT, MORED and MODRED. Please do not set parameter redirRAT to ‘utraTDD’ in REDRT, MORED and MODRED otherwise the related cell will not provide service and the alarm ‘Cell configuration data distribution failed' will be reported after upgrade to RL70.

9.6 Mast Head Amplifier FHLA: Validation error “Incorrect parameter: mhaGain” after upgrade to RL70

When the configuration contains MHA of type FHLA with version 103 and upgrade to RL70 is executed the validation with BTSSM will show a validation error “Incorrect parameter: mhaGain” and an alarm Antenna Line Device failure (1873). During the next reconfiguration via BTSSM mhaGain will be set automatically from 13.00 to 12.00. This requires a BTS reset. With NetACT mhaGain must be manually set from 13.0 to 12.0.

9.7 Juniper SEC-GW

While using Multi-Layered Certificates in combination with Juniper JUNOS 12.1x44-D23 as SEC-GW, IPsec Connections between eNB and SEC-GW are only possible if the used certificates for both devices are at the same branch and the same level of the Certificate Chain. Any other combination of different certificate level or branches for eNB and SEC-GW are not working.


With JUNOS 12.1X46-D10.2 and JUNOS 12.1X46-D20.5 the certificates may also be from different levels and branches. If eNB trust chain has a different Root CA, it is necessary to install as Trust Anchor in the GW not only the eNB RootCA but also the complete eNB trust chain including all intermediate CAs.

9.8 Checkpoint SEC-GW

Operation mode: Round robin for Ethernet interface on Checkpoint should be avoided as packet loss is observed with this setting in R&D Lab. Recommended setting for Ethernet interface operation mode configuration at Checkpoint to be set to LACP(802.3ad) . IKEv1: To work with IKEv1 one need to choose exclusively “IKEv1 only” mode in community level on CP. IKEv1: Multi tunnel configuration: Not released (Restriction for multi tunnel configurations due to CP offering of traffic selector of 0.0.0.0/0 0.0.0.0/0 (universal tunnel) and so no IPSec SA established.) Multi Layer Certificates: Multi Layer Certificates operation with Checkpoint is not released by Nokia Security organization.

9.9 Auto Connection and VLAN Scan Optimization

Cisco Interoperability for improved eNB AutoConnection Feature. The SON feature has been improved to be faster. In case of using VLANs at the transport configuration a VLAN scan functionality has been introduced with RL70. This feature will inspect all incoming packets to detect the VLAN IDs in use. Since this process speeds up the switching time between sending DHCP DISCOVER messages as plain frames and sending VLAN tagged messages, a change at the access router/switch has to be made if it is a Cisco device. By default a physical interface on Cisco is set to support “DTP – Dynamic Trunking Protocol” which is a proprietary protocol. If this is enabled it will try to detect configured trunks on the next hop once the port is up. It will block the VLAN IF to be up for 30sec. This will cause the DHCP negotiation to fail.


According to Cisco’s documentation this feature should be turned off if the next hop is not a Cisco product. Therefore configuration of the physical interface at Cisco router/switches should be as following:

----- Example ----- TT_Cisco#sh run int gi 3/11 Building configuration... Current configuration : 273 bytes ! interface GigabitEthernet3/11 description Gi 3/11 Temp AutoConnection switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 201 switchport mode trunk switchport nonegotiate logging event link-status spanning-tree portfast trunk end

9.10 LTE497 Smart Admission Control: Avoid GBR admission in empty cells fail

When 'Enhanced AC and GBR services' are activated, i.e. if ‘actEnhAcandGbrServices’ equals 'true', it is highly recommended to configure ‘gbrCongHandling’ to 'l2andl3'. If it not configured like this, GBR admission in empty cells may fail.

9.11 IPSec: MTU size in OMS, CA Server and LDAP Server to be reduced to 1400 Bytes

IPSec requires additional IP overhead. In case the default MTU size of 1500 Bytes is used, the IPSec Gateway needs to fragment the IP packets before encrypting is done. Some applications are setting the ‘don’t fragment’ bit, which is prohibiting the fragmentation, but in this case the IP packets are dropped and not transferred at all. In order to avoid this the MTU size of OMS, CA Server and LDAP Server shall be limited. For OMS:

fsipnet bond modify bond0 node CLA-0 mtu 1400 fsipreconfigure commit

9.12 IPSec PROTECT / BYPASS Policies Definition

For the configuration of IPSec policies in the eNB, the following rule needs to be considered. In case of several matching IPSec policies, the policy rule which shall be applied needs to have a lower number than the other matching policy. The lowest number of several matching policies is applied first. For example, if a wide-ranging PROTECT policy is defined (e.g. ANY-TO-ANY) and a dedicated traffic type shall bypass the IPSec tunnel, than the BYPASS policy needs to be configured with a lower ‘Policy Order Number’ than the protect policy.

9.13 ICMP Rate Limiting

In order to avoid a system outage due to DoS attacks (ICMP flood) the ingress and egress ICMP packet rates are limited. Only a burst of 8 ICMP_ECHO_REQUESTS / ICMP_ECHO_REPLY are allowed. If e.g. more than 8 ICMP_ECHO_REQUESTS are sent in a burst, eNB will only reply to the first 8. This is applicable for the eNB interface address(es) (Ethernet and VLAN).


9.14 LTE574 IP Transport Network Measurements: Configuration of UDP Port number of TWAMP Responder

Currently, the UDP port of the TWAMP Reflector can be freely configured in the range from 0 to 65535, with a default value of 5000. Free configuration of this parameter requires special care, since the entries may conflict with port numbers which are already assigned to other applications. E.g. the port numbers 0 … 1023 and 5001 … 5010 are reserved and must not be used for the TWAMP responder function. Currently, the system does not support a complete check of the configured TWAMP responder port number against all other port numbers used in the system. To avoid conflicts between the TWAMP UDP port number and other port numbers, it is recommended to always use the default value of 5000. It has been found that the flexibility in configuring the port number does not provide a real benefit, and using a fixed value eliminates the possibility of mis-configurations.

9.15 Date/Time in Transmission Alarms is misleading in BTS Site Manager

Date/time included in fault name of transmission alarms is misleading in BTS Site Manager. Same issue is correctly displayed in NetAct Alarm Monitor.

9.16 Import new MRBTS SW to NetAct

When a new MRBTS SW is imported to NetAct SW Archive the ‘Version ID’ and the ‘Package name’ should be set to the SW release version. By default the file name of the SW is entered. If the default name is used an automatic fallback via NE-triggered-SW-update wouldn’t work: Before import is executed, select ‘Details’


And enter in the fields ‘Version ID’ and ‘Package name’ the SW release version e.g. LN6.0_ENB_1311_114_00 as shown as example in the picture above and below.

9.17 Automatic Synchronization with NetAct after Upgrade of eNB

By default the feature LTE954 ‘Intelligent Configuration Synchronization’ is disabled in NetAct. If it is disabled data synchronization via CM Upload of NetAct must be executed manually after upgrade (the same way as it was in previous releases, e.g. after upgrade from RL40 to RL50). If it is enabled the automatic upload of the configuration data is not started immediately after upgrade, it is started after a configurable time interval. Furthermore there are situations when it is necessary to perform manually the data synchronization after upgrade even the feature is enabled. This can happen when the establishment of the OAM connection takes a long time, but the startup of the eNB is very quick, e.g. when eNB is configured with only one cell and OAM connection with IPSEC. When after upgrade the configuration data synchronization state is empty the eNB must be manually synchronized with NetAct. For more information about the configuration of the feature LTE954 ‘Intelligent Configuration Synchronization’ please refer to the documentation of LTE954.

9.18 LTE523 Multi-layered Certificate Authorities: Slash character not supported as subject name element separator

Manual key and certificate commissioning: BTS and eNB does not support slash ‘/’ as subject name element separator.


9.19 BTS booted due to TRS power on reset during FSMF upgrade

When FSMF upgrade requires FPGA version upgrade, during activation of new software, an additional power on reset occur after FPGA firmware update. Because of this reset, after software upgrade, BTS booted alarm due to TRS power on reset alarm will observed. Alarm can be ignored in this case.

9.20 TRS not commissioned, eNB Re-commissioning possible only after 12 Minutes after

Start-Up

If after resetting the eNB state is ‘BTS configured’ and ’TRS not commissioned’, eNB re-commissioning may fail due to ongoing RNW plan activation. Re-Commissioning will be successful after RNW plan activation will have finished (latest after 12 min timer expiry).

9.21 RF Sharing: Upgrade first the Master Technology

Unless otherwise stated, it is recommended to first upgrade the master technology (i.e. LTE) as the SW management of Radio Modules in RF sharing is done via the master System Module only.

9.22 Recommendations for RF Sharing WCDMA-LTE dual band configurations

• During FSMF rollout 3G SM optIf4 should be connected to 4G FSMF optIf6 for sync Advantage: No change of sync port during upgrade to dual band configuration

• Install FBBA/FBBC during FSMF rollout Advantage: No additional power off/on reset during upgrade from single band RF sharing

9.23 RF Sharing WCDMA-LTE Synchronization

• Clock source switching from OCXO to clock received from RP3-01, when operating as an extension system module or as a synchronization slave system module.

• At slave system module, the setting about the sync is not necessary. Synchronization will be fixed to master system module.

• If system module is synchronized to master system module, Site manager will display the synchronization source as “Other BTS”.

9.24 RF sharing WCDMA-LTE with FSMF on LTE side

LTE side: Local Maintenance Terminal (LMT) of the LTE eNB: Set the IP address of the LMT PC to 192.168.255.126/24.


LTE BTS Site Manager: It is possible to use local or remote IP addresses to login to the LTE eNB with BTS Site Manager. In case of using the local IP address, for a standalone LTE eNB choose the option “Local”:


For an LTE eNB running in RF sharing WCDMA-LTE configuration, choose “Local (192.168.255.127)”:

After enabling or disabling RF sharing for the LTE eNB, please restart the BTS Site Manager with the correct option. Alternatively the remote IP address of the LTE eNB can be used.


WCDMA side: Local Maintenance Terminal (LMT) of the LTE eNB: Set the IP address of the LMT PC to 192.168.255.130/24.

WCDMA BTS Site Manager: It is possible to login with local or remote IP addresses to the WCDMA BTS with BTS Site Manager. Use the option Local, or the remote IP address of the BTS. For example, using the option Local:


9.25 Don’t configure WCDMA-LTE RF Sharing in use if shared BTS site doesn’t contain WCDMA System Module

If WCDMA system module does not exist and if WCDMA-LTE RF sharing has been taken into use then BTS remains in initializing state because WCDMA system module is fixedly synchronization master in LTE-WCDMA RF sharing. Initializing state in BTS SW prevents reconfiguration commissioning from BTSSM Workaround: If this accidently happens it is possible to commission BTS to the synchronization master mode via NetAct, because Flexi Radio auto-detection is not required, when commissioned via NetAct.

9.26 MHA/RET settings - ReadOnly field

In RL70 Error indication (Read Only parameter, Execution failed) is raised to alert and tell the operator a ReadOnly field of MHA/RET is being edited. Such operation will not be executed by eNB. Currently this error indication is missing before RL70 so if the wrong value is already set before, customer may perceive such error indication from site manager after eNB is upgraded to RL70. This error indication has no harm to eNB performance but operator should re-commission MHA/RET settings to make the wrong value correct.

9.27 Change of RX level calculation procedure for Vegas and Reno RF Variants

With RL70 RX level calculation procedure has been changed for Vegas FXEB, FXDB, FXCB, FXFC and Reno FHEB, FHDB, FRPK RF variants. Instead of using power scaling factor values hardcoded in BPF file Scaling factor as sent by Radio Module is used in System Module for the RX level calculation. Impact on network performance: Modification of scaling factor are visible in change of KPI trends for RSSI PUCCH/PUSCH (up-to +-3dB) and mostly – but depending on settings for UL Power Control – additionally in Power Head Room Reporting from UE, UL SINR, UL HARQ Retransmission.


9.28 BTS Site Browser behavior change for TRS parameters between RL60 and RL70

The backup commissioning file does not support the TRS parameters in RL70 while they are supported in RL60. The RL70 BTS Site Browser does a backup of BTS parameters only.

9.29 Workaround for alarm 1836: EFaultId_ALOvercurrentAl

In default BTS commissioning, both 3GPP/AISG and DC are marked. This is because eNB does not know what equipment is in antenna line and it will sniff ALD equipments in startup (i.e. DC must be marked there). However if this DC tap is not unchecked, in case NO ALD equipment in feeder (instead of feeder RS485 port is used for ALD (tilt)) then 1836: EFaultId_ALOvercurrentAl alarm will be raised. The workaround to avoid mentioned above problem is to enable only 3GPP/AISG communication in case TILT equipment is supposed to be taken into use with RF modules with RS485 port for RET devices.

This workaround should be done when eNB is RL60 SW level. After DC taps are unchecked on BTS commissioning, alarm 4141 DcVoltageAdministrativelyDisabled will appear to SEM/iOMS. This alarm will disappear after upgrade to RL70 or resetting alarming RF module. If workaround is made in RL70 SW level, eNB reset is needed to avoid any unnecessary alarms or unexpected eNB behavior.

9.30 Rules for commissioning of passive / virtual MHA

In case eNB with RL60 SW has been commissioned with more than two LNAs, only 2 LNAs can have same serial number and product code. Different PC and SN for all LNAs is also allowed – however it would mean that each LNA belongs to separate MHA (this can occasionally lead to other problems like mistaken recovery). In general relationship between PC and SN for every LNA shall reflect to physical MHA construction and to the way this physical device is connected to Base Station. In case this condition is not fulfilled, the cells will stay disabled / degraded after upgrade to RL70 SW. Serial numbers need to be removed or rewritten so that pair of SN and PC for every LNA is in line with statement above. Such reconfiguration (if required) shall be performed prior migration to LN7.0 is started If there is some gain provided by external source to antenna line (either active MHA controlled by different site or passive MHA which is not fed with power by our site) suggested way of commissioning is to use additionalRxGain parameter (carrying the value of gain provided by such device) instead of using “MHA in Use” option. In such case, if MHA will be commissioned to the antenna line, then antennaTotalLoss value will be taken to FEG calculations (by default -3db). For example, if MhaGain is set to 12db and antennaTotalLoss is set to -5db, then additionalRxGain should be 5db less, means 7db.


9.31 TRS becomes un-commissioned after adding address set for 2nd operator

When additional operator needs to be configured on the eNB (for RAN sharing purposes), TAC needs to be configured for 2nd operator transport network. Otherwise, when only U-Plane and C-Plane addresses for 2nd operator are configured, the TRS will become un-commissioned.

10 CHECKING OF THE PACKAGE CONSISTENCY

After downloading the software it is important to generate SH1 checksum for files and compare it with the one provided in the Summary of Corrections and Enhancements document, this will ensure that the files were not corrupted during downloading. In order to check the package consistency after Flexi Multiradio BTS LTE SW update, please ensure that the procedure “Update SW to BTS site” is terminating successfully. In order to check the package consistency after Flexi Zone BTS SW update, please ensure that the procedure “Update SW to BTS site” is terminating successfully.

11 FALLBACK

11.1 Flexi Multiradio BTS LTE Operator Hints

11.1.1 HW configuration changes HW configuration changes should not be done during SW upgrade as this may lead to inconsistencies in the internal configuration files. Changes in configurations should either be executed before SW upgrade or after SW upgrade. In case the changes have been executed before SW upgrade a SW fallback will keep the configuration changes. In case the configuration change will be done directly after SW upgrade and then a SW fallback will be initiated, the changed configuration may lead to start up problems with former SW. Reason would be that the internal configuration file of pre-upgrade will be used and this may not match the changed configuration.

11.1.2 New HW not supported by previous SW Version

For new HW that was not supported by previous SW (i.e. FBBC extension board) the HW changes and configuration have to be done after SW upgrade. Those changes must be revoked before fallback otherwise the previous SW may not work.

11.2 Flexi Zone BTS Operator Hints

11.2.1 Manual Rollback to factory load is not supported

Rollback to factory-installed loads (means uncommisioned) is not a supported scenario. SW Rollback allows the operator to return to the previously active (commissioned) SW load and configuration that are stored in the passive file system.

12 APPENDICES / REFERENCES

[1] NOLS - Nokia Online Services log in link: https://online.portal.nsn.com [2] - "Installing Flexi Multiradio 10 Base Station for Stack, Wall, and Pole Configurations", DN09107819, Issue 13 - "Installing Flexi Multiradio BTS LTE Modules for Stack, Wall, and Pole Configurations", DN0951987, Issue 07B - "Installing Flexi Multiradio Base Station and Flexi Multiradio 10 Base Station Modules in Cabinets", DN09147506, Issue 04

https://online.portal.nsn.com/


- "Installing Flexi Multiradio Base Station and Flexi Multiradio 10 Base Station Optional Items", DN09142359, Issue 02D - "Installing Flexi Cabinet for Outdoor (FCOA)", DN09144084, Issue 01B - "Installing Flexi Cabinet for Indoor (FCIA)", DN09144096, Issue 01 - "Cabling Flexi Multiradio 10 Base Station", DN09107822, Issue 17 - "Cabling Flexi Multiradio BTS LTE", DN0951881, Issue 06A - “Installing and Cabling Flexi Zone Micro BTS”, DN09158885, Issue 03A [3] - "Commissioning Flexi Multiradio BTS LTE", DN0951893, Issue 07A - "Commissioning Flexi Zone Micro BTS LTE", DN09150296, Issue 02A [4] Long Term Evolution Information Center (LTE Radio Access, Rel. RL70, Operating Documentation, Pre-release, Issue 01) [6] " Upgrading from LTE OMS 5.0 or LTE OMS 6.0 to LTE OMS 7.0", DN0983101, Issue 01A [7] "LTE System Upgrade", DN09183906, Issue 01 [8] "Installing and Commissioning LTE OMS", DN0956464, Issue 07A

https://online.portal.nsn.com/pic/com/nsn/extranet/pic/controller/productinfoview/pivoverview.do?productId=urn:nsn.com:mxpdm:133-047488


Disclaimer The information in this document applies solely to the hardware/software product (“Product”) specified herein, and only as specified herein.

This document is intended for use by Nokia Solutions and Networks' customers (“You”) only, and it may not be used except for the purposes defined in the agreement between You and Nokia Solutions and Networks (“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 Solutions and Networks. 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 Solutions and Networks 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 Solutions and Networks welcome 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 Solutions and Networks reserves the right to change any such information and statements without notice. Nokia Solutions and Networks has made all reasonable efforts to ensure that the content of this document is adequate and free of material errors and omissions, and Nokia Solutions and Networks will correct errors that You identify in this document. But, Nokia Solutions and Networks' total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia Solutions and Networks 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 SOLUTIONS AND NETWORKS 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 Solutions and Networks’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the prior written consent of Nokia Solutions and Networks.

Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © 2015 Nokia Solutions and Networks. All rights reserved.

LTE RL70 1.2 - Change Note Forms - Page 1/38 © Nokia Solutions and Networks 2015 APPROVED 1.0 Confidential

Change Note Forms Id: LTE_RL70_1.2 Release Delivery: RL70 1.2 Product Family: Base Stations Product: Flexi Multiradio BTS LTE, Flexi Zone BTS Release: LN7.0 1.2,

LNF7.0 1.2

Approved version: 09-September-2015

Summary of changes:

09-September-2015 1.0 Approved version



CN-id: LN7.0_00226

Title: After RL70 upgrade, BTS in RF sharing sites shows alarm 7744 Excessive TCH interference Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: When using P-type config with MHA’s, excessive UL interference seen in both LTE and 2G How end user/operator could detect the problem: Unexpected 7744 – HIGH INTERFERENCE and 7607 – TRX OPERATION DEGRADED –“RSSI…” alarms in 2G. Description of the fault: Incorrect UL gain calculation in FXEA when using P-type config with MHA Related feature / functionality: P -type configuration Workaround: Use P-type config with MHAs Effects on operator: After activating the LTE SW containing the correction, P-type configuration with MHA works correctly and unexpected 7744 and 7607 – “RSSI” alarms are cancelled. Effects on end-user: Improved LTE and 2G performance Corrected Fault Reports: NA05815362 After RL70 upgrade, BTS in RF sharing sites shows alarm 7744 Excessive TCH interference Modified components: Component Version *Net element *SW-type *Unit CellP.- 24176 Change effects:


Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: Select a live P-type configuration having MHA’s and running previous LN7.0 release, with active and unexpected 7744 and 7606 – “RSSI” alarms in 2G. Test execution: Upgrade the affected live site to LTE SW to LN7.0 1.2. Expected results: 7744 and 7607 alarms do not occur anymore. Unexpected results: 7744 and 7607 alarms occur at the same occurrence than with the previous LN7.0 build.


CN-id: LN7.0_00227

Title: WCDMA-LTE RF Sharing: LTE does not get onair after commissioning Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: WCDMA and LTE sharing and configuration WCDMA: FSME+FSME and 2xFRGP, 2+2+2 15W H-type / LTE: FSME and 2xFRGP, 1+1+1 30W H-type 10MHz is commissioned to the site. After commissioning LTE not fully operational and does not get OnAir. How end user/operator could detect the problem: LTE not fully operational and does not get OnAir. Alarms indicated by eNB 0x7652 Failure in optical RP3 interface, Unit: Cablink100, Cell: , RN: 2016 set 0x7653 Configuration error: BTS config error (Not enough HW for LCR), Unit: 0, Cell: 2, RN: 1868 set 0x7652 Parallel RP3-01 link length mismatch, Unit: Cablink100, Cell: , RN: 4072 Description of the fault: LTE OAM stuck due to race condition during applying configuration to HW. Related feature / functionality: RAN2126 / LTE435 Workaround: As workaround set syncPropagationEnabled to true in configuration to prevent this problem. Description of the correction (incl. risk analysis): LTE OAM improved to resolve race condition properly. Effects on operator: eNB will be not in OnAir Effects on end-user: LTE Calls not possible. Corrected Fault Reports: PR068687


WCDMA-LTE RF Sharing: LTE does not get onair after commissioning Modified components: Component Version *Net element *SW-type *Unit CellP.- 24180 Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: N/A Test execution: Commission referred configuration to the sites. Expected results: WCDMA and LTE sharing operational and both sites “OnAir” and calls succeed. Unexpected results: LTE not fully operational and does not get “OnAir”. Alarms indicated by eNB.


CN-id: LN7.0_00228

Title: eNB restarts during MP3.1 sw-downloads via sw- manager Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: RL60MP3.0/3.1 eNB restarts during MP3.1 sw-downloads via sw- manager How end user/operator could detect the problem: Unexpected Site Autonomous Reset Description of the fault: Process crash in SMAFileTransfer , when the critical section of the code executed from multiple contexts. Workaround: No workaround Description of the correction: SSL ctx mutex got locked before setting the SSL cert context and released the mutex after setting ssl context to avoid any other thread parallely using SSL context. Corrected Fault Reports: NA05818149 eNB restarts during MP3.1 sw-downloads via sw- manager Modified components: Component Version *Net element *SW-type *Unit deltaforce_na05818149_rl70_mp12_fix.-

FTM_R3_LN70_LNT50_FZM55_WN9010_MP12_430.00.03

Change effects:


Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A

Testing Instructions for the change Pre-requirements: EnB must be up and running. Test execution: Download SW without activation. Expected results: eNB is running, new SW is loaded on passive partition. Unexpected results: eNB is reseted.


CN-id: LN7.0_00229

Title: Functionality of ULCoMP on stations from FBBC at the 2nd slot cannot be activated Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: When calculating UPlaneDeployment, exception is thrown and not all alternative UPlaneDeployment possibilities are checked. How end user/operator could detect the problem: In given configuration with UlComp, BTS does not reach onair - none of cells are calculated Dependency on configuration: UlComp in this configuration must be present to detect fault Description of the correction: The code change is needed so that exception is not thrown; this enables UPlaneDeployment alternatives to be calculated. Effects on operator: All LTE cells that belongs to eNB are out of service, no LTE service is available for such site Effects on end-user: No LTE service available, UE is camping on 3G or 2G. Corrected Fault Reports: NA05823899 Functionality of ULCoMP on stations from FBBC at the 2nd slot cannot be activated Modified components: Component Version *Net element *SW-type *Unit CellP.- 24261 Change effects: N/A Effects on end-user


N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: eNB configuration as following:FSFM+FBBC 2FXEB 1FXEA( RF sharing with 2G) 3FRHB, two in a chain. ULComp must be activated: actUlCoMp=´true´ Test execution: Connect the RF modules to eNB as stated above, and check the cell status. Expected results: All the cells are in on air status after eNB startup. Unexpected results: All the cells are in Faulty state and the following alarm is present: 7653 Local cell faulty Additional fault reason: BTSOAM is not able to configure routings.BTS Reset is needed.


CN-id: LN7.0_00230

Title: LTE2050 Wrong CAC calculation / Active Bearers measurement wrong Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: When running the SW in field for a longer time (several days) the CAC value did not return to 100 anymore even in times when cell load was low. How end user/operator could detect the problem: Handover UEs are prevented from getting into the cell. Description of the fault: Calculation of CAC depends on a value (average scheduling weights of nonGBR bearers having data in buffer) which is reported by MAC-PS to C-Plane. This value did not return to 0 in some cases and as a result CAC value was stuck. The reason why the value did not return to 0 was a hanging UE which was not released correctly after it went out of sync. So the scheduling weights of nonGBR bearers of this UE were always used for the average calculation even if the UE wasn’t connected anymore. In case of several hanging UEs the scheduling weights accumulated. Description of the correction: There are 2 changes in order to solve the problem: 1. PDCCH order will be triggered if either L2 buffer status is filled or MAC-PS buffer status is filled or both are filled. 2. In case of UE goes out of sync a timer is started which triggers a final out of sync in case of expiry which in turn triggers a UE release. The timer is chosen in a way that neither the inactivity procedure nor the PDCCH order procedure is affected. Risk analysis of the correction: If the timer of 2. is not calculated correctly UE might be released even if there is a chance to get the UE in sync again. Corrected Fault Reports: NA05814845 LTE2050 Wrong CAC calculation / Active Bearers measurement wrong


Modified components: Component Version *Net element *SW-type *Unit fb14_07.- 360680 Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: Smart DRX enabled and different smart DRX profile configured with different short cycle and long cycle. QCI5 is configured with smart DRX profile4 and QCI1 is configured with smart DRX profile2. Smart DRX profile 4 has longer ‘short/long drx cycle’ than that of smart DRX profile2. Test execution: QCI5 bearer established by default after UE IMS registration. Make VoLTE(QCI1) call setup and release, before RRC inactivity timer expiry, make the 2nd VoLTE call setup and release. Expected results: The second call setup successful. Unexpected results: The second call is failure, SIP:INVITE message does not reach UE.


CN-id: LN7.0_00231

Title: UE stuck in OutOfSync. Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: During reconfiguration of DRX in MAC PS it could happen that the DL scheduler ended up using inconsistent DRX parameters. This caused the call to be dropped. How end user/operator could detect the problem: Call dropped. Description of the fault: When the DRX parameters are reconfigured, we have a transient phase in the ENB because it is not known when exactly the UE takes the new DRX parameters into use. During this transient phase the ENB tries to use a safe combination of the old and new DRX parameters to avoid that the UE is scheduled while it is DRX sleep. Due to a bug in MAC PS it could happen that after the transient phase was over the DRX short cycle timer continued running for ever with the old DRX offset. This lead to lots of allocations during DRX sleep and the call was dropped. Dependency on configuration: Only occurs if smart DRX is enabled. Faulty component and version: SW component and version where problem occurred first time, if problem occurred in different branches based on different versions then all first broken versions for each branches shall be listed Workaround: Disable Smart DRX feature (LTE585). Description of the correction: Don't start the DRX short cycle timer during the DRX reconfiguration transient phase. Corrected Fault Reports: NA05831781 UE stuck in OutOfSync


Modified components: Component Version *Net element *SW-type *Unit fb14.7 360683 Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: Smart DRX enabled and different smart DRX profile configured with different short cycle and long cycle. QCI5 is configured with smart DRX profile4 and QCI1 is configured with smart DRX profile2. Smart DRX profile 4 has longer ‘short/long drx cycle’ than that of smart DRX profile2. Test execution: QCI5 bearer established by default after UE IMS registration. Make VoLTE(QCI1) call setup and release, before RRC inactivity timer expiry, make the 2nd VoLTE call setup and release. Expected results: The second call setup successful. Unexpected results: The second call is failure, SIP:INVITE message does not reach UE.


CN-id: LN7.0_00232

Title: VoLTE calls DL data transfer stalls Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: VoLTE calls DL data transfer stalls Description of the problem: When total number of data UEs with data in buffer rises, voice UEs are no longer scheduled in DL. How end user/operator could detect the problem: Pings from voice UEs no longer received. Description of the fault: Voice UEs were not getting passed from DL pre-scheduler to DL TD scheduler. UEs are not prioritised in the MAC PS DL pre-scheduler, but rather only once they get to the TD scheduler. In the TD scheduler a GBR UE will overtake a non-GBR UE. However, what was happening here is that a VoLTE waking up out of DRX sleep on the first TTI of the DRX on duration was written to the end of the pre-scheduler candidate list. The DL pre-scheduler processes this list in round-robin fashion, and sends up to 50 UEs (but fewer in case of high CPU load) to the TD scheduler every TTI for further processing, the so-called CS1 list. When the candidate list gets longer than 4 * length of the CS1 list (from drxOnDuratT=4), then the VoLTE UE still will not have reached the front of the pre-scheduler candidate list before the DRX on duration expires, i.e. it doesn’t even reach the TD scheduler. Dependency on configuration: Problem only occurs with small values of drxOnDuratT, under 10 ms. Faulty component and version: Present in all releases. Workaround: drxOnDuratT greater than or equal to 10 Description of the correction:


The fix will be to insert a VoLTE which wakes up from DRX sleep at the start of the DRX on duration near the front of the candidate list. (UEs with pending HARQ retries must take priority and so are inserted right at the front.) Corrected Fault Reports: PR058899 VoLTE calls DL data transfer stalls Modified components: Component Version *Net element *SW-type *Unit LTE_UP_1164.- 8.1 FB14.07 357810 Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: 3CC carrier aggregation activated. DRX and smart DRX activated. Test execution: Cell has 150 (or more) users doing simultaneously FTP DL/UL data transfer. One or more users make VoLTE call. Expected results: VoLTE calls succesfull with expected voice quality. Unexpected results: VoLTE users DL speech data stalls completely (or speech quality not acceptable).


CN-id: LN7.0_00233

Title: [LTE430] PDCCH Power Boost missing from time to time Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: PDCCH Power Boost was missing in certain allocations, even if allocated aggregation was lower than the required aggregation How end user/operator could detect the problem: increased DTX rate decreased throughput Description of the fault: PDCCH Power Boost was missing in certain allocations, even if allocated aggregation was lower than the required aggregation Related feature / functionality: PDCCH Power Control (LTE430) Workaround: disable PDCCH Power Control, by setting enablePcPdcch to false Description of the correction (incl. risk analysis): Correcting adPdcchUssAllocAndPwrStep2 (see LTE_UP_9882) implementation. Execute power boost when needed. Effects on operator: increased DTX rate decreased throughput Effects on end-user: decreased throughput Corrected Fault Reports: PR069186 [LTE430] PDCCH Power Boost missing from time to time


Modified components: Component Version *Net element *SW-type *Unit fb14_07.- 359317 Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: Multiple UEs set up in cell and transmitting data. Test execution: Put most of the UE into average radio conditions. Put some of the UEs into poor radio conditions. Expected results: Alarm 1907 should not occur. Unexpected results: Alarm 1907 occurs.


CN-id: LN7.0_00234

Title: attach not possible with category 1 UE Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: Call with Cat1 UE does not work. Description of the problem: NIR-value is wrong for physical layer. Workaround: Use dlMimoMode = txDiv, that should work. Description of the correction: Choose the correct NIR-value for Cat1 UE also for dlMimoMode = open or closed-loop MIMO. Effects on operator: KPI degradation. Effects on end-user: Cat1 UE cannot attach in TM3/TM4. Corrected Fault Reports: PR070078 attach not possible with category 1 UE Modified components: Component Version *Net element *SW-type *Unit fb14.7 r360545 Change effects: Effects on end-user N/A


Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: Cell is on air. Test execution: Attach LTE UE with Category=1 to cell. Expected results: Attach successful. Unexpected results: Attach unsuccessful.


CN-id: LN7.0_00235

Title: 2 Sites out of service with FRMC RF module failure (1907) Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: Too high PDCCH power correction values in downlink direction. How end user/operator could detect the problem: Failure indication at RF module side. Description of the fault: After blocked PDCCH DCI entry PDCCH power basket changes are lost, which leads to higher PDCCH power correction values, sent to DL PHY. Dependency on configuration: PDCCH power relocation. Faulty component and version: Packet Scheduler dowlink power calculation. Workaround: Disable PDCCH power relocation via R&D parameter. Description of the correction: Keep information about PDCCH power basket changes after blocked PDCCH DCI entry to avoid too high PDCCH power correction values, sent to DL PHY. Effects on operator: Degradation in service due to cell in faulty state after raise of 1907 alarm. Effects on end-user: Degradation in service.

Corrected Fault Reports: NA05804048 2 Sites out of service with FRMC RF module failure (1907)


Modified components: Component Version *Net element *SW-type *Unit fb14_07.- 358317 Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: eNB with FRMC/FRHC Test execution: Normal work in a field. Expected results: No 1907 alarm (RF Module Failure) occurrence. Unexpected results: 1907 alarm occurrence.


CN-id: LN7.0_00236

Title: Tracking fix for - NA05829186 RL70 1.1 upgrade failure caused by TRS IPSec configuration lost Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: Configuration migration failed for IPsec part during LN60 to LN70 upgrade. How end user/operator could detect the problem: Configuration migration fails during upgrade Description of the fault: In LN70 there is a check to make sure IKE parameters are same for Tunnels with same local and remote endpoints. This check is applicable only for protect policy, but the existing logic was even checking for BYPASS/DISCARD policy as well. Dependency on configuration: Applicable only with IPsec configuration for policies with same local and remote tunnel end point Faulty component and version: Initial Workaround: Before upgrade to RL 70 ensure that the IKE parameters are same for policies with same local and remote end points Description of the correction: In LN70 there is a check to make sure IKE parameters are same for Tunnels with same local and remote endpoints. This check is applicable only for protect policy, but the existing logic was even checking for BYPASS/DISCARD policy as well. Now the condition check is done only for protect policy. Corrected Fault Reports: PR074268 Tracking fix for - NA05829186 RL70 1.1 upgrade failure caused by TRS IPSec configuration lost


Modified components: Component Version *Net element *SW-type *Unit LN7.0_ENB_1407_572_04

LN7.0_ENB_1407_572_04

Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: eNB is onAir. Test execution: SW upgrade. Expected results: No alarms, TRS configure the IPsec. Unexpected results: TRS configuration is lost in IPSEC part.


CN-id: LN7.0_00237

Title: MAC PS logging: too many SR or CQI requests per TTI Version of the SW-build: LN7.0_ENB_1407_572_04 Valid for Product(s): Flexi LTE Base Station References: Reason for the Change Note: Summary of the original problem: C-plane sets up UEs with too many periodic CQI and SR occurrences per TTI on FSMr3. MAC PS prints error message and does not request the periodic CQI/SR reception on PUCCH. Description of the fault: During RL70 in LTE1799 the CQI/SR capacity was increased in UL PHY to 75 per TTI for all deployments on FSMr3. But in MAC PS this was done only in 4-DSP deployment, not in 2-DSP deployment. Workaround: No workaround. Description of the correction: In MAC PS, increase the periodic CQI/SR capacity to 75 per TTI for all deployments on FSMr3. Effects on Operator: Depending on eNB cell configuration, in some cases cells supported SR/CQI capacity per TTI not fully utilized. Corrected Fault Reports: PR062199 MAC PS logging: too many SR or CQI requests per TTI Modified components: Component Version *Net element *SW-type *Unit fb14.7 r357848 Change effects:


Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: 20Mhz cell under high load including UE’s doing state transitions, FTP UL/DL data transfer, HO’s, VoLTE calls. Test execution: During high load eNB internal logging under observation. Expected results: eNB internal logging doesn’t include unexpected logs indicating too many SR or CQI resource requests per TTI on cell under tests (depends on cell configuration). Unexpected results: eNB internal logging includes unexpected logs indicating too many SR or CQI resource requests per TTI (depends on cell configuration).


CN-id: LNF7.0_00017

Title: BTS activation failure due to failure to sign U-Boot on eNB165301(FZM) Version of the SW-build: LNF7.0_ENB_1407_150_14 Valid for Product(s): FlexiZone Micro References: Reason for the Change Note: Summary of the original problem: Software activation failed from LNF7.0_ENB_1407_137_12 to LNF7.0_ENB_1407_138_02. How end user/operator could detect the problem: Site Manager reports BTS SW download or activation failure. Description of the fault: Activation failure due to a failure to sign a new U-Boot image.

Faulty component and version: LNP8_PS_REL_2014_05_327 Faulty component first delivered in(e.g. release, CD): LNF7.0 Workaround: A BTS site reset should allow the next SW upgrade/activation attempt to succeed. A power cycle may be necessary in case a BTS site reset does not resolve the issue. Description of the correction: The U-Boot signing procedure was enhanced to retry up to 2 additional times using different temporary directories (located in different file system partitions) in case the first attempt fails. Additional logging and debug information was added. The root cause for the failure is unknown. However the correction will attempt to eliminate a possible scenario where signing of the U-Boot image would have failed due to a problem with the /tmp file system (which is used by other applications or may be used by anyone logged in with a service account on the system). Low risk of correction. The U-Boot signing process will function the same way as before except in the case of failure. In that case, an alternate temporary directory will be used to attempt the signing process again. The signing process itself is unchanged. Correction effects:


Should a BTS site encounter a U-Boot signing failure due to an issue with the /tmp directory (e.g. if it's full), the SW activation will automatically retry signing with alternate directories and continue activation successfully. Effects on operator: SW activation will succeed if original U-Boot signing issue was due to a full /tmp. Corrected Fault Reports: NA05824923 BTS internal SW management problem occurred in eNB165301(FZM) Modified components: Component Version *Net element *SW-type *Unit FZM_PS_LFS.- P8_FZM_PS

_LFS_OS_2014_05_92

Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A

Testing Instructions for the change Pre-requirements: RL50FZ 2.1.1PD LNF5.0_ENB_1304_161_01 to PP0.2.7.1 LNF7.0_ENB_1407_139_03 and vice versa to be tested in the operator laboratory. Test execution: Through NetAct (UUF) Update, Upgrade , Fallback Expected results: Pass and executed without any alarms. Unexpected results: Failure of UUF testing.


CN-id: LNF7.0_00019

Title: Software+failure+reset+occurred+in+FZM(LNF7.0_ENB_1407_138_02) Version of the SW-build: LNF7.0_ENB_1407_150_14 Valid for Product(s): FlexiZone Micro References: Reason for the Change Note: Summary of the original problem: ENB restart How end user/operator could detect the problem: Alarm 6706 and autonomous reset as recovery action Description of the fault: L2 generates a SW crash when it detects an incorrect parameter in MAC_HARQ_RELEASE_REQ message. CPU reads an invalid parameter from the memory because of L1D cache coherency issue in L2’s UL data handling. Workaround: No workaround. Description of the correction (incl. risk analysis): L1D cache coherency is now handled correctly when the received UL data is released Effects on operator: ENB restarts will be reduced Faulty component and version: L2 SW system component Faulty component first delivered in (e.g. release, CD): The fault has existed since the beginning of RL70 (fb1407) SW

Corrected Fault Reports: NA05821517 Software failure reset occurred in FZM(LNF7.0_ENB_1407_138_02) NA05825759 Software failure reset occurred on FZM(eNB-148152) after rollback to RL70PP0.2.2


Modified components: Component Version *Net element *SW-type *Unit L2.- fb14_07_P8 Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A

Testing Instructions for the change Pre-requirements: N/A Test execution: N/A Expected results: N/A Unexpected results: N/A


CN-id: LNF7.0_00020

Title: LNF7.0 FZM; High load test causes L2 assert in PHR message Version of the SW-build: LNF7.0_ENB_1407_150_14 Valid for Product(s): FlexiZone Micro References: Reason for the Change Note: Summary of the original problem: ENB restart How end user/operator could detect the problem: Alarm 6706 and autonomous reset as recovery action Description of the fault: L2 generates a SW crash when it detects too many UL power headroom reports in received MAC PDU Workaround: No workaround. Description of the correction (incl. risk analysis): L2 SW ignores the received MAC PDU when it detects the fault situation. Effects on operator: UL data robustness improved Faulty component and version: L2 SW system component Faulty component first delivered in (e.g. release, CD): The fault has existed since the beginning of RL70 (fb1407) SW Corrected Fault Reports: PR069722 LNF7.0 FZM; High load test causes L2 assert in PHR message PR070573 LNF7.0 FZM LCID value detected! 0x10 MAC header corrupted crash during high load test


Modified components: Component Version *Net element *SW-type *Unit Change effects: Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: N/A Test execution: N/A Expected results: N/A Unexpected results: N/A


CN-id: LNF7.0_00021

Title: FZM crash again by autonomous FSP reset Version of the SW-build: LNF7.0_ENB_1407_150_14 Valid for Product(s): FlexiZone Micro References: Reason for the Change Note: Summary of the original problem: eNB restart How end user/operator could detect the problem: 6706 autonomous reset generated Description of the fault: L2 SW gets invalid values from the received syscom message Faulty component and version: L2 SC Faulty component first delivered in(e.g. release, CD): Fault exist from the beginning of RL70 release Workaround: No workaround Corrected Fault Reports: NA05829844 FZM crash again by autonomous FSP reset NA05831155 FOA - After RL70 Upgrade on Chicago FzM Sites - Alarm "6706 autonomous reset as recovery action" is Appearing Modified components: Component Version *Net element *SW-type *Unit L2.- SC Change effects:


Effects on end-user N/A Effects on Operator N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: This issue cannot be reproduced at system level Test execution: N/A Expected results: N/A Unexpected results: N/A


CN-id: LNF7.0_00238

Title: There is an alarm 7652 Base station notification (6803: EFaultId_GpsAntennaCurrentHighAl) at A101 PICO with RL70 P8 SW. Version of the SW-build: LNF7.0_ENB_1407_150_14 Valid for Product(s): FlexiZone Micro References: Reason for the Change Note: Summary of the original problem: The FZP GNSS receiver reports a high antenna LNA following receiver firmware version 16 upgrade. The problem is caused by a defect in the vendor version 16 firmware where an antenna over-current condition is reported while the actual antenna current level is normal. Further investigation however has shown that the actual antenna current is not a factor since the Foxconn designed FZP GNSS receiver does not include the hardware to measure antenna current. The FZP GNSS receiver utilizes the Furuno 64-pin OPUS-7 GNSS receiver ASIC. This firmware defect is not present in the 141-pin OPUS-7 and OPUS-5 ASIC’s used on the FZM platform. The FZM GPS/GNSS receiver design does support the ability to measure antenna over-current. The GPS over-current functionality on the FZM is operating properly. How end user/operator could detect the problem: The 6803: EFaultId_GpsAntennaCurrentHighAl fault is reported by an FZP that is operating with the Furuno version 16 firmware. The actual antenna current is not a factor. Description of the fault: The Furuno OPUS-7 ASIC supports the ability to report on the power provided to the externally connected antenna through the following possible conditions: No-voltage, under-current, normal current, over-current. The FZM / FZP SyncApp only supports provisions to read the over-current report. The Furuno version 16 (and some previous firmware versions) improperly report the antenna LNA supply conditions where the bit setting inputs to the OPUS-7 ASIC that represent a normal operating current result in the reporting of an over-current condition by the ASIC. Dependency on configuration: This problem is present on the FZP platform with Furuno receiver’s operating with the version 16 firmware. The problem does not affect the FZM. Faulty component and version: Furuno version 16 firmware running on the FZP GNSS receiver.


Faulty component first delivered in(e.g. release, CD): The affected Furuno version 16 firmware is being deployed on all FZP software releases. Workaround: If the GNSS antenna is properly functioning (despite the reported 6803 fault) normal eNodeB operation should be experienced and the fault can be ignored. Description of the correction: Since the FZP hardware does not support the ability to monitor the GNSS antenna current software will be modified to disable the ability to report the 6803 fault on the FZP. Risk analysis of the correction: The correction involves the masking of the FZP’s ability to report the 6803 fault. This correction poses no risk as the FZP hardware does not support detection of the 6803 fault. If an actual GNSS antenna problem were to exist a loss of satellite reception fault would be reported notifying the customer of the hardware problem. Corrected Fault Reports: NA05819629 There is an alarm 7652 Base station notification (6803: EFaultId_GpsAntennaCurrentHighAl) at A101 PICO with RL70 P8 SW. Modified components: Component Version *Net element *SW-type *Unit WBTS_SYNC_72361.-

1.2

BM.- 37630 Change effects: Effects on end-user N/A Effects on Operator

N/A Other effects N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: Pico BTS A101 version or newer. Test execution: Install SW to BTS via BTS Site Manager.


Expected results: Alarm 7652 Base station notification (6803: EFaultId_GpsAntennaCurrentHighAl) does not show in BTS manager. Unexpected results: 7652 Base station notification (6803: EFaultId_GpsAntennaCurrentHighAl) is generated.


CN-id: LNF7.0_00239

Title: FZM reboots due to "BUG: soft lockup - CPU# stuck" after TL15A to RL55 backout Version of the SW-build: LNF7.0_ENB_1407_150_14 Valid for Product(s): FlexiZone Micro References: Reason for the Change Note: Summary of the original problem: gpio-keystone driver doesn't acknowledge hIRQ in case if there is no vIRQ associated with it. It causes gpio irqs to stop firing and eventually leads to soft lockup and watchdog reset. Workaround: Acknowledge hIRQ in case if there is no vIRQ associated with it. Faulty component first delivered in(e.g. release, CD): Acknowledge hardware IRQ even if there no virtual IRQ's associated with it. Effects on end-user: Interruption in service Corrected Fault Reports: PR065078 FZM rolling reboots due to "BUG: soft lockup - CPU# stuck"

Modified components: Component Version *Net element *SW-type *Unit linux.- FB_FZM_PS

_LFS_OS_2014_05_106

Change effects: Effects on end-user N/A Effects on Operator N/A Other effects


N/A New functionality N/A Customer Impact N/A Testing Instructions for the change Pre-requirements: N/A Test execution: N/A Expected results: N/A Unexpected results: N/A

LTE_RL70 1.2 SW Update Verification Report - Page 1/4 © Nokia Solutions and Networks 2015 APPROVED 1.0 Confidential

SW Update Verification Report Id: LTE_RL70_1.2 Release Delivery: RL70 1.2 Product Family: Base Stations Product: Flexi Multiradio BTS LTE, Flexi Zone BTS Release: LN7.0 1.2, LNF7.0 1.2 Approved version: 09-Sep-2015



Table of Contents 1. Introduction ............................................................................................................................................. 3 2. Test Environment .................................................................................................................................... 3 3. Description of test phase entities ............................................................................................................ 3 4. Remaining Open Faults Found In Testing .............................................................................................. 3 5. Appendices / References ........................................................................................................................ 3

Contact:

Contact your local Nokia support

Summary of changes:

09-Sep-2015 1.0 Approved version


1. INTRODUCTION

This document presents the testing results for RL70 1.2 including the findings made. The following table summarizes performed test cases in corresponding test phase.

Test Phase Total Passed Passed Rate Correction testing 21 21 100% Regression testing 471 471 100% Software update/upgrade installation testing 41 41 100% Total 533 533 100%

2. TEST ENVIRONMENT

Test environment is build according to chapter “System Descriptions” [1] in Customer Documentation library.

3. DESCRIPTION OF TEST PHASE ENTITIES

Correction Testing All individual corrections have passed sub-system testing. All individual corrections have passed entity testing. Regression Testing Regression test verifies the unchanged parts of a product after parts of the product have been changed. It is a way to ensure that the change did not affect anything else and that there are no unexpected side effects. Software Update Installation Testing The target is to validate that the entity in an older version can be updated as expected to the version to be released. Update was tested from several SW levels, for detailed information about upgrade paths and procedures, please refer to “LTE_RL70 1.2 Installation Instructions” document which is part of RL70 1.2 Release Documentation.

4. REMAINING OPEN FAULTS FOUND IN TESTING

Findings are included in LGF report “LGF-LTE-RL50FZ_RL60_RL70-2015-w31”

5. APPENDICES / REFERENCES

[1] “LTE RAN and EPC System Description”, DN0993921, Issue 05A


Disclaimer The information in this document applies solely to the hardware/software product (“Product”) specified herein, and only as specified herein. This document is intended for use by Nokia Solutions and Networks' customers (“You”) only, and it may not be used except for the purposes defined in the agreement between You and Nokia Solutions and Networks (“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 Solutions and Networks. 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 Solutions and Networks 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 Solutions and Networks welcome 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 Solutions and Networks reserves the right to change any such information and statements without notice. Nokia Solutions and Networks has made all reasonable efforts to ensure that the content of this document is adequate and free of material errors and omissions, and Nokia Solutions and Networks will correct errors that You identify in this document. But, Nokia Solutions and Networks' total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia Solutions and Networks 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 SOLUTIONS AND NETWORKS 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 Solutions and Networks’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the prior written consent of Nokia Solutions and Networks. Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright © 2015 Nokia Solutions and Networks. All rights reserved.

Documents

LTE_RL70_1.2_Release_Documentation.pdf