IManager M2000 V200R013 Basic Feature Description(GSM&UMTS&LTE)

iManager M2000 V200R013

Basic Feature Description

Issue

02

Date

2013-07-20

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2013. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent 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.

Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase 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 representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd. Address:

Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China

Website:

http://www.huawei.com

Email:

[email protected]

Issue 02 (2013-07-20)

Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

i

Copyright © Huawei Technologies Co., Ltd. 2013. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent 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.

Notice The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase 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 representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd. Address:

Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China

Website:

http://www.huawei.com

Email:

[email protected]

Issue 02 (2013-07-20)


i

iManager M2000 Basic Feature Description

Contents

Contents 1 Overview...................................................... ............................................................................ ............................................. ............................................. ...................................... ................ 1 2 Basic Features (WOFD-100000) ........................... ................................................. ............................................. ............................................. ........................... ..... 5 2.1 Platform ........................................................................................................................................................................ 5 2.2 Fault Management ...................................................................................................................................................... 23 2.3 Configuration Management ..................................................................................................................... ................... 40 2.4 CME ........................................................................................................................................................................... 52 2.5 Performance Management ......................................................... .............................................................. ................... 86 2.6 Security Management ................................................................................................................................................. 94 2.7 Topology Management Management ................................................................................... .......................................................... 108 2.8 NE License Management ........................................................... .............................................................. ................. 112 2.9 Hardware and Soft ware Management ............................................................. .......................................................... 117 2.10 Network Monitoring and Analysis ................................................................ .......................................................... 122 2.11 FARS....................................................... ................................................................. ............................................... 134 2.12 Base Station Commissioning Management ..................................................................... ....................................... 150 2.13 SingleRAN Management ......................................................... .............................................................. ................. 156 2.14 Network Planning and Optimization ............................................................ .......................................................... 165 2.15 Wireless Auxiliary Networking Devices ........................................................................................................... ...... 169

Acronyms and Abbreviations .................................... .......................................................... ............................................. .......................................... ................... 171

Issue 02 (2013-07-20)


ii


1 Overview

1

Overview

This document describes the basic features provided by Huawei M2000 V200R013. This document helps users understand the M2000 features. The network elements (NEs) in this document refer to the network devices managed by the M2000. The M2000 manages Wideband Code Division Multiple Access (WCDMA), Global System for Mobile Communications (GSM), SingleRAN, Long Term Evolution (LTE), information management system (IMS), and UMTS Broadband (uBro) NEs, transmission devices, IP devices, and other devices such as domain name servers (DNSs) and Dynamic Host Configuration Protocol (DHCP) servers. Unless otherwise specified, all the devices described in this document are Huawei products. NOTE

By default, SingleRAN is managed by one M2000 system.

The solutions used with M2000 V200R013 include GBSS15.1, RAN15.1, eRAN6.1, SingleRAN8.1, eRelay3.0, SingleDAS1.1, CS10.1, PS10.1, SingleSDB6.0, IMS10.0, NGN10.9, and signaling transfer point (STP). The new and enhanced features in M2000 V200R012 are available only when M2000 V200R013 works with a corresponding solution. The M2000 manages the following WRAN NEs: 



Base station: NodeBV1, including the base station types of BTS3812, BTS3806, BTS3806A, BTS3812E, BTS3812AE, BTS3812A, and DBS3800 Base station: NodeBV2, including the base station types of DBS3900 WCDMA, BTS3900 WCDMA, BTS3900A WCDMA, BTS3900L WCDMA, BTS3900AL WCDMA, BTS3902E WCDMA (micro base station), and BTS3803E WCDMA (micro base station)



Co-MPT multimode base station: BTS3900



Radio network controller: BSC6800



Multimode base station controller: BSC6900 UMTS and BSC6910 UMTS



Clock server: IP Clock Server

The M2000 manages the following GBSS NEs: 

Base station controller: BSC6000 (GSM-R)



Multimode base station controller: BSC6900 GSM, BSC6910 GSM



Base station: GBTSs, including the pico BTS BTS3900B and compact BTS BTS3900E



Co-MPT MBTS: BTS3900




Issue 02 (2013-07-20)


1


1 Overview

The M2000 manages the following GSM/UMTS core network (CN) NEs: 

Serving GPRS support node: SGSN



Gateway GPRS support node: GGSN



Report server: SUR



Mobile switching center server: MSC Server



Home location register: HLR9820 and HSS9860



Home location register (service node): HLR-FE



Media gateway: MGW



Fixed-mobile convergence media gateway: FMC MGW



Charging gateway: CG



Signaling gateway: SG7000



Interworking function: IWF



Enhanced name server: ENS



Unified number portability: UNP



Unified identity management: UIM



Unified equipment identity register: UEIR



Unified Subscriber Center Database: USCDB



Visual IP



Security immunity gateway: SIG



Embedded Edge Router: EER



SigProbe



SigProbeTDM

The M2000 manages the following SingleRAN NEs: 

Multimode base station controller (GU mode): BSC6900 GU, BSC6910 GU



Multimode base station: MBTS(GU), MBTS(GL), MBTS(UL), MBTS(GUL), and MBTS(WL)

Co-MPT MBTS: BTS3900The M2000 manages the following eRAN NEs: 

Base station: eNodeB, including DBS3900 LTE, BTS3900 LTE, BTS3900A LTE, BTS3900L LTE, BTS3900AL LTE, BTS3202E (micro base station), BTS3202B (micro base station), and BTS3203E (micro base station)



Co-MPT multimode base station: BTS3900



Universal switching unit: USU




The M2000 manages the following eRelay NEs: 

Wireless backhaul system: eRelay, including eRelay BS and eRelay Remote Node (RRN)

The M2000 manages the following SingleDAS NE: 

In-building solution: DBS3900 IBS

The M2000 manages the following evolved packet core (EPC) NEs: 

Issue 02 (2013-07-20)

Home subscriber server: SAE-HSS and HSS9860


2


1 Overview



Unified service node: USN



Unified gateway: UGW



Charging gateway: CG



Unified policy and charging controller: UPCC



Signaling service processing system: SPSV3

The M2000 manages the following IMS NEs: 

Media gateway: MGW



Session border controller: SBC (SE2300, SE2600, and SE2900)



Home subscriber server: HSS (HSS9820 and HSS9860)



Call session control function: CSCF (CSC3300)



Unified policy and charging controller: UPCC



Charging collection function: CCF (iCG9815)



Advanced telephony server: ATS (ATS9900)



Multimedia exchange server: MediaX (MediaX3600)



Multimedia resource function processor: MRFP (MRP6600)



Unified Subscriber Center Database: USCDB



Attachment information management system: AIM (AIM6300)



Service provisioning gateway: SPG (SPG2800)



Unified gateway controller: UGC (UGC3200)



E.164 number: ENUM



Convergent Application Server: CAS9910



Presence server, Group server, Messaging server: PGM



Enhanced name server: ENS



Multipoint control unit: ViewPoint



Open service gateway: OSG



Access gateway control function: AGCF (UAC3000)



Rich Communication Suite: RCS9100 and RCS9880



Terminal management system: TMS9950



Network recording&playback server: MediaX3600NRS (NRS2000)

The M2000 manages the following signaling transfer point (STP) NEs: 




Signaling service processing system: SPS






The M2000 manages the following next generation network (NGN) NEs:



Softswitch system: SoftX3000



Media gateway: MGW






Signaling service processing system: SPS



Media switch server: MediaX3600



Session border controller: SE2300, SE2600, and SE2900



Media resource server: MRS6100

Issue 02 (2013-07-20)


3


1 Overview



iGateWay Bill: iGWB



Signaling transfer point: STP



Smart home location register: SHLR (SHLR9200)




The M2000 manages the following wireless transmission devices: 

Optical transmission devices: Metro1000V3, OSN1800, OSN3800, OSN6800, OSN1500, OSN2500, OSN3500, and OSN7500



Microwave transmission devices: RTN910, RTN950, RTN980, RTN905, RTN950a, RTN620, RTN610, RTN605, RTN380, and RTN310



Building integrated timing supply system: BITS

The M2000 manages the following IP devices: 



S series switches: S5000, S3300, S3500, S3900, S5300, S5600, S6500, S8500, and S9300 NE08 series routers: NE40, NE80, NE16E/NE08E/NE05, NE20E-8, NE20-2/4/8, NE16/NE08, NE40E/NE40E-4/NE40E-8, and NE80E



AR series routers: AR4640 and AR46-20



CX series routers: CX600-4/8/16, CX600-X3/X8/X16, CX600-X3-DO/X8-DO/X16-DO, and CX600-X1/X2



ATN series routers: ATN910(910I), ATN950, ATN950B, ATN980, and ATN990



Eudemon series firewalls E8080E, E8160E, and E8000E-X3/X8/X16 E8000E-B/C/D E1000E series: E1000E-U2/U3/U5/U6, E1000E-D/I, and E1000E-X3/X5/X6/X7/X8/X7-D/X8-D E200E series: E200E-X3/X5/X5DC/X6/X6DC/X7, E200E-B/BW/C/F/F-D, and E200E-X1/X1W/X1AGW-C/X1AGW-W/X2/X2W/X3/X5/X5DC/X6/X6DC/X7 E200E-C/F/F-D, E8040, E8080, E300, E500, E1000, E100E, E200S, and E200 Security gateways: Sig9820, SVN5300, and SVN5500



Other devices that can be managed by the M2000 are as follows: 

DNS (including third-party DNSs)



DHCP server (including third-party DHCP servers)



NE bearing server: servers that bear the SG7000, MSC Server, and iGWB



Wi-Fi device: Skyway Excel XL5810, which is from a third-party system

Issue 02 (2013-07-20)


4


2 Basic Features (WOFD-100000)

2

Basic Features (WOFD-100000)

2.1 Platform WOFD-000100 Basic M2000 Service Availability This feature was introduced in M2000 V200R003.

Summary This feature provides hardware and software platforms and basic functions required for the proper operation of the M2000. Basic functions include system operating-status monitoring, online help, and remote maintenance.

Benefits The M2000 centrally manages WCDMA, GSM, LTE, and SingleRAN networks. Based on common software and hardware platforms, the M2000 provides various network management application services such as alarm, performance, security, and configuration management. These functions improve the M2000's working efficiency, reduce operating expense (OPEX), and therefore minimize telecom operators' investments.

Description This feature provides the following functions: 

Hardware and software platforms For details about the hardware and software platforms, see iManager M2000 V200R012 Product Description.



M2000 software integrity check This function ensures the accuracy and integrity of the M2000 s oftware when it is being installed on the live network. When releasing an M2000 software version, the M2000 uses a digital certificate to sign the software version. Before installing or upgrading the M2000 software, the M2000 verifies the digital certificate of the software. If the digital certificate passes the verification, the M2000 proceeds with the installation or upgrade. Otherwise, the M2000 provides information about the verification failure.

Issue 02 (2013-07-20)


5

iManager M2000 Basic Feature Description 


Online help The M2000 provides online help information that supports functions such as hotspot help, full-text search, and offline browse. Online help includes the following items: −

Description of M2000 functions such as fault, configuration, performance, security, and topology management, and how to implement these functions

−

Description and valid value ranges of MML command parameters

−

Details about configuration parameters, alarms, and performance counters

Users can switch to Help information about the MML commands, alarms, performance counters, and configuration objects and parameters from the command-line interface (CLI), alarm, performance, and configuration management windows. Users can create, edit, delete, and manage remarks on any Help pages. Remarks management functions include querying, importing, and exporting. 

M2000 status monitoring This function monitors the M2000, database, and hardware status, and performance counters in real time. −



System status information that can be monitored includes the server, service and process status, database and disk partition space, and component information. The M2000 allows users to set thresholds for system status. If a counter value exceeds the user-specified threshold, the M2000 generates an alarm. If the counter value returns to the valid range, the M2000 clears the alarm.

−

The parts of the system that can be monitored include disks, CPUs, memory, disk arrays, power supplies, fans, network ports, and environments. When a fault occurs on the hardware, the M2000 generates an alarm. This function does not apply to the ATAE cluster solution.

−

After being started, the M2000 automatically collects its own performance statistics, including the average and peak usage of the server processor, server memory, server partitions, and database space. The M2000 allows users to query the M2000 performance statistics based on time ranges.

M2000 license management The M2000 license defines the M2000's management capability on the network. The M2000 provides specific network resource management capacity and optional features under license control. The M2000 license control items consist of function control items and resource control items. Users can view the function authorization information, update the license file, and export license information to a CSV or XLS file.



−

Function control items: authorized optional M2000 features controlled on the basis of functions.

−

Resource control items: authorized M2000 features that are controlled by the number of resources, manageable resource capacities, and number of used resources of these features. The M2000 generates an alarm if the number of network resources managed by a resource control item exceeds the number specified by the license. Users can manually clear the alarm.

Invalidating a license The M2000 allows users to invalidate a license on the client and generates an invalid code. According to the invalid code, Huawei technical support personnel apply for a new license. This significantly improves the efficiency of updating licenses in cases such as expansion, incremental sales, electronic serial number (ESN) replacement, and version upgrade.



Issue 02 (2013-07-20)

Concurrent M2000 clients


6



The M2000 supports multiple concurrent clients. The number of concurrent clients that the M2000 can manage depends on the hardware configuration of the M2000 server. An M2000 single-server system supports up to 100 concurrent clients, and a multi-server load-sharing (SLS) system supports up to 120 concurrent clients. 

Remote maintenance Users can connect the M2000 client to the M2000 server for remote maintenance through dial-up or a virtual private network (VPN). Remote maintenance through dial-up requires a dial-up server. Remote maintenance through a VPN requires a VPN gateway.



Web-based installation and automatic upgrade of the M2000 client Users can install the M2000 client locally or remotely through a web browser. In the case of a remote web-based installation, users can log in to the M2000 server through a web browser and install the M2000 client. The M2000 supports automatic upgrades of the M2000 client. If the version of the M2000 client is inconsistent with the server version when users log in, the M2000 automatically updates the client software to the matching version according to the user confirmation. This improves the efficiency of changing client versions and reduces OPEX.



Dynamic adaption of new NE version The M2000 provides the mediation solution to match multiple NE versions. Therefore, to manage a new NE version, users only need to install the mediation of the NE without upgrading the M2000. During the mediation installation, the M2000 can provide network management services properly. The installation of mediation does not affect the online users who do not require the mediation version. Users who require the new mediation need log in to the client again to use the latest mediation version. In scenarios such as initial site deployment and network upgrade, multiple mediations need to be loaded at a time. The M2000 can load NE mediations in batches, reducing the loading time and improving efficiency.



Online user monitoring The M2000 monitors the session status and operations performed by all M2000 users. The user-session monitoring can display information such as user name, maintenance terminal IP address, user type, session start time, and user group. The user-operation monitoring can display information such as user name, maintenance terminal IP address, security operation, operation object, risk level and execution result. With this function, administrators can force a specified user to log out.



Workbench management The M2000 provides a workbench for function and application shortcuts. Users can create function and application shortcuts on the workbench, which simplifies operations and improves operation efficiency. Users can also customize the names, description, and icons of workbench shortcuts. The M2000 provides default workbench shortcuts to certain functions such as centralized MML CLI, centralized task management, system monitoring, and topology management.



Southbound and northbound subnet separation To enhance network security, the M2000 now separates southbound and northbound interfaces by configuring IP addresses belonging to different subnets. This ensures that these interfaces are deployed in different subnets. The southbound subnet connects NEs and the M2000 and the northbound subnet connects the M2000 client and a third-party system.

Issue 02 (2013-07-20)


7



Enhancement The following function is added to M2000 V200R012C00: 

Southbound and northbound subnet separation: This solution is supported by Sun-platform-based single-server, local HA, remote HA, SLS, and emergency systems.

The following functions are added to M2000 V200R011C00: 

Monitoring M2000 hardware based on HP platform



Dynamically loading NE mediations in batches



Running M2000 clients on the Windows 7 operating system



Verifying M2000 software integrity

The following functions are added to M2000 V200R010: 

Associating alarm, performance, and configuration management and centralized command configuration functions with related Help information: Only the NodeB, BSC6900 GU, BSC6900 GSM, and BSC6900 UMTS support the function of associating performance counters with related Help information.



Creating and managing remarks in a Help window



Invalidating licenses



Monitoring the operating status of the Sybase database


Verifying M2000 services after the M2000 is upgraded



Supporting Windows Vista and XP operating systems



Managing functions and applications using a workspace



Updating M2000 license files on the client


Collecting M2000 performance statistics



Installing and automatically upgrading M2000 clients on a web browser



Loading M2000 mediation versions online



Supporting HP and ATAE platforms

WOFD-000200 File Transfer Management Availability This feature was introduced in M2000 V200R003.

Summary The M2000 supports file transfer between the M2000 server and the M2000 client, between the M2000 and NEs, and between the M2000 and a third-party system by using File Transfer Protocol (FTP). To ensure data transmission security, the M2000 supports FTPS- and SFTP-based file transfer. For details, see the optional feature WOFD-210100 Encrypted Transmission.

Issue 02 (2013-07-20)


8



Benefits This feature ensures effective file transfers between the M2000 server and the M2000 client, between the M2000 and NEs, and between the M2000 and a third-party system.

Description FTP is a standard protocol, which specifies that file transfer between network nodes can be implemented by setting up control channels and data transfer channels. Complying with the RFC 959 FTP standard protocol, the M2000 supports file transfer and management. It transfers files between the M2000 server and the M2000 client, between the M2000 and NEs, and between the M2000 and a third-party system. The data to be transferred is as follows: 

 

Performance data, log, and configuration data files collected from NEs or sent to a third-party system by the M2000 NE version, configuration data, and patch files downloaded from the M2000 by NEs License and NE version files transferred between the M2000 client and server

According to the application scenarios, the M2000 can function as an FTP server or client. For example, when transferring files to a third-party system, the M2000 can be either an FTP server or client based on user requirements. When upgrading NEs, users need to upload the software version from the M2000 client to the M2000 server. In such a case, the M2000 server functions as an FTP server, while the M2000 client functions as an FTP client. The M2000 manages parameters related to file transfer. For example, it allows users to set file transfer between NEs and the M2000 server and between the M2000 client and server, disable plaintext transfer, and set a transfer server and a third-party FTP server. Generally, FTP and File Transfer Protocol over SSL (FTPS) use default service ports, which may cause security risks. To improve system security, the M2000 allows users to customize FTP and FTPS service ports.

Enhancement The function of customizing FTP and FTPS service ports is added to M2000 V200R012C00.

Dependency None

WOFD-000300 Application Management Platform Availability This feature was introduced in M2000 V200R008.

Summary The application management platform supports centralized management of iSStar script applications and other applications. The iSStar is an enhanced script development platform provided by the M2000. With the application management platform, the M2000 manages application shortcuts by category and manages iSStar script applications.

Issue 02 (2013-07-20)


9



The iSStar script applications are classified into local script applications and remote script applications. Local script application files are stored and executed on the M2000 client. Remote script application files are stored and executed on the M2000 server.

Benefits This feature brings about the following benefits: 

Using this feature, users do not need to pay attention to the implementation of the iSStar script. After the script is released, users can run it and obtain the execution results through the shortcut on the application management platform.



The application management platform can also manage other applications to implement the uniform management of scripts and other applications.

Description The application management platform is used to manage the iSStar and other applications. This feature allows users to categorize application shortcuts and manage the remote iSStar applications, including management for workspaces, application shortcuts, remote applications, and iSStar tasks. 

Workspace management A workspace is a management platform for categorizing application shortcuts. The applications of the same category can be managed by one workspace. Users can categorize applications based on their preferences and manage these applications on different workspaces. Users can create or delete workspaces and change the workspace names.



Remote application management The application management platform allows users to manage remote iSStar script applications, such as viewing, issuing, downloading, and deleting the applications.



Management of application shortcuts Users can create, delete, and copy shortcuts. They can also modify the attributes of the shortcuts. In addition, users can create shortcuts to both local and remote iSStar script applications. When using the shortcuts of iSStar script applications, users can select multiple NEs at a time to create script tasks in batches.



Task management The M2000 provides a GUI for managing local and remote iSStar script tasks, including tasks started through application shortcuts or through the iSStar development platform. Users can check task information such as script file path and name, NE, progress, start time, end time, status, task creator, and IP address of the client where a local task is executed. Users can also create, copy, start, suspend, resume a task, delete tasks in batches, and check task execution results.

WOFD-000700 ATAE Cluster Solution Availability This feature was introduced in M2000 V200R010.

Issue 02 (2013-07-20)


10



Summary The advanced telecommunications application environment (ATAE) cluster solution is an integrated OSS solution developed on the Huawei ATAE platform. The characteristics of the ATAE cluster solution are as follows: 

Highly professional



Highly integrated



Carrier-class reliability



High performance



Enables smooth expansion through board insertion

In addition, the ATAE cluster solution centrally implements the following functions: 

Managing large-scale networks



Monitoring and maintaining hardware



Holding multiple OSS products such as the M2000 (including the Trace Server), PRS, and Nastar (including the eSAU, which is short for evolved service aware unit)

These features of the ATAE cluster solution help telecom operators minimize energy consumption, save equipment room space, reduce overall deployment costs, and improve competitiveness. NOTE

The Trace Server is a dedicated server provided b y the M2000 for LTE tracing services. This server stores LTE UE and cell tracing data. The eSAU is a server provided by the Nastar for p reprocessing data reported from NEs, such as measurement reports (MRs).


An ATAE subrack contains 14 boards, where 12 boards function as servers and 2 boards function as switching boards. Compared with traditional servers that provide equivalent management capability, the ATAE cluster solution reduces energy consumption by over 60%, saves equipment room space by 50%, and reduces the number of cables for connecting servers.



The ATAE cluster solution helps improve O&M efficiency and minimize OPEX because it can centrally manage large-scale networks. For example, a single ATAE cabinet can hold an M2000 system, the PRS, and the Nastar at the same time.



The ATAE cluster solution provides carrier-class reliability and ensures that services run smoothly all the time. In an ATAE cabinet, the key function modules such as subrack power supply units, fans, subrack management units, and switching units adopt the redundancy design, which provides carrier-class high reliability for telecom operators. The ATAE cluster solution adopts the N:1 redundancy solution, which improves hardware usage.



ATAE cluster solution supports board plug-and-play by using SAN boot technology to re-load software automatically. Therefore, services can be quickly restored when a fault occurs.



The ATAE cluster solution provides the OSS self-maintenance unit (OSMU), which helps telecom operators to improve O&M efficiency.

Issue 02 (2013-07-20)


11



Description This feature is described as follows: 

Hardware configuration An ATAE cabinet consists of 1 or 2 subracks, which can house OSS products (including the M2000, PRS, Nastar, TranSight, and Trace Server) independently or concurrently. The ATAE cluster solution provides flexible integrated deployment solutions for different application scenarios. For example, integrated deployment of the M2000 and Trace Server for the LTE network and integrated deployment of the M2000, PRS, and Nastar for GSM and UMTS networks. This solution also provides different management capacities based on OSS deployment requirements for various network scales. The management capacities include 200 equivalent NEs, 400 equivalent NEs, 800 equivalent NEs, and 1200 equivalent NEs.



Carrier-class reliability −

−

Software redundancy: The boards in the ATAE cluster solution are classified into server, switching, and DB boards. Server and DB boards support N:1 redundancy. The server boards implement different functions by loading corresponding software. One OSS product can be deployed on multiple server boards, and the boards are grouped into a cluster that adopts N:1 redundancy. DB boards implement data storage by loading corresponding database software. The DB board architectures for all OSS products are similar. Therefore, these DB boards share only one standby board. Hardware redundancy: The key function modules in an ATAE subrack adopt the redundancy design. When the active module is faulty, services are immediately switched over to the standby module. a The power supply units, subrack management units, switching units, and fans of the ATAE subrack adopt the redundancy design. b The service bus of the ATAE subrack adopts dual-star redundancy. c The service plane and the management plane are deployed on different boards. In this manner, the impact on services is minimized. d The main storage system adopts the RAID 1+0 and backup storage system adopts RAID 5 to protect data. e The controllers and power supply units in the storage system adopt the redundancy design.





Smooth expansion −

In the ATAE cluster solution, services are classified into different types and are deployed on corresponding boards. Therefore, users can smoothly expand the system capacity by inserting boards.

−

The ATAE cluster solution adopts the storage area network (SAN) architecture, which allows for the smooth expansion of storage devices. For example, users can expand storage capacity by adding disk arrays or a storage cabinet.

Board plug-and-play In the ATAE cluster solution, only the OSMU is configured with hard disks, and other boards adopt the SAN Boot technology. With the SAN Boot technology, users can start the operating system from the disk arrays. When a board is faulty, the boot volume is mapped on a new board that replaces the faulty one. Therefore, the SAN Boot technology helps quickly rectify faults.



OSMU The OSMU is the O&M unit of the ATAE cluster solution. It provides centralized maintenance and management for the ATAE cluster system. The OSMU is deployed on

Issue 02 (2013-07-20)


12



an independent board, supporting functions such as device, software, and service management, OSMU maintenance, and data backup.



−

The device management function supports one-click installation and configuration of the operating system, database, and Veritas Cluster Server (VCS). This function allows users to monitor and maintain hardware devices such as cabinets, subracks, boards, and disk arrays. It also allows users to view device information and status in real time, and perform operations on boards such as powering on and off and resetting boards and changing their IP addresses.

−

The OSMU provides a device panel, which displays hardware configuration and status in graphics and provides command portals for querying hardware status and maintaining boards. On the device panel, users can query basic information about subracks, power entry modules (PEMs), self management modules (SMMs), and boards, health events, and sensor information. They can also maintain boards with functions such as powering on and off, resetting, and switching over.

−

The software management function allows users to centrally manage various software packages, including the VCS, operating system, database, and application packages. It also allows users to install antivirus software and applications of the M2000, PRS, and Nastar, upgrade M2000 applications, and manage the VCS software license.

−

The service management function allows users to start and stop board and system services, and query cluster resource status and OSS product versions. It also provides product-specific functions for OSSs, such as northbound interface commissioning, mediation installation, and fault information collection for the M2000 and a management tool for the PRS.

−

System maintenance includes time and route management, operating system and database password management, and device preventive maintenance.

−

The OSMU centrally backs up the operating system, database, OSMU, and OSS applications from server boards to disk arrays, and restores the system using backup data. Each OSS product backs up its service data in the database and dumps the data to the OSMU. The data is restored on the OSMU.

−

OSMU maintenance supports self-management functions, such as monitoring hardware, signing and verifying software, managing log s. The hardware components that can be monitored are boards, subracks, power supplies, and fans. After detecting a hardware fault, the OSMU automatically generates an alarm and reports it to the M2000 for centralized monitoring. When the OSMU fails to communicate with the M2000, the M2000 detects that the fault occurred on the OSMU and generates an alarm.

−

The OSMU centrally manages system tasks created by management modules. Users can perform or delete the tasks and view task information in real time, such as the execution type, status, progress, and start and end time.

Integrated or independent Trace Server deployment solution The ATAE cluster allows users to deploy the Trace Server together with the M2000 or independently. Based on the managed network scale and collected data amount, the ATAE cluster provides two configuration specifications: 6000 cells and 18, 000 cells.

Enhancement The following modification is made in M2000 V200R013C01: 

The online ATAE cluster remote HA solution has been incorporated into the new optional feature WOFD-530300 ATAE Cluster Online Remote HA System.

The following functions are added to M2000 V200R013C00:

Issue 02 (2013-07-20)


13





Online ATAE cluster remote HA solution



Independent deployment of the Trace Server and management capabilities of 200 equivalent NEs and 1200 equivalent NEs



Independent deployment of the Trace Server and supporting two configuration specifications: 6000 cells and 18,000 cells


Installing antivirus software and updating virus definitions for all boards through the OSMU



Querying hardware status on the device panel



Deploying the eSAU (a module of the Nastar) with the M2000



Detecting OSMU faults


Centrally deploying the M2000 (including the Trace Server), PRS, and Nastar in a cabinet configured with two subracks



Performing OS hardening for the OSMU and OSSs



Enhancing OSMU maintenance, including monitoring hardware, signing and verifying software, and recording and managing logs



Acting as an intermediate NTP server to obtain reference time from the upper-level clock source and providing clock synchronization signals for the M2000 and the PRS



Upgrading the PRS software through the OSMU

Dependency The ATAE cluster solution of the current version does not support or does not involve the following features: 

WOFD-000600 Database Hardening



WOFD-130100 Local HA System



WOFD-530100 Server Load Sharing



WOFD-210700 Emergency System – for Single-Server and Local HA System



WOFD-210800 Emergency System – for SLS System



WOFD-500100 Veritas System Backup and Restore Solution



WOFD-040900 Single Sign On

The ATAE cluster solution in M2000 V200R013C00 currently does not support capacity expansion from 200 equivalent NEs to a larger number of equivalent NEs.

WOFD-070100 Local Maintenance Agent Availability This feature was introduced in M2000 V200R002.

Issue 02 (2013-07-20)


14



Description The M2000 provides communication agents for local maintenance terminals (LMTs) to maintain NEs. When an NE and its LMT are located on different network segments, the LMT can connect to the NE through the agent provided by the M2000 to maintain the NE. Along with the development and spread of the Web LMT, M2000 can also be a communication proxy for the Web LMT. LMTs can still set up connections to NEs through SSL or HTTPs to ensure transmission security when using the M2000 as an agent.

WOFD-070800 Supporting Network Time Synchronization Availability This feature was introduced in M2000 V200R002.

Summary The M2000 supports the NTP/SNTP network time synchronization protocols so that it can synchronize time with the time server of a third-party system and provide synchronization time sources for NEs. This ensures that the time between the M2000 and the NEs is synchronized. In addition, according to the security policy of the telecom operator, the M2000 uses MD5 encrypted algorithm defined in the NTP V3 in time synchronization.

Benefits This feature ensures that the time of NEs on the entire network is synchronized. In addition, it supports adopting the encrypted authentication to enhance the security of network time synchronization.

Description If the NTP server provided by a telecom operator network cannot communicate with the mobile communication devices managed by the M2000, the M2000 server can function as an intermediate NTP server. The M2000 server obtains the reference time from the NTP server provided by the telecom operator and sends time synchronization signals to NEs to ensure the consistency between the time of all NEs and the time of the time source. The M2000 monitors the operating status of the NTP service in real time and generates an alarm after detecting any exceptions in the NTP service or a synchronization failure with the upper-level time source. The NTP protocol supports two authentication modes: unauthenticated and encrypted authentication. Telecom operators can determine the authentication mode according to security requirements. If the upper-layer NTP server provided by the telecom operator uses the encrypted authentication mode, the M2000 server synchronizes time with the time of the upper-layer NTP server in encrypted authentication mode. After NEs send a time synchronization request to the M2000, the M2000 allows NEs to synchronize time with the M2000 server time in encrypted authentication mode. This feature requires telecom operators to provide a top-level clock source server. If telecom operators require a top-level clock source server from Huawei, they need to purchase Huawei entire-network time synchronization solution. For details about the solution, see the feature WOFD-540100 Network Time Synchronization Solution. Issue 02 (2013-07-20)


15




In the ATAE cluster solution, the OSMU acts as an intermediate NTP server.




The M2000 generates an alarm after detecting any exceptions in the NTP service or a synchronization failure with the upper-level time source. The M2000 functions as an intermediate NTP server in an SLS system, Sun-based local and remote HA systems, HP-based single-server and local HA systems, and ATAE – based single-server and local HA systems.

The following function is added to M2000 V200R009: 

The M2000 supports encrypted authentication of the NTP.

Dependency None

WOFD-070900 Daylight Saving Time and Management of Multiple Time Zones Availability This feature was introduced in M2000 V200R003.

Description For some countries that use the Daylight Saving Time (DST), there are two time switchovers every year. Some countries cross multiple time zones. Therefore, the time of NEs in different time zones must be different. This feature ensures that the M2000 adapts to DST shifts on NEs and allows users to set time zone information. For example, users can choose whether to display server time or local NE time in the alarm browsing window. If the area where an NE is located is using DST, the M2000 displays DST in MML messages.

WOFD-071200 Centralized Task Manager Availability This feature was introduced in M2000 V200R005.

Description Centralized task manager is a task management mechanism of the M2000. It manages and controls all the scheduled tasks in the M2000 system through a centralized task management window. The tasks managed centrally are classified into system-scheduled tasks and user-scheduled tasks. There are two types of tasks: one-time tasks and periodic tasks. Users can create user-scheduled tasks and select one-time tasks or periodic tasks as required. All system-scheduled tasks are periodic tasks and cannot be created by users.

Issue 02 (2013-07-20)


16



Users can view information about all tasks on the task list provided by the M2000. The task information includes task name, execution period, type, creator, status, execution progress, execution result, and last execution time. Users can also perform specific operations on the tasks, such as start, delete, suspend, copy, or resume the tasks. In addition, users can modify task parameters. System-scheduled tasks are as follows: 

Database capacity management



Data export



Synchronization



M2000 data backup

The limitations on the operations of system tasks are as follows: 

Only users in the administrator group can manage and view s ystem-scheduled tasks.



System-scheduled tasks cannot be copied or deleted, and only some parameters can be modified.



Data capacity tasks in system-scheduled tasks cannot be suspended or resumed. Data export tasks, synchronization tasks, and backup tasks can be suspended and resumed. Users can set the time to suspend and resume tasks.

User-scheduled tasks are as follows: 

NE license backup



NE backup



BSC and RNC license activation



Distribution of NodeB licenses



MML script execution



iSStar script execution



Software download



Verification after upgrade



Generation of configuration reports



Single antenna interference cancellation (SAIC) terminal capability sharing



Configuration data synchronization on the CME



Data consistency check on the CME



Export of data from the current data area on the CME

Enhancement SAIC terminal capability sharing for GSM is added to M2000 V200R012C00.

Dependency None

Issue 02 (2013-07-20)


17



WOFD-071300 Script Trigger Availability This feature was introduced in M2000 V200R006.

Description This feature supports two triggering modes, customizing menus to trigger scripts and automatic triggering. Customizing menus to trigger scripts: This function allows users to customize the menus for script triggering. Users can add, delete, modify, or query user-defined menus. When adding a user-defined menu, users can select the script and set script execution parameters. The user-defined menus are used to trigger scripts stored on the M2000 client. Automatic triggering: The M2000 allows users to set script triggering conditions and specify the scripts. Triggering conditions include validity time range, script type, execution period, and alarm ID. The M2000 automatically checks whether script triggering conditions are met. If the conditions are met, the corresponding script is automatically triggered. The automatically triggered scripts are scripts stored on the M2000 server. Currently, HSL scripts and the following Shell scripts can be automatically triggered: 

Bourne Again shell



Bourne shell



C shell



Z shell



Korn shell



TC shell

Enhancement The following function is added to M2000 V200R008: 

This feature can be used for triggering the HSL script.

WOFD-071400 Auto IP Address Allocation Service for BTS Availability This feature was introduced in M2000 V200R008.

Description The M2000 automatically assigns IP addresses to BTSs through the DHCP protocol. The M2000 extends the DHCP protocol based on the standard protocol to support the required functions, and automatically assigns IP addresses to Huawei BSs on IP networks based on the extended DHCP protocol. The DHCP Server service provides the following functions: 

Issue 02 (2013-07-20)

The M2000 extends protocols based on the DHCP protocol and assigns IP addresses based on specific configuration information such as the BTS name, BTS ID, IP address, and electronic serial number (ESN).


18





The M2000 allows users to add, delete, or modify the binding relationships between specific NE configuration information and IP addresses on the M2000 client. It also allows users to import the information about the binding relationships into a file. The M2000 allows users to view the assignment information about IP addresses. To facilitate information browse, it also allows users to filter IP address assignment records by fields such as BTS ID, BTS name, and ESN.

Enhancement The following function is added to M2000 V200R011C01: Allowing users to filter IP address assignment records by fields such as BTS ID, BTS name, and ESN

WOFD-071500 User Profile Management Availability This feature was introduced in M2000 V200R008.

Description The user profile setting provides the user-defined settings based on M2000 users. Therefore, multiple maintenance terminals can share the user-defined user settings. The M2000 provides default settings for all M2000 users. The supported profile setting options are as follows: 

Display styles of parameter settings on the M2000 client, such as area setting, metrology setting, LMT prompt setting, agent server setting, MML client setting, file transfer parameter setting, alarm sound and colors, time mode, system lock time, data display modes, system login modes, display of alarm states in the topology view, and display of the performance module interface.



Environment setting of function interfaces, such as the topology view, activated subnets and filter criteria in the topology view, filter criteria for querying alarms, and alarm query templates.

WOFD-080100 Disk Redundant Backup Availability This feature was introduced in M2000 V200R002.

Description The local disks of the M2000 support the RAID 1 backup mode (1+1 disk mirroring). The supported redundancy solutions vary according to disk array types. Sun 6140, Sun 3320, OceanStor S3100, and OceanStor S3200 disk arrays support the RAID 5+Hotspare mode. Sun 6180, OceanStor S2600, and OceanStor S3900 disk arrays support the RAID 10+Hotspare mode.

Issue 02 (2013-07-20)


19



WOFD-080200 Dual Plane Communication Availability This feature was introduced in M2000 V200R002.

Description The M2000 supports the dual-plane networking of operation and maintenance, and two independent communication links form an O&M network. The M2000 automatically monitors the communication status of both channels. The routine communication is performed on the active plane. If the active plane is faulty, the M2000 automatically switches the communication to the standby plane to ensure the reliability of the O&M network.

WOFD-080300 M2000 Data Backup and Restore Availability This feature was introduced in M2000 V200R002.

Summary The M2000 provides the backup and restore solutions for M2000 data. According to the characteristics of backup data, the backup and restore is classified into backup and restore of application data including M2000 application and service data, backup and restore of database applications, and backup and restore of operating systems. The M2000 provides different backup and restore solutions based on the levels.


The M2000 provides cost-efficient backup and restore solutions for the O&M network.



With the characteristics of simple configuration and flexible deployment, the backup and restore solutions require only tape drives and related tapes. Therefore, the solutions are easy to use.



The M2000 provides backup and restore solutions at multiple levels, meeting the requirements of primary O&M application scenarios.


Backing up and restoring application data Application data consists of the data in the M2000 application and the service data in the M2000 database. The M2000 provides a user-friendly GUI for backup operations and management. Users can set backup tasks on the M2000 client to back up the application data of the M2000 in full or incremental backup mode. The M2000 deployed on the Sun s erver supports both full and incremental backups. The M2000 that is deployed on the HP server or PC Server, or uses the ATAE cluster solution supports only the full backup.

Issue 02 (2013-07-20)


20



The system provides automatic and manual backups. A manual backup is started immediately after users activate the backup. Manual backups can be implemented in incremental or full backup mode. The M2000 manages automatic backup tasks based on the feature WOFD-071200 Centralized Task Manager. In each backup period, the M2000 (deployed on the Sun server) supporting the incremental backup performs a full backup on the first day. Users can set the M2000 to perform no backup or an incremental backup on each of the other days. Users can also specify the backup execution time and period. The M2000 (using the ATAE cluster solution, or deployed on the HP server or PC Server) supporting only the full backup performs a full backup every seven days. Users can also specify the backup execution time. The backup data is stored on the disk array of the M2000 server or external tape drives. The M2000 based on ATAE platform stores the backup data on the disk array. To restore the application data in specified full and incremental backup files to the database and applications, users need to run the restore script. 

Backing up and restoring the database application and operating systems Database application consists of database server application and database device files. Operating system data involves all the files related to the operating system. Users perform the backup or recovery of the database application and operating system by running the scripts. Database applications and operating systems are backed up to the local hard disk and disk array of the M2000 server or external tape drives. The M2000 based on ATAE platform stores the backup data on the disk array.


The M2000 system using M4000 or M5000 servers allows users to back up the operating system to the local hard disk of the M2000 server.

The following function is added to M2000 V200R011C00: 

Users can back up database applications to local hard disk of the M2000 server.

WOFD-080400 NE Data Backup and Restore Availability This feature was introduced in M2000 V200R002.

Summary The M2000 supports backup and restore of key NE data. If NE data is missing due to a fault, users can use the backup data to restore the NE data on the M2000.

Description Generally, key NE data (such as NE configuration data and logs) is stored on NEs. The M2000 backs up NE data by obtaining the data from NEs and saving it on the disk array of the M2000 server or downloading the data to the M2000 client. Key NE data is backed up and restored on the M2000. The data can be backed up manually or automatically on a scheduled basis. The M2000 centrally manages and schedules backup tasks

Issue 02 (2013-07-20)


21



by using the feature WOFD-071200 Centralized Task Manager. The M2000 backs up the data based on the preset period and time. Data must be restored manually because it may lead to NE restart. After users start restoring NE data, the M2000 downloads backup NE data to the NE and runs data restoration commands for the data to take effect. Users must upload the NE data that was downloaded and stored on the M2000 client to the M2000 server before restoring the data. NOTE

NE logs cannot be modified or replaced, and the restore of NE logs may result in invalid modification of the NE logs. Therefore, the M2000 does not provide the function of restoring NE logs.

WOFD-210200 Automatic File Upload Availability This feature was introduced in M2000 V200R008.

Summary The M2000 supports the function of automatically uploading the northbound configuration files, performance files, inventory files and alarm files to the specified FTP server by using FTP. To ensure data transmission security, the M2000 supports SFTP-based file transfer with the third-party system. For details, see the optional feature WOFD-210100 Encrypted Transmission.

Benefits This feature reduces the workload and costs for developing a third-party system. 

The M2000 sets up and manages the transmission connection.



In the HA, remote HA, or SLS system, the switchover between the active node and the standby node does not affect the uploading of files to a third-party system.


Configuring the uploaded information about the server On the client, users can choose to upload the exported files of configuration data, alarms, performance data, inventory data, and license data and set the IP address, directory, user name, password, and file compression mode of the server. The M2000 creates a directory on the server according to the settings. Users can configure specific file servers for different types of data. The M2000 can upload data files to a maximum of 10 file servers.



Supporting the file transfer in single-connection or multi-connection mode The types of northbound exported files comprise the configuration files, performance files, alarm files, and inventory files. The M2000 can upload the files of each type to one server (single connection) or multiple servers (multi-connection). By default, the single-connection mode is used. Users can set the uploading mode.



Issue 02 (2013-07-20)

Creating a directory on the uploading server


22



Users can create a directory on the server for the M2000 to save uploaded northbound files. Alternatively, the M2000 can create a directory for saving the files. The directory structure is the same as that of the M2000 northbound export file directory. 

Managing file transfer On the M2000 client, users can browse files to be transferred and files failing to be transferred. In addition, users can delete the files to be transferred. Users can automatically re-transfer the files that failed to be transferred according to the configuration parameters.



−

The valid duration for re-transferring the files is 1 hour. The system cancels the transfer of the files that exceed the valid duration.

−

The system transfers the files again three times. The system records the files that are re-transferred more than three times, to the logs.

−

The interval for re-transferring files is 15 minutes.

Managing faults If a file fails to be uploaded to a third-party system because the FTP service of a third-party system is not enabled or the network is disconnected, the M2000 generates an alarm and forwards this alarm to the third-party system through the northbound alarm interface.

Enhancement In M2000 V200R010, the M2000 generates an alarm if a file fails to be uploaded to a third-party system.

Dependency This feature is used with the following features to implement automatic file upload and cannot work independently: 

WOFD-100210 Alarm File Interface



WOFD-100220 Performance File Interface



WOFD-100230 Configuration File Interface



WOFD-100240 Inventory File Interface



WOFD-261000 Interface for Exporting Configuration Data Files – GBSS



WOFD-184500 Interface for Exporting Configuration Data Files – WRAN



WOFD-188011 Interface for Exporting Configuration Data Files – LTE FDD/TDD



WOFD-070400 NE License Management

2.2 Fault Management WOFD-010100 Centralized Storage of Alarm Information Availability This feature was introduced in M2000 V200R002.

Issue 02 (2013-07-20)


23



Description The M2000 centrally collects the alarm information about all the entities (including th e M2000 itself) of managed networks and stores the alarm information in the database. The fault management module of the M2000 can manage alarms and events. Alarms are classified into ADAC alarms and ADMC alarms. Unless otherwise stated, alarms mentioned in this document do not include events. Event: An event is a notification that is generated and needs to be sent to users when the system is running properly. For example, the notification can be the deletion, modification, or status change of an object. Fault: A fault occurs when the system is running improperly. The fault may affect the operation capability or backup capability. Alarm: An alarm is a notification that is generated when the system detects a fault. Based on the detection capability, alarms are categorized as ADAC alarms and ADMC alarms. ADAC (Auto Detected Auto Cleared) alarm: An ADAC alarm is generated and cleared when specified conditions are met. When a fault occurs, an alarm occurrence notification is generated. After the fault is cleared, an alarm clearance notification is generated. ADMC alarm: An ADMC alarm is generated when specified conditions are met, but it cannot be cleared automatically. When a fault occurs, an alarm occurrence notification is generated. An alarm clearance notification, however, is not sent. O&M personnel need to check that the fault is cleared and manually clear the ADMC alarm. After receiving the alarm and event reported by an NE, the M2000 preprocesses the alarm and event and stores them in the centralized mode. The information serves as the reference for future browse, collection of statistics, and query. The M2000 records each alarm or event as one log. The database stores alarm or event logs for a maximum of 90 days. Users can change the period. If the M2000 alarm database does not meet the standard configuration or the network size exceeds the management capacity of the server, users may not be able to store the logs for 90 days. When the M2000 reaches the end of the storage period or disk capacity limit, the M2000 automatically dumps event logs and logs for acknowledged and cleared alarms to files.

WOFD-010300 Alarm Viewer Availability This feature was introduced in M2000 V200R002.

Summary This feature allows users to view the alarms and events of NEs and the M2000 in real time. Based on the browse results, users can also perform operations such as saving and printing alarm information, viewing detailed alarm information, and locating alarms in the topology view. Users can set conditions for filtering alarms or save the filter criteria as a template for future use. In addition, users can customize the colors and properties of alarms and events displayed in the browsing window. Users can also set the uncleared alarms to be highlighted.

Issue 02 (2013-07-20)


24




The M2000 allows users to browse alarms on the entire network in real time. It also allows users to set various filter criteria to focus on key network faults.



The function of customizing display styles helps users to personalize working interfaces.


Alarm/Event browse The M2000 displays the alarms that meet the preset filter criteria in the alarm/event browsing window. Multiple browsing windows can be opened concurrently to display alarm logs, event logs, and alarm lists. Users can set filter criteria in each browsing window. The alarm list displays important alarms that users must focus on or handle. If an alarm has duplicate alarm records, only one record is displayed in the alarm list. During routine maintenance, O&M personnel need to monitor only the alarm list. By default, acknowledged and cleared alarms are not stored in the alarm list. Users can store these alarms after setting a storage period. Users can set the following filter criteria: alarm source including NE types, NEs, MOs, MBTSs, object groups and topology maintenance areas, severity, type, and name. Events do not need to be cleared or acknowledged. Therefore, log browse does not support status-related filter criteria such as clearance status and acknowledgment status. The M2000 supports the following alarm types: −

Power system alarm

−

Environment system alarm

−

Signaling system alarm

−

Trunk system alarm

−

Hardware system alarm

−

Software system alarm

−

Running system alarm

−

Communication system alarm

−

QoS alarm

−

Processing error alarm

−

Internal alarm

−

Integrity violation alarm

−

Operational violation alarm

−

Physical violation alarm

−

Security violation alarm

−

Time domain violation alarm

In addition, the M2000 supports the browse of alarms based on alarm categories. Users can browse alarms according to alarm severities or alarm statuses in the same window. Alarms statuses are unacknowledged and uncleared, unacknowledged and cleared, acknowledged and uncleared, and acknowledged and clear.

Issue 02 (2013-07-20)


25



In the event browsing window, users can query event details, locate an event on the corresponding NE in the topology view, mask the event, or send a remote notification. In the alarm browsing windows, users can perform more operations, such as acknowledging, unacknowledging, and clearing alarms. 

Template Users can save common filter criteria as a template so that they can use the template to set filter criteria when browsing alarms or events. The M2000 filters the browse results according to the conditions set in the template. Alarm templates are saved by user. The owner of a template is the user who creates the template. Such users can share their templates with other users. Administrators can manage and use all templates. Common users can manage and use their templates and shared templates. The M2000 provides a centralized template management window. Users can manage their templates, for example, viewing, creating, deleting, modifying, and renaming templates.



Alarm/Event groups and object groups The M2000 allows users to view, query, and collect the statistics on alarms and events based on alarm/event groups and object groups. An alarm or event group is a set of alarms or events. An object group is a set of objects where alarms or events are generated, for example, NEs, boards, cells, and links. Users can define alarm/event groups and object groups according to the actual requirements.



Saving and printing alarm/event information Users can save the alarm or event information in the browsing window as TXT, HTML, PDF, XLS, XLSX, and CSV files or print the information. Users can save or print part of or all alarms.



Customizing alarm/event display styles The M2000 allows users to customize the following elements in the alarm browsing window: −

Colors in which alarms/events are displayed

−

Attributes of the alarms/events to be displayed

−

Orders for sorting alarm/event attribute columns

−

Conditions for sorting alarm/event attributes

The settings take effect only on the current client. Alarm properties include alarm names, severities, types, location information, IDs, clearance status, and acknowledgment status. Events do not need to be cleared or acknowledged. Therefore, log browse does not support status-related filter criteria such as clearance status and acknowledgment status. In the alarm browsing window, users can sort alarms/events according to one or more alarm/event attributes. Alarms and events of different severities are identified with different colors. Users can modify the default settings. The settings take effect in the alarm browsing window, alarm boards, and alarm icons in the topology view. The M2000 checks alarms and highlights the alarms that are in the unacknowledged and uncleared state, unacknowledged and cleared state, and acknowledged and uncleared state for a long time. Users can set thresholds for alarms of different severities. When the status or state duration reaches the preset thresholds, the M2000 highlights the corresponding alarms.

Issue 02 (2013-07-20)


26



Enhancement The following functions are added to M2000 V200R009: 

The M2000 allows users to open the device panel of the NE that generates the selected alarm when users locate the device panel in the alarm viewer.



The M2000 supports alarm/event groups and object groups. Users can perform operations such as viewing, querying, and collecting the statistics on alarms and events based on alarm/event groups and object groups.

WOFD-014200 Real-Time Alarm Notification Availability This feature was introduced in M2000 V200R002.

Summary The M2000 supports the real-time notification of alarms in the forms of sound, light, blinking, and display of statistical results. Alarms are notified through alarm boxes, alarm boards, tool tips, and real-time statistics.

Benefits The M2000 supports the real-time alarm notification in multiple modes. This ensures that users can learn about the generation and clearance of alarms in real time to take corresponding troubleshooting measures, reducing the impacts on network services.


Alarm box The M2000 notifies users of audible and visual alarms through an alarm box. The alarm box is connected to the M2000 client through a serial port. The M2000 client sends the alarms that meet the preset conditions to the alarm box in real time. Then, the alarm box generates sound and the corresponding alarm indicators blink according to the alarm severities. Users can filter alarms based on alarm severities or by using a query template. The filter criteria set in a query template are the same as the filter criteria in the feature WOFD-010300 Alarm Viewer.



Alarm notification by sound and light M2000 provides alarm boards to display the total number of current alarms, number of alarms of each severity, and number of alarms of each severity in each status in real time and to notify users of new alarms by emitting sound and through blinking icons. Users can customize notification sound. Users can set a template to control the range for collecting the statistics of alarms. The conditions in the template are the same as the conditions described in the feature WOFD-010300 Alarm Viewer.



Tool tip After users set the alarm indication in the topology view, the NE icon is identified in the color of the alarm of the highest severity when alarms in the same status exist on an NE. The alarm states that can be selected are unacknowledged and uncleared. In addition,

Issue 02 (2013-07-20)


27



users can set whether to display the current number of alarms of the highest severity on NEs. 

Real-time collection of alarm statistics When creating statistical charts, users need to select alarm templates. According to filter criteria in the alarm list templates, the M2000 filters alarms and collects the statistics of alarms based on alarm severities and types. The statistical results are displayed in a bar chart and are updated in real time according to the generation or clearance of alarms. Users can select multiple alarm list templates to create multiple statistical charts. NOTE

Users can obtain the details about alarm sources in masking conditions by referring to the feature WOFD-010300 Alarm Viewer.

WOFD-011400 Automatic Alarm Retrieval Availability This feature was introduced in M2000 V200R002.

Description After the connection between the M2000 and NEs is restored, the M2000 automatically synchronizes the data between the M2000 and NEs to obtain the alarm data generated during the disconnection. This feature ensures that the alarm data on the M2000 and NEs is consistent. When NEs report alarms to the M2000, the M2000 automatically checks whether the alarm data on the M2000 is consistent with that on NEs. If the data is inconsistent, the M2000 synchronizes the alarm data on the M2000 with that on NEs.

WOFD-011500 Alarm Synchronization Availability This feature was introduced in M2000 V200R002.

Description Generally, after an alarm is generated on an NE or the M2000, the alarm is automatically reported to the M2000 in real time. The M2000 supports manual and scheduled alarm synchronization modes. Therefore, alarms can be synchronized in the following scenarios: 

The connection between an NE and the M2000 is restored after it is disrupted.



The status of an alarm is updated after the alarm is handled.

The M2000 supports manual alarm synchronization and scheduled alarm synchronization. In manual synchronization mode, users manually synchronize the alarm data on the M2000 with that on NEs through the M2000 client. Scheduled synchronization tasks are managed by using the feature WOFD-071200 Centralized Task Manager. In scheduled synchronization mode, the M2000 synchronizes the alarm data on the M2000 with that on NEs according to the preset period and time. Users can

Issue 02 (2013-07-20)


28



change the synchronization period and time. The unit of the synchronization period is day. The default synchronization period is one day.

WOFD-014000 Alarm Pre-Processing on M2000 Availability This feature was introduced in M2000 V200R002.

Summary Alarm pre-processing on the M2000 refers to processing the new alarms and events received by the M2000 before they are saved to the database. Alarm pre-processing involves alarm masking, alarm severity redefinition, and alarm correlation analysis.

Benefits The M2000 provides flexible functions of masking alarms and customizing the rules for analyzing alarm correlations. This helps in sharing the maintenance experience of O&M personnel, reducing the number of alarms, and improving work efficiency.


Masking alarms and events After receiving alarms or events, the M2000 checks and discards the alarms or events that meet the preset conditions. The supported conditions for masking alarms and events include alarm/event sources, severities, names, types, location information, and duration. Users can set alarm/event sources based on NE types, NEs, base stations, and cell objects. Users can also set the time segment for alarm masking conditions to take effect. Delayed alarm/event processing: If the duration of an alarm/event is shorter than the threshold set in the alarm/event masking criteria, the M2000 discards the alarm/event after analyzing toggling alarms. When the duration of an alarm/event reaches or exceeds the preset threshold, the M2000 delays processing the alarm/event. The delay time equals the preset threshold of alarm/event duration. NOTE

Users can obtain the details about alarm sources in masking conditions b y referring to the feature WOFD-010300 Alarm Viewer. 

Redefining alarm and event severities Users can modify the properties of alarms and events on the M2000. For example, users can change the severities, names, and types of alarms and events. After the alarm and event properties are redefined, the M2000 displays the alarms and events based on the new properties. The redefinition takes effect only on the M2000. On NEs, the properties of alarms and events remain unchanged. Alarm severities can be redefined on the basis of time segments, such as during a busy hour and a non-busy hour.



Analyzing correlations Correlation rules are classified into default and user-defined rules.

Issue 02 (2013-07-20)


29



Default rules are provided by the system and can be instantiated by users. These rules are used for analyzing alarm or event occurrence frequency, intermittent alarms, repeated events, and duration of acknowledged and uncleared alarms. Associated concepts are described as follows: Alarm or event occurrence frequency: If the number of repeated alarms or events exceeds a preset threshold within a specified period, the M2000 considers that these alarms or events are correlated and performs one of the following operations, which have different threshold ranges: −

Changing the alarm or event severity

−

Generating an avalanche alarm

−

Masking alarms or events and generating an avalanche alarm

−

Generating a toggling alarm

−

Masking alarms or events and generating a toggling alarm

Intermittent alarm: The M2000 generates an intermittent alarm if the interval for reporting the clearance alarm of an alarm is within a specified period. The M2000 displays only the first intermittent alarm and discards other ones. If the number of intermittent alarms exceeds a preset threshold within a specified period, the M2000 generates a high-frequency intermittent alarm. When intermittent alarms are generated at a lower frequency than the threshold, the high-frequency intermittent alarm is automatically cleared. Repeated event: The M2000 generates a repeated event if the interval for reporting an event is within a specified period. The M2000 displays only the first repeated event and discards other ones. If the number of repeated events exceeds a preset threshold within a specified period, the M2000 generates a high-frequency repeated event. With the correlation analysis function, users can create rule instances for analyzing alarms/events frequency, intermittent alarms, and repeated events. If alarms/events meet the preset conditions, the M2000 deals with the information about redundant alarms/events according to the preset policy. This prevents the M2000 from generating or clearing the same alarms, enhancing system reliability. The purpose of analyzing the duration of acknowledged and uncleared alarms is to prompt users to clear these alarms in time. If certain alarms are already acknowledged but are not cleared for a long time, the M2000 sets the severity of these alarms to a higher level. The M2000 allows users to define alarm correlation rules by setting root alarms, correlated alarms, handling methods, handling conditions, analysis periods, and priorities through the creation wizard. Users can delete or modify alarm correlation rules. After users apply advanced correlation rules, the M2000 discards the alarms that meet the correlation rules. It can also redefine the severities of these alarms or set the m to correlative alarms. Therefore, the number of unnecessary alarms is reduced and non-root alarms are not considered. Therefore, users can handle key alarms to quickly locate and rectify related faults. Advanced correlation rules support the following functions:



Issue 02 (2013-07-20)

−

Setting correlations within a single NE and among multiple NEs.

−

The main property values in the alarm locating information can serve as correlation conditions.

−

Users can set the interval for analyzing correlations.

Converting events to ADMC alarms


30



The M2000 allows users to convert an event to an ADMC alarm. Then, the ADMC alarm is displayed in the alarm list. After the conversion setting is canceled, newly reported records of this event are no longer displayed in the alarm list.


Set alarm masking conditions based on base stations and cell objects.


The M2000 generates a summarized parallel alarm when the number of alarms meeting the requirements exceeds Set Threshold.



The M2000 clears the summarized parallel alarm when the number of alarms is smaller than Clear Threshold.



Users can add or delete summarized parallel alarm rule.


The M2000 generates a toggling alarm in analyzing alarm or event occurrence frequency.


The M2000 supports redefinition of alarm severities based on time segments.


A wizard for creating advanced correlation rules is added, which improves the usability of this feature.



The names and types of alarms/events can be redefined.

WOFD-012200 Alarm Severity Redefinition on NE Availability This feature was introduced in M2000 V200R002.

Description Alarm severity redefinition on NEs allows users to change the severities of alarms and events on NEs. After severities of alarms and events are redefined, NEs report alarms and events according to the new severities, and the M2000 displays the alarms and events according to the new severities.

WOFD-012400 Alarm Masking on NE Availability This feature was introduced in M2000 V200R002.

Issue 02 (2013-07-20)


31



Description Alarm masking on NEs allows users to set masking conditions and mask alarms by NE on the M2000 and send the conditions to NEs so that NEs do not report the alarms and events that meet the masking conditions. Therefore, the masking for alarms and events is implemented on NEs. The M2000 masks alarms and events according to alarm/event names and severities. When setting conditions, users can sort NE objects according to NE types and sort alarms and events according to alarm/event types and severities. This facilitates alarm/event selection. Some NEs such as the BSC6900 GSM and BSC6900 GU can mask alarms and events according to objects. The supported objects are cells and GBTSs. Users can modify, delete, or query preset alarm masking conditions. In addition, the M2000 allows users to import the masking conditions of alarms and events from a file to the M2000. Users can export the preset masking conditions as a template, set masking conditions in the template, and import the template to the M2000. Then, the M2000 generates masking conditions based on the records in the file.

Enhancement None

WOFD-013400 Environment Alarm Setting Availability This feature was introduced in M2000 V200R002.

Summary To monitor NE environments, the M2000 supports the settings of environment alarms.

Benefits Users can customize environment alarms to learn about the faults in the equipment room environment and remotely monitor the environment centrally. This helps ensure the normal equipment operation.

Description Based on the actual situations, users can set environment alarms of NEs through the M2000 client, and bind the alarms with an NE port. In addition, users can mount an environment monitoring device on the port so that NEs can generate alarms and report the alarms to the M2000 in real time when the environment monitoring device detects environment faults. This feature requires alarm definition and binding information. The alarm information to be defined includes alarm names, severities, and IDs. Alarm binding information indicates the mapping between environment monitoring devices and defined alarms (including alarm generation conditions). After the binding, NEs can generate alarms based on the binding conditions and report the alarms to the M2000.

Issue 02 (2013-07-20)


32



The M2000 also allows users to import and export environment alarms as XLS or XLSX files. Users export a template from the M2000, fill in required information, and import the template into the M2000. The M2000 can then generate environment alarms based on the information in the template. This feature does not apply to the LTE micro base station BTS3202E.

Enhancement The functions of importing and exporting environment alarms are added to M2000 V200R012C00.

WOFD-014100 Alarm Post-Processing on M2000 Availability This feature was introduced in M2000 V200R002.

Summary In alarm post-processing on the M2000, the M2000 allows users to perform a series of operations on the alarms stored in the database, such as acknowledging alarms, unacknowledging alarms, and collecting the statistics of alarms.

Benefits 

According to the requirements of the 3GPP specifications, alarm acknowledgment, alarm unacknowledgment, and status switch are supported to meet the requirements of network O&M scenarios.



The M2000 collects the statistics on alarms based on different conditions and displays the statistical results on the GUI so that users can directly learn about the alarm distribution on the network.


Acknowledging and unacknowledging alarms After users successfully acknowledge an alarm, its status automatically changes to "Acknowledged." The M2000 supports manual acknowledgment and automatic acknowledgment. In manual acknowledgment mode, users can select and acknowledge alarms in the alarm browsing window. In automatic acknowledgment mode, alarms can be automatically acknowledged according to the preset conditions. NOTE

Users can learn about the deta ils of alarm sources in the automatic alar m acknowledgment conditions by referring to the feature WOFD-010300 Alarm Viewer.

Users can unacknowledge the alarms that are acknowledged but not cleared. After an alarm is successfully unacknowledged, its status automatically changes to "Unacknowledged." The M2000 records the information about the time and the user who performs the related operations. 

Issue 02 (2013-07-20)

Collecting alarm and event statistics


33



Users can collect the statistics of alarms and events based on multiple conditions. The statistical results can be displayed in a table or pie chart. Supported statistical conditions are NE types, NEs, alarm/event names, severities, types, and status. Users can collect alarm statistics based on a maximum of three conditions. Users can save the statistical results as TXT, HTML, CSV, XLS, XLSX, or PDF files, or print the results. In addition, users can filter alarms before collecting statistics. The supported filter criteria are the same as the conditions described in the feature WOFD-010300 Alarm Viewer.

WOFD-012000 Automatic Alarm Clearing Availability This feature was introduced in M2000 V200R002.

Description When the fault on an NE or on the M2000 is rectified, the NE reports a cleared alarm and the M2000 sets the status of the corresponding fault alarm to "Cleared."

WOFD-011900 Manual Alarm Clearing Availability This feature was introduced in M2000 V200R002.

Description On the M2000 client, users can manually clear specified alarms. After an alarm is cleared, the M2000 changes the status of this alarm to "Cleared" and instructs the related NE to change the alarm status to "Cleared." This feature is used to clear the alarms that cannot be automatically cleared or the alarms that do not exist according to user confirmation.

WOFD-013300 Alarm Checking Availability This feature was introduced in M2000 V200R002.

Description This feature allows users on the M2000 client to check whether the status of a specified alarm is consistent on the M2000 and on NEs. If the status is inconsistent, the M2000 updates the alarm status.

WOFD-013900 Alarm Correlation View Availability This feature was introduced in M2000 V200R008. Issue 02 (2013-07-20)


34



Summary This feature is used for classifying NE alarms into root alarms and correlative alarms, depending on alarm generation causes. This feature allows O&M personnel to focus on root alarms in the case of excessive alarms. Generally, multiple correlative alarms may result from a root alarm. If a root alarm is cleared, most of its correlative alarms are cleared automatically.

Benefits Device O&M personnel can clear root alarms first so that most of the correlative alarms can be cleared automatically. Therefore, manual operations are reduced and maintenance efficiency is improved.


Analyzing alarm correlations When alarms are generated, NEs and the M2000 analyze the correlated alarms, identify root alarms and correlative alarms, and report analysis results to the M2000.



Displaying alarm correlations The M2000 displays the correlations between root alarms and correlative alarms in the alarm browsing window. This helps users to quickly locate faults. The M2000 displays correlations between root and correlative alarms in the alarm browsing window. Users can quickly and efficiently locate faults by checking alarm correlations. Users can disable this function if they do not require the correlated alarms reported by NEs. After this function is disabled, the M2000 does not display the correlations between root and correlative alarms reported from NEs.

Enhancement The following functions are added to M2000 V200R011C01: 

Displaying alarm correlations for USNs



Controlling the switch of alarm correlation display

In M2000 V200R010, this feature applies to the MSC Server, MGW, and SGSN. In M2000 V200R009, this feature applies to the BSC6900 GSM and GBTS.

Dependency This feature applies to eRAN1.0, G&U CS8.3, and G&U PS8.1 and later versions.

WOFD-012900 Alarm Information Base Availability This feature was introduced in M2000 V200R002.

Issue 02 (2013-07-20)


35



Description This feature allows users to record the explanations of alarms or events and the troubleshooting experience in the alarm information base through the M2000 client. The M2000 keeps the records in terms of the alarm/event ID. To facilitate maintenance experience sharing, the M2000 allows users to export the alarm information base as an XML, CSV, TXT, XLS, XLSX, HTML, or PDF file. It also allows users to import an external alarm information base as an XML file to append to or replace the original alarm information base on the M2000. The M2000 supports fuzzy search of maintenance experience information based on the names of alarms and events or keywords of maintenance experience information in the alarm knowledge library. The search criteria can be the names of alarms and events, keywords of maintenance experience information, or the combination of the names and keywords. This imp roves the efficiency of querying maintenance experience information. Users can also add comments to alarms and events to record the operations performed on the alarms and events. The change history (including the user, change time, and contents), is automatically saved in the comments.

Enhancement In M2000 V200R009, the M2000 supports fuzzy search of maintenance experience information based on the names of alarms and events or keywords of maintenance experience information.

WOFD-014500 AP Alarm Management Availability This feature was introduced in M2000 V200R010.

Summary In the uBro network, access points (APs) are devices on the user s ide and are managed by the AP Manager. NEs other than APs are managed by the M2000 such as AHR, AG, and IP Clock Server. To enable telecom operators to perform centrally routine maintenance on the uBro network, the M2000 provides the AP alarm management feature, including viewing AP alarms in real time, and querying, acknowledging, unacknowledging, and clearing AP alarms.

Benefits O&M personnel can monitor alarms on the entire uBro network through the M2000 without switching between the M2000 client and the AP Manager client. Therefore, problems are identified and solved in time and network maintainability and service quality are improved.

Description After users subscribe to AP alarms on the AP Manager, the AP Manager forwards the AP alarms to the M2000. After receiving the alarms, the M2000 displays the alarms on the GUI. On the M2000 client, users can view, acknowledge, unacknowledge, and clear AP alarms. Users can also post-process alarms, such as collecting the statistics on AP alarms and masking AP alarms. The specific features supported by the M2000 are as follows: 

Issue 02 (2013-07-20)

WOFD-010100 Centralized Storage of Alarm Information Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

36





WOFD-010300 Alarm Viewer



WOFD-014200 Real-Time Alarm Notification



WOFD-014000 Alarm Pre-Processing on M2000



WOFD-014100 Alarm Post-Processing on M2000



WOFD-011900 Manual Alarm Clearing



WOFD-012000 Automatic Alarm Clearing



WOFD-013300 Alarm Checking



WOFD-012900 Alarm Information Base

The M2000 collects AP alarms from the AP Manager instead of managing APs as individual NEs. Therefore, the M2000 allows users to set only AP Manager as the object condition for querying, viewing, and masking AP alarms on the M2000.

Enhancement None

Dependency Only telecom operators adopting Huawei uBro solution can use the AP alarm management feature. This feature depends on the feature COFD-120100 Real-Time Alarm Management of the AP Manager. Therefore, to use the feature WOFD-014500 AP Alarm Management, telecom operators must purchase the feature COFD-120100 Real-Time Alarm Management of the AP Manager.

WOFD-240400 Antenna Fault Detector – GBSS Availability This feature was introduced in M2000 V200R009.

Summary The faults on the antenna system and radio frequency (RF) channels are caused by the improper installation of projects when the projects are created, relocated, or optimized. The faults can also be caused by natural or external changes. The GBSS antenna fault detection system provides GUIs that are based on the B/S architecture. On the GUIs, the M2000 remotely detects and locates faults on GBSS antennas, which is more efficient than the previous onsite O&M mode. The client of the antenna management system accesses the server using HTTPS to ensure data transmission security.


This feature implements the detection of common antenna faults, improving the efficiency and accuracy of fault diagnosis.



By using this feature, RF engineers do not need to use equipment to measure BTSs on site every time, reducing the project cost.



This feature adopts the Browser/Server mode, which allows users to manage antennas through only the web browser instead of installing client software.

Issue 02 (2013-07-20)


37



Description The antenna system plays an important role in mobile communications. The performance of the entire network is affected by the following problems: 

Improper type or location of the antenna system



Incorrectly configured parameters of the antenna system



Faulty antenna system

This feature can be used to analyze and compare the performance measurement data of NEs, analyze the causes of antenna faults through algorithms, and generate analysis reports. This feature provides the following functions: 

Supporting antenna fault detection tasks The M2000 allows users to create wizard-based tasks, where users can set the NEs to be detected, the fault type, time range, start time, end ti me, and algorithm-related parameters. One task can detect multiple types of faults on multiple BTSs. Antenna fault detection is based on three algorithms: main and diversity level analysis algorithm, reversely connected cell analysis algorithm, and downlink problem analysis algorithm. Using these algorithms, the M2000 diagnoses possible faults on the antenna system, such as a main antenna fault, only one antenna, RX main and diversity cable fault on the TRX, RXU TX-RX mode error, and cable fault between RXUs, reversely connected cell antennas, and TX cable fault on the TRX. The M2000 allows users to manage detection tasks, including browsing task progress and task status, and creating, starting, stopping, and deleting tasks.



Generating antenna fault detection reports After an antenna fault detection task is complete, the M2000 generates a detection report in XLS format. A detection report consists of the summary information and a list of detailed results. The summary information includes the total number of NEs, total number of cells, analysis period, and problem statistics. The list of detailed results provides the detection results of all detected cells and TRXs based on the fault type. The M2000 also provides the data about main and diversity levels to help users understand the detection process.

Enhancement None

Dependency The function of analyzing main and diversity levels applies to 3012 and 3900 series base stations, while the function of analyzing downlink problems applies only to 3012 series base stations.

WOFD-240600 Antenna Fault Detector – WRAN Availability This feature was introduced in M2000 V200R010.

Issue 02 (2013-07-20)


38



Summary The antenna system receives and transmits signals on communication networks. Antenna faults are probably caused by improper installation during network setup, reparenting, or optimization, and they may also be caused by environment changes. These faults have severe impacts on network quality. To locate and rectify these faults, however, is expensive and time-consuming. In view of the previous difficulties, the antenna fault detection system provides GUIs that are based on the B/S architecture and the WRAN antenna connection detection function. This function helps engineers check whether antenna connections are correct so that engineers can rectify faults in time. This reduces subsequent troubleshooting and OPEX. The client accesses the server using HTTPS to ensure data transmission security.


During site deployment, engineers only need to perform dialing tests by using UEs, and the M2000 automatically detects antenna installation faults for engineers. This reduces OPEX because engineers do not need to travel to the site a second time.



This feature is based on the Browser/Server (B/S) architecture, which allows users to manage antenna line devices (ALDs) only by using a web browser instead of installing client software.

Description Cross-connection of antenna cables always affects neighbor relationship, cell coverage, or NodeB receiving sensitivity. Therefore, problems such as UE handover failure, call drop, and poor call quality may occur. Therefore, troubleshooting cross-connection of antenna cables in a timely manner is significant for ensuring the service quality of the network. Site engineers need to start data collection tasks on the M2000 to check for antenna faults. Before starting a data collection task, site engineering parameters and test UE information must be set. After starting a data collection task, site engineers use test UEs to perform dialing tests in all sectors of a NodeB. Then, the M2000 records location information and measurement data reported by the test UEs and the NodeB. The M2000 use the fault detection algorithm to check whether the antenna of the NodeB is properly connected. If the antenna is not properly connected, the M2000 provides correct antenna connection information. After checking the antenna connection, the M2000 displays the check results in a table and in a chart. Based on the check results, site engineers can reconnect the antennas. The table maps each NodeB to a record, which contains the RNC name, NodeB name, antenna location, configured sectors, connected sectors, and the status, start time, and end time of the check. Site engineers can export the check results to a file and save the file on a local PC. The chart displays the connections between antennas and RRUs in a topology view. Dialing tests need to be performed at an appropriate location for accurate check results. The M2000 displays NodeBs, sectors, cells, and the real-time locations of test UEs in a chart. If the location of a UE is not suitable for dialing tests, site engineers are prompted to adjust its location.

Issue 02 (2013-07-20)


39


2 Basic Features (WOFD-100000) NOTE

The detailed information about each detection record lists the antenna location, configured sectors, and actually connected sectors. Based on the information displayed in the list, engineers can correct the antenna connection.


Displaying the real-time locations of test UEs in a chart



Displaying check results in a chart

Dependency The test UE for the detection must be a PHU that supports the global positioning system (GPS). BTS3902E WCDMA is not configured with the previously mentioned ALDs, and therefore it does not support this feature.

2.3 Configuration Management WOFD-020100 Auto-Synchronization for Configuration Alteration Availability This feature was introduced in M2000 V200R002.

Description If the configuration of an NE is modified, the NE reports a modification notification to the M2000. Then, the M2000 updates the NE configuration data in the database according to the notification. This implements the automatic synchronization of configuration data and ensures the consistency of the configuration data between NEs and the M2000. Users can view the information about the latest automatic configuration data synchronization of each NE. The information contains the start time and end time of the synchronization, synchronization types, synchronization results, and result details.

Enhancement The function of browsing the information about automatic data configuration synchronization is added to M2000 V200R008.

WOFD-020200 Configuration Data Synchronization Availability This feature was introduced in M2000 V200R002.

Issue 02 (2013-07-20)


40



Summary To ensure that the configuration data between the M2000 and NEs is consistent, the M2000 supports manual and scheduled synchronization of configuration data. Users can view the information about synchronization tasks.

Benefits 

The M2000 provides manual and scheduled configuration data synchronization. The two synchronization modes enable users to control the synchronization progress and ensure that the configuration data between NEs and the M2000 is consistent.



The M2000 displays the detailed information about NE configuration data synchronization on the GUI, facilitating tracing and review of the configuration data.


Synchronizing configuration data The M2000 supports synchronizing configuration data manually or on a scheduled basis. In manual synchronization mode, users manually start a synchronization task on the M2000 client. The M2000 updates and stores the data in the M2000 database based on the current data obtained from NEs. The M2000 synchronizes configuration based on the period and time set by users and the range of NEs. If users do not set the period or time, the M2000 performs scheduled synchronization tasks according to the default settings. Users can set synchronization intervals by day. The intervals must be a multiple of one day. Scheduled synchronization tasks are managed by using the feature WOFD-071200 Centralized Task Manager.



Browsing configuration task information The M2000 displays, in a list, the current manual and scheduled data synchronization information about all NEs managed by the M2000. The information listed includes the start time, type, progress, and description of the synchronization. Users can save the information to a local PC as a file. After the synchronization is started, the M2000 automatically records the synchronization. After the synchronization is complete, the M2000 automatically deletes the record. In addition, users can view the information about the latest manual or scheduled configuration data synchronization. The M2000 displays, in a list, the execution information about the latest configuration data synchronization of all the NEs managed by the M2000. The list displays the information about the start and end time of the history configuration data synchronization tasks, synchronization types, synchronization results, and result details.

Enhancement The function of browsing the information about manual and scheduled configuration synchronization tasks is added to M2000 V200R008.

Dependency None

Issue 02 (2013-07-20)


41



WOFD-020400 Configuration Data Query Availability This feature was introduced in M2000 V200R002.

Summary The M2000 provides a window for viewing configuration data. It supports the functions of searching for and exporting NE configuration data.

Benefits The M2000 displays NE configuration data in a navigation tree and a table so that users can easily view the logical relationships between configuration objects and detailed configuration information.

Description The M2000 displays NE configuration data in an interface that contains a navigation tree in the left pane and a table in the right pane. The navigation tree displays NE configuration objects and their logical relationships. The table displays the details about selected configuration objects. The M2000 allows users to search for NE configuration data based on the keywords contained in configuration object names. It also allows users to locate the search results on the corresponding nodes in the navigation tree. In the window for viewing configuration data, users can select an NE to export its configuration data. The exported data can be saved as CSV and XML files. In addition, the M2000 displays the common configuration data of some objects as labels in the topology view. The common configuration data includes NE names, NE types, IP addresses, current version information, link names, link types, and names of the NE nodes at both ends of a link.

WOFD-020800 Object Management Status Monitor Availability This feature was introduced in M2000 V200R003.

Description The M2000 displays the information about and status of hardware and software resources on the GUI, which allows users to learn about the network status in real time. Users can set the range of the objects whose status is to be monitored. They can also add, delete, suspend, and resume monitoring tasks. The M2000 supports sorting the monitoring results b y the statuses and names of NEs and objects. Table 2-1 describes the resources and resource statuses that can be monitored by using this feature.

Issue 02 (2013-07-20)


42



Table 2-1 Object management status

NE Type

Object Type

Management Status

RNC

Cell

Administration status: unlocked, locked, shutting down Operating status: enable, disable Activation status: activated and deactivated Availability status: normal, faulty, intelligent shutdown, intelligent RF channel shutdown, and low-power consumption mode

NodeB node

Administration status: unlocked, locked, shutting down Takeover status: takeover, un-takeover

BSC6900 UMTS

CN node

CN node status: normal, off-load, and inhibited

Cell

Administration status: unlocked, locked, shutting down

BSC6900 GU

Operating status: enable, disable Activation status: activated and deactivated Availability status: normal, faulty, intelligent shutdown, intelligent RF channel shutdown, and low-power consumption mode NodeB node

Administration status: unlocked, locked, shutting down Takeover status: takeover, un-takeover

CN node

CN node status: normal, off-load, and inhibited

Destination signaling point code (DPC)


BSC6900 GSM

Cell

Operating status: enable, disable

BSC6900 GU

BTS node


Destination signaling point code (DPC)



Operating status: enable, disable DPC capability

eNodeB

Cell

Administration status: unlocked, locked, shutting down Operating status: enable, disable

eNodeB

License status: Default, Demo, Normal, Protected, Emergency Operating status: Starting, Software ready, Software not ready

Issue 02 (2013-07-20)


43


NE Type


Object Type

Management Status

Board

Administration status: unlocked, locked, shutting down Operating status: enable, disable Availability status: normal, fault, uninstalled, un-configured, inconsistent, power-off Usage status: idle, active, busy Standby status: active, standby

GGSN

Board


UGW

Board


MSC Server

Link

Operating status: enable, disable Congestion status: un-congested, congested Inhibited status: unblocked, locked, local locked, remote locked, local and remote locked Activation status: active, inactive Release status: unreleased, released

SGSN

Link


MGW

Link


Issue 02 (2013-07-20)


44



Enhancement The following functions are added to M2000 V200R008: 

Managing the status of the BSC6900 GSM SCCP DPC.



Board status management of the UGW.

WOFD-020900 Link Status Report Availability This feature was introduced in M2000 V200R003.

Description Link status reports are essential in the case of link disconnections or uncertain alarm prompts. This feature allows the M2000 to generate link status reports on a scheduled basis so that users can easily learn about network link statuses and locate link exceptions in time. 

The status reports of all the links of a selected NE can be displayed. The supported link types vary according to NEs. Table 2-2 describes the link types supported by NEs.

Table 2-2 Link types supported by NEs

NE Type

Link Type

SGSN

MTP3/MTP3B/MTP3/MTP3B/NSVC

MSC Server

M3UA/H248/MTP3B/MTP3/BICCSCTP

RNC

PPP/ML-PPP/RNC PPP group/IPPATH/SCTP

BSC6900 GSM/BSC6900 GU/BSC6900 UMTS/BSC6000 (GSM-R)

PPP/ML-PPP/PPP group/IPPATH/SCTP

Enhancement 

The following function is added to M2000 V200R008:



Supporting MSC Server links such as the H248 and the M3UA

WOFD-021000 Local Device Panel Availability This feature was introduced in M2000 V200R003.

Description The device panel provided by the LMT of an NE displays the subracks, boards, configuration, and alarms of NEs on the GUI. On the boards, users can perform common operations such as querying board statuses and resetting boards.

Issue 02 (2013-07-20)


45



After starting the LMT of a specified NE in the M2000 topology view and starting the device panel, users can check the hardware status in the topology view or perform routine maintenance of devices through shortcut menus. To ensure security of data transmission between LMTs and NEs, LMTs based on the iView platform support SSL-encrypted transmission, and web LMTs support HTTPS-encrypted transmission.

Dependency This feature is implemented on the LMT. If the NE LMT is based on the iView platform, users must install the NE LMT on the M2000 client before using this feature. If the NE supports a Web LMT, users do not need to install the NE LMT.

WOFD-022300 Centralized Device Panel Availability This feature was introduced in M2000 V200R008.

Summary The M2000 provides the centralized device panel function and graphically displays subracks, boards, and the status and alarm information about subracks and boards. On the device panel, users can perform common operations such as querying board states and restarting boards.

Benefits The graphical display of devices allows users to maintain NEs easily and improves the usability of the M2000. By using this feature, users can directly view the hardware status of devices and perform common operations on the device panel.

Description The M2000 implements centralized device panel management, which allows users to switch device panels of different NEs on the same GUI. The device panel graphically displays the physical locations and states of racks, subracks, and boards. In addition, the states can be updated in real time. The M2000 displays the following board states: null, unknown, uninstalled, unconfigured, inconsistent, starting up, power off, blocked normal, blocked faulty, faulty, active normal, and standby normal. The states are identified in different colors on the device panel. In addition, on the device panel, users can learn about the running status of boards according to the indicators of board states, fault bar, and the indicators of active alarms. Users can right-click a board and perform common O&M operations through shortcut menus, such as querying board status, alarms, CPU usage, inventory information, and resetting or blocking the board. Board status varies according to the board type, and shortcut menus supported by boards are slightly different. The device panel provides shortcut menus for common maintenance, such as querying board status, alarms, CPU usage, and inventory data, and resetting or blocking boards. The shortcut menus vary according to board states.

Issue 02 (2013-07-20)


46



If a BTS is configured with RRUs, the M2000 displays the physical topology relationships between RRUs and between RRUs and BBUs by displaying ports on the interface boards, RRUs, RRU chains, and CPRI ports. The physical network topology can be updated in real time, showing the RRU chains, CPRI ports, status, and device status. Connection states are normal, unconfigured, and uninstalled. The topology also provides common command portals, including querying board information, configuration parameters, extended parameters, and inventory information about RRUs, resetting boards, and querying CPRI port and SPF module information.


Centralized device panel for BTS3900 (co-MPT multimode base station)


Centralized device panel for the USU and eRelay


Querying the inventory data on boards through the device panel



Displaying the topology of CPRI ports



Detecting faults



Centralized device panel for BTS3902E WCDMA (micro NodeB) and BTS3202E (micro eNodeB)


Managing the SBC2600 device panel


Displaying the device panel of the RRU



Displaying the device panels of BSC6900 GSM, BSC6900 UMTS, BSC6900 GU and GBTS



Displaying the centralized device panels of GBTSs of 3900 series



Displaying the centralized device panels of NodeBV2, including the DBS3900 WCDMA, BTS3900 WCDMA, BTS3900A WCDM, and BTS3900L WCDMA

Dependency This feature applies to eRAN1.0 and later versions. This feature applies to SBC V200R008 and later versions.

WOFD-022000 Configuration Report Availability This feature was introduced in M2000 V200R008.

Issue 02 (2013-07-20)


47



Summary The M2000 provides the NE report, core network resource report, NE statistics report, link report, and RAN configuration report. Users can view the basic NE information, port resource information, NE version information, link information, base station configuration information, and cell configuration information presented by these reports through GUI. Users can also save the reports to a local PC or print the reports. In addition, the M2000 can periodically generate the configuration reports through centralized task management.

Benefits The M2000 provides various configuration reports according to configuration data types and O&M scenarios. Therefore, users can easily learn about the NE information, port resource information, link information, base station configuration information, and cell configuration information. This improves O&M efficiency.

Description The M2000 provides reports such as the RAN configuration report, core network resource report, and link report. Users can view these reports through the GUI. In addition, users can save the reports as XLS, XLSX, CSV, TXT, PDF, or HTML files. They can also print the reports. The configuration reports can be generated periodically through centralized task management. Users can set the report generation period in the unit of day. The data in each report is as follows: 

NE report An NE report contains basic NE information, such as NE names, types, versions, IP addresses, physical locations, vendors, districts, maintenance areas, status of the connection with the M2000, and capacity. The report also provides the total number of NEs and the number of disconnected NEs by NE type.



NE statistics report An NE statistics report allows users to query the version information about multiple NEs. The version information includes the NE type, NE versions involved in each type of NE, and number of NEs corresponding to each version.



Core network resource report A core network resource report allows users to query the resource information about multiple NEs. The resource information includes the NE name, NE type, number of 2 Mbit/s signaling ports, number of 2 Mbit/s trunk ports, number of 64 kbit/s signaling ports, number of FE ports, number of GE ports, number of CPUs, and update time.



Link report A link report allows users to query the link information about specified NEs. Only the SGSN, MSC server, and RNC support link reports. Table 2-3 describes the mapping between NE types and report types.

Issue 02 (2013-07-20)


48



Table 2-3 Link types supported by NEs

NE Type

Link Report Type

SGSN

N7 link report, N7 route report, MTP3B link report, NSVC report, and MTP3B route report

MSC Server

MTP3 link report and MTP3 route report

RNC/BSC6900 GSM/BSC6900 UMTS/BSC6900 GU

PPP link report, Multi-Link Point-to-Point Protocol (MLPPP) link report, PPP group link report, IPPATH link report, and SCTP signaling link report



RAN configuration report Users can view the configuration reports of a specified RAN. WRAN configuration reports contain the configuration reports of NodeBs and cells. GBSS configuration reports contain the configuration reports of GBTSs, cells, neighboring cells, external cells, TRXs, and channels. These reports provide an easy way for users to learn about the statuses of network resources. In WRAN configuration reports, the NodeB configuration report includes NodeB ID, NodeB name, NodeB type, subsystem No., RNC name, and NCP SAAL link No.. The cell configuration report includes cell ID, cell name, RNC name, NodeB ID, NodeB name, location area code (LAC), Service Area Code (SAC), routing area code (RAC), uplink frequency, downlink frequency, and maximum transmit power. In GBSS configuration reports, the BTS configuration report includes the name, index, type, and transfer mode of the BTS. The cell configuration report includes the name and index of cell and BTS, CGI, BCC, and NCC. The carrier configuration report includes BTS name and index, cell index, TRX index, cabinet No., frame No., slot No., board type, active state, frequency, level and type of power, TCH rate adjust allow, receive mode, and send mode. The channel report includes No. and type of channel, name and index of BTS, cell index, frequency index, hop index, hopping s equence No., training sequence code, and mobile allocation index offset (MAIO). The neighboring cell configuration report includes BTS name, cell index, neighboring 2G cell index, PBGT HO threshold, minimum access level offset, and BQ HO margin. The external cell configuration report includes BTS name, base station color code (BCC), NCC, index and name of cell, cell CI, MCC, MNC, inter-layer HO threshold, penalty on fast moving HO, minimum DL level on candidate cell, and cell priority.



MBTS relationship report An MBTS relationship report helps users know correlations between MBTSs and base stations that comprise the MBTSs. Such a report provides information about the names, ESNs, and capacities of MBTSs and base stations that comprise the MBTSs.

All the NEs support the NE report and NE statistics report. Some NEs support core network resource report, link report, MBTS relationship report, and RAN configuration report. For details, see the "Dependency" part.

Enhancement The following report is added to M2000 V200R013C01: 

MBTS relationship report

The following function is added to M2000 V200R012C00:

Issue 02 (2013-07-20)


49



Information about NE maintenance areas and connection status with the M2000 are added to an NE report.

The following functions are added to M2000 V200R009:  

NE report, core network resource report, NE statistics report, and link report. Various configuration reports can be automatically generated by using centralized task management.

Dependency The MGW and MSC server support the core network resource report. The SGSN, MSC server, BSC6900 GSM, BSC6900 UMTS, BSC6900 GU, and RNC support the link report. The RNC, NodeB, BSC6900 GSM, BSC6900 UMTS, BSC6900 GU, and GBTS support the RAN configuration report.

WOFD-021400 Dual Homing Configuration Management Availability This feature was introduced in M2000 V200R005.

Description The dual homing is a disaster tolerance mechanism that prevents the disconnection of mobile network services in the managed domain due to MSC Server, UGC or UAC system breakdown or system faults. This ensures that mobile networks are running securely and reliably. The following description is based on the MSC Server, which also supports the UGC and UAC. In dual homing networking mode, one MGW is controlled by t wo MSC Servers. The two MSC Servers are referred to as a dual homing pair. Normally, each MGW is registered only on the active MSC Server. When the active MSC Server is faulty, the MGW can be registered on the standby MSC Server to ensure the continuous and normal network communication services. The active and standby MSC Servers check the status of each other through heartbeats. The M2000 can automatically detect dual homing relationships and displays the relationships in the topology view. As one type of the basic data of the MSC Server, dual homing data is used to define virtual nodes, working modes, heartbeat links, and backup routes of dual homing. The M2000 supports the consistency check of dual homing data and generates comparison reports. Based on the check results, the M2000 can generate an MML adjustment script to modify inconsistent NE data. Users can manually send and run scripts on NEs to ensure the data consistency between dual homing MSC Servers. Users can send MML commands to one MSC Server or to both MSC Servers of a dual homing pair.

Issue 02 (2013-07-20)


50



WOFD-022100 Basic Configuration of CS Domain Availability This feature was introduced in M2000 V200R005.

Description A circuit switched (CS) domain is a set of the CN entities that provide CS domain services on mobile networks. This feature allows users to configure CS domains based on the configuration navigation tree.

Benefits The M2000 provides the graphical configuration function, which allows users to view and configure the configuration data of CS NEs and their MOs.

Description The M2000 provides a configuration navigation tree to display the logical relationships between each NE and its MOs on the CS network. The M2000 displays the property parameters of each MO on the interface that contains a navigation tree in the left pane and a table in the right pane. The MOs such as circuits and links are the basic units configured on the CS network. The basic CS navigation configuration supports the following functions: 

Viewing configuration data: Users can view the configuration data of each NE and its MOs in the CS domain. In addition, users can sort the viewing results.



Configuring NE data: On the interface for viewing configuration data, users can adjust the NE configuration data, such as adding MOs, deleting MOs, and modifying the property parameters. These operations can be performed in batches.



Viewing configuration operation records: When users adjust CS network parameters through the M2000, the M2000 automatically records and displays user operations.

WOFD-070200 Centralized MML for Configuration Availability This feature was introduced in M2000 V200R002.

Summary This feature allows users to concurrently send MML commands and MML scripts to multiple NEs on the M2000 client.

Description The centralized command line feature allows users to send MML commands to multiple NEs of the same type on the M2000 client. The CLI provides a command navigation tree organized by function, supports the predictive input technique and help information, and records executed commands. It also allows users to filter, search for, and sort NEs. Before executing a command that may have severe negative effects, the M2000 displays a message, informing

Issue 02 (2013-07-20)


51



users of the possible execution results. The M2000 executes the command only after users confirm the operation. The M2000 displays the execution results of MML commands on a GUI in real time. It also provides a result redirection function so that users can directly save the command execution results in a file. MML commands can be processed in batches. To implement this, users edit the MML commands to be executed in MML scripts, import the scripts to the M2000, and create a centralized task to deliver the scripts to NEs. After a script is executed, the M2000 provides statistics about the execution, including the number of successfully executed MML commands, number of unsuccessfully executed MML commands, and list of unsuccessfully executed MML commands. The M2000 centrally manages and schedules script tasks by using the feature WOFD-071200 Centralized Task Manager. When creating a task, users need to specify a script and set the execution mode (immediate execution or scheduled execution), running mode, redirection of the script result and NEs. According to the preset time, the M2000 sends the MML commands in sequence in the script to the selected NE or multiple NEs of the same type. If required, user can cancel the task during its execution.


The M2000 displays a message, which indicates the possible execution results before executing an MML command that may have severe negative effects.


The M2000 provides the statistical information about the task execution after an MML script task is completed.

Dependency Only GGSNV9R7C01 and earlier releases support this feature.

2.4 CME The CME features are modified in M2000 V200R012 for users to easily use and read. Basic CME features are combined based on configuration scenarios, and some optional features are changed to basic features. The following table describes the mapping between features in M2000 V200R012 and M2000 V200R011.

Feature ID and Name Before Optimization

Feature ID and Name After Optimization

WOFD-181500 Management of the Current and Planned Area

WOFD-186000 CME Basic Service

WOFD-182500 Automatic Discovery of RNCs and NodeBs – WRAN WOFD-265400 Automatic Discovery of BSCs and BTSs – GBSS

Issue 02 (2013-07-20)


52





WOFD-181600 Data Browse and Search WOFD-181700 Script Executor WOFD-183100 NodeB Configuration Template – WRAN WOFD-265700 BTS Configuration Template – GBSS WOFD-181514 eNodeB Configuration Template – LTE WOFD-260600 Cell Template Management – GBSS WOFD-184100 Cell Template Management – WRAN WOFD-188004 Cell Template Management – LTE WOFD-265200 CME Device Panel – GBSS WOFD-265600 Negotiated Data of batch BTS Creation – GBSS WOFD-266700 BTS Creation – GBSS

WOFD-186100 Network Initial Configuration – GBSS

WOFD-266000 Configuration of Neighboring Cell Relations – GBSS WOFD-266100 Import and Export of the Radio Network Planning Data – GBSS WOFD-265100 Device Data Configuration – GBSS WOFD-265200 CME Device Panel – GBSS WOFD-265500 Basic Configuration of Transmission Data – GBSS

WOFD-186110 Network Reconfiguration – GBSS

WOFD-265800 Basic Configuration of Abis – GBSS WOFD-261200 Abis Timeslots Advanced Configuration – GBSS WOFD-266400 Wizard for Batch Configuration of BTS Parameters – GBSS WOFD-266500 Wizard for Batch Configuration of TRX Parameters – GBSS WOFD-265900 Basic Configuration of Cells – GBSS WOFD-266000 Configuration of Neighboring Cell Relations – GBSS WOFD-185910 Interlocked Modification of Cell Parameters – GBSS WOFD-266100 Import and Export of the Radio Network Planning Data – GBSS WOFD-266200 Import and Export of the Radio Network Optimization Data – GBSS WOFD-266300 Wizard for Batch Configuration of Cell Parameters – GBSS

Issue 02 (2013-07-20)


53





WOFD-266800 BTS Reparenting in a Single BSC – GBSS WOFD-266600 Data Integrity Check in a Single BSC – GBSS

WOFD-186120 Parameter Consistency Check – GBSS

WOFD-182400 CME Device Panel – WRAN

WOFD-186200 Network Initial WOFD-183000 Import and Export of the Interface Negotiated Data – Configuration – WRAN WRAN WOFD-184000 IUB Transmission Configuration Wizard – WRAN WOFD-183900 NodeB Configuration Express – WRAN WOFD-183600 Batch Configuration of Radio Parameters – WRAN WOFD-183500 Import and Export of the Radio Network Planning Data – WRAN WOFD-182300 Device Data Configuration – WRAN WOFD-182400 CME Device Panel – WRAN WOFD-182600 RNC Pool Management – WRAN

WOFD-186210 Network Reconfiguration – WRAN

WOFD-182700 RNC MOCN Management – WRAN WOFD-182800 Basic Configuration of Transmission Data – WRAN WOFD-183000 Import and Export of the Interface Negotiated Data – WRAN WOFD-182900 Batch Configuration of the Objects Related to Transmission Properties – WRAN WOFD-183800 NodeB Network Topology – WRAN WOFD-183900 NodeB Configuration Express – WRAN WOFD-183200 Basic Configuration of Cells – WRAN WOFD-183300 Configuration of Neighboring Cell Relations – WRAN WOFD-185900 Interlocked Modification of Cell Parameters – WRAN WOFD-183500 Import and Export of the Radio Network Planning Data – WRAN WOFD-185700 Import and Export of the Radio Network Optimization Data – WRAN WOFD-183600 Batch Configuration of Radio Parameters – WRAN

Issue 02 (2013-07-20)


54





WOFD-183700 Wizard for Batch Configuration of Radio Parameters – WRAN WOFD-184200 Cell Frequency Re-configuration Wizard – WRAN WOFD-187000 Data Integrity Check in a Single RNC – WRAN

WOFD-186220 Parameter Consistency Check – WRAN

WOFD-181512 CME Device Panel – LTE

WOFD-186300 Network Initial WOFD-181520 Import and Export of the Interface Negotiated Data – Configuration – LTE LTE FDD/TDD WOFD-181515 eNodeB Creation – LTE WOFD-181518 Import and Export of the Radio Network Planning Data – LTE WOFD-181511 Device Data Configuration – LTE WOFD-181512 CME Device Panel – LTE WOFD-181513 Basic Configuration of Transmission Data – LTE

WOFD-186310 Network Reconfiguration – LTE

WOFD-181520 Import and Export of the Interface Negotiated Data – LTE WOFD-181516 Basic Configuration of Cells – LTE WOFD-181518 Import and Export of the Radio Network Planning Data – LTE WOFD-181517 Wizard for Batch Configuration of Radio Parameters – LTE WOFD-188008 MBTS Creation – SingleRAN

WOFD-186400 Network Initial Configuration – SingleRAN

WOFD-185200 CME MBSC Device Panel – SingleRAN

WOFD-186410 Network Reconfiguration – SingleRAN

WOFD-185300 CME MBTS Device Panel – SingleRAN WOFD-185600 MBTS Configuration Management – SingleRAN WOFD-185100 Common Resource Consistency Check – SingleRAN

Issue 02 (2013-07-20)


WOFD-186420 Parameter Consistency Check – SingleRAN

55



WOFD-186000 Basic CME Service Availability This feature was introduced in M2000 V200R010.

Summary The Configuration Management Express (CME) is an M2000's configuration solution for radio access technology (RAT) networks. It provides configuration data for NEs in wizard-, template-, and GUI-based modes.


With this feature, data on the live network is assigned to the current data area, and user-configured data is assigned to planned data areas. This allows multiple engineers to configure data in different planned data areas and ensures operation security.



Users can easily configure data by using the flexible data browsing and search functions.



Users can organize scripts as projects, and deliver and modify the projects on GUIs. They do not need to perform script-based tasks such as manually selecting NEs, scripts, execution policies, and dependencies. This improves operation accuracy.



Template and filter management helps users create base stations, cells, and neighboring cells, compare parameters, trace configuration parameter changes, and apply templates. This simplifies user operations and improves O&M efficiency.

Description Basic CME services include the following functions: 

Managing the current and planned data areas −

Current data area: A current data area mirrors the data on the live network. A radio access network (RAN) has only one current data area. Data in the current data area is read-only.

−

Planned data area: A planned data area is a replication of the current data area. Multiple users can plan configuration data of the same NE in their own planned data areas. Before a user activates the data in a planned data area, neither the data on the live network nor that in any other planned data area is affected. Planned data areas are categorized into public and private planned data areas. A public planned data area is available to users in the user group to which the creator belongs while a private planned data area is available only to the creator and administrators. A CME system supports up to 90 planned data areas.



Using attribute value changes (AVCs) to notify users of data changes in the current data area AVCs on the live network are sent to users in real time to notify users of configuration data changes. The CME AVC stores configuration data changes for seven days so users can query them. The queried configuration data changes can be exported as HTML, CSV, XLS, XLSX, PDF, or TXT files.



Issue 02 (2013-07-20)

Synchronizing data in the current data area


56


2 Basic Features (WOFD-100000) −

Manual synchronization: Users can manually synchronize data in the current data area with data on the live network.

−

Automatic synchronization: After the configuration data about NEs is modified, the CME automatically synchronizes data in the current data area with data on the live network.

−



Scheduled synchronization: The CME synchronizes data in the current data area based on tasks. It manages and schedules the tasks based on the feature WOFD-071200 Centralized Task Manager.

Highlighting and exporting modified data in planned data areas When users modify data in a planned data area, the CME highlights the added, modified, and deleted configuration data. In addition, the CME provides a modification report, which records the configuration data in the planned data area before and after the modification. The modification report can be exported as an HTML file.



Undoing data changes in planned data areas After a planned data area is created or synchronized with the current data area and before the data is exported as scripts, data modification operations (excluding NE addition and deletion) can be undone step by step within this period.



Dumping planned data areas A planned data area that is idle for a long time can be dumped from the database to a file, releasing database space and improving system performance. After being dumped, the planned data area can still be opened or deleted. Planned data areas can be automatically or manually dumped.



Checking for conflicting data in a planned data area When users configure data in a planned data area, data on the live network may change. As a result, activating the configuration data in the planned data area may fail because of data conflicts. To solve this problem, the CME provides a data check mechanism. This mechanism allows users to compare the configuration data between the planned and current data areas and locate conflicts before activating configuration data. After finding conflicting data, users can modify the data in the planned data area based on data check results. This ensures data consistency and improves the success rate of data activation. Conflicting data can be exported as a report in HTML format.



Providing a unified view The unified view centrally displays configuration data in data areas and allows users to browse and check configuration data of base station controllers, base stations, and cells in the data areas. The unified view is related to the configuration navigation window and therefore allows users to quickly locate specified configuration objects.



Browsing data in the configuration navigation tree The configuration navigation tree consists of a tree in the left pane and a table in the right pane. The CME displays all configuration objects and parameters in the configuration navigation tree for users to add, delete, and modify them. Data browse in the configuration navigation tree consists of the following sub-functions:

Issue 02 (2013-07-20)

−

Data filter: After a user enters certain filter criteria, the CME automatically filters out the data that meets the preset criteria.

−

Field display: Users can determine whether to display a field. By doing this, they can view key information clearly.

−

Data locating: After a user enters a field name, the CME automatically locates the column of the field.

−

Data export: The CME allows users to export the displayed data as a TXT file. Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

57





Record counting: The CME allows users to view the total number of records in a table.

Using a script executor After a user has configured data in a planned data area, the CME generates configuration scripts (in XML or MML format) based on all the data reconfiguration. Then, it delivers the scripts to NEs as a project by using the script executor. Users can process multiple NEs concurrently. They can create a maximum of 200 projects, each project containing one or more tasks, and each task mapping one configuration script. The script executor provides the following functions: −

Creating a project

−

Deleting a project

−

Pre-activating a project: Users can pre-activate a project to check script accuracy.

−

Activating a project: Users can make the configuration scripts in a project take effect on NEs.

−

Canceling an operation being performed on a project

−

Suspending or resuming a project

−

Activating a project on schedule

−

Monitoring the status of a project

−

Viewing script execution results

There are two script execution modes:



−

Break on failure: Script activation stops immediately when an error occurs. The activation resumes only after the error is rectified.

−

Best effort: If an error occurs during the activation of a configuration script, the script executor ignores the error and continues to activate other data. After the activation is complete, all the incorrect configuration data is submitted to users for rectification.

Managing templates The CME provides various templates and template management functions that help users prepare configuration data. Templates are in XML format and are associated with NE versions. The CME provides templates for controllers, base stations, cells, neighboring cells, external cells, frequencies, transport parameters, and radio parameters. Different NEs support different types of template. With the template management functions, users can perform the following operations:

Issue 02 (2013-07-20)

−

Customizing templates: Users can save data on the live network as templates.

−

Importing and exporting templates: CME templates can be exported as XML files, and XML files can be imported.

−

Deleting templates: User-defined templates can be deleted.

−

Setting template rights: A template creator can specify a user group for each template. Members of the user group can use this template.

−

Viewing templates: Users can view the configuration objects and parameters in templates.

−

Editing templates: Users can modify configuration parameters in templates and save the parameters in the current or other templates.

−

Upgrading templates: Users can upgrade a template from a source version to a target version.


58



Replacing templates: Users can replace an existing template by typing new cabinet and subrack numbers in it. Template browsing, editing, upgrading, and replacing functions are mapped with templates types and NE versions. For details about the mapping relationships, see CME Online Help.



Filter management Operations such as comparing parameters, tracing parameter changes, and applying templates involve a large number of parameters. To facilitate operations, the CME provides default filters and allows users to define filters so that the CME quickly filters out required parameters. The CME provides the following filter management functions: −

Customizing filters: Users can select configuration objects and parameters, and save them as a filter.

−

Editing filters: Users modify configuration parameters of various filters and save the parameters in the current or other filters.

−

Importing and exporting filters: Users can export filter files as XML files or import XML filter files into the CME.

−

Deleting filters: Users can delete user-defined filters.


Providing a unified view for base station controllers, base stations, and cells


Supporting external cell templates on LTE networks


Supporting Iur, Iu-CS, and Iu-PS transport parameter templates



Highlighting new, modified, and deleted configuration data in planned data areas



Undoing data changes in planned data areas

Dependency Excel 2003, Excel 2007, or Excel 2010 must be installed on the PC running the CME client. Users must purchase and install Microsoft Office in advance.

WOFD-186100 Network Initial Configuration – GBSS Availability This feature was introduced in M2000 V200R010.

Summary Network initial configuration is performed at the deployment phase for GSM networks. Initial configuration ensures that devices run properly and provide required service capability. Objects to be configured are BSCs and BTSs.

Issue 02 (2013-07-20)


59



After a BSC is connected to the M2000, users can configure the global data, device data, and transport data about the BSC by using the configuration navigation tree, device panel, or negotiated interface data import/export function. They can create BTSs, TRXs, and cells in the BTS topology view or by using the interface data batch import function. They can also create neighbor relationships by using the configuration navigation tree or network planning data batch import function.


Convenient and flexible modes for network initial configuration based on the scenario



Simplified site deployment and improved site deployment efficiency



Bidirectional neighbor relationships that ensure configuration data consistency

Description The following parameters are configured during BSC initial configuration: 

BSC global parameters BSC global parameters are the parameters that take effect on the entire BSC, such as the originating signaling point (OSP), destination signaling point (DSP), clock, and timer. BSC global parameters are configured in the configuration navigation tree. The configuration navigation tree, also known as a configuration express, consists of a tree in the left pane and a table in the right pane. The CME displays all configuration objects and parameters in the configuration navigation tree for users to add, delete, and modify them.



BSC device parameters BSC device parameters are the parameters about physical devices such as cabinets, subracks, and boards. BSC device parameters are essential for carrying upper-layer service data. Device parameters are configured on a device panel. The device panel displays the components of BSC physical devices. Users can view component attributes on the device panel. They can also add, delete, and modify parameters about the physical devices.



BSC transport parameters BSC transport parameters are interface parameters that ensure proper data transmission between NEs. The interfaces include the A, Ater, Gb, Pb, and Iur-g interfaces. Users can configure BSC transport parameters by using the configuration navigation tree or configure BSC transport parameters in batches by importing negotiated data about the A, Ater, and Gb interfaces.

BTSs are created using the CME. 

Creating a single BTS The CME provides the following BTS initial configuration functions: −

Creating BTSs:

−

Users can use a BTS template to create BTSs and configure basic BTS parameters in the BTS topology view.

−

Configuring BTS device data: Users can configure parameters of objects such as cabinets, boards, RF modules, and power modules on the device panel.

Issue 02 (2013-07-20)


60



Configuring BTS transport parameters: For TDM-based BTSs, users can configure secondary chains and Abis interface timeslots in the BTS topology view. For IP-based BTSs, users can configure parameters such as IP attributes, IP addresses, and IP routes in the configuration navigation tree.

−

Creating cells: In the BTS topology view, users can use a cell template to create cells and configure basic cell parameters, FH groups, and hopping antenna groups.

−

Creating TRXs: Users can add TRXs and configure TRX attributes in the BTS topology view.

− 

Checking/activating BTSs

Creating BTSs in batches The CME allows users to create BTSs in batches by using either of the following functions: −

Importing a negotiated BTS data file The CME allows users to create BTSs, TRXs, and cells in batches by importing a negotiated BTS data template that references BTS templates and cell templates. In this mode, a maximum of 50 BTSs can be created at a time. A BTS negotiated interface data template is an XLS or XLSM file that records the following data for BTS creation: BTS basic parameters, BTS transport parameters, cell basic parameters, and TRX basic parameters.

−

Importing a summary data file The CME allows users to quickly create BTSs, TRXs, and cells in batches and add neighboring cells and external cells at the same time by i mporting data using a default or user-defined summary data file. In this mode, a maximum of 50 BTSs can be created at a time. A summary data file is an XLS or XLSM file that contains planned data required for creating BTSs in batches. It can contain the following data: BTS basic parameters, transport parameters, cell basic parameters, information about neighboring GSM, UMTS, and LTE cells and external cells, and IBCA neighboring cell groups. When a summary data file is used, it references a BTS template and cell template. The file and templates simplify data editing during BTS creation. The CME provides a tool for customizing summary data files. Using this tool, users can customize objects and parameters required for BTS creation. For example, users can design the data file and edit NE configuration objects and the mappings between data in the file.

The CME allows users to create neighbor relationships in the following modes: 

Configuring neighbor relationships in the configuration navigation tree In the configuration navigation tree, users can add or delete neighboring GSM, UMTS, and LTE cells in batches for GSM cells by referencing neighbor relationship templates. The CME also allows users to configure bidirectional neighbor relationships for GSM and UMTS cells to ensure that MSs are properly handed over between these cells.



Importing network planning data in batches By importing network planning data, users can create neighbor relationships in batches. A network planning template is an XLS, XLSM, or TXT file that contains user-planned data about neighboring GSM, UMTS, and LTE relationships, external cells, and IBCA neighboring cell groups. The CME also allows users to configure bidirectional neighbor

Issue 02 (2013-07-20)


61



relationships for GSM, UMTS, and LTE cells to ensure that MSs are properly handed over between these cells.


Creating base stations on a unified GUI


Importing and exporting negotiated Gb interface data


Customizing summary data files


WOFD-186110 Network Reconfiguration – GBSS Availability This feature was introduced in M2000 V200R010.

Summary Network reconfiguration applies to network expansion and routine maintenance scenarios. Users need to reconfigure the device, transport, and radio data about BSCs and BTSs in the following modes: configuration navigation tree, device panel, batch modification center, planned data import/export, and interlocked modification.


Graphical reconfiguration modes simplify data reconfiguration procedures and ensure data correctness.



The batch modification center and planned data import/export function significantly improve data reconfiguration efficiency.



Interlocked modification and bidirectional neighbor relationships ensure data consistency across the entire network.

Description The CME provides the following network reconfiguration modes: 

Issue 02 (2013-07-20)

Configuration navigation tree: It is also known as a configuration express. It consists of a tree in the left pane and a table in the right pane. The CME displays all configuration objects and parameters in the configuration navigation tree for users to add, delete, and modify them.


62



Device panel: The device panel displays the components of BSC physical devices. Users can view component attributes on the device panel. They can also add, delete, and modify parameters about the physical devices.



Batch modification center: The CME allows users to change the values of parameters in batches under a specified object for NEs of the same version in the planned data area.



BTS topology view: The BTS topology view displays the networking relationships, physical connections, and information about the ports between BTSs and BSCs or between BTSs. In this view, users can perform operations such as configuring cells, TRXs, and Abis timeslots.



The configuration wizard presents users with a sequence of dialog boxes that lead users with a series of well-defined steps. In the configuration wizard, correlated operations such as deleting cells in batches, configuring the ring network, Abis bypass mode, BTS multiplexing ratio, and Flex Abis assignment mode are easy to perform.



Planned data import/export: The CME allows users to batch-configure objects and parameters by importing and exporting a data planning template for onsite network planning and network optimization data. Users can import and export network planning data, cell parameters, neighboring cell BA data, cell frequency data, and TRX parameters.



Interlocked modification: In routine maintenance scenarios such as frequency optimization, frequency refarming, and LAC optimization, users need to adjust cell parameters such as LACs, BCCs, NCCs, and BCCHs. When users modify cell parameters in the configuration navigation tree, batch modification center, or planned data import-export mode, the CME automatically triggers interlocked modification for external cell parameters under GSM, UMTS, and LTE NEs. This ensures parameter consistency.

Network reconfiguration involves device data, transport data, and radio data. Reconfiguring device data: 

Reconfiguring BSC device parameters −

Reconfiguring BSC global parameters in Configuration Navigation Tree mode or Batch Modification Center mode In the configuration navigation tree, users can reconfigure BSC global parameters such as the OSP, DSP, clock, and timer. In the batch modification center, users can batch-reconfigure common BSC global parameters such as the basic attributes, timer parameters, and clock mode.

−

Reconfiguring BSC device parameters in Device Panel mode On the device panel, users can reconfigure parameters about BSC devices such as cabinets, subracks, and boards. These parameters are essential for carrying upper-layer data.



Reconfiguring BTS device parameters −

Reconfiguring basic BTS parameters in Configuration Navigation Tree, Batch Modification Center, or General Configuration mode In the configuration navigation tree, users can reconfigure BTS basic parameters such as BTS name, clock type, transmission mode, and alarm attributes. In the batch modification center, users can batch-reconfigure common BTS basic parameters such as clock type, alarm attributes, and extended attributes. In the general configuration window, users can reconfigure basic BTS parameters.

−

Issue 02 (2013-07-20)

Reconfiguring BTS device parameters in Device Panel mode


63



On the device panel, users can reconfigure parameters about BTS devices such as cabinets and boards. These parameters are essential for carrying upper-layer data. Reconfiguring transport data: 

Reconfiguring BSC transport parameters in Configuration in Configuration Navigation Tree mode In the configuration navigation tree, users can reconfigure BSC transport parameters such as A, Ater, Gb, Pb, and Iur-g interface data. This ensures proper transmission between NEs.



Reconfiguring BTS transport parameters: −

Reconfiguring transport parameters parameters for IP-based BTSs in Configuration in Configuration Navigation Tree mode In the configuration navigation tree, users can reconfigure BTS transport parameters such as IP attributes, IP addresses, and IP routes. This ensures proper transmission between Abis interfaces.

−

Reconfiguring transport parameters for TDM-based BTSs in BTS Topology View mode or Configuration Configuration Wizard mode The BTS topology view provides a configuration wizard, allowing users to configure BTS transport parameters such as secondary chain, ring network, Abis bypass mode, BTS multiplexing ratio, and Flex Abis assignment mode. This ensures proper transmission between Abis interfaces.

−

Reconfiguring timeslots for TDM-based BTSs in BTS in BTS Topology View mode In the BTS topology view, users can view the status of Abis timeslots under a BTS, such as assigned timeslots, idle timeslots, monitoring timeslots, forbidden timeslots, OML timeslots, transparent transmission timeslots, and manually allocated timeslots. In addition, the CME allows users to collect and export statistics about the Abis E1 timeslot resource file for TDM-based BTSs across the entire network. When assigning timeslots, users can reference the statistics, which consist of the E1 port usage and timeslot resources for TDM-based interfaces boards and BTSs. The exported files are in XLS, XLSM, CSV, or TXT format.



Intra-BSC BTS reparenting The CME provides a reparenting function. By using this function, users can reconfigure BTS connection attributes according to site requirements. Then, the CME automatically completes the reconfiguration process. During intra-BSC BTS reparenting, the logical homing relationships between the BTSs and the BSC and relationships between cells and neighboring cells under these BTSs remain unchanged. Therefore, the CME automatically ensures the consistency of neighbor relationships. A maximum number of 50 BTSs can be reparented at a time under one BSC. Users can reconfigure transport data by using the general configuration and batch reconfigured data import functions.

Reconfiguring radio data: 

Expanding cell capacity and reconfiguring data −

Creating and deleting cells in BTS in BTS Topology View mode, Batch mode, Batch Cell Deletion Wizard mode or Expanding/Reducing Wizard Wizard In the BTS topology view, users can add cells for a specified BTS and to set cell basic parameters parameters based on the planned data. data. This ensures radio area coverage coverage for cells under the BTS. Users can delete cells in batches under controllers of the same version. When deleting cells, they can also delete their external cells and neighboring cells under GSM, UMTS, and LTE LTE NEs inside the planned data area.

Issue 02 (2013-07-20)


64



Users can create and delete cells through Expanding/Reducing Wizard. Wizard. −

Reconfiguring cell parameters in Configuration in Configuration Navigation Tree mode, Batch mode, Batch Modification Center mode, Cell mode, Cell Parameter P arameter Import-Export mode, or Interlocked Interlocked Modification mode In the configuration navigation tree, users can reconfigure cell algorithm parameters such as cell basic parameters, idle mode, and parameters related to call control, handover control, power control, and channel management. Cell algorithm parameters can can also be reconfigured reconfigured in batches in batch modification modification center mode or cell parameter import-export mode.

−

Reconfiguring frequency-refarming frequency-refarming parameters in BTS in BTS Topology View mode or Cell Cell Frequency Data Import-Export mode By reconfiguring cell FH groups in the BTS topology view, view, users can implement network optimization, frequency multiplexing, and interference balancing. By importing and exporting cell frequency data, users can configure frequencies and FH attributes in batches. Cell frequency data includes cell basic attributes, cell frequencies, TRX frequencies, frequencies, TRX FH mode, channel FH mode, and FH groups.

−

Reconfiguring parameters parameters in the cell BA table in BTS in BTS Topology View mode or Neighboring Cell BA Data Import-Export Import-Export mode By reconfiguring parameters in the cell BA table in the BTS topology view, users can configure neighboring cells properly. properly. By importing and exporting of neighboring cell BA parameters, users can reconfigure cell BA tables in batches. Neighboring cell BA tables are BA1 and BA2 tables for neighboring GSM, TDD, and FDD cells.



Reconfiguring TRX parameters −

Creating and deleting TRXs in BTS in BTS Topology View mode or Expanding/Reducing Expanding/Reducing Wizard TRXs are used for transmitting and receiving radio signals between BTSs and MSs. When the network capacity is insufficient, users can add TRXs for specific cells in the BTS topology view, configure TRX parameters, and activate the TRXs. This improves the capability for transmitting and receiving radio signals and expands the network capacity. Users can create and delete TRXs through Expanding/Reducing Wizard. Wizard.

−

Reconfiguring TRX parameters in Configuration in Configuration Navigation Tree mode, Batch mode, Batch Modification Center mode, or TRX TRX Parameter Import-Export mode In the configuration navigation tree, users can reconfigure TRX parameters such as TRX power, TRX attributes, channel type, and channel attributes. By doing this, users can replan network frequencies, reduce intra-frequency and neighboring frequency interference, interference, optimize frequencies across the entire network, and therefore optimize performance counters. These parameters parameters can also be reconfigured in batches in batch modification center mode or TRX parameter import-export mode.



Reconfiguring neighbor relationships and external cell parameters in Configuration in Configuration Navigation Tree mode or Network Network Planning Data Import-Export mode In the configuration navigation tree, users can add or delete neighboring GSM, UMTS, and LTE LTE cells in batches for GSM cells by referencing neighbor relationship templates. The CME also allows users to configure bidirectional neighbor relationships for GSM and UMTS cells to ensure that MSs are properly handed over between these cells. By importing network planning data, users can create neighbor relationships in batches. The CME verifies the data before the import and provides a report after the import. A network planning template is an XLS, XLSM, or TXT file that contains user-planned data about neighboring GSM, UMTS, and LTE relationships, external cells, and IBCA

Issue 02 (2013-07-20)


65



neighboring cell groups. The CME also allows users to configure bidirectional neighbor relationships for GSM, UMTS, and LTE cells to ensure that MSs are properly handed over between these cells.


Carrier resource management



Allowing users to create and delete cells and TRXs through Expanding/Reducing Wizard Wizard

The following function is added to M2000 M 2000 V200R012C00: V200R012C00: 

Supporting interlocked modification for cell parameters with eNodeBs



Reconfiguring BTS transmission modes using in Configuration Wizard Wizard mode


Supporting interlocked modification for cell parameters with UMTS NEs



Deleting cells in batches



Excel 2003, Excel 2007, or Excel 2010 must be installed on the PC running the CME client. Users must purchase and install Microsoft Office in advance.



Reconfiguring BTS transmission modes using in Configuration Wizard Wizard mode needs the customized software and dedicated services of Huawei which are not included in this feature.

Dependency

WOFD-186200 Network Initial Configuration – WRAN Availability This feature was introduced in M2000 V200R010.

Summary Network initial configuration configuration is performed at the deployment deployment phase for UMTS UMTS networks. Initial configuration ensures that devices run properly and provide required service capability. After an RNC is connected to the M2000, users can configure the global, device, and transport data about the RNC by using the configuration navigation tree or device panel provided by the CME, or by importing negotiated interface interface data in batches. They can create create NodeBs and cells on GUIs GUIs or create them them in batches by importing importing interface data. They can also create neighbor relationships by using the configuration navigation tree or by importing network planning data in batches.








Bidirectional neighbor relationship configuration for ensuring configuration data consistency

Issue 02 (2013-07-20)


66



Description The following parameters are configured during RNC initial configuration: 

RNC global parameters RNC global parameters are parameters on the entire RNC, such as the telecom operator information, system information, clock mode, time zone information, OSP, and transmission resource mapping (TRM) information. BSC global parameters are configured in the configuration navigation tree. The configuration navigation tree, also known as a configuration express, consists of a tree in the left pane and a table in the right pane. The CME displays all configuration objects and parameters in the configuration navigation tree for users to add, delete, and modify them.



RNC device parameters RNC device parameters are the parameters about physical devices such as cabinets, subracks, and boards. RNC device parameters are the basis for carrying upper-layer service data. Device parameters are configured on a device panel.



RNC transport parameters RNC transport parameters are interface parameters that ensure proper data transmission between NEs. The interfaces interfaces include Iur, Iur, Iu-CS, Iu-PS, Iu-PS, Iu-BC, Iu-PC, Iu-PC, Gi, and Iur-g interfaces. Users can configure RNC transport parameters by using the configuration navigation tree or configure Iur, Iu-CS, and Iu-PS interface data in batches by importing i mporting negotiated data about the Iu/Iur interfaces.



RNC radio global algorithm parameters RNC radio global algorithm parameters are parameters parameters on the entire RNC, such as the flow control switch, load control, direct retry algorithm parameters, handover algorithm parameters, channel channel management parameters, parameters, and MBMS configuration. configuration. These parameters are are configured in the configuration configuration navigation tree. tree.

The CME allows users to create a single NodeB or create NodeBs in batches: 

Creating a single NodeB on the GUI In the configuration navigation tree, users can create a logical NodeB and perform the following operations: −

Configure basic data about the logical NodeB, such as basic information, algorithm parameters, and and overload control parameters. parameters.

−

Configure Iub interface data on the RNC side in ATM, IP, or ATM/IP dual-stack mode, such as physical layer data, interface control plane data, user plane data, and management plane data.

−

Create cells under a single logical NodeB in the configuration navigation tree by using cell templates.

The CME allows users to create physical and logical NodeBs using a unified base station creation wizard. When using the wizard to create NodeBs, users can specify the RNC information so that the CME automatically creates the corresponding logical NodeBs when it creates physical NodeBs under the RNC. If a logical NodeB already exists, the CME automatically correlates it with the corresponding physical NodeB. Using a NodeB template, users can create physical NodeBs in batches and perform the following operations: −

Issue 02 (2013-07-20)

Configure basic information about the physical NodeB in the configuration navigation tree, such as IP address of the NodeB local maintenance channel, basic


67



NodeB attributes, time zone, clock source, and active/standby mode of transmission interface boards. −

Configure device data about the physical NodeB on the device panel, such as data about cabinets, boards, RF modules, monitoring units, power modules, and antenna line devices (ALDs).

−

Configure transport data about the physical NodeB, such as the physical link data and transmission link data about the ATM- or IP-based NodeB

−

Configure radio data about the physical NodeB, such as site data, sector data, uplink/downlink baseband resource group data, cell data, and cell-related data.

−



Reconfigure objects related to cells, sectors, and TRXs using the carrier resource management function. The carrier resource management function provides a smart configuration mode. In this mode, the CME automatically generates radio data about objects such as the sector equipment, sector equipment antennas, and sector antennas, based on the configured cells, sectors, and TRX transmit channels.

Creating NodeBs in batches The CME allows users to create NodeBs in batches in either of the following modes: −

Importing negotiated Iub interface data Using NodeB templates, users can import negotiated Iub interface data that contains physical NodeB data. They can configure Iub interface data about the logical and physical NodeBs. Using cell templates, users can add cells in batches for the logical NodeB by import network planning data. Then, NodeBs are created in batches. In this mode, a maximum of 50 NodeBs can be created at a time. In the configuration navigation tree, users can reconfigure the basic information and radio data about the logical NodeB and the physical NodeB. On the device panel, users can reconfigure the device parameters of the physical NodeB. Using cell templates, users can import cell parameters in batches to modify cell algorithm parameters in batches. By importing network planning data in batches, users can reconfigure radio data about the physical NodeB, such as cell ID, local cell frequency, power, and cell radius. The negotiated Iub data template that contains physical NodeB data is an XLS or XLSM file that records the data required for creating NodeBs. It consists of the Iub interface data on the RNC side and Iub interface data on the physical NodeB side.

−

Importing a summary data file The CME provides a tool for customizing summary data files. Users can define objects and parameters by using this customization tool. The customization tool allows users to customize a summary data file and edit the mappings between collected data and NE configuration objects. Then, the tool automatically generates user-defined sheets for the summary data file. In this mode, a maximum of 50 NodeBs can be created at a time.

The CME allows users to create neighbor relationships in the following modes: 

In the configuration navigation tree In the configuration navigation tree, users can add or delete neighboring GSM, UMTS, and LTE cells in batches for UMTS cells by referencing neighbor relationship templates. The CME also allows users to configure bidirectional neighbor relationships for GSM and UMTS cells to ensure that MSs are properly handed over between these cells.



Importing network planning data By importing network planning data, users can create neighbor relationships in batches. A network planning template is an XLS, XLSM, or TXT file that contains basic parameters of UMTS cells, neighboring GSM, UMTS, and LTE cell relationships, and

Issue 02 (2013-07-20)


68



data about external cells. The CME also allows users to configure bidirectional neighbor relationships for GSM, UMTS, and LTE cells to ensure that MSs are properly handed over between these cells.


Creating base stations on a unified GUI



Creating base stations using a summary data file



Carrier resource management function for SRAN8.0 base stations




WOFD-186210 Network Reconfiguration – WRAN Availability This feature was introduced in M2000 V200R010.

Summary Network reconfiguration reconfiguration applies to network expansion expansion and routine maintenance maintenance scenarios. Users need to reconfigure the device, transport, and radio data about RNCs and NodeBs in the following modes: configuration navigation tree, device panel, batch modification center, planned data import/export, import/export, and interlocked modification. modification. The CME provides typical functions for network service reconstruction, such as reconfiguring RNC pools, multioperator core network (MOCN) cells, High Speed Packet Access (HSPA) (HSPA) cells, and IP pools in batches.





The batch modification center and planned data import/export function significantly improve data reconfiguration efficiency. efficiency.



Interlocked modification and bidirectional neighbor relationships ensure data consistency across the entire network.

Description The CME provides the following network reconfiguration modes:

Issue 02 (2013-07-20)


69








Device panel: The device panel displays the components of physical devices such as cabinets and boards. Users can view component attributes on the device panel. They can also add, delete, and modify parameters about the physical devices.



Batch modification center: The CME allows users to change the values of parameters in batches under a specified specified object for RNCs RNCs of the same version version in the planned data area. area.



Iub batch configuration center: The CME allows users to add and delete Iub transmission data in batches. Users can easily select required physical layer links and planned parameters for configuring the transport data about the NodeBs under an RNC in batches.



NodeB topology browse: browse: The CME displays displays the cascading relationships relationships between physical NodeBs under an RNC in a navigation navigation tree in the left left pane and a table in the right pane. The navigation tree in the left pane shows the parenting relationships between NodeBs, while the table in the the right pane shows the basic basic information about the selected NodeB, such as NodeB NodeB name, NodeB type, NodeB serial number and version number, number, and parent node name.



Configuration wizard: The configuration wizard presents users with a sequence of dialog boxes that lead users with with a series of well-defined well-defined steps. In the configuration configuration wizard, correlated operations such as modifying physical NodeB parameters in batches, changing frequencies, and deleting cells and logical NodeBs in batches are easy to perform.



Interface data and planned data import/export: The CME allows users to batch-configure objects and parameters by importing and exporting a data planning template for onsite network planning and network optimization data. The CME allows users to import and export the following planned data in batches: negotiated Iub interface data, negotiated Iub interface data containing physical NodeB data, network planning data, and cell parameters.



Interlocked modification: In routine maintenance scenarios such as algorithm parameter optimization, users need to adjust cell parameters such as LACs, frequencies and scrambling codes. When users modify cell parameters in the configuration navigation tree, batch modification center, or planned data import-export mode, the CME automatically triggers interlocked modification for external cell parameters under GSM, UMTS, and LTE NEs. This ensures parameter consistency.

Network reconfiguration reconfiguration involves device data, transport data, and radio radio data. It also supports supports the reconstruction of typical network services. Reconfiguring device data: 

Reconfiguring RNC device parameters −

Reconfiguring RNC global parameters in Configuration Navigation Tree mode or Batch Modification Center mode In the configuration navigation tree, users can reconfigure RNC global parameters such as the telecom operator information, system information, clock mode, time zone information, OSP, and TRM mappings. In the batch modification center, center, users can batch-reconfigure batch-reconfigure common RNC global parameters such such as the RNC timer parameters and clock clock mode.

−

Issue 02 (2013-07-20)

Reconfiguring RNC device parameters parameters in Device Panel mode


70



On the device panel, users can reconfigure parameters about RNC devices such as cabinets, subracks, and boards. These parameters are the basis for carrying upper-layer upper-layer data. 

Reconfiguring NodeB device parameters −

Reconfiguring basic NodeB parameters in Configuration in Configuration Navigation Tree mode or Batch Modification Center mode In the configuration navigation tree, users can reconfigure the basic information about the logical NodeB and that about the physical NodeB, such as NodeB algorithm parameters, NodeB OLC parameters, IP address of the NodeB local maintenance channel, basic attributes of the physical NodeB, N odeB, time zone, clock source, and active/standby mode of transmission interface boards. In the batch modification center, center, users can batch-reconfigure batch-reconfigure commonly-used basic parameters about about logical NodeBs, such as NodeB algorithm parameters and LDR LDR parameters.

−

Reconfiguring device parameters parameters about physical NodeBs in the the Device Device Panel mode On the device panel, users can reconfigure parameters about NodeB devices such as cabinets, boards, RF modules, and power modules. These parameters are the basis for carrying upper-layer data.

Reconfiguring transport data: 

Reconfiguring RNC transport parameters in Configuration in Configuration Navigation Tree mode In the configuration navigation tree, users can reconfigure RNC transport parameters such as the Iur, Iur, Iu-CS, Iu-PS, Iu-BC, Iu-PC, Gi, and Iur-g interface data. This ensures proper transmission between between NEs. Reconfiguring Reconfiguring NodeB transport transport parameters: −

Expanding transmission capacity in Configuration in Configuration Navigation Tree mode, Iub mode, Iub Batch Configuration Center mode, Iub mode, Iub Data Import-Export Containing Physical NodeB Data mode, or NodeB NodeB Topology Browse mode In the configuration navigation tree, users can configure the Iub interface data about an ATM- or IP-based logical NodeB and physical NodeB to ensure proper transmission between Iub interfaces. In the Iub batch configuration center, users can batch-configure the following transport configuration objects for an ATM-based logical NodeB: NBAP, Adjacent Node, AAL2 Route, AAL2PA AAL2PATH, NodeB IP Address, IPoA PVC. They can batch configure the following transport configuration objects for an IP-based logical NodeB: NBAP, NBAP, Adjacent Adjacent Node, IP IP Path, and NodeB NodeB IP Address. By importing and exporting negotiated Iub interface data, users can batch-configure the Iub interface data for ATM- or IP-based logical NodeBs. By importing and exporting negotiated Iub interface data that contains physical NodeB data, users users can batch-configure batch-configure the Iub interface interface data for ATM- or IP-based IP-based logical NodeBs and physical NodeBs.

−

Reconfiguring NodeB transport parameters in Configuration in Configuration Navigation Tree mode, Iub Data Import-Export mode, Iub mode, Iub Data Import-Export Containing Physical NodeB Data mode, Physical mode, Physical NodeB Batch Configuration Wizard mode, or NodeB Topology Management mode In the configuration navigation tree, users can configure the Iub interface data about an ATM- or IP-based logical NodeB and physical NodeB to ensure proper transmission between Iub interfaces. By importing and exporting negotiated Iub interface data, users can batch-configure the Iub interface data for ATM- or IP-based logical NodeBs.

Issue 02 (2013-07-20)


71



By importing and exporting negotiated Iub interface data that contains physical NodeB data, users can batch-configure the Iub interface data for ATM- or IP-based logical NodeBs and physical NodeBs. By using the NodeB batch configuration wizard, users can modify the following primary parameters of physical NodeBs under an RNC in a planned data area: IMAGRP, IPOA, PPPOE, IPPATH, MPGRP, DEVIP, PPP, AAL2NODE, SNTP, and SCTP. In the NodeB topology view, users can drag a NodeB in the navigation tree in the left pane to change the cascading relationships between the NodeB and the RNC and between the NodeB and other NodeBs. Reconfiguring radio data: 

Reconfiguring global radio parameters in Configuration Navigation Tree mode or Batch Modification Center mode In the configuration navigation tree, users can configure global radio algorithm parameters of the RNC, such as process control switch, load control, direct retry algorithm parameters, handover algorithm parameters, channel management parameters, and multimedia broadcast and multicast service (MBMS) parameters. These parameters can also be reconfigured in batches in the batch modification center.




Creating or deleting cells in Configuration Navigation Tree mode, Network Planning Data Import-Export mode, and Batch Cell Deletion Wizard mode By using cell templates, users can add cells in batches under a logical NodeB by importing and exporting network planning data. A network planning data template contains basic parameters of UMTS cells, neighboring GSM, UMTS, and LTE relationships, and information about external cells. In the configuration navigation tree, users can add or delete cells from physical NodeBs. Users can delete cells in batches under controllers of the same version. When deleting cells, they can also delete their external cells and neighboring cells under GSM, UMTS, and LTE NEs inside the planned data area.

−

Reconfiguring cell parameters in Configuration Navigation Tree mode, Batch Modification Center mode, Cell Parameter Import-Export mode, Interlocked Modification mode, Physical NodeB Batch Configuration Wizard mode, or Network Planning Data Import-Export mode In the configuration navigation tree, users can reconfigure the basic parameters and algorithm parameters of cells. These parameters can also be reconfigured in batches by using the batch modification center or by using the cell parameter import/export function. Parameters for cells under physical NodeBs can be modified in batches by using the physical NodeB batch configuration wizard or network planning data import/export function.

−

Reconfiguring frequency parameters in Frequency Modification Wizard mode or Network Planning Data Import-Export mode The CME provides a cell frequency reconfiguration wizard that allows users to modify frequencies and scrambling codes for specified cells under RNCs and external cells. Parameters that can be modified in batches include cell frequency bands, cell uplink/downlink frequencies, and cell primary scrambling codes. When modifying frequencies or scrambling codes for specified cells under RNCs in batches, the CME modifies the frequencies or scrambling codes for corresponding

Issue 02 (2013-07-20)


72



local cells under physical NodeBs and those for corresponding external cells in the planned data area. At the same time, the CME updates neighbor relationships. When modifying frequencies or scrambling codes for specified external cells in batches, the CME updates only neighbor relationships. 

Reconfiguring neighbor relationships and external cell parameters in Configuration Navigation Tree mode or Network Planning Data Import-Export mode In the configuration navigation tree, users can add or delete GSM, UMTS, and LTE relationships in batches for UMTS cells by referencing neighbor relationship templates. The CME also allows users to configure bidirectional neighbor relationships for GSM and UMTS cells to ensure that MSs are properly handed over between these cells. By importing network planning data, users can create neighbor relationships in batches. The CME verifies the data before the import and provides a report after the import. A network planning template is an XLS, XLSM, or TXT file that contains radio data such as basic parameters about UMTS cells, and local cell frequencies of physical NodeBs, and power neighboring GSM, UMTS, and LTE relationships, and external cells. The CME also allows users to configure bidirectional neighbor relationships for GSM, UMTS, and LTE cells to ensure that MSs are properly handed over between these cells.

Reconstructing network services: 

Configuring RNC pools in batches In an RNC pool, a NodeB is controlled by two RNCs, a primary RNC and a secondary RNC. If a fault occurs on the primary RNC, the NodeB is automatically switched over to the secondary RNC to ensure service continuity. This minimizes the impact on ongoing services on the live network. The CME allows users to change homing relationships between single-homing and dual-homing in batches using a wizard. For example, to change homing relationships from single-homing to dual-homing, users need to reconfigure the following objects: −

Homing relationships of target NodeBs and cells under them: Homing relationships are changed from single-homing to primary-homing under the primary RNC.

−

Iub transmission from the NodeBs to the secondary RNC

−

Cells, external cells, and neighboring cells of the NodeBs under the secondary RNC. This ensures consistency of cell, external cell, and neighboring cell data with that under the primary RNC

−

Neighbor relationships of neighboring RNCs

Users can reconfigure a maximum of 50 single-homing NodeBs as dual-homing NodeBs in an RNC pool at a time. 

Reconfiguring MOCN sharing for cells in batches The MOCN was introduced in 3GPP Release 6. In an MOCN, both NEs on the access network (such as RNCs and NodeBs) and TRX resources are shared. The MOCN uses common TRX resources and allows multiple telecom operators to share one cell. Common TRXs have a higher resource usage than private TRXs. The CME allows users to configure MOCN cells in batches. After importing an MOCN reconfiguration template, users can change non-MOCN cells to MOCN cells or change MOCN cells to non-MOCN cells in batches by setting the telecom operator group information for NodeBs.



Reconfiguring HSPA cells in batches WCDMA introduces High Speed Downlink Packet Access (HSDPA) in 3GPP Release 5 and High Speed Uplink Packet Access (HSUPA) in 3GPP Release 6. HSDPA and HSUPA are amalgamated into HSPA, which ensures efficient scheduling and fast retransmission and therefore improves HSPA's performance.

Issue 02 (2013-07-20)


73



The CME allows users to reconfigure HSPA cells in batches by selecting a cell template and modifying HSPA cell parameters through a wizard. 

Reconfiguring IP pools in batches IP pools allow IP address sharing and load balancing within the pools. IP pools are configured for Iur, Iub, Iu-PS, and Iu-CS interfaces to balance services between interface boards within IP pools, and improve reliability and usage of IP-based networks. The CME allows users to change transmission modes for NodeBs to IP pools in batches through a wizard.

Configuration parameters for base stations in SRAN8.0 and later versions can be reconfigured using the following functions: 

General configuration The general configuration window provides a navigation tree in the left pane and a table in the right pane. Users can reconfigure the following base station data in the window: basic information, and radio, device, and transport data.



Carrier resource management The carrier resource management window displays logical relationships between cells, sectors, and RF modules. This function allows users to add or delete objects related to cells and sectors.



Batch import of base station configuration data Users can customize, edit, and import a summary data file to reconfigure base station data in batches.



Batch modification center Users can reconfigure parameters of objects in batches by using a wizard.


General configuration applied to base stations in SRAN8.0 and later versions



Batch configuration data import applied to base stations in SRAN8.0 and later versions



Batch modification center applied to base stations in SRAN8.0 and later versions



Carrier resource management applied to base stations in SRAN8.0 and later versions


Supporting interlocked modification for cell parameters with eNodeBs



Reconfiguring IP pools in batches


Allowing interlocked deletion of corresponding external cells and neighbor relationships under GSM NEs



Supporting interlocked modification for cell parameters with GSM NEs



Reconfiguring NodeBs as dual-homing NodeBs in an RNC pool



Excel 2003, Excel 2007, or Excel 2010 must be installed on the PC running the CME client. Users must purchase and install Microsoft Office in advance.

Dependency

Issue 02 (2013-07-20)


74



Reconfiguring IP pools in batches needs the customized software and dedicated services of Huawei which are not included in this feature.

WOFD-186300 Network Initial Configuration – LTE FDD/TDD Availability This feature was introduced in M2000 V200R010.

Summary Users can configure the global, device, and transport data about the LTE by using the configuration navigation tree or device panel provided by the CME, or by i mporting negotiated data in batches. They can also create eNodeBs and cells by using the GUI or by importing negotiated data in batches, and create neighbor relationships by using the configuration navigation tree or by importing network planning data in batches.






Description The CME allows users to create a single eNodeB or create eNodeBs in batches: 

Creating a single eNodeB The CME allows users to create a single eNodeB on the GUI b y using an eNodeB template. Users can configure the device, transport, and radio data about the eNodeB in the configuration navigation tree.



−

Configure device data about the eNodeB on the device panel, such as cabinet data, subrack data, board data, common parameters, clock data, and time zone data.

−

Configure transport data about the eNodeB in the configuration navigation tree, including data about the physical layer, link layer, network layer, transport layer, and algorithm category.

−

Configure radio data about the eNodeB in the configuration navigation tree, including global algorithm parameters, telecom operators' basic parameters, handover parameters, and cell algorithm parameters.

Creating eNodeBs in batches The CME allows users to create eNodeBs and cells in batches quickly by using a default or user-defined summary data file to import data. In this mode, a maximum of 50 eNodeBs can be created at a time. A summary data file is an XLS or XLSM file that contains the required data planned for creating eNodeBs in batches. Together with data in the eNodeB template, data in this file contributes to eNodeB creation and simplifies the data editing process. Users can also create eNodeBs by referring to data in the radio template or cell template. The summary data file contains eNodeB common parameters, eNodeB transport parameters, and eNodeB radio parameters.

Issue 02 (2013-07-20)


75



The CME provides a tool for customizing summary data files. Users can define objects and parameters by using this customization tool. The customization tool allows users to customize a summary data file and edit the mappings between collected data and NE configuration objects. Then, the tool automatically generates user-defined sheets for the summary data file. This simplifies the procedure for customizing summary data files and improves data editing efficiency. The CME allows users to create neighbor relationships in the following modes: 

Creating neighbor relationships by using the configuration navigation tree In the configuration navigation tree, users can add and delete neighboring GSM, UMTS, LTE, or CDMA relationships to ensure proper UE handover between cells.



Creating neighbor relationships in batches by importing network planning data By importing network planning data, users can create neighbor relationships in batches. A network planning template is an XLS, XLSM, or TXT file that contains basic data about LTE cells, neighboring GSM, UMTS, LTE and CDMA relationships, data about external cells, and blacklist for neighboring LTE cells. The CME also allows users to configure bidirectional neighbor relationships for GSM, UMTS, and LTE cells to ensure that MSs are properly handed over between these cells.


Importing neighboring UMTS/CDMA relationships and external cell information as network planning data


Importing and exporting network planning data





WOFD-186310 Network Reconfiguration – LTE FDD/TDD Availability This feature was introduced in M2000 V200R010.

Summary Network reconfiguration applies to network expansion and routine maintenance scenarios. Users need to reconfigure the device, transport, and radio data about eNodeBs in the following modes: configuration navigation tree, device panel, batch modification center, planned data import/export, and interlocked modification.

Benefits This feature brings about the following benefits:

Issue 02 (2013-07-20)


76








The batch modification center and planned data import/export function significantly improve data reconfiguration efficiency.



Interlocked cell parameter modification and bidirectional neighbor relationship configuration ensure data consistency across the entire network.

Description The CME provides the following network reconfiguration modes: 




Device panel: The device panel displays the components of physical devices such as cabinets, subracks, and boards. Users can view component attributes on the device panel. They can also add, delete, and modify parameters about the physical devices.



Batch modification center: The CME allows users to change the values of parameters in batches under a specified object for eNodeBs of the same version in the planned data area.



Planned data import/export: The CME allows users to batch-configure objects and parameters by importing and exporting a data planning template for onsite network planning and network optimization data. Users can import and export network planning data in batches.



Batch configuration data import/export: This function is based on a summary data file. Users can customize a summary data file and then use this function to reconfigure data in the planned data area.



Interlocked modification: In routine maintenance scenarios such as algorithm parameter optimization, users need to adjust cell parameters such as TACs, PCIs, and frequencies. When users modify cell parameters in batch modification center, or planned data import-export mode, the CME automatically triggers interlocked modification for external cell parameters under GSM, UMTS, and LTE NEs. This ensures parameter consistency.



Carrier resource management: The carrier resource management window displays logical relationships between cells, sectors, and RF modules. This function allows users to add or delete objects related to cells and sectors.

Network reconfiguration involves device data, transport data, and radio data. Reconfiguring device data: 

Reconfiguring BSC device parameters in Configuration Navigation Tree, Device Panel, or batch configuration data import/export mode Users can reconfigure parameters about eNodeB devices such as cabinets, subracks, boards, RF modules, and ports. They can also reconfigure common parameters and clock and time zone parameters. These parameters are the basis for carrying upper-layer data.

Reconfiguring transport data: 

Expanding transmission capacity in Configuration Navigation Tree or batch configuration data import/export mode Users can reconfigure MME and S-GW connections.

Issue 02 (2013-07-20)


77



Reconfiguring eNodeB transport parameters in Configuration Navigation Tree or batch configuration data import/export mode Users can reconfigure transport data, including data about the physical layer, link layer, network layer, transmission layer, and algorithm category. For example, they can configure eNodeB co-transmission, reconfigure remote maintenance channel, or change the IP address of the clock server.

Reconfiguring radio data: 

Reconfiguring global radio parameters in Configuration Navigation Tree mode or Batch Modification Center mode In the configuration navigation tree, users can configure global radio parameters for the eNodeB, such as cell basic parameters, global algorithm parameters, telecom operators' basic parameters, handover parameters, external cells, and interface information. In the batch modification center, users can modify common global radio parameters such as global algorithm parameters and handover parameters in batches.




Creating cells in Configuration Navigation Tree mode, Network Planning Data Import-Export mode, or Carrier Resource Management mode By using cell templates, users can create eNodeB cells in the configuration navigation tree, or create eNodeB cells in batches by importing and exporting network planning data. A network planning template is an XLS, XLSM, or TXT file that contains basic data about LTE cells, neighboring GSM, UMTS, LTE and CDMA relationships, data about external cells, and blacklist for neighboring LTE cells. The carrier resource management function allows users to create, delete, and reconfigure cells.

−

Reconfiguring cell parameters in Configuration Navigation Tree mode, Batch Modification mode, Network Planning Data Import-Export mode, and Interlocked Modification mode In the configuration navigation tree, users can reconfigure the following cell parameters: system message parameters, channel configuration parameters, cell algorithm parameters, and neighboring GSM, UMTS, LTE, and CDMA relationships. In the batch modification center, users can modify the following common cell parameters in batches: system message parameters, channel configuration parameters, and cell algorithm parameters. By using the network planning data import/export function, users can modify basic parameters such as cell basic information and cell operator information in batches. They can also add LTE cells to the blacklist in batches.



Reconfiguring neighbor relationships and external cell parameters in Configuration Navigation Tree mode or Network Planning Data Import-Export mode In the configuration navigation tree, users can add and delete neighboring GSM, UMTS, LTE, or CDMA relationships to ensure proper UE handover between cells. By importing network planning data, users can create neighbor relationships in batches. The CME verifies the data before the import and provides a report after the import. A network planning template is an XLS, XLSM, or TXT file that contains basic data about LTE cells, neighboring GSM, UMTS, LTE and CDMA relationships, data about external cells, and blacklist for neighboring LTE cells. The CME also allows users to configure bidirectional neighbor relationships for GSM, UMTS, and LTE cells to ensure that MSs are properly handed over between these cells.

Issue 02 (2013-07-20)


78



The carrier resource management function allows users to reconfigure radio data such as cell and sector data for base stations in SRAN8.0 and later versions.


Carrier resource management applied to base stations in SRAN8.0 and later versions


Supporting interlocked modification for cell parameters



Importing neighboring UMTS/CDMA relationships and external cell information as network planning data



Batch import/export of base station configuration data


Importing and exporting network planning data


WOFD-186400 Network Initial Configuration – SingleRAN Availability This feature was introduced in M2000 V200R010.

Summary The multi-mode base station (MBTS) is a future-oriented base station solution provided by Huawei, which integrates the base station devices of different RATs. MBTSs are base stations that support two or more RATs among GSM, UMTS, and LTE. For example, MBTS(GU)s support GSM and UMTS and MBTS(GUL)s support GSM, UMTS, and LTE. Network initial configuration is performed at the deployment phase for SingleRAN networks. Initial configuration ensures that devices run properly and provide required service capability. After a multi-mode base station controller (MBSC) is connected to the M2000, users can use the CME to complete the initial configuration of controller global data, device data, and transport data. They can also create MBTSs and cells in capacity expansion or integrated mode, and create neighbor relationships.


Allowing users to create MBTSs flexibly, simplifying initial configuration in various scenarios



Simplifying site deployment by providing a clear procedure, and improving site deployment efficiency by supporting batch operations



Providing a multi-mode device panel, integrating configuration access for devices of different RATs, simplifying user operations

Issue 02 (2013-07-20)


79



Description Using the CME to complete the initial configuration of an MBSC(GU): 

To complete the initial configuration for the global data, transport data, and radio data of the MBSC(GU), users can configure the BSC and RNC by referring to the features WOFD-186100 Network Initial Configuration – GBSS and WOFD-186200 Network Initial Configuration – WRAN, respectively.



The CME displays the device parameters of the MBSC(GU) on the MBSC device panel, which displays the components of physical devices for the MBSC. Users can view the attributes of the components. They can also add, delete, and modify parameters of physical devices on the live network, such as cabinets, subracks, boards, and physical ports. Using the CME to create MBTSs:



Creating a single MBTS −

Creating an MBTS by binding base stations of different RATs The CME allows users to configure single-mode base stations of different RATs as an MBTS. It also allows users to export MBTS binding relationships as an XLS file.

−

Creating base stations on a unified GUI Users can create single-mode base stations of various RATs and bind the single-mode base stations as MBTSs.

Users can create co-MPT multimode base stations. 

Creating MBTSs in batches −

Binding single-mode base stations as MBTSs in batches The CME allows users to import a binding relationship table to bind base stations of different RATs as required MBTSs in batches. It also allows users to export MBTS binding relationships as an XLS file.

−

Importing negotiated interface data The CME provides a wizard, allowing users to create MBTSs in batches by using negotiated interface data templates of different RATs and MBTS binding relationship tables. The CME also allows users to create multiple single-mode base stations and bind them as MBTSs or create MBTSs by expanding the capacities of single-mode base stations. Currently, only MBTS(GU)s, MBTS(GL)s, and MBTS(GUL)s can be created by importing negotiated interface data. Users can create base stations in SRAN8.0 and later versions by importing a summary data file.

−

Creating base stations using a summary data file Users can create co-MPT multimode base stations in batches by importing a summary data file. Users can bind created single-mode base stations as MBTSs by importing binding relationships.



Using the CME to create neighbor relationships: To create neighbor relationships for SingleRAN networks, users can create neighbor relationships for single-mode cells by referring to the features WOFD-186100 Network Initial Configuration – GBSS, WOFD-186200 Network Initial Configuration – WRAN, and WOFD-186300 Network Initial Configuration – LTE, respectively.

Issue 02 (2013-07-20)


80




Supporting co-MPT multimode base stations


Binding NodeBs and eNodeBs as MBTS(UL)s in batches


Creating MBTS(GUL)s through capacity expansion


WOFD-186410 Network Reconfiguration – SingleRAN Availability This feature was introduced in M2000 V200R010.

Summary Network reconfiguration applies to network expansion and routine maintenance scenarios. Users need to reconfigure the device, transport, and radio data about controllers and base stations by performing data reconfiguration for each RAT. Device data can also be reconfigured centrally on the multi-mode device panel.


The CME centrally displays data about devices in different RATs on the multi-mode device panel and allows users to configure data on the device panel, simplifying operations.



The CME displays multiple views on the MBTS device panel, allowing users to view and configure device data about single- and multi-mode base stations.

Description MBTSs are base stations that support two or more RATs among GSM, UMTS, and LTE. For example, MBTS(GU)s and MBTS(GUL)s. Network reconfiguration involves the reconfiguration of device, transport, and radio data. Data reconfiguration for co-MPT multimode base stations is the same as that for single-mode base stations in the same version. Reconfiguring device data: 

Issue 02 (2013-07-20)

Reconfiguring the global data and basic information about MBSCs


81



Users can reconfigure the global data about the BSC and the RNC by referring to the features WOFD-186110 Network Reconfiguration – GBSS and WOFD-186210 Network Reconfiguration – WRAN, respectively. Users can reconfigure the basic information about the single-mode base stations by referring to the features WOFD-186110 Network Reconfiguration – GBSS, WOFD-186210 Network Reconfiguration – WRAN, and WOFD-186310 Network Reconfiguration – LTE, respectively. 

Reconfiguring MBSC device parameters in Device Panel mode The device panel displays the components of the physical devices for the MBSC, such as cabinets, subracks, boards, and physical ports, in a graphical manner. Users can view the attributes on the GUI. They can also add, delete, and modify parameters about the physical devices.



Reconfiguring MBTS device parameters in Device Panel mode On the MBTS device panel, the configuration parameters of single- or multi-mode base stations are displayed. For common boards like the PMU, EMU, TCU, and FMU, users can configure the same device parameters for each single-mode base station or configure the device parameters for the entire MBTS for the parameters to take effect on each single-mode base station.



Reconfiguring transport data: Users can reconfigure the transport data about the single-mode base stations by referring to the features WOFD-186110 Network Reconfiguration – GBSS, WOFD-186210 Network Reconfiguration – WRAN, and WOFD-186310 Network Reconfiguration – LTE, respectively.



Reconfiguring radio data: Users can reconfigure the radio data about the single-mode base stations by referring to the features WOFD-186110 Network Reconfiguration – GBSS, WOFD-186210 Network Reconfiguration – WRAN, and WOFD-186310 Network Reconfiguration – LTE, respectively.


Supporting co-MPT multimode base stations


MBTS (GUL) configuration management


WOFD-186220 Parameter Consistency Check – WRAN Availability This feature was introduced in M2000 V200R010.

Issue 02 (2013-07-20)


82



Summary The CME allows users to perform integrity, redundancy checks and RNC pool consistency checks on the configuration data of a single RNC. It also allows users to restore data and compare check results.

Benefits This feature helps users detect and correct incomplete and redundant configuration data for a single RNC. This improves configuration data accuracy and reduces the amount of useless data. The RNC pool consistency check function ensures data consistency in the RNC pool.

Description The CME provides a project for users to check the integrity and redundancy of the RNC configuration data, and to check the consistency of an RNC pool that has been configured or activated. The M2000 centrally manages scheduled tasks for data integrity and redundancy checks by using the feature WOFD-071200 Centralized Task Manager. 

Checking redundancy Redundant data is bottom-layer data that is not referenced by upper layers. For example, data related to redundant device IP addresses, local cells, ATM-based transmission, IP-based transmission, and location areas. Redundancy checks help clear redundant data and reduce system load.



Checking integrity Integrity checks are used to detect whether mandatory configuration objects for implementing NE services are configured completely. Integrity checks involve checking the physical bearer links of ATM-based transmission links, IP link validity, cells, and neighbor relationships.



Checking data consistency between RNCs and NodeBs Iub interface consistency check: checks consistency of parameters such as the NCP, CCPs, and the operation and maintenance channel (OMCH). Radio data consistency check: checks consistency such as the number of LOCELLs, ID of LOCELLs, and the parameters of LOCELLs.



Checking data consistency in an RNC pool Users can set check criteria to check the configuration consistency on the primary and secondary RNCs, such as to check whether transport and radio parameters exist on the primary and secondary RNCs and whether the transport and radio parameters are consistent on the primary and secondary RNCs.

After the consistency check is complete, the CME generates check results with alarm severities of error, major, and warning. Users can customize the alarm severity of each check result. The CME allows users to save check results as an HTML, CSV, XLS, PDF, or TXT file and to compare check results. It also provides the following modes for restoring incorrect data based on check results: 

Wizard-based data update: The CME provides modification suggestions for users.



GUI-based data editing: The CME provides a general configuration window for users to modify related configuration data.

Issue 02 (2013-07-20)


83



Automatic restoration: The CME automatically changes the parameter values to the recommended values.


Checking radio data consistency between RNCs and NodeBs


Checking data consistency in an RNC pool

Dependency None

WOFD-186120 Parameter Consistency Check – GBSS Availability This feature was introduced in M2000 V200R010.

Summary The CME allows users to perform integrity and redundancy checks on the configuration data of a single GBSC. It also allows users to restore data and compare check results.

Benefits This feature helps users detect and correct incomplete and redundant configuration data for a single GBSC. This improves configuration data accuracy and reduces the amount of useless data.

Description The CME provides a project for users to check the integrity and redundancy of the GBSC configuration data that has been configured or activated. The M2000 uses the feature WOFD-071200 Centralized Task Manager to centrally manage scheduled tasks for data integrity and redundancy checks. 

Redundancy check Redundant data is bottom-layer data that is not referenced by upper layers. For example, data related to redundant device IP addresses, IP-based transmission, and GBSC interfaces. Redundancy checks help clear redundant data and reduce system load.



Integrity check Integrity checks are used to detect whether mandatory configuration objects for implementing NE services are configured completely. Integrity checks involve checking GBTS data, IP link validity, internal cells, and neighbor relationships.

After the consistency check is complete, the CME generates check results with alarm severities of error, major, and warning. Users can customize the alarm severity of each check result. The CME allows users to save check results as an HTML, CSV, XLS, PDF, or TXT file and to compare check results.

Issue 02 (2013-07-20)


84



It also provides the following modes for restoring incorrect data based on check results: 








Enhancement None

Dependency None

WOFD-186420 Parameter Consistency Check – SingleRAN Availability This feature was introduced in M2000 V200R010.

Summary The configuration of MBTS common resources and RRU resources must be kept consistent between different modes. The CME performs consistency check on common devices of the MBTS, conflict check on RRU resources, and consistency check on dynamic spectrum sharing for MBTS(GU)s.

Benefits This feature ensures consistent and valid parameter configuration for MBTS common resources, RRU resources, and dynamic spectrum sharing among various RATs. Therefore, impacts on services due to incorrect or inconsistent configurations are eliminated.


Common device consistency check In BM/TC separated mode, MBTS common boards such as the PMU, EMU, TCU, and FMU may be configured in GSM, UMTS, or LTE modes. Therefore, the same configuration parameters must be set to the same value in each mode. Otherwise, configuration errors will occur and alarms indicating inconsistent parameters will be generated. By using the data consistency check function, the CME identifies MBTS common boards and checks for inconsistent parameters of the common boards. The CME allows users to set the primary and secondary RATs of an MBTS. If any parameter inconsistency is detected, the CME updates the base station configuration parameters of the secondary RAT based on the parameters of the primary RAT. This ensures data consistency.



Issue 02 (2013-07-20)

RRU resource conflict check


85



Based on the data of one RAT for an MBTS, users can check whether the RF resources of other RATs conflict with the baseline data. The check items include number of carriers, carrier bandwidths, carrier intervals, and carrier power. Currently, MBTS(UL)s do not support this function. 

Consistency check of MBTS(GU) dynamic spectrum sharing The dynamic spectrum sharing (DSS) function dynamically allocates some GSM spectrum resources between the GSM and UMTS networks. This function utilizes different busy hours for voice services on the GSM network and for data services on the UMTS network. This function improves spectrum efficiency and reduces the overall cost of data services for telecom operators. The CME allows users to check the consistency of dynamic spectrum sharing for MBTS(GU)s. The CME provides a sharing switch and allows users to check for frequency band conflicts for base stations where dynamic spectrum sharing tasks have been created.

After the consistency check is complete, the CME generates check results with alarm severities of error, major, and warning. Users can customize the alarm severity of each check result. The CME allows users to save check results as an HTML, CSV, XLS, PDF, or TXT file and to compare check results. It also provides the following modes for restoring incorrect data based on check results: 









Consistency check of MBTS(GUL) common resources



Consistency check of MBTS(GU) dynamic spectrum sharing

Dependency None

2.5 Performance Management WOFD-030100 Performance Measurement Data Collection and Storage Availability This feature was introduced in M2000 V200R002.

Summary Based on the measurement settings, the M2000 can obtain the measurement results of performance counters from NEs and save the results in the M2000 database. Users can adjust

Issue 02 (2013-07-20)


86



the measurement settings and use a template for the measurement settings. They can also view the measurement status, perform measurement data synchronization, and view the synchronization status.

Benefits 

The user-friendly GUI simplifies operations and facilitates the monitoring and viewing of the measurement status of an object.



By default, the M2000 collects and stores the measurement results of common object counters. This can meet the data requirements in multiple O&M scenarios without any user setting.


Setting measurements The M2000 collects the data of network measurement counters and stores the data in the M2000 database. Measurement objects, counters, and periods are three required elements for performance data collection. A measurement object can be a physical board, a physical subrack, or a logical cell. Certain corresponding relationships exist between measurement objects and measurement counters. Each type of measurement object corresponds to some measurement counters. Measurement objects can be classified as follows: −

Objects of the first category: The M2000 automatically displays these measurement objects, and collects and saves the measurement data of all the objects of this category. No user setting is required.

−

Objects of the second category: The M2000 automatically displays these measurement objects. The M2000 collects the measurement data of these objects only after users manually type these objects and measure them.

−

Objects of the third category: The M2000 does not display these measurement objects. It displays the measurement data of these objects only after users type the data such as the local network number of the calling party, destination and office direction, local network number, and supplementary services.

Measurement counters are classified into common counters and extended counters. When the network is running, the M2000 collects and stores the common counters of the first category by default. Users can set measurement objects based on the default settings, or cancel the measuring of common counters. The M2000 collects and stores extended counters based on the preset measurement objects and counters. The M2000 suspends and activates the data collection tasks of some measurement data based on measurement units. It does not store counter results in suspended measurement units in the database. A measurement period refers to the interval for NEs to report performance measurement results. The report periods for measurement results vary according to measurement counters of different NEs. Measurement periods vary according to NE measurement counters. By default, common counters and extended counters are collected at the interval of 30 or 60 minutes. Users can also reset the period to the other periods that the NE measurement counters support. Users can set measurements based on network performance measurement requirements. The M2000 allows users to:

Issue 02 (2013-07-20)


87



Manually set a measurement for a single counter, object, and period.

−

Set measurements in one-click mode, where users can select all counters and objects under an NE to set measurements at a time.

−

Set measurements in batches through file import and export.

The M2000 allows users to export the measurement setting information about an NE, such as measurement periods, objects, sets, units, and counters to XM L files. The exported file can be used as a template for measurement setting. Users can complete the measurement setting by importing the template file. They can also modify and edit the template file. 

Storing measurement data The database stores collected performance data in the database for a maximum of 30 days. Users can change the period. If the M2000 performance counters are not measured based on the default settings or the network size exceeds the management capacity of the server, the M2000 may not be able to store the performance counters for 30 days. When the storage duration is about to expire or the disk space usage has been exceeded, the M2000 automatically dumps performance data to files. Performance data dumping affects the performance of the M2000 and therefore it is disabled by default.



Viewing measurement status The M2000 provides a dedicate window for viewing the current measurement settings, including measurement objects and sets, and periods and status of measurement units. Users can export measurement status information to a TXT, HTML, CSV, or XLS file based on NEs.



Synchronizing measurement data To ensure the consistency of performance measurement data between NEs and the M2000, the M2000 provides manual and automatic measurement data synchronization modes. Manual synchronization is performed when users detect exceptions on performance data. When an NE is disconnected from the M2000 or when the M2000 performance service is stopped, the M2000 detects that NE performance data is missing. In this case, the M2000 starts automatic supplementary collection. If no results are reported after the automatic supplementary collection is complete, the M2000 generates an alarm, indicating that the performance measurement results are missing. The M2000 also allows users to manage the status of performance data synchronization tasks. The M2000 provides a window for users to view all the ongoing performance data synchronization tasks. On the interface, users can also perform operations such as filtering, sorting, canceling, and retrying synchronization tasks, and resetting their priorities.

Enhancement The one-click measurement setting is added to M2000 V200R013C01. Performance data synchronization task management is added to M2000 V200R008.

Dependency None

Issue 02 (2013-07-20)


88



WOFD-030500 Performance Measurement Data Query Availability This feature was introduced in M2000 V200R002.

Summary Users can query the performance data imported into the database on the M2000. The M2000 displays the query results in a table, line chart, or column chart. The M2000 also allows users to print and save the query results, query data by template, query missing data, and subscribe to performance data.




The M2000 allows users to set search criteria to easily query data based on fixed conditions and customize search criteria. Multiple data display modes facilitate the viewing of performance data. The M2000 allows users to analyze causes of performance result loss in most application scenarios. This improves efficiency in locating and solving performance result loss problems.


Querying data The M2000 supports data query by condition and displays the query results in a table, line chart, or column chart. The supported search criteria are measurement objects, measurement counters, measurement period, sort mode, and time ranges. The line chart displays the information about multiple counters of an object, or displays the information about multiple objects of a counter. Line charts and column charts can be saved as JPG images. Users can print the query results, and all the data in the active window is printed. They can also save query results as TXT, HTML, XLS, XLSX, or CSV files.



Query templates The M2000 allows users to use templates for query. The templates consist of the default templates and user-defined templates. A default template is a predefined template provided for some NEs to facilitate the query of common performance counter data. All the M2000 users can use the default template. Users can create templates by copying default templates. Users can save preferred performance data search criteria as a user-defined template. Templates are saved according to users. The M2000 allows users to import, export, cut, paste, copy, delete, rename, and view user-defined templates, delete the templates in batches, and collect template usage statistics. When users use a template to query performance data without any modifications of the conditions, the M2000 does it according to the default conditions of the template. Users can also reconfigure the search criteria based on the template.

Issue 02 (2013-07-20)


89



Analyzing causes of performance result loss The M2000 analyzes causes of performance result loss and provides diagnosis reports. Based on performance data processing procedures and common problems, the M2000 designs the following diagnosis process: performance result loss check, cause analysis, and report summarization. The possible causes for performance result loss are as follows: −

An exception occurs when performance results are reported.

−

Measurement parameters are not set.

−

NEs are disconnected.

−

An exception occurs when measurement parameters are delivered.

−

Performance files are incomplete.

− −

NEs delay reporting performance results. System resources are unavailable.

A diagnosis report provides causes of performance result loss, and suggestions and procedures for handling the problems. Users can set criteria for analyzing performance result loss, which are the same as the result search criteria. Users can also analyze causes of performance result loss for specified performance query results. 

Subscribing to performance data Users can subscribe to performance data by condition. The supported conditions include NE objects, measurement periods, and measurement units. The M2000 displays the newly generated performance data that meets the subscription conditions in the window. Only one subscription task can be started on one client.


Analyzing causes of performance result loss Users can collect statistics about performance query template usage and delete the templates in batches.

WOFD-031000 Customizable Counter Management Availability This feature was introduced in M2000 V200R002.

Description This feature allows users to define new performance counters based on the raw counters provided by default and based on the existing user-defined counters. This meets the requirements of performance counters that exceed the range of raw counters in the network operation and maintenance. The supported calculation rules are + , – , x, /, (,) and {and}, where {and} is used to define constants. Users can create, modify, or delete user-defined counters. Users can create, modify, and delete user-defined counters, which include the counter name, unit, measurement set, function unit, formula, and description information. In addition, users can export and import user-defined counters as XML files.

Issue 02 (2013-07-20)


90




The M2000 allows users to create, modify, and delete the description of user-defined counters.

WOFD-031050 Default KPI System Availability This feature was introduced in M2000 V200R009.

Description Based on the customized key performance indicator (KPI) management and the KPI system of NEs, the M2000 provides a default KPI definition for the NEs and a KPI query profile to facilitate the information query. The query interval defined in the default KPI query profile is 5 minutes or 15 minutes. Users can create a query profile based on the default profile. This feature applies to the following NEs: SoftX30000, MSC Server, SGSN, GGSN, HLR, CSCF, HSS, ATS, MGCF, AGCF, MRFP, USN, and UGW.

WOFD-031200 Performance Threshold Alarm Availability This feature was introduced in M2000 V200R002.

Description This feature allows users to set performance alarm thresholds for measurement counters. When a counter value exceeds the threshold, a performance alarm is generated. When the counter value is within the normal range, the alarm is automatically cleared. This feature consists of threshold definition and threshold management. Threshold definition: 

The M2000 allows users to set multiple alarm thresholds for a counter. The alarm thresholds can be set according to objects, time segments, periods, and trends. Different thresholds can be set for the same counter according to objects, time segments, periods, and trends.



Users can set threshold alarms for user-defined counters.



Combined thresholds are supported. The triggering conditions for generating and clearing threshold alarms are condition expressions. An expression can contain multiple counters. The supported calculation rules are +, – , x, /, AND, OR, =, !=, >=, >, <, (and), {and}, where {and} is used to define constants.



Thresholds can be set for object groups (such as cell groups). The M2000 summarizes the counter results of all the objects in an object group, determines the threshold conditions, and generates performance threshold alarms for the results that meet the conditions for triggering threshold alarms.

Issue 02 (2013-07-20)


91





Users can customize the threshold alarm names. After a threshold task is bound with a user-defined alarm name, the alarms that meet the threshold conditions are reported with the user-defined alarm names.



The M2000 supports the dynamic change of alarm severities. If alarms of the sa me severity are generated consecutively, the severity of this alarm can be changed to a higher severity. Users can set the times for generating an alarm of the same severity for raising the alarm severity.



The M2000 generates an alarm only when the times for triggering alarms that meet the conditions reach a certain threshold. Users can set the threshold.



After an alarm is generated, it is cleared only when the performance counter monitoring results do not meet the condition that the times of alarm conditions reach a certain threshold. Users can set the threshold.

Threshold management 

Users can create, change, and delete thresholds.



The threshold query is supported. Users can filter thresholds according to threshold names, NEs (or objects under NEs), periods, triggering time segments, and threshold trends. They can also query thresholds by combining multiple conditions.



The batch activation, suspension, copy, and paste of thresholds are allowed.



NE thresholds can be suspended automatically or manually according to time.



Users can redefine threshold alarm names, including customizing, changing, and deleting user-defined threshold alarm names.



The threshold template can now be imported or exported.


Importing and exporting the threshold template


Deleting user-defined threshold alarm names


Cell group thresholds can be set for BSC6900 GSM, BSC6000 (GSM-R), BSC6900 UMTS, and BSC6900 GU.


The threshold alarm names can be customized.

The following functions are added to M200V200R008: 

Threshold definition: setting thresholds of object groups (such as cell groups), which is supported only by BSC6800.



Threshold management

Issue 02 (2013-07-20)

−

Threshold query

−

Threshold operation in batches

−

Suspension of NE thresholds


92



Dependency None

WOFD-031600 Remote Service Validation Availability This feature was introduced in M2000 V200R008.

Summary After the devices on the live network are upgraded, users need to verify that the services can run normally after the upgrade. The remote service upgrade validation feature allows users to verify services remotely from the network management center. Therefore, users do not need to verify the services through site dialing tests. This reduces network OPEX and improves efficiency. In addition, the remote service upgrade validation can be performed on all types of NEs.

Benefits This feature allows users to perform the verification remotely after an NE upgrade to avoid or reduce manual dialing tests on site, reducing upgrade costs and workload.

Description In the traditional O&M mode, after radio devices are upgraded on the communication network, local manual dialing tests are required to check whether the services are normal. In this case, the efficiency is low. Currently, NE upgrades are performed at the network management center instead of on site to reduce upgrade costs and to improve O&M efficiency. In this case, the remote service upgrade validation feature is developed. Users can use this feature to check whether the services of NEs are normal after an upgrade by comparing the key traffic counters before and after the upgrade. This feature is service-oriented, comprehensive, precise and measurable, time-based, and object-based. Therefore, it can be used to verify NE upgrades. The M2000 verifies the upgrade after an NE upgrade is complete. When verifying the upgrade, the M2000 obtains raw counters from the NE, calculates KPIs based on the raw counters, and compares the best KPIs with the standard and historical reference values. Then, the M2000 provides the verification results. Users can save the verification results as an HTML, CSV, PDF, or TXT file. Service upgrade verification is performed on a task basis. The M2000 manages and schedules the tasks by using the feature WOFD-071200 Centralized Task Manager.

Enhancement This feature applies to eNodeBs since M2000 V200R010.

Dependency This feature applies to GBSS8.1 and RAN11.0 and later versions.

Issue 02 (2013-07-20)


93



2.6 Security Management WOFD-040100 Centralized User Authorization and Authentication Availability This feature was introduced in M2000 V200R002.

Summary The M2000 centrally manages and authenticates O&M users on a network. The M2000 provides functions such as user account management, authority assignment, and user authentication.

Description Managing O&M users is the most important aspect of the security management function in the OSS environment. The M2000 centralized user management and authentication provide support to harden the access security of the system. The M2000 allows administrators to create, delete, and change O&M user accounts of both the M2000 and NEs, and assign rights to the O&M users. The M2000 supports a maximum of 500 M2000 users, including the default superuser. The M2000 supports role-based user group management. A user group consists of a set of users who have the same operation permissions. Operation permissions vary according to user groups. Basic and rights information is required for creating user accounts and groups. Basic information includes user or user group names and types. Rights information includes management domains, operation rights, rights rules, and bound NEs. The M2000 assigns user rights to users in either of the following modes: 

The M2000 directly assigns rights to users by copying existing user rights information. This simplifies the process of assigning rights.



The M2000 assigns rights to user groups and then to users based on the binding relationships between user groups and users. The M2000 can assign rights to a user group by copying rights information about another existing user group. This improves working efficiency. A user can belong to multiple user groups and has the rights of all the user groups it belongs to.

The M2000 provides six default user groups: Administrators, Operators , Guests , NBI, Maintenance, and SMManagers . Telecom operators can create other user groups and assign rights to the user groups as required. The Administrators user group has all rights except security management rights. The SMManagers user group has only security management rights. Users in this group can query security logs and perform security management operations, for example, creating new users and user groups, granting permissions to users and user groups, and changing the permissions of users and user groups. Users in other groups do not have security management rights. The rights of Administrators and SMManagers groups cannot be changed. The M2000 provides a default superuser, user admin. The default superuser can perform all operations on the M2000. User admin can still log in to the M2000 even if the number of login users exceeds the threshold. User Admin belongs to both the Administrators and SMManagers user groups, and the user groups cannot be changed.

Issue 02 (2013-07-20)


94



All the O&M users are authenticated by the M2000. When a user logs in to the M2000 through an M2000 client or logs in to an NE through the LMT, the M2000 authenticates the login based on the user name and password. Only the authorized user can log in to and operate the system. In addition to that, the M2000 authenticates operations performed on an M2000 client or the LMT. Therefore, users can perform operations with the most restrictive authority.


The maximum number of M2000 users is increased from 255 to 500.

Dependency Security data is imported and exported only among M2000 systems of the same version.

WOFD-040300 Security Policy Availability This feature was introduced in M2000 V200R002.

Description This feature allows users to set security policies for the M2000 system based on the requirements of different security levels. For example, users can set global user password and account policies, single user password and account policies, access control lists (ACLs), database password policies, and security-related alarms. To ensure service data security, the M2000 encrypts stored passwords and tracing data (except the data collected by using the Trace Server) and data transmitted using USB flash drives. By default, tracing data is not encrypted because the complicated encryption algorithm affects the M2000's operating efficiency. USB flash drives are required for transmitting data to NEs in many application scenarios. The M2000 provides a tool to prevent key data from being stolen or tampered with. The tool encrypts data, allows encrypted data transfer using USB flash drives, and protects data integrity. NEs verify the data integrity and decrypt the data. The tool supports the DES3_CBC, AES192_CBC, and AES256_CBC encryption algorithms and HMAC_SHA1 and HMAC_SHA256 integrity algorithms. The global password policies apply to the passwords of all M2000 users. The policies are as follows: 

Min. length of common user password: The default value is 8.



Min. length of system administrator password: The default value is 8.



Max. length of password: The default value is 16.



Duration for which a password cannot be reused (months): The default value is 0.



Max. valid duration for password (days): The default value is 180.



Min. valid duration for password (days): The default value is 10.



Issue 02 (2013-07-20)

Number of days in advance a warning is given before a password expires: The default value is 10.


95





Previously used passwords that cannot be the same as new password: The default value is 24.



Min. character difference between new password and old password: The default value is 3.



Min. number of letters in a password: The default value is 2.



Min. number of uppercase letters in a password: The default value is 1.



Min. number of lowercase letters in a password: The default value is 1.



Min. number of numerals in a password: The default value is 1.



Minimum number of special characters in a password: Special characters include ~ ! @ # $ % ^ & * ( ) + - = { } | \\ : \ " ; ' ? , . / ` and space. The default value is 1.



Password cannot contain any space: This policy is disabled by default.



Max. number of same consecutive characters between user name and password: This policy is disabled by default.



Password cannot contain any word given in password dictionary or any hacker language (For example, one or several letters in a word cannot be replaced by a numeral or numerals.) This policy is disabled by default.



Password cannot be the full user name or the reverse of user name: This policy is disabled by default.



Password cannot contain any repeated string: Users can set both the number of characters contained in a string and the number of times a string repeats in a password. This policy is disabled by default.



Password cannot be numerals or letters in ascending, descending, or interval order: For example, passwords a1z9123, a1z9cba, a1a2b3, and c1b111a are invalid. This policy is disabled by default.



Similarity between a new password and history passwords: The number of characters that cannot be repeated between the new and history passwords can be set. The value ranges from 1 to 24, where 24 is the default value.

The M2000 allows users to set password policies for a single user, and the settings take effect on only this user: 

Valid duration for password (days): The default value is 180.



Password must be changed at next login: This policy is disabled by default.



Password cannot be changed: This policy is disabled by default.

The M2000 provides the following password policies for database users: 

Oracle database: An Oracle database user password must contain at least eight characters, including at least one letter and one number.



Sybase database: A Sybase user password must contain at least eight characters, including at least one upper-case letter, one lower-case letter, and one number.

The M2000 allows users to set global user account policies, and the settings take effect on all M2000 users: 

Min. length of a user name: The default value is 6.



Lockout Duration: Specifies the number of minutes an account remains locked when the number of failed login attempts exceeds the specified threshold. The default value is 30. Users can also lock a user account permanently.



Delay in case of login failure or unlocking failure (seconds): refers to the wait time in case of re-login and re-unlocking. The default value is 3.

Issue 02 (2013-07-20)


96





Max. number of user login attempts: When the number of user login attempts reaches the maximum, the user is automatically locked. The default value is 3.



System administrator not locked permanently: This policy is disabled by default.



Inactive user policy: If a user does not log in for a specified period, the user account is hibernated or deleted. By default, the user account is hibernated if a user does not log in for 60 days.



Automatic client locking: After automatic client locking is enabled, the M2000 client is locked if no operation is performed on it within the specified time. The default setting is 3 minutes.

The M2000 allows users to set user account policies for a single user, and the settings take effect on only this user: 

Automatic idle user logout: After automatic idle user logout feature is enabled, the user who does not perform any operation on the M2000 client within a specified time range is automatically logged out. This policy is disabled by default.



Max. number of online users with the same user name: If the number of online users with the same user name exceeds the preset number, the M2000 does not allow this user to log in any longer. This policy is disabled by default.



Inactive user policy: If a user does not log in for a specified period, the user account is hibernated or deleted. This policy is disabled by default.



Login time restriction: A user can log in to the M2000 only within a specified time range. This policy is disabled by default.

ACL: 

The M2000 provides ACLs for users. After an ACL is set, users can log in to the M2000 only by using a specified IP address or network segment. The system administrator is authorized to set ACLs for all M2000 users. Users in the security management user group are authorized to set ACLs for all M2000 users except the system administrator.

Security alarms: 

The M2000 and NEs generate security-related alarms. These alarms are centrally monitored by the M2000 fault management system. NEs of different types support different alarms.

As defined in the 3GPP specifications, the M2000 and NEs support the following security-related alarms: 

Integrity violation



Operational violation



Physical violation



Security violation



Time domain violation



Security-related alarms vary according to the NE type.






Encrypted storage of passwords and tracing data (except data collected by using the Trace Server)



Support of password policies for database users

Enhancement

Issue 02 (2013-07-20)


97



The following password and security policies are added to M2000 V200R010: 

Encryption of data transmitted using USB flash drives



More Security-related alarm types



Encrypted password storage



More powerful password security policy −

A new password must be different from history passwords.

−

A password cannot contain repeated strings.

−

A password cannot contain any hacker language. For example, one or several letters in a word cannot be replaced by a digit or digits.

The following password and security policies are added to M2000 V200R009: 





Max. number of the adjacent characters that can be the same in the user name and password. The numerals and letters in a password cannot be in the interval sequence of numerals or letters. The minimum number of characters different in the new password from the old password.



The password cannot be in reverse order of the characters in a user name.



Automatic unlocking time specified for a user account.



Delay period after a login or unlocking failure.



Superuser not allowed to be locked.



Maximum number of online sessions of one user.



ACL.

The following security policies are added to M2000 V200R008: 

The system automatically logs out idle users.



The following security policies are added to M2000 V200R006:



Advance reminder of password expiry (days)



Password cannot contain consecutive and repeated characters.



Password cannot be numerals or letters in ascending or descending order.



Password cannot contain whole or part of user name.



Password cannot contain a word in the password dictionary.

WOFD-040700 Online NE User Monitoring Availability This feature was introduced in M2000 V200R003.

Description The online NE user monitoring feature allows users to monitor the session status and operations performed by all NE users. On the session status browsing window, information about session status, such as NE name, user name, user type, and login IP address. On the user operation monitoring window, information about user operations, such as NE name, user name, user type, login IP address, user operations, operation time, and execution results is

Issue 02 (2013-07-20)


98



displayed. All the information about session status and user operations is monitored and displayed on the monitoring interface in real time. This feature also allows users to kick out specified users.

WOFD-040800 Authority-Based and Domain-Based Management in Large Regional Networks Availability This feature was introduced in M2000 V200R005.

Description The large local network is a network in which an MSC server controls several small local networks, with the bearer part separated from the control part. The radio network devices of each small local network are connected to the media gateway (MGW) of the network. The MGW implements the interconnection between the radio network devices of the small local network and the NEs in other networks. This feature is based on the M2000 centralized user management function. The objects in a large local network are grouped into different domains. System administrators can grant users the authority to operate the objects in the domains. When users operate NEs through the M2000 client or the LMT, the M2000 authenticates user operations on the basis of the domain authority. Only authorized operations are performed on NEs. The management of a large local network involves domain management and domain authority management. Only the system administrator has the authority to manage the domain and domain authority. 

Domain management System administrators can add, modify, browse, and delete domains. After creating domains, the system administrators can bind NEs and domains. A domain can contain the objects that belong to different MSC Servers. An NE can also belong to multiple domains.



Domain authority management A domain contains multiple users, but a user belongs to only a domain. Administrators assign domain authority to users or user groups by binding them to a domain. Domain authority is categorized into private domain authority and global domain authority. A user belongs to only a private domain or a global domain. If a user has the authority of a domain, the user can add, modify, and delete the objects in the domain. System administrators can also unbind users (user groups) and domains.

WOFD-050100 M2000 Log Management Availability This feature was introduced in M2000 V200R002.

Issue 02 (2013-07-20)


99



Summary The M2000 records the information about system running status in logs. Users can query, export, and collect the statistics of logs. Logs help users to monitor and audit the running status and executed operations of the M2000.

Description Logs record the information about the running status of the M2000. Logs are categorized into operation logs, system logs, and security logs. Operation logs record the information about operations performed by users on the M2000 client. Running logs record the operating information about the M2000 system. Security logs record the following security-related events: 

Events related to account management



Events related to account login



System events such as system startup and shutdown or events that affect system security or system logs



Resource access events such as unauthorized access

This feature provides the following functions: 

Collecting and storing logs The database stores M2000 logs for a maximum of 180 days. Users can change the period. If the M2000 log database does not meet the standard planning or the network size exceeds the management capacity of the server, the M2000 may not be able to store the logs for 90 days. When the M2000 reaches the end of the storage period or disk capacity limit, the M2000 automatically dumps M2000 logs to files.



Querying logs The system allows users to query logs according to the preset conditions and displays the query results. The M2000 provides various types of search criteria. Therefore, users can easily view the required log information and save the query results in TXT, HTML, XLS, XLSX, PDF, or CSV files. Users can save search criteria as a template. Search criteria vary according to log types. The search criteria for operation logs are operation names, risk levels, operators, user types, time, categories, terminals, results, and details. The search criteria for system logs are risk levels, sources, operation time, basic information, operation results, and details. The search criteria for security logs are security events, risk levels, operators, user types, operation time, terminals, objects, results, and details.



Collecting log statistics The M2000 collects log statistics and saves the statistical results to tables. Users can customize the statistics by setting statistical items and filter criteria. Statistical items include users, terminals, operations, and results. Filter criteria are the same as search criteria. Users can save statistical conditions as a template. This function helps users to quickly learn about operating status, such as the period when most user operations are performed and the most frequently performed operations.

Issue 02 (2013-07-20)


100



Collecting and dumping logs The system saves the information about NE logs to the database.



Exporting logs This function allows users to export log information in the database to files. Log export tasks are managed and scheduled by the centralized task manager. The log export function contains two sub-functions, the latest data export and expiry data export. The latest data export function exports the log data that is generated recently to files for analysis. Users can set the conditions of data export, such as task names, execution periods, file formats, and save paths. The exported log data is not deleted from the database. The expiry data export function exports the log data that are generated before a preset time to files. After the data is exported, it is deleted from the database. Users can set the conditions of data export, such as task names, storage duration of log data (days), file formats, save paths, and whether to compress the file. Both export modes support exporting log data to an XML, HTML, TXT or CSV file.

Enhancement Logs can be exported to HTML and TXT files in M2000 V200R011C00.

WOFD-050300 NE Log Management Availability This feature was introduced in M2000 V200R002.

Summary This feature allows users to query and collect the statistics on the logs stored in the database. The logs contain NE operation logs, NE security logs. NE operation logs record operations performed by NE user, which help users to locate faults caused by manual operations. NE security logs record the security-related events such as logging in to the local maintenance terminals (LMTs) of NEs, changing NE user rights, and adding NE users. These logs help users to monitor the running status of NEs.


Collecting and storing logs The database stores all logs collected from NEs for a maximum of 90 days. Users can change the period. If the disk configuration for the M2000 is low or the space planned for the NE log database is less, users may not be able to store the logs for 90 days. When the M2000 reaches the end of the storage period or disk capacity limit, the M2000 automatically dumps NE logs to files. The M2000 collects subscribed log data from NEs using files and stores the data in the database. It also allows users to manually collect and import NE log data that has not been subscribed to, into the database. Both types of NE logs can be saved for a

Issue 02 (2013-07-20)


101



maximum of 90 days by default. Users can change the duration. If the disk configuration for the M2000 is low or the space planned for the NE log database is less, users may not be able to store the logs for 90 days. When the M2000 reaches the end of the storage period or disk capacity limit, the M2000 automatically dumps NE logs to TXT files. NE log data dumping is disabled by default because it affects the M2000's performance. 

Synchronizing logs By synchronizing the log information about the M2000 with that about NEs, the M2000 ensures the consistency of log information. The M2000 supports manual and automatic synchronization. Both manual and automatic synchronization are performed through tasks. Manual synchronization is triggered by users, and automatic synchronization is automatically triggered through preset M2000 parameters. Automatic synchronization tasks are managed and scheduled by using the feature WOFD-071200 Centralized Task Manager. Users can set task parameters such as task start time, execution period, and NEs. Users can also view the status and progress of a synchronization task.



Querying logs The system allows users to query logs according to the preset conditions and displays the query results. The M2000 provides various types of search criteria. Therefore, users can easily view the required log information and save the query results in TXT, HTML, CSV, PDF, XLSX, or XLS files. By default, the query results are saved in XLS files. Users can save search criteria as a template. Search criteria vary according to the log type. The search criteria for NE operation logs are user names, user types, terminals, NEs, and operation results and time The search criteria for NE security logs are time, users, user types, security levels, terminals, operation results, and NEs. All the NEs that support NE log management support NE operation logs. Currently RNC, NodeB, eNodeB, USU, eRelay, BTS3900, BSC6900 GSM, BSC6900 UMTS, BSC6900 GU, BSC6910 GSM, BSC6910 UMTS, BSC6910 GU, SGSN, GGSN, MGW, and IP Clock Server support security logs.



Collecting log statistics The system collects the statistics of log data and saves the statistical results to tables. Users can customize the statistics by setting statistical items and filter criteria. Statistical items include log types, users, terminals, operations, and results. Filter criteria are the same as search criteria. Users can save statistical conditions as a template. This function helps users to quickly learn about operating status, such as the period when most user operations are performed and the most frequently performed operations.



Exporting logs The M2000 exports NE log data generated within the latest time range to TXT and CSV files and provides the files for other systems or users to analyze. Users can set data export criteria such as task names, execution periods, valid time, file formats, and save paths. The exported log data is not deleted from the database.

WOFD-040900 Single Sign On Availability This feature was introduced in M2000 V200R010.

Issue 02 (2013-07-20)


102



Summary The OSS centralized user management function can centrally manage and authenticate the users of Huawei wireless OSS systems, such as the M2000, PRS, and Nastar. The single sign-on (SSO) server is deployed in the M2000 system, and an SSO client is deployed on the client in each OSS system. Therefore, users can switch between the OSS systems (M2000, PRS, Nastar) after logging in to the SSO server for only once. User groups are centrally granted rights on the SSO server.

Benefits 

Security administrators can centrally manage and authorize the users of the M2000, PRS, and Nastar. This simplifies the operations of managing and authorizing users.



Users can switch between the M2000, PRS, and Nastar after logging in to the SSO server for only once. When using multiple OSS systems, O&M personnel can use only one account and password to log in to the OSS systems. This prevents repeated user authentication.

Description When M2000, PRS, and Nastar are deployed on a network, users can configure the M2000 as the SSO server and install the SSO client on each OSS client. This ensures that the OSS systems run in centralized authentication mode. With the SSO feature, a user logs in to an OSS system once and gains access to all OSS systems without being prompted to log in again at each of them. The SSO client communicates with SSO servers through the Lightweight Directory Access Protocol (LDAP) and supports SSL encryption. The SSO provides the offline login function. If the SSO server is faulty, a user can log in to the SSO server by using the last user account recorded by the SSO client to manage the versions of SSO clients. The user account, however, cannot be authenticated on the SSO server. In such a case, the user can start a corresponding OSS client and use the local user account and password to log in to the OSS. The user account and password are authenticated locally in the OSS. In centralized authentication mode, the SSO provides a web-based user management GUI for security administrators to centrally manage OSS users, such as OSS user registration and authorization, and password complexity setting. The SSO server provides user management services based on HTTPS to ensure data transmission security. Security administrators grant users rights on a per user group basis. The rights of a user are determined by the rights of the group to which the user belongs. The SSO provides the LDAP-based interface (LDAP is short for Lightweight Directory Access Protocol). Therefore, a third-party security management system can perform operations related to user account management by using the LDAP-based interface on the SSO. In centralized user authentication mode, all local users of OSS systems except the default superuser are disabled. If the SSO server is faulty, the default superuser can log in to the SSO client to obtain the user account of the latest login. Then, the M2000 automatically allows the local accounts to restore the local security management function of the M2000, PRS, or Nastar.

Enhancement None

Issue 02 (2013-07-20)


103



Dependency This feature applies only to the Sun platform.

WOFD-000500 OS Hardening Availability This feature was introduced in M2000 V200R009.

Summary This feature enhances the security of the M2000 operating system by disabling unsecured operating system services, restricting access to files and directories, securing user accounts and passwords, and adjusting kernel parameters. OS hardening policies enable the M2000 to display a warning banner when users log in to the M2000 through FTP or SSH. In addition, the hardening policies provide system logs related to Inetd, FTP, cron tasks, and daemon process for users to tracing and audit the operations performed on the operating system. Before delivery, the M2000 performs security hardening on SUSE Linux and Solaris operating systems according to default hardening policies. Some hardening policies must be manually implemented in certain scenarios. For example, users must manually set TCP Wrappers.

Benefits The hardening policies protect operating systems against malicious attacks and enhance the security of the M2000 system. These policies include hardening the security of application, controlling the access to files and directories, adjusting kernel parameters, tracing and auditing logs, and securing user accounts and passwords.

Description The default hardening items are as follows: 

Application hardening This function lowers the system security risks by restricting the use of system services and disabling unsecured and unnecessary services. Solaris hardening policies include configuring SSH Daemon, disabling mail relay and external listeners, configuring SNMP, enhancing the security of NTP services, disabling RC services such as RPC and Apache, disabling traditional services such as SPC and auto install, and disabling inetd services such as RSH, RCP, Telnet. SUSE hardening policies include deleting unnecessary daemon processes, enabling the Initd service, Xinet service, SSH encryption algorithm, SSHD accounts, secure SSH authentication, and FTP security configuration, and limiting FTP users.



Log tracing and auditing Solaris: The M2000 provides system logs for users to trace system activities. The system logs include Inetd logs, FTP logs, debugging-level daemon logs, system log authentication messages, cron logs, su logs, login failure logs, and kernel auditing logs.

Issue 02 (2013-07-20)


104



SUSE: The M2000 provides system logs for users to trace system activities. The system logs include info event logs, cron task logs, daemon process logs, and kernel message logs. 

Kernel parameter adjustment Kernel parameters determine the network configuration status and rights for applications. Kernel parameter adjustment enhances the security of operating s ystems by adjusting or configuring network options, disabling information dumping, and enabling protocol stack protection.



User account and password securing Securing user accounts and passwords is an effective means of protecting operating systems against malicious attacks. User account and password securing policies for the Solaris operating system include locking user accounts without passwords, disabling system user accounts, setting the validity period for user accounts, forcing users to use complex passwords, using Message Digest Algorithm 5 (MD5) to encrypt passwords, and setting the home directory to a non-root directory. User account and password securing policies for the SUSE operating system include disabling system user accounts, using the hash algorithm to encrypt passwords, and forcing users to use complex passwords.



System access, authentication, and authorization This function enhances the security of operating systems by enabling users to set the scope of user operations and the execution environment of key services. The policies related to the Solaris operating system include details about using the main console, account management activities, and recent failed login attempts. The policies related to the SUSE operating system include restarting the system using the keyboard, setting the timeout of idle sessions, setting the secure single-user mode, setting SSH warning banners, restricting login attempts, and disabling remote login of user root.



File and directory rights All applications and data in the UNIX and Linux systems are stored as files. A directory that contains files is also regarded as a file. Therefore, the security of files and directories is of great importance to the UNIX and Linux systems. This function enhances the security of operating systems by setting rights for all the directories and files except the /proc directory. The policies for the Solaris operating system include checking the integrity of system files, restricting the access to the system files and directories in the system directory, restricting the access to key files and user home directories, setting system directory rights and owners, and setting secure network-shared directories. The policies for the SUSE operating system include restricting access to system directories, files, and executable files, setting files and directories that have no owners, restricting the use of the crob command, restricting the access to the PATH directories (only user root is authorized to access the PATH directories), and setting ro mounting.



Warning banners Warning banners are the messages displayed when users log in to the system through FTP or SSH. The messages indicate the penalties for unauthorized access to the system. This policy also hides system version information to protect the system against attacks.

Enhancement The following function is added to M2000 V200R011C00:

Issue 02 (2013-07-20)


105



Optional security hardening


Hardening the SUSE operating system

Dependency None

WOFD-000600 Database Hardening Availability This feature is introduced in M2000 V200R012C00.

Summary This feature enhances Oracle database security by restricting the access to files and directories, adjusting database parameters, locking unnecessary default user accounts, and preventing common users from accessing system tables. This feature enhances Sybase database security by locking unnecessary default user accounts, deleting unnecessary user rights information, increasing password complexity, and using the minimum software installation. By enhancing database security, this feature enhances M2000 system security. Before delivery, the M2000 performs Sybase and Oracle database hardening based on default hardening policies.

Benefits This feature combines database and operating system hardening to protect the M2000 against external attacks and enhance M2000 system security.

Description Oracle hardening items are as follows: 

Restricting access to files and directories This function reduces database security risks and improves database service security by restricting access to files and directories and preventing unauthorized users from accessing or modifying database files and directories.



Adjusting database parameters Database parameters determine memory usage and database listener configuration. This function enhances Oracle database security by setting database parameters such as database listener parameters.



Securing database user accounts and passwords Securing database user accounts and passwords is a significant means of protecting the database against external attacks. This function can be used to lock unnecessary default user accounts.



Authorizing operations on system tables This function enhances system security by setting database users' operation permissions for some system tables. The policies include preventing common users from accessing system tables and withdrawing the permissions of modifying system configurations.

Issue 02 (2013-07-20)


106



Sybase hardening items are as follows: 

Securing database user accounts and passwords This function enhances database security by locking unnecessary default user accounts, deleting unnecessary user rights, and enabling complex password policies and password encryption algorithms.



Managing rights and sessions This function deletes unnecessary user rights information.



Setting the system This function enhances database security by encrypting message transfer, ensuring message integrity, encrypting storage, using the minimum software installation, deleting unnecessary components, and disabling Java.

Dependency The ATAE cluster solution and PC Server support Oracle hardening. Sun-based single-server, HA, remote HA, SLS, and emergency systems, ATAE cluster solution, and PC Server support Sybase hardening.

WOFD-000800 Anti-virus Solution Availability This feature was introduced in M2000 V200R011C00.

Summary Main risks that threaten OSS security include viruses, worms, and spyware. To prevent OSSs from being attacked by these threats, Huawei provides antivirus solutions for Windows and SUSE Linux operating systems by deploying third-party software.

Benefits This feature protects M2000 and Citrix clients and servers from being attacked by viruses, worms, and spyware and enhances the system's antivirus capability.

Description OfficeScan 10.0 is deployed to provide antivirus protection for M2000 and Citrix clients and servers that run on the Windows operating system. ServerProtect for Linux 3.0 and Trend Micro Control Manager 5.0 are deployed to provide antivirus protection for M2000 servers that run on the SUSE Linux operating system.

Enhancement The antivirus solution applies to the ATAE cluster solution in M2000 V200R012C00.

Dependency ServerProtect for Linux 3.0 provides antivirus protection only for ATAE-based M2000 servers. OfficeScan 10.0, ServerProtect for Linux 3.0, and Trend Micro Control Manager 5.0 are Issue 02 (2013-07-20)


107



commercial antivirus software and must be purchased individually. Third-party software and hardware configured for the antivirus solution apply to OSS products such as the M2000, PRS, and Nastar after being deployed one time. Therefore, users do not need to purchase the software and hardware for each product.

2.7 Topology Management WOFD-060100 Topology Management Availability This feature was introduced in M2000 V200R002.

Summary Topology management provides a complete overview of the M2000 network topology. The topology view displays the networking and running status of devices. After an NE topology object is created, it is added to the M2000 topology.

Benefits 

Providing a complete overview of the WCDMA, GSM, LTE, and EPC network topology.



Providing a system portal, through which users are given direct access to NEs, which improves system usability.



Using subnets to represent the network hierarchy, which improving visibility. Working with the feature WOFD-040100 Centralized User Management and Authentication, the topology management feature allows users to operate and maintain NEs based on regions and NE hierarchy.

Description The topology management module displays objects such as NEs, links, and subnets in charts and navigation trees. It also provides functions of viewing configuration, alarms, and performance data, starting the MML clients and LMTs, and synchronizing logs, configuration, and alarm data 

Topology view In the topology view, the M2000 uses icons to identify different types of NEs. The topology view consists of a navigation tree in the left pane and a chart in the right pane. The navigation tree displays topology objects and their logical hierarchy. The navigation tree shows each topology object and the hierarchy. The topology map in the display pane shows all the topology objects and their basic information on the existing subnet, relationship between the objects, alarm status of the objects, and KPIs. Users can use the fuzzy search function to find and locate a topology object by using the following keywords: object name, IP address, version, vendor, and position, cell name. Users can create, add, and delete a topology object in the topology view. Users can create, add, and delete a topology object in the topology view. In the topology view, different icons represent different NEs and users can select an icon based on its size. The length of the topology object name displayed in the topology view can be set. The settings take effect only on this client. Users can change the background of the topology root view and subnet view. The M2000 supports the background image in JPG or GIF format.

Issue 02 (2013-07-20)


108



Administrators can export information about the root node, links, devices, and subnets to a CSV file. Then, the M2000 provides this file for a third-party system to re-create a topology. 

Topology object −

NE If the device can be managed by the M2000, it is termed physical NE. If the device cannot be managed by the M2000, it is termed virtual NE. The M2000 is a special NE in the topology view.

−

Link In the topology view, links are used to represent the physical or logical connections between NEs. Links are categorized into physical links and virtual links. Physical links refer to the links connecting physical NEs. Virtual links are created by users. They are used to represent the connections between NEs in the topology view. Currently, the M2000 supports links of the following types: M3UA, H248, BICCSCTPLNK, DATALINK, MTP3, MTP3B, and Fiber Link. M3UA, H248, and BICCSCTPLNK links are created automatically and cannot be created manually. DATALINK, MTP3, and MTP3B links need to be created manually.

−

Subnet In the topology view, subnets are used to categorize NEs. In this way, a large network is divided into several small subnets. Each subnet can contain a maximum of 500 NEs.

When creating objects, users need to set the properties of objects, such as name, IP address, version, vendor, position, region, description. The properties vary according to objects. The M2000 allows users to quickly create and delete NE objects in batches in the topology view. In addition, the M2000 allows users to modify the longitude and latitude information about NEs in batches in a file and import the file to the M2000 to implement the batch modification. The M2000 supports subnets. A well-designed physical subnet structure cannot only picture the actual topology of the network, but also facilitate routine operation and maintenance. The M2000 classifies a network into physical subnets by region, NE type, IP address, and maintenance personnel. 

NE and object status monitoring The M2000 allows users to monitor NEs in the entire network in real time. Users can learn about the status of the entire network in time by checking the alarm severities of NEs and connection status between NEs and the M2000. The M2000 allows users to quickly view the status of cells under GBTSs, NodeBs, and eNodeBs. It also provides shortcuts to facilitate operations on cells, such as activating and deactivating a cell.


The M2000 allows users to quickly view the status of cells under GBTSs, NodeBs and eNodeBs and provides shortcuts to facilitate operations on cells


Issue 02 (2013-07-20)

The length of the topology object name that can be displayed can be set. The settings take effect only on this client.


109





Users can change the background of the subnet view.



In the topology view, users can select an icon based on its size.



Modify the longitude and latitude information about NEs in batches by importing the file to the M2000.


The M2000 allows users to export topology relationship data to a CSV file. The file is provided to a third-party system for re-creating topology.


An IP-featured icon is used to identify the NodeB whose transmission mode is IP transmission.

Dependency The KPI values displayed in the topology view are provided by the feature WOFD-190100 Real-Time Performance Monitoring. If this feature is unavailable, the topology view does not display KPI values.

WOFD-060200 NE Automatic Detection Availability This feature was introduced in M2000 V200R002.

Description The NE automatic detection feature allows the M2000 to detect lower-level NEs based on the configuration data of an NE. For example, this feature allows the M2000 to automatically detect NodeBs based on the configuration data of an RNC. Then, based on the detection results, the M2000 creates NE topology objects and establishes connection with the objects. In this way, the NEs are managed by the M2000. The M2000 is a special NE. Therefore, this feature also applies to the M2000. The system supports manual search and automatic search. After users create the topology object of an upper-level NE, the M2000 automatically synchronizes its configuration data and searches for its lower-level NEs after the synchronization is complete. The process is called automatic searching. Manual searching is a mode based on which users trigger the process of searching for lower-level NEs in the M2000 topology view. Before enabling the NE automatic detection function, users need to ensure that the upper-layer NE is connected properly to the M2000 server. For example, before using the NodeB automatic detection function, users must ensure that the RNC, BSC6900 UMTS, or BSC6900 GU to which the NodeBs belong is properly connected to the M2000 server. The eNodeB automatic detection is implemented during eNodeB automatic deployment (WOFD-280400 eNodeB Auto-Deployment – LTE FDD/TDD). Therefore, it is not included in this feature. The M2000 can automatically detect the CORE ATCA NEs of the specified CGPOMU on the physical topology view. After CGPOMU is created successfully, the CGPOMU automatically searches for its sub-NEs. The detected sub-NEs are displayed in the topology view. If the communication between the CGPOMU and its sub-NEs is abnormal, the sub-NEs fail to be

Issue 02 (2013-07-20)


110



automatically found. In such a case, user can manually trigger the Search CORE NE function of the CGPOMU to search for the sub-NEs.


The NodeB automatic detection in IP-based WRAN networking mode

WOFD-060700 Wireless Transmission Devices Search Availability This feature was introduced in M2000 V200R008.

Summary Mobile networks contain a large number of transmission devices. Therefore, the M2000 manages the transmission devices such as optical fibers, microwave devices (for example, RTN), and cables to perform centralized network management. To enable users to selectively create and manage the required transmission devices, the M2000 provides the transmission devices search function.

Benefits Device search helps users find and create optical devices, microwave devices, and transmission links. By using this function, users can find transmission devices and links that meet the preset search criteria and create transmission devices and links on the M2000 quickly.

Description By using this function, users can find all the transmission devices and links that meet the search criteria on the network, select the required devices, and create the devices in the topology. Users can create search tasks. The M2000 displays all the created search tasks in a list so that users can start or stop the search operation on a task by selecting it from the list. When searching for transmission devices, users can set the device IP address or the IP network segment the device IP address is located on as the search criterion. The M2000 displays all the searched optical devices or microwave devices in a list. Users can select one or more devices from the list to create topology objects. After creating transmission devices, users can create optical fiber links between Metro1000V3 and OSN3500. The method of creating transmission links is similar to the method of creating transmission devices. Users should specify the target transmission devices and start the link search. The M2000 displays all the searched optical links or microwave links in a list. Users can select one or more links from the list to create topology objects. If the actual networking links collide with the M2000 data, users can delete the networking links as required.

Enhancement None

Issue 02 (2013-07-20)


111



2.8 NE License Management WOFD-070400 NE License Management Availability This feature was introduced in M2000 V200R002.

Description The NE license management feature includes base station controller, NodeB, eNodeB, and standalone license management. The base station controller license management functions are as follows: 

Viewing detailed license information



Transferring license files



Activating license files



Synchronizing license files



Downloading license files



Deleting license files



Backing up license files on a scheduled basis The M2000 periodically backs up the license files that are activated on NEs. The M2000 centrally manages license backup tasks based on the feature WOFD-071200 Centralized Task Manager. User can set execution time for license backup tasks. Currently, only the BSC6900 GSM, BSC6910 GSM, BSC6900 UMTS, BSC6910 UMTS, BSC6900 GU, and BSC6910 GU support this function.



Activating license files on a scheduled basis In non-RAN sharing scenarios, users can create scheduled tasks to deliver and activate GBSC and RNC license files. The M2000 centrally manages license delivery tasks based on the feature WOFD-071200 Centralized Task Manager. User can set execution time for license delivery tasks. Currently, the RNC, BSC6900 GU, BSC6910 GU, BSC6900 UMTS, BSC6910 UMTS, BSC6900 GSM, and BSC6910 GSM support this function.



Exporting license data on a scheduled basis The M2000 exports license data about NEs to files on a scheduled basis. The export tasks are managed and scheduled centrally by using the feature WOFD-071200 Centralized Task Manager. Users can set the time and period for running a task. Currently, this feature applies to the NodeB, eNodeB eGBTS, BSC6900 GU, BSC6910 GU, BSC6900 UMTS, BSC6910 UMTS, BSC6900 GSM, and BSC6910 GSM. License data for the NodeB and eGBTS can be exported as CSV and XML files, while the data for base station controllers and eNodeBs can be exported only as XM L files.



Providing a northbound license file interface The M2000 exports NE license data as an XML file on schedule. A third-party system can obtain this file by using FTP. Export tasks for the northbound license file interface are centrally managed and scheduled by using the feature WOFD-071200 Centralized Task Manager. Users can set the time and period for running a task. Currently, this feature applies to the eNodeB, NodeB, eGBTS, BSC6900 GU, BSC6910 GU, BSC6900 UMTS, BSC6910 UMTS, BSC6900 GSM, and BSC6910 GSM.

NodeB license allocation and management functions are as follows:

Issue 02 (2013-07-20)


112





Uploading or downloading license files to or from the M2000 server and client



Allocating NodeB license information All the NodeBs under an RNC use the resources specified in the same license file. The M2000 allows users to upload and download license files between the M2000 client and server and centrally allocate license resources to NodeBs in a RAN system.



Exporting and importing license information Users can manually export the license data of a single NodeB or all NodeBs under an RNC to CSV files. The exported file informs users about how licenses are allocated to NodeBs. Users can also import NodeB license allocation information to the M2000.



Delivering NodeB license information The M2000 centrally manages scheduled NodeB license delivery tasks based on the feature WOFD-071200 Centralized Task Manager. Users can specify the task execution time and period. Users can also manually deliver NodeB license information.



Generating NodeB license allocation threshold alarms This function applies to NodeB resource licenses. On a RAN sharing network, when the ratio of the total amount of license resources allocated to all of the operator's NodeBs to the amount of resources specified in purchased licenses reaches the preset threshold, a threshold alarm is generated. On a non-RAN sharing network, when the ratio of the total amount of license resources allocated to all the NodeBs to the amount of resources specified in purchased licenses reaches the preset threshold, the M2000 generates a threshold alarm. When the ratio is within the normal value range, the M2000 clears the corresponding threshold alarm. This function is disabled by default and can be enabled based on site requirements.



Disabling a NodeB license The M2000 allows users to disable a NodeB license. After a NodeB license is disabled, the M2000 generates a failure code that Huawei technical support uses to apply for a new license. This significantly improves efficiency in replacing licenses in cases such as capacity adjustment, ESN change, customer name change, and version upgrades. On the M2000 GUI, users select an RNC and disable the license of the NodeBs under the RNC. The M2000 returns a failure code and sends a failure notification to the NodeBs. When the NodeB license is disabled, the license automatically applies a grace period of 60 days. Within the grace period, the NodeB license can be used properly, but it becomes invalid after the grace period. Users can obtain the license status b y viewing the NodeB license information.



Allocating a trial NodeB license If a user does not purchase certain features for a device, the user can use these features for a trial period to determine whether to purchase the features. A commercial license containing such features is called a trial license. The default validity period of a trial license is three months. Trial licenses do not affect purchased license items in the commercial license. When the trial license is used, each function of the RAN system can be used only once. When users allocate a trial NodeB license on the M2000, the M2000 delivers the validity period of the trial license to NodeBs. Based on the validity period, the NodeBs confirm the validity period of the features controlled by the license. The M2000 does not allow users to allocate or adjust license items that exceed the validity period of the trial license.

eGBTS license management involves GBTS and eGBTS license management and provides the following functions: 

Uploading or downloading license files to or from the M2000 server and client



Allocating license information

Issue 02 (2013-07-20)


113



All GBTSs and eGBTSs under a base station controller use the resources specified in the same license file. The M2000 allows users to upload or download license files to or from the M2000 server and client and centrally allocate license resources to eGBTSs. 

Exporting and importing license data Users can manually export all base station license information under a single base station or base station controller to a CSV file. By viewing the exported file, users can learn about the license allocation information. Users can also import the license allocation data to the M2000.



Delivering eGBTS license information The M2000 centrally manages scheduled eGBTS license delivery tasks based on the feature WOFD-071200 Centralized Task Manager. Users can specify the task execution time and period. Users can also manually deliver eGBTS license information.



Generating eGBTS license allocation threshold alarms This function applies to eGBTS resource licenses. On a RAN sharing network, when the ratio of the total amount of license resources allocated to all of the operator's eGBTSs to the amount of resources specified in purchased licenses reaches the preset threshold, a threshold alarm is generated. On a non-RAN sharing network, when the ratio of the total amount of license resources allocated to all the eGBTSs to the amount of resources specified in purchased licenses reaches the preset threshold, the M2000 generates a threshold alarm. When the ratio is within the normal value range, the M2000 clears the corresponding threshold alarm. This function is disabled by default and can be enabled based on site requirements.



Disabling an eGBTS license The M2000 allows users to disable an eGBTS license. After an eGBTS license is disabled, the M2000 generates a failure code that Huawei technical support uses to apply for a new license. This significantly improves efficiency in replacing licenses in cases such as capacity adjustment, ESN change, customer name change, and version upgrades. On the M2000 GUI, users select a base station controller and disable the license of the eGBTSs under the base station controller. The M2000 returns a failure code and sends a failure notification to the eGBTSs. When the license is disabled, the license automatically applies a grace period of 60 days. Within the grace period, the license can be used properly, but it becomes invalid after the grace period. Users can obtain the license status by viewing the license information.



Allocating a trial eGBTS license If a user does not purchase certain features for a device, the user can use these features for a trial period to determine whether to purchase the features. A commercial license containing such features is called a trial license. The default validity period of a trial license is three months. Trial licenses do not affect purchased license items in the commercial license. When the trial license is used, each function of the GSM system can be used only once. When users allocate a trial eGBTS license on the M2000, the M2000 delivers the validity period of the trial license to eGBTSs. Based on the validity period, the eGBTSs confirm the validity period of the features controlled by the license. The M2000 does not allow users to allocate or adjust license items that exceed the validity period of the trial license.

Standalone license management refers to management of eNodeB, USU, DBS3900 IBS, and eRelay licenses. Standalone license management involves the following procedures: 

Issue 02 (2013-07-20)

Applying for a license


114





Installing the license file



Updating the license



Viewing license status

The M2000 provides the following functions for implementing these procedures: 

Viewing license information The M2000 displays detailed NE license information (such as NE l icense type, status, expiration time, and time for the grace period) on a list. Users can synchronize the latest NE license information from NEs to the M2000.



Loading a license file Users download a license file from the M2000 to an NE for the license file to take effect.



Backing up a license file



After delivering a license file to an NE, the M2000 automatically backs up the license file to the backup directory.



Exporting information to apply for a commercial license file Each NE must be configured with an individual license file. Users export the NE type, ESN, license serial number (LSN), and the license allocation and usage information during NE commissioning to an XML file. The exported XML file serves as a reference to applying for a new license file.



Exporting the information about adjusting a license file After a commercial license file is configured for an NE, the license file needs to be updated because of network change or optimization. The procedure for updating an NE license file is as follows:



1.

Invalidates the license.

2.

Obtains an invalidity code.

3.

Exports information such as license usage, requirement evaluation data, invalidity code, and ESN to an XML file.

4.

Applies for a new license file based on the exported information.

Backing up license files The M2000 allows users to manually back up NE license files in batches to the M2000 server.



Obtaining license file backups The M2000 allows users to download license file backups from the M2000 server to a user-specified directory on the local PC.



Invalidating a license The procedure for invalidating an NE is similar to that for invalidating a NodeB license. Before updating the license information about an NE, users must invalidate the existing license to obtain an invalidity code, which is mandatory for applying for a new license.


Standalone license management provides the functions of backing up license files and obtaining license file backups.


Issue 02 (2013-07-20)


115





eGBTS license allocation management



License management for new NEs such as the USU and BSC6910


Providing a northbound license file interface for eNodeBs



Backing up eNodeB license files



Backing up BSC6900 UMTS license files on a scheduled basis



Downloading NodeB license files from the M2000 server to the M2000 client


Disabling a NodeB license



Allocating a trial NodeB license


Delivering NodeB licenses on a scheduled basis



Delivering and activating the license files of the RNC, BSC6900 GU, BSC6900 UMTS, and BSC6900 GSM on a scheduled basis in non-RAN sharing scenarios



Exporting the license data about the NodeB, NodeB, BSC6900 GU, BSC6900 UMTS, and BSC6900 GSM on a scheduled basis



Immediately exporting the license data of the NodeBs under a selected RNC



Generating NodeB license allocation threshold alarms



Providing a northbound license file for the NodeB, BSC6900 GU, BSC6900 UMTS, and BSC6900 GSM


Managing eNodeB license information



Managing license information about BSC6900 UMTS, BSC6900 GSM, and BSC6900 GU



This feature applies to NodeBs in RAN6.0 and later versions.



By integrating with the feature WOFD-210200 Automatic File Upload, the northbound license file interface provided in this feature allows the M2000 to upload alarm files to the third-party and other systems.

Dependency

WOFD-071600 NE Emergency License Management Availability This feature was introduced in M2000 V200R008.

Summary Generally, telecom operators can use only the network services that are restricted by license resources. The requests for using the services that are beyond license control are denied by NEs.

Issue 02 (2013-07-20)


116



The M2000 allows telecom operators to manually activate the emergency license function. After the function is activated, NEs provide services with the maximum capability, and they are not restricted by licenses. After the emergency status ends, the capability of NEs is controlled by licenses again.

Benefits With the emergency license function, telecom operators are able to provide proper services in the case of emergencies when there is sharp increase in traffic, meeting the requirements of end users.

Description Telecom operators can manually activate or deactivate the emergency license function. The M2000 enables the license to enter the emergency state by sending MML commands to an NE. The license enters the emergency state immediately when the MML commands are sent, and the state lasts seven days. Each R version of the RAN system can enter the emergency license state three times. If the license has entered the emergency state three times, users must upgrade the RAN software to use this function.

Dependency This feature applies to RNCs in RAN11.1 and NodeBs in RAN13.0 and later versions.

2.9 Hardware and Software Management WOFD-110100 NE Software Management Availability This feature was introduced in M2000 V200R002.

Summary NE software management provides dedicated O&M procedures to manage NE version files and upgrade NE versions and patches based on NE software maintenance scenarios. NE software management allows users to query, upgrade, back up, and delete NE version software, patches, configuration data files, and license files. NE software management is classified into software upgrade management and file management. Software upgrade management provides various NE upgrade methods based on upgrade scenarios, including the SME, task-based upgrade, wizard-based upgrade, and external upgrade. NE upgrade management facilitates NE upgrades. File management allows users to check and transfer files stored on the M2000 and NEs. File management facilitates NE file management.

Benefits This feature brings about the following benefits:

Issue 02 (2013-07-20)


117





This feature provides upgrade project management and batch upgrade mode based on NE upgrade operations. In this way, NE upgrade management becomes more reasonable by reducing a large amount of repetitive work. It can also reduce errors caused by manual operations and improve upgrade efficiency.



The M2000 provides a user-friendly GUI, which simplifies upgrade operations and improves upgrade efficiency.



The NE file management simplifies local operations and implements easy, efficient, and centralized NE file management.



Remote management enables users to copy and operate software remotely, reducing telecom operators' OPEX.

Description NE software management provides the following functions: NE file management, and NE software and patch upgrade. NE File Management:

NE software management allows users to centrally manage NE version software, patches, licenses, and configuration data. This reduces O&M operations and improves O&M efficiency. The managed file types are as follows: 

Software: indicates the software of NEs, including cold patches. NOTE

The patches of NE software are categorized into hot patches and cold patches. After cold patches are loaded, NEs need to be restarted. After hot patches are loaded, NEs do not need to be restarted. Cold patches are managed as special software. 

Patch: indicates hot patches of NEs.



Data: indicates configuration files and log files of NEs.



Software upgrade package: indicates the package used for software upgrades. A software package contains the programming files required for running boards.



Patch upgrade package: indicates the package used for patch upgrades. A patch upgrade package contains the hot patch files required for running boards.



Patch package of third-party software: indicates the package of third-party software, such as the BAM OS patch.



Upgrade risk check package: indicates the check scripts of the SME. It provides check items for software upgrade, such as upgrade path, version mapping, and upgrade risk. The file types supported by the M2000 vary according to NEs. Table 2-4 provides the details.

Table 2-4 File types supported by NEs

NE Type

Supported File Type

RNC

Software upgrade package, patch upgrade package, patch package of third-party software, and LMT software package

NodeB

Software, patch, data, LMT software package, upgrade risk check package, SPP package, and others

eNodeB

Software, patch, upgrade risk check package, and others

MSC Server

Software

Issue 02 (2013-07-20)


118



NE Type

Supported File Type

MGW

Software, patch, and data

SGSN


GGSN


BSC6900

Software upgrade package, software upgrade patch, and patch package of third-party software

BSC6910

Software upgrade package, software upgrade patch, and patch package of third-party software

GBTS

Software, upgrade risk check package, and patch

BTS3900


USU


eRelay


IP Clock Server

Software

AG

Software and patch

HLR9820, SAEHSS, and HSS9860

Software

IWF


UGW


NE file management provides the following functions: 

Checking version information about the M2000 server software and software installed on the M2000 server. The version information includes the versions and patches of the M2000 server software, version of each NE mediation, and version of the CORBA interface.



Checking version file information about all NEs stored on the M2000 server, current version file information used by NEs and version file information stored on NEs.



Transferring NE files: Users can upload NE version software, patch, and license files to NEs and monitor the upload.



Deleting unnecessary version files and backing up NE data: Users can delete unnecessary version files from the M2000 server and back up NE data on the M2000 server for data restoration. Users can manually back up NE data or create scheduled backup tasks for automatic backup.

NE Software and Patch Upgrade:

The M2000 provides the following methods for upgrading NE software and patches based on site requirements: Software Management Expert (SME), task-based upgrade, and external upgrade. SME:

Issue 02 (2013-07-20)


119



The SME provides an end-to-end upgrade solution and upgrade guide. SME-based upgrade applies to NEs including GBTS, eGBTS, NodeB, eNodeB, BTS3900, USU, DBS3900 IBS and eRelay. The end-to-end upgrade solution includes operation procedures, such as upgrade planning, upgrade preparation, upgrade execution, and upgrade completion, in compliance with users' O&M requirements. The M2000 manages the software upgrade of base stations as a project. When users plan a network upgrade, they must first create an upgrade project and set a target version for the project. Afterwards, they sort the NEs to be upgraded into an upgrade batch. The upgrade project comprises of three operation procedures: preparation information check, pre-upgrade check, and upgrade execution. Pre-upgrade check includes a feasibility check and a risk check. Items required for feasibility and risk checks, such as the upgrade path, version mapping, and upgrade risks, are determined based on the imported upgrade risk package. Upgrade execution involves NE software delivery and activation. Upgrade projects can be executed immediately, manually, or on a scheduled basis. The SME allows users to view reports about successfully executed batch upgrade tasks and compare the alarm and cell status before and after the upgrade. This helps analyze and verify the upgrade results. Such reports are saved in CSV format on the M2000 client. If some NEs fail to be upgraded during a batch upgrade task, users can repeat the pre-upgrade check and upgrade execution procedures for these NEs until they are successfully upgraded. 

Task-based upgrade Users create an upgrade task and set task parameters on the M2000 client. Afterwards, the M2000 automatically executes the upgrade based on the task settings. The BSC6000 also supports manual upgrade and scheduled upgrade. The upgrade procedures vary slightly according to NEs: −

Upgrading software and patches of multiple NEs of the same type concurrently Task-based upgrade allows users to upgrade the software and patches of multiple NEs of the same type concurrently. Such NEs include NodeB, MGW, GBTS, eNodeB, GGSN, MSC server, and IP clock server. Users can upgrade around 1800 base stations within four hours at night using this scheme. The M2000 upgrades NEs in batches to avoid affecting other system operations. Users can set the execution steps and execution type of an upgrade task as required. Execution types include immediate execution, manual execution, and scheduled execution. Task-based upgrade gives a pre- and post-upgrade alarm. It additionally gives cell status check reports for the eNodeB, NodeB, and GBTS to help users verify and analyze the upgrade results and quickly detect the impacts of the upgrade on devices and services. Such reports are saved in CSV format on the M2000 client. Task-based upgrade also provides pre- and post-upgrade health check reports for the eNodeB. To learn which check items are supported, see "WOFD-240100 Network Health Checking."

−

Rolling back the software and patches of NEs in batches Task-based upgrade allows users to roll back the software and patches of NEs in batches. Such NEs include MSC server, eNodeB, NodeB, and GBTS. Users do not need to reload or re-activate software and patch versions. Instead, they can directly use the software version saved in the main control board of the NE. This function applies to GBTSs including BTS3900, BTS3900A, DBS3900, and BTS3900L.

−

Upgrading or Rolling back the patches for purchased software of NEs in batches Task-based upgrade allows users to upgrade or roll back the patches for the purchased software of NEs in batches. Such NEs include BSC6800, BSC6900 UMTS, BSC6900 GSM, BSC6900 GU, BSC6910 GSM, BSC6910 UMTS, and BSC6910 GU. It allows

Issue 02 (2013-07-20)


120



users to upgrade the versions of purchased software and patches for multiple NEs of the same type concurrently. 

Wizard-based upgrade Wizard-based upgrade allows users to upgrade the software and patches of only one NE. Only the MSC server and HLR9820 support wizard-based upgrade.



External upgrade External upgrade allows users to upgrade the software and patches of one or more NEs by using the single-step upgrade wizard and NE upgrade tool of the M2000. This function applies to NEs including RNC, BSC6900 UMTS, BSC6900 GSM, BSC6900 GU, BSC6910 GSM, BSC6910 UMTS, and BSC6910 GU.

After NE software is upgraded by using the SME or in wizard-based or task-based mode, the M2000 provides an HTML upgrade report. This report, saved on the M2000 client, records detailed upgrade procedures and execution results, such as NE types, target versions, parameter settings, upgrade steps, and start time, end time, and execution result of each step. When a user creates an NE upgrade task, the M2000 performs a self-check on the CPU usage. If the CPU usage is high, the M2000 prompts the user to choose other time for the upgrade. Users can stop and retry upgrade tasks in batches.

Enhancement M2000 V200R013C00 optimizes the following functions provided by the SME: 

The upgrade processes for base stations of all RATs are normalized. Therefore, one project can be used for upgrading base stations of multiple RATs. This improves upgrade efficiency and user experience.



Users can set upgrade batches to reduce repeated NE selections at each upgrade stage, improving upgrade efficiency.



Users can plan upgrade batches by region according to the distribution of base stations under base station controllers and subnets. This avoids selecting base stations one by one and therefore no base station will be missed.



Software management for BTS3900, BTS3202E, BTS3203E, BTS3803E, and DBS3900 IBS


Verifying upgrades using the SME



Viewing pre- and post-upgrade cell status comparison reports after an eNodeB, NodeB, or GBTS is upgraded



Upgrading BSC6900 UMTS and BSC6900 GU patches in batches


Checking software integrity



Providing the SME for the NodeB, eNodeB, and GBTS



Providing reports for wizard- and task-based upgrade and SME



Creating file transfer tasks in batches



Stopping or retrying tasks in batches



Checking the M2000 CPU usage before the upgrade

The following functions are added to M2000 V200R010:

Issue 02 (2013-07-20)


121





Rolling back GBTS and NodeB software and patches in batches



Providing integrity check and policy-specific upgrades for eNodeB software versions



Upgrading third-party software patches for the BSC6900 UMTS and BSC6900 GU in batches


Rolling back software and patches of MSC Servers and eNodeBs in batches



Upgrading purchased software and patches of BSC6900 GSM and BSC6800 in batches



Performing health checks on the eNodeB at the pre-upgrade and post-upgrade stages



Providing external upgrades for BSC6900 GSM, BSC6900 UMTS, and BSC6900 GU


Managing MSC Server and eNodeB software



Applying 3900 and 3012 series GBTS patches

Dependency GBTS patch installation applies to GBSS8.1 and later versions.

2.10 Network Monitoring and Analysis WOFD-021100 Local Interface Tracing Availability This feature was introduced in M2000 V200R003.

Description The LMTs of NEs provide the interface tracing function, which traces signaling messages and single UE signaling messages. The LMTs trace these messages in real time. Users can save the messages as TXT or TMF files for offline browsing. After starting the LMT of a specified NE in the M2000 topology view, users can monitor network status in real time, and detect and locate problems in time by creating interface and signaling link tracing tasks. To ensure security of data transmission between LMTs and NEs, LMTs based on the iView platform support SSL-encrypted transmission, and web LMTs support HTTPS-encrypted transmission.


Issue 02 (2013-07-20)


122



WOFD-021200 Local Real-Time Status Monitoring Availability This feature was introduced in M2000 V200R003.

Description The LMT of the NE provides the function of monitoring the status of NE in real time. The results can be displayed in charts or through data. The running status of ongoing services and of the M2000 system can be monitored. In addition, this feature supports exception analysis and device maintenance. After starting the LMT of a specified NE through the topology view of the M2000, users can create real-time status monitoring tasks. The monitoring function varies according to the NE type. The CPU usage of all NEs can be monitored. The other items that can be monitored are as follows: 

RNC and BSC6900 UMTS monitored items: includes CPU/DSP usage, block error rate (BLER), port error seconds, connection performance, cell performance, and link performance.



NodeB monitored items: include cell service resources, board service resources, uplink frequency scanning, RTWP measurement, temperature, power, and clock test.



BSC6900 GSM and BSC monitored items: include CPU/DSP usage, bit error rate, port error seconds, GPRS user plane traffic, Abis HDLC channel transmission resource usage, cell performance, and DSP service resources.



AG monitored items: include port traffic information.



eNodeB monitored items: include cell performance, user performance, RRU performance, and transmission performance.

To ensure security of data transmission between LMTs and NEs, LMTs based on the iView platform support SSL-encrypted transmission, and web LMTs support HTTPS-encrypted transmission.


WOFD-014300 Maintenance Mode Management Availability This feature was introduced in M2000 V200R008.

Summary The M2000 allows users to manage the lifecycle of NEs by setting maintenance modes for NEs. In this way, users can perform appropriate maintenance on the NEs according to their maintenance modes. For example, users can distinguish common alarms and maintenance mode alarms that are generated in scenarios such as network setup, expansion, and upgrade.

Issue 02 (2013-07-20)


123



This reduces the impacts of maintenance mode alarms on monitoring common alarms and improves maintenance efficiency. In addition, users can focus on the alarms that affect services.

Description NE maintenance policies vary according to scenarios such as NE deployment, upgrade, commissioning, capacity expansion, and normal operation. To meet maintenance requirements in different scenarios, the M2000 provides a flexible mechanism so that users can adopt different maintenance policies to maintain NEs based on NE maintenance modes. For example, during deployment, upgrade, and commissioning, NEs will generate a large number of unnecessary alarms. The statistics about the live network indicate that the ratio of the unnecessary alarms to all generated alarms is greater than or equal to 85%. If these alarms are not differentiated from common alarms, maintenance engineers may fail to identify important alarms in time. Users can set NE maintenance modes on the M2000. When the network is in a specified state, users can set the status of an NE to the corresponding state on the M2000. The M2000 regards NE maintenance modes as a type of index. Users can filter various NE data by maintenance mode in scenarios such as processing maintenance mode alarms and filtering NEs in a topology view. 

Maintenance mode management: Currently, the default maintenance modes are normal, initialization, upgrade, expansion, and commissioning. To meet specified user requirements, the M2000 allows users to set 10 extended maintenance modes based on the five default modes. Users can customize a maintenance mode by setting the name of an extension mode. Users can define alias names for NE maintenance modes on the M2000, set and query maintenance modes, and export them to CSV files.



Maintenance mode alarms: Alarms generated in other NE modes, except the "normal" mode, are regarded as maintenance mode alarms. After the maintenance mode settings take effect, the M2000 handles alarms based on the maintenance mode identities in the alarms reported by NEs. By default, the M2000 does not monitor maintenance mode alarms. After receiving a maintenance mode alarm, the M2000 does not display the alarm, generate an audio or visual alarm message, send an alarm notification, or forward the alarm to a third-party system. In the alarm monitoring window, users can browse, query, and collect statistics on maintenance mode alarms by maintenance mode. This meets the requirements in specified scenarios.



Topology filtering: The M2000 allows users to query the maintenance modes of NEs in a topology view and allows users to filter NEs by maintenance mode.


Defining alias names for maintenance modes



Enabling the customization of maintenance modes for RNC, NodeB, BSC6900 GSM, BSC6900 GU, BSC6900 UMTS, GBSC, and GBTS


Querying the maintenance modes of NEs in the topology view



Exporting the NE maintenance modes to a CSV file


Issue 02 (2013-07-20)

The M2000 supports filtering NEs based on maintenance modes in the topology view.


124




The management of maintenance mode is available for the BSC6900 GSM, BSC6900 GU and eNodeB.



User can customize the maintenance modes of the eNodeB.

Dependency This feature applies to eNodeBs in eRAN1.1 and later versions. Users can use this feature in GSM networks only after they have purchased the corresponding GBSS features.

WOFD-031700 Radio Frequency Performance Check Availability This feature was introduced in M2000 V200R008.

Summary An excessive voltage standing wave ratio (VSWR) reduces communication distances, and the power amplifier pipe pipe may be burnt because the reflected power power returns to the transmit transmit power amplifier. amplifier. This affects normal communication. To solve this problem, the M2000 provides the VSWR test function, which allows users to remotely monitor base station VSWR. This feature supports tests on one or multiple frequencies, and applies in the following scenarios: 

In the early stages of base station deployment, Huawei GTS personnel use this feature to test the project quality of the cooperation partner. partner.



During the delivery of the entire network, users use this feature to test the project quality.



This feature is used in routine maintenance scenarios.

To improve O&M efficiency for RFs on the air interface, the M2000 provides intermodulation counter detection, services-based intermodulation interference detection, and external network interference detection. Service-based intermodulation interference detection can be performed online or offline. Intermodulation counter detection can be performed by selecting specified or random frequencies. The M2000 introduces the functions of detecting intermodulation interference and external network interference. Intermodulation interference detection involves lossy intermodulation interference and lossless intermodulation interference. External network interference detection occurs only on GBTS because only the interference on the GSM network, which is caused by the CDMA network, can be detected.

Benefits Compared with the traditional method of using measurement instruments to monitor base station VSWRs, this feature allows users to remotely monitor BS VSWRs on the M2000 and therefore reduces maintenance and labor costs. The function of detecting RF interference simplifies the troubleshooting process for customers based on the experience experience of RF experts. experts. They have have unique values for improving improving network O&M efficiency.

Issue 02 (2013-07-20)


125



Description The VSWR test function involves VSWR query and threshold settings. Currently, Currently, GBTSs, NodeBs, eNodeBs, eNodeBs, and BTS3900s support support VSWR testing testing for a single frequency or multiple frequencies. 

VSWR query: Users can select one or multiple base stations (the version of the selected base stations excluding GBTSs GBTSs must be the same) same) in the query window to view view the VSWR of the BTSs/NodeBs. They can save or print the query results. The query results are saved in a CSV, PDF, HTML, TXT, XLS, or XLSX file.



Threshold settings: Users can divide VSWRs into multiple value ranges and set a display color for each value range. After the colors are set, the M2000 displays the value ranges of the query result in the user-defined user-defined colors.



The function of detecting RF interference involves setting detection parameters, starting or stopping the detection, and viewing the detection progress and results. Users can save the detection results in a CSV, CSV, XLS, or XLSX file. The following table describes the detection functions supported by GBTSs, NodeBs, and eNodeBs:

Detection Item

Detection Mode

GSM

UMTS

LTE

Intermodulation counter detection

Specified frequencies

√

√

√

Random frequencies

√

√

√

Online

√

√

√

Offline

√

√

√

Service-based intermodulation interference detection External network interference detection

√

In addition, the M2000 supports intermodulation interference detection between base stations of an MBTS, which involves the following: −

Intermodulation counter detection for a single base station of an MBTS: tests physical antenna attributes attributes

−

Service-based Service-based intermodulation interference detection for a single base station or between base stations of an MBTS: tests the intermodulation interference interference for the configured service frequencies


Multi-frequency VSWR testing for NodeBs, eNodeBs, BTS3900s, eGBTSs, and GBTSs, avoiding missing detection of VSWR threshold alarms, compared with testing only the VSWR of the center frequency



Intermodulation interference detection between base stations of an M BTS, offline service-based intermodulation interference detection for GBTSs, online service-based service-based intermodulation interference detection for eNodeBs and NodeBs, and MBTS intermodulation interference detection



2-tone intermodulation counter detection, sweep intermodulation counter detection, online service-based intermodulation detection, offline service-based intermodulation

Issue 02 (2013-07-20)


126



detection, external network interference interference detection, and MBTS intermodulation interference detection for BTS3900s. The following functions are added to M2000 V200R011C00: 

Detecting intermodulation interference and external network interference



Querying VSWRs of eNodeBs

Dependency The VSWR test function applies to GBTSs and NodeBs in GBSS8.1 and RAN11.0 and later versions. The GBTSs that support this feature include BTS3012, BTS3012AE, BTS3006C, BTS3002E, DBS3036, DBS3900 GSM, BTS3036, BTS3900 GSM, BTS3036A, BTS3900A GSM, and BTS3900C GSM. The NodeBs that support this feature include DBS3800, BTS3900 series, and DBS3900 series. External network interference detection applies to DBS3900, BTS3900, BTS3900L, and BTS3900A. Service-based intermodulation interference detection applies to BTS3900 and DBS3900 services of NodeB type. Service-based intermodulation interference detection applies to BTS3012, BTS3012AE, BTS3006C, BTS3002E, DBS3900, BTS3900, BTS3900L, BTS3900L, BTS3900A.

WOFD-081200 Centralized Resource Monitoring in Real Time Availability This feature was introduced in M2000 V200R009.

Summary The M2000 monitors the current network resource usage in real time through key counters, such as CPU usage, GPRS user-plane traffic traffic volume, and link status. The monitoring results are displayed in charts. By using this function, users can learn about the device performance status and system running status in real time.

Benefits 

The M2000 supports various types of monitoring, which applies to various O&M scenarios.



This feature allows users to learn about the device status in real time, and identify and rectify faults in time, reducing the impacts of faults.

Description Currently, Currently, the M2000 supports the real-time resource monitoring for GSM, UMTS, eRAN, SingleRAN, and eRelay NEs. Table NEs. Table 2-5, Table 2-5, Table 2-6, Table 2-7, Table 2-8, and 2-8, and Table Table 2-9 describe the monitored items supported by the M2000.

Issue 02 (2013-07-20)


127



Table 2-5 Monitored items for GSM NEs

Monitored Item

Description

CPU Usage Monitoring

Obtains the CPU usage of a specified board in real time. This helps users monitor the device load in real time in special scenarios such as in heavy traffic hours.

Subsystem CPU Usage Monitoring

Obtains the subsystem CPU usage of a specified board in real time. This facilitates real-time monitoring of subsystem CPU load in heavy traffic hours.

GPRS Flux Monitoring

Obtains the traffic in the GPRS user planes on the DSPs of a build-in PCU in real time. This helps users learn about the load of data services. The monitored traffic in user planes includes the uplink and downlink traffic in the GPRS user planes over the Um and Gb interfaces.

Abis HDLC Usage Monitoring

Obtains the average TX and RX rates of the HDLC channel of the BTS configured with the Abis optimization transmission in real time. This helps users learn about the resource usage.

DSP/CS UP Resource Monitoring

Obtains the number of services provided by DSPs/CS UPs in real time. This helps users learn about information about the voice services provided by DSPs/CS UPs. The types of the monitored voice services are as follows:

Link Performance Monitoring

PPP Link Monitoring MLPPP Group Monitoring



Full rate (FR)



Half rate (HR)



Enhanced full rate (EFR)



Full rate adaptive multi rate (FAMR)



Half rate adaptive multi rate (HAMR)

Monitors the RX traffic, TX traffic, and number of received error frames of a specified link. It displays the traffic of the current link in a table and a chart.

FE/GE Monitoring IP Path Monitoring SCTP Link Monitoring

Monitors the RX traffic and TX traffic of a specified link. It displays the traffic of the current link in a table and a chart.

Logic Port Monitoring Logic Port Bandwidth Monitoring

Issue 02 (2013-07-20)

Monitors the bandwidth of a specified port and displays the bandwidth of the current port in a table and a chart.


128



Table 2-6 Monitored items for eRAN NEs

Monitored Item

Description

Cell Performance Monitoring

Monitors satisfaction of services, general throughput, service statistics, subscriber statistics, RB usage, ICIC (cell), MIMO, RSSI statistics, interference detection, TDD interference detection, multi-user BF (cell), scheduled subscriber statistics, HARQ statistics, DCI statistics, DRB statistics, and eICIC statistic for CRE area monitoring.

Subscriber Performance Monitoring

Monitors UL CoMP, TCP service quality, voice quality, DL RSRP/RSRQ, BER, power headroom, channel quality, scheduling, RLC data stream, throughput, AQM, UL power control, DL power control, ICIC (subscriber), MCS count, RRN traffic, multi-user BF (subscriber), SFN detection, and subscriber-level eICIC monitoring, and eICIC user monitoring.

Table 2-7 Monitored items for SingleRAN NEs

Monitored Item

Description

GU Power Share Monitoring

Monitors the power of GSM and UMTS carriers on MBTSs and enables users to learn about power sharing.

IP Link Monitoring

Monitors traffic and received error frames of ports in real time. This helps users evaluate networks and reconfigure network parameters in time. The monitored objects are as follows: 

TX and RX traffic, number of received frames, and number of received error frames of the PPP link



TX and RX traffic, number of received frames, and number of received error frames of the MLPPP group



TX and RX traffic, number of received frames, and number of received error frames of the FE/GE port

Table 2-8 Monitored items for base station device and transport

Monitored Item

Description

Device Monitoring

Monitors, CPRI BER, CPU usage, RRU/RFU/BRU output power, RRU/RFU temperature, clock quality, and IP clock data.

Transport Performance Monitoring

Monitors local pass-by traffic, IP performance, transport port performance, transport link performance, UDP packet injection testing, NodeB IP link, LTE IP link, IP path performance, SCTP performance, resource group, PPPoE, GBTS PPP link, GBTS MLPPP group, GBTS FE/GE, and GBTS tunnel.

Issue 02 (2013-07-20)


129



Table 2-9 Monitored items for eRelay

Monitored Item

Description

Cell Performance Monitoring

Monitors RB usage, MIMO, RSSI statistics, interference detection, scheduled subscriber statistics, HARQ statistics, DCI statistics, and DRB statistics.

Subscriber Performance Monitoring

Monitors DL RSRP/RSRQ, BER, Power Headroom, channel quality, scheduling, RLC data stream, throughput, AQM, UL power control, DL power control, MCS count, and RRN traffic.

The M2000 implements various types of monitoring functions by performing various tasks. Users can control the monitoring process by creating, starting, stopping, or deleting tasks. The M2000 supports a maximum of 30 concurrent monitoring tasks. After a user selects a monitored item and set the required task parameters, the M2000 sends a command to NEs to start a monitoring task. NEs report the monitoring results to the M2000 in real time. Then, the M2000 parses the monitoring results and saves the parsing results in the database. The M2000 displays monitoring results in a list or a chart. In the list, users can view the details of each monitoring result. In the line chart, users can view the history status and trend of counters. Users can view the monitoring results through playback. After this playback function is enabled, the M2000 dynamically displays the monitoring results in the receiving sequence. During the playback, users can perform the stop, pause, or forward operation. With this function, users can view and analyze messages without manually dragging.


LTE monitoring items eICIC statistic for CRE area monitoring and eICIC user monitoring have been added.


Unified device and transport monitored items for GSM, UMTS, and LTE



Monitored items for LTE have been enhanced. ICIC monitoring counters, RB-level UL RSSI monitoring, cell- and subscriber-level UL CoMP monitoring, real-time PDCP data transmission statistics reporting monitoring, MLB monitoring, voice quality monitoring, and multi-cell combination monitoring are supported.


Monitoring the bit error rate of the CPRI port for eNodeBs


Monitoring CPU usage, RSSI interference detection, and DL RSRP/RSRQ for eNodeBs



Monitoring CPRI BER for GBSS



Monitoring SingleRAN items

The following function is added to M2000 V200R011C00:

Issue 02 (2013-07-20)


130



Centrally monitoring resources for eNodeBs and NodeBV2 in real time.

Dependency This feature applies to the BSC6900 GSM, BSC6900 GU, and GBTS in GBSS9.0 and later versions.

WOFD-240100 Network Health Checking Availability This feature was introduced in M2000 V200R006.

Summary This feature allows users to inspect NE devices, analyze alarms, and check the M2000 system status. It also allows users to export check reports.

Benefits 



This feature can implement the total check of the devices on the live network. Therefore, users need to view only the check report to identify hidden device problems and take preventive measures to ensure the normal operation of devices and improve the quality of service. Users can set a scheduled task to check the network in non-busy hours to reduce the impacts on network services.

Description Network health check is performed on the basis of tasks. Users can customize health check tasks according to the actual requirements. Users can perform operations such as creating, copying, manually performing a task, enabling the automatic task execution, and viewing the task status. After a health check task is complete, a check report in HTML or DOC format is generated. To meet the requirements in different scenarios, the system provides the following preventive maintenance and check items: 

NE device preventative maintenance The items required for device preventative maintenance vary according to scenarios. The M2000 allows users to manage device preventive maintenance templates based on scenarios. By default, the M2000 provides common device preventive maintenance templates during scenarios such as maintenance, upgrade check, and device preventive maintenance. NEs of different types support different default device preventive maintenance templates. Users can also customize device preventive maintenance templates and select check items based on scenarios. Before the M2000 conducts device preventive maintenance, it checks the NE CPU usage: −

If the CPU usage exceeds the threshold, the M2000 does not conduct preventive maintenance and periodically checks the CPU usage.

−

If the CPU usage is lower than the threshold, the M2000 starts preventive maintenance.

This function prevents a CPU usage decrease during device preventive maintenance. Issue 02 (2013-07-20)


131



Health check reports are in HTML or DOC format. The M2000 supports the comparison of device preventive maintenance results. The NEs that support this check item are the RNC, NodeB, GBTS, eNodeB, BTS3900, BSC6900 GSM, BSC6900 GU, BSC6900 UMTS, BSC6910 GSM, BSC6910 GU, BSC6910 UMTS, MBTS(GU), MBTS(GL), MBTS(UL), USU3900, eRelay, AG, and IP Clock Server. Each type of NE supports different preventive maintenance items: −

Preventive maintenance items of the RNC and BSC6900 UMTS Board status, cell status, status of the interfaces at the physical layer, signaling point status, link set status, link status, route status, BAM server, clock, interface configuration data, routing configuration, parameters for loading RNC subracks, host program, patch, and the loading mode of the DSP.

−

Preventive maintenance items of the NodeB Current NodeB type, NodeB version, quality of the NodeB clock, NodeB board configuration, cell status, NEMU temperature, status of the power supply module, and IPRAN status.

−

Check items of the BSC6900 GSM Board status, interface status, link status, BAM status, BTS board version, whether license resources exceed the limit, GBTS operating status, cell broadcast status, GPRS cell status, subrack cable status, and the Ethernet adapter status of a board.

−

Check items of the eNodeB eNodeB type, eNodeB version, hardware status, Ethernet port property, cell status, environment status, and data consistency.

−

Check items of the GBTSTS patch, channel status, OML link, board status, VSWR, and software version.

−

MBTS(GU)/MBTS(GL)/MBTS(UL) check items MBTS health check items include MBTS type, software version, hardware status, interface status, clock status, cell status, environment status, and configuration data. An MBTS check report is generated on the basis of the check items of each single-mode NE and the common check items of the NEs. MBTS(GL) check items involve GBTS check items, LTE check items, and their common check items. MBTS(GU) check items involve GBTS check items, NodeB check items, and their common check items. MBTS(UL) check items involve LTE check items, NodeB check items, and their common check items.

−

BSC6910 GSM/GU check items Interface status, base station operating status, software version, license, board status, OMU status, and physical transmission link

−

BSC6910 UMTS Interface status, software version, license, board status, OMU status, and physical transmission link

−

AG check items AG check items include subrack and board information, versions of active and standby software, hardware management status, device running status, resource status, interface link status, online AP link status, and fault information.

−

IP Clock Server check items IP Clock Server check items include versions of active and standby software, consistency check of configuration data, device running status, system working mode, board routing, port status, and fault information.

−

Issue 02 (2013-07-20)

M2000 health check


132



The check items include versions of the operating system and of the patches, version of the database, M2000 version, NTP server status, system time zone, disk status and partition usage, available memory, cluster status, and status of the M2000 services. 

Alarm check Both the M2000 and NEs support the alarm check function. Alarm check reports are in HTML format. Supported check items include the alarm trend, alarm comparison, TopN common alarms, TopN alarm features, alarm maintenance, and fault information collection. Base station/ell fault statistics apply only to the RNC, BSC6900GU, BSC6900 GSM, BSC6900 UMTS, BSC6910GU, BSC6910 GSM, and BSC6910 UMTS.

Enhancement The network health check for the BTS3900, BSC6910 GSM, BSC6910 GU, BSC6910 UMTS, USU3900, and eRelay is added to M2000 V200R013C00. The network health check of MBTS(UL) is added to M2000 V200R011C00. The network health check of GBTS, MBTS(GU), MBTS(GL), AG, and IP Clock Server is added to M2000 V200R010. The following functions are added to M2000 V200R009: 

Checking NE CPU usage before starting device preventive maintenance



Device preventive maintenance management based on scenarios

The network health check for the eNodeB and the MBSC is added to M2000 V200R008.

Dependency This feature applies to RAN6.1 and GBSS7.0 and later versions.

WOFD-240700 Network Health Check – CN Availability This feature was introduced in M2000 V200R009.

Summary This feature can be used to check the running status of NEs and the network. By viewing health check reports, users can detect potential faults in devices and take preventive measures to ensure the normal running of the network.


This feature can implement the total check of the devices on the live network. Therefore, users can detect potential device faults by viewing the check report and take preventive measures to ensure the normal operation of devices and improve the quality of service.



After a fault occurs on the network, maintenance engineers can perform NE health check to quickly identify the causes of the fault.

Issue 02 (2013-07-20)


133



Before and after an NE is upgraded, maintenance engineers need to use the health check function to check the NE status and check whether the result is correct after upgrade. Maintenance engineers can also use this function to check the result of NE patch upgrade and NE preventive maintenance.

Description Most NEs, such as the MSOFTX3000, UMG, SGSN, GGSN, HLR, and CSCF devices, support the network health check. For the details about the NEs that support this function, see the feature list. The health check items include hardware status, NE version, and patch information, interface status, link status, circuit status, route and sub-route status, OMU status, basic configuration data, office data configuration, and alarm information. To facilitate the implementation of the function, the M2000 supports the health check by scenarios. NEs and NE check items are classified into scenarios. The check items vary according to scenarios, such as the upgrade scenario and the capacity expansion scenario. Network health check is performed through tasks. Users can customize health check tasks according to the actual requirements. Users can perform operations such as creating, copying, manually performing a task, enabling the automatic task execution, and viewing the task status. After a health check task is complete, a check report in HTML or DOC format is generated. Network health check is performed through tasks. When configuring a task, users need to only select a proper scenario and NEs to be checked, but do not need to specify check items. This helps to check NEs in specified scenario. For example, when creating a task, users can select a type of NEs or a specified NE, and set the running time of the health check task. The M2000 supports instant tasks, scheduled tasks, and periodic tasks. After a task is completed, users can download task running report that contains the check results for all check items. The M2000 supports the function of comparing reports for users to learn the comparison of check results. This function can be used to compare the check results before and after NE upgrade.

Dependency None

2.11 FARS This function can be used to quickly locate and resolve problems. Normally there is no way to avoid that some user data such as IMSI, MSISDN will be used during the troubleshooting. However, this function provides an anonymous data processing method. Operators are obligated to take considerable measures, in compliance with the laws of the countries concerned and the user privacy policies of your company, to ensure that the personal data of users is fully protected.

Issue 02 (2013-07-20)


134



WOFD-081400 Tracing Task Management and Message Browse Availability This feature was introduced in M2000 V200R008.

Summary This feature provides tracing task management and task browsing functions. The task management function allows users to create, start, and stop tracing tasks. The task browsing function allows users to browse, explain, filter, play back, and store tracing messages. The M2000 provides subscriber information anonymization policy management to encrypt IMSI, IMEI, and MSISDN during signaling tracing. This protects subscriber data from being disclosed.

Benefits This feature provides the following benefits: 

Providing enhanced LMT functions while inheriting existing functions



Helping users detect exceptions in a timely manner



Improving fault locating efficiency



Subscriber information anonymization policy management encrypts IMSI, IMEI, and MSISDN for users, prevents plaintext display, storage, and transmission, and protects subscriber data.

Description This feature supports signaling tracing in task mode and provides task management functions. This feature allows users to control the tracing procedure by viewing information about all tracing tasks and performing operations such as task creation, startup, stopping, and deletion. The information about each tracing task includes the task name, tracing type, creator, status, start time, end time, network element, exception cause, and data source. In addition, signaling tracing management displays data amounts for tasks in real time. The M2000 supports a maximum of 100 concurrent subscriber tracing tasks. These tasks include GBSS, WRAN, G&U CS, GBSS PS call, LTE, IMS, and NGN subscriber tracing tasks, where a maximum of five concurrent GBSS PS call tracing tasks are supported. The M2000 supports a maximum of 12 concurrent non-subscriber tracing tasks for all RATs. The tasks include cell tracing and interface tracing tasks but do not include UMTS detailed cell tracing or LTE/eRelay cell tracing tasks. After a tracing task is started, NEs report traced messages to the M2000. Then, the M2000 analyzes these messages and saves analysis results to the database. The M2000 supports the following functions on the traced messages: 

Message browse The analysis results for a tracing task are displayed in a list. The contents in the list include message SN, report time, tracing type, message type, message direction, and message contents. Users can set message colors according to the message direction and type.



Issue 02 (2013-07-20)

Message explanation


135



Message explanation is to translate a binary message into a protocol frame structure, which is displayed as a tree diagram. Users can view the message explanation. 

Message filtering Users can filter tracing messages by message field, message byte, or information element. Supported fields include message type, message direction, time, and interface type. An information element is a node carrying service messages in the message tree generated during message explanation. An information element is identified by a path.



Message storage and printing Users can save and print all or selected tracing messages. Tracing messages are saved in XLS, XLSX, TXT, HTML, TMF, PDF, or CSV format.



Message export Users can export the data about a selected tracing task to a TMF file. Messages in the TMF file can be imported into the M2000 again.



Message comparison Users can compare messages after the M2000 translates messages into protocol frame structures. Signaling in two messages is highlighted in different colors.



Message summarization The M2000 displays the summary about a tracing task, including tracing type, task name, creator, traced NE, and start time and end time.



Message playback Users can view collected tracing messages using the playback function. After the playback function is enabled, the M2000 displays tracing messages according to the sequence they are received. During the playback, users can stop and pause messages, and adjust the playback rate. With the playback function, users can view and analyze messages without manually dragging messages.

Subscriber information anonymization policy management provides the following functions: 

Enabling or disabling the anonymization policy: Users can enable or disable the subscriber information anonymization policy on the entire network. After this policy is enabled, the M2000 and NEs automatically encrypt the IMSI, IMEI, and MSISDN used in creating tracing tasks and in messages to prevent subscriber data from being disclosed.



Updating cipher keys: After a new cipher key is delivered and takes effect on the M2000 and NEs, the M2000 and NEs use the new cipher key to encrypt IMSI, IMEI, and MSISDN.



Checking consistency: Users check the status of the cipher keys and anonymization switches on the M2000 and NEs and synchronize the status based on the check results to ensure that the status is consistent between the M2000 and NEs.


Saving traced messages as a TMF file



Subscriber information anonymization policy management


Maximum number of concurrent subscriber tracing tasks reaches to 100

The following functions are added to M2000 V200R009:

Issue 02 (2013-07-20)


136





Message playback



Message filtering based on information elements

Dependency Users can use this feature only after they have purchased the optional tracing features.

WOFD-080500 GBSS Subscriber Tracing Availability This feature was introduced in M2000 V200R008.

Summary GBSS subscriber tracing refers to the process of tracing the standard signaling messages of the calls of a specified UE on the CS domain, for example, a VIP UE on the GSM network in a certain time segment. By collecting and analyzing statistics of the call s ignaling messages, users can locate call faults. A GBSS subscriber tracing task is used to trace the UE messages on a single BSC. The subscriber tracing applies to the following scenarios: 

Rectifying call faults to handle customer complaints



Analyzing drive test data to locate network problems



The user-friendly GUI makes operations more convenient. This helps O&M personnel locate call faults effectively and helps telecom operators reduce OPEX.



Real-time subscriber tracing allows O&M personnel to know the call signaling of VIP UEs and drive test UEs in real time, which helps O&M personnel detect and locate faults more effectively.

Benefits

Description The parameters involved in creating a subscriber tracing task are the task name, GBSC, UE number (single option), interface filtering setting (A/Abis/Um), start time and end time. The GBSC refers to the general base station controller of GSM, and it does not represent the specific NE type. The default duration of a CS user tracing task is one day and the maximum duration is seven days. Users can specify the start time and end time. After a subscriber tracing collection task is started, the NEs trace call signaling on the CS domain according to the user setting and report the call signaling messages to the M2000. The M2000 parses the signaling messages and stores the parsing results in the database. In addition to the functions provided in the feature WOFD-081400 Tracing Task Management and Data Browse, the M2000 also provides the function of extracting messages based on information elements. In many scenarios, users need to export the counters or fields generated during a call into a report and submit the report to a third party. To meet the requirements in these scenarios, the M2000 provides message extraction based on information elements. An information element

Issue 02 (2013-07-20)


137



is a node carrying service messages in the message tree that is obtained through message explanation. An information element is identified by a unique path. Message extraction is performed on the basis of tracing tasks. Before extracting messages, users need to specify a tracing task and template. The template specifies the information elements based on which message extraction is performed. After starting message extraction, the M2000 extracts the values of all information elements specified in the template from each message and displays the extraction results in the message list. The message list displays all message fields, and a column is added for each information element to display the value of the information element recorded in each message. Message extraction results can be exported to XLS, XLSX, HTML, TMF, PDF, TXT, or CSV files.


Message extraction based on information elements

Dependency This feature and the feature WOFD-190700 Subscriber Tracing of PS Call – GBSS together implement MS tracing in both CS domain and PS domain. A GBSS subscriber tracing task can trace UE messages under multiple GBSC.

WOFD-080600 GBSS Cell Tracing Availability This feature was introduced in M2000 V200R008.

Summary The GBSS cell tracing refers to sampling the subscribers in conversation in a specified cell and tracing the standard signaling of the sampling subscribers. By analyzing the tracing data, users can evaluate the performance of the live network or identify network faults. The cell tracing feature applies to the following scenarios: 



Network status sampling analysis, which is used to optimize the network and to detect and rectify network faults. Drive tests during site deployment, which is used to locate network problems.

Benefits The user-friendly GUI makes operations more convenient. This facilitates network fault detection and rectification and network coverage optimization, and helps telecom operators reduce OPEX.

Description The M2000 provides the function of tracing the sample calls of a specified cell. The upper limit of sample calls is configurable and its maximum is 16. Assume the upper limit is set to N and the number of currently traced calls is N. In such a case, the M2000 does not trace the

Issue 02 (2013-07-20)


138



subsequent calls. When a call that is being traced is terminated and the number of concurrently traced calls is less than N, the M2000 automatically traces another new call. The parameters involved in creating a cell tracing task are the task name, GBSC (single option), cell ID (single option), interface filtering setting (A/Abis/Um), number of call samples, and start time and end time. The GBSC refers to the general base station controller of GSM, and it does not represent the specific NE type. The maximum duration of a cell tracing task is 1 hour. Users can specify the start time and end time. After a data tracing collection task is started, the NEs report the call signaling messages of the specified cell to the M2000 through a file. The M2000 parses the signaling messages and stores the parsing results in the database. In addition to the functions provided in the feature WOFD-081400 Tracing Task Management and Data Browse, the M2000 also provides the function of extracting messages based on information elements. In many scenarios, users need to export the counters or fields generated during a call into a report and submit the report to a third party. To meet the requirements in these scenarios, the M2000 provides message extraction based on information elements. An information element is a node carrying service messages in the message tree that is obtained through message explanation. An information element is identified by a unique path. Message extraction is performed on the basis of tracing tasks. Before extracting messages, users need to specify a tracing task and template. The template specifies the information elements based on which message extraction is performed. After starting message extraction, the M2000 extracts the values of all information elements specified in the template from each message and displays the extraction results in the message list. The message list displays all message fields, and a column is added for each information element to display the value of the information element recorded in each message. Message extraction results can be exported to XLS, XLSX, HTML, TMF, PDF, TXT, or CSV files.



Dependency None

WOFD-081500 GBSS Interface Message Tracing Availability This feature was introduced in M2000 V200R009.

Summary By tracing, collecting, and listing standard signaling messages on the GBSS interfaces, this feature provides data support for routine maintenance, commissioning, and fault location. GBSS interface message tracing includes: 

A interface tracing



Um and Abis interface tracing in the CS domain

Issue 02 (2013-07-20)


139





Um and Abis interface tracing in the PS domain



PTP, SIG, and NS message tracing over the Gb interface

Benefits The task mode used in this feature facilitates interface tracing, data collection, and task management. User-friendly GUIs and convenient operations enable rapid detection of call problems and equipment interconnection problems.

Description The maximum duration of an interface tracing task is 1 hour. Users can specify the start time and end time. After a tracing task is started, the NE traces the messages on a specified interface and reports them to the M2000. The M2000 parses these messages and saves the results in the database. In addition to the functions provided in the feature WOFD-081400 Tracing Task Management and Data Browse, the M2000 also provides the function of extracting messages based on information elements. In many scenarios, users need to export the counters or fields generated during a call into a report and submit the report to a third party. To meet the requirements in these scenarios, the M2000 provides message extraction based on information elements. An information element is a node carrying service messages in the message tree that is obtained through message explanation. An information element is identified by a unique path. Message extraction is performed on the basis of tracing tasks. Before extracting messages, users need to specify a tracing task and template. The template specifies the information elements based on which message extraction is performed. After starting message extraction, the M2000 extracts the values of all information elements specified in the template from each message and displays the extraction results in the message list. The message list displays all message fields, and a column is added for each information element to display the value of the information element recorded in each message. Message extraction results can be exported to XLS, XLSX, HTML, TMF, PDF, TXT, or CSV files.


NS message tracing over the Gb interface



Dependency None

WOFD-080700 WRAN Subscriber Tracing Availability This feature was introduced in M2000 V200R008.

Issue 02 (2013-07-20)


140



Summary The WRAN subscriber tracing can trace the signaling messages generated on the RNC side during the call of a single UE. When creating a subscriber tracing, users can start connection performance monitoring to observe the measurement data during calls. A WRAN subscriber tracing task is used to trace the UE messages on a single RNC. The subscriber tracing applies to the following scenarios: 

Rectifying call faults to handle customer complaints



Analyzing drive test data to locate network problems

Benefits The user-friendly GUI makes operations more convenient. This helps O&M personnel locate call faults effectively and helps telecom operators reduce OPEX. Real-time subscriber tracing allows O&M personnel to know the call signaling of VIP UEs and drive test UEs in real time, which helps O&M personnel detect and locate faults more effectively.

Description The WRAN subscriber tracing can trace the signaling messages of a single UE. The interfaces that can be traced are Iu, Iur, Iub, and Uu. Users can specify the message types to be traced according to the interface type. The parameters involved in creating a subscriber tracing task are the task name, RNC, RNCID, UE number (single option), interface filtering setting (Iub/Iur/Iu/Uu), start time and end time. The duration of a subscriber tracing task is one day by default, and the maximum duration is seven days. Users can specify the start time and end time. After a data tracing task is started, the NEs trace call signaling according to the user setting, monitor the signaling, and report the call signaling messages to the M2000. The M2000 parses the signaling messages and stores the parsing results in the database. In addition to the functions provided in the feature WOFD-081400 Tracing Task Management and Data Browse, the M2000 also provides the function of extracting messages based on information elements. In many scenarios, users need to export the counters or fields generated during a call into a report and submit the report to a third party. To meet the requirements in these scenarios, the M2000 provides message extraction based on information elements. An information element is a node carrying service messages in the message tree that is obtained through message explanation. An information element is identified by a unique path. Message extraction is performed on the basis of tracing tasks. Before extracting messages, users need to specify a tracing task and template. The template specifies the information elements based on which message extraction is performed. After starting message extraction, the M2000 extracts the values of all information elements specified in the template from each message and displays the extraction results in the message list. The message list displays all message fields, and a column is added for each information element to display the value of the information element recorded in each message. Message extraction results can be exported to XLS, XLSX, HTML, TMF, PDF, TXT, or CSV files.

Enhancement The following function is added to M2000 V200R010:

Issue 02 (2013-07-20)


141





WRAN subscriber tracing of BSC6900 GU and BSC6900 UMTS

Dependency A WRAN subscriber tracing task is used to trace the UE messages on a single RNC.

WOFD-080800 WRAN Integrative Message Tracing Availability This feature was introduced in M2000 V200R008.

Summary WRAN integrated tracing is classified into integrated subscriber tracing (detail subscriber tracing) and integrated cell tracing (detail cell tracing). Integrated subscriber tracing is used to collect the standard signaling messages and Huawei-defined signaling messages of the calls of a UE. The signaling messages on both the RNC side and the NodeB side are collected. Integrated cell tracing is used to collect the standard signaling messages and Huawei-defined signaling messages of multiple sample calls in a cell. The signaling messages on both the RNC side and the NodeB side are collected.

Benefits This feature provides telecom operators with signaling message collection interfaces, which facilitate network fault localization by providing data support.

Description Integrated subscriber tracing is used to trace the signaling messages on the RNC and NodeB sides during a call. Both standard and Huawei-defined signaling messages are traced. Integrated cell tracing is used to collect sample calls in a specified cell and trace the signaling messages of the sample calls on the RNC and NodeB sides. Standard signaling messages, user plane signaling messages, and control plane signaling messages are traced. The parameters involved in creating an integrated subscriber tracing are the task name, RNC, RNCID, UE number (single option), interface filtering setting (Iub/Iur/Iu/Uu), start time and end time, and NodeB message type filtering setting. The parameters involved in creating an integrated cell tracing task are the task name, RNC, RNCID, cell ID, number of sample calls, event type filtering setting, RAB parameter (service type/RAB submission sequence/RAB maximum uplink and downlink rates/RAB uplink and downlink guaranteed rate), RRC parameter (setup cause/RRC localization type/NBAP sharing/UE quality), IMEI TAC, start time and end time, and NodeB message type filtering. The default and maximum duration of an integrative message tracing and collecting task is 8 hours. Users can specify the start time and end time. After a tracing task is started, NEs trace signaling messages and monitor the performance based on the settings of UEs and report the

Issue 02 (2013-07-20)


142



messages to the M2000. The M2000 saves the messages on the server as files. Users can export the data in the files and use the tracing review tool to view the data. Therefore, integrative message tracing does not support the data browse function in the feature WOFD-081400 Tracing Task Management and Data Browse.


The maximum duration of an integrated message tracing and collecting task changes from 1 hour to 8 hours.


WRAN integrative message tracing of BSC6900 GU and BSC6900 UMTS

Dependency A WRAN integrative message tracing task is used to trace the messages on a single RNC and NodeBs under the RNC.

WOFD-080900 WRAN Cell Tracing Availability This feature was introduced in M2000 V200R008.

Summary WRAN cell tracing refers to the process of sampling tracing of the in-traffic UEs in a specified cell and tracing the standard signaling messages on the interfaces including Iur, Iub, Iu and UU reported by an RNC during a sample call. By collecting statistics and analyzing the sampling data, users can evaluate the performance and faults of the live network. The cell tracing feature applies to the following scenarios: 



Network status sampling analysis, which is used to optimize the network and to detect and rectify network faults. Drive tests during site deployment, which is used to locate network problems.

Benefits The user-friendly GUI makes operations more convenient. This facilitates network fault detection and rectification and network coverage optimization, and helps telecom operators reduce OPEX.

Description The M2000 provides the function of tracing the sample calls of a specified cell. The upper limit of the number of sample calls is configurable and its maximum is 50. Assume the upper limit is set to N and the number of currently traced calls is N. In such a case, the M2000 does not trace the subsequent calls. When a call that is being traced is terminated and the number of concurrently traced calls is less than N, the M2000 automatically traces another new call.

Issue 02 (2013-07-20)


143



The parameters involved in creating a cell tracing task are the task name, RNC (single option), RNCID, cell ID (multiple options), number of sample calls, event type filtering setting, RAB parameter (service type/RAB submission sequence/RAB maximum uplink and downlink rates/RAB uplink and downlink guaranteed rate), RRC parameter (setup cause/RRC localization type/NBAP sharing/UE quality), IMEI TAC, and start time and end time. The maximum duration of a cell tracing task is 1 hour. Users can specify the start time and end time. After a data tracing task is started, the NEs sample the calls in a cell based on the settings of users, trace the standard signaling messages of the sample calls, and report the call signaling messages to the M2000 as a file. The M2000 parses the signaling messages and stores the parsing results in the database. In addition to the functions provided in the feature WOFD-081400 Tracing Task Management and Data Browse, the M2000 also provides the function of extracting messages based on information elements. In many scenarios, users need to export the counters or fields generated during a call into a report and submit the report to a third party. To meet the requirements in these scenarios, the M2000 provides message extraction based on information elements. An information element is a node carrying service messages in the message tree that is obtained through message explanation. An information element is identified by a unique path. Message extraction is performed on the basis of tracing tasks. Before extracting messages, users need to specify a tracing task and template. The template specifies the information elements based on which message extraction is performed. After starting message extraction, the M2000 extracts the values of all information elements specified in the template from each message and displays the extraction results in the message list. The message list displays all message fields, and a column is added for each information element to display the value of the information element recorded in each message. Message extraction results can be exported to XLS, XLSX, HTML, TMF, PDF, TXT, or CSV files.




WRAN cell tracing of BSC6900 GU and BSC6900 UMTS

Dependency A WRAN cell tracing task is used to trace the call messages on a single RNC.

WOFD-081300 Centralized Interface Tracing – LTE FDD/TDD Availability This feature was introduced in M2000 V200R008.

Summary This feature enables the M2000 to trace and display interface and link messages, and provide effective data support for device routine maintenance, commissioning, and fault locating. The LTE provides the following interface tracing tasks:

Issue 02 (2013-07-20)


144





Tracing tasks of standard interface messages: S1 interface tracing, X2 interface tracing, Uu interface tracing, IOS tracing, and standard CDT tracing



Tracing tasks of transport network layer protocol messages: SCTP tracing, PPP tracing, LACP tracing, 802.1X tracing, OAM3AH tracing, GTPU tracing, MP tracing, IKE tracing, CFM, CMPV2 tracing, and IP protocol tracing.



By using this feature, the M2000 collects tracing data on interfaces such as the S1 and X2 interfaces in tasks. This helps users trace data and monitor task status.



This feature provides a user-friendly GUI, which allows users to quickly locate call faults and solve problems related to device interconnection.

Benefits

Description The maximum duration of an interface tracing task is 12 hours. Users can specify the start time and end time. After a tracing task is started, NEs trace the messages of a specified object or over a specified interface and report the messages to the M2000. The M2000 parses these messages and saves the parsing results in the database. In addition to the functions provided in the feature WOFD-081400 Tracing Task Management and Data Browse, the M2000 also provides the function of extracting messages based on information elements. In many scenarios, users need to export the counters or fields generated during a call into a report and submit the report to a third party. To meet the requirements in these scenarios, the M2000 provides message extraction based on information elements. An information element is a node carrying service messages in the message tree that is obtained through message explanation. An information element is identified by a unique path. Message extraction is performed on the basis of tracing tasks. Before extracting messages, users need to specify a tracing task and template. The template specifies the information elements based on which message extraction is performed. After starting message extraction, the M2000 extracts the values of all information elements specified in the template from each message and displays the extraction results in the message list. The message list displays all message fields, and a column is added for each information element to display the value of the information element recorded in each message. Message extraction results can be exported to XLS, XLSX, HTML, TMF, PDF, TXT, or CSV files.


IP protocol message tracing at the transport network layer


Tracing of transport network layer protocol messages: PPP tracing, LACP tracing, 802.1X tracing, OAM3AH tracing, GTPU tracing, MP tracing, IKE tracing, CFM, and CMPV2 tracing.



Dependency None

Issue 02 (2013-07-20)


145



WOFD-191200 Centralized Subscriber Tracing – LTE FDD/TDD Availability This feature was introduced in M2000 V200R008.

Summary The subscriber tracing refers to tracing the signaling messages of all the calls of a specified UE (for example, a VIP UE) on the network within a certain period. By collecting and analyzing statistics of the call signaling messages, users can locate call faults. This feature supports subscriber tracing across multiple eNodeBs. After the subscriber tracing is triggered on the core network, the eNodeB where the traced UE resides reports the call message to the M2000. Then, the M2000 collects and displays the subscriber tracing messages of multiple eNodeBs.


The user-friendly GUI makes operations more convenient. This helps O&M personnel locate call faults effectively and helps telecom operators reduce OPEX.



Real-time subscriber tracing allows O&M personnel to learn about the call messages of VIP UEs and drive test UEs in real time. This helps O&M personnel detect and locate faults more effectively and therefore improves user satisfaction.



The M2000 supports UE signaling tracing across multiple NEs. This allows users to trace all the signaling of a call by creating a task.

Description Before creating a subscriber tracing task, users need to start the subscriber tracing, obtain the tracing reference number from the CN, and enter the tracing reference number on the M2000 to create the tracing task. After the tracing task is started, NEs trace the call messages of a specified UE and report the messages to the M2000. The M2000 parses these messages and saves the parsing results in the database. The duration of a subscriber tracing task is one day by default, and the maximum duration is seven days. Users can specify the start time and end time. In addition to the functions provided in the feature WOFD-081400 Tracing Task Management and Data Browse, the M2000 also provides the function of extracting messages based on information elements. In many scenarios, users need to export the counters or fields generated during a call into a report and submit the report to a third party. To meet the requirements in these scenarios, the M2000 provides message extraction based on information elements. An information element is a node carrying service messages in the message tree that is obtained through message explanation. An information element is identified by a unique path. Message extraction is performed on the basis of tracing tasks. Before extracting messages, users need to specify a tracing task and template. The template specifies the information elements based on which message extraction is performed. After starting message extraction, the M2000 extracts the values of all information elements specified in the template from each message and displays the extraction results in the message list. The message list displays all message fields, and a column is added for each information element to display the value of the

Issue 02 (2013-07-20)


146



information element recorded in each message. Message extraction results can be exported to XLS, XLSX, HTML, TMF, PDF, TXT, or CSV files.



Dependency None

WOFD-191600 Centralized Cell Tracing – LTE FDD/TDD Availability This feature was introduced in M2000 V200R010.

Summary Cell tracing is a process of tracing the call signaling of UEs that are live in one or multiple specified cells. The M2000 collects the cell tracing data to provide the data source for users to evaluate live network performance or diagnose network faults. The cell tracing feature applies to the following scenarios: 

Sampling and analyzing network performance to optimize the network or identify and rectify network faults



Performing drive tests during site deployment to locate network problems



Adjusting and verifying cell configuration parameters

Benefits The user-friendly GUI simplifies operations and helps O&M personnel effectively identify and rectify call faults. It also helps telecom operators reduce OPEX.

Description Using the centralized cell tracing feature, users can collect call signaling tracing messages generated in one or multiple cells within a specified period. In addition, users can collect radio measurement data during calls. Signaling tracing messages include standard messages specified by the 3GPP specifications and traced at the application layer over S1, X2, and Uu interfaces. Radio measurement data includes MRs for Uu interfaces. Centralized cell tracing allows users to collect data at three levels specified by 3GPP specifications: minimum, medium, and maximum. Users can collect MRs only at medium and maximum levels. The maximum duration for a tracing task is 365 days. Users can set start time and end time for a task. In addition, users can specify the period for collecting periodic events on the M2000.

Enhancement The following function is added to M2000 V200R012C00:

Issue 02 (2013-07-20)


147



Allowing users to specify the period for collecting periodic events.


A tracing task can run for a maximum of seven consecutive days.


Supporting the data browse function in the feature WOFD-081400 Tracing Task Management and Data Browse.

Dependency None

WOFD-600100 Centralized Interface Tracing – eRelay Availability This feature is introduced in M2000 V200R013.

Summary This feature enables the M2000 to trace and display interface and link messages, and provide effective data support for device routine maintenance, commissioning, and fault locating. The eRelay provides the following signaling tracing tasks: Uu, IOS, RRN, standard CDT, IFTS, user plane, and cell DT tracing tasks


By using this feature, the M2000 collects tracing data in tasks, helping users trace data and monitor task status.



This feature provides a user-friendly GUI, which allows users to quickly locate call faults and solve problems related to device interconnection.

Description The maximum duration of an interface tracing task is 12 hours. Users can specify the start time and end time. After a tracing task is started, NEs trace the messages of a specified object or over a specified interface and report the messages to the M2000. The M2000 parses these messages and saves the parsing results in the database. In addition to the functions provided in the feature WOFD-081400 Tracing Task Management and Data Browse, the M2000 also provides the function of extracting messages based on information elements. In many scenarios, users need to export the counters or fields generated during a call into a report and submit the report to a third party. To meet the requirements in these scenarios, the M2000 provides message extraction based on information elements. An information element is a node carrying service messages in the message tree that is obtained through message explanation. An information element is identified by a unique path.

Issue 02 (2013-07-20)


148



Message extraction is performed on the basis of tracing tasks. Before extracting messages, users need to specify a tracing task and template. The template specifies the information elements based on which message extraction is performed. After starting message extraction, the M2000 extracts the values of all information elements specified in the template from each message and displays the extraction results in the message list. The message list displays all message fields, and a column is added for each information element to display the value of the information element recorded in each message. Message extraction results can be exported to XLS, XLSX, HTML, TMF, PDF, TXT, or CSV files.

Enhancement None

Dependency None

WOFD-600200 Centralized Cell Tracing – eRelay Availability This function is introduced in M2000 V200R013C00.

Summary Cell tracing is a process of tracing the call signaling of UEs that are live in one or multiple specified cells. The M2000 collects the cell tracing data to provide the data source for users to evaluate live network performance or diagnose network faults. The cell tracing feature applies to the following scenarios: 

Sampling and analyzing network performance to optimize the network or identify and rectify network faults



Performing drive tests during site deployment to locate network problems



Adjusting and verifying cell configuration parameters

Benefits The user-friendly GUI simplifies operations and helps O&M personnel effectively identify and rectify call faults. It also helps telecom operators reduce OPEX.

Description Centralized cell tracing allows users to collect call signaling tracing messages and radio MRs generated in one or multiple cells within a specified period. Signaling tracing messages include standard messages specified by 3GPP specifications and traced at the application layer over the Uu interface. Radio measurement data includes MRs over the Uu interface. Centralized cell tracing allows users to collect data at three levels specified by 3GPP specifications: minimum, medium, and maximum. Users can collect MRs only at medium and maximum levels. The maximum duration for a tracing task is 365 days. Users can set start time and end time for a task. In addition, users can specify the period for collecting periodic events on the M2000.

Issue 02 (2013-07-20)


149



Enhancement None

Dependency None

2.12 Base Station Commissioning Management WOFD-280200 NodeB Auto-Deployment – WRAN Availability This feature was introduced in M2000 V200R008.

Summary During network deployment, expansion, or reconstruction, users have to commission NEs and ensure that the NEs can work properly and are connected to the M2000. Automatic NodeB deployment allows users to remotely commission NEs on the M2000 client in the center equipment room. This reduces the frequency and complexity of manual operations and significantly improves O&M efficiency.


The time on NodeB deployment is reduced, while the deployment efficiency is improved.



The NodeB deployment cost is reduced.



The qualifications required for NodeB deployment engineers are lowered.



Users do not need to frequently enter the site.



The possibility of manual errors is reduced.

Description This feature applies to NodeB deployment, expansion, reparenting, reconstruction, and RAT addition scenarios, which reduces the frequency and complexity of manual operations. To implement the automatic deployment and commissioning of NodeBs, the M2000 provides the following automatic NodeB deployment solutions: Solution I: Remote and automatic commissioning

Before automatic NodeB commissioning, the installation, configuration, and commissioning of the M2000 and related RNC must be complete. In addition, the NodeB must be installed, powered on and assigned IP address. The procedure of NodeB commissioning is as follows:

Issue 02 (2013-07-20)


150





The M2000 automatically detects all the NodeBs on the live network and connects to these NodeBs.



The M2000 operators select the NodeBs to be commissioned and commissioning items through the wizard for setting the commissioning task. The items include downloading and activating software, downloading configuration files, and performing health check.



The M2000 automatically triggers the commissioning task according to the settings. The process takes little time and does not require manual operations.



Site operators can validate the services by making calls. If the validation is passed, the site operators inform the M2000 operators that they are ready to leave the site.



The M2000 operators check the NodeB commissioning report generated by the M2000. If the commissioning items, status, and performance of objects are proper, the site operators can leave the site.

Solution II: End-to-end NodeB auto-deployment

The M2000 provides the end-to-end NodeB deployment solution, which reduces the frequency and complexity of manual operations. Before deploying a NodeB, ensure that: 

The target software version and configuration data of the NodeB are uploaded to the M2000.



The transmission between the NodeBs and the M2000 is proper.

Automatic NodeB deployment involves the following procedures, which can be customized based on application scenarios. The steps of assigning NodeB IP addresses and automatic configuration can be performed locally by using the USB flash drive or the LMT. 

Automatic detection Engineers import the NodeB deployment list to the M2000. This list contains the required deployment information such as the NodeB names, target version numbers, ESNs, IP addresses. After O&M personnel select target NodeBs on the M2000 GUI and start deployment, the M2000 automatically checks whether the required data is available. If no exception occurs, the deployment is automatically performed without human intervention. Then, the M2000 assigns IP addresses to the NodeBs using DHCP and connects to the NodeBs.



Automatic configuration The M2000 sends software upgrade commands to the NodeBs. The NodeBs automatically download the software from the M2000. Then, the NodeBs upgrade the software and load the data.



Automatic planning The automatic planning process is as follows: −

Users provide reference data for automatic planning of micro base stations, including available frequencies and scrambling codes for micro base stations, available frequencies for UMTS macro base stations, and public land mobile network (PLMN) of GSM cells.

−

Based on the user-specified reference data, frequency scanning results reported by micro base stations, and radio parameters, the M2000 selects algorithms and plans frequencies, neighbor relationships, scrambling codes, LACs, RACs, and SACs.

−

The M2000 sends the planning results to micro base stations to complete the automatic planning.

Automatic planning applies only to UMTS micro base stations.

Issue 02 (2013-07-20)


151



Installation & deployment quality testing During installation & deployment quality testing check, users must check the availability of RF modules, standing wave, intermodulation, and crossed pairs for base stations.

During the whole NodeB deployment process, engineers can obtain the deployment report at any time. The report records the information such as operation results and unsolved problems.

Enhancement The following modifications have been made in M2000 V200R013: 

Automatic planning operations are used for micro base stations during automatic deployment.



Installation & deployment quality testing has been enhanced.



ACCP, status monitoring, service verification, and IP address verification have been deleted from the automatic deployment process.


Solution II of the remote and automatic commissioning, which is also referred to as end-to-end NodeB deployment, is implemented.


Starting the VSWR test in the process of NodeB status monitoring and fault diagnosis

Dependency The remote NodeB commissioning applies to the RAN13.0 and earlier releases. The end-to-end NodeB deployment solution can be used for deploying NodeBs of the RAN13.0 and later versions.

WOFD-280400 eNodeB Auto-Deployment – LTE FDD/TDD Availability This feature was introduced in M2000 V200R008.

Summary During network deployment, expansion, or reconstruction, users have to commission NEs and ensure that the NEs can work properly and are connected to the M2000. Automatic eNodeB/USU deployment allows users to remotely commission NEs on the M2000 client in the center equipment room. This reduces the frequency and complexity of manual operations and significantly improves O&M efficiency.

Benefits The deployment wizard simplifies the eNodeB deployment and reduces human errors, improving the efficiency of deploying eNodeBs. The M2000 works with NEs to implement automatic eNodeB deployment in batches, reducing manual interventions, improving the capability of network deployment.

Issue 02 (2013-07-20)


152



Description This feature applies to eNodeB/USU deployment, deployment, expansion, reparenting, reconstruction, and RAT RAT addition scenarios. This feature implements end-to-end eNodeB/USU deployment, which reduces the frequency and complexity of manual operations. The following preparations must be made before eNodeB deployment: 

The target software version, commissioning license, and configuration data of the eNodeB/USU are uploaded to the M2000.



Transmission between the eNodeBs/USUs and the M2000 is proper. proper.

Automatic eNodeB/USU deployment involves the following procedures, which can be customized based on application scenarios: 

Automatic detection O&M personnel import an eNodeB/USU deployment list to the M2000. The list contains data required for eNodeB/USU deployment, such as eNodeB/USU eNodeB/USU names, target version number, ESNs, and IP addresses. The M2000 creates eNodeBs/USUs in a topology view, based on the deployment deployment list. After O&M personnel select select target eNodeBs/USUs eNodeBs/USUs on the M2000 GUI and start deployment, the M2000 automatically checks whether the required data is available. If no exception occurs, the M2000 automatically performs eNodeB/USU deployment without human intervention. The M2000 assigns IP addresses to the selected eNodeBs/USUs using DHCP and automatically sets up O&M channels to the eNodeBs/USUs. eNodeBs/USUs.



Automatic configuration The M2000 instructs the eNodeBs/USUs to start software upgrade. Then, the eNodeBs/USUs automatically download software and configuration data from the M2000, and perform software upgrade and data loading.



Automatic planning The automatic planning process is as follows: −

Network planning engineers engineers set receiver receiver scanning parameters parameters for micro base stations stations in advance on the M2000.

−

After being powered on, micro base stations search for neighboring cells based on the preset parameters parameters and report the neighboring neighboring cell information to the M2000. M2000.

−

The M2000 determines the areas of micro base stations based on the area locating information.

−

The M2000 generates cell radio parameters (such as frequencies, PCIs, TACs, TACs, RootSequenceIdx, RootSequenceIdx, and neighboring cell list) using automatic planning algorithms and sends the parameter data to micro base stations.

Automatic planning applies only to LTE micro base stations. 

Delivery of commissioning licenses During initial eNodeB/USU deployment, the M2000 cannot allocate commercial licenses to the eNodeBs/USUs because network planning is uncertain. After the eNodeBs/USUs perform software software upgrade and data loading, loading, the M2000 delivers delivers commissioning licenses to the eNodeBs/USUs. This ensures that the eNodeBs/USUs provide services properly before commercial commercial licenses are available. available.




Issue 02 (2013-07-20)


153



During the whole eNodeB deployment process, engineers can obtain the deployment report at any time. The report records the information such as operation results and unsolved problems.


Automatic planning operations are used for micro base stations during automatic deployment.






RET antenna commissioning, base station status monitoring, and IP resource pool have been deleted from the automatic deployment deployment process.


Automatic USU deployment


eNodeB status monitoring


Supporting the O&M IP pool function: After users set the network segment of the O&M IP pool, the M2000 automatically assigns O&M IP addresses to eNodeBs.



Automatically commissioning license distribution and RET commissioning.

Dependency None

WOFD-280700 BTS Auto-Deployment – GBSS Availability This feature was introduced in M2000 V200R010.

Summary During network deployment, expansion, or reconstruction (including reconstructing a GBTS to an eGBTS), users have to commission NEs and ensure that the NEs can work properly and are connected to the M2000. Automatic GBTS/eGBTS GBTS/eGBTS deployment allows users to remotely commission NEs on the M2000 client in the center equipment room. This reduces the frequency and complexity of manual operations and significantly improves O&M efficiency. efficiency.


The time on GBTS deployment is reduced, while the deployment efficiency efficiency is improved.



The GBTS deployment cost is reduced.



The qualifications required for GBTS deployment engineers are lowered.



Users do not need to frequently enter the site.



The possibility of manual errors is reduced.

Issue 02 (2013-07-20)


154



Description Automatic deployment applies to base station creation, expansion, reparenting, reconstruction, and RAT RAT addition scenarios. The GBTS/eGBTS automatic deployment solution provides an end-to-end base station deployment process, which reduces the frequency and complexity of manual operations. Before using the automatic GBTS/eGBTS deployment feature, engineers need to ensure that: 

The target GBTS version is uploaded to the GBSC, and the target eGBTS version is uploaded to the M2000.



Transmission between the GBTSs/eGBTSs and the M2000 is proper. proper.

Automatic GBTS/eGBTS deployment involves the following procedures: 

Automatic detection O&M personnel import a GBTS deployment list into the M2000. This list contains data required for GBTS/eGBTS deployment, such as GBTS/eGBTS names, target software version, ESNs, and IP addresses. After After O&M personnel select target GBTSs/eGBTSs on the M2000 GUI and start deployment, the M2000 automatically checks whether the required data is available. If GBSCs work as the DHCP servers, GBTS/eGBTS IP addresses are assigned by the GBSCs, and the M2000 checks whether the O&M channel of the eGBTSs and the O&M channels between the GBTSs and GBSCs are working properly. properly. If the M2000 works as the DHCP server server,, the M2000 assigns GBTS/eGBTS GBTS/eGBTS IP addresses using DHCP. DHCP. Then, the GBTSs automatically set up O&M channels with the GBSCs or eGBTSs. Before the deployment, users can select whether to enable manual intervention, such as manually checking whether the transmission is normal. If manual intervention is not selected, the deployment is performed automatically, automatically, and no manual intervention is required.



Automatic configuration The M2000 instructs the GBSC to start the GBTS software upgrade. The GBTS downloads the software of the required version from the GBSC and upgrades the software. The procedure of loading the GBTS configuration data is not controlled by the M2000. Instead, the reset GBTS obtains the configuration data directly from the GBSC and loads the data. The M2000 instructs eGBTSs to start software upgrade. Then, the eGBTSs automatically download the software and configuration data from the M2000, and upgrade software and load data.




In the preceding procedures, IP address assignment and automatic configuration can be locally performed through USB flash drives or LMTs. After the GBTS deployment is complete, the M2000 generates a deployment report. The report records the information such as operation results and unsolved problems.


Issue 02 (2013-07-20)

eGBTS automatic deployment is supported.


155








Service verification, base station status monitoring, and fault diagnosis have been deleted from the automatic deployment process.


The M2000 assigns IP addresses to GBTSs using DHCP.

Dependency This feature applies to 3900 series GBTSs/eGBTs excluding BTS3900E and BTS3900B.

2.13 SingleRAN Management WOFD-071700 MBTS Management – SingleRAN Availability This feature was introduced in M2000 V200R009.

Summary As the solution to the base stations in the future mobile network, multi-mode base stations (MBTSs) developed by Huawei can work in various RATs. The M2000 provides various MBTS management functions to satisfy the requirements for centralized operation and maintenance. MBTS management inherits the management functions of single-mode base stations and existing O&M methods. It also provides centralized management functions for MBTS common resources, simplifying common resource management. Currently, the M2000 provides a RAT priority management view. The M2000 manages an MBTS as a whole. Inventory and alarm information about MBTS common resources is displayed on the side of the primary RAT. The M2000 provides MBTS topology, alarm, power-saving, and inventory management, and MBTS upgrade functions to meet requirements for maintaining the MBTS as a whole.

Benefits Users can manage the MBTS as a whole by performing topology management, alarm management, and software upgrade. In this way, the M2000 centrally manages MBTSs, improving efficiency and reducing OPEX.

Description Currently, MBTSs refer to dual-mode or tri-mode base stations. Dual-mode base stations are MBTSs that support any two of GSM, LTE, and UMTS modes, for example, MBTS(GU), MBTS(GL), and MBTS(UL). Tri-mode base stations are MBTSs that support the GSM, UMTS, and LTE modes, which is MBTS(GUL). This feature takes the MTBS(GU) as an example to describe the MBTS management feature. Unless otherwise specified, the MBTS(GL), the MBTS(UL) and MBTS(GUL) support the same functions as the MBTS(GU).

Issue 02 (2013-07-20)


156



When managing the MBTSs in priority-based mode, the M2000 provides the following MBTS management functions: 

MBTS configuration The M2000 allows users to plan MBTS configuration. Users can plan MBTS deployment data using the unified site deployment module of the CME. The parameter check function of the CME ensures consistency of configuration parameters among MBTS common resources. For details about how to configure MBTS data, see the features related to SingleRAN in the sections about the CME in this document.



MBTS deployment This function supports the individual deployment of each side of an MBTS and deployment of the entire MBTS. During automatic deployment, the M2000 automatically assigns MBTS IP addresses, upgrades the MBTS software, delivers MBTS configuration data, and verifies services. This ensures quick and reliable MBTS deployment while reducing deployment costs. For details about MBTS deployment, see the feature WOFD-110500 MBTS Auto-Deployment – SingleRAN.



MBTS topology management The M2000 provides a dedicated topology management window for MBTS maintenance, which: −

Displays MBTSs on the entire network.

−

Provides shortcut menus for maintaining an MBTS, such as viewing MBTS inventory and alarm information, and its device panel.

−

Allows users to quickly view cell status under MBTSs and perform shortcut operations on the cells, such as activating and deactivating the cells, and change MBTS names and deployment IDs in batches.

The M2000 checks multimode relationships and automatically binds MBTSs. It also allows users to manually bind MBTSs based on planned data. 

MBTS alarm management The M2000 centrally queries alarms and collects statistics about the MBTS, which facilitates alarm management by the MBTS as a whole. MBTS common resources, such as power modules and fans, are shared by each side of an MBTS. By default, if faults occur on these common components, alarms are simultaneously reported from each side. To avoid redundant alarm reporting, the M2000 displays common alarms only on the side of the highest RAT priority. In addition, the M2000 centrally queries alarms and collects alarm statistics based on MBTSs. For the northbound alarm interface, the M2000 retains the existing mode for reporting alarms from each side of an MBTS. In addition, it adds a function of masking common alarms. As a result, a third-party system does not need to process redundant common alarms.



MBTS software upgrade The M2000 supports individual upgrades and rollbacks of each side of an MBTS. It also supports upgrades and rollbacks of the entire MBTS. Upgrades and rollbacks of the entire MBTS efficiently reduce MBTS service interruption duration.



MBTS power-saving management This function allows users to query MBTS power consumption. Users can learn about the power consumption and traffic volume of all base stations in an MBTS on a per hour basis. In addition, network power-saving effects are compared in charts, so that users can adjust power-saving policies based on the power consumption.



Issue 02 (2013-07-20)

MBTS inventory management


157



Inventory information about MBTS common resources is reported repeatedly. To avoid redundant reporting, the M2000 integrates inventory data by MBTS. In this scenario, users maintain and manage inventory data of each MBTS. In addition, the M2000 allows users to synchronize, query, import, and export MBTS inventory data. For the northbound inventory interface, the M2000 exports inventory data by the entire MBTS. As a result, a third-party system does no need to process redundant inventory data. 

Export of the MBTS list The M2000 provides MBTS configuration reports for users to quickly query each side of an MBTS and associations between the sides. The reports contain MBTS names, base station Full Distinguished Names (FDNs), MBTS capability, and local and peer base station names, types, FDNs, and capability. Users can export the configuration reports as XLS, XLSX, CSV, PDF, TXT, and HTML files and print the reports.


Changing MBTS names and deployment IDs in batches


Viewing the status of the cells under each MBTS and performing shortcut operations on the cells


Topology management, alarm management, and MBTS list export for MBTS(WL)


Power-saving management of the MBTS



Software upgrade of the MBTS(UL)



Topology management, alarm management, software upgrades, and inventory data synchronization of the MBTS(GUL)


Inventory data synchronization of the MBTS(GU), MBTS(GL), and MBTS(UL)



Topology management, alarm management, MBTS relationship management, inventory management and export of the MBTS list of the MBTS(GL) and the MBTS(UL)



Software upgrade of the MBTS(GL)

Dependency The MBTS inventory management must work with the features WOFD-160100 Inventory Management. The MBTS power-saving management must work with the features WOFD-200200 Base Station Power-Saving Management – LTE FDD/TDD, WOFD-200600 Base Station Power-Saving Management – WRAN and WOFD-200500 Base Station Power-Saving Management – GBSS.

Issue 02 (2013-07-20)


158



WOFD-110200 MBTS Device Panel – SingleRAN Availability This feature was introduced in M2000 V200R009.

Summary The M2000 provides a centralized MBTS panel. All the subracks and boards of the MBTS, and their status and alarm information, are displayed on the same device panel. For instance, for an MBTS(GU), the boards of the GBTS and the NodeB are displayed on the panel of the MBTS. Users can run commands on the device panel to query the board status or to restart the boards. The MBTS(GL), MBTS(UL) and MBTS(GUL) also support this function.

Benefits This function centrally manages MBTSs. The display of the boards facilitates user maintenance and improves the usability of the M2000.

Description To monitor the real-time status of the MBTS, the M2000 provides panel management over the MBTS. The MBTS is displayed as an entire device panel, containing the subracks and boards on the MBTS. Panel management over the MBTS has the following functions: 

Displaying the board status and alarm information on the device panel, and automatically updating them. Users can learn the running status of a board based on the color of the board status indicator, the indicators of active alarms on the board, and the fault scrolling bar.



When faults occur on the board, the fault scrolling bar displays information about the faulty board, including the rack number, subrack number, slot number, and the name of boards. Users can choose to display or hide the fault scrolling bar.



Users can query the status of a board, restart a board, or query the board CPU usage by selecting a board and choosing different options from the shortcut menu.



If an MBTS is configured with RRUs, the M2000 provides a physical topology view for RRUs:

Issue 02 (2013-07-20)

−

The M2000 displays the topology relationships between RRUs and between RRUs and BBUs by displaying ports on interface boards, RRUs, RRU chains, and CPRI ports. The topology is updated in real time, showing the RRU chains, CPRI ports, status, and device status. Connection states are normal, unconfigured, and uninstalled. The topology also provides common command navigation paths, including querying board information, configuration parameters, extended parameters, and inventory information about RRUs, resetting boards, and querying CPRI port information, SPF module information, and bandwidth ratio of each RAT.

−

The M2000 detects CPRI connection and configuration errors for MBTSs in real time and displays incorrect CPRI ports as conflict status.

−

The M2000 displays the backplane connections of BBUs in the CPRI MUX topology. Users can directly view the convergence relationships between backplanes for RATs of an MBTS.


159






The M2000 displays the backplane connections of BBUs in the CPRI MUX topology. Users can directly view the convergence relationships between backplanes for RATs of an MBTS. The M2000 allows users to query the CPRI bandwidth ratio of each RAT in the RRU physical topology view.


Displaying the device panel of the MBTS(WL)


Displaying the device panel of the MBTS(GUL)


Displaying the device panel of the MBTS(GL)

Dependency This feature applies to MBTS(GU) in SingleRAN3.0 and later versions.

WOFD-110400 MBTS Dynamic Power Sharing – SingleRAN Availability This feature was introduced in M2000 V200R010.

Summary The GSM and UMTS carriers for the MBTS(GU) share one power amplifier. The power sharing function can be enabled when the GSM and UMTS carriers share the same power amplifier. This significantly improves the power usage and the quality of both the GSM and UMTS networks in situations where the busy hours of GSM and UMTS fall on different time segments or the traffic of GSM and UMTS is unbalanced. The M2000 provides the MBTS dynamic power sharing feature, which allows users to monitor power usage and power sharing of the MBTS(GU) on the GUI.

Benefits This feature allows users to monitor the dynamic power usage and power sharing on the GUI and to adjust power allocation according to the monitoring result.


Issue 02 (2013-07-20)

Creating an MBTS(GU) power sharing task: Users can specify the NEs to be monitored, the cabinet, subrack, and slot where the power amplifier to be monitored is located, and the monitoring time range before task creation.


160





Starting an MBTS(GU) power sharing task: After an MBTS(GU) power sharing task is started, the M2000 displays the power waveform chart in real time. The chart involves the respective peak power and average power consumed by UMTS and GSM, total power shared, power sharing duration, and total task execution duration.



Reviewing an MBTS(GU) power sharing task: Users can review a completed MBTS(GU) power sharing task. The M2000 dynamically displays the power sharing information during the task execution in chronological order. This helps users to check the history task information.

Enhancement None

Dependency None

WOFD-110500 MBTS Auto-Deployment – SingleRAN Availability This feature was introduced in M2000 V200R010.

Summary In addition to hardware installation, device and service commissioning is also important during the deployment or upgrade of an MBTS. Installation and commissioning personnel must work together to deploy or upgrade an MBTS. In this situation, the M2000 provides the MBTS automatic deployment feature to achieve the following goals: 

Lower the qualification requirements for deployment personnel



Reduce workforce costs



Improve the automation degree of MBTS deployment



Reduce errors caused by manual operations

By using this feature, MBTS deployment personnel only need to complete site hardware installation. The succeeding commissioning procedures such as software upgrade, data configuration, and installation & deployment quality testing are performed on the M2000.


The MBTS deployment period is reduced and the deployment efficiency is improved.



The MBTS deployment costs are reduced.



The qualification requirements for MBTS deployment personnel are lowered.



Site maintenance is minimized.



Errors caused by manual operations are reduced.

Issue 02 (2013-07-20)


161



Description The MBTS auto-deployment feature applies to MBTS(GU), MBTS(GL), and MBTS(UL). MBTS auto-deployment is classified into independent auto-deployment and simultaneous auto-deployment. In the case of independent auto-deployment, the auto-deployment procedure is the same as that for each RAT. In the case of simultaneous auto-deployment, auto-deployment is also performed for individual RATs. Before enabling MBTS automatic deployment, personnel need to ensure the following: 

The target software version of the MBTS is uploaded to the M2000 or the MBSC.



Transmission between the BTS, the M2000, and BSC is ready.

The phases of MBTS auto-deployment depend on those of the auto-deployment process of each RAT, for example, automatic detection and automatic configuration and software upgrade. O&M personnel can customize the auto-deployment process. After the deployment, the M2000 generates a deployment report, which contains task and progress information about the MBTS deployment. Users can export the report.

Enhancement The MBTS auto-deployment function for MBTS(GL) and MBTS(UL) is added to M2000 V200R011C00.

Dependency This feature applies to MBTS(GU) in SingleRAN5.0 and later versions.

WOFD-031800 Base Station Co-Transmission Monitoring Availability This feature was introduced in M2000 V200R011C00.

Summary Huawei MBTS provides a co-transmission scheme for multiple RATs. The M2000 provides a transmission monitoring window for the MBTS. This window displays transmission status (indicated by traffic volume and packet loss ratio) and dynamic bandwidth sharing in real time. It also displays the actual bandwidth usage of each RAT.

Benefits Efficiently collecting statistics about bandwidth usage and reusing bandwidth helps telecom operators about the transmission plan and verification, and reduce OPEX. By viewing packet loss ratio, users can check the usage of transmission resources in time, and try to improve network quality by expanding transmission capacity. This prevents network KPI deterioration caused by insufficient transmission resources.

Description Currently, The Base Station Co-Transmission Monitoring feature applies to MBTS(GU), MBTS(GL), MBTS(UL), and MBTS(GUL).

Issue 02 (2013-07-20)


162



The co-transmission scenarios supported by MBTS(GU) are as follows: 

FE/GE cascade



FE/GE convergence



IP over E1 cascade

MBTS(GL), MBTS(UL), and MBTS(GUL) support FE/GE cascade scenarios and FE/GE convergence scenarios. The M2000 provides the management of co-transmission monitoring tasks. Users can create the IP transmission monitoring task by setting objects and ports to be monitored, and setting the networking mode. The M2000 displays the co-transmission information about each base station in a chart or table. The co-transmission information includes peak traffic, average traffic, peak packet loss ratio, average packet loss ratio, total peak traffic, and total average traffic.

Enhancement None

Dependency None

WOFD-110600 Dynamic Spectrum Sharing Availability This feature was introduced in M2000 V200R011C00.

Summary The dynamic spectrum sharing feature is developed to meet the frequency refarming requirements of telecom operators. Frequency refarming is a solution with which telecom operators reuse their spectrum resources by adopting new radio telecommunications technologies, improving spectrum efficiency and data throughput. GSM subscribers are gradually evolving from to UMTS subscribers. Frequency refarming cannot be implemented during the transition period. To solve this problem, Huawei provides the dynamic spectrum sharing feature for improving spectrum efficiency during the transition period. Using this feature, the M2000 classifies the spectrum on a GSM network into basic spectrum and shared spectrum. Shared spectrum can be dynamically switched between GSM and UMTS networks.


Costs on data services are reduced, while the spectrum resource usage is improved.



The coverage of mobile broadband data services and user satisfaction are improved.

Description The M2000 allows users to create, modify, delete, start, and stop dynamic spectrum sharing tasks. The following information can be defined in a dynamic spectrum sharing task:

Issue 02 (2013-07-20)


163



Spectrum sharing areas. A spectrum sharing area is served by one or several base stations or base station pairs. Based on base station locations in the sharing areas and spectrum sharing modes, base station coverage types are classified as normal, small, and Buffer Zone coverage. −

Normal coverage: This coverage mode is used when the base station is in the center of the spectrum sharing area, because there is no co-channel interference between shared UMTS cells and neighboring GSM cells.

−

Small coverage: This coverage mode is used to reduce co-channel interference between shared UMTS cells and neighboring GSM cells if the base station is on the edge of the spectrum sharing area.

−

Buffer Zone coverage: This coverage mode is used to reduce co-channel interference from GSM cells under the base stations to surrounding shared UMTS cells if no UMTS cell exists in the spectrum sharing area.



Information about base station pairs can be imported to the M2000 using CSV files. Base station pairs can also be selected on the M2000 GUI.



Spectrum sharing periods for different days in a week or specified times on special dates to start or stop spectrum sharing.



Proportion of BTSs for reclaiming spectrum. If the proportion of BTSs requiring spectrum reclaiming to the total number of BTSs reaches a specified threshold in an area, reclaiming spectrum sharing is triggered.

After a dynamic spectrum sharing task is started, the M2000 sends task setting rules to the BSC. Then, the BSC determines whether to start spectrum sharing based on the network load within a specified period. If the BSC has started spectrum sharing, the M2000 instructs the RNC to start spectrum sharing. 

In non-Buffer Zone scenarios, the RNC activates cells and uses the spectrum shared by the BSC to bear services.



In Buffer Zone scenarios, however, the RNC does not activate cells.

When a spectrum sharing period ends or the BSC determines to reclaim spectrum sharing based on the network load, the M2000 will instruct the RNC to block shared UMTS cells. Users can also manually share or reclaim spectrums. During dynamic spectrum sharing, the M2000 monitors the spectrum sharing status of GSM and UMTS.

Enhancement None

Dependency None

Issue 02 (2013-07-20)


164



2.14 Network Planning and Optimization WOFD-050800 Network Optimization Policy Management – LTE FDD/TDD Availability This feature was introduced in M2000 V200R009.

Summary The M2000 provides the feature of managing network optimization policies. This feature allows telecom operators to easily create network optimization policies, configure policy parameters, and control policy switches, according to the actual network deployment situations and optimization requirements. In addition, the M2000 provides network optimization logs for users to check network optimization progress and results.

Benefits The M2000 provides the function of managing network optimization policies so that users can adopt a corresponding network optimization policy based on the actual network load. The M2000 provides the function of viewing network optimization logs so that users can easily monitor the optimization process and query optimization results.

Description The M2000 provides the following network optimization policy management feature and corresponding network optimization logs: 

Network optimization policies −

Mobility Robust Optimization (MRO) policy The MRO algorithm automatically adjusts mobility parameters by measuring the numbers of premature handovers and delayed handovers periodically. By adjusting mobility parameters, the MRO algorithm can reduce abnormal handovers and radio link failures (RLFs), ensuring smooth UE handovers. The M2000 provides the function of setting MRO switches for eNodeBs, including intraand inter-frequency MRO switches and inter-RAT MRO switches (GERAN and UTRAN). Base stations also support MRO control. In MRO controlled mode, handover parameters are not adjusted automatically. Instead, the related parameter optimization advice is generated. Users then review the optimization advice and perform related adjustments. The M2000 provides a switch for the MRO controlled mode and related GUIs for users to determine whether to adjust MRO handover parameters. In addition, the M2000 allows users to manually adjust parameters, including intra-frequency handover and intra-frequency handover and reselection parameters, inter-frequency handover parameters related to A2, and inter-frequency handover parameters unrelated to A2.

−

Inter-Cell Interference Co-ordination (ICIC) optimization policy The ICIC technique reduces the inter-cell interference by coordinating allocation of time and frequency domain resources and setting RF power. The M2000 provides eNodeB ICIC optimization switches that are easy to control, such as uplink switch in time domain, and uplink and downlink switches in frequency domain.

Issue 02 (2013-07-20)


165



Mobility Load Balancing (MLB) policy The M2000 provides the functions of querying and configuring the MLB parameters of eNodeBs. The MLB policy applies to the following three scenarios: intra-frequency load balancing, inter-frequency load balancing, and inter-RAT load balancing. Therefore, the MLB parameters contain the switches and thresholds corresponding to these three scenarios.



Self-organizing network (SON) logs When a network optimization policy is applied, the key st eps and results related to network optimization are recorded into logs. The M2000 provides the functions of querying and viewing network optimization logs and collecting log statistics. Users can set various filter criteria or combined filter criteria when querying optimization logs.


Providing a switch for the MRO controlled mode and the optimization advice for handover parameters in MRO controlled mode


Collecting SON log statistics

The MRO and MLB optimization policies are added to M2000 V200R010.

Dependency Users can use the preceding network optimization policies only after they have purchased the corresponding eNodeB features.

WOFD-050900 Automatic Planning of Micro eNodeBs – LTE FDD/TDD Availability This feature was introduced in M2000 V200R011C01.

Summary Planning radio parameters for micro eNodeBs is difficult because a micro eNodeB covers a small area and is frequently reparented or expanded. To solve this problem, the M2000 provides the feature of automatically planning radio parameters for micro eNodeBs based on clusters. This feature is based on cluster parameters and is used together with the plug-and-play function. When enabled, the receiver on a micro eNodeB starts scanning neighboring cells and sends scanning results to the M2000. Upon receiving the results, the M2000 identifies the cluster where the micro eNodeB is located and generates radio cell parameters for the micro eNodeB based on cluster planning parameters.

Benefits Automatic parameter planning reduces site deployment time, manual operations, and project construction costs. With this feature, micro eNodeBs are put into service shortly after they are deployed.

Issue 02 (2013-07-20)


166



Description This feature is based on cluster parameters. A cluster indicates a scope defined by network planning engineers based on macro cell locations. After a micro eNodeB is deployed, this feature allows the micro eNodeB to obtain radio parameters and complete the parameter configurations based on the micro eNodeB's location. Cluster parameters include the cluster name, cluster location information, and cluster resource information. The cluster location information is used for locating micro eNodeBs and is defined in a GSM macro cell list and a UMTS macro cell list. The cluster resource information is used for allocating radio parameters of micro eNodeBs in this cluster. These parameters include TAC, the value range of the PCIs that can be allocated, RootSequenceIdx that can be allocated, and the frequency range. Cluster parameters can be imported from and exported to CSV files. In addition to setting cluster parameters, network planning engineers need to preset parameters to be scanned by micro eNodeB's receivers. The scanning parameters contain the MCC and MNC of neighboring GSM cells and frequencies of UMTS neighboring cells. After being powered on, a micro eNodeB searches for its neighboring cells based on these parameters and reports the neighboring cell information to the M2000. Then, the M2000 identifies the cluster where the micro eNodeB is located based on the cluster location information. After computing cell radio parameters using the automatic planning algorithm, the M2000 sends the parameters to the micro eNodeB. These parameters include RootSequenceIdx, the frequency, PCI, TAC, and neighboring cell list. In the plug-and-play process, the micro eNodeB starts the automatic planning after upgrading the software and downloading configuration files. The M2000 supports the monitoring of the automatic planning process. With this function, users can view the status of the automatic planning and export a report.

Enhancement None

Dependency This feature is dependent on the feature LOFD-002016 Micro eNodeB Self-planning.

WOFD-051000 Automatic Micro NodeB Planning – WRAN Availability This feature is introduced in M2000 V200R012C00.

Summary Micro NodeBs have simple configuration and are used in small parts of coverage areas such as hot spots and holes. Due to the characteristics of micro NodeBs, the M2000 automatically plans their radio parameters based on certain rules and algorithms. Automatic planning of micro NodeBs is performed during automatic deployment of micro NodeBs. The following data of micro NodeBs can be automatically planned in single- or dual-carrier scenarios:   

Issue 02 (2013-07-20)

Frequencies and scrambling codes Neighbor relationships LACs, RACs, SACs, and URAs Huawei Proprietary and Confidential Copyright © Huawei Technologies Co., Ltd.

167



Benefits This feature, integrated into the automatic deployment of micro NodeBs, automatically plans radio parameters of micro NodeBs. This simplifies micro NodeB planning, reduces planning costs, and shortens micro NodeB deployment.

Description The M2000 automatically plans frequencies, scrambling codes, neighbor relationships, LACs, RACs, SACs, and URAs during automatic deployment of micro NodeBs. Before starting automatic micro NodeB planning, users must provide reference data, including available frequencies and scrambling codes of micro NodeBs, available frequencies of macro NodeBs, PLMN of GSM cells, maximum number of macro carriers, and continuous coverage ARFCNs. In single-or dual-carrier scenario, if users have selected the automatic planning procedure during automatic micro NodeB deployment, the M2000 triggers the planning and sends a frequency scanning command to micro NodeBs. Based on the frequency scanning results reported from micro NodeBs and planned reference data entered by users, the M2000 plans frequencies, neighbor relationships, scrambling codes, LACs, RACs, SACs, and URAs using the automatic radio parameter selection algorithm. Then, the M2000 delivers the planning results to the micro NodeBs to complete the automatic planning. The principle for automatically planning frequencies and scrambling codes is as follows: Micro NodeBs detect available frequencies and the scrambling code of each frequency. The M2000 selects the frequency with the minimum received signal strength as the working frequency for each micro NodeB. It then filters out the scrambling codes that meet the requirements under this frequency and selects the most appropriate scrambling code as the available scrambling code for the micro NodeB. The principle for automatically planning neighbor relationships is as follows: The receiver of each micro NodeB obtains the signal strength of each cell by searching for cells and detecting scrambling codes. It then selects cells with the optimal signal strength quality and configures these cells and the cells under the micro NodeB as bidirectional neighboring cells. The principle for automatically planning LACs, RACs, SACs, and URAs is as follows: In the scanning result of neighboring cells for a local cell, the M2000 selects the LAC, RAC, and URA of the neighboring cell with the optimal signal quality as the LAC, RAC, and URA of the local cell. The value of the SAC is the same as the local cell ID. The M2000 monitors automatic micro NodeB planning. It allows users to view the automatic planning progress, result, and report, and export the report as an HTML file.


Automatic micro base station planning in dual-carrier scenarios

Dependency This feature applies to BTS3902E WCDMA and BTS3803E WCDMA, and needs to collaborate with the automatic micro NodeB planning on the RAN side.

Issue 02 (2013-07-20)


168



2.15 Wireless Auxiliary Networking Devices WOFD-300200 Auxiliary Networking Devices Management Availability This feature was introduced in M2000 V200R009.

Summary On mobile networks, various networking devices are used, such as routers, switches, and firewalls. To implement centralized management of mobile devices and these auxiliary networking devices, the M2000 provides the function of managing Huawei IP devices and NE bearing servers that are frequently used in RANs and third-party devices such as the Wi-Fi, DNS, and DHCP.

Benefits This feature implements the management of the entire mobile network through only one third-party system. It minimizes the investments on OSS devices and reduces the workload of maintenance personnel, reducing OPEX for telecom operators.

Description On mobile networks, networking devices provided by Huawei are used, such as routers, switches, and firewalls. Traditionally, to manage these networking devices, the N2000 provided by Huawei is used to manage the networking devices and the M2000 is used to manage mobile network devices such as BTSs and BSCs. Therefore, at least two OSS products must be deployed. The traditional management mode cannot implement the mutual network management. In addition, it cannot minimize the investments of telecom operators when only a few transmission devices are used. To solve these problems, the M2000 implements the basic management of common networking devices such as routers, switches, and firewalls. It also provides other functions such as alarm management, configuration browse, and topology management. 

Alarm Management The M2000 centrally collects and displays the alarms of IP devices including S-series switches, routers of NE08-series and AR46-series, Eudemon-series firewall, IPSec Gateway, Wi-Fi device (Skyway Excel XL5810), and NE bearer servers on the network. Users can mask, acknowledge, unacknowledge, clear, and collect the statistics of alarms.



Status Check of the Third-Party DHCP and DNS The M2000 can check the running status of the devices that use third-party DHCP and DNS on GSM, LTE and WCDMA networks. When the devices do not work properly, the M2000 generates alarms.



Configuration Management The M2000 can collect interface configuration data of IP devices. The data is displayed through the Management Information Tree (MIT). In this way, user can centrally view the interface configuration data of IP devices. User can export the configuration data of a selected IP device on the GUI. The file is in CSV or XML format.



Issue 02 (2013-07-20)

Topology Management


169



The M2000 provides the centralized topology management function, through which users can create, delete, and modify the topology objects of IP devices and other devices in the topology view. −

Creating topology objects When creating objects, users need to set the properties of objects. The properties vary according to objects. All the objects have two common properties, creation time and last modified time. The system automatically records the two properties. The M2000 can create the IP devices, and other devices such as DNS, DHCP, and Wi-Fi device in batches in the topology view. Users can export the batch creation file template of the corresponding NE from the M2000, edit the script files of batch creation according to the template format, and perform batch NE creation by importing the script files.

−

Configuration information labels The M2000 displays the configuration information about IP devices, DNS, Wi-Fi, and DHCP in the topology view.

−

Deleting topology objects The M2000 allows users to delete one or multiple topology objects from the topology view.



Log management NE system logs record important events such as operation errors, faults, and attacks. These logs help users analyze the operating status of NEs and perform troubleshooting. The M2000 collects and stores system logs for IP devices and allows users to query, export, and collect statistics about the logs. NE system logs can be exported as CSV and TXT files. The database stores these logs for a maximum of 90 days. Users can change the period. If the disk configuration for the M2000 is low or the space planned for the NE log database is less, users may not be able to store the logs for 90 days. When the M2000 reaches the end of the storage period or disk capacity limit, the M2000 automatically dumps NE system logs to files.

Enhancement None

Dependency Only telecom operators who have purchased Huawei IP devices including S-series switches, NE08-series routers, AR46-series routers, and Eudemon-series firewall, or who use the M2000 to manage the third-party DNS, DHC, and Skyway Excel XL5810 need to use this feature. Users must purchase Huawei customization services if they require enhanced management for DNS, DHCP, and Skyway Excel from Huawei.

Issue 02 (2013-07-20)


170


0Acronyms and Abbreviations

Acronyms and Abbreviations 3GPP

3rd Generation Partnership Project

A ACL

access control list

ALD

antenna line device

ATAE

Advanced Telecommunications Application Environment

C CME

Configuration Management Express

CORBA

Common Object Request Broker Architecture

D DST

daylight saving time

E ESN

electronic serial number

eSAU

evolved service aware unit

F FDN

Full Distinguished Name

FTP

File Transfer Protocol

G GPS

Global Positioning System

GSM

Global System for Mobile Communications

GUI

graphical user interface

Issue 02 (2013-07-20)


171


0Acronyms and Abbreviations

H HTTP

Hypertext Transfer Protocol

I ICIC

inter-cell interference coordination

L LDAP

Lightweight Directory Access Protocol

LTE

Long Term Evolution

M MD5

message digest algorithm 5

MDT

Minimization of Drive-Tests

MLB

mobility load balancing

MML

man-machine language

MOCN

multioperator core network

MR

measurement report

MRO

mobility robust optimization

N NTP

Network Time Protocol

O O&M

operation and maintenance

OPEX

operating expense

OSMU

OSS self-maintenance unit

OSS

operations support system

P PC

personal computer

R

Issue 02 (2013-07-20)


172

IManager M2000 V200R013 Basic Feature Description(GSM&UMTS&LTE)

Recommend Documents