Pki (Sran11.1 08)

SingleRAN
SRAN11.1
PKI Feature Parameter Description
Issue 08
Date 2018-01-08
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2018. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 08 (2018-01-08) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
SingleRAN
PKI Feature Parameter Description Contents
Contents
1 About This Document.................................................................................................................. 1

1.1 Scope.............................................................................................................................................................................. 1
1.2 Intended Audience.......................................................................................................................................................... 2
1.3 Change History............................................................................................................................................................... 3
1.4 Differences Between Base Station Types....................................................................................................................... 8
2 Overview....................................................................................................................................... 10
3 PKI Architecture.......................................................................................................................... 12
3.1 Introduction.................................................................................................................................................................. 12
3.2 CA.................................................................................................................................................................................13
3.3 RA.................................................................................................................................................................................14
3.4 Certificate & CRL Database.........................................................................................................................................14
4 Certificates and Files Used by NEs.......................................................................................... 15

4.1 Device Certificate......................................................................................................................................................... 15
4.2 Root Certificate, Certificate Chain, and Trust Certificate............................................................................................ 17
4.3 Cross-Certificate........................................................................................................................................................... 18
4.4 CRL.............................................................................................................................................................................. 19
5 Certificate Management and Application Scenarios............................................................20

5.1 Certificate Preconfiguration Phase............................................................................................................................... 20
5.2 Certificate Management During Base Station Deployment......................................................................................... 20
5.3 Certificate Management During Base Station Controller Deployment........................................................................23
5.4 Certificate Management During eCoordinator Deployment........................................................................................ 25
5.5 Certificate Management During the Operation Phase.................................................................................................. 26
5.5.1 Certificate Application.............................................................................................................................................. 26
5.5.2 Certificate Sharing..................................................................................................................................................... 27
5.5.3 Certificate Validity Check......................................................................................................................................... 28
5.5.4 Certificate Update......................................................................................................................................................30
5.5.5 Certificate Revocation............................................................................................................................................... 31
5.5.6 CRL Acquisition........................................................................................................................................................32
5.5.7 Offline Certificate Monitoring...................................................................................................................................33
5.5.8 CMPv2-based Certificate Management.....................................................................................................................34
5.6 PKI Networking Reliability..........................................................................................................................................38
5.7 Certificate Usage in UMPT+UMPT Cold Backup Mode............................................................................................ 39
Issue 08 (2018-01-08) Huawei Proprietary and Confidential ii

SingleRAN
5.8 Digital Certificate Whitelist Management....................................................................................................................39
6 Related Features...........................................................................................................................41
6.1 GBFD-113526 BTS Supporting PKI............................................................................................................................41
6.2 WRFD-140210 NodeB PKI Support............................................................................................................................ 41
6.3 LOFD-003010 Public Key Infrastructure (PKI)...........................................................................................................42
6.4 TDLOFD-003010 Public Key Infrastructure (PKI)..................................................................................................... 42
6.5 GBFD-160211 BSC Supporting PKI............................................................................................................................42
6.6 WRFD-160276 RNC Supporting PKI.......................................................................................................................... 43
6.7 GBFD-160210 BTS Supporting PKI Redundancy.......................................................................................................43
6.8 GBFD-160208 BSC Supporting PKI Redundancy...................................................................................................... 44
6.9 WRFD-160275 NodeB Supporting PKI Redundancy..................................................................................................44
6.10 WRFD-160277 RNC Supporting PKI Redundancy................................................................................................... 44
6.11 LOFD-070212 eNodeB Supporting PKI Redundancy............................................................................................... 45
6.12 TDLOFD-070212 eNodeB Supporting PKI Redundancy..........................................................................................45
6.13 GBFD-181202 BTS Supporting Digital Certificate Whitelist Management..............................................................46
6.14 WRFD-181220 NodeB Supporting Digital Certificate Whitelist Management.........................................................46
6.15 LOFD-111203 eNodeB Supporting Digital Certificate Whitelist Management........................................................ 46
6.16 eCoordinator Supporting PKI..................................................................................................................................... 47
7 Network Impact........................................................................................................................... 48
8 Engineering Guidelines for PKI...............................................................................................49
8.1 When to Use................................................................................................................................................................. 49
8.2 Required Information................................................................................................................................................... 49
8.3 Hardware Planning....................................................................................................................................................... 51
8.4 Requirements................................................................................................................................................................ 52
8.5 Deployment of PKI on the eGBTS/NodeB/eNodeB/Multimode Base Station............................................................ 55
8.5.1 Data Preparation........................................................................................................................................................ 56
8.5.2 Initial Configuration.................................................................................................................................................. 69
8.5.2.1 Using the CME....................................................................................................................................................... 69
8.5.2.2 Using MML Commands......................................................................................................................................... 75
8.5.2.3 MML Command Examples.................................................................................................................................... 76
8.5.3 Activation Observation..............................................................................................................................................78
8.5.4 Deactivation...............................................................................................................................................................79
8.6 Deployment of PKI on the eGBTS using a GTMUb....................................................................................................79
8.6.4 Deactivation...............................................................................................................................................................85
8.7 Deployment of PKI on a NodeB Using a WMPT........................................................................................................ 85
Issue 08 (2018-01-08) Huawei Proprietary and Confidential iii

SingleRAN

8.7.4 Deactivation...............................................................................................................................................................91
8.8 Deployment of PKI on the GBTS.................................................................................................................................91
8.8.2 Initial Configuration................................................................................................................................................ 103
8.8.2.1 Using the CME..................................................................................................................................................... 103
8.8.2.2 Using MML Commands....................................................................................................................................... 103
8.8.2.3 MML Command Examples.................................................................................................................................. 104
8.8.3 Activation Observation............................................................................................................................................105
8.8.4 Deactivation.............................................................................................................................................................106
8.9 Deployment of PKI on the Base Station Controller................................................................................................... 106
8.9.1 Data Preparation...................................................................................................................................................... 106
8.9.2 Initial Configuration................................................................................................................................................ 118
8.9.4 Deactivation.............................................................................................................................................................121
8.10 Deployment of PKI on the eCoordinator..................................................................................................................121
8.10.1 Data Preparation.................................................................................................................................................... 122
8.10.2 Initial Configuration.............................................................................................................................................. 127
8.10.3 Activation Observation..........................................................................................................................................129
8.10.4 Deactivation...........................................................................................................................................................130
8.11 Deployment of PKI Redundancy on the eGBTS/NodeB/eNodeB/Multimode Base Station................................... 130
8.11.3 Activation Observation.......................................................................................................................................... 132
8.11.4 Deactivation........................................................................................................................................................... 133
8.12 Deployment of PKI Redundancy on the Base Station Controller............................................................................ 133
8.12.3 Activation Observation..........................................................................................................................................134
8.12.4 Deactivation...........................................................................................................................................................135
8.13 Reconstruction from a PKI-based Secure Network to a PKI Redundancy Network on the eGBTS/NodeB/eNodeB/
Multimode Base Station................................................................................................................................................... 135
8.14 Reconstruction from a PKI-based Secure Network to a PKI Redundancy Network on the Base Station Controller
.......................................................................................................................................................................................... 139
8.15 Reconfiguration........................................................................................................................................................ 143
8.16 Performance Monitoring...........................................................................................................................................143
8.17 Parameter Optimization............................................................................................................................................ 143
8.18 Possible Issues.......................................................................................................................................................... 143
Issue 08 (2018-01-08) Huawei Proprietary and Confidential iv

SingleRAN
8.18.1 Base Station Side................................................................................................................................................... 143

8.18.2 Base Station Controller/eCoordinator Side........................................................................................................... 143
9 Engineering Guidelines for Digital Certificate Whitelist Management........................ 145

9.1 When to Use............................................................................................................................................................... 145
9.2 Required Information................................................................................................................................................. 145
9.3 Deployment................................................................................................................................................................ 145
9.3.1 Process..................................................................................................................................................................... 145
9.3.2 Requirements........................................................................................................................................................... 146
9.3.3 Precautions...............................................................................................................................................................147
9.3.4 Data Preparation and Feature Activation.................................................................................................................147
9.3.4.1 Data Preparation................................................................................................................................................... 147
9.3.4.2 Using the CME..................................................................................................................................................... 148
9.3.6 Deactivation.............................................................................................................................................................150
9.3.6.1 Using the CME..................................................................................................................................................... 150
9.4 Performance Monitoring.............................................................................................................................................150
9.5 Parameter Optimization.............................................................................................................................................. 150
9.6 Possible Issues............................................................................................................................................................ 150
10 Parameters................................................................................................................................. 151
11 Counters.................................................................................................................................... 216
12 Glossary..................................................................................................................................... 217
13 Reference Documents............................................................................................................. 218
Issue 08 (2018-01-08) Huawei Proprietary and Confidential v

SingleRAN
PKI Feature Parameter Description 1 About This Document
1 About This Document
1.1 Scope
This document describes the public key infrastructure (PKI), including its technical principles,
related features, network impact, and engineering guidelines.
This document covers the following features:
l GBFD-113526 BTS Supporting PKI

l WRFD-140210 NodeB PKI Support
l LOFD-003010 Public Key Infrastructure (PKI)
l TDLOFD-003010 Public Key Infrastructure (PKI)
l GBFD-160211 BSC Supporting PKI
l WRFD-160276 RNC Supporting PKI
l GBFD-160210 BTS Supporting PKI Redundancy
l GBFD-160208 BSC Supporting PKI Redundancy
l WRFD-160275 NodeB Supporting PKI Redundancy
l WRFD-160277 RNC Supporting PKI Redundancy
l LOFD-070212 eNodeB Supporting PKI Redundancy
l TDLOFD-070212 eNodeB Supporting PKI Redundancy
l GBFD-181202 BTS Supporting Digital Certificate Whitelist Management
l WRFD-181220 NodeB Supporting Digital Certificate Whitelist Management
l LOFD-111203 eNodeB Supporting Digital Certificate Whitelist Management
Unless otherwise specified, in this document, LTE, eNodeB, and eRAN always include both
FDD and TDD. The "L" and "T" in RAT acronyms refer to LTE FDD and LTE TDD,
respectively.
NOTE
The eCoordinator does not support PKI-related optional features. It only supports manual configuration
of digital certificates.
Table 1-1 provides the definitions of the base stations.
Issue 08 (2018-01-08) Huawei Proprietary and Confidential 1

SingleRAN
Table 1-1 Base station definitions

Base Station Definition
Name
GBTS A base station configured with a GTMU, GTMUb, or GTMUc board

and managed through a base station controller.
eGBTS A base station configured with a GTMUb, GTMUc, UMPT_G, or

UMDU_G board and directly managed by an element management
system (EMS).
NodeB A base station configured with a WMPT, UMPT_U, or UMDU_U

board.
eNodeB A base station configured with an LMPT, UMPT_L, UMPT_T,

UMDU_L, or UMDU_T board.
Co-MPT A base station configured with a UMPT_GU, UMDU_GU, UMPT_GL,

multimode base UMDU_GL, UMPT_GT, UMDU_GT, UMPT_UL, UMDU_UL,
station UMPT_UT, UMDU_UT, UMPT_LT, UMDU_LT, UMPT_GUL,
UMDU_GUL, UMPT_GUT, UMDU_GUT, UMPT_ULT, UMDU_ULT,
UMPT_GLT, UMDU_GLT, UMPT_GULT, or UMDU_GULT board. A
co-MPT multimode base station functionally corresponds to any
physical combination of eGBTS, NodeB, and eNodeB. For example, a
co-MPT multimode base station configured with a UMPT_GU or
UMDU_GU board functionally corresponds to the physical combination
of eGBTS and NodeB.
NOTE
Unless otherwise specified, the descriptions and examples of the UMPT board in
a co-MPT base station also apply to the UMDU board in a co-MPT base station.
Separate-MPT A base station on which each mode uses its separate main control board.
multimode base For example, a base station configured with a GTMU providing GSM
station services and a WMPT providing UMTS services, is called a separate-
MPT GSM/UMTS dual-mode base station.
NOTE
A UMDU board cannot be used in a separate-MPT base station.
The universal switching unit (USU) is configured with an SMPT or UEFU board. A USU can
be either a USU3900 configured with an SMPT board, or a USU3910 configured with a
UEFU board. Unless otherwise specified, the feature implementation of a USU is the same as
that of a base station. The licenses mentioned in this document are not applicable to USUs.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the features described herein
l Work with Huawei products

SingleRAN
1.3 Change History

This section provides information about the changes in different document versions. There are
two types of changes, which are defined as follows:
l Feature change
Changes in features of a specific product version
l Editorial change
Changes in wording or addition of information that was not described in the earlier
version
SRAN11.1 08 (2018-01-08)
This issue includes the following changes.
Change Change Description Parameter

Type Change
Feature None None

change
Editorial Modified the description that the base station does not None
changes apply for a new device certificate when the base station
automatically obtains a certificate (for example, during
base station deployment) in which the issuer is
inconsistent with the CA information. For details, see 5.2
Certificate Management During Base Station
Deployment.
SRAN11.1 07 (2017-04-21)

Type Change
Feature None None

change
Editorial Revised the configuration suggestions about LOCALIP None

change and LOCALIP (BSC6900, BSC6910). For details, see
8.5.1 Data Preparation and 8.8.1 Data Preparation.
SRAN11.1 06 (2017-03-30)

SingleRAN

Type Change
Feature None None

change
Editorial Corrected the license control item ID of LOFD-111203 None

change eNodeB Supporting Digital Certificate Whitelist
Management. For details, see 9.3.2 Requirements.
SRAN11.1 05 (2016-10-08)

Type Change
Feature Added how to configure CANAME in different scenarios. None

change For details, see 8.5.1 Data Preparation and 8.9.1 Data
Preparation.
Editorial None None

change
SRAN11.1 04 (2016-06-23)

Type Change
Feature Added deployment of PKI on a NodeB that uses a WMPT None

change as the main control board and is not configured with a
UTRPc. For details, see 8.7 Deployment of PKI on a
NodeB Using a WMPT.
Editorial None None

change
SRAN11.1 03 (2016-05-26)

Type Change
Feature None None

change

SingleRAN

Type Change
Editorial Added descriptions of triggering automatic certificate None

change application if an IKE negotiation failure is caused by
digital certificate problems. For details, see 5.5.1
Certificate Application.
SRAN11.1 02 (2016-04-20)

Type Change
Feature None None

change
Editorial Added the LTE CN devices (MME and S-GW) to Figure None
change 2-1.
Revised descriptions of the application scenarios of None

Huawei-issued device certificates. For details, see 4.1
Device Certificate.
Removed descriptions that Huawei-issued device None

certificates can be permanently used. For details, see 5.1
Certificate Preconfiguration Phase.
SRAN11.1 01 (2016-02-29)
This issue does not include any changes.
SRAN11.1 Draft A (2015-12-30)

Compared with Issue 03 (2015-09-30) of SRAN10.1, Draft A (2015-12-30) of SRAN11.1
includes the following changes.

SingleRAN

Type Change
Feature Supported the GTMUc in an eGBTS. For details, see the None
change following sections:
l 1.1 Scope
l 2 Overview
l 5.6 PKI Networking Reliability
l 8.3 Hardware Planning
l 8.5 Deployment of PKI on the eGBTS/NodeB/
eNodeB/Multimode Base Station
The S and ST fields in CANAME are regarded as the None

same field. For details, see the following sections:
l 8.5.1 Data Preparation
Added the function of monitoring offline certificates. None

Offline certificates refer to certificates that are not in use
but are recorded as in use on the U2000. For details about
offline certificate monitoring, see the following sections:
l 5.5.7 Offline Certificate Monitoring
l 8.5.3 Activation Observation
l 8.6.3 Activation Observation
Supported a micro base station: BTS3205E. None

SingleRAN

Type Change
Feature Added digital certificate whitelist management. For Added the

change details, see the following sections: following
l 5.8 Digital Certificate Whitelist Management MML
commands:
l 9 Engineering Guidelines for Digital Certificate
Whitelist Management l ACT
CERTWHI
l 6.13 GBFD-181202 BTS Supporting Digital TELSTFIL
Certificate Whitelist Management E
l 6.14 WRFD-181220 NodeB Supporting Digital l DSP
Certificate Whitelist Management CERTWHI
l 6.15 LOFD-111203 eNodeB Supporting Digital TELSTITE
Certificate Whitelist Management M
l SET
CERTCFG
l LST
CERTCFG
Added the
value
CERTWHITE
LST(CERTW
HITELST) to
the following
parameters:
l CT in the
DLD
CERTFIL
E command
l CERTFILE
TYPE in the
RMV
CERTFIL
E and LST
CERTFIL
E
commands
Editorial Added descriptions that base stations cannot apply for None
change certificates through E1/T1 ports. For details, see 5.5.1
Certificate Application.
Revised the descriptions of CME-based feature None

configuration in engineering guidelines.
Adjusted the format in 6 Related Features. None

SingleRAN
1.4 Differences Between Base Station Types

Definition
The macro base stations referenced in this document are the 3900 series base stations listed in
the "Scope" section. These base stations may be configured to work in GSM, UMTS, or LTE
mode.
The LampSite base stations referenced in this document are distributed base stations designed
for indoor coverage. These base stations work in UMTS or LTE mode but do not work in
GSM mode.
The micro base stations referenced in this document are all integrated entities that work in
UMTS or LTE mode but do not work in GSM mode. Descriptions of boards, cabinets,
subracks, slots, and RRUs do not apply to micro base stations.
The following table lists micro base station models.
Base Station Model RAT
BTS3202E LTE FDD
BTS3205E LTE TDD
BTS3911E UMTS+LTE FDD
NOTE
The multimode micro base station BTS3911E is used in UMTS+LTE FDD co-MPT scenarios but not in
separate-MPT scenarios.
Co-MPT and separate-MPT applications are not relevant to single-mode micro base stations.
Feature Support by Macro, Micro, and LampSite Base Stations

Feature ID Feature Name Supporte Supported by Supporte
d by Micro Base d by
Macro Stations LampSite
Base Base
Stations Stations
GBFD-113526 BTS Supporting PKI Yes No No
WRFD-140210 NodeB PKI Support Yes Yes Yes
LOFD-003010 Public Key Yes Yes Yes

Infrastructure (PKI)
TDLOFD-003010 Public Key Yes Yes Yes

GBFD-160211 BSC Supporting PKI N/A N/A N/A

SingleRAN
Feature ID Feature Name Supporte Supported by Supporte

d by Micro Base d by
Macro Stations LampSite
Base Base
Stations Stations
WRFD-160276 RNC Supporting PKI N/A N/A N/A
GBFD-160210 BTS Supporting PKI Yes No No

Redundancy
GBFD-160208 BSC Supporting PKI N/A N/A N/A

Redundancy
WRFD-160275 NodeB Supporting PKI Yes Yes Yes

Redundancy
WRFD-160277 RNC Supporting PKI N/A N/A N/A

Redundancy
LOFD-070212 eNodeB Supporting PKI Yes Yes Yes

Redundancy
TDLOFD-070212 eNodeB Supporting PKI Yes Yes Yes

Redundancy
LOFD-111203 eNodeB Supporting Yes Yes Yes

Digital Certificate
Whitelist Management
WRFD-181220 NodeB Supporting Yes Yes Yes

Digital Certificate
GBFD-181202 BTS Supporting Digital Yes No No

Certificate Whitelist
Management
Function Implementation in Macro, Micro, and LampSite Base Stations

Function Difference
Certificate application in UMPT+UMPT Micro base stations do not consist of boards

cold backup mode and therefore do not support cold backup.

SingleRAN
PKI Feature Parameter Description 2 Overview
2 Overview
PKI is a type of security infrastructure that provides information security and digital
certificate management. It uses an asymmetric cryptographic algorithm to allow client and
server applications to trust each other's authentication credentials and perform authentication.
In multi-operator PKI scenarios, each operator can deploy an independent PKI server and use
the certificate issued by the operator's PKI server to perform authentication on Internet
Protocol Security (IPsec) tunnels. In this way, secondary operators do not depend on the PKI
of the primary operator, and services of each operator can be securely isolated.
A digital certificate identifies a specific device. The device is created by a trusted certificate
authority (CA), which digitally signs the device and public key. A digital certificate includes
the following information:
l Serial number and validity period of the certificate
l Organization that issued the certificate
l Public key
l Extension fields of the certificate
The SubjectAltName extension field in a digital certificate contains the base station's/
base station controller's/eCoordinator's identity information, such as the electronic serial
number (ESN) of the NodeB's main control board.
Asymmetric keys are used to authenticate devices during digital certificate authentication.
The sender uses a private key to sign data, and the receiver uses a public key in the certificate
to verify signature validity. With digital certificates, both the receiver and the sender confirm
each other's identities to protect against communication fraud and eavesdropping.
Huawei base stations/base station controllers/eCoordinators use a PKI-based end-to-end
certificate management solution. This solution facilitates the deployment and use of digital
certificates.
For Huawei products, digital certificates apply to the following scenarios:
l Authentication during the setup of an IPsec tunnel between a base station and an SeGW
on a radio bearer network
l Authentication during the setup of a Secure Sockets Layer (SSL) connection between an
eGBTS/NodeB/eNodeB/RNC/BSC/eCoordinator and the U2000 to protect data
transmission at the application layer
l 802.1x-based access control for the eGBTS/NodeB/eNodeB, which uses digital
certificates for identity authentication

SingleRAN
PKI Feature Parameter Description 2 Overview
l Setup of separate IPsec tunnels for each operator, thereby implementing secure service
isolation in RAN sharing scenarios when multiple operators share a base station and each
operator deploys a separate PKI server.
NOTE
l For a GBTS configured with a GTMUb/GTMUc, PKI-based authentication is not supported by SSL,
Base Station Supporting Multi-operator PKI, or Access Control based on 802.1x.
l For an eGBTS configured with a GTMUb, PKI-based authentication is not supported by Access
Control based on 802.1x.
l The eGBTS configured with a GTMUb/GTMUc does not support Base Station Supporting Multi-
operator PKI.
l For details about IPsec, see IPsec Feature Parameter Description.
l For details about SSL, see SSL Feature Parameter Description.
l For details about 802.1x, see Access Control based on 802.1x Feature Parameter Description.
l For details about base station supporting multi-operator PKI in RAN sharing scenarios, see Base
Station Supporting Multi-operator PKI Feature Parameter Description.
Figure 2-1 Example of networking that uses digital certificates

SingleRAN
PKI Feature Parameter Description 3 PKI Architecture
3 PKI Architecture
3.1 Introduction
A PKI system manages digital certificates for network devices. This enables operators to
establish a trusted security domain so that they have a trust relationship with devices from
different vendors.
As shown in Figure 3-1, a PKI system on a wireless network generally consists of the
following network elements (NEs):
l NEs that use certificates, including the base station, base station controller, security
gateway (SeGW), and U2000.
l PKI server that manages certificates, including the CA, registration authority (RA), and
certificate & CRL database. CRL stands for certificate revocation list.
Figure 3-1 PKI system
NOTE
For more information about PKI, see IETF RFC 5280 and IETF RFC 2585. Certificates and CRLs
comply with X.509v3 and X.509v2, respectively, but do not comply with earlier specifications. For
details, see IETF RFC 5280.
The eCoordinator cannot directly apply for and update certificates from the PKI system. The
eCoordinator's certificates must be manually maintained on the U2000.

SingleRAN
3.2 CA
A CA serves as a central management node in a PKI system. As shown in Figure 3-1, a CA
manages certificates as follows:
l Approves or rejects certificate applications and issues certificates for approved

applications.
l Handles requests for certificate updates, verifications, revocations, and queries.
l Generates certificates and CRLs and publishes them in the certificate & CRL database.
On a live network, a CA system can use a layered structure to meet the requirements for CA
deployment across different areas. The root CA is responsible for managing all certificates on
the entire network. The layered structure helps share the load of the root CA. Figure 3-2
shows an example of the CA system architecture.
Figure 3-2 Example of the CA system architecture
When building a PKI system, an operator determines the root CA domain based on the
operator's business scale and global network distribution.
l Root CA: The root CA is located at the top level and has the highest security and
reliability.
l Subordinate CA: Operators usually use the root CA to authorize important subordinate
CAs. CAs at each level can be authorized to sign and issue certificates for their lower-
level CAs or for end users. All certificates from end users to the root CA form a
certificate chain. As long as a user obtains the peer's root CA certificate and certificates
of subordinate CAs at different levels, the user can authenticate the certificates in the
certificate chain. This method facilitates certificate deployment because the root CA is
no longer required for signing and issuing certificates for all end users.
l Cross-certification CA: issues a cross-certificate to a peer CA under another root CA
when a trust relationship must be set up with the peer CA.
l Device CA: issues digital certificates to network devices within its service scope.

SingleRAN
NOTE
Base station controllers and eCoordinators do not support cross-certificates.
There is no strict limitation imposed on the number of layers in a CA system. Operators can
divide the CA system into layers according to their requirements. Generally, a three-layer CA
system can meet the requirements of most operators. However, a two-layer CA system is
recommended, considering the management cost and complexity.
3.3 RA
An RA is a certificate registration and approval authority. As shown in Figure 3-1, an RA
interacts with communication entities such as base stations and base station controllers,
collects certificate applicants' information, and verifies their qualifications. The RA then
determines whether to issue a certificate to an applicant based on the verification result. If the
application is approved, the RA sends the application information to the CA which then issues
the certificate.
A CA incorporates the functions of an RA, thereby making the RA an optional component.
An RA is not required in a small-sized PKI system because the CA itself can handle
interactions with base stations and base station controllers. In a large-sized PKI system, the
CA focuses on certificate management and an RA takes over the functions of interacting with
base stations and base station controllers.
3.4 Certificate & CRL Database

As shown in Figure 3-1, a certificate & CRL database stores all certificates and CRLs.
Certificates are approved, signed, and issued by CAs. CRLs contain certificates revoked by
CAs. Base stations/base station controllers/eCoordinators can access the database.
On a live network, a certificate & CRL database is an independent entity deployed on a server
in a demilitarized zone (DMZ). This allows users on the network to obtain certificates and
CRLs online, without imposing any security threat on the CA system.
A certificate & CRL database is generally deployed on a File Transfer Protocol (FTP) server
or Lightweight Directory Access Protocol (LDAP) server.
NOTE
The CRL is obtained by the NE from the operator's PKI system.

The CRL enables the base station and base station controller to verify the certificate sent by the peer
equipment (such as an SeGW), but the base station and base station controller cannot verify their own
certificates.

SingleRAN
PKI Feature Parameter Description 4 Certificates and Files Used by NEs
4 Certificates and Files Used by NEs
4.1 Device Certificate

Device certificates are used to authenticate the identities of NEs. Each device certificate has a
private-public key pair. The key pair is used to compute digital signatures during
authentication between a base station/base station controller/eCoordinator and an SeGW or
the U2000.
Device certificates used by base stations/base station controllers/eCoordinators are Huawei-
issued device certificates and operator-issued device certificates.
Huawei-Issued Device Certificate

Each Huawei base station is preconfigured with a Huawei-issued device certificate before
delivery. The certificate is stored on the main control board (UMPT/LMPT/UMDU/GTMUc/
SMPT/UEFU) or UTRPc board. The certificate is bound with the ESN of the board. The key
of a Huawei-issued device certificate is 2048 bits long. Huawei-issued device certificates are
named appcert.pem and are activated before base stations are delivered.
NOTE
The Huawei-issued device certificate preconfigured on the GTMUc in a GBTS can only be used for SSL
connections between the GBTS and the site maintenance terminal (SMT). It cannot be used for PKI or
IPsec authentication.
The Huawei-issued device certificate preconfigured on the GTMUc in an eGBTS can only be used for
PKI and SSL authentication. It cannot be used for IPsec authentication.
Each Huawei base station controller is preconfigured with a Huawei-issued device certificate
before delivery. The certificate is bound with the ESN of the OMU board and is named
hwusercert.pem. The key of a Huawei-issued device certificate is 2048 bits long. Huawei-
issued device certificates for base station controllers are activated before base station
controllers are delivered.
All Huawei eCoordinators are preconfigured with the same certificate issued by Huawei CA
before delivery. The certificate is stored on the OMU board.

SingleRAN
NOTE
The certificate preconfigured on an eCoordinator, in a strict sense, is not a device certificate because it is
not bound with the ESN of the OMU. If the preconfigured certificate on one Huawei eCoordinator is
cracked, the preconfigured certificates on all Huawei eCoordinators are cracked. Therefore, it is
recommended that an operator-issued device certificate be applied for an eCoordinator after the
eCoordinator connects to a network.
The application scenarios of Huawei-issued device certificates are as follows:

l If a PKI system is deployed in an operator's network, Huawei-issued device certificates
are used for authentication during the operator-issued device certificate application
process.
– When a base station/base station controller accesses the operator's network, it
applies for a device certificate from the operator's CA by sending a CMPv2
message. The operator-issued device certificate is then used for authentication
during the subsequent communication process.
– When an eCoordinator accesses the operator's network, a device certificate must be
manually applied for from the operator's CA through the U2000. The operator-
issued device certificate is then used for authentication during the subsequent
communication process.
l If no PKI system is deployed in an operator's network, the peer equipment of a base
station/base station controller/eCoordinator can be preconfigured with the Huawei root
certificate. Huawei-issued device certificates are used for authentication between the
base station/base station controller/eCoordinator and peer equipment.
Regardless of whether a PKI system is deployed in the operator's network, if Huawei-issued
device certificates are used for authentication during all communication processes, the
following security risks exist: Huawei-issued device certificates have a validity period of 15
years; you cannot update, apply for, or revoke Huawei-issued device certificates. In addition,
Huawei-issued device certificates may be disclosed if they are used online for long period of
time.
Operator-Issued Device Certificate

If a PKI system is deployed in an operator's network, Huawei-issued device certificates are
used for authentication during the operator-issued device certificate application process. The
operator-issued device certificate is then used for authentication during the subsequent
communication process.
The validity periods of operator-issued device certificates are configured by operators.
Operator-issued device certificates can be applied for, updated, and revoked. Compared with
Huawei-issued device certificates, operator-issued device certificates feature flexible
management and various risk control methods. It is recommended that the Huawei-issued
device certificate be replaced with an operator-issued device certificate immediately after the
base station/base station controller/eCoordinator connects to the operator's network.

SingleRAN
4.2 Root Certificate, Certificate Chain, and Trust

Certificate
Root Certificate
A root certificate is the certificate of the root CA and is used to verify the validity of device
certificates issued by the root CA.
The Huawei root certificate is preconfigured in each Huawei base station as the trust
certificate before delivery. The certificate is stored on the main control board (UMPT/LMPT/
UMDU/GTMUc) or UTRPc board and can be used to verify Huawei-issued device
certificates. The Huawei root certificate is named caroot.pem.
The Huawei root certificate is preconfigured on each Huawei base station controller/
eCoordinator as the trust certificate before delivery. The certificate can be used to verify
Huawei-issued device certificates and is named rootca.pem.
NOTE
Huawei wireless-network CA system is a 2-layer CA system. caroot.pem and rootca.pem are files in
the 2-layer certificate chain.
If a Huawei base station/base station controller/eCoordinator uses an operator-issued device

certificate to connect to an operator's network, the base station/base station controller/
eCoordinator must be preconfigured with the operator's root certificate or certificate chain to
authenticate the operator's device, such as an SeGW or a third-party FTP server. The
operator's device must be preconfigured with and trust the operator's root certificate or
certificate chain to authenticate the base station/base station controller/eCoordinator. During
authentication, the communicating parties use their respective trust certificates to verify the
validity of the peer's device certificate.
Figure 4-1 shows an example of how a CA uses the Huawei root certificate to authenticate a
Huawei-issued device certificate. The CA is preconfigured with the Huawei root certificate.
During authentication, a base station sends its Huawei-issued device certificate to the CA
which then uses the Huawei root certificate to verify the device certificate.
Figure 4-1 Base station authentication by a CA

SingleRAN
Certificate Chain
If there are multiple layers of CAs in a PKI system, certificates of the CAs form a certificate
chain, which is used to verify the validity of device certificates issued by the bottom-level CA
in the chain.
If there is a certificate chain from the base station's device certificate up to the root CA, the
peer device must be preconfigured with the certificate chain so that the device can verify the
validity of the device certificate sent by the base station during Internet Key Exchange (IKE)
authentication.
Trust Certificate
A trust certificate is the root certificate or certificate chain that is loaded on NEs.
NOTE
A base station/base station controller/eCoordinator reloads the device certificate and verifies its validity
each time the base station/base station controller/eCoordinator restarts.
4.3 Cross-Certificate
A cross-certificate is issued by one CA to another in order to establish a trust relationship
between them.
Cross-certification is a process in which two devices use the cross-certificate for
authentication. Figure 4-2 shows the procedure for cross-certification before and during base
station deployment.
Figure 4-2 Procedure for cross-certification before and during base station deployment

SingleRAN
NOTE
The eGBTS, NodeB, and eNodeB support cross-certificates, whereas the GBTS, BSC, eCoordinator, and
RNC do not.
Before using the cross-certificate for authentication, the operator's CA and the Huawei CA
must issue a cross-certificate to each other. This is a cumbersome procedure and hence is not
recommended.
4.4 CRL
CRL is used to verify the validity of the peer certificate. Certificates need to be revoked when
certificates are disclosed or when devices that use the certificates are replaced or discarded.
Revoked certificates are recorded in a CRL. An NE uses a CRL to check the validity of the
certificate sent by a peer device when authenticating the peer device. The peer device is not
trustworthy if its certificate is recorded in a CRL.
l O&M personnel can run the SET BTSCRLPOLICY command to set a CRL usage
policy for the GBTS.
l O&M personnel can run the SET CRLPOLICY command to set a CRL usage policy
for the eGBTS/NodeB/eNodeB/eCoordinator/base station controller.
The setting of CRLPOLICY is as follows:
l If this parameter is set to NOVERIFY, the base station/base station controller/
eCoordinator does not perform CRL-based certificate validity checks.
l If this parameter is set to ALARM, the base station reports ALM-26832 Peer Certificate
Expiry and the base station controller/eCoordinator reports ALM-20854 Peer Certificate
Invalid, Expiry, or Damage when the peer's device certificate is detected in the CRL.
l If this parameter is set to DISCONNECT, the base station/base station controller/
eCoordinator reports the preceding alarms and disconnects the communication with the
peer end when the peer's device certificate is detected in the CRL.

SingleRAN
PKI Feature Parameter Description 5 Certificate Management and Application Scenarios
5 Certificate Management and Application

Scenarios
5.1 Certificate Preconfiguration Phase

The certificate preconfiguration phase includes the following activities:
l Preconfiguration of certificates on a base station/base station controller/eCoordinator
The main control board or UTRPc board of each base station is preconfigured with the
Huawei root certificate and a Huawei-issued device certificate. The OMU board of each
base station controller/eCoordinator is preconfigured with the Huawei root certificate
and a Huawei-issued device certificate.
NOTE
Each Huawei eCoordinator is preconfigured with a Huawei-issued device certificate before

delivery. The certificate is not bound with the ESN of the OMU board. That is, all Huawei
eCoordinators are preconfigured with the same Huawei-issued device certificate before delivery.
l Publication of the Huawei root certificate and CRLs
The Huawei root certificate and CRLs are published at http://support.huawei.com/
support/pki by using a web server or a Universal Serial Bus (USB) flash drive.
5.2 Certificate Management During Base Station

Deployment
Each Huawei base station is preconfigured with a Huawei-issued device certificate before
delivery. To connect to an operator's network deployed with a PKI system, the Huawei base
station must apply for an operator-issued device certificate during base station deployment.
This section describes a scenario where IPsec is used and digital certificates are used for
authentication. Figure 5-1 shows such an example.

SingleRAN
Figure 5-1 Example of automatic base station deployment in IPsec networking
Figure 5-2 shows the certificate application procedure during automatic base station
deployment.

SingleRAN
Figure 5-2 Certificate application procedure during automatic base station deployment
During automatic base station deployment, the Huawei-issued device certificate

preconfigured on the base station is used as follows:
l If the base station has obtained CA information from the DHCP server or USB flash
drive, the operator requires the base station to use an operator-issued device certificate
for authentication. The CA information includes the IP address of the CA and is used to
obtain certificates.
– If the base station has a valid operator-issued device certificate, the base station
directly uses this certificate.

SingleRAN
– If the base station fails to obtain the operator-issued device certificate or if the
request for the device certificate times out, the base station uses the preconfigured
Huawei-issued device certificate. If the base station cannot be automatically
deployed by using the Huawei-issued device certificate, it restarts and attempts to
obtain the operator-issued device certificate again.
l If the base station fails to obtain the CA information, the base station uses the
preconfigured Huawei-issued device certificate.
NOTE
l If an operator's network is deployed with a PKI system, it is recommended that the same operator-
issued device certificate be used for IPsec authentication, SSL authentication, and 802.1x-based
access control.
l During automatic base station deployment by plug and play (PnP), only Huawei-issued device
certificates can be used for authentication during 802.1x-based access control.
l By default, the same certificate is used for 802.1x-based access control and SSL authentication in
the operation phase.
l The name of the operator-issued device certificate used by a base station during base station
deployment must be OPKIDevCert.cer.
5.3 Certificate Management During Base Station

Controller Deployment
To connect to an operator's network deployed with a PKI system, the Huawei base station
controller must apply for a device certificate from the operator's CA. The operator-issued
device certificate can be applied for using a CMPv2-based certificate application procedure or
in manual mode depending on the type of preconfigured Huawei-issued device certificate.
Figure 5-3 shows a base station controller deployment procedure.

SingleRAN
Figure 5-3 Base station controller deployment procedure
A CMPv2-based certificate application procedure is triggered by the REQ DEVCERT

command. Figure 5-4 shows a manual certification application procedure.

SingleRAN
Figure 5-4 Manual certificate application procedure
For details about CMPv2-based and manual certification application procedures, see 8.12.2
Initial Configuration.
5.4 Certificate Management During eCoordinator

Deployment
The eCoordinator does not support CMPv2. During eCoordinator deployment, an operator-
issued device certificate must be applied for through the U2000.
eCoordinators can be classified into standalone ECO6910s and built-in ECO6910s. These two
types of eCoordinators use different certification application methods.
l Built-in ECO6910:
– If the POLICY parameter in the SET CERTPOLICY command is set to
SHARE(Share), the built-in ECO6910 synchronizes certificates from the host base
station controller, and you cannot manage certificates for the ECO6910. In this
case, configuring and querying the following MOs of the ECO6910 will fail:
TRUSTCERT, CERTMK, APPCERT, CRL, and CRLTSK.
For a built-in ECO6910, you only need to ensure deployment of the host base
station controller. For details, see 5.3 Certificate Management During Base
Station Controller Deployment.
INDEPENDENCY(Independency), certificates for the built-in ECO6910 are
independently configured and managed.
l Standalone ECO6910: Certificates for a standalone ECO6910 are independently
configured and managed.
When certificates for an eCoordinator can be independently configured and managed, an
SSL connection must be established between the eCoordinator and the U2000 using the
Huawei-issued device certificate, and then an operator-issued device certificate must be
manually applied for through the U2000, as illustrated in Figure 5-5.

SingleRAN
Figure 5-5 Manual certificate application procedure
For details about the manual certification application procedure, see 8.10.2 Initial
Configuration.
5.5 Certificate Management During the Operation Phase
5.5.1 Certificate Application

For details about how to apply for a certificate for the base station controller, see 5.3
Certificate Management During Base Station Controller Deployment. For details about
how to apply for a certificate for the eCoordinator, see 5.4 Certificate Management During
eCoordinator Deployment.
In the operation phase, if a base station needs to use an operator-issued device certificate for
IKE authentication but it does not have such a certificate, the base station must apply for an
operator-issued device certificate from the operator's CA based on CMPv2.
CMPv2-based certificate application of base stations is triggered in two modes:
l Manual mode
To manually trigger the application, O&M personnel can configure information such as
the certificate deployment location, CA, trust certificate, and certificate request on the
base station, and then run the REQ DEVCERT command to trigger a CMPv2-based
certificate application procedure. After this command is executed, the base station
reports the progress of the certificate application. If an operator-issued device certificate
is obtained, O&M personnel can run the MOD APPCERT command to change the
active certificate to the operator-issued device certificate.
NOTE
To ensure that the device certificate can be used to successfully establish secure channels between
the base station and the peer end, it is recommended that the TST APPCERT command be
executed to check whether the operator-issued device certificate can be used for IKE and SSL
connections before running the MOD APPCERT command. Then, run the CFM CB command to
enable automatic configuration data rollback. For details, see the CFM CB command help.
l Automatic mode

SingleRAN
The base station obtains information about the certificate deployment location, CA,
certificate request, and active certificate from the configuration file. After the base
station restarts, it automatically triggers a CMPv2-based certificate application procedure
based on CA information. If the application fails, the base station automatically
reinitiates a CMPv2-based certificate application procedure.
NOTE
After an IKE negotiation succeeds, the base station checks IKE negotiation status every 7 minutes.
If an IKE negotiation fails and digital certificates are used for identity authentication, the base
station checks the digital certificates used by the IKE negotiation. If a digital certificate is
abnormal (for example, the digital certificate has been revoked or expired, or the certificate file
does not exist), a certificate application procedure is automatically triggered.
For the CMPv2-based certificate application procedure, see 5.5.8 CMPv2-based Certificate
Management.
NOTE
Base stations cannot apply for certificates through E1/T1 ports.
5.5.2 Certificate Sharing
Base Station
The certificate that is applied for during base station deployment is configured on the board
that connects the base station to the transport network. SSL authentication applies only to the
main control board of a base station. If no certificate is deployed on the main control board
for SSL authentication, the main control board must share the certificate with the board that
connects the base station to the transport network.
Certificate sharing applies to the following scenarios:
l A certificate is deployed on a UTRPc board of a single-mode base station, and the main
control board shares the certificate with the UTRPc board. As indicated by (1) in Figure
5-6, the WMPT board shares the certificate with the UTRPc board.
l In co-transmission scenarios with a separate-MPT multimode base station, a certificate is
deployed on a main control board connecting to the transport network and is shared
between this main control board and the main control board of a different radio system.
As indicated by (2) in Figure 5-6, a certificate is deployed on the UMPT_L board and
shared between the UMPT_U and UMPT_L boards.
l In co-transmission scenarios with a separate-MPT multimode base station, a certificate is
deployed on a UTRPc board, and the main control board shares the certificate with the
UTRPc board. As shown by (3) in Figure 5-6, the UMPT_U and UMPT_L boards share
the certificate with the UTRPc board.
Figure 5-6 Examples of certificate sharing

SingleRAN
To implement certificate sharing on a base station, set the DEPLOYTYPE (eGBTS,

BSC6900, BSC6910) parameter in the CERTDEPLOY MO to SPECIFIC. Then, set CN
(eGBTS, BSC6900, BSC6910), SRN (eGBTS, BSC6900, BSC6910), and SN (eGBTS,
BSC6910, BSC6900) parameters in the CERTDEPLOY MO to specify the board that
provides a certificate for sharing.
Only active certificates can be shared. For example, SSL certificates, root certificates, and
CRLs can be shared.
NOTE
Huawei base stations support certificate sharing in backplane interconnection and BBU interconnection
scenarios but do not support this function in panel interconnection scenarios.
BBU3910As do not support certificate sharing.
Base Station Controller/eCoordinator

If the base station controller/eCoordinator uses the ESN of the active OMU board to apply for
a digital certificate during base station controller/eCoordinator deployment and the standby
OMU board or SAU board (only configured in a base station controller) needs to use the
digital certificate, the standby OMU board or SAU board must obtain the digital certificate
from the active OMU board.
Certificate sharing needs to be performed when:
l Active and standby OMU boards are switched over. The currently active OMU board can
use the digital certificate on the previously active OMU board to set up an SSL
connection with the U2000.
l The SAU board needs the digital certificate on the active OMU board to set up an SSL
connection with the Nastar. This scenario occurs only for base station controllers.
NOTE
During base station controller deployment, use the ESN of the active OMU board to apply for a digital
certificate. If the active OMU board becomes faulty and is removed, use the ESN of a functional OMU
board to apply for a new digital certificate.
5.5.3 Certificate Validity Check

If an expired certificate is not updated, a base station/base station controller/eCoordinator that
uses the certificate cannot be authenticated to access the operator's network. To prevent this
problem, base stations/base station controllers/eCoordinators periodically check the validity
periods of certificates. The ISENABLE parameter specifies whether to enable certificate
validity checks. The PERIOD parameter specifies the interval between two consecutive
certificate validity checks. When certificate validity checks are enabled, the base station/base
station controller/eCoordinator periodically checks certificate validity as follows:
l Upon detecting that the period remaining until a certificate expires is less than the value
of the ALMRNG parameter, the base station/base station controller/eCoordinator
determines that the certificate is about to expire.
l Upon detecting that the expiration time of a certificate is earlier than the current time, the
base station/base station controller/eCoordinator determines that the certificate has
expired.
Table 5-1 describes the processing performed by the base station/base station controller/
eCoordinator when it detects that the device certificate is abnormal.

SingleRAN
Table 5-1 Processing performed when a device certificate detected abnormal

Certificate Certificate Is Value of Processing
Validity in Use or UPDATEME
Status Not THOD
(BSC6900,
BSC6910,
eGBTS)
Is about to In use CMP The base station/base station controller

expire automatically triggers a CMPv2-based
certificate update procedure. If the
certificate update fails, the base station
reports ALM-26842 Automatic
Certificate Update Failed or the base
station controller reports ALM-20803
Certificate Auto-update Failed to the
U2000. Subsequently, if the certificate
has been successfully updated or the
corresponding CERTMK managed
object (MO) has been deleted, the
alarm is cleared.
In use MANUAL The base station reports ALM-26840

Imminent Certificate Expiry or the
Not in use N/A base station controller/eCoordinator
reports ALM-20850 Digital Certificate
Will Be out of Valid Time to the
U2000. Subsequently, if the certificate
has been updated or the corresponding
CERTMK MO has been deleted, the
alarm is cleared.
Expired N/A N/A The base station reports ALM-26841

Certificate Invalid or the base station
controller/eCoordinator reports
ALM-20851 Digital Certificate Loss,
Expiry, or Damage to the U2000,
reminding the O&M personnel to
determine the cause and update the
certificate as soon as possible.
Subsequently, if the certificate has been
updated or the corresponding
CERTMK MO has been deleted, the
alarm is cleared.

SingleRAN
NOTE
l You can specify the device certificate to be used through:

1. The MOD APPCERT command
2. The certificate source in the ADD IKEPEER command
l Certificate validity checks require that the time of the base station/base station controller/
eCoordinator be the same as the local time. If they are different, alarms may fail to be reported.
l Each time a base station is reset, a certificate validity check task is added to immediately check
certificate validity. If the certificate is about to expire, the base station triggers an automatic
certificate update procedure.
5.5.4 Certificate Update

Device certificates used by base stations/base station controllers/eCoordinators are Huawei-
issued device certificates and operator-issued device certificates. This section only describes
how to update operator-issued device certificates. Huawei-issued device certificates do not
need to be updated because:
l Huawei-issued device certificates are used to ensure security during certificate
application.
l Generally, Huawei-issued device certificates are used only during base station/base
station controller/eCoordinator deployment.
l The lifecycle of Huawei-issued device certificates is usually longer than that of the
devices.
Certificate Update Scenarios

A certificate used by a base station/base station controller/eCoordinator must be updated in
the following scenarios:
l The certificate is about to expire.
l Base station/base station controller/eCoordinator information, such as the time and
location, has changed.
Certificate Update of the Base Station and Base Station Controller

A certificate update is triggered on the base station or base station controller in two modes:
l Automatic mode
A task of periodically checking the certificate validity is configured on the base station
or base station controller and the UPDATEMETHOD (eGBTS, BSC6900, BSC6910)
parameter is set to CMP. Upon detecting that a certificate is about to expire, the base
station or base station controller automatically triggers a CMPv2-based certificate
update. In automatic mode, a private-public key pair is also automatically updated during
the certificate update.
NOTE
During an automatic certificate update procedure, if the certificate update fails due to intermittent
transmission or network congestion, the system automatically retries certificate update for at most
twice with an interval of 10 minutes.
l Manual mode
O&M personnel can run the UPD DEVCERT command to manually trigger a CMPv2-
based certificate update. In this command, the APPCERT parameter specifies a

SingleRAN
certificate to be updated, the REKEY parameter specifies whether to update a private-

public key pair, and the KEYSIZE parameter specifies a key length. After this command
is executed, the base station or base station controller reports the progress of the
certificate update.
During the certificate update, the base station or base station controller automatically
configures a new certificate and tests it. If the configuration or test of the new certificate fails,
the base station reports ALM-26842 Automatic Certificate Update Failed or the base station
controller reports ALM-20803 Certificate Auto-update Failed. In this scenario, the original
certificate will be used until a successful certificate update occurs.
NOTE
Bidirectional authentication is used for SSL certificate testing. That is, the base station/base station
controller and U2000 authenticate the device certificates of each other. The SSL certificate testing result
reflects whether the certificates can be used.
In IPsec scenarios, a new certificate is tested by using the certificate for authentication during
IKE renegotiation. In SSL scenarios, a new certificate is tested by using the certificate for
authentication during SSL reconnection. If the IKE renegotiation or SSL reconnection fails,
the base station uses the original certificate. The base station controller only supports the SSL
scenarios. If SSL reconnection fails, the base station controller uses the original certificate.
NOTE
The eGBTS configured with a GTMUb does not support SSL certificate testing.
Certificate Update of the eCoordinator

eCoordinators can be classified into standalone ECO6910s and built-in ECO6910s. These two
types of eCoordinators use different certification update methods.
l Built-in ECO6910
SHARE(Share), the built-in ECO6910 synchronizes certificate updates from the
host base station controller.
INDEPENDENCY(Independency), certificates for the built-in ECO6910 are
independently configured and managed.
l Standalone ECO6910
Certificates for a standalone ECO6910 are independently configured and managed.
When certificates for an eCoordinator can be independently configured and managed, the
procedure for certificate update is as follows:
1. Run the SET CERTCHKTSK command to set a periodic certificate validity check task.
2. The eCoordinator does not support CMPv2. When the eCoordinator reports a certificate
expiry alarm, the certificate needs to be manually updated. The manual update procedure
is the same as a certificate application procedure. For details, see 5.4 Certificate
Management During eCoordinator Deployment.
5.5.5 Certificate Revocation

If a base station/base station controller/eCoordinator is no longer used or the private key of its
device certificate is disclosed or cracked before the certificate expires, the certificate must be
revoked to prevent illegal use of the certificate. Currently, the base station/base station

SingleRAN
controller/eCoordinator does not support online certificate revocation. Certificates must be

manually revoked. Figure 5-7 shows the base station's certificate revocation process. The
base station controller's/eCoordinator's certificate revocation process is identical to this
process.
Figure 5-7 Base station's certificate revocation process
If the base station finds that the operator-issued device certificate was revoked based on the
CRL file, the base station initiates a certificate application procedure. If the base station is
discarded, the certificate application request will be rejected by the CA and no new device
certificate will be issued.
5.5.6 CRL Acquisition

A base station/base station controller/eCoordinator periodically obtains CRLs from the
certificate & CRL database. The CRLs are used to verify the validity of the certificate of the
peer device.
Table 5-2 lists the methods to obtain CRLs.
Table 5-2 Methods to obtain CRLs

Mode Method to Obtain CRLs Type of CRL Server Supported By
Manual Users run MML commands to FTP server Base station/base

enable the base station or base station controller/
station controller to obtain the eCoordinator
CRLs from the FTP server.
Automa Scheduled tasks are LDAP server Base station/base

tic configured so that CRLs can station controller
be automatically obtained.
FTP server Base station/base
station controller/
eCoordinator
To enable the base station/base station controller/eCoordinator to automatically obtain CRLs,

set IP to the IP address of the CRL server and set CRLGETMETHOD to the method of
obtaining CRLs. In addition, if the LDAP server is used, set SEARCHDN and PORT to
specify the name of the LDAP server and the port number. The ISCRLTIME parameter
specifies whether to automatically download CRLs after a CRL update period (specified by
the PERIOD parameter) has elapsed.

SingleRAN
The CRL can be obtained by using SSL-protected transmission mode:
l If the CRL is obtained using LDAP, the CONNMODE (eGBTS, BSC6900, BSC6910)
and AUTHPEER (eGBTS, BSC6900, BSC6910) parameters must be set. If the
AUTHPEER (eGBTS, BSC6900, BSC6910) parameter is set to ENABLE, ensure that
both the base station/base station controller and the CRL server are configured with the
peer device certificate and the peer CA trust certificate.
NOTE
If the CRL is obtained using LDAP and the base station/base station controller supports only
LDAPv3, the CRL server must support LDAPv3. For details, see IETF RFC 4511 Lightweight
Directory Access Protocol (LDAP).
l If the CRL is obtained using FTP over SSL (FTPS), set ENCRYMODE (eGBTS,
BSC6900, BSC6910) to AUTO(Auto) or ENCRYPTED(SSL Encrypted) on the base
station/base station controller/eCoordinator side, and enable the FTPS function on the
CRL server side. If this parameter is set to ENCRYPTED(SSL Encrypted), ensure that
all FTP servers communicating with the base station/base station controller/eCoordinator
support FTPS.
If the CRL server needs to be authenticated, set the SSLCERTAUTH (BSC6900,
eGBTS, BSC6910) parameter to YES(Yes). In addition, ensure that the base station/base
station controller/eCoordinator has been configured with the peer CA trust certificate and
the CRL server has been configured with a device certificate.
NOTE
l If the FTPS client is not configured with a device certificate, the CRL server cannot
authenticate the FTPS client.
l Each time a base station is reset, a periodical CRL update task is added.
5.5.7 Offline Certificate Monitoring

If a board leaves the customer's network due to board repair or retirement, the certificate and
private key on the board may be disclosed. Therefore, the offline certificate monitoring
function is required. This function allows users to use the U2000 to query and export basic
information about abnormal certificates, including the base station name, certificate issuer
name, certificate serial number, status, and time when the certificate is detected abnormal.
Currently, this function can take effect only for offline certificates on base stations.
NOTE
Basic information about abnormal certificates will be saved on the U2000 for 30 days and then be
automatically removed. The purpose is to avoid repeatedly exporting certificate information.
The status of a certificate may be abnormal in the following conditions:
l The certificate does not exist, for example, when the board is returned for repair.
l The U2000 deletes the NE where the certificate is deployed.
l The U2000 cannot communicate with the NE, where the certificate is deployed, for a
long time (for example, when the NE leaves the network).
l The certificate is deleted manually. The operator needs to ensure that a manually deleted
certificate has been revoked by the CA. The information about a deleted certificate will
be saved on the U2000 for a period. After the period expires, the information is
automatically deleted.
Figure 5-8 shows the principle of offline certificate monitoring.

SingleRAN
Figure 5-8 Principle of offline certificate monitoring
In the following scenarios, the device certificate on the base station does not need to be
revoked although the device certificate status is abnormal on the U2000:
l The base station operates normally but cannot communicate with the U2000 for a long
time.
l The base station or its board is transferred to another U2000 for management. In this
case, the device certificate of the base station or board is recorded as abnormal on the
original U2000.
l The value of DEPLOYTYPE is changed to NULL, which indicates that the device
certificate on the base station is not applied. In this situation, the certificate status on the
U2000 is that the certificate does not exist.
If the certificate must be revoked, you need to manually run the certificate revocation
command on the CA.
The offline certificate monitoring function cannot be used in the following conditions:
l This function does not take effect for the preconfigured Huawei-issued device
certificates. The name of the issuer of the preconfigured Huawei-issued device
certificates starts with "Huawei". Therefore, it is not recommended that the name of the
issuer of operator-issued device certificates start with "Huawei".
l If the base station cannot communicate with the U2000 after obtaining a device
certificate, the U2000 cannot record the information about the device certificate. In this
case, the U2000 cannot monitor the device certificate.
l During the period when base station software is rolled back to a version not supporting
offline certificate monitoring, the U2000 cannot update certificate status. After base
station software is upgraded to a version supporting offline certificate monitoring, the
U2000 can update certificate status.
The offline certificate monitoring function does not need to be activated. You can query and
export the basic information about abnormal certificates on the U2000. For details, see 8.5.3
Activation Observation and 8.6.3 Activation Observation.
5.5.8 CMPv2-based Certificate Management

On secure networks, the base station/base station controller can automatically apply for
operator-issued device certificates and update certificates using CMPv2. The eCoordinator
does not support CMPv2-based certificate management.
CMPv2 complies with IETF RFC 4210, IETF RFC 4211, and draft-ietf-pkix-cmp-transport-
protocols-07. The base station/base station controller/U2000 uses Hypertext Transfer
Protocol/Hypertext Transfer Protocol Secure (HTTP/HTTPS) as the bearer protocol for
CMPv2. Figure 5-9 shows the transport protocol stack for CMPv2.

SingleRAN
Figure 5-9 Transport protocol stack for CMPv2
Figure 5-10 shows the topology for managing certificates in base stations and base station
controllers based on CMPv2.
Figure 5-10 Example topology for CMPv2-based certificate management
As shown in Figure 5-10, base stations or base station controllers communicate with the
operator's PKI server for CMPv2-based certificate management. The PKI server can be a CA,
RA, or certificate & CRL database.
When the base stations or base station controllers apply for operator-issued device certificates
for the first time, the operator's CA is preconfigured with the Huawei root certificate. The root
certificate is used to verify Huawei-issued device certificates carried in CMPv2 messages sent
by the base stations or base station controllers. The operator's CA also includes operator-
issued device certificates and root certificates or certificate chains in CMPv2 response
messages sent to the base stations or base station controllers.
When the base stations or base station controllers update certificates, the operator's CA and
the base stations or base station controllers authenticate each other using operator-issued
device certificates and operator's root certificates or certificate chains. In this case, Huawei-
issued device certificates and Huawei root certificates are no longer used.
Figure 5-11 shows how a base station or base station controller applies for a certificate based
on CMPv2.

SingleRAN
Figure 5-11 Certificate application process for a base station or base station controller
NOTE
After sending a CMPv2-based certificate request message, the base station waits for a response from the
CA. The waiting timeout interval is 60s in single-operator PKI scenarios and 20s for each PKI in multi-
operator PKI scenarios. If the base station does not receive any response from the CA before the waiting
timeout interval elapses, the certificate application fails.
In step 2, the message contains information such as the generated public key, SubjectName
field of the certificate, backup SubjectName field of the certificate, certificate signature
algorithm, and Huawei-issued device certificate.
l The SubjectName field in the certificate request message contains the Common Name
field. Some CAs require that the Common Name field in certificate request messages be
the same as that in Huawei-issued device certificate. If they are not the same, these CAs
will not issue device certificates (also known as operator-issued device certificates).
l In Huawei-issued device certificates preconfigured on some LMPT boards, the Common
Name field uses the format of ESN+space+eNodeB. In this case, to meet the preceding
CA requirement, a space is automatically added to the Common Name field in the
certificate request message if the values of the COMMNAME and USERADDINFO
parameters are ESN and eNodeB, respectively. In this way, the Common Name field in
the message is in the format of ESN+space+eNodeB. If the LOCALNAME parameter is

SingleRAN
not specified, the DNSName field in the backup SubjectName field also uses the format
of ESN+space+eNodeB.
Figure 5-12 shows how a base station or base station controller updates its certificate based
on CMPv2.
Figure 5-12 CMPv2-based certificate update process for a base station or base station
controller
In step 2, the key update request message is also the certificate update request. This message
includes the new public key and the operator-issued device certificate to be updated.
In step 5, the CA uses the public key of the operator-issued device certificate carried in the
key update request message to verify the signature in the message. In addition, the CA uses
the operator's root certificate or certificate chain to verify the operator-issued device
certificate.
For details about the structure of a CMPv2 message and the process of exchanging CMPv2
messages, see IETF RFC 4210 and IETF RFC 4211.

SingleRAN
5.6 PKI Networking Reliability

To improve the reliability of PKI-based secure networks, both the base station and base
station controller support PKI redundancy. The eCoordinator does not support PKI
redundancy.
To achieve PKI redundancy, two PKI servers must be deployed on the network. There should
be reachable routes between the base station/base station controller and the two PKI servers.
In addition, the following conditions should be met:
l The two PKI servers have the same CANAME and root certificate or certificate chain
and synchronize certificate management databases between them.
l The two CAs must have different IP addresses, and so do active and standby CRL
servers.
Every time before certificate application, certificate update, and CRL acquisition, the base
station or base station controller first initiates a session with the active PKI server. If the
session fails, the base station or base station controller reinitiates a session with the standby
PKI server. This mechanism ensures successful certificate applications and updates as well as
CRL acquisitions.
Figure 5-13 Working principles of PKI redundancy
For both the base station and base station controller, the SLVURL (BSC6900, eGBTS,
BSC6910) and SLVINITREQURL parameters have been added to the CA MO to specify the
URL of the standby CA; the SLVIP (eGBTS, BSC6900, BSC6910), SLVPORT (eGBTS,
BSC6900, BSC6910), SLVUSR (eGBTS, BSC6900, BSC6910), and SLVPWD (eGBTS,
BSC6900, BSC6910) parameters have been added to the CRLTSK MO to specify the login
information of the standby CRL server.
During certificate updates or CRL acquisitions, the base station/base station controller reports
ALM-26842 Automatic Certificate Update Failed only when the sessions between the base
station/base station controller and both the active and standby PKI servers fail.
The following network elements support PKI redundancy: eGBTS, NodeB, eNodeB, GBTS
(configured with GTMUb/GTMUc and UMPT_L/LMPT boards), BSC, and RNC.
PKI redundancy has the following application limitations:

SingleRAN
PKI redundancy is not supported during base station deployment by PnP. The operator must
ensure that the active PKI server works properly during base station deployment by PnP.
5.7 Certificate Usage in UMPT+UMPT Cold Backup Mode

In UMPT+UMPT cold backup mode, only one UMPT works at a time. The two UMPT
boards are deployed in the same logical slot and configured with the same logical slot number.
The data configuration for the certificate deployment location specifies the bound logical slot
number.
NOTE
For the description of UMPT cold backup and the definition of logical slot numbers, see Base Station
Equipment Reliability Feature Parameter Description.
UMDUs cannot be used in UMPT+UMPT cold backup mode.
During the deployment phase, apply for the operator-issued device certificate only for the
active UMPT.
During the operation phase, a CMPv2-based certificate application is triggered if all the
following conditions are met:
l The active UMPT becomes faulty.
l The active and standby UMPT boards are switched over.
l The standby UMPT determines that an operator-issued device certificate must be applied
for based on the configuration file.
The two UMPT boards manage and use their own certificates.
NOTE
In UMPT+UMPT cold backup mode, if both IPsec and PKI are deployed, the IDTYPE parameter in the
IKEPEER MO can be set to IP or FQDN on the base station side. If this parameter is set to FQDN, the
SeGW should not check the ID of the base station.
5.8 Digital Certificate Whitelist Management

If no PKI system is deployed on an operator's network, the base station cannot use an
operator-issued device certificate to access the operator's network. In this case, the base
station can use the digital certificate whitelist management function to access the operator's
network.
A digital certificate whitelist is a list of Common Name in the Huawei-issued device
certificates preconfigured on the base station and SeGW.
NOTE
To support the digital certificate whitelist management, both the base station and SeGW must be Huawei
equipment and be preconfigured with Huawei-issued device certificates.
A digital certificate whitelist is configured on the U2000 and then loaded onto the base
station. During IKE negotiation for IPsec tunnel establishment, the base station uses the
digital certificate whitelist to authenticate each piece of equipment that expects to establish an
IPsec tunnel with the base station. The base station can perform IKE negotiation and establish
IPsec tunnels only with the equipment in the whitelist. IPsec tunnels cannot be established
between the base station and any equipment not in the whitelist.

SingleRAN
NOTE
The digital certificate whitelist is used for authentication between base stations only when there are links
(for example, the X2 interface) between them or base stations are cascaded.
Digital certificate whitelist management has the following application limitations:

l Only Huawei-issued device certificates can be used for authentication. Security risks
exist if Huawei-issued device certificates are always used for authentication. For details,
see 4.1 Device Certificate.
l The digital certificate whitelist management function supports only IKE/IPsec
negotiation and does not support other types of security channels (such as SSL).

SingleRAN
PKI Feature Parameter Description 6 Related Features
6 Related Features
6.1 GBFD-113526 BTS Supporting PKI

Prerequisite Features
Feature ID Feature Name Description
GBFD-118601 Abis over IP N/A
Mutually Exclusive Features

None
Impacted Features
None
6.2 WRFD-140210 NodeB PKI Support

WRFD-050402 IP Transmission N/A

Introduction on Iub
Interface

None

SingleRAN
Impacted Features
None
6.3 LOFD-003010 Public Key Infrastructure (PKI)

None

None
Impacted Features
None
6.4 TDLOFD-003010 Public Key Infrastructure (PKI)

None

TDLOFD-001134 Virtual Routing and N/A

Forwarding
Impacted Features
None
6.5 GBFD-160211 BSC Supporting PKI

None

None

SingleRAN
Impacted Features
Feature ID Feature Name Impact
GBFD-113522 Encrypted Network N/A

Management
6.6 WRFD-160276 RNC Supporting PKI

None

None
Impacted Features
MRFD-210305 Security Management N/A
6.7 GBFD-160210 BTS Supporting PKI Redundancy

GBFD-113526 BTS Supporting PKI N/A

None
Impacted Features
None

SingleRAN
6.8 GBFD-160208 BSC Supporting PKI Redundancy

GBFD-160211 BSC Supporting PKI N/A

None
Impacted Features
None
6.9 WRFD-160275 NodeB Supporting PKI Redundancy

WRFD-140210 NodeB PKI Support N/A

None
Impacted Features
None
6.10 WRFD-160277 RNC Supporting PKI Redundancy

WRFD-160276 RNC Supporting PKI N/A

None

SingleRAN
Impacted Features
None
6.11 LOFD-070212 eNodeB Supporting PKI Redundancy

LOFD-003010 Public Key N/A


None
Impacted Features
None
6.12 TDLOFD-070212 eNodeB Supporting PKI

Redundancy
TDLOFD-003010 Public Key N/A


None
Impacted Features
None

SingleRAN
6.13 GBFD-181202 BTS Supporting Digital Certificate

GBFD-113524 BTS Integrated IPSec N/A

None
Impacted Features
None
6.14 WRFD-181220 NodeB Supporting Digital Certificate

WRFD-140209 NodeB Integrated IPSec N/A

None
Impacted Features
None
6.15 LOFD-111203 eNodeB Supporting Digital Certificate

LOFD-003009 IPsec N/A

SingleRAN

None
Impacted Features
None
6.16 eCoordinator Supporting PKI

None

None
Impacted Features
None

SingleRAN
PKI Feature Parameter Description 7 Network Impact
7 Network Impact
System Capacity
No impact.
Network Performance
During base station or base station controller deployment, the certificate application process
takes about 10s.

SingleRAN
PKI Feature Parameter Description 8 Engineering Guidelines for PKI
8 Engineering Guidelines for PKI
8.1 When to Use

A Huawei-issued device certificate can meet the basic transmission security requirements, but
it does not support online update. Therefore, directly using a Huawei-issued device certificate
on the network has security risks. It is recommended that the operator build a PKI system on
the live network and use the operator's device certificate to replace the Huawei-issued device
certificate, so that the operator's device certificate can be updated online, which minimizes
security risks.
To interconnect the operator's base stations and base station controllers on the live network
with the PKI system, enable the PKI feature for the base stations and base station controllers.
8.2 Required Information

Before deploying the PKI feature for a base station or base station controller, engineering
personnel must obtain CA information from CA maintenance personnel. The following table
lists the CA information that needs to be collected.
Items to Be Collected Required Parameter on the Base Station or

Base Station Controller Side
CA name CANAME (eGBTS, BSC6910, BSC6900)
Uniform resource locator (URL) URL (eGBTS, BSC6900, BSC6910)

of the CA INITREQURL (optional)
Signature algorithm for CMP SIGNALG (eGBTS, BSC6910, BSC6900)

messages
Signature algorithm for the CA to SIGNALG (eGBTS, BSC6910, BSC6900)

issue certificates
Size of the certificate key KEYSIZE (eGBTS, BSC6910, BSC6900)
Use of the certificate key KEYUSAGE (eGBTS, BSC6910, BSC6900)

SingleRAN
Items to Be Collected Required Parameter on the Base Station or

Base Station Controller Side
Local name of the certificate LOCALNAME (eGBTS, BSC6910, BSC6900)
File name of the root certificate or CERTNAME

certificate chain
IP address of the CRL server IP (eGBTS, BSC6910, BSC6900)

(optional)
User name for logging in to the USR

CRL server (optional)
Password for logging in to the PWD (eGBTS, BSC6900, BSC6910)

CRL file name (optional) FILENAME (eGBTS, BSC6910, BSC6900)
Method of obtaining the CRL file CRLGETMETHOD (eGBTS, BSC6900, BSC6910)

(optional)
Name of the CRL server (optional) SEARCHDN (eGBTS, BSC6910, BSC6900)
Port number of the CRL server PORT (eGBTS, BSC6910, BSC6900)

(optional)
Before deploying the PKI feature for an eCoordinator, engineering personnel must obtain CA
information from CA maintenance personnel. The following table lists the CA information
that needs to be collected.
Items to Be Collected Required Parameter on the eCoordinator Side
Signature algorithm for the CA to SIGNALG

issue certificates
Size of the certificate key KEYSIZE
Use of the certificate key KEYUSAGE
Local name of the certificate LOCALNAME
File name of the trust certificate or CERTNAME

certificate chain
IP address of the CRL server IP

(optional)
User name for logging in to the USR

Password for logging in to the PWD

CRL file name (optional) FILENAME

SingleRAN
Items to Be Collected Required Parameter on the eCoordinator Side
Method of obtaining the CRL file CRLGETMETHOD

(optional)
Before deploying the PKI redundancy feature, engineering personnel also need to collect the
following information.
Items to Be Collected Required Parameter on the Base Station or Base

Station Controller Side
URL of the standby CA SLVURL (eGBTS, BSC6900, BSC6910)

SLVINITREQURL (optional)
IP address of the standby CRL SLVIP (eGBTS, BSC6910, BSC6900)

server (optional)
User name for logging in to the SLVUSR (eGBTS, BSC6900, BSC6910)

standby CRL server (optional)
Password for Logging in to the SLVPWD (eGBTS, BSC6900, BSC6910)

standby CRL server (optional)
Port number of the standby CRL SLVPORT (eGBTS, BSC6900, BSC6910)

server (optional)
8.3 Hardware Planning

Table 8-1 lists the hardware to be configured in base stations to support PKI.
Table 8-1 PKI hardware requirements

NE Hardware
GBTS l GTMUb/GTMUc+UMPT_L/LMPT
l GTMUb+UTRPc
eGBTS UMPT_G/UMDU_G/GTMUb/GTMUc
NodeB UMPT_U/UTRPc/UMDU_U
eNodeB UMPT_L/UMPT_T/LMPT/UTRPc/UMDU_L/UMDU_T
Multimode UMPT_G/UMDU_G/UMPT_U/UMDU_U/UMPT_L/UMPT_T/
base station UMDU_L/UMDU_T/LMPT/UTRPc
Base station l OMU

controller l SAU (the SAU obtains digital certificates from the OMU)
eCoordinator OMU

SingleRAN
8.4 Requirements
PKI Deployment Requirements
l Other Features
See Related Features.
l Hardware
Table 8-2 PKI hardware requirements

NE Hardware
GBTS l GTMUb/GTMUc+UMPT_L/LMPT
l GTMUb+UTRPc
eGBTS UMPT_G/UMDU_G/GTMUb/GTMUc
NodeB UMPT_U/UTRPc/UMDU_U
eNodeB UMPT_L/UMPT_T/LMPT/UTRPc/UMDU_L/UMDU_T
Multimode UMPT_G/UMDU_G/UMPT_U/UMDU_U/UMPT_L/UMPT_T/
base station UMDU_L/UMDU_T/LMPT/UTRPc
Base station l OMU

controller l SAU (the SAU obtains digital certificates from the OMU)
eCoordinator OMU
l License
The licenses for the PKI feature have been activated for the base station and base station
controller. To support the PKI feature, the eCoordinator does not require a license. The
following table lists the licenses controlling PKI.
Feature ID Feature License License NE Sales
Name Control Control Unit
Item ID Item Name
GBFD-1135 BTS LGMIB BTS BSC6900& per BTS

26 Supporting TSPKI Supporting BSC6910
PKI PKI (per
BTS)
WRFD-1402 NodeB PKI LQW9P NodeB PKI NodeB per

10 Support KI01 support(per NodeB
NodeB)

SingleRAN

Name Control Control Unit
Item ID Item Name
LOFD-00301 Public Key LT1S00 Public Key Macro per

0 Infrastructure 0PKI00 Infrastructure eNodeB/ eNodeB
(PKI) (PKI) LampSite
eNodeB/
Micro
eNodeB
TDLOFD-00 Public Key LT1ST0 Public Key eNodeB per

3010 Infrastructure 0PKI00 Infrastructure eNodeB
(PKI) (PKI)
GBFD-1602 BSC LGMIP BSC BSC6900& per TRX

11 Supporting KI Supporting BSC6910
PKI PKI (per
TRX)
WRFD-1602 RNC LQW1P RNC BSC6900 per Erl

76 Supporting KIE Supporting BSC6910
PKI PKI (per Erl)
WRFD-1602 RNC LQW1P RNC BSC6900 per Mbps

76 Supporting KIM Supporting BSC6910
PKI PKI (per
Mbps)
NOTE
The rules for activating the license controlling PKI for a multimode base station are as follows:
l In co-transmission scenarios with a separate-MPT multimode base station, the license controlling
PKI needs to be activated for the mode that provides a transmission port. If another mode requires
certificate sharing, the license controlling PKI must also be activated for this mode.
l If a UTRPc board is used to connect to the transport network, the license controlling PKI must be
activated for the mode that manages the board.
For a BSC6900 GU or BSC6910 GU, the license controlling PKI only needs to be activated for one
mode, that is, you can activate either the license for the BSC Supporting PKI feature or the license for
the RNC Supporting PKI feature.
l Other Requirements
– A PKI server is deployed on the operator's network.
– Operator-issued device certificates and CRLs comply with IETF RFC 5280.
– The operator's CA supports CMPv2 defined in IETF RFC 4210, and the format of
certificate request messages complies with IETF RFC 4211.
– As stipulated in 3GPP TS 33.310, the Initialization Response message sent by the
operator's CA contains the operator's root certificate or certificate chain.
– The operator's CA is preconfigured with the Huawei root certificate.
PKI Redundancy Deployment Requirements

l Other Features

SingleRAN
See Related Features.

l Hardware
For details, see Table 8-2.
l License
The licenses for the PKI Redundancy feature have been activated for the base station and
base station controller. The following table lists the licenses controlling PKI
Redundancy.
Name Control Control Item Unit
Item ID Name
GBFD-1602 BTS LGB3BTS BTS BTS Per BTS

10 Supporting PKIR Supporting
PKI PKI
Redundancy redundancy
(per BTS)
WRFD-1602 NodeB LQW9PKI NodeB NodeB Per

75 Supporting RD01 supporting PKI NodeB
PKI redundancy
Redundancy (per NodeB)
LOFD-0702 eNodeB LT1SESP eNodeB Macro Per

12 Supporting KIR00 Supporting eNodeB eNodeB
PKI PKI /
Redundancy Redundancy(F LampSit
DD) e
eNodeB
/
BTS320
2E
TDLOFD-07 eNodeB LT1SENB eNodeB eNodeB Per

0212 Supporting SPR00 Supporting eNodeB
PKI PKI
Redundancy Redundancy(T
DD)
GBFD-1602 BSC LGMIPKI BSC BSC690 Per TRX

08 Supporting RED Supporting 0&BSC
PKI PKI 6910
Redundancy redundancy
(per TRX)
WRFD-1602 RNC LQW1PKI RNC BSC690 Per Erl

77 Supporting REDE supporting PKI 0
PKI redundancy BSC691
Redundancy (per Erl) 0

SingleRAN

Name Control Control Item Unit
Item ID Name
WRFD-1602 RNC LQW1PKI RNC BSC690 Per Mbps

77 Supporting REDM supporting PKI 0
PKI redundancy BSC691
Redundancy (per Mbps) 0
l Other Requirements
– Two PKI servers are deployed on the operator's network. For the requirements for
PKI servers, see PKI Deployment Requirements.
– The two PKI servers have the same CA name and root certificate or certificate
chain and synchronize certificate management databases between them.
– There are reachable routes between the base station/base station controller/
eCoordinator and the two PKI servers.
8.5 Deployment of PKI on the eGBTS/NodeB/eNodeB/

Multimode Base Station
This section uses the networking illustrated in Figure 8-1 as an example to describe how to
deploy the PKI feature on the eGBTS, NodeB, eNodeB, or multimode base station.
NOTE
A UMDU can be used in a co-MPT multimode base station in the secure networking shown in Figure
8-1. However, a UMDU cannot be used in a separate-MPT multimode base station.
This section describes how to deploy PKI on an eGBTS using a GTMUc, UMPT, or UMDU. For details
about how to deploy PKI on an eGBTS using a GTMUb, see 8.6 Deployment of PKI on the eGBTS
using a GTMUb.

SingleRAN
Figure 8-1 Example of the secure networking for the eGBTS/NodeB/eNodeB/multimode

base station
8.5.1 Data Preparation

NOTE
In the following tables, "N/A" indicates that there is no special requirement for the parameter setting.
You can set the parameter based on site requirements.
Table 8-3 lists the data to be prepared for the deployment location of a certificate on the base
station (the CERTDEPLOY MO in MML and CME configurations).
Table 8-3 Data to be prepared for the deployment location of a certificate
Parameter Parameter ID Setting Notes Data

Name Sour
ce
Certification DEPLOYTYPE If a digital certificate is deployed on a Netw

Deploy Position main control board, this parameter ork
Type must be set to DEFAULT. If a digital plan
certificate is deployed on another
board in a specified slot, this parameter
must be set to SPECIFIC. If no digital
certificate is deployed on the base
station, this parameter must be set to
NULL.
Cabinet No. CN N/A

SingleRAN

Name Sour
ce
Subrack No. SRN
Slot No. SN
Table 8-4 lists the data to be prepared for a certificate request template (the CERTREQ MO
in MML and CME configurations).
Table 8-4 Data to be prepared for a certificate request template

Name Sour
ce
Common Name COMMNAME The default value of the Common Netw

Name field in a certificate request file ork
is XXX.huawei.com (XXX indicates the plan
ESN of the board connecting to the
transport network). The recommended
value of this parameter is ESN.
Currently, this parameter cannot be set
to MAC or IP.
Common Name USERADDINFO N/A

Additional Info.
Country COUNTRY N/A
Organization ORG N/A
Organization ORGUNIT N/A

Unit
State or STATEPROVINCEN N/A

Province AME
Locality LOCALITY N/A

SingleRAN

Name Sour
ce
Key Usage KEYUSAGE The recommended values are

DIGITAL_SIGNATURE and
KEY_ENCIPHERMENT. If this
parameter is set to
DIGITAL_SIGNATURE, the key is
used to verify the peer's digital
signature during a CMPv2-based
certificate application or update, IKE
negotiation, and SSL authentication. If
this parameter is set to
KEY_ENCIPHERMENT, the key is
used to encrypt transmission data
during IKE negotiation, IPsec
negotiation, or SSL-based key
exchange.
Signature SIGNALG l SHA256 is recommended.

Algorithm l MD5 is not recommended for use
because it provides low security.
Key Size KEYSIZE N/A
Local Name LOCALNAME If this parameter is not set, the default

value of the Common Name field in a
certificate is used. If this parameter is
set, the value of the Local Name field
in a certificate must be the same as the
value of this parameter.
Local IP LOCALIP If IDTYPE is set to IP(IP Identify),

the value of this parameter must be the
same as the value of LOCALIP in the
IKEPEER MO.
The base station must be configured with CA information to apply for a certificate from the
CA. Table 8-5 lists the data to be prepared for the CA (the CA MO in MML and CME
configurations).

SingleRAN
Table 8-5 Data to be prepared for the CA

Name Sour
ce
Certificate CANAME This parameter indicates the name of Netw

Authority the CA on the operator's PKI server. ork
Name During a CMPv2-based certificate plan
procedure, the value of the Recipient
field in a CMPv2 message sent to the
CMP server equals the value of this
parameter. For details about how to
configure this parameter, see Figure
8-2.
For example, if the values of the C, S,
L, O, OU, CN, and E fields in the
Subject name of a certificate used for
signing CMP messages on the CA/RA
are AU, Some-State, cd, Internet
Widgits Pty Ltd, Wireless, eca1, and
rosa@huawei.com, respectively,
CANAME for the organization must
be set to C = AU, S = Some-State, L =
cd, O = Internet Widgits Pty Ltd,
OU = Wireless, CN = eca1, E =
rosa@huawei.com. To prevent errors
during the execution of the REQ
DEVCERT command, all of the
following conditions must be met: The
character type for the C, S, L, O, OU,
and CN fields is PRINTABLE. The
character type for the E field is IA5.
The S field can be replaced with the ST
field. For a base station, the S and ST
fields are regarded as the same field.
For details about the character set of
the PRINTABLE type, see RFC 3642.
Certificate URL Currently, base stations cannot

Authority URL translate domain names. Therefore, an
IP address instead of a domain name is
used in the URL.
By default, the CA uses TCP port 80
for HTTP services and TCP port 443
for HTTPS services. The TCP port
number is determined by the CA. The
URL domain name of the CA can be
set as follows: http://10.88.88.88:80/
pkix/.

SingleRAN

Name Sour
ce
Signature SIGNALG N/A

Algorithm

SingleRAN

Name Sour
ce
Certificate MODE l If this parameter is set to Netw

Fetch Mode DEFAULT_MODE, the UPDSIP, ork
INITREQURL, and INITREQSIP plan
parameters do not need to be set.
The base station uses the O&M IP
address and URL as the source and
destination IP addresses,
respectively, for routine certificate
management. Routine certificate
management involves certificate
application and certificate update,
both of which can be done
performed automatically or
manually. When applying for a
certificate for the first time during
base station deployment, the base
station uses the interface IP address
or O&M IP address as the source IP
address, and the URL as the
destination IP address.
l If this parameter is set to
CFG_UPD_SIP, INITREQURL
and INITREQSIP do not need to
be set. The base station uses
UPDSIP and URL as the source
and destination IP addresses,
management. When applying for a
certificate for the first time during
base station deployment, the base
station uses the interface IP address
or UPDS IP address as the source
IP address, and the URL as the
destination IP address. The
interface IP address is used during
base station deployment by PnP,
and the UPDS IP address is used
during base station deployment by
USB.
l If this parameter is set to
CFG_INIT_UPD_ADDR:
– During daily certificate
management, the base station
uses UPDSIP and URL as the
source and destination IP
addresses, respectively.

SingleRAN

Name Sour
ce
– When obtaining a certificate for

the first time during base station
deployment, the base station
uses the interface IP address
(automatic base station
deployment) or INITREQSIP
(base station deployment using a
USB flash drive) as the source
IP address, and uses
INITREQURL as the
destination IP address.
Certificate UPDSIP N/A Netw

Update Source ork
IP plan
CA URL INITREQURL N/A Netw

During Site ork
Deployment plan
Source IP for INITREQSIP N/A Netw

Applying for a ork
Certificate plan
During Site
Deployment

SingleRAN
Figure 8-2 CANAME configuration
NOTE
If O&M data flows are transmitted by the IPsec tunnel, the O&M IP address cannot be used for data that
is not protected by IPsec. If O&M data flows are not transmitted by the IPsec tunnel, the O&M IP
address cannot be used for data that is protected by IPsec.
Table 8-6 lists the data to be prepared for a device certificate (the CERTMK MO in MML
and CME configurations).

SingleRAN
Table 8-6 Data to be prepared for a device certificate

Name Sour
ce
Certificate File APPCERT l If an operator-issued device Netw

Name certificate is used for identity ork
authentication between the base plan
station and SeGW, two CERTMK
MOs must be configured to specify
an operator-issued device certificate
and a Huawei-issued device
certificate. For Huawei-issued
device certificates, this parameter is
set to appcert.pem. For operator-
issued device certificates, this
parameter is set to
OPKIDevCert.cer during base
station deployment by PnP.
l If a Huawei-issued device
certificate is used for identity
authentication between the base
station and SeGW, only one
CERTMK MO needs to be
configured to specify a Huawei-
issued device certificate. This
parameter is set to appcert.pem
accordingly. Users cannot modify
or remove this MO.
Table 8-7 lists the data to be prepared for an active certificate (the APPCERT MO in MML
and CME configurations). Active certificates are device certificates that are currently used by
a base station.
Table 8-7 Data to be prepared for an active certificate

Name Sour
ce
Application Type APPTYPE l This parameter must be set to IKE Netw

for IKE authentication and SSL ork
for SSL authentication. (The base plan
station controllers do not support
IKE authentication.)
l This parameter must be set to SSL
for SSL authentication.

SingleRAN

Name Sour
ce
Certificate File APPCERT Base stations do not have special

Name requirements for the setting of this
parameter.
Table 8-8 lists the data to be prepared for a trust certificate (the TRUSTCERT MO in MML
and CME configurations).
Table 8-8 Data to be prepared for a trust certificate

Name Sourc
e
Certificate File CERTNAME The base station must be configured Netwo

Name with an operator's trust certificate and rk
a Huawei trust certificate. For the plan
Huawei trust certificate, this
parameter is set to caroot.pem on the
base station side and is set to
rootca.pem on the base station
controller side. For the operator's trust
certificate, this parameter is set to
CN.cer when automatic certificate
application is used. The value of CN
must be the same as that in the
Subject field of the trust certificate.
If the operator's CA system has a
multi-layer structure, the base station
must be configured with all trust
certificates in the certificate chain.
Table 8-9 lists the data to be prepared for a periodic certificate validity check task (the
CERTCHKTSK MO in MML and CME configurations).
Table 8-9 Data to be prepared for a periodic certificate validity check task

Name Sourc
e
Certificate ISENABLE The recommended value of this Netwo

Validity parameter is ENABLE. rk plan
Period
Checking

SingleRAN

Name Sourc
e
Checking PERIOD The default value is recommended for

Period(day) this parameter.
Alarm ALMRNG The default value is recommended for

Threshold(d this parameter.
ay)
Update UPDATEMETHOD The recommended value of this

Method parameter is CMP.
(Optional) Prepare CRL data if the base station needs to obtain CRL information from the
CA. Table 8-10 lists the data to be prepared for a CRL (the CRL MO in MML and CME
configurations).
Table 8-10 Data to be prepared for a CRL

Name Sourc
e
CRL File CERTNAME N/A Netwo

Name rk plan
(Optional) Prepare data related to CRL usage policies. Table 8-11 lists the data to be prepared
for these policies (the CRLPOLICY MO in MML and CME configurations).
Table 8-11 Data to be prepared for CRL usage policies

Name Sour
ce
CRL Using CRLPOLICY The default value of this parameter is Netw

Policy NOVERIFY. Operators can set this ork
parameter based on site requirements. plan
During base station deployment by PnP,
the base station does not support CRL-
based certificate validity checks.
(Optional) Prepare data related to a periodic CRL download task. Table 8-12 lists the data to
be prepared for the task (the CRLTSK MO in MML and CME configurations).

SingleRAN
Table 8-12 Data to be prepared for a periodic CRL download task

Name Sourc
e
IP Address IP This parameter is set to the IP address of Netwo

the CRL server. rk plan
User Name USR N/A
Password PWD N/A
File Name FILENAME N/A
Using ISCRLTIME If this parameter is set to ENABLE, the

CRL's Next base station downloads a CRL when the
Update next update time arrives.
CRL PERIOD This parameter must be set when

Updating ISCRLTIME is set to DISABLE.
Period(h)
Access CRLGETMETHOD The recommended value of this parameter

Method is LDAP. This parameter is set to FTP
only when the peer device does not
support LDAP.
Distinguish SEARCHDN This parameter must be set when

Name CRLGETMETHOD is set to LDAP.
Port No. PORT This parameter must be set when

CRLGETMETHOD is set to LDAP.
Task ID TSKID N/A User-

define
d
Source IP SIP If this parameter is not set, the base station Netwo
uses the O&M IP address as the source IP rk plan
address to update a CRL.
Connection CONNMODE This parameter indicates whether to use Netwo

Mode SSL connections. This parameter takes rk plan
effect only when CRLGETMETHOD is
set to LDAP.

SingleRAN

Name Sourc
e
Authenticat AUTHPEER This parameter specifies whether to Netwo

e Peer authenticate the peer certificate when SSL rk plan
connections are used. This parameter takes
effect only when the CRLGETMETHOD
parameter is set to LDAP.
If this parameter is set to
ENABLE(Enable), ensure that both the
base station/base station controller and the
CRL server have been configured with the
CA trust certificates and device
certificates.
(Optional) Prepare data to manually download an operator's root certificate or CRL from an
FTP server. Table 8-13 lists the data to be prepared for downloading a certificate file. The
corresponding MML command is DLD CERTFILE.
Table 8-13 Data to be prepared for downloading a certificate file

Name Source
FTP Server IP IP N/A Network

plan
User Name USR N/A Network

plan
Password PWD N/A Network

plan
Source SRCF N/A Network

File Name plan
Destination DSTF It is recommended that this parameter Network

File Name be set to the same value as SRCF. plan
Guage Option GA This parameter determines whether to Network

report the progress of file downloading. plan
Certificate CT N/A Network

Type plan
(Optional) Prepare data to manually trigger a CMPv2-based certificate application. Table

8-14 lists the data to be prepared for applying for a device certificate based on CMPv2. The
corresponding MML command is REQ DEVCERT.

SingleRAN
Table 8-14 Data to be prepared for applying for a device certificate based on CMPv2
Name Source
Certificate CANAME N/A Network

Authority plan
Name
Certificate File APPCERT N/A Network

Name plan
Renew Key REKEY The recommended value of this Network

parameter is Yes. plan
Table 8-15 lists the data to be prepared for updating a device certificate (the DEVCERT MO
in MML configurations) based on CMPv2. The corresponding MML command is UPD
DEVCERT.
Table 8-15 Data to be prepared for updating a device certificate based on CMPv2
Name Source
Certificate File APPCERT This parameter specifies a certificate to Network

Name be updated. plan
Renew Key REKEY The recommended value of this Network

parameter is Yes. plan
Key Size KEYSIZE N/A Network

plan
8.5.2 Initial Configuration

This section only describes how to deploy the PKI feature by using the CME or MML
commands. For details about how to deploy the PKI feature on the U2000 client, see the
U2000 Help.
8.5.2.1 Using the CME

You can use either of the following methods to deploy the PKI feature for newly deployed
base stations: CME Summary batch configuration and CME transport security wizard
configuration.
CME Summary Batch Configuration

This feature can be activated using the CME. This section uses the eNodeB as an example.
For detailed operations, see CME-based Feature Configuration or the CME online help
(press F1 in an active CME window).

SingleRAN
Configuration CME Online Help

Type
Single configuration CME Management > CME Guidelines > Getting Started with
the CME > Introduction to Data Configuration Operations
Batch eGBTS CME Management > CME Guidelines > GSM Application
configuration Management > Base Station Related Operations > Importing
and Exporting eGBTS Data for Batch Reconfiguration
Batch NodeB CME Management > CME Guidelines > UMTS Application
configuration Management > NodeB Related Operations > Importing and
Exporting NodeB Data for Batch Configuration
Batch eNodeB CME Management > CME Guidelines > LTE Application
configuration Management > eNodeB Related Operations > Importing and
Exporting eNodeB Data for Batch Configuration
CME Transport Security Wizard Configuration

You can use the transport security wizard to configure the parameters for the PKI and IPsec
features on the CME. The wizard will guide you to configure most of the key parameters for
PKI and IPsec networking. After the wizard configuration is completed, the CME
automatically imports the configured parameters to the Summary data file and prompts which
parameters should be manually configured in the Summary data file (for example, the
UPDSIP parameter in the CA MO).
Figure 8-3 shows the procedure for configuring data using the CME transport security
wizard.

SingleRAN
Figure 8-3 Procedure for configuring data using the CME transport security wizard
After configurations on the CME transport security wizard are complete, the IPsec and PKI
parameter setting tables are exported, displaying the IPsec and KPI parameters that have been
configured and the parameters that need to be manually configured in the summary data file.

SingleRAN
You can adjust the configured parameters in the summary data file based on the actual
conditions.
The CME transport security wizard has the following restrictions on configuring PKI:
l PKI redundancy cannot be configured.
l SSL transmission cannot be configured for obtaining the CRL.
l Base station supporting multi-operator PKI cannot be configured.
l PKI parameters for the eGBTS, NodeB, and eNodeB can be configured. PKI parameters
can be configured for the GBTS only when it is configured with GTMUb/GTMUc
+UMPT_L/LMPT.
l The following figure shows the PKI attribute selection in the CME transport security
wizard.
NOTE
For the IPsec attribute selection, see section 10.6.1 Using the CME in Batch Configuration for
Newly Deployed Base Stations in IPsec Feature Parameter Description.
l The following table lists the PKI parameters to be configured.
MO Parameter Sheet in Setting Notes
Group the
Summary
Data File
CERTDEPLOY DEPLOYTY Common This parameter is

PE Data automatically set to
SPECIFIC in certificate
sharing scenarios.
In other scenarios, manual
configuration is required.
CN Common Manual configuration

Data
SRN Common Manual configuration

Data
SN Common Manual configuration

Data
CA CANAME Common This parameter uses the

Data default configuration on the
wizard interface.
URL Common This parameter uses the

wizard interface.

SingleRAN

Group the
Summary
Data File
SIGNALG Common This parameter uses the

wizard interface.
MODE Common Manual configuration

Data
UPDSIP Base Manual configuration

Station
Transport
Data
INITREQUR Common This parameter uses the

L Data default configuration on the
wizard interface.
INITREQSIP Base Manual configuration

Station
Transport
Data
CERTREQ COMMNAM Common This parameter is

E Data automatically set to ESN.
USERADDIN Common This parameter is

FO Data automatically set
to .huawei.com.
KEYUSAGE Common This parameter is

Data automatically set to
DATA_ENCIPHERMENT-
1&DIGITAL_SIGNATUR
E-1&KEY_AGREEMENT-
1&KEY_ENCIPHERMEN
T-1.
SIGNALG Common This parameter is

SHA256.
KEYSIZE Common This parameter is

Data automatically set to 2048.
LOCALNAM Base Manual configuration

E Station
Transport
Data

SingleRAN

Group the
Summary
Data File
LOCALIP Base Manual configuration

Station
Transport
Data
CERTMK APPCERT Common This parameter is

Data automatically set to appcert.
pem and OPKIDevCert.
cer.
APPCERT APPTYPE Common This parameter is

OPKIDevCert.cer.
APPCERT Common
Data
TRUSTCERT CERTNAME Common The preconfigured root

Data certificate of the base station
is automatically set to
caroot.pem. The operator's
root certificate automatically
uses the default
configuration on the wizard
interface.
CERTCHKTSK ISENABLE Common This parameter is

ENABLE.
PERIOD Common This parameter is

ALMRNG Common This parameter is

UPDATEME Common This parameter is

THOD Data automatically set to CMP.
CRL CERTNAME Common This parameter uses the

wizard interface.
CRLPOLICY CRLPOLICY Common This parameter is

ALARM.
CRLTSK IP Common This parameter uses the

wizard interface.

SingleRAN

Group the
Summary
Data File
USR Common This parameter uses the

wizard interface.
PWD Common This parameter uses the

wizard interface.
FILENAME Common This parameter uses the

wizard interface.
ISCRLTIME Common This parameter is

Data automatically set to CMP.
PERIOD Common This parameter is

DISABLE.
CRLGETME Common This parameter uses the

THOD Data default configuration on the
wizard interface.
SEARCHDN Common This parameter uses the

wizard interface.
PORT Common This parameter uses the

wizard interface.
TSKID Common This parameter is

SIP Base Manual configuration

Station
Transport
Data
For the configuration path and interface for the transport security wizard, see Transport
Security Wizard in the "Introduction to the Wizards for Customizing a Data File" section of
CME Product Documentation.
8.5.2.2 Using MML Commands

Perform the following steps to activate an operator-issued device certificate on the base
station side:

SingleRAN
NOTE
If multi-level CAs are deployed in an operator's PKI system, a complete certificate chain must be added.
If the certificates of different levels of CAs in the certificate chain are stored separately, run the ADD
TRUSTCERT command for each certificate you want to add.
Step 1 Run the MML command SET CERTDEPLOY to set the deployment position of a certificate
on the base station. You need to reset the base station to make the configuration take effect.
Step 2 Run the MML command MOD CERTREQ to modify configurations of a certificate request
template.
Step 3 Run the MML command ADD CA to add an operator's CA.
Step 4 (Optional) Run the MML command DLD CERTFILE to download a trusted operator's root
certificate from the operator's certificate & CRL database. This step is required only when a
manual certificate application procedure is used.
Step 5 Run the MML command ADD TRUSTCERT to add an operator's trust certificate.
Step 6 (Optional) Run the MML command REQ DEVCERT to set information required for the base
station to apply for an operator-issued device certificate. This step is required only when a
manual certificate application procedure is used. After the setting takes effect, a certificate
application procedure is triggered.
Step 7 Run the MML command MOD APPCERT to modify configurations of an active certificate.
Step 8 Run the MML command SET CERTCHKTSK to set a periodic certificate validity check
task.
Step 9 (Optional) Run the MML command DLD CERTFILE to download a CRL from the
operator's certificate & CRL database.
Step 10 (Optional) Run the MML command ADD CRL to add a CRL. This step is required only
when a manual certificate application procedure is used.
Step 11 (Optional) Run the MML command SET CRLPOLICY to set a CRL usage policy.
Step 12 (Optional) Run the MML command ADD CRLTSK to add a periodic CRL download task.
----End
In addition to the preceding steps, perform the following step to manually trigger a certificate
update:
Step 1 Run the MML command UPD DEVCERT to set information about a certificate update. After
the setting takes effect, a CMPv2-based certificate update procedure is triggered.
----End
Perform the following step to configure certificate sharing:
Step 1 Run the MML command SET CERTDEPLOY to set a board whose certificate is shared.
----End
8.5.2.3 MML Command Examples

The following is an MML command example of how to activate an operator-issued device
certificate.

SingleRAN
//Setting the deployment position of a certificate

SET CERTDEPLOY: DEPLOYTYPE=DEFAULT;
NOTE
If you run the SET CERTDEPLOY command to set the deployment location of a certificate on a base
station online, the setting takes effect only after the base station is reset.
//Modifying configurations of a certificate request template
MOD CERTREQ: COMMNAME=ESN, USERADDINFO=".huawei.com", COUNTRY="cn", ORG="ITEF",
ORGUNIT="Hw", STATEPROVINCENAME="sc", LOCALITY="cd",
KEYUSAGE=DATA_ENCIPHERMENT-1&DIGITAL_SIGNATURE-1&KEY_AGREEMENT-1&KEY_ENCIPHERMENT-
1, SIGNALG=SHA256, KEYSIZE=KEYSIZE1024, LOCALNAME="abcdefghijklmn.huawei.com",
LOCALIP="10.20.20.188";
//Adding an operator's CA
//If the base station can access the CA either through an external network or
through the intranet and O&M data is protected by IPsec, you are advised to set
the source IP addresses for certificate application and update to an interface IP
address and an O&M IP address (for example, 10.31.31.188), respectively. The
following is an example:
ADD CA: CANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca1",
URL="http://10.88.88.88:80/pkix/", SIGNALG=SHA256, MODE= CFG_INIT_UPD_ADDR,
UPDSIP="10.31.31.188",INITREQURL="http://10.89.89.89:80/
pkix/",INITREQSIP="10.20.20.188";
through the intranet, and O&M data is not protected by IPsec, you are advised to
set the source IP addresses for certificate application and update to an
interface IP address and an intranet IP address(for example, 10.45.45.45),
respectively.
//If the base station can access the CA through only an external network, you are
advised to set the source IP addresses for both certificate application and
update to interface IP addresses. The following is an example:
//Downloading an operator's root certificate from an FTP server (assume that the
FTP server is deployed on the U2000, indicating that the IP address of the FTP
server is the same as that of the U2000)
DLD
CERTFILE:IP="10.60.60.60",USR="admin",PWD="*****",SRCF="OperationCA.cer",DSTF="Ope
rationCA.cer";
//Adding an operator's root certificate as the trust certificate
ADD TRUSTCERT: CERTNAME="OperationCA.cer";
//Setting information required for the base station to apply for an operator-
issued device certificate based on CMPv2 when the certificate application needs
to be manually triggered
//(Skip this step when the certificate application is automatically triggered.)
REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd, CN=eca1",
APPCERT="OPKIDevCert.cer";
//Modifying configurations of an active certificate
MOD APPCERT: APPTYPE=IKE, APPCERT="OPKIDevCert.cer";
NOTE
After the active IKE certificate is changed by running the MOD APPCERT command, if IKE
authentication uses the new certificate and the current IKE SA is normal, the base station automatically
initiates IKE renegotiation.
//Setting a periodic certificate validity check task
SET CERTCHKTSK: ISENABLE=ENABLE, PERIOD=7, ALMRNG=30, UPDATEMETHOD=CMP;
//(Optional) Downloading the CRL file from the FTP server. If the FTP server is
deployed on the U2000, the IP address of the FTP server is the same as that of
the U2000.
DLD
CERTFILE:IP="10.60.60.60",USR="admin",PWD="*****",SRCF="eNodeB.crl",DSTF="eNodeB.c
rl";
//(Optional) Loading the CRL file

SingleRAN
ADD CRL: CERTNAME="eNodeB.crl";

//(Optional) Setting a CRL usage policy
SET CRLPOLICY:CRLPOLICY= NOVERIFY;
//(Optional) Adding a task of periodically downloading the CRL
ADD CRLTSK: IP="10.86.86.86", USR="admin", PWD="*****", FILENAME="eNodeB.crl",
ISCRLTIME=DISABLE, PERIOD=24, TSKID=0, CRLGETMETHOD=FTP;
In addition, the following configuration is required to manually trigger a certificate update:

UPD DEVCERT: APPCERT="OPKIDevCert.cer",REKEY=YES;
NOTE
When you run the UPD DEVCERT command to update a certificate, if the base station is performing
IKE or SSL negotiation, the certificate update fails. You need to execute this command after the
negotiation is complete.
The following is an MML command example of how to configure certificate sharing.

//Setting the deployment location of a certificate
SET CERTDEPLOY: DEPLOYTYPE=SPECIFIC, CN=0, SRN=0, SN=6;
8.5.3 Activation Observation
Observing the PKI Feature

Step 1 Run the MML command DSP APPCERT to check the status of device certificates.
If the values of Certificate File Name, Issuer, and Common Name are correct and the value
of Status is Normal in the query result, the device certificate has been loaded to the base
station.
Step 2 Run the MML command DSP TRUSTCERT to check the status of trust certificates.
If the value of Status is Normal in the query result, the trust certificate has been loaded to the
base station.
Step 3 (Optional) Run the MML command DSP CRL to check the CRL status.
If the value of Status is Normal in the query result, the CRL has been loaded to the base
station.
----End
Observing Certificate Sharing

Step 1 Run the MML command DSP CERTSYNCINFO to check the status of certificate sharing.
If the value of Status is Normal in the query result, certificate sharing is successful.
----End
Observing Offline Certificate Monitoring

Step 1 On the U2000 client in tradition style, choose Security > Certificate Authentication
Management > Offline Certificate Management. Alternatively, on the Application Center
tab page of the U2000 client in application style, double-click Security Management. Then,
choose NE Security > Certificate Authentication Management > Offline Certificate
Management. All device certificates in abnormal states are displayed on the U2000.

SingleRAN
Step 2 (Optional) To import information of device certificates in abnormal states, click Export. If the
On disconnected NE or On deleted NE check box is selected, you also need to set the
duration in which the device certificates remain in the state.
----End
8.5.4 Deactivation
Step 1 Run the MML command RMV CA to remove the CA.
Step 2 (Optional) Run the MML command RMV CRLTSK to remove the task of automatically
updating CRL whose CRLGETMETHOD is set to LDAP.
----End
8.6 Deployment of PKI on the eGBTS using a GTMUb

deploy the PKI feature on the eGBTS using a GTMUb.
Figure 8-4 Example of the secure networking for the eGBTS using a GTMUb
NOTE
This networking scenario supports only SSL authentication.

NOTE

SingleRAN
Table 8-16 lists the data to be prepared for applying for a certificate from the CA (the SSL
MO in MML configurations).
Table 8-16 Data to be prepared for applying for a certificate from the CA
Name Sour
ce
Common Name This parameter is The value of the Common Name field in Netw
manually set on the a certificate request file consists of ork
CA and it does not Common Name+Common Name plan
have a parameter ID. Additional Info. The recommended
value of the Common Name field is
XXX.huawei.com (XXX indicates the
transport network).
Common Name This parameter is The recommended value of this

Additional Info. manually set on the parameter is .huawei.com.
CA and it does not
have a parameter ID.
Country This parameter is N/A

manually set on the
CA and it does not
Organization This parameter is N/A

manually set on the
CA and it does not

Unit manually set on the
CA and it does not
State or This parameter is N/A

Province manually set on the
CA and it does not
Locality This parameter is N/A

manually set on the
CA and it does not

SingleRAN

Name Sour
ce
Key Usage This parameter is The recommended values are

manually set on the DIGITAL_SIGNATURE and
CA and it does not KEY_ENCIPHERMENT. If this
have a parameter ID. parameter is set to
used to verify the peer's digital signature
during a CMPv2-based certificate
application or update, IKE negotiation,
and SSL authentication. If this
parameter is set to
used to encrypt transmission data during
IKE negotiation, IPsec negotiation, or
SSL-based key exchange.
Signature This parameter is Secure hash algorithm 256 (SHA256) is

Algorithm manually set on the recommended for signing a certificate
CA and it does not request file.
have a parameter ID. MD5 is not recommended for use
Key Size This parameter is N/A

manually set on the
CA and it does not
Local Name This parameter is l If this parameter is not set, the

manually set on the default value of the Common Name
CA and it does not field in a certificate is used.
have a parameter ID. l If this parameter is set, the value of
the Local Name field in a certificate
must be the same as the value of this
parameter.
Root Certificate ROOTCERT N/A

File Name
Public PUBCERT N/A

Certificate File
Name
Private Key PRIVKEY N/A

File Name
Private Key PKPENABLESTA It is recommended that the private key

Password password protection be enabled for
Enabled State security reasons.
Private Key PWD N/A

Password

SingleRAN

Name Sour
ce
Certificate CRLENABLESTA N/A

Revocation List
File Enabled
State
Certificate CRL N/A

Revocation List
File Name
Certificate CCAENABLESTA If the local certificate chain is different

Chain File from the peer certificate chain, set this
Enabled State parameter to ENABLE, and set the
CERTCHAIN parameter to the
certificate chain file name.
Certificate CERTCHAIN N/A

Chain File
Name

Parameter Parameter ID Setting Notes Dat
Name a
Sou
rce
Certification DEPLOYTYPE Set this parameter to NULL for the Net

Deploy eGBTS using a GTMUb. work
Position Type plan
Cabinet No. CN N/A
Subrack No. SRN
Slot No. SN
Table 8-18 lists the data to be prepared for downloading an operator's root certificate, public
key, private key, or CRL file from an FTP server. The corresponding MML command is DLD
GENFILE.

SingleRAN

Parameter Name Parame Setting Notes Data
ter ID Source
Source File Name SRCF N/A Network

plan
Type TYPE Set this parameter to the SSL type. Network

plan
Destination File Name DSTF It is recommended that this parameter Network

be set to the same value as SRCF. plan
Mode MODE This parameter indicates the IP mode Network

of the FTP server. plan

plan

plan

plan

The recommended value of this
parameter is Y.

station side:
NOTE
If multi-level CAs are deployed in the operator's PKI system and the local certificate chain is different
from the peer certificate chain, you also need to run the SET CERTFILE command to configure the
peer certificate chain.
Step 1 Upload the operator's root certificate and CRL file to the FTP server.
Step 2 Based on the data plan listed in Table 8-16, apply for a device certificate from the CA, and
upload the public key certificate (device certificate) and private key file generated by the CA
to the FTP server.
Step 3 Run the SET CERTDEPLOY command to set Certification Deploy Position Type to
NULL(NULL).
Step 4 Run the DLD GENFILE command to download the operator's root certificate, public key
certificate, private key file, and CRL file from the FTP server.

SingleRAN
Step 5 Run the SET CERTFILE command to set the operator's root certificate, public key
certificate, private key file, and CRL file.
----End

certificate.
//There are no MML commands for steps 1 and 2.
//Downloading the operator's root certificate, public key certificate, private
key file, and CRL file from the FTP server (assume that the FTP server is on the
U2000 and the FTP server and U2000 have the same IP address)
//Setting the certification deployment position so that the certificate is not
deployed on the base station
SET CERTDEPLOY:DEPLOYTYPE=NULL;
//Downloading the operator's root certificate from the FTP server
DLD
GENFILE:SRCF="OperationCA.cer",TYPE=SSL,DSTF="OperationCA.cer",MODE=IPV4,IP="10.60
.60.60",USR="admin",PWD="*****";
//Downloading the public key certificate from the FTP server
DLD
GENFILE:SRCF="OperationDev.cer",TYPE=SSL,DSTF="OperationDev.cer",MODE=IPV4,IP="10.
60.60.60",USR="admin",PWD="*****";
//Downloading the private key file from the FTP server
DLD
GENFILE:SRCF="OperationDevPri.cer",TYPE=SSL,DSTF="OperationDevPri.cer",MODE=IPV4,I
P="10.60.60.60",USR="admin",PWD="*****";
//Downloading the CRL file from the FTP server
DLD
GENFILE:SRCF="eGBTS.crl",TYPE=SSL,DSTF="eGBTS.crl",MODE=IPV4,IP="10.60.60.60",USR=
"admin",PWD="*****";
//Setting the operator's root certificate, public key certificate, private key
file, and CRL file
SET CERTFILE:ROOTCERT="OperationCA.cer ",PUBCERT="OperationDev.cer ",PRIVKEY="
OperationDevPri.cer",PKPENABLESTA=DISABLE,CRLENABLESTA=ENABLE,CRL="eNodeB.crl
",CCAENABLESTA=DISABLE;

Step 1 Run the MML command SET SSLAUTHMODE to set Authentication Mode to
PEER(Verify Peer Certificate).
Management > SSL Connection Management to open the SSL Connection Management
window. Alternatively, on the Application Center tab page of the U2000 client in application
style, double-click Security Management. Then, choose NE Security > Certificate
Authentication Management > SSL Connection Management to open the SSL
Connection Management window.
Then, observe Connection Status of the base station. If the value of Connection Status is
Connected, an SSL connection has been successfully established.
If the SSL connection setup fails, go to Step 3.
Step 3 Run the MML command SET CONNTYPE to set Connection Type to SSL(Only SSL
Connection).

SingleRAN
Step 4 In the SSL Connection Management window, select the base station, and then observe the
SSL connection status.
Then, observe Connection Status of the base station. If the value of Connection Status is
Connected, an SSL connection has been successfully established.
----End

The procedure for observing offline certificate monitoring of an eGBTS configured with a
GTMUb is the same as that of an eGBTS configured with a UMDU. For details, see
Observing Offline Certificate Monitoring in 8.5 Deployment of PKI on the eGBTS/
NodeB/eNodeB/Multimode Base Station.
8.6.4 Deactivation
None
8.7 Deployment of PKI on a NodeB Using a WMPT

deploy the PKI feature on the NodeB that uses a WMPT as the main control board and is not
configured with a UTRPc.
Figure 8-5 Example of the secure networking for the NodeB that uses a WMPT as the main
control board and is not configured with a UTRPc
NOTE
This networking scenario supports only SSL authentication.

SingleRAN

NOTE
Table 8-19 lists the data to be prepared for applying for a certificate from the CA (the SSL
MO in MML configurations).
Table 8-19 Data to be prepared for applying for a certificate from the CA
Name Sour
ce
Common Name This parameter is The value of the Common Name field in Netw
manually set on the a certificate request file consists of ork
CA and it does not Common Name+Common Name plan
have a parameter ID. Additional Info. The recommended
value of the Common Name field is
XXX.huawei.com (XXX indicates the
transport network).
Common Name This parameter is The recommended value of this

Additional Info. manually set on the parameter is .huawei.com.
CA and it does not
Country This parameter is N/A

manually set on the
CA and it does not

manually set on the
CA and it does not

Unit manually set on the
CA and it does not
State or This parameter is N/A

Province manually set on the
CA and it does not
Locality This parameter is N/A

manually set on the
CA and it does not

SingleRAN

Name Sour
ce
Key Usage This parameter is The recommended values are

manually set on the DIGITAL_SIGNATURE and
CA and it does not KEY_ENCIPHERMENT. If this
have a parameter ID. parameter is set to
used to verify the peer's digital signature
during a CMPv2-based certificate
application or update, IKE negotiation,
and SSL authentication. If this
parameter is set to
used to encrypt transmission data during
IKE negotiation, IPsec negotiation, or
SSL-based key exchange.
Signature This parameter is Secure hash algorithm 256 (SHA256) is

Algorithm manually set on the recommended for signing a certificate
CA and it does not request file.
have a parameter ID. MD5 is not recommended for use
Key Size This parameter is N/A

manually set on the
CA and it does not
Local Name This parameter is l If this parameter is not set, the

manually set on the default value of the Common Name
CA and it does not field in a certificate is used.
have a parameter ID. l If this parameter is set, the value of
the Local Name field in a certificate
must be the same as the value of this
parameter.
Root Certificate ROOTCERT N/A

File Name
Public PUBCERT N/A

Certificate File
Name
Private Key PRIVKEY N/A

File Name
Private Key PKPENABLESTA It is recommended that the private key

Password password protection be enabled for
Enabled State security reasons.
Private Key PWD N/A

Password

SingleRAN

Name Sour
ce
Certificate CRLENABLESTA N/A

Revocation List
File Enabled
State
Certificate CRL N/A

Revocation List
File Name
Certificate CCAENABLESTA If the local certificate chain is different

Chain File from the peer certificate chain, set this
Enabled State parameter to ENABLE, and set the
CERTCHAIN parameter to the
certificate chain file name.
Certificate CERTCHAIN N/A

Chain File
Name

Name a
Sou
rce
Certification DEPLOYTYPE Set this parameter to NULL for the Net

Deploy NodeB that uses a UMPT as the main work
Position Type control board and is not configured with plan
a UTPRc.
Cabinet No. CN N/A
Subrack No. SRN
Slot No. SN
Table 8-21 lists the data to be prepared for downloading an operator's root certificate, public
key, private key, or CRL file from an FTP server. The corresponding MML command is DLD
GENFILE.

SingleRAN

ter ID Source

plan
Type TYPE Set this parameter to the SSL type.
Destination File Name DSTF It is recommended that this parameter

be set to the same value as SRCF.
Mode MODE This parameter indicates the IP mode

of the FTP server.
FTP Server IP IP N/A
User Name USR N/A
Password PWD N/A
Guage Option GA This parameter determines whether to

report the progress of file downloading.
The recommended value of this
parameter is Y.

station side:
NOTE
If multi-level CAs are deployed in the operator's PKI system and the local certificate chain is different
from the peer certificate chain, you also need to run the SET CERTFILE command to configure the
peer certificate chain.
Step 1 Upload the operator's root certificate and CRL file to the FTP server.
Step 2 Based on the data plan listed in Table 8-19, apply for a device certificate from the CA, and
upload the public key certificate (device certificate) and private key file generated by the CA
to the FTP server.
Step 3 Run the SET CERTDEPLOY command to set Certification Deploy Position Type to
NULL(NULL).
Step 4 Run the DLD GENFILE command to download the operator's root certificate, public key
certificate, private key file, and CRL file from the FTP server.
Step 5 Run the SET CERTFILE command to set the operator's root certificate, public key
certificate, private key file, and CRL file.
----End

SingleRAN

certificate.
//There are no MML commands for steps 1 and 2.
//Downloading the operator's root certificate, public key certificate, private
key file, and CRL file from the FTP server (assume that the FTP server is on the
U2000 and the FTP server and U2000 have the same IP address)
//Setting the certification deployment position so that the certificate is not
deployed on the base station
SET CERTDEPLOY:DEPLOYTYPE=NULL;
//Downloading the operator's root certificate from the FTP server
DLD
GENFILE:SRCF="OperationCA.cer",TYPE=SSL,DSTF="OperationCA.cer",MODE=IPV4,IP="10.60
.60.60",USR="admin",PWD="*****";
//Downloading the public key certificate from the FTP server
DLD
GENFILE:SRCF="OperationDev.cer",TYPE=SSL,DSTF="OperationDev.cer",MODE=IPV4,IP="10.
60.60.60",USR="admin",PWD="*****";
//Downloading the private key file from the FTP server
DLD
GENFILE:SRCF="OperationDevPri.cer",TYPE=SSL,DSTF="OperationDevPri.cer",MODE=IPV4,I
P="10.60.60.60",USR="admin",PWD="*****";
//Downloading the CRL file from the FTP server
DLD
GENFILE:SRCF="NodeB.crl",TYPE=SSL,DSTF="NodeB.crl",MODE=IPV4,IP="10.60.60.60",USR=
"admin",PWD="*****";
//Setting the operator's root certificate, public key certificate, private key
file, and CRL file
SET CERTFILE:ROOTCERT="OperationCA.cer ",PUBCERT="OperationDev.cer ",PRIVKEY="
OperationDevPri.cer",PKPENABLESTA=DISABLE,CRLENABLESTA=ENABLE,CRL="NodeB.crl
",CCAENABLESTA=DISABLE;

Step 1 Run the SET SSLAUTHMODE command to set Authentication Mode to PEER(Verify
Peer Certificate).
Management > SSL Connection Management to open the SSL Connection Management
window. Alternatively, on the Application Center tab page of the U2000 client in application
style, double-click Security Management. Then, choose NE Security > Certificate
Authentication Management > SSL Connection Management to open the SSL
Connection Management window.
Then, observe Connection Status of the base station. If the value of this field is Connected,
an SSL connection has been successfully established.
If the SSL connection setup fails, go to Step 3.
Step 3 Run the SET CONNTYPE command to set Connection Type to SSL(Only SSL
Connection).
Step 4 In the SSL Connection Management window, select the base station, and then observe the
SSL connection status.
Then, observe Connection Status of the base station. If the value of this field is Connected,
an SSL connection has been successfully established.
----End

SingleRAN

The procedure for observing offline certificate monitoring of a NodeB configured with a
WMPT is the same as that of a NodeB configured with a UMPT, UMDU, or UTRPc. For
details, see Observing Offline Certificate Monitoring in 8.5 Deployment of PKI on the
eGBTS/NodeB/eNodeB/Multimode Base Station.
8.7.4 Deactivation
None
8.8 Deployment of PKI on the GBTS

deploy the PKI feature on the GBTS. A GBTS configured with GTMUc+UTRPc does not
support PKI.
NOTE
This section only describes how to deploy the PKI feature by using MML commands or the CME. For
details about how to deploy the PKI feature on the U2000 client, see the U2000 Help.
Figure 8-6 Example of the secure networking for the GBTS (GTMUb+UTRPc)

NOTE
In the following tables, the hyphen (-) indicates that there is no special requirement for the parameter
setting. You can set the parameter based on site requirements.
Table 8-22 lists the data to be prepared for the deployment location of a certificate on the
GBTS (the BTSCERTDEPLOY MO in MML configurations and the BTSCERTDEPLOY
or BTS Certification Deploy Position MO in CME configurations).

SingleRAN
Table 8-22 Data to be prepared for the deployment location of a certificate on the GBTS
Name Source
Index Type IDTYPE It is recommended that the ID Network

be used to identify a GBTS. plan
BTS Index BTSID (BSC6900, BSC6910) N/A
BTS Name BTSNAME N/A
Certificatio DEPLOYTYPE (BSC6900, If a digital certificate is

n deploy BSC6910) deployed on a main control
position board, this parameter must be
type set to DEFAULT. If a digital
certificate is deployed on
another board in a specified
slot, this parameter must be set
to SPECIFIC. If no digital
certificate is deployed on the
base station, this parameter
must be set to NULL.
Cabinet No. CN (BSC6900, BSC6910) N/A
Subrack SRN (BSC6900, BSC6910)

No.
Slot No. SN (BSC6900, BSC6910)
GBTSs must be configured with information about a CA so that they can apply for certificates
from the CA. Table 8-23 lists the data to be prepared for the CA (the BTSCA MO in MML
configurations and the BTSCA or BTS Certificate Authority MO in CME configurations).

Name Source
Index Type IDTYPE (BSC6900, It is recommended that the ID Network

BSC6910) be used to identify a GBTS. plan

SingleRAN

Name Source
Certificate CANAME (BSC6900, This parameter is set based on

Authority BSC6910) the name of the operator's CA.
Name For example, if the values of the
C, S, L, O, OU, CN, and E
fields for a certificate issuing
organization are AU, Some-
State, cd, Internet Widgits Pty
Ltd, Wireless, eca1, and
rosa@huawei.com, respectively,
CANAME for the organization
must be set to C = AU, S =
Some-State, L = cd, O =
Internet Widgits Pty Ltd, OU
= Wireless, CN = eca1, E =
rosa@huawei.com. To prevent
errors during the execution of
the REQ DEVCERT
command, all of the following
conditions must be met: The
character type for the C, S, L,
O, OU, and CN fields is
PRINTABLE. The character
type for the E field is IA5.
Characters that do not meet the
previous two conditions are
invalid. The S field can be
replaced with the ST field. For a
base station, the S and ST fields
are regarded as the same field.
For details about the character
set of the PRINTABLE type,
see RFC 3642.
Certificate URL (BSC6900, BSC6910) Currently, GBTSs cannot

Authority translate domain names.
URL Therefore, an IP address instead
of a domain name is used in the
URL.
By default, the CA uses TCP
port 80 for HTTP services and
TCP port 443 for HTTPS
services. The URL domain
name of the CA can be set as
follows: http://10.88.88.88:80/
pkix/.

SingleRAN

Name Source
Signature SIGNALG (BSC6900, SHA256 is recommended.

Algorithm BSC6910) Message digest algorithm 5
(MD5) cannot be used because
it provides low security.
Therefore, this parameter is
invalid when it is set to MD5.
Table 8-24 lists the data to be prepared for a certificate request template (the BTSCERTREQ
MO in MML configurations and the BTSCERTREQ or BTS Certreq File Configuration
MO in CME configurations).

Name Source

Common COMMNAME (BSC6900, The default value of the

Name BSC6910) Common Name field in a
certificate request file is
XXX.huawei.com (XXX
indicates the ESN of the board
connecting to the transport
network). Therefore, the
recommended value of this
parameter is ESN. Currently,
this parameter cannot be set to
MAC or IP.
Common USERADDINFO (BSC6900, N/A

Name BSC6910)
Additional
Info.
Country COUNTRY (BSC6900, N/A

BSC6910)
Organizatio ORG (BSC6900, BSC6910) N/A

n
Organizatio ORGUNIT (BSC6900, N/A

n Unit BSC6910)

SingleRAN

Name Source
State or STATEPROVINCENAME N/A

Province (BSC6900, BSC6910)
Locality LOCALITY (BSC6900, N/A

BSC6910)
Key Usage KEYUSAGE (BSC6900, N/A

BSC6910)
Signature SIGNALG (BSC6900, l SHA256 is recommended.

Algorithm BSC6910) l MD5 is not recommended
for use because it provides
low security.
Key Size KEYSIZE (BSC6900, N/A

BSC6910)
Local LOCALNAME (BSC6900, If this parameter is not set, the

Name BSC6910) default value of the Common
Name field in a certificate is
XXX.huawei.com (XXX
indicates the ESN of the board
connecting to the transport
network). If this parameter is
set, the value of the Common
Name field in a certificate must
be the same as the value of this
parameter.
Local IP LOCALIP (BSC6900, If LOCALIDTYPE

BSC6910) (BSC6900, BSC6910) is set to
IP(IP Identify), the value of
this parameter must be the
same as the value of
LOCALIP in the
BTSIKEPEER MO.
Table 8-25 lists the data to be prepared for a device certificate (the BTSCERTMK MO in
MML configurations and the BTSCERTMK or BTS Device Certificate MO in CME
configurations).

Paramete Parameter ID Setting Notes Data
r Name Source
Index IDTYPE (BSC6900, It is recommended that the ID Network

Type BSC6910) be used to identify a GBTS. plan

SingleRAN

r Name Source
Certificate APPCERT (BSC6900, l If an operator-issued device

File Name BSC6910) certificate is used for
identity authentication
between the base station and
SeGW, two BTSCERTMK
MOs must be configured to
specify an operator-issued
device certificate and a
Huawei-issued device
certificate. This parameter is
set to OPKIDevCert.cer for
the operator-issued device
certificate and appcert.pem
for the Huawei-issued
device certificate.
certificate is used for
between the base station and
SeGW, only one
BTSCERTMK MO can be
configured to specify a
Huawei-issued device
certificate. This parameter is
set to appcert.pem
accordingly. This parameter
is set to appcert.pem
accordingly.
Table 8-26 lists the data to be prepared for an active certificate (the BTSAPPCERT MO in
MML configurations and the BTSAPPCERT or BTS Application's Certificate MO in CME
configurations). Active certificates are device certificates that are currently used by a GBTS.

Name Source
Index Type IDTYPE It is recommended that the ID Networ

be used to identify a GBTS. k plan

SingleRAN

Name Source
Applicatio APPTYPE (BSC6900, This parameter must be set to

n Type BSC6910) IKE for IKE authentication
and SSL for SSL
authentication.
This parameter must be set to
SSL for SSL authentication.
Certificate APPCERT (BSC6900, l If an operator-issued

File Name BSC6910) device certificate is used
for identity authentication
between the base station
and SeGW, this parameter
must be set to
OPKIDevCert.cer.
certificate is used for
between the base station
and SeGW, this parameter
must be set to
appcert.pem.
Table 8-27 lists the data to be prepared for a trust certificate (the BTSTRUSTCERT MO in
MML configurations and the BTSTRUSTCERT or BTS Trust Certificate MO in CME
configurations).

r Name Source
Index Type IDTYPE (BSC6900, BSC6910) It is recommended that the ID Networ

be used to identify a GBTS. k plan

SingleRAN

r Name Source
Certificate CERTNAME (BSC6900, The GBTS must be

File Name BSC6910) configured with an operator's
trust certificate and a Huawei
trust certificate. For a Huawei
trust certificate, this
parameter is set to
caroot.pem. For an operator's
trust certificate, this
parameter is set to the name
of the operator's root
certificate.
If the operator's CA system
has a multi-layer structure, the
GBTS must be configured
with all trust certificates in the
certificate chain.
BTSCERTCHKTSK MO in MML configurations and the BTSCERTCHKTSK or BTS
Certificate Checking Task MO in CME configurations).
Name Source

Certificate ISENABLE (BSC6900, The recommended value of

Validity BSC6910) this parameter is ENABLE.
Period
Checking
Checking PERIOD (BSC6900, BSC6910) The default value is

Period recommended for this
parameter.
Alarm ALMRNG (BSC6900, The default value is

Threshold BSC6910) recommended for this
parameter.
Update UPDATEMETHOD (BSC6900, The recommended value of

Method BSC6910) this parameter is CMP.

SingleRAN
(Optional) Prepare CRL data if GBTSs need to obtain CRL information from the CA. Table
8-29 lists the data to be prepared for a CRL (the BTSCRL MO in MML configurations and
the BTSCRL or BTS CRL MO in CME configurations).

Name Source
Index Type IDTYPE (BSC6900, BSC6910) It is recommended that the Network

ID be used to identify a plan
GBTS.
CRL File CERTNAME (BSC6900, N/A

Name BSC6910)
for these policies (the BTSCRLPOLICY MO in MML configurations and the
BTSCRLPOLICY or BTS CRL Using Policy MO in CME configurations).

Name Source
Index Type IDTYPE It is recommended that the Network

GBTS.
CRL Using CRLPOLICY (BSC6900, N/A

Policy BSC6910)
be prepared for the task (the BTSCRLTSK MO in MML configurations and the
BTSCRLTSK or BTS CRL Updating Task MO in CME configurations).

SingleRAN

Name Source
Index Type IDTYPE It is recommended that the Network

GBTS.
BTS Index BTSID (BSC6900, N/A

BSC6910)
IP Address IP (BSC6900, BSC6910) This parameter is set to the

IP address of the CRL
server.
User Name USR (BSC6900, N/A

BSC6910)
Password PWD (BSC6900, N/A

BSC6910)
File Name FILENAME (BSC6900, N/A

BSC6910)
Using CRL's Next ISCRLTIME (BSC6900, If this parameter is set to

Update BSC6910) ENABLE, the GBTS
downloads a CRL when the
next update time arrives.
CRL Updating PERIOD (BSC6900, This parameter must be

Period(h) BSC6910) specified when
ISCRLTIME (BSC6900,
BSC6910) is set to
DISABLE.
Access Method CRLGETMETHOD N/A

(BSC6900, BSC6910)
Distinguish Name SEARCHDN (BSC6900, This parameter must be set

BSC6910) when CRLGETMETHOD
(BSC6900, BSC6910) is set
to LDAP.
Port NO. PORT (BSC6900, This parameter must be set

BSC6910) when CRLGETMETHOD
to LDAP.
Task ID TSKID (BSC6900, N/A User-

BSC6910) defined

SingleRAN

Name Source
Connection Mode CONNMODE This parameter indicates Network

(BSC6900, BSC6910) whether to use SSL plan
connections. This parameter
takes effect only when
CRLGETMETHOD
to LDAP.
Authenticate Peer AUTHPEER (BSC6900, This parameter indicates Network

BSC6910) whether to authenticate the plan
peer certificate when the
SSL connections are used.
This parameter takes effect
only when
CRLGETMETHOD
to LDAP.
authenticate the peer
certificate, the NEs and CRL
server must have been
correctly configured with the
CA trust certificates and
device certificates.
FTP server. Table 8-32 lists the data to be prepared for downloading a certificate file.

Parameter Name Parameter Setting Notes Data
ID Source

plan

plan

plan

plan
Destination File Name DSTF N/A Network

plan

SingleRAN
Parameter Name Parameter Setting Notes Data

ID Source
Guage Option GA This parameter determines whether Network

to report the progress of file plan
downloading. The recommended
value of this parameter is
Yes(Guage).
Certificate Type CT N/A Network

plan

8-33 lists the data to be prepared for applying for a device certificate (the BTSDEVCERT
MO in MML configurations) based on CMPv2.
Name Source
Certificate CANAME This parameter must be set Network

Authority Name to the same value as plan
CANAME (BSC6900,
BSC6910).
Certificate File APPCERT N/A Network

Name plan
Renew Key REKEY The recommended value of Network

this parameter is Yes. plan
(Optional) Prepare data to manually trigger a CMPv2-based certificate update. Table 8-34
lists the data to be prepared for updating a device certificate (the BTSDEVCERT MO in
MML configurations) based on CMPv2.
Name Source
Certificate File APPCERT This parameter specifies a Network

Name certificate to be updated. plan
Renew Key REKEY The recommended value of Network

this parameter is Yes. plan
Key Size KEYSIZE N/A Network

plan

SingleRAN


Type

Perform the following steps to activate an operator-issued device certificate:
Step 1 Run the MML command SET BTSCERTDEPLOY to set the deployment position of a
certificate on the GBTS.
Step 2 Run the MML command MOD BTSCERTREQ to modify configurations of a certificate
request template.
Step 3 Run the MML command ADD BTSCA to add an operator's CA.
Step 4 Run the MML command DLD BTSCERTFILE to download a trusted operator's root
certificate from the operator's certificate & CRL database.
Step 5 Run the MML command ADD BTSTRUSTCERT to add an operator's trust certificate.
Step 6 Run the MML command REQ BTSDEVCERT to set information required for the GBTS to
apply for an operator-issued device certificate. After the setting takes effect, a certificate
application procedure is triggered. If a certificate application procedure is automatically
triggered, skip this step.
Step 7 Run the MML command MOD BTSAPPCERT to modify configurations of an active
certificate.
Step 8 Run the MML command SET BTSCERTCHKTSK to set a periodic certificate validity
check task.

SingleRAN
Step 9 (Optional) Run the MML command DLD BTSCERTFILE to download a CRL from the
Step 10 (Optional) Run the MML command ADD BTSCRL to add a CRL.
Step 11 (Optional) Run the MML command SET BTSCRLPOLICY to set a CRL usage policy.
Step 12 (Optional) Run the MML command ADD BTSCRLTSK to add a periodic CRL download
task.
----End
update:
Step 1 Run the MML command UPD BTSDEVCERT to set information about a certificate update.
After the setting takes effect, a CMPv2-based certificate update procedure is triggered.
----End

//Setting the deployment location of a certificate
SET BTSCERTDEPLOY: IDTYPE=BYID, BTSID=0, DEPLOYTYPE=SPECIFIC, CN=0, SRN=0, SN=4;
NOTE
l If you run the MML command SET BTSCERTDEPLOY to set the deployment location of a
certificate on a base station online, the setting takes effect only after the base station is reset.
MOD BTSCERTREQ: IDTYPE=BYID, BTSID=0, COMMNAME=ESN, USERADDINFO=".huawei.com",
COUNTRY="cn", ORG="ITEF", ORGUNIT="hw", STATEPROVINCENAME="sc", LOCALITY="cd",
LOCALIP="10.20.20.188";
//Adding an operator's CA
ADD BTSCA: IDTYPE=BYID, BTSID=0, CANAME="C = AU, S = Some-State, O = Internet
Widgits Pty Ltd, CN = eca1", URL="http://10.88.88.88:80/pkix/", SIGNALG=SHA256;
//Downloading an operator's root certificate from the operator's certificate &
CRL database
DLD BTSCERTFILE: IDTYPE=BYID, BTSID=0, IP="10.86.86.86", USR="admin",PWD="*****",
SRCF="OperationCA.cer", DSTF="OperationCA.cer", CT=TRUSTCERT;
ADD BTSTRUSTCERT: IDTYPE=BYID, BTSID=0, CERTNAME="OperationCA.cer";
//Setting information required for the base station to apply for an operator-
issued device certificate based on CMPv2 when the certificate application needs
to be manually triggered
//(skip this step when the certificate application is automatically triggered)
REQ BTSDEVCERT: IDTYPE=BYID, BTSID=0, CANAME="C=AU, S=Some-State, O=Internet
Widgits Pty Ltd, CN=eca1", APPCERT="OPKIDevCert.cer";
MOD BTSAPPCERT: IDTYPE=BYID, BTSID=0, APPTYPE=IKE, APPCERT="OPKIDevCert.cer";
SET BTSCERTCHKTSK: IDTYPE=BYID, BTSID=0,ISENABLE=ENABLE, PERIOD=7, ALMRNG=30,
UPDATEMETHOD=CMP;
//Downloading a CRL from the operator's certificate & CRL database
DLD BTSCERTFILE: IDTYPE=BYID, BTSID=0, IP="10.86.86.86", USR="admin",PWD="*****",
SRCF="BTS.crl", DSTF="BTS.crl", CT=CRL;
//(Optional) Adding a CRL
ADD BTSCRLPOLICY: IDTYPE=BYID, BTSID=0, CERTNAME="BTS.crl";
//Setting a CRL usage policy
SET BTSCRL: IDTYPE=BYID, BTSID=0, CRLPOLICY=NOVERIFY;
//Adding a periodic CRL download task
ADD BTSCRLTSK: IDTYPE=BYID, BTSID=0,IP="10.86.86.86", USR="admin", PWD="*****",
FILENAME="BTS.crl", ISCRLTIME=DISABLE, PERIOD=24, TSKID=0, CRLGETMETHOD=FTP;

SingleRAN
In addition, the following configuration is required to manually trigger a certificate update:

UPD BTSDEVCERT: APPCERT="OPKIDevCert.cer",REKEY=YES;

Perform the following steps to observe the PKI feature on the GBTS:
Step 1 Check the status of device certificates.
Run the MML command DSP BTSAPPCERT and check the value of Status in the query
result. If Normal is displayed, the device certificate has been loaded to the GBTS.
The following is an example.
Step 2 Check the status of trust certificates.
Run the MML command DSP BTSTRUSTCERT and check the value of Status in the query
result. If Normal is displayed, the trust certificate has been loaded to the GBTS. The
following is an example.
Step 3 (Optional) Check the CRL status.
Run the MML command DSP BTSCRL and check the value of Status in the query result. If
Normal is displayed, the CRL has been loaded to the GBTS. The following is an example.

SingleRAN
----End
8.8.4 Deactivation
For details, see 8.5.4 Deactivation.
8.9 Deployment of PKI on the Base Station Controller

deploy the PKI feature on the base station controller.
Figure 8-7 Example of the secure networking for the base station controller

NOTE

SingleRAN
in MML configurations and the CERTREQ or Certificate Request Configuration MO in
CME configurations).

Name a
Sou
rce
Common Name COMMNAME The default value of the Common Name Net
(BSC6900, field in a certificate request file is work
BSC6910) XXX.huawei.com (XXX indicates the ESN plan
of the board connecting to the transport
network). Therefore, the recommended
value of this parameter is ESN. Currently,
this parameter cannot be set to MAC or
IP.
Common Name USERADDINFO N/A

Additional Info. (BSC6910,
BSC6900)
Country COUNTRY N/A

(BSC6910,
BSC6900)
Organization ORG (BSC6910, N/A

BSC6900)
Organizational ORGUNIT N/A

Unit (BSC6910,
BSC6900)
State or Province STATEPROVINC N/A

ENAME
(BSC6900,
BSC6910)

(BSC6900,
BSC6910)

SingleRAN

Name a
Sou
rce
Key Usage KEYUSAGE This parameter can be set to one or

(BSC6900, multiple values. The recommended values
BSC6910) are DIGITAL_SIGNATURE and
KEY_ENCIPHERMENT. If this
parameter is set to
DIGITAL_SIGNATURE, the key is used
to verify the peer's digital signature during
CMPv2-based certificate application or
update and SSL authentication. If this
parameter is set to
used to encrypt the key for data
transmission during SSL-based key
exchange.
Signature SIGNALG SHA256 is recommended.

Algorithm (BSC6900, MD5 is not recommended for use because
BSC6910) it provides low security.

(BSC6910,
BSC6900)
Local Name LOCALNAME If this parameter is not set, the default

(BSC6910, value of the Common Name field in a
BSC6900) certificate is used. If this parameter is set,
the value of the Common Name field in a
certificate must be the same as the value
of this parameter.
Local IP LOCALIP The recommended value of this parameter

(BSC6900, is the external virtual IP address of the
BSC6910) OMU.
The base station controller must be configured with CA information to apply for a certificate
from the CA. The following table lists the data to be prepared for the CA (the CA MO in
MML configurations and the CA or Certificate Authority MO in CME configurations).

SingleRAN

Name a
Sou
rce
Certificate CANAME This parameter indicates the name of the Net

Authority Name (BSC6900, CA on the operator's PKI server. work
BSC6910) During a CMPv2-based certificate plan
procedure, the value of the Recipient field
in a CMPv2 message sent to the CMP
server equals the value of this parameter.
For details about how to configure this
parameter, see Figure 8-8.
For example, if the values of the C, S, L,
O, OU, CN, and E fields in the Subject
name of the certificate used for signing
CMP messages on the CA/RA AU, Some-
State, cd, Internet Widgits Pty Ltd,
Wireless, eca1, and rosa@huawei.com,
respectively, CANAME for the
organization must be set to C = AU, S =
Some-State, L = cd, O = Internet
Widgits Pty Ltd, OU = Wireless, CN =
eca1, E = rosa@huawei.com. To prevent
errors during the execution of the REQ
DEVCERT command, all of the
following conditions must be met: The
character type for the C, S, L, O, OU, and
CN fields is PRINTABLE. The character
type for the E field is IA5. The S field can
be replaced with the ST field. For base
station controllers, the S and ST fields are
regarded as the same field.
For details about the character set of the
PRINTABLE type, see RFC 3642.
Certificate URL (BSC6900, Currently, the base station controller

Authority URL BSC6910) cannot translate domain names.
Therefore, an IP address instead of a
domain name is used in the URL.
By default, the CA uses TCP port 80 for
HTTP services and TCP port 443 for
HTTPS services. The TCP port number is
determined by the CA. For example, The
URL domain name of the CA can be set
to http://10.88.88.88:80/pkix/.
Signature SIGNALG N/A

Algorithm (BSC6900,
BSC6910)

SingleRAN

Name a
Sou
rce
Certificate Fetch MODE If this parameter is set to Net

Mode (BSC6900, DEFAULT_MODE, the UPDSIP work
BSC6910) parameter does not need to be set. The plan
base station controller uses the O&M IP
address and URL as the source and
destination IP addresses, respectively, for
routine certificate management.
CFG_UPD_SIP, the UPDSIP parameter
needs to be set. The base station
controller uses UPDSIP and URL as the
source and destination IP addresses,
management.
Certificate UPDSIP N/A Net

Update Source IP (BSC6900, work
BSC6910) plan

SingleRAN
Figure 8-8 CANAME configuration
configurations and the CERTMK or Device Certificate MO in CME configurations).

SingleRAN

Name a
Sou
rce
Certificate File APPCERT l If an operator-issued device certificate Net

Name (BSC6900, is used for identity authentication work
BSC6910) between the base station controller and plan
U2000, two CERTMK MOs must be
configured to specify an operator-
issued device certificate and a
Huawei-issued device certificate,
respectively. For operator-issued
device certificates, this parameter is
set to OPKIDevCert.cer. For
Huawei-issued device certificates, this
parameter is set to usercert.pem or
hwusercert.pem.
l If a Huawei-issued device certificate is
used for identity authentication
between the base station controller and
U2000, only one CERTMK MO
needs to be configured to specify a
Huawei-issued device certificate. This
parameter is set to usercert.pem or
hwusercert.pem accordingly. Users
cannot modify or remove this MO.
configurations and the APPCERT or Device Certificate in Use MO in CME configurations).
Active certificates are device certificates that are currently used by a base station controller.

Name a
Sou
rce
Application APPTYPE l This parameter must be set to SSL. Net

Type (BSC6900, work
BSC6910) plan

SingleRAN

Name a
Sou
rce
Certificate File APPCERT l If an operator-issued device certificate

Name (BSC6910, is used for identity authentication
BSC6900) between the base station controller and
U2000, this parameter must be set to
OPKIDevCert.cer.
used for identity authentication
between the base station controller and
U2000, this parameter must be set to
usercert.pem or hwusercert.pem.
configurations and the TRUSTCERT or Trusted Certificate MO in CME configurations).

Name Sour
ce
Certificate File CERTNAME An operator's trust certificate and a Netw

Name (BSC6910, Huawei trust certificate must be ork
BSC6900) configured. For the Huawei trust plan
certificate, set this parameter to
rootca.pem on the base station controller
side. For the operator's trust certificate,
set this parameter to CN.pem when
automatic certificate application is used.
The value of CN must be the same as that
in the Subject field of the trust certificate.
If the operator's CA system has a multi-
layer structure, all trust certificates in the
certificate chain must be configured.
CERTCHKTSK MO in MML configurations and the CERTCHKTSK or Certificate
Validity Check Task MO in CME configurations).

SingleRAN
Name Sour
ce
Certificate ISENABLE The recommended value of this Netw

Validity Period (BSC6900, parameter is ENABLE. ork
Checking BSC6910) plan

Period(day) (BSC6900, this parameter.
BSC6910)

Threshold(day) (BSC6900, this parameter.
BSC6910)
Update Method UPDATEMETHO The recommended value of this

D (BSC6900, parameter is CMP.
BSC6910)
(Optional) Prepare CRL data if the base station controller needs to obtain the CRL
information from the CA. Table 8-41 lists the data to be prepared for a CRL (the CRL MO in
MML configurations and the CRL or Certificate Revocation List MO in CME
configurations).

Name Sour
ce
CRL File Name CERTNAME N/A Netw

(BSC6900, ork
BSC6910) plan
for these policies (the CRLPOLICY MO in MML configurations and the CRLPOLICY or
CRL Check Policy MO in CME configurations).

Name Sour
ce
CRL Using CRLPOLICY The default value of this parameter is Netw

Policy (BSC6910, NOVERIFY. Operators can set this ork
BSC6900) parameter based on site requirements. plan

SingleRAN
be prepared for the task (the CRLTSK MO in MML configurations and the CRLTSK or
CRL Updating Obtaining Task MO in CME configurations).

Name Sour
ce
Task ID TSKID (BSC6900, N/A User-

BSC6910) defin
ed
IP Address IP (BSC6900, Set this parameter to the IP address of Netw

BSC6910) the certificate & CRL database. ork
plan
Access Method CRLGETMETHOD The recommended value of this
(BSC6900, parameter is LDAP. Set this parameter to
BSC6910) FTP only when the peer device does not
support LDAP.
Port No. PORT (BSC6900, N/A

BSC6910)
User Name USR (BSC6900, N/A

BSC6910)
Password PWD (BSC6900, N/A

BSC6910)

(BSC6910,
BSC6900)
Using CRL's ISCRLTIME If this parameter is set to ENABLE, the

Next Update (BSC6900, base station controller downloads a CRL
BSC6910) when the next update time arrives.
CRL Updating PERIOD This parameter must be set when

Period(h) (BSC6900, ISCRLTIME (BSC6900, BSC6910) is
BSC6910) set to DISABLE.
Source IP SIP (BSC6900, This parameter indicates the source IP

BSC6910) address to download a CRL. When the IP
address is set to 0.0.0.0, the system
automatically uses the IP address of the
OMU board as the source IP address to
obtain the updated CRL from the CRL
server.
Distinguish SEARCHDN This parameter must be set when

Name (BSC6900, CRLGETMETHOD (BSC6900,
BSC6910) BSC6910) is set to LDAP.

SingleRAN

Name Sour
ce
Connection CONNMODE This parameter indicates whether to use Netw

Mode (BSC6900, SSL connections. This parameter takes ork
BSC6910) effect only when CRLGETMETHOD plan
(BSC6900, BSC6910) is set to LDAP.
Authenticate AUTHPEER This parameter indicates whether to Netw

Peer (BSC6900, authenticate the peer certificate when the ork
BSC6910) SSL connections are used. This plan
parameter takes effect only when the
CRLGETMETHOD (BSC6900,
BSC6910) parameter is set to LDAP.
If this parameter is set to authenticate the
peer certificate, the NEs and CRL server
must have been correctly configured with
the CA trust certificates and device
certificates.
FTP server. Table 8-44 lists the data to be prepared for downloading a certificate file (the
DLD CERTFILE in MML configurations).

Name Sour
ce
FTP Server IP IP N/A Netw

ork
plan
User Name USR N/A Netw

ork
plan
Password PWD N/A Netw

ork
plan
Source File SRCF N/A Netw

Name ork
plan
Destination File DSTF It is recommended that this parameter be Netw

Name set to the same value as SRCF. ork
plan

SingleRAN

Name Sour
ce
Guage Option GA This parameter determines whether to Netw

report the progress of file downloading. ork
The recommended value of this plan
parameter is Yes(Guage).
Certificate CT N/A Netw

Type ork
plan

8-45 lists the data to be prepared for applying for a device certificate based on CMPv2 (the
REQ DEVCERT in MML configurations).
Name Sourc
e
Certificate CANAME N/A Netw

Authority ork
Name plan
Certificate File APPCERT N/A Netw

Name ork
plan
(Optional) Prepare data to manually trigger a CMPv2-based certificate update. Table 8-46
lists the data to be prepared for updating a device certificate (the UPD DEVCERT in MML
configurations) based on CMPv2.
Name Sour
ce
Certificate File APPCERT This parameter specifies a certificate to Netw

Name be updated. ork
plan
Renew Key REKEY The recommended value of this Netw

parameter is YES(YES). ork
plan

SingleRAN

Name Sour
ce
Key Size KEYSIZE N/A Netw

ork
plan

This section describes how to deploy the PKI feature by using MML commands. For details
about how to deploy the PKI feature on the U2000 client, see the U2000 Help.

station controller side:
template.
Step 2 Run the MML command ADD CA to add an operator's CA.
Step 3 Run the MML command LST APPCERT to check whether the base station controller has
been configured with a device certificate for identity authentication. If the value of
Certificate File Name in the command output is usercert.pem, the preconfigured Huawei-
issued device certificate is used. In this case, go to step 4. If the value is hwusercert.pem, the
preconfigured Huawei-issued device certificate which is bound to the OMU ESN is used. In
this case, go to step 5.
Step 4 Perform the following steps to manually configure an operator-issued device certificate for
the base station controller on the U2000:
1. Run the MML command CRE CERTREQFILE to generate the certificate request file.
2. Run the MML command ULD CERTFILE to send the local certificate request file to
the U2000 to apply for the device certificate.
3. The U2000 applies to the operator's CA for a certificate. You can manually operate the
U2000 to submit the certificate request file to the operator's CA for an operator-issued
device certificate. Then, the CA returns the operator-issued device certificate to the
U2000 by manual operation. The certificate request file and operator-issued device
certificate are saved in the following directory of the U2000: /export/home/sysm/
ftproot/ftptmp.
4. Run the MML command DLD CERTFILE to download the operator's root certificate.
5. Run the MML command ADD TRUSTCERT to add an operator's trust certificate.
6. Run the MML command DLD CERTFILE to download the requested device
certificate.
7. Run the MML command ADD CERTMK to add the device certificate to the base
station controller.
8. Go to step 6.

SingleRAN
Step 5 Run the MML command REQ DEVCERT to apply an operator-issued device certificate for
the base station controller.
NOTE
If the certificate application succeeds, running the MML command REQ DEVCERT will return a
message about successful execution. In addition, running the MML command DSP CERTMK can
query whether a certificate has been applied.
Step 6 On the U2000, choose Security > Certificate Authentication Management > Certificate
Management. In the displayed interface, click Test to check whether SSL connection can be
established between the base station controller and the U2000.
NOTE
Bidirectional authentication is used for SSL certificate testing. That is, the base station controller and
U2000 authenticate the device certificates of each other. The SSL certificate testing result reflects
whether the certificates can be used.
task.
Step 10 (Optional) Run the MML command ADD CRL to add a CRL.
----End
update:
Step 1 Run the MML command UPD DEVCERT to set information about a certificate update. After
the setting takes effect, a CMPv2-based certificate update procedure is triggered.
----End

certificate on the base station controller side.
LOCALIP="10.120.20.188";
//Adding the operator's CA
//If the base station controller can access the CA only through an external
network, you are advised to set the virtual IP address of the base station
controller in the external network for certificate application and update. The
URL="http://10.88.88.88:80/pkix/", SIGNALG=SHA256, MODE= CFG_UPD_SIP,
UPDSIP="10.120.20.188";
//Setting information required for the base station controller to apply for an

SingleRAN
operator-issued device certificate based on CMPv2 when the application needs to

be manually triggered
REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd, CN=eca1",
APPCERT="OPKIDevCert.cer";
//Adding the active certificate

MOD APPCERT: APPTYPE=IKE, APPCERT="OPKIDevCert.cer";

SET CERTCHKTSK: ISENABLE=ENABLE, PERIOD=7, ALMRNG=30, UPDATEMETHOD=CMP;
//(Optional) Downloading a CRL from an FTP server (assume that the FTP server is
deployed on the U2000, indicating that the IP address of the FTP server is the
same as that of the U2000)
DLD CERTFILE: CT=CRL, SRCF="bsc.crl", DSTF="bsc.crl", IP="10.120.86.86",
USR="admin";
ADD CRL: CERTNAME="bsc.crl";
SET CRLPOLICY: CRLPOLICY= NOVERIFY;
ADD CRLTSK: TSKID=0, IP="10.120.86.86", CRLGETMETHOD=LDAP, USR="admin",
PWD="*****", FILENAME="bsc.crl", ISCRLTIME=DISABLE, PERIOD=24;
//In addition, the following configuration is required to manually trigger a

certificate update:
UPD DEVCERT: APPCERT="OPKIDevCert.cer",REKEY=YES;

Run the MML command DSP APPCERT and check the values of the Certificate File
Name, Issuer, Common Name, and Status parameters in the query result. If the values of
Certificate File Name, Issuer, and Common Name are correct and the value of Status is
Normal, the device certificate has been loaded to the base station controller.
Step 2 Check the status of trust certificates.

Run the MML command DSP TRUSTCERT and check the value of Status in the query
result. If Normal is displayed, the trust certificate has been loaded to the base station
controller.

SingleRAN
Step 3 (Optional) Check the CRL status.
Run the MML command DSP CRL and check the value of Status in the query result. If
Normal is displayed, the CRL has been loaded to the base station controller.
----End
8.9.4 Deactivation
For details, see 8.5.4 Deactivation.
8.10 Deployment of PKI on the eCoordinator

deploy the PKI feature on the eCoordinator.

SingleRAN
Figure 8-9 Example of the secure networking for the eCoordinator

Prepare the following data before using the U2000 to manually configure an operator-issued
device certificate for the eCoordinator:
l Data for certificate requests
l Data for device certificates
l Data for active certificates
l Data for trust certificates
l Data for periodic certificate validity checks
l Data for CRLs
l (Optional) Data for CRL usage policies
l (Optional) Data for periodic CRL download tasks
l (Optional) Data for downloading certificate files
NOTE
l Managed objects (MOs) include parameters and MML commands related to the MOs. For details,
see ECO6910 Parameter Reference.
l In the following tables, "N/A" indicates that there is no special requirement for the parameter
setting. You can set the parameter based on site requirements.
in MML configurations).

SingleRAN

Name Source
Common Name COMMNAME The common name can only be the Network
electronic serial number (ESN). plan
Enumeration values such as MAC and
IP are not supported. Upon the
generation of a certificate request file,
the value of the ESN is used as the
common name of the certificate
request file.
Common Name USERADDINF N/A

Additional Info. O
Country COUNTRY N/A
Organization ORG N/A
Organizational ORGUNIT N/A

Unit
State or Province STATEPROVI N/A

NCENAME
Key Usage KEYUSAGE N/A
Signature SIGNALG SHA256 is recommended.

Algorithm MD5 is not recommended for use
Local Name LOCALNAME If this parameter is not set, the value of

the Common Name field in a
certificate is used (for example,
03021377001000001.huawei.com).
If this parameter is set, the value of
this parameter is the configured value.
Local IP LOCALIP N/A
NOTE
There is a Common Name field in both the certificate request message sent from the U2000 to the
CA/RA and the obtained digital certificate. The value of this field is a combination of the values for
Common Name and Common Name Additional Info., for example,
03021377001000001.huawei.com.
configurations).

SingleRAN

Parameter Parameter Setting Notes Data
Name ID Source
Certificate APPCERT l If an operator-issued device certificate is Network

File Name used for identity authentication between the plan
eCoordinator and U2000, two CERTMK
MOs must be configured to specify an
operator-issued device certificate and a
Huawei-issued device certificate,
respectively. This parameter must be set to
OPKIDevCert.cer for the operator-issued
device certificate and
eCoordinator_Certificate.cer for the
Huawei-issued device certificate.
used for identity authentication between the
eCoordinator and U2000, only one
CERTMK MO needs to be configured to
specify a Huawei-issued device certificate.
This parameter needs to be set to
eCoordinator_Certificate.cer accordingly.
Users cannot modify or remove this MO.
NOTE
You can run the LST CERTFILE command to query all certificates on the eCoordinator. If the query
result shows that a certificate is inactive, run the ADD CERTMK command to activate it.
configurations). Active certificates are device certificates that are currently used by the
eCoordinator.

Parameter Paramete Setting Notes Data
Name r ID Source
Application Type APPTYPE This parameter must be set to SSL because Network
the eCoordinator does not support IKE plan
currently.
Certificate File APPCERT The certificate file name must have been
Name configured in a CERTMK MO.
configurations).

SingleRAN

Name Source
Certificate File CERTNAME l An operator's trust certificate and a Network

Name Huawei trust certificate must be plan
configured. For the Huawei trust
certificate, set this parameter to
rootca.pem. For the operator's
trust certificate, it is recommended
that this parameter be set to
OperationCA.cer.
l If the operator's CA system has a
multi-layer structure, all trust
certificates in the certificate chain
must be configured.
CERTCHKTSK MO in MML configurations).

Name Source
Certificate ISENABLE The recommended value of this Network

Validity parameter is ENABLE. plan
Checking

Period(day) this parameter.

Threshold(day) this parameter.
Update Method UPDATEMET The default value is recommended for

HOD this parameter. The eCoordinator
currently does not support CMP.
(Optional) If the eCoordinator needs to obtain CRL information from the CA, the following
data must be prepared:
l Data to be prepared for a CRL (the CRL MO in MML configurations). For details, see
Table 8-52.
l Data to be prepared for CRL usage policies (the CRLPOLICY MO in MML
configurations). For details, see Table 8-53.
l Data to be prepared for a periodic CRL download task (the CRLTSK MO in MML
configurations). For details, see Table 8-54.

SingleRAN

Name Source
CRL File Name CERTNAME N/A Network

plan

Name Source
CRL Using CRLPOLICY The default value of this parameter is Network

Policy NOVERIFY. Operators can set this plan
parameter based on site requirements.

Parameter Parameter Setting Notes Data
Name ID Source
IP Address IP Set this parameter to the IP address of Network

the CRL server. plan
User Name USR N/A
Password PWD N/A
Using CRL's ISCRLTIME If this parameter is set to ENABLE, the

Next Update eCoordinator downloads a CRL when
the next update time arrives.
CRL Updating PERIOD Set this parameter when ISCRLTIME is

Period(h) set to DISABLE.
Access Method CRLGETME The recommended value of this

THOD parameter is FTP. Value LDAP is
currently not supported by the
eCoordinator.
Task ID TSKID N/A User-

defined
Source IP SIP If this parameter is not set, the Network

eCoordinator uses the O&M IP address plan
as the source IP address to update a
CRL.

SingleRAN
FTP server. Table 8-55 lists the data to be prepared for downloading a certificate file (the
CERTFILE MO in MML configurations).

ter ID Source
Certificate Type CT N/A Network

plan

plan
Destination File DSTF It is recommended that this parameter be Network

Name set to the same value as SRCF. plan

plan

plan

plan

The recommended value of this parameter
is Yes(Guage).
Using the U2000

Perform the following procedures to apply for and activate an operator-issued device
certificate: Configure an operator's root certificate.
Step 1 For details, see Operation and Maintenance > Security Management > Data Management
> Configuring Digital Certificates > Importing CA Certificates in U2000 Product
Documentation.
Step 2 Configure and activate an operator-issued device certificate. For details, see Operation and
Maintenance > Security Management > Data Management > Configuring Digital
Certificates > Manually Installing a Device Certificate in U2000 Product Documentation.
Obtain a CRL.
Step 3 For details, see Operation and Maintenance > Security Management > Data Management
> Obtaining the Certificate Revocation List in U2000 Product Documentation.
----End

SingleRAN
Using MML Commands

Perform the following steps to apply for and activate an operator-issued device certificate:
template.
Step 2 Run the MML command CRE CERTREQFILE to generate the certificate request file.
Step 3 Run the MML command ULD CERTFILE to upload the certificate request file to the
U2000.
Step 4 O&M personnel submit the certificate request file uploaded to the U2000 in Step 3 to the
operator's CA, obtain the operator-issued device certificate from the operator's CA, and save
the device certificate to the U2000. The certificate request file and operator-issued device
certificate are saved in the following directory of the U2000: /export/home/sysm/ftproot/
ftptmp.
Step 5 Run the MML command DLD CERTFILE to download the operator's root certificate from
the U2000 to the eCoordinator.
Step 6 Run the MML command ADD TRUSTCERT to add the operator's trust certificate.
Step 7 Run the MML command DLD CERTFILE to download the operator-issued device
certificate to the eCoordinator.
Step 8 Run the MML command ADD CERTMK to add the operator-issued device certificate to the
eCoordinator.
Step 9 On the U2000, choose Security > Certificate Authentication Management > Certificate
Management. In the certificate management window, select the requested operator-issued
device certificate. Click Test to test whether an SSL connection can be established between
the eCoordinator and the U2000 by using this device certificate.
NOTE
Bidirectional authentication is used for SSL certificate testing. That is, the eCoordinator and U2000
authenticate the device certificates of each other. The SSL certificate testing result reflects whether the
certificates can be used.
task.
Step 13 (Optional) Run the MML command ADD CRL to add a CRL.
----End
MML Command Examples


SingleRAN

LOCALIP="10.20.20.188";
//Generating a certificate request file
CRE CERTREQFILE:FILENAME="ECO6910Cert.req",REQMODE=NEW;
///Uploading the certificate request file
ULD
CERTFILE:CT=CERTREQ,SRCF="ECO6910Cert.req",DSTF="ECO6910Cert.req",IP="10.86.86.86"
,USR="admin",PWD="*****";
//O&M personnel apply for an operator-issued device certificate on the U2000. For
details, see section "Manually Applying For a Device Certificate" in U2000
Product Documentation.
//Downloading an operator-issued device certificate from the CA (assuming that
the FTP server is deployed on the U2000, and therefore the IP address of the FTP
DLD CERTFILE:CT=DEVCERT,SRCF="/Cert/
OPKIDevCert.cer",DSTF="OPKIDevCert.cer",IP="10.86.86.86",USR="admin",PWD="*****";
//Adding a device certificate
ADD CERTMK:APPCERT="OPKIDevCert.cer";
//Downloading an operator's root certificate from an FTP server (assume that the
FTP server is deployed on the U2000, indicating that the IP address of the FTP
DLD
CERTFILE:CT=TRUSTCERT,SRCF="OperationCA.cer",DSTF="OperationCA.cer",IP="10.86.86.8
6",USR="admin",PWD="*****";
ADD TRUSTCERT:CERTNAME="OperationCA.cer";
MOD APPCERT:APPTYPE=SSL,APPCERT="OPKIDevCert.cer";
SET CERTCHKTSK:ISENABLE=ENABLE,PERIOD=7,ALMRNG=30,UPDATEMETHOD=CMP;
//(Optional) Downloading the CRL file from the FTP server. If the FTP server is
deployed on the U2000, the IP address of the FTP server is the same as that of
the U2000.
DLD
CERTFILE:CT=CRL,SRCF="ECO.crl",DSTF="ECO.crl",IP="10.86.86.86",USR="admin",PWD="**
***";
ADD CRL:CERTNAME="ECO.crl";
SET CRLPOLICY:CRLPOLICY=NOVERIFY;
ADD
CRLTSK:TSKID=0,IP="10.86.86.86",USR="admin",PWD="*****",FILENAME="ECO.crl",ISCRLTI
ME=DISABLE;
Using the CME

Set parameters on the CME configuration interface according to the MOs, parameters, and
application scenarios described in 8.10.1 Data Preparation. For instructions on how to
perform the CME single configuration, see CME Single Configuration Operation Guide.

Perform the following steps to observe whether the PKI feature has been activated:
Step 1 Run the MML command DSP APPCERT to check the status of device certificates. If the
values of Certificate File Name, Issuer, and Common Name are correct and the value of
Status is Normal, the device certificate has been loaded to the eCoordinator.
Step 2 Run the MML command DSP TRUSTCERT to check the status of trust certificates. If the
value of Status is Normal in the query result, the trust certificate has been loaded to the
eCoordinator.

SingleRAN
Step 3 (Optional) Run the MML command DSP CRL to check the CRL status. If the value of Status
is Normal in the query result, the CRL has been loaded to the eCoordinator.
----End
8.10.4 Deactivation
This feature does not need to be deactivated.
8.11 Deployment of PKI Redundancy on the eGBTS/

NodeB/eNodeB/Multimode Base Station
deploy PKI redundancy on the eGBTS, NodeB, eNodeB, or multimode base station.
NOTE
This section only describes how to deploy PKI redundancy by using the MML commands or the CME.
For details about how to deploy PKI on the U2000 client, see the U2000 Help.
Figure 8-10 Example of the secure networking for the eGBTS/NodeB/eNodeB/multimode

base station

Compared with the data to be prepared described in section 8.5.1 Data Preparation the
following lists the additional data for preparation.
The following table lists the additional data to be prepared for the CA (the CA MO).

SingleRAN

Name Source
Slave Certificate SLVURL This parameter needs to Network

Authority URL be set when PKI plan
redundancy is enabled.
Slave CA URL SLVINITREQURL This parameter needs to Network

During Site be set when PKI plan
Deployment redundancy is enabled.
(Optional) The following table lists the additional data to be prepared for a periodic CRL
download task.

Name Source
Slave IP Address SLVIP This parameter needs to be Network

set to the IP address of the plan
standby CRL server when
PKI redundancy is
enabled.
Slave User SLVUSR This parameter needs to be Network

Name set when PKI redundancy plan
is enabled.
Slave Password SLVPWD This parameter needs to be Network

set when PKI redundancy plan
is enabled.
Slave Port No. SLVPORT This parameter can be set Network

only when PKI plan

This section describes only the configurations that are different from those described in
section 8.5.2 Initial Configuration. The following lists the differences in MML commands.
The following lists the differences in MML commands.
In the PKI redundancy scenario, the configurations of the CA and periodic CRL download
task are as follows:
through the intranet and O&M data is protected by IPsec, you are advised to set
the source IP addresses for certificate application and update to an interface IP
address and an O&M IP address (for example, 10.31.31.188), respectively. The

SingleRAN
UPDSIP="10.31.31.188", INITREQURL="http://10.89.89.89:80/
pkix/",INITREQSIP="10.20.20.188",SLVURL="http://10.98.98.98:80/
pkix/",SLVINITREQURL="http://10.99.99.99:80/pkix/";
through the intranet and O&M data is not protected by IPsec, you are advised to
set the source IP addresses for certificate application and update to an
interface IP address and an intranet IP address(for example, 10.45.45.45),
respectively. The following is an example:
UPDSIP="10.45.45.45", INITREQURL="http://10.89.89.89:80/
pkix/",INITREQSIP="10.20.20.188",SLVURL="http://10.98.98.98:80/
pkix/",SLVINITREQURL="http://10.99.99.99:80/pkix/";
//If the base station can access the CA only through an external network, you are
advised to set the source IP addresses for both certificate application and
update to interface IP addresses. The following is an example:
ADD CA: CANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN =
eca1",URL="http://10.88.88.88:80/
pkix/",SIGNALG=SHA256,MODE=CFG_INIT_UPD_ADDR,UPDSIP="10.20.20.188",INITREQURL="htt
p://10.89.89.89:80/pkix/",INITREQSIP="10.20.20.188",SLVURL="http://10.98.98.98:80/
pkix/",SLVINITREQURL="http://10.99.99.99:80/pkix/",CERTREQSW=DEFAULT;
//(Optional) Adding a periodic CRL download task
ADD CRLTSK: IP="10.86.86.86", USR="admin", PWD="*****", FILENAME="eNodeB.crl",
ISCRLTIME=DISABLE, PERIOD=24, TSKID=0, CRLGETMETHOD=FTP, SLVIP="10.96.96.96",
SLVUSR="admin2", SLVPWD="*****";

The certificate update and CRL file obtaining succeed when the active PKI server is faulty
and the standby PKI server is normal. You can run MML commands to query the status of the
device certificates and CRL files. If the results shown in the following figures are displayed,
PKI redundancy functions properly.

Run the MML command DSP CERTMK. In the command output, CA URL Last Used
indicates the URL of the standby CA, and Last Update Time of Certificate indicates the
time of the latest certificate update.
Step 2 Check the status of CRL files.

Run the MML command DSP CRL. In the command output, CRL Server IP Address Last
Used indicates the IP address of the standby CRL, and Last Update Time of CRL indicates the
time of the latest CRL obtaining.

SingleRAN
----End
8.11.4 Deactivation
----End
8.12 Deployment of PKI Redundancy on the Base Station

Controller
PKI redundancy on the base station controller helps improve the reliability of the device
certificate and CRL update. Therefore, the standby CA and CRL servers must be configured
before PKI redundancy is enabled.

Compared with the data to be prepared described in section 8.9.1 Data Preparation the
following lists the additional data for preparation.
The following table lists the additional data to be prepared for the CA (the CA MO).

Name Source
Slave SLVURL (BSC6900, This parameter needs to be Network

Certificate BSC6910) set when PKI redundancy is plan
Authority enabled.
URL
(Optional) The following table lists the additional data to be prepared for a periodic CRL
download task.

SingleRAN

Name Source
Slave IP SLVIP (BSC6900, BSC6910) This parameter needs to be Network

Address set to the IP address of the plan
standby CRL server when
PKI redundancy is enabled.
Slave User SLVUSR (BSC6900, This parameter needs to be Network

Name BSC6910) set when PKI redundancy is plan
enabled.
Slave SLVPWD (BSC6910, This parameter needs to be Network

Password BSC6900) set when PKI redundancy is plan
enabled.
Slave Port SLVPORT (BSC6910, This parameter can be set Network

No. BSC6900) only when PKI redundancy is plan
enabled.

This section describes only the configurations that are different from those described in
section 8.9.2 Initial Configuration. The following lists the differences in MML commands.
//If the base station controller can access the CA only through an external
network, you are advised to set the virtual IP address of the base station
controller in the external network for certificate update. The following is an
example:
URL="http://10.88.88.88:80/pkix/", SIGNALG=SHA256, MODE= CFG_UPD_SIP,
UPDSIP="10.120.20.188",SLVURL="http://10.98.98.98:80/pkix/";
//(Optional) Adding a periodic CRL download task
ADD CRLTSK: TSKID=1, IP="10.86.86.86", CRLGETMETHOD=LDAP, PORT=389, USR="admin",
PWD="*****", FILENAME="bsc.crl", ISCRLTIME=ENABLE, SIP="10.120.20.188",
SLVIP="10.86.86.90", SLVPORT=389, SLVUSR="test", SLVPWD="*****", SEARCHDN="C =
AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca1";

The certificate update and CRL file obtaining succeed when the active PKI server is faulty
and the standby PKI server is normal. You can run MML commands to query the status of the
device certificates and CRL files. If the results shown in the following figures are displayed,
PKI redundancy functions properly.
Run the MML command DSP CERTMK. In the command output, CA URL Last Used
indicates the URL of the standby CA, and Last Update Time of Certificate indicates the
time of the latest certificate update.

SingleRAN
Step 2 Check the status of CRL files.

Run the MML command DSP CRL. In the command output, CRL Server IP Address Last
Used indicates the IP address of the standby CRL, and Last Update Time of CRL indicates
the time of the latest CRL obtaining.
----End
8.12.4 Deactivation
----End
8.13 Reconstruction from a PKI-based Secure Network to a

PKI Redundancy Network on the eGBTS/NodeB/eNodeB/
Multimode Base Station
This section uses the networking illustrated in Figure 8-11 as an example to describe the
reconstruction requirements and reconfiguration procedure when a PKI-based secure network
is reconstructed into a PKI redundancy network on the eGBTS, NodeB, eNodeB, or
multimode base station.

SingleRAN
Figure 8-11 Example of reconstructing a PKI-based secure network into a PKI redundancy network on the
eGBTS, NodeB, eNodeB, or multimode base station
NOTE

SingleRAN
General Procedure
Network Deployment and Information Collection

l A standby PKI server has been deployed on the network.
l The active and standby PKI servers have the same CA name and root certificate or
certificate chain and synchronize certificate management databases between them. There
should be reachable routes between the base station and the two PKI servers.
l Engineering personnel collect information about the standby PKI server, including the
URL of the standby CA, URL of the CA which issues the certificate during deployment,
IP address of the standby CRL server, user name, password, and port number.
Data Planning
In additional to the original configuration data, you need to configure data for the standby CA
and standby CRL server.
The following table lists the data to be prepared for the standby CA.

Name Source
Slave Certificate SLVURL This parameter needs to be set Network

Authority URL when PKI redundancy is plan
enabled.

SingleRAN

Name Source
Slave CA URL SLVINITREQURL Network

During Site plan
Deployment
(Optional) The following table lists the data to be prepared for a periodic CRL download task.

Name Source
Slave IP Address SLVIP This parameter needs to be set Network

to the IP address of the standby plan
CRL server when PKI
Slave User Name SLVUSR This parameter needs to be set Network

when PKI redundancy is plan
enabled.
Slave Password SLVPWD Network
plan
Slave Port No. SLVPORT Network

plan
Preparing the Incremental Script

An incremental script is generated based on data of existing base stations and includes
configuration modifications.
For details about how to modify PKI redundancy configurations, see 8.5.2.1 Using the CME.
Checking the Base Station Environment

l The base station meets the hardware requirements described in section 8.3 Hardware
Planning.
l The license for the PKI redundancy feature has been activated on the base station.
Downloading the Modified Data

The procedure for downloading the modified data is as follows:
1. On the main menu of the U2000, click in the upper left corner.
2. On the Application Center tab page, double-click the CME icon to start the CME.
3. On the CME, choose CM Express > Planned Area, and click to export the
incremental script.

SingleRAN
4. In the Export Incremental Scripts dialog box, choose a specific base station to which
the script is exported, specify Output Path and Script Executor Operation, and click
OK.
5. On the displayed Script Executor page, observe the export progress.
Activation Observation
For details, see section 8.11.3 Activation Observation.
8.14 Reconstruction from a PKI-based Secure Network to a

PKI Redundancy Network on the Base Station Controller
This section uses the networking illustrated in Figure 8-12 as an example to describe the
reconstruction requirements and reconfiguration procedure when a PKI-based secure network
is reconstructed into a PKI redundancy network on the base station controller.

SingleRAN
Figure 8-12 Example of reconstructing a PKI-based secure network into a PKI redundancy
network on the base station controller

SingleRAN
General Procedure
Network Deployment and Information Collection

l A standby PKI server has been deployed on the network.
l The active and standby PKI servers have the same CA name and root certificate or
certificate chain and synchronize certificate management databases between them. There
are reachable routes between the base station controller and the two PKI servers.
l Engineering personnel collect information about the standby PKI server, including the
URL of the standby CA, IP address of the standby CRL server, user name, password, and
port number.
Data Planning
In additional to the original configuration data, you need to configure data for the standby CA
and standby CRL server.
The following table lists the data to be prepared for the standby CA.

Name Source
Slave Certificate SLVURL (BSC6910, This parameter needs to be set Network

Authority URL BSC6900) when PKI redundancy is plan
enabled.

SingleRAN
(Optional) The following table lists the data to be prepared for a periodic CRL download task.

Name Source
Slave IP Address SLVIP (BSC6910, This parameter needs to be set Network

BSC6900) to the IP address of the standby plan
CRL server when PKI
Slave User Name SLVUSR (BSC6910, This parameter needs to be set Network
BSC6900) when PKI redundancy is plan
enabled.
Slave Password SLVPWD (BSC6900, This parameter needs to be set Network

BSC6910) when PKI redundancy is plan
enabled.
Slave Port No. SLVPORT This parameter can be set only Network
(BSC6910, BSC6900) when PKI redundancy is plan
enabled.
Preparing the Incremental Script

For details about how to modify PKI redundancy configurations, see 8.9.2 Initial
Configuration.
Checking the Base Station Controller Environment

The license for the PKI redundancy feature has been activated on the base station controller.
Downloading the Modified Data

1. The procedure for downloading the modified data is as follows: On the main menu of the
U2000, click in the upper left corner.

2. On the Application Center tab page, double-click the CME icon to start the CME.
3. On the CME, choose CM Express > Planned Area, and click to export the
incremental script.
4. In the Export Incremental Scripts dialog box, choose a specific base station controller
to which the script is exported, specify Output Path and Script Executor Operation,
and click OK.
5. On the displayed Script Executor page, observe the export progress.
6. After the export is complete, restart the base station controller to make the script take
effect.
Activation Observation

SingleRAN
8.15 Reconfiguration
In Certificate Authority Name, the S and ST fields are regarded as the same field. Services
can be properly provided if the S field is used at one end but the ST field is used at the peer
end.
To reconfigure the S or ST field, perform the following steps:
Step 1 Run the RMV CA command to remove the old CA.
Step 2 Run the ADD CA command to add a CA.
----End
MML command examples are as follows:
RMV CA:CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd, CN=eca1";
ADD CA:CANAME="C=AU, ST=Some-State, O=Internet Widgits Pty Ltd, CN=eca1",
URL="http://10.88.88.88:80/pkix/";
8.16 Performance Monitoring

The PKI feature does not require performance optimization.
8.17 Parameter Optimization

The PKI feature does not require performance optimization.
8.18 Possible Issues
8.18.1 Base Station Side

When the PKI feature is used, the base station reports the following alarms to facilitate fault
diagnosis:
l ALM-26832 Peer Certificate Expiry
l ALM-26840 Imminent Certificate Expiry
l ALM-26841 Certificate Invalid
l ALM-26842 Automatic Certificate Update Failed
After any of the preceding alarms is reported, O&M personnel need to find the cause and
clear the alarm according to the alarm information. For details about how to clear these alarms
for each type of base station, see 3900 Series Base Station Alarm Reference.
8.18.2 Base Station Controller/eCoordinator Side

When the PKI feature is used, the base station controller/eCoordinator reports the following
alarms to facilitate fault diagnosis:
l ALM-20732 SSL Certificate File Abnormity

SingleRAN
l ALM-20850 Digital Certificate Will Be out of Valid Time

l ALM-20851 Digital Certificate Loss, Expiry, or Damage
l ALM- 20803 Certificate Auto-update Failed
After any of the preceding alarms is reported, O&M personnel need to find the cause and
clear the alarm according to the alarm information. For details about how to clear these alarms
for the base station controller, see BSC6900 GU Alarm Reference and BSC6910 GU Alarm
Reference. For details about how to clear these alarms for the eCoordinator, see ECO6910
Alarm Reference.
Use the following guidance to handle a damaged certificate.
When an SSL connection and device certificates are used for authentication between the base
station controller/eCoordinator and U2000, the base station controller/eCoordinator may get
out of control from the U2000 if faults occur on the base station controller/eCoordinator side,
for example, a certificate damage.
In this case, check the alarm on the U2000 first, and then clear the alarm according to related
handling suggestions. If the alarm cannot be cleared on the U2000, O&M personnel need to
log in to the base station controller/eCoordinator LMT as local users to check the alarm
information. If ALM-20851 Digital Certificate Loss, Expiry, or Damage is generated, re-apply
for a device certificate for the base station controller/eCoordinator according to the alarm
information, and then replace the certificate.

SingleRAN 9 Engineering Guidelines for Digital Certificate Whitelist
PKI Feature Parameter Description Management
9 Engineering Guidelines for Digital

Certificate Whitelist Management
9.1 When to Use

This feature is recommended when no PKI system is deployed on the network and the
preconfigured Huawei certificates will be used for IKE/IPsec authentication.
9.2 Required Information

Collect the common names in the preconfigured Huawei-issued device certificates of all base
stations and SeGWs to be connected to the network.
9.3 Deployment
9.3.1 Process
Figure 9-1 shows the process of deploying Digital Certificate Whitelist Management.

Figure 9-1 Process of deploying Digital Certificate Whitelist Management
9.3.2 Requirements
Other Features
For details, see 6 Related Features.
Hardware
l For an eGBTS, only the Ethernet ports on the UMPT, BBU3910A, and UTRPc support
this feature.
l For a NodeB, only the UMPT, BBU3910A, and UTRPc support this feature.
l For an LTE FDD eNodeB, only the UMPT, BBU3910A, LMPT, and UTRPc support this
feature.
License
Feature Feature License License NE Sales Unit
ID Name Control Item Control Item
ID Name
GBFD-18 BTS LGB3BSDCWM BTS BTS Per BTS

1202 Supporting 01 Supporting
Digital Digital
Certificate Certificate
Whitelist Whitelist
Manageme Management(p
nt er BTS)

Feature Feature License License NE Sales Unit

ID Name Control Item Control Item
ID Name
WRFD-1 NodeB LQW9SDCWL NodeB NodeB Per NodeB

81220 Supporting M01 Supporting
Digital Digital
Certificate Certificate
Whitelist Whitelist
Manageme Management
nt (per NodeB)
LOFD-11 eNodeB LT1SDIGWHI00 eNodeB Macro Per eNodeB

1203 Supporting Supporting eNodeB/
Digital Digital LampSite
Certificate Certificate eNodeB/
Whitelist Whitelist Micro
Manageme Management(F eNodeB
nt DD)
Other Requirements
SeGWs must be Huawei devices and support Digital Certificate Whitelist Management.
9.3.3 Precautions
None
9.3.4 Data Preparation and Feature Activation
9.3.4.1 Data Preparation

The following tables list the data to be prepared for activating Digital Certificate Whitelist
Management on the base station side.
Table 9-1 Parameters in the DLD CERTFILE command

Parameter Name Parameter ID Setting Notes Data
Source
FTP Server IP IP Set these parameters based User-

on the site conditions. defined
User Name USR
Password PWD
Source File Name SRCF
Destination File DSTF

Name
Guage Option GA


Source
Certificate Type CT Set this parameter to

CERTWHITELST(CER
TWHITELST).
Table 9-2 Parameters in the ACT CERTWHITELSTFILE command

Source
Digital Certificate CERTWHITELSTFILE Set this parameter based User-

Whitelist File Name NAME on the site conditions. defined
Integrity Check INTEGRITYCHECKS Set this parameter to User-

Switch W ON(On). defined
Integrity Check INTERGRITYCHECKP Set this parameter based User-

Password WD on the site conditions. defined
Table 9-3 Parameters in the SET CERTCFG command

Source
IKE Check Switch IKECHECKSW Set this parameter to User-

ON(On). defined

Type


Type

You can configure a digital certificate whitelist on the U2000, download it from the U2000 to
a base station, and then activate it. For details, see descriptions in U2000 Product
Documentation.
This section describes how to activate a digital certificate whitelist using MML command on
the base station.
Step 1 Run the DLD CERTFILE command to download a digital certificate whitelist from the
U2000 to the base station.
Step 2 Run the ACT CERTWHITELSTFILE command to activate the digital certificate whitelist.
Step 3 Run the SET CERTCFG command to turn on the IKE check switch.
----End

//Downloading a digital certificate whitelist from the U2000 to a base station
DLD CERTFILE: IP="192.168.1.1", USR="admin", PWD="*****",
SRCF="certwhitelist.gz", DSTF="certwhitelist.gz",CT=CERTWHITELST;
//Activating the digital certificate whitelist

ACT CERTWHITELSTFILE: CERTWHITELSTFILENAME="certwhitelist.gz",
INTEGRITYCHECKSW=ON, FILEPWD="********";
//Turning on the IKE check switch

SET CERTCFG: IKECHECKSW=ON;

After Digital Certificate Whitelist Management is deployed, observe the status of IPsec
tunnels using the digital certificate whitelist to determine whether this feature has been
successfully enabled.
Step 1 Run the DSP IPSECSA command to check the IPsec SA status.
Step 2 Check whether services protected by the IPsec tunnel are normal.
l Initiate a voice service and a data service and then check whether the two services are
running normally.
l Check whether the corresponding base station is online on the topology view of the
U2000.
----End

9.3.6 Deactivation
Table 9-4 lists the data to be prepared for deactivating this feature.
Table 9-4 Data to be prepared for deactivating this feature

MO Parameter Name Parameter ID Setting Notes
CERTCFG IKE Check Switch IKECHECKSW Set this parameter to

OFF(Off).
This feature can be deactivated using the CME or MML commands.

The method of using the CME to deactivate this feature is the same as that of using the CME
to activate this feature. For details, see 9.3.4.2 Using the CME.

Run the SET CERTCFG command to turn off the IKE check switch.

//Turning off the IKE check switch
SET CERTCFG: IKECHECKSW=OFF;
9.4 Performance Monitoring

None
9.5 Parameter Optimization

None
9.6 Possible Issues

None

SingleRAN
PKI Feature Parameter Description 10 Parameters
10 Parameters
Table 10-1 Parameters

Parame NE MML Feature Feature Description
ter ID Comma ID Name
nd
LOCAL BTS390 MOD LOFD-0 Public Meaning: Indicates the IP address of the subject
IP 0, CERTR 03010 / Key alternative name of a certificate.
BTS390 EQ TDLOF Infrastru GUI Value Range: Valid IP address
0 LST D-00301 cture(P
WCDM 0 KI) Unit: None
CERTF
A, ILE Actual Value Range: Valid IP address
BTS390 GBFD-1 BTS
LST 13526 Supporti Default Value: 0.0.0.0
0 LTE
CERTR ng PKI
EQ WRFD-
140210 NodeB
PKI
Support
LOCAL BSC690 MOD GBFD-1 BTS Meaning: Equipment's local IP address.

IP 0 BTSCE 13526 Supporti GUI Value Range: Valid IP Address
RTREQ ng PKI
Unit: None
Actual Value Range: Valid IP Address
Default Value: 0.0.0.0
LOCAL BSC691 MOD GBFD-1 BTS Meaning: Equipment's local IP address.

IP 0 BTSCE 13526 Supporti GUI Value Range: Valid IP Address
RTREQ ng PKI
Unit: None

SingleRAN

nd
CRLPO BTS390 SET LOFD-0 Public Meaning: Indicates the policy type. There are three
LICY 0, CRLPO 03010 / Key policies using CRLs: (1) The BS does not perform
BTS390 LICY TDLOF Infrastru CRL-based certificate checks. (2) The BS performs
0 LST D-00301 cture(P CRL-based certificate checks and reports alarms when
WCDM CRLPO 0 KI) the checks fail. (3) The BS performs CRL-based
A, LICY certificate checks, and it reports alarms and
BTS390 GBFD-1 BTS disconnects from the peer device when the checks fail.
0 LTE 13526 Supporti The value NOVERIFY indicates that the BS does not
ng PKI perform CRL-based certificate checks on the peer
WRFD-
140210 NodeB device. The value ALARM indicates that the BS
PKI performs CRL-based certificate checks on the peer
Support device and reports ALM-26832 Peer Certificate
Expiry if the peer certificate has been revoked. The
value DISCONNECT indicates that the BS performs
CRL-based certificate checks on the peer device. If
the BS finds that the peer certificate has been revoked,
the BS stops the link negotiation with the peer device
and reports ALM-26832 Peer Certificate Expiry. If the
BS finds that the CRL expires, the BS stops the link
negotiation with the peer device.
GUI Value Range: NOVERIFY(No Verifying),
ALARM(Send an Alarm If Verifying CRL Failed),
DISCONNECT(Disconnect If Verifying CRL Failed)
Unit: None
Actual Value Range: NOVERIFY, ALARM,
DISCONNECT
Default Value: NOVERIFY(No Verifying)
DEPLO BTS390 SET LOFD-0 Public Meaning: Indicates the deployment position of a
YTYPE 0, CERTD 03010 / Key digital certificate. If this parameter is set to
BTS390 EPLOY TDLOF Infrastru DEFAULT, the certificate is configured on the main
0 LST D-00301 cture(P control board. If this parameter is set to SPECIFIC,
WCDM CERTD 0 KI) the certificate is configured on the board in the
A, EPLOY specified slot. If this parameter is set to NULL, no
BTS390 GBFD-1 BTS certificate is configured on the BS.
0 LTE 13526 Supporti
ng PKI GUI Value Range: DEFAULT(Default),
WRFD- SPECIFIC(Specific), NULL(NULL)
140210 NodeB Unit: None
PKI
Support Actual Value Range: DEFAULT, SPECIFIC, NULL
Default Value: DEFAULT(Default)

SingleRAN

nd
DEPLO BSC690 SET GBFD-1 BTS Meaning: Deploying position type of the BTS
YTYPE 0 BTSCE 13526 Supporti certificate.
RTDEP ng PKI GUI Value Range: DEFAULT(Default Position),
LOY SPECIFIC(Specifig Position), NULL(No Certification
Deploy)
Unit: None
Actual Value Range: DEFAULT, SPECIFIC, NULL
Default Value: NULL(No Certification Deploy)
DEPLO BSC691 SET GBFD-1 BTS Meaning: Deploying position type of the BTS
YTYPE 0 BTSCE 13526 Supporti certificate.
RTDEP ng PKI GUI Value Range: DEFAULT(Default Position),
LOY SPECIFIC(Specifig Position), NULL(No Certification
Deploy)
Unit: None
Actual Value Range: DEFAULT, SPECIFIC, NULL
Default Value: NULL(No Certification Deploy)
CN BTS390 SET LOFD-0 Public Meaning: Indicates the number of the cabinet where a
0, CERTD 03010 / Key board is located.
BTS390 EPLOY TDLOF Infrastru GUI Value Range: 0~7
CERTD
A, EPLOY Actual Value Range: 0~7
BTS390 WRFD- NodeB
140210 PKI Default Value: 0
0 LTE
Support
CN BSC690 SET GBFD-1 O&M of Meaning: Number of the cabinet where the BTS board
0 BTSCE 11202 BTS is located.
RTDEP GUI Value Range: 0~62
LOY
Unit: None
Actual Value Range: 0~62
Default Value: None
CN BSC691 SET GBFD-1 O&M of Meaning: Number of the cabinet where the BTS board
0 BTSCE 11202 BTS is located.
LOY
Unit: None
Default Value: None

SingleRAN

nd
SRN BTS390 SET LOFD-0 Public Meaning: Indicates the number of the subrack where a
CERTD
BTS390 WRFD- NodeB
0 LTE
Support
SRN BSC690 SET GBFD-1 O&M of Meaning: Number of the subrack where the BTS
0 BTSCE 11202 BTS board is located.
LOY
Unit: None
Default Value: None
SRN BSC691 SET GBFD-1 O&M of Meaning: Number of the subrack where the BTS
0 BTSCE 11202 BTS board is located.
LOY
Unit: None
Default Value: None
SN BTS390 SET LOFD-0 Public Meaning: Indicates the number of the slot where a
CERTD
BTS390 WRFD- NodeB
0 LTE
Support
SN BSC691 SET GBFD-1 O&M of Meaning: Number of the slot where the BTS board is
0 BTSCE 11202 BTS located.
LOY
Unit: None
Default Value: None

SingleRAN

nd
SN BSC690 SET GBFD-1 O&M of Meaning: Number of the slot where the BTS board is
0 BTSCE 11202 BTS located.
LOY
Unit: None
Default Value: None
ISENA BTS390 SET LOFD-0 Public Meaning: Indicates whether a task of certificate
BLE 0, CERTC 03010 / Key validity checking is started.
BTS390 HKTSK TDLOF Infrastru GUI Value Range: DISABLE(Disable),
0 LST D-00301 cture(P ENABLE(Enable)
WCDM CERTC 0 KI)
A, Unit: None
HKTSK GBFD-1 BTS
BTS390 Actual Value Range: DISABLE, ENABLE
ng PKI Default Value: ENABLE(Enable)
WRFD-
140210 NodeB
PKI
Support
PERIO BTS390 SET LOFD-0 Public Meaning: Indicates the interval between certificate
D 0, CERTC 03010 / Key validity checking tasks.
BTS390 HKTSK TDLOF Infrastru GUI Value Range: 1~15
WCDM 0 KI) Unit: day
CERTC
A, HKTSK Actual Value Range: 1~15
BTS390 GBFD-1 BTS
13526 Supporti Default Value: 7
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
ALMR BTS390 SET LOFD-0 Public Meaning: Indicates the threshold for a certificate
NG 0, CERTC 03010 / Key expiration alarm. If the base station detects that the
BTS390 HKTSK TDLOF Infrastru interval between its current time and the expiration
0 LST D-00301 cture(P date of an activated device certificate is shorter than
WCDM CERTC 0 KI) the threshold, an Imminent Certificate Expiry alarm is
A, HKTSK reported.
BTS390 GBFD-1 BTS
13526 Supporti GUI Value Range: 7~180
0 LTE
ng PKI Unit: day
WRFD-
140210 NodeB Actual Value Range: 7~180
PKI Default Value: 30
Support

SingleRAN

nd
UPDAT BSC690 SET GBFD-1 BSC Meaning: Update policy for an expired certificate. If
EMET 0 CERTC 60211 Supporti PROXY or MANUAL is selected, the system will
HOD HKTSK ng PKI disable the automatic device certificate update
function. In this case, you need to manually update the
device certificate.
GUI Value Range: PROXY(Proxy), CMP(CMP),
MANUAL(Manual)
Unit: None
Actual Value Range: PROXY, CMP, MANUAL
Default Value: PROXY(Proxy)
UPDAT BSC691 SET GBFD-1 BSC Meaning: Update policy for an expired certificate. If
EMET 0 CERTC 60211 Supporti PROXY or MANUAL is selected, the system will
HOD HKTSK ng PKI disable the automatic device certificate update
function. In this case, you need to manually update the
device certificate.
GUI Value Range: PROXY(Proxy), CMP(CMP),
MANUAL(Manual)
Unit: None
UPDAT BTS390 SET LOFD-0 Public Meaning: Indicates the method for updating a
EMET 0, CERTC 03010 / Key certificate that has expired or is about to expire. There
HOD BTS390 HKTSK TDLOF Infrastru are three methods: PROXY, CMP and MANUAL. If
0 LST D-00301 cture(P the PROXY method is used, the BS uses the U2000 as
WCDM CERTC 0 KI) the proxy to update the certificate from the Certificate
A, HKTSK Authority (CA). If the CMP method is used, the BS
BTS390 GBFD-1 BTS directly updates the certificate from the CA. If the
0 LTE 13526 Supporti MANUAL method is used, the certificate needs to be
ng PKI updated manually instead of automatically.
WRFD-
140210 NodeB GUI Value Range: PROXY(Proxy), CMP(CMP),
PKI MANUAL(Manual)
Support Unit: None
Default Value: CMP(CMP)

SingleRAN

nd
UPDAT BSC690 SET GBFD-1 BTS Meaning: Certificate updating mode used when the
EMET 0 BTSCE 13526 Supporti certificate detecting task detects that a certificate has
HOD RTCH ng PKI expired or is about to expire. There are two modes:
KTSK PROXY and CMP. In the PROXY mode, the BTS
updates the certificate through the CA on the U2000.
In CMP mode, the BTS updates the certificate through
the CA configured by the user.
GUI Value Range: PROXY(Proxy), CMP(CMP)
Unit: None
Actual Value Range: PROXY, CMP
UPDAT BSC691 SET GBFD-1 BTS Meaning: Certificate updating mode used when the
EMET 0 BTSCE 13526 Supporti certificate detecting task detects that a certificate has
HOD RTCH ng PKI expired or is about to expire. There are two modes:
KTSK PROXY and CMP. In the PROXY mode, the BTS
updates the certificate through the CA on the U2000.
In CMP mode, the BTS updates the certificate through
the CA configured by the user.
GUI Value Range: PROXY(Proxy), CMP(CMP)
Unit: None
Actual Value Range: PROXY, CMP

SingleRAN

nd
APPCE BTS390 ADD LOFD-0 Public Meaning: Indicates the file name of a device
RT 0, CERT 03010 / Key certificate. The file name cannot include any of the
BTS390 MK TDLOF Infrastru following characters: backslashes (\), slashes (/),
0 DSP D-00301 cture(P colons (:), asterisks (*), question marks (?), double
WCDM CERT 0 KI) quotation marks ("), left angle brackets (<), right angle
A, MK brackets (>), and bars (|).
BTS390 GBFD-1 BTS
MOD 13526 Supporti GUI Value Range: 1~64 characters
0 LTE
CERT ng PKI Unit: None
MK WRFD-
140210 NodeB Actual Value Range: 1~64 characters
REQ PKI Default Value: None
DEVCE Support
RT
RMV
CERT
MK
UPD
DEVCE
RT
DSP
CMPSE
SSION
LST
CERT
MK
KEYSI BTS390 MOD LOFD-0 Public Meaning: Indicates the length of a key, which can be
ZE 0, CERTR 03010 / Key 1024 bits or 2048 bits.
BTS390 EQ TDLOF Infrastru GUI Value Range: KEYSIZE1024(KEYSIZE1024),
0 UPD D-00301 cture(P KEYSIZE2048(KEYSIZE2048)
WCDM DEVCE 0 KI)
A, Unit: None
RT GBFD-1 BTS
BTS390 Actual Value Range: KEYSIZE1024, KEYSIZE2048
0 LTE LST 13526 Supporti
CERTR ng PKI Default Value: KEYSIZE2048(KEYSIZE2048)
EQ WRFD-
140210 NodeB
PKI
Support

SingleRAN

nd
IP BTS390 ADD LOFD-0 Public Meaning: Indicates the IP address of the master FTP
0, CRLTS 03010 / Key server or master LDAP server.
BTS390 K TDLOF Infrastru GUI Value Range: Valid IP address
CRLTS
A, K Actual Value Range: Valid IP address
BTS390 GBFD-1 BTS
13526 Supporti Default Value: None
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
CRLGE BTS390 ADD LOFD-0 Public Meaning: Indicates the method using which the BS
TMET 0, CRLTS 03010 / Key periodically obtains a CRL.
HOD BTS390 K TDLOF Infrastru GUI Value Range: FTP(FTP), LDAP(LDAP)
CRLTS
A, K Actual Value Range: FTP, LDAP
BTS390 GBFD-1 BTS
13526 Supporti Default Value: FTP(FTP)
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
SEARC BTS390 ADD LOFD-0 Public Meaning: Indicates the name of a node found in an
HDN 0, CRLTS 03010 / Key LDAP server.
BTS390 K TDLOF Infrastru GUI Value Range: 0~255 characters
CRLTS
A, K Actual Value Range: 0~255 characters
BTS390 GBFD-1 BTS
13526 Supporti Default Value: NULL(empty string)
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support

SingleRAN

nd
PORT BTS390 ADD LOFD-0 Public Meaning: Indicates the port number of an LDAP
0, CRLTS 03010 / Key server.
BTS390 K TDLOF Infrastru GUI Value Range: 0~65535
CRLTS
A, K Actual Value Range: 0~65535
BTS390 GBFD-1 BTS
13526 Supporti Default Value: 389
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
ISCRL BTS390 ADD LOFD-0 Public Meaning: Indicates whether to update the CRL at the
TIME 0, CRLTS 03010 / Key next update time specified in the CRL that is obtained
BTS390 K TDLOF Infrastru during the latest update. If this parameter is set to
0 LST D-00301 cture(P ENABLE, the BS automatically updates the CRL
WCDM CRLTS 0 KI) when the next update time specified in the CRL
A, K arrives. If this parameter is set to DISABLE, the BS
BTS390 GBFD-1 BTS automatically updates the CRL based on the
0 LTE 13526 Supporti configured updating period.
ng PKI
WRFD- GUI Value Range: DISABLE(Disable),
140210 NodeB ENABLE(Enable)
PKI Unit: None
Support
Actual Value Range: DISABLE, ENABLE
Default Value: DISABLE(Disable)
PERIO BTS390 ADD LOFD-0 Public Meaning: Indicates the interval at which the BS
D 0, CRLTS 03010 / Key automatically obtains the CRL from the FTP server or
BTS390 K TDLOF Infrastru LDAP server.
0 LST D-00301 cture(P GUI Value Range: 8~240
WCDM CRLTS 0 KI)
A, Unit: h
K GBFD-1 BTS
BTS390 Actual Value Range: 8~240
ng PKI Default Value: 24
WRFD-
140210 NodeB
PKI
Support

SingleRAN

nd
CONN BTS390 ADD None None Meaning: Indicates whether to use the SSL to protect
MODE 0, CRLTS the security of the connection.
BTS390 K GUI Value Range: PLAINTEXT(Plaintext),
0 LST SSL(SSL)
WCDM CRLTS
A, Unit: None
K
BTS390 Actual Value Range: PLAINTEXT, SSL
0 LTE Default Value: PLAINTEXT(Plaintext)
CONN BSC690 ADD GBFD-1 BSC Meaning: Mode of connection to the CRL server.
MODE 0 CRLTS 60211 Supporti GUI Value Range: PLAINTEXT(Plaintext),
K ng PKI SSL(SSL)
Unit: None
Actual Value Range: PLAINTEXT, SSL
Default Value: PLAINTEXT(Plaintext)
CONN BSC691 ADD GBFD-1 BSC Meaning: Mode of connection to the CRL server.
MODE 0 CRLTS 60211 Supporti GUI Value Range: PLAINTEXT(Plaintext),
K ng PKI SSL(SSL)
Unit: None
Actual Value Range: PLAINTEXT, SSL
Default Value: PLAINTEXT(Plaintext)
AUTHP BTS390 ADD None None Meaning: Indicates whether to authenticate the
EER 0, CRLTS certificate of the peer end when SSL connection is
BTS390 K used.
0 LST GUI Value Range: DISABLE(Disable),
WCDM CRLTS ENABLE(Enable)
A, K
BTS390 Unit: None
0 LTE Actual Value Range: DISABLE, ENABLE
AUTHP BSC690 ADD GBFD-1 BSC Meaning: Whether to authenticate the identity of the
EER 0 CRLTS 60211 Supporti peer end.
K ng PKI GUI Value Range: DISABLE(Disable),
ENABLE(Enable)
Unit: None

SingleRAN

nd
AUTHP BSC691 ADD GBFD-1 BSC Meaning: Whether to authenticate the identity of the
EER 0 CRLTS 60211 Supporti peer end.
K ng PKI GUI Value Range: DISABLE(Disable),
ENABLE(Enable)
Unit: None
ENCRY BTS390 SET MRFD- Security Meaning: Indicates the transmission encryption mode
MODE 0, FTPSC 210305 Manage of the FTP client. If this parameter is set to Auto, the
BTS390 LT ment FTP client first attempts to transmit data in ciphertext.
0 LBFD-0 If the attempt fails, the FTP client automatically
LST 04003 Security
WCDM FTPSC switches the encryption mode to retransmit data in
A, Socket plaintext. Therefore, setting this parameter to Auto
LT Layer
BTS390 may pose security risks. However, if there are faults in
0 LTE transmission equipment, the FTP client does not
attempt to retransmit data in plaintext even if the FTP
server supports encrypted transmission. In this case,
the FTP connection setup fails.
GUI Value Range: Auto(Auto), Plaintext(Plaintext),
Encrypted(SSL Encrypted)
Unit: None
Actual Value Range: Auto, Plaintext, Encrypted
Default Value: Auto(Auto)
ENCRY BSC690 SET GBFD-1 O&M of Meaning:

MODE 0 FTPSC 11203 BSC Transport encryption mode supported when the NE
LT serves as the FTP client.
AUTO(Auto): indicates that the FTP server selects the
encryption mode.
PLAINTEXT(Plain Text): indicates that the plaintext
mode must be used.
ENCRYPTED(SSL Encrypted): indicates that the
encrypted mode must be used.
GUI Value Range: AUTO(Auto), PLAINTEXT(Plain
Text), ENCRYPTED(SSL Encrypted)
Unit: None
Actual Value Range: AUTO, PLAINTEXT,
ENCRYPTED
Default Value: AUTO(Auto)

SingleRAN

nd
ENCRY BSC691 SET GBFD-1 O&M of Meaning:

MODE 0 FTPSC 11203 BSC Transport encryption mode supported when the NE
LT serves as the FTP client.
AUTO(Auto): indicates that the FTP server selects the
encryption mode.
PLAINTEXT(Plain Text): indicates that the plaintext
mode must be used.
ENCRYPTED(SSL Encrypted): indicates that the
encrypted mode must be used.
GUI Value Range: AUTO(Auto), PLAINTEXT(Plain
Text), ENCRYPTED(SSL Encrypted)
Unit: None
Actual Value Range: AUTO, PLAINTEXT,
ENCRYPTED
Default Value: AUTO(Auto)
SSLCE BSC690 SET GBFD-1 O&M of Meaning: Whether the FTP client supports
RTAUT 0 FTPSC 11203 BSC authenticating the FTP server.
H LT GUI Value Range: NO(No), YES(Yes)
Unit: None
Actual Value Range: YES, NO
Default Value: NO(No)
SSLCE BTS390 SET MRFD- Security Meaning: Indicates whether the certificate
RTAUT 0, FTPSC 210305 Manage authentication mode is supported when encrypted data
H BTS390 LT ment is being transmitted.
0 LBFD-0
LST 04003 Security GUI Value Range: No(No), Yes(Yes)
WCDM FTPSC
A, Socket Unit: None
LT Layer
BTS390 Actual Value Range: No, Yes
0 LTE Default Value: No(No)
SSLCE BSC691 SET GBFD-1 O&M of Meaning: Whether the FTP client supports
RTAUT 0 FTPSC 11203 BSC authenticating the FTP server.
H LT GUI Value Range: NO(No), YES(Yes)
Unit: None
Actual Value Range: YES, NO
Default Value: NO(No)

SingleRAN

nd
SLVUR BSC690 ADD GBFD-1 BSC Meaning: URL of the secondary CA.
L 0 CA 60208 Supporti GUI Value Range: 1~128 characters
MOD ng PKI
Redunda Unit: None
CA
ncy Actual Value Range: 1~128 characters
Default Value: None
SLVUR BTS390 ADD None None Meaning: Indicates the slave URL of the CA. The
L 0, CA URL can be either an HTTP or HTTPS URL. The IP
BTS390 MOD address in the URL must be a valid IP address. The
0 CA default port number is 80 for HTTP or 443 for
WCDM HTTPS. If the certificate fails to be obtained using the
A, LST CA URL, the slave CA URL can be used to obtain the
BTS390 CA certificate only when this parameter is set.
0 LTE GUI Value Range: 0~128 characters
Unit: None
Actual Value Range: 0~128 characters
Default Value: NULL(empty string)
SLVUR BSC691 ADD GBFD-1 BSC Meaning: URL of the secondary CA.
L 0 CA 60208 Supporti GUI Value Range: 1~128 characters
MOD ng PKI
Redunda Unit: None
CA
ncy Actual Value Range: 1~128 characters
Default Value: None
SLVINI BTS390 ADD None None Meaning: Indicates the slave URL of the CA that is
TREQU 0, CA used during site deployment. The URL can be either
RL BTS390 MOD an HTTP or HTTPS URL. In the URL, the IP address
0 CA must be a valid IP address, and the default port
WCDM number is 80 for HTTP or 443 for HTTPS. If the
A, LST certificate fails to be obtained using the CA URL
BTS390 CA during site deployment, the slave CA URL during site
0 LTE deployment can be used to obtain the certificate only
when this parameter is set.
GUI Value Range: 0~128 characters
Unit: None

SingleRAN

nd
SLVIP BTS390 ADD None None Meaning: Indicates the IP address of the slave FTP
0, CRLTS server or slave LDAP server. If the certificate fails to
BTS390 K be obtained using the IP address of the master CRL
0 LST server, the IP address of the slave CRL server is used
WCDM CRLTS only when this parameter is not set to 0.0.0.0. If the IP
A, K address of the slave CRL server is used, the slave port
BTS390 number, slave user name, and slave password need be
0 LTE configured.
GUI Value Range: Valid IP address
Unit: None
Actual Value Range: Valid IP address
SLVIP BSC690 ADD GBFD-1 BSC Meaning: IP address of the secondary CRL server.
0 CRLTS 60208 Supporti GUI Value Range: Valid IP Address
K ng PKI
Redunda Unit: None
ncy Actual Value Range: Valid IP Address
SLVIP BSC691 ADD GBFD-1 BSC Meaning: IP address of the secondary CRL server.
0 CRLTS 60208 Supporti GUI Value Range: Valid IP Address
K ng PKI
Redunda Unit: None
ncy Actual Value Range: Valid IP Address
SLVPO BTS390 ADD None None Meaning: Indicates the port number of a slave LDAP
RT 0, CRLTS server.
BTS390 K GUI Value Range: 0~65535
0 LST
WCDM Unit: None
CRLTS
BTS390 Default Value: 389
0 LTE

SingleRAN

nd
SLVPO BSC690 ADD GBFD-1 BSC Meaning: Port number of the standby CRL server.
RT 0 CRLTS 60208 Supporti This parameter does not need to be specified when
K ng PKI CRLGETMETHOD is set to FTP. The system uses the
Redunda port which is configured by command "ADD
ncy FTPSCLTDPORT" as the default port number. This
parameter must be specified when
CRLGETMETHOD is set to LDAP. The default value
is 389.
GUI Value Range: 0~65535
Unit: None
Default Value: None
SLVPO BSC691 ADD GBFD-1 BSC Meaning: Port number of the standby CRL server.
RT 0 CRLTS 60208 Supporti This parameter does not need to be specified when
K ng PKI CRLGETMETHOD is set to FTP. The system uses the
Redunda port which is configured by command "ADD
ncy FTPSCLTDPORT" as the default port number. This
parameter must be specified when
CRLGETMETHOD is set to LDAP. The default value
is 389.
Unit: None
Default Value: None
SLVUS BTS390 ADD None None Meaning: Indicates the user name for logging in to the
R 0, CRLTS slave FTP server or slave LDAP server.
BTS390 K GUI Value Range: 0~255 characters
0 LST
WCDM Unit: None
CRLTS
BTS390 Default Value: NULL(empty string)
0 LTE
SLVUS BSC690 ADD GBFD-1 BSC Meaning: User name for accessing the secondary CRL
R 0 CRLTS 60208 Supporti server.
K ng PKI GUI Value Range: 0~128 characters
Redunda
ncy Unit: None
Default Value: None

SingleRAN

nd
SLVUS BSC691 ADD GBFD-1 BSC Meaning: User name for accessing the secondary CRL
R 0 CRLTS 60208 Supporti server.
Redunda
ncy Unit: None
Default Value: None
SLVPW BTS390 ADD None None Meaning: Indicates the password for logging in to the
D 0, CRLTS slave FTP server or slave LDAP server.
BTS390 K GUI Value Range: 0~32 characters
0
WCDM Unit: None
A, Actual Value Range: 0~32 characters
BTS390 Default Value: NULL(empty string)
0 LTE
SLVPW BSC690 ADD GBFD-1 BSC Meaning: Password for accessing the secondary CRL
D 0 CRLTS 60208 Supporti server.
Redunda
ncy Unit: None
Default Value: None
SLVPW BSC691 ADD GBFD-1 BSC Meaning: Password for accessing the secondary CRL
D 0 CRLTS 60208 Supporti server.
Redunda
ncy Unit: None
Default Value: None
SIGNA BTS390 MOD LOFD-0 Public Meaning: Indicates the signature algorithm for a
LG 0, CERTR 03010 / Key certificate request file. The signature algorithm can be
BTS390 EQ TDLOF Infrastru Secure Hash Algorithm 1 (SHA1), Message-Digest
0 LST D-00301 cture(P Algorithm 5 (MD5) or Secure Hash Algorithm 256
WCDM CERTF 0 KI) (SHA256).
A, ILE GUI Value Range: SHA1(SHA1), MD5(MD5),
BTS390 GBFD-1 BTS
LST 13526 Supporti SHA256(SHA256)
0 LTE
CERTR ng PKI Unit: None
EQ WRFD-
140210 NodeB Actual Value Range: SHA1, MD5, SHA256
PKI Default Value: SHA256(SHA256)
Support

SingleRAN

nd
SIGNA BSC690 MOD GBFD-1 BTS Meaning: Signature algorithm of the certificate
LG 0 BTSCE 13526 Supporti request file. Currently, the SHA1, MD5 and SHA256
RTREQ ng PKI algorithms are supported. The MD5 and SHA1
algorithms have security risks. If the Certificate
Authority (CA) supports the SHA256 algorithm, it is
recommended that SHA256 be used as the signature
algorithm of the certificate.
GUI Value Range: SHA1(SHA1), MD5(MD5),
SHA256(SHA256)
Unit: None
Actual Value Range: SHA1, MD5, SHA256
Default Value: SHA256(SHA256)
SIGNA BSC691 MOD GBFD-1 BTS Meaning: Signature algorithm of the certificate
LG 0 BTSCE 13526 Supporti request file. Currently, the SHA1, MD5 and SHA256
RTREQ ng PKI algorithms are supported. The MD5 and SHA1
algorithms have security risks. If the Certificate
Authority (CA) supports the SHA256 algorithm, it is
recommended that SHA256 be used as the signature
algorithm of the certificate.
GUI Value Range: SHA1(SHA1), MD5(MD5),
SHA256(SHA256)
Unit: None
SIGNA BSC690 MOD MRFD- Security Meaning: Signature algorithm used by the device
LG 0 CERTR 210305 Manage certificate.
EQ ment GUI Value Range: SHA1(SHA1), MD5(MD5),
SHA256(SHA256)
Unit: None
SIGNA BSC691 MOD MRFD- Security Meaning: Signature algorithm used by the device
LG 0 CERTR 210305 Manage certificate.
EQ ment GUI Value Range: SHA1(SHA1), MD5(MD5),
SHA256(SHA256)
Unit: None

SingleRAN

nd
CANA BTS390 ADD LOFD-0 Public Meaning: Indicates the name of the CA. The CA name
ME 0, CA 03010 / Key must not contain the following invalid characters:
BTS390 LST TDLOF Infrastru backslashes (\), slashes (/), colons (:), asterisks (*),
0 CA D-00301 cture(P question marks (?), double quotation marks ("), left
WCDM 0 KI) angle brackets (<), right angle brackets (>), bars (|)
A, MOD and underscores (_). Otherwise, an error occurs when
BTS390 CA GBFD-1 BTS you run the REQ DEVCERT command to apply for a
0 LTE REQ 13526 Supporti device certificate.
DEVCE ng PKI
WRFD- GUI Value Range: 1~127 characters
RT 140210 NodeB Unit: None
RMV PKI
CA Support Actual Value Range: 1~127 characters
Default Value: None
CANA BSC691 ADD GBFD-1 BSC Meaning: Name of the CA.

ME 0 CA 60211 Supporti GUI Value Range: 0~127 characters
MOD ng PKI
Unit: None
CA
RMV
CA Default Value: None
CANA BSC690 ADD GBFD-1 BSC Meaning: Name of the CA.

ME 0 CA 60211 Supporti GUI Value Range: 0~127 characters
MOD ng PKI
Unit: None
CA
RMV
CA Default Value: None
URL BTS390 ADD LOFD-0 Public Meaning: Indicates the URL of the CA. The URL can
0, CA 03010 / Key be either an HTTP or HTTPS URL. The IP address in
BTS390 MOD TDLOF Infrastru the URL must be a valid IP address. The default port
0 CA D-00301 cture(P number is 80 for HTTP or 443 for HTTPS.
WCDM 0 KI) GUI Value Range: 1~128 characters
A, LST
BTS390 CA GBFD-1 BTS Unit: None
0 LTE 13526 Supporti Actual Value Range: 1~128 characters
ng PKI
WRFD- Default Value: None
140210 NodeB
PKI
Support

SingleRAN

nd
URL BSC690 ADD GBFD-1 BSC Meaning: URL of the CA. The URL can be either an
0 CA 60211 Supporti HTTP or HTTPS URL. The IP address in the URL
MOD ng PKI must be a valid IPv4 address. The default port number
CA is 80 for an HTTP URL and 443 for an HTTPS URL.
Unit: None
Default Value: None
URL BSC691 ADD GBFD-1 BSC Meaning: URL of the CA. The URL can be either an
0 CA 60211 Supporti HTTP or HTTPS URL. The IP address in the URL
MOD ng PKI must be a valid IPv4 address. The default port number
CA is 80 for an HTTP URL and 443 for an HTTPS URL.
Unit: None
Default Value: None
INITRE BTS390 ADD LOFD-0 Public Meaning: Indicates the URL of the CA that is used
QURL 0, CA 03010 / Key during site deployment. The URL can be either an
BTS390 MOD TDLOF Infrastru HTTP or HTTPS URL. In the URL, the IP address
0 CA D-00301 cture(P must be a valid IP address, and the default port
WCDM 0 KI) number is 80 for HTTP or 443 for HTTPS. This
A, LST parameter is mandatory when the CA uses different
BTS390 CA GBFD-1 BTS URLs during site deployment or certificate update.
ng PKI GUI Value Range: 1~128 characters
WRFD- Unit: None
140210 NodeB
PKI Actual Value Range: 1~128 characters
Support Default Value: None
SIGNA BTS390 ADD LOFD-0 Public Meaning: Indicates the signature algorithm for
LG 0, CA 03010 / Key message of CMP. The signature algorithm can be
BTS390 MOD TDLOF Infrastru Secure Hash Algorithm 1 (SHA1) or Secure Hash
0 CA D-00301 cture(P Algorithm 256 (SHA256).
WCDM 0 KI) GUI Value Range: SHA1(SHA1), SHA256(SHA256)
A, LST
BTS390 CA GBFD-1 BTS Unit: None
0 LTE 13526 Supporti Actual Value Range: SHA1, SHA256
ng PKI
WRFD- Default Value: SHA256(SHA256)
140210 NodeB
PKI
Support

SingleRAN

nd
SIGNA BSC691 ADD GBFD-1 BSC Meaning: Signature algorithm used by the Certificate
LG 0 CA 60211 Supporti Management Protocol (CMP) to request for a
MOD ng PKI certificate. The algorithm includes SHA1 and
CA SHA256.
GUI Value Range: SHA1(SHA1), SHA256(SHA256)
Unit: None
Actual Value Range: SHA1, SHA256
SIGNA BSC690 ADD GBFD-1 BSC Meaning: Signature algorithm used by the Certificate
LG 0 CA 60211 Supporti Management Protocol (CMP) to request for a
MOD ng PKI certificate. The algorithm includes SHA1 and
CA SHA256.
Unit: None
KEYSI BSC691 MOD MRFD- Security Meaning: Size of the key used by the device
ZE 0 CERTR 210305 Manage certificate file.When this parameter is set to
EQ ment "KEYSIZE1024", security risks exist. It is
recommended that this parameter be set to
"KEYSIZE2048".
GUI Value Range: KEYSIZE1024(1024 Bits),
KEYSIZE2048(2048 Bits)
Unit: None
Actual Value Range: KEYSIZE1024, KEYSIZE2048
Default Value: KEYSIZE2048(2048 Bits)
KEYSI BSC690 MOD MRFD- Security Meaning: Size of the key used by the device
ZE 0 CERTR 210305 Manage certificate file.When this parameter is set to
EQ ment "KEYSIZE1024", security risks exist. It is
"KEYSIZE2048".
GUI Value Range: KEYSIZE1024(1024 Bits),
KEYSIZE2048(2048 Bits)
Unit: None
Default Value: KEYSIZE2048(2048 Bits)

SingleRAN

nd
KEYUS BTS390 MOD LOFD-0 Public Meaning: Indicates the usage for a key, including
AGE 0, CERTR 03010 / Key KEY_AGREEMENT (key negotiation),
BTS390 EQ TDLOF Infrastru DATA_ENCIPHERMENT (data encryption),
0 LST D-00301 cture(P KEY_ENCIPHERMENT (key encryption), and
WCDM CERTF 0 KI) DIGITAL_SIGNATURE (digital signature). This
A, ILE parameter can be set to one or multiple values.
BTS390 GBFD-1 BTS
LST 13526 Supporti GUI Value Range:
0 LTE DATA_ENCIPHERMENT(DATA_ENCIPHERMEN
CERTR ng PKI
EQ WRFD- T),
140210 NodeB DIGITAL_SIGNATURE(DIGITAL_SIGNATURE),
PKI KEY_AGREEMENT(KEY_AGREEMENT),
Support KEY_ENCIPHERMENT(KEY_ENCIPHERMENT)
Unit: None
Actual Value Range: DATA_ENCIPHERMENT,
DIGITAL_SIGNATURE, KEY_AGREEMENT,
KEY_ENCIPHERMENT
Default Value: DATA_ENCIPHERMENT:ON,
DIGITAL_SIGNATURE:ON,
KEY_AGREEMENT:ON,
KEY_ENCIPHERMENT:ON
KEYUS BSC691 MOD MRFD- Security Meaning: Key usage. The options are key agreement,
AGE 0 CERTR 210305 Manage data encryption, key encryption, and digital signature.
EQ ment Each time, more than one option can be selected. At
least one usage must be selected for this parameter.
GUI Value Range: DATA_ENCIPHERMENT(Data
Encipherment), DIGITAL_SIGNATURE(Digital
Signature), KEY_AGREEMENT(Key Agreement),
KEY_ENCIPHERMENT(Key Encipherment)
Unit: None
KEY_ENCIPHERMENT
Default Value: None

SingleRAN

nd
KEYUS BSC690 MOD MRFD- Security Meaning: Key usage. The options are key agreement,
AGE 0 CERTR 210305 Manage data encryption, key encryption, and digital signature.
EQ ment Each time, more than one option can be selected. At
least one usage must be selected for this parameter.
Encipherment), DIGITAL_SIGNATURE(Digital
Signature), KEY_AGREEMENT(Key Agreement),
KEY_ENCIPHERMENT(Key Encipherment)
Unit: None
KEY_ENCIPHERMENT
Default Value: None
LOCAL BTS390 MOD LOFD-0 Public Meaning: Indicates the local name of a BS. This
NAME 0, CERTR 03010 / Key parameter is used to generate the DNS name of the
BTS390 EQ TDLOF Infrastru subject alternative name of a certificate, to verify the
0 LST D-00301 cture(P peer's identification in IKE negotiation. If this
WCDM CERTF 0 KI) parameter is not configured, the BS automatically uses
A, ILE the common name and its additional information to
BTS390 GBFD-1 BTS generate the DNS name.
0 LTE LST 13526 Supporti
CERTR ng PKI GUI Value Range: 0~128 characters
EQ WRFD- Unit: None
140210 NodeB
PKI Actual Value Range: 0~128 characters
Support Default Value: NULL(empty string)
LOCAL BSC691 MOD MRFD- Security Meaning: Local name of the device. If this parameter
NAME 0 CERTR 210305 Manage is not configured, set this parameter to the same value
EQ ment as "COMMNAME". If this parameter is configured,
use the actually configured value. The parameter
value can contain only letters, digits, spaces, and the
following characters: ()+-./:?. The original parameter
settings remain unchanged if the parameter is left
unspecified. The original parameter settings are
cleared if a space is entered.
Unit: None
Default Value: None

SingleRAN

nd
LOCAL BSC690 MOD MRFD- Security Meaning: Local name of the device. If this parameter
NAME 0 CERTR 210305 Manage is not configured, set this parameter to the same value
EQ ment as "COMMNAME". If this parameter is configured,
use the actually configured value. The parameter
value can contain only letters, digits, spaces, and the
following characters: ()+-./:?. The original parameter
settings remain unchanged if the parameter is left
unspecified. The original parameter settings are
cleared if a space is entered.
Unit: None
Default Value: None
CERTN BTS390 ADD LOFD-0 Public Meaning: Indicates the file name of the trusted
AME 0, TRUST 03010 / Key certificate. The file name cannot include any of the
BTS390 CERT TDLOF Infrastru following characters: backslashes (\), slashes (/),
0 DSP D-00301 cture(P colons (:), asterisks (*), question marks (?), double
WCDM TRUST 0 KI) quotation marks ("), left angle brackets (<), right angle
A, CERT brackets (>), and bars (|).
BTS390 GBFD-1 BTS
RMV 13526 Supporti GUI Value Range: 1~64 characters
0 LTE
TRUST ng PKI Unit: None
CERT WRFD-
LST PKI Default Value: None
TRUST Support
CERT
IP BSC691 ADD MRFD- Security Meaning: IP address of the server where the CRL file
0 CRLTS 210305 Manage is saved.
K ment GUI Value Range: Valid IP Address
Unit: None
Default Value: None
IP BSC690 ADD MRFD- Security Meaning: IP address of the server where the CRL file
0 CRLTS 210305 Manage is saved.
K ment GUI Value Range: Valid IP Address
Unit: None
Default Value: None

SingleRAN

nd
USR BTS390 ADD LOFD-0 Public Meaning: Indicates the user name used to log in to an
0, CRLTS 03010 / Key FTP server or LDAP server.
CRLTS
BTS390 GBFD-1 BTS
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
PWD BTS390 ADD LOFD-0 Public Meaning: Indicates the password used to log in to an
0, CRLTS 03010 / Key FTP server or LDAP server.
0 D-00301 cture(P
A, Actual Value Range: 0~32 characters
BTS390 GBFD-1 BTS
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
PWD BSC690 ADD MRFD- Security Meaning: Password for logging in to the server.
0 CRLTS 210305 Manage GUI Value Range: 0~32 characters
K ment
Unit: None
Default Value: None
PWD BSC691 ADD MRFD- Security Meaning: Password for logging in to the server.
0 CRLTS 210305 Manage GUI Value Range: 0~32 characters
K ment
Unit: None
Default Value: None

SingleRAN

nd
FILEN BTS390 ADD LOFD-0 Public Meaning: Indicates the file name of a CRL. File name
AME 0, CRLTS 03010 / Key with path is supported when the access method is set
BTS390 K TDLOF Infrastru to FTP.
0 LST D-00301 cture(P GUI Value Range: 1~128 characters
WCDM CRLTS 0 KI)
A, Unit: None
K GBFD-1 BTS
BTS390 Actual Value Range: 1~128 characters
ng PKI Default Value: None
WRFD-
140210 NodeB
PKI
Support
FILEN BSC691 ADD MRFD- Security Meaning: Name of the CRL file on the server. The file
AME 0 CRLTS 210305 Manage name can contain the save path of this file on the
K ment server. You can use a slash (/) or a backslash (\) as a
separator for the save path. When the Access Method
is set to LDAP, only the file name should be specified.
Unit: None
Default Value: None
FILEN BSC690 ADD MRFD- Security Meaning: Name of the CRL file on the server. The file
AME 0 CRLTS 210305 Manage name can contain the save path of this file on the
K ment server. You can use a slash (/) or a backslash (\) as a
separator for the save path. When the Access Method
is set to LDAP, only the file name should be specified.
Unit: None
Default Value: None
CRLGE BSC690 ADD GBFD-1 BSC Meaning: Method for obtaining the CRL file.
TMET 0 CRLTS 60211 Supporti GUI Value Range: FTP(FTP), LDAP(LDAP)
HOD K ng PKI
Unit: None
Actual Value Range: FTP, LDAP
Default Value: FTP(FTP)
CRLGE BSC691 ADD GBFD-1 BSC Meaning: Method for obtaining the CRL file.
TMET 0 CRLTS 60211 Supporti GUI Value Range: FTP(FTP), LDAP(LDAP)
HOD K ng PKI
Unit: None

SingleRAN

nd
SEARC BSC691 ADD GBFD-1 BSC Meaning: Distinct name of CRL files saved on the
HDN 0 CRLTS 60211 Supporti LDAP server.
Unit: None
Default Value: None
SEARC BSC690 ADD GBFD-1 BSC Meaning: Distinct name of CRL files saved on the
HDN 0 CRLTS 60211 Supporti LDAP server.
Unit: None
Default Value: None
PORT BSC691 ADD MRFD- Security Meaning: Number of the port used by the protocol.
0 CRLTS 210305 Manage This parameter does not need to be specified when
K ment "CRLGETMETHOD" is set to FTP. The system uses
the port which is configured by command "ADD
FTPSCLTDPORT" as the default port number. When
"CRLGETMETHOD" is set to LDAP, ensure that the
LDAP service on the port supports LDAP V3.
Unit: None
Default Value: None
PORT BSC690 ADD MRFD- Security Meaning: Number of the port used by the protocol.
0 CRLTS 210305 Manage This parameter does not need to be specified when
K ment "CRLGETMETHOD" is set to FTP. The system uses
the port which is configured by command "ADD
FTPSCLTDPORT" as the default port number. When
"CRLGETMETHOD" is set to LDAP, ensure that the
LDAP service on the port supports LDAP V3.
Unit: None
Default Value: None

SingleRAN

nd
COMM BTS390 MOD LOFD-0 Public Meaning: Indicates the common name of the
NAME 0, CERTR 03010 / Key certificate request file, which can be the electronic
BTS390 EQ TDLOF Infrastru serial number (ESN), media access control (MAC)
0 LST D-00301 cture(P address, or IP address of a board.
WCDM CERTR 0 KI) GUI Value Range: ESN(ESN), MAC(MAC), IP(IP)
A, EQ
BTS390 GBFD-1 BTS Unit: None
0 LTE 13526 Supporti Actual Value Range: ESN, MAC, IP
ng PKI
WRFD- Default Value: ESN(ESN)
140210 NodeB
PKI
Support
USERA BTS390 MOD LOFD-0 Public Meaning: Indicates the additional information about a
DDINF 0, CERTR 03010 / Key certificate common name. The information will be
O BTS390 EQ TDLOF Infrastru added behind the value of the COMMNAME
0 LST D-00301 cture(P parameter to compose a complete common name for a
WCDM CERTR 0 KI) certificate request file. The default value
A, EQ is .huawei.com. A space is not supported before the
BTS390 GBFD-1 BTS value of this parameter, that is, a space is not
0 LTE 13526 Supporti supported before the character string. However, to
ng PKI meet requirements of consistency checks performed
WRFD-
140210 NodeB by some CA servers to the certificate common name
PKI in a certificate request packet and that in a Huawei
Support device certificate, the certificate common name in a
certificate request packet is displayed as "Board
ESN"+space+"Common Name Additional Info" only
when the certificate common name in a Huawei
device certificate is "Board ESN"+space+"Common
Name Additional Info". For example, when the value
of this parameter is "eNodeB" and the certificate
common name in a Huawei device certificate is "ESN
eNodeB", a space is automatically added before
"eNodeB", that is, the certificate common name in a
certificate request packet is displayed as "ESN
eNodeB".
Unit: None

SingleRAN

nd
COUN BTS390 MOD LOFD-0 Public Meaning: Indicates the country where a BS is located.
TRY 0, CERTR 03010 / Key GUI Value Range: 0~0,2~2 characters
BTS390 EQ TDLOF Infrastru
0 D-00301 cture(P Unit: None
LST
WCDM CERTR 0 KI) Actual Value Range: 0~0,2~2 characters
A, EQ Default Value: NULL(empty string)
BTS390 GBFD-1 BTS
ng PKI
WRFD-
140210 NodeB
PKI
Support
ORG BTS390 MOD LOFD-0 Public Meaning: Indicates the organization that owns a BS.
0, CERTR 03010 / Key GUI Value Range: 0~64 characters
LST
WCDM CERTR 0 KI) Actual Value Range: 0~64 characters
BTS390 GBFD-1 BTS
ng PKI
WRFD-
140210 NodeB
PKI
Support
ORGU BTS390 MOD LOFD-0 Public Meaning: Indicates the organization unit that owns a
NIT 0, CERTR 03010 / Key BS.
BTS390 EQ TDLOF Infrastru GUI Value Range: 0~64 characters
CERTR
A, EQ Actual Value Range: 0~64 characters
BTS390 GBFD-1 BTS
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support

SingleRAN

nd
STATE BTS390 MOD LOFD-0 Public Meaning: Indicates the state or province where a BS is
PROVI 0, CERTR 03010 / Key located.
NCENA BTS390 EQ TDLOF Infrastru GUI Value Range: 0~128 characters
ME 0 LST D-00301 cture(P
CERTR
A, EQ Actual Value Range: 0~128 characters
BTS390 GBFD-1 BTS
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
LOCAL BTS390 MOD LOFD-0 Public Meaning: Indicates the location of a BS.
ITY 0, CERTR 03010 / Key GUI Value Range: 0~128 characters
LST
WCDM CERTR 0 KI) Actual Value Range: 0~128 characters
BTS390 GBFD-1 BTS
ng PKI
WRFD-
140210 NodeB
PKI
Support
IDTYP BTS390 ADD LOFD-0 IPsec Meaning: Indicates the type of the identification
E 0, IKEPE 03009 / payload that the local end transmits. The
BTS390 ER TDLOF BTS authentication can be performed based on IP or fully
0 D-00300 Integrate qualified domain name (FQDN).
MOD d Ipsec
WCDM IKEPE 9 GUI Value Range: IP(IP Identify), FQDN(Name
A, ER NodeB Identify)
BTS390 GBFD-1
DSP 13524 Integrate Unit: None
0 LTE d IPSec
IKEPE Actual Value Range: IP, FQDN
ER WRFD-
140209 Default Value: None
LST
IKEPE
ER

SingleRAN

nd
MODE BTS390 ADD LOFD-0 Public Meaning: Indicates the policy for configuring the
0, CA 03010 / Key following parameters: Certificate Update Source IP,
BTS390 MOD TDLOF Infrastru CA URL During Site Deployment, and Source IP for
0 CA D-00301 cture(P Applying for a Certificate During Site Deployment.
WCDM 0 KI) When the parameter is set to DEFAULT_MODE, the
A, LST UPDSIP, INITREQURL, INITREQSIP and
BTS390 CA GBFD-1 BTS SLVINITREQURL parameters do not need to be
0 LTE 13526 Supporti configured. When a certificate is initially obtained
ng PKI during site deployment, is manually applied for, or is
WRFD-
140210 NodeB automatically or manually updated, the base station
PKI uses the effective IP address of the local OM channel
Support as the source address, and the URL as the destination
address. When this parameter is set to
CFG_INIT_UPD_ADDR, the base station uses
INITREQSIP and INITREQURL as the source and
destination addresses for initially obtaining a
certificate during site deployment and UPDSIP and
URL as the source and destination addresses for
automatically and manually updating a certificate and
for manually applying for a certificate. When the
parameter is set to CFG_UPD_SIP, the
INITREQURL, INITREQSIP and SLVINITREQURL
parameters do not need to be configured. When a
certificate is initially obtained during site deployment,
is manually applied for, or is automatically or
manually updated, the base station uses the UPDSIP
and URL address as the source and destination
addresses, respectively.
GUI Value Range:
DEFAULT_MODE(DEFAULT_MODE),
CFG_UPD_SIP(CFG_UPD_SIP),
CFG_INIT_UPD_ADDR(CFG_INIT_UPD_ADDR)
Unit: None
Actual Value Range: DEFAULT_MODE,
CFG_UPD_SIP, CFG_INIT_UPD_ADDR
Default Value:
DEFAULT_MODE(DEFAULT_MODE)

SingleRAN

nd
UPDSI BTS390 ADD LOFD-0 Public Meaning: Indicates the source address for certificate
P 0, CA 03010 / Key management, such as automatic certificate update,
BTS390 MOD TDLOF Infrastru manual certificate update, and manual certificate
0 CA D-00301 cture(P application. If the source address for certificate
WCDM 0 KI) application in site deployment is not configured, the
A, LST address will be used as the source address for
BTS390 CA GBFD-1 BTS acquiring the certificate for the first time.
ng PKI GUI Value Range: Valid IP address
WRFD- Unit: None
140210 NodeB
PKI Actual Value Range: Valid IP address
Support Default Value: 0.0.0.0
INITRE BTS390 ADD LOFD-0 Public Meaning:

QSIP 0, CA 03010 / Key Indicates the source IP address for the BS to access
BTS390 MOD TDLOF Infrastru the CA and to initially obtain a certificate. This
0 CA D-00301 cture(P parameter is mandatory when the CA uses different
WCDM 0 KI) URLs in the following scenarios:
A, LST
BTS390 CA GBFD-1 BTS -The BS initially obtains a certificate during site
0 LTE 13526 Supporti deployment.
ng PKI
WRFD- -A certificate is updated.
140210 NodeB
PKI GUI Value Range: Valid IP address
Support Unit: None
Actual Value Range: Valid IP address
Default Value: None
APPTY BTS390 DSP LOFD-0 Public Meaning: Indicates the application type of activated
PE 0, APPCE 03010 / Key device certificate. There are two types: IKE and SSL.
BTS390 RT TDLOF Infrastru When APPTYPE is set to IKE and CERTSOURCE in
0 LST D-00301 cture(P IKEPEER MO is set to Appcert, the device certificate
WCDM APPCE 0 KI) being used during IKE negotiation is the certificate
A, RT configured in APPCERT MO. When APPTYPE is set
BTS390 GBFD-1 BTS to SSL, the device certificate being used is the
0 LTE MOD 13526 Supporti certificate used during SSL connection or 802.1x
APPCE ng PKI authentication.
RT WRFD-
140210 NodeB GUI Value Range: IKE(IKE), SSL(SSL)
TST PKI
APPCE Unit: None
Support
RT Actual Value Range: IKE, SSL
LST Default Value: None
CERTT
YPE

SingleRAN

nd
APPCE BTS390 MOD LOFD-0 Public Meaning: Indicates the file name of an activated
RT 0, APPCE 03010 / Key device certificate. The file name cannot include any of
BTS390 RT TDLOF Infrastru the following characters: backslashes (\), slashes (/),
0 TST D-00301 cture(P colons (:), asterisks (*), question marks (?), double
WCDM APPCE 0 KI) quotation marks ("), left angle brackets (<), right angle
A, RT brackets (>), and bars (|).
BTS390 GBFD-1 BTS
DSP 13526 Supporti GUI Value Range: 1~64 characters
0 LTE
APPCE ng PKI Unit: None
RT WRFD-
LST PKI Default Value: None
APPCE Support
RT
CERTN BTS390 ADD LOFD-0 Public Meaning: Indicates the file name of a CRL. The file
AME 0, CRL 03010 / Key name cannot include any of the following characters:
BTS390 DSP TDLOF Infrastru backslashes (\), slashes (/), colons (:), asterisks (*),
0 CRL D-00301 cture(P question marks (?), double quotation marks ("), left
WCDM 0 KI) angle brackets (<), right angle brackets (>), and bars
A, RMV (|).
BTS390 CRL GBFD-1 BTS
13526 Supporti GUI Value Range: 1~64 characters
0 LTE LST
CRL ng PKI Unit: None
WRFD-
PKI Default Value: None
Support
TSKID BTS390 ADD LOFD-0 Public Meaning: Indicates the ID of the task for periodically
0, CRLTS 03010 / Key obtaining the CRL.
BTS390 K TDLOF Infrastru GUI Value Range: 0~5
CRLTS
BTS390 GBFD-1 BTS
RMV 13526 Supporti Default Value: None
0 LTE
CRLTS ng PKI
K WRFD-
140210 NodeB
PKI
Support

SingleRAN

nd
SIP BTS390 ADD LOFD-0 Public Meaning: Indicates the source IP address for
0, CRLTS 03010 / Key downloading CRLs. When this parameter is set to
BTS390 K TDLOF Infrastru 0.0.0.0, the effective local OM IP address serves as
0 LST D-00301 cture(P the source IP address to access the CRL server for
WCDM CRLTS 0 KI) updating CRL files.
A, K GUI Value Range: Valid IP address
BTS390 GBFD-1 BTS
0 LTE 13526 Supporti Unit: None
ng PKI Actual Value Range: Valid IP address
WRFD-
140210 NodeB Default Value: 0.0.0.0
PKI
Support
BTSID BSC690 SET None None Meaning: Index of the BTS, uniquely identifying a
0 BTSCE BTS in a BSC.
LOY
Unit: None
Default Value: None
LOY
Unit: None
Default Value: None
IDTYP BSC690 ADD GBFD-1 O&M of Meaning: Index type. BYNAME: query by name;
E 0 BTSCA 11202 BTS BYID: query by index.
MOD GUI Value Range: BYNAME(By Name), BYID(By
BTSCA Index)
RMV Unit: None
BTSCA Actual Value Range: BYNAME, BYID
Default Value: None
E 0 BTSCA 11202 BTS BYID: query by index.
MOD GUI Value Range: BYNAME(By Name), BYID(By
BTSCA Index)
RMV Unit: None
BTSCA Actual Value Range: BYNAME, BYID
Default Value: None

SingleRAN

nd
BTSID BSC690 ADD None None Meaning: Index of the BTS, uniquely identifying a
0 BTSCA BTS in a BSC.
MOD GUI Value Range: 0~2047
BTSCA Unit: None
RMV Actual Value Range: 0~2047
BTSCA
Default Value: None
0 BTSCA BTS in a BSC.
MOD GUI Value Range: 0~7999
BTSCA Unit: None
RMV Actual Value Range: 0~7999
BTSCA
Default Value: None
CANA BSC690 ADD GBFD-1 BTS Meaning: Name of the CA.

ME 0 BTSCA 13526 Supporti GUI Value Range: 0~127 characters
MOD ng PKI
Unit: None
BTSCA
RMV
BTSCA Default Value: None
CANA BSC691 ADD GBFD-1 BTS Meaning: Name of the CA.

ME 0 BTSCA 13526 Supporti GUI Value Range: 0~127 characters
MOD ng PKI
Unit: None
BTSCA
RMV
BTSCA Default Value: None
URL BSC690 ADD GBFD-1 BTS Meaning:

0 BTSCA 13526 Supporti URL of the CA. The URL can be either an HTTP or
MOD ng PKI HTTPS URL. The IP address in the URL must be a
BTSCA valid IPv4 address. The default port number is 80 for
HTTP and 443 for HTTPS. This parameter cannot
contain the following invalid characters:
,;="'
In addition, this parameter cannot contain two or more
consecutive %, two or more consecutive spaces, and
three or more consecutive +.
Unit: None
Default Value: None

SingleRAN

nd
URL BSC691 ADD GBFD-1 BTS Meaning:

0 BTSCA 13526 Supporti URL of the CA. The URL can be either an HTTP or
MOD ng PKI HTTPS URL. The IP address in the URL must be a
BTSCA valid IPv4 address. The default port number is 80 for
HTTP and 443 for HTTPS. This parameter cannot
contain the following invalid characters:
,;="'
In addition, this parameter cannot contain two or more
consecutive %, two or more consecutive spaces, and
three or more consecutive +.
Unit: None
Default Value: None
SIGNA BSC690 ADD GBFD-1 BTS Meaning: Signature algorithm of the CMPV2
LG 0 BTSCA 13526 Supporti message. Currently, the SHA1 and SHA256
MOD ng PKI algorithms are supported. The SHA1 algorithm has
BTSCA security risks. If the Certificate Authority (CA)
supports the SHA256 algorithm, it is recommended
that SHA256 be used as the signature algorithm used
by the Certificate Management Protocol (CMP) to
request for a certificate.
Unit: None
SIGNA BSC691 ADD GBFD-1 BTS Meaning: Signature algorithm of the CMPV2
LG 0 BTSCA 13526 Supporti message. Currently, the SHA1 and SHA256
MOD ng PKI algorithms are supported. The SHA1 algorithm has
BTSCA security risks. If the Certificate Authority (CA)
supports the SHA256 algorithm, it is recommended
that SHA256 be used as the signature algorithm used
by the Certificate Management Protocol (CMP) to
request for a certificate.
Unit: None

SingleRAN

nd
BTSID BSC690 MOD None None Meaning: Index of the BTS, uniquely identifying a
RTREQ GUI Value Range: 0~2047
Unit: None
Default Value: None
RTREQ GUI Value Range: 0~7999
Unit: None
Default Value: None
COMM BSC690 MOD GBFD-1 BTS Meaning: Common name of the certificate request
NAME 0 BTSCE 13526 Supporti file. The common name can be the Electronic Serial
RTREQ ng PKI Number (ESN), MAC address, or IP address of the
board. When a certificate request file is generated, the
corresponding content of the specified type is used as
the common name of the file.
GUI Value Range: ESN(ESN), MAC(MAC), IP(IP)
Unit: None
Actual Value Range: ESN, MAC, IP
Default Value: ESN(ESN)
COMM BSC691 MOD GBFD-1 BTS Meaning: Common name of the certificate request
NAME 0 BTSCE 13526 Supporti file. The common name can be the Electronic Serial
RTREQ ng PKI Number (ESN), MAC address, or IP address of the
board. When a certificate request file is generated, the
corresponding content of the specified type is used as
the common name of the file.
GUI Value Range: ESN(ESN), MAC(MAC), IP(IP)
Unit: None
Actual Value Range: ESN, MAC, IP

SingleRAN

nd
USERA BSC690 MOD GBFD-1 BTS Meaning: Equipment description in the generic
DDINF 0 BTSCE 13526 Supporti certificate name. It is defined by operators. The
O RTREQ ng PKI default value of this parameter is .huawei.com before
BTS delivery.
Unit: None
Default Value: None
USERA BSC691 MOD GBFD-1 BTS Meaning: Equipment description in the generic
DDINF 0 BTSCE 13526 Supporti certificate name. It is defined by operators. The
O RTREQ ng PKI default value of this parameter is .huawei.com before
BTS delivery.
Unit: None
Default Value: None
COUN BSC690 MOD GBFD-1 BTS Meaning: Country where the equipment is located.
TRY 0 BTSCE 13526 Supporti GUI Value Range: 2 characters
RTREQ ng PKI
Unit: None
Actual Value Range: 2 characters
Default Value: None
COUN BSC691 MOD GBFD-1 BTS Meaning: Country where the equipment is located.
TRY 0 BTSCE 13526 Supporti GUI Value Range: 2 characters
RTREQ ng PKI
Unit: None
Actual Value Range: 2 characters
Default Value: None
ORG BSC690 MOD GBFD-1 BTS Meaning: Organization that owns the equipment.
0 BTSCE 13526 Supporti GUI Value Range: 0~64 characters
RTREQ ng PKI
Unit: None
Default Value: None
ORG BSC691 MOD GBFD-1 BTS Meaning: Organization that owns the equipment.
0 BTSCE 13526 Supporti GUI Value Range: 0~64 characters
RTREQ ng PKI
Unit: None
Default Value: None

SingleRAN

nd
ORGU BSC690 MOD GBFD-1 BTS Meaning: Organizational unit that owns the
NIT 0 BTSCE 13526 Supporti equipment.
RTREQ ng PKI GUI Value Range: 0~64 characters
Unit: None
Default Value: None
ORGU BSC691 MOD GBFD-1 BTS Meaning: Organizational unit that owns the
NIT 0 BTSCE 13526 Supporti equipment.
RTREQ ng PKI GUI Value Range: 0~64 characters
Unit: None
Default Value: None
STATE BSC690 MOD GBFD-1 BTS Meaning: State or province where the equipment is
PROVI 0 BTSCE 13526 Supporti located.
NCENA RTREQ ng PKI GUI Value Range: 0~128 characters
ME
Unit: None
Default Value: None
STATE BSC691 MOD GBFD-1 BTS Meaning: State or province where the equipment is
PROVI 0 BTSCE 13526 Supporti located.
NCENA RTREQ ng PKI GUI Value Range: 0~128 characters
ME
Unit: None
Default Value: None
LOCAL BSC690 MOD GBFD-1 BTS Meaning: Location of the equipment.

ITY 0 BTSCE 13526 Supporti GUI Value Range: 0~128 characters
RTREQ ng PKI
Unit: None
Default Value: None
LOCAL BSC691 MOD GBFD-1 BTS Meaning: Location of the equipment.

ITY 0 BTSCE 13526 Supporti GUI Value Range: 0~128 characters
RTREQ ng PKI
Unit: None
Default Value: None

SingleRAN

nd
KEYUS BSC690 MOD GBFD-1 BTS Meaning: Key usage. The options are key agreement,
AGE 0 BTSCE 13526 Supporti data encryption, key encryption, and digital signature.
RTREQ ng PKI Each time, more than one option can be selected.
Encryption), DIGITAL_SIGNATURE(Digital
Signature), KEY_AGREEMENT(Key Negotiation),
KEY_ENCIPHERMENT(Key Encryption)
Unit: None
KEY_ENCIPHERMENT
Default Value: DATA_ENCIPHERMENT:1,
DIGITAL_SIGNATURE:1, KEY_AGREEMENT:1,
KEY_ENCIPHERMENT:1
KEYUS BSC691 MOD GBFD-1 BTS Meaning: Key usage. The options are key agreement,
AGE 0 BTSCE 13526 Supporti data encryption, key encryption, and digital signature.
RTREQ ng PKI Each time, more than one option can be selected.
Encryption), DIGITAL_SIGNATURE(Digital
Signature), KEY_AGREEMENT(Key Negotiation),
KEY_ENCIPHERMENT(Key Encryption)
Unit: None
KEY_ENCIPHERMENT
Default Value: DATA_ENCIPHERMENT:1,
DIGITAL_SIGNATURE:1, KEY_AGREEMENT:1,
KEY_ENCIPHERMENT:1
KEYSI BSC690 MOD GBFD-1 BTS Meaning: Key size. The size can be 1,024 bits or
ZE 0 BTSCE 13526 Supporti 2,048 bits. When this parameter is set to
RTREQ ng PKI KEYSIZE1024, security risks exist. It is
KEYSIZE2048.
GUI Value Range: KEYSIZE1024(KEYSIZE1024),
KEYSIZE2048(KEYSIZE2048)
Unit: None
Default Value: KEYSIZE2048(KEYSIZE2048)

SingleRAN

nd
KEYSI BSC691 MOD GBFD-1 BTS Meaning: Key size. The size can be 1,024 bits or
ZE 0 BTSCE 13526 Supporti 2,048 bits. When this parameter is set to
RTREQ ng PKI KEYSIZE1024, security risks exist. It is
KEYSIZE2048.
GUI Value Range: KEYSIZE1024(KEYSIZE1024),
KEYSIZE2048(KEYSIZE2048)
Unit: None
Default Value: KEYSIZE2048(KEYSIZE2048)
LOCAL BSC690 MOD GBFD-1 BTS Meaning: Equipment's local name.

NAME 0 BTSCE 13526 Supporti GUI Value Range: 0~128 characters
RTREQ ng PKI
Unit: None
Default Value: None
LOCAL BSC691 MOD GBFD-1 BTS Meaning: Equipment's local name.

NAME 0 BTSCE 13526 Supporti GUI Value Range: 0~128 characters
RTREQ ng PKI
Unit: None
Default Value: None
LOCAL BSC690 ADD GBFD-1 BTS Meaning: Mode in which the local end authenticates
IDTYP 0 BTSIK 13524 Integrate the peer end. This parameter can be set to IP or
E EPEER MRFD- d IPsec FQDN.
MOD 211602 Multi- GUI Value Range: IP(IP Identify), FQDN(Name
BTSIK mode Identify)
EPEER BS Unit: None
Commo
n Actual Value Range: IP, FQDN
IPSec(G Default Value: None
SM)
LOCAL BSC691 ADD GBFD-1 BTS Meaning: Mode in which the local end authenticates
IDTYP 0 BTSIK 13524 Integrate the peer end. This parameter can be set to IP or
E EPEER MRFD- d IPsec FQDN.
MOD 211602 Multi- GUI Value Range: IP(IP Identify), FQDN(Name
BTSIK mode Identify)
EPEER BS Unit: None
Commo
n Actual Value Range: IP, FQDN
IPSec(G Default Value: None
SM)

SingleRAN

nd
E 0 BTSCE 11202 BTS BYID: query by index.
RTMK GUI Value Range: BYNAME(By Name), BYID(By
RMV Index)
BTSCE Unit: None
RTMK
Actual Value Range: BYNAME, BYID
Default Value: None
E 0 BTSCE 11202 BTS BYID: query by index.
RTMK GUI Value Range: BYNAME(By Name), BYID(By
RMV Index)
BTSCE Unit: None
RTMK
Default Value: None
RTMK GUI Value Range: 0~2047
RMV Unit: None
BTSCE
RTMK Actual Value Range: 0~2047
Default Value: None
RTMK GUI Value Range: 0~7999
RMV Unit: None
BTSCE
RTMK Actual Value Range: 0~7999
Default Value: None
APPCE BSC690 ADD GBFD-1 BTS Meaning: File name of the device certificate. The file
RT 0 BTSCE 13526 Supporti name cannot contain any of the following characters:
RTMK ng PKI \, /, :, *, ?, ", <, >, and |.
RMV GUI Value Range: 1~64 characters
BTSCE Unit: None
RTMK
Default Value: None

SingleRAN

nd
APPCE BSC691 ADD GBFD-1 BTS Meaning: File name of the device certificate. The file
RT 0 BTSCE 13526 Supporti name cannot contain any of the following characters:
RTMK ng PKI \, /, :, *, ?, ", <, >, and |.
RMV GUI Value Range: 1~64 characters
BTSCE Unit: None
RTMK
Default Value: None
0 BTSAP BTS in a BSC.
PCERT GUI Value Range: 0~2047
Unit: None
Default Value: None
0 BTSAP BTS in a BSC.
PCERT GUI Value Range: 0~7999
Unit: None
Default Value: None
APPTY BSC690 MOD GBFD-1 BTS Meaning: Application type of the device certificate in
PE 0 BTSAP 13526 Supporti use. IKE and SSL are supported.
PCERT ng PKI GUI Value Range: IKE(IKE), SSL(SSL)
Unit: None
Actual Value Range: IKE, SSL
Default Value: None
APPTY BSC691 MOD GBFD-1 BTS Meaning: Application type of the device certificate in
PE 0 BTSAP 13526 Supporti use. IKE and SSL are supported.
PCERT ng PKI GUI Value Range: IKE(IKE), SSL(SSL)
Unit: None
Actual Value Range: IKE, SSL
Default Value: None

SingleRAN

nd
APPCE BSC690 MOD GBFD-1 BTS Meaning: File name of the device certificate. The file
RT 0 BTSAP 13526 Supporti name cannot contain any of the following characters:
PCERT ng PKI \, /, :, *, ?, ", <, >, and |.
Unit: None
Default Value: None
APPCE BSC691 MOD GBFD-1 BTS Meaning: File name of the device certificate. The file
RT 0 BTSAP 13526 Supporti name cannot contain any of the following characters:
PCERT ng PKI \, /, :, *, ?, ", <, >, and |.
Unit: None
Default Value: None
E 0 BTSTR 11202 BTS BYID: query by index.
USTCE GUI Value Range: BYNAME(By Name), BYID(By
RT Index)
RMV Unit: None
BTSTR
USTCE Actual Value Range: BYNAME, BYID
RT Default Value: None
E 0 BTSTR 11202 BTS BYID: query by index.
USTCE GUI Value Range: BYNAME(By Name), BYID(By
RT Index)
RMV Unit: None
BTSTR
USTCE Actual Value Range: BYNAME, BYID
0 BTSTR BTS in a BSC.
USTCE GUI Value Range: 0~2047
RT
Unit: None
RMV
BTSTR Actual Value Range: 0~2047
USTCE Default Value: None
RT

SingleRAN

nd
0 BTSTR BTS in a BSC.
USTCE GUI Value Range: 0~7999
RT
Unit: None
RMV
BTSTR Actual Value Range: 0~7999
USTCE Default Value: None
RT
CERTN BSC690 ADD GBFD-1 BTS Meaning: File name of the trust certificate or
AME 0 BTSTR 13526 Supporti certificate chain. The file name cannot contain any of
USTCE ng PKI the following characters: \, /, :, *, ?, ", <, >, and |.
RT GUI Value Range: 1~64 characters
RMV Unit: None
BTSTR
USTCE Actual Value Range: 1~64 characters
CERTN BSC691 ADD GBFD-1 BTS Meaning: File name of the trust certificate or
AME 0 BTSTR 13526 Supporti certificate chain. The file name cannot contain any of
USTCE ng PKI the following characters: \, /, :, *, ?, ", <, >, and |.
RT GUI Value Range: 1~64 characters
RMV Unit: None
BTSTR
USTCE Actual Value Range: 1~64 characters
RTCH GUI Value Range: 0~2047
KTSK
Unit: None
Default Value: None
RTCH GUI Value Range: 0~7999
KTSK
Unit: None
Default Value: None

SingleRAN

nd
ISENA BSC690 SET GBFD-1 BTS Meaning: Whether the task of checking the certificate
BLE 0 BTSCE 13526 Supporti validity is started.
RTCH ng PKI GUI Value Range: DISABLE(Disable),
KTSK ENABLE(Enable)
Unit: None
Default Value: ENABLE(Enable)
ISENA BSC691 SET GBFD-1 BTS Meaning: Whether the task of checking the certificate
BLE 0 BTSCE 13526 Supporti validity is started.
RTCH ng PKI GUI Value Range: DISABLE(Disable),
KTSK ENABLE(Enable)
Unit: None
PERIO BSC690 SET GBFD-1 BTS Meaning: Period of checking the certificate validity.
D 0 BTSCE 13526 Supporti GUI Value Range: 1~15
RTCH ng PKI
KTSK Unit: day
Default Value: 7
PERIO BSC691 SET GBFD-1 BTS Meaning: Period of checking the certificate validity.
D 0 BTSCE 13526 Supporti GUI Value Range: 1~15
RTCH ng PKI
KTSK Unit: day
Default Value: 7
ALMR BSC690 SET GBFD-1 BTS Meaning: Alarm threshold of certificate expiry. When
NG 0 BTSCE 13526 Supporti the BTS detects that the time between the current time
RTCH ng PKI and the expiry time of the loaded certificate is less
KTSK than this threshold, a certificate expiry alarm is
reported.
Unit: day
Default Value: 30

SingleRAN

nd
ALMR BSC691 SET GBFD-1 BTS Meaning: Alarm threshold of certificate expiry. When
NG 0 BTSCE 13526 Supporti the BTS detects that the time between the current time
RTCH ng PKI and the expiry time of the loaded certificate is less
KTSK than this threshold, a certificate expiry alarm is
reported.
Unit: day
Default Value: 30
E 0 BTSCR 11202 BTS BYID: query by index.
L GUI Value Range: BYNAME(By Name), BYID(By
RMV Index)
BTSCR Unit: None
L
Default Value: None
E 0 BTSCR 11202 BTS BYID: query by index.
L GUI Value Range: BYNAME(By Name), BYID(By
RMV Index)
BTSCR Unit: None
L
Default Value: None
0 BTSCR BTS in a BSC.
L GUI Value Range: 0~2047
RMV Unit: None
BTSCR
L Actual Value Range: 0~2047
Default Value: None
L GUI Value Range: 0~7999
RMV Unit: None
BTSCR
L Actual Value Range: 0~7999
Default Value: None

SingleRAN

nd
CERTN BSC690 ADD GBFD-1 BTS Meaning: Indicates the file name of the CRL. The
AME 0 BTSCR 13526 Supporti name cannot contain any of the following characters:
L ng PKI backslashes (\), slashes (/), colons (:), asterisks (*),
RMV question marks (?), double quotation marks ("), left
BTSCR angle brackets (<), right angle brackets (>), and bars
L (|).
Unit: None
Default Value: None
CERTN BSC691 ADD GBFD-1 BTS Meaning: Indicates the file name of the CRL. The
AME 0 BTSCR 13526 Supporti name cannot contain any of the following characters:
L ng PKI backslashes (\), slashes (/), colons (:), asterisks (*),
RMV question marks (?), double quotation marks ("), left
BTSCR angle brackets (<), right angle brackets (>), and bars
L (|).
Unit: None
Default Value: None
LPOLI GUI Value Range: 0~2047
CY
Unit: None
Default Value: None
LPOLI GUI Value Range: 0~7999
CY
Unit: None
Default Value: None

SingleRAN

nd
CRLPO BSC690 SET GBFD-1 BTS Meaning: Policy type.

LICY 0 BTSCR 13526 Supporti GUI Value Range: NOVERIFY(No Verifying),
LPOLI ng PKI ALARM(Send an Alarm If Verifying CRL Failed),
CY DISCONNECT(Disconnect If Verifying CRL Failed)
Unit: None
DISCONNECT
CRLPO BSC691 SET GBFD-1 BTS Meaning: Policy type.

LICY 0 BTSCR 13526 Supporti GUI Value Range: NOVERIFY(No Verifying),
LPOLI ng PKI ALARM(Send an Alarm If Verifying CRL Failed),
CY DISCONNECT(Disconnect If Verifying CRL Failed)
Unit: None
DISCONNECT
LTSK GUI Value Range: 0~2047
RMV Unit: None
BTSCR
LTSK Actual Value Range: 0~2047
Default Value: None
LTSK GUI Value Range: 0~7999
RMV Unit: None
BTSCR
LTSK Actual Value Range: 0~7999
Default Value: None
IP BSC690 ADD GBFD-1 BTS Meaning: The IP address of an FTP server or LDAP
0 BTSCR 13526 Supporti server.
LTSK ng PKI GUI Value Range: Valid IP Address
Unit: None
Default Value: None

SingleRAN

nd
IP BSC691 ADD GBFD-1 BTS Meaning: The IP address of an FTP server or LDAP
0 BTSCR 13526 Supporti server.
LTSK ng PKI GUI Value Range: Valid IP Address
Unit: None
Default Value: None
USR BSC690 ADD GBFD-1 BTS Meaning: The user name used to log in to an FTP
0 BTSCR 13526 Supporti server or LDAP server.
LTSK ng PKI GUI Value Range: 0~255 characters
Unit: None
Default Value: None
USR BSC691 ADD GBFD-1 BTS Meaning: The user name used to log in to an FTP
Unit: None
Default Value: None
PWD BSC690 ADD GBFD-1 BTS Meaning: The password used to log in to an FTP
Unit: None
Default Value: None
PWD BSC691 ADD GBFD-1 BTS Meaning: The password used to log in to an FTP
Unit: None
Default Value: None
FILEN BSC690 ADD GBFD-1 BTS Meaning: Revoked device certificate. The file name
AME 0 BTSCR 13526 Supporti cannot contain any of the following characters: \, /, :,
LTSK ng PKI *, ?, ", <, >, and |.
Unit: None
Default Value: None

SingleRAN

nd
FILEN BSC691 ADD GBFD-1 BTS Meaning: Revoked device certificate. The file name
AME 0 BTSCR 13526 Supporti cannot contain any of the following characters: \, /, :,
LTSK ng PKI *, ?, ", <, >, and |.
Unit: None
Default Value: None
ISCRL BSC690 ADD GBFD-1 BTS Meaning: Whether to update the CRL at the next
TIME 0 BTSCR 13526 Supporti update time specified in the CRL that is obtained
LTSK ng PKI during the latest update. If this parameter is set to
ENABLE, the BTS automatically updates the CRL
when the next update time specified in the CRL
arrives. If this parameter is set to DISABLE, the BTS
automatically updates the CRL based on the
configured updating period.
GUI Value Range: DISABLE(Disable),
ENABLE(Enable)
Unit: None
ISCRL BSC691 ADD GBFD-1 BTS Meaning: Whether to update the CRL at the next
TIME 0 BTSCR 13526 Supporti update time specified in the CRL that is obtained
LTSK ng PKI during the latest update. If this parameter is set to
ENABLE, the BTS automatically updates the CRL
when the next update time specified in the CRL
arrives. If this parameter is set to DISABLE, the BTS
automatically updates the CRL based on the
configured updating period.
ENABLE(Enable)
Unit: None
PERIO BSC690 ADD GBFD-1 BTS Meaning: Interval for updating the CRL.
D 0 BTSCR 13526 Supporti GUI Value Range: 8~240
LTSK ng PKI
Unit: h
Default Value: 24

SingleRAN

nd
PERIO BSC691 ADD GBFD-1 BTS Meaning: Interval for updating the CRL.
D 0 BTSCR 13526 Supporti GUI Value Range: 8~240
LTSK ng PKI
Unit: h
Default Value: 24
CRLGE BSC690 ADD GBFD-1 BTS Meaning: Method of getting the CRL file.
TMET 0 BTSCR 13526 Supporti GUI Value Range: FTP(FTP), LDAP(LDAP)
HOD LTSK ng PKI
Unit: None
CRLGE BSC691 ADD GBFD-1 BTS Meaning: Method of getting the CRL file.
TMET 0 BTSCR 13526 Supporti GUI Value Range: FTP(FTP), LDAP(LDAP)
HOD LTSK ng PKI
Unit: None
SEARC BSC690 ADD GBFD-1 BTS Meaning: Distinguish name when search on LDAP
HDN 0 BTSCR 13526 Supporti server.
Unit: None
Default Value: None
SEARC BSC691 ADD GBFD-1 BTS Meaning: Distinguish name when search on LDAP
HDN 0 BTSCR 13526 Supporti server.
Unit: None
Default Value: None
PORT BSC690 ADD GBFD-1 BTS Meaning: Port number.

0 BTSCR 13526 Supporti GUI Value Range: 0~65535
LTSK ng PKI
Unit: None
Default Value: 389

SingleRAN

nd
PORT BSC691 ADD GBFD-1 BTS Meaning: Port number.

LTSK ng PKI
Unit: None
Default Value: 389
TSKID BSC690 ADD GBFD-1 BTS Meaning: ID of the periodic task.

LTSK ng PKI
Unit: None
RMV
BTSCR Actual Value Range: 0~3
LTSK Default Value: None
TSKID BSC691 ADD GBFD-1 BTS Meaning: ID of the periodic task.

LTSK ng PKI
Unit: None
RMV
BTSCR Actual Value Range: 0~3
LTSK Default Value: None
COMM BSC690 MOD MRFD- Security Meaning: Common name of the certificate request
NAME 0 CERTR 210305 Manage file. When a certificate request file is generated, the
EQ ment corresponding content of the specified type is used as
the common name of the file. The common name can
only be the electronic serial number (ESN).
GUI Value Range: ESN(ESN)
Unit: None
Actual Value Range: ESN
COMM BSC691 MOD MRFD- Security Meaning: Common name of the certificate request
NAME 0 CERTR 210305 Manage file. When a certificate request file is generated, the
EQ ment corresponding content of the specified type is used as
the common name of the file. The common name can
only be the electronic serial number (ESN).
GUI Value Range: ESN(ESN)
Unit: None
Actual Value Range: ESN

SingleRAN

nd
USERA BSC691 MOD MRFD- Security Meaning: Equipment description in the generic
DDINF 0 CERTR 210305 Manage certificate name. The parameter value can contain
O EQ ment only letters, digits, spaces, and the following
characters: ()+-./:?. The original parameter settings
remain unchanged if the parameter is left unspecified.
The original parameter settings are cleared if a space
is entered.
Unit: None
Default Value: None
USERA BSC690 MOD MRFD- Security Meaning: Equipment description in the generic
DDINF 0 CERTR 210305 Manage certificate name. The parameter value can contain
O EQ ment only letters, digits, spaces, and the following
characters: ()+-./:?. The original parameter settings
remain unchanged if the parameter is left unspecified.
The original parameter settings are cleared if a space
is entered.
Unit: None
Default Value: None
COUN BSC691 MOD MRFD- Security Meaning: Country where the device is located. The
TRY 0 CERTR 210305 Manage parameter value must be two English characters or
EQ ment one space. The original parameter settings remain
unchanged if the parameter is left unspecified. The
original parameter settings are cleared if a space is
entered.
Unit: None
Default Value: None

SingleRAN

nd
COUN BSC690 MOD MRFD- Security Meaning: Country where the device is located. The
TRY 0 CERTR 210305 Manage parameter value must be two English characters or
EQ ment one space. The original parameter settings remain
unchanged if the parameter is left unspecified. The
original parameter settings are cleared if a space is
entered.
Unit: None
Default Value: None
ORG BSC691 MOD MRFD- Security Meaning: Organization to which the device belongs.
0 CERTR 210305 Manage The parameter value can contain only letters, digits,
EQ ment spaces, and the following characters: ()+-./:?. The
original parameter settings remain unchanged if the
parameter is left unspecified. The original parameter
settings are cleared if a space is entered.
Unit: None
Default Value: None
ORG BSC690 MOD MRFD- Security Meaning: Organization to which the device belongs.
0 CERTR 210305 Manage The parameter value can contain only letters, digits,
EQ ment spaces, and the following characters: ()+-./:?. The
original parameter settings remain unchanged if the
parameter is left unspecified. The original parameter
settings are cleared if a space is entered.
Unit: None
Default Value: None
ORGU BSC691 MOD MRFD- Security Meaning: Organization unit to which the device
NIT 0 CERTR 210305 Manage belongs. The parameter value can contain only letters,
EQ ment digits, spaces, and the following characters: ()+-./:?.
The original parameter settings remain unchanged if
the parameter is left unspecified. The original
parameter settings are cleared if a space is entered.
Unit: None
Default Value: None

SingleRAN

nd
ORGU BSC690 MOD MRFD- Security Meaning: Organization unit to which the device
NIT 0 CERTR 210305 Manage belongs. The parameter value can contain only letters,
Unit: None
Default Value: None
STATE BSC690 MOD MRFD- Security Meaning: State or province where the device is
PROVI 0 CERTR 210305 Manage located. The parameter value can contain only letters,
NCENA EQ ment digits, spaces, and the following characters: ()+-./:?.
ME The original parameter settings remain unchanged if
Unit: None
Default Value: None
STATE BSC691 MOD MRFD- Security Meaning: State or province where the device is
PROVI 0 CERTR 210305 Manage located. The parameter value can contain only letters,
NCENA EQ ment digits, spaces, and the following characters: ()+-./:?.
ME The original parameter settings remain unchanged if
Unit: None
Default Value: None
LOCAL BSC690 MOD MRFD- Security Meaning: Specific position where the device is
ITY 0 CERTR 210305 Manage located. The parameter value can contain only letters,
Unit: None
Default Value: None

SingleRAN

nd
LOCAL BSC691 MOD MRFD- Security Meaning: Specific position where the device is
ITY 0 CERTR 210305 Manage located. The parameter value can contain only letters,
Unit: None
Default Value: None
LOCAL BSC690 MOD MRFD- Security Meaning: Local IP address of the device. The original
IP 0 CERTR 210305 Manage parameter settings remain unchanged if the parameter
EQ ment is left unspecified. The original parameter settings are
cleared if 0.0.0.0 is entered.
GUI Value Range: Valid IP Address
Unit: None
Default Value: None
LOCAL BSC691 MOD MRFD- Security Meaning: Local IP address of the device. The original
IP 0 CERTR 210305 Manage parameter settings remain unchanged if the parameter
EQ ment is left unspecified. The original parameter settings are
cleared if 0.0.0.0 is entered.
Unit: None
Default Value: None

SingleRAN

nd
MODE BSC690 ADD GBFD-1 BSC Meaning: Configuration mode of the source IP
0 CA 60211 Supporti address that is used for updating the certificate. When
MOD ng PKI this parameter is set to DEFAULT_MODE, the source
CA IP address used for updating the certificate does not
need to be configured. The system uses the OM IP to
apply for and update the certificate. When this
parameter is set to CFG_UPD_SIP, the source IP
address used for updating the certificate must be
configured. The system uses the configured source IP
address to apply for and update the certificate.
GUI Value Range:
CFG_UPD_SIP(CFG_UPD_SIP)
Unit: None
CFG_UPD_SIP
Default Value:
MODE BSC691 ADD GBFD-1 BSC Meaning: Configuration mode of the source IP
0 CA 60211 Supporti address that is used for updating the certificate. When
MOD ng PKI this parameter is set to DEFAULT_MODE, the source
CA IP address used for updating the certificate does not
need to be configured. The system uses the OM IP to
apply for and update the certificate. When this
parameter is set to CFG_UPD_SIP, the source IP
address used for updating the certificate must be
configured. The system uses the configured source IP
address to apply for and update the certificate.
GUI Value Range:
CFG_UPD_SIP(CFG_UPD_SIP)
Unit: None
CFG_UPD_SIP
Default Value:

SingleRAN

nd
UPDSI BSC690 ADD GBFD-1 BSC Meaning:

P 0 CA 60208 Supporti Source IP address used for certificate update. The
MOD ng PKI setting of this parameter must ensure proper
CA Redunda communication between the OMU and the CA. If not,
ncy use the default value 0.0.0.0. If the OMU works in
active/standby mode, the external fixed IP address
cannot be set. If it is set, the OMU cannot
communicate properly with the CA after a switchover
between the active and standby OMUs.
Disuse Statement:The interface in the current version
still supports configuration synchronization and
configuration delivery, but the system no longer uses
this parameter. The function provided by this
parameter is deleted or does not need to be manually
configured any more. This parameter will be deleted
in later version
Unit: None
UPDSI BSC691 ADD GBFD-1 BSC Meaning:

P 0 CA 60208 Supporti Source IP address used for certificate update. The
MOD ng PKI setting of this parameter must ensure proper
CA Redunda communication between the OMU and the CA. If not,
ncy use the default value 0.0.0.0. If the OMU works in
Disuse Statement:The interface in the current version
still supports configuration synchronization and
configuration delivery, but the system no longer uses
this parameter. The function provided by this
parameter is deleted or does not need to be manually
configured any more. This parameter will be deleted
in later version
Unit: None

SingleRAN

nd
APPCE BSC690 ADD MRFD- Security Meaning: File name of the device certificate file.
RT 0 CERT 210305 Manage GUI Value Range: 1~64 characters
MK ment
Unit: None
RMV
CERT Actual Value Range: 1~64 characters
MK Default Value: None
APPCE BSC691 ADD MRFD- Security Meaning: File name of the device certificate file.
RT 0 CERT 210305 Manage GUI Value Range: 1~64 characters
MK ment
Unit: None
RMV
MK Default Value: None
APPTY BSC690 MOD MRFD- Security Meaning: Application type of the device certificate.
PE 0 APPCE 210305 Manage Only SSL is supported at present.
RT ment GUI Value Range: SSL(SSL)
Unit: None
Actual Value Range: SSL
Default Value: SSL(SSL)
APPTY BSC691 MOD MRFD- Security Meaning: Application type of the device certificate.
PE 0 APPCE 210305 Manage Only SSL is supported at present.
RT ment GUI Value Range: SSL(SSL)
Unit: None
Actual Value Range: SSL
Default Value: SSL(SSL)
APPCE BSC691 MOD MRFD- Security Meaning: File name of the device certificate file.
RT 0 APPCE 210305 Manage GUI Value Range: 1~64 characters
RT ment
Unit: None
Default Value: None
APPCE BSC690 MOD MRFD- Security Meaning: File name of the device certificate file.
RT 0 APPCE 210305 Manage GUI Value Range: 1~64 characters
RT ment
Unit: None
Default Value: None

SingleRAN

nd
CERTN BSC691 ADD MRFD- Security Meaning: File name of the trust certificate or
AME 0 TRUST 210305 Manage certificate chain.
CERT ment GUI Value Range: 1~64 characters
RMV Unit: None
TRUST
Default Value: None
CERTN BSC690 ADD MRFD- Security Meaning: File name of the trust certificate or
AME 0 TRUST 210305 Manage certificate chain.
CERT ment GUI Value Range: 1~64 characters
RMV Unit: None
TRUST
Default Value: None
ISENA BSC690 SET MRFD- Security Meaning: Whether the task of checking the certificate
BLE 0 CERTC 210305 Manage validity is started.
HKTSK ment GUI Value Range: DISABLE(Disable),
ENABLE(Enable)
Unit: None
ISENA BSC691 SET MRFD- Security Meaning: Whether the task of checking the certificate
BLE 0 CERTC 210305 Manage validity is started.
HKTSK ment GUI Value Range: DISABLE(Disable),
ENABLE(Enable)
Unit: None
PERIO BSC690 SET MRFD- Security Meaning: Period of checking the certificate validity.
D 0 CERTC 210305 Manage The value of this parameter must be smaller than or
HKTSK ment equal to the value of the ALMRNG parameter.
Unit: day
Default Value: 7

SingleRAN

nd
PERIO BSC691 SET MRFD- Security Meaning: Period of checking the certificate validity.
D 0 CERTC 210305 Manage The value of this parameter must be smaller than or
HKTSK ment equal to the value of the ALMRNG parameter.
Unit: day
Default Value: 7
ALMR BSC690 SET MRFD- Security Meaning: When the MBSC detects that the time
NG 0 CERTC 210305 Manage between the current time and the expiry time of the
HKTSK ment loaded certificate is less than this threshold, a
certificate expiry alarm is reported.
Unit: day
Default Value: 30
ALMR BSC691 SET MRFD- Security Meaning: When the MBSC detects that the time
NG 0 CERTC 210305 Manage between the current time and the expiry time of the
HKTSK ment loaded certificate is less than this threshold, a
certificate expiry alarm is reported.
Unit: day
Default Value: 30
CERTN BSC690 ADD MRFD- Security Meaning: File name of the CRL.
AME 0 CRL 210305 Manage GUI Value Range: 1~64 characters
RMV ment
Unit: None
CRL
Default Value: None
CERTN BSC691 ADD MRFD- Security Meaning: File name of the CRL.
AME 0 CRL 210305 Manage GUI Value Range: 1~64 characters
RMV ment
Unit: None
CRL
Default Value: None

SingleRAN

nd
CRLPO BSC691 SET MRFD- Security Meaning: Application strategy of a certificate

LICY 0 CRLPO 210305 Manage revocation list (CRL) file.
LICY ment GUI Value Range: NOVERIFY(No Verifying),
ALARM(Only Send an Alarm If Verifying CRL
Failed), DISCONNECT(Disconnect If Verifying CRL
Failed)
Unit: None
DISCONNECT
CRLPO BSC690 SET MRFD- Security Meaning: Application strategy of a certificate

LICY 0 CRLPO 210305 Manage revocation list (CRL) file.
LICY ment GUI Value Range: NOVERIFY(No Verifying),
ALARM(Only Send an Alarm If Verifying CRL
Failed), DISCONNECT(Disconnect If Verifying CRL
Failed)
Unit: None
DISCONNECT
TSKID BSC690 ADD MRFD- Security Meaning: ID of a task.

0 CRLTS 210305 Manage GUI Value Range: 0~3
K ment
Unit: None
RMV
CRLTS Actual Value Range: 0~3
K Default Value: None
TSKID BSC691 ADD MRFD- Security Meaning: ID of a task.

0 CRLTS 210305 Manage GUI Value Range: 0~3
K ment
Unit: None
RMV
CRLTS Actual Value Range: 0~3
K Default Value: None
USR BSC690 ADD MRFD- Security Meaning: User name for logging in to the server
0 CRLTS 210305 Manage where the CRL file is saved.
K ment GUI Value Range: 0~128 characters
Unit: None
Default Value: None

SingleRAN

nd
USR BSC691 ADD MRFD- Security Meaning: User name for logging in to the server
0 CRLTS 210305 Manage where the CRL file is saved.
K ment GUI Value Range: 0~128 characters
Unit: None
Default Value: None
ISCRL BSC690 ADD MRFD- Security Meaning: Whether to update the CRL file at the next
TIME 0 CRLTS 210305 Manage update time recorded in the file. If this parameter is set
K ment to ENABLE, the task will update the CRL file at the
next update time recorded in the file. If this parameter
is set to DISABLE, the task will periodically update
the CRL file at an interval specified by
[CRLTSK:PERIOD].
ENABLE(Enable)
Unit: None
ISCRL BSC691 ADD MRFD- Security Meaning: Whether to update the CRL file at the next
TIME 0 CRLTS 210305 Manage update time recorded in the file. If this parameter is set
K ment to ENABLE, the task will update the CRL file at the
next update time recorded in the file. If this parameter
is set to DISABLE, the task will periodically update
the CRL file at an interval specified by
[CRLTSK:PERIOD].
ENABLE(Enable)
Unit: None
PERIO BSC690 ADD MRFD- Security Meaning: Interval for updating the CRL (unit: hour).
D 0 CRLTS 210305 Manage If ISCRLTIME is set to DISABLE(Disable), the CRL
K ment is updated at the interval specified by this parameter.
Unit: h
Default Value: 24

SingleRAN

nd
PERIO BSC691 ADD MRFD- Security Meaning: Interval for updating the CRL (unit: hour).
D 0 CRLTS 210305 Manage If ISCRLTIME is set to DISABLE(Disable), the CRL
K ment is updated at the interval specified by this parameter.
Unit: h
Default Value: 24
SIP BSC690 ADD GBFD-1 BSC Meaning: Source IP address for downloading CRL
0 CRLTS 60211 Supporti files. The setting of this parameter must ensure proper
K ng PKI communication between the OMU and the CA. If not,
use the default value 0.0.0.0. If the OMU works in
Unit: None
SIP BSC691 ADD GBFD-1 BSC Meaning: Source IP address for downloading CRL
0 CRLTS 60211 Supporti files. The setting of this parameter must ensure proper
K ng PKI communication between the OMU and the CA. If not,
use the default value 0.0.0.0. If the OMU works in
Unit: None

SingleRAN
PKI Feature Parameter Description 11 Counters
11 Counters
There are no specific counters associated with this feature.

SingleRAN
PKI Feature Parameter Description 12 Glossary
12 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

SingleRAN
PKI Feature Parameter Description 13 Reference Documents
13 Reference Documents
1. IETF RFC4210, "Internet X.509 Public Key Infrastructure Certificate Management

Protocol (CMP)"
2. IETF RFC4211, "Internet X.509 Public Key Infrastructure Certificate Request Message
Format (CRMF)"
3. IETF RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile"
4. IETF RFC 2585, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP
and HTTP"
5. IPsec Feature Parameter Description for SingleRAN
6. SSL Feature Parameter Description for SingleRAN
7. Access Control based on 802.1x Feature Parameter Description for SingleRAN
8. 3900 Series Base Station Alarm Reference


Pki (Sran11.1 08)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pki (Sran11.1 08)

Uploaded by

Copyright:

Available Formats

SingleRAN

PKI Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 08 (2018-01-08) Huawei Proprietary and Confidential i

1 About This Document.................................................................................................................. 1

4 Certificates and Files Used by NEs.......................................................................................... 15

5 Certificate Management and Application Scenarios............................................................20

Issue 08 (2018-01-08) Huawei Proprietary and Confidential ii

5.8 Digital Certificate Whitelist Management....................................................................................................................39

Issue 08 (2018-01-08) Huawei Proprietary and Confidential iii

8.7.2 Initial Configuration.................................................................................................................................................. 89

Issue 08 (2018-01-08) Huawei Proprietary and Confidential iv

8.18.1 Base Station Side................................................................................................................................................... 143

9 Engineering Guidelines for Digital Certificate Whitelist Management........................ 145

Issue 08 (2018-01-08) Huawei Proprietary and Confidential v

1 About This Document

This document covers the following features:

l GBFD-113526 BTS Supporting PKI

Table 1-1 provides the definitions of the base stations.

Issue 08 (2018-01-08) Huawei Proprietary and Confidential 1

Table 1-1 Base station definitions

GBTS A base station configured with a GTMU, GTMUb, or GTMUc board

eGBTS A base station configured with a GTMUb, GTMUc, UMPT_G, or

NodeB A base station configured with a WMPT, UMPT_U, or UMDU_U

eNodeB A base station configured with an LMPT, UMPT_L, UMPT_T,

Co-MPT A base station configured with a UMPT_GU, UMDU_GU, UMPT_GL,

1.2 Intended Audience

Issue 08 (2018-01-08) Huawei Proprietary and Confidential 2

1.3 Change History

Change Change Description Parameter

Feature None None

Change Change Description Parameter

Feature None None

Editorial Revised the configuration suggestions about LOCALIP None

Issue 08 (2018-01-08) Huawei Proprietary and Confidential 3

Change Change Description Parameter

Feature None None

Editorial Corrected the license control item ID of LOFD-111203 None

Change Change Description Parameter

Feature Added how to configure CANAME in different scenarios. None

Editorial None None

Change Change Description Parameter

Feature Added deployment of PKI on a NodeB that uses a WMPT None

Editorial None None

Change Change Description Parameter

Feature None None

Issue 08 (2018-01-08) Huawei Proprietary and Confidential 4

Change Change Description Parameter

Editorial Added descriptions of triggering automatic certificate None

Change Change Description Parameter

Feature None None

Revised descriptions of the application scenarios of None

Removed descriptions that Huawei-issued device None

SRAN11.1 Draft A (2015-12-30)

Issue 08 (2018-01-08) Huawei Proprietary and Confidential 5

Change Change Description Parameter

The S and ST fields in CANAME are regarded as the None

Added the function of monitoring offline certificates. None

Supported a micro base station: BTS3205E. None

Issue 08 (2018-01-08) Huawei Proprietary and Confidential 6

Change Change Description Parameter