IPsec (SRAN8.0 02)

SingleRAN
IPsec Feature Parameter Description

Issue
02
Date
2013-07-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

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

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://www.huawei.com
Email:
support@huawei.com
Issue 02 (2013-07-30)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.
SingleRAN
Contents
Contents
1 About This Document..................................................................................................................1
1.1 Scope..............................................................................................................................................................................1
1.2 Intended Audience..........................................................................................................................................................2
1.3 Change History...............................................................................................................................................................2
2 Overview.........................................................................................................................................5
3 IPsec Working Principles.............................................................................................................7
3.1 Security Association.......................................................................................................................................................7
3.2 IPsec Policies..................................................................................................................................................................8
3.3 IPsec Proposal.................................................................................................................................................................9
3.3.1 Security Protocols........................................................................................................................................................9
3.3.2 Encapsulation Modes.................................................................................................................................................10
3.3.3 Encryption and Verification Algorithms...................................................................................................................13
3.4 IPsec Service Procedure...............................................................................................................................................14
4 IKE Working Principles.............................................................................................................15

4.1 Introduction..................................................................................................................................................................15
4.2 IKE Negotiation............................................................................................................................................................16
4.2.1 IKEv1 Negotiation.....................................................................................................................................................16
4.2.2 IKEv2 Negotiation.....................................................................................................................................................17
4.2.3 Key Generated by IKE Negotiation...........................................................................................................................18
4.3 IKE Proposal.................................................................................................................................................................18
4.3.1 Introduction...............................................................................................................................................................18
4.3.2 Encryption and Verification Algorithms...................................................................................................................18
4.3.3 Authentication Method..............................................................................................................................................18
4.3.4 DH Group and PRF Algorithm..................................................................................................................................19
4.3.5 IKE SA Lifetime........................................................................................................................................................19
4.4 IKE Security Mechanism..............................................................................................................................................20
4.5 IKE DPD.......................................................................................................................................................................20
5 IPsec Reliability...........................................................................................................................21
5.1 IPsec Tunnel Backup....................................................................................................................................................22
6 IEEE 1588v2 over IPsec...............................................................................................................23

Issue 02 (2013-07-30)

ii
SingleRAN
Contents
7 IPsec Application.........................................................................................................................25
7.1 Typical IPsec Networking............................................................................................................................................25
7.2 Application of IPsec on Macro Base Stations..............................................................................................................26
7.2.1 Application of IPsec on GBTSs.................................................................................................................................26
7.2.2 Application of IPsec on eGBTSs, NodeBs, and eNodeBs........................................................................................28
7.2.3 Application of IPsec on Multimode Base Stations....................................................................................................28
7.3 External IPsec on the Base Station Controller Side.....................................................................................................29
7.4 Application of IPsec on Cascaded Base Stations.........................................................................................................30
7.5 Network Evolution Solutions.......................................................................................................................................31
8 Related Features...........................................................................................................................33
8.1 Features Related to Integrated IPsec on the Base Station.............................................................................................34
8.2 Features Related to IPsec Tunnel Backup....................................................................................................................34
9 Network Impact...........................................................................................................................36
10 Engineering Guidelines...........................................................................................................39
10.1 When to Use IPsec......................................................................................................................................................39
10.2 Required Information.................................................................................................................................................39
10.3 Planning......................................................................................................................................................................41
10.3.1 Network Planning....................................................................................................................................................41
10.3.2 Hardware Planning..................................................................................................................................................43
10.4 Requirements..............................................................................................................................................................44
10.5 Configuration Principles.............................................................................................................................................45
10.5.1 IPsec Policies...........................................................................................................................................................45
10.5.2 ACL Rules...............................................................................................................................................................46
10.6 Deployment of IPsec on a PKI-based Secure Network..............................................................................................47
10.6.1 Deploying IPsec on an eGBTS, NodeB, or eNodeB...............................................................................................47
10.6.2 Deploying IPsec on a GBTS (GTMUb+UMPT_L)................................................................................................69
10.6.3 Deploying IPsec on a GBTS (GTMUb+UTRPc)....................................................................................................71
10.6.4 Deploying Co-IPsec on a GL Dual-Mode Base Station (UMPT_GL/GTMUb+UMPT_L)...................................93
10.6.5 Deploying Co-IPsec on a GU Dual-Mode Base Station (UMPT_GU/GTMUb+UMPT_U)..................................96
10.6.6 Deploying Co-IPsec on a UL Dual-Mode Base Station (UMPT_UL/UMPT_U+UMPT_L).................................99
10.6.7 Deploying Co-IPsec on a GUL Multimode Base Station (UMPT_GUL).............................................................102
10.6.8 Deploying Co-IPsec on a GUL Multimode Base Station (UMPT_L+GTMUb+UCIU in the Root BBU and UMPT_U
in the Leaf BBU)..............................................................................................................................................................104
10.6.9 Deploying Co-IPsec on a GUL Multimode Base Station (UMPT_U+GTMUb+UCIU in the Root BBU and UMPT_L
in the Leaf BBU)..............................................................................................................................................................106
10.7 Deployment of IPsec on a PSK-based Secure Network...........................................................................................108
10.7.1 Data Preparation....................................................................................................................................................109
10.7.2 Initial Configuration..............................................................................................................................................111
10.7.3 Activation Observation..........................................................................................................................................111
10.8 Secure Configuration Modification on a Reconstructed Network...........................................................................112
10.8.1 Reconstruction from an Insecure Network to a PKI-based Secure Network........................................................112
Issue 02 (2013-07-30)

iii
SingleRAN
Contents
10.8.2 Reconstruction from an Insecure Network to a PSK-based Secure Network.......................................................117

10.8.3 Reconstruction from a PSK-based Secure Network to a PKI-based Secure Network..........................................122
10.9 Performance Monitoring...........................................................................................................................................125
10.10 Performance Optimization......................................................................................................................................125
10.11 Troubleshooting......................................................................................................................................................125
11 Parameters.................................................................................................................................126
12 Counters....................................................................................................................................203
13 Glossary.....................................................................................................................................207
14 Reference Documents.............................................................................................................208
Issue 02 (2013-07-30)

iv
SingleRAN
1 About This Document
About This Document
1.1 Scope
This document describes the Internet Protocol Security (IPsec) , including its technical
principles, related features, network impact, and engineering guidelines.
This document covers the following features:
l
GBFD-113524 BTS Integrated IPsec
WRFD-140209 NodeB Integrated IPSec
LOFD-003009 IPsec
MRFD-211602 Co-IPSec Between GSM, UMTS and LTE (GSM)
MRFD-221602 Co-IPSec Between GSM, UMTS and LTE (UMTS)
MRFD-231602 Co-IPSec Between GSM, UMTS and LTE (LTE)
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.
Table 1-1 Definitions of all kinds of base stations
Issue 02 (2013-07-30)
Base Station
Name
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.

SingleRAN
Base Station
Name
Definition
Co-MPT
Multimode Base
Station
Co-MPT multimode base station refers to a base station deployed with

UMPT_GU, UMPT_GL, UMPT_UL, or UMPT_GUL, and it
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
Multimode Base
Station
Separate-MPT multimode base station refers to a base station on which

different modes use different main control boards. For example, base
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
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
Editorial change
Changes in wording or addition of information that was not described in the earlier version
02 (2013-07-30)
This issue includes the following changes.
Change Type
Change Description
Parameter
Change
Feature change
None
None
Editorial change
Deleted the descriptions of IPsec supported by micro

base stations.
None
01 (2013-04-28)
This issue does not include any changes.
Issue 02 (2013-07-30)

SingleRAN
Draft B (2013-04-10)
This issue includes the following changes.
Change Type
Change Description
Parameter
Change
Feature change
Implemented IPsec on micro base stations.
None
Editorial change
None
None
Draft A (2012-12-30)
This document is created for SRAN8.0.
As to GSM BSS/WCDMA RAN, the name of the document is changed into IPsec Feature
Parameter Description from Transmission Security Feature Parameter Description.
As to eRAN, this document is derived from Transmission Security Feature Parameter
Description.
Compared with Issue 02 (2012-07-20) of SRAN7.0, Draft A (2012-12-30) of SRAN8.0 includes
the following changes.
Change Type
Change Description
Parameter Change
Feature change
Added IPsec deployment scenarios for

eGBTSs.
None
Added the IEEE 1588v2 over IPsec

solution. For details, see chapter 6 IEEE
1588v2 over IPsec.
None
Added descriptions of the IPsec security

association (SA) and anti-replay window.
For details, see chapter 3 IPsec Working
Principles.
None
Revised descriptions of IKEv1

negotiation. For details, see section 4.2.1
IKEv1 Negotiation.
None
Added descriptions of the Diffie-Hellman

(DH) group and pseudo-random function
(PRF) algorithm. For details, see section
4.3.4 DH Group and PRF Algorithm.
None
Simplified the base station deployment

process in typical scenarios. For details,
see section 7.1 Typical IPsec
Networking.
None
Editorial change
Issue 02 (2013-07-30)

SingleRAN
Change Type
Issue 02 (2013-07-30)
Change Description
Parameter Change
Modified the application of IPsec on base

stations. For details, see section 7.2
Application of IPsec on Macro Base
Stations.
None
Modified the description of IPsec-related

features. For details, see chapter 8
Related Features.
None
Revised IPsec engineering guidelines, and

detailed how to deploy IPsec on GBTSs,
eGBTSs, NodeBs, eNodeBs, and
multimode base stations in different
networking scenarios. For details, see
chapter 10 Engineering Guidelines.
None

SingleRAN
2 Overview
Overview
The evolution from radio networks to IP-based networks has improved network performance
and reduced network deployment costs. However, inherent vulnerabilities on IP networks leave
them open to security threats.
Before IPsec is introduced, a base station transmits control-plane data, user-plane data, and
management-plane data in plaintext. Packets transmitted on an insecure network are vulnerable
to unauthorized access or malicious modification. To ensure secure data transmission, Huawei
base stations incorporate the IPsec function, by which IPsec tunnels are established.
As defined by the Internet Engineering Task Force (IETF), IPsec is a security mechanism
implemented at the IP layer and consists of three protocols: Authentication Header (AH),
Encapsulation Security Protocol (ESP), and IKE. IPsec provides transparent end-to-end security
services for IP networks, thereby protecting the networks from cyber attacks.
With IPsec, two communicating peers (also known as IPsec peers) ensure the following security
features of IP packets transmitted on the network by encrypting the packets and authenticating
the data source:
l
Confidentiality: An IPsec entity encrypts user data and transmits the data in ciphertext to
prevent the data from being disclosed on the transmission path. The IPsec entity is the
network element (NE) or network equipment that uses IPsec for communication.
Integrity: The IPsec entity checks the received data to ensure that it has not been tampered
with.
Authenticity: The IPsec entity authenticates the data source.
Anti-replay protection: The IPsec entity identifies and rejects packets that are intercepted
and repeatedly sent by malicious users.
IPsec tunnels between the base station and security gateway (SeGW) can protect data
transmission between the base station and base station controller. Figure 2-1 shows a secure
network.
Issue 02 (2013-07-30)

SingleRAN
2 Overview
Figure 2-1 Secure network
Issue 02 (2013-07-30)

SingleRAN
3 IPsec Working Principles
IPsec Working Principles
3.1 Security Association

Before using IPsec tunnels for secure data transmission, an SA must be established between
communicating peers. An SA defines security policies negotiated between communicating peers
to protect data flows. The security policies involve:
l
Security protocols
Encapsulation modes
Verification algorithms
Encryption algorithms
Key for data protection and key lifetime
There are two types of SAs in the IPsec framework: IPsec SAs and IKE SAs. IPsec SAs are
established by negotiation under the protection of IKE SAs. IKE SAs are established by
negotiation between IKE peers. An IKE SA defines the IKE SA lifetime and encryption,
verification, authentication, and Pseudo-random Function(PRF) algorithms used between IKE
peers. For details, see section 4 IKE Working Principles.
IPsec SAs are unidirectional, and therefore at least two IPsec SAs are required to protect data
flows in two directions. Figure 3-1 shows an example of an IPsec SA.
Issue 02 (2013-07-30)

SingleRAN
Figure 3-1 Example of an IPsec SA
NOTE
The Security Parameter Index(SPI) is used to identify IPsec SAs. Each IPsec SA has a unique SPI.
Each IPsec SA uses either AH or ESP to provide security services. If both AH and ESP are used,
each IPsec entity requires two IPsec SAs: one for AH and the other for ESP.
An IPsec SA has a limited lifetime. After the lifetime elapses, the IPsec SA becomes invalid.
Before an IPsec SA becomes invalid, IKE establishes a new IPsec SA by negotiation. For details
about the IPsec SA, see IETF RFC 4301.
3.2 IPsec Policies

Security services offered by IPsec are based on IPsec policies defined by a Security Policy
Database (SPD). The SPD specifies which security services are to be offered to IP packets and
provides information about how to obtain these services.
The SPGN and SPSN parameters specify an IPsec policy. An IPsec policy includes the
following:
l
Access control list (ACL)

An ACL consists of a series of ACL rules, which specify the data flows to be protected.
Only data flows that comply with ACL rules can enter an IPsec tunnel.
IPsec proposal
An IPsec proposal defines how to protect data flows, that is, which protocol type,
encapsulation mode, and encryption and verification algorithms are used. For details, see
section 3 IPsec Working Principles.
IKE
IKE is used to specify the identity authentication method and the encryption, verification,
and key generation algorithms before an ISPec SA is established. For details, see chapter
4 IKE Working Principles.
Issue 02 (2013-07-30)

SingleRAN
IPsec SA lifetime
The LTCFG, LTS, and LTKB parameters specify the IPsec SA lifetime. If LTCFG is set
to GLOBAL, the IPsec SA lifetime is set to 3600 seconds. If LTCFG is set to LOCAL, the
IPsec SA lifetime is configured by LTS and LTKB. If LTKB is set to 0, traffic-based IPsec
SA validity judgment is disabled. An IPsec SA becomes invalid when its lifetime reaches
the value of LTS or LTKB.
Anti-replay window
The REPLAYWND parameter specifies the anti-replay window size.
If this parameter is set to WND_DISABLE(0), the window size is 0 and therefore the antireplay function is disabled.
If this parameter is set to WND_32(32), WND_64(64), WND_128(128), WND_256
(256), WND_512(512), WND_1024(1024), WND_2048(2048), or WND_4096(4096),
the window size is 32, 64, 128, 256, 512, 1024, 2048, or 4096, respectively. Base stations
check for packet duplicates within the window. If a packet has a duplicate within the
window or falls on the left of the window, base stations discard the packet.
It is recommended that the anti-replay function be disabled if there is a severe out-of-order
problem in IPsec packets on live networks. For example, such a problem could occur when
differentiated services code point (DSCP) values are attached to IPsec packets based on
service types due to scheduling at network nodes. If the anti-replay function is enabled in
this situation, a large number of IPsec packets may be lost, which severely affects service
performance.
Base stations can negotiate one or multiple IPsec SAs based on a set of parameters related to
IPsec policies. The number of negotiated IPsec SAs depends on the number of configured ACL
rules. If the ACTION parameter in an ACLRULE MO is set to PERMIT, one incoming IPsec
SA and one outgoing IPsec SA can be negotiated for the corresponding ACL rule.
3.3 IPsec Proposal

An IPsec proposal covers security protocols, encapsulation modes, and encryption and
verification algorithms.
3.3.1 Security Protocols

IPsec uses two security protocols: AH and ESP, which are described in Table 3-1 .
Table 3-1 AH and ESP
Security
Protocol
Function
Verification Scope
Application
Scenario
AH
l Integrity protection
AH verifies both the IP

packet header and
payload.
Non-confidential
data
ESP verifies only the IP

payload.
Confidential data
l Anti-replay
ESP
l Integrity protection
l Anti-replay
l Encryption
Issue 02 (2013-07-30)

SingleRAN
AH and ESP can be applied separately or jointly. When both are used, ESP takes precedence
over AH.
IPsec tunnels protect IP packets by encapsulating the packets. Both AH and ESP support two
packet encapsulation modes: transport mode and tunnel mode. The transport mode applies to
the host's packets, whereas the tunnel mode applies to packets transmitted on forwarding
equipment. For details about the packet encapsulation modes, see section 3.3.2 Encapsulation
Modes.
Data integrity protection or encryption provided by AH or ESP relies on the verification and
encryption algorithms. For details, see section 3.3.3 Encryption and Verification
Algorithms .
Protocol types, encapsulation modes, and encryption and verification algorithms are negotiated
between the base station and SeGW. In addition, the key used in data encryption is generated
based on IKE negotiation. For details about IKE, see chapter 4 IKE Working Principles.
For details about AH, see IETF RFC 4302. For details about ESP, see IETF RFC 4303.
3.3.2 Encapsulation Modes

IPsec supports two packet encapsulation modes: transport mode and tunnel mode.
Transport Mode
In transport mode, an AH header is inserted after the IP header of the original packet and before
any other transport layer protocol, as shown in Figure 3-2.
Figure 3-2 AH packet encapsulation format used in transport mode
In transport mode, an ESP header is inserted after the IP header of the original packet and before
any other transport layer protocol, and an ESP trailer and an ESP authenticator are attached to
the rear of the original packet, as shown in Figure 3-3.
Figure 3-3 ESP packet encapsulation format used in transport mode
Issue 02 (2013-07-30)

10
SingleRAN
In transport mode, the source IP address for packets sent by a base station is the service or
operation and maintenance (O&M) IP address of the base station, and the destination IP address
for the packets is the service or O&M IP address of peer equipment.
Generally, IP packets transmitted between hosts are encapsulated in transport mode. The sending
equipment encrypts IP packets and the receiving equipment decrypt the IP packets. The transport
mode is used only for end-to-end IPsec protection.
Figure 3-4 shows the end-to-end protocol stack in transport mode.
Figure 3-4 End-to-end protocol stack in transport mode
Tunnel Mode
In tunnel mode, an AH header is prefixed to the IP header of the original packet, and a new IP
header is prefixed to the AH header. Figure 3-5 shows the format used for encapsulating AH
packets in tunnel mode.
Figure 3-5 AH packet encapsulation format used in tunnel mode
In tunnel mode, an ESP header is prefixed to the IP header of the original packet, and a new IP
header is prefixed to the ESP header. Figure 3-6 shows the format used for encapsulating ESP
packets in tunnel mode.
Issue 02 (2013-07-30)

11
SingleRAN
Figure 3-6 ESP packet encapsulation format used in tunnel mode
AH does not provide integrity protection for some variable fields in an IP packet, such as Type
of Service, Time to Live, and Checksum. This is because these fields may be legally modified
during transmission.
In tunnel mode, IPsec encrypts an IP header of the original packet and generates a new IP header,
which is used for route forwarding. The new IP header always uses the interface IP address of
a base station and the IP address of the peer equipment (usually, an SeGW) as the source and
destination IP addresses, respectively. The IP header of the original packet contains the service
or O&M IP address of the base station.
Figure 3-7 shows the end-to-end protocol stack in tunnel mode.
Figure 3-7 End-to-end protocol stack in tunnel mode
If the sending equipment does not encrypt the packets or the receiving equipment does not
decrypt the packets, IPsec peers usually use the tunnel mode for communication. Figure 3-7
shows an example of using the tunnel mode between a base station and a SeGW.
Figure 3-8 Tunnel mode example
Issue 02 (2013-07-30)

12
SingleRAN
Summary
The transport and tunnel modes differ in the following ways:
l
Security: The tunnel mode provides higher security than the transport mode, because the
entire original IP packet is encrypted and integrity protection is performed in tunnel mode.
Performance: The transport mode provides better transmission performance than the tunnel
mode, because a new IP header is added in tunnel mode and therefore more bandwidth is
used.
In addition, in tunnel mode, an SeGW must be deployed on a network to separate the security
and non-security domains. The SeGW must also support functions, such as encapsulation in
tunnel mode, encryption, and integrity protection. In transport mode, both communicating peers
must support functions, such as IKE negotiation, encryption, and integrity protection. Therefore,
users must comprehensively consider security, deployment, and performance when choosing
between the two encapsulation modes. The chosen encapsulation mode must be supported by
the IPsec peer.
The ENCAPMODE parameter specifies the encapsulation mode.
3.3.3 Encryption and Verification Algorithms

Encryption Algorithm
ESP encrypts IP packets to prevent unauthorized access during packet transmission. The
encryption algorithm uses symmetric keys so that the same key is used by IPsec peers for
encryption and decryption. Base stations support the following encryption algorithms:
l
Data Encryption Standard (DES)
Triple Data Encryption Standard (3DES)
Advanced Encryption Standard 128 (AES128)
AES192
AES256
Compared with DES and 3DES, AES is more secure and provides higher encryption speed.
3DES is more secure than DES, but 3DES takes longer to encrypt than DES. Therefore, DES is
not recommended for security reasons.
Verification Algorithm
Both AH and ESP can check the integrity of IP packets to determine whether the IP packets
were tampered with during transmission. The verification algorithm is implemented mainly
based on a hash function, which accepts messages of any length and generates outputs of a fixed
length. The outputs are called message digests. Upon receiving a packet from the IPsec local
end, the IPsec peer calculates the digests and compares them with those carried in the packet. If
the two sets of digests are the same, the packet is complete and has not been tampered with. Base
stations support the following verification algorithms:
l
Message digest algorithm 5 (MD5)
Secure hash algorithm 1 (SHA-1)
Issue 02 (2013-07-30)

13
SingleRAN
SHA-256
AES-XCBC (extension-cipher-block-chaining)-MAC-96
Among the four verification algorithms, MD5 has the lowest security level and therefore is not
recommended.
For details about MD5, see IETF RFC 2403. For details about SHA, see IETF RFC 2404.
3.4 IPsec Service Procedure

Figure 3-9 shows the IPsec service procedure.
Figure 3-9 IPsec service procedure
The IPsec service procedure is as follows:

1.
IPsec peers establish an IKE SA by IKE negotiation.
2.
The IPsec peers establish an IPsec SA by IPsec negotiation.
3.
During data communication, the IPsec local end encrypts data that complies with ACL
rules, and the IPsec peer end decrypts the received data.
Issue 02 (2013-07-30)

14
SingleRAN
4 IKE Working Principles
IKE Working Principles
4.1 Introduction
IPsec SAs can be manually configured. However, due to an increase in security equipment on
the network, manual configuration is difficult and can hardly ensure security. IKE can be used
to automatically establish SAs to simplify using and managing IPsec.Currently, IPsec SAs can
be established for base stations by using IKE, not manual configuration.
IKE is a security mechanism based on the Internet Security Association and Key Management
Protocol (ISAKMP) framework. It provides encryption and authentication algorithms and key
negotiation for communicating peers. It also securely distributes keys, authenticates identities,
and establishes IPsec SAs on insecure networks. The details are as follows:
l
IKE SA establishment
An ISAKMP SA (also known as IKE SA) is established based on IKE negotiation. The
IKE SA provides an authenticated and secure channel for data exchange. Under the
protection of the IKE SA, an IPsec SA is established by negotiation.
IKE negotiation involves the IKE protocol version, negotiation mode, and IKE proposal.
Session key generation

Communicating peers perform a Diffie-Hellman (DH) exchange to generate session keys,
which are then used for IKE encryption, IKE data integrity check, IKE authentication, and
IPsec data encryption. During the DH exchange, session key materials are exchanged.
Identity authentication
Communicating peers exchange identity information to authenticate each other. This
information includes authentication methods agreed upon in IKE negotiation and keys
generated by DH exchange.
IP addresses for the IKE local and peer ends (specified by LOCALIP and REMOTEIP,
respectively) must be specified for IKE negotiation.
For details about IKE, see IETF RFC 4301, IETF RFC 2409, and IETF RFC 4306.
Issue 02 (2013-07-30)

15
SingleRAN
4.2 IKE Negotiation

There are two IKE versions: IKEv1 and IKEv2. The two versions have different negotiation
processes.
4.2.1 IKEv1 Negotiation

IKEv1 defines two phases for IPsec key negotiation and IPsec SA establishment.
l
In the first phase, communicating peers establish an IKE SA.
In the second phase, the communicating peers negotiate and establish an IPsec SA under
the protection of the IKE SA. The IPsec SA is used for secure data transmission.
A negotiation mode is an information exchange mode used during IKE negotiation. IKEv1
allows for three negotiation modes: main mode, aggressive mode, and quick mode.
In the first phase, either main mode or aggressive mode can be used.
l
If main mode is used, an IKE SA is established after three exchanges, as shown in Figure
4-1.
Policy negotiation: An IKE proposal is negotiated by exchanging IKE policies.
DH exchange: A shared key is generated by exchanging key materials.
Identity authentication: Communicating peers exchange identity information and
authenticate each other based on the negotiated IKE proposal and generated key.
If aggressive mode is used, an IKE SA is established as follows:

The initiator sends the first message to the responder. This message contains the IKE
proposal, key materials, and identity information.
The responder sends the second message to the initiator. This message contains the IKE
proposal, DH exchange information, identity information, and authentication payload.
The initiator sends the third message to the responder. This message contains the
authentication payload.
Main mode is recommended in the first phase according to the following comparisons:
l
Main mode is more secure than aggressive mode because identify information is encrypted
in main mode but is not encrypted in aggressive mode.
Multiple IKE proposals can be negotiated at a time in main mode, whereas only one IKE
proposal can be negotiated at a time in aggressive mode.
Main mode provides stronger negotiation capability but more complex negotiation process
than aggressive mode.
NOTE
If a pre-shared key (PSK) is used for IKE authentication, main mode can use only IP addresses for peer
authentication. In this case, the IDTYPE parameter must be set to IP.
The IKEVERSION parameter specifies the IKE version. The EXCHMODE parameter specifies
the negotiation mode in the first phase of IKEv1 negotiation.
Issue 02 (2013-07-30)

16
SingleRAN
Figure 4-1 IKEv1 negotiation in main mode
In the second phase, quick mode is used. In this mode, an IPsec SA is established by exchanging
three messages.
4.2.2 IKEv2 Negotiation

Compared with IKEv1, IKEv2 simplifies the exchange process. Only two exchanges are required
to establish an IKE SA and the first IPsec SA, as shown in Figure 4-2. If more than one IPsec
SA needs to be established, information exchange is required only for each corresponding IPsec
SA.
Figure 4-2 IKEv2 negotiation process
Issue 02 (2013-07-30)

17
SingleRAN
4.2.3 Key Generated by IKE Negotiation

After the exchange of key materials, communicating peers use these materials to generate seven
keys, of which:
l
Two keys are used to encrypt subsequent messages.
Two keys are used for the integrity protection of subsequent messages.
Two keys serve as the ciphering keys for identity authentication.
One key is used for IPsec data encryption and integrity protection.
NOTE
Subsequent messages are those sent during IKE negotiation after the DH exchange.
For details about the key generation method, see section 4.3.4 DH Group and PRF
Algorithm.
4.3 IKE Proposal

4.3.1 Introduction
An IKE proposal consists of the encryption algorithm, verification algorithm, authentication
method, DH group, PRF algorithm, and IKE SA lifetime.
During IKE negotiation, the IKE local end uses its IKE proposal to negotiate with the IKE peer
end and establishes an IKE SA, thereby providing security services for IPsec SA negotiation.
4.3.2 Encryption and Verification Algorithms

Huawei base stations support the following encryption and verification algorithms:
l
Encryption algorithms, including:

DES
3DES
AES128
AES192
AES256
Verification algorithms, including:

MD5
SHA1
AES-XCBC-MAC-96 (only IKEv2 supports)
MD5 and DES are not recommended because they have low security.
4.3.3 Authentication Method

IKE supports two methods for authenticating IPsec peers: PSK and digital certificate.
l
Issue 02 (2013-07-30)
PSK
18
SingleRAN
After encrypting a message with a PSK, the sending party sends the encrypted message to
the receiving party. The receiving party decrypts the message with the same PSK. If the
message is decrypted successfully, the authentication is successful.
When PSK authentication is used, communicating peers must use the same PSK. Users can
predefine the PSK by using a Universal Serial Bus (USB) flash drive on a base station.
l
Digital certificate
This method enables communicating peers to authenticate each other based on digital
certificates. Certificates are difficult to counterfeit and are managed with a complete
mechanism. For example, certificates have validity periods and can be revoked. Therefore,
certificates are more reliable than PSKs. A public key infrastructure (PKI) system manages
digital certificates for network equipment. For details, see PKI Feature Parameter
Description.
4.3.4 DH Group and PRF Algorithm

When IKE is used, both communicating peers can exchange data to calculate a session key
without transferring any keys. Even if a third party intercepts all exchanged data, it cannot
calculate the correct key because the DH algorithm and PRF are used.
A DH group determines the length of the material used for key generation. Base stations support
the following DH groups:
l
DH_GROUP1: defines 768-bit material
The material length determines the security level. A longer length indicates a higher security
level.
PRF is a highly-reliable unidirectional function that generates keys. After the DH exchange of
key materials, communicating peers use these materials as an input to PRF and generate a key.
Base stations support the following PRF algorithms:
l
HMAC_MD5
HMAC_SHA1
AES128_XCBC
The DHGRP parameter specifies a DH group, and the PRFALG parameter specifies a PRF
algorithm.
For details about PRF, see IETF RFC 4306.
4.3.5 IKE SA Lifetime

An IKE SA has a limited lifetime. Before the lifetime expires, another SA is automatically
established to replace the old one.
A long lifetime may allow the key to be cracked. A short lifetime triggers frequent IKE
negotiations, which may interrupt ongoing IPsec sessions because IKE negotiation takes time
to perform the DH exchange and calculate session keys. To prevent IKE SA updates from
affecting secure communication, a lifetime longer than 10 minutes is recommended.
Issue 02 (2013-07-30)

19
SingleRAN
The DURATION parameter specifies the IKE SA lifetime.
4.4 IKE Security Mechanism

The IKE security mechanism is described as follows:
l
DH exchange and key distribution

Before encrypting IP packets, communication peers must perform a DH exchange to
generate session keys by negotiation. IKE ensures that the communication peers exchange
data to calculate session keys without transferring any keys. Even if a third party, such as
a hacker, intercepts all exchanged data, they cannot calculate the correct key.
Perfect forward secrecy (PFS)

PFS is a security feature, in which the decoding of one key does not affect the security of
other keys because no session key can be derived from any other key. PFS is guaranteed
by the DH algorithm.
Identity authentication
The communication peers authenticate each other.
Identity protection
To protect identity data, it is sent in encrypted mode after a key is generated.
4.5 IKE DPD

IP and IPsec are unidirectional and connectionless. When IPsec peers communicate, there is a
probability that one end may not know if the other end because of abnormalities such as a system
failure. If this occurs, the normal end continues to transmit IPsec traffic, resulting in traffic loss.
Dead peer detection (DPD) is introduced to detect the peer status (online or offline) for base
stations. DPD can be enabled by setting the DPD parameter to PERIODIC.
The local end starts DPD only when both of the following conditions are met:
l
The local end does not receive IPsec packets from the peer end within the period specified
by the DPDIDLETIME parameter.
The local end needs to send IPsec packets to the peer end.
If the local end receives an acknowledgement from the peer end after sending a DPD message,
it considers the peer end online or normal. If the local end does not receive any acknowledgement
from the peer end after sending the DPD message multiple times (specified by the
DPDRETRN parameter), it considers the peer end unresponsive. In this case, the local end reinitiates IKE negotiation and begins to record security events. The local end retransmits DPD
messages at an interval specified by the DPDRETRI parameter.
For details about DPD, see IETF RFC 3706.
Issue 02 (2013-07-30)

20
SingleRAN
5 IPsec Reliability
5
l
IPsec Reliability
IPsec Tunnel Backup

Two IPsec tunnels, one primary and one secondary, are established between a base station
and two SeGWs. If the primary IPsec tunnel becomes faulty, data flows are automatically
switched to the secondary IPsec tunnel. Therefore, the reliability of IPsec data transmission
is enhanced.
Issue 02 (2013-07-30)

21
SingleRAN
5 IPsec Reliability
5.1 IPsec Tunnel Backup

If IPsec is activated, the base station can communicate with the SeGW through the primary and
secondary IPsec tunnels, which operate in hot backup mode. The base station negotiates
individual IKE tunnels and IPsec tunnels for the primary and secondary SeGWs. This ensures
the reliability of the IPsec tunnels. Normally, IPsec traffic is transmitted through the primary
IPsec tunnel. If the primary IPsec tunnel is faulty, for example, due to a link failure, services are
automatically switched over to the secondary IPsec tunnel. The services are not automatically
switched back to the primary IPsec tunnel even when the primary IPsec tunnel recovers.
In the uplink, the base station usually uses the primary IPsec tunnel to send packets according
to user configurations. The MSPGN or MSPSN parameter specifies the primary IPsec tunnel.
The SSPGN or SSPSN parameter specifies the secondary IPsec tunnel. In the downlink, the
router must support the dynamic routing protocol to select routes.
When primary and secondary IPsec tunnels are used, the base station must use Bidirectional
Forwarding Detection (BFD) to detect connectivity between the base station and the SeGW. To
enable BFD, an IPsec tunnel must be bound to a BFD session ID. If BFD detects that the primary
IPsec tunnel is faulty:
l
In the uplink, the base station automatically switches services to the secondary IPsec tunnel.
In the downlink, the SeGW requires that BFD be bound to the dynamic routing protocol in
order to switch services to the secondary IPsec tunnel. If the SeGW detects that the primary
IPsec tunnel is faulty, the SeGW automatically switches services to the secondary IPsec
tunnel.
On the base station side, the source and destination IP addresses for a BFD session must be the
same as the local and peer IP addresses for the associated primary or secondary IPsec tunnel,
respectively.
For details about BFD, see IP Transport Architecture Feature Parameter Description.The
application constraints of IPsec Tunnel Backup are as follows:
l
IPsec Tunnel Backup cannot be used when two SeGWs work in hot backup mode.
When the primary IPsec tunnel is recovered, uplink data flows will not be automatically
switched back to the primary IPsec tunnel, which may cause asymmetrical data flows in
the uplink and downlink. This requires that the firewall on the SeGW side support
unidirectional data flows and the SeGW can trigger IKE negotiation.
IPsec Tunnel Backup does not apply to scenarios where the base station provides one
transmission port with VLAN configurations and one transmission port without VLAN
configurations.
If IPsec tunnel backup is enabled and the OM channel is IPsec-encrypted,the base station
cannot be deployed in PnP mode.
Issue 02 (2013-07-30)

22
SingleRAN
6 IEEE 1588v2 over IPsec
IEEE 1588v2 over IPsec
Data processing at the IP and Media Access Control (MAC) layers may be delayed. To eliminate
the delay and provide accurate timestamps for clock packets, IEEE 1588v2 defines that a
timestamp is attached after data processing at the MAC layer and before data processing at the
physical layer, as shown in Figure 6-1 . After an IEEE 1588v2 clock packet is encapsulated by
MAC and upper-layer protocols, an NE uses equipment to detect the User Datagram Protocol
(UDP) port number carried in the packet before data processing at the physical layer. If the UDP
port number is 319, the NE attaches a timestamp to the packet to record the leaving or arrival
time of the packet.
Figure 6-1 Timestamp processing in IEEE 1588v2
IPsec encrypts and verifies packets at the IP layer, whereas timestamps are attached to IEEE
1588v2 clock packets between data processing at the MAC layer and data processing at the
physical layer. As a result, two problems occur when IPsec is used to provide confidentiality
and data integrity protection for IEEE 1588v2 clock packets. The problems are as follows:
l
After IPsec encryption, the UDP port number carried in an IEEE 1588v2 clock packet
cannot be identified.
After IPsec data integrity protection by the sender, an IEEE 1588v2 clock packet fails the
data integrity check performed by the receiver due to an attached timestamp.
Issue 02 (2013-07-30)

23
SingleRAN
6 IEEE 1588v2 over IPsec
To solve these problems, the IEEE 1588v2 over IPsec solution is introduced. This solution
enables IPsec encryption for Layer 3 (L3) unicast packets in frequency synchronization. The
procedure is as follows:
1.
Upon receiving an encrypted packet that cannot be identified as an IEEE 1588v2 clock
packet, the base station records the arrival time of the packet and sends the timestamp to
the upper layer together with the encrypted packet.
2.
The base station decrypts the encrypted packet and checks whether the packet is an IEEE
1588v2 clock packet based on the UDP port number.
3.
If the packet is an IEEE 1588v2 clock packet, the base station checks the leaving time of
the packet. The base station then uses the Adapter Clock Recover (ACR) algorithm to
restore the clock frequency based on the leaving and arrival time of the packet.
NOTE
This solution applies only to L3 unicast packets in frequency synchronization. This solution does not apply
to time synchronization because time synchronization has the following restrictions:
l Timestamps are required for all L3 equipment between the base station and SeGW.
l Intermediate equipment cannot identify IEEE 1588v2 clock packets within encrypted packets.
Issue 02 (2013-07-30)

24
SingleRAN
7 IPsec Application
IPsec Application
7.1 Typical IPsec Networking

Huawei base stations support IPsec. To protect data transmitted between the base station and
base station controller, an SeGW must be deployed on the network.
In typical IPsec networking, the base station and the SeGW use digital certificates to authenticate
each other. Therefore, a PKI system and a public DHCP server must be deployed on the operator's
network. As stipulated in 3GPP TS 33.310, the Initialization Response message sent by the
operator's CA server must contain the operator's root certificate or certificate chain. The
operator's CA server must be preconfigured with the Huawei root certificate.Figure 7-1 shows
the typical IPsec networking.
Figure 7-1 Typical IPsec networking
Issue 02 (2013-07-30)

25
SingleRAN
7 IPsec Application
NOTE
The connection mode between the router and SeGW is determined in the network plan.
l On an existing network, an SeGW is recommended on the router side.
l On a newly deployed network, the router should connect directly to the SeGW.
In the typical IPsec networking, the base station must obtain a device certificate from the CA
before an IPsec tunnel is established between the base station and SeGW. For details about how
to apply for a device certificate, see PKI Feature Parameter Description.
Base stations can be deployed in two modes in the typical IPsec networking:
l
Automatic base station deployment by plug and play (PnP)

If a public DHCP server is deployed on the network and O&M data is protected by
IPsec, two temporary IPsec tunnels are established between the base station and SeGW.
The base station uses the second IPsec tunnel to obtain the configuration file. After the
configuration file is obtained, the base station negotiates with the SeGW according to
the file, and establishes a formal IPsec tunnel. For the purpose and requirements of
temporary IPsec tunnels, see Automatic OMCH Establishment Feature Parameter
Description.
If no public DHCP server is deployed on the network and O&M data is protected by
IPsec, only one temporary IPsec tunnel is established between the base station and
SeGW. The base station uses the IPsec tunnel to obtain the configuration file. After the
configuration file is obtained, the base station negotiates with the SeGW according to
the file, and establishes a formal IPsec tunnel. For the automatic OMCH establishment
procedure, see Automatic OMCH Establishment Feature Parameter Description.
If O&M data is not protected by IPsec, the base station directly obtains the configuration
file, negotiates with the SeGW according to the file, and establishes a formal IPsec
tunnel.
Automatic base station deployment by USB

The base station negotiates with the SeGW according to the configuration file and directly
establishes a formal IPsec tunnel.
7.2 Application of IPsec on Macro Base Stations

To apply IPsec on a Huawei base station, the base station must be configured with a UMPT,
LMPT, or UTRPc because only Ethernet ports on these boards support IPsec.
7.2.1 Application of IPsec on GBTSs

A GBTS uses either of the following board combinations to implement IPsec:
l
GTMUb+UMPT_L/LMPT
The GTMUb and UMPT_L/LMPT communicate with each other through the BBU
backplane, and the UMPT_L/LMPT provides IPsec and transfers GBTS data.
Figure 7-2 shows an example of implementing IPsec on a GBTS configured with the
GTMUb and UMPT_L.
Issue 02 (2013-07-30)

26
SingleRAN
7 IPsec Application
Figure 7-2 Example of implementing IPsec on a GBTS configured with the GTMUb and
UMPT_L
NOTE
UMPT_L refers to a UMPT working in LTE(FDD) mode,and UMPT_T refers to a UMPT working in LTE
(TDD) mode.
GTMUb+UTRPc
The GTMUb and UTRPc communicate with each other through the BBU backplane, and
the UTRPc provides IPsec and connects to the transport network.
Figure 7-3 shows an example of implementing IPsec on a GBTS configured with the
GTMUb and UTRPc.
Figure 7-3 Example of implementing IPsec on a GBTS configured with the GTMUb and the
UTRPc
GTMUb+UMPT_L is recommended for GBTSs to implement IPsec.

The UTRPc cannot be used for existing 3012 series base stations. To implement IPsec on such
a base station or to enable the base station to support IPsec after being upgraded to a multimode
base station, an external SeGW must be deployed on the base station side, as shown in Figure
7-4.
Figure 7-4 External SeGW deployed on the base station side
Issue 02 (2013-07-30)

27
SingleRAN
7 IPsec Application
7.2.2 Application of IPsec on eGBTSs, NodeBs, and eNodeBs

Generally, an eGBTS, NodeB, or eNodeB uses a UMPT_G, UMPT_U, UMPT_L or UMPT_T
to implement IPsec, as shown in Figure 7-5 .
NOTE
UMPT_G refers to the UMPT working in GSM mode, UMPT_U refers to the UMPT working in UMTS
mode, UMPT_L refers to the UMPT working in LTE(FDD) mode,and UMPT_T refers to the UMPT
working in LTE(TDD) mode.
Figure 7-5 Example of implementing IPsec on an eGBTS, NodeB, or eNodeB
To implement IPsec on an existing 3812 series base station or to enable the base station to support
IPsec after being upgraded to a multimode base station, an external SeGW must be deployed on
the base station side.
7.2.3 Application of IPsec on Multimode Base Stations

Multimode base stations are classified into co-MPT and separate-MPT multimode base stations.
IPsec can be applied on both of them.
Co-IPsec on Co-MPT Multimode Base Stations

To implement co-IPsec:
l
A co-MPT GU dual-mode base station uses a UMPT_GU.

The UMPT_GU supports GSM and UMTS and provides IPsec for eGBTS and NodeB data
flows.
A co-MPT GL dual-mode base station uses a UMPT_GL.

The UMPT_GL supports GSM and LTE and provides IPsec for eGBTS and eNodeB data
flows.
A co-MPT UL dual-mode base station uses a UMPT_UL.

The UMPT_UL supports UMTS and LTE and provides IPsec for NodeB and eNodeB data
flows.
A co-MPT GUL multimode base station uses a UMPT_GUL, as shown in Figure 7-6.
The UMPT_GUL supports GSM, UMTS, and LTE and provides IPsec for eGBTS, NodeB,
and eNodeB data flows.
Issue 02 (2013-07-30)

28
SingleRAN
7 IPsec Application
Figure 7-6 Example of implementing co-IPsec on a co-MPT GUL multimode base station
Co-IPsec on Separate-MPT Multimode Base Stations

To implement co-IPsec:
l
A separate-MPT GU dual-mode base station uses GTMUb+UMPT_U.

The GTMUb and UMPT_U communicate with each other through the BBU backplane,
and the UMPT_U provides IPsec for GBTS and NodeB data flows.
A separate-MPT GL dual-mode base station uses GTMUb+UMPT_L .

The GTMUb and UMPT_L communicate with each other through the BBU backplane, and
the UMPT_L provides IPsec for GBTS and eNodeB data flows.
A separate-MPT UL dual-mode base station uses UMPT_U+UMPT_L .

The UMPT_U and UMPT_L or communicate with each other through the BBU backplane,
and the UMPT_L provides IPsec for NodeB and eNodeB data flows.
A separate-MPT GUL multimode base station uses UMPT_L+GTMUb+UCIU or in the

root BBU and the UMPT_U in the leaf BBU, as shown in Figure 7-7.
The two BBUs are interconnected by connecting the UCIU and UMPT_U. In the root BBU,
the GTMUb and UMPT_L communicate with each other through the BBU backplane, and
the UMPT_L or UMPT_T provides IPsec for GBTS, NodeB, and eNodeB data flows.
Figure 7-7 Example of networking for co-IPsec on a separate-MPT GUL multimode base station
NOTE
Implementing Co-IPsec on a separate-MPT multimode base station requires co-transmission.
7.3 External IPsec on the Base Station Controller Side

If bearer networks such as leased networks and public networks encounter security threats, IPsec
tunnels can be used to isolate network services for secure transmission. Currently, base station
Issue 02 (2013-07-30)

29
SingleRAN
7 IPsec Application
controllers do not support integrated IPsec and therefore can only use external IPsec. Figure
7-8 shows an example of external IPsec on the base station controller side.
Figure 7-8 Example of external IPsec on the base station controller side
The throughput of an external SeGW must exceed the planned total traffic volume on GSM and
UMTS user planes.
If no SeGW is deployed on the operator's network, it is recommended that you use Huawei
Eudemon1000E-X or Eudemon8000E-X to implement external IPsec on the base station
controller side.
It is recommended that the following functions be disabled on the SeGW:
l
Whitelist
Interface boards on a base station controller have firewalls and provide the whitelist
function.
Packet filtering based on the UDP port number

Disabling this function on the SeGW prevents normal packets from being filtered out.
Whether to deploy an external SeGW for IPsec depends on customer requirements.
7.4 Application of IPsec on Cascaded Base Stations

When base stations are cascaded, IPsec can be implemented in two ways:
l
Each base station has a separate IPsec tunnel and the Hub base station provides route
forwarding, as shown in Figure 7-9 .
The Hub base station provides one IPsec tunnel or all cascaded base stations, as shown in
Figure 7-10 .
Issue 02 (2013-07-30)

30
SingleRAN
7 IPsec Application
Figure 7-9 Separate IPsec tunnel for each base station and route forwarding by the Hub base
station
Figure 7-10 IPsec tunnel provided by the Hub base station for all cascaded base stations
In base station cascading scenarios, it is recommended that the Hub base station be used only
for route forwarding, as shown in Figure 7-9 .
7.5 Network Evolution Solutions

Operators use three evolution solutions described in Table 7-1 to reconstruct existing networks.
Table 7-1 Network evolution solutions
Issue 02 (2013-07-30)
Network Evolution Solution
Network Equipment Deployment

Requirement
Evolution from an insecure transport network to a

secure network that uses digital certificate
authentication (referred to as the PKI-based
secure network)
A PKI system, public DHCP server, and

SeGW must be deployed. The SeGW can
use digital certificates to authenticate the
identity of the peer end.

31
SingleRAN
7 IPsec Application
Network Evolution Solution
Network Equipment Deployment

Requirement
Evolution from an insecure transport network to a

secure network that uses PSK authentication
(referred to as the PSK-based secure network)
An SeGW must be deployed. The SeGW

can use a PSK to authenticate the identity
of the peer end.
Evolution from a PSK-based secure network to a

PKI-based secure network
A PKI system, public DHCP server, and

SeGW must be deployed. The SeGW can
use digital certificates to authenticate the
identity of the peer end.
In the evolution from an insecure transport network to a secure network, if the SeGW and PKI
system have already been deployed, operators can directly upgrade the insecure transport
network to a PKI-based secure network. During the evolution, users need to download and
activate configuration data. This process interrupts ongoing services.
In the evolution from a PSK-based secure network to a PKI-based secure network, users need
to modify configuration data online and specify a board where a certificate is to be deployed.
The base station must be reset for the modifications to take effect, which interrupts ongoing
services. Users can run the SET BTSCERTDEPLOY and SET CERTDEPLOY commands
to set a board where a certificate is to be deployed on the GBTS and the eGBTS/NodeB/eNodB,
respectively.
Issue 02 (2013-07-30)

32
SingleRAN
8 Related Features
Related Features
The IPsec feature relates to the following features:

l
LOFD-003009 IPsec
LOFD-003019 IPsec Tunnel Backup
Issue 02 (2013-07-30)

33
SingleRAN
8 Related Features
8.1 Features Related to Integrated IPsec on the Base Station

Prerequisite Features
l

This feature requires the GBFD-118601 Abis over IP feature. If IPsec uses digital certificate
authentication, this feature also requires the GBFD-113526 BTS Supporting PKI feature.

This feature requires the WRFD-050402 IP Transmission Introduction on Iub Interface
feature. If IPsec uses digital certificate authentication, this feature also requires the
WRFD-140210 NodeB PKI Support feature.
LOFD-003009 IPsec
If IPsec uses digital certificate authentication, this feature requires the LOFD-003010
Public Key Infrastructure(PKI) feature.

This feature requires the GBFD-118601 Abis over IP feature. If IPsec uses digital certificate
authentication, this feature also requires the GBFD-113526 BTS Supporting PKI feature.

This feature requires the WRFD-050402 IP Transmission Introduction on Iub Interface
feature. If IPsec uses digital certificate authentication, this feature also requires the
WRFD-140210 NodeB PKI Support feature.

If IPsec uses digital certificate authentication, this feature requires the LOFD-003010
Public Key Infrastructure(PKI) feature.
Mutually Exclusive Features

The GBFD-113524 BTS Integrated IPsec and MRFD-211602 Co-IPSec Between GSM, UMTS
and LTE (GSM) features cannot be used together with the GBFD-117702 BTS Local Switch
feature.
The MRFD-211602 Co-IPSec Between GSM, UMTS and LTE (GSM) feature cannot be used
together with the GBFD-118611 Abis IP over E1/T1 feature.
Impacted Features
None
8.2 Features Related to IPsec Tunnel Backup

Prerequisite Features
The LOFD-003019 IPsec Tunnel Backup feature requires the LOFD-003009 IPsec and
LOFD-003007 Bidirectional Forwarding Detection features.
Issue 02 (2013-07-30)

34
SingleRAN
8 Related Features
Mutually Exclusive Features

None
Impacted Features
None
Issue 02 (2013-07-30)

35
SingleRAN
9 Network Impact
Network Impact
System Capacity
No impact.
Network Performance
IPsec ensures transmission security by encapsulating and encrypting IP packets. This reduces
the transmission efficiency of service packets on the bearer network.
Take ESP encapsulation in tunnel mode as an example. Assume that the IP payload is 500 bytes,
the packet length (including the IP header and Ethernet header) before IPsec encapsulation is
540 bytes, the encryption algorithm is 3DES, and the authentication algorithm is MD5. Then,
the packet structure after encapsulation is as follows:
20 bytes (Ethernet header) + 20 bytes (external IP header) + 8 bytes (ESP header) + 20 bytes
(internal IP header) + 8 bytes (initialization vector) + 500 bytes (payload) + 2 bytes (padding)
+ 2 bytes (ESP trailer) + 16 bytes (integrity check value for MD5)
The total length is 596 bytes. The transmission efficiency decreases from 92.59% to 83.89%.
The impact of IPsec on the transmission efficiency of service data varies depending on the
protocol, algorithm, and encapsulation mode. Table 9-1 and Table 9-2 describe the impact of
IPsec on the transmission efficiency when AH and the MD5, SHA, or SHA2 (256 bits) algorithm
are used for data integrity check.
Table 9-1 Impact of IPsec on the transmission efficiency in transport mode
Service
FR
MCS9
AMR
12.2k
PS
32kbps
CS
64kbps
PS
128kbp
s
PS
384kbps
IPsec
disabled
32%
65.5%
29%
51.6%
69.3%
78.6%
83.5%
MD5
25%
58.3%
22.9%
43.7%
61.8%
73.6%
79.6%
SHA
24.4%
57.4%
22.3%
42.8%
60.8%
72.9%
78.9%
Algorith
m
Issue 02 (2013-07-30)

36
SingleRAN
Service
9 Network Impact
FR
MCS9
AMR
12.2k
PS
32kbps
CS
64kbps
PS
128kbp
s
PS
384kbps
22.4%
54.8%
20.5%
40.2%
58.2%
71.0%
77.5%
Algorith
m
SHA2
Table 9-2 Impact of IPsec on the transmission efficiency in tunnel mode

Service
FR
MCS-9
AMR
12.2k
PS 32kbps
CS
64kbps
PS
128kbps
PS
384kbps
IPsec
disabled
32%
65.5%
29%
51.6%
69.3%
78.6%
83.5%
MD5
21.9%
54%
20.0%
39.4%
57.4%
70.3%
77.0%
SHA
21.3%
53.2%
19.4%
38.6%
56.5%
69.7%
76.6%
SHA2
19.8%
51%
18.4%
36.5%
54.2%
67.9%
75.1%
Algorith
m
Table 9-3 and Table 9-4 describe the impact of IPsec on the transmission efficiency when ESP
and the DES, 3DES, or AES algorithm are used for encryption.
Table 9-3 Impact of IPsec on the transmission efficiency in transport mode
Service
FR
MCS-9
AMR
12.2k
PS
32kbps
CS
64kbps
PS
128kbps
PS
384kbps
IPsec
disabled
32%
65.5%
29%
51.6%
69.3%
78.6%
83.5%
DES/
3DES
23.9%
56.4%
22.1%
43.0%
60.2%
72.4%
78.7%
23.2%
55.6%
21.5%
42.1%
59.3%
71.7%
78.2%
AES
+MD5
23.9%
55.6%
20.9%
41.2%
58.4%
71.1%
78.7%
AES
+SHA
23.2%
54.8%
20.3%
40.4%
57.6%
70.5%
78.2%
Algorith
m
+MD5
DES/
3DES
+SHA
Issue 02 (2013-07-30)

37
SingleRAN
9 Network Impact
Table 9-4 Impact of IPsec on the transmission efficiency in tunnel mode

Service
FR
MCS-9
AMR
12.2k
PS
32kbps
CS
64kbps
PS
128kbps
PS
384kbps
IPsec
disabled
32%
65.5%
29%
51.6%
69.3%
78.6%
83.5%
DES/
3DES
20.4%
52.5%
18.7%
38.1%
56.7%
69.9%
76.7%
19.9%
51.7%
18.3%
37.4%
55.9%
69.3%
76.2%
AES
+MD5
19.4%
52.5%
18.7%
38.1%
55.2%
68.7%
76.7%
AES
+SHA
19.4%
51.7%
18.3%
37.4%
54.4%
68.1%
76.2%
Algorith
m
+MD5
DES/
3DES
+SHA
If IPsec is enabled on an operator's network, the time required for initial base station deployment
increases by less than 2 minutes when transmission is available. The increased time, caused by
certificate requests and IPsec tunnel setups, depends on the response speed of the public DHCP
server and the encryption protocol used by the SeGW.
Issue 02 (2013-07-30)

38
SingleRAN
10 Engineering Guidelines
10
Engineering Guidelines
10.1 When to Use IPsec

Unlike time division multiplexing (TDM) networks, IP networks cannot ensure transmission
security. If an operator uses a public IP network, activate the IPsec feature to provide integrity
and confidentiality protection for wireless services. If the operator requires that IPsec negotiation
use digital certificate authentication, activate the PKI feature. For details about how to activate
the PKI feature, see PKI Feature Parameter Description.
10.2 Required Information

Before activating the IPsec feature, engineering personnel must confirm the peer SeGW
configuration information listed in Table 10-1 with the operator to ensure successful IPsec
negotiation between communicating peers.
Table 10-1 Information for IPsec negotiation
Issue 02 (2013-07-30)
Information to Be Collected
Parameters on the Base Station

Side
IKE information
IKE version
Version
IKEv1 exchange mode
Exchange Mode
Type of the local ID
Local ID Type
IP address of the SeGW
Remote IP Address

39
SingleRAN
Information to Be Collected
IKE name of the SeGW
Parameters on the Base Station

Side
Remote Name
NOTE
l If a PSK is used for identity
authentication, obtain the local
name of the SeGW.
l If digital certificates are used
for identity authentication,
obtain information about the
subjectaltname field in the
device certificate used by the
SeGW.
IKE encryption algorithm
Encryption Algorithm
IKE integrity protection

algorithm
Authentication Algorithm
IKE PRF algorithm
PRF Algorithm
IKE DH group
Diffie-Hellman Group
DPD switch
DPD Mode
NOTE
If DPD is enabled on the SeGW,
obtain the following information:
l DPD Idle Time
l DPD Retransmission Interval
l DPD Retransmission Count
IPsec information
Issue 02 (2013-07-30)
DPD idle time
DPD Idle Time
DPD packet retransmission

interval
DPD Retransmission Interval
Number of DPD packet

retransmissions
DPD Retransmission Count
Authentication method
Authentication Method
IPsec encapsulation mode
Encapsulation Mode
IPsec protocol type
Transform
ESP encryption algorithm
ESP Encryption Algorithm
ESP integrity protection

algorithm
ESP Authentication Algorithm
AH integrity protection
algorithm
AH Authentication Algorithm
Perfect forward secrecy (PFS)

flag
Perfect Forward Secrecy

40
SingleRAN
10.3 Planning
10.3.1 Network Planning
IPsec Networking
IPsec networking concerns three major factors:
l
Security and non-security domains

An operator's network is divided into security and non-security domains. IPsec protects
only the non-security domain. Usually, the core network (CN) is considered secure and the
access network is considered insecure. SeGWs are deployed between the two domains to
provide IPsec for data flows transmitted between the base station and SeGW.
Authentication method
Two authentication methods can be used between the base station and SeGW: PKI and
PSK authentication. Depending on the authentication method, IPsec networks are classified
into PKI- and PSK-based secure networks. They have different deployment requirements.
For details, see section 10.4 Requirements.
Data flow protection

Data flows on the base station include signaling, services, O&M, and clock data flows. In
network planning, the operator must identify data flows to be protected and specify
protection policies. Huawei base stations provide IPsec and Secure Sockets Layer (SSL)
protection for O&M data flows.
Figure 10-1 shows an example of the PKI-based secure network in which O&M data flows are
protected by IPsec and can be protected by SSL first.
Figure 10-1 Example of the PKI-based secure network in which O&M data flows are protected
by IPsec
Figure 10-2 shows an example of the PKI-based secure network in which O&M data flows are
protected by SSL rather than IPsec.
Issue 02 (2013-07-30)

41
SingleRAN
Figure 10-2 Example of the PKI-based secure network in which O&M data flows are protected
by SSL rather than IPsec
Centralized protection is recommended for data flows transmitted by eNodeBs over X2

interfaces. In centralized protection mode, an IPsec tunnel is established between each eNodeB
and the SeGW. During communication, the IPsec tunnel protects data flows transmitted over
X2 interfaces.
Figure 10-3 Example of the IPsec network on the X2 interface
Networking with IPsec Tunnel Backup

When the IPsec Tunnel Backup feature is used, a pair of primary and secondary IPsec tunnels
are established between a base station and two SeGWs. In typical networking, the base station
provides one or two physical ports for IPsec tunnel establishment, depending on the actual
transmission conditions.
l
Issue 02 (2013-07-30)
If two physical ports are provided, IPsec policies are bound to the two ports and BFD is
enabled, as shown in Figure Figure 10-4 .
42
SingleRAN
Figure 10-4 Example of networking in which the base station provides two physical ports
If one physical port is provided, security policies are bound to the same port and BFD is
enabled, as shown in Figure 10-5 .
Figure 10-5 Example of networking in which the base station provides one physical port
10.3.2 Hardware Planning

GBTS/eGBTS
Among 3900 series GSM base stations, GBTSs must be configured with a UMPT_L, LMPT, or
UTRPc to support IPsec and IPsec Tunnel Backup; eGBTSs must be configured with a UMPT_G
to support IPsec and IPsec Tunnel Backup.
NodeB
To support IPsec and IPsec Tunnel Backup, 3900 series WCDMA base stations must be
configured with a UMPT_U or UTRPc.
eNodeB
3900 series LTE base stations must be configured with a UMPT_L, LMPT, or UTRPc to support
IPsec and IPsec Tunnel Backup.
Multimode Base Station

3900 series multimode base stations must be configured with a UMPT, LMPT, or UTRPc to
provide security protection.
Issue 02 (2013-07-30)

43
SingleRAN
10.4 Requirements
The IPsec feature has the following deployment requirements:
l
An SeGW is deployed on the operator's network.
The SeGW complies with the encryption protocol defined in IETF RFC 2409 or 4306 and
supports PKI or PSK authentication.
The license for the IPsec feature has been activated.Table 10-2 lists the license information
for IPsec.
Table 10-2 License information for IPsec
Feature ID
Feature
Name
License
Control Item
NE
Sales Unit
GBFD-113524
BTS Integrated
IPsec
BTS Integrated
IPsec
GBTS/
eGBTS
Per GBTS/
eGBTS
WRFD-14020
9
NodeB
Integrated
IPsec
NodeB
Integrated
IPsec
NodeB
Per NodeB
LOFD-003009
IPsec
IPsec
eNodeB
Per eNodeB
MRFD-21160
2
Co-IPsec
Between GSM,
UMTS and
LTE (GSM)
Co-IPsec
Between GSM,
UMTS and
LTE (GSM)
MBTS
Per MBTS
MRFD-22160
2
Co-IPsec
Between GSM,
UMTS and
LTE (UMTS)
Co-IPsec
Between GSM,
UMTS and
LTE (UMTS)
MBTS
Per MBTS
MRFD-23160
2
Co-IPsec
Between GSM,
UMTS and
LTE (LTE)
Co-IPsec
Between GSM,
UMTS and
LTE (LTE)
MBTS
Per MBTS
NOTE
The co-IPsec license activation rules for a multimode base station are as follows:
l The co-IPsec license needs to be activated only for the mode that provides a transmission port. For
example, to implement co-IPsec on a GU dual-mode base station, only the license for the
MRFD-221602 Co-IPsec Between GSM, UMTS and LTE (UMTS) feature needs to be activated if a
transmission port is provided by the UMTS mode.
l If a UTRPc provides a transmission port, the co-IPsec license needs to be activated for the mode that
controls the UTRPc. For example, if the UMTS mode controls the UTRPc, the license for the
MRFD-221602 Co-IPsec Between GSM, UMTS and LTE (UMTS) feature must be activated.
Issue 02 (2013-07-30)

44
SingleRAN
If digital certificate authentication is used between the base station and SeGW, the PKI
deployment requirements must also be met. For details, see PKI Feature Parameter
Description.
If PSK authentication is used between the base station and SeGW, the same PSK must be
preconfigured on both sides.
The IPsec Tunnel Backup feature has the following deployment requirements:
l
Single- or multi-hop BFD sessions can be established between the base station and SeGW.
The SeGW can publish the BFD status to NEs in the security domain, enabling the NEs to
dynamically modify downlink routes.
The license for the IPsec Tunnel Backup feature has been activated. Table 10-3 lists the
license information for IPsec Tunnel Backup.
Table 10-3 License information for IPsec Tunnel Backup
Feature ID
Feature Name
License
NE
Sales Unit
LOFD-003019
IPsec Tunnel
Backup
IPsec Tunnel
Backup
eNodeB
Per eNodeB
The license for the LOFD-003007 Bidirectional Forwarding Detection feature has been
activated.
NOTE
GBTSs, eGBTSs, and NodeBs do not have the license for the IPsec Tunnel Backup feature.
10.5 Configuration Principles

10.5.1 IPsec Policies
The operator can configure one or multiple IPsec policies according to actual network conditions.
Each IPsec policy is bound to one ACL. In an ACL, one or multiple ACL rules can be configured
for data flows that need to be protected by IPsec. The base station provides IPsec for data flows
that comply with the ACL rules. An IPsec policy takes effect only after it is bound to a
transmission port.
IPsec configuration principles are as follows:
l
An ACL rule is added to an ACL by using the ACLID parameter.
An IKE proposal is bound to an IKE peer by using the PROPID parameter.
An ACL is bound to an IPsec policy by using the ACLID parameter.
An IKE peer is bound to an IPsec policy by using the PEERNAME parameter.
An IPsec proposal is bound to an IPsec policy by using the PROPNAME parameter.
An IPsec policy is bound to a transmission port by using the SPGN parameter.
Figure 10-6 shows the IPsec configuration principles.

Issue 02 (2013-07-30)

45
SingleRAN
Figure 10-6 IPsec configuration principles
NOTE
Each IPsec tunnel corresponds to an IPsec policy, which is specified by the SPGN and SPSN parameters.
Multiple IPsec SAs can be established in an IPsec tunnel. The number of IPsec SAs depends on the number
of configured ACL rules. The operator can configure specific ACL rules for different types of data flows
to establish individual IPsec SAs for these data flows.
In various network conditions, the configuration of LMPT is the same as that of UMPT_L.
The IKECFG MO is optional. For PSK-based secure networks, the IKELNM parameter in the IKECFG
MO must be set when the IDTYPE parameter in the IKEPEER MO is set to FQDN.
If the operator requires multiple IPsec tunnels, multiple IPsec policies must be configured and
bound to different IKE peers and ACLs. If the operator requires multiple IPsec policies to be
bound to the same port, these policies must have the same SPGN value but different SPSN
values. Multiple IPsec policies can be bound to the same port by using the SPGN parameter.
10.5.2 ACL Rules

ACL rules are configured in two modes:
l
Any to Any
The value of RULEID for an ACL rule whose ACTION is set to DENY must be smaller
than that for an ACL rule whose ACTION is set to PERMIT. In Any to Any mode,
configure ACL rules as follows:
1.
Configure an ACL rule with the parameter settings as follows:

- SIP: set to an interface IP address.
- SWC and DIP: set to 0.0.0.0.
- DWC: set to 255.255.255.255.
- ACTION: set to DENY.
2.
Configure ACL rules for data flows that do not need to be protected by IPsec.
The parameter settings for the ACL rules are as follows:
- SIP: set to the source IP address of the data flow.
-SWC and DIP: set to 0.0.0.0.
- DWC: set to 255.255.255.255.
- ACTION: set to DENY.
3.
Issue 02 (2013-07-30)
Configure an ACL rule in Any to Any mode with the parameter settings as follows:
46
SingleRAN
SIP and DIP: set to 0.0.0.0.

SWCand DWC: set to 255.255.255.255.
ACTION: set to PERMIT.
The value of RULEID for an ACL rule whose ACTION is set to DENY must be smaller
than that for an ACL rule whose ACTION is set to PERMIT.
l
IP to Any
Configure ACL rules for data flows that need to be protected by IPsec.
The parameter settings for the ACL rules are as follows:
SIP: set to the source IP address of the data flow
SWC and DIP: set to 0.0.0.0.
DWC: set to 255.255.255.255.
ACTION: set to PERMIT.
NOTE
l Any to Any mode applies only to scenarios where a base station is interconnected with an SeGW
provided by Juniper. The following sections use IP to Any mode as an example to describe how to
configure ACL rules. The specific method for configuring ACL rules depends on the network plan.
l No two ACL rules can apply to the same data flow.
10.6 Deployment of IPsec on a PKI-based Secure Network

This section describes IPsec data preparation, initial configuration, and activation observation
on a PKI-based secure network. For the PKI data preparation, initial configuration, and activation
observation, see PKI Feature Parameter Description.
10.6.1 Deploying IPsec on an eGBTS, NodeB, or eNodeB

On a PKI-based secure network, IPsec configurations are the same for eGBTSs, NodeBs, and
eNodeBs. This section uses the network shown in Figure 10-7 as an example to describe how
to deploy IPsec on an eNodeB on a PKI-based secure network.
Figure 10-7 Example of deploying IPsec on an eNodeB on a PKI-based secure network
Issue 02 (2013-07-30)

47
SingleRAN
In this networking scenario, the UMPT_L provides IPsec for the following data flows:
l
eNodeB signaling and service data flows.
eNodeB O&M data flows.
Certificate management-related data flows between the eNodeB and CA.
Data flows generated when the eNodeB obtains CRLs or certificate files from the CRL
server.
NOTE
IPsec configurations are the same for co-MPT and separate-MPT multimode base stations. Therefore, the
following configurations apply to both.
Data Preparation
"-" in the following tables in this section indicates that there is no special requirement for setting
the parameters. Set the parameters based on site requirements.
Table 10-4 lists the data to prepare for an IKE proposal (the IKEPROPOSAL MO in MML
configurations and the IKEPROPOSAL or IKE Proposal MO in CME configurations).
Table 10-4 Data to prepare for an IKE proposal
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Data Source
Proposal ID
PROPID
User-defined
Encryption
Algorithm
ENCALG
The parameter settings on the

base station and SeGW sides
must be the same.
Network plan
Authentication
Algorithm
AUTHALG

must be the same.
Authentication
Method
AUTHMETH
This parameter must be set to

IKE_RSA_SIG if digital
certificates are used for identity
authentication.The parameter
settings on the base station and
SeGW sides must be the same.
Diffie-Hellman
Group
DHGRP

must be the same.
PRF Algorithm
PRFALG
This parameter must be set when

the IKEVERSION parameter in
the IKEPEER MO is set to
IKE_V2. The parameter
settings on the base station and
SeGW sides must be the same.

48
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
ISAKMP SA
Duration(s)
DURATION

must be the same.
Data Source
Table 10-5 lists the data to prepare for an IKE peer (the IKEPEER MO in MML configurations
and the IKEPEER or IKE Peer MO in CME configurations).
Table 10-5 Data to prepare for an IKE peer
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Data Source
IKE Peer Name
PEERNAME
User-defined
IKE Proposal ID
PROPID
The value of this parameter must

be the same as the value of
PROPID in the
IKEPROPOSAL MO.
Version
IKEVERSION

must be the same.
Exchange Mode
EXCHMODE
Set this parameter when

IKEVERSION is set to IKEV1. The parameter settings on
the base station and SeGW sides
must be the same. The
recommended value of this
parameter is MAIN.
Local ID Type
IDTYPE
If digital certificate
authentication is used, the
parameter is FQDN.

Network plan
Negotiation
with the IKE
peer
49
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
Data Source
Remote IP
Address
REMOTEIP
l If ENCAPMODE in the
IPSECPROPOSAL MO is
set to TRANSPORT, the
value of this parameter must
be the same as that of DIP in
the ACLRULE MO.
Otherwise, encrypted packets
cannot be decrypted.
Network plan
IPSECPROPOSAL MO is
set to TUNNEL, the value of
this parameter must be the
same as the IP address of the
peer SeGW.
Remote Name
REMOTENAME
In the case of digital certificate

authentication:
l If this parameter is set, the
be the same as the value of the
subjectaltname field in the
device certificate used by the
SeGW.
l If this parameter is not set, the
base station does not
authenticate the identity of
the SeGW during IKE
negotiation.
Pre-shared Key
Issue 02 (2013-07-30)
PKEY
DPD Mode
DPD
DPD Idle Time(s)
DPDIDLETIME
DPD
Retransmission
Interval(s)
DPDRETRI
DPD
Retransmission
Count
DPDRETRN
authentication is used, this
parameter does not need to be set.
l Network
plan
DPD is enabled by default. Set

the DPD-related parameters to
same values at both IKE ends. If
the values are different, the IKE
end with a shorter timer length
will detect that the peer is offline
before the other IKE end does,
and an IKE renegotiation will be
triggered.
Network plan

l Negotiatio
n with the
IKE peer
50
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
Local IP Address
LOCALIP
This parameter specifies the

local IP address for IKE
negotiation.
Data Source
l If there is only one device IP

address, the device IP address
is used by default when this
parameter is set to the invalid
value 0.0.0.0.
l If there are multiple device IP
addresses, set this parameter
to one of the IP addresses that
belongs to a port bound with
IPsec policies.
If ENCAPMODE in the
IPSECPROPOSAL MO is
set to TRANSPORT, set this
parameter to a value same as
SIP in the ACLRULE MO.
Table 10-6lists the data to prepare for an ACL (the ACL MO in MML configurations and the
ACL or Access Control List MO in CME configurations)
Table 10-6 Data to prepare for an ACL
Parameter
Name
Parameter ID
Setting Notes
Data Source
ACL ID
ACLID
l At least one ACL rule must

be defined for each ACL.
User-defined
l If an ACL is bound to an
IPsec policy, the value of
this parameter ranges from
3000 to 3999.
Description
ACLDESC
Table 10-7 lists the data to prepare for an ACL rule (the ACLRULE MO in MML configurations
and the ACLRULE or Access Control List Rule MO in CME configurations). Multiple ACL
rules can be configured to protect different types of data flows. How many ACL rules are
configured depends on the network plan.
Issue 02 (2013-07-30)

51
SingleRAN
Table 10-7 Data to prepare for an ACL rule

Parameter
Name
Parameter ID
Setting Notes
Data
Source
ACL ID
ACLID
The value of this parameter

must be the same as that of
ACLID in the ACL MO.
User-defined
Rule ID
RULEID
Each ACL rule in an ACL must

have a unique ID.
Action
ACTION
Set this parameter according to

the network plan. It can be set
to DENY or PERMIT.
Network
plan
When an ACL rule in an ACL

is used to match packets:
l If a packet matches the ACL
rule, the base station
determines whether to
encrypt the packet by IPsec
based on the value of this
parameter.
l If a packet does not match
the ACL rule, the base
station does not encrypt the
packet, and tries the next
ACL rule until all ACL
rules in the ACL have been
tried.
The value of RULEID for
an ACL rule whose
ACTION is set to DENY
must be smaller than that for
an ACL rule whose
ACTION is set to
PERMIT.
Issue 02 (2013-07-30)
Protocol Type
PT
Source IP Address
SIP
If ENCAPMODE in the
IPSECPROPOSAL MO is set
to TRANSPORT, the value of
this parameter must be a
configured device IP address.

52
SingleRAN
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Destination IP
Address
DIP
If ENCAPMODE in the
IPSECPROPOSAL MO is set
to TRANSPORT, the value of
this parameter must be a host IP
address, not a network segment
address. The value of this
parameter must be the same as
that of REMOTEIP in the
IKEPEER MO. Otherwise,
encrypted packets cannot be
decrypted.
Source Wildcard
SWC

wildcard for a source IP
address, that is, the inverse of
the subnet mask of the source
IP address.
Destination
Wildcard
DWC

wildcard for a destination IP
the subnet mask of the
destination IP address.
Match Source
Port
SMPT
This parameter and MFRG

cannot be simultaneously set to
YES.
Source Port
Operate
SOP
Source Port 1
SPT1
Source Port 2
SPT2
Match
Destination Port
DMPT

cannot be simultaneously set to
YES.
Destination Port
Operate
DOP
Destination Port 1
DPT1
Destination Port 2
DPT2
Match DSCP
MDSCP
DSCP
DSCP

Data
Source
53
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
Data
Source
Match Fragment
Message
MFRG
Set this parameter to NO if an

ACL is bound to an IPsec
policy.
VLAN ID
Operate
VLANIDOP
If an ACL is bound to an IPsec

policy, this parameter does not
need to be set.
VLAN ID 1
VLANID1

need to be set.
VLAN ID 2
VLANID2

need to be set.
Table 10-8 lists the data to prepare for an IPsec proposal (the IPSECPROPOSAL MO in MML
configurations and the IPSECPROPOSAL or IPsec Proposal MO in CME configurations).
Table 10-8 Data to prepare for an IPsec proposal
Issue 02 (2013-07-30)
Parameter Name
Parameter ID
Setting Notes
Data Source
IPsec Proposal Name
PROPNAME
User-defined
Encapsulation Mode
ENCAPMODE
The tunnel mode is

recommended. The
parameter settings on
the base station and
SeGW sides must be
the same.
l Network plan
Transform
TRANMODE
The parameter
settings on thebase
station and SeGW
sides must be the
same.
AH Authentication
Algorithm
AHAUTHALG
The parameter
settings on the base
station and SeGW
sides must be the
same.

l Negotiation with
the IKE peer
54
SingleRAN
Parameter Name
Parameter ID
Setting Notes
ESP Authentication
Algorithm
ESPAUTHALG
The parameter
station and SeGW
sides must be the
same.
ESP Encryption
Algorithm
ESPENCALG
The parameter
station and SeGW
sides must be the
same.
Data Source
Table 10-9 lists the data to prepare for an IPsec policy (the IPSECPOLICY MO in MML
configurations and the IPSECPOLICY or IPsec Policy MO in CME configurations)
Table 10-9 Data to prepare for an IPsec policy
Issue 02 (2013-07-30)
Parameter Name
Parameter ID
Setting Notes
Data Source
Policy Group Name
SPGN
User-defined
IPsec Sequence No.
SPSN
ACL ID
ACLID
This parameter
specifies the binding
between an IPsec
policy and an ACL.
Only data flows that
comply with rules in
the ACL are processed
based on the IPsec
policy.
IPsec Proposal Name
PROPNAME
The value of this

parameter must be the
same as the value of
PROPNAME in the
IPSECPROPOSAL
MO.
IKE Peer Name
PEERNAME
The value of this

parameter must be the
PEERNAME in the
IKEPEER MO.

55
SingleRAN
Parameter Name
Parameter ID
Setting Notes
Data Source
Perfect Forward
Secrecy
PFS
The parameter settings

on the base station and
SeGW sides must be
the same.
l Network plan
SA Duration Mode
LTCFG
l If this parameter is
set to GLOBAL,
LTS and LTKB are
permanently set to
3600 and
69120000,
respectively.
Network plan
l Negotiation
with the IKE
peer
l If this parameter is
set to LOCAL, the
IPsec SA lifetime is
specified by LTS
and LTKB.
Lifetime Based On
Time(s)
LTS
This parameter must be

set when LTCFG is set
to LOCAL.
Lifetime Based On
Traffic(KB)
LTKB

set when LTCFG is set
to LOCAL.
Anti-Replay
Windows
REPLAYWND
If this parameter is set

to 0, the anti-replay
function does not take
effect. It is
recommended that the
anti-replay function be
disabled if a severe outof-order problem
occurs in IPsec packets
on live networks. If the
anti-replay function is
enabled in this
situation, a large
number of IPsec
packets may be lost,
which severely affects
service performance.
An IPsec policy takes effect only after it is bound to a port. Table 10-10 lists the data to prepare
for the binding between an IPsec policy and a port (the IPSECBIND MO in MML configurations
and the IPSECBIND or IPsec Policy Group Binding MO in CME configurations).
Issue 02 (2013-07-30)

56
SingleRAN
Table 10-10 Data to prepare for the binding between an IPsec policy and a port
Parameter Name
Parameter ID
Setting Notes
Data Source
Cabinet No.
CN
Network plan
Subrack No.
SRN
Slot No.
SN
Subboard Type
SBT
Port Type
PT
Port No.
PN
Policy Group Name
SPGN
If PT is set to
ETH, the port
specified by PN
cannot be a
member of an
Ethernet trunk.
The value of this
parameter must be
the same as the
value of SPGN in
the
IPSECPOLICY
MO.
User-defined
(Optional) Prepare data related to basic IKE configurations. Table 10-11 lists the data to prepare
for basic IKE configurations (the IKECFG MO in MML configurations and the IKECFG or
IKE Basic Configuration MO in CME configurations).
Table 10-11 Data to prepare for basic IKE configurations
Parameter Name
Parameter ID
Setting Notes
Data Source
Local Name
IKELNM
If AUTHMETH is set
to IKE_RSA_SIG, this
parameter does not
need to be set.
l Network plan
l Set this parameter if

IKEv1 entities
require the
keepalive function.
Network plan
Keepalive Interval
IKEKLI
l Negotiation with
the IKE peer
l If both IKEKLI and

IKEKLT are set to
0, the keepalive
function is disabled.
l The value of
IKEKLT must be
Issue 02 (2013-07-30)

57
SingleRAN
Parameter Name
Parameter ID
Keepalive Timeout
IKEKLT
Setting Notes
Data Source
greater than the

value of IKEKLI.
l IKEv2 does not
support the
keepalive function.
Therefore, IKEKLI
and IKEKLT do not
need to be set.
DSCP
DSCP
This parameter
specifies the
differentiated services
code point (DSCP) for
IKE negotiation
packets. The
recommended value of
this parameter is 48.
(Optional) Prepare data related to the IPsec replay alarm switch. Table 10-12 lists the data to
prepare for the switch (the IPGUARD MO in MML and CME configurations).
Table 10-12 Data to prepare for the IPsec replay alarm switch
Issue 02 (2013-07-30)
Parameter Name
Parameter ID
Setting Notes
Data
Source
IPsec Replay Alarm

Switch
IPSECREPLAY
CHKSW
If this parameter is set to

Enable, IPsec replay alarm
detection is enabled. In this case,
the anti-replay function must
also be enabled, that is,
REPLAYWND in the
IPSECPOLICY MO cannot be
set to WND_DISABLE(0).
Network
plan

58
SingleRAN
Parameter Name
Parameter ID
Setting Notes
Data
Source
IPsec Replay Alarm

Threshold
IPSECREPLAYALMTHD
If the number of IPsec replay

attack packets reaches the value
of this parameter, ALM-25950
Base Station Being Attacked is
reported and the value of the
alarm parameter "Specific
Problem" is IPsec Replay.
Network
plan
If a pair of primary and secondary IPsec tunnels are to be established, BFD detection must be
enabled to detect the connectivity of the primary and secondary IPsec tunnels. Table 10-13 lists
the data to prepare for BFD detection (the BFDSESSION MO in MML configurations and the
BFDSESSION or BFD Session MO in CME configurations).
Table 10-13 Data to prepare for BFD detection
Issue 02 (2013-07-30)
Parameter Name
Parameter ID
Setting Notes
Data Source
Cabinet No.
CN
User-defined
Subrack No.
SRN
Slot No.
SN
Session ID
BFDSN
Source IP
SRCIP
Network plan
Destination IP
DSTIP
If primary and secondary

IPsec tunnels are used,
BFD detection must be
enabled to detect the
connectivity of the
primary and secondary
IPsec tunnels. In BFD
sessions, SRCIP and
DSTIP are set to the IP
address for the IKE local
end and the IP address for
the IKE peer end,
respectively.
Hop Type
HT
Min TX Interval
(ms)
MINTI
Min RX Interval
(ms)
MINRI
Detection Multiplier
DM

59
SingleRAN
Parameter Name
Parameter ID
Session Catalog
CATLOG
DSCP
DSCP
Protocol Version
VER
Setting Notes
Data Source
Prepare data if a pair of primary and secondary IPsec tunnels are to be established. Table
10-14 lists the data to prepare for the primary and secondary IPsec tunnels (the IPSECDTNL
MO in MML configurations and the IPSECDTNL or IPsec Tunnel Pair MO in CME
configurations).
Table 10-14 Data to prepare for the primary and secondary IPsec tunnels
Parameter Name
Parameter ID
Setting Notes
Data Source
IPsec Dual Tunnel

ID
DUALID
User-defined
Master Policy
Group Name
MSPGN
Master IPsec
Sequence No.
MSPSN
Network plan
Slave Policy Group

Name
SSPGN
User-defined
Slave IPsec
Sequence No.
SSPSN
Network plan
Master Tunnel's
BFD Session ID
MBFDSN
Slave Tunnel's BFD

Session ID
SBFDSN
Initial Configuration
Using MML Commands
The procedure for configuring an IPsec tunnel is as follows:
Step 1 Run the ADD IKEPROPOSAL command to add an IKE proposal.
Step 2 Run the ADD IKEPEER command to add an IKE peer.
Step 3 Run the ADD ACL command to add an ACL.
Step 4 Run the ADD ACLRULE command to add a rule to the ACL.
Issue 02 (2013-07-30)

60
SingleRAN
Step 5 Run the ADD IPSECPROPOSAL command to add an IPsec proposal.

Step 6 Run the ADD IPSECPOLICY command to add an IPsec policy.
Step 7 Run the ADD IPSECBIND command to add the binding between the IPsec policy and a
transmission port.
Step 8 (Optional) Run the SET IKECFG command to set basic IKE information.
Step 9 (Optional) Run the SET IPGUARD command to set the IPsec replay alarm switch and threshold.
----End
The procedure for configuring a pair of primary and secondary IPsec tunnels is as follows:
Configure one IPsec tunnel according to the preceding operations in Step 1 through Step
7..Configure another IPsec tunnel by performing the following steps:
Step 1 Run the ADD IKEPEER command to add an IKE peer.
Step 2 Run the ADD IPSECPOLICY command to add an IPsec policy.
Step 3 Run the ADD IPSECBIND command to add the binding between the IPsec policy and a
transmission port.
Step 4 Run the ADD BFDSESSION command to add BFD sessions for the two IPsec tunnels.
Step 5 Run the ADD IPSECDTNL command to configure the two IPsec tunnels as a pair of primary
and secondary IPsec tunnels.
----End
MML Command Examples
The following is an example of configuring an IPsec tunnel:
//Adding an IKE proposal
ADD IKEPROPOSAL: PROPID=10, ENCALG=AES128, AUTHALG=SHA1, AUTHMETH=IKE_RSA_SIG,
DHGRP=DH_GROUP14, DURATION=86400;
//Adding an IKE peer
ADD IKEPEER: PEERNAME="ike", PROPID=10, IKEVERSION=IKE_V1, EXCHMODE=MAIN,
IDTYPE=IP, REMOTEIP="90.90.90.90", REMOTENAME="secgw", DPD=PERIODIC,
DPDIDLETIME=20, DPDRETRI=4, DPDRETRN=6, LOCALIP="20.20.20.188";
//Adding an ACL
ADD ACL: ACLID=3000, ACLDESC="for IPsec";
//Adding a rule to the ACL
ADD ACLRULE: ACLID=3000, RULEID=1, ACTION=PERMIT, PT=IP, SIP="33.33.33.188",
SWC="0.0.0.0", DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;
Issue 02 (2013-07-30)

61
SingleRAN
NOTE
In the preceding commands:

l Rule 1 applies to eNodeB signaling and service data flows.
l Rule 2 applies to eNodeB O&M data flows and certificate management-related data flows, including
those generated during the interaction with the certificate & CRL database.
These ACL rules are required when O&M data is protected by IPsec. When the preceding data flows pass
through a transmission port on the UMPT, the UMPT encrypts or decrypts them.
If O&M data is not protected by IPsec:
l SIP for any ACL rule cannot be set to the O&M IP address.
l For certificate management-related data flows, configure a new intranet IP address and use it as the
source IP address. For example, if the new intranet IP address is 45.45.45.45, set SIP to 45.45.45.45
for rule 2.
//Adding an IPsec proposal
ADD IPSECPROPOSAL: PROPNAME="prop0", ENCAPMODE=TUNNEL, TRANMODE=ESP,
ESPAUTHALG=SHA1,ESPENCALG=AES128;
//Adding an IPsec policy
ADD IPSECPOLICY: SPGN="Policy0", SPSN=1, ACLID=3000, PROPNAME="prop0",
PEERNAME="ike", PFS= DISABLE, LTCFG=LOCAL, LTS=86400, REPLAYWND=WND_DISABLE;
//Adding the binding between the IPsec policy and a transmission port
ADD IPSECBIND: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PT=ETH, PN=1, SPGN="Policy0";
//(Optional) Setting the IPsec replay alarm switch and threshold
SET IPGUARD: IPSECREPLAYCHKSW=ENABLE, IPSECREPLAYALMTHD=10;
The following is an example of configuring a pair of primary and secondary IPsec tunnels
(configure one IPsec tunnel by following the preceding MML command example and then
configure as follows):
//Adding the second IKE peer
ADD IKEPEER: PEERNAME="Ike2", PROPID=10, IKEVERSION=IKE_V1, EXCHMODE=MAIN,
IDTYPE=IP, REMOTEIP="80.80.80.80", REMOTENAME="Secgw2", DPD=PERIODIC,
//Adding the second IPsec policy when two ports are used
ADD IPSECPOLICY: SPGN="Policy1", SPSN=2, ACLID=3000, PROPNAME="prop0",
PEERNAME="Ike2", PFS= DISABLE, LTCFG=LOCAL, LTS=86400, REPLAYWND=WND_DISABLE;
NOTE
If one port is used, the two IPsec policies have the same group name but different numbers, and they are
bound to the same port at a time.
If two ports are used, the two IPsec policies have different group names but may
have the same number. The two IPsec policies are separately bound to the two
ports.
//Adding the binding between the second IPsec policy and a transmission port
ADD IPSECBIND: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PT=ETH, PN=0, SPGN="Policy1";
//Adding BFD sessions for the two IPsec tunnels
ADD BFDSESSION: CN=0, SRN=0, SN=7, BFDSN=1, SRCIP="20.20.20.188",
DSTIP="90.90.90.90", HT=MULTI_HOP, MINTI=100, MINRI=100, DM=3, CATLOG=RELIABILITY,
DSCP=0, VER=DRAFT4;
ADD BFDSESSION: CN=0, SRN=0, SN=7, BFDSN=2, SRCIP="21.21.21.188",
DSTIP="80.80.80.80", HT=MULTI_HOP, MINTI=100, MINRI=100, DM=3, CATLOG=RELIABILITY,
DSCP=0, VER=DRAFT4;
//Configuring the two IPsec tunnels as primary and secondary IPsec tunnels
ADD IPSECDTNL: DUALID=0, MSPGN="Policy0", MSPSN=1, SSPGN="Policy1", SSPSN=2,
MBFDSN=1, SBFDSN=2;
Using the CME to Perform Single Configuration

Set parameters on the CME configuration interface by referring to Data Preparation in Data
Preparation For instructions on how to perform the CME single configuration, see CME Single
Configuration Operation Guide.
Issue 02 (2013-07-30)

62
SingleRAN
Using the CME to Perform Batch Configuration for Newly Deployed Base Stations
Enter the values of the parameters listed in Table 10-15 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 10-15 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.
Some MOs in Table 10-15are not contained in a scenario-specific summary data file. In
this situation, customize a summary data file to include the MOs before you can set the
parameters.
Table 10-15 MOs related to the IPsec feature

MO
Sheet in the
Summary Data
File
Parameter Group
Remarks
IKEPROPOSAL
Common Data
l PROPID
l ENCALG
l AUTHALG
l AUTHMETH
l DHGRP
l PRFALG
l DURATION
IKEPEER
Common Data
l PEERNAME
l PROPID
l IKEVERSION
l EXCHMODE
l IDTYPE
l REMOTEIP
l REMOTENAME
l DPD
l DPDIDLETIME
l DPDRETRI
l DPDRETRN
Issue 02 (2013-07-30)

63
SingleRAN
MO
Sheet in the
Summary Data
File
Parameter Group
Remarks
IKEPEER
Base Station
Transport Data
l PKEY
PKEY and
LOCALIP are
unique for each
base station.
Therefore, it is
recommended
that these two
parameters be
customized on
the Base Station
Transport Data
sheet.
Common Data
l PROPNAME
IPSECPROPOSA
L
l LOCALIP
l ENCAPMODE
l TRANMODE
l AHAUTHALG
l ESPAUTHALG
l ESPENCALG
IPSECPOLICY
Common Data
l SPGN
l SPSN
l ACLID
l PROPNAME
l PEERNAME
l PFS
l LTCFG
l LTS
l LTKB
l REPLAYWND
IPSECBIND
Common Data
l CN
l SRN
l SN
l SBT
l PT
l PN
l SPGN
ACL
Common Data
l ACLID
l ACLDESC
Issue 02 (2013-07-30)

64
SingleRAN
MO
Sheet in the
Summary Data
File
Parameter Group
Remarks
ACLRULE
ACLPattern
l ACLID
l RULEID
l ACTION
l PT
l SIP
l DIP
l SWC
l DWC
l SMPT
l SOP
l SPT1
l SPT2
l DMPT
l DOP
l DPT1
l DPT2
l MDSCP
l DSCP
l MFRG
l VLANIDOP
l VLANID1
l VLANID2
IPGUARD
User-defined
l IPSECREPLAYCHK
SW
l IPSECREPLAYALMTHD
For instructions about performing batch configuration for each type of base station, see the
following sections in 3900 Series Base Station Initial Configuration Guide.
l
"Creating NodeBs in Batches"
" Creating eNodeBs in Batches"
"Creating Separate-MPT Multimode Base Stations in Batches"
"Creating Co-MPT Base Stations in Batches"(for an eGBTS or a co-MPT base station)
Using the CME to Perform Batch Configuration for Existing Base Stations
Issue 02 (2013-07-30)

65
SingleRAN
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 M2000
client, or choose Advanced > Customize Summary Data File from the main menu of a CME
client, to customize a summary data file for batch reconfiguration.
Step 2 Export the NE data stored on the CME into the customized summary data file.
l For co-MPT multimode base stations: Choose CME > SRAN Application > MBTS
Application > Export Data > Export Base Station Bulk Configuration Data from the
main menu of the M2000 client, or choose SRAN Application > MBTS Application >
Export Data > Export Base Station Bulk Configuration Data from the main menu of the
CME client.
l For separate-MPT GSM-involved multimode base stations or GO base stations: Choose
CME > GSM Application > Export Data > eGBTS Bulk Configuration Data from the
main menu of the M2000 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 M2000 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 M2000 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 10-15 and close the file.
Step 4 Import the summary data file into the CME.
Application > Import Base Station Bulk Configuration Data from the main menu of the
M2000 client, or choose SRAN Application > MBTS Application > Import Data > Import
CME > GSM Application > Import Data > Import eGBTS Bulk Configuration Data
from the main menu of the M2000 client, or choose GSM Application > Import Data >
Import eGBTS Bulk Configuration Data from the main menu of the CME client.
CME > UMTS Application > Import Data > Import Base Station Bulk Configuration
Data from the main menu of the M2000 client, or choose UMTS Application > Import
Data > Import Base Station Bulk Configuration Data from the main menu of the CME
client.
> LTE Application > Import Data > Import Base Station Bulk Configuration Data from
the main menu of the M2000 client, or choose LTE Application > Import Data > Import
----End
For details about how to import and export data, see the M2000 online help.
Issue 02 (2013-07-30)

66
SingleRAN
Activation Observation
Observing the IPsec Tunnel
Step 1 Run the DSP IKESA command to check the SA status.
As shown in the following figure, all SAs are successfully established when the command output
indicates both of the following:
l The status of SAs in the first and second phases is Ready StayAlive.
l The number of SAs in the second phase is the same as the number of ACL rules whose
ACTION is set to PERMIT.
Step 2 Run the DSP IPSECSA command to check the IPsec SA status.
The following is an example of the command output.
Step 3 Check whether services protected by the IPsec tunnel are normal.
l If service data is protected by IPsec, initiate a voice service and a data service and then check
whether the two services are running normally.
l If O&M data is protected by IPsec, observe whether the base station deployed with the IPsec
tunnel is online on the M2000 topology view.
Step 4 Check the IPsec replay status.
1.
Check whether ALM-25950 Base Station Being Attacked is reported with "Specific
Problem" set to IPsec Replay. If so, IPsec replay attacks exist.
2.
If IPsec replay attacks exist, run the DSP INVALIDPKTINFO command to query IPsec
replay packets.
Only the latest 100 invalid packets can be displayed in the command output and only the first
64 bytes of an invalid packet can be displayed in the value of the Invalid Packet Data parameter.
Issue 02 (2013-07-30)

67
SingleRAN
Step 5 Check the IKE- and IPsec-related performance counters.

On the main menu of the M2000, click
in the upper left corner, and then On the
Application Center tab page, double-click the Performance icon, choose Management >
Measurement Management . In the navigation tree of the displayed window, choose a base
station type, and choose Common > Measurement related to Transport > Measurement
related to IKE or Common > Measurement related to Transport > Measurement related
to IPsec under the type. Then, choose a specific base station deployed with the IPsec tunnel to
start monitoring its IKE or IPsec performance.
NOTE
eGBTSs, NodeBs, and eNodeBs support IKE and IPsec performance monitoring, whereas GBTSs do not.
The IKE-related performance counters are as follows:

l VS.IKE.RxPackets: number of received IKE packets
l VS.IKE.TxPackets: number of transmitted IKE packets
l VS.IKE.SubSARekey.Times: number of Re-key procedures performed by IPsec SAs.
l VS.IKE.DPDSessionFail.Times: number of failed DPD sessions
The IPsec-related counters are as follows:
l VS.IPsec.RxCheckReplayFailDropPkts: number of packets discarded due to anti-replay
protection at the receiver end
l VS.IPsec.RxAHCheckFailDropPkts: number of packets discarded due to failed AH
verification at the receiver end
l VS.IPsec.RxESPFailDropPkts: number of packets discarded due to failed ESP verification
and encryption at the receiver end
l VS.IPsec.RxDecryptACLFailDropPkts: number of discarded packets that should have not
been encrypted at the receiver end
l VS.IPsec.RxDecryptSuccessPkts: number of successfully decrypted packets at the receiver
end
l VS.IPsec.TxOutboundSAMissDropPkts: number of packets discarded due to the nonexistent
outbound SA at the transmitter end
Issue 02 (2013-07-30)

68
SingleRAN
l VS.IPsec.TxAntiReplaySnWrappedDropPkts: number of packets discarded due to the

overflow of sequence numbers at the transmitter end
l VS.IPsec.TxEncryptSuccessPkts: number of successfully encrypted packets at the
transmitter end
----End
Observing the Primary and Secondary IPsec Tunnels
Step 1 Run the DSP IPSECSA command to separately check the status of the primary and secondary
IPsec tunnels.
If data about the primary and secondary IPsec SAs is displayed in the command output, the
primary and secondary IPsec tunnels have been established successfully.
Step 2 Disable the primary IPsec tunnel and then check whether services are running normally.
1.
Remove the network cable to disable the primary IPsec tunnel.
2.
Run the DSP IPSECDTNL command to check whether the IPsec policy in use is the
standby IPsec SA.
3.
Initiate a voice service and a data service and then check whether the two services are
running normally.
4.
Observe whether the base station deployed with the primary and secondary IPsec tunnels
is online on the M2000 topology view.
----End
10.6.2 Deploying IPsec on a GBTS (GTMUb+UMPT_L)

On a PKI-based secure network, IPsec configurations are the same for a GBTS using GTMUb
+LMPT and a GBTS using GTMUb+UMPT_L. This section uses the network shown in Figure
10-8 as an example to describe how to deploy IPsec on a GBTS using GTMUb+UMPT_L on a
PKI-based secure network.
Issue 02 (2013-07-30)

69
SingleRAN
Figure 10-8 Example of deploying IPsec on a GBTS using GTMUb+UMPT_L on a PKI-based

secure network
In this networking scenario:

l
The GTMUb and UMPT_L communicate with each other through the BBU backplane.
All IPsec data on the UMPT_L is configured on the eNodeB.
The UMPT_L transfers GBTS data and provides IPsec for the following data flows:
GBTS signaling and service data flows.
Data flows generated when the eNodeB obtains CRLs or certificate files from the CRL
server.
Data Preparation
For details, see Data Preparation in section 10.6.1 Deploying IPsec on an eGBTS, NodeB,
or eNodeB.
For details, see Initial Configuration in section 10.6.1 Deploying IPsec on an eGBTS, NodeB,
or eNodeB. The following describes only the differences in initial configuration of a PKI-based
secure network between an eGBTS/NodeB/eNodeB and a GBTS using GTMUb+UMPT_L.
Using MML Commands
Run the ADD ACLRULE command as follows:
SWC="0.0.0.0", DIP="0.0.0.0, DWC="255.255.255.255", MDSCP=NO;
Issue 02 (2013-07-30)

70
SingleRAN
NOTE
l In the preceding commands:

l Rule 1 applies to GBTS signaling and service data flows.
These ACL rules are required when O&M data is protected by IPsec. When the preceding data flows
pass through a transmission port on the UMPT_L, the UMPT_L encrypts or decrypts them.
for rule 2.
For details, see Activation Observation in section 10.6.1 Deploying IPsec on an eGBTS,
NodeB, or eNodeB.When the IPsec feature is deployed on a GBTS using GTMUb+UMPT_L,
observe the online status of the GBTS and eNodeB.
10.6.3 Deploying IPsec on a GBTS (GTMUb+UTRPc)

This section uses the network shown in Figure 10-9 as an example to describe how to deploy
IPsec on a GBTS using GTMUb+UTRPc on a PKI-based secure network.
Figure 10-9 Example of deploying IPsec on a GBTS using GTMUb+UTRPc on a PKI-based
secure network

l
The GTMUb and UTRPc communicate with each other through the BBU backplane.
The UTRPc only provides IPsec for the following data flows because the GBTS has no
O&M channel:
Issue 02 (2013-07-30)

71
SingleRAN
GBTS signaling and service data flows.

Certificate management-related data flows between the GBTS and CA.
Data flows generated when the GBTS obtains CRLs or certificate files from the CRL
server.
Data Preparation
"-" in the following tables in this section indicates that there is no special requirement for setting
the parameters. Set the parameters based on site requirements.
Table 10-16 lists the data to prepare for an IKE proposal (the BTSIKEPROPOSAL MO in
MML configurations and the BTSIKEPROPOSAL or BTS IKE Proposal MO in CME
configurations).
Table 10-16 Data to prepare for an IKE proposal
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE
It is recommended that
the ID be used to identify
a GBTS.
Network plan
BTS Index
BTSID
BTS Name
BTSNAME
Proposal ID
PROPID
User-defined
Encryption
Algorithm
ENCALG

on the GBTS and SeGW
sides must be the same.
l Network plan
Authentication
Algorithm
AUTHALG

Authentication
Method
AUTHMETH
Set this parameter to

IKE_RSA_SIG if
digital certificates are
used for identity
authentication.
Diffie-Hellman
Group
DHGRP


l Negotiation
with the IPsec
peer
72
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
PRF Algorithm
PRFALG

set when
IKEVERSION in the
BTSIKEPEER MO is
set to IKE_V2.
Data Source

ISAKMP SA
Duration(s)
DURATION
Table 10-17 lists the data to prepare for an IKE peer (the BTSIKEPEER MO in MML
configurations and the BTSIKEPEER or BTS IKE Peer MO in CME configurations).
Table 10-17 Data to prepare for an IKE peer
Parameter
Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE
It is recommended that the ID

be used to identify a GBTS.
Network plan
BTS Index
BTSID
BTS Name
BTSNAME
IKE Peer Name
PEERNAME
IKE Proposal
ID
PROPID

must be the same as the value
of PROPID in the
BTSIKEPROPOSAL MO.
Version
IKEVERSION

GBTS and SeGW sides must be
the same.
Exchange
Mode
Issue 02 (2013-07-30)
EXCHMODE
Set this parameter when

IKEVERSION is set to IKEV1. The parameter settings on
the GBTS and SeGW sides
must be the same. The
parameter is MAIN.

User-defined
l Network
plan
l Negotiati
on with
the IPsec
peer
73
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
Local ID Type
IDTYPE
authentication is used, the
parameter is FQDN.
Remote IP
Address
REMOTEIP
BTSIPSECPROPOSAL
MO is set to
TRANSPORT, set this
parameter to a value same as
that of DIP in the
BTSACLRULE MO.
Otherwise, encrypted
packets cannot be
decrypted.
Data Source
Network plan
BTSIPSECPROPOSAL
MO is set to TUNNEL, set
this parameter to a value
same as the IP address of the
peer SeGW.
Remote Name
REMOTENAME
In the case of digital certificate

authentication:
l If this parameter is set, the
be the same as the value of
the subjectaltname field in
the device certificate used
by the SeGW.
l If this parameter is not set,
the base station does not
authenticate the identity of
the SeGW during IKE
negotiation.
Pre-shared Key
Issue 02 (2013-07-30)
PKEY
DPD Mode
DPD
DPD Idle Time

(s)
DPDIDLETIME
If digital certificates are used

for identity authentication, this
parameter does not need to be
set.
l Network
plan
DPD is enabled by default. Set

the DPD-related parameters to
same values at both IKE ends.
If the values are different, the
IKE end with a shorter timer
Network plan

l Negotiati
on with
the IPsec
peer
74
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
DPD
Retransmission
Interval(s)
DPDRETRI
DPD
Retransmission
Count
DPDRETRN
length will detect that the peer

is offline before the other IKE
end does, and an IKE
renegotiation will be triggered.
NAT Traversal
NATTRAV
The recommended value of this

parameter is Disable.
Local IP
Address
LOCALIP

local IP address for IKE
negotiation.
Data Source
l If there is only one device IP

address, the device IP
address is used by default
when this parameter is set to
the invalid value 0.0.0.0.
l If there are multiple device
IP addresses, set this
parameter to one of the IP
addresses that belongs to a
port bound with IPsec
policies.
If ENCAPMODEin the
IPSECPROPOSAL MO is
set to TRANSPORT, set
this parameter to a value
same as SIP in the
ACLRULE MO.
packets cannot be
decrypted.
Table 10-18 lists the data to prepare for an ACL (the BTSACL MO in MML configurations
and the BTSACL or BTS Access Control List MO in CME configurations).
Table 10-18 Data to prepare for an ACL
Issue 02 (2013-07-30)
Parameter Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE

Network plan
BTS Index
BTSID

75
SingleRAN
Parameter Name
Parameter ID
Setting Notes
BTS Name
BTSNAME
ACL ID
ACLID
At least one ACL rule must be

defined for each ACL.
Data Source
User-defined

policy, the value of this
parameter ranges from 3000 to
3999.
Table 10-19 lists the data to prepare for an ACL rule (the BTSACLRULE MO in MML
configurations and the BTSACLRULE or BTS Access Control List Rule MO in CME
configurations). Multiple ACL rules can be configured to protect different types of data flows.
How many ACL rules are configured depends on the network plan.
Table 10-19 Data to prepare for an ACL rule
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE

Network plan
BTS Index
BTSID
BTS Name
BTSNAME
Rule Type
RULETYPE
ACL ID
ACLID
Set this parameter to a value

same as that of ACLID in the
BTSACL MO.
Rule ID
RULEID
Each ACL rule in an ACL

must have a unique ID.

User-defined
76
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
Data Source
Action
ACTION
Set this parameter according

to the network plan. It can be
set to DENY or PERMIT.
Network plan
When an ACL rule in an ACL

is used to match packets:
l If a packet matches the
ACL rule, the base station
determines whether to
encrypt the packet by
IPsec based on the value
of this parameter.
l If a packet does not match
the ACL rule, the base
station does not encrypt
the packet, and tries the
next ACL rule until all
ACL rules in the ACL
have been tried.
The value of ACLID for
an ACL rule whose
ACTION is set to DENY
must be smaller than that
for an ACL rule whose
ACTION is set to
PERMIT.
Issue 02 (2013-07-30)
Protocol
Type
PT
Source IP
Address
SIP
If ENCAPMODE in the
BTSIPSECPROPOSAL
MO is set to TRANSPORT,
the value of this parameter
must be a configured device
IP address. Otherwise,
encrypted packets cannot be
decrypted.

77
SingleRAN
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Destination
IP Address
DIP
If ENCAPMODE in the
BTSIPSECPROPOSAL
MO is set to TRANSPORT,
the value of this parameter
must be a host IP address, not
a network segment address.
must be the same as that of
REMOTEIP in the
BTSIKEPEER MO.
packets cannot be decrypted.
Source
Wildcard
SWC

wildcard for a source IP
the subnet mask of the source
IP address.
Destination
Wildcard
DWC

wildcard for a destination IP
the subnet mask of the
destination IP address.
Match
Source Port
SMPT

cannot both be set to YES.
Source Port
Operate
SOP
Source Port 1
SPT1
Source Port 2
SPT2
Match
Destination
Port
DMPT

cannot both be set to YES.
Destination
Port Operate
DOP
Destination
Port 1
DPT1
Destination
Port 2
DPT2
Match DSCP
MDSCP

Data Source
78
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
Data Source
Match
Fragment
Message
MFRG
Set this parameter to NO if an

ACL is bound to an IPsec
policy.
VLAN ID
Filter
Criteria
VLANIDOP
If an ACL is bound to an
IPsec policy, this parameter
does not need to be set.
VLAN ID 1
VLANID1
VLAN ID 2
VLANID2
Table 10-20 lists the data to prepare for an IPsec proposal (the BTSIPSECPROPOSAL MO
in MML configurations and the BTSIPSECPROPOSAL or BTS IPsec Proposal MO in CME
configurations).
Table 10-20 Data to prepare for an IPsec proposal
Issue 02 (2013-07-30)
Parameter Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE
a GBTS.
Network plan
BTS Index
BTSID
BTS Name
BTSNAME
IPsec Proposal Name
PROPNAME
User-defined
Encapsulation Mode
ENCAPMODE
The tunnel mode is

recommended. The
parameter settings on the
GBTS and SeGW sides
must be the same.
l Network plan
Transform
TRANMODE

AH Authentication
Algorithm
AHAUTHALG


l Negotiation
with the IPsec
peer
79
SingleRAN
Parameter Name
Parameter ID
Setting Notes
ESP Authentication
Algorithm
ESPAUTHALG

ESP Encryption
Algorithm
ESPENCALG

Data Source
Table 10-21 lists the data to prepare for an IPsec policy (the BTSIPSECPOLICY MO in MML
configurations and the BTSIPSECPOLICY or BTS IPsec Policy MO in CME configurations).
Table 10-21 Data to prepare for an IPsec policy
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Data
Source
Index Type
IDTYPE

Network
plan
BTS Index
BTSID
BTS Name
BTSNAME
ACL ID
ACLID

binding between an IPsec
policy and an ACL. Only data
flows that comply with rules
in the ACL are processed
based on the IPsec policy.
IPsec Proposal
Name
PROPNAME

PROPNAME in the
BTSIPSECPROPOSAL
MO.
IKE Peer Name
PEERNAME

PEERNAME in the
BTSIKEPEER MO.
Policy Group
Name
SPGN
IPsec
Sequence No.
SPSN

User-defined
80
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
Data
Source
Perfect
Forward
Secrecy
PFS

GBTS and SeGW sides must
be the same.
l Network
plan
SA Duration
Mode
LTCFG
l If this parameter is set to

GLOBAL, LTS and are
permanently set to
and,respectively.
Network
plan
l Negotiati
on with
the IPsec
peer
l If this parameter is set to

LOCAL, the IPsec SA
lifetime is specified by
LTS and LTKB
Lifetime Based
On Time(s)
LTS
This parameter must be set

when LTCFG is set to
LOCAL.
Lifetime Based
On Traffic
(KB)
LTKB
This parameter must be set

when LTCFG is set to
LOCAL.
Anti-Replay
Windows
REPLAYWND
If this parameter is set to 0,

the anti-replay function does
not take effect.
It is recommended that the
anti-replay function be
disabled if a severe out-oforder problem occurs in IPsec
packets on live networks. If
the anti-replay function is
enabled in this situation, a
large number of IPsec
packets may be lost, which
severely affects service
performance.
An IPsec policy takes effect only after it is bound to a port.Table 10-22 lists the data to prepare
for the binding between an IPsec policy and a port (the BTSIPSECBIND MO in MML
configurations and the BTSIPSECBIND or BTS IPsec Policy Group Binding MO in CME
configurations).
Issue 02 (2013-07-30)

81
SingleRAN
Table 10-22 Data to prepare for the binding between an IPsec policy and a port
Parameter
Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE

ID be used to identify a
GBTS.
Network plan
BTS Index
BTSID
BTS Name
BTSNAME
Cabinet No.
CN
Subrack No.
SRN
Slot No.
SN
Port Type
PT
Port No.
PN
Policy Group
Name
SPGN
If PT is set to ETH, the port

specified by PN cannot be a
member of an Ethernet
trunk.
must be the same as the
value of SPGN in the
BTSIPSECPOLICY MO.
User-defined
(Optional) Prepare data related to the IPsec replay alarm switch.Table 10-23 lists the data to
prepare for the switch (the BTSIPGUARD MO in MML and CME configurations).
Table 10-23 Data to prepare for the IPsec replay alarm switch
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE

Network plan
BTS Index
BTSID
BTS Name
BTSNAME
IPsec Replay
Alarm Switch
IPSECREPLAYCHKSW
If this parameter is set to

Enable, IPsec replay alarm
detection is enabled. In this
case, REPLAYWND in the
BTSIPSECPOLICY MO
cannot be set to
WND_DISABLE(0).

82
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
Data Source
IPsec Replay
Alarm
Threshold
IPSECREPLAYALARMTHD
If the number of IPsec replay

attack packets reaches the
value of this parameter,
ALM-25950 Base Station
Being Attacked is reported
and the value of the alarm
parameter "Specific
Problem" is IPsec Replay.
(Optional) Prepare data related to basic IKE configurations.Table 10-24 lists the data to prepare
for basic IKE configurations (the BTSIKECFG MO in MML configurations and the
BTSIKECFG or BTS IKE Basic Configuration MO in CME configurations).
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE

Network plan
BTS Index
BTSID
BTS Name
BTSNAME
Local Name
IKELNM
If AUTHMETH in the
BTSIKEPROPOSAL MO
and IDTYPE in the
BTSIKEPEER MO are set to
IKE_RSA_SIG and FQDN,
respectively, this parameter
does not need to be set. This is
because the GBTS directly
uses the value of the
SubjectAltName field in its
digital certificate as the value
of this parameter.
l Network plan
Set this parameter if IKEv1

entities require the keepalive
function.
Network plan
Keepalive
Interval
IKEKLI
Keepalive
Timeout
IKEKLT
NAT Keepalive
Timeout
NATKLI
l Negotiation
with the IPsec
peer
If both IKEKLI and IKEKLT

are set to 0, the keepalive
function is disabled.
-

83
SingleRAN
Parameter
Name
Parameter ID
Setting Notes
DSCP
DSCP

DSCP for IKE negotiation
packets. The recommended
value of this parameter is 48.
Data Source
Table 10-25 lists the data to prepare for BFD detection (the BTSBFD MO in MML
configurations and the BTSBFD or BFD Sessions of BTS MO in CME configurations).
Table 10-25 Data to prepare for BFD detection
Issue 02 (2013-07-30)
Parameter Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE

ID be used to identify a
GBTS.
Network plan
BTS Index
BTSID
BTS Name
BTSNAME
Cabinet No.
CN
Subrack No.
SRN
Slot No.
SN
BFD Session No.
BFDSN
User-defined
Source IP Address
SRCIP
Network plan
Destination IP
Address
DSTIP
If primary and secondary

IPsec tunnels are used, BFD
detection must be enabled to
detect the connectivity of
the primary and secondary
IPsec tunnels. In BFD
sessions, SRCIP and
DSTIP are set to the IP
address for the IKE local
end and the IP address for
the IKE peer end,
respectively.
Hop Type
HT
Min TX Interval
MINTXINTERVAL
Min RX Interval
MINRXINTERVAL
Detection
Multiplier
DETECTMULT

84
SingleRAN
Parameter Name
Parameter ID
DSCP
DSCP
Setting Notes
Data Source
Prepare data if a pair of primary and secondary IPsec tunnels are to be established. Table
10-26 lists the data to prepare for the primary and secondary IPsec tunnels (the
BTSIPSECDTNL MO in MML configurations and the BTSIPSECDTNL or BTS IPsec
Tunnel Pair MO in CME configurations).
Table 10-26 Data to prepare for the primary and secondary IPsec tunnels
Parameter Name
Parameter ID
Setting Notes
Data Source
Index Type
IDTYPE
a GBTS.
Network plan
BTS Index
BTSID
BTS Name
BTSNAME
IPsec Dual Tunnel ID
DUALID
Master Policy Group

Name
MSPGN
Master IPsec Sequence

No.
MSPSN
Network plan
Slave Policy Group

Name
SSPGN
User-defined
Slave IPsec Sequence

No.
SSPSN
Network plan
BFD Session ID of
Master Tunnel
MBFDSN
BFD Session ID of
Slave Tunnel
SBFDSN
User-defined
Using MML Commands
The procedure for configuring an IPsec tunnel is as follows:
Step 1 Run the ADD BTSIKEPROPOSAL command to add an IKE proposal.
Step 2 Run the ADD BTSIKEPEER command to add an IKE peer.
Step 3 Run the ADD BTSACL command to add an ACL.
Issue 02 (2013-07-30)

85
SingleRAN
Step 4 Run the ADD BTSACLRULE command to add a rule to the ACL.
Step 5 Run the ADD BTSIPSECPROPOSAL command to add an IPsec proposal.
Step 6 Run the ADD BTSIPSECPOLICY command to add an IPsec policy.
Step 7 Run the ADD BTSIPSECBIND command to add the binding between the IPsec policy and a
transmission port.
Step 8 (Optional) Run the SET BTSIPGUARD command to set the IPsec replay alarm switch and
threshold.
----End
The procedure for configuring a pair of primary and secondary IPsec tunnels is as follows:
Configure one IPsec tunnel according to the preceding operations in Step 1 through Step
7.Configure another IPsec tunnel by performing the following steps:
Step 1 Run the ADD BTSIKEPEER command to add an IKE peer.
Step 2 Run the ADD BTSIPSECPOLICY command to add an IPsec policy.
Step 3 Run the ADD BTSIPSECBIND command to add the binding between the IPsec policy and a
transmission port.
Step 4 Run the ADD BTSBFDSESSION command to add BFD sessions for the two IPsec tunnels.
Step 5 Run the ADD BTSIPSECDTNL command to configure the two IPsec tunnels as a pair of
primary and secondary IPsec tunnels.
----End
The following is an example of configuring an IPsec tunnel:
//Adding an IKE proposal
ADD BTSIKEPROPOSAL: IDTYPE=BYID, BTSID=0, PROPID=10, ENCALG=3DES, AUTHALG=MD5,
AUTHMETH=IKE_RSA_SIG, DHGRP=DH_GROUP14, DURATION=86400;
//Adding an IKE peer
ADD BTSIKEPEER: IDTYPE=BYID, BTSID=0, PEERNAME="ike", PROPID=10,
IKEVERSION=IKE_V1, EXCHMODE=MAIN, IDTYPE=IP, REMOTEIP="90.90.90.90",
REMOTENAME="secgw", DPD=PERIODIC, DPDIDLETIME=20, DPDRETRI=4, DPDRETRN=6,
LOCALIP="20.20.20.188";
//Adding an ACL
ADD BTSACL: IDTYPE=BYID, BTSID=0, ACLID=3000, ACLDESC="For IPsec";
//Adding a rule to the ACL
ADD
BTSACLRULE:IDTYPE=BYID,BTSID=0,RULETYPE=ADV,ACLID=3000,RULEID=1,ACTION=PERMIT,
PT=IP,
SIP="35.35.35.188",SWC="0.0.0.0",DIP="0.0.0.0",DWC="255.255.255.255",MDSCP=NO;
ADD
BTSACLRULE:IDTYPE=BYID,BTSID=0,RULETYPE=ADV,ACLID=3000,RULEID=2,ACTION=PERMIT,
PT=IP,
SIP="35.35.35.188",SWC="0.0.0.0",DIP="0.0.0.0",DWC="255.255.255.255",MDSCP=NO;
NOTE

l Rule 2 applies to certificate management-related data flows on the UTRPc, including those generated
during the interaction between the GBTS and certificate & CRL database.
When the preceding data flows pass through a transmission port on the UTRPc, the UTRPc encrypts or
decrypts them.
Issue 02 (2013-07-30)

86
SingleRAN
//Adding an IPsec proposal

ADD BTSIPSECPROPOSAL: IDTYPE=BYID, BTSID=0, PROPNAME="prop0", ENCAPMODE=TUNNEL,
TRANMODE=ESP, ESPAUTHALG=MD5,ESPENCALG=DES;
//Adding an IPIPsecolicy
ADD BTSIPSECPOLICY: IDTYPE=BYID, BTSID=0, SPGN="Policy0", SPSN=1, ACLID=3000,
PROPNAME="prop0", PEERNAME="ike", LTCFG=LOCAL, LTS=86400, REPLAYWND=WND_DISABLE;
//Adding the binding between the IPsec policy and a transmission port
ADD BTSIPSECBIND: IDTYPE=BYID, BTSID=0, CN=0, SRN=0, SN=4, PT=ETH, PN=1,
SPGN="Policy0";
//(Optional) Setting the IPsec replay alarm switch and threshold
SET BTSIPGUARD: IDTYPE=BYID, BTSID=0,IPSECREPLAYCHKSW=ENABLE,
IPSECREPLAYALMTHD=10;
The following is an example of configuring a pair of primary and secondary IPsec tunnels
(configure one IPsec tunnel by following the preceding MML command example and then
configure as follows):
//Adding the second IKE peer
ADD BTSIKEPEER: IDTYPE=BYID, BTSID=0,PEERNAME="Ike2", PROPID=10,
IKEVERSION=IKE_V1, EXCHMODE=MAIN, IDTYPE=IP, REMOTEIP="80.80.80.80",
REMOTENAME="Secgw2", DPD=PERIODIC, DPDIDLETIME=20, DPDRETRI=4, DPDRETRN=6,
LOCALIP="21.21.21.188";
//Adding the second IPsec policy when two ports are used ADD BTSIPSECPOLICY:
IDTYPE=BYID, BTSID=0, SPGN="Policy1", SPSN=2, ACLID=3000, PROPNAME="prop0",
PEERNAME="Ike2", PFS= DISABLE, LTCFG=LOCAL, LTS=86400, REPLAYWND=WND_DISABLE;
NOTE
l If one port is used, the two IPsec policies have the same group name but different numbers, and they
are bound to the same port at a time.
l If two ports are used, the two IPsec policies have different group names but may have the same number.
The two IPsec policies are separately bound to the two ports.
//Adding the binding between the second IPsec policy and a transmission port
ADD BTSIPSECBIND: IDTYPE=BYID, BTSID=0, CN=0, SRN=0, SN=4, SBT=BASE_BOARD, PT=ETH,
PN=0, SPGN="Policy1";
//Adding BFD sessions for the two IPsec tunnels
ADD BTSBFDSESSION: IDTYPE=BYID, BTSID=0,CN=0, SRN=0, SN=4, BFDSN=1,
SRCIP="20.20.20.188", DSTIP="90.90.90.90", HT=MULTI_HOP, MINTI=100, MINRI=100,
DM=3, CATLOG=RELIABILITY, DSCP=0, VER=DRAFT4;
ADD BTSBFDSESSION: IDTYPE=BYID, BTSID=0,CN=0, SRN=0, SN=4, BFDSN=2,
SRCIP="21.21.21.188", DSTIP="80.80.80.80", HT=MULTI_HOP, MINTI=100, MINRI=100,
DM=3, CATLOG=RELIABILITY, DSCP=0, VER=DRAFT4;
//Configuring the two IPsec tunnels as primary and secondary IPsec tunnels
ADD BTSIPSECDTNL: IDTYPE=BYID, BTSID=0,DUALID=0, MSPGN="Policy0", MSPSN=1,
SSPGN="Policy1", SSPSN=2, MBFDSN=1, SBFDSN=2;
Using the CME to Perform Single Configuration

Set parameters on the CME configuration interface by referring to Data Preparation in section
10.6.3 Deploying IPsec on a GBTS (GTMUb+UTRPc). 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 10-27 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
Issue 02 (2013-07-30)
The MOs in Table Table 10-27 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.
87
SingleRAN
Some MOs in Table 10-27 are not contained in a scenario-specific summary data file. In
this situation, customize a summary data file to include the MOs before you can set the
parameters.
Table 10-27 MOs related to the IPsec feature

MO
Sheet in the
Summary
Data File
Parameter Group
Remarks
BTSIKEPROPOSAL
BTS Transport
Layer
l PROPID
l ENCALG
l AUTHALG
l AUTHMETH
l DHGRP
l PRFALG
l DURATION
BTSIKEPEER
l PEERNAME
l PROPID
l IKEVERSION
l EXCHMODE
l IDTYPE
l REMOTEIP
l REMOTENAME
l DPD
l DPDIDLETIME
l DPDRETRI
l DPDRETRN
BTSIKEPEER
BTSIPSECPROPOS
AL
BTS Transport
Layer
l PKEY
BTS Transport
Layer
l PROPNAME
l LOCALIP
-
l ENCAPMODE
l TRANMODE
l AHAUTHALG
l ESPAUTHALG
l ESPENCALG
Issue 02 (2013-07-30)

88
SingleRAN
MO
Sheet in the
Summary
Data File
Parameter Group
Remarks
BTSIPSECPOLICY
BTS Transport
Layer
l SPGN
l SPSN
l ACLID
l PROPNAME
l PEERNAME
l PFS
l LTCFG
l LTS
l LTKB
l REPLAYWND
BTSIPSECBIND
BTS Transport
Layer
l CN
l SRN
l SN
l SBT
l PT
l PN
l SPGN
BTSACL
Issue 02 (2013-07-30)
BTS Transport
Layer
l ACLID
l ACLDESC

89
SingleRAN
MO
Sheet in the
Summary
Data File
Parameter Group
Remarks
BTSACLRULE
BTS Transport
Layer
l ACLID
l RULEID
l ACTION
l PT
l SIP
l DIP
l SWC
l DWC
l SMPT
l SOP
l SPT1
l SPT2
l DMPT
l DOP
l DPT1
l DPT2
l MDSCP
l DSCP
l MFRG
l VLANIDOP
l VLANID1
l VLANID2
BTSIPGUARD
Common Data
l IPSECREPLAYCHKSW
l IPSECREPLAYALARMTHD
For the batch configuration of GBTSs, see the section "Creating GBTSs in Batches"section in
3900 Series Base Station Initial Configuration Guide.
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 eNodeBs in a single procedure. The procedure is as follows:
Step 1 Choose CME > Advanced > Customize Summary Data File from the main menu of an M2000
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.
Issue 02 (2013-07-30)

90
SingleRAN
Step 2 Export the NE data stored on the CME into the customized summary data file.
Application > Export Data > Export Base Station Bulk Configuration Data from the
main menu of the M2000 client, or choose SRAN Application > MBTS Application >
Export Data > Export Base Station Bulk Configuration Data from the main menu of the
CME client.
CME > GSM Application > Export Data > eGBTS Bulk Configuration Data from the
main menu of the M2000 client, or choose GSM Application > Export Data > Export
eGBTS Bulk Configuration Data from the main menu of the CME client.
CME > UMTS Application > Export Data > Export Base Station Bulk Configuration
Data from the main menu of the M2000 client, or choose UMTS Application > Export
Data > Export Base Station Bulk Configuration Data from the main menu of the CME
client.
> LTE Application > Export Data > Export Base Station Bulk Configuration Data from
the main menu of the M2000 client, or choose LTE Application > Export Data > Export
Step 3 In the summary data file, set the parameters in the MOs listed in Table 10-27 and close the file.
Step 4 Import the summary data file into the CME.
Application > Import Base Station Bulk Configuration Data from the main menu of the
M2000 client, or choose SRAN Application > MBTS Application > Import Data > Import
CME > GSM Application > Import Data > Import eGBTS Bulk Configuration Data
from the main menu of the M2000 client, or choose GSM Application > Import Data >
Import eGBTS Bulk Configuration Data from the main menu of the CME client.
CME > UMTS Application > Import Data > Import Base Station Bulk Configuration
Data from the main menu of the M2000 client, or choose UMTS Application > Import
Data > Import Base Station Bulk Configuration Data from the main menu of the CME
client.
> LTE Application > Import Data > Import Base Station Bulk Configuration Data from
the main menu of the M2000 client, or choose LTE Application > Import Data > Import
For details about how to import and export data, see the M2000 online help.
----End
Observing the IPsec Tunnel
Step 1 Run the DSP BTSIKESA command to check the SA status.
Issue 02 (2013-07-30)

91
SingleRAN
Step 2 Run the DSP BTSIPSECSA command to check the IPsec SA status.
Step 3 Check whether services protected by the IPsec tunnel are normal.
l If voice services are protected by IPsec, initiate a voice service and check whether the service
is running normally.
l If management packets are protected by IPsec, observe whether the GBTS deployed with the
IPsec tunnel is online on the M2000 topology view.
Step 4 Check the IPsec replay status.
1.
Check whether ALM-25950 Base Station Being Attacked is reported with "Specific
Problem" set to IPsec Replay. If so, IPsec replay attacks exist.
2.
If IPsec replay attacks exist, run the DSP BTSINVALIDPKTINFO command to query
IPsec replay packets.
Only the latest 100 invalid packets can be displayed in the command output and only the
first 64 bytes of an invalid packet can be displayed in the value of the Invalid Packet
Dataparameter. The following is an example of the command output.
Issue 02 (2013-07-30)

92
SingleRAN
----End
Observing the Primary and Secondary IPsec Tunnels
Step 1 Run the DSP BTSIPSECSA command to separately check the status of the primary and
secondary IPsec tunnels.
If data about the primary and secondary IPsec SAs is displayed in the command output, the
primary and secondary IPsec tunnels have been established successfully.
Step 2 Disable the primary IPsec tunnel and then check whether services are running normally.
1.
Remove the network cable to disable the primary IPsec tunnel.
2.
Run the DSP BTSIPSECDTNL command to check whether the IPsec policy in use is the
standby IPsec SA.
3.
Initiate a voice service and a data service and then check whether the two services are
running normally.
4.
Observe whether the base station deployed with the primary and secondary IPsec tunnels
is online on the M2000 topology view.
----End
10.6.4 Deploying Co-IPsec on a GL Dual-Mode Base Station

(UMPT_GL/GTMUb+UMPT_L)
co-IPsec on a GL dual-mode base station on a PKI-based secure network.
Issue 02 (2013-07-30)

93
SingleRAN
Figure 10-10 Example of deploying co-IPsec on a GL dual-mode base station on a PKI-based

secure network
On the co-MPT GL dual-mode base station, the UMPT_GL provides IPsec for the following
data flows:
l
eGBTS/eNodeB signaling and service data flows.
O&M data flows.
Certificate management-related data flows between the GL dual-mode base station and CA.
Data flows generated when the GL dual-mode base station obtains CRLs from the CRL
server.
On the separate-MPT GL dual-mode base station:

l
The GTMUb and UMPT_L communicate with each other through the BBU backplane.
The UMPT_L transfers GBTS data and provides IPsec for the following data flows:
GBTS/eNodeB signaling and service data flows.
Data flows generated when the eNodeB obtains CRLs from the CRL server.
Issue 02 (2013-07-30)

94
SingleRAN
NOTE
If an IPsec network with an eNodeB using UMPT_L is evolved into a co-IPsec network with a GL dualmode base station using UMPT_GL:
l Do not modify IPsec configurations if an existing ACL rule applies to eGBTS signaling and service
data flows, that is, an ACL rule in Any to Any mode whose ACTION is set to PERMIT has been
configured.
l Add an ACL rule whose ACTION is set to PERMIT for eGBTS signaling and service data flows if
existing ACL rules do not apply to these data flows.
If an IPsec network with an eNodeB using UMPT_L is evolved into a co-IPsec network with a GL dualmode base station using GTMUb+UMPT_L:
l Do not modify IPsec configurations if an existing ACL rule applies to GBTS signaling and service data
flows, that is, an ACL rule in Any to Any mode whose ACTION is set to PERMIT has been configured.
l Add an ACL rule whose ACTION is set to PERMIT for GBTS signaling and service data flows if
Data Preparation
or eNodeB.
secure network between an eGBTS/NodeB/eNodeB and a GL dual-mode base station.
Using MML Commands
On the co-MPT GL dual-mode base station using UMPT_GL, run the ADD ACLRULE
command as follows:
NOTE

l Rule 1 applies to eGBTS signaling and service data flows.
l Rule 3 applies to O&M data flows and certificate management-related data flows on the GL dual-mode
base station, including those generated during the interaction with the certificate & CRL database.
through a transmission port on the UMPT, the UMPT encrypts or decrypts them.
for rule 3.
On the separate-MPT GL dual-mode base station using GTMUb+UMPT_L, run the ADD
ACLRULE command as follows:
Issue 02 (2013-07-30)

95
SingleRAN

NOTE
l In the preceding commands:

through a transmission port on the UMPT_L, the UMPT_L encrypts or decrypts them.
for rule 3.
NodeB, or eNodeB. When co-IPsec is implemented on a GL dual-mode base station, observe
the status of GSM and LTE services and the online status of the GBTS/eGBTS and eNodeB.
10.6.5 Deploying Co-IPsec on a GU Dual-Mode Base Station

(UMPT_GU/GTMUb+UMPT_U)
co-IPsec on a GU dual-mode base station on a PKI-based secure network.
Issue 02 (2013-07-30)

96
SingleRAN
Figure 10-11 Example of deploying co-IPsec on a GU dual-mode base station on a PKI-based

secure network
On the co-MPT GU dual-mode base station, the UMPT_GU provides IPsec for the following
data flows:
l
eGBTS/NodeB signaling and service data flows.
O&M data flows.
Certificate management-related data flows between the GU dual-mode base station and
CA.
Data flows generated when the GU dual-mode base station obtains CRLs from the CRL
server.
On the separate-MPT GU dual-mode base station:

l
The GTMUb and UMPT_U communicate with each other through the BBU backplane.
The UMPT_U transfers GBTS data and provides IPsec for the following data flows:
GBTS/NodeB signaling and service data flows.
NodeB O&M data flows.
Certificate management-related data flows between the NodeB and CA.
Data flows generated when the NodeB obtains CRLs from the CRL server.
Issue 02 (2013-07-30)

97
SingleRAN
NOTE
If an IPsec network with a NodeB using UMPT_U is evolved into a co-IPsec network with a GU dualmode base station using UMPT_GU:
l Do not modify IPsec configurations if an existing ACL rule applies to eGBTS signaling and service
configured.
l Add an ACL rule whose ACTION is set to PERMIT for eGBTS signaling and service data flows if
If an IPsec network with a NodeB using UMPT_U is evolved into a co-IPsec network with a GU dualmode base station using GTMUb+UMPT_U:
l Do not modify IPSec configurations if an existing ACL rule applies to GBTS signaling and service
configured.
l Add an ACL rule whose ACTION is set to PERMIT for GBTS signaling and service data flows if
Data Preparation
or eNodeB.
secure network between an eGBTS/NodeB/eNodeB and a GU dual-mode base station.
Using MML Commands
On the co-MPT GU dual-mode base station using UMPT_GU, run the ADD ACLRULE
command as follows:
ADD ACLRULE: ACLID=3000, RULEID=1, PT=IP, SIP="35.35.35.188", SWC="0.0.0.0",
DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;
DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;
DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;
NOTE

l Rule 2 applies to NodeB signaling and service data flows.
l Rule 3 applies to O&M data flows and certificate management-related data flows on the GU dual-mode
pass through a transmission port on the UMPT, the UMPT encrypts or decrypts them.
for rule 3.
On the separate-MPT GU dual-mode base station using GTMUb+UMPT_U, run the ADD
Issue 02 (2013-07-30)

98
SingleRAN

DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;
DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;
DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;
NOTE

l Rule 3 applies to O&M data flows and certificate management-related data flows on the GU dual-mode
for rule 3.
NodeB, or eNodeB. When co-IPsec is implemented on a GU dual-mode base station, observe
the status of GSM and UMTS services and the online status of the GBTS/eGBTS and NodeB.
10.6.6 Deploying Co-IPsec on a UL Dual-Mode Base Station

(UMPT_UL/UMPT_U+UMPT_L)
co-IPsec on a UL dual-mode base station on a PKI-based secure network.
Figure 10-12 Example of deploying co-IPsec on a UL dual-mode base station on a PKI-based
secure network
Issue 02 (2013-07-30)

99
SingleRAN
On the co-MPT UL dual-mode base station, the UMPT_UL provides IPsec for the following
data flows:
l
NodeB/eNodeB signaling and service data flows.
O&M data flows.
Certificate management-related data flows between the UL dual-mode base station and CA.
Data flows generated when the UL dual-mode base station obtains CRLs from the CRL
server.
On the separate-MPT UL dual-mode base station:

l
The UMPT_U and UMPT_L communicate with each other through the BBU backplane.
The UMPT_L transfers NodeB data and provides IPsec for the following data flows:
NodeB/eNodeB signaling and service data flows.
NodeB/eNodeB O&M data flows.
NOTE
If an IPsec network with an eNodeB using UMPT_L is evolved into a co-IPsec network with a UL dualmode base station using UMPT_UL:
l Do not modify IPsec configurations if an existing ACL rule applies to NodeB signaling and service
configured.
l Add an ACL rule whose ACTION is set to PERMIT for NodeB signaling and service data flows if
If an IPsec network with an eNodeB using UMPT_L is evolved into a co-IPsec network with a UL
dual-mode base station using UMPT_U+UMPT_L:
l If an existing ACL rule applies to NodeB signaling and service data flows (that is, an ACL rule in Any
to Any mode whose ACTION is set to PERMIT has been configured):
- Do not modify IPsec configurations when O&M data is protected by IPsec.
- Add an ACL rule whose ACTION is set to DEDY for NodeB O&M data flows when O&M data is
not protected by IPsec. ACLID for this ACL rule must be smaller than that for any ACL rule in Any
to Any mode.
l If existing ACL rules do not apply to NodeB signaling, service, and O&M data flows, add an ACL rule
whose ACTION is set to PERMIT for these data flows.
Data Preparation
or eNodeB.
secure network between an eGBTS/NodeB/eNodeB and a UL dual-mode base station.
Using MML Commands
Issue 02 (2013-07-30)

100
SingleRAN
On the co-MPT UL dual-mode base station using UMPT_UL, run the ADD ACLRULE
command as follows:
NOTE

l Rule 3 applies to O&M data flows and certificate management-related data flows on the UL dual-mode
for rule 3.
On the separate-MPT UL dual-mode base station using UMPT_U+UMPT_L, run the ADD
NOTE

l Rule 3 applies to NodeB O&M data flows.
l Rule 3 does not need to be configured.
for rule 4.
Issue 02 (2013-07-30)

101
SingleRAN
NodeB, or eNodeB. When co-IPsec is implemented on a UL dual-mode base station, observe
the status of UMTS and LTE services and the online status of the NodeB and eNodeB.
10.6.7 Deploying Co-IPsec on a GUL Multimode Base Station

(UMPT_GUL)
co-IPsec on a GUL multimode base station on a PKI-based secure network.
Figure 10-13 Example of deploying co-IPsec on a GUL multimode base station on a PKI-based
secure network
In this networking scenario, the UMPT_GUL provides IPsec for the following data flows:
l
eGBTS/NodeB/eNodeB signaling and service data flows.
O&M data flows on the GUL multimode base station.
Certificate management-related data flows between the GUL multimode base station and
CA.
Data flows generated when the GUL multimode base station obtains CRLs from the CRL
server.
Issue 02 (2013-07-30)

102
SingleRAN
NOTE
If an IPsec network with an eNodeB using UMPT_L is evolved into a co-IPsec network with a GUL
multimode base station using UMPT_GUL:
l Do not modify IPsec configurations if an existing ACL rule applies to eGBTS and NodeB signaling
and service data flows, that is, an ACL rule in Any to Any mode whose ACTION is set to PERMIT.
l Add an ACL rule whose ACTION is set to PERMIT for eGBTS and NodeB signaling and service
data flows data flows if existing ACL rules do not apply to these data flows.
Data Preparation
or eNodeB.
secure network between an eGBTS/NodeB/eNodeB and a GUL multimode base station.
Using MML Commands
SWC="0.0.0.0", DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;ADD ACLRULE:
ACLID=3000, RULEID=2, ACTION=PERMIT, PT=IP, SIP="32.32.32.1", SWC="0.0.0.0",
DIP="0.0.0.0", DWC="255.255.255.255", MDSCP=NO;
NOTE

l Rule 4 applies to O&M data flows and certificate management-related data flows on the GUL
multimode base station, including those generated during the interaction with the certificate & CRL
database.
for rule 4.
NodeB, or eNodeB. When co-IPsec is implemented on a GUL multimode base station, observe
the status of GSM, UMTS, and LTE services and the online status of the eGBTS, NodeB, and
eNodeB.
Issue 02 (2013-07-30)

103
SingleRAN

(UMPT_L+GTMUb+UCIU in the Root BBU and UMPT_U in the
Leaf BBU)
secure network

l
In the root BBU, the GTMUb and UCIU communicate with the UMPT_L through the BBU
backplane.
The root and leaf BBUs are interconnected by connecting the UCIU and UMPT_U.
The UMPT_L provides IPsec for the following data flows:

GBTS/NodeB/eNodeB signaling and service data flows.
Issue 02 (2013-07-30)

104
SingleRAN
NOTE
If an IPsec network with an eNodeB using UMPT_L is evolved into a co-IPsec network with a GUL
multimode base station (UMPT_L+GTMUb+UCIU in the root BBU and UMPT_U in the leaf BBU):
l If an existing ACL rule applies to eGBTS/NodeB signaling and service data flows and NodeB O&M
data flows (that is, an ACL rule in Any to Any mode whose ACTION is set to PERMIT has been
configured):
- Do not modify IPsec configurations when O&M data is protected by IPsec.
- Add an ACL rule whose ACTION is set to DEDY for NodeB O&M data flows when O&M data is
to Any mode.
l If existing ACL rules do not apply to these data flows, add ACL rules whose ACTION is set to PERMIT
for eGBTS/NodeB signaling and service data flows and for NodeB O&M data flows.
Data Preparation
or eNodeB.
Using MML Commands
Issue 02 (2013-07-30)

105
SingleRAN
NOTE

l Rule 4 applies to NodeB O&M data flows.
for rule 5.
the status of GSM, UMTS, and LTE services and the online status of the GBTS, NodeB, and
eNodeB.

(UMPT_U+GTMUb+UCIU in the Root BBU and UMPT_L in the
Leaf BBU)
Issue 02 (2013-07-30)

106
SingleRAN
secure network

l
In the root BBU, the GTMUb and UCIU communicate with the UMPT_U through the BBU
backplane.
The root and leaf BBUs are interconnected by connecting the UCIU and UMPT_L.
The UMPT_U provides IPsec for the following data flows:

GBTS/NodeB/eNodeB signaling and service data flows.
Certificate management-related data flows between the NodeB and CA.
Data flows generated when the NodeB obtains CRLs from the CRL server.
NOTE
If an IPsec network with a NodeB using UMPT_U is evolved into a co-IPsec network with a GUL
multimode base station (UMPT_U+GTMUb+UCIU in the root BBU and UMPT_L in the leaf BBU):
l If an existing ACL rule applies to eGBTS/eNodeB signaling and service data flows and eNodeB O&M
data flows (that is, an ACL rule in Any to Any mode whose ACTION is set to PERMIT has been
configured):
l Do not modify IPsec configurations when O&M data is protected by IPsec.
Add an ACL rule whose ACTION is set to DEDY for eNodeB O&M data flows when O&M data is
to Any mode.
l If existing ACL rules do not apply to eGBTS/eNodeB signaling and service data flows and eNodeB
O&M data flows, add ACL rules whose ACTION is set to PERMIT for these data flows.
Data Preparation
or eNodeB.
Issue 02 (2013-07-30)

107
SingleRAN
Using MML Commands
NOTE

l Rule 4 applies to eNodeB O&M data flows.
l Rule 5 applies to NodeB O&M data flows and certificate management-related data flows, including
for rule 5.
the status of GSM, UMTS, and LTE services and the online status of the GBTS, NodeB, and
eNodeB.
10.7 Deployment of IPsec on a PSK-based Secure Network

On PSK-based secure networks, a PKI system does not need to be deployed.
IPsec configurations on a PSK-based secure network differ from those on a PKI-based secure
network in the following ways:
l
Issue 02 (2013-07-30)
AUTHMETH in the IKEPROPOSAL MO must be set to PRE_SHARED_KEY.

108
SingleRAN
REMOTENAME in the IKEPEER MO must be set to the same value as Local Name in
the IKE MO on the SeGW. PKEY must be set and its settings on the local and peer ends
must be the same.
In the IKEPEER MO, if IKEVERSION and EXCHMODE are set to IKE_V1 and
MAIN, respectively, IDTYPE must be set to IP.
If IKEVERSION and IDTYPE in the IKEPEER MO are set to IKE_V2 and FQDN,
respectively, IKELNM in the IKECFG MO must be set, and the value of IKELNM must
be the same as the value of Remote Name in the IKE MO on the SeGW.
In the ACLRULE MO, ACL rules do not need to be configured for certificate managementrelated data flows and CRL-related data flows.
The following uses the network shown in Figure 10-16 as an example to describe how to deploy
IPsec on an eNodeB on a PSK-based secure network. IPsec configurations in other scenarios
are similar and are not described in this document.
Figure 10-16 Example of deploying IPsec on an eNodeB on a PSK-based secure network
10.7.1 Data Preparation

or eNodeB.The following describes only the differences in parameter settings between the PKIand PSK-based secure networks:
l
Data to prepare for an IKE proposal

Table 10-28 Different data to prepare for an IKE proposal
Issue 02 (2013-07-30)
Parameter
Name
Parameter ID
Setting Notes
Data Source
Authentication
Method
AUTHMETH
Set this parameter to

PRE_SHARED_KEY
if PSK authentication is
used.
l Network plan

l Negotiation
with the IKE
peer
109
SingleRAN
Data to prepare for an IKE peer

Table 10-29 Different data to prepare for an IKE peer
Parameter
Name
Parameter ID
Setting Notes
Data Source
Local ID Type
IDTYPE
If PSK authentication
is used and if
IKEVERSION and
EXCHMODE are set
to IKE_V1 and
MAIN, respectively,
set this parameter to
IP.
l Network plan
Remote Name
REMOTENAME
is used, set this
parameter to a value
same as the IKE local
name configured at the
SeGW.
Pre-shared
Key
PKEY
is used, set this
parameter to a value
same as that of the IKE
peer.
l Negotiation
with the IKE
peer
Data to prepare for basic IKE configurations

If PSK authentication is used and IDTYPE is set to FQDN, engineering personnel also
need to configure the IKE local name and prepare data related to basic IKE configurations
described in Table 10-30 .
Parameter
Name
Parameter ID
Setting Notes
Data Source
Local Name
IKELNM
Set this parameter when Network plan

AUTHMETH
and IDTYPE are set to
PRE_SHARED_KEY
and FQDN, respectively.
Set this parameter to a
value same as the IKE
peer name configured at
the SeGW.
Issue 02 (2013-07-30)

110
SingleRAN
10.7.2 Initial Configuration

or eNodeB. The following describes only the differences in initial configuration between the
PKI- and PSK-based secure networks.
Using MML Commands

The following describes the differences in steps for initially configuring an IPsec tunnel.
Step 1 Before running the ADD IKEPROPOSAL command, run the SET IKECFG command to set
local IKE configurations.
Step 2 In the ADD IKEPROPOSAL command, set AUTHMETH to PRE-SHARED-KEY.
Step 3 In the ADD IKEPEER command, specify PKEY.
Step 4 In the ADD ACLRULE command, remove ACL rules for the following data flows:
----End
l
Certificate management-related data flows between the eNodeB and CA
Data flows generated when the eNodeB obtains CRLs form the CRL server

The following lists the differences in MML command examples of initially configuring an IPsec
tunnel.
SET IKECFG: IKELNM="IKECFG1", IKEKLI=0, IKEKLT=0, DSCP=48;
ADD IKEPROPOSAL: PROPID=10, ENCALG=3DES, AUTHALG=MD5, AUTHMETH=PRE-SHARED-KEY,
DHGRP=DH_GROUP14, PRFALG=AES128_XCBC, DURATION=86400;
ADD IKEPEER: PEERNAME="ike", PROPID=10, IKEVERSION=IKE_V2, IDTYPE=FQDN,
REMOTEIP="90.90.90.90", REMOTENAME="secgw", PKEY="ikekey", DPD=PERIODIC,
NOTE

l Rule 2 applies to eNodeB O&M data flows.
If O&M data is not protected by IPsec, rule 2 does not need to be configured.
10.7.3 Activation Observation

NodeB, or eNodeB.
Issue 02 (2013-07-30)

111
SingleRAN
10.8 Secure Configuration Modification on a Reconstructed

Network
An insecure transport network can be reconstructed into a PKI- or PSK-based secure network
to meet operator's requirements. If an operator uses a PSK-based secure network, the operator
can reconstruct the network into a PKI-based secure network to improve network security.
During the network reconstruction, the base station must be reset to activate modified data, which
interrupts ongoing services.
If operators deploy a PKI system to reconstruct the live network into a PKI-based secure network,
the PKI system enables equipment on the operator's network to directly use an operator-issued
device certificate for authentication, thereby eliminating the need to preconfigure a Huaweiissued device certificate on the equipment. This section describes only the PKI-based secure
network that uses operator-issued device certificates.
10.8.1 Reconstruction from an Insecure Network to a PKI-based

Secure Network
In this scenario, the reconstruction requirements and IPsec reconfiguration procedure are the
same for eGBTSs, NodeBs, eNodeBs, and multimode base stations. This section uses an eNodeB
as an example to describe the reconstruction requirements and IPsec reconfiguration procedure
when an insecure network is reconstructed into a PKI-based secure network.
Figure 10-17 shows the network topologies before and after the reconstruction.
Issue 02 (2013-07-30)

112
SingleRAN
Figure 10-17 Example of reconstructing an insecure network into a PKI-based secure network
for an eNodeB
Before the reconstruction, the eNodeB must meet the hardware requirements described in section
10.3.2 Hardware Planning.
General Procedure
The general procedure for IPsec and PKI configuration modification is as follows:
Issue 02 (2013-07-30)

113
SingleRAN
Network Deployment and Information Collection

The operator deploys the following on the network:
l
An SeGW configured with an operator-issued device certificate, an operator's root

certificate, and security-related parameters.
A PKI system, in which the CA is preconfigured with the Huawei root certificate.
Engineering personnel collect the following information:

l
Information about the SeGW

For details, see section 10.2 Required Information.
Issue 02 (2013-07-30)
Information about the CA, including the CA name, uniform resource locator (URL) of the
CA, and signature algorithm used by the CA.

114
SingleRAN
Data Planning
Reconstructing an insecure network to a PKI-based secure network requires special IP address
planning, as described in Table 10-31.
Table 10-31 Special IP address planning for reconstructing an insecure network into a PKIbased secure network
Item
Example
Remarks
IP address of FE port 1 on the

UMPT_L
20.20.20.188/24
This IP address is used as the source

IP address at the outer layer of the
IPsec tunnel on the eNodeB side.
Signaling/service IP address
of the eNodeB
33.33.33.188/32
This IP address must be a logical IP

address.
O&M IP address of the

eNodeB
31.31.31.188/32

address.
Source IP address for

certificate updates
l 31.31.31.188/32
l If the O&M channel is protected

by IPsec and the eNodeB can
access the CA either through an
external network or through the
intranet, the source IP address
for certificate updates must be
set to the O&M IP address, for
example, 31.31.31.188.
l 45.45.45.45/32
l 20.20.20.188/24
l If the O&M channel is not

protected by IPsec and the
eNodeB can access the CA
either through an external
network or through the intranet,
it is recommended that the
source IP address for certificate
updates be set to a new intranet
logical IP address, for example,
45.45.45.45.
l If the eNodeB can access the CA
through only an external
network, the source IP address
for certificate updates must be
set to a port IP address, for
example, 20.20.20.188.
IPsec data planning is similar to that described in Data Preparation in section 10.6.1 Deploying
IPsec on an eGBTS, NodeB, or eNodeB.
PKI data planning is the same as that described in section "Data Preparation" in PKI Feature
Parameter Description.
Issue 02 (2013-07-30)

115
SingleRAN
Preparing the Incremental Script

An incremental script is generated based on data of existing base stations and includes
configuration modifications.
For details about how to modify IPsec configurations, see Data Preparation in section1 10.6.1
Deploying IPsec on an eGBTS, NodeB, or eNodeB. ACL rules are configured according to
the network plan.
For details about how to modify PKI configurations, see Using the CME to Perform Batch
Configuration for Newly Deployed Base Stations of section "Initial Configuration" in PKI
Feature Parameter Description.
Checking the eNodeB Environment

Engineering personnel must check the eNodeB and ensure that:
l
The eNodeB meets the hardware requirements described in section 10.3.2 Hardware
Planning.
The licenses for the IPsec and PKI features have been activated on the base station.
The eNodeB is preconfigured with a Huawei-issued device certificate and the Huawei root
certificate.
Downloading the Modified Data

The procedure for downloading the modified data is as follows:
Step 1 On the main menu of the M2000, click
in the upper left corner.
Step 2 On the Application Center tab page, double-click the CME icon to start the CME.
Step 3 On the CME, choose CM Express > Planned Area, and click
script.
to export the incremental
Step 4 In the Export Incremental Scripts dialog box, choose a specific base station to which the script
is exported, specify Output Path and Script Executor Operation, and click OK.
Step 5 On the displayed Script Executor page, observe the export progress.
Step 6 After the export is complete, restart the base station to make the script take effect.
----End
Modifying Routing Information

The operator modifies routing information to enable data flows that need to be protected by
IPsec to pass through the SeGW before reaching their final destination.
Step 1 Run the DSP IKESA command to check the SA status.
Issue 02 (2013-07-30)

116
SingleRAN
Step 2 Run the DSP IPSECSA command to check the IPsec SA status.
The following is an example of the command output:
----End
10.8.2 Reconstruction from an Insecure Network to a PSK-based

Secure Network
when an insecure network is reconstructed into a PSK-based secure network.
Issue 02 (2013-07-30)

117
SingleRAN
Figure 10-18 Example of reconstructing an insecure network into a PSK-based secure network
for an eNodeB
Before the reconstruction, the eNodeB must meet the hardware requirements described in section
10.3.2 Hardware Planning.
General Procedure
The general procedure for IPsec configuration modification is as follows:
Issue 02 (2013-07-30)

118
SingleRAN

1.
The operator deploys an SeGW on the network. The SeGW is configured with an operatorissued device certificate, an operator's root certificate, and security-related parameters.
2.
Engineering personnel collect information about the SeGW. For details, see section 10.2
Required Information.
Data Planning
Reconstructing an insecure network to a PSK-based secure network requires special IP address
planning, as described in Table 10-32.
Issue 02 (2013-07-30)

119
SingleRAN
Table 10-32 Special IP address planning for reconstructing an insecure network into a PSKbased secure network
Item
Example
Remarks
IP address of FE port 1 on the

UMPT_L
20.20.20.188/24
This IP address is used as the source IP

address at the outer layer of the IPsec
tunnel on the eNodeB side.
Signaling/service IP address
of the eNodeB
33.33.33.188/32

address.
O&M IP address of the

eNodeB
31.31.31.188/32

address.
IPsec data planning is similar to that described in Data Preparation in section 10.6.1 Deploying
IPsec on an eGBTS, NodeB, or eNodeB.The following describes only the differences in IPsec
data planning between a reconstructed PSK-based secure and a newly deployed PKI-based
secure network:
l
Data to prepare for an IKE proposal

Table 10-33 Different data to prepare for an IKE proposal
Parameter Name
Parameter ID
Setting Notes
Data Source
Authentication
Method
AUTHMETH
Set this parameter

to
PRE_SHARED_
KEY if PSK
authentication is
used.
l Network plan
l Negotiation
with the IKE
peer
Data to prepare for an IKE peer

Table 10-34 Different data to prepare for an IKE peer
Paramete
r Name
Parameter ID
Setting Notes
Data Source
Local ID
Type
IDTYPE
If PSK authentication is used and if

IKEVERSION and EXCHMODE are
set to IKE_V1 and MAIN,
respectively, set this parameter to IP.
l Network
plan
Remote
Name
Issue 02 (2013-07-30)
REMOTENA
ME
If PSK authentication is used, set this

parameter to a value same as the IKE
local name configured at the SeGW.

l Negotiatio
n with the
IKE peer
120
SingleRAN
Paramete
r Name
Parameter ID
Setting Notes
Data Source
Pre-shared
Key
PKEY
If PSK authentication is used, set this

parameter to a value same as that of the
IKE peer.
(Optional) If PSK authentication is used and IDTYPE is set to FQDN, engineering

personnel also need to configure the IKE local name.
Table 10-35 Data related to the IKE local name
Parameter Name
Parameter ID
Setting Notes
Data Source
Local Name
IKELNM
Set this parameter

when
AUTHMETH and
IDTYPE are set to
PRE_SHARED_
KEY and FQDN,
respectively.
Network plan
Set this parameter

to a value same as
the IKE peer name
configured at the
SeGW.

An incremental script is generated based on data of existing base stations and includes
configuration modifications.
For details about how to modify IPsec configurations, see Data Preparation in section 10.6.1
Deploying IPsec on an eGBTS, NodeB, or eNodeB. ACL rules are configured according to
the network plan.

l
Planning.
The license for the IPsec feature has been activated on the eNodeB.

For details, see Downloading the Modified Data in section 10.8.1 Reconstruction from an
Insecure Network to a PKI-based Secure Network.
Issue 02 (2013-07-30)

121
SingleRAN
Modifying Routing Information

The operator modifies routing information to enable data flows that need to be protected by
IPsec to pass through the SeGW before reaching their final destination.
For details about how to observe IPsec, see Activation Observation of section 10.8.1
Reconstruction from an Insecure Network to a PKI-based Secure Network.
10.8.3 Reconstruction from a PSK-based Secure Network to a PKIbased Secure Network

when a PSK-based secure network is reconstructed into a PKI-based secure network.
Figure 10-19 Example of reconstructing a PSK-based secure network into a PKI-based secure
network for an eNodeB
General Procedure
The general procedure for IPsec and PKI configuration modification is as follows:
Issue 02 (2013-07-30)

122
SingleRAN

1.
The operator deploys a PKI system on the network and preconfigures the Huawei root
certificate on a CA in the system.
2.
The operator configures an operator-issued device certificate and an operator's root

certificate on the SeGW.
3.
Engineering personnel collect information about the CA, including the CA name, URL of
the CA, and signature algorithm used by the CA.
Data Planning
Reconstructing a PSK-based secure network to a PKI-based secure network requires special IP
address planning, as described in Table 10-36 .Special IP address planning for reconstructing a
PSK-based secure network into a PKI-based secure network.
Issue 02 (2013-07-30)

123
SingleRAN
Table 10-36 Special IP address planning

Item
Example
Remarks
Source IP address for

certificate updates
l 31.31.31.188/32
l If the O&M channel is protected by

IPsec and the eNodeB can access the
CA either through an external
network or through the intranet, the
updates must be set to the O&M IP
address, for example, 31.31.31.188.
l 45.45.45.45/32
l 20.20.20.188/24
l If the O&M channel is not protected

by IPsec and the eNodeB can access
the CA either through an external
network or through the intranet, it is
recommended that the source IP
address for certificate updates be set
to a new intranet logical IP address,
for example, 45.45.45.45.
l If the eNodeB can access the CA
through only an external network, the
updates must be set to a port IP
address, for example, 20.20.20.188.
The requirements for IPsec data planning are as follows:

l
AUTHMETH in the IKEPROPOSAL MO must be set to IKE_RSA_SIG.
REMOTENAME in the IKEPEER MO must be set to be consistent with the value of the
subjectaltname field in the device certificate used by the SeGW.
NOTE
It is recommended that IDTYPE in the IKEPEER MO be set to FQDN.
Other IPsec parameter settings on the eNodeB remain unchanged.
PKI data planning is the same as that described in section "Data Preparation" in PKI Feature
Parameter Description.

For details, see Preparing the Incremental Script in section 10.8.1 Reconstruction from an

l
Issue 02 (2013-07-30)
Planning.
124
SingleRAN
The license for the PKI feature has been activated on the eNodeB.
The eNodeB is preconfigured with a Huawei-issued device certificate and the Huawei root
certificate.

For details, see Downloading the Modified Data in section 10.8.1 Reconstruction from an
Modifying SeGW Configurations

Engineering personnel modify security-related parameter settings on the SeGW, such as the
authentication method.
For details, see Activation Observation in section 10.8.1 Reconstruction from an Insecure
Network to a PKI-based Secure Network.
10.9 Performance Monitoring

The IPsec feature does not require performance optimization.
10.10 Performance Optimization

The IPsec feature does not require performance optimization.
10.11 Troubleshooting
After the IPsec feature is activated, the base station may report the following alarms:
l
ALM-25891 IKE Negotiation Failure
ALM-25950 Base Station Being Attacked with "Specific Problem" set to IPsec Replay
For details about how to clear these alarms for each type of base station, see the following sections
in 3900 Series Base Station Alarm Reference:
l
"eGBTS Alarm Reference"
"NodeB Alarm Reference"
"eNodeB Alarm Reference"
Issue 02 (2013-07-30)

125
SingleRAN
11 Parameters
11
Parameters
Table 11-1 UMTS: Parameter description

Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SPGN
BTS3900
ADD
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the name

of the IPSec
policy group.
DSP
IPSECPOLICY
LST
IPSECPOLICY
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
MOD
IPSECPOLICY
RMV
IPSECPOLICY
GUI Value
Range:1~15
characters
Unit:None
Actual Value
Range:1~15
characters
Default
Value:None
Issue 02 (2013-07-30)

126
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SPSN
BTS3900
ADD
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IPSECPOLICY
Meaning:Indicates the
sequence No. of
the IPSec policy
group. The
smaller the
number, the
higher the
priority.
RMV
IPSECPOLICY
GUI Value
Range:1~10000
DSP
IPSECPOLICY
LST
IPSECPOLICY
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
Unit:None
Actual Value
Range:1~10000
Default
Value:None
Issue 02 (2013-07-30)

127
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
LTCFG
BTS3900
ADD
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
IPsec
configuration
mode of the
IPSec SA life
cycle. If this
parameter is set
to GLOBAL, the
default SA life
cycle is used. In
this case, LTS
and LTKB are
set to the default
values 3600 and
69120000,
respectively. If
this parameter is
set to LOCAL,
the SA life cycle
is configurable.
MOD
IPSECPOLICY
DSP
IPSECPOLICY
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPOLICY
GUI Value
Range:GLOBA
L(Global
Configuration),
LOCAL(Local
Configuration)
Unit:None
Actual Value
Range:GLOBA
L, LOCAL
Default
Value:LOCAL
(Local
Configuration)
Issue 02 (2013-07-30)

128
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
LTS
BTS3900
ADD
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the life

cycle of an
IPSec SA. An
IPSec SA
becomes invalid
once its life
cycle specified
by this
parameter
elapses. Before
the life cycle of
an IPSec SA
elapses, the
IPSec policy is
used in an
attempt to
establish a new
IPSec SA
through
negotiation to
ensure secure
transmission;
before the
negotiation is
complete, the
original IPSec
SA is still used.
After the
negotiation is
complete, the
new SA is
immediately
used. IPSec SA
negotiation
takes a period.
To prevent SA
updating from
affecting
communication
security, a life
cycle longer
than 900
seconds is
recommended.
MOD
IPSECPOLICY
DSP
IPSECPOLICY
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPOLICY
Issue 02 (2013-07-30)

129
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
GUI Value
Range:
30~604800
Unit:s
Actual Value
Range:
30~604800
Default Value:
3600
Issue 02 (2013-07-30)

130
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
LTKB
BTS3900
ADD
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the traffic

volume
threshold for the
IPSec policy,
above which
negotiation for a
new IPSec SA is
started. The
value 0 indicates
that the function,
which initiates
negotiation for a
new IPSec SA
based on the
traffic volume,
is disabled. But
when BS acts as
initiator in
IKEv1 and this
value is set to 0,
if the responder
insists or
enforces the
IPSec SA traffic
lifetime to BS,
BS will enable
this function to
avoid service
break down.
MOD
IPSECPOLICY
DSP
IPSECPOLICY
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPOLICY
GUI Value
Range:
0,1843200~429
4967295
Unit:KB
Actual Value
Range:
0,1843200~429
4967295
Default Value:
69120000
Issue 02 (2013-07-30)

131
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
REPLAYWND
BTS3900
ADD
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the size of

the IPSec packet
anti-replay
window. If the
value of this
parameter is set
to 0, the IPSec
packet antireplay function
is disabled. If the
value of this
parameter is set
to 32, 64, 128,
256, 512, 1024,
2048 or 4096,
the system
checks whether
the packets are
duplicate in the
window. A
packet is
discarded if it
has a duplicate
packet or its
sequence
number is
smaller than any
packet in the
window. The
window slides if
the sequence
number of the
packet is larger
than any packet
that is received
in the window.
MOD
IPSECPOLICY
DSP
IPSECPOLICY
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPOLICY
GUI Value
Range:WND_D
ISABLE(0),
WND_32(32),
WND_64(64),
WND_128
(128),
WND_256
(256),
WND_512
Issue 02 (2013-07-30)

132
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
(512),
WND_1024
(1024),
WND_2048
(2048),
WND_4096
(4096)
Unit:None
Actual Value
Range:WND_D
ISABLE,
WND_32,
WND_64,
WND_128,
WND_256,
WND_512,
WND_1024,
WND_2048,
WND_4096
Default
Value:WND_DI
SABLE(0)
Issue 02 (2013-07-30)

133
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
ACTION
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
Meaning:Indicates the action

taken on the data
that matches the
ACL rule. When
the ACL to
which the ACL
rule belongs is
referenced by a
packet filter, the
BS accepts or
transmits the
data that
matches the rule
if this parameter
is set to
PERMIT, and
rejects the data if
this parameter is
set to DENY.
When the ACL
is referenced by
an IPSec policy,
the BS encrypts
or decrypts the
data that
matches the rule
if this parameter
is set to
PERMIT, and
does not
perform any
encryption or
decryption on
the data if this
parameter is set
to DENY.
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:DENY
(Deny),
PERMIT
(Permit)
Unit:None
Actual Value
Range:DENY,
PERMIT
Issue 02 (2013-07-30)

134
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
Default
Value:PERMIT
(Permit)
Issue 02 (2013-07-30)

135
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
ENCAPMODE
BTS3900
ADD
IPSECPROPOS
AL
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IPSECPROPOS
AL
GBFD-113524
encapsulation
mode of an
IPSec proposal,
which can be set
to TUNNEL or
TRANSPORT.
In
TRANSPORT
mode, only data
is encrypted. In
TUNNEL mode,
the whole IP
packet is
protected, and a
new IP header is
added to the
original IP
packet. The
source IP
address and the
destination IP
address of the
new IP header
are the IP
addresses of two
ends of the
security tunnel.
Both the
TRANSPORT
mode and the
TUNNEL mode
are used for endto-end IPSec
protection. The
TUNNEL mode,
however, is also
applied to the
protection of a
certain segment.
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IPSECPROPOS
AL
LST
IPSECPROPOS
AL
GUI Value
Range:TUNNE
L(Tunnel),
TRANSPORT
(Transport)
Unit:None
Issue 02 (2013-07-30)

136
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
Actual Value
Range:TUNNE
L,
TRANSPORT
Default
Value:TUNNE
L(Tunnel)
Issue 02 (2013-07-30)

137
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
LOCALIP
BTS3900
ADD IKEPEER
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the IP
address of the
local end, which
is used in IKE
negotiation.
This IP address
can be set to
0.0.0.0 or a
configured
interface IP
address at the
local end. If this
parameter is set
to 0.0.0.0, the
BS
automatically
uses the
interface IP
address to
negotiate with
the peer. If
multiple IP
addresses are
configured at the
port, it is
recommended
that you specify
one IP address
for the
negotiation. If
the local BS uses
the digital
certificate and
IP address for
authentication in
the negotiation,
ensure that the
IP address in the
certificate is the
same as the local
IP address of the
BS.
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:Valid IP
address
Unit:None
Issue 02 (2013-07-30)

138
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
Actual Value
Range:Valid IP
address
Default Value:
0.0.0.0
REMOTEIP
BTS3900
ADD IKEPEER
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
Meaning:Indicates the IP
address of the
peer end.
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Default
Value:None
IDTYPE
BTS3900
ADD IKEPEER
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
Meaning:Indicates the type of

the
identification
payload that the
local end
transmits. The
authentication
can be
performed based
on IP or fully
qualified
domain name
(FQDN).
GUI Value
Range:IP(IP
Identify), FQDN
(Name Identify)
Unit:None
Actual Value
Range:IP,
FQDN
Default
Value:None
Issue 02 (2013-07-30)

139
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
IKEVERSION
BTS3900
ADD IKEPEER
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the IKE

protocol
version.
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:IKE_V1
(IKE V1),
IKE_V2(IKE
V2)
Unit:None
Actual Value
Range:IKE_V1,
IKE_V2
Default
Value:IKE_V2
(IKE V2)
Issue 02 (2013-07-30)

140
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
EXCHMODE
BTS3900
ADD IKEPEER
LOFD-003009 /
TDLOFD-0030
09
IPsec

exchange mode.
In main mode,
keys are
exchanged
independently
from identity
authentications.
This protects
identity
information and
hence enhances
security. The
aggressive mode
does not have
identity
authentication
protection.
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:MAIN
(Main Mode),
AGGRESSIVE
(Aggressive
Mode)
Unit:None
Actual Value
Range:MAIN,
AGGRESSIVE
Default
Value:MAIN
(Main Mode)
Issue 02 (2013-07-30)

141
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DHGRP
BTS3900
ADD
IKEPROPOSA
L
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IKEPROPOSA
L
GBFD-113524
Meaning:Indicates the DiffieHellman (DH)

group of the IKE
proposal. The
core technology
used in an IKE
proposal is the
Diffie-Hellman
(DH) exchange
technology. The
DH exchange
technology is
used to calculate
private
information
based on public
information. It is
mathematically
proven that
decrypting the
DH information
is impractical
due to
calculation
complexity.
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IKEPROPOSA
L
LST
IKEPROPOSA
L
GUI Value
Range:DH_GR
OUP1(768-bit
Diffie-Hellman
Group),
DH_GROUP2
(1024-bit DiffieHellman
Group),
DH_GROUP14
Group),
DH_GROUP15
(3072-bit DiffieHellman Group)
Unit:None
Actual Value
Range:DH_GR
OUP1,
DH_GROUP2,
Issue 02 (2013-07-30)

142
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
DH_GROUP14,
DH_GROUP15
Default
Value:DH_GR
OUP2(1024-bit
Diffie-Hellman
Group)
PRFALG
BTS3900
ADD
IKEPROPOSA
L
LOFD-003009 /
TDLOFD-0030
09
MOD
IKEPROPOSA
L
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IKEPROPOSA
L
LST
IKEPROPOSA
L
Pseudo-random
Function (PRF)
algorithm used
in IKEv2. The
PRF algorithm
is used to
generate the
materials
required for IKE
authentication
and encryption.
For details about
how to generate
materials, see
RFC4306.
GUI Value
Range:HMAC_
MD5
(HMAC_MD5),
HMAC_SHA1
(HMAC_SHA1
),
AES128_XCBC
(AES128_XCB
C)
Unit:None
Actual Value
Range:HMAC_
MD5,
HMAC_SHA1,
AES128_XCBC
Default
Value:HMAC_
SHA1
(HMAC_SHA1
)
Issue 02 (2013-07-30)

143
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DURATION
BTS3900
ADD
IKEPROPOSA
L
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IKEPROPOSA
L
GBFD-113524
Meaning:Indicates the life

cycle of an
ISAKMP SA.
ISAKMP refers
to Internet
Security
Association and
Key
Management
Protocol, and
SA refers to
security
association. IKE
negotiation
requires a long
time to calculate
Diffie-Hellman
(DH) keys. It is
recommended
that this
parameter be set
to greater than
10 minutes so
that the update
of the ISAKMP
SA does not
affect the secure
communication.
Before the SA
life cycle
elapses, local
and peer ends
will negotiate
with each other
to generate a
new SA to
replace the
original one.
The new SA is
used upon
completion of
the negotiation,
and the original
SA is
automatically
removed once
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IKEPROPOSA
L
LST
IKEPROPOSA
L
Issue 02 (2013-07-30)

144
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
its life cycle
elapses.
GUI Value
Range:
60~604800
Unit:s
Actual Value
Range:
60~604800
Default Value:
86400
DPD
BTS3900
ADD IKEPEER
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
Meaning:Indicates whether to
enable the dead
peer detection
(DPD) function.
GUI Value
Range:DISABL
E(Disable),
PERIODIC
(Periodic)
Unit:None
Actual Value
Range:DISABL
E, PERIODIC
Default
Value:PERIODI
C(Periodic)
Issue 02 (2013-07-30)

145
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DPDIDLETIM
E
BTS3900
ADD IKEPEER
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the DPD

idle time. If the
local end does
not receive
encrypted
packets for a
time defined by
this parameter, it
sends a DPD
packet to
perform dead
peer detection.
The interval for
sending a DPD
packet slightly
varies in various
network
environments.
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:10~3600
Unit:s
Actual Value
Range:10~3600
Default Value:
10
DPDRETRN
BTS3900
ADD IKEPEER
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
Meaning:Indicates the number

of
retransmission
attempts after a
DPD detection
fails.
GUI Value
Range:3~10
Unit:None
Actual Value
Range:3~10
Default Value:5
Issue 02 (2013-07-30)

146
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DPDRETRI
BTS3900
ADD IKEPEER
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the interval

at which DPD
detection frames
are sent. The
interval at which
DPD detection
frames are sent
may slightly
vary in various
network
environments
such as network
congestion,
delay, and jitter.
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:3~30
Unit:s
Actual Value
Range:3~30
Default Value:5
PWD
BTS3900
SET
IPSECBYPASS
CFG
None
None
DSP
IPSECBYPASS
CFG
LST
IPSECBYPASS
CFG
password used
for switching the
base station
between an
IPSec network
and a non-IPSec
network.
GUI Value
Range:1~19
characters
Unit:None
Actual Value
Range:1~19
characters
Default
Value:None
Issue 02 (2013-07-30)

147
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
MSPGN
BTS3900
ADD
IPSECDTNL
LOFD-003019/
TDLOFD-0030
19
IPsec Tunnel
Backup

of the primary
IPSec policy
group. The
primary IPSec
tunnel uses an
IPSec policy in
the primary
IPSec policy
group.
MOD
IPSECDTNL
DSP
IPSECDTNL
GBFD-113524
WRFD-140209
LST
IPSECDTNL
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:1~15
characters
Unit:None
Actual Value
Range:1~15
characters
Default
Value:None
MSPSN
BTS3900
ADD
IPSECDTNL
MOD
IPSECDTNL
DSP
IPSECDTNL
LST
IPSECDTNL
LOFD-003019/
TDLOFD-0030
19
GBFD-113524
WRFD-140209
IPsec Tunnel
Backup
BTS Integrated
Ipsec
NodeB
Integrated IPSec
Meaning:Indicates the ID of
the primary
IPSec policy.
The primary
IPSec tunnel
uses the primary
IPSec policy,
which is
identified by this
parameter and
the MSPGN
parameter
together.
GUI Value
Range:1~10000
Unit:None
Actual Value
Range:1~10000
Default
Value:None
Issue 02 (2013-07-30)

148
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SSPGN
BTS3900
ADD
IPSECDTNL
LOFD-003019/
TDLOFD-0030
19
IPsec Tunnel
Backup

of the secondary
IPSec policy
group. The
secondary IPSec
tunnel uses an
IPSec policy in
the secondary
IPSec policy
group.
MOD
IPSECDTNL
DSP
IPSECDTNL
GBFD-113524
WRFD-140209
LST
IPSECDTNL
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:1~15
characters
Unit:None
Actual Value
Range:1~15
characters
Default
Value:None
SSPSN
BTS3900
ADD
IPSECDTNL
MOD
IPSECDTNL
DSP
IPSECDTNL
LST
IPSECDTNL
LOFD-003019/
TDLOFD-0030
19
GBFD-113524
WRFD-140209
IPsec Tunnel
Backup
BTS Integrated
Ipsec
NodeB
Integrated IPSec
the secondary
IPSec policy.
The secondary
IPSec tunnel
uses the
secondary IPSec
policy, which is
identified by this
parameter and
the SSPGN
parameter
together.
GUI Value
Range:1~10000
Unit:None
Actual Value
Range:1~10000
Default
Value:None
Issue 02 (2013-07-30)

149
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
ACLID
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
the Access
Control List
(ACL) to which
the ACL rule
belongs.
GBFD-118601
BTS Integrated
Ipsec
LST ACLRULE
MOD
ACLRULE
RMV
ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:
3000~4999
Unit:None
Actual Value
Range:
3000~4999
Default
Value:None
PROPID
BTS3900
ADD
IKEPROPOSA
L
LOFD-003009 /
TDLOFD-0030
09
DSP
IKEPROPOSA
L
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
the IKE
proposal.
NodeB
Integrated IPSec
GUI Value
Range:1~99
LST
IKEPROPOSA
L
Unit:None
MOD
IKEPROPOSA
L
Default
Value:None
Actual Value
Range:1~99
RMV
IKEPROPOSA
L
Issue 02 (2013-07-30)

150
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
ACLID
BTS3900
ADD ACL
WRFD-050402
LST ACL
WRFD-140209
MOD ACL
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
the Access
Control List
(ACL) to which
the access
control rule
belongs. ACL
ID in the range
from 3000 to
3999 identifies
high-level rules
based on the
layer 3 and layer
4 information.
ACL ID in the
range from 4000
to 4999
identifies access
control rules
based on the
MAC layer
information.
RMV ACL
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:
3000~4999
Unit:None
Actual Value
Range:
3000~4999
Default
Value:None
PEERNAME
BTS3900
ADD IKEPEER
DSP IKEPEER
LST IKEPEER
LOFD-003009 /
TDLOFD-0030
09
MOD IKEPEER
GBFD-113524
RMV IKEPEER
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec

of the IKE peer.
GUI Value
Range:1~15
characters
Unit:None
Actual Value
Range:1~15
characters
Default
Value:None
Issue 02 (2013-07-30)

151
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
PROPNAME
BTS3900
ADD
IPSECPROPOS
AL
LOFD-003009 /
TDLOFD-0030
09
IPsec
DSP
IPSECPROPOS
AL
GBFD-113524

of the IPSec
proposal.
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPROPOS
AL
Unit:None
Actual Value
Range:1~15
characters
MOD
IPSECPROPOS
AL
Default
Value:None
RMV
IPSECPROPOS
AL
IKELNM
BTS3900
SET IKECFG
DSP IKECFG
LST IKECFG
GUI Value
Range:1~15
characters
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec

local name.
GUI Value
Range:0~31
characters
Unit:None
Actual Value
Range:0~31
characters
Default
Value:NULL
(empty string)
RULEID
BTS3900
ADD
ACLRULE
LST ACLRULE
MOD
ACLRULE
RMV
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
the ACL rule.
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
GUI Value
Range:1~65535
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
Unit:None
Access Control
List (ACL)
Actual Value
Range:1~65535
Abis over IP
GBFD-118601
Default
Value:None
BTS Integrated
Ipsec
GBFD-113524
Issue 02 (2013-07-30)

152
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SIP
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
Meaning:Indicates the source

IP address of
data to which the
ACL rule is
applied. To add
an ACL rule that
is applicable to
data of all source
IP addresses, set
this parameter to
0.0.0.0.
MOD
ACLRULE
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Default
Value:None
Issue 02 (2013-07-30)

153
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SWC
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
wildcard of the
source IP
address. The
wildcard is used
to determine
which bits can
be neglected
when IP address
matching is
being
performed.
Generally, it can
be considered as
the inverse of the
corresponding
subnet mask.
MOD
ACLRULE
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:Valid
wildcard of the
IP address
Unit:None
Actual Value
Range:Valid
wildcard of the
IP address
Default
Value:None
Issue 02 (2013-07-30)

154
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DIP
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
destination IP
address of data
to which the
ACL rule is
applied. To add
an ACL rule that
is applicable to
data of all
destination IP
addresses, set
this parameter to
0.0.0.0.
MOD
ACLRULE
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Default
Value:None
Issue 02 (2013-07-30)

155
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DWC
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
wildcard of the
destination IP
address. The
wildcard is used
to determine
which bits can
be neglected
when IP address
matching is
being
performed.
Generally, it can
be considered as
the inverse of the
corresponding
subnet mask.
MOD
ACLRULE
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:Valid
wildcard of the
IP address
Unit:None
Actual Value
Range:Valid
wildcard of the
IP address
Default
Value:None
Issue 02 (2013-07-30)

156
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
ENCALG
BTS3900
ADD
IKEPROPOSA
L
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IKEPROPOSA
L
GBFD-113524
encryption
algorithm used
in the IKE
proposal. The
Data Encryption
Standard (DES)
is an
internationally
used data
encryption
algorithm,
which uses a 56bit key. The
3DES is also an
internationally
used encryption
algorithm,
which uses a
168-bit key. The
Advanced
Encryption
Standard (AES)
is an advanced
encryption
algorithm,
which provides
three types of
key of different
lengths: 128,
192, and 256
bits. Thus,
different
protection levels
are available.
For details, see
RFC2401.
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IKEPROPOSA
L
LST
IKEPROPOSA
L
GUI Value
Range:DES
(DES), 3DES
(3DES),
AES128
(AES128),
AES192
(AES192),
Issue 02 (2013-07-30)

157
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
AES256
(AES256)
Unit:None
Actual Value
Range:DES,
3DES, AES128,
AES192,
AES256
Default
Value:AES128
(AES128)
Issue 02 (2013-07-30)

158
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
AUTHALG
BTS3900
ADD
IKEPROPOSA
L
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IKEPROPOSA
L
GBFD-113524
authentication
algorithm used
in the IKE
proposal. IKE
uses hashed
message
authentication
code (HMAC)
or cipher block
chaining (CBC)
for identity
authentication
and data
integrity check.
For details about
HMAC, see
RFC4306.
HMAC
currently
supports two
hash functions:
message digest
algorithm 5
(MD5) and
secure hash
algorithm 1
(SHA1). For
details about the
hash functions,
see RFC2409.
MD5 and SHA1
verify data by
means of
integrity
protection.
SHA1 provides
higher security
level than MD5.
CBC currently
supports AESXCBC- 96,
which is an
enhancement to
CBC and applies
only to IKEv2.
For details about
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IKEPROPOSA
L
LST
IKEPROPOSA
L
Issue 02 (2013-07-30)

159
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
AES-XCBC-96,
see RFC3566.
GUI Value
Range:MD5
(MD5), SHA1
(SHA1),
AES_XCBC_96
(AES_XCBC_9
6)
Unit:None
Actual Value
Range:MD5,
SHA1,
AES_XCBC_96
Default
Value:SHA1
(SHA1)
AUTHMETH
BTS3900
ADD
IKEPROPOSA
L
LOFD-003009 /
TDLOFD-0030
09
MOD
IKEPROPOSA
L
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IKEPROPOSA
L
LST
IKEPROPOSA
L
authentication
mode used in the
IKE proposal.
For details, see
RFC2409.
GUI Value
Range:PRE_SH
ARED_KEY
(Pre-shared
Key),
IKE_RSA_SIG
(RSA Digital
Certificate
Signature)
Unit:None
Actual Value
Range:PRE_SH
ARED_KEY,
IKE_RSA_SIG
Default
Value:PRE_SH
ARED_KEY
(Pre-shared
Key)
Issue 02 (2013-07-30)

160
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
PROPID
BTS3900
ADD IKEPEER
LOFD-003009 /
TDLOFD-0030
09
IPsec
BTS Integrated
Ipsec
the IKE
proposal in use.
NodeB
Integrated IPSec
GUI Value
Range:1~99
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
GBFD-113524
WRFD-140209
Unit:None
Actual Value
Range:1~99
Default
Value:None
REMOTENAM
E
BTS3900
ADD IKEPEER
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec

of the peer end.
GUI Value
Range:0~31
characters
Unit:None
Actual Value
Range:0~31
characters
Default
Value:None
Issue 02 (2013-07-30)

161
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
PKEY
BTS3900
ADD IKEPEER
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the preshared key. The

two negotiation
ends must be
configured with
the same
authenticator.
This parameter
takes effect only
when
Authentication
Method in the
corresponding
IKEPROPOSA
L is set to
PRE_SHARED
_KEY.
MOD IKEPEER
DSP IKEPEER
LST IKEPEER
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:0~127
characters
Unit:None
Actual Value
Range:0~127
characters
Default
Value:None
ACLDESC
BTS3900
ADD ACL
WRFD-050402
MOD ACL
WRFD-140209
LST ACL
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
GBFD-113524
Issue 02 (2013-07-30)
Access Control
List (ACL)
Abis over IP

Meaning:Indicates the brief

description of
the ACL.
GUI Value
Range:0~127
characters
Unit:None
Actual Value
Range:0~127
characters
Default
Value:None
162
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
PT
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
protocol type of
the data to which
the ACL rule is
applied.
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:IP(IP),
ICMP(ICMP),
TCP(TCP),
UDP(UDP),
SCTP(SCTP)
Unit:None
Actual Value
Range:IP,
ICMP, TCP,
UDP, SCTP
Default
Value:None
SMPT
BTS3900
ADD
ACLRULE
LST ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
GBFD-113524
Access Control
List (ACL)
Abis over IP
check the source
port number of
each data stream
before applying
the ACL rule.
GUI Value
Range:NO(No),
YES(Yes)
Unit:None
Actual Value
Range:NO, YES
Default
Value:None
Issue 02 (2013-07-30)

163
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
MFRG
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
match the
fragment
message. The
ACL rules for
matching
fragment
messages apply
to only packet
filtering and
does not apply to
the IPSec
function.
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:NO(No),
YES(Yes)
Unit:None
Actual Value
Range:NO, YES
Default
Value:NO(No)
Issue 02 (2013-07-30)

164
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SOP
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
filtering
condition for the
source port. If
this parameter is
set to OP_LT,
the ACL rule is
applied to the
data stream
whose source
port number is
smaller than or
equal to the
configured port
number. If this
parameter is set
to OP_GT, the
ACL rule is
applied to the
data stream
whose source
port number is
larger than or
equal to the
configured port
number. If this
parameter is set
to OP_EQ, the
ACL rule is
applied to the
data stream
whose source
port number is
equal to the
configured port
number. If this
parameter is set
to OP_NEQ, the
ACL rule is
applied to the
data stream
whose source
port number is
not equal to the
configured port
number. If this
parameter is set
LST ACLRULE
GBFD-113524
Issue 02 (2013-07-30)
Access Control
List (ACL)
Abis over IP

165
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
to OP_RANGE,
the ACL rule is
applied to the
data stream
whose
destination port
number is within
the configured
range.OP_NEQ
is available only
on the
LMPT,UMPT,
UTRPc and
SMPT.
GUI Value
Range:OP_LT
(Less or Equal),
OP_GT(Greater
or Equal),
OP_EQ
(Equivalent),
OP_NEQ(Not
Equivalent),
OP_RANGE
(Range)
Unit:None
Actual Value
Range:OP_LT,
OP_GT,
OP_EQ,
OP_NEQ,
OP_RANGE
Default
Value:None
Issue 02 (2013-07-30)

166
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SPT1
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec

port number
used when
SMPT is set to
YES. If SOP is
set to
OP_RANGE,
this parameter
indicates the
smallest source
port number. If
SOP is not set to
OP_RANGE,
this parameter
indicates a
specific source
port number.
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:0~65535
Unit:None
Actual Value
Range:0~65535
Default
Value:None
Issue 02 (2013-07-30)

167
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SPT2
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec

port number
used when
SMPT is set to
YES. If SOP is
set to
OP_RANGE,
this parameter
indicates the
largest source
port number.
This parameter
is valid only
when SOP is set
to OP_RANGE.
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:0~65535
Unit:None
Actual Value
Range:0~65535
Default
Value:None
DMPT
BTS3900
ADD
ACLRULE
LST ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
GBFD-113524
Access Control
List (ACL)
Abis over IP
check the
destination port
number of each
data stream
before applying
the ACL rule.
GUI Value
Range:NO(No),
YES(Yes)
Unit:None
Actual Value
Range:NO, YES
Default
Value:None
Issue 02 (2013-07-30)

168
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DOP
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
filtering
condition for the
destination port.
This parameter
is valid only
when DMPT is
set to YES. If
this parameter is
set to OP_LT,
the ACL rule is
applied to the
data stream
whose
destination port
number is
smaller than or
equal to the
configured port
number. If this
parameter is set
to OP_GT, the
ACL rule is
applied to the
data stream
whose
destination port
number is larger
than or equal to
the configured
port number. If
this parameter is
set to OP_EQ,
the ACL rule is
applied to the
data stream
whose
destination port
number is equal
to the
configured port
number. If this
parameter is set
to OP_NEQ, the
ACL rule is
applied to the
data stream
LST ACLRULE
GBFD-113524
Issue 02 (2013-07-30)
Access Control
List (ACL)
Abis over IP

169
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
whose
destination port
number is not
equal to the
configured port
number. If this
parameter is set
to OP_RANGE,
the ACL rule is
applied to the
data stream
whose
destination port
number is within
the configured
range.OP_NEQ
is available only
on the
LMPT,UMPT,
UTRPc and
SMPT.
GUI Value
Range:OP_LT
(Less or Equal),
OP_GT(Greater
or Equal),
OP_EQ
(Equivalent),
OP_NEQ(Not
Equivalent),
OP_RANGE
(Range)
Unit:None
Actual Value
Range:OP_LT,
OP_GT,
OP_EQ,
OP_NEQ,
OP_RANGE
Default
Value:None
Issue 02 (2013-07-30)

170
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DPT1
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
destination port
number used
when DMPT is
set to YES. If
DOP is set to
OP_RANGE,
this parameter
indicates the
smallest
destination port
number. If DOP
is not set to
OP_RANGE,
this parameter
indicates a
specific
destination port
number.
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:0~65535
Unit:None
Actual Value
Range:0~65535
Default
Value:None
Issue 02 (2013-07-30)

171
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DPT2
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
destination port
number used
when DMPT is
set to YES. If
DOP is set to
OP_RANGE,
this parameter
indicates the
largest
destination port
number. This
parameter is
valid only when
DOP is set to
OP_RANGE.
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:0~65535
Unit:None
Actual Value
Range:0~65535
Default
Value:None
MDSCP
BTS3900
ADD
ACLRULE
LST ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
GBFD-113524
Access Control
List (ACL)
Abis over IP
check the DSCP
of each data
stream before
applying the
ACL rule.
GUI Value
Range:NO(No),
YES(Yes)
Unit:None
Actual Value
Range:NO, YES
Default
Value:NO(No)
Issue 02 (2013-07-30)

172
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DSCP
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
Differentiated
Services Code
Point (DSCP).
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GUI Value
Range:0~63
Access Control
List (ACL)
Unit:None
Abis over IP
Actual Value
Range:0~63
GBFD-118601
BTS Integrated
Ipsec
Default
Value:None
LST ACLRULE
GBFD-113524
Issue 02 (2013-07-30)

173
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
VLANIDOP
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
Meaning:Indicates the filter

criteria for
VLAN IDs. This
parameter is
valid only when
ACLID ranges
from 4000 to
4999. When this
parameter is set
to OP_EQ, only
the VLAN ID
specified by
VLANID1 is a
valid one. When
this parameter is
set to
OP_RANGE, all
the VLAN IDs
within the range
of VLANID1 to
VLANID2 are
valid ones.
When this
parameter is set
to
OP_NOVLAN,
only packets
without VLAN
tags are valid
ones.
MOD
ACLRULE
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:OP_EQ
(Equivalent),
OP_RANGE
(Range),
OP_NOVLAN
(No Vlan)
Unit:None
Actual Value
Range:OP_EQ,
OP_RANGE,
OP_NOVLAN
Default
Value:None
Issue 02 (2013-07-30)

174
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
VLANID1
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
Meaning:Indicates the ID of a
VLAN to which
service data
belongs. When
Source Port
Operate is set to
OP_EQ, this
parameter
specifies the ID
of the matching
VLAN. When
Source Port
Operate is set to
OP_RANGE,
this parameter
specifies the
minimum ID of
the matching
VLANs.
MOD
ACLRULE
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:1~4094
Unit:None
Actual Value
Range:1~4094
Default
Value:None
Issue 02 (2013-07-30)

175
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
VLANID2
BTS3900
ADD
ACLRULE
WRFD-050402
WRFD-140209
IP Transmission
Introduction on
Iub Interface
LOFD-003009 /
TDLOFD-0030
09
NodeB
integrated IPSec
LOFD-0030140
1/
TDLOFD-0030
1401
IPsec
GBFD-118601
BTS Integrated
Ipsec
VLAN to which
service data
belongs. When
Source Port
Operate is set to
OP_RANGE,
this parameter
specifies the
maximum ID of
the matching
VLANs. This
parameter is
valid only when
Source Port
Operate is set to
OP_RANGE.
MOD
ACLRULE
LST ACLRULE
GBFD-113524
Access Control
List (ACL)
Abis over IP
GUI Value
Range:1~4094
Unit:None
Actual Value
Range:1~4094
Default
Value:None
Issue 02 (2013-07-30)

176
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
TRANMODE
BTS3900
ADD
IPSECPROPOS
AL
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IPSECPROPOS
AL
GBFD-113524
security
protocol used in
an IPSec
proposal. The
value AH
indicates the
Authentication
Header (AH)
protocol
specified in
RFC2402. The
value ESP
indicates the
Encapsulating
Security
Payload (ESP)
protocol
specified in
RFC2406. The
value AH_ESP
indicates that the
ESP protocol is
preferentially
used to protect
packets, but not
the AH protocol.
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IPSECPROPOS
AL
LST
IPSECPROPOS
AL
GUI Value
Range:AH(AH
Protocol), ESP
(ESP Protocol),
AH_ESP(AH/
ESP Protocol)
Unit:None
Actual Value
Range:AH,
ESP, AH_ESP
Default
Value:ESP(ESP
Protocol)
Issue 02 (2013-07-30)

177
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
AHAUTHALG
BTS3900
ADD
IPSECPROPOS
AL
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IPSECPROPOS
AL
GBFD-113524
Meaning:Indicates the AH
authentication
algorithm used
by an IPSec
proposal. IPSec
can use hashed
message
authentication
code (HMAC)
or cipher block
chainingmessage
authentication
code (CBCMAC) for
identity
authentication
and data
integrity check.
For details about
HMAC, see
RFC4306.
HMAC
currently
supports three
hash functions:
message digest
algorithm 5
(MD5), secure
hash algorithm 1
(SHA1), and
secure hash
algorithm 256
(SHA256). The
three hash
functions verify
data by means of
integrity
protection.
Among them,
SHA256
provides the
highest security
level and MD5
provides the
lowest security
level. For details
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IPSECPROPOS
AL
LST
IPSECPROPOS
AL
Issue 02 (2013-07-30)

178
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
about the hash
functions, see
RFC2409. CBCMAC currently
supports AESXCBCMAC-96, which
is an
enhancement to
CBC-MAC. For
details about
AES-XCBCMAC-96, see
RFC3566.
GUI Value
Range:MD5
(MD5), SHA1
(SHA1), AESXCBCMAC-96(AESXCBCMAC-96),
SHA256
(SHA256)
Unit:None
Actual Value
Range:MD5,
SHA1, AESXCBCMAC-96,
SHA256
Default
Value:SHA1
(SHA1)
Issue 02 (2013-07-30)

179
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
ESPAUTHALG
BTS3900
ADD
IPSECPROPOS
AL
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IPSECPROPOS
AL
GBFD-113524
Meaning:Indicates the ESP

authentication
algorithm used
by an IPSec
proposal. If this
parameter is set
to NULL, the
following
algorithms are
not used: MD5,
SHA1,
SHA256, and
AES-XCBCMAC-96.
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IPSECPROPOS
AL
LST
IPSECPROPOS
AL
GUI Value
Range:NULL
(NULL), MD5
(MD5), SHA1
(SHA1), AESXCBCMAC-96(AESXCBCMAC-96),
SHA256
(SHA256)
Unit:None
Actual Value
Range:NULL,
MD5, SHA1,
AES-XCBCMAC-96,
SHA256
Default
Value:SHA1
(SHA1)
Issue 02 (2013-07-30)

180
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
ESPENCALG
BTS3900
ADD
IPSECPROPOS
AL
LOFD-003009 /
TDLOFD-0030
09
IPsec
MOD
IPSECPROPOS
AL
GBFD-113524
encryption
algorithm used
in ESP. The
Data Encryption
Standard (DES)
is an
internationally
used data
encryption
algorithm,
which uses a 56bit key. The
3DES is also an
internationally
used encryption
algorithm,
which uses a
168-bit key. The
Advanced
Encryption
Standard (AES)
is an advanced
encryption
algorithm,
which can use
three types of
keys of different
lengths: 128,
192, and 256
bits. Therefore,
different
protection levels
are available.
For details, see
RFC2401.
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
DSP
IPSECPROPOS
AL
LST
IPSECPROPOS
AL
GUI Value
Range:NULL
(NULL), DES
(DES), 3DES
(3DES),
AES128
(AES128),
AES192
(AES192),
Issue 02 (2013-07-30)

181
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
AES256
(AES256)
Unit:None
Actual Value
Range:NULL,
DES, 3DES,
AES128,
AES192,
AES256
Default
Value:AES128
(AES128)
ACLID
BTS3900
ADD
IPSECPOLICY
MOD
IPSECPOLICY
DSP
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPOLICY
the access
control list.
GUI Value
Range:
3000~3999
Unit:None
Actual Value
Range:
3000~3999
Default
Value:None
PROPNAME
BTS3900
ADD
IPSECPOLICY
MOD
IPSECPOLICY
DSP
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPOLICY

of the IPSec
proposal.
GUI Value
Range:1~15
characters
Unit:None
Actual Value
Range:1~15
characters
Default
Value:None
Issue 02 (2013-07-30)

182
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
PEERNAME
BTS3900
ADD
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
IPsec

of the IKE peer
that is
referenced by
the IPSec policy.
MOD
IPSECPOLICY
DSP
IPSECPOLICY
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPOLICY
GUI Value
Range:1~15
characters
Unit:None
Actual Value
Range:1~15
characters
Default
Value:None
Issue 02 (2013-07-30)

183
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
PFS
BTS3900
ADD
IPSECPOLICY
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the perfect

forward secrecy
(PFS) value. In
the second phase
of IPSec
negotiation, PFS
enables the BS
to use a key that
is not derived
from the firstphase key,
ensuring that the
two keys are
independent of
each other.
According to
PFS, a key
protects a
unique set of
data. The
elements used to
generate keys
are not reusable.
If a key is
decrypted, other
keys are still
secure. If the
IPSec policy is
used to initiate
IPSec
negotiation, a
PFS exchange is
launched. If the
PFS is assigned
to the local end,
then the PFS
exchange is
required when
the negotiation
is launched at
the peer end.
The DH group
assigned to the
local end and the
peer end should
be the same.
Otherwise, the
MOD
IPSECPOLICY
DSP
IPSECPOLICY
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
LST
IPSECPOLICY
Issue 02 (2013-07-30)

184
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
negotiation fails.
The security
level of the
1024-bit DiffieHellman group
(Dh-group2) is
higher than that
of the 768-bit
Diffie-Hellman
group (Dhgroup1).
However, a
longer
processing time
is required by
the Dh-group2.
GUI Value
Range:DISABL
E(Disable),
PFS_GROUP1
Group),
PFS_GROUP2
(1024-bit DiffieHellman Group)
Unit:None
Actual Value
Range:DISABL
E,
PFS_GROUP1,
PFS_GROUP2
Default
Value:DISABL
E(Disable)
Issue 02 (2013-07-30)

185
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
CN
BTS3900
ADD
IPSECBIND
None
None
Meaning:Indicates the cabinet

number of the
port to which the
IPSec policy
group is bound.
MOD
IPSECBIND
RMV
IPSECBIND
GUI Value
Range:0~7
LST
IPSECBIND
Unit:None
Actual Value
Range:0~7
Default Value:0
SRN
BTS3900
ADD
IPSECBIND
None
None
RMV
IPSECBIND
subrack number
of the port to
which the IPSec
policy group is
bound.
LST
IPSECBIND
GUI Value
Range:0~1
MOD
IPSECBIND
Unit:None
Actual Value
Range:0~1
Default Value:0
SN
BTS3900
ADD
IPSECBIND
None
None
MOD
IPSECBIND
RMV
IPSECBIND
LST
IPSECBIND
Meaning:Indicates the slot

number of the
port to which the
IPSec policy
group is bound.
GUI Value
Range:0~7
Unit:None
Actual Value
Range:0~7
Default
Value:None
Issue 02 (2013-07-30)

186
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SBT
BTS3900
ADD
IPSECBIND
None
None

sub-board on the
board with the
port to which the
IPSec policy
group is bound.
MOD
IPSECBIND
RMV
IPSECBIND
LST
IPSECBIND
GUI Value
Range:BASE_B
OARD(Base
Board),
ETH_COVERB
OARD(Ethernet
Cover Board)
Unit:None
Actual Value
Range:BASE_B
OARD,
ETH_COVERB
OARD
Default
Value:None
PT
BTS3900
ADD
IPSECBIND
MOD
IPSECBIND
RMV
IPSECBIND
LOFD-003009
IPsec
GBFD-113524
BTS Integrated
Ipsec
WRFD-140209
NodeB
Integrated IPSec
LST
IPSECBIND

port to which the
IPSec policy
group is bound.
GUI Value
Range:ETH
(Ethernet Port),
ETHTRK
(Ethernet
Trunk)
Unit:None
Actual Value
Range:ETH,
ETHTRK
Default
Value:None
Issue 02 (2013-07-30)

187
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
PN
BTS3900
ADD
IPSECBIND
LOFD-003009
IPsec
GBFD-113524
BTS Integrated
Ipsec
Meaning:Indicates the number

of the port to
which the IPSec
policy group is
bound.
MOD
IPSECBIND
WRFD-140209
NodeB
Integrated IPSec
RMV
IPSECBIND
GUI Value
Range:0~5
LST
IPSECBIND
Unit:None
Actual Value
Range:0~5
Default
Value:None
SPGN
BTS3900
ADD
IPSECBIND
LST
IPSECBIND
LOFD-003009
Ipsec
GBFD-113524
BTS Integrated
Ipsec
WRFD-140209
NodeB
Integrated IPSec

of the IPSec
policy group.
GUI Value
Range:1~15
characters
Unit:None
Actual Value
Range:1~15
characters
Default
Value:None
Issue 02 (2013-07-30)

188
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
IKEKLI
BTS3900
SET IKECFG
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the time

interval for
sending the
keepalive
packets. If the
parameter is set
to 0, keepalive
packets are not
sent.
DSP IKECFG
LST IKECFG
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:
0,20~28800
Unit:s
Actual Value
Range:
0,20~28800
Default Value:0
IKEKLT
BTS3900
SET IKECFG
DSP IKECFG
LST IKECFG
LOFD-003009 /
TDLOFD-0030
09
GBFD-113524
WRFD-140209
IPsec
BTS Integrated
Ipsec
NodeB
Integrated IPSec
Meaning:Indicates the timeout

duration for
waiting for the
keepalive
packets. If this
parameter is set
to 0, keepalive
packets are not
sent.
GUI Value
Range:
0,60~28800
Unit:s
Actual Value
Range:
0,60~28800
Default Value:0
Issue 02 (2013-07-30)

189
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DSCP
BTS3900
SET IKECFG
LOFD-003009 /
TDLOFD-0030
09
IPsec
Meaning:Indicates the DSCP

for IKE
negotiation
packets.
DSP IKECFG
LST IKECFG
GBFD-113524
WRFD-140209
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:
48
IPSECREPLAY
CHKSW
BTS3900
SET IPGUARD
LST IPGUARD
LOFD-003014 /
TDLOFD-0030
14
Integrated
Firewall
report IPSec
packet replay
alarm.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:DISABL
E(Disable)
IPSECREPLAYALMTH
D
BTS3900
SET IPGUARD
LST IPGUARD
LOFD-003014 /
TDLOFD-0030
14
Integrated
Firewall
Meaning:Indicates the IPSec

anti-replay
alarm threshold.
GUI Value
Range:
1~100000
Unit:packet/s
Actual Value
Range:
1~100000
Default Value:
100
Issue 02 (2013-07-30)

190
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
CN
BTS3900
ADD
BFDSESSION
None
None
Meaning:Indicates the cabinet

No. to which a
BFD session
belongs.
DSP
BFDSESSION
MOD
BFDSESSION
GUI Value
Range:0~7
RMV
BFDSESSION
Unit:None
Actual Value
Range:0~7
LST
BFDSESSION
Default Value:0
SRN
BTS3900
ADD
BFDSESSION
None
None
DSP
BFDSESSION
MOD
BFDSESSION
subrack No. to
which a BFD
session belongs.
GUI Value
Range:0~1
RMV
BFDSESSION
Unit:None
Actual Value
Range:0~1
LST
BFDSESSION
Default Value:0
SN
BTS3900
ADD
BFDSESSION
None
None
DSP
BFDSESSION
Meaning:Indicates the slot No.

to which a BFD
session belongs.
MOD
BFDSESSION
GUI Value
Range:0~7
RMV
BFDSESSION
Unit:None
LST
BFDSESSION
Issue 02 (2013-07-30)

Actual Value
Range:0~7
Default
Value:None
191
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
BFDSN
BTS3900
ADD
BFDSESSION
WRFD-050403
Hybrid Iub IP
Transmission
BFD session.
The session ID
plus 1 is the local
discriminator of
the BFD session.
The local
discriminator
must be
consistent with
the
configuration at
the peer side.
DSP
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
MOD
BFDSESSION
GBFD-118601
RMV
BFDSESSION
Bidirectional
Forwarding
Detection
Abis over IP
LST
BFDSESSION
GUI Value
Range:0~95
Unit:None
Actual Value
Range:0~95
Default
Value:None
Issue 02 (2013-07-30)

192
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
SRCIP
BTS3900
ADD
BFDSESSION
WRFD-050403
Hybrid Iub IP
Transmission

IP address of the
BFD session.
The source IP
address of a
BFD session
must be a device
IP address of a
specified board
(for example,
the IP address of
an Ethernet port
or a port that
carries a PPP
link or MP
group) or a
logical IP
address (for
example, the IP
address of a
loopback port),
but cannot be set
to the same
value as the IP
address of a
remote
maintenance
channel or a
negotiated IP
address. Note
that a BFD
session cannot
be configured as
a single-hope
session if its
source IP
address is a
logical IP
address.
MOD
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
DSP
BFDSESSION
GBFD-118601
LST
BFDSESSION
Bidirectional
Forwarding
Detection
Abis over IP
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Issue 02 (2013-07-30)

193
SingleRAN
Parameter ID
NE
11 Parameters
MML
Command
Feature ID
Feature Name
Description
Default
Value:None
DSTIP
BTS3900
ADD
BFDSESSION
WRFD-050403
MOD
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
DSP
BFDSESSION
GBFD-118601
LST
BFDSESSION
Hybrid Iub IP
Transmission
Bidirectional
Forwarding
Detection
Abis over IP
destination IP
address of a
BFD session.
The destination
IP address must
be a valid IP
address, and
cannot be set to
0.0.0.0 or any
existing IP
addresses in the
system. If
Virtual Router
Redundancy
Protocol
(VRRP) is used
in the network,
two BFD
sessions must be
configured with
the destination
IP addresses set
to the active and
standby physical
IP addresses of
the virtual
router,
respectively.
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Default
Value:None
Issue 02 (2013-07-30)

194
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
HT
BTS3900
ADD
BFDSESSION
WRFD-050403
Hybrid Iub IP
Transmission
Meaning:Indicates the hop

type of the BFD
session. The
single-hop BFD
session is used to
perform pointto-point
detection at the
data link layer,
and often used in
layer 2
networking
scenarios. The
multi-hop BFD
session is used to
perform end-toend connectivity
checks at the
transport layer,
and often used in
layer 3
networking
scenarios.
MOD
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
DSP
BFDSESSION
GBFD-118601
LST
BFDSESSION
Bidirectional
Forwarding
Detection
Abis over IP
GUI Value
Range:SINGLE
_HOP(Single
Hop),
MULTI_HOP
(Multiple Hops)
Unit:None
Actual Value
Range:SINGLE
_HOP,
MULTI_HOP
Default
Value:None
Issue 02 (2013-07-30)

195
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
MINTI
BTS3900
ADD
BFDSESSION
WRFD-050403
Hybrid Iub IP
Transmission
minimum
interval at which
the BFD session
transmits
control packets.
MOD
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
DSP
BFDSESSION
GBFD-118601
Bidirectional
Forwarding
Detection
Abis over IP
LST
BFDSESSION
GUI Value
Range:10~1000
Unit:ms
Actual Value
Range:10~1000
Default Value:
100
MINRI
BTS3900
ADD
BFDSESSION
WRFD-050403
MOD
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
DSP
BFDSESSION
GBFD-118601
Hybrid Iub IP
Transmission
Bidirectional
Forwarding
Detection
Abis over IP
LST
BFDSESSION
minimum
interval at which
the BFD session
receives control
packets.
GUI Value
Range:10~1000
Unit:ms
Actual Value
Range:10~1000
Default Value:
100
DM
BTS3900
ADD
BFDSESSION
WRFD-050403
MOD
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
DSP
BFDSESSION
GBFD-118601
LST
BFDSESSION
Hybrid Iub IP
Transmission
Bidirectional
Forwarding
Detection
Abis over IP
detection
multiplier of a
BFD session.
GUI Value
Range:3~10
Unit:None
Actual Value
Range:3~10
Default Value:3
Issue 02 (2013-07-30)

196
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
CATLOG
BTS3900
ADD
BFDSESSION
WRFD-050403
Hybrid Iub IP
Transmission

the BFD session.
If this parameter
is set to
MAINTENAN
CE, this BFD
session is used
only for
continuity check
(CC). If this
parameter is set
to
RELIABILITY,
the BFD session
is used to trigger
route interlock.
Route interlock
enables the
standby route to
take over once
the active route
becomes faulty,
and therefore
prevents service
interruption
caused by route
failures.
MOD
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
DSP
BFDSESSION
GBFD-118601
LST
BFDSESSION
Bidirectional
Forwarding
Detection
Abis over IP
GUI Value
Range:MAINT
ENANCE
(Maintenance),
RELIABILITY
(Reliability)
Unit:None
Actual Value
Range:MAINT
ENANCE,
RELIABILITY
Default
Value:RELIABI
LITY
(Reliability)
Issue 02 (2013-07-30)

197
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DSCP
BTS3900
ADD
BFDSESSION
WRFD-050403
Hybrid Iub IP
Transmission
Differentiated
Services Code
Point (DSCP).
The priority has
a positive
correlation with
the value of this
parameter.
LST
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
GBFD-118601
Bidirectional
Forwarding
Detection
Abis over IP
GUI Value
Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:
48
VER
BTS3900
ADD
BFDSESSION
WRFD-050403
MOD
BFDSESSION
LOFD-003007 /
TDLOFD-0030
07
LST
BFDSESSION
GBFD-118601
Hybrid Iub IP
Transmission
Bidirectional
Forwarding
Detection
Abis over IP
protocol version
of a BFD
session.
GUI Value
Range:DRAFT4
(DRAFT4),
STANDARD
(STANDARD)
Unit:None
Actual Value
Range:DRAFT4
, STANDARD
Default
Value:DRAFT4
(DRAFT4)
Issue 02 (2013-07-30)

198
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
DUALID
BTS3900
ADD
IPSECDTNL
LOFD-003019/
TDLOFD-0030
19
IPsec Tunnel
Backup
the IPSec tunnel
pair. It uniquely
identifies a pair
of primary and
secondary IPSec
tunnels.
DSP
IPSECDTNL
LST
IPSECDTNL
GBFD-113524
WRFD-140209
MOD
IPSECDTNL
BTS Integrated
Ipsec
NodeB
Integrated IPSec
GUI Value
Range:0~49
RMV
IPSECDTNL
Unit:None
Actual Value
Range:0~49
Default
Value:None
MBFDSN
BTS3900
ADD
IPSECDTNL
MOD
IPSECDTNL
DSP
IPSECDTNL
LOFD-003019/
TDLOFD-0030
19
GBFD-113524
WRFD-140209
LST
IPSECDTNL
IPsec Tunnel
Backup
BTS Integrated
Ipsec
NodeB
Integrated IPSec
the BFD session
referenced by
the primary
IPSec tunnel.
GUI Value
Range:0~95
Unit:None
Actual Value
Range:0~95
Default
Value:None
SBFDSN
BTS3900
ADD
IPSECDTNL
MOD
IPSECDTNL
DSP
IPSECDTNL
LST
IPSECDTNL
LOFD-003019/
TDLOFD-0030
19
GBFD-113524
WRFD-140209
IPsec Tunnel
Backup
BTS Integrated
Ipsec
NodeB
Integrated IPSec
the BFD session
referenced by
the secondary
IPSec tunnel.
GUI Value
Range:0~95
Unit:None
Actual Value
Range:0~95
Default
Value:None
Issue 02 (2013-07-30)

199
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
IKEVERSION
BTS3900
ADD
SECURITYTE
MPLATE
WRFD-050402
IP Transmission
Introduction on
Iub Interface
MOD
SECURITYTE
MPLATE
GBFD-118601

protocol
version.
LST
SECURITYTE
MPLATE
WRFD-140209
GBFD-113524
LOFD-002004 /
TDLOFD-0020
04
LOFD-003009 /
TDLOFD-0030
09
NodeB
Integrated IPSec
Abis over IP
BTS Integrated
Ipsec
Selfconfiguration
Ipsec
GUI Value
Range:IKE_V1
(IKE V1),
IKE_V2(IKE
V2)
Unit:None
Actual Value
Range:IKE_V1,
IKE_V2
Default
Value:IKE_V2
(IKE V2)
Issue 02 (2013-07-30)

200
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
EXCHMODE
BTS3900
ADD
SECURITYTE
MPLATE
WRFD-050402
IP Transmission
Introduction on
Iub Interface
MOD
SECURITYTE
MPLATE
GBFD-118601
Meaning:Indicates the IKE V1

exchange mode.
There are two
exchange
modes: main
mode and
aggressive
mode. In main
mode, keys are
exchanged
separately from
identity
information,
which protects
identity
information and
hence enhances
security. In
aggressive
mode, identity
information is
not protected,
but
requirements of
specific network
environments
can be met.
LST
SECURITYTE
MPLATE
WRFD-140209
GBFD-113524
LOFD-002004 /
TDLOFD-0020
04
LOFD-003009 /
TDLOFD-0030
09
NodeB
Integrated IPSec
Abis over IP
BTS Integrated
Ipsec
Selfconfiguration
Ipsec
GUI Value
Range:MAIN
(Main Mode),
AGGRESSIVE
(Aggressive
Mode)
Unit:None
Actual Value
Range:MAIN,
AGGRESSIVE
Default
Value:MAIN
(Main Mode)
Issue 02 (2013-07-30)

201
SingleRAN
11 Parameters
Parameter ID
NE
MML
Command
Feature ID
Feature Name
Description
BYPASSSWIT
CH
BTS3900
SET
IPSECBYPASS
CFG
None
None
enable the
switchover of
IPSec Bypass. If
this parameter is
set to
DISABLE, the
base station
cannot switch
between an
IPSec network
and a non-IPSec
network.
DSP
IPSECBYPASS
CFG
LST
IPSECBYPASS
CFG
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:DISABL
E(Disable)
Issue 02 (2013-07-30)

202
SingleRAN
12 Counters
12
Counters
Table 12-1 UMTS: Counter description

Counter ID
Counter Name
Counter
Description
NE
Feature ID
Feature Name
1542460340
VS.IKE.RxPackets
Number of IKE
packets received
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
1542460341
VS.IKE.TxPackets
Number of IKE
packets transmitted
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
Issue 02 (2013-07-30)

203
SingleRAN
12 Counters
Counter ID
Counter Name
Counter
Description
NE
Feature ID
Feature Name
1542460342
VS.IKE.SubSAReke
y.Times
Times of IKE sub

SA rekey completed
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
1542460343
VS.IKE.DPDSession
Fail.Times
Times of DPD
session fail
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
1542460344
VS.IPSec.RxCheckReplayFailDropPkts
Number of
discarded packets
received due to
replay checking fail
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
1542460345
VS.IPSec.RxAHCheckFailDropPkts
Number of
discarded packets
received due to AH
checking fail
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
Issue 02 (2013-07-30)

204
SingleRAN
12 Counters
Counter ID
Counter Name
Counter
Description
NE
1542460346
VS.IPSec.RxESPFailDropPkts
Number of
NodeB
discarded packets
received due to ESP
fail
Feature ID
Feature Name
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
1542460347
VS.IPSec.RxDecryptACLFailDropPkts
Number of
discarded packets
received due to
decrypt ACL fail
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
1542460348
VS.IPSec.RxDecryptSuccessPkts
Number of decrypt
success packets
received
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
1542460349
VS.IPSec.TxOutboundSAMissDropPkts
Number of
discarded packets
transmitted due to
outbound SA miss
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
Issue 02 (2013-07-30)

205
SingleRAN
12 Counters
Counter ID
Counter Name
Counter
Description
NE
Feature ID
Feature Name
1542460350
VS.IPSec.TxAntiReplaySnWrappedDropPkts
Number of
discarded packets
transmitted due to
sequence number
overflow
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
1542460351
VS.IPSec.TxEncryptSuccessPkts
Number of encrypt
success packets
transmitted
NodeB
Multi-mode:
None
BTS Integrated
IPsec
GSM:
GBFD-113524
NodeB
Integrated IPsec
UMTS:
WRFD-140209
IPsec
IPsec
LTE:
LOFD-003009
TDLOFD-0030
09
Issue 02 (2013-07-30)

206
SingleRAN
13 Glossary
13
Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.
Issue 02 (2013-07-30)

207
SingleRAN
14 Reference Documents
14
Reference Documents
1.
IETF RFC 2401,2403,2404, 2409
2.
IETF RFC 4301,4302, 4303, 4304, 4306
3.
IETF RFC 3706
4.
PKI Feature Parameter Description for SingleRAN
5.
Automatic OMCH Establishment Feature Parameter Description for SingleRAN
6.
IP Transport Architecture Feature Parameter Description for GSM BSS and WCDMA
RAN
7.
3900 Series Base Station Initial Configuration Guide
8.
3900 Series Base Station Alarm Reference
9.
BSC6900 Alarm Reference
10. BSC6910 Alarm Reference
Issue 02 (2013-07-30)

208

IPsec (SRAN8.0 02)

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IPsec (SRAN8.0 02)

Încărcat de

Drepturi de autor:

Formate disponibile

SingleRAN

IPsec Feature Parameter Description

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

4 IKE Working Principles.............................................................................................................15

6 IEEE 1588v2 over IPsec...............................................................................................................23

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

10.8.2 Reconstruction from an Insecure Network to a PSK-based Secure Network.......................................................117

Huawei Proprietary and Confidential

1 About This Document

About This Document

GBFD-113524 BTS Integrated IPsec

WRFD-140209 NodeB Integrated IPSec

MRFD-211602 Co-IPSec Between GSM, UMTS and LTE (GSM)

MRFD-221602 Co-IPSec Between GSM, UMTS and LTE (UMTS)

MRFD-231602 Co-IPSec Between GSM, UMTS and LTE (LTE)

GBTS refers to a base station deployed with GTMU.

eGBTS refers to a base station deployed with UMPT_G.

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

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

Huawei Proprietary and Confidential

1 About This Document

Co-MPT multimode base station refers to a base station deployed with

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

1.2 Intended Audience

Need to understand the features described herein

Work with Huawei products

1.3 Change History

Deleted the descriptions of IPsec supported by micro

Huawei Proprietary and Confidential

1 About This Document

Implemented IPsec on micro base stations.

Added IPsec deployment scenarios for

Added the IEEE 1588v2 over IPsec

Added descriptions of the IPsec security

Revised descriptions of IKEv1

Added descriptions of the Diffie-Hellman

Simplified the base station deployment

Huawei Proprietary and Confidential

1 About This Document

Modified the application of IPsec on base

Modified the description of IPsec-related

Revised IPsec engineering guidelines, and

Huawei Proprietary and Confidential

Authenticity: The IPsec entity authenticates the data source.

Huawei Proprietary and Confidential

Figure 2-1 Secure network

Huawei Proprietary and Confidential

3 IPsec Working Principles

IPsec Working Principles

3.1 Security Association

Key for data protection and key lifetime

Huawei Proprietary and Confidential

3 IPsec Working Principles

Figure 3-1 Example of an IPsec SA

3.2 IPsec Policies

Access control list (ACL)

Huawei Proprietary and Confidential