Product Type Technical Description

ZXSDR Upgrade Guide (from OMCB V4.11 to OMMB V12.12.40PXX)

ZXSDR Upgrade Guide (from OMCB V4.11 to OMMB V12.12.40PXX)

ZXSDR Upgrade Guide (from OMCB V4.11 to OMMB V12.12.40PXX)

Product Type Technical Proposal

IV 2015ZTE CORPORATION. All rights reserved.ZTE Confidential Proprietary

ZTE Confidential Proprietary 2014 ZTE Corporation. All rights reserved.1(4)

LEGAL INFORMATION

By accepting this certain document of ZTE CORPORATION you agree to the following terms. If you do not agree to the following terms, please notice that you are not allowed to use this document.

Copyright 2015 ZTE CORPORATION. Any rights not expressly granted herein are reserved. This document contains proprietary information of ZTE CORPORATION. Any reproduction, transfer, distribution, use or disclosure of this document or any portion of this document, in any form by any means, without the prior written consent of ZTE CORPORATION is prohibited.

and are registered trademarks of ZTE CORPORATION. ZTEs company name, logo and product names referenced herein are either trademarks or registered trademarks of ZTE CORPORATION. Other product and company names mentioned herein may be trademarks or trade names of their respective owners. Without the prior written consent of ZTE CORPORATION or the third party owner thereof, anyones access to this document should not be construed as granting, by implication, estopped or otherwise, any license or right to use any marks appearing in the document.

The design of this product complies with requirements of environmental protection and personal security. This product shall be stored, used or discarded in accordance with product manual, relevant contract or laws and regulations in relevant country (countries).

This document is provided as is and as available. Information contained in this document is subject to continuous update without further notice due to improvement and update of ZTE CORPORATIONs products and technologies.

ZTE CORPORATION

Address:Address:NO. 55Hi-tech Road SouthShenZhenP.R.China518057

Website:http://dms.zte.com.cn

Email:TSM.Aftersales@zte.com.cn

Revision History

Product VersionDocument VersionSerial NumberReason for Revision

R1.0First published

R1.1Modules added

Author

DateDocument VersionPrepared byReviewed byApproved by

2013-10-12R1.0Qi Xianfeng He Yijun

2014-03-31R1.1Qi Xianfeng, He Yijun He Yijun

Intended audience: SDR commissioning engineers

TABLE OF CONTENTS1Introduction11.1Application Scope11.2Conventions12Overview33Pre-check54Preparation64.1Acquiring Version Package64.2Uploading Version Package74.3Clearing Disk Space on OMCB74.4Performing Active/Standby Board Changeover Test95Data Backup115.1Backing up SDR Data on OMCB115.1.1SDR Configuration115.1.2Running Status125.1.3Alarm Notification125.2Database and Version Backup165.2.1Stopping Logservice on the Standby Board165.2.2Performing Active/Standby Data Synchronization165.2.3Data Backup176Data Conversion (with Laptop)196.1Preparing Data196.2Checking Java Operating Environment196.3Unzipping Tool Package196.4Converting Data197Upgrading OMMB227.1Single Server Scenario227.1.1Stopping NE Agent on EMS227.1.2Installing OMMB227.1.3Starting OMMB237.1.4Importing Configuration Data247.1.5Creating EMS Agent267.2Cold Backup Scenario277.2.1Generating Mirror Data277.2.2Stopping NE Agent on EMS297.2.3Installation297.2.4Starting OMMB307.2.5Importing Configuration Data317.2.6Creating EMS Agent337.2.7Active/Standby Board Changeover347.3Active/Standby Boards in Hot Backup347.3.1Stopping NE Agent on EMS347.3.2Installing OMMB on the Standby Board347.3.3Stopping OMMB on the Active Board357.3.4Starting OMMB on the Standby Board357.3.5Importing Configuration Data377.3.6Creating EMS Agent397.3.7Upgrading the Original Master SBCX407.3.8Starting the New OMMB on the Original Active Board428Verification448.1Verifying OMMB448.2Verifying SDR448.3Checking Status448.3.1Monitoring Performance449Rollback469.1SDR Rollback469.2OMMB Rollback4810Re-upgrade50AppAAppendix51A.1EXP-00091 Message Prompted in the Backup Process51A.2OMMB Startup Failure After the Execution of ./upgrade.sh restore (Cold Backup)51A.3Configuration Data Importing Error51A.4Conversion Error51A.5Database Restoration Failure During Standby Board Restoration53A.6EMS Agent53A.6.1Creating Upgrade Agent53A.6.2Deleting the Old Agent56A.6.3Stop the Old Agent57A.6.4Starting the New Agent58A.7Method of Setting JAVA_HOME in Windows OS58A.8Link Restoration After Rollback58A.9Method of Distinguishing Logservice/Ommhost59

ZXSDR Upgrade Guide (from OMCB V4.11 to OMMB V12.12.40PXX)

ZXSDR Upgrade Guide (from OMCB V4.11 to OMMB V12.12.40PXX)

ZTE Confidential Proprietary 2015 ZTE CORPORATION. All rights reserved.27

IntroductionApplication ScopeThis Guide applies to the following scenarios:1.SDR upgradeApplicable Site Types: BS8700, BS8800, BS8900, BS8900A, and BS8906Applicable versions:SDR V4.11.10.08P04-P06 and V4.11.10.14P02-P06 series, which are to be upgraded to V4.12.10.15PXX2.OMMB upgradeApplicable platform:SBCX REHL Applicable versions:OMMB V4.11.10.14P02-P06 and V4.11.10.08P05-07, which are to be upgraded to V12.12.40P29/V12.12.40P55ConventionsOMCB V4.11 is hereafter referred to as OMCB (the old OMM), while OMMB V12.12.40P29/ V12.12.40P55 is hereafter referred to as OMMB (the new OMM). In this guide the OMMBV12.1240P29 is used as an example in explaining the upgrade of OMMB version.The server is operated only as the root user. This Guide applies to the upgrade of the active/standby boards in hot backup and cold backup, as well as the upgrade in the single server scenario. The active/standby boards in hot backup use dual-server configuration and the active board and the standby board run at the same time.In the scenario of active/standby boards in cold backup, the standby board is not online, it only provides mirroring to upgrade the active board. After the upgrade, it will switch to the active board. The single server scenario refers to the OMMB server without standby board.The working directory in this Guide may change. The ./upgrade.sh script is executed under the following directory by default. /home/OMMB-Installer/Installer/install/tools/upgrade

OverviewThis Upgrade Guide consists of two parts, i.e., OMMB upgrade and SDR upgrade, which fall into three stages. The operations of these three stages are all required to be performed. Please perform these operations in the sequence specified in this Guide. If only the OMM or the SDR is to be upgraded, all the upgrade steps should be performed. 1.Operations before the upgradeThe operations before upgrade involve two parts. The first part, i.e., Chapters 3, 4, and 5, is about saving the data of the existing network and will not affect services. The second part, i.e., Chapter 6, introduces the preparation of backup environment, version file, and data conversion, which will not affect services. Therefore, the operations of these two parts can be performed in advance at any time.2.Operations during the upgradeChapter 7 is the core of the upgrade.OMMB upgrade does not affect the services of the existing network, but it will affect the NE management control. Therefore, OMMB upgrade should be performed at the time when there are fewer services. 3.Operations after the upgradeChapters 8 and 9 introduce the operations after the upgrade, including mainly upgrade verification (whether the upgrade succeeds or not) and the rollback after upgrade failure.4.The upgrade in different scenarios is as detailed below:Single server scenarioUpload version > Export configuration data > Back up data > Convert configuration dataStop OMCB > Perform upgrade > Start OMMB > Import Configuration Data Perform rollback > Start the OMCBActive/standby boards in hot backup:Upload version (on the active board and the standby board respectively) > Synchronize data > Export configuration data > Perform backup on the standby board > Convert configuration dataStop Logservice on the standby board > Upgrade the standby board > Stop Logservcie on the active board > Start Logservice on the standby board > Import configuration data on the standby board Upgrade the active board > Synchronize data (after the standby board runs normally)Roll back the standby board > Start Logservice on the standby board Scenario of active/standby boards in cold backupUpload version > Export configuration data > Back up data on active board > Upload data to the standby board > Perform mirroring on the standby board > Switch configuration dataUpgrade the standby board > Start OMMB > Import configuration data on the standby board Replace SBCX 5.SDR upgrade procedure: Convert configuration data > Upgrade configuration data > Download software version > activate software version

Pre-check Check whether the upgrade requirements are satisfied. If some sites do not meet the requirements, filter or adjust these sites before starting the upgrade procedure. Perform the following operations on OMCB: 1.SDR version: Make sure the hardware and software version of the SDR satisfy the requirements specified in Section 1.1. 2.SDR status Make sure there is no transmission fault. Otherwise, the fault may affect the upgrade of the SDR. If there is some fault, clear the fault before performing or canceling the upgrade. 3.SDR configuration: Check the master/slave CC boards. Check whether there are alarms indicating the board is not configured. If the alarm details show that the CC at Slot 1 or Slot 2 is not configured, the upgrade cannot be performed. In this case, it is necessary to modify the configuration and add a standby CC. Then, delete the CC after the upgrade is completed.

PreparationAcquiring Version PackageBefore the upgrade, it is necessary to acquire OMMB version package ZXSDR_OMMB_V12.12.40P29.zip, tool package ZXSDR_OMMB_Tools_V12.12.40P29.zip, and the SDR version package. All the current OMMB version packages have patch packages. The patch package of OMMB can be put under the SPTool\sp directory, which is appointed for the OMMB version. Thus, the patch is also installed after OMMB installation is completed. The detailed operation procedure is as shown below:Unzip the patch set to a folder, open the version package, and add the unzipped patch set to the SPTool or sp directory. Then save and close the version package to finish the modification to the version package. It should be noted that the version package is not unzipped here. Instead, only some patch sets are added in it. In the Windows OS, unzip patch set ZXSDR_OMMB_V12.12.40P29_xx.zip, and drag the emergency patch (the *.zip file) under the patch directory of the patch set to the installation package ZXSDR_OMMB_V12.12.40P29.zip, as shown in the figure below:

The target location is as shown below:

Uploading Version PackagePerform this operation in the following scenarios: the active and standby boards of the cold backup scenario, the active and standby boards of the hot backup scenario, and the single-server scenario. Log in to OMMB server as the root user, and upload the following two packages to the /home directory. Installation package ZXSDR_OMMB_V12.12.40P29.zipTool package ZXSDR_OMMB_Tools_V12.12.40P29.zipOpen the command terminal, and copy the following commands in to the command terminal for execution as the root user. Check Ommhost start /stop is start then stop firstcd /home/ommhost/bin/./stosys

mkdir /home/OMMB-Installercd /home/OMMB-Installer#chmod 777 R /home/OMMB-Installermv /home/ZXSDR_OMMB_V12.12.40P29.zip . mv /home/ZXSDR_OMMB_Tools_V12.12.40P29.zip . unzip ZXSDR_OMMB_V12.12.40P29.zipunzip ZXSDR_OMMB_Tools_V12.12.40P29.zip j ZXSDR_OMMB_Tools_v12.12.V40P29cd /home/OMMB-Installer/Installer/install/tools/upgrademv /home/OMMB-Installer/ZXSDR_TO412_SCRIPT.tar.gz . tar -zxvf ZXSDR_TO412_SCRIPT.tar.gz

The above statements are used to perform the following operations: 1.Create a new directory, i.e., /home/OMMB-Installer. 2.Move the installation package and the tool package to the new directory. 3.Unzip the installation package and the tool package. 4.Move the script to the /home/OMMB-Installer/Installer/install/tools/upgrade directory. 5.Unzip the script package. Clearing Disk Space on OMCBThe disk space on OMCB needs to be cleared in advance to avoid upgrade failure due to disk space insufficiency in the upgrade process. 1.Click View > Dynamic Data Management, and set Model Versions as v11.02.01. Then, select the NE of which the disk space is to be cleared on the Config Resource Tree in the left pane. Select Device Group Object in Objects Tree, as shown in the figure below.

2.Select the CC of which the disk is to be cleared, and click Clean Disk. Then set the value of all the attributes in the pop-up dialog box to Yes.

3.Click OK and wait until the system returns the disk space clearing result, as shown in the figure below.

Performing Active/Standby Board Changeover TestThis step is performed in the high availability solution scenario. It is to verify whether the standby board is normal before the upgrade. If active/standby changeover is performed recently and the standby board works normally, ignore this step. Execute the following command on the active board. #telnet localhost 1234Trying 127.0.0.1...Connected to localhost.localdomain (127.0.0.1).Escape character is '^]'.#SCS_TestChgOverAfter the execution ends, switch to the standby board about five minutes later, and execute the following command. #telnet localhost 1234Trying 127.0.0.1...Connected to localhost.localdomain (127.0.0.1).Escape character is '^]'.SBCX-> SCSShowBrdInfo Bureau: 0 rack: 1 shelf: 2 slot: 1 cpu: 1 board pos: 0 boardtype: 132 boardId: 2 pcbVer: 1 ipaddr: 0x80002101 ctrl plat mac addr: 00:d0:d0:80:30:01Logical address info: system: 0 subsystem: 255 module: 100 unit: 65535 board backup mode: 1+1 board ms state: masterboard run mode: act as server,and share board with OMMIf the state of the standby board is board ms state:master, it means the board has been switched to the active board. Log in to OMCB through the OMCB client in Windows OS, and check whether OMCB can be started and whether its basic functions can be used normally. After it is confirmed that OMCB works normally, we can either perform active/standby board changeover with the method mentioned above or keep the current state.

Data BackupPerform data backup on OMCB. Warning:After the data backup is completed, it is prohibited to perform any modification to the data of the existing network. Otherwise, the follow-up upgrade may become abnormal.Backing up SDR Data on OMCBSDR Configuration Perform this operation on the client of OMCB.This operation is used mainly to save the SDR configuration data and other related data, which may be needed in the comparison of SDR status before and after the upgrade, verification, and rollback. Perform this operation on the client of OMCB.Before data backup, make sure the configuration data of the SDR is consistent with that on OMMB.1.Upload data onlinei.Apply for Mutex Right in Batch.Right-click the target subnet node, and click Batch Apply Mutex Right to apply for Mutex right in batch. ii.Upload data online.Right-click the node of the subnet and select Base Station Configuration Wizard (SDR). Select a site to upload data from NE according to the wizard. And then switch the uploaded configset to the master one.2.Export data in batchOpen the Configuration Management window, click SDR Configuration Management > Batch Export Ne Data, and set Export Directory. Then click OK to export the configuration data.

3.Record the subnet ID of the SDR. This step is a preparation for creating subnet on the OMMB of the new version in the later phase. Running Status1.Iub interface link status 2.Cell status3.The link disconnection and commissioning status of the SDR Alarm Notification Note:Notify the operator of the operations before disabling alarm filter and stopping the commissioning mode.1.At the OMCB side, cancel the alarm filter rules and perform alarm synchronization.2.At the EMS side, change the site commissioning mode to the normal working mode and perform alarm synchronization.3.Backing up active alarms and notifications:i.Export the active alarms.In the alarm management window, click Fault > Query Active Alarms.

Click the export button, and the following dialog box pops up.

Click OK and carry out the operations according to the following figure.

ii.Export the notifications.In the alarm management window, click Fault > Query Notifications.

Click the export button, and the following dialog box pops up.

Click OK and carry out the operations according to the following figure.

Database and Version BackupFor the scenario of active/standby boards in hot backup, perform all the following steps. For other scenarios, start the steps from Section 5.2.3. Stopping Logservice on the Standby Board For Logservice, execute the following command: #cd /home/zte/logservice/bin# ./stopsys For OmmHost, execute the following command. #cd /home/zte/OmmHost/bin# ./stopsysRefer to A.9 to judge whether it is Logservice or OmmHost. For the scenarios involving Logservice and OmmHost in the following sections, Logservice will be taken as the example. Performing Active/Standby Data Synchronization After both the active board and the standby board run normally, execute the following commands on the active board, and synchronize data from the active board to the standby board (enter the OMM operation directory). # cd ums-svr/tools/backup# sh dbsync-linux.sh oracle //oracle is the password to the system account of the database. 2013-10-14 11:00:39,605 INFO [DBSyncProcess] Welcome to use the database synchronise tool.2013-10-14 11:00:39,606 INFO [DBSyncProcess] 1. Synchronise all tables which configed by the tableConfig-dbsync*.properties.2013-10-14 11:00:39,606 INFO [DBSyncProcess] 2. Synchronise the history tables of Fault Management(FM) and Performance Management(PM)2013-10-14 11:00:39,607 INFO [DBSyncProcess] 3. Synchronise the Performance Management(PM) file2013-10-14 11:00:39,607 INFO [DBSyncProcess] 4. Compare the local database data and the remote.2013-10-14 11:00:39,607 INFO [DBSyncProcess] Please select 1 , 2 , 3 or 4:1//Input 1 here and perform all-data synchronization. After the all-data synchronization is finished, execute the following commands to confirm whether the data on the active board and the standby board are successfully synchronized. #sh dbsync-linux.sh oracle2013-10-14 11:03:02,038 INFO [DBSyncProcess] Please select 1 , 2 , 3 or 4:4//Select 4 for comparison. 2013-10-14 11:03:05,016 INFO [DBSyncProcess] 1. Only Compare one table2013-10-14 11:03:05,017 INFO [DBSyncProcess] 2. Compare all the tables2013-10-14 11:03:05,017 INFO [DBSyncProcess] Please select 1 or 2:2//Select 2 for all-data comparison. 2013-10-14 11:03:09,721 INFO [DBSyncProcess] The localIP:128.0.29.12013-10-14 11:03:09,722 INFO [DBSyncProcess] The remoteIP:128.0.29.9There are 134 same tables and 0 different tables .//It means the data on the master board are exactly the same as those on the slave board.Data BackupExcept the active board of the hot backup scenario, it is necessary to perform data backup for all the other scenarios. Execute the following commands to back up OMCB data and the database. #cd /home/OMMB-Installer/Installer/install/tools/upgrade#./upgrade.sh backup begin to readOMCBInfoExOmc path is found as follows:=========================================================================1 : /home/ZX-OMMB=========================================================================Which one is Old omc path?(input your choice):1//Select OMCB path. If it cannot be found, the following prompt will appear. Input OMCB path:/home/ZX-OMMB//Type in OMCB path manually. Old omc dir is /home/ZX-OMMBORACLE_SID read from omc is ommbPlease input correct system's password of oracle database:oracle//Input password of databaseMake sure the following information:====================================================================System's password of oracle database is [oracle]====================================================================Enter 'y' to continue,'n' to cancel:y//Type in y to continue .backup all successfully.//This prompt means the backup succeeds. After the data backup is completed, execute the following commands to see whether the file is generated. #ls /home/OMMB-Installer/Installer/install/tools/upgrade/tempbackup.tar.gzsilence-setup.propertieslog_conf.tar.gz//If Logservice is installed, the log_conf.tar.gz file will be generated.

Data Conversion (with Laptop) This step is to convert the SDR configuration data of the old version to the format of OMMBV12.12.40P29 with the smooth upgrade tool and verify whether the data restrictions satisfy the requirements in OMMBV12.12.40P29, so as to make preparation for the follow-up upgrade.If the conversion fails, the subsequent OMMB upgrade plan should be adjusted accordingly. It is recommended that the conversion be performed several weeks in advance. Currently there are some problems (such as data error, version inconsistency, and data restriction problems) in the field that affect the follow-up upgrade. If the upgrade needs to be performed at this time, data modification must be performed before the upgrade. Therefore, data conversion should be performed in advance. This operation should be performed in Windows OS.Preparing DataCopy the XML configuration data backed up in Section 5.2 to the c:\exports directory. Checking Java Operating EnvironmentExecute the following commands and make sure Java operating environment is installed correctly in the Windows OS. It should be one of jdk1.6 series. If Java has not been installed, configure it according to Section A.7. C:\Documents and Settings\10116340.ZTE>java versionjava version "1.6.0_32"Java(TM) SE Runtime Environment (build 1.6.0_32-b05)Java HotSpot(TM) Client VM (build 20.7-b02, mixed mode, sharing)Unzipping Tool PackageUnzip the ZXOMMBSmoothTool_V12.12.40P29.zip smooth tool package to the C:\trans directory. Converting DataDouble-click c:\trans\runWindowsGUI.bat to start the tool. 1.Specify the source directory and the destination directory.Source Directory: c:\exportsDestination Directory: c:\dest2.Choose the source version and the destination version.Source Version: 4.11.10.xx (select the version actually used) Destination Version: 4.12.10.08P103.Click Data Upgrade to start converting data. 4.Check the execution result and click OK.

View the list of the files exported under the c:\dest directory.If the conversion fails, refer to Section A.4 for details.

Upgrading OMMBThis chapter describes the upgrade operations in the three scenarios respectively, i.e., single-server, active/standby boards in cold backup, and active/standby boards in hot backup. Single Server Scenario Upgrade procedure: Stop OMCB > Perform upgrade > Start OMMB > Import configuration data > Create OMMB (MO) agent on EMS Stopping NE Agent on EMS The corresponding NE agent on the EMS must be stopped before the upgrade. Refer to A.6 for the operation method. Installing OMMB Execute the upgrade.sh script to stop the old OMM (OMCB) and Logservice and its auto-start, and install the new OMM (OMMB). Note: If OMMR is configured in Logservice, OMMR will also be stopped. #cd /home/OMMB-Installer/Installer/install/tools/upgrade# chmod 777 R /home/womcb (for RNC)# chmod 777 -R /home/gomcb(for BSC)# chmod 777 -R /home/gomcb/*# ./upgrade.sh update copy /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../temp/silence-setup.properties to /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../../../bin/silence-setup.properties.It will delete Old omc and db,are you sure to continue?(y/n):y//Start the upgrade when the operation is confirmed. begin to update...Succeeded in installing OMMB by silence installation.//Now OMMB is successfully installed. If the following prompt appears, it means the backup has not been made yet. In this case, it is necessary to perform the operations in Section 5.2 first. /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../temp/silence-setup.properties not exists.Please backup firstly and put backup.tar.gz and silence-setup.properties to /home/OMMB-Installer/Installer/install/tools/upgrade/tempIf OMCB is installed as user gomcb, after the installation succeeds, it is necessary to execute the following commands to change the owner of the OMM directory back to gomcb (modify the part in red to the actual directory). # chown gomcb:gomcb -R /home/gomcb/ZX-OMMBStarting OMMB This section introduces the following contents: restoring Logservice auto-start, modifying Logservice configuration path, starting OMMB, and mapping port. Restoring Logservice Auto-startFor Logservice, execute the following command: #sed -i 's/#\/home\/zte\/logservice\/bin\/startsys/\/home\/zte\/logservice\/bin\/startsys/g' /etc/rc.localFor OmmHost, execute the following command: #sed -i 's/#\/home\/zte\/OmmHost\/bin\/startsys/\/home\/zte\/OmmHost\/bin\/startsys/g' /etc/rc.localModifying Logservice Configuration Path For logservice, modify the OMMB execution path in the /home/zte/logservice/bin/conf/OmmProcConfig.conf file by adding the ums layer. ExePath = /home/ZX-OMMB/ums/ums-svr/bin/For OmmHost, modify the OMMB execution path in the /home/zte/OmmHost/bin/conf/OmmProcConfig.conf file by adding the ums layer. ExePath = /home/ZX-OMMB/ums/ums-svr/bin/Starting OMMB For Logservice, execute the following command: #cd /home/zte/logservice/bin/#sh startsysFor OmmHost, execute the following command: #cd /home/zte/OmmHost/bin/#sh startsysIf no logservice/OmmHost exists, directly start the OMMB (by entering the OMMB installation directory). #sh ums/ums-svr/bin/console-linux.shMapping PortIf the OMCB uses V4.09, port mapping is required. (The $NE_IP refers to the internal network IP, which can be viewed in the configuration center on OMMB; the $NET_CARD refers to the net card of the internal network, which can be viewed with ifconfig.) # sh install/bin/linux-config.sh//Enter the configuration center to view the internal network IP. # ifconfig//View the IP and net card name. # iptables -t nat -I PREROUTING -p tcp --dport 21 -d $NE_IP -i $NET_CARD -j DNAT --to-destination $NE_IP:64021//Here colon is not required for NET_CARD. # iptables-save >/etc/sysconfig/iptablesImporting Configuration DataPerform this operation on the client of OMMB.1.Prepare data. For the upgrade of different versions, the SDR configuration data to be prepared is also different. In the following scenarios, copy the corresponding data to the /home/data directory on the Client according to the following description. Upgrade of V4.11 Series:The upgrade of V4.11series falls into two cases:If the SDRs of OMCB V4.11 need to be managed by OMMBV12.12.40P29, copy the data before the conversion, i.e. the backup data acquired in Chapter 5.1. If the SDRs of OMCB V4.11 do not need to be managed by OMMB V12.12.40P29, copy the converted configuration data in Chapter 6. 2.Import configuration data. Choose Configuration Management > Data Import, and select the configuration data prepared in the /home/data directory in the following dialog box.

To import the configuration of V4.11, in the pop-up NE Version Select window select the version according to the data imported, as shown in the figure below.

Back up data before performing the operationMake sure the check box is unselected.Select an NE version. The version should be selected according the version information of the data, i.e., if the configuration data has not been converted, select V4.11.For the converted data, the NE Version Select interface will not pop up. Click Import. After the import finishes, the link between the SDR and OMMB can be established normally. At this time the OMMB version is V12.12.40P29 and the SDR is in the old version.If there is some problem in the importing process, refer to Section A.3.Creating EMS Agent Stop the old agent first (it can be deleted after OMMB runs stably), and then create and start the new agent. Refer to Section A.6 for the detailed operations. Cold Backup ScenarioIn the cold backup scenario, except the Generating Mirror Data step, the following upgrade procedure is the same as that in the single-server scenario. Generating Mirror Data This section describes the operation steps performed on the standby board of the cold backup. These steps are used to copy the operation environment and configuration data on the active board to the standby board. PreparationCompare the following information between the active board and the standby board. If the information on them is inconsistent, modify the data and make sure the information is consistent on these two boards.Note: After the laptop is connected to the standby board, it is required that the IP be configured on the standby board in advance and the IP can be queried with the ifconfig command successfully. However, because the standby board is not connected to the internal/external network at this time, the IP can only be pinged through on the laptop but cannot be pinged through from the external network. 1.Network Configurationi.IPCheck ItemsChecking Method (as the root user)

eth4 IPifconfig eth4

eth4:1 IPifconfig eth4:1

eth6 IPifconfig eth6

eth6:1 IP and routeifconfig eth6:1, route -n

eth6:2 IP and routeifconfig eth6:2, route -n

ii.Network configuration fileCheck ItemsChecking Method (as the root user)

/etc/hosts gedit /etc/hosts

/etc/sysconfig/network The hostname in the gedit /etc/sysconfig/network file should be consistent with the hostname in the host file.

Check port mapping.iptables t nat L

2.ORACLE_SIDCheck ItemsChecking Method (as the root user)

ORACLE_SIDenv | grep ORACLE_SID

The ORACLE_SID on the active board and the standby board should be kept consistent. If it does not exist on the standby board, create this instance first. 3.Check network service name:Execute the following commands on the active board and the standby board respectively, and compare the execution result. Modify the SID and the network service name on the standby board the same as those used by OMCB on the active board.#cd $ORACLE_HOME/network/admin#cat tnsnames.ora 4.Check Logservice. Refer to A.9, and check and restore Logservice according to the scenarios in the following table. ScenarioLogservice on the Active Board Logservice on the Standby Board Operations

1Installed Installed None

2Installed Not installed Install Logservice on the standby board and it is not necessary to configure it.

3Not installed Installed Configure the OMMB process, LogNetIf, and Netif of the standby board. Refer to the Logservice installation guide for details.

4Not installed Not installed None

Uploading Data Upload the backup.tar.gz, silence-setup.properties, and log_conf.tar.gz backup files generated on the active board to the /home/OMMB-Installer/Installer/install/tools/upgrade/temp/ directory of the standby board. Generating Mirror Data Execute the following commands on the standby board to generate the mirror data. # cd /home/OMMB-Installer/Installer/install/tools/upgrade# ./upgrade.sh restore Begin to do mirror OMMB.Please ensure that OMMB being upgraded is not running.If there are OMMB processes running, stop them firstly.Continue(Y/N)?YPlease wait...End up restoring OMMB.//This prompt means the operation succeeds. At this time, OMMB is stopped. If the following prompt appears, it means the mirror file copied from the active board is not found. /../temp/silence-setup.properties not found.put it here.//The upgrade/temp/silence-setup.properties file is not found. /../temp/backup.tar.gz not exists. Restore is not suppported because of no backup executed before.//The upgrade/temp/backup.tar.gz file is not found. Stopping NE Agent on EMS The corresponding NE agent on the EMS must be stopped before the upgrade. Refer to A.6.3 for the operation method. InstallationExecute the following command on the standby board to stop OMCB (if OMMB on the standby board has been started), and Logservice and its auto-start function, and then install the OMMB. #cd /home/OMMB-Installer/Installer/install/tools/upgrade#./upgrade.sh update copy /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../temp/silence-setup.properties to /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../../../bin/silence-setup.properties.It will delete Old omc and db,are you sure to continue?(y/n):y//Start the upgrade when the operation is confirmed. begin to update...Succeeded in installing OMMB by silence installation.//Now OMMB is successfully installed. The following prompt means, the mirror file is not copied to the standby board. /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../temp/silence-setup.properties not exists.Please backup firstly and put backup.tar.gz and silence-setup.properties to /home/OMMB-Installer/Installer/install/tools/upgrade/tempIf OMCB is installed as user gomcb, after the installation succeeds, it is necessary to execute the following commands to change the owner of the OMM directory back to gomcb (modify the part in red to the actual directory). # chown gomcb:gomcb -R /home/gomcb/ZX-OMMBStarting OMMB Carry out the following operations: restoring logservice auto-start, modifying Logservice configuration, starting OMMB, and mapping the port. Restoring Logservice Auto-startFor Logservice, execute the following command: #sed -i 's/#\/home\/zte\/logservice\/bin\/startsys/\/home\/zte\/logservice\/bin\/startsys/g' /etc/rc.localFor OmmHost, execute the following command: #sed -i 's/#\/home\/zte\/OmmHost\/bin\/startsys/\/home\/zte\/OmmHost\/bin\/startsys/g' /etc/rc.localModifying Logservice Configuration Path For logservice, modify the OMMB execution path in the /home/zte/logservice/bin/conf/OmmProcConfig.conf file by adding the ums layer. ExePath = /home/ZX-OMMB/ums/ums-svr/bin/For OmmHost, modify the OMMB execution path in the /home/zte/OmmHost/bin/conf/OmmProcConfig.conf file by adding the ums layer. ExePath = /home/ZX-OMMB/ums/ums-svr/bin/Starting OMMB For Logservice, execute the following command: #cd /home/zte/logservice/bin/#sh startsysFor OmmHost, execute the following command: #cd /home/zte/OmmHost/bin/#sh startsysIf no logservice/OmmHost exists, directly start the OMMB (by entering the OMMB installation directory). #sh ums/ums-svr/bin/console-linux.shMapping PortIf the OMCB uses V4.09, port mapping is required. (The $NE_IP refers to the internal network IP, which can be viewed in the configuration center on OMMB; the $NET_CARD refers to the net card of the internal network, which can be viewed with ifconfig.)# sh install/bin/linux-config.sh//Enter the configuration center to view the internal network IP. # ifconfig//View the IP and net card name. # iptables -t nat -I PREROUTING -p tcp --dport 21 -d $NE_IP -i $NET_CARD -j DNAT --to-destination $NE_IP:64021//Here colon is not required for NET_CARD. # iptables-save >/etc/sysconfig/iptables

Importing Configuration DataPerform this operation on the client of OMMB.1.Prepare data. For the upgrade of different versions, the SDR configuration data to be prepared is also different. In the following scenarios, copy the corresponding data to the /home/data directory on the Client according to the following description. Upgrade of V4.11 Series:The upgrade of V4.11series falls into two cases:If the SDRs of OMCB V4.11 need to be managed by OMMBV12.12.40P29, copy the data before the conversion, i.e. the backup data acquired in Chapter 5.1. If the SDRs of OMCB V4.11 do not need to be managed by OMMB V12.12.40P29, copy the converted configuration data in Chapter 6. 2.Import configuration data. Choose Configuration Management > Data Import, and select the configuration data prepared in the /home/data directory in the following dialog box.

To import the configuration of V4.11, in the pop-up NE Version Select window select the version according to the data imported, as shown in the figure below.

Back up data before performing the operationMake sure the check box is unselected.Select an NE version. The version should be selected according the version information of the data, i.e., if the configuration data has not been converted, select V4.11.For the converted data, the NE Version Select interface will not pop up. Click Import. After the import finishes, the link between the SDR and OMMB can be established normally. At this time the OMMB version is V12.12.40P29 and the SDR is in the old version.If there is some problem in the importing process, refer to Section A.3.Creating EMS Agent Create and start the new agent. Refer to A.6 for the operation details. Do not delete the old agent temporarily, so as to keep the alarm and performance data of EMS. Active/Standby Board ChangeoverAfter the standby board is upgraded successfully, plug out the active board and plug in the standby board, and then start OMMB. For Logservice, execute the following command: #cd /home/zte/logservice/bin/# sh startsys For OmmHost, execute the following command: #cd /home/zte/OmmHost/bin/#sh startsysIf no Logservice/OmmHost exists, directly start the OMMB (by entering the OMMB installation directory). #sh ums/ums-svr/bin/console-linux.shActive/Standby Boards in Hot Backup The procedure is: upgrade the slave board > suspend the EMS on the master board > start the EMS on the slave board > import the configuration data > upgrade the master board Stopping NE Agent on EMS The corresponding NE agent on the EMS must be stopped before the upgrade. Refer to A.6.3 for the operation method. Installing OMMB on the Standby Board Execute the following command on the standby board to stop the EMS, and logservice and its auto-start function, and then install OMMB. #cd /home/OMMB-Installer/Installer/install/tools/upgrade#./upgrade.sh update copy /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../temp/silence-setup.properties to /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../../../bin/silence-setup.properties.It will delete Old omc and db,are you sure to continue?(y/n):y//Start the upgrade when the operation is confirmed. begin to update...Succeeded in installing OMMB by silence installation.//Now OMMB is successfully installed. If the following prompt appears, it means the backup has not been made yet. In this case, it is necessary to perform the operations in Section 5.2 first. /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../temp/silence-setup.properties not exists.Please backup firstly and put backup.tar.gz and silence-setup.properties to /home/OMMB-Installer/Installer/install/tools/upgrade/tempStopping OMMB on the Active BoardBefore starting OMMB on the standby board, stop OMCB and the Logservice auto-start function on the active board. Stop the OMMB on the active board. For Logservice, execute the following commands. #cd /home/zte/logservice/bin# ./stopsys For OmmHost, execute the following commands. #cd /home/zte/OmmHost/bin# ./stopsysDisable Logservice auto-start on the active board with the following command. # sed -i 's/\/home\/zte\/logservice\/bin\/startsys/#\/home\/zte\/logservice\/bin\/startsys/g' /etc/rc.localDisable OmmHost auto-start on the active board with the following command. # sed -i 's/\/home\/zte\/OmmHost\/bin\/startsys/#\/home\/zte\/OmmHost\/bin\/startsys/g' /etc/rc.localStarting OMMB on the Standby Board Carry out operations on the slave board, including restoring logservice auto-start, modifying Logservice configuration, starting OMMB, and mapping the port. Restoring Logservice Auto-startFor Logservice, execute the following command: #sed -i 's/#\/home\/zte\/logservice\/bin\/startsys/\/home\/zte\/logservice\/bin\/startsys/g' /etc/rc.localFor OmmHost, execute the following command: #sed -i 's/#\/home\/zte\/OmmHost\/bin\/startsys/\/home\/zte\/OmmHost\/bin\/startsys/g' /etc/rc.localModifying Logservice Configuration Path For logservice, modify the OMMB execution path in the /home/zte/logservice/bin/conf/OmmProcConfig.conf file by adding the ums layer. ExePath = /home/ZX-OMMB/ums/ums-svr/bin/For OmmHost, modify the OMMB execution path in the /home/zte/OmmHost/bin/conf/OmmProcConfig.conf file by adding the ums layer. ExePath = /home/ZX-OMMB/ums/ums-svr/bin/Starting OMMB For Logservice, execute the following command: #cd /home/zte/logservice/bin/# sh startsys For OmmHost, execute the following command: #cd /home/zte/OmmHost/bin/#sh startsysIf no logservice/OmmHost exists, directly start the OMMB (by entering the OMMB installation directory). #sh ums/ums-svr/bin/console-linux.shMapping PortIf the OMCB uses V4.09, port mapping is required. (The $NE_IP refers to the internal network IP, which can be viewed in the configuration center on OMMB; the $NET_CARD refers to the net card of the internal network, which can be viewed with ifconfig.) # sh install/bin/linux-config.sh//Enter the configuration center to view the internal network IP. # ifconfig//View the IP and net card name. # iptables -t nat -I PREROUTING -p tcp --dport 21 -d $NE_IP -i $NET_CARD -j DNAT --to-destination $NE_IP:64021//Here colon is not required for NET_CARD. # iptables-save >/etc/sysconfig/iptablesImporting Configuration DataPerform this operation on the client of OMMB.1.Prepare data. For the upgrade of different versions, the SDR configuration data to be prepared is also different. In the following scenarios, copy the corresponding data to the /home/data directory on the Client according to the following description. Upgrade of V4.11 Series:The upgrade of V4.11series falls into two cases:If the SDRs of OMCB V4.11 need to be managed by OMMB V12.12.40P29, copy the data before the conversion, i.e. the backup data acquired in Chapter 5.1. If the SDRs of OMCB V4.11 do not need to be managed by OMMB V12.12.40P29, copy the converted configuration data in Chapter 6. 2.Import configuration data. Choose Configuration Management > Data Import, and select the configuration data prepared in the /home/data directory in the following dialog box.

To import the configuration of V4.11, in the pop-up NE Version Select window select the version according to the data imported, as shown in the figure below.

Back up data before performing the operationMake sure the check box is unselected.Select an NE version. The version should be selected according the version information of the data, i.e., if the configuration data has not been converted, select V4.11.For the converted data, the NE Version Select interface will not pop up. Click Import. After the import finishes, the link between the SDR and OMMB can be established normally. At this time the OMMB version is V12.12.40P29 and the SDR is in the old version.If there is some problem in the importing process, refer to Section A.3. Must check the Oracle database after importing Xml file and if disk space is require then do the alteration Creating EMS Agent Stop the old agent first (it can be deleted after OMMB runs stably), and then create and start the new agent. Refer to Section A.6 for the detailed operations. Upgrading the Original Master SBCXAfter the upgrade is completed and the services return to normal, upgrade the original master board. Execute the following command on the original master board. Read the OMCB configuration on the original master board. Warning: Do not execute ./upgrade.sh backup here. # cd /home/OMMB-Installer/Installer/install/tools/upgrade# ./upgrade.sh readOmcbInfobegin to readOMCBInfoExOmc path is found as follows:=========================================================================1 : /home/ZX-OMMB=========================================================================Which one is Old omc path?(input your choice):1Old omc dir is /home/ZX-OMMBORACLE_SID read from omc is ommbPlease input correct system's password of oracle database:oracle

Make sure the following information:====================================================================System's password of oracle database is [oracle]====================================================================Enter 'y' to continue,'n' to cancel:ybegin to exec perllogserviceType is RAP300procType is 4101begin to isRBsplited/home/ZX-OMMB/ums-svr/deploy/deploy-999split.properties exists.end up at isRBsplitedend up at readOMCBInfoEx

# ./upgrade.sh update copy /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../temp/silence-setup.properties to /home/OMMB-Installer/Installer/install/tools/upgrade/conf/../../../bin/silence-setup.properties.It will delete Old omc and db,are you sure to continue?(y/n):y//Start the upgrade when the operation is confirmed. begin to update...Succeeded in installing OMMB by silence installation.//Now OMMB is successfully installed. After OMMB is successfully installed, synchronize the data from the master board to the slave board (i.e. synchronize data from the original slave board to the original master board). Execute the following command on the master board (i.e. the original slave board): (enter the OMMB installation directory. # cd ums-svr/tools/backup# sh dbsync-linux.sh oracle //oracle is the password to the system account of the database. 2013-10-14 11:00:39,605 INFO [DBSyncProcess] Welcome to use the database synchronise tool.2013-10-14 11:00:39,606 INFO [DBSyncProcess] 1. Synchronise all tables which configed by the tableConfig-dbsync*.properties.2013-10-14 11:00:39,606 INFO [DBSyncProcess] 2. Synchronise the history tables of Fault Management(FM) and Performance Management(PM)2013-10-14 11:00:39,607 INFO [DBSyncProcess] 3. Synchronise the Performance Management(PM) file2013-10-14 11:00:39,607 INFO [DBSyncProcess] 4. Compare the local database data and the remote.2013-10-14 11:00:39,607 INFO [DBSyncProcess] Please select 1 , 2 , 3 or 4:1//Input 1 here and perform all-data synchronization. After the all-data synchronization is finished, execute the following commands to confirm whether the data on the active board and the standby board are successfully synchronized. #sh dbsync-linux.sh oracle2013-10-14 11:03:02,038 INFO [DBSyncProcess] Please select 1 , 2 , 3 or 4:4//Select 4 for comparison. 2013-10-14 11:03:05,016 INFO [DBSyncProcess] 1. Only Compare one table2013-10-14 11:03:05,017 INFO [DBSyncProcess] 2. Compare all the tables2013-10-14 11:03:05,017 INFO [DBSyncProcess] Please select 1 or 2:2//Select 2 for all-data comparison. 2013-10-14 11:03:09,721 INFO [DBSyncProcess] The localIP:128.0.29.12013-10-14 11:03:09,722 INFO [DBSyncProcess] The remoteIP:128.0.29.9There are 134 same tables and 0 different tables .//It means the data on the master board are exactly the same as those on the slave board.Starting the New OMMB on the Original Active Board Carry out the operations on the original master board, including restoring Logservice auto-start, modifying Logservice configuration, starting OMMB, and mapping the port. Restoring Logservice Auto-startFor Logservice, execute the following command: #sed -i 's/#\/home\/zte\/logservice\/bin\/startsys/\/home\/zte\/logservice\/bin\/startsys/g' /etc/rc.localFor OmmHost, execute the following command: #sed -i 's/#\/home\/zte\/OmmHost\/bin\/startsys/\/home\/zte\/OmmHost\/bin\/startsys/g' /etc/rc.localModifying Logservice Configuration Path For logservice, modify the OMMB execution path in the /home/zte/logservice/bin/conf/OmmProcConfig.conf file by adding the ums layer. ExePath = /home/ZX-OMMB/ums/ums-svr/bin/For OmmHost, modify the OMMB execution path in the /home/zte/OmmHost/bin/conf/OmmProcConfig.conf file by adding the ums layer. ExePath = /home/ZX-OMMB/ums/ums-svr/bin/Starting OMMB For Logservice, execute the following command: #cd /home/zte/logservice/bin/#sh startsysFor OmmHost, execute the following command: #cd /home/zte/OmmHost/bin/#sh startsysIf no logservice/OmmHost exists, directly start the OMMB (by entering the OMMB installation directory). #sh ums/ums-svr/bin/console-linux.shMapping PortIf the OMCB uses V4.09, port mapping is required. (The $NE_IP refers to the internal network IP, which can be viewed in the configuration center on OMMB; the $NET_CARD refers to the net card of the internal network, which can be viewed with ifconfig.) # sh install/bin/linux-config.sh//Enter the configuration center to view the internal network IP. # ifconfig//View the IP and net card name. # iptables -t nat -I PREROUTING -p tcp --dport 21 -d $NE_IP -i $NET_CARD -j DNAT --to-destination $NE_IP:64021//Here colon is not required for NET_CARD. # iptables-save >/etc/sysconfig/iptables

VerificationVerifying OMMB After OMMB upgrade, it is necessary to check whether the link establishment status between OMMB and SDR, configuration management, alarms, dynamic query, performance data reporting, and software version management are normal.Verifying SDR After the upgrade we need to restore the previously-cancelled alarm filter rules, cell block status, and site commissioning status. After this, extract the corresponding KPIs from OMMB and perform checks and verifications, so as to make sure that the upgrade is normal and the system is normal. This is to provide the data for version rollback.Checking Status1.Alarm comparisonExport the real-time alarms, and compare them with the alarm information recorded before the upgrade. If there is no new alarm, this item can pass the check.2.Link statusExport the link status, and compare it with the link status recorded before the upgrade. If the link status is consistent before and after the upgrade, this item can pass the check.3.Cell statusExport the cell status, and compare it with the cell status recorded before the upgrade. If the cell status is consistent before and after the upgrade or it is normal after the upgrade, this item can pass the check.Monitoring Performance1.Start performance measurement.In EMS Performance Management, check whether the SDR measurement task status is consistent and activated. If it is not activated, right-click the measurement task to perform manual activation. If the measurement task status is not consistent, perform manual synchronization.2.Trace the KPIs in one or two hours after the upgrade. Make sure there is no abnormal fluctuation in KPIs, and then start tracing the major KPIs. If any problem occurs during the KPI tracing, we need to check whether the problem can exert serious impact on the system, and whether version rollback is necessary.UMTS KPIsNE typeObject TypeKPI Name

RNCCellNumber of RRC Connection Establishment Attempts

RNC CS RAB Establishment Success Rate

RNC PS RAB Establishment Success Rate

RNC Radio CS Call Drop Rate

RNC Radio PS Call Drop Rate

RNC Radio Call Drop Rate

Number of Soft Handover Attempts

RNC Soft Handover Success Rate

RNC RAB Establishment Success Rate

RRC Connection Establishment Success Rate

Important UMTS KPIsNE typeObject TypeKPI Name

RNCCellNumber of RRC Connection Establishment Attempts

RNC CS RAB Establishment Success Rate

RNC PS RAB Establishment Success Rate

RNC Radio CS Call Drop Rate

RNC Radio PS Call Drop Rate

RNC Radio Call Drop Rate

Number of Soft Handover Attempts

RNC Soft Handover Success Rate

Intra-RNC Co-Frequency Hard HO Success Rate

Number of Intra-RNC Co-Frequency Hard HO Attempts

Inter-RNC Co-Frequency Hard HO Success Rate

Number of Cross-Iur Inter-RNC Co-Frequency Hard HO Attempts

Intra-RNC Hetero-Frequency Hard HO Success Rate

Number of Intra-RNC Hetero-Frequency Hard HO Attempts

Inter-RNC Hetero-Frequency Hard HO Success Rate

Number of Cross-Iur Inter-RNC Hetero-Frequency Hard HO Attempts

RNC RAB Establishment Success Rate

RRC Connection Establishment Success Rate

HSDPA CS call drop rate

HSUPA PS Call Drop Rate

RollbackIf some problem is found in the verification process, we can roll back either the SDR or both the SDR and the OMMB according to the on-site requirement. The system status after the rollback should be consistent with that before the upgrade.If only SDR rollback is performed, the OMMB configuration can remain unchanged because OMMB is compatible with OMCB V4.11. SDR Rollback 1.Roll back a task. i.Click View > Software Version Management > Special Task Management. ii.Click the button to create the upgrade task, as shown in the figure below. In the Create Roll Back Package Task window (Window 1 on the left), select the target NE. iii.Click OK, and the task will be executed immediately.

2.Query the download result. i.Click Query Task Management. ii.Click the button to create the query task, as shown in the figure below. In the Create Version Query Task window (Window 1 on the left), select the target NE. iii.Click OK, and the query task will be executed immediately. iv.After the execution is completed, query version package state in Window 2, and make sure the SDR is of V4.11.10.14p03 and is running.

3.Roll back configuration data. Delete the configuration of OMMB V12.12.40P29 and import the configuration of OMCB V4.11. 4.Restore link. After the version rollback, the link will be established automatically within 15 minutes. If the link needs to be restored immediately, refer to Section A.8 for the method. OMMB Rollback 1.Roll back OMMB.Perform this operation on the standby board of the hot backup or the single server scenario. For the cold backup scenario, replace SBCX directly. Note: The following rollback command will stop OMMB services automatically, so it is not necessary to stop OMMB manually. # cd /home/OMMB-Installer/Installer/install/tools/upgrade# ./upgrade.sh rollbackEnd up rollback OMMB.//This prompt means the restoration succeeds. At this time, OMMB is stopped. If the OMCB is of V4.09, it is necessary to delete the port mapping (The $NE_IP refers to the internal network IP; the $NET_CARD refers to the net card of the internal network, which can be viewed with ifconfig). # iptables -t nat -D PREROUTING -p tcp --dport 21 -d $NE_IP -i $NET_CARD -j DNAT --to-destination $NE_IP:64021# iptables-save >/etc/sysconfig/iptablesExecute the following command to view the mapping records. # iptables t nat -LIf the mapping of 21 to 64021 cannot be found, it means the mapping is deleted successfully. If OMCB is installed as the gomcb user, it is necessary to execute the following command after the rollback is completed (/home/gomcb/ZX-OMMB is the directory of OMCB). # chown gomcb -R /home/gomcb/ZX-OMMB2.Roll back EMS agent.Refer to A.6 for the detailed operations.

Re-upgrade If the version needs to be upgraded again after the upgrade, refer to Chapters 7-9. AppendixEXP-00091 Message Prompted in the Backup Process If there is EXP-00091:Exporting questionable statistics in the print of the exported database in the backup process, this can be ignored. This information is caused by the inconsistency of NLS_CHARACTERSET between NLS_LANG and DB in the environment variable of the exp tool. OMMB Startup Failure After the Execution of ./upgrade.sh restore (Cold Backup) Because the IP of the standby board is not consistent with the IP of the active board in the cold backup scenario, OMMB IP cannot be started with the IP of the active board. Make sure these IPs are consistent before the upgrade. Configuration Data Importing ErrorThe following information is prompted when the configuration data is imported: start ommb successfully.perl /home/wl/12.12.40P29/Installer/install/tools/upgrade/conf/update/CmDataImport.pl /home/wl/12.12.40P29/Installer/ -import cmdata failed, goto /home/ZX-OMMB/ums/ums-svr/cmdata/cmimport/fail to get files.The failure file will be stored under the /ums-svr/cmdata/cmimport/fail directory of OMMB. Check whether there is some configuration error in the file, and convert the data with the conversion tool to find out the cause of the error. Conversion ErrorIf there is some error in the conversion process, please contact the R&D engineers. The following are some possible errors, which can be located by field engineers. 1.If there is the groovy error, the groovy check error, Please check message from 'More information for groovy and static check information will be displayed on the interface.

Double-click the More information for groovy and static check button, and the following window will pop up.

If it is necessary to view the details of all groovy errors, perform the operations shown in the above figure. Field engineers can either modify the source configuration files according to the error information or send the error information to the support engineers for troubleshooting. 2.If the Please check the original file ObjItf :Head file property omcVersion is start with ZXOMCBV4.09.21.08, not ZXOMCBV4.11.10.14P06 error is prompted after the conversion, open the source configuration file and check whether the Source Version converted is correct according to the prompt. 3.If the system prompts the Size < 20KB :The Size of file Subnetwork301_ManagedElement115.xml is Illegal ,Please check if it is empty or Lost some messager error, check whether the data is complete. In most cases, this error is caused by incomplete configuration data. 4.For null point exception or other errors, the possible causes include incorrect source version and upgrade tool conversion error. If the version is incorrect, select the correct version and perform conversion again. If the error is caused by the upgrade tool, send the raw data and the log (such as ommb.txt.*) under the *\ZXOMCBSmoothToo\ZXOMMBSmoothTool directory to the R&D engineers for troubleshooting. 5.After ZXOMMBSmoothTool.jar or runWindowsGUI.bat is clicked, they fail to run normally: check whether JRE is installed. Database Restoration Failure During Standby Board RestorationIn the cold backup scenarios, when the current active board is restored, if the SID or password typed in is incorrect, or the sid_127.0.0.1 network service name does not exist, database restoration failure will occur. At this time the version has been restored successfully. To avoid restoring data from the very beginning, start the restoration from database restoration, i.e., execute the following command../upgrade.sh DBRestoreEMS AgentCreating Upgrade Agent Create MO SDR NE agent.

In the following window, except Name (modification not recommended), other parameters should be kept consistent with those of the original OMCB NE agent.

Deleting the Old Agent

Stop the Old Agent

Starting the New Agent

Method of Setting JAVA_HOME in Windows OS JDK1.6 series are built in OMMB. Perform the following steps to set JAVA_HOME. Right-click My Computer > Properties > Advanced > Environment Variables > System Variables > PATH, and Edit to modify the value of the variable, and add the jdk path after the variable. The jdk path is OMMB directory\jdk-windows\bin. Then, click OK and exit. Link Restoration After Rollback After the version rollback, the link will be established automatically within 15 minutes. If the link needs to be restored immediately, perform the following operations: Click View > MML Terminal to open the MML terminal and type in the following two commands: Command 1: APPLY MUTEXRIGHT:SUBNET="X",NE="Y";Command 2: UPDATE:MOC="NEManagedElement",MOI="SubNetwork=X,MEID=Y",ATTRIBUTES="ExtendField1=2";(X and Y represent subnetwork and MEID respectively)

Method of Distinguishing Logservice/OmmhostExecute the following commands to check whether Logservice or OmmHost is used currently: Use the following commands to see whether Logservice is installed. #ls /home/zte/logservice/binAGLogProc conf MoAdaptProcSyb mostart.sh rmtlogstopsys startmodule.pl stopproc WLogProcautogather GLogProc mo_rnc_syncgsm.xml mostop.sh run startproc stopsysCommonLogProc gsm_mo_table.xml mo_rnc_table_gsm.xml mo_sync_gsm.xml sbcx startsys SysCtrlProcCommProc MoAdaptProcOcl mo_rule_gsm.xml rmtlogstartsys setup stopmodule.pl TDLogProc////If this directory exists, it means Logservice is installed. If the directory does not exist, it means Logservice is not installed. Execute the following commands to see whether OmmHost is installed: #ls /home/zte/OmmHost/binAGLogProc conf MoAdaptProcSyb mostart.sh rmtlogstopsys startmodule.pl stopproc WLogProcautogather GLogProc mo_rnc_syncgsm.xml mostop.sh run startproc stopsysCommonLogProc gsm_mo_table.xml mo_rnc_table_gsm.xml mo_sync_gsm.xml sbcx startsys SysCtrlProcCommProc MoAdaptProcOcl mo_rule_gsm.xml rmtlogstartsys setup stopmodule.pl TDLogProc////If this directory exists, it means OmmHost is installed. If the directory does not exist, it means OmmHost is not installed. 1ZTE Confidential Proprietary

28 2015ZTE CORPORATION. All rights reserved.ZTE Confidential Proprietary