LTE Radio Access, Rel. RL70,
Operating Documentation,
Issue 02, Documentation
Change Delivery 4
Troubleshooting LTE RAN
DN09185928
Issue 02
Approval Date 2015-09-15
This document is intended for use by Nokia Solutions and Networks' customers (“You”) only, and it may not be used except for the purposes defined in the agreement between You and Nokia Solutions and Networks (“Agreement”) under which this document is distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Solutions and Networks. If you have not entered into an Agreement applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this document in any manner and You are obliged to return it to Nokia Solutions and Networks and destroy or delete any copies thereof.
The document has been prepared to be used by professional and properly trained personnel, and You assume full responsibility when using it. Nokia Solutions and Networks welcome Your comments as part of the process of continuous development and improvement of the documentation.
This document and its contents are provided as a convenience to You. Any information or statements concerning the suitability, capacity, fitness for purpose or performance of the Product are given solely on an “as is” and “as available” basis in this document, and Nokia Solutions and Networks reserves the right to change any such information and statements without notice. Nokia Solutions and Networks has made all reasonable efforts to ensure that the content of this document is adequate and free of material errors and omissions, and Nokia Solutions and Networks will correct errors that You identify in this document. But, Nokia Solutions and Networks' total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia Solutions and Networks does not warrant that the use of the software in the Product will be uninterrupted or error-free.
NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF AVAILABILITY, ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN RELATION TO THE CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA SOLUTIONS AND NETWORKS BE LIABLE FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS FROM THIS DOCUMENT OR ITS CONTENT.
This document is Nokia Solutions and Networks’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the prior written consent of Nokia Solutions and Networks.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright © 2015 Nokia Solutions and Networks. All rights reserved.
f
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 Solutions and Networks is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the recommendations for power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia Solutions and Networks for any additional information.
Summary of changes... 9 1 LTE troubleshooting methodology...10 2 Monitoring LTE RAN...11 2.1 Hardware and software monitoring...11 2.1.1 Handling faults and alarms ... 11 2.1.2 Troubleshooting faults and alarms... 12 2.1.3 Viewing alarms in BTS Site Manager...12 2.1.4 Alarm monitoring in NetAct... 13 2.1.5 LED indications... 14 2.1.5.1 LEDs of the Flexi Multiradio System Module (FSME)... 14 2.1.5.2 LEDs of the Flexi Multiradio 10 BTS... 15 2.1.5.2.1 LEDs of the Flexi Multiradio 10 System Module (FSMF)... 15 2.1.5.2.2 LEDs of the Flexi Multiradio 10 System Module (FSIH)... 17 2.1.5.2.3 LEDs of the capacity extension sub-module (FBBA)... 18 2.1.5.2.4 LEDs of the capacity extension sub-module (FBBC)... 20 2.1.5.2.5 LEDs of the capacity extension sub-module (FBIH)... 21 2.1.5.3 LEDs of the transmission sub-module... 21 2.1.5.4 LEDs of the Flexi Zone Micro/Pico BTS... 22 2.1.5.5 LEDs of the Flexi Zone Controller... 26 2.2 Performance monitoring... 27 2.2.1 Viewing counters in BTS Site Manager...28 2.2.2 Performance monitoring in NetAct... 29 2.2.3 Network monitoring using Traffica... 30 2.2.3.1 Traffica general use case for LTE troubleshooting... 30 3 Collecting and analyzing troubleshooting data...32 3.1 eNB snapshot...32 3.1.1 eNB snapshot content... 32 3.1.2 Saving a Flexi Multiradio BTS LTE snapshot file for troubleshooting purposes... 33 3.1.3 LTE1099: Event-triggered symptom data collection and provisioning ... 34 3.1.3.1 Collecting eNB logs using the LTE1099: Event-triggered symptom data collection and provisioning feature...34 3.1.4 LTE1909: BTS Diagnostics Toolkit... 35 3.1.4.1 Triggering snapshot collection using LTE1909: BTS Diagnosis Toolkit... 36 3.2 Cell trace... 36 3.2.1 Trace features... 37 3.2.1.1 LTE163: Subscriber and Equipment Trace... 37 3.2.1.2 LTE433: Cell Trace...38
3.2.1.6 LTE953: MDT (Minimization of Drive Test)...38 3.2.1.7 LTE1340: Trace-based Real Time Monitoring...39 3.2.1.8 LTE1457: Cell trace Configuration via Configuration Management. 39 3.2.1.9 LTE1687: Basic Layer3 Data Analyzer (L3DA) for LTE...39 3.2.2 Cell trace content... 39 3.2.3 Activating cell trace in BTS Site Manager... 40 3.2.4 Viewing and analyzing cell trace data using L3DA... 41 3.2.5 Tracing with NetAct... 43 3.3 IP traffic capturing... 43 3.3.1 Monitoring IP traffic using the LTE1460: Local and Remote IP Traffic Capturing feature...44 3.3.2 Analyzing IP capture files with Wireshark... 45 3.4 Sending troubleshooting data to technical support... 47 3.5 Problems and use cases... 48 4 LTE troubleshooting use cases... 51 4.1 BTS Site Manager connection problems...51 4.1.1 Accessing eNB using BTS Site Manager... 51 4.1.1.1 Problems with BTS Site Manager connectivity to the eNB... 51 4.1.1.2 Checking the PC firewall settings in Windows... 52 4.1.1.2.1 Checking PC firewall settings in Windows XP Professional...53 4.1.1.2.2 Checking the PC firewall settings in Windows Vista/Windows 7... 54 4.1.1.3 Remote connectivity via transport backhaul (m-plane)... 55 4.1.1.4 Remote connectivity over Bluetooth (FZM only)... 56 4.1.1.5 Local connection problems... 60 4.1.1.5.1 Local connectivity via local maintenance port... 61 4.1.1.5.2 Cannot ping modules through LMP port... 61 4.1.2 Changing BTS Site Manager local account... 62 4.1.3 Configuring Exceed for BTS Site Manager launching...62 4.1.4 Access to the Linux shell...63 4.1.5 GPS maintenance access not possible through remote connection ... 64 4.2 Software download/activation problems...65 4.2.1 Incompatible BTS software version ...65 4.2.2 Software update to BTS site fails... 66 4.2.3 Software version mismatch... 67 4.2.4 Problems with local software download from BTS Site Manager... 67 4.3 (Re)commissioning problems...70 4.3.1 Checking the BTS commissioning file... 70 4.3.2 Cannot save commissioning file or send parameters... 70 4.3.3 Verification of normal eNB site operation... 71
4.4.3 Fallback solution for phase synchronization... 74 4.5 Cell does not come on air... 75 4.6 Sleeping cell... 76 4.7 eNB in a reset loop...77 4.8 Troubleshooting call processing problems ... 77 4.8.1 High RRC Setup failure rate/RACH problems...78 4.8.2 RAB setup problems... 79 4.9 Antenna line device problems... 80 4.9.1 Checking antenna line and MHA ...80 4.10 Troubleshooting hardware problems...81 4.10.1 Performing routine maintenance tasks...81 4.10.2 Troubleshooting Flexi transmission module... 85 4.10.2.1 BTS reset required... 85 4.10.2.2 Dead Peer detected... 85 4.10.2.3 Ethernet interface is not working... 86 4.10.3 Identification of faulty units... 87 4.10.4 Identification of faulty FZM unit... 91 4.10.5 Problems in connectivity between BTS modules... 91 4.10.6 FZM Recovery...92
Figure 2 Faults view in BTS Site Manager... 13 Figure 3 System Module LED positions...14 Figure 4 LEDs of the Flexi Multiradio 10 System Module (FSMF)...17 Figure 5 LEDs of the Flexi Multiradio 10 System Module (FSIH)... 18 Figure 6 LEDs of the capacity extension sub-module (FBBA)...19 Figure 7 LEDs of the capacity extension sub-module (FBBC)... 20 Figure 8 LEDs of the capacity extension sub-module (FBIH)...21 Figure 9 LEDs of pico eNB... 23 Figure 10 Front panel of the Flexi Zone Controller module ... 26 Figure 11 Performance monitoring data useful for troubleshooting...27 Figure 12 Measurement configuration in BTS Site Manager...28 Figure 13 Viewing counters in BTS Site Manager... 29 Figure 14 Defining symptom data trigger list... 34 Figure 15 Selecting triggers for eNB snapshot collection... 36 Figure 16 Local and Remote IP Traffic Capturing Service window...44 Figure 17 IP capture file in Wireshark...46 Figure 18 Expert Info view in Wireshark... 46 Figure 19 Disabling Windows Firewall in Windows XP Professional...54 Figure 20 BTS Site Manager log-in screen...56 Figure 21 Legacy pairing settings...57 Figure 22 Select manual pairing option... 58 Figure 23 Enter the legacy pairing code... 59 Figure 24 Successful pairing ... 59 Figure 25 Establishing PAN connection...60 Figure 26 Local connectivity log-in screen...61 Figure 27 Enabling the SSH service for Linux shell access... 64 Figure 28 Software update failed...68 Figure 29 Software update report... 69 Figure 30 BTS statuses in BTS Site Manager... 72 Figure 31 IP Connectivity Test in BTS SM...72 Figure 32 IP Connectivity test result... 72 Figure 33 Example ToP configuration...74 Figure 34 LMP IP plug installed...82 Figure 35 LMP port IP cap not reinstalled after maintenance...82 Figure 36 Connector IP boot correctly installed firmly in place...83 Figure 37 Connector IP boot incorrectly installed (IP seals not firmly in place on any edge)...83 Figure 38 Connector IP boot incorrectly installed (not pushed all the way in).... 84
Table 2 LEDs of the Flexi Multiradio 10 System Module (FSMF)...15 Table 3 LEDs of the Flexi Multiradio 10 System Module (FSIH)... 17 Table 4 LEDs of the capacity extension sub-module (FBBA) ...18 Table 5 LEDs of the capacity extension sub-module (FBBC)... 20 Table 6 LEDs of the capacity extension sub-module (FBIH)...21 Table 7 Transmission sub-module LED indications...22 Table 8 FZM and FZP LED indications... 23 Table 9 Flexi Zone Pico Wi-Fi LED states...25 Table 10 Description of front panel indicator LEDs in a BCN module... 26 Table 11 Features related to eNB snapshot...32 Table 12 Trace features...37 Table 13 Nokia Case Types... 47 Table 14 Nokia Problem Priorities... 48 Table 15 LTE use cases... 48 Table 16 Explanation of NetAct Diagnostic Info values...87 Table 17 Explanation of NetAct Diagnostic Info values...89 Table 18 Explanation of NetAct Diagnostic Info values...89
Summary of changes
Changes between issues 01 (2014-11-21, RL70) and 02 (2015-09-15, RL70) The Fallback solution for phase synchronizationsection was added.
Issue 01 (2014-11-21, RL70)
1 LTE troubleshooting methodology
Figure 1: LTE troubleshooting methodology presents a general example of the procedures performed and tools used by the troubleshooting personnel. Figure 1 LTE troubleshooting methodologyMONITORING
COLLECTING
DATA
ANALYZING
DATA
FINDING
ROOT!CAUSE
TROUBLESHOOTING!PROCEDURES
• ALARMS KPIs/!COUNTERS NETACT TRAFFICA • • • • • • eNB!SNAPSHOT CELL!TRACE IP!TRAFFIC CAPTURE • • • NETACT TRAFFICA PROTOCOL ANALYZER • • • DATA!CORRELATION RECOVERY PROCEDURES USE!CASESTROUBLESHOOTING!TOOLS
The LTE troubleshooting methodology consists of the following procedures: • Monitoring • Collecting and analyzing data • Finding root cause (with the help of use cases) The order of actions and the selection of tools might vary depending on the use case and operator preferences. It depends on the nature of a problem if the root cause analysis is performed by the operator (for example, site configuration-related problems) or by Nokia Services (for example, defects inside a product). If it is not possible to find the root cause of the problems, Nokia Services should be contacted.2 Monitoring LTE RAN
Monitoring of LTE RAN network allows the operator to notice potential problems and unwanted behaviors. Network monitoring consists of: • hardware and software monitoring (using faults and alarms) • performance monitoring (using key performance indicators and counters) Particular eNB sites can be monitored using the BTS Site Manager. NetAct and Traffica applications allows the operator to monitor the whole LTE RAN network.2.1 Hardware and software monitoring
This section explains how to monitor hardware and software using faults, alarms, and LED indications.
2.1.1 Handling faults and alarms
Issues with software or hardware are signalled via fault messages, which in turn raise alarms. Fault messages come either from hardware devices or software components. The faults are system-specific or hardware-specific. The Fault Diagnosis System creates upper network alarms, which are based on an analysis of the faults, and sends them to the BTS Site Manager and iOMS/NetAct. The eNB alarm handling is based on the information of a unit or module state. It prevents sending unnecessary alarms by checking and updating the unit states. The eNB is able to maintain alarm handling after it has been commissioned and is in a configured state. During the start-up, the eNB waits for the real-time clock from the Network Time Protocol (NTP) server, and the fault diagnosis starts after the time has been set, or a time-out has been detected. If the eNB is unable to set the time using the NTP server, the default time (1.1.2004) is used.
eNB transmission alarms
The eNB transmission alarms (alarm ID 7665) are reported towards iOMS or NetAct. The transmission equipment uses the base station interface. Therefore, the retrieval of alarm information is mapped (using the fault ID) either in the iOMS or in the NetAct to
distinguish between the alarms. Troubleshooting faults and alarms
Faults and alarms are signaled in several ways: • in BTS Site Manager
• using LEDs
When starting to solve a problem, first refer to the instructions given in individual alarm descriptions. See the fields 'Fault source' and 'Instructions' in the alarm description. Many problems can be caused by commissioning mistakes, incorrect cabling, or wrong module installation.
2.1.2 Troubleshooting faults and alarms
The following procedure is an overview of faults and alarms troubleshooting methodology. Symptoms Fault or alarms is detected. Recovery procedure Follow these instructions to check the BTS faults and LED states.
Procedure
1 Check the faults with OMS Fault Management. a) Start the Fault Management application.
b) Check the active faults from the Active Alarms tab.
c) Additionally fault history can be checked from the Alarm History tab.
2 Establish a connection to the BTS using BTS Site Manager and read alarm information.
For more information see Viewing alarms in BTS Site Manager.
3 Check the unit states signalized by LEDs.
Ensure that BTS Site Manager HW view corresponds with the actual BTS HW configuration. If there is a mismatch or grey units, check the SW level and unit states. For instructions, see Checking BTS SW versions and SW download. For descriptions on module LED states see LED indications.
2.1.3 Viewing alarms in BTS Site Manager
BTS Site Manager displays the current alarm information, and the following procedure explains how to access this information. Alarm history is also included in the eNB snapshot.
Procedure
1 Check the Faults view in BTS Site Manager (in the BTS Hardware tab). Figure 2 Faults view in BTS Site Manager
A
B
2 Click Show Source to find out which component is responsible for the alarm. Show Source is marked as element A in Figure 2: Faults view in BTS Site Manager. Clicking this button will highlight the faulty unit or open a configuration window where the error occurs.
3 To display the alarm description, click the question mark icon.
The question mark icon is marked as element B in Figure 2: Faults view in BTS Site Manager.
Clicking this button will open an online help window with detailed information about the fault.
2.1.4 Alarm monitoring in NetAct
The NetAct Monitor application allows the user to view and process alarm information. For information on available tools and functions, refer to NetAct operating
documentation:
• Fault Management Overview and Operations • Fault Management Helps
2.1.5 LED indications
Most hardware components have tricolor LEDs on the front panel to indicate the operational status and fault conditions. It is recommended that you read the information on the LED indications carefully. A blinking red LED does not always require removing of the module.
2.1.5.1 LEDs of the Flexi Multiradio System Module (FSME)
See figure below for the FSME System Module LEDs location. Figure 3 System Module LED positions The LED indications are listed and explained in table below. Table 1 System Module LEDs (from left to right) LED Color FPFB status (one LED for internal and each external power output) • Yellow: Stand-by, output disabled • Green: Normal operation, output enabled • Red: Fault, output disabled • Yellow, blinking: Remote controlled, output disabled Fan status • Red: Fan fault • Green: Fan OK System Module status • Red: Module self-test or reset (LED red for < 5 seconds) or major alarm or critical alarm • Red, blinking: Minor alarm • Yellow: Stand-by or blocked
Table 1 System Module LEDs (from left to right) (Cont.) LED Color • Yellow, blinking: SW download or configuration ongoing, module non-operational • Green: Module operational (the cell can be locked in the RNC) • Green, blinking: Module is loading software or parameters or local maintenance access when modules are operational RF Module 1 fiber connection status (OPT-RF1) • Red: no connection • Green: connection OK • Yellow: not in use RF Module 2 fiber connection status (OPT-RF2) • Red: no connection • Green: connection OK • Yellow: not in use RF Module 3 fiber connection status (OPT-RF3) • Red: no connection • Green: connection OK • Yellow: not in use System Extension Module 1 fiber connection status (OPT-EXT1) • Red: no connection • Green: connection OK • Yellow: not in use System Extension Module 2 fiber connection status (OPT-EXT2) • Red: no connection • Green: connection OK • Yellow: not in use
2.1.5.2 LEDs of the Flexi Multiradio 10 BTS
2.1.5.2.1 LEDs of the Flexi Multiradio 10 System Module (FSMF)
Table 2 LEDs of the Flexi Multiradio 10 System Module (FSMF)
LED Color
EIF2/RF/6 • Red: no connection
Table 2 LEDs of the Flexi Multiradio 10 System Module (FSMF) (Cont.) LED Color RF/EXT link 6 status or transport interface 2 status • Yellow: not in use RF/EXT1 RF link 1 status • Red: no connection • Green: connection OK • Yellow: not in use RF/EXT2 RF link 2 status • Red: no connection • Green: connection OK • Yellow: not in use RF/EXT3 RF link 3 status • Red: no connection • Green: connection OK • Yellow: not in use SRIO • Red: no connection • Green: connection OK • Yellow: not in use EIF1/TRS Transport interface 1 status • Red: no connection • Green: connection OK • Yellow: not in use FAN Fan status • Red: Fan fault • Green: Fan OK STATUS System Module status • Red: Module self-test or reset (LED red for < 5 seconds) or major alarm or critical alarm • Red, blinking: Minor alarm • Yellow: Stand-by or blocked • Yellow, blinking: SW download or configuration ongoing, module non-operational • Green: Module operational (the cell can be locked in the RNC) • Green, blinking: Module is loading software or parameters or local maintenance access when modules are operational
Figure 4 LEDs of the Flexi Multiradio 10 System Module (FSMF)
EIF2/RF/6
RF/EX 2
T
RF/EX 1
T
RF/EX 3
T
SRIO
EIF1/TRS
FAN
STATUS
2.1.5.2.2 LEDs of the Flexi Multiradio 10 System Module (FSIH)
Table 3 LEDs of the Flexi Multiradio 10 System Module (FSIH) LED Color FAN Fan status • Red: Fan fault • Green: Fan OK STATUS System Module status • Red: Module self-test or reset (LED red for < 5 seconds) or major alarm or critical alarm • Red, blinking: Minor alarm • Yellow: Stand-by or blocked • Yellow, blinking: SW download or configuration ongoing, module non-operational • Green: Module operational • Green, blinking: Module is loading software or parameters or local maintenance access when modules are operational RF1 RF2 RF3 RF4 RF5 RF6 RF/EXT1 RF/EXT2 RF/EXT3 RF/EXT4 • Red: no connection • Green: connection OK • Yellow: not in use
Table 3 LEDs of the Flexi Multiradio 10 System Module (FSIH) (Cont.) LED Color RF/EXT5 RF/EXT6 RF link status SRIO1 SRIO2 SRIO1-2 connection status • Red: no connection • Green: connection OK • Yellow: not in use EIF1 EIF2 Transport interface status • Red: no connection • Green: connection OK • Yellow: not in use Figure 5 LEDs of the Flexi Multiradio 10 System Module (FSIH)
SRIO2
RF1-4
RFEXT4
RFEXT5/10G
RFEXT6
RFEXT3/10G
RFEXT2
RFEXT1/10G
SRIO1
RF5
RF6/EIF5
EIF1-2
FAN
STATUS
2.1.5.2.3 LEDs of the capacity extension sub-module (FBBA)
Table 4 LEDs of the capacity extension sub-module (FBBA) LED Color SRIO SRIO1 connection status • Red: no connection • Green: connection OK
Table 4 LEDs of the capacity extension sub-module (FBBA) (Cont.) LED Color • Yellow: not in use STATUS Operational status • Red: Module self-test or reset (LED red for < 5 seconds) or major alarm or critical alarm • Red, blinking: Minor alarm • Yellow: Stand-by or blocked • Yellow, blinking: SW download or configuration ongoing, module non-operational • Green: Module operational • Green, blinking: Module is loading software or parameters or local maintenance access when modules are operational RF/EXT RF link status • Red: no connection • Green: connection OK • Yellow: not in use Figure 6 LEDs of the capacity extension sub-module (FBBA)
2.1.5.2.4 LEDs of the capacity extension sub-module (FBBC)
Table 5 LEDs of the capacity extension sub-module (FBBC) LED Color RF1 RF2 RF3 RF link status • Red: no connection • Green: connection OK • Yellow: not in use SRIO/RF4 RF4 link status or SRIO interface status • Red: no connection • Green: connection OK • Yellow: not in use STATUS Operational status • Red: Module self-test or reset (LED red for < 5 seconds) or major alarm or critical alarm • Red, blinking: Minor alarm • Yellow: Stand-by or blocked • Yellow, blinking: SW download or configuration ongoing, module non-operational • Green: Module operational • Green, blinking: Module is loading software or parameters or local maintenance access when modules are operational Figure 7 LEDs of the capacity extension sub-module (FBBC)RF1
RF2
RF3
SRIO/RF4
STATUS
CLASS1 LASERPRODUCT2.1.5.2.5 LEDs of the capacity extension sub-module (FBIH)
Table 6 LEDs of the capacity extension sub-module (FBIH) LED Color STATUS Operational status • Red: Module self-test or reset (LED red for < 5 seconds) or major alarm or critical alarm • Red, blinking: Minor alarm • Yellow: Stand-by or blocked • Yellow, blinking: SW download or configuration ongoing, module non-operational • Green: Module operational • Green, blinking: Module is loading software or parameters or local maintenance access when modules are operational. RF/EXT1 RF/EXT2 RF/EXT3 RF/EXT4 RF/EXT5 RF/EXT6 RF1-6 link status • Red: no connection • Green: connection OK • Yellow: not in use SRIO1 SRIO2 SRIO1-2 connection status • Red: no connection • Green: connection OK • Yellow: not in use Figure 8 LEDs of the capacity extension sub-module (FBIH)SRIO1
RFEXT1/10G
RFEXT2
RFEXT3/10G
RFEXT4
RFEXT5/10G
RFEXT6
SRIO2
STATUS
2.1.5.3 LEDs of the transmission sub-module
Table 7 Transmission sub-module LED indications
Color Explanation Relevant fault
No color The module has no power.
Red Module is faulty. • AIS on unit $U, interface $IF
• BFD Session down in egress direction for session $S • BFD Session down in ingress direction for session $S • EBER on unit $U, interface $IF • License missing for feature $feature on interface $if • LOF on unit $U, interface $IF • LOMF on slot $U, interface $IF • LOS on unit $U, [ethernet] interface $IF • Missing or non-compliant SFP module on unit $U, interface $I • RDI on unit $U, interface $IF • Synchronization lost Red, blinking Module is degraded. • $Protocol Timing source lost on unit $U [, interface $IF] Yellow Module is not operational (blocked or uncommissioned). • Dead Peer Detected Yellow, blinking Module is not operational but SW download or configuration is ongoing. Green Module is operational (configured and working). Green, blinking Module is operational but SW download or configuration is ongoing.
2.1.5.4 LEDs of the Flexi Zone Micro/Pico BTS
Figure 9 LEDs of pico eNB TransportStatusLED WiFiStatusLED RFPowerStatusLED RFPowerStatusLED BTSStatusLED The Flexi Zone Micro/Pico BTS LED indications are listed and explained in tables below. Table 8 FZM and FZP LED indications
LED Color Description Priority ( 1 is
highest) Transport Status LED OFF BTS is booting up, and the
Platform SW is starting up. LED is being controlled by HW. 1 Stable RED In the startup sequence, the Platform SW is up and it has taken the control of LED. This state continues until the TRSW become operational following Site Power-Up or Site Reset. Includes POST (in case of a power on scenario) 1 Stable RED TRSW has taken control of Transport Status LED and is Initializing *or* Critical or Major Fault raised on TRSW 2 Stable YELLOW Critical or Major Fault raised on TRSW AND Bluetooth is ENABLED automatically 2 Blinking RED MINOR or Degraded alarm exists on TRSW 3 Stable GREEN TRSW is ready (fully initialized) - No known Critical/Major/Degraded/Minor Transport faults present. 4 RF Power Status LED OFF BTS is booting up, and the Platform SW is starting up. LED is being controlled by HW. 1 OFF Platform SW has come up successfully. 1
Table 8 FZM and FZP LED indications (Cont.)
LED Color Description Priority ( 1 is
highest) Blinking GREEN FPGA has taken control of the RF LED in the startup sequence 1 Blinking GREEN RF Transmission OFF 1 Stable GREEN RF Transmission ON 2 BTS Status LED Stable RED While BTS is booting up and
Status LED is being controlled by HW 1 Blinking YELLOW In startup sequence, Platform SW is up and is now controlling the Status LED. Includes POST (in case of a power on scenario) 1 Blinking YELLOW Startup: Indicates BTSOM has taken control of the BTS Status LED and is performing site initialization related activities with the iOMS (SW version inquiry, SW download, SCF download, HW Configuration upload, Alarm sync, etc). 2 Stable YELLOW Indicates BTS and/or all CELLs are Blocked/Locked 3 Stable RED Indicates BTS is Faulty: It signifies that at-least one Critical Fault is currently present on BTS. Note: Includes any type of BTS faults including Transport, U-Plane, and C-Plane faults. 4 Blinking RED Indicates BTS is degraded: At least one Major Fault is currently active on BTS (while no Critical Faults are active) Note: Includes any type of BTS faults including Transport, U-Plane, and C-Plane faults. 5 Blinking GREEN Indicates a SW download is in progress during runtime operation (i.e. SW download is occurring outside of startup) 6
Table 8 FZM and FZP LED indications (Cont.)
LED Color Description Priority ( 1 is
highest) Stable RED Indicates a Critical Failure occurred during Auto Connection (AutoConnectionState is "Disconnected"). If failure is due to an iOMS rejection (unsuccessful AutoConnectionEstablishedReply message was received), condition will persist for 5 min until the Auto-Connection process is automatically retried. Note: If failure is due to iOMS connectivity being down (detected by Supervision on iOMS link), a Critical Fault will be active (SET). 7 Blinking YELLOW Indicates Auto-Connection is in Progress (Until connection to Final iOMS is achieved) 8 Stable YELLOW Indicates BTS is Uncommissioned Note: A "4030: EFaultId_NoCommDataAl" will be SET resulting in generation of a "7652 BASE STATION NOTIFICATION" alarm. 9 Blinking GREEN BTS in Test Dedicated State 10 Stable GREEN Indicates either 1) a stable condition where at least one CELL is OnAir (indicated in conjuction with "RF Power Status" LED being Stable GREEN), or 2) a transitory condition where the BTS is fully configured and nothing is preventing a CELL from transitioning to onAir (indicated in conjuction with "RF Power Status" LED being Blinking GREEN). 10 For descriptions of Pico module Wi-Fi LED states, see table below. Table 9 Flexi Zone Pico Wi-Fi LED states
Wi-Fi LED state Description
Off Wi-Fi module not present
Table 9 Flexi Zone Pico Wi-Fi LED states (Cont.)
Wi-Fi LED state Description
Stable red 2.4 GHz and 5 GHz fault
Blinking green 2.4 GHz or 5 GHz fault
Stable green 2.4 GHz and 5 GHz on
2.1.5.5 LEDs of the Flexi Zone Controller
Location of LEDs on the Flexi Zone Controller is show in figure below. Figure 10 Front panel of the Flexi Zone Controller module
The Flexi Zone Controller LED indications are listed and explained in table below. Table 10 Description of front panel indicator LEDs in a BCN module
Symbol and name Color State Description
Application-specific LEDs
A1 and A2
Green Steady or blinking Two tri-color application-specific LEDs controlled through an IPMI command. During module startup both LEDs indicate start (BLUE) and completion (GREEN) of an LMP’s boot sequence. After successful boot-up the LEDs will remain green. Red Steady or blinking Blue Steady or blinking Off
PSU indicator LED Green Steady Both power supplies operate normally. Red Steady One of the power supplies has failed.
Table 10 Description of front panel indicator LEDs in a BCN module (Cont.)
Symbol and name Color State Description
NS LED Blue Steady Reserved for future use. Default state: Off Off
Processor/add-in card LEDs P1-P8
Green Steady The module application has started. Red Steady The processor add-in card is powered on,
but no application is running. Blue Steady MMC is running, but the processor is
powered off. Off No add-in card inserted into the slot.
2.2 Performance monitoring
This section focuses on key performance indicators (KPIs) and counters used to monitor network performance. The graphic illustrates how KPI and counter data can be used for troubleshooting purposes. Figure 11 Performance monitoring data useful for troubleshooting The KPI descriptions can be found in the LTE Radio Access Operating Documentation/Reference/Key Performance Indicatiors document. The counterdescriptions can be found in the LTE Radio Access Operating Documentation/Reference/Counters document.
2.2.1 Viewing counters in BTS Site Manager
BTS Site Manager allows the user to schedule measurements and view counter data. The following procedure explains how to access this information.
Before you start
There are separate GUIs for viewing radio-related counters (BTS PM) and transport-related counters (TRS PM). The counter data is also available in the eNB snapshot. The KPIs that are calculated from counter-based formulas can be viewed in NetAct. The user can also define his own KPI formulas.
Procedure
1 Choose either BTS Performance Monitoring or TRS Performance Monitoring. On the left side of BTS Site Manager choose either BTS PM or TRS PM tab.
2 Activate required measurements.
In the selected tab switch to the 'Measurement Configuration' and select the required measurement types and define the collection interval.
3 Switch to the Counters.
4 Select the Object (for example, BTS or a certain cell) and select the Counters to be displayed.
It is possible to view the data in a graph or table format. Figure 13 Viewing counters in BTS Site Manager
2.2.2 Performance monitoring in NetAct
The NetAct Performance Manager application allows the user to view and process counter and KPI data. For information on available tools and functions, refer to NetAct operating documentation: • Performance Management Overview • Performance Manager Overview • Thresholder and Profiler Overview
2.2.3 Network monitoring using Traffica
This chapter introduces the Traffica application. The LTE1053: Real-time KPI-monitoring with Traffica feature provides real-time performance monitoring for the LTE Flexi Multiradio BTS. The Flexi Multiradio BTS is connected directly to Traffica using a new real-time data interface. This real-time data interface contains the results of ongoing performance measurements (PM-counter values) in real-time. These results are sent every minute. The LTE1340: Trace-based Real Time Monitoring feature offers a real time network monitoring solution based on the Flexi Multiradio BTS cell trace interface (introduced with the LTE433: Cell trace feature). The collected trace data is sent to the Layer 3 Data Collector (L3DC) that transfers the data to Traffica for visualization. Traffica consists of: • a Traffica News client for offline analysis of collected data. • a Traffic Views client for real-time monitoring (various graph sets for displaying collected data in different time periods). A Traffica user can configure threshold-based real-time alarms that can be forwarded to the NetAct Monitor application. For more details on Traffica applications and functions, refer to Traffica operating documentation: • Traffica Principles • Traffica Reference Guide2.2.3.1 Traffica general use case for LTE troubleshooting
Purpose
Traffica is a real-time traffic monitoring tool designed to monitor and analyze network traffic. Traffica allows the operator to see how the network functions from the network element level down to individual subscriber information.
Before you start
To visualize the cell trace data and real-time counter data in Traffica, the following requirements must be fulfilled: • The L3 Data Collector (L3DC) is installed and configured. • The LTE433: Cell Trace is activated. • The Traffica - L3DC interface is configured.
Procedure
1 Follow network and service performance indicators using Traffic Views. • Spot degradations (for example, RRC/RAB setup failure increase). • Detect sites with no traffic.
• Define threshold alarms to automate fault detection.
2 Analyze problem severity and location using Traffic Views.
Use failure graphs to check whether the problem is limited to certain network elements (NEs) or cells.
3 Troubleshoot the problem using linked graphs and Traffic News. • Use drill down graphs to isolate the problem further down in topology.
3 Collecting and analyzing troubleshooting
data
To efficiently perform the troubleshooting process, a set of supporting data should be collected. In case of call processing and signaling problems, data can be collected using one of the following methods: • saving eNB snapshot • cell tracing • IP traffic capturing Additional data can be obtained by: • drive test data • end-user feedback • core network indicators • problematic site location (for example, from such geographic location tools as Traffica) If despite having all available data, the operator is not able to solve a problem by himself, Nokia Services should be contacted. Sending troubleshooting data to technical support describes how to contact Nokia in a most effective way.3.1 eNB snapshot
This section explains what is included in an eNB snapshot and how to save a snapshot using different features. Table below list features related to eNB snapshot functionality. Table 11 Features related to eNB snapshot Feature Release LTE1099: Event-triggered Symptom Data Collection and Provisioning RL50 LTE1909: BTS Diagnostics Toolkit RL603.1.1 eNB snapshot content
Examples of data included in the eNB snapshot: • Active alarms and alarm history
• Installed SW versions
• Internal log files for different eNB components (including MAC TTI traces)
• PM counter data for this eNB (starting from the last eNB reset but for a maximum for 24 hours)
3.1.2 Saving a Flexi Multiradio BTS LTE snapshot file for
troubleshooting purposes
Purpose
The snapshot file can be saved in the connected mode; it contains the current status of elements and BTS Site Manager: used HW configuration, logs, alarms, HW and SW version information.
Before you start
Remember to attach the logs when raising a Resolve case to Tier3 level.
g
Note: Several parts of the eNB snapshot are based on ring buffers which are covering only limited time. Therefore, it is important to save the snapshot as soon as possible after a problem has occurred. Otherwise the log parts showing the root cause of the problem might have been overwritten. Setting snapshot collection triggers (eNB faults, signaling events) helps to automate the process.Procedure
1 Choose File → Save → Snapshot to open the Save Snapshot dialog box.
2 Enter the file name and define the location for the file to be saved.
The default file name is Snapshot_<Site name>_<yyyymmdd>.zip. The default location is the folder where you have saved snapshot files previously or your default working folder, for example <OS default user home for
documents>\BTS Site Manager Data.
3 Under Detail Level, select 'Fetch all data from elements'.
4 Enter the description of the situation when the snapshot was taken in the Notes field.
5 Click the Save button.
3.1.3 LTE1099: Event-triggered symptom data collection and
provisioning
Introduction to the feature
This feature introduces automatic fault-triggered BTS symptom data (troubleshooting logs) collection. The triggering BTS faults are defined in the Site Configuration File (SCF) using the NetAct Configurator or using the BTS Site Manager.
The logs are available in the OMS and can be uploaded to NetAct.
3.1.3.1 Collecting eNB logs using the LTE1099: Event-triggered symptom
data collection and provisioning feature
This procedure shows how to configure the LTE1099: Event-triggered symptom data collection and provisioning feature to automate the eNB snapshot collection.
Before you start
The feature configuration is done during an eNB commissioning.
Procedure
1 Define the list of symptom data collection triggers.
Add a new Symptom data trigger list under the MRBTS object. Figure 14 Defining symptom data trigger list
2 Set the Fault ID that should trigger the data collection. Up to 20 faults can be configured.
g
Note: Use the faults that most frequently occur in a certain site or contact Nokia Services for a list of recommended triggers.3 Define the recovery reset delay.
Configure the recovery reset delay parameter under the LNBTS object. If a fault leads to a recovery reset, the eNB might delay it according to the configured value:
• '0': no delay • '1-9999': delay time
• '10000': wait for snapshot to be transferred in iOMS
4 Configure the dwBTSUploadEnabled parameter to enable/disable the data transfer to OMS.
It is recommended to provide an empty trigger list if upload is to be permanently disabled.
5 Configure the dwAlarmForUploadCompleted parameter to enable/disable the alarm setting in OMS.
If enabled, the 71106 TROUBLESHOOTING DATA RECEIVED alarms is raised once the data is received in OMS
6 Configure the NetActNotifyEnabled parameter to enable/disable the data upload to NetAct.
Result
When a fault defined in the symptom trigger list occurs, the symptom data is collected. The 71129 TROUBLESHOOTING DATA CREATION OR UPLOAD FAILED indicates that the data creation or upload to OMS has failed.
3.1.4 LTE1909: BTS Diagnostics Toolkit
Introduction to the feature
The LTE1909: BTS Diagnostics Toolkit provides the operator, technical support and the Nokia developer with efficient data collection from eNB. The set of data collected, such as: trace data, BTS snapshot data, is sent from the operator to Nokia. This feature supports resolving an error at first occurrence given that all the necessary information is available for detailed analysis. The following are the functions/features of this toolkit: • supervises the eNBs via cell tracing • triggers the BTS snapshot creation in a timely manner, based on the trigger events in the cell trace content • comes with the SW of the Layer 3 Data Collector • is easy to use and install
3.1.4.1 Triggering snapshot collection using LTE1909: BTS Diagnosis
Toolkit
With the LTE1909: BTS Diagnosis Toolkit feature, it is possible to trigger an eNB snapshot collection based on selected events.
Procedure
1 Open the L3DA.
2 Go to Filter -> Set snapshot filter for TCP.
3 Configure the triggering options in the opened window. Figure 15 Selecting triggers for eNB snapshot collection
4 Activate the filter.
Result
Once the selected event occurs, the eNB snapshot will be collected.
3.2 Cell trace
3.2.1 Trace features
This section lists all features related to cell trace functionality. Table 12 Trace features Feature Release LTE163: Subscriber and Equipment Trace RL20 LTE433: Cell Trace RL20 LTE459: LTE Timing Advance Evaluation RL30 LTE644: Configurable Cell Trace Content RL30 LTE162: Cell Trace with IMSI RL40 LTE953: MDT (Minimization of Drive Test) RL40 LTE1340: Trace-based Real Time Monitoring RL40 LTE1457: Cell trace Configuration via Configuration Management RL40 LTE1687: Basic Layer3 Data Analyzer (L3DA) for LTE RL50 LTE1501: Measurement Report (MR) addition to cell trace RL70 LTE1914: RIP (Received Interference Power) measurement report extension/Support RIP initiated alarms RL70 LTE1931: Measurement Report addition with UE Uplink SINR RL70 LTE2054: Measurement Report addition with PDCP KPI counter subset RL703.2.1.1 LTE163: Subscriber and Equipment Trace
This feature provides detailed, subscriber-oriented information at a call-level for one or more specific UEs. The subscriber and equipment trace supports the tracing of IMSI or IMEI numbers. The traces are activated on demand. The operator can activate subscriber and equipment tracing for a limited period for the purpose of specific analysis, for example: • root cause determination of a malfunctioning mobile • advanced troubleshooting • optimization of resource usage and quality • RF coverage control and capacity improvement
• dropped call analysis • E2E procedure validation
For more details, see LTE163: Subscriber and Equipment Trace.
3.2.1.2 LTE433: Cell Trace
With this feature, it is possible to follow the ongoing connections in a cell and to verify the intended functions within a cell. All UEs in a target cell that are in the connected state are traced simultaneously. This feature is also used for a more extensive analysis of a problem when various performance measurements do not give a clear indication of the problem. For more details, see LTE433: Cell Trace.
3.2.1.3 LTE459: LTE Timing Advance Evaluation
With this feature, the Timing Advance (TA) values are added to trace reports. Depending on the configuration, the TA values are added to vendor-specific extension tracing of the subscriber trace (LTE163: Subscriber and Equipment Trace) or the cell trace (LTE433: Cell Trace). For more details, see LTE459: LTE Timing Advance Evaluation.
3.2.1.4 LTE644: Configurable cell trace content
This feature allows the operator to configure specific messages to be traced for each selected interface. For more details, see LTE644: Configurable cell trace content.
3.2.1.5 LTE162: Cell Trace with IMSI
With this feature, the existing cell trace data reports are mapped with the IMSI/IMEI numbers of the UEs located in the traced cell. This feature extends the scope of the LTE433: Cell Trace feature. The current LTE433: Cell Trace feature remains unchanged. For more details, see LTE162: Cell Trace with IMSI.
3.2.1.6 LTE953: MDT (Minimization of Drive Test)
This feature is introduced as an alternative to expensive drive tests performed during network deployment and optimization. It offers a predefined set of MDT profiles available at the NetAct TraceViewer application. The profiles are defined to detect and monitor potential coverage problems. The solution is based on the data collected using the following features:
• LTE433: Cell Trace
• LTE644: Configurable cell trace content • LTE570: Periodic UE Measurements
For more details, see LTE953: MDT (Minimization of Drive Test).
3.2.1.7 LTE1340: Trace-based Real Time Monitoring
This feature introduces a real-time network monitoring solution that is based on: • trace data collected from multiple eNBs • L3 Data Collector (L3DC) network element that acts as a trace collection entity in tracing • Traffica is used for visualizing the collected data For more details, see LTE1340: Trace-based Real Time Monitoring.
3.2.1.8 LTE1457: Cell trace Configuration via Configuration Management
The LTE1457: Cell trace Configuration via Configuration Management feature allows the operator to configure the cell trace using NetAct Configuration Management (CM) and the BTS Site Manager. This solution is an alternative to the existing method using NetAct TraceViewer application.
For more details, see LTE1457: Cell trace Configuration via Configuration Management.
3.2.1.9 LTE1687: Basic Layer3 Data Analyzer (L3DA) for LTE
The LTE1687: Basic Layer3 Data Analyzer (L3DA) for LTE feature introduces the Layer 3 Data Analyzer (L3DA), which is a tool for analyzing Flexi Multiradio BTS trace data. The LTE L3DA allows the operator to visualize and analyze the cell trace data collected in the L3 Data Collector (L3DC).
For more details, see LTE1687: Basic Layer3 Data Analyser (L3DA) for LTE.
3.2.2 Cell trace content
Cell trace data consists of: • S1 Interface: S1AP data
– context management – handover signaling
– E-RAB management – NAS transport – location reporting – error indication • X2 Interface: X2AP data – basic X2 mobility – error indication • Uu Interface: RRC data – RRC connection signaling – counter check – inter-RAT mobility – measurements – UE capability – UL/DL information transfer
g
Note: The user plane is not traced.3.2.3 Activating cell trace in BTS Site Manager
This procedure shows how to activate the LTE433: Cell Trace feature using the BTS Site Manager.
Before you start
g
Note: To activate the feature on a wider scale, create a plan using the NetAct Configurator.Procedure
1 Set the LNBTS: Activate cell trace parameter to true. During commisioning
• go to the Radio Network Configuration page • expand MRBTS object
• select LNBTS object
• set Activate cell trace parameter to true
To activate other trace-related features, set the following parameter values to true: • LNBTS: Activate cell trace with IMSI
• LNBTS: Activate MDT cell trace
2 Create an MTRACE object. To create MTRACE object: • expand LNBTS object • right click CTRLTS object and creat new MTRACE object The CRTLTS object contains the basic trace parameters. Every active cell trace session equals one MTRACE object.
3 Configure the MTRACE object parameters.
To view the cell trace data in another tool than the NetAct, put the appropriate address in MTRACE:Trace collection entity IP address.
4 Set TA tracing to true. • MTRACE object
• select Cell vendor specific tracing object • set Cell TA tracing to true
The Timing Advance information is useful for troubleshooting.
Result
The cell trace data can be viewed with the NetAct Traceviewer, L3DA, or Traffica.
3.2.4 Viewing and analyzing cell trace data using L3DA
The following procedure shows how to use the L3DA application. Purpose The cell trace analysis platform consists of the following features: • LTE1340: Trace-based Real Time Monitoring Introduction of the L3 Data Collector (L3DC) and the function of sending cell trace data to Traffica • LTE1687: Basic Layer3 Data Analyzer (L3DA) Introduction of the L3 analysis function • LTE1909: BTS Diagnostics Toolkit A set of events for snapshot triggering Typical call processing problems analyzed using the L3DA: • call setup problems • call drops • handover failures
Before you start
To collect the cell trace data, the LTE433: Cell Trace feature needs to be configured.
Procedure
1 Start the cell trace.
To view the traces in L3DA, the L3DC IP address needs to be included in the cell trace configuration. The cell trace configuration is done with the BTS Site Manager or the TraceViewer application. The L3DC needs to be selected as the Trace Collection Entity during the cell trace configuration (the L3DC’s IP address put as the
tceIpAddress parameter value). 2 Open the L3DA.
To manage sacks and profiles, go to Environment > Change sack and profile (SCREEN). Select the one you need and click Load. To configure your log paths (and other preferences) go to Tools > Options.
3 Identify problematic calls by checking the ‘Out cause’ column.
Every call scenario is displayed in one row. They can be grouped by clicking on one of the columns in the main window (move the cursor on the column to see its description). The grouping helps to locate common root causes for failed events. Columns useful for troubleshooting: • Out Cause Examples of abnormal call releases: – No UE Reply – No EPC Messages – No UE Messages – Radiolink Failure – Re-est Reject • Failure Phase Examples: – RAB Active – RAB Setup – RAB Access – RRC Active – RRC Access – Source S1 HO Setup – Target S1 HO Access • Missing Reply Examples: – RachPreamble – InitialUEMessage – rrcConnectionSetup
– securityModeCommand • UE Distance
• HO Attempts
4 To view the scenario details right-click on the selected row and choose Trace View or Message view.
The Trace view shows the scenario in an L3 view, sequence view, or message view.
3.2.5 Tracing with NetAct
The NetAct Traceviewer application allows the user to activate and configure tracing. For information on available tools and functions, refer to the NetAct operating documentation: • TraceViewer Overview • Tracing Subscribers and Equipment
3.3 IP traffic capturing
The capturing of IP traffic is possible as a result of the LTE1460 feature. Introduction to the featureThe LTE1460: Local and Remote IP Traffic Capturing feature enables Nokia Technical Support, R&D personnel and as well customers' staff to capture the IP traffic of an eNB and fetch it for later offline root-cause analysis. With this feature it is possible to: • capture ingress and egress IP traffic such as C-plane, U-plane, M-plane or S-plane traffic • Web interface for configuration and capture file retrieval, Layer 3 internal measurement points can be selected and U-plane can be excluded to maximize capturing duration. • For local use, trace is streamed to configurable TRS port or LMP. For remote use libpcap file is created, compressed and downloaded by user. • allows capturing and storage (compressed libpcap file) of at least 60 s of single UE peak data • IPv6 capturing is supported
3.3.1 Monitoring IP traffic using the LTE1460: Local and Remote
IP Traffic Capturing feature
The following procedure shows how to capture the IP traffic using the BTS web interface. Before you start
To monitor the IP traffic online, an interface analyzer (for example, Wireshark) needs to be configured.
Procedure
1 Login to the BTS Web interface.
In any web browser enter the m-plane IP address of the BTS (https://BTS_M-PLANE_ADDRESS)
2 Select Tools > Local and Remote IP Traffic Capturing Service
Figure 16 Local and Remote IP Traffic Capturing Service window
3 Select the measurement point for IP traffic capturing. • Point A is located before the IPsec gateway • Point B is located after the IPsec gateway (the ciphered protocols need to be decoded)
g
Note: Capturing at point B is useful when you suspect that the IPSec gateway is not working properly.g
Note: Capturing at point B makes sense if you suspect problems at the IPSec gateway (compare files taken from A and B). Capturing at point B with Wireshark - need additional decoders to see all information.4 Decide whether the user plane should be captured.
g
Note: The user plane should be included to troubleshoot backhaul IP problems. 5 Select the Streaming (local) or File (remote) capturing output option.After selecting Streaming, you need to provide the destination MAC Address of the machine you want to see the result on. The File option will generate a pcap log file that can be opened for analysis with protocol analyzer (for example, Wireshark).
6 Optionally, provide a password for the capture file encryption.
7 Click the GEN&DOWNLOAD_PCAP button to start the IP traffic capturing. a) BTS deletes the content of the capturing history data structure.
b) BTS raises the 7665 Base station Transmission Alarm alarm to indicate that the IP traffic capturing is ongoing. c) BTS starts the IP traffic capturing.
g
Note: The BTS stops the IP traffic capturing after a timeout of 24 hours has been reached. Result The IP capturing is visible in the protocol analyzer (Streaming mode) or the pcap file is stored in the eNB (File mode).3.3.2 Analyzing IP capture files with Wireshark
The following procedure shows how to use the Wireshark application to analyze IP traffic. Purpose Protocol analyzers such as Wireshark can be used for troubleshooting the following symptoms: • lost packets • transmission delays • low throughput Before you start
The IP capturing has been initiated and the pcap file is available.
1 Open the generated pcap file using Wireshark. Figure 17 IP capture file in Wireshark
In the main view, the potential problems are highlighted with different colors (for example, errors have been highlighted in red).
2 Go to Analyze -> Expert Info . Figure 18 Expert Info view in Wireshark
This view shows a summary of all errors detected in the analyzed file.
3 Use the Packet Details view to map the packets with certain Network Elements (NEs) and User Equipments (UEs).
The IP addresses are available in the protocol view. The TEID identifier or the source and destination addresses can be used to locate certain NEs and UEs.
3.4 Sending troubleshooting data to technical support
This is an overview of best practices when contacting Nokia technical support.Details to be included in a problem report
Problem reports are used to communicate problems and failures to customer support team. Report only one fault in one problem report. Include the attachments in the compressed format. To make the investigation of a problem faster, include the following information in the problem report: • a title that gives a brief description of the problem (see Problems and use cases) • a clear and exact description of the problem itself • problem background information: – software and hardware releases – situation in the beginning, for example, the first symptoms of the problem – situation after the problem occurred – operations you made which possibly caused the failure, for example: hardware, software, parameter, feature or configuration changes, including operations in transport network and third party equipment – describe if the problem can be reproduced and what actions are required to reproduce this problem – troubleshooting and recovery actions that you made • additional problem specific symptom data • detailed information on the other third party products (in case of a multivendor environment) • the scale of the problem using Nokia Case Types and Nokia Problem Priorities (see tables below) Table 13 Nokia Case Types
Case type Definition Available problem priorities Emergency Concerns total and partial outages. Total outage: total loss of voice and data traffic capability. An unscheduled event must be longer than 15 seconds. Partial outage: Loss of greater than 10% of the provisioned capacity for origination and/or termination of voice and/or data traffic. Total loss of one or Critical
Table 13 Nokia Case Types (Cont.)
Case type Definition Available problem priorities more critical services. An unscheduled event must be longer than 15 seconds. Trouble Resolution This case type is for problems which caused by a suspected or an identified defect. Major, Medium, and Minor Technical Query This case type is for technical questions regarding daily network operations and maintenance issues. Major and Medium Table 14 Nokia Problem Priorities
Problem Priority Definition
Critical Problems under Emergency Support service. Major Only Total or Partial outages which are not avoidable with a workaround solution. Medium Total or Partial outages avoidable with a workaround solution. Partial loss of one or more critical services. Minor Minor fault not affecting operation or service quality.
3.5 Problems and use cases
The most common problems can be divided into several use case categories. When the data that has been collected is used to create a problem report for Nokia Services, it is recommended to use unified naming. Table 15: LTE use cases lists and explains the most common use cases. For several use cases, you can find a troubleshooting methodology in LTE troubleshooting use cases. Table 15 LTE use cases
Use case category Exemplary symptoms
Tools/Site Manager connection problems Problems with connecting the BTS Site Manager, BTSLog, L3DC via remote IP address or LMP to the BTS. Software download/activation problems Software download/activation fails when started from the NetAct/Site Manager or software fallback fails when performed as a recovery action. (Re)commissioning problems Problems with starting or finishing (re)commissioning. Missing commissioning parameters, missing units, or unplanned resets.