commissioning and installtion guide huaw copy

22 Debugging with gdb

3.3 Getting Help

You can always ask gdb itself for information on its commands, using the command help.

helph You can use help (abbreviated h) with no arguments to display a short list of

named classes of commands:

(gdb) helpList of classes of commands:

aliases -- Aliases of other commandsbreakpoints -- Making program stop at certain pointsdata -- Examining datafiles -- Specifying and examining filesinternals -- Maintenance commandsobscure -- Obscure featuresrunning -- Running the programstack -- Examining the stackstatus -- Status inquiriessupport -- Support facilitiestracepoints -- Tracing of program execution without

stopping the programuser-defined -- User-defined commands

Type "help" followed by a class name for a list ofcommands in that class.Type "help" followed by command name for fulldocumentation.Command name abbreviations are allowed if unambiguous.(gdb)

help classUsing one of the general help classes as an argument, you can get a list of theindividual commands in that class. For example, here is the help display forthe class status:

(gdb) help statusStatus inquiries.

List of commands:

info -- Generic command for showing thingsabout the program being debugged

show -- Generic command for showing thingsabout the debugger

Type "help" followed by command name for fulldocumentation.Command name abbreviations are allowed if unambiguous.(gdb)

help commandWith a command name as help argument, gdb displays a short paragraph onhow to use that command.

BSC6900 GSMV900R012C01

Commissioning Guide

Issue 06

Date 2011-05-19

HUAWEI TECHNOLOGIES CO., LTD.

Debugging with gdb

The gnu Source-Level Debugger

Tenth Edition, for gdb version 7.10.50.20151203-cvs

(GDB)

Richard Stallman, Roland Pesch, Stan Shebs, et al.

Copyright © Huawei Technologies Co., Ltd. 2011. All rights reserved.No part of this document may be reproduced or transmitted in any form or by any means without prior writtenconsent of Huawei Technologies Co., Ltd. Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.All other trademarks and trade names mentioned in this document are the property of their respective holders. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,and recommendations in this document are provided "AS IS" without warranties, guarantees or representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 06 (2011-05-19) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[email protected]

About This Document

OverviewBSC6900 commissioning is performed after the hardware is installed and before the servicesare provided. It aims to ensure that the BSC6900 can work properly by performing verificationtasks related to equipment, BSC6900 board software and data file loading, interfaces, andservices.

This document provides guidelines for commissioning the BSC6900. It includes the followingcontents: Verifying the Operation and Maintenance Unit (OMU), Activating and Verifying theLicense, Loading the BSC6900 Board Software and Data Files, Connecting the BSC6900 to theM2000, and Verifying the Interfaces and Services.

Product VersionThe following table lists the product version related to this document.

Product Name Product Version

BSC6900 V900R012C01

Intended AudienceThis document is intended for field engineers.

Organization1 Changes in the BSC6900 GSM Commissioning Guide

This chapter describes the changes in the BSC6900 GSM Commissioning Guide.

2 Prerequisites for Commissioning

Before the BSC6900 commissioning, the status of the equipment and the network to becommissioned must meet the conditions required. The software installation package, license,and MML command scripts required for commissioning must be ready.

3 Commissioning Process

BSC6900 GSMCommissioning Guide About This Document


iii

The BSC6900 commissioning can be performed remotely or locally. Remote commissioning isperformed by the remote engineer (technical owner of the BSC) and multiple BSCs can becommissioned simultaneously in the central equipment room. Local commissioning isperformed by the site engineer (commissioning owner in the BSC equipment room) whoconnects a PC to the BSC and performs the commissioning through the LMT. There is alsoanother commissioning mode: remote commissioning through local assistance, which isperformed by both the remote engineer and the site engineer.

4 Checking Operating Status of Hardware

Before verifying the equipment, ensure that the cabinet is powered on and operates normally.

5 Verifying the OMU

This section describes how to verify the OMU to enable the normal communication between theLMT and the BSC6900. The OMU verification involves installing the OMU operating systemand OMU application, checking the OMU operation status, and changing the external fixed IPaddress and external virtual IP address of the OMU on site.

6 Logging in to the BSC6900 Through the LMT

This section describes how to log in to the BSC6900 through the LMT and enable the normalcommunication. LMT verification ensures the BSC6900 commissioning through the LMT.

7 Updating the OMU Database

This describes how to update configuration data in the OMU database by running MMLcommands.

8 Activating and Verifying the License

This chapter describes how to activate the license and verify the licensed configurationinformation to enable service checking.

9 Loading BSC6900 Board Software and Data Files

This chapter describes how to load the BSC6900 board software and data files to enable thenormal operation of the BSC6900.

10 Connecting the BSC6900 to the M2000

This chapter describes how to connect the BSC6900 to the M2000 for the centralizedmanagement.

11 Verifying Interfaces

This section describes how to verify interfaces. The interfaces to be verified are Abis, A, Gb,Ater, Pb, and Lb interfaces. The Ater interface verification is mandatory in BM/TC separatedmode; the Pb interface verification is mandatory when the external PCU is used on the BSC6900;the Lb interface verification is mandatory when the external SMLC is used on the BSC6900.

12 Handling the Alarms Generated During the Commissioning

This chapter describes how to handle the alarms generated during the commissioning, thuspreventing the alarms from affecting the verification of services.

13 Verifying the GSM Services

This chapter describes how to verify that the GSM basic services and the feature services thatare enabled are normal. The basic services consist of speech service and data service. The featureservices consist of the inter-RAT handover, location service, and AMR service.

About This DocumentBSC6900 GSM

Commissioning Guide

iv Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 06 (2011-05-19)

(Send bugs and comments on gdb to http://www.gnu.org/software/gdb/bugs/.)Debugging with gdb

TEXinfo 2011-02-14.11

Published by the Free Software Foundation51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USAISBN 978-0-9831592-3-0

Copyright c� 1988-2015 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the termsof the GNU Free Documentation License, Version 1.3 or any later version published bythe Free Software Foundation; with the Invariant Sections being “Free Software” and “FreeSoftware Needs Free Documentation”, with the Front-Cover Texts being “A GNU Manual,”and with the Back-Cover Texts as in (a) below.

(a) The FSF’s Back-Cover Text is: “You are free to copy and modify this GNU Man-ual. Buying copies from GNU Press supports the FSF in developing GNU and promotingsoftware freedom.”

http://www.gnu.org/software/gdb/bugs/

11 Verifying Interfaces

About This Chapter

This section describes how to verify interfaces. The interfaces to be verified are Abis, A, Gb,Ater, Pb, and Lb interfaces. The Ater interface verification is mandatory in BM/TC separatedmode; the Pb interface verification is mandatory when the external PCU is used on the BSC6900;the Lb interface verification is mandatory when the external SMLC is used on the BSC6900.

ContextSelect a verification method according to the actual scenario.

11.1 Verifying Interfaces Through M2000This section describes how to verify interfaces through the maintenance mode and the NE healthcheck function of the M2000.

11.2 Verifying Interfaces Through LMTThis chapter describes how to verify interfaces on the BSC6900 through MML commands orGUI on the LMT. The interfaces to be verified are Abis, A, Gb, Ater, Pb, and Lb interfaces. TheAter interface verification is mandatory in BM/TC separated mode; the Pb interface verificationis mandatory when the external PCU is used on the BSC6900; the Lb interface verification ismandatory when the external SMLC is used on the BSC6900.

BSC6900 GSMCommissioning Guide 11 Verifying Interfaces


11-1

11.1 Verifying Interfaces Through M2000This section describes how to verify interfaces through the maintenance mode and the NE healthcheck function of the M2000.

11.1.1 Setting Maintenance Mode of NE to InstallDuring the commissioning, the NE may report many alarms that require no attention. You canshield these alarms by setting the maintenance mode of the NE to be in Install mode.

11.1.2 Verifying Interfaces AutomaticallyThis section describes how to verify the BSC6900 interfaces automatically through NE healthcheck on the M2000.

11.1.3 Setting the Maintenance Mode of the NE to NormalAfter the End Time of the maintenance mode, the NE enters the normal mode automatically.In addition, you can set the UE mode to Normal manually.

11.1.1 Setting Maintenance Mode of NE to InstallDuring the commissioning, the NE may report many alarms that require no attention. You canshield these alarms by setting the maintenance mode of the NE to be in Install mode.

Prerequisitel The BSC6900 and the peer equipment are physically connected, and the hardware

installation acceptance is passed.l All the subracks of the BSC6900 are running normally.l The BSC6900 is connected to the M2000 (for details, see 10 Connecting the BSC6900 to

the M2000).

Contextl Currently, four maintenance modes are provided on the M2000: Install, Expand,

Upgrade, and Testing. In the BSC6900 commissioning scenario, set the maintenance modeto Install.

l The maintenance modes are effective for the UE during Start Time and End Time. BeforeStart Time and after End Time, NEs are in the Normal mode. When NEs are in the Normalmode, alarms are reported normally.

l When the NE is restored to the Normal mode, the alarms that are not cleared when the NEis in the Install mode are reported to the M2000 as common alarms.

ProcedureStep 1 Set the maintenance mode of the NE to Install on the M2000 client. For details, see 15.8 Setting

Maintenance Mode for NE.

----End

11.1.2 Verifying Interfaces AutomaticallyThis section describes how to verify the BSC6900 interfaces automatically through NE healthcheck on the M2000.

11 Verifying InterfacesBSC6900 GSM

Commissioning Guide

11-2 Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

Issue 06 (2011-05-19)

Prerequisitel The BSC6900 and the peer equipment are physically connected, and the hardware

installation acceptance is passed.

l All the subracks of the BSC6900 are running normally.

l The BSC6900 is connected to the M2000 (see 10 Connecting the BSC6900 to theM2000 for details).

Context

The Lb interface and the internal interface should be verified through MML commands or GUIon the LMT, see 11.2.6 Verifying Lb Interface and 11.2.7 Verifying the InternalInterfaces for details.

Procedure

Step 1 Set the scenario for NE health check.

1. On the M2000 client, choose Maintenance > NE Health Check.

2. Click Scenario Management on the displayed tab page.

3. Click New in the displayed dialog box.

4. Enter the scenario name in the Scenario Name text box on the right of the dialog box.

NOTE

The scenario name must be different from existing scenario names.

5. Click the type of the NE for health check in NE Types, that is BSC6900 GSM.

6. Select the NEs for health check (deselect those not for health check) in the InterfaceCheck under Check Items.

7. Click OK. A dialog box is displayed, prompting that the NE health check scenario is setup successfully. Click OK to complete the setup of the NE health check scenario.

Step 2 Create the NE health check task.

1. On the NE Health Check tab page, click New. The Create Task dialog box is displayed.

2. Select the application scenario corresponding to the task that is currently created from theScenario drop-down list. The Name text box is automatically filled in with the textconsisting of the application scenario and the specific time (the time is accurate to thesecond) on which the task is created.

3. Select the NE for health check in under Select NE.

4. Select the option to kick off the task in under Time Setting. The options are as follows:

Operation Mode Description

Instant Click Next. The Time Setting dialog boxis displayed. Click Finish.NOTE

The setting of Time Setting is not requiredduring commissioning.



11-3

Operation Mode Description

Scheduled Set the time for kicking off the task in theScheduled spin box. Click Next. SetHealth Check Period in the displayeddialog box, and then click Finish.

Periodic Click Next. Set Start Time, Period, andRun Times, and then click Finish.

NOTE

The executed health check tasks are listed under the Finished Tasks node on the navigation tree on theleft of the NE Health Check tab page.

Step 3 View the result of the NE health check.1. Under the Finished Tasks node of the navigation tree, click the executed task. Right-click

the corresponding task on the right and then click View Report from the shortcut menu.2. In the displayed Health Check Report dialog box, click the HTML Format tab or DOC

Format tab to view the report.

If... Then...

You selected the HTMLFormat,

Select the report from the report list, and then viewthe report in one of the following ways:l Click Open to directly open the report in HTML

format.l Click Save As, and then select the path for saving

the report in the displayed Save dialog box to savethe report in HTML format.

You selected DOC Format, Click Save As, and then select the path for saving thereport in the displayed Save dialog box to save thereport in Word format.

NOTE

The health check report is compressed to a zip file. To view the report, double-click the .zip file, andthen double-click the report file “index.html” in the zip file browser.

If some items in the health check report are in red, the corresponding interface is faulty. Rectify thefault by referring to the health check report.

----End

11.1.3 Setting the Maintenance Mode of the NE to NormalAfter the End Time of the maintenance mode, the NE enters the normal mode automatically.In addition, you can set the UE mode to Normal manually.


Commissioning Guide


Issue 06 (2011-05-19)

Prerequisitel The BSC6900 is connected to the M2000 (see 10 Connecting the BSC6900 to the

M2000 for details).l Before verifying interfaces, set the maintenance mode for the NE by referring to 11.1.1

Setting Maintenance Mode of NE to Install.l The BSC6900 has passed the commissioning.

Procedure

Step 1 Set the maintenance mode of the NE to Normal on the M2000 client. For details, see 15.8 SettingMaintenance Mode for NE.

----End

11.2 Verifying Interfaces Through LMTThis chapter describes how to verify interfaces on the BSC6900 through MML commands orGUI on the LMT. The interfaces to be verified are Abis, A, Gb, Ater, Pb, and Lb interfaces. TheAter interface verification is mandatory in BM/TC separated mode; the Pb interface verificationis mandatory when the external PCU is used on the BSC6900; the Lb interface verification ismandatory when the external SMLC is used on the BSC6900.

ContextDuring the interface verification, you can run the LST command to view the configurationinformation. For example, before running the MML command DSP ADJNODE, you can runthe MML command LST ADJNODE to check the parameter Adjacent Node ID.

11.2.1 Verifying the Abis InterfaceThis section describes how to verify the control plane and the user plane of the Abis interface.The Abis interface verification varies according to the transmission mode over the Abis interface.

11.2.2 Verifying the A InterfaceThis section describes how to verify the control plane and the user plane of the A interface. TheA interface verification varies according to the transmission mode of the A interface.

11.2.3 Verifying the Gb InterfaceThis section describes how to verify the Gb interface. The Gb interface verification variesaccording to the transmission mode over the Gb interface.

11.2.4 Verifying the Ater InterfaceThis section describes how to verify the Ater interface when the BSC6900 is in BM/TC separatedmode.

11.2.5 Verifying the Pb InterfaceIf the BSC6900 is configured with an external PCU, Pb interface verification is needed.

11.2.6 Verifying Lb InterfaceThis section describes how to verify the Lb interface. Both E1/T1 transmission and FE/GEtransmission can be applied on the Lb interface. When E1/T1 transmission is applied, the datalink layer adopts TDM transmission. When FE/GE transmission is applied, the data link layeradopts IP transmission.

11.2.7 Verifying the Internal Interfaces



11-5

This describes how to verify the link status of the ports on the TNUa and SCUa boards.

11.2.1 Verifying the Abis InterfaceThis section describes how to verify the control plane and the user plane of the Abis interface.The Abis interface verification varies according to the transmission mode over the Abis interface.

Prerequisitel The BSC6900 and the base stations are physically connected, and the hardware installation

acceptance is passed.l The base stations used to verify the Abis interface are commissioned and the cell

configuration is complete.l All the subracks of the BSC6900 are running normally.l You have logged in to the BSC6900 through the LMT.

ContextFor the commissioning of the base station, see the commissioning guide of the base station.

The following takes one base station as an example to describe the commissioning process onthe Abis interface. If multiple base stations are connected, repeat the operations.

There are two ways to verify the Abis interface (Abis over TDM): through GUI or through MML.You can choose either way according to your convenience.

Procedurel To verify the Abis interface (Abis over TDM) through GUI, see Verifying the Abis Interface

(Abis over TDM) Through GUI.l Verifying the Abis interface (Abis over TDM) through MML

1. Run the MML command DSP LAPDLNK to check whether the Link Access Protocolon the D channel (LAPD) link on the Abis interface is normal.

Expected result: The value of UsageStatus is Normal.

If the status of LAPD links on the Abis interface is abnormal, check the transmissionlink by referring to 15.1 Checking the Transmission Link.

2. Run the MML command DSP ABISTS to query the timeslot status of the Abisinterface.

Expected result: The State of many timeslots is Idle, and there is no timeslot with theState of Failure.

If the status of timeslots on the Abis interface is abnormal, check the transmission linkby referring to 15.1 Checking the Transmission Link.

NOTETo query the Subrack No., Slot No., and Port No. of the timeslots to be verified, run the MMLcommand LST BTSCONNECT.

3. Run the MML command DSP BTSSTAT to query the status of cells and channels.

Expected result: The value of Cell Initialized is Yes and the value of ChannelFault is No.


Commissioning Guide


Issue 06 (2011-05-19)

If the value of Cell Initialized is No, see ALM-21801 GSM Cell out of Service fortroubleshooting; if the value of Cell Initialized is Yes but the value of ChannelFault is Yes, check the alarms related to the TRX and rectify the fault according tothe alarm handling suggestion.

l Verifying the Abis interface (Abis over IP)1. Run the MML command DSP LAPDLNK to check whether the LAPD link on the

Abis interface is normal.



2. Run the MML command DSP ADJNODE to query the status of the adjacent node.

Expected result: The values of available bandwidth are not all 0.

If the values of available bandwidth are all 0, see EVT-22918 Change of TransportResource State for Adjacent Node User Plane for troubleshooting.

3. Run the MML command DSP IPPATH to query the status of the IP path on the Abisinterface.

Expected result: The value of Operation state is Available.

If the value of Operation state is Unavailable, see 15.4 IP Connection SetupFailure for troubleshooting.

4. Run the MML command DSP BTSSTAT to query the status of the cells and channels.



l Verifying the Abis interface (Abis over HDLC)1. Run the MML command DSP LAPDLNK to check whether the LAPD link on the

Abis interface is normal.



2. Run the MML command DSP HDLCLNK to query the status of the HDLC link.

Expected result: The value of operation state is Available and the value of AvailableTx Bandwidth or Available Rx Bandwidth is not 0.


NOTETo query the number of the HDLC link to be verified, run the MML command LSTBTSABISHDLCPATH.

3. Run the MML command DSP BTSSTAT to query the status of the cells and channels.



11-7



----End

11.2.2 Verifying the A InterfaceThis section describes how to verify the control plane and the user plane of the A interface. TheA interface verification varies according to the transmission mode of the A interface.

Prerequisitel The BSC6900 and the MSC are physically connected.l The MSC used to verify the A interface operates normally.l The Ater interface has been verified when the BSC6900 is in BM/TC separated mode.l All the subracks of the BSC6900 are running normally.l You have logged in to the BSC6900 through the LMT.

ContextThere are two ways to verify the A interface (A over TDM): through GUI or through MML.You can choose either way according to your convenience.

Procedurel To verify the A interface (A over TDM) through GUI, see Verifying the A Interface (A

over TDM) Through GUI.l Verifying the A interface (A over TDM) through MML

1. Run the MML command DSP MTP2LNK to query the status of the Message TransferPart Level 2 (MTP2) signaling link.

Expected result: The value of Link State is IN SERVICE.

If the value of Link State is OUT OF SERVICE, check the transmission links byreferring to 15.1 Checking the Transmission Link.

2. Run the MML command DSP MTP3LNK to query the status of the Message TransferPart Level 3 (MTP3) signaling link.


If the value of Operation state is Unavailable, see ALM-21506 MTP3 SignalingLink Faulty for troubleshooting.

3. Run the MML command DSP SSN to query the status of the SCCP SSN.

Expected result: The value of SSN state is Allowed.

If the value of SSN state is Prohibited, see ALM-21521 SCCP Subsystem Prohibitedfor troubleshooting.


Commissioning Guide


Issue 06 (2011-05-19)

4. Run the MML command DSP N7DPC to query the status of the SS7 destinationsignaling point.

Expected result: The value of SCCP DSP state is Accessible.

If the value of SCCP DSP state is not normal, see ALM-21521 SCCP SubsystemProhibited for troubleshooting.

5. Run the MML command DSP ACIC to query the status of A interface circuits.

Expected result: The CIC State of many CICs is Idle, and there is no CIC with theCIC State of Failure.

If the value of CIC State is Failure, check the transmission links by referring to 15.1Checking the Transmission Link.

NOTETo query the OPC Index and DPC Group Index of the E1/T1 to be verified on the A interface, runthe MML command LST AE1T1.

l Verifying the A interface (A over IP)

1. Run the MML command DSP SCTPLNK to query the status of the Stream ControlTransmission Protocol (SCTP) link.

Expected result: The value of SCTP link Operation state is Normal.

If the value of Operation state is Unavailable, check the transmission links byreferring to 15.1 Checking the Transmission Link.

NOTE

Run the MML command DSP SCTPLNK for two or three times, if the value of Operation stateis always Normal and the value of State Changed Time does not change, you can infer that theSCTP link is normal without intermittent disconnection.

2. Run the MML command DSP M3LNK to query the status of the MTP3 User AdaptionLayer (M3UA) signaling link.

Expected result: The value of Operation state is Activated state.

If the value of Operation state is not normal, see ALM-21506 MTP3 Signaling LinkFaulty for troubleshooting.

3. Run the MML command DSP SSN to query the status of the SCCP SSN.

Expected result: The value of SSN state is Allowed.

If the value of SSN state is Prohibited, see ALM-21521 SCCP Subsystem Prohibitedfor troubleshooting.

4. Run the MML command DSP N7DPC to query the status of the SS7 destinationsignaling point.

Expected result: The value of SCCP DSP state is Accessible.

If the value of SCCP DSP state is not normal, see ALM-21521 SCCP SubsystemProhibited for troubleshooting.

5. Run the MML command DSP ADJNODE to query the status of the adjacent node.

Expected result: The values of available bandwidth are not all 0.



11-9

If the values of available bandwidth are all 0, see EVT-22918 Change of TransportResource State for Adjacent Node User Plane for troubleshooting.

6. Run the MML command DSP IPPATH to query the status of the IP path.


If the value of Operation state is Unavailable, see 15.4 IP Connection SetupFailure for troubleshooting.

----End

11.2.3 Verifying the Gb InterfaceThis section describes how to verify the Gb interface. The Gb interface verification variesaccording to the transmission mode over the Gb interface.

Prerequisitel The BSC6900 and the SGSN are physically connected, and the hardware installation

acceptance is passed.l The SGSN equipment used to verify the Gb interface operates normally.l All the subracks of the BSC6900 are running normally.l You have logged in to the BSC6900 through the LMT.

Procedurel Verifying the Gb interface links (Gb over FR)

1. Run the MML command DSP BC to query the status of the Bearer Channel (BC) tobe verified.

Expected result: The value of BC Service State is available.

If the value of BC Administration State is Blocked, run the MML command UBLBC to unblock the BC, and then run the MML command DSP BC to check whetherthe BC status is normal. If the status remains abnormal, check the transmission linksby referring to 15.1 Checking the Transmission Link.

2. Run the MML command DSP NSVC to query the status of the Network ServiceVirtual Connection (NSVC) to be verified.

Expected result: The value of NSVC Service State is Active Unblock.

If the value of Service State is not normal, see the "Follow-up procedure" fortroubleshooting.

3. Run the MML command DSP SIGBVC to query the SIG BSSGP Virtual Connection(SIGBVC) status of the Network Service Entity (NSE) to be verified.

Expected result: The value of SIG BVC State is Normal.

If the value of SIG BVC State is Fault, the SGSN may be configured with an NSEthat has a different NSE ID.

NOTETo query the configuration of the NSE to be verified, run the MML command LST NSE.

4. Run the MML command DSP PTPBVC to query the status of the PTP BSSGP VirtualConnection (PTPBVC) of the NSE to be verified.


Commissioning Guide


Issue 06 (2011-05-19)

Expected result: The value of Service State is Normal.

If the value of Service State is not normal, see the Postrequisites below fortroubleshooting.

l Verifying the Gb interface links (Gb over IP)1. Run the MML command DSP NSVL to query the status of the Network Service

Virtual Link (NSVL) to be verified.

Expected result: The value of NSVL State is Normal.

If the value of NSVL State is Fault, check the transmission links by referring to 15.1Checking the Transmission Link.

NOTETo query the configuration of the local or remote NSVL to be verified, run the MML commandLST NSVLLOCAL or LST NSVLREMOTE.

2. Run the MML command DSP GBIPROUTE to query the status of the IP connectionto be verified on the Gb interface.

Expected result: The value of State is Normal .

If the value of State is Faulty, run the MML command DSP IPRT to check whetherthe route configuration on the Gb interface is correct.

3. Run the MML command DSP SIGBVC to query the SIGBVC status of the NSE tobe verified.

Expected result: The value of SIG BVC State is Normal.

If the value of SIG BVC State is Fault, the SGSN may be configured with an NSEthat has a different NSE ID.

NOTETo query the configuration of the NSE to be verified, run the MML command LST NSE.

4. Run the MML command DSP PTPBVC to query the PTPBVC status of the NSE tobe verified.

Expected result: The value of Service State is Normal.

If the value of Service State is not normal, see the Postrequisites below fortroubleshooting.

----End

Follow-up Procedure

Handling Suggestions to Exceptional NSVC Status

l If the value of NSVC Manage State is Unblock and the NSVC Service State is ActiveBlock, you can infer that the FR link that bears the NSVC is functional and that the NSVCis blocked by the SGSN.

l If the value of NSVC Manage State is Block and the NSVC Service State is ActiveBlock, you can infer that the FR link that bears the NSVC is functional and that the NSVCis blocked by the BSC6900 or by both the BSC6900 and the SGSN.

1. Run the MML command UBL NSVC to unblock the BSC6900.



11-11

2. Run the MML command DSP NSVC to query the status of the NSVC. If the value ofNSVC Service State is still Active Block, you can infer that the NSVC is blocked bythe SGSN.

l If the value of NSVC Service State is Deactive Block, the possible causes are as follows:

– The NSVC ID and NSE ID of the NSVC on the BSC6900 are inconsistent with that onthe SGSN.

– The NSVC configured on the same BC at the SGSN is not the required one.

Handling Suggestions to Exceptional PTPBVC Service Status

1. If the value of PTPBVC Manage State is Block, run the MML command UBLPTPBVC to unblock the PTPBVC, and then run the MML command DSP PTPBVC toquery the status of the PTPBVC. If the status remains abnormal, go to step 2.

2. Run the MML command RST PTPBVC to reset the PTPBVC, and then run the MMLcommand DSP PTPBVC to query the status of the PTPBVC. If the status remainsabnormal, go to step 3.

3. Run the MML command RST PSCELL to reset the cell corresponding to the exceptionalPTPBVC, and then run the MML command DSP PTPBVC to query the status of thePTPBVC. If the status remains abnormal, go to step 4.

4. Run the MML command RST SIGBVC to reset the SIGBVC corresponding to theexceptional PTPBVC, and then run the MML command DSP PTPBVC to query the statusof the PTPBVC. If the status remains abnormal, contact the Huawei Customer ServiceCenter by referring to Contact the Huawei Customer Service Center.

11.2.4 Verifying the Ater InterfaceThis section describes how to verify the Ater interface when the BSC6900 is in BM/TC separatedmode.

Prerequisitel The MPS/EPS and the TCS are physically connected.l The data configuration on the Ater interface is complete.l The TCS is loaded and started.l You have logged in to the BSC6900 through the LMT.

Context

There are two ways to verify the Ater interface: through GUI or through MML. You can chooseeither way according to your convenience.

Procedurel To verify the Ater interface through GUI, see Verifying the Ater Interface Through GUI.l Verifying the Ater Interface through MML

1. Run the MML command DSP ATERTS to query the status of timeslots on the Aterinterface.

Expected result: The State of many timeslots is Idle, and there is no timeslot with theState of Failure.


Commissioning Guide


Issue 06 (2011-05-19)

If the State of a timeslot is Failure, check the transmission links by referring to 15.1Checking the Transmission Link.

NOTETo query the Ater connection path index and ID of BSC in TC Pool of the E1/T1 to be verifiedon the Ater interface, run the MML command LST ATERE1T1.

2. Optional: If the TCS is configured remotely, run the MML command DSPATERSL to query whether the Ater signaling link is normal.


If the value of UsageStatus is Faulty, check the transmission links by referring to15.1 Checking the Transmission Link.

----End

11.2.5 Verifying the Pb InterfaceIf the BSC6900 is configured with an external PCU, Pb interface verification is needed.

Prerequisitel The PCU used to verify the Pb interface operates normally.l The BSC6900 and the PCU are physically connected, and the hardware installation

acceptance is passed.l All the subracks of the BSC6900 are running normally.l You have logged in to the BSC6900 through the LMT.

Procedure

Step 1 Run the MML command DSP LAPDLNK to check whether the LAPD link on the Pb interfaceis normal.


If the status of LAPD links on the Pb interface is abnormal, check the transmission link byreferring to 15.1 Checking the Transmission Link.

Step 2 Run the MML command DSP PBCIC to query the status of the circuit on the Pb interface.

Expected result: The status of many circuit identity codes (CICs) is Idle, and there is no CICwith the status of Failure.

If the status of a CIC is Failure, check the transmission links by referring to 15.1 Checking theTransmission Link.

NOTETo query the E1/T1 configuration information to be verified on the Pb interface, run the MML command LSTPBE1T1.

----End

11.2.6 Verifying Lb InterfaceThis section describes how to verify the Lb interface. Both E1/T1 transmission and FE/GEtransmission can be applied on the Lb interface. When E1/T1 transmission is applied, the data



11-13

link layer adopts TDM transmission. When FE/GE transmission is applied, the data link layeradopts IP transmission.

Prerequisitel The BSC and the Serving Mobile Location Center (SMLC) are physically connected.l The SMLC that is used to verify the Lb interface operates normally.l All the subracks of the BSC6900 are running normally.l You have logged in to the BSC6900 through the LMT.

ContextThere is no dedicated interface board for the Lb interface. The data link layer of the Lb interfacecan be carried on the Abis interface board, A interface board, or Ater interface board.

Procedurel When the data link layer of the Lb interface is carried on the Abis interface board, verify

the Lb interface in the same way as for the Abis interface. For details, see 11.2.1 Verifyingthe Abis Interface.

l When the data link layer of the Lb interface is carried on the A interface board, verify theLb interface in the same way as for the A interface. For details, see 11.2.2 Verifying theA Interface.

l When the data link layer of the Lb interface is carried on the Ater interface board, verifythe Lb interface in the same way as for the Lb interface. For details, see 11.2.4 Verifyingthe Ater Interface.

----End

11.2.7 Verifying the Internal InterfacesThis describes how to verify the link status of the ports on the TNUa and SCUa boards.

Prerequisitel The inter-TNUa cables and inter-SCUa cables of the BSC6900 are installed.l All the subracks of the BSC6900 are running normally.l You have logged in to the BSC6900 through the LMT.

Procedure

Step 1 Run the MML command DSP LINKBTNUTNU to query the link status of the ports on theTNUa boards.

Expected result: The value of Link Status is Normal.

If the value of Link Status is Failure, re-install the inter-TNUa cables as required in the returnedresult by referring to Installing the Inter-TNUa Cables.

Step 2 Run the MML command DSP PANELPORT to query the link status of the ports on the SCUaboards.

Expected result: The actual link status of the ports on the SCUa boards are displayed in thereturned result.


Commissioning Guide


Issue 06 (2011-05-19)

If the link status in the returned result does not meet the installation requirements, re-install theinter-SCUa cables by referring to Installing the Inter-SCUa Cables Between Different Subracks.

----End



11-15

12 Handling the Alarms Generated Duringthe Commissioning

This chapter describes how to handle the alarms generated during the commissioning, thuspreventing the alarms from affecting the verification of services.

Prerequisitel The communication between the BSC6900 and the OMU is normal.l You have logged in to the BSC6900 through the LMT.

Procedure

Step 1 Click the Alarm on the LMT main page. The Alarm tab page is displayed.

Step 2 Check whether alarms are listed on the Fault tab page.

If... Then...

No alarm is listed, End this task.

One or more alarms are listed, Go to step Step 3.

Step 3 Double-click the alarm to be handled in the fault tab page. The Detail dialog box is displayed.

Step 4 Click Solution.... The LMT Online Help interface is displayed.

Step 5 Follow the suggestions to handle the alarm.

Step 6 Repeat Step 3 to Step 5 to handle other alarms.

----End

BSC6900 GSMCommissioning Guide

12 Handling the Alarms Generated During theCommissioning


12-1

13 Verifying the GSM Services

This chapter describes how to verify that the GSM basic services and the feature services thatare enabled are normal. The basic services consist of speech service and data service. The featureservices consist of the inter-RAT handover, location service, and AMR service.

Prerequisitel The verification over the Abis, A, Gb, Ater, Pb, and Lb interfaces is successful. The

verification over Ater interface is mandatory only in BM/TC separated mode. Theverification over Pb interface is mandatory only if the BSC6900 is configured with anexternal PCU. The verification over Lb interface is mandatory only if the BSC6900 isconfigured with an external SMLC.

l The MSs used for test are functional and are registered in the HLR.

l You have logged in to the BSC6900 through the LMT.

Procedure

Step 1 Table 13-1 lists the procedure for verifying the basic services by testing the MS in the BTS cells.

Table 13-1 Performing dialing tests on the basic services

Basic Services Procedure for Conductingthe Dialing Test

Expected Result

Speech service Make 20 calls from an MS to afixed-line phone and hold on eachcall for 60 seconds.

The connection success rate ishigher than 90%. The voice isclear and without loud noise. Nocall drop occurs and the systemresources are released normallyafter the call is terminated.

Make 20 calls from a fixed-linephone to an MS and hold on eachcall for 60 seconds.


BSC6900 GSMCommissioning Guide 13 Verifying the GSM Services


13-1


Expected Result

Make 20 calls from an MS toanother MS and hold on each callfor 60 seconds.


Data service Send a fax from an MS to anelectrograph. Send a fax from anelectrograph to an MS.

Faxes are sent and receivednormally.

Test the General Packet RadioService (GPRS) or EnhancedData Rate for GSM Evolution(EDGE) function on the MS.

The test data rate is similar to thedata rate tested in a lab.

NOTEIf the result of service verification cannot meet the expected results, start message tracing on the LMT over theUm, Abis, A, Gb, Pb, and Ater interfaces. Where the message tracing over the Pb interface is mandatory onlywhen the BSC6900 is configured with an external PCU, and the message tracing over the Ater interface ismandatory only in BM/TC separated mode.

Step 2 Table 13-2 lists the procedure for verifying the feature services by testing the MS in the BTScells.

Table 13-2 Performing dialing tests on the feature services

Feature Services Procedure for Conductingthe Dialing Test

Expected Result

Inter-RAT handover Hand over a dual-mode MS fromthe GSM to the UMTS for 20times. Hand over a dual-modeMS from the UMTS to the GSMfor 20 times.

The connection success rate ishigher than 90%. The voice isclear and without loud noise.

Location service Make a call from the MS and holdon the call. Then, locate the MS.

The location of the MS conformsto the precision requirements.

Adaptive Multi Rate(AMR) service

Make 50 calls from an MS to afixed-line phone and select voiceversion to AMR.

The connection success rate ishigher than 90%. The voice isclear and without loud noise.

----End

13 Verifying the GSM ServicesBSC6900 GSM

Commissioning Guide


Issue 06 (2011-05-19)

14 Verifying Network Reliability

The network reliability is verified by alarm checks and dialing tests after the active/standbyswitchover of boards.

Prerequisitel The standby board for the switchover operates normally.l All the subracks of the BSC6900 are running normally.l You have logged in to the BSC6900 through the LMT.l The alarms generated before the switchover have been cleared.

Procedure

Step 1 Switch over the active/standby boards. For details, see Switching Over the BSC Boards.

Step 2 Check and handle the alarms generated during the active/standby switchover. For details, see12 Handling the Alarms Generated During the Commissioning.

Step 3 Use an MS in a cell under the BTS to perform basic services and verify the services. For details,see Table 14-1.

Table 14-1 Performing dialing tests on the basic services


Expected Result

Speech service Make 20 calls from an MS to afixed-line phone and hold on eachcall for 60 seconds.


BSC6900 GSMCommissioning Guide 14 Verifying Network Reliability


14-1


Expected Result

Make 20 calls from a fixed-linephone to an MS and hold on eachcall for 60 seconds.


Make 20 calls from an MS toanother MS and hold on each callfor 60 seconds.


Data service Send a fax from an MS to anelectrograph. Send a fax from anelectrograph to an MS.

Faxes are sent and receivednormally.

Test the General Packet RadioService (GPRS) or EnhancedData Rate for GSM Evolution(EDGE) function on the MS.

The test data rate is similar to thedata rate tested in a lab.

----End

14 Verifying Network ReliabilityBSC6900 GSM

Commissioning Guide


Issue 06 (2011-05-19)

15 FAQ

About This Chapter

This chapter describes how to handle the common problems encountered during thecommissioning.

15.1 Checking the Transmission LinkThis section describes how to verify that the terrestrial transmission links of the BSC6900 arefunctional. The verification covers E1/T1 port, FE/GE port, optical port, and upper-layer link.

15.2 Unavailable E1/T1 PortThis section describes how to handle the problem that the E1/T1 port is unavailable.

15.3 Unavailable FE/GE PortThis section describes how to handle the problem that the FE/GE port is unavailable.

15.4 IP Connection Setup FailureThis section describes how to handle the failures during IP connection setup.

15.5 Board Data Loading FailureThis section describes how to handle the failures that occur during data loading to theBSC6900 board.

15.6 Performing the Loopback Test on the E1/T1 PortThis section describes how to perform the loopback test to check whether the E1/T1 port isfunctional.

15.7 Performing the Loopback Test on the Optical PortThis section describes how to perform the group loopback test to check whether the optical portis functional.

15.8 Setting Maintenance Mode for NE

BSC6900 GSMCommissioning Guide 15 FAQ


15-1

15.1 Checking the Transmission LinkThis section describes how to verify that the terrestrial transmission links of the BSC6900 arefunctional. The verification covers E1/T1 port, FE/GE port, optical port, and upper-layer link.

Prerequisitel All the subracks of the BSC6900 are running normally.l You have logged in to the BSC6900 through the LMT.

Procedurel Check the status of the transmission link based on the transmission mode.

Table 15-1 Methods for checking the status of transmission link in different transmissionmodes

If the transmission on the interface isover...

Then...

IP PPP/MLPPP transmission mode 1. If the channelized STM-1transmission is used on theinterface, check the status of theoptical port.

2. Check the status of the E1/T1port.

3. Check the status of the upper-layer link.l For the PPP transmission

mode, run the MML commandDSP PPPLNK to check thestatus of the PPP link.

l For the MLPPP transmissionmode, run the MML commandDSP MPGRP to check thestatus of the MLPPP group.NOTE

If the upper-layer link is notfunctional, run the MMLcommand LST PPPLNK/LSTMPGRP accordingly to checkwhether the data configurationon the interface is correct.

IP over Ethernet transmission mode Check the status of the FE/GEport.

TDM

E1/T1 transmission mode Check the status of the E1/T1port.

15 FAQBSC6900 GSM

Commissioning Guide


Issue 06 (2011-05-19)

xiv Debugging with gdb

Appendix F The GDB Agent ExpressionMechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677

F.1 General Bytecode Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677F.2 Bytecode Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679F.3 Using Agent Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684F.4 Varying Target Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685F.5 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

Appendix G Target Descriptions . . . . . . . . . . . . . 689G.1 Retrieving Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689G.2 Target Description Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689

G.2.1 Inclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690G.2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690G.2.3 OS ABI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691G.2.4 Compatible Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691G.2.5 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691G.2.6 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691G.2.7 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

G.3 Predefined Target Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693G.4 Standard Target Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694

G.4.1 AArch64 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694G.4.2 ARM Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694G.4.3 i386 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695G.4.4 MicroBlaze Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696G.4.5 MIPS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696G.4.6 M68K Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696G.4.7 Nios II Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696G.4.8 PowerPC Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696G.4.9 S/390 and System z Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 697G.4.10 TMS320C6x Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

Appendix H Operating System Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

H.1 Process list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Appendix I Trace File Format . . . . . . . . . . . . . . . 701

Appendix J .gdb_index section format . . . . . . . 703

Appendix K Manual pages . . . . . . . . . . . . . . . . . . . . 707

Appendix L GNU GENERAL PUBLICLICENSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713

22 Debugging with gdb

3.3 Getting Help

You can always ask gdb itself for information on its commands, using the command help.

helph You can use help (abbreviated h) with no arguments to display a short list of

named classes of commands:

(gdb) helpList of classes of commands:

aliases -- Aliases of other commandsbreakpoints -- Making program stop at certain pointsdata -- Examining datafiles -- Specifying and examining filesinternals -- Maintenance commandsobscure -- Obscure featuresrunning -- Running the programstack -- Examining the stackstatus -- Status inquiriessupport -- Support facilitiestracepoints -- Tracing of program execution without

stopping the programuser-defined -- User-defined commands

Type "help" followed by a class name for a list ofcommands in that class.Type "help" followed by command name for fulldocumentation.Command name abbreviations are allowed if unambiguous.(gdb)

help classUsing one of the general help classes as an argument, you can get a list of theindividual commands in that class. For example, here is the help display forthe class status:

(gdb) help statusStatus inquiries.

List of commands:

info -- Generic command for showing thingsabout the program being debugged

show -- Generic command for showing thingsabout the debugger

Type "help" followed by command name for fulldocumentation.Command name abbreviations are allowed if unambiguous.(gdb)

help commandWith a command name as help argument, gdb displays a short paragraph onhow to use that command.

Debugging with gdb

The gnu Source-Level Debugger

Tenth Edition, for gdb version 7.10.50.20151203-cvs

(GDB)

Richard Stallman, Roland Pesch, Stan Shebs, et al.

If the transmission on the interface isover...

Then...

Channelized STM-1 transmission mode Check the status of the opticalport.

HDLC Check the status of the E1/T1port.

FR Check the status of the E1/T1port.

l Checking the status of the E1/T1 port

1. Run the MML command DSP E1T1 to query the status of the E1/T1 ports.

Expected result: The Port running state of the associated E1/T1 port is Portavailable.

If the value of the Port running state is Port is down, see the 15.2 Unavailable E1/T1 Port for troubleshooting.

l Checking the status of the FE/GE port1. Run the MML command DSP ETHPORT to query the status of the Ethernet port.

Expected result: The value of Link Availability Status is Available.

If either of the following cases occurs, see 15.3 Unavailable FE/GE Port fortroubleshooting.

– The value of Link Availability Status is Unavailable.

– The value of Port state is Deactivated.2. Optional: Check the connectivity of the gateway (mandatory in three-layer

networking).

(1) Run the MML command LST IPCHK to query the configuration of the gatewayconnectivity check.

(2) Run the MML command STR IPCHK to start the gateway connectivity check.

NOTEIf the BFD function is supported by and enabled at the peer router, set Check type to SBFD.Otherwise, set it to ARP.

(3) In the alarm tab page of the LMT, check whether the ALM-21346 IP ConnectivityCheck Failure alarm is reported. If yes, clear the alarm as suggested.

(4) To keep the gateway connectivity check, end this task; otherwise, run the MMLcommand STP IPCHK to stop the gateway connectivity check.

l Checking the status of the optical port1. Run the MML command DSP OPT to query the status of the optical port.

Expected result: The value of Optical port state is Available.

If the value of Optical port state is not normal, check the alarms related to the opticalport and rectify the fault according to the alarm handling suggestion.

----End

BSC6900 GSMCommissioning Guide 15 FAQ


15-3

commissioning and installtion guide huaw copy

Documents

command help

huawei trademarks

help argument

generic command

huawei proprietary

debuggertype help

list of commands

general help classes