Base Station Supporting Multi-Operator PKI (SRAN10.1 - 02)

SingleRAN
Base Station Supporting Multi-

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

Copyright © Huawei Technologies Co., Ltd. 2016. 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-04-20) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
SingleRAN
Base Station Supporting Multi-operator PKI Feature
Parameter Description Contents
Contents
1 About This Document.................................................................................................................. 1

1.1 Scope.............................................................................................................................................................................. 1
1.2 Intended Audience.......................................................................................................................................................... 2
1.3 Change History............................................................................................................................................................... 2
1.4 Differences Between Base Station Types....................................................................................................................... 3
2 Overview......................................................................................................................................... 5
2.1 Background.....................................................................................................................................................................5
2.2 Introduction.................................................................................................................................................................... 5
2.3 Benefits........................................................................................................................................................................... 6
2.4 Architecture.................................................................................................................................................................... 7
3 Certificate Management and Application.............................................................................. 10

3.1 Certificate Preconfiguration Phase............................................................................................................................... 11
3.2 Base Station Deployment Phase................................................................................................................................... 11
3.3 Operation Phase............................................................................................................................................................ 14
3.3.1 Certificate Application.............................................................................................................................................. 14
3.3.2 Certificate Sharing..................................................................................................................................................... 15
3.3.3 Certificate Validity Check......................................................................................................................................... 15
3.3.4 Certificate Update......................................................................................................................................................15
3.3.5 Certificate Revocation............................................................................................................................................... 15
3.3.6 CRL Acquisition........................................................................................................................................................16
3.4 PKI Networking Reliability..........................................................................................................................................16
3.5 Digital Certificate Usage in UMPT+UMPT Cold Backup Mode................................................................................ 16
4 Related Features...........................................................................................................................17
4.1 Features Related to GBFD-171205 BTS Supporting Multi-operator PKI................................................................... 17
4.2 Features Related to WRFD-171220 NodeB Supporting Multi-operator PKI.............................................................. 17
4.3 Features Related to LOFD-081280 eNodeB Supporting Multi-operator PKI..............................................................18
4.4 Features Related to TDLOFD-081206 eNodeB Supporting Multi-operator PKI........................................................ 18
5 Network Impact........................................................................................................................... 19
5.1 GBFD-171205 BTS Supporting Multi-operator PKI................................................................................................... 19
5.2 WRFD-171220 NodeB Supporting Multi-operator PKI.............................................................................................. 19
5.3 LOFD-081280 eNodeB Supporting Multi-operator PKI..............................................................................................19
5.4 TDLOFD-081206 eNodeB Supporting Multi-operator PKI........................................................................................ 20
Issue 02 (2015-04-20) Huawei Proprietary and Confidential ii

SingleRAN
Parameter Description Contents
6 Engineering Guidelines............................................................................................................. 21
6.1 When to Use Base Station Supporting Multi-operator PKI......................................................................................... 21
6.1.1 Typical Scenarios.......................................................................................................................................................21
6.1.2 Unrecommended Scenarios....................................................................................................................................... 24
6.1.3 Forbidden Scenarios.................................................................................................................................................. 26
6.2 Required Information................................................................................................................................................... 26
6.3 Deployment.................................................................................................................................................................. 27
6.3.1 Deployment Process.................................................................................................................................................. 28
6.3.2 Requirements............................................................................................................................................................. 29
6.3.3 Data Preparation........................................................................................................................................................ 31
6.3.4 Precautions.................................................................................................................................................................33
6.3.5 Activation (from No-PKI to Multi-PKI)................................................................................................................... 33
6.3.5.1 Using MML Commands......................................................................................................................................... 33
6.3.5.2 MML Command Examples.................................................................................................................................... 35
6.3.5.3 CME Single Configuration..................................................................................................................................... 38
6.3.5.4 CME Batch Configuration......................................................................................................................................38
6.3.6 Activation (from Single-PKI to Multi-PKI).............................................................................................................. 40
6.3.6.3 CME Single Configuration..................................................................................................................................... 43
6.3.6.4 CME Batch Configuration......................................................................................................................................43
6.3.7 Activation Observation..............................................................................................................................................44
6.3.8 Deactivation (from Multi-PKI to No-PKI)................................................................................................................ 45
6.3.8.3 Using the CME....................................................................................................................................................... 46
6.3.9 Deactivation (from Multi-PKI to Single-PKI)...........................................................................................................46
6.3.9.3 Using the CME....................................................................................................................................................... 48
6.4 Performance Monitoring...............................................................................................................................................48
6.5 Parameter Optimization................................................................................................................................................ 48
6.6 Troubleshooting............................................................................................................................................................ 48
7 Parameters..................................................................................................................................... 49
8 Counters........................................................................................................................................ 56
9 Glossary......................................................................................................................................... 57
10 Reference Documents............................................................................................................... 58
Issue 02 (2015-04-20) Huawei Proprietary and Confidential iii

SingleRAN
Parameter Description 1 About This Document
1 About This Document
1.1 Scope
This document describes Base Station Supporting Multi-operator PKI, including its technical
principles, related features, network impact, and engineering guidelines.
This document covers the following features:
l GBFD-171205 BTS Supporting Multi-operator PKI

l WRFD-171220 NodeB Supporting Multi-operator PKI
l LOFD-081280 eNodeB Supporting Multi-operator PKI
l TDLOFD-081206 eNodeB Supporting Multi-operator PKI
In this document, the following naming conventions apply for LTE terms.
Includes FDD and TDD 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
In addition, the "L" and "T" in RAT acronyms refer to LTE FDD and LTE TDD, respectively.
Table 1-1 provides the definitions of base stations.
Table 1-1 Base station definitions
Base Station Definition

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

maintained through a base station controller.
Issue 02 (2015-04-20) Huawei Proprietary and Confidential 1

SingleRAN
Base Station Definition

Name
eGBTS A base station configured with a GTMUb, UMPT_G, or UMDU_G and

directly maintained by the element management system (EMS).
NodeB A base station configured with a WMPT, UMPT_U, or UMDU_U.
eNodeB A base station configured with an LMPT, UMPT_L, UMPT_T,

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

multimode base UMDU_GL, UMPT_GT, UMDU_GT, UMPT_UL, UMDU_UL,
station UMPT_UT, UMDU_UT, UMPT_LT, UMDU_LT, UMPT_GUL,
UMDU_GUL, UMPT_GUT, UMDU_GUT, UMPT_ULT, UMDU_ULT,
UMPT_GLT, UMDU_GLT, UMPT_GULT, or UMDU_GULT. A co-
MPT multimode base station functionally corresponds to any physical
combination of eGBTS, NodeB, and eNodeB. For example, a co-MPT
multimode base station configured with a UMPT_GU or UMDU_GU
functionally corresponds to the physical combination of eGBTS and
NodeB.
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.
Separate-MPT A base station on which each mode uses its separate main control board.
multimode base For example, a base station configured with a GTMU and WMPT is
station called a separate-MPT GSM/UMTS dual-mode base station.
NOTE
A UMDU cannot be used in a separate-MPT base station.
NOTE
MOs, parameters, alarms, and performance counters in this document are consistent with those of the
latest software version at the time of document release. To obtain information about MOs, parameters,
alarms, and performance counters of the current software version, see the product documentation of this
document.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the feature 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:
l Feature change
Changes in features and parameters of a specified version as well as the affected entities

SingleRAN
l Editorial change
Changes in wording or addition of information and any related parameters affected by
editorial changes. Editorial change does not specify the affected entities.
SRAN10.1 02 (2015-04-20)
Change Type Change Description Parameter
Change
Feature change None None
Editorial change Corrected errors in 6.3.5.2 MML Command None

Examples.
SRAN10.1 01 (2015-03-23)
This issue does not include any changes.
SRAN10.1 Draft A (2015-01-15)

This document is created for SRAN10.1.
1.4 Differences Between Base Station Types

Definition
The macro base stations described in this document refer to 3900 series base stations. These
base stations work in GSM, UMTS, or LTE mode, as listed in the "Scope" section.
The LampSite base stations described in this document refer to distributed base stations that
provide indoor coverage. These base stations work in UMTS or LTE mode but not in GSM
mode.
The micro base stations described in this document refer to all integrated entities that work in
UMTS or LTE mode but not in GSM mode. Descriptions of boards, cabinets, subracks, slots,
and RRUs do not apply to micro base stations.
The following table defines the types of micro base stations.
Base Station Model RAT
BTS3202E LTE FDD
NOTE
The co-MPT and separate-MPT applications are irrelevant to single-mode micro base stations.

SingleRAN
Feature Support by Macro, Micro, and LampSite Base Stations

Feature ID Feature Name Supported Supported Supported
by Macro by Micro by
Base Base LampSite
Stations Stations Base
Stations
GBFD-171205 BTS Supporting Multi- Yes No No

operator PKI
WRFD-171220 NodeB Supporting Yes Yes Yes

Multi-operator PKI
LOFD-081280 eNodeB Supporting Yes Yes Yes

Multi-operator PKI
TDLOFD-081206 eNodeB Supporting Yes No No

Multi-operator PKI
Function Implementation in Macro, Micro, and LampSite Base Stations

Function Difference
Base Station Supporting Micro base stations: Only the BTS3202E support this
Multi-operator PKI feature.
Macro base stations: The eGBTS configured with a GTMUb
and the GBTS do not support this feature.
LampSite: Only the DBS3900 LampSite supports this
feature.

SingleRAN
Parameter Description 2 Overview
2 Overview
2.1 Background
As network deployment demands increase, operators are confronted with the following
challenges if they independently deploy networks:
l Expensive spectrum licenses

l Significant network deployment costs
l High network coverage requirements
l Difficult site deployment
To cope with these challenges, more and more operators choose the network sharing solution,
through which they can use one set of base station equipment to cover the same area. For
details about the network sharing solution, see RAN Sharing Feature Parameter Description.
In RAN Sharing scenarios, however, a base station can only be deployed with the public key
infrastructure (PKI) server of one operator (the primary operator). IPsec tunnels of secondary
operators must be authenticated using the certificate issued by the PKI server of the primary
operator, which impairs the IPsec tunnel reliability of secondary operators.
With the Base Station Supporting Multi-operator PKI feature, a base station can be deployed
with the PKI servers of multiple operators, thereby enhancing base station transmission
reliability.
NOTE
In this document, the PKI system where the base station is deployed with one PKI server is called
single-PKI for short and the PKI system where the base station is deployed with multiple PKI servers is
called multi-PKI for short.
2.2 Introduction
This feature applies to RAN Sharing scenarios. If each operator deploys its own PKI server,
the IPsec tunnel of each operator can be authenticated using the certificate issued by its own
PKI server. This allows services of each operator to be securely isolated. Figure 2-1
illustrates the networking of Base Station Supporting Multi-operator PKI.

SingleRAN
Figure 2-1 Networking of Base Station Supporting Multi-operator PKI
The feature functions are described as follows:
l Only base stations support multi-PKI in RAN Sharing scenarios, except for the eGBTS
configured with a GTMUb or a GBTS.
l A base station can be loaded with and can manage certificates of multiple operators.
Activities such as certification applications, updates, and revocations are performed
separately for operators.
l When working in PKI redundancy mode, each base station can be configured with a
maximum of six pairs of Certificate Authorities (CAs). When PKI redundancy is not
used, each base station can be configured with a maximum of six CAs.
l Each base station can be loaded with a maximum of 20 certificates, including
preconfigured Huawei certificates.
Each base station can store a maximum of 20 certificates. If operators use multi-level
certificates and the size of the certificates exceeds the storage space, then these
certificates must be converted into the .p7b format for storage.
l Each base station can be configured with six periodic CRL acquisition tasks, which can
be configured using the CRLTSK MO. CRL is short for certificate revocation list and
MO is short for managed object.
2.3 Benefits
In RAN Sharing scenarios where each operator deploys its own PKI server, this feature
provides an independent IPsec tunnel for each operator to achieve secure isolation for their
individual services.

SingleRAN
2.4 Architecture
Figure 2-2 illustrates the PKI system architecture for the Base Station Supporting Multi-
operator PKI feature.
l The PKI system of operator 1 consists of CA 1, RA 1, and certificate & CRL database 1.
l The PKI system of operator 2 consists of CA 2, RA 2, and certificate & CRL database 2.
RA is short for registration authority. For details about the CA, RA, and certificate & CRL
database, see PKI Feature Parameter Description.
Figure 2-2 PKI system architecture for the Base Station Supporting Multi-operator PKI
feature
Table 2-1 describes the function differences between single-PKI and multi-PKI.

SingleRAN
Table 2-1 Function differences between single-PKI and multi-PKI

Function Is Difference Description
There
Any
Differ
ence
CMPv2-based certificate No -
management
Certificat Certificate No -
e preconfiguration
manage phase
ment and
applicati Base station Yes See 3.2 Base Station Deployment Phase.
on deployment phase
Certificate application Yes See 3.3.1 Certificate Application.
Certificate sharing No -
Certificate validity No -
check
Certificate update No -
Certificate revocation No -
CRL acquisition No -
PKI Networking No -
Reliability
UMPT+UMPT cold No -
backup mode
Figure 2-3 illustrates the differences in configuration objects used for configuring multi-PKI
compared with those used for configuring single-PKI.

SingleRAN
Figure 2-3 Differences in configuration objects used for configuring multi-PKI

SingleRAN
Parameter Description 3 Certificate Management and Application
3 Certificate Management and Application
This chapter describes the differences in certificate management and application between
single-PKI and multi-PKI. For the similarities, see PKI Feature Parameter Description.

SingleRAN
3.1 Certificate Preconfiguration Phase

A base station is preconfigured with Huawei certificates before delivery. In multi-PKI
scenarios, the base station uses the preconfigured Huawei certificates to apply for certificates
for operators.
3.2 Base Station Deployment Phase

Figure 3-1 shows an IPsec networking where a digital certificate is used for identity
authentication.
In RAN Sharing scenarios, the base station sets up the OM channel with only the primary
operator and the primary operator manages the base station. In the following figure, CA 1 is
the PKI server deployed for the primary operator and CA 2 is the PKI server deployed for a
secondary operator. The OM channel is authenticated using a Secure Sockets Layer (SSL)
certificate.

SingleRAN
Figure 3-1 Networking for multi-PKI base station deployment in RAN Sharing scenarios
NOTE
Steps 1 to 5 are performed for the primary operator and steps 6 to 8 are performed for the secondary
operator.
Comply with the following rules when deploying a multi-PKI network:
l Each operator's CA should be preconfigured with Huawei's root certificate and a CRL
(optional), which are used to verify Huawei-issued device certificates.
l Each operator's SeGW should be preconfigured with its own operator's root certificate, a
CRL (optional), and an operator-issued device certificate, which are used for the two-
way authentication between the SeGW and the Huawei base station.
l During automatic base station deployment, the base station needs to apply for a CA
certificate for the two operators, and perform a two-way authentication with each
operator's SeGW.

SingleRAN
– In plug and play (PnP) base station deployment mode, the base station must first
apply for a CA certificate for the primary operator and then for the secondary
operator.
– In USB-based base station deployment mode, CA certificates can be applied for
without following the above sequence.
Figure 3-2 details base station deployment procedures illustrated in Figure 3-1.
Figure 3-2 Automatic base station deployment
1. The base station obtains security-related parameters.

– In PnP base station deployment mode, a CMPv2-based certificate application
procedure is triggered when both of the following conditions are true:
The base station obtains information of CA 1 by exchanging Dynamic Host
Configuration Protocol (DHCP) packets with the DHCP server.

SingleRAN
The base station does not have an operator-issued device certificate, or it has an
invalid operator-issued device certificate.
NOTE
PnP base station deployment must follow steps 2 to 6.

– In USB-based base station deployment mode, a CMPv2-based certificate
application procedure is triggered based on the CA information of the two operators
when both of the following conditions are true:
Operator-issued device certificates are authenticated through IKE negotiation.
The base station does not have an operator-issued device certificate, or it has an
invalid operator-issued device certificate.
NOTE
In USB-based base station deployment mode, step 6 can be performed prior to step 2 or 5.
2. The base station applies for a device certificate for the primary operator from CA 1.
a. The base station sends a certificate request message to CA 1 based on CMPv2.
b. CA 1 uses the preconfigured Huawei root certificate to verify the Huawei-issued
device certificate carried in the certificate request message.
3. After the verification succeeds, CA 1 issues the primary operator's device certificate and
root certificate to the base station.
4. The base station performs a two-way authentication and sets up an IPsec tunnel with
SeGW 1.
The two parties send the operator-issued digital certificate they have obtained to each
other and use the operator's root certificate to confirm each other's identities. The base
station sets up an IPsec tunnel with SeGW 1 after an authentication procedure.
5. After obtaining the primary operator's device certificate, the base station sets up an OM
channel with the U2000 of the primary operator, and downloads and activates the base
station configurations, which include the configuration information of CA 2.
6. The base station applies for a device certificate for the secondary operator from CA 2
and sets up an IPsec tunnel with SeGW 2.
The procedures are the same as those for the primary operator. For details, see 2 to 4.
NOTE
During CMPv2-based automatic certificate application, the preconfigured Huawei-issued device

certificate is used for SSL authentication.
3.3 Operation Phase

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

Multi-PKI has the following requirements in the certificate application phase:
l If operators use different certificate request templates, these certificate request templates
must be configured before certificate application.
Set the CERTREQSW parameter under the CA MO to USERDEFINE to customize a
certificate request template for the CA.

SingleRAN
l When a manual CMPv2-based certificate application is triggered:

– Operators' certificates must be applied for one by one.
– When the REQ DEVCERT command is executed to trigger a CMPv2-based
certificate application, the preconfigured Huawei-issued device certificate is used
for certificate application by default, which saves the trouble of running the MOD
APPCERT command to change a configured device certificate to the preconfigured
Huawei-issued device certificate.
– After a successful certificate application, the obtained operator's certificate will be
automatically loaded to the MO CERTMK, and the CASW parameter is
automatically set to on for this certificate.
l Before a single-PKI to multi-PKI reconstruction, the CASW parameter in the MOD
CERTMK command must be set to on.
l After a successful certificate application, run the MOD APPCERT command to set a
certificate under the MO CERTMK as the global certificate, which saves the trouble of
running the MOD APPCERT command to validate certificates for multiple operators.
l After successful certificate loading, bind each operator's certificate to the corresponding
IPsec tunnel.
You can use the CERTSOURCE and CERTNAME parameters under the IKEPEER
MO to bind operators' certificates to IPsec tunnels.
3.3.2 Certificate Sharing

The SSL certificate sharing method in multi-PKI scenarios is the same as that in single-PKI
scenarios. Secondary operators have no SSL tunnel and therefore, they do not need to use the
SSL certificate.
3.3.3 Certificate Validity Check

In multi-PKI scenarios, the periodic certificate validity check task is globally set for all
operators. You cannot set a periodic certificate validity check task for a specific operator.
3.3.4 Certificate Update

Certificate updates can be performed in two modes:
l Automatic CMPv2-based certificate update

– Upon detecting that a certificate is about to expire, a CMPv2-based certificate
update procedure is automatically triggered for multiple operators. The certificate
update procedure is the same as that in single-PKI scenarios.
– If the automatic certificate update fails due to packet loss caused by intermittent
transmission, the base station automatically initiates another certificate update
attempt. A maximum of two certificate update attempts can be initiated.
l Manual CMPv2-based certificate update
A certificate update is manually triggered for operators one by one.
3.3.5 Certificate Revocation

The certificate revocation procedure in multi-PKI scenarios is the same as that in single-PKI
scenarios.

SingleRAN
3.3.6 CRL Acquisition

In multiple-PKI scenarios:
l Operators' CRL servers are independent of each other and the CRL acquisition procedure
is the same as that in single-PKI scenarios.
l A maximum of six automatic CRL acquisition tasks can be configured under the
CRLTSK MO.
l Only one global CRL policy can be configured for a base station under the MO
CRLPOLICY.
3.4 PKI Networking Reliability

To improve the reliability of PKI-based secure networks, the base station supports PKI
redundancy.
l The two PKI servers of one operator can work in redundancy mode. The working
mechanism is the same as that in single-PKI scenarios.
l The base station supports a maximum of six pairs of PKI servers in redundancy mode.
l The active and standby PKI servers must belong to the same operator.
3.5 Digital Certificate Usage in UMPT+UMPT Cold

Backup Mode
The digital certificate usage in UMPT+UMPT cold backup mode in multi-PKI scenarios is
the same as that in single-PKI scenarios. The difference is that in multi-PKI scenarios, one
base station manages the certificates of multiple operators. A base station can manage a
maximum of 20 certificates, including the preconfigured Huawei certificates.

SingleRAN
Parameter Description 4 Related Features
4 Related Features
4.1 Features Related to GBFD-171205 BTS Supporting

Multi-operator PKI
Prerequisite Features
Feature ID Feature Name Description
GBFD-118601 Abis over IP -
Mutually Exclusive Features

None
Impacted Features
None
4.2 Features Related to WRFD-171220 NodeB Supporting

Multi-operator PKI
Feature ID Feature Name Description
WRFD-050402 IP Transmission -
Introduction on Iub
Interface

SingleRAN
Parameter Description 4 Related Features

None
Impacted Features
None
4.3 Features Related to LOFD-081280 eNodeB Supporting

Multi-operator PKI
None

None
Impacted Features
None
4.4 Features Related to TDLOFD-081206 eNodeB

Supporting Multi-operator PKI
None

None
Impacted Features
None

SingleRAN
Parameter Description 5 Network Impact
5 Network Impact
5.1 GBFD-171205 BTS Supporting Multi-operator PKI

System Capacity
No impact.
Network Performance
The duration of base station deployment is prolonged by 10s due to certificate application for
each operator.
5.2 WRFD-171220 NodeB Supporting Multi-operator PKI

System Capacity
No impact.
Network Performance
each operator.
5.3 LOFD-081280 eNodeB Supporting Multi-operator PKI

System Capacity
No impact.
Network Performance
each operator.

SingleRAN
Parameter Description 5 Network Impact
5.4 TDLOFD-081206 eNodeB Supporting Multi-operator

PKI
System Capacity
No impact.
Network Performance
each operator.

SingleRAN
Parameter Description 6 Engineering Guidelines
6 Engineering Guidelines
6.1 When to Use Base Station Supporting Multi-operator

PKI
In RAN Sharing scenarios, if each operator deploys its own PKI server, this feature must be
enabled to isolate each operator's services. Before feature deployment, configure PKI
information for each operator.
6.1.1 Typical Scenarios

Single-Mode Base Station
Figure 6-1 uses LTE as an example to illustrate the PKI system in this scenario.
l Operator A and operator B share the base station in the RAN Sharing scenario.
l The two operators have their own PKI system and IPsec tunnel.
l The base station is managed by operator A.
l The base station uses the digital certificate issued by each operator to access each
operator's network.

SingleRAN
Figure 6-1 PKI system of an LTE single-mode base station
Co-MPT Multimode Base Station

The PKI system of a co-MPT multimode base station is the same as that of a single-mode
base station.
Separate-MPT Multimode Base Station

Figure 6-2 uses a separate-MPT UL dual-mode base station as an example to illustrate the
PKI system in this scenario.
l The UMPT_L and UMPT_U are shared by operator A and operator B.
l UMTS data is transmitted through LTE.
l The two operators' certificates are deployed on the UMPT_L.
l On the U2000 of the primary operator, the base station is managed as two separated base
stations.
l The UMPT_U and UMPT_L have a separate SSL channel and OM channel with the
U2000. The UMPT_U shares the SSL certificate with the UMPT_L.
l The UMPT_L has separate IPsec tunnels with SeGW A and SeGW B. The two IPsec
tunnels are authenticated using the certificate issued by the corresponding operator.

SingleRAN
Figure 6-2 PKI system of a separate-MPT UL dual-mode base station
IPsec Redundancy Among Multiple SeGWs

IPsec redundancy among multiple SeGWs improves the reliability of base station operation.
In Figure 6-3, SeGW A and SeGW A' belong to operator A and work in active/standby mode.
SeGW B and SeGW B' belong to operator B and work in active/standby mode. Before
deploying the Base Station Supporting Multi-operator PKI feature in IPsec redundancy mode,
enable the IPsec redundancy feature. For details, see IPsec Feature Parameter Description.
For details about how to configure the Base Station Supporting Multi-operator PKI feature in
IPsec redundancy mode, see 6.3 Deployment.

SingleRAN
Figure 6-3 IPsec redundancy among multiple SeGWs
6.1.2 Unrecommended Scenarios

Shared Base Station Controller with No IPsec Tunnel Between the Base Station
Controller and CN
Operator A (primary operator) and operator B (secondary operator) share the base station
controller, which is connected to the CN of each operator. No IPsec tunnel is set up between
the base station controller and the CN. Figure 6-4 shows an example.
In this scenario, data of operator A and operator B is converged on the base station controller
and then is forwarded to the respective CN. It is recommended that only one IPsec tunnel be
set up between the base station and the base station controller. The primary operator's digital
certificate and SeGW are used.

SingleRAN
Figure 6-4 Shared base station controller with no IPsec tunnel between the base station
controller and CN
Shared Base Station Controller with IPsec Tunnel Between the Base Station
Controller and CN
Operator A and operator B share the base station controller, which is connected to the CN of
each operator. IPsec tunnels are set up between the base station controller and the CNs of the
two operators. Figure 6-4 shows an example.
In this scenario, although the base station controller has separate IPsec tunnels with the CNs
of the two operators, the base station supports the IPsec tunnel only with an external SeGW. If
separate IPsec tunnels are to be set up for different operators between the base station and
base station controller, different digital certificates must be configured to authenticate these
IPsec tunnels and certificate update should be performed separately for different PKI systems.

SingleRAN
Figure 6-5 Shared base station controller with IPsec tunnel between the base station
controller and CN
6.1.3 Forbidden Scenarios

l In a GU RAN Sharing network, operators share the base station but use different base
station controllers.
At present, the GU dual-mode base station cannot be connected to base station
controllers of different operators.
l OM channels are securely isolated.
In RAN Sharing scenarios, the base station does not support separate OM channels for
different operators and only the primary operator can set up the SSL-based OM channel.
In this case, this feature cannot implement secure isolation of OM channels.
l Some IPsec MOs are manually configured (with no SeGW between eNodeBs) during X2
self-setup in IPsec-enabled scenarios.
In this scenario, the base station cannot determine which certificate to be used when
fautomatically generating the IKE peer.
For details about this scenario, see section "X2 Interface Self-Management in IPSec-
enabled Scenarffffios" in S1/X2 Self-Management Feature Parameter Description, which
is included in eRAN Feature Documentation and eRAN TDD Feature Documentation.
6.2 Required Information

Before deploying this feature, engineering personnel must obtain CA information from CA
maintenance personnel. The required CA information in this scenario is the same as that in
single-PKI scenarios. For details, see PKI Feature Parameter Description.

SingleRAN
6.3 Deployment
l New sites
A new site is not enabled with any PKI-related features (including the PKI and PKI
redundancy features) and needs to be deployed with multiple PKIs.
Figure 6-6 shows an example of multi-PKI deployment in RAN sharing scenarios where
operator A and operator B share an eNodeB.
NOTE
The deployment method is the same for the eGBTS, NodeB, eNodeB, and multimode base
stations.
This document describes how to enable the Base Station Supporting Multi-operator PKI feature
using MML commands and the CME. For details about how to enable this feature using the
U2000, see the U2000 help document.
Figure 6-6 No-PKI to multi-PKI reconstruction
l Existing sites
An existing site has been deployed with the PKI, PKI redundancy, or IPsec redundancy
feature. It needs to be deployed with multiple-operator PKIs.
Figure 6-7 shows an example of single-PKI to multiple-PKI reconstruction in an
eNodeB.
– Before reconstruction: Operator A and operator B share the eNodeB and the
certificate issued by the PKI server of operator A is used for authentication.
– After reconstruction: Operator A and operator B have their own PKI server and use
the certificate issued by their own PKI server for authentication.

SingleRAN
Figure 6-7 Single-PKI to multi-PKI reconstruction
6.3.1 Deployment Process

Figure 6-8 shows the feature deployment process.

SingleRAN
Figure 6-8 Process of deploying the Base Station Supporting Multi-operator PKI feature
6.3.2 Requirements
Other Features
For details, see 4 Related Features.
For details about the IPsec redundancy among multi-SeGWs feature, see IPsec Feature
Parameter Description. For other features, see PKI Feature Parameter Description.

SingleRAN
Hardware
Table 6-1 Hardware required for deploying this feature on the eGBTS, NodeB, eNodeB,
NE Type Board Configuration Board That Provides a Port Type
Port for Connecting
the Base Station to the
Transport Network
eGBTS UMPT/UMDU UMPT/UMDU Ethernet port
UMPT+UTRPc UTRPc Ethernet port
NodeB UMPT/UMDU UMPT/UMDU Ethernet port
UMPT/WMPT+UTRPc UTRPc Ethernet port
eNodeB UMPT/LMPT/UMDU LMPT/UMPT/UMDU Ethernet port
LMPT/UMPT+UTRPc UTRPc Ethernet port
License
Before deploying this feature, purchase and activate the license for this feature.
Feature Feature License License Control NE Sales Unit

ID Name Control Item
Item ID
GBFD-171 BTS LGB3MOPK BTS Supporting BTS Per BTS

205 Supporting I01 Multi-operator PKI
Multi-operator (per BTS)
PKI
WRFD-171 NodeB LQW9MOK NodeB supporting Node Per NodeB

220 Supporting PI01 Multi-operator PKI B
Multi-operator (per NodeB)
PKI
LOFD-081 eNodeB LT1SESMU eNodeB eNode Per

280 Supporting PKI0 Supporting Multi- B eNodeB
Multi-operator operator PKI(FDD)
PKI
TDLOFD- eNodeB LT1STMOP eNodeB eNode Per

081206 Supporting KI00 Supporting Multi- B eNodeB
Multi-operator operator
PKI PKI(TDD)

SingleRAN
NOTE
The license activation rules for a multimode base station are as follows:
l In a separate-MPT multimode base station with co-transmission, the license needs to be deployed
only on the mode that provides the co-transmission port. If another mode needs to share the
certificate, the license also needs to be deployed on this mode.
l If the UTRPc provides a co-transmission port, the license needs to be activated for the mode that
controls the UTRPc.
l In a co-MPT multimode base station, the license can be activated on any of the GSM, UMTS, or
LTE mode.
Others
This feature has the following requirements:
l The PKI server (CA) of each operator must be deployed. Each base station supports a
maximum of six operators' PKI servers, that is, six independent CAs or twelve active/
standby CAs.
l The device certificate and CRL file issued by each operator's CA server must meet the
RFC 5280 standards.
l The operator's CA server complies with the CMPv2 specified in the RFC 4210
standards. The certificate request message format meets the RFC 4211 standards.
l The operator's CA server meets the following specification in 3GPP TS 33.310: The
certificate request message contains the operator's root certificate or certificate chain.
l The operator's CA server is preconfigured with the Huawei root certificate.
6.3.3 Data Preparation

Table 6-2 lists data that needs to be prepared for enabling the Base Station Supporting Multi-
operator PKI feature. For parameters related to the PKI and PKI redundancy features, see PKI
Feature Parameter Description. For parameters related to IPsec redundancy among multi-
SeGWs, see IPsec Feature Parameter Description.
The base station must initiate certificate application requests to each operator's CA server.
Each operator's CA information must be configured on the base station side. The involved
MOs are CA in MML and CME configurations.
Table 6-2 Data to be prepared on the base station side for the CA server
Parameter Parameter ID Setting Notes Data

Name Source
Certificate CERTREQSW l When the certificate request Network plan

Request Switch template configured in the
MOD CERTREQ
command is used, set this
parameter to DEFAULT.
l When a customized
certificate request template
is used, set this parameter to
USERDEFINE.

SingleRAN

Name Source
Common Name COMMNAME This parameter is valid only

when CERTREQSW is set to
Common Name USERADDINFO USERDEFINE.
Additional Info.
These parameters are used to
Country COUNTRY configure the certificate request
template used for certificate
Organization ORG application for a secondary
operator. The setting notes are
Organization ORGUNIT
the same as those in the MO
Unit
CERTREQ.
State or STATEPROVINCE
Province NAME
Locality LOCALITY
Key Usage KEYUSAGE
Certificate CERTREQSIGNAL
Request G
Signature
Algorithm
Key Size KEYSIZE
Local Name LOCALNAME
Local IP LOCALIP
Table 6-3 lists the data to be prepared for a device certificate (involving the CERTMK MO
in MML and CME configurations).
Table 6-3 Data to be prepared for a device certificate

Name Sour
ce
CA Switch CASW l When CMPv2-based feature Netw

deployment is used, bind ork
certificates issued for all operators plan
to the corresponding CA. In this
case, set this parameter to ON(On)
for each certificate.
l Set this parameter to OFF(Off) for
Certificate CANAME This parameter is valid only when Netw

Authority CASW is set to ON(On). ork
Name plan

SingleRAN
Table 6-4 lists the data to be prepared for an IKE peer (involving the IKEPEER MO in
MML and CME configurations).
Table 6-4 Data to be prepared for the IKE peer

Name Sour
ce
Certificate CERTSOURCE In multi-PKI scenarios, you need to Netw

Source bind a certificate for each IKEPEER. ork
l If the certificate configured by the plan
APPCERT MO is used, set this
parameter to APPCERT(Appcert).
l If the certificate configured by the
CERTMK MO is used, set this
parameter to CERTMK(Certmk).
Certificate File CERTNAME This parameter is valid only when Netw

Name CERTSOURCE is set to ork
CERTMK(Certmk). plan
6.3.4 Precautions
l During new PKI deployment, the IPsec tunnel needs to be reestablished, which interrupts
services.
l This feature cannot be deployed on an eGBTS configured with the GTMUb or a GBTS.
l During manual certificate application using an MML command, the preconfigured
Huawei-issued device certificate is used by default for certificate application. In this
case, you do not need to run the MOD APPCERT command to change the device
certificate used for IKE negotiation between the base station and the peer end to the
preconfigured Huawei-issued device certificate.
l Periodic certificate validity check is performed for all operators. You cannot set a
periodic certificate validity check task for a specific operator.
l One CRL policy applies to all operators. You cannot configure a CRL policy for a
specific operator.
6.3.5 Activation (from No-PKI to Multi-PKI)

This section describes how to activate this feature for a base station with no PKI feature
deployed.
6.3.5.1 Using MML Commands

This feature is disabled by default. To enable this feature, perform the following steps:
Step 1 (Optional) Run the MML command SET CERTDEPLOY to set the board where a certificate
is to be deployed.

SingleRAN
NOTE
In separate-MPT scenarios, you need to reset the base station after the command execution to validate
the configuration.
If the base station is configured with only one main control board, the certificate is deployed on this
main control board by default. In this case, you can skip this step.
Step 2 Run the MML command MOD CERTREQ to configure a global certificate request template.
NOTE
Pay attention to the following tips when configuring the global certificate request template.
l If the certificate request file used by the CA is the same as the global certificate request template,
use the template specified in CERTREQ.
l If the certificate request file used by the CA is different from the global certificate request template,
configure a certificate request template for the CA by referring to Step 3.
Step 3 Run the MML command ADD CA to add CA information for each operator.
l If the certificate request file used by the CA is different from that configured in Step 2,
set Certificate Request Switch to USERDEFINE(USERDEFINE) to customize a
certificate request template for this CA.
l If the PKI redundancy mode is used, configure the standby CA of this CA.
NOTE
You need to purchase the license for the PKI redundancy feature before enabling this feature. For
details, see PKI Feature Parameter Description.
Step 4 (Manual) Run the MML command DLD CERTFILE for several times to download
operators' root certificates from each operator's certificate & CRL database.
Step 5 (Manual) Run the MML command ADD TRUSTCERT for each CA trust certificate you
want to add.
NOTE
If multi-level CAs are deployed in an operator's PKI system, a complete certificate chain must be added.
If the certificates of different levels of CAs in the certificate chain are stored separately, run the ADD
TRUSTCERT command for each certificate you want to add.
Step 6 (Manual) Run the MML command REQ DEVCERT for each CMP session you want to start
to apply for a device certificate.
NOTE
The certificate application procedure is triggered when this configuration takes effect.
The obtained certificate will be automatically loaded to CERTMK and the CA Switch is set to on.
If automatic certificate loading fails, run the MML command ADD CERTMK to manually load the
certificate.
Step 7 Run the MML command MOD APPCERT to activate the configured global certificate.
NOTE
Pay attention to the following tips when activating the configured global certificate:
l You can configure only one SSL certificate and one IKE certificate, respectively.
l In multi-PKI scenarios, if the certificate used by an operator is different from the configured
certificate, set the certificate name for the operator in the MO IKEPEER in Step 8.
Step 8 Enable the IPsec feature. For details, see IPsec Feature Parameter DescriptionDeployment
of IPsec on a PKI-based Secure Network > Deploying IPsec on an eGBTS, NodeB, or
eNodeB > Activation > Using MML Commands.

SingleRAN
Pay attention to the following configurations:

Run the MML command ADD IKEPEER. In this step, set parameters Certificate Source
and Certificate File Name to bind certificates to each IKE channel.
l When Certificate Source is set to APPCERT, the certificate configured in Step 7 is

used.
l When Certificate Source is set to CERTMK, the certificate configured in the MO
CERTMK is used.
Step 9 Run the MML command SET CERTCHKTSK to set a periodic certificate validity check
task.
----End
(Optional) After this feature is enabled, the CRL files of secondary operators can be
downloaded from the corresponding certificate & CRL database either manually or
automatically.
l Manual download
Step 1 Run the MML DLD CERTFILE for each CRL file you want to download.
Step 2 Run the MML command ADD CRL command for each CRL file you want to add.
Step 3 Run the MML command SET CRLPOLICY to configure the CRL policy.
----End
l Automatic download
Step 1 Run the MML command ADD CRLTSK for each periodic CRL download task you want to
add.
Step 2 Run the MML command SET CRLPOLICY to configure the CRL policy.
----End
(Optional) After this feature is activated, perform the following step if you want to manually
trigger a certificate update:
Step 1 Run the MML command UPD DEVCERT to set certificate update information. A CMPv2-
based certificate application is triggered after this configuration takes effect.
----End
6.3.5.2 MML Command Examples

Assume that:
l Operator A: C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca1

l Operator B: C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca2
//Setting the board where a certificate is to be deployed
SET CERTDEPLOY:DEPLOYTYPE=SPECIFIC,CN=0,SRN=0,SN=7;
NOTE
After command execution, reset the base station to validate the configuration.

SingleRAN
//Configuring the global 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_SIGNAT
URE-1&KEY_AGREEMENT-1&KEY_ENCIPHERMENT-1,SIGNALG=SHA256,KEYSIZE=KEYSIZE1024,LOCALN
AME="abcdefghijklmn.huawei.com",LOCALIP="10.20.20.188";
//Setting CA information for operator A and use this information to customize a certificate
request template for the CA
l If the CA is accessible either through the intranet or through an external network and the
OM data is protected by IPsec, it is recommended that the source IP address used for
certificate application be set to an interface IP address, the source IP address used for
certificate update be set to the OM IP address (for example, 10.31.31.188), the CA URL
during site deployment be set to 10.87.87.87, and the certificate request template be
customized. 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.87.87.87:80/
pkix/",INITREQSIP="10.20.20.188",CERTREQSW=USERDEFINE,COUNTRY="cn",ORG="ITEF",
ORGUNIT="hw",STATEPROVINCENAME="sc",LOCALITY="cd",KEYUSAGE=DATA_ENCIPHERMENT-1
&DIGITAL_SIGNATURE-1&KEY_AGREEMENT-1&KEY_ENCIPHERMENT-1,CERTREQSIGNALG=SHA256,
KEYSIZE=KEYSIZE1024;
l If the CA is accessible either through the intranet or through an external network and the
OM data is not protected by IPsec, it is recommended that the source IP address used for
certificate update be set to an internal IP address (for example, 10.45.45.45), the source
IP address used for certificate application be set to an interface IP address, the CA URL
during site deployment be set to 10.87.87.87, and the certificate request template be set
to the global template. The following is an example:
eca1",URL="http://10.88.88.88:80/
pkix/",SIGNALG=SHA256,MODE=CFG_INIT_UPD_ADDR,UPDSIP="10.45.45.45",INITREQURL="
http://10.87.87.87:80/pkix/",INITREQSIP="10.20.20.188",CERTREQSW=DEFAULT;
l The following shows an example when operator A uses PKI redundancy, an interface IP
address is used for certificate application and certificate update, and the default
certificate request template is used.
eca1",URL="http://10.88.88.88:80/
http://10.85.85.85:80/pkix/",INITREQSIP="10.20.20.188",SLVURL="http://
10.10.10.87:80/pkix/",SLVINITREQURL="http://10.10.10.86:80/
pkix/",CERTREQSW=DEFAULT;
//Setting CA information for operator B
l If operator B' CA is accessible only through the external network, it is recommended that
interface IP addresses be used for certificate application and certificate update, and a
customized certificate request template be used. The following is an example:
eca2",URL="http://10.89.89.89:80/
pkix/",SIGNALG=SHA256,MODE=CFG_INIT_UPD_ADDR,UPDSIP="10.20.20.188",INITREQURL=
"10.86.86.86:80/
pkix/",INITREQSIP="10.35.35.35",CERTREQSW=USERDEFINE,COMMNAME=ESN,
USERADDINFO=".huawei.com",COUNTRY="cn",ORG="ITEF",ORGUNIT="hw",STATEPROVINCENA
ME="sc",LOCALITY="cd",KEYUSAGE=DATA_ENCIPHERMENT-1&DIGITAL_SIGNATURE-1&KEY_AGR
EEMENT-1&KEY_ENCIPHERMENT-1,CERTREQSIGNALG=SHA256,KEYSIZE=KEYSIZE1024;
l The following shows an example when operator B uses PKI redundancy, an interface IP
address is used for certificate application and certificate update, and the default
certificate request template is used.

SingleRAN

eca2",URL="http://10.89.89.89:80/
http://10.86.86.86:80/pkix/",INITREQSIP="10.20.20.188",SLVURL="http://
10.10.10.85:80/pkix/",SLVINITREQURL="http://10.10.10.84:80/
pkix/",CERTREQSW=DEFAULT;
//(Manual triggering of CMPv2-based certificate application) Downloading operator's root

certificate 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.
l Downloading operator A's root certificate

DLD
CERTFILE:IP="10.60.60.60",USR="admin",PWD="*****",SRCF="OperationCA1.cer",DSTF
="OperationCA1.cer";
l Downloading operator B's root certificate

DLD
CERTFILE:IP="10.60.60.60",USR="admin",PWD="*****",SRCF="OperationCA2.cer",DSTF
="OperationCA2.cer";
//(Manual triggering of CMPv2-based certificate application) Setting each operator's root

certificate to the trust certificate
l Setting operator A's root certificate to the trust certificate

ADD TRUSTCERT: CERTNAME="OperationCA1.cer";
l Setting operator B's root certificate to the root certificate

//(Manual triggering of CMPv2-based certificate application) Setting information used by the

base station to apply for operator-issued device certificates
l //Configuring the certificate request template

REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd,
CN=eca1", APPCERT="OPKIDevCert1.cer";
l Manually applying for a digital certificate for operator B. Skip this step if you use
automatic triggering of CMPv2-based certificate application.
REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd,
CN=eca2", APPCERT="OPKIDevCert2.cer";
//Setting information about a global certificate
If operator A's certificate is used as the global certificate, operators not deployed with PKI
servers can share this certificate.
MOD APPCERT: APPTYPE=IKE, APPCERT="OPKIDevCert1.cer";
NOTE
After command execution, if the IKE connection is authenticated using a certificate and the current
status of the IKE SA is normal, the base station automatically triggers an IKE re-negotiation.
//Configuring the certificate used for IKE negotiation
l Operator A uses the global certificate for IKE negotiation.

ADD IKEPEER: PEERNAME="peer", PROPID=1, IKEVERSION=IKE_V2, IDTYPE=FQDN,
REMOTEIP="10.90.90.90", DPD=PERIODIC, CERTSOURCE = 0;
l Operator B does not use the global certificate for IKE negotiation and the certificate
name is OpkiDevCert2.cer.
ADD IKEPEER: PEERNAME="peer", PROPID=1, IKEVERSION=IKE_V2, IDTYPE=FQDN,
REMOTEIP="10.91.91.91", DPD=PERIODIC, CERTSOURCE = 1,
CERTNAME="OpkiDevCert2.cer";
//Setting a periodic certificate validity check task universally for all operators

SingleRAN
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
l Loading the CRL file for operator A

ADD CRL: CERTNAME="eNodeB1.crl";
l Loading the CRL file for operator B

//(Optional) Setting the CRL policy universally for all operators

SET CRLPOLICY: CRLPOLICY= NOVERIFY;
//(Optional) Adding a periodic CRL download task
l Adding a periodic CRL download task for operator A

ADD CRLTSK: IP="10.86.86.86", USR="admin", PWD="*****",
FILENAME="eNodeB1.crl", ISCRLTIME=DISABLE, PERIOD=24, TSKID=0,
CRLGETMETHOD=FTP;
l Adding a periodic CRL download task for operator B

ADD CRLTSK: IP="10.87.87.87", USR="admin", PWD="*****",
FILENAME="eNodeB2.crl", ISCRLTIME=DISABLE, PERIOD=24, TSKID=0,
CRLGETMETHOD=FTP;
//Manually triggering a certificate update
l Manually updating operator A's certificate

UPD DEVCERT: APPCERT="OPKIDevCert1.cer",REKEY=YES;
l Manually updating operator B's certificate

UPD DEVCERT: APPCERT="OPKIDevCert2.cer",REKEY=YES;
NOTE
If the base station is undergoing an IKE or SSL negotiation during the command execution, the
certificate update is performed after the negotiation.
6.3.5.3 CME Single Configuration

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

Fill the values of the parameters listed in Table 6-5 into a summary data file, which contains
other data for the base stations to be newly deployed. Then, import the summary data file into
the CME.
The summary data file may be a scenario-specific file provided by the CME or a customized
file, depending on the following conditions:
l The MOs in Table 6-5 are contained in a scenario-specific summary data file. In this
situation, set the parameters in the MOs, and then verify and save the file.

SingleRAN
l Some MOs in Table 6-5 are not contained in a scenario-specific summary data file. In
this situation, customize a summary data file to include the MOs before you can set the
parameters.
Table 6-5 Relate MOs

SN MO Sheet in the Parameter Group Re
Summary ma
Data File rks
1 CERTDEPLOY Common Data DEPLOYTYPE, CN, SRN, -

SN
2 CA Common Data CANAME, URL, -

SIGNALG, MODE,
UPDSIP, INITREQURL,
INITREQSIP,
CERTREQSW,
COMMNAME,
USERADDINFO,
COUNTRY, ORG,
ORGUNIT, STATE,
PROVINCENAME,
LOCALITY, KEYUSAGE,
SIGNALG, KEYSIZE,
LOCALNAME, LOCALIP
3 CERTREQ Common Data COMMNAME, -

USERADDINFO,
COUNTRY, ORG,
ORGUNIT, STATE,
PROVINCENAME,
LOCALITY, KEYUSAGE,
SIGNALG, KEYSIZE,
LOCALNAME, LOCALIP
4 CERTMK Common Data APPCERT, CASW, -

CANAME
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 CRLTSK Common Data CRLPOLICY -

SingleRAN
SN MO Sheet in the Parameter Group Re

Summary ma
Data File rks
10 CRLTSK Common Data IP, USR, PWD, -

FILENAME, ISCRLTIME,
PERIOD,
CRLGETMETHOD,
SEARCHDN, PORT,
TSKID, SIP, CONNMODE,
AUTHPEER
11 IKEPEER Common Data PEERNAME, PROPID, -

EXCHMODE,
IKEVERSION, IDTYPE,
REMOTEIP,
REMOTENAME, PKEY,
DPD, DPDIDLETIME,
DPDRETRI, DPDRETRN,
LOCALIP, CTRLMODE,
REDUNDANCYFLAG,
PRIORITY,
MASTERPEERNAME,
CERTSOURCE,
CERTNAME
For detailed operations on each type of base station, see the following section in 3900 Series
Base Station Initial Configuration Guide:
l For eGBTS, see section "Creating eGBTSs in Batches."

l For NodeBs, see section "Creating NodeBs in Batches."
l For eNodeBs, see section "Creating eNodeBs in Batches."
l For separate-MPT multimode base stations, see section "Creating Separate-MPT
Multimode Base Stations in Batches."
l For co-MPT multimode base stations, see section "Creating Co-MPT Multimode Base
Stations".
6.3.6 Activation (from Single-PKI to Multi-PKI)

This section describes how to activate this feature when the base station has been deployed
with the PKI, PKI redundancy, or IPsec redundancy for multiple SeGWs feature.

This feature is disabled by default. To enable this feature, perform the following steps:
Step 1 Specify a CA for the primary operator's certificate that has been loaded to the base station.
1. Run the MML command LST CERTMK to query information about the device
certificate configured on the base station.

SingleRAN
2. Run the MML command MOD CERTMK. In this step, set CA Switch to ON(On) for
all the loaded certificates except for the preconfigured Huawei certificates and specify
CAs for these certificates.
Step 2 Run the MML command ADD CA to add CA information for each operator.
If the certificate request file used by the CA is different from that configured in the MO
CERTREQ, set Certificate Request Switch to USERDEFINE(USERDEFINE) to
customize a certificate request template for this CA.
Step 3 (Manual) Run the MML command DLD CERTFILE to download operator's root certificates
from the corresponding certificate & CRL database.
Step 4 (Manual) Run the MML command ADD TRUSTCERT for each CA trust certificate you
want to add.
NOTE
If multi-level CAs are deployed in an operator's PKI system, a complete certificate chain must be added.
If the certificates of different levels of CAs in the certificate chain are stored separately, run the ADD
TRUSTCERT command for each certificate you want to add.
Step 5 (Manual) Run the MML command REQ DEVCERT to set the information required for the
base station to apply for operator's device certificates.
NOTE
The certificate application procedure is triggered when this configuration takes effect.
The obtained certificate will be automatically loaded to CERTMK and the CA Switch is set to on.
If automatic certificate loading fails, run the MML command ADD CERTMK to manually load the
certificate.
Step 6 Run the MML command MOD IKEPEER. In this step, set parameters Certificate Source
and Certificate File Name to bind certificates to each IKE channel.
NOTE
This step is performed based on the assumption that the base station has been configured with IKE peers
(IKEPEER). If IKEPEER is not configured, you need to enable the IPsec feature and the MML
command used in this step is changed to ADD IKEPEER. For details about how to enable the IPsec
feature, see IPsec Feature Parameter Description.
Step 7 Run the MML command SET CERTCHKTSK to set a periodic certificate validity check
task.
----End
(Optional) After this feature is enabled, the CRL files of secondary operators can be
downloaded from the corresponding certificate & CRL database either manually or
automatically.
l Manual download
Step 1 Run the MML DLD CERTFILE for each CRL file you want to download.
Step 2 Run the MML command ADD CRL command for each CRL file you want to add.
----End
l Automatic download

SingleRAN
Step 1 Run the MML command ADD CRLTSK for each periodic CRL download task you want to
add.
----End

Assume that:
l Operator A is the primary operator and operator B is a secondary operator. Before the
reconstruction, the two operators use the certificate issued by operator A's PKI server for
authentication. After the reconstruction, operator B uses an independent PKI server.
l Operator A: C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca1
l Operator B: C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca2
//Turning on the CA switch in the CERTMK MO
MOD CERTMK:APPCERT=" opki1.cer",CASW=ON,CANAME="C = AU, S = Some-State, O =
Internet Widgits Pty Ltd, CN = eca1";
NOTE
The CA switch must be turned on for all certificates loaded to the base station except for the
//Setting CA information for operator B and use this information to customize a certificate
request template for the CA
If operator B' CA is accessible only through the external network, it is recommended that
interface IP addresses be used for certificate application and certificate update, and a
customized certificate request template be used. The following is an example:
eca2",URL="http://10.89.89.89:80/
pkix/",SIGNALG=SHA256,MODE=CFG_INIT_UPD_ADDR,UPDSIP="10.20.20.188",INITREQURL="10.
86.86.86:80/
pkix/",INITREQSIP="10.35.35.35",CERTREQSW=USERDEFINE,COMMNAME=ESN,USERADDINFO=".hu
awei.com",COUNTRY="cn",ORG="ITEF",ORGUNIT="hw",STATEPROVINCENAME="sc",LOCALITY="cd
",KEYUSAGE=DATA_ENCIPHERMENT-1&DIGITAL_SIGNATURE-1&KEY_AGREEMENT-1&KEY_ENCIPHERMEN
T-1,CERTREQSIGNALG=SHA256,KEYSIZE=KEYSIZE1024;
//(Manual triggering of CMPv2-based certificate application) Downloading operator B's root

certificate 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="OperationCA2.cer",DSTF="Op
erationCA2.cer";
//(Manual triggering of CMPv2-based certificate application) Setting operator B's root

certificate to the trust certificate
//(Manual triggering of CMPv2-based certificate application) Applying for operator B's root
certificate
REQ DEVCERT: CANAME="C=AU, S=Some-State, O=Internet Widgits Pty Ltd, CN=eca2",
APPCERT="OPKIDevCert2.cer";
//Configuring the certificate used for IKE negotiation

A customized certificate added using the ADD CERTMK command is used for IKE
negotiation for operator B and the certificate name is OpkiDevCert2.cer.

SingleRAN
MOD IKEPEER: PEERNAME="peer", PROPID=1, IKEVERSION=IKE_V2, IDTYPE=FQDN,

REMOTEIP="10.91.91.91",
DPD=PERIODIC,CTRLMODE=AUTO_MODE,REDUNDANCYFLAG=NONE,CERTSOURCE=CERTMK,CERTNAME="Op
kiDevCert2.cer";
//(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 for operator B

//(Optional) Adding a periodic CRL download task for operator B

ADD CRLTSK: IP="10.87.87.87", USR="admin", PWD="*****", FILENAME="eNodeB2.crl",
ISCRLTIME=DISABLE, PERIOD=24, TSKID=0, CRLGETMETHOD=FTP;
6.3.6.3 CME Single Configuration

6.3.6.4 CME Batch Configuration

Batch reconfiguration using the CME is the recommended method to activate a feature on an
existing base station. This method reconfigures all data, except neighbor relationships, for
multiple NEs in a single procedure.
Step 1 After creating a planned data area, choose CME > Advanced > Customize Summary Data
File (U2000 client mode), or choose Advanced > Customize Summary Data File (CME
client mode) 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 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.

SingleRAN
l For USUs: Choose CME > SRAN Application > USU Application > Export Data >
Export Base Station Bulk Configuration Data from the main menu of the U2000
client, or choose SRAN Application > USU Application > Export Data > Export
Base Station Bulk Configuration Data from the main menu of the CME client.
Step 3 In the summary data file, set the parameters in the MOs listed in Table 6-5 and close the file.
Step 4 Import the summary data file into the CME.

l For co-MPT multimode base stations: Choose CME > SRAN Application > MBTS
Application > Import Base Station Bulk Configuration Data from the main menu of
the U2000 client, or choose SRAN Application > MBTS Application > Import Data >
Import 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 > 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.
l For separate-MPT UMTS-involved multimode base stations or UO base stations: Choose
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.
l For separate-MPT LTE-involved multimode base stations or LO base stations: Choose
CME > 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 Base Station Bulk Configuration Data from the main menu of the
CME client.
l For USUs: Choose CME > SRAN Application > USU Application > Import Data >
Import Base Station Bulk Configuration Data from the main menu of the U2000
client, or choose SRAN Application > USU Application > Import Data > Import
Base Station Bulk Configuration Data from the main menu of the CME client.
For detailed instructions on the import or export operation, see U2000 Online Help.
----End
6.3.7 Activation Observation

Perform the following steps to observe the performance of this feature:
Step 1 Run the DSP APPCERT command to query the status of the global device certificate.
The values of Certificate File Name, Issuer, and Common Name are correct and the value
of Status is Normal. This indicates that the global device certificate has been loaded to the
base station.
Step 2 Run the DSP CERTMK command to query the binding relationships between a certificate
and the CA.
If the value of CA Switch in the returned result is ON, this feature has been enabled. You can
query the value of CA to check the CA server that issues the certificate.
Step 3 Run the DSP IKEPEER command to query the certificate used for IKE negotiation.
Check whether the certificate has taken effect by querying the values of Certificate Source
and Certificate File Name.

SingleRAN
Step 4 Run the DSP TRUSTCERT command to query the status of the trust certificate.
If the value of Status is Normal in the query result, the trust certificate has been loaded to the
base station.
Step 5 (Optional) Run the DSP CRL command to query the status of the CRL file.
If the value of Status in the returned result is NORMAL, the CRL has been loaded to the
base station.
----End
6.3.8 Deactivation (from Multi-PKI to No-PKI)

Step 1 Run the MML command RMV IPSECBIND/RMV IPSECPOLICY/RMV IKEPEER to
remove IPsec-related configurations.
NOTE
The MO CERTMK is referenced by the MO IKEPEER. Before running the RMV CERTMK
command, remove the reference relationships between the two MOs.
Step 2 (Optional) Run the MML command MOD APPCERT to modify the application certificate to
a preconfigured Huawei certificate.
NOTE
Skip this step if no operator-issued certificate is bound.
Step 3 Run the MML command RMV CERTMK to remove configurations of the CERTMK MO
(except for the preconfigured Huawei certificates).
NOTE
The MO CERTMK is referenced by the MO IKEPEER. Before running the RMV CA command,
remove the reference relationships between the two MOs.
Step 4 Run the RMV CA command to remove the configured CA information.
Step 5 (Optional) Run the MML command RMV CRLTSK to remove the periodic CRL acquisition
task started for multiple operators.
----End

//Removing the binding relationships between an IPsec policy group and a port
l Removing the binding relationships for operator A

RMV IPSECBIND:SN=6,SBT=BASE_BOARD,PT=ETH,PN=0,SPGN="A";
l Removing the binding relationships for operator B

RMV IPSECBIND:SN=7,SBT=BASE_BOARD,PT=ETH,PN=0,SPGN="A";
//Removing an IPsec policy
l Removing the IPsec policy for operator A (Policy Group Name = A, IPSec Sequence
No. = 10)
RMV IPSECPOLICY:SPGN="A",SPSN=10;

SingleRAN
l Removing the IPsec policy for operator B (Policy Group Name = B, IPSec Sequence No.
= 11)
RMV IPSECPOLICY:SPGN="A",SPSN=10;
//Removing an IKE peer

l Removing the IKE peer of operator A (IKE Peer Name = ike1)
RMV IKEPEER: PEERNAME="ike1";
l Removing the IKE peer of operator B (IKE Peer Name = ike2)

RMV IKEPEER: PEERNAME="ike2";
//Restoring the application certificate to the preconfigured Huawei certificate (Skip this step if
no operator-issued certificate is bound.)
MOD APPCERT:APPTYPE=IKE,APPCERT="appcert.pem";
//Removing the certificates loaded to the base station

l Remove operator A's certificate (Certificate File Name = eNodeBCert1.pem)
RMV CERTMK: APPCERT="eNodeBCert1.pem";
l Remove operator B's certificate (Certificate File Name = eNodeBCert2.pem)

//Removing the CAs configured for the base station

l Removing CA information for operator A
RMV CA: CANAME=" C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN =
eca1";
l Removing CA information for operator B

RMV CA: CANAME=" C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN =
eca2";
//Removing the periodic CRL acquisition task started for multiple operators
l Removing the periodic CRL acquisition task started for operator A (Task ID = 0)
RMV CRLTSK: TSKID=0;
l Removing the periodic CRL acquisition task started for operator B (Task ID = 1)
6.3.8.3 Using the CME

6.3.9 Deactivation (from Multi-PKI to Single-PKI)

Step 1 (Optional) Run the MOD APPCERT command to change the IKE certificate under the
APPCERT MO to the primary operator's certificate.
NOTE
Perform this step only when the IKE certificate specified by APPCERT is not the primary operator's
certificate.
Step 2 Run the MOD IKEPEER command to change the value of Certificate Source to
APPCERT for a secondary operator.

SingleRAN
NOTE
The MO CERTMK is referenced by the MO IKEPEER. Before running the RMV CERTMK
command, remove the reference relationships between the two MOs.
Step 3 Run the RMV CERTMK command to remove secondary operators' certificates loaded to the
base station.
NOTE
The MO CERTMK is referenced by the MO IKEPEER. Before running the RMV CA command,
remove the reference relationships between the two MOs.
Step 4 Run the RMV CA command to remove the PKI information configured for the secondary
operator.
Step 5 Run the MOD CERTMK command to change the value of CA Switch to OFF for all
operators.
Step 6 Run the MOD CA command to change the value of Certificate Request Switch for the
primary operator's CA to DEFAULT.
Step 7 (Optional) Run the MML command RMV CRLTSK to remove the periodic CRL acquisition
task started for multiple operators.
----End

//Modifying the IKE certificate specified by the APPCERT MO to the primary operator's
certificate (Skip this step if the IKE certificate specified by the APPCERT is the primary
operator's certificate.)
MOD APPCERT:APPTYPE=IKE,APPCERT="eNodeBCert1.pem";
//Modifying the binding relationships between operator B's IKE and the certificate (Certificate
Source = APPCERT, which means that operator B shares the certificate with operator A)
Assuming that the IKE peer of operator B is ike2
MOD IKEPEER:PEERNAME="ike2",CERTSOURCE=APPCERT;
//Removing secondary operators' certificates loaded to the base station

Assuming that the certificate file name is eNodeBCert2.pem
//Removing secondary operator's CA configured for the base station

RMV CA: CANAME=" C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca2";
//Changing the value of CA Switch to OFF for the primary operator's certificate that will
continue to use
MOD CERTMK:APPCERT=" eNodeBCert1.pem",CASW=OFF;
//Changing the value of Certificate Request Switch to DEFAULT

MOD CA:CANAME="C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN =
eca1",URL="http://10.88.88.88:80/pkix/",CERTREQSW=DEFAULT;
//Removing the periodic CRL acquisition task started for secondary operators
Assuming that the task ID is 1

SingleRAN
6.3.9.3 Using the CME

6.4 Performance Monitoring

N/A
6.5 Parameter Optimization

N/A
6.6 Troubleshooting
After the PKI feature is enabled, the following alarms may be reported if a fault related to PKI
occurs:
l ALM-26832 Peer Certificate Expiry
l ALM-26840 Imminent Certificate Expiry
l ALM-26841 Certificate Invalid
l ALM-26842 Automatic Certificate Update Failed
l For details about how to locate and analyze the problem, see the following documents:
For alarm reference of a certain type of base station, see 3900 Series Base Station Alarm
Reference.

SingleRAN
Parameter Description 7 Parameters
7 Parameters
Table 7-1 Parameters

MO Parame MML Feature Feature Description
ter ID Comma ID Name
nd
CA CERTR ADD LOFD-0 Public Meaning: Indicates the switch of certificate request
EQSW CA 81280 / Key configuration information. When this parameter is set
MOD TDLOF Infrastru to DEFAULT, the CA uses the request information
CA D-08121 cture(P configured in the CERTREQ MO. When this
0 KI) parameter is set to USERDEFINE, the CA requires
LST CA the customized certificate request information.
GBFD-1 BTS
71205 Supporti GUI Value Range: DEFAULT(DEFAULT),
ng PKI USERDEFINE(USERDEFINE)
WRFD- Unit: None
171220 NodeB
PKI Actual Value Range: DEFAULT, USERDEFINE
Support Default Value: DEFAULT(DEFAULT)
CERTM CASW ADD LOFD-0 Public Meaning: Indicates whether a CA server is specified
K CERTM 81280 / Key for a device certificate. When this parameter is set to
K TDLOF Infrastru OFF, only one CA is configured or no CA is
MOD D-08121 cture(P configured (the device certificate can be configured
CERTM 0 KI) only in the offline mode). When this parameter is set
K to ON, a CA needs to be specified.
GBFD-1 BTS
DSP 71205 Supporti GUI Value Range: OFF(Off), ON(On)
CERTM ng PKI Unit: None
K WRFD-
171220 NodeB Actual Value Range: OFF, ON
LST PKI Default Value: OFF(Off)
CERTM Support
K

SingleRAN

nd
IKEPEE CERTS ADD LOFD-0 IPsec Meaning: Indicates the source of the certificate used
R OURCE IKEPEE 81280 / for IKE negotiation in the multi-PKI scenario. When
R TDLOF BTS this parameter is set to APPCERT, the certificate
D-08121 Integrate configured by the APPCERT MO is used. When this
MOD d Ipsec
IKEPEE 0 parameter is set to CERTMK, the certificate
R NodeB configured by the CERTMK MO is used.
GBFD-1
DSP 71205 Integrate GUI Value Range: APPCERT(Appcert),
IKEPEE d IPSec CERTMK(Certmk)
R WRFD- Unit: None
171220
LST Actual Value Range: APPCERT, CERTMK
IKEPEE Default Value: APPCERT(Appcert)
R
IKEPEE CERTN ADD LOFD-0 IPsec Meaning: Indicates the name of the certificate file
R AME IKEPEE 81280 / used in the IKE negotiation in the multi-PKI scenario.
R TDLOF BTS
Integrate GUI Value Range: 1~64 characters
MOD D-08121
0 d Ipsec Unit: None
IKEPEE
R NodeB Actual Value Range: 1~64 characters
GBFD-1
DSP 71205 Integrate Default Value: None
IKEPEE d IPSec
R WRFD-
171220
LST
IKEPEE
R
CA COMM ADD LOFD-0 Public Meaning: Indicates the common name of the
NAME CA 81280 / Key certificate request file, which can be the electronic
MOD TDLOF Infrastru serial number (ESN), media access control (MAC)
CA D-08121 cture(P address, or IP address of a board.
0 KI) GUI Value Range: ESN(ESN), MAC(MAC), IP(IP)
LST CA
GBFD-1 BTS Unit: None
71205 Supporti Actual Value Range: ESN, MAC, IP
ng PKI
WRFD- Default Value: ESN(ESN)
171220 NodeB
PKI
Support

SingleRAN

nd
CA USERA ADD None None Meaning: Indicates the additional information about a
DDINF CA certificate common name. The information will be
O MOD added behind the value of the COMMNAME
CA parameter to compose a complete common name for a
certificate request file. The default value
LST CA is .huawei.com. A space is not supported before the
value of this parameter, that is, a space is not
supported before the character string. However, to
meet requirements of consistency checks performed
by some CA servers to the certificate common name
in a certificate request packet and that in a Huawei
device certificate, the certificate common name in a
certificate request packet is displayed as "Board
ESN"+space+"Common Name Additional Info" only
when the certificate common name in a Huawei
device certificate is "Board ESN"+space+"Common
Name Additional Info". For example, when the value
of this parameter is "eNodeB" and the certificate
common name in a Huawei device certificate is "ESN
eNodeB", a space is automatically added before
"eNodeB", that is, the certificate common name in a
certificate request packet is displayed as "ESN
eNodeB".
GUI Value Range: 0~32 characters
Unit: None
Actual Value Range: 0~32 characters
Default Value: .huawei.com
CA COUNT ADD LOFD-0 Public Meaning: Indicates the country where a BS is located.
RY CA 81280 / Key GUI Value Range: 0~0,2~2 characters
MOD TDLOF Infrastru
D-08121 cture(P Unit: None
CA
0 KI) Actual Value Range: 0~0,2~2 characters
LST CA
GBFD-1 BTS Default Value: NULL(empty string)
71205 Supporti
ng PKI
WRFD-
171220 NodeB
PKI
Support

SingleRAN

nd
CA ORG ADD LOFD-0 Public Meaning: Indicates the organization that owns a BS.
CA 81280 / Key GUI Value Range: 0~64 characters
MOD TDLOF Infrastru
CA
0 KI) Actual Value Range: 0~64 characters
LST CA
71205 Supporti
ng PKI
WRFD-
171220 NodeB
PKI
Support
CA ORGUN ADD LOFD-0 Public Meaning: Indicates the organization unit that owns a
IT CA 81280 / Key BS.
MOD TDLOF Infrastru GUI Value Range: 0~64 characters
CA D-08121 cture(P
0 KI) Unit: None
LST CA Actual Value Range: 0~64 characters
GBFD-1 BTS
71205 Supporti Default Value: NULL(empty string)
ng PKI
WRFD-
171220 NodeB
PKI
Support
CA STATEP ADD LOFD-0 Public Meaning: Indicates the state or province where a BS is
ROVIN CA 81280 / Key located.
CENA MOD TDLOF Infrastru GUI Value Range: 0~128 characters
ME CA D-08121 cture(P
0 KI) Unit: None
LST CA Actual Value Range: 0~128 characters
GBFD-1 BTS
71205 Supporti Default Value: NULL(empty string)
ng PKI
WRFD-
171220 NodeB
PKI
Support

SingleRAN

nd
CA LOCAL ADD LOFD-0 Public Meaning: Indicates the location of a BS.

ITY CA 81280 / Key GUI Value Range: 0~128 characters
MOD TDLOF Infrastru
CA
0 KI) Actual Value Range: 0~128 characters
LST CA
71205 Supporti
ng PKI
WRFD-
171220 NodeB
PKI
Support
CA KEYUS ADD LOFD-0 Public Meaning: Indicates the usage for a key, including
AGE CA 81280 / Key KEY_AGREEMENT (key negotiation),
MOD TDLOF Infrastru DATA_ENCIPHERMENT (data encryption),
CA D-08121 cture(P KEY_ENCIPHERMENT (key encryption), and
0 KI) DIGITAL_SIGNATURE (digital signature). This
LST CA parameter can be set to one or multiple values.
GBFD-1 BTS
71205 Supporti GUI Value Range:
ng PKI DATA_ENCIPHERMENT(DATA_ENCIPHERMEN
WRFD- T),
171220 NodeB DIGITAL_SIGNATURE(DIGITAL_SIGNATURE),
PKI KEY_AGREEMENT(KEY_AGREEMENT),
Support KEY_ENCIPHERMENT(KEY_ENCIPHERMENT)
Unit: None
Actual Value Range: DATA_ENCIPHERMENT,
DIGITAL_SIGNATURE, KEY_AGREEMENT,
KEY_ENCIPHERMENT
Default Value: DATA_ENCIPHERMENT:ON,
DIGITAL_SIGNATURE:ON,
KEY_AGREEMENT:ON,
KEY_ENCIPHERMENT:ON
CA CERTR ADD LOFD-0 Public Meaning: Indicates the signature algorithm for a
EQSIG CA 81280 / Key certificate request file. The signature algorithm can be
NALG MOD TDLOF Infrastru Secure Hash Algorithm 1 (SHA1), Message-Digest
CA D-08121 cture(P Algorithm 5 (MD5) or Secure Hash Algorithm 256
0 KI) (SHA256).
LST CA
GBFD-1 BTS GUI Value Range: SHA1(SHA1), MD5(MD5),
71205 Supporti SHA256(SHA256)
ng PKI Unit: None
WRFD-
171220 NodeB Actual Value Range: SHA1, MD5, SHA256
PKI Default Value: SHA256(SHA256)
Support

SingleRAN

nd
CA KEYSIZ ADD LOFD-0 Public Meaning: Indicates the length of a key, which can be
E CA 81280 / Key 1024 bits or 2048 bits.
MOD TDLOF Infrastru GUI Value Range: KEYSIZE1024(KEYSIZE1024),
CA D-08121 cture(P KEYSIZE2048(KEYSIZE2048)
0 KI)
LST CA Unit: None
GBFD-1 BTS Actual Value Range: KEYSIZE1024, KEYSIZE2048
71205 Supporti
ng PKI Default Value: KEYSIZE2048(KEYSIZE2048)
WRFD-
171220 NodeB
PKI
Support
CA LOCAL ADD LOFD-0 Public Meaning: Indicates the local name of a BS. This
NAME CA 81280 / Key parameter is used to generate the DNS name of the
MOD TDLOF Infrastru subject alternative name of a certificate, so as to verify
CA D-08121 cture(P the peer's identification in IKE negotiation. If this
0 KI) parameter is not configured, the BS automatically uses
LST CA the common name and its additional information to
GBFD-1 BTS generate the DNS name.
71205 Supporti
ng PKI GUI Value Range: 0~128 characters
WRFD- Unit: None
171220 NodeB
PKI Actual Value Range: 0~128 characters
Support Default Value: NULL(empty string)
CA LOCAL ADD LOFD-0 Public Meaning: Indicates the IP address of the subject
IP CA 81280 / Key alternative name of a certificate.
MOD TDLOF Infrastru GUI Value Range: Valid IP address
CA D-08121 cture(P
0 KI) Unit: None
LST CA Actual Value Range: Valid IP address
GBFD-1 BTS
71205 Supporti Default Value: 0.0.0.0
ng PKI
WRFD-
171220 NodeB
PKI
Support

SingleRAN

nd
CERTM CANA ADD LOFD-0 Public Meaning: Indicates the name of the CA server
K ME CERTM 81280 / Key specified by the certificate.
K TDLOF Infrastru GUI Value Range: 1~127 characters
MOD D-08121 cture(P
0 KI) Unit: None
CERTM
K Actual Value Range: 1~127 characters
GBFD-1 BTS
DSP 71205 Supporti Default Value: None
CERTM ng PKI
K WRFD-
171220 NodeB
LST PKI
CERTM Support
K

SingleRAN
Parameter Description 8 Counters
8 Counters
There are no specific counters associated with this feature.

SingleRAN
Parameter Description 9 Glossary
9 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

SingleRAN
Parameter Description 10 Reference Documents
10 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. PKI Feature Parameter Description for SingleRAN
7. 3900 Series Base Station Alarm Reference


Base Station Supporting Multi-Operator PKI (SRAN10.1 - 02)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Base Station Supporting Multi-Operator PKI (SRAN10.1 - 02)

Uploaded by

Copyright:

Available Formats

SingleRAN

Base Station Supporting Multi-

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

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

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

3 Certificate Management and Application.............................................................................. 10

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

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

1 About This Document

This document covers the following features:

l GBFD-171205 BTS Supporting Multi-operator PKI

LTE LTE FDD LTE TDD

eNodeB LTE FDD eNodeB LTE TDD eNodeB

eRAN LTE FDD eRAN LTE TDD eRAN

Table 1-1 provides the definitions of base stations.

Table 1-1 Base station definitions

Base Station Definition

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

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

Base Station Definition

eGBTS A base station configured with a GTMUb, UMPT_G, or UMDU_G and

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

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

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

1.2 Intended Audience

1.3 Change History

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

Feature change None None

Editorial change Corrected errors in 6.3.5.2 MML Command None

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

1.4 Differences Between Base Station Types

The following table defines the types of micro base stations.

Base Station Model RAT

BTS3202E LTE FDD

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

Feature Support by Macro, Micro, and LampSite Base Stations

GBFD-171205 BTS Supporting Multi- Yes No No

WRFD-171220 NodeB Supporting Yes Yes Yes

LOFD-081280 eNodeB Supporting Yes Yes Yes

TDLOFD-081206 eNodeB Supporting Yes No No

Function Implementation in Macro, Micro, and LampSite Base Stations

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

l Expensive spectrum licenses

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

Figure 2-1 Networking of Base Station Supporting Multi-operator PKI

The feature functions are described as follows:

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

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

Table 2-1 Function differences between single-PKI and multi-PKI

Certificate application Yes See 3.3.1 Certificate Application.

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

Figure 2-3 Differences in configuration objects used for configuring multi-PKI

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

3 Certificate Management and Application

Issue 02 (2015-04-20) Huawei Proprietary and Confidential 10

3.1 Certificate Preconfiguration Phase

3.2 Base Station Deployment Phase

Issue 02 (2015-04-20) Huawei Proprietary and Confidential 11

Comply with the following rules when deploying a multi-PKI network:

Issue 02 (2015-04-20) Huawei Proprietary and Confidential 12

Figure 3-2 Automatic base station deployment