Base Station Supporting Multi-Operator PKI (SRAN12.1 - 04) PDF

SingleRAN
Base Station Supporting Multi-

operator PKI Feature Parameter
Description
Issue 04
Date 2017-09-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2017. 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: [email protected]
Issue 04 (2017-09-30) 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.......................................................................................................................................................... 1
1.3 Change History............................................................................................................................................................... 2
1.4 Differences Between Base Station Types....................................................................................................................... 3
1.5 Functional differences between NB-IoT and FDD.........................................................................................................4
2 Overview......................................................................................................................................... 5
2.1 Background.....................................................................................................................................................................5
2.2 Introduction.................................................................................................................................................................... 5
2.3 Benefits........................................................................................................................................................................... 6
2.4 Architecture.................................................................................................................................................................... 7
3 Certificate Management and Application................................................................................ 8

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

SingleRAN
Parameter Description Contents
5.3 LOFD-081280 eNodeB Supporting Multi-operator PKI..............................................................................................17

5.4 TDLOFD-081206 eNodeB Supporting Multi-operator PKI........................................................................................ 18
5.5 MLOFD-081282 eNodeB Supporting Multi-operator PKI.......................................................................................... 18
6 Engineering Guidelines............................................................................................................. 19
6.1 When to Use................................................................................................................................................................. 19
6.1.1 Typical Scenarios.......................................................................................................................................................19
6.1.2 Unrecommended Scenarios....................................................................................................................................... 22
6.1.3 Forbidden Scenarios.................................................................................................................................................. 24
6.2 Required Information................................................................................................................................................... 24
6.3 Deployment.................................................................................................................................................................. 25
6.3.1 Deployment Process.................................................................................................................................................. 26
6.3.2 Requirements............................................................................................................................................................. 27
6.3.3 Data Preparation........................................................................................................................................................ 29
6.3.4 Precautions.................................................................................................................................................................31
6.3.5 Activation (from No-PKI to Multi-operator PKI)..................................................................................................... 32
6.3.5.1 Using the CME....................................................................................................................................................... 32
6.3.5.2 Using MML Commands......................................................................................................................................... 32
6.3.5.3 MML Command Examples.................................................................................................................................... 34
6.3.6 Activation (from Single-operator PKI to Multi-operator PKI)..................................................................................37
6.3.6.1 Using the CME....................................................................................................................................................... 37
6.3.7 Activation Observation..............................................................................................................................................40
6.3.8 Deactivation (from Multi-operator PKI to No-PKI)..................................................................................................41
6.3.8.1 Using the CME....................................................................................................................................................... 41
6.3.9 Deactivation (from Multi-operator PKI to Single-operator PKI).............................................................................. 42
6.3.9.1 Using the CME....................................................................................................................................................... 42
6.3.10 Reconfiguration....................................................................................................................................................... 43
6.4 Performance Monitoring...............................................................................................................................................44
6.5 Parameter Optimization................................................................................................................................................ 44
6.6 Possible Issues.............................................................................................................................................................. 44
7 Parameters..................................................................................................................................... 45
8 Counters........................................................................................................................................ 55
9 Glossary......................................................................................................................................... 56
10 Reference Documents............................................................................................................... 57
Issue 04 (2017-09-30) 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
l MLOFD-081282 eNodeB Supporting Multi-operator PKI
Unless otherwise specified, in this document, LTE, eNodeB, and eRAN always include FDD,
TDD, and NB-IoT. The "L", "T", and "M" in RAT acronyms refer to LTE FDD, LTE TDD,
and LTE NB-IoT, respectively.
For definitions of base stations described in this document, see section "Base Station
Products" in SRAN Networking and Evolution Overview Feature Parameter Description.
NOTE
Any parameters, alarms, counters, or managed objects (MOs) described herein apply only to the
corresponding software release. For future software releases, refer to the corresponding updated product
documentation.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the feature described herein
l Work with Huawei products
Issue 04 (2017-09-30) Huawei Proprietary and Confidential 1

SingleRAN
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
l Editorial change
Changes in wording or addition of information and any related parameters affected by
editorial changes.
SRAN12.1 04 (2017-09-30)
This issue includes the following changes.
Change Change Description Parameter

Type Change
Feature Supported this feature by 5900 series base stations. None

change For details, see the following sections:
l 6.6 Possible Issues
l 10 Reference Documents
Supported this feature by MDUC boards. For details, None

see 6.3.2 Requirements.
Editorial None None

change
SRAN12.1 03 (2017-06-29)
This issue includes the following changes.
Change Change Description Parameter

Type Change
Feature Added the support for NB-IoT by the BTS3912E. For None
change details, see 1.4 Differences Between Base Station
Types.
Editorial Revised the descriptions in this document. None

change
SRAN12.1 01 (2017-03-08)
This issue does not include any changes.

SingleRAN
SRAN12.1 Draft A (2016-12-30)

Draft A (2016-12-30) of SRAN12.1 introduces the following changes to Issue 03
(2016-06-23) of SRAN11.1.
Change Change Description Paramete

Type r Change
Feature The CERTCHKTSK.ISENABLE parameter will be disused CERTCH

change in later versions. From this version onwards, the certificate KTSK.IS
validity check task is started forcibly. If this parameter is set to ENABLE
DISABLE, the other parameters for the certificate validity
check task retain the recently configured values. For details,
see 6.3 Deployment.
Added the NB-IoT feature MLOFD-081282 eNodeB None

Supporting Multi-operator PKI. For details, see the following
sections:
l 1.1 Scope
l 1.4 Differences Between Base Station Types
l 1.5 Functional differences between NB-IoT and FDD
l 4 Related Features
l 5 Network Impact
l 6.3.2 Requirements
Editorial None None

change
1.4 Differences Between Base Station Types

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

Multi-operator PKI

SingleRAN
Feature ID Feature Name Supported Supported Supported

by Macro by Micro by
Base Base LampSite
Stations Stations Base
Stations
MLOFD-081282 eNodeB Supporting Yes Yes No

Multi-operator PKI
Among micro base stations, only BTS3912Es support NB-IoT. LampSite base stations do not
support NB-IoT.
Function Implementation in Macro, Micro, and LampSite Base Stations

Function Difference
Base Station Supporting The following micro base stations support this feature:
Multi-operator PKI l BTS3202E
l BTS3203E
l BTS3911E
Macro base stations: The eGBTS configured with a
GTMUb/GTMUc and the GBTS do not support this feature.
LampSite: Only the DBS3900 LampSite supports this
feature.
1.5 Functional differences between NB-IoT and FDD

NB-IoT NB-IoT Feature FDD FDD Feature Difference
Feature ID Name Feature ID Name
MLOFD-08128 eNodeB LOFD-0812 eNodeB None

2 Supporting Multi- 80 Supporting
operator PKI Multi-operator
PKI

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
(RAN Sharing for short), through which they can use one set of base station equipment to
cover the same area. For details on RAN Sharing, 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 reduces 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 systems of multiple operators, thereby enhancing base station transmission
reliability.
NOTE
In this document, the scenario where a base station is deployed with the PKI system of only one operator
is called single-operator PKI for short, and the scenario where a base station is deployed with the PKI
systems of multiple operators is called multi-operator PKI for short.
2.2 Introduction
This feature enables each operator to deploy its own PKI server on the base station. With this
feature, certificates from multiple operators can be loaded to and managed on the base station,
and certificate application, update, and revocation of one operator are independent from those
of another operator. The IPsec tunnel of each operator uses the certificates issued by its own
PKI server for authentication, as shown in Figure 2-1.

SingleRAN
Figure 2-1 Networking of Base Station Supporting Multi-operator PKI
Limitations
The Base Station Supporting Multi-operator PKI feature can be deployed only in RAN
Sharing scenarios. The eGBTS configured with a GTMUb or GTMUc and the GBTS do not
support this feature.
Specifications
l When PKI redundancy is used, 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 configured with six periodic certificate revocation list (CRL)
acquisition tasks, which can be configured using the CRLTSK managed object (MO).
l Each base station can be loaded with a maximum of 20 certificates, including
preconfigured Huawei certificates.
If operators use multi-level certificates and the certificates take up more storage space
than is available, then these certificates can be converted into the .p7b format to save
storage.
2.3 Benefits
In RAN Sharing scenarios, if each operator deploys its own PKI server, this feature provides
an independent IPsec tunnel for each operator so as to achieve the secure isolation of each
operator's 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

SingleRAN
Parameter Description 3 Certificate Management and Application
3 Certificate Management and Application
Table 3-1 describes the differences in certificate management and application between single-
operator PKI and multi-operator PKI. For the similarities, see PKI Feature Parameter
Description.
Table 3-1 Differences between single-operator PKI and multi-operator PKI
Function Is There a Difference Description

Difference?
CMPv2-based certificate No N/A

management
Certificat Certificate No N/A

e preconfiguration
manage phase
ment and
applicati Base station Yes See 3.2 Base Station Deployment
on deployment phase Phase.
Certificate application Yes See 3.3.1 Certificate Application.
Certificate sharing No N/A
Certificate validity No N/A

check
Certificate update No N/A
Certificate revocation No N/A
CRL acquisition No N/A
PKI networking No N/A

reliability
Digital certificate No N/A

usage in UMPT
+UMPT cold backup
mode

SingleRAN
3.1 Certificate Preconfiguration Phase

A base station is preconfigured with Huawei certificates before delivery. In multi-operator
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 digital certificates are 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 uses Secure Sockets Layer (SSL) protection.

SingleRAN
Figure 3-1 Networking for deploying Base Station Supporting Multi-operator PKI in RAN
Sharing scenarios
In comparison to deploying single-operator PKI, deploying Base Station Supporting Multi-

operator PKI has the following differences:
l Each operator's CA should be preconfigured with Huawei's root certificate and a Huawei
CRL (optional), which are used to verify Huawei-issued device certificates.
l Each operator's security gateway (SeGW) should be preconfigured with its own
operator's root certificate, an operator's CRL (optional), and an operator-issued device
certificate, which are used for the bidirectional authentication between the SeGW and the
Huawei base station.
l During automatic base station deployment, the base station needs to apply for a
certificate from the CAs of the two operators, and perform a bidirectional authentication
with each operator's SeGW.

SingleRAN
– In plug and play (PnP) base station deployment mode, the base station must first
apply for a certificate from the CA of the primary operator and then from the CA of
the secondary operator.
– In USB-based base station deployment mode, certificates can be applied for without
following the sequence described in Figure 3-1.
Figure 3-2 details base station deployment procedures illustrated in Figure 3-1.
Figure 3-2 Automatic base station deployment
NOTE
During CMPv2-based automatic certificate application, the preconfigured Huawei-issued device

certificate is used for SSL authentication.
Figure 3-3 illustrates the differences in configuration objects used for configuring multi-
operator PKI compared with those used for configuring single-operator PKI.

SingleRAN
Figure 3-3 Differences in configuration objects
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-operator 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.

SingleRAN
Set the CA.CERTREQSW parameter to USERDEFINE to customize a certificate

request template for the CA.
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.
NOTE
After the base station sends a CMPv2-based certificate request message to the CA, the
certificate application procedure fails if the certificate request times out. The waiting timeout
interval is 60s in single-operator PKI scenarios and is 20s for each PKI in multi-operator
PKI scenarios.
– After a successful certificate application, the obtained operator's certificate will be
automatically loaded to the CERTMK MO, and the CERTMK.CASW parameter
is automatically set to ON for this certificate.
l Before a reconstruction from single-operator PKI to multi-operator PKI, the
CERTMK.CASW parameter must be set to ON.
l After a successful certificate application, run the MOD APPCERT command to set a
certificate under the CERTMK MO 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 IKEPEER.CERTSOURCE and IKEPEER.CERTNAME parameters
to bind operators' certificates to IPsec tunnels.
3.3.2 Certificate Sharing

The SSL certificate sharing method in multi-operator PKI scenarios is the same as that in
single-operator 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-operator 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

In multi-operator PKI scenarios, a manual CMPv2-based certificate update procedure can
only be triggered for operators one by one. The automatic CMPv2-based certificate update
procedure in multi-operator PKI scenarios is the same as that in single-operator PKI
scenarios.
3.3.5 Certificate Revocation

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

SingleRAN
3.3.6 CRL Acquisition

In multiple-operator PKI scenarios:
l Operators' CRL servers are independent of each other and the CRL acquisition procedure
is the same as that in single-operator PKI scenarios.
l Only one global CRL policy can be configured for a base station. The global CRL policy
is configured using the CRLPOLICY MO.
l Each base station can be configured with six periodic CRL acquisition tasks, which can
be configured using the CRLTSK MO.
3.4 PKI Networking Reliability

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

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

SingleRAN
Parameter Description 4 Related Features
4 Related Features
4.1 GBFD-171205 BTS Supporting Multi-operator PKI

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

None
Impacted Features
None
4.2 WRFD-171220 NodeB Supporting Multi-operator PKI

Feature ID Feature Name Description
WRFD-050402 IP Transmission N/A

Introduction on Iub
Interface

None

SingleRAN
Parameter Description 4 Related Features
Impacted Features
None
4.3 LOFD-081280 eNodeB Supporting Multi-operator PKI

None

None
Impacted Features
None
4.4 TDLOFD-081206 eNodeB Supporting Multi-operator

PKI
None

None
Impacted Features
None
4.5 MLOFD-081282 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.
5.5 MLOFD-081282 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

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 an LTE single-mode base station 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 systems.
l The base station is managed by operator A.

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, as shown in Figure 6-1.
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 (the primary operator) 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.
As shown 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, enable IPsec
redundancy among multiple SeGWs. 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 Multi-operator PKI enabled with 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-5 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-related MOs are automatically configured during X2 self-setup in IPsec-
enabled scenarios.
In this scenario, the base station cannot determine which certificate to be used when
automatically generating the IKE peer.
For details about this scenario, see the "X2 Interface Self-Management in IPSec-enabled
Scenarios" section in S1 and 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 multi-operator PKI.
Figure 6-6 shows an example of multi-operator 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-operator PKI reconstruction
l Existing sites
An existing base station has been deployed with the PKI, PKI redundancy, or IPsec
redundancy among multiple SeGWs feature, and it needs to be deployed with base
station supporting multi-operator PKI.
Figure 6-7 shows an example of single-operator PKI to multi-operator 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-operator PKI to multi-operator 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
NE Type Board Configuration Board That Provides a Port Type
Port for Connecting
the Base Station to the
Transport Network
eGBTS UMPT/UMDU/MDUC UMPT/UMDU/MDUC Ethernet port
UMPT+UTRPc UTRPc
NodeB UMPT/UMDU/MDUC UMPT/UMDU/MDUC
UMPT/WMPT+UTRPc UTRPc
eNodeB UMPT/LMPT/UMDU LMPT/UMPT/UMDU
LMPT/UMPT+UTRPc UTRPc
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 Name
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
MLOFD-0 eNodeB ML1SESMU eNodeB eNode Per

81282 Supporting PKI0 Supporting Multi- B eNodeB
Multi-operator operator PKI(NB-
PKI IoT)
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
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-1 lists the data 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 multiple
SeGWs, see IPsec Feature Parameter Description.
The base station must initiate certificate application requests to the CA server of each
operator. 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-1 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 Transport

Request Switch template configured in the network plan
MOD CERTREQ (internal
command is used, set this plan)
parameter to
DEFAULT(DEFAULT).
l When a customized
certificate request template
is used, set this parameter to
USERDEFINE(USERDEF
INE).

SingleRAN

Name Source
Common Name COMMNAME These parameters are valid only

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

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

deployment is used, bind ult
certificates issued for all operators value
to the corresponding CA. In this /
case, set this parameter to ON(On) Reco
for each certificate. mme
l Set this parameter to OFF(Off) for nded
preconfigured Huawei certificates. value

SingleRAN

Name Sour
ce
Certificate CANAME This parameter is valid only when Trans

Authority CASW is set to ON(On). port
Name netw
ork
plan
(inter
nal
plan)
Table 6-3 lists the data to be prepared for an IKE peer (involving the IKEPEER MO in
MML and CME configurations).
Table 6-3 Data to be prepared for the IKE peer

Name Sour
ce
Certificate CERTSOURCE In multi-operator PKI scenarios, you Radi

Source need to bind a certificate for each o
IKEPEER MO. netw
l If the certificate configured by the ork
APPCERT MO is used, set this plan
parameter to APPCERT(Appcert). (nego
tiated
l If the certificate configured by the with
CERTMK MO is used, set this the
parameter to CERTMK(Certmk). peer
end)
Certificate File CERTNAME This parameter is valid only when Defa

Name CERTSOURCE is set to ult
CERTMK(Certmk). value
/
Reco
mme
nded
value
6.3.4 Precautions
During new PKI deployment, the IPsec tunnel needs to be reestablished, which interrupts
services.

SingleRAN
6.3.5 Activation (from No-PKI to Multi-operator PKI)

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

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

Type
Single configuration CME Management > CME Guidelines > Getting Started with
the CME > Introduction to Data Configuration Operations
Batch eGBTS CME Management > CME Guidelines > GSM Application
configuration Management > Base Station Related Operations > Importing
and Exporting eGBTS Data for Batch Reconfiguration
Batch NodeB CME Management > CME Guidelines > UMTS Application
configuration Management > NodeB Related Operations > Importing and
Exporting NodeB Data for Batch Configuration
Batch eNodeB CME Management > CME Guidelines > LTE Application
configuration Management > eNodeB Related Operations > Importing and
Exporting eNodeB Data for Batch Configuration
6.3.5.2 Using MML Commands
Configuring Base Station Supporting Multi-operator PKI

Step 1 (Optional, applicable only to separate-MPT base station) Run the SET CERTDEPLOY
command to specify the board where a certificate is to be deployed.
NOTE
You need to reset the base station to make the configuration take effect.
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 MOD CERTREQ command 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 ADD CA command to add CA information for each operator.

SingleRAN
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 (Optional, applicable only to manual certificate application) Run the DLD CERTFILE
command to download each operator's root certificate from the operator's certificate & CRL
database.
Step 5 (Optional, applicable only to manual certificate application) Run the ADD TRUSTCERT
command 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 (Optional, applicable only to manual certificate application) Run the REQ DEVCERT
command 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 ADD CERTMK command to load the certificate.
Step 7 Run the MOD APPCERT command 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 Deployment of IPsec > Deployment > Deploying
IPsec on an eGBTS/NodeB/eNodeB > Using MML Commands in IPsec Feature
Parameter Description.
Pay attention to the following configurations:
Run the ADD IKEPEER command. In this step, set 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 SET CERTCHKTSK command to set a periodic certificate validity check task.
----End

SingleRAN
(Optional) Loading the CRL File

After the Base Station Supporting Multi-operator PKI feature is enabled, CRL files can be
downloaded from each operator's certificate & CRL database to the base station manually or
automatically.
l Manual download
Step 1 Run the DLD CERTFILE command for each CRL file you want to download.
Step 2 Run the ADD CRL command for each CRL file you want to add.
Step 3 Run the SET CRLPOLICY command to configure the CRL policy.
Step 4 Run the ADD CRLTSK command for each periodic CRL download task you want to add.
----End
l Automatic download
----End
(Optional) Manually Triggering a Certificate Update

Step 1 Run the UPD DEVCERT command to set certificate update information. A CMPv2-based
certificate application is triggered after this configuration takes effect.
----End
6.3.5.3 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;
//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:

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

SingleRAN
//(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 //Manually applying for a digital certificate for operator A. 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=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
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;

SingleRAN
//(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.6 Activation (from Single-operator PKI to Multi-operator PKI)

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

This feature can be activated using the CME. This section uses the eNodeB as an example.
For detailed operations, see CME-based Feature Configuration or the CME online help (press
F1 in an active CME window).
Configuration CME Online Help
Type
Single configuration CME Management > CME Guidelines > Getting Started with
the CME > Introduction to Data Configuration Operations
Batch eGBTS CME Management > CME Guidelines > GSM Application
configuration Management > Base Station Related Operations > Importing
and Exporting eGBTS Data for Batch Reconfiguration
Batch NodeB CME Management > CME Guidelines > UMTS Application
configuration Management > NodeB Related Operations > Importing and
Exporting NodeB Data for Batch Configuration
Batch eNodeB CME Management > CME Guidelines > LTE Application
configuration Management > eNodeB Related Operations > Importing and
Exporting eNodeB Data for Batch Configuration

SingleRAN
Configuring Base Station Supporting Multi-operator PKI

Step 1 Specify a CA for the primary operator's certificate that has been loaded to the base station.
1. Run the LST CERTMK command to query information about the device certificate
configured on the base station.
2. Run the MOD CERTMK command. 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 ADD CA command to add CA information for each operator.
If the certificate request file used by the CA is different from that configured in the
CERTREQ MO, set Certificate Request Switch to USERDEFINE(USERDEFINE) to
customize a certificate request template for this CA.
Step 3 (Optional, applicable only to manual certificate application) Run the DLD CERTFILE
command to download each secondary operator's root certificate from the operator's
certificate & CRL database.
Step 4 (Optional, applicable only to manual certificate application) Run the ADD TRUSTCERT
command for the CA trust certificate of each secondary operator 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 (Optional, applicable only to manual certificate application) Run the REQ DEVCERT
command to set the information required by the base station to apply for operators' 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 ADD CERTMK command to load the certificate.
Step 6 Run the MOD IKEPEER command. In this step, set 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 SET CERTCHKTSK command to set a periodic certificate validity check task.
----End
(Optional) Loading the CRL File

After the Base Station Supporting Multi-operator PKI feature is enabled, CRL files can be
downloaded from each operator's certificate & CRL database to the base station manually or
automatically.

SingleRAN
l Manual download
Step 1 Run the DLD CERTFILE command for each CRL file you want to download.
Step 2 Run the ADD CRL command for each CRL file you want to add.
----End
l Automatic download
----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

SingleRAN
//(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.
MOD IKEPEER: PEERNAME="peer", PROPID=1, IKEVERSION=IKE_V2, IDTYPE=FQDN,
REMOTEIP="10.91.91.91",
DPD=PERIODIC,REDUNDANCYFLAG=NONE,CERTSOURCE=CERTMK,CERTNAME="OpkiDevCert2.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.7 Activation Observation

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

SingleRAN
6.3.8 Deactivation (from Multi-operator PKI to No-PKI)

The method of feature deactivation using the CME is the same as that of feature activation
using the CME. For detailed operations, see 6.3.5.1 Using the CME.

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, applicable only to binding an operator-issued certificate) Run the MML command
MOD APPCERT to modify the application certificate to a preconfigured Huawei certificate.
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;
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";

SingleRAN
//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.9 Deactivation (from Multi-operator PKI to Single-operator

PKI)

The method of feature deactivation using the CME is the same as that of feature activation
using the CME. For detailed operations, see 6.3.9.1 Using the CME.

Step 1 (Optional, applicable only when the IKE certificate under the APPCERT MO is not the
primary operator's certificate) Run the MOD APPCERT command to change the IKE
certificate under the APPCERT MO to 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.
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.

SingleRAN
Step 5 Run the MOD CERTMK command to change the value of CA Switch to OFF(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(DEFAULT).
Step 7 (Optional) Run the RMV CRLTSK command to remove the periodic CRL acquisition task
started for secondary operators.
----End

//Modify 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";
//Modify 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).
Assume that the IKE peer name of operator B is ike2.
MOD IKEPEER:PEERNAME="ike2",CERTSOURCE=APPCERT;
//Remove secondary operators' certificates loaded to the base station. Assume that the
certificate file name is eNodeBCert2.pem.
//Remove secondary operator's CA configured for the base station.

RMV CA: CANAME=" C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca2";
//Change the value of CA Switch to OFF for the primary operator's certificate that will be
used.
MOD CERTMK:APPCERT=" eNodeBCert1.pem",CASW=OFF;
//Change 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;
//Remove the periodic CRL acquisition task started for secondary operators. Assume that the
task ID is 1.
6.3.10 Reconfiguration
In Certificate Authority Name, the S and ST fields are regarded as the same field. Services
can be properly provided if the S field is used at the local end but the ST field is used at the
peer end.
To reconfigure the S or ST field, perform the following steps:
Step 1 Run the ADD CA command to add a CA.
Step 2 Run the MOD CERTMK command to modify the device certificate.

SingleRAN
Step 3 Run the RMV CA command to remove the old CA.
----End
MML command examples are as follows:
ADD CA:CANAME="C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN =
eca1",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;
MOD CERTMK:APPCERT=" opki1.cer",CASW=ON,CANAME="C = AU, ST = Some-State, O =

Internet Widgits Pty Ltd, CN = eca1";
RMV CA: CANAME=" C = AU, S = Some-State, O = Internet Widgits Pty Ltd, CN = eca1";
6.4 Performance Monitoring

N/A
6.5 Parameter Optimization

N/A
6.6 Possible Issues

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
After any of the preceding alarms is reported, O&M personnel need to find out the cause and
clear the alarm according to the alarm information. For the alarm reference of a certain type of
base station, see 3900 & 5900 Series Base Station Alarm Reference.

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

Parame NE MML Feature Feature Description
ter ID Comma ID Name
nd
ISENA BTS390 SET LBFD-0 Public Meaning: Indicates whether a task of certificate
BLE 0, CERTC 03010 / Key validity checking is started.
BTS390 HKTSK TDLBF Infrastru GUI Value Range: DISABLE(Disable),
0 LST D-00301 cture(P ENABLE(Enable)
WCDM CERTC 0/ KI)
A, MLBFD Unit: None
HKTSK
BTS390 -120003 Actual Value Range: DISABLE, ENABLE
0 LTE, 12 Default Value: ENABLE(Enable)
BTS590
0,
BTS590
0
WCDM
A,
BTS590
0 LTE

SingleRAN

nd
CERTR BTS390 ADD LBFD-0 Public Meaning: Indicates the switch of certificate request
EQSW 0, CA 03010 / Key configuration information. When this parameter is set
BTS390 MOD TDLBF Infrastru to DEFAULT, the CA uses the request information
0 CA D-00301 cture(P configured in the CERTREQ MO. When this
WCDM 0/ KI) parameter is set to USERDEFINE, the CA requires
A, LST CA MLBFD the customized certificate request information.
eNodeB
BTS390 -120003 Supporti GUI Value Range: DEFAULT(DEFAULT),
0 LTE, 12 ng USERDEFINE(USERDEFINE)
BTS590 LOFD-0 Multi-
0, Unit: None
81280 / operator
BTS590 TDLOF PKI Actual Value Range: DEFAULT, USERDEFINE
0 D-08120 Default Value: DEFAULT(DEFAULT)
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE
CASW BTS390 ADD LOFD-0 Public Meaning: Indicates whether a CA server is specified
0, CERTM 81280 / Key for a device certificate. When this parameter is set to
BTS390 K TDLOF Infrastru OFF, only one CA is configured or no CA is
0 MOD D-08121 cture(P configured (the device certificate can be configured
WCDM CERTM 0/ KI) only in the offline mode). When this parameter is set
A, K MLOFD to ON, a CA needs to be specified.
BTS390 -081282 GUI Value Range: OFF(Off), ON(On)
0 LTE, DSP
BTS590 CERTM Unit: None
0, K Actual Value Range: OFF, ON
BTS590 LST Default Value: OFF(Off)
0 CERTM
WCDM K
A,
BTS590
0 LTE

SingleRAN

nd
CERTS BTS390 ADD LOFD-0 Ipsec Meaning: Indicates the source of the certificate used
OURCE 0, IKEPEE 03009 / Multi- for IKE negotiation in the multi-PKI scenario. When
BTS390 R TDLOF mode this parameter is set to APPCERT, the certificate
0 MOD D-00300 BS configured by the APPCERT MO is used. When this
WCDM IKEPEE 9 Commo parameter is set to CERTMK, the certificate
A, R MRFD- n configured by the CERTMK MO is used.
BTS390 121136 IPSec(L GUI Value Range: APPCERT(Appcert),
0 LTE, DSP
IKEPEE MRFD- TE) CERTMK(Certmk)
BTS590
0, R 121146 Multi- Unit: None
BTS590 LST MRFD- mode Actual Value Range: APPCERT, CERTMK
0 IKEPEE 121156 BS
Commo Default Value: APPCERT(Appcert)
WCDM R
A, n
BTS590 IPSec(L
0 LTE TE
TDD)
Multi-
mode
BS
Commo
n
IPSec(N
B-IoT)
CERTN BTS390 ADD LOFD-0 Ipsec Meaning: Indicates the name of the certificate file
AME 0, IKEPEE 03009 / Multi- used in the IKE negotiation in the multi-PKI scenario.
BTS390 R TDLOF mode GUI Value Range: 1~64 characters
0 MOD D-00300 BS
WCDM 9 Unit: None
IKEPEE Commo
A, R MRFD- n Actual Value Range: 1~64 characters
BTS390 121136 IPSec(L Default Value: None
0 LTE, DSP
IKEPEE MRFD- TE)
BTS590
0, R 121146 Multi-
BTS590 LST MRFD- mode
0 IKEPEE 121156 BS
WCDM R Commo
A, n
BTS590 IPSec(L
0 LTE TE
TDD)
Multi-
mode
BS
Commo
n
IPSec(N
B-IoT)

SingleRAN

nd
COMM BTS390 ADD LBFD-0 Public Meaning: Indicates the common name of the
NAME 0, CA 03010 / Key certificate request file, which can be the electronic
BTS390 MOD TDLBF Infrastru serial number (ESN), media access control (MAC)
0 CA D-00301 cture(P address, or IP address of a board.
WCDM 0/ KI) GUI Value Range: ESN(ESN), MAC(MAC), IP(IP)
A, LST CA MLBFD eNodeB Unit: None
BTS390 -120003 Supporti
0 LTE, 12 ng Actual Value Range: ESN, MAC, IP
BTS590 LOFD-0 Multi- Default Value: ESN(ESN)
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE
USERA BTS390 ADD None None Meaning: Indicates the additional information about a
DDINF 0, CA certificate common name. The information will be
O BTS390 MOD added behind the value of the COMMNAME
0 CA parameter to compose a complete common name for a
WCDM certificate request file. The default value
A, LST CA is .huawei.com. A space is not supported before the
BTS390 value of this parameter, that is, a space is not
0 LTE, supported before the character string. However, to
BTS590 meet requirements of consistency checks performed
0, by some CA servers to the certificate common name
BTS590 in a certificate request packet and that in a Huawei
0 device certificate, the certificate common name in a
WCDM certificate request packet is displayed as "Board
A, ESN"+space+"Common Name Additional Info" only
BTS590 when the certificate common name in a Huawei
0 LTE 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

SingleRAN

nd
COUNT BTS390 ADD LBFD-0 Public Meaning: Indicates the country where a BS is located.
RY 0, CA 03010 / Key GUI Value Range: 0~0,2~2 characters
BTS390 MOD TDLBF Infrastru
0 D-00301 cture(P Unit: None
CA
WCDM 0/ KI) Actual Value Range: 0~0,2~2 characters
A, LST CA MLBFD eNodeB Default Value: NULL(empty string)
0 LTE, 12 ng
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE
ORG BTS390 ADD LBFD-0 Public Meaning: Indicates the organization that owns a BS.
0, CA 03010 / Key GUI Value Range: 0~64 characters
CA
WCDM 0/ KI) Actual Value Range: 0~64 characters
0 LTE, 12 ng
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE

SingleRAN

nd
ORGUN BTS390 ADD LBFD-0 Public Meaning: Indicates the organization unit that owns a
IT 0, CA 03010 / Key BS.
BTS390 MOD TDLBF Infrastru GUI Value Range: 0~64 characters
0 CA D-00301 cture(P
WCDM 0/ KI) Unit: None
A, LST CA MLBFD Actual Value Range: 0~64 characters
eNodeB
BTS390 -120003 Supporti Default Value: NULL(empty string)
0 LTE, 12 ng
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE
STATEP BTS390 ADD LBFD-0 Public Meaning: Indicates the state or province where a BS is
ROVIN 0, CA 03010 / Key located.
CENA BTS390 MOD TDLBF Infrastru GUI Value Range: 0~128 characters
ME 0 CA D-00301 cture(P
A, LST CA MLBFD Actual Value Range: 0~128 characters
eNodeB
BTS390 -120003 Supporti Default Value: NULL(empty string)
0 LTE, 12 ng
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE

SingleRAN

nd
LOCAL BTS390 ADD LBFD-0 Public Meaning: Indicates the location of a BS.
ITY 0, CA 03010 / Key GUI Value Range: 0~128 characters
CA
WCDM 0/ KI) Actual Value Range: 0~128 characters
0 LTE, 12 ng
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE
KEYUS BTS390 ADD LBFD-0 Public Meaning: Indicates the usage for a key, including
AGE 0, CA 03010 / Key KEY_AGREEMENT (key negotiation),
BTS390 MOD TDLBF Infrastru DATA_ENCIPHERMENT (data encryption),
0 CA D-00301 cture(P KEY_ENCIPHERMENT (key encryption), and
WCDM 0/ KI) DIGITAL_SIGNATURE (digital signature). This
A, LST CA MLBFD parameter can be set to one or multiple values.
eNodeB
BTS390 -120003 Supporti GUI Value Range:
0 LTE, 12 ng DATA_ENCIPHERMENT(DATA_ENCIPHERMEN
BTS590 LOFD-0 Multi- T),
0, 81280 / operator DIGITAL_SIGNATURE(DIGITAL_SIGNATURE),
BTS590 TDLOF PKI KEY_AGREEMENT(KEY_AGREEMENT),
0 D-08120 KEY_ENCIPHERMENT(KEY_ENCIPHERMENT)
WCDM 6/
A, Unit: None
MLOFD
BTS590 -081282 Actual Value Range: DATA_ENCIPHERMENT,
0 LTE DIGITAL_SIGNATURE, KEY_AGREEMENT,
KEY_ENCIPHERMENT
Default Value: DATA_ENCIPHERMENT:ON,
DIGITAL_SIGNATURE:ON,
KEY_AGREEMENT:ON,
KEY_ENCIPHERMENT:ON

SingleRAN

nd
CERTR BTS390 ADD LBFD-0 Public Meaning: Indicates the signature algorithm for a
EQSIG 0, CA 03010 / Key certificate request file.
NALG BTS390 MOD TDLBF Infrastru GUI Value Range: SHA1(SHA1), MD5(MD5),
0 CA D-00301 cture(P SHA256(SHA256)
WCDM 0/ KI)
A, LST CA MLBFD Unit: None
eNodeB
BTS390 -120003 Supporti Actual Value Range: SHA1, MD5, SHA256
0 LTE, 12 ng Default Value: SHA256(SHA256)
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE
KEYSIZ BTS390 ADD LBFD-0 Public Meaning: Indicates the length of a key, which can be
E 0, CA 03010 / Key 1024 bits or 2048 bits.
BTS390 MOD TDLBF Infrastru GUI Value Range: KEYSIZE1024(KEYSIZE1024),
0 CA D-00301 cture(P KEYSIZE2048(KEYSIZE2048)
WCDM 0/ KI)
A, LST CA MLBFD Unit: None
eNodeB
BTS390 -120003 Supporti Actual Value Range: KEYSIZE1024, KEYSIZE2048
0 LTE, 12 ng Default Value: KEYSIZE2048(KEYSIZE2048)
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE

SingleRAN

nd
LOCAL BTS390 ADD LBFD-0 Public Meaning: Indicates the local name of a BS. This
NAME 0, CA 03010 / Key parameter is used to generate the DNS name of the
BTS390 MOD TDLBF Infrastru subject alternative name of a certificate, so as to verify
0 CA D-00301 cture(P the peer's identification in IKE negotiation. If this
WCDM 0/ KI) parameter is not configured, the BS automatically uses
A, LST CA MLBFD the common name and its additional information to
eNodeB
BTS390 -120003 Supporti generate the DNS name.
0 LTE, 12 ng GUI Value Range: 0~128 characters
0, Unit: None
81280 / operator
BTS590 TDLOF PKI Actual Value Range: 0~128 characters
0 D-08120 Default Value: NULL(empty string)
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE
LOCAL BTS390 ADD LBFD-0 Public Meaning: Indicates the IP address of the subject
IP 0, CA 03010 / Key alternative name of a certificate.
BTS390 MOD TDLBF Infrastru GUI Value Range: Valid IP address
0 CA D-00301 cture(P
A, LST CA MLBFD Actual Value Range: Valid IP address
eNodeB
BTS390 -120003 Supporti Default Value: 0.0.0.0
0 LTE, 12 ng
0, 81280 / operator
BTS590 TDLOF PKI
0 D-08120
WCDM 6/
A, MLOFD
BTS590 -081282
0 LTE

SingleRAN

nd
CANA BTS390 ADD LOFD-0 Public Meaning: Indicates the name of the CA server
ME 0, CERTM 81280 / Key specified by the certificate.
BTS390 K TDLOF Infrastru GUI Value Range: 1~127 characters
0 MOD D-08121 cture(P
CERTM
A, K MLOFD Actual Value Range: 1~127 characters
BTS390 -081282 Default Value: None
0 LTE, DSP
BTS590 CERTM
0, K
BTS590 LST
0 CERTM
WCDM K
A,
BTS590
0 LTE

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 RFC 4210, "Internet X.509 Public Key Infrastructure Certificate Management
Protocol (CMP)"
2. IETF RFC 4211, "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 & 5900 Series Base Station Alarm Reference


Base Station Supporting Multi-Operator PKI (SRAN12.1 - 04) PDF

Uploaded by

Copyright:

Available Formats

Base Station Supporting Multi-Operator PKI (SRAN12.1 - 04) PDF

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 (SRAN12.1 - 04) PDF

Uploaded by

Copyright:

Available Formats

SingleRAN

Base Station Supporting Multi-

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 04 (2017-09-30) Huawei Proprietary and Confidential i

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

3 Certificate Management and Application................................................................................ 8

Issue 04 (2017-09-30) Huawei Proprietary and Confidential ii

5.3 LOFD-081280 eNodeB Supporting Multi-operator PKI..............................................................................................17

Issue 04 (2017-09-30) Huawei Proprietary and Confidential iii

1 About This Document

1.2 Intended Audience

Issue 04 (2017-09-30) Huawei Proprietary and Confidential 1

1.3 Change History

Change Change Description Parameter

Feature Supported this feature by 5900 series base stations. None

Supported this feature by MDUC boards. For details, None

Editorial None None

Change Change Description Parameter

Editorial Revised the descriptions in this document. None

Issue 04 (2017-09-30) Huawei Proprietary and Confidential 2

SRAN12.1 Draft A (2016-12-30)

Change Change Description Paramete

Feature The CERTCHKTSK.ISENABLE parameter will be disused CERTCH

Added the NB-IoT feature MLOFD-081282 eNodeB None

Editorial None None

1.4 Differences Between Base Station Types

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

Issue 04 (2017-09-30) Huawei Proprietary and Confidential 3

Feature ID Feature Name Supported Supported Supported

MLOFD-081282 eNodeB Supporting Yes Yes No

Function Implementation in Macro, Micro, and LampSite Base Stations

1.5 Functional differences between NB-IoT and FDD

MLOFD-08128 eNodeB LOFD-0812 eNodeB None

Issue 04 (2017-09-30) Huawei Proprietary and Confidential 4

Issue 04 (2017-09-30) Huawei Proprietary and Confidential 5

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

Issue 04 (2017-09-30) Huawei Proprietary and Confidential 6

Issue 04 (2017-09-30) Huawei Proprietary and Confidential 7

3 Certificate Management and Application

Table 3-1 Differences between single-operator PKI and multi-operator PKI

Function Is There a Difference Description

CMPv2-based certificate No N/A

Certificat Certificate No N/A

Certificate application Yes See 3.3.1 Certificate Application.

Certificate sharing No N/A

Certificate validity No N/A

Certificate update No N/A

Certificate revocation No N/A

CRL acquisition No N/A

PKI networking No N/A

Digital certificate No N/A

Issue 04 (2017-09-30) Huawei Proprietary and Confidential 8

3.1 Certificate Preconfiguration Phase

3.2 Base Station Deployment Phase