SSL (Sran9.0 01)

SingleRAN
SSL Feature Parameter Description
Issue 01
Date 2014-04-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. 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 01 (2014-04-30) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
SingleRAN
SSL 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.........................................................................................................................................4
2.1 Introduction....................................................................................................................................................................4
2.2 Benefits...........................................................................................................................................................................4
2.3 Application.....................................................................................................................................................................4
3 Technical Description...................................................................................................................6
3.1 SSL Protocol Stack.........................................................................................................................................................6
3.2 Procedure for Establishing an SSL Connection.............................................................................................................7
3.3 SSL Renegotiation Management....................................................................................................................................9
4 SSL Application Scenarios........................................................................................................12

4.1 OM Channel.................................................................................................................................................................12
4.1.1 OM Channel Between the Base Station and the U2000............................................................................................12
4.1.2 OM Channel Between the Base Station Controller and the U2000..........................................................................19
4.2 FTP Transmission.........................................................................................................................................................21
4.3 HTTP Transmission......................................................................................................................................................22
5 Related Features...........................................................................................................................24
5.1 Features Related to SSL (eGBTS Side)........................................................................................................................24
5.2 Features Related to SSL (NodeB Side)........................................................................................................................24
5.3 Features Related to SSL (eNodeB Side).......................................................................................................................25
5.4 Features Related to SSL (Base Station Controller Side)..............................................................................................25
6 Network Impact...........................................................................................................................26
7 Engineering Guidelines on the Base Station Side................................................................27
7.1 When to Use SSL.........................................................................................................................................................27
7.2 Required Information...................................................................................................................................................27
7.3 Planning........................................................................................................................................................................27
7.4 Deployment..................................................................................................................................................................28
Issue 01 (2014-04-30) Huawei Proprietary and Confidential ii

SingleRAN
SSL Feature Parameter Description Contents
7.4.1 Requirements.............................................................................................................................................................28
7.4.2 Data Preparation........................................................................................................................................................28
7.4.3 Precautions.................................................................................................................................................................32
7.4.4 Hardware Adjustment................................................................................................................................................32
7.4.5 Initial Configuration..................................................................................................................................................32
7.4.6 Activation Observation..............................................................................................................................................35
7.4.7 Reconfiguration.........................................................................................................................................................37
7.5 Configuring the OM Channel on the U2000................................................................................................................37
7.6 Performance Monitoring...............................................................................................................................................37
7.7 Parameter Optimization................................................................................................................................................37
7.8 Troubleshooting............................................................................................................................................................38
8 Engineering Guidelines on the Base Station Controller Side............................................39

8.1 When to Use SSL.........................................................................................................................................................39
8.2 Required Information...................................................................................................................................................39
8.3 Planning........................................................................................................................................................................39
8.4 Deployment..................................................................................................................................................................39
8.4.1 Requirements.............................................................................................................................................................40
8.4.2 Data Preparation........................................................................................................................................................40
8.4.3 Precautions.................................................................................................................................................................45
8.4.4 Hardware Adjustment................................................................................................................................................45
8.4.5 Initial Configuration..................................................................................................................................................45
8.4.6 Activation Observation..............................................................................................................................................46
8.4.7 Reconfiguration.........................................................................................................................................................46
8.5 Configuring the OM Channel on the U2000................................................................................................................47
8.6 Performance Monitoring...............................................................................................................................................47
8.7 Parameter Optimization................................................................................................................................................47
8.8 Troubleshooting............................................................................................................................................................47
9 Parameters.....................................................................................................................................48
10 Counters......................................................................................................................................59
11 Glossary.......................................................................................................................................60
12 Reference Documents...............................................................................................................61
Issue 01 (2014-04-30) Huawei Proprietary and Confidential iii

SingleRAN
SSL Feature Parameter Description 1 About This Document
1 About This Document
1.1 Scope
This document describes SingleRAN Security Socket Layer (SSL), including its basic principles,
related features, network impact, engineering guidelines, and parameters.
This document describes the following features.
l GBFD-113522 Encrypted Network Management

l MRFD-210305 Security Management
l LBFD-004003 Security Socket Layer
l TDLBFD-004003 Security Socket Layer
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.
Any managed objects (MOs), parameters, alarms, or counters described herein correspond to
the software release delivered with this document. Any future updates will be described in the
product documentation delivered with future software releases.
Table 1-1 lists the definitions of all kinds of macro base stations.
Issue 01 (2014-04-30) Huawei Proprietary and Confidential 1

SingleRAN
Table 1-1 Definitions of all kinds of base stations
Base Station Definition

Name
GBTS GBTS refers to a base station deployed with GTMU.
eGBTS eGBTS refers to a base station deployed with UMPT_G.
NodeB NodeB refers to a base station deployed with WMPT or UMPT_U.
eNodeB eNodeB refers to a base station deployed with LMPT or UMPT_L.
Co-MPT Co-MPT multimode base station refers to a base station deployed with
Multimode Base UMPT_GU, UMPT_GL, UMPT_UL, or UMPT_GUL, and it
Station functionally corresponds to any combination of eGBTS, NodeB, and
eNodeB. For example, Co-MPT multimode base station deployed with
UMPT_GU functionally corresponds to the combination of eGBTS
and NodeB.
Separate-MPT Separate-MPT multimode base station refers to a base station on which

Multimode Base different modes use different main control boards. For example, base
Station stations deployed with GTMU and WMPT are called separate-MPT
GSM/UMTS dual-mode base station.
1.2 Intended Audience

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

l Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions. There are
two types of changes, which are defined as follows:
l Feature change
Changes in features of a specific product version
l Editorial change
Changes in wording or addition of information that was not described in the earlier version
SRAN9.0 01 (2014-04-30)
This issue does not include any changes.
SRAN9.0 Draft B (2014-02-28)

This issue includes the following changes.

SingleRAN
Change Type Change Description Parameter

Change
Feature change None None
Editorial change Added the descriptions about the feature and function None
differences between different site types. For details, see
section 1.4 Differences Between Base Station Types.
SRAN9.0 Draft A (2014-01-20)

Compared with 02 (2013-07-30) of SRAN8.0, Draft A (2014-01-20) of SRAN9.0 includes the
following changes.
Change Type Change Description Parameter Change
Feature change Added the LTE TDD eRAN mode support None
the SSL feature.
Added the SSL renegotiation management Added the following

function. For details, see section 3.3 SSL parameters:
Renegotiation Management. l RENEGO
l RENEGOINTERVAL
Editorial change Added section 5.4 Features Related to None

SSL (Base Station Controller Side).
1.4 Differences Between Base Station Types

Feature Support by Macro, Micro, and LampSite Base Stations
None.
Function Implementation in Macro, Micro, and LampSite Base Stations

Working in either UMTS only or LTE FDD only mode, micro base stations do not support GSM,
LTE TDD, multimode, co-MPT, or separate-MPT scenarios. As integrated entities, micro base
stations do not involve such concepts as boards, cabinets, subracks, slots, or RRUs.

SingleRAN
SSL Feature Parameter Description 2 Overview
2 Overview
2.1 Introduction
SSL is a protocol that provides end-to-end communication security by encrypting segments of
network connections at the Application Layer for the Transport Layer that complies with the
TCP protocol. SSL provides security protection for high-layer application protocols, such as
Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and Telecommunication
Network Protocol (Telnet).
The SSL protocol is the predecessor of Transport Layer Security (TLS). SSL/TLS versions
include SSL1.0, SSL2.0, SSL3.0, TLS1.0, TLS1.1, and TLS1.2. SRAN8.0 supports SSL3.0,
TLS1.0, TLS1.1, and TLS1.2. Higher versions are backward compatible with lower versions.
In this document, SSL is used as a collective name for SSL and TLS.
2.2 Benefits
SSL ensures secure communication between the client and the server by establishing an SSL
connection. SSL provides the following security functions:
l Confidentiality: SSL encrypts data transmitted between communication parties to prevent

eavesdropping.
l Authentication: The communication parties must authenticate each other before
establishing an SSL connection.
l Integrity: SSL provides integrity protection for data transmitted between the
communication parties so that the data is not tampered with during transmission.
2.3 Application
SSL can be used to provide protection for:
l The OM channel between the base station and the U2000 or between the base station
controller and the U2000

SingleRAN
SSL Feature Parameter Description 2 Overview
l The FTP connection between the base station and the U2000 or between the base station
controller and the U2000.
l The HTTP connection between the base station and the LMT or between the base station
controller and the LMT.
l The HTTP connection between the base station and the CA server or between the base
station controller and the CA.
l The LDAP and FTP connection between the base station and the CRL server or between
the base station controller and the CRL.
NOTE
Unless otherwise specified, the base station controller in this document is a generic term for GSM and
UMTS modes.
The FTPS components of the U2000 do not support TLS1.2. Therefore, the connection between an NE and
the U2000 does not support TLS1.2.
For detailed descriptions about the application scenarios, see 4 SSL Application Scenarios.

SingleRAN
SSL Feature Parameter Description 3 Technical Description
3 Technical Description
3.1 SSL Protocol Stack

The SSL protocol stack consists of two protocol layers: the record layer and the handshake layer,
as shown in Figure 3-1.
Figure 3-1 SSL protocol stack
l Record layer
The record layer receives data from the application layer or transmits data to the application
layer. In addition, the record layer performs security-related operations, such as
compression/decompression, encryption/decryption, and message authentication code
(MAC) computation.
l Handshake layer
The handshake layer consists of three protocols:
Handshake protocol

SingleRAN
The handshake protocol establishes a security channel between the communication

parties before data transmission begins. During the handshake procedure, the
communication parties authenticate each other, select encryption algorithms, generate
keys, and initialize vectors.
ChangeCipherSpec protocol
After the communication parties agree on a set of new keys, each party sends a
ChangeCipherSpec message to notify the other party that subsequent messages will be
protected under the newly negotiated keys.
Alert protocol
An alert message conveys the severity of the alert. If there is a fatal alert message, the
SSL connection is immediately terminated.
3.2 Procedure for Establishing an SSL Connection

The procedure for establishing an SSL connection consists of two phases: the handshake phase
and the data transmission phase. Before data transmission, the client initiates an SSL handshake
with the server. If the SSL handshake is successful, data is fragmented into protected records
for transmission.
The purposes of the SSL handshake are as follows:
1. The client and the server agree on a set of encryption algorithms, integrity check algorithms,
and keys for the algorithms to secure data transmission.
2. The communication parties can choose whether to authenticate each other.
Figure 3-2 describes the general message exchange process between the client and the server
during an SSL handshake.
Figure 3-2 General message exchange process between the client and the server during an SSL
handshake

SingleRAN
The general message exchange process is described as follows:
1. The client sends a ClientHello message to the server. This message contains the following
information: SSL version, encryption algorithms, signature algorithms, key exchange
algorithms, and MAC algorithms supported by the client.
2. Upon receiving the ClientHello message, the server responds with a ServerHello message.
The ServerHello message contains the SSL version and algorithms selected by the server.
3. (Optional) If the client requests server authentication, the key exchange algorithm field in
the ClientHello message sent in Step 1 instructs the server to send its certificate. The server
then sends a Certificate message containing its certificate to the client.
4. (Optional) If the client does not request server authentication, the server sends a
ServerKeyExchange message to the client. The key contained in this message is used to
encrypt the ClientKeyExchange message sent later in Step 8 . If the client requests server
authentication but the Certificate message sent by the server does not contain complete key
information, the server sends a ServerKeyExchange message to the client to supplement
the key information.
5. (Optional) If the server requests client authentication, the server sends a CertificateRequest
message to the client.
6. The server sends the client a ServerHelloDone message, notifying the client that the
handshake is complete.
7. (Optional) If the client receives a CertificateRequest message from the server, the client
sends a Certificate message containing its certificate to the server.
8. The client sends a ClientKeyExchange message to the server. This message contains the
data for generating the keys for encryption algorithms and integrity check algorithms. The
data is encrypted using the key information described in Step 4 .
9. (Optional) If the client receives a CertificateRequest message from the server, the client
sends a CertificateVerify message which is signed by the private key associated with its
certificate to the server.
10. The client sends the server a ChangeCipherSpec message, notifying the server that the client
will use the negotiated algorithms for subsequent communications.
11. The client sends a Finished message to the server. The message is the first message that is
sent by the client and that is protected by using the negotiated algorithms. This message
contains the MAC of all messages transmitted during the handshake. The MAC is used to
check whether handshake messages have been tampered with during transmission.
12. The server sends the client a ChangeCipherSpec message, notifying the client that the server
will use the negotiated algorithms for subsequent communications.
13. The server sends the client a Finished message. The message is the first message that is
sent by the server and that is protected by using the negotiated algorithms.
After the handshake phase is complete, the client and the server begin to transmit data with SSL
protection.
For details about SSL, see the following protocols:
l RFC 6101 for SSL3.0

l RFC 2246 for TLS1.0

SingleRAN

l RFC 5246 and RFC 5746 for TLS renegotiation
3.3 SSL Renegotiation Management

l SSL renegotiation attack
SSL key renegotiation (SSL renegotiation for short) is used to negotiate a new cipher key
between the SSL communication parties. The new cipher key will replace the old one to
avoid key disclosure after a long period of usage.
The SSL renegotiation procedure is similar to the SSL handshake procedure, as shown in
Figure 3-3.
Figure 3-3 Comparison between the SSL renegotiation procedure and the SSL handshake
procedure
As shown in Figure 3-3, the procedure on the left is the SSL handshake procedure and the
procedure on the right is the SSL renegotiation procedure. The messages in the form of
"Encrypted (message name)" are encrypted, and other messages are transmitted in plaintext.
The SSL renegotiation procedure and SSL handshake procedure have identical signaling
messages. According to SSL protocols, only the ChangeCipherSpec message is transmitted
in plaintext, and other renegotiation messages are transmitted in encrypted channels in the
SSL renegotiation procedure.
According to RFC 4306, the SSL renegotiation procedure is proactively initiated by the
SSL client (or server) on an established SSL connection. The SSL server (or client)
passively accepts the SSL renegotiation request and generates a new cipher key after
calculation. During this procedure, the SSL client and server consume different calculation
resources. Generally, the calculation resources consumed at the SSL server are ten times
those at the SSL client during an SSL renegotiation procedure.
If a malicious SSL client frequently sends SSL renegotiation requests to the SSL server,
the SSL server consumes a large amount of or even uses up the calculation resources. As
a result, other SSL clients cannot initiate SSL connections to the SSL server. In the worst
case, the SSL server breaks down and a denial of service (DoS) attack occurs.
Currently, Huawei base station controller or base station in most cases works as the SSL
server and the peer end works as the SSL client in SSL connections. For example, on the

SingleRAN
SSL connection between a base station controller or base station and the U2000, the base
station controller or base station works as the SSL server and the U2000 works as the SSL
client.
l SSL renegotiation management
The principle of SSL negotiation management is as follows: The RENEGO and
RENEGOINTERVAL parameters are configured at the SSL server (base station controller
or base station) to limit the frequency of sending SSL renegotiations by SSL clients. This
prevents frequent SSL renegotiation transmissions from forming DoS attacks.
The RENEGO parameter specifies whether to allow SSL renegotiation. The
RENEGOINTERVAL parameter specifies the interval at which SSL renegotiation can be
initiated.
The following uses the base station controller or base station working as the SSL server as
an example to describe the configuration scenarios of the RENEGO and
RENEGOINTERVAL parameters.
Set RENEGO to Disable and leave RENEGOINTERVAL unspecified.
This configuration scenario indicates that the SSL renegotiation function is disabled on
the SSL server side. The SSL server rejects all SSL renegotiation requests sent by the
SSL client on the SSL connection. In addition, the SSL server returns Alert messages
with the level "Warning" and the cause value "no_renegotiation(100)" to the SSL client.
For version compatibility concerns, the SSL server will not actively disconnect the
current SSL connection due to SSL renegotiation rejections.
According to RFC 5246, upon receiving an SSL renegotiation rejection message with
the level "Warning", the SSL client can choose to continue using the current SSL
connection or disconnect it based on the SSL client's configuration.
Set RENEGO to Enable and RENEGOINTERVAL to X (minutes).
This configuration scenario indicates that the SSL renegotiation function is enabled on
the SSL server side, the SSL server can accept and process SSL renegotiation requests
sent by the SSL client, and the interval between two valid SSL renegotiation requests
is greater than X minutes. For example, when the SSL client sends the first SSL
renegotiation request message to the SSL server on the current SSL connection, the SSL
server accepts and processes the SSL renegotiation request and finally generates a new
cipher key if the SSL server determines that the request message is valid and the time
interval meets the requirement. Subsequently, when the SSL client sends another SSL
renegotiation request:
- If the interval between this SSL renegotiation request and the first SSL negotiation
request is smaller than or equal to X minutes, the SSL server rejects the SSL
renegotiation request and returns an Alert message with the level "Warning" and the
cause value "no_renegotiation(100)" to the SSL client. For version compatibility
concerns, the SSL server will not actively disconnect the current SSL connection due
to SSL renegotiation rejections.
- If the interval between this SSL renegotiation request and the first SSL negotiation
request is greater than X minutes, the SSL server accepts and processes the SSL
renegotiation request and finally generates a new cipher key after a series of
negotiations.
Set RENEGO to Enable and RENEGOINTERVAL to 0.
This configuration scenario indicates that the SSL renegotiation function is enabled on
the SSL server side, the SSL server can accept and process SSL renegotiation requests

SingleRAN
sent by the SSL client, and the interval between two SSL renegotiation requests is not
limited. That is, whenever the SSL client sends an SSL renegotiation request to the SSL
server, the SSL server will accept and process the SSL renegotiation request and finally
generate a new cipher key only if the SSL renegotiation request complies with RFC
5246.
This configuration scenario disables the SSL renegotiation management function.

SingleRAN
SSL Feature Parameter Description 4 SSL Application Scenarios
4 SSL Application Scenarios
4.1 OM Channel
SSL can be used to secure the data transmitted on the OM channel between the base station and
the U2000, and between the base station controller and the U2000.
4.1.1 OM Channel Between the Base Station and the U2000

Figure 4-1 shows a typical network topology in which SSL is applied to the OM channel between
the base station and the U2000. In this network topology, IPsec is not used to protect the OM
channel.
Figure 4-1 Network topology for SSL applied to the OM channel between the base station and
the U2000

SingleRAN
CRL: certificate revocation list DMZ: demilitarized zone
RA: registration authority CA: certificate authority
Before you configure SSL in this application scenario, you must set the connection type between
the U2000 and the base station to SSL and set the authentication method to "authenticate the
peer end" on the U2000. In addition, preconfigure the operator-issued device certificate and the
operator's root certificate on the U2000.
NOTE
Before establishing an SSL connection, the base station needs to obtain the operator-issued device
certificate and the operator's root certificate from the operator's public key infrastructure (PKI) system. For
details about how to obtain the certificates, see PKI Feature Parameter Description.
The process of establishing an SSL connection is as follows:
Step 1 The base station and the U2000 establish a TCP connection.
Step 2 The U2000 functions as an SSL client and initiates an SSL handshake with the base station.
Step 3 The U2000 authenticates the base station using the specified authentication method during the
SSL handshake. Whether the base station authenticates the U2000 depends on the configuration
file of the base station. After the authentication is successful, the base station and the U2000
establish an OM channel protected by SSL.
----End
NOTE
When using plug and play (PnP) for base station deployment, the U2000 can choose whether to authenticate
the base station. The base station does not authenticate the U2000 by default.
When an OM channel is protected by IPsec, the process of establishing an SSL connection on the OM
channel is the same as the previously mentioned process.
The SSL authentication method of the OM channel between the base station and the U2000 is
determined by both the U2000 and the base station, as described in Table 4-1.
Table 4-1 SSL authentication method of the OM channel between the base station and the U2000
SSL Configuration Configuration on Deployment Applicati

Authenticatio on the U2000 the Base Station Requirement on
n Method Side Side s Scenario
The base station Anonymous The AUTHMODE None Routine

and the U2000 do Authentication parameter is set to maintenan
not authenticate NONE(Verify ce and base
each other. None). station
deploymen
t by PnP

SingleRAN

Only the U2000 OSS The AUTHMODE Any of the Routine

authenticates the Authentication parameter is set to following maintenan
base station. NE NONE(Verify conditions is ce and base
None). met: station
l The base deploymen
station is t by PnP
preconfigur
ed with the
Huawei-
issued
device
certificate
and Huawei
root
certificate.
The U2000
is
preconfigur
ed with the
Huawei
root
certificate.
l The base
station is
preconfigur
ed with the
operator-
issued
device
certificate
and the
operator's
root
certificate.
The U2000
is
preconfigur
ed with the
operator's
root
certificate.

SingleRAN

The base station Bidirectional The AUTHMODE Any of the Routine

and the U2000 parameter is set to following maintenan
authenticate each PEER(Verify Peer conditions is ce
other. Certificate). met:
l Both the
base station
and the
U2000 are
preconfigur
ed with
Huawei-
issued
device
certificates
and Huawei
root
certificates.
l Both the
base station
and the
U2000 are
preconfigur
ed with
operator-
issued
device
certificates
and
operator's
root
certificates.

SingleRAN

Only the base NE The AUTHMODE Any of the Routine

station Authentication parameter is set to following maintenan
authenticates the OSS PEER(Verify Peer conditions is ce
U2000. Certificate). met:
l The base
station is
preconfigur
ed with the
Huawei
root
certificate.
The U2000
is
preconfigur
ed with the
Huawei-
issued
device
certificate
and Huawei
root
certificate.
l The base
station is
preconfigur
ed with the
operator's
root
certificate.
The U2000
is
preconfigur
ed with the
operator-
issued
device
certificate
and the
operator's
root
certificate.

SingleRAN
NOTE
When the PKI system is deployed in the operator's network, it is recommended that the base station and
the U2000 use operator-issued device certificates to authenticate each other.
When no PKI system is deployed in the operator's network, the base station and the U2000 can use only
Huawei-issued device certificates to authenticate each other or they do not authenticate each other.
The configuration of SSL authentication on the base station side is as follows:
l The AUTHMODE parameter specifies the authentication method used by the SSL
handshake between the base station and the U2000.
When AUTHMODE is set to NONE(Verify None), the base station does not
authenticate the U2000.
When AUTHMODE is set to PEER(Verify Peer Certificate), the base station
authenticates the U2000.
l To use SSL on the OM channel, set the APPTYPE parameter to SSL, and set the
APPCERT parameter to specify the device certificates used for SSL authentication.
OM Channel of a Single-Mode Base Station (eGBTS, NodeB, or eNodeB)

Figure 4-2 shows a network topology in which SSL is applied to the OM channel between a
single-mode base station and the U2000. SSL is based on the TCP protocol, whereas the OM
data of the GBTS is encapsulated in UDP packets. Therefore, SSL does not apply to the GBTS.
Figure 4-2 Network topology for SSL applied to the OM channel between a single-mode base
station and the U2000
The WMPT, which is the main control board of the NodeB, does not support certificate
deployment. If the U2000 chooses to authenticate the NodeB, the WMPT must share the

SingleRAN
certificates of the UTRPc. For details about certificate sharing, see PKI Feature Parameter
Description.
OM Channel of a Separate-MPT Multimode Base Station

When SSL is applied to the OM channels of a separate-MPT multimode base station, an SSL
connection needs to be established between each mode and the U2000. If a certain mode of the
base station wants to use SSL authentication and no certificates are configured on the main
control board of the mode, this main control board must share certificates of another board
through backplane.
Figure 4-3 uses the scenario in which different modes of a separate-MPT GSM/UMTS/LTE
multimode base station share the same IPsec tunnel as an example to describe certificate sharing.
Figure 4-3 Network topology for SSL applied to the OM channels between the separate-MPT
GSM/UMTS/LTE multimode base station and the U2000
As shown in Figure 4-2, the operator-issued device certificate and the operator's root certificate
of multimode base station 1 are deployed on the UMPT_L. If the NodeB and the U2000 want
to establish an SSL connection and the operator-issued device certificate will be used for
authentication, the UMPT_U needs to share the certificates of the UMPT_L through backplane.
The operator-issued device certificate and the operator's root certificate of multimode base
station 2 are deployed on the UTRPc. If two SSL connections need to be established between
the NodeB and the U2000 and between the eNodeB and the U2000, and the operator-issued
device certificate will be used for authentication, then the UMPT_U and UMPT_L need to share
the certificates of the UTRPc through backplane.
OM Channel of a Co-MPT Multimode Base Station

When SSL is applied to the OM channel of a co-MPT multimode base station, there is only one
OM channel between the base station and the U2000, as shown in Figure 4-4. In this scenario,
the SSL function is implemented by the UMPT_GUL.

SingleRAN
Figure 4-4 Network topology for SSL applied to the OM channel between the co-MPT
multimode base station and the U2000
For a hybrid-MPT multimode base station, OM channels need to be established between each
separate-MPT main control board and the U2000, and between the co-MPT main control board
and the U2000.
4.1.2 OM Channel Between the Base Station Controller and the

U2000
Whether SSL is applied to the OM channel between the base station controller and the U2000
depends on the setting of connection type on the U2000 side. The SSL authentication method
of the OM channel depends on the data configuration on both the U2000 and the base station
controller sides, as described in Table 4-2.
Table 4-2 SSL authentication method of the OM channel between the base station controller
and the U2000
SSL Configuration on Configuration on Deployment

Authentication the U2000 Side the Base Station Requirement
Method Controller Side
The base station Anonymous The AUTHMODE Both the base station
controller and the Authentication parameter is set to controller and the
U2000 do not NONE(Verify U2000 support the
authenticate each None). same anonymous
other. authentication
algorithm.

SingleRAN
SSL Configuration on Configuration on Deployment

Authentication the U2000 Side the Base Station Requirement
Method Controller Side
Only the U2000 OSS Authentication The AUTHMODE l The OMU board
authenticates the NE parameter is set to of the base station
base station NONE(Verify controller is
controller. None). preconfigured
with the Huawei-
issued device
certificate and the
Huawei root
certificate.
l The U2000 is
preconfigured
with the Huawei
root certificate.
The base station Bidirectional The AUTHMODE Both the U2000 and
controller and the parameter is set to the OMU board of
U2000 authenticate PEER(Verify Peer the base station
each other. Certificate). controller are
preconfigured with
the Huawei-issued
device certificate and
the Huawei root
certificate.
Only the base station NE Authentication The AUTHMODE l The OMU board
controller OSS parameter is set to of the base station
authenticates the PEER(Verify Peer controller is
U2000. Certificate). preconfigured
with the Huawei
root certificate.
l The U2000 is
preconfigured
with the Huawei-
issued device
certificate and the
Huawei root
certificate.
From SRAN7.0 onwards, the base station controller is preconfigured with Huawei-issued device
certificate and Huawei root certificate before delivery. All base station controllers are
preconfigured with the same Huawei-issued device certificate and the same Huawei root
certificate.
The base station controller supports applying for an operator-issued device certificate in U2000-
assisted certificate management mode. If network conditions are met, it is recommended that

SingleRAN
the U2000 apply for an operator-issued device certificate and then the base station controller
use the certificate to perform SSL authentication on the O&M channel.
If the base station controller is not preconfigured with Huawei-issued device certificate or
Huawei root certificate but the U2000 requests to authenticate the base station controller, the
base station controller and the U2000 first establish a non-SSL-protected OM channel or an OM
channel with SSL anonymous authentication. Then, the engineering personnel obtain the
Huawei-issued device certificate and Huawei root certificate for the base station controller in
U2000-assisted certificate management mode. Then, they configure these certificates on the base
station controller by using the certificate management function on the U2000. Finally, the
engineering personnel modify the SSL connection type and authentication method on both the
U2000 and the base station controller sides.
For details about the digital certificate, see PKI Feature Parameter Description.
4.2 FTP Transmission

Both base stations and base station controllers support FTP over SSL (FTPS) and can be
configured with the FTPS state firewall function. When a state firewall is configured, this
function enables an FTP client to send the message, switching the transmission mode of the
control connection channel to plaintext. In this way, the state firewall can identify and
dynamically open the port required for FTPS transmission.
Table 4-3 describes the application scenarios for FTPS.
Table 4-3 Application scenarios for FTPS
Application Scenario Description
The base station functions as the l The ENCRYMODE parameter specifies the
FTPS client. transmission encryption mode of the base station.
l The SSLCERTAUTH parameter specifies whether to
perform SSL authentication on the FTPS server.
l The SPTSTATEFWL parameter specifies whether an
FTPS connection can be set up when a state firewall is
configured.
The base station controller l The ENCRYMODE(BSC6900,BSC6910) parameter

functions as the FTPS client. specifies the transmission encryption mode of the base
station controller.
l The SSLCERTAUTH(BSC6900,BSC6910)
parameter specifies whether to perform SSL
authentication on the FTPS server.
l The SPTSTATEFWL(BSC6900,BSC6910)
parameter specifies whether an FTPS connection can
be set up when a state firewall is configured.
The base station controller The ENCRYMODE(BSC6900,BSC6910) parameter

functions as the FTPS server. specifies the transmission encryption mode of the base
station controller.

SingleRAN
FTPS is mainly applicable to the file transmission between the base station and the U2000,
between the base station and the base station controller, and between the base station controller
and the U2000.
NOTE
The certificates used for FTPS authentication are the same as those used for SSL authentication of the OM
channel.
4.3 HTTP Transmission

Both the base station and the base station controller support HTTP over SSL (HTTPS). HTTPS
is applicable to the communication between the base station and the LMT and between the base
station controller and the LMT.
The POLICY parameter specifies the login policy of the LMT for the base station and the base
station controller. Table 4-4 provides the mapping between the value of the POLICY parameter
and the login policy of the LMT.
Table 4-4 Mapping between the value of the POLICY parameter and the login policy of the
LMT
Value of the Input to the IE Displayed in Displayed Policy

POLICY Address Bar the Login Page in the LMT Descriptio
Parameter Operation n
Window
COMPATIBLE HTTP HTTP HTTP Compatibili

ty mode
HTTPS HTTPS HTTPS
HTTPS_ONLY HTTP HTTPS HTTPS HTTPS

connection
HTTPS HTTPS HTTPS is used for
both the
login page
and the
LMT
operation
window
LOGIN_HTTPS_O HTTP HTTPS HTTP HTTPS

NLY connection
HTTPS HTTPS HTTP is used only
for the login
page

SingleRAN
NOTE
The default value of the POLICY parameter is HTTPS_ONLY, indicating that HTTPS must be used in
both the login page and the LMT operation window.
The certificates used for HTTPS authentication are the same as those used for SSL authentication of the
OM channel. The corresponding root certificate must be preconfigured on the LMT. Otherwise, when you
attempt to log in to the LMT, a dialog box is displayed, indicating that the certificate is unreliable and
asking whether to continue. If you select Yes, you can log in to the LMT.
HTTPS can also apply to the Certificate Management Protocol v2 (CMPv2) message interaction
between the base station and the Certificate Authority (CA) server.

SingleRAN
SSL Feature Parameter Description 5 Related Features
5 Related Features
5.1 Features Related to SSL (eGBTS Side)

Prerequisite Features
This feature requires the GBFD-118601 Abis over IP feature.
When certificates are required for SSL authentication, this feature requires the GBFD-113526
BTS Supporting PKI feature.
Mutually Exclusive Features

None
Impacted Features
None
5.2 Features Related to SSL (NodeB Side)

When certificates are required for SSL authentication, this feature requires the WRFD-140210
NodeB PKI Support feature.

None
Impacted Features
None

SingleRAN
SSL Feature Parameter Description 5 Related Features
5.3 Features Related to SSL (eNodeB Side)

When certificates are required for SSL authentication, this feature requires the LOFD-003010
Public Key Infrastructure(PKI) feature.

None
Impacted Features
None
5.4 Features Related to SSL (Base Station Controller Side)

None

None
Impacted Features
None

SingleRAN
SSL Feature Parameter Description 6 Network Impact
6 Network Impact
System Capacity
No impact.
Network Performance
When SSL is used to provide encryption and integrity protection, the network bandwidth
utilization decreases slightly. For example, if the application-layer data length is 500 bytes and
the encryption algorithm and integrity check algorithm are 3DES and SHA1, respectively, the
network bandwidth utilization decreases by 4%. 3DES stands for Triple Data Encryption
Standard and SHA1 stands for Secure Hash Algorithm 1.

SingleRAN
SSL Feature Parameter Description 7 Engineering Guidelines on the Base Station Side
7 Engineering Guidelines on the Base Station

Side
7.1 When to Use SSL

When operators use the public IP network to carry wireless services, the public IP network cannot
ensure transmission security. In this case, it is recommended that SSL be used to provide
transmission security for the OM channel.
When certificates are required for SSL authentication, the PKI feature must be activated on the
base station side. For details about how to activate the PKI feature, see PKI Feature Parameter
Description.
7.2 Required Information

If the operator-issued device certificate is required for SSL authentication, deploy the PKI system
in the network. For the data required for deploying the PKI feature, see PKI Feature Parameter
Description.
7.3 Planning
RF Planning
N/A
Network Planning
N/A
Hardware Planning
Table 7-1 describes the hardware required for deploying SSL on eGBTSs, NodeBs, and
eNodeBs.

SingleRAN
Table 7-1 Hardware required for deploying SSL on eGBTSs, NodeBs, and eNodeBs
NE Board Board That Provides a Port for Port Type

Configuration Connecting the Base Station to
the Transport Network
eGBTS UMPT UMPT Ethernet port
UMPT+UTRPc UTRPc Ethernet port
NodeB WMPT or UMPT WMPT or UMPT Ethernet port
WMPT+UTRPc or UTRPc Ethernet port

UMPT+UTRPc
eNodeB LMPT or UMPT LMPT or UMPT Ethernet port
LMPT+UTRPc or UTRPc Ethernet port

UMPT+UTRPc
7.4 Deployment
7.4.1 Requirements
l If the operator-issued device certificate is used for SSL authentication, the PKI system
needs to be deployed in the network and the PKI feature needs to be activated on the base
station side. For details about how to deploy the PKI system, see PKI Feature Parameter
Description.
l If the Huawei-issued device certificate is used for SSL authentication, the PKI feature needs
to be activated on the base station side but the PKI system is not required in the network.
NOTE
When the Huawei-issued device certificate is used for SSL authentication, you need only to activate
the license for the PKI feature on the base station side because the default data configuration contains
the PKI feature data.
7.4.2 Data Preparation

The SSL configuration data is the same for the eGBTS, NodeB, and eNodeB. This section
describes only the SSL configuration. For the configuration of the PKI feature, see PKI Feature
Parameter Description.
SSL Connection for the OM Channel

1. (Optional) Collect the data in the CONNTYPE managed object (MO). The CONNTYPE
parameter in this MO specifies the connection type supported by the base station. The
CONNTYPE MO can be configured and managed only on the U2000.

SingleRAN
Table 7-2 Connection type supported by the base station
MO Parameter Parameter ID Setting Notes Data

Name Source
SSL Connection Type CONNTYPE l The default Network

value of this plan
parameter is
ALL(All
Type), which
indicates that
all connection
types,
including SSL
connections,
are supported.
l If this
parameter is
set to
ONLY_SSL
(Only SSL
Connection),
all application
data
transmitted
over the TCP
layer is
protected by
SSL. In this
case, if the
peer end does
not support
SSL, the
communicatio
n parties
cannot
establish a
connection.
Therefore,
exercise
caution when
setting this
parameter.
l The
recommended
value of this
parameter is
ALL(All
Type).

SingleRAN
2. Collect data in the SSL MO for the SSL authentication method of the OM channel. The
most important parameter in this MO is described in the following table. The SSL MO can
be configured and managed only on the U2000.
Table 7-3 SSL authentication method of the OM channel
MO Parameter Name Parameter ID Setting Notes Data

Source
SSL Authentication Mode AUTHMODE Set this Network plan

parameter based
on the network
plan.
l If the SSL
authenticatio
n method is
bidirectional
authenticatio
n, set this
parameter to
PEER
(Verify Peer
Certificate).
l If the SSL
authenticatio
n method is
anonymous
authenticatio
n or is that
only the
U2000
authenticates
the base
station, set
this
parameter to
NONE
(Verify
None).
The default
value of this
parameter is
NONE
(Verify
None).
3. Collect data in the APPCERT and APPCER MOs. The parameters in these MOs specify
the device certificate used for SSL authentication of the base station.

SingleRAN
Table 7-4 Certificate configuration
MO Parameter Name Parameter ID Setting Notes Data Source
APPCERT Application Type APPTYPE Set this Network plan

parameter to
SSL(SSL).
APPCERT Certificate File APPCERT Set this Network plan

Name parameter
based on the
network plan.
If the Huawei-
issued device
certificate is
used for SSL
authentication,
set this
parameter to
appcert.pem.
If the operator-
issued device
certificate is
used for SSL
authentication,
set this
parameter to
the name of the
certificate.
NOTE
Before activating the SSL feature on a separate-MPT multimode base station, configure SSL data for each
mode separately.
Before activating the SSL feature on a co-MPT multimode base station, configure only a set of SSL data,
which is shared by different modes of the base station.
Base Station Functioning as the FTPS Client

Collect data in the FTPSCLT MO. The parameters in this MO specify the FTPS connection
between the U2000 and a base station functioning as the FTPS client.
Table 7-5 Base station functioning as the FTPS client
FTPCLT Transport ENCRYMODE The recommended Network plan

Encrypted Mode value of this
parameter is
AUTO(AUTO).

SingleRAN
FTPCLT Support State SPTSTATEFW Set this parameter Network plan

Firewall L based on the
network plan.
FTPCLT Support SSL SSLCERTAUT If this parameter is Network plan

Certificate H set to YES(Yes),
Authentication the root certificate
used on the FTP
server must be
preconfigured on
the base station.
This root certificate
is used by the base
station to
authenticate the
device certificate of
the FTP server.
Login Policy of the LMT

Collect data in the WEBLOGINPOLICY MO for the login policy of the LMT.
Table 7-6 Login policy of the LMT
WEBLMT Policy for login to POLICY The Network plan

LMT and recommended
transmission value of this
parameter is
HTTPS
(HTTPS
Only).
7.4.3 Precautions
None.
7.4.4 Hardware Adjustment

N/A
7.4.5 Initial Configuration

This section describes how to initially configure the SSL feature by using either MML commands
or the CME. If the PKI system has been deployed in the network and the operator-issued device

SingleRAN
certificate is required for SSL authentication, you need to configure the PKI feature. For details
about how to configure the PKI feature, see PKI Feature Parameter Description.
Using MML Commands

l Configuring SSL for the OM channel
Step 1 Run the MML command MOD APPCERT to configure the device certificate used for SSL
authentication.
----End
l Setting the security policy for the FTP client

Run the MML command SET FTPSCLT to set the security policy for the FTP client.
l Setting the login policy of the LMT
Run the MML command SET WEBLOGINPOLICY to set the login policy of the LMT.
MML Command Examples

//Configuring the device certificate used for SSL authentication
MOD APPCERT: APPTYPE=SSL, APPCERT="appcert.pem";

//Setting the security policy for the FTP client
SET FTPSCLT: ENCRYMODE=Auto, SPTSTATEFWL=Yes, SSLCERTAUTH=Yes;

//Setting the login policy of the LMT
SET WEBLOGINPOLICY: POLICY=HTTPS_ONLY;
Using the CME to Perform Single Configuration

Set parameters on the CME configuration interface according to the MOs, parameters, and
application scenarios described in section 7.4.2 Data Preparation. For instructions on how to
perform the CME single configuration, see CME Single Configuration Operation Guide.
Using the CME to Perform Batch Configuration for Newly Deployed Base Stations
Enter the values of the parameters listed in Table 7-7 in a summary data file, which also contains
other data for the new base stations to be deployed. Then, import the summary data file into the
CME for batch configuration.
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 7-7 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.
l Some MOs in Table 7-7 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.

SingleRAN
Table 7-7 MOs related to the SSL feature
MO Sheet in the Parameter Group Remarks

Summary Data File
SSL Common Data Connection Type, Connection Type,

Authentication Method Authentication
Method
FTPCLT Common Data ENCRYMODE, -

SPTSTATEFWL,
SSLCERTAUTH
WEBLMT Common Data POLICY -
NOTE
During base station deployment by PnP, you can also set the Connection Type and Authentication Type
parameters in the PnP Parameters MO on the Auto Deployment sheet of a scenario-specific summary
data file.
For detailed operations on each type of base station, see the following sections in 3900 Series
Base Station Initial Configuration Guide:
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 eGBTSs and co-MPT multimode base stations, see section "Creating Co-MPT Base
Stations in Batches."
Using the CME to Perform Batch Configuration for Existing Base Stations
Batch reconfiguration using the CME is the recommended method to activate a feature on
existing base stations. This method reconfigures all data, except neighbor relationships, for
multiple base stations in a single procedure. The procedure is as follows:
Step 1 Choose CME > Advanced > Customize Summary Data File from the main menu of an U2000
client, or choose Advanced > Customize Summary Data File from the main menu of a CME
client, to customize a summary data file for batch reconfiguration.
NOTE
For context-sensitive help on a current task in the client, press F1.
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

SingleRAN
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.
Step 3 In the summary data file, set the parameters in the MOs listed in Table 7-7 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
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
----End
7.4.6 Activation Observation

l SSL for the OM channel
In the SSL connection management window of the U2000 client, check whether the
connection between the base station and the U2000 is normal. If the connection is normal,
SSL has been successfully activated on the OM channel.
l FTPS connection between the base station and the U2000
Check whether log files are being transmitted between the base station and the U2000 based
on FTPS as expected. If log file transmission is normal, an FTPS connection has been
successfully established between the base station and the U2000.
l HTTPS connection between the base station and the LMT
Set the login policy of the LMT for the base station to HTTPS and Log in to the base station
through the LMT. If you can successfully log in to the base station, an HTTPS connection
has been successfully established between the base station and the LMT.

SingleRAN
l SSL renegotiation management

SSL renegotiation takes place between the SSL server and the SSL client. Therefore, you
can check whether the SSL renegotiation function is enabled by capturing packets
transmitted between the SSL server and the SSL client.
Prerequisites:
An SSL connection has been established between the SSL server and the SSL client. Then,
enable the SSL client to send an SSL renegotiation request message to the SSL server. The
following shows how to observe SSL renegotiation management.
Figure 7-1 Observing SSL renegotiation management
As shown in Figure 7-1, you can determine whether SSL renegotiation management is
enabled by analyzing the messages transmitted between the SSL server and the SSL client:
If the SSL client sends an EncryptedHandshakeMessage to the SSL server immediately
after an SSL connection is established, this message is an encrypted Client Hello
handshake message, indicating that the SSL client initiates an SSL renegotiation
procedure.
Upon receipt of the EncryptedHandshakeMessage from the SSL client, if the SSL server
consecutively sends two to four EncryptedHandshakeMessages to the SSL client, the
SSL server has accepted and processed the SSL renegotiation request. Among these
message interactions, if both the SSL server and the SSL client send a

SingleRAN
ChangeCipherSpec message to the peer end, the SSL renegotiation procedure is

completed, and the new cipher keys are used for communication.
Upon receipt of the EncryptedHandshakeMessage from the SSL client, if the SSL server
responds with an Encrypted Alert message, the SSL server has rejected the SSL
renegotiation request.
7.4.7 Reconfiguration
N/A
7.5 Configuring the OM Channel on the U2000

Use the SSL connection management function on the U2000 to change the connection type and
authentication method used between the base station and the U2000. The detailed procedure is
as follows:
Step 1 Log in to the U2000, choose Security > Certificate Authentication Management > SSL
Connection Management (traditional style) or Security Management > NE Security >
Certificate Authentication Management > SSL Connection Management (application style)
to open the SSL connection management window.
Step 2 In the left pane, select the base station to configure. In the right pane, set the connection type
and authentication method, as shown in Figure 7-2.
----End
Figure 7-2 Changing the SSL configuration of an existing base station
For more information about managing NE certificates and preconfiguring certificates on the
U2000, see the "Procedure for Configuring Digital Certificates" section in U2000 Online
Help (Security Management > Data Management > Configuring Digital Certificates).
To check the status of an SSL connection between the base station and the U2000, select the
base station in the SSL connection management window and then check the value of the
Connection Status field. If the value of this field is Connected, an SSL connection has been
successfully established.
7.6 Performance Monitoring

N/A
7.7 Parameter Optimization

N/A

SingleRAN
7.8 Troubleshooting
After the SSL feature is activated, the base station may report the following alarm:
ALM-25950 Excessive Flood Packet; the value of the Specific Problem parameter in the alarm
help is SSL Renegotiation.
After the PKI feature is activated, the base station may report the following alarms:
l ALM-26840 Imminent Certificate Expiry

l ALM-26841 Certificate Invalid
l ALM-26842 Automatic Certificate Update Failed
l ALM-26832 Peer Certificate Expiry
For details about how to locate and analyze the problem, see 3900 Series Base Station Alarm
Reference.

SingleRAN
SSL Feature Parameter Description 8 Engineering Guidelines on the Base Station Controller Side
8 Engineering Guidelines on the Base Station

Controller Side
8.1 When to Use SSL

When the base station controller and the U2000 are located in different networks, it is
recommended that the SSL feature be activated to secure the OM channel between the base
station controller and the U2000.
8.2 Required Information

None
8.3 Planning
RF Planning
N/A
Network Planning
N/A
Hardware Planning
N/A
8.4 Deployment

SingleRAN
8.4.1 Requirements
If certificates are required to authenticate the SSL connection of the OM channel, ensure that
the device certificate and root certificate have been preconfigured on the OMU board of the base
station controller.
For details about how to configure the certificates for the base station controller, see PKI Feature
Parameter Description.
8.4.2 Data Preparation
SSL Connection for the OM Channel

1. (Optional) Collect the data in the CONNTYPE MO. The CONNTYPE parameter in this
MO specifies the connection type supported by the base station controller. The
CONNTYPE MO can be configured and managed only on the U2000.

SingleRAN
Table 8-1 Connection type supported by the base station controller
MO Parameter Paramet Setting Notes Data Source

Name er ID
SSL Connection Type CONNTY The default value Network plan

PE of this parameter is
ALL(All Type),
which indicates
that all connection
types, including
SSL connections,
are supported.
If this parameter is
set to ONLY_SSL
(Only SSL
Connection), all
application data
transmitted over
the TCP layer is
protected by SSL.
In this case, if the
peer end does not
support SSL, the
communication
parties cannot
establish a
connection.
Therefore, exercise
caution when
setting this
parameter.
The recommended
value of this
parameter is ALL
(All Type).
2. Collect data in the SSLAUTHMODE MO for the SSL authentication method of the OM
channel. The most important parameter in this MO is described in the following table.

SingleRAN
Table 8-2 SSL authentication method of the OM channel
MO Parameter Parameter ID Setting Notes Data Source

Name
SSLAUTHM Authenticatio AUTHMODE Set this Network plan

ODE n Mode parameter
based on the
network plan.
l If the SSL
authenticati
on method
is
bidirectiona
l
authenticati
on, set this
parameter
to PEER
(Verify
Peer
Certificate
).
l If the SSL
authenticati
on method
is
anonymous
authenticati
on or is that
only the
U2000
authenticat
es the base
station
controller,
set this
parameter
to NONE
(Verify
None).
The
recommend
ed value of
this
parameter
is PEER
(Verify
Peer
Certificate
).

SingleRAN
3. Collect the data of the certificates to authenticate the SSL connection of the OM channel.
For details see PKI Feature Parameter Description.
Base Station Controller Functioning as the FTPS Client

Collect data in the FTPSCLT MO. The parameters in this MO specify the FTPS connection
between the U2000 and the base station controller functioning as the FTPS client.
Table 8-3 Base station controller functioning as the FTPS client
MO Parameter Name Para Setting Notes Data Source

meter
ID
FTPSCLT The Encrypted Mode ENCR The Network plan

YMO recommended
DE value of this
( parameter is
BSC6 AUTO(AUTO).
900,
BSC6
910)
FTPSCLT Support State Firewall SPTS Set this parameter Network plan
TATE based on the
FWL network plan.
(
BSC6
900,
BSC6
910)
FTPSCLT Support SSL Certificate SSLC If this parameter is Network plan

Authentication ERTA set to YES(Yes),
UTH the root certificate
( used on the FTP
BSC6 server must be
900, preconfigured on
BSC6 the base station
910) controller. This
root certificate is
used by the base
station controller
to authenticate the
device certificate
of the FTP server.

SingleRAN
Base Station Controller Functioning as the FTPS Server

Collect data in the FTPSSRV MO. The parameters in this MO specify the FTPS connection
between the U2000 and the base station controller functioning as the FTPS server.
Table 8-4 Base station controller functioning as the FTPS server
MO Parameter Parameter ID Setting Notes Data

Name Source
FTPSSRV The ENCRYMODE The recommended value of Network

Encrypted (BSC6900, this parameter is AUTO plan
Mode BSC6910) (Automatic).
FTPSSRV The Type DFTPORTSWT Set this parameter to the Network

of FTP (BSC6900, default port (port 21) or a plan
Server BSC6910) customized port number.
Command
Port
FTPSSRV The SRVCMDPORT Set this parameter only when Network

Command (BSC6900, the DFTPORTSWT plan
Port of BSC6910) (BSC6900,BSC6910)
FTP Server parameter is set to
CUSTOMPORT.
FTPSSRV The Source SRVDATAPOR Set this parameter only when Network
Data Port T the DFTPORTSWT plan
of FTP (BSC6900, (BSC6900,BSC6910)
Server BSC6910) parameter is set to
CUSTOMPORT.
FTPSSRV Passive ACDPORTLWL - Network

mode data T plan
port lower (BSC6900,
limit BSC6910)
FTPSSRV Passive ACDPORTUPL - Network

mode data T plan
port upper (BSC6900,
limit BSC6910)
Login Policy of the LMT

Collect data in the WEBLOGINPOLICY MO for the login policy of the LMT.

SingleRAN
Table 8-5 Setting the login policy of the LMT
MO Parameter Parameter ID Setting Notes Data Source

Name
WEBLOGINP Policy for login POLICY The Network plan

OLICY to LMT and (BSC6900, recommended
transmission BSC6910) value of this
parameter is
HTTPS
(HTTPS Only).
8.4.3 Precautions
None
8.4.4 Hardware Adjustment

N/A
8.4.5 Initial Configuration

This section describes how to initially configure the SSL feature on the base station controller
by using MML commands.
Using MML Commands

Step 1 Run the MML command SET SSLAUTHMODE to set the SSL authentication method.
Step 2 Run the MML command MOD APPCERT to configure the certificates used for SSL
authentication.
----End

Run the MML command SET FTPSCLT to set the security policy for the FTP client.
l Setting the security policy for the FTP server
Run the MML command SET FTPSSRV to set the security policy for the FTP server.
Run the MML command SET WEBLOGINPOLICY to set the login policy of the LMT.
MML Command Examples

//Setting the SSL authentication method
SET SSLAUTHMODE: AUTHMODE=PEER;
//Configuring the certificates used for SSL authentication

SingleRAN
MOD APPCERT: APPTYPE=SSL,APPCERT="_ClientCer.pem";

//Setting the security policy for the FTP client
SET FTPSCLT: ENCRYMODE=Auto, SPTSTATEFWL=Yes, SSLCERTAUTH=Yes;
l Setting the security policy for the FTP server

//Setting the security policy for the FTP server
SET FTPSSRV: ENCRYMODE=AUTO,
DFTPORTSWT=DEFAULTPORT,ACDPORTLWLT=25000,ACDPORTUPLT=30000;

//Setting the login policy of the LMT
SET WEBLOGINPOLICY: POLICY=HTTPS;
Using the CME to Perform Single Configuration

Set parameters on the CME configuration interface according to the MOs, parameters, and
application scenarios described in section 8.4.5 Initial Configuration For instructions on how
to perform the CME single configuration, see CME Single Configuration Operation Guide.
Using the CME to Perform Batch Configuration

Not supported.
8.4.6 Activation Observation

l SSL for the OM channel
In the SSL connection management window of the U2000 client, check whether the
connection between the base station controller and the U2000 is normal. If the connection
is normal, SSL has been successfully activated on the OM channel.
l Base station controller functioning as the FTPS client
On the U2000, set the transmission mode to FTPS and select the target base station
controller in the navigation tree. On the license interface of the base station controller,
deliver a license file to the base station controller. Check whether the license file is
successfully transmitted. If yes, the FTPS function is successfully enabled.
l Base station controller functioning as the FTPS server
On the LMT offline tool, set the FTP client to FTPS mode. Log in to the FTP server of the
base station controller and upload a test file (for example, test.txt) to the base station
controller. Check whether the test file is successfully uploaded. If yes, the FPTS function
is successfully enabled.
l HTTPS connection between the base station controller and the LMT
Set the login policy of the LMT for the base station controller to HTTPS and Log in to the
base station controller from the LMT. If you can successfully log in to the base station
controller, an HTTPS connection has been successfully established between the base station
controller and the LMT.
8.4.7 Reconfiguration
N/A

SingleRAN
8.5 Configuring the OM Channel on the U2000

On the U2000, you can change the connection type and authentication method used between the
base station controller and the U2000 by using the SSL connection management function on the
U2000. The detailed procedure is as follows:
Step 1 Log in to the U2000, choose Security > Certificate Authentication Management > SSL
Connection Management (traditional style) or Security Management > NE Security >
Certificate Authentication Management > SSL Connection Management (application style)
to open the SSL connection management window.
Step 2 In the left pane, select the base station controller to be configured. In the right pane, set the
connection type and authentication method, as shown in Figure 8-1.
----End
Figure 8-1 Changing the SSL configuration of an existing base station controller
For more information about managing NE certificates and preconfiguring certificates on the
U2000, see the "Procedure for Configuring Digital Certificates" section in U2000 Online
Help (Security Management > Data Management > Configuring Digital Certificates >).
To check the status of an SSL connection between the base station controller and the U2000,
select the base station controller in the SSL connection management window and then check the
value of the Connection Status field. If the value of this field is Connected, an SSL connection
has been successfully established.
8.6 Performance Monitoring

N/A
8.7 Parameter Optimization

N/A
8.8 Troubleshooting
After the SSL feature is activated, the base station controller may report the following alarm:
l ALM-20851 Digital Certificate Loss, Expiry, or Damage
For details about how to locate and analyze the problem, see the following documents:
l BSC6900 Alarm Reference

l BSC6910 Alarm Reference

SingleRAN
SSL Feature Parameter Description 9 Parameters
9 Parameters
Table 9-1 Parameter description
Parame NE MML Feature Feature Description

ter ID Comma ID Name
nd
RENEG BTS390 SET None None Meaning: Indicates Whether the NE supports the SSL
O 0, SSLCO renegotiation.
BTS390 NF GUI Value Range: DISABLE(Disable Renegotiation),
0 LST ENABLE(Enable Renegotiation)
WCDM SSLCO
A, Unit: None
NF
BTS390 Actual Value Range: DISABLE, ENABLE
0 LTE Default Value: ENABLE(Enable Renegotiation)
RENEG BTS390 SET None None Meaning: Indicates Minimum interval between two
OINTE 0, SSLCO consecutive SSL renegotiations supported by the NE.
RVAL BTS390 NF GUI Value Range: 0~60
0 LST
WCDM Unit: min
SSLCO
A, NF Actual Value Range: 0~60
BTS390 Default Value: 60
0 LTE
AUTH BTS390 SET MRFD- Security Meaning: If Authentication Mode to is set to PEER
MODE 0, SSLAU 210305 Manage (Verify Peer Certificate), the NE must verify the
BTS390 THMO ment certificate of the U2000 or LMT during SSL connection
0 DE setup. If the certificate verification fails, the SSL
WCDM LST connection cannot be set up.
A, SSLCO GUI Value Range: NONE(Verify None), PEER(Verify
BTS390 NF Peer Certificate)
0 LTE
Unit: None
Actual Value Range: NONE, PEER
Default Value: NONE(Verify None)

SingleRAN

nd
APPTY BTS390 DSP LOFD-0 Public Meaning: Indicates the application type of activated
PE 0, APPCE 03010 / Key device certificate. There are two types: IKE and SSL.
BTS390 RT TDLOF Infrastru GUI Value Range: IKE(IKE), SSL(SSL)
0 LST D-00301 cture
WCDM 0 (PKI) Unit: None
APPCE
A, RT Actual Value Range: IKE, SSL
BTS390 Default Value: None
0 LTE MOD
APPCE
RT
TST
APPCE
RT
LST
CERTT
YPE
APPCE BTS390 MOD LOFD-0 Public Meaning: Indicates the file name of an activated device
RT 0, APPCE 03010 / Key certificate. The file name cannot include any of the
BTS390 RT TDLOF Infrastru following characters: backslashes (\), slashes (/), colons
0 TST D-00301 cture (:), asterisks (*), question marks (?), double quotation
WCDM APPCE 0 (PKI) marks ("), left angle brackets (<), right angle brackets
A, RT (>), and bars (|).
BTS390 GUI Value Range: 1~64 characters
0 LTE DSP
APPCE Unit: None
RT Actual Value Range: 1~64 characters
LST Default Value: None
APPCE
RT
ENCRY BTS390 SET MRFD- Security Meaning: Indicates the transmission encryption mode
MODE 0, FTPSCL 210305 Manage of the FTP client. If this parameter is set to Auto, the
BTS390 T ment FTP client first attempts to transmit data in ciphertext.
0 LST If the attempt fails, the FTP client automatically
WCDM FTPSCL switches the encryption mode to retransmit data in
A, T plaintext. However, if there are faults in transmission
BTS390 equipment such as the SeGW, the FTP client does not
0 LTE attempt to retransmit data in plaintext even if the FTP
server supports encrypted transmission. In this case, the
FTP connection setup fails.
GUI Value Range: Auto(Auto), Plaintext(Plaintext),
Encrypted(SSL Encrypted)
Unit: None
Actual Value Range: Auto, Plaintext, Encrypted
Default Value: Auto(Auto)

SingleRAN

nd
SSLCE BTS390 SET MRFD- Security Meaning: Indicates whether the certificate
RTAUT 0, FTPSCL 210305 Manage authentication mode is supported when encrypted data
H BTS390 T ment is being transmitted.
0 LST GUI Value Range: No(No), Yes(Yes)
WCDM FTPSCL
A, Unit: None
T
BTS390 Actual Value Range: No, Yes
0 LTE Default Value: No(No)
SPTST BTS390 SET MRFD- Security Meaning: Indicates whether FTP connections in
ATEFW 0, FTPSCL 210305 Manage encrypted mode can be established when there is a state
L BTS390 T ment firewall. In encrypted mode, if this parameter is set to
0 LST Yes, the FTP client sends a command to switch the
WCDM FTPSCL transmission mode of the control connection channel to
A, T plaintext. In this way, the state firewall can identify and
BTS390 dynamically open the port required for FTP
0 LTE transmission; if this parameter is set to No, the FTP
connection may fail to be set up due to port restrictions
imposed by the state firewall. If security requirements
are met, it is recommended that this parameter be set to
Yes.
GUI Value Range: No(No), Yes(Yes)
Unit: None
Actual Value Range: No, Yes
Default Value: Yes(Yes)
ENCRY BSC690 SET None None Meaning: Transport encryption mode supported when
MODE 0 FTPSCL the NE serves as the FTP client. AUTO(Auto): indicates
T that the FTP server selects the encryption mode.
PLAINTEXT(Plain Text): indicates that the plaintext
mode must be used. ENCRYPTED(SSL Encrypted):
indicates that the encrypted mode must be used.
GUI Value Range: AUTO(Auto), PLAINTEXT(Plain
Text), ENCRYPTED(SSL Encrypted)
Unit: None
Actual Value Range: AUTO, PLAINTEXT,
ENCRYPTED
Default Value: PLAINTEXT(Plain Text)

SingleRAN

nd
ENCRY BSC691 SET None None Meaning: Transport encryption mode supported when
MODE 0 FTPSCL the NE serves as the FTP client. AUTO(Auto): indicates
T that the FTP server selects the encryption mode.
PLAINTEXT(Plain Text): indicates that the plaintext
mode must be used. ENCRYPTED(SSL Encrypted):
indicates that the encrypted mode must be used.
GUI Value Range: AUTO(Auto), PLAINTEXT(Plain
Text), ENCRYPTED(SSL Encrypted)
Unit: None
ENCRYPTED
SSLCE BSC690 SET None None Meaning: Whether the FTP client supports
RTAUT 0 FTPSCL authenticating the FTP server.
H T GUI Value Range: NO(No), YES(Yes)
Unit: None
Actual Value Range: YES, NO
Default Value: NO(No)
SSLCE BSC691 SET None None Meaning: Whether the FTP client supports
RTAUT 0 FTPSCL authenticating the FTP server.
H T GUI Value Range: NO(No), YES(Yes)
Unit: None
Actual Value Range: YES, NO
Default Value: NO(No)
SPTST BSC690 SET None None Meaning: Whether the FTP client supports the state
ATEFW 0 FTPSCL firewall.
L T GUI Value Range: NO(Not Support), YES(Support)
Unit: None
Actual Value Range: NO, YES
Default Value: YES(Support)
SPTST BSC691 SET None None Meaning: Whether the FTP client supports the state
ATEFW 0 FTPSCL firewall.
L T GUI Value Range: NO(Not Support), YES(Support)
Unit: None
Actual Value Range: NO, YES
Default Value: YES(Support)

SingleRAN

nd
ENCRY BSC690 SET None None Meaning: Transport encryption mode used when the NE
MODE 0 FTPSSR serves as the FTP server. If Transport Encrypted Mode
V is set to SSL Encrypted, the FTP client should also
support SSL encryption, otherwise the FTP connection
will fail. AUTO(Automatic): indicates that the FTP
client selects the encryption mode. PLAINTEXT(Plain
Text): indicates that the plaintext mode must be used.
ENCRYPTED(SSL Encrypted): indicates that the
encrypted mode must be used.
GUI Value Range: AUTO(Automatic), PLAINTEXT
(Plain Text), ENCRYPTED(SSL Encrypted)
Unit: None
ENCRYPTED
ENCRY BSC691 SET None None Meaning: Transport encryption mode used when the NE
MODE 0 FTPSSR serves as the FTP server. If Transport Encrypted Mode
V is set to SSL Encrypted, the FTP client should also
support SSL encryption, otherwise the FTP connection
will fail. AUTO(Automatic): indicates that the FTP
client selects the encryption mode. PLAINTEXT(Plain
Text): indicates that the plaintext mode must be used.
ENCRYPTED(SSL Encrypted): indicates that the
encrypted mode must be used.
GUI Value Range: AUTO(Automatic), PLAINTEXT
(Plain Text), ENCRYPTED(SSL Encrypted)
Unit: None
ENCRYPTED

SingleRAN

nd
POLIC BTS390 SET LBFD-0 Security Meaning: Indicates the policy for logging in to the Web
Y 0, WEBLO 04003 Socket LMT. The value COMPATIBLE indicates that if http is
BTS390 GINPO LBFD-0 Layer entered in the address bar of an IE browser, the HTTP
0 LICY 04001 Local is used for and after the login. If https is entered in the
WCDM LST Mainten address bar of an IE browser, the HTTPS is used for and
A, WEBLO ance of after the login. The value HTTPS_ONLY indicates that
BTS390 GINPO the LMT no matter whether http or https is entered in the address
0 LTE LICY bar of an IE browser, the HTTPS is used for and after
the login. The value LOGIN_HTTPS_ONLY indicates
that no matter whether http or https is entered in the
address bar of an IE browser, the HTTPS is used for
login and the HTTP is used after the login.
GUI Value Range: COMPATIBLE(Compatible),
HTTPS_ONLY(Https_only), LOGIN_HTTPS_ONLY
(Login_https_only)
Unit: None
Actual Value Range: COMPATIBLE, HTTPS_ONLY,
LOGIN_HTTPS_ONLY
Default Value: HTTPS_ONLY(Https_only)
CONNT BTS390 SET MRFD- Security Meaning: Indicates the connection type supported by
YPE 0, CONNT 210305 Manage the NE.Compatible connection mode indicates that the
BTS390 YPE ment NE supports both the common connection mode and the
0 LST SSL connection mode.
WCDM SSLCO GUI Value Range: ALL(All Type), SSL(Only SSL
A, NF Connection)
BTS390
0 LTE Unit: None
Actual Value Range: ALL, SSL
Default Value: ALL(All Type)

SingleRAN

nd
DFTPO BSC690 SET None None Meaning: Whether the FTP server uses a default or
RTSWT 0 FTPSSR custom port. DEFAULTPORT(Default 21 Port):
V indicates that the FTP server uses default port 21 as the
command listening port and port 20 as the data port to
provide FTP service. CUSTOMPORT(Custom Port):
indicates that the FTP server uses a custom port to
provide FTP service. If the parameter DFTPORTSWT
is set to CUSTOMPORT, the NE must have the same
port configuration as the NE management system.
Otherwise, the FTP service supplied by the NE will be
unavailable.
GUI Value Range: DEFAULTPORT(Default 21 Port),
CUSTOMPORT(Custom Port)
Unit: None
Actual Value Range: DEFAULTPORT,
CUSTOMPORT
Default Value: DEFAULTPORT(Default 21 Port)
DFTPO BSC691 SET None None Meaning: Whether the FTP server uses a default or
RTSWT 0 FTPSSR custom port. DEFAULTPORT(Default 21 Port):
V indicates that the FTP server uses default port 21 as the
command listening port and port 20 as the data port to
provide FTP service. CUSTOMPORT(Custom Port):
indicates that the FTP server uses a custom port to
provide FTP service. If the parameter DFTPORTSWT
is set to CUSTOMPORT, the NE must have the same
port configuration as the NE management system.
Otherwise, the FTP service supplied by the NE will be
unavailable.
GUI Value Range: DEFAULTPORT(Default 21 Port),
CUSTOMPORT(Custom Port)
Unit: None
Actual Value Range: DEFAULTPORT,
CUSTOMPORT
Default Value: DEFAULTPORT(Default 21 Port)

SingleRAN

nd
SRVCM BSC690 SET None None Meaning: Number of the command listening port of the
DPORT 0 FTPSSR FTP server. The port cannot be occupied by other
V applications. For the method of querying occupied
OMU ports, see section "Querying Occupied OMU
Ports" in the OMU Administration Guide specific to the
working mode of the OMU in question. You are not
advised to use the ports 4443(If this port is used, the
certificate test function becomes unavailable),
6000~7000, 8000~9000, 16000~17000, and
18000~19000.
GUI Value Range: 1024~65535
Unit: None
Actual Value Range: 1024~65535
Default Value: None
SRVCM BSC691 SET None None Meaning: Number of the command listening port of the
DPORT 0 FTPSSR FTP server. The port cannot be occupied by other
V applications. For the method of querying occupied
6000~7000, 8000~9000, 16000~17000, and
18000~19000.
Unit: None
Default Value: None
SRVDA BSC690 SET None None Meaning: Data source port number of the FTP server in
TAPOR 0 FTPSSR active mode. The port cannot be occupied by other
T V applications. For the method of querying occupied
6000~7000, 8000~9000, 16000~17000, and
18000~19000.
Unit: None
Default Value: None

SingleRAN

nd
SRVDA BSC691 SET None None Meaning: Data source port number of the FTP server in
TAPOR 0 FTPSSR active mode. The port cannot be occupied by other
T V applications. For the method of querying occupied
6000~7000, 8000~9000, 16000~17000, and
18000~19000.
Unit: None
Default Value: None
ACDPO BSC690 SET None None Meaning: Start data port number on the FTP server in
RTLWL 0 FTPSSR passive mode. The FTP server data ports in passive
T V mode cannot be used by other applications. For the
method of querying occupied OMU ports, see section
"Querying Occupied OMU Ports" in the OMU
Administration Guide specific to the working mode of
the OMU in question. You are not advised to use the
ports 6000~7000, 8000~9000, 16000~17000, and
18000~19000.
Unit: None
Default Value: 25001
ACDPO BSC691 SET None None Meaning: Start data port number on the FTP server in
RTLWL 0 FTPSSR passive mode. The FTP server data ports in passive
ports 6000~7000, 8000~9000, 16000~17000, and
18000~19000.
Unit: None

SingleRAN

nd
ACDPO BSC690 SET None None Meaning: End data port number on the FTP server in
RTUPL 0 FTPSSR passive mode. The FTP server data ports in passive
ports 6000~7000, 8000~9000, 16000~17000, and
18000~19000.
Unit: None
ACDPO BSC691 SET None None Meaning: End data port number on the FTP server in
RTUPL 0 FTPSSR passive mode. The FTP server data ports in passive
ports 6000~7000, 8000~9000, 16000~17000, and
18000~19000.
Unit: None
POLIC BSC690 SET None None Meaning: Policy for LMT login and data transmission,
Y 0 WEBLO which includes COMPATIBLE(Both HTTP and
GINPO HTTPS), HTTPS(HTTPS Only), LOGINHTTPS
LICY (HTTPS for Login Only).
GUI Value Range: COMPATIBLE(Both HTTP and
HTTPS), HTTPS(HTTPS Only), LOGINHTTPS
(HTTPS for Login Only)
Unit: None
Actual Value Range: COMPATIBLE, HTTPS,
LOGINHTTPS
Default Value: HTTPS(HTTPS Only)

SingleRAN

nd
POLIC BSC691 SET None None Meaning: Policy for LMT login and data transmission,
Y 0 WEBLO which includes COMPATIBLE(Both HTTP and
GINPO HTTPS), HTTPS(HTTPS Only), LOGINHTTPS
LICY (HTTPS for Login Only).
GUI Value Range: COMPATIBLE(Both HTTP and
HTTPS), HTTPS(HTTPS Only), LOGINHTTPS
(HTTPS for Login Only)
Unit: None
Actual Value Range: COMPATIBLE, HTTPS,
LOGINHTTPS
Default Value: HTTPS(HTTPS Only)

SingleRAN
SSL Feature Parameter Description 10 Counters
10 Counters
There are no specific counters associated with this feature.

SingleRAN
SSL Feature Parameter Description 11 Glossary
11 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

SingleRAN
SSL Feature Parameter Description 12 Reference Documents
12 Reference Documents
1. IETF RFC 6101

2. IETF RFC 2246
3. IETF RFC 4346
4. IETF RFC 5246
5. PKI Feature Parameter Description for SingleRAN
6. Equipment Security Feature Parameter Description for SingleRAN
7. OM Security Feature Parameter Description for SingleRAN


SSL (Sran9.0 01)

Загружено:

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

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

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

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

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

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

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

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

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

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

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

SSL (Sran9.0 01)

Загружено:

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

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

SingleRAN

SSL Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2014-04-30) Huawei Proprietary and Confidential i

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

4 SSL Application Scenarios........................................................................................................12

Issue 01 (2014-04-30) Huawei Proprietary and Confidential ii

8 Engineering Guidelines on the Base Station Controller Side............................................39

Issue 01 (2014-04-30) Huawei Proprietary and Confidential iii

1 About This Document

This document describes the following features.

l GBFD-113522 Encrypted Network Management

LTE LTE FDD LTE TDD

eNodeB LTE FDD eNodeB LTE TDD eNodeB

eRAN LTE FDD eRAN LTE TDD eRAN

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 1

Table 1-1 Definitions of all kinds of base stations

Base Station Definition

GBTS GBTS refers to a base station deployed with GTMU.

eGBTS eGBTS refers to a base station deployed with UMPT_G.

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

eNodeB eNodeB refers to a base station deployed with LMPT or UMPT_L.

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

1.2 Intended Audience

l Need to understand the features described herein

1.3 Change History

SRAN9.0 Draft B (2014-02-28)

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 2

Change Type Change Description Parameter

Feature change None None

SRAN9.0 Draft A (2014-01-20)

Change Type Change Description Parameter Change

Added the SSL renegotiation management Added the following

Editorial change Added section 5.4 Features Related to None

1.4 Differences Between Base Station Types

Function Implementation in Macro, Micro, and LampSite Base Stations

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 3

l Confidentiality: SSL encrypts data transmitted between communication parties to prevent

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 4

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 5

3.1 SSL Protocol Stack

Figure 3-1 SSL protocol stack

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 6

The handshake protocol establishes a security channel between the communication

3.2 Procedure for Establishing an SSL Connection

The purposes of the SSL handshake are as follows:

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 7

The general message exchange process is described as follows:

For details about SSL, see the following protocols:

l RFC 6101 for SSL3.0

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 8

l RFC 5246 for TLS1.2

3.3 SSL Renegotiation Management

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 9

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 10

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 11

4 SSL Application Scenarios

4.1.1 OM Channel Between the Base Station and the U2000

Issue 01 (2014-04-30) Huawei Proprietary and Confidential 12

CRL: certificate revocation list DMZ: demilitarized zone

RA: registration authority CA: certificate authority