LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48

List of Generic Faults LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Base Stations , Radio Controllers Flexi Multiradio BTS LTE, LTE iOMS, Flexi Zone BTS RL60, RL70, FL15A iOMS6.0, iOMS7.0, LTE OMS15A RL50FZ Approved: 10-December-2015

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.

© Nokia

Company Confidential

Table of Contents 1. OVERVIEW ............................................................................................................................ 20 2. OPENED Generic faults ......................................................................................................... 21 2.1 RF alarms 1910/1920 observed after upgrade ...................................................................... 21 2.2 Missing oms agent in monitor ................................................................................................ 21 2.3 After BTS site is onair, FBIH 1 that is assigned to cell3 and cell4 still show gray on SEM .... 23 2.4 Application Launcher Server is not responding ..................................................................... 23 2.5 System Module failure (0010) alarm after upgrade from RL70 to FL15A .............................. 23 2.6 [FL15A] [FSMr3] Unit autonomous reset as recovery action ................................................. 25 2.7 [LN7.0 2.0][FSMr3]: M8001C151 (Max number of UEs with buffered data in UL) counter starts reporting abnormally high values during stability test ................................................................ 25 2.8 [FSMr3] [FL15A] Cell_config_data_distribution_failed(6253)................................................. 27 2.9 Unexpected Failure in optical interface alarm (0010) on FRIG cell in faulty state ................. 27 2.10 iOMS rehome failed for some eNBs due to parameter issue ................................................. 28 2.11 (RL70) the processin of DM stopped, LED of EIF 2 off, eNB cannot get temporary IP ......... 28 2.12 Some cells are Disabled after SW upgrade due to alarm 4008 (Power level not supported) 30 2.13 RL70 Mp1.1-MP2 upgrade failed on sites .............................................................................. 30 2.14 No Traffic 4G MRBTS-506488 Post 4019 autonomous FSP restart (add info 52)................. 31 2.15 eNB does not generate PM data after SW activation............................................................. 31 2.16 High RSSI is seen on multiple sites ....................................................................................... 32 2.17 Three cells on FRLB are not working. Cell state is Disabled ................................................. 32 2.18 High GSM drops on some GSM/LTE RF sharing sites .......................................................... 34 2.19 WMP-FDD\FL15A\LTE1058: Core dump and DUT crashing observed after sending IPv4 ACPAR values for Plug and play auto-connection............................................................................... 34 2.20 After upgrade from RL70 0.2.6 to RL70 1.2.3 FBCC remained in state configuring .............. 36 2.21 PDCCH order not send (UE stay RRC connected even though eNB released RRC connection) .......................................................................................................................................... 36 2.22 850 refarming issue with FXCB on WN9.1 3.0 & RL70 1.1.................................................... 38 2.23 [FL15A][FSMr3] Autonomous reset after changing cell's administrative state to unlocked ... 38 2.24 Missing B2 Report Configuration to GSM with MODPR with Autoadapt=false ...................... 39 2.25 Unit autonomous reset of FBB/FSP on multiple sites caused by MTRACE parameter change 39 2.26 2.25 Certificates are missing after upgrade to FL16 when IPSEC is configured ................... 40 2.27 Conversion between RL70 and FL15A software showing problems during recommissioning with prachFreqOff parameter ............................................................................................................... 41 2.28 LTE_5801d Average Active UEs with data in the buffer UL KPI is rising............................... 41 2.29 LTE908 Select always same ANRPRW profile ...................................................................... 42 2.30 E-RAB drop after FL15A upgrade and some sites having PS call issues .............................. 42 2.31 TRS commissioning data lost after upgrade to RL70 1.1....................................................... 43 2.32 FSMF - Timing over Packet, Phase synchronization, PTP correction field, Interoperability with transparent clock, TC ........................................................................................................................... 43 2.33 LNCEL out of use with the alarm "Distributed site supported not enabled" after SW upgrade …………………………………………………………………………………………………………44 2.34 VOLTE Quality Trial: DSCP and SGW IP change ................................................................. 44 2.35 Cell outage "Not enough HW for LCR" .................................................................................. 45 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 2/330 Version 1.0 Confidential

© Nokia Solutions and Networks 2015

2.36 Alarms 3000 (EFaultId_SystemModuleFailure) and 1836 (EFaultId_ALOvercurrentAl) ........ 45 2.37 Vendor Certificates missing in Flexi Zone. ............................................................................. 46 2.38 After LN7 activation the sites loose O&M .............................................................................. 47 2.39 Huge amount of 71058 alarms generated ............................................................................. 47 2.40 Failing Consistence Check for MaxNumQci1Drb ................................................................... 48 2.41 After eNB restart, duplicate LNREL that generated by earlier bump up and alarm 7650 will be trigger …………………………………………………………………………………………………………48 2.42 Intra-eNB Inter-F HO failed due to radio-connection-with-ue-lost .......................................... 49 2.43 Unable to perform CM upload or provisioning - NE busy, details: Readonly ......................... 49 2.44 MTRACE migration chnage based on requirements update.................................................. 50 2.45 RFS FHEA/ FXEA Configuration error: BTS config error (Not enough HW for LCR) (1868) appears after upgrade.......................................................................................................................... 50 2.46 eNB not able to recover itself (dpd tasks gets accumulated) in a specific state .................... 50 2.47 LNCEL out of service with the alarm "Configuration error: Not enough HW for LCR" after upgrading SW upgrade ........................................................................................................................ 51 2.48 FOA Configuration problem with 2600+1800 RFM 4way ULRX – BW15+15Mhz in RF sharing …………………………………………………………………………………………………………52 2.49 Some DSCP values incorrectly changed in the Traffic Type Settings table after RL50 to RL70 MP1.2 Upgrade .................................................................................................................................... 52 2.50 eNBs sending IR message to PKI after upgrade to RL70 ...................................................... 52 2.51 Cells down after RF module Block/Unblock ........................................................................... 53 2.52 Drop ERAB SSR on eNodeB configuration 15+20 MHz ........................................................ 53 2.53 Unblocking one carrier changes the tx spectrum of 2nd carrier ............................................. 53 2.54 LDAP errors after minor update ............................................................................................. 54 3. SOLVED Generic faults ......................................................................................................... 55 3.1 LTE cell disabled without any alarm ...................................................................................... 55 3.2 eNodeB restart during logs collection .................................................................................... 55 3.3 1835 alarm was raised only for WMHC LNA2........................................................................ 55 3.4 Functionality of ULCoMP on stations from FBBC at the 2nd slot cannot be activated .......... 56 3.5 Wrong temp Ue handling when processing also dedicated preambles in same tti ................ 56 3.6 IRAT UE based ANR CGI report not triggering with 10s LNCEL Inactivity timer ................... 57 3.7 PDCCH Power Boost missing from time to time .................................................................... 57 3.8 attach not possible with category 1 UE .................................................................................. 58 3.9 Unit autonomous reset was occurred during cell block and unblock procedure .................... 58 3.10 M8016C14-C16 are not pegged in case of SRVCC to GERAN ............................................. 58 3.11 eNB not sending HO Cancel in case SRVCC2GSM failed and UE reconnect to LTE causing VOLTE call drop................................................................................................................................... 59 3.12 LN7.0 2.0 GPS Receiver alarm control interface not available (4011)................................... 60 3.13 [LN7.0_ENB_1407_556_04]VoLTE RTP timeout .................................................................. 60 3.14 Tracking fix for - RL70 1.1 upgrade failure caused by TRS IPSec configuration lost ............ 61 3.15 UE stuck in OutOfSync. ......................................................................................................... 61 3.16 [FRPB] Antenna Line Device failure (0010) with MHA ........................................................... 62 3.17 After RL70 upgrade, BTS in RF sharing sites shows alarm 7744 Excessive TCH interference …………………………………………………………………………………………………………63 3.18 RL60MP3.0/3.1 eNB restarts during MP3.1 sw-downloads via sw- manager........................ 63

LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 3/330 Version 1.0 Confidential


3.19 Counter M8026C259 PDCP_SDU_LOSS_DL_FNA seems omit part of PDCP SDU related to GBR …………………………………………………………………………………………………………63 3.20 Multiple sites dropping "Q6" packets...................................................................................... 64 3.21 WCDMA-LTE RF Sharing: LTE does not get onair after commissioning ............................... 64 3.22 OMS-11 not operational in Telefonica live network................................................................ 65 3.23 UL PHY reports 0x4000 instead of 0x8000 for 2bit rank = 2.................................................. 65 3.24 Kernel Panic happened during USB installation. ................................................................... 66 3.25 iOMS alarm and NetAct were not synchronized. ................................................................... 66 3.26 diagnostic file Collected due to duplicate Mtrace issue from 400151 .................................... 66 3.27 Incompatible SW version was not detected after RFM replace from FXDA to FXED ............ 67 3.28 Cell stays disabled when MHA SN and product code modifications are made...................... 67 3.29 NE busy occurred after CM Plan activation ........................................................................... 68 3.30 UART enabled console was causing 4019 alarms ................................................................ 68 3.31 Mast Head Amplifier fault (1870) alarm observed after upgrading from LN6.0 ...................... 69 3.32 Failure in optical RP3 interface (unsp) issue ......................................................................... 69 3.33 Acceptance: RFsharing After RP3 disconnection/re-connection LTE cell 3 remains in state disable …………………………………………………………………………………………………………69 3.34 LTE2050 Activation on 7 eNB shows wrong CAC values after feature is activated............... 70 3.35 After SW upgrade MOAM crash seen in the eNB logs .......................................................... 70 3.36 Lock LNMME not executed – no response to file activation request ..................................... 71 3.37 Auto+connection+fails+with+IPSec+configuration ................................................................. 71 3.38 Rl60 ipsec-2h-issues .............................................................................................................. 72 3.39 No handler for unexpected message with TEventId: 0x42cf .................................................. 72 3.40 Unit autonomous reset as recovery action (4019) occurred .................................................. 73 3.41 [FSMr3]Enabled IPsec causes wrong ToP Phase counter values. ........................................ 73 3.42 M8012C107/M8012C108 IP_TPUT_VOL_UL_QCI_9/IP_TPUT_TIME_UL_QCI_9 changed trend after upgrade .............................................................................................................................. 74 3.43 The name of "VSWR major alarm" was changed after upgrade LTE. ................................... 74 3.44 VoLTE calls DL data transfer stalls ........................................................................................ 74 3.45 BTS hardware notification is sent too often for not integrated BTS, which is causing unnecessary flood of notifications ........................................................................................................ 75 3.46 All cells are faulty when new FBBC is hot inserted ................................................................ 75 3.47 After RL70 corr29 upgrade eNB's are unable to connect to iOMS ........................................ 76 3.48 RL70 0.2: FSMr2 IPsec: PM M51125C2 (Discarded_ESPFramesTx) and M51125C3 (Discarded_ESPFramesRx) are wrongly pegged. ............................................................................... 76 3.49 LTE1491 Additional layer 1 performance measurements should not be activated on FSME 77 3.50 BTS EM DC AISG options not reflective of FRPA/FRHF unit capabilities ............................. 77 3.51 Failure in optical RP3 interface (unsp) ................................................................................... 78 3.52 (FDD LTE RL60) can't connect to eNB in remote. ................................................................. 78 3.53 BTS not commissioned due to unnecessary rtwp result range check in LTE1634 ................ 78 3.54 FXED - Faults 1910 RF module failure and 4003 TX failure in MIMO reported after startup. 79 3.55 RF Diagnostics test cannot run while eNB is in BTS Test State ............................................ 80 3.56 FRHC modules suggested in eNB configuration in the BTSManager in RFsharing page ..... 80 3.57 FSMr3: M51137C0 (topRxFreqSyncMsg) is occasionally pegged zero while synced with ToP frequency. ............................................................................................................................................ 80 3.58 FXED Piloting with high RF module failure (3010) ................................................................. 81 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 4/330 Version 1.0 Confidential


3.59 Part of sites have no KPI data ............................................................................................... 81 3.60 LN7.0 2.0 - BTS config error 1868, Not enough HW after SW upgrade ................................ 82 3.61 RL70 2.0 Transmission parameters missing (1825) .............................................................. 82 3.62 Flexi Zone Micro - "6707 autonomous reset as recovery action" alarm after RL70 MP1.2 Upgrade …………………………………………………………………………………………………………82 3.63 Voltage was set on for not commissioned diversity antennalines .......................................... 84 3.64 All LNCELs of eNB went down after upgrading SW from RL60 1.1 to RL70 1.1 ................... 84 3.65 MHA passively commissioned in with same S/N and product code cause faulty cells and BTS loosing operability ................................................................................................................................ 85 3.66 (Flexi Multiradio BTS EDGE MCPA)L1800 FEFAMING 2G cannot access the network ....... 85 3.67 RL60MP3.0 - outage of eNB after/during upgrade procedure RL60MP2.0MP3.0 ................. 87 3.68 Wrong DRB ID in DrbtoReleaselist - HO got cancelled ......................................................... 87 3.69 Unexpected reset occur after parameter change ................................................................... 87 3.70 RL70 Acceptance - eNB PNP not working ............................................................................. 88 3.71 (FDD LTE RL60) eNB restart randomly in one iOMS, about every 6 hours, others work well. …………………………………………………………………………………………………………88 3.72 LTO7.0_OMS decompressed and save to btsfilesBU backup path after received BTS PM files …………………………………………………………………………………………………………89 3.73 FOA - After RL70 Upgrade on FzM Sites - Alarm "6706 autonomous reset as recovery action" is Appearing ............................................................................................................................. 89 3.74 the system timestamp in SIB 8 is incorrect ............................................................................ 90 3.75 LNF7.0 FZM; High load test causes L2 assert ....................................................................... 90 3.76 BTS activation failure due to failure to sign U-Boot on eNB165301 (FZM) ............................ 90 3.77 [FWIB]Factory update failed from LNF5.0_ENB_1407_169_00 to LNF7.0_ENB_1407_145_14 ................................................................................................................ 91 3.78 Software failure reset occurred in FZM(LNF7.0_ENB_1407_138_02) .................................. 92 3.79 Failure in optical RP3 interface alarm for FRLB when upgraded to LN7.0_ENB_1407_556_54 …………………………………………………………………………………………………………93 3.80 BTS cannot detect the Rosenberger HB RETs with daisy chain mode ................................. 93 3.81 Antenna Line Device Failure 0010 for each MHA after RF unblock....................................... 94 3.82 FZM reboots due to "BUG: soft lockup - CPU# stuck" after TL15A to RL55 backout ............ 94 3.83 Impossible to pair with FlexiZone via bluetooth using QR code............................................. 95 3.84 FXED RF module failure (1910) with unknown trigger ........................................................... 95 3.85 DL Scheduler doesn't apply pdcchAggPreamb setting .......................................................... 95 3.86 IOMS SW restoration from Backup fails ................................................................................ 96 3.87 FM_Alarm Information can't show user the alarm information. .............................................. 96 3.88 Application Launcher cannot be opened from NetAct after OMS 3.1 upgrade. ..................... 97 3.89 RF Module Failure(1920)- FRIG after PP0.2.5 upgrade ........................................................ 97 3.90 uecontextreleaserequest with cause Transport resource unavailable after RRCReconfiguration ............................................................................................................................ 97 3.91 LTE 498 RIM for GSM Multiple Report PDU is re-send incorrectly when timer tRimKaG=150 mins …………………………………………………………………………………………………………98 3.92 After RL70 upgrade with PP 0.2 package, InfoModelGwExe crash seen in the eNBs log... 100 3.93 LTE1617 with other vendors eNB causes eNB restart......................................................... 100 Impact to End-user: Handover fails occasionally. Loss of connection ............................................... 100



3.94 NTP server is not accessible on eNobeB - chain configuration 1st(FSME+FTLB), 2nd (FSMF+FTIF). .................................................................................................................................... 102 3.95 DU reset due to TRS software failure .................................................................................. 102 3.96 Critical fault with MHA on RRU antenna B ports .................................................................. 103 3.97 Second RF module disappeared after power reset ............................................................. 104 3.98 RP3 routing collisions are detected on FR module active on 9 sites after SW upgrade of 22 sites ………………………………………………………………………………………………………..104 3.99 [3G-4G RFS][RFS Automation: WL0831_CT#112]: WCDMA SW upgrade causes Configuration error: Faulty configuration of system modules (1858) alarm for LTE .......................... 104 3.100 SW Rollback from FL15A to RL70 failed. ............................................................................ 105 3.101 After upgrade some sites have Antenna Line failure ........................................................... 106 3.102 Online change of parameter "consecHoFailThres" needs additional site reset ................... 106 3.103 Configuration error: BTS config error (Not enough HW for LCR) (1868) alarm after site upgrade to RL70 PP0.2 ..................................................................................................................... 106 3.104 After LTE SW upgrade, auto Reset occurred by eNB side .................................................. 107 3.105 Clock drift after eNB reset .................................................................................................... 108 3.106 Backup Commissioning file collection failed after LTE SW upgrade.................................... 108 3.107 Cannot administer eNB remotely. ........................................................................................ 109 3.108 RF Module (FRIG) is not detected (0010) and (2016) after upgrading from LN7.0_ENB_1407_557_36 to LN7.0 PP0.2.5.................................................................................... 109 3.109 BASE STATION OUT OF USE after IUB break ................................................................... 110 3.110 M8006C45 "Sum of simultaneous E-RABs of QCI1" abnormal recorded ............................ 110 3.111 CCN revision number decreases after site reset ................................................................. 111 3.112 Trace failure (6263) with additional info "trace reference in use, trace cannot be started" .. 111 3.113 Synchronization did not recover after restarting ToP server ................................................ 112 3.114 ALD devices remain faulty after unblock RF during 1923 alarm testing on LN7.0_ENB_1407_550_71 ................................................................................................................ 112 3.115 Abnormal KPI value in LTE_5603A and LTE_5601a ........................................................... 113 3.116 OMS switchover in eNB then Serving OAM system "None" ................................................ 113 3.117 1910 RF module failure occurred on the FHDB ................................................................... 114 3.118 FSMR3: ARP is not getting resolved after enabling VLAN aware flag ................................. 114 3.119 2 Cells are down after BW change of another cell ............................................................... 115 3.120 9047 alarm start arriving from the element .......................................................................... 115 3.121 S1 base handover counter update mismatch ...................................................................... 116 3.122 Multiple “Unit autonomous reset” on FBBC ......................................................................... 116 3.123 FID 4019 was occurred after SW activation due to segmentation fault in ENBC................. 117 3.124 maxNumRrc and maxNumRrcEmergency value is changed after SW upgrade causing parameter validation error .................................................................................................................. 118 3.125 TRS software failure and site reset ...................................................................................... 118 3.126 FSMF+FBBC - Two cells are disabled (FBBC local mode) after activating UL comp .......... 119 3.127 Fix reboots and random operation when UART is disabled ................................................. 119 3.128 After upgrade some sites have RF Module Configuration Failed......................................... 120 3.129 UTC PTP offset change ....................................................................................................... 120 3.130 Issues encountered with some 6 sector sites during RL70 upgrade.................................... 121 3.131 NTP server is not accessible (61613) .................................................................................. 121 3.132 [LN70]Throughput 5MHz UL wrong KPI .............................................................................. 122 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 6/330 Version 1.0 Confidential


3.133 [4G-2G RF Sharing][FSMr3]: Alarm 1958 active on LTE 15MHZ BW (Option2 cabling; FXEA shared RFMs connected to FBBC). ................................................................................................... 122 3.134 Initial Context Setup failure happens with Transport Resource not Available (trswcause=47) ……………………………………………………………………………………………………….123 3.135 Red-incomplete configuration Enodeb failed to take any configuration change during comisioning it resets immediately ...................................................................................................... 123 3.136 Failure in Optical RP3 Interface Alarm ................................................................................. 124 3.137 Incompatible SW Version after SW Upgrade to PP.0.2.5 .................................................... 124 3.138 No outgoing X2 ANR links after deleting LNADJ/LNADJL and activating UE based ANR .. 125 3.139 Cells are down after upgrading to LN7.0 PP0.2.5 ................................................................ 126 3.140 All cells go faulty and off-air after FBBC Hot insert .............................................................. 126 3.141 Antenna Line device failure Alarm not reporting from two enodeBs. ................................... 126 3.142 FBBC RP3 port stuck in blocked after SW upgrade............................................................. 127 3.143 After upgrade some sites have Not Enough HW fault.......................................................... 127 3.144 enodeB locks up and cannot administer site remotely. Call Processing stops and customers are impacted. ..................................................................................................................................... 128 3.145 FSMr3 [Automation]: BTS stays in commissioned state after site reset in RF hot remove testing ………………………………………………………………………………………………………..129 3.146 In co-sited BTSs, 2Mhz Sync Out does not work after 10Mhz Test Clock is enabled and then disabled ………………………………………………………………………………………………………..129 3.147 L7 cell faulty and BTS reset required alarm shows after SW upgrade from RL60 MP1.1 to RL70 P8 ............................................................................................................................................. 129 3.148 RP3 alarm and Cell Configuration Data Distribution Failure alarm shown after rollback to RL60 MP3.0.1 from RL70 P8 ............................................................................................................. 130 Problem report: NA05791955 ............................................................................................................ 130 Exists in Release: LN6.0 2.1 .............................................................................................................. 130 Correction Target: correction not needed .......................................................................................... 130 Severity: B - Major ............................................................................................................................. 130 Customer Impact: Operation & Maintenance ..................................................................................... 130 Probability: Occasional ...................................................................................................................... 130 Description: eNB rollback procedure was triggered from NetAct SW manager. Initially eNB was running on RL70 P8. An activation of RL60 MP3.0.1 from the passive bank was started. After rollback was completed and eNB restarted itself one of the cells shows alarm 6253 (Cell Configuration Data Distribution Failure) and there is an RP3 alarm on second FXEB. Cell Block/ Unblock, RF module block/unblock operations failed to mitigate the issue. ........................................................................ 130 Solution / Workaround: Full site reset. ............................................................................................... 130 Impact to Operator: Rollback is failure, it might be influence the customer decide if upgrade SW from current SW to RL70 branch. .............................................................................................................. 130 3.149 FSMF: RF-modules didn't recover after hot remove/insert (BTS reset in between) ............ 130 3.150 FHCA: Cells in chain disabled after unblock if master RF blocked ...................................... 131 3.151 After SW upgrade the majority of LTE sites reported the Alarm 7654 increased BER detected on the optical connection to Radio Module ........................................................................................ 132 3.152 After upgrade 2 sites report Antenna Line Failure 1873 ...................................................... 132 3.153 3 out of 6 cells stayed disabled after SW upgrade from RL60 MP3.0.1 to RL70 P8............ 133 3.154 Configuration error: BTS conf error (Not enough HW for LCR) (1868) ................................ 133 3.155 eNB DPD alarms after software rollback ............................................................................. 134 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 7/330 Version 1.0 Confidential


3.156 3.157

FBBC stays in configuring state when radio module has incompatible SW ......................... 134 SW upgrade from PP0.1 to PP0.2, site did not come On air Power cycle resolved the issue. ……………………………………………………………………………………………………….134 3.158 Rollback to LN7.0 0.2 failed due to alarm 0023 FTLB ......................................................... 135 3.159 [FSMr3]: Counter M8001C420 needs similar correction as M8001C266 - Buffers status to be checked for each active TTI ............................................................................................................... 135 3.160 Alarm 1868 is active and one cell is in faulty state............................................................... 137 3.161 Failure in replaceable baseband unit on deleting CAREL ................................................... 137 3.162 During SW upgrade Antenna Line Failure (1836) alarm was observed on multiple sites .... 137 3.163 Antenna Line Device failure (1873) alarms appear after upgrade LN6.0 3.0 to LN7.0 0.1 .. 138 3.164 DRB Inactivity timer is not restarted by user data carried by Msg3 ..................................... 138 3.165 Handover trace report isn't traced in encoded ASN1 format ................................................ 139 3.166 In Fault Management window the active alarms table list shows blank, and it shows the “CORBA BAD_PARAM” error prompt after closed the window. ........................................................ 139 3.167 BtsAddressList.txt file doesn't contain information about connected MRBTS ...................... 139 3.168 MRBTS FZC rollback fails. ................................................................................................... 140 3.169 Duplicate measurement entry in NBI LTE xml files on the same period. ............................. 140 3.170 BackupReply message was displayed instead of RestoreReply during remote restore ...... 140 3.171 Alarm 1868 is active and one cell is in faulty state............................................................... 141 3.172 Failure in replaceable baseband unit on deleting CAREL ................................................... 141 3.173 FXCC: RF Diagnostic VSWR value randomly wrongly displayed ........................................ 142 3.174 [FSMr2][2G-LTE RF Sharing] Rollback fails from RL70 0.1 to RL70 P8.............................. 142 3.175 LTE RL70 FZM BTS Status LED Indication wrong .............................................................. 143 3.176 Major Upgrade to iOMS7.0 fails if disk size is larger than 147GB ....................................... 143 3.177 After upgrading, the values of maxNumRrcEmergency and maxNumRrc have been set to zero with FSME.................................................................................................................................. 143 3.178 RET stays configuring state after upgrade to LN7.0 ............................................................ 144 3.179 BTS In commissioned state / after site reset back onAir ..................................................... 145 3.180 Plan validation failed (parameter actRemoteRfDiag is missing) during auto configuration with Netact 15.2 after RL50 to RL70 SW upgrade for FZM Small cell ...................................................... 145 3.181 LMT port access doesn't get disabled even after setting lmtport parameter to "None" in a FZM with Integrated WiFi ................................................................................................................... 146 3.182 Fault 475 lead abnormal cell deletion .................................................................................. 146 3.183 Site upgrade RL70 vs RL70 failed with fault Configuration error Not enought HW.............. 147 3.184 FlexiZone eNB send RDN sequence in different order causing automatic cert retrieval failure ……………………………………………………………………………………………………….147 3.185 BTSOM PM stats collection issues during leap second adjustment .................................... 148 3.186 [FSMr2] Unexpected fault 1807 Configuration error: Invalid frequency channel for one cell after SW update ................................................................................................................................. 148 3.187 EE SRAN Testbed: New LTE MHA Parameters cause "Parameter error" after CM Plan Upload ……………………………………………………………………………………………………….149 3.188 Unnecessary alarm (1816) after upgrade eNB from LN6.0 to LN 7.0 .................................. 149 3.189 Alarm 71122 CRL UPDATE FAILURE after iOMS upgrade to R_GOMS7_1.3.2.0.corr27.. 149 3.190 RL70 - RET Settings under Antenna Menu in BTSSM shows RETs as “not commissioned” after successful RET detection and configuration.............................................................................. 150 3.191 RTWP counters scaled per PRB should be per total bandwidth .......................................... 150 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 8/330 Version 1.0 Confidential


3.192 eNB autonomous reset after RET comissioning .................................................................. 151 3.193 LN7.0 0.1 Failure in RP3 interface (2001) after site reset .................................................... 151 3.194 LTE Conf6 only Cell51 at 15Mhz and other at 10 Mhz, report fault 1958 not described...... 152 3.195 After RL70FZ upgrade netmask of remote network in each IPsec policies is missing......... 152 3.196 NWI3 status inconsistency to FAILURE ............................................................................... 153 3.197 RL70 FZM restarts repeatedly every 4 min after SW uploading at test BTS ....................... 153 3.198 BTS not commissioned due to unnecessary rtwp result range check in LTE1634 .............. 154 3.199 Security mode failure when initiating service req for R11 UE .............................................. 155 3.200 Periodical fault 'TX Failure in MIMO (4003)' and 'Failure in optical RP3 interface (0010)' for all cells at FXCB 1.3.1 in FSMr3 ............................................................................................................. 155 3.201 1841 doesn't clear during RF module Unblock .................................................................... 156 3.202 Neighborhood relations objects are not reappearing after deletion and activation of UE based ANR ……………………………………………………………………………………………………….156 3.203 LNF7.0 LNF7.0_ENB_1407_135_06 Corrupted IQ on the TxDiv RF branch, Main branch is OK. ……………………………………………………………………………………………………….157 3.204 Unnecessary double reset during upgrade from RL50 to RL70 ........................................... 157 3.205 FRIG RF modules connected to FBBC are not detected ..................................................... 157 3.206 RF module failure with fault code 1841 ................................................................................ 158 3.207 Emergency bypass exit not working .................................................................................... 159 3.208 VoLTE mute after HO from Samsung eNB with AM to Nokia eNB with RoHC .................... 159 3.209 GTP-U alarms against all TEF SGWs after plan activation.................................................. 160 3.210 RL70: release original aperiodic configuration missing during HO between 3Mhz and 1.4 Mhz cells ……………………………………………………………………………………………………….160 3.211 Fragmented IPv4 Ping requests and replies going out of TRS cannot be decrypted at security gateway ……………………………………………………………………………………………………….161 3.212 Incorrect LED color display for alarm 4141 and 4142 .......................................................... 161 3.213 GPS receiver alarm: control interface not available (4011) alarm does not clear when reconnecting FYGB GPS ................................................................................................................... 162 3.214 Wrong Fault number (1900) visible in BTS Site Manager Faults-view................................. 162 3.215 RET fault (Antenna Line Device Failure 0010) is cleared after hot remove optical fiber...... 162 3.216 Manually started remote Rollback of iOMS is not terminated at NetAct .............................. 163 3.217 After Rollback of the iOMS interface configuration lost ........................................................ 163 3.218 FHFB: Fault 1958 and 1905 is visible after startup .............................................................. 164 3.219 All radio modules are reset after hot removal of FBBA and hot insert of FBBC................... 164 3.220 Hitachi and Dengo RETs not detected on RS485 port ........................................................ 165 3.221 RNW Measurement Management crashed when clicking stop then clicking start measurement button .......................................................................................................................... 165 3.222 BTS is not reset after sending delta changes to the BTS after new FBBA/FBBC has been hot inserted ……………………………………………………………………………………………………….165 3.223 Cells under RF modules connected to port3 of FBBCs are faulty after eNB reset. ............. 165 3.224 FSMF: “Failure in optical RP3 interface (unsp.)” and “Not enough HW for LCR (1868)” FRGQ on 1.1.3.2 not detected, both cells 8+9 of on 1.1.3.1 and 1.1.3.2 and in addition on cell 7 on 1.3.1 (FRHB) not on Air ..................................................................................................................... 166 3.225 Inconsistency in Supported Maximum Password Length .................................................... 166 3.226 On stopping the capture at point B we are observing the UE traffic interruption ................. 167



3.227

RL70 MSU: semid 262150: semop failed for cookie 0xd4d34b9: incorrect semaphore state 167 3.228 MDs are not synchronized but commit status is "success" - commit on new OMS ............. 167 3.229 FDD UL Throughput vs. SINR curve below KPI................................................................... 168 3.230 Application Launcher Version doesn't show correct in WebPage ........................................ 168 3.231 MHA states are shown incorrectly in Site Element Manager during BTS start-up ............... 168 3.232 FRMC radio module is reset with "Unit autonomous reset as recovery action (1905)" alarm, after change of FBBA extension card to which FRMC radio module was connected to FBBC ......... 169 3.233 LTE1854: Conversion phase failed during OMS upgrade from RL50 corr31 to RL70 ......... 169 3.234 LTE1634: RF diagnostic VSWR value constantly reported as 0.0 after number of runs ..... 169 3.235 No voltage in uncommissioned antenna lines ...................................................................... 170 3.236 Radio Module reset after 15sec break on RP3 interface ..................................................... 170 3.237 An exception in the operation feedback message during deleting some MO via GOMS..... 170 3.238 After FBBA is swapped for FBBC, optical link connected to newly inserted FBBC is not activated............................................................................................................................................. 171 3.239 SEC_iOMS: Key update disabled when oms ee certificate manually installed .................... 171 3.240 RU not assigned at FBBC No.3 Port .................................................................................... 171 3.241 [2G-4G RF Sharing]: Cell power failure after hot Insert of the RFM .................................... 172 3.242 LTE BTS - High RSSI on PUSCH/PUCCH .......................................................................... 172 3.243 LTE eNB Software download failed by Software manager in NetAct................................... 173 3.244 Antenna Round Trip Delay in 3rd Party 'Distributed Site'..................................................... 174 3.245 RSSI difference of 27-29 is seen after radio block/unblock and radio power resets ............ 174 3.246 FSMFr3 uncommissioning button doesn’t work ................................................................... 174 3.247 RFsharing "RRC Connection Reconfiguration" in LTE during 2G BCF Unblock ................. 175 3.248 Duplicated H/W inventory information on eNB with SyncHub BTS sync configured............ 175 3.249 [FWHI][RL70FZ] PUCCH Format 2b DTX'ed by pico working with QCOM 9635 ................ 176 3.250 BTS autonomous reset as recovery action alarm due to ENBC crash ................................ 176 3.251 FSME - 5MHz bandwidth Cell disabled without alarm ......................................................... 177 3.252 PM Data cannot get from BTS site Browser ........................................................................ 177 3.253 Site is stuck in INTEGRATED STATE after SW upgrade .................................................... 178 3.254 All MHA & RET down on site ............................................................................................... 178 3.255 RP3 alarm was observed. 3-RF modules were not detected and 1-FBBA remained in "configuring" state. ............................................................................................................................. 179 3.256 After the SW upgrade, Incompatible SW Version/BTS Integrated to RAN .......................... 180 3.257 [FZP, FWHC,EB,HM] Furuno Multi-GNSS Receiver 1PPS Phase Jump After 49.7 Days Operation ........................................................................................................................................... 180 3.258 ALD alarm reported from multiple sites with RETs after PP0.2 activation. .......................... 182 3.259 [FSMr2] After setting ToP Phase sync eNB stucks in Integrated mode ............................... 182 3.260 LTE RL70 FZM BTS Clock Tuning History is gone from RL50 to RL70 .............................. 183 3.261 TOP ip address was not transfer from RL50 2.0 to RL60 3.0 during upgrade ..................... 183 3.262 Fails ENB Rel OTH(M8006C13) KPI increase than RL60 ................................................... 184 3.263 NE O&M Connection Failure sometimes happened at FSME SMODs after RL70 MP1.0 upgrade 184 3.264 Chained RRHs does not work correct on FBBC1 port 3 ...................................................... 185 3.265 RL70_General: Installation of iOMS with Gen8 HW via FEWS fails when eth0 of iOMS is connected to FEWS and eth1 connected to local network ................................................................ 186 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 10/330 Version 1.0 Confidential


3.266 Transport master unblock cause short drop in FSM2 interface traffic for Ethernet chaining to other BTS ........................................................................................................................................... 186 3.267 Partition problems in OMS after USB or FEWS installation ................................................. 187 3.268 FSME - Grey Cell occurred in FSME site after SW upgrade ............................................... 187 3.269 No PM files transferred to OMS after 25h OAM link break .................................................. 188 3.270 RET stays configuring state after upgrade to LN7.0 ............................................................ 188 3.271 LTE2019 - Radio Module is disabled after commissioning. ................................................. 188 3.272 Problem with process trace logging by Web Gui ................................................................. 189 3.273 TRS ETH IF Ethernet statistics counter showing wrong value............................................. 189 3.274 Remote MSU download: TargetBD verification failed (current correction level not supported) 190 3.275 After SW upgrade MHAs lost "Not enough HW for LCR"..................................................... 191 3.276 [FSMr2][2G-LTE RF Sharing] Rollback fails from RL70 0.1 to RL70 P8.............................. 191 3.277 SW fallback(faultID=4083FSMF) occurred during upgrading to RL70 ................................. 191 3.278 Replacing a faulty disk in HP Proliant hardware operation do not work............................... 192 3.279 FSMr3 AutoConn - no IP-renewal in VLAN case ................................................................ 192 3.280 Increase in UL latency when upgrading from RL60 to RL70 ............................................... 193 3.281 Mismatch of radio module for each Cell ID while RF-diagnosticTest ................................... 193 3.282 BTS autonomous reset was occurred suddenly by FID 6706 (DSP crash) ......................... 194 3.283 “Unit autonomous reset as recovery action” alarms............................................................. 194 3.284 FHCA: Failure in RP3 interface (0010) and cell stays faulty after 1s optical break.............. 195 3.285 Slight degradation in the VoLTE/E-RAB Assginment Failure Rate ...................................... 195 3.286 FATAL APPLICATION ERROR Nid:0x1251 proc=0x00000021 (EmDispatch) FILE:DlDrb.cpp 196 3.287 LTE1439: Unit autonomous reset (1806) and RACH fail after link break after fiber length change 196 3.288 LN7.0_ENB_1407_554_32 - RF module receives reset request ......................................... 197 3.289 Unexpected Drop Call counted during ongoing Rrc Session ............................................... 197 3.290 RL50FZ - duplicated LNHOW mocs configuration should not be allowed ........................... 197 3.291 Upgrade from RL60 to RL70 (555_05) failed (FBBC configuring) ....................................... 198 3.292 CL PC can have over- or undershoot of power in certain conditions ................................... 199 3.293 ProhibitLBHOTimer(timer temporary blacklisting) doesn’t work during intra-eNB SBHO .... 199 3.294 eNB transmission interrupted when remote LAN switch port speed/duplex setting as 1000M 200 3.295 RL70_FHFB hot insertion to 6 cells site is not working till resetting the site ........................ 200 3.296 LTE site Beta sector has 100% RACH setup failure rate. sleepy cell .................................. 201 3.297 RL70 FSMr3: eNB reboot during ETWS load test: EAaErrorFatality_System ..................... 201 3.298 DL VoLTE RTP packet dropped by TUPu after two times Intra-Cell HO(TtiBundling activation/deactivation) ...................................................................................................................... 202 3.299 Configuration error (Not enough HW for LCR, cell 1 down ) seen for site LDA01389B / 63016 202 3.300 RP3 Failure Alarm on FRLB after upgrade to LN7.0_ENB_1407_556_52 .......................... 203 3.301 Incorrect parameters in LNREL object ................................................................................. 204 3.302 Cell configuration data distribution failed ............................................................................. 204 3.303 eNB is showing ALD Failure alarms .................................................................................... 205



3.304 BTS re-commissioning failed due to OAM cannot remove MHA with empty product code and serial number ..................................................................................................................................... 205 3.305 LTE Conf6 Cell51 remain DISABLED at 15Mhz but works at 10Mhz .................................. 206 3.306 SW fallback(faultID=4083FSMF) occurred during upgrading to RL70 ................................. 206 3.307 High RRC DR Occur after upgraded RL70 MP1.0(LN7.0_ENB_1407_556_04) ................. 207 3.308 LNF7.0:FZM PM Monitoring/missing granularities, GP shift of 1min... ................................ 207 3.309 ALM7654 RF Module failure (1927FXDA) occurred after upgrade to LN7.0_ENB_1407_557_26 ................................................................................................................ 207 3.310 RLF triggered HO fail due to wrong MAC header structure of Msg4(RRCConnectionReestablishment) ........................................................................................... 208 3.311 No Alarm Generated When due to Disabled Cell when configured for Band 4+4 CA. ........ 209 3.312 Passive MHA not shown correctly in Site Element Manager view ....................................... 209 3.313 2xFXEB Shared RF modules connected to LTE FBBC are not completely detected by ESMC 209 3.314 [FRIG+FRLB]：RF module Failure in RP3 interface happened after BTS restart occasionally 210 3.315 LTE1691: Alarm/notification is not raised when 4RX UL Comp is attempted to be activated without connected extension module ................................................................................................. 211 3.316 Duplicate ECGI (LNADJL) Error Monitoring ......................................................................... 211 3.317 [FRIG+FRLB]：FBBC took long time to start up caused RP3 failure alarm after upgrade from RL70 P7.1 to RL70 P8 PP with TMO configuration ........................................................................... 212 3.318 Cell is down when serial number added for passive MHA with recommissioning................ 212 3.319 Incorrect RET parameter after SW upgrade from RL60....................................................... 213 3.320 RP3 alarm (FRIG Fault 10) .................................................................................................. 213 3.321 LTE site in 4G/2G RF-sharing (3xFHEB) doesn't go OnAir with LTE 15MHz antenna configuration ...................................................................................................................................... 214 3.322 FSMF - Timing over Packet, phase synchronization, ethernet multicast communication mode not taken as synchronization source.................................................................................................. 215 3.323 LN6.0 - LN7.0 very long SCFC conversion .......................................................................... 215 3.324 Status of SSH, display of FTM does not change from the state of Disable ......................... 215 3.325 GHOST glibc vulnerability .................................................................................................... 216 3.326 FZM counter M8005C208 and M8005C233 is wrongly generated although LTE macro site shows properly ................................................................................................................................... 216 3.327 FZM stays in RL50FZ after upgrade to RL70 was executed................................................ 217 3.328 [FZM][RL50FZ] BTS operational state OnAir instead Configured (with invalid MME IP ...... 217 3.329 FlexiZone CM Upload Warning for BFDGRP parameter ..................................................... 217 3.330 The difference in value of maxTimeoutCounter between FZM and Macro eNB .................. 218 3.331 Alarm 7651 "GPS receiver alarm not tracking sattelites" is set while GNSS is NOT configured 219 3.332 FlexiZone integration issues - UE can't camp into LNCEL .................................................. 219 3.333 U-plane not working for dedicated IPSec configuration ....................................................... 220 3.334 FlexiZoneMicro start up takes longer time ........................................................................... 220 3.335 eNB does not sent UE Context Release Request when received GTP-U Error Indication .. 220 3.336 NetAct8 EP1 - RL50FZ Build_163_00 - Activating Cell trace fails on FzM, generates a connectivity alarm .............................................................................................................................. 221 3.337 FzM LTE eNodeB: AutoNegotiate on Fiber Not Working ..................................................... 221 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 12/330 Version 1.0 Confidential


3.338 [X21-MBB] Synchronization alarms are present even after the eNodeB is on Air ............... 222 3.339 TRS Alarm Canceled when OMS Upload ............................................................................ 222 3.340 LNFZ5.0_BTSSM_1309_035_00 allows to set lower values for Upper thresholds than for Lower thresholds................................................................................................................................ 222 3.341 TRSW takes on ARM Linux have potential memory leaks................................................... 223 3.342 FZM: FATAL EXCEPTION Nid:0x1234 TYPE:EXTERNAL:[0xEA7C]CpuL2MemoryProtectionFault Violated memory add ........................... 223 3.343 BMgrexe and other like BStatexe, RP1Aexe, BMAexe ARM tasks have potential memory leak issue ........................................................................................................................................... 224 3.344 FZM may become inaccessible over EIF1 backhaul when Ethernet switching is turned on and EIF2 is disabled ................................................................................................................................. 224 3.345 BTS commissioning reconfigure fails when the sync state in unsynchronized .................... 224 3.346 Discrepancy between hardware clock that counts power up time and Linux monotonic clock 225 3.347 1-58494071 : [MBB-X13]-LTE692- Codenomicon: EM connection issue and interface reachability issue ............................................................................................................................... 225 3.348 FZM SW version’s HW unit displayed FWGH despite FWGB in Site Information ............... 225 3.349 Arm CPU1 Starvation; load ~100% with IPSec.................................................................... 226 3.350 Cell down after ToP server restart ....................................................................................... 226 3.351 Bash Environment Variable Handling Code Injection (Shellshock)...................................... 226 3.352 ETWS test fail ...................................................................................................................... 226 3.353 SON - Auto connection does not work ................................................................................. 227 3.354 FlexiZone no PM data with Secure O&M ............................................................................. 227 3.355 Sleeping cell ......................................................................................................................... 227 3.356 RL50: SW upgrade from one load to the same should not be processed............................ 228 3.357 RL50 Flexi Zone: VSWR alarm active for some sites- the sites are not on-air .................... 228 3.358 Cell doesn't get disabled when VSWR major alarm is raised .............................................. 228 3.359 Auto Config / Auto Connection fails to properly commission TRS. ...................................... 229 3.360 RP3 routing collisions are detected on FR module (1958) .................................................. 229 3.361 'TX failure in MIMO” appears and clears after SW downgrade from RL70 to RL60. ........... 230 3.362 RL60 Acceptance HW Inventory Name FYGA .................................................................... 230 3.363 Cell Configuration data distribution failed FDD .................................................................... 231 3.364 FSMF generating IP packet with 16 bytes less than defined in MTU................................... 231 3.365 RF module failure with fault code 1910 ................................................................................ 232 3.366 Fault RF Module failure (1907) with fault id 3010 seen after SW upgrade .......................... 232 3.367 Fault 6259 triggered when setting antennaRoundTripDelay to a high value and when using a radio Module FRHC ........................................................................................................................... 233 3.368 Alarm 'Techn.log buffer freezing' combined with 'unit auto.reset' ........................................ 234 3.369 Unexpected Drop Call counted during S1 Handover Cancel procedure .............................. 234 3.370 GSM-LTE RF sharing: Increased BER detected on the optical connection to Radio Module (1955) alarm....................................................................................................................................... 235 3.371 Counters of the family M51137C* ( top Freq Sync Error ) have values out of range in FSMF HW after RL50_2.1 SW Upgrade....................................................................................................... 236 3.372 No Cell trace send to NetAct with iOMS 71108 alarms........................................................ 237 3.373 SM Missing requirement for max number of possible AaTestPort instances” for features LTE163 (Subscriber and Equipment Trace)/ LTE433 (Basic Cell Trace)/ LTE1049 (Logged MDT) . 237 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 13/330 Version 1.0 Confidential


3.374 Cannot connect LegacyBTS by BTSSiteBrowser ................................................................ 237 3.375 30/40 MHz CA applicable for SMr2 via BTS Site Manager .................................................. 238 3.376 FRMB, FRLB: Increased number of RF module failure alarms 1920................................... 238 3.377 SVMIS Notification 2-276-27185-2015-01-28 (Vuln. ID: 27185) : glibc 2.2 2.18 - Buffer Overflow Vulnerability (aka GHOST) - 2.18 ....................................................................................... 239 3.378 PM counter M8006C134&M8006C143 and M8006C12&M8006C13 are incremented incorrectly with cause tx2relocoverall-expiry...................................................................................... 239 3.379 IPSEC Tunnels do not get re-established after overloading the certificates in FSMR2 ....... 240 3.380 [Vul ID 26899] strongSwan 4.5.0 5.2.1 - IKE_SA_INIT Message Handling Denial of Service Vulnerability - CVE-2014-9221 ............................................................................................. 240 3.381 FSMr2: [Vul id 17338, 22439, 26736] New vulnerability on glibc ......................................... 241 3.382 Fault ID 0418 in RL60 1.1 SW ............................................................................................. 241 3.383 MME and SGW links randomly down with alarm 7657 Base station connectivity degraded 242 3.384 NA8 CUAA for eNB not working .......................................................................................... 242 3.385 FATAL EXCEPTION:[0xEA07A]CpuL1DMemoryProtectionFault Violated memory address(L1DMPFAR) during FiVe stability test ................................................................................. 243 3.386 About CSFB PSHO,the Redirect don't include WCDMA frequency point. ........................... 243 3.387 Lot of RF MODULE ALARMS from LTE 800 FRMA-units ................................................... 244 3.388 MHA gain is not adjustable in a range. ................................................................................ 244 3.389 PNP not using IKEv1 ........................................................................................................... 244 3.390 Ghost vulnerability - CVE-2015-0235 .................................................................................. 245 3.391 BER detected. ...................................................................................................................... 245 3.392 Increase in e-RAB drop rate ................................................................................................ 246 3.393 DSP crash in "second" eNB after SW upgrade .................................................................... 246 3.394 Counters M8001C150 / M8001C266 are fluctuating with new SW ...................................... 247 3.395 RET Alarms Not Displayed .................................................................................................. 247 3.396 VoLTE ADR of QCI1 is worse than other vendors. .............................................................. 248 3.397 Attach impossible on BW = 20MHz...................................................................................... 248 3.398 VoLTE eRAB SR of QCI1 is worse than other vendor’s. ..................................................... 249 3.399 System module failure (412:EFaultId_LostFrameSync) occurred after SW upgrade .......... 249 3.400 RL60 CRL content ignored during authentication IKE phase .............................................. 250 3.401 E-UTRAN HO Preparation Success Ratio, inter eNB X2 based degradation ...................... 250 3.402 FRMB 1920 Alarm after RL40 EP3.2 Upgrade .................................................................... 251 3.403 iOMS openssl.cnf file must be modified to fulfill RL60 EE certificate requirements (Error during cert installation in iOMS) ......................................................................................................... 252 3.404 Security Vulnerability on iOMS - Denial of Service in web application................................. 252 3.405 LTE Multiple sites with Inter eNodeB HO preparation Failure Rate ..................................... 253 3.406 [Security Vulnerability] SSLv3 Padding Oracle Attack Information Disclosure Vulnerability (aka POODLE Attack: CVE-2014-3566) ............................................................................................ 253 3.407 After upgrade to RL50 MP2.1 we see on some enbs remotely only "O+M disconnected alarms" and we have to drive onsite .................................................................................................. 254 3.408 Duplicate eNB Mac address showing in FSM physical interfaces ....................................... 254 3.409 FSMr3: some of the IPsec tunnels stayed down for long time. ............................................ 255 3.410 Unable to send paging over the air due to failure in timer allocation ................................... 255 3.411 After change dlRsBoost, the base station automatic restart ................................................ 256 3.412 LTE1198 RSRQ triggered mobility: Backup plan logical validation failure ........................... 256 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 14/330 Version 1.0 Confidential


3.413 3G-4G LTE uses wrong transmission rules for 20 MHz configuration ................................. 257 3.414 MHA and RET units are not be detected automatically ....................................................... 257 3.415 Abnormal released issue initiated by eNB after upgrading to RL60..................................... 257 3.416 eNB crash due to lot of Srio errors ....................................................................................... 258 3.417 Missing Consistency Check for actFastMimoSwitch==true and dlMimoMode== Dynamic Open Loop MIMO .............................................................................................................................. 258 3.418 FXEB reporting 3-4db lower RX level vs. FXEA .................................................................. 259 3.419 Reno - New RX Scaling Factors for 4G SM ......................................................................... 259 3.420 DSP crash (problem with bit toggling detection and correction) .......................................... 260 3.421 No network connection from Site Manager .......................................................................... 260 3.422 Handover cancel with TEID duplication and Route establishment failed leading to hanging TEID resource .................................................................................................................................... 261 3.423 NWI3 access credentials shown in plain text in the rac_cm_events.log .............................. 261 3.424 Unit autonomous reset after paramater changing ................................................................ 262 3.425 KPI Active UE increased ...................................................................................................... 262 3.426 Changing otnRecoveryPeriod parameter from setting value(5000) to default (500) ............ 263 3.427 [FDSW] Autoconnection IP parameters are not migrated to RAT SW after successful SW Download ........................................................................................................................................... 263 3.428 Fail during configuring 6RX carriers (4xLTE1.4+2xGSM) .................................................... 264 3.429 Open SSL CVE-2014-3567 .................................................................................................. 264 3.430 eNB cells down without any alarm. ...................................................................................... 265 3.431 Actual read-only parameter value 'Serving OMS' missing ................................................... 265 3.432 KPI Active UE increased ...................................................................................................... 266 3.433 After SW upgrade, the value of MaxnumUeul is changed from 10 to 7 ............................... 266 3.434 UL User Throughput degradation after FULA activation. ..................................................... 267 3.435 Site fails to recover IPSec after long TRS outage (23hrs) ................................................... 267 3.436 Multiple IPSec Tunnels between eNB and SEG after SW upgrade ..................................... 267 3.437 Starting HO from queued measurement when UE release decision was already taken and scheduled........................................................................................................................................... 268 3.438 Rl50 sites are all reporting Fetching faults ........................................................................... 269 3.439 PNP not possible with FSMF ............................................................................................... 269 3.440 Alarm "Cell configuration data distribution failed" active in 4 eNB 4 cells ............................ 270 3.441 ETWS test fail ...................................................................................................................... 270 3.442 In installed PC to "BTSSiteEM-LTE60-1311_092_05" and "WN5.0 SEM", it is not possible to SiteManager connection. ................................................................................................................... 271 3.443 Transmission Link Speed alignment failure ......................................................................... 271 3.444 ENB use wrong UEContextReleaseCommand from buffer.................................................. 272 3.445 RF module failure (1907) after SW upgrade ........................................................................ 273 3.446 Alarm 7738 "BTS WITH NO TRANSACTIONS" seen on 2g BTS and fixed after Block/Unblock of 4g RF module......................................................................................................... 274 3.447 BTS autonomous reset as recovery action (4019 FSME) occurred during ADR degradation. 274 3.448 When adding MTRACE on BTSSiteManager for Trace UE specific message for RRC, S1 & X2 there is no option to input any value ............................................................................................. 275 3.449 Incorrect PDCCH capacity estimation .................................................................................. 275 3.450 FRHA was happened RF module failure with FID 1841 ...................................................... 276 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 15/330 Version 1.0 Confidential


3.451 CMP CertConf message not sent after SW upgrade ........................................................... 276 3.452 "Zero attempt" was detected after SW upgrade ................................................................... 277 3.453 FTIB (FSME) got reset due to "FpgaLib: Last reset was: Watchdog reset" ......................... 277 3.454 Unit autonomous reset as recovery action ........................................................................... 277 3.455 DSP reset with fault ID 418 .................................................................................................. 278 3.456 Unit autonomous reset as recovery action detected and recovered(fault =4019) on MRBTS450909 278 3.457 maxNumCaConfUeDc changed after SWACT during upgrade or fallback .......................... 279 3.458 Abnormal high value of PDCP_SDU_UL_LR_QCI6 (LTE_1222A) detected ....................... 279 3.459 RRC connection reject with MAC_UserSetupResp ............................................................. 280 3.460 Increased LTE_5807c (E-UTRAN Avg. Active Ues with data in the buffer for QCI1 DRBs UL) after SW upgrade ............................................................................................................................... 280 3.461 The E-UTRAN Average Latency Downlink (LTE-5134A) count has abnormal values ......... 281 3.462 PDCP config for turning off ROHC fails when UE comes to Nokia eNB from other vendors eNBs by HO with DRB id 1 for QCI 1 bearer ..................................................................................... 281 3.463 Cell load of NonGBR does not decrease even though Active CU is smaller than 1 ............ 282 3.464 FXEA not detected after SW upgrade .................................................................................. 282 3.465 X2HO Preparation fail rate was increasing by RACH problem of target cell........................ 283 3.466 Initial Context Setup Fails with TNL fail happen often on site .............................................. 283 3.467 LNADJ status unavailable .................................................................................................... 284 3.468 Increase in RACH Attempts is seen but no change in the RRC attempts............................ 284 3.469 4019FSPD error in corresponding unit reset recovery ......................................................... 285 3.470 VoLTE call drop during on-hold mode ................................................................................. 285 3.471 Cell state is disabled without alarm ...................................................................................... 286 3.472 High amount of FXFC hardware failure occurrences in the network. WN8.0....................... 286 3.473 More IPSec tunnels setup then configured in eNB .............................................................. 287 3.474 eNB start up delay after SW activation ................................................................................ 287 3.475 RL50 MP 2.0: Sleeping cell on eMarupe_2600 ................................................................... 287 3.476 prachFreqOff changed after SoftWare Activation or reset ................................................... 288 3.477 System Module Failure due to UEC Crash .......................................................................... 288 3.478 UnitAutonomous(52) and KeepAliveStatusError(4019) occurred on FSPC of high load cell. 289 3.479 After RL50 upgrade RETs are not detected and Antenna line device failure alarms raised 289 3.480 Paging messages cannot be sent sometimes to UE in a weak/strong electric field. ........... 290 3.481 Red Hat Security Patches - September 2014 ...................................................................... 290 3.482 70158 FILE SYSTEM USAGE OVER LIMIT in OMS for MySQL_DB_CosNaming ............. 292 3.483 RL 60 Project - G6 Blade: Firnware upgrade failure ............................................................ 292 3.484 The last digit of M8012C133 value is deleted in OMS ......................................................... 293 3.485 Topology DB backup failed as part of USB backup/restore procedure ................................ 293 3.486 Counter HIGH_CELL_LOAD_LB stuck ................................................................................ 294 3.487 Incorrect MCS/maxUlcoderate for SRS frames with FULA .................................................. 294 3.488 Red Hat Security Patches - July 2014 ................................................................................. 295 3.489 UL SINR was degraded in a particular cell with delay of cell setup after eNB restart .......... 295 3.490 FSMF with FRHF: Alarm 1900 is generated after setting minimum Total Loss on antenna 296 3.491 RACH storming with high ATA ............................................................................................. 296 3.492 M8005C4 was 0 even though RRC ATT is counted in cell .................................................. 297 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 16/330 Version 1.0 Confidential


3.493 LED on FBBA/FBBC and BTS Site Manager are not showing fault BTS reset required (fault number 4001) correctly ...................................................................................................................... 297 3.494 Incorrect LED Condition Displayed for Major VSWR Alarm (1837) on FHCA...................... 298 3.495 Third Party cell trace can't restart after trace link disconnected for long duration ................ 298 3.496 Automatic BTS certificate renewal ( 61510) and CRL update failure alarm (61074) --LED display is not Blinking red on HW ..................................................................................................... 299 3.497 RL60_SEC_FTMr2_KUR fails when new single layer CA is used ....................................... 299 3.498 FSM2_LN60: Site Autonomous Reset when GPS is plugged into working eNB ................. 299 3.499 Addition / deletion of 5th VLAN shows an impact on running IPSec operation .................... 300 3.500 Throughput of PCell is affected if SCell has bad radio conditions ....................................... 300 3.501 After deletion of LNADJ using Send All parameter option, related LNREL are not automatically deleted. ........................................................................................................................ 301 3.502 Red Hat Security Patches - June 2014 ................................................................................ 301 3.503 PM counter M8001C8: RACH_STP_COMPLETIONS is not updated correctly................... 302 3.504 Sporadically after system module reset, initialization failure ................................................ 302 3.505 M8001C150 UL_UE_DATA_BUFF_AVG value is ~0.5 of expected value in multi-UE test 303 3.506 UE cannot receive RRC Connection Release after X2 handover from other vendor eNB... 303 3.507 Bad FHEA spectrum which recovers after reset .................................................................. 304 3.508 iOMS cell trace limitation for 1000 eNB needs to be extended ............................................ 304 3.509 Due to missing PUSCH code rate checks for TTI bundling UEs eNB skip decoding in very bad radio conditions ........................................................................................................................... 305 3.510 Fault6259 RF Module Failure occurred during the plan activation which requires cell lock/unlock operation ......................................................................................................................... 305 3.511 M8006C15 PEGGING HIGH ................................................................................................ 306 3.512 Manual Alarm DB upload via TLUI not working [06/2014] ................................................... 306 3.513 KPI LTE_5801D has sometimes abnormal values .............................................................. 307 3.514 StAX Parsing XML Exception appears for LNBTS NEs ....................................................... 307 3.515 Sporadic RP3 Alarm – Third RF module was not detected after the upgrade to RL60........ 307 3.516 Alarm Database Upload Failure from iOMS ......................................................................... 308 3.517 Sleeping site after RL60 SW upgrade .................................................................................. 308 3.518 Cannot make a call on the certain cell when RTT delay is set more than 20000 ................ 309 3.519 FBBA plug-in causes Technical log buffer(6450) and BB failure(1811) faults ..................... 309 3.520 iOMS alarm pipe to NetAct broke time to time with new SW release .................................. 310 3.521 After correction update, Nwi3TUCorba process is not responding [06/2014] ...................... 310 3.522 RF module reset because of additional fault1143 ................................................................ 311 3.523 RP3 Alarm occurred in FBBA after activating LTE1099....................................................... 311 3.524 Technical log buffer Freezing (6450) alarm causes cell lock up .......................................... 312 3.525 Technical Log Buffer freezing(6450FSMF) with Unit autonomous reset(0418FBBA) occurred repeatedly in RL60 PT2.2 .................................................................................................................. 312 3.526 Counter shows wrongly no downlink data (Zero PDCP) for some sites............................... 313 3.527 Significant decrease in ENB data volume and connections since may 1............................ 313 3.528 eNB send Paging message with some timing gap ............................................................... 314 3.529 SON: After get the DHCP IP for 55 seconds, site connection lost ....................................... 314 3.530 Wrong Logical type in M8005C281/2/3 counter description................................................. 315 3.531 F-ULA performance degradation on high speed .................................................................. 315 3.532 Site reset startup time over limit ........................................................................................... 316 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 17/330 Version 1.0 Confidential


3.533 Cell state should not keep active after s1 link has down more than 20 minutes .................. 316 3.534 CS call is not working on shared RRH/RFM and TRX test is also getting failed due to reason “Low power in Abis1-Air3 loop” on shared RRH/RFM at 2G-LTE RF sharing site ............................. 316 3.535 FRHF: SFP hot insert doesn't work...................................................................................... 317 3.536 PNP blocks Certificate Management ................................................................................... 317 3.537 SCFC off-line migration via BTSSM from RL40 to RL60 doesn’t select TRS topology........ 318 3.538 Internal error occurred while configuring DSCP and Message Size parameters for TWAMP sessions ............................................................................................................................................. 318 3.539 MO name did not display right in source from Sitebrowser.................................................. 319 3.540 Longer startup time of LTE Base Station after Site Reset with two extension baseband modules FBBC. .................................................................................................................................. 319 3.541 After upgrade of OMS from RL50 to RL60 RUIM is no more active .................................... 320 3.542 Direct Upgrade RL40_RL60 commissioning error for b2Threshold1GERAN parameter ..... 321 3.543 eNB reset required to switch ethernet to optical connectivity for RACS .............................. 321 3.544 The secondary DNS server is not queried if the primary DNS server returns the query with "no such name" .................................................................................................................................. 321 3.545 [LTE1644-B-a] [FRMC] Recovery control after Hot insert-removal of RF module without BTS Reset is failing.................................................................................................................................... 322 3.546 [FRHC] VSWR tuning .......................................................................................................... 322 3.547 [RF Sharing LTE-GSM] GSM TRX Tests fails after LTE BW change. ................................ 323 3.548 RL50 IPSEC conf dpd action parameter wrong (restart instead of clear) ............................ 323 3.549 FTIB : Partial drop in chained traffic when uplink u-plane traffic is sent simultaneously ...... 324 3.550 MHA current window alarms (1834 and 1835) not reported in SEM after RF module block/unblock ..................................................................................................................................... 324 3.551 Fragmented ESP Reassembly Failure for a range of Packet sizes ..................................... 325 3.552 Decreased intra eNB HO success rate if rekeying is used .................................................. 325 3.553 Restore of iOMS failed ......................................................................................................... 326 3.554 FSMF fasttune does not work for SyncE, no alarm displayed ............................................. 326 3.555 iOMS issue with backup archive naming ............................................................................. 327 3.556 No cronjob possible as user Nemuadmin ............................................................................ 327 3.557 PUCCH RSSI Values are differents between FXEA and FXEB........................................... 328 3.558 FSPC unit autonomous reset with faulty 4019 - UEC crash in function ............................... 328 3.559 7654 System Module Failure spurious alarm due to RET failure ......................................... 328

Contact: Contact your local Nokia Solutions and Networks support

Summary of changes: 10-December-2015

1.0

Approved





1. OVERVIEW List of Generic Faults describes the current unsolved problems affecting the functionality of the Flexi LTE Base Station and LTE iOMS, as well as the corrections made to the existing problems. Chapter 2 lists opened generic problems Chapter 3 lists solved generic problems The problem descriptions are structured as follows: Problem title: Title of the problem Problem report: Problem ID number Exists in: Product and software release in which the problem exists Correction Target / Corrected in: Product/software release in which the problem is either fixed or planned to be fixed Severity: • Critical • Major • Minor Customer Impact: Area of impact • Capacity & Performance • New feature/functionality • Operation & Maintenance • Security • Stability Description: A short description of the problem and in the corrected cases also a description of the correction. Attached PR: Related Fault reports attached with same root cause. This field is optional. Probability: • Rare: 1-2 cases during an observation period

• Seldom: few times during an observation period • Occasional: seen several times (5-10) during an observation period • Permanent: will occur always when a configuration or a feature is used Solution / Workaround: Describes method to avoid the problem or minimize the defect impact before the actual correction is available Impact to Operator: A description of what will be the most likely phenomena seen in the network because of the problem Impact to End user: A description of problem on the End user maintenance



2. OPENED GENERIC FAULTS 2.1 RF alarms 1910/1920 observed after upgrade

Problem report: NA05860820 Exists in Release: LN7.0 Correction Target: RL70 2.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05860820, PR074934 Probability: Occasional Description: Summary of the original problem: 1910/1920 alarms were observed on site. Description of the fault: 1. There was issue with samples misaligned TX vs FB. 2. False FilterInputPowerMissing 1910 alarm was raised when carriers were activated/deactivated one by one in short period of time. Solution / Workaround: Description of the correction: 1. After correction in specification there was implemented fix for better alignment of TX and FB samples. It fixed the false 1910 alarms. 2. 1910 alarm counter reset in case of carrier activation/deactivation Impact to Operator: Partially reduced downlink functionality. Impact to End user: Reduced signal range.

2.2 Missing oms agent in monitor

Problem report: NA05859000 Exists in Release: LTE15A_OMS Correction Target: LTE15A 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Operability Attached PRs: NA05808467, NA05859000 Probability: Permanent Description: Topology upload to NetAct 15.2 (or later versions) will cause problem for disconnected Network Element. Topology upload does not include disconnected NEs that will cause problem on NetAct site. Solution / Workaround: No workaround. Impact to Operator: Topology upload does not include disconnected NEs which will cause problem on NetAct site. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 21/330 Version 1.0 Confidential


Impact to End user: No impact



2.3 After BTS site is onair, FBIH 1 that is assigned to cell3 and cell4 still show gray on SEM

Problem report: PR083791 Exists in Release: FL15A Correction Target: FL15A 0.1 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: PR083640, PR083791, PR089519, PR093510 Probability: Permanent Description: Configuration: 3FHFB/3FRIG/3FRLB (total 9 Radio Modules), 2 FBBCs. After site reset during BTS startup, it is noticed that FBBCs are in configuring/working state and then suddenly they go to “not detected state”. All cells come on air including the ones connected to FBBCs, but FBBCs still show “not detected” in BTS Site Manager. Solution / Workaround: No workaround. Impact to Operator: In configurations with 9 cells and 2 FBBCs the state “not detected state” of the FBBCs in BTS Site manager is wrong. All cells come on air including the ones connected to FBBCs, but FBBCs still show “not detected” in BTS Site manager. Impact to End user: No impact.

2.4 Application Launcher Server is not responding

Problem report: NA05857552 Exists in Release: RL70_OMS Correction Target: OMS_FL15A 0.2, OMS_FL15A 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Operability Attached PRs: NA05843185, NA05843437, NA05851203, NA05854789, NA05857552, PR090631 Probability: Occasional Description: Occasionally Application Launcher Server is not responding. Solution / Workaround: Restart NWI3 Adapter by (fshascli -r /NWI3Adapter) Impact to Operator: Occasionally Application Launcher Server is not responding. Impact to End user: No impact.

2.5 System Module failure (0010) alarm after upgrade from RL70 to FL15A

Problem report: PR089393 Exists in Release: FL15A Correction Target: FL15A 0.2, FL15A 1.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 23/330 Version 1.0 Confidential


Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: System Module failure (0010) alarm after upgrade from RL70 to FL15A - FSPD1. Site cannot be recovered with site reset, needs to be rolled back to previous software. Fault is not reproducible in lab environment. Solution / Workaround: No workaround. Impact to Operator: System Module failure (0010) alarm after upgrade from RL70 to FL15A. Impact to End user: Long service outage during upgrade and rollback.



2.6 [FL15A] [FSMr3] Unit autonomous reset as recovery action

Problem report: PR089757 Exists in Release: FL15A Correction Target: FL15A 0.1; FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR089757, PR090078, PR090546 Probability: Permanent Description: Summary of the original problem: In high load scenarios, UE attach procedures fail and lead to sleeping cell or crash in LTE L2. How end user/operator could detect the problem: Sleeping cell or crash Description of the fault: UL overload protection in LTE L2 has too loose tresholds for activation and too tight for deactivation. This leads to a situation where LTE L2 rejects all the incoming UL MAC TBs. Therefore all UE attach procedures are failing. Solution / Workaround: Workaround: Reset needed Description of the correction: The tresholds for overload protection are modified. So the overload protection is activated less frequently. And, when activated, it is deactivated more easily. Risk analysis of the correction: The risks are low, since only the treshold values are modified, not the code logic. Impact to Operator: Service interruption on the eNB, possible load increase in the neighboring eNBs without alarm indicating the issue. Impact to End user: Calls can’t be made.

2.7 [LN7.0 2.0][FSMr3]: M8001C151 (Max number of UEs with buffered data in UL) counter starts reporting abnormally high values during stability test

Problem report: NA05857831 Exists in Release: LN7.0 2.0 Correction Target: RL70 2.1; FL15A 1.0 Severity: B - Major Customer Impact: Capacity & Performance Attached PRs: NA05857831, PR091252 Probability: Occasional Description: Summary of the original problem: M8001C151 counter starts reporting abnormally high values. Description of the fault: M8001C151 value was calculated so that for each index the counter value got LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 25/330 Version 1.0 Confidential


amount of active UEs from all ueGroups Solution / Workaround: Description of the correction: M8001C151 value is now calculated by index. Impact to Operator: M8001C151 value is too high Impact to End user: No impact



2.8 [FSMr3] [FL15A] Cell_config_data_distribution_failed(6253)

Problem report: PR091340 Exists in Release: FL15A Correction Target: FLA15A 0.1; FLA15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Summary of the original problem: Hanging UE service due to missing response for tunnel release from UEC Ipcs subsystem. Description of the problem: Wrong handling of tunnel release in TRSW lead to improper deletion of some random path in UEC in case path release attempt happen during HO after connection modification request in target cell but before acknowledging it to the source cell. Race condition between intra-eNB HO and path removal due to cell deletion, connected with new OSAID being by accident used for some other path in source cells UEC thread. Solution / Workaround: Workaround: Disable intra-eNB HO Description of the correction: Corrected handling of acknowledged removed paths. Path is only removed if given OSAID removal was really requested, and not only if it by accident exist for some other UE / tunnel. Impact to Operator: Cell outage as a result of failed cell locking. Impact to End user: Prolonged service interruption.

2.9 Unexpected Failure in optical interface alarm (0010) on FRIG cell in faulty state

Problem report: PR093701 Exists in Release: FL15A 0.1 Correction Target: FL15A 0.1; FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Rare one occurrence Description: Dirty IP routes to radios via fbbc on system module. Radio module not detected correctly. Solution / Workaround: Workaround: Site reset. Description of the correction: IP routes are cleared on startup. Impact to Operator: Alarm 10 on radio module. Impact to End user: Limited or no connectivity.



2.10 iOMS rehome failed for some eNBs due to parameter issue

Problem report: NA05852567 Exists in Release: LN7.0 Correction Target: RL70 2.1; FL15A 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: iOMS rehoming (also known as iOMS switchover) was tried for 6000 sites. It failed in 200 sites with the following warning in NetAct: Mandatory parameter "lowValue" is missing in the config file uploaded by the eNB. Root cause: Parameter missing. Correction: The parameter for this issue is available from FL16 release onwards. l2VlanIdlist is the parameter, it has highValue - default -1, lowValue - default 0. Solution / Workaround: Ensure that for ETHLK-0-2, lowValue = 2, and highValue = 4094. If this is configured for all the sites, then the problem will not occur. Impact to Operator: iOMS rehoming failed with a warning in NetAct. Impact to End user: No impact.

2.11 (RL70) the processin of DM stopped, LED of EIF 2 off, eNB cannot get temporary IP

Problem report: NA05854549 Exists in Release: LN7.0 1.0 Correction Target: LN7.0 2.0 Severity: B - Major Customer Impact: New feature/functionality Attached PRs: Probability: Rare one occurrence Description: The processing of DM stopped, LED of EIF 2 off eNB cannot get temporary IP. Due to Device manager (DM) observers hang Auto connection (AC) is not able to send DHCP DISCOVER messages to DHCP server which results AC DHCP state entering into infinite loop. Description of the fault: Due to DM observers hanging auto connection DHCP state will not be completed, which results AC is entering into infinite loop and not able to send DHCP DISCOVER messages out of eNodeB. Faulty component and version: TRS and FTM_R3_LN70_LNT50_FZM55_WN9010_MP1_463.00.01 Solution / Workaround: Made code changes to try DHCP state only 60 seconds which will prevent AC entering into infinite loop Impact to Operator: Auto-Connection feature will not work as expected Impact to End user: No impact LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 28/330 Version 1.0 Confidential




2.12 Some cells are Disabled after SW upgrade due to alarm 4008 (Power level not supported)

Problem report: NA05857704 Exists in Release: FL15A Correction Target: FL15A 0.1; FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: After SW upgrade 3 cells are Disabled due to alarm 4008 (Power level not supported) is Active on FRIE. Recommissioning to set cell power to a supported power level is needed to clear the alarms. This means that 10W cannot be used because it is not available in Site Manager drop down menu. Root cause: Incorrect merge of FRIE .101 hw variant of TX parameter Tx.Carrier.Max.Pa.Power. Correction: Correctly insert values of property Tx.Carrier.Max.Pa.Power into infoModel. Solution / Workaround: Operator can choose different power level to get L3Call. Impact to Operator: Cells will be down causing outage. Impact to End user: Service degradation. Calls are dropped or not possible.

2.13 RL70 Mp1.1-MP2 upgrade failed on sites

Problem report: NA05857941 Exists in Release: LN7.0 2.0 Correction Target: RL70 2.0, FL15A 0.2, FL15A 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Summary of the original problem: Problem to merge RNW.xml to InfoModel How end user/operator could detect the problem: rrom sends create MO to BTSOM and sends update/delete of the same MO in a short period. Solution / Workaround: Avoid the race condition. Impact to Operator: It is occasional issue, and it is possible that: 1 operator cannot upgrade eNB load to newer one (the appearance in this PR) 2 reconfiguration may fail (full reconfiguration works well). 3 After reset, it is possible that eNB cannot reach onAir. Impact to End user: End-user will be served via old eNB load, and if eNB cannot reach onAir, end user will be out of service.



2.14 No Traffic 4G MRBTS-506488 Post 4019 autonomous FSP restart (add info 52)

Problem report: NA05855279 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.1 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Simultaneous UTRAN ANR inactivity for different UEs caused UECexe crash. Root cause: Simultaneous read operations performed on boost::circular_buffer were not supported (not thread-safe) due to enabled "debug support" for circular_buffer. Solution / Workaround: Correction: The problem was fixed by disabling this “debug support” functionality. Workaround: Disable LTE908 UTRAN ANR functionality. Impact to Operator: Sporadic unit autonomous reset (frequency depends eg. on the number of connected UEs and LTE908 configuration). Impact to End user: Call drop, no service for a few minutes.

2.15 eNB does not generate PM data after SW activation

Problem report: NA05857875 Exists in Release: FL15A Correction Target: FL15A 1.0; RL70 2.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: eNB does not generate PM data after SW activation. Root cause: PM maybe do repeat measurement schedule when timesync at the time interval. Solution / Workaround: No workaround. Correction: Add a local variable to record the last measurement time. If the next measurement time equal last measurement time, skip this schedule. Impact to Operator: PM data not generated. Impact to End user: No impact.



2.16 High RSSI is seen on multiple sites

Problem report: NA05857170 Exists in Release: FL15A Correction Target: FL15A 0.1, FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05857170, NA05857845 Probability: Permanent Description: Average PUSCH RSSI in the network is increased. Lots of small (1 PRB) grants on PUSCH without data transmission. Those small allocations on PUSCH are smart-DRX related dummy grants which are meant to restart the drxShortCycleTimer. But they are occurring much too often. The RSSI is increased because powerlimited UEs will transmit 1 PRB with a higher power density than N PRBs. Root cause: The fault was caused by a refactoring of the DRX functionality needed for DL CA. The result is that the dummy grants don't stop when one grant is given, instead they continue until the drxShortCycleTimer is actually restarted or the short-term inactivity timer expires. Correction: Only give one dummy grant to restart the drxShortCycleTimer. Solution / Workaround: Set drxShortCycleT = smartStInactFactor. Impact to Operator: Interference increases in UL. Impact to End user: No impacts.

2.17 Three cells on FRLB are not working. Cell state is Disabled

Problem report: NA05858509 Exists in Release: FL15A Correction Target: FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Summary of the original problem: All cells with at least one channel going through MHA does not go to onAir. Dependency on configuration: MHA connected to 2 RMODs connected to SMOD. Faulty component and version: BTSOM Faulty component first delivered in(e.g. release, CD): xL15A Solution / Workaround: Workaround: No workaround Description of the correction: If Cell Channel antennaDN parameter points to antenna connected to MHA, then path to radio module is determined basing on internal MHA structure. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 32/330 Version 1.0 Confidential


Correction effects: all Cells go to onAir. Impact to Operator: Cells are down, cell state audit alarm is visible. Impact to End user: No user activity can be made on cells affected with that problem.



2.18 High GSM drops on some GSM/LTE RF sharing sites

Problem report: NA05858182 Exists in Release: FL15A Correction Target: FL15A 1.0 Severity: A - Critical Customer Impact: Capacity & Performance Attached PRs: Probability: Permanent Description: Configuration: 2G and 4G SM connected to RFMs. After SW upgrade on 4G side the 2G KPIs are getting bad. After site reset on 4G side everything goes back to normal. LTE RSSI level for PUSCH will increase 40dBm. There is something wrong in receiver part in RF module after reset. Same problem seen in GSM side also. Root cause: RSSI alarm on BTS caused by elevated RX power seen on RFM. This higher RX level on RFM is caused by change of 1 bit in analog-to-digital converter register (data format from ‘2’s complement’ to ‘offset binary’). Solution / Workaround: No workaround. Correction: In VEGAS software, at the middle layer in driver for ADC read/write a verification of control words was introduced. An algorithm was inserted which is fixing one bit in particular control word. This bit should not be different than designed. Impact to Operator: KPI degradation on 2G side in RF Sharing configuration 2G/4G after SW upgrade on 4G side. Impact to End user: Service degradation, higher drop rate on GSM.

2.19 WMP-FDD\FL15A\LTE1058: Core dump and DUT crashing observed after sending IPv4 ACPAR values for Plug and play auto-connection.

Problem report: PR100413 Exists in Release: FL15A Correction Target: FL15A 1.0 Severity: B - Major Customer Impact: Probability: Permanent Description: Core dump and DUT crashing observed after sending IPv4 ACPAR values for Plug and play auto-connection.Crash was due to wrong format specifier used in log file writing. Solution / Workaround: Correction: Typecasted the log content properly according to the format specifier. Impact to Operator: System doesn't comes up after autoconfiguration. Impact to End user: System not up. No connectivity to oms. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 34/330 Version 1.0 Confidential




2.20 After upgrade from RL70 0.2.6 to RL70 1.2.3 FBCC remained in state configuring

Problem report: NA05852978 Exists in Release: LN7.0 Correction Target: RL70 2.1; FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: After SW upgrade FBCC remained in state configuring with alarm BTS reset required (4001). Cells are in faulty state and a new site reset was needed to recover the eNB. Root cause: CellP requested to delete MHA and when this request was processing by ADET, real RMOD is detected and CellP requested to add CABLNK between already detected RMOD and MHA which deletion process is started. As result we have additional CABLNK connected from RMOD to MHA which doesn’t exist. Correction: Fixed by adding “memory” to CellP to not add CABLNK to devices which deletion is already requested. Solution / Workaround: No workaround. Impact to Operator: After SW upgrade FBCC remained in state configuring with alarm BTS reset required (4001). Cells are in faulty state and a new site reset was needed to recover the eNB. Impact to End user: Service degradation as long as the cell is down.

2.21 PDCCH order not send (UE stay RRC connected even though eNB released RRC connection)

Problem report: PR100750 Exists in Release: FL15A Correction Target: RL70 2.1; FL15A 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: PDCCH order not send (UE stay RRC connected even though eNB released RRC connection) Description of the fault: MAC-PS sent final out of sync during RRC connection release procedure. As a result RRC connection release was not sent to the UE. Final out of sync was triggered by a timer which should avoid hanging UE contexts in MAC-PS but calculated timeout value was too short. Solution / Workaround: Description of the correction: Timer that supervises the release of the MAC-PS context after UE went out of sync is increased. Impact to Operator: No impact. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 36/330 Version 1.0 Confidential


Impact to End user: Calls go to voice mail.



2.22 850 refarming issue with FXCB on WN9.1 3.0 & RL70 1.1

Problem report: NA05859380 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.1 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Summary of the original problem: On 3G-4G RF sharing, After 3G SW upgrade from WN9.1 2.2 to WN9.1 3.0, LTE cell down with RF module configuration failure (1900) alarm. How end user/operator could detect the problem: LTE cells not operational and RF module configuration failed alarm is active. Description of the fault: LTE OAM tries to create BusNode MO with wrong configuration, using slot 4. Latest RF SW’s (part of WN9.1 3.0) validates RP1 parameters hence causing this failure. Solution / Workaround: Workaround: Rollback WCDMA SW or upgrade LTE to FL15A Correction: BusNode slot calculation has been updated in LTE OAM. Impact to Operator: LTE cell off AIR. Impact to End user: No service.

2.23 [FL15A][FSMr3] Autonomous reset after changing cell's administrative state to unlocked Problem report: PR097679 Exists in Release: LN7.0 1.1 Correction Target: FL15A 0.2, FL15A 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: PR093306, PR094584, PR095062, PR100576 Probability: Ocassional Description: BTS autonomous reset after cPlaneIpAddressSec Solution / Workaround: No workaround. Description of the correction: Code to check if TRS is waiting for creating directory /tmp/iptables_test Impact to Operator: It will cause unwanted reset of BTS. Impact to End-user: Service loss during restart.



2.24 Missing B2 Report Configuration to GSM with MODPR with Autoadapt=false

Problem report: NA05849712 Exists in Release: LN7.0 Correction Target: RL70 2.1, FL15A 0.2, FL15A 1.0 Severity: B - Major Customer Impact: User Plane Quality Attached PRs: Probability: Permanent Description: Measurement that is using geran meas object was activated only when: - one of the arfcn values from lnhog was present in the proper list in mobility profile (for srvcc or enacc), - the same frequency was used by at least one of the geran neighbors (configured in adjg + lnrelg). This was not correct, as measurement should be activated when one of the frequencies from lnhog was found in mobility profile, and there was a neighbor using a frequency (potentially different) from that lnhog. Root cause: Wrong conditions was used to activate the measurement. Correction: Condition to activate measurement using geran meas object was changed, so there is no need to have the same arfcn in mobility profile and one of the neighbors. Now it is sufficient to have one arfcn from lnhog supported in mobility profile, and neighbor using any of the arfcn values from that lnhog. Solution / Workaround: No workaround. Impact to Operator: Missing B2 Report Configuration to GSM with MODPR with Autoadapt=false. Impact to End user: No SRVCC to GSM mobility will be provided to UEs which are assigned to the default profile.

2.25 Unit autonomous reset of FBB/FSP on multiple sites caused by MTRACE parameter change

Problem report: NA05861636 Exists in Release: FL15A Correction Target: FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: After Online recommissioning regarding MTRACE Unit autonomous reset on FBB/FSP cards occurs. Site recovers autonomously after few seconds. Root Cause: The crash of LOM was caused by receiving of LOM_TracingCtrlStopProviderReq from LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 39/330 Version 1.0 Confidential


RROM for not existing cell (i.e. cell which was already deleted). Solution / Workaround: No Workaround. Site recovers autonomously. Correction: Now LOM handles such situation. Should not crash when LOM_TracingCtrlStopProviderReq is received after cell deletion. NOK response is send by LOM to RROM in such situation. Impact to Operator: Cell availability / KPI degradation. Impact to End user: Call Drop and service outage during FSP reset and recovery.

2.26 2.25 Certificates are missing after upgrade to FL16 when IPSEC is configured Problem report: NA05852131 Exists in Release: FL15A Correction Target: FL15A 0.2, FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05852131, R089153, PR095997 Probability: Permanent Description: Multi-layer certificates are lost after upgrade when IPSEC is configured. IPSEC tunnels can't be established after upgrade. Root cause: Encfs mounting of "/ffs/run/trs_data/active/.keystorage" folder to "/ffs/run/trs_data/active/keystorage" is failing due to “.ecnfs6.xml” file corruption in ".keystorage" folder, hence certs are lost after upgrade. Correction: Change to copy the contents from /ffs/stb/trs_data/active/keystorage to /ffs/run/trs_data/active/keystorage during upgrade. Solution / Workaround: Remove CMP/CA address before an upgrade in Certificate Management window, and send changes. Impact to Operator: Connection to eNB is lost. Impact to End-user: No impact



2.27 Conversion between RL70 and FL15A software showing problems during recommissioning with prachFreqOff parameter

Problem report: NA05861466 Exists in Release: FL15A Correction Target: FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: After SW upgrade, recommissioning not possible due to prachFreqOff being outside range. Root cause: Migration related to n1PucchAn is defined incorrectly due to misunderstood relations. Solution / Workaround: No workaround. Correction: There is added actDLCAggr parameter value "true" as precondition for n1PucchAn migration. Impact to Operator: After SW upgrade, recommissioning not possible due to prachFreqOff being outside range. Impact to End user: No impact.

2.28 LTE_5801d Average Active UEs with data in the buffer UL KPI is rising

Problem report: PR101852 Exists in Release: FL15A Correction Target: FL15A 0.2, FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: In some scenarios LTE_5801d/M8001C150/M8001C266 are increasing while later that value is not decreasing. How end user/operator could detect the problem: LTE_5801d/M8001C150/M8001C266 exceeds real number of UEs with buffered data. When UL transmission is stopped (no UEs with buffered data) nonzero values could be reported Description of the fault: Incrementation of number of UEs with buffered data was done not in proper place in the function. Faulty component and version: MAC_PS fb15_03/fb15_09 Solution / Workaround: No workaround Description of the correction: Redundant method call is removed Impact to Operator: Operator see that buffered data values are high in UL direction. Incrementation of number of UEs with buffered data was done not in proper place in the function and eNB is not performing as it should be in case of UL data is transferred. Impact to End user: Low UL tput in case of fault occurs. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 41/330 Version 1.0 Confidential


2.29 LTE908 Select always same ANRPRW profile

Problem report: NA05855370 Exists in Release: LN7.0 Correction Target: FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Selection algorithm choose carrier which has the highest number of unknown neighboring cells, or till measurement report still contained unknown neighboring cells. In case when UE did not send measurement report, permanently is selected same carrier till all unknown neighboring cells will be known. Solution / Workaround: Selection algorithm has been changed that carriers are selected in round robin. Initial selection is executed that carrier with lowest frequency value is taken as first (if UE is capable) Impact to Operator: Instead of learning one carrier till no unknown neighbors exists, carriers will be considered in parallel. Impact to End user: Shall be not visible to end user.

2.30 E-RAB drop after FL15A upgrade and some sites having PS call issues

Problem report: NA05862557 Exists in Release: FL15A Correction Target: FL15A 1.0 Severity: B - Major Customer Impact: User Plane Quality Attached PRs: Probability: Permanent Description: If the customer performs S1-U GTP link supervision based on SGW sending GTP echo requests and if no LNBTS/GTPU object exists in eNB DB for this SGW or if this GTPU object has parameter "GTP-U path supervision interval" set to 0, the eNB does not reply to GTP echo requests sent by SGW. As a consequence the SGW considers the S1-U link to eNB to be broken, which might lead to call releases. Solution / Workaround: Configure eNB based GTP link supervision by creating LNBTS/GTPU object for eNB. Impact to Operator: Increase of ERAB drop rate and related KPI degradation. Impact to End-user: Increase of call drops.



2.31 TRS commissioning data lost after upgrade to RL70 1.1

Problem report: NA05864297 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.1; FL15A 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Station would limit itself to 2 bytes when reporting btsId to the network. Additionally, a race condition would make the btsId 0 in some circumstances. This would make autoconfiguration and configuration from netact impossible, especially for sites with btsId bigger than 65535. Solution / Workaround: Solution: remove the 2 bytes limitation and introduce correct synchronization. Workaround: none, except using lower btsId. Impact to Operator: Inability to commission the station on the new software. Impact to End user: No impact.

2.32 FSMF - Timing over Packet, Phase synchronization, PTP correction field, Interoperability with transparent clock, TC

Problem report: 154900ESPE02 Exists in Release: FL15A Correction Target: FL15A 1.0 Severity: B - Major Customer Impact: New feature/functionality Attached PRs: Probability: Permanent Description: eNB utilizes information from the Correction Field used by Transparent Clock nodes in the Sync and Delay Response Messages in IP unicast/Ethernet multicast communication mode using PTP one-step mode, but does not support the usage of information from the Correction Field used by Transparent Clock nodes in the Sync, Follow Up and Delay Responses Messages in IP unicast/Ethernet multicast communication mode using PTP two-step mode. A populated Correction Field in Sync, Follow Up and Delay Response messages in PTP two-step mode leads to loss of phase synchronization of eNB. Therefore the usage of Transparent Clocks with PTP two-step mode within the communication path between ToP Slave eNB and ToP Master shall be avoided. Solution / Workaround: Usage of Transparent Clocks with PTP two-step mode within the communication path between ToP Slave eNB and ToP Master shall be avoided. Impact to Operator: Loss of eNB phase synchronization. Impact to End user: Service degradation. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 43/330 Version 1.0 Confidential


2.33 LNCEL out of use with the alarm "Distributed site supported not enabled" after SW upgrade Problem report: NA05839469 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: B - Major Customer Impact: Capacity & Performance Probability: Occasional Description: Site use single mode fiber and total distance won’t over 15 Km. After SW upgrade it triggered "Distributed site supported not enabled" in particular LNCEL and this LNCEL is not working (before upgrade this LNCEL is working). The 1st RFM is affected. The distance between system module and radio module is not evaluated correctly. Root cause: The minDelayFactorValue in OBSAI_AXCDELAY was wrong calculated due to selected max minDelay value from all bandwithes in RU_BP::delayRanges instead of by value from LNCEL::xlChBw. Correction: According to specification max value of minDelay from RU_BP::delayRanges is determined by LNCEL::xlChBw values. Solution / Workaround: No workaround. Impact to Operator: After SW upgrade alarm 4076 "Distributed site supported not enabled" was raised in particular LNCEL and this LNCEL are not working. Impact to End user: Service degradation.

2.34 VOLTE Quality Trial: DSCP and SGW IP change Problem report: NA05845640 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Probability: Occasional Description: Three identical eTeids in IpcsOriginatingReleaseRequest triggers Gtp_ResetRequest msg with duplicated eTeid and Osaid. The (correct) Gtp_ResetConfirm msg causes a trigger of initialReset in TRSW. This could happen in following scenario: - InitialContextSetupServiceRequest with 3 or more bearers - Then timer expired for RrcConnReconfComplete and InitialContextSetupServiceRequest failed. - UEC receives: evaluateTupuBearerDeleteResp() payLoadId:TUP_BEARER_DELETE_RESP_MSG negative response status:1 cause:0 specificCause:1 The negative response was caused by duplicated drbIds sent in BearerDeleteReq msg from UEC to L2. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 44/330 Version 1.0 Confidential


- UEC tries to release TRSW resources by triggering IpcsOriginatingReleaseRequest with 3 identical eTeids. - But 3 times the same eTeid cause the trigger of first Gtp_ResetRequest with 2 identical eTeids and then the trigger of initialReset in TRSW. Solution / Workaround: Fill list of indexes of bearers that need to be released by TUP_BearerDeleteReq message during failed service request with values from 0 to n, where n is equal to number of bearers stored in UE context. Impact to Operator: After failed ICS with 3 or more bearers TRSW will trigger reset all connections. UEs starts to send data to wrong SGW IP. Impact to End user: After failed ICS with 3 or more bearers for one user, all UEs connected to the same GTP tunnel starts sending data to wrong SGW IP which causes that this data is lost.

2.35 Cell outage "Not enough HW for LCR" Problem report: NA05843950 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: B - Major Customer Impact: Capacity & Performance Probability: Occasional Description: In sites configured with multiple UlComp groups with different bandwidths occasionally a BTS config error "Not enough HW for LCR" is visible. Affected cells are down. Root cause: Not all cells are allocated during UPlane deployment calculation due to wrong order of BBPool assignment of cells. Fault 1868 EFaultId_NotEnoughHwForLcrAl is detected and UPlane deployment calculation is Partial success. Solution / Workaround: No workaround. Correction: Fix the sorting of cells to be allocated before UPlane deployment calculation such that those in UlComp groups with higher bandwidths have the priority. Impact to Operator: Cell outage due to BTS config error "Not enough HW for LCR". Impact to End user: Service degradation if cells are not available.

2.36 Alarms 3000 (EFaultId_SystemModuleFailure) and 1836 (EFaultId_ALOvercurrentAl) Problem report: NA05840591 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 45/330 Version 1.0 Confidential


Probability: Occasional Description: Alarms 3000 (EFaultId_SystemModuleFailure) and 1836 (EFaultId_ALOvercurrentAl) occur on sites with FSMF. eNB restarts from time to time. Root cause: Issue is strictly related to UTRAN incoming handovers. Nokia eNB reads part of Handover REQ msg, which is unitialized. Reading uninitialized values can lead to unexpected crashes. In details: Even though asConfig (handoverPreparationInformationR8) structure was not included in Handover REQ msg, UEC read drbToAddModList field which belongs to asConfig. In such case, values of drbToAddModList are undefined and reading them can cause a crash. Solution / Workaround: No workaround. Correction: Additional check will be introduced not to access as-Config structure in case when UTRANLTE Handover takes place. Impact to Operator: Handover UTRAN-LTE can cause eNB to crash. Impact to End user: Service degradation during eNB restart.

2.37 Vendor Certificates missing in Flexi Zone. Problem report: NA05844545 Exists in Release: LNF7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance When Customer Initializes IPSEC during Deployment then Customer may observe Vendor Certificates missing due to File Permission unavailability to load the certifications. Due to this Site's will not be able initialize IPSEC in their Setups. Workaround is to change the File Permissions. Probability: Occasional Description: Vendor certificate is missing from upgrade from RL50 to RL70 Operator is not able to see vendor certificate, IPSec connection not possible. Solution / Workaround: Workaround: Need to change permission of vendor certificate. Description of the correction: Vendor Certificate Private key doesn’t have permission for group/others. The Root Cause of this issue is, A process called CertMgr is trying to read the content of the private key, since that comes under group/others doesn't have permission, hence the issue is observed, now giving the permission to other at the TRS startup. Permissions might be changed manually by adding chmod 644 to /etc/keys.d/private/* Impact to Operator: Cannot establish IPSec tunnel. Impact to End user: IPSec connections not available.



2.38 After LN7 activation the sites loose O&M Problem report: NA05842431 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.0, FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05842431, NA05846951 Probability: Permanent Description: If any of the application address is defined as x.x.x.0, then all incoming packets addressed to that application will be dropped in eNB and corresponding alarm indication S1 interface down will be raised. Solution / Workaround: Make sure that none of the application addresses are in format x.x.x.0 before start of SW upgrade. Impact to Operator: S1 interface for either U/C/M/S plane will be down depending upon which of those application has IP in format x.x.x.0. If x.x.x.0 is for M-plane then O&M loss will be observed, if it is for C/U plane then network outage will be observed. Impact to End user: No impact

2.39 Huge amount of 71058 alarms generated Problem report: NA05845152 Exists in Release: RL70_OMS Correction Target: OMS_RL70 2.1 Severity: A - Critical Customer Impact: Operation & Maintenance Operability Probability: Occasional Description: Disconnection alarms (71058) are being received, since BTSOM resets TCP connection when FM (Fault Management) does not process "alarmObservations" if NEList is being updated. Solution / Workaround: No workaround. As a solution FMAdapter replies AckNack with NackReason busy to BTSOM for the AlarmObservations received when the NEList is updated. Impact to Operator: Critical Alarm (71058) NE Disconnected is raised several times. Impact to End user: No impact



2.40 Failing Consistence Check for MaxNumQci1Drb Problem report: NA05841429 Exists in Release: LN7.0 Correction Target: FL15A 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: Although the switch actEnhAcAndGbrServices is set to true the Consistence Check for MaxNumQci1Drb fails in case the following condition is not fulfilled: maxNumQci1Drb must be half or less than maxNumActDrb, i.e. maxNumQci1Drb <= maxNumActDrb/2 (each GBR-DRB is counted as normal DBR as well). With activated switch actEnhAcAndGbrServices the parameter MaxNumQci1Drb should be ignored. Solution / Workaround: No workaround. Impact to Operator: Although the switch actEnhAcAndGbrServices is set to true the Consistence Check for MaxNumQci1Drb fails. With activated switch actEnhAcAndGbrServices the parameter MaxNumQci1Drb will not be ignored as expected. Impact to End user: No impact.

2.41 After eNB restart, duplicate LNREL that generated by earlier bump up and alarm 7650 will be trigger Problem report: NA05847375 Exists in Release: LN7.0 Correction Target: FL15A 1.0 Severity: B - Major Customer Impact: Capacity & Performance Probability: Occasional Description: There will be duplicated LNREL and triggered alarm FN7650 BASE STATION FAULTY (shared:N;Incorrect radio network parameters) after eNB restart. Also, all the affected cells can’t working. Root cause: The duplicated LNADJ_A-230 & LNADJ_A-231 (same parameter adjEnbId 512402) were configured before the restart. Solution / Workaround: No workaround. Impact to Operator: Duplicated LNREL was created in system without any notification to operator, system is working fine until reset and after reset cells are not working. Impact to End user: Service degradation, affected cells are not available.



2.42 Intra-eNB Inter-F HO failed due to radio-connection-with-ue-lost Problem report: PR091153 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: After Intra-eNB inter-freq HO the UE is released with cause: radio-connection-with-ue-lost. Root cause: After Qci1ReconStopTimer expiry, eVTT status is changed causing RrcConnectionReconfiguration. While waiting for RrcConnectionReconfigurationComplete, A4 measurement is received and tries to trigger another RrcConnectionReconfiguration which is unsuccessful, resulting in UE release. Solution / Workaround: No workaround Description of the correction: Qci1ReconStopTimer expiry handling will be corrected to prevent other reconfigurations to take place while reconfiguration related to eVTT status change is ongoing. They will be queued instead. Impact to Operator: Intra-eNB Inter-F HO failed due to radio-connection-with-ue-lost. Impact to End user: No impact

2.43 Unable to perform CM upload or provisioning - NE busy, details: Readonly Problem report: PR091370 Exists in Release: LN7.0 Correction Target: RL70 2.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: I case in plan upload BTSOM need to ask CPLANE to upload their part of plan. In some cases it can be unsuccessful (request comes in early state, some error ETC). In case like that BTSOM should send plan without CPLANE part of plan and entire request should be end and clean up. In application in RL70 currently when we try to cleanup scenario we try to delete file. If deleting is unsuccessful we cannot end scenario. Issue here is that if scenario is failed, path to file which should be removed is empty and removing cannot be done. When comes next request we still have one scenario undone and next request cannot be processed. Solution / Workaround: Workaround: reset BTS. After solution we won't try to remove file when path is empty. Impact to Operator: Operator can't upload any plan to OMS/BTSSM (Site Manager). So reconfiguration cannot be done. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 49/330 Version 1.0 Confidential


Impact to End user: There is no impact to end-user. During restart there is a service loss.

2.44 MTRACE migration chnage based on requirements update Problem report: PR093994 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: MTRACE related parameters are not migrated (on upgrade LN6.0 to LN7.0) as customer needs. As result, trace is not working as customer expects after upgrade. Solution / Workaround: Description of the correction: System level requirements updated. Migration done based on the updated requirements. Impact to Operator: Trace doesn't work as expected. Impact to End user: No impact.

2.45 RFS FHEA/ FXEA Configuration error: BTS config error (Not enough HW for LCR) (1868) appears after upgrade. Problem report: NA05854698 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Some cells on certain configuration cannot go onAir. Operator can detect the problem by commissioning any LTE-GSM Sharing 15MHz G/I Type using MERA-based radio. Incorrect RP3 routing constraints are being applied, which makes RP3 routing impossible. Dependency on configuration: All LTE-GSM Sharing 15MHz G/I Type using MERA-based radio Solution / Workaround: No workaround. Description of the correction: Proper routing constraints should be applied for LTE-GSM 15MHz G/I type. FHDA should also be fixed in BPF2. DIV Rx should be added for both ANTs. Cells will now go onAir. Impact to Operator: Some cells on certain configuration cannot go onAir. Impact to End user: Cannot make calls on not onAir cells

2.46 eNB not able to recover itself (dpd tasks gets accumulated) in a specific state LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 50/330 Version 1.0 Confidential


Problem report: PR080822 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: B - Major Customer Impact: Attached PRs: PR080822, PR087544 Probability: Permanent Description: In case during IKE rekeying phase (eNB being either being initiator or responder) and SecGW goes down or a network e.g. outage happens, the rekeying process in eNB doesn't get successfully finished or cancelled. eNB hangs in this process. No data are sent any longer through IPsec tunnel. No further rekeying or re-establishment gets triggered by eNB. Solution / Workaround: IPsec tunnel needs to be re-initiated by either switch off/on IPsec on eNB or by triggering IPsec tunnel establishment from SecGW. Impact to Operator: Traffic drop might happen. Impact to End user: User traffic drop might happen.

2.47 LNCEL out of service with the alarm "Configuration error: Not enough HW for LCR" after upgrading SW upgrade Problem report: NA05839939 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: For chain configurations with 15MHz+5MHz BW, one optical fiber link and 3Gbps SFP are used between SMOD and 1st RRH. After SW upgrade one of the two cells could not be on air per chain. Root cause: RF chain configurations with 15MHz + 5MHz bandwidth are not fully support due to wrong RP routing allocations. Solution / Workaround: Avoid having 5Mhz + 15MHz cells in a single RF chain or Change 3Gbps SFP to 6Gbps SFP Impact to Operator: After SW upgrade one cell of the two cells under one radio chain could not be on air. Impact to End user: No impact.



2.48 FOA Configuration problem with 2600+1800 RFM 4way ULRX – BW15+15Mhz in RF sharing Problem report: NA05838605 Exists in Release: LN7.0 0.2 Correction Target: RL70 2.0, FL15A 1.0 Severity: A - Critical Customer Impact: New feature/functionality Probability: Occasional Description: During RF sharing configuration, where 2G SM is connected via LTE SM through TRS LMP interface, Communication is broken between 2G SM and RF module. Solution / Workaround: Workaround: There is direct method to add the policy in TRS module but it will not be persistent across reboot. ip x p add src 0.0.0.0/0 dst 192.168.253.0/24 dir fwd priority 2 ip x p add src 0.0.0.0/0 dst 192.168.254.0/24 dir fwd priority 3 Description of the correction: The TRS module has been modified to add this FWD policy during system boot up. Impact to Operator: There shall not be any issue with connection via TS LMP interface when any network element is connected with TRS LMP interface. Impact to End user: 2G is not working

2.49 Some DSCP values incorrectly changed in the Traffic Type Settings table after RL50 to RL70 MP1.2 Upgrade Problem report: NA05843193 Exists in Release: LNF7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: Some DSCP values incorrectly changed in the Traffic Type Settings table after RL50 to RL70 MP1.2 Upgrade Solution / Workaround: RL50 has SSE (support equipment).This is not supported for FlexiZone Micro in RL70. During upgrade from RL50 to RL70, SSE is present in config_upgrade.xml. RL70 load is ignoring configuration list "trafficTypesMap" of QOS mo. Now transport of RL70 load will remove this SSE item from config_upgrade.xml. Impact to Operator: Some traffic will get default DSCP value. Due to that some traffic which has been assigned higher per hop behavior get default PHB which is less, so traffic may get less priority. Impact to End user: No impact.

2.50 eNBs sending IR message to PKI after upgrade to RL70



Problem report: NA05841703 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Customer upgraded their network from RL50 to RL70 with valid configuration of CERTs in RL50. After upgrade "Automatic certificates fetch unsuccessful" alarm is seen on all the eNBs that are upgraded to RL70. Solution / Workaround: Removed the comparison check between cmp recipient and cert issuer name as it's obsolete as per the latest/modified requirement. Impact to Operator: Netact gets flooded with alarms from multiple eNBs from the network. Impact to End user: No impact.

2.51 Cells down after RF module Block/Unblock Problem report: PR085788 Exists in Release: LN7.0 Correction Target: RL70 2.0, FL15A 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Problem is that ValidationManager didn't clear ValidationFailed state under LCELL after recalculation (triggered by unblock RF module). Solution / Workaround: Added functionality to ValidationManager with correct reaction for CALCULATION_REQ(Online) after Unblock RF. Impact to Operator: CELLs after unblock RF didn't reach onAir. Impact to End user: End user cannot connect to cell with UE.

2.52 Drop ERAB SSR on eNodeB configuration 15+20 MHz Problem report: NA05844030 Exists in Release: LN7.0 0.2 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Sleeping cell LTE20 in case LTE15 + LTE20 configuration Solution / Workaround: Corrected settings of MERA sample rate converter. No workaround Impact to Operator: Zero traffic on affected cell, degenerated LTE20 spectrum. Impact to End-user: UE cannot attach to LTE20 cell.

2.53 Unblocking one carrier changes the tx spectrum of 2nd carrier Problem report: PR053989 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 53/330 Version 1.0 Confidential


Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Unblocking one carrier changes the tx spectrum of 2nd carrier Description of the fault: HW reconfiguration was done for specific bundle mode related configuration LTE15+LTE20 or LTE20+LTE15, which shouldn’t be done. Solution / Workaround: Workaround: No workaround. Description of the correction: Added dependency for HW changes for such configurations. Impact to Operator: After blocking/unblocking one cell/carrier, the other cell/carrier in a dual carrier site would be out of service with no alarm. (In a MORAN scenario, one operator's cell would have an outage). Occasionally the problem also happens on startup, where the tx spectrum for one cell is malformed. Impact to End user: Loss of service on one cell/carrier when the other cell/carrier is blocked and unblocked or the site starts up with one carrier faulty.

2.54 LDAP errors after minor update Problem report: PR087137 Exists in Release: RL70_OMS Correction Target: OMS_RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: After successful activation, when OMS restarts, Primary LDAP perpetually returns error code 80. bdb files are getting corrupted after the reboot. LDAP "fixes itself" after some period of time, but when it is down, OMS malfunctions may happen. Solution / Workaround: Remove bdb files and restart LDAP. If the problem still exists - it might be required to recreate the Primary LDAP from Slave database. Impact to Operator: Primary LDAP is down after postactivation reboot. OMS malfunctions may be observered. Impact to End user: No impact.



3. SOLVED GENERIC FAULTS 3.1 LTE cell disabled without any alarm Problem report: NA05837319 Exists in Release: LN7.0 Correction Target: FL15A P8 Severity: B - Major Customer Impact: Capacity & Performance Attached PRs: NA05837319, PR039939 Probability: Permanent Description: One cell disabled and no alarm on eNB. Without active alarm customer have problems with locating faulty sites. Root cause: Missing implementation that checks the number of cell against the HW supported baseband capacity for HW configuration containing HW release 3 system modules. Solution / Workaround: Validation rule added that checks for the cell count against cell configuration that contains more cells than what is the HW supported baseband capacity with high amount of Active UE. Impact to Operator: No error is shown in BTS Site Manager when actHighRrc is set to 'true' and cell configuration contains more cells than what is the HW supported baseband capacity with high amount of Active UE. Impact to End user: No impact.

3.2 eNodeB restart during logs collection Problem report: NA05786353 Exists in Release: LN6.0 2.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: There is a bug in Linux kernel which causes processing of IPSec policies ineffective. Problem is visible on FSMF units with IPSec enabled, when sending large numbers of small packets via M/C plane. It can cause increased CPU usage on eNB and even lead to unexpected reboot sometimes. User plane and bypassed traffic is not affected at all, since the traffic is going via different path. Solution / Workaround: No workaround. Impact to Operator: In some cases eNB can restart during such operations like: - log collection (snapshot, remote syslog, Emil) - running cell/subscriber trace feature. Impact to End user: eNB out of service during restart time.

3.3 1835 alarm was raised only for WMHC LNA2 Problem report: PR055370 Exists in Release: LN7.0 Correction Target: RL70 2.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 55/330 Version 1.0 Confidential


Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Create 1835 alarm for WMHC (FRGS1.2.1 ant 3 is DC power branch) and check alarms. The alarming failed, 1835 alarm was raised only for WMHC LNA2. WMHC has only one power branch. 1835 alarm affect to both LNAs, so two alarms should be raised. Root cause: DC Cablink between two MHAs of dual LNA PassiveMha should get created and all components should consider that cablink while finding path to VU. Correction: Handling of components improved in CellP, MOAM and SysAdapter. Solution / Workaround: No workaround. Impact to Operator: 1835 alarm raise only for WMHC LNA2. 1835 alarm affect to both LNAs, so two alarms should be raised. Impact to End user: No impact.

3.4 Functionality of ULCoMP on stations from FBBC at the 2nd slot cannot be activated Problem report: NA05823899 Exists in Release: LN7.0 Correction Target: RL70 1.2; RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: 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 Solution / Workaround: Description of the correction: change the code so that exception is not thrown, this enables UPlaneDeployment alternatives to be calculated Impact to Operator: All LTE cells that belong to eNB are out of service, no LTE service is available for such site. Impact to End user: No LTE service available, UE is camping on 3G or 2G.

3.5 Wrong temp Ue handling when processing also dedicated preambles in same tti Problem report: PR076587 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent



Description: When in same tti a dedicated preamble and a non dedicated preambled where processed, the non dedicated preamble was not properly process and UE had to send it again in next ocassion. Solution / Workaround: Was a bug in code which was fixed. Impact to Operator: This fix will help to slighly improve the figures regarding successfuls call setup. The system overall load will also be slightly imrpoved due to fewer temp ues handling time. Impact to End user: No impact.

3.6 IRAT UE based ANR CGI report not triggering with 10s LNCEL Inactivity timer Problem report: NA05804397 Exists in Release: LN7.0 0.1 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05804397, PR067682 Probability: Occasional Description: UE (Quanta) was attached to cell-1 (PCI: 444) which is activating LTE908, and started Ping. eNB sent RSCFS to UE. After that, UE sent Measurement report with Unknown cell to eNB. UE was stopped Ping. Then UE became to user inactivity. eNB didn't send ReportStrongestCells measurement to UE after eNB received UTRA unknown PCI for LTE908. Solution / Workaround: No workaround. Impact to Operator: eNB didn't send ReportStrongestCells measurement to UE after eNB received UTRA unknown PCI for LTE908. Impact to End user: No impact.

3.7 PDCCH Power Boost missing from time to time Problem report: PR069186 Exists in Release: LN7.0 Correction Target: RL70 1.2 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Some PDCCH allocations do not have power boost while it is required. Solution / Workaround: Correction of power boosting during Step 2 in case the PDCCH allocation with doubled aggregation did fail. Impact to Operator: Alarm 1907 is raised, increased DTX rate, loss of throughput Impact to End user: Loss of throughput



3.8 attach not possible with category 1 UE Problem report: PR070078 Exists in Release: LN7.0 Correction Target: RL70 1.2, RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: Call with Cat1 UE does not work. Description of the problem: NIR-value is wrong for physical layer. Solution / Workaround: Workaround: Use dlMimoMode = txDiv, that should work. Description of the correction: Choose the correct NIR-value for Cat1 UE also for dlMimoMode = open o closed-loop MIMO. Impact to Operator: KPI degradation. Impact to End user: Cat1 UE cannot attach in TM3/TM4.

3.9 Unit autonomous reset was occurred during cell block and unblock procedure Problem report: NA05826594 Exists in Release: LN7.0 0.1 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: L2 does not completely clean UE's context from SCell information after SCell releasing o after UE deletion. Solution / Workaround: Clearing L2 UE's context from SCell information after SCell releasing or after deletion. Impact to Operator: eNodeB crash and has to be rebooted Impact to End user: UE could lose connection to network

3.10 M8016C14-C16 are not pegged in case of SRVCC to GERAN Problem report: NA05825939 Exists in Release: LN7.0 0.2 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: Counters M8016C14 – C17 are not counting events fro Inter System HO to GERAN with SRVCC. Wrong counter description for M8016C21, M8016C23, M8016C25, M8017C7 - C9 (“Inter System Handover attempts” are counting in fact “PS-HO attempts to



UTRAN”). Missing information for counters M8017C4 - C6 and M8017C10 that they are incremented by all IRAT cases to UTRAN only. How end user/operator could detect the problem: Problem was detected through a counter comparison using a KPI formula. LTE5191B = 100*sum(ISYS_HO_ATT+ISYS_HO_UTRAN_SRVCC_ATT+ISYS_HO_GERAN_SRVCC_ATT)/ sum(ISYS_HO_PREP) – This KPI formula is considering that in the counter ISYS_HO_PREP there are counted events for SRVCC to GERAN, but in fact in the code they are not. Description of the fault: Counters M8016C14 – C17 are not counting events from Inter System HO to GERAN with SRVCC. Wrong counter description for M8016C21, M8016C23, M8016C25, M8017C7 - C9 (“Inter System Handover attempts” are counting in fact “PS-HO attempts to UTRAN”). Missing information for counters M8017C4 - C6 and M8017C10 that they are incremented by all IRAT cases to UTRAN only. Faulty component and version: The problem is most probably counted from the beginning of RL30, but found and reported for RL70. Solution / Workaround: Workaround: the problem can be avoided only if we change KPI formula, but it is not acceptable. Description of the correction: for counters M8016C14-C17 an event from Inter System HO to GERAN with SRVCC must be counted. For counters M8017C4 - C6 and M8017C10 it must be checked whether they count only cases related to UTRAN. Impact to Operator: KPI impact. Counters M8016C14 – C17 are not counting events from Inter System HO to GERAN with SRVCC. Wrong counter description for M8016C21, M8016C23, M8016C25, M8017C7 - C9 (“Inter System Handover attempts” are counting in fact “PS-HO attempts to UTRAN”). Missing information for counters M8017C4 - C6 and M8017C10 that they are incremented by all IRAT cases to UTRAN only. KPI is affected, LTE_5191B = 100*sum(ISYS_HO_ATT+ISYS_HO_UTRAN_SRVCC_ATT+ISYS_HO_GERAN_SRVCC_ATT)/ sum(ISYS_HO_PREP) – This KPI formula is considering that in the counter ISYS_HO_PREP there are counted events for SRVCC to GERAN, but in fact in the code they are not (and they should be counted). Impact to End user: End-users should not be impacted. This is only connected to the wrong update of certain counters and additionally wrong counter description.

3.11 eNB not sending HO Cancel in case SRVCC2GSM failed and UE reconnect to LTE causing VOLTE call drop Problem report: PR071386 Exists in Release: LN6.0 1.1 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: In case of a running SRVCC to Geran is interrupted by a Reestablish HandoverCancel to MME is not sent by eNodeB. Solution / Workaround: No workaround. Impact to Operator: Poor Drop call rate Impact to End user: VoLTE call will drop unnecessary



3.12 LN7.0 2.0 GPS Receiver alarm control interface not available (4011) Problem report: PR073676 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: GPSd daemon could not be stopped and/or started. Solution / Workaround: Merge missing correction from trunk. Impact to Operator: Possibly site resets are needed for recovery which causes traffic gap during the site reset. Impact to End user: As sync is ok there should not be any direct effect to the end-user. There may be indirect effect to the end-user if the eNB needs to be reset/power reset for recovering the problem (as described in alarm description instructions): possible gap in service.

3.13 [LN7.0_ENB_1407_556_04]VoLTE RTP timeout Problem report: NA05819961 Exists in Release: LN7.0 0.1 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05819961, PR070212 Probability: Occasional Description: While VoLTE test (M2M), termination mobile didn't respond for SIP update. Accordingly the call has been drop by CSCF. It is not related to specific mobile model. Problem happens when UE does intra HO and stays attached long enough for L2 to allocate several thousand new GTP-U tunnels for new UEs. At that point TEID context of problematic UE will be wrongly reused. The same root cause can lead to an interruption of the DL data path in case of long ongoing data calls (e.g. if the end user is continuously sending traffic). Root cause: TEID index is allocated by L2 Manager Execution Object then passed to L2 Local Manager Execution which stores TEID information. Normally new TEID index is allocated during bearer setup but intra HOs are a special case because up to 3 users can share the same TEIDs for their bearers. L2 Local Manager handles this situation by having only one TEID context that points to the source user’s bearer and holds additional information about bearer of target and eventual reestablishment user. So L2 Local Manager uses only one TEID context with index allocated for source user’s bearer. When source is deleted it still reuses this context for target. L2 Manager on the other hand allocates TEID indexes for all bearers and deletes them upon user delete no matter if it’s intra HO user or not. Now when intra HO user is deleted all his TEID indexes are released and can be allocated for any new user by L2 Manager but this indexes are still being used in L2 Local Manager. When this happens TEID context in Local Manager will be rewritten with new user TEID information.



How to identify the problems in eNB logs (DSP runtime logs contained in snapshot): If the problem happens for a UE the following print will be visible in the DSP runtime log:

INF/L2TupuDl: Unknown localTeid eventCounter=1 localTeid=5571 Correction: Correction introduces into L2 Manager the same logic of reusing TEID index as the one that L2 Local Manager applies. Solution / Workaround: No workaround Impact to Operator: VoLTE RTP timeout occurs. Impact to End user: VoLTE Call drop occurs, no DL data is received anymore (for data calls).

3.14 Tracking fix for - RL70 1.1 upgrade failure caused by TRS IPSec configuration lost Problem report: PR074268 Exists in Release: LN7.0 Correction Target: RL70 1.2 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: 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 appliciable 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. Solution / Workaround: 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 appliciable 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. Impact to Operator: During upgrade from LN60 to LN70 with IPSec configuration , more then one Bypass or Discard policies with same local and remote end points, if any one of Ike parameters such as [IKE Protocol , IKE diffie hellman group, IKE encryption method, Dead peer detection delay, Dead Peer detection timeout ] are different, the upgrade fails. Impact to End user: No impact

3.15 UE stuck in OutOfSync. Problem report: NA05831781 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.2, RL60 3.2



Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: 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. 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. Solution / Workaround: Workaround: Disable LTE585 smart DRX. Description of the correction: in RL70 1.1: Don't start the DRX short cycle timer during the DRX reconfiguration transient phase, i.e. between steps 1. and 3. of the reconfiguration. In all other releases: Take the new drxShortCycle into use in step 2. instead of step 1. That insures that it is consistent with the new drxStartOffset. Additionally, stop the drxShortCycleTimer in step 3 if it is still running. Impact to Operator: KPI degradation Impact to End user: Call drop can happen when the DRX profile is switched due to RB addition or removal.

3.16 [FRPB] Antenna Line Device failure (0010) with MHA Problem report: NA05830349 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05830349, PR069329 Probability: Permanent Description: Summary of the original problem: Radio unit was incorrectly modelled in bpf2 configuration file. How end user/operator could detect the problem: Antenna Line Devices were not working properly ( Antenna Line Device failure fault) Description of the fault: no response to scan messages from ALDU Dependency on configuration: configuration based on FRPB unit Faulty component and version: LN70 and xL15 branches Solution / Workaround: Description of the correction: Correction in bpf2 configuration file for FRPB Correction effects: correct ALDU handling in FRPB configuration Impact to Operator: Inoperable ALDU devices. Impact to End user: Setup success may weaken, because loss of the MHA gain.



3.17 After RL70 upgrade, BTS in RF sharing sites shows alarm 7744 Excessive TCH interference Problem report: NA05815362 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.2, RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: 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 Solution / Workaround: Use P-type config with MHAs. Impact to Operator: P-type configuration with MHA not working correctly. Unexpected 7744 and 7607 – “RSSI” alarms raised by 2G. Impact to End user: Degraded LTE and 2G performance

3.18 RL60MP3.0/3.1 eNB restarts during MP3.1 sw-downloads via sw- manager Problem report: NA05818149 Exists in Release: LN6.0 3.1 Correction Target: RL70 1.2, RL70 2.0, RL60 3.2 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: RL60MP3.0/3.1 eNB restarts during MP3.1 swdownloads 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. Solution / 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. Impact to Operator: Unexpected Site Autonomous Reset. Impact to End user: Unexpected Site Autonomous Reset so loss of service is possible.

3.19 Counter M8026C259 PDCP_SDU_LOSS_DL_FNA seems omit part of PDCP SDU



related to GBR Problem report: NA05827873 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05827873, PR060861 Probability: Occasional Description: L2 Tup and L2 Mac send both same counter value to LOM (in different dataset) O&M cannot handle duplicate measurements report that cause counter value is zero. Solution / Workaround: No available. This need L2 correction, in which we remove duplicate measurement report. Impact to Operator: KPI impact. The counter value appears randomly zero value (in the Element manager). Impact to End user: No impact

3.20 Multiple sites dropping "Q6" packets Problem report: NA05812366 Exists in Release: LN7.0 0.2 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Multiple sites dropping "Q6" packets How end user/operator could detect the problem: ethIfOutDiscShapping_Q6 counter is incremented when "QoS aware Ethernet switching in use" parameter is Not Enabled Description of the fault: "QoS aware Ethernet switching in use" parameter value is not considered in the implementation when it is disabled. Hence the packets are Queued as per the DSCP configuration. Faulty component and version: FTM_R2_LN70_MP1_372.00 Solution / Workaround: Workaround: No workaround Description of the correction: "QoS aware Ethernet switching in use" parameter value is considered and when this parameter is NOT Enabled (0) then the packets are sent using Strict Priority Queue. Impact to Operator: Multiple sites dropping "Q6" packets. Impact to End-user: No impact

3.21 WCDMA-LTE RF Sharing: LTE does not get onair after commissioning



Problem report: PR068687 Exists in Release: LN7.0 1.1 Correction Target: RL70 1.2, RL70 2.0 Severity: C – Minor Attached PR: PR067063, PR065131 Customer Impact: Operation & Maintenance Probability: Occasional Description: OAM stuck due to race condition during applying configuration to HW. Solution / Workaround: As workaround set syncPropagationEnabled to true in configuration to prevent this race. Implementation added to solve race problem Impact to Operator: eNB will be not in OnAir Impact to End-user: Calls not possible.

3.22 OMS-11 not operational in Telefonica live network Problem report: NA05807739 Exists in Release: RL70_OMS Correction Target: OMS RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance, Operability Attached PRs: NA05800828 Probability: Occasional Description: During OMS startup udev hangs and don't release the swraid for booting. Solution / Workaround: Udev will be settle before starting software raid. No workaround. Impact to Operator: OMS is not Operational. Impact to End user: No impact

3.23 UL PHY reports 0x4000 instead of 0x8000 for 2bit rank = 2 Problem report: PR060508 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: C - Minor Customer Impact: User Plane Quality Attached PRs: PR060508, PR066057 Probability: Permanent Description: Description of the problem: In case of 2-bit, 2-value RI reports value 2, inside message to MAC PS it should be reported as 0x4000. But instead it is reported as 0x8000 How end user/operator could detect the problem: With high category UE, possible drops to RI=1, so lowered throughput without MIMO in use. Description of the fault: RI treated as riSize=1 even though riSize=2 was set by MAC PS. Dependency on configuration: Requires high category UE.



Faulty component and version: ULPHY in RL70 and FL15A. Solution / Workaround: Description of the correction: Proper handling of RI value when riSize=2. Impact to Operator: With high category UE, possible drop to RI=1, so MIMO not used. Impact to End user: No impact.

3.24 Kernel Panic happened during USB installation. Problem report: PR065131NA05818716 Exists in Release: RL70_OMS Correction Target: OMS RL70 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance, Operability Attached PRs: NA05818716, PR067063 Probability: Occasional Description: During system startup kernel panic has occurred due to unhandled nmi event caused incorrect implementation of hpwdt kernel module. Solution / Workaround: hpwdt kernel module will be blacklisted during startup. No workaround. Impact to Operator: USB installation will not be successful. Impact to End user: No impact

3.25 iOMS alarm and NetAct were not synchronized. Problem report: NA05801012 Exists in Release: RL70_OMS Correction Target: OMS RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance, Operability Attached PRs: Probability: Occasional Description: Alarms are not sent to NetAct automatically. The variable "lastNotificationId" keeps notificationId of latest processed alarm which was send/skip to NMS was not changed. Solution / Workaround: For the solution, change the value of “lastNotificationId”, increment it by 500. The value is stored in location /var/mnt/local/sysimg/flexiserver/opt/Nokia/var/SS_Nwi3Adapter/store/nwi3fmsupplier-buffer/lastevent. For workaround, Restart Nwi3Adapter: fshascli -rn /NWI3Adapter If it doesn't help - repeat the procedure. You can try to increment it by a bigger number, e.g. 2000 or 10000. WARNING: the "lastNotificationId" stored in mentioned file should not exceed the latest notificationId stored in AlarmDB. In order to check the latest notificationId please execute the following query on AlarmDB: select max(notificationId) from AlarmHistoryRecord; Impact to Operator: Alarms from OMS are not sent to NetAct automatically. Impact to End user: No impact

3.26 diagnostic file Collected due to duplicate Mtrace issue from 400151 Problem report: NA05822125 Exists in Release: LN7.0 0.2 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 66/330 Version 1.0 Confidential


Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Missing implementation for MTRACE-eutranTraceId uniqueness checking. Description of the problem: Duplicate Mtrace id causes generation of 6450 alarm How end user/operator could detect the problem: By configuring the same values for all instances of eutranTraceIdMcc, eutranTraceIdMnc, eutranTraceIdMncLen and traceId within all MTRACE objects. Description of the fault: No validation was implemented on SEM for such rule. Description if problem based on certain configuration: For sites with 2 or more Mtrace objects created Solution / Workaround: Workaround: No workaround Description of the correction: Implemented uniqueness checking for eutranTraceId. Correction effects: SEM would not allow duplicate values for all eutranTraceId within the BTS. Impact to Operator: Degraded BTS capacity Impact to End user: Degraded performance

3.27 Incompatible SW version was not detected after RFM replace from FXDA to FXED Problem report: PR067604 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: While SWDL there were request of execution on RU_SWM_L. Registration on execution was moved earlier in startup. This registration was common for RU_SWM_L and BUILD_DATA. Due to that RUMAG tried to register on execution for BUILD_DATA when it was not yet created. Solution / Workaround: Split the execution registration for RU_SWM_L and BUILD_DATA. Impact to Operator: Incompatible SW version detected Impact to End user: No impact.

3.28 Cell stays disabled when MHA SN and product code modifications are made Problem report: NA05821277 Exists in Release: LN7.0 1.1



Correction Target: RL70 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: MHA objects are not mapped properly when they are marked as passive. Solution / Workaround: Omit checking product code and serial number for passive MHAs to map MHAs. Impact to Operator: Cells stayed disabled. Impact to End user: Calls are not possible

3.29 NE busy occurred after CM Plan activation Problem report: NA05818732 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: NE CM Plan don't activate anymore after NE busy. Timeout occur on NetAct side. The problem is not permanent but visible in 12 eNBs of total 43 eNBs. Root cause: There were 2 problems: 1. New NP (Network Plan) was being created in case of transport delta. 2. When sysadapter was processing invalid RNW (delta from CPlane), the RNW queue has been blocked and no more RNW has been processed. Correction: New NP will no more created in case of transport delta. Unlock the queue when invalid RNW detected. Solution / Workaround: No workaround. Impact to Operator: NE CM Plan cannot be activated anymore after NE busy error occurs. Impact to End user: No impact.

3.30 UART enabled console was causing 4019 alarms Problem report: NA05820158 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Within the logs it’s visible that console uart was enabled on some extension boards (FSP1 and FSP2) It’s already known issue that his configuration could lead to Alarm 4019 keep alive/bcn issue. FSP crashes (4019) were observed in customer’s network. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 68/330 Version 1.0 Confidential


Solution / Workaround: No workaround Impact to Operator: UART enabled console was causing 4019 alarms Impact to End user: No impact

3.31 Mast Head Amplifier fault (1870) alarm observed after upgrading from LN6.0 Problem report: NA05820617 Exists in Release: LN7.0 0.2 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: DC voltage was enabled only for one LNA but MHAs with product code ATMAA1412D1A20 (Twin RFS MHA) needs voltage on both LNAs. Solution / Workaround: Proper solution needs to be implemented on SW side; there is no workaround for this problem. Impact to Operator: MHAs are in faulty state (they doesn't provide gain), affected Cells are not operational. Impact to End user: No impact

3.32 Failure in optical RP3 interface (unsp) issue Problem report: PR065546 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: After upgrade from load LN5.0 RL50 to RL70 1.1 there is Failure in optical RP3 interface (unspecified 1) fault visible for few seconds and then it`s gone and cell went onAir. Solution / Workaround: No workaround Impact to Operator: Longer onAir time for cells using FRIE modules, unnecessary fault visible for few seconds. Impact to End user: No impact

3.33 Acceptance: RFsharing After RP3 disconnection/re-connection LTE cell 3 remains in state disable



Problem report: NA05816190 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: CreateCarriers function didn't check if carrier was moved to another RX_PU_L. Solution / Workaround: CreateCarriers now checks if carrier was moved to another RX_PU_L. Impact to Operator: Sometimes cell couldn't go "on air" after radio was hot re-inserted. Impact to End user: Loss of service possible.

3.34 LTE2050 Activation on 7 eNB shows wrong CAC values after feature is activated. Problem report: NA05814845 Exists in Release: LN7.0 0.2 Correction Target: RL 70 1.2, RL60 3.2 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: After eNB reset CAC is back to normal for Cell1 and Cell3. We see active bearers in DL dropped immediately after reset. It seems that some UE/bearers are wrongly recognized as “Active” at least in measurement before the reset. That causes the wrong active bearer measurement and result in CAC calculation wrong. UL is worse, the value from counter (M8001C420 UE_DRB_UL_DATA_NON_GBR) is totally wrong before the reset, we see 300 UEs with Active NON-GBR in average but Max only 20 UEs. After reset it is back to normal. Solution / Workaround: No workaround. Impact to Operator: After eNB reset CAC is back to normal for Cell1 and Cell3. We see active bearers in DL dropped immediately after reset. It seems that some UE/bearers are wrongly recognized as “Active” at least in measurement before the reset. That causes the wrong active bearer measurement and result in CAC calculation wrong. UL is worse, the value from counter (M8001C420 UE_DRB_UL_DATA_NON_GBR) is totally wrong before the reset, we see 300 UEs with Active NONGBR in average but Max only 20 UEs. After reset it is back to normal. Impact to End user: No impact

3.35 After SW upgrade MOAM crash seen in the eNB logs



Problem report: NA05818358 Exists in Release: LN7.0 0.2 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: MOAM crash is seen in eNB logs. Root cause: TRUMAG doesn't unregister the executor, then if it already exits, LIM still can call the operation. Correction: Unregister executor when TRUMAG exits. Solution / Workaround: No workaround. Impact to Operator: MOAM crash is seen in eNB logs. Impact to End user: No impact.

3.36 Lock LNMME not executed – no response to file activation request Problem report: PR061533 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: When switching from NP-5 to NP0-7, the new RNW delta inserts under NP-7, while the new OAM delta inserts under NP-5. The issue happens when the new oam task executes and the rnw task has not been applied. Because there is only one deltaToPlanApplier instance exists in the deltaController, The delta and mos under it for rnw task are covered by the oam task’s in deltaToPlanApplier. Solution / Workaround: Correction: Add a container in DeltaToPlanApplier. Use a map(key=delta distname, value=delta and mos under it) to save all task’ result. Impact to Operator: After LNMME is locked, LNMME can’t be unlocked and activation still ongoing with timeout. Impact to End user: No impact.

3.37 Auto+connection+fails+with+IPSec+configuration Problem report: PR059367 Exists in Release: LNF7.0 Correction Target: RL70 2.0 Severity: B - Major LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 71/330 Version 1.0 Confidential


Customer Impact: Operation & Maintenance Probability: Permanent Description: Wrong IP address was being set in IPsec by auto connection module. Solution / Workaround: The correction is in LNF7.0 MP2. Impact to Operator: Auto connection feature does not work when IPSec is configured. Manual connection is required, which requires engineer to visit site. Higher site costs. Alternative is to not run IPSec. This would reduce data security for BTS traffic Impact to End user: If IPSec is disabled, user data will be vulnerable.

3.38 Rl60 ipsec-2h-issues Problem report: NA05801588 Exists in Release: LN6.0 2.0 Correction Target: RL60 3.1, RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Rl60 ipsec-2h-issues Description of the fault: While an IPSec session is enabled and the tunnels are up and when re-routing is enabled it is observed that roaming enable is triggered which leads to the triggering of re-authentication of IPSec tunnels. This leads to breaking of tunnels. Dependency on configuration: IPSEC in use, fast IPO rerouting happening causing default GW change in FP Faulty component and version: FTM_R2_LN70 Solution / Workaround: Workaround: delete IPSEC SA on core side (SecGW) once BTS O&M alarm is raised. Description of the correction: As roaming is not supported. We are disabling the triggering of roaming, so the tunnels won't break. The patch has been tested and found the changes working fine so far. Impact to Operator: eNodeB is down until IPSEC SA is rekeyed or IPSEC SA delted on SecGW side. Impact to End user: no calls possible on eNodeB as IPSEC tunnel is down.

3.39 No handler for unexpected message with TEventId: 0x42cf Problem report: PR056575 Exists in Release: LN7.0 Correction Target: Correction not needed Severity: B - Major Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 72/330 Version 1.0 Confidential


Probability: Occasional Description: The issue can occur during eNB reconfiguration - when parameters which enable the Downlink Interface Shaping functionality are changed, the race condition between parameters propagation and DIS algorithm recommendation update may occur. The message indicating the change of the recommendation to use/not use the algorithm in the U-plane will not reach the destination. There will be discrepancy in between the components, which will lead to inappropriate use of DIS functionality. The probability of the issue is very low (race condition) but can have significant impact. Solution / Workaround: There is no Workaround for this issue as it is the race condition. Correction: The resolution will be the introduction of new handler on CELLC for unconditional passing the 0x42cf message to MAC. The risk of this change is rather small. Impact to Operator: There gain of DIS algorithm for decreasing the interference in the system will not be visible so the RF conditions might be worse in some part of the cell. Impact to End user: There gain of DIS algorithm for decreasing the interference in the system will not be visible so the RF conditions might be worse in some part of the cell.

3.40 Unit autonomous reset as recovery action (4019) occurred Problem report: NA05806222 Exists in Release: LN7.0 0.2 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Stability Probability: Occasional Description: Unit autonomous reset as recovery action (4019) occurred. Root cause: UEC is crashing due to zero-initialized memory in UecHoExecSrc service. This could not be reproduced, no exact cause for this scenario found. Correction: UEC corrected to avoid possible scenarios that lead to zero-initialized memory. Solution / Workaround: No workaround. Impact to Operator: Occasional unnecessary eNB restart. Impact to End-user: Loss of service because of eNB restart.

3.41 [FSMr3]Enabled IPsec causes wrong ToP Phase counter values. Problem report: PR053375 Exists in Release: LN7.0 1.0 Correction Target: Correction not needed Severity: B – Major Customer Impact: Operation & Maintenance Probability: Permanent Description: The ToP phase sync counters are going out of range when ToP and IPSec is enabled and ToP traffic is over protect policy. There is no issue with synchronization of enb as per the tester. Only LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 73/330 Version 1.0 Confidential


issue seen is counters are out of range. Solution / Workaround: No workaround possible as such. We can make ToP traffic over bypass policy. Impact to Operator: The ToP counter values would be shown out of range. No issue with ToP functionality. Impact to Operator: BTS cannot go OnAir after SW upgrade. Additional eNB reset necessary. Impact to End user: No impact.

3.42 M8012C107/M8012C108 IP_TPUT_VOL_UL_QCI_9/IP_TPUT_TIME_UL_QCI_9 changed trend after upgrade Problem report: NA05807852 Exists in Release: LN7.0 0.2 Correction Target: RL70 2.0 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Trend change after SW upgrade was observed the following counters: - M8012C107 IP_TPUT_VOL_UL_QCI_9 Decrease after upgrade. - M8012C108 IP_TPUT_TIME_UL_QCI_9 Decrease after upgrade. Root cause: Two TTIs were removed from calculation. Correction: Only the last TTI will be removed to correct the calculation. Solution / Workaround: No workaround. Impact to Operator: IP SCHEDULED THP UL counter samples are lower. Impact to End user: No impact.

3.43 The name of "VSWR major alarm" was changed after upgrade LTE. Problem report: NA05812125 Exists in Release: LN7.0 Correction Target: FL15A P8 Severity: C – Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: After upgrade alarm's tag shared was "N", instead of "D". Solution / Workaround: Correction - LNA_L objects now are categorized as RF. Impact to Operator: No impact. Impact to End user: No impact.

3.44 VoLTE calls DL data transfer stalls Problem report: PR058899 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 74/330 Version 1.0 Confidential


Exists in Release: LNF7.0 0.2 Correction Target: RL70 1.2 Severity: B - Critical Customer Impact: Capacity & Performance Probability: Permanent Description: VoLTE UE0’s DL AM packets stop whilst the UL continues. VoLTE UE1’s DL UM packets are not received. Other UEs 2..150 seem to be scheduled in preference to UEs 0/1 in the DL, they never seem to hit Max RLC retransmission even though they are configured as AM bearers. So it seems that VoLTE UE’s DL data transfers stalls (seems to happen apprx. at a same time) while FTP DL data transfer seems to be ok. Solution / Workaround: Do not change DRX state during Carrier Aggregation with 3CC. Impact to Operator: Increase on Drop Ratio KPi's (LTE_5004a, LTE_5025d, LTE_5119c, LTE_5812b) May also decrease RRC success rate KPi (LTE_5220a) and Radio Bearer success rates KPi's (LTE_5117a, LTE_5023d, LTE_5024d). Impact to End user: Bad voice quality for VoLTE users. VoLTE calls dropping (UE's going out of sync).

3.45 BTS hardware notification is sent too often for not integrated BTS, which is causing unnecessary flood of notifications Problem report: NA05805434 Exists in Release: LN6.0 1.1.3 Correction Target: FL15A P8 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Missing requirement to LBT2594 (to have adjusting timeout) Solution / Workaround: Modified timeout behavior per latest requirement update. Impact to Operator: Too many notification might cause slow down in CM editor in NetAct Impact to End user: No impact

3.46 All cells are faulty when new FBBC is hot inserted Problem report: PR037194 Exists in Release: LN7.0 Correction Target: FL15A P8 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR037194, PR036133 Probability: Permanent



Description: Lncels becomes faulty after FBBC hot insert. Solution / Workaround: Sysadapter/Rrom wont sent configurationChageRequest for BBU not existing in layaut. HwConfiguration will indicate fault on LNCEL instead CPLANE. Impact to Operator: All cell will be faulty under the BTS Impacts of the fault to operator Impact to End user: No Service available Impacts of the fault to end-user

3.47 After RL70 corr29 upgrade eNB's are unable to connect to iOMS Problem report: NA05789106 Exists in Release: RL70_OMS Correction Target: open Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: NA05789106, NA05791300 Probability: Rare one occurrence Description: Connection from NE to OMS is closed by lower layer of OMSBTSOM process. Solution / Workaround: There is no preventive workaround available. If the problem occurs then restart BTSOM process using following command: # fshascli -r /OMSBTSOM The request will terminate all the processes running in /OMSBTSOM. Are you sure you want to proceed? [y/n] y /OMSBTSOM is restarted successfully Impact to Operator: OMSBTSOM is not operational, there is no communication from/to NEs Impact to End user: No impact

3.48 RL70 0.2: FSMr2 IPsec: PM M51125C2 (Discarded_ESPFramesTx) and M51125C3 (Discarded_ESPFramesRx) are wrongly pegged. Problem report: PR040976 Exists in Release: LN7.0 0.2 Correction Target: FL15A P8 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: In FTM internal debug counter we see packets have been dropped due to SPI mismatch; that means no SA present for the received ESP packets, hence counter “Discarded_ESPFramesRx” is getting incremented. Solution / Workaround: RISE counters description update. Impact to Operator: False PM is misleading to the operator. Impact to End user: No Impact



3.49 LTE1491 Additional layer 1 performance measurements should not be activated on FSME Problem report: NA05802703 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: The feature LTE1491 is only supported for system module FSMr3. There is no check to prevent the LTE1491 parameter actL1PM being set to 'true' for system module FSMr2 (FSME). How end user/operator could detect the problem: The operator would be able to set the LTE1491 parameter actL1PM to 'true' for system module FSMr2 (FSME), thereby causing the LTE1491 to not function properly when generating PM counts. Description of the fault: A check is missing for the parameter actL1PM to prevent the operator from setting the parameter to 'true' when equipped with system module FSMr2. Solution / Workaround: The operator should not set the parameter actL1PM to 'true' when system module is FSMr2. Correction: A check will be added to LTE CCPM and PDDB to limit the parameter actL1PM to be set to 'true' only when system module is FSMr3. BTSSM will be updated to incorporate this check. Risk analysis of the correction: Minimal risk to prevent potential problems with environments having system module FSMr2. Impact to Operator: The operator would-be able to set the parameter actL1PM to 'true' for system module FSMr2. Impact to End user: The end-user with system module FSMr2 would encounter erroneous PM counts associated the LTE1491 feature.

3.50 BTS EM DC AISG options not reflective of FRPA/FRHF unit capabilities Problem report: NA05805322 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: HW conifg: FRPA or FRHF In the BTS EM commissioning, Antenna Line Management: The EM allows the user to select “DC Voltage” on ANT ports 2,4,6 for FRPA and FRHF. However, as per Flexi Multiradio BTS Radio Module and Remote Radio Head Description DN0951745 Issue 05 Approval Date 2014-05-30 The FRPA and FRHF ANT 2, 4, 6 are not DC capable, actually they are a DC short on the AISG/DC bus as they have no internal bias T. Solution / Workaround: Re-commission eNB, using only DC from ANT which also carries AISG signalization. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 77/330 Version 1.0 Confidential


Impact to Operator: The BTS EM needs to be updated to forbid the Operator user to select DC on ANT line where it is not supported by HW. This is causing major issues in deployment as it suggests that DC is allowed, site integration engineers are connecting this port and it’s causing connected MHAs to be powered down. Impact to End user: If MHA is power down, coverage/KPI even service are impacted.

3.51 Failure in optical RP3 interface (unsp) Problem report: NA05775409 Exists in Release: LN7.0 Correction Target: FL15A P8 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: Minor faults occurs “Failure in optical RP3 interface (unsp)” in GSM-LTE RF sharing configurations. Fault 10 visible for HWF objects. Solution / Workaround: Solution: Corrected according to specification change: No 10 for HWF radio not present in SCF. Impact to Operator: Unexplained minor fault “Failure in optical RP3 interface (unsp)” in GSM-LTE RF sharing configurations. Impact to End user: No impact.

3.52 (FDD LTE RL60) can't connect to eNB in remote. Problem report: NA05773216 Exists in Release: LN6.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: (FDD LTE RL60 and RL70) can't connect to eNB in remote after plug out/in the fiber in BBU. There was in use the optical 6 as the transport. The port setting is forced 1000M. Solution / Workaround: Change the Port 6 mode as full duplex , Impact to Operator: RF connection failure from the SYSTEM module Impact to End user: No cell could be accessed, no any traffic

3.53 BTS not commissioned due to unnecessary rtwp result range check in LTE1634 Problem report: NA05790272



Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: The RF Test Diagnostic uses a plan download to initiate a diagnostic, and a Configuration Change Notification to report diagnostic results. This enables the diagnostic to be executed from EITHER NetAct or the SiteManager. An RF Test Diagnostic was executed and results were returned successfully. One of the results returned by this diagnostic is RTWP, which has a minimum value of 110.0. Some radios can report values less than -110.0, and that is indeed what occurred in this case. The below -110.0 value was displayed at NetAct and the SiteManager. Later, the ENB was reset for other reasons. As the ENB initialized, it read the stored value of this out of range RTWP and failed initialization. The ENB was left in the uncommissioned state. The ENB was recovered remotely using a backup commissioning file. It is possible to happen also with other BTS settings. Solution / Workaround: Customers have been notified to disable RF Test Diagnostic functionality. The valid minimum range of RTWP has been changed at the ENB from -110.0 to -180.0. More importantly, code has been put in place to ensure that out of range values are not sent in the Configuration Change Notificaiton or preserved in the SCFC. Impact to Operator: The defect is related to LTE1634 feature and the issue is happened in the case that the measure RF test result is out of range. Impact to End user: RF module failure, cells on that RF module are down.

3.54 FXED - Faults 1910 RF module failure and 4003 TX failure in MIMO reported after startup Problem report: 60307ESPE05 Exists in: LN7.0 Correction Target: FL15A P8 Severity: C - Minor Customer Impact: Capacity & Performance Description: Conditions under which issue was observed: LTE system was power on. After successful startup no faults are active and cells are OnAir. After few minutes in idle state fault 1910 - RF module failure appeared together with fault 4003 TX failure in MIMO. Described issue is occasional and occurs 1/10 times. Configurations on which problem was seen: L11-Gc-40-2TX-2RX BW 10MHz (carrier power 8W) L111-N-93-4TX-4RX BW 20MHz (carrier power 8W) Probability: Occasional Solution / Workaround: RF module block/unblock or power off/on. Impact to Operator: Cells on affected antenna lines are degraded or faulty, which in turn will effects KPI.



3.55 RF Diagnostics test cannot run while eNB is in BTS Test State Problem report: NA05812125 Exists in: LN7.0 Correction Target: FL15A P8 Severity: B - Major Customer Impact: Operation & Maintenance Description: LTE is up and running with no alarms. Remote RF Diagnostic feature is activated. RF Diagnostic tests are successfully run during normal LTE operation. In Site Manager, LTE is put into a BTS Test State. Attempted RF Diagnostic tests will not return results because RF power is off while in BTS Test State. RF power needs to be on to return valid RF Diagnostic test results. BTS Test Model will allow the RF power to be turned on while in BTS Test State. Diagnostic tests cannot run RF because operator is not allowed to leave the BTS Test Model dialog box without turning off the power. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: RF Diagnostic Test cannot run while the Test Model is active. Will only be seen when RF Diagnostic tests are ran when the LTE is in BTS Test state.

3.56 FRHC modules suggested in eNB configuration in the BTSManager in RFsharing page Problem report: NA05773318 Exists in: LN7.0 Correction Target: FL15A P8 Severity: C - Minor Customer Impact: Operation & Maintenance Description: During the configuration of this configuration the BTSManager suggests the RFsharing also for FRHC modules. This is not possible. Root cause: FRMC and FRHC RF units support was not aligned to current BPF spec. Improvement needed in BTSOM SysAdapter to provide proper info about supported technologies. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: During the configuration of this configuration the BTSManager suggests the RFsharing also for FRHC modules. This is not possible.

3.57 FSMr3: M51137C0 (topRxFreqSyncMsg) is occasionally pegged zero while synced with ToP frequency. Problem report: PR044960 Exists in Release: LN7.0 1.0 Correction Target: FL15A P8 Severity: B - Major Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 80/330 Version 1.0 Confidential


Probability: Occasional Description: Summary of the original problem: PM M51137C0 (topRxFreqSyncMsg) will be pegged zero when connection with ToP Server is lost during that PM cycle. How end user/operator could detect the problem: Check PM M51137C0 (topRxFreqSyncMsg). Description of the fault: Requirement does not cover this scenario, implementation does not match with requirement. Solution / Workaround: No workaround. Description of the correction: Requirement will be updated accordingly to cover this scenario. Risk analysis of the correction: Low. Correction effects: Requirements. Impact to Operator: False PM is misleading to the operator.

3.58 FXED Piloting with high RF module failure (3010) Problem report: NA05833238 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.0, FL15 P8 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: False triggering of alarm 1910 (FilterInputPowerMissing) occurred occasionally. Solution / Workaround: Description of the correction: Correction by preventing false triggering of alarm 1910 False alarm probability is degraded by changing triggering parameter for "FilterInputPowerMissing" from 1500 to 800 and rising TX input level at BB from 800 to 4500. Impact to Operator: there is no 1910FXED. KPI is maintained. Impact to End user: Cell lost traffic.

3.59 Part of sites have no KPI data Problem report: NA05839037 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: After SW upgrade for two sites appears no PM data issue. Dependency on configuration: GPS, CPRI, ToP as a time source OR Sync Hub Slave. Root cause: Not validated timestamp was taken from shared memory after oneshot NTPd, and time was set incorrectly. Solution / Workaround: Workaround: No workaround. Description of the correction: valid field in shared memory is cleared whenever timestamp is wanted, then waits for valid to be set, so new timestamp can be validated. Impact to Operator: Occasionally no PM data sent after SW upgrade. Time on BTS was set incorrectly. Impact to End user: No impact. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 81/330 Version 1.0 Confidential


3.60 LN7.0 2.0 - BTS config error 1868, Not enough HW after SW upgrade Problem report: PR083149 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Rare one occurrence Description: After SW upgrade from LN7.0 0.2.7 to LN7.0 2.0 the alarm '1868 BTS configuration error (not enough HW for LCR)' is active and certain cells remain disabled. Solution / Workaround: Extra eNB reset has to be performed to get alarm cancelled and cells enabled. Impact to Operator: Extra eNB reset has to be performed. Impact to End user: A bit longer downtime. Especially in rural areas end-users cannot make call during eNB reset because neighbor eNB is too far.

3.61 RL70 2.0 Transmission parameters missing (1825) Problem report: PR083703 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: The issue was visible on HW configuration FSMF (FTIF) + 2x FRMA (1+1+1). The load RL70 2.0 (LN7.0_ENB_1407_581_06) was on active partition, next step was rollback via NetAct 15.5 to RL50 2.3 (LN5.0_ENB_1304_797_00). After that Rollback failed and Commissioning error like "Transmission parameters missing" (1825) - EFaultId_PublicIPmissingAl occurred. SW version on TRS did not activate from passive to active partition. Solution / Workaround: Don't remove TRS's data when rollback is executed. Impact to Operator: BTS capacity might have decreased. Impact to End user: Service loss

3.62 Flexi Zone Micro - "6707 autonomous reset as recovery action" alarm after RL70 MP1.2 Upgrade Problem report: NA05840698 Exists in Release: LNF7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05840698, PR083779 Probability: Occasional Description: L2 Crash causing a product reset. Root cause: It is a cache corruption issue. This corruption was identified through memlogs. Cache corruption resulted in messages being corrupted. The corrupted messages were detected at the application layer and this triggered a reset as a form of recovery. An explicit call to invalidate cache to a LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 82/330 Version 1.0 Confidential


common message handling function should avoid these problems going forward. Solution / Workaround: No workaround. Impact to Operator: L2 crash caused site reset. Impact to End user: Loss of service until reboot



3.63 Voltage was set on for not commissioned diversity antennalines Problem report: PR075555 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR075555, PR076805 Probability: Permanent Description: DC voltage is enabled according to SCF alDcVoltageEnabled parameter on antenna lines without commissioned MHA and AISG communication support. Solution / Workaround: Workaround: Set "alDcVoltageEnabled" to false and "feederVoltage" to 0V for antenna line without commissioned MHA. Description of the correction: Setting Dc Enabled to false on antenna line without commissioned MHA even if alDcVoltageEnabled is set to true in SCF. Impact to Operator: Voltage disabled on antenna lines without commissioned MHA and AISG communication support. Impact to End user: No impact.

3.64 All LNCELs of eNB went down after upgrading SW from RL60 1.1 to RL70 1.1 Problem report: NA05836932 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: NA05823899, NA05836932, NA05841995 Probability: Occasional Description: 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 Solution / Workaround: Description of the correction: change the code so that exception is not thrown, this enables UPlaneDeployment alternatives to be calculated Impact to Operator: All LTE cells that belong to eNB are out of service, no LTE service is available for such site. Impact to End user: No LTE service available, UE is camping on 3G or 2G.



3.65 MHA passively commissioned in with same S/N and product code cause faulty cells and BTS loosing operability Problem report: NA05818400 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Operator uses dual or triple band MHAs that are serving co-located GSM/3G and LTE nodes on a share RF feeder. Typically 3G site will be controlling the MHA, provide DC and using AISG in the MHA commissioning. On LTE sites MHA presence will be indicated by using option "MHA in use" - MHA type selected as Other, MHA gain, SN and product code needs to be then filled in manually. Doing this remotely in many cases same serial number was used or SN and PC fields were left blank. At a rough estimate couple hundred of sites might still be having this issue. But when site is upgraded to latest SW release with several MHAs using same PC and S/N cell is shown as faulty with insufficient HW resources for LCR alarm. BTS resets itself and comes back with faulty cells. BTS Site Manager shows alarms but does not show cell configuration and only really allows to roll software back. Root cause: There can be more then 2 passive MHA use same serial number and product code which is not allowed in real environment. Correction: Message added to prevent commissioning go next on Antenna line settings page when user configure more than two passive mha have same produce code and serial number. Also a new prevalidation that "No more than two non-AISG MHAs can have same serial number (value of serNum) and product code (value of prodCode)" was added. Solution / Workaround: Do not configure same serial number and product code for more than 2 passive MHA. Impact to Operator: After SW upgrade when several MHAs using same PC and S/N then cell is shown as faulty with insufficient HW resources for LCR alarm. BTS resets itself and comes back with faulty cells. BTS Site Manager shows alarms but does not show cell configuration and only really allows to roll software back. Impact to End user: No impact.

3.66 (Flexi Multiradio BTS EDGE MCPA)L1800 FEFAMING 2G cannot access the network Problem report: NA05820753 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Customer had no possibility to commission LTE for 15MHz bandwidth. This is causing capacity and DL throughput limitation. 10 MHz BW was max with affected SW Attached PRs: NA05820753, NA05840894 Probability: Occasional Description: There was lack of implementation of internal logical resource for FHEA radio and handling it in RP3 routing computation. Even when routing was computed it wasn't correct and caused collisions on the radio module between 2G and 4G. The base station couldn't process data properly because the stream was malformed. No calls were possible. The problem occurred every time, 15MHz cell was set up. Solution / Workaround: Added internal radio resource to hardware model and adjusted routing LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 85/330 Version 1.0 Confidential


computation implementation to new model. Impact to Operator: Operator had no possibility to commission LTE for 15MHz bandwidth. This is causing capacity and DL throughput limitation. 10 MHz BW was max with affected SW Impact to End user: Planned throughput was not available for end-user.



3.67 RL60MP3.0 - outage of eNB after/during upgrade procedure RL60MP2.0MP3.0 Problem report: NA05806622 Exists in Release: LN6.0 3.0 Correction Target: RL70 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: The default GW configured by the operator was not getting configured to the FP (Packet processing software ) due to a bug in the library used for configuring FP Solution / Workaround: In RL70 new library(different design ) is used to configure the FP. Impact to Operator: The IKE Packets,User plane packets which check FP routing table for packet forwarding will be dropped inside the ENB. Those packets will not be send out of the ENB. As a result IPsec tunnels cannot be established and hence S1 failure with IPsec enabled. Impact to End user: Out of service. Cannot establish connection with MME if IPSec is used.

3.68 Wrong DRB ID in DrbtoReleaselist - HO got cancelled Problem report: NA05838934 Exists in Release: LN7.0 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Capacity & Performance Probability: Permanent Description: By implementing the neighbor restriction, the UE is not able to hand over from a non restrictive zone to a restrictive zone. Four EPS bearer are included in HO required message but MME grant only two of them. eNB must release the DRB which are not granted by MME but it is using the wrong DRB num in DrbToReleaseList of HO Request Ack. This wrong HO Request Ack is passed to source eNB and triggered fault and HO cancelled. Root cause: During S1 HO, LTE UEC shall fill drbToRelease list in HandoverRequestAck message using drbIdentity. Correction: Change the code responsible for filling drbToReleaseList and fill it with drbIdentity. This correction has low risk as the functionality is used only if there are DRBs to be released during S1 HO and the EPS Bearer Identity is not aligned to DRB Identity. Solution / Workaround: No workaround. Impact to Operator: S1 HO will fail on UEC SRC as drbToReleaseList will contain wrong drbIdentity (in case of different drbId and epsBearerId in AS-Config sent from HO UEC SRC). Impact to End user: Failing S1 HO on SRC.

3.69 Unexpected reset occur after parameter change Problem report: NA05839179 Exists in Release: LNF7.0 Correction Target: RL70 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Site rebooted during startup after planned commissioning. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 87/330 Version 1.0 Confidential


How end user/operator could detect the problem: The site rebooted twice after planned commissioning instead of once. Description of the fault: Simultaneous X2 link setup during startup caused CellP process to be flooded with messages from CPlane and as a result CCS supervision ping was missed and the site rebooted. Dependency on configuration: Number of configured LNADJ objects impacts the amount of messages generated by CPlane. Solution / Workaround: Workaround: Reducing the amount of configured LNADJ objects reduces the amount of messages processed by BTSOM. Reproduction attempts estimate the safe amount of LNADJ objects to be 40. Description of the correction: Correction changes the way supervision timer is handled allowing for pings to be sent between processing of queued messages. Impact to Operator: Occasionally site rebooted twice instead of once. Impact to End user: Service outage longer then anticipated during site reset

3.70 RL70 Acceptance - eNB PNP not working Problem report: NA05832189 Exists in Release: LN7.0 1.1 Correction Target: RL70 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Auto connection was writing CMP and DHCP bypass policies incorrectly. Faulty component and version:FTM_R3_LN70_LNT50_FZM55_WN9010_MP1_444.00 Solution / Workaround: No workaround Description of the correction: Auto connection writing CMP and DHCP bypass policies incorrectly, which results OMS connectivity not happening when we enable IPSEC through auto connection. Impact to Operator: PnP not working during eNodeB launching. Impact to End user: No impact

3.71 (FDD LTE RL60) eNB restart randomly in one iOMS, about every 6 hours, others work well. Problem report: NA05828511 Exists in Release: LN6.0 Correction Target: Correction not needed Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: NA05828511, NA05837382 Probability: Occasional Description: Summary of the original problem: eNB restart randomly in one iOMS, about every 6 hours, while others work well. Description of the problem: There is a crash occurred in the HardHGW code during sending of an ALARM_OBSERVATION to iOMS. How end user/operator could detect the problem: eNB reset about every 6 hours. The eNB should be connected to an iOMS with approximately ~900 eNBs. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 88/330 Version 1.0 Confidential


Description of the fault: A crash occurred in the eNB. Faulty component and version: RL60 SC_MONOLTIH/SIM_SystemInterfaceManagement r274046 Faulty component first delivered in(e.g. release, CD): LN6.0_ENB_1311_731_01 Solution / Workaround: Workaround: Local cut-over ~300 eNB to iOMS3 from iOMS2, there is no more site reset. Description of the correction: The correction is preventing the possibility of the early deletion of the socket during sending of message to iOMS. Impact to Operator: There is a crash/ reset of the eNBs Impact to End user: During restart is service loss

3.72 LTO7.0_OMS decompressed and save to btsfilesBU backup path after received BTS PM files Problem report: 123543ESPE01 Exists in Release: RL70_OMS Correction Target: OMS RL70 1.1 Severity: C - Minor Customer Impact: Capacity & Performance Probability: Permanent Description: Summary of the original problem: After decompression of the .xz files, decompressed xml files are saved in btsfilesBU for troubleshooting and take up more disk space. How end user/operator could detect the problem: Enable backup of files. Description of the fault: The decompressed files in btsfilesBU take up more disk space. Solution / Workaround: Description of the correction: The decompressed files are compressed with gz compression so that it would reduce the size of each file stored in btsfilesBU which in turn will prevent the consumption of more disk space. Impact to Operator: When backup is enabled, disk will be full due to the decompressed files which will cause other backup files to not be saved and it will also affect performance. Impact to End user: No impact

3.73 FOA - After RL70 Upgrade on FzM Sites - Alarm "6706 autonomous reset as recovery action" is Appearing Problem report: NA05829844 Exists in Release: LN7.0 Correction Target: RL70 1.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05829844, NA05831155 Probability: Occasional Description: 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 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 89/330 Version 1.0 Confidential


Faulty component and version: L2 SC Faulty component first delivered in(e.g. release, CD): Fault exist from the begging of RL70 release Solution / Workaround: No workaround Impact to Operator: Cells down. Capacity decreases Impact to End user: Cells down

3.74 the system timestamp in SIB 8 is incorrect Problem report: NA05822143 Exists in Release: LN7.0 1.0 Correction Target: RL70 2.0 Severity: C - Minor Customer Impact: Capacity & Performance Probability: Permanent Description: Symptom is that systemTimeInfo in SIB8 is different in RL60 and RL70 after test which caused wrong timestamp convert. Solution / Workaround: No workaround. Impact to Operator: Wrong CDMA time for SIB8, and cause the call timestamp convert. Impact to End user: No CDMA call correctly rollback.

3.75 LNF7.0 FZM; High load test causes L2 assert Problem report: PR069722 Exists in Release: LNF7.0 Correction Target: RL70 1.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR069722, PR070573 Probability: Occasional Description: Description of the 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. Solution / Workaround: No workaround. Impact to Operator: UL data robustness improved. Impact to End user: No impact.

3.76 BTS activation failure due to failure to sign U-Boot on eNB165301 (FZM) Problem report: NA05824923 Exists in Release: LNF7.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 90/330 Version 1.0 Confidential


Correction Target: RL70 1.2 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Rare one occurrence Description: 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 Solution / Workaround: 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 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). Risk analysis of the correction: Low risk: 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. Customer effects: SW activation will succeed if original U-Boot signing issue was due to a full /tmp. Test requirements: SW upgrades, Snapshot. Impact to Operator: Operator cannot upgrade BTS site. Impact to End user: No impact to end user due to SW activation failure. However, any new features or fixes provided by the intended new BTS SW release would not be available for the end user to experience.

3.77 [FWIB]Factory update failed from LNF5.0_ENB_1407_169_00 to LNF7.0_ENB_1407_145_14 Problem report: PR067484 Exists in Release: LNF7.0 Correction Target: Corection not needed Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Uncomissioned upgrade from RL50FZ factory-installed loads will fail if OMS IP is not properly LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 91/330 Version 1.0 Confidential


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". Solution / Workaround: • 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) Impact to Operator: N/A Impact to End user: N/A

3.78 Software failure reset occurred in FZM(LNF7.0_ENB_1407_138_02) Problem report: NA05821517 Exists in Release: LNF7.0 Correction Target: RL70 1.2 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: NA05821517, NA05825759 Probability: Occasional Description: Summary of the original problem: L2 SW assert and following error print see in the UDP-log "LTE MAC/RlcCoreDl/FFFFFFFF:FFFFFFFF/Fatal(line=771): UE received in the wrong ueGroup:2, ueGroupFromUeIndex:0, ueIdxOnly:0x0" Description of the problem When the L2 start to handle the MAC_HarqReleaseReq-message, the L2 detected that the content of message is wrong. In that case we see error print "LTE MAC/RlcCoreDl/FFFFFFFF:FFFFFFFF/Fatal(line=771): UE received in the wrong ueGroup:2, ueGroupFromUeIndex:0, ueIdxOnly:0x0" And after that SW assert is done because, also the received servingCellIndex is greater than MAX_NUM_OF_CELLINDEXES”. Reasson is another message before MAC_HarqReleaseReq cause cache coherence problem. That was reson why MAC_HarqReleaseReq-message is corrupted. Corretions is when CRlcSupportUlQCtx free events in freeOriginalTBsEvents()-fungtion. Insted of em_free( em_disable_coherency_ex( eventToFree ) ) we have to use remove em_disable_coherency_ex (em_free( eventToFree )) How end user/operator could detect the problem: Randomly Sw Resest and error print. Description how problem can be detected: Error print (UE received in the wrong ueGroup...) and SW Assert Faulty component and version: MAC L2 Solution / Workaround: No workaround. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 92/330 Version 1.0 Confidential


Description of the correction: Corretions is when CRlcSupportUlQCtx free events in freeOriginalTBsEvents()-fungtion. Insted of em_free( em_disable_coherency_ex( eventToFree ) ) we have to use remove em_disable_coherency_ex -- (em_free( eventToFree )) Impact to Operator: The Enb reset the dsps and return back to online Impact to End user: All calls to drop from this EnB. After restating, EUs can be attached to the Enb again normally.

3.79 Failure in optical RP3 interface alarm for FRLB when upgraded to LN7.0_ENB_1407_556_54 Problem report: PR038110 Exists in Release: LN7.0 0.1 Correction Target: Correction not needed Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR038110, PR038129 Probability: Occasional Description: eNB(FSMF) configured with 2xFBBC 2xFRIE + 3xFRLB. 2 FRIE's connected to FSMF and each FRIE's has two 3Gb RP3 cables connected (15/20 Mhz configuration). 1 FRLB connected to FBBC1 (on port 3). 2 FRLB's connected to FBBC2 (one on port 2 and second on port 3). CA configured with FRIE cells on 10 Mhz and FRLB cells on 5 Mhz. eNB is on RL70 0.1 (LN7.0_ENB_1407_556_54) eNB passive side has RL60 1.1.3 (LN6.0_EBB_1311_766_10). Upgrade to LN7.0_0.1 After the SW upgrade: FRLB connected to FBBC2 port 3 comes up then disappear then eventually stays up due to FBBC taking too long to configure. Alarm "Failure in optical RP3 interface (0010)" is raised after FRLB disappear but cancels after it re-appear. FBBC2 is taking too long to come up hence causing the FRLB RP3 alarm. Solution / Workaround: No workaround Impact to Operator: Alarm "Failure in optical RP3 interface (0010)" is raised Impact to End user: No impact

3.80 BTS cannot detect the Rosenberger HB RETs with daisy chain mode Problem report: 122132ESPE01 Exists in Release: LN7.0 Correction Target: correction not needed Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: problem is in Rosenberger product and not in eNB SW. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 93/330 Version 1.0 Confidential


Flexi BTS cannot detect the Rosenberger HB Multi-RET daisy chain mode. How end user/operator could detect the problem: Connect the Rosenberger HB multi RETs to BTS and restart the BTS. Description of the fault: Cannot find the Rosenberger HB Multi-RETs Related feature / functionality: LTE2452 Dependency on configuration: FSMF + FHFB + ALDS Solution / Workaround: Change the RET SN sequence or change the OM sw detection method Impact to Operator: Flexi BTS cannot detect the Rosenberger HB Multi-RET daisy chain mode. Impact to End user: No impact

3.81 Antenna Line Device Failure 0010 for each MHA after RF unblock Problem report: PR050762 Exists in Release: LN7.0 0.2 Correction Target: correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: The alarm 0010 activates for all MHAs after RF unblock. Alarms stay active around 2 minutes and then they are cancelled. Solution / Workaround: There is no workaround available since the alarm 0010 is cancelled in couple of minutes after it is activated. Impact to Operator: More alarms for the statistics. Impact to End user: No impact

3.82 FZM reboots due to "BUG: soft lockup - CPU# stuck" after TL15A to RL55 backout Problem report: PR065078 Exists in Release: LNF7.0 Correction Target: RL70 1.2 Severity: B - Major Customer Impact: Operation & Maintenance Backing out from TL15A to RL55 (1407_130_53) causes the FZM to go into rolling reboot. Attached PRs: PR065078, PR066460 Probability: Permanent Description: 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. Solution / Workaround: acknowledge hIRQ in case if there is no vIRQ associated with it / no workaround



Impact to Operator: interruption in service Impact to end-user: interruption in service

3.83 Impossible to pair with FlexiZone via bluetooth using QR code Problem report: NA05820342 Exists in Release: LNF7.0 Correction Target: Correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: For some FlexiZone micro and pico hardware it might be impossible to pair over bluetooth using FZAUTH tool. The reason is that data is incorrectly encoded in QR code sticker on FlexiZone. Solution / Workaround: Please use FZAUTH tool in version FZAUTHREL_v1_4_20150728_1 It is delivered since BTSSM package BTSSiteEM-LNF70-1407_070_00 Impact to Operator: Impossible to pair over bluetooth with FlexiZone Impact to end-user: No impact.

3.84 FXED RF module failure (1910) with unknown trigger Problem report: PR066056 Exists in Release: LN7.0 1.0 Correction Target: Correction not needed Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Conditions under which issue was observed: LTE system was power on. After successful startup no faults are active and cells are OnAir. After that state fault 1910 - RF module failure appeared together with fault 4003 TX failure in MIMO with no trigger. Solution / Workaround: RF module block/unblock or power off/on. Impact to Operator: Cells on affected antenna lines are degraded or faulty, which in turn will effects KPI Impact to End user: User throughput degrade

3.85 DL Scheduler doesn't apply pdcchAggPreamb setting Problem report: PR061877 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 95/330 Version 1.0 Confidential


Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: DL Scheduler doesn't apply pdcchAggPreamb setting How end user/operator could detect the problem: Use pdcchAggPreamb different from pdcchAggRaresp Description of the fault: In case of PDCCH Order Allocation the used aggregation was based on pdcchAggRaresp istead of pdcchAggPreamb were used. Solution / Workaround: Workaround: Set some value for pdcchAggPreamb and pdcchAggRaresp Description of the correction: pdcchAggPreamb used in PDCCH ORder assignement Impact to Operator: The number of CCE used in Msg0 (Pdcch Order) assignment were choose according to pdcchAggRaresp instead of pdcchAggPreamb Impact to End-user: No impact.

3.86 IOMS SW restoration from Backup fails Problem report: NA05808014 Exists in Release: RL70_OMS Correction Target: OMS RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance, Operability Probability: Permanent Description: During MSU procedure upgrade partition was not always handled properly. Therefore sometimes it was not present in LDAP or some entries were missing. It caused full backup not to dump all needed information from LDAP. Solution / Workaround: For solution, edit usp_prepare file from Backup image and add lvcreate entries to add upgrade partition. No workaround. Impact to Operator: OMS Full Restore fails. Impact to End user: No impact

3.87 FM_Alarm Information can't show user the alarm information. Problem report: NA05824338 Exists in Release: RL70_OMS Correction Target: OMS RL70 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance, Operability Attached PRs: PR056299, PR063415 Probability: Permanent Description: The showing of empty alarm information view is caused by nullpointerexception detected after clicking the table to show the alarm information. Solution / Workaround: To address the issue (NullPointerException) the condition on the openAlarmInfoDialog() must be change that it can also allow opening the Alarm Info view not empty even if OMS History Analysis is not open. No workaround. Impact to Operator: Alarm information view shows empty after selecting a specific active alarm in the active alarm table. Impact to End user: No impact.



3.88 Application Launcher cannot be opened from NetAct after OMS 3.1 upgrade. Problem report: NA05809215 Exists in Release: RL70_OMS Correction Target: OMS RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance, Operability Probability: Permanent Description: Java 7 introduced SNI support which is enabled by default (In Java 6 it is disabled). This support should be disabled in Application Launcher client. Solution / Workaround: Disabled SNI support which is introduced in Java 7. For Workaround: Operator can add ’java -Djsse.enableSNIExtension=false’ argument inside script which running Application Launcher. Impact to Operator: Operator cannot login to OMS via Application Launcher by FQDN. Impact to End user: No impact

3.89 RF Module Failure(1920)- FRIG after PP0.2.5 upgrade Problem report: NA05809059 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: Power of the signal is too low and alarm 1920 is active. How end user/operator could detect the problem: Alarm 1920 will be visible. Power of the signal will be too low. Description of the fault: This fault is in gain control loop that was introduced for FRIG while fixing/improving gain algorithm in VEG SW (VCR238). Related feature / functionality: VCR238 Vegas DAPD and DPC limiting with controlled resets for better PA protection. Solution / Workaround: No workaround. Correction: Modification of gain control loop calculation to work as before VCR238. Impact to Operator: Alarm 1920 is visible. Impact to End user: No impact.

3.90 uecontextreleaserequest with cause Transport resource unavailable after RRCReconfiguration Problem report: NA05821760 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.1



Severity: B - Major Customer Impact: Capacity & Performance Probability: Occasional Description: UE lost after RRCReconfiguration due uecontextreleaserequest with cause Transport resource unavailable. In S1 HO procedure, eNB receives RRC Reconfiguraation Complete with wrong Transaction ID. In this case eNB sends S1 Release Request with Transport Resource Unavailable. Root cause: Some consistency checks were missing. Correction: Consistency checks were added in UEC. Solution / Workaround: Consistency checks was added Impact to Operator: Occasional UE lost after RRCReconfiguration due uecontextreleaserequest with cause Transport resource unavailable. Impact to End user: Service degradation for affected UE.

3.91 LTE 498 RIM for GSM Multiple Report PDU is re-send incorrectly when timer tRimKaG=150 mins Problem report: NA05816886 Exists in Release: LN6.0 Correction Target: RL60 3.1 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: eNB was making attempt to connect to remote peer too often due to value overflow. LTE498 uses two configurable timer tRimPollG and tRimKaG. That can be used to increase the delay between an eNB attempts to establish an association (in case of tRimPollG) or refresh the association (in case of tRimKaG). The timers were created by passing the delay in microseconds with the use of a variable that was not able to contain value bigger than 4294967295 (2^31-1). Due to the fact both timers wasn't constructed correctly for the values bigger than 71 minutes. Note: 72 minutes = 4320000000 4294967295 How end user/operator could detect the problem: Increased traffic on S1Link. If tRimKaG timer is set to 72, eNB will be waiting less than one minute to send another request. Faulty component and version: ENBC since - r209373 Solution / Workaround: Workaround: tRimPollG and tRimKaG values should be set to 71, the biggest possible value. Description of the correction: Proxy timer that ticks of the timer with smaller delay introduced Correction effects: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 98/330 Version 1.0 Confidential


Both timers tRimPollG and tRimKaG may be slightly less accurate, proxy uses 10 seconds timer. Thus the delays between attempt may increase by 10 seconds Impact to Operator: No direct impact, but indirect possible due to increased traffic. Impact to End-user: No impact.



3.92 After RL70 upgrade with PP 0.2 package, InfoModelGwExe crash seen in the eNBs log Problem report: NA05818357 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.2 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: In some cases after eNB restart InfoModelGwExe starts earlier than network interfaces. Because of that IMGW fails on bind to TCP/IP port. Solution / Workaround: Workaround: use nonSSL in place on SSL connection. Description of the correction: services behavior aligned between SSL and nonSSL Impact to Operator: Service impact Impact to End user: During crash period, calls are not able to proceed.

3.93 LTE1617 with other vendors eNB causes eNB restart Problem report: NA05818746 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Capacity & Performance Probability: Occasional Description: Customer reported a strange behavior that eNB restart occurs when LTE1617 RLF triggered HO is activated towards other vendors eNB. UE send RRC Connection Re-establishment Request to other vendors eNB so that trigger X2AP: RLF INDICATION and LTE1617 RLF triggered HO to ZTE eNB. Nokia eNB automatically restarts after RLF triggered HO procedure ends. Root cause: eNB is restarted, in case X2 source side handover is ongoing and source cell does not receive proper handover command. UEC binary crashes, during X2 handover source side when handover command is not received. UEC crash causes eNB restart. Correction: Check if HO command container is in proper format and if HO command exists inside container. If not - correcting procedure introduced. Solution / Workaround: No workaround. Impact to Operator: eNB restart occurs when LTE1617 RLF triggered HO is activated towards other vendors eNB. Impact to End-user: Handover fails occasionally. Loss of connection





3.94 NTP server is not accessible on eNobeB - chain configuration 1st(FSME+FTLB), 2nd (FSMF+FTIF). Problem report: NA05802783 Exists in Release: LN6.0 Correction Target: RL70 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: NTP server is not accessible on eNobeB - chain configuration 1st(FSME+FTLB), 2nd (FSMF+FTIF). Description of the fault: The pronto issue is due to leak in file-descriptors for the file /dev/confd in the process trsDrvCore, some open file descriptors in the process trsDrvCore are not closed after using them. Due to this the MAX_FD's for the process is reached and no more files can opened by this process. Due to no file descriptors available for this process, it leads to side-effects in other areas such as NTP and reading of MAC. In the case of NTP, ntpReachPoller code is unable to determine the ntp reachability, due to a failure in reading from a ntpq output file in /tmp directory. The issue is seen only when the EIF links are configured at different link speeds. Solution / Workaround: No workaround Impact to End user: User service affected Impact to Operator: NTP unreachable seen, though NTP server is reachable.

3.95 DU reset due to TRS software failure Problem report: NA05807893 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.1 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Multiple DU resets due to TRS software failure in customers network. FTM autonomous reset happened when the crash/ORB hang was seen. Root cause: Two causes identified which lead to TRS software failure, trsMgr crash and ORB hang. 1) trsMgr crash: The trsMgr crash was seen because of memory access to a freed pointer due to a race condition between AFW Reflect worker threads. One Reflect worker thread freed the thread specific memory allocated to it on termination. But the parent thread still had a pointer to that heap memory which became stale once the newly spawned thread terminated. As a result when parent thread accessed the freed pointer, that heap memory was already re-allocated and pointing to something else. This caused a SIGSEGV. This is a rare timing scenario when a newly spawned Reflect worker thread terminates within a few ms



after processing the RMI message and the parent thread which spawned it didn’t get a chance to run in the meantime. 2) ORB hang: ORB hang was due to trsDrvCore process got stuck while collecting ip table statistics for PM data. The call which invoked ip tables binary never returned. Since this was done in the context of RMI observer, it resulted in ORB hang. IP tables binary invocation is done using Linux popen() system call. On occasions when the newly spawned child process dumps a lot of output to stdio, the Linux pipe created to communicate with the child process might get full. This can cause the child process to hang. Correction: 1) TrsMgr crash: The race condition described above is fixed with proper synchronization between Reflect worker threads. This will ensure the thread structure memory will be freed only when there are no pending references to it. 2) ORB hang: Changed the popen to system call while executing commands for collecting iptable statistics for PM data as popen call may get stuck if linux pipe is full during the iptable command execution. Since current usage of ip tables is to dump output to a file in /tmp and then read that file, system is more suited than popen. Solution / Workaround: No workaround. Impact to Operator: Multiple DU resets due to TRS software failure in customers network. Impact to End user: No impact.

3.96 Critical fault with MHA on RRU antenna B ports Problem report: NA05814759 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: NA05814759, NA05815018 Probability: Permanent Description: After SW upgrade the MHAs on B feeder lines (antenna ports 2, 4 and 6) cannot be commissioned any more. Cell with this MHA comes up faulty with an alarm: Configuration error: BTS config error (Not enough HW for LCR) (1868). Root cause: After SW upgrade invalid SCF due to MHA with name="scannedAntennaInterface"NONE. Correction: Accept plan instead of reject it in this case. Solution / Workaround: Use Full recommissioning instead of partial. Impact to Operator: Recommissioning not possible in case of MHA with scannedAntennaInterface NONE. Impact to End user: No impact.



3.97 Second RF module disappeared after power reset Problem report: PR060929 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: RF module is not detected on 4G side due to link configuration problem. Alarm “Failure in optical interface (0010)” raise for shared radio module. Solution / Workaround: Description of the correction: Added handling of runtime link configuration change caused by 3G module Impact to Operator: Hardware not detected Impact to End user: No impact.

3.98 RP3 routing collisions are detected on FR module active on 9 sites after SW upgrade of 22 sites Problem report: NA05815139 Exists in Release: LN6.0 Correction Target: RL60 3.1 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Every time the RF module restart there will be an alarm regarding RP3 Routing Collision. Solution / Workaround: SW scenario responsible for synchronize signal from two different Optical port in Sharing scenario has been approved Impact to Operator: 2G voice calls doesn’t succeed during if the alarm is up Impact to End user: 2G voice calls doesn’t succeed.

3.99 [3G-4G RFS][RFS Automation: WL0831_CT#112]: WCDMA SW upgrade causes Configuration error: Faulty configuration of system modules (1858) alarm for LTE Problem report: PR060883 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major



Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: Additional reset on LTE side occurs after Fault1858 filtering time expires. Description of the problem: Fault1858 filtering time expires because synchronization between LTE and WCDMA did not occur within the 180s window provided causing an additional reset on LTE side. How end user/operator could detect the problem: Perform reset on 3G (sync master) system module: Description of the fault: Filtering time is not sufficient to wait for 3G startup time (~5 min) Dependency on configuration: 3G-4G RFS (more frequent on rel2 hw) Solution / Workaround: Description of the correction: Increase filtering time from 180s to 270s to allow enough time for WCDMA to start-up. Impact to Operator: Additional reset on LTE side is observed Impact to End-user: Loss of service

3.100 SW Rollback from FL15A to RL70 failed. Problem report: PR060475 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Configuration on FBBC link switch was applied twice after rollback. Cells are not OnAir on RMOD connected to FBBC. Solution / Workaround: Workaround: Additional manual reset. Description of the correction: Links switch is re-configured only if previous configuration request finished. Impact to Operator: Site is not operational after SW Rollback. Impact to end user: User cannot attach to the network.



3.101 After upgrade some sites have Antenna Line failure Problem report: NA05811006 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: NA05811006, PR063130 Probability: Occasional Description: Description: Fault 10 on antenna line with MHA and overcurrent detected occurs in startup without HWF. Root cause: CellP didn't create Power Relations on MHA_Ls if MHA_A::realDN is changed (MHA_L object corresponding to device is replaced by other object in IM). Solution / Workaround: Trigger setting Power Relations on MHA_A::realDN change. Impact to Operator: Cells are down, loss on traffic, KPIs degradation.

3.102 Online change of parameter "consecHoFailThres" needs additional site reset Problem report: NA05811194 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: After changing online parameter "consecHoFailThres" it is not activated. 1868 fault is raised and 1906 too. Reset is needed to clear situation. Root cause: In the process of recommissioning BBMOD configuration topology wasn't updated properly, RMOD connected to BBMOD wasn't aligned to the newly created network plan, so HW mapping when detecting radio module created new RMOD leaving the existing one in uncommissioned state after recommissioning. Correction: RMODs connected to BBMOD are properly applied to newly created network plan and topology is correct. Solution / Workaround: eNB site reset. Impact to Operator: Online change of parameter "consecHoFailThres" needs additional site reset. Impact to End user: Disconnect and/or loss of service.

3.103 Configuration error: BTS config error (Not enough HW for LCR) (1868) alarm after site



upgrade to RL70 PP0.2 Problem report: NA05798720 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Bug in CellP during adding into IM passive MHAs connected by CABLNK problems in startup in configurations with MHAs Only configurations with MHAs Solution / Workaround: Workaround: Remove MHAs from configuration. Description of the correction: Bug in logic responsible for creation adding MHAs into IM corrected. Impact to Operator: Configurations with MHAs couldn't go OnAir. Impact to End user: Cell is not OnAir.

3.104 After LTE SW upgrade, auto Reset occurred by eNB side Problem report: NA05816767 Exists in Release: LN7.0 1.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05816767, PR059441, PR059767 Probability: Occasional Description: Summary of the original problem: During upgrade from RL60 MP1.1 to RL70 MP1 P7，shortly after site becomes available for remote connection, second site restart is triggered. After the second site reset was completed FXEA 1.1.1 took long time to be detected and initialized, fault 4001 showed. In total 3 BTS restarts were needed and taking site upgrade outage time to around 20min. How end user/operator could detect the problem: Fault 4001 EFaultId_BtsResetNeededAl was reported for cell. Description of the fault: Code was not prepared for a situation when there's one lna under mha in infomodel. Because of that unexpected reset happened causing internal configuration issues. The configuration issues were causing 4001 alarm. Solution / Workaround: Workaround: Execute reset after fault 4001 Description of the correction (incl. risk analysis): Check if mha has other lna than checked one Impact to Operator: In total 3 BTS restarts were needed taking site upgrade outage time to around 20min. Impact to End user: Call cannot be setup successfully under the faulty cell.



3.105 Clock drift after eNB reset Problem report: NA05814196 Exists in Release: LN7.0 1.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: After SW upgrade synchronization tuning failure is seen in eNB occasionally. Root cause: Tuning failure will be seen and "Difference between BTS master clock and reference frequency" alarm will be seen in the BTS if synchronization Configuration with any of the FTIF interfaces used. PLL is seen as not initialized in the faulty units. According to PLL datasheet, once ddal_reset_set is done for PLL, 5ms delay should be there before initializing the PLL. Correction: Once the 5ms is included as per the datasheet, PLL initialization should succeed. Solution / Workaround: Possible clock tuning issue after upgrade when SyncE is in use. Impact to Operator: After upgrade operator is not able to use the clock from master clock source. Impact to End user: No impact.

3.106 Backup Commissioning file collection failed after LTE SW upgrade Problem report: NA05812123 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: There is a situation where SysAdapter tries to create objects in IM with same DistName (Same InstanceId to be specific). UPLD_REQ based on requestId has been created that came with req msg. “requestId” is unique only for one session so after reconnecting with BTSSM it will be same as during previous session. Operator would see error window as Cannot get the commissioning parameters on SiteManager. Solution / Workaround: Avoid short periods between BTSSM connection sessions. Once problem has been reproduced the only workaround is a reset (software or hardware) of associated eNB. Impact to Operator: Backup commissioning operation on SiteManger is failed. Impact to End user: No impact.



3.107 Cannot administer eNB remotely. Problem report: NA05813390 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Experienced issue that BTS cannot be administered remotely How end user/operator could detect the problem: Wide spread of possible problems, i.e. no Ethernet on FR, cell down, no call, problems with BTS recovery. Description of the fault: DiagnosticDataRead RP3-01 message interference causes invalid read of FR productCode and serialNumber. Solution / Workaround: Workaround: BTS hard reset Description of the correction: When invalid read of productCode or serialNumber detected, rest of DiagnosticDataResponses are ignored before repeating whole operation. No risk of regression. Impact to Operator: BTS stuck, not administrable remotely. Impact to End user: Call is dropped.

3.108 RF Module (FRIG) is not detected (0010) and (2016) after upgrading from LN7.0_ENB_1407_557_36 to LN7.0 PP0.2.5 Problem report: NA05812460 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Rare or Occurrence Description: Summary of the original problem: There is a hardware issue on SM Murkku that (very occasional) cause that response for Rp3 message send to node on particular port is routed to some other port (where different node is connected). Here NodeLabel message was incorrectly routed therefore SM saw two different node sent the same message payload (NodeLabel message contains serial number and product code of the node). This broke the detection of the node. Description of the fault: Internal description of the fault which causes detected problem. Dependency on configuration: Issue can be visible on any configuration although it is very rare. Solution / Workaround: Workaround: Site reset, issue is very rare. Description of the correction: NodeLabel message will be send twice in order to check if both responses are the same. Impact to Operator: On effected startup radio module unit could not be detected and configured; cells on LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 109/330 Version 1.0 Confidential


that radio could not reach onAir state. Impact to End user: Out of service of affected cells.

3.109 BASE STATION OUT OF USE after IUB break Problem report: NA05812633 Exists in Release: LNF7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05812633, PR052548, PR053416 Probability: Permanent Description: LTE1857 "Basic Ethernet Switching (Daisy Chaining)": Ethernet Switching with Chaining FzP135 Port #1 (copper) connected to Core and Port #2(copper) connected to Chained FzP136 Port #1. Both sites are working as standalone but when configure as daisy chaining, slave site is not on-air. We did switch master/slave where FzP136 (internal antenna, 11.255.131.21) as master and FzP 135 (11.255.131.20) as slave, however the issue remains the same where slave site was not on-air and ping to GW failed. The master site is always up, but sometimes slave site got reset by itself. Then no local connection available. HW Reset is needed to connect back to slave site locally. Root cause: Restarting ethernet autonegotiation on BH link makes the link unusable. Correction: Changes in LFS related to PHY configuration done. Entries in dts file and DDAL library (ddal_phy_copper_restart_autoneg function) correct this issue. Solution / Workaround: Site reset. Impact to Operator: Site visit needed to do HW Reset to connect back to slave site locally. Impact to End-user: Service not available.

3.110 M8006C45 "Sum of simultaneous E-RABs of QCI1" abnormal recorded Problem report: NA05806023 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: After SW upgrade it was detected that counter M8006C45 "Sum of simultaneous E-RABs of QCI1" abnormal recorded. Root cause: In UEC SW some increments and decrements of "sum of simultaneous erabs" are incorrect. 1. Sum of simultaneus erabs counters were not decremented when unsuccessful trsw setup scenario was LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 110/330 Version 1.0 Confidential


followed by ArpRacRollbac. 2. Sum of simultaneus erabs counters were not decremented after receiving RacReleaseResp in some scenarios. 3. Sum of simultaneus erabs counters were erroneously decremented when RacResp triggered undo or cleanup actions. 4. Sum of simultaneus erabs counters were erroneously decremented after r8 CSFB. Correction: Increments and decrements of "sum of simultaneous erabs" counters were adjusted to eliminate erroneous ones. Solution / Workaround: No workaround. Impact to Operator: Incorrect counter values at M8006C45 "Sum of simultaneous E-RABs of QCI1". Impact to End user: No impact.

3.111 CCN revision number decreases after site reset Problem report: PR036573 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: CCN revision number decreases after site reset How end user/operator could detect the problem: After site reset (due to recommissioning, SW update, etc.) NetAct will detect that there’s invalid CCN message from eNB and will request configuration upload. Description of the fault: During site reset some CCNs are sent, but the revision number is not incremented Related feature / functionality: LTE954 Solution / Workaround: No workaround Description of the correction (incl. risk analysis): During site reset SysAdapter is blocking any CCNs which can’t be sent. Behavior during site reset may be slightly changed. Impact to Operator: If LTE954 is in use, unnecessary configuration upload will be avoided. Impact to End user: No impact

3.112 Trace failure (6263) with additional info "trace reference in use, trace cannot be started" Problem report: NA05791005 Exists in Release: LN6.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 111/330 Version 1.0 Confidential


Description: Operator observed large amount of alarm 6263 with information "trace reference in use, trace cannot be started" when Subscriber Trace Session were activated for UEs in the network. Root cause: eNB did not remove the Subscriber Trace Session (which was not successfully started e.g. due to disabled Subscriber Trace feature in eNB) after the reception if S1AP:DeactivatateTrace message from MME. This stored session was later passed via X2HO (or intra eNB HO) to the next eNB and caused the conflict with the new Subscriber Trace Session requested by MME in the target eNB. Planned correction: The Subscriber Trace Session which was not successfully started is now correctly removed (UEC) from eNB after reception of S1AP:DeactivatateTrace from MME. Solution / Workaround: No workaround. Impact to Operator: Large amount of alarm 6263 with information "trace reference in use, trace cannot be started" when Subscriber Trace Session were activated for UEs in the network. Impact to End user: No impact.

3.113 Synchronization did not recover after restarting ToP server Problem report: 122210ESPE01 Exists in: LNF7.0 Correction Target: RL70 P8 Severity: C - Minor Customer Impact: Operation & Maintenance Description: After rebooting it doesn’t get synchronized to real time, so BM realize there is too big delay between current BM state and ToP Master. In that case our BM discards all packages that comes to it and turns off that master and get to soft reset state which doesn’t clean buffer of old samples. In result BM tries to make such soft reset each 3min and never recover from it. Probability: Permanent Solution / Workaround: Check out in use checkbox for ToP and Check in use checkbox for ToP again. Impact to Operator: No ToP sync after server restart.

3.114 ALD devices remain faulty after unblock RF during 1923 alarm testing on LN7.0_ENB_1407_550_71 Problem report: NA05800425 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: NA05800425, 126705ESPE04 Probability: Occasional Description: Summary of the original problem: Crash that happened because PortStatusIndicationPoller didn't unsubscribe for portConf becoming Synchronized when the PortStatusIndicationPoller object was destroyed. Solution / Workaround: No workaround. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 112/330 Version 1.0 Confidential


Description of the correction (incl. risk analysis): Change the method of allocating 128kB continuous memory by MTD driver whenever HWAPI application calls bare metal flash read/write operation from dynamic kernel memory at every requests to static kernel memory at the beginning of eNB startup to avoid further memory reclaim procedure being triggered by MTD driver. Impact to Operator: ALD devices faulty after unblock RF Impact to End user: No service.

3.115 Abnormal KPI value in LTE_5603A and LTE_5601a Problem report: NA05803652 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Too large value(about 2^32) in LTE_5603A & LTE_5601a Solution / Workaround: No workaround Impact to Operator: Wrong KPI value Impact to End user: No impact

3.116 OMS switchover in eNB then Serving OAM system "None" Problem report: NA05788578 Exists in Release: LN6.0 Correction Target: correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: OMS switchover from Primary to Secondary by CM Plan. “Serving OAM system showed “None” in Site manager” Solution / Workaround: Workaround -- Perform switchover again Root Cause: Since two threads are involved in connection closure and connection establishment, they seem to be overriding the servingOms status updated by another. Solution: While updating the sevingOms to any, check once again if in reality the connectivity with OMS is in line with the servingOms value. Impact to Operator: Mismatch servingOMS status between real eNB connected iOMS and site Manager Impact to End user: No impact.



3.117 1910 RF module failure occurred on the FHDB Problem report: NA05802473 Exists in Release: LN7.0 0.1 Correction Target: RL70 0.2 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Unnecessary Low power alarms seen after update to LN7.0_ENB_1407_556_54. No other than FHDB affected by this issue. Solution / Workaround: Workaround is either FHDB power reset or SW downgrade/upgrade. Impact to Operator: Alarm of MIMO failure. Impact to End user: No maximum performance can be served since only single path among MIMO path is enabled.

3.118 FSMR3: ARP is not getting resolved after enabling VLAN aware flag Problem report: PR043091 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Capacity & Performance Attached PRs: PR043091, 59635ESPE05 Probability: Description: On enabling VLAN aware on primary eNB, ping between the chained and primary does not work Description of the problem With default vlan configured and when Ethernet aware and VLAN aware switching are enabled ping doesn't works. Test procedure: 1. Have two DUT's. 2. Configure transport interface on one DUT with ip address assigned (say 30.30.30.3). 3. On the other DUT create a vlan interface (say vlanid 7), assign an ip address (say 30.30.30.4) and enable the Ethernet aware and VLAN aware switching. Also in the default vlan for ports enter the vlan id which is configured and in the Vlan id list give other vlan ids excluding the configured vlan id (i.e. 7). 4. Now ping from the plain interface (30.30.30.3) to the vlan interface (30.30.30.4). No ping reply is seen. Even ping in reverse direction doesn't works. Solution / Workaround: Description of the correction: 1. When the arp reply was sent by the other DUT it comes with vlan tagged. But here the reply is to a plain interface. So the arp reply should be a plain one i.e. vlan tag removed. Root cause: In the Ingress the vlan tag gets added for the request packets. In egress when the host(Linux) sends arp reply it fills some priority in the Vlan header . In FP there was a check which compares whether the priority in the packet and the default priority are the same. But in this case it fails LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 114/330 Version 1.0 Confidential


as the default priority is 0 and the priority in the packet is different. This check was added as a fix for some corner case. Only when the check passes the vlan is untagged. Fix: Removed this check from the vlan untag place and moved the get_queue_offset function before the vlan untag function which would handle the priority. 2. After this fix the ping reply was seen but only for first two or three requests. From the packet dump we observed that in ingress the vlan tag was not getting added for further requests. Root cause: Only the first few packets go through the usual element handler. But after that the packets go through the cached handler. In ingress in the L2 switch cached handler only the vlan id was tagged into the packets but the vlan header was not added. This was causing the problem. Fix: Modified the function so that it adds the complete vlan header. Impact to Operator: On enabling VLAN aware on primary eNB, ping between the chained and primary does not work. Impact to End user: No impact

3.119 2 Cells are down after BW change of another cell Problem report: PR046004 Exists in Release: LN7.0 1.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: After change BW of one cell from 10 MHz to 15 MHz and BTS Reset two cells are comes down. This one cell which i change BW is coming up normally with changed BW. Cells are disabled and no alarm is raised. Summary of the original problem: No alarm is raised when cell is disabled. How end user/operator could detect the problem: In BTS SM is visible that cell is disabled. Solution / Workaround: Workaround: Connect each RF module with FSM with 2 optic cables. Description of the correction: Correction adds this scenario to fault 1868 and enable alarm 7653 with additonal info: “Detected hardware doesn’t allow to setup cell according to configuration”. Impact to Operator: Cell is unavailable. No Alarm is visible in BTS SM or NetAct Monitor. Impact to End user: Cell is unavailable.

3.120 9047 alarm start arriving from the element Problem report: NA05800034 Exists in Release: RL70_OMS Correction Target: iOMS RL70 1.1 Severity: A - Critical Customer Impact: Operability Probability: Rare one occurrence LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 115/330 Version 1.0 Confidential


Description: It was reported that after LTE iOMS backup failure, LTE iOMS stops sending alarms to NetAct and alarm 9074 (ALARMS FROM NETWORK ELEMENT NOT ARRIVING) is raised on NetAct. Solution / Workaround: Restart of Alarm Processor to start reading new alarm file: fshascli --restart /AlarmSystem Impact to Operator: LTE iOMS stops sending alarms to NetAct Impact to End user: No impact

3.121 S1 base handover counter update mismatch Problem report: NA05798920 Exists in Release: LN6.0 1.1 Correction Target: RL70 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: S Customer complaints about high number of M8014C17 INTER_S1_HO_PREP_FAIL_OTHER in KPI report. The overall amount of failures is very close to same our KPI repot M8014C17 INTER_S1_HO_PREP_FAIL_OTHER total number 5498. Root cause: M8014C17 "Failed Inter eNB S1-Handover preparations due to other reason" is updated after source eNB has already received "handover command". Correction: Implementation corrected according the requirements. Solution / Workaround: No workaround Impact to Operator: PM Counter M8014C17 "Failed Inter eNB S1-Handover preparations due to other reason" not correct. Impact to End user: No impact

3.122 Multiple “Unit autonomous reset” on FBBC Problem report: NA05802135 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Description of the problem: Multiple “Unit autonomous reset” on FBBC How end user/operator could detect the problem: Alarm list from NetAct/SEM Description how problem can be detected Alarm list from NetAct/SEM Solution / Workaround: N/A LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 116/330 Version 1.0 Confidential


Impact to Operator: Alarm on NetAct/SEM Impact to End user: Service interrupt during the crash and unit auto reset

3.123 FID 4019 was occurred after SW activation due to segmentation fault in ENBC Problem report: NA05815215 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Capacity & Performance Probability: Occasional Description: Summary of the original problem: ENBC crash due to invalid memory reference. How end user/operator could detect the problem: BTS restart due to ENBC crash Description of the fault: ENBC crash due to invalid memory reference. Problem may occur when during ongoing AdjacentCellConfiguration which is part of X2 Setup and X2 Configuration update procedure. When link is closed due SCTP association error/due SCTP is closed by neighbor/ or due aborted ongoing X2 Setup procedure and there is still ongoing AdjacentCellConfiguration procedure it is possible that response from RROM for started AdjacentCellConfiguration is received when X2 link is already removed by ENBC. That may happen when removing of X2 link by ENBC and TUPC on SCTP layer take less time than ongoing validation of previously received neighbor eNb configuration. Solution / Workaround: No workaround. Description of the correction: In scope of correction additional checks are added to avoid calling callback on not existing object. Additionally procedures which may call callbacks which caused crash are aborted during X2 link removal. After correction ENBC shouldn't crash when X2 link goes down during ongoing AdjacentCellConfiguration. Impact to Operator: Temporary service outage of eNB due to site reset with FID4019 Impact to End user: Temporary service outage of eNB due to site reset with FID4019



3.124 maxNumRrc and maxNumRrcEmergency value is changed after SW upgrade causing parameter validation error Problem report: PR040548 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Parameters maxNumRrc and maxNumRrcEmergency value are changed after SW upgrade causing parameter validation error. Correction: certain maxNumRrc and maxNumRrcEmergency migrations changed to take the actDLCAggr flag into account on the migration. Solution / Workaround: The certain maxNumRrc and maxNumRrcEmergency migrations changed to take the actDLCAggr flag into account on the migration. Precondition actDLCAggr = true for the relations in section (6). Migrations done only if actDLCAggr is true. Impact to Operator: Parameter validation error occurred due to changed maxNumRrc and maxNumRrcEmergency values. After correction, no validation error occurs. Impact to End user: Parameter validation error occurred due to changed maxNumRrc and maxNumRrcEmergency values. After correction, no validation error occurs.

3.125 TRS software failure and site reset Problem report: NA05798475 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: BTS rebooted unexpectedly during snapshot creation. After restart BTS restart due to TRS software failure alarm was seen (61006). Snapshot was partially created. Root cause: A thread in ipda_cv (on Octeon) had acquired run permission and was printing a trace message when it got stuck. This led to ORB hang since subsequent RMI messages got blocked on run permissions. There’s no information on what this thread was doing, but it most likely got stuck on mq_send() while dumping trace (addTraceEntry). The only obvious reason mq_send() can get stuck is the queue is full (reached MAX_MSG limit). We create the message_queue in blocking mode (default) and hence mq_send will block indefinitely once queue is full if no thread/process picks messages from the queue. Most likely trcFwd process on Octeon (which is supposed to pick messages from the trc msg queue) got terminated. This is not spawned using Task Manager, so if it got terminated, it won’t be restarted automatically. trcRemoteLogHdlr on WP is started via Task Manager with automatic restart flag set. Correction: Three improvement changes done. 1. Change the mq_send() call in addTraceEntry(traceLibRemote.C) to mq_timedsend() call with a timeout LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 118/330 Version 1.0 Confidential


of say 4 secs. That way if message queue is full, it will at least timeout and release run permissions in the event ECL_TRACE is called with run permissions. 2. In trcFwd process, we terminate the application even if msg parsing failed just once or mq_recv() failed. We can change the logic such that trcFwd prints an error message on console (which will come in uart_telnet_srvr trace set I think) on error condition and continue with waiting for next message in message queue. That way we can prevent trcFwd process getting terminated on a corrupted message. 3. Change trcFwd application to spawn a child process for actual functionality and re-spawn if it’s terminated. Solution / Workaround: No Workaround. Impact to Operator: BTS will go for abnormal reset due to TRS software failure. Impact to End user: No impact.

3.126 FSMF+FBBC - Two cells are disabled (FBBC local mode) after activating UL comp Problem report: NA05804007 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: NA05804007, NA05809614 Probability: Occasional Description: Two cells are disabled (FBBC local mode) after applying uplink comp. Root Cause: During UPlaneDeployment calculation ULCompGroup was being assigned to wrong FSP in that configuration. It was being assigned to SMOD even though none of cells in that ULCompGroup was connected to SMOD at all. Correction: Change the way ULCompGroup is assigned to FSP – now it is being checked if cells under that ULCompGroup have any real connection to FSP to which ULCompGroup attempts to be connected. Solution / Workaround: This issue can be clear by deactivating uplink comp. Impact to Operator: Cell setup failure after applying uplink comp. Impact to End user: No impact.

3.127 Fix reboots and random operation when UART is disabled Problem report: PR059399 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Secured (UART disabled) board goes into rolling reboot and falls back to previous software load after a software upgrade. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 119/330 Version 1.0 Confidential


Solution / Workaround: Do not disable UART. Impact to Operator: Unable to upgrade to new software releases. Impact to End-user: No impact.

3.128 After upgrade some sites have RF Module Configuration Failed Problem report: NA05811008 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: After upgrade of 2G/4G RFS site from RL60 to RL70 0.2.6 some sites showed fault "RF Module configuring failed (1900) " and cells are out of service (faulty) Summary of the original problem: RMOD_L object created by FactoryExecutor was incorrectly removed. Because of that CABLNK_L to PHYANT_L was not removed and are still active then cause routing issue. Dependency on configuration: Issue can be visible only with 2G/4G or 3G/4G radio sharing configuration and only during software update or when the hardware configuration file (HWF file) is not present yet. It’s not permanent as it also strongly depends on communication timing between OAM components. Solution / Workaround: Workaround: Site reset Description of the correction: Don't remove RMOD-L object created by FactoryExecutor Impact to Operator: Some cells are faulty after RL60 to RL70 upgrade. Impact to End-user: Some cells do not provide service.

3.129 UTC PTP offset change Problem report: PR040667 Exist in Release: LN7.0 0.1 Correction Target: RL70 1.1 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: UTC offset change was not handled properly. How end user/operator could detect the problem: In case of phase sync mode BCN validation will fail once GPSUTC offset has changed (next UTC offset change at end of June 2015). BCN validation is done at startup and after every holdover. If validation fails, BTS will reset. Description of the fault: In case of UTC offset change there was not updated OS time immediately after offset change (existing NTP solution reacts too slow to change. This was leading to failure in common BCN setting. Dependency on configuration: phase synchronization Faulty component first delivered in(e.g. release, CD): LN7.0 onwards Solution / Workaround: Workaround is not possible, BTS will reset after fault and recovers autonomously. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 120/330 Version 1.0 Confidential


Impact to Operator: There will be reset of base stations in case of GPS-UTC offset has changed. This will lead to service break and have impact to KPIs. However, this will not happen very often as GPS-UTC offset changes only when leap second is inserted in UTC. The period between inserting leap second is typically several years. Impact to End-user: Service break.

3.130 Issues encountered with some 6 sector sites during RL70 upgrade Problem report: NA05807655 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Description of problem: After RL70 upgrade, for some sites the sixth sector didn’t come on air but no alarms reported. All these sites have the 6th sector RF Chained and the second RF Module in the chain doesn’t go on air. No issues after rolling back to RL50 SW. Dependency on configuration: - RMOD type FRIG or FHGB or FRHD or FRHE - Chain configuration (including FRIG/FHGB/FRHD/FRHE in chain) - Usage of port 3 (OPTIF 3) on any of the above RFMs in chain Solution / Workaround: No workaround. Impact to Operator: Due to lack of connection on bbswitch Operator cannot use chain configuration based on port 3 of radio module. Using port 3 in radio chain will occur in cells being down (or some of them - depending on configuration). Impact to End user: Due to lack of connection on bbswitch end user cannot use chain configuration based on port 3 of radio module.

3.131 NTP server is not accessible (61613) Problem report: PR053692 Exists in Release: LN7.0 1.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Rare one occurrence Description: Summary of the original problem: NTP external server was not accessible when there was switched from GPS. Description of the fault: After switching time source to NTP server and when time difference between BTS and time source is greather then 400ms the ntpd must be restarted i.e closed and run again. In this fault the ntpd was closed but not started. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 121/330 Version 1.0 Confidential


Solution / Workaround: No workaround. Description of the correction: In function stopNTPD reset status was added. When nptd is restated and this flag is set the ntpd is restarted. Impact to Operator: Problem can be seen, when e.g. external NTP server is switched to GPS and vice versa. Operator will see problem with time setting on BTS. Impact to End user: BTS is restarted because time cannot be set.

3.132 [LN70]Throughput 5MHz UL wrong KPI Problem report: PR053800 Exists in Release: LN7.0 1.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance KPI statistics. Probability: Permanent Description: Summary of the original problem: Expression (M8001C266 / M8001C267) / (M8001C420 / 100) = 1.27 in case of 5MHz, but it should be at least between [0.95; 1.05]. Counters of average number of users with buffered uplink data have different value. Description of the fault: Sampling for average counters related to buffered UE data in uplink are counted incorrectly and uses as divider for M8001C420 and as result it leads to different values. Faulty component and version: LN7.0 LTEL2 Solution / Workaround: No workaround Description of the correction: Sampling should be incremented one time for one TTI even if reports came unordered with different TTI are used. Impact to Operator: Incorrect KPI statistics about users with uplink buffered data: M8001C266 / M8001C267 and M8001C420 / 100. Impact to End user: No impact.

3.133 [4G-2G RF Sharing][FSMr3]: Alarm 1958 active on LTE 15MHZ BW (Option2 cabling; FXEA shared RFMs connected to FBBC). Problem report: PR054745 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance No impact Probability: Occasional Description: The operator was unable to connect 2 shared radios to 1 FBBC - such configuration hasn't been supported on software level.



Solution / Workaround: No workaround. Impact to Operator: No impact. The operator hasn't been using this particular configuration. Impact to End user: No impact.

3.134 Initial Context Setup failure happens with Transport Resource not Available (trswcause=47) Problem report: NA05805321 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Initial Context Setup failure happens with Transport Resource not Available (trswcause=47) Solution / Workaround: Description of the correction: Implementation required in TRSW to handle the multibearer GTP_RES msgs in case of FSP specific reset. Impact to Operator: Operator will see lot of UE connection failures for one particular set of TEIDs. UE calls would not be established for a particular set of TEIDs. In effect the total number of calls supported by the eNB would be less than the actual maximum supported number of connections. Only a full BTS reboot would solve this. Impact to End user: If user's calls request an Initisl Context Setup Request with problematic TEID, this call is failed by TRSW. UE connections would fail randomly.

3.135 Red-incomplete configuration Enodeb failed to take any configuration change during comisioning it resets immediately Problem report: NA05808086 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: A – Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: HwMapping could crash when there were RETs from SCF without prodCode or serNumber. This can only happen for "passive" RETs (using ASIG1.1) that are not supported anymore in RL70. Solution / Workaround: Description of the correction: Two defensive checks have been added in LteHardwareToUnifiedTreeTranslator class. Impact to Operator: After crash operator will observe bts reset. Impact to End user: Users could not connect to bts during its restart.



3.136 Failure in Optical RP3 Interface Alarm Problem report: NA05809058 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Permanent Description: LTE sites that use GPS synchronization and "Network synchronization mode" = phaseSync will not reach commissioned state during RL70 startup if GPS receiver alarm (4125) is present during start-up. Solution / Workaround: LTE sites that use GPS synchronization and "Network synchronization mode" = phaseSync will not reach commissioned state during RL70 startup if GPS receiver alarm (4125) is present during start-up. Impact to Operator: eNB will not reach OnAir under the described conditions. Impact to End user: Some cells are out of service.

3.137 Incompatible SW Version after SW Upgrade to PP.0.2.5 Problem report: NA05808857 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Rare one occurrence Description: After SW upgrade the following alarms was observed: SW Fallback (4085), Incompatible SW version detected (0023). In addition, all of the RF modules and FBBC were being reported as “faulty” after the software upgrade. Site was stuck in “Integrated” state. Root cause: During SW upgrade a persistency file was not deleted. This resulted in failure of configuration on TRS (due to duplicate MOCs). Correction: Deleting persistency will avoid duplicate configuration. Solution / Workaround: If SW fallback happens (from RL70 to previous release) caused by alarm 4085: EfaultId_FallbackDueToTransportRequestAl, "Transport SW on the source unit has indicated the need for a software fallback", check for presence of file persisted on passive file system (/ffs/stb/trs_data/db/persist.db) and if it is present, delete it manually. After that SW upgrade to RL70 should be possible. Impact to Operator: During SW upgrade a persistency file was not deleted. This resulted in failure of configuration on TRS (due to duplicate MOCs) and SW upgrade is not possible. Impact to End user: No Impact.



3.138 No outgoing X2 ANR links after deleting LNADJ/LNADJL and activating UE based ANR Problem report: NA05809453 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.1 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Description of the problem: Relations in ENBC are not updated after some time due to transactionGroupId counter overflow. How end user/operator could detect the problem: By increased number of S1 HO attempts (due to missing X2 links) Description how problem can be detected: Updating relations enough times to overflow 16bit counter. Faulty component and version: ENBC/RROM Solution / Workaround: Workaround: eNB reset. Description of the correction: RROM uses dedicated counter for transactionGroupId instead of JobSequence counter. ENBC detects overflow and handle ENBC_RelactionsConfigReq properly. Impact to Operator: SON features operation. Impact to End user: No impact.



3.139 Cells are down after upgrading to LN7.0 PP0.2.5 Problem report: NA05811265 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Rare one occurrence Description: DeploymentCalc failed for one LCELL. Root Cause: DeploymentCalc triggered to soon due to SCF RMOD deletion and inappropriate antenna mapping check. Correction: Added additional check for antennas existence in IM. Solution / Workaround: No workaround. Impact to Operator: DeploymentCalc failed for one LCELL. Impact to End user: No impact.

3.140 All cells go faulty and off-air after FBBC Hot insert Problem report: PR057309 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: After insert non commissioned FBBC Sysadapter/RROM report it as non-available for CPLANE. CPLANE return error because BBU wasn't reported earlier in HwConfigReq. Fault was triggered and cell goes down. Solution / Workaround: HwConfigChange won’t be sent for non Commisioned bbu. Fault will be reported for affected LNCEL, not for CPLANE Mo. Impact to Operator: Operator couldn't hot insert uncommisioned FBBC when BTS is OnAir. It caused drop all cells and trigger alarm 4001. It caused detach UEs. Everything back to normal after reset and commission extension module. Impact to End user: Before correction end-user need to reset BTS and commission extension module.

3.141 Antenna Line device failure Alarm not reporting from two enodeBs. Problem report: NA05810708 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B – Major Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 126/330 Version 1.0 Confidential


Probability: Occasional Description: Alarm is not generated because EndLess device scan is not handled. Solution / Workaround: Solution: Modify the code to raise an alarm when EndLess device scan is detected. Workaround: Execute RMOD block/Unblock to see whether device is getting detected or not. Impact to Operator: RET device will be shown as lost without an alarm Impact to End user: No impact

3.142 FBBC RP3 port stuck in blocked after SW upgrade Problem report: NA05808858 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Occasional Description: After software upgrade radios connected to FBBC port 3 are not detected. Also eNB is stuck in Integrated to RAN state. After reset radios were detected and all cells are OnAir. RP3 Connector is disabled because last status update of FBBC OM got from HWAPI is SwUpgrade. Root cause: LFS overwrite SRIO master enabling. Correction: Disable LFS access during master enable setting by DSP. Solution / Workaround: Additional eNB reset necessary to get eNB OnAir. Impact to Operator: BTS cannot go OnAir after SW upgrade. Additional eNB reset necessary. Impact to End user: No impact.

3.143 After upgrade some sites have Not Enough HW fault Problem report: NA05810855 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B – Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: After upgrade from RL60 to RL70 0.2.6 some sites showed fault “BTS configuration error (not enough HW for LCR) (1868)” and related cells did not reach OnAir. How end user/operator could detect the problem: Fault “BTS configuration error (not enough HW for LCR) (1868)” is present and related cells are in faulty state. Description of the fault: It can only happen for site with MHAs connected to two radio modules at same time (affected sites had also 6 MHAs or more). - In case of configurations with many ALD devices (e.g. MHA/RET), startup becomes more complex and LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 127/330 Version 1.0 Confidential


takes more resources. - Because of that, at some point in time O&M “forgets” that we already created MHA objects, and we create them for the second time on same port in our internal model. - eNB determines that there are MHA’s that were not detected successfully (those which are created as duplicates) which leads to the issue and alarm. Dependency on configuration: MHAs connected to two radio modules at same time Solution / Workaround: Site reset recovers the eNB. Impact to Operator: Some cells do not reach OnAir after SW upgrade from RL60 to RL70. Impact to End user: Some LTE cells do not provide service until WA is applied.

3.144 enodeB locks up and cannot administer site remotely. Call Processing stops and customers are impacted.

Problem report: NA05810628 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: A – Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: When ALMAG processes SetDeviceData with longer inputs, it writes to incorrect memory and causes BTSOM reset. Solution / Workaround: Description of the correction: ALMAG truncates and store the longer input to correct memory. Impact to Operator: enodeB reset.



3.145 FSMr3 [Automation]: BTS stays in commissioned state after site reset in RF hot remove testing Problem report: NA05808859 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05808859, PR045968 Probability: Occasional Description: Summary of the original problem: Startup problem Description of the problem: Unexpected restart of bts result in broken startup How end user/operator could detect the problem: Cells not on-air Solution / Workaround: Workaround: BTS restart Description of the correction: HWFController Impact to Operator: Lack of alarms indicating not fully operational BTS. Impact to End user: Calls are not possible.

3.146 In co-sited BTSs, 2Mhz Sync Out does not work after 10Mhz Test Clock is enabled and then disabled Problem report: PR046584 Exists in Release: LN7.0 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: 2.048MHz sync output will be cut off from master when 10MHz test clock will be enabled and won’t be activated after 10MHz clock will be disabled. Root cause: ddal_clk_set_2M48_ref_clk_src(DDAL_REF_2M48_CLK_SRC_GND) is not executed when we disable syncOutFrameClock. Correction: On DiffClockOut 2M will be available instead GND if 2M is available in SingleEndedClockOutput. Solution / Workaround: No workaround. Impact to Operator: Slave BTS loses secondary sync source from Master BTS. Impact to End user: No impact.

3.147 L7 cell faulty and BTS reset required alarm shows after SW upgrade from RL60 MP1.1 to RL70 P8 Problem report: NA05791334 Exists in Release: LN7.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 129/330 Version 1.0 Confidential


Correction Target: RL70 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Occasional Description: After eNB was upgraded to RL70 P8 load, the two cells were disabled and 4001 alarms "BTS reset required" raised on the cell49 of FRPA; the additional information for this alarm is "BTSOAM is not able to configure routings". Root cause description: Port speed auto-negotiation for secondary port has been triggered before synchronization of primary port. Solution / Workaround: After reset the eNB, all cells recovered. Impact to Operator: Alarm 4001 is showing. Impact to End user: No impact

3.148 RP3 alarm and Cell Configuration Data Distribution Failure alarm shown after rollback to RL60 MP3.0.1 from RL70 P8 Problem report: NA05791955 Exists in Release: LN6.0 2.1 Correction Target: correction not needed Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: eNB rollback procedure was triggered from NetAct SW manager. Initially eNB was running on RL70 P8. An activation of RL60 MP3.0.1 from the passive bank was started. After rollback was completed and eNB restarted itself one of the cells shows alarm 6253 (Cell Configuration Data Distribution Failure) and there is an RP3 alarm on second FXEB. Cell Block/ Unblock, RF module block/unblock operations failed to mitigate the issue. Solution / Workaround: Full site reset. Impact to Operator: Rollback is failure, it might be influence the customer decide if upgrade SW from current SW to RL70 branch. Impact to End-user: Cells are on air after reset eNB.

3.149 FSMF: RF-modules didn't recover after hot remove/insert (BTS reset in between) Problem report: 155531ESPE02 Exists in: LN7.0 Correction Target: FL15A Severity: B - Major Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 130/330 Version 1.0 Confidential


Description: Test scenario: 1. Mains supply disconnection for both radios FRHC(1.0.1.1) and FRHC(1.0.3.1) 2. BTS reset via Site Element Manager. Wait until BTS startup is ready and related alarms are active 3. Mains supply reconnection to both radio modules. Expected behavior is that radio modules are back to working state and related cells are in operational state. According test results after test step 3, connection to radio modules weren't created as expected and therefore radio modules were unreachable and configured cells were not-operational state. Similar test are executed with FSME and Rel2.1 radios too. No problems observed with those tests. Probability: Permanent Solution / Workaround: Additional BTS reset via Site Element Manager will recover situation back to normal. Impact to Operator: Radio modules and related cells are in not-operational state until additional BTS reset is executed.

3.150 FHCA: Cells in chain disabled after unblock if master RF blocked Problem report: 122146ESPE01 Exists in: LN7.0 Correction Target: correction not needed Severity: B - Major Customer Impact: Operation & Maintenance Description: Configuration with FHCA in chain. Block first FHCA in chain and then block other RF unit later in the chain. Unblock second RF later in chain. Cell of second RF in chain will stay "Faulty" after second RF is unblocked. After a while "Configuration error: BTS configuration error (Not enough HW for LCR)(1868)" is raised. Start-up of cells in chain are disabled if preceding FHCA in chain is blocked. Due to "failed" status of FHCA while blocked (critical severity of 1931), in chaining configuration it is not possible to set up cell on RF units located in chain after blocked FHCA. Probability: Permanent Solution / Workaround: If several RF units are unblocked in chain then FHCA units should be unblocked in order starting from the system module end. FHCA should not be blocked before RF units later in the chain have reached operational state. It is not recommended to leave FHCA into blocked state if there are other RF units in chain after FHCA, due to risk of autonomous reset of other RF units that would not be automatically recovered to operational state. Impact to Operator: Cells in chain are out of service if preceding FHCA in chain is blocked.



3.151 After SW upgrade the majority of LTE sites reported the Alarm 7654 increased BER detected on the optical connection to Radio Module Problem report: NA05808722 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: After SW Upgrade the majority of LTE Sites were experiencing the following alarm: Alarm id 7654 (shared:M;Increased BER detected on the optical connection to Radio Module). Proper transport rules are not being applied in the configuration. Root Cause: Current implementation in ConfigH10MhzDescriptor handles only shared FR_111 and FR_121. But in current pronto we have shared FR_121 & FR_131. There is no implementation to support LTE-GSM RF sharing H-type using FR_121 & FR_131. The fault will only arise in LTE-GSM Sharing for H-type configurations using fr121 fr131 instead of fr111 fr121. Correction: Transport rules to support GSM Sharing H-type using fr121 fr131 added. Solution / Workaround: Use H-type configuration fr111 fr121 instead of fr121 fr131. Impact to Operator: No support for LTE-GSM RF sharing H-type using FR_121 & FR_131. Impact to End user: No impact.

3.152 After upgrade 2 sites report Antenna Line Failure 1873 Problem report: NA05804228 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: After SW upgrade Antenna Line Failure 1873 fault was reported. Root cause: BTSOM was attempting to set the gain on a MHA/LNA that did not need its gain to be set, resulting in the MHA/LNA rejecting the attempt and causing an 1873 fault to be raised. Correction: BTSOM has added additional checking to prevent this attempt to set gain from occuring. Specifically, if the LNA minGain and maxGain are identical, or if the requested gain is outside of the range specified by minGain and maxGain, then no attempt to set gain will be made. Non-linear gain values (supported by some MHAs) are now also supported. If the requested gain does not have a correct resolution, then non-linear gain values are checked (if the MAH support non-linear values). If the requested gain matches a supported non-linear value, then gain is set. Solution / Workaround: No workaround. Impact to Operator: After SW upgrade Antenna Line Failure 1873 fault was reported. Impact to End user: No impact. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 132/330 Version 1.0 Confidential


3.153 3 out of 6 cells stayed disabled after SW upgrade from RL60 MP3.0.1 to RL70 P8 Problem report: NA05791730 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: After SW upgrade Out of 6 cells only 3 came on air. No related alarms seen. Cell block/unblock brings the disabled cell OnAir. Site reset fixed remaining 2 cells. Issue seen on 1 out of 8 nodes that was upgraded. Root cause: Race condition between reaction for disabling s1link and carriers activation. Correction: Internal readiness flag for channels should be set when activation request is triggered - not when carriers activation result notification comes. Solution / Workaround: Additional site reset brings all cells OnAir. Impact to Operator: Occasionally after SW upgrade not all cells came on air. No related alarms seen. Impact to End user: No service at affected cells.

3.154 Configuration error: BTS conf error (Not enough HW for LCR) (1868) Problem report: NA05809294 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05809294, NA05809299 Probability: Occasional Description: The fault root cause is related to configuration file processing. When starting up with LN7.0 software and configuration file contains 2 MHA objects with identical productCode and serialNumber, if first has parameter connection=”Internal” and the second is “External” and if data under scannedAntennaInterface parameter doesn’t match those under antlId parameter – CABLNK_A objects were wrongly created. That resulted with errors while mapping hardware objects to their alias objects and after startup alarm 1868 (Not enough HW for LCR) occurred. Solution / Workaround: The solution was repairing bug in the code that was responsible for wrong CABLNK_A creation. Impact to Operator: After update to LN7.0 with configuration described in “Description” field – alarm 1868 will occur and site will be roll backed to previous build. Impact to End user: No impact.



3.155 eNB DPD alarms after software rollback Problem report: NA05799993 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: IPSEC certs are missing when downgrade from RL70 to RL60. Due to this DPD alarm seen. How end user/operator could detect the problem: Install RL70 software in Active partition and RL60 is passive/stb partition. Then configure IPSEC with relevant certs. Trigger downgrade to RL60. Then problem is seen. Description of the fault: During downgrade handling in NMA the cert file backup was not done for LTE, due to which files were not present while RL60 boots up. Faulty component and version: TRSW Solution / Workaround: Workaround: Disable IPSEC. Description of the correction: The code has been removed from WCDMA product type check. Why it was under product check is not known yet. Impact to Operator: BTS will not be operational with IPSEC. Impact to End user: BTS will not be operational due to DPD alarm.

3.156 FBBC stays in configuring state when radio module has incompatible SW Problem report: 60312ESPE05 Exists in: LN7.0 Correction Target: correction not needed Severity: B - Major Customer Impact: Operation & Maintenance Description: BTS is powered on and three FXEB radio modules have incompatible software. After BTS startup two FBBC modules stay in configuring state. Three cells are faulty with Configuration error (Not enough HW for LCR) 1868. When all radio modules have compatible SW - FBBC are configured correctly, BTS is OnAir and cells are enabled. Probability: Permanent Solution / Workaround: Update Radio modules to compatible SW version Impact to Operator: Cells are not onAir if radio modules have incompatible software

3.157 SW upgrade from PP0.1 to PP0.2, site did not come On air Power cycle resolved the issue. Problem report: NA05797625 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.0 Severity: A - Critical LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 134/330 Version 1.0 Confidential


Customer Impact: Operation & Maintenance Attached PRs: NA05797625, NA05812080 Probability: Occasional Description: Description of the problem: SNTP, and Holdover thread register dynamic CPID but don't unregistered it before thread end. How end user/operator could detect the problem: BTS start reporting faults. Description how problem can be detected: If You use e.g. GPS as synchronization source and You plug it out and plug it in few times (wait 30s before plug in) then in aashell (telnet 127.0.0.1 15007) run command cpid -c. You will see that there are some repeated thread names with different cpid. Solution / Workaround: Description of the correction: In holdover thread we unregister cpid before thread ends. Impact to Operator: Bts stop working. Lack of new CPIDs. Impact to End user: Bts stop working. Lack of new CPIDs.

3.158 Rollback to LN7.0 0.2 failed due to alarm 0023 FTLB Problem report: PR049942 Exists in Release: LN7.0 1.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: After rollback to LN7.0 0.2 the alarm 0023 'Incompatible SW version detected' for FTLB is active. All cells are disabled and eNB is in integrated state. Solution / Workaround: Execute SW update for rollback SW again. After that all SW is rolled back and eNB is on-air. Impact to Operator: Extra SW update is needed to get eNB back on-air. Impact to End user: No impact.

3.159 [FSMr3]: Counter M8001C420 needs similar correction as M8001C266 - Buffers status to be checked for each active TTI Problem report: NA05802335 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Incorrect KPI values about UEs with buffered uplink data. Attached PRs: NA05802335, PR046862 Probability: Occasional LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 135/330 Version 1.0 Confidential


Description: Summary of the original problem: KPI statistics provides incorrect values regarded to UEs with buffered uplink data (PM counters M8001C150, M8001C266, M8001C419, M8001C420). How end user/operator could detect the problem: Issue doesn't affect user. Operator has incorrect statistics about UEs with buffered uplink data. Description of the fault: PM counters M8001C150, M8001C419 and M8001C420 are updated only in case of receiving uplink BSRs from UE, but should be updated each TTI even if there is no any UL BSRs. Dependency on configuration: No dependencies. Faulty component and version: eNB: LN7.0_ENB_1407_561_67. BTS SC L2 FB_14_07: 419561 (SVN rev.). Solution / Workaround: No workaround. Description of the correction: PM counter M8001C150, M8001C266, M8001C419, M8001C420 should be updated each TTI. Algorithm of updating should be changed. Impact to Operator: Operator has incorrect statistics about UEs with buffered uplink data (PM counters M8001C150, M8001C266, M8001C419, M8001C420). Impact to End user: No impact.



3.160 Alarm 1868 is active and one cell is in faulty state Problem report: PR034294 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Without correction we can block communication with SFP. Correction fixing Communication with SFP via I2C which has impact on link speed change which has impact on RF bandwidth. Solution / Workaround: HW reboots which is not supported remotely. Impact to Operator: One cell is in faulty state so it is not onAir, so the KPIs will decrease. Impact to End user: There are problems with calls because one cell is not in use (onAir state).

3.161 Failure in replaceable baseband unit on deleting CAREL Problem report: NA05797061 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05797061, PR038511 Probability: Occasional Description: MACPS stopped on an assertion in case a cell identifier didn't match the known cells when distributing messages. An assert is not necessary here, since the effect can easily be mitigated by not sending the message out. Solution / Workaround: Remove the assert, and instead don't send the message. Impact to Operator: No impact Impact to End user: No impact

3.162 During SW upgrade Antenna Line Failure (1836) alarm was observed on multiple sites Problem report: NA05789319 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Antenna Line Failure (1836) alarm was observed on multiple sites. A site reset was performed on each site in order to clear the alarm. No active alarms remained with regards to this issue. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 137/330 Version 1.0 Confidential


Solution / Workaround: Site reset clear the alarms. Impact to Operator: BTS is not onAir - call is dropped. Operator can see Antenna Line Failure (1836) alarm on site. Impact to End user: Dropped call

3.163 Antenna Line Device failure (1873) alarms appear after upgrade LN6.0 3.0 to LN7.0 0.1 Problem report: 128128ESPE04 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: After upgrade to LN7.0 SetGain operation was performed with a mhaGain that was invalid. Solution / Workaround: CellP calls Set Gain operation only if MHA_L::minGain is not equal to MHA_L::maxGain, and if requested gain is between MHA_L::minGain and MHA_L::maxGain Impact to Operator: Fault 1873 is an informational alarm indicating the ALD does not support Set Gain operation. In general, the fault does not impact ALD device. Impact to End user: MHA provides gain and is remains operational.

3.164 DRB Inactivity timer is not restarted by user data carried by Msg3 Problem report: 154601ESPE02 Exists in Release: LN6.0 0.1.2 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: msg3 data is not considered for inactivity timer restart How end user/operator could detect the problem: UE release too early due to inactivity Description of the fault: when temp CRNTI for msg3 delivery of temp UE belongs to different UE group than corresponding permanent UE incorrect UE group is used to retrieve RB context for used LCID. So delivered data is not included to UE buffer status field of MAC_UlBSRInd sent to MAC_PS. This could also lead to the situation when wrong MAC PS instance is used to send BSR to. Related feature / functionality: UL data of UE in Out-of-Sync state Solution / Workaround: No workaround Description of the correction: ueGroup of permanent UE is used to retrieve RB context for used LCID in msg3. Also this correct ueGroup is used to determine MAC_PS instance to send BSR to. The only risk is that in this case L2 have to forward UE buffer status info accumulated from received msg3 to RlcCoreUl of another UE group. It will cause the delay in processing the UE buffer status report and in LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 138/330 Version 1.0 Confidential


case of several UEs scheduled to current TTI it could result in several MAC_UlBSRInd msg will be send to MAC_PS unbundled for current TTI. This is a specific case and should not be a problem for MAC_PS since it could cause just small overload. Impact to Operator: UE is not released too early. Impact to End user: UE is not released too early.

3.165 Handover trace report isn't traced in encoded ASN1 format Problem report: 60033ESPE05 Exists in Release: LN6.0 Correction Target: RL70 C5 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: EnbcX2HandoverReport was traced not-ASN1 encoded. Solution / Workaround: Description of the correction (incl. risk analysis): Change the traced buffer to encode. Impact to Operator: Operator (Trace Collection Entity tool) will receive malformed (garbage) data in Trace Record instead of ASN1 payload of X2AP:HandoverReport. Impact to End user: No impact to user experience.

3.166 In Fault Management window the active alarms table list shows blank, and it shows the “CORBA BAD_PARAM” error prompt after closed the window. Problem report: 127993ESPE04 Exists in: RL70_OMS Correction Target: OMS RL70 1.0 Severity: B-major Probability: Occasional Customer Impact: Operation & Maintenance Description: In Fault Management window the active alarms table list shows blank, and it shows the “CORBA BAD_PARAM” error prompt after closed the window. Solution / Workaround: Improved trace logging for logger library to remove log flooding. No workaround. Impact to Operator: Operator is unable to see active alarms in FM GUI. Impact to End User: No impact.

3.167 BtsAddressList.txt file doesn't contain information about connected MRBTS Problem report: 128240ESPE04 Exists in: RL70_OMS Correction Target: OMS RL70 1.0 Severity: B-major Probability: Occasional LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 139/330 Version 1.0 Confidential


Customer Impact: Operation & Maintenance Description: BtsAddressList.txt file is not updated in OMS since there is no checking whether such file needs to be updated or not. Solution / Workaround: Added updating of the flag that decides whether BtsAddressList.txt file requires updating. No workaround. Impact to Operator: Operator will notice that BtsAddressList.txt file will not contain information about connected MRBTS. Impact to End User: No impact.

3.168 MRBTS FZC rollback fails. Problem report: PR040065 Exists in: RL70_OMS Correction Target: OMS RL70 1.0 Severity: C-minor Probability: Permanent Customer Impact: Operation & Maintenance Description: FZC SW Rollback shows fail in NEtAct even though eNB successfully sent SWRollbackReply with OK status. Solution / Workaround: Provide queue for SWRollbackReply messages. No workaround. Impact to Operator: SW Rollback will fail in NetAct. Impact to End User: No impact.

3.169 Duplicate measurement entry in NBI LTE xml files on the same period. Problem report: NA05730385 Exists in: RL60_OMS Correction Target: OMS RL70 1.0 Severity: A-critical Probability: Permanent Customer Impact: Operation & Maintenance Description: NE was sending twice a particular measurement file to OMS. This was not detected as duplicates in OMS because of the difference in the directory path. Solution / Workaround: The directory path is removed when comparing two duplicate files. No workaround. Impact to Operator: Duplicate entries will be found on two OMS files. Impact to End User: No impact.

3.170 BackupReply message was displayed instead of RestoreReply during remote restore Problem report: 122675ESPE01 Exists in: RL60_OMS Correction Target: OMS RL70 P8 Severity: C-minor LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 140/330 Version 1.0 Confidential


Probability: Permanent Customer Impact: Operation & Maintenance Description: RL60 BackupReply message was displayed instead of RestoreReply during remote restore operation. Solution / Workaround: Change the display of "RestoreReply" to correct one which is "RestoreReply ". No workaround. Impact to Operator: Operator will have some confusion on the display for "RestoreReply" upon checking the logs.

Impact to End User: No impact.

3.171 Alarm 1868 is active and one cell is in faulty state Problem report: PR034294 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Without correction we can block communication with SFP. Correction fixing Communication with SFP via I2C which has impact on link speed change which has impact on RF bandwidth. Solution / Workaround: HW reboots which is not supported remotely. Impact to Operator: One cell is in faulty state so it is not onAir, so the KPIs will decrease. Impact to End user: There are problems with calls because one cell is not in use (onAir state).

3.172 Failure in replaceable baseband unit on deleting CAREL Problem report: NA05797061 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05797061, PR038511 Probability: Occasional Description: MACPS stopped on an assertion in case a cell identifier didn't match the known cells when distributing messages. An assert is not necessary here, since the effect can easily be mitigated by not sending the message out. Solution / Workaround: Remove the assert, and instead don't send the message. Impact to Operator: No impact Impact to End user: No impact



3.173 FXCC: RF Diagnostic VSWR value randomly wrongly displayed Problem report: 155014ESPE02 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: New feature/functionality Description: Automated test repeated many times: 1. Initiate RF diagnostic test o Download current SCF file from eNB via FTP; o Set initiateTest parameter to true; o Execute commissioning from this file via BTSSM CLI. 2. Verify RF diagnostic results o Download current SCF file from eNB via FTP again; o Search file for test results. Randomly VSWR test result value is displayed as 0.0 (while minimum value of VSWR is 1) Sometimes RF Diagnostic measurement results are displayed correctly for both cells, sometimes displayed VSWR value is 0.0 or results are duplicated. There was observed no dependency and this faulty behavior seems random. Test scenario was run on 200 times on different software versions on this site configuration and each time 20%-25% of measurements showed 0.0 VSWR value. Those failed runs occurred randomly. Each run took 4-5 minutes. Used Configuration: FSMF + two FXCC Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: RF Diagnostic VSWR value randomly wrongly displayed as 0.0.

3.174 [FSMr2][2G-LTE RF Sharing] Rollback fails from RL70 0.1 to RL70 P8 Problem report: PR038774 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR038774, PR041612, PR043179 Probability: Permanent Description: OM.0710 - RF Sharing - SW Upgrade for an RF sharing setup 1. Upgrade from RL70 P8 (LN7.0_ENB_1407_555_05) to RL70 0.1 (LN7.0_ENB_1407_556_54) on a 2GLTE RF sharing site. 2. Rollback to passive SW is performed. After successful SW upgrade, rollback fails with a message: Rollback failed Reason: Passive SW inconsistency Solution / Workaround: Perform a software update to SW located on passive partition (by choosing LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 142/330 Version 1.0 Confidential


TargetBD or .zip and clicking Update button, not by using "Rollback to Passive SW"), similar like in RL60. Impact to Operator: Time can be wasted by performing failing rollbacks. If Operator will not be informed about workaround, they may not be able to revert to passive SW. Impact to End user: No impact

3.175 LTE RL70 FZM BTS Status LED Indication wrong Problem report: NA05803299 Exists in Release: LNF7.0 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: Currently FZM RL70 implementation won't provide a clear indication via status LED as to when the autoconnection is completed and when the autoconfiguration starts. Solution / Workaround: The installer will have to use the BTSSM GUI. Impact to Operator: The installers cannot just depend on the status LED to determine the installation state. Impact to End user: No impact

3.176 Major Upgrade to iOMS7.0 fails if disk size is larger than 147GB Problem report: 155172ESPE02 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: MSU upgrade failed due to “Failed writing received data to disk/application” It will happen if iOMS was upgraded to RL60 from RL50 via Major Software Upgrade & HDD is larger than 147 GB

Probability: Permanent Solution / Workaround: Before performing Major Software Upgrade either local or remote operation and if iOMS was upgraded to RL60 from RL50 via Major Software Upgrade & HDD is larger than 147 GB, then the following should be performed 1.Execute the script included to the RL70 Release Note to iOMS machine. Note: File permission needs to be updated to executable when executing the workaround in iOMS machine. 2. Perform Major Software Upgrade one more time. Impact to Operator: MSU can't be remotely installed when upgrade partition is missing Impact to End user: No impact

3.177 After upgrading, the values of maxNumRrcEmergency and maxNumRrc have been set to zero with FSME Problem report: 122554ESPE01 Exists in Release: LN7.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 143/330 Version 1.0 Confidential


Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: 122554ESPE01, 123091ESPE01, NA05798795 Probability: Permanent Description: Summary of the original problem: During SW upgrade from RL70 P8 (555_05) to RL70 PP02 (557_36), parameter actCompChecks is changed to false. How end user/operator could detect the problem: In normal operation after all RAN parameters are set correctly according to the configuration rules of RL70, actCompChecks should be set to TRUE by operator. Upgrade from RL60 to RL70 will set actCompChecks=false automatically to ensure a smooth upgrade because some configuration rules had been changed (refer to release note, section 8.1.2 RL70 PUCCH Dimensioning Change). After this one-time correction, actCompChecks should stay TRUE and not be modified by SW upgrade within RL70 anymore. Solution / Workaround: Workaround: Set actCompChecks=true after SW upgrade, no eNB reset necessary. Description of the correction (incl. risk analysis): Adapt conversion rules to ensure that actCompChecks=false is set only in case source SW build is before RL70 P8 Impact to Operator: Recommissioning required to set actCompChecks=true to enable consistency checks again after SW upgrade. Impact to End user: No impact

3.178 RET stays configuring state after upgrade to LN7.0 Problem report: 128127ESPE04 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: 128127ESPE04, NA05794292, PR038354 Probability: Permanent Description: SW upgrade from LN6.0 1.1.2 to RL70. After the upgrade RET stays configuring state with error code 'Read Only Parameter, Execution failed'. RET configuring is never completed. Dependency on configuration: FSMF, 2xFRIE, 6xMHA, 5xRET (Kathrein) configuration: L111-H-32-2TX-2RX, BW: 10MHz. Solution / Workaround: Calibrate RET, after that RET is working and symbol green. Impact to Operator: RET stays configuring state after upgrade to RL70. Impact to End user: No impact



3.179 BTS In commissioned state / after site reset back onAir Problem report: NA05799262 Exists in Release: LN70 0.2 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05799262, NA05799439, 155676ESPE02 Probability: Permanent Description: Summary of the original problem: After power reset, when NTP become InSync MainSync thread save TuningHistory.log to flash. It takes too much time, and Sync can't response in time to TimeS. This cause the problem with set common BCN. How end user/operator could detect the problem: No network service. Description of the fault: After power reset, when NTP become InSync MainSync thread save TuningHistory.log to flash. It takes too much time, and Sync can't response in time to TimeS. This cause the problem with set common BCN. Related feature / functionality: Set common BCN, Holdover preparations file writing. Solution / Workaround: Workaround: Restart eNB Description of the correction (incl. risk analysis): Every TuningHistory.log saving to flash was moved to separate thread. Impact to Operator: No network service Impact to End user: No network service

3.180 Plan validation failed (parameter actRemoteRfDiag is missing) during auto configuration with Netact 15.2 after RL50 to RL70 SW upgrade for FZM Small cell Problem report: PR034447 Exists in Release: LNF5.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: Plan validation failed (parameter actRemoteRfDiag is missing) during auto configuration with Netact 15.2 after RL50 to RL70 SW upgrade for FZM Small cell How end user/operator could detect the problem: Plan validation failure can be seen in the Netact during Auto configuration process. Description of the fault: Un-commissioned FZM is using a wrong MRBTS version(LNFZ5.0) in the configurationChangeNotification and connectionEstablishedIndication messages, It will cause the plan validation fail in Netact. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 145/330 Version 1.0 Confidential


Solution / Workaround: Don't use the auto configuration feature to deploy RL70 FZM or make sure that FZM is already RL70 level before using the auto configuration feature. Impact to Operator: FZM stays un-commissioned state and out of service after the auto configuration procedure failed.

3.181 LMT port access doesn't get disabled even after setting lmtport parameter to "None" in a FZM with Integrated WiFi Problem report: PR034907 Exists in Release: LNF7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: LMT port access doesn't get disabled even after setting lmtport parameter to "None" in a FZM with Integrated WiFi. In order to put the configuration change into effect and disable LMT port FZM needs to be reset. Solution / Workaround: Perform additional FZM reset after initial commissioning in which lmtport is set to null. Impact to Operator: Additional reset is required. Operator may also be unaware that LMT access is enabled while they think it's not (at least until next site reset). Impact to End user: No impact

3.182 Fault 475 lead abnormal cell deletion Problem report: NA05784171 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Source UEC tried to do InterEnbX2 Handover of UE. At the beginning of HO Source Execution faze UEC sent GtpRouteEstablish request message to TRSW and it waits for response. At this time UEC received Cell Delete Request. It tried to abort itself, but first it wanted to handle GtpRouteEstablish response from TRSW. Unfortunately, when it received response from TRSW, it hanged and did not trigger UE Release procedure. So it blocked cell delete procedure. In the meantime, RROM timer for cell delete procedure expired, faults were raised and cell was tried to setup (which ended with failure, because cell was not deleted yet). Two minutes later, UEC noticed that we have hanging resources and forced UE services and Cell services to finish When handover service was waiting for data forwarding response from TRSW, it received cell delete request Solution / Workaround: Description of the correction: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 146/330 Version 1.0 Confidential


Uec Source Handover Service handles properly Cell Delete Request while it's waiting for GtpRouteEstablish response. Impact to Operator: Cell is not available. Impact to End user: Services are not available in the problematic cell.

3.183 Site upgrade RL70 vs RL70 failed with fault Configuration error Not enought HW Problem report: NA05802927 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Occasional Description: Description of the problem checkIfMhaIsConnectedToOtherRmod method used wrong object: cablnk instead of mha Solution / Workaround: In considered method mha object used for check instead of cablnk Impact to Operator: Some of the cells are Out of order Impact to End user: No service from the cells that are Out of order

3.184 FlexiZone eNB send RDN sequence in different order causing automatic cert retrieval failure Problem report: NA05791738 Exists in Release: LNF5.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: KUR procedure will fail if customer has CA subject name configured globally for all eNBs in reverse order (compared to BTS certificate order) i.e. commonName, organizationName, countryName. In RL50, FlexiZone does not use the value of CA subject name configured by operator therefore Rdnsequence is always of fixed order as read from BTS CA certificate. Solution / Workaround: The solution is to construct Rdn sequence in the order present in CA subject name if it was configured by operator. If not configured, use CA subject name from BTS CA certificate. For workaround, configure CA subject name for FlexiZone eNBs in the following order as in BTS CA certificate: countryName, organizationName, commonName Impact to Operator: Certificate retrieval from CMP/CA server will fail. Impact to End user: No impact.



3.185 BTSOM PM stats collection issues during leap second adjustment Problem report: PR038034 Exists in Release: LNF7.0 Correction Target: correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: Summary of the original problem: The following applies to RL70 (FDD) Micro and RL55 (TDD) Micro: when the GPS and/or Timing over Packet (ToP) is configured the operator will see an additional PM statistic file in the Site Manager approximately midnight of June 30, 2015. In addition, the Site Manager will not show the PM Statistic for 23:45 interval. The following applies to RL70 (FDD) Micro: when NTP is configured, the operator will see an additional PM statistic file in the Site Manager approximately midnight of June 30, 2015. In addition, the Site Manager will have 60 seconds missing from 23:45 PM Statistics 15 minute interval. PM Statistics should not have issues related to the above after midnight of June 30, 2015. Solution / Workaround: PM Statistics should not have issues related to the above after midnight of June 30, 2015. Impact to Operator: BTS PM data for intervals just around leap second adjustment may not be accurate.

3.186 [FSMr2] Unexpected fault 1807 Configuration error: Invalid frequency channel for one cell after SW update Problem report: PR042664 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Iframe responses from ALDs are out of sequence which leads to almag incorrectly processes response data. Solution / Workaround: Description of the correction: - change retransmission timeout value to 1 second - validate sequence number in responses from ALDs. From HDLC spec: 5.6.2 N(S) sequence error An N(S) sequence error exception condition shall occur in the receiver when an I frame received error free (no FCS error) contains an N(S) that is not equal to the receive state variable at the receiver. The receiver shall not acknowledge (i.e., not increment its receive state variable) the frame causing the sequence error or any I frames which may follow until an I frame with the correct N(S) is received. Unless the SREJ frame is to be used to recover from a given sequence error, the information field of all I frames received whose N(S) does not equal the receive state variable shall be discarded. (See 5.6.2.3 for SREJ recovery.) LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 148/330 Version 1.0 Confidential


Impact to Operator: One or more cells with commissioned MHAs may be set to faulty state with unexpected alarm (fault 1807) during cell setup phase (startup). Impact to End user: Lack of service from the affected cells (not possible to attach).

3.187 EE SRAN Testbed: New LTE MHA Parameters cause "Parameter error" after CM Plan Upload Problem report: NA05784404 Exists in Release: LN6.0 3.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: NetAct CM Operation manager cannot upload adjustable gain MHA parameters of eNB SCF from eNode B. Parameters are: gainResolution, maxGain and minGain. Their values are empty in upload log. They are as decimal values in the SCF and they should be as integer. Decimal values are not expected to be present in the NetAct CM UL file. In the example above mhaGain is having correct value (1200 = 12.0 in the UI) but maxGain should be ‘1600’ instead of ’16.00’. Solution / Workaround: N/A Impact to Operator: MHA-Max Gain, MHA-Min Gain and MHA-Gain Resolution values are not available in the NetAct CM. Impact to End user: No impact

3.188 Unnecessary alarm (1816) after upgrade eNB from LN6.0 to LN 7.0 Problem report: PR036628 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: PR036628, PR040150 Probability: Permanent Description: After upgrade from LN6.0 x.x eNB SW to LN7.0 x.x eNB SW. Unnecessary alarm id 1816 will be visible on short time. Alarm is active only with REL2 system module. Solution / Workaround: No workaround Impact to Operator: Unwanted alarm will be visible on short time. Impact to End user: No impact.

3.189 Alarm 71122 CRL UPDATE FAILURE after iOMS upgrade to LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 149/330 Version 1.0 Confidential


R_GOMS7_1.3.2.0.corr27 Problem report: NA05784977 Exists in Release: RL70_OMS Correction Target: OMS RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Description : Alarm "71122 CRL UPDATE FAILURE" raised even though CRL checking feature is disabled Solution / Workaround: Solution / Workaround : Adding to platform SS_CertMan API function that can provide information if CRL checking feature is disabled/enabled Impact to Operator: This error will raise an alarm but it can be ignored because it has no impact to OMS functionalities. Impact to End user: End users see alarm that shouldn't be raised.

3.190 RL70 - RET Settings under Antenna Menu in BTSSM shows RETs as “not commissioned” after successful RET detection and configuration. Problem report: PR037628 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: RET Settings under Antenna Menu in BTSSM shows RETs as “not commissioned” after successful RET detection and configuration. Solution / Workaround: Impact to Operator: RET Settings not reflecting right status Impact to End user: N/A

3.191 RTWP counters scaled per PRB should be per total bandwidth Problem report: NA05786747 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Probability: Permanent Description: Summary of the original problem: Values reported for Wideband power per antenna shows too low values (under noise level). The bigger LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 150/330 Version 1.0 Confidential


bandwidth the lower reported value. Values didn't match wideband power but look like power per single PRB. How end user/operator could detect the problem: Comparing reported RTWP Measurements per antenna with other measurements (like ie. noise level). Description of the fault: Wrong interpretation of interface which provides power measurements, reported values from PHY layer are already scaled per PUSCH PRBs so the wider band - the bigger difference. Dependency on configuration: None but size of inaccuracy is proportional to current system bandwidth Faulty component and version: LTE MAC PS, RL70 Faulty component first delivered in(e.g. release, CD): fb14.07 Solution / Workaround: Correct reported values by number of PRBs for given bandwidth Description of the correction: apply multiplication of received power measurements by number of used PUSCH PRBs (available in same message) Impact to Operator: None reliable counter values (AVG RTWP per antenna) Impact to End user: No impact

3.192 eNB autonomous reset after RET comissioning Problem report: PR038973 Exists in Release: LN7.0 0.1 Correction Target: open Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Issue occurs only when Symptom Data Trigger on "Radio Network Configuration" page in Commissioning, is set for Fault ID: 3070. It was discovered, after request from Prescreening phase, to switch off snapshot generating, to disable logging freeze. After removing such Symptom Data Trigger, issue did not occur. Solution / Workaround: Solution: Provide a correction for this issue. This trigger should not cause autonomous resets. Workaround: Remove Symptom Data Trigger set on Fault ID: 3070 .Without this Symptom Data Trigger, issue does not occur. Impact to Operator: Reset of whole eNB - in operational during this time. Impact to End user: No connection with eNB. No service

3.193 LN7.0 0.1 Failure in RP3 interface (2001) after site reset



Problem report: PR039210 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: After site reset the alarm failure in RP3 interface (2001) is visible and one FRLB radio module (connected to FBBC card) is not detected. Case is occasional 4/100. Solution / Workaround: Problem disappears after next site reset. Impact to Operator: One radio module is not detected and the cell connected this radio module is in faulty state. KPIs decreases. Impact to End user: Cell is not in use because it is in faulty state.

3.194 LTE Conf6 only Cell51 at 15Mhz and other at 10 Mhz, report fault 1958 not described Problem report: NA05786739 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: N/A Probability: Permanent Description: [NPI RL70 VF-IT]- LTE Conf6 only Cell51 at 15Mhz and other at 10 Mhz, report fault 1958 not described Solution / Workaround: Link in fault 3010 to fault 1958 and in other direction for LN7.0, FL15A, FL16 was added. Impact to Operator: N/A Impact to End user: N/A

3.195 After RL70FZ upgrade netmask of remote network in each IPsec policies is missing Problem report: NA05785573 Exists in Release: LNF7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: During upgrade from RL50FZ to RL70FZ, remote netmask parameter in IPSECC managed object is not transformed to RLF70 parameter remoteIpPrefixlength. As a consequence, in case there was a specific network configured as remote network in bypass or protect policies, it will be treated as ANY after upgrade (0.0.0.0/0). LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 152/330 Version 1.0 Confidential


Solution / Workaround: Please insert manually remote network mask in each IPsec policies after upgrade to RL70FZ. Impact to Operator: Depending on actual IPsec configuration in RL50FZ there is a probability of: loosing connectivity with smallcell after upgrade to RL70 - small cell being not operational after upgrade to RL70 Impact to End user: SmallCell not operational after upgrade.

3.196 NWI3 status inconsistency to FAILURE Problem report: NA05780309 Exists in Release: RL70_OMS Correction Target: iOMS RL70 1.0 Severity: A – Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: OMS cannot push NE events to NetAct. Solution / Workaround: Restart Nwi3Adapter on OMS by executing the command: fshascli -rn /Nwi3Adapter Impact to Operator: Operator is not notified with events coming from NE. Impact to End user: No impact

3.197 RL70 FZM restarts repeatedly every 4 min after SW uploading at test BTS Problem report: NA05789865 Correction Target: RL70 1.0 Severity: B-Major Customer Impact: The BTS unit continuously reboots, and does not come on air. Description: The EFaultId_SynchronizationAl alarm may be raised after board reboot or software upgrade. On some units we can observe roiling reboot because this issue will by repeated until calibration file will be removed. BM drops sync after it starts using the calibration file and switches from ocxo to another time source in frequency mode. It goes back to sync state after pll reset. How the problem can be detected:

-

Check if BM works in frequency mode and has valid calibration file. o How to check if BM works in frequency mode:  After BM start, run following command: `syncappmmi status | grep "Mode:"` ‐ you should see "Mode: frequency" (problem concerns only frequency mode) o How to check valid calibration file is available:  Run command: `syncappmmi status | grep ‐A 3 "Calibration:"` ‐ if you see for e.g. "Auto: 290911, done: 2015‐05‐06 11:55:05, remaining 29d01:43:06" with remaining



time greater than 0 it means that this calibration file will be used after reboot (of course within the limits of remaining time). The scenario of this issue is as follows:

-

-

-

-

board reboot or sw upgrade BM starts using calibration file, get sync after max 2 seconds in frequency mode. o Running `cat /tmp/syncapp‐info.log | grep "sync manager now synced"`  You should see e.g : "2015‐05‐07T07:24:44.342 [INFO ] sync.manager ‐ sync manager now synced, was unsynced for 00:00:01" BM switch to active synchronisation source (GNSS, ToP, SyncE) o Running `cat /tmp/syncapp‐info.log | grep "switching from source ocxo"`  You should see e.g : "2015‐05‐07T07:25:28.340 [INFO ] sync.manager ‐ sync manager switching from source ocxo (used for 00:00:45) to GNSS"  starting from this moment control value reached min or max limit (0x1D00000 = 30408704) o Running `cat /tmp/syncapp‐all.log | grep "30408704"`  You should see a lot of lines like this:  "2015‐04‐08T06:10:51.548 [DEBUG] ocxo pll: mode 2, source GNSS, control 30408704, error 38, tolerance 0, cap 500, good_thresh 20, bad_thresh 180, count 0, target 90, i 587259942, ip 512, iq 16, stability good_min, run ok, jump no" After dozens seconds phase error reached max value and sync was dropped because of frequency was not good. o Running `cat syncapp‐all.log | grep "UNSYNCED"`  You should see e.q : "2015‐04‐08T06:12:23.000 [ERROR] sync manager now UNSYNCED because frequency not good, was synced for 00:01:42" Other components can raise synchronisation alarms which may cause the board to reboot. If all steps above was visible it means that is described issue.

Probability: Permanent Workaround: Remove the /rom/etc/syncapp-cal.dat file before each reboot or sw upgrade (by SM). Impact to operator: There will be no service from this BTS while it is rebooting.

3.198 BTS not commissioned due to unnecessary rtwp result range check in LTE1634 Problem report: PR041796 Exists in Release: RL70_OMS Correction Target: iOMS RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: RL70 (correction 29) added a new method of performing rollback which is not compatible with method used to upgrade to RL70 iOMS. Solution / Workaround: Correction reverts previous functionality using post installation note. Impact to Operator: OMS is not usable after rollback LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 154/330 Version 1.0 Confidential


Impact to End user: impact unknown to mobile users

3.199 Security mode failure when initiating service req for R11 UE

Problem report: 144200ESPE02 Exists in Release: LN6.0 Correction Target: RL60 3.1 Severity: B - Major Customer Impact: Attached PRs: 113520ESPE01, 144200ESPE02, 53221ESPE05 Probability: Description: Issue observed is that during attach, security algorithm setting was fixed for R11 UE, instead of setting it based on context information. Hence, during service request or handover, the operation will failed due to security mode failure as the algorithm will mismatch. Solution / Workaround: Solution provided is to set security algorithm setting based on setting received in the UE context. Impact to Operator: From operator perspective, quality of the service will degrade as some customer (using R11 UEs) will not be able to get the service or will expereicne issues. Impact to End user: From end-user perspective, the connection will be unstable as user will expericence dropped connection when trying those operations (service req, handover etc).

3.200 Periodical fault 'TX Failure in MIMO (4003)' and 'Failure in optical RP3 interface (0010)' for all cells at FXCB 1.3.1 in FSMr3 Problem report: 123244ESPE01 Exists in Release: LN7.0 Correction Target: Correction not needed Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: 123244ESPE01, 127148ESPE04, 127942ESPE04, 154465ESPE02, 60472ESPE05 Probability: Permanent Description: Both Alarms 'TX Failure in MIMO (4003)' and 'Failure in optical RP3 interface (0010)' are raised every 6 hours and cleared again 1-2 minutes later for all cells configured at affected radio module. Even a manual power off reboot of affected radio module does not interrupt the 6 hour cycle. After a eNB reboot, the 6 hour period is still there, starting with reboot time. eNB configuration: LN7.0_ENB_1407_554_35 FSMr3 + FBBC 2x FXEB 2x FXCB Solution / Workaround: No workaround Impact to Operator: Affected cells are degraded every 6 hours for up to 2 minutes. Impact to End user: No impact



3.201 1841 doesn't clear during RF module Unblock Problem report: 155365ESPE02 Exists in Release: LN70 Correction Target: RL70 0.1 Severity: C - Minor Customer Impact: Attached PRs: Probability: Occasional Description: Fault 1841 which indicated a failure in radio module’s FF unit was not cleared after the reset of the radio module. How end user/operator could detect the problem: End user was not able to clear the FF unit’s faults by using procedures which included radio module’s reset. In this case block/unblock. Description of the fault: Fault state was stored in RUMAG’s local map and was able to endure the radio module’s reset. The map was not cleared during the reset procedure. Related feature / functionality: RUMAG area. Dependency on configuration: Configurations that include radio modules handled by RUMAG Solution / Workaround: Description of the correction (incl. risk analysis): Clearing of local FF map was implemented. Impact to Operator: Alarm (Fault 1841) is visible after RF block/unblock Impact to End user: No impact

3.202 Neighborhood relations objects are not reappearing after deletion and activation of UE based ANR Problem report: 155373ESPE02 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: 155373ESPE02, NA05774642 Probability: Permanent Description: After reconfiguration with deletion of all LNADJ, LNREL, LNADJL objects and activation of UE based ANR, there aren't any of thes objects created in Netact/BTSSM view. Despite of that KPI are high and everything happens as it were detected. After restart there is also no objects, but thery are created when neighbourhood is detected. Root Cause: RNW queue was locked when invalid RNW is processed. Solution: RNW queue unlocked when processing invalid RNW. Solution / Workaround: No Workaround Impact to Operator: Neighborhood relations objects are not visible in Netact/BTSSM view. Impact to End user: No impact



3.203 LNF7.0 LNF7.0_ENB_1407_135_06 Corrupted IQ on the TxDiv RF branch, Main branch is OK. Problem report: 123576ESPE01 Exists in Release: LNF7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: HW I&V team reported lower than expected throughput (half) on FWGB radio with new C4C14600 FPGA image release. Simultaneously, RF Software team noticed with FWGB radio using C4C14600 FPGA image that PA operating voltage was below expected operational range. FPGA team investigated issue and discovered that FPGA's GPS LNA Enable output pin was undriven with the C5C24900/CXC14600 image releases. This output pin affected the PA operating voltage which in turn degraded the TX/Downlink performance of the radio. Solution / Workaround: The workaround is to reboot the site until the downlink udp data is back to full rate. Usually 1 reboot fixes it, occasionally multiple reboots are needed. Impact to Operator: After any planned or unplanned reboot of the site, there is a risk it will have half the downlink data throughput when it comes back up. x Impact to End user: Possible low throughput on downlink data. See above operator impact.

3.204 Unnecessary double reset during upgrade from RL50 to RL70 Problem report: 156013ESPE02 Exists in Release: LNF7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Additional reset occurs when doing upgrade from RL50 to RL70 sw build due to changed implementation of u-boot in RL70. Solution / Workaround: Additional couples of minutes are needed to upgrade to RL70 from RL50 due to unnecessary reboot happening. Estimated time to be added is around 3-4 minutes. Impact to Operator: There are two reboots after update from RL50 build to RL70 build Impact to End user: No impact

3.205 FRIG RF modules connected to FBBC are not detected



Problem report: 127781ESPE04 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: 127781ESPE04, 155300ESPE02, 155389ESPE02, 60415ESPE05 Probability: Permanent Description: Test scenario 1. BTS in onAir state witch LN7.0_ENB_1407_554_03 - OK 2. Configuration: FSMF+FBBA+FBBC with 4xFRIG, cell 4 FRIG is connected to FBBC - OK 3. SW upgraded to LN7.0_ENB_1407_554_21 - OK 4. BTS should be in onAir state on all cells - NOK 5. Only 3 cells go onAir, the fourth cell connected to FBBC is not detected Fault Description: There is an RP3 alarm for the RF module connected to FBBC since it is not detected. FRIG RF module connected to the port 3 of the FBBC is disabled and cannot be detected. Solution / Workaround: No Workaround Impact to Operator: Radios connected to FBBC can't be detected. Impact to End user: No impact

3.206 RF module failure with fault code 1841

Problem report: NA05760003 Exists in Release: RL60 1.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Attached PRs: Probability: Description: Customer has seen a lot of RF module failure with fault code 1841 in many sites and getting fix by RFM block/unblock. Root cause: Fault 1841 does not have autonomous recovery. Solution: Added recovery radio reset action without filtering time triggered by LTE BTSOAM when fault 1841 is reported by RFSW. Solution / Workaround: RF failure fixed by RFM block/unblock. Solution: Added recovery radio reset action without filtering time triggered by LTE BTSOAM when fault 1841 is reported by RFSW Impact to Operator: Recovery reset on RMOD, possible short break in radio service for G type and similar configuration, Tx MIMO loss for H type and similar configuration Impact to End user: Possible short break in service, short TP degradation LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 158/330 Version 1.0 Confidential


3.207 Emergency bypass exit not working Problem report: NA05769984 Exists in Release: LN6.0 2.0 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Description: After emergency bypass was activated (no IPsec tunnel between eNB and security gateway in use), we wanted to test the function to exit the emergency bypass state and trigger reestablishment of IPsec tunnel. For this, we created a plan in CM Editor, which was to set the parameter ipSecEmBypassExit in the IPSECC managed object to value 0 - exit. When this plan was activated, the relevant parameter was sent to eNodeB, but plan execution failed with several error messages after a number of retries. We collected Wireshark traces and noticed that the eNB started attempt to set up the IPsec tunnel immediately after it received the changed parameter value. The eNB did not complete the ongoing transaction with NetAct (plan activation) because it immediately attempted to set up an IPsec tunnel. Expected behaviour would be: The eNodeB completes the transaction with NetAct (over the IPsec bypass connection) and only after (successful) completion starts to switch from ipSecEmBypassState to IPsec state. This would avoid that plan activation at NetAct ends with numerous error messages. The situation will be even worse, if the operator creates a bulk plan to exit the emergency bypass state for larger numbers of network elements, which will fail for all network elements with corresponding high number of error messages. Solution / Workaround: No Workaround Impact to Operator: Emergency bypass exit not working. Impact to End user: N/A

3.208 VoLTE mute after HO from Samsung eNB with AM to Nokia eNB with RoHC Problem report: NA05777228 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Attached PRs: Probability: Permanent Description: Summary of the original problem: Voice call was muted after handover Description of the fault: ROHC was wrongly setup Dependency on configuration: Source ENB must have configured a QCI1 profile on rlc mode AM and ROHC must be enabled on target ENB . eNB seems not supporting S1 HO from AM mode VoLTE call with RoHC activation. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 159/330 Version 1.0 Confidential


because Nokia eNB doesn't contain RoHC information in HO request ack message in case of RoHC activation. Solution / Workaround: Disable ROHC Impact to Operator: VoLTE muted after HO with RoHC Impact to End user: End user does not hear the partner anymore

3.209 GTP-U alarms against all TEF SGWs after plan activation Problem report: NA05777398 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05769357, NA05777398 Probability: Occasional Description: Summary of the original problem: The masterTUPUSICAD was not getting changed for 2 operators. How end user/operator could detect the problem: If RAN sharing is enabled then mastertupusicad cannot be configured. Calls were getting dropped. GTP path failure indication alarm was raised. Description of the fault: In TRSWConfig there was a comparison between the current tupusicad and the tupusicad that was retrieved from the path configuration request. Related feature / functionality: TRSWCOnfig functionality. Description of the correction (incl. risk analysis): The TUPUSICAD is stored in a map, per operator. The current and received tupusicads are compared based on the uplane ip received in request message. Solution / Workaround: None Impact to Operator: If RAN sharing is enabled then mastertupusicad cannot be configured. Calls were getting dropped. GTP path failure indication alarm was raised. Impact to End user: Calls were getting dropped.

3.210 RL70: release original aperiodic configuration missing during HO between 3Mhz and 1.4 Mhz cells Problem report: PR039943 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0, RL60 3.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 160/330 Version 1.0 Confidential


Probability: Description: Release aperiodic configuration missing at HO to 1.4 Mhz. 3Mhz cell was configured aperiodic cqi report enabled but 1.4 Mhz cells doesn't support aperiodic cqi report. When UE HO from 3Mhz to 1.4 Mhz, HO failed, UE sent rrc-reestablishment to eNB instead of HO complete message. UE supposed to receive releasig the old aperiodic cqi configuration too during the HO for this case. Solution / Workaround: No workaround Impact to Operator: All Handover into a 1.4MHz cell will fail, if it is R10 UE and if source cell is different than 1.4MHz and aperiodic CQI reporting is enabled (O&M) in the source cell. HO failure leads to RRC Connection Reestablishment. Impact to End user: Short interruptions in voice and streaming services

3.211 Fragmented IPv4 Ping requests and replies going out of TRS cannot be decrypted at security gateway Problem report: PR035248 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B-Major Customer Impact: Security Description: Configuring IPv4 TRS address and collapsing it to a specific FzM Application IP, while setting MTU of the TRS as 1000. Ping to the FzM Application from a remote peer. Response packets are dropped. When trying to ping to FZM Application IPs over IPSec (and with uplink fragmentation is necessary) from remote peer to check the connectivity, no response will be received at remote peer. FZM while replying to ping request will perform post fragmentation and send the packets out when fragmentation in uplink is required. These packets are not getting decrypted properly at security gateway and hence dropped at security gateway. Probability: Permanent Workaround: No workaround Impact to operator: Ping tests from remote peer might fail with IPSec ON and uplink fragmentation required.

3.212 Incorrect LED color display for alarm 4141 and 4142 Problem report: 59403ESPE05 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Initiate the 4141 alarm on Cell 1, Ant 1. RF module LED display shows flashing red/green. This is incorrect. LED should display solid green for alarm 4141, Initiate the 4142 alarm on Cell 1, Ant 1. RF module LED display shows flashing red/green. This is incorrect. LED should display solid green for LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 161/330 Version 1.0 Confidential


alarm 4142. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Incorrect LED color (flashing red/green) is displayed for alarm 4141 and 4142.

3.213 GPS receiver alarm: control interface not available (4011) alarm does not clear when reconnecting FYGB GPS Problem report: 59544ESPE05 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: eNB on Air. GPS Frequency Sync in use. Normal tuning ongoing. Unplug GPS and wait for Alarms to show up. Wait a few tuning cycles before plugging GPS again. GPS receiver alarm control interface not available (4011) does not clear and FYGB remains grayed out, but GPS tuning works as expected. Attached PR: 118742ESPE01, 125410ESPE04, 121889ESPE01 Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: GPS receiver alarm control interface not available (4011) does not clear and FYGB remains grayed out. GPS tuning works as expected.

3.214 Wrong Fault number (1900) visible in BTS Site Manager Faults-view. Problem report: 59616ESPE05 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: LTE eNB is up and running with H-type antenna configuration. If another RF Module is replaced with not compatible frequency band RF Module, fault 1900 (RF Module configuring failed) is visible in Faults-view of BTS Site Manager, instead of correct fault 1807 (Invalid frequency channel for the BTS HW). After BTS reset, with not compatible RF Module, correct fault 1807 (Invalid frequency channel for the BTS HW) is visible in Faults-view of BTS Site Manager. Failure situation is recovered by replacing compatible frequency band RF Module. Probability: Permanent Solution / Workaround: Replace only frequency band compatible RF Modules to the H-type configurations with two RF Modules. Impact to Operator: Fault 1900 (RF Module configuring failed) visible instead of correct fault 1807 (Invalid frequency channel for the BTS HW).

3.215 RET fault (Antenna Line Device Failure 0010) is cleared after hot remove optical LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 162/330 Version 1.0 Confidential


fiber Problem report: 59625ESPE05 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: 1. BTS is On Air with configuration: L1‐J‐98‐2TX‐4RX 2. RF has commissioned ALD 3. Optical fiber is hot removed from SM, RF is disconnected. 4. Optical fiber from different Radio Frequency is hot inserted. There are no ALDs physically connected to this RF. Following faults appears: - Antenna Line Device Failure (0010) - for RET1 - OK - Antenna Line Device Failure (0010) - for MHA1 (LNA1) - OK - Antenna Line Device Failure (0010) - for MHA3 (LNA2) - OK Optical fiber from RF connected at point 4 is hot removed. There are no ALDs physically connected to this RF. Faults changes in following way: - Failure in optical RP3 interface (0010) - appears - OK - Antenna Line Device Failure (0010) - disappears - NOK. Failure should be still active. - Antenna Line Device Failure (0010) - for MHA1 (LNA1) - still active - OK - Antenna Line Device Failure (0010) - for MHA3 (LNA2) - still active - OK, After hot remove fiber from second RF, failure regarding RET1 is cleared (Antenna Line Device Failure (0010)) - NOK. This failure should be still active. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: After hot remove fiber from second RF, failure regarding RET1 is wrongly cleared but should remain still active.

3.216 Manually started remote Rollback of iOMS is not terminated at NetAct Problem report: 59773ESPE05 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Rollback task is still active at NetAct till it is timed out. NetAct is not notified that rollback is finished. Probability: Permanent Solution / Workaround: Execute rollback via cli command. Check result via ssh. Impact to Operator: The not terminated rollback task in NetAct blocks any other SW Management task concerning this iOMS till the task is timed out.

3.217 After Rollback of the iOMS interface configuration lost Problem report: 59786ESPE05 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 163/330 Version 1.0 Confidential


Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Interface configuration was lost after Rollback of iOMS was done. Operator was not able to ping iOMS anymore. Probability: One occurrence Solution / Workaround: Use ILO connection to retry Impact to Operator: After Rollback of the iOMS, interface configuration lost.

3.218 FHFB: Fault 1958 and 1905 is visible after startup Problem report: 60052ESPE05 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Capacity & Performance, New feature/functionality Description: BTS is On Air with all cells. Site reset is performed. After startup RF reports fault 1958, after that 1905 and RF reset is visible. Problem seen in 1 out of 20 cases. Probability: Occasional Solution / Workaround: Site reset to bring cells back into service Impact to Operator: Reduced capacity as few cells remain out of service

3.219 All radio modules are reset after hot removal of FBBA and hot insert of FBBC Problem report: 60296ESPE05 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: BTS is starting up. BTS is OnAir. FBBA card is hot removed. FBBC card is hot inserted. About 6 minutes after FBBC hot insert, all radios are reset, this is not OK. Secondly just after radio resets alarm Unit autonomous reset as recovery action is reported (0476), this is also not OK. Thirdly after radios recovery two previously enabled cells LNCEL-21968 and LNCEL-21971 are disabled, as you can assume this is also not OK. Probability: Permanent Solution / Workaround: eNB reset. Impact to Operator: All radio modules are reset after hot insert of FBBC, additionally two cells are not enabled after BTS recovers from RMODs reset and Unit autonomous reset as recovery action (0476) is reported for FSMF.



3.220 Hitachi and Dengo RETs not detected on RS485 port Problem report: 60314ESPE05 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: 1. BTS is OnAir with configuration #L1-A-4-1TX-2RX 2. RET Hitachi or Dengo was connected to RS485 interface 3. BTS startup was performed, Dengo RETs wasn't detected at all, Hitachi RETs are detected from time to time, when they are detected calibration scenario failed with fault 1873. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Hitachi and Dengo RETs are not detected.

3.221 RNW Measurement Management crashed when clicking stop then clicking start measurement button Problem report: 60335ESPE05 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: RNW Measurement Management window crashes when clicking stop then clicking start button. Probability: Permanent Solution / Workaround: Reload RNW Measurement Management window. Impact to Operator: RNW Measurement Management Window stops working

3.222 BTS is not reset after sending delta changes to the BTS after new FBBA/FBBC has been hot inserted Problem report: 60424ESPE05 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: BTS is OnAir. FBBC card is hot removed. FBBA card is hot inserted. As an alarm source, some strange number is visible and not the real FBBA or FBBC number as it should be. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Strange numbers for alarm source are visible for FFBA or FBBC

3.223 Cells under RF modules connected to port3 of FBBCs are faulty after eNB reset. Problem report: 60613ESPE05 Exists in: LN7.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 165/330 Version 1.0 Confidential


Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: eNB commissioned and ON-air with 3FHFB/3FRIG/3FRLB and 2 FBBCs When eNB is reset, all cells come on air except the ones with RF Modules connected to port3 of FBBCs. No alarm is generated. Sometimes cells came up. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Cells related to RF modules connected to Port 3 of FBBC are not operational.

3.224 FSMF: “Failure in optical RP3 interface (unsp.)” and “Not enough HW for LCR (1868)” - FRGQ on 1.1.3.2 not detected, both cells 8+9 of on 1.1.3.1 and 1.1.3.2 and in addition on cell 7 on 1.3.1 (FRHB) not on Air Problem report: 91144ESPE03 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Stability Description: 1. All RM/RRHs detected and all cells on Air with load 544_08 2. Update from 544_08 to 554_35 3. 1st Minor Failure: "Failure in optical RP3 interface (unsp.)". 4. Then configuration error: BTS configuration error (Not enough HW for LCR (1868) BTS:BS 3022/cell9. Cell on FRHB (1.3.1) not on Air, but no failure occurred. 5. FHCA (1.1.3.1) and not detected FRGQ (1.1.3.2) not on Air. 6. Additional manual reset as workaround doesn't work. 7. But now cell 7 on FRHB 1.3.1, cell 8 on FHCA 1 1 3.1 and cell9 are detected. FRGQ 1.1.3.2 doesn't go onAir and now BTS reset required (4001) for cell 9. 8. Manual reset 2: all cells on Air. 9. Manual reset 3: still all cells on Air. Probability: Occasional Solution / Workaround: Two additional manual eNB resets. Impact to Operator: If the update to RL70 SW will be done from an older SW build, below RL70 1.0PD (LN7.0_ENB_1407_548_07), occasional radio modules will not be detected and cells does not go onAir. In this case two additional eNB resets are necessary: First manual reset to detect normally the former not detected RMs/RRHs and the second manual reset brings the cells on this radio modules onAir.

3.225 Inconsistency in Supported Maximum Password Length Problem report: 120754ESPE01 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: OMS shall support maximum password length of only 128 characters for operator management. However, when password more than the supported maximum length is set, user is still able to log in at application launcher when it's not possible to close the RNW Measurement Management window. Probability: Permanent Solution / Workaround: For workaround, do not use password longer than 128 characters. Impact to Operator: Operator will not be able to close the RNW Measurement Management window.



3.226 On stopping the capture at point B we are observing the UE traffic interruption Problem report: 120996ESPE01 Exists in: LNF7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: New feature/functionality Description: During the file based/stream based capture in IPsec environment at point B during stopping of the capture UE traffic being interrupted. All the users under FZM will get impacted for few minutes. The traffic some time automatically resumes or sometimes need UE attach and detach. Probability: Permanent Solution / Workaround: Use tcpdump command to capture ESP packets at site with SSH access. Impact to Operator: Data loss to end users who are under the coverage are of that FZM for few minutes when operator uses L&R feature is to capture ESP packets.

3.227 RL70 MSU: semid 262150: semop failed for cookie 0xd4d34b9: incorrect semaphore state Problem report: 122488ESPE01 Exists in: iOMS7.0 Correction Target: RL70 P8 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Failed message "semid 262150: semop failed for cookie 0xd4d34b9: incorrect semaphore state" found in msu.log. A ticket was created against Red Hat. Probability: Occasional Solution / Workaround: Ignore "semid 262150: semop failed for cookie 0xd4d34b9: incorrect semaphore state" error if occured during commit operation. Impact to Operator: Errors may lead to misunderstanding, that upgrade procedure was not completed correctly. In fact everything should work fine.

3.228 MDs are not synchronized but commit status is "success" - commit on new OMS Problem report: 122489ESPE01 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: After system upgrade from iOMS6.0 to iOMS7.0 MDs are still not synched after successful commit. Probability: Permanent Solution / Workaround: After a successful commit operation, manually check the synchronization of the HDD. To check if the hard disk are working, execute the command: # cat /proc/mdstat Expected output: The output should include [UU] next to each partition. Impact to Operator: Even though system displays that commit is successful disks may not be in sync.



3.229 FDD UL Throughput vs. SINR curve below KPI Problem report: 123253ESPE01 Exists in: LNF7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Capacity & Performance, FDD UL throughput values at mid-to-poor SINR ranges are below the specification. Description: RL70 UL Throughput curves (independent of UDP/TCP, AWGN/EPA5) are all a few dB below the RL70 KPI levels based on the validation sheets. The top-most point which is based on the Demo configuration was left off of the graph, but all other values are based on the GMC which was used for the test. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: RL70 FDD UL Throughput levels do not meet the Specification at various SINR levels. The peak values are not problematic, but other points along the SINR curve from mid to poor SINR values are below expectations.

3.230 Application Launcher Version doesn't show correct in WebPage Problem report: 126119ESPE04 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: The value used for the download window was a static value and there was no utility method used in order to dynamically retrieve the current version value of Application Launcher. Probability: Permanent Solution / Workaround: A jar was added containing a utility file which would retrieve the current version of AL as provided by Flexi. This file was used upon building the Application Launcher Download window to be able to display the correct version value. Impact to Operator: The operator will not be able to see the correct version of the Application Launcher that is available for download.

3.231 MHA states are shown incorrectly in Site Element Manager during BTS start-up Problem report: 126911ESPE04 Exists in: LN7.0 Correction Target: RL70 P8 Severity: C - Minor Customer Impact: Operation & Maintenance Description: MHA states are incorrect during BTS start-up. After startup MHA state is correct. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: MHA states are incorrect during BTS start-up. After startup MHA states are correct without operator intervention.



3.232 FRMC radio module is reset with "Unit autonomous reset as recovery action (1905)" alarm, after change of FBBA extension card to which FRMC radio module was connected to FBBC Problem report: 127042ESPE04 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Problem occurs when radio module, like FRMC, is connected with two optical cables to two extension baseband modules, FBBA and FBBC, and we are trying to change FBBA to FBBC extension card. After changing the card to FBBC, radio module is changing its position in the BTS hardware, and about 1:30 minute after 4001 alarm is reported for newly inserted FBBC card, FRMC radio module is reset with Unit autonomous reset as recovery action (1905) alarm. Radio module is reset and recovers within specified time. After radio module is recovered no further action is needed from the operator point of view, there are no additional alarms reported due to FRMC radio reset. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Only minimal impact. Just an additional alarm "Unit autonomous reset as recovery action (1905)" which is visible for affected radio module in Alarm History.

3.233 LTE1854: Conversion phase failed during OMS upgrade from RL50 corr31 to RL70 Problem report: 127473ESPE04 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: OMS with G6 HW was used. At iOMS R_GOMS6_1.107.1.0.release_oms.corr31 is installed. Start upgrade to RL70 with MSU image via CLI command. In this case the upgrade failed during Conversion phase. Probability: Permanent Solution / Workaround: Please check if your rpm exist in db # rpm -qa | grep hp-scripting-tools If yes then check this folder # ll /opt/hp/hp-scripting-tools If it doesn’t exist execute this rpm -e hp-scripting-tools-xxx.xxxx (version from rpm –qa command) Then execute this MSU one more time. Impact to Operator: After a rollback/fallback the next upgrade of the OMS fails

3.234 LTE1634: RF diagnostic VSWR value constantly reported as 0.0 after number of runs Problem report: 127533ESPE04 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: New feature/functionality, The feature stops working until site reset. Description: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 169/330 Version 1.0 Confidential


After a number of RF Diagnostic runs VSWR value is constantly being displayed as 0.0 for one of two radios. In reported case this failure occurred after 83 test iterations and since then every time RF Diagnostic is initiated, VSWR value is reported as 0.0, which means it is not measured. Site reset brings this feature back to work (but still occasionally 0.0 is reported) This issue is repeatable, but occurs after different number of test iterations. In reported case it occurred after 83 RF Diagnostic runs, but previously more than 100 where needed. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: RF diagnostic VSWR value constantly reported as 0.0

3.235 No voltage in uncommissioned antenna lines Problem report: 127571ESPE04 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: There is no voltage in new uncommissioned antenna lines and related Antenna Line Devices are not detected. Probability: Permanent Solution / Workaround: Commissioning is needed for new antenna lines, then voltage is set and related Antenna Line Devices are detected. Impact to Operator: Antenna Line Devices are not detected.

3.236 Radio Module reset after 15sec break on RP3 interface Problem report: 127590ESPE04 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Stability Description: BTS state is OnAir. Call was established. One 15s break on RP3 interface was performed. Radio Module (FRIG) reset occurs. Fault 10 was visible on every cell. + OTN recovery period was set to 200000ms so RM should not reset. 14 sec breaks works, 15 sec seems to be a limit. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Call drop and temporary service outage of Cell fed by affected Radio Module.

3.237 An exception in the operation feedback message during deleting some MO via GOMS Problem report: 127616ESPE04 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 170/330 Version 1.0 Confidential


Description: No successful message returned after some MO deletion was successfully executed via GOMS. Probability: Permanent Solution / Workaround: No Workaround. Impact to Operator: Operator will not know that the MO deletion operation was completed.

3.238 After FBBA is swapped for FBBC, optical link connected to newly inserted FBBC is not activated Problem report: 127647ESPE04 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Problem occurs in configuration in which radio is connected with two optical links to two extension modules FBBA and FBBC. When FBBA is swapped for FBBC, optical link connected to newly inserted FBBC is not enabled. Link is activated after commissioning of this new FBBC and BTS reset which is needed to get this new FBBx module to work. Probability: Permanent Solution / Workaround: Commissioning and BTS reset (which is required to get new FBBx module fully operational) Impact to Operator: Radio is commissioned on different port than it could be expected but this has no impact on any functionality.

3.239 SEC_iOMS: Key update disabled when oms ee certificate manually installed Problem report: 127651ESPE04 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Security Description: Manually installed iOMS certificate. Trigger key update sequence with # omscertificate cmp-key-update Key update failed failed with error: # omscertificate cmp-key-update Generating RSA private key, 2048 bit long modulus .+++ .........+++ e is 65537 (0x10001) Requesting End Entity certificate. CMP Key Update failed with return code: 58 [Inappropriate usage of key update (End entity certificate installed manually)]. Probability: Permanent Solution / Workaround: No Workaround. Impact to Operator: Manually installed iOMS entity certificate cannot be updated upon expiration.

3.240 RU not assigned at FBBC No.3 Port Problem report: NA05773463 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 171/330 Version 1.0 Confidential


Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: RMOD plugin to FBBC port 3 in live network. RMOD is not configured. Current analysis shows that there's a problem of RMOD clock stability. Probability is high that the problem occurs (around 50% of the cases). Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Cells related to Radio modules connected to FBBC optical Port 3 are not operational.

3.241 [2G-4G RF Sharing]: Cell power failure after hot Insert of the RFM Problem report: 58462ESPE05 Exists in: LN6.0 Correction Target: RL60 3.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: Configuration: LTE FSME,111,15MHz,20W,I-Type with 3 x FHEB and GSM ESMB,222,20W,IDD I-Type TRS configuration in LTE: IP IUB IUB configuration in 2G: Packet abis SEM Version in LTE: LN6.0 (1311_104_00) SEM Version in 2G: 5.1 3.1.0 BL23 EFS requirement reference (if possible): FTM SW Version in LTE: R2_LN60_MP2_359.00 LTE SW: LN6.0_ENB_1311_870_01 2G BTS SW: BTSM51D3.17X 5.29-3 (EX5.1 3.1. Faulty scenario: Step 1: Calls are made both technologies and left on during the testing. Calls are successful. Step 2: One RF module is hot removed from the master technology BTS and BTS hardware view is checked from the BTS Site Manager for both technologies. Calls via removed RF module are dropped but other calls are not disturbed. RF transmission of the affected cells is stopped but other cells are not affected. Step 3: Previously removed RF module is hot insert and BTS hardware view is checked from the BTS Site Manager for both technologies. Unexpected alarm: PER detected in RP3 interface and LTE cell power failure alarm occurred. 2g calls are successful but no LTE calls via the affected sell. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: 2g calls are successful but no LTE calls via the affected sell. PER detected in RP3 interface and LTE cell power failure alarm occurred.

3.242 LTE BTS - High RSSI on PUSCH/PUCCH Problem report: NA05770173 Exists in Release: LN5.0, LN6.0 Correction Target: RL60 3.1 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 172/330 Version 1.0 Confidential


Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: Degraded RSSI performance reported by a number of Nokia eNBs that have MHAs in their antenna system. MHAs remain in the passive (or bypass) mode of operation until recovered to the normal (gain) mode operation by AISG command. MHA AISG/3GPP protocol response to the eNB request TmaGetDeviceDataRequest returns an incorrect TmaSubunitType value. In a MHA fault condition, where the MHA is seen as faulty, the TmaSubunitType is requested and used by the eNB to try and recover the MHA. The eNB does not recognise value as being AISG compliant. The response is not expected nor recognised by the eNB and therefore it commands the MHA into ‘bypass’ mode. Solution / Workaround: Solution: If MHA firmware supporting the correct TmaSubunitType cannot be deployed this correction offers workaround. eNB commands the MHA into ‘normal’ mode even TmaSubunitType is not expected nor recognized. For the solution details please contact the responsible Technical Support team. Workaround: Launch 4G BTS Manager and then block/unblock RFM1 module using BTS manager, as this is the AISG master. Impact to Operator: Average RSSI for PUSCH KPI collected via NetAct indicated that some cells were reporting a degradation of between 8-10 dBm, indicating a receive level -110dBm. Impact to End user: eNB coverage is limited and uplink performance decreased.

3.243 LTE eNB Software download failed by Software manager in NetAct Problem report: NA05776318 Exists in Release: iOMS 6.0, iOMS7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: When SW download from NetAct to iOMS is interrupted on directory listening, iOMS will not abort whole operation and not delete directory with corrupted SW.. SW upgrade on eNB will fail in such scenario. Solution / Workaround: Delete directory with corrupted SW on iOMS (/var/mnt/local/omsdata/OMSftproot/SWPackages) and retry update/upgrade procedure once again. Impact to Operator: eNB SW upgrade/update may fail. Procedure needs to be executed once again after applying workaround. Impact to End user: No Impacts to End-User



3.244 Antenna Round Trip Delay in 3rd Party 'Distributed Site' Problem report: NA05740108 Exists in Release: LN6.0 1.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Description: Summary of the original problem: Antenna Round Trip Delay in 3rd Party 'Distributed Site' How end user/operator could detect the problem: Nokia eNB is realized using normal H-Type configuration and in some case I-Type where 6-Pipe Rel.3 Module is deployed. Each ANTL-TX/RX is connected to a coupler where on one port we have Adaptive Load and in the other we are connected to a Master Unit via RF cable and diplexer. From master Unit to Remote Unit we have 12,8 Km of Optical Fiber From Remote Unit to Antenna we have still 1/2” RF cable (25m) In order to compensate as much as possible Passive Unit Delay introduces we decide to use the maximum value allowed by “AntennaRoundTripDelay” in MO ANTL equal to 45077.5ns. Solution / Workaround: Workaround: none Description of the correction (incl. risk analysis): sack update Impact to Operator: wrong parameter description Impact to End user: wrong parameter description

3.245 RSSI difference of 27-29 is seen after radio block/unblock and radio power resets Problem report: PR043175 Exists in Release: LN7.0 0.2 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: After radio resets all TRXs report a RSSI difference of 27-29 Solution / Workaround: Do a full site reset if radios are needed to be reset or they have already been reseted due to power reset or sw reset Impact to Operator: degraded operability

3.246 FSMFr3 uncommissioning button doesn’t work Problem report: NA05785840 Exists in Release: LN7.0 Correction Target: RL70 1.0



Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: FSMFr3 uncommissioning button doesn’t work. Solution / Workaround: Manually delete SCF file from eNB Impact to Operator: Not possible to fast remove configuration from eNB Impact to End user: No Impact

3.247 RFsharing "RRC Connection Reconfiguration" in LTE during 2G BCF Unblock Problem report: NA05790004 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Capacity & Performance Attached PRs: NA05790004, NA05796998 Probability: Permanent Description: We start a download FTP session on cell 31 in sharing with 2G BTS. Download Performance were as expected for 15MHz: 109Mbps. Then we tried to Lock/Unlock the 2G and in both action (Lock and Unlock) we saw a degradation of 4G throughput for few seconds. Same behavior with Lock/Unlock of the BCF. From Nemo trace seems that during the degradation period, the DL BLER and UL retransmission rate increase up to 80% (Throughput pass from 109 to 0-10Mbps). Throughput degradation is a well known consequence of CNI-1594 which was needed to solve several major issues related to LTE15 Nyquist. Change according above internal change note is included in VEGAS software but not present in RL60. That is why issue was spotted only in RL70 and higher releases with 15MHz and RF sharing. It is expected behavior which will not be changed. Root cause: Throughput degradation is caused by long time of carrier reconfiguration. Correction: We optimized time dependencies during carrier reconfiguration which allows us to shorten transmission break to acceptable level. Solution / Workaround: Throughput degradation is a well known consequence of CNI-1594 which was needed to solve several major issues related to LTE15 Nyquist. CNI is included in VEGAS software but not present in RL60. That is why issue was spotted only in RL70 and higher releases with 15MHz and RF sharing. It is expected behavior which will not be changed. Impact to Operator: Throughput degradation of 4G for few seconds during Lock/Unlock actions. Impact to End user: Throughput degradation of 4G traffic for few seconds.

3.248 Duplicated H/W inventory information on eNB with SyncHub BTS sync configured Problem report: NA05790817 Exists in Release: LN7.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 175/330 Version 1.0 Confidential


Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Customer use GPS as their sync reference for eNBs and made sync chain topology for daisy eNBs. Usually upper alphabet with number 0 (eg. L0) designates the eNB with GPS master role and number greater than 0 (eg. L1) designates the eNB with SyncHub clock mode. While the project team deployed software onto some of eNBs in the live network, they observed odd symptom that the HW inventory of GPS module are duplicated from both GPS master eNB and SyncHub eNB ie. The gathered product Code and serial Number from HW DB in NetAct are same for collocated eNBs as well as GPS clock master eNB. The duplicated inventory DB entries in the NetAct HW DB gives somewhat confusion to our operator as well as customer who handles the stock of real GPS lots. Even the BTSSM HW view gives hints that this module is shown just for the convenience and show the detected the product id. being read on the propagated TSIP signal on sync cable being fed by their precedence eNB. The HW inventory information collected by the upper node should not include this GPS module in collocated eNBs as real one being regarded the HW modules being plugged physically. Correction: Sysadapter will detect if the eNB is SyncHub eNB. Solution / Workaround: No workaround. Impact to Operator: Master eNB GPS showing duplicated in the HW database. Impact to End user: No impact.

3.249 [FWHI][RL70FZ] PUCCH Format 2b DTX'ed by pico working with QCOM 9635 Problem report: PR042180 Exists in Release: LNF7.0 Correction Target: Correction not needed Severity: B - Major Customer Impact: Capacity & Performance Attached PRs: Probability: Occasional Description: PUCCH Format 2b cannot be decoded correctly in ULPHY. The root cause seems to be, the UE does not compose the Format 2b correctly (as per ULPHY team analysis). Problem visible only with one kind of UE (Qualcomm prototype terminal 9635) Summary of the original problem: TCP tput lower by ~4Mbps Dependency on configuration: 4Mbps @20MHz cell bandwith Solution / Workaround: Use another UE (newest Qualcomm SW) Impact to Operator: TCP peak tput downgrade Impact to End user: End user will see TCP tput downgrade by ~4Mbps

3.250 BTS autonomous reset as recovery action alarm due to ENBC crash



Problem report: NA05791315 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: BTS restart due to ENBC crash. Crashed happened because event which was in the queue was discarded and later there was attempt to access to event which not exists. Root cause: Problem may occur when there are problems with communication with other eNBs via X2 interface (for example some network issues). Additional condition to trigger error scenario are finished S1 Setup procedures for multiple S1 links, or toggling of one S1 link - finished S1 Setup which provide new supported GuGroups is trigger for starting X2 Configuration Update. Correction: Additional X2 Configuration which lead to ENBC crash problem won't be started anymore when X2 link is waiting for slot in X2 Setup Queue. Solution / Workaround: No workaround. Impact to Operator: Occasionally BTS autonomous reset as recovery action alarm due to ENBC crash occur. Impact to End user: No service during BTS autonomous reset.

3.251 FSME - 5MHz bandwidth Cell disabled without alarm Problem report: NA05791260 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: In given configuration (Mixed bandwidth cells on REL2) 5Mhz Cells were disabled without any alarm after SW upgrade. Cells with bandwidth 5MHz not OnAir if using mixed bandwidth configuration on REL2 hardware. Root cause: Cells with mixed bandwidth were deployed on same baseband unit, which caused problem with routing calculation. Correction: Restricted deploying mixed bandwidths on single baseband unit. Solution / Workaround: Configure cells with same bandwidth only, or mixed bandwidths cells but number of cells per bandwidth has to be smaller than baseband units number. Impact to Operator: Occasional 5MHz Cells with mixed bandwidth disabled without alarm.

3.252 PM Data cannot get from BTS site Browser LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 177/330 Version 1.0 Confidential


Problem report: PR046108 Exists in Release: LNF7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR046108, PR046286, PR047641 Probability: Permanent Description: Summary of the original problem: Getting PM files in SiteBrowser always fail. Description of the fault: Group mapping was always checked if present where in SiteBrowser it is always empty thus caused the behavior of not returning the PM files. Solution / Workaround: Description of the correction: Added checking whether group mapping of a PM file is present or not. Since in Site Browser group mapping is always empty, there is no need to proceed to the other checking that is only needed in Site Manager. Impact to Operator: If customer is collecting the PM data with site browser tool, then PM data can not be collected. Impact to End user: No Impact

3.253 Site is stuck in INTEGRATED STATE after SW upgrade Problem report: NA05799265 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Capacity & Performance Attached PRs: Probability: Occasional Description: BTS stuck in "Integrate" state SW upgrade. A "Configuraton error: BTS config error (Not enough HW for LCR) (1868)" alarm is observed in BTS Site Manager. In addition, 2-MHA were undetected and Antenna Line Device Failure (0010) alarm was observed in BTS Site Manager. Root cause: CellP will be not deleting MHA which is still connected to other RMOD. Correction: Fix for race in MOAM. Solution / Workaround: The site was reverted back to previous SW release in order to recover site operational status. Impact to Operator: Performance and capacity degradation. Impact to End user: No calls possible in affected cell.

3.254 All MHA & RET down on site



Problem report: NA05799258 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: SW upgrade and Activation is performed using NetAct. After Activation of the eNB SW all of MHAs are not detected with following alarm: "Antenna Line Device Failure (1873)". Root cause: BTSOM CellP component was attempted to configure gain mode on these MHAs, resulting in a error response from the MHA. Correction: BTSOM CellP will no longer attempt to configure gain mode on MHAs that do not support bypass mode. Solution / Workaround: No workaround. Impact to Operator: Sites with MHAs that do not support bypass mode (such as ATMAP1412D-1A20) were not able to go in service after SW upgrade. Alarm 1873 was reported on these MHAs. This problem only occurs on sites with fixed gain MHAs. Impact to End user: No impact.

3.255 RP3 alarm was observed. 3-RF modules were not detected and 1-FBBA remained in "configuring" state. Problem report: NA05799255 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05799255, NA05799441 Probability: Permanent Description: FDD eNB startup halted in early phase (RF module detection not started) without alarm which corresponds to synchronization issue from GPS in case of commissioned phase sync. Site commissioning procedure is not possible. GPS device or GPS cabling is damaged How end user/operator could detect the problem: Startup procedure halted on very beginning, RF modules detection not started. Active alarm 4011 “GPS control interface not available”. RF modules not detected with alarm “RP3 failure in optical interface” when phase sync is commissioned. PPS signal from GPS is available but “CommonBCN” is not set. Solution / Workaround: In case of problems during startup procedure with GPS synchronization source on FDD sites with phase sync configured alarm 4153 “Reference clock missing in startup” should be raised. Startup will proceed to detect RF modules and allow reconfigure eNB e.g. to Frequency sync. Description of the correction (incl. risk analysis): New feature is required. Issue cannot be fully fixed in RL70 with pronto.



Impact to Operator: Occasionally eNB startup halted in early phase (RF module detection not started) without alarm due to missing synchronization. This occur if FDD sites configured with phase sync as GPS synchronization source and there are problems with GPS device or cable. Operator needs to manually reconfigure affected BTSes to enabled basic startup functionalities. Features requiring network level synchronization cannot be operational. GPS device or GPS cabling is damaged. GPS device replacement is recommended. Impact to End user: No impact.

3.256 After the SW upgrade, Incompatible SW Version/BTS Integrated to RAN Problem report: NA05799257 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: After the SW upgrade "Incompatible SW Version/BTS Integrated to RAN" occur which causes auto fallback to previous SW release. But only FSMF fallback to previous SW release takes place. Other unit RF module/FBBA/FBBC is still in current SW release. Root cause: MHA::scannedAntennaInterface NONE value was not handled by sysadapter. Correction: MHA::scannedAntennaInterface NONE value is now handled by sysadapter. Solution / Workaround: No workaround. Impact to Operator: eNB upgrade failure and auto fallback to previous SW release. Impact to End user: No impact.

3.257 [FZP, FWHC,EB,HM] Furuno Multi-GNSS Receiver 1PPS Phase Jump After 49.7 Days Operation Problem report: PR046591 Exists in Release: LNF5.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: User Plane Quality Attached PRs: Probability: Permanent Description: he Multi-GNSS timing receiver will demonstrate a phase shift in its output clock after 49.7 days of being powered. This shift will affect LTE synchronization for Flexi Zone Micro (FZM) and Flexi Zone Pico) eNodeB’s equipped with a Multi-GNSS capable timing receiver while operating in the phase synchronization mode. Summary of the original problem: The multi-GNSS capable timing receiver used in all indoor Flexi Zone LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 180/330 Version 1.0 Confidential


Pico (FZP) and the FWHC, FWEB and FWHM Flexi Zone Micro (FZM) outdoor Small Cell products contains a design defect that will result in a shift of its output clock phase of between 4ms to 8ms after being powered for more than 49.7 days. For so equipped eNodeB’s operating in the phase synchronization mode this phase shift will propagate to the LTE carrier resulting in degraded call quality (e.g. increased interference, Circuit Switched Fall Back (CSFB) handoff failures, etc). How end user/operator could detect the problem: After 49.7 days of powered operation the GNSS receiver clock phase will shift most likely triggering the “Difference between BTS master clock and reference frequency” fault (9: EFaultId_DacWordChangAl) and a possible eNodeB reset. Following these events LTE call processing will continue but with an incorrect time alignment. The incorrect time alignment will result in degraded call quality in terms of high levels of interference and handoff failures. Description of the fault: A design defect exists within the multi-GNSS timing receiver where a 4ms to 8ms phase shift of the output clock phase occurs following the rollover of an internal 32-bit hardware counter. The counter rollover occurs 49.7 days after the receiver has been powered. Dependency on configuration: The problem affects all FZM’s and FZP’s operating in the phase synchronization mode equipped with the multi-GNSS (GPS + GLONASS) capable timing receiver which includes: FZM (Outdoor): FWHC, FWEB and FWHM FZP (Indoor): All models Faulty component and version: The problem is present in all version Small Cell products equipped with the multi-GNSS capable timing receiver. FZM (Outdoor): FWHC, FWEB and FWHM FZP (Indoor): All models Solution / Workaround: Impacts to call processing can be avoided by subjecting the multi-GNSS capable timing receiver to a power reset prior to its completing 49.7 days of operation. A GNSS receiver reset can be performed without impacting call processing by BTS Site Manager (BTSSM) command. After commanding a Small Cell GNSS receiver power reset the eNodeB will continue to operate with a secondary synchronization reference source (if available) or in the synchronization holdover mode. The GNSS receiver will re-acquire satellites and resume normal operation. Performing a power reset of all Small Cell eNodeB’s equipped with a multi-GNSS capable timing receiver at a 1-month interval will prevent a phase shift of the receiver’s clock output. Description of the correction: An updated version of GNSS receiver firmware that corrects the problem leading to the clock phase shift is being developed that will be loaded into all affected Small Cell eNodeB GNSS receivers. Risk analysis of the correction: The process to load the new GNSS receiver firmware must be performed as part of an eNodeB reset. The Small Cell eNodeB will not be available for call processing while the receiver firmware is being updated. It is estimated that 15 minutes will be required to perform the eNodeB reset and GNSS receiver firmware update. Customer effects: Requires reset of all impacted eNodeB’s along with a 15-minute estimated recovery time as part of the firmware upgrade process. Impact to Operator: The phase shift of the multi-GNSS timing receiver clock output will result in degraded call quality including increased interference and handoff failures. Impact to End user: The phase shift of the multi-GNSS timing receiver clock output will result in degraded call quality including increased interference and handoff failures.



3.258 ALD alarm reported from multiple sites with RETs after PP0.2 activation. Problem report: NA05800227 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: After SW upgrade the number of ALD alarms increased. This problem report is focusing on fault ID 10. Correction: Faster reaction on “write uart” requests and switches faster to receive mode. This will decrease number of failed transmissions. Solution / Workaround: No workaround. Impact to Operator: After SW upgrade the number of ALD alarms increased. Impact to End user: No impact.

3.259 [FSMr2] After setting ToP Phase sync eNB stucks in Integrated mode Problem report: PR047023 Exists in Release: LN7.0 Correction Target: Correction Not Needed Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: After selecting Phase synchronization as Network synchronization mode in commissioning file for FSME eNBs, they stuck in "Integrated Mode" and never go 'On air". This issue is seen on FSME-FTIB/FTLB eNB, load LN7.0_ENB_1407_562_04. According to LTE891 specification ToP Phase feature is only supported on FSMF eNBs. FSME eNB shouldn’t allow the operator to select TOP PHASE as a Synchronization Source. The suggestion is to remove ToP Phase Synchronization option from BTS SM GUI. Test Scenario Steps: 1. Upgrade FSME-FTLB/FTIB to any RL70. 2. Configure TOP Phase. ( please refer to the attached screen shot) 3. Monitor the eNB events logs. Solution / Workaround: Suggested adding to the actTopPhaseSynch description that ToP-P is not supported with FSMr2 HW and add the from site element manager already existing validation rule for FSMr2 HW against actTopPhaseSynch to CCPM (and from there to PDDB).Take care that this is covered with the parameter relationship attribute as well. No impact to actual implementation as the validator at site element manager did already include this dependency. Impact to customer is cosmetic, since there is LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 182/330 Version 1.0 Confidential


no functional bug and resolution is improving rather usability by providing further information avoiding potential confusion. Impact to Operator: Phase synchronization as Network synchronization mode in commissioning file for FSME eNBs doesn’t work. Operator can wrongly configure BTS leading to failure. Impact to End user: No impact

3.260 LTE RL70 FZM BTS Clock Tuning History is gone from RL50 to RL70 Problem report: NA05800692 Exists in Release: LNF7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Summary of the original problem: It is not possible to check BTS clock tuning history in RL70 FlexiZone How end user/operator could detect the problem: BTS clock tuning option is not visible in BTS site manager Description of the fault: In RL70 BTS clock tuning history was made available only for sync master and disabled for sync slave eNBs. Since FlexiZones have hardcoded sync slave setting, BTS clock tuning option was not available. Related feature / functionality: Clock tuning Solution / Workaround: No workaround available. Description of the correction (incl. risk analysis): Checking of sync master parameter has been removed for FlexiZone BTSSM. Impact to Operator: Impossible to check BTS clock tuning history Impact to End user: No Impact

3.261 TOP ip address was not transfer from RL50 2.0 to RL60 3.0 during upgrade Problem report: NA05796777 Exists in Release: LN6.0 Correction Target: RL60 3.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Summary of the original problem: TOP ip address doesn’t get transferred from RL50 2.0 to



RL60 3.0 during SW upgrade. How end user/operator could detect the problem: Sw activation from RL50 to RL60 , The TOP ip address configured in RL50 doesn’t get restored in RL60. Description of the fault: In RL50 MP1, Sw team defined new adaptation version “"LN5.1" .The adaptation version is used in next release [LN6.x] during the upgrades to identify the correct transform class and modify the MO parameters. So the next higher release [LN6.x] version should have a transform method to handle the adaptation version “"LN5.1". But there is no transform method defined in LN6.x , so the code is taking wrong flow. There was no need for LN5.1,So this is a bug in LN5.1 release, instead it should have used the adaptation version as LN5.0 . We can fix it in LN6.x release to handle LN5.1 also as LN5.0 . Dependency on configuration: TOP enabled in RL60 Solution / Workaround: Workaround: Reconfiguration of TOP ip address again after the SW upgrade. NA Description of the correction: Code change is needed in NMA LN6.x release to handle LN5.1 also as LN5.0 Impact to Operator: TOP ip address doesn’t get transferred from RL50 2.0 to RL60 3.0 during SW upgrade. Since the customer has large number of site with ToP as primary synchronization source it is a rework to configure the TOP again. Impact to End user: Sw activation from RL50 to RL60, The TOP ip address configured in RL50 doesn’t get restored in RL60.

3.262 Fails ENB Rel OTH(M8006C13) KPI increase than RL60 Problem report: NA05798237 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Summary of the original problem: eNB sends S1AP_UE_CONTEXT_RELEASE_REQUEST to MME after S1AP_INITIAL_CONTEXT_SETUP_FAILURE which is not correct but degrades KPI values. Solution / Workaround: None Impact to Operator: M8006C13 is increased so Drop Rate is also increased. Impact to End user: No impact

3.263 NE O&M Connection Failure sometimes happened at FSME SMODs after RL70 MP1.0 upgrade Problem report: NA05789746 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 184/330 Version 1.0 Confidential


Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Summary of the original problem: FSME may goes out of service of callp and losing OAM connections towards iOMS/BTSSM repeatedly. How end user/operator could detect the problem: Successive NEOAM alarms and failing of BTSSM connection Description of the fault: HWAPI requests a flash operation at once per 24hours for several purposes, which leads to an allocation attempt of 128kB of continuous memory in kernel space. If this request can't be fulfilled, because idle RAM become fragmented to a certain level that there isn't a continuous 128kB region available, the memory reclaim procedure will be kicked in. This operation includes evicting pages backed by a permanent storage (e.g. squashfs being adopted by BTSOM binaries since RL70) from the memory. If the allocation attempt by MTD driver succeeds, the rest of the operation continues. If it fails, the requested size by MTD driver will be divided by 2 and the process starts from the beginning. From many problematic logs we saw that allocations of 64kB were usually successful, but after the second reclaim done by kernel, which may remove almost all squashfs backed pages from the memory. In some cases, The loss of memory for squashFS will be too much and finally for running BTSOM binaries(MOAM, FaReco, SysAdapter, BStat, and Cellp) may not be recovered well to make the BTSOM operation on predefined time margin. And finally the BTSOM processes will become out-of timing w.r.t. the BTSOM runtime requirement. The reason why evicted pages are not loaded back then is unknown. Note that such a big request for continuous memory is very unusual and in the case of flash (MTD) driver is not necessary and is there only because the driver is very old and hasn't been rewritten to use common zero copy approach used by modern drivers Related feature / functionality: Regression, Stability Dependency on configuration: FSME with more than 5 10MHz 2x2 cells and many neighborhood information to make up of big SCF Solution / Workaround: Workaround: N/A Description of the correction (incl. risk analysis): Change the method of allocating 128kB continuous memory by MTD driver whenever HWAPI application calls bare metal flash read/write operation from dynamic kernel memory at every requests to static kernel memory at the beginning of eNB startup to avoid further memory reclaim procedure being triggered by MTD driver. Impact to Operator: Callp and OAM service outage Impact to End user: No call service.

3.264 Chained RRHs does not work correct on FBBC1 port 3 Problem report: 2059ESPE09 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 185/330 Version 1.0 Confidential


Customer Impact: Capacity & Performance, New feature/functionality, Operation & Maintenance, Stability Description: 1. BTS with RL70 on OnAir 2. Upgrade from RL70 to RL70 3. After reset of upgrade, all RRHs detected. FBBC stays long time in configuring state. 4. When FBBC goes from configuring to working state, Failure in optical RP3 interface 1.1.3.2 5. Both modules master and slave are lost and come back after a while, I think reset - RRH-chain (1.1.3.1+1.1.3.2) on FBBC port 3). 6. Some seconds before cell 8 of 1.1.3.1 goes on Air, all cells from each RRH go from enabled state to disabled state. 7. After 10-15 seconds all cells enabled again. 8. Only cell 9 of 1.1.3.2 is disabled. 9. RRH-chain (1.1.3.1+1.1.3.2) on FBBC port 3. 10. Then cell 8 on master 1.1.3.1 go on Air, cell 9 on slave 1.1.3.2 stays in disabled state. 11. With normal reset cell 9 on 1.1.3.2 never comes up, only after a power reset. Probability: Permanent Solution / Workaround: Wait until optical link on chained module will be canceled and 2nd reset of both RRHs finished and cell goes on Air. Cell outage time for the 2 cells on FBBC1 port 3 chain can be up to 15minutes from the moment the go done, within activation reset. Impact to Operator: Chained RRHs on FBBC1 port 3 do additional reset within startup. So it needs 3-4 minutes longer before the cells here goes on Air.

3.265 RL70_General: Installation of iOMS with Gen8 HW via FEWS fails when eth0 of iOMS is connected to FEWS and eth1 connected to local network Problem report: 54269ESPE05 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: After commissioning is completed and iOMS auto-rebooted, access to iOMS is no more possible. Also ping to iOMS via local network is not successful. Only console works. iOMS receives packets via eth1 but responses via eth0. Probability: Permanent Solution / Workaround: Before upgrade of iOMS is started check that local network is connected at eth0 interface of iOMS. Impact to Operator: After upgrade to RL70 with new MSU package or after fresh installation after the restart with the new installed RL70 the iOMS can no more be pinged. Eth0 have to be shutdown manually via console.

3.266 Transport master unblock cause short drop in FSM2 interface traffic for Ethernet chaining to other BTS Problem report: 58179ESPE05 Exists in: LN7.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 186/330 Version 1.0 Confidential


Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Stability Description: Network configuration: IXIA N2X port4---Switch---(FSM1) LTE eNB (FSM2)---IXIA N2X port3. Send UDP data from IXIA N2X port4 to IXIA N2X port3. Trigger Block BTS on LTE eNB. Trigger Unblock BTS on LTE eNB. Expected is, that Block/Unblock of transport master BTS doesn't affect to chained traffic, but Unblock of transport master BTS cause short drop to chained traffic. This starts to happen on 3th unblock BTS after BTS site reset. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Transport master unblock cause short drop in FSM2 interface traffic.

3.267 Partition problems in OMS after USB or FEWS installation Problem report: 117060ESPE01 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Partition Issues: 1. Boot partition is only 115.32 MB in size (should be close to 304MB in ENFS requirement) after successful USB installation for both RU51 & RL70 builds. 2. sysimg partition size is 29000MB (should be close to 24576MB in ENFS) after successful USB installation for RU51 build. 3. Home partition size is only 4900 MB (should be close to 16384 MB in ENFS) after successful USB installation for RU51 build. Sizes of OMS partitions were incorrect because a script that updates partition sizes was using incorrect LDIF syntax. Probability: Permanent Solution / Workaround: No workaround. Impact to Operator: Partition size is limited or incorrect after USB or FEWS installation.

3.268 FSME - Grey Cell occurred in FSME site after SW upgrade Problem report: NA05797210 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: After SW upgrade to new SW release, grey Cell occurred in FSME site. This was cleared after eNB reset. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 187/330 Version 1.0 Confidential


Root cause: CellPCplaneOperation_setupComplete not cleared. Correction: Solved by CellPCplaneOperation clearance. Solution / Workaround: eNB reset clears the situation. Impact to Operator: Occasionally grey Cell occurred in FSME site after SW upgrade in sites with FSME. Impact to End user: No impact.

3.269 No PM files transferred to OMS after 25h OAM link break Problem report: 127898ESPE04 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Preconditions: - Measurement interval 15min. - PM upload period 60min. 1) BTS is onAir. 2) OAM link is disconnected. 3) After 25h the link is restored. No PM files are transferred to OMS when the next PM result file upload period expires. Probability: Permanent. Solution / Workaround: At least software update. Impact to Operator: No PM files are transferred from eNB to OMS after long OAM link break.

3.270 RET stays configuring state after upgrade to LN7.0 Problem report: 128127ESPE04 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PR: Description: SW upgrade from LN6.0 1.1.2 to RL70. After the upgrade RET stays in configuring state with error code 'Read Only Parameter, Execution failed'. RET configuration is never completed. Dependency on configuration: FSMF, 2xFRIE, 6xMHA, 5xRET configuration: L111-H-32-2TX-2RX, BW: 10MHz. Probability: Permanent Solution / Workaround: Calibrate RET, after that RET is working and symbol green. Impact to Operator: RET stays configuring state after upgrade to RL70.

3.271 LTE2019 - Radio Module is disabled after commissioning. Problem report: 128138ESPE04 Exists in: LN7.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 188/330 Version 1.0 Confidential


Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: 1. eNB with FSMF and RL70 SW will be decommissioned. 2. Radio are on. 3. All radios are detected. 4. eNB commissioning. There is 'Failure in optical RP3 interface (0010)' alarm raised for radio module FRMA 1.2.1. after commissioning. Radio is disabled and has unknown Module SW state. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Radio module is not operational after site commissioning. Cells set up on this RMOD are disabled. There is an alarm raised: "Failure in optical RP3 interface (0010)".

3.272 Problem with process trace logging by Web Gui Problem report: 153561ESPE02 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: When using Parameter Editor to change "level logging" parameter, there is no effect on OMS level logging, but when CLI "ztraceli" is used inste Probability: Permanent Solution / Workaround: As a workaround, Log-level will take effect when using CLI command in OMS target command prompt: # ztracecli --level 5 # ztracecli --level 2 Impact to Operator: When "Parameter Editor change in Web GUI" is used, it will have no effect on OMS logging level.

3.273 TRS ETH IF Ethernet statistics counter showing wrong value Problem report: 153992ESPE02 Exists in: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: TRS ETH IF Ethernet statistics counter shows randomly looking values. In fact in hex they are FFFFFFFF or FFFFFFFE. There is also mismatch between counting octets and eth packets. Whole traffic goes through VLAN1001 in the given example. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Performance counter IP---TRS ETH IF---Ethernet statistic, shows huge junk values of the same value but with random frequency.



3.274 Remote MSU download: TargetBD verification failed (current correction level not supported) Problem report: 154178ESPE02 Exists in: iOMS7.0 Correction Target: RL70 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Remote MSU download - Steps:

1. Connect NetAct‐OMS 2. Start tc_sw_mass_da_v5.xml Result: FAILED - TargetBD verification failed occurs when there is a new conversion script published and the original MSU image is used. This issue only occurs when there is a conversion script added in the original MSU Image. Probability: Permanent Solution / Workaround: Before performing Major Software Upgrade via remote operation, if iOMS SW level is R_GOMS6_1.113.1.0 CORR44, fallback to R_GOMS6_1.113.1.0 CORR42 should be performed. Impact to Operator: TargetBD verification failed occurs when there is a new conversion script published and the original MSU image is used.



3.275 After SW upgrade MHAs lost "Not enough HW for LCR" Problem report: NA05788804 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: After SW upgrade of a customer site, some MDDA MHA remains in faulty state. Solution / Workaround: It was necessary to perform a manual commissioning in order to resolve the problem. Impact to Operator: Occasional MDDA MHA remains in faulty state after SW upgrade. Impact to End user: No impact.

3.276 [FSMr2][2G-LTE RF Sharing] Rollback fails from RL70 0.1 to RL70 P8 Problem report: PR038774 Exists in Release: LN7.0 0.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR038774, PR041612, PR043179 Probability: Permanent Description: OM.0710 - RF Sharing - SW Upgrade for an RF sharing setup 1. Upgrade from RL70 P8 (LN7.0_ENB_1407_555_05) to RL70 0.1 (LN7.0_ENB_1407_556_54) on a 2GLTE RF sharing site. 2. Rollback to passive SW is performed. After successful SW upgrade, rollback fails with a message: Rollback failed Reason: Passive SW inconsistency Solution / Workaround: Perform a software update to SW located on passive partition (by choosing TargetBD or .zip and clicking Update button, not by using "Rollback to Passive SW"), exactly like in RL60. Impact to Operator: Time can be wasted by performing failing rollbacks. If Operator will not be informed about workaround, they may not be able to revert to passive SW.

3.277 SW fallback(faultID=4083FSMF) occurred during upgrading to RL70 Problem report: NA05786291 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05786291, NA05788928, PR039205 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 191/330 Version 1.0 Confidential


Probability: Permanent Description: eNBs have manually commissioned MHAs - MHA in use option is used with relevant parameters filled in. MHA and it's gain is therefore enabled and showed as active. In selected configurations SW upgrade fails, fall back procedure triggered, site recovers with previous SW level. Affected configurations are those with more than one MHA without (SN, PC), or combination of one MHA without (SN, PC) with MHA having (PC, SN). Solution / Workaround: No workaround. Impact to Operator: Cells are down with error configuration error: BTS config error (Not enough HW for LCR (1868) Also Passive (current mode) MHAs are all gray in SEM. Except one which is RED (faulty state).

3.278 Replacing a faulty disk in HP Proliant hardware operation do not work Problem report: NA05788077 Exists in Release: RL70_OMS Correction Target: iOMS RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: NA05788077, NA05798091, PR038908 Probability: Permanent Description: Replacing a faulty disk in HP Proliant hardware operation do not work due to faulty disk_change_post script. Disk swap procedure can't be finished. Solution / Workaround: No workaround. If faulty disk need to be replaced and LTE iOMS SW level is iOMS7.0 (CORR29) or older, please contact Nokia support. Impact to Operator: Faulty disk cannot be changed Impact to End user: No impact

3.279 FSMr3 AutoConn - no IP-renewal in VLAN case Problem report: NA05754326 Exists in Release: LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Summary of the original problem: On RL60, the ENB no IP renewal function and SON ENB commission failure How end user/operator could detect the problem: SON test Solution / Workaround: No Workaround LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 192/330 Version 1.0 Confidential


Description of the correction (incl. risk analysis): IP renewal added to ENB SW Impact to Operator: ENB commission failure Impact to End user: No impact

3.280 Increase in UL latency when upgrading from RL60 to RL70 Problem report: NA05785072 Exists in Release: LN7.0 Correction Target: Correction not needed Severity: C - Minor Customer Impact: Attached PRs: NA05785072, NA05786476 Probability: Description: Avg UL Latency(M8001C5) degraded after SW activated to RL70 Solution / Workaround: N/A Impact to Operator: Avg UL performance KPI degraded Impact to End user: Unknown if real UL end user service degraded cause root cause unknown. There isn’t end user impact if it’s only counter behavior change.

3.281 Mismatch of radio module for each Cell ID while RF-diagnosticTest Problem report: NA05774435 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Radio module names are shown incorrectly in the RF diagnostic result report on BTSSM Solution / Workaround: This issue is because SEM uses unit number to match with RF modules to be shown in the RF diagnostic result report which is incorrect. Matching of the RF units should depend on dist-name. So, the implementation using dist-name to match RF unit type had been made in the RF diagnostic report Impact to Operator: End-user might see incorrect data Impact to End user: BTSSM provide non-matched RFM type on each cell ID in RF diagnostic report to the operator using LTE1634



3.282 BTS autonomous reset was occurred suddenly by FID 6706 (DSP crash) Problem report: NA05772383 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Stability Attached PRs: Probability: Permanent Description: After 49 days running time BTS autonomous reset was occurred suddenly on FSMF with FBBx by FID 6706 (DSP crash) and then those sites reset again after 1 hour. Root cause: After 49 days, the roll-over of 32-bit tick counter causes more false event send to Apps EO. And some timers got expired avanced. This make heavy cache invalid/flush operation. Finaly this cause L2 code's assertion error. Solution: After changing the tick counter to 64 bits, and change the expireTimer field to 64bits, roll-over issue will not happen anymore. Solution / Workaround: No Workaround Impact to Operator: Call drop and temporary service outage due to BTS autonomous reset due to DSP crash. Impact to End user: Call drop and temporary service outage

3.283 “Unit autonomous reset as recovery action” alarms Problem report: NA05781566 Exists in Release: LNF7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Capacity & Performance No service due eNB restart. Attached PRs: NA05781566, 123482ESPE01, 155777ESPE02, Probability: Description: Summary of the original problem: crash due releasing non allocated memory. suspected cause mem corruption by timers. How end user/operator could detect the problem: no connectivity Description of the fault: Crash due to releasing non allocated memory. Related feature / functionality: UL resegmentation limiter Solution / Workaround: None Impact to Operator: No service for a while when eNB is restarted Impact to End user: No service for a while when eNB is restarted



3.284 FHCA: Failure in RP3 interface (0010) and cell stays faulty after 1s optical break Problem report: 127315ESPE04 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: FSME+2xchain(2xFHCA) BTS is working onAir without any unexpected alarms with RL70 SW. Optical link break provoked between SM and both chains. After optical link break Failure in optical RP3 interface (0010) appeared, cell stays faulty, occasionally FHCA1.2.2 stays missing (without ping response). Solution / Workaround: No Workaround Impact to Operator: Cell not OnAir Impact to End user: Reduced eNB capacity.

3.285 Slight degradation in the VoLTE/E-RAB Assginment Failure Rate Problem report: NA05772236 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Capacity & Performance Attached PRs: Probability: Permanent Description: In RL70 we noticed an increased E-RAB setup failure(avg from 0.16% to 0.6%) and problem call pattern like below. Call sequence: 1. RRC: rrcConnectionReconfiguration(SRS update) 2. S1AP: E-RABSetupRequest (QCI1) 3. RRC rrcConnectionReconfigurationComplete 4. Internal: ENBC_ID_ALLOCATION_REQ_MSG 5. Internal: ENBC_ID_ALLOCATION_RESP_MSG /*TEID allocation successful 6. S1AP: E-RABSetupResponse(FailedERABList, QCI1, radioNetwork : unspecified) /* actually not only QCI1, I see similar failed setup from QCI7 also. eNB received S1AP E-RABSetupRequest just after RrcConnectionReconfiguration(SRS update), E-RAB Setup Request is held until the ongoing RrcConnectionReconfiguration session Complete, further ENBC allocation successful but somehow E-RABSetupResponse(FailedErablist, RNL : unspecified) raised then. Totally we captured 8 cases that E-RABSetupRequest coming after RrcConnectionReconfiguration(SRS update) and 4 of them failed, means the failure rate of this pattern is 50%. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 195/330 Version 1.0 Confidential


Root cause: Incorrect behavior of baerer manager service. Solution / Workaround: Entry for service UEC_DATA_BEARER_MGR from BehaviourMatrix was removed. After correction TUP_SRB_SEND_RESPONSE message is handled in different service. No Workaround Impact to Operator: Slight degradation in the VoLTE/E-RAB Assginment Failure Rate. Impact to End user: N/A

3.286 FATAL APPLICATION ERROR Nid:0x1251 proc=0x00000021 (EmDispatch) FILE:DlDrb.cpp

Problem report: 60956ESPE05 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Rare one occurrence Description: Summary of the original problem: RlcCoreDl is load balanced, what means that it can come to core4 and flush away our not written back data How end user/operator could detect the problem: DSP crash Related feature / functionality: RlcCoreDl load balancing Solution / Workaround: Description of the correction (incl. risk analysis): caching lines removed Impact to Operator: Unstable eNB, eNB reset may occur Impact to End user: No impact

3.287 LTE1439: Unit autonomous reset (1806) and RACH fail after link break after fiber length change

Problem report: NA05771060 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: 60598ESPE05, NA05771060 Probability: Permanent Description: In case of link break after optical fiber length change RMOD autonomous reset (1806) occurred, causing temporary cell outage. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 196/330 Version 1.0 Confidential


Solution / Workaround: None Impact to Operator: Autonomous reset is avoided. Impact to End user: Can’t get LTE service, no attach possible temporarily to affected cell.

3.288 LN7.0_ENB_1407_554_32 - RF module receives reset request Problem report: 60609ESPE05 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Cells served by radios connected to FBBC are faulty after reset. Attached PRs: 60609ESPE05, 60613ESPE05 Probability: Permanent Description: eNB commissioned and ON-air with 3FHFB/3FRIG/3FRLB and 2 FBBCs When eNB is reset, all cells come on air except the ones with RF Modules connected to port3 of FBBCs. No alarm is generated. Sometimes cells cames up. Solution / Workaround: No Workaround Impact to Operator: Cells related to RF modules connected to Port 3 of FBBC are not operational. Impact to End user: Limited access to radio network due to missing cell at this area.

3.289 Unexpected Drop Call counted during ongoing Rrc Session Problem report: NA05775543 Exists in Release: LN6.0 1.1 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: eNB receiving UEContextReleaseCommand when there is ongoing RrcSesson at eNB side, rather than process UEContextReleaseCommand eNB send UEContextReleaseRequest(RNL:Radon connection with UE lost) after failed RrcSession, which is contributing to M8006C12 and M8006C134 pegged. Solution / Workaround: Rather send UEContextReleaseRequest, eNB shall process the buffered UEContextReleaseCommand from MME after RrcSession failed. Impact to Operator: Drop call increased in KPI measurement Impact to End user: No End User impact.

3.290 RL50FZ - duplicated LNHOW mocs configuration should not be allowed Problem report: NA05786009 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 197/330 Version 1.0 Confidential


Exists in Release: LNF5.0 Correction Target: Correction not needed Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: In RL50FZ it is possible to configure on small cell two identical MOCs for WCDMA cell measurments (LNHOW). As a consequence the content of RRC reconfiguration message is changed and is no more aligned with 3gpp specs. UEs do not reply with RRC reconfiguration complete. Solution / Workaround: Remove duplicated LNHOW managed object. There is a check in RL70 P8 software to detect such misconfiguration and throw an error. Impact to Operator: Low eRAB setup success ratio of around 60% and high eRAB drop rate. Impact to End user: No calls possible.

3.291 Upgrade from RL60 to RL70 (555_05) failed (FBBC configuring) Problem report: 123553ESPE01 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Attached PRs: Probability: Permanent Description: After SW upgrade from RL60 to RL70 (P8 or later) of dual band RFSharing eNB, FBBC stays in ‘configuring’ and radio module connected to FBBC is not detected. Alarm (0010) raised for radio module connected to port 3 of FBBC. Summary of the original problem: After SW upgrade from RL60 to RL70 (P8 or later) of dual band RFSharing eNB, FBBC stays in ‘configuring’ and radio module connected to FBBC is not detected. Alarm (0010) raised for radio module connected to port 3 of FBBC. All cells are faulty. How end user/operator could detect the problem: In BTSSEM, FBBC is yellow, configuring. FXDA 1.1.3.1 not detected. Alarm (0010 Failure in optical RP3 interface for FXDA 1.1.3.1. Description of the fault: CellP’s lim is notified about change of CONNECTOR_L, but it synchronization managers are not aware of that. Related feature / functionality: LTE 435, RF sharing. Dependency on configuration: Occurred ONLY with following RF-Sharing configuration: LTE: FSMF+FBBC +2x FRGS (1/1/1 H 15MHz) + 2x FXDA (1/1/1 H 10 MHz) WCDMA: FSMD+ 2x FRGS (1/1/1 H) + 1x FXDA (1/1/1 X) LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 198/330 Version 1.0 Confidential


Problem visible on 2 test lines only, but permanent on these ones. No real difference to other test lines found. Solution / Workaround: No real workaround. Sometimes it helps to delete files from eNB file system and reset eNB: /flash/config/HWF.xml and /flash/config/hwf.bin.gz Impact to Operator: All cells are down. No calls possible. Impact to End user: No calls possible.

3.292 CL PC can have over- or undershoot of power in certain conditions Problem report: PR035201 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: LTE28 closed loop UL power control for PUSCH could have over- or undershoot in certain conditions. In case of undershoot, this could lead to reduced UL throughput for cell center UEs and degraded KPIs. Solution / Workaround: Description of the correction: When a TPC is sent to the UE, the same correction is applied to the internal filtered power measurements. This leads to a faster convergence of the filtered values to the real measured values and thus avoids the over- or undershoot. The TPC is not applied to the filtered measurements if the UE is power limited and the TPC is positive, as the UE will not apply such an adjustment. Impact to Operator: Lower than expected max. UL throughput in certain conditions. Impact to End user: Lower than expected max. UL throughput in certain conditions.

3.293 ProhibitLBHOTimer(timer temporary blacklisting) doesn’t work during intra-eNB SBHO Problem report: NA05781999 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: During creation of temporary blacklist (after unsuccessful intra-eNB SBHO) incorrect PLMN was used. Instead of get PLMN from CellData common data was used as a source of information. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 199/330 Version 1.0 Confidential


Because of that when next SBHo was triggered cell wasn't considered as blacklisted and handover begins. After correction cell is considered as blacklisted until prohibitLBHOTimere expires. Solution / Workaround: After Intra-eNB SBHo prohibitLBHOTimere need to expire before another handover Impact to Operator: No visible impact Impact to End user: No impact

3.294 eNB transmission interrupted when remote LAN switch port speed/duplex setting as 1000M Problem report: NA05773746 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: 127882ESPE04, NA05773746 Probability: Permanent Description: Optical interface 6 or EIF2 is disconnected when we upgrade from RL60 to RL70. How end user/operator could detect the problem: When the operator performs upgrade the issue is visible. Description of the fault: EIF2 is enabled but traffic is not flowing. Solution / Workaround: Reboot the system Description of the correction: Correction includes proper auto negotiation settings from TRSW to LFS. Impact to Operator: Loss of calls Impact to End user: No backhaul connectivity

3.295 RL70_FHFB hot insertion to 6 cells site is not working till resetting the site Problem report: 156019ESPE02 Exists in Release: LNF5.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: 156019ESPE02, PR034483 Probability: Permanent Description: Summary of the original problem: Detecting FHFB is not working until resetting the site How end user/operator could detect the problem: Hot insertion is not working means that Expansion is not possible till reset the site. Description of the fault: Detecting FHFB is not working until resetting the site . Solution / Workaround: reset the site LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 200/330 Version 1.0 Confidential


Impact to Operator: FHFB is not detected till reset the site Impact to End user: FZM is out of service - calls cannot be made.

3.296 LTE site Beta sector has 100% RACH setup failure rate. sleepy cell Problem report: NA05769933 Exists in Release: LN6.0 1.1 Correction Target: RL60 3.1, RL70 0.2 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: One or a few sectors in eNB had 100% RACH setup failure rate. Permanent UE counter in L2 is inconsistent with real number of permanent UE in MAC_PS and UEC. And also eNB did not handle this error-case correctly, which has caused hanging UE indexes in MAC_PS. Solution / Workaround: eNB reset will temporary recover the situation Impact to Operator: Sleeping cell, RACH_STP_COMPLETIONS dramatically reduced, often to “0” Impact to End user: UE cannot register to Network

3.297 RL70 FSMr3: eNB reboot during ETWS load test: EAaErrorFatality_System Problem report: PR035832 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: User Plane Quality Attached PRs: Probability: Rare one occurrence Description: Summary of the original problem: eNB crashes because of invalid vector element access. Description of the problem Missing exception in cause of invalid QCI tab in function saveBearerInfo. Error occurs only under very rare condition - Cell data reconfiguration which changes QCI tab must occur while executing Initial Context Setup procedure. Note: There is a general solution in discussion which would prevent cell data reconfigurations during running procedures. How end user/operator could detect the problem: eNB crashes. In case of high load (CS signaling and ETWS paging) network operator can see that for short time eNB was not in service. Mobile user cannot use any service during eNB downtime but more critical is that end user cannot receive any ETWS messages afterwards even eNB is back in service. (ETWS = Earthquake LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 201/330 Version 1.0 Confidential


and Tsunami Warning) Description if problem based on certain configuration Not based on certain configuration Solution / Workaround: Description of the correction: Throw exception in case of invalid QCI tab. Impact to Operator: Network operator can see that for short time eNB was not in service. Impact to End user: Mobile user cannot use any service during eNB downtime but more critical is that reception of ETWS messages isn't possible after eNB is in service again.

3.298 DL VoLTE RTP packet dropped by TUPu after two times Intra-Cell HO(TtiBundling activation/deactivation) Problem report: NA05780151 Exists in Release: LN6.0 1.1.3 Correction Target: RL60 3.1, RL70 0.2 Severity: A - Critical Customer Impact: User Plane Quality Attached PRs: Probability: Occasional Description: DL VoLTE RTP packet dropped by TUPu after two times Intra-Cell HO(TtiBundling activation/deactivation). For such case, we see UE first is transitioning to TTI_Bundling ON, and after 1-4 s it is transitioning back to TTI_Bundling Off, then issue starts. All DL VoLTE packet over QCI1 are held and dropped by TUPu. Other DL bearers traffic are ok. and all UL packet including QCi1 is going through well. Root cause: Packets discarded because of unsupported IP version issue are not discarded properly, they are still in queue, but are not sent, so they stuck there. Then when new packets are received timer based discarding mechanism checks timer of oldest packet and because it stucked its timer expires so newest packet is discarded (it is proper behavior that newest packet is discarded by the fact that oldest packets timer expired). Needs to be check why these packets are still in queue and are not dealt with (by discard or sent). Solution: Processing of stucked packets are done properly. All packets in X2 queue are now checked one by one instead of discarding first one and stop processing next ones. Solution / Workaround: No workaround. Description of the correction: Processing of stucked packets are done properly. All packets in X2 queue are now checked one by one instead of discarding first one and stop processing next ones. Impact to Operator: DL VoLTE RTP packet dropped by TUPu after two times Intra-Cell HO(TtiBundling activation/deactivation). Impact to End user: No audio observed sometimes after making VoLTE calls.

3.299 Configuration error (Not enough HW for LCR, cell 1 down ) seen for site



LDA01389B / 63016 Problem report: NA05784445 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: NA05784445, PR035329 Probability: Occasional Description: Site reported NOT ENOUGH HW FOR LCR for ALD device issue and that caused one cell to go down. Creating additional configuration cablnk if there is scannedAntennaInterface not matching either LNA1 and LNA2 Solution / Workaround: In case the problem occurs a site reset is necessary. Impact to Operator: reduced cell availability leading to reduced capacity Impact to End user: reduced cell availability leading to reduced capacity after recommissioning

3.300 RP3 Failure Alarm on FRLB after upgrade to LN7.0_ENB_1407_556_52

Problem report: PR037187 Exists in Release: LN7.0 1.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: PR036706, PR037187 Probability: Rare one occurrence Description: After the SW upgrade from RL70 P7.1 (LN7.0_ENB_1407_551_25) to RL70 P8 PP0.1 (LN7.0_ENB_1407_556_52) with RL60 1.1.3 (LN6.0_EBB_1311_766_10) in the passive bank, one of the FRLB module is not detected. Alarm "Failure in optical RP3 interface (0010)" is raised Related feature / functionality: Problem is associated with feature LTE1745 - Up to 12 optical RF ports for high capacity BTS configurations. Dependency on configuration: The eNB configuration is as follows: FSMF and 2 FBBCs are configured with 2 FRIE (H-type) + 3 FRLB in 3 sector (2x2 MIMO) Carrier aggregation (band 4 + band 12) with bandwidth combination of 10MHz on each FRIE and 5MHz on each FRLB. 2 FRIE's are connected to FSMF and each FRIE's has two 3GB RP3 cables connected (in 15/20 MHz configuration) 1 FRLB connected to port 3 of FBBC1 2 FRLB's connected to ports 2 and 3 of FBBC2 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 203/330 Version 1.0 Confidential


Solution / Workaround: eNB reset through BTS site manager. After the reset all RF modules are up and cells are on Air. Impact to Operator: One out of the three FRLB module is not detected. No data calls on one FRLB. Impact to End user: The RF units remain undetected

3.301 Incorrect parameters in LNREL object

Problem report: NA05777432 Exists in Release: LN6.0 Correction Target: RL70 0.2 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: UE sends invalid ecgi measurement report about the serving cell, It caused eNB to create invalid LNREL which is pointing to its own LNCEL Solution / Workaround: eNB will ignore measurement report from UE with such wrong configuration, no LNREL will be created. Impact to Operator: When doing eNB restart or eNB SW upgrade, invalid LNREL configuration will cause eNB to fail to start. Impact to End user: When doing eNB restart or eNB SW upgrade, invalid LNREL configuration will cause eNB to fail to start, if this happens, UE is not able to attain service from this eNB.

3.302 Cell configuration data distribution failed Problem report: NA05786034 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Cell configuration data distribution failed on 10 cells from 8 eNBs, all cells are recovered by eNB reset. Root cause: An UE starts a reestablishment in the cell which will be deleted shortly thereafter. The UE is unknown in this cell, therefore UEC asks all neighbor cells whether someone knows this UE. While waiting for a feedback from the neighbors the cell deletion starts. During processing of cell deletion the UE which waits for a feedback from neighbors is deleted and indicates that related resources are reset. The fault is that the reset of the UE related resources is done at end of cell deletion message processing and will wrongly reset the cell deletion resources instead of UE related resources, therefore the cell deletion is stopped without sending cell deletion response. Solution: In case of CellDeletion



pending resetService was called for UeManagers and not anymore for CellManager. Solution / Workaround: All cells are recovered by eNB reset. Impact to Operator: Cell configuration data distribution failed Impact to End user: No impact.

3.303 eNB is showing ALD Failure alarms Problem report: NA05786455 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Description: ALD Failure alarms observed against the ALDs connected to the Radio AntennaLine Device Failure alarm (0010) and BTS Time not corrected ( 0026) alarm reported on SiteManager/NetAct. When the time shift happened on BTS, Fake AntennaLine Device Failure alarms are reported even though the ALD devices are functional Solution / Workaround: Perform a BTS Reset Impact to Operator: Device is functional. But user won’t be able to change any ALD device attributes Impact to End user: No impact

3.304 BTS re-commissioning failed due to OAM cannot remove MHA with empty product code and serial number Problem report: NA05786880 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Summary of the original problem: MHA commissioning could fail if one MHA has not one of serial number or product code How end user/operator could detect the problem: user could not remove MHA without one of serial number or product code Description of the fault: commissioning of MHA that has not one of serial number of product code was thought as a faulty configuration Related feature / functionality: commissioning Solution / Workaround: Workaround: setting both serial code and product number solves a problem; other option is to perform full recommissioning Description of the correction (incl. risk analysis): error is not registered if MHA without serial number or LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 205/330 Version 1.0 Confidential


product code is commissioned; in my opinion no risk Impact to Operator: Operator can perform commissioning with MHA that has not one of serial number or product code Impact to End user: N/A

3.305 LTE Conf6 Cell51 remain DISABLED at 15Mhz but works at 10Mhz Problem report: NA05786737 Exists in Release: LN7.0 0.1 Correction Target: RL70 0.2 Severity: A - Critical Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Summary of the original problem: Radio modules were rejecting rp3 routing sent by BTSOM. Description of the problem: RP3 routing calculated by BTSOM was not valid. How end user/operator could detect the problem: At least one cell as not reaching on air. Dependency on configuration: Problem existed only when RF sharing enabled, LTE15 antenna K-type configuration. Solution / Workaround: No workaround possible Impact to Operator: Cell is in disable state, from ims it is visible that routing state -> notRoutable Impact to End user: N/A

3.306 SW fallback(faultID=4083FSMF) occurred during upgrading to RL70 Problem report: NA05786291 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: NA05786291, NA05788928, PR039205 Probability: Permanent Description: eNBs have manually commissioned MHAs - MHA in use option is used with relevant parameters filled in. MHA and it's gain is therefore enabled and showed as active. In selected configurations SW upgrade fails, fall back procedure triggered, site recovers with previous SW level. Affected configurations are those with more than one MHA without (SN, PC), or combination of one MHA without (SN, PC) with MHA having (PC, SN). Solution / Workaround: In the described scenario, BTSOM cannot convert the SCF from RL60 to RL70 correctly. Now that is fixed with SW correction. No feasible WA available. Impact to Operator: Cells are down with error configuration error: BTS config error (Not enough HW for LCR (1868) Also Passive (current mode) MHAs are all gray in SEM. Except one which is RED (faulty LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 206/330 Version 1.0 Confidential


state). Impact to End user: No impact

3.307 High RRC DR Occur after upgraded RL70 MP1.0(LN7.0_ENB_1407_556_04) Problem report: NA05787242 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: CellID converting problem. L2 was converting cell ID from u32 to u16 internally and Cell ID 0xFFFF was handled wrong. Problem was introduced with crash pronto correction RABLTESWFOUL2 Description of the correction: Change PDU Mux data request validity check use Cell active status instead of validity of Cell ID. Also internal Cell ID is changed u16 to u32, to possibility to represent invalid Cell ID. Solution / Workaround: Not configure Cell ID 0xFFFF. Impact to Operator: Cell ID 65535 can't be used with CA. Impact to End user: SCell or PCell trough put will come zero with CA activated Ue.

3.308 LNF7.0:FZM PM Monitoring/missing granularities, GP shift of 1min... Problem report: PR039797 Exists in Release: LNF7.0 Correction Target: RL70 0.2 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: PM reports are occasionally missing or are shifted by 1 minute. Solution / Workaround: No workaround. Impact to Operator: Missing PM counters or PM granularity incorrect. Impact to End user: No end user impact

3.309 ALM7654 RF Module failure (1927FXDA) occurred after upgrade to LN7.0_ENB_1407_557_26 Problem report: NA05789535 Exists in Release: LN7.0 0.2 Correction Target: RL70 Severity: B - Major



Customer Impact: Operation & Maintenance Attached PRs: Probability: Occasional Description: Alarm is reported when condition for level of power reduction is above threshold. In this particular case variable which was responsible for reduction level was not initialized properly. It holds random value. Usually it is 0, but if memory was used before by another variable then it is possible that variable has value different than 0 This happened in this case. Solution / Workaround: no workaround Impact to Operator: smaller range of affected cell Impact to End user: no impact on end user

3.310 RLF triggered HO fail due to wrong MAC header structure of Msg4(RRCConnectionReestablishment) Problem report: NA05789864 Exists in Release: LN7.0 Correction Target: RL70 0.2 Severity: B - Major Customer Impact: Attached PRs: Probability: Permanent Description: Summary of the original problem: Some UE cannot recognize MAC header when LTE1617 feature is enabled. UE call dropped since RRC re-establishment procedure is not completed. How end user/operator could detect the problem: Call drop. Description of the fault: MAC Contention Resolution header is wrong, i.e. 3C 1F, this format is not in the allowed cases specified in 3GPP 36.321 Annex B, which now is normative so UE must follow the information. It cause UE judge resolution and Reestablishment procedure failed. Related feature / functionality: LTE1617: RLF HO Dependency on configuration: LTE1617 is enabled. Solution / Workaround: Workaround: Disable LTE1617. Description of the correction (incl. risk analysis): Fix TBS of 56 bits shall be used if msg4 contains only the UE contention resolution identity MAC CE Impact to Operator: Higher call drop rate and low RRC re-establishment successful rate in case feature LTE1617 is used. Impact to End user: Higher call drop rate and low RRC re-establishment successful rate.



3.311 No Alarm Generated When due to Disabled Cell when configured for Band 4+4 CA. Problem report: 123711ESPE01 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance False alarm(4001) leading to unnecessary Site reset when needed after changing config. Attached PRs: 123711ESPE01, 127604ESPE04, 127824ESPE04, 128256ESPE04 Probability: Permanent Description: During this test instance, customer can see that one of the CA cells remained in “Disabled” state. They already know the root cause for the cell not going “On Air”. The reason being that the cell was configured for a bandwidth combination of 20Mhz + 10 MHz and thus requiring a 6G SFP. However for this cell is actually a 3G SFP installed instead of a 6G SFP. Thus they were expecting a “Configuration error: BTS config error (Not enough HW for LCR)” alarm. However, we can see that no alarm was reported by the BTS Site Manager. Solution / Workaround: The problem in non-reproduce in TS Lab Dallas. Impact to Operator: No alarm reported in BTSSM

3.312 Passive MHA not shown correctly in Site Element Manager view Problem report: 127932ESPE04 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Passive MHAs are not shown correctly in Site Element Manager view. Passive MHAs are shown grey (or missing) and properties produt code and serial number can be seen only. Solution / Workaround: No Workaround Impact to Operator: Passive MHAs are not shows correctly in Site Element Manager view. Impact to End user: No impact

3.313 2xFXEB Shared RF modules connected to LTE FBBC are not completely detected by ESMC Problem report: 121352ESPE01 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: New feature/functionality



Attached PRs: 121352ESPE01, 153410ESPE02 Probability: Permanent Description: LTE/GSM RF Sharing configuration: 2xFXEB Shared (connected to FBBC) 1+1+1 10 MHz H configuration LTE system is up and running. Shared with GSM radio modules are connected to optical ports in FBBC new configuration introduced in RL 70. GSM system is detecting that it has shared radio modules connected to optical ports, but product code, hardware version in site manager are visible as unknown. After commisioning TRXs can't be allocated to radio module. Solution / Workaround: Primary links for shared radios are allowed on FSMF only. Possible secondary link are allowed on FBBC1/2 port #3 (each radio has first link as primary and 2nd link as secondary. If there are 2 links for radios: there are max 2 radios i.e. max 4 ports are required). Impact to Operator: 2G TRX are unavailable when primary links of shared radio modules are connected to FBBC Impact to End user: N/A

3.314 [FRIG+FRLB]：RF module Failure in RP3 interface happened after BTS restart occasionally Problem report: 155631ESPE02 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Attached PRs: Probability: Occasional Description: 1.Test Scenario Steps] With SW LN70_ENB_1407_554_35, the FRLB which connected to FBBC can't be detected after BTS power off and on, it happened occasionally. The HW configuration, FSMF + 2 FBBC, 3 FRIG + 3 FRLB， the FRLB failed to be detected was connected to FBBC With SW LN70_ENB_1407_554_35, the FRLB which connected to FBBC can't be detected after BTS power off and on Summary of the original problem: Problem was with meta mismatch. When reading data from HWF data was misalignment How end user/operator could detect the problem: Unable to detect FRs Description of the fault: System Module was not able to detect FRs because of wrong technology was chosen. Related feature / functionality: No Dependency on configuration: No Workaround: Removing of HWF file Solution / Workaround: Description of the correction (incl. risk analysis): Technology unused in this release was disabled. Impact to Operator: Faults with undetected radios Impact to End user: N/A



3.315 LTE1691: Alarm/notification is not raised when 4RX UL Comp is attempted to be activated without connected extension module Problem report: NA05774444 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: New feature/functionality Attached PRs: Probability: Permanent Description: Basically single FSMF configuration does not support this feature so the feature activation through site manager should be rejected by OAM. But actually OAM does not reject such operation and accept it. Invalid DSP-Cell mapping happens. Dependency on configuration: 4RX UlComp not supported configurations. Root cause: In case of such configuration we will wrongly calculate capacity of baseband units. It will lead to false positive result of our calculation. It will not be possible to reach onAir on all cells. Solution: Correct capacity taken by 4RX Ulcomp. There is no more possibility to calculate overloaded baseband units. Such behavior could occur when baseband modules would be disabled during startup with 4RX ulcomp configured. Solution / Workaround: No Workaround Impact to Operator: Alarm or notification is not raised when 4RX UL Comp is attempted to be activated without connected extension module. Impact to End user: No uplink compression feature available.

3.316 Duplicate ECGI (LNADJL) Error Monitoring Problem report: NA05776037 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: Radio Network/Flexi Multiradio BTS LTE with HW: FSMF, FSME. SW version is RL70 1.1PD. In RL60: We can see ‘Commissioning error alarm’ when an eNB got duplicate ECGI which is located borderto other vendors network. In RL70: There is no alarm in same situation, and cells are disabled. Root cause: Invalid Fault 6252 reporting. Solution / Workaround: No Workaround Solution: Handling of fault 6252 corrected in SysAdapter SW. Impact to Operator: No alarm and cells are disabled in case of Duplicate ECGI (LNADJL) Error Monitoring. Impact to End user: No impact LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 211/330 Version 1.0 Confidential


3.317 [FRIG+FRLB]：FBBC took long time to start up caused RP3 failure alarm after upgrade from RL70 P7.1 to RL70 P8 PP with TMO configuration Problem report: 155954ESPE02 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Attached PRs: Probability: Permanent Description: Summary of the original problem: much longer than allowed startup time after SW upgrade due to unnecessary radio reset caused by switching from local to transparent mode during startup with late radio detection. How end user/operator could detect the problem: By upgrading SW from LN60 to LN70 Description of the fault: With tested configuration radio connected to FBBC has started late. At first attempt to calculate optimal mode of FBBC's linkswitch no radio was detected on port#3 and port it was set in local mode. After that radio was detected and it started synchronization with port being on local mode. Meanwhile second calculation was started with radio already visible and result was linkswitch in transparent mode. During switching from local to transparent mode radio lost connection and was reset. This delayed on Air further. Problem was not observed after first BTS reset (after HWF was generated). Related feature / functionality: Startup without HWF, after sw upgrade. Dependency on configuration: Problem is most likely to be observed if configuration contains FBBC with only one radio connection on optical port#3. Additional conditions are lack of HWF and late detection of radio module (FRLB in this case). Solution / Workaround: Description of the correction (incl. risk analysis): linkswitch on FBBC is always fixed in transparent mode if no radio is detected on any port. Impact to Operator: longer network recovery after sw upgrade. Impact to End user: longer period of lack of network service after sw upgrade (~5 min more than usual).

3.318 Cell is down when serial number added for passive MHA with recommissioning Problem report: 59337ESPE05 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Stability Attached PRs: Probability: Permanent Description: Recommissioning: add serial number for passive MHA connected for cell 1 Cell is down and MHA99 is visible when serial number was added for passive MHA. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 212/330 Version 1.0 Confidential


Serial number is not updated for LNA2. MHA 1 LNA2 is shown as MHA99 after serial number was added for passive MHA. Cell 1 is down after recommissioning (additional reset needed to get cell 1 on Air) BTS is changed to not commissioned, if serial number missing from passive MHA. Solution / Workaround: BTS reset and second recommissioning is needed. Impact to Operator: Serial number is not updated for LNA2. BTS is changed to not commissioned, if serial number missing from passive MHA. Impact to End user: No impact.

3.319 Incorrect RET parameter after SW upgrade from RL60 Problem report: 60374ESPE05 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: 122879ESPE01, 60364ESPE05, 60374ESPE05 Probability: Permanent Description: [1. Test Scenario Steps] RF sharing eNodeB with 2 shared FXFC , 1 FSMF ,1FBBA and 1 ESMC . 6 MHAs connected to FXFC 1.1.1 and FXFC 1.2.3 ANT 1,3,5, 8 chained RETs connected to the MHA which connect to FXFC 1.2.1 ANT5, the cells are all in working state and ALDs are in working state. SW upgrade from LN6.0_ENB_1311_766_10 to LN7.0_ENB_1407_552_70 [2. Fault Description] After the SW upgrade , some RETs got “incorrect parameter” error (antBandList and ant antBeamwidth) in recommission wizard. See the attached error screen snapshot. There is no problem for this with SW upgrade test from RL60 to LN7.0_ENB_1407_551_25, with RL60 or LN7.0_ENB_1407_551_25, for the problem RETs (Andrew RETs) ,those parameters are empty. But with this LN7.0_ENB_1407_552_70, those RET’s 'incorrect parameters” got the value but some of them are out of range. Same problem happened for the SW upgrade test from RL60 to LN7.0_ENB_1407_552_55 Solution / Workaround: No Workaround Impact to Operator: When go through the Reconfiguration commissioning wizard after SW upgrade, first page show “the structure or parameter of the file are not valid “, click the “detailed” button can see some RETs got incorrect additional parameters. Impact to End user: N/A

3.320 RP3 alarm (FRIG Fault 10) Problem report: NA05773535 Exists in Release: LN7.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 213/330 Version 1.0 Confidential


Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: 155330ESPE02, NA05773535 Probability: Occasional Description: Failure in optical RP3 interface raised and cleared (FRIG Fault 10) after RL70 upgrade. Based on the IMS Logs, “NoConnectionToUnit” added to RMOD_L-9/RU_L-1 at Frame 49239, that triggered the alarm Fault 10. Why RMOD_L-9 become undetected and NoconnectionToUnit is added to this RU_L? The alarm cleared automatically after 5 mins. No user activities performed on this site during the issue. Root cause: Radio module was triggering watchdog reset. Radio TX line of UART wasn't changing state after missed interrupt. Which caused infinite loop in our program and watchdog starvation. Solution: When we notice missed interrupt we simply change state of TX line. Solution / Workaround: No Workaround Impact to Operator: Occasional RP3 alarm (FRIG Fault 10) which will be cleared by itself after 5 minutes due to watchdog reset. Impact to End user: No impact

3.321 LTE site in 4G/2G RF-sharing (3xFHEB) doesn't go OnAir with LTE 15MHz antenna configuration Problem report: NA05774419 Exists in Release: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Attached PRs: Probability: Permanent Description: LTE site is StandAlone and then the RF Sharing configuration with 2G configuration is added. The LTE site is arranged with the LTE fiber connected to RF modules (1 fiber each) and without the sync cable between LTE-2G (In this way we are working as LTE standalone) The LTE site if it has the RFSharing flag ON, is not able to go OnAir, instead if we remove that flag all works as expected Root cause: Applying wrong sharing RP3 transmission rules in case of LTE 15MHz antenna configuration Solution / Workaround: No Workaround Impact to Operator: LTE cells not onAir in RF Sharing 4G/2G configuration with LTE 15MHz antenna configuration Impact to End user: N/A



3.322 FSMF - Timing over Packet, phase synchronization, ethernet multicast communication mode not taken as synchronization source Problem report: 155307ESPE02 Exists in: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: eNB doesn't take Timing over Packet, phase synchronization in Ethernet multicast communication mode as synchronization source, even though Master clock state is Operational and Lock status is Locked. On reboot, the alarms are not cleared. Root cause: The TRS internal framework needs a valid IP for multicast mode even though the external interfaces do not define the need of IP. Planned Solution: The TRS internal framework needs a valid IP for multicast mode (even though the external interfaces do not define the need of IP). That is added. Attached PR: 60499ESPE05 Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: ToP phase in Ethernet multicast mode can't be used as synchronization source. Only ToP phase in IP unicast mode or GPS phase can be used for phase synchronization.

3.323 LN6.0 - LN7.0 very long SCFC conversion Problem report: 56414ESPE05 Exists in: LN7.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: When SW Upgrade is done from LN6.0 build to LN7.0 build, configuration file SCFC is converted during startup after upgrade. For large SCFC files such conversion could last over 2.5 minutes (in comparison to 10-20 seconds for relatively small files). Also under tests, BTS state in BTS SiteManager was visible as uncommissioned for a while, despite conversion is ongoing. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: On eNB with big configuration SCFC files, eNB downtime could be about 2 minutes longer during SW Upgrade from RL60 to RL70.

3.324 Status of SSH, display of FTM does not change from the state of Disable Problem report: PR033861 Exists in Release: LNF7.0 Correction Target: RL70 0.2 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 215/330 Version 1.0 Confidential


Severity: C - Minor Customer Impact: Operation & Maintenance Attached PRs: PR033861, PR034901 Probability: Permanent Description: Summary of the original problem: SSH status always shows disabled in webpage Description of the problem: There was a rate limiter that already had a DROP rule in it. Hence the result would always show status as disabled even though session is enabled. How end user/operator could detect the problem: In webpage, even after enabling SSH, status will show as disabled. Solution / Workaround: Description of the correction: DROP checking changed to ACCEPT with small other change. Impact to Operator: SSH status displays correct result in the webpage. Impact to End user: No impact

3.325 GHOST glibc vulnerability Problem report: 121082ESPE01 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Security Description: RL50FZ is currently running glibc 2.17 which is vulnerable to GHOST (CVE2015-0235). GHOST vulnerability can lead to unauthenticated remote exploit. Probability: Permanent Solution/Workaround: No Workaround Impact to operator: GHOST vulnerability can potentially lead to a remote unauthenticated exploit of the BTS.

3.326 FZM counter M8005C208 and M8005C233 is wrongly generated although LTE macro site shows properly Problem report: NA05758421 Attached problem report: 120708ESPE01 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Operation & Maintenance Description: Counters: - M8005C208 RSSI_CELL_PUCCH_MEAN - M8005C233 RSSI_CELL_PUSCH_MEAN are generated as mW unit instated of dBm unit. dBm conversion requirements are not done. Probability: Permanent Solution/Workaround: No Workaround Impact to operator: Values for counters Mean of cell-wide RSSI on PUCCH (M8005C208) and Mean of cell-wide RSSI on PUSCH (M8005C233) are invalid



3.327 FZM stays in RL50FZ after upgrade to RL70 was executed Problem report: 121840ESPE01 Attached problem report: 126027ESPE04 Exists in: LNF5.0 Correction Target: RL70 Severity: A - Critical Customer Impact: Operation & Maintenance Description: In a specific scenario when all below conditions are true:LGF-LTE-RL50FZ-2015-w11 - Page 7/23 © Nokia Solutions and Networks 2015 Version 1.0 Confidential FZM received from factory is with RL70 load - due to customer network requirements FZM is downgraded to RL50FZ - SW upgrade to RL70FZ is done - SW rollback to RL50FZ is triggered (performance of FZM in RL70 is bad, fault discovered etc) - FZM is rebooted during rollback operation (by accident, power outage etc.) When another upgrade to RL70 will be executed, FZM will remain on RL50FZ. Although upgrade will be shown as successful, after reboot FZM will stay with RL50FZ software. Probability: Permanent for described scenario. Solution/Workaround: No Workaround Impact to operator: Second upgrade to RL70 fails. Nokia support needs to be contacted to resolve the problem.

3.328 [FZM][RL50FZ] BTS operational state OnAir instead Configured (with invalid MME IP address). Problem report: 152237ESPE02 Exists in: LNF5.0 Correction Target: RL70 Severity: C – Minor Customer Impact: Operation & Maintenance Description: When operator uses the BTSSM/NetAct to change administrativeState of Cell to locked and some other parameters as part of Reconfiguring the site, administrativeState gets reflected correctly but other parameters changed with the administrativeState doesn’t get reflected in the FZM. So it is required to do the administrativeState of the cell change alone. The other parameters change can be done in the next delta push. Probability: Permanent Solution/Workaround: Perform any configuration changes in an operation separate to changing LNCEL administrativeState. Inconsistency between the NetAct/BTSSM state and actual FZM state can be solved with site reset. Impact to operator: Configuration visible in management tools (NetAct/Site Manager) does not reflect real BTS/FZM settings. Operator is unaware of actual settings until nearest site reset.

3.329 FlexiZone CM Upload Warning for BFDGRP parameter Problem report: NA05721288 Exists in: LNF5.0 Correction Target: RL70 Severity: C – Minor Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 217/330 Version 1.0 Confidential


Description: Parameter BFDGRP is incorrectly constructed because of SW bug in FZM. This results in warning message when CM Upload operation is tried from NetAct for FlexiZone NE, and FZM network id is longer than 2 digits. In such scenario following Java error is shown: "value is too long, db column size: 40, value: MRBTS-XX...X/LNBTS-XX...X/FTM-1/IPNO-1/BFDGRP-1" Probability: Permanent Solution/Workaround: Use numbering from 1 up to 99 for FZM network ID. Impact to operator: Warning message is displayed and CM plan with BFDGRP parameter is not loaded on NetAct

3.330 The difference in value of maxTimeoutCounter between FZM and Macro eNB Problem report: NA05705850 Exists in: LNF5.0 Correction Target: RL70 Severity: C – Minor Customer Impact: Operation & Maintenance Description: Value of parameter maxTimeoutCounter in case of FZM SW is set to 8 whereas in Macro BTS case it is 2. According to BTSOM specification it should be 2 so value 8 is against to those specifications and has to be changed. Probability: Permanent Solution/Workaround: No Workaround Impact to operator: Different behavior of BTSOM supervision mechanism compared to macro (it takes longer for the BTSOM connection to be marked as unavailable)

3.4 POST failure causes additional reset in FZM after SW Fallback from RL70 Problem report: 149346ESPE02 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Operation & Maintenance Description: In case of FZM SW upgrade from RL50FZ to RL70FZM and its failure, FZM will automatically fall back to original SW version (RL50FZ in this case). In such scenario (after FZM successfully rolls back to RL50FZ) a "SW fallback" alarm should appear and there should be no additional site reset afterwards. This generic problem causes additional site reset after successful SW fallback and in turn "SW fallback" alarm is not displayed. Probability: Permanent Solution/Workaround: No Workaround Impact to operator: Operator will not be alarmed in case of SW upgrade failure (RL50FZ - RL70FZ) and successful fallback to RL50FZ. Additional automatic FZM reset is performed.

3.5 ARP Rate Limiting not working as expected Problem report: 114829ESPE01 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Capacity & Performance Description: ARP packets sent at rate above the allowed rate are not dropped. The unit is accepting all arp packets (request+ reply). ipDroppedPacketsRateLimiting counter value doesn't increment. It is always zero. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 218/330 Version 1.0 Confidential


Probability: Permanent Workaround: No Workaround Impact to Operator: Performance of the system can get affected. - ARP and SOAM Rate limiting filter is not getting applied as per SPEC - If the rate limiting doesn’t happen then L2 traffic will be affected. - ARP traffic might consume the bandwidth and other packets flow might go for Toss since the traffic filter is getting applied for Ingress. It might affect 60% of the packet flow if ARP is triggered simultaneously with other traffic.

3.331 Alarm 7651 "GPS receiver alarm not tracking sattelites" is set while GNSS is NOT configured Problem report: 121460ESPE04 Exists in: LNF5.0 Correction Target: RL70 Severity: C – Minor Customer Impact: Operation & Maintenance Description: When FzM is commissioned without GNSS source and ToP is configured as primary synchronization source, FzM goes to onAir after reset, but about 8 minutes from onAir transition following alarm is set:, 15:20:35 | /bts-169 14-09-25 15:20:35 15:20:35 |** ALARM:7651 "BASE STATION OPERATION DEGRADED" 15:20:35 | ACTIVITY=SET 15:20:35 | SEVERITY=MAJOR 15:20:35 | EVENT_TIME=04-01-01 01:00:30 SEQUENCE=21 15:20:35 | EVENT_TYPE="Equipment Failure" 15:20:35 | ALARM_TEXT="BTS reference clock missing: GPS receiver alarm: not tracking satellites" 15:20:35 | ADDITIONAL_INFO="additionalFaultId3080/additionalFaultId" Probability: Permanent Solution/Workaround: Wait till all alarms with clear hysteresis aren't set or cleared, and then disable the sync source. Impact to Operator: Operator will see an alarm related to disabled sync source, when the disabling operation will be triggered while alarm was in CLEARING state.

3.332 FlexiZone integration issues - UE can't camp into LNCEL Problem report: NA05716571 Exists in: LNF5.0 Correction Target: RL70 Severity: C – Minor Customer Impact: User Plane Quality Description: FZM is on-air but UE is unable to camp to the cell, when Synchronous Ethernet EIF2 is configured timing source and EIF2 as a primary backhaul interface. UE is able to camp and make data calls when GPS or ToP is configured as a synch method. Attached PR: NA05784808



robability: Permanent Solution/Workaround: Configure GPS/ToP as a sync source or use EIF1 as backhaul. Impact to Operator: UEs are not able to camp to the cell.

3.333 U-plane not working for dedicated IPSec configuration Problem report: NA05720296 Exists in: LNF5.0 Correction Target: RL70 Severity: C – Minor Customer Impact: User Plane Quality Description: For dedicated customer IPSec configuration with protect policy configured as any-any type, User-plane is not working. GTPU packets are being incorrectly dropped by IPsec policy check mechanism. Probability: Permanent Workaround: Reconfigure IPsec policy to "network/host-network/host" type policy. Impact to Operator: No user plane IP packets are leaving FZM interface - user plane not working.

3.334 FlexiZoneMicro start up takes longer time Problem report: 113529ESPE01 Attached problem report: 115613ESPE01 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Operation & Maintenance Description: FZM Product Definition says FZM with file based provisioning should become operational within around 4 minutes. In some situations system startup takes around one minute longer which extends total downtime to around 5 to 6 minutes. Probability: Occasional Workaround: No workaround Impact to customer: Around 1 minute longer time is needed for system startup, until FZM will become operational.

3.335 eNB does not sent UE Context Release Request when received GTP-U Error Indication Problem report: NA05719120 Exists in: LNF5.0



Correction Target: RL70 Severity: B – Major Customer Impact: User Plane Quality Description: eNB does not sent S1AP UE Context Release Request when received GTP-U Error Indication from SGW. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: If the eNodeB receives a GTP error indication from the SGW over an S1-U tunnel not doing indirect forwarding, it shall initiate the E-RAB Release procedure and immediately locally release the E-RAB (i.e. without waiting for a response from the MME). Because of this bug UE context is not released on eNodeB and remain as active.

3.336 NetAct8 EP1 - RL50FZ Build_163_00 - Activating Cell trace fails on FzM, generates a connectivity alarm Problem report: 114982ESPE01 Attached problem report: 142738ESPE02; 145001ESPE02; NA05722697 Exists in: LNF5.0 Correction Target: RL70 Severity: B - Major Customer Impact: Operation & Maintenance Description: NetAct8 EP1 - RL50FZ Build_163_00 - Activating Cell trace fails on FzM, generates a connectivity alarm Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: Unable to activate Cell Trace

3.337 FzM LTE eNodeB: AutoNegotiate on Fiber Not Working Problem report: NA05707118 Exists in: LNF5.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Fiber backhaul links (BH1) do not come up in case Auto-negotiation is enabled on switch port. Probability: Permanent for specific switch models (eg. C3560, Alcatel-Lucent 7705 SAR-M,Cisco 3750X). Solution/Workaround: Disable speed/duplex auto-negotiation on switch port if problem occurs.



Impact to Operator: FZM LTE eNB cannot be integrated to the core network. Switch's optical ethernet port link towards FZM is down. Alarm "7656 Base station connectivity lost Transport layer connection failure in S1 interface" is active in FZM.

3.338 [X21-MBB] Synchronization alarms are present even after the eNodeB is on Air Problem report: 115489ESPE01 Exists in: LNF5.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: FREQUENCY_JUMP alarm set for the case when FZM stands up using calibration file and no other synchronization source (ToP, GPS) is available at that moment. The alarm basically means that FZM lost synchronization, which is not true. Although the alarm is set, site goes onAir and call processing is not affected. The alarm is cleared when GPS or ToP goes into good state. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: Operator will see FREQUENCY_JUMP alarm set while site is onAir using calibration file.

3.339 TRS Alarm Canceled when OMS Upload Problem report: NA05671346 Exists in: LNF5.0 Correction Target: RL70 Severity: C – Minor Customer Impact: Operation & Maintenance Description: Active TRS alarms are cancelled and raised again when Alarm Upload is triggered from NetAct. It is due to the fact that BTSOM is sending a space character in one of the fields in Transport alarm observation. OMS treats alarms with white space different than the existing ones are hence clears the old ones and raises them again. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: It gives false information to the operator that the alarms are cleared at the FZM and raised again.

3.340 LNFZ5.0_BTSSM_1309_035_00 allows to set lower values for Upper thresholds than for Lower thresholds Problem report: 86381ESPE03 Exists in: LNF5.0 Correction Target: RL70



Severity: B – Major Customer Impact: Operation & Maintenance Description: BTSSM released with RL50 FZ P8 allows to set the following values: ulpcUplevSch less than ulpcLowlevSch ulpcUpQualSch less than ulpcLowQualSch ulpcUplevCch less than ulpcLowlevCch ulpcUpQualCch less than ulpcLowQualCch PDDB for these parameters contains following restrictions: ulpcUplevSch greater or equal to ulpcLowlevSch ulpcUpQualSch greater or equal to ulpcLowQualSch ulpcUplevCch greater or equal to ulpcLowlevCch ulpcUpQualCch greater or equal to ulpcLowQualCch Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: No error message when the value of the parameters passed the restrictions.

3.341 TRSW takes on ARM Linux have potential memory leaks Problem report: 117929ESPE04 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Capacity & Performance Description: Potential memory leak issue. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: Operator will observe the Memory leak when the system is running with/or 100UEs with maximum UL and DL t-put over UDP and may lead to Reset/Crash in the FZM board if run for longer days. Lab analysis indicates the FZM board will support continuous operation for approximately one year from last reset until another reset is required due to out of memory condition.

3.342 FZM: FATAL EXCEPTION Nid:0x1234 TYPE:EXTERNAL:[0xEA7C]CpuL2MemoryProtectionFault Violated memory add Problem report: 52324ESPE05 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Capacity & Performance Description: A site reset occurs when a high load is performed.



Probability: One Occurrence Solution/Workaround: No Workaround Impact to Operator: On a 20 MHz Site, when the customer is performing High Load; ( 280 X2 handover ues; - 180 UDP UL ues (34 Mbits/s); - 180 UDP DL ues (120 Mbits/s); - 30 UDP_UL QCI1 ues; - 25 TAU ues; - fake pagings; Customer is likely to experience the FZM Reset (Loss of Service ); It was seen on sites running continuous high load after approx 3 days.; The site resets, restoring it back to normalcy.

3.343 BMgrexe and other like BStatexe, RP1Aexe, BMAexe ARM tasks have potential memory leak issue Problem report: 52371ESPE05 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Capacity & Performance Description: Potential memory leak issue. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: Operator will observe the Memory leak when the system is running with/or 100UEs with maximum UL and DL t-put over UDP and may lead to Reset/Crash in the FZM board if run for longer days. Lab analysis indicates the FZM board will support continuous operation for approximately one year from last reset until another reset is required due to out of memory condition.

3.344 FZM may become inaccessible over EIF1 backhaul when Ethernet switching is turned on and EIF2 is disabled Problem report: 50985ESPE05 Exists in: LNF5.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: FZM may become inaccessible over backhaul when Ethernet switching is turned on and nonprimary backhaul EIF port is disabled (locked) and next enabled (unlocked). Probability: Permanent Solution/Workaround: Do not disable (lock) non-primary EIF when Ethernet switching is enabled. For recovery, perform reset of the site. Impact to Operator: S1 link goes down, communication b/w eNode-B and Core Network will be lost.

3.345 BTS commissioning reconfigure fails when the sync state in unsynchronized Problem report: 110790ESPE01 Exists in: LNF5.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: When the site is in BTS commissioned state and still acquiring the synchronization the commissioning is blocked from BTSSM. Probability: Permanent Solution/Workaround: No Workaround LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 224/330 Version 1.0 Confidential


Impact to Operator: At the BTS startup time, while the clock is not acquired via GPS or sync method, operator will not be able to change any parameters using BTSSM or NetAct. The operator will have to wait until the clock is acquired. If the sync source is miss-configured, the operator will have to re-commission the BTS from scratch.

3.346 Discrepancy between hardware clock that counts power up time and Linux monotonic clock Problem report: 111568ESPE01 Exists in: LNF5.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Site initialization takes longer, 119 minutes instead of 75 minutes, when no sync source is present. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: There is a valid calibration file, but no valid sync source. The time it takes for FZM to get in sync and come up on air is longer than 75 minutes as per requirement. In this particular case, it takes 119 minutes.

3.347 1-58494071 : [MBB-X13]-LTE692- Codenomicon: EM connection issue and interface reachability issue Problem report: 46655ESPE05 Exists in: LNF5.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: One of the Codemonicon IPv4 suite test cases disables the FZ AP Ethernet interface. Test case is 41750LGF-LTE-RL50FZ-2015-w11 - Page 17/23 © Nokia Solutions and Networks 2015 Version 1.0 Confidential Probability: Permanent Solution/Workaround: Customers should not run the Codenomicon IPv4 test suite. For recovery, reset the FZ AP. Impact to Operator: Codenomicon IPv4 test suite will disable the FZ AP Ethernet interface.

3.348 FZM SW version’s HW unit displayed FWGH despite FWGB in Site Information Problem report: NA05677418 Exists in: LNF5.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: SW version's HW unit displayed incorrectly Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: The customer will see the HW unit as FWGH in BTSSM’s site Information screen instead of the correct hardware unit



3.349 Arm CPU1 Starvation; load ~100% with IPSec Problem report: 52875ESPE05 Exists in: LNF5.0 Correction Target: RL70 Severity: B – Major Customer Impact: Capacity & Performance Description: During testing with IPSEC, it was observed that a max t-put with packet size = 431Bytes causes ARM CPU1 starvation and reboot or S1 drop. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: An unexpected reset will occur.

3.350 Cell down after ToP server restart Problem report: NA05683175 Exists in: LNF5.0 Corrected in: RL50FZ 0.2 Severity: B – Major Customer Impact: Operation & Maintenance Description: FZM uses only one synchronization source - TOP. After ToP server restart FZM goes to holdover mode but when it expires FZM lost sync. ToP server restart results in discontinuity of time delivered by it on when FZM is not ready. Probability: Occasional Solution/Workaround: Disable/ Enable of ToP Slave (checkbox for “In use” : Unchecked -> Send -> Checked -> Send) Impact to Operator: All of UEs on cells cannot attach to the cell because of cell down. Top Clock Tuning Failure (4186) is detected.

3.351 Bash Environment Variable Handling Code Injection (Shellshock) Problem report: 121395ESPE04 Exists in: LNF5.0 Corrected in: RL50FZ 0.2 Severity: A - critical Customer Impact: Security Description: FZMs are vulnerable to the Bash Shellshock bug, CVE-2014-6271, CVE-2014-7169 which is present in Bash 4.3. Code can be executed without the user's intent by setting an environment variable. An attacker may use this to execute code remotely on attacked machine. Shellshock is rated CVSS 10/10.; The vulnerability is remotely exploitable against the FZM’s cgi service. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: Code can be executed without the user's intent by setting an environment variable. An attacker may use this to execute code remotely on attacked machine.

3.352 ETWS test fail Problem report: NA05719993 Exists in: LNF5.0 Corrected in: RL50FZ 0.2 Severity: A – Critical Customer Impact: Capacity & Performance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 226/330 Version 1.0 Confidential


Description: Occasionally UE cannot catch ETWS message. Root cause: A problem with MAC PS internal array for storing the BCCH Modification Paging occurs during high load of ETWS paging request coming from C-Plane plus additional high BCCH Mod Paging load. b Occasionally Solution / Workaround: No Workaround Impact to Operator: UE cannot catch ETWS message.

3.353 SON - Auto connection does not work Problem report: NA05717831 Attached problem report: NA05737495 Exists in: LNF5.0 Corrected in: RL50FZ 0.2 Severity: C – Minor Customer Impact: Operation & Maintenance Description: In case network elements involved during FZM auto connection (iOMS, IPsec gateway, CA/CMP server) have IP address with octet "38", auto-connection will fail. ASCII number 38 is incorrectly handled and not being decoded properly. Probability: Permanent Workaround: Reconfigure network element IP address so it does not have "38" Impact to Operator: SON feature - autoconnection will fail and whole Plug and play procedure will not continue.

3.354 FlexiZone no PM data with Secure O&M Problem report: NA05730696 Exists in: LNF5.0 Corrected in: RL50FZ 0.2 Severity: A - Critical Customer Impact: Operation & Maintenance Description: FlexiZone is not able to deliver PM data (notify iOMS with FileLoadPrepare message) in case Secure O&M is used (TLS mode set to "Forced"). Probability: Permanent Solution/Workaround: Disable TLS - set TLS mode to "Off" Impact to operator: No performance measurements are delivered to iOMS/NetAct, impossible to monitor KPIs from FlexiZone Micro.

3.355 Sleeping cell Problem report: NA05702426



Attached problem report: NA05705886 Exists in: LNF5.0 Corrected in: RL50FZ 0.2 Severity: C – Minor Customer Impact: Capacity & Performance Description: Cell has no DL traffic to UE The FFTC pop errors occurring in DL PHY are a result of the DL PHY process in the DSP being blocked for a significant number of CPU cycles (i.e. – stalls). When this happens, the CELL “sleeps”, that is no more traffic in Downlink over the air occurs, since the last symbol send out in on the air is stuck in the FFTC. Probability: Occasional Solution/Workaround: No Workaround Impact to operator: No signal on air. The CELL “sleeps” may occur that is no more traffic in Downlink over the air.

3.356 RL50: SW upgrade from one load to the same should not be processed Problem report: 118221ESPE04 Exists in: LNF5.0 Corrected in: RL50FZ 0.1 Severity: C – Minor Customer Impact: Stability Description: Upgrading to the same SW releases causes loss of commissioning. Probability: Permanent Solution/Workaround: For the lost commissioning case, avoid upgrading to the same release. Impact to Operator: Commissioning data gets lost after the same SW release goes through upgrade. As a result, manual re commission and an additional reboot is required.

3.357 RL50 Flexi Zone: VSWR alarm active for some sites- the sites are not on-air Problem report: NA05685936 Exists in: LNF5.0 Corrected in: RL50FZ 0.1 Severity: B – Major Customer Impact: Operation & Maintenance Description: FZM became disabled due to a VSWR High alarm being falsely triggered due to too low of a VSWR threshold being used. Probability: Occasional Solution/Workaround: The customer should not set any VSWR threshold value. The threshold is hardcoded to ensure there will be no false alarms detected by the FZM. Any configuration changes will be overwritten by the hardcoded value. Impact to Operator: The system does not allow the operator to properly set the threshold for VSWR major fault (1837). The FZM product has a pass / fail VSWR threshold that should not be set by the customer but the product is not implemented that way. The recovery action of this fault will result in the disabling of cell leading to loss of service. In order to clear the alarm, operator has to manually reset the site. However, this doesn’t ensure that the same high VSWR condition will not be detected again.

3.358 Cell doesn't get disabled when VSWR major alarm is raised Problem report: 85615ESPE03 Exists in: LNF5.0 Corrected in: RL50FZ 0.1 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 228/330 Version 1.0 Confidential


Severity: C – Minor Customer Impact: Operation & Maintenance Description: In case when lCellId is not equal to 1, appearance of VSWR major alarm does not cause cell to be automatically locked. In spite of measured VSWR is above major alarm threshold and the alarm is raised the cell stays on-air. Probability: Permanent Solution/Workaround: If possible, set lCellId to 1. If lCellId is not equal to 1 and problem occurs: manually lock the cell when major VSWR alarm appears. After fixing the root cause of an alarm, reset FZM. Impact to Operator: May result in throughput/quality degradation. Additional tasks are required to be performed by operator.

3.359 Auto Config / Auto Connection fails to properly commission TRS. Problem report: 146040ESPE02 Attached problem report: NA05704730 Exists in: LNF5.0 Corrected in: RL50FZ 0.1 Severity: B – Major Customer Impact: Operation & Maintenance Description: Two issues related to the same SW fault: * AutoConfig / AutoConnect fails, leaving the TRS in 'not Commissioned' state. * Template re-commissioning does not work for BTSID in TRS config. TRS generates an unnecessary backup file, before sending a response to modify state request received from BTSOM. This file generation takes long time and FZM reboot is triggered before the modify state response is sent; hence the config file is not marked for activation. Probability: Permanent Solution/Workaround: No Workaround Impact to Operator: AutoConfig / AutoConnect and TRS recommissioning does not work for FZM.

3.360 RP3 routing collisions are detected on FR module (1958) Problem report: 122094ESPE01 Exists in Release: LN6.0 3.0 Correction Target: Correction Not Needed Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Transmission rules affect collision between LTE and GSM transmission. Solution / Workaround: Change link speed from 6G to 3g or not use 20Mhz BW in current configuration. Impact to Operator: Possible sleeping cell, Maximum throughput is lower than expected. Impact to End user: Maximum throughput is lower than expected. Slower data transfer



3.361 'TX failure in MIMO” appears and clears after SW downgrade from RL70 to RL60. Problem report: 59894ESPE05 Exists in Release: LN6.0 0.1.3 Correction Target: RL70 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Summary of the original problem: Unexpected “TX failure in MIMO” alarm appears and clears after SW downgrade from RL70 to RL60. How end user/operator could detect the problem (How Operator can see the problem?): Unexpected “TX failure in MIMO” alarm appears and clears after SW downgrade from RL70 to RL60. Description of the fault: Unexpected fault (4003) - 'TX failure in MIMO' was raised after SW downgrade from RL70 to RL60 (rollback), and cancels out when cells gone on air. Solution / Workaround: Solution / Workaround: No Impact to Operator: Impact to Operator: Unexpected alarm raised during SW downgrade from RL70 to RL60 and cancels out when cells gone on air.

3.362 RL60 Acceptance HW Inventory Name FYGA Problem report: NA05751083 Exists in Release: LN6.0 1.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Probability: Permanent Description: After exchange of FYGA to FYGB (successor product) the old HW inventory name (FYGA) is shown in O&M tools (BTSSM and NetAct) to old product code recognition the instead of FYGB. The HW name of the new module is not update accordingly in BTSSM and Netact in RL60, when the FYGB has been already official released Solution / Workaround: No workaround Impact to Operator: Wrong HW type is displayed in the maintenance tools like BTSSM and Netact. No KPIs are affected



3.363 Cell Configuration data distribution failed FDD Problem report: NA05753025 Exists in Release: LN6.0 1.1 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: Many eNBs have Cell Configuration data distribution failed alarm (6253) in network. Main problem is that Cell Deactivation can't be finished and in result eNB will have unavailable cells. Problem may occur when cell deactivation is triggered when there is ongoing S1 Setup. Cell Deactivation triggers S1 Partial Reset which used to inform MME about UEs which will be dropped due to Cell Deactivation. In scenario where there is already ongoing S1 Setup then such trigger is ignored because UEs are already released or are during release operation. Main problem is that state machine responsible for Cell States Handling is not informed that S1 Partial Reset is not needed. In result it is still waiting for information about result of S1 Partial Reset (that S1 Partial Reset is finished or that S1 Partial reset wasn’t necessary). Solution / Workaround: The workaround is by Increasing s1InducedCellDeactDelayTime timer to 30s. Solution: When Cell Deactivation is triggered during ongoing S1 Setup procedure, S1 Partial Reset trigger is now ignored and Cell Deactivation is finished immediately. Impact to Operator: Cell Deactivation can't be finished and in result eNb will have unavailable cells

3.364 FSMF generating IP packet with 16 bytes less than defined in MTU Problem report: NA05753365 Exists in Release: LN6.0 Correction Target: RL70 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Some tests, involving the use of jumbo frames, have been performed to find out the most adequate MTU value. Tests gave a not expected behavior in this scenario: The UDP traffic in UL tests are showing a different behavior in fragmentation between eNB types: FSME&FTLB, with MTU 1560, in case of fragmentation the eNB generates IPpackets (IPsec enabled) of 1560bytes (1st fragment) FSMF&FTIF, with MTU 1560, in case of fragmentation the eNB generates IPpackets (IPsec enabled) of 1544bytes (1st fragment) LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 231/330 Version 1.0 Confidential


MTU=1576 tested and gave the same not expected behaviour. Empirically we have seen those 16bytes difference. Solution / Workaround: No workaround Impact to Operator: FSMF fragmentation constant with FSME/FTLB

3.365 RF module failure with fault code 1910 Problem report: NA05754005 Exists in Release: LN6.0 Correction Target: RL70 0.1 Severity: B - Major Customer Impact: Stability Attached PRs: 123096ESPE01, NA05754005 Probability: Occasional Description: Occasional RF module failure alarm with fault code 1910 has been encountered. When operating under very high VSWR conditions, the latest Grentech firmware (version 1CB3) produces a false Low Power Alarm. Root cause: Not enough power samples for averaging may lead to false VSWR alarm. Solution: Increase the measurement cycle time to allow more Forward and Reverse power samples to be accumulated for averaging. Solution / Workaround: No Workaround Impact to Operator: Unnecessary Low Power Alarms 1910 for Vegas RF modules. Impact to End user: No impact

3.366 Fault RF Module failure (1907) with fault id 3010 seen after SW upgrade Problem report: NA05756181 Exists in Release: LN6.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Occasional Description: After SW upgrade there is seen ~24 alarms. One week before the upgrade there were seen 2 alarms. RF Module failure (1907) faults are coming from FRLB with supplementary information 3010. Based on the alarm history some sites (3) are having repeating occurrences of this alarm. However there are new sites that are reporting the alarm. Example of one alarm: 7654 CELL OPERATION DEGRADED/RF module failure, fault ID 3010. Root cause: SW detect improper signal quality (degraded) on feedback path after PA (Power Amplifier). LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 232/330 Version 1.0 Confidential


Solution: The SW correction consists of a change where drive strength parameters of PA were adjusted to stabilize 20W operation. Solution / Workaround: No Workaround Impact to Operator: More than usual fault RF Module failure (1907) with fault id 3010 seen after SW upgrade.

3.367 Fault 6259 triggered when setting antennaRoundTripDelay to a high value and when using a radio Module FRHC Problem report: NA05761986 Exists in Release: LN6.0 0.1, LN7.0 Correction Target: RL70 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: With 6 pipe RF Module and actDistributedSite' = true some settings are causing RF Module Failure: 035000ns - OK & 037500ns - OK 039000ns - NOT OK & 040000ns - NOT OK & 450775ns - NOT OK. RF SW rejects configuration because timing parameters didn’t match: systemDelay = 343958 suggest that distance from SM to FRM is in range 31..44km while linkDelay = 12 tells that distance from SM to FRM is ~2m. Current FRM3.0 Timing Calculation Specification doesn't address this case. TC spec. needs to be updated and timing verification for related parameters removed from SW. Root cause: Problem happens due to not acknowledged request for uplink carrier creation by radio module. Before carrier is created FRM checks timing parameters provided by SM. This is needed as radio has limited buffering capabilities. There was an error in equation used to verify timing parameters – external delay latency was not used. Solution: After correcting the function used to verify timings parameters by adding required ‘external delay latency’ into equation the request for uplink carrier creation is accepted. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: If Radio Module FRHC is used, fault 6259 triggered when setting antennaRoundTripDelay to a high value. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 233/330 Version 1.0 Confidential


3.368 Alarm 'Techn.log buffer freezing' combined with 'unit auto.reset' Problem report: NA05765784 Exists in Release: LN6.0, LN7.0 Correction Target: RL70 Severity: C - Minor Customer Impact: Stability Probability: Occasional Description: In customer network has occurred the alarm 'technical log buffer freezing' and it led to unit autonomous reset as recovery action of FSME. Root cause: The issue happens during PDCP discard timer handling but the weird thing about it is that it happens when our SoC is idling. There should be no discard timers running at all. Solution: TUPu has a timer database which is in the form of linked list and it manages aging of each PDCP SDUs in buffer. Pointer to SDU descriptor is also located in the timer database together with the timer value. The timer maintained by the database corresponds to the 'SDU discard timer'. In the very beginning of a routine for discarding of PDCP SDUs which has expired, there is validation check which validates the pointer to PDCP SDU descriptor. The crash is result of an assert when the pointer is being checked to be null or not. In the fix we have removed that assert and replaced it by a regular 'if' statement. Solution / Workaround: No Workaround Impact to Operator: Alarm 'technical log buffer freezing' occur and it led to unit autonomous reset as recovery action of FSME.

3.369 Unexpected Drop Call counted during S1 Handover Cancel procedure Problem report: NA05765945 Exists in Release: LN6.0 1.1.2, LN7.0 Correction Target: RL70 1.0 Severity: B - Major Customer Impact: Capacity & Performance Probability: Permanent Description: VoLTE drop call rate is high in case S1 HO cancelled due to UE RrcReestablishment, but actually the VoLTE call does not drop from user p.o.v. 1. During S1 HO procedure, UE is failed in accessing target cell for some reason and performs RrcReestablishment back to source eNB. 2. Source eNB sends HO_Cancel(reason = RNL, unspecified) to MME. 3. MME relays the “reason =RNL, unspecified” and releases the target eNB resources by S1AP UEContextReleaseCommand. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 234/330 Version 1.0 Confidential


4. Target eNB receives S1AP UEContextReleaseCommand(reason = RNL, unspecified) and got drop call counter M8006C107 and M8006C8 pegged. This S1 HO_Cancel sequence triggered drop call counted in KPI but actually the terminal user does not perceive any drop call, just a short interruption in user plane and voice resume after that UE RrcReestablishment procedure. We know the similar Handover_Cancel scenario due to UE RrcReestablishment can happen in X2 HO procedure also, but the X2 case does not contribute to any drop call counter. This push us to align the X2 and S1 counter behavior and remove the HO cancel(due to UE Reestablishment) from our drop call counter(M8006C107/M8006C8). E-RAB release counters shall not be pegged in the described scenario since there haven't been any ERAB established because the UE doesn't get 'RRC-Connected' in the target cell. Root cause: During target HO on receiving S1AP Connection Release Command we should not increment counter when RRC Connection Complete from this UE was never received in eNb. Solution: Special check is performed before incrementing bearer release counters. Solution / Workaround: No Workaround Impact to Operator: Unexpected Drop Call counted during S1 Handover Cancel procedure.

3.370 GSM-LTE RF sharing: Increased BER detected on the optical connection to Radio Module (1955) alarm Problem report: NA05765992 Exists in Release: LN6.0 1.1 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Stability Probability: Occasional Description: Increased BER detected on the optical connection to Radio Module (1955) alarm from the LTE base stations running with the RF sharing in the 1800 MHz RRH FHEA. The problem appears when the LTE cell is in unlocked state, meanwhile when the LTE cell is locked the GSM cell returns to the normal operation. Example for such a major alarm: Code 7654, 'Increased BER detected on the optical connection to Radio Module (1955)', 'Local cell operation degraded'. Root cause: Increased BER in this case is caused by buffer underflow interruption raised by RF hardware. Meaning of this interrupt is that there is not enough data available at the input of radio part. Direct reason for this interrupt was routing collisions. Data was colliding and because of that it was not routed, not reaching its destination. Data collisions were caused by timing shift in RF router (murkku). This was caused by the hardware issue connected with pi (downlink) alignment procedure when clock link change to different system module. Problem does not appear when changing clock for a different link from the same system module. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 235/330 Version 1.0 Confidential


Solution: Workaround for pi alignment procedure was implemented. Initial downlink pi setting is applied before starting re synchronization of the new clock source link. Solution / Workaround: No workaround For the solution in RL60 SW release please contact the responsible Technical Support team. Impact to Operator: GSM cell not possible to carry traffic.

3.371 Counters of the family M51137C* ( top Freq Sync Error ) have values out of range in FSMF HW after RL50_2.1 SW Upgrade Problem report: NA05767877 Exists in Release: LN5.0 2.1, LN 6.0 Correction Target: RL70 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Probability: Permanent Description: We just started the RL50_2.1 Software Upgrade in our network, and afther active the RL50_2.1 we observe the following behavior in TOP services. Only in a FSMF HW in some moments the value of the counter of the family M51137C its very large, and have a kind of sequence. I suspect of some SW issue because of you observe the other counters below they have a properly value. 1- topRxFreqSyncMsg (M51137C0)--[packet] - Description: The number of received ToP frequency synchronisation event messages. Event messages are time stamped and used for clock recovery. It means I received the properly number of SYNC menssages of the Master Clock. 2- M51137C4 / topFreqSyncSLS - Description: The number of seconds during this interval while the timing over packet frequency synchronization service was in locked state. I means the eND was synchronized during all of the time with TOP Sync Resource; If we had a large deviation according the counter value , the eND will change your sync resource to internal sync. Another observation is the value of the topMinFreqSyncError it´s must to be lower to than topMaxFreqSyncError, but if you observe our site , the value of the topMaxFreqSyncError some times is lower than the topMinFreqSyncError. Solution / Workaround: No Workaround For the solution in RL60 SW release please contact the responsible Technical Support team. Impact to Operator: Counters of the family M51137C* ( top Freq Sync Error ) have values out of range in FSMF HW.



3.372 No Cell trace send to NetAct with iOMS 71108 alarms Problem report: NA05745993 Exists in Release: iOMS6.0 Correction Target: RL70 P8 Severity: B - Major Customer Impact: Operation & Maintenance Probability: Permanent Description: Calls are not counted in Trace Viewer application on NetAct. Trace Viewer is no longer good for analysis incoming calls. iOMS is connected to NetAct correctly, but response from NetAct is CORBA::OBJECT_NOT_EXIST. It appears that NetAct Corba object is non-existent. This is used by TraceReceiver to notify NetAct from OMS. All notification attempts were unsuccessful because of this. First connection attempt to TraceViewer (NetAct) from OMS was unsuccessful and succeeding connection attempts weren't successful either. Root cause: Failure in registering to NWI3Adapter. Solution: Corba reconnection mechanism was enhanced so this problem will not occur. Solution / Workaround: No workaround Impact to Operator: Calls are not counted in Trace Viewer application on NetAct. Trace Viewer is no longer good for analysis incoming calls.

3.373 SM Missing requirement for max number of possible AaTestPort instances” for features LTE163 (Subscriber and Equipment Trace)/ LTE433 (Basic Cell Trace)/ LTE1049 (Logged MDT) Problem report: 121943ESPE04 Exists in: LN6.0 Correction target: RL70 P8 Severity: B - Major Customer Impact: Operation & Maintenance Description: Missing requirement for max number of possible AaTestPort instances How end user/operator could detect the problem: CC&S has restriction for simultaneous testport connections adjusted to 15. This is not enough due to the requirement on EFS level (Testability) for LTE1049. It should be specified and aligned with SFS requirements. Related feature / functionality: LTE163, LTE433, LTE1049 Description of the correction (incl. risk analysis): CC&S AaTestPort needs to support 40 tcp client instances simultaneously. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Limitation with max number of possible AaTestPort

3.374 Cannot connect LegacyBTS by BTSSiteBrowser Problem report: NA05740171 Exists in: LN6.0 Correction Target: RL70 P8 Severity: B - Major LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 237/330 Version 1.0 Confidential


Customer Impact: Operation & Maintenance Description: Cannot connect the LegacyBTS by BTSSiteBrowser. BTSSiteBrowser is not able to connect to Ultra BTS sites., Root cause: BTSSiteBrowser is not able to connect to BTS sites with more than 1 number in release version., Solution: Make release version parsing more flexible (e.g. consider formats, not just single numbers). Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: BTS Site Browser is not able to connect to BTS sites with 2 or more numbers in release version.

3.375 30/40 MHz CA applicable for SMr2 via BTS Site Manager Problem report: NA05751687 Exists in: LN6.0 Correction Target: RL70 P8 Severity: C - Minor Customer Impact: Operation & Maintenance Description: BTS Site Manager doesn't highlight configuration warning/error when commissioning 30 MHz built on FSME (SMr2) unit. Accordingly to CuDo and Supported Configurations documentation, FSME supports only 10 (5+5) and 20 (10+10) MHz Carrier Aggregation. BTS Site Manager doesn't notify online commissioner about these dependencies. It allows the commissioner to go the next page of commissioning after setting values. BTS Site Manager notifies about commissioning error only when trying to upload the SCF file., Root cause: The validation error was intentionally removed in LN6.0 from RNW page, but the prevalidation part was overlooked., Solution: Problem is fixed in LN7.0, but the prevalidation hardcode case was not fixed in LN6.0, but based on FM decision this will no longer needed to be fixed in LN6.0. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Missing notification in BTS Site Manager about unsupported configuration.

3.376 FRMB, FRLB: Increased number of RF module failure alarms 1920 Problem report: NA05768770 Exists in Release: LN6.0, LN7.0 Correction Target: RL60 3.0, RL70 1.0 Severity: A - Critical Customer Impact: Stability Probability: Permanent Description: Sporadically RF module failure alarms 1920 occur for RF Modules FRLB with 30W and FRMB with 40W carrier configuration. Some RF modules detect problems with adjusting output power. Improvement for FRMB and FRLB situation by decreasing RF module 1920 alarming with specified SW power amplifier input voltage control provided in RL60 3.0 is not yet implemented in RL70. Solution / Workaround: No Workaround Impact to Operator: Fault 'RF module failure' with fault code 1907 or 1920 will be active for following LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 238/330 Version 1.0 Confidential


configurations: eNBs with FRLB or FRMB RF modules.

3.377 SVMIS Notification 2-276-27185-2015-01-28 (Vuln. ID: 27185) : glibc 2.2 2.18 Buffer Overflow Vulnerability (aka GHOST) - 2.18 Problem report: 58943ESPE05 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: Vendor Affected Components: glibc 2.2 2.18 - Buffer Overflow Vulnerability (aka GHOST) 2.18, How end user/operator could detect the problem: security vulnerability gets exploited by an attacker, Description of the fault: A heap-based buffer overflow was found in glibc's __nss_hostname_digits_dots() function, which is used by the gethostbyname() and gethostbyname2() glibc function calls. A remote attacker able to make an application call either of these functions could use this flaw to execute arbitrary code with the permissions of the user running the application. (CVE-20150235), Vendor Affected Components:glibc 2.2 2.18, Related feature / functionality: all components doing hostname lookups, Dependency on configuration: name lookups are done Description of the correction (incl. risk analysis): harden code by buffer size checking; low risk since no functional change; tested intensively in glibc upstream project, Probability: Occasional Solution / Workaround: No workaround Impact to Operator: Attackers can exploit this issue to cause the application to enter an infinite loop which may cause denial-of-service.

3.378 PM counter M8006C134&M8006C143 and M8006C12&M8006C13 are incremented incorrectly with cause tx2relocoverall-expiry Problem report: 152881ESPE02 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: When eNB release a bearer due to cause tx2relocoverall-expiry, the counter M8006C134 and M8006C12 are updated by UEC incorrectly, the increment should be in M8006C143 and M8006C13 ., With X2 HO failure scenario (tx2relocoverall-expiry case), the Source eNB that detects the HO failure sends S1AP:UeContextReleaseRequest with “tx2relocoverall-expiry” cause. From field result the M8006C134 is updated in this case. eNB is expected to update LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 239/330 Version 1.0 Confidential


M8006C143 in this scenario., M8006C134 shall be restricted to the root cause “Radio Link Failure”, which reflects to non-recoverable connectivity problems between eNB and UE in the reporting cell. RLF scenario must not be mixed with the scenario “failed HO” since the usually the connectivity in the target cell is the problem and not in the source cell as it is in case of RLF. M8006C143 reflects to all UE Context release causes with the exception of those listed in the PM counter description. This implies that M8006C143 has to be pegged instead of M8006C134. Description of the correction (incl. risk analysis): M8006C134 update has been restricted only for “Radio Link Failure” cases. M8006C143 covers all cases except these listed in the PM counter description. Probability: Permanent Solution / Workaround: No workaround Impact to Operator: Wrong PM counters updated. User can observe that wrong PM counter (M8006C134) is updated when X2 Handover Source procedure fails due to tx2relocoverall timer expiry.

3.379 IPSEC Tunnels do not get re-established after overloading the certificates in FSMR2 Problem report: 114758ESPE04 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: After the tunnels are up, if we overload the same certificates (which are valid, NTP is properly synced), the tunnels are going down as expected. But after some time the tunnels are expected to get re-established. However, this does not happen. The tunnels do not get reestablished. This issue is seen in FTIB type of hardware only. Issue is not seen in FTLB. Probability: Permanent Solution / Workaround: No workaround Impact to Operator: Lack of 2G traffic after BSC reset. After certificate reload IPsec will not be established

3.380 [Vul ID 26899] strongSwan 4.5.0 5.2.1 - IKE_SA_INIT Message Handling Denial of Service Vulnerability - CVE-2014-9221 Problem report: 125441ESPE04 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: A new vulnerability is reported on StrongSwan package which can be exploited by malicious people to cause a DoS (Denial of Service). IKE_SA_INIT Message Handling Denial of Service Vulnerability - CVE-2014-9221. It means it was possible to crash charon with an IKE_SA_INIT message containing a KE payload with DH group MODP_CUSTOM(1025)., This issue was anlayzed for LN FSMr2 releases and found to be relevant and recommendation is to fix it. Also this issue is reported LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 240/330 Version 1.0 Confidential


for LN FSMr3 releases too and the same recommendation can be obtained as LN FSMr2., References: http://download.strongswan.org/patches/17_modp_custom_patch/ http://secunia.com/advisories/62095, Affected releases: FSMr2 - LN5.0, LN6.0, LN7.0, FSMr3 - LN5.0, LN6.0 Probability: Occasional Solution / Workaround: No workaround Impact to Operator: Attackers can exploit this issue to cause the application to enter an infinite loop which may cause denial-of-service.

3.381 FSMr2: [Vul id 17338, 22439, 26736] New vulnerability on glibc Problem report: 125439ESPE04 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: A new vulnerability is reported on glibc package (glibc-2.3.6) from the SVM tool. The ids of the vulnerabilities are the following [Vul id 17338, 22439, 26736]. These issues were analyzed by SW team and found to relevant. The recommendation is to fix this issues., References. http://www.securityfocus.com/bid/71670 https://bugzilla.redhat.com/show_bug.cgi?id=1175369 https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=11e3417af6e354f1942c68a271ae51e892b2 814d, Applicable releases: FSMr2 - LN5.0, LN6.0 Probability: Occasional Solution / Workaround: Apply glibc patches with vul ID Vul id 17338, 22439, 26736, Impact to Operator: Attackers can exploit this issue to cause the application to enter an infinite loop which may cause denial-of-service.

3.382 Fault ID 0418 in RL60 1.1 SW Problem report: NA05752187 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Alarm 418 occur in eNB., Root cause: High load might cause delays in EDMA transfer causing the alarm., Solution: Following improvements were done: - Decoder EDMA machine transfers moved to CC2_TC2. This should decrease load on CC2_TC0 used by EdmaDriver. - Snapshot DMA implementation merged from trunk to offload EdmaDriver. EdmaTransferXx calls now linked to L2 in all cores.



- Some bigger sleeps to Pusch Controller., Root cause: Wrong handling of EDMA traffic. Solution: Moved TCP3d EDMA traffic to CC2_TC2. This gives more resources to EdmaDriver on CC2_TC0. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Alarm 418 occur in eNB.

3.383 MME and SGW links randomly down with alarm 7657 Base station connectivity degraded Problem report: NA05710124 Exists in: LN5.0, LN6.0 Correction Target: RL50 2.3, RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: On integrated sites MME and SGW links go randomly down with alarm “7657 Base station connectivity degraded.” – Fault names: Transport layer connection failure in S1 interface (6202) and GTP-U Path Failure (6150)”. Once S1 link breaks and comes up again, eNB was not going 'on Air' Reason is - IPSec tunnels are not getting re-established after transmission outage longer than 3 min with configuration of 10 or more protect policies. Description of the fault. Strongswan threads got exhausted and it was not responding when TRSW was trying to reestablish the tunnels that were down due to S1 link failure. And eventually there was ORB hang in TRSW., Problem is related IPSec feature. This is seen only with configuration of 10 or more IPSec tunnels Probability: Occasional Solution / Workaround: Site reset helps to recover from this situation. Running strongswan stroke commands in foreground with timeout 500ms, and that forked processes will be killed after timeout. So strongswan threads will be released for other operations. Impact to Operator: Service impacted as eNB will not be 'on Air'

3.384 NA8 CUAA for eNB not working Problem report: NA05690529 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: CUAA is failing between Netact8 and eNB (RL60), There was enabled anonymous LDAP bind for CUAA according to documentation: Security Management Security Management Operating Procedures Administering Users and Permissions Controlling network element access with Centralized Network Element User



Management Activating Centralized Network Element User Management, [root@t4bnnnvsni16 ~]# /opt/oss/NSN-sm_hardening/bin/configureRestrictedLdapAccess.sh -e Enabling restricted anonymous LDAP access Enabling restricted anonymous LDAP access completed successfully, And additionally enabled CUAA via NetAct "Network Element Access Control" as desribed in: Security Management Security Management Operating Procedures Administering Users and Permissions Controlling network element access with Centralized Network Element User Management Network element specific procedures and requirements eNodeB, Monitor is now opening the Element Manager with the correct credentials., – Error report title: RL60 Acceptance - NA8 CUAA for eNB not working CUAA is failing between Netact8 and eNB (RL60) Probability: Permanent Solution / Workaround: No workaround Impact to Operator: CUAA is failing

3.385 FATAL EXCEPTION:[0xEA07A]CpuL1DMemoryProtectionFault Violated memory address(L1DMPFAR) during FiVe stability test Problem report: 120380ESPE01 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: CpuL1DMemoryProtectionFault Violated memory address(L1DMPFAR), crash in UL core (PreScheduler) debug facility added; if problem appears again, the snapshot will contain relevant information for finding the root cause Probability: Occasional Solution / Workaround: Radio reset (may not always help) Impact to Operator: fatal exception crashes seen in eNB

3.386 About CSFB PSHO,the Redirect don't include WCDMA frequency point. Problem report: NA05746215 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: UE report CSFB failure caused by Ue-inactivity. Ue doesn't drop form LTE cell to camp on WCDMA cell to establish Voice call. Probability: Occasionally Solution / Workaround: No workaround Impact to Operator: Voice call fail to establish, UE still camp on LTE cell.



3.387 Lot of RF MODULE ALARMS from LTE 800 FRMA-units Problem report: NA05751873 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: Alarm TX OutOfOrder get to state active. Huge numbers of alarm 1907 are visible. 79% of affected sites - Cell operation degraded (MIMO is not working). 21% cell outage if 1907 happens on 2 antennas belonging to one cell., Root cause: RF SW incorrectly handle alarm., Solution: Changes in alarm 1907 (TX out of order) alarm. Adding anti bouncer to alarm handling. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Alarm TX OutOfOrder get to state active. Huge numbers of alarm 1907 are visible.

3.388 MHA gain is not adjustable in a range. Problem report: NA05739500 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Active adjustable gain MHA with gain resolution less than 1dB cannot be set a gain within its range; only the minimum gain and maximum gain can be set. Use active adjustable gain MHA with gain resolution less than 1dB. Set gain within MHA gain range. , Related feature / functionality: TMA/MHA set gain Problem concern the scenario where eNB using active adjustable gain MHA with gain resolution less than 1dB. Probability: Occasional Solution/Workaround: Set to either minimum or maximum gain Impact to Operator: Without the correction, only the minimum gain and maximum gain can be set.

3.389 PNP not using IKEv1 Problem report: NA05733672 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: An eNB with FSME has been resettet to Factory Default and performed Plug and Play. Following PNP procedure should be done every 10 minutes: - VLAN Scan - DHCP - CMP - IPSec IKEv2 + IKEv1 - O&M, IKEv1 was not done during PNP for half an hour (3 cycles) and just in 4th cycle IKEv1 is used. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 244/330 Version 1.0 Confidential


The 1st cycle was not successfully as no connection to iOMS was established. However in 2nd and 3rd cycle IKEv1 was not even tried. Auto-connection was not possible., Root cause: After the 1st Auto-connection was successful and OMS connection was deliberately failed the next Auto-connection attempt was started. During this 2nd attempt, when IKEv2 probing was started Auto-connection thread slept for 40 sec. But in the meantime DPD thread also slept for 40 sec(30 sec + 10 sec due to DPD thread restart case). This meant that Auto-connection thread comes back from sleep a little bit earlier than the DPD thread and assumes that there is no DPD alarm. Hence Auto-connection falsely assumed that IKEv2 succeeded even though it actually failed and DPD alarm was raised few seconds after Auto-connection thread came back from sleep and checked for DPD alarm. This is why IKEv1 was never attempted., Solution: Design was changed, Auto-connection now relies on actual IPSec state rather than DPD fault. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Autoconnection was not working with FSME.

3.390 Ghost vulnerability - CVE-2015-0235 Problem report: 59137ESPE05 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: A new remotely exploitable vulnerability was identified in the Linux glibc library starting from the fourteen year old version of 2.2. A vulnerability resides in the code underlying gethostbyname() making this a real threat to any network functionality resolving DNS names. The vulnerability was identified by Qualys and they also made a POC code that bypasses all existing protections (like ASLR, PIE and NX). There was a fix between the releases of glibc2.17 and glibc-2.18, unfortunately most stable and long-term-support distributions were left exposed including Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example., References: Qualys blogpost: https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability, Orignal advisory by Qualys: https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt, Useful summary: http://arstechnica.com/security/2015/01/highly-critical-ghost-allowing-code-execution-affectsmost-linux-systems/, This issue was analyzed by SW team and confirmed as applicable and recommendation is to fix it., Affected releases: FSMr2 - LN5.0,LN6.0 Probability: Occasional Solution / Workaround: No workaround Impact to Operator: A vulnerability of the Linux GNU C library (glibc) makes it possible to access the system bypassing all existing protections.

3.391 BER detected. Problem report: 121358ESPE01 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: A - Critical LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 245/330 Version 1.0 Confidential


Customer Impact: Operation & Maintenance Description: Summary of the original problem: Increase in bit error rate detected for radio module How end user/operator could detect the problem: Use an I-type 5/10 MHz configuration Description of the fault: Configuration of I-type 5/10 MHz is not supported as per specifications. Hence, all ocation of slots between the two radio technologies are colliding. Related feature / functionality: RF Sharing Dependency on configuration: Yes. I-type 5/10 MHz Description of the correction (incl. risk analysis): Apply constraints for I-type 5/10 MHz configuration using Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: BER detected. Calls will not be possible on this specific configuration

3.392 Increase in e-RAB drop rate Problem report: NA05741866 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Capacity & Performance Description: eRAB drop rate on one Carrier Aggregation eNodeB is increased. 1) Failure is mainly due to CA second cell addition. 2) 215 out of 911 drops happened because of one UE., Root cause: eNB is sending an S1AP ErrorIndication with cause "Semantic Error" when receiving UeContextReleaseCommand from EPC, while RRC Reconfiguration to add scell is ongoing. Problem is happening only with a specific MME probably because that MME has a shorter timeout. The reason why the UE does not answer to the RRc Connection reconfiguration (S-Cell addition) was not analysed here – could be this particular MME send some invalid values). First problem in UEC is that when going to Idle state, it should analyse the queued messages. Don’t send blindly error indication for all of them but UEContect release should have a special handling. Second problem in UEC: The content of the Error Indication sent from UEC is wrong., Solution: Specific registration and handling of S1ApErrorInd message while ScellSwap procedure is running missing. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: e-RAB drop rate increased

3.393 DSP crash in "second" eNB after SW upgrade Problem report: NA05750875 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: A - Critical Customer Impact: Stability Description: After SW upgrade on two eNBs the first eNB is ok but the second eNB starts autonomous reset always – eNB can come to On-Air and cells are in service, then DSPs of FBBC start crash., Root cause: DSP crash because of memory access violation. The memory corruption occurs in critical memory section., Solution: LTEL2RlcCoreUlTimerPool memory section (critical) is swapped with LTEL2RlcSupportUlStatsLogger sections. It is supposed that corruption is performed by StatsLogger, but could be that it is done by completely different module of L2 or even system component located on the same DSP (MAC PS). Attached PR: NA05754786 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 246/330 Version 1.0 Confidential


Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: DSP crash because of memory access violation after SW upgrade.

3.394 Counters M8001C150 / M8001C266 are fluctuating with new SW Problem report: NA05755603 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: After upgrade we still observe fluctuations of M8001C150 / M8001C266 counters. Example: In 3 cells the counter M8001C266 shows much higher values than on the day before. Updating of PM counters M8001C266 and M8001C150 is based on the received UL buffer status reports. Value of counter M8001C266 ("Number of active UL UEs") is incremented when a UL buffer status report is received from UE and it indicates that UE's buffer state has changed from empty to not-empty. Value of counter M8001C266 is decremented when UE informs empty buffer status or when UE is deteched from eNB with still having unsent data. Counter M8001C150 is average counter based on the same principle as M8001C266., Root cause: During the initial access or RRC connection re-establishment UE sends data to uplink (RRC connection request or RRC connection reestablishment request). With this request UE can optionally send also UL buffer status report which informs eNB how much payload data UE currently has for uplink data tranmission. This will trigger incrementation of counter M8001C266 ("Number of active UL UEs"). If initial access or RRC connection re-establishment happens to fail before UE attachment is complete then eNB L2 SW does not decrement counter value correctly. This causes that counters M8001C266 and M8001C150 begins to report permanently too high value., Solution: Implementation of counter updating is corrected to eNB L2 SW so that failure in initial access or RRC connection reestablishment does not lead to incorrectly high values of counters M8001C266 and M8001C150. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: PM counters M8001C150 and M8001C266 showing incorrect values.

3.395 RET Alarms Not Displayed Problem report: NA05737587 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Once the RET Acctuator cap is removed and and TILT command is sent the site displays Acctuator jamed fault. Once the caps are put back and Tilt command is sent it successfully passes however the Alarm is not removed until the site is reset.//, .....a different result was observed. The Actuator Jammed error code was seen in the RET Settings window, as well as the message in attached screenshot "Step 11 Cap removed and Acctuator jammed", which is correct behaviour., However, with the actuator cap still removed, the message "Unexpected Problem" also appeared, as captured in screenshot "Step 11 Unexpected Problem". No alarms LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 247/330 Version 1.0 Confidential


appeared for this issue, which I would have expected, as was seen in case NA05661594 at RL50 sw., Summary of the original problem: When error occurs when calibrating ret, a error dialog will pop up. Then close this dialog later, the balloon message is not shown, and an unexpected dialog is up., How end user/operator could detect the problem: When the error dialog pops up, don't close the error dialog until OAM sends a DCN to clear all the error messages, then close the error dialog, the unexpected dialog will appear., Description of the fault: Did not consider the case that OAM will send DCN to clear all error messages after calibrating, so SEM doesn't handle this correctly and caused the unexpected dialog. And because error messages are cleared, so no balloon message will be shown. , Description of the correction (incl. risk analysis): Handle the case if the error messages are cleared after calibrating. No risk increased. Probability: Occasional Solution / Workaround: No workaround Impact to Operator: User will have to close the unexpected dialog to continue.

3.396 VoLTE ADR of QCI1 is worse than other vendors. Problem report: NA05752295 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: After both successful and unsuccessful E-RAB setup for QCI1 (VoLTE call) UE was released due to A2 measurement report. UeContextReleaseRequest had networkLayerCause set to interrat-redirection and then wrong counter M8006C134 was incremented. This counter should be incremented only for cause radio connection with UE lost., It is visible in statistics of ENB_EPS_BEAR_REL_REQ_R_QCI1 counter., Description of the fault: 1.Code implementation of the counter follows RL50 specification, which is different from RL60. 2.There are three procedures ongoing when problem occurs: -After X2 handover UEC decides to send to UE UeCapabilityEnquiry since it doesn’t know utra capabilities of UE. -E-RAB setup request for QC1 is sent to eNB. -UE sends A2 measurement report with that indicates low signal level. UEC decides to redirect the UE. When the decision of release is made RRC connection release is sent to UE. After that there are some messages on RRC sent by eNB which is incorrect. One of them is UeCapabilityEnquiry. It is because this message is in message queue before rrcrelease is sent. Code implementation is that during sending UeCapabilityEnquiry casue of release is set to radio connection with UE lost and this triggers incrementation of counter., Related feature / functionality: VoLTE, Description of the correction (incl. risk analysis): 1.Implementing counter incrementation according to RL60 definition. 2.Removal of UeCapabilityEnquiry from the messages queue when redirection is triggered. Probability: Occasional Solution / Workaround: No workaround Impact to Operator: KPI increased

3.397 Attach impossible on BW = 20MHz Problem report: 124425ESPE04 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 248/330 Version 1.0 Confidential


Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Capacity & Performance Description: Unable to attach UEs to the cells configured on the FRHD A.102 Units with 20 Mhz bandwith., Root cause: Attach impossible due to wrong timing configuration (High ATA detected). Due to wrong timing, the eNB estimate much higher distance between antenna and UE, than it is in real. Solution: Timing parameter was changed for the FRHD A.102. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: No service possible with 20 MHz bandwith. UEs couldn't be attached to the cells when FRHD A.102 is used.

3.398 VoLTE eRAB SR of QCI1 is worse than other vendor’s. Problem report: NA05749456 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: When (Intra eNB Inter Cell, S1 not from Utran, X2, Intra eNB Intra Cell not triggered by Ue Context Modification) handover in the target cell is not complete, the coming S1AP E-RAB Setup Request from MME will be put in the queue temporarily. With this specific HO and ERAB Setup mixed scenarios and timing, the counter M8006C26 is updated twice incorrectly (first update is at the reception of S1AP, the 2nd one is processing this message after HO completion) when only one VoLTE call is set up. M8006C44 is updated once correctly, so the KPI SR (=Completions/Attempts) will be degraded when this scenario happens., Root cause: The part of code, which handles E-RAB Setup Req in DataBearerMgr and decides that msg should be put to the queue, is executed twice in this scenario, and it leads to double counter incrementation., Solution: Now only actual processing of S1AP:BearerSetupRequest triggers counter update. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Counter M8006C26 is updated incorrectly in a few cal scenarios. KPI SR (=Completions/Attempts) will be degraded (attempts failure + success).

3.399 System module failure (412:EFaultId_LostFrameSync) occurred after SW upgrade Problem report: NA05747467 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: We detected "System module failure(FaultID412)" after RL60 0.1.2 RollOut. This faultID did not occurred the RL50 SW eNB. But Fault ID:412 defined in NED(RL50 issue03)., Root cause: In particular cases under low-memory, highly- fragmented situations on the system load like it is happen during SW activation at SW upgrade there is a memory allocation error on the mounted flash device. The main root cause is in the Linux Kernel, where



we found a not properly designed memory allocation handler., Solution: In RL70 this was already corrected at platform SW with first release. Attached PR: 118585ESPE04 Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: System module failure (412:EFaultId_LostFrameSync) occurred after SW upgrade. SW Download / Startup fails.

3.400 RL60 CRL content ignored during authentication IKE phase Problem report: NA05735513 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: During RL60 tests the session dedicated to certificate management has demonstrated a serious problem in CRL management.RL60 CRL content ignored during authentication IKE phase, • eNB updates correctly CRL file either if manually triggered or via periodic event. • The content of the CRL file is updated correctly and, as expected, the BTS allarm 61074: CRL Update failure, BTS certificate being part of the CRL is shown when BTS certificate is inside the CRL. •However, the CRL content is not considered during authentication IKE phase., Here it is the test sequence description:, 1)SEG or BTS certificate are suspended/revoked by HP CA 2)the BTS downloads the new CRL (CRL updating in SEG side is disabled, for test purposes) 3)the IP sec tunnel is interrupted to force a new IKE authentication phase 4)the BTS re-establishes the IPsec tunnel even if SEG or BTS have a revoked certificate Probability: Occasional Solution / Workaround: No workaround Impact to Operator: RL60 CRL content ignored during authentication IKE phase

3.401 E-UTRAN HO Preparation Success Ratio, inter eNB X2 based degradation Problem report: NA05740645 Exists in: LN5.0, LN6.0 Correction Target: RL50 2.2, RL60 3.0 Severity: C - Minor Customer Impact: Capacity & Performance Description: E-UTRAN HO Preparation Success Ratio, inter eNB X2 based Degradation. We have X2 KPI degraded to 20%., Root cause: Incorrect implementation for Deduce Cell Barred Status in CELLC., Solution: The code was aligned to the current specification. Deduce Cell Barred Status, List of PLMNs to be broadcasted and Cell Reserved status for primary PLMN (if required) using EpcPlmnIdSet List of PLMNs of the cell with S1 availability received from ENBC in ENBC_CellS1AvailabilityResp, 1. If empty list of PLMNs is received then: - If the cell barred status is received as "not barred" in CELLC_CellSetupReq then the cell is assumed to be barred.



- If the cell barred status is received as "barred" in CELLC_CellSetupReq then nothing has to be done. 2. If step 1 is not true then CELLC has to use the received list of PLMNs with S1 availability. In addition CELLC shall include the "eNB Primary PLMN Id" to this list of PLMNs with S1 availability irrespective of its inclusion in the received list. CELLC shall broadcast only this list of PLMNs with S1 availability. Further CELLC has to internally store this list of PLMNs with S1 availability in order to detect any changes in a later Cell S1 availability Indication from ENBC. 3. If the "eNB Primary PLMN Id" is not included in the received list then the cell reserved status for it is set to "reserved" else the value received in CELLC_CellSetupReq shall be retained. If the list of PLMNs with S1 availability is not empty then CELLC shall broadcast "eNB Primary PLMN Id" along with the list of PLMNs with S1 availability. If the list of PLMNs with S1 availability is empty then CELLC shall broadcast the cell as "barred". CELLC shall also store internally the received list of PLMNs with S1 availability from ENBC. This is required to detect any changes in a later Cell Reconfiguration from RROM. The previous implementation set the cell as barred if primary PLMN ID was not found in the list of available PLM IDs. The new implementation adheres to the requirement and sets the cell as barred if the list of available PLMN IDs is empty. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: E-UTRAN HO Preparation Success Ratio, inter eNB X2 based degradation. Degraded performance - some cells in operator's network are unavailable.

3.402 FRMB 1920 Alarm after RL40 EP3.2 Upgrade Problem report: NA05720689 Exists in: LN6.0 Correction Target: RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Analysis detected an improper signal (spike) on feedback path in the PA (Power Amplifier). • The RFM SW needs a proper power level on the feedback path, else the unit cannot self-adjust power level, channel separation etc. • If this condition is not fulfilled, the RFM cannot work properly and the alarm 1920 is raised. • The situation was seen only when PA was set up • with a specific voltage value and • if the received IQ data (from the System Module) are by -10 dB lower than the commissioned power. • Typical conditions for the problem to occur are: The PA is cold and traffic starts suddenly. • The spike signal was caused by an oscillation effect in the PA lineup under the above mentioned circumstances. Probability: Permanent Solution / Workaround: No workaround. The SW correction consists of a function that, on detection of the improper feedback signal, adjusts the voltage value and thus eliminates the spike on the feedback path while, at the same time, preserving the gain budget from depleting. Impact to Operator: Alarmed FRMB units have been impacted/damaged by previously experienced spikes (voltage overdrive) to such an extent that the reactive voltage adaptation does not suffice to eliminate the alarm conditions.



3.403 iOMS openssl.cnf file must be modified to fulfill RL60 EE certificate requirements (Error during cert installation in iOMS) Problem report: NA05753364 Exists in: iOMS6.0 Correction Target: iOMS6.0 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Existing command is too complicated for operator to execute everytime there is a need for manual creation of csr file. Solution/Workaround: Our proposal is to enrich existing omscertficate CLI command to allow for manual creation of csr file. Using a wrapper instead of specific openssl command would be more user friendly. The proposal for the new command would be as follows: omscertificate create-csr-request -csr-filename csr_filename [-csr-dirpath csr_dirpath] [-keyfilepath key_filepath] [-cn-name cn_name] -csr-filename csr-filename - name of the csr file //mandatory parameter [-csr-dirpath csr_dirpath] – path to directory where the csr file will be stored (if this is not provided then csr file will be saved to current folder) [-key-filepath key_filepath] – private key filepath (if not provided then private key will be generated automatically and saved in current folder or in the specified folder for csr file) [-cn-name cn_name] – common name (if not provided ip machine is used as common name) Probability: Permanent Solution / Workaround: No workaround Impact to Operator: No impact

3.404 Security Vulnerability on iOMS - Denial of Service in web application Problem report: 150295ESPE02 Exists in: iOMS6.0 Correction Target: iOMS6.0 3.0 Severity: B - Major Customer Impact: Security Description: OMS needs to fix the following vulnerability detected. * IR-nc-http-dos-1 - Denial of Service in web application. See VAMS for detailed description. * PoC against Slowloris denial of service and usage of mod_reqtimeout module * Apache in general is vulnerable to the “Slowloris” DoS attack and it could be mitigated with the mod_reqtimeout. https://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html How end user/operator could detect the problem: Vulnerability is not easily detected by operator. Operator has to run a third party tool (e.g. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 252/330 Version 1.0 Confidential


slowhttptest) against the application with authenticated scan and execute “Slowloris” attack on web application Description of the fault: Web application server is prone to DoS attack Probability: Permanent Solution / Workaround: No workaround. Change httpd configuration, include mod_reqtimeout module parameters. Impact to Operator: Vulnerability is not easily detected by operator. Operator has to run a third party tool (e.g. slowhttptest) against the application with authenticated scan and execute “Slowloris” attack on web application.

3.405 LTE Multiple sites with Inter eNodeB HO preparation Failure Rate Problem report: NA05722826 Exists in: LN6.0 Correction target: RL60 3.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: Multiple eNBs having high HO Preparation Failure Rate, caused by unbalanced X2 link status., Root cause: Due to SCTP buffer congestion, X2 setup response is not being delivered, caused unbalanced X2 link status., Solution: A new SW function will be introduced to BTS SW. The new function terminates and restarts a congested SCTP association (without C-plane context release). With this solution SCTP stack congestion will be resolved without tearing down other SCTP associations at that SCTP endpoint (latest after 30 seconds). Probability: Occasional Solution / Workaround: eNB reset or change the X2 IP to fake one, then change back to trigger Impact to Operator: Occasional eNBs having high HO Preparation Failure Rate

3.406 [Security Vulnerability] SSLv3 Padding Oracle Attack Information Disclosure Vulnerability (aka POODLE Attack: CVE-2014-3566) Problem report: 87670ESPE03 Exists in: iOMS6.0 Correction target: iOMS6.0 3.0 Severity: B - Major Customer Impact: Security Description: This PR is raised to fix the vulnerability CVE-2014-3566 in OpenSSL versions., The required security correction must be implemented in all the active FP releases (Cat, Lynx and FPT). Summary of the original problem: OMS was venerable for SSLv3 Padding Oracle Attack How end user/operator could detect the problem: By opening connection with forcible usage of SSLv3 Description of the fault:SSLv3 has flaw, which allows for security breach. Related feature / functionality:HTTPs access, security Dependency on configuration: None LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 253/330 Version 1.0 Confidential


Probability: Permanent Solution / Workaround: Disabling sslv3 in httpd manually Description of the correction (incl. risk analysis): By recommendation OpenSSL Toolkit has been upgraded, which internally disables fallback to SSLv3. Also SSLv3 has been added to list of protocols that are by default disabled Impact to Operator: By allowing to use of SSLv3 in HTTP there was possibility of security breach.

3.407 After upgrade to RL50 MP2.1 we see on some enbs remotely only "O+M disconnected alarms" and we have to drive onsite Problem report: NA05743515 Exists in: LN5.0 Correction Target: RL60 1.1 Severity: A - Critical Customer Impact: Operation & Maintenance Description: After upgrade to RL50 MP2.1 and after the activation of the sw we only see "O+M disconnected alarms" and we have to drive onsite for Power-on-Reset procedure. There are 2 different cases. 1.)eNB is locally via Elementmanager reachable 2) eNB is locally not reachable via Elementmanager, The problem isssue is that API to add route to fastpath is failing, due to which route not available at fastpath. Dependency on configuration is fast-ip rerouting. Probability: Permanent, Solution / Workaround: Disable fast rerouting before upgrade As a solution the recovery added in case API fails., Impact to Operator: In case the problem occure the communication between those nodes can be corrupted.

3.408 Duplicate eNB Mac address showing in FSM physical interfaces Problem report: NA05723011 Exists in: LN5.0 Correction Target: Correction not needed Severity: B - Major Customer Impact: Operation & Maintenance Description: Duplicate Mac address showing in eNB FSMF physical interfaces in customer network. Wireshark captures in access router part for those eNBs and ARP table check in access router.Mac address duplicate is observable from the investigation. The rollout and implement scheduler was impacted due to this issue. Probability: Permanent, Solution / Workaround: Nokia prepared a special script to gather all information about MAC addresses of eNBs from network. In case when problem exists in network, Nokia will provide a script to replace affected MACs. For the solution there is required to contact directly with the Technical Support. , Impact to Operator: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 254/330 Version 1.0 Confidential


In case when in network duplicated MAC addresses exist, communication between those nodes can be corrupted. Many KPIs are affected when communication is corrupted. Low throughput(less than 1Mbps for downlink) is visible under those Mac address duplicate eNBs.PS service and rollout scheduler can be impacted.

3.409 FSMr3: some of the IPsec tunnels stayed down for long time. Problem report: 153432ESPE02 Exists in: LN5.0 Correction Target: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Problem has been discovered during stability test., An after an unexpected outage in the lab, after recovery, some of the tunnels on both eNB 448 and 416 stayed down for more than 2 hours. "Dead peer detected" alarm (fault 61030) is seen from BTS SM GUI and related functionality (C/U/M/S plane) is not functioning when their tunnel is down. Tunnel should not stay down for long during normal operation or after an outage. From the wireshark, we did not see either eNB or SecGW trying to bring up the tunnel. IPSec tunnels remain down till the next re-keying phase. IPSec and IKEv1 in use, Test-Line Reference / Info: FSM HW: FSMr3 TRS: FTIF Multiple IPsec tunnels configured Probability: Occasional, Solution / Workaround: A deletion and re-creation of the Security Associations at the SecGW sites should recover the problem., Impact to Operator: eNB off air.connection to eNB might be lost. Some functionalities (C/U/M/S plane) will not be functioning when their related tunnel is down.

3.410 Unable to send paging over the air due to failure in timer allocation Problem report: NA05748001 Exists in: LN5.0 Correction Target: RL50 2.3 Severity: A - Critical Customer Impact: Operation & Maintenance Description: Once an eNB starts to show symptoms of reduced paging sent over the air, the degradation progresses, until one few percents of the incoming S1 paging volume can be sent to mobiles over the air. More specifically, counter M8008C1 "RRC Paging requests" decreases over time while counter M8000C11 "S1 Paging requests" continues with its usual trend. At some point the paging rate is getting lower, at the end only 1 paging per second is allowed and BTS is practically out of usage., Analysis of syslog from snapshot on affected sites reveals that paging cannot be sent over the air because the associated timers cannot be allocated. ENB SW is RL50 MP2.0 (LN5.0_ENB_1304_752_03). Both FSME and FSMF are impacted., Due to sam variable name in LTE and WCDMA the timer ID pools in which we store timerIDs for WCDMA LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 255/330 Version 1.0 Confidential


timers and LTE timers were mixing and we were losing available timer IDs over the time. Because of this the paging rate dropped down when we've lost more than ~4700 IDs. Probability: Occasional Solution / Workaround: Resetting the BTS as a temporary solution, Impact to Operator: The paging rate is getting lower, at the end only 1 paging per second is allowed and BTS is practically out of usage.

3.411 After change dlRsBoost, the base station automatic restart Problem report: NA05716252 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Customer found after change dlRsBoost, the base station automatic restart., Root cause: Crash was caused by LOM Trace registeration has failed., Solution: Following corrections were done: - An alarm (6112) is raised if LOM trace registration upon cell setup fails. - Sending LOM traces is avoided if LOM Trace registeration has failed. Thus avoiding crashes. - LOM TraceHandle provided upon Initialize() is not used to distinguish if LOM registration/unregistration is needed, as it can be Zero (depends on CellId). Attached PR: 117288ESPE01 Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: After change of parameter dlRsBoost the eNB does an automatic restart.

3.412 LTE1198 RSRQ triggered mobility: Backup plan logical validation failure Problem report: NA05704992 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance, Description: Provision plan which changes RSRQ parameters with 'Create backup plan' option is available. Then attempt plan rollback by provisioning the backup plan (with pre-activate option) with this provision plan. The backup plan validation failed in the logical validation phase., Root cause: Validation in the NetAct is failing because validation file includes a structure 'rsrqMobilityParams' that is going to be deleted: In list name="rsrqMobilityParams"/... only "parent" parameter included, no parameters of this structure are present., Solution: BTS Site Manager has to check first the size of the parameter list. If does not contain at least 1 item, skip the validation of the list. Probability: Permanent Solution / Workaround: Disable the validator in NetAct Impact to Operator: Operator cannot rollback the configuration



3.413 3G-4G LTE uses wrong transmission rules for 20 MHz configuration Problem report: 123125ESPE04 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Summary of the original problem: Fault appears on RF sharing of LTE - WCDMA (config: WCDMA A-type LTE H-type; 3G configured as 2+2+2 and LTE is 1+1+1 15MHz band in use), How end user/operator could detect the problem: RP3 collision in transmission rules between WCDMA and LTE causing that cell 2 in WCDMA is faulty and Cell 2 in LTE is faulty. Fault (125) RF module failure in WCDMA and in LTE fault(4090) Cell Power failure. Fault 125 and Fault 4090 will be raised thru SEM. Description of the fault: Transmission rule for the said configuration (20Mhz) is not supported., Related feature / functionality: 3G-LTE RF sharing, Dependency on configuration: WCDMA A-type, LTE H-type 20MHz. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Calls may not be possible or quality may be degraded.

3.414 MHA and RET units are not be detected automatically Problem report: NA05696988 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Lots of different alarm raised for same device How end user/operator could detect the problem: Found the duplicate alarm on same device Description of the fault: Lots of different alarm raised for same device Related feature / functionality: None Probability: Permanent Solution / Workaround: No Workaround. Avoid different device ID used for same alarm Impact to Operator: May see duplicate alarm (on same fault device)

3.415 Abnormal released issue initiated by eNB after upgrading to RL60 Problem report: NA05719472 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Summary of the original problem: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 257/330 Version 1.0 Confidential


Measurement gaps in handover scenarios were misconfigured occasionally. How end user/operator could detect the problem: HARQ re-Tx parameters were missing in measurement gaps configuration during RRC connection reconfiguration. Ues were released occasionally. Measurement gaps offset was incorrect. Description of the fault:Current DrxStartOffset wasn’t taken into account in measurement gaps offset calculation during handovers, what led to misconfiguration. Related feature / functionality:LTE42 Drx Probability: Permanent Solution / Workaround: No Workaround Description of the correction (incl. risk analysis): Measurement gaps offset calculation fixed. Valid DrxStartOffset is used during handovers. Impact to Operator: No more occasional misconfigurations/releases caused by ignoring DrxStartOffset in handover cases.

3.416 eNB crash due to lot of Srio errors Problem report: 119494ESPE04 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: eNB stuck in integrated state with fault 418 and 6450 due to EDMA transfer aging issue., Description of the fault: EdmaIsComplete() API inheritet from Faraday was no longer working as expect are launching EventMachine based application. Too small difference between current and checked TSN (2000) was allowed., Related feature / functionality: PS DMADrivers., Effects on end-user: Call outage, Effects on operator: eNB not on air, System effects:, Other effects:, Interface Effects:, Faulty component and version:, Faulty component first delivered in (e.g. release, CD):, Test case analysis (from EDMA POV): 1. Why this pronto was not detected in our test environment? DSPHWAPI testcase are not simulating real load in application scenario. This load is different for different applications and it's impossible to predict all of the possibilities. Probability: Occasional Solution / Workaround: No Workaround .Solution from EDMAShooter inherited, now bigger difference is allowed. Impact to Operator: Call outage/eNB not on air.

3.417 Missing Consistency Check for actFastMimoSwitch==true and dlMimoMode== Dynamic Open Loop MIMO Problem report: 56624ESPE05 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 258/330 Version 1.0 Confidential


We observed missing of Consistency Check for parameters pair: actFastMimoSwitch==true and dlMimoMode== Dynamic Open Loop MIMO., If actFastMimoSwitch is set to 'true' following conditions need to be fulfilled: - riPerOffset must be configured to '-1' - riPerM must be configured to '1' - riEnable must be configured to 'true' - dlMimoMode must be configured to ('Closed Loop Mimo' or 'Closed Loop Mimo (4x2)', Based on MINT database we noticed that now exists ~6000 cells (7 Net. Operators) with such configuration where actFastMimoSwitch==true and dlMimoMode== Dynamic Open Loop MIMO. Such situation is Critical from SW Upgrade Perspective . How end user/operator could detect the problem: During SW Upgrade procedure Description of the fault: There is and Error during SW Upgrade. Related feature / functionality: • LTE568 DL adaptive closed loop MIMO (4x2) (optional), Probability: Permanent Solution / Workaround: As there is no possibiity to change PDDB Parameter Relationships in RL50 then the additional migration rule should be implemented: If (LNCEL:dlMimoMode== Dynamic Open Loop MIMO and LNCEL:actFastMimoSwitch==true) then (LNCEL:actFastMimoSwitch==true need to be change to LNCEL:actFastMimoSwitch==false)., Impact to Operator: Error / Wrong Commissioning Cells will not go thru upgrade proc

3.418 FXEB reporting 3-4db lower RX level vs. FXEA Problem report: 116357ESPE04 Exists in: LN5.0, LN6.0 Corrected in: RL50 2.0, RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: PUCCH / PUSCH RSSI reporting changed after LN6.0 sw updated from LN5.0 LN5.0 R&D has found out that FXEB (vegas) reporting too low 3-4dB. This could be seen when monitoring RX reporting from RF module and udp log from system module. In UDP log was seen this 3-4dB difference. Attached PR: NA05732818 Probability: Permanent Solution / Workaround: No Workaround. Rx. RX scaling parameter in property file was tuned corresponding certain RF module reporting over obsai to the System Module. For FXEB and FXDB: Rx.Power.Scaling = -122.31 Impact to Operator: 4dB differs from FXEA and causing HO problems like ping-pong effect between cells.

3.419 Reno - New RX Scaling Factors for 4G SM Problem report: 101424ESPE01 Exists in: LN6.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 259/330 Version 1.0 Confidential


Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: PUCCH / PUSCH RSSI reporting changed after LN6.0 sw updated from LN5.0. The 4G System Module uses hard-coded RX scaling factors for the Reno project. The latest testing shows these scaling factors to be incorrect and they need to be updated. LN5.0 R&D has found out that FHEB (reno radio) reporting 3-4dB too high RSSI. The new scaling factors are: FHDB: Changed from -120.31 to -122.0 FHEB: Changed from -120.31 to -124.56 FRPK: Changed from -120.31 to -122.8 LN5.0 R&D has found out that FXEB reporting too low 3-4dB. This could be seen when monitoring RX reporting from RF module and udp log from system module. In UDP log was seen this 3-4dB difference. Probability: Permanent Solution / Workaround: No Workaround Power Scaling changed for RENO modules FHDB, FHEB and FRPK. Impact to Operator: 4dB differs from FXEA and causing HO problems like ping-pong effect between cells.

3.420 DSP crash (problem with bit toggling detection and correction) Problem report: NA05718771 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Capacity & Performance Description: DSP crash on customer pilot SW has revealed a problem in routines correcting L2 bit toggles. The crash was the result of a bit toggle in the L2 Cache area., Solution: Corrected by changing the function EDCCheckErrors so that EDC is not activated in L2 cache area. How end user/operator could detect the problem: Memory protection fault that leads to the DSP crash. Description of the fault:The crash was the result of a bit toggle in the L2 Cache area. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Memory protection fault that leads to the DSP crash.

3.421 No network connection from Site Manager Problem report: NA05731940 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 260/330 Version 1.0 Confidential


Customer Impact: Operation & Maintenance Description: Site Manager for LN6.0 and Site manager for WN5.0 was installed on the same machine. Then after input of user name and password network connection could not be established., Root cause: CL was not compatible with WN5.0 cl config file. Probability: Permanent Solution / Workaround: Remove old manager and try again. The problem was fixed in RL60 by updated cl.jar. Impact to Operator: Network connection could not be established if Site manager for LN6.0 and WN5.0 was installed on the same PC.

3.422 Handover cancel with TEID duplication and Route establishment failed leading to hanging TEID resource Problem report: 122606ESPE04 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Capacity & Performance Description: Inter eNB X2Handover fails permanently because of hanging unidirectional forwarding channel on source side: ERR/UEC/IpcsOriginating.cpp#266 [ThreadID:68 ueContextId:2 cellId:1] fillConnectionsList():[contextId = 0x2] WRONG eTEID: 0x1 - is already established by [contextId = 0x0] with tupuSicAddr=0x12520f73 and isUniDir:1 in state 2! How end user/operator could detect the problem: next X2Ho failed if it was tried to reuse this specific eTeid Description of the fault: X2Ho was interrupted by Reestablishment on Ho-Src-side and Reestablishment failed. In this case the unidirectional forwarding channel wasn't released. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: UE attach or HO requests would be rejected after all TEID resources are either used or hanging

3.423 NWI3 access credentials shown in plain text in the rac_cm_events.log Problem report: NA05721685 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: When monitored the rac_cm_events.log file it was found out that eNB is sending CCN to NetAct containing NWI3 access credentials. This seems to be security issue that needs to be solved. These credentials are not shown in cm and not included in the metadata. Probability: Permanent LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 261/330 Version 1.0 Confidential


Solution / Workaround: No Workaround. Solution - in case of local account credentials update, CCN sent from TRS will only have username. Password parameter is removed from CCN. Impact to Operator: eNB is sending password in CCN messages sent to Netact.

3.424 Unit autonomous reset after paramater changing Problem report: NA05735495 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Stability Description: Unit autonomous reset occurred after parameter changing to enable feature LTE801 and LTE1402., Root cause: Cell deletion (low prio) already ongoing while high prio task still uses cell class members. Dependency on configuration: Feature enabling: Any feature that causes cell restart (when cell is in active state) if feature will be enabled or disabled. Attached PR: NA05742260 Probability: Permanent Solution / Workaround: No Workaround, High prio access blocked when cell scheduling is stopped (before deletion). Impact to Operator: Unit autonomous reset occurred after parameter changing to enable feature LTE801 and LTE1402 (any feature that causes cell restart (when cell is in active state) if feature will be enabled or disabled).

3.425 KPI Active UE increased Problem report: NA05724113 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: A - Critical Customer Impact: Capacity & Performance Description: Counter group M8001 AVG and SUM counters doesn't work properly. Root cause: The new SW architecture introduced for FSMr3 from RL60 onwards which has not been taken into account from counters pov. in a specification nor implementation. How end user/operator could detect the problem: Unrealistic counter values and KPIs. Dependency on configuration: Problem exist with FSMr3 only. Description of the correction (incl. risk analysis): Problematic averaging method removed and several other bugs corrected. Counter update frequency increased(updated in every ms. at the end of every TTI) to get counter values more specific when additional averaging not needed anymore. Started to use a new accurate timer for counter reporting. Possible risks: CPU loads might get increasing but should be in acceptable level still. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 262/330 Version 1.0 Confidential


Probability: Permanent Workaround: No Workaround Effects to operator: KPI for DL active UE is not correct.

3.426 Changing otnRecoveryPeriod parameter from setting value(5000) to default (500) Problem report: NA05726205 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: The Value of parameter 'OTN Recovery Period' is changed from 5000 to 500 after SW upgrade., Root cause: The parameter conversion / migration was provided to change the parameter value when the input value was 5000. The problem here is the value is changed on every SW upgrade independently is the feature (actOtnRecovery) active or not. Thus, if a customer wants to have real value 5000 for the otnRecoveryPeriod, it was not possible but the value changed to 500 on an SW upgrade. The problem exists only when the otnRecoveryPeriod is configured to value 5000 (the total range of 0...20000)., Solution: The parameter otnRecoveryPeriod conversion / migration done only if the feature is not active (actOtnRecovery is false). Probability: Permanent Solution / Workaround: The otnRecoveryPeriod to be configured to any value other than 5000 (within the value range of 0...4999, 5001...20000)., Impact to Operator: The parameter otnRecoveryPeriod value changed to 500 on a SW upgrade when the original configured value was 5000.

3.427 [FDSW] Autoconnection IP parameters are not migrated to RAT SW after successful SW Download Problem report: 86902ESPE03 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: [1. Test Scenario Steps] After successful SW Download, when RAT SW is activated, autoconnection parameters are not transferred. Autoconnection process is starting all over again when RAT SW is started for the first time., [2. Fault Description] After successful autoconfiguration all parameters of autoconnection should be saved and autoconnection process cannot be executed again., The LN6.0 will lose configuration detected by FDSW1.0, and as consequence, LN6.0 will repeat autoconnection procedure., Description of the fault: Root cause: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 263/330 Version 1.0 Confidential


Configuration files generated by FDSW1.0 are accessible only for so-called root user. However, in LN60, the NMA process is not running under root user, but has own account. Therefore, LN6.0 NMA process is denied access to configuration file., Once this was corrected, another issue surfaced: IP address configuration was rejected as invalid by LN6.0. This was a programmatic error in LN6.0, since the particular validation functions should not be applied in case of sw upgrade. Probability: Permanent Workaround: No Workaround Description of the correction (incl. risk analysis): Two corrections are required in TRSW versions starting with LN60/LNt40: 1. NMA should take ownership of the configuration file migrated from FDSW1.0 before it changes user and group ID. 2. Correction in NMA to skip additional validations of IP addresses Impact to Operator: BTS startup time increased due to unnecessary repetition of BTS autoconnection procedure.

3.428 Fail during configuring 6RX carriers (4xLTE1.4+2xGSM) Problem report: 143916ESPE02 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: 1. Configure and activate RX carriers in order: LTE1.4-LTE1.4-LTE1.4-LTE1.4-GSM-GSM., [2. Fault Description] “Configure logical carrier failed occurs during last GSM carrier adding. If we set up GSM carriers first everything is ok. Wrong allocation of MERA resources in case of LTE1.4 and GSM sharing because the algorithm that determines which resources are free was working in a wrong way when LTE1.4 was used. , Issue is reproducible for VEGAS and RENO RM. Specific for LTE 1.4MHz., Configuration: * FHEB/FXEB (VEG24.06.R05) * HTX5.3.1, Summary of the original problem: Configuring and activating RX carriers failed in order: LTE1.4-LTE1.4-LTE1.4-LTE1.4-GSMGSM. Probability: Permanent Workaround: No Workaround, corrected condition for LTE1.4, Impact to Operator: Failure of logical carrier configuration

3.429 Open SSL CVE-2014-3567 Problem report: 122420ESPE04 Exists in: LN6.0 Corrected in: RL60 2.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 264/330 Version 1.0 Confidential


Severity: B - Major Customer Impact: Security Description: Security vulnerability identified by: CVE-2014-3567 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3567 "Memory leak in the tls_decrypt_ticket function in t1_lib.c in OpenSSL before 0.9.8zc, 1.0.0 before 1.0.0o, and 1.0.1 before 1.0.1j allows remote attackers to cause a denial of service (memory consumption) via a crafted session ticket that triggers an integrity-check failure." Probability: Permanent Workaround: No Workaround, Security vulnerability identified by: CVE-2014-3567 is closed, no functional changes. Impact to Operator: Denial of service (memory consumption)

3.430 eNB cells down without any alarm. Problem report: NA05718588 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: eNB cells down without any alarm.BCN synchronization failed with unknown reason, this triggered OAM fault 16 but fault 16 sent with incorrect source which cause no fault reported to host and no recover action performed. Related feature / functionality: WBTS_SYNC_59916 (UC: BCN synchronization) Probability: Occasional Workaround: No Workaround, Fault 16 & 4019 now sent with correct source (DSP CHIP ID) Impact to Operator: No alarm and recover action when BCN synchronization with DSP CHIPs failed

3.431 Actual read-only parameter value 'Serving OMS' missing Problem report: NA05710469 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Actual read-only parameter value 'Serving OMS' is missing from CM Editor. This read-only parameter is not missing from every eNB, but most of them. Upload is scheduled for every night and does not solve this issue., Root cause: The parameter "ServingOms" was not getting exported to configuration file when SCF is generated. This is because the PDDB converter which creates mibs had excluded servingOms from getting exported to SCF file., Solution: Added logic in nmi/3rd_party/saxon/convert.xslt to include ServingOms. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 265/330 Version 1.0 Confidential


Attached PR: NA05682262 Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: The parameter "ServingOms" was not getting exported to configuration file when SCF is generated.

3.432 KPI Active UE increased Problem report: NA05731793 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: After SW upgrade KPI Active UE increased., Root cause: Several UL related problems has been found. Problem in end of TTI recognition in UL cores in case of several UE groups. Part of UL counter internal statistics updated as cell based even they should be handled as UE group specific because UL PHY message for counter updating is handled by UE groups. Master core was not able to collect UL counter reports from same TTI correctly as they arrived from several UL cores. Attached PR: NA05709102 Probability: Permanent Solution / Workaround: No Workaround Solution: Several UL related problems has been found and corrected. Fixed end of TTI recognition in UL cores in case of several UE groups. Part of UL counter internal statistics changed as UE group specific because UL PHY message is handled by UE groups. Collection of UL counter reports from several UL cores in master core improved to combine counter values from same TTI together before reporting to LOM. Impact to Operator: Invalid values for UL counters M8001C150 and M8001C266.

3.433 After SW upgrade, the value of MaxnumUeul is changed from 10 to 7 Problem report: NA05727899 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: During SW upgrade MaxNumUeUl is changed from 10 to 7 (Only Band8 Cell)., Root cause: Parameter relations was changed but this was not taken over to migration rules. Because of this, migration correction was missed. Initial correction failed. Parameter conversion also found in BTS Site Manager., Solution: Parameter conversion changed to not convert maxNumUeUl on the SW upgrade. BTS Site Manager: Removed rule that converts maxNumUeUl from 10 to 7. Probability: Permanent Solution / Workaround: Modify manually maxNumUeUl back to correct value after SW upgrade. Impact to Operator: Parameter conversion modifies maxNumUeUl incorrectly.



3.434 UL User Throughput degradation after FULA activation. Problem report: NA05712805 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: C - Minor Customer Impact: Capacity & Performance Description: UL MCS is increased but, UL User Throughput is degraded after FULA activation. This can be discovered by special PING type lab test comparing EUlLa and FUlLa. Root cause: The number of PRBs assigned for scheduling requests (SRs) based on the preliminary MCS is defined as maxNumPrbsSr. No transport block size (TBS) is defined for SRs. Solution: PRB reduction for SRs has been disabled. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: UL User Throughput degradation after FULA activation.

3.435 Site fails to recover IPSec after long TRS outage (23hrs) Problem report: NA05722574 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: A number of LTE sites failed to recover IPSec after a transmission break that lasted over 23hrs. When completing short TRS breaks, the site always recovered. As Child SA lifetime expires on eNB, eNB sends QUICK_mode messages to initiate Child SA rekey. As SEG is simulated down, no response from SEG. It is observed that eNB is continuously sending quick mode messages to rekey Child SA irrespective of dpd timeout. Waited for 1 hr - eNB does not recover itself. As eNB is stuck in rekey process, so also no dpd alarm raised. , Root Cause: eNB is not initiating main mode message to recover the connection. eNB is also not raising DPD alarm when child SA is down and is in Quit mode., Solution: Change in adapter code is done to raise DPD alarm and to initiate main mode message to recover the connection. Attached PR: NA05722990 Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Site fails to recover IPSec after long TRS outage.

3.436 Multiple IPSec Tunnels between eNB and SEG after SW upgrade Problem report: NA05720123 Exists in: LN5.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 267/330 Version 1.0 Confidential


Corrected in: RL50 2.2, RL60 3.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Since SW upgrade of the eNB we see less sites with multiple tunnels, so we certainly see an improvement with this new software. In a network there will always be transmission interruptions (some short, other for a longer period). So we cannot avoid this. However there are still multiple IPSec Tunnels between eNB and SEG after SW upgrade., Root cause: 2 timers associated with the rekey process, IPSEC SA lifetime (configurable, here 45 min) and a second timer to establish the successor IPSEC SA before its expiry (in order to avoid traffic loss), which can be called "soft timer" and is determined by a fuzziness factor (50%) and margin of 180sec in order to gain a statistically distribution of the rekey process over many eNodeB., Solution: The rekey is initiated when soft timer (rekey time) expires. If the rekey fails continuously and "no proposal chosen" is keep on receiving during rekey attempts, this IPSEC SA will be deleted once its lifetime (Hard timer) expires and therefore the entry is cleaned up. The exact trigger (i.e. rekey failure reason ) which leads to this situation (IPSEC in rekey active state within eNodeB) is still unknown, with this fix the robustness of eNodeB IPSEC implementation is increased. No stacking of obsolete IPSEC SA observed, only when unknown trigger happens again a obsolete IPSEC SA can be added. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Multiple IPSec Tunnels between eNB and SEG.

3.437 Starting HO from queued measurement when UE release decision was already taken and scheduled Problem report: 116168ESPE01 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: C - Minor Customer Impact: User Plane Quality Description: UE do Handover, eNB send UeContextReleaseRequest in source cell with reason “radioconnection-with-ue-lost” , HO failed, after RRC reestablishment procedure eNB send UeContextReleaseRequest for the same S1APID in target cell.MME reply ErrorIndication with cause: unknown-pair-ue-s1ap-id. Root cause is starting HO from queued measurement when UE release decision was already taken and scheduled (ue release decision was made due to broken RASR procedure). Rest of the flow is result of that. Description of the fault: Starting HO from queued measurement when UE release decision was already taken and scheduled in LNT4.0_ENB_1311_594_00 How end user/operator could detect the problem: 1. Start RRC COnnection reconfiguration due to RASR 2. UE should sent measurement report (handover trigger) 3. UE should not sent RRC reconfiguration complete 4. Ho will be started instead of ue release It is hard to reproduce, it doesn't seem to be critical problem. Related feature / functionality:Legacy code Probability: Occasionally Solution / Workaround: No Workaround LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 268/330 Version 1.0 Confidential


Description of the correction: During failed RASR procedure (missing rrc connection reconfiguration) ue internal release event will be queued. Additionaly, after ue internal release decision, any measurement report will be silently discarded. Impact to Operator: HO success rate will be lowered. Unsuccessful handover preparation counters on source side may increase. This can have influence on KPIs.

3.438 Rl50 sites are all reporting Fetching faults Problem report: NA05679917 Exists in: LN6.0 Corrected in: RL50 2.1, RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Site Browser can connect to all the sites and collect the SW and cell status data but gets stuck with fetching eNB faults(alarms). Summary of the original problem: Fault fetching takes forever, How end user/operator could detect the problem: use old BTSSB (packaged with LN4.0 1202_777_00) and connect to BTS with alarms, Description of the fault: Site progress is stuck at Fetching faults, Related feature / functionality:BTS Site Browser, Alarms module, Dependency on configuration: None Probability: Permanent Workaround: Perform clean installation of LN6.0_BTSSM_1311_092_00 (only clean installation overwrites the currently installed BTS Site Browser version) Impact to Operator: Configuring multiple BTS sites will take a while. User can't proceed with any other operation (BTSSB becomes effectively unusable) for the sites stuck at Fetching faults.

3.439 PNP not possible with FSMF Problem report: NA05730697 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: After receiving the PKI certificate the IPSec tunnel is not used. It seems to be established, but no ESP packets are sent., Root cause: It was seen that PROTECT policy created during autoconnection was changed from one-to-one to one-to-any. This change was introduced to ensure that connection to the file/configuration server works fine which contained the Software. This caused a mismatch in the policy between eNB (which now has one-to-any) and SecGW (which remains to have one-to-one) hence leading to tunnel establishment failure. It was also seen that strongswan peers allow one-to-any to match with one-to-one but Juniper SecGW used in the setup does not allow this. Customer estimated that the effort to change the policy at SecGW is substantial and cannot be tried. , Solution: The older behavior of creating one-toone policy is restored now. Debugging for an alternate solution is ongoing. Probability: Permanent LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 269/330 Version 1.0 Confidential


Solution / Workaround: No Workaround Impact to Operator: PNP not possible with FSMF. After receiving the PKI certificate the IPSec tunnel is not used.

3.440 Alarm "Cell configuration data distribution failed" active in 4 eNB 4 cells Problem report: NA05713927 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: After running the plans 4 eNB:s 4 cells were in disabled state with alarm "Cell configuration data distribution failed" active. Alarms happen on eNB equipped with 3 cells and also 4 cells. The affected eNB:s were restarted and after the restart all the 4 cells were back onAir state. It was deadlock in UEC with hanging UE. Deadlock between two services - BearerMgr and MeasurementProcessing, and two procedures: ERabSetup including measurement reconfiguration and handover (on source). Test scenario (from UEC POV): 1. Ue attach and maybe some activity 2. Start ERab Setup procedure with measurement reconfiguration ** note: it is also possible to setup erab without measurement reconfiguration (but here it is needed) ** note: eRab setup isn't an atomic operation from UEC point of view (and here is a source of problems) 2a. ERab Setup: ebnc + RAC 2b. ERab: TRSW 2c. ERab Sretup: TUP/MAC user setup request (no response for MAC, some delay) 3. Measurement raport sent to UEC (just before MAC user setup response). It should cause ho decision and internal event HO_START_REQ is queued due to active ERAB procedure. 4. MAC response sent to UEC, measurement reconfiguration should be started but MeasurementProcessing is blocked. Finally: ERAB procedure is waiting for MeasurementProcessing and MeasurementProcessing is waiting for HO start and HO start is blocked due to pending ERAB procedure. Other procedures like ue release (including cell delete) are also blocked. Probability: Permanent Solution / Workaround: Restarting eNB clear the alarms and bring cells on air. Correction: added handling of abort event in MeasurementProcessing (it should avoid permanent deadlock). Impact to Operator: Cells goes in disable state. Deadlock in UEC with hanging UE

3.441 ETWS test fail Problem report: NA05719993 Exists in: LN5.0, LN6.0 Corrected in: RL60 2.0 Severity: A - Critical Customer Impact: Capacity & Performance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 270/330 Version 1.0 Confidential


Description: Occasionally UE cannot catch ETWS message. Root cause: A problem with MAC PS internal array for storing the BCCH Modification Paging occurs during high load of ETWS paging request coming from C-Plane plus additional high BCCH Mod Paging load., Solution: 1) When paging arrives in particular time frames some BCCH Mod paging request will no longer be stored permanently in the message buffer (hanging entries issue is resolved now). 2) An alarm will be raised at some special filling levels of the internal message buffer, before reaching the condition of "array full" in order to recognize the situation in an early state and being able to collect more information (traces). 3) If all 34 buffer entries are occupied (just before "message arry full") the "Safety Net" functionality has been added. It deletes the oldest entry in the message buffer in order to create more space for the new arriving request. Probability: Occasionally Solution / Workaround: No Workaround Impact to Operator: UE cannot catch ETWS message

3.442 In installed PC to "BTSSiteEM-LTE60-1311_092_05" and "WN5.0 SEM", it is not possible to SiteManager connection. Problem report: NA05731940 Exists in: LN6.0 Corrected in: RL60 2.0 Severity: B - Major Customer Impact: Capacity & Performance Description: Site Manager for LN6.0 and Site manager for WN5.0 was installed on the same machine. Then after input of user name and password network connection could not be established. Root cause: CL was not compatible with WN5.0 cl config file. Solution: The problem was fixed in RL60 and RL70 by updated cl.jar. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Network connection could not be established if Site manager for LN6.0 and WN5.0 was installed on the same PC.

3.443 Transmission Link Speed alignment failure Problem report: NA05676820 Exists in: LN6.0 Corrected in: Correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Description: 1. Set 1000Mbps Full Duplex both on FTIF and on the switch. 2. Check Transmission link speed alignment. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 271/330 Version 1.0 Confidential


FTTS equipment in front of eNB is a Cisco ASR901. Its port is configured as 1000Mbps Full Duplex. eNB FTIF port used is also configured as 1000Mbps Full Duplex and the link always stays down. If eNB FTIF port is changed to Autodetect, then the link comes up. Both side set as 1000Mbps Full Duplex should be compatible (it is working with other kinds of transport switch/router on SFR/Network). Issues with links speed can be checked using ddal debug commands on FTM shell. If eNB FTIF port is changed to Autodetect, then the link comes up. Probability: Permanent Solution / Workaround: Configure FTIF port always to Autodetect. Impact to Operator: eNB FTIF port was manually configured as 1000Mbps Full Duplex (same as partner side) but the link always stays down.

3.444 ENB use wrong UEContextReleaseCommand from buffer Problem report: 115356ESPE01 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: When ENB send a UEContextReleaseRequest message to MME, it doesn't wait for MME's response, just use a UEContextReleaseCommand in buffer which is received several seconds ago. Summary of the original problem: The use of the enqueued ReleaseCommand which does not correspond exactly to the ReleaseRequest sent before. “S1AP_Error_Indication not being sent out” is only the consequence of the connection already deleted by earlier ReleaseCommand. How end user/operator could detect the problem:, The use of the enqueued ReleaseCommand which does not correspond exactly to the ReleaseRequest sent before. “S1AP_Error_Indication not being sent out” is only the consequence of the connection already deleted by earlier ReleaseCommand., How end user/operator could detect the problem: MME release procedure not according to specified flow - but context is released. (no hanging resources) , Description of the fault: The use of the enqueued ReleaseCommand which does not correspond exactly to the ReleaseRequest sent before., UEC of source-eNB sends RRC_HANDOVER_COMMAND and waits for UeContextReleaseReq from target-eNB. But instead a S1AP_UE_CONTEXT_RELEASE_COMMAND arrives. This cannot be handled at this time and is enqueued. After some seconds the overall-timer expires and initiates the release which leads to S1AP_UE_CONTEXT_RELEASE_REQUEST sent to MME. Now UEC takes the S1AP_UE_CONTEXT_RELEASE_COMMAND from the queue, processes it and sends S1AP_UE_CONTEXT_RELEASE_COMPLETE to MME. From UEC pov the release procedure is OK. , However the MME has just received a new S1AP_UE_CONTEXT_RELEASE_REQUEST from eNB and replies with S1AP_UE_CONTEXT_RELEASE_COMMAND. Description of the correction (incl. risk analysis): Don't send S1AP_UE_CONTEXT_RELEASE_REQUEST request if S1AP_UE_CONTEXT_RELEASE_COMMAND was already received in state Wait for UeContextReleaseReq from HO Target. Only change in release procedure, low risk.



Attached: 103355ESPE01 Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: There is no apparent impact from customer pov (context should be released and was also really released), but this issue could and should be corrected and improved.

3.445 RF module failure (1907) after SW upgrade Problem report: NA05724142 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: A - Critical Customer Impact: Stability Description: Summary of the original problem: RFM SW available in RL60 0.1 (FRM34.05.R02G) package contained some bug in DPD (Digital PreDistortion) configuration. This has been found and fixed in FRM34.05.R03G (PR 117913ESPE04: The SEM case of FRGY testing failed with WN128540 SW during two cell opened). Now it has been proved that this problem was responsible for causing HW damage on few units. Fix is available in RL60 1.0 package How end user/operator could detect the problem: 1907 and 1920 alarm have been raised by RFM for the same antenna (note that 1907 has higher priority) Description of the fault: Due to some configuration error, data from one TX path of GAIA Asic were affecting DPD operation on the second TX. In some specific cases, this could lead to HW damage (PA overpower due to instable DPD) Related feature / functionality: This issue is technology independent. Dependency on configuration: This issue might occur only when main and diversity antenna is running Downlink signal. Probability: Occasional Solution / Workaround: No Workaround Problem has been fixed by changing configuration routines. Further occurrence is impossible, there is no risk. Impact to Operator: Occasional RF module failure (1907) after SW upgrade. This issue is known to damage some output PA on several units., After SW upgrade from RL50 to RL60 many site has RF module failure (1907) and cell are on-Air. In few sites happen this alarm 0.5~2 days after upgrade., Root cause: Adaptation in main pipe (pipe 3) goes bad as soon as adaptation in div pipe (pipe 4) is started. Things are OK in main pipe when div pipe has DPD runtime stopped. Seems that some part of data get mixed between the pipes., Solution: Corrected in newer RFSW. The performance is much more stable and if corr mixing is enabled the performance is as good as with the old original SW before upgrade.



3.446 Alarm 7738 "BTS WITH NO TRANSACTIONS" seen on 2g BTS and fixed after Block/Unblock of 4g RF module Problem report: NA05734407 Exists in: LN5.0 Corrected in: RL50 2.1, RL60 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: 2G cell is not carrying traffic after Abis link breaks and BCCH reconfiguration How end user/operator could detect the problem (How Operator can see the problem?): Alarm 7738 BTS WITH NO TRANSACTIONS is raised Description of the fault: 2G Abis links have been disconnected and re-established, BCCH has been reconfigured. 2G has recovered but BTS alarm 7738 BTS WITH NO TRANSACTIONS has been raised after the supervision period. 2G has sleeping cell. LTE is carrying traffic. Issue is sporadic and occurring rarely. Related feature / functionality: BB hopping Dependency on configuration: LTE-2G RF sharing configuration in use. Probability: Rare Solution / Workaround: Block/unblock of 4G RF Module Impact to Operator: 2G cell is not carrying traffic

3.447 BTS autonomous reset as recovery action (4019 FSME) occurred during ADR degradation. Problem report: NA05706737 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Capacity & Performance Description: During eNB startup procedure there is a possibility to get incoming X2 connection before ENBC registration. In that case optional ENBC address is not set. In this procedure TUPc uses undefined ENBC addres., ENBC address is an optional, which was not checked during incoming ANR X2 link handling procedure. That caused throwing an exception from TUPc and "crash". End user can observe this error as a prolonged wae up time of the ENB Description of the fault: During eNB startup procedure there is a possibility to get incoming X2 connection before ENBC registration. In that case optional ENBC address is not set. In this procedure TUPc uses undefined ENBC addres. Related feature / functionality:CPLANE/TUPc module Core CPLANE functionality is affected by this error. All TUPc functionality and depended one ( UE management and CELL management, connection with other eNB’s ), Dependency on configuration: Yes. This error can be observed in the network with adjacent eNB’s. , Description of the correction (incl. risk analysis):



In case of incoming X2 link handling TUPc will check presence of ENBC address which prevent not set optional usage. Instead of this the ANR link will be closed (the same as in case when ANR is disabled). Behavior in that case is the same as in previous releases. No risks. Probability: Occasional Workaround/Solution: This error is result of coincidence of tasks in resetting BTS and adjacent BTS. Probability of this error is very small. Typically reset of BTS is enough to overcome problem. Impact to Operator: Operator can observe this error as a crash of TUPc in the early phase of operation after reset/startup of ENB. This error provokes additional reset of CPLANE and BTS

3.448 When adding MTRACE on BTSSiteManager for Trace UE specific message for RRC, S1 & X2 there is no option to input any value Problem report: NA05703212 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Capacity & Performance Description: There is no option to input value for RRC, S1 & XE UE Specific Trace Messages on the MTRACE. Thus not able to provision MTRACE for UE specific RRC, S1 & X2 messages from BTS Site Manager. , On eNB running release LN6.0_1311_617_01 and BTS site manager LN6.0 (1311_092_02) add and MTRACE for trace UE specific message for RRC, S1 & X2., How end user/operator could detect the problem: Create MTRACE mo, then delete it and add it again, MTRACE Trace UE specific message for RRC, S1 & X2 becomes unmodified, Related feature / functionality: LTE644 Probability: Permanent Workaround/Solution: no W/A. Added checking for parent MO if it already exists or not in SCF Impact to Operator: Cannot create MTRACE Trace UE specific message for RRC, S1 & X2 Cannot configure LTE644 correctly

3.449 Incorrect PDCCH capacity estimation Problem report: 119809ESPE04 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Capacity & Performance Description: PDCCH capacity estimation is incorrect in case the number of UEs in CS1 list changes. In this case the PDCCH capacity estimation is done with the number of TD selected UEs from the TTI before the current TTI. This leads to incorrect PDCCH capacity estimation and removing of UEs during FD scheduling phase., Root cause: PDCCH estimation was incorrect in case number of UEs in CS1 list has LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 275/330 Version 1.0 Confidential


changed. This leads to unused or lack of PDCCH capacity, Solution: Moving PDCCH estimation after TD scheduling phase. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Incorrect PDCCH capacity estimation and removing of UEs during FD scheduling phase.

3.450 FRHA was happened RF module failure with FID 1841 Problem report: NA05704929 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Stability Description: When there are some disturbance in Ethernet communication software was closing UDP socket to prevent sending data (UDP is connectionless). It appears that operating system can open/close UDP socket only 40 times. After that socket couldn’t be open and further communication was broken. It led to 1841 alarm and RFM restart. Solution: Opening and closing socket was replaced with special flag which enable or disable communication over UDP port Probability: Occasional Solution / Workaround: RFM reset Impact to Operator: 1841 alarm occur with RFM restart.

3.451 CMP CertConf message not sent after SW upgrade Problem report: NA05707825 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: After SW upgrade site is on air (IPsec tunnels were established with certificates obtained on old SW level), but eNB is unable to get the certificates any more., 1) If we manually trigger certificate update it sends CMP kur message, receives CMP kup message, and then eNB doesn’t accept received certificates, and doesn’t send CMP CertConf message. 2) If we manually trigger initial certificate request, it sends CMP ir message, receives CMP ip message, and then eNB doesn’t accept received certificates, and doesn’t send CMP CertConf message., Root cause: The issue has occured because of profile validation check which was introduced as a fix for another fault report. The profile validation is partially done., Solution: Now proper profile validation is done both for CA certificates and RA certificates. For RA certificates in Key Extension it should have "Digital Signature" and for CA certs in key Extensions it "keyCertSign" present. Probability: Permanent Solution / Workaround: No Workaround LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 276/330 Version 1.0 Confidential


Impact to Operator: If IR request was triggered then Certificates (RA certificates) are rejected.

3.452 "Zero attempt" was detected after SW upgrade Problem report: NA05704957 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: A while after SW upgrade one cell is not accepting any attaches when other cells are accepting. Only known workaround is site reset., Root cause: Race condition between MAC PS support/core task while startup. System startup does not finish Probability: Occasional Solution / Workaround: No Workaround SW correction to synchronize MAC PS support/core task while startup by messages to fix race condition. Impact to Operator: Cell Configuration Data distribution failed alarm (6253) triggered after BTS reset. Cell is not accepting any attaches.

3.453 FTIB (FSME) got reset due to "FpgaLib: Last reset was: Watchdog reset" Problem report: NA05696268 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: C - Minor Customer Impact: Stability Description: Watchdog reset on the FTIB (FSME). Watchdog reset can be triggered by hardware issue or also be kernel panic. But current logging mechanism was not sufficient to debug that. Solution / Workaround: Description of the correction (incl. risk analysis): To improve this kernic panic logging is added which is stored in SRAM and is available after reset. Also a new reset cause is introduced "Kernel Reset" to differentiate between hardware watchdog and kernel panic reset. Watchdog timer increased from 10 seconds to 30 seconds Probability: Occasional Impact to Operator: Call drop and Service Outage due to eNB reset.

3.454 Unit autonomous reset as recovery action Problem report: NA05694294 Exists in: LN6.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 277/330 Version 1.0 Confidential


Corrected in: RL50 2.1, RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: FSP/DSP crash happened occasionally and there is big BCN delay from FSP/DSP response. FSMF unit out of service. DSP crash will result in a retrying device. Cavium won't drop a message after a timeout without the setup of the retry threshold value., Root cause: Silent DSP crash lead to disturbed communication (messages type11) to all other devices. Solution: The retry threshold was configured to 240. We also traced a typical response message for messages which will arrive around 1us later. Response timeout is 250 and a message will be dropped after that time if the far device doesn't react in time. There should be no risk for unexpected message drops since the retry threshold is in the same region as the response timeout. Attached PR: NA05690487 Probability: Occasional Solution / Workaround: No workaround Impact to Operator: BTS autonomous reset appeared in eNB. FSMF unit is out of service.

3.455 DSP reset with fault ID 418 Problem report: NA05704190 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Buffer overrun in CTimeAlignment::m_OutofSynchExtDrxUeIndexArray causes DSP reset with fault ID 418., Root cause: If more UEs are detected as OOS in one TTI than fit into this array, then adjacent variables would have been overwritten., Corrections: - Check array index before writing to m_OutofSynchExtDrxUeIndexArray. - If array already full, then ignore OOS UE and write ERR to syslog. Probability: Permanent, Solution / Workaround: No Workaround Impact to Operator: DSP crash occur with fault ID 418.

3.456 Unit autonomous reset as recovery action detected and recovered(fault =4019) on MRBTS-450909 Problem report: NA05708386 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 278/330 Version 1.0 Confidential


It was detected the Unit autonomous reset as recovery action and recovered(fault =4019) on FSPC., Description of the fault: - Logs showed that kernel oopses happen. - Kernel oops happened due to access to invalid memory. - Memory was invalid because address was overwritten by NULL. -This can be caused by different reasons, which can’t be specified more precise based on present logs. -CASA reset was only code change in this area. The fault did not happen before. Most likely root cause could be therefore CASA reset commit, that we rolled back now. , How end user/operator could detect the problem: Unit autonomous reset as recovery action detected and recovered(fault =4019) will be observed. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Unit Reset.

3.457 maxNumCaConfUeDc changed after SWACT during upgrade or fallback Problem report: NA05707344 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: Value of maxNumCaConfUeDc is changed, even if the original value was correct. Root cause: Wrong migration for maxNumCaConfUeDc., How operator could detect the problem: Value of maxNumCaConfUeDc is changed, even if the original value was correct. Solution: Following rules changed: - LNCEL-maxNumActUE maxNumActUE = maxNumCaConfUeDc (public). - If maxNumActUE is set smaller than maxNumCaConfUeDc, then the value of maxNumCaConfUeDc will be set same as maxNumActUE. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Wrong migration for maxNumCaConfUeDc during SW upgrade or fallback.

3.458 Abnormal high value of PDCP_SDU_UL_LR_QCI6 (LTE_1222A) detected Problem report: NA05700682 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: Abnormal high value of PDCP_SDU_UL_LR_QCI6 (LTE_1222A) detected occasionally. Root cause: This counter is calculating packets gap, based on SNs. In exceptional cases when the LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 279/330 Version 1.0 Confidential


delayed packet was send (which had SN 4) and the last send packet had SN 5 the SN gap difference is calculated by (currentSN – lastSN - 1). In this case it would be a negative value (4 – 5 - 1). With 12bits SN value, such negative results cause calculated SN gap with entire range of 12bits value and appear as extreme high values., Solution: SW correction to moved SN gap calculation earlier than packet sends, when all packets, were still in correct order. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Abnormal high value of counter PDCP_SDU_UL_LR_QCI6 detected.

3.459 RRC connection reject with MAC_UserSetupResp Problem report: NA05698134 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Capacity & Performance Description: At eNB occurred RRC rejection count. This is not very frequently, but it makes RRC connection reject counters sometimes., Exception situtation was handled wrongly in L2. L2 does not get response in message RadioBearerSetupReq from WMP MAC PS. L2 send RadioBearerSetupResp with NACK to L3 and start internal releasing. Internal release is still ongoin when L3 Send UserDeletionReq and because internal release is ongoing StateMachine discard the message handling and in the end we will get hanging user. This is now corrected in L2. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: UeID Misalignment between L3 and L2. In this case it is not possible to attach user in certain UeId.

3.460 Increased LTE_5807c (E-UTRAN Avg. Active Ues with data in the buffer for QCI1 DRBs UL) after SW upgrade Problem report: NA05693926 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: Counter group M8001 AVG counters doesn't work properly. There are unrealistic values in counters., Root cause: Averaging method that was introduced doesn't work in all cases, especially counter M8001C419 (UE_DRB_UL_DATA_QCI_1) doesn't seem to work correctly. Problem exists with FSMF only., Solution: Averaging method removed and several other bugs corrected. Counter update frequency increased (updated in every millisecond at the end of every TTI) to get counter values more specific when additional averaging not needed anymore. Possible risks: CPU loads might get increasing but should be in acceptable level still. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Counter group M8001 AVG counters doesn't work properly. There are unrealistic values in counters. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 280/330 Version 1.0 Confidential


3.461 The E-UTRAN Average Latency Downlink (LTE-5134A) count has abnormal values Problem report: NA05698304 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Description: The E-UTRAN Average Latency Downlink (LTE-5134A) count has abnormal values. Root cause: Counter registration of unused counters in MAC PS., M8001C2 should be registered as AverageWithWeight. MAC PS register M8001C2 as EPmCounterType_Average, it’s not being used value in MAC PS. MAC DATA register M8001C2 as EPmCounterType_AverageWithWeight. It makes LOM to report counter as EPmCounterType_Average to OAM, and OAM sum this value and it could make abnormal value of counter. , Solution: Registration of unused counters removed. Probability: Occasional Solution / Workaround: No workaround Impact to Operator: E-UTRAN Average Latency Downlink (LTE-5134A) counter is not reliable.

3.462 PDCP config for turning off ROHC fails when UE comes to Nokia eNB from other vendors eNBs by HO with DRB id 1 for QCI 1 bearer Problem report: NA05712521 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: When UE comes from other vendors eNB with drb identity 1 for QCI 1(ROHC on), Nokia eNB doesn't send PDCP config for turning off ROHC. Then, the user experiences silent and QCI 1 bearer is released. Note that it works fine with other drb identitiesother than drb identity 1., Root cause: When drbToAddModList was not configured properly in HORequest (if it was unsorted), it resulted in mismatch of drbIds from source and target cell, therefore ROHC deactivation didn't work well., Solution: Now, before performing HO, both source and target lists are being sorted by drbId. So source and target configuration of bearers is being compared properly. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: ROHC deactivation didn't work after performing inter handover. End-user could have problems with call muting.



3.463 Cell load of NonGBR does not decrease even though Active CU is smaller than 1 Problem report: NA05708791 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Capacity & Performance Description: After CA and IFLB activation in SW. "Active Conn UE" is smaller than 1, but Cell load of NonGBR keeps 42%. It seems that number of Active CU are smaller than 1 during high load. Cell load of NonGBR does not decrease even though Active CU is smaller than 1. Root cause: MAC-PS calculates the average of scheduling weights of active nonGBR bearers (bearers with data in buffer) over the time. This calculation is based on the sum of scheduling weights of all active nonGBR bearers updated every TTI. When calculating the sum of scheduling weights mentioned before in case of a carrier aggregation UE the scheduling weights are distributed between the cells according to the averaged throughput of a cell related to the averaged throughput over all cells. When calculating the share in case of a CA UE QCI5 bearers used as signaling bearers were handled differently from nonGBR bearers whereas in all other cases QCI5 signaling bearers were handled in the same way as nonGBR bearers. As a result the wrong scheduling weight share was used when updating the sum of scheduling weights e.g. in case of state transition of such a bearer from active to non active., Solution: Handle QCI5 signaling bearers like nonGBR bearers in all cases. Probability: Permanent Solution/ Workaround: No workaround Impact to Operator: Cell load of NonGBR keeps 42% even if Active Conn UE’ is smaller than 1.

3.464 FXEA not detected after SW upgrade Problem report: NA05697999 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: Cross connected RF's are not detected anymore after SW upgrade in several configurations (Rel2.1/2.2 RFM connected using 2 optic link to SM, cross-connected)., Root cause: There was a condition added in handler for 'system timer lost' to check actual state of system timer. If handler is called but system timer is OK than timer resynchronization is skipped. This caused problems when system timer handler was called from SetClockSourcePort handler to force system timer resynchronization. Unfortunately new condition prevented resynchronization procedure from happening when system timer had actual OK status., Solution: System timer resynchronization is now forced in case of changing ClockSourcePort, regardless of actual system timer status. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: FXEA not detected in BTS Site Manager after SW upgrade. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 282/330 Version 1.0 Confidential


3.465 X2HO Preparation fail rate was increasing by RACH problem of target cell. Problem report: NA05704932 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Capacity & Performance Description: During the normal operation, X2 HO preparation rate was decreased suddenly by RACH problem of target cell. For recovery of this KPI, Target eNB's cell must be reset by Cell or RFM block/unblock., Root cause: During UE attach procedure an internal message PS_UeReconfigReq is sent from L2 to both DL and UL scheduler (MAC_PS). PS_UeReconfigReq msg handling succeeds in UL scheduler so it sends PS_UeReconfigResp with OK back to L2. But this procedure (PS_UeReconfigReq msg handling) fails in DL scheduler so it sends PS_UeReconfigResp with NOK. Upon receiving response with NOK L2 terminates user setup procedure by sending MAC_UserSetupResp with NOK to C-Plane. However this UE remains hanging in UL scheduler with allocated UE index., Solution: Upon receiving PS_UeReconfigResp with NOK from MAC_PS L2 will send UE delete request to MAC_PS (both schedulers) as well as send the response to C-Plane. Probability: Permanent Solution / Workaround: Target eNB's cell must be reset by Cell or RFM block/unblock Impact to Operator: X2HO Preparation fail rate increasing and Rach SR decreasing.

3.466 Initial Context Setup Fails with TNL fail happen often on site Problem report: NA05700605 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: During the normal operation "initial context fail" occur with TNL Fail (Transport resource unavailable). It happens at random customer sites. Root cause: Handover Target was interrupted by Tup Error Ind msg and finished immediately. That's why the forwarding channels weren't released in TRSW and caused hanging resources. Normally these hanging resources will be release with UeContextRelease except an Intra eNB Handover follows, Solution: Tup Error Ind msg will be queued to make sure that HO releases all forwarding channels. The problem is hard to detect, because the hanging resource will be only noticed when the eTeid is used next time (can last hours when the traffic is low). Probability: Permanent Solution / Workaround: No Workaround, Impact to Operator: During the normal operation "initial context fail" occurs with TNL Fail (Transport resource unavailable) which is caused by hanging resources.



3.467 LNADJ status unavailable Problem report: NA05703985 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: Many of LNADJs are unavailable status after created by ANR. Even all of conditions are normal., Root cause: Unsuccessful X2 link setup due to connect problem caused inconsistent link state between ENBC and TUPc. Because of this following attempts to set up a link with the same link id failed., Unsuccessful X2 link setup due to connect problem caused inconsistent link state between ENBC and TUPc. Because of this following attempts to set up a link with the same link id failed. How end user/operator could detect the problem: eNB is unable to successfully set up a new link with id previously used for a link that was configured with an invalid address (0.0.0.0 in this case). Description of the fault: Upon link connect failure TUPc notified ENBC not releasing its resources for the faulty link and waiting for the link deletion request, while due to inconsistent system specification ENBC assumed that requesting the link deletion on TUPc is not necessary. This lead to a state where link resources were not properly released on TUPc side due to lack of release request to do so from ENBC side, which made following link setup requests for the link id failing. Related feature / functionality: LTE1383 ANR Robustness Probability: Occasional Solution / Workaround: No Workaround, Solution: TUPc behavior was aligned so it releases link resources immediately upon encountering such connect failure. Impact to Operator: Many of LNADJ status are unavailable.

3.468 Increase in RACH Attempts is seen but no change in the RRC attempts. Problem report: NA05690457 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Description: RACH setup success rate degradation occurred. Ghost preambles were detected because of wrong handling of intermediate data in PRACH, after an interrupt was triggered by PUSCH. There was a possibility of data from one antenna to overwrite data of the next antenna. Summary of the original problem: RACH setup success rate degradation on 4Rxsites How end user/operator could detect the problem: RACH setup success rate degradation LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 284/330 Version 1.0 Confidential


Related feature / functionality: 4Rx Rach Dependency on configuration: 4RX Probability: Permanent Solution / Workaround: No Workaround, Intermediate data in PRACH is handled in a way that avoids overwriting of another antenna data. Low risk - no changes in amount of allocated memory is needed, just corrected offsets to where save intermediate data. Impact to Operator: eNB is detected RACH preambles even there is not a single RACH preamble really transmitted from any UE.

3.469 4019FSPD error in corresponding unit reset recovery Problem report: NA05690772 Exists in: LN6.0 Corrected in: RL50 2.1, RL60 1.0 Severity: B - Major Customer Impact: Stability Description: Error 4019 FSPD reset and corresponding unit reset recovery occurs once after the deployment of RL60 3.0PD and activation of 20+10 CA., Root cause: Reception of an S1AP_DOWNLINK_NAS_TRANSPORT message during a later failing (path switch error) reestablishment causes an infinite loop in UEC. The infinite loop is caused by the reestablishment service which doesn’t reset the store NAS state after failed path switch., This problem was very rare, error happens only if path switch fails, it occurred about 1%., SW Correction: Reset the store NAS state after failed path switch. Probability: Occasional Attached PR: NA05712742 Solution / Workaround: No Workaround Impact to Operator: UEC stuck in endless loop and doesn't send keep alive message anymore. For this reason FSP was reset and 4019 FSPD error occur. Effects on end-user: No service during FSP reset.

3.470 VoLTE call drop during on-hold mode Problem report: NA05710970 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Capacity & Performance Description: Customer reported a VoLTE call drop issue after few seconds from on-hold mode. This issue was seen on several type of VoLTE UE. It seems no abnormal behavior on S1AP/RRC/NAS/SIP messages but suddenly UE sends SIP: BYE after 35sec from on-hold., Root cause: Nyquist DSP is not able to invalidate & write back the L2 cache lines correctly if the invalidated data is located in the memory in a specific way. If the cache line boundary is



exceeded only by one 4-byte word, this single word is never invalidated / written back correctly. Probability: Permanent Solution / Workaround: No Workaround Solution Checking for the invalidate / writeback addresses and lengths added to L2 cache functions. Invalidate/writeback length is increased by two words in a case where the cache line boundary exceeded by one word Impact to Operator: Unexpected VoLTE call drops after few seconds from on-hold mode.

3.471 Cell state is disabled without alarm Problem report: NA05697252 Exists in: LN6.0 Corrected in: RL60 1.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: After sending invalid cell configuration (parameter prsBandWidth) the cell is disabled and "7653 CELL FAULTY" alarm (fault 6257 Cell reconfiguration data distribution failed) is raised. Block/unblock of the affected cell clear the alarm, but cell stays in disabled state. Problem appears only if cell configuration is invalid. Probability: Permanent Solution / Workaround: Avoid sending invalid cell configuration to eNB. Impact to Operator: Affected cell is not available

3.472 High amount of FXFC hardware failure occurrences in the network. WN8.0 Problem report: NA05694129 Exists in: LN5.0, LN6.0 Corrected in: RL50 2.1, RL60 1.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: High amount of FXFC hardware failure occurrences in the network, Optical Interface Alarm. Some nodeB outages were due to to broken FXFC unit. The units which have fatigued during the use of non corrected SW may fail within short period of time. PA failures are happening due to software-based, overdrive conditions which lead to the breakdown voltage of the PA device being exceeded. One potential source of overdrive is an error in the radio initialization sequence. Another contributor identified is a problem in the gain control algorithm. Variations in network traffic loads exacerbate these gain control errors. Probability: Permanent Solution / Workaround: No Workaround RL6.0_1.0 and subsequent releases include a change to the radio initialization sequence that will reduce the risk of PA failures Impact to Operator: Units which have fatigued during the use of non corrected SW may fail within short period of time.



3.473 More IPSec tunnels setup then configured in eNB Problem report: NA05617573 Exists in: LN4.0, LN5.0, LN6.0 Corrected in: RL50 2.1, RL60 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: The eNB and SecGW can negotiate at a certain time more than one IKE having each child SA (IPSEC tunnels). This can lead to more IPSEC tunnels than the ones configured. After it can happen (for example when IPSEC GW send delete notification of child SA under different IKE SA) that the eNB rejects that deletion but continues to rekey that child which the SEC GW neglects (NO PROPOSAL CHOSEN) leaving child SA in rekey active state on eNB side. Solution: Two Strongswan patches are introduced to resolve this case. One will check the task queue and confirm if there is any CHILD_CREATE task with same connection name. And if present then it will ignore the request. Second will delete expire SA. Attached PR: NA05694978 Probability: Permanent Operation & Maintenance No Workaround Impact to Operator: Multiple ChildSA are getting established at Customer Site. Only one CHILD SA is ESTABLISHED and rest is in REKEY ACTIVE state. Charon is not able to delete the active REKEY process that is failing continuously.

3.474 eNB start up delay after SW activation Problem report: NA05704754 Exists in: LN5.0 Corrected in: RL60 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Description: eNB start up delay after SW activation. After software activation, FTM was not resetting. It was happening as it was stuck in reset. Additional eNB reset caused by FTIB occurred after SW activation., Root cause: FTM was getting hung in Sync command due to which it was suspected that there was some issue with the file system., Solution: Recovery loop is added such that in case FTM is not resetting within 1 minute then "reboot -f -n" will be called every 60 seconds to reset the board. Probability: Occasional Solution / Workaround: No workaround Impact to Operator: After software activation, FTM was not resetting. It was happening as it was stuck in reset. FTIB caused an additional eNB reset.

3.475 RL50 MP 2.0: Sleeping cell on eMarupe_2600 Problem report: NA05702426 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 287/330 Version 1.0 Confidential


Exists in: LN5.0, LN6.0 Corrected in: RL50 2.1, RL60 1.1 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Description of the fault: Cell has no DL traffic to UE, The FFTC pop errors occurring in DL PHY are a result of the DL PHY process in the DSP being blocked for a significant number of CPU cycles (i.e. – stalls). When this happens, the CELL “sleeps”, that is no more traffic in Downlink over the air occurs, since the last symbol send out in on the air is stuck in the FFTC. In order to prevent the “cell sleeps” whenever an FFTC pop error occurs, DL PHY has integrated a method into their application which will retry several times to pop from FFTC TX queue, which prevents the “sleeps” whenever an FFTC pop error is detected. This method has already been incorporated into trunk and now it is being back ported to other branches. Probability: Occasional Solution / Workaround: Description of the correction (incl. risk analysis) When FFTC pop errors in DL occur because of CPU stalls, a retry several times is applied to the FFTC TX retrievals. This results in a continuation of DL traffic Impact to Operator: No signal on air. The CELL “sleeps” may occurred, that is no more traffic in Downlink over the air. Attached PR: NA05700598 No signal on sector2

3.476 prachFreqOff changed after SoftWare Activation or reset Problem report: NA05695318 Exists in: LN5.0, LN6.0 Corrected in: RL50 2.1, RL60 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Parameter prachFreqOff was changed from 3 to 4 after SW update in 15MHz Bandwidth site., Root cause: Parameter dlMimoMode is changed, which caused change of MaxPucchResourceSize and then change of prachFreqOff., Solution: dlMimoMode handling corrected.Related feature / functionality: CRL0973 Attached PR: NA05702579 Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Parameter prachFreqOff was changed from 3 to 4 after SW update in 15MHz Bandwidth site.

3.477 System Module Failure due to UEC Crash Problem report: NA05709300 Exists in: LN5,0, LN6.0 Corrected in: RL50 2.1, RL60 1.1 Severity: C - Minor Customer Impact: Stability Description: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 288/330 Version 1.0 Confidential


UEC crash was detected with internal system module failure. This causes UEC to be crashed and restarted. Root cause: In S1HOExecTgt there was an raw pointer pointing on memory that can be fried in other procedure. In that case, we have segmentation fault and UEC is killed., Related feature / functionality:S1 Handover from LTE to WCDMA. Dependency on configuration: Fsmr2 only. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: System Module Failure due to UEC Crash.

3.478 UnitAutonomous(52) and KeepAliveStatusError(4019) occurred on FSPC of high load cell. Problem report: NA05693184 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Capacity & Performance Description: UnitAutonomous(52) and KeepAliveStatusError(4019) occurred on FSPC of high load cell. LINUX Kernel OOPS happen and CPU Load increases while connecting with SSH., Root cause: The tty atomic_write_lock does not provide an exclusion guarantee for the TTY driver if the termios settings are LECHO & !OPOST. And since it is unexpected and not allowed to call TTY buffer helpers like tty_insert_flip_string concurrently, this may lead to crashes when concurrect writers call pty_write. In that case the following two writers: * the ECHOing from a workqueue and * pty_write from the process race and can overflow the corresponding TTY buffer like follows., Solution: Kernel fix for TTY buffer handling. Attached PR: NA05697549 Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: UnitAutonomous(52) and KeepAliveStatusError(4019) occurred on FSPC of high load cell.

3.479 After RL50 upgrade RETs are not detected and Antenna line device failure alarms raised Problem report: NA05680713 Exists in: LN6.0 Corrected in: Solution provided with CR: CNI-2509. No plans to release this CR in maintenance. Severity: A - Critical Customer Impact: Operation & Maintenance Description: Starting from RL50 when alDCVoltageEnabled=true and MHA is not used it may happen that RETs will not be detected and Antenna line device failure alarm will be raised. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 289/330 Version 1.0 Confidential


Problem occurs when short circuit is detected in the same time on all ports. In such case is raised alarm EFaultId_Rs485PowerFailureAl (1214) which causes turn off RET port. In rest of the cases (not on all ANT ports are detected short circuit in the same time) EFaultId_Rs485PowerFailureAl (1214) is not raised and RET port remains on. Issue can be met if MHA is not used and alDCVoltageEnabled=true Probability: Occasional Solution / Workaround: If MHA is not used set alDCVoltageEnabled=false Impact to operator: In case of problem occurrence RET’s doesn’t works and cannot be detected. All KPI’s for which RET’s disabling can have impact

3.480 Paging messages cannot be sent sometimes to UE in a weak/strong electric field. Problem report: NA05681287 Exists in: LN6.0 Corrected in: RL50 2.1, RL60 0.1 Severity: A - Critical Customer Impact: User Plane Quality Description: In some sites involved in ETWS (Earthquake and Tsunami Warning System) testing it was observed that occasionally (3/11) ETWS broadcast failed due to missing paging (not visible over the air). The problem was reproduced in the field, it was observed that the occurrence depends on RF conditions (problem more frequent in poor radio conditions), ETWS broadcast problem was caused by MAC layer SW defect. Once problem was triggered: • wrong message array allocation limits overall paging capacity for both types of paging (Pcch / Bcch) leading to occasional paging scheduling failures. • depending on the amount of paging procedure: it is still possible to handle some paging operation successfully as long as “incoming rate of paging related requested towards MAC doesn’t exceed ~1/20ms” if it does – operation will fail due to lack of message array resources., In poor RF conditions, more re-tries triggered by MME are expected if normal paging doesn’t go through which implies higher message array utilization – increased probability of ETWS failure., Related feature / functionality:ETWS Probability: Occasional Solution / Workaround: Cell resource re-initialization (SM restart or cell lock / unlock operation) Impact to Operator: Once problem was triggered: wrong message array allocation limits overall paging capacity for both types of paging (Pcch / Bcch) leading to occasional paging scheduling failures. Reliability of ETWS BCCH paging in the high load paging scenario and high interference environment.

3.481 Red Hat Security Patches - September 2014 Problem report: 116216ESPE0 Exists in: iOMS5.0, iOMS6.0 Corrected in: iOMS5.0 2.1, iOMS6.0 1.1 Severity: B - Major Customer Impact: Capacity & Performance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 290/330 Version 1.0 Confidential


Description: Bash which is used in OMS is vulnerable to external access from the internet. RedHat security updates (including ShellShock fix) needs to be applied to OMS. RHEL5 updates: Critical: bash security update, RHSA-2014:1293 & RHSA-2014:1306 (bash-3.233.el5_11.4.x86_64.rpm) openssl security update, RHSA-2014:1053 (openssl-0.9.8e-27.el5_10.4.x86_64.rpm) glibc security update & glibc bug fix update, RHBA-2014:1213 (glibc-2.5-123.i386, glibc-2.5123.x86_64.rpm, glibc-common-2.5-123.x86_64.rpm) kernel security and bug fix update (https://rhn.redhat.com/errata/RHSA-2014-1143.html) + Red Hat Enterprise Linux 5 kernel update (https://rhn.redhat.com/errata/RHBA-2014-1196.html) (kernel-2.6.18-398.el5.x86_64.rpm, kernel-devel-2.6.18-398.el5.x86_64.rpm, kernel-headers2.6.18-398.el5.x86_64.rpm) procmail security update, RHSA-2014:1172 (procmail-3.22-17.1.2.x86_64.rpm) nss and nspr security, bug fix, and enhancement update, RHSA-2014:1246 + Important: nss security update, RHSA-2014:1307 (nss-3.16.1-4.el5_11.x86_64.rpm) krb5 security and bug fix update, RHSA-2014:1245 & Moderate: krb5 security update, RHSA2014:1255 (krb5-libs-1.6.1-80.el5_11.x86_64.rpm) tzdata enhancement update, RHEA-2014:1253 & RHEA-2014:1242 (tzdata-2014g1.el5.x86_64.rpm, tzdata-java-2014g-1.el5.x86_64.rpm) redhat-release enhancement update, RHEA-2014:1230 (redhat-release-5Server5.11.0.2.x86_64.rpm) hwdata enhancement update, RHEA-2014:1220 (hwdata-0.213.30-1.el5.noarch.rpm) dmidecode enhancement update, RHEA-2014:1208 (dmidecode-2.12-1.el5.x86_64.rpm) udev bug fix update, RHBA-2014:1239 (libvolume_id-095-14.32.el5.x86_64.rpm, udev-09514.32.el5.x86_64.rpm) nfs-utils bug fix update, RHBA-2014:1235 (nfs-utils-1.0.9-71.el5.x86_64.rpm) httpd bug fix and enhancement update, RHBA-2014:1232 (httpd-2.2.3-91.el5.x86_64.rpm, mod_ssl-2.2.3-91.el5.x86_64.rpm) device-mapper-multipath bug fix update, RHBA-2014:1228 (device-mapper-multipath-0.4.763.el5.x86_64.rpm, kpartx-0.4.7-63.el5.x86_64.rpm) mkinitrd bug fix and enhancement update, RHBA-2014:1224 (mkinitrd-5.1.19.682.el5.x86_64.rpm, nash-5.1.19.6-82.el5.x86_64.rpm) e2fsprogs bug fix update, RHBA-2014:1222 (e2fsprogs-1.39-37.el5.x86_64.rpm, e2fsprogslibs-1.39-37.el5.x86_64.rpm) lvm2 bug fix and enhancement update, RHBA-2014:1218 (lvm2-2.02.88-13.el5.x86_64.rpm, device-mapper-1.02.67-2.el5.x86_64.rpm, device-mapper-event-1.02.67-2.el5.x86_64.rpm) shadow-utils bug fix update, RHBA-2014:1217 (shadow-utils-4.0.17-23.el5.x86_64.rpm) initscripts bug fix and enhancement update, RHBA-2014:1210 (initscripts-8.45.451.el5.x86_64.rpm) gcc bug fix update, RHBA-2014:1209 (libgcc-4.1.2-55.el5.x86_64.rpm, libgcc-4.1.255.el5.i386.rpm, libstdc+-4.1.2-55.el5.x86_64.rpm, libstdc+-4.1.2-55.el5.i386.rpm ) selinux-policy bug fix update, RHBA-2014:1205 (selinux-policy-2.4.6-351.el5.noarch.rpm) sos bug fix update, RHBA-2014:1200 (sos-1.7-9.73.el5.noarch.rpm?) sysstat bug fix update, RHBA-2014:1199 (sysstat-7.0.2-13.el5.x86_64.rpm) perl bug fix update, RHBA-2014:1198 (perl-5.8.8-42.el5.x86_64.rpm) How end user/operator could detect the problem: Primarily, the vulnerability will be easily found on web server used in OMS. The exploitation of this vulnerability relies on bash functionality somehow being accessible from the Internet. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 291/330 Version 1.0 Confidential


Description of the fault: Primarily, the vulnerability will be found on the web server used in OMS. In order to make use of this vulnerability the attacker needs to login to OMS or break into OMS/hack other user session by injecting a command into bash via an environment variable. Such commands can download password files, run remote shell, or carry out other tasks to manipulate the system. Probability: Permanent Solution / Workaround: No Workaround Solution: OMS updates bash package that already addresses Shellshock vulnerability (bash3.2-33.el5_11.4.x86_64.rpm) Impact to Operator: There is no direct impact on OMS. However all applications that makes Bash calls are affected

3.482 70158 FILE SYSTEM USAGE OVER LIMIT in OMS for MySQL_DB_CosNaming Problem report: NA05681886 Exists in: iOMS5.0, iOMS6.0 Corrected in: iOMS5.0 2.1, iOMS6.0 1.0 Severity: B - Major Customer Impact: Capacity & Performance Description: Following alarm occurs in iOMS: 70158 FILE SYSTEM USAGE OVER LIMIT (A). (Suppl info: /var/mnt/local/MySQL_DB_CosNaming). MySQL_DB_CosNaming directory is out of space. Root Cause: MySQL error log file consume file system resources assigned for mysql server partition. Log rotation mechanism wasn't triggered periodically. Description: Mysql error log file consumes file system resources assigned for mysql server partition. Alarm 70158 is raised Probability: Occasional Solution / Workaround: # fshascli -ln /NamingServiceDB (ssh session might get lost, but just reconnect to OMS) # create_sw_raid /dev/md8 /dev/VG_62/MySQL_DB_CosNaming /dev/VG_63/MySQL_DB_CosNaming # mount /dev/md8 /var/mnt/local/MySQL_DB_CosNaming # rm -rf /var/mnt/local/MySQL_DB_CosNaming/* # umount /var/mnt/local/MySQL_DB_CosNaming/ # release_sw_raid /dev/md8 # fshascli -un /NamingServiceDB # fshascli -rn /PrivateCosNaming Impact to Operator: 70158 alarm will be raised in OMS because MySQL_DB_CosNaming directory is out of space.

3.483 RL 60 Project - G6 Blade: Firnware upgrade failure Problem report: NA05707107 Exists in: iOMS5.0, iOMS6.0 Corrected in: iOMS2.1, iOMS6.0 1.1 Severity: B - Major Customer Impact: Capacity & Performance



Description: OMS firmware upgrade failure occurred. RHEL 32-bit package library was integrated to OMS so there is no possibility to upgrade OMS firmware Problem could be detected when firmware upgrade is triggered. Application does not start due to 32 bit libraries are missing after upgrade HDD/iLO firmware on iOMS. This is due to 32-bit compatibility runtime from x86_64 build during upgrade from RHEL 5.7 to RHEL 5.9 was removed. Solution: To add support for HP tools, 32-bit RHEL packages is delivered to iOMS. Probability: Permanent Solution / Workaround: Solution to iLO upgrade on ProLiant BL460c G6 is to copy lacking libs to /lib/ folder on OMS: cp ld-linux.so.2 /lib/ cp libc.so.6 /lib/ Libs can be found in glibc-2.5-118.i686.rpm, which can be downloaded from Red Hat repositories. Impact to Operator: Firmware upgrade will fail due to missing 32 bit libraries

3.484 The last digit of M8012C133 value is deleted in OMS Problem report: NA05712299 Exists in: iOMS6.0 Corrected in: iOMS6.0 1.1 Severity: B - Major Customer Impact: Capacity & Performance Description: We found that M8012C133 value changed in OMS side. When the last digit of M8012C133 value is "0" (zero), that last digit is deleted in OMS. Probability: Permanent Solution / Workaround: No Workaround Solution is the updated implementation so that counter values ending with 0 will not be truncated. Impact to Operator: Wrong counter values will be displayed. The counter value will be truncated if it is ending with 0.

3.485 Topology DB backup failed as part of USB backup/restore procedure Problem report: NA05680249 Exists in: iOMS5.0 Corrected in: iOMS5.0 2.1 Severity: B - Major Customer Impact: Capacity & Performance Description: DB backup failed as part of USB backup/restore procedure How end user/operator could detect the problem: Problem could be detected during selective backup and restore procedure for Topology database. PREBTS object and other important data were not copied during backup and restore procedure. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 293/330 Version 1.0 Confidential


Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: eNB cannot connect to IOMS after restore.

3.486 Counter HIGH_CELL_LOAD_LB stuck Problem report: NA05678576 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Tests were performed for LTE 1170 (inter-eNB inter-frequency load balancing). Quite a lot of parameter changes and switching on/off of the feature were successful without problems. But after one of the deactivations of the feature the counter HIGH_CELL_LOAD_LB jumped to the maximum 900 and stays there even if the load is stopped (only single calls ongoing). The identical job before has lead to the expected outcome that the counter returns to 0. The change was performed in a load situation with 24 mobiles. The thresholds for PDCCH before were reduced, while the other thresholds (non-GBR, GBR) were on default. After the deactivation also the thresholds were changed to the defaults. It was verified, that this is only a counter issue - the feature 1170 is not triggered any more although the conditions are fulfilled. Root cause: The counter wasn't stopped when actInterFreqLb flag was disabled and cell LbState was unbalanced. Probability: Occasional Solution / Workaround: The counter wasn't stopped when actInterFreqLb flag was disabled and cell LbState was unbalanced. Fix adds checking if feature flag is enabled. Impact to Operator: After deactivation of the feature LTE1170 the counter HIGH_CELL_LOAD_LB jumped to the maximum 900 and remains there even if the load is stopped (only single calls ongoing). If this counter error happens more often it will be difficult to verify LTE1170 in live network.

3.487 Incorrect MCS/maxUlcoderate for SRS frames with FULA Problem report: 113305ESPE01 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: When using FULA and SRS, the scheduler is not correctly reducing the MCS in frames using SRS as indicated in requirement RRM_LTE_SFS_RRM.5209. When running an UL SNR vs. Throughput curve using FULA and SRS, low throughput is observed at some SNR points. This can be seen specifically in a SNR=15 (postcombined, SNR=13 pre-combined) UL RF condition using FULA and SRS, the max UL code rate is not being honored. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 294/330 Version 1.0 Confidential


Problem related LTE1495-A (FUlLa) feature and have been tested with the following configuration: GMC with FULA CAS+SRS, 1799A, UL throughput with FULA+CAS+SRS TTI trace log can be used to detect the problem. Probability: Permanent Solution / Workaround: Impact to Operator: MCS reduction in SRS TTIs not applied for final MCS in FUlLa. There’s an impact for static (lab) conditions in terms of a small throughput degradation.

3.488 Red Hat Security Patches - July 2014 Problem report: 119366ESPE04 Exists in: iOMS6.0, Corrected in: iOMS6.0 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Several security advisories has been issued by RedHat for RHEL 5: 2-741-24817-2014-07-23, Red Hat RHEL Server 5 - nss, nspr Certification Verification Vulnerability - RHSA-2014:0916-1 (nss-3.15.3-7.el5_10.x86_64.rpm, nspr-4.10.61.el5_10.x86_64.rpm) 2-741-24828-2014-07-23, Red Hat RHEL Server 5, Server 6, Workstation 6 - httpd Multiple Vulnerabilities - RHSA-2014:0920-1 (httpd-2.2.3-87.el5_10.x86_64.rpm, mod_ssl-2.2.387.el5_10.x86_64.rpm) 2-516-24834-2014-07-24, Red Hat RHEL Server 5 - kernel Two Vulnerabilities - RHSA2014:0926-1 (kernel-2.6.18-371.11.1.el5.x86_64.rpm) Description of the fault: OMS is possibly affected to several security advisories issued by Red Hat. Probability: Permanent Solution / Workaround: Update and integrate Red Hat patches to OMS build. Impact to Operator: This vulnerability is not easily detected by operator. However OMS may be vulnerable to security attacks or tampering of data from external sources.

3.489 UL SINR was degraded in a particular cell with delay of cell setup after eNB restart Problem report: NA05500602 Exists in: LN6.0 Corrected in: Correction Not Needed Severity: C - Minor Customer Impact: Capacity & Performance Description: - eNB restart by RF Sharing WCDMA restart. - After eNB restart, “CELL OUT OF USE” of short duration (about 60 sec) was detected in a cell 3 only. - UL SINR was degraded in the cell 3. UL SINR was decreased 6dB. - eNB restart by user. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 295/330 Version 1.0 Confidential


-

This issue was recovered. UL SINR was increased 6dB in the cell 3.

After eNB restart, “9400 CELL OUT OF USE” of short duration (about 60 sec) was detected in a particular cell, then the UL SINR was degraded in that cell at a low probability. There is no alarm while this issue is occurring. From BASIC_KPI, UL SINR was decreased 6dB, but CQI was same trend. Attached PR: NA05600396 Probability: Very rare Solution / Workaround: eNB reset. Fault was not reproducible. Impact to Operator: UL SINR was degraded in a particular cell with delay of cell setup after eNB restart.

3.490 FSMF with FRHF: Alarm 1900 is generated after setting minimum Total Loss on antenna Problem report: 49917ESPE05 Exists in: LN6.0 Corrected in: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: The value range of parameter ANTL - "Antenna total loss" contains values that are not supported and lead to configuration errors and autonomous reset on RF module. This is already corrected in RL70 software. In RL60 use only supported values for parameter ANTL - "Antenna total loss". Probability: Permanent Solution / Workaround: Use only supported values for parameter ANTL - "Antenna total loss". Impact to Operator: The value range of parameter ANTL - "Antenna total loss" contains values that are not supported and lead to configuration errors and autonomous reset on RF module.

3.491 RACH storming with high ATA Problem report: NA05617855 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: RACH Storm Reproduction: After FR1_2_2 reset by BTS SM block/unblock, when FR1_2_2 alive, try to intra Frequency HO from FR1_2_2 and FR1_2_1. RACH failure happened there included high ATA ( ATA value = 100 ~ 184 ) but msg3 failure happened. PM Data show msg3 failure so Complete Stp SR reached to "0". This behavior can be detected in ATA profile at BTS Performing Monitoring. Problem can only happen if optical fiber length between System module and RF module is larger or even 10km. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 296/330 Version 1.0 Confidential


Attached PR: 52189ESPE05 Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: RACH storm with high ATA. This behavior will ATA give a constant timing shift in DL direction inside BTS, thus BTS will incorrectly calculate the distance between UE and BTS. As a result KPI will drop.

3.492 M8005C4 was 0 even though RRC ATT is counted in cell Problem report: NA05673172 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: In eNB site, the counter RSSI for PUSCH [Max](M8005C4) value is 0 in 15 min KPI even though there is RRC ATT in the cell during that period. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: The counter RSSI for PUSCH [Max](M8005C4) value is 0 in 15 min KPI interval even though there is RRC ATT in the cell during that period.

3.493 LED on FBBA/FBBC and BTS Site Manager are not showing fault BTS reset required (fault number 4001) correctly Problem report: 84936ESPE03 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: When FBBA or FBBC is newly installed in the System Module, or BB_EXT port is change for FBBA or FBBC, fault BTS reset required (fault number 4001) is reported but the LED in FBBA/FBBC and BTS Site Manager are not showing this fault correctly. All the LEDs are Stable GREEN. When BTS reset required (fault number 4001) is reported LED on FBBA/FBBC and in BTS Site Manager should be Stable RED. Problem is repeatable in 100 % cases. There is no need to recover from this problem. Only the LED status is wrongly reported. After the BTS will be reset, according to the reported fault BTS reset required (fault number 4001), BTS is going to be fully operational. Probability: Permanent Solution / Workaround: No workaround is needed, BTS needs to be reset according to the reported fault number BTS reset required (fault number 4001). Impact to Operator: LEDs are not indicating a problem (Stable GREEN LED is reported instead of Stable RED), when in fact BTS reset is required to fully recover after BB_EXT port has been changed for extension module, or to make FBBA/FBBC work after extension module has been newly installed.



3.494 Incorrect LED Condition Displayed for Major VSWR Alarm (1837) on FHCA Problem report: 110185ESPE01 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: When "7653 Local cell faulty: VSWR major alarm (1837)" is active for FHCA, the LED on FHCA module (displayed also in "BTS HW view" of BTS Site Manager) should be blinking red, but is green. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: The operator cannot detect by watching the LED on FHCA a major VSWR alarm.

3.495 Third Party cell trace can't restart after trace link disconnected for long duration Problem report: 117103ESPE04 Exists in: LN6.0 Corrected in: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: On multiple RL50 and RL60 releases, if the third party cell trace is disconnected at the trace tool, after a long period of time (6 hours to 4 days), the eNB eventually stops sending the keep alive messages on the m-plane IP address, and instead uses the internal IP address. After the eNB starts using internal IP address, if the third party tool were reconnected, the cell traces would never go through again. The eNB can be in steady state or even have been reset during the time when the trace is disconnected, and the problem is still seen eventually in time. Proper fault is generated on the eNB as below during time trace is disconnected, but never clears after trace re-connected. Severity: Major Fault name: Failure in connection between BTS and iOMS or 3rd party tool (6261) Alarm Code: 7651 Scope: Base station operation degraded Destination IP address: 27.128.129.87:49151 This problem was reproduced multiple times on multiple releases from times ranging from 6 hours to 4 days of the third party trace tool being disconnected. Recovery is to reset the eNB after the third party trace tool is reconnected. Probability: Occasional Solution / Workaround: After third party trace tool is reconnected, the operator can perform an eNB site reset to recover the cell trace. Or the operator can delete trace object and add a new one. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 298/330 Version 1.0 Confidential


Impact to Operator: Third party cell trace will never be re-established.

3.496 Automatic BTS certificate renewal ( 61510) and CRL update failure alarm (61074) -LED display is not Blinking red on HW Problem report: 117586ESPE04 Exists in: LN6.0 Corrected in: RL70 Severity: B - Major Customer Impact: Operation & Maintenance Description: eNB is up on air. Trigger Automatic BTS certificate Renewal (61510) and CRL update failure (61074) alarm. LED on Transport HW is solid green instead of blinking red. This is valid for RL60 and RL50. Probability: Permanent Solution / Workaround: None Impact to Operator: When alarm is active, by looking at HW LED status cannot tell how severe these alarms are.

3.497 RL60_SEC_FTMr2_KUR fails when new single layer CA is used Problem report: 117938ESPE04 Exists in: LN6.0 Corrected in: RL70 Severity: C - Minor Customer Impact: Operation & Maintenance Description: CMP Key Update (KUR) fails when a new single layer CA is configured in Automatic Certificate Management. BTSSM displays Fault 61510 Automatic Operator Certificate retrieval unsuccessful. Probability: Permanent Solution / Workaround: Use Initialize Certificates (IR) instead of CMP Key Update (KUR). Impact to Operator: For FSMr2 only: During CA update procedure KUR fails when new single layer CA is used.

3.498 FSM2_LN60: Site Autonomous Reset when GPS is plugged into working eNB Problem report: 118016ESPE04 Exists in: LN6.0 Corrected in: Correction Not Needed Severity: B - Major Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 299/330 Version 1.0 Confidential


Description: 1. BTS is On Air with no alarms. 2. ToP is Synch source and Tuning works fine. 3. GPS cable is plugged in. 4. Site Autonomous Reset and BTS is back OnAir afterward. Sync Source switching causing Site Reset. Probability: Permanent Solution / Workaround: eNB will reset and come back On Air autonomously after switching sync source. Impact to Operator: eNB reset will be seen if GPS Sync is switching with ToP.

3.499 Addition / deletion of 5th VLAN shows an impact on running IPSec operation Problem report: 142219ESPE02 Exists in: LN6.0 Corrected in: RL60 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: When adding or deleting a 5th VLAN existing IPSec connections might get affect. A 5th VLAN might be needed in case Nokia Flexi Packet Radio is used. eNB stops sending outbound message for one of the configured VLAN interface randomly. Probability: Permanent Solution / Workaround: After adding or deleting a 5th VLAN eNB needs to be restarted. Impact to Operator: Traffic impacting.

3.500 Throughput of PCell is affected if SCell has bad radio conditions Problem report: 104190ESPE01 Exists in: LN6.0 Corrected in: RL70 Severity: B - Major Customer Impact: New feature/functionality Description: 1. BTS is configured with 2x FXEA, 1xFRHA,1xFRHC 20 MHz and all four cells are onAir 2. Attach UE in cellid=1 and send DL 320Mbit/s UDP DL data to the UE – UE is configured for DL-CA with Scell id=3 and get MAC CE activation 3. change the signal from Scell (cellid=3) via a attenuator to bad radio conditions and only round about 2-3Mbits/ are scheduled in SCell Throughput of PCell is affected if SCell signal has bad radio conditions. The PCell throughput is not stable linear anymore in that scenario and it is highly fluctuating. The existence of this behavior in real field conditions will be very rare and depends heavily on network setup and configurations. Probability: Permanent Solution / Workaround: The eNB behavior will be improved by LBT2102 for LN7.0. No modifications to be done in LN6.0. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 300/330 Version 1.0 Confidential


Impact to Operator: Throughput of PCell is affected if SCell signal has bad radio conditions. The PCell throughput is not stable linear anymore in that scenario and it is highly fluctuating.

3.501 After deletion of LNADJ using Send All parameter option, related LNREL are not automatically deleted. Problem report: 111938ESPE04 Exists in: LN6.0 Corrected in: Correction Not Needed Severity: C - Minor Customer Impact: Operation & Maintenance Description: After deletion of LNADJ using Send All parameter option (requests reset of eNB) via BTSSM or NetAct, related LNREL are not automatically deleted. Probability: Permanent Solution / Workaround: Explicitly delete LNRELs related to LNADJs to be deleted using "Send All" parameter option. Or manually delete LNRELs after or before Send All parameter to eNB including deletion of LNADJ. Impact to Operator: LNRELs are not automatically deleted after deletion of related LNADJs using Send All parameter option and remain after eNB comes up after reset. If ActS1Ho=true and ANR is performed to the eNB corresponding to the previously deleted LNADJ, X2 handover instead of S1 HO is triggered.

3.502 Red Hat Security Patches - June 2014 Problem report: 117616ESPE04 Exists in: iOMS5.0, iOMS6.0 Corrected in: iOMS5.0 2.0, iOMS60 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Several security advisories has been issued by RedHat. RHEL 5: - 2-516-24298-2014-06-05 Red Hat RHEL Server 5, 6, Workstation 6 - openssl Usage of Weak Keying Material Vulnerability - RHSA-2014:0626-1, RHSA-2014:0624-1 - 2-282-24297-2014-06-05 - Red Hat RHEL Server 4, 5.6, 5.9, 6.3, 6.2, 6.4 - openssl Usage of Weak Keying Material Vulnerability - RHSA-2014:0627-1 - 2-516-24351-2014-06-11 - Red Hat RHEL Server 5 - kernel Multiple Vulnerabilities - RHSA2014:0740-1 RHEL 6: - 2-714-24266-2014-06-04 - Red Hat RHEL Server 6, Workstation 6 - libtasn1 Multiple Vulnerabilities - RHSA-2014:0596-1 - 2-714-24265-2014-06-04 - Red Hat RHEL Server 6, Workstation 6 - gnutls Session ID Parsing Vulnerability - RHSA-2014:0595-1



- 2-714-24299-2014-06-05 - Red Hat RHEL Server 6, Workstation 6 - openssl Multiple Vulnerabilities - RHSA-2014:0625-1 - 2-714-24226-2014-05-30 - Red Hat RHEL Server 6, Workstation 6 - curl Incorrect Connection Reuse Vulnerability - RHSA-2014:0561-1 Probability: Permanent Solution / Workaround: Red Hat patches will be integrated to OMS build. No workaround. Impact to Operator: This vulnerability is not easily detected by operator. However OMS may be vulnerable to security attacks or tampering of data from external sources.

3.503 PM counter M8001C8: RACH_STP_COMPLETIONS is not updated correctly Problem report: 52552ESPE05 Exists in: LN6.0 Corrected in: RL60 0.1 Severity: C - Minor Customer Impact: New feature/functionality Description: The PM counter M8001C8: RACH_STP_COMPLETIONS is not updated correctly when RA responses are sent to more than one UE in a TTI. In that case, the counter is updated with "1" and not with the actual number of UEs which receive RA responses. Solution: SW changed to update M8001C8 immediately when the RA response is sent and with the correct number of RA responses sent to the UEs. A general problem is, that it is not guaranteed that the events counted are related (so in case preamble is close to the end of the measurement period, but success is only in next period). This may lead to success rates larger than 100% in a single measurement period but the average over all periods is correct. Attached PR: 143957ESPE02 Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Counter M8001C8: RACH_STP_COMPLETIONS occasionally shows too low values.

3.504 Sporadically after system module reset, initialization failure Problem report: NA05678281 Exists in: LN6.0 Corrected in: RL60 0.1 Severity: B - Major Customer Impact: Stability Description: If a plan change is sent from NetAct during eNB start-up phase the eNB may remain initialization state (configuring for RFMs) and doesn't reach OnAir state. Site reset via "Recover FCT" option from FTM done for each site to recover the site. The issue is caused by commission being performed before activating RNW in startup. Probability: Occasional LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 302/330 Version 1.0 Confidential


Solution / Workaround: If problem has happened, workaround is to reset eNB. Problem can be avoided by sending plan change from NetAct only after eNB has reached Integrated or OnAir state. Impact to Operator: If a plan change is sent from NetAct during eNB start-up phase the eNB may remain initialization state (configuring for RFMs) and doesn't reach OnAir state.

3.505 M8001C150 UL_UE_DATA_BUFF_AVG value is ~0.5 of expected value in multi-UE test Problem report: 118083ESPE04 Exists in: LN6.0 Corrected in: RL60 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: The value of counter M8001C150 reports values that are 50% of the correct values. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Counter M8001C150 is incorrect. The reported value is 50% of the correct value.

3.506 UE cannot receive RRC Connection Release after X2 handover from other vendor eNB Problem report: NA05678753 Exists in: LN6.0 Corrected in: RL60 0.1 Severity: B - Major Customer Impact: Capacity & Performance Description: UE cannot receive RRC Connection Release after X2 handover from other vendor eNB. Completion of X2HO from other vendor eNB(EARFCN=1649, BW=10MHz) to RL60(EARFCN=3750, BW=10MHz, CA), no data are available on GTP-U then RL60 detect user inactivity. But RrConRelease is not received by UE. The procedure and root cause is that: 1. Normal UE attach - Inactivity timeout - RrcRelease is OK and UE received it. 2. when the UE is handed over from other vendor's eNB to Nokia eNB with CA configuration. 3. Inactivity timeout - RrcRelease is triggered correctly in UEC. 4. But the actual sent TB is taken from DRB buffer, should be SRB1. 5. When UE received this TB, it found all with padding data, so RrcRelease is not received. Also other RRC messages will not reach the UE at this point. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: UE in CA configuration cannot receive RRC Connection Release after X2 handover from other vendor eNB. UE will not be able to send or receive data until it LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 303/330 Version 1.0 Confidential


establishes a new call. No KPI degradation is expected since affected UE is released from eNB point of view. Impact to End User: After HO from other vendor's eNB and inactivity timer expiry the UE cannot send or receive data until it establishes a new call. This is done autonomously after a few seconds if the UE tries to send UL data.

3.507 Bad FHEA spectrum which recovers after reset Problem report: NA05646267 Exists in: LN6.0 Corrected in: RL60 0.1 Severity: B - Major Customer Impact: Capacity & Performance Description: Occasional there is a bad FHEA spectrum which recovers after reset. This was seen in customers network and improved by CN5619: RF SW workaround for RF wideband emission problem. However with the latest issue, it is evident that the resolution is not working perfectly. Probability: Occasional Solution / Workaround: eNB reset Impact to Operator: Occasional there is a bad FHEA spectrum which recovers after reset.

3.508 iOMS cell trace limitation for 1000 eNB needs to be extended Problem report: NA05671228 Corrected in: iOMS6.0 Corrected in: Correction not needed Severity: A - Critical Customer Impact: Operation & Maintenance Description: iOMS cell trace limitation for 1000 eNB needs to be extended to be able to give more support. iOMS is unable to manage all socket connections with all controlled eNBs for trace reporting. 1) Specifications and implementation are corrected via OMS EFS CR CRO610 (CRO610 OMS iOMS shall be able to manage all socket connections with all controlled eNBs) 2) Quick solution for operator: The parameter value for the maximum number of trace connections can be adjusted to a higher value. The maximum number of trace connections should NOT exceed value: 2000. The above limit was determined from iOMS performance tests. Exceeding of this limit can cause critical iOMS overload which can lead to operational degradation. For more detailed instructions, Separate Technical Support Note (TS-LTE_iOMS-SW-0015 LTE iOMS - Maximum number of trace data connections) is prepared for customers who are using 3rd party tool as Trace Collection Entity(TCE). Attached PR: NA05674160 Probability: Permanent Solution / Workaround: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 304/330 Version 1.0 Confidential


The parameter value for the maximum number of trace connections can be adjusted to a higher value. The maximum number of trace connections should NOT exceed value: 2000. The above limit was determined from iOMS performance tests. Exceeding of this limit can cause critical iOMS overload which can lead to operational degradation. For more detailed instructions, Separate Technical Support Note (TS-LTE_iOMS-SW-0015 LTE iOMS - Maximum number of trace data connections) is prepared for customers who are using 3rd party tool as Trace Collection Entity(TCE). Impact to Operator: Operator is unable to successfully activate trace for more than 1000 connected eNBs.

3.509 Due to missing PUSCH code rate checks for TTI bundling UEs eNB skip decoding in very bad radio conditions Problem report: 135305ESPE02 Exists in: LN5.0 Corrected in: RL60 Severity: C - Minor Customer Impact: Operation & Maintenance Description: During tests of TTI bundling and intra-cell HO the following error was found in syslog: 1C ERR/LTE RX PHY DEC:CBcpFrontEnd.cpp 1C ERR/LTE RX PHY DEC:CDecoderBackEnd.cpp The problem is that due to missing PUSCH code rate checks for TTI bundling UEs, in very bad radio condition, a common exception handling is used that is “skip all kind of processing/decoding”. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: In very bad radio condition all kinds of processing/decoding will be skipped and related errors are visible in the syslog.

3.510 Fault6259 RF Module Failure occurred during the plan activation which requires cell lock/unlock operation Problem report: NA05647591 Exists in: LN5.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: Fault6259 RF Module Failure occurred after change Parameter that Object locking are needed. Solution: Supplier delivered fix SW in FRRH4-SW_0407761. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Fault6259 RF Module Failure occurred during the plan activation which requires cell lock/unlock operation. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 305/330 Version 1.0 Confidential


3.511 M8006C15 PEGGING HIGH Problem report: NA05622140 Exists in: LN 5.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: eNB is onAir with RL50 LN5.0_ENB_1304_619_02. - Redirects are disabled in the eNB. As per counter definition in SFS and RISE it is expected that only S1AP releases due to RNL E-UTRAN generated reason or RNL Inter-RAT Redirection are included in this counter. Counter showing much higher value then the number of these cases. Solution: Description updated in RISE and BTS Site Manager. This counter is updated when the S1AP: UE CONTEXT RELEASE REQUEST message (eNB - MME; 3GPP TS 36.413) is transmitted in case that one of the following release causes is used: - Release due to E-UTRAN Generated Reason, - Inter-RAT redirection, - Redirection towards 1xRTT, - CS Fallback Triggered. This counter is also updated with the number of released E-RABs.

Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Counter M8006C15 is showing much higher value as expected.

3.512 Manual Alarm DB upload via TLUI not working [06/2014] Problem report: NA05676526 Exists in: iOMS6.0 Corrected in: RL60 Severity: A - Critical Customer Impact: Operation & Maintenance, Alarm upload Description: Due to error in database query results handling, some query result can cause unexpected failure during active alarm list chunks iteration. Due to failure, NetAct will cancel the alarm upload operation. When occurred, the problem is permanent on the specific OMS machine. Attached PR: 44605ESPE07 Probability: Occasional Solution / Workaround: No workaround. Impact to Operator: Operator is unable to perform successful alarm upload operation



3.513 KPI LTE_5801D has sometimes abnormal values Problem report: NA05676670 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: B - Major Customer Impact: Operation & Maintenance Description: The counter M8001C266 SUM_ACTIVE_UE_DATA_UL ((Sum of Active UEs with buffered data in UL per cell)) is reported wrong occasionally with abnormal high values and that causes KPI LTE5801D is wrong. Description of the fault: Counter variable was decreased even it value was already zero. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: KPI LTE_5801D and counter M8001C266 are not reliable

3.514 StAX Parsing XML Exception appears for LNBTS NEs Problem report: NA05676758 Exists in: LN6.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: SAX XML Parser Exception when Audit Trail runs log collection. The issue is occurring because the xml have "R&D PORT STATUS", '&' is not recognizable as such in xml, Because of which parsing error is occurring. This is fixed by addend 'amp;' in the xml, i.e "R&D PORT STATUS", now the parsing error can be removed. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: SAX XML Parser Exception when Audit Trail runs log collection.

3.515 Sporadic RP3 Alarm – Third RF module was not detected after the upgrade to RL60 Problem report: NA05676967 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: C - Minor Customer Impact: Operation & Maintenance Description: RP3 Alarm – Third RF module was not detected after the upgrade to RL60. Alarm cleared after site reset given from BTS SM.



In link speed change scenario BTSOM requested FR1_3_1 port 0 status. Two portStatus response messages were received, although only one request was sent. First response message included port 1 status and it was handled by BTSOM. Second response included port 0 status (which was requested), but BTSOM discarded the message because one portStatus response was already received. Link speed scenario for FR1_3_1 failed and was causing 4064 alarm. At the same time BTSOM was requesting FR1_1_1 port 1 status, but response was not received. Timeout occurred, and BTSOM requested port 1 status again. Response for the second request was received with correct data. In MCUHWAPI SUM prints it could be seen that even though port 1 status was not requested from RP3-01 1 link SUM received response from RP3-01 1 about port 1 status. Conclusion was that messages were somehow incorrectly handled in driver level. Solution: In LFS MCU buffer driver, interrupt mode of both UL and DL buffers were changed to 0 - interrupt is generated from every received message. Probability: Sporadically Solution / Workaround: No Workaround Impact to Operator: Third RF module is not detected, related cell remains down and additional site reset is needed to bring RF module in service and cell on Air

3.516 Alarm Database Upload Failure from iOMS Problem report: NA05678251 Exists in: iOMS6.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: Alarm Database Upload failed during iOMS upgrade. Upload from OperationsManager and SW Upload from SW-Manager works fine. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Alarm Database Upload from NetAct to failed during iOMS upgrade.

3.517 Sleeping site after RL60 SW upgrade Problem report: NA05679344 Exists in: LN6.0 Corrected in: RL60 Severity: C - Minor Customer Impact: Capacity & Performance Description: It was noticed that after the upgrade site does not take any traffic at all. This was noticed from the KPIs. After performing a site reset this problem was not seen anymore. In link speed change scenario BTSOM requested FR1_3_1 port 0 status. Two portStatus response messages were received, although only one request was sent. First response message included port 1 status and it was handled by BTSOM. Second response included port 0 status (which was requested), but BTSOM discarded the message because one portStatus LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 308/330 Version 1.0 Confidential


response was already received. Link speed scenario for FR1_3_1 failed and was causing 4064 alarm. At the same time BTSOM was requesting FR1_1_1 port 1 status, but response was not received. Timeout occurred, and BTSOM requested port 1 status again. Response for the second request was received with correct data. In MCUHWAPI SUM prints it could be seen that even though port 1 status was not requested from RP3-01 1 link SUM received response from RP3-01 1 about port 1 status. Conclusion was that messages were somehow incorrectly handled in driver level (LFS). Solution: In LFS MCU buffer driver, interrupt mode of both UL and DL buffers were changed to 0 - interrupt is generated from every received message. Attached PR: 142054ESPE02 Probability: One occurrence Solution / Workaround: Perform eNB reset. Impact to Operator: Site does not take any traffic when problem occur.

3.518 Cannot make a call on the certain cell when RTT delay is set more than 20000 Problem report: NA05669021 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: C - Minor Customer Impact: Capacity & Performance Description: Cannot make a call due to high ATA on the certain cell when RTT Delay is set more than 20000 on the FHCB. Solution: Solved with new FRRH4-SW_0407762. Probability: Permanent Solution / Workaround: Set RTT delay below 20000. Impact to Operator: User cannot make a call due to high ATA on the certain cell when RTT Delay is set more than 20000 on the FHCB.

3.519 FBBA plug-in causes Technical log buffer(6450) and BB failure(1811) faults Problem report: NA05669406 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: B - Major Customer Impact: Operation & Maintenance Description: 1) FSMF Configuration without FBBA 2) See that all cells are on-air 3) FBBA plug in 4) Check if there are alarms of 1811 and 6450



FBBA should be detected without alarm. But FBBA hot plug in causes following alarms sequentially and Baseband bus failure (1811) alarm doesn't disappear: - BTS reset required (4001) - Technical log buffer freezing (6450) - Unit autonomous reset as recovery action (1811) - Technical log buffer freezing (6450) - Baseband bus failure (1811). BTS reset required(4001) should be remained until BTS reset, but it seems FSMF tries to connect FBBA before BTS reset. Then 4001 alarm cancellation may cause the other faults. During Startup FSPBConf get the value of m_DspNumber in initialize operation, but it doesn’t update the value of m_DspNumber when it gets the DBChange notify of FSP. Solution: To avoid this scenario the value of m_DspNumber will be updated when it gets the DBChange notify of FSP. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: FBBA hot plug-in causes Technical log buffer(6450) and baseband failfure(1811) faults.

3.520 iOMS alarm pipe to NetAct broke time to time with new SW release Problem report: NA05669473 Exists in: iOMS6.0 Corrected in: RL60 3.1PD Severity: B - Major Customer Impact: Operation & Maintenance Description: Occasionally iOMS is not sending measurement nor alarms to NetAct. Root cause are problems with database resources management in the Nwi3Adapter subsystem. Database resources used in alarm upload operation were not released correctly and it may happen that new begin alarm upload operations were not able to start. This issues have impact on the new nwi3 session creation also and can cause that thread responsible for login process could be suspended. These problems caused memory resource management problems and Nwi3Adapter was not working properly. Solution: Database resource management in the Nwi3Adapter was corrected. Probability: Occasional Solution / Workaround: Restart of Nwi3Adapter. Impact to Operator: Alarms and measurements from iOMS stopped arriving to NetAct.

3.521 After correction update, Nwi3TUCorba process is not responding [06/2014] Problem report: NA05669992 Exists in: iOMS6.0 Corrected in: RL60 3.1PD Severity: C - Minor Customer Impact: Operation & Maintenance Description: Nwi3TUCorba process does not respond after correction update leading to topology upload failure to NetAct. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 310/330 Version 1.0 Confidential


The core file was not generated. But the backtrace file was generated. After 10 minutes, Nwi3TUCorba process status became active with HAS recovery action. Root cause was a Thread synchronization issue which was solved in iOMS5.0 and iOMS6.0. Synchronization between threads improved by setting additional flag. Probability: Occasional Solution / Workaround: No workaround. Impact to Operator: Topology upload to NetAct will fail. The operator could not see actual network topology in NetAct.

3.522 RF module reset because of additional fault1143 Problem report: NA05672636 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: B - Major Customer Impact: Stability Description: 1) Upgrade to RL60 3.0PD for pilot test (LTE1439). 2) Monitoring eNB status. 3) RF module reset because of additional fault1143. All of 1143 fault trigger RP3 alarm. In case of very short link break (1ms) FCB (clock) is not lost (occasional situation). It was assumed in SW, that after link break FCB is always lost, and restored back. This was the trigger to begin recovery procedure. In case FCB was not lost, trigger did not happen. All RP3 links remained down, carriers remained inactivated. Due to RP3 links not synchronized fault 1143 was raised. Recovery for fault 1143 caused RF reset. Solution: After successful RP3-01 synchronization timer is explicitly triggered to check if FCB is already received and stable. After check the recovery procedure is normally triggered. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Unexpected RF module reset because of additional fault 1143 after short link break.

3.523 RP3 Alarm occurred in FBBA after activating LTE1099 Problem report: NA05672850 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: C - Minor Customer Impact: Operation & Maintenance Description: 1. Symptom data trigger list "100000" setting(LTE1099) by online 2. Commissioning complete 3. eNB Reset 4. Failure in optical RP3 interface(2000) Alarm occurred LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 311/330 Version 1.0 Confidential


5. TX failure in MIMO(4003) Alarm occurred. Same problem occurs with both, FBBA and FBBC. Using LTE1099 with other value does not cause any alarm. Probability: Permanent Solution / Workaround: Modify symptom data trigger list with other value than 100000. Impact to Operator: RP3 Alarm occurred in FBBA after activating LTE1099 with a Symptom data trigger list set to "100000".

3.524 Technical log buffer Freezing (6450) alarm causes cell lock up Problem report: NA05674486 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: B - Major Customer Impact: Stability Description: The eNB occasionally shows Technical log buffer freezing transient alarm. Alarm shows briefly but even after it disappears from the active faults sector 3 cells are disabled. FSMF shows working state as degraded. Issue resolves itself after a few minutes or with the BTS restart. This problem occurred occasionally during user deletion. Before user deletion all sdu packets for each drb’s are released for each user successfully and user delete can be proceed further. Inside user delete function there is additional checking if “m_bufferedDataAmount 0”, so it is checking if there are sdu packets in buffer. Theoretically there shouldn’t be any data because there we checked in previous step Solution: Reason for this to happened was that there was a problem with PDUs forwarded through X2 with SN that already in queue. This packets weren't dealt with properly and left unconnected to an internal PDCP queue. The fix ignores these packets leaving the queue and user context in a consistent state. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Call Drop and temporary cell outage due to System Module Failure reset.

3.525 Technical Log Buffer freezing(6450FSMF) with Unit autonomous reset(0418FBBA) occurred repeatedly in RL60 PT2.2 Problem report: NA05675117 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: B - Major Customer Impact: Operation & Maintenance Description: Monitor Alarms for FSMF with FBBA sites in RL60.



Technical Log Buffer Freezing Alarm (6450FSMF) occurred after RL60 PT2.2(164_07) upgrade. It always involved 'Unit autonomous reset as recovery action alarm' (0418FBBA). This is an occasional problem. 5 out of 1000 monitored eNB affected. Root cause: PDCP PDU flush request comes between user deletions in TUPu EO and local manager. Additional check if bearer exists during PDCP PDU handling solves the problem. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Call Drop and temporary cell outage due to System Module Failure reset.

3.526 Counter shows wrongly no downlink data (Zero PDCP) for some sites Problem report: NA05675839 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: A - Critical Customer Impact: Operation & Maintenance Description: Counter shows wrongly no downlink data (Zero PDCP) for some sites Timers not working occasionally on different cores. Creating timer wheels at the same time can lead in a situation where second creation overwrites the configuration of the first one. Both will get the same timer wheel handle but all the events will go to second queue. Timer wheel creation was not protected with semaphores Description of the correction: Protecting the timer wheel creation with semaphores. This will prevent a situation where two users would get the same timer wheel handle. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Counter shows wrongly no downlink data (Zero PDCP) for some sites.

3.527 Significant decrease in ENB data volume and connections since may 1. Problem report: NA05668605 Exists in: iOMS6.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: Significant decrease in ENB data volume and connections since may 1. Backup for some of the measurement files in xmlfilesBU is empty (filesize is 0 Kb). Fault is cause by eNB trying to trigger similar measurement time/date/etc files. This therefore causes OMS to incorrectly copy and backup files from xmlfiles/ to xmlfilesBU/. There are instances where eNB sends duplicate measurement files after couple of hours. Due to this special circumstances, we cannot be assured that the filename in xmlfiles/ is similar in backup folder xmlfilesBU/. To solve this the handling how to copy measurement files for backup was changed. Probability: Occasional Solution / Workaround: No Workaround LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 313/330 Version 1.0 Confidential


Impact to Operator: Significant decrease in ENB data volume and connections, measurement appears as incorrect. Backup for some of the measurement files in xmlfilesBU is empty (file size is 0 Kb).

3.528 eNB send Paging message with some timing gap Problem report: NA05663844 Exists in: LN6.0 Corrected in: RL60 P8 Severity: B - Major Customer Impact: Capacity & Performance Description: 1) Monitor Paging message in RL60 site. 2) Compare Paging message time between paging request time(TUPC_L3S1_MESSAGE_IND_MSG) and Paging send time(MAC_PCCH_DATA_SEND_REQ_MSG). eNB send Paging message with some timing gap. eNB did not received UE's response that problem time. It occurred 2~5 times / Total test 100000 paging signal. At full load when there are some delays in system CC&S LteTime service triggers some timers 41 sec later. This occurs when user creates a timer that should be triggered 2 SFN later from moment when it is created. The timer is not added to list at time and it is triggered 41 sec later (4096 frames). Solution: The issue is corrected in LteTime service (function TimerHandleNewTimeoutInd). In checking of some boundary conditions, the possibility of triggering and adding timer in list in the same SFN is forgotten. Bug is fixed. Now in this scenario timer is triggered immediately if the current SFN is that in which the timer should be triggered. Probability: Very rare Solution / Workaround: No Workaround Impact to Operator: eNB send dome Paging messages 41 sec later.

3.529 SON: After get the DHCP IP for 55 seconds, site connection lost Problem report: NA05663309 Exists in: LN6.0 Corrected in: RL60 3.1PD Severity: B - Major Customer Impact: Operation & Maintenance Description: Operator uses SON to access to the site. After get the DHCP IP for 55 seconds, connection to site is lost. 10 minutes later site start the DHCP process again. Root cause: Error in DHCP TLV parsing. Special symbol '|' was not successfully decoded. Solution: Add handling for special symbol '|'. Probability: Occasional Solution / Workaround: No Workaround



Impact to Operator: Operator uses SON to access to the site. After get the DHCP IP for 55 seconds, connection to site is lost. 10 minutes later site start the DHCP process again.

3.530 Wrong Logical type in M8005C281/2/3 counter description Problem report: NA05662474 Exists in: LN6.0 Corrected in: RL60 P8 Severity: C - Minor Customer Impact: Operation & Maintenance Description: The following counters wrong “Logical type” and the “NW aggregation function” description: - M8005C281 / Minimum of cell-wide SINR on PUSCH - M8005C282 / Maximum of cell-wide SINR on PUSCH - M8005C283 / Mean of cell-wide SINR on PUSCH. The "Logical type" and "NW aggregation function" are for each of these counters "Sum" but should be - Min - Max - Average. Solution: Description corrected BTS Site Manager. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: Wrong Logical type in M8005C281/2/3 counter description: "Sum" instead of "Min/Max/Average".

3.531 F-ULA performance degradation on high speed Problem report: NA05649505 Exists in: LN6.0 Corrected in: RL60 P8 Severity: B - Major Customer Impact: Capacity & Performance Description: Tests results show good F-ULA gains at 5 Hz (resp. 3km/h) fading, but degradation at 250 Hz (resp. 125km/h) and 125 Hz (resp. 63km/h). Some small degradation for F-ULA as well at 30 Hz (resp. 15km/h). Crossover point between E-ULA and F-ULA is between 5 Hz and 30 Hz fading. F-ULA cannot track the higher fading rates, and spends too much time at too low or too high MCS values (this is due to the delay between the measurement of the SINR and the actual data transmission which is introduced by the 3GPP protocols and cannot be avoided). This leads to the fact that assigned MCS no longer correlates with the SINR on PUSCH. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: F-ULA performance degradation on high speed.



3.532 Site reset startup time over limit Problem report: 140216ESPE02 Exists in: LN6.0 Corrected in: RL60 P8 Severity: B - Major Customer Impact: Operation & Maintenance Description: Configuration: FSMF+2xFRHA Automated Site reset: Reply received to cell query = now performing site reset initiated by user. Startup takes too long time. FSP board detection fails. Overlap of add and SYN events can lead to corruption of switch lane configuration. This then prevent switch links to come up. SW-Solution: Serialize add and SYN events so that there cannot being an overlap of switch configuration, FSP-FCT link speed setup or encryption enable. Attached PR: 111313ESPE01, 111314ESPE01 Probability: Permanent Solution / Workaround: No Workaround. Pronto is closed by SPEC Update. Impact to Operator: FSP boards may not working.

3.533 Cell state should not keep active after s1 link has down more than 20 minutes Problem report: 76353ESPE03 Exists in: LN6.0 Corrected in: Correction Not Needed Severity: C - Minor Customer Impact: Operation & Maintenance Description: Sequence of events to trigger this problem: 1. S1 link is on and all cells are on air 2. Block RF modules 3. Disconnect S1 link 4. Unblock RF modules while S1 link is not available. After unblock successfully, all cells reach OnAir state and transmit reference signals and broadcast channels. Since S1 link is not available at this time, no calls are possible in this situation. Only after expiry of timer s1InducedCellDeactDelayTime (default value 15min) the cell state change to deactivated. The situation where this can happen is very rare in life networks. It will be improved by CR L1940. Probability: Occasional Solution / Workaround: This behavior will be improved in FL15A by CRL1940. Impact to Operator: BTS status change to configured and alarm 6202 reported. But more than 20 minutes later the all cells’ availability state still keep active and the icons at BTSSM show as if they are still on air. This happens only if RF is blocked when S1 link gets down.

3.534 CS call is not working on shared RRH/RFM and TRX test is also getting failed due to reason “Low power in Abis1-Air3 loop” on shared RRH/RFM at 2G-LTE RF sharing site



Problem report: 40852ESPE06 Exists in: LN6.0 Corrected in: Correction Not Needed Severity: B - Major Customer Impact: Operation & Maintenance Description: LTE and 2G site is in supervisory state. Action and observation: 1) Full commissioning is performed by changing the power budget of Sectors configured on 1800 band RRH. 2) Site commissioned successfully but during commissioning TRX test is getting failed due to reason “Low power in Abis1-Air3 loop”.(Unexpected) 3) CS call is also not getting established on the RRH for which TRX test is getting failed. 4) Same observation has been on RFM ( FXEA) . CS call is not working on shared RFM and TRX test is getting failed due to reason "low power in Abis1-Air3" loop. This is no software issue, but the problem has to be solved by hardware correction. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: LTE-GSM-RF-sharing configuration with RRH1800 FHEA not working.

3.535 FRHF: SFP hot insert doesn't work Problem report: 46555ESPE05 Exists in: LN6.0 Corrected in: Correction Not Needed Severity: B - Major Customer Impact: Operation & Maintenance Description: 1. BTS is in OnAir state 2. FR1_2_1 was hot removed (optic and SFP) (still in 2 remain optical ports SFP were inserted) 3. After few minutes, previously removed SFP (with optical link) was inserted to the same port. FR is not able to be detect. This works as specified in RL60. Hot insert of FR module or SFP module is not supported. Improvement is planned for further development. Probability: Permanent Solution / Workaround: Restart the eNB after installing the FR module or SFP (locally or remotely). Correction Not Needed since not specified with CuDo. Impact to Operator: Hot insert of FR module or SFP module not supported.

3.536 PNP blocks Certificate Management Problem report: NA05624801 Exists in: LN6.0 Corrected in: Correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Description:



When executing PNP we observed that the manual entry for "Configuration - Certificate Management" is blocked. Certificate management tab is not available during Autoconfiguration DHCP step. It's not possible to check the Certificate Status or Restore the Vendor Certificate. This effect is caused by caServerPort default value set to 0. This value should be 1024 according to parameter specification. In autconnection when CMP parameter are received at first time then if CMP got failed and autoconnection stoped then we are reverting the CMP parameter to default values. In this default value caServerPort was set to 0 while it should be 1024. Probability: Permanent Solution / Workaround: No Workaround. Impact to Operator: When executing PNP, the manual entry for "Configuration - Certificate Management" is blocked.

3.537 SCFC off-line migration via BTSSM from RL40 to RL60 doesn’t select TRS topology Problem report: 52600ESPE05 Exists in: LN6.0 Corrected in: Correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Description: 1. Save backupCommissioning File of eNB with RL40. 2. Use BTSSM and select Create File. 3. Select target level for off-line commissioning (1311_092_01) and BackupCommissioning File with RL40 topology version which was saved in step 1. In spite of BackupCommissioning File contains BTS and TRS topology BTSSM only selects BTS topology and not TRS topology. SCFC off-line migration via BTSSM from RL40 to RL50 works correctly. SCFC off-line migration via BTSSM from RL50 to RL60 works correctly. Probability: Permanent Solution / Workaround: BTSSM only supports the SCF backward compatibility for one major previous version officially. BTSSM behavior is correct in this case. SCFC Offline migration can be done in 2 steps, first from RL40 to RL50 and then from RL50 to RL60. Precondition is that RL50 BTSSM SW is installed at BTSSM. Impact to Operator: In case of SCFC off-line migration via BTSSM from RL40 to RL60 TRS topology is not available and must be reconfigured.

3.538 Internal error occurred while configuring DSCP and Message Size parameters for TWAMP sessions Problem report: 112044ESPE01 Exists in: LN6.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: 1. Create First TWAMP Session (IP=10.10.10.10, DSCP Value=25, Message Size=100). 2. Create Second TWAMP Session (IP=10.10.10.10, DSCP Value=26, Message Size=100). LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 318/330 Version 1.0 Confidential


3. Try to change to change DSCP Parameter of second TWAMP Session (DSCP Value=25). Then you will hit into the Incomplete configuration error by saying at least change at least one parameter in this set. 4. Keeping DSCP as 25 for second TWAMP change the Message size to 110 and press send. Internal error occurred while configuring DSCP and Message Size parameters for TWAMP sessions. Customer should be able to edit any number of parameters at a time, only restricting should be no two TWAMP sessions should contain same set of parameter values. If there is a restriction where the current S/W cannot handle more than one parameter at a time, we should update the same with a Pre-Check asking user to edit only one parameter at time. Probability: Permanent Solution / Workaround: Change the parameters of the TWAMP session step by step (one parameter at a time). Impact to Operator: With the existing behavior customer failed to update two parameters at one time while configuring TWAMP sessions.

3.539 MO name did not display right in source from Sitebrowser Problem report: 112213ESPE01 Exists in: LN6.0 Corrected in: RL60 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Upload BTS via Sitebrowser. Check fault source information: Sitebrowser shows code "1011" instead of "LNADJ". Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: BTSSB alarm doesn't show correct source object for LNADJ alarm.

3.540 Longer startup time of LTE Base Station after Site Reset with two extension baseband modules FBBC. Problem report: 117408ESPE04 Exists in: LN6.0 Corrected in: Correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Description: LTE system is up and running, no faults are active, cells are onAir. Site reset is performed remotely. LTE Base Station will startup to operational state onAir longer then LTE Base Station without baseband extension modules. The startup time after site reset is extended by 4-50 seconds. Affected configurations are:  L111111-NI-210-4TX-4RX/2TX-2RX  L111111111111-HI-235-2TX-2RX  L222111-KI-278-2TX-4RX / 2TX-2RX LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 319/330 Version 1.0 Confidential


  

L111111-MI-213-4TX-4RX /2TX-2RX L111111-H-171-2TX-2RX L111111-HN-169-2TX-2RX & 4TX-4RX

In general most of configuration with two extension baseband modules FBBC will have startup time after site reset extended. Attached PR: 117411ESPE04 Probability: Permanent Solution / Workaround: No Workaround. Correction not needed in RL60 Impact to Operator: Startup time of LTE Base Station with two extension baseband modules after site reset is extended by 4-50 seconds.

3.541 After upgrade of OMS from RL50 to RL60 RUIM is no more active Problem report: 117777ESPE04 Exists in: iOMS6.0 Corrected in: iOMS6.0 P8 Severity: B - Major Customer Impact: Operation & Maintenance, Operability Description: In RL50 at NetAct and iOMS RUIM is enabled in the following way: - Activate CUAA/RUIM in NetAct for OMS and connected eNBs: - Start “Network Element Access Control” (NEAC) application in NetAct, Category Security, - goto “Centralized NE User Management” folder. - Mark OMS in test - LDAP access type = LDAPS means TLS unconditionally - LDAP access type = PREFER_TLS means: TLS optionally. (select this) - Press Activate button, Activate CUAA/RUIM in OMS: - Start Application Launcher for OMS and open Parameter Tool Select OMS / System / RUIM / RUIMAutomaticActivation Set attribute omsParameterValue from 0 to 1 - Login to OMS as root and enter command: # fscontrolRUIM –enable In RL50 RUIM is working correctly. After the upgrade from RL50 to RL60 is finished the automatically triggered SW upload is failed because: Could not connect to network element. [Could not create session [Failed to open NWI3 management session [systemId=NE-OMS-52], error=[fragment=NWI3 COMMON(30000), code=AUTHENTICATION_ERROR(1), info="javax.security.auth.login.FailedLoginException: FailedLoginException with PAM return code 10"]]], This means RUIM in no more enabled in iOMS. In consequence it is not possible to enter the missing corrections 25-27 via NetAct. Probability: Permanent Solution / Workaround: If RUIM was activated before upgrade of the iOMS, after upgrade the LDAP parameter fsnwi3PrimiaryLDAPPort must be set to 389 again via Application Launcher. Impact to Operator: When RUIM was enabled before iOMS upgrade after the upgrade RUIM is no more active. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 320/330 Version 1.0 Confidential


3.542 Direct Upgrade RL40_RL60 commissioning error for b2Threshold1GERAN parameter Problem report: NA05675892 Exists in: LN6.0 Corrected in: RL60 Severity: A - Critical Customer Impact: Operation & Maintenance Description: Direct upgrade was done from RL40 MP3 to RL60 without problem. After the restart in RL60 we obtain a commissioning error for b2Threshold1GERAN parameter. Reason was an Out-of-range value for b2Threshold1GERAN (-1) due to inconsistent parameter values in RL40 (threshold2GERAN=0 and b2threshold1GERAN=10). The same problem can happen for b2Threshold1UTRA if threshold2Wcdma=0. Solution: The relation conversion: "b2threshold1GERAN must be smaller than threshold2GERAN" was removed for RL60 P8. Probability: Permanent Solution / Workaround: Before upgrade from RL40 to RL50 or RL60 change threshold2GERAN and threshold2Wcdma to a higher value than 0. Impact to Operator: During upgrade from RL40 to RL60 after the restart a commissioning error for b2Threshold1GERAN parameter occurs.

3.543 eNB reset required to switch ethernet to optical connectivity for RACS Problem report: 82458ESPE03 Exists in: LN 4.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: We use FSMF hardware which support one Ethernet and one optical port for connectivity. Whenever we switch our RACS setup from ethernet to optical connectivity we face issue that our RACS is not reachable from external network. Solution for this is to restart eNB. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: RACS is not reachable from external network when switch from ethernet to optical connectivity

3.544 The secondary DNS server is not queried if the primary DNS server returns the query with "no such name" Problem report: 117883ESPE04 Exists in: LN6.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 321/330 Version 1.0 Confidential


Corrected in: Correction not needed Severity: C - Minor Customer Impact: Operation & Maintenance Description: If primary DNS server unstable und returns often "no such name" to BTS DNS queries, the BTS shall attempt a query to the secondary DNS server address when one is configured in the NE. But instead of querying to the secondary DNS server, BTS sends query every minute only to the primary DNS server. BTS shall query to the secondary DNS server before it raised DNS resolution failure. a) CRL DP contains FQDN string, b) primary DNS server and secondary DNS server both configured, c) trigger CRL update. CRL Update Failure alarm raised with reason "DNS Resolution Failure". Probability: Permanent Solution / Workaround: Check the DN entries in the primary DNS server. Use a stable DNS server as primary. Impact to Operator: When the primary DNS server cannot map the FQDN to corresponding IP address, eNB will fail the CRL update if the CRLDP is with FQDN even if there's a secondary DNS server configured.

3.545 [LTE1644-B-a] [FRMC] Recovery control after Hot insert-removal of RF module without BTS Reset is failing Problem report: 81003ESPE03 Exists in: LN 5.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: Test scenario: 1. BTS is in OnAir state with L111111-I-119-2TX-2RX (15 MHz) configuration. 2. Second radio is hot removed, cells number 2,4,6 which were commissioned on this radio are down. 3. After hot insert radio is not responding, cells are down. Two cells (number 2 and 4) are down with Failure in optical RP3 interface (4064) alarm and cell number 6 is down with Configuration error: Not enough HW for LCR (1868) Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: After hot insert radio is not responding, cells are down with Failure in optical RP3 interface (4064) alarm or with Configuration error: Not enough HW for LCR (1868).

3.546 [FRHC] VSWR tuning Problem report: 49901ESPE05 Exists in: LN 5.0 Corrected in: RL60 Severity: C - Minor Customer Impact: Operation & Maintenance



Description: Anytime in operational state. When user changes VSWR limit, a response to user (UI) about change of the value has to be within 1 second in most of cases. If VSWR alarm limit exceeds in filter/RRH 60W/WiMAX RFSW during VSWR threshold tuning procedure, VSWR alarm has to be indicated to user (UI) within 1 second in most of cases. It takes about 30s when new value is in use and alarm occurred. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: VSWR tuning is too slow.

3.547 [RF Sharing LTE-GSM] GSM TRX Tests fails after LTE BW change. Problem report: 41841ESPE07 Exists in: LN5.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: The GSM TRX Tests fails during the automatic testing phase in commissioning. TRX Test failure reason is:"RF Module RF Failure". After the commissioning, when TRX Test is executed manually, the test result will fail as well. The problem is visible when the LTE carrier BW is changed with commissioning from 5MHz to 10MHz in the following RF Sharing configuration: Two shared FXEB : LTE 1+1+1 5MHz (MIMO) H-type 20W 1+1+1, GSM C-type 20W/15W 3+4+3 (Operator1) and 4+3+4 (Operator2). Problem was found when testing GSM MOBBS configuration but the problem is visible also in non MOBBS configurations. Fault disappears after GSM BCF reset and TRX Tests works fine after that. Probability: Permanent Solution / Workaround: GSM BCF restart from BSC (MML terminal) or from GSM SiteManager. Impact to Operator: The TRX Test results is showing unnecessary RFM failure even the RFM is working fine. GSM commissioning report will show RFM failure as a result of automatic TRX Tests. Additional GSM BCF restart is needed to recover.

3.548 RL50 IPSEC conf dpd action parameter wrong (restart instead of clear) Problem report: 47381ESPE05 Exists in: LN5.0 Corrected in: RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: The "dpdaction" parameter for the IPSEC demon (strongswan) has wrong setting. This was (for no obvious reason) changed and apparently this change is causing lots of issues in customer networks. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 323/330 Version 1.0 Confidential


Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: The "dpdaction" parameter for the IPSEC demon (strongswan) has wrong setting.

3.549 FTIB : Partial drop in chained traffic when uplink u-plane traffic is sent simultaneously Problem report: 79925ESPE03 Exists in: LN5.0 Corrected in: RL60 Severity: C - Minor Customer Impact: Operation & Maintenance Description: With chained traffic ongoing (according to setup mentioned below), if uplink U-plane traffic is sent, partial traffic drop is seen in chained traffic. Setup: Chained traffic: IXIA-1 ---- EIF2--- EIF3 --- IXIA-2, Uplink traffic: IXIA-3 --- LMP --- EIF2 --- IXIA-1, Steps to reproduce: Set egress shaper rate for eif3 as 300 Mbps. Send following chained traffic: Q1 - 100 mbps, Q2 - 180 mbps (expected to leave DUT - 160 mbps) Q3 - 20 mbps and Q4 20 mbps. Start one stream of uplink u-plane traffic along with chained traffic. Drop up to 50 mbps is seen in chained traffic as soon as uplink traffic is started. Probability: Permanent Solution / Workaround: When enabling VLAN aware Ethernet switching on FTIB, the total number of different VLAN IDs configured in the VLAN ID Lists of the Ethernet interfaces must be limited. Impact to Operator: If a high number of different VLAN IDs (more than 100) is configured in the VLAN ID Lists, the number of available entries to learn new MAC addresses becomes limited. This may lead to the situation that ARP traffic due to repeated address resolutions increases. In the worst case, there may be no available entries left at all to learn new MAC addresses, which leads to the situation that all BTS traffic is constantly broadcast through all enabled Ethernet interfaces.

3.550 MHA current window alarms (1834 and 1835) not reported in SEM after RF module block/unblock Problem report: 111236ESPE04 Exists in: LN5.0 Corrected in: RL60 Severity: C - Minor Customer Impact: Operation & Maintenance Description: LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 324/330 Version 1.0 Confidential


Test 1: 1834 alarm 1. BTS is on air 2. Raise alarm (1834)=EFaultId_AboveCurrentWindowAl to FRGS 1.1.1 ANT 1 - Alarm reported correctly to SEM - OK 3. RF block/unblock, alarm (1834) still active to ANT 1 - Led of RF-module status is alternating red and green , ok (MHA fault happened) - Alarm not reported in SEM – NOK Test2: 1835 alarm 1. BTS is on air 2. Raise alarm (1835)=EFaultId_BelowCurrentWindowAl to FRGS 1.2.1 ANT 1 - Alarm reported correctly to SEM - OK 3. RF block/unblock, alarm (1835) still active to ANT 1 - Led of RF-module status is alternating red and green , ok (MHA fault happened) - Alarm not reported in SEM - NOK, Current window alarms (1834 or 1835) not reported in SEM after RF module block/unblock. Alarm handling is started when RF module is in "resetting" state according to BTSOM database. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: MHA current window alarms (1834 and 1835) not reported in BTSSM after RF module block/unblock.

3.551 Fragmented ESP Reassembly Failure for a range of Packet sizes Problem report: 108749ESPE01 Exists in: LN5.0 Corrected in: RL50 2.0, RL60 Severity: B – Major Customer Impact: Operation & Maintenance Description: Fragmented ESP Reassembly Failure for a range of Packet sizes and smaller first fragment. The root cause for the misbehavior is a limitation in the enodeB fastpath architecture to identify streams for C/M/U/S plane. So far this was done due to the L4 header (TCP/UDP/SCTP). In a rare scenario, where the fragmentation was done in reverse order (small fragment first), the L4 header got truncated due to this reverse fragmentation pattern. Reverse fragmentation means: first generated fragment is short, second fragment is long (as if the IP packet had been fragmented from the back to front, not front to back -> reverse) As a consequence, the Fastpath could not identify the destination of the packet due to the missing L4 information and had to discard the packet. Probability: Permanent Solution / Workaround: The issue can be avoided by usage of jumbo frames. Impact to Operator: It shall be mentioned, that reverse fragmentation could be considered as a defect in the backhaul network, as the expected fragmentation pattern would be: long fragment first, short fragment second. It can be observed heavy U-plane degradation concerning the throughput.

3.552 Decreased intra eNB HO success rate if rekeying is used Problem report: NA05665387 Exists in: LN 5.0 LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 325/330 Version 1.0 Confidential


Corrected in: RL50 2.0, RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: A high number of intra eNB handover fails because the HO command in the RRC connection reconfiguration has keyChangeIndicator set to “TRUE”. The reason for this is that after S1AP UE CONTEXT MODIFICATION REQUEST message with a new KeNB the keyChangeIndicator in HO target service was set , intra cell HO was then triggered, but after that keyChangeIndicator in HO target service did not reset, it was being used for next intra eNB handover which is causing handover failure. Problem concerns the Intra cell handover feature which is turned on by default. Probability: Permanent Solution / Workaround: Disable Rekeying Impact to Operator: Decreased intra eNB HO success rate if rekeying is used.

3.553 Restore of iOMS failed Problem report: NA05667382 Exists in: iOMS5.0 Corrected in: iOMS5.0 2.0, iOMS6.0 Severity: A - Critical Customer Impact: Operation & Maintenance Description: Perform iOMS restore from full backup: estores fails at the "./postRestore.sh --stage1" step with error message: "Nodes not found (postRestore:_exit) Unable to update HW info in LDAP", Dmidecode returns additional comment which breaks function responsible for extracting HW-related informations. Solution: Filtering out additional comments produced by dmidecode. Fix does not introduce any additional risk. Probability: Permanent Solution / Workaround: Below, you can find WA to avoid this issue. These steps need to be executed only once before iOMS backup procedure starts. 1. Overwrite bu_ffy.sh script with old version from corr16 2. Create SupportedHWTypes file in /var/mnt/local/sysimg/opt/Nokia_BP/etc/ 3. Redistribute the file: # fsdistribute /var/mnt/local/sysimg/opt/Nokia_BP/etc/SupportedHWTypes For procedure details please contact responsible TS team. Impact to Operator: Operator is unable to perform full restore from USB due to broken script used to retrieve HW related information.

3.554 FSMF fasttune does not work for SyncE, no alarm displayed Problem report: NA05634595 Exists in: LN5.0 Corrected in: RL50 2.0, RL60 Severity: B - Major Customer Impact: Operation & Maintenance LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 326/330 Version 1.0 Confidential


Description: When using the BTS fasttune option for transmission synchronization when there is SyncE being delivered to the BTS, SSM flag ok, the BTS does not alarm when the fasttune fails. We have tried a number of times to fasttune, each time we click fast tune option, nothing happens, the BTS clocking does not update (BTS Clock Tuning history) but the BTS never alarms. SyncE is definitely configured on the trs, SSM is showing PRC. This fault is to track the lack of alarming, the BTS should alarm if it fails fasttune or even if fast tune is not used, when the BTS periodically tunes the clock every 20mins, if this fails, it should alarm. No alarm of 1831 raised when tuning not success. Probability: Permanent Solution / Workaround: No Workaround Impact to Operator: FSMF fasttune does not work for SyncE, no alarm displayed

3.555 iOMS issue with backup archive naming Problem report: NA05644880 Exists in: iOMS5.0, iOMS6.0 Corrected in: iOMS5.0 2.0, iOMS6.0 1.0 Severity: C - Minor Customer Impact: Operation & Maintenance Description: OMS ID does not match during backup archive. When running backup archive using NetAct, OMS ID will not match with the set OMS ID in the backup archive. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Backup archive will fail since OMS ID does not match correctly.

3.556 No cronjob possible as user Nemuadmin Problem report: NA05628278 Exists in: iOMS5.0 Corrected in: iOMS5.0 1.1, iOMS 6.0 Severity: B - Major Customer Impact: Operation & Maintenance Description: The "crontab" command will not work for other user accounts than root. Only the root user is able to manage cron jobs using the "crontab" command. The SGID bit (special type of file permissions given to a file/folder) was taken away from the crontab binary and no other means of allowing regular users to manage cron jobs with the "crontab" command were delivered. Probability: Permanent Solution / Workaround: Issue the command "chmod g+s /usr/bin/crontab". That command applies a SGID bit to the /usr/bin/crontab binary so that this binary even when run as a regular user behaves as if it was run by the root user (because the group owner of this binary is root). Impact to Operator: The "crontab" command can only be run by root.



3.557 PUCCH RSSI Values are differents between FXEA and FXEB Problem report: NA05573872 Exists in: LN4.0, LN5.0 Corrected in: RL50 2.0, RL60 Severity: B - Major Customer Impact: Operation & Maintenance Description: FXEB is having wider RX band filter, thus possible interference signal is received by filter and is summed into PUCCH RSSI measurement. In places where are swapped FXEA for FXEB, there was a difference of about 4 dB. Probability: Permanent Solution / Workaround: No workaround. Impact to Operator: Reported PUCCH level is 4dB lower. Average RSSI for both PUSCH and PUCCH are increased by 4dB. No effect to service.

3.558 FSPC unit autonomous reset with faulty 4019 - UEC crash in function Problem report: 109307ESPE01 Exists in: LN5.0 0.2 (LN5.0_ENB_1304_647_28) Corrected in: RL50 1.0, RL60 0.1 Severity: B - Major Customer Impact: Operation & Maintenance Description: RL50 0.2.1 experience crashes during HO procedures to RL60 sites. Specifically, issue was introduced with LN5.0_ENB_1304_647_28. In RL60 eNB SW, InfoElement ‘AntennaInfoRel10’ is requested from Rel 10 UE and added to X2 HO message to RL50 eNB. In case of HO fails , UE performs RRC Connection Reestablishment Request in RL50 eNB with InfoElement ‘AntennaInfoRel10’. While building downlink RRCConnectionReestablishment with InfoElement ‘AntennaInfoRel10’. UEC module got crashed due to coding error that caused a memory violation. Subsequently it triggered autonomous restart of FSP module. Probability: Occasional (High when RL50 0.2 sites are neighboring RL60 sites.) Solution / Workaround: Upgrade to RL50 1.0 or RL60 0.1. Impact to Operator: High number of eNB restarts. Issue will be seen case for HO failure from RL60 to RL50 eNBs for Rel 10 UEs

3.559 7654 System Module Failure spurious alarm due to RET failure Problem report: NA05622045 Exists in: LN5.0 Corrected in: RL50 2.0, RL60 Severity: C - Minor Customer Impact: Operation & Maintenance Description: Live network, site with 6 RETs in chain. Occasionally alarm 7654 Cell Operation Degraded system module failure occurred instead of "Antenna Line Device Failure." Wrong fault id is set, so FM cannot link fault with its source, and alarm is raised for whole system module. A device is assign two different address. LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48 Page 328/330 Version 1.0 Confidential


Root cause: HDLC link is not initialized again if scanned device has been initialized at previous. This is corrected now. Probability: Occasional Solution / Workaround: No Workaround Impact to Operator: Occasionally alarm 7654 "Cell Operation Degraded - system module failure" occurred instead of "Antenna Line Device Failure" occurs in chained configurations.



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.



LGF-LTE-RL50FZ_RL60_RL70_FL15A-2015-w48

Recommend Documents