You are on page 1of 1054

Standard Delivery

Mobile Packet Core


Flexi NS
NS 16 SW
NS 16.5 MP1

Document name:
NS 16.5 MP1 Summary of corrections and enhancements
Flexi NS 16.5 MP1 List of Restrictions
NS 16.5 MP1 Change Notes Form
NS 16.5 MP1 Impact Document
NS 16.5 MP1 eSW content for release note

NS 16.5 MP1 Verification Report

NS 16.5 MP1 SW Update Paths

Contact
Contact your local Nokia support

Summary of changes:
02-Mar-2017 1.0 Approval date

NS 16.5 MP1 – Release Delivery Content - Page 1 / 1 © Nokia 2016


Version 1.0
Confidential
Summary of Corrections and
Enhancements
Id: NS 16.5 MP1
Product Family: Mobile Packet Core
Product: Flexi NS
Release: NS 16 SW

Approval date: 01-Mar-2017

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 1/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Table of Contents
1. Purpose .................................................................................................................................................16
2. Corrections ............................................................................................................................................16
2.1 NS16.50481 Incorrect NAS Sequence number ...............................................................................16
NA05916537 NS16 1.24-0 - Incorrect NAS Sequence number ......................................................16
2.2 NS16.50490 Incorrect destination port in PGW restart notification acknowledgement from MME to
SGW for EPC node restoration feature ............................................................................................17
NA05916632 Incorrect destination port in PGW restart notification acknowledgement from MME to
SGW for EPC node restoration feature ............................................................................................17
2.3 NS16.50508 Emergency call is dropped in case of E-UTRAN Restricted Access Type in IDR .....18
PR154615 Emergency call is dropped in case of E-UTRAN Restricted Access Type in IDR ........18
2.4 NS16.50544 ZKAI doesn't show any application IP for IPPU-17 ....................................................19
NA05931813 ZKAI doesn't show any application IP for IPPU-17 ...................................................19
2.5 NS16.50545 Console History showed by raw command was empty on ACPI4-B ..........................20
PR072068 #22622 / ACPI4-A Console History showed by raw command is empty on ACPI4-A/B
..........................................................................................................................................................20
2.6 NS16.50546 Console History showed by raw command was empty on ACPI4-A ..........................20
PR072068 #22622 / ACPI4-A Console History showed by raw command is empty on ACPI4-A/B
..........................................................................................................................................................20
2.7 NS16.50552 MME did not send Update Bearer Response during GW initiated QOS modification
for an unreachable subscriber ..........................................................................................................21
PR169125 For Unreachable Subscriber (PPF off) the QosUpdateProcedure Hangs in TRHandler
..........................................................................................................................................................21
2.8 NS16.50571 Collision handling between ongoing Insert Subscriber Data and incoming Delete
Subscriber Data was not done correctly ...........................................................................................22
NA05933794 MME didn't response DSR message lead to 4G APN replacement with dummy APN
failure ................................................................................................................................................22
2.9 NS16.50572 Cause code in the E-RAB Release Command is changed from "nas unspecified" to
"normal release" ...............................................................................................................................24
NA05947937 Changing cause code to unspecified to normal ........................................................24
2.10 NS16.50573 ULI was sent without TAI and ECGI in MBR when HO Notify was not received .......25
PR153977 ULI is sent without TAI and ECGI in MBR when HO Notify is not received ..................25
2.11 NS16.50574 When multiple Delete Subscriber Data Requests collided with Attach, E-RAB
Release Command with Ue AMBR=0 was sent to ENB...................................................................25
NA05936752 Increase in M51C017 PDN Connectivity Failed_SGW in MME after NS16.5 upgrade
..........................................................................................................................................................25
2.12 NS16.50575 3G users faced navigation problems ..........................................................................26
NA05950892 Flexi NS 15 / Claim 3G users for navigation problems and errors in the computer
logs / No alarms provided .................................................................................................................26
2.13 NS16.50576 Emergency Bearer not added in ICSR request in Gn Based TAU. ............................27
PR154033 Emergency Bearer not added in ICSR request in Gn Based TAU. ...............................27
2.14 NS16.50577 E-RAB set up failure with cause [RadioNetwork-cause=multiple-E-RAB-ID-
instances] ..........................................................................................................................................28
NA05939708 eRAB addition QCI1 SR degraded TT 11904843 - Multiple eRAB instances ...........28
2.15 NS16.50578 EPC initiated EPS Bearer Release requests for QCI1 & Volte drop call increased ...29
NA05957270 FNS : EPC initiated EPS Bearer Release requests for QCI1 & Volte drop call
increasing .........................................................................................................................................29
2.16 NS16.50579 During HSS initiated detach the Mme_internal_cause was missing from Traffica MM
reports ...............................................................................................................................................30
PR173241 HSS_initiated_detach missing Mme_internal_cause ...................................................30
2.17 NS16.50580 MME was sending invalid ENB-S1AP-ID in PDN Disconnect reject message ..........31
NA05937549 Incorrect ENB ID(s1ap.MME_UE_S1AP_ID) sent by MME ......................................31
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 2/231
D553209967 © Nokia 2016
Version 1.0
Confidential
2.18 NS16.50581 Wrong PGW selection by MME during PDN connectivity procedure .........................32
NA05940713 PGW Selection in MME .............................................................................................32
2.19 NS16.50582 GSP GRP3 hand hang up during periodic RAU .........................................................33
NA05960359 GSP hand hang up related to ticket NA05950892 ....................................................33
PR181522 GSP GRP3 hand hang up during periodic RAU ...........................................................33
2.20 NS16.50583 VoLTE basic call stopped working .............................................................................34
NA05911702 VoLTE basic call stopped working after upgrading FNS from NS3.0 to NS15 MP2 .34
2.21 NS16.50584 SHMU COMMUNICATION FAILURE alarms.............................................................35
PR178207 3481 SHMU COMMUNICATION FAILURE alarms.......................................................35
2.22 NS16.50585 Dedicated bearer activation failed after colliding with incoming X2 handover ...........36
NA05942939 (NS 16)Dedicated bearer activation failure due to collision between ongoing Bearer
Activation and incoming X2 Handover ..............................................................................................36
2.23 NS16.50586 MME did not respond to first create bearer request from SGW when handover from
WiFi to LTE was performed ..............................................................................................................37
NA05947056 MME does not respond to first create bearer request from SGW when handover
from WiFi to LTE ...............................................................................................................................37
2.24 NS16.50587 Some Logs were enabled in MMDU without checking the logging level ....................37
PR146847 Logging in SS_LNXmmeSubsHandler without checking trace log enable ....................37
2.25 NS16.50588 MME not responding to some CMAS Write-Replace-Warning Requests ..................38
NA05953177 MME not responding to some Write-Replace-Warning-Request sent by CMAS ......38
2.26 NS16.50589 Sv interface - MSC peer table timeout .......................................................................39
NA05939697 Sv interface - MSC peer table timeout ......................................................................39
2.27 NS16.50590 NAS sequence number (NAS#35) issue after s1 release by inactivity timer .............40
NA05956786 NAS sequence number (NAS#35) issue after s1 release by inactivity timer ............40
2.28 NS16.50591 MML command error ..................................................................................................41
PR172065 NS17_NSHW16_8hrun_MML_command_error ............................................................41
2.29 NS16.50592 MME was sending unauthenticatedIMSI flag as true in Indication Flags IE in Create
Session Request for subscriber attached with IMEI .........................................................................42
PR156436 NS17-CI27:unauthenticatedIMSI indication flag is set to true in CSR with Prose PR file
is on ..................................................................................................................................................42
2.30 NS16.50593 MME did not trigger PDN re-establishment after inter MME TAU with SGW change 42
NA05938360 (Flexi NS)PDN re-establish failed ..............................................................................42
2.31 NS16.50594 LG K7 MPCS handset models were causing EPC initiated drop loops for IMS default
bearer................................................................................................................................................43
NA05955170 LG K7 MPCS handset models causing EPC initiated drop loops for IMS default
bearer................................................................................................................................................43
2.32 NS16.50595 3689 alarm was not cancelled in MMDU after recovery action .................................44
PR171036 3689 alarm not cancelled if DBHandler restarts ............................................................44
2.33 NS16.50596 MME sends wrong APN selection mode value for Emergency PDN in CSR during
Intra-mme S1/X2 HO with SGW change ..........................................................................................45
PR151039 Incorrect Selection mode Value for Emergency PDN in CSR during Intramme S1/X2
HO with SGW change .......................................................................................................................45
2.34 NS16.50597 ( Flexi NS-MME ) VoLTE video cross vendor switching failure ..................................46
NA05918207 ( Flexi NS-MME) VoLTE video cross vendor switching failure ..................................46
2.35 NS16.50598 MME locate failure accidentally ..................................................................................47
NA05927910 'VoLTE 100day campaign'(FLexi NS MME NS316)MME .........................................47
2.36 NS16.50599 Relocation failure due to additional RAB added .........................................................48
NA05917971 Relocation failure due to additional RAB added ........................................................48
2.37 NS16.50600 KPI drop after both MMDUs of a pair were put to SE-NH state .................................49
NA05906039 LASGSN14 - Database error in GSBASE .................................................................49
2.38 NS16.50601 Collision due to PDN Connectivity ..............................................................................50
NA05919202 Collision due to PDN Connectivity .............................................................................50
2.39 NS16.50602 ( Flexi NS MME )TAL (TaiList) and TAI (LastVisitedTAI) information is incorrect in
LIC event log .....................................................................................................................................51
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 3/231
D553209967 © Nokia 2016
Version 1.0
Confidential
NA05918928 ( Flexi NS MME )TAL (TaiList) and TAI (LastVisitedTAI) information is incorrect in
LIC event log .....................................................................................................................................51
2.40 NS16.50603 Internal UDP packet towards CPPU sent from IPDU's external interface with
Gn/S11/S10 IP ..................................................................................................................................52
NA05926379 Internal UDP packet sent on external interface with Gn/S11/S10 IP ........................52
2.41 NS16.50604 MME performs unnecessary IMEI check in IS TAU procedure during '4g Attach - IS
RAU - IS TAU' ...................................................................................................................................53
NA05929166 IMEI parameters in MME S13 Diameter ....................................................................53
2.42 NS16.50605 The M51 measurement includes the TAI-0 and TAI-65535 while the enodeb does not
have these TAI values ......................................................................................................................54
NA05938817 The measurement include the TAI-0 and TAI--65535 items even the enodeb do not
have these TAI ..................................................................................................................................54
2.43 NS16.50606 Alarm 2101 MME UNIT FAILURE due to memory leak in S1Handler .......................55
NA05944741 S1 handler memory leak caused OoM CPPU restart ................................................55
2.44 NS16.50607 Roaming partner has ESM failures ............................................................................56
NA05962653 Roaming partner has ESM failures ...........................................................................56
2.45 NS16.50608 For Emergency PDN Connectivity Failures, the internal/external cause code sets are
incorrect ............................................................................................................................................57
NA05975155 cause code is inconsistent between in the CPPU and the corresponding traffica
report.................................................................................................................................................57
NA05975937 For Emergency PDN Connectivity Failures, the internal/external cause code set are
incorrect ............................................................................................................................................57
2.46 NS16.50609 Dns Resolving Unsuccessful alarm(0095) flooding and map clearing .......................58
PR153396 Dns Resolving Unsuccessful alarm(0095) flooding and map clearing ..........................58
2.47 NS16.50610 IESIEU: Create logical file for upglog failed ...............................................................59
PR161042 IESIEU: Create logical file for upglog failed ..................................................................59
2.48 NS16.50611 The IPMC version is not correct after updating the eSW. ..........................................60
PR166698 The IPMC version is not correct after update the eSW of ACPI4- A/B blade. ..............60
2.49 NS16.50612 CDR Data volume mismatch between CDRs reported from SGSN & GGSN ............61
NA05916304 SGSN Volume mismatch in S CDR & SA CDR in all EAST SGSN ..........................61
2.50 NS16.50613 LNXAA0G2 IFMonitor Improve the TRepeat timer implementation ...........................62
NA05922776 (Flexi_NS MME NS16MP0.1)MME appear a large number of 2101 "MME UNIT
FAILURE" alarms after upgrade to NS16MP0.1 ..............................................................................62
PR177848 LNXAA0G2 IFMonitor Improve the TRepeat timer implementation ..............................62
2.51 NS16.50614 Wrong APN was sent by MME in Create Session Request message to GW ...........63
NA05956048 (Flexi NS-MME NS16.5)MME was wrong to create session by apn "CMIOT" ..........63
NA05958335 MME override APN wrongly ......................................................................................63
2.52 NS16.50615 Empty ULI ...................................................................................................................64
NA05932852 Empty ULI ..................................................................................................................64
2.53 NS16.50616 When Dual Stack was activated on HLR, APN override stopped working .................64
NA05943488 When Dual Stack was activated on HLR, APN override stopped working ................64
2.54 NS16.50617 MME was not responding to the Downlink Data Notification message from the SGW
..........................................................................................................................................................66
NA05942190 MME is not responding to the Downlink Data Notification message from the SGW .66
2.55 NS16.50618 TAU Reject with CC 0xA (Implicit Detach) after FLEXI NS upgrade..........................67
NA05947959 TAU Reject after upgrade from NS40 0.2 to NS16 MP0.1 WU2 ..............................67
2.56 NS16.50619 Increase in counter EPS_ABNORMAL_PDN_DROPPED even though there are no
PDN connectivity reject due to Abnormal UE ...................................................................................68
NA05941183 Increase in EPS_ABNORMAL_PDN_DROPPED counter after NS16.5 upgrade ....68
2.57 NS16.50620 9047 alarms in NetAct after activating CNUM in NEs ................................................69
NA05958784 WROSS: 9047 Alarms after activating CNUM in 10 NEs ..........................................69
2.58 NS16.50621 CSFB Success Rate is degraded ...............................................................................69
NA05963570 CSFB Success Rate is degraded ..............................................................................69

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 4/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.59 NS16.50622 Buffer overflows and error logs were printed when many ftp clients send many files
simultaneously ..................................................................................................................................70
PR138589 [NS16.5] e-logs in FSRVER PRB during logs written ...................................................70
PR148259 Md1.6 GCD 1.7 (MMXX1700) - Error messages from 063D under TCP robustness test
on port 21 ..........................................................................................................................................70
2.60 NS16.50623 "ST0: physical_file_inquiry_io error" written in working OMU's computer logs ..........71
PR157740 "ST0: physical_file_inquiry_io error" written in working OMU's computer logs .............71
2.61 NS16.50624 MME could not deal with collision between AKA with Ue context release procedure 72
PR163347 MME NS16(N6_1_24_0) MME seem cannot deal with collision between AKA with Ue
context release procedure ................................................................................................................72
2.62 NS16.50625 S1 Handover ping-pong with SGW relocation does not work ....................................73
PR171542 NS17 - Pingpong S1HO with SGW relocation does not work .......................................73
2.63 NS16.50626 Tracking Area Update was not completed after S10 HandOver with SGW relocation
..........................................................................................................................................................74
PR178393 TAU after S10 Handover is not completed when SGW Reselection & Blacklisting are
enabled .............................................................................................................................................74
2.64 NS16.50627 Wrong PGW selection by MME during PDN connectivity procedure when
FC085_003402 feature was enabled ...............................................................................................75
NA05957933 Wrong PGW Used in CSR for Standalone PDN Connectivity ...................................75
2.65 NS16.50628 Subs from 3G to 4G, after inter internode TAU to new MME, stay registered to both
source and target MME ....................................................................................................................76
NA05915374 MME Offloading Very Slow NS16 0.1 .......................................................................76
2.66 NS16.50629 The commands "cli showinternal -dialbs" in the IPDU service terminal and "cli
showinternal -diah" in MMDU service terminal do not work, after upgrading to NS15 .....................77
NA05946355 The command "cli showinternal -dialbs" in the IPDU service terminal doesn't work in
2 MMEs after upgrade to NS15. .......................................................................................................77
2.67 NS16.50630 The success rate of CSFB dropped suddenly after upgrade to NS16.5 ....................78
NA05936196 (Flexi NS-MME NS16.5)The success rate of CSFB dropped suddenly after upgrade
to NS16.5 ..........................................................................................................................................78
NA05936445 'PILOT'(Flexi NS16.5)CSFB and SMS paging success rate decreased. ..................78
2.68 NS16.50631 VoLTE Setup failure due to Multiple QCI-1 ERAB setup ...........................................79
NA05921832 VoLTE Setup failure due to Multiple QCI-1 ERAB setup ..........................................79
2.69 NS16.50632 VOLTE Default bearer was forwarded to UTRAN and establishment failed ..............80
NA05953814 Continuation of case ID #NA05914101 - Problems after PS HO / RAU in 3G ..........80
2.70 NS16.50633 One subscriber had two copies of data ......................................................................81
NA05960561 (Flexi MME NS16.5)CSFB MT failed because of SGS paging reject with cause "IMSI
Detached for EPS Service" ...............................................................................................................81
2.71 NS16.50634 MME failed to handle inter-MME S1 HO collision with incoming TAU .......................81
NA05912672 (VoLTE 100day campaign)(Flexi NS)MME failed to handle inter-MME S1 HO
collision with incoming TAU ..............................................................................................................81
2.72 NS16.50635 P-TMSI signature mismatch (206) cause code in SGSN Context Response caused
RAU failure .......................................................................................................................................83
NA05970344 inter system RAU ( 4F) Cause: P-TMSI signature mismatch (206) .........................83
PR192070 NS15MP3: No response to sgsn-ctx-request. ...............................................................83
2.73 NS16.50636 Order of PDP context QoS profiles changed in subscription data stored in SGSN
after "HLR-initiated QoS modification" procedure ............................................................................84
PR150366 Different order of pdp contexts in 'reg_get_subscription_res_s' message to SGSN ....84
2.74 NS16.50637 MME detach type is incorrect in LIC event log ...........................................................85
NA05919015 (Flexi NS-SGSN/MME NS15) MME detach type is incorrect in LIC event log ..........85
2.75 NS16.50638 MME does not send MM report to Traffica element for VLR offloading .....................86
PR177459 NS17 compatibility - MME seems not sending report at Traffica for VLR offloading ....86
2.76 NS16.50639 MME was faulty sending "Combined TA/LA updated " value in TAU Accept even if
the Network access mode was sent as Packet Only ........................................................................87

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 5/231


D553209967 © Nokia 2016
Version 1.0
Confidential
PR167485 NS17 Feature - "Combined TA/LA updated" EPS value is coming inTAU accept
message even if the Network access mode is sent as Packet Only ................................................87
2.77 NS16.50640 MME sends two Traffica SM Reports for one dedicated bearer establishment in case
of collision. ........................................................................................................................................88
PR154601 The MME sends two Traffica SM Reports for one dedicated bearer establishment .....88
2.78 NS16.50641 MSISDN missing in Create Session Request after Ping-Pong inter-MME mobility with
Huawei MME ....................................................................................................................................89
NA05983138 (Flexi NS MME NS16.5)MSISDN missed in CSR .....................................................89
2.79 NS16.50642 During Inter system TAU from 3G to 4G, MME doesn’t send response to GW initiated
Update Bearer Request ....................................................................................................................89
NA05957300 Degradation in PDP context act SR due to cause 0x5F ...........................................89
2.80 NS16.50643 Wrong PGW IP was selected during PDN connectivity procedure when the APN was
the same as in Attach procedure ......................................................................................................91
NA05945924 Wrong pgw ip selected for the scenario - attach/post PDN connect procedure with
same apn. .........................................................................................................................................91
2.81 NS16.50644 China LI MME X2 interface connection status became NOK after upgrade ..............92
NA05940511 (NS16.5)China LI MME X2 interface became NOK after upgraded to the NS16.5...92
2.82 NS16.50645 MME caused hung bearer due to PGW initiated DBR (delete bearer request) for
default bearer and DDN (downlink data notification) collision ..........................................................93
NA05962662 MME causing hung bearer due to DBR and DDN collision .......................................93
2.83 NS16.50646 Incorrect SGW blacklist cause code ...........................................................................94
PR177156 Incorrect SGW blacklist cause code occurred...............................................................94
2.84 NS16.50647 3G Data KPIs Decrease and IPPU AVE CPU Load Unbalancing..............................95
PR163043 3G Data KPIs Decrease and IPPU AVE CPU Load Unbalancing.................................95
2.85 NS16.50648 SGS Paging not answered .........................................................................................95
NA05932745 NS16.5 Pilot, Follow up NA05921818 : SGS Paging not answered .........................95
2.86 NS16.50649 faulty data present in platform measurement .............................................................96
NA05931196 (MME NS16MP1)faulty data present in platform measurement................................96
2.87 NS16.50650 Subscriber detached due to irregular idle timer reset ................................................97
NA05870692 Irregular idle timer detach ..........................................................................................97
2.88 NS16.50651 Ongoing PDN gateway dedicated Bearer Creation fails when collided with incoming
X2 handover with Tracking Area Update .........................................................................................98
NA05918571 CBR-X2HO-TAU collision ..........................................................................................98
NA05918637 Collision with dedicated Bearer and X2 handover with TAU .....................................98
2.89 NS16.50652 MME was unable to process Update Bearer Request without QoS information, sent
as part of MME requested QoS Modification ....................................................................................99
NA05928337 Flexi-NS-16.5_Pilot:NS 16.5 1.17-2: HSS Initiated Bearer Modification eNB Error
Failure Ratio is Relatively High .........................................................................................................99
2.90 NS16.50653 An exception of OMOLIB module due to large allocation size or inadequate free size
........................................................................................................................................................100
NA05947718 Traffic dip observing in 7 BSCs of SGSN ................................................................100
2.91 NS16.50654 Services were denied for Subscribers due to invalid UEAMBR value '0' sent by MME
........................................................................................................................................................101
NA05938815 (Flexi NS-MME NS16MP0.1)Increased lots of new subscribers UEMBR=0...........101
2.92 NS16.50655 Collision between PGW initiated bearer modification and bearer deactivation
procedures - MME sends wrong NAS sequence number in Deactivate EPS bearer context request.
........................................................................................................................................................102
NA05943975 Issue 1 :: UBR DBR X2 CBR S1 release collision ..................................................102
2.93 NS16.50656 IPDU diagnostic systematically fails (UNIT NOT OK) when PRFILE 54:13
DOUBLE_ETH_FAILURE is set to 1 ..............................................................................................103
NA05958644 IPDU diagnostic fails when PRFILE 54:13 DOUBLE_ETH_FAILURE is set to 1 ..103
NA05966494 IPDU diagnostic systematically fails (UNIT NOT OK) when PRFILE 54:13
DOUBLE_ETH_FAILURE is set to 1 ..............................................................................................103

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 6/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.94 NS16.50657 Collision between Ongoing Default Bearer Creation and Incoming X2 Handover
Request is causing the Default Bearer to fail .................................................................................104
NA05962898 Collision between Ongoing Default Bearer Creation and Incoming X2 Handover
Request is causing the Default Bearer to fail .................................................................................104
2.95 NS16.50658 IPDU restarts and does not recover on MME...........................................................105
NA05963048 IPDU restarted and dint recovered on MME ...........................................................105
2.96 NS16.50659 S11 "Delete Bearer Command" message contains the wrong TAI ..........................106
NA05962025 S11 "Delete Bearer Command" message contains the wrong TAI .........................106
NA05987299 Mixup of TAI and GCI MNC in Change notification req on S11. .............................106
2.97 NS16.50660 S-CDR with zero PLMNID is getting generated randomly .......................................107
NA05941551 S CDR with Blank PLMNID is getting generated randomly ...................................107
2.98 NS16.50661 MML Command ZMMF fails after being executed many times ................................108
NA05973926 ERROR IN FETCHING SUB COUNT FROM ROB SGSN6 ...................................108
2.99 NS16.50662 After MMDU restart process restarted every 5 minutes ...........................................109
PR125648 [NS16] - DBHandler reports 1007 RESTARTED PROGRAM BLOCK alarm every 5
minutes ...........................................................................................................................................109
2.100 NS16.50663 Create Bearer Request and S1 release collision caused NAS sequence
issue 110
NA05943886 Issue 2 :: DBR and S1 release collision causing NAS sequence issue ..................110
2.101 NS16.50665 ID (GUTI, TEID) leakage during multiple Initial Context Setup Failure .......111
NA05961400 EME Follow up case - NA05958290 - FNS (NS15 MP2) The subscribers cannot
connect 4G nor 3G .........................................................................................................................111
2.102 NS16.50666 4G Attach/Intersystem TAU is not updating MSS/VLR via SGs ..................112
NA05972640 4G Attach/Intersystem TAU is not updating MSS/VLR via SGs ..............................112
2.103 NS16.50667 MME was including inactive bearers in ICSR during Inter PLMN TAU .......113
PR150991 MME is including inactive bearers in ICSR during Inter PLMN TAU ...........................113
2.104 NS16.50668 Data from FlexiNS to traffica shows faulty Neg QCI =1 when PDN
Connection is rejected due to "Invalid APN" ...................................................................................114
NA05913149 Data from FlexiNS to traffica shows faulty Neg QCI =1 in NS 16 Mp1. ..................114
2.105 NS16.50669 Illegal charging ID caused raising of 3464 alarm ........................................115
NA05955826 3464 CHG INTERFACE DATA PROBLEM .............................................................115
2.106 NS16.50670 Serving PLMN ID was incorrect in Create Session Request during Inter
PLMN intra MME X2 HO.................................................................................................................116
PR156450 Serving PLMNID is incorrect in CSR during Inter PLMN intra MME X2 HO ...............116
2.107 NS16.50671 During emergency call UICCless IMEI was missing from GMLC Location-
Report-Request (LRR) ....................................................................................................................117
PR163268 emergency call UICC missing IMEI on GMLC LRR ....................................................117
2.108 NS16.50672 Delay in DB process replica after MMDU unit restarted by reset button .....118
PR131969 [NS 16.5] Delay in Secondary DB startup after MMDU unit restart by reset button ....118
2.109 NS16.50673 CS PLMN is not included in PLMN list after second Intra MME TAU when in
the First TAU the TAU Complete is received without LAI IE ..........................................................118
PR170076 FC085_3653: CS PLMN is not included in PLMN list after second Intra MME TAU .118
2.110 NS16.50674 ETHLIBGIX component causes unit startup failure .....................................119
PR156729 ETHLIBGIX causes unit startup failure ........................................................................119
2.111 NS16.50675 Partial handover from UTRAN to LTE failed ...............................................120
PR177672 Partial handover from UTRAN to LTE fails ..................................................................120
2.112 NS16.50676 Offline CDR is not transferred .....................................................................121
NA05917044 Offline CDR is not transferred .................................................................................121
2.113 NS16.50677 Deactivate dedicate bearer collision with incoming ESRVCC handover.....122
NA05926367 Deactivate dedicate bearer collision with incoming ESRVCC handover ...............122
2.114 NS16.50678 MME doesn't send Location update to MSC after S1 handover procedure.
123
NA05936054 (Flexi NS-MME NS16.5)cs service notification with imsi after upgrade to NS16.5 .123
2.115 NS16.50679 TAU SR Degradation ...................................................................................124
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 7/231
D553209967 © Nokia 2016
Version 1.0
Confidential
NA05942790 TAU SR Degradation ...............................................................................................124
2.116 NS16.50680 Incorrect PTAU Handling After Roaming Control Feature Activation ..........124
NA05950344 N16.5 PILOT: Incorrect PTAU Handling After Roaming Control Feature Activation 124
2.117 NS16.50681 MME cannot deal with ULA with unknown EPS subscription in TAU
procedure ........................................................................................................................................125
PR163333 MME NS16(N6_1_24_0) MME cannot deal with ULA with unknown EPS subscription
in TAU procedure of 3G HO to 4G .................................................................................................125
2.118 NS16.50682 Update of the java jre ..................................................................................126
NA05959530 MME CPPU Restart .................................................................................................126
2.119 NS16.50683 IPDU switchover caused by LNX92D (S1LBS) crash .................................127
NA05965981 (Flexi NS MME NS17)IPDU switchover in NS16 and NS17 ...................................127
2.120 NS16.50684 Inconsistent ZD8F MML command output ..................................................128
PR161011 Inconsistent ZD8F MML command output ..................................................................128
2.121 NS16.50685 SGW relocation was not working during HO if TAI list prfile was disabled but
TAI list was configured ....................................................................................................................129
PR171522 NS17 - SGW relocation seems not working during ping pong HO if tai list prfile is
disabled but tai list configured ........................................................................................................129
2.122 NS16.50686 Traffic is not recovered after kernel panic in active IPDU followed by IPDU
switchover. ......................................................................................................................................130
PR176767 trHandler does not recover traffic after IPDU kernel panic ..........................................130
2.123 NS16.50687 In the output of ZBJB:EBSM MML command , if the eMBMS Service ID
contains 0, 0 is not displayed .........................................................................................................131
PR166638 eMBMS service ID containing 0, 0 is not displayed ...................................................131
2.124 NS16.50688 PersistenceException: Missing identifier. (Cause:-) in MMDU SubsHandler
on IPDU WO GRP2 blade removal ................................................................................................131
PR178222 PersistenceException: Missing identifier. (Cause:-) in MMDU SubsHandler on IPDU
WO GRP2 blade removal ...............................................................................................................131
2.125 NS16.50689 Check for active RABs failed and SCCP was released without IU-release.
132
PR182370 Check active RABs fails , SCCP release , missing IU-release. ..................................132
2.126 NS16.50690 Traffic drop when an MMDU unit is unreachable (failure, restart, TE state)
133
PR190146 Composite Persistence not enabled during pair MMDU restart ..................................133
2.127 NS16.50691 MME did not send SGsAP messages to VLR despite the fact that the UE
cannot be paged .............................................................................................................................134
PR176268 NS 15 - MME does not send SGsAP messages to VLR despite the fact that the UE
cannot be paged .............................................................................................................................134
2.128 NS16.50692 MME NS16(N6_1_24_0) MME seem cannot deal with collision between
detach with create bearer procedure ..............................................................................................135
PR166064 MME NS16(N6_1_24_0) MME seem cannot deal with collision between detach with
create bearer procedure .................................................................................................................135
2.129 NS16.50693 MME downgration of MBR during dedicated bearer creation .....................136
PR160188 NS17 Feature - FC085_3653_us1_CR1771_MME downgrades the MBR .................136
2.130 NS16.50694 Deactivate non-emergency bearers for a roaming LBO subscriber in TAU
when "VPLMN-Dynamic-Address-Allowed" is false in subscription data .......................................137
PR151166 During InterMME HO roaming subscriber LBO, partial TAU bearers should be deleted
other than emergency, when VPLMN dynamic is not allowed in ULA ...........................................137
2.131 NS16.50695 Reason for GBU unit switchover in BIH SGSN-6 after SW upgrade...........138
NA05945528 Reason for GBU unit switchover in BIH SGSN-6 after NS15 upgradation .............138
2.132 NS16.50696 Fluctuation on all BSCs GB Links................................................................139
NA05760300 Fluctuation on all BSCs GB Links ...........................................................................139
2.133 NS16.50697 Mishandling of ongoing attach procedure - incoming detach procedure
collision 140
NA05979608 (Flexi NS MME 16.5)attach request and detach request collision handling ............140
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 8/231
D553209967 © Nokia 2016
Version 1.0
Confidential
2.134 NS16.50698 Inter PLMN TAU in Create session request, ServingNetworkValue PLMN
was not changed to new PLMN ......................................................................................................141
PR148635 NS17: servingNetworkValue is not changed during Inter PLMN TAU in Create session
request ............................................................................................................................................141
2.135 NS16.50699 Cause value "unspecified" in UEContextReleaseCommand for SRVCC
cancellation .....................................................................................................................................142
NA05930961 When SRVCC Cancel occurs what is correct cause in UEContextRelease for MME
to send ............................................................................................................................................142
2.136 NS16.50700 Improper time was set when adjusting both time and summer time ON in one
ZDCT MML command ....................................................................................................................143
NA05906119 MSS -P : MML ZDCT to make SUMMER TIME ON behaved differently for
MSS/MGW/CDS .............................................................................................................................143
2.137 NS16.50701 Multiple MMEs had alarming issues ............................................................144
NA05909052 Multiple MMEs having Alarming issues - NS16 (previous case, NA05880373)......144
2.138 NS16.50702 Collision between Service Request Procedure and S1 Release causes OLC
drop due to CPPU holding ticket for S1 Release Procedure ..........................................................145
PR165423 CPPU ticket is held at least 500ms in case ongoing Service Request colliding with
incoming eNB initiated S1 Release ................................................................................................145
2.139 NS16.50703 Support of EPS info in ULR. ........................................................................146
PR159345 Support of EPS info in ULR. ........................................................................................146
2.140 NS16.50704 OpenSSH ≤ 7.3 - Denial of Service Vulnerability - CVE-2016-8858 ...........147
PR193204 OpenSSH ≤ 7.3 - Denial of Service Vulnerability - CVE-2016-8858 ...........................147
2.141 NS16.50705 The MME send the wrong S1U ip address to enodeb.................................147
NA05975474 (Flexi NS-SGSN/MME NS16.5)The MME send the wrong S1U ip address to enodeb
........................................................................................................................................................147
2.142 NS16.50706 Intra MME TAU related counters (M50C038 and M50C044) increased during
Inter System TAU. ..........................................................................................................................149
NA05977910 Need to know how the counter M50C044 works and updated................................149
2.143 NS16.50707 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718 .........150
PR158441 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718 .........................150
2.144 NS16.50708 Commissioning is failing in ZQRN:GBU command in NS15 MP2 after N5
1.20-0 frozen SW build ...................................................................................................................151
PR153584 Commissioning is failing in ZQRN:GBU command in NS15 MP2 after N5 1.20-0 frozen
SW build..........................................................................................................................................151
2.145 NS16.50709 Security Test - TCP SYN flood attack against OMU Telnet port - UNIT restart
152
PR172955 Security Test - TCP SYN flood attack against OMU Telnet port - UNIT restart ..........152
2.146 NS16.50710 MME generated APN NI as LBO mode for HRT PDNs in Context Response
and Create Session Request message when emergence PDN was active ...................................153
PR159734 APNOI part of Access point name IE for HRT Subscriber is not filled properly during
TAU with SGW relocation ...............................................................................................................153
PR159847 NS17 Provocative - Roaming parameters are not transferred correctly in Context
Response during Inter MME TAU when emergency PDN is established. .....................................153
2.147 NS16.50711 Delete Session Request did not had the proper value in the field of Tunnel
Endpoint Id ......................................................................................................................................154
PR160109 Delete_session_failure_prfile_2241_ARP for non emergency services ......................154
2.148 NS16.50712 Decrease of Inter-PAPU RAU Success Ratio after RNC rehoming ............155
NA05943664 Big decrease of Inter-PAPU RAU Success Ratio after RNC rehoming ..................155
2.149 NS16.50713 ZD8I output for AHUB3-A IPMC was incorrect ............................................157
PR174015 ZD8I output for AHUB3-A IPMC incorrect ...................................................................157
2.150 NS16.50714 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718 .........157
PR158892 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718 .........................157
2.151 NS16.50715 MME does not handle correctly the collision between Intersystem TAU
procedure - Update Bearer Request procedure .............................................................................158
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 9/231
D553209967 © Nokia 2016
Version 1.0
Confidential
PR153492 MME does not handle correctly the collision between Intersystem TAU procedure -
Update Bearer Request procedure .................................................................................................158
NA05932798 50 % decrease in bearer modification SR ..............................................................158
NA05934940 MME sent “Detach Request” with cause “Re-attach required” to ENB after
successful CSFB ............................................................................................................................158
2.152 NS16.50716 Collision handling between ongoing Dedicated Bearer Activation and
incoming UE Initiated Tracking Area Update was not correct. .......................................................159
NA05977669 NS16.5_PILOT: QCI1 Included in MBR But Not Included in TAU Request ............159
NA05977926 NS16.5_PILOT: Dedicated Bearer Success Rate Went Down After Loading NS16.5
PCD ................................................................................................................................................159
2.153 NS16.50717 Abnormal number of secondary paging ......................................................161
NA05938357 (MME NS16.5)the number of secondary paging was abnormal .............................161
NA05974632 flns 3227b counter(EPS PS Paging first attempt success ratio) exceed 100% ......161
2.154 NS16.50718 RAB release response missing from collision scenario ..............................162
NA05969882 3G RAN Investigation into IU failures ......................................................................162
2.155 NS16.50719 solid and DB handler constant restart every 6 minutes ...............................163
PR194509 solid and DB handler constant restart every 6 minutes ...............................................163
2.156 NS16.50720 Peak IPDU CPU % elevated in multiple offices...........................................164
NA05977359 Peak IPDU CPU % elevated in multiple offices.......................................................164
NA05990429 (Flexi NS-MME)CPU load increase from 0 to 8% in standby IPDU ........................164
NA05993087 MME CPU load going high due to spare IPDU unit since 8th January in MME-TH 164
2.157 NS16.50721 S1 handover failure increase after enable NITZ ..........................................165
PR185352 S1 handover failure increase after enable NITZ..........................................................165
2.158 NS16.50722 Improvement in KPI “DNS Inquiry Success Rate (Home)” after upgrading to
newer release. ................................................................................................................................166
NA05923719 Improved in KPI “DNS Inquiry Success Rate (Home)” after FNS4.0 2.0 release
upgrade. ..........................................................................................................................................166
2.159 NS16.50723 SGs interface status abnormal ....................................................................167
NA05961025 SGS interface status abnormal................................................................................167
2.160 NS16.50724 PROCESS EXCEPTION for NE3SAGGX and loss of alarms on Netact side
168
PR176477 PROCESS EXCEPTION for NE3SAGGX and loss of alarms on Netact side ............168
2.161 NS16.50725 TAU reject of Roaming Subscriber leaves hanging bearers in PGW. .........168
PR165857 Tau Reject Cause Mismatch for HRT Roaming Subscriber during Inter System Tau
Reject ..............................................................................................................................................168
2.162 NS16.50726 Blackbox collection (Z1U) from spare MCHU-1 fails ...................................169
PR192125 Blackbox collection (Z1U) from spare MCHU-1 fails ...................................................169
2.163 NS16.50727 GTPV2 DDN request missing DDN ack response to SGW .........................170
PR176010 GTPV2 DDN request missing DDN_ack response to SGW .......................................170
2.164 NS16.50728 Process Exception during overload situation ..............................................171
PR175365 Process Exception during overload situation ..............................................................171
2.165 NS16.50729 NE3S Process Exception Alarms ................................................................172
NA05942925 MME Process Exceptions ........................................................................................172
2.166 NS16.50730 No Service-Req from MME on SGSAP PAGING-req = Failed MT CSFB calls
173
NA05973155 No Service-req from MME on SGSAP PAGING-req = Failed MT CSFB calls ........173
2.167 NS16.50731 The collision resolution between gateway initiated Detach and S1-Release
procedure ........................................................................................................................................174
NA05990508 (Flexi NS MME NS16.5)The collision resolution between gateway initiated Detach
and S1-Release procedure .............................................................................................................174
2.168 NS16.50732 ACPI5-A GISU CPU overloaded .................................................................175
PR140160 OpenTAS 16.2,TH 52.11-0, T4XX30FD: EPOFFI 13.19-0 fault..................................175
PR149947 OpenTAS 16.5, TH 54.6-0, T4XX40F8, PeV: EPOFFI 13.19 causes 509H file error
clear codes and huge load difference among the units ..................................................................175
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 10/231
D553209967 © Nokia 2016
Version 1.0
Confidential
PR158085 MSS15 MH 27.27-50 GCD5.0 PeV: ACPI5-A GISU CPU overloaded........................175
2.169 NS16.50733 Security testing:Dos Attack causes OMU reboot/swo .................................176
PR203273 Security testing:Dos Attack causes OMU reboot/swo .................................................176
2.170 NS16.50735 Commands ZDDS & ZDDE fail randomly when using CNUM ....................177
NA05977155 Commands ZDDS & ZDDE fails randomly when using CNUM ...............................177
2.171 NS16.50736 Iphone terminal was notified that did not support IMS calls during attach ..177
NA05975103 (Flexi NS MME NS16.5 WU3)Iphone terminal is notified does not support IMS calls
by MME in the process of attach ....................................................................................................177
2.172 NS16.50737 Failed OMU switchover due to NE3SAG (9C2) due to OMU's WDU disks
inconsistency ..................................................................................................................................179
PR149557 NE3SAG error logs were reported when doing unit diagnostic ...................................179
PR150970 Various computer logs appeared during Alarm System - Storing of alarm events test
case execution ................................................................................................................................179
2.173 NS16.50738 OMU unit did not recieve the supervision message ACK resulting in the
restart of FRIU unit .........................................................................................................................179
PR164745 The FRIU unit is restarted by OMU unit does not receive the supervision message
ACK from it .....................................................................................................................................179
2.174 NS16.50739 Alarm 1020 PROGRAM BLOCK START UP FAILURE caused by TUKEVA
after MCHU restart ..........................................................................................................................180
PR159315 [NS17] Not allowed alarms 1020:PROGRAM BLOCK START UP FAILURE,
1001:UNIT RESTARTED, 1023:EXCESSIVE DISTURBANCES IN SUPERVISION,
1007:RESTARTED PROGRAM BLOCK" .......................................................................................180
PR159320 [NS17-NS16.5MP1] : Alarm 1020 PROGRAM BLOCK START UP FAILURE caused by
TUKEVA after MCHU restart ..........................................................................................................180
2.175 NS16.50740 High CPU CPPU load ..................................................................................181
NA05959528 high CPPU load in MMEs CPPU .............................................................................181
2.176 NS16.50741 VOLTE video call failed ...............................................................................182
NA05982185 (Flexi NS MME NS16.5WU3)VOLTE video call failed ............................................182
2.177 NS16.50742 No response from MME to SGSN during Inter system RAU if IMSI does not
exist 183
PR193486 inter system RAU, no response , if imsi does not exist ...............................................183
2.178 NS16.50743 Command calander files not transferred during SW upgrade .....................184
NA05980990 Command calendar files not transferred during SW upgrade .................................184
2.179 NS16.50744 DBhandler sent messages to Subshandler but subshandler never replied
with ACK after maximum amount of retries was reached ..............................................................185
PR190478 MMDU-0 does not communicate with MMDU-1 ..........................................................185
2.180 NS16.50745 MME selection after CSFB in a pool with TA MMEs. ..................................186
NA05983787 MME selection after CSFB ......................................................................................186
2.181 NS16.50746 Subsystem MAPv can't startup automatically after MSS restart .................187
NA05931350 Double location after MSSKRC CD1.7 ....................................................................187
2.182 NS16.50747 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718 .........188
PR158905 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718 .........................188
2.183 NS16.50748 Inter MME TAU has conflict with X2 HO .....................................................189
NA05960953 (Flexi NS MME NS16.5)MME TAU has conflict with X2 HO on NS16.5 version ....189
2.184 NS16.50749 Attach successful ratio was dropped to 0 due to 1014 and 0004 alarms were
raised on CPPUs ............................................................................................................................189
NA05968119 (Flexi NS MME NS16.5) alarm 0004 on CPPUs, attach successful ratio is 0. ........189
2.185 NS16.50750 Error during TCP DoS test ...........................................................................190
PR165656 Open MSS 17 ATCA MH 40.23-0 security test - Error during TCP DoS test ..............190
2.186 NS16.50751 Alarm 3463 (73D) CHGINTERFACE PRB PROBLEM raised in SGSN......191
NA05972642 (Flexi NS-SGSN/MME NS16.5)2G 3G S-CDR did not generate. ...........................191
NA05981809 3463 (73D) CHG INTERFACE PRB PROBLEM in OR SGSN4 .............................191
2.187 NS16.50752 Possilbe IPDU SWO in case of multiple eNodeB Configuration Update
messages from the same eNodeB .................................................................................................192
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 11/231
D553209967 © Nokia 2016
Version 1.0
Confidential
NA05982786 After IPDU2 to reset is when resets remain high. ...................................................192
2.188 NS16.50753 MME did not send TAU reject message when Roaming control and ODB for
MME feature were on .....................................................................................................................193
PR200411 The MME does not send TAU reject message when Roaming control and ODB for
MME feature are on ........................................................................................................................193
2.189 NS16.50754 CSFB &IS TAU/RAU KPIs drop ...................................................................194
PR210751 NS16.5 MP1 NSHW3.0 TA: CSFB & IS TAU/RAU KPIs drop ....................................194
2.190 NS16.50755 CALENDAR TIME REFERENCE LOST ......................................................195
NA05926595 CALENDAR TIME REFERENCE LOST ..................................................................195
2.191 NS16.50756 MME sends error message to HSS because SRVCC failed .......................196
NA05991562 (Flexi NS-MME NS16.5WU3)MME send error message to HSS cause SRVCC failed
........................................................................................................................................................196
2.192 NS16.50757 Abnormal UE signaling control wasn't triggered when PDN connectivity was
rejected due to wrong PDN type .....................................................................................................197
NA05995095 (Flexi NS NS16.5) Abnormal UE signaling control wasn't triggered when PDN
connectivity was rejected due to wrong PDN type .........................................................................197
2.193 NS16.50758 When Inter MME TAU with SGW change was performed and UE did not
respond with TAU complete, 3717 alarm "SGW Unavailable" was raised. ....................................198
NA05985231 (Flexi NS-MME NS16.5)3717 alarm ........................................................................198
2.194 NS16.50759 ODB flag is still set as "Y" on MME side after removal of ODB ..................199
PR202017 ODB flag is still set as "Y" on MME side after removal of ODB ..................................199
2.195 NS16.50760 MME was not sending SGsAP location update to available VLR after MME
restart. 200
NA05975505 Why MME is not sending SGsAP location update to available VLR after MME
restart. .............................................................................................................................................200
2.196 NS16.50761 SOAP - Format String Vulnerability (libxml2) ..............................................201
PR156253 T16.2 SP1 Cloud - T5XX3100 - LNXAB6G2 1.8-0 - SOAP - Format String Vulnerability
(libxml2) ..........................................................................................................................................201
2.197 NS16.50762 MME ARP issue caused during inter-system TAU ......................................202
NA05995101 MME ARP issue when inter-system TAU ................................................................202
2.198 NS16.50763 Service affectation was presented after upgrade from NS15MP1 to NS15
MP2 203
NA05965736 Flexi NS-SGSN / After update it presents service affectation .................................203
2.199 NS16.50764 OpenSSL ≤ 1.0.1t, ≤ 1.0.2h - Multiple Vulnerabilities - CVE-2016-2182.....204
PR176863 OpenSSL ≤ 1.0.1t, ≤ 1.0.2h - Multiple Vulnerabilities - CVE-2016-2182.....................204
2.200 NS16.50766 Increase in S1 RESET // Femto-GW ..........................................................204
NA05991744 NA05991744 / MME Increase in S1 RESET//Femto GW .......................................204
2.201 NS16.50767 MME sending PAA - IPv6 - ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00 in
CSReq 205
CAS-11908-F0Z5 MME sending PAA - IPv6 - ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00 in
CSReq ............................................................................................................................................205
2.202 NS16.50768 Wrong counting of RAU events ...................................................................206
NA05973702 FlexiNS - SGSN NS15 MP2 is counting RAU events as MME-SGSN RAU via S3 206
2.203 NS16.50770 MME did not send Delete Session Request when procedure was discarded
by UE AMBR as zero. .....................................................................................................................207
PR178969 MME does not send Delete Session Request when the UE performs 2nd attach
procedure without detaching first ....................................................................................................207
2.204 NS16.50771 MME China LI X2 interface failure ...............................................................208
NA05982880 (NS16.5)The MME China LI X2 interface cannot establish after MME upgrade from
NS16 MP1 to NS16.5 .....................................................................................................................208
2.205 NS16.50772 UCSW version was not correct after AHUB3-A UCSW/IPMC activation ....209
PR146640 RDY 230743 - UCSW version is not correct after AHUB3-A UCSW/IPMC activation 209
2.206 NS16.50773 Alarm 3550 was active on IPPU13/15/17 although the application was
configured .......................................................................................................................................211
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 12/231
D553209967 © Nokia 2016
Version 1.0
Confidential
NA05935573 Alarm 3550 is active on IPPU13/15/17 although the application is configured .......211
2.207 NS16.50774 CSFB degradation .......................................................................................212
NA05994265 CSFB degradation ...................................................................................................212
2.208 NS16.50775 ACPI4-B Firmware update failed .................................................................213
NA05992182 (NS16.5)ACPI4-B Firmware update failed ..............................................................213
2.209 NS16.50776 Service Request success rate decreased because of Modify Bearer
Response not include S1-U GTP-U FTEID as part of Inter MME TAU ..........................................213
NA05983132 (Flexi NS-MME NS16.5)MME upgrade to NS16.5, the Service Request success rate
decreased .......................................................................................................................................213
2.210 NS16.50777 SWU configuration not loaded to 3rd shelf SWU after ZD8A ......................214
PR200010 SWU configuration not loaded to 3rd shelf SWU after ZD8A ......................................214
2.211 NS16.50778 Netstat caused segment fault and coredump was generated .....................215
PR156418 NS15 MP3 NSHW:3.0 SA-MME, netstat coredump ....................................................215
2.212 NS16.50780 Wrong BCD encoding in case IMREQ=ONNONSTD and IMEI/SV had less
that normal digits. ...........................................................................................................................216
PR173789 IMREQ=ONNONSTD wrong BCD encode ( FF is wrong) ..........................................216
2.213 NS16.50781 EPS_ROAM_PDN_ACT_FOR_VOLTE_FAIL increase after Roaming Control
for IMS and VOLTE ........................................................................................................................217
NA05947303 NS 16.5 - EPS_ROAM_PDN_ACT_FOR_VLTE_FAIL increase after Roaming
Control for IMS and VOLTE FOA ...................................................................................................217
2.214 NS16.50782 IPDU unit restarted automatically when it went to WO-EX status after
upgrade ...........................................................................................................................................218
NA05979981 (Flexi NS-MME NS16.5)IPDU units restarted automatically when it came to WO-EX
status after upgraded to NS16.5 .....................................................................................................218
2.215 NS16.50783 Files could not be transferred to OMU using ftpput-command....................218
PR161879 Files cannot be transfer from TGS to other DXT OMU using ftpput-command in ATCA
........................................................................................................................................................218
2.216 NS16.50784 IMG size much bigger than the previous ones. ...........................................219
PR164543 IMG size much bigger than the previous ones ............................................................219
2.217 NS16.50785 Performance degradation after critical process kill on MMDU ....................220
PR071392 NS15 MP1:: Traffic drop during SubsHandler process restart provocative test case .220
3. New / Changed functionality ...............................................................................................................222
3.1 NS16.50734 RNC Data Traffic Decrease due To Messages Flow Control from SGSN ...............222
NA05938362 RNCs Decrease Data Traffic Until 90% Due To Messages Flow Control From SGSN
........................................................................................................................................................222
3.2 NS16.50769 FC085_004074 Network KPI Downgrade as many counters are mapped to Single
KPI counter .....................................................................................................................................223
3.3 NS16.50779 FC085_004133 CMAS Performance Enhancements Taiwan Market ......................223
4. 3rd party corrections ...........................................................................................................................223
5. Known Open Faults ............................................................................................................................224
5.1 MME doesn’t send update location to MSS for share MCC 901 Roaming case ............................224
5.2 HSS Restoration is not working as per 3GPP specifications .........................................................224
5.3 Connection from MME to LIMS is not restored after any communication failure ...........................225
5.4 X2 Handovers failure KPI increased 0.02% on MME after E/// eNB upgrade ................................225
5.5 CAS-12671-K9Y2 -  S6a Cancel Location SR and ISD SR Went Down After Activating Paging
Profile ..............................................................................................................................................225
5.6 Received corrupted CDRs at CMD during eSW upgrade of SGSN in NS15 MP3 .........................226
5.7 Starvation on GSP Hand Group 3; Follow-up on EME O679 .........................................................227
5.8 No PLMN measurements in ATCA SGSNs (and one DX SGSN) ..................................................228
5.9 Hanging session not deleted due to double attach in the MME .....................................................228
5.10 On-going PDN Connectivity collide with incoming X2 HO ..............................................................230
6. Release objects...................................................................................................................................231
7. Previous deliveries for the release ......................................................................................................231
8. Appendices / References ....................................................................................................................231
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 13/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Contact
Contact your local Nokia support

Summary of changes

01-Mar-2017 1.0 Approval date

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 14/231


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

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

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

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

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

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

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

Copyright © 2016 Nokia. All rights reserved.

Important Notice on Product Safety

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

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

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

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

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

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 15/231


D553209967 © Nokia 2016
Version 1.0
Confidential
1. PURPOSE

The purpose of this document is to give a brief summary on the SW update Delivery
corrections content.

2. CORRECTIONS

2.1 NS16.50481 Incorrect NAS Sequence number

NA05916537 NS16 1.24-0 - Incorrect NAS Sequence number

Summary of the original problem:


- During SRVCC handover cancel procedure, the MME did not update the Downlink NAS count and as a
result sent wrong NAS sequence number to UE. This caused UE inactivity.

How end user/operator could detect the problem:


- By performing the following procedure:
1. Attach.
2. PDN connectivity.
3. Dedicated bearer activation.
4. SRVCC handover cancellation.
5. PDN connection activation or dedicated bearer modification.

Description of the fault:


- During SRVCC handover cancel procedure, the MME did not update the Downlink NAS count and as a
result sent wrong NAS sequence number to UE. This caused UE inactivity.

Related feature / functionality:


- SRVCC handover cancellation.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- The Downlink NAS count will be increased correctly during SRVCC handover cancel procedure.
In detail, the sequence number in following downlinkNASTransport message after
id-downlinkNASTransport, Notification should be greater than the id-downlinkNASTransport, Notification
and consecutive.

Risk analysis of the correction:


- None

Effects on end-user:
- Defective end-user experience. Procedure after SRVCC handover cancel procedure was affected.

Effects on operator:
- Next two NAS messages were going with wrong NAS count before NAS count recovery. This makes
procedure to wait for two NAS timer expiration (i.e. two extra retry). Hence chances of collision /
retransmission also increase.

System effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 16/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 11.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

2.2 NS16.50490 Incorrect destination port in PGW restart notification acknowledgement from MME
to SGW for EPC node restoration feature

NA05916632 Incorrect destination port in PGW restart notification acknowledgement from


MME to SGW for EPC node restoration feature

Summary of the original problem:


- During PGW restoration procedure, SGW sent PGW restart notification message to MME with UDP src
port different than the default (2123) and MME faulty sent PGW restart notification Ack to the default port.
As a result, Ack message never reached SGW. So SGW continues to send retransmissions of PGW
restart notification message. MME concluded normally PGW restoration procedure but it didn't send
correct ack message.

How end user/operator could detect the problem:


- End user did not detect any problem but operator saw decreased KPIs due to the retransmissions.

Description of the fault:


- MME did not sent the ack message with the updated src port which has been sent in the PGW restart
notification message.

Related feature / functionality:


- FC0085_003290_EPC_NODE_RESTORATION

Dependency on configuration:
- If operator has configured the default source port in SGW the problem couldn't be detected.

Workaround:
- Operator can configure the default src port in SGW (2123) and the problem will be overcome.

Description of the correction:


- In the PGW restart notification Ack message MME will update the SGW port based on the src port of
PGW restart notification message.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- KPIs for restoration procedure were decreased in cases that PGW would configure src UDP port other
than the default.

System effects:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 17/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX924G2.IMG 8.60-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

2.3 NS16.50508 Emergency call is dropped in case of E-UTRAN Restricted Access Type in IDR

PR154615 Emergency call is dropped in case of E-UTRAN Restricted Access Type in IDR

Summary of the original problem:


- Emergency call is dropped in case of E-UTRAN Restricted Access Type and the value is E-UTRAN not
allowed in Insert Data Request message.

Description of the problem


- Emergency call is dropped in case of E-UTRAN Restricted Access Type and the value is E-UTRAN not
allowed in Insert Data Request message.

How end user/operator could detect the problem:


- UE created emergency call and HSS sends E-UTRAN Restricted Access Type and the value was E-
UTRAN not allowed in Insert Data Request message, then emergency call dropped.

Description of the fault:


- Emergency call dropped in case of E-UTRAN Restricted Access Type in Insert Data Request message.

Dependency on configuration:
- Configure the Emergency parameter.

Faulty component and version:


- LNX934G2.IMG 7.270-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP4

Workaround:
- None

Description of the correction:


- When UE creates multiple pdn (one of is emergency pdn), MME will keep the emergency PDN and drop
the other PDN.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 18/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Customer effects:
- None

Test requirements:
- None

2.4 NS16.50544 ZKAI doesn't show any application IP for IPPU-17

NA05931813 ZKAI doesn't show any application IP for IPPU-17

Summary of the original problem:


- ZKAI doesn't show any application IP for IPPU-17.

How end user/operator could detect the problem:


- By typing ZKAI command. The printout does not show anything related to IPPU-17.

Description of the fault:


- IPPU-17 receives Logical Address: 0x42DF at customer's SGSN. Through code review, it is observed
that the IPPUs' Logical Address ranges among limits 0x41D6 - 0x41F5. Based on Platform experts,
IPPUs' Logical Address is not sequential and valid ranges are among limits: 0x41D6 - 0x41E6 and
0x42DF - 0x42ED. Subsequently, it seems that IPPU-17 Logical Address: 0x42DF is out of the accepted
range.

Dependency on configuration:
- None

Faulty component and version:


- CGHHANJX.PAC 13.8-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- The ranges of IPPUs' Logical Address are updated to the following valid (not sequential) limits: 0x41D6
- 0x41E6 and 0x42DF - 0x42ED. These new ranges are checked when ZKAI command is typed. As
result, ZKAI command for the IPPUs that are in the second range (such as IPPU-17), is printed correctly.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- ZKAI MML command will work as intended.

Test requirements:
- Test the ZKAI MML.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 19/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.5 NS16.50545 Console History showed by raw command was empty on ACPI4-B

PR072068 #22622 / ACPI4-A Console History showed by raw command is empty on ACPI4-
A/B

Summary of the original problem:


- Console History showed by raw command was empty on ACPI4-B.

How end user/operator could detect the problem:


- By using raw command: ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00 to check the output of CONSOLE
HISTORY.

Description of the fault:


- The Console History showed by raw command was empty on ACPI4-B:
root@ACPI4-A_02_02_02_BI0:/root ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00
***************************
** CONSOLE HISTORY **

************END************

Faulty component and version:


- AEM00019.IMG 1.26-0 and before (version too legacy to be specified).

Description of the correction:


- Console History showed by raw command is fixed in order not to be empty on ACPI4-B.

HW UNIT: ACPI4-B
Firmware application: HPM
Firmware version: 2.62.0
Corresponding AEM Delivery module: AEM00019
Corresponding AEM Delivery module version: 1.27-0

Dependency on configuration:
- None

Faulty component first delivered in(e.g. release, CD):


- NS40

Risk analysis of the correction:


- None

Correction effects:
- None

Customer effects:
- None

2.6 NS16.50546 Console History showed by raw command was empty on ACPI4-A

PR072068 #22622 / ACPI4-A Console History showed by raw command is empty on ACPI4-
A/B

Summary of the original problem:


- Console History showed by raw command was empty on ACPI4-A.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 20/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- By using raw command: ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00 to check the output of CONSOLE
HISTORY.

Description of the fault:


- The Console History showed by raw command was empty on ACPI4-A:
root@ACPI4-A_02_02_02_BI0:/root ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00
***************************
** CONSOLE HISTORY **

************END************

Faulty component and version:


- AEM00018.IMG 1.31-0 and before (version too legacy to be specified)
- AEM00064.IMG 1.5-0 and before (version too legacy to be specified)

Description of the correction:


- Console History showed by raw command is fixed in order not to be empty on ACPI4-A.

HW UNIT: ACPI4-A
Firmware application: HPM
Firmware version: 2.62.0
Corresponding AEM Delivery module: AEM00018
Corresponding AEM Delivery module version: 1.32-0

HW UNIT: ACPI4-A
Firmware application: EEPROM
Firmware version: 3.48.1
Corresponding AEM Delivery module: AEM00064
Corresponding AEM Delivery module version: 1.6-0

Dependency on configuration:
- None

Faulty component first delivered in(e.g. release, CD):


- NS40

Risk analysis of the correction:


- None

Correction effects:
- None

Customer effects:
- None

2.7 NS16.50552 MME did not send Update Bearer Response during GW initiated QOS modification
for an unreachable subscriber

PR169125 For Unreachable Subscriber (PPF off) the QosUpdateProcedure Hangs in


TRHandler

Summary of the original problem:


- GW requested with Update Bearer Request message a bearer modification while UE was Unreachable
and MME did not send an Update Bearer Response.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 21/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- MME did not respond to GW in the Update Bearer Request in case that UE is Unreachable.

Description of the fault:


- The UE was unreachable and GW sent Update Bearer Request for bearer modification but in that case
MME did not send a response to the GW.

Related feature / functionality:


- QoS Update Procedure.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Response to the Update Bearer Request message when the UE is Unreachable with cause Unable to
Page UE.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 11.13-30
- LNX924G2.IMG 11.5-27

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

2.8 NS16.50571 Collision handling between ongoing Insert Subscriber Data and incoming Delete
Subscriber Data was not done correctly

NA05933794 MME didn't response DSR message lead to 4G APN replacement with dummy
APN failure

Summary of the original problem:


- This issue happened due to wrong collision handling in MME. In detail, there was ongoing Insert
Subscriber Data Request and Incoming Delete Subscriber Data Request collision for which the current
resolution was to drop the incoming Delete Subscriber Data Request silently.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 22/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- By performing Attach / PDN Connectivity for a specific APN. The HSS sent Insert Subscription Data by
modifying Service selection for APN context ID 1 when UE was in IDLE. This triggered NW initiated
detach in MME. At the same time, the HSS sent Delete Subscriber Data request by deleting PDN with
APN context ID 2. The MME drops Delete Subscriber Data request silently and thus the MME held the
APN context with ID 2.

Description of the fault:


- UE had one default bearer active with APN context ID as 1. HSS sent Insert Subscriber Data Request
almost simultaneously with Delete Subscriber Data request in order to delete the APN configuration PDN
with APN context ID 2. Due to a collision, the MME dropped Delete Subscriber Data request silently.
Hence, APN configuration with APN context ID 2 was not deleted. When the UE tried Attach or PDN
Connectivity for APN presented in APN configuration with context ID 2 then the procedure would succeed
even though HSS had deleted the subscription for that specific APN. As a result, Collision handling for
ongoing Insert Subscriber Data and Delete Subscriber Data was not done correctly.

Related feature / functionality:


- Collision handling.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Ongoing Insert Subscriber Data Request and Incoming Delete Subscriber Data Request collision will be
handled with collision resolution by continuing ongoing and the incoming procedures (COCI). So
subscription data is updated properly in MME and then it is acknowledged to HSS using Delete
Subscriber Data Answer.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 8.65-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 23/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.9 NS16.50572 Cause code in the E-RAB Release Command is changed from "nas unspecified" to
"normal release"

NA05947937 Changing cause code to unspecified to normal

Summary of the original problem:


- Cause code in the E-RAB Release Command was "nas unspecified" instead of "normal release" when
Dedicated Bearer Activation procedure was terminated due to collision with any incoming procedure (e.g.
MT CSFB).

How end user/operator could detect the problem:


- During collision of Dedicated Bearer Activation procedure with an incoming procedure (e.g. MT CSFB),
where the ongoing Dedicated Bearer Activation procedure is dropped, MME sends E-RAB Release
Command as part of the termination procedure. In the E-RAB Release Command, during the Dedicated
Bearer Activation procedure termination, cause code value was set to "nas unspecified".

Description of the fault:


- Wrong cause code was filled in the E-RAB Release Command when Dedicated Bearer Activation
procedure was terminated due to collision with any incoming procedure (e.g. MT CSFB).

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.0-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Cause code is changed to "normal release" in E-RAB Release Command when Dedicated Bearer
Activation procedure gets terminated due to collision with any incoming procedure (e.g. MT CSFB).

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- ENB VoLTE Call KPI will not be degraded due to "nas unspecified" cause in E-RAB Release Command.

Test requirements:
1. Attach.
2. PDN connectivity.
3. Dedicated bearer activation procedure.
MME sends E-RAB Setup Request with "Activate dedicated EPS bearer context request" NAS message.
eNB responded with E-RAB Setup Response but response from UE is still awaited.
4. MT CSFB.
Note: Ongoing Dedicated bearer procedure collides with incoming MT CSFB (e.g. SGs Paging) and
terminates the ongoing Dedicated bearer activation procedure.
5. MME sends E-RAB Release command as part of dedicated bearer activation procedure termination.
6. MT CSFB proceeds.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 24/231
D553209967 © Nokia 2016
Version 1.0
Confidential
2.10 NS16.50573 ULI was sent without TAI and ECGI in MBR when HO Notify was not received

PR153977 ULI is sent without TAI and ECGI in MBR when HO Notify is not received

Summary of the original problem:


- ULI (User Location Info) was sent without TAI and ECGI in MBR (modify bearer request) when
Handover Notify was not received during Inter MME Handover procedure.

How end user/operator could detect the problem:


- During inter MME handover, if ENB didn't send Handover Notify but send TAU request, the ongoing
handover collided with incoming TAU.

Description of the fault:


- Normally, MME gets the ECGI and the TAI value from the Handover Notify message, however, there
wasn’t Handover Notify message in collision procedure between HO and Inter MME TAU procedure.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 5.17-0

Workaround:
- None

Description of the correction:


- MME gets the TAI and ECGI value from the TAU request message.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.11 NS16.50574 When multiple Delete Subscriber Data Requests collided with Attach, E-RAB
Release Command with Ue AMBR=0 was sent to ENB

NA05936752 Increase in M51C017 PDN Connectivity Failed_SGW in MME after NS16.5


upgrade

Summary of the original problem:


- When Multiple Delete Subscriber Data Requests collided with Attach, E-RAB Release Command with
Ue AMBR=0 was sent to ENB.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 25/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- Increase in MME counter M51C017 (PDN MME INITIATED DEACTIVATION FAILED).

Description of the fault:


- Ongoing Attach collided with incoming Delete Subscriber Data Request(DSR) and MME put DSR on
hold till attach was completed. When the second DSR comes, a third procedure collision was detected
and MME queued up this 3rd procedure (DSR #2) as well, to be executed after 2nd procedure (DSR #1)
completed. At this stage, Attach was completed and (DSR#1) procedure was started which triggered NW
detach. If a fourth procedure (DSR #3) came in, it was picked up by the on-hold 3rd procedure (DSR #2)
and started execution by sending E-RAB release with UeAMBR = 0 instead of starting a new DSR
procedure. The issue was seen when Attach-DSR-DSR collision happened and a third DSR came before
the first DSR was completed.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.260-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Additional check is added in this scenario before sending E-RAB Release Command to ENB by
checking if Subscriber is registered. Also, validity check is added for OnHold procedures to not consume
incoming messages, instead start a new procedure for the incoming message.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- Reduced signalling on S1 interface.

Customer effects:
- None

Test requirements:
1. UE starts Attach procedure.
2. HSS sends DSR with "PDN subscription contexts withdrawal" for non-default APN with which UE tried
to attach.
3. Before completion of Attach procedure, HSS re-sends DSR.
4. Attach is completed, MME start processing 1st DSR message and triggers NW detach towards UE.
5. HSS sends DSR again for the 3rd time.

2.12 NS16.50575 3G users faced navigation problems

NA05950892 Flexi NS 15 / Claim 3G users for navigation problems and errors in the computer
logs / No alarms provided

Summary of the original problem:


- 3G users faced navigation problems.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 26/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- Degradation in the formulas of PDP modification. MOD PDP was 99,93% success and after this error
appeared went to 93.60%.

Description of the fault:


- In Inter SGSN relocation scenarios, with QoS change initiated from GGSN, modification of service was
failing due to error cause mand_ie_inc_c. This IE is rnc_ip_address in gtp_update_pdp_context_req_s
message. During the modification of service, after the rab is established with RNC, if RNC parameter
RAB MODIFY SUPPORTED is set to OFF, SGSN should send two rab assignment requests. The first
one will have as rab task release_c to release the rab and re-create it with the second rab assignment
request that will have as rab task setup_c. In NS15 SW release, only the first rab assignment request
was sent and after that message gtp_update_pdp_context_req_s was sent to GGSN with empty
rnc_ip_address as the rab has been released.

Dependency on configuration:
- RAB MODIFY SUPPORTED RNC parameter is set to OFF

Faulty component and version:


- GMRPRBMX.PAC 27.155-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP2

Workaround:
- A workaround could be to change RNC parameter RAB MODIFY SUPPORTED to ON, so SGSN will
send only one rab assignment request with rab task set to modify_c.

Description of the correction:


- Changes were done in the procedure where GMG receives the first rab assignment response where rab
has been successfully released. With the provided correction, a second rab assignment request will be
sent towards RNC with rab task setup_c.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.13 NS16.50576 Emergency Bearer not added in ICSR request in Gn Based TAU.

PR154033 Emergency Bearer not added in ICSR request in Gn Based TAU.

Summary of the original problem:


- Ue was sending Tau Request message with emergency bearer as active during Gn Based InterSystem
Tau, but it is not included in Initial Context Setup Request Message.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 27/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description how problem can be detected
- The problem could be detected when ICSR was sent as part of Gn Based InterSystem Tau and in ICSR
did not contain emergency bearer. After InterSystem Tau end user, won't be able to do emergency call.

Dependency on configuration: Yes


- Gn Interface Should be configured between MME and SGSN.

Faulty component and version:


- LNX934G2.IMG 11.67-0

Description of the fault:


- During Gn Based InterSystem Tau, if Ue sends Tau Request with Emergency Bearers as active, then
these bearers are not included in Initial Context Setup Request message.

Workaround:
- None

Description of the correction:


- During Gn Based InterSystem Tau, if Ue sends Tau Request with Emergency Bearers as active, then
these bearers are included in Initial Context Setup Request message.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Emergency Bearers will be established successfully as part of Gn Based InterSystem Tau if they are
requested by UE. Hence operator will be able provide emergency services to end user.

Test requirements:
- Ue Performs Gn Based InterSystem Tau by sending Tau Request Message with at least one
emergency pdn as active. MME sends context Request to SGSN. Context Response containing at least
one emergency PDN from SGSN.

2.14 NS16.50577 E-RAB set up failure with cause [RadioNetwork-cause=multiple-E-RAB-ID-


instances]

NA05939708 eRAB addition QCI1 SR degraded TT 11904843 - Multiple eRAB instances

Summary of the original problem:


- E-RAB set up failure was occurring with cause [RadioNetwork-cause=multiple-E-RAB-ID-instances],
after x2 handover collision with Delete Bearer Request.

How end user/operator could detect the problem:


- E-RAB set up failure with cause [RadioNetwork-cause=multiple-E-RAB-ID-instances].

Description of the fault:


- During x2 handover collision with Delete Bearer Request, MME did not send E-RAB Release Command
message to ENB to release the deactivated bearer and when MME requested a new bearer with same E-
RAB ID to ENB, ENB rejected with cause multiple-E-RAB-ID-instances.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 28/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.5-0
- LNX934G2.IMG 11.13-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- MME sends E-RAB Release Command message to ENB to delete the bearer during x2 handover
collision with Delete Bearer Request

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.15 NS16.50578 EPC initiated EPS Bearer Release requests for QCI1 & Volte drop call increased

NA05957270 FNS : EPC initiated EPS Bearer Release requests for QCI1 & Volte drop call
increasing

Summary of the original problem:


- Collision between Service Request and S1 Release when SGW has triggered bearer release.

How end user/operator could detect the problem:


- Many Service Request and S1 Releases for a specified UE in this scenario would be observed, while it
would not be able to connect.

Description of the fault:


- During a UE triggered Service Request scenario, MME had already sent Modify Bearer Request to
SGW for the active bearers. Then, SGW replied with failure cause "Context Not Found" for one of the
active bearers. MME sent ERAB Release Command to the UE which replied with ERAB Release
Response. UE did not send DeactivateEpsBearerContextAccept and for MME was still considered to be
as active. Finally, UE triggered S1 Release while Service Request procedure was still ongoing. MME
resolved the collision terminating Service Request procedure. However, during Service Request some
bearers were marked from SGW as pending to be released but were eventually never removed from the
Database. The resolution of collision was to terminate Service Request and continue S1 release without
removing the bearer.

Dependency on configuration:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 29/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- LNX934G2.IMG 11.13-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- The correction included enhancement of collision handling between Service Request and S1 Release
when SGW has triggered bearer release so that the subscriber in database is being updated and the
proper bearers are released.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.16 NS16.50579 During HSS initiated detach the Mme_internal_cause was missing from Traffica
MM reports

PR173241 HSS_initiated_detach missing Mme_internal_cause

Summary of the original problem:


- When Cancel Location Request was sent during the InterMME Tau and cancellation Type was
MMEUpdateProcedure then MME was not filling the internal cause in Traffica MM Report.

How end user/operator could detect the problem:


- Operator could detect the problem at Traffica report received for HSS initiated Detach procedure.

Description of the fault:


- Internal cause that was sent to Traffica Report for HSS Initiated Detach procedure (Cancel Location
Request) was empty as result-code in case cancellation type was MMEUpdateProcedure.

Dependency on configuration:
- Traffica is used as system reporting tool.

Faulty component and version:


- LNX924G2.IMG 11.92-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 30/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- Internal MME cause of procedure hssDetachProc is included to message sent to Traffica Handler for
creating the report.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- Traffica Report for HSS initiated detach

Customer effects:
- None

Test requirements:
- None

2.17 NS16.50580 MME was sending invalid ENB-S1AP-ID in PDN Disconnect reject message

NA05937549 Incorrect ENB ID(s1ap.MME_UE_S1AP_ID) sent by MME

Summary of the original problem:


- MME was sending invalid eNBS1APID in PDN disconnect reject message.

How end user/operator could detect the problem:


- Invalid eNBS1APID will be sent in PDN disconnect reject message.

Description of the fault:


- In this case collision happened between PDN connectivity request and UE Context Release Request.
MME terminated the ongoing PDN creation and processed the eNB sent UE Context Release Request.
After this, UE sent PDN disconnect message and again collision happened in MME between UE context
release and PDN disconnect message. Once UE context release procedure was completed, ECM state
changed to IDLE and MME made the eNBS1AP as FFFFF.
So, while PDN disconnect request message was picked up, MME was sending eNB s1ap id with value
FFFFFF.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 1.450-0
- LNX934G2.IMG 1.450-0

Faulty component first delivered in(e.g. release, CD):


- NS22

Workaround:
- None

Description of the correction:


- When MME receives PDN disconnect request message and ECM state is idle, it will send error
indication message instead of sending PDN disconnect reject with wrong eNB S1ap id.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 31/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Analysis of the correction risk to the customer / end-user:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- With the fix, error indication will be sent whenever PDN disconnect message is received by MME in
ECM idle state.

Test requirements:
1. Attach.
2. PDN Connectivity Request.
3. UE Context Release Request.
NOTE: At this stage collision, will happen between PDN connectivity and S1 release procedures. PDN
connectivity procedure will be terminated, s1release procedure will be continued and after this processing
ECM state will move to IDLE.
4. PDN Disconnect Request.

2.18 NS16.50581 Wrong PGW selection by MME during PDN connectivity procedure

NA05940713 PGW Selection in MME

Summary of the original problem:


- During standalone PDN connectivity procedure MME was selecting wrong PGW when UE provided
APN was not present in subscribed APN list and if 2250 PRFILE (MME_OVRD_INV_APN_PDN_CO) is
enabled.

How end user/operator could detect the problem:


- MME was sending create session request with wrong PGW IP as part of the standalone PDN
connectivity procedure.

Description of the fault:


- During Inter system TAU if SGSN sends Context Response with bearer id 6, MME stores the APN in
PDN id 2 as per implementation.
After that when MME receives UE initiated standalone PDN connectivity request with UE provided APN it
allocates Bearer id 5/PDN1 and stores the HSS provided APN in PDN id 1 as UE provided APN not
found in subscription Data received from HSS.
During PDN connectivity request procedure, due to internal fault in MMDU, MMDU was sending internal
message to CPPU with same UE provided APN for both the PDNs. Since same APN was received for
both the PDN, hence based on the current implementation, CPPU was not considering the IP which is
fetched from DNS resolution. Instead it was sending to the same IP in which previous create session
request was sent for bearer ID 6.

Dependency on configuration:
- Below feature parameters need to be enabled:
ZWOC:2,2250,0001;
ZWOC:2,2050,00FF;
ZWOC:2,2051,00FF;

MME local default APN parameter:


ZMXN: ETPLMN, MAPN: OPT=1;

Faulty component and version:


- LNX934G2.IMG 7.10-0
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 32/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component first delivered in(e.g. release, CD):
- NS15

Workaround:
- None

Description of the correction:


- Corrected the fault in MMDU so that proper APN is sent in internal message for each of the PDN
connections if multiple PDN's exists.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- With the fix MME will send create session request with proper PGW IP as part of the standalone PDN
connectivity procedure.

Customer effects:
- With the fix MME will select proper PGW as part of the standalone PDN connectivity procedure.

Test requirements:
- Below feature parameters need to be enabled:
ZWOC:2,2250,0001;
ZWOC:2,2050,00FF;
ZWOC:2,2051,00FF;

MME local default APN parameter:


ZMXN: ETPLMN, MAPN: OPT=1;

Scenario:
1. During Inter system TAU, SGSN sends Context Response to MME with bearer id 6.

2. Then UE sends standalone PDN connectivity request with UE provided APN which is not present in
subscription Data received from HSS.

2.19 NS16.50582 GSP GRP3 hand hang up during periodic RAU

NA05960359 GSP hand hang up related to ticket NA05950892

PR181522 GSP GRP3 hand hang up during periodic RAU

Summary of the original problem:


- GSP GPR3 hand remain hanging for 5 minutes during periodic RAU.

How end user/operator could detect the problem:


- Via tracing internal and external log files.

Description of the fault:


- During a periodic RAU on 3G, after completion of this procedure, UE sends routing area complete
message to the already reserved GSP hand (responsible to serve RAU procedure). Then the
aforementioned GSP hand receives this message and since there is nothing else to do in this phase of

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 33/231


D553209967 © Nokia 2016
Version 1.0
Confidential
scenario, remains hanging for 5 minutes and then a supervision message is triggered from GSP master
to release this hand.

Dependency on configuration:
- None

Faulty component and version:


- GSP_G6JX.PAC 10.7-0

Faulty component first delivered in(e.g. release, CD):


- SG7

Workaround:
- None

Description of the correction:


- After routing area complete message comes from MS, iu release cmd timer is reset. This timer is
responsible to release GSP hand in cases where there are instructions for IU release and follow on.
Although in this scenario there are the aforementioned conditions, GSP hand had not been released due
to this timer reset when there is an unexpected RAU complete message from MS. To this direction, this
timer is set again and as result, GSP hand is released as well as SCCP connection is released.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.20 NS16.50583 VoLTE basic call stopped working

NA05911702 VoLTE basic call stopped working after upgrading FNS from NS3.0 to NS15
MP2

Summary of the original problem:


- If customer used IMS APN 'ims.oi.com.br', the ims bearer couldn't be allocated.

How end user/operator could detect the problem:


- By using the APN name is configured as 'ims.oi.com.br'.

Description of the fault:


- Generally, MME only allow IMS OI configured as 'ims'. if customer configured APN-OI second part less
than 3 characters, such as 'ims.oi', the method substring (0,3) will throw an exception which caused
bearer activation failure.

Dependency on configuration:
- IMS APN-OI configured as ims.xx (less than 3 characters).

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 34/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- LNX922G2.IMG 7.1.8-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP2

Workaround:
- None

Description of the correction:


- If the second part of APN-OI is less than 3, the method returns false, and do not throw exception.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.21 NS16.50584 SHMU COMMUNICATION FAILURE alarms

PR178207 3481 SHMU COMMUNICATION FAILURE alarms

Summary of the original problem:


- Alarm 3481 was raised for both Shelves.

How end user/operator could detect the problem:


- 3481 alarm was triggered several times.

Description of the fault:


- It was a known issue in Shelf Manager eSW 63998-06199. One logic IP address in the active Shelf
Manager couldn't open 623 port for RMCP, which is used to build IPMI session from OMU to Shelf
Manager.

Faulty component and version:


- AEM00006.PAC 1.33
- AEM00041.PAC 1.25-1

Faulty component first delivered in(e.g. release, CD):


- NS15

Description of the correction:


- Retry mechanism introduced in PPS Root File System.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 35/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.22 NS16.50585 Dedicated bearer activation failed after colliding with incoming X2 handover

NA05942939 (NS 16)Dedicated bearer activation failure due to collision between ongoing
Bearer Activation and incoming X2 Handover

Summary of the original problem:


- Dedicated bearer activation failed after colliding with incoming X2 handover.

How end user/operator could detect the problem:


- The target eNB added all those bearers (to be setup in ongoing Dedicated bearer activation) into the
Path Switch Request message and forward Activate Dedicated EPS Bearer Context Accept (for
Dedicated bearer activation) to MME during X2 handover.

Description of the fault:


- MME did not retry to active dedicated bearers after X2 handover is complete.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 8.102

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- MME ignores the Activate Dedicated EPS Bearer Context Accept arriving during X2 handover and
retries to active dedicate bearers towards target eNB after X2 handover.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Dedicated bearer activation will be successful in this specific scenario.

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 36/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.23 NS16.50586 MME did not respond to first create bearer request from SGW when handover
from WiFi to LTE was performed

NA05947056 MME does not respond to first create bearer request from SGW when handover
from WiFi to LTE

Summary of the original problem:


- MME didn't respond to the first Create Bearer Request from SGW when handover from WiFi to LTE
happened.

How end user/operator could detect the problem:


- UE handover from Wifi to LTE, S-GW sent first Create Bearer Request to MME, but MME didn't send
message to eNB to continue the procedure.

Description of the fault:


- S-GW sent Create Bearer Request and Modify Bearer Response almost at the same time. If MME
handled Create Bearer Request firstly, since collision result is continue ongoing and drop incoming, the
Create Bearer Request message was dropped silently.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.95-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Change the collision resolver between PDN connectivity and Bearer activation from continue ongoing
drop incoming to continue ongoing continue incoming. So, MME will finish PDN connectivity procedure
and then start to handle bearer activation. The incoming Create Bearer Request will not be dropped.

Risk analysis of the correction:


- None

2.24 NS16.50587 Some Logs were enabled in MMDU without checking the logging level

PR146847 Logging in SS_LNXmmeSubsHandler without checking trace log enable

Summary of the original problem:


- In MMDU, some logs were always enabled without checking the logging level.

How end user/operator could detect the problem:


- Operator could see in MMDU internal logs some logs printed always despite the enabled log level. This
could have also a potential increase in CPU utilization of MMDU.

Description of the fault:


- Some MMDU logs were printed always because there was not a log level check or there was an
erroneous log level check.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 37/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.7-0
- LNX922G2.IMG 11.4-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Checks are implemented in MMDU so that logs are printed properly depending on the log level.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.25 NS16.50588 MME not responding to some CMAS Write-Replace-Warning Requests

NA05953177 MME not responding to some Write-Replace-Warning-Request sent by CMAS

Summary of the original problem:


- MME did not always respond to CBC (Cell Broadcasting Centre) messages.

How end user/operator could detect the problem:


- CBC was sending Write-Replace Warning Request to MME but MME was not always sending a
response back.

Description of the fault:


- SBcHandler did not apply the configuration parameters from INI file
(DW0/ACTIVESWDIRECTORY/ASWDIR/FNSINI/LNX985NX.INI) for inbound / outbound streams
(MaxInboundStreams, OutboundStreams).
- Furthermore, SBcHandler replied using the Streamed received from the message from CBC. But this
Streamid was not valid to be used for the outbound message to CBC.
As a result, SCTP_SENDMSG failed with "error 22 = Invalid Argument". Streamid that was used was not
valid.

Dependency on configuration:
- None

Faulty component and version:


- LNX985G2.IMG 9.3-0

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 38/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component first delivered in(e.g. release, CD):
- NS30

Workaround:
- None

Description of the correction:


- SBcHandler will respond to CBC using Streamid 0.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

2.26 NS16.50589 Sv interface - MSC peer table timeout

NA05939697 Sv interface - MSC peer table timeout

Description of the problem:


- Every time that a MSS was set to BL-US (blocked-BLU) mode, GTPLBS deleted it from its internal
table. However, when it was changed back to Normal (NOR) or Default (DEF), GTPLBS was not adding it
back to its table. This way MME was not able to monitor the connection towards this MSS.
Furthermore, this led to an empty MSS table when (at some point) all MSS-es mode had been changed
to BL-US. In addition, on restart or switchover GTPLBS stored in its table both Blocked and
Normal/Default MSS, while it was expected to store only Normal or Default.

How end user/operator could detect the problem:


- If mode of MSS was changed to BL-US and back to NOR or DEF, ECHO requests stopped being
triggered towards this MSS. Also, if at some point all MSS-es asynchronously changed mode to BL-US
mode and then back to Normal or Default, MML interrogation for MSS configuration status (ZBIR:INT;)
caused a timeout issue.

Description of the fault:


- When a MSS changed mode from BL-US back to NOR or DEF, GTPLBS was not adding it back to its
table.

Dependency on configuration:
- The timeout issue/output was detected when prfile 2248 "MME_SV_BLACKLISTING" was enabled,
however faulty mechanism existed independently of the configuration.

Description if problem based on certain configuration:


- When prfile 2248 "MME_SV_BLACKLISTING" Sv blacklisting is enabled, GPU sends a message to
GTPLBS to provide the output of the MML command ZBIR (ZBIR:INT;).

Workaround:
- IPDU switchover of the first IPDU pair (IPDU-0/1). This way GTPLBS calculates again its internal table.
Therefore, the table is not empty and contains the correct information.
- Instead of changing the MSS mode to BL-US, use MML to delete or add MSS in the Sv interface
functionality (ZBIR).

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 39/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- LNX968G2.IMG 8.28-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Description of the correction:


- When mode of MSS changes from BL-US to NOR or DEF it is added to MSS table.
When there is a restart or switchover in IPDU, blocked MSS is not added to MSS table.
This way GTPLBS will never be empty as there is always a default MSS. Also, MME will monitor all MSS-
es in non-blocked mode.

Risk analysis of the correction:


- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Sv Blacklisting feature/prfile enabled.

2.27 NS16.50590 NAS sequence number (NAS#35) issue after s1 release by inactivity timer

NA05956786 NAS sequence number (NAS#35) issue after s1 release by inactivity timer

Summary of the original problem:


- While paging procedure was ongoing, UE triggered S1 Release. The ERAB ReleaseCommand
message received by eNB included wrong Sequence Number.

How end user/operator could detect the problem:


- Operator would see two consecutive NAS/S1 messages having the same Sequence Number

Description of the fault:


- During collision between Paging procedure and S1 Release procedure, TrHandler informed
SubsHandler about the current downlink and uplink NAS count, but SubsHandler did not update the
subscriber in database.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.238-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Changes were implemented, so as to update the subscriber with NAS count in case of collision between
Paging and S1 Release procedure.

Risk analysis of the correction:


- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 40/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

2.28 NS16.50591 MML command error

PR172065 NS17_NSHW16_8hrun_MML_command_error

Summary of the original problem:


- When executing ZBAO:PURGE MML command, the output had a typo mistake:
PURGEING was printed instead of PURGING.

How end user/operator could detect the problem:


- By executing ZBAO:PURGE MML command, and then noticing that the output had a typo mistake:
PURGEING instead of PURGING.

Description of the fault:


- When executing ZBAO:PURGE MML command, the output had a typo mistake:
PURGEING was printed and not PURGING, which is the correct spelling.

Dependency on configuration:
- None

Faulty component and version:


- AUBHANJX.PAC 2.3-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Correct the typo.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 41/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.29 NS16.50592 MME was sending unauthenticatedIMSI flag as true in Indication Flags IE in
Create Session Request for subscriber attached with IMEI

PR156436 NS17-CI27:unauthenticatedIMSI indication flag is set to true in CSR with Prose PR


file is on

Summary of the original problem:


- For the subscriber that has done IMEI attach, MME was setting unauthenticatedIMSI flag as true in
Create Session Request when 2376(PROSE_AUTHORIZATION) PrFile was on.

How end user/operator could detect the problem:


- For the IMEI attached subscriber, operator would be able to see in pcap that MME sends
unauthenticatedIMSI flag as true in Indication Flags IE in Create Session Request when
2376(PROSE_AUTHORIZATION) PrFile is on.

Dependency on configuration:
- 2376(PROSE_AUTHORIZATION) PrFile should be enabled.

Faulty component and version:


- LNX934G2.IMG 11.67-0

Workaround:
- None

Description of the correction:


- When Subscriber Performs IMEI Attach and if 2376(PROSE_AUTHORIZATION) is on then
unauthenticatedIMSI flag will be false in Indication Flags IE in Create Session Request message.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Attach with IMEI
- S1 Release
- Tau with SGW Relocation

2.30 NS16.50593 MME did not trigger PDN re-establishment after inter MME TAU with SGW change

NA05938360 (Flexi NS)PDN re-establish failed

Summary of the original problem:


- MME did not trigger PDN re-establishment after inter MME TAU with SGW change.
How end user/operator could detect the problem:
- During inter MME TAU with SGW change, the source MME sent Context Response message with the
SGW FQDN and PGW FQDN in upper case.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 42/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the fault:
- The MME did not handle some special FQDNs in upper case correctly.

Dependency on configuration:
- FC085_003052 PDN re-establishment after SGW change feature must be enable.

Faulty component and version:


- LNX934G2.IMG 11.1-0
- LNXA9BG2.IMG 5.1-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- Make all FQDNs in Context Response message to be in lower case.

Description of the correction:


- Parse and treat FQDNs in Context Response message case-insensitive.

Risk analysis of the correction:


- None

Correction effects:
- MME will handle upper case FQDNs in Context Response message correctly.

2.31 NS16.50594 LG K7 MPCS handset models were causing EPC initiated drop loops for IMS
default bearer.

NA05955170 LG K7 MPCS handset models causing EPC initiated drop loops for IMS default
bearer.

Summary of the original problem:


- DB was not properly updated if UE did not respond to E-RAB Release Command.

How end user/operator could detect the problem:


- If UE did not respond to E-RAB Release Command and max retries reached, then operator could
observe the deactivated bearer with proper MML command as not deactivated.

Description of the fault:


- After max retries reached, trHandler did not send the proper message to subsHandler so DB was not
updated for the deactivated bearer.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG, 11.13-42

Faulty component first delivered in(e.g. release, CD):


- NS16.5

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 43/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- Proper message is sent from trHandler to subsHandler with cause "UE not respond"
to update the DB with the correct status of bearer. Also, if timer expires in subsHandler due to e.g. CPPU
restart, the bearer status is updated on timer expiration.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- KPIs improvement

Test requirements:
- None

2.32 NS16.50595 3689 alarm was not cancelled in MMDU after recovery action

PR171036 3689 alarm not cancelled if DBHandler restarts

Summary of the original problem:


- Alarm 3689 was not reset although both DBHandler and the database had been restarted successfully.

How end user/operator could detect the problem:


- Alarm 3689 was not cancelled after 1007 disturbance was raised for processes 93D and 930.

Description of the fault:


- On DBHandler initialization, the database was unresponsive. As result, 3689 alarm was raised and after
the 5 min timeout, both DBHandler and HAC were restarted as a recovery action. After the restart, the
initialization was successful, however the alarm was not cleared. DBHandler keeps local variables for
remembering that an alarm was raised. Since the process was restarted, the variables were initialized to
false, hence the check for resetting the alarm was evaluated to false.

Dependency on configuration:
- None

Faulty component and version:


- LNX93DG2.IMG 11.3-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- In the DBHnadler initialization phase alarm 3689 is reset once the database is operational.

Risk analysis of the correction:


- None

Correction effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 44/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.33 NS16.50596 MME sends wrong APN selection mode value for Emergency PDN in CSR during
Intra-mme S1/X2 HO with SGW change

PR151039 Incorrect Selection mode Value for Emergency PDN in CSR during Intramme
S1/X2 HO with SGW change

Summary of the original problem:


- MME was not sending correct APN selection mode in Create Session Request.

Description of the problem:


- During Intra MME s1/x2 HO MME was sending wrong APN selection mode in Create Session request.

Description of the fault:


- MME was filling hard coded value
MS_OR_NETWORK_PROVIDED_APN_AND_SUBSCRIBED_VERIFIED (0) in Create Session request

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 7.229-1 and LNX934G2.IMG 7.238-2

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- With the correction MME sends correct APN selection mode in Create Session Request.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- Correct Selection mode value is included in Create Session Request.

Customer effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 45/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Test requirements:
- Attach with Emergency PDN.
- Perform Intra-mme S1/X2 HO with SGW change
- MME send CreateSessionRequest with correct Selection Mode

2.34 NS16.50597 ( Flexi NS-MME ) VoLTE video cross vendor switching failure

NA05918207 ( Flexi NS-MME) VoLTE video cross vendor switching failure

Summary of the original problem:


- VoLTE video cross vendor switching failure due to create session reject by GW.

How end user/operator could detect the problem:


- UE performs a normal attach, then the PGW triggers a dedicated bearer activation (two dedicated
bearers with different PGW_TEID_U), then UE performs an inter-MME handover. This fails because the
create session is rejected in target side.

Description of the fault:


- MME stores the PGW_TEID_U as the same for all bearers even if the PGW_TEID_U is different for
each bearer in Create Bearer Request.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.140.1.6-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- MME will store PGW_TEID_U for each bearer and the value should be taken from the Create Bearer
Request.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 46/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.35 NS16.50598 MME locate failure accidentally

NA05927910 'VoLTE 100day campaign'(FLexi NS MME NS316)MME

Summary of the original problem:


- In the process of UE Circuit-switched fallback(CSFB), the emergency Gateway Mobile Location Center
(EGMLC) sent a Provide-Location-Request (PLR) with location type
"CURRENT_OR_LAST_KNOWN_LOCATION (1)" to MME. The MME could not page the UE
successfully and replied with a Provide-Location-Answer (PLA) message with Result-Code "success",
however there was no location estimate data in PLA.

Description of the problem


- In the process of UE CSFB,EGMLC did sent a PLR with location type
"CURRENT_OR_LAST_KNOWN_LOCATION (1)" to MME, the MME could not page the UE successfully
and replied with PLA message with Result-Code "success" , however there was no location estimate data
in PLA.

Description of the fault:


- MME responded with PLA message to GMLC with Result code 2001 to indicate success directly

Related feature / functionality:


- None

Dependency on configuration:
- sls, slg interface configured.

Workaround:
- None

Description of the correction:


- Configure message LOC_EST_TYPE_T_CURR_LST_KNWN as 1 via CLI. Then MME responds PLA to
GMLC with Experimental-Result code 4221 to indicate failure directly when paging fails for PLR with
location type CURRENT_OR_LAST_KNOWN_LOCATION (1).

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 8.71-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 47/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.36 NS16.50599 Relocation failure due to additional RAB added

NA05917971 Relocation failure due to additional RAB added

Summary of the original problem:


- During inter-SGSN SRNS relocation (from DX-SG8 CD6.1 to FNS4.0 CD 2.0), the target RNC cancels
the relocation and replies with cause "unable to establish during relocation".

How end user/operator could detect the problem:


- Via tracing internal and external logs of the relocation scenario.

Description of the fault:


- On Inter-SGSN relocation procedure, GSP receives signal for relocation command from GMG. After
receiving this signal GSP prepares RANAP message "Relocation Command" in order to send it to
SORPRO. However, due to RANAP error, (which is printed in this scenario), there is an indication that an
encoding error is detected. As a result SGSN does not send "Relocation Command" to source RNC. The
reason that Inter-SGSN Relocation procedure failed is due to encoding error which is related to wrong
construction on behalf of GSP of RAB list received from GMG, in order to send it to SORPRO.

Dependency on configuration:
- None

Faulty component and version:


- GSP_G6JX.PAC 10.7-0

Faulty component first delivered in(e.g. release, CD):


- SG7

Workaround:
- None

Description of the correction:


- On GSP prb, on the encoding procedure of Rab list of relocation command message that is sent to
SORPRO, all available Rabs will be included.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 48/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.37 NS16.50600 KPI drop after both MMDUs of a pair were put to SE-NH state

NA05906039 LASGSN14 - Database error in GSBASE

Summary of the original problem:


- One pair of MMDUs failed in a SA SGSN configuration and db_errors were reported in SMMUs. The
failing MMDUs were put to SE-NH state but the db_errors in SMMUs persisted.

How end user/operator could detect the problem:


- Notice 0004 ACCESS SERVICE REJECT RATE LIMIT EXCEEDED were raised for SMMUs, as well as
db_errors.

Description of the fault:


- GRN PRB that resides in SMMU uses an internal table for mapping subscriber IMSIs to MMDUs serving
them. SMMUs were informed when MMDUs went down, however when request for a subscriber that was
served by a faulty MMDU arrived in SMMU, it would look up the subscriber in the aforementioned table
and would return an MMDU in SE-NH state. Since SMMU knew that MMDU is in SE-NH state, it tried to
find the subscribers in the WO-EX MMDUs but they were not available as they were not stored there. In
addition, there was no logic for redirecting the subscribers to the WO-EX MMDU pair and as a result, the
subscribers served by the faulty MMDUs requests kept getting db_error responses.

Dependency on configuration:
- SA SGSN and TA MME.

Faulty component and version:


- GSL_GXNX.PAC 5.2-0

Faulty component first delivered in(e.g. release, CD):


- Legacy product, cannot be identified.

Workaround:
- None

Description of the correction:


- Once a request arrives in SMMU concerning a subscriber that was mapped to a faulty MMDU, the stale
entry is removed from SMMU's internal table. This way once the subscriber re-attaches, she is forwarded
to a WO-EX MMDU.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 49/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.38 NS16.50601 Collision due to PDN Connectivity

NA05919202 Collision due to PDN Connectivity

Summary of the original problem:


- During Inter-System TAU with 2 PDNs (ebi5 and ebi6) and qos throttling, collision happened when PDN
disconnection (ebi 6) was performed.

How end user/operator could detect the problem:


- By performing Inter System TAU and UE-initiated PDN disconnection.

Description of the fault:


- During Inter-System TAU with 2 PDNs (ebi5 and ebi6) and qos throttling, collision happened when PDN
disconnection (ebi 6) was performed as request message came before TAU complete message. As a
result, the MME dropped the incoming PDN disconnection procedure.

Related feature / functionality:


- Inter-system TAU and QoS throttling.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- The MME will first complete ongoing Inter-System TAU and then continue with incoming PDN
disconnection procedure and then with qos throttling if existed in previous Inter-System TAU.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- PDN disconnection KPI was dropped. Furthermore, the MME was initiating QoS throttling for the PDN
connection where the UE had already sent PDN disconnection. Hence, this procedure hung as the UE
did not response. This caused QoS modification KPI drop.

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 12.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 50/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.39 NS16.50602 ( Flexi NS MME )TAL (TaiList) and TAI (LastVisitedTAI) information is incorrect in
LIC event log

NA05918928 ( Flexi NS MME )TAL (TaiList) and TAI (LastVisitedTAI) information is incorrect
in LIC event log

Summary of the original problem:


- TAL (TaiList) information is incorrect in LIC event log.

How end user/operator could detect the problem:


- TAL field is omitted in China Li X2 active event report(Detach).

Description of the fault:


- After network initiated Detach, MME deleted subscriber data from database, hence TaiList information is
incorrect in China li detach event report.

Dependency on configuration:
- The feature China LI for MME (5347) is enabled.

Faulty component and version:


- LNX93FG2.IMG 7.2-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP1

Workaround:
- None

Description of the correction:


- Get TaiList from MM report if subscriber cannot be found in database.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- The feature China LI for MME (5347) is enabled.
- MME didn't configure TaiList.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 51/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.40 NS16.50603 Internal UDP packet towards CPPU sent from IPDU's external interface with
Gn/S11/S10 IP

NA05926379 Internal UDP packet sent on external interface with Gn/S11/S10 IP

Summary of the original problem:


- UDP packets are sent from IPDU's external IP of S11 interface, towards CPPU's internal IP.

How end user/operator could detect the problem:


- The issue could be detected by examining IPDU's pcap trace, and checking that UDP packets sent from
IPDU's external S11 interface to CPPU's internal interface. Also, there is an ICMP packet for each
aforementioned UDP packet coming from the router with error message Destination network
unreachable.

Description of the fault:


- In case of receiving Echo Request from SGWs, LNX968 in IPDU tried to send SGW's blacklist status to
CPPUs over UDP but used wrongly the external interface instead of the internal one.

Dependency on configuration:
- None

Faulty component and version:


- LNX968G2.IMG 11.4

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Use the right IPDU's internal interface towards CPPU to send the UDP packet regarding SGW
blacklisting status.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 52/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.41 NS16.50604 MME performs unnecessary IMEI check in IS TAU procedure during '4g Attach -
IS RAU - IS TAU'

NA05929166 IMEI parameters in MME S13 Diameter

Summary of the original problem:


- During '4g Attach - IS RAU - IS TAU' scenario, MME performed again IMEI check in IS TAU procedure
even though it has been already performed during 4g Attach.

How end user/operator could detect the problem:


- Unnecessary IMEI checks in IS TAU in Wireshark log. Thus, unnecessary signalling observed in IS
RAU -IS TAU.

Description of the fault:


- The problem occurred with 2 different configurations:
1.Imei check completely OFF in SGSN
In this case, during RAU, SGSN overwrote the IMEI value to FFFFFFF and thus MME found that the IMEI
has changed and performed IMEI check again in IS TAU.

2.Imei check ON in SGSN but not for RAU procedures.


In this case, MME set the imei_status of the subscriber as whitelisted in IS RAU and then SGSN set it to
not_done instead of whitelisted. For this reason, MME, initiated IMEI check again in IS TAU.
Also, even if SGSN have send the correct imei and imei status, MME does not retrieve the values stored
in DB, so they IMEI and IMEI_STATUS contain the default values. MME have never retrieved the values
that SGSN stored previously.

Dependency on configuration:
- Imei check completely OFF in SGSN.
- Imei check was ON in SGSN but not for RAU procedures.

Faulty component and version:


- LNX934G2.IMG 11.62-0
- GRN_GSJX 20.21-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Correction given for both possible configurations in SGSN side:
1. GRN PRB overwrites the IMEI value in case the new received IMEI is not unknown.
2. When GRN PRB receives 'reg_check_imei_req_s' message, it sets the imei_status to not_done in
case its previous value is unknown.
3. MMSM retrieves correctly the updated IMEI and IMEI_STATUS that got from SGSN.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Customer will not see unnecessary IMEI CHECK during 4G Attach - IS RAU - IS TAU.
Also, traffic will be reduced as unnecessary imei check will not be performed.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 53/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Test requirements:
1.Imei check is completely OFF in SGSN
IMEI CHECK MODE...................................(ICHM) OFF
IMEI REQUEST MODE.................................(IRM) OFF
UE performs 4G Attach-IS RAU-IS TAU
Results: IMEI CHECK not occurred during IS TAU

2. Imei check is ON in SGSN but not for RAU procedures


UE performs 4G Attach-IS RAU-IS TAU.
Results: IMEI CHECK not occurred during IS TAU.

2.42 NS16.50605 The M51 measurement includes the TAI-0 and TAI-65535 while the enodeb does
not have these TAI values

NA05938817 The measurement include the TAI-0 and TAI--65535 items even the enodeb do
not have these TAI

Summary of the original problem:


- The M51 measurement includes the TAI-0 and TAI-65535.
But the enodeB does not have this kind of TAI.

How end user/operator could detect the problem:


- The M51 measurement includes the TAI-0 and TAI-65535.

Description of the fault:


- Tai List initialized with 0xFF, hence if procedure get Tai List failed, the initialized value was recorded in
measurement file.

Related feature / functionality:


- Measurement function

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Code is added to check for invalid TAC and exclude the TAC 0 and 0xFFFE when the counter
increased because the TAC-0000 and TAC-FFFE values are reserved for special cases in MS.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 54/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 8.10-0, GST_GMJX.PAC too legacy to be specified

Faulty component first delivered in(e.g. release, CD):


- NS 16

2.43 NS16.50606 Alarm 2101 MME UNIT FAILURE due to memory leak in S1Handler

NA05944741 S1 handler memory leak caused OoM CPPU restart

Summary of the original problem:


- Memory leak in S1Handler.

How end user/operator could detect the problem:


- Alarms 2381 AMOUNT OF FREE MEMORY CRITICALLY REDUCED and 2101 MME UNIT FAILURE
were raised from CPPU. CPPUs were restarted after the free memory of unit was exceeded.

Description of the fault:


- Flow Controller of S1Handler leaks messages in case of large gaps. Large messages gaps are a result
of high CPU usage on the unit in general.

Dependency on configuration:
- None

Faulty component and version:


- LNX925G2.IMG (version to older to be specified).

Faulty component first delivered in(e.g. release, CD):


- NS30

Workaround:
- None

Description of the correction:


- Improvement of S1Handler Flow Controller. Change the cyclic message buffer that leaks messages in
case of large gaps with a dynamic ordered set.

Risk analysis of the correction:


- Solution is based on the capacity figures of "Flexi NS System Capacity" chapter "3.1 MME system
capacity figures". Correction is working as expected.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- High CPU usage of CPPU units (perhaps OLC scenarios etc.).

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 55/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.44 NS16.50607 Roaming partner has ESM failures

NA05962653 Roaming partner has ESM failures

Summary of the original problem:


- When the VoLTE roaming feature (FC085_002933_Roaming Control for IMS APN and VoLTE) is on,
roaming subscribers on partner network, experience attach failure with Cause: ESM failure (19) and PDN
Connectivity reject with Cause: Missing or unknown APN.

How end user/operator could detect the problem:


- Attach procedure fails with ESM failure cause and PDN Connectivity procedure is rejected with cause
Missing or unknown APN.

Description of the fault:


- APN-Configuration AVP is not decoded correctly by MME.

Dependency on configuration:
- None

Faulty component and version:


- LNX938G2.IMG 12.3-0

Faulty component first delivered in(e.g. release, CD):


- NS30

Workaround:
- Unsupported AVPs after supported AVPs with multiple instances shall be avoided to be sent from HSS.

Description of the correction:


- When multiple instances of the same AVP are present, retrieve the total length instead of the length of
the last instance.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 56/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.45 NS16.50608 For Emergency PDN Connectivity Failures, the internal/external cause code sets
are incorrect

NA05975155 cause code is inconsistent between in the CPPU and the corresponding traffica
report.

NA05975937 For Emergency PDN Connectivity Failures, the internal/external cause code set
are incorrect

Summary of the original problem:


- The UE initiated PDN Connectivity procedure for Emergency Pdn was failing with erroneous ESM cause
in PdnConnectivityReject message.

How end user/operator could detect the problem:


- The UE initiated PdnConnectivityRequest message for Emergency PDN was rejected with ESM cause
= 34 (SERVICE OPTION TEMPORARILY OUT OF ORDER) instead of ESM cause=32 (SERVICE
OPTION NOT SUPPORTED).

Description of the fault:


- In case that the UE initiated Pdn Connectivity procedure (Emergency and non-Emergency alike) is
rejected because the MME gets a GTP cause equal to REFERRED_PDN_TYPE_NOT_SUPPORTED in
CreateSessionResponse message from the GW, then the external/ESM cause included in
PdnConnectivityReject message and the respective internal cause, should be:
- for UE Requested PDN Type = IPv4: external/ESM cause=51 (PDN TYPE IPV6 ONLY ALLOWED) &
internal cause=126
- for UE Requested PDN Type = IPv6: external/ESM cause=50 (PDN TYPE IPV4 ONLY ALLOWED) &
internal cause=125
- for UE Requested PDN Type = IPv4v6: external/ESM cause=32 (
SERVICE OPTION NOT SUPPORTED) & internal cause=178
Instead of this, in case of Emergency Pdn Request for all IPv4/IPv6/IPv4v6 types, the following causes
were exposed: external/ESM cause=34 (SERVICE OPTION TEMPORARILY OUT OF ORDER) &
internal cause=128.
According to the 3GPP specification, if the UE gets ESM cause=34, then the UE may retry with
PdnConnectivityRequest with same APN & PDN type and in turn the Operator may also get a KPI drop.
While if the UE gets the ESM cause #50 or #51, it shall not automatically send another
PdnConnectivityRequest message (e.g. it may register to a new PLMN or the PDN type which was used
may change).

Dependency on configuration:
- The error occurred only in case that the PDN type in the UE initiated PdnConnectivityRequest message
was not supported by the MME or by the GW.

Faulty component and version:


- LNX924G2.IMG 11.100-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- In case of Emergency UE initiated PdnConnectivityRequest message that was rejected with GTP cause
'PREFERRED_PDN_TYPE_NOT_SUPPORTED' by the GW the correct internal/external causes were
initially assigned (equal to the non-Emergency case) and those were overwritten later during the
execution. With the correction, the initial cause values are not overwritten.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 57/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- The correct ESM cause is returned with PdnConnectivityReject.

Test requirements:
1. The UE is configured to send emergency Pdn requests with Pdn type e.g. IPv4v6.
2. The MME is configured to support only e.g. IPv4.
3. The GW is configured to support only e.g. IPv6.
4. The test scenario is: EPS Attach (non-emergency). The UE initiates a PdnConnectivityRequest for
Emergency Pdn. (The CreateSessionRequest message is send to the GW with Pdn type = IPv4. The
CreateSessionResponse is send to the MME with cause
PREFERRED_PDN_TYPE_NOT_SUPPORTED.)
5. Expected result:
PdnConnectivityReject towards the UE with ESM cause 32 (SERVICE OPTION NOT SUPPORTED)
6. Non-expected result:
PdnConnectivityReject towards the UE with ESM cause 34 (SERVICE OPTION TEMPORARILY OUT OF
ORDER)

2.46 NS16.50609 Dns Resolving Unsuccessful alarm(0095) flooding and map clearing

PR153396 Dns Resolving Unsuccessful alarm(0095) flooding and map clearing

Summary of the original problem:


- The same failed DNS query could raise the alarm again and again, flooding the alarm history. After fix
for NA05907970 in NS16_5 the alarm is raised once per CPPU and cannot be raised again for the same
fqdn and error code.

How end user/operator could detect the problem:


- The problem can be detected by not configuring the FQDN in the DNS server and if MME does DNS
query for the unconfigured FQDN, DNS RESOLVING UNSCCESSFUL alarm will be raised as many
number of DNS query attempts. The fault after fix for NA05907970 could not be detected.

Description of the fault:


- The original problem was that DNS resolving unsuccessful alarm could be raised again and again for
the same pair of error code and fqdn. After correction of NA05907970 the DNS resolving unsuccessful
alarm (0095), once raised by a CPPU for a pair of fqdn and error code it was permanently stored and the
alarm could not be raised again for the same pair by the same CPPU.

Dependency on configuration:
- Missing configuration from external DNS server

Faulty component and version:


- LNX922G2.IMG 11.4-0
- LNXA9BG2.IMG 5.4-0

Faulty component first delivered in(e.g. release, CD):


- NS40

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 58/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
- None

Description of the correction:


- The problem of DNS resolving Unsuccessful flooding the alarm history can be avoided by keeping the
pair of fqdn and error code in a map and raising the alarm once per day per CPPU for each pair of fqdn
and error code.

Risk analysis of the correction:


- None

Correction effects:
- The same failed DNS query will raise the alarm only once per day per CPPU. Also, the operator can
clear the map that keeps the FQDNs for which the alarm is raised through the day with following cli
command on CPPU:
cli dns clearalarmmap. That is if the operator wants to see a problematic FQDN to raise the alarm again
within the same day,

Interface effects:
- None

Customer effects:
- No flooding of the alarm history

Test requirements:
- FQDN should not be configured in external DNS server for which DNS query will be done by MME.

2.47 NS16.50610 IESIEU: Create logical file for upglog failed

PR161042 IESIEU: Create logical file for upglog failed

Summary of the original problem:


- IES prints Test logs sometimes.

How end user/operator could detect the problem:


- Irreproducible problem.

Description of the fault:


- IES prints Test logs sometimes.

Dependency on configuration:
- None

Faulty component and version:


- IESPRBGX.PAC 2.31-0

Faulty component first delivered in(e.g. release, CD):


- Y2 16.57-0

Workaround:
- None

Description of the correction:


- Change Test logs to Info logs.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 59/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.48 NS16.50611 The IPMC version is not correct after updating the eSW.

PR166698 The IPMC version is not correct after update the eSW of ACPI4- A/B blade.

Summary of the original problem:


- The minor version of some IPMC is incompatible with disk version.

How end user/operator could detect the problem:


- Execute ZD8I command to inquire IPMC version.

Description of the fault:


- The minor version of some IPMC is incompatible with disk version.

Dependency on configuration:
- None

Faulty component and version:


- EUMANAGX.PAC 1.25-0

Faulty component first delivered in(e.g. release, CD):


- Y2 17.15-10

Workaround:
- None

Description of the correction:


- Convert hardware minor version to disk version.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 60/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.49 NS16.50612 CDR Data volume mismatch between CDRs reported from SGSN & GGSN

NA05916304 SGSN Volume mismatch in S CDR & SA CDR in all EAST SGSN

Summary of the original problem:


- Based on customer's report and log files, there is a mismatch on CDR volume reported between SGSN
and GGSN.

How end user/operator could detect the problem:


- Via tracing internal and external log files as well as CMD reports.

Description of the fault:


- More thoroughly, a GGSN initiated "update pdp context" loop is triggered with no modification on QoS
which although leads to a forwarding of pdp modification notifications to the charging process of an active
PDP context. In terms of this procedure, for prepaid subscribers on S4S prb, there is a mechanism which
fetches data volumes and calculates the total uplink and downlink data volume. Even though there is no
modification on PDP, it is an originally abnormal behaviour on behalf of gateway, SGSN used to
summarize data volumes received and as result such a mismatch on the final S-CDRs is observed. Also,
due to this calculation the upper limit of data volume (UL/DL) is reached and CDR is closed and
forwarded to A4S to be written.

Dependency on configuration:
- None

Faulty component and version:


- S4S_GMJX.PAC 4.49-0

Faulty component first delivered in(e.g. release, CD):


- SG7

Workaround:
- None

Description of the correction:


- A defensive mechanism was implemented in terms of data volume calculation on S4S for such
abnormal update PDP context loops initiated by GGSN, so as not to summarize them when there are no
PDP modifications as well as volume data changes.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 61/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.50 NS16.50613 LNXAA0G2 IFMonitor Improve the TRepeat timer implementation

NA05922776 (Flexi_NS MME NS16MP0.1)MME appear a large number of 2101 "MME UNIT
FAILURE" alarms after upgrade to NS16MP0.1

PR177848 LNXAA0G2 IFMonitor Improve the TRepeat timer implementation

Summary of the original problem:


- LNXAA0G2 IFMonitor Improve the TRepeat timer implementation.

Description of the problem:


- LNXAA0G2 IFMonitor Improve the TRepeat timer implementation.

How end user/operator could detect the problem:


- IFMonitor system logs shows the TRepeat timer expires longer than expected time when issue is
observed.

Description how problem can be detected:


- IFMonitor system logs shows the TRepeat timer expires longer than expected time when issue is
observed.

Description of the fault:


- LNXAA0G2 IFMonitor Improve the TRepeat timer implementation.

Dependency on configuration:
- None

Faulty component and version:


- LNXAA0G2 6.8-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Use C++ instead of java for IFMonitor. C++ provide reliable timer scheduling.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- No 2101 alarms will be raised when the TRepeat timer expires with the configured value.

Test requirements:
- No 2101 alarms should be raised due to delay in expiration of the TRepeat timer.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 62/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.51 NS16.50614 Wrong APN was sent by MME in Create Session Request message to GW

NA05956048 (Flexi NS-MME NS16.5)MME was wrong to create session by apn "CMIOT"

NA05958335 MME override APN wrongly

Summary of the original problem:


- Wrong APN was sent by MME in Create Session Request message to GW.

How end user/operator could detect the problem:


- When the system was loaded with many attach requests, an increase in Attach failures was observed
due to the fact that the requested APN, was not included in the subscribers’ subscription data.

Description of the fault:


- The problem was that if a subscriber did not request during Attach or PDN Connection to be connected
to a certain APN, then the APN that MME might choose to provide to the UE, might be an APN that was
not included at subscriber's subscription data. More specifically, MME would provide wrongly, the default
APN of another subscriber's data.

Dependency on configuration:
- For the issue to be revealed feature should be activated. (Prfile Parameters: 2051, 2250, 2050) and
load of attach requests and PDN Connectivity requests should be applied to MME. The issue will be
revealed if range of default APNs is used at subscription data for different subscribers.

Faulty component and version:


- LNX934G2.IMG 11.117-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Default APN value is not overwritten when new subscriber tries to Attach or create a PDN Connection.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 63/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.52 NS16.50615 Empty ULI

NA05932852 Empty ULI

Summary of the original problem:


- ULI in delete session request was empty after inter system TAU failed.

How end user/operator could detect the problem:


- Perform inter system TAU with eNB sending initial context setup failure.

Description of the fault:


- CPPU tries to get TAU request with an error message number which was wrong and so, TAI and ECGI
in ULI of delete session request were set to NULL and SGW was getting a GTP message with invalid
length.

Dependency on configuration:
- Gn interface should be configured in order to communicate with SGSN.

Faulty component and version:


- LNX924G2.IMG 11.40-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- CPPU tries to get TAU request with an error message number which is now corrected. TAI and ECGI in
ULI of delete session request are set to the correct value without NULL and SGW does not get a GTP
message with invalid length.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.53 NS16.50616 When Dual Stack was activated on HLR, APN override stopped working

NA05943488 When Dual Stack was activated on HLR, APN override stopped working

Summary of the original problem:


- After HLR modifications, where Dual Stack subscription was activated on HLR (the subscription only
contains IPv4v6 records) and SGSN used GNI or GNIv6 (some SGSNs have SECGNI SECGNIv6) for
APN Override functionality, it is observed that APN override feature has stopped working for UEs
requesting IPv4 or IPv6 and providing incorrect APN.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 64/231
D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- Through Wireshark tracers, UEs request IPv4 or IPv6 PDP Address Type and provide incorrect APN
through PDP Context Activation Request message, it is observed that these requests are rejected, when
the APN Override Feature is enabled.

Description of the fault:


- After customer's modification on HLR configuration to send extPDPtype IPv4v6 subscription information
to the SGSN (in preparation for an Apple IOS upgrade which has iphones start using dual stack
PDPcontext/PDN connections), it is actually noticed that APN override feature has stopped working for
UEs requesting IPv4 or IPv6 and providing an incorrect APN. That seems to affect a sizable
subscriber/UE population (~5%) which do not get service any more. SGSN used GNI or GNIv6 (some
SGSNs have SECGNI SECGNIv6) for APN Override functionality and then looks for a suitable PDP type
in the subscription records. The request is either IPv4 or IPv6 while the subscription only contains IPv4v6
records. SGSN does not find a suitable type and rejects the request without triggering APN Override
mechanism. This would not be an expected behavior, as dual stack subscription includes individual PDP
type requests as per spec.

Dependency on configuration:
- SGSN Dual stack PDP context support: FEA=3205: OFF
- SGSN Override of requested APN: FEA=372: ON
- APN Conversion and Correction: FEA=5336:ON
- PRFILE parameter DUAL_STACK_PDP_CTXT: 002:1940,0;
- PRFILE parameter OVERRIDE_ROAMING_APN: 002:1042,0;
- PRFILE parameter ENFORCE_SUBSCRIBED_APN:002,1043,1;
- PRFILE parameter APN_WITH_LOWEST_PDP_ID: 002,1797,0;
- GNI and GNIv6 only set
- Wildcard APN in subscription: Does not exist
- Home Subscriber

Faulty component and version:


- GMG_G6JX.PAC 30.114-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- In case requested PDP type is IPv4, the respective subscription should include an IPv4 record as a last
record (if it does not already exist).
- In case requested PDP type is IPv6, the respective subscription should include an IPv6 record as a last
record (if it does not already exist).
- In such cases no failures will occur anymore and the selected record from HLR will be the 1st suitable
each time. For example, when IPv4 is the requested type and the 1st subscription is type IPv4v6 this is
considered to be the 1st suitable record and it will be selected. PDP will then be created with IPv4 part of
the IPv4v6 address.

Description of the correction:


- After correction, customer's modification on HLR configuration to send extPDPtype IPv4v6 subscription
information to the SGSN, it will not affect the APN Override Functionality. When UEs request PDP
Address Type IPv4 or IPv6 with incorrect APN, SGSN uses GNI or GNIv6 (some SGSNs have SECGNI
SECGNIv6) based on missing APN Override functionality and looks for a suitable PDP type in the
subscription records, which could be either IPv4/IPv6 or IPv4v6 records. Subsequently, SGSN finds
suitable record and PDP Context Activation is successful independently of HLR subscription, through
APN Override functionality.

Risk analysis of the correction:


- None

Correction effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 65/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.54 NS16.50617 MME was not responding to the Downlink Data Notification message from the
SGW

NA05942190 MME is not responding to the Downlink Data Notification message from the
SGW

Summary of the original problem:


- When doing volte TAI-list level paging, MME updates the last updated TAI to current TAI list.
If current used TAI list is configured with 16 different TACs and the last updated TAI is not the same as
them, there was no room for the new TAI to be saved and so IndexOutOfBoundsException was caused.
This had as result the MME not to send Paging request message to ENB and finally MME not to respond
to Downlink Data Notification message.

How end user/operator could detect the problem:


- If the above described preconditions were met then MME did not respond to Downlink Data Notification
message.

Description of the fault:


- When the last updated TAI is not in the full configured 16 different TACs of current used TAI list it
caused the IndexOutOfBoundsException while trying to add it, because the list was full. So, MME didn't
send the Paging request message to ENB which cause MME not to response to Downlink Data
Notification message.

Dependency on configuration:
- Current used TAI list is configured with 16 different TACs.
Prfile MmeTAIListMgmtEnabled 2096 is on.

Faulty component and version:


- LNX934G2.IMG 11.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- After the correction MME can update the last updated TAI to current TAI list correctly even the original
TAI list is full, so that all the latest TAI are saved.

Description how problem will solved:


- None

Analysis of the correction risk to the customer / end-user:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 66/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Current used TAI list is configured with 16 different TACs.
Prfile MmeTAIListMgmtEnabled 2096 is on.
1. Attach with IMS APN.
2. s1 release, ue turns into the ecm-idle state.
3. volte mt call (In paging procedure last updated TAI is not in the 16 different TACs in configured TAI
list).

2.55 NS16.50618 TAU Reject with CC 0xA (Implicit Detach) after FLEXI NS upgrade

NA05947959 TAU Reject after upgrade from NS40 0.2 to NS16 MP0.1 WU2

Summary of the original problem:


- TAU reject with cause ue identity cannot be derived.

How end user/operator could detect the problem:


- Inter MME TAU is initiated for a UE, MME is sending TAU accept to eNB providing the new guti for the
subscriber, TAU complete from UE/eNB that is not coming because UE has lost connection with the eNB,
MME retries TAU accept and waits for TAU complete. In the meantime, UE sends normal TAU to MME
using the GUTI provided in TAU accept, MME rejects the TAU with cause UE identity not Derived.

Description of the fault:


- Inter MME TAU is dropped when TAU complete is not received and new normal TAU is coming, the
subscriber is not store in the database, so the following TAU is rejected.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 6.21-0
- LNX924G2.IMG 6.20-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- Correct the code to complete inter MME TAU and process new received TAU.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 67/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Customer effects:
- Normal TAU KPI increases.

Test requirements:
- None

2.56 NS16.50619 Increase in counter EPS_ABNORMAL_PDN_DROPPED even though there are no


PDN connectivity reject due to Abnormal UE

NA05941183 Increase in EPS_ABNORMAL_PDN_DROPPED counter after NS16.5 upgrade

Summary of the original problem:


- Increase in counter EPS_ABNORMAL_PDN_DROPPED even though there are no PDN connectivity
reject due to Abnormal UE.

How end user/operator could detect the problem:


- At operator level, TA counter M51C060 (EPS_ABNORMAL_PDN_DROPPED) would get incremented
even though there are no PDN Reject due to Abnormal UE.

Description of the fault:


- While handling 3 procedures that collided, MME holds PDN Connectivity procedure and continues NW
Detach procedure as the latter is having higher priority. After detach, when PDN Connectivity procedure
resumes, MME should drop the procedure as subscriber already detached. As part of stopping the PDN
connectivity procedure, the above mentioned counter is incremented wrongly.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2 11.30

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- As part of handling PDN Reject, MME checks if the PDN connectivity procedure is dropped due to
subscriber being already detached or not (i.e. ECM state=IDLE, EMM state=Deregistered). If so, MME
will not increment the mentioned counter and only drop the PDN connectivity procedure.

Risk analysis of the correction:


- The correction does not affect the normal PDN Connectivity operation.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Post correction, counter 51060 (EPS_ABNORMAL_PDN_DROPPED) will not increment if there is no
PDN reject due to Abnormal UE. KPI will be restored.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 68/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Test requirements:
- None

2.57 NS16.50620 9047 alarms in NetAct after activating CNUM in NEs

NA05958784 WROSS: 9047 Alarms after activating CNUM in 10 NEs

Summary of the original problem:


- 9047 alarm appeared in Alarm List in NetAct after CNUM (Centralized Network Element User
Management) was activated.

How end user/operator could detect the problem:


- After activating CNUM feature, login with remote user for NE3S session (e.g. initiating Alarm Uploading
from NetAct).

Description of the fault:


- The authentication for remote user of NE3S session exceeded the time limit setting in NE side (MME)
due to high network latency and redundant role configuration in customer environment.

Dependency on configuration:
- CNUM is activated.

Faulty component and version:


- NE3SAGGX 8.16-6

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- Remove redundant role configuration for NE3S session or turn off CNUM.

Description of the correction:


- Optimize the role configuration in NetAct LDAP, increase the time limit for user login authentication.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

2.58 NS16.50621 CSFB Success Rate is degraded

NA05963570 CSFB Success Rate is degraded

Summary of the original problem:


- Null pointer exception in attach - IDR (Insert Subscriber Data Request) for NPLI: "network-provided
location information" procedure, collision scenario.

How end user/operator could detect the problem:


- attach - IDR (NPLI procedure) collision scenario.
- CSFB MT call procedure.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 69/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the fault:
- The attach - IDR (NPLI procedure) collision resolution is DICO (Drop the Incoming and continue the
ongoing procedure), there is one NULL pointer exception in this test scenario.

Dependency on configuration
- The prfile 2012(MME_CSFB_ENABLED) should be set as 0xFF.

Faulty component and version:


- LNX934G2.IMG 11.80-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Fix the Null pointer exception and the collision (Attach and NPLI procedure) resolution needs to be
changed from terminating IDR to continuing IDR.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.59 NS16.50622 Buffer overflows and error logs were printed when many ftp clients send many
files simultaneously

PR138589 [NS16.5] e-logs in FSRVER PRB during logs written

PR148259 Md1.6 GCD 1.7 (MMXX1700) - Error messages from 063D under TCP robustness
test on port 21

Summary of the original problem:


- When many ftp sessions send a lot of files at the same time, too many ftp log messages are being sent
to buffer, leading to buffer overflow. e-logs are printed.

How end user/operator could detect the problem:


- Many hand processes are sending a lot of files at same time.

Description of the fault:


- Too many log messages go to log hand, but max message count of buffer is too small. This leads to
buffer overflow.

Dependency on configuration:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 70/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- FSRVERGX.PAC 1.1-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- Store multiple logs into a large message instead of many log messages. This way the frequency in
which log messages are being sent is reduced.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Testing requirements:
- None

2.60 NS16.50623 "ST0: physical_file_inquiry_io error" written in working OMU's computer logs

PR157740 "ST0: physical_file_inquiry_io error" written in working OMU's computer logs

Summary of the original problem:


- After system restart, error log is in the work OMU.

How end user/operator could detect the problem:


- Delete log file only in the W1 disk, restart system.

Description of the fault:


- Code didn't check if file was existing in W1 disk.

Dependency on configuration:
- None

Faulty component and version:


- ST0LOG 2.6-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- Copy log file from W0 to W1

Description of the correction:


- if file is does not exists e.g. in W1, then create a new one.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 71/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.61 NS16.50624 MME could not deal with collision between AKA with Ue context release
procedure

PR163347 MME NS16(N6_1_24_0) MME seem cannot deal with collision between AKA with
Ue context release procedure

Summary of the original problem:


- MME didn't handle collision properly between InterNode Tau with Ue context release procedure.

How end user/operator could detect the problem:


- UE handover from 3G to 4G with partial TAU procedure, when MME send authentication request, ENB
send UE context release with cause interrat -redirection, it will detect the problem.

Description of the fault:


- When Ongoing Inter Node TAU collide with incoming UE context release procedure in AKA sub-
procedure state, MME continue the ongoing interNode TAU and hold incoming UE release procedure.

Dependency on configuration:
- S3 interface or Gn interface.

Faulty component and version:


- LNX934G2.IMG 11.40-0
- LNX924G2.IMG 11.30-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- When Ongoing Inter Node TAU collide with incoming UE context release procedure in AKA sub-
procedure state, MME drop the ongoing interNode TAU and continue incoming UE release procedure.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 72/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Customer effects:
- None

Test requirements:
- None

2.62 NS16.50625 S1 Handover ping-pong with SGW relocation does not work

PR171542 NS17 - Pingpong S1HO with SGW relocation does not work

Summary of the original problem:


- SGW does not change during s1Handover Ping-pong.

How end user/operator could detect the problem:


- Attach, S1 handover with SGW relocated, S1 handover back to former eNB/TAC.

Description of the fault:


- Partial TAU coming before eps_t3tunnel_timeout_s, and sent eps_tau_complete with original SGW
Host name.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG, 7.134-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- To update the relocated SGW host name once s1Handover complete instead of during resource
releasing for s1ho.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 73/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.63 NS16.50626 Tracking Area Update was not completed after S10 HandOver with SGW
relocation

PR178393 TAU after S10 Handover is not completed when SGW Reselection & Blacklisting
are enabled

Summary of the original problem:


- Tracking Area Update was not completed after S10 HandOver with SGW relocation.

How end user/operator could detect the problem:


- Operator could see exceptions in error logs.
- End User could not observe any issues since the UE retries TAU in case MME didn't sent any
response.

Description of the fault:


- In some cases when multiple collision between HO procedures, a Handover/Tau procedure might come
earlier than a timer expiration that was started from a previous collided handover due to a delete session
and this led to use the same subscriber object where the Sgw relocation flag was set. Different code part
is triggered in case this flag had been set.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.7-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- The code checks if the information is available before using it. In case it is not available it gathers this
information from different source.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Multiple HO requests should take place between two MMEs with SGW relocation.
- After multiple HO requests one of them should continue successfully.
- TAU procedure should follow the successful HO.
- During the successful HO/TAU the subscriber object should not be removed from cache so it holds the
values that were set before.
- Expected results:
- No exception should occur and the TAU procedure should be completed.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 74/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.64 NS16.50627 Wrong PGW selection by MME during PDN connectivity procedure when
FC085_003402 feature was enabled

NA05957933 Wrong PGW Used in CSR for Standalone PDN Connectivity

Summary of the original problem:


- The MME selected the same PGW as part of the stand-alone PDN Connectivity Request procedure if a
PDN Connection with the same APN was already established. This caused problems, when operator
wanted to select PGW based on customized DNS query formed from APN and PDN type. Existing PDN
connection created with the same APN might be with different PDN type than the new requested one
from MME in Create Session Request(CSR) as part of the current standalone PDN Connectivity Request.
In this case, PGW of the existing PDN connection might not support the new requested PDN type and
hence PGW rejected the Create Session Request.

How end user/operator could detect the problem:


- MME sent create session request with wrong PGW IP as part of the standalone PDN connectivity
procedure.

Description of the fault:


- According to the Spec 23.401 Chapter - 4.7.3 Bearer level QoS parameters, all simultaneous active
PDN connections of a UE that are associated with the same APN shall be provided by the same PDN
GW. However, this had to be modified after considering the interworking with “FC085_003402_MME
intelligent PGW selection based on requested PDN type activated”.

Dependency on configuration:
- The PRFILE Parameter 002:2256 (MME_HOME_GW_ENABLED) should be disabled and DNS should
contain a non-empty string for the new requested PDN Type in the UE initiated standalone PDN
Connectivity Request in ZBII output.

Faulty component and version:


- LNX924G2.IMG 3.68-0

Faulty component first delivered in(e.g. release, CD):


- NS21

Workaround:
- None

Description of the correction:


- During UE initiated PDN Connectivity Request procedure, the existing check to implement the spec
23.401 reference "All simultaneous active PDN connections of a UE that are associated with the same
APN shall be provided by the same PDN GW ", will be enhanced to include the PDN type also when the
PGW selection is based on the feature "FC085_003402 MME intelligent PGW selection based on
requested PDN type".

Risk analysis of the correction:


- If two PDN connections are established by the same UE using the same APN and served by two
different PGWs, each of PGW (PGW1 and PGW2) will allocate N bps as APN-AMBR but MME will
calculate the negotiated UE Aggregate Maximum Bit Rate with respect with N bps only and send towards
eNB. So, there will be rate shaping in eNB; there can be cases where PGW will charge for packets, which
are dropped in eNB. Those packets would be also visible in lawful interception even though UE never got
them.

Correction effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 75/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Interface Effects:
- None

Other effects:
- None

Test requirements:
- None

2.65 NS16.50628 Subs from 3G to 4G, after inter internode TAU to new MME, stay registered to
both source and target MME

NA05915374 MME Offloading Very Slow NS16 0.1

Summary of the original problem:


- During LTE offloading, it could be observed that the number of subscribers registered in MME was
large.

How end user/operator could detect the problem:


- In all triple access scenarios where subscribers moved from 3G to 4G (inter system TAU) and after
successful internode TAU to new MME and when the Cancel Location Request received immediately
after the Context ack, subscribers would be shown as registered in Database. By selecting, with query
execution in database, the EMM state for these specific IMSI their EMM state should appear as
registered.

Description of the fault:


- MME offloading seemed to offload subscribers slowly and left a large number of them registered. Even
though subscriber has moved to another MME, the number of registered subscribers stays quite high.
After further analysis, it was concluded that in all triple access scenarios where subscribers moved from
3G to 4G (inter system TAU) and after successful internode TAU to new MME and when the Cancel
Location Request received immediately after the Context ack, subscribers would be registered both in
source and in target MME. Specifically, after processing the Cancel Location Request, which was
received from HSS because of the InterMME TAU procedure, MME did not change the EMM state of the
subscriber to deregistered in database for the subscribers that have previously been in SGSN side of the
TA node. Subscribers that have only been in MME will be deleted from the database.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.7-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- After processing the Cancel Location Request, which was received from HSS because of the InterMME
TAU procedure, MME changes the state of the subscriber to deregistered and idle in database for the
subscribers that have previously been in SGSN side of the TA node.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 76/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- In order to test the fix a subscriber that has previously been in SGSN side of the TA node is needed.
Subscriber should attach in 3G and then with Intersystem TAU go to 4G from 3G and continue with an
InterMME TAU to another MME. A Cancel Location Request should be received from HSS immediately
after Context Ack. Expected result: Subscriber should be in idle and deregistered state in the source
MME.

2.66 NS16.50629 The commands "cli showinternal -dialbs" in the IPDU service terminal and "cli
showinternal -diah" in MMDU service terminal do not work, after upgrading to NS15

NA05946355 The command "cli showinternal -dialbs" in the IPDU service terminal doesn't
work in 2 MMEs after upgrade to NS15.

Summary of the original problem:


- The commands "cli showinternal -dialbs" in the IPDU service terminal and "cli showinternal -diah" in
MMDU service terminal do not work, after upgrading to NS15.

How end user/operator could detect the problem:


- Problem could be detected by typing the command "cli showinternal -dialbs" in the IPDU service
terminal or by typing the command "cli showinternal -diah" in the MMDU service terminal.

Description of the fault:


- The internal Byte Buffers that are used for the above commands had capacity of 1024 bytes, so when
the output of the above commands was bigger than 1024 bytes an overflow occurred.

Dependency on configuration:
- The contents of FXCRRTNX.XML file should exceed the size of 1024 bytes.

Faulty component and version:


- LNX967G2.IMG 11.4-2
- LNX936G2.IMG 11.4-0
- LNX938G2.IMG 12.3-0

Faulty component first delivered in(e.g. release, CD):


- NS22

Workaround:
- None

Description of the correction:


- Adjusted the capacity of the internal Byte Buffers that are used for the "cli showinternal -dialbs" and "cli
showinternal -diah" commands to the size of the output of these commands.

Risk analysis of the correction:


- None

Correction effects:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 77/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.67 NS16.50630 The success rate of CSFB dropped suddenly after upgrade to NS16.5

NA05936196 (Flexi NS-MME NS16.5)The success rate of CSFB dropped suddenly after
upgrade to NS16.5

NA05936445 'PILOT'(Flexi NS16.5)CSFB and SMS paging success rate decreased.

Summary of the original problem:


- During Inter MME TAU source, ORR_TIMEOUT timer (15s) is started after MME received Context
Acknowledge, and "Inter MME TAU ongoing" flag is set to true. HSS initiated detach, 15s timer is ongoing
and "Inter MME TAU ongoing" flag is still kept as true. Within 15s, a new Inter MME TAU target is
triggered, that flag (true) is copied to this procedure. After Inter MME TAU, every MT call and MT SMS
will be failed no matter within or beyond 15s. And there is also NullPointer exception issue for MME
doesn't check if plmn record in subscriber is valid or not.

How end user/operator could detect the problem:


- By executing the following scenario:
1. Inter MME TAU source, ORR_TIMEOUT timer (15s) is started after MME received Context
Acknowledge, and "Inter MME TAU ongoing" flag is set to true
2. HSS initiated detach, 15s timer is ongoing and "Inter MME TAU ongoing" flag is still kept as true
3. Within 15s, a new Inter MME TAU target is triggered, that flag (true) is copied to this procedure.
4. After Inter MME TAU, every MT call and MT SMS will be failed with cause 0x75: unable_to_page_ue_c
no matter within or beyond 15s.

Description of the fault:


- During Inter MME TAU source, ORR_TIMEOUT timer (15s) is started after MME received Context
Acknowledge, and "Inter MME TAU ongoing" flag is set to true. HSS initiated detach, 15s timer is ongoing
and "Inter MME TAU ongoing" flag is still kept as true. Within 15s, a new Inter MME TAU target is
triggered, that flag (true) is copied to this procedure. After Inter MME TAU, every MT call and MT SMS
will be failed no matter within or beyond 15s. And there is also NullPointer exception issue for MME
doesn't check if plmn record in subscriber is valid or not.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- MME will set "Inter MME TAU ongoing" flag to false in Inter MME TAU target procedure and escalate
the NullPointer check about the PlmnRecord.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 78/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Interface effects:
- None

Customer effects:
- MT-SMS, MT-CALL success ratio will be dropped

2.68 NS16.50631 VoLTE Setup failure due to Multiple QCI-1 ERAB setup

NA05921832 VoLTE Setup failure due to Multiple QCI-1 ERAB setup

Summary of the original problem:


- VoLTE bearer setup failed.

How end user/operator could detect the problem:


- By performing Tracking Area Update procedure with inactive VoLTE bearer, then VoLTE bearer was
created with the same bearer ID as the inactive VoLTE bearer.

Description of the fault:


- Second VoLTE bearer setup failed.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.5-10

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- MME informs the eNB in order to release resources for the inactive bearers during Tracking Area
Update procedure.

Related feature /functionality:


- Intra MME Tracking Area Update

Risk analysis of the correction:


- None

Correction effects:
- None

Effects on end-user:
- VoLTE bearer setup failed

Effects on operator:
- KPI of VoLTE bearer setup dropped.

Interface Effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 79/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Test requirements:
- None

2.69 NS16.50632 VOLTE Default bearer was forwarded to UTRAN and establishment failed

NA05953814 Continuation of case ID #NA05914101 - Problems after PS HO / RAU in 3G

Summary of the original problem:


- VOLTE Default bearer was forwarded to UTRAN and establishment failed.

How end user/operator could detect the problem:


- By performing attach with one internet PDN and one IMS PDN and then Inter system handover to
UTRAN.

Description of the fault:


- IMS Default bearer was included in Forward Relocation Request message, but Volte was not supported
in most of UTRAN networks. As a result, establishment of the Volte default bearer failed.

Related feature / functionality:


- Inter System HO from LTE to UTRAN with IMS APN

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Support an INI file parameter in MME in order to indicate if UTRAN supports VOLTE. If not, the MME
will not include the IMS Default bearer in Forward Relocation Request message and will perform deletion
after HO.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX924G2.IMG and LNX934G2.IMG. Version too legacy to be specified.

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 80/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.70 NS16.50633 One subscriber had two copies of data

NA05960561 (Flexi MME NS16.5)CSFB MT failed because of SGS paging reject with cause
"IMSI Detached for EPS Service"

Summary of the original problem:


- Same subscribers exist in different MMDUs' DB.

How end user/operator could detect the problem:


- ZMMO command was showing two same subscribers existed in DB.

Description of the fault:


- scenario1: during Inter System TAU with Initial Context Setup failure, subscriber was incorrectly
finalized.
- scenario2: native GUTI attach and IS Attach run in the same MMDU, when collision happened,
subscriber was incorrectly finalized.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.257-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- When Intersystem TAU fails, in case subscriber can't be found from DB, he is not finalized into DB.
- When IS attach collides with native GUTI attach, in case current subscriber is not created by own
MMDU, he is not finalized.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.71 NS16.50634 MME failed to handle inter-MME S1 HO collision with incoming TAU

NA05912672 (VoLTE 100day campaign)(Flexi NS)MME failed to handle inter-MME S1 HO


collision with incoming TAU

Summary of the original problem:


- MME failed to handle collision in TAU procedure.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 81/231
D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- Incoming Inter MME TAU collided with ongoing Inter MME Handover before Handover Notify received
from target eNB.

Description of the fault:


- When MME receives the inter MME TAU and inter MME S1HO is still waiting for HO notify
(HNO timer = 1,5 sec), collision will occur between ongoing inter MME HO and incoming TAU. Resolution
is Continue both i.e. start the TAU immediately.
- Now TAU sends TAU Accept but HO is still waiting for HO Notify i.e. MBR (Modify Bearer Request) is
not sent yet. Please note, this case is with SGW relocation. So, new SGW didn’t send the MBR to PGW
yet when target MME sends CSR (Create Session Request) to the new SGW. This is supposed to done
only when HO is confirmed i.e. HO notify is received or if HO notify didn’t come (HNO timer expires) but
TAU comes.
- As TAU Accept is sent, eNB/UE point of view UL user plane is setup. So, Uplink data is sent.
- SGW knows the PGW details. So SGW sends the Uplink data to the PGW but the PGW doesn’t know
the new SGW yet and hence PGW sends Error Indication.
- PGW sends Error Indication and hence we can see SGW sends Delete Bearer Request to the target
MME.
- Due to handling of collision with the new Delete Bearer Request and ongoing S1HO (HNO timer still
ongoing), although HO should have sent MBR, but HO is not sending MBR based on some coding issue.

Related feature / functionality:


- None

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Correct the MME behaviour to continue ongoing Handover Procedure and sending MBR & HO
complete, if TAU is coming while waiting for Handover Notify.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG, 7.266-0

Faulty component first delivered in(e.g. release, CD):


- NS15

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 82/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.72 NS16.50635 P-TMSI signature mismatch (206) cause code in SGSN Context Response caused
RAU failure

NA05970344 inter system RAU ( 4F) Cause: P-TMSI signature mismatch (206)

PR192070 NS15MP3: No response to sgsn-ctx-request.

Summary of the original problem:


- When MME responded with Cause: P-TMSI signature mismatch (206) to SGSN, the SGSN resent
SGSN Context Request to MME, but the MME did not respond with the SGSN Context Response.

How end user/operator could detect the problem:


- During intersystem RAU, MME responded to SGSN with Cause: P-TMSI signature mismatch (206).
Then there is a second SGSN Context Request immediately by SGSN to MME, but the MME did not
respond.

Description of the fault:


- The second SGSN Context Request caused collision between RAU and 1st ongoing RAU and MME
dropped the 2nd RAU wrongly and caused no response to SGSN for the 2nd RAU.

Related feature / functionality:


- 3G Inter System Mobility.

Dependency on configuration:
- GN interface

Faulty component and version:


- LNX934G2 1.23-2
- LNX924G2 1.23-2
- LNX922G2 1.23-2

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- The MME will drop the first RAU procedure and continue the incoming RAU.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 83/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.73 NS16.50636 Order of PDP context QoS profiles changed in subscription data stored in SGSN
after "HLR-initiated QoS modification" procedure

PR150366 Different order of pdp contexts in 'reg_get_subscription_res_s' message to SGSN

Summary of the original problem:


- Problem occurred after "HLR-initiated QoS modification" procedure took place for a subscriber with two
or more PDP context QoS profiles the SGSN internally moved the updated QoS profile to the last position
of the profile list in the stored subscription data. As result, if the MS detached and reattached it would be
using a QoS profile other than the initial one. For the above to apply, the MS would have to be requesting
an invalid APN during the attach requests.

How end user/operator could detect the problem:


- Operator: The conditions under which the operator could detect the problem are the following:
1) There were at least two PDP context QoS profiles stored in the SGSN for the subscriber.
2) The first PDP context QoS profiles had been changed via an "HLR-initiated QoS modification"
procedure.
3) The MS had detached, reattached and activated a PDP context, the new PDP context would not be
using the initial PDP context QoS profile.
4) In both the attaches above the APN requested by the MS was invalid.
- End-user: Cannot be detected on end-user level.

Description of the fault:


- In the scenario described above, during the QoS modification procedure, the application first removed
the PDP context QoS profile which was to be modified from the PDP context QoS profile list and then
added the updated form of the same profile to that list. Due to the replacing taking two steps, removal
and addition, the order of the profiles would be changed. In other words, the target profile was not simply
replaced while remaining in the same array index, it was first removed and then re-added in the last array
index.

Related feature / functionality:


- None

Dependency on configuration:
- Activated licenses:
- 3205 SGSN Dual stack PDP context support.
- 372 SGSN Override of requested APN.

Deactivated licenses:
- 5336 APN Conversion and Correction
- 3477 SGSN S4 Functionality (Gr/S6d)
- 1786 SGSN IMEI based APN Override
- Activated PRfiles:
- 1042 OVERRIDE_ROAMING_APN
- 1043 ENFORCE_SUBSCRIBED_APN
- 1999 SGW_DUAL_STACK_SUPPORT
- 1940: DUAL_STACK_PDP_CTXT
- Deactivated PRfiles:
- 1797 APN_WITH_LOWEST_PDP_ID

Workaround:
- None

Description of the correction:


- The update of the PDP context QoS profile is done with the profile retaining its index in the profile list
instead of removing and then re-adding it.

Risk analysis of the correction:


- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 84/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Effects on end-user:
- None

Effects on operator:
- PDP context QoS profiles are not re-ordered anymore with the QoS modification procedure. No KPI
impact.

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX922G2.IMG 9.2-0, LNX922G2.IMG 13.5-0

Faulty component first delivered in(e.g. release, CD):


- NS30

2.74 NS16.50637 MME detach type is incorrect in LIC event log

NA05919015 (Flexi NS-SGSN/MME NS15) MME detach type is incorrect in LIC event log

Summary of the original problem:


- MME detach type is incorrect in LIC event report.

Description of the problem:


- MME detach type is incorrect in LIC event report in case of detach initiated by UE power off.

How end user/operator could detect the problem:


- After Detach procedure performed due to combined power off initiated detach, MME sends the
Detach event report to LIC and the detach type as 11.

Description of the fault:


- MME gets the detach type incorrectly in case of power off initiated detach.

Dependency on configuration:
- The feature China LI for MME (5347) enabled.

Faulty component and version:


- LNX934G2.IMG 7.140-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP1

Workaround:
- None

Description of the correction:


- Ignore the switch off field when set the detach type in detach event report for China LI.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 85/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- The feature China LI for MME (5347) enabled.

2.75 NS16.50638 MME does not send MM report to Traffica element for VLR offloading

PR177459 NS17 compatibility - MME seems not sending report at Traffica for VLR offloading

Summary of the original problem:


- When "NW initiated IMSI only detach" event took place, the MME did not send any MM report to the
Traffica element with this cause code.

How end user/operator could detect the problem:


- An MM report with cause code "NW initiated IMSI only detach" was not sent to Traffica element by MME
when this event took place. Specifically, if the MM reports are on, i.e., they are expected to be sent to
Traffica element, and the "NW initiated IMSI only detach" took place, the MME did not send any MM
report to the Traffica element with this cause code.

Description of the fault:


- An MM report with cause code "NW initiated IMSI only detach" was not received by Traffica element
when this event took place and the MM reports were enabled.

Dependency on configuration:
- MM reports to Traffica element should be enabled.

Faulty component and version:


- LNX96AG2.IMG 11.5-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- The cause code describing the "NW initiated IMSI only detach" event was added in the MM reports.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- A MM report with cause code describing the "NW initiated IMSI only detach" event is sent to Traffica
element.

Customer effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 86/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Test requirements:
- Create a scenario of "NW initiated IMSI only detach", enable the MM reports to Traffica element and an
MM report with this cause code should be received from Traffica element.

2.76 NS16.50639 MME was faulty sending "Combined TA/LA updated " value in TAU Accept even
if the Network access mode was sent as Packet Only

PR167485 NS17 Feature - "Combined TA/LA updated" EPS value is coming inTAU accept
message even if the Network access mode is sent as Packet Only

Summary of the original problem:


- Combined TA/LA updated" EPS value was coming in TAU accept message even if the Network access
mode was sent as Packet Only.

How end user/operator could detect the problem:


- End user will not have access to 2G services.

Description of the fault:


- In case where UE was successfully attached in both 2G and 4G (combined attach) and before a
combined TAU takes places an Insert Subscriber Data Request was received with the network access
mode changed only to gprs, MME was faulty sending TAU accept with value set to "Combined TA/LA
updated".

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2 11.5-0

Faulty component first delivered in(e.g. release, CD):


- NS4.0

Workaround:
- None

Description of the correction:


- In case where UE is successfully attached in both 2G and 4G (combined attach) and before a combined
TAU takes place an Insert Subscriber Data Request is received with the network access mode changed
only to gprs, MME now sends the correct value in TAU accept, "TaUpdated".

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- A subscriber successfully attached in both 2G and 4G.
- An IDR should be sent to MME and change the network access to packet only.
- UE should attempt a combined TAU.
- Expected results: UE should receive a TAU accept with the value "TaUpdated".
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 87/231
D553209967 © Nokia 2016
Version 1.0
Confidential
2.77 NS16.50640 MME sends two Traffica SM Reports for one dedicated bearer establishment in
case of collision.

PR154601 The MME sends two Traffica SM Reports for one dedicated bearer establishment

Summary of the original problem:


-MME sends two Traffica SM reports for one dedicated bearer establishment in case of collision.

How end user/operator could detect the problem:


-Traffica received two SM reports for one dedicated bearer establishment.

Description of the fault:


- Collision between ongoing PDN connectivity and incoming GW initiated dedicated bearer activation for
the same PDN, incoming procedure is terminated and traffica SM report is sent. Later, GW re-sends
Create Bearer Request, dedicated bearer is created successfully, SM report is sent again, so 2 SM
reports are sent in total for one dedicated bearer activation. Internal cause sent to the Traffica should
indicate the reason why the first attempt was rejected (i.e. collision_c = 0x17;)

Dependency on configuration:
- FC085_002543 MME_GTP_PIGGYBACKING is OFF.

Faulty component and version:


- LNX934G2.IMG 7.1-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- The SM report should be sent to Traffica, but should indicate the reason why the first attempt was
rejected. Correction is filling the right cause code to SM report.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 88/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.78 NS16.50641 MSISDN missing in Create Session Request after Ping-Pong inter-MME mobility
with Huawei MME

NA05983138 (Flexi NS MME NS16.5)MSISDN missed in CSR

Summary of the original problem:


- MSISDN missed in Create Session Request.

Description of the problem


- MSISDN missed in Create Session Request.

How end user/operator could detect the problem:


- VoLTE call failed after Ping-Pong inter-mme mobility with Huawei MME.

Description of the fault:


- C-MSISDN IE is missed in Forward Relocation Request message from Huawei MME, Nokia MME
stored an invalid MSISDN in DB.

Dependency on configuration:
- S10 interface

Faulty component and version:


- LNX934G2 11.13-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Adding validity check when setting MSISDN to DB.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.79 NS16.50642 During Inter system TAU from 3G to 4G, MME doesn’t send response to GW
initiated Update Bearer Request

NA05957300 Degradation in PDP context act SR due to cause 0x5F

Summary of the original problem:


- During inter system TAU, if there is HSS initiated Insert subscriber data, MME doesn’t send response to
the GW initiated Update Bearer Request and also ITAU not successful.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 89/231
D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- During inter system TAU, if there is HSS initiated Insert subscriber data, MME doesn’t send response to
the GW initiated Update Bearer Request and also ITAU not successful.

Description of the fault:


- During Inter system TAU from 3G to 4G, MME doesn’t send response to GW initiated Update Bearer
Request. This was due to collision between three procedures - ISTAU, HSS initiated Insert subscriber
data and SGW initiated Bearer modification procedure where the Insert Subscriber Data procedure is
terminated. In this scenario, because of an internal fault, UE moves to EMM De-Registered state and
SGW Teid becomes NULL. UE later moves on to 3G coverage and initiating PDP activation on 3G. As
PGW and GGSN are being the same node, it's not able to handle the PDP activation due to the fact that
it's still waiting for response for Update Bearer Response from MME.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.140

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- When the Insert subscriber data procedure is terminated due to collision, procedure will be gracefully
terminated and MME will send Insert Subscriber Data Answer with the relevant cause code. ITAU
procedure will be completed successfully and MME will send Update Bearer Response.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Collision scenario ongoing ISTAU and incoming Insert Subscriber Data procedure with Network
Provided Location Information (NPLI) Request while Insert Subscriber Data procedure is waiting to start
after ISTAU. SGW trigger Bearer Modification causing 3 procedure collision. MME should terminate
Insert Subscriber Data procedure and continue with SGW trigger Bearer Modification after ISTAU and
MME responds to SGW with Update Bearer Response.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 90/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.80 NS16.50643 Wrong PGW IP was selected during PDN connectivity procedure when the APN
was the same as in Attach procedure

NA05945924 Wrong pgw ip selected for the scenario - attach/post PDN connect procedure
with same apn.

Summary of the original problem:


- PDN connectivity procedure used the same APN as in attach procedure, however, different PGW IP
was used in Create Session Request for PDN connectivity procedure.

How end user/operator could detect the problem:


- UE requested PDN connectivity procedure with APN which was same as in Attach. However, the PGW
IP in Create Session Request was different from the one during Attach.

Description of the fault:


- MME did not check the APN Name during PGW IP address selection for PDN Connectivity procedure.

Dependency on configuration:
- For one APN, multiple PGW IPs should be mapped in DNS.

Faulty component and version:


- LNX934G2.IMG 11.89-0
- LNX924G2.IMG 11.64-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- One APN was mapped to one PGW.

Description of the correction:


- MME now checks whether the APN during PDN Connectivity procedure is the same as the APN during
attach procedure. If APNs are the same, the PGW host name for PDN to DNS query is set.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 91/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.81 NS16.50644 China LI MME X2 interface connection status became NOK after upgrade

NA05940511 (NS16.5)China LI MME X2 interface became NOK after upgraded to the


NS16.5.

Summary of the original problem:


- China LI MME X2 interface connection status became NOK after upgrade.

How end user/operator could detect the problem:


- Enable the MME China LI feature and start China LI function. After establishing X1 connection, X2
connection could not be setup and the connection state was NOK.

Description of the fault:


- China LI MME X2 interface connection status became NOK after upgrade. During TCP connection
establishment, MME set the timeout timer for establishing, but this timer was too short so that connection
could not be established on time.

Related feature / functionality:


- FC085_002621 China LI for MME.

Dependency on configuration:
- The feature China LI for MME (5347) should be enabled.

Workaround:
- None

Description of the correction:


- TCP connection timer of timeout increased.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNXA92G2.IMG 6.4-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 92/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.82 NS16.50645 MME caused hung bearer due to PGW initiated DBR (delete bearer request) for
default bearer and DDN (downlink data notification) collision

NA05962662 MME causing hung bearer due to DBR and DDN collision

Summary of the original problem:


- MME cause hung bearer due to PGW initiated DBR (delete bearer request) for default bearer and DDN
(downlink data notification) collision.

How end user/operator could detect the problem:


- If the DBR comes with default bearer ID during DDN procedure, then MME includes the default bearer
ID coming in DBR in ICSR (Initial context setup request) and in MBR (modify bearer request) during
service request procedure. Then GW sends Modify Bearer Response with the cause code = “No
resource available” due to which MME sent ERAB Release Command towards eNB. After this, the
default bearer ID coming in DBR is not released in MME and as result every time UE sends service
request, MME still includes that bearer in ICSR.

Description of the fault:


- When DDN and DBR procedures collide, then MME does not include the bearer ID present in DBR
during the service request procedure neither towards SGW nor towards eNB only in DBR with Dedicated
bearer. MME is checking if the DBR comes with Dedicated bearer ID during DDN procedure, then MME
does not include the dedicated bearer ID in MBR and ICSR during service request procedure. Because
of this dedicated bearer check, this procedure is not applied when DBR comes with default bearer ID.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 8.15-0
- LNX934G2.IMG 8.15-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Collision between DDN and PGW initiated default bearer deactivation are also addressed so that
default bearer under deactivation does not get established on radio side unnecessarily as part of the
ongoing DDN procedure. When this collision occurs, E-RAB ID of the Bearer that is going to be
deactivated in the Incoming Delete Bearer Request is not included in the ICSR and in the MBR that is
sent as part of the Ongoing DDN Procedure.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 93/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.83 NS16.50646 Incorrect SGW blacklist cause code

PR177156 Incorrect SGW blacklist cause code occurred

Summary of the original problem:


- Incorrect SGW blacklist cause occurred.

How end user/operator could detect the problem:


1. MME sends Create Session Request message to SGW1.
2. After the GCSRT timer expires, MME re-sends the message to SGW1.
3. SGW1 is not responding
4. MME blacklists the "SGW1".
5. MME selects a new SGW and sends Create Session Request message to the SGW2.
When executed the ZDDE: CPPU, *:"cli showinternal -tr"; it was observed that the printout was the
following:10.200.40.200, Add (New), Cause: -1, Msg: CREATE_SESSION_REQUEST,
at 2016-08-16 10:39:11.378.

Description of the fault:


- The TrHandler set the Cause code as -1 by hardcode.

Dependency on configuration:
- None

Faulty component and version:


- LNX9242G.IMG 13.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 17

Workaround:
- None

Description of the correction:


- Set the Cause code value from CreateSessionResponse, if no Response, the value will be set to default
value “No Responding (0)”.

Risk analysis of the correction:


- None.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 94/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.84 NS16.50647 3G Data KPIs Decrease and IPPU AVE CPU Load Unbalancing

PR163043 3G Data KPIs Decrease and IPPU AVE CPU Load Unbalancing

Summary of the original problem:


- 3G Data KPIs Decrease and IPPU AVE CPU Load Unbalancing.

How end user/operator could detect the problem:


- Element under traffic.

Description of the fault:


- SGSN application program (GUD) will get less opportunities to run because of less schedule times.
Sessions will be inclined to be unbalanced. At the same time, Ethernet driver's priority is not high enough
under this case, FIFO error will increase dramatically.

Dependency on configuration:
- None

Faulty component and version:


- EPOFFIGX.PAC 13.17-0
- ETHLIBGX.PAC 12.49-22

Faulty component first delivered in(e.g. release, CD):


- NS 16.5 MP1

Workaround:
- None

Description of the correction:


- Rollback ETHLIBGX "switch_priority" operation.
- Also use EPOFFIGX.PAC 13.20-0 to fix load difference among the units issue.

Risk analysis of the correction:


- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.85 NS16.50648 SGS Paging not answered

NA05932745 NS16.5 Pilot, Follow up NA05921818 : SGS Paging not answered

Summary of the original problem:


- SGS paging failed due to subscriber flag was not reset at the end of TAU.

How end user/operator could detect the problem:


- After successful Intermme TAU, UE attach to source MME again, but SGS paging failed.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 95/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the fault:
- Internal description of the fault which causes detected problem. Subscriber flag (intermme TAU
ongoing) is set to true during intermme TAU, but at the end of the procedure (ORR timer expired), it was
not reset to false.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 10.7-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Reset the subscriber flag (intermme tau ongoing) even though EMM state is DEREGISTERED.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.86 NS16.50649 faulty data present in platform measurement

NA05931196 (MME NS16MP1)faulty data present in platform measurement

Summary of the original problem:


- Faulty data present for 250H measurement.

How end user/operator could detect the problem:


- Create a LINDX unit object for 250H measurement, then generate the report.

Description of the fault:


- Year should be 2016 and not 4116(BCD code).

Dependency on configuration:
- None

Faulty component and version:


- LNX6FFG2.IMG 6.5-1

Faulty component first delivered in(e.g. release, CD):


- Y2 16.50-0

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 96/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
- None

Description of the correction:


- Year is changed from 4116(BCD code) to 2016.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.87 NS16.50650 Subscriber detached due to irregular idle timer reset

NA05870692 Irregular idle timer detach

Summary of the original problem:


- Invalid trigger of "detach by timer" was observed for random subscribers.

How end user/operator could detect the problem:


- By checking traffica report.

Description of the fault:


- An erroneous handling of the GSP internal table which is responsible for handling subscriber's "detach
by timer" procedure, was observed. This erroneous handling led to force some subscribers to get
detached (by detach timer) before its appropriate reset timestamp. As a result, GSP sent detach by timer
message to GMG and then detach procedure for this subscriber started.

Related feature / functionality:


- None

Dependency on configuration:
- Detach by timer feature should be set to ON.

Workaround:
- None

Description of the correction:


- A defensive mechanism is implemented on GMG. Specifically, when GSP sends "detach by timer" to
GMG, GMG asks for subscription form database. Inside response message from database, there is the
subscriber's attach time. With this information, available, the difference of the current time and the attach
time is calculated and if it is less than detach timer's value, subscriber is not getting detached but "start
detach timer" message is sent back to GSP in order to have this subscriber inside hash table again. The
new duration of this subscriber inside table (hash table) is calculated by the differences that result
between the detach timer and the attach duration. There is also a threshold of one minute which means
that if detach timer expires one minute before its appropriate reset time, then continue with the detach
procedure.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 97/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- GMG_G6JX.PAC 13.3-8

Faulty component first delivered in(e.g. release, CD):


- NS15

2.88 NS16.50651 Ongoing PDN gateway dedicated Bearer Creation fails when collided with
incoming X2 handover with Tracking Area Update

NA05918571 CBR-X2HO-TAU collision

NA05918637 Collision with dedicated Bearer and X2 handover with TAU

Summary of the original problem:


- Dedicated bearer establishment failed when there was a collision between Ongoing Create bearer
procedure and Incoming X2-HandOver (HO) with intra MME TrackingAreaUpdate (TAU) procedure.

How end user/operator could detect the problem:


- Dedicated bearer establishment failed when there was a collision between incoming X2- Handover with
TAU and ongoing Create bearer procedure.

Description of the fault:


- As part of the Ongoing Create bearer procedure and Incoming X2-HO with intra MME TAU procedure
collision, Ongoing Create bearer was terminated and continued with TAU procedure after X2-HO.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.5-0
- LNX924G2.IMG 11.6-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 98/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- Collision resolution is made in such a way that first Incoming X2-HO with TAU procedure will be
continued by holding the Ongoing Create bearer procedure. Once TAU is completed, Create bearer
procedure will be continued.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Dedicated bearer will be succeeded when there a collision between incoming X2-HO with TAU and
ongoing Create bearer procedure.

Test requirements:
- There should be a collision between incoming X2-HO with TAU and ongoing Create bearer procedure.

2.89 NS16.50652 MME was unable to process Update Bearer Request without QoS information,
sent as part of MME requested QoS Modification

NA05928337 Flexi-NS-16.5_Pilot:NS 16.5 1.17-2: HSS Initiated Bearer Modification eNB


Error Failure Ratio is Relatively High

Summary of the original problem:


- HSS Initiated Bearer Modification eNB Error Failure Ratio was Relatively High.

How end user/operator could detect the problem:


- User: User will experience lower Bandwidth till PGW sends Update Bearer Request next time.
- Operator: KPI degradation due to increment of counter HSS_INIT_BEARER_MOD_FAIL_ENB
(M51C012).

Description of the fault:


- When MME sends Modify Bearer Command to GW for QoS modification and GW sends Update Bearer
Request without QoS IE, MME does not send E-RAB Modify Request towards eNodeB. But, MME is
waiting for E-RAB Modify Response even when there is no E-RAB Modify Request sent.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.2-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- When MME sends Modify Bearer Command to GW for QoS modification and GW sends Update Bearer
Request without QoS IE, MME will consider that requested QoS Values, as sent in the Modify Bearer
Command, is accepted by the GW. MME will send the E-RAB Modify Request with the QoS values as
sent in the Modify Bearer Command.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 99/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- HSS Initiated Bearer Modification would be successful. HSS_INIT_BEARER_MOD_FAIL_ENB
(M51C012) would not be increased when there are no ERAB Modify Request sent by MME.

Test requirements:
1. Intersystem TAU.
2. As part of QoS upgradation after ITAU, MME sends Modify Bearer Command to GW with APN-AMBR
and ARP change.
3. GW sends Update Bearer Request without “Bearer Level QoS” IE.

2.90 NS16.50653 An exception of OMOLIB module due to large allocation size or inadequate free
size

NA05947718 Traffic dip observing in 7 BSCs of SGSN

Summary of the original problem:


- Traffic drop in BSCs due to an exception of OMOLIB module.

How end user/operator could detect the problem:


- When the free memory was small, a traffic drop in BSCs occurred.

Description of the fault:


- The mem_walloc_r () function is called by application module GIP; when allocation size was large or the
free size was not enough, the memory overflowed and there was an error in mem_walloc_r () function,
resulting in an exception of OMOLIB at CS.EIP = 0858.0000C121 address.

Dependency on configuration:
- None

Faulty component and version:


- OMOLIBGX.PAC 15.5-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- Unit restart.

Description of the correction:


- A memory protector for the exception case has been added.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 100/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- None

2.91 NS16.50654 Services were denied for Subscribers due to invalid UEAMBR value '0' sent by
MME

NA05938815 (Flexi NS-MME NS16MP0.1)Increased lots of new subscribers UEMBR=0

Summary of the original problem:


- The number of subscriber for which MME was sending UeAMBR value as 0 was increased in Initial
Context Setup Request message.

How end user/operator could detect the problem:


- During Attach/Intra MME Tau/ Inter System Tau/ Service Request procedures in some erroneous
situations MME was sending 0 value for "Ue Ambr" value in the Initial Context Setup Request message
towards eNB denying services to the UE.

Description of the fault:


- During Attach/Intra MME Tau/ Inter System Tau/Service Request procedures in some erroneous
situations, MME finds UeAMBR value 0 in DB and sending it towards the eNB in Initial Context Setup
Request message which causes denial of service to the UE.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 8.74-0
- LNX924G2.IMG 8.102-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- When MME finds UeAMBR value 0 in DB, it will do the S1Release if the procedure is Attach/Intra MME
Tau and MME will send the Reject message for Service Request and InterSystemTau procedures, there
by UE will again trigger the attach procedure and the above problem will be solved and UE will again get
the desired bit rates.

Description of the correction:


- During the Attach/Intra MME Tau procedure after ULA, if MME finds UeAMBR values '0' in DB, then
check is made to send the S1Release towards the eNB, and if procedure is InterSystemTau/Service
Request then MME will send the Reject message and thereby it will force the UE to again re-trigger the
Attach procedure.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- After the fix MME, will send the Reject messages for IntraMMETau/ Service Request and MME will send
the S1Release for Attach/InterSystem tau procedures there by forcing the Ue to retrigger the attach
procedure and hence the above erroneous issue will be avoided.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 101/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Test requirements:
- Ini Parameter "CHECK_FOR_INVALID_UEAMBR_VALUE" should be enabled
Attach (Native GUTI)
1. UE sends Attach request with Native GUTI
2. AKA SMC procedure completes
3. MME sends ULR to HSS
4. HSS sends ULA with UE AMBR as 1 Gbps
Note: MME finds UEAMBR is set to 0 in DB.
5. MME drops Attach procedure
6. MME sends UE Context Release Command with 'implicitly detached' cause.
7. UE retries Attach procedure
8. MME completes AKA SMC Procedure
9. MME sends ULR and HSS sends ULA
10. MME completes CSR with GW
11. MME sends Attach Accept/Initial Context Setup Request with correct UE AMBR values and no UE
AMBR issue is observed
13. ENB sends Initial Context Setup Response
14. UE sends Attach Complete to MME
15. MME sends MBR with GW

2.92 NS16.50655 Collision between PGW initiated bearer modification and bearer deactivation
procedures - MME sends wrong NAS sequence number in Deactivate EPS bearer context request.

NA05943975 Issue 1 :: UBR DBR X2 CBR S1 release collision

Summary of the original problem:


- When ongoing Update Bearer Request and incoming Delete Bearer Request collide in MME, Update
Bearer Request is terminated and Delete Bearer Request is continued. But while terminating the Update
Bearer Request procedure, the NAS count was not updated into MMDU database. This led to incorrect
sequence number in the subsequent Downlink NAS message i.e. “Deactivate EPS bearer context
request” as part of PGW initiated bearer deactivation procedure due to which, UE dropped this message
and did not respond with Deactivate EPS bearer context accept.

How end user/operator could detect the problem:


- MME sent incorrect sequence number in the subsequent Downlink NAS message i.e. “Deactivate EPS
bearer context request” as part of PGW initiated bearer deactivation procedure due to which, UE dropped
this message and did not respond with Deactivate EPS bearer context accept.

Description of the fault:


- NAS count was not updated to database after terminating gateway PGW initiated bearer modification
procedure due to collision.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.13-40

Faulty component first delivered in(e.g. release, CD):


- NS16.5

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 102/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- NAS count updated to subscriber details in MMDU after terminating ongoing Gateway initiated bearer
modification procedure. So, the subsequent messages have the correct NAS Sequence number.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- Proper sequence number will be sent in “Deactivate EPS bearer context request” as part of PGW
initiated bearer deactivation procedure after collision between UBR and DBR.

Customer effects:
- None

Test requirements:
- None

2.93 NS16.50656 IPDU diagnostic systematically fails (UNIT NOT OK) when PRFILE 54:13
DOUBLE_ETH_FAILURE is set to 1

NA05958644 IPDU diagnostic fails when PRFILE 54:13 DOUBLE_ETH_FAILURE is set to 1

NA05966494 IPDU diagnostic systematically fails (UNIT NOT OK) when PRFILE 54:13
DOUBLE_ETH_FAILURE is set to 1

Summary of the original problem:


- IPDU diagnostic systematically fails (UNIT NOT OK) when PRFILE 54:13 DOUBLE_ETH_FAILURE is
set to 1.

How end user/operator could detect the problem:


- Setting PRFILE 54:13 DOUBLE_ETH_FAILURE to 1, then check if IPDU diagnostic is OK.

Description of the fault:


- SFP link mode was missed in DMX Ethernet driver, DMX ETHLIB can't support SFP link feature, so it
fails to establish physical link when there is SFP plugged in the EL4/5.

Dependency on configuration:
- There is SFP plugged in the EL4/5.

Faulty component and version:


- ETHLIBGX.PAC 12.49-31

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Add a feature in DMX Ethernet driver to support SFP link mode.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 103/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- It will establish physical link correctly when there is SFP plugged in the EL4/5.

Interface effects:
- None

Customer effects:
- IPDU diagnostic will be successful (UNIT OK) when PRFILE 54:13 DOUBLE_ETH_FAILURE is set to 1.

2.94 NS16.50657 Collision between Ongoing Default Bearer Creation and Incoming X2 Handover
Request is causing the Default Bearer to fail

NA05962898 Collision between Ongoing Default Bearer Creation and Incoming X2 Handover
Request is causing the Default Bearer to fail

Summary of the original problem:


- Ongoing PDN connectivity collides with incoming X2 handover.

Description of the problem:


- When a PDN connectivity procedure (e.g. ebi 6) is ongoing in the MME and the target ENB sends a
Path Switch Request which includes the bearer (e.g. ebi 6) under activation, the MME will send Path
Switch Request Failure to target ENB. After the correction MME will hold the incoming X2 Handover
temporarily and continue with completing the ongoing PDN connectivity procedure. Then once PDN
connectivity request procedure is over, MME resumes X2 Handover procedure.

How end user/operator could detect the problem:


- Attach (default bearer id =5).
- PDN connectivity (default bearer id=6, IMS).
- SGW sends Create Session Request (ebi=6) to MME and gets Response.
- MME sends E-RAB Request (ebi=6) to source eNB.
- Source eNB sends E-RAB Setup Response to MME
- Target eNB sends Path Switch Request (E-RAB ID=5, 6) to MME, while MME is still waiting for Activate
dedicated EPS bearer accept.
- PDN connectivity continues. SGW gets modifyBearerRequest (ebi=6) and sends response to MME
- X2HO started. MME sends modifyBearerRequest (ebi=5) and modifyBearerRequest (ebi=6) to SGW,
and SGW replies to the second message.
- MME sends Path Switch Request Ack (E-RAB ID=5, 6) to Target eNB.
- Detach.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16 MP0.1

Workaround:
- None

Description of the correction:


- After the correction, MME will hold the incoming X2 Handover temporarily and continue with completing
the ongoing PDN connectivity procedure. Then once PDN connectivity request procedure is over, MME
resumes X2 Handover procedure.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 104/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- PDN connectivity and X2 handover KPI will no longer degrade when collision occurs.

2.95 NS16.50658 IPDU restarts and does not recover on MME

NA05963048 IPDU restarted and dint recovered on MME

Summary of the original problem:


- Memory leak in diameterLbs. When working IPDU free memory reaches a threshold, working IPDU
restarts and switchover happens.

How end user/operator could detect the problem:


- Operator could detect the problem by monitoring diameterLbs memory usage and working IPDU free
memory.

Description of the fault:


- When Resending Rerouting & Overload Control feature is enabled, diameterLbs does not free properly
memory allocated when received a diameter message from HSS.

Dependency on configuration:
- Resending Rerouting & Overload Control feature is enabled.

Faulty component and version:


- LNX967G2 7.23-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- Disable Resending Rerouting & Overload Control feature.

Description of the correction:


- Free memory that is allocated when a Diameter message is received from HSS and Resending
Rerouting & Overload Control feature is enabled.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Resending Rerouting & Overload Control feature is enabled.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 105/231
D553209967 © Nokia 2016
Version 1.0
Confidential
2.96 NS16.50659 S11 "Delete Bearer Command" message contains the wrong TAI

NA05962025 S11 "Delete Bearer Command" message contains the wrong TAI

NA05987299 Mixup of TAI and GCI MNC in Change notification req on S11.

Summary of the original problem:


- MME filled wrong PLMN ID in the TAI of ULI in the Delete Bearer Command and Change Notification
Request message.

How end user/operator could detect the problem:


- PLMN ID in the TAI of ULI in the Delete Bearer Command or Change Notification Request message is
wrong.

Description of the fault:


- When constructing Delete Bearer Command and Change Notification Request message, MME filled
both PLMN IDs in TAI and in ECGI with the one in the ECGI received in S1 message.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.0-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- When constructing Delete Bearer Command and Change Notification Request message, MME will fill
PLMN ID in TAI with the PLMN ID in the TAI received in previous S1 message instead of the PLMN ID in
ECGI.

Risk analysis of the correction:


- None

Correction effects:
- SGW will receive right PLMN IDs in the Delete Bearer Command and Change Notification Request
message.

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 106/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.97 NS16.50660 S-CDR with zero PLMNID is getting generated randomly

NA05941551 S CDR with Blank PLMNID is getting generated randomly

Summary of the original problem:


- S CDR with Blank PLMNID is getting generated randomly for some subscribers.

How end user/operator could detect the problem:


- In CMD charging files, there will be CDRs with PLMN ID = 0.

Description of the fault:


- From the provided customer log files, the following scenario could be identified:
During an outgoing RAU scenario, there is a collision with a new Inter SGSN RAU and as result outgoing
RAU is rejected. Then SGSN continues with asking DB detach info, but DB is responded with
"db_no_subs_c". Due to this response from DB, a detach mechanism is triggered for this subscriber with
cause "smmu_reset". As result, all charging information is deleted from charging library.After that, while
processing inter SGSN RAU, a new MS initiated service request is triggered so a new collision is
detected. After detection of second collision, GMG decides to continue with service request. Service
request is accepted and GMG hand is reserved for RAB creation which is triggered with GPRS CGI field
as zeros. This field is used from GCS and S4S PRBs in order to construct PLMN ID for CDRs. Since
value 0 for field PLMN ID is not forbidden, there is no mechanism in order to avoid creation of CDRs with
zeroed PLMN ID.

Dependency on configuration:
- None

Faulty component and version:


- S4S_GMJX.PAC 4.49-0

Faulty component first delivered in(e.g. release, CD):


- SG7

Workaround:
- None

Description of the correction:


- To this direction and based on the above analysis, a defensive mechanism is going to be implemented
on S4S side via UTPFIL patch, in order to check GPRS CGI filed and avoid creation of CDRs with zeroed
PLMN ID.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 107/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.98 NS16.50661 MML Command ZMMF fails after being executed many times

NA05973926 ERROR IN FETCHING SUB COUNT FROM ROB SGSN6

Summary of the original problem:


- MML command ZMMF failed as DBHandler in MMDU was not able to query the database.

How end user/operator could detect the problem:


- No impact to end user. For operator, MML command ZMMF would fail with error message "NO
RESPONSE" or "NO RESPONSE FROM DBHANDLER".

Description of the fault:


- When ZMMF was executed, pre-compiled queries (prepared statements) would be sent to the
database. Only 1000 prepared statements were allowed per connection and as ZMMF could on occasion
require many queries, this 1000 limit could be reached if ZMMF was executed a sufficient amount of
times. When this happened, the affected connections could no longer send new queries to the database,
thus causing this problem.

Dependency on configuration:
- None

Faulty component and version:


- LNX922G2.IMG 11.4-2

Faulty component first delivered in(e.g. release, CD):


- Too legacy to identify

Workaround:
- Restart affected MMDUs (traffic will be affected by restart).

Description of the correction:


- Instead of using pre-compiled queries (prepared statements) for executing the necessary queries for
ZMMF MML command, simple statements that are not pre-compiled are now used.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 108/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.99 NS16.50662 After MMDU restart process restarted every 5 minutes

PR125648 [NS16] - DBHandler reports 1007 RESTARTED PROGRAM BLOCK alarm every 5
minutes

Summary of the original problem:


- After restarting a pair of MMDUs, during database replication procedure, the second MMDU that was
restarted could not support traffic.

How end user/operator could detect the problem:


- Operator: Multiple ‘1007 RESTARTED PROGRAM BLOCK’ alarms, in the second MMDU of the pair
that was restarted, indicating that the program block 093D was restarted. When interrogating with ZMMN
MML command less subscribers can be observed in the MMDU pair that was restarted. Probably during
high traffic ‘1014 PROCESSOR LOAD RATE ALARM LIMIT EXCEEDED’ alarm could be raised,
indicating overload, due to the fact that one MMDU could not support traffic.
- User: Probably during high traffic, some latency in services can be expected, due to occasional
procedure being rejected.

Description of the fault:


- After a synchronized pair MMDU restart, during database replication procedure (netcopy), the primary
database located in the second MMDU that was restarted and its secondary database located in the first
MMDU that was restarted were stacked in an endless loop performing replication. So, the second MMDU
could not store and serve subscribers.

Related feature / functionality:


- Database

Dependency on configuration:
- None

Workaround:
- After the occurrence of the issue, restart both MMDUs in the pair.

Description of the correction:


- The issue is fixed by upgrading to a new 3rd party software for database (solidDB V7.0_FP23). This
new database contains a fix, where the database controller (High Availability Controller - HAC) tries to
start the local database instance, instead of waiting for the primary and secondary databases to finish the
endless replication loop.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX930G2.IMG 5.16-0
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 109/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component first delivered in(e.g. release, CD):
- Too legacy to be specified.

2.100 NS16.50663 Create Bearer Request and S1 release collision caused NAS sequence issue

NA05943886 Issue 2 :: DBR and S1 release collision causing NAS sequence issue

Summary of the original problem:


- During a collision with an ongoing Create Bearer Request procedure and an incoming S1-Release
procedure, NAS is not updated in the Database. Therefore, there is a discontinuity in the NAS sequence
number (Both Uplink and Downlink NAS count).

How end user/operator could detect the problem:


- After the collision MME sends incorrect NAS Sequence number.
Thus, UE drops any - out of sequence - NAS message.

Description of the fault:


- During an ongoing Create Bearer Request procedure and an incoming S1-Release procedure, before
Create Bearer Request was terminated (as part of the collision resolution in MMDU), CPPU sent Create
Bearer Response to S-GW. After the Create Bearer Request is terminated, MMDU is not consuming the
Create Bearer Response DMX message from CPPU. So, it does not update the NAS count. As result,
any a new NAS message from the MME, has a wrong NAS sequence number.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 9.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Changes were implemented so that NAS count will be updated in the Database in case a collision
occurs between an ongoing Create Bearer Request procedure and an incoming S1-Release procedure.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 110/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.101 NS16.50665 ID (GUTI, TEID) leakage during multiple Initial Context Setup Failure

NA05961400 EME Follow up case - NA05958290 - FNS (NS15 MP2) The subscribers cannot
connect 4G nor 3G

Summary of the original problem:


- ID (GUTI, TEID) leakage observed in MMDU which leads to zero available IDs. Thus, no subscriber can
be added in the respective MMDU.

How end user/operator could detect the problem:


- Alarm "3797 NUMBER OF SUBSCRIBERS IS OVER THE CAPACITY" is raised.

Description of the fault:


- When one or more of the scenarios below took place:
4g Attach- IS RAU - IS-TAU receiving Initial Context Setup Failure from eNodeB.
4g Attach- ISRAU - ISTAU collision with S1 release.
4g Attach- ISRAU - ISTAU with cause Modify Bearer Failure.
ID leakage was observed in the MMDU unit handling the specific subscriber and eventually this led to
zero available IDs. As result, no subscriber could be added in this MMDU, while MMDU pair restart was
required to overcome this situation. This was due to the fact that in the specific scenarios the previously
allocated IDs (from 4G Attach) were not released. Additionally, the 3797 alarm which was raised was
showing that GUTIs (01) reached 0 despite the fact that TEIDs or MmeS1apId were the ones that
reached 0.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.132-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- Enhancement implemented for releasing the previously allocated IDs (from 4G Attach) in mentioned
scenarios. Additionally, the 3797 alarm is now raised properly, based on which LTE identifier is
exhausted.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 111/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.102 NS16.50666 4G Attach/Intersystem TAU is not updating MSS/VLR via SGs

NA05972640 4G Attach/Intersystem TAU is not updating MSS/VLR via SGs

Summary of the original problem:


- During X2HO, a Delete Bearer Request is received by SGW with cause Reactivation Requested. MME
waits for an answer to Modify Bearer Request from X2HO before continuing the SGW Detach procedure.
Modify Bearer Response is not received and SGW resends the Delete Bearer Request. X2HO eventually
fails because there is no answer from SGW. Then MME initiates 2 SGW Detach procedures (one for
each Delete Bearer Request message). The 1st SGW Detach procedure is silently dropped by the
MMDU. However, the CPPU is not informed and Detach Request to the UE - as well as - SGsAP EPS
DETACH INDICATION to the VLR are sent. The SGsAP DETACH ACK is not consumed properly and
one of the procedures doesn't stop TS8 timer. UE attaches again and the TS8 timer expires sending
another SGsAP EPS DETACH INDICATION to the VLR.

How end user/operator could detect the problem:


- CSFB KPI degradation may be observed.

Description of the fault:


-After the mentioned collision, the Create Bearer Request procedure stops and waits until the completion
of TAU procedure and after that it completes its execution too. During this period the new bearer (of
Create Bearer Request procedure) has not been established. The SGW sends Modify Bearer Response
with cause Context Not Found. Therefore, MME sends ERAB Release Command message to eNB, ENB
responds with ERAB Release Command Failure (since this bearer has not been established yet).
As result, Create Bearer Request procedure fails. Moreover, regarding TAU procedure, MME sends TAU
Accept message with wrong sequence number to eNB, which doesn't respond with TAU Complete, so
after max retries, TAU will fail too.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.100-0
- LNX934G2.IMG 11.120-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- The handling of the collision between an ongoing X2HO and an incoming DBR changed, both continue
simultaneously. If one bearer is established, a Path Switch Request Failure is sent to eNB with causes
NAS detach, if more bearers are established both procedures are completed normally.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- In a collision between an ongoing X2HO and an incoming DBR changed, with one bearer is established,
a Path Switch Request Failure is sent to eNB with cause nas detach and counter M50C159 increases.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 112/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Test requirements:
- None

2.103 NS16.50667 MME was including inactive bearers in ICSR during Inter PLMN TAU

PR150991 MME is including inactive bearers in ICSR during Inter PLMN TAU

Summary of the original problem:


- MME included inactive bearers in Initial Context Setup Request (ICSR) during Inter PLMN TAU.

Description how problem can be detected


- The problem could be detected when ICSR was sent as part of Inter Plmn Tau.

Description of the fault:


- MME was including all the active and inactive bearers that were coming in Tau Request message in
ICSR as there was no specific handling for inactive bearers.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.67-0

Workaround:
- None

Description of the correction:


- When Tau Request message comes with active and inactive bearers, then inactive bearers will not be
included in ICSR sent as part of Tau.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Inactive Bearers won’t be included in ICSR during InterPLMN Tau, as result of which the bearers that
are not requested by UE will not be established. This will lead to effective utilization of bearer resources
from the operator perspective.

Test requirements:
- Attach establishing Default Bearer with EBI 5
- PDN Connectivity establishing PDN with EBI 6
- PDN Connectivity establishing PDN with EBI 7
- S1 Release
- Ue Sends Tau Request Message with EBI5, EBI 6 as active and EBI 7
as inactive in EpsBearerContextStatus.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 113/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.104 NS16.50668 Data from FlexiNS to traffica shows faulty Neg QCI =1 when PDN Connection is
rejected due to "Invalid APN"

NA05913149 Data from FlexiNS to traffica shows faulty Neg QCI =1 in NS 16 Mp1.

Summary of the original problem:


-Data from Flexi NS to traffica showed faulty Negotiated QCI =1 when PDN connectivity procedure was
rejected due to invalid APN. This should be 0 since no information for that particular APN is available.

How end user/operator could detect the problem:


- Enable prfile HSSPGW_PARAM_OVRD_ENABLED (2285), set MMEQOSProfile with QCI=1 as default
for all PLMN. After Attach is performed trigger PDN connection with an APN that is not configured in the
HSS.

Description of the fault:


- With prfile HSSPGW_PARAM_OVRD_ENABLED (2285) enabled if PDN Connection is rejected due to
"invalid APN" then QoS parameters were overridden according to the value configured in the
MmeQoSProfile. This was not necessary as no prior information of that particular APN is available.
Instead it should have default value, which is 0.

Dependency on configuration:
1. Prifle HSSPGW_PARAM_OVRD_ENABLED (2285) should be enabled
2. MMEQosProfile should be configured for that particular Subscriber

Faulty component and version:


- LNX934G2 11.25

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Added a check to see if the APN provided is valid. If so continue with MMEQoSProfile Override, else no
override is done.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 114/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.105 NS16.50669 Illegal charging ID caused raising of 3464 alarm

NA05955826 3464 CHG INTERFACE DATA PROBLEM

Summary of the original problem:


- Alarm "3464 CHG INTERFACE DATA PROBLEM" was raised due to wrong setting of Charging ID
within the scope of charging a PDP activation, caused by several collisions among PAPUs.

How end user/operator could detect the problem:


- While tracing log file and NeHa reports.

Description of the fault:


- After analysing customer's provided log files, and after reproduction of the erroneous behaviour, it was
concluded that: When GCS PRB sends indication to GST for charging PDP activation with charging ID
set to 0xFFFFFFFF, alarm 3464 is raised. This is caused due to collisions occurring between RAU
scenarios within two or more PAPUs. The state of CDR is erroneously set to activated, and as result
GCS goes to state ‘wait no messages’, so indication message is triggered to GST without request
message arriving.

Dependency on configuration:
- None

Faulty component and version:


- GCS_GMJX.PAC 11.2-0

Faulty component first delivered in(e.g. release, CD):


- SG7

Workaround:
- None

Description of the correction:


- Based on the above analysis, to this direction, CDR's state should be set to "unknown" so as to have
the correct message flow.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 115/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.106 NS16.50670 Serving PLMN ID was incorrect in Create Session Request during Inter PLMN
intra MME X2 HO

PR156450 Serving PLMNID is incorrect in CSR during Inter PLMN intra MME X2 HO

Summary of the original problem:


- ServingNetworkValue was not changed during Inter PLMN X2 Handover in Create session request.

How end user/operator could detect the problem:


- Create Session Request was sent with old plmnId in ServingNetwork IE in case of interplmn X2
Handover.

Description of the fault:


- During Inter PLMN X2 Handover, PLMN id changed in guti and TAI. However, the servingNetworkValue
was not changed to new PLMN ID in TAI in the create session request. CSR still had the old plmn id.

Related feature / functionality:


- None

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- During Inter PLMN X2 Handover, PLMN id in TAI will be set to serving network value in Create Session
Request.

Effects on end-user:
- None

Effects on operator:
- Billing will be proper.

System effects:
- None

Other effects:
- None

Interface Effects:
- ServingNetwork value in Create Session Request will have PLMN in TAI in case of inter PLMN X2
Handover.

Faulty component and version:


- LNX924G2.IMG too legacy to be specified.

Faulty component first delivered in(e.g. release, CD):


- NS15

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 116/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.107 NS16.50671 During emergency call UICCless IMEI was missing from GMLC Location-Report-
Request (LRR)

PR163268 emergency call UICC missing IMEI on GMLC LRR

Summary of the original problem:


- During sim-less emergency call scenario with network-induced location request and
IMREQ=ONNONSTD, the location-report-request(LRR) message to GMLC did not include the IMEI and
GMLC was not able to request location to MME.

How end user/operator could detect the problem:


- GMLC was not able to request location to MME.

Description of the fault:


- During this specific scenario, the SecurityModeCommand(SMC) procedure did not include the IMEI so it
was considered from MME as "invalid". This way it was not sent further to the GMLC.

Dependency on configuration:
- IMREQ = ONNONSTD.
- PRFILE MME_NI_LR_ENABLED (2219) is enabled.
- GMLC for emergency is configured.

Faulty component and version:


- LNX934G2.IMG 11.13-30

Faulty component first delivered in(e.g. release, CD):


- NS15 MP1

Workaround:
- None

Description of the correction:


- When the SecurityModeCommand (SMC) procedure does not request an IMEI, the corresponding field
will not be processed for its validity. This way, it is not considered to be invalid and is sent to the GMLC.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- In location-report-request (LRR) from MME to GMLC, the IMEI from the UICCless emergency calls will
be forwarded.

Customer effects:
- KPI increase for the location services success.

Test requirements:
- IMREQ = ONNONSTD.
- PRFILE MME_NI_LR_ENABLED (2219) is enabled.
- GMLC for emergency is configured.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 117/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.108 NS16.50672 Delay in DB process replica after MMDU unit restarted by reset button

PR131969 [NS 16.5] Delay in Secondary DB startup after MMDU unit restart by reset button

Summary of the original problem:


- Sometimes there was a delay in secondary DB startup after MMDU unit restart by reset button.

Description of the fault:


- After MMDU unit restart by reset button the delay in secondary DB startup was introduced by a solidDB
internal issue.

Dependency on configuration:
- None

Faulty component and version:


- LNX9302G.IMG 5.16-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP3

Workaround:
- None

Description of the correction:


- This is a solidDB internal issue and is solved by upgrading to a new solidDB version.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.109 NS16.50673 CS PLMN is not included in PLMN list after second Intra MME TAU when in the
First TAU the TAU Complete is received without LAI IE

PR170076 FC085_3653: CS PLMN is not included in PLMN list after second Intra MME TAU

Summary of the original problem:


- In a case where the subscriber had been updated with LAI in combined attach and two consecutive
TAU procedures were occurred without changing Location Area, in the second TAU, MME sent TAU
Accept without CS PLMN in PLMN list.

How end user/operator could detect the problem:


- The problem could be detected when there is a combined attach with SGs Update Location Request
and Answer and afterwards two consecutive intra-MME TAU occurred without changing Location Area. In
TAU Accept of the second TAU CS PLMN is not included in PLMN list.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 118/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the fault:
- In the First TAU, when TAU Complete message was received without LAI IE, since the Location Area
didn't change, MME updated the CS PLMN domain with FF FF as value. So, in the second TAU, MME
replied to eNB with TAU Accept with no CS PLMN in PLMN list.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.5-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- In the First TAU, when TAU Complete is received without LAI IE, since the Location Area isn't change,
MME updates the CS PLMN domain with the proper value. So, in the second TAU, MME replies to eNB
with TAU Accept with the CS PLMN in PLMN list.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user


- None

Correction effects:
Interface effects
- None

Customer effects:
- None

2.110 NS16.50674 ETHLIBGIX component causes unit startup failure

PR156729 ETHLIBGIX causes unit startup failure

Summary of the original problem:


- SPARE OMU was falling to TE-EX state.

How end user/operator could detect the problem:


- By restarting the spare OMU unit.

Description of the fault:


- Virtio VF driver did not support max-no-packets equal to 128.

Dependency on configuration:
- None

Faulty component and version:


- ETHLIBGX.PAC 12.49-21

Faulty component first delivered in(e.g. release, CD):


- NS 16.5 MP1

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 119/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
- None

Description of the correction:


- max-no-packet equal to 64 is set when using virtio.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.111 NS16.50675 Partial handover from UTRAN to LTE failed

PR177672 Partial handover from UTRAN to LTE fails

Summary of the original problem:


- During Partial Inter-System handover from UTRAN to LTE over S3 or partial Inter-MME handover
procedure, the relocation would not be accepted by the target MME/SGSN if the Cause IE value differs
from "Request accepted".

How end user/operator could detect the problem:


- MME S3 ISHO feature has been activated (ZWOC:2,2286,0002;)
MME SGW Relocation feature has been activated (ZWOC:2,2029,00FF;)
1. Perform S3 based Inter System Handover from 3G to LTE with SGW change.
2. Partial Handover Resource Allocation Failure occurred.

Description of the fault:


- The scenario is partial Inter-System handover from UTRAN to LTE over S3 or partial Inter-MME
handover procedure. According to 3GPP 29.274 GTPv2 rel11, in Forward Relocation Response
Message Cause IE indicates if the relocation has been accepted or not. The relocation has not been
accepted by the target MME/SGSN if the Cause IE value differs from "Request accepted". In partial
success situation MME fills this cause IE with Request accepted partially in Forward Relocation
Response message.

Related feature / functionality:


- Inter-System handover from UTRAN to LTE over S3 or partial Inter-MME handover.

Dependency on configuration:
- S3 Interface has been configured.
- MME S3 ISHO feature has been activated (ZWOC:2,2286,0002;).
- MME SGW Relocation feature has been activated (ZWOC:2,2029,00FF;).
- S10 Interface has been configured.
- UE has performed attach with 5 PDN connections (1-5) and 5 default bearers.

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 120/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- After the correction, MME should fill this IE with Request accepted instead of Request accepted partially
and affects only S10/S3 interface.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- Partial S3 or S10 handover will be rejected by source SGSN or MME.

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 12.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

2.112 NS16.50676 Offline CDR is not transferred

NA05917044 Offline CDR is not transferred

Summary of the original problem:


- Offline CDR is not transferred. Need to know root cause for 1078 PROCESS EXCEPTION in MCHU-0.

How end user/operator could detect the problem:


- Customer detect the problem during actual use.

Description of the fault:


- IOMANA process copies data to invalid address which cause an IOMANA exception on MCHU-0 then
cause MCHU units switch over, and MCHU-1 take role to became new WO-EX and MCHU-0 restart to
recover the situation.

Dependency on configuration:
- None

Faulty component and version:


- IOMANAGX.PAC 25.85-0

Faulty component first delivered in(e.g. release, CD):


- Too legacy to be specified.

Workaround:
- Restart unit.

Description of the correction:


- Add a protection code to check address valid before copy data.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 121/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Functional testing

2.113 NS16.50677 Deactivate dedicate bearer collision with incoming ESRVCC handover

NA05926367 Deactivate dedicate bearer collision with incoming ESRVCC handover

Summary of the original problem:


- SRVCC failed when deactivate dedicate bearer collision with incoming ESRVCC handover.

How end user/operator could detect the problem:


- Ongoing bearerDeactivatedProcedure collided with incoming SRVCC, ongoing procedure with voice
bearer. SRVCC with CS only.

Description of the fault:


- Voice bearer was deactivated in bearerDeactivatedProcedure, SRVCC with CS only failed due to no
voice bearer activated.

Dependency on configuration:
- Gn interface is configured.

Faulty component and version:


- LNX934G2.IMG 7.15-0
- LNX924G2.IMG 7.10-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Modify the collision resolver for BearerDeactivationProcedure and SRVCC. When
BearerDeactivationProcedure with voice bearer is ongoing, should hold BearerDeactivationProcedure in
TrHandler, and process SRVCC first and SRVCC procedure failed, MME send
HandoverPreparationFailure to ENB. After SRVCC process complete, continue
BearerDeactivationProcedure process.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 122/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Customer effects:
- None

Test requirements:
- Gn interface should be configured.

2.114 NS16.50678 MME doesn't send Location update to MSC after S1 handover procedure.

NA05936054 (Flexi NS-MME NS16.5)cs service notification with imsi after upgrade to NS16.5

Summary of the original problem:


- MME doesn't send Location update to MSC after S1 handover procedure.

How end user/operator could detect the problem:


1. UE successfully attached on ENB1 with TAC1.
2. MME sent Location update request to MSC (tac-lac mapping: TAC1-LAC1).
3. UE triggered S1 handover from ENB1(TAC1) to ENB2(TAC2).
4. UE triggered combined TA/LA TAU procedure with the TAC2 and map to LAC2.
5. MME did not send Location update request to MSC.

Description of the fault:


- MME does not send Location update request to MSC in combined tracking area update procedure after
S1 Handover.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 10.3-0
- LNX922G2.IMG 10.3-0

Faulty component first delivered in(e.g. release, CD):


NS 16.5 MP1

Workaround:
- None

Description of the correction:


- Made changes to use correct latestTai - lastKnowTai instead last updated tai in all procedures except
Attach and TAU.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
-None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 123/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.115 NS16.50679 TAU SR Degradation

NA05942790 TAU SR Degradation

Summary of the original problem:


- Increase of number of failed TAU procedures due to unspecified reasons.

How end user/operator could detect the problem:


- TAU success rate degradation.

Description of the fault:


- Counter EPS_TAU_UNSPECIFIED_FAIL is increased incorrectly in intersystem TAU.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.306-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- When intersystem TAU is performed and the T3 timer in RAU is still running, in this case, TAU will be
completed successfully, Failure counter EPS_TAU_UNSPECIFIED_FAIL should not be increased.

Risk analysis of the correction:


-None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Number of failure counter EPS_TAU_UNSPECIFIED_FAIL decrease.

Test requirements:
- None

2.116 NS16.50680 Incorrect PTAU Handling After Roaming Control Feature Activation

NA05950344 N16.5 PILOT: Incorrect PTAU Handling After Roaming Control Feature
Activation

Summary of the original problem:


- When subscriber performs TAU with emergency bearers, MME sent UE Context Release Command
instead of TAU Accept and Emergency calls were dropped.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 124/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- When subscriber performs emergency attach or emergency PDN and later during Inter S1HO followed
by TAU, X2HO followed by TAU, Intra MME TAU, PTAU, Inter MME HO followed by partial TAU, MME
sent UeContextReleaseCommand instead of TAU Accept when FC085_002933 Roaming Control for IMS
APN feature was enabled. Reduction in Periodic TAU failure counter (M50C004).

Description of the fault:


- An exception occurred in MMDU.

Dependency on configuration:
- Enable feature using the ZWOC:2,2074,0002; MML command.

Faulty component and version:


- LNX934G2.IMG 11.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- If Roaming control for IMS APN feature is enabled, MME attempts to retrieve per APN information PDN
connection wise from the APN configuration data. For the emergency subscribers, as the APN is not
picked up from HSS configuration data, instead from local configuration, this operation throws an
exception. Similar exception happens during PTAU in EMM deregistered state. MMDU procedure gets
ended abruptly. CPPU gets timed out for MMDU response and sends S1 release. Correction is made
such that if the APN index is found as invalid, retrieval from the HSS APN configuration data is skipped
and also this feature specific code handling.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.117 NS16.50681 MME cannot deal with ULA with unknown EPS subscription in TAU procedure

PR163333 MME NS16(N6_1_24_0) MME cannot deal with ULA with unknown EPS
subscription in TAU procedure of 3G HO to 4G

Summary of the original problem:


- MME cannot deal with ULA with unknown EPS subscription in TAU procedure of 3G HO to 4G.

Description of the problem:


- MME cannot deal with ULA with unknown EPS subscription in TAU procedure of 3G HO to 4G.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 125/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- 3G card, 4G phone which support 3G to 4G HO.
- intersystem HO(S3/GN).
- Partial TAU.

Description how problem can be detected


- TAU is not rejected.

Description of the fault:


- TAU should be rejected when Update Location Answer received with ext-result Unknown Eps
Subscription.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 9.2-0
- LNX934G2.IMG 9.2-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Reject TAU when Update Location Area response is received with ext-result Unknown Eps
Subscription.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.118 NS16.50682 Update of the java jre

NA05959530 MME CPPU Restart

Summary of the problem


- jvm crash happened during threaddump collection.

How end user/operator could detect the problem:


- 1007 RESTARTED PROGRAM BLOCK alarms will be raised in CPPU with memory protection error
(0924 302d).

Description of the fault:


- The issue was caused by a bug of the used jre version 7u95.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 126/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Dependency on configuration:
- None

Faulty component and version:


- LNX91AG2 2.23-0 NS16.5

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- The jre is updated to a later version with fix provided by Oracle. The new jre is 7u111.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.119 NS16.50683 IPDU switchover caused by LNX92D (S1LBS) crash

NA05965981 (Flexi NS MME NS17)IPDU switchover in NS16 and NS17

Summary of the original problem:


- LNX92D (S1LBS) crashed, core dump was generated and automatic IPDU switchover occurred.

How end user/operator could detect the problem:


- IPDU switchover occurred & alarm 1023 was raised.

Description of the fault:


- While processing S1AP message in S1LBS the Linux ‘pthread_mutex_lock’ is used in the function that
determines the CPPU to forward the message. The referred mutex object was not initialized in the
common library code. According to the specification the behaviour of pthread_mutex_lock () is undefined
if the mutex object is not initialized and this caused the problem.

Dependency on configuration:
- None

Faulty component and version:


- LNX936G2.IMG 11.4-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 127/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- The pthread_mutex_init is called to initialize the mutex object that is used later during processing S1AP
messages.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.120 NS16.50684 Inconsistent ZD8F MML command output

PR161011 Inconsistent ZD8F MML command output

Summary of the original problem:


- The unit info in the output of D8 command could be duplicated occasionally.

How end user/operator could detect the problem:


- Execute ZD8I command.

Description of the fault:


- Units might be repetitively selected when create tasks for D8 command group, it can lead to an
inconsistent output.

Dependency on configuration:
- None

Faulty component and version:


- EUMANAGX.PAC 1.21-0

Faulty component first delivered in(e.g. release, CD):


- Y2 16.57-0

Workaround:
- None

Description of the correction:


- A mechanism is introduced to verify and filter out duplicated tasks before tasks get started.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 128/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Customer effects:
- None

Test requirements:
- None

2.121 NS16.50685 SGW relocation was not working during HO if TAI list prfile was disabled but TAI
list was configured

PR171522 NS17 - SGW relocation seems not working during ping pong HO if tai list prfile is
disabled but tai list configured

Summary of the original problem:


- SGW relocation seems not working during ping pong HO if TAI list prfile is disabled but TAI list is
configured.

How end user/operator could detect the problem:


- Intra MME S1HO performed with PR_NR_T_MME_SGW_RELOCATION enabled,
PR_NR_T_MME_TAI_LIST_IN_USE disabled and TAI list configured.

Description of the fault:


- When PR_NR_T_MME_SGW_RELOCATION is enabled, MME will load the configured taiList XML file
without checking the state of PrFile parameter PR_NR_T_MME_TAI_LIST_IN_USE.

Dependency on configuration:
- PR_NR_T_MME_SGW_RELOCATION is enabled,
- PR_NR_T_MME_TAI_LIST_IN_USE is disabled
- TaiList.xml is configured.

Faulty component and version:


- LNX924G2.IMG 12.4-0

Faulty component first delivered in(e.g. release, CD):


- NS 17

Workaround:
- None

Description of the correction:


- When PR_NR_T_MME_TAI_LIST_IN_USE is disabled but PR_NR_T_MME_SGW_RELOCATION is
enabled, the XML file should not be filled and SGW relocation should be performed.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 129/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.122 NS16.50686 Traffic is not recovered after kernel panic in active IPDU followed by IPDU
switchover.

PR176767 trHandler does not recover traffic after IPDU kernel panic

Summary of the original problem:


- After kernel panic in active IPDU followed by IPDU SWO (switchover), MME sent GTP message
continuously multiple times without any retry timer causing SGW to overload. This causes SGW
messages not to be answered and traffic got effected.

How end user/operator could detect the problem:


- GTP messages were sent for the same subscriber multiple times without any delay.

Description of the fault:


- During active IPDU restart, MME sets the associated interface timers to 0. This is to close the
procedures that are waiting for response but response could not be received due to restart. Timers are
set back to the original values, after the restarted IPDU came up as active unit only. In the case of IPDU
SWO after active IPDU restart, the associated Interface message timers were not set back to original
value from 0 as the restarted IPDU came up as spare and not as active due to the IPDU SWO. This
made the MME to identify timer is 0 and sent the request multiple time.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG, 11.5-27

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- Restart the new active IPDU with “ZUSU: IPDU,0:C=DSK;” MML command. MME will set back the
associated interface timers to the original values.

Description of the correction:


- With the new implementation during active IPDU restart, the associated timers will not be set to zero.
So, when the Spare IPDU comes up the Interface timers will still remain actual value. This will make sure
re-sending the Interface messages will happen with configured delay time. With delay time used, MME
waits to get response from other network elements before it resent.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- All Interface Message will be re-sent with MME configured delay.

Customer effects:
- Any KPI degrade will be avoided.

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 130/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.123 NS16.50687 In the output of ZBJB:EBSM MML command , if the eMBMS Service ID contains
0, 0 is not displayed

PR166638 eMBMS service ID containing 0, 0 is not displayed

Summary of the original problem:


- In ZBJB:EBSM MML command output, if the eMBMS Service ID contains 0, 0 was not displayed.

How end user/operator could detect the problem:


- By administrating BJB:EBSM; MML command and if eMBMS active sessions were present with Service
ID containing 0, 0 was not been displayed.

Description of the fault:


- Hexadecimal bytes that consist the eMBMS Service ID were displayed without leading zero as decimal
number.

Dependency on configuration:
- Active eMBMS sessions must be present with Service ID containing 0 value.

Faulty component and version:


- J5CHAN 5.6-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Leading zero is included in the hexadecimal bytes that consist the eMBMS service ID decimal format.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Customer will see the correct eMBMS Service ID in the BJB MML output.

Test requirements:
- Active eMBMS session with Service ID containing 0.

2.124 NS16.50688 PersistenceException: Missing identifier. (Cause:-) in MMDU SubsHandler on


IPDU WO GRP2 blade removal

PR178222 PersistenceException: Missing identifier. (Cause:-) in MMDU SubsHandler on


IPDU WO GRP2 blade removal

Summary of the original problem:


- PersistenceException: Missing identifier. (Cause:-) in MMDU SubsHandler on IPDU WO GRP2 blade
removal.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 131/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- X2HO procedure performed with invalid MME S1AP ID in PathSwitchRequest.

Description of the fault:


- Invalid MME S1AP ID in PathSwichRequest was sent to Subshandler but cannot found subscriber for
this IE, thus error occurred.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2 13.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 17

Workaround:
- None

Description of the correction:


- Check the MME S1AP ID in PathSwitchRequest before sending out eps_path_switch_request_s. If
MME S1AP ID is invalid, then send PathSwitchRequestFailure to eNB.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.125 NS16.50689 Check for active RABs failed and SCCP was released without IU-release.

PR182370 Check active RABs fails , SCCP release , missing IU-release.

Summary of the original problem:


- GSP GRP3 hand hang-up during periodic RAU and then SCCP will be released before send
IU-RELEASE-REQUEST to RNC.

Description of the problem:


- Before periodic RAU complete, RNC sent incorrectly RAU complete message to SGSN. This case
a time delay to GSP hand, and an internal mechanism of hand_supervision_msg_s begins to be involved
in flow. After this, follow the SCCP release before IU-RELEASE.

How end user/operator could detect the problem:


- IU release not correctly is done.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 132/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the fault:
- When GSP master begin to inform the gsp hand (with hand_supervision_msg_s) to release the iu and
SCCP connection, there is a checking of RAB existing. For RAB = 0 (because RNC sends incorrectly
RAU complete), the code doesn't have the right sequence of releasing messages. And thus, we see the
SCCP will be released before send IU-RELEASE to RNC.

Dependency on configuration:
- None

Faulty component and version:


- GSP_G6JX.PAC 30.23-0

Faulty component first delivered in(e.g. release, CD):


- NS15MP3 WU1

Workaround:
- None

Description of the correction:


- The hand_supervision_msg_s must have the correct way to release the connection, when we meet
RAB =0. Also, a rab check procedure must modify their parameter.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.126 NS16.50690 Traffic drop when an MMDU unit is unreachable (failure, restart, TE state)

PR190146 Composite Persistence not enabled during pair MMDU restart

Summary of the original problem:


- The first MMDU to become operational after system restart, was not able to serve its pair MMDU
subscribers during its pair MMDU restart.

How end user/operator could detect the problem:


- KPIs might drop because of:
- rejects in procedures using temporary identities instead of IMSIs while pair MMDU is down.
- duplicate subscribers in MMDUs, after the pair MMDU is up again.

Description of the fault:


- Connection URL to pair MMDU was not set correctly during MMDU start up for the MMDU of the pair
that became operational first. As a result, when its pair MMDU was unavailable because it was restarting,
MMDU was not able to connect to its secondary DB and serve the subscribers of its pair.

Dependency on configuration:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 133/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- LNX922G2.IMG 11.4-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- The correction makes sure that on each MMDU, the connections to pair MMDU database are re-
initialized, using the correct set of JDBC configuration properties, when pair MMDU changes state. This
way, the replica of pair MMDU database on each MMDU is reachable even if its pair is unavailable.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.127 NS16.50691 MME did not send SGsAP messages to VLR despite the fact that the UE cannot
be paged

PR176268 NS 15 - MME does not send SGsAP messages to VLR despite the fact that the UE
cannot be paged

Summary of the original problem:


- When the subscriber had two default bearers, the MME did not send SGsAP IMSI DETACH
INDICATION messages to VLR when the UE couldn’t be paged.

How end user/operator could detect the problem:


- By performing attach procedure using two default bearers. Then, UE goes to idle. GW sends a bearer
deactivation for both PDNs. However, the paging procedure failed because the UE is unreachable. The
MME did not send IMSI DETACH INDICATION messages to VLR in order to inform VLR about UE's
unavailability.

Description of the fault:


- When the subscriber was attached with two default bearers and went in idle mode, GW did send bearer
deactivation for both PDNs. However, the paging failed as the UE was not reachable. As a result, the
MME should sent IMSI DETACH INDICATION messages to VLR in order to inform VLR about UE's
unavailability. Instead, the MME did not send the IMSI DETACH INDICATION messages due to the fact
that the UE has two bearers established. In case of one bearer established the MME behaves correctly.

Related feature / functionality:


- None

Dependency on configuration:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 134/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
- None

Description of the correction:


- After the correction, the MME can check if the bearer in Delete Bearer Request is the last bearer and
then will trigger the NW Detach and send out the following sgs-imsi-detach-indication message to MSC.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 11.1-0

Faulty component first delivered in(e.g. release, CD):


- NS15

2.128 NS16.50692 MME NS16(N6_1_24_0) MME seem cannot deal with collision between detach
with create bearer procedure

PR166064 MME NS16(N6_1_24_0) MME seem cannot deal with collision between detach
with create bearer procedure

Summary of the original problem:


- When ongoing detach and incoming MPS bearer activation collided, MME held the detach and
continued with the bearer activation.

Description of the problem


- When ongoing detach and incoming MPS bearer activation collide, MME held the detach and continued
with the bearer activation.

How end user/operator could detect the problem:


- When ongoing detach and incoming MPS bearer activation collide, MME holds the detach and
continues with the bearer activation. So, when UE sends UE context release request to MME, the MME
sends UE context release command with detach ENB response ERROR indication (with unknown pair ue
s1ap id).

Description of the fault:


- The wrong collision resolver between ongoing detach and incoming MPS bearer activation.

Dependency on configuration:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 135/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- LNX934G2 7.1.5-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Change the collision resolver to DOCI.
- MME will drop incoming bearer activation no matter priority, detach will continue.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.129 NS16.50693 MME downgration of MBR during dedicated bearer creation

PR160188 NS17 Feature - FC085_3653_us1_CR1771_MME downgrades the MBR

Summary of the original problem:


- During dedicated bearer creation or modification, the MME selected the lower value of the range of
Maximum Bit Rates provided by SGW.

How end user/operator could detect the problem:


- Lower QoS is delivered to end users that requested one.

Description of the fault:


- During conversion of bit rates (UL/DL) from predefined ranges that were received from SGW the MME
selected the lower value.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.33-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- The problem was fixed and for the rate for UL and DL bit rate the upper limit was chosen.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 136/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- Correct bit UL/DL bit rate will be delivered to UE (S1 Interface).

Customer effects:
- Correct bit UL/DL bit rate will be delivered to UE (S1 Interface).

Test requirements:
- All the ranges of bit rates that are supposed to be propagated on the NAS interface must be tested.
There are no preconditions needed for the issue to be tested.

2.130 NS16.50694 Deactivate non-emergency bearers for a roaming LBO subscriber in TAU when
"VPLMN-Dynamic-Address-Allowed" is false in subscription data

PR151166 During InterMME HO roaming subscriber LBO, partial TAU bearers should be
deleted other than emergency, when VPLMN dynamic is not allowed in ULA

Summary of the original problem:


- Deactivate non-emergency bearers for a roaming LBO (Local Break Out) subscriber in TAU (Tracking
Area Update) when "VPLMN-Dynamic-Address-Allowed" is false in subscription data.

How end user/operator could detect the problem:


- Non-emergency bearers are not deactivated for a roaming LBO subscriber during TAU when HSS
sends "VPLMN-Dynamic-Address-Allowed" as false in subscription data. It can be seen from Wireshark
logs.

Description of the fault:


- Non-emergency bearers are not deactivated for a roaming LBO subscriber during TAU and MME is not
rejecting TAU if UE does InterMME Hand Over with last non-emergency PDN when HSS sends "VPLMN-
Dynamic-Address-Allowed" as false in subscription data.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.10
- LNX924G2.IMG 7.10

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Non-emergency bearers are deactivated and MME will reject TAU in case if UE does InterMME Hand
Over with last non-emergency PDN when HSS sends "VPLMN-Dynamic-Address-Allowed" as false in
subscription data.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 137/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- None

Interface effects:
- None

Customer effects:
- Bearers will be in Sync between MME, UE and GW in this scenario.

Test requirements:
- UE performs interMME Hand Over followed by TAU with one or more non-emergency bearer/s. HSS
sends "VPLMN-Dynamic-Address-Allowed" as false in subscription data.

2.131 NS16.50695 Reason for GBU unit switchover in BIH SGSN-6 after SW upgrade

NA05945528 Reason for GBU unit switchover in BIH SGSN-6 after NS15 upgradation

Summary of the original problem:


- GBU switchover occurred due to process exception in GGB. Exception was caused by RIM packets
RAN_INFORMATION_REQUEST with invalid length information in the BSSGP decode function.

How end user/operator could detect the problem:


- By detecting GBU switchover and alarm 1078.

Description of the fault:


- The problem occurred in BSSGP decode function when processing IE Length identifier of
source_cell_id.
The length extension bit is used to decide the length of the information element
(0: 2 octets, 1: 1 octet)
In case of destination_cell_id where length is 0x89, the size of IE is properly calculated to 9 because
length extension bit is 1, so 1 octet is used.
In case of source_cell_id where length its 0x09, the size of IE is calculated to 9* 256 =2304 because
length extension bit is 0, so 2 octets is used to calculate length. 2304 is bigger than the maximum size of
sdu (1600) so, in the process of the next IE (RAN_information_request_RIM_container) an index out of
bounds will be assigned to the sdu table and a process exception will occur, which will lead to GBU
switchover.

Related feature / functionality:


- None

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- A protective mechanism is introduced in GGB so when a RIM message arrives with invalid length for an
information element, code will not assign to a table an index out of bounds. A status response will be sent
to sender with cause “Semantically incorrect PDU”. It is advisable to use correct length extension bit for
IE length when RIM packets (Ran information request) are being sent to SGSN. 0x89 should be sent like
in the destination cell id IE, instead of 0x09.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 138/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- GGB_G6JX.PAC 15.7-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP3

Faulty component and version:


- GGB_G6JX.PAC 15.7-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP3

2.132 NS16.50696 Fluctuation on all BSCs GB Links

NA05760300 Fluctuation on all BSCs GB Links

Summary of the original problem:


- Fluctuation on all BSCs GB Links.

How end user/operator could detect the problem:


- Set alarm 1010 to the same FRIU twice.

Description of the fault:


- A huge amount of CPU interrupts that are raised in a short time can cause CPU overload. As a result,
the unit_supervision_msg cannot been handled in time and "1010" alarm is reported. In case a certain
amount of "1010" alarms is reported in a specific amount of time (3 mins) this will cause 1598 alarm and
FRIU recovery mechanism will start causing FRIU unit restart.

Related feature / functionality:


- None

Dependency on configuration:
- FRIU

Workaround:
- None

Description of the correction:


- When huge amount of pm8310 interrupts raised, when SDH driver detect more than threshold interrupts
handled in one second, then SDH driver will delay 3 seconds not to handling the interrupts to release the
CPU occupied.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 139/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LN071C06.IMG 3.105-0
- LNXSCR06.IMG 3.105-0
- LNXUBO06.IMG 3.105-0
- LNX93BG3.IMG 2.19-0

Faulty component first delivered in(e.g. release, CD):


- NS3.0 2.0 WU1

2.133 NS16.50697 Mishandling of ongoing attach procedure - incoming detach procedure collision

NA05979608 (Flexi NS MME 16.5)attach request and detach request collision handling

Summary of the original problem:


- Mishandling of ongoing attach procedure - incoming detach procedure collision. If UE is already
attached and detach (after collision with attach) fails due to security the emm state of the subscriber is
set to deregistered.

How end user/operator could detect the problem:


- The end user would not detect the problem.
- The operator would observe that although the attach procedure was terminated as should, the detach
procedure was dropped due to security failure. So, if UE tried to attach again (double attach case) no
Delete Session Request is sent to SGW as the emm state is wrongly set to DEREGISTERED.

Description of the fault:


- In the case of an ongoing attach procedure and an incoming detach procedure's collision, the attach
procedure was terminated and set the state of the subscriber to DEREGISTERED state. However, if UE
was already attached and the incoming detach failed due to security the subscriber is set wrongly to
DEREGISTERED state. As a result, the next attach (double attach case) will not send Delete Session
Request to SGW. So, hanging sessions will remain in SGW.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2 11.13-30

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 140/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
- None

Description of the correction:


- In case of Attach and Detach collision, the Detach procedure will handle the EMM state of the
subscriber and not the attach terminate end state.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.134 NS16.50698 Inter PLMN TAU in Create session request, ServingNetworkValue PLMN was not
changed to new PLMN

PR148635 NS17: servingNetworkValue is not changed during Inter PLMN TAU in Create
session request

Summary of the original problem:


- ServingNetworkValue was not changed during Inter PLMN TAU in Create session request.

How end user/operator could detect the problem:


- Create Session Request message was sent with old plmnId in ServingNetwork IE in case of inter PLMN
TAU with SGW change.

Description of the fault:


- During Inter PLMN TAU with SGW change, PLMN id was different in guti and TAI, but the
servingNetworkValue was not changed to new PLMN ID in TAI in the create session request. CSR
contained the old plmn id.

Related feature / functionality:


- None

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- During inter PLMN TAU with sgw change, plmn id in TAI will be set to serving network value in Create
Session Request.

Effects on end-user:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 141/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Effects on operator:
- Billing will be proper

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX924G2.IMG too legacy to be specified.

Faulty component first delivered in(e.g. release, CD):


- NS15

2.135 NS16.50699 Cause value "unspecified" in UEContextReleaseCommand for SRVCC


cancellation

NA05930961 When SRVCC Cancel occurs what is correct cause in UEContextRelease for
MME to send

Summary of the original problem:


- Cause value "unspecified" in UE Context Release Command for SRVCC cancellation.

How end user/operator could detect the problem:


- Due to "UEContextReleaseCommand" from MME to old eNB with cause=unspecified, old eNB-A
incremented VoLTE drop counter.

Description of the fault:


- During UE handover from LTE(eNB-A) to GERAN, air connection between UE and eNB-A was lost due
to some reason. UE moved to a new eNB-B and established connection, thus two UE contexts were
present at same time. So MME released the old S1 connection and sent UE CONTEXT RELEASE
COMMAND to old eNB with cause "unspecified".

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.58-0
- LNX924G2.IMG 11.42-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- The Cause Code will be sent in UE CONTEXT RELEASE COMMAND can be modified based on the INI
file parameter value, described in the "Special Conditions for Installation" field. This is not only for
SRVCC scenario but also for all scenarios which need to release old S1 connection. In detail, when the
"OperatorType" is set to 1, the S1AP Cause Code value will be "normal release". In any other case, the
S1AP Cause Code value will be "Release due to E-UTRAN generated reason".

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 142/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Effects on operator:
- Increment of the call drop counter.

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Test requirements:
- None

2.136 NS16.50700 Improper time was set when adjusting both time and summer time ON in one
ZDCT MML command

NA05906119 MSS -P : MML ZDCT to make SUMMER TIME ON behaved differently for
MSS/MGW/CDS

Summary of the original problem:


- When ZDCT:ST=ON: future time; and ZDCT:ST=ON; are executed, the time will be forwarded two
hours.

How end user/operator could detect the problem:


- execute ZDCT:ST=ON: future time;
- execute ZDCT:ST=ON;
- execute ZDCD; to check time.

Description of the fault:


- ZDCT:ST=ON; this MML command forwards one hour immediately.
- ZDCT:ST=ON: future time; when the future time was reached, the time was forwarded one more hour
without checking if summer time was already on or not.

Workaround:
- None

Dependency on configuration:
- None

Description of the correction:


- When the future time is reached, summer time will be checked if it is opened or not.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 143/231


D553209967 © Nokia 2016
Version 1.0
Confidential
System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- OCLOCKGX.PAC 2.27-0

Faulty component first delivered in(e.g. release, CD):


- B12 28.29-0

2.137 NS16.50701 Multiple MMEs had alarming issues

NA05909052 Multiple MMEs having Alarming issues - NS16 (previous case, NA05880373)

Summary of the original problem:


- Alarms from MME could not be uploaded to NetAct due to NE3SAG exception.

How end user/operator could detect the problem:


- When NetAct 15.5 was connected with NS16, NE3S exceptions randomly occurred.

Description of the fault:


- When memory request fails, function "strerror" is called, but "strerror" was wild pointer and caused an
exception.

Dependency on configuration:
- None

Faulty component and version:


- NE3SAGGX.PAC 8.15-20

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- A header file is added, so as to avoid the "strerror" to become a wild pointer.

Risk analysis of the correction:


- None

Correction effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 144/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.138 NS16.50702 Collision between Service Request Procedure and S1 Release causes OLC drop
due to CPPU holding ticket for S1 Release Procedure

PR165423 CPPU ticket is held at least 500ms in case ongoing Service Request colliding with
incoming eNB initiated S1 Release

Summary of the original problem:


- Collision between Service Request Procedure and S1 Release causes OLC drop due to CPPU holding
ticket for S1 Release Procedure.

How end user/operator could detect the problem:


- OLC drop for S1 Release procedure in CPPU logs.

Description of the fault:


- When CPPU does not get the response from SGW in Service Request and NW detach is triggered, in
this point, eNB also triggers the S1 release procedure. Collision occurs and Service Request is
terminated, but in CPPU there is no transition to consume the message from MMDU to terminate the
ongoing Service Request. This caused CPPU's ticket for S1 release to be held for at least 500ms. MMDU
also waited for 500ms to get a response from CPPU before starting S1 Release procedure.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 13.4-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Changed collision handling between ongoing Service Request and incoming S1 Release as explained
below: If NW Detach is started as part of Service Request, then drop incoming S1 Release and continue
with ongoing Service Request. If NW Detach is not started as part of Service Request and S1 Release is
for the same S1 Connection, then drop Service Request and continue with S1 Release. If NW Detach is
not started as part of Service Request and S1 Release is for the different S1 Connection, then continue
both procedures in parallel. Now MMDU won't send message to terminate the procedure in CPPU when
NW Detach is triggered as part of Service Request then S1 Release will get a response immediately and
ticket in CPPU will be released quickly.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- KPI for S1 Release will improve.

Test requirements:
- SGW should not respond to MME in ServiceRequest, MME should trigger NW Detach, S1 Release
must be triggered from ENB side.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 145/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.139 NS16.50703 Support of EPS info in ULR.

PR159345 Support of EPS info in ULR.

Summary of the original problem:


- SGSN does not set initial attach indicator into EPS Info parameter, after initial attach, when UE is
stating EPC capability.

How end user/operator could detect the problem:


- EPS info IE isn't included in "Update Gprs Location Request" message and initialAttachIndicator isn't
set after initial attach, when UE is stating EPC capability.

Description of the fault:


- In MTA protocol, the info_type isr_info is not encoded in the version of the MTA code that SGSN
includes in its build. In addition, GRN program block does not set "initial Attach Indicator" in initial attach
procedure when UE is stating EPC capability.

Dependency on configuration:
- Subscriber is EPC capable and new PRFILE Parameter 002:2492 is ON.

Faulty component and version:


- MTA_IXMX.PAC 14.1-37
- GRN_GSJX.PAC 21.3-0

Faulty component first delivered in(e.g. release, CD):


- NS 17

Workaround:
- None

Description of the correction:


- New PRFILE Parameter 002:2492 is created in order to control this functionality.
- In MTA, the info_type isr_info is encoded in the version of the MTA code that SGSN includes in its build.
- In GRN, set "initial Attach Indicator" in initial attach procure when UE is stating EPC capability and new
PRFILE Parameter 002:2492 is ON.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- SGSN
- HLR/IWMSC/GMSC/EIR/GMLC interface.

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 146/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.140 NS16.50704 OpenSSH ≤ 7.3 - Denial of Service Vulnerability - CVE-2016-8858

PR193204 OpenSSH ≤ 7.3 - Denial of Service Vulnerability - CVE-2016-8858

Summary of the original problem:


- The vulnerability of denial of service was found on openssh.

How end user/operator could detect the problem:


- This problem was reported as CVE-2016-8858.

Description of the fault:


- A memory exhaustion issue in OpenSSH that can be triggered before user authentication was found.
An unauthenticated attacker could consume approx. 400 MB of memory per each connection. The
attacker could set up multiple such connections to run out of server’s memory.

Dependency on configuration:
- The ssh or sftp service is enabled.

Faulty component and version:


- KANALAGX.PAC 3.24-0

Faulty component first delivered in(e.g. release, CD):


- Too legacy to be defined.

Workaround:
- None

Description of the correction:


- Unregister the KEXINIT handler after message has been received.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- The patch of CVE-2016-8858.

Test requirements:
- Enable the ssh or sftp server.

2.141 NS16.50705 The MME send the wrong S1U ip address to enodeb

NA05975474 (Flexi NS-SGSN/MME NS16.5)The MME send the wrong S1U ip address to
enodeb

Summary of the original problem:


- After Inter-System TAU failure in Initial context setup procedure, MO-CSFB call procedure fails. MME is
sending ICSR message with Transport Layer Address and GTP-TEID filled with zeros.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 147/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- After Inter-System TAU failure in Initial context setup procedure, MO-CSFB call procedure would fail.

Description of the fault:


- After Inter-System TAU failure in Initial context setup procedure, S-GW user plane TEID and IP address
for S1-U was not stored in MMDU. As a result, in following MO-CSFB MME was sending Initial context
setup message with Transport Layer Address and GTP-TEID filled with zeros.
- Furthermore, when Inter-System TAU failed in Initial context setup procedure, in case subscriber was
not already stored in MMDU, would not be finalized. Even if subscriber was stored in MMDU or not, on
CPPU side a Delete Session Request message was sent to S-GW. This behaviour was only correct in
the case when the subscriber was not stored in MMDU (not right in case subscriber was already stored in
MMDU).

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.133-0
- LNX924G2.IMG 11.113-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- After Inter-System TAU failure in Initial context setup procedure, S-GW user plane TEID and IP address
for S1-U will be stored in MMDU only in case subscriber is already persisted in MMDU.
- Furthermore, when Inter-System TAU fails in Initial context setup procedure, in case subscriber is not
already stored in MMDU (will not be finalized in TAU complete) Delete Session Request message will be
sent as part of Inter-System TAU failure. On the other hand, in case subscriber is already persisted in
MMDU, Delete Session Request message will not be sent as part Inter-System TAU failure.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Subscriber performs a combined attach, then moves to 3G with inter-system RAU, returns to 4G with
inter-system TAU which fails in initial context setup procedure. Afterwards UE performs MO-CSFB and
then detach.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 148/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.142 NS16.50706 Intra MME TAU related counters (M50C038 and M50C044) increased during Inter
System TAU.

NA05977910 Need to know how the counter M50C044 works and updated.

Summary of the original problem:


- When CPPU received a TAU request with GUTI which was not allocated by current MME, DNS query
was needed for getting old SGSN/MME address. But if DNS query was disabled or DNS query failed,
CPPU fell back the TAU to Intra MME TAU, which caused the intra MME TAU related counters
(M50C038 and M50C044) to increase.

How end user/operator could detect the problem:


- Customer experienced sudden Increase in the Failure Rate of counter (M50C044 / EPS INTRA MME
TAU FAIL) after enabled SGs and Gn interface. Also, Counter EPS_CMB_INTRA_TAU_IMSI_ATT_FAI
(M50C038) increased a lot after implement SGs.

Description of the fault:


- Different implementation approaches for InterSystem TAU in CPPU and MMDU. In TrHandler
InterSystem and (intra) TAU use some common procedure States (same code) and the procedure code
changes from InterSystem TAU to TAU. In SubsHandler the implementation is separated.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- MMDU needs to check whether GUTI was allocated by current MME or not in intra MME TAU, then
increase the matched counter.

Risk analysis of the correction:


- Customer may experience different statistics values for these counters (and for the related formulas)
from that is used to be in the past. Values of this counter before and after the correction may be not
comparable.

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 8.71-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 149/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.143 NS16.50707 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718

PR158441 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718

Summary of the original problem:


- Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718.

How end user/operator could detect the problem:


- Report by Third-party Open Source test group for security issue.

Description of the fault:


- The Expat XML parser mishandles certain kinds of malformed input documents, resulting in buffer
overflows during processing and error reporting. The overflows can manifest as a segmentation fault or
as memory corruption during a parse operation. The bugs allow for a denial of service attack in many
applications by an unauthenticated attacker, and could conceivably result in remote code execution.

Dependency on configuration:
- None

Faulty component and version:


- Version too legacy to be specified.

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Two vulnerabilities have been reported in Expat, which can be exploited by malicious people to cause a
DoS (Denial of Service) or potentially compromise an application using the library.
1) An integer overflow error in the “XML_GetBuffer ()” function (lib/xmlparse.c) can be exploited to cause
a heap-based buffer overflow.
2) Another integer overflow error in the “XML_GetBuffer ()” function (lib/xmlparse.c) can be exploited to
trigger an infinite loop.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 150/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.144 NS16.50708 Commissioning is failing in ZQRN:GBU command in NS15 MP2 after N5 1.20-0
frozen SW build

PR153584 Commissioning is failing in ZQRN:GBU command in NS15 MP2 after N5 1.20-0


frozen SW build

Summary of the original problem:


- When large numbers of units need to be configured with IP and routes, it will fail on continuously IP
configuration when most of the units will have been finished the configuration job. (Note: the error only
occurs on higher version of build; old build has no such error).

How end user/operator could detect the problem:


- Configure 50+ units including IPDU and continuously configure logical IP address for each unit.

Description of the fault:


- Every time the IP configuration data is changed on one unit, all the units in system have to ask for the
newest IP data from OMU for xiplib synchronization. In PR070625, the mechanism of asking IP data from
OMU for lindx unit has been changed leading to big increment of requests to OMU from Lindx unit. This
influences other units synch job. In this case, when GBU is restarted by first configuring logic IP address,
during system start up JAPILA will ask xiplib data from OMU but it takes much longer time than before.
This causes JASPRB to be unable to finish IP configuration data reassignment timely, even if GBU's
state has changed to WO-EX. So, when user finds GBU is WO-EX, he will continue IP configuration but
actually the interface has not yet been assigned to kernel already and error shows up.

Dependency on configuration:
- It should contain large numbers of units which include both DMX and lindx units and configuring a
certain number of logical IP address for each of them.

Faulty component and version:


- LNX709G2.IMG 7.10-0 to LNX709G2 7.28-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP2

Workaround:
- Add delay in ZQRN MML commands to make the IP configuration speed down.

Description of the correction:


- Roll back the change of PR070625.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 151/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.145 NS16.50709 Security Test - TCP SYN flood attack against OMU Telnet port - UNIT restart

PR172955 Security Test - TCP SYN flood attack against OMU Telnet port - UNIT restart

Summary of the original problem:


- OMU restart during DoS attack.

How end user/operator could detect the problem:


- DoS attack on Ethernet port.

Description of the fault:


- In multi-core environment, because sufficient CPU resources, both WYNONA and POZMAN will be
scheduled from CPU to CPU and run all the time even with lower WYNONA priority 0x4F. It will cause
overload and block other processes.
- Another issue is that WYNONA el hand priority was changed to 0xF4 by CPUPROGX during DoS
attack, and priority 0xF4 will cause unit restart because of message flood. So, WYNONA el hand priority
should remain 0x4F under overload/DoS situation.

Dependency on configuration:
- None

Faulty component and version:


- WYNONAGX.PAC 10.14-0
- CPUPROGX.PAC 9.22-0

Faulty component first delivered in(e.g. release, CD):


- NS16.5 MP1

Workaround:
- None

Description of the correction:


- During overload, binding WYNONA el hand and POZMAN net hand to second CPU.
- Fix CPUPRO write stack log problem that it doesn't change WYNONA el hand priority to 0xF4 when
print WYNONA stack.

Risk analysis of the correction:


- None

Correction effects:
- It will avoid unit restart during DoS attack.

Interface effects:
- None

Customer effects:
- It will help customer to avoid unit restart during DoS attack.

Test requirements:
-Run DoS attack on Ethernet port.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 152/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.146 NS16.50710 MME generated APN NI as LBO mode for HRT PDNs in Context Response and
Create Session Request message when emergence PDN was active

PR159734 APNOI part of Access point name IE for HRT Subscriber is not filled properly
during TAU with SGW relocation

PR159847 NS17 Provocative - Roaming parameters are not transferred correctly in Context
Response during Inter MME TAU when emergency PDN is established.

Summary of the original problem:


- When emergence PDN was active, MME generated APN NI as LBO mode for HRT PDNs in Context
Response and Create Session Request message.

How end user/operator could detect the problem:


- Establish the emergency PDN for HRT Roaming subscriber; Then trigger inter MME TAU as source
MME or intra MME TAU with SGW change.

Description of the fault:


- When emergency PDN was active, MME treated all PDNs as LBO PDNs even if they are originally HRT
mode.

Dependency on configuration:
- Emergency call is enable, only HRT roaming is enable.

Faulty component and version:


- LNX924G2.IMG 7.1-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- APN NI will be generated according to the roaming mode of the PDN. Emergency PDN is always LBO.

Risk analysis of the correction:


- None

Correction effects:
- APN NI in the Context Response and Create Session Request will be accordant to the roaming mode.

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 153/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.147 NS16.50711 Delete Session Request did not had the proper value in the field of Tunnel
Endpoint Id

PR160109 Delete_session_failure_prfile_2241_ARP for non emergency services

Summary of the original problem:


- Delete Session Request did not had the proper value in the field of Tunnel Endpoint Id (TEID) in case
the Create Session Response ARP value had the same value as set in MME EMDATA.

How end user/operator could detect the problem:


- From the SGW side it could have probably detected some resources bounded although the sessions
were ended. Also, could be observed from the cause "Context not Found" of the Delete Session
Response.

Description of the fault:


- In case of a normal attach procedure, if the ARP value has been changed in Create Session Response
to the value that is set as emergency ARP in the MME for a non-emergency service the TEID in Delete
Session Request is not filled properly.

Dependency on configuration:
- This requires PRFILES 2241 and IMS emergency call support PRFILE 2220 to be enabled in MME.

Faulty component and version:


- LNX924G2.IMG (too legacy to be defined).

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- The proper value from Create Session Response is stored and used later in Delete Session Request so
the correct TEID is set.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- In order to test the fix both the ARP for non-emergency services feature and the IMS emergency call
support feature should be enabled.
- A subscriber should try to attach and should try to establish a non-emergency bearer. The SGW should
send a Create Session Response which will set the ARP value to the same value that the MME EMDATA
is set.
- This will lead MME to raise the alarm "(1554) 3847 EMERGENCY ARP USED FOR NON-
EMERGENCY SERVICES" send an attach reject to the UE and a Delete Session Request to SGW.
- Expected Results:
- The Delete Session Request to SGW should have the proper value in TEID field.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 154/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.148 NS16.50712 Decrease of Inter-PAPU RAU Success Ratio after RNC rehoming

NA05943664 Big decrease of Inter-PAPU RAU Success Ratio after RNC rehoming

Summary of the original problem:


- RNC rehoming from one SGSN (e.g. SGSN-1) to another one (e.g. SGSN-2) can cause a decrease in
the following KPI counters:
- Iu periodic RA update success ratio (normal behaviour).
- Iu inter PAPU RA update success ratio.

How end user/operator could detect the problem:


- Big decrease of Inter-PAPU RAU Success ratio after RNC rehoming from another SGSN.

Description of the fault:


- Big decrease of Inter-PAPU RAU Success ratio after RNC rehoming from another SGSN
Preconditions for KPI drop:
1. RNC is rehomed from “old” SGSN-1 to “new” SGSN-2.
2. In “new” SGSN-2, RNC is configured in PAPU group (LRAS feature enabled).
3. Features “SGSN Multipoint Iu” (feature code: 351) and “SGSN Multipoint Gb” (feature code: 395) are
disabled.
4. SGSN-ID has not been configured in new SGSN-2.

After RNC rehoming to SGSN-2, it can be noticed big decrease in following KPI counters:

1. Iu periodic RA update success ratio (normal behaviour):

This decrease in success rate of Periodic RAU it is normal behaviour as:


a. 3G subscribers that have been attached previously to SGSN-1 have already been allocated P-TMSI
from this SGSN-1
b. As RNC rehoming normally takes place in non-peak-hours, most of the subscribers will be in “PMM-
IDLE state” during re-homing.
c. At expiration of “Periodic-RAU timer” (default value: 180 minutes), those subscribers perform a “Iu
Periodic RA update request” to new SGSN-2, with P-TMSI of SGSN-1.
d. SGSN-2 receives this Periodic-RAU with an unknown P-TMSI which indicates that is “Local-TLLI”,
e. SGSN-2 rejects the Periodic-RAU with internal cause “unknown MS”. This is normal behaviour
f. Finally, UE performs a new attach to SGSN-2.

KPI “Iu periodic RA update success ratio, e2e” (FLNS_529A) is restored back to normal values after
expiration of “periodic RAU timer” (e.g. 180 minutes). From that point onwards, all subscribers have
already performed fresh attach to SGSN-2, so they have been allocated P-TMSIs from new SGSN.
These results that Periodic-RAUs are not failing anymore.

2. Iu inter PAPU RA update success ratio:

In parallel with already mentioned above Periodic-RAU update success ratio, it has been observed big
decrease in success ratio of Inter PAPU RAU (FLNS_525A).

Behaviour is similar with previous mentioned KPI for Periodic-RAU, except steps “e” onwards:
a. 3G subscribers that have been attached previously to SGSN-1 have already been allocated P-TMSI
from this SGSN-1.
b. As RNC rehoming normally takes place in non-peak-hours, most of the subscribers will be in “PMM-
IDLE state” during re-homing.
c. At expiration of “Periodic-RAU timer” (default value: 180 minutes), those subscribers perform a “Iu
Periodic RA update request” to new SGSN-2, with P-TMSI of SGSN-1.
d. SGSN-2 receives this Periodic-RAU with an unknown P-TMSI which indicates that is “Local-TLLI”,
e. P-TMSI bits includes also SGSN-ID & PAPU-ID. For some Periodic-RAUs (depending on the P-TMSI
value), SGSN wrongly identifies that this subscriber is handled by another PAPU of same SGSN-2.
f. So, procedure is identified as “inter PAPU RAU”. However, this PAPU which PTMSI is pointing to, it
does not exist in SGSN-2.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 155/231
D553209967 © Nokia 2016
Version 1.0
Confidential
g. SGSN creates an “gtp_sgsn_context_req_s” with gtp_ip_info (own PAPU IP address)
=255.255.255.255 (FF.FF.FF. FF).
h. GUD receives this illegal IP-address, but cannot route accordingly this message.
i. Above Inter-PAPU-RAU finally fails either with:
cause “unknow_ms” (after expiration of an internal timer of 26 seconds) or with “collision” with another
Periodic-RAU (in case that UE re-attempts a new P-RAU in these 26 second times period).

Dependency on configuration:
1. RNC is rehomed from “old” SGSN-1 to “new” SGSN-2.
2. In “new” SGSN-2, RNC is configured in PAPU group (LRAS feature enabled).
3. Features “SGSN Multipoint Iu” (feature code: 351) and “SGSN Multipoint Gb” (feature code: 395) are
disabled
4. SGSN-ID has not been configured in new SGSN-2.

Workaround:
- SGSN-ID has to be configured.

Description of the correction:


- During the unpack procedure of RAU request, after it is identified that a PAPU group exists, a procedure
is called to retrieve the PAPU index from PTMSI/TLLI. In this procedure
(con_get_papu_id_based_on_tlli), a check exists whether the TLLI is local or foreign. After this, the next
check that is performed is whether there is a SGSN-id used. In this check, normally as there is a valid
SGSN-id configured, this procedure is ended by returning the type of computer and the unpack or RAU
request proceeds successfully. After this check, a procedure is called in GMG source code
(gmg_get_papu_ip_addr) that gets the PAPU IP-address based on PAPU computer address. Inside this
procedure, the first check that it is performed is the value of g_gmg_papu_ip_table. ip_addresses
(s_papu_index). ipv6_exist. This is where the problem was identified. During the initialization of
g_gmg_papu_ip_table we set this value to FF. As this is a boolean, every other value than 00 will be
translated to True. So, this check is considered as True and the computer IP address is filled with the
value of computer IP v6 address, which of course is FF. The correction is to check if the IP has a value
other than FF and if it has to return successfully the IP if it does not, then it should continue and check if
IPv4 exist.

Risk analysis of the correction:


- None

Faulty component and version:


- GMG_G6JX 27.174-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP3

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 156/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.149 NS16.50713 ZD8I output for AHUB3-A IPMC was incorrect

PR174015 ZD8I output for AHUB3-A IPMC incorrect

Summary of the original problem:


- ZD8I command output, presenting the IPMC version, was occasionally messy.

How end user/operator could detect the problem:


- By executing ZD8IMML command continuously.

Description of the fault:


- Sometimes switch was sending one telnet echo of one command in two different packets resulting in
TFD parsing the reply with improper key word.

Dependency on configuration:
- None

Faulty component and version:


- TFDHCPGX.PAC 11.11-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- If command will be executed again, the output is correct.

Description of the correction:


- TFD parses the reply with proper key word now.

Risk analysis of the correction:


- None

Correction effects:
- None

2.150 NS16.50714 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718

PR158892 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718

Summary of the original problem:


- Security vulnerability: Expat XML Parser Crashes on Malformed Input.

How end user/operator could detect the problem:


- When certain malformed XML document were inputted.

Description of the fault:


- The Expat XML parser mishandled certain kinds of malformed input documents, resulting in buffer
overflows during processing and error reporting. The overflows can manifest as a segmentation fault or
as memory corruption during a parse operation. The bugs allowed for a denial of service attack in many
applications by an unauthenticated attacker, and could conceivably result in remote code execution.

Dependency on configuration:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 157/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- LN071C00 4.1-0
- LN071C01 4.1-0
- LN071C05 4.1-0
- LN071C07 4.1-0
- LN071C04 4.1-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Patch from expat community is added.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- This correction cannot be tested using the operator interface commands. The correction has been
tested internally in Nokia test lab and proved to be fully functional

2.151 NS16.50715 MME does not handle correctly the collision between Intersystem TAU
procedure - Update Bearer Request procedure

PR153492 MME does not handle correctly the collision between Intersystem TAU procedure -
Update Bearer Request procedure

NA05932798 50 % decrease in bearer modification SR

NA05934940 MME sent “Detach Request” with cause “Re-attach required” to ENB after
successful CSFB

Summary of the original problem:


- During Inter System TAU and after Modify Bearer Command message of HSS Initiated Bearer
Modification procedure, SGW was sending message Update Bearer Request so as to change AMBR
from 10240 / 160000 to 56K / 56K. Resolution of collision between GW initiated Update Bearer Request
and Intersystem TAU QoS modification was "drop ongoing procedure and continue incoming", thus IS
TAU QoS Modification procedure was terminated. The problem was that the message Modify Bearer
Command of IS TAU QoS initiated bearer modification had already been sent before the termination of
the procedure. This caused SGW to send Update Bearer Request message. This message has the same
sequence number with the ITAU procedure and MME rejects the update bearer request message with
cause "reason not specified" and as a result, nw initiated detach with cause "re-attach required" was
triggered.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 158/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- End user could not detect the problem as the UE during IS TAU is in IDLE mode.

Description of the fault:


- Since resolution between IS TAU QoS modification and GW initiated Update Bearer Request was
"DropOngoingContinueIncoming" after Modify Bearer Command had been sent Update Bearer Request
that was received as part of GW Initiated Update Bearer Request had the same sequence number as
Modify bearer command of IS TAU QoS Modification which was already terminated and MME could not
consume it to any procedure. As a result, network, initiated detach with cause "re-attach required" was
triggered.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.13-7

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Resolution of collision between Intersystem TAU QoS modification and Update Bearer Request is
changed so as to continues both Intersystem TAU and GW initiated Update Bearer Request procedure.

Risk analysis of the correction:


- Wrong QoS value to be requested from eNB.

Correction effects:
- Collision resolution between GW initiated Update Bearer Request and Intersystem TAU QoS
modification is now changed to Continue Ongoing (IS TAU QoS Modification) and Continue Incoming
GW Initiated Bearer Modification. Also, we have a new INI file parameter that we can fall back the
functionality to the previous resolution Drop Ongoing Continue Incoming.

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.152 NS16.50716 Collision handling between ongoing Dedicated Bearer Activation and incoming
UE Initiated Tracking Area Update was not correct.

NA05977669 NS16.5_PILOT: QCI1 Included in MBR But Not Included in TAU Request

NA05977926 NS16.5_PILOT: Dedicated Bearer Success Rate Went Down After Loading
NS16.5 PCD

Summary of the original problem:


- Collision handling between ongoing Dedicated Bearer Activation and incoming UE Initiated Tracking
Area Update was not correct.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 159/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- In case of collision between ongoing Dedicated Bearer Activation and incoming UE initiated Tracking
Area Update, Modify Bearer Response (as part of UE initiated TAU procedure) was sent with cause
"Context Not Found". ENB sent ERAB Release Command Failure (with cause "Unknown ERAB ID").
Create Bearer Response was sent with cause as Request Rejected and TAU Accept ICSR message was
sent with wrong sequence number.

Description of the fault:


- Handling of collision between ongoing Dedicated Bearer Activation and incoming Tracking Area Update
was the same, whether TAU was Uplink NAS or UE initiated. During collision between ongoing Dedicated
Bearer Activation and incoming UE initiated Tracking Area Update occurred Dedicated Bearer Activation
was put on hold and Tracking Area Update continued. As a result, MME processed TAU and included
bearer under Modify Bearer Request, although bearer setup was not complete, so GW sent Modify
Bearer Response with cause "Context Not Found". MME triggered ERAB Release Command message
and ENB sent ERAB Release Command Failure (with cause "Unknown ERAB ID). MME sent Create
Bearer Response with cause as Request Rejected. Lastly, MME sent TAU Accept ICSR message with
wrong sequence number.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.13-50
- LNX924G2.IMG 11.5-39

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Collision handling between ongoing Dedicated Bearer Activation and incoming UE initiated Tracking
Area Update was changed to terminate ongoing and continue incoming.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 160/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.153 NS16.50717 Abnormal number of secondary paging

NA05938357 (MME NS16.5)the number of secondary paging was abnormal

NA05974632 flns 3227b counter(EPS PS Paging first attempt success ratio) exceed 100%

Summary of the original problem:


- In case "MME_PAGING_PROFILES" (i.e. 2311) PRFILE is enabled, counter "M50C012 EPS PAGING
PROCEDURE SUCC" is getting increased during CSFB paging not fully comply with Customer
Documentation. Additionally, if this certain PRFILE is disabled then this counter stops getting increased.

How end user/operator could detect the problem:


- By enabling prfile parameter: "MME_PAGING_PROFILES" (i.e. 2311) during CSFB paging procedure.

Description of the fault:


- "M50C012 EPS PAGING PROCEDURE SUCC" was getting incremented only when the
"MME_PAGING_PROFILES" (i.e. 2311) PRFILE was enabled. This rule is different from the increment
rules of other two related counters: M50C011 PAGING_PROCEDURE_ATTEMPTS and M50C013
PAGING_PROCEDURE_FAILURE. This had as a result the formula: M50C011 = M50C012 + M50C013
was evaluated erroneously. M50C012 EPS PAGING PROCEDURE SUCC should be updated when the
paging procedure is not CSFB.

Dependency on configuration:
- When the "MME_PAGING_PROFILES" (i.e. 2311) PRFILE is enabled, then the counter "M50C012 EPS
PAGING PROCEDURE SUCC" is getting incremented during CSFB paging.

Faulty component and version:


- LNX934G2.IMG 7.13-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Counter "M50C012 EPS PAGING PROCEDURE SUCC" is getting incremented without checking if the
"MME_PAGING_PROFILES" (i.e. 2311) PRFILE is enabled. This counter gets incremented when the UE
is in IDLE state and the paging procedure is not CSFB.

Risk analysis of the correction:


- Customer may experience different statistics values for this counter (and for the related formulas) from
that is used to be in the past. Values of this counter before and after the correction may be not
comparable.

Correction effects:
- Counter value and related with this counter formula should have more convenient values.

Interface effects:
- None

Customer effects:
- None

Test requirements:
- CSFB paging procedure with Prfile ON and OFF. Counter should not get incremented for both
scenarios.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 161/231


D553209967 © Nokia 2016
Version 1.0
Confidential
- Non CSFB paging procedure with Prfile ON and OFF. Counter should get incremented for every
scenario.

2.154 NS16.50718 RAB release response missing from collision scenario

NA05969882 3G RAN Investigation into IU failures

Summary of the original problem:


- A relocation request arrives with two PDPs. Relocation procedure is completed successfully but later
during modification of the second PDP, a RAB release request arrives from RNC. So, modification
procedure collides with RNC initiated deactivation procedure. Although the PDP is deactivated, RAB
release request is never answered and RNC is not informed about the release.

How end user/operator could detect the problem:


- Problem is detected through the IU failures caused from this scenario.

Description of the fault:


- When the aforementioned collision happens between modify service and RNC initiated deactivation,
PDP context deactivation is triggered immediately after the collision, PDP is deleted from the sgsn files
and therefore rab release answer could not be triggered.

Dependency on configuration:
- None

Faulty component and version:


- GMG_G6JX.PAC 22.462-0

Faulty component first delivered in(e.g. release, CD):


- SG8 DX CD8

Workaround:
- None

Description of the correction:


- When the aforementioned collision occurs, priority is given to the RAB release procedure which is now
instructed to continue with RAB release and the deactivation procedure is triggered as long as RAB
release is completed.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 162/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.155 NS16.50719 solid and DB handler constant restart every 6 minutes

PR194509 solid and DB handler constant restart every 6 minutes

Summary of the original problem:


- When MMDU was restarted while its pair MMDU was in a non-WO state, in case of very long network
delays (such as delays from inefficient network configuration), DBHandler and database in restarted
MMDU keeps restarting every 6 minutes.

How end user/operator could detect the problem:


- Alarm 1007 is raised every 6 minutes indicating a restart of DBHandler and database.

Description of the fault:


- Timer used to check connection to the database during MMDU start up while pair MMDU was in non-
WO state, was cancelled at a late stage of database initialization. As a result, the timer measures more
than it is supposed to, and in case of long network delays, this timer was expired before it was cancelled
causing DBHandler and database restart.

Dependency on configuration:
- None

Faulty component and version:


- LNX93DG2.IMG 11.3-0

Faulty component first delivered in(e.g. release, CD):


- Too legacy to identify.

Workaround:
- None

Description of the correction:


- Timer used to check connection to the database during MMDU start up while pair MMDU is in non-WO
state is now cancelled earlier in the database initialization process if connection to the database is
achieved. This way the timer only measures what it is supposed to.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 163/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.156 NS16.50720 Peak IPDU CPU % elevated in multiple offices.

NA05977359 Peak IPDU CPU % elevated in multiple offices.

NA05990429 (Flexi NS-MME)CPU load increase from 0 to 8% in standby IPDU

NA05993087 MME CPU load going high due to spare IPDU unit since 8th January in MME-
TH

Summary of the original problem:


- Peak CPU usage increased in spare IPDU, about 50 days after the system restart.

How end user/operator could detect the problem:


- The operator could observe the CPU usage increase by examining MonitoringSnapshot in IPDU or with
any CPU usage monitoring tool/procedure.

Description of the fault:


- Almost 50 days after the system start up, the CPU usage of the Synapse(LNXA9FG2) java process in
spare IPDU suddenly got higher than usual, and as a result, operator observed high CPU usage in spare
IPDU unit. The CPU load was caused due to the high number of major Garbage Collections (Full GC) in
Synapse and their execution's duration. Those Full GCs started when used heap memory in Synapse
had increased enough (local testing showed at 50%-60% of the available memory), however they didn't
have any impact on the memory deallocation. The used memory kept increasing till reaching around
90%, 85 days after system start up, when finally memory was freed and returned to normal level;
subsequently Full GCs stopped and CPU usage was normal again.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Since the issue is visible only when Java 7 is used in Synapse, and not with Java 8 which is used in
later releases, by tuning JVM arguments in mmeSynapse, the garbage collection is now stable and not
causing high CPU usage.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNXA9FG2.IMG 1.28

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 164/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component first delivered in(e.g. release, CD):
- NS15

2.157 NS16.50721 S1 handover failure increase after enable NITZ

PR185352 S1 handover failure increase after enable NITZ

Summary of the original problem:


- When MME sent NITZ EMM information during a TAU procedure and UE did not recognize it, it did not
respond with TAU Complete, therefore TAU procedure was completed with delay.

How end user/operator could detect the problem:


- A drop in success rate would be noticed in procedures that follow TAU.

Description of the fault:


- During all types of TAU when MME sent to UE the NITZ EMM information and UE did not recognize it, it
did not respond with TAU complete. MME was waiting until the expiration of T3450 timer and then it
resent TAU Accept, which would be responded with TAU Complete by eNB. During this period if a new
Handover was received by MME, it would collide with TAU and drop.

Related feature / functionality:


- None

Dependency on configuration:
- UE should not recognize NITZ EMM information.

Workaround:
- None

Description of the correction:


- NITZ EMM information will be sent after MME receives TAU Complete.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- NITZ EMM information will be sent after MME receives TAU Complete

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX924G2.IMG 13.28-0
- LNX924G2.IMG 11.94-0
- LNX924G2.IMG 14.4-0

Faulty component first delivered in(e.g. release, CD):


- NS40

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 165/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.158 NS16.50722 Improvement in KPI “DNS Inquiry Success Rate (Home)” after upgrading to
newer release.

NA05923719 Improved in KPI “DNS Inquiry Success Rate (Home)” after FNS4.0 2.0 release
upgrade.

Summary of the original problem:


- There was an improvement in KPI “DNS Inquiry Success Rate (Home)” because counter FAIL DNS
INQUIRIES DUE HOST NOT FOUND was not updated correctly.

How end user/operator could detect the problem:


- By checking counter M07C004 - FAIL DNS INQUIRIES DUE HOST NOT FOUND in latest release and
compare it to older one.

Description of the fault:


- Due to introduction of feature FC085_002405 R8 DNS Support in FNS Gn-SGSN, a new decision was
added to the code flow of gtp, so procedure that increased counter was never called in case of pdp
context activation.

Dependency on configuration:
- None

Faulty component and version:


- GTP_GXJX 26.87-0

Faulty component first delivered in(e.g. release, CD):


- NS40 20

Workaround:
- None

Description of the correction:


- Procedure that increases M07C004 - FAIL DNS INQUIRIES DUE HOST NOT FOUND is called
appropriately in order to include Release pdp context activation failure.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 166/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.159 NS16.50723 SGs interface status abnormal

NA05961025 SGS interface status abnormal

Summary of the original problem:


- When a non-established SGs link is removed with ZBIV:REMLNK, then the MME tries to reconnect
continuously and as a result the status of the association appears to be not stable.

How end user/operator could detect the problem:


- By trying to change the wrong IPPRI address of one SGs link by ZBIV:REMLNK and ZBIV:ADDLNK, but
the alarm 3771 was being continuously raised and cancelled.

Description of the fault:


- At the time where a SCTP_COMM_LOST notification event is received by MME for an established SGs
association, then a Reconnect timer (60 sec) is started and MME will try to re-establish the connection. In
this case, we had the following repeated messages: INIT, INIT_ACK, COOKIE_ECHO, COOKIE_ACK,
SHUTDOWN, SHUTDOWN_ACK, SHUTDOWN_COMPLETE. Since the connection is established for a
moment after COOKIE_ACK, then the alarm 3771 is cancelled and it is raised again when MME receives
a SCTP_SHUTDOWN by the VLR. In case that the problematic association is the only association
towards the VLR, then we see also the alarm 3772 flickering up and down, and the VLR status itself
seems flickering. Until this point we have a correct behaviour. But in case that the association was
manually removed with ZBIV:REMLNK, then the Reconnect timer was not stopped, so MME continued to
send SCTP_INIT and the above situation continued.

Dependency on configuration:
- Connection with VLR present.

Faulty component and version:


- LNX969G2.IMG 11.4-0

Faulty component first delivered in(e.g. release, CD):


- NS3.0

Workaround:
- Restart the SGsLBS process (ZDDS:IPDU,0; and give 'lnx-launcher -r lnx-mmeSGsLBS').

Description of the correction:


- When a SGs association is removed via MML, then the MME stops trying to reconnect.
The alarm 3771 is cancelled when the respective association is removed.
The alarm 3772 is cancelled when the last association towards a VLR is removed.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Alarms 3771 & 3772 are not flickering after removing a problematic association.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 167/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.160 NS16.50724 PROCESS EXCEPTION for NE3SAGGX and loss of alarms on Netact side

PR176477 PROCESS EXCEPTION for NE3SAGGX and loss of alarms on Netact side

Summary of the original problem:


- Process exception for NE3SAGGX and loss of alarms on NetAct side.

How end user/operator could detect the problem:


- Check for disturbance 1078 using ZAHP MML

Description of the fault:


- NE3SAGGX exception.

Dependency on configuration:
- None.

Faulty component and version:


- NE3SAGGX.PAC 8.15-18

Faulty component first delivered in(e.g. release, CD):


- NS 16.5 MP1

Workaround:
- None

Description of the correction:


- Added memory protection, to avoid using wild pointer.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.161 NS16.50725 TAU reject of Roaming Subscriber leaves hanging bearers in PGW.

PR165857 Tau Reject Cause Mismatch for HRT Roaming Subscriber during Inter System Tau
Reject

Summary of the original problem:


- When MME rejected a roaming Subscriber with LBO and HRT set to NOT, it would leave hanging
bearers in the GW side. In Gn interface there is no way to drop these bearers unless MME sends Create
Session Request and then Delete Session Request to SGW. In the mentioned scenario, the subscriber
would be rejected, but the MME would not send the Create Session Request message.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 168/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- The subscriber would be rejected anyway but the operator would be able to see the hanging bearers.
The cause of the TAU rejection in the Downlink Nas Transport message would be Implicitly Detached.

Description of the fault:


- The way Gn interface is implemented, MME is required to send Create Session Request and then
Delete Session Request to GW to release selected bearers. The case of a Roaming Subscriber who is
neither HRT nor LBO was not handled correctly by the CPPU causing the MMDU to reject the Subscriber
before the Create Session Request message could be sent by the MME.

Dependency on configuration:
- None

Faulty component and version:


- LNXA9BG2.IMG 5.2-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- In CPPU, during the SGW selection, we populate the allowed protocols list so that the call flow moves
on and the subscriber gets rejected after the Create Session Request is being sent.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.162 NS16.50726 Blackbox collection (Z1U) from spare MCHU-1 fails

PR192125 Blackbox collection (Z1U) from spare MCHU-1 fails

Summary of the original problem:


- Service terminal was getting frozen when trying to print blackbox.

How end user/operator could detect the problem:


- By trying to print blackbox data.

Description of the fault:


- Blackbox parser BOXANA didn't understand the binary data correctly, and resulted in infinite loop.

Dependency on configuration:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 169/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- BOXANAGX 8.17-0 and older versions.

Faulty component first delivered in(e.g. release, CD):


- Too legacy to be defined.

Workaround:
- None

Description of the correction:


- Correct BOXANA, so it will properly understand the binary blackbox data.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.163 NS16.50727 GTPV2 DDN request missing DDN ack response to SGW

PR176010 GTPV2 DDN request missing DDN_ack response to SGW

Summary of the original problem:


- GTPV2 DDN (Downlink Data Notification) request missing DDN ack response to SGW when the
sequence number is 0.

How end user/operator could detect the problem:


- Start a SGW initial paging procedure with sequence number 0 in the Downlink Data Notification
message.

Description of the fault:


- When the DDN carry 0 value on GtpSequenceNumber, the CPPU will send it to MMDU without
changing the value, this will cause MME not to consider the DDN as MME initial paging and then not
send ACK to SGW

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 10.8-0
- LNX934G2.IMG 10.8-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 170/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- When DDN carry 0 GtpSequenceNumber, CPPU send DMX message to MMDU and will change the
GtpSequenceNumber (it was 0 in DDN) to 0xFFFFFFFF. MME will not consider the DDN as MME
initialed Paging and then will send DDN ACK to SGW.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.164 NS16.50728 Process Exception during overload situation

PR175365 Process Exception during overload situation

Summary of the original problem:


- Exception occurred in many processes in LIBGEN code when memory was exceeded.

How end user/operator could detect the problem:


- Exception occurred in many processes in LIBGEN code when memory was exceeded, process
exception alarm is shown in alarm history.

Description of the fault:


- Some internal procedure of LIBGEN returned to invalid address when memory was exceeded.

Related feature / functionality:


- None

Dependency on configuration:
- None

Workaround:
- When problem happens, restart the problematic unit.

Description of the correction:


- Correct LIBGEN code in order to return right address.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 171/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LIBGENDX.PAC 5.13-0 and older versions

Faulty component first delivered in(e.g. release, CD):


- Too legacy to be specified. Problem first observed in Open TAS 16.5.

2.165 NS16.50729 NE3S Process Exception Alarms

NA05942925 MME Process Exceptions

Summary of the original problem:


- NE3S Exception happened when upload.

How end user/operator could detect the problem:


- This was an occasional issue and no specific actions could take place for the customer to detect the
problem.

Description of the fault:


- When a NULL buffer for XML file was requested, if it was called, it was causing exception.

Dependency on configuration:
- None

Faulty component and version:


- NE3SAGGX.PAC 8.17-9

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Protection for pointer is added in order to avoid the exception.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 172/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.166 NS16.50730 No Service-Req from MME on SGSAP PAGING-req = Failed MT CSFB calls

NA05973155 No Service-req from MME on SGSAP PAGING-req = Failed MT CSFB calls

Summary of the original problem:


- If Service Request is triggered by UE while MT-Call is ongoing, MT-Call will be dropped and Service
Request will continue. After that, UE sends Extended Service Request as a response to the MT-Call
paging which already dropped as part of collision. So, MME just processes this Extended Service
Request and never sends the SGsAP Service Request towards MSC/VLR.

How end user/operator could detect the problem:


- In case Service Request was established while MT-CALL was ongoing, MT-Call drop rates would be
increased.

Description of the fault:


- Collision resolution between MT-CALL procedure and Service Request procedure is to drop ongoing
MT-Call procedure and continue incoming Service Request procedure. As a result, MT-Call is dropped,
Service Request continues and SGsAP Service Request is never sent to MSC/VLR.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG, 11.119-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- In case UE is Active and MT-Call has been initiated and dropped due to collision with Service Request
(MO-Data), Service Request procedure will continue and afterwards (UE in connected ECM state)
SGsAP Service Request will be sent through Extended Service Request procedure.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- There must be an ongoing CSFB MT Call for CS call service and an incoming Service Request with
establishment cause MO-Data. In this case, MT-Call will be dropped and the Extended Service Request
that will follow will send the appropriate SGsAP Service Request to MSC/VLR.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 173/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.167 NS16.50731 The collision resolution between gateway initiated Detach and S1-Release
procedure

NA05990508 (Flexi NS MME NS16.5)The collision resolution between gateway initiated


Detach and S1-Release procedure

Summary of the original problem:


- During Collision of SGW initiated detach, UE Context release and TAU Request, UE was implicit
detached but MME did not answer with correct cause to reject of TAU Request or reject of Service
Request that followed. So, UE was never informed that it was implicitly detached.

How end user/operator could detect the problem:


- Since end user received detach request with re-attach required, most probably it would try to re-attach
and would not behave as at lab testing. Though, if UE acted erroneously, as at the test scenario, it would
not be served until SGW retried to initiate a detach.

Description of the fault:


- The issue was that during termination of SGW initiated Detach because of the collision, MME should
send Delete Bearer Response to SGW since UE is implicit detached. After this was corrected, MME
sends correct cause of rejection to UE requests ("cause: implicit detach"). So, UE now will retry to re-
attach.

Related feature / functionality:


- Collision handling

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- The correction is that MME answers to SGW with Delete Bearer Response after SGW initiated Detach
procedure is terminated because of collision handling. With this MME answers with correct failing cause
code to UE requests. So, UE is informed that it is implicitly detached and tries to re-attach.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 11.117-0 and below.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 174/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component first delivered in(e.g. release, CD):
- NS15

2.168 NS16.50732 ACPI5-A GISU CPU overloaded

PR140160 OpenTAS 16.2,TH 52.11-0, T4XX30FD: EPOFFI 13.19-0 fault

PR149947 OpenTAS 16.5, TH 54.6-0, T4XX40F8, PeV: EPOFFI 13.19 causes 509H file error
clear codes and huge load difference among the units

PR158085 MSS15 MH 27.27-50 GCD5.0 PeV: ACPI5-A GISU CPU overloaded

Summary of the original problem:


- ACPI5-A CPU overloads during Performance testing. Some of the cards were overloaded and the
average load was ~10% higher, compared to the previous SW level. The top CPU user PRBs were the
same compared to previous SW level, but the amount of the CPU usage was much higher in case of
every PRBs.

How end user/operator could detect the problem:


- By noticing the average load which was ~10% higher, compared to the previous SW level.

Description of the fault:


- Updating EPOFFI from 13.17-0 to 13.17-1 is required for the problem to be triggered. EPOFFI was
causing 509H file error clear codes resulting in huge load difference among the units, since the global
variables were not optimized and conflicts occurred.

Dependency on configuration:
- None

Faulty component and version:


- EPOFFIGX.PAC 13.17-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Global variable access is optimized to avoid conflict.

Risk analysis of the correction:


- None

Correction effects:
- None of the ACPI5-A cards are overloaded and the average load is the same, compared to the previous
SW level.

Interface effects:
- None

Customer effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 175/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.169 NS16.50733 Security testing:Dos Attack causes OMU reboot/swo

PR203273 Security testing:Dos Attack causes OMU reboot/swo

Summary of the original problem:


- When unit is under DoS attack, CPU load of POZMAN net hand will reach 100% and SYN cache costs
too much memory. This can lead to Unit restart.

Description of the problem


- Unit restart under DoS attack.

How end user/operator could detect the problem:


- Use tool t50 and perform SYN flood attack.

Description of the fault:


- The unit, that is under DoS attack, restarts and fails to startup. CPU load of POZMAN net hand will
reach 100%.

Dependency on configuration:
- None

Faulty component and version:


- POXLIBGX.PAC 33.114-0

Faulty component first delivered in(e.g. release, CD):


- Y2 17.17-10

Workaround:
- None

Description of the correction:


- Adjust SYN cache dynamically in TCP stack.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 176/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.170 NS16.50735 Commands ZDDS & ZDDE fail randomly when using CNUM

NA05977155 Commands ZDDS & ZDDE fails randomly when using CNUM

Summary of the original problem:


- After configuration and activation of CNUM (Centralized Network Element User Management)
functionality, ZDDS & ZDDE commands were randomly failing.

How end user/operator could detect the problem:


- In a setup where CNUM functionality was activated and a remote user was logged in the Network
Element (MME), execution of ZDDS & ZDDE commands were failing.

Description of the fault:


- Execution of ZDDS & ZDDE commands were failing with notice "Session setup problem, abort".

Dependency on configuration:
- CNUM activated.

Faulty component and version:


- LNX716G2.IMG 3.2-0
- LNX716G3.IMG 3.2-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Considering that customer network latency might exceed 2 seconds, the delay timer (waiting for LDAP
response) is increased to 3 seconds (hardcoded).

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

2.171 NS16.50736 Iphone terminal was notified that did not support IMS calls during attach

NA05975103 (Flexi NS MME NS16.5 WU3)Iphone terminal is notified does not support IMS
calls by MME in the process of attach

Summary of the original problem:


- The MME sent Attach Accept with the indication that IMS voice over PS session was not supported
despite the fact that Voice domain preference was set to 3.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 177/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- The MME sent Attach Accept with the indication that IMS voice over PS session was not supported
despite the fact that Voice domain preference was set to 3. As a result, UE performed calls through
CSFB.

Description of the fault:


- In Triple Access Architecture, where MME and SGSN shared the same database, UE made attach with
Voice domain preference set to 0 and as a result IMS voice over PS session was not supported. Then,
UE was detached. Afterwards, UE made Intersystem attach with Voice domain preference set to 3 in
Attach Request message. MME retrieved subscriber's data from database, since SGSN had saved them
before. However, due to the initial attach with Voice domain preference set to 0, subscriber's data in
database contained indicator that IMS voice over PS session was not supported. As a result, having
retrieved data from database, MME considered that IMS was not supported, so sent Attach Accept with
IMS PS voice not supported despite the fact that Voice domain preference was set to 3 in the last attach
attempt.

Related feature / functionality:


- Roaming control.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Code enhanced so that the MME retrieves the data from SGSN but also from Attach Request.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX924G2.IMG 7.238 and backwards.

Faulty component first delivered in(e.g. release, CD):


- NS15

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 178/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.172 NS16.50737 Failed OMU switchover due to NE3SAG (9C2) due to OMU's WDU disks
inconsistency

PR149557 NE3SAG error logs were reported when doing unit diagnostic

PR150970 Various computer logs appeared during Alarm System - Storing of alarm events
test case execution

Summary of the original problem:


- The previous correction increased the time of starting up NE3S and it triggered a legacy problem.

How end user/operator could detect the problem:


- Delete "NE3SCONF.XML" and perform switchover 3 times as soon as possible.

Description of the fault:


- The time of synchronizing NE3S between WO and SP OMU was too long. So the flag indicated the
starting up was OK before it was ready. At last this flag has been reset by switchover messages.

Dependency on configuration:
- None

Faulty component and version:


- NE3SAGGX 8.16-5

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- Kill and start NE3S.

Description of the correction:


- Decrease the time of synchronization and optimize the synchronization mechanism.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.173 NS16.50738 OMU unit did not recieve the supervision message ACK resulting in the restart
of FRIU unit

PR164745 The FRIU unit is restarted by OMU unit does not receive the supervision message
ACK from it

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 179/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Summary of the original problem:
- The FRIU unit was restarted by OMU because OMU did not receive the supervision message
ACK from it.

How end user/operator could detect the problem:


- By observing the FRIU restart.

Description of the fault:


- Timeout and interval of unit supervision message between OMU and FRIU unit was too short resulting
in FRIU restart.

Dependency on configuration:
- FRIU unit must exist.

Faulty component and version:


- Version too legacy to be specified.

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- Increasing the timeout and interval of unit supervision message between OMU and FRIU unit quadruple
to about 19 seconds and so no FRIU restart is happening.

Risk analysis of the correction:


- None

Correction effects:
- None

2.174 NS16.50739 Alarm 1020 PROGRAM BLOCK START UP FAILURE caused by TUKEVA after
MCHU restart

PR159315 [NS17] Not allowed alarms 1020:PROGRAM BLOCK START UP FAILURE,


1001:UNIT RESTARTED, 1023:EXCESSIVE DISTURBANCES IN SUPERVISION,
1007:RESTARTED PROGRAM BLOCK"

PR159320 [NS17-NS16.5MP1] : Alarm 1020 PROGRAM BLOCK START UP FAILURE


caused by TUKEVA after MCHU restart

Summary of the original problem:


- TUKEVA can't startup successfully after MCHU restart.

How end user/operator could detect the problem:


- Restart system.

Description of the fault:


- TUKEVA can't startup successfully after MCHU restart due to Disk reservation is not free before MCHU
restart, then CAM reports critical error and remove disks when TUKEVA tries to detect if any native disk
exists during MCHU restart.

Dependency on configuration:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 180/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- EDISKDGX.PAC 21.42-0

Faulty component first delivered in(e.g. release, CD):


- Too legacy to be defined.

Workaround:
- None

Description of the correction:


- Subscribe unit restart and system restart message for MCHU/CHU.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.175 NS16.50740 High CPU CPPU load

NA05959528 high CPPU load in MMEs CPPU

Summary of the original problem:


- High CPPU load occurred.

How end user/operator could detect the problem:


- By observing the high CPU load in CPPUs.

Description of the fault:


- When IMSI attach fails due to no response for Create Session request, HSS sends cancel location
request and MME triggers detach indication towards SGS. In this case, some cache data which were
supposed to be cleared were left uncleared in CPPU leading to high CPPU load.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Code added in failure states of Attach, Extended Service Request and Service Request procedures,
when TrHandler sent SGs Detach Indication to VLR. In these cases, the current CPPU will send an
internal message to other CPPU which has subscriber's IMSI cached too.

Risk analysis of the correction:


- None

Effects on end-user:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 181/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX924G2.IMG 13.0-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

2.176 NS16.50741 VOLTE video call failed

NA05982185 (Flexi NS MME NS16.5WU3)VOLTE video call failed

Summary of the original problem:


- While PGW was sending Update Bearer Request message to MME, carrying two bearers to be modified
(as part of MO call initialization) one with QoS change and one without QoS change. However, the
sequence of messages that inform the UE regarding the modifications, was not according to their NAS
Sequence number and thus not correct.

How end user/operator could detect the problem:


- In case we had two bearers to be modified one with QoS modification and one with only TFT
modification the QoS modification will be completed first and Non QoS modification will be dropped.

Description of the fault:


- The sequence of messages that were sent to UE was not according to their NAS sequence number.
While Downlink Nas message was constructed first (Non QoS modification) the E-RAB Modify Request
(QoS modification) with higher sequence number is sent first. As a result, UE responded to E-RAB Modify
Request with proper uplink message (Modify EPS Bearer Accept) but never to Non QoS modification
downlink request message.

Related feature / functionality:


- GW initiated default bearer modification.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- In case update bearer request for multiple bearers is received and there are bearers that need to
change their QoS values and bearers without QoS change, messages Downlink NAS message (Modify
EPS Bearer Context Request - No-QoS change) and E-RAB Modify Request (QoS change) are now sent
according to their sequence number.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 182/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG, 11.119-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

2.177 NS16.50742 No response from MME to SGSN during Inter system RAU if IMSI does not exist

PR193486 inter system RAU, no response , if imsi does not exist

Summary of the original problem:


- When more than one home PLMNs are configured in MME and an SGSN Context Request is received
from SGSN for a subscriber that no longer exists in MME DB, then MME does not send Response.

How end user/operator could detect the problem:


- From logging and counters that no response received.

Description of the fault:


- This problem occurred only when there were more than one home PLMNs configured and SGSN
Context Request contained info that pointed on other than first Home PLMN (e.g. Second PLMN in MME)
MME received SGSN Context Request and from the old-TMSI signature the GUTI for the subscriber was
created. It wrongly took the GUMMEI details - available in the first of PLMN List - so the generated GUTI
was based on the first PLMN information this wrongly created GUTI led MME to follow a different internal
flow and not to send a response to SGSN.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.7-0
- LNX924G2.IMG 11.5-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- The appropriate GUTI is now generated and MME is able to end the RAU on time and reply to SGSN
with appropriate cause (IMSI not known).

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 183/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- MME should receive a message SGSN Context Request from SGSN for a subscriber that
does not exist in the DB of MME.
- MME then should send a response to SGSN with cause IMSI not known.

2.178 NS16.50743 Command calander files not transferred during SW upgrade

NA05980990 Command calendar files not transferred during SW upgrade

Summary of the original problem:


- .CMD files with name characters greater than 11, were not parsed from upgrade macro, thus during
Software Upgrade execution they were not copied to destination build.

How end user/operator could detect the problem:


- Customer has noticed that the .CMD files have not being copied after the upgrade

Description of the fault:


- Software upgrade macro did not parse the name of .CMD files properly, thus during Software Upgrade
execution files with name characters equals to 11 were not copied to destination build.

Dependency on configuration:
- None

Faulty component and version:


- flexinsswup.tel, 8.1.0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- .CMD files can be copied manually from source to destination folder.

Description of the correction:


- Macro has been corrected so as to parse correctly all .CMD files despite the number of the characters
of their name.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 184/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Customer effects:
- None

Test requirements:
- .CMD files with name characters equals to 11 to be present in NE and Software Upgrade should be
performed.

2.179 NS16.50744 DBhandler sent messages to Subshandler but subshandler never replied with
ACK after maximum amount of retries was reached

PR190478 MMDU-0 does not communicate with MMDU-1

Summary of the original problem:


- MMDUs did not broadcast its activation to other MMDUs. As a result other MMDUs were not aware of
each other leading to subscriber duplication and procedure rejects.

How end user/operator could detect the problem:


- Subscribers duplicated in MMDUs and large number of CS Fall Back (CSFB) failures.

Description of the fault:


- When DBHandler in MMDU sent mme_unit_status message to own SubsHandler, it allowed for 1 retry
per second in case own SubsHandler did not reply up to a maximum of 60 retries. In case own
SubHandler did not reply within this time frame and replied later, DBHandler would ignore its reply and
not broadcast its MMDU activation to other MMDUs. This resulted in MMDUs not being aware of all other
running MMDUs that could led to subscriber duplication and procedure rejects.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- If mme_unit_status_ack is received by DBHandler from own SubsHandler, then activation will be
broadcasted regardless of the 60 retries limit reached or not.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None
Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX93DG2.IMG 13.12-0

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 185/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component first delivered in(e.g. release, CD):
- Too legacy to be specified.

2.180 NS16.50745 MME selection after CSFB in a pool with TA MMEs.

NA05983787 MME selection after CSFB

Summary of the original problem:


- MME selection after CSFB when a SA MME is added in a pool of TA MMEs.

How end user/operator could detect the problem:


- The end user would never detect the problem.
- The operator would observe a non-balanced distribution of subscribers between the core network
elements of the pool.

Description of the fault:


- When Flexi NS operates in combined SGNS/MME mode and the collocated SGSN is pooled, in case
the same physical SGSN/MME is required to be maintained in 2G/3G-to-LTE access change, the eNB
needs to be communicated accordingly so that it recognizes not only the MME's native Global Unique
MME Identifier (GUMMEI) but also all the possible GUMMEIs (PLMNs + MMECs + MMEGIs) that are a
result of the identifier mapping. For this purpose, the MME application reads the collocated SGSN's
PLMN, LAC and NRI configuration and includes it as additional Served GUMMEIs into the S1 SETUP
RESPONSE message (specified in 3GPP TS 36.413). If SGSN's NRI or LAC configuration changes,
MME uses the MME CONFIGURATION UPDATE message to update the Served GUMMEIs to the eNBs.
As a result of the above, all the subscribers that belonged to one of the TA MMEs (LTE) in case they
performed a CSFB they would be forced to return to the same MME that was physically collocated to the
SGSN that served them during the CSFB. Therefore, when a new SA MME was added, all its subscribers
that performed a CSFB when they would try to return to LTE they would be forced to go to the MME that
was physically collocated to the SGSN that served them during the CSFB. In this way, the load of
subscribers in the pool would not be distributed equally in all MMEs.

Dependency on configuration:
- The problem appeared in pools containing both TA MMEs and SA MMEs.

Faulty component and version:


- S1C_GMNX.PAC 9.13-0
- S1C_GMNX.PAC 9.7-0
- S1C_GMNX.PAC 10.3-0

Faulty component first delivered in(e.g. release, CD):


- NS3.0

Workaround:
- None

Description of the correction:


- The new PRFILE parameter MAPPED_GUMMEIS_ENABLED is created with default value ON. When
is turned OFF, the mapped GUMMEIs are prevented to be sent in the S1-SETUP RESPONSE and MME
CONFIGURATION UPDATE. When the PRFILE value is modified all eNBs will be informed with a MME
CONFIGURATION UPDATE for the new serving GUMMEIs.

Risk analysis of the correction:


- The customer might observe an increase in the signaling between MMEs associated to inter-access
changes.

Correction effects:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 186/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Interface effects:
- None

Customer effects:
- Increase in the signaling between MMEs associated to the 2G/3G-to-LTE access change.

2.181 NS16.50746 Subsystem MAPv can't startup automatically after MSS restart

NA05931350 Double location after MSSKRC CD1.7

Summary of the original problem:


- Subsystem MAPv can't startup automatically after MSS restart.

How end user/operator could detect the problem:


- The problem occurred occasionally after system restart.

Description of the fault:


- After system restart, subsystem MAPv can't startup automatically.

Dependency on configuration:
- None

Faulty component and version:


- SMNPROGX.PAC 15.53-0

Faulty component first delivered in(e.g. release, CD):


- Md16.2 24.4-0

Workaround:
- State of subsystem can be activated manual with ZNHC MML.

Description of the correction:


- Print out the log while SMNPRO fail to write the state to table SSYMFI.
- Ignore the request with error subsystem from other PRB.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 187/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.182 NS16.50747 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718

PR158905 Expat XML Parser - Buffer Overflow Vulnerability - CVE-2016-0718

Summary of the original problem:


- A denial of service could occur.

How end user/operator could detect the problem:


- By observing a denial of service attack.

Description of the fault:


- The Expat XML parser mishandled certain kinds of malformed input documents, resulting in buffer
overflows during processing and error reporting. The overflows could manifest as a segmentation fault or
as memory corruption during a parse operation. The bugs allow for a denial of service attack in many
applications by an unauthenticated attacker, and could conceivably result in remote code execution.

Dependency on configuration:
- None

Description if problem based on certain configuration


- None

Faulty component and version:


- NE3SAGGX.PAC 8.16-11

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Porting the patch from the main trunk of Expat.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 188/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.183 NS16.50748 Inter MME TAU has conflict with X2 HO

NA05960953 (Flexi NS MME NS16.5)MME TAU has conflict with X2 HO on NS16.5 version

Summary of the original problem:


- During call, Inter MME TAU was ongoing and before procedure completion, an X2HO was received.
X2HO procedure waited for Inter MME TAU completion but TAU complete never sent and as a result
X2HO failed too.

How end user/operator could detect the problem:


- Call was dropped.

Description of the fault:


- Ongoing Inter MME TAU procedure collided with X2HO in Subshandler. The X2HO was on hold and
timer was running in TrHandler. MME did not receive TAU complete message so timer expired and X2HO
failed.

Related feature / functionality:


- Inter MME Mobility

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2 10.6-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Collision between Inter MME TAU and X2HO is handled as Continue ongoing and Continue Incoming.

Risk analysis of the correction:


- To send the retries of DownlinkNasTrasport\TAU Accept in the old EnodeB after the X2 Handover
completed.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.184 NS16.50749 Attach successful ratio was dropped to 0 due to 1014 and 0004 alarms were
raised on CPPUs

NA05968119 (Flexi NS MME NS16.5) alarm 0004 on CPPUs, attach successful ratio is 0.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 189/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Summary of the original problem:
- "0004 ACCESS SERVICE REJECT RATE LIMIT EXCEEDED" and "1014 PROCESSOR LOAD RATE
ALARM LIMIT EXCEEDED" alarms were raised after PGW Restore Notification message.

How end user/operator could detect the problem:


- Service drop may be happened due to the fact that MME was in overload situation. Operator KPIs were
significantly reduced.

Description of the fault:


- PGW Restart Notification messages triggered for long time, are consuming request to Database. This
fact, blocked working threads and TrHandler was overloaded.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 8.13-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Resolution:
- None

Workaround:
- None

Description of the correction:


- PGW Restart Notification messages are handled by a new thread-pool. Furthermore, enhanced
collections for IMSI list used to avoid concurrency issues.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Increased traffic is needed where subscribers are already attached in MME and all of them have
established a PDN connection to the specific PGW.

2.185 NS16.50750 Error during TCP DoS test

PR165656 Open MSS 17 ATCA MH 40.23-0 security test - Error during TCP DoS test

Summary of the original problem:


- IPsec activation during DoS attack lead to POZMAN net hand CPU over load and unit switched to SE.

Description of the problem


- IPsec activation under DoS attack lead to POZMAN net hand CPU over load and unit switched to SE.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 190/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- Activate IPsec in OMU and do TCP DoS attack.

Description of the fault:


- POZMAN net hand has a high process priority, and POZMAN CPU overload could lead to Application
process block at Giant lock in kernel.

Dependency on configuration:
- IPsec rules should be activated in OMU.

Faulty component and version:


- POXLIBGX.PAC 33.111-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- When POZMAN and WYNONA detect IPsec activated in kernel and meanwhile kernel is under DoS
attack. It will lower packet reception rate.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Activate IPsec rule in OMU before TCP DoS attack.

2.186 NS16.50751 Alarm 3463 (73D) CHGINTERFACE PRB PROBLEM raised in SGSN

NA05972642 (Flexi NS-SGSN/MME NS16.5)2G 3G S-CDR did not generate.

NA05981809 3463 (73D) CHG INTERFACE PRB PROBLEM in OR SGSN4

Summary of the original problem:


- Message queue overflow in S4S, resulting to failure of charging procedures.

How end user/operator could detect the problem:


- Alarm 3463 with argument 073D (S4S).

Description of the fault:


- In case of 2G GGSN initiated PDP modification messages burst, S4S master queue became full due to
a correction introduced through pronto NA05304906 which led to messages being dropped from the
queue and CDRs loss. Correction of NA05304906 was to fetch data volume information from GTP when
a GGSN initiated PDP modification with zero data volume arrives. To do that, it called a stateful
procedure that sent a request to GTP and waits until GTP responds. This behavior caused master
process to lock and when moved out to re-receive all messages in the queue.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 191/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- In case of GGSN initiated PDP modification messages burst, S4S master will receive the PDP
modification message and check the data volumes if it finds them 0, it will forward the modification
message to GTP to update the data volumes.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- GTP_GXJX.PAC 13.252-0
- S4S_GMJX.PAC 6.55-0

Faulty component first delivered in(e.g. release, CD):


- NS15

2.187 NS16.50752 Possilbe IPDU SWO in case of multiple eNodeB Configuration Update messages
from the same eNodeB

NA05982786 After IPDU2 to reset is when resets remain high.

Summary of the original problem:


- IPDU [1-2] SWO occurred due to S1LBS auto-crash because of threads deadlock.

How end user/operator could detect the problem:


- IPDU SWO.

Description of the fault:


- In order for the eNB Configuration Update to be completed, 2 internal messages arrive in IPDU. Due to
the locking mechanism of S1LBS (that handles these messages), there is a very rare case in which 2
threads could lead to deadlock. There are 2 scenarios that could rarely lead to this. 1) An eNB could
send more than one eNB Configuration Update messages at the same time without waiting for
Response. This could rarely lead to threads deadlock. And 2) An eNB sends 1 eNB Configuration Update
and 2 internal messages arrive at the exact same time. Due to that IPDU did not answer to eNB, the eNB
sent again eNB Configuration Update and again the 2 internal messages arrived at the exact same time.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 192/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Dependency on configuration:
- None

Faulty component and version:


- LNX92DG2.IMG 12.4-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None
Description of the correction:
- The lock mechanism of S1LBS that affects eNB Configuration Update was improved in order to work in
a complete atomic operation way over the eNB Configuration mechanism.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.188 NS16.50753 MME did not send TAU reject message when Roaming control and ODB for
MME feature were on

PR200411 The MME does not send TAU reject message when Roaming control and ODB for
MME feature are on

Summary of the original problem:


- TAU reject/accept message was not sent in some cases when one or more APNs in "SGSN Context
Response" message from SGSN were not contained in the list of APNs received in Update Location
Answer from HSS and Operator-Determined Barring (ODB) feature was activated.

How end user/operator could detect the problem:


- TAU reject or TAU accept would not be sent in some cases when there was a different APN
configuration between SGSN and MME HSS and ODB was activated.

Description of the fault:


- When ODB feature was activated and one or more APNs in "SGSN Context Response" message from
SGSN were not contained in the list of APNs received in Update Location Answer from HSS an
unhandled exception was thrown in method isOperatorDeterminedBarredTauProcedure() that caused the
tau procedure to be interrupted.

Related feature / functionality:


- 3G Inter System Mobility, ODB feature and Roaming control feature

Dependency on configuration:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 193/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
- None

Description of the correction:


- Case when one or more APNs in "SGSN Context Response" message from SGSN are not contained in
the list of APNs received in Update Location Answer from HSS does not cause an exception in
isOperatorDeterminedBarredTauProcedure().

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 11.13-30

Faulty component first delivered in(e.g. release, CD):


- NS15

2.189 NS16.50754 CSFB &IS TAU/RAU KPIs drop

PR210751 NS16.5 MP1 NSHW3.0 TA: CSFB & IS TAU/RAU KPIs drop

Summary of the original problem:


- During Stability run, a transaction drop observed in CSFB and TAU procedures.

How end user/operator could detect the problem:


- Drop in KPIs.

Description of the fault:


- When multiple UE needed to fallback to 2G (CSFB) with call indication, MME reserved unnecessary
resources which led to reduced performance on CSFB and TAU procedure.
TAU was also affected due to the fact that both shared the same resource pool.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.5-0
- LNX934G2.IMG 11.7-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 194/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
- None

Description of the correction:


- Previously MME resources from the CSFB procedure is now released on time.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

2.190 NS16.50755 CALENDAR TIME REFERENCE LOST

NA05926595 CALENDAR TIME REFERENCE LOST

Summary of the original problem:


- After MSS15 MP4.0 P3 upgrade the alarm 3455 CALENDAR TIME REFERENCE lost
It was discovered that NTP was blocked by IPSEC rule. IPSEC rule is not working as it should:
Passby/deny rule (both direction + local IP + remote IP) passed OUT message, but discarded IN
message with destination IP = local IP.

How end user/operator could detect the problem:


- By configuring a passby rule (both direction + local IP + remote IP) and attach it to unit. Then, ping
remote IP.

Description of the fault:


- Passby/deny rule with both direction did not match inverse direction.

Related feature / functionality:


- None

Dependency on configuration:
- IPSec passby/deny rule with "both direction, local IP, remote IP".

Workaround:
- Configure 2 rules for IN and OUT direction messages.

Description of the correction:


- Roll back to original codes, which will handle inverse direction messages.

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 195/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Interface Effects:
- None

Faulty component and version:


- IKEPRBGX.PAC 8.9-0, LNX988G2.IMG 1.31-0

Faulty component first delivered in(e.g. release, CD):


- NS17

2.191 NS16.50756 MME sends error message to HSS because SRVCC failed

NA05991562 (Flexi NS-MME NS16.5WU3)MME send error message to HSS cause SRVCC
failed

Summary of the original problem:


- MME sets SRVCC not supported in ULR during Attach, even though UE sent Attach Request with
SRVCC support.

How end user/operator could detect the problem:


- Check UE SRVCC supported AVP in ULR and compare it with the respective value sent in Attach
Request.

Description of the fault:


- In a specific scenario, UE was not set in Deregistered state. A subsequent attach, was considered as
double attach, resulting to not acquire SRVCC supported indication from new Attach Request.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG, legacy code.

Faulty component first delivered in(e.g. release, CD):


- Too legacy to be specified.

Workaround:
- None

Description of the correction:


- Set in database subscriber SRVCC support indication received in Attach Request and handle correctly
previous deregistration of the subscriber.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 196/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.192 NS16.50757 Abnormal UE signaling control wasn't triggered when PDN connectivity was
rejected due to wrong PDN type

NA05995095 (Flexi NS NS16.5) Abnormal UE signaling control wasn't triggered when PDN
connectivity was rejected due to wrong PDN type

Summary of the original problem:


- When PDN connectivity was rejected due to wrong PDN type, abnormal UE signaling control wasn't
triggered as it supposed to.

How end user/operator could detect the problem:


- KPI of PDN Connectivity Reject was increased dramatically even from a solid UE, when this UE
repeatedly was keeping sending the same PDN Connectivity, even if this Request was rejected from
MME.

Description of the fault:


- Information that UE had passed to abnormal behavior was lost when subscriber was discarded from the
procedure due to error of PDN connectivity.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.146-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Information that UE is behaving abnormally is restored to subscriber data and MME handles UE as
abnormal.

Risk analysis of the correction:


- UE is not handled as "abnormal" and KPI of PDN rejection is increased.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- KPI of PDN Connection Reject has been corrected.

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 197/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.193 NS16.50758 When Inter MME TAU with SGW change was performed and UE did not respond
with TAU complete, 3717 alarm "SGW Unavailable" was raised.

NA05985231 (Flexi NS-MME NS16.5)3717 alarm

Summary of the original problem:


- When Inter MME TAU with sgw change was performed and UE did not respond to TAU Accept with
TAU complete message then alarm 3717 was raised.

How end user/operator could detect the problem:


- Operator could detect the problem from 3717 alarm report which indicates that local SGW address
communication failed. User could not detect the problem because the UE has not responded.

Description of the fault:


- When inter MME TAU with SGW change was performed and TAU complete was not sent from UE, then
MME did not properly update the sgw_c_fteid value. This caused the delete session request msg to be
sent to wrong IP Address. This also raised alarm 3717.

Related feature / functionality:


- Inter MME TAU with sgw change.

Dependency on configuration:
- The SGW relocation PRfile (2029) should be enabled with FF value.

Workaround:
- None

Description of the correction:


- After processing eps_tau_complete with cause ue not responding from CPPU, MMDU updates the
sgw_c_fteid value when Inter MME tau is performed.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 7.265-0

Faulty component first delivered in(e.g. release, CD):


- NS15

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 198/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.194 NS16.50759 ODB flag is still set as "Y" on MME side after removal of ODB

PR202017 ODB flag is still set as "Y" on MME side after removal of ODB

Summary of the original problem:


- Operator-Determined Barring (ODB) flags were not removed after message "Insert Subscriber Data
Request" (IDR) was received from HSS with subscriber status set to "SERVICE-GRANTED".

How end user/operator could detect the problem:


- Assuming some ODB flags were set for a subscriber, if ODB data was removed on HSS side, and HSS
sent message IDR with subscriber-status "SERVICE-GRANTED" in subscriber-data IE to MME, the ODB
flags were still set in the subscriber as returned by ZMMS command.

Description of the fault:


- Old ODB flags were not reset when IDR message was received from HSS with subscriber-status
"SERVICE-GRANTED" in Subscriber-Data IE. ODB flags were still visible in the subscriber in question
using the ZMMS MML command. However, if subscriber-status "SERVICE-GRANTED" was received
then ODB flags were not taken into account anymore, so this fault did not cause any other side effects
other than the flags being visually available in the output of ZMMS command for the subscriber in
question.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.13-30

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Old Operator-Determined Barring (ODB) flags are reset when "Insert Subscriber Data Request" (IDR)
message is received from HSS with subscriber-status "SERVICE-GRANTED" in Subscriber-Data IE.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 199/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.195 NS16.50760 MME was not sending SGsAP location update to available VLR after MME
restart.

NA05975505 Why MME is not sending SGsAP location update to available VLR after MME
restart.

Summary of the original problem:


- Before MME was restarted, VLR was set offline (due to VLR upgrade). After MME restart
there were no Location Update Requests sent to available VLR.

How end user/operator could detect the problem:


- After MME restart, UEs could not perform combined attach, instead EPS attach was possible.

Description of the fault:


- After MME restart, SGs handler informed TrHandler about the availability of all VLRs. The erroneous
behaviour was that SGs communicated the VLR availability for all VLRs as "connected" meaning that
they had active sctp associations with each one. This was wrong as we had a VLR that was set to offline
mode. Upon startup, TrHandler tried to send Location Update Requests towards the VLR that was not
available and SGs replied with an sctp error message indicating that failure because no sctp association
existed. The result was an EPS attach with emm cause "MSC temporarily not reachable".

Related feature / functionality:


- Multipoint MSC/VLR support feature.

Dependency on configuration:
- None

Workaround:
- Delete and re-create the VLR links.

Description of the correction:


- SGs communicates the correct sctp association status for every VLR to all TrHandlers upon process
startup.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX969G2.IMG 11.4-0

Faulty component first delivered in(e.g. release, CD):


- NS15

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 200/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.196 NS16.50761 SOAP - Format String Vulnerability (libxml2)

PR156253 T16.2 SP1 Cloud - T5XX3100 - LNXAB6G2 1.8-0 - SOAP - Format String
Vulnerability (libxml2)

Summary of the original problem:


- Call for libxml2 could cause core dump, if the xml contained some invalid format string. When libxml2
solved some format string, e.g. "%123456$s" with vsnprintf, core dump could happen.

How end user/operator could detect the problem:


- When xmllint was used in order to analyze an xml which contained some invalid format string, e.g.
"%123456$s", then xmllint printed out "*** invalid %N$ use detected *** Aborted" and coredump was
created.

Description of the fault:


- Some invalid format string could not be processed, e.g. "%12345$s" when given as input into vsnprintf.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Code is committed for the invalid format string to be processed and not to create coredump.

Risk analysis of the correction:


- None

Faulty component and version:


- LNXA8CG2 3.1-0.

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 201/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.197 NS16.50762 MME ARP issue caused during inter-system TAU

NA05995101 MME ARP issue when inter-system TAU

Summary of the original problem:


- During Inter System TAU from SGSN Rel99 the MME set the ARP value to 1. The value from the SGSN
Context Response was not used and the bearer was created with this priority. After that the MME tried to
downgrade the priority according to the HSS and the modification was failed in EndB. It was set to not
allow the replacement of priority 1 to lower priority.

How end user/operator could detect the problem:


- Operator could notice failures in Update Bearer Response since the modification failed in EndB for
priority reason.

Description of the fault:


- In the current implementation, MME was not considering the ARP value from the SGSN context
response messages for Pre-release 99 and release 99 scenarios. When the QOS was in release 99, pre-
release 99 MME would fill the ARP value as 1. This shouldn't be applicable for release 99 scenarios.

Related feature / functionality:


- None

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Use of ARP Value that is received in SGSN Context Response for SGSN rel99 and after.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX924G2.IMG 7.17-0

Faulty component first delivered in(e.g. release, CD):


- NS15

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 202/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.198 NS16.50763 Service affectation was presented after upgrade from NS15MP1 to NS15 MP2

NA05965736 Flexi NS-SGSN / After update it presents service affectation

Summary of the original problem:


- After upgrade from NS15MP1 to NS15 MP2 PDP rejection increased for a specific APN:
internetdefault.tuenti.com.ec which is configured to do APN override.

How end user/operator could detect the problem:


- PDP rejection increased for specific APNs.

Description of the fault:


- Erroneous internal pronto correction PR089673 caused the issue. Erroneous Customer Documentation
for APN Override Feature stated: "If the roaming subscriber has an allowed visiting address and the
requested APN is incorrect, the PDP context is activated with a default SGSN APN.". According to
feature specification the first suitable subscription record should be used for a roaming subscriber with
VAA flag on.

Related feature / functionality:


- APN Override Feature.

Dependency on configuration:
- IMEI Based APN override feature should be on and configured.

Workaround:
- None

Description of the correction:


- Erroneous internal pronto correction for PR089673 reverted. Erroneous APN Override Feature
Customer Documentation modified to: "If the roaming subscriber has an allowed visiting address and the
requested APN is incorrect, the PDP context is activated with the first suitable APN from subscription".

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- PDPs with unknown requested APNs will not be rejected.

System effects:
- None

Other effects:
- Correction effects: PDPs with unknown requested APNs will not be rejected.

Interface Effects:
- None

Faulty component and version:


- GMG_G6JX 27.174-3

Faulty component first delivered in(e.g. release, CD):


- NS15 MP2

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 203/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.199 NS16.50764 OpenSSL ≤ 1.0.1t, ≤ 1.0.2h - Multiple Vulnerabilities - CVE-2016-2182

PR176863 OpenSSL ≤ 1.0.1t, ≤ 1.0.2h - Multiple Vulnerabilities - CVE-2016-2182

Summary of the original problem:


- Security vulnerability found in OpenSSL v1.0.0.

How end user/operator could detect the problem:


- A remote user supplied a specially crafted value to trigger an out-of-bounds write error in BN_bn2dec()
in 'crypto/bn/bn_print.c' and caused the target application using OpenSSL to crash.

Description of the fault:


- If an oversized BIGNUM was present to BN_bn2dec(), it caused BN_div_word() to fail and to not
reduce the value of 't'. This resulted in OOB writing to the bn_data buffer and eventually crashing.

Dependency on configuration:
- WR Linux unit with OpenSSL v1.0.0

Faulty component and version:


- LNXELF05.IMG 4.9-12
- LN071C05.IMG 4.9-12
- LNXPAR05.IMG 4.9-12
- LNXELF07.IMG 4.9-12
- LN071C07.IMG 4.9-12
- LNXPAR07.IMG 4.9-12
- LNXELF04.IMG 4.9-12
- LN071C04.IMG 4.9-12
- LNXPAR04.IMG 4.9-12

Faulty component first delivered in (e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- Fixing it, by checking return value of BN_div_word() and checking that buffer does not overflow.

Risk analysis of the correction:


- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.200 NS16.50766 Increase in S1 RESET // Femto-GW

NA05991744 NA05991744 / MME Increase in S1 RESET//Femto GW

Summary of the original problem:


- MME doesn't respond to S1 Messages to eNB/Femto-GW after Switchover.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 204/231
D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- MME doesn't respond to S1 Messages to eNB/Femto-GW after Switchover.

Description of the fault:


- Working IPDU didn’t send synchronization message to spare IPDU to delete the old connection under
the following scenario:
1) eNB/Femto-GW S1 setup established
2) eNB/Femto-GW SCTP was DOWN
3) eNB/Femto-GW sent new S1 Setup Request from different IP or port.
4) Perform IPDU Switchover.
5) New working IPDU sent INIT to both old and new IP/port.
6) eNB/Femto-GW sent Abort to the old IP/port.
7) IPDU deleted all connection data including global ID from global IP map.
8) eNB/Femto-GW S1 Messages will not be answered as global ID cannot be found in global ID map.

Dependency on configuration:
- None

Faulty component and version:


- LNX92DG2.IMG 12.21-0

Faulty component first delivered in(e.g. release, CD):


- NS2.2 2.0

Workaround:
- Restart eNB/Femto-GW or MME.

Description of the correction:


- Working IPDU will check if connection exists in connection lost map upon receiving a new S1 Setup
Request.
- If it exists, then it will check if IP address or port changed in the new S1 setup.
- If changed, it will send SYNC message to spare IPDU to delete the old connection.

Risk analysis of the correction:


- Wrong output in ZB6I.

Correction effects:
- None

Interface effects:
- S1-C interface

Customer effects:
- None

Test requirements:
- None

2.201 NS16.50767 MME sending PAA - IPv6 - ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00 in


CSReq

CAS-11908-F0Z5 MME sending PAA - IPv6 - ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00 in


CSReq

Summary of the original problem:


- MME sets PDN Address Allocation IPv6 address of Create Session Request to
ff:ff:ff:ff:00:00:00:00:00:00:00:00:00:00:00:00.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 205/231
D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- Create Session Request of PDN connectivity procedure is rejected by SGW-PGW.

Description of the fault:


- MME wrongly initialises PDN Address and Prefix IPv6 address to FFFFFFFF00000000000 instead of
0000000000000000000.

Dependency on configuration:
- Prfiles;
- MME_UE_PROVIDED_APN_ENABLED (2050),
- MME_OVERRIDE_UE_INV_APN (2051),
- MME_OVRD_INV_APN_PDN_CO (2250)
should be on.

Faulty component and version:


- LNX934G2.IMG 7.29

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Set correctly PDN Address Allocation IPv6 address in Create Session Request.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Following PRfiles should be on:
- MME_UE_PROVIDED_APN_ENABLED (2050),
- MME_OVERRIDE_UE_INV_APN (2051),
- MME_OVRD_INV_APN_PDN_CO (2250)

2.202 NS16.50768 Wrong counting of RAU events

NA05973702 FlexiNS - SGSN NS15 MP2 is counting RAU events as MME-SGSN RAU via S3

Summary of the original problem:


- SUCC_IN_RAU_MME_TO_3GSGSN and FAIL_IN_RAU_MME_TO_3GSGSN which by definition count
RAU MME to SGSN events via S3, were increasing even though S3 interface was not configured.

How end user/operator could detect the problem:


- By checking in statistics that counters SUCC_IN_RAU_MME_TO_3GSGSN and
FAIL_IN_RAU_MME_TO_3GSGSN were increasing.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 206/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the fault:
- There was not check whether user was post-rel8 or pre-rel8, so the counter was increasing in both
cases. As a result, counters were incrementing SUCC_IN_RAU_MME_TO_3GSGSN and
FAIL_IN_RAU_MME_TO_3GSGSN even if S3 was not configured.

Dependency on configuration:
- Gn sgsn

Faulty component and version:


- GST_GMJX.PAC 26.59-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP3

Workaround:
- None

Description of the correction:


- User is checked before incrementing the aforementioned counters. If user is pre-rel8 counters are not
incremented.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.203 NS16.50770 MME did not send Delete Session Request when procedure was discarded by
UE AMBR as zero.

PR178969 MME does not send Delete Session Request when the UE performs 2nd attach
procedure without detaching first

Summary of the original problem:


- MME doesn't send Delete Session Request when procedure was discard by UE AMBR as zero.

How end user/operator could detect the problem:


- When UE AMBR as zero, Intersystem Attach, Inter MME TAU cases, MME will trigger the implicit
detach approach and send DSR, but no signalling towards UE/ENB. And for other scenarios like Service
Reject, TAU reject MME send DSR at the same time when sending Reject messages to UE/ENB.

Description of the fault:


- During Attach/Intra MME Tau/Service Request/CSFB procedure in some erroneous situation MME will 0
value for "Ue Ambr" in the ULA message. The procedure was discard but the session was not deleted by
MME.

Dependency on configuration:
- None
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 207/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Faulty component and version:
- LNX934G2 11.100-0
- LNX924G2 11.60-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Intersystem Attach, Native GUTI Attach, IMSI Attach, Double Attach, Inter MME TAU cases, MME will
trigger the implicit detach approach and send DSR, but no signalling towards UE/ENB. And for other
scenarios like Service Reject, TAU reject MME send DSR at the same time when sending Reject
messages to UE/ENB When UE AMBR as zero.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.204 NS16.50771 MME China LI X2 interface failure

NA05982880 (NS16.5)The MME China LI X2 interface cannot establish after MME upgrade
from NS16 MP1 to NS16.5

Summary of the original problem:


- MME China LI X2 interface cannot establish after MME upgrade from NS16 MP1 to NS16.5, the result
of ping test is ok.
There are totally 8 MMEs upgraded from NS16MP1 to NS16.5, only MME09 X2 interface is in OK states,
other 7 NEs are all have same problem with X2 is in NOK states.
MAIN LEVEL COMMAND ___
VBO:LIA=MME;

Flexi NS SHMME10BNK 2016-12-05 23:39:31


LAWFUL INTERCEPTION INTERFACE STATES:

LIC IF STATE IP ADDRESS


------- ------------ ---------------------------------------------
X1 ESTABLISHING 168.2.1.57:8261
X2 NOK 168.2.1.57:8262

From the wireshark trace, the X2 interface do not send any packet to LIC side.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 208/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- Through the MML command ZVBO:LIA=MME; and from wireshark trace (check if the X2 interface send
any packet to LIC side).

Description of the fault:


- The request to IPDU for MME to open the X2 interface towards LIC (with dmx message:
li_ch_mme_conn_req_s) was not send to the IPDU where the X2 interface was created. Instead, the
above mentioned dmx message was sent to the IPDU that was created first after ACTA restart and not to
the IPDU, which has the X2 interface established. That why X2 connection could not established in
pronto's case.

Dependency on configuration:
- 2 pairs of IPDUs (4 IPDUs).

Faulty component and version:


- LNX92DG2.IMG 1.43-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- Create the X2 interface to the other (pair) active (WO-EX) IPDU.

Description of the correction:


- The L1CPRB instructs the IPDU where the X2 interface is created to initiate the communication towards
the LIB. After one IPDU IP of the IP list is returned, a check is added if this is also the same IP where the
X2 interface is created.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

2.205 NS16.50772 UCSW version was not correct after AHUB3-A UCSW/IPMC activation

PR146640 RDY 230743 - UCSW version is not correct after AHUB3-A UCSW/IPMC activation

Summary of the original problem:


- UCSW version was not correct after AHUB3-A UCSW/IPMC activation.

How end user/operator could detect the problem:


- By resetting LMP when IPMC enters reset process during the activation of a new firmware may cause
this problem.

Description of the fault:


- This problem is caused by IPMI firmware defect, it was exposed when reset IPMC(activating a new
firmware) and reset LMP at the same time. Below are the steps of IPMC resetting:
1. IPMC enters reset process when activating a new firmware.
2. IPMC will check if all conditions are okay before resets itself, this may take a few seconds.
3. IPMC resets itself.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 209/231


D553209967 © Nokia 2016
Version 1.0
Confidential
4. Boot from new firmware.
If a cold reset for LMP is received in step 2 above, and not all LMP reset stages are done before resetting
IPMC (above step 3) it causes this issue to occur.

Faulty component and version:


- AEM00016.IMG 1.14-0
- AEM00017.IMG 3.0-117

Description of the correction:


1. During step 2, IPMC will check if there is a pending reset operation for LMP, if yes, IPMC will wait for
this reset operation to finish (all stages) and then reset itself. This solution is included in 9.23 EB
firmware.
2. In 9.24 EB firmware, IPMC will check if there is any pending reset state after IPMC reset (IPMC can
restore running states across IPMC reset), if yes, it will clear the state.

HW UNIT: AHUB3-A
Firmware application: IPMC
Firmware version: 00.24.0000
Corresponding AEM Delivery module: AEM00016
Corresponding AEM Delivery module version: 1.15-0

HW UNIT: AHUB3-A
Firmware application: UCSW
Firmware version: 03.00.0120
Corresponding AEM Delivery module: AEM00017
Corresponding AEM Delivery module version: 3.0-120

Dependency on configuration:
- None

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- Do not reset LMP when IPMC enters reset process when activating a new firmware.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 210/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.206 NS16.50773 Alarm 3550 was active on IPPU13/15/17 although the application was configured

NA05935573 Alarm 3550 is active on IPPU13/15/17 although the application is configured

Summary of the original problem:


- Alarm 3550 appeared on IPPUs due to missing LIB IP address although application configuration had
been done properly.

How end user/operator could detect the problem:


- By checking alarm 3550 on IPPUs.

Description of the fault:


- The problem occurred on initialization procedure of TCP hands from GLP PRB, during supervision
message from USAPRO. During initialization GLP PRB received the IP addresses from Uibfil. GLP PRB
got those IP addresses with the "snl_get_ips_by_application" procedure. This procedure took as input a
list of IP addresses. The IP list is type "application_ip_list_t" and had less IP addresses than it should. As
a result, it returns an IP list where many IP addresses were missing. Such an address was the LIB IP
address of one IPPU. So, when an IP address is missing, the Alarm 3550 is raised.

Related feature / functionality:


- None

Dependency on configuration:
- None

Description of the correction:


- Modification of the amount of TYPE "application_ip_list_t" from 42 to 128 in order to meet the new
hardware specifications.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- dty07693.sdt
- application_ip_list_t 1.2

Faulty component first delivered in(e.g. release, CD):


- NS 16

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 211/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.207 NS16.50774 CSFB degradation

NA05994265 CSFB degradation

Summary of the original problem:


- When subscriber was not in MME previously and combined IS TAU was performed which failed with
Initial Context Setup Failure, MME did not inform VLR that subscriber was not in the MME.

How end user/operator could detect the problem:


- Operator would receive multiple SGs Paging Requests and most probably will respond with Paging
Reject and cause IMSI_Unknown.

Description of the fault:


- When subscriber was not in MME previously and combined IS TAU was performed which failed with
Initial Context Setup Failure, MME did not inform VLR that subscriber was not in the MME.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.5-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Impact to End-User:
- None

Impact to Operator:
- Will notice KPI drop in paging reject.

Workaround:
- None

Description of the correction:


- When subscriber is not in MME previously and combined IS TAU is performed which fails with Initial
Context Setup Failure, MME sends a SGs Detach indication in VLR.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 212/231


D553209967 © Nokia 2016
Version 1.0
Confidential
2.208 NS16.50775 ACPI4-B Firmware update failed

NA05992182 (NS16.5)ACPI4-B Firmware update failed

Summary of the original problem:


- ACPI4-B Firmware update failed.

How end user/operator could detect the problem:


- After executing ZD8U upgrade eSW, and then activate the new eSW with ZD8A.

Description of the fault:


- One exception occurred during execution of ZD8A to activate new eSW. So D8A failed in the end.

Dependency on configuration
- Configuration with ACPI4-B blade is needed.

Faulty component and version:


- ILIBRAGX.PAC 2.41-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- Activate eSW again.

Description of the correction:


- Adding protection code in current routine. When one message is received, check the message length
first. If the length of message is invalid, ignore this message and record one computer log. This
correction will avoid exception occur again when wrong message is received.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.209 NS16.50776 Service Request success rate decreased because of Modify Bearer Response
not include S1-U GTP-U FTEID as part of Inter MME TAU

NA05983132 (Flexi NS-MME NS16.5)MME upgrade to NS16.5, the Service Request success
rate decreased

Summary of the original problem:


- The UE tried an Inter MME TAU with active flag on and the SGW did not include the S1-U GTP-U
FTEID information element in the Modify Bearer Response. The MME send to UE the GTP-U teid with
zero value.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 213/231


D553209967 © Nokia 2016
Version 1.0
Confidential
How end user/operator could detect the problem:
- The operator would not notice any failure in the Inter MME TAU but will noticed KPI drops in the Service
Request after that since MME had send zero GTP-U teid. The user will experience Service Rejection.

Description of the fault:


- The UE tried an Inter MME TAU with active flag on and the SGW did not include the S1-U GTP-U
FTEID information element in the Modify Bearer Response, the MME send the SGW U TEID to zero in
Initial Context Setup Request.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 7.254-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- We check if the Modify Bearer Response as part of Inter MME TAU procedure not include the S1U GW
FTEID and if not we fill this info from Context Response.

Risk analysis of the correction:


-None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Inter MME TAU active flag on and in Modify Bearer Response the SGW did not fill the S1U GW Fteid.

2.210 NS16.50777 SWU configuration not loaded to 3rd shelf SWU after ZD8A

PR200010 SWU configuration not loaded to 3rd shelf SWU after ZD8A

Summary of the original problem:


- SWU configuration not loaded to 3rd shelf SWU after ZD8A.

How end user/operator could detect the problem:


- Execute the MML "ZYFL::::;", there is not such log "File loaded to switch" for the third shelf.

Description of the fault:


- SWU configuration not loaded to 3rd shelf SWU after ZD8A.

Dependency on configuration:
- Upgrade 3 or more than 3 shelves at the same time.

Faulty component and version:


- AKSELIGX.PAC 9.52-0 or older.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 214/231
D553209967 © Nokia 2016
Version 1.0
Confidential
- AKSELIGX.PAC 10.3-0 or older.

Faulty component first delivered in(e.g. release, CD):


- Too legacy to be defined

Workaround:
- Using the MML command "ZYFM:UCF:SWU,X;" to upload configuration file to the failed SWU.

Description of the correction:


- The PRB "AKSE" can't process 3 shelf at the same time, its hand group 4 has only 5 hand, it can only
process 5 SWU at the same time, but every shelf has 2 SWU, so AKSE could only process 2 shelf at the
same time, so in this pronto the third shelf load the configuration file failed. The correction is that we
enlarge the hand number of hand group 4 from 5 to 10, in our NE the max shelf is 5, so 10 hand is
enough.

Risk analysis of the correction:


- None

Correction effects:
- None

Customer effects:
- None

Interface Effects:
- None

Test requirements:
- 3 or more than 3 shelves.

2.211 NS16.50778 Netstat caused segment fault and coredump was generated

PR156418 NS15 MP3 NSHW:3.0 SA-MME, netstat coredump

Summary of the original problem:


- Netstat -a was generating segfaults when certain SCTP traffic was running.

How end user/operator could detect the problem:


- When SCTP connections reached a certain number (enbs=40k), and at this time execute netstat -a.

Description of the fault:


- When the segfault happened, the SCTP sysfs was containing NULL strings. The related SCTP pronto is
PR101202. Affected function of netstat is sctp_assoc_do_one. The first kind of segment fault caused is
when NULL char pointer passed as 1st argument to lib function atoi. The second one is when first time
strtok_r is called, the 1st argument of strtok_r is NULL (this is rare but it happened) and char* ss2 is not
initialized, so strtok_r will segfault when it tries to de-reference the random memory address (ss2).

Faulty component and version:


- LN071C05 4.9-11
- LN071C07 4.9-11
- LN071C04 4.9-11

Faulty component first delivered in(e.g. release, CD):


- 4.9-0

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 215/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- Function returns a message when NULL pointer argument is found before following
functions is called in sctp_assoc_do_one:
1. atoi
2. firsrt time strtok_r is called

Risk analysis of the correction:


- Function returns early if netstat is trying to parse NULL strings. The following warning message will
output to serial, instead of a segment fault: "warning, got bogus sctp assoc line." Other than this, no logic
change to the function. The risk is very low. This message reminds user that something wrong is in SCTP
layer, and the resulted strings cannot be parsed and so coredump is omitted.

2.212 NS16.50780 Wrong BCD encoding in case IMREQ=ONNONSTD and IMEI/SV had less that
normal digits.

PR173789 IMREQ=ONNONSTD wrong BCD encode ( FF is wrong)

Summary of the original problem:


- When the option for IMEI request allowed nonstandard values for IMEI and the IMEI length was shorter
than the valid length and had odd length value, the MME encoded IMEI value wrongly. MME filled the
remaining bytes with the value FF. Faulty IMEI was forwarded to Service Gateway (SGW) but the SGW
was rejecting it with cause "Cause: Mandatory IE incorrect (69)".

How end user/operator could detect the problem:


- The SGW was replying to MME with reject cause "Cause: Mandatory IE incorrect (69)".

Description of the fault:


- In order to keep a valid length for the IMEI internally, when IMEI value is shorter, MME fills the extra
bytes of IMEI with the value FF. This IMEI value was sent to the SGW but the SGW was not accepting
the IMEI value as a valid one.

Dependency on configuration:
- Parameter IMREQ = ONNONSTD should be set at MME and UE must send IMEI with length shorter
than the valid IMEI length.

Faulty component and version:


- LNX934G2.IMG 12.1-0
- LNX924G2.IMG 12.1-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP1

Workaround:
- None

Description of the correction:


- When the IMEI value handled by the MME includes bytes with value equal to FF and is forwarded to
SGW, the bytes filled with value FF are not included in the message to SGW. So, now this is the default
behavior. In case the operator wants to keep the old behavior which includes the value FF in IMEI,
parameter S11_IMEI_POPULATED_CONTENT has been created. If this parameter is set to 1, IMEI with
values filled with FF will be included in the messages to SGW. If parameter is set to 0, MME keeps the
default behavior as described.

Risk analysis of the correction:


- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 216/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Correction effects:
- None

Interface effects:
- IMEI with bytes filled with FF will not be included in the messages towards the SGW.

Customer effects:
- The SGW will not reject requests from the MME due to invalid value of the IMEI.

Test requirements:
- Parameter IMREQ should be set to ONNONSTD. IMEI should have an IMEI with odd and shorter length
than the valid one.

2.213 NS16.50781 EPS_ROAM_PDN_ACT_FOR_VOLTE_FAIL increase after Roaming Control for


IMS and VOLTE

NA05947303 NS 16.5 - EPS_ROAM_PDN_ACT_FOR_VLTE_FAIL increase after Roaming


Control for IMS and VOLTE FOA

Summary of the original problem:


- EPS_ROAM_PDN_ACT_FOR_VOLTE_FAIL counter was increased after Roaming Control for IMS and
VOLTE.

How end user/operator could detect the problem:


- During a PDN Connectivity procedure with VoLTE service for roaming UE failed PDN Connectivity
procedure was rejected and Traffica report was sent with incorrect cause value. Operator could detect
the problem if Traffica report that was sent with incorrect cause value was observed.

Description of the fault:


- MME sent the Traffica report with incorrect cause when PDN Connectivity procedure with VoLTE
service for roaming UE fails.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 8.2-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Correct cause code was included to Traffica report when PDN connectivity procedure with VoLTE
service for roaming UE failed.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 217/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Customer effects:
- None

Test requirements:
- None

2.214 NS16.50782 IPDU unit restarted automatically when it went to WO-EX status after upgrade

NA05979981 (Flexi NS-MME NS16.5)IPDU units restarted automatically when it came to WO-
EX status after upgraded to NS16.5

Summary of the original problem:


- After an MME upgrade, IPDU was spontaneously restarting and kernel oops was observed. The issue
was due to SCTP module function code error (NULL pointer).

How end user/operator could detect the problem:


- When the same SCTP association link was created twice, kernel oops was observed and unit restarted.

Description of the fault:


- When duplicated SCTP association parameters were tried to be created by the Application SW,
sctp_connectx() function triggered a NULL pointer in the SCTP part of kernel. That resulted in kernel
oops and unit restart.

Dependency on configuration:
- If a duplicate SCTP association is being configured in addition to the already existing SCTP association.

Faulty component and version:


- LNXELF04.IMG 4.1-0 (for ACPI4 board)
- LNXELF05.IMG 4.1-0 (for CPVC board)
- LNXELF07.IMG 4.1-0 (for ACPI5 board)

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- The correction is to avoid the NULL pointer issue in case the same SCTP association link is configured.

Risk analysis of the correction:


- None

2.215 NS16.50783 Files could not be transferred to OMU using ftpput-command

PR161879 Files cannot be transfer from TGS to other DXT OMU using ftpput-command in
ATCA

Summary of the original problem:


- “ftpput”- command used for transferring files from LinDX unit to OMU disk was failing to units using
newer Linux version.

How end user/operator could detect the problem:


- By using ftpput tool to transfer local file (size 64KB) to OMU disk.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 218/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the fault:
- On newer busybox releases (WR4.3), ftp tool is updated to up-to-date FTP protocol and one of the
commands (ALLO) which was used to reserve storage for large file is obsolete. However, this command
is necessary when the remote side is OMU (which is still using the old protocol due to the system
limitation).

Dependency on configuration:
- None

Faulty component and version:


- LN071C04.IMG 3.153-2
- LN071C05.IMG 3.153-2
- LN071C07.IMG 3.153-2

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- FTP ALLO raw cmd command is issued before STOR when non-default file size is detected.

Risk analysis of the correction:


- The new FTP protocol backwards compatible with the old one so no problem will occur.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- System test

2.216 NS16.50784 IMG size much bigger than the previous ones.

PR164543 IMG size much bigger than the previous ones

Summary of the original problem:


- Image was oversized and caused slow loading speed.

How end user/operator could detect the problem:


- Image loading was much slower than before.

Description of the fault:


- The debug symbol was not striped due to wrong build parameter in build script. The system run-time
performance was not jeopardized but debug symbols consumed a lot of disk space, and hence it
impacted the image loading speed.

Dependency on configuration:
- CPVC

Faulty component and version:


- LNXELF05
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 219/231
D553209967 © Nokia 2016
Version 1.0
Confidential
- LN071C05
- LNXPAR05

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Correct the CPVC build script with production compile parameter.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

2.217 NS16.50785 Performance degradation after critical process kill on MMDU

PR071392 NS15 MP1:: Traffic drop during SubsHandler process restart provocative test case

Summary of the original problem:


- Performance degradation was observed during high load, due to the database version being used
(SolidDB: V7.0_FP20).

How end user/operator could detect the problem:


- KPI drops (response time-outs or/and procedure rejects) were observed during high load or when
critical process (SubsHandler) was being killed on MMDU. Furthermore, depending on traffic load, alarm
1014 - PROCESSOR LOAD RATE ALARM LIMIT EXCEEDED was raised.

Description of the fault:


- Performance degradation due to the database version being used (SolidDB: V7.0_FP20).

Dependency on configuration:
- None

Faulty component and version:


- LNX930G2.IMG 5.16-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Impact to End-User:
- Occasional procedure rejects.

Impact to Operator:
- Lower traffic rates and KPI drops.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 220/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
- None

Description of the correction:


- Solved by upgrading SolidDB from V7.0_FP20 to V7.0_FP26.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 221/231


D553209967 © Nokia 2016
Version 1.0
Confidential
3. NEW / CHANGED FUNCTIONALITY

3.1 NS16.50734 RNC Data Traffic Decrease due To Messages Flow Control from SGSN

NA05938362 RNCs Decrease Data Traffic Until 90% Due To Messages Flow Control From
SGSN

Summary of the original problem:


- The problem was caused by GMG HG2 starvation. When starvation happened, subscriber tried to
perform an outgoing RAU from 3G to 2G and due to the fact that GMG HG2 was left out of hands, routing
area procedure failed and subscriber remained as “IDLE” in PAPU unit.

How end user/operator could detect the problem:


-Traffic degradation can be detected and this is due to RNC flow control after receiving CREF from
SGSN.

Description of the fault:


- The problem was caused by GMG HG2 starvation. When starvation happened, subscriber tried to
perform an outgoing RAU from 3G to 2G and due to the fact that GMG HG2 was left out of hands, routing
area procedure failed and subscriber remained as “IDLE” in PAPU unit.

Dependency on configuration:
- None

Faulty component and version:


- DXPARAN0.IMG 8.3-0
- DXPARAN2.IMG 10.3-0
- DXPARAN6.IMG 9.3-0
- DXPARANX.IMG 10.3-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- FC085_004219:Increase of SGSN GMG PRB G2 hands from 300 to 600:As an option in order to help
customer improve his network performance, it was decided to increase again the number of GMG hands
of second group from 300 to 600. In this way, there is room for more procedures to be served since more
resources will be available to be reserved for outgoing procedures.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Avoid hand starvation on 2nd GMG hand group.

Test requirements:
- Performance Testing
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 222/231
D553209967 © Nokia 2016
Version 1.0
Confidential
3.2 NS16.50769 FC085_004074 Network KPI Downgrade as many counters are mapped to Single
KPI counter

Feature referred into description known as “Technical KPI Success Rate” and exposes “technical”
network performance, excluding faults inducted by user’s subscription (e.g. operator barring, roaming
imitations from HSS etc.).
The difference between “actual KPI” and “technical KPI” vary from network to network and may be quite
big. As reference numbers, typical KPI for Attach SR is about 60-70%, but “technical KPI” for same
network is close to 95-99%. The gap of 30-40% comes from typical Attach reject because of subscriber
limitations (e.g. roaming, for most of the cases).
Then, after subscriber successfully attached to the Network, typical TAU KPI keeps high because
subscription faults are filtered out already (for inter/intra MME TAU scenarios).
But for Intersystem TAUs (TAU over Gn which mentioned into original request), subscriber considered as
“new subscriber” for LTE network so same security checking performed and they may generate typical
faults related with authentication as well as prevision context retrieval operations.

3.3 NS16.50779 FC085_004133 CMAS Performance Enhancements Taiwan Market

The scope of this feature is to improve the MME's CMAS handling. The improvement affects two main
areas. The first area is the ability to handle multiple messages (Write Replace Warnings and Stop
Warnings) with the same Message ID and Serial Number. The second area is a general improvement of
CMAS handling performance.

New PRFILE value for PRFILE WARNING_MESSAGE_DELIVER (Identifier: 2094, Class:2) is


introduced. The value 3 is the one being added.
Using the value 3 in the PRFILE, SBcHandler will handle in parallel all received CMAS requests (Write
Replace Warnings and Stop Warnings) with same Message ID and Serial Number (with PRFILE value 1
or 2, received messages with the same Message ID and Serial Number are being overwritten in case the
previous ones are still ongoing).
The generated reports (XML files under PWS directory) will contain those eNB(s) that have been alerted
and have responded but it will not contain the number of responses received by a eNB, if multiple CMAS
requests (with same Message ID and Serial Number) have been sent to it.

Apart from the above mentioned changes, the internal communication and handling of MME for CMAS
messages is redesigned and implemented in order to improve the capacity and the performance
(regardless of the PRFILE value).

4. 3RD PARTY CORRECTIONS

None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 223/231


D553209967 © Nokia 2016
Version 1.0
Confidential
5. KNOWN OPEN FAULTS

5.1 MME doesn’t send update location to MSS for share MCC 901 Roaming case

Problem report: NA05993815


Exists in: NS 16.5
Correction Target: NS15 MP4, NS 16.5 MP2, NS 17.5
Severity: B - Major
Customer Impact: Mobility

Reported date: 20.02.2017


Closed date: -

Solution / Workaround:

Description:
- MME performs SGs-update location request for all other roamers and home subscribers, except
roaming MCC=901. MCC=901 is a shared MCC for global SIM for M2M service. This Subscriber has
performed combine attach, MME create session to SGW. After create bearer response, MME didn’t
trigger any SGs message. From attach accept message, it can’t be found any EMM cause. This case just
happened MCC=901 subscriber. All other home or roamer SGs are ok.

Solution / Workaround
- Analysis is ongoing by R&D.

5.2 HSS Restoration is not working as per 3GPP specifications

Problem report: NA05999549


Exists in: NS16 MP0.1
Correction Target: NS 16.5 MP2, NS 17.5
Severity: A - Critical
Customer Impact: Operation & Maintenance

Reported date: 20.02.2017


Closed date: -

Solution / Workaround:

Description:
- The Feature Multiple CS Core Support (2299) is required by the customer as they don’t want some
subscribers to do the Combined Attach, so it’s always enabled. E/// MSC doesn't support pooling so the
workaround is to shift the existing users to the new MSC when the old MSC is down, is by manually
sending the Reset from HSS so that MT calls do not fail. When HSS sends Reset Request, MME sets the
SUBSCRIBER TO BE RESTORED IN HSS Flag and NON-EPS ALERT FLAG to start the HSS
Restoration when the UE comes in contact again. MME is supposed to do Update Location towards HSS
and Send UE Activity Indication or Normal Location Update towards MSC. But since MME was not
sending anything towards MSC and thus MSC was not sending any message towards the
HLR and hence HLR would still hold the old MSC information which caused MT calls to fail.

UE is combined attached with the MME/MSC. After getting the S6a Reset Request Message from the
HSS, MME sets the NEAF flag in the subscriber profile. After the UE sends Service Request, MME
updates the Location towards HSS, Resets the NEAF Flag but MME doesn't send any messages over
SGs to the MSC/VLR which is not correct as per 3GPP specs.

Solution / Workaround
- Analysis is ongoing by R&D.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 224/231


D553209967 © Nokia 2016
Version 1.0
Confidential
5.3 Connection from MME to LIMS is not restored after any communication failure

Problem report: NA05981994


Exists in: NS 16.5
Correction Target: NS 16.5 MP2, NS 17.5
Severity: C-Minor
Customer Impact: Operation & Maintenance

Reported date: 20.02.2017


Closed date: -

Solution / Workaround:

Description of the problem:


- After communication from MME to LIMS is somehow failed or LIMS is restarted, the connection looked
ON with the command ZKAQ:INT:LIA=MME; but from LIMS side it looks failure. EL1-USI loosing
reference to socket (posix); only solution is restart entire system.

Solution / Workaround
- Analysis is ongoing by R&D

5.4 X2 Handovers failure KPI increased 0.02% on MME after E/// eNB upgrade

Problem report: CAS-12930-X0S8


Exists in: NS 16.5 MP0.1
Correction Target: NS 16.5 MP2, NS 17.5
Severity: B - Major
Customer Impact: Capacity & Performance

Reported date: 16.02.2017


Closed date: -

Solution / Workaround:

Summary of the original problem:


- In customer network, there is a collision happening between Ongoing ITAU and incoming X2HO
procedures. Current resolution is MME terminating the ITAU and trying to remove the bearers.
But the resolution should be to hold the ITAU and continue the incoming X2HO, once X2HO is completed
then resume the on-hold ITAU procedure.

Solution / Workaround
- Analysis is ongoing by R&D

5.5 CAS-12671-K9Y2 -  S6a Cancel Location SR and ISD SR Went Down After Activating Paging
Profile

Problem report: PR217709


Exists in: NS 16.5 MP0.1
Correction Target: NS 16.5 MP2, NS 17.5
Severity: B - Major
Customer Impact: Stability

Reported date: 15.02.2017


Closed date: -

Solution / Workaround:

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 225/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Summary of the original problem:
- The error occurs when Delete Resources for the dedicated bearer (triggered by S1 Release procedure)
collides with DDN for the same bearer. The resolution of the collision is COCI (which should be
considered if it should be modified when both procedures affect the same bearer). When Delete
Resources is over, Paging procedure should be resumed. However, paging profile feature is on, and in
the constructor of EpsNwPagingInd, code tries to find the APN of the bearer. Since the bearer was
deactivated by Delete Resources, this is not possible and an exception is thrown.
eps_procedure_timeout is sent, but instead of terminating Paging Procedure, it is S1 Release procedure
that gets terminated. That happens probably because the exception is thrown in the constructor and
EpsNwPagingInd state has not actually started. All subsequent messages coming for the subscriber that
can trigger a state transition in Paging procedure are consumed, and the exception is thrown again.

Solution / Workaround
- Analysis is ongoing by R&D

5.6 Received corrupted CDRs at CMD during eSW upgrade of SGSN in NS15 MP3

Problem report: NA05973114


Exists in: NS15 MP3
Correction Target: NS15 MP4, NS 16.5 MP2, NS 17.5
Severity: B - Major
Customer Impact: Operation & Maintenance

Reported date: 10.02.2016


Closed date: -

Solution / Workaround:

Summary of the original problem:


- Received corrupted CDRs at CMD during eSW upgrade of SGSN.

How end user/operator could detect the problem:


- Corrupted CDRs. Malformed data packets in Wireshark trace. CMD could not decode CDRs.

Description of the fault:


- In GIG PRB in procedure "transfer_cdr_to_send_buffer", in which a packet is added to buffer and after
adding the packet, the block is sent to SP unit. In this procedure, variables for cdr_type and length were
not the correct, with the updated/correct values. In GIG Master when "gig_packets_to_sp_unit_s"
message is received, cdr_type variable was missing from code, in the part where the packet data are
copied to internal structure in order to store them in file.

Dependency on configuration:
- None

Faulty component and version:


- GIG_GMJX.PAC 18.1-0

Impact to End-User:
- None

Impact to Operator:
- Corrupted CDRs after MCHU switchover.

Faulty component first delivered in(e.g. release, CD):


- Version too legacy to be specified.

Workaround:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 226/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Description of the correction:
- Store the correct values for cdr_type and length of the packet before sending message
"gig_packets_to_sp_unit_s" and copying cdr_type variable in the local structure before storing to file.
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

5.7 Starvation on GSP Hand Group 3; Follow-up on EME O679

Problem report: NA05978869


Exists in: NS15 MP3
Correction Target: NS15 MP4, NS 16.5 MP2, NS 17.5
Severity: C - Minor
Customer Impact: Capacity & Performance

Reported date: 23.12.2016


Closed date: -

Solution / Workaround:

Summary of the original problem:


- The erroneous behavior has been identified in Intra PAPU relocation scenarios. It is observed that GSP
hand which handles Intra PAPU relocation ends up hanged and is released only after 5 minutes, when a
platform’s timer expires and hand supervision message is sent. Subsequently, GSP Hands that remain
hanging lead to starvation on GSP Hand Group 3.

How end user/operator could detect the problem:


- 3G service loss

Description of the fault:


- The ongoing Intra PAPU relocation collides with an Iu release (from source RNC) but in the end neither
the relocation is completed nor the collision response is received on time. This happen due to the
instructions that are given in the aforementioned collision. Iu release is given the instruction "success"
and Intra PAPU relocation the instruction "release".

Dependency on configuration:
- Location Reporting Control: PRFILE 2177 is False

Faulty component and version:


- GMG_G6JX.PAC 27.174-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP3

Impact to End-User:
- None

Impact to Operator:
- 3G service loss.
NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 227/231
D553209967 © Nokia 2016
Version 1.0
Confidential
Workaround:
-None

Description of the correction:


- The following collision takes place: an ongoing Intra PAPU relocation collides with an Iu release (from
source RNC). In the end, the relocation is not completed and the collision response is not received on
time. As a result, the GSP hand that handles the relocation remains hanging. This happens due to the
instructions that are given in the aforementioned collision. With this correction, the instructions have
changed, Iu release gets the instruction "continue" and Intra PAPU relocation "stay and continue". So, the
above collision ends properly, without leaving hanging hands.

Risk analysis of the correction:


-None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

5.8 No PLMN measurements in ATCA SGSNs (and one DX SGSN)

Problem report: NA05893268


Exists in: NS15 MP2
Correction Target: NS15 MP4, NS 16.5 MP2, NS 17.5
Severity: C - Minor
Customer Impact: Capacity & Performance

Reported date: 08.08.2016


Closed date: -

Solution / Workaround:

Summary of the original problem:


- In customer network, after system restart, M32 counters for specific configured PLMN slots are not
reported.

Solution / Workaround
- Analysis is ongoing by R&D

5.9 Hanging session not deleted due to double attach in the MME

Problem report: NA05998663


Exists in: NS15 MP2
Correction Target: NS15 MP4, NS 16.5 MP2, NS 17.5
Severity: A - Critical
Customer Impact: Capacity & Performance

Reported date: 10.02.2017


Closed date: -

Solution / Workaround:

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 228/231


D553209967 © Nokia 2016
Version 1.0
Confidential
Summary of the original problem:
- Sessions were hanging in SGW due to double attach non-reply from eNB in Authentication Request
and Delete Session was not triggered.

How end user/operator could detect the problem:


- End user cannot detect the problem.
- Operator can observe hanging sessions in SGW.

Description of the fault:


- ΜΜΕ does not send Delete Session Request message to SGW when UE not replied and
NasNondelivery received from eNB in Authentication Request.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.5-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP4

List Releases and/or Change-Delivery where Faulty SW components was delivered.


- Legacy issue.

Impact to End-User:
- None

Impact to Operator:
- Operator will observe hanging sessions in SGW.

Workaround:
- None

Description of the correction:


- MME triggers Delete Session Request during Attach procedure if Ue not replies and eNB sends
NasNonDelivery to MME before setting subscriber state to Deregistered.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 229/231


D553209967 © Nokia 2016
Version 1.0
Confidential
5.10 On-going PDN Connectivity collide with incoming X2 HO

Problem report: CAS-13347-V6X6


Exists in: NS 16.5 MP0.1
Correction Target: NS 16.5 MP2, NS 17.5
Severity: B - Major
Customer Impact: Capacity & Performance

Reported date: 22.02.2017


Closed date: -

Solution / Workaround:

Summary of the original problem:


- In Customer network following scenario occurred. Ongoing PDN connectivity incoming X2HO collided.
Since EBI in PDN connectivity is present in Patch Switch Request message, MME resolved the collision
as COCI (Continue Ongoing and Continue incoming). MMDU will be waiting for the PDN connectivity
procedure to get completed, but CPPU started the X2HO procedure. MMDU will not respond for the
eps_path_switch_req_s message and hence the timer in CPPU will get expired which will lead to the
Path switch failure with cause "Radio NW radio Network: ho-failure-in-target-EPC-Enb-or-target-system
(6)". The resolution should be to continue the X2Ho by keeping the ongoing PDN connectivity on hold.

Solution / Workaround
- There can be two solutions for this
1) MME can wait for the UE message as part of the PDN connectivity which will be on hold, as part of the
X2HO, don't include the bearer of PDN connectivity in MBR. Include this bearer in Path switch Ack
message. As part of PDN connectivity resumption send the ERAB request message to eNB and then
continue the PDN connectivity message normally.
2) MME as part of PDN connectivity procedure no need to send MBR, mark the PDN connectivity as
success, complete the PDN connectivity procedure. As part of X2HO we can continue the MBR with the
new bearers as well as the PDN connectivity bearer. This thing will be similar implementation as the
handling of CBR and X2HO collision as part of the feature FC085_004061-Collision handling between
VoLTE dedicated bearer setup and handover. This parameter will define if MME support linear collision
resolution between ongoing CBR and incoming HO.

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 230/231


D553209967 © Nokia 2016
Version 1.0
Confidential
6. RELEASE OBJECTS

NS 16.5 MP1 SW package: n6051800.zip


SW Build: N6 5.18-0
FlexiNS_SWUP_8.6.0_for_N6_5_18_0 v8.6.0
NS 16.5 MP1 Flexi NS Software Upgrade
with Special Conditions

Embedded SW:
NS_16.5_MP1_eSW.zip
NS_16.5_MP1_eSW_update_instructions.zip

7. PREVIOUS DELIVERIES FOR THE RELEASE

History information for the same release deliveries. In case of generic SW, this table does not
include customer specific deliveries.

02-Mar-2016 NS 16
07-Apr-2016 NS 16 MP0.1
05-Jul-2016 NS 16.5
01-Nov-2016 NS 16.5 MP0.1

8. APPENDICES / REFERENCES

None

NS 16.5 MP1 – Summary of Corrections and Enhancements - Page 231/231


D553209967 © Nokia 2016
Version 1.0
Confidential
List of Restrictions
Release Delivery: NS 16.5 MP1
Product Family: Mobile Packet Core
Product: Flexi NS
Release: NS 16 SW

Approval date: 17-Feb-2017

NS 16.5 MP1 – List of Restrictions - Page 1/7 © 2016 Nokia


D552759645
Version 1.0
Confidential
Table of Contents
1. Purpose ................................................................................................................................................... 4
2. NetAct Interface ...................................................................................................................................... 4
3. eSW Upgrade Capability......................................................................................................................... 4
4. HW Capability ......................................................................................................................................... 5
5. HW Diagnostic ........................................................................................................................................ 5
6. Common Restrictions .............................................................................................................................. 5
7. MME Restrictions .................................................................................................................................... 5
8. SGSN Restrictions .................................................................................................................................. 6
9. Removed Features/Functionality ............................................................................................................ 7

Contact:
Contact your local Nokia support

Summary of changes:

17-Feb-2017 1.0 Approved Version

NS 16.5 MP1 – List of Restrictions - Page 2/7 © 2016 Nokia


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

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

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

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

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

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

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

Copyright © 2016 Nokia. All rights reserved.

Important Notice on Product Safety

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

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

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

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

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

NS 16.5 MP1 – List of Restrictions - Page 3/7 © 2016 Nokia


D552759645
Version 1.0
Confidential
1. PURPOSE

The purpose of this document is to list restrictions on Flexi NS 16.5 MP1 SW Delivery.

2. NETACT INTERFACE

Flexi NS 16.5 MP1 full support comes with NetAct 16.5.

Restrictions between Flexi NS 16.5 and NetAct releases:

 Flexi NS 16.5 SGSN or MME or Triple Access is compatible with NetAct 15.5.
Support is on Flexi NS 15 feature/functionality level. For full new feature/functionality
support the NetAct release must be upgraded to NetAct 16.5
 Same applies for the NetAct 15.2, NetAct 15 (with Flexi NS 4.0) and NetAct 8 EP1
MP4 (with Flexi NS 3.0), where feature/functionality support is then on older Flexi
NS releases.
 NetAct Trace Viewer (NE3S) is not working with older releases than NetAct 15.5.

3. ESW UPGRADE CAPABILITY

The recommended root eSW level to perform eSW upgrade to NS 16.5 is the previous
official one (NS 16 main release or NS 15 main/maintenance release eSW version). There
is some further information like supported update paths in the corresponding eSW update
instruction documentation for NS 16.5.

ACPI4-A/B may need serial connections for checking the BIOS settings after the upgrade.

SCNAM-C STM-1 Frame Relay AMC eSW is not remote upgradable

ACAR1-B AMC carrier ATCA blade eSW is not remote upgradable.

It is highly recommended that all ACPI5A blades should be upgraded to IPMC eSW
version 2.2.3 (contained in NS 16.5 SW build). In the case that their IPMC version is
earlier than 2.2.2, the alarm 1334 will not be reported and a unit that is faulty (due to a HW
issue or local OS crash) will be detected by Recovery system of the OSP platform
passively. For this reason, the unit recovery may take some additional time to complete
certain diagnostic phase. However, the unit can be recovered anyway, if there is no HW
fault.

Note:
If an ACPI4-A/B blade has older eSW version than UCD 3.44 and is removed from the
chassis for more than 3 days and gets re-inserted, then it may only initialize half of logical
cores (even when HT is enabled). To recover from this faulty situation, the blade needs to
be deactivated / activated from shelf manager or go to BIOS settings and save before exit
(no need to perform any changes). Rebooting the blade is not enough. This fault is not
present in UCD 3.44.

NS 16.5 MP1 – List of Restrictions - Page 4/7 © 2016 Nokia


D552759645
Version 1.0
Confidential
4. HW CAPABILITY

With the Flexi NS 16.5 release the MMDU Functional Unit (FU) of the Flexi NS-HW-1.0
hardware of the ACPI4-A type require to have 3 x 8 Gbyte, hence a total of 24 Gbyte of
memory. This then allows better logging capability.

5. HW DIAGNOSTIC

Certain NE Topology related to 3-shelf deployment does not allow HUB diagnosis to
complete.

6. COMMON RESTRICTIONS

IPSec support for the Lawful Interception interfaces


 Due to possible NE capacity impact, currently IPSec cannot be used with the SGSN
nor MME LI interfaces.

7. MME RESTRICTIONS

Network Identity and Time Zone


 Time zone delivered to the SGW and back to MSS direction is not synchronized with
the time zone MME receives over SGs (if the NITZ via SGs feature is used). The
system time zone configured to MME is still delivered to SGW/MSS.

SGs redundancy
 Only restriction is that VLR should support VLR backup feature (Nokia proprietary
solution) or similar failure backup solution in MSC/VLR pool. It means that during MT
call/MT SMS, Paging Request can come from another MSC/VLR in case current
VLR failed, which has SGs association for the UE.

Public Warning System


 Only one CBC supported per MME, with one SCTP association only
 Only IPv4 supported on SBc.

MME Offloading
 NS16 implements both passive (NS2.1 level functionality) and active offloading
(NS2.2 level functionality). Selection between use of active and passive offloading
can be controlled via INI file and MML command ZWVF:MMERC=0:;
 In case of TAU/Active Flag=off to not to release S1 connection, the passive
offloading is not exactly same as in NS2.1 where UE context release with “load
balancing TAU required” can be used.

eNB Overload Control


 Not available for commercial use.

Statistics
 There is a limitation in the number of Tracking Areas and eNBs supported by MME
when M50, M51 and M66 measurement collection is active. Above 650 TAs and
14000 eNBs the loss of measurement data and the occurrence of 3003
INCORRECT MEASUREMENT DATA alarm may be observed.

NS 16.5 MP1 – List of Restrictions - Page 5/7 © 2016 Nokia


D552759645
Version 1.0
Confidential
eMBMS
 eMBMS Session Update is not supported.

Directly connected Home eNB


 Global eNB ID of Directly connected Home eNB, should be limited to 3LSB. There
should not be any directly connected Home eNB with same Global eNB ID as any
Macro eNB.
Note: This restriction is not applicable for the HeNBs connecting to the MME through
HeNBGW.

Loadbalancing enabled for the S5 interface towards the P-GW


 Without S5 load balancing, i.e. in single addressing mode the feature works e2e as
expected. With S5 load balancing, if all the GW nodes fail or are restarted then the
S5 LB address is unreachable also. In this case the MME blacklists the GW
addresses but not the S5 LB address, so the MME still can send the session
creation requests to the S5 LB address until the “remote peer not responding”
message received from SGW.

MSC/VLR interface
 The VLR ID = 0 cannot be used.

8. SGSN RESTRICTIONS

S4 SGSN IP addressing restriction


 The 2G S4 interface user plane and control plane share the same IP address.
Hence it's not possible to have different. VRF for them so that S4-C and S11 can
have same loopback IP address and S4-U and S1-U can have same loopback IP
address.

Limitation in usage of SMMUs


 It is not possible to configure more than 7 SMMUs (6 active + 1 spare)

SiMo is not fully usable in NS16


 Communication between Signaling Monitor (Si Mo) and PC is not working, and it is
not possible to get traces for Gr interface.

In S4-SGSN a non-EPC UE (roamer) cannot get GPRS subscription from HSS


 GPRS Subscription is not supported by SGSN over Diameter and HSS.
SGSN solution requires that this information is returned only by HLR.
Similarly, EPS Subscription shall be provided only by HSS.

Manual restart of spare MCHU with high number of I-HSPA base stations must be avoided
during high traffic
 NS16 supports up to 12 000 I-HSPA base stations. A manual restart of spare MCHU
during high traffic may lead to overloading of internal message bus and abnormal
functionality of the spare MCHU (auto restarts). The situation recovers when traffic is
lower or when the system is restarted. The problem does not affect working MCHU
operation.

Manual MCHU restart is normally performed during maintenance operations when


traffic is low.

NS 16.5 MP1 – List of Restrictions - Page 6/7 © 2016 Nokia


D552759645
Version 1.0
Confidential
2G GEA1 and GEA2 cyphering
 The new NS-HW-16 hardware with ACPI5-A CPU blades support only GEA3 for 2G
encryption. GEA1 and GEA2 are not supported. In case the UE does not support
GEA3, it is set to non-encrypted mode
 GEA1 and GEA2 is still supported on NS-HW-1.0/2.0/3.0/15 based on ACPI4-A/B
GBU.

Frame Relay issues


 Due to FRIU CPU Overload, caused by SDH FRIU Interrupts and Alarms, NSCV
links stability problems have been noticed in Flexi NS SGSNs running on NS3.0
release in certain environments. One possible reason for SDH Interrupts/Alarms is
related with broken fiber between SDH network and SGSN/GBU HW unit. Although
no problem reports have been filed of similar problems in releases NS4.0 and NS15,
the same issue may be present also in later releases including NS16.5.

Restriction to use S13’ IMEI checking –feature


 In Gn/S4-SGSN when IMEI check is active, the feature “S13prime IMEI checking”,
license 5348, is active and the S13’ i/f is configured, the following error cases are
observed:
o During Inter SGSN RAU completion, “Cancel location” is sent by HLR. As soon
as message is received by source SGSN, the source SGSN wrongly sends
“Identity Request” message to source RNC even the subscriber is already moved
to the target SGSN/RNC. Furthermore, the cause, in the generated CDR by
source SGSN, is “Abnormal deactivation” instead of “RAU”. RAU is completed
successfully.
o Due to S13prime IMEI Checking feature, IMEI Check procedure is activated and
supervisor timer is started. In the meanwhile, when a RAU or Attach process
from new LAC/RAC area is in progress and database has been updated with the
current LAC/RAC values, the supervisor timer expires and overwrites the
database entry with outdated values. Paging is not possible due to the wrong
LAC/RAC values.

 Workaround:
The feature “S13prime IMEI checking”, license 5348, should be de-activated in
Gn/S4-SGSN. In case of Gn-SGSN, this feature is needless as it is relevant only for
R8 architecture.

9. REMOVED FEATURES/FUNCTIONALITY

No features have been removed in the Flexi NS 16.5 MP1 release.

NS 16.5 MP1 – List of Restrictions - Page 7/7 © 2016 Nokia


D552759645
Version 1.0
Confidential
Change Note Forms
Id: NS 16.5 MP1
Product Family: Mobile Packet Core
Product: Flexi NS
Release: NS 16 SW

Approval date: 01-Mar-2017

Summary of changes:

01-Mar-2017 1.0 Approval date

NS 16.5 MP1 – Change Notes Form - Page 1/2 © Nokia 2016


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

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

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

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

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

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

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

Copyright © 2016 Nokia. All rights reserved.

Important Notice on Product Safety


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

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

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

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

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

NS 16.5 MP1 – Change Notes Form - Page 2/2 © Nokia 2016


D552953480
Version 1.0
Confidential
Mobile Packet Core

CN-id: NS16.50481

Title:
Incorrect NAS Sequence number

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- During SRVCC handover cancel procedure, the MME did not update the Downlink NAS
count and as result sent wrong NAS sequence number to UE. This caused UE inactivity.

How end user/operator could detect the problem:


- By performing the following procedure:
1.Attach
2.PDN connectivity
3.Dedicated bearer activation
4.SRVCC handover cancellation
5.PDN connection activation or dedicated bearer modification

Description of the fault:


- During SRVCC handover cancel procedure, the MME did not update the Downlink NAS
count and as result sent wrong NAS sequence number to UE. This caused UE inactivity.

Related feature / functionality:


- SRVCC handover cancellation

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- The Downlink NAS count will be increased correctly during SRVCC handover cancel
procedure. In detail, the sequence number in following downlinkNASTransport message after

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
id-downlinkNASTransport, Notification should be greater than the id-downlinkNASTransport,
Notification and consecutive.

Risk analysis of the correction:


- None

Effects on end-user:
- Defective end-user experience. Procedure after SRVCC handover cancel procedure was
affected.

Effects on operator:
- Next two NAS messages were going with wrong NAS count before NAS count recovery. This
makes procedure to wait for two NAS timer expiration (i.e. two extra retry). Hence chances of
collision / retransmission also increase.

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 11.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Corrected Fault Reports:


NA05916537
Incorrect NAS Sequence number

Modified components:

Component Version
LNX934G2.IMG 11.11-0

Change effects:

Customer Impact
Mobility scenarios
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
1.Attach
2.PDN connectivity
3.Dedicated bearer activation
4.SRVCC handover cancellation
5.PDN connection activation or dedicated bearer modification

Expected results:
Next two downlink NAS messages’ sequence number is correct
(e.g.
id-downlinkNASTransport, Notification
NAS.seq = 244
id-downlinkNASTransport, Modify EPS bearer context request
NAS.seq = 245
id-downlinkNASTransport, Modify EPS bearer context request
NAS.seq = 246
)

Unexpected results:
Next two downlink NAS messages’ sequence number is incorrect
(e.g.
id-downlinkNASTransport, Notification
NAS.seq = 244
id-downlinkNASTransport, Modify EPS bearer context request
NAS.seq = 243
id-downlinkNASTransport, Modify EPS bearer context request
NAS.seq = 244
)

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50490

Title:
Incorrect destination port in PGW restart notification acknowledgement from MME to SGW for
EPC node restoration feature.

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- During PGW restoration procedure, SGW sent PGW restart notification message to MME
with UDP src port different than the default (2123) and MME faulty sent PGW restart
notification Ack to the default port. As result, Ack message never reached SGW. So SGW
continues to send retransmissions of PGW restart notification message. MME concluded
normally PGW restoration procedure but it didn't send correct ack message.

How end user/operator could detect the problem:


- End user did not detect any problem but operator saw decreased KPIs due to the
retransmissions.

Description of the fault:


- MME did not sent the ack message with the updated src port which has been sent in the
PGW restart notification message.

Related feature / functionality:


- FC0085_003290 EPC NODE RESTORATION

Dependency on configuration:
- If operator has configured the default source port in SGW the problem couldn't be detected.

Workaround:
- Operator can configure the default src port in SGW (2123) and the problem will be overcome.

Description of the correction:


- In the PGW restart notification Ack message MME will update the SGW port based on the src
port of PGW restart notification message.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Effects on end-user:
- None

Effects on operator:
- KPIs for restoration procedure were decreased in cases that PGW would configure src UDP
port other than the default.

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX924G2.IMG 8.60-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Corrected Fault Reports:


NA05916632
Incorrect destination port in PGW restart notification acknowledgement from MME to SGW for
EPC node restoration feature.

Modified components:

Component Version
LNX924G2.IMG 11.6-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Operator needs to set UDP src port of PGW different than the default (2123).

Test execution:
Perform a restart in one of the PGWs where MME has been connected. After that SGW sent
PGW restart notification to MME and MME will respond with PGW restart notification ack.

Expected results:
MME will send the ack to the configured new PGW's source port.

Unexpected results:
MME will send the ack message to PGW to source 2123 even though operator has configured
as source port of PGW other than 2123.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50508

Title:
Emergency call is dropped in case of E-UTRAN Restricted Access Type in IDR

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Emergency call is dropped in case of E-UTRAN Restricted Access Type and the value is E-
UTRAN not allowed in Insert Data Request message.

Description of the problem


- Emergency call is dropped in case of E-UTRAN Restricted Access Type and the value is E-
UTRAN not allowed in Insert Data Request message.

How end user/operator could detect the problem:


- UE created emergency call and HSS sends E-UTRAN Restricted Access Type and the value
was E-UTRAN not allowed in Insert Data Request message, then emergency call dropped.

Description of the fault:


- Emergency call dropped in case of E-UTRAN Restricted Access Type in Insert Data Request
message.

Dependency on configuration:
- Configure the Emergency parameter.

Faulty component and version:


- LNX934G2.IMG 7.270-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP4

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- When UE creates multiple pdn (one of is emergency pdn), MME will keep the emergency
PDN and drop the other PDN.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


PR154615
NS15 MP3 Manual Regression - Emergency call is dropped in case of E-UTRAN Restricted
Access Type in IDR.

Modified components:

Component Version
LNX934G2.IMG 11.13-9

Change effects:

Customer Impact
Signaling & Plane Quality

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
UE creates one emergency pdn.

Test execution:
Test Scenario A: No collision.
1: UE create one common PDN in attach procedure.
2: UE send PDN Connectivity Request message to MME to create emergency PDN.
3: HSS sends Insert Subscriber Data Request message with eutranNotAllowed to MME.

Test Scenario B: Collision between emergency attach and IDR message.


1: UE create emergency pdn.
2: UE doesn't complete emergency attach, HSS sends Insert Subscriber Data Request
message with eutranNotAllowed to MME.

Expected results:
Test Scenario A:
1: MME can drop the common PDN and keep the emergency PDN.

Test Scenario B:
1: MME continue to emergency attach and drop the IDR message.

Unexpected results:
Test Scenario A:
1: MME don't keep the emergency pdn, and MME will trigger HSS detach.

Test Scenario B:
1: MME don't keep the emergency attach.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50544

Title:
ZKAI doesn't show any application IP for IPPU-17

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- ZKAI doesn't show any application IP for IPPU-17.

How end user/operator could detect the problem:


- By typing ZKAI command. The printout does not show anything related to IPPU-17.

Description of the fault:


- IPPU-17 receives Logical Address: 0x42DF at customer's SGSN. Through code review, it is
observed that the IPPUs' Logical Address ranges among limits 0x41D6 - 0x41F5. Based on
Platform experts, IPPUs' Logical Address is not sequential and valid ranges are among limits:
0x41D6 - 0x41E6 and 0x42DF - 0x42ED. Subsequently, it seems that IPPU-17 Logical
Address: 0x42DF is out of the accepted range.

Dependency on configuration:
- None

Faulty component and version:


- CGHHANJX.PAC 13.8-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- The ranges of IPPUs' Logical Address are updated to the following valid (not sequential)
limits: 0x41D6 - 0x41E6 and 0x42DF - 0x42ED. These new ranges are checked when ZKAI
command is typed. As result, ZKAI command for the IPPUs that are in the second range (such
as IPPU-17), is printed correctly.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- ZKAI MML command will work as intended.

Test requirements:
- Test the ZKAI MML

Corrected Fault Reports:


NA05931813
ZKAI doesn't show any application IP for IPPU-17.

Modified components:

Component Version
CGHHANJX.PAC 16.1-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Run ZKAI MML command for IPPU-17.
Run ZKAI MML command for All Units.

Expected results:
Printout of ZKAI MML for IPPU-17 show application IPs for this IPPU.
Printout of ZKAI MML for All Units includes IPPU-17.

Unexpected results:
Printout of ZKAI MML for IPPU-17 doesn't show any application IP for this IPPU.
Printout of ZKAI MML for All Units doesn't include IPPU-17.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50545

Title:
Console History showed by raw command was empty on ACPI4-B

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Console History showed by raw command was empty on ACPI4-B.

How end user/operator could detect the problem:


- By using raw command: ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00 to check the output of
CONSOLE HISTORY.

Description of the fault:


- The Console History showed by raw command was empty on ACPI4-B:
root@ACPI4-A_02_02_02_BI0:/root ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00
***************************
** CONSOLE HISTORY **

************END************

Description of the correction:


- Console History showed by raw command is fixed in order not to be empty on ACPI4-B.
HW UNIT: ACPI4-B
Firmware application: HPM
Firmware version: 2.62.0
Corresponding AEM Delivery module: AEM00019
Corresponding AEM Delivery module version: 1.27-0

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Dependency on configuration:
- None

Faulty component and version:


- AEM00019.IMG 1.26-0 and before (version too legacy to be specified).

Faulty component first delivered in(e.g. release, CD):


- NS40

Risk analysis of the correction:


- None

Correction effects:
- None

Customer effects:
- None

Corrected Fault Reports:


PR072068
#22622 / ACPI4-A Console History showed by raw command is empty on ACPI4-A/B

Modified components:

Component Version
AEMCONF1.XML 4.16-0
AEM00019.IMG 1.27-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Use raw command: ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00 .

Expected results:
Correct output of CONSOLE HISTORY.

Unexpected results:
The output of CONSOLE HISTORY is empty.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50546

Title:
Console History showed by raw command was empty on ACPI4-A

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Console History showed by raw command was empty on ACPI4-A.

How end user/operator could detect the problem:


- By using raw command: ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00 to check the output of
CONSOLE HISTORY.

Description of the fault:


- The Console History showed by raw command was empty on ACPI4-A:
root@ACPI4-A_02_02_02_BI0:/root ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00
***************************
** CONSOLE HISTORY **

************END************

Description of the correction:


- Console History showed by raw command is fixed in order not to be empty on ACPI4-A.
HW UNIT: ACPI4-A
Firmware application: HPM
Firmware version: 2.62.0
Corresponding AEM Delivery module: AEM00018
Corresponding AEM Delivery module version: 1.32-0

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
HW UNIT: ACPI4-A
Firmware application: EEPROM
Firmware version: 3.48.1
Corresponding AEM Delivery module: AEM00064
Corresponding AEM Delivery module version: 1.6-0

Dependency on configuration:
- None

Faulty component and version:


- AEM00018.IMG 1.31-0 and before (version too legacy to be specified).
- AEM00064.IMG 1.5-0 and before (version too legacy to be specified).

Faulty component first delivered in(e.g. release, CD):


- NS40

Risk analysis of the correction:


- None

Correction effects:
- None

Customer effects:
- None

Corrected Fault Reports:


PR072068
#22622 / ACPI4-A Console History showed by raw command is empty on ACPI4-A/B

Modified components:

Component Version
AEMCONF1.XML 4.16-0
AEM00018.IMG 1.32-0
AEM00064.IMG 1.6-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Use raw command: ipmitool raw 0x3a 0x14 0x2a 0x6f 0x00.

Expected results:
Correct output of CONSOLE HISTORY.

Unexpected results:
The output of CONSOLE HISTORY is empty.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50552

Title:
MME did not send Update Bearer Response during GW initiated QOS modification for an
unreachable subscriber

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- GW requested with Update Bearer Request message a bearer modification while UE was
Unreachable and MME did not send an Update Bearer Response.

How end user/operator could detect the problem:


- MME did not respond to GW in the Update Bearer Request in case that UE is Unreachable.

Description of the fault:


- The UE was unreachable and GW sent Update Bearer Request for bearer modification but in
that case MME did not send a response to the GW.

Related feature / functionality:


- QoS Update Procedure.

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Response to the Update Bearer Request message when the UE is Unreachable with cause
Unable to Page UE.

Risk analysis of the correction:


- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 11.13-30
- LNX924G2.IMG 11.5-27

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Corrected Fault Reports:


PR169125
For Unreachable Subscriber (PPF off) the QosUpdateProcedure Hangs in TrHandler

Modified components:

Component Version
LNX934G2.IMG 11.82-0
LNX924G2.IMG 11.56-0

Change effects:

Customer Impact
Signalling Plane Quality

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
The UE must be Unreachable.

Test execution:
The GW must request Bearer Modification.

Expected results:
The MME will respond to the GW.

Unexpected results:
The MME will not respond to the GW.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50571

Title:
Collision handling between ongoing Insert Subscriber Data and incoming Delete Subscriber
Data was not done correctly

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- This issue happened due to wrong collision handling in MME. In detail, there was ongoing
Insert Subscriber Data Request and Incoming Delete Subscriber Data Request collision for
which the current resolution was to drop the incoming Delete Subscriber Data Request silently.

How end user/operator could detect the problem:


- By performing Attach / PDN Connectivity for a specific APN. The HSS sent Insert
Subscription Data by modifying Service selection for APN context ID 1 when UE was in IDLE.
This triggered NW initiated detach in MME. At the same time, the HSS sent Delete Subscriber
Data request by deleting PDN with APN context ID 2. The MME drops Delete Subscriber Data
request silently and thus the MME held the APN context with ID 2.

Description of the fault:


- UE had one default bearer active with APN context ID as 1. HSS sent Insert Subscriber Data
Request almost simultaneously with Delete Subscriber Data request to delete the APN
configuration PDN with APN context ID 2. Due to a collision, the MME dropped Delete
Subscriber Data request silently. Hence, APN configuration with APN context ID 2 was not
deleted. When the UE tried Attach or PDN Connectivity for APN presented in APN
configuration with context ID 2 then the procedure would succeed even though HSS had
deleted the subscription for that specific APN. As result Collision handling for ongoing Insert
Subscriber Data and Delete Subscriber Data was not done correctly.

Related feature / functionality:


- Collision handling.

Dependency on configuration:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(4)
Workaround:
- None

Description of the correction:


- Ongoing Insert Subscriber Data Request and Incoming Delete Subscriber Data Request
collision will be handled with collision resolution by continuing ongoing and the incoming
procedures (COCI). So, subscription data is updated properly in MME and then it is
acknowledged to HSS using Delete Subscriber Data Answer.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 8.65-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Corrected Fault Reports:


NA05933794
(MME NS16 MP0.1+ontop) MME didn't response DSR message lead to 4G APN replacement
with dummy APN failure.

Modified components:

Component Version
LNX934G2.IMG 11.85

Change effects:

Effects on end-user
None

Effects on Operator
None

Other effects
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(4)
New functionality
Ongoing Insert Subscriber Data Request and Incoming Delete Subscriber Data Request
collision will be handled with collision resolution by continuing ongoing and the incoming
procedures (COCI).

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(4)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
1. Attach should be performed. Make sure HSS sends 2 APN configurations (Each one with
different APNs) in ULA msg.
2. UE goes to IDLE mode.
3. HSS sends Insert Subscriber Data Request for modifying the service selection name
associate with context ID-1.
4. Immediately HSS sends Delete Subscriber Data Request to delete the context ID-2
information.
5. MME sends Insert Subscriber Data Answer.
6. Start Service request, but MME sends NW initiated detach with cause Implicitly detached.
7. Now starts GUTI attach with ESM information flag set and send the old APN in ESM
information response which is associated with context ID-2 during attach.

Expected results:
MME should Reject Attach with cause e_unknown_or_missing_apn (27).

Unexpected results:
MME will proceed with old APN and Attach will be accepted.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 4(4)
Mobile Packet Core

CN-id: NS16.50572

Title:
Cause code in the E-RAB Release Command is changed from "nas unspecified" to "normal
release"

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Cause code in the E-RAB Release Command was "nas unspecified" instead of "normal
release" when Dedicated Bearer Activation procedure was terminated due to collision with any
incoming procedure (e.g. MT CSFB).

How end user/operator could detect the problem:


- During collision of Dedicated Bearer Activation procedure with an incoming procedure (e.g.
MT CSFB), where the ongoing Dedicated Bearer Activation procedure is dropped, MME sends
E-RAB Release Command as part of the termination procedure. In the E-RAB Release
Command, during the Dedicated Bearer Activation procedure termination, cause code value
was set to "nas unspecified".

Description of the fault:


- Wrong cause code was filled in the E-RAB Release Command when Dedicated Bearer
Activation procedure was terminated due to collision with any incoming procedure (e.g. MT
CSFB).

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.0-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(4)
Description of the correction:
- Cause code is changed to "normal release" in E-RAB Release Command when Dedicated
Bearer Activation procedure gets terminated due to collision with any incoming procedure (e.g.
MT CSFB).

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- ENB VoLTE Call KPI will not be degraded due to "nas unspecified" cause in E-RAB Release
Command.

Test requirements:
1. Attach.
2. PDN connectivity.
3. Dedicated bearer activation procedure.
MME sends E-RAB Setup Request with "Activate dedicated EPS bearer context request" NAS
message. eNB responded with E-RAB Setup Response but response from UE is still awaited.
4. MT CSFB.
Note: Ongoing Dedicated bearer procedure collides with incoming MT CSFB (e.g. SGs
Paging) and terminates the ongoing Dedicated bearer activation procedure.
5. MME sends E-RAB Release command as part of dedicated bearer activation procedure
termination.
6. MT CSFB proceeds.

Corrected Fault Reports:


NA05947937
Changing cause code to unspecified to normal

Modified components:

Component Version
LNX924G2.IMG 11.72-0

Change effects:

Effects on end-user
None

Effects on Operator
ENB VoLTE Call KPI will not be degraded due to "nas unspecified" cause in E-RAB release
command.

Other effects
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(4)
New functionality
None

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(4)
Testing Instructions for the change

Pre-requirements:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 4(4)
Mobile Packet Core

CN-id: NS16.50573

Title:
ULI was sent without TAI and ECGI in MBR when HO Notify was not received

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- ULI (User Location Info) was sent without TAI and ECGI in MBR (modify bearer request)
when Handover Notify was not received during Inter MME Handover procedure.

How end user/operator could detect the problem:


- During inter MME handover, if ENB didn't send Handover Notify but send TAU request, the
ongoing handover collided with incoming TAU.

Description of the fault:


- Normally, MME gets the ECGI and the TAI value from the Handover Notify message,
however, there wasn’t Handover Notify message in collision procedure between HO and Inter
MME TAU procedure.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 5.17-0

Workaround:
- None

Description of the correction:


- MME gets the TAI and ECGI value from the TAU request message.

Risk analysis of the correction:


- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Analysis of the correction risk to the customer / end-user:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


PR153977
ULI is sent without TAI and ECGI in MBR when HO Notify is not received

Modified components:

Component Version
LNX924G2.IMG 11.24-0

Change effects:

Customer Impact
Mobility scenarios

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50574

Title:
When multiple Delete Subscriber Data Requests collided with Attach, E-RAB Release
Command with Ue AMBR=0 was sent to ENB

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- When Multiple Delete Subscriber Data Requests collided with Attach, E-RAB Release
Command with Ue AMBR=0 was sent to ENB.

How end user/operator could detect the problem:


- Increase in MME counter M51C017 (PDN MME INITIATED DEACTIVATION FAILED).

Description of the fault:


- Ongoing Attach collided with incoming Delete Subscriber Data Request(DSR) and MME put
DSR on hold till attach was completed. When the second DSR comes, a third procedure
collision was detected and MME queued up this 3rd procedure (DSR #2) as well, to be
executed after 2nd procedure (DSR #1) completed. At this stage, Attach was completed and
(DSR#1) procedure was started which triggered NW detach. If a fourth procedure (DSR #3)
came in, it was picked up by the on-hold 3rd procedure (DSR #2) and started execution by
sending E-RAB release with UeAMBR = 0 instead of starting a new DSR procedure. The issue
was seen when Attach-DSR-DSR collision happened and a third DSR came before the first
DSR was completed.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2 7.260-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(4)
Workaround:
- None

Description of the correction:


- Additional check is added in this scenario before sending E-RAB Release Command to ENB
by checking if Subscriber is registered. Also, validity check is added for On Hold procedures to
not consume incoming messages, instead start a new procedure for the incoming message.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- Reduced signalling on S1 interface.

Customer effects:
- None

Test requirements:
1. UE starts Attach procedure.
2. HSS sends DSR with "PDN subscription contexts withdrawal" for non-default APN with
which UE tried to attach.
3. Before completion of Attach procedure, HSS re-sends DSR.
4. Attach is completed, MME start processing 1st DSR message and triggers NW detach
towards UE.
5. HSS sends DSR again for the 3rd time.

Corrected Fault Reports:


NA05936752
Increase in M51C017 PDN Connectivity Failed in HIMME001 after NS16.5 upgrade

Modified components:

Component Version
LNX934G2.IMG 11.75-0

Change effects:

Effects on end-user
None

Effects on Operator
None

Other effects
Reduced S1 Signalling.

New functionality
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(4)
Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(4)
Testing Instructions for the change

Pre-requirements:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 4(4)
Mobile Packet Core

CN-id: NS16.50575

Title:
3G users faced navigation problems

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- 3G users faced navigation problems.

How end user/operator could detect the problem:


- Degradation in the formulas of PDP modification. MOD PDP was 99,93% success and after
this error appeared went to 93.60%.

Description of the fault:


- In Inter SGSN relocation scenarios, with QoS change initiated from GGSN, modification of
service was failing due to error cause mand_ie_inc_c. This IE is rnc_ip_address in
gtp_update_pdp_context_req_s message. During the modification of service, after the rab is
established with RNC, if RNC parameter RAB MODIFY SUPPORTED is set to OFF, SGSN
should send two rab assignment requests. The first one will have as rab task release_c to
release the rab and re-create it with the second rab assignment request that will have as rab
task setup_c. In NS15 SW release, only the first rab assignment request was sent and after
that message gtp_update_pdp_context_req_s was sent to GGSN with empty rnc_ip_address
as the rab has been released.

Dependency on configuration:
- RAB MODIFY SUPPORTED RNC parameter is set to OFF.

Faulty component and version:


- GMRPRBMX.PAC 27.155-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP2

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Workaround:
- A workaround could be to change RNC parameter RAB MODIFY SUPPORTED to ON, so
SGSN will send only one rab assignment request with rab task set to modify_c.

Description of the correction:


- Changes were done in the procedure where GMG receives the first rab assignment response
where rab has been successfully released. With the provided correction, a second rab
assignment request will be sent towards RNC with rab task setup_c.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05950892
Flexi NS 15 / Claim 3G users for navigation problems and errors in the computer logs / No
alarms provided

Modified components:

Component Version
GMG_G6JX. - 31.71-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Direct tunnel ON + rab modify supported OFF.

Test execution:
Test Scenario:
1. Incoming relocation with one rab with direct tunnel ON.
2. During relocation update pdp context is send from sgsn (DT flag ON).
3. GGSN sends update pdp context response with different qos.
4. RAU after relocation.
5. RAB release.

Expected results:
Sgsn sends update pdp context to ggsn with valid IP for GSN address.

Unexpected results:
After rab release sgsn sends update pdp context to ggsn with 0.0.0.0 for GSN address.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50576

Title:
Emergency Bearer not added in ICSR request in Gn Based TAU.

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Ue was sending Tau Request message with emergency bearer as active during Gn Based
InterSystem Tau, but it is not included in Initial Context Setup Request Message.

Description how problem can be detected


- The problem could be detected when ICSR was sent as part of Gn Based InterSystem Tau
and in ICSR did not contain emergency bearer. After InterSystem Tau end user, won't be able
to do emergency call.

Dependency on configuration: Yes


- Gn Interface Should be configured between MME and SGSN.

Faulty component and version:


- LNX934G2.IMG 11.67-0

Description of the fault:


- During Gn Based InterSystem Tau, if Ue sends Tau Request with Emergency Bearers as
active, then these bearers are not included in Initial Context Setup Request message.

Workaround:
- None

Description of the correction:


- During Gn Based InterSystem Tau, if Ue sends Tau Request with Emergency Bearers as
active, then these bearers are included in Initial Context Setup Request message.

Risk analysis of the correction:


- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Correction effects:
- None

Interface effects:
- None

Customer effects:
- Emergency Bearers will be established successfully as part of Gn Based InterSystem Tau if
they are requested by UE. Hence operator will be able provide emergency services to end
user.

Test requirements:
- Ue Performs Gn Based InterSystem Tau by sending Tau Request Message with at least one
emergency pdn as active. MME sends context Request to SGSN. Context Response
containing at least one emergency PDN from SGSN.

Corrected Fault Reports:


PR154033
Emergency Bearer not added in ICSR request in Gn Based TAU.

Modified components:

Component Version
LNX934G2.IMG 11.69-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Gn Interface Should be configured.

Test execution:
Ue Performs Gn Based InterSystem Tau by sending Tau Request Message with at least one
emergency pdn as active.
MME sends context Request to SGSN.
Context Response coming with at least one emergency PDN from SGSN.

Expected results:
Initial Context Setup Request sent as part of Inter System Tau will contain the Emergency
Bearer Id in E-RAB Setup IE.

Unexpected results:
Initial context setup Request will not contain Emergency Bearer Id in E-RAB Setup IE.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50577

Title:
E-RAB set up failure with cause [RadioNetwork-cause=multiple-E-RAB-ID-instances]

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- E-RAB set up failure was occurring with cause [RadioNetwork-cause=multiple-E-RAB-ID-
instances], after x2 handover collision with Delete Bearer Request.

How end user/operator could detect the problem:


- E-RAB set up failure with cause [RadioNetwork-cause=multiple-E-RAB-ID-instances].

Description of the fault:


- During x2 handover collision with Delete Bearer Request, MME did not send E-RAB Release
Command message to ENB to release the deactivated bearer and when MME requested a
new bearer with same E-RAB ID to ENB, ENB rejected with cause multiple-E-RAB-ID-
instances.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 11.5-0
- LNX934G2.IMG 11.13-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- MME sends E-RAB Release Command message to ENB to delete the bearer during x2
handover collision with Delete Bearer Request.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05939708
eRAB addition QCI1 SR degraded TT 11904843 - Multiple eRAB instances

Modified components:

Component Version
LNX924G2.IMG 11.61
LNX934G2.IMG 11.88

Change effects:

Customer Impact
Stability

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50578

Title:
EPC initiated EPS Bearer Release requests for QCI1 & Volte drop call increased

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Collision between Service Request and S1 Release when SGW has triggered bearer release.

How end user/operator could detect the problem:


- Many Service Request and S1 Releases for a specified UE in this scenario would be
observed, while it would not be able to connect.

Description of the fault:


- During a UE triggered Service Request scenario, MME had already sent Modify Bearer
Request to SGW for the active bearers. Then, SGW replied with failure cause "Context Not
Found" for one of the active bearers. MME sent ERAB Release Command to the UE which
replied with ERAB Release Response. UE did not send DeactivateEpsBearerContextAccept
and for MME was still considered to be as active. Finally, UE triggered S1 Release while
Service Request procedure was still ongoing. MME resolved the collision terminating Service
Request procedure. However, during Service Request some bearers were marked from SGW
as pending to be released but were eventually never removed from the Database. The
resolution of collision was to terminate Service Request and continue S1 release without
removing the bearer.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.13-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Workaround:
- None

Description of the correction:


- The correction included enhancement of collision handling between Service Request and S1
Release when SGW has triggered bearer release so that the subscriber in database is being
updated and the proper bearers are released.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05957270
FNS: EPC initiated EPS Bearer Release requests for QCI1 & Volte drop call increasing

Modified components:

Component Version
LNX934G2.IMG 11.107-0

Change effects:

Customer Impact
Mobility scenarios

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
This correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
This correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50579

Title:
During HSS initiated detach the Mme_internal_cause was missing from Traffica MM reports

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- When Cancel Location Request was sent during the InterMME Tau and cancellation Type
was MMEUpdateProcedure then MME was not filling the internal cause in Traffica MM Report.

How end user/operator could detect the problem:


- Operator could detect the problem at Traffica report received for HSS initiated Detach
procedure.

Description of the fault:


- Internal cause that was sent to Traffica Report for HSS Initiated Detach procedure (Cancel
Location Request) was empty as result-code in case cancellation type was
MMEUpdateProcedure.

Dependency on configuration:
- Traffica is used as system reporting tool.

Faulty component and version:


- LNX924G2.IMG 11.92-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- Internal MME cause of procedure hssDetachProc is included to message sent to Traffica
Handler for creating the report.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- Traffica Report for HSS initiated detach.

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


PR173241
HSS_initiated_detach missing Mme_internal_cause

Modified components:

Component Version
LNX934G2.IMG 11.94-0

Change effects:

Effects on end-user
None

Effects on Operator
Traffica report for HSS initiated detach will contain the right mme cause.

Other effects
None

New functionality
None

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Include and configure Traffica to system setup.

Test execution:
Intersystem HO with Cancel Location Request so as HSS - Initiated detach to be triggered and
report to be sent to Traffica.

Expected results:
EMM report with MME internal cause "success" should be sent to Traffica.

Unexpected results:
EMM report with no MME internal cause sent to Traffica.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50580

Title:
MME was sending invalid ENB-S1AP-ID in PDN Disconnect reject message

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- MME was sending invalid eNBS1APID in PDN disconnect reject message.

How end user/operator could detect the problem:


- Invalid eNBS1APID will be sent in PDN disconnect reject message.

Description of the fault:


- In this case collision happened between PDN connectivity request and UE Context Release
Request. MME terminated the ongoing PDN creation and processed the eNB sent UE Context
Release Request. After this, UE sent PDN disconnect message and again collision happened
in MME between UE context release and PDN disconnect message. Once UE context release
procedure was completed, ECM state changed to IDLE and MME made the eNBS1AP as
FFFFF. So, while PDN disconnect request message was picked up, MME was sending eNB
s1ap id with value FFFFFF.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 1.450-0
- LNX934G2.IMG 1.450-0

Faulty component first delivered in(e.g. release, CD):


- NS22

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- When MME receives PDN disconnect request message and ECM state is idle, it will send
error indication message instead of sending PDN disconnect reject with wrong eNB S1ap id.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- With the fix, error indication will be sent whenever PDN disconnect message is
received by MME in ECM idle state.

Test requirements:
1. Attach.
2. PDN Connectivity Request.
3. UE Context Release Request.
NOTE: At this stage collision, will happen between PDN connectivity and S1 release
procedures. PDN connectivity procedure will be terminated, s1release procedure will be
continued and after this processing ECM state will move to IDLE.
4. PDN Disconnect Request.

Corrected Fault Reports:


NA05937549
Incorrect ENB ID(s1ap.MME_UE_S1AP_ID) sent by MME

Modified components:

Component Version
LNX934G2.IMG 11.84-0
LNX924G2.IMG 11.58-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50581

Title:
Wrong PGW selection by MME during PDN connectivity procedure

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- During standalone PDN connectivity procedure MME was selecting wrong PGW when UE
provided APN was not present in subscribed APN list and if 2250 PRFILE
(MME_OVRD_INV_APN_PDN_CO) is enabled.

How end user/operator could detect the problem:


- MME was sending create session request with wrong PGW IP as part of the standalone PDN
connectivity procedure.

Description of the fault:


- During Inter system TAU if SGSN sends Context Response with bearer id 6, MME stores the
APN in PDN id 2 as per implementation. After that when MME receives UE initiated
standalone PDN connectivity request with UE provided APN it allocates Bearer id 5/PDN1 and
stores the HSS provided APN in PDN id 1 as UE provided APN not found in subscription Data
received from HSS. During PDN connectivity request procedure, due to internal fault in
MMDU, MMDU was sending internal message to CPPU with same UE provided APN for both
the PDNs. Since same APN was received for both the PDN, hence based on the current
implementation, CPPU was not considering the IP which is fetched from DNS resolution.
Instead it was sending to the same IP in which previous create session request was sent for
bearer ID 6.

Dependency on configuration:
- Below feature parameters need to be enabled:
ZWOC:2,2250,0001;
ZWOC:2,2050,00FF;
ZWOC:2,2051,00FF;

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(4)
MME local default APN parameter:
ZMXN: ETPLMN, MAPN: OPT=1;

Faulty component and version:


- LNX934G2.IMG 7.10-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Corrected the fault in MMDU so that proper APN is sent in internal message for each of the
PDN connections if multiple PDN's exists.

Risk analysis of the correction:


- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- With the fix MME will send create session request with proper PGW IP as part of the
standalone PDN connectivity procedure.

Customer effects:
- With the fix MME will select proper PGW as part of the standalone PDN connectivity
procedure.

Test requirements:
- Below feature parameters need to be enabled:
ZWOC:2,2250,0001;
ZWOC:2,2050,00FF;
ZWOC:2,2051,00FF;

MME local default APN parameter:


ZMXN: ETPLMN, MAPN: OPT=1;

Scenario:
1. During Inter system TAU, SGSN sends Context Response to MME with bearer id 6.

2. Then UE sends standalone PDN connectivity request with UE provided APN which is not
present in subscription Data received from HSS.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(4)
Corrected Fault Reports:
NA05940713
PGW Selection in MME

Modified components:

Component Version
LNX934G2.IMG 11.93-0

Change effects:

Customer Impact
User Plane Quality

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(4)
Testing Instructions for the change

Pre-requirements:
Below feature parameters need to be enabled:
ZWOC:2,2250,0001;
ZWOC:2,2050,00FF;
ZWOC:2,2051,00FF;

MME local default APN parameter:


ZMXN: ETPLMN, MAPN: OPT=1;

Test execution:
1. During Inter system TAU, SGSN sends Context Response to MME with bearer id 6.

2. Then UE sends standalone PDN connectivity request with UE provided APN which is not
present in subscription Data received from HSS.

Expected results:
During PDN connectivity request procedure, MME should send create session request with
PGW IP which is fetched from DNS resolution.

Unexpected results:
During PDN connectivity request procedure, MME will send create session request with same
PGW IP in which previous create session request was sent for bearer ID 6.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 4(4)
Mobile Packet Core

CN-id: NS16.50582

Title:
GSP GRP3 hand hang up during periodic RAU

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- GSP GPR3 hand remain hanging for 5 minutes during periodic RAU.

How end user/operator could detect the problem:


- Via tracing internal and external log files.

Description of the fault:


- During a periodic RAU on 3G, after completion of this procedure, UE sends routing area
complete message to the already reserved GSP hand (responsible to serve RAU procedure).
Then the aforementioned GSP hand receives this message and since there is nothing else
to do in this phase of scenario, remains hanging for 5 minutes and then a supervision
message is triggered from GSP master to release this hand.

Dependency on configuration:
- None

Faulty component and version:


- GSP_G6JX.PAC 10.7-0

Faulty component first delivered in(e.g. release, CD):


- SG7

Workaround:
- None

Description of the correction:


- After routing area complete message comes from MS, iu release cmd timer is reset. This
timer is responsible to release GSP hand in cases where there are instructions for IU release
and follow on. Although in this scenario there are the aforementioned conditions, GSP hand

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
had not been released due to this timer reset when there is an unexpected RAU complete
message from MS. To this direction, this timer is set again and as result, GSP hand is
released as well as SCCP connection is released.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05960359
GSP hand hang up related to ticket NA05950892

PR181522
NS15MP3wu1: GSP GRP3 hand hang up during periodic RAU

Modified components:

Component Version
GSP_G6JX.PAC 30.23-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
3G Attach.
Periodic RAU is triggered with IU release and Follow ON set as TRUE.
After completion of RAU procedure, MS sends also RAU complete message to GSP hand.

Expected results:
After correction, GSP hand which receives RAU complete message from MS will be released
since there is nothing else to do.

Unexpected results:
After correction, GSP hand which receives RAU complete message from MS will not be
released since there is nothing else to do.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50583

Title:
VoLTE basic call stopped working

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- If customer used IMS APN 'ims.oi.com.br', the ims bearer couldn't be allocated.

How end user/operator could detect the problem:


- By using the APN name is configured as 'ims.oi.com.br'.

Description of the fault:


- Generally, MME only allow IMS OI configured as 'ims'. if customer configured APN-OI second
part less than 3 characters, such as 'ims.oi', the method substring (0,3) will throw an exception
which caused bearer activation failure.

Dependency on configuration:
- IMS APN-OI configured as ims.xx (less than 3 characters)

Faulty component and version:


- LNX922G2.IMG 7.1.8-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP2

Workaround:
- None

Description of the correction:


- If the second part of APN-OI is less than 3, the method returns false, and do not throw
exception.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05911702
VoLTE basic call stopped working after upgrading FNS from NS3.0 to NS15 MP2

Modified components:

Component Version
LNX922G2.IMG 11.11-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
IMS APN-OI was configured as ims.xx (the second part is less than 3 characters).

Test execution:
IMS bearer is allocated on the IMS APN. S-GW sends Create Bearer request to MME.

Expected results:
Bearer allocated successfully.

Unexpected results:
MME dropped the bearer activation silently.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50584

Title:
SHMU COMMUNICATION FAILURE alarms

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Alarm 3481 was raised for both Shelves.

How end user/operator could detect the problem:


- 3481 alarm was triggered several times.

Description of the fault:


- It was a known issue in Shelf Manager eSW 63998-06199. One logic IP address in the active
Shelf Manager couldn't open 623 port for RMCP, which is used to build IPMI session from
OMU to Shelf Manager.

Faulty component and version:


- AEM00006.PAC 1.33
- AEM00041.PAC 1.25-1

Faulty component first delivered in(e.g. release, CD):


- NS15

Description of the correction:


- Retry mechanism introduced in PPS Root File System.

Corrected Fault Reports:


PR178207
3481 SHMU COMMUNICATION FAILURE alarms

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Modified components:

Component Version
AEM00006.PAC 1.41-0
AEM00041.PAC 1.30-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
No special testing needed. User should check the active alarms using the MML command
ZAHO;

Expected results:
No alarm 3481.

Unexpected results:
Alarm 3481 is raised.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50585

Title:
Dedicated bearer activation failed after colliding with incoming X2 handover

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Dedicated bearer activation failed after colliding with incoming X2 handover.

How end user/operator could detect the problem:


- The target eNB added all those bearers (to be setup in ongoing Dedicated bearer activation)
into the Path Switch Request message and forward Activate Dedicated EPS Bearer Context
Accept (for Dedicated bearer activation) to MME during X2 handover.

Description of the fault:


- MME did not retry to active dedicated bearers after X2 handover is complete.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 8.102

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- MME ignores the Activate Dedicated EPS Bearer Context Accept arriving during X2
handover and retries to active dedicate bearers towards target eNB after X2 handover.

Risk analysis of the correction:


- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Correction effects:
- None

Interface effects:
- None

Customer effects:
- Dedicated bearer activation will be successful in this specific scenario.

Test requirements:
- None

Corrected Fault Reports:


NA05942939
(NS 16) Dedicated bearer activation failure due to collision between ongoing Bearer Activation
and incoming X2 Handover

Modified components:

Component Version
LNX924G2.IMG 11.66-0

Change effects:

Customer Impact
Stability

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50586

Title:
MME did not respond to first create bearer request from SGW when handover from WiFi to
LTE was performed

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- MME didn't respond to the first Create Bearer Request from SGW when handover from WiFi
to LTE happened.

How end user/operator could detect the problem:


- UE handover from Wifi to LTE, S-GW sent first Create Bearer Request to MME, but MME
didn't send message to eNB to continue the procedure.

Description of the fault:


- S-GW sent Create Bearer Request and Modify Bearer Response almost at the same time. If
MME handled Create Bearer Request firstly, since collision result is continue ongoing and drop
incoming, the Create Bearer Request message was dropped silently.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.95-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
-None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- Change the collision resolver between PDN connectivity and Bearer activation from continue
ongoing drop incoming to continue ongoing continue incoming. So, MME will finish PDN
connectivity procedure and then start to handle bearer activation. The incoming Create Bearer
Request will not be dropped.

Risk analysis of the correction:


- None

Corrected Fault Reports:


NA05947056
MME does not respond to first create bearer request from SGW when handover from WiFi to
LTE

Modified components:

Component Version
LNX934G2.IMG 11.97-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Successful PDN connectivity procedure is ongoing.
MME sends out Modify Bearer Request to S-GW.
S-GW sends Create Bearer Request to MME before sending Modify Bearer Response.

Expected results:
The bearer activation procedure will be start after PDN established, MME will send E-RAB
setup request to eNB to continue the bearer activation procedure.

Unexpected results:
The bearer activation procedure is dropped by MME. No E-RAB Setup request message will
be sent out.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50587

Title:
Some Logs were enabled in MMDU without checking the logging level

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- In MMDU, some logs were always enabled without checking the logging level.

How end user/operator could detect the problem:


- Operator could see in MMDU internal logs some logs printed always despite the enabled log
level. This could have also a potential increase in CPU utilization of MMDU.

Description of the fault:


- Some MMDU logs were printed always because there was not a log level check or there was
an erroneous log level check.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 11.7-0
- LNX922G2.IMG 11.4-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Checks are implemented in MMDU so that logs are printed properly depending on the log
level.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


PR146847
Logging in SS_LNXmmeSubsHandler without checking trace log enable

Modified components:

Component Version
LNX934G2.IMG 11.15-0
LNX922G2.IMG 11.6-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50588

Title:
MME not responding to some CMAS Write-Replace-Warning Requests

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- MME did not always respond to CBC (Cell Broadcasting Centre) messages.

How end user/operator could detect the problem:


- CBC was sending Write-Replace Warning Request to MME but MME was not always
sending a response back.

Description of the fault:


- SBcHandler did not apply the configuration parameters from INI file
(DW0-/ACTIVESWDIRECTORY/ASWDIR/FNSINI/LNX985NX.INI) for inbound / outbound
streams (MaxInboundStreams, OutboundStreams).
- Furthermore, SBcHandler replied using the Streamid received from the message from
CBC.But this Streamid was not valid to be used for the outbound message to CBC.
As result, SCTP_SENDMSG failed with "error 22 = Invalid Argument". Streamid that was used
was not valid.

Dependency on configuration:
- None

Faulty component and version:


- LNX985G2.IMG 9.3-0

Faulty component first delivered in(e.g. release, CD):


- NS30

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- SBcHandler will respond to CBC using Streamid 0.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Corrected Fault Reports:


NA05953177
MME not responding to some Write-Replace-Warning-Request sent by CMAS

Modified components:

Component Version
LNX985G2.IMG 9.4-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
CBC connection to MME.

Test execution:
INIT and INIT ACK exchanged between CBC and MME respectively.
Send a Write-Replace-Warning Request from CBC to MME with Stream ID not equal to 0.

Expected results:
MME, in INIT ACK MME responds with the correct inbound / outbound streams as configured
in LNX985NX.INI file [DW0-/ACTIVESWDIRECTORY/ASWDIR/FNSINI/LNX985NX.INI:
MaxInboundStreams, OutboundStreams]. Default value is 4/4.
MME always responds to CBC with Stream ID = 0.

Unexpected results:
MME does not respond in INIT ACK with the correct configuration parameters for inbound /
outbound streams, as configured in the LNX985NX.INI file.
MME respond to CBC with Stream ID not equal to 0.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50589

Title:
Sv interface - MSC peer table timeout

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Description of the problem:
- Every time that a MSS was set to BL-US (blocked-BLU) mode, GTPLBS deleted it from its
internal table. However, when it was changed back to Normal (NOR) or Default (DEF),
GTPLBS was not adding it back to its table. This way MME was not able to monitor the
connection towards this MSS. Furthermore, this led to an empty MSS table when (at some
point) all MSS-es mode had been changed to BL-US. In addition, on restart or switchover
GTPLBS stored in its table both Blocked and Normal/Default MSS, while it was expected to
store only Normal or Default.

How end user/operator could detect the problem:


- If mode of MSS was changed to BL-US and back to NOR or DEF, ECHO requests stopped
being triggered towards this MSS. Also, if at some point all MSS-es asynchronously changed
mode to BL-US mode and then back to Normal or Default, MML interrogation for MSS
configuration status (ZBIR:INT;) caused a timeout issue.

Description of the fault:


- When a MSS changed mode from BL-US back to NOR or DEF, GTPLBS was not adding it
back to its table.

Dependency on configuration:
- The timeout issue/output was detected when PRFILE 2248 "MME_SV_BLACKLISTING" was
enabled, however faulty mechanism existed independently of the configuration.

Description if problem based on certain configuration:


- When PRFILE 2248 "MME_SV_BLACKLISTING" Sv blacklisting is enabled, GPU sends a
message to GTPLBS to provide the output of the MML command ZBIR (ZBIR:INT;).

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Workaround:
- IPDU switchover of the first IPDU pair (IPDU-0/1). This way GTPLBS calculates again its
internal table. Therefore, the table is not empty and contains the correct information.
- Instead of changing the MSS mode to BL-US, use MML to delete or add MSS in the Sv
interface functionality (ZBIR).

Faulty component and version:


- LNX968G2.IMG 8.28-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Description of the correction:


- When mode of MSS changes from BL-US to NOR or DEF it is added to MSS table.
When there is a restart or switchover in IPDU, blocked MSS is not added to MSS table.
This way GTPLBS will never be empty as there is always a default MSS. Also, MME will
monitor all MSS-es in non-blocked mode.

Risk analysis of the correction:


- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- Sv Blacklisting feature/PRFILE enabled.

Corrected Fault Reports:


NA05939697
SLMME001 - Sv interface - MSC peer table timeout

Modified components:

Component Version
LNX968G2.IMG 11.8-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Prfile 2248 "MME_SV_BLACKLISTING" enabled.
(Enable with MML command: ZWOC:2,2248, FF: ;)
At least two MSS configured on Sv interface.
(Check output with MML ZBIR:INT;)

Test execution:
MSS1 is in DEFAULT state (DEF) and MSS2 is in NORMAL state (NOR).
(Interrogate with MML ZBIR:INT;)
Modify MSS2 to blocked BL-US state (BLU) and then back to NORMAL (NOR).
(Use MML options under ZBIR: MODMSS and choose options depending on MSS)
Modify MSS2 to DEF state. Subsequently, MSS1 switches to NOR state.
Modify MSS1 to BLU state and then back to NOR.
Execute interrogation MML ZBIR:INT;

Expected results:
ECHO requests towards a MSS that is modified to BLU (BL-US) state are stopped and started
again when the MSS state turns back to NOR or DEF.
MML command ZBIR:INT; works properly and displays the interrogation result of all the
MSSes.

Unexpected results:
ECHO requests towards a MSS that had (even once) been set to BLU (BL-US) will never be
triggered again, unless a Unit restart happens.
MMLs ZBIR:INT; command will throw Timeout Error.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50590

Title:
NAS sequence number (NAS#35) issue after s1 release by inactivity timer

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- While paging procedure was ongoing, UE triggered S1 Release. The ERAB
ReleaseCommand message received by eNB included wrong Sequence Number.

How end user/operator could detect the problem:


- Operator would see two consecutive NAS/S1 messages having the same Sequence Number.

Description of the fault:


- During collision between Paging procedure and S1 Release procedure, TrHandler informed
SubsHandler about the current downlink and uplink NAS count, but SubsHandler did not
update the subscriber in database.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.238-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- Changes were implemented to update the subscriber with NAS count in case of collision
between Paging and S1 Release procedure.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Corrected Fault Reports:


NA05956786
NAS sequence number (NAS#35) issue after s1 release by inactivity timer

Modified components:

Component Version
LNX934G2.IMG 11.104-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
This correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
This correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50591

Title:
MML command error

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- When executing ZBAO: PURGE MML command, the output had a typo mistake:
PURGEING was printed instead of PURGING.

How end user/operator could detect the problem:


- By executing ZBAO: PURGE MML command, and then noticing that the output had a typo
mistake: PURGEING instead of PURGING.

Description of the fault:


- When executing ZBAO: PURGE MML command, the output had a typo mistake:
PURGEING was printed and not PURGING, which is the correct spelling.

Dependency on configuration:
- None

Faulty component and version:


- AUBHANJX.PAC 2.3-0

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None.

Description of the correction:


- Correct the typo.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


PR172065
NS17_NSHW16_8hrun_MML_command_error

Modified components:

Component Version
AUBHANJX.PAC 2.4-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Enable feature by executing the command ZWOC:2,2312,1.

Test execution:
Execute command ZBAO: PURGE;

Expected results:
The print-out should be:

PURGING UE BEHAVIOUR CONTEXTS, PLEASE WAIT ...

MMDU ACTION STATUS


======= ===============
MMDU-0 SUCCESSFUL
MMDU-1 SUCCESSFUL

COMMAND EXECUTED

Unexpected results:
The following print-out is observed:

PURGEING UE BEHAVIOUR CONTEXTS, PLEASE WAIT ...

MMDU ACTION STATUS


======= ===============
MMDU-0 SUCCESSFUL
MMDU-1 SUCCESSFUL

COMMAND EXECUTED

The typo still exists.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50592

Title:
MME was sending unauthenticatedIMSI flag as true in Indication Flags IE in Create Session
Request for subscriber attached with IMEI

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- For the subscriber that has done IMEI attach, MME was setting unauthenticatedIMSI flag as
true in Create Session Request when 2376(PROSE_AUTHORIZATION) PrFile was on.

How end user/operator could detect the problem:


- For the IMEI attached subscriber, operator would be able to see in pcap that MME sends
unauthenticatedIMSI flag as true in Indication Flags IE in Create Session Request when
2376(PROSE_AUTHORIZATION) PrFile is on.

Dependency on configuration:
- 2376(PROSE_AUTHORIZATION) PrFile should be enabled.

Faulty component and version:


- LNX934G2.IMG 11.67-0

Workaround:
- None

Description of the correction:


- When Subscriber Performs IMEI Attach and if 2376(PROSE_AUTHORIZATION) is on then
unauthenticatedimsi flag will be false in Indication Flags IE in Create Session Request
message.

Risk analysis of the correction:


- None

Correction effects:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Interface effects:
- None

Customer effects:
- None

Test requirements:
- Attach with IMEI.
- S1 Release.
- Tau with SGW Relocation.

Corrected Fault Reports:


PR156436
NS17-CI27: unauthenticatedIMSI indication flag is set to true in CSR with Prose PR file is on

Modified components:

Component Version
LNX934G2.IMG 11.69-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
PROSE_AUTHORIZATION PrFile (2376) should be enabled.

Test execution:
Attach with IMEI.
S1 Release.
Tau with SGW Relocation.

Expected results:
Unauthenticatedimsi flag in indication flags IE in Create Session Request will be false.

Unexpected results:
Unauthenticatedimsi flag in indication flags IE in Create Session Request will be true.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50593

Title:
MME did not trigger PDN re-establishment after inter MME TAU with SGW change

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- MME did not trigger PDN re-establishment after inter MME TAU with SGW change.

How end user/operator could detect the problem:


- During inter MME TAU with SGW change, the source MME sent Context Response message
with the SGW FQDN and PGW FQDN in upper case.

Description of the fault:


- The MME did not handle some special FQDNs in upper case correctly.

Dependency on configuration:
- FC085_003052 PDN re-establishment after SGW change feature must be enable.

Faulty component and version:


- LNX934G2.IMG 11.1-0
- LNXA9BG2.IMG 5.1-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- Make all FQDNs in Context Response message to be in lower case.

Description of the correction:


- Parse and treat FQDNs in Context Response message case-insensitive.

Risk analysis of the correction:


- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Correction effects:
- MME will handle upper case FQDNs in Context Response message correctly.

Corrected Fault Reports:


NA05938360
(Flexi NS) PDN re-establish failed

Modified components:

Component Version
LNX934G2.IMG 11.79-0
LNXA9BG2.IMG 5.8-0

Change effects:

Customer Impact
User Plane Quality
Signaling Plane Quality

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
1. FC085_003052 PDN re-establishment after SGW change feature is enable. Thus, voice
APN list and data APN list is configured via MML command 'ZE5C'.
2. The 'PDN CONNECTION PARAMETERS' in 'MM/SM CONFIGURATION HANDLING' (MML
command group 'ZBJ') should be configured as following:
PDN RECONNECTION INITIATION TIMER.................(TPDN) 2 s
LABEL INDEX FOR CANONICAL NODE NAME COMPARISON.... (LABEL) 4

Test execution:
Perform inter MME TAU with SGW change. The subscriber has the active PDNs whose APN is
in the voice APN list. The source MME sends Context Response message with the SGW
FQDN and PGW FQDN in upper case as following:

TOPON.SGW-
S11.JNSAEGW03BHW.JN.SD.NODE.EPC.MNC000.MCC460.3GPPNETWORK.ORG
TOPON.PGW-
S5.JNSAEGW03BHW.JN.SD.NODE.EPC.MNC000.MCC460.3GPPNETWORK.ORG

In DNS query result in target MME, the SGW FQDN and PGW FQDN of new selected SGW
and PGW should be:
topon.sgw-s5.jnsaegw30bnk.jn.sd.node.epc.mnc000.mcc460.3gppnetwork.org
topon.pgw-s5.jnsaegw30bnk.jn.sd.node.epc.mnc000.mcc460.3gppnetwork.org

Expected results:
MME will trigger PDN re-establishment after inter MME TAU with SGW change.

Unexpected results:
MME will not trigger PDN re-establishment after inter MME TAU with SGW change.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50594

Title:
LG K7 MPCS handset models were causing EPC initiated drop loops for IMS default bearer.

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- DB was not properly updated if UE did not respond to E-RAB Release Command.

How end user/operator could detect the problem:


- If UE did not respond to E-RAB Release Command and max retries reached, then operator
could observe the deactivated bearer with proper MML command as not deactivated.

Description of the fault:


- After max retries reached, trHandler did not send the proper message to subsHandler so DB
was not updated for the deactivated bearer.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG, 11.13-42

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Proper message is sent from trHandler to subsHandler with cause "UE not respond"
to update the DB with the correct status of bearer. Also, if timer expires in subsHandler due to
e.g. CPPU restart, the bearer status is updated on timer expiration.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- KPIs improvement

Test requirements:
- None

Corrected Fault Reports:


NA05955170
LG K7 MPCS handset models causing EPC initiated drop loops for IMS default bearer.

Modified components:

Component Version
LNX934G2.IMG 11.104-0
LNX924G2.IMG 11.78-0

Change effects:

Customer Impact
Operation & Maintenance
Signaling Plane Quality

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
This correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
This correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50595

Title:
3689 alarm was not cancelled in MMDU after recovery action

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


FLEXI NS

References:

Reason for the Change Note:


Summary of the original problem:
- Alarm 3689 was not reset although both DBHandler and the database had been restarted
successfully.

How end user/operator could detect the problem:


- Alarm 3689 was not cancelled after 1007 disturbance was raised for processes 93D and 930.

Description of the fault:


- On DBHandler initialization, the database was unresponsive. As result, 3689 alarm was
raised and after the 5 min timeout, both DBHandler and HAC were restarted as a recovery
action. After the restart, the initialization was successful, however the alarm was not cleared.
DBHandler keeps local variables for remembering that an alarm was raised. Since the process
was restarted, the variables were initialized to false, hence the check for resetting the alarm
was evaluated to false.

Dependency on configuration:
- None

Faulty component and version:


- LNX93DG2.IMG 11.3-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- In the DBHnadler initialization phase alarm 3689 is reset once the database is operational.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


PR171036
3689 alarm not cancelled if DBHandler restarts

Modified components:

Component Version
LNX93DG2.IMG 11.7-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
This procedure is not recommended to be performed on a production environment.
ZDDS: MMDU,0;
lnx-launcher -k lnx-solidDB-d
lnx-launcher -r lnx-mmeDBHandler-d
exit

Expected results:
Alarms 3698 and 3058 should be raised, check using:
ZAHO: MMDU,0;
After 5 mins, 1007 disturbance will be raised for DBHandler and HAC (93D, 930) after which
alarms 3698 and 3058 should be cancelled.

Unexpected results:
After the1007 disturbances for DBHandler and HAC (93D, 930) alarms 3698 and 3058 are still
ON.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50596

Title:
MME sends wrong APN selection mode value for Emergency PDN in CSR during Intra-mme
S1/X2 HO with SGW change

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- MME was not sending correct APN selection mode in Create Session Request.

Description of the problem:


- During Intra MME s1/x2 HO MME was sending wrong APN selection mode in Create Session
request.

Description of the fault:


- MME was filling hard coded value
MS_OR_NETWORK_PROVIDED_APN_AND_SUBSCRIBED_VERIFIED (0) in Create
Session request.

Dependency on configuration:
- None

Faulty component and version:


- LNX924G2.IMG 7.229-1 and LNX934G2.IMG 7.238-2

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- With the correction MME sends correct APN selection mode in Create Session Request.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Analysis of the correction risk to the customer / end-user:


- None

Correction effects:
- None

Interface effects:
- Correct Selection mode value is included in Create Session Request.

Customer effects:
- None

Test requirements:
- Attach with Emergency PDN.
- Perform Intra-mme S1/X2 HO with SGW change.
- MME send CreateSessionRequest with correct Selection Mode.

Corrected Fault Reports:


PR151039
Incorrect Selection Mode Value for Emergency PDN in CSR during Intramme S1/X2 HO with
SGW change

Modified components:

Component Version
LNX934G2.IMG 11.73-0
LNX924G2.IMG 11.53-0

Change effects:

Effects on end-user
None

Effects on Operator
None

Other effects
None

New functionality
Emergency Inter eNB Intra MME Handover with X2.
Emergency Inter eNB Intra MME Handover with S1.

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Attach with Emergency PDN.

Test execution:
Intra-mme S1/X2 HO with SGW change.

Expected results:
MME will send selection mode value as
NETWORK_PROVIDED_APN_AND_SUBSCRIPTION_NOT_VERIFIED (2) During create
Session Request to new SGW for emergency PDN.

Unexpected results:
MME will send selection mode value as
MS_OR_NETWORK_PROVIDED_APN_AND_SUBSCRIBED_VERIFIED (0) During create
Session Request to new SGW for emergency PDN.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50597

Title:
( Flexi NS-MME ) VoLTE video cross vendor switching failure

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- VoLTE video cross vendor switching failure due to create session reject by GW.

How end user/operator could detect the problem:


- UE performs a normal attach, then the PGW triggers a dedicated bearer activation (two
dedicated bearers with different PGW_TEID_U), then UE performs an inter-MME handover.
This fails because the create session is rejected in target side.

Description of the fault:


- MME stores the PGW_TEID_U as the same for all bearers even if the PGW_TEID_U is
different for each bearer in Create Bearer Request.

Dependency on configuration:
- None

Faulty component and version:


- LNX934G2.IMG 7.140.1.6-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Description of the correction:


- MME will store PGW_TEID_U for each bearer and the value should be taken from the Create
Bearer Request.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05918207
( Flexi NS-MME ) VoLTE video cross vendor switching failure

Modified components:

Component Version
LNX934G2.IMG 11.27-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
UE performs a normal attach, PGW initial dedicated bearer activation, to create two dedicated
bearers within one Create Bearer Request message. The PGW TEID for user plane is different
for each bearer.

Test execution:
UE performs an inter-MME handover.

Expected results:
Inter-MME handover successful.

Unexpected results:
Inter-MME handover failed.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50598

Title:
MME locate failure accidentally

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- In the process of UE Circuit-switched fallback(CSFB), the emergency Gateway Mobile
Location Center (EGMLC) sent a Provide-Location-Request (PLR) with location type
"CURRENT_OR_LAST_KNOWN_LOCATION (1)" to MME. The MME could not page the UE
successfully and replied with a Provide-Location-Answer (PLA) message with Result-Code
"success", however there was no location estimate data in PLA.

Description of the problem


- In the process of UE CSFB, EGMLC did sent a PLR with location type
"CURRENT_OR_LAST_KNOWN_LOCATION (1)" to MME, the MME could not page the UE
successfully and replied with PLA message with Result-Code "success", however there was
no location estimate data in PLA.

Description of the fault:


- MME responded with PLA message to GMLC with Result code 2001 to indicate success
directly.

Related feature / functionality:


- None

Dependency on configuration:
- sls, slg interface configured.

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- Configure message LOC_EST_TYPE_T_CURR_LST_KNWN as 1 via CLI. Then MME
responds PLA to GMLC with Experimental-Result code 4221 to indicate failure directly when
paging fails for PLR with location type CURRENT_OR_LAST_KNOWN_LOCATION (1).

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 8.71-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Corrected Fault Reports:


NA05927910
‘VoLTE 100day campaign’ (FLexi NS MME NS316) MME

Modified components:

Component Version
LNX934G2.IMG 11.58-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Set INI parameter value (LOC_EST_TYPE_T_CURR_LST_KNWN_CMCC) as 1.
For all LNX934G2.IMG (MMDUs).

Test execution:
In the process of UE CSFB, EGMLC send PLR with location type
CURRENT_OR_LAST_KNOWN_LOCATION (1) to MME, MME cannot page the UE
successfully.

Expected results:
PLA with Experimental-Result-Code: DIAMETER_ERROR_UNREACHABLE_USER (4221).

Unexpected results:
PLA with Result-Code is success. However, no location estimate data in PLA.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50599

Title:
Relocation failure due to additional RAB added

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- During inter-SGSN SRNS relocation (from DX-SG8 CD6.1 to FNS4.0 CD 2.0), the target
RNC cancels the relocation and replies with cause "unable to establish during relocation".

How end user/operator could detect the problem:


- Via tracing internal and external logs of the relocation scenario.

Description of the fault:


- On Inter-SGSN relocation procedure, GSP receives signal for relocation command from
GMG. After receiving this signal GSP prepares RANAP message "Relocation Command" to
send it to SORPRO. However, due to RANAP error, (which is printed in this scenario), there is
an indication that an encoding error is detected. As result SGSN does not send "Relocation
Command" to source RNC. The reason that Inter-SGSN Relocation procedure failed is due to
encoding error which is related to wrong construction on behalf of GSP of RAB list received
from GMG, to send it to SORPRO.

Dependency on configuration:
- None

Faulty component and version:


- GSP_G6JX.PAC 10.7-0

Faulty component first delivered in(e.g. release, CD):


- SG7

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- On GSP prb, on the encoding procedure of Rab list of relocation command message that is
sent to SORPRO, all available Rabs will be included.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05917971
Relocation failure due to additional RAB added

Modified components:

Component Version
GSP_G6JX.PAC 30.22-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Inter-SGSN relocation scenario with 2 RABs.

Expected results:
Relocation command RANAP message is successfully triggered from GSP to SORPRO.

Unexpected results:
Relocation command RANAP message is not triggered from GSP to SORPRO.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50600

Title:
KPI drop after both MMDUs of a pair were put to SE-NH state

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- One pair of MMDUs failed in a SA SGSN configuration and db_errors were reported in
SMMUs. The failing MMDUs were put to SE-NH state but the db_errors in SMMUs persisted.

How end user/operator could detect the problem:


- Notice 0004 ACCESS SERVICE REJECT RATE LIMIT EXCEEDED were raised for SMMUs,
as well as db_errors.

Description of the fault:


- GRN PRB that resides in SMMU uses an internal table for mapping subscriber IMSIs to
MMDUs serving them. SMMUs were informed when MMDUs went down, however when
request for a subscriber that was served by a faulty MMDU arrived in SMMU, it would look up
the subscriber in the aforementioned table and would return an MMDU in SE-NH state. Since
SMMU knew that MMDU is in SE-NH state, it tried to find the subscribers in the WO-EX
MMDUs but they were not available as they were not stored there. In addition, there was no
logic for redirecting the subscribers to the WO-EX MMDU pair and as result, the subscribers
served by the faulty MMDUs requests kept getting db_error responses.

Dependency on configuration:
- SA SGSN and TA MME.

Faulty component and version:


- GSL_GXNX.PAC 5.2-0

Faulty component first delivered in(e.g. release, CD):


- Legacy product, cannot be identified.

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- Once a request arrives in SMMU concerning a subscriber that was mapped to a faulty
MMDU, the stale entry is removed from SMMU's internal table. This way once the subscriber
re-attaches, she is forwarded to a WO-EX MMDU.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05906039
LASGSN14 - Database error in GSBASE

Modified components:

Component Version
GSL_GXNX. - 6.1-1

Change effects:

Customer Impact
Stability

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Standalone SGSN or Triple Access MME configuration.

Test execution:
This procedure is not recommended to be performed in live network.
Put both MMDUs of a pair to SE-NH state, e.g.:
1. ZUSC: MMDU,0:TE;
2. ZUSC: MMDU,0:SE;
3. ZUSC: MMDU,0:SE;
4. ZUSC: MMDU,1:TE;
5. ZUSC: MMDU,1:SE;
6. ZUSC: MMDU,1:SE;

Expected results:
Procedures other than attach might be rejected. The subscribers rejected should be able to re-
attach and be served.

Unexpected results:
Attach procedures are also rejected.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50601

Title:
Collision due to PDN Connectivity

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- During Inter-System TAU with 2 PDNs (ebi5 and ebi6) and qos throttling, collision happened
when PDN disconnection (ebi 6) was performed.

How end user/operator could detect the problem:


- By performing Inter System TAU and UE-initiated PDN disconnection.

Description of the fault:


- During Inter-System TAU with 2 PDNs (ebi5 and ebi6) and qos throttling, collision happened
when PDN disconnection (ebi 6) was performed as request message came before TAU
complete message. As result the MME dropped the incoming PDN disconnection procedure.

Related feature / functionality:


- Inter-system TAU and QoS throttling

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- The MME will first complete ongoing Inter-System TAU and then continue with incoming PDN
disconnection procedure and then with qos throttling if existed in previous Inter-System TAU.

Risk analysis of the correction:


- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Effects on end-user:
- None

Effects on operator:
- PDN disconnection KPI was dropped. Furthermore, the MME was initiating QoS throttling for
the PDN connection where the UE had already sent PDN disconnection. Hence, this
procedure hung as the UE did not response. This caused QoS modification KPI drop.

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 12.1-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Corrected Fault Reports:


NA05919202
Collision due to PDN Connectivity

Modified components:

Component Version
LNX934G2.IMG 11.32-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Test scenario 1:
1. Inter-system TAU with 2 PDNs (ebi5 and ebi6).
2. QoS for both PDNs should be changed.
3. UE-initiated pdn disconnection for one PDN (e.g. ebi 6) should be triggered.
4. Qos throttling for ebi5.

Test scenario 2:
1. Inter-system TAU with 2 PDNs (ebi5 and ebi6).
2. QoS for 1 PDN should be changed (e.g. ebi 6).
2. UE-initiated pdn disconnection for one PDN (e.g. ebi 6) should be triggered.
3. No Qos throttling will be triggered.

Expected results:
Test scenario 1:
Intersystem TAU then perform Pdn disconnection for ebi6 and then qos throttling for ebi 5.

Test scenario 2:
Intersystem TAU then perform Pdn disconnection for ebi6.

Unexpected results:
PDN disconnection procedure will not occur.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50602

Title:
( Flexi NS MME ) TAL (TaiList) and TAI (LastVisitedTAI) information is incorrect in LIC event
log

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- TAL (TaiList) information is incorrect in LIC event log.

How end user/operator could detect the problem:


- TAL field is omitted in China Li X2 active event report(Detach).

Description of the fault:


- After network initiated Detach, MME deleted subscriber data from database, hence TaiList
information is incorrect in China li detach event report.

Dependency on configuration:
- The feature China LI for MME (5347) is enabled.

Faulty component and version:


- LNX93FG2.IMG 7.2-0

Faulty component first delivered in(e.g. release, CD):


- NS15 MP1

Workaround:
- None

Description of the correction:


- Get TaiList from MM report if subscriber cannot be found in database.

Risk analysis of the correction:


- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Analysis of the correction risk to the customer / end-user:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- The feature China LI for MME (5347) is enabled.
- MME didn't configure TaiList

Corrected Fault Reports:


NA05918928
(Flexi NS MME) TAL (TaiList) and TAI (LastVisitedTAI) information is incorrect in LIC event log

Modified components:

Component Version
LNX93FG2.IMG 11.3-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
1.The feature China LI for MME (5347) is enabled.
2.MME didn't configure TaiList.

Test execution:
1. Perform combine Attach.
2. Perform NW Detach.

Expected results:
MME will send the China li Detach Event Report to LIC with TaiList.

Unexpected results:
MME will send the China li Detach Event Report to LIC without TaiList.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50603

Title:
Internal UDP packet towards CPPU sent from IPDU's external interface with Gn/S11/S10 IP

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- UDP packets are sent from IPDU's external IP of S11 interface, towards CPPU's internal IP.

How end user/operator could detect the problem:


- The issue could be detected by examining IPDU's pcap trace, and checking that UDP
packets sent from IPDU's external S11 interface to CPPU's internal interface. Also, there is an
ICMP packet for each aforementioned UDP packet coming from the router with error message
Destination network unreachable.

Description of the fault:


- In case of receiving Echo Request from SGWs, LNX968 in IPDU tried to send SGW's
blacklist status to CPPUs over UDP but used wrongly the external interface instead of the
internal one.

Dependency on configuration:
- None

Faulty component and version:


- LNX968G2.IMG 11.4

Faulty component first delivered in(e.g. release, CD):


- NS 16.5

Workaround:
- None

Description of the correction:


- Use the right IPDU's internal interface towards CPPU to send the UDP packet regarding
SGW blacklisting status.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05926379
Internal UDP packet sent on external interface with Gn/S11/S10 IP

Modified components:

Component Version
LNX968G2.IMG 11.6

Change effects:

Customer Impact
Stability

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
Capture network packets on IPDU.

Test execution:
Send an Echo Request from SGW to MME.

Expected results:
In the captured trace, there should NOT be any UDP packet send from IPDU's external IP
(S11 interface) towards CPPUs' internal IPs.

Unexpected results:
In the captured trace, there are UDP packets send from IPDU's external IP (S11 interface)
towards CPPUs' internal IPs.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50604

Title:
MME performs unnecessary IMEI check in IS TAU procedure during '4g Attach - IS RAU - IS
TAU'

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- During '4g Attach - IS RAU - IS TAU' scenario, MME performed again IMEI check in IS TAU
procedure even though it has been already performed during 4g Attach.

How end user/operator could detect the problem:


- Unnecessary IMEI checks in IS TAU in Wireshark log. Thus, unnecessary signalling
observed in IS RAU -IS TAU.

Description of the fault:


- The problem occurred with 2 different configurations:
1.Imei check completely OFF in SGSN.
In this case, during RAU, SGSN overwrote the IMEI value to FFFFFFF and thus MME found
that the IMEI has changed and performed IMEI check again in IS TAU.

2.Imei check ON in SGSN but not for RAU procedures.


In this case, MME set the imei_status of the subscriber as whitelisted in IS RAU and then
SGSN set it to not_done instead of whitelisted. For this reason, MME, initiated IMEI check
again in IS TAU.
Also, even if SGSN have send the correct imei and imei status, MME does not retrieve the
values stored in DB, so they IMEI and IMEI_STATUS contain the default values. MME have
never retrieved the values that SGSN stored previously.

Dependency on configuration:
- Imei check completely OFF in SGSN.
- Imei check was ON in SGSN but not for RAU procedures.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(4)
Faulty component and version:
- LNX934G2.IMG 11.62-0
- GRN_GSJX 20.21-0

Faulty component first delivered in(e.g. release, CD):


- NS 16

Workaround:
- None

Description of the correction:


- Correction given for both possible configurations in SGSN side:
1. GRN PRB overwrites the IMEI value in case the new received IMEI is not unknown.
2. When GRN PRB receives 'reg_check_imei_req_s' message, it sets the imei_status to
not_done in case the its previous value is unknown.
3. MMSM retrieves correctly the updated IMEI and IMEI_STATUS that got from SGSN.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- Customer will not see unnecessary IMEI CHECK during 4G Attach - IS RAU - IS TAU.
Also, traffic will be reduced as unnecessary imei check will not be performed.

Test requirements:
1.Imei check is completely OFF in SGSN
IMEI CHECK MODE...................................(ICHM) OFF
IMEI REQUEST MODE.................................(IRM) OFF
UE performs 4G Attach-IS RAU-IS TAU
Results: IMEI CHECK not occurred during IS TAU

2. Imei check is ON in SGSN but not for RAU procedures


UE performs 4G Attach-IS RAU-IS TAU
Results: IMEI CHECK not occurred during IS TAU

Corrected Fault Reports:


NA05929166
IMEI parameters in MME S13 Diameter

Modified components:

Component Version
GRN_GSJX.PAC 20.22-0
LNX934G2.IMG 11.63-0

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(4)
Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(4)
Testing Instructions for the change

Pre-requirements:
For the 1st issue must be:
IMEI CHECK MODE...................................(ICHM) OFF
IMEI REQUEST MODE.................................(IRM) OFF

And for the 2nd issue:


Imei check ON in SGSN but not for RAU procedures.

Test execution:
UE should make:
1. 4G Attach
2. IS RAU
3. IS TAU

Expected results:
Unnecessary IMEI CHECK will not happen during 4G Attach - IS RAU - IS TAU.

Unexpected results:
IMEI CHECK will happen in IS TAU although it has been made in Attach.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 4(4)
Mobile Packet Core

CN-id: NS16.50605

Title:
The M51 measurement includes the TAI-0 and TAI-65535 while the enodeb does not have
these TAI values

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- The M51 measurement includes the TAI-0 and TAI-65535. But the enodeb does not have this
kind of TAI.

How end user/operator could detect the problem:


- The M51 measurement includes the TAI-0 and TAI-65535.

Description of the fault:


- Tai List initialized with 0xFF, hence if procedure get Tai List failed, the initialized value was
recorded in measurement file.

Related feature / functionality:


- Measurement function

Dependency on configuration:
- None

Workaround:
- None

Description of the correction:


- Code is added to check for invalid TAC and exclude the TAC 0 and 0xFFFE when the
counter increased because the TAC-0000 and TAC-FFFE values are reserved for special
cases in MS.

Risk analysis of the correction:


- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Faulty component and version:


- LNX934G2.IMG 8.10-0, GST_GMJX.PAC too legacy to be specified

Faulty component first delivered in(e.g. release, CD):


- NS 16

Corrected Fault Reports:


NA05938817
The measurement includes the TAI-0 and TAI--65535 items even the enodeb do not have
these TAI

Modified components:

Component Version
GST_GMJX.PAC 28.21-0
LNX924G2.IMG 11.68

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
1. Configure the Session Management Measurement(M51) using MML command ZTPM.
2. Start the Session Management Measurement(M51) by using MML command ZTPS.
3. Subscriber performs attach procedure with TAC 0x0 and 0xFFFE.
4. Stop the Session Management Measurement(M51) by using MML command ZTPE.

Expected results:
TAC 0x0 and 0xFFFE not recorded in M51 measurement file.

Unexpected results:
TAC 0x0 and 0xFFFE recorded in M51 measurement file.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50606

Title:
Alarm 2101 MME UNIT FAILURE due to memory leak in S1Handler

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Memory leak in S1Handler.

How end user/operator could detect the problem:


- Alarms 2381 AMOUNT OF FREE MEMORY CRITICALLY REDUCED and 2101 MME UNIT
FAILURE were raised from CPPU. CPPUs were restarted after the free memory of unit was
exceeded.

Description of the fault:


- Flow Controller of S1Handler leaks messages in case of large gaps. Large messages gaps
are a result of high CPU usage on the unit in general.

Dependency on configuration:
- None

Faulty component and version:


- LNX936G2.IMG (version too old to be specified).

Faulty component first delivered in(e.g. release, CD):


- NS30

Workaround:
- None

Description of the correction:


- Improvement of S1Handler Flow Controller. Change the cyclic message buffer that leaks
messages in case of large gaps with a dynamic ordered set.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- Solution is based on the capacity figures of "Flexi NS System Capacity" chapter "3.1 MME
system capacity figures". Correction is working as expected.

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- High cpu usage of CPPU units (perhaps OLC scenarios etc.)

Corrected Fault Reports:


NA05944741
FNS01ALD: S1 handler memory leak caused OoM CPPU restart

Modified components:

Component Version
LNX936G2.IMG 11.8-0

Change effects:

Customer Impact
Stability

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Perform OLC test and monitor the memory utilization of S1Handler program on CPPU.

Expected results:
Memory usage of S1Handler is stable.
Memory usage of S1Handler has some spikes but then returns to minimal values.

Unexpected results:
Memory usage of S1Handler has some spikes but the memory is never returned to minimal
values.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50607

Title:
Roaming partner has ESM failures

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- When the VoLTE roaming feature (FC085_002933_Roaming Control for IMS APN and
VoLTE) is on, roaming subscribers on partner network, experience attach failure with Cause:
ESM failure (19) and PDN Connectivity reject with Cause: Missing or unknown APN.

How end user/operator could detect the problem:


- Attach procedure fails with ESM failure cause and PDN Connectivity procedure is rejected
with cause Missing or unknown APN.

Description of the fault:


- APN-Configuration AVP is not decoded correctly by MME.

Dependency on configuration:
- None

Faulty component and version:


- LNX938G2.IMG 12.3-0

Faulty component first delivered in(e.g. release, CD):


- NS30

Workaround:
- Unsupported AVPs after supported AVPs with multiple instances shall be avoided to be sent
from HSS.

Description of the correction:


- When multiple instances of the same AVP are present, retrieve the total length instead of the
length of the last instance.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Risk analysis of the correction:
- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05962653
Roaming partner has ESM failures

Modified components:

Component Version
LNX938G2.IMG 12.5-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
In Diameter ULA message sent from HSS during an Attach procedure, add the following AVPs
in the Subscription Data AVP: LCS-INFO containing multiple GMLC-Number AVPs and right
after MO-LR AVP.After MO-LR unsupported AVP, add APN-Configuration AVP.

Expected results:
Attach procedure containing ULR/ULA exchange is completed successfully.

Unexpected results:
Attach procedure is rejected because Diameter message is not decoded correctly.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50608

Title:
For Emergency PDN Connectivity Failures, the internal/external cause code sets are incorrect

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- The UE initiated PDN Connectivity procedure for Emergency Pdn was failing with erroneous
ESM cause in PdnConnectivityReject message.

How end user/operator could detect the problem:


- The UE initiated PdnConnectivityRequest message for Emergency PDN was rejected with
ESM cause = 34 (SERVICE OPTION TEMPORARILY OUT OF ORDER) instead of ESM
cause=32 (SERVICE OPTION NOT SUPPORTED).

Description of the fault:


- In case that the UE initiated Pdn Connectivity procedure (Emergency and non-Emergency
alike) is rejected because the MME gets a GTP cause equal to
REFERRED_PDN_TYPE_NOT_SUPPORTED in CreateSessionResponse message from the
GW, then the external/ESM cause included in PdnConnectivityReject message and the
respective internal cause, should be:
- for UE Requested PDN Type = IPv4: external/ESM cause=51 (PDN TYPE IPV6 ONLY
ALLOWED) & internal cause=126
- for UE Requested PDN Type = IPv6: external/ESM cause=50 (PDN TYPE IPV4 ONLY
ALLOWED) & internal cause=125
- for UE Requested PDN Type = IPv4v6: external/ESM cause=32 (
SERVICE OPTION NOT SUPPORTED) & internal cause=178
Instead of this, in case of Emergency Pdn Request for all IPv4/IPv6/IPv4v6 types, the following
causes were exposed: external/ESM cause=34 (SERVICE OPTION TEMPORARILY OUT OF
ORDER) & internal cause=128.
According to the 3GPP specification, if the UE gets ESM cause=34, then the UE may retry with
PdnConnectivityRequest with same APN & PDN type and in turn the Operator may also get a
KPI drop. While if the UE gets the ESM cause #50 or #51, it shall not automatically send
another PdnConnectivityRequest message (e.g. it may register to a new PLMN or the PDN
type which was used may change).

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(4)
Dependency on configuration:
- The error occurred only in case that the PDN type in the UE initiated
PdnConnectivityRequest message was not supported by the MME or by the GW.

Faulty component and version:


- LNX924G2.IMG 11.100-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Workaround:
- None

Description of the correction:


- In case of Emergency UE initiated PdnConnectivityRequest message that was rejected with
GTP cause 'PREFERRED_PDN_TYPE_NOT_SUPPORTED' by the GW the correct
internal/external causes were initially assigned (equal to the non-Emergency case) and those
were overwritten later during the execution. With the correction, the initial cause values are not
overwritten.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- The correct ESM cause is returned with PdnConnectivityReject.

Test requirements:
1.The UE is configured to send emergency Pdn requests with Pdn type e.g. IPv4v6.
2.The MME is configured to support only e.g. IPv4.
3.The GW is configured to support only e.g. IPv6.
4.The test scenario is:EPS Attach (non-emergency). The UE initiates a
PdnConnectivityRequest for Emergency Pdn. (The CreateSessionRequest message is send to
the GW with Pdn type = IPv4. The CreateSessionResponse is send to the MME with cause
PREFERRED_PDN_TYPE_NOT_SUPPORTED.)
5.Expected result:
PdnConnectivityReject towards the UE with ESM cause 32 (SERVICE OPTION NOT
SUPPORTED)
6.Non-expected result:
PdnConnectivityReject towards the UE with ESM cause 34 (SERVICE OPTION
TEMPORARILY OUT OF ORDER)

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(4)
Corrected Fault Reports:
NA05975155
cause code is inconsistent between in the CPPU and the corresponding traffica report.

NA05975937
For Emergency PDN Connectivity Failures, the internal/external cause code set are incorrect

Modified components:

Component Version
LNX924G2.IMG 11.5.1.39

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(4)
Testing Instructions for the change

Pre-requirements:
The UE is configured to send emergency Pdn requests with Pdn type e.g. IPv4v6.
The MME is configured to support only e.g. IPv4.
The GW is configured to support only e.g. IPv6.

Test execution:
EPS Attach (non-emergency)
The UE initiates a PdnConnectivityRequest for Emergency Pdn. (The CreateSessionRequest
message is send to the GW with Pdn type = IPv4. The CreateSessionResponse is send to the
MME with cause PREFERRED_PDN_TYPE_NOT_SUPPORTED.)

Expected results:
PdnConnectivityReject towards the UE with ESM cause 32 (SERVICE OPTION NOT
SUPPORTED).

Unexpected results:
PdnConnectivityReject towards the UE with ESM cause 34 (SERVICE OPTION
TEMPORARILY OUT OF ORDER).

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 4(4)
Mobile Packet Core

CN-id: NS16.50609

Title:
Dns Resolving Unsuccessful alarm (0095) flooding and map clearing

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- The same failed DNS query could raise the alarm again and again, flooding the alarm history.
After fix for NA05907970 in NS16_5 the alarm is raised once per CPPU and cannot be raised
again for the same fqdn and error code.

How end user/operator could detect the problem:


- The problem can be detected by not configuring the FQDN in the DNS server and if MME
does DNS query for the unconfigured FQDN, DNS RESOLVING UNSCCESSFUL alarm will be
raised as many number of DNS query attempts. The fault after fix for NA05907970 could not
be detected.

Description of the fault:


- The original problem was that DNS resolving unsuccessful alarm could be raised again and
again for the same pair of error code and fqdn. After correction of NA05907970 the DNS
resolving unsuccessful alarm (0095), once raised by a CPPU for a pair of fqdn and error code
it was permanently stored and the alarm could not be raised again for the same pair by the
same CPPU.

Dependency on configuration:
- Missing configuration from external DNS server.

Faulty component and version:


- LNX922G2.IMG 11.4-0
- LNXA9BG2.IMG 5.4-0

Faulty component first delivered in(e.g. release, CD):


- NS40

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(4)
Workaround:
- None

Description of the correction:


- The problem of DNS resolving Unsuccessful flooding the alarm history can be avoided by
keeping the pair of fqdn and error code in a map and raising the alarm once per day per CPPU
for each pair of fqdn and error code.

Risk analysis of the correction:


- None

Correction effects:
- The same failed DNS query will raise the alarm only once per day per CPPU. Also, the
operator can clear the map that keeps the FQDNs for which the alarm is raised through the
day with following cli command on CPPU:
cli dns clearalarmmap. That is if the operator wants to see a problematic FQDN to raise the
alarm again within the same day.

Interface effects:
- None

Customer effects:
- No flooding of the alarm history.

Test requirements:
- FQDN should not be configured in external DNS server for which DNS query will be done by
MME

Corrected Fault Reports:


PR153396
Dns Resolving Unsuccessful alarm (0095) flooding and map clearing

Modified components:

Component Version
LNX922G2.IMG 11.5-0
LNX935G2.IMG 10.9-0
LNXA9BG2.IMG 5.5-0
LNX924G2.IMG 11.8-0
LNX971G2.IMG 8.6-0
ald00095.sed 1.3-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(4)
Testing Instructions for the change

Pre-requirements:
DNS configuration missing form external DNS server.

Test execution:
Test 1:
1 Attach request 1.
2 SWG/PGW DNS query (not configured in DNS server)
Note: DNS query fails.
3 DNS RESOLVING UNSUCCESSFUL alarm raised for the first time.
4 Attach request 2
5 SWG/PGW DNS query (not configured in DNS server)
Note: DNS query fails.

Test 2:
1 Inter MME TAU request 1
2 MME DNS query (not configured in DNS server)
Note: DNS query fails.
3 DNS RESOLVING UNSUCCESSFUL alarm raised for the first time.
4 Inter MME TAU request 2
5 MME DNS query (not configured in DNS server)
Note: DNS query fails.

Test 3:
1 Inter System TAU request 1
2 SGSN DNS query (not configured in DNS server)
Note: DNS query fails.
3 DNS RESOLVING UNSUCCESSFUL alarm raised for the first time.
4 Inter System TAU request 2
5 SGSN DNS query (not configured in DNS server)
Note: DNS query fails.

Expected results:
Test 1:
After step 5, DNS RESOLVING UNSUCCESSFUL alarm shouldn't be raised by the same
CPPU.

Test 2:
After step 5, DNS RESOLVING UNSUCCESSFUL alarm shouldn't be raised by the same
CPPU.

Test 3:
After step 5, DNS RESOLVING UNSUCCESSFUL alarm shouldn't be raised by the same
CPPU.

The next day the same CPPU can raise the alarm again for pair of fqdn and error code

Unexpected results:
Test 1:
After step 5, DNS RESOLVING UNSUCCESSFUL alarm will be raised by the same CPPU.

Test 2:
After step 5, DNS RESOLVING UNSUCCESSFUL alarm will be raised by the same CPPU.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(4)
Test 3:
After step 5, DNS RESOLVING UNSUCCESSFUL alarm will be raised by the same CPPU.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 4(4)
Mobile Packet Core

CN-id: NS16.50610

Title:
IESIEU: Create logical file for upglog failed

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- IES prints Test logs sometimes.

How end user/operator could detect the problem:


- Irreproducible problem.

Description of the fault:


- IES prints Test logs sometimes.

Dependency on configuration:
- None

Faulty component and version:


- IESPRBGX.PAC 2.31-0

Faulty component first delivered in(e.g. release, CD):


- Y2 16.57-0

Workaround:
- None

Description of the correction:


- Change Test logs to Info logs.

Risk analysis of the correction:


- None

Correction effects:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


PR161042
IESIEU: Create logical file for upglog failed

Modified components:

Component Version
IESPRBGX.PAC 2.33-0

Change effects:

Customer Impact
Stability

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Execute MML command ZD8F: UT=SHMU: FRUD: FCD: PRE;

Expected results:
No test logs are shown in service terminal.

Unexpected results:
Some test logs are shown in service terminal.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50611

Title:
The IPMC version is not correct after updating the eSW.

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- The minor version of some IPMC is incompatible with disk version.

How end user/operator could detect the problem:


- Execute ZD8I command to inquire IPMC version.

Description of the fault:


- The minor version of some IPMC is incompatible with disk version.

Dependency on configuration:
- None

Faulty component and version:


- EUMANAGX.PAC 1.25-0

Faulty component first delivered in(e.g. release, CD):


- Y2 17.15-10

Workaround:
- None

Description of the correction:


- Convert hardware minor version to disk version.

Risk analysis of the correction:


- None

Correction effects:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


PR166698
The IPMC version is not correct after update the eSW of ACPI4- A/B blade.

Modified components:

Component Version
EUMANAGX.PAC 1.27-2

Change effects:

Customer Impact
Stability

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
Execute ZD8U command to update IPMC to 05.52.6600.
Execute ZD8I:::ALL; command to check IPMC versions of ACPI4_A or ACPI4_B.

Expected results:
IPMC of ACPIs are 05.52.6600.

Unexpected results:
IPMC of ACPIs are 05.52.66100.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50612

Title:
CDR Data volume mismatch between CDRs reported from SGSN & GGSN

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Based on customer's report and log files, there is a mismatch on CDR volume reported
between SGSN and GGSN.

How end user/operator could detect the problem:


- Via tracing internal and external log files as well as CMD reports.

Description of the fault:


- More thoroughly, a GGSN initiated "update pdp context" loop is triggered with no modification
on QoS which although leads to a forwarding of pdp modification notifications to the charging
process of an active PDP context. In terms of this procedure, for prepaid subscribers on S4S
prb, there is a mechanism which fetches data volumes and calculates the total uplink and
downlink data volume. Even though there is no modification on PDP, it is an originally
abnormal behaviour on behalf of gateway, SGSN used to summarize data volumes received
and as result such a mismatch on the final S-CDRs is observed. Also, due to this calculation
the upper limit of data volume (UL/DL) is reached and CDR is closed and forwarded to A4S to
be written.

Dependency on configuration:
- None

Faulty component and version:


- S4S_GMJX.PAC 4.49-0

Faulty component first delivered in(e.g. release, CD):


- SG7

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- A defensive mechanism was implemented in terms of data volume calculation on S4S for
such abnormal update PDP context loops initiated by GGSN, so as not to summarize them
when there are no PDP modifications as well as volume data changes.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- None

Test requirements:
- None

Corrected Fault Reports:


NA05916304
SGSN Volume mismatch in S CDR & SA CDR in all EAST SGSN

Modified components:

Component Version
S4S_GMJX.PAC 15.4-0
GTP_GXJX.PAC 28.46-0

Change effects:

Customer Impact
Charging

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
None

Test execution:
1.2G Attach.
2.Activate pdp.
3.GGSN initiates a loop of Update PDPs with same QoS.

Expected results:
No CDRs are closed due to maximum limit volume and no mismatch on CDRs that are
reported by SGSN in comparison with the ones reported by GGSN.

Unexpected results:
CDRs are closed due to maximum limit volume and there is mismatch on CDRs that are
reported by SGSN in comparison with the ones reported by GGSN.

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50613

Title:
LNXAA0G2 IFMonitor Improve the TRepeat timer implementation

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- LNXAA0G2 IFMonitor Improve the TRepeat timer implementation.

Description of the problem:


- LNXAA0G2 IFMonitor Improve the TRepeat timer implementation.

How end user/operator could detect the problem:


- IFMonitor system logs shows the TRepeat timer expires longer than expected time when
issue is observed.

Description how problem can be detected:


- IFMonitor system logs shows the TRepeat timer expires longer than expected time when
issue is observed.

Description of the fault:


- LNXAA0G2 IFMonitor Improve the TRepeat timer implementation.

Dependency on configuration:
- None

Faulty component and version:


- LNXAA0G2 6.8-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- Use C++ instead of java for IFMonitor. C++ provide reliable timer scheduling.

Risk analysis of the correction:


- None

Correction effects:
- None

Interface effects:
- None

Customer effects:
- No 2101 alarms will be raised when the TRepeat timer expires with the configured value.

Test requirements:
- No 2101 alarms should be raised due to delay in expiration of the TRepeat timer.

Corrected Fault Reports:


NA05922776
(Flexi_NS MME NS16MP0.1) MME appear a large number of 2101 "MME UNIT FAILURE"
alarms after upgrade to NS16MP0.1

PR177848
LNXAA0G2 IFMonitor Improve the TRepeat timer implementation

Modified components:

Component Version
LNXAA0G2.IMG 4.12-0

Change effects:

Customer Impact
Capacity & Performance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Test execution:
The correction cannot be tested using the operator interface commands. The correction has
been tested internally in Nokia test lab and proved to be fully functional.

Expected results:
None

Unexpected results:
None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 3(3)
Mobile Packet Core

CN-id: NS16.50614

Title:
Wrong APN was sent by MME in Create Session Request message to GW

Version of the SW-build:


N6 5.18-0

Valid for Product(s):


Flexi NS

References:

Reason for the Change Note:


Summary of the original problem:
- Wrong APN was sent by MME in Create Session Request message to GW.

How end user/operator could detect the problem:


- When the system was loaded with many attach requests, an increase in Attach failures was
observed due to the fact that the requested APN, was not included in the subscribers’
subscription data.

Description of the fault:


- The problem was that if a subscriber did not request during Attach or PDN Connection to be
connected to a certain APN, then the APN that MME might choose to provide to the UE, might
be an APN that was not included at subscriber's subscription data. More specifically, MME
would provide wrongly, the default APN of another subscriber's data.

Dependency on configuration:
- For the issue to be revealed feature should be activated. (Prfile Parameters: 2051, 2250,
2050) and load of attach requests and PDN Connectivity requests should be applied to MME.
The issue will be revealed if range of default APNs is used at subscription data for different
subscribers.

Faulty component and version:


- LNX934G2.IMG 11.117-0

Faulty component first delivered in(e.g. release, CD):


- NS15

Workaround:
- None

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 1(3)
Description of the correction:
- Default APN value is not overwritten when new subscriber tries to Attach or create a PDN
Connection.

Risk analysis of the correction:


- None

Effects on end-user:
- None

Effects on operator:
- None

System effects:
- None

Other effects:
- None

Interface Effects:
- None

Corrected Fault Reports:


NA05956048
(Flexi NS-MME NS16.5) MME was wrong to create session by apn "CMIOT"

NA05958335
MMEW4 override Apn wrongly

Modified components:

Component Version
LNX934G2.IMG 11.129-0

Change effects:

Customer Impact
Operation & Maintenance

Copyright © Nokia 2016. All rights reserved.


CONFIDENTIAL 2(3)
Testing Instructions for the change

Pre-requirements:
This correction cannot be tested using the operator interface commands. The correction has
been tested internally i