Pki (Sran10.1 02)

SingleRAN
PKI Feature Parameter Description
Issue 02
Date 2015-05-20
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2015. 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 02 (2015-05-20) 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
2 Overview.........................................................................................................................................5
3 PKI Architecture............................................................................................................................7
3.1 Introduction....................................................................................................................................................................7
3.2 CA...................................................................................................................................................................................8
3.3 RA...................................................................................................................................................................................9
3.4 Certificate & CRL Database...........................................................................................................................................9
4 Certificates and Files Used by NEs..........................................................................................10

4.1 Device Certificate.........................................................................................................................................................10
4.2 Root Certificate and Certificate Chain.........................................................................................................................11
4.3 Trust Certificate............................................................................................................................................................12
4.4 Cross-Certificate...........................................................................................................................................................13
4.5 CRL..............................................................................................................................................................................14
5 Certificate Management and Application Scenarios............................................................15

5.1 Certificate Preconfiguration Phase...............................................................................................................................16
5.2 Certificate Management During Base Station Deployment.........................................................................................16
5.2.1 Introduction...............................................................................................................................................................16
5.2.2 Certificate Management During Automatic Base Station Deployment....................................................................17
5.3 Certificate Management During Base Station Controller Deployment........................................................................19
5.3.1 Introduction...............................................................................................................................................................19
5.3.2 Application for an Operator-Issued Device Certificate.............................................................................................19
5.4 Certificate Management During eCoordinator Deployment........................................................................................21
5.4.1 Introduction...............................................................................................................................................................21
5.4.2 Application for an Operator-Issued Device Certificate.............................................................................................21
5.5 Operation Phase............................................................................................................................................................23
5.5.1 Certificate Application..............................................................................................................................................23
5.5.2 Certificate Sharing.....................................................................................................................................................23
5.5.3 Certificate Validity Check.........................................................................................................................................25
Issue 02 (2015-05-20) Huawei Proprietary and Confidential ii

SingleRAN
5.5.4 Certificate Update......................................................................................................................................................26

5.5.5 Certificate Revocation...............................................................................................................................................27
5.5.6 CRL Acquisition........................................................................................................................................................28
5.6 PKI Networking Reliability..........................................................................................................................................29
5.7 Certificate Usage in UMPT+UMPT Cold Backup Mode............................................................................................30
6 CMPv2-based Certificate Management..................................................................................32

7 Related Features...........................................................................................................................38
8 Network Impact...........................................................................................................................40
9 Engineering Guidelines for Base Stations..............................................................................41
9.1 When to Use PKI..........................................................................................................................................................42
9.2 Required Information...................................................................................................................................................42
9.3 Hardware Planning.......................................................................................................................................................44
9.4 Requirements................................................................................................................................................................45
9.5 Deployment of PKI on the eGBTS/NodeB/eNodeB/Multimode Base Station............................................................47
9.5.1 Data Preparation........................................................................................................................................................48
9.5.2 Initial Configuration..................................................................................................................................................60
9.5.3 Activation Observation..............................................................................................................................................70
9.5.4 Deactivation...............................................................................................................................................................71
9.6 Deployment of PKI on the eGBTS using a GTMUb....................................................................................................71
9.6.4 Deactivation...............................................................................................................................................................77
9.7 Deployment of PKI on the GBTS.................................................................................................................................77
9.7.4 Deactivation...............................................................................................................................................................94
9.8 Deployment of PKI on the Base Station Controller.....................................................................................................94
9.8.2 Initial Configuration................................................................................................................................................106
9.8.3 Activation Observation............................................................................................................................................108
9.8.4 Deactivation.............................................................................................................................................................110
9.9 Deployment of PKI on the eCoordinator....................................................................................................................110
9.9.1 Data Preparation......................................................................................................................................................111
9.9.2 Initial Configuration................................................................................................................................................116
9.9.3 Activation Observation............................................................................................................................................118
9.9.4 Deactivation.............................................................................................................................................................118
9.10 Deployment of PKI Redundancy on the eGBTS/NodeB/eNodeB/Multimode Base Station...................................119
9.10.1 Data Preparation....................................................................................................................................................119
Issue 02 (2015-05-20) Huawei Proprietary and Confidential iii

SingleRAN
9.10.2 Initial Configuration..............................................................................................................................................120

9.10.3 Activation Observation..........................................................................................................................................121
9.10.4 Deactivation...........................................................................................................................................................121
9.11 Deployment of PKI Redundancy on the Base Station Controller............................................................................122
9.11.1 Data Preparation....................................................................................................................................................122
9.11.2 Initial Configuration..............................................................................................................................................123
9.11.3 Activation Observation..........................................................................................................................................123
9.11.4 Deactivation...........................................................................................................................................................124
9.12 Reconstruction from a PKI-based Secure Network to a PKI Redundancy Network on the eGBTS/NodeB/eNodeB/
Multimode Base Station...................................................................................................................................................124
9.13 Reconstruction from a PKI-based Secure Network to a PKI Redundancy Network on the Base Station Controller
..........................................................................................................................................................................................128
9.14 Performance Monitoring...........................................................................................................................................132
9.15 Parameter Optimization............................................................................................................................................132
9.16 Troubleshooting........................................................................................................................................................132
9.16.1 Base Station Troubleshooting................................................................................................................................132
9.16.2 Base Station Controller/eCoordinator Troubleshooting........................................................................................132
10 Parameters.................................................................................................................................134
11 Counters....................................................................................................................................176
12 Glossary.....................................................................................................................................177
13 Reference Documents.............................................................................................................178
Issue 02 (2015-05-20) Huawei Proprietary and Confidential iv

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 Support PKI Redundancy
l GBFD-160208 BSC Support PKI Redundancy
l WRFD-160275 NodeB Support PKI Redundancy
l WRFD-160277 RNC Support PKI Redundancy
l LOFD-070212 eNodeB Support PKI Redundancy
l TDLOFD-070212 eNodeB Support PKI Redundancy
In this document, the following naming conventions apply for LTE terms.
Includes FDD and Includes FDD Only Includes TDD Only

TDD
LTE LTE FDD LTE TDD
eNodeB LTE FDD eNodeB LTE TDD eNodeB
eRAN LTE FDD eRAN LTE TDD eRAN
Issue 02 (2015-05-20) Huawei Proprietary and Confidential 1

SingleRAN
In addition, 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 base stations.
Table 1-1 Base station definitions
Base Station Definition
GBTS GBTS refers to a base station deployed with a GTMU and maintained
through a base station controller.
eGBTS eGBTS refers to a base station deployed with a GTMUb, UMPT_G, or

UMDU_G and directly maintained by the element management system
(EMS).
NodeB NodeB refers to a base station deployed with a WMPT, UMPT_U, or

UMDU_U.
eNodeB eNodeB refers to a base station deployed with an LMPT, UMPT_L,

UMPT_T, UMDU_L, or UMDU_T.
Co-MPT Co-MPT multimode base station refers to a base station deployed with
multimode base a UMPT_GU, UMDU_GU, UMPT_GL, UMDU_GL, UMPT_GT,
station UMDU_GT, UMPT_UL, UMDU_UL, 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. A co-MPT
multimode base station functionally corresponds to any combination of
eGBTS, NodeB, and eNodeB. For example, a co-MPT multimode base
station deployed with a UMPT_GU functionally corresponds to the
combination of eGBTS and NodeB.
Separate-MPT Separate-MPT multimode base station refers to a base station on which

multimode base different modes use different main control boards. For example, a base
station station deployed with GTMU and WMPT is called a separate-MPT
GSM/UMTS dual-mode base station.
NOTE
A UMDU cannot be used in a separate-MPT base station.
NOTE
Unless otherwise specified, the descriptions and examples of the UMPT in a co-MPT base station also
apply to the UMDU in a co-MPT base station.
1.2 Intended Audience

This document is intended for personnel who:

SingleRAN
l Need to understand the features described herein

l Work with Huawei products
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
SRAN10.1 02(2015-05-20)
This issue includes the following changes.
Change Change Description Paramete

Type r Change
Feature None None

change
Editorial Added the following descriptions to 5.5.3 Certificate Validity None

change Check: 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.
SRAN10.1 01 (2015-03-23)
This issue includes the following changes.

Type r Change
Feature None None

change
Editorial Added descriptions of precautions to be taken before manually None

change triggering a CMPv2-based certificate application for the base
station. For details, see 5.5.1 Certificate Application.
SRAN10.1 Draft A (2015-01-15)

Compared with Issue , Draft A (2015-01-15) of SRAN10.1 includes the following changes.

SingleRAN

Type r Change
Feature In RAN Sharing scenarios, when multiple operators share a base None
change station, the base station supports independent deployment of a
PKI system for each operator.
Feature Added PKI descriptions for a new type of BBU: BBU3910A. None
change
Added descriptions of eGBTSs configured with GTMUb boards. None
For details, see 9.6 Deployment of PKI on the eGBTS using a
GTMUb.
Changed the authentication method of SSL certificate testing. None

l Before the change:
The authentication method is specified by the
AUTHMODE parameter.
l After the change:
Bidirectional authentication is used. For details, see 5.3.2
Application for an Operator-Issued Device Certificate.
Enhanced the signature algorithm used for device certificates. None

The recommended value of the SIGNALG
(NodeB,BSC6900,BSC6910) parameter is changed from
SHA1 to SHA256.
Modified the method of handling intermittent link disconnection None

during an automatically triggered certificate update. For details.
see 5.5.4 Certificate Update.
Modified the display format of the Common Name field in the None
SubjectName and backup SubjectName fields of eNodeBs'
certificate request messages. For details, see the following
section:
6 CMPv2-based Certificate Management
Editorial Added PKI descriptions for the eCoordinator. None

change
Modified descriptions of the CFG_INIT_UPD_ADDR value None
for the MODE parameter. For details, see 9.5.1 Data
Preparation.

SingleRAN
PKI Feature Parameter Description 2 Overview
2 Overview
PKI is a 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 piece of equipment and is created by a trusted certificate authority
(CA), which digitally signs the equipment information and public key. A digital certificate
includes the following information:
l Serial number and validity period of the certificate

l Organization that grants 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 equipment identities 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, which involves the certificate preconfiguration phase,
deployment phase, and operation phase. This solution facilitates the deployment and use of
digital certificates. Certificates in Huawei base stations and base station controllers are managed
based on CMPv2. The eCoordinator does not support certificate management based on CMPv2.
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 in
a radio bearer network

SingleRAN
PKI Feature Parameter Description 2 Overview
l Authentication during the setup of a Secure Sockets Layer (SSL) connection between an
eGBTS/NodeB/eNodeB and the U2000 at the application layer
l 802.1x-based access control for the eGBTS/NodeB/eNodeB, which uses digital certificates
for identity authentication
l Authentication during the setup of an SSL connection when the RNC/BSC/eCoordinator
uses the SSL connection to protect application data transmission.
l In RAN Sharing scenarios, when multiple operators share a base station and each operator
deploys a separate PKI server, digital certificates can be used to establish separate IPsec
tunnels for each operator, thereby implementing secure service isolation.
NOTE
l The GBTS does not support SSL or Access Control based on 802.1x.
l The eGBTS configured with a GTMUb does not support Access Control based on 802.1x.
l The eGBTS configured with a GTMUb and GBTS do not support 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 equipment. This enables operators to
establish a trusted security domain so that they have a trustworthy relationship with equipment
from other vendors.
As shown in Figure 3-1, a PKI system in a wireless network generally consists of the following
network elements (NEs):
l NEs that use certificates, including the base station, base station controller, 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

SingleRAN
NOTE
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. The CRL is obtained by the base station and base station controller from the operator's PKI
system. 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.
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, revocation, 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. The root CA is located at the top level and has
the highest security and reliability. 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. This method facilitates certificate deployment because the root
CA is no longer required for signing and issuing certificates for all end users.

SingleRAN
NOTE
Base station controllers and eCoordinators do not support cross-certificates.
Related Concepts
l Device CA: issues digital certificates to network devices within its service scope.
l Cross-certification CA: issues a cross-certificate to a peer CA under another root CA when
a trustworthy relationship must be set up with the peer CA.
l Subordinate CA: issues a user certificate or authorizes its lower-level CAs, which then issue
user certificates to O&M personnel who need to access equipment.
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 of a three-layer system.
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 to the CA, which then issues the certificate and
publishes it in the certificate database.
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 is adequate to 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 CRLs online, without
imposing any security threat on the CA system.
A certificate & CRL database is generally deployed on an FTP server or Lightweight Directory
Access Protocol (LDAP) server.

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.
Each Huawei base station is preconfigured with a Huawei-issued device certificate before
delivery. The certificate is stored on the main control board (UMPT/LMPTUMPT/LMPT/
UMDU) or UTRPc board. The certificate has a one-to-one mapping to 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.
Old Huawei base station controllers are not preconfigured with Huawei-issued device
certificates before delivery. The Huawei-issued device certificates on old Huawei base station
controllers are preconfigured by using software and are named usercert.pem. The device
certificates are not bound with the ESN of the OMU board.
New Huawei base station controllers are preconfigured with Huawei-issued device certificates
before delivery. The Huawei-issued device certificates on new Huawei base station controllers
are bound with the ESN of the OMU board and are 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.
NOTE
Huawei base station controllers of versions earlier than SRAN9.0 are called old Huawei base station
controllers. Huawei base station controllers of SRAN9.0 or later are called new Huawei base station
controllers.
All Huawei eCoordinators are preconfigured with the same certificate issued by Huawei CA
before delivery. The certificate is stored on the OMU board.
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 it connects to
a network.

SingleRAN
The application scenarios of Huawei-issued device certificates are as follows:
l If an operator's network is not deployed with a PKI system, Huawei-issued device

certificates are used for authentication throughout the communication process. The peer
equipment of a base station/base station controller/eCoordinator is preconfigured with the
Huawei root certificate. For authentication between the base station/base station
controller/eCoordinator and peer equipment, Huawei base station/base station controller/
eCoordinator uses the Huawei-issued device certificate and the peer equipment uses the
operator-issued device certificate.
l If an operator's network is deployed with a PKI system:
– When a base station 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 a base station controller is preconfigured with a Huawei-issued device certificate
that is not bound with the ESN of the OMU board, a device certificate must be manually
applied for from the operator's CA through the U2000 before the base station controller
accesses the operator's network. The operator-issued device certificate is then used for
authentication during the subsequent communication process.
– When a base station controller is preconfigured with a Huawei-issued device certificate
that is bound with the ESN of the OMU board, the base station applies for a device
certificate from the operator's CA by sending a CMPv2 message after accessing the
operator's network. The operator-issued device certificate is then used for authentication
during the subsequent communication process.
– When an eCoordinator is preconfigured with a Huawei-issued device certificate that is
not bound with the ESN of the OMU board, a device certificate must be manually
applied for from the operator's CA through the U2000 before the eCoordinator accesses
the operator's network. The operator-issued device certificate is then used for
authentication during the subsequent communication process.
4.2 Root Certificate and Certificate Chain

A root certificate is used by a root CA 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) 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 in 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 layer-two CA system. caroot.pem and rootca.pem are files in
the layer-two certificate chain.
Figure 4-1 shows an example of how an operator's CA uses the Huawei root certificate to
authenticate a Huawei-issued device certificate.

SingleRAN
Figure 4-1 Base station authentication by an operator's CA
The operator's CA is preconfigured with the Huawei root certificate. During authentication, the
base station sends its Huawei-issued device certificate to the operator's CA, which then uses the
Huawei root certificate to verify the device certificate.
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
equipment must be preconfigured with the certificate chain so that the equipment can verify the
validity of the device certificate sent by the base station during Internet Key Exchange (IKE)
authentication.
4.3 Trust Certificate

A trust certificate is the root certificate or certificate chain that is loaded on NEs. It can be
provided either by Huawei or an operator. When a device certificate is loaded, the trust certificate
is used to verify the validity of the device certificate. When communication parties perform
authentication, the trust certificate is used to verify the validity of a device certificate provided
by the peer end.
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.
If a Huawei base station/base station controller/eCoordinator uses an operator-issued device

certificate to access an operator's network:
l The base station/base station controller/eCoordinator must be preconfigured with the

operator's root certificate or certificate chain to authenticate the operator's equipment, such
as an SeGW or a third-party FTP server.
l The operator's equipment must be preconfigured with the operator's root certificate or
certificate chain to authenticate the base station/base station controller/eCoordinator.
During an authentication process, the communication parties use their respective trust
certificates to verify the validity of the peer's device certificate.

SingleRAN
O&M personnel can run the ADD BTSTRUSTCERT command to add a root certificate or
certificate chain as the trust certificate of the GBTS. They can also run the ADD TRUSTCERT
command to add a root certificate or certificate chain as the trust certificate of the eGBTS/NodeB/
eNodeB/RNC/BSC/eCoordinator.
4.4 Cross-Certificate
A cross-certificate is issued by one CA to another in order to establish a trustworthy relationship
between them.
Cross-certification is a process in which two pieces of equipment 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
Before base station deployment, the following prerequisites for cross-certification must be met:
l The Huawei CA and the operator's CA issue a cross-certificate to each other.

l A Huawei-issued device certificate and the Huawei root certificate are preconfigured in the
base station.
l The SeGW is preconfigured with an operator-issued device certificate, an operator's root
certificate, and cross-certificate 1 issued by the operator's CA to the Huawei CA.
During base station deployment, cross-certification is implemented as follows:

SingleRAN
1. The base station obtains cross-certificate 2 issued by the Huawei CA to the operator's CA
from the operator's certificate & CRL database.
2. The base station uses the Huawei root certificate to verify cross-certificate 2.
3. The base station and SeGW exchange their device certificates.
4. The base station uses cross-certificate 2 to verify the operator-issued device certificate, and
the SeGW uses cross-certificate 1 to verify the Huawei-issued device certificate.
5. If both the base station and SeGW pass the verification, the authentication succeeds.
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.5 CRL
CRL is used to verify the validity of a peer certificate. Certificates are revoked when keys 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 during authentication of 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.
– If the CRLPOLICY parameter is set to NOVERIFY, the base station/base station
controller/eCoordinator does not perform CRL-based certificate validity checks.
– If CRLPOLICY(NodeB,BSC6900,BSC6910) 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.
– If CRLPOLICY(NodeB,BSC6900,BSC6910) 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.
On the base station side, the deployment locations for all the preceding types of certificates and
CRLs can be queried and modified by running MML commands:
l For the GBTS, run the LST BTSCERTDEPLOY and SET BTSCERTDEPLOY
commands to display and modify the certificate deployment location, respectively.
l For the eGBTS/NodeB/eNodeB, run the LST CERTDEPLOY and SET
CERTDEPLOY commands to display and modify the certificate deployment location,
respectively.

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

Scenarios
This chapter describes how base stations use digital certificates.

SingleRAN
5.1 Certificate Preconfiguration Phase

The certificate preconfiguration phase includes the following activities:
l Preconfiguration of certificates on a base station

Each main control board or UTRPc board of a base station is preconfigured with the Huawei
root certificate and a Huawei-issued device certificate. The two certificates are signed and
issued by a Huawei CA, and are the default configurations of a base station and have an
unlimited lifetime.
l Publishing of the Huawei root certificate and CRLs
The Huawei root certificate and CRLs are published by using a web server or a Universal
Serial Bus (USB) flash drive. They are published at http://support.huawei.com/support/
pki.
l Preconfiguration of certificates on a base station controller/eCoordinator
The OMU board of each base station controller/eCoordinator is configured with the Huawei
root certificate and a Huawei-issued device certificate. The two certificates are signed and
issued by a Huawei CA. They are the default configurations of a base station controller/
eCoordinator and have an unlimited lifetime.
NOTE
Old Huawei base station controllers are not preconfigured with Huawei-issued device certificates
before delivery. The Huawei-issued device certificates on the base station controllers are
preconfigured by using software.
Each new Huawei base station controller is preconfigured with a Huawei-issued device certificate
before delivery. The Huawei-issued device certificate on the base station controller is bound with
the ESN of the OMU board.
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.
5.2 Certificate Management During Base Station

Deployment
5.2.1 Introduction
A base station is preconfigured with a vendor's device certificate before delivery. If equipment
from multiple operators coexists on an operator's network, there are multiple certificates issued
by different CAs. To meet the operator's requirements for unified certificate management, the
base station must automatically replace the preconfigured device certificate with an operator-
issued device certificate when it connects to the operator's network for the first time. In this
manner, base stations from different vendors all use device certificates issued by the operator's
CA.
Each Huawei base station is preconfigured with a Huawei-issued device certificate before
delivery. To access 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.

SingleRAN
5.2.2 Certificate Management During Automatic 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.
Figure 5-1 Example of automatic base station deployment in IPsec networking
To implement automatic base station deployment in IPsec networking, the operator's CA and
the SeGW must meet both the following conditions:
l The operator's CA has been preconfigured with the Huawei root certificate and a CRL,
which are used to verify Huawei-issued device certificates.
l The SeGW has been preconfigured with an operator's root certificate, a CRL, and an
operator-issued device certificate, which are used for mutual authentication between the
SeGW and the Huawei base station.
During automatic base station deployment, the certificate-related procedure is as follows:
1. During automatic base station deployment in plug and play (PnP) mode, the base station
exchanges Dynamic Host Configuration Protocol (DHCP) packets with the DHCP server
and obtains CA information. A CMPv2-based certificate application procedure is triggered
if the base station does not have an operator-issued device certificate, or it has an invalid
2. During automatic base station deployment by USB, a CMPv2-based certificate application
procedure is triggered based on CA information when both of the following are true:
l The configuration file requires an operator-issued device certificate for IKE
authentication.
l The base station does not have an operator-issued device certificate, or it has an invalid
3. The base station sends a certificate request message to the CA based on CMPv2.

SingleRAN
4. The CA uses the preconfigured Huawei root certificate to verify the Huawei-issued device
certificate carried in the message.
5. After the verification succeeds, the CA issues an operator-issued device certificate and an
operator's root certificate to the base station.
6. The base station and SeGW perform two-way authentication.
They send their respective operator-issued digital certificates to each other and then use
the operator's root certificate to confirm each other's identities.
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 in which issuer
information is consistent with the CA information, the base station directly uses this
certificate.
– If the base station has an operator-issued device certificate but information about the
issuer is inconsistent with the CA information, this certificate is considered invalid and
cannot be used. In this case, the base station uses the preconfigured Huawei-issued
device certificate to apply for a new operator-issued device certificate.
– 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 in PnP mode, 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.
In the deployment and operation phases, O&M personnel can run the LST CERTFILE
command to query certificates on the eGBTS/NodeB/eNodeB, including certificates that are not
in use and loaded certificates and CRLs.
O&M personnel can run the RMV CERTFILE command to remove a certificate that is not in
use on the eGBTS/NodeB/eNodeB. However, they must run the RMV CERTMK command to
remove a loaded device certificate from the eGBTS/NodeB/eNodeB or run the RMV
TRUSTCERT command to remove a loaded root certificate from the eGBTS/NodeB/eNodeB.

SingleRAN
5.3 Certificate Management During Base Station Controller

Deployment
5.3.1 Introduction
To access 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 method of applying for the
operator's device certificate depends on the device certificate preconfigured on the base station
controller.
5.3.2 Application for an Operator-Issued Device Certificate

The Huawei-issued device certificate on the base station controller can be replaced with an
operator-issued device certificate by using the CMPv2 certificate application procedure. This
replacement does not affect other network operations. The replacement process is as follows:
1. The base station controller sets up an SSL connection with the U2000 by using the Huawei-
issued device certificate.
2. O&M personnel run the LST APPCERT command to check whether the base station
controller has an identifiable device certificate:
l If Certificate File Name in the command output is usercert.pem, the base station
controller has a preconfigured Huawei-issued device certificate and O&M personnel
must perform step 3.
l If Certificate File Name in the command output is hwusercert.pem, the base station
controller has a preconfigured Huawei-issued device certificate that is bound with the
ESN of the OMU board. In this case, the base station controller obtains the operator-
issued device certificate from the operator's CA by using CMPv2 messages as described
in step 4.
3. O&M personnel send the certificate request file through the U2000 to the operator's CA.
O&M personnel run the following commands:
l Run the MOD CERTREQ command to modify configurations of a certificate request
template.
l Run the CRE CERTREQFILE command to generate the certificate request file.
l Run the ULD CERTFILE command to send the certificate request file locally saved
to the U2000.
l The U2000 sends the certificate request to the operator's CA. The certificate request is
manually sent to the operator's CA. The operator-issued device certificate is manually
sent to the U2000. O&M personnel must store the certificate request file and the
operator-issued device certificate in the /export/home/sysm/ftproot/ftptmp directory
of the U2000.
Figure 5-2 shows the certificate application procedure.

SingleRAN
Figure 5-2 Certificate application procedure
l Run the DLD CERTFILE command to download the operator's root certificate from
the U2000.
l Run the ADD TRUSTCERT command to add the operator's root CA certificate.
l Run the DLD CERTFILE command to download the operator-issued device certificate
from the U2000.
l Run the ADD CERTMK command to add the device certificate to the base station
controller.
l 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 base station controller and the U2000 by using this device
certificate.
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.
l Run the MOD APPCERT command to modify configurations of an active certificate.
4. The base station controller obtains the operator-issued device certificate from the operator's
CA by using CMPv2 messages. The OM personnel perform the following operations:
l Run the MOD CERTREQ command to modify configurations of a certificate request
template.
l Run the ADD CA command to add the operator's CA server. If the operator's CA server
works in active/standby mode, add both the active and standby CA servers to improve
reliability of certificate requests and updates.
l Run the REQ DEVCERT command to apply for a device certificate issued by the
operator's CA server.
established between the base station controller and the U2000 by using this device
certificate.

SingleRAN
l Run the MOD APPCERT command to modify configurations of an active certificate.

l The base station controller sets up another SSL connection by using the operator-issued
device certificate.
5.4 Certificate Management During eCoordinator

Deployment
5.4.1 Introduction
The eCoordinator does not support CMPv2. During eCoordinator deployment, the operator-
issued device certificate must be applied for through the U2000 so that the eCoordinator can
access the operator's network.
5.4.2 Application for an Operator-Issued Device Certificate

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.
– If the POLICY parameter in the SET CERTPOLICY command is set to
INDEPENDENCY(Independency), certificates for the built-in ECO6910 can be
independently configured and managed.
l Standalone ECO6910: Certificates for a standalone ECO6910 can be independently
configured and managed.
When certificates for an eCoordinator can be independently configured and managed, the
procedure for applying for the operator-issued device certificate is as follows:
1. The eCoordinator sets up an SSL connection with the U2000 by using the Huawei-issued
device certificate.
2. O&M personnel send the certificate request file through the U2000 to the operator's CA.
O&M personnel run the following commands:
l Run the MML command MOD CERTREQ to modify configurations of a certificate
request template.
l Run the MML command CRE CERTREQFILE to generate the certificate request file.
l Run the MML command ULD CERTFILE to send the local certificate request file to
the U2000 to apply for the device certificate.
l The U2000 applies to the operator's CA for a certificate. The certificate request is
manually sent to the operator's CA. The operator-issued device certificate is manually

SingleRAN
sent to the U2000. O&M personnel must store the certificate request file and the
operator-issued device certificate in the /export/home/sysm/ftproot/ftptmp directory
of the U2000.
Figure 5-3 shows the certificate application procedure.
Figure 5-3 Certificate application procedure
l Run the DLD CERTFILE command to download the CRL from the U2000.
l Run the ADD CRLTSK command to create a CRL update task.
l Run the DLD CERTFILE command to download the operator's root certificate from
the U2000.
l Run the MML command ADD TRUSTCERT to add an operator's trust certificate.
l Run the MML command DLD CERTFILE to download the requested device
certificate.
l Run the MML command ADD CERTMK to add the device certificate to the
eCoordinator.
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.
l Run the MML command MOD APPCERT to modify configurations of an active
certificate.
l The eCoordinator sets up another SSL connection by using the operator-issued device
certificate.

SingleRAN
5.5 Operation Phase

The following certificate management activities are performed in the operation phase: certificate
application, certificate sharing, certificate validity check, certificate update, and CRL
acquisition.
5.5.1 Certificate Application

For details about how to apply for a certificate for the base station controller, see 5.3.2
Application for an Operator-Issued Device Certificate. For details about how to apply for a
certificate for the eCoordinator, see 5.4.2 Application for an Operator-Issued Device
Certificate.
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. 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
Before running the MOD APPCERT command, run the TST APPCERT command to check
whether the operator-issued device certificate can be used for IKE and SSL connections. Ensure that
the device certificate can be used to successfully establish security channels between the base station
and the peer end. It is recommended that the CFM CB command be executed to enable automatic
configuration data rollback before running the MOD APPCERT command. For details, see the
CFM CB command help.
l Automatic mode
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 based on CA
configuration. If the application fails, the base station automatically reinitiates a CMPv2-
based certificate application.
For the CMPv2-based certificate application procedure, see Figure 6-3.
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.

SingleRAN
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-4, 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 another main control board of a different radio system. As
indicated by (2) in Figure 5-4, 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-4, the UMPT_U and UMPT_L boards share
the certificate with the UTRPc board.
Figure 5-4 Examples of certificate sharing
To implement certificate sharing on a base station, set the DEPLOYTYPE parameter in the
CERTDEPLOY MO to SPECIFIC. Then, set CN, SRN, and SN parameters in the
CERTDEPLOY MO to specify the board that provides a certificate for sharing.
Only active certificates can be shared. For example, IKE and 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

If the base station controller uses the ESN of the active OMU board to apply for the digital
certificate during base station controller deployment, the standby OMU board and SAU board
must share the digital certificate on 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.

SingleRAN
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, use the ESN of a functional OMU board to apply for
a new digital certificate.
eCoordinator
If the eCoordinator uses the ESN of the active OMU board to apply for the digital certificate
during eCoordinator deployment, the standby OMU board must share the digital certificate on
the active OMU board.
Certificate sharing needs to be performed when 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.
NOTE
During eCoordinator deployment, use the ESN of the active OMU board to apply for a digital certificate.
If the active OMU board becomes faulty, 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 and cannot 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 ISENABLE is set to ENABLE, 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.
If a certificate is about to expire and the UPDATEMETHOD parameter is set to CMP, the base
station/base station controller/eCoordinator automatically triggers a CMPv2-based certificate
update. 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 is successfully updated or the corresponding
CERTMK managed object (MO) is deleted, the alarm is cleared.
If a certificate is about to expire and the UPDATEMETHOD parameter is set to MANUAL,
the base station reports ALM-26840 Imminent Certificate Expiry or the 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.
If a certificate has expired, 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, notifying 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
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.
5.5.4 Certificate Update

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 lifetime of Huawei-issued device certificates is usually longer than that of equipment.
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 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(NodeB,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 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.

SingleRAN
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
– If the POLICY parameter in the SET CERTPOLICY command is set to SHARE
(Share), the built-in ECO6910 synchronizes certificate updates from the host base
station controller.
– If the POLICY parameter in the SET CERTPOLICY command is set to
INDEPENDENCY(Independency), certificates for the built-in ECO6910 can be
independently configured and managed.
l Standalone ECO6910
Certificates for a standalone ECO6910 can be 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 MML command SET CERTCHKTSK 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.2 Application for an
Operator-Issued Device Certificate.
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
controller/eCoordinator does not support online certificate revocation. Certificates must be
manually revoked. Figure 5-5 shows the base station's certificate revocation process. The base
station controller's/eCoordinator's certificate revocation process is identical to this process.

SingleRAN
Figure 5-5 Base station's certificate revocation process
The certificate revocation process on a base station is as follows:

1. A U2000 administrator runs the DSP CERTMK command on the U2000 to query the base
station's certificate information.
2. The U2000 administrator sends the certificate information to the manager of the operator's
CA, requesting to revoke the certificate.
3. The manager of the operator's CA revokes the certificate, updates the CRL file, and
publishes the CRL file to the CRL database.
4. The base station periodically obtains the latest CRL file from the CRL database.
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
after initiating the certificate application procedure, 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 a certificate of peer
equipment.
Table 5-1 lists the methods to obtain CRLs.
Table 5-1 Methods to obtain CRLs
Mode Type of CRL Server Method to Obtain CRLs
Manual FTP server Users run MML commands to enable the base station
or base station controller to obtain the CRLs from the
FTP server.
Automatic LDAP server Base stations and base station controllers are
configured with scheduled tasks for periodically
FTP server obtaining CRLs.

SingleRAN
The base station/base station controller/eCoordinator supports both manual mode and automatic
mode. However, the eCoordinator can only obtain CRLs from the FTP server. If the base station/
base station controller/eCoordinator 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(NodeB,BSC6900,BSC6910) and PORT
(NodeB,BSC6900,BSC6910) to specify the name of the LDAP server. The ISCRLTIME
(NodeB,BSC6900,BSC6910) parameter specifies whether to automatically download CRLs
after an update period (specified by the PERIOD(NodeB,BSC6900,BSC6910) parameter) has
elapsed.
From SRAN9.0 onwards, the CRL can be obtained by using SSL-protected transmission mode.
l If the CRL is obtained using LDAP, the CONNMODE(BSC6900,BSC6910,NodeB) and

AUTHPEER(BSC6900,BSC6910,NodeB) parameters must be set. If the AUTHPEER
(BSC6900,BSC6910,NodeB) 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, the base station and base station controller support only LDAPv3.
For details, see IETF RFC 4511 Lightweight Directory Access Protocol (LDAP).
l If the CRL is obtained using FTP over SSL (FTPS), run the SET FTPSCLT command on
the base station/base station controller/eCoordinator side with ENCRYMODE set to
AUTO(Auto) or ENCRYPTED(SSL Encrypted), and enable the FTPS function on the
CRL server side. If this parameter is set to ENCRYPTED(SSL Encrypted), ensure that
all FTP servers communicated with the base station support FTPS.
If the CRL server needs to be authenticated, set the SSLCERTAUTH 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
If the FTPS client is not configured with a device certificate, the CRL server cannot authenticate the
FTPS client.
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. The two PKI
servers have the same CA name and root certificate or certificate chain and synchronize
certificate management database between them. There should be reachable routes between the
base station/base station controller and the two PKI 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 success certificate applications and updates as well as CRL
acquisitions. Active and standby CAs must have different IP addresses, and so do active and
standby CRL servers.

SingleRAN
Figure 5-6 Working principles of PKI redundancy
For both the base station and base station controller, the SLVURL
(NodeB,BSC6900,BSC6910)and SLVINITREQURL(NodeB,BSC6900,BSC6910) parameters
have been added to the CA MO to specify the URL of the standby CA; the SLVIP
(NodeB,BSC6900,BSC6910), SLVPORT(NodeB,BSC6900,BSC6910), SLVUSR
(NodeB,BSC6900,BSC6910), and SLVPWD 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 reports ALM-26842 Automatic
Certificate Update Failed and the base station controller reports ALM-20803 Certificate Auto-
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+UMPT_L/LMPT), BSC, and RNC.
NOTE
PKI redundancy is not supported when base stations are deployed using plug and play (PnP). The operator
must ensure that the active PKI server works properly when base stations are deployed using 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 details about UMPT+UMPT cold backup, see section 4.1 in Base Station Equipment Reliability Feature
Parameter Description. For the definition of logical slot numbers, see section 8.4.2 in 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:

SingleRAN
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.

SingleRAN
PKI Feature Parameter Description 6 CMPv2-based Certificate Management
6 CMPv2-based Certificate Management
Certificates in Huawei base stations and base station controllers are managed based on CMPv2.
With CMPv2, base stations and base station controllers on secure networks can automatically
apply for operator-issued device certificates and update certificates.
CMPv2 complies with IETF RFC 4210, IETF RFC 4211, and draft-ietf-pkix-cmp-transport-
protocols-07. Base stations, base station controllers, or the U2000 use Hypertext Transfer
Protocol/Hypertext Transfer Protocol Secure (HTTP/HTTPS) as the bearer protocol for CMPv2.
Figure 6-1 shows the transport protocol stack for CMPv2.
NOTE
3GPP recommends HTTP as the bearer protocol.
Figure 6-1 Transport protocol stack for CMPv2
Figure 6-2 shows the topology for managing certificates in base stations and base station
controllers based on CMPv2.

SingleRAN
Figure 6-2 Example topology for CMPv2-based certificate management
As shown in Figure 6-2, 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 verifies 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 6-3 shows how a base station or base station controller applies for a certificate based on
CMPv2.

SingleRAN
Figure 6-3 Certificate application process for a base station or base station controller
As shown in Figure 6-3, a base station or base station controller applies for a certificate based
on CMPv2 as follows:
1. The base station or base station controller generates a private-public key pair for an
2. The base station or base station controller generates a certificate request message. This
message contains information such as the generated public key, SubjectName field of the
certificate, backup SubjectName field of the certificate, certificate signature algorithm, and

SingleRAN
NOTE
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).
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 not specified, the DNSName field in the backup SubjectName field
also uses the format of ESN+space+eNodeB.
3. The base station or base station controller uses the generated private key to sign the
certificate request message.
4. The base station or base station controller sends the certificate request message to the CA
by using HTTP.
5. The CA uses the public key in the message to verify the signature, and uses the Huawei
root certificate to verify a Huawei-issued device certificate carried in the message.
6. After the verification succeeds, the CA generates a device certificate for the base station
or base station controller, and uses the private key corresponding to the CA certificate to
sign the generated certificate.
7. The CA generates and then signs an Initialization Response message. This message contains
the device certificate issued by the CA to the base station or base station controller and the
operator's root certificate or certificate chain.
8. The CA sends an Initialization Response message to the base station or base station
controller by using HTTP.
9. The base station or base station controller verifies the signature carried in the response
message.
10. The base station or base station controller verifies the operator's root certificate or certificate
chain and the operator-issued device certificate.
11. After the verification succeeds, the base station or base station controller generates a
confirmation message, indicating that the operator-issued device certificate is accepted.
Then, the base station or base station controller signs the confirmation message.
12. The base station or base station controller sends the confirmation message to the CA using
HTTP.
13. The CA verifies the signature contained in the confirmation message.
14. The CA generates and then signs a confirmation message.
15. The CA sends the confirmation message to the base station or base station controller using
HTTP.
16. The base station or base station controller verifies the signature carried in the confirmation
message and completes the certificate application.
Figure 6-4 shows how a base station or base station controller updates its certificate based on
CMPv2.

SingleRAN
Figure 6-4 CMPv2-based certificate update process for a base station or base station controller
As shown in Figure 6-4, a base station or base station controller updates its certificate as follows:
1. The base station or base station controller generates a new private-public key pair.
2. The base station or base station controller generates a key update request message, which
is also the certificate update request. This message includes the new public key and the
operator-issued device certificate to be updated.
3. The base station or base station controller uses the private key corresponding to the device
certificate to sign the key update request message.
4. The base station or base station controller sends the key update request message to the CA
by using HTTP.
5. The CA uses the public key of the operator-issued device certificate carried in the 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.
6. After the verification succeeds, the CA generates a new device certificate for the base
station or base station controller. The CA then uses the private key corresponding to the
CA certificate to sign the new certificate.

SingleRAN
7. The CA generates and then signs a key update response message. This message contains
the new device certificate.
8. The CA sends the key update response message to the base station or base station controller
by using HTTP.
9. The base station or base station controller verifies the signature contained in the message.
10. The base station or base station controller verifies the new operator-issued device
certificate.
11. After the verification succeeds, the base station or base station controller generates a
confirmation message, indicating that the new operator-issued device certificate is
accepted. Then, the base station or base station controller signs the confirmation message.
12. The base station or base station controller sends the confirmation message to the CA using
HTTP.
13. The CA verifies the signature contained in the confirmation message.
14. The CA generates and then signs a confirmation message.
15. The CA sends the confirmation message to the base station or base station controller using
HTTP.
16. The base station or base station controller verifies the signature carried in the confirmation
message and completes the certificate update.
NOTE
When applying for a certificate for the first time, the base station or base station controller uses a Huawei-
issued device certificate for authentication, and the CA or RA uses the Huawei root certificate to
authenticate the base station or base station controller. During a certificate update procedure, the base
station or base station controller uses an operator-issued device certificate for authentication.
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
PKI Feature Parameter Description 7 Related Features
7 Related Features
Prerequisite Features
Base Station:
l GBFD-113526 BTS Supporting PKI depends on GBFD-118601 Abis over IP.

l WRFD-140210 NodeB PKI Support depends on WRFD-050402 lub over IP.
l GBFD-160210 BTS Support PKI Redundancy depends on GBFD-113526 BTS Supporting
PKI.
l WRFD-160275 NodeB Support PKI Redundancy depends on WRFD-140210 NodeB PKI
Support.
l LOFD-070212 eNodeB Support PKI Redundancy depends on LOFD-003010 Public Key
Infrastructure(PKI).
l TDLOFD-070212 eNodeB Support PKI Redundancy depends on TDLOFD-003010 Public
Key Infrastructure(PKI).
Base Station Controller:
l GBFD-160208 BSC Support PKI Redundancy depends on GBFD-160211 BSC Supporting

PKI.
l WRFD-160277 RNC Support PKI Redundancy depends on WRFD-160276 RNC
Supporting PKI.
eCoordinator
None
Mutually Exclusive Features

Base Station:
TDLOFD-003010 Public Key Infrastructure(PKI) is mutually exclusive with TDLOFD-001134

Virtual Routing & Forwarding.
None
eCoordinator

SingleRAN
PKI Feature Parameter Description 7 Related Features
None
Impacted Features
Base Station:
None
l GBSS: GBFD-113522 Encrypted Network Management

l WRAN: MRFD-210305 Security Management
l LTE FDD eRAN: LBFD-004003 Security Socket Layer
eCoordinator
None

SingleRAN
PKI Feature Parameter Description 8 Network Impact
8 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 9 Engineering Guidelines for Base Stations
9 Engineering Guidelines for Base Stations
This chapter describes how to deploy the PKI feature on a newly deployed base station.

SingleRAN
9.1 When to Use PKI

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.
9.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(NodeB,BSC6900,BSC6910)
Uniform resource locator (URL) of URL(NodeB,BSC6900,BSC6910)

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

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

issue certificates
Size of the certificate key KEYSIZE(NodeB,BSC6900,BSC6910)
Use of the certificate key KEYUSAGE(NodeB,BSC6900,BSC6910)
Local name of the certificate LOCALNAME(NodeB,BSC6900,BSC6910)
File name of the trust certificate or CERTNAME(NodeB,BSC6900,BSC6910)

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

(optional)
User name for logging in to the CRL USR(NodeB,BSC6900,BSC6910)

server (optional)
Password for Logging in to the CRL PWD(NodeB,BSC6900,BSC6910)

server (optional)
CRL file name (optional) FILENAME(NodeB,BSC6900,BSC6910)

SingleRAN

Method of obtaining the CRL file CRLGETMETHOD(NodeB,BSC6900,BSC6910)

(optional)
Distinct name of the CRL server SEARCHDN(NodeB,BSC6900,BSC6910)

(optional)
Port number of the CRL server PORT(NodeB,BSC6900,BSC6910)

(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 CRL USR

server (optional)
Password for Logging in to the CRL PWD

server (optional)
CRL file name (optional) FILENAME
Method of obtaining the CRL file CRLGETMETHOD

(optional)
Before deploying the PKI redundancy feature, engineering personnel also need to collect the
following information.

SingleRAN

URL of the standby CA SLVURL(NodeB,BSC6900,BSC6910)

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

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

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

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

server (optional)
9.3 Hardware Planning

GBTS/eGBTS
To support the PKI feature, the GBTS must be configured with a UMPT_L/LMPT/UTRPc board,
and the eGBTS must be configured with a UMPT_G/UMDU_G/GTMUb board.
NodeB
3900 series WCDMA base stations must be configured with a UMPT_U/UTRPc board or a
UMDU board to support the PKI feature.
eNodeB
3900 series LTE base stations must be configured with a UMPT_L/UMPT_T/LMPT/UTRPc
board or a UMDU_L/UMDU_T board to support the PKI feature.
Multimode base station

Multimode base stations must be configured with a UMPT_G/UMDU_G/UMPT_U/UMDU_U/
UMPT_L/UMPT_T/UMDU_L/UMDU_T/LMPT/UTRPc board to support the PKI feature.
Multimode base station controller

Multimode base station controllers must be configured with an OMU or SAU board to support
the PKI feature (the SAU shares the certificate with the OMU).
eCoordinator
eCoordinators must be configured with an OMU board to support the PKI feature.

SingleRAN
9.4 Requirements
The PKI feature has the following deployment requirements:
l A PKI server is deployed in the operator's network.

l Operator-issued device certificates and CRLs meet the RFC5280 standards.
l The operator's CA supports CMPv2 defined in IETF RFC 4210, and the format of a
certificate request message complies with IETF RFC 4211.
l 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.
l The operator's CA is preconfigured with the Huawei root certificate.
l The licenses for the PKI feature have been activated for the base station and base station
controller. The eCoordinator does not require a license for the PKI feature.
The following table lists the licenses controlling PKI.
Feature ID Feature License License NE Sales Unit

Name Control Control Item
Item ID Name
GBFD-11352 BTS LGMIBT BTS BSC6900& per BTS

6 Supporting SPKI Supporting BSC6910
PKI PKI (per BTS)
WRFD-14021 NodeB PKI LQW9P NodeB PKI NodeB per NodeB

0 Support KI01 support(per
NodeB)
LOFD-00301 Public Key LT1S000 Public Key Macro per eNodeB

0 Infrastructure PKI00 Infrastructure eNodeB
(PKI) (PKI)
TDLOFD-003 Public Key LT1ST00 Public Key eNodeB per eNodeB

010 Infrastructure PKI00 Infrastructure
(PKI) (PKI)
GBFD-16021 BSC LGMIPK BSC BSC6900& Per TRX

1 Supporting I Supporting BSC6910
PKI PKI (per TRX)
WRFD-16027 RNC LQW1P RNC BSC6900 Per Erl

6 Supporting KIE Supporting BSC6910
PKI PKI (per Erl)
WRFD-16027 RNC LQW1P RNC BSC6900 Per Mbps

6 Supporting KIM Supporting BSC6910
PKI PKI (per
Mbps)

SingleRAN
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.
The PKI redundancy feature has the following deployment requirements:
l Two PKI servers are deployed in the operator's network. The requirements for the PKI
servers are the same as those specified for the PKI feature.
l The two PKI servers have the same CA name and root certificate or certificate chain and
synchronize certificate management data between them.
l There are reachable routes between the base station/base station controller and the two PKI
servers.
l 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.
Feature ID Feature License License NE Sales

Name Control Control Item Unit
Item ID Name
GBFD-1602 BTS Support LGB3BTS BTS GBTS/ Per BTS

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

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

12 Support PKI KIR00 Support PKI eNodeB/ eNodeB
Redundancy Redundancy LampSite
eNodeB
TDLOFD-07 eNodeB LT1SENB eNodeB eNodeB per

0212 Support PKI SPR00 supporting eNodeB
Redundancy PKI
redundancy
(TDD)
GBFD-1602 BSC Support LGMIPKI BSC BSC6900 Per TRX

08 PKI RED Supporting &BSC69
Redundancy PKI (per 10
TRX)

SingleRAN
Feature ID Feature License License NE Sales

Name Control Control Item Unit
Item ID Name
WRFD-1602 RNC Support LQW1PKI RNC BSC6900 Per Erl

77 PKI REDE supporting BSC6910
Redundancy PKI
redundancy
(per Erl)
WRFD-1602 RNC Support LQW1PKI RNC BSC6900 Per Mbps

77 PKI REDM supporting BSC6910
Redundancy PKI
redundancy
(per Mbps)
9.5 Deployment of PKI on the eGBTS/NodeB/eNodeB/

Multimode Base Station
This section uses the networking illustrated in Figure 9-1 as an example to describe how to
deploy the PKI feature on the eGBTS, NodeB, eNodeB, or multimode base station.
NOTE
This section only describes how to deploy the PKI feature by using MML commands or the Configuration
Management Express (CME). For details about how to deploy the PKI feature on the U2000 client, see the
U2000 Help.
A UMDU can be used in a co-MPT multimode base station in the secure networking shown in Figure
9-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 UMPT or UMDU. For details about how
to deploy PKI on an eGBTS using a GTMUb, see 9.6 Deployment of PKI on the eGBTS using a
GTMUb.

SingleRAN
Figure 9-1 Example of the secure networking for the eGBTS/NodeB/eNodeB/multimode base
station
9.5.1 Data Preparation

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 9-1 lists the data to prepare for the
deployment location of a certificate on the base station (the CERTDEPLOY MO in MML
configurations and the CERTDEPLOY or Certification Deploy Position MO in CME
configurations).
Table 9-1 Data to prepare 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 must ork
Type 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 -

SingleRAN

Name Sour
ce
Subrack No. SRN
Slot No. SN
Table 9-2 lists the data to prepare for a certificate request template (the CERTREQ MO in
MML configurations and the CERTREQ or Certificate Request Configuration MO in CME
configurations).
Table 9-2 Data to prepare for a certificate request template

Name Sour
ce
Common Name COMMNAME The default value of the Common Name Netw
field in a certificate request file is ork
XXX.huawei.com (XXX indicates the plan
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 Name USERADDINFO The default value of this parameter

Additional Info. is .huawei.com.
Country COUNTRY -
Organization ORG -
Organization ORGUNIT -
Unit
State or STATEPROVINCE- -
Province NAME
Locality LOCALITY -

SingleRAN

Name Sour
ce
Key Usage KEYUSAGE This parameter can be set to one or more

of the following values:
DIGITAL_SIGNATURE,
KEY_ENCIPHERMENT,
KEY_AGREEMENT, and
DATA_ENCIPHERMENT. The
recommended values are
DIGITAL_SIGNATURE and
KEY_ENCIPHERMENT. If this
parameter is set to DIGITAL_SIGNA-
TURE, 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 Secure hash algorithm 256

Algorithm (SHA256) is recommended for
signing a certificate request file.
l Therefore, this parameter is invalid
when it is set to MD5.
Key Size KEYSIZE -
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 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 9-3 lists the data to prepare for the CA (the CA MO in MML configurations and the CA
or Certificate Authority MO in CME configurations).

SingleRAN
Table 9-3 Data to prepare for the CA

Name Sour
ce
Certificate CANAME This parameter is set based on the name Netw

Authority of the operator's CA. For example, if the ork
Name values of the C, S, L, O, OU, CN, and E plan
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.
For details about the character set of the
PRINTABLE type, see RFC 3642.
Certificate URL Currently, base stations cannot translate

Authority URL 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/.
Signature SIGNALG -
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 The interface IP address is used
during base station deployment by
PnP, and the O&M IP address is used
during base station deployment by
USB. If this parameter is set to
CFG_UPD_SIP,
INITREQURLand INITREQSIPdo
not need to be set. The base station
uses UPDSIPand URLas the source
and destination IP addresses,
respectively, for routine certificate
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

SingleRAN

Name Sour
ce
uses UPDSIP and URL as the

source and destination IP
addresses, respectively.
– 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 - Netw

Update Source ork
IP plan
CA URL INITREQURL - Netw

During Site ork
Deployment plan
Source IP for INITREQSIP - Netw

Applying for a ork
Certificate plan
During Site
Deployment
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 9-4 lists the data to prepare for a device certificate (the CERTMK MO in MML
configurations and the CERTMK or Device Certificate MO in CME configurations).

SingleRAN
Table 9-4 Data to prepare 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
This parameter is set to appcert.pem
accordingly. Users cannot modify or
remove this MO.
Table 9-5 lists the data to prepare for an active certificate (the APPCERT MO in MML
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.
Table 9-5 Data to prepare for an active certificate

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

for IKE authentication and SSL for ork
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 9-6 lists the data to prepare for a trust certificate (the TRUSTCERT MO in MML
configurations and the TRUSTCERT or Trust Certificate MO in CME configurations).
Table 9-6 Data to prepare 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 plan
a Huawei trust certificate. For the
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 9-7 lists the data to prepare for a periodic certificate validity check task (the
CERTCHKTSK MO in MML configurations and the CERTCHKTSK or Certificate Validity
Check Task MO in CME configurations).

SingleRAN
Table 9-7 Data to prepare for a periodic certificate validity check task

Name Sourc
e
Certificate ISENABLE The recommended value of this parameter Netwo

Validity is ENABLE. rk plan
Period
Checking
Checking PERIOD The default value is recommended for this

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

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

Method is CMP.
(Optional) Prepare CRL data if the base station needs to obtain CRL information from the CA.
Table 9-8 lists the data to prepare for a CRL (the CRL MO in MML configurations and the
CRL or Certificate Revocation List MO in CME configurations).
Table 9-8 Data to prepare for a CRL

Name Sourc
e
CRL File CERTNAME - Netwo

Name rk plan
(Optional) Prepare data related to CRL usage policies. Table 9-9 lists the data to prepare for
these policies (the CRLPOLICY MO in MML configurations and the CRLPOLICY or CRL
Check Policy MO in CME configurations).

SingleRAN
Table 9-9 Data to prepare 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 9-10 lists the data to
prepare for the task (the CRLTSK MO in MML configurations and the CRLTSK or CRL
Updating Obtaining Task MO in CME configurations).
Table 9-10 Data to prepare for a periodic CRL download task

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

CRL server. rk plan
User Name USR -
Password PWD -
File Name FILENAME -
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 peer equipment 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.

SingleRAN

Name Sourc
e
Task ID TSKID - 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 specifies whether SSL is Netwo

Mode used to secure connections. This parameter rk plan
takes effect only when the
CRLGETMETHOD parameter is set to
LDAP.
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 9-11 lists the data to prepare for downloading a certificate file (the CERTFILE
MO in MML configurations).
Table 9-11 Data to prepare for downloading a certificate file

Name Source
FTP Server IP IP - Network

plan
User Name USR - Network

plan
Password PWD - Network

plan
Source File SRCF - Network

Name plan

SingleRAN

Name Source
Destination DSTF It is recommended that this parameter be Network

File Name 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 - Network
Type plan
(Optional) Prepare data to manually trigger a CMPv2-based certificate application. Table

9-12 lists the data to prepare for applying for a device certificate based on CMPv2. The
corresponding MML command is REQ DEVCERT.
Table 9-12 Data to prepare for applying for a device certificate based on CMPv2

Name Source
Certificate CANAME - Network

Authority plan
Name
Certificate File APPCERT - Network

Name plan
Renew Key REKEY The recommended value of this Network

parameter is Yes. plan
Table 9-13 lists the data to prepare for updating a device certificate (the DEVCERT MO in
MML configurations) based on CMPv2. The corresponding MML command is UPD
DEVCERT.
Table 9-13 Data to prepare 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 - Network

plan

SingleRAN
9.5.2 Initial Configuration
Using MML Commands

Perform the following steps to activate an operator-issued device certificate on the base station
side:
NOTE
If multi-level CAs are deployed in the 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. If a certificate application procedure
is automatically triggered, skip this step.
Step 5 Run the MML command ADD TRUSTCERT to add an operator's trust certificate.
Step 6 Run the MML command REQ DEVCERT to set information required for the base station 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 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
Step 10 (Optional) Run the MML command ADD CRL to add a CRL. If a certificate application
procedure is automatically triggered, skip this step.
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:

SingleRAN
Step 1 Run the MML command SET CERTDEPLOY to set a board whose certificate is shared.
----End
MML Command Examples

The following is an MML command example of how to activate an operator-issued device
certificate.
//Setting the deployment position of a certificate
SET CERTDEPLOY: DEPLOYTYPE=SPECIFIC, CN=0, SRN=0, SN=7;
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.
UPDSIP="10.45.45.45",INITREQURL="http://10.89.89.89:80/
pkix/",INITREQSIP="10.20.20.188";
//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:
UPDSIP="10.20.20.188";
//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";

SingleRAN
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
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=7;
Using the CME in Single Configuration

Set parameters on the CME GUI by referring to section "9.5.1 Data Preparation" For the
method of performing the CME single configuration, see CME Single Configuration Operation
Guide.
Using the CME in Batch Configuration for Newly Deployed Base Stations
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.
I. CME Summary batch configuration
Fill the settings of the parameters listed in Table 9-14 into a summary data file, which also
contains data for the base stations to be deployed. Then, import the summary data file into the
CME.
Fill in the summary data file as follows:
l If the MOs listed in Table 9-14 are contained in a scenario-specific summary data file,
verify the parameters related to the MOs and save the file.
l If some MOs listed in Table 9-14 are not contained in a scenario-specific summary data
file, customize a summary data file to include these MOs.

SingleRAN
Table 9-14 MOs related to PKI
Number MO Sheet in the Parameter Group Re

Summary ma
Data File rks
1 CERTDEPLO Common Data DEPLOYTYPE/CN/SRN/ -

Y SN
2 CA Common Data CANAME/URL/ -

SIGNALG/MODE/
UPDSIP/INITREQURL/
INITREQSIP/
3 CERTREQ Common Data COMMNAME/ -

USERADDINFO/
COUNTRY/ORG/
ORGUNIT/STATE/
PROVINCENAME/
LOCALITY/KEYUSAGE/
SIGNALG/KEYSIZE/
LOCALNAME/LOCALIP
4 CERTMK Common Data APPCERT -
5 APPCERT Common Data APPTYPE/APPCERT -
6 TRUSTCERT Common Data CERTNAME -
7 CERTCHKTS Common Data ISENABLE/PERIOD/ -

K ALMRNG/
UPDATEMETHOD
8 CRL Common Data CERTNAME -
9 CRLPOLICY Common Data CRLPOLICY -
10 CRLTSK Common Data IP/USR/PWD/FILENAME/ -

ISCRLTIME/PERIOD/
CRLGETMETHOD/
SEARCHDN/PORT/
TSKID/SIP/CONNMODE/
AUTHPEER
For instructions about performing batch configuration for each type of base station, see the
following sections in 3900 Series Base Station Initial Configuration Guide for diffident base
stations:
l "Creating eGBTSs in Batches"

l "Creating NodeBs in Batches"
l "Creating eNodeBs in Batches"
l "Creating Separate-MPT Multimode Base Stations in Batches"
l "Creating Co-MPT Base Stations in Batches"(for an eGBTS or a co-MPT base station)

SingleRAN
II. 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 9-2 shows the procedure for configuring data using the CME transport security wizard.

SingleRAN
Figure 9-2 Procedure for configuring data using the CME transport security wizard
After completing configurations on the CME transport security wizard, the IPsec and PKI
parameter setting tables are exported, displaying the IPsec and KPI parameters that have been

SingleRAN
configured and the parameters that need to be manually configured in the summary data file.
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 for configuring PKI:
l PKI redundancy cannot be configured.

l SSL transmission cannot be configured for obtaining the CRL.
l PKI parameters for the eGBTS, NodeB, and eNodeB can be configured.
l PKI parameters can be configured for the GBTS only when it is configured with GTMUb
+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 the Setting Notes

Group Summary Data
File
CERTDEPLO DEPLOYT Common Data This parameter is automatically

Y YPE set to SPECIFIC in certificate
sharing scenarios.
In other scenarios, manual
configuration is required.
CN Common Manual configuration
SRN Common Manual configuration
SN Common Manual configuration
CA CANAME Common Data This parameter uses the default

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

interface.
SIGNALG Common Data This parameter uses the default

interface.

SingleRAN

Group Summary Data
File
MODE Common Data Manual configuration
UPDSIP Base Station Manual configuration

Transport Data
INITREQU Common Data This parameter uses the default

RL configuration on the wizard
interface.
INITREQS Base Station Manual configuration

IP Transport Data
CERTREQ COMMNA Common Data This parameter is automatically

ME set to ESN.
USERADD Common Data This parameter is automatically

INFO set to .huawei.com.
KEYUSAG Common Data This parameter is automatically

E set to
DATA_ENCIPHERMENT-
1&DIGITAL_SIGNATURE
-1&KEY_AGREEMENT-1
&KEY_ENCIPHER-
MENT-1.
SIGNALG Common Data This parameter is automatically

set to SHA256.
KEYSIZE Common Data This parameter is automatically

set to 2048.
LOCALNA Base Station Manual configuration

ME Transport Data
LOCALIP Base Station Manual configuration

Transport Data
CERTMK APPCERT Common Data This parameter is automatically

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

set to OPKIDevCert.cer.
APPCERT Common Data

SingleRAN

Group Summary Data
File
TRUSTCERT CERTNA Common Data The preconfigured root

ME 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.
CERTCHKTS ISENABLE Common Data This parameter is automatically

K set to ENABLE.
PERIOD Common Data This parameter is automatically

set to 7.
ALMRNG Common Data This parameter is automatically

set to 30.
UPDATEM Common Data This parameter is automatically

ETHOD set to CMP.
CRL CERTNA Common Data This parameter uses the default

ME configuration on the wizard
interface.
CRLPOLICY CRLPOLI Common Data This parameter is automatically

CY set to ALARM.
CRLTSK IP Common Data This parameter uses the default

interface.
USR Common Data This parameter uses the default

interface.
PWD Common Data This parameter uses the default

interface.
FILENAM Common Data This parameter uses the default

E configuration on the wizard
interface.
ISCRLTIM Common Data This parameter is automatically

E set to CMP.
PERIOD Common Data This parameter is automatically

set to DISABLE.

SingleRAN

Group Summary Data
File
CRLGET Common Data This parameter uses the default

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

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

interface.
TSKID Common Data This parameter is automatically

set to 0.
SIP Base Station Manual configuration

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.
Using the CME in Batch Configuration for Existing Base Stations

When configuring the PKI feature on an existing base station, you are advised to perform CME
batch modification. This function modifies data on multiple base stations, excluding that for
neighboring cell configurations.
Step 1 Choose CME > Advanced > Customize Summary Data File from the main menu of a U2000
client, or choose Advanced > Customize Summary Data File from the main menu of a CME
client, to customize a summary data file for batch reconfiguration.
Step 2 Export the NE data stored on the CME into the customized summary data file.
l For co-MPT multimode base stations: Choose CME > SRAN Application > MBTS
Application > Export Data > Export Base Station Bulk Configuration Data from the
main menu of the U2000 client, or choose SRAN Application > MBTS Application >
Export Data > Export Base Station Bulk Configuration Data from the main menu of the
CME client.
l For separate-MPT GSM-involved multimode base stations or GO base stations: Choose
CME > GSM Application > Export Data > eGBTS Bulk Configuration Data from the
main menu of the U2000 client, or choose GSM Application > Export Data > Export
eGBTS Bulk Configuration Data from the main menu of the CME client.
l For separate-MPT UMTS-involved multimode base stations or UO base stations: Choose
CME > UMTS Application > Export Data > Export Base Station Bulk Configuration
Data from the main menu of the U2000 client, or choose UMTS Application > Export Data
> Export Base Station Bulk Configuration Data from the main menu of the CME client.
l For separate-MPT LTE-involved multimode base stations or LO base stations: Choose CME
> LTE Application > Export Data > Export Base Station Bulk Configuration Data from

SingleRAN
the main menu of the U2000 client, or choose LTE Application > Export Data > Export
Base Station Bulk Configuration Data from the main menu of the CME client.
Step 3 After filling the MO data listed in Table 9-14 into the summary data file, close the file.
Step 4 Import the summary data file into the CME.
Application > Import Base Station Bulk Configuration Data from the main menu of the
U2000 client, or choose SRAN Application > MBTS Application > Import Data > Import
CME > GSM Application > Import Data > Import eGBTS Bulk Configuration Data
from the main menu of the U2000 client, or choose GSM Application > Import Data >
Import eGBTS Bulk Configuration Data from the main menu of the CME client.
CME > UMTS Application > Import Data > Import Base Station Bulk Configuration
Data from the main menu of the U2000 client, or choose UMTS Application > Import
Data > Import Base Station Bulk Configuration Data from the main menu of the CME
client.
> LTE Application > Import Data > Import Base Station Bulk Configuration Data from
the main menu of the U2000 client, or choose LTE Application > Import Data > Import
----End
For details about how to import and export data, see the U2000 Help.
9.5.3 Activation Observation

Perform the following steps to observe the PKI feature on the eGBTS, NodeB, eNodeB, and
multimode base station:
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
Perform the following steps to observe 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

SingleRAN
9.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
9.6 Deployment of PKI on the eGBTS using a GTMUb

deploy the PKI feature on the eGBTS using a GTMUb.
Figure 9-3 Example of the secure networking for the eGBTS using a GTMUb
NOTE
This networking scenario supports only SSL certificates.

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 9-15 lists the data to prepare for applying for a certificate from the CA (the SSL MO in
MML configurations).

SingleRAN
Table 9-15 Data to prepare 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
ESN of the board connecting to 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 -

manually set on the
CA and it does not
Organization This parameter is -

manually set on the
CA and it does not
Organization This parameter is -

Unit manually set on the
CA and it does not
State or This parameter is -

Province manually set on the
CA and it does not
Locality This parameter is -

manually set on the
CA and it does not

SingleRAN

Name Sour
ce
Key Usage This parameter is This parameter can be set to one or more
manually set on the of the following values:
CA and it does not DIGITAL_SIGNATURE,
have a parameter ID. KEY_ENCIPHERMENT,
KEY_AGREEMENT, and
DATA_ENCIPHERMENT. The
recommended values are
TURE, 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 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. Message digest algorithm 5
have a parameter ID. (MD5) cannot be used because it
provides low security.
Key Size This parameter is -

manually set on the
CA and it does not
Local Name This parameter is l If this parameter is not set, the default
manually set on the value of the Common Name field in a
CA and it does not 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 -

File Name
Public PUBCERT -
Certificate File
Name
Private Key File PRIVKEY -

Name

SingleRAN

Name Sour
ce
Private Key PKPENABLESTA It is recommended that the private key

Password password protection be enabled for
Enabled State security reasons.
Private Key PWD -

Password
Certificate CRLENABLESTA -
Revocation List
File Enabled
State
Certificate CRL -
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 -
Chain File
Name
Table 9-16 lists the data to prepare for the deployment location of a certificate on the base station
(the CERTDEPLOY MO in MML configurations and the CERTDEPLOY or Certification
Deploy Position MO in CME configurations).
Table 9-16 Data to prepare for the deployment location of a certificate
Parameter Parameter ID Setting Notes Dat

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

Deploy Position eGBTS using a GTMUb. work
Type plan
Cabinet No. CN -
Subrack No. SRN
Slot No. SN

SingleRAN
Table 9-17 lists the data to prepare 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.
Parameter Name Parame Setting Notes Data

ter ID Source
Source File Name SRCF - Network

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

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

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

the FTP server. plan

plan

plan

plan

report the progress of file downloading. plan
The recommended value of this
parameter is Y.
Using MML Commands

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.

SingleRAN
Step 2 Based on the data plan listed in Table 9-15, 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

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",DSTF="OperationCA.cer",MODE=IPV4,IP="10.60.60.60",U
SR="admin",PWD="*****";
//Downloading the public key certificate from the FTP server
DLD
GENFILE:SRCF="OperationDev.cer",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",DSTF="OperationDevPri.cer",MODE=IPV4,IP="10.60.
60.60",USR="admin",PWD="*****";
//Downloading the CRL file from the FTP server
DLD
GENFILE:SRCF="eNodeB.crl",DSTF="eNodeB.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).
Step 2 On the U2000 client in tradition style, choose Security > Certificate Authentication
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 SSL Connection
Management window. Then, observe Connection Status of the base station.

SingleRAN
If the value of Connection Status is Connected, an SSL connection has been successfully
established.
Step 3 Run the MML command SET CONNTYPE 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.
If the value of Connection Status is Connected, an SSL connection has been successfully
established.
----End
9.6.4 Deactivation
None
9.7 Deployment of PKI on the GBTS

deploy the PKI feature on the GBTS.
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 9-4 Example of the secure networking for the GBTS (GTMUb+UTRPc)

SingleRAN

NOTE
Table 9-18 lists the data to prepare 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).
Table 9-18 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 be Network

used to identify a GBTS. plan
BTS Index BTSID -
BTS Name BTSNAME -
Certificatio DEPLOYTYPE If a digital certificate is deployed

n deploy on a main control board, this
position parameter must be set to
type 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 -
Subrack No. SRN
Slot No. SN
GBTSs must be configured with information about a CA so that they can apply for certificates
from the CA. Table 9-19 lists the data to prepare for the CA (the BTSCA MO in MML
configurations and the BTSCA or BTS Certificate Authority MO in CME configurations).
Table 9-19 Data to be prepared for a CA

Name Source


SingleRAN

Name Source
BTS Index BTSID -
BTS Name BTSNAME -
Certificate CANAME This parameter is set based on the

Authority name of the operator's CA. For
Name 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.
For details about the character set
of the PRINTABLE type, see
RFC 3642.
Certificate URL 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 Secure hash algorithm 256

Algorithm (SHA256) is recommended for
signing a certificate request file.
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 9-20 lists the data to prepare for a certificate request template (the BTSCERTREQ MO
in MML configurations and the BTSCERTREQ or BTS Certreq File Configuration MO in
CME configurations).
Table 9-20 Data to be prepared for a certificate request template

Name Source

BTS Index BTSID -
BTS Name BTSNAME -
Common COMMNAME The default value of the

Name 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 The default value of this

Name parameter is .huawei.com.
Additional
Info.
Country COUNTRY -
Organizati ORG -
on

SingleRAN

Name Source
Organizati ORGUNIT -
on Unit
State or STATEPROVINCENAME -
Province
Locality LOCALITY -
Key Usage KEYUSAGE -
Signature SIGNALG l Secure hash algorithm 256

Algorithm (SHA256) is recommended
for signing a certificate
request file.
l Message digest algorithm 5
(MD5) cannot be used
because it provides low
security.
Key Size KEYSIZE -
Local LOCALNAME If this parameter is not set, the

Name 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 The value of this parameter must

be the same as that of
LOCALIP in the
BTSIKEPEER MO.
Table 9-21 lists the data to prepare for a device certificate (the BTSCERTMK MO in MML
configurations and the BTSCERTMK or BTS Device Certificate MO in CME configurations).
Table 9-21 Data to be prepared for a device certificate
Paramete Parameter ID Setting Notes Data

r Name Source


SingleRAN

r Name Source
BTS Index BTSID -
BTS Name BTSNAME -
Certificate APPCERT l If an operator-issued device

File Name 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.
l If a Huawei-issued device
certificate is used for identity
authentication 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.
Table 9-22 lists the data to prepare 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.
Table 9-22 Data to be prepared for an active certificate

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

be used to identify a GBTS. k plan
BTS Index BTSID -
BTS Name BTSNAME -

SingleRAN

Name Source
Applicatio APPTYPE This parameter must be set to

n Type IKE for IKE authentication
and SSL for SSL
authentication.
This parameter must be set to
SSL for SSL authentication.
Certificate APPCERT l If an operator-issued device

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

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

be used to identify a GBTS. k plan
BTS Index BTSID -
BTS Name BTSNAME -

SingleRAN

r Name Source
Certificate CERTNAME The GBTS must be configured

File Name 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).
Table 9-24 Data to be prepared for a periodic certificate validity check task

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

be used to identify a GBTS. plan
BTS Index BTSID -
BTS Name BTSNAME -
Certificate ISENABLE The recommended value of

Validity this parameter is ENABLE.
Period
Checking
Checking PERIOD The default value is

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

Threshold recommended for this
parameter.
Update UPDATEMETHOD The recommended value of

Method this parameter is CMP.

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

Name Source

BTS Index BTSID -
BTS Name BTSNAME -
CRL File CERTNAME -

Name
(Optional) Prepare data related to CRL usage policies. Table 9-26 lists the data to prepare for
these policies (the BTSCRLPOLICY MO in MML configurations and the
BTSCRLPOLICY or BTS CRL Using Policy MO in CME configurations).
Table 9-26 Data to be prepared for CRL usage policies

Name Source

BTS Index BTSID -
BTS Name BTSNAME -
CRL Using CRLPOLICY -

Policy
(Optional) Prepare data related to a periodic CRL download task. Table 9-27 lists the data to
prepare for the task (the BTSCRLTSK MO in MML configurations and the BTSCRLTSK or
BTS CRL Updating Task MO in CME configurations).
Table 9-27 Data to be prepared for a periodic CRL download task

Name Source


SingleRAN

Name Source
BTS Index BTSID -
BTS Name BTSNAME -
IP Address IP This parameter is set to the IP

address of the CRL server.
User Name USR -
Password PWD -
Using CRL's Next ISCRLTIME If this parameter is set to

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

Period(h) specified when
ISCRLTIME is set to
DISABLE.
Access Method CRLGETMETHOD -
Distinguish Name SEARCHDN This parameter must be set

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

set to LDAP.

defined
Connection Mode CONNMODE This parameter indicates Network

whether to use SSL plan
connections. This parameter
takes effect only when
CRLGETMETHOD is set to
LDAP.

SingleRAN

Name Source
Authenticate Peer AUTHPEER This parameter indicates Network

whether to authenticate the plan
peer certificate when the SSL
connections are used. This
parameter takes effect only
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.
server. Table 9-28 lists the data to prepare for downloading a certificate file.
Table 9-28 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 - Network

plan

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

plan

SingleRAN

9-29 lists the data to prepare for applying for a device certificate (the BTSDEVCERT MO in
MML configurations) based on CMPv2.
Table 9-29 Data to be prepared for applying for a device certificate based on CMPv2

Name Source
Certificate CANAME This parameter must be set Network

Authority Name to the same value as plan
CANAME.
Certificate File APPCERT - 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 9-30 lists
the data to prepare for updating a device certificate (the BTSDEVCERT MO in MML
configurations) based on CMPv2.
Table 9-30 Data to be prepared for updating a device certificate 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 - Network

plan
Using MML Commands

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.

SingleRAN
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.
Step 9 (Optional) Run the MML command DLD BTSCERTFILE to download a CRL from the
operator's certificate & CRL database.
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";

SingleRAN
//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;
In addition, the following configuration is required to manually trigger a certificate update:

UPD BTSDEVCERT: APPCERT="OPKIDevCert.cer",REKEY=YES;
Using the CME in Single Configuration

Set parameters on the CME GUI by referring to section "9.7.1 Data Preparation" For the
method of performing the CME single configuration, see CME Single Configuration Operation
Guide.
Using the CME in Batch Configuration for Newly Deployed Base Stations
Fill the settings of the parameters listed in Table 9-31 into a summary data file, which also
contains data for the base stations to be deployed. Then, import the summary data file into the
CME.
Fill in the summary data file as follows:
l If the MOs listed in Table 9-31 are contained in a scenario-specific summary data file,
verify the parameters related to the MOs and save the file.
l If some MOs listed in Table 9-31 are not contained in a scenario-specific summary data
file, customize a summary data file to include these MOs.
Table 9-31 MOs related to PKI
Numbe MO Sheet in the Parameter Group Remar

r Summary ks
Data File
1 BTSCERTDEPLO Common Data l DEPLOYTYPE -

Y l CN
l SRN
l SN

SingleRAN

r Summary ks
Data File
2 BTSCA Common Data l CANAME -

l URL
l SIGNALG
3 BTSCERTREQ Common Data l COMMNAME -

l USERADDINFO
l COUNTRY
l ORG
l ORGUNIT
l STATEPROVINCE-
NAME
l LOCALITY
l KEYUSAGE
l SIGNALG
l KEYSIAE
l LOCALNAME
l LOCALIP
4 BTSCERTMK Common Data APPCERT -
5 BTSAPPCERT Common Data l APPTYPE -

l APPCERT
6 BTSTRUSTCERT Common Data CERTNAME -
7 BTSCERTCHKTS Common Data l ISENABLE -

K l PERIOD
l ALMRNG
l UPDATEMETHOD
8 BTSCRL Common Data CERTNAME -
9 BTSCRLPOLICY Common Data CRLPOLICY -

SingleRAN

r Summary ks
Data File
10 BTSCRLTSK Common Data l IP -

l USR
l PWD
l FILENAME
l ISCRLTIME
l PERIOD
l CRLGETMETHOD
l SEARCHDN/PORT
l TSKID/
l SIP
l CONNMODE
l AUTHPEER
Using the CME in Batch Configuration for Existing Base Stations

When configuring the PKI feature on an existing base station, you are advised to perform batch
modification on the CME. This function modifies data on multiple base stations, excluding that
for neighboring cell configurations.
Perform CME batch modification as follows:
Step 1 Choose CME > Advanced > Customize Summary Data File from the main menu of a U2000
client, or choose Advanced > Customize Summary Data File from the main menu of a CME
client, to customize a summary data file for batch reconfiguration.
Step 2 Export the NE data stored on the CME into the customized summary data file.
Application > Export Data > Export Base Station Bulk Configuration Data from the
main menu of the U2000 client, or choose SRAN Application > MBTS Application >
Export Data > Export Base Station Bulk Configuration Data from the main menu of the
CME client.
CME > GSM Application > Export Data > eGBTS Bulk Configuration Data from the
main menu of the U2000 client, or choose GSM Application > Export Data > Export
eGBTS Bulk Configuration Data from the main menu of the CME client.
CME > UMTS Application > Export Data > Export Base Station Bulk Configuration
Data from the main menu of the U2000 client, or choose UMTS Application > Export Data
> Export Base Station Bulk Configuration Data from the main menu of the CME client.
> LTE Application > Export Data > Export Base Station Bulk Configuration Data from

SingleRAN
the main menu of the U2000 client, or choose LTE Application > Export Data > Export
Step 3 After filling the MO data listed in Table 9-31 into the summary data file, close the file.
Step 4 Import the summary data file into the CME.

Application > Import Base Station Bulk Configuration Data from the main menu of the
U2000 client, or choose SRAN Application > MBTS Application > Import Data > Import
CME > GSM Application > Import Data > Import eGBTS Bulk Configuration Data
from the main menu of the U2000 client, or choose GSM Application > Import Data >
Import eGBTS Bulk Configuration Data from the main menu of the CME client.
CME > UMTS Application > Import Data > Import Base Station Bulk Configuration
Data from the main menu of the U2000 client, or choose UMTS Application > Import
Data > Import Base Station Bulk Configuration Data from the main menu of the CME
client.
> LTE Application > Import Data > Import Base Station Bulk Configuration Data from
the main menu of the U2000 client, or choose LTE Application > Import Data > Import
For details about how to import and export data, see the U2000 Help.
----End

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.

SingleRAN
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.
----End
9.7.4 Deactivation
----End
9.8 Deployment of PKI on the Base Station Controller

deploy the PKI feature on the base station controller.

SingleRAN
NOTE
Figure 9-5 Example of the secure networking for the base station controller

NOTE
Table 9-32 lists the data to be prepared for a certificate request template (the CERTREQ MO
in MML configurations and the CERTREQ or Certificate Request Configuration MO in
CME configurations).
Table 9-32 Data to be prepared for a certificate request template

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.

SingleRAN

Name a
Sou
rce
Common Name USERADDINFO The default value of this parameter

Additional Info. (BSC6900, is .huawei.com.
BSC6910)
Country COUNTRY -
(BSC6900,
BSC6910)
Organization ORG -
(BSC6900,
BSC6910)
Organizational ORGUNIT -
Unit (BSC6900,
BSC6910)
State or Province STATEPROVIN -

CENAME
(BSC6900,
BSC6910)
Locality LOCALITY -
(BSC6900,
BSC6910)
Key Usage KEYUSAGE This parameter can be set to one or more of

(BSC6900, the following values: DIGITAL_SIGNA-
BSC6910) TURE, KEY_ENCIPHERMENT,
KEY_AGREEMENT, and
DATA_ENCIPHERMENT. This
parameter can be set to one or multiple
values. The recommended values are
TURE, the key is used to verify the peer's
digital signature during CMPv2-based
certificate application or update, SSL
authentication, and IKE negotiation. If this
parameter is set to
KEY_ENCIPHERMENT, the key is used
to encrypt the key for data transmission
during SSL-based key exchange.
Signature SIGNALG Secure hash algorithm 256 (SHA256) is

Algorithm (BSC6900, recommended for signing a certificate
BSC6910) request file.

SingleRAN

Name a
Sou
rce
Key Size KEYSIZE -

(BSC6900,
BSC6910)
Local Name LOCALNAME If this parameter is not set, the default value
(BSC6900, of the Common Name field in a certificate
BSC6910) 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 This parameter must be set to the local IP

(BSC6900, address of the device.
BSC6910)
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
Table 9-33 Data to be prepared for the CA

Name a
Sou
rce
Certificate CANAME This parameter is set based on the name of Net

Authority Name (BSC6900, the operator's CA. For example, work
BSC6910) if the values of the C, S, L, O, OU, CN, and plan
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.
For details about the character set of the
PRINTABLE type, see RFC 3642.
Certificate URL Currently, the base station controller

Authority URL (BSC6900, cannot translate domain names. Therefore,
BSC6910) 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 -
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 base plan
station controller uses the O&M IP address
and URL as the source and destination IP
addresses, respectively, for routine
certificate management.
If this parameter is set to
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, respectively, for
routine certificate management.
Certificate UPDSIP - Net

Update Source IP (BSC6900, work
BSC6910) plan
Table 9-34 lists the data to be prepared for a device certificate (the CERTMK MO in MML
configurations and the CERTMK or Device Certificate MO in CME configurations).

SingleRAN
Table 9-34 Data to be prepared for a device certificate

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.
Table 9-35 lists the data to be prepared for an active certificate (the APPCERT MO in MML
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.
Table 9-35 Data to be prepared for an active certificate

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

(BSC6900, work
BSC6910) plan

SingleRAN

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

Name (BSC6900, is used for identity authentication
BSC6910) between the base station controller and
U2000, this parameter must be set to
OPKIDevCert.cer.
l If a Huawei-issued device certificate is
used for identity authentication between
the base station controller and U2000,
this parameter must be set to
usercert.pem or hwusercert.pem.
Table 9-36 lists the data to be prepared for a trust certificate (the TRUSTCERT MO in MML
configurations and the TRUSTCERT or Trusted Certificate MO in CME configurations).
Table 9-36 Data to be prepared for a trust certificate

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

Name (BSC6900, trust certificate must be configured. For the ork
BSC6910) Huawei trust certificate, set this parameter plan
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.
Table 9-37 lists the data to be prepared for a periodic certificate validity check task (the
CERTCHKTSK MO in MML configurations and the CERTCHKTSK or Certificate Validity
Check Task MO in CME configurations).

SingleRAN
Table 9-37 Data to be prepared for a periodic certificate validity check task

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

Validity Period (BSC6900, is ENABLE. ork
Checking BSC6910) plan
Checking Period PERIOD The default value is recommended for this

(day) (BSC6900, parameter.
BSC6910)
Alarm ALMRNG The default value is recommended for this

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

D is CMP.
(BSC6900,
BSC6910)
(Optional) Prepare CRL data if the base station controller needs to obtain the CRL information
from the CA. Table 9-38 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).
Table 9-38 Data to be prepared for a CRL

Name Sour
ce
CRL File Name CERTNAME - Netw

(BSC6900, ork
BSC6910) plan
(Optional) Prepare data related to CRL usage policies. Table 9-39 lists the data to be prepared
for these policies (the CRLPOLICY MO in MML configurations and the CRLPOLICY or
CRL Check Policy MO in CME configurations).

SingleRAN
Table 9-39 Data to be prepared for CRL usage policies

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

Policy (BSC6900, NOVERIFY. Operators can set this ork
BSC6910) parameter based on site requirements. plan
(Optional) Prepare data related to a periodic CRL download task. Table 9-40 lists the data to be
prepared for the task (the CRLTSK MO in MML configurations and the CRLTSK or CRL
Updating Obtaining Task MO in CME configurations).
Table 9-40 Data to be prepared for a periodic CRL download task

Name Sour
ce

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

(BSC6900,BSC6910 CRL server. ork
) plan
Access Method CRLGETMETHOD The recommended value of this parameter

(BSC6900,BSC6910 is LDAP. Set this parameter to FTP only
) when the peer equipment does not support
LDAP.
Port No. PORT -

(BSC6900,BSC6910
)
User Name USR -

(BSC6900,BSC6910
)
Password PWD -
(BSC6900,BSC6910
)

(BSC6900,BSC6910
)

SingleRAN

Name Sour
ce
Using CRL's ISCRLTIME If this parameter is set to ENABLE, the

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

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

(BSC6900,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,BSC6910 CRLGETMETHOD is set to LDAP.
)
Connection CONNMODE This parameter indicates whether to use Netw

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

Peer (BSC6900,BSC6910 authenticate the peer certificate when the ork
) SSL connections are used. This parameter plan
takes effect only when
CRLGETMETHOD 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.
server. Table 9-41 lists the data to be prepared for downloading a certificate file (the DLD
CERTFILE in MML configurations).

SingleRAN
Table 9-41 Data to be prepared for downloading a certificate file

Name Sour
ce
FTP Server IP IP - Netw

ork
plan
User Name USR - Netw

ork
plan
Password PWD - Netw

ork
plan
Source File SRCF - 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
Guage Option GA This parameter determines whether to Netw

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

ork
plan

9-42 lists the data to be prepared for applying for a device certificate based on CMPv2 (the REQ
DEVCERT in MML configurations).
Table 9-42 Data to be prepared for applying for a device certificate based on CMPv2
Name Sourc
e
Certificate CANAME - Netw

Authority ork
Name plan
Certificate File APPCERT - Netw

Name ork
plan

SingleRAN
(Optional) Prepare data to manually trigger a CMPv2-based certificate update. Table 9-43 lists
the data to be prepared for updating a device certificate (the UPD DEVCERT in MML
configurations) based on CMPv2.
Table 9-43 Data to be prepared for updating a device certificate 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. ork
plan
Key Size KEYSIZE - Netw

ork
plan
Using MML Commands

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 update request file to the operator's CA for an operator-issued device

SingleRAN
certificate. Then, the CA returns the operator-issued device certificate to the U2000 by
manual operation.
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.
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.
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.

SingleRAN
LOCALIP="10.120.20.188";
//Adding the operator's CA
//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 external virtual IP address
of the base station controller for certificate application and update. 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_UPD_SIP, UPDSIP="10.120.20.188";
//Setting information required for the base station controller to apply for an
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;

Perform the following steps to observe the PKI feature on the base station controller:
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. The following is an example.

SingleRAN
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.
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.

SingleRAN
----End
9.8.4 Deactivation
----End
9.9 Deployment of PKI on the eCoordinator

deploy the PKI feature on the eCoordinator.
NOTE
Figure 9-6 Example of the secure networking for the eCoordinator

SingleRAN

Prepare the following data before using the U2000 to manually configure the 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, the hyphen (-) indicates that there is no special requirement for the parameter
setting. You can set the parameter based on site requirements.
Table 9-44 lists the data to prepare for a certificate request template (the CERTREQ MO in
MML configurations).
Table 9-44 Data to prepare for a certificate request template

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 The default value of this parameter

Additional Info. O is .huawei.com.
Country COUNTRY -
Organization ORG -
Organizational ORGUNIT -
Unit
State or Province STATEPROVI -

NCENAME
Locality LOCALITY -

SingleRAN

Name Source
Key Usage KEYUSAGE -
Signature SIGNALG SHA1 and SHA256 are supported.

Algorithm SHA256 is recommended. The value of
this parameter must be the same as that
for the peer end.
Key Size KEYSIZE -
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 -
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.
Table 9-45 lists the data to prepare for a device certificate (the CERTMK MO in MML
configurations).

SingleRAN
Table 9-45 Data to prepare for a device certificate
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
l If a Huawei-issued device certificate is 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.
Table 9-46 lists the data to prepare for an active certificate (the APPCERT MO in MML
configurations). Active certificates are device certificates that are currently used by the
eCoordinator.
Table 9-46 Data to prepare for an active certificate
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.
Table 9-47 lists the data to prepare for a trust certificate (the TRUSTCERT MO in MML
configurations).

SingleRAN
Table 9-47 Data to prepare for a trust certificate

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).
Table 9-48 Data to prepare for a periodic certificate validity check task

Name Source
Certificate ISENABLE The recommended value of this Network

Validity parameter is ENABLE. plan
Checking
Checking Period PERIOD The default value is recommended for

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

(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 prepare for a CRL (the CRL MO in MML configurations). For details, see Table
9-49.
l Data to prepare for CRL usage policies (the CRLPOLICY MO in MML configurations).
For details, see Table 9-50.
l Data to prepare for a periodic CRL download task (the CRLTSK MO in MML
configurations). For details, see Table 9-51.

SingleRAN
Table 9-49 Data to prepare for a CRL

Name Source
CRL File Name CERTNAME - Network

plan
Table 9-50 Data to prepare for CRL usage policies

Name Source
CRL Using Policy CRLPOLICY The default value of this parameter is Network
NOVERIFY. Operators can set this plan
parameter based on site requirements.
Table 9-51 Data to prepare for a periodic CRL download task
Parameter Parameter Setting Notes Data

Name ID Source
IP Address IP Set this parameter to the IP address of the Network

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

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 parameter

THOD is FTP. Value LDAP is currently not
supported by the eCoordinator.

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

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

SingleRAN
server. Table 9-52 lists the data to prepare for downloading a certificate file (the CERTFILE
MO in MML configurations).
Parameter Name Parame Setting Notes Data

ter ID Source
Certificate Type CT - Network

plan

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

Name to the same value as SRCF. plan

plan

plan

plan
Guage Option GA This parameter determines whether to report Network

the progress of file downloading. The plan
recommended value of this parameter is Yes
(Yes).
Using the U2000

Perform the following procedures to apply for and activate an operator-issued device certificate:
Step 1 Configure an operator's root certificate. 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.
Step 3 Obtain a CRL. 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.
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 an 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 12 (Optional) Run the MML command ADD CRL to add a CRL.
----End

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 server
is the same as that of the U2000)
DLD CERTFILE:CT=DEVCERT,SRCF="/Cert/
OPKIDevCert.cer",DSTF="OPKIDevCert.cer",IP="10.86.86.86",USR="admin",PWD="*****";

SingleRAN
//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
server is the same as that of the U2000)
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=PROXY;
//(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 9.9.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.
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
9.9.4 Deactivation
This feature does not need to be deactivated.

SingleRAN
9.10 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.
9-7. However, a UMDU cannot be used in a separate-MPT multimode base station.
Figure 9-7 Example of the secure networking for the eGBTS/NodeB/eNodeB/multimode base
station

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

Name Source
Slave Certificate SLVURL This parameter needs to be Network

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

During Site set when PKI redundancy plan
Deployment is enabled.

SingleRAN
(Optional) The following table lists the additional data to prepare 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 Name SLVUSR This parameter needs to be Network

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

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

only when PKI redundancy plan
is enabled.

This section describes only the configurations that are different from those described in section
9.5.2 Initial Configuration.
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 to an interface IP address and for
certificate update to an O&M IP address (such as 10.31.31.188). The following is an
example:
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", ITREQURL="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/";

SingleRAN
//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",SLVURL="http://
10.98.98.98: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.
----End
9.10.4 Deactivation
----End

SingleRAN
9.11 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. It allows configuring the active and standby CA and CRL servers.
If the base station controller fails to update the certificate on one server, it will be automatically
switched over to the other, thereby ensuring the security and validity for the certificate.
Therefore, the CA and CRL servers must be configured before PKI redundancy is enabled.

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

Name Source
Slave SLVURL This parameter needs to be set Network

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

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

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

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

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

No. (BSC6900,BSC6910) when PKI redundancy is plan
enabled.

SingleRAN

This section describes only the configurations that are different from those described in section
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:
//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.
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
9.11.4 Deactivation
----End
9.12 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 9-8 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 9-8 Example of reconstructing a PKI-based secure network into a PKI redundancy network on the eGBTS,
NodeB, eNodeB, or multimode base station
NOTE
9-8.

SingleRAN
General Procedure
The general procedure for PKI configuration modification is as follows: Network

Deployment and Information Collection
l The operator deploys a standby PKI server on the network.
synchronize certificate management data 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, 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 prepare for the standby CA.
Parameter Name Parameter ID Setting Notes Data

Source
Slave Certificate SLVURL This parameter needs to be set Network

Authority URL when PKI redundancy is plan
enabled.

SingleRAN
Parameter Name Parameter ID Setting Notes Data

Source
Slave CA URL SLVINITREQURL This parameter needs to be set Network

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

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

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 This parameter needs to be set Network

enabled.
Slave Port No. SLVPORT This parameter can be set only Network
enabled.
Preparing the Incremental Script

An incremental script is generated based on data of existing base stations and includes
configuration modifications.
For details, see "Using the CME in Batch Configuration for Existing Base Stations" in section
Checking the Base Station Environment

l The base station meets the hardware requirements described in section 9.3 Hardware
Planning.
l The license for the PKI redundancy feature has been activated on the base station.
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.

SingleRAN
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 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 9.10.3 Activation Observation.
9.13 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 9-9 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 9-9 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 The operator deploys a standby PKI server on the network.
synchronize certificate management data 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 prepare for the standby CA.

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

Authority URL (BSC6900,BSC6910) when PKI redundancy is enabled. plan

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

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

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

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

enabled.
Slave Port No. SLVPORT This parameter can be set only Network
enabled.
Preparing the Incremental Script

For details, see "Using the CME in Batch Configuration for Existing Base Station Controllers"
in section 9.8.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

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.
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.

SingleRAN
Activation Observation
9.14 Performance Monitoring

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

The PKI feature does not require performance optimization.
9.16 Troubleshooting
9.16.1 Base Station Troubleshooting

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.
9.16.2 Base Station Controller/eCoordinator Troubleshooting

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

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

SingleRAN
of control from the U2000 if faults occur on the base station controller/eCoordinator side, for
example, the certificate is damaged.
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
PKI Feature Parameter Description 10 Parameters
10 Parameters
Table 10-1 Parameters
Parame NE MML Feature Feature Description

ter ID Comma ID Name
nd
AUTH BTS390 SET MRFD- Security Meaning: If Authentication Mode to is set to PEER
MODE 0, SSLAU 210305 Manage (Verify Peer Certificate), the NE must verify the
BTS390 THMO ment certificate of the U2000 or LMT during SSL connection
0 DE GBFD-1 setup. If the certificate verification fails, the SSL
WCDM 13522 Encrypt connection cannot be set up.
LST ed
A, SSLCO LBFD-0 GUI Value Range: NONE(Verify None), PEER(Verify
BTS390 Network
NF 04003 Manage Peer Certificate)
0 LTE
ment Unit: None
Security Actual Value Range: NONE, PEER

Socket Default Value: NONE(Verify None)
Layer
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 Algorithm 5 (MD5) or Secure Hash Algorithm 256
WCDM CERTFI 0 (PKI) (SHA256).
A, LE 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 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
Actual Value Range: SHA1, MD5, SHA256
Default Value: SHA256(SHA256)
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
Actual Value Range: SHA1, MD5, SHA256

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, CA
BTS390 MOD TDLOF Infrastru URL During Site Deployment, and Source IP for
0 CA D-00301 cture Applying for a Certificate During Site Deployment.
WCDM 0 (PKI) When the parameter is set to DEFAULT_MODE, the
A, LST CA UPDSIP, INITREQURL, INITREQSIP and
BTS390 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 uses
PKI the effective IP address of the local OM channel as the
Support 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)
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), SSL(SSL)
0 LST
WCDM Unit: None
CRLTS
A, K Actual Value Range: PLAINTEXT, SSL
BTS390 Default Value: PLAINTEXT(Plaintext)
0 LTE

SingleRAN

nd
CONN BSC690 ADD WRFD- RNC Meaning: Mode of connection to the CRL server.
MODE 0 CRLTS 160276 Supporti GUI Value Range: PLAINTEXT(Plaintext), SSL(SSL)
K ng PKI
Unit: None
Actual Value Range: PLAINTEXT, SSL
Default Value: PLAINTEXT(Plaintext)
CONN BSC691 ADD WRFD- RNC Meaning: Mode of connection to the CRL server.
MODE 0 CRLTS 160276 Supporti GUI Value Range: PLAINTEXT(Plaintext), SSL(SSL)
K ng PKI
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 used.
BTS390 K GUI Value Range: DISABLE(Disable), ENABLE
0 LST (Enable)
WCDM CRLTS
A, Unit: None
K
BTS390 Actual Value Range: DISABLE, ENABLE
0 LTE Default Value: DISABLE(Disable)
AUTHP BSC690 ADD WRFD- RNC Meaning: Whether to authenticate the identity of the
EER 0 CRLTS 160276 Supporti peer end.
K ng PKI GUI Value Range: DISABLE(Disable), ENABLE
(Enable)
Unit: None
Actual Value Range: DISABLE, ENABLE
Default Value: DISABLE(Disable)
AUTHP BSC691 ADD WRFD- RNC Meaning: Whether to authenticate the identity of the
EER 0 CRLTS 160276 Supporti peer end.
K ng PKI GUI Value Range: DISABLE(Disable), ENABLE
(Enable)
Unit: None

SingleRAN

nd
SLVUR BTS390 ADD None None Meaning: Indicates the slave URL of the CA. The URL
L 0, CA can be either an HTTP or HTTPS URL. The IP address
BTS390 MOD in the URL must be a valid IP address. The default port
0 CA number is 80 for HTTP or 443 for HTTPS. If the
WCDM certificate fails to be obtained using the CA URL, the
A, LST CA slave CA URL can be used to obtain the certificate only
BTS390 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)
SLVINI BTS390 ADD None None Meaning: Indicates the slave URL of the CA that is used
TREQU 0, CA during site deployment. The URL can be either an
RL BTS390 MOD HTTP or HTTPS URL. In the URL, the IP address must
0 CA be a valid IP address, and the default port number is 80
WCDM for HTTP or 443 for HTTPS. If the certificate fails to
A, LST CA be obtained using the CA URL during site deployment,
BTS390 the slave CA URL during site deployment can be used
0 LTE to obtain the certificate only when this parameter is set.
GUI Value Range: 0~128 characters
Unit: None
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 be
BTS390 K obtained using the IP address of the master CRL server,
0 LST the IP address of the slave CRL server is used only when
WCDM CRLTS this parameter is not set to 0.0.0.0. If the IP address of
A, K the slave CRL server is used, the slave port number,
BTS390 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
Default Value: 0.0.0.0

SingleRAN

nd
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
A, K Actual Value Range: 0~65535
BTS390 Default Value: 389
0 LTE
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
A, K Actual Value Range: 0~255 characters
BTS390 Default Value: NULL(empty string)
0 LTE
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
SLVUR BSC690 ADD WRFD- RNC Meaning: URL of the secondary CA.
L 0 CA 160277 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 BSC691 ADD WRFD- RNC Meaning: URL of the secondary CA.
L 0 CA 160277 Supporti GUI Value Range: 1~128 characters
MOD ng PKI
Redunda Unit: None
CA
ncy Actual Value Range: 1~128 characters
Default Value: None
SLVIP BSC690 ADD WRFD- RNC Meaning: IP address of the secondary CRL server.
0 CRLTS 160277 Supporti GUI Value Range: Valid IP Address
K ng PKI
Redunda Unit: None
ncy Actual Value Range: Valid IP Address

SingleRAN

nd
SLVIP BSC691 ADD WRFD- RNC Meaning: IP address of the secondary CRL server.
0 CRLTS 160277 Supporti GUI Value Range: Valid IP Address
K ng PKI
Redunda Unit: None
ncy Actual Value Range: Valid IP Address
SLVPO BSC690 ADD WRFD- RNC Meaning: Port number of the standby CRL server. This
RT 0 CRLTS 160277 Supporti 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
Actual Value Range: 0~65535
Default Value: None
SLVPO BSC691 ADD WRFD- RNC Meaning: Port number of the standby CRL server. This
RT 0 CRLTS 160277 Supporti 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 BSC690 ADD WRFD- RNC Meaning: User name for accessing the secondary CRL
R 0 CRLTS 160277 Supporti server.
K ng PKI GUI Value Range: 0~128 characters
Redunda
ncy Unit: None
Default Value: None

SingleRAN

nd
SLVUS BSC691 ADD WRFD- RNC Meaning: User name for accessing the secondary CRL
R 0 CRLTS 160277 Supporti server.
Redunda
ncy Unit: None
Default Value: None
SLVPW BSC690 ADD WRFD- RNC Meaning: Password for accessing the secondary CRL
D 0 CRLTS 160277 Supporti server.
Redunda
ncy Unit: None
Default Value: None
SLVPW BSC691 ADD WRFD- RNC Meaning: Password for accessing the secondary CRL
D 0 CRLTS 160277 Supporti server.
Redunda
ncy Unit: None
Default Value: 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 CRL-
BTS390 LICY TDLOF Infrastru based certificate checks. (2) The BS performs CRL-
0 LST D-00301 cture based certificate checks and reports alarms when the
WCDM CRLPO 0 (PKI) checks fail. (3) The BS performs CRL-based certificate
A, LICY checks, and it reports alarms and disconnects from the
BTS390 GBFD-1 BTS peer device when the checks fail. The value
0 LTE 13526 Supporti NOVERIFY indicates that the BS does not perform
ng PKI CRL-based certificate checks on the peer device. The
WRFD-
140210 NodeB value ALARM indicates that the BS performs CRL-
PKI based certificate checks on the peer device and reports
Support 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)
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

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
AUTH BSC690 SET None None Meaning: Authentication mode for SSL connections.
MODE 0 SSLAU GUI Value Range: NONE(Verify None), PEER(Verify
THMO Peer Certificate)
DE
Unit: None
Actual Value Range: NONE, PEER
Default Value: NONE(Verify None)
AUTH BSC691 SET None None Meaning: Authentication mode for SSL connections.
MODE 0 SSLAU GUI Value Range: NONE(Verify None), PEER(Verify
THMO Peer Certificate)
DE
Unit: None
Actual Value Range: NONE, PEER
Default Value: NONE(Verify None)
DEPLO BTS390 SET LOFD-0 Public Meaning: Indicates the deployment position of a digital
YTYPE 0, CERTD 03010 / Key certificate. If this parameter is set to DEFAULT, the
BTS390 EPLOY TDLOF Infrastru certificate is configured on the main control board. If
0 LST D-00301 cture this parameter is set to SPECIFIC, the certificate is
WCDM CERTD 0 (PKI) configured on the board in the specified slot. If this
A, EPLOY parameter is set to NULL, no certificate is configured
BTS390 GBFD-1 BTS on the BS.
0 LTE 13526 Supporti
ng PKI GUI Value Range: DEFAULT(Default), SPECIFIC
WRFD- (Specific), NULL(NULL)
140210 NodeB Unit: None
PKI
Support Actual Value Range: DEFAULT, SPECIFIC, NULL
Default Value: DEFAULT(Default)

SingleRAN

nd
ISENA BTS390 SET LOFD-0 Public Meaning: Indicates whether a task of certificate validity
BLE 0, CERTC 03010 / Key checking is started.
BTS390 HKTSK TDLOF Infrastru GUI Value Range: DISABLE(Disable), ENABLE
0 LST D-00301 cture (Enable)
WCDM CERTC 0 (PKI)
A, Unit: None
HKTSK GBFD-1 BTS
BTS390 Actual Value Range: DISABLE, ENABLE
ng PKI Default Value: ENABLE(Enable)
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 eNodeB detects that the interval
BTS390 HKTSK TDLOF Infrastru between its current time and the expiration date of an
0 LST D-00301 cture activated device certificate is shorter than the threshold,
WCDM CERTC 0 (PKI) an Imminent Certificate Expiry alarm is reported.
A, HKTSK GUI Value Range: 7~180
BTS390 GBFD-1 BTS
0 LTE 13526 Supporti Unit: day
ng PKI Actual Value Range: 7~180
WRFD-
140210 NodeB Default Value: 30
PKI
Support
UPDAT BTS390 SET LOFD-0 Public Meaning: Indicates the method for updating a certificate
EMETH 0, CERTC 03010 / Key that has expired or is about to expire. There are three
OD BTS390 HKTSK TDLOF Infrastru methods: PROXY, CMP and MANUAL. If the PROXY
0 LST D-00301 cture method is used, the BS uses the U2000 as the proxy to
WCDM CERTC 0 (PKI) update the certificate from the Certificate Authority
A, HKTSK (CA). If the CMP method is used, the BS directly
BTS390 GBFD-1 BTS updates the certificate from the CA. If the MANUAL
0 LTE 13526 Supporti method is used, the certificate needs to be updated
ng PKI manually instead of automatically.
WRFD-
140210 NodeB GUI Value Range: PROXY(Proxy), CMP(CMP),
PKI MANUAL(Manual)
Support Unit: None
Actual Value Range: PROXY, CMP, MANUAL
Default Value: CMP(CMP)

SingleRAN

nd
UPDAT BSC690 SET WRFD- RNC Meaning: Update policy for an expired certificate. If
EMETH 0 CERTC 160276 Supporti PROXY or MANUAL is selected, the system will
OD 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
Default Value: PROXY(Proxy)
UPDAT BSC691 SET WRFD- RNC Meaning: Update policy for an expired certificate. If
EMETH 0 CERTC 160276 Supporti PROXY or MANUAL is selected, the system will
OD 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
Default Value: PROXY(Proxy)

SingleRAN

nd
APPCE BTS390 ADD LOFD-0 Public Meaning: Indicates the file name of a device certificate.
RT 0, CERTM 03010 / Key The file name cannot include any of the following
BTS390 K TDLOF Infrastru characters: backslashes (\), slashes (/), colons (:),
0 DSP D-00301 cture asterisks (*), question marks (?), double quotation
WCDM CERTM 0 (PKI) marks ("), left angle brackets (<), right angle brackets
A, K (>), and bars (|).
BTS390 GBFD-1 BTS
MOD 13526 Supporti GUI Value Range: 1~64 characters
0 LTE
CERTM ng PKI Unit: None
K WRFD-
140210 NodeB Actual Value Range: 1~64 characters
REQ PKI Default Value: None
DEVCE Support
RT
RMV
CERTM
K
UPD
DEVCE
RT
DSP
CMPSE
SSION
LST
CERTM
K
KEYSIZ BTS390 MOD LOFD-0 Public Meaning: Indicates the length of a key, which can be
E 0, CERTR 03010 / Key 1024 bits or 2048 bits.
BTS390 EQ TDLOF Infrastru GUI Value Range: KEYSIZE1024(KEYSIZE1024),
0 UPD D-00301 cture KEYSIZE2048(KEYSIZE2048)
WCDM DEVCE 0 (PKI)
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
0 LST D-00301 cture
WCDM 0 (PKI) Unit: None
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
TMETH 0, CRLTS 03010 / Key periodically obtains a CRL.
OD BTS390 K TDLOF Infrastru GUI Value Range: FTP(FTP), LDAP(LDAP)
0 LST D-00301 cture
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
0 LST D-00301 cture
CRLTS
BTS390 GBFD-1 BTS
13526 Supporti Default Value: NULL(empty string)
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
SEARC BSC690 ADD WRFD- RNC Meaning: Distinct name of CRL files saved on the
HDN 0 CRLTS 160276 Supporti LDAP server.
Unit: None
Default Value: None

SingleRAN

nd
SEARC BSC691 ADD WRFD- RNC Meaning: Distinct name of CRL files saved on the
HDN 0 CRLTS 160276 Supporti LDAP server.
Unit: None
Default Value: None
PORT BTS390 ADD LOFD-0 Public Meaning: Indicates the port number of an LDAP server.
0, CRLTS 03010 / Key GUI Value Range: 0~65535
BTS390 K TDLOF Infrastru
0 D-00301 cture Unit: None
LST
WCDM CRLTS 0 (PKI) Actual Value Range: 0~65535
A, K Default Value: 389
BTS390 GBFD-1 BTS
ng PKI
WRFD-
140210 NodeB
PKI
Support
PORT BSC690 ADD MRFD- Security Meaning: Number of the port used by the protocol. This
0 CRLTS 210305 Manage 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 BSC691 ADD MRFD- Security Meaning: Number of the port used by the protocol. This
0 CRLTS 210305 Manage 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
ISCRLT BTS390 ADD LOFD-0 Public Meaning: Indicates whether to update the CRL at the
IME 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 ENABLE, the BS automatically updates the CRL when
WCDM CRLTS 0 (PKI) the next update time specified in the CRL arrives. If this
A, K parameter is set to DISABLE, the BS automatically
BTS390 GBFD-1 BTS updates the CRL based on the configured updating
0 LTE 13526 Supporti period.
ng PKI
WRFD- GUI Value Range: DISABLE(Disable), ENABLE
140210 NodeB (Enable)
PKI Unit: None
Support
ISCRLT BSC690 ADD MRFD- Security Meaning: Whether the next update time in the CRL is
IME 0 CRLTS 210305 Manage used. If this parameter is set to ENABLE(Enable), the
K ment CRL file will be updated at the next update time
recorded in the CRL file.
GUI Value Range: DISABLE(Disable), ENABLE
(Enable)
Unit: None
ISCRLT BSC691 ADD MRFD- Security Meaning: Whether the next update time in the CRL is
IME 0 CRLTS 210305 Manage used. If this parameter is set to ENABLE(Enable), the
K ment CRL file will be updated at the next update time
recorded in the CRL file.
GUI Value Range: DISABLE(Disable), ENABLE
(Enable)
Unit: None

SingleRAN

nd
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 GUI Value Range: 8~240
WCDM CRLTS 0 (PKI)
A, Unit: h
K GBFD-1 BTS
BTS390 Actual Value Range: 8~240
ng PKI Default Value: 24
WRFD-
140210 NodeB
PKI
Support
PERIO BSC690 ADD MRFD- Security Meaning: Interval for updating the CRL (unit: hour). If
D 0 CRLTS 210305 Manage ISCRLTIME is set to DISABLE(Disable), the CRL is
K ment updated at the interval specified by this parameter.
Unit: h
Default Value: 24
PERIO BSC691 ADD MRFD- Security Meaning: Interval for updating the CRL (unit: hour). If
D 0 CRLTS 210305 Manage ISCRLTIME is set to DISABLE(Disable), the CRL is
K ment updated at the interval specified by this parameter.
Unit: h
Default Value: 24

SingleRAN

nd
ENCRY BTS390 SET MRFD- Security Meaning: Indicates the transmission encryption mode
MODE 0, FTPSCL 210305 Manage of the FTP client. If this parameter is set to Auto, the
BTS390 T 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 FTPSCL switches the encryption mode to retransmit data in
A, Socket plaintext.Therefore, setting this parameter to Auto may
T Layer
BTS390 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)
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 CA TDLOF Infrastru backslashes (\), slashes (/), colons (:), asterisks (*),
0 D-00301 cture question marks (?), double quotation marks ("), left
WCDM MOD 0 (PKI) angle brackets (<), right angle brackets (>), bars (|) and
A, CA underscores (_). Otherwise, an error occurs when you
BTS390 REQ GBFD-1 BTS run the REQ DEVCERT command to apply for a device
0 LTE DEVCE 13526 Supporti certificate. For the valid characters of the CA name, see
RT ng PKI IETF RFC5280.
WRFD-
RMV 140210 NodeB GUI Value Range: 1~127 characters
CA PKI Unit: None
Support
Default Value: None
CANA BSC690 ADD WRFD- RNC Meaning: Name of the CA.

ME 0 CA 160276 Supporti GUI Value Range: 0~127 characters
MOD ng PKI
Unit: None
CA
RMV
CA Default Value: None
CANA BSC691 ADD WRFD- RNC Meaning: Name of the CA.

ME 0 CA 160276 Supporti GUI Value Range: 0~127 characters
MOD ng PKI
Unit: None
CA
RMV
CA Default Value: None

SingleRAN

nd
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 number is 80 for HTTP or 443 for HTTPS.
WCDM 0 (PKI) GUI Value Range: 1~128 characters
A, LST CA
BTS390 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
URL BSC690 ADD WRFD- RNC Meaning: URL of the CA. The URL can be either an
0 CA 160276 Supporti HTTP or HTTPS URL. The IP address in the URL must
MOD ng PKI be a valid IPv4 address. The default port number is 80
CA for an HTTP URL and 443 for an HTTPS URL.
Unit: None
Default Value: None
URL BSC691 ADD WRFD- RNC Meaning: URL of the CA. The URL can be either an
0 CA 160276 Supporti HTTP or HTTPS URL. The IP address in the URL must
MOD ng PKI be a valid IPv4 address. The default port number is 80
CA 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 must
0 CA D-00301 cture be a valid IP address, and the default port number is 80
WCDM 0 (PKI) for HTTP or 443 for HTTPS. This parameter is
A, LST CA mandatory when the CA uses different URLs during site
BTS390 GBFD-1 BTS 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

SingleRAN

nd
SIGNA BTS390 ADD LOFD-0 Public Meaning: Indicates the signature algorithm for message
LG 0, CA 03010 / Key of CMP. The signature algorithm can be Secure Hash
BTS390 MOD TDLOF Infrastru Algorithm 1 (SHA1) or Secure Hash Algorithm 256
0 CA D-00301 cture (SHA256).
WCDM 0 (PKI) GUI Value Range: SHA1(SHA1), SHA256(SHA256)
A, LST CA
0 LTE 13526 Supporti Actual Value Range: SHA1, SHA256
ng PKI
WRFD- Default Value: SHA256(SHA256)
140210 NodeB
PKI
Support
SIGNA BSC690 ADD WRFD- RNC Meaning: Signature algorithm used by the Certificate
LG 0 CA 160276 Supporti Management Protocol (CMP) to request for a
MOD ng PKI certificate. The algorithm includes SHA1 and SHA256.
CA GUI Value Range: SHA1(SHA1), SHA256(SHA256)
Unit: None
Actual Value Range: SHA1, SHA256
SIGNA BSC691 ADD WRFD- RNC Meaning: Signature algorithm used by the Certificate
LG 0 CA 160276 Supporti Management Protocol (CMP) to request for a
MOD ng PKI certificate. The algorithm includes SHA1 and SHA256.
CA GUI Value Range: SHA1(SHA1), SHA256(SHA256)
Unit: None
Actual Value Range: SHA1, SHA256
KEYSIZ BSC690 MOD MRFD- Security Meaning: Size of the key used by the device certificate
E 0 CERTR 210305 Manage file.
EQ ment GUI Value Range: KEYSIZE1024(1024 Bits),
KEYSIZE2048(2048 Bits)
Unit: None
Actual Value Range: KEYSIZE1024, KEYSIZE2048
Default Value: KEYSIZE2048(2048 Bits)

SingleRAN

nd
KEYSIZ BSC691 MOD MRFD- Security Meaning: Size of the key used by the device certificate
E 0 CERTR 210305 Manage file.
EQ ment GUI Value Range: KEYSIZE1024(1024 Bits),
KEYSIZE2048(2048 Bits)
Unit: None
Actual Value Range: KEYSIZE1024, KEYSIZE2048
Default Value: KEYSIZE2048(2048 Bits)
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 KEY_ENCIPHERMENT (key encryption), and
WCDM CERTFI 0 (PKI) DIGITAL_SIGNATURE (digital signature). This
A, LE parameter can be set to one or multiple values.
BTS390 GBFD-1 BTS
LST 13526 Supporti GUI Value Range: DATA_ENCIPHERMENT
0 LTE (DATA_ENCIPHERMENT), DIGITAL_SIGNA-
CERTR ng PKI
EQ WRFD- TURE(DIGITAL_SIGNATURE),
140210 NodeB KEY_AGREEMENT(KEY_AGREEMENT),
PKI KEY_ENCIPHERMENT(KEY_ENCIPHERMENT)
Support 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 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.
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 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
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, so as to verify
0 LST D-00301 cture the peer's identification in IKE negotiation. If this
WCDM CERTFI 0 (PKI) parameter is not configured, the BS automatically uses
A, LE 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 BSC690 MOD MRFD- Security Meaning: Local name of the device. If this parameter is
NAME 0 CERTR 210305 Manage not configured, set this parameter to the same value as
EQ ment "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 BSC691 MOD MRFD- Security Meaning: Local name of the device. If this parameter is
NAME 0 CERTR 210305 Manage not configured, set this parameter to the same value as
EQ ment "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 (/), colons
0 DSP D-00301 cture (:), asterisks (*), question marks (?), double quotation
WCDM TRUST 0 (PKI) marks ("), left angle brackets (<), right angle brackets
A, CERT (>), 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
CERTN BSC690 ADD MRFD- Security Meaning: File name of the trust certificate or certificate
AME 0 TRUST 210305 Manage chain.
CERT ment GUI Value Range: 1~64 characters
RMV Unit: None
TRUST
CERT Actual Value Range: 1~64 characters
Default Value: None
CERTN BSC691 ADD MRFD- Security Meaning: File name of the trust certificate or certificate
AME 0 TRUST 210305 Manage chain.
CERT ment GUI Value Range: 1~64 characters
RMV Unit: None
TRUST
CERT Actual Value Range: 1~64 characters
Default Value: None

SingleRAN

nd
IP BSC690 ADD MRFD- Security Meaning: IP address of the server where the CRL file is
0 CRLTS 210305 Manage saved.
K ment GUI Value Range: Valid IP Address
Unit: None
Actual Value Range: Valid IP Address
Default Value: None
IP BSC691 ADD MRFD- Security Meaning: IP address of the server where the CRL file is
0 CRLTS 210305 Manage saved.
K ment GUI Value Range: Valid IP Address
Unit: None
Default Value: None
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.
0 LST D-00301 cture
CRLTS
BTS390 GBFD-1 BTS
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support
USR BSC690 ADD MRFD- Security Meaning: User name for logging in to the server where
0 CRLTS 210305 Manage the CRL file is saved. Parameters USR and PWD must
K ment be specified or left unspecified at the same time. If USR
is not specified, the RNC connects to a specified server
using an anonymous account and a blank password.
Unit: None
Default Value: None

SingleRAN

nd
USR BSC691 ADD MRFD- Security Meaning: User name for logging in to the server where
0 CRLTS 210305 Manage the CRL file is saved. Parameters USR and PWD must
K ment be specified or left unspecified at the same time. If USR
is not specified, the RNC connects to a specified server
using an anonymous account and a blank password.
Unit: None
Default Value: None
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
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
FILENA BTS390 ADD LOFD-0 Public Meaning: Indicates the file name of a CRL. File name
ME 0, CRLTS 03010 / Key with path is supported when the access method is set to
BTS390 K TDLOF Infrastru FTP.
0 LST D-00301 cture GUI Value Range: 1~128 characters
WCDM CRLTS 0 (PKI)
A, Unit: None
K GBFD-1 BTS
BTS390 Actual Value Range: 1~128 characters
ng PKI Default Value: None
WRFD-
140210 NodeB
PKI
Support
FILENA BSC690 ADD MRFD- Security Meaning: Name of the CRL file on the server. The file
ME 0 CRLTS 210305 Manage name can contain the save path of this file on the server.
K ment 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
FILENA BSC691 ADD MRFD- Security Meaning: Name of the CRL file on the server. The file
ME 0 CRLTS 210305 Manage name can contain the save path of this file on the server.
K ment 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 WRFD- RNC Meaning: Method for obtaining the CRL file.
TMETH 0 CRLTS 160276 Supporti GUI Value Range: FTP(FTP), LDAP(LDAP)
OD K ng PKI
Unit: None
Actual Value Range: FTP, LDAP
Default Value: FTP(FTP)

SingleRAN

nd
CRLGE BSC691 ADD WRFD- RNC Meaning: Method for obtaining the CRL file.
TMETH 0 CRLTS 160276 Supporti GUI Value Range: FTP(FTP), LDAP(LDAP)
OD K ng PKI
Unit: None
Actual Value Range: FTP, LDAP
Default Value: FTP(FTP)
COMM BTS390 MOD LOFD-0 Public Meaning: Indicates the common name of the certificate
NAME 0, CERTR 03010 / Key request file, which can be the electronic serial number
BTS390 EQ TDLOF Infrastru (ESN), media access control (MAC) address, or IP
0 LST D-00301 cture address of a board.
WCDM CERTR 0 (PKI) GUI Value Range: ESN(ESN), MAC(MAC), IP(IP)
A, EQ
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 parameter
0 LST D-00301 cture to compose a complete common name for a certificate
WCDM CERTR 0 (PKI) request file. The default value is .huawei.com. A space
A, EQ is not supported before the value of this parameter, that
BTS390 GBFD-1 BTS is, a space is not supported before the character string.
0 LTE 13526 Supporti However, to meet requirements of consistency checks
ng PKI performed by some CA servers to the certificate
WRFD-
140210 NodeB common name in a certificate request packet and that in
PKI a Huawei device certificate, the certificate common
Support 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
COUNT BTS390 MOD LOFD-0 Public Meaning: Indicates the country where a BS is located.
RY 0, CERTR 03010 / Key GUI Value Range: 0~0,2~2 characters
BTS390 EQ TDLOF Infrastru
LST
WCDM CERTR 0 (PKI) 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 (PKI) Actual Value Range: 0~64 characters
BTS390 GBFD-1 BTS
ng PKI
WRFD-
140210 NodeB
PKI
Support
ORGUN BTS390 MOD LOFD-0 Public Meaning: Indicates the organization unit that owns a
IT 0, CERTR 03010 / Key BS.
BTS390 EQ TDLOF Infrastru GUI Value Range: 0~64 characters
0 LST D-00301 cture
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
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 (PKI) Actual Value Range: 0~128 characters
BTS390 GBFD-1 BTS
ng PKI
WRFD-
140210 NodeB
PKI
Support
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
CERTR
A, EQ Actual Value Range: Valid IP address
BTS390 GBFD-1 BTS
13526 Supporti Default Value: 0.0.0.0
0 LTE
ng PKI
WRFD-
140210 NodeB
PKI
Support

SingleRAN

nd
UPDSIP BTS390 ADD LOFD-0 Public Meaning: Indicates the source address for certificate
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 application. If the source address for certificate
WCDM 0 (PKI) application in site deployment is not configured, the
A, LST CA address will be used as the source address for acquiring
BTS390 GBFD-1 BTS 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 the
BTS390 MOD TDLOF Infrastru CA and to initially obtain a certificate. This parameter
0 CA D-00301 cture is mandatory when the CA uses different URLs in the
WCDM 0 (PKI) following scenarios:
A, LST CA
BTS390 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 IKEPEER MO is set to Appcert, the device certificate
WCDM APPCE 0 (PKI) being used during IKE negotiation is the certificate
A, RT configured in APPCERT MO. When APPTYPE is set
BTS390 GBFD-1 BTS to SSL, indicates the device certificate being used
0 LTE MOD 13526 Supporti during SSL connection.
APPCE ng PKI
RT WRFD- GUI Value Range: IKE(IKE), SSL(SSL)
140210 NodeB Unit: None
TST PKI
APPCE Support Actual Value Range: IKE, SSL
RT Default Value: None
LST
CERTT
YPE

SingleRAN

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

SingleRAN

nd
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
0 LST D-00301 cture
CRLTS
A, K Actual Value Range: 0~5
BTS390 GBFD-1 BTS
RMV 13526 Supporti Default Value: None
0 LTE
CRLTS ng PKI
K WRFD-
140210 NodeB
PKI
Support
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 the
0 LST D-00301 cture source IP address to access the CRL server for updating
WCDM CRLTS 0 (PKI) 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
COMM BSC690 MOD MRFD- Security Meaning: Common name of the certificate request file.
NAME 0 CERTR 210305 Manage 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
Default Value: ESN(ESN)
COMM BSC691 MOD MRFD- Security Meaning: Common name of the certificate request file.
NAME 0 CERTR 210305 Manage 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
Default Value: ESN(ESN)

SingleRAN

nd
USERA BSC690 MOD MRFD- Security Meaning: Equipment description in the generic
DDINF 0 CERTR 210305 Manage certificate name. The parameter value can contain only
O EQ ment 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 BSC691 MOD MRFD- Security Meaning: Equipment description in the generic
DDINF 0 CERTR 210305 Manage certificate name. The parameter value can contain only
O EQ ment letters, digits, spaces, and the following characters: ()
+-./:?. The original parameter settings remain
entered.
Unit: None
Default Value: None
COUNT BSC690 MOD MRFD- Security Meaning: Country where the device is located. The
RY 0 CERTR 210305 Manage parameter value must be two English characters or one
EQ ment space. The original parameter settings remain
entered.
Unit: None
Default Value: None

SingleRAN

nd
COUNT BSC691 MOD MRFD- Security Meaning: Country where the device is located. The
RY 0 CERTR 210305 Manage parameter value must be two English characters or one
EQ ment space. The original parameter settings remain
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
ORG BSC691 MOD MRFD- Security Meaning: Organization to which the device belongs.
0 CERTR 210305 Manage The parameter value can contain only letters, digits,
Unit: None
Default Value: None
ORGUN BSC690 MOD MRFD- Security Meaning: Organization unit to which the device
IT 0 CERTR 210305 Manage belongs. The parameter value can contain only letters,
EQ ment digits, spaces, and the following characters: ()+-./:?. The
Unit: None
Default Value: None

SingleRAN

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

SingleRAN

nd
LOCAL BSC691 MOD MRFD- Security Meaning: Specific position where the device is located.
ITY 0 CERTR 210305 Manage The parameter value can contain only letters, digits,
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 WRFD- RNC Meaning: Configuration mode of the source IP address
0 CA 160276 Supporti that is used for updating the certificate. When this
MOD ng PKI parameter is set to DEFAULT_MODE, the source IP
CA 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.
(CFG_UPD_SIP)
Unit: None
CFG_UPD_SIP
(DEFAULT_MODE)
MODE BSC691 ADD WRFD- RNC Meaning: Configuration mode of the source IP address
0 CA 160276 Supporti that is used for updating the certificate. When this
MOD ng PKI parameter is set to DEFAULT_MODE, the source IP
CA 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.
(CFG_UPD_SIP)
Unit: None
CFG_UPD_SIP
(DEFAULT_MODE)

SingleRAN

nd
UPDSIP BSC690 ADD WRFD- RNC Meaning:

0 CA 160276 Supporti Source IP address used for certificate update. The
MOD ng PKI setting of this parameter must ensure proper
CA communication between the OMU and the CA. If not,
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
UPDSIP BSC691 ADD WRFD- RNC Meaning:

0 CA 160276 Supporti Source IP address used for certificate update. The
MOD ng PKI setting of this parameter must ensure proper
CA communication between the OMU and the CA. If not,
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 CERTM 210305 Manage GUI Value Range: 1~64 characters
K ment
Unit: None
RMV
CERTM Actual Value Range: 1~64 characters
K Default Value: None
APPCE BSC691 ADD MRFD- Security Meaning: File name of the device certificate file.
RT 0 CERTM 210305 Manage GUI Value Range: 1~64 characters
K ment
Unit: None
RMV
CERTM Actual Value Range: 1~64 characters
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 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
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

SingleRAN

nd
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
Default Value: ENABLE(Enable)
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
Default Value: ENABLE(Enable)
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
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

SingleRAN

nd
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
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
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

SingleRAN

nd
SIP BSC690 ADD WRFD- RNC Meaning: Source IP address for downloading CRL files.
0 CRLTS 160276 Supporti The setting of this parameter must ensure proper
K ng PKI communication between the OMU and the CA. If not,
Unit: None
SIP BSC691 ADD WRFD- RNC Meaning: Source IP address for downloading CRL files.
0 CRLTS 160276 Supporti The setting of this parameter must ensure proper
K ng PKI communication between the OMU and the CA. If not,
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 (Sran10.1 02)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Pki (Sran10.1 02)

Загружено:

Авторское право:

Доступные форматы

SingleRAN

PKI Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 02 (2015-05-20) Huawei Proprietary and Confidential i

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

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

5 Certificate Management and Application Scenarios............................................................15

Issue 02 (2015-05-20) Huawei Proprietary and Confidential ii

5.5.4 Certificate Update......................................................................................................................................................26

6 CMPv2-based Certificate Management..................................................................................32

Issue 02 (2015-05-20) Huawei Proprietary and Confidential iii

9.10.2 Initial Configuration..............................................................................................................................................120

Issue 02 (2015-05-20) Huawei Proprietary and Confidential iv

1 About This Document

This document covers the following features:

l GBFD-113526 BTS Supporting PKI

Includes FDD and Includes FDD Only Includes TDD Only

LTE LTE FDD LTE TDD

eNodeB LTE FDD eNodeB LTE TDD eNodeB

eRAN LTE FDD eRAN LTE TDD eRAN

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 1

Table 1-1 provides the definitions of base stations.

Table 1-1 Base station definitions

Base Station Definition

eGBTS eGBTS refers to a base station deployed with a GTMUb, UMPT_G, or

NodeB NodeB refers to a base station deployed with a WMPT, UMPT_U, or

eNodeB eNodeB refers to a base station deployed with an LMPT, UMPT_L,

Separate-MPT Separate-MPT multimode base station refers to a base station on which

1.2 Intended Audience

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 2

l Need to understand the features described herein

1.3 Change History

Change Change Description Paramete

Feature None None

Editorial Added the following descriptions to 5.5.3 Certificate Validity None

Change Change Description Paramete

Feature None None

Editorial Added descriptions of precautions to be taken before manually None

SRAN10.1 Draft A (2015-01-15)

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 3

Change Change Description Paramete

Changed the authentication method of SSL certificate testing. None

Enhanced the signature algorithm used for device certificates. None

Modified the method of handling intermittent link disconnection None

Editorial Added PKI descriptions for the eCoordinator. None

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 4

l Serial number and validity period of the certificate

Huawei base stations/base station controllers/eCoordinators use a PKI-based end-to-end

For Huawei products, digital certificates apply to the following scenarios:

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 5

Figure 2-1 Example of networking that uses digital certificates

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 6

Figure 3-1 PKI system

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 7

l Approves or rejects certificate applications and issues certificates for approved

Figure 3-2 Example of the CA system architecture

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 8

Base station controllers and eCoordinators do not support cross-certificates.

A CA incorporates the functions of an RA, thereby making the RA an optional component. An

3.4 Certificate & CRL Database

Issue 02 (2015-05-20) Huawei Proprietary and Confidential 9