Change Note Forms
Product Family:
Product:
Release:
Base Stations
Flexi Multiradio BTS LTE
FL15A 1.1
Approval date: 14-Apr-2016
Summary of changes:
Date
14-Apr-2016
Version
1.0
Summary of changes
Approved version
Nokia Solutions and Networks is continually striving to reduce the adverse environmental effects of its
products and services. We would like to encourage you as our customers and users to join us in working
towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for
power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we
offer, please contact us at Nokia Solutions and Networks for additional information.
FL15A 1.1 - Change Note Forms - Page 1/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00247
Title:
Fault 1900 is not cleared forever after recovery reset due to fault 1841
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Fault 1841 was raised and as a recovery radio was reset. During the radio reset, fault 1900
conditions was detected for short time but after raise, fault 1900 was never cleared.
How end user/operator could detect the problem:
Fault 1900 appears and is never cleared.
Description of the fault:
Due to bug in fault 1900 handling, when fault 1900 conditions are visible for short time (less
than 5s) it can happen that processing of fault cancelation will be processed before fault start
which led to fault 1900 staying forever in active state.
Dependency on configuration:
None. Can occur in any configuration.
Faulty component and version:
OAM/FaReco
Workaround:
No workaround
Description of the correction:
A proper handling of short occurrence of fault 1900 was implemented.
Corrected Fault Reports:
NA05857176
Fault 1900 is not cleared forever after recovery reset due to fault 1841
Modified components:
Component
fareco.-
Version
14460
FL15A 1.1 - Change Note Forms - Page 2/66
Version 1.0
Confidential
*Net element
*SW-type
*Unit
© Nokia Solutions and Networks 2016
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05857176)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional.
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 3/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00248
Title:
Multiple ENB's showing High Memory Consumption
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
There is a sudden surge in the amount of memory being allocated. The memory surge is
approximately 10MB per day, without end.
How end user/operator could detect the problem:
When enough memory has been allocated, then a Memory alarm will appear. In order to
detect the problem earlier, then memory stats can be monitored.
Description of the fault:
There are several defects that combine to produce the problem. Basically, if the Broadcast
Socket receives a RR/RNR/Alarm message while Scanning is running, then an infinite loop is
entered. That infinite loop also allocates memory for a message to send, but the message is
not actually sent, nor is the memory recovered.
Dependency on configuration:
AISG communication must be enabled.
Faulty component and version:
MOAM Rl70, all future version of MOAM also contain the error.
Faulty component first delivered in(e.g. release, CD):
RL70, FL15A, FL16
Workaround:
Setting the AISG communication to disabled will stop the problem.
Description of the correction:
First change is to replace the new/delete message interface with a stack-allocation/pass-byreference interface. This will stop the memory leak.
Second change is to modify the BroadcastSocket to (gracefully) handle RR/RNR messages.
This will stop the memory leak. Note: The RR/RNR message is not considered a valid
response per spec. Current suspicion is that an ALD device is not following the spec.
Corrected Fault Reports:
NA05850170
FL15A 1.1 - Change Note Forms - Page 4/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Multiple ENB's showing High Memory Consumption
NA05880543
High memory consumption
NA05890847
[FL15A_enodeB] “ MRBTS-19864 Antenna Line Failure 0010 on MHA in FRMC
PR126004
[FSMr3][FL15A 1.0] Increase in BTSOMexe memory consumption
Modified components:
Component
MOAM.-
Version
50759
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05850170, NA05880543, PR126004, NA05890847)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 5/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00249
Title:
4G BTS MAC address (planeMacAddr) not available in Netact
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
The parameters are not part of exception list in TRSW, as a result of which they are not
exported to the SCF.
How end user/operator could detect the problem:
4G BTS MAC address (planeMacAddr) not available in Netact
Description of the fault:
The parameters are not part of exception list in TRSW, as a result of which they are not
exported to the SCF.
Workaround:
No workaround
Description of the correction:
The 2 parameters have to be added in an exception list in TRSW, as a result of which they will
be exported to the SCF.
Corrected Fault Reports:
NA05868410
4G BTS MAC address (planeMacAddr) not available in Netact
Modified components:
Component
team_odyssey_n
a05868410_fix_fl
15a.-
Version
*Net element
FTM_R3_FL
15A_TL15A_
W16_MP1_4
55.00.01
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
FL15A 1.1 - Change Note Forms - Page 6/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05868410)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 7/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00250
Title:
eNodeB freeze with "BTS internal SW management Problem during SW DL
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
After Downloading SW to eNB, BTS Internal SW management problem alarm raised, SW File
distribution failed with error: No Reply from FTM, Problem seen in TRSW as ORB Hang while
collecting FTM Logs
How end user/operator could detect the problem:
eNB Abrupt Restart/ Loss of OAM Connection to eNB, during log collection FTM get Struck.
Description of the fault:
A process which was created for FTM extended log collection, got crashed/killed when it was
holding a semaphore. As a result timer threads which needs the same semaphore got blocked
waiting for the same. Since a new thread gets spawned each time a timer expires, this led to a
number of new threads getting spawned and all waiting due to unavailability of semaphore.
This piling up of timer threads leads to high memory utilization.
Since the first timer thread which got blocked also holds the run permission (which is needed
for inter process communication) , other threads which needs run permission also gets
blocked which leads to ORB hangs. This ORB hang triggers a recovery reset, but this gets
blocked due to the high memory utilization caused by the piling up of Timer threads.
Workaround:
Avoid running node backup too frequently, this could lead to frequent failures.
Description of the correction:
1. Timer thread releases run permission temporarily before trying to acquire semaphore so
that other threads can acquire run permission and proceed even if timer thread is blocked on
semaphore.
2. Tracking mechanism is added with which processes can check whether they are holding
the semaphore and release the same before exiting. In addition, if semaphore is not available
for 5 minutes, a dummy post is done for making it available again for all.
3. A possible buffer over run which can lead to semaphore release being skipped in API calls
is corrected by passing a local buffer of correct size
Effects on operator:
Power On Reset Required to recover out of this condition without the fix.
FL15A 1.1 - Change Note Forms - Page 8/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Corrected Fault Reports:
NA05882346
eNodeB freeze with "BTS internal SW management Problem during SW DL
Modified components:
Component
Version
*Net element
wipro_sabharga_ FTM_R2_FL
na05882346_fix_f 15A_MP1_3
l15.55.00
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05882346)
Testing Instructions for the change
Pre-requirements:
eNB running
Test execution:
Start collecting FTM logs [example: ExtendedNE logs, Snapshot logs or scheduled log
collections etc] in regular intervals.
Expected results:
eNB connection via SEM or TRS Web UI should remain stable. Log collection process should
run normally, other eNB process should run normally after log collection is completed.
Unexpected results:
Occasionally loss of eNB connection either via SEM or TRS Web UI will be observed, FTM
internal processes may get hanged or crashed due to increased memory utilization, which
could affect other processes like eNB SW download/Activation etc.
FL15A 1.1 - Change Note Forms - Page 9/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00251
Title:
Cell configuration data distribution failed(6253) on Power Saved Mode(LTE1103)
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
User deletion for UEx is in progress (MAC_UserDeleteReq is sent and waits for response).
Cell deletion request occurs and thread responsible for UEx still waits for
MAC_UserDeleteResp so it delays UEC_CellDeleteResp for this thread.
How end user/operator could detect the problem:
Problem can be detected when there is UE release ongoing when RROM sends cell deletion
requests.
Description of the fault:
MAC is not obliged to send the response after it receives cell deletion request. UEC waits 10
seconds for MAC_UserDeleteResp and in that time cell deletion timeouts (timer for cell
deletion is set to 5s).
Faulty component and version:
UEC
Description of the correction:
When UEC is waiting for MAC_UserDeleteResp and receives cell delete request, it aborts
waiting for the response from MAC and proceeds with cell deletion procedure.
Corrected Fault Reports:
NA05886221
Cell configuration data distribution failed(6253) on Power Saved Mode(LTE1103)
Modified components:
Component
Version
UEC.424549
LTE_CP_66368.- 1
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
FL15A 1.1 - Change Note Forms - Page 10/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05886221)
Testing Instructions for the change
Pre-requirements:
eNB is on air
Test execution:
Upgrade SW
Expected results:
Connectivity towards OMS remains stable.
Unexpected results:
Connection towards OMS not stable, logs shows TCP socket error
FL15A 1.1 - Change Note Forms - Page 11/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00252
Title:
VoLTE DCR 5 degradation after activate dyn DRX
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
VoLTE DCR 5 bps degradation after activate dyn DRX.
Description of the fault:
MAC PS SW estimates the initial channel status based on the first CQI sample and reports it
to UEC. Any update is estimated according to a defined algorithm (taking more samples into
consideration) and cannot be sent before a minimum interval time between two consecutive
reports for a certain UE (1sec). Critical scenario: Channel status is set as ‘good’ based on the
first CQI sample but the channel deteriorates suddenly afterwards. MAC PS SW cannot react
quick enough due to 1s wait time.
Workaround:
No workaround
Description of the correction:
MAC PS SW assumes that the initial state is ‘good’ (as assumed by UEC) such that it can
react to any change in a shorter time;
Effects on operator:
Increased Voice call drop rate.
Corrected Fault Reports:
NA05891386
VoLTE DCR 5 degradation after activate dyn DRX
Modified components:
Component
Version
LTE_SFS_RRM.
2.0
9017
LTE_UP_17810.- 3.0
fb15_03.379788
*Net element
*SW-type
*Unit
Change effects:
FL15A 1.1 - Change Note Forms - Page 12/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05891386)
Testing Instructions for the change
Pre-requirements:
eNB is on air and cells are available. DRX is enabled in cells.
Test execution:
Attenuate both source and target cell tx power and UE makes HO to target cell even it is also
not good.
Expected results:
In target cell because of the bad radio conditions eNB requests drx deactivation as quick as
200ms by sending RrcConnectionReconfigruation(DRX release) to UE.
Unexpected results:
In target cell because of the bad radio conditions eNB requests drx deactivation by sending
RrcConnectionReconfigruation(DRX release) to UE but it is done more than 200ms after.
FL15A 1.1 - Change Note Forms - Page 13/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00253
Title:
SCTP association stops attempting to establish to MME
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Upon testing a particular scenario it turned out that after performing an eNB reset a S1 link
can't get established, but there is no alarm raised on this issue.
The exact scenario that had been tested included resetting the eNB while the connectivity
between the eNB and the MME was simultaneously interrupted.
How end user/operator could detect the problem:
A SCTP link remains unavailable after an eNB reset with no connectivity alarm being raised.
Description of the fault:
It turned out that the link establishment attempt triggered after the eNB reset failed because of
link-related resources still being not yet released at the Linux kernel level, making the
connect() call done by TUPc application to fail with EADDRNOTAVAIL error. As the scenario
was not really possible before changing the way how the eNB reset is done in the LTE1266
feature, there was no clear requirements on how TUPc shall behave upon encountering such
a problem and the application was simply responding to the link setup request, that triggered
the link creation in the first place, with NotOk. The eNB requirements did not really foresee
such an answer from the application, so the original requester (ENBC) was not taking any
further steps upon getting NotOk answer from TUPc application. All of this led to a situation
where after getting such an error upon connect attempt there were no further attempts taken
to establish the connection, and no alarm was raised, while still being okay with the
specification.
The problem should only be possible when the connectivity towards a remote host is
interrupted short time before eNB reset, but not yet detected.
Dependency on configuration:
Low max RTO (retransmission timeout) values and low max retransmission numbers for the
SCTP configuration significantly reduce the chance for encountering the issue making the
releases on the kernel layer to time out faster.
Faulty component and version:
There was no single application responsible for the problem as the problem is actually an
unforeseen and therefore unspecified scenario of interactions between multiple applications
and planes: CPlane (ENBC, TUPc), Platform (LFS, LXC containers, maybe HWApi).
FL15A 1.1 - Change Note Forms - Page 14/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Nevertheless the problem had been introduced with implementation of LTE1266, where the
eNB reset no longer meant resetting the OS as well.
Faulty component first delivered in(e.g. release, CD):
FL15A
Workaround:
Another eNB reset, or S1 link reconfiguration, where the link is removed first, and added again
later.
Description of the correction:
Right now TUPc upon encountering such a problem responds with LinkSetupResp:Ok, but
schedules next connect() attempt in 5 seconds, that should give the kernel enough time to
clean its resources up. If the second connect attempt fails it is reported to the ENBC, that the
link is out of service, so the 6202 alarm will be raised, and next attempts are scheduled every
60 seconds until success.
Risk analysis of the correction is that there may be some additional alarms reported for a
while after eNB resets sometimes.
Corrected Fault Reports:
NA05864947
SCTP association stops attempting to establish to MME
PR103379
6202 alarm transport layer connection failure in s1 not shown
Modified components:
Component
TUPc.-
Version
422285
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05864947, PR103379)
FL15A 1.1 - Change Note Forms - Page 15/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 16/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00254
Title:
Unit Autonomous Reset happens after fault 4019 in the FBBA
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Unit Autonomous Reset happens after fault 4019 in the FBBA.
Description of the fault:
With LTE2050 IMMLB algorithm compares serving cell available capacity (CAC) with the
operator configured threshold to determine if UE should be load balanced. CAC value update
comes to UEC from ENBC every 0.5 second it needs to be stored in cell related data and
IMMLB specific data. It might happen that when UE is released in the same time as CAC
value update is received there will be a deadlock situation.
- Cell thread will have already locked the cell specific mutex and is waiting for release of
IMMLB specific mutex (which is already locked by UE thread).
- UE thread will have already locked the IMMLB specific mutex and is waiting for release of
cell specific mutex (which is already locked by cell thread).
Workaround:
Probably only disabling LTE1677 will work.
Description of the correction:
CAC value update is rework not to lock mutex with a locked mutex:
1. New CAC value received (cell thread)
2. Cell specific data mutex lock
a. CAC stored to cell specific data
3. IMMLB specific mutex lock
a. CAC stored to IMMLB specific data
In this way cell thread will not cause deadlock situation.
Effects on operator:
Occasional Unit Autonomous Reset occur.
Effects on end-user:
Temporary service degradation during unit reset
Corrected Fault Reports:
NA05893066
Unit Autonomous Reset happens after fault 4019 in the FBBA
FL15A 1.1 - Change Note Forms - Page 17/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Modified components:
Component
UEC.-
Version
424270
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05893066)
Testing Instructions for the change
Pre-requirements:
Checked the Alarm history as Unit Autonomous reset after fault ID=4019.
Install SW to corrected SW into above target site.
Test execution:
Monitoring whether Unit Autonomous reset happens after fault 4019, or not.
Actually, it is not easy to verify its correction in lab environment.
Expected results:
Unit Autonomous reset happens after fault 4019 doesn't happen.
Unexpected results:
Unit Autonomous reset happens after fault 4019 happens.
FL15A 1.1 - Change Note Forms - Page 18/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00256
Title:
After Upgrading to latest FL16A load, changed login password get expired
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Across upgrade the certs were lost.
How end user/operator could detect the problem:
The certs present before upgrade will be lost and IPsec connectivity to the eNB will fail.
Operator cannot login in to the eNB.
Description of the fault:
During upgrade the target software was copying certificates from a wrong location, due to this
all the certs were lost.
Faulty component and version:
TRS module
Workaround:
A workaround is released to backup the certs in a suitable location before upgrade.
Description of the correction:
The certs will be copied from a right location, which will solve the problem across upgrade.
Effects on operator:
Wrong security configuration can be present after SW upgrade or SW update. Affected are
Operator Certificates and Local Account settings. When the problem occurs, the old
certificates and Local account settings of N-2 SW are get back in use.
Corrected Fault Reports:
NA05894966
Automatic BTS Operator Certificate retrieval unsuccessful (61510) after TL16 PD1 upgrade
Modified components:
Component
Version
*Net element
avengers_na058
FTM_R3_FL
94966_fl15amp1. 15A_TL15A_
FL15A 1.1 - Change Note Forms - Page 19/66
Version 1.0
Confidential
*SW-type
*Unit
© Nokia Solutions and Networks 2016
-
W16_MP1_4
66.00
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05894966)
Testing Instructions for the change
Pre-requirements:
eNodeB running well under the LNT5.0_ENB_1407_556_48
Test execution:
Upgrade the eNodeB into the TL16_ENB_0000_000508_000010 from TL55
Expected results:
The eNodeB should run normally after the restart
Unexpected results:
Two sites lost O&M remote connection after TL16 PD1 upgrade.
Automatic BTS Operator Certificate retrieval unsuccessful occurred to both cases. BTS SM
shows certificate is expired in TL16.
They are back on air after SW rollback to RL55.
Below alarm also occurs on the TL16 version,
Severity: Major
Time: 25.02.2016 00:09:10
Fault name: Automatic BTS Operator Certificate retrieval unsuccessful
(61510)
Source: TRS: Certificate Management
Alarm Code: 7665
Fault Code: 61510
Scope: Base station transmission alarm
State: Active
Clear time:
Code: 61510
Type: Communication
FL15A 1.1 - Change Note Forms - Page 20/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00257
Title:
FL16 PCD2.1 Failure during SW upgrade - passive bank not available, unable to rollback
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
How end user/operator could detect the problem:
Do rollback.
Description of the fault:
After SW update, there will be site reset in normal cases. And in RL70 OAM code, we started
a 2 minutes timer to write FileDirectory.xml file into flash after SW update finished. In this
pronto, the site reset was triggered too quickly and almost same time as 2 minutes timeout
happened. So the result is during FileDirectory.xml file updated, site reset happened and file
get corrupted.
Faulty component first delivered in(e.g. release, CD):
RL70
Workaround:
Creating an auto-script to check if the FileDirectory in passive bank was corrupted. If yes, then
do the file recovery. Afer upgrading from RL70 to any higher release, run this script to check
the sanity of FileDirectory file.
Description of the correction:
Save FileDirectory.xml once activition completes immediately.
Correction effects:
Repair the FileDirectory file.
Corrected Fault Reports:
NA05897506
FL16 PCD2.1 Failure during SW upgrade - passive bank not available, unable to rollback
Modified components:
Component
Version
FL15A 1.1 - Change Note Forms - Page 21/66
Version 1.0
Confidential
*Net element
*SW-type
*Unit
© Nokia Solutions and Networks 2016
MOAM.-
46788
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05897506)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional.
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 22/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00258
Title:
LTE1684 feature doesn't work properly
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
When LTE-idle carrier is active then the input signal for vswr measurement is very variable. In
such conditions there are a lot of moments when vswr cannot be calculated. Each time the
VSWR could not be calculated the VSWR parameter requested by SM was reseted to 0.
Description of the correction:
The more traffic on the carrier the smaller probability of 0 value of VSWR.
Effects on operator:
VSWR = 0 visible in Site Manager very often.
Corrected Fault Reports:
NA05893042
LTE1684 feature doesn't work properly
Modified components:
Component
FRM35.08
Version
*Net element
FRM35.08.R
36L
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
FL15A 1.1 - Change Note Forms - Page 23/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
N/A
Customer Impact
Change 1: (NA05893042)
Testing Instructions for the change
Pre-requirements:
eNB up and running no alarms visible.
Test execution:
Check measurements for VSWR value (functionality from LTE1684).
Expected results:
Non 0 values of VSWR are visible in measurements.
Unexpected results:
0 return in VSWR value.
FL15A 1.1 - Change Note Forms - Page 24/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00259
Title:
(FDD-LTE RL70MP2.0)Tom rl60 to rl70he base station upgrade fr, TRS disconnection(All
Link).
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
TRS disconnection when upgraded from rl60 to rl70
Description of the fault :
There were rules added to arp table to drop packets with source mac as multicast
Faulty component and version:
FTM_R3_LN70_LNT50_FZM55_WN9010_MP1_470.00
Description of the correction:
The ARP rules are not needed and was added by mistake and hence will be removed
Effect on operator:
All the ARP packets with destination MAC address used as Multicast address will get
dropped, and hence no ARP resolution will be done for those MAC addresses. Applications
using the services from Multicast MAC addresses will not work since IP packets cannot be
sent out.
Corrected Fault Reports:
NA05870195
(FDD-LTE RL70MP2.0)Tom rl60 to rl70he base station upgrade fr, TRS disconnection(All
Link).
Modified components:
Component
Version
*Net element
na05870195_fl15 FTM_R3_FL
a_tl151a_fix.15A_TL15A_
W16_MP1_4
65.00
*SW-type
*Unit
Change effects:
Effects on end-user
FL15A 1.1 - Change Note Forms - Page 25/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05870195)
Testing Instructions for the change
Pre-requirements:
eNB running with FL15A 1.1 SW build, default gateway has Multi-cast MAC address.
Test execution:
Upgrade the eNB to FL15A 1.1 SW build.
Expected results:
ARP should get resolved for the default gateway router, and the backhaul traffic will flow
normally.
Unexpected results:
ARP resolution for Gateway router will get failed and ARP packet will get dropped due to
multicast MAC address in ARP reply, and since ARP will not get resolved eNB cannot send
any packets outside.
FL15A 1.1 - Change Note Forms - Page 26/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00260
Title:
Missing parameter consistency check error in case of inter-eNB CA configuration
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
The DL Carrier Aggregation (CA) related consistency check for parameter "ACK/NACK offset"
(n1PucchAn) in not performed when all configured SCells (CAREL objects) are located on
another eNB (via parameter "BTS ID of the parent eNB of the cell to be aggregated").
How end user/operator could detect the problem:
If you configure an eNB for carrier aggregation only certain values are allowed for LNCEL
"ACK/NACK offset". E.g. "ACK/NACK offset" = 36 is NOT allowed in CA configuration.
However, BTSSM does NOT issue a consistency check warning about such invalid
configuration, if ALL CAREL objects that belong to this LNCEL point to another eNB by
parameter "BTS ID of the parent eNB of the cell to be aggregated" (let's call this "pure intereNB CA" configuration).
This PR requests to change the consistency check behavior of BTSSM such that CA related
consistency checks are also performed in the "pure inter-eNB CA" configuration.
Description of the correction:
Separate PLNCEL generation and PLNCEL related conditions
Effects on operator:
The operator might not be informed about PCell misconfiguration which can lead to cell setup
failures.
Corrected Fault Reports:
PR117890
Missing parameter consistency check error in case of inter-eNB CA configuration
Modified components:
Component
Version
ltebtsmanager.jar 873413
*Net element
*SW-type
*Unit
Change effects:
FL15A 1.1 - Change Note Forms - Page 27/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR117890)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 28/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00261
Title:
LTE1980: DUT got Crashed Sending U-plane traffic on Vlan Tunnel End points
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Fastapath is crashed while IPv6 L2 header
Description of the fault:
Unnecessarily swp.s.back address was modified for vlan packets. Due to which Fastpath is
crashed while adding L2 header for vlan packets
Workaround:
No workaround
Description of the correction:
Removed unnecessary check in fastpath
Corrected Fault Reports:
PR115629
LTE1980: DUT got Crashed Sending U-plane traffic on Vlan Tunnel End points
Modified components:
Component
Version
*Net element
passion_fl15a_du FTM_R3_FL
t_crash_ipv6vlan. 15A_TL15A_
W16_MP1_4
55.00.02
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
FL15A 1.1 - Change Note Forms - Page 29/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR115629)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 30/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00262
Title:
X2AP Cell Trace - X2AP RLF Indication - loss of last 5 bytes
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Incoming X2 AP RLF INDICATION is traced but without rRCConnSetupIndicator and
rRCConnReestabIndicator fields.
Faulty component first delivered in(e.g. release, CD):
Problem exists in FL15A, FL16
Workaround:
No workaround
Description of the correction:
Adding rRCConnSetupIndicator and rRCConnReestabIndicator from X2 AP RLF INDICATION
to tracing
Effects on operator:
Operator get traced X2 AP RLF INDICATION but some of data will be lost.
Corrected Fault Reports:
PR125539
X2AP Cell Trace - X2AP RLF Indication - loss of last 5 bytes
Modified components:
Component
UEC.-
Version
423821
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
FL15A 1.1 - Change Note Forms - Page 31/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR125539)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 32/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00263
Title:
DBD-EuUec::UeContextThr
ERR/Common/CommonLomAgentCplaneErrorHandlingPolicy.cpp#34 Object with requested
Uri not found
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Error log is displayed in syslog and counter is not incremented because wrong PLMN is used
during incrementation.
How end user/operator could detect the problem:
Error log 'Object with requested Uri not found' is present in syslog and wrong counter value
(EPmCounterId_LteUecNumOfHandoverAttForUesRunningInDrxMode,
EPmCounterId_LteUecNumOfHandoverComplForUesRunningInDrxMode)
Faulty component and version:
UECexe
Faulty component first delivered in(e.g. release, CD):
UECexe
Description of the correction:
Cell primary PLMN is used when incrementing counter '525664274
(EPmCounterId_LteUecNumOfHandoverAttForUesRunningInDrxMode)' and '525664275
(EPmCounterId_LteUecNumOfHandoverComplForUesRunningInDrxMode)'.
Corrected Fault Reports:
PR127295
DBD-EuUec::UeContextThr
ERR/Common/CommonLomAgentCplaneErrorHandlingPolicy.cpp#34 Object with requested
Uri not found
Modified components:
Component
UECexe.-
Version
423560
FL15A 1.1 - Change Note Forms - Page 33/66
Version 1.0
Confidential
*Net element
*SW-type
*Unit
© Nokia Solutions and Networks 2016
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR127295)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 34/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00264
Title:
[LTE2562]: UeContextThr crashed after 1xCSFB performed when LTE2562 is enabled and
ANRPRX is set
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Wrong handling of uninitialized optional cellToAddModList under CDMA2000 MeasObject
resulting in UEC crash.
Faulty component and version:
FL15A
Description of the correction:
Fixed handling of uninitialized optional cellToAddModList under CDMA2000 MeasObject.
Corrected check for uninitialized value.
Effects on operator:
Possible UEC crash when UE with configured measObjectCdma2000 and empty
cellsToAddModList is attached to cell.
Effects on end-user:
Possible lost connection.
Corrected Fault Reports:
PR116987
[LTE2562]: UeContextThr crashed after 1xCSFB performed when LTE2562 is enabled and
ANRPRX is set
Modified components:
Component
UEC.-
Version
424435
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
FL15A 1.1 - Change Note Forms - Page 35/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR116987)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional.
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 36/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00265
Title:
FL16 QCI1 Call dropped due to 'RrcConnectionReconfguration' message not scheduled
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
QCI1 Call dropped due to 'RrcConnectionReconfguration' message not scheduled
How end user/operator could detect the problem:
Call drop after QCI1 bearer delete
Description of the fault:
DRX in MAC PS DL ignored DRX on duration in the transient phase of a DRX reconfiguration.
On duration should only be ignored in the transient phase of a DRX activation, but not of a
DRX configuration.
Dependency on configuration:
DRX on.
Description of the correction:
Change condition to ignore DRX on duration only in transient phase of DRX activation.
Effects on operator:
KPI decrease.
Effects on end-user:
Call drop.
Corrected Fault Reports:
PR129395
FL16 QCI1 Call dropped due to 'RrcConnectionReconfguration' message not scheduled
Modified components:
Component
fb15_03.-
Version
380298
FL15A 1.1 - Change Note Forms - Page 37/66
Version 1.0
Confidential
*Net element
*SW-type
*Unit
© Nokia Solutions and Networks 2016
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR129395)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional.
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 38/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00266
Title:
Connection setup KPI drop because Received MAC_CCCH_DATA_SEND_REQ while there
is no user!
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
KPI drop
Description of the fault:
CCS was not taking into account file system fragmentation which resulted in exhausting space
in nvrd volume which causes drop in KPI
Related feature / functionality:
CN5613
Dependency on configuration:
No
Workaround:
BTS reset
Description of the correction:
File system fragmentation was taken into account when calculating available space in rpram
Corrected Fault Reports:
PR117946
Connection setup KPI drop because Received MAC_CCCH_DATA_SEND_REQ while there
is no user!
Modified components:
Component
ARCH.-
Version
*Net element
FL15A_ARC
H_0000_399
787_000000
*SW-type
*Unit
Change effects:
FL15A 1.1 - Change Note Forms - Page 39/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR117946)
Operation & Maintenance
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 40/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00267
Title:
[FSMr3] After multi-RET swap, RET unit2 is not assigned to ANT ports in RET Settings page
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
When replacing MultiRet by another MultiRet with a different serial number only one RET will
receive a CCN notification due to having only a single RET_A MO in DELTA with multiple
scfDN
How the problem can be detected by operator/end-user:
After hot swapping a multi-RET with another multi-RET, BTSSM Commissioning Wizard RET
Settings 1/2 page should display ANT assignments and additional data for RET subunit1 and
subunit2. However, RET subunit2 information is missing from BTSSM.
Description of the fault:
Only the first scfDN is added to the changedParamList
Workaround:
Assigning ANT ports and additional data to hot swapped multi-RET subunit2 during
recommissioning
Description of the correction:
Loop thru scfDN instead instead of finding only the first one.
Corrected Fault Reports:
PR126483
[FSMr3] After multi-RET swap, RET unit2 is not assigned to ANT ports in RET Settings page
Modified components:
Component
SYSADAPT.-
Version
28770
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
FL15A 1.1 - Change Note Forms - Page 41/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR126483)
Testing Instructions for the change
Pre-requirements:
eNB is alarm free and cells are on air. A multi-RET (with 2 sub units) is configured and
commissioned to a radio module.
Test execution:
Block radio module.
Physically swap a multi-RET with another multi-RET of same vendor and model.
Unblock radio module.
Expected results:
Commissioning Wizard RET Settings ½ page should show data for multi-RET sub-unit 1 and
sub-unit 2.
Unexpected results:
Commissioning Wizard RET Settings ½ page does not show data for multi-RET sub-unit 2.
FL15A 1.1 - Change Note Forms - Page 42/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00268
Title:
[FL15A_1.1][SFE] Not enough radio resources for QCI 2 and 3 E-RABs setup
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Not enough radio resources for QCI 2 and 3 E-RABs setup
Description of the fault:
Wrong calculation of cell TransmissionEfficiency
Workaround:
No workaround
Description of the correction:
Calculation of cell TransmissionEfficiency fixed
Effects on operator:
Degradation of GBR calls success ratio for QCI 2 and 3 services.
Effects on end-user:
Degradation of quality for QCI 2 and 3 services.
Corrected Fault Reports:
PR132891
[FL15A_1.1][SFE] Not enough radio resources for QCI 2 and 3 E-RABs setup
Modified components:
Component
fb15_03.-
Version
r384564
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
FL15A 1.1 - Change Note Forms - Page 43/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR132891)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 44/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00269
Title:
[LTE1103] RAC is passed during HO while target cell's status is barred
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
eNb allowed UE to attach to cell even though it was already barred due to energy saving
procedure.
Description of the fault:
Missing port to FL15A branch.
Workaround:
No workaround
Description of the correction:
Corrected radio control admission code in CELLC.
Corrected Fault Reports:
PR135128
[LTE1103] RAC is passed during HO while target cell's status is barred
Modified components:
Component
CELLC.-
Version
r428142
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
FL15A 1.1 - Change Note Forms - Page 45/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
N/A
Customer Impact
Change 1: (PR135128)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 46/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00270
Title:
LTE1140 LB started with blacklistHoL to neighbour eNB cell
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
LNCEL/blacklistHoL/freqEutra has a 'special value' defined for FDD release. Special values
require special implementation, which was missing in this case.
Align documentation of LTE1140 "Resource Status Reporting Control" to LTE1841 "Resource
Status Reporting Control" feature behaviour.
Handle "Resource Status Reporting Control" in case of existing X2 interface between eNBs
and parameter LNCEL/blacklistHoL/blacklistTopo configured to onlyX2 to neighbour cell of
target eNB
Description of the correction:
Implementation and documentation correction needed
Effects on operator:
Blacklisting on own cell frequency is not possible without 'special value'.
In case of configured LNCEL/blacklistHoL/blacklistTopo configured to onlyX2 to neighbour
eNB end existing X2 interface between eNBs, Inra-frequency load balancing via S1 interface
will not start to target eNB.
Effects on end-user:
UEs can perform handover into blacklisted cell on the same frequency
Impact on UE data throughput
Corrected Fault Reports:
PR132467
LTE1140 LB started with blacklistHoL to neighbor eNB cell
Modified components:
Component
ENBC.RROM.-
Version
429921
429921
*Net element
*SW-type
*Unit
Change effects:
FL15A 1.1 - Change Note Forms - Page 47/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (PR132467)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 48/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00271
Title:
Increased BER detected on the optical connection to Radio Module (1955)
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Increased BER detected on the optical connection to Radio Module (1955) alarm raised after
upgrade eNB from LN7.0_ENB_1407_570_77 to FL15A_ENB_0107_001533_000000
Workaround:
No workaround
Description of the correction:
Enable sorting bus nodes for TX resources for LTE15 Faraday so that HW will not complain
about missing messages and overflow errors and in consequence alarm 1955 will not accure.
Effects on operator:
Alarm 1955 not visible; there might be some KPI degradation.
Corrected Fault Reports:
PR137176
Increased BER detected on the optical connection to Radio Module (1955)
Modified components:
Component
Version
*Net element
BTSRFM-52192.- MED25.08.R
18L
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
FL15A 1.1 - Change Note Forms - Page 49/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
New functionality
N/A
Customer Impact
Change 1: (PR137176)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 50/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00272
Title:
LTE1460 doesn't work correctly in FL15A
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
LTE1460 doesn't work correctly in FL15A
How end user/operator could detect the problem:
By starting traffic mirroringand dowloading the PCAP file with test scenario to file transfer.
Description of the correction:
Increased the time limit for Token. libzip function delay is due to the busy RAM access.
Effects on operator:
Operator would get Token Invalid issue.
Corrected Fault Reports:
NA05882048
LTE1460 doesn't work correctly in FL15A
Modified components:
Component
Version
*Net element
knights_pkodihal
FTM_R3_FL
_na05882048_to
15A_TL15A_
ken_invalid_fl15a W16_MP1_4
_mp1.67.00.01
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
FL15A 1.1 - Change Note Forms - Page 51/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05882048)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 52/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00273
Title:
[FL15A_enodeB] “Reduced LTE_5662a IP incoming VLAN traffic volume (DL) (Mbyte) after
upgrade from RL70 to FL15A
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
IPPM interface counter not incremented as expected with IPSEC.
How end user/operator could detect the problem:
Enable IPSEC and send any kind of packet in DL and check the IPPM in BTSSM. It will not
show the correct value.
Description of the fault:
The check in FP while incrementing this counter was wrong. IP_forwarder module updated
the cache for ESP packet but in cache handler the counter increment function was called
!ESP packet.
Faulty component and version:
TRSW, FL15A.
Faulty component first delivered in(e.g. release, CD):
FL15A
Workaround:
No workaround
Description of the correction:
Check has been modified to increment when packet is ESP.
Corrected Fault Reports:
NA05897717
[FL15A_enodeB] “Reduced LTE_5662a IP incoming VLAN traffic volume (DL) (Mbyte) after
upgrade from RL70 to FL15A
Modified components:
Component
Version
FL15A 1.1 - Change Note Forms - Page 53/66
Version 1.0
Confidential
*Net element
*SW-type
*Unit
© Nokia Solutions and Networks 2016
avengers_na058
97717.-
FTM_R3_FL
15A_TL15A_
W16_MP1_4
68.00
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05897717)
Operation & Maintenance
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 54/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00274
Title:
Site with FL15 0.1 doesn't recognize RET modules after upgrade from FL7.0
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Description of the fault:
When filling internal parameters map wrong data was taken - code wasn't aware of logical
antennaLines which caused taking their names as real ones.
Workaround:
As this was occasional issue - couple of reboots should do the job.
Description of the correction:
Find antennaName in TX resource first. If not found then search for RX resource. As there are
only RX logical resources this will resolve problem.
Effects on operator:
MHA/RET were not detected as parameters were sent on wrong antennaLine.
Corrected Fault Reports:
NA05905464
Site with FL15 0.1 doesn't recognize RET modules after upgrade from FL7.0
(LN7.0_ENB_1407_572_04). In this case rollback solves problem
PR140569
Site with FL15 0.1 doesn't recognize RET modules after upgrade from FL7.0
Modified components:
Component
MOAM.-
Version
53209
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
FL15A 1.1 - Change Note Forms - Page 55/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05905464, PR140569)
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 56/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00277
Title:
eNB is not sending alarm time with proper resolution (milliseconds are not included in alarm
times received by OMS)
Valid for Product(s):
Flexi LTE Base Station
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
If same alarm toggles status in eNB within same second, then NetAct is unable to differentiate
between the alarm status.
As eNB is sending alarms with time stamp of accuracy of seconds, while NetAct has an
accuracy of accepting events with timestamp of millisecond accuracy.
Description of the correction:
AlarmObservation message sent by BTSOM does not contain the millisecond information.
Workaround:
No workaround
Description of the correction:
Add the milliseconds to the alarm time
Description of the correction:
Millisecond information added.
Effects on operator:
Alarm toggling events within same second for the same alarm from the same BTS can cause
alarm monitoring issues on NetAct, but the occurrence rate is very low.
Multiple unique alarms raised or cancelled within same second does not have any issues.
Corrected Fault Reports:
NA05878937
eNB is not sending alarm time with proper resolution (milliseconds are not included in alarm
times received by OMS)
Modified components:
Component
Version
FL15A 1.1 - Change Note Forms - Page 57/66
Version 1.0
Confidential
*Net element
*SW-type
*Unit
© Nokia Solutions and Networks 2016
sysadapter.common.Fareco.trsmanger.-
28527
14290
-
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05878937)
Testing Instructions for the change
Pre-requirements:
eNB connected to LTE OMS
Test execution:
Raise and cancel several alarms(exactly the same) within 1 seconds
Expected results:
All alarms will be visible in history of fault management inside OMS
Unexpected results:
Some of alarms will be missed in alarm history of fault management inside OMS
FL15A 1.1 - Change Note Forms - Page 58/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00278
Title:
Some parameter's validation mechanism is missed during CM plan activation in FL15a.
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
Some parameter's validation mechanism is missed during CM plan activation. After CM plan
execution completed with wrong parameters, sites may be out of service. If the same
parameter will be changed directly by BTS Site Manager, BTS Site Manager will check the
parameter and give error information.
How end user/operator could detect the problem:
The prevalidation result is different on NetAct prevalidation and BTS Site Manager validation.
The empty list should be regarded as not exist so mandatory list missing prevalidation can be
shown, but in NetAct prevalidation mode, this will not be shown.
Description of the fault:
The empty list shoud be regarded as not exist so mandatory list missing prevalidation can be
shown, but in netact prevalidation mode, this will not show.
Workaround:
Manual delete the empty list, the prevalition will work well.
Description of the correction:
Remove all empty list when do prevalidation.
Effects on operator:
The prevalidation result is different on NetAct prevalidation and Site Element Manager
validation. CM Validation passed without error if the parameter values are missing.
Corrected Fault Reports:
NA05876904
CM Validation passed without error if the parameter values are missing
NA05877216
Some parameter's validation mechanism is missed during CM plan activation in FL15a.
Modified components:
FL15A 1.1 - Change Note Forms - Page 59/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Component
sitemanager.-
Version
63044
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05876904, NA05877216)
Operation & Maintenance
The netact prevalidation will work well when scf contain empty list.
Testing Instructions for the change
Pre-requirements:
N/A
Test execution:
The correction has been tested internally and proved to be fully functional
Expected results:
N/A
Unexpected results:
N/A
FL15A 1.1 - Change Note Forms - Page 60/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00279
Title:
BTS Site Manager Login fail
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
After upgrade eNBs have not stable IP connectivity.
How end user/operator could detect the problem:
LOS alarm will be raised
Description of the fault:
Due to fluctuations of link, LOS alarm is raised.
Related feature / functionality:
Legacy
Workaround:
No workaround
Corrected Fault Reports:
NA05902286
Unable to access eNodeb with BTS Manager
Modified components:
Component
Version
*Net element
scrum_titans_lam FTM_R3_FL
dash_pr126791_f 15A_TL15A_
l15a_mp1.W16_MP1_4
59.00.01
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
FL15A 1.1 - Change Note Forms - Page 61/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05902286)
Testing Instructions for the change
Pre-requirements:
eNB is on air
Test execution:
Upgrade SW
Expected results:
Connectivity towards OMS remains stable.
Unexpected results:
Connection towards OMS not stable, logs shows TCP socket error
FL15A 1.1 - Change Note Forms - Page 62/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00280
Title:
FL16 PCD1.4 MHA detection issue
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
MHA is not detected after disable then enable AISG and DC voltage, need a site reset to
detect MHA.
How end user/operator could detect the problem:
MHA is not detected.
Dependency on configuration:
FXEA
Description of the fault:
Wrong antenna used for SetDc on FXEA
Workaround:
No workaround
Description of the correction:
Disable diversity antennas by default
Effects on operator:
Undetected MHA, no/limited connectivity
Corrected Fault Reports:
NA05893857
FL16 PCD1.4 MHA detection issue
Modified components:
Component
MOAM.-
Version
50937
*Net element
*SW-type
*Unit
Change effects:
FL15A 1.1 - Change Note Forms - Page 63/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05893857)
Testing Instructions for the change
Pre-requirements:
Change configuration of MHA related
eNB has MHA commissioned
Test execution:
Disable then enable AISG and DC voltage
Expected results:
MHA is detected successfully
Unexpected results:
MHA is not detected after disable then enable AISG and DC voltage, need a site reset to
detect MHA.
FL15A 1.1 - Change Note Forms - Page 64/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
CN-id: FL15A_00281
Title:
after upgrade to RL70 MP2.2 at FHEA 2x RET shows "antenna line device failure 0010―,
after fallback to RL60 RET is working, again RL70 again RET failure, Fallback RL60 RET
working, again RL70 upgrade and now RET are there also working
Valid for Product(s):
Flexi LTE Base Station
References:
Reason for the Change Note:
Summary of the original problem:
RUMAG searches antennaName to which he should send message based on info written to
RX resources, if not found then on TX resources. On FHEA there is a logical only resource
(RX only) that were taken in calculations, so it is antennaName was taken (it was wrong, such
antennaName do not exist physically so it cannot be sent messages on such antenna.
How end user/operator could detect the problem:
Antenna line device failure 0010 in SiteManager
Description of the fault:
SMOD picks wrong antennaLine
Dependency on configuration:
Issue occurs when RU got more than 1 RX resource connected to single antentennaLine,
FHEA unit for example
Workaround:
As issue is occasional restart BTS till success
Description of the correction (incl. risk analysis):
Correction changes order of searching antennaName so it first search for TX resources (they
are never logical, only physical, real ones) then on RX resources. This prevented wrong
antennaName from being taken and provide that all messages were sent on correct
antennaLine
Corrected Fault Reports:
NA05890930
After upgrade to RL70 MP2.2 at FHEA 2x RET shows "antenna line device failure 0010―,
after fallback to RL60 RET is working, again RL70 again RET failure, Fallback RL60 RET
working, again RL70 upgrade and now RET are there also working
FL15A 1.1 - Change Note Forms - Page 65/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016
Modified components:
Component
MOAM.-
Version
51252
*Net element
*SW-type
*Unit
Change effects:
Effects on end-user
N/A
Effects on Operator
N/A
Other effects
N/A
New functionality
N/A
Customer Impact
Change 1: (NA05890930)
Testing Instructions for the change
Pre-requirements:
eNB onAir, RETs detected and working without any problems
Test execution:
Upgrade SW
Expected results:
eNB onAir, RETs detected and working without any problems
Unexpected results:
eNB onAir, not all RETs detected, for missing ones fault 0010 raised Antenna Line Device
failure
FL15A 1.1 - Change Note Forms - Page 66/66
Version 1.0
Confidential
© Nokia Solutions and Networks 2016