ZXUN USPP. Configuration Management Description. Universal Subscriber Profile Platform. Version: V

Transcription

1 ZXUN USPP Universal Subscriber Profile Platform Configuration Management Description Version: V ZTE CORPORATION No. 55, Hi-tech Road South, ShenZhen, P.R.China Postcode: Tel: Fax: URL:

2 LEGAL INFORMATION Copyright 2014 ZTE CORPORATION. The contents of this document are protected by copyright laws and international treaties. Any reproduction or distribution 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. Additionally, the contents of this document are protected by contractual confidentiality obligations. All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE CORPORATION or of their respective owners. This document is provided as is, and all express, implied, or statutory warranties, representations or conditions are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose, title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the use of or reliance on the information contained herein. ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications covering the subject matter of this document. Except as expressly provided in any written license between ZTE CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter herein. ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice. Users may visit the ZTE technical support website to inquire for related information. The ultimate right to interpret this product resides in ZTE CORPORATION. Revision History Revision No. Revision Date Revision Reason R First edition Serial Number: SJ Publishing Date: (R1.0)

3 Contents Chapter 1 Configuration Management Overview Configuration Data Composition Configuration Scenarios Data Configuration Methods Database Configuration Chapter 2 Configuration Management Principles Software Structure Data Storage Mechanism Data Loading Mechanism Data Synchronization Mechanism Chapter 3 Data Management Mechanism Data Transfer and Rollback Data Backup and Recovery Data Configuration Precautions Glossary... I I

4 This page intentionally left blank. II

5 Chapter 1 Configuration Management Overview The configuration management function provided by the ZXUN USPP enables the configuration of data required by network elements. After receiving a configuration request from an OMM client (back-end network element management system), the system checks validity of the data in the request. After saving the correct data into the in-memory database (the OMP board) of the front-end network element, this system returns the configuration result to the OMM client (back-end network element management system). This function is described as follows: Supports multiple configuration channel accesses. Parses the formats of configuration requests. Distributes configuration requests. Supports application registration configuration commands, and is responsible for command management. Provides the storage and loading of configuration scripts. Table of Contents Configuration Data Composition Configuration Scenarios Data Configuration Methods Database Configuration Configuration Data Composition Overview Data configuration refers to operations such as providing data for normal operation of communications equipment, and setting the data for the equipment. The ZXUN USPP provides adding, deletion, modification, query, saving, backup, and recovery operations for you to effectively manage and maintain various system operation data (for example, hardware data, signaling data, route data, number analysis data, and mobile service data). Configuration Data Range The configuration data of the ZXUN USPP includes basic data, protocol stack data, interconnection data, and service data. 1-1

6 ZXUN USPP Configuration Management Description Basic data The basic data consists of two parts, physical data and local office data, and is the basis of the ZXUN USPP configuration data. The basic data is mainly used to define global network element data. After the basic data configuration, the ZXUN USPP has software logic, and can provide communication services for network entities. Key parameters defined by physical data include the module IDs and unit IDs of the board configuration modules. The module number of a board is an important parameter. This parameter will be used in the subsequent configuration processes multiple times. If you want to modify the module number of a module, you must first delete all data tables that already use this module number. Key parameters defined for the local office include the signaling addresses or host addresses of the local office and the adjacent office. The key parameters will be used in subsequent data configuration processes. After you create a key parameter by using a data configuration command, the key parameter cannot be deleted or modified in the subsequent data configuration processes due to the limitation of the database storage process. Therefore, you must attach great importance to the basic data planning. The basic data should make the database easy to manage and maintain, and the system easy to expand, or the database easy to extend during software upgrade. Protocol stack data Protocol stack configuration is used to configure the real-interface addresses, loopback interface addresses, routes, aggregate ports, subinterfaces, and VRFs bound to interfaces for interconnecting the USPP and other NEs. Interconnection data The interconnection data is an important part of the ZXUN USPP configuration data. It defines the signaling, protocol, trunk, and other information for the interconnection of the ZXUN USPP with another network element, for example, MTP data, M3UA data, SCCP data, and Diameter data. Interconnection data configuration is the necessary prerequisite for the carrier before carrying out different services through the ZXUN USPP. Because of the complexity of the networking structure, the configuration flow of interconnection data varies with the networking condition. To reduce the complexity of data configuration and improve software debugging efficiency, you should first divide the complicated networking structure into multiple independent networking units before configuring the interconnection data. After division, you can perform data configuration based on the configuration steps and example in the corresponding networking scenario. Service data Service data configuration is the ultimate expression of services and functions that the carrier carries out through the ZXUN USPP. It also indicate operation contents in daily maintenance. 1-2

7 1.2 Configuration Scenarios Chapter 1 Configuration Management Overview The ZXUN USPP supports the following data configuration scenarios: Initial configuration during office creation phase: Global data configuration is required. When an office is created, initial data configuration is required to activate system services after the hardware installation, software installation, initial acceptance, final acceptance, and delivery. Configuration adjustment during maintenance phase: Local data must be added or modified due to network parameter changes (such as newly-added network elements, links, or expanded capacity). After the equipment is successfully operating in the network, configuration adjustment is required during daily maintenance when the system resources are not enough, circuits and links are not enough or loaded, or office routes are not balanced. 1.3 Data Configuration Methods Overview Based on operation types, the data configuration methods of the ZXUN USPP are classified as follows: MML command configuration This type of method refers to the configuration of a command on the MML command interface. It is the most commonly used configuration method. All configurations can be done with this method. Script file configuration This type of method is also called script configuration. It saves the configuration data into scripts, and you only need to execute these scripts for data configuration. MML Command Configuration The MML command configuration supports both offline and online configuration. Operators can configure data in two ways in accordance with the configuration types. Offline configuration Offline configuration refers to data configuration on the UMM/OMM without a link between the OMP module and the OMM. Other data except IP protocol stack data is configured off line. After being configured, the data must be synchronized. Online configuration Online configuration refers to configuring the interface IP address and route on the OMM when a link is established between the OMP module and the OMM. With online 1-3

8 ZXUN USPP Configuration Management Description configuration, the interface IP address and route information take effect without synchronization. IP protocol stack data must be configured on line. Script File Configuration Script configuration refers to configuring offline data in batches by using a script file. This mode is normally used when office commissioning is needed or configuration data is blank to set massive data fast. A script file, also called a batch command processing file, is a text file (ended with the suffix name.txt). Note: During the creation of an office, script file configuration is recommended. The operation steps of script file configuration are described as follows: 1. Log in to the OMM server of the ZXUN USPP from an OMM client. 2. In the command entering area in the Terminal window, click the icon. The batch command processing window is displayed, see Figure 1-1. Figure 1-1 Batch Command Processing Window 3. In the toolbar, click the icon to select the script file (*.txt) to be executed. 4. Click the icon (syntax check) to start checking the syntax of the script. If the script is found incorrect, modify the script as suggested. If the script is found correct, go to the next step. 5. Click the icon (execute). 1-4

9 Chapter 1 Configuration Management Overview During execution, if an MML command or parameter in the script is found incorrect, a message box is displayed and asks you whether to continue execution. After the script is executed, the number of MML commands that are successfully executed and failed is displayed. 6. Restart all boards of the host to load the configuration data. 1.4 Database Configuration Overview The ZXUN USPP uses a relational database for system data management. The database consists of multiple data tables linked with each other. A data table describes a group of data, and is indexed by other data tables through key fields. Database Type Based on storage locations, the databases of the ZXUN USPP are classified into host databases and the back-end database. The host databases refer to the databases stored in memories of all boards. Databases of this type are mainly used for storing data closely related with service processing. The host databases are used for storage based on module number. The host data can be stored in either of the following two modes: one, the Flash or disk of the host, and the other, memory database of the host. A data file is saved into the Flash or disk after being successfully loaded to a board. After a configuration command is executed in the command window of the managed network element, if there is data added, deleted, or modified, the data file in the Flash or disk will be updated at the same time. When a host process starts, the process uses data from data files to create a host memory database. The host memory database is mainly used for storing data closely related with service processing. After a configuration command is executed in the command window of the managed network element, if there is data added, deleted, or modified, the data in the memory database will be dynamically refreshed. Back-end data storage The back-end database refers to the Firebird database stored on the hard disk of the OMM server. It is based on the CGSL operating system provided by ZTE Corporation. This database is mainly used for storing host operation support data. The operation data is saved in the OMM server database, and disk file. For details, see Figure

10 ZXUN USPP Configuration Management Description Figure 1-2 OMM Data Storage Database Management Function The ZXUN USPP provides the following data configuration and database management functions: Enabling database operations, such as adding, deletion, modification, query, storage, backup, and recovery Effectively managing and maintaining system operation data (such as hardware data, signaling data, route data, number analysis data, and mobile service data) Supporting offline and online configuration data Supporting local and remote configuration Supporting the data online upgrade function Supporting the configuration rollback function. After a user finishes new data configuration, the user can use the configuration rollback function to recover the original data configuration. Supporting the data verification function (ensuring that the host data is the same as the data on the OMP board) 1-6

11 Chapter 2 Configuration Management Principles Table of Contents Software Structure Data Storage Mechanism Data Loading Mechanism Data Synchronization Mechanism Software Structure Overview The configuration management function is mainly implemented by the configuration management module of the Operation, Administration and Maintenance (OAM) subsystem in the ZXUN USPP software system. The OAM subsystem refers to all works that a carrier needs to do on the exchange system that is already put into use. Its purpose is to ensure normal system operation, so that the system can provide good telecommunications services for users. The main functions of the OAM subsystem include providing configuration management access, and analyzing configuration data. The configuration management access function supports the following three access modes: Local maintenance terminal (meaning OMM client) access The OMM client serves as a TCP/IP client and is connected to the OMP. It supports data configuration, daily maintenance, and maintenance management through Telnet, FTP, and MML commands. EMS access The EMS is an integrated network element management system provided by ZTE Corporation. It provides unified management of different devices in the mobile network. The EMS communicates with the ZXUN USPP through the standard TCP/IP protocol. Third-party network element management system access The third-party network element management system enters an internal network of the carrier for remote maintenance through a dialup server. 2-1

12 ZXUN USPP Configuration Management Description Note: The software system of the ZXUN USPP includes the OAM and other subsystems. For details about the OAM subsystem, refer to Section 2.2 Software Structure in the ZXUN USPP Universal Subscriber Profile Platform XXX Product Description (XXX is the NE type). Software Structure of the OAM Subsystem The OAM subsystem is the only subsystem that has interface relationships with the OMM server. It implements the management function on a network element at the front end after receiving a monitoring command from the network element management layer. When the network element is powered on, this subsystem is responsible for version loading and configuration processing on boards. The OAM subsystem monitors the performance of the network element during normal operation, and provides local maintenance when a fault occurs. After receiving a control command from the OMC, the OAM completes the requested operation through interfaces with other software subsystems. The process is described as follows: 1. The network element management system forwards a data configuration request to the OAM subsystem through the management access channel. 2. The OAM analyzes the request, converts it into an internal message structure, and forwards the converted request to the related applications based on the type of the configuration data and the processing processes that each application registers for different configuration data. 3. The applications check the validity of the message, and write it into the memory databases at the management node. 4. The databases distribute the message to the applications that need to use the data. The databases are responsible for data synchronization between boards. For the software structure of the OAM subsystem, see Figure

13 Chapter 2 Configuration Management Principles Figure 2-1 OAM Subsystem Software Structure In Figure 2-1, the configuration management module is located at the service layer of the OAM subsystem. The OAM subsystem includes the OAM management access adaptation layer and OAM application layer. The back-end network element management system manages network elements by interacting with the OAM application modules through the OAM management access adaptation layer, and with the service applications through the OAM application modules. Features of the OAM Subsystem The OAM subsystem has the following features: Providing multiple standard interfaces for network element management, such as Telnet/SSH and XML, and also the ZTE private interface, that is, supporting the Type/Length/Value (TLV) format, dramatically reducing coupling of network element version and network element management system version, facilitating the access of a third-party network element management system, and improving expansibility Providing unified access channel for internal subsystems, optimizing the internal structure, reducing the coupling with subsystem applications, and improving compatibility Configuration Management Access Modes The management access modes supported by configuration management are command line modes, including XML and Telnet/SSH. For details, see Figure

14 ZXUN USPP Configuration Management Description Figure 2-2 Configuration Management Flow The configuration management also includes synchronization of the configuration data between network element nodes, distribution of the configuration data to APPs, and loading and storage of the configuration data. The tasks are divided as follows: The OAM forwards a configuration request after receiving the request from the OMM, and is also responsible for the loading and storage of command data. The APP is responsible for data validity check, and storage of data into the database and auxiliary command data. The database subsystem is responsible for data distribution, synchronization, and loading and storage of the configuration database. Description of the CLI Command Processing Module The CLI command processing module uses a distributed structure, including the CLI Manager (command line management) and CLI Agent (command line agent). For details, see Figure 2-3. Figure 2-3 CLI Command Processing Module Framework For a description of the modules, refer to the following table. Module Description Function CLI Manager Resides on the OMP board. This module parses the configuration command strings entered at different configuration terminals into configuration structures required by applications. Matches the entered string with commands and parameters and sends the matched results to the application subsystem. Processes the command execution results from the application subsystem, generates echoed strings based on the echo scripts of commands, and sends the echoed strings to the configuration terminals. 2-4

15 Chapter 2 Configuration Management Principles Module Description Function CLI Agent Resides at the CPUs of all service centralized points mainly for command registration. Provides the command request registration interface for application processes. Saves the command registration table of the local CPU. Provides the command result sending interface for application processes. The workflow of the CLI command processing module is described as follows: 1. The CLI Manager receives a command registration request from the CLI Agent, and generates a global command registration table. The command registration is implemented by loading a DAT binary script file through version management, and the DAT file is a command format configuration file (ended with the suffix.dat). 2. The CLI Manager receives an OMM client command from the OMM server, matches the command and checks its validity, and converts it into the corresponding format. If the command is a local command, the CLI Manager directly executes the command. If the command is not a local command, the CLI Manager first converts it into an internal format. 3. The CLI Manager queries the command registration table, and forwards the request message to the application process (APP) of the corresponding board. APP refers to the application program that needs the CLI module to provide the configuration command parsing service. 4. The CLI Manager receives the command execution result from the APP, formats the result based on the command syntax tree, and returns the formatted result to the OMM server. 2.2 Data Storage Mechanism Overview MML commands are first saved to the OMP board after being configured through the OMM client, and then delivered to service network elements through the Base bus. In the system, the Base bus is used for bearing maintenance management and data configuration messages between the OMP board and service boards. The Fabric bus is used for bearing network element service messages. The two buses are described as follows: The Base bus acts as the management control bus for the E4140 shelf. It is mainly used as a channel for software loading, alarm, and information maintenance. The SWBB1 is the switching core of the entire Base plane. It enables exchange of control-plane information, and provides cascading interfaces on the Base plane. All 2-5

16 ZXUN USPP Configuration Management Description boards are connected to the OMP (DPBB2) through the Base plane. The exchange of control-plane messages between boards is implemented through the SWBB1. The Fabric bus acts as a data channel on the system service plane. It is mainly used for bearing service-related information within the system. The SWBB1 is the switching core of the entire Fabric bus. It enables the service data exchange, and provides cascading interfaces. All boards are connected to the OMP (DPBB2) through the Fabric bus. The exchange of service messages between boards is implemented through the OMP. Data Storage Format The ZXUN USPP supports the following two file formats for the storage of configuration data: ZDB: The suffix of the saved file is.zdb. TXT: The suffix of the saved file is.txt. Different configuration data supports different storage modes. The protocol stack configuration data can be saved into only.txt files. The configuration data of other types is usually saved into.zdb files. Data Storage Flow The ZXUN USPP supports both the global data storage and the storage of data by modules. For details, refer to the following table. Storage Type Global storage Storage by modules Supported Storage Format Supports both ZDB and TXT formats. Supports the ZDB format only. Flow If the ZDB format is selected, the protocol stack data of the RPU module is first saved in TXT format, and the other configuration data is saved in ZDB format. If the TXT format is selected, global data storage can be directly performed. ZXUN USPP The ZXUN USPP determines whether the module is the RPU module based on the module number, saves the data in TXT format if the module is the RPU module, and directly sends the data to the DBS process if the module is the other logical board. If the module is the RPU module, the protocol stack data of the RPU module is saved in TXT format. If the module is not the RPU module, the configuration data is saved in ZDB format. 2-6

17 Chapter 2 Configuration Management Principles Note: If the configuration data is saved in TXT format, all TXT files are stored on the OMP board. If you want to save the configuration data to the standby OMP board, you need to synchronize data from the active OMP board. 2.3 Data Loading Mechanism Overview Loading refers to the process in which software and configuration data is loaded from an external storage device to the memory of the ZXUN USPP (boards). Loading Modes The loading modes to be used vary with the source files to be loaded and the storage locations of these files. For details, see Figure 2-4. Figure 2-4 Loading Mode Diagram Based on the storage locations of the source files to be loaded, the loading modes can be classified into the following two types: Loading software and data from the local storage medium, such as the OMM hard disk, to the memory of the host (boards). In this mode, all the required source files are stored on the local storage medium of the OMM board. Loading software and data from the local storage medium of a board to the memory of the board. In this mode, all the required source files are stored in the local storage media of the corresponding boards. Loading Flow The loading formats for online data include ZDB and TXT. Different configuration data supports different loading formats. The protocol stack configuration data is loaded from.txt files. The protocol stack data is saved in the RPU module of the OMP board. 2-7

18 ZXUN USPP Configuration Management Description The configuration data of other subsystems is loaded from.zdb files. 2.4 Data Synchronization Mechanism Configuration Flow Some data in the ZXUN USPP system only supports online configuration mode. For the data that supports both online and offline configuration, if you use both configuration modes at the same time, ensure that the data at the front end is the same as that at the back end. The online and offline configuration flows are described as follows. The online configuration data in the ZXUN USPP system comes from the following two sources: Data that you configured on the network element management client Configuration data automatically generated by the system Data of this type mainly refers to the physical configuration data automatically detected by the System Control Subsystem (SCS). The automatic detection of the ZXUN USPP can greatly reduce your workload in configuration maintenance. Data of this type is detected when the SCS is powered on, and written into the memory database. The configuration data includes offline configuration data and online configuration data. The online configuration data needs no synchronization. Synchronization Flows of Offline Configuration Data The offline configuration data supports two synchronization modes: message synchronization and FTP synchronization. The flow of synchronizing data between the front end and back end through messages is described as follows: 1. The configuration result is saved at the back-end network element management database after you finish data configuration. 2. The back end triggers data synchronization. The back-end synchronization tool, together with the front-end synchronization process, finishes the synchronization of static data through messages, loads the configuration data to the database, notifies the database application process about the configuration change, and implements the distribution and storage of the data. The flow of synchronizing data between the front end and back end through FTP is described as follows: 1. The back end makes the.zdb file. 2. The back end logs in to the specified directory on the front-end OMP board through FTP. 3. The back end sends an FTP message to the front end for synchronization, implement the file loading under the specified directory, and trigger the storage, distribution, and notification flows. 2-8

19 Chapter 3 Data Management Mechanism Table of Contents Data Transfer and Rollback Data Backup and Recovery Data Configuration Precautions Data Transfer and Rollback Overview Data transfer refers to the process in which you transfer the configuration data from the back end to the front-end OMP board. The data transfer function provides a mechanism ensuring that the configuration data modified at the back end can take effect at the front-end network element at the same time. Data rollback refers to the process in which you clear the configuration data modified at the back end before the data is transferred to the front end. The data rollback function ensures data security, prevents data changes due to mis-operation, and improves equipment maintainability. Data Transfer The data is saved to the OMM server in the format of data tables in real time after data configuration operations on the ZXUN USPP OMM, such as adding, modification, and deletion. However, the front-end data is not accordingly modified. Data transfer refers to the process in which you transfer the configuration data at the back end to the front-end OMP. The data transfer function provides a mechanism ensuring that the configuration data modified at the back end can take effect at the front-end network element at the same time. The data synchronization can be done in either of the following two modes: Transferring all tables: performed after all data setting operations. Transferring alter tables: performed after a particular operation. An alter table refers to the configuration data (table) that is related to the front-end network element and modified in the network element management system. During data transfer, the network element management system queries the alter table, and transfers the data in the alter table to the front end. 3-1

20 ZXUN USPP Configuration Management Description The data transfer includes the following two situations: Situation 1: Transfer data as the Admin user This command can be used only when the current login user is Admin. This command transfers the data modified by all users (including the Admin user). Situation 2: Transfer the data modified by the current login user This command transfers only the data modified by the current user. The data modified by other users will not be synchronized. Basic Concepts Alter table An alter table refers to the configuration data (table) that is related to the front-end network element and modified in the network element management system. During data transfer, the network element management system queries the alter tables, and transfers the data corresponding to the altered table to the front end. User lock User locks are flag bit information stored in the database. The network element-related configuration data that you modified on the client occupies a lock flag bit. The lock flag bit is released only after you transfer the modified configuration data to the front end through the transfer command. If a user wants modify the configuration data of a network element, the user must query the status of the corresponding lock flag. If the user lock corresponding to the configuration data is occupied by another user, the user cannot modify the data. 3.2 Data Backup and Recovery Overview To improve reliability and security of system data, the configuration data is backed up after the initial configuration or before the important configuration change. If the system database is damaged, the backup data can be used for recovery. If the configuration data is not backed up, data loss may occur, which affects the carrier s services. Data Backup Data backup refers to the process in which the alarm data, configuration data, and security data of the OMM are backed up to the disk. The ZXUN USPP uses the three-level backup management mechanism: backup task, backup object collections, and backup objects. For details, see Figure

21 Chapter 3 Data Management Mechanism Figure 3-1 Backup Management Mechanism A backup task corresponds to one or multiple backup object collections. A backup object collection corresponds to one or multiple backup objects. Backup objects Backup objects refer to database tables or files that the function modules of the system need to back up. Backup object collections Backup object collections are collections of backup objects in the function modules of the system. By default, there are backup object collections of the alarm, performance, security, log, and configuration function modules in the current system. The ZXUN USPP supports manual backup and automatic backup. Automatic backup is usually recommended for configuration data. After you modify important data, you can also choose manual backup. Data Recovery Data recovery refers to the recovery of the configuration data from the disk to the database in case of system crash, user mis-operation or system upgrade failure, so that the system can recover from failure. The ZXUN USPP supports only manual recovery. Related Operations For details about the ZXUN USPP backup and recovery, refer to ZXUN USPP Universal Subscriber Profile Platform Backup and Restoration. 3-3

22 ZXUN USPP Configuration Management Description 3.3 Data Configuration Precautions Impact of Board Restart on Data Configuration This part describes the operations that cannot be performed during the restart of a board, and the impact of these operations on the system. Normally, after you set data in the OMM host database through the local maintenance terminal, the system can ensure that the information in the host database is the same as that in the OMP database when both the OMM host and the OMP board are in normal status. In some special situations, for example, during troubleshooting, software upgrade, or system capacity expansion, you may perform the switchover or reset operation on a board. In this case, the board needs to reload program and data from the OMP board. This process is called board restart. During the restart of a board, the operation of the board is not stable, which lies in the following aspects: The communication between the board and the OMP board is not stable. The communication between the board and other boards is not stable. The board cannot immediately respond to an operation maintenance command from the back end (local maintenance terminal). In this situation, you cannot perform any data configuration operation on the local maintenance terminal that may cause database modification. Otherwise, the information in the host database may become different from that in the OMP database, threatening system security and stability. Therefore, if you performs the switchover or reset operation on a board, you must query the operational status of the board. You can perform data configuration operations on the local maintenance terminal only when the board recovers to normal status. Impact of Software Parameters on Data Configuration Software parameters can coordinate with the configuration data only when they are correctly configured. In general, you can directly use the default values. In actual application, it is difficult for the ZXUN USPP to connect to other network devices due to any of the following causes: different countries have different technical specifications and industry standards, equipment manufacturers have different understandings of related protocol or signaling, or network devices use different technical standards. To solve this problem, the ZXUN USPP provides the software switch control mechanism for some controversial and flexible software parameters. This means that the local office can correctly connect to different network devices or implement some special functions by modifying the corresponding software switches. 3-4

23 Chapter 3 Data Management Mechanism Therefore, software parameters are provided to solve special problems. Each bit in the software parameters has a special meaning. In general, you can directly use the default values. Note: If you want to modify software parameters, contact ZTE technical support before modification. 3-5

24 ZXUN USPP Configuration Management Description This page intentionally left blank. 3-6

25 Glossary CGSL - Carrier Grade Server Linux EMS - Element Management System FTP - File Transfer Protocol MML - Man Machine Language OAM - Operation, Administration and Maintenance OMC - Operation & Maintenance Center OMM - Operation and Maintenance Management OMP - Operation & Maintenance Processor SCS - System Control Subsystem TCP/IP - Transmission Control Protocol/Internet Protocol TLV - Type/Length/Value UMM - Unified Maintenance Module ZDB - ZIP Database I