Automatic OMCH Establishment (SRAN12.1 - 01)

SingleRAN
Automatic OMCH Establishment

Feature Parameter Description
Issue 01
Date 2017-03-08
HUAWEI TECHNOLOGIES CO., LTD.

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

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2017-03-08) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
SingleRAN
Automatic OMCH Establishment Feature Parameter
Description Contents
Contents
1 About This Document.................................................................................................................. 1

1.1 Scope.............................................................................................................................................................................. 1
1.2 Intended Audience.......................................................................................................................................................... 1
1.3 Change History............................................................................................................................................................... 1
1.4 Differences Between Base Station Types....................................................................................................................... 2
1.5 Functional Differences Between NB-IoT and FDD....................................................................................................... 3
2 Overview......................................................................................................................................... 4
2.1 Introduction.................................................................................................................................................................... 4
2.2 Benefits........................................................................................................................................................................... 6
2.3 Application Networking Scenarios.................................................................................................................................6
3 IP-based Automatic OMCH Establishment for Base Stations..............................................8

3.1 OMCH Protocol Stacks.................................................................................................................................................. 8
3.1.1 Non-IPsec Networking Scenario................................................................................................................................. 8
3.1.2 IPsec Networking Scenario......................................................................................................................................... 9
3.2 Base Station Obtaining Transmission Configuration Information............................................................................... 12
3.2.1 Transmission Mode of the OMCH............................................................................................................................ 12
3.2.2 Physical Layer Detection...........................................................................................................................................12
3.2.3 Data Link Layer Detection........................................................................................................................................ 13
3.2.4 DHCP Overview........................................................................................................................................................15
3.2.4.1 Introduction............................................................................................................................................................ 15
3.2.4.2 DHCP Interworking................................................................................................................................................16
3.2.4.3 DHCP Packet Format............................................................................................................................................. 17
3.2.5 DHCP Clients and Servers........................................................................................................................................ 19
3.2.6 DHCP Procedure....................................................................................................................................................... 21
3.2.6.1 Base Station Identification......................................................................................................................................21
3.2.6.2 Obtaining Configuration Information in Non-IPsec Networking Scenarios.......................................................... 22
3.2.6.3 Obtaining Configuration Information in IPsec Networking Scenarios.................................................................. 23
3.2.6.4 Releasing Allocated Configuration Information.................................................................................................... 25
3.2.7 Automatic DHCP Data Synchronization................................................................................................................... 25
3.2.8 Obtaining VLAN Information for DHCP Packets.................................................................................................... 26
3.2.8.1 Overview................................................................................................................................................................ 26
3.2.8.2 Scheme 1.................................................................................................................................................................28
Issue 01 (2017-03-08) Huawei Proprietary and Confidential ii

SingleRAN
3.2.8.3 Scheme 2.................................................................................................................................................................30

3.2.8.4 Scheme 3.................................................................................................................................................................31
3.2.8.5 Scheme 4.................................................................................................................................................................31
3.2.8.6 Enabling and Disabling the VLAN Scanning Function......................................................................................... 32
3.2.8.7 Saving VLAN IDs.................................................................................................................................................. 33
3.3 Automatic OMCH Establishment by Single-mode Base Station and Co-MPT Multimode Base Station................... 33
3.3.1 Overview................................................................................................................................................................... 33
3.3.2 Automatic OMCH Establishment in Non-IPsec Networking Scenarios................................................................... 33
3.3.2.1 Introduction to Non-IPsec Networking.................................................................................................................. 34
3.3.2.2 Automatic OMCH Establishment Procedure......................................................................................................... 34
3.3.2.3 Configuration Requirements for the DHCP Server................................................................................................ 35
3.3.2.4 SSL Authentication on the OMCH.........................................................................................................................45
3.3.2.5 Obtaining an Operator-Issued Device Certificate...................................................................................................47
3.3.2.6 Configuration Requirements for Network Equipment........................................................................................... 49
3.3.3 Automatic OMCH Establishment in IPsec Networking Scenario 1..........................................................................50
3.3.3.1 Introduction to IPsec Networking Scenario 1.........................................................................................................50
3.3.3.3 Configuration Requirements for the Public DHCP Server.....................................................................................53
3.3.3.4 Obtaining an Operator-Issued Device Certificate...................................................................................................58
3.3.3.5 Establishing a Temporary IPsec Tunnel................................................................................................................. 59
3.3.3.6 Configuration Requirements for the Internal DHCP Server...................................................................................62
3.3.3.7 Obtaining Formal Transmission Configuration Information from the Internal DHCP Server...............................63
3.3.3.8 Establishing a Formal IPsec Tunnel....................................................................................................................... 69
3.3.3.9 Establishing an OMCH...........................................................................................................................................69
3.3.3.10 Configuration Requirements for Network Equipment......................................................................................... 69
3.4 Automatic OMCH Establishment by the Separate-MPT Multimode Base Station......................................................80
3.4.1 Networking................................................................................................................................................................ 80
3.4.2 Automatic OMCH Establishment Procedure............................................................................................................ 81
3.4.3 Configuration Requirements for the DHCP Server................................................................................................... 82
3.4.4 Configuration Requirements for Network Equipment.............................................................................................. 84
3.5 Application Restrictions............................................................................................................................................... 89
3.5.1 Configuration Requirements for Base Stations and Other Network Equipment.......................................................89
Issue 01 (2017-03-08) Huawei Proprietary and Confidential iii

SingleRAN
3.5.2 Impact of U2000 Deployment on Base Station Deployment by PnP........................................................................93
4 ATM-based Automatic OMCH Establishment for Base Stations......................................99

4.1 Overview...................................................................................................................................................................... 99
4.2 Principles...................................................................................................................................................................... 99
4.2.1 Port Listening.......................................................................................................................................................... 100
4.2.2 Port Configuration................................................................................................................................................... 101
4.2.3 PVC Setup and BOOTP Request Initiation............................................................................................................. 101
4.2.4 RNC Returning the BOOTREPLY Message........................................................................................................... 101
4.2.5 IPoA Configuration................................................................................................................................................. 102
4.3 Configuration Guidelines........................................................................................................................................... 102
5 TDM-based Base Station Automatic OMCH Establishment............................................103

5.1 Introduction................................................................................................................................................................ 103
5.2 Process........................................................................................................................................................................ 103
5.2.1 Sending L2ML Establishment Requests..................................................................................................................104
5.2.2 Saving Detection Information................................................................................................................................. 105
6 Related Features.........................................................................................................................106
7 Network Impact......................................................................................................................... 107
8 Parameters................................................................................................................................... 108
9 Counters...................................................................................................................................... 122
10 Glossary..................................................................................................................................... 123
11 Reference Documents............................................................................................................. 124
Issue 01 (2017-03-08) Huawei Proprietary and Confidential iv

SingleRAN
Description 1 About This Document
1 About This Document
1.1 Scope
This document describes the Automatic OMCH Establishment, including its implementation
principles, procedures, and requirements for NEs.
This document covers the following features:
l WRFD-031100 BOOTP
l WRFD-031101 NodeB Self-discovery Based on IP Mode
l LBFD-002035 Self-configuration
l TDLBFD-002036 Self-configuration
l MLBFD-12000241 Self-configuration
For definitions of base stations described in this document, see section "Base Station
Products" in SRAN Networking and Evolution Overview Feature Parameter Description.
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the features described herein
l Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions. There are
two types of changes, which are defined as follows:
l Feature change
Changes in features of a specific product version
l Editorial change
Changes in wording or addition of information that was not described in the earlier
version
Issue 01 (2017-03-08) Huawei Proprietary and Confidential 1

SingleRAN
SRAN12.1 01 (2017-03-08)
This issue does not include any changes.
SRAN12.1 Draft A (2016-12-30)

Draft A (2016-12-30) of SRAN12.1 introduces the following changes to Issue 01
(2016-02-29) of SRAN11.1.
Change Change Description Parameter Change

Type
Feature Added support for NB-IoT. For details, see None

change related descriptions in the document.
Editorial None None

change
1.4 Differences Between Base Station Types

Feature Support by Macro, Micro, and LampSite Base Stations
Feature ID Feature Name Suppo Suppo Suppo
rted rted rted
by by by
Macro Micro Lamp
Sites Sites Site
Sites
WRFD-031100 BOOTP Yes No Yes
WRFD-031101 NodeB Self-discovery Based on IP Yes Yes Yes

Mode
LBFD-0020035 Self-configuration (for LTE FDD) Yes Yes Yes
TDLBFD-002036 Self-configuration (for LTE TDD) Yes No No
MLBFD-12000241 Self-configuration (for NB-IoT) Yes No No
Function Implementation in Macro, Micro, and LampSite Base Stations

Function Difference
Automatic data Micro base stations do not support automatic data

synchronization by synchronization through the DHCP process.
DHCP

SingleRAN
1.5 Functional Differences Between NB-IoT and FDD

There are no functional differences between NB-IoT and FDD.

SingleRAN
Description 2 Overview
2 Overview
2.1 Introduction
Operation and maintenance channels (OMCHs) are established between base stations and the
operation maintenance center (OMC, either the U2000 or BSC). OMCHs are used to transmit
operation and maintenance information about base stations and are classified as follows:
l OMCH between the single-mode base station (such as the eGBTS, NodeB, or eNodeB)
and the U2000, or between the GBTS and the BSC
l OMCH between the co-MPT multimode base station and the U2000
l OMCHs between the separate-MPT base station and the U2000. For example, the
OMCHs for the separate-MPT UMTS/LTE dual-mode base station include the OMCH
between the NodeB and the U2000, as well as the OMCH between the eNodeB and the
U2000.
l OMCH between the U2000 and the NodeB on the ATM-based network
NOTE
One end of an OMCH is located at the main control board of a base station. Depending on the
configuration of the main control board, multimode base stations are classified into co-MPT multimode
and separate-MPT multimode base stations. For co-MPT multimode base stations, GSM, UMTS, and
LTE modes share the same main control board and OMCH. For separate-MPT multimode base stations,
GSM, UMTS, and LTE modes have individual main control boards and OMCHs.
In this document, the term base station is universally used for GBTS, eGBTS, NodeB, eNodeB,separate-
MPT multimode base station, and co-MPT multimode base station if differentiation among GSM,
UMTS, and LTE is not required. A GBTS, eGBTS, NodeB, eNodeB, co-MPT multimode, or separate-
MPT multimode base station is used if differentiation among GSM, UMTS, and LTE modes is required.
In this document, the BSC is the OMC of a GBTS and the U2000 is the OMC of an eGBTS, NodeB,
eNodeB, separate-MPT multimode, or co-MPT multimode base station.
The Automatic OMCH Establishment feature enables a powered-on base station, which is
configured with hardware but no transmission information, to obtain OMCH configuration
information. This information is collected through the transport network and is used to
automatically establish an OMCH to the U2000 or BSC. The base station can then
automatically download software and configuration files/configuration data from the U2000
or BSC over the established OMCH and activate the software and configuration files/
configuration data. After being commissioned, the base station enters the working state. For
details, see 3900 & 5900 Series Base Station Commissioning Guide.

SingleRAN
This feature applies to base station deployment by PnP. Figure 2-1 shows the O&M path self-
establishment phase during deployment by PnP.
Figure 2-1 Automatic OMCH establishment phase during base station deployment by PnP
NOTE
This document only describes the procedures marked in the dashed box shown in Figure 2-1.
A base station must obtain the following transmission configuration data to establish an
OMCH:
l Basic information, including the following:

– OM IP address
– OM virtual local area network (VLAN) ID
– Interface IP address
– Interface IP address mask
– IP address of the next-hop gateway
– IP address of the U2000 or BSC
– IP address mask of the U2000 or BSC
l Security-related information, including the following:
– Certificate Authority (CA) name
– Transmission protocol (HTTP or HTTPS) used by the CA
– CA IP address
– CA port number

SingleRAN
– CA path
– IP address of the security gateway (SeGW)
– Name of the SeGW
Obtaining the operator's CA information is only required when the base station uses
digital certificates issued by the operator's CA to perform identity authentication with
other devices.
For details about how the base station obtains the preceding information, see 3.2 Base Station
Obtaining Transmission Configuration Information.
2.2 Benefits
With the Automatic OMCH Establishment feature, a base station can establish OMCHs by
network communication (not requiring local end operations). This implements remote base
station deployment by PnP, and facilitates base station deployment (cost and time).
2.3 Application Networking Scenarios

GBTSs support automatic OMCH establishment in TDM and IP networking scenarios.
NodeBs support automatic OMCH establishment in ATM and IP networking scenarios.
eNodeBs, and eGBTSs support automatic OMCH establishment in IP networking scenarios.
Table 2-1 describes the application networking scenarios for the Automatic OMCH
Establishment feature.
Table 2-1 Application networking scenarios
Networking Scenario Description
Non-IPsec in IP IPsec does not secure Dynamic Host Configuration Protocol

networking (DHCP) packets, OMCH data, service data, signaling data, or
clock data.
IPsec in IP networking IPsec secures DHCP packets, OM data, IPsec scenario 1

and all or a portion of other data.
IPsec secures OM data and all or a IPsec scenario 2

portion of other data. It does not secure
DHCP packets.
IPsec secures service data, signaling IPsec scenario 3

data, and all or a portion of other data.
It does not secure OM data.
ATM The OMCH between the NodeB and U2000 is configured over
ATM.
TDM The OMCH between the GBTS and BSC uses TDM
transmission. The OMCH is set up over E1 or T1 links.

SingleRAN
NOTE
In this document, the IPsec or non-IPsec networking indicates that the IP layer communication between
the base station and other devices is secured or not secured by IPsec, respectively.

SingleRAN
Automatic OMCH Establishment Feature Parameter 3 IP-based Automatic OMCH Establishment for Base
Description Stations
3 IP-based Automatic OMCH Establishment

for Base Stations
3.1 OMCH Protocol Stacks

OMCHs between the eGBTS, NodeB, eNodeB, or co-MPT multimode base station and the
U2000 are carried over Transmission Control Protocol (TCP). OMCHs between the GBTS
and the BSC are carried over User datagram protocol (UDP).
3.1.1 Non-IPsec Networking Scenario

Figure 3-1 shows the protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or
co-MPT multimode base station and the U2000.
Figure 3-1 Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT
multimode base station and the U2000.
As shown in Figure 3-1, an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT
multimode base station and the U2000 is carried over TCP and Secure Sockets Layer (SSL),
of which SSL is optional.
The eGBTS, NodeB, eNodeB, or co-MPT multimode base station listens to the TCP
connection establishment request with a specific TCP port number from the U2000, and
establishes the TCP connection to the U2000 as requested. After the TCP connection is

SingleRAN
established, the U2000 initiates an OMCH establishment request to the eGBTS, NodeB,
eNodeB, or co-MPT multimode base station.
The U2000 can use SSL to perform encryption and authentication for OMCHs and enable the
establishment of SSL-based OMCHs. SSL uses the public key infrastructure (PKI), with
which the communication between the base station and the U2000 is protected against
eavesdropping to provide guaranteed confidentiality and reliability. For details about SSL, see
SSL Feature Parameter Description for SingleRAN.
Figure 3-2 shows the protocol stacks for an OMCH between the GBTS and the BSC.
Figure 3-2 Protocol stacks for an OMCH between the GBTS and the BSC
As shown in Figure 3-2, an OMCH between the GBTS and the BSC is carried over UDP. The
GBTS listens to the UDP connection establishment request with a specific UDP port number
from the BSC, and establishes the UDP connection to the BSC as requested. After the UDP
connection is established, the BSC initiates an OMCH establishment request to the GBTS.
NOTE
During the OMCH establishment, the eGBTS, NodeB, eNodeB, or co-MPT multimode base station
listens to specific TCP port numbers, and the GBTS listens to UDP port numbers. For details, see
Communication Matrix of 3900 & 5900 Series Base Stations. The packets with these port numbers must
be allowed to pass through the firewall between the base station and the DHCP server, U2000, or BSC.
After establishing an OMCH to the U2000, the base station uses File Transmission Protocol (FTP) to
download software and configuration files from the FTP server. FTP runs over TCP/IP, and the transport
layer is secured using SSL. For details about FTP, see RFC 959. After establishing an OMCH to the
BSC, the GBTS uses the proprietary protocol that runs over UDP to download software and
configuration files from the BSC.
For the deployment policy of the DHCP server, see 3.2.5 DHCP Clients and Servers.
3.1.2 IPsec Networking Scenario

In IPsec networking scenarios, OMCH data can be secured or not secured by IPsec. Figure
3-3 shows the networking scenario in which IPsec secures OMCH data.

SingleRAN
Figure 3-3 Networking scenario in which IPsec secures OMCH data
As shown in Figure 3-3, the network is divided into the trusted and untrusted domains, which
are separated by the SeGW. Devices in the untrusted domain cannot access the devices in the
trusted domain. After a base station starts, an IPsec tunnel is established to the SeGW. Packets
from the base station are sent over the IPsec tunnel to the untrusted domain and then
forwarded by the SeGW to the U2000 or BSC in the trusted domain.
Figure 3-4 shows the protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or
co-MPT multimode base station and the U2000 in IPsec networking scenarios. Figure 3-5
shows the protocol stacks for an OMCH between the GBTS and the BSC.
Figure 3-4 Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT
multimode base station and the U2000 (IPsec networking)

SingleRAN
Figure 3-5 Protocol stacks for an OMCH between the GBTS and the BSC (IPsec networking)
NOTE
The protocol stacks shown in Figure 3-4 and Figure 3-5 only apply to IPsec networking scenarios.
Whether the base station supports IPsec depends on the base station type, software, and hardware
pertaining to the main control board.
IPsec networking is not supported by the following base stations:
l GBTS that uses the GTMU/GTMUc as the main control board
l eGBTS that uses the GTMUb/GTMUc as the main control board
l NodeB that uses the WMPT to provide transmission ports
In IPsec networking scenarios, IPsec secures base station data. IPsec is a security architecture
defined by the Internet Engineering Task Force (IETF) and applicable to the IP layer. IPsec
secures data communication by identity authentication, data encryption, data integrity, and
address encryption. During automatic OMCH establishment, the base station establishes an
IPsec tunnel to the SeGW and then an OMCH secured by the IPsec tunnel.
The base station uses two types of IP addresses:
l IP addresses that can be used to access an untrusted domain

Interface IP addresses for the base station to communicate with the SeGW
l IP addresses that can be used to access a trusted domain
IP addresses for the base station to communicate with the peer end such as the U2000,
BSC, or U2000 with an integrated DHCP server in the trusted domain
During site deployment, NEs in the trusted and untrusted domains may communicate with one
another. For example, a base station uses an interface IP address in the untrusted domain to
communicate with the DHCP server in the trusted domain. Alternatively, the DHCP relay in
the untrusted domain uses the IP address in the untrusted domain to communicate with the
DHCP server in the trusted domain. For details, see 3.3.3 Automatic OMCH Establishment
in IPsec Networking Scenario 1 and 3.3.4 Automatic OMCH Establishment in IPsec
Networking Scenario 2.

SingleRAN
The base station uses the interface IP address to access the untrusted domain. Unless
otherwise specified, the base station uses the logical IP address to access the trusted domain.
When using IPsec to secure data and digital certificates to perform identity authentication, an
operator must deploy the PKI. During automatic OMCH establishment, the base station
interworks with the operator's PKI using the Certificate Management Protocol (CMP) and
obtains the operator-issued device certificate and CA root certificate. The base station then
establishes an IPsec tunnel to the SeGW as well as the OMCH to which the new IPsec tunnel
provides security. For details about IPsec tunnels, see IPsec Feature Parameter Description
for SingleRAN. For details about digital certificate management, see PKI Feature Parameter
Description for SingleRAN.
When the operator uses IPsec to secure data and the pre-shared key (PSK) for identity
authentication, the base station fails to automatically establish an OMCH. In this case, it is
required to use other alternative methods to deploy the base station.
As an option, the U2000 can use SSL to perform encryption and authentication for OMCHs
and enable the establishment of SSL-based OMCHs. SSL uses the PKI, with which the
communication between the base station and the U2000 is protected against eavesdropping
and confidentiality and reliability are guaranteed. For details about SSL, see SSL Feature
Parameter Description for SingleRAN.
3.2 Base Station Obtaining Transmission Configuration

Information
3.2.1 Transmission Mode of the OMCH

A base station has two types of transmission ports: E1/T1 ports and Ethernet ports. E1/T1
ports support TDM, ATM, and IP over E1/T1 transmission modes, and Ethernet ports support
IP transmission mode. No transmission mode is configured on the base station before the
OMCH is established. The base station tries different transmission modes over the
transmission ports until the OMCH is successfully established.
eGBTS, NodeB, eNodeB, and co-MPT multimode base station try transmission modes in the
following sequence:
1. IP over FE/GE
2. ATM
3. IP over E1/T1
GBTS tries transmission modes in the following sequence:
1. TDM
2. IP over E1/T1
3. IP over FE/GE
3.2.2 Physical Layer Detection

A base station negotiates the duplex mode and data rate for an Ethernet port on the physical
layer with a peer transmission device. The peer transmission device can work in auto-
negotiation or full duplex mode.

SingleRAN
If an E1/T1 port is available on the physical layer, an eGBTS, NodeB, eNodeB, or co-MPT
multimode base station aims to set the working mode of a detection port to E1/T1 mode.
Users can also set the working mode of a detection port to E1/T1 mode for a GBTS by using
the related DIP switch.
3.2.3 Data Link Layer Detection
IP over FE/GE Transmission

A base station obtains the VLANs used by the data link layer through the VLAN acquisition
process. For details, see section "3.2.8 Obtaining VLAN Information for DHCP Packets."
IP over E1/T1 Transmission

Physical layer detection shows that a base station works in E1 or T1 mode. The base station
supports PPP/MP detection on E1/T1 timeslot combinations. Table 3-1 and Table 3-2
describe the E1 and T1 timeslot combinations, respectively. PPP is short for Point-to-Point
Protocol and MP for Multilink Protocol.
Table 3-1 E1 timeslot combinations
Serial 31 Timeslot<------------------>0 Timeslot Hexadecimal Digit

Number
1 11111111111111111111111111111110 0xFFFFFFFE
2 00000000000000001111111111111110 0x0000FFFE
3 00000000000000011111111111111110 0x0001FFFE
4 00000000000001111111111111111110 0x0007FFFE
5 00000000000000000011111111111110 0x00003FFE
6 00000000000111111111111111111110 0x001FFFFE
7 00000000000000000000111111111110 0x00000FFE
8 00000000011111111111111111111110 0x007FFFFE
9 00000000000000000000001111111110 0x000003FE
10 00000001111111111111111111111110 0x01FFFFFE
11 00000111111111111111111111111110 0x07FFFFFE
12 00011111111111111111111111111110 0x1FFFFFFE
13 01111111111111111111111111111110 0x7FFFFFFE
14 00000000000000000000000011111110 0x000000FE
15 00000000000000000000000000111110 0x0000003E
16 00000000000000111111111111111110 0x0003FFFE
17 00000000000000000111111111111110 0x00007FFE

SingleRAN
Serial 31 Timeslot<------------------>0 Timeslot Hexadecimal Digit

Number
18 00000000000011111111111111111110 0x000FFFFE
19 00000000000000000001111111111110 0x00001FFE
20 00000000001111111111111111111110 0x003FFFFE
21 00000000000000000000011111111110 0x000007FE
22 00000000111111111111111111111110 0x00FFFFFE
23 00000011111111111111111111111110 0x03FFFFFE
24 00001111111111111111111111111110 0x0FFFFFFE
25 00111111111111111111111111111110 0x3FFFFFFE
26 00000000000000000000000111111110 0x000001FE
27 00000000000000000000000001111110 0x0000007E
Table 3-2 T1 timeslot combinations

Serial 23 Timeslot<------------------>0 Hexadecimal Digit
Number Timeslot
1 111111111111111111111111 0x00FFFFFF
2 000000000111111111111111 0x00007FFF
3 000000011111111111111111 0x0001FFFF
4 000000000001111111111111 0x00001FFF
5 000001111111111111111111 0x0007FFFF
6 000000000000011111111111 0x000007FF
7 000111111111111111111111 0x001FFFFF
8 000000000000000111111111 0x000001FF
9 011111111111111111111111 0x007FFFFF
10 000000000000000001111111 0x0000007F
11 000000000000000000011111 0x0000001F
12 000000001111111111111111 0x0000FFFF
13 000000000011111111111111 0x00003FFF
14 000000111111111111111111 0x0003FFFF
15 000000000000111111111111 0x00000FFF

SingleRAN
Serial 23 Timeslot<------------------>0 Hexadecimal Digit

Number Timeslot
16 000011111111111111111111 0x000FFFFF
17 000000000000001111111111 0x000003FF
18 001111111111111111111111 0x003FFFFF
19 000000000000000011111111 0x000000FF
20 000000000000000000111111 0x0000003F
NOTE
In Table 3-1 and Table 3-2, 1 indicates that the timeslot is occupied and 0 indicates that the timeslot is
not occupied. Timeslot combinations that are not listed in the tables cannot be used for PnP deployment.
If a base station works in IP over E1/T1 mode, the peer transmission device must be
configured as follows:
l PPP/MP detection is configured as non-authentication.

l The peer IP address is configured for PPP/MP detection.
If the peer transmission device is not functioning as a DHCP server, the DHCP relay agent
function must be enabled on the interface for PPP/MP detection on the peer transmission
device.
3.2.4 DHCP Overview
3.2.4.1 Introduction
Before an OMCH is established, a base station is not configured with any data and cannot
perform end-to-end communication with other devices at the IP layer. The base station
implements this communication by obtaining the following information:
l OMCH configuration data, including the following:

– OM IP address
– OM VLAN ID
– Interface IP address
– Interface IP address mask
– IP address of the next-hop gateway
– IP address of the U2000 or BSC
– IP address mask of the U2000 or BSC
l During base station deployment by PnP, if the base station must use digital certificates
issued by the operator's CA to perform identity authentication with other devices,
operator's CA information is required. This information includes the following:
– CA name
– CA address

SingleRAN
– CA port number
– CA path
– Transmission protocol (HTTP or HTTPS) used by the CA
l In IPsec networking scenarios, the base station must obtain SeGW information,
including the IP address and local name.
The base station uses DHCP to obtain the preceding OMCH information, operator's CA
information, and SeGW information. DHCP is a protocol used to implement dynamic
configuration of the host. It allocates and distributes configuration parameters and works in
client/server mode. The DHCP procedure involves the following logical NEs:
l DHCP client: a host that uses DHCP to obtain configuration parameters

l DHCP server: a host that allocates and distributes configuration parameters to a DHCP
client
l DHCP relay agent: an NE that transmits DHCP packets between a DHCP server and a
DHCP client. A DHCP relay agent must be deployed between a DHCP server and a
DHCP client that are in different broadcast domains.
After a DHCP client accesses the network, it actively exchanges DHCP packets with its
DHCP server to obtain configuration parameters. During the exchange, the DHCP server and
the DHCP relay agent listen to DHCP packets in which the destination UDP port number is
67, and the DHCP client listens to DHCP packets in which the destination UDP port number
is 68.
3.2.4.2 DHCP Interworking

When a DHCP client and a DHCP server are in the same broadcast domain, broadcast packets
can be received by each other. Figure 3-6 shows the interworking between the DHCP client
and DHCP server that are in the same broadcast domain.
Figure 3-6 DHCP interworking between the DHCP client and DHCP server that are in the
same broadcast domain

SingleRAN
1. After the DHCP client starts, a DHCPDISCOVER packet is broadcast to search for an
available DHCP server. The DHCPDISCOVER packet carries the identification
information about the DHCP client.
2. The DHCP server responds to the DHCPDISCOVER packet with a DHCPOFFER
packet.
3. The DHCP client sends a DHCPREQUEST packet to the DHCP server, requesting
parameters such as an IP address.
4. The DHCP server sends a DHCPACK packet to the DHCP client to assign parameters
such as an IP address.
5. If the assigned parameters cannot be used, for example, an assigned IP address has been
used by other DHCP clients, and the DHCP client sends a DHCPDECLINE packet to
notify the DHCP server.
6. If the DHCP client no longer requires the assigned parameters, a DHCPRELEASE
packet is sent to notify the DHCP server so that the DHCP server can assign these
parameters to other DHCP clients.
When the DHCP client and DHCP server are not in the same broadcast domain, broadcast
packets cannot be received by each other. In this case, the DHCP relay agent function must be
enabled in the broadcast domain of the DHCP client to ensure the communication between the
DHCP client and DHCP server. In general, the DHCP relay agent function is enabled on the
gateway. When the DHCP relay agent function is enabled, the IP address of the corresponding
DHCP server must be configured so that the DHCP relay agent can forward the DHCP
packets from the DHCP client to the correct DHCP server. Figure 3-7 shows the interworking
between the DHCP client and DHCP server that are not in the same broadcast domain.
Figure 3-7 DHCP interworking between the DHCP client and DHCP server that are not in the
same broadcast domain
3.2.4.3 DHCP Packet Format

Figure 3-8 shows the example format of DHCP packets shown in Figure 3-6.

SingleRAN
Figure 3-8 DHCP packet format
NOTE
The actual length and sequence of each field in a DHCP packet in software implementation may be
different from those shown in Figure 3-8.
The DHCP header contains the DHCP control and configuration information. In the DHCP
header, the fields related to automatic OMCH establishment are as follows:
l yiaddr
This field carries the interface IP address of the base station.
l giaddr
This field carries the IP address of the DHCP relay agent.
l Option fields
These fields are encoded in code-length-value (CLV) format and consist of many
subcodes. Among these fields, Option 43 carries Huawei proprietary information
elements (IEs) and most configuration information of the base station. For example,
subcode 1 in Option 43 carries the electronic serial number (ESN) of the Huawei base
station. For details about subcodes of Option 43, see Table 3-7.

SingleRAN
Since Option 43 has a limited length, Option 224 is also used to carry Huawei
proprietary IEs in SRAN8.0 or later.
For details about DHCP, see section "Dynamic Host Configuration Protocol (DHCP)" in RFC
2131 and "DHCP Options and BOOTP Vendor Extensions" in RFC 2132.
3.2.5 DHCP Clients and Servers

In this document, base stations act as DHCP clients. Table 3-3 describes the mapping between
base stations and DHCP servers.
Table 3-3 Mapping between base stations and DHCP servers

Base Station Type DHCP Server in DHCP Server in
Non-IPsec IPsec Networking
Networking
Single-mode GBTS BSC In the trusted

domain: U2000
eGBTS/eNodeB U2000 DHCP server
NodeB U2000 In the untrusted
domain: public
Multimode Co-MPT multimode U2000 DHCP server
base station
Separate-MPT Same as that of a

multimode base single-mode base
station station
NOTE
l The DHCP server and the U2000 are different logical communication entities, although deployed on
the same hardware. This document distinguishes between the DHCP server and the U2000.
l It is recommended that the DHCP server be deployed on the U2000 for base stations other than
GBTSs that are not protected by IPsec.
l If the DHCP server is deployed on the U2000, the base station cannot be on the same L2 network as
the U2000. For security reasons, the U2000's operating system can process only DHCP unicast
packets, not DHCP broadcast packets
From SRAN8.0 onwards, if single-mode or separate-MPT multimode base stations evolve to

co-MPT multimode base stations, corresponding DHCP servers must migrate to the U2000.
Even if the evolution is not implemented, the migration is recommended due to the provision
of better function support, paving the way to smooth future upgrades and evolutions.
When the base station is not on the same L2 network as the DHCP server, a DHCP relay
agent must be deployed. Pay attention to the following when deploying a DHCP relay agent:
l When a next-hop gateway of the base station is deployed on the transport network, the
DHCP relay agent function must be enabled. The U2000 DHCP server IP address must
also be configured on the next-hop gateway of the base station.
– If the Virtual Router Redundancy Protocol (VRRP) is deployed on the next-hop
gateway, configure the VRRP's virtual IP address as the IP address of the DHCP
relay agent. When the active router is faulty, the standby router can act as the DHCP
relay agent.

SingleRAN
– If the base station is a GBTS, run the SET BTSIP command. In this step, set
BTSGWIPSWITCH to ON and NEXTHOP to the IP address of the base station's
next-hop gateway.
l When the base station is on the same L2 network as the base station controller, DHCP
packets pass through the base station controller. The U2000 then serves as the DHCP
server for the base station (for example, eGBTS or NodeB), and this base station
controller can be deployed as the DHCP relay agent. If the DHCP relay agent function is
enabled on a certain port of the base station controller, this port serves as the DHCP relay
agent for all eGBTSs and NodeBs connected to this port. The ADD DHCPRLY
command can be used to enable the DHCP relay agent function on a port of the base
station controller. This command contains the following parameters:
– DHCPRLYID (BSC6900, BSC6910) indicates the identity of a DHCP relay agent.
– DHCPRLYGATEWAYIP (BSC6900, BSC6910) indicates the interface IP address
of the base station controller.
– DHCPPID is used to enable or disable the DHCP relay agent function only on
BSC6900s. The base station controller serves as the DHCP server for the base
station by default. The OTHERSWITCH check box under the DHCPPID
parameter can be selected to enable the DHCP relay agent function for the base
station.
MML command examples are as follows:
//Enabling the DHCP relay agent function on the base station controller
when the U2000 that manages this base station controller is the DHCP
server for the base station
ADD DHCPRLY: DHCPRLYID=1, DHCPRLYGATEWAYIP="10.1.1.1",
DHCPPID=OTHERSWITCH-1, DHCPSRVISEMSIP=Yes;
Information such as the U2000 IP address and route must be configured on the base
station controller side. For details, see the section about configuring Abis interface
operation and maintenance channels for eGBTS in BSC6900/BSC6910 GSM initial
configuration guide. Also, refer to the section about configuring Iub interface
operation and maintenance channels in BSC6900/BSC6910 UMTS initial
configuration guide.
NOTE
Whether the base station controller can serve as the DHCP server or DHCP relay agent depends on the
base station type.
l For GBTSs, the base station controller can only serve as the DHCP relay server.
l For other types of base stations, such as the eGBTS, NodeB, and co-MPT multimode base station,
the base station controller can only serve as the DHCP relay agent.
l When base stations are cascaded or backplane co-transmission is applied, an upper-level
base station serves as the next-hop gateway for the lower-level base station. In this case,
the DHCP relay agent function must be enabled and the DHCP server IP address of the
lower-level base station must be configured on the upper-level base station.
– If the upper-level base station is an eGBTS, NodeB, eNodeB, or co-MPT
multimode base station, run the SET DHCPRELAYSWITCH command with ES
set to ENABLE to enable the DHCP relay agent function. Then, run the ADD
DHCPSVRIP command with DHCPSVRIP set to the DHCP server IP address of
the lower-level base station. A maximum of four DHCP server IP addresses can be
configured. MML command examples are as follows:
//Enabling the DHCP relay agent function on the upper-level base station
SET DHCPRELAYSWITCH: ES=ENABLE;
//Setting the DHCP server IP address to 10.19.19.11. Each DHCP broadcast
packet will be forwarded to all DHCP servers.
ADD DHCPSVRIP: DHCPSVRIP="10.19.19.11";

SingleRAN
NOTE
In backplane co-transmission, when the IP transmission of the upper transmission port is

used as the DHCP relay agent IP address and the source-based route is configured for the
base station, the DHCP relay agent IP address must be manually configured. If multiple
DHCP server IP addresses specified by DHCPSVRIP are configured, each must be
configured with an IP address of the DHCP relay agent.
The following MML command example assumes that the IP address of the DHCP relay
agent is 10.1.1.1:
ADD DHCPSVRIP: DHCPSVRIP="10.19.19.11", DHCPRELAYIPSW="ENABLE",
DHCPRELAYIP="10.1.1.1";
For application scenarios of the source-based route, see IP Transmission Feature Parameter
Description.
– If the upper-level base station is a GBTS, run the ADD BTSDHCPSVRIP
command with DHCPSRV set to the IP address of the lower-level base station's
DHCP server. MML command examples are as follows:
ADD BTSDHCPSVRIP: IDTYPE=BYID, BTSID=20, DHCPSRV="10.100.10.10";
In base station cascading scenarios, manual configuration of DHCP relay agent IP

addresses is not supported, and the upper-level base station will use its OM IP address
and lower port IP address as the DHCP relay agent IP address.
In backplane co-transmission scenarios, manual configuration of DHCP relay agent IP
addresses is supported. If no DHCP relay agent IP address is manually configured, the
upper-level base station will use its OM IP address and upper transmission port interface
IP address as the DHCP relay agent IP address. The upper transmission port interface IP
address is on the same network as the next-hop IP address of the DHCP server IP
address.
For details about configuration requirements, see Table 3-28.
l A base station can serve as the DHCP relay agent for other base stations in the same L2
network. In this case, the DHCP relay agent function must be enabled and the DHCP
server IP addresses of the other base stations must be configured on the base station in
question. The enabling and configuring methods for this base station are the same as
those for an upper-level base station.
l When base station cascading is used, the number of base station nodes on the chain
topology cannot exceed four. This is because some DHCP relay agents in the transport
network require that the number of relay agents cannot exceed four. Otherwise, DHCP
packets will be discarded.
3.2.6 DHCP Procedure
3.2.6.1 Base Station Identification

Upon receiving a DHCP packet from a base station, the DHCP server finds and sends related
configuration information to the base station depending on the base station identification (BS
ID) contained in the DHCP packet.
The U2000 that matches SRAN8.0 or a later version uses the combination of the ESN and slot
number or the combination of the deployment identifier (DID), subrack topology, and slot
number as the BS ID.
Base station controllers and U2000s that match versions earlier than SRAN8.0 use the
combination of the ESN and NE type or the combination of the DID and NE type as the BS
ID.

SingleRAN
The details about each element in the combinations are as follows:

l ESN identifies the baseband unit (BBU) backplane of the base station. Each backplane
has a unique ESN (reported by the base station).
l Deployment ID (DID) is the site identifier planned by the operator. DID is scanned into
the base station using a barcode scanner connected to the USB port of the main control
board during base station deployment. After being scanned into the base station, the DID
is broadcast in all BBUs. All main control boards will record the DID and use it as the
BS ID in the DHCP procedure.
l Subrack topology identifies the interconnection relationship between BBU subracks that
are interconnected. The combination of the DID and subrack topology uniquely
identifies a BBU subrack.
l Slot number identifies the number of the slot that accommodates the main control board.
The slot number is used to differentiate main control boards in a BBU subrack. If the
base station is configured with active and standby main control boards, the slot number
is that of the active main control board. The slot number is reported by the base station.
l NE type indicates whether the base station works in the GSM, UMTS, or LTE mode.
When creating a base station commissioning task by PnP, operators must specify the ESN if
the U2000 uses the combination of the ESN and slot number as the BS ID. The DID must be
included in the base station configuration file if the U2000 uses the combination of the DID,
subrack topology, and slot number as the BS ID.
NOTE
In some networking scenarios, such as IPsec networking scenario 1, it is not recommended that the
public DHCP server deliver the transmission configuration based on the BS ID.
A combination of the DID, subrack topology, and slot number can be used as the BS ID only if the
transmission port of the base station is an Ethernet port. This also requires that the DHCP server of the
base station be deployed on the U2000.
3.2.6.2 Obtaining Configuration Information in Non-IPsec Networking Scenarios
Obtaining Configuration Information with No DHCP Relay Agent

A DHCP client and a DHCP server on the same Layer 2 (L2) network can directly
communicate with each other. The L2 network is a subnet in which broadcast IP packets can
be exchanged and forwarded by Media Access Control (MAC) addresses and VLAN IDs. An
example is Ethernet or Ethernet VLAN.
Figure 3-9 shows the procedure for a base station to obtain configuration information from a
DHCP server when no DHCP relay agent is deployed.

SingleRAN
Figure 3-9 Procedure for obtaining configuration information with no DHCP relay agent
The procedure is as follows: After the base station is powered on, a DHCPDISCOVER packet
with the BS ID is broadcast. The DHCP server then sends configuration information to the
base station based on the BS ID.
Obtaining Configuration Information with a DHCP Relay Agent

If a DHCP server is not deployed on the L2 network of a DHCP client, a DHCP relay agent
must be installed on the next-hop gateway of the DHCP client to forward DHCP packets. The
DHCP relay agent must be on the same L2 network as the DHCP client, and the DHCP server
must be on the Layer 3 (L3) network in which packets are forwarded by IP addresses.
Figure 3-10 shows the procedure for a base station to obtain configuration information from a
DHCP server when a DHCP relay agent is deployed.
Figure 3-10 Procedure for obtaining configuration information with a DHCP relay agent
The procedure is as follows: The DHCP relay agent converts DHCP packets broadcast by the
base station into unicast packets, which are routed to the DHCP server. The DHCP server
sends unicast response packets to the DHCP relay agent, which then broadcasts received
response packets on the L2 network.
3.2.6.3 Obtaining Configuration Information in IPsec Networking Scenarios

In IPsec networking scenarios, the DHCP server in the trusted domain can be secured or not
secured by IPsec. When the DHCP server is secured by IPsec, a public DHCP server in the

SingleRAN
untrusted domain must be deployed. Figure 3-11 shows the OMCH networking in this
scenario.
Figure 3-11 IPsec OMCH networking
Figure 3-12 shows the two procedures for the base station to obtain transmission
configuration information in the networking shown in Figure 3-11.
Figure 3-12 Two procedures for obtaining transmission configuration information in IPsec
networking scenarios
1. The base station exchanges DHCP packets with a public DHCP server to obtain
information, such as the interface IP address for accessing the untrusted domain and the
SeGW IP address. The base station must also obtain the CA IP address due to required
digital certificates for identity authentication with the SeGW. This procedure is referred
to as the first DHCP procedure.
2. The base station negotiates with the SeGW on the Internet Key Exchange (IKE) security
association (SA) and IPsec SA, and then establishes an IPsec tunnel. Since digital

SingleRAN
certificates are required for identity authentication with the SeGW, the base station must
apply to the CA for digital certificates that can be identified by the SeGW.
3. The base station exchanges DHCP packets with its U2000 DHCP server to obtain the
OM IP address used for accessing the trusted domain. This procedure is referred to as the
second DHCP procedure. The second DHCP procedure varies depending on IPsec
networking scenarios. For details, see section 3.3.3.7 Obtaining Formal Transmission
Configuration Information from the Internal DHCP Server.
During the first DHCP procedure, the public DHCP server runs DHCP. It may not support
Huawei-defined DHCP Option fields and fail to identify the BS ID reported by the base
station. In this case, the public DHCP server selects an IP address from the IP address pool
and sends it to the base station. During the second DHCP procedure, the U2000 DHCP server
sends configuration parameters to the base station based on the BS ID reported by the base
station.
3.2.6.4 Releasing Allocated Configuration Information

When a base station obtains configuration information from a U2000 DHCP server, but does
not require configuration information allocated by a public DHCP server, the base station
sends a DHCPRELEASE message to the public DHCP server. After receiving the
DHCPRELEASE message, the public DHCP server can redistribute allocated configuration
information to other NEs. Figure 3-13 shows the procedure for releasing allocated
configuration information.
Figure 3-13 Procedure for releasing allocated configuration information
NOTE
In addition to the preceding procedures, DHCP also supports the procedure for updating configuration
information. However, base stations in SRAN8.0 do not support the procedure for updating
3.2.7 Automatic DHCP Data Synchronization

Ensure that the correct DHCP data of a base station is available on the U2000 DHCP server
before using Automatic OMCH Establishment. Any manual modifications to a base station's
transmission configuration data may change its DHCP data on the U2000. In earlier versions,
users had to manually ensure that the DHCP data on the U2000 DHCP server was correct
before the start of the next automatic OMCH establishment procedure. As a manual data
check is a complex and error-prone process, the automatic DHCP data synchronization
function is introduced in this version.

SingleRAN
After the base station is deployed, the system automatically synchronizes manual
modifications to the transmission configuration data in the base station configuration file with
the U2000 DHCP server. This ensures the configuration information consistency between the
U2000 DHCP server and the base station. For manual modifications on a single base station,
the system starts data synchronization (5 minutes), which begins 10 minutes after the last
manual data modification. For manual modifications on several base stations, the system
starts data synchronization for every 200 base stations as a batch, with each batch completed
within less than or equal to 30 minutes. It is important to highlight that DHCP data must be
manually modified on the U2000 GUI.
However, the automatic DHCP data synchronization function does not support automatic
synchronization of the NE name, NE type, ESN, and working mode because they identify a
specific NE. In addition, this function does not support automatic synchronization of the
Security Gateway Emergency Bypass field because this field must be manually configured.
Automatic DHCP data synchronization supports synchronization of other information on the
U2000 DHCP server. Ensure that the related NE data exists in the current data area on the
CME before starting automatic DHCP data synchronization.
3.2.8 Obtaining VLAN Information for DHCP Packets
3.2.8.1 Overview
Packets sent by a base station on a VLAN-based network must carry the VLAN ID. Before an
OMCH is established, specifically before the base station sends the first DHCP packet, the
base station must learn VLAN information after it starts. After learning VLAN information by
parsing received Address Resolution Protocol (ARP) packets with VLAN IDs, the base
station delivers DHCP packets with VLAN IDs and interworks with DHCP servers to obtain
transmission configuration information. The procedure for obtaining VLAN information is as
follows:
1. Once the DHCP function is enabled on the base station, the base station starts the VLAN
acquisition process. With VLAN acquisition, the base station actively acquires VLAN
IDs of all received ARP packets and records these VLAN IDs in a PnP VLAN-ID table.
The base station sends DHCP packets without VLAN IDs or with VLAN ID being either
0 or 1.
2. The base station waits 20s. If the base station receives a DHCPOFFER packet within
20s, it exits the DHCP procedure and enters the subsequent PnP deployment procedure.
Otherwise, the base station is directed to go to the next step.
3. The base station checks the PnP VLAN-ID table and sends DHCP packets using all
acquired VLAN IDs. If the base station receives a valid DHCPOFFER packet, it exits the
DHCP procedure and enters the subsequent PnP deployment procedure.
4. When the preceding steps fail:
– If the base station has only one transmission port, the base station continues ro
repeat the preceding steps on this port.
– If the base station has multiple transmission ports, the base station continues to
repeat the preceding steps on other transmission ports.
Table 3-4 describes the recommended schemes for the base station in SRAN8.0 and later
versions to obtain VLAN information during deployment.

SingleRAN
Table 3-4 Obtaining VLAN information

Scena Whether Networking Requirement for NE How to
rio IPsec Scenario Obtain
SN Secures VLAN
OMCH Informati
Data on
1 No IPsec secures service N/A Using

data, signaling data, scheme 1
and all or a portion of
the other data. It does
not secure OMCH
data. (IPsec
networking scenario
3)
2 Yes IPsec secures DHCP l The SeGW initiates a

packets, OMCH data, request for IKE
and all or a portion of negotiation with the
the other data. (IPsec base station. The
networking scenario destination IP address
1) of the request is the
interface IP address that
the base station uses to
access the untrusted
domain.
l The VLAN information
in DHCP packets sent
by the base station must
be the same as the
VLAN information in
the configuration files
of the base station.
3 Yes IPsec secures OMCH The security policy allows Using

data and all or a the transmission of DHCP scheme 2
portion of the other packets sent by the U2000
data. It does not DHCP server to the base
secure DHCP packets. station.
(IPsec networking
scenario 2)
4 Yes IPsec secures DHCP The L2 network is Using

packets, OMCH data, configured with the default scheme 3
and all or a portion of VLAN ID or no VLAN ID.
the other data. (IPsec
networking scenario
1)

SingleRAN
Scena Whether Networking Requirement for NE How to

rio IPsec Scenario Obtain
SN Secures VLAN
OMCH Informati
Data on
5 Yes IPsec secures DHCP The next-hop gateway of Using

packets, OMCH data, the base station can scheme 4
and all or a portion of periodically send ping
the other data. (IPsec packets to the interface IP
networking scenario address of the base station.
1)
If a base station is deployed by PnP, the scheme for obtaining VLAN information varies
depending on whether IPsec secures OMCH data and the capability of NEs:
l If IPsec does not secure OMCH data, scheme 1 is used:
The U2000 or BSC actively and periodically sends OMCH establishment requests to the
base station. After receiving the requests, the next-hop gateway of the base station sends
ARP packets to the base station. The base station then records VLAN IDs derived from
ARP packets and includes recorded VLAN IDs in DHCP packets.
l If IPsec secures OMCH data, any of the following schemes is used:
– Scheme 1
– Scheme 2: The DHCP server on the U2000 periodically sends the base station
empty DHCPOFFER packets (only containing DHCP headers) with the destination
IP address set to the non-security domain interface IP address of the base station.
This enables the next-hop gateway of the base station to send ARP packets, from
which the base station derives VLAN information.
– Scheme 3: The base station sends DHCP packets with no VLAN ID, and the L2
network attaches a VLAN ID to DHCP packets sent by the base station. In this case,
the base station does not need to acquire VLAN information.
– Scheme 4: The next-hop gateway of the base station or other NEs periodically send
packets to the base station or an idle address of the subnet in which the base station
is deployed. This enables the next-hop gateway of the base station to send ARP
packets, from which the base station derives VLAN information.
3.2.8.2 Scheme 1
Scheme 1 applies to two scenarios:
l IPsec does not secure OMCH data. Figure 3-14 shows the procedure for a base station to
obtain VLAN information in this scenario.
l IPsec secures OMCH data and NEs meet specific requirements. Figure 3-15 shows the
procedure for a base station to obtain VLAN information in this scenario.

SingleRAN
Figure 3-14 Scheme 1 (IPsec does not secure OMCH data)
1. The U2000 or BSC sends an OMCH establishment request to the OM IP address of the
base station.
2. To forward the OMCH establishment request to the correct base station, the next-hop
gateway of the base station broadcasts ARP packets to obtain the MAC address mapping
the destination IP address of the request. The next-hop gateway or the L2 network
attaches VLAN IDs to ARP packets so that correct VLAN IDs are contained in the ARP
packets received by the base station.
3. The base station parses all received ARP packets and records the VLAN IDs contained
in the packets.
4. The base station sends all DHCP packets with recorded VLAN IDs. Only DHCP packets
with correct VLAN IDs can reach the DHCP relay agent which is installed on the next-
hop gateway of the base station.
Figure 3-15 Scheme 1 (IPsec secures OMCH data)
1. The U2000 or BSC sends an OMCH establishment request to the OM IP address of the
base station. The request is forwarded to the SeGW.

SingleRAN
2. The SeGW detects that the IPsec SA with the base station is not established and sends an
IKE negotiation request to the interface IP address of the base station. The request is then
routed to the next-hop gateway of the base station.
3. To forward the IKE negotiation request to the correct base station, the next-hop gateway
of the base station broadcasts ARP packets to obtain the MAC address mapping the
destination IP address of the request. The next-hop gateway or the L2 network attaches
VLAN IDs to ARP packets so that correct VLAN IDs are contained in the ARP packets
received by the base station.
in the packets. It may record the VLAN ID in an ARP packet destined for another base
station.
with correct VLAN IDs can reach the DHCP relay agent.
3.2.8.3 Scheme 2
Figure 3-16 shows the procedure for a base station to obtain VLAN information in scheme 2.
Figure 3-16 Scheme 2
1. The U2000 sends a DHCPOFFER packet with no content to the interface IP address of
the base station. The packet is then forwarded to the next-hop gateway of the base
station.
2. To forward the DHCPOFFER packet to the correct base station, the next-hop gateway of
the base station broadcasts ARP packets to obtain the MAC address mapping the
destination IP address of the request. The next-hop gateway or the L2 network attaches
VLAN IDs to ARP packets so that correct VLAN IDs are contained in the ARP packets
received by the base station.
station.

SingleRAN
3.2.8.4 Scheme 3
1. The base station sends a DHCP packet with no VLAN ID.

2. The L2 network between the base station and the next-hop gateway of the base station
automatically attaches the default VLAN ID to the DHCP packet. The default VLAN ID
is the same as the VLAN ID required for deploying the base station. With the correct
VLAN ID, the DHCP packet can then be forwarded over the L2 network to the DHCP
relay agent to reach the DHCP server.
3.2.8.5 Scheme 4

SingleRAN
1. The next-hop gateway periodically sends ping packets to the interface IP address of the
base station or an IP address on the network segment of the base station.
2. To forward ping packets to the correct base station, the next-hop gateway of the base
station broadcasts ARP packets to obtain the MAC address of the base station mapping
the destination IP address of the ping packets. The ARP packets received by the base
station carry correct VLAN IDs.
station.
3.2.8.6 Enabling and Disabling the VLAN Scanning Function

In SRAN7.0, the VLAN scanning function is provided for eNodeBs to solve the issue that
base stations cannot acquire VLAN IDs in secure networking scenarios. After the VLAN
scanning function is enabled, the base station sends DHCP packets with random VLAN IDs.
This occurs if the base station does not receive a response after sending DHCP packets
without a VLAN ID and DHCP packets with acquired VLAN IDs.
After the VLAN scanning function is enabled, some DHCP packets with invalid VLAN IDs
may be broadcast. In scenarios where different VLANs are not isolated, VLAN scanning
imposes great impacts on the network. Therefore, this function is disabled for base stations of
SRAN8.0 or a later version by default. For base stations upgraded from SRAN7.0 to
SRAN8.0 or later, it is recommended to run the SET DHCPSW command to locally or
remotely enable or disable this function.
l //Enabling the VLAN scanning function

SingleRAN
SET DHCPSW: SWITCH=ENABLE; VLANSCANSW=ENABLE;

l //Disabling the VLAN scanning function
SET DHCPSW: SWITCH=ENABLE; VLANSCANSW=DISABLE;
NOTE
When the OMCH and service channels are disconnected, the SET DHCPSW command is used to
determine whether to automatically start the DHCP procedure to obtain the initial configuration
information or to restore the base station configuration. The SWITCH parameter indicates whether to
enable the function of starting the DHCP procedure automatically. The VLANSCANSW parameter
indicates whether to enable the VLAN scanning function when the base station sends DHCP packets.
3.2.8.7 Saving VLAN IDs

From SRAN8.0 onwards, VLAN IDs that are used for a successful DHCP procedure can be
saved. Upon receiving a DHCP-ACK message, the base station saves VLAN IDs (a
maximum of eight) that are used for the DHCP procedure. If the maximum limit is reached,
the new VLAN ID will replace the earliest VLAN ID.
The base station can use the saved and acquired VLAN IDs to send DHCP packets when
reinitiating a DHCP procedure during or after deployment of the base station.
The saved VLAN IDs will be automatically cleared after the base station experiences a
power-off reset.
3.3 Automatic OMCH Establishment by Single-mode Base

Station and Co-MPT Multimode Base Station
3.3.1 Overview
This chapter describes the automatic OMCH establishment procedures implemented by the
single-mode base station and co-MPT multimode base station in IPsec or non-IPsec
networking scenarios, outlining the procedural requirements for NEs. In IPsec networking
scenarios, the network is divided into the trusted and untrusted domains. Depending on NE
distribution in these domains, IPsec networking scenarios are classified as follows:
l Scenario 1: IPsec secures DHCP packets, OM data, and all or a portion of other data.
l Scenario 2: IPsec secures OM data and all or a portion of other data. It does not secure
DHCP packets.
l Scenario 3: IPsec secures service data, signaling data, and all or a portion of other data. It
does not secure DHCP packets or OM data.
Automatic OMCH establishment may fail if the peer equipment is not ready or the
configuration of the base station, transmission equipment, or peer equipment is incorrect. In
this case, the base station initiates another DHCP procedure to obtain the configuration and
then restarts automatic OMCH establishment.
3.3.2 Automatic OMCH Establishment in Non-IPsec Networking

Scenarios

SingleRAN
3.3.2.1 Introduction to Non-IPsec Networking

Figure 3-19 shows a non-IPsec networking scenario in which IPsec does not secure OMCH
data.
Figure 3-19 Non-IPsec networking
This networking has the following characteristics:

l The DHCP server is not deployed on the L2 network of the base station.
l The DHCP relay agent is deployed on the next-hop gateway of the base station.
l IPsec does not secure OMCH data.
3.3.2.2 Automatic OMCH Establishment Procedure

Figure 3-20 shows the automatic OMCH establishment procedure.
Figure 3-20 Automatic OMCH establishment
1. After a base station commissioning task by PnP is created on the U2000, the U2000
periodically sends an SSL-based or plaintext-based OMCH establishment request to the

SingleRAN
base station. After an NE is created on the BSC, a plaintext-based OMCH establishment

request is periodically sent by the BSC to the base station. In the request, the source IP
address is the IP address of the U2000 or BSC and the destination IP address is the OM
IP address of the base station. After the next-hop gateway of the base station receives the
request, ARP packets are broadcast to the base station to obtain the MAC address
mapping the interface IP address of the base station.
NOTE
The next-hop gateway of the base station broadcasts ARP packets each time it receives a TCP
connection request sent periodically by the U2000.
If the Use SSL option on the U2000 is selected, the U2000 periodically sends an SSL-based
OMCH establishment request to the base station. If this option is not selected, the U2000
periodically sends a plaintext-based OMCH establishment request to the base station. For the
automatic OMCH establishment procedure in this scenario, see section "3.3.2.4 SSL
Authentication on the OMCH."
During a DHCP procedure, a DHCP response packet sent by the U2000 contains the target RAT
for the base station. Upon detecting an inconsistency between the current and target RATs, the base
station changes the current RAT and is restarted. The base station will then reinitiate a DHCP
procedure.
2. The base station obtains VLAN information. For details, see section "3.2.8 Obtaining
VLAN Information for DHCP Packets."
3. The base station first sends DHCP packets with no VLAN ID and then DHCP packets
with VLAN IDs. By exchanging DHCP packets with its next-hop gateway and DHCP
server, the base station obtains the OMCH configuration data and makes the data take
effect.
4. The base station responds to the OMCH establishment request from the U2000 or BSC
and then establishes an OMCH to the U2000 or BSC.
NOTE
If the OMCH fails to be established, the base station automatically restarts the automatic OMCH
establishment procedure.
3.3.2.3 Configuration Requirements for the DHCP Server

The DHCP server of a base station must be configured with the following:
l A route to the IP address of the DHCP relay agent
l Parameters to be used during the DHCP procedure
These parameters are contained in the DHCP packet headers, Option fields defined by RFC
2132, and subcodes of Option 43 defined by Huawei. Table 3-5 lists the parameters to be
contained in the DHCP packet headers. Table 3-6 describes common Option fields. Table 3-7
provides subcode information in the Option 43 field.
Table 3-5 Parameters to be contained in the DHCP packet headers

Parameter Mapping Length Parameter Mandatory DHCP
Name DHCP (Bytes) Descriptio or Packet
Field n Optional Involved
Interface IP yiaddr 4 Interface IP Mandatory DHCPOFFE

Address address of R
the base DHCPACK
station

SingleRAN
Parameter Mapping Length Parameter Mandatory DHCP

Name DHCP (Bytes) Descriptio or Packet
Field n Optional Involved
Relay Agent giaddr 4 IP address of Optional DHCPDISC

IP the DHCP OVERY
relay agent DHCPOFFE
deployed on R
the network,
if any are DHCPREQ
available. UEST
Broadcast DHCPACK
packets
(Discovery
and Request
packets) sent
by the base
station do
not carry
this IP
address, and
the DHCP
relay agent
adds this IP
address to
DHCP
packets to be
forwarded.
For details,
see RFC
2131.
Table 3-6 Parameters to be contained in DHCP Option fields

Paramete Opti Leng Parameter Mandatory or DHCP Packet
r Name on th Description Optional Involved
Field (Byt
es)
Subnet 1 4 Subnet mask of a Mandatory DHCPOFFER

Mask DHCP client DHCPACK
Router 3 N*4 List of the IP Mandatory DHCPOFFER

Option addresses of routers DHCPACK
deployed in a DHCP
client's subnet
N indicates the
number of next-hop
gateways for the
DHCP client.

SingleRAN
Paramete Opti Leng Parameter Mandatory or DHCP Packet

r Name on th Description Optional Involved
Field (Byt
es)
Vendor 43 0-255 Vendor-specific Mandatory DHCPDISCOV

Specific information exchanged ER
Informatio between a DHCP DHCPREQUES
n client and a DHCP T
server
DHCPOFFER
DHCPACK
IP 51 4 Lease time of an Mandatory DHCPOFFER

Address assigned IP address DHCPACK
Lease
Time
DHCP 53 1 Value: 1: Mandatory DHCPDISCOV

Message DHCPDISCOVER ER
Type 2: DHCPOFFER DHCPREQUES
3: DHCPREQUEST T
5: DHCPACK DHCPOFFER
DHCPACK
Server 54 4 IP address of a DHCP Mandatory DHCPOFFER

Identifier server DHCPACK
REQUEST
Renewal 58 4 Interval from address Optional DHCPOFFER

(T1) Time assignment to the DHCPACK
Value transition to the
RENEWING state
Rebinding 59 4 Interval from address Optional DHCPOFFER

(T2) Time assignment to the DHCPACK
Value transition to the
REBINDING state
Vendor 60 0-255 Vendor type and client Optional DHCPDISCOV

class configuration ER
identifier DHCPREQUES
T
Client- 61 0-255 Unique identifier of a Optional DHCPDISCOV

identifier DHCP client ER
DHCPREQUES
T

SingleRAN
Table 3-7 Parameters to be contained in subcodes of Option 43

Parameter Subcode Length Parameter Mandatory DHCP
Name (Bytes) Descriptio or Packet
n Optional Involved
ESN 1 20 ESN of the Mandatory DHCPDISC

BBU OVER
backplane. It DHCPOFFE
is used by a R
DHCP
server to DHCPREQ
determine UEST
the location DHCPACK
and BBU
subrack of
the base
station.
DHCP 50 1 Whether the Mandatory DHCPOFFE

Server ID DHCP when the R
packets are U2000 DHCPACK
sent by the serves as the
U2000 DHCP
DHCP server. This
server. The field is left
U2000 blank when
DHCP a device
server fills other than
in this field the U2000
when serves as the
sending the DHCP
DHCP server.
packets. If
the DHCP
packets are
not sent by
the U2000
DHCP
server, this
field is left
blank.
MPT 1st 251 1 Slot number Mandatory DHCPDISC

Slot Number of the first OVER
main control DHCPOFFE
board R
DHCPREQ
UEST
DHCPACK

SingleRAN

n Optional Involved
MPT 2nd 249 1 Slot number Optional. DHCPOFFE

Slot Number of the Mandatory R
second main only if the DHCPACK
control base station
board is configured
with active/
standby or
primary/
secondary
main control
boards.
DID 27 1~64 If the base Optional. DHCPDISC

station is DID is OVER
configured mandatory if DHCPOFFE
with only it is used as R
one BBU, the base
the DID station DHCPREQ
serves the identificatio UEST
same n in DHCP DHCPACK
purpose as packets.
the ESN.
If the base
station is
configured
with
multiple
BBUs that
are
interconnect
ed, these
BBUs use
the same
DID.

SingleRAN

n Optional Involved
Subrack 246 1–16 Interconnecti Mandatory DHCPDISC

Topo on OVER
relationship DHCPOFFE
between the R
BBU
accommodat DHCPREQ
ing the main UEST
control DHCPACK
board that
sends the
DHCP
packets and
other BBUs
if these
BBUs are
interconnect
ed. The
DHCP
server uses
the
combination
of the DID,
BBU
subrack
topology,
and slot
number to
identify the
configuratio
n file of the
base station.

SingleRAN

n Optional Involved
OM Bearing 250 1 Value: Optional. DHCPOFFE

Board l 0: An The default R
OMCH is value is 0. DHCPACK
establish
ed on the
panel.
Use this
value for
single-
mode
base
stations.
l 1: An
OMCH is
establish
ed on the
backplan
e.
OM 2 1 Transmissio Optional. DHCPOFFE

Interface n interface The default R
Type of the base value is DHCPACK
station: Ethernet.
Ethernet or
E1.
NOTE
If an
Ethernet
interface is
used as the
transmission
interface,
the OMCH
managed
object (MO)
in
configuratio
n files of the
base station
must be
bound to a
route, or the
peer IP
address
must be the
IP address
of the
U2000 or
the next-hop
gateway of
the base
station.

SingleRAN

n Optional Involved
OM 248 1 Slot number Mandatory DHCPOFFE

Interface of the main in SRAN8.0 R
Slot Number control or later only DHCPACK
board if the if an
transmission Ethernet
interface is interface is
provided by used as the
the main transmission
control interface.
board, or the If this
slot number parameter is
of the UTRP not
board if the specified,
transmission the base
interface is station
provided by automaticall
the UTRP y identifies
board. the slot
number.
OMCH 247 1 Port number Optional. DHCPOFFE

Interface of the Mandatory R
Port Number transmission in SRAN8.0 DHCPACK
interface of or later only
the base if an
station Ethernet
interface is
used as the
transmission
interface.
If this
parameter is
not
specified,
the base
station
automaticall
y identifies
the port
number.

SingleRAN

n Optional Involved
OMLOCATI 51 2 The numbers Optional. DHCPOFFE

ON of the Mandatory R
cabinet, and in SRAN8.0 DHCPACK
subrack that or later only
accommodat if an
e the main Ethernet
control interface is
board where used as the
the OMCH transmission
is located. interface. If
this
parameter is
not
specified,
the base
station
automaticall
y identifies
the numbers
of the
cabinet, and
subrack.
OM IP 3 4 Local IP Mandatory DHCPOFFE

the OMCH DHCPACK
OM IP 4 4 Local IP Mandatory DHCPOFFE

Address address R
Subnet Mask mask of the DHCPACK
OMCH
U2000 IP 5 4 Peer IP Mandatory DHCPOFFE

the OMCH DHCPACK
U2000 IP 6 4 Peer IP Mandatory DHCPOFFE

Subnet Mask address R
mask of the DHCPACK
OMCH

SingleRAN

n Optional Involved
OM Vlan ID 11 2 VLAN ID of This DHCPOFFE

the OMCH parameter is R
mandatory if DHCPACK
VLAN is
configured
on the
Ethernet port
of the base
station.
OM Vlan 12 1 VLAN This DHCPOFFE

Priority priority of parameter is R
the OMCH not included DHCPACK
in DHCP
packets
when an
E1/T1 port
is used as
the
transmission
port.
BSC IP 13 4 IP address of Mandatory DHCPOFFE

the BSC for the GSM R
mode DHCPACK
OM Next 17 4 Next-hop IP Mandatory DHCPOFFE

Hop IP address of R
Address the base DHCPACK
station
GBTS 54 1 DSCP used Optional DHCPOFFE

OMCH by the This R
DSCP GBTS to parameter is DHCPACK
establish an supported
OMCH. only by
GBTSs from
SRAN7.0
onwards. If
this
parameter is
not
specified,
the DSCP
subcode will
not be
delivered.

SingleRAN

n Optional Involved
Routing 57 1 Routing Optional DHCPOFFE

Mode mode This R
indicator: parameter is DHCPACK
0: supported
Destination- from
based route SRAN10.0
1: Source- onwards. If
based route this
parameter is
not
specified,
the base
station uses
the
destination-
based route
by default.
When creating a base station commissioning by PnP task on the U2000, deployment
engineers can import configuration information listed in Table 3-7 into the DHCP server.
Deployment engineers can only manually modify the configuration information for the DHCP
server on the U2000 GUI. Deployment may fail if the DHCP server is not configured with
mandatory parameters listed in Table 3-7 or optional parameters that must be configured in
certain scenarios.
3.3.2.4 SSL Authentication on the OMCH

If an OMCH uses SSL authentication, the base station must obtain an operator-issued device
certificate before establishing the OMCH with the U2000. Figure 3-21 shows the automatic
OMCH establishment procedure in this scenario.
Figure 3-21 Automatic OMCH establishment procedure

SingleRAN
1. After a PnP-based commissioning task is created on the U2000, SSL-based OMCH

establishment requests are periodically sent by the U2000 to the base station.
The source and destination IP addresses of the request packets are the IP address of the
U2000 and the O&M IP address of the base station, respectively.
Upon receiving the requests, the next-hop gateway of the base station sends ARP
broadcast packets to the base station to parse the MAC address corresponding to the
interface IP address of the base station.
2. The base station obtains VLAN information.
For details, see section "3.2.8 Obtaining VLAN Information for DHCP Packets."
3. The base station first sends DHCP packets without VLAN IDs and then DHCP packets
with VLAN IDs. By exchanging the DHCP packets with the DHCP server, the base
station obtains OMCH configurations and makes them take effect.
4. Based on the CA information obtained from the DHCP server, the base station applies
for an operator-issued device certificate from the CA. For details, see section "3.3.2.5
Obtaining an Operator-Issued Device Certificate."
5. In response to the OMCH establishment requests from the U2000, the base station
performs mutual authentication with the U2000 using the obtained device certificate.
After the authentication is successful, an OMCH is established between them.
In this scenario, the U2000 DHCP server delivers configurations to the base station. The
configurations include those described in section "3.3.2.3 Configuration Requirements for
the DHCP Server" and CA information described in Table 3-8.
Table 3-8 Parameters specific to the U2000 DHCP server
Param Parame Subcod Length (Bytes) Parameter Man DHCP

eter ter e Description dato Packet
Catego Name ry Involv
ry or ed
Opti
onal
CA CA URL 44 1 to 128 URL of the CA Man l DH

informa from which the dator CPO
tion base station y FFE
obtains an R
operator-issued l DH
device certificate CPA
in IPsec CK
networking
scenarios
This URL must
be reachable in
the untrusted
domain.
CA 38 1 to 127 CA name
Name

SingleRAN
3.3.2.5 Obtaining an Operator-Issued Device Certificate

After obtaining the interface IP address and CA information, the base station generates a
certificate request file. The base station then uses this certificate request file to apply for an
operator-issued device certificate from the CA (obtained through the DHCP procedure) based
on CMPv2.
During the certificate application, the CA authenticates the base station by verifying its
Huawei-issued device certificate. All UMPT/UMDU/GTMUc boards and the LMPT boards
of SRAN7.0 or later are preconfigured with Huawei-issued device certificates before
shipment. During the certification application, the base station provides the CA with Huawei-
issued device certificates as its identity. The CA is also preconfigured with a Huawei root
certificate.
Before the certificate application, the base station obtains from the DHCP server partial
configuration data (such as the URL of the CA and the CA name) rather than the
configuration file. Therefore, the base station uses the default parameters described in Table
3-9 to complete the certificate application. The base station cannot contain parameters other
than those listed in the table during the certification application or in the certificate request
files.
NOTE
l For details about the certificate application procedure, see the "Certificate Management and
Application Scenarios" part in PKI Feature Parameter Description for SingleRAN.
l PKI redundancy is not supported during base station deployment by PnP. The active PKI server must
work properly during base station deployment by PnP.
l Huawei-issued device certificates deployed on the GTMUc boards in the GBTSs can only be used
for encrypting the connections between the GBTSs and the site maintenance terminal (SMT). These
certificates cannot be used to obtain operators' certificates during automatic OMCH establishment.
However, those deployed on the GTMUc boards in the eGBTSs can be used to obtain operators'
certificates during automatic OMCH establishment.
Table 3-9 Default parameters used for certificate application
Parame Parameter Parameter Description Remarks

ter Name
Catego
ry
CMPv2 Source IP Source IP address used to This parameter is set to the

-related apply for the operator- interface IP address of the base
paramet issued device certificate station that is obtained through
ers the DHCP procedure.
CA URL URL of the CA This parameter is set to the URL

During Site of the CA that is obtained through
Deployment the DHCP procedure.
Signature Signature algorithm for This parameter is set to SHA256.

Algorithm CMP messages NOTE
This parameter is set to SHA1 in
versions earlier than SRAN10.1, and
to SHA256 in SRAN10.1 and later
versions.

SingleRAN

ter Name
Catego
ry
Paramet Request Type of a certificate This parameter is set to NEW.

ers in Type request. The request can be
the either a new certificate
certifica request or a certificate
te update request. The default
request type is new certificate
file request.
Certificate Format of a certificate This parameter is set to CRMF.

Request File request file
Format
Renew Key Whether to generate a new This parameter is set to YES.

key pair
Key Size Length of a key This parameter is set to

KEYSIZE2048.
Common Common name of the This parameter is set to the ESN

Name certificate request file of the base station that applies for
a certificate, which can be
obtained from ESN.huawei.com.
Key Usage Usage of a key KEY_AGREEMENT (key

negotiation),
DATA_ENCIPHERMENT (data
encryption),
KEY_ENCIPHERMENT (key
encryption), and
DIGITAL_SIGNATURE (digital
signature) are selected for this
parameter.
Signature Signature algorithm for a This parameter is set to SHA256.

Algorithm certificate request file NOTE
This parameter is set to SHA1 for a
base station using an LMPT whose
version is SRAN6.0 or earlier, and is
set to SHA256 for a base station
using an LMPT whose version is
SRAN7.0 or later.
Local Name Local name of a base The value of this parameter

station. This parameter is consists of the ESN of the base
used to generate the DNS station and ".huawei.com."
name of the certificate
subject alternative name to
verify the peer's
identification in IKE
negotiation.

SingleRAN

ter Name
Catego
ry
Local IP Local IP address This parameter is set to 0.0.0.0.

NOTE
This parameter cannot be set to the
IP address that the base station
obtains from the DHCP server,
because the obtained IP address may
not be used finally.
In addition to the operator-issued device certificate, the base station also obtains the root
certificate of the CA.
If the application for operator-issued digital certificates fails or the base station receives no
response within about 30 seconds, the preconfigured digital certificates are used to establish
an OMCH.
3.3.2.6 Configuration Requirements for Network Equipment

Table 3-10 describes the configuration requirements for network equipment during base
station deployment by PnP (3.3.2.1 Introduction to Non-IPsec Networking is used as an
example).
Table 3-10 Configuration requirements for network equipment

Network Requirement
Equipment
L2 device l Allows the transmission of DHCP broadcast and unicast

packets without filtering or modifying DHCP packets.
l Is configured with correct VLAN information.
Next-hop gateway of l Is enabled with the DHCP relay agent function and configured
the base station with the IP address of the DHCP server, which is the IP
address of the U2000. If an NAT server is deployed, the IP
address of the U2000 must be converted by the NAT server.
l Is configured with a route of which the destination IP address
is the DHCP server IP address
l If the base station's OM IP address is not its interface IP
address, configure a route of which the destination IP address
is the OM IP address of the base station.
is the IP address of the CA if the OMCH uses SSL
authentication.

SingleRAN
Network Requirement
Equipment
L3 device l Is configured with a route of which the destination IP address

is the OM IP address of the base station or the U2000 IP
address.
is the DHCP relay agent IP address.
is the IP address of the CA if the OMCH uses SSL
authentication.
U2000/BSC Is configured with a route of which the destination IP address is

the OM IP address of the base station.
DHCP server Is configured with a route of which the destination IP address is

the DHCP relay agent IP address.
FTP server l Is configured with a route of which the destination IP address

is the OM IP address of the base station.
l Stores software and configuration files of the base station in a
specified directory.
l Provides access rights, such as the user name and password,
for the base station.
CA l Is configured with the IP address that can be accessed by NEs

(Required only when in the untrusted domain.
the OMCH uses SSL l Is configured with Huawei-issued CA root certificates.
authentication)
3.3.3 Automatic OMCH Establishment in IPsec Networking

Scenario 1
3.3.3.1 Introduction to IPsec Networking Scenario 1

Figure 3-22 shows IPsec networking scenario 1, in which IPsec secures both OMCH data and
DHCP packets.
Figure 3-22 IPsec networking scenario 1

SingleRAN
This type of networking has the following characteristics:

l A public DHCP server and an U2000 DHCP server are deployed in the untrusted domain
and the trusted domain, respectively. The base station obtains the transmission
configuration information (from the public DHCP server) required for establishing a
temporary IPsec tunnel to the SeGW and obtains the formal transmission configuration
information from the U2000 DHCP server.
l The base station in the untrusted domain cannot directly access NEs in the trusted
domain. Instead, packets from the base station must be encrypted over the IPsec tunnel to
the SeGW before being transmitted to the U2000 or BSC in the trusted domain.
l A CA is deployed. During base station deployment, the CA is accessible through IP
addresses of NEs in the untrusted domain (for example, the interface IP address of the
base station).
l After the base station starts, it must apply to the CA for operator-issued digital
certificates before connecting to the SeGW. After obtaining the certificates, the base
station negotiates with the SeGW to establish an IPsec tunnel.

In IPsec networking scenario 1, the base station obtains configuration information as follows:
The base station obtains the following information from the public DHCP server:
l Temporary interface IP address used for accessing NEs in the untrusted domain
l Configuration information used for establishing a temporary IPsec tunnel to the SeGW,
including the SeGW configuration data and the CA configuration data.
The base station obtains digital certificates from the CA.
After establishing the temporary IPsec tunnel, the base station obtains the formal interface IP
address and other OMCH configuration data from the U2000 DHCP server and then
establishes a formal IPsec tunnel.
The obtained information is used for accessing NEs in the trusted domain and referred to as
formal transmission configuration information in this document. The interface IP address
obtained from the public DHCP server can be the same as or different from that obtained from
the U2000 DHCP server.
Figure 3-23 shows the automatic OMCH establishment procedure in IPsec networking
scenario 1.

SingleRAN
Figure 3-23 Automatic OMCH establishment procedure in IPsec networking scenario 1
2. Using the DHCP procedure, the base station obtains the transmission configuration
information (from the public DHCP server) used for establishing a temporary IPsec
tunnel. The information includes the interface IP address of the base station, CA
configuration data, SeGW configuration data, and U2000 DHCP server IP address. For
details about the configuration information on the public DHCP server, see section
"3.3.3.3 Configuration Requirements for the Public DHCP Server."
3. Using CMPv2, the base station applies to the CA for an operator-issued device
certificate. (For details about the certificate application procedure, see section "3.3.3.4
Obtaining an Operator-Issued Device Certificate".) The base station then adds the
obtained certificate to the default trusted certificate list for subsequent IPsec tunnel
establishment and SSL authentication.
4. The base station establishes a temporary IPsec tunnel to the SeGW. For details about the
security parameters used by the base station during the temporary IPsec tunnel
establishment, see section "3.3.3.5 Establishing a Temporary IPsec Tunnel."
5. With protection from the temporary IPsec tunnel, the base station obtains formal
transmission configuration information from the U2000 DHCP server in different ways,
This is determined depending on whether the IP address used for accessing the trusted
domain and the U2000 DHCP server IP address are both available. For details, see
section "3.3.3.7 Obtaining Formal Transmission Configuration Information from
the Internal DHCP Server."
6. The base station releases the temporary IPsec tunnel and uses formal transmission
configuration information to establish a formal IPsec tunnel to the SeGW. For details, see
section "3.3.3.8 Establishing a Formal IPsec Tunnel."
7. After the formal IPsec tunnel is established, the base station waits for the OMCH
establishment request from the U2000/BSC and then establishes an OMCH to the
U2000/BSC. If an OMCH is not established between the U2000/BSC and base station
within 10 minutes, the base station restarts the automatic OMCH establishment
procedure. Because the base station has obtained the operator-issued device certificate,
SSL authentication is supported between the U2000 and base station.

SingleRAN
NOTE
station changes its current RAT and is restarted. Then the base station reinitiates a DHCP
procedure.
If any steps (except step 1) fail during the automatic OMCH establishment procedure, the base
station automatically restarts the procedure.
IPsec Redundancy Among Multiple SeGWs is not supported during base station deployment by
PnP when multiple SeGWs are configured. The active SeGW must work properly during base
station deployment by PnP.
3.3.3.3 Configuration Requirements for the Public DHCP Server

The public DHCP server must be configured with the parameters listed in Table 3-11. The
server must also be configured with a route of which the destination IP address is the IP
address of the base station or of which the destination network segment is the network
segment of the base station. Unless otherwise specified, these parameters are contained in
subcodes of Option 43 in DHCP packets.
Table 3-11 Parameters to be configured on the public DHCP server
Classificatio Paramete Subco Length Parameter Mandator DHCP

n r Name de (Bytes) Descriptio y or Packet
n Optional Involve
d
CA PKI 35 4 IP address Mandatory l DHC

information SERVER of the CA only if POF
IP identity FER
authenticat l DHC
ion by PAC
digital K
certificates
is required
and the CA
URL is not
configured.
These
parameters
collectivel
y identify
and equal
the URL of
the CA.
These four
parameters
cannot be
configured
if the CA
URL has
been
configured.

SingleRAN

n Optional Involve
d
CA 39 1 Protocol l DHC
protocol used to POF
type access the FER
CA: HTTP l DHC
or HTTPS PAC
Value 0 K
indicates
HTTP and
value 1
indicates
HTTPS.
When the
communicat
ion between
the base
station and
CA is
protected by
SSL, this
parameter
must be set
to 1.
CA port 36 2 HTTP or l DHC

HTTPS port POF
number of FE
the CA l DHC
PAC
K
CA Path 37 1 to 60 Path for l DHC

saving POF
digital FE
certificates l DHC
on the CA. PAC
This K
parameter is
optional if
no path is
required for
accessing
the CA.

SingleRAN

n Optional Involve
d
CA URL 44 1 to 128 URL used Mandatory l DHC

for only if the POF
accessing following FE
the digital parameters l DHC
certificate are not PAC
path. configured K
This when
parameter is authenticat
configurable ion by
only when digital
the base certificates
station and is required:
CA use PKI
CMPv2. SERVER
IP, CA
The CA protocol
URL format type, CA
is as port, and
follows: CA Path.
http(s)://
CAIP:CApo
rt/CAPath.
CA Name 38 1 to 127 CA name Mandatory l DHC

only if the POF
base FE
station l DHC
uses the PAC
digital K
certificates
for identity
authenticat
ion

SingleRAN

n Optional Involve
d
SeGW Public 18 4 IP address Mandatory l DHC

information SeGW IP of the public only if the POF
Address SeGW in base FE
IPsec station l DHC
networking needs to PAC
scenarios. access the K
This U2000
parameter is DHCP
allocated by server
the public through the
DHCP SeGW
server and
used during
DHCP
interworkin
g between
the base
station and
the U2000
DHCP
server.
Public 31 1 to 32 Local name Optional l DHC

SeGW of the public when the POF
Local SeGW. SeGW is FE
Name It is used by configured l DHC
the base PAC
station to K
authenticate
the public
SeGW in
IPsec
networking
scenarios.

SingleRAN

n Optional Involve
d
Internal Internal 42 N*4 IP address Optional. l DHC

DHCP server DHCP of the If this POF
IP address Server IP U2000 parameter FE
(list) Address DHCP is l DHC
(List) server that configured, PAC
sends the base K
transmission station can
configuratio send
n unicast
information DHCP
to the base packets to
station. the DHCP
In SRAN8.0 server even
and later if the
versions, a SeGW
maximum cannot
of eight send any
U2000 DHCP
DHCP server IP
server address to
addresses the base
can be station.
configured.
N indicates
the number
of DHCP
servers built
into the
U2000.
Transmission Interface - 4 Carried in Mandatory l DHC

configuration IP the yiaddr POF
information Address field in FE
for the base DHCP l DHC
station packet PAC
headers K
Interface - 4 Carried in Mandatory l DHC

IP DHCP POF
Address option 1 FE
mask l DHC
PAC
K

SingleRAN

n Optional Involve
d
Next-hop - 4 Carried in Mandatory l DHC

Gateway DHCP POF
IP option 3 FE
Address l DHC
PAC
K
All IP addresses or URLs listed in Table 3-11 except Internal DHCP Server IP Address
(List) can be used only in the untrusted domain. Particularly, NEs in the untrusted domain
must have access to the CA IP address and the CA URL. If the base station cannot access the
CA, any operator-issued certificates cannot be retrieved.
NOTE
In IPsec networking scenario 1, the public DHCP server assigns an interface IP address in the IP address
pool to the base station, without parsing the BS ID contained in Option 43. Therefore, the BS ID
contained in DHCP packets is meaningless in such a scenario.
3.3.3.4 Obtaining an Operator-Issued Device Certificate

The base station generates a certificate request file after a temporary IP address and CA
information is retrieved. The base station then uses this certificate request file to apply for an
operator-issued device certificate from the CA (obtained through the DHCP procedure) based
on CMPv2.
Before the certificate application, the base station obtains from the DHCP server partial
configuration data (such as the URL of the CA and the CA name) rather than the
configuration file. The default parameters for certificate application are the same as those
listed in Table 3-9 except for those listed in Table 3-12.
Table 3-12 Default parameters used for certificate application

Parameter Parameter Parameter Remarks
Category Name Description
CMPv2- CA URL During URL of the CA This parameter is set to the

related Site Deployment URL of the CA configured
parameters on the public DHCP server,
or to a combination of CA
Protocol, CAIP, CA Path,
and CA Port.
NOTE
CA Path is optional. Whether
it is required depends on the
relative path of the CA in
which CMPv2 services are
provided for the base station.

SingleRAN
In addition to the operator-issued device certificate, the base station also obtains the root
certificate of the CA. The base station then uses both certificates to perform mutual
authentication with the SeGW on the operator's network. After the authentication is
successful, the base station and SeGW establish an IPsec tunnel, through which the base
station accesses the internal DHCP server and the U2000 in the trusted domain.
3.3.3.5 Establishing a Temporary IPsec Tunnel

After the base station obtains the transmission configuration information (including the
interface IP address, SeGW IP address, and CA IP address) from the public DHCP server, the
base station obtains digital certificates from the CA and then establishes a temporary IPsec
tunnel to the SeGW. For details about the temporary IPsec tunnel establishment, see IPsec
Feature Parameter Description for SingleRAN. For details about the procedure for obtaining
digital certificates, see PKI Feature Parameter Description for SingleRAN. This section
describes the IPsec and IKE proposal algorithms used by the base station during deployment
by PnP.
IKEv1 and IKEv2 are incompatible. During base station deployment by PnP, the base station
cannot predict the IKE version used by the SeGW. If the base station successfully negotiated
an IKE version with the SeGW, the base station preferentially uses this IKE version.
Otherwise, the base station uses IKEv2 before IKEv1.
IKE SA Negotiation
During IKE SA negotiation in the normal operation of the base station, the base station
supports a large number of algorithm combinations. However, during base station deployment
by PnP, the base station supports only the 48 algorithm combinations in Table 3-13 and the 9
algorithm combinations in Table 3-14 in the IKEv2 proposal and the 120 algorithm
combinations in Table 3-15 in the IKEv1 proposal.
NOTE
The 48 algorithm combinations in the IKEv2 proposal are obtained as follows: Encryption Algorithm
has four values, Authentication Algorithm has two values, Diffie-Hellman Group has three values, and
PRF Algorithm has two values. Therefore, the number of algorithm combinations in the IKEv2 proposal
is 48 (4 x 2 x 3 x 2).
The 120 algorithm combinations in the IKEv1 proposal as well as the 9 algorithm combinations in the
IKEv2 proposal are obtained in the same way as the 48 algorithm combinations in the IKEv2 proposal.
Considering the negotiation efficiency, the SHA256 and HMAC_SHA256 algorithms added to the
IKEv2 proposal support only the nine combinations described in Table 3-14.
Table 3-13 Algorithms in the IKEv2 proposal
Encryption Authentication Diffie-Hellman PRF Algorithm

Algorithm Algorithm Group
3DES SHA1 DH_GROUP2 HMAC_SHA1
AES128 AES_XCBC_96 DH_GROUP14 AES128_XCBC
AES192 - DH_GROUP15 -
AES256 - - -

SingleRAN
Table 3-14 Algorithms added to the IKEv2 proposal
Encryption Authentication Diffie-Hellman PRF Algorithm

Algorithm Algorithm Group
AES128 SHA256 DH_GROUP2 HMAC_SHA256
AES192 DH_GROUP14
AES256 DH_GROUP15
Table 3-15 Algorithms in the IKEv1 proposal
Encryption Authentication Diffie-Hellman Authentication

Algorithm Algorithm Group Method
(Only IKEv1)
DES MD5 DH_GROUP1 PSK
3DES SHA1 DH_GROUP2 RSA-SIG
AES128 - DH_GROUP14 DSS-SIG
AES192 - DH_GROUP15 -
AES256 - - -
To improve the negotiation efficiency, the base station first uses the IKEv2 negotiation. If the
negotiation fails, the base station then implements IKEv1 negotiation. If the negotiation
continues to fail, the base station obtains transmission configuration from the public DHCP
server again to set up a temporary IPsec tunnel and then restarts an IKE SA negotiation.
During PnP-based deployment, the base station without initial configuration requires that all
supported algorithm combinations be negotiated with the peer end. Some SeGWs may only
negotiate the required algorithm combinations. As a result, the negotiation fails. Ensure that
the peer end can negotiate planned algorithm combinations. For example, if a SeGW has its
authentication algorithm set to SHA256 or its pseudo random algorithm set to
HMAC_SHA256, and the SeGW uses only the first five algorithm combinations required by
the base station for negotiation, the negotiation fails. This is due to the planned SHA256
(HMAC_SHA256) algorithm is not among the first five algorithm combinations. As a result,
the PnP-based deployment fails. Table 3-16 lists the first five algorithm combinations in the
IKEv2 proposal.
Table 3-16 First five algorithms combinations in the IKEv2 proposal
Seque Encryption Authentication Diffie-Hellman PRF Algorithm

nce Algorithm Algorithm Group (Only IKEv2)
1 AES128 SHA1 DH-Group2 HMAC-SHA1
2 3DES SHA1 DH-Group2 HMAC-SHA1

SingleRAN
3 AES256 AES_XCBC_96 DH_GROUP15 AES128_XCBC
4 AES192 SHA1 DH_GROUP14 HMAC_SHA1
5 AES128 SHA1 DH_GROUP14 HMAC_SHA1
NOTE
During base station deployment by PnP, the IDTYPE parameter in the IKEPEER MO is set to FQDN
by default and the base station uses SubjectAltName in the digital certificate as the local name of the
base station for IKE negotiation.
IPsec SA Negotiation
During IPsec SA negotiation in the normal operation of the base station, the base station
supports ESP and AH authentication in tunnel or transport mode. However, during base
station deployment by PnP, the base station only supports ESP authentication in tunnel mode.
During IPsec SA negotiation in the normal operation of the base station, the base station
supports multiple IPsec proposal algorithm combinations. However, during base station
deployment by PnP, the base station supports only the encryption and authentication
algorithm combinations listed in Figure 3-24. The base station performs IPsec SA negotiation
in two steps. It first uses the six algorithm combinations marked in green and then the six
algorithm combinations marked in gray. Once IKE negotiation is successful, the base station
applies this algorithm combination.
Figure 3-24 Encryption and authentication algorithms in IPsec proposal
The base station uses IKE version and algorithm combinations in the following priority
sequence:
1. IKEv2 and algorithm combinations marked in green
2. IKEv2 and algorithm combinations marked in gray
3. IKEv1 and algorithm combinations marked in green
4. IKEv1 and algorithm combinations marked in gray

SingleRAN
NOTE
During base station deployment by PnP, the base station does not use all supported IPsec and IKE
proposal algorithms when establishing an IPsec tunnel. This is because trying all supported
combinations of security parameters may take a long time. For example, the base station will not try the
DES algorithm during the PnP-based deployment even when it supports the DES algorithm because the
algorithm is not secure.
During base station deployment by PnP, the base station must use tunnel mode instead of transfer mode
as the encapsulation mode when establishing an IPsec tunnel. This is because the U2000, BSC, DHCP
server, and FTP server do not support IPsec.
During base station deployment by PnP, the base station does not try the perfect forward secrecy (PFS).
If the IPsec and IKE proposal algorithms and their settings on the base station or SeGW side
are inconsistent with those tried during base station deployment by PnP, OMCH establishment
may fail, leading to deployment failures. Therefore, ensure that the IPsec and IKE proposal
algorithms and their settings on the base station or SeGW side are consistent with those tried
during PnP-based deployment.
3.3.3.6 Configuration Requirements for the Internal DHCP Server

The U2000 DHCP server must be configured with the parameters listed in Table 3-7 as well
as the parameters listed in Table 3-17. These parameters are contained in subcodes of Option
43 in DHCP packets.
Table 3-17 Parameters specific to the U2000 DHCP server in IPsec networking scenario 1
Classific Paramete Subcode Length Paramete Mandato DHCP
ation r Name (Bytes) r ry or Packet
Descripti Optional Involved
on
SeGW Serving 20 4 IP address Mandator l DHCP

informatio SeGW IP of the y OFFE
n serving R
SeGW in l DHCP
IPsec ACK
networkin
g
scenarios

SingleRAN

on
Serving 32 1 to 32 Local Optional

SeGW name of
Local the
Name serving
SeGW. It
is
provided
by the
base
station to
authentica
te the
serving
SeGW in
IPsec
networkin
g
scenarios
CA CA URL 44 1 to 128 URL of Mandator DHCPOF

informatio the CA y FER
n from DHCPAC
which the K
base
station
obtains an
operator-
issued
device
certificate
in IPsec
networkin
g
scenarios
CA Name 38 1 to 127 Name of

the CA
3.3.3.7 Obtaining Formal Transmission Configuration Information from the

Internal DHCP Server
RFC 4306, the standard protocol for IKEv2, defines the MODE-CONFIG mode in which the
base station uses the configuration payload (CP) to apply to the SeGW for certain
configuration information. Using the MODE-CONFIG mode during IKE negotiation, the base
station can obtain one temporary logical IP address used for accessing the trusted domain and
one U2000 DHCP server IP address. The base station can obtain one U2000 DHCP server IP
address at most.

SingleRAN
NOTE
In IKEv1, CP is not standardized and is referred to as MODE-CONFIG, which is supported only by the
base station in aggressive mode. For details about the MODE-CONFIG, see RFC4306 Internet Key
Exchange (IKEv2) Protocol.
The base station follows procedures listed in Table 3-18 to obtain formal transmission
configuration information from the U2000 DHCP server, depending on whether the logical IP
address used for accessing the untrusted domain and any U2000 DHCP server IP address are
available.
Table 3-18 Obtaining formal transmission configuration information from the U2000 DHCP
server
If... Then... Configuration
Requirements for NEs
The base station has l The base station uses the See Table 3-19.
obtained the interface IP logical IP address for
address, logical IP address, accessing the trusted
and U2000 DHCP server IP domain as the source IP
address. address, and uses any
NOTE U2000 DHCP server IP
The base station obtains the address as the destination
preceding IP addresses in IP address. The base
different ways: Interface IP station then unicasts
address: from the DHCP
DHCP packets to each
procedure Logical IP address:
from MODE-CONFIG mode U2000 DHCP server.
during IKE negotiation U2000 Only the U2000 DHCP
DHCP server IP address: from server that has the
the DHCP procedure or from correct BS ID sends
MODE-CONFIG mode during configuration
IKE negotiation
information to the base
station.
l The base station
automatically configures
an access control list
(ACL) rule in Any to
Any mode that allows
DHCP packets to reach
the base station.

SingleRAN

The base station has l The base station uses the See Table 3-20.
obtained the interface IP interface IP address for
address and U2000 DHCP accessing the untrusted
server IP address, but not domain as the source IP
the logical IP address. address, and uses any
U2000 DHCP server IP
address as the destination
IP address. The base
station then unicasts
DHCP packets to each
U2000 DHCP server.
Only the U2000 DHCP
server that has the
correct BS ID sends
configuration
information to the base
station.
l The base station
an ACL rule that allows
the base station. In the
ACL rule, the source IP
address is the interface
IP address and the
destination IP address is
an U2000 DHCP server
IP address. If there are
multiple U2000 DHCP
servers, one ACL rule is
generated for each
connected U2000 DHCP
server.

SingleRAN

The base station has not l The base station uses See Table 3-21.
obtained the logical IP 0.0.0.0 as the source IP
address for accessing the address and
trusted domain or any 255.255.255.255 as the
U2000 DHCP server IP destination IP address to
address. broadcast DHCP packets
over an IPsec tunnel. The
packets are encapsulated
over the IPsec tunnel
before reaching the
SeGW.
l The base station
an ACL rule that allows
the base station. In the
ACL rule, the source
UDP port number is 68
and the destination UDP
port number is 67.
Table 3-19 Configuration requirements for network equipment (1)

NE Requirement
Public DHCP server l Is configured with one to eight U2000

DHCP server IP addresses only if the
SeGW is not configured with any U2000
DHCP server IP address.
l No preceding configuration is required if
the SeGW is configured with a U2000
DHCP server IP address.
l For detailed configurations, see Table
3-11.

SingleRAN
NE Requirement
SeGW l Supports the MODE-CONFIG mode so

that the SeGW sends a temporary logical
IP address and an U2000 DHCP server
IP address to the base station.
Alternatively, the SeGW sends a
temporary logical IP address and the
public DHCP server sends an U2000
DHCP server IP address. It is
recommended that the operator plan all
temporary logical IP addresses for
accessing the trusted domain on the
same network segment and on a different
network segment from the OM IP
address of the base station.
l Automatically generates an ACL rule in
Temporary Logical IP to Any mode after
using the MODE-CONFIG mode to send
the U2000 DHCP server IP address. This
eliminates the need to manually
configure associated ACL rules. If an
ACL rule is manually configured that the
source IP address is the temporary
logical IP address for accessing the
trusted domain, the IP addresses of all
U2000 DHCP servers must be on the
network segment defined by this ACL
rule.
All NEs between the base station and the l Is configured with the firewall policy or
U2000 DHCP server the packet filtering policy so that they
allow the transmission of packets with
67 or 68 as the source and destination
UDP port number.
l Is configured with a route whose
destination IP address is the logical IP
address for accessing the trusted domain
or network segment of the logical IP
address so that related packets can be
routed to the SeGW.
U2000 DHCP server Is configured with a route whose destination

IP address is the logical IP address of the
base station.

SingleRAN

NE Requirement
Public DHCP server Is configured with one to eight U2000

DHCP server IP addresses.
For detailed configurations, see Table 3-11.
UDP port number.
destination IP address is the interface IP
address of the base station or the IP
address of the network segment.

IP address is the interface IP address of the
base station.

NE Requirement
Public DHCP server For detailed configurations, see Table 3-11,

in which the IP address of the internal
DHCP server does not need to be
configured.
SeGW Supports sending DHCP broadcast packets

in IPsec tunnels, in compliance with RFC
3456.
UDP port number.
destination IP address is the IP address
of the DHCP relay agent on the SeGW.

IP address is the IP address of the DHCP
relay agent on the SeGW.
The base station obtains transmission configuration information in IPsec networking scenarios
differently from non-IPsec networking scenarios:

SingleRAN
l The DHCP server can be deployed only on the U2000, not the base station controller.
That is, the U2000 DHCP server is used.
l The base station may obtain IP addresses of many DHCP servers. Therefore, it needs to
communicate with each DHCP server to find the correct DHCP server. IPsec secures
OMCH data.
l Therefore, among the configuration information sent by the U2000 DHCP server to the
base station, the SeGW IP address is mandatory and the local name of the SeGW is
optional. The local name of the SeGW is used to authenticate the SeGW.
3.3.3.8 Establishing a Formal IPsec Tunnel

The SeGW IP address obtained from the U2000 DHCP server may or may not be the same as
the SeGW IP address obtained from the public DHCP server. In either case, the base station
needs to negotiate an IKE SA and an IPsec SA with the SeGW before establishing a formal
tunnel to the SeGW. The SeGW is identified by the SeGW IP address in the configuration
information from the U2000 DHCP server.
The procedure for establishing a formal IPsec tunnel differs from the procedure for
establishing a temporary IPsec tunnel as follows:
l The base station uses the interface IP address delivered by the U2000 DHCP server and
SeGW IP address delivered by the U2000 DHCP server for IKE SA and formal IPsec
establishment negotiations between the base station and SeGW. During IPsec tunnel
establishment, the base station automatically configures an ACL rule in OM IP to Any
mode and the SeGW configures an ACL rule in Any to OM IP or Any to Any mode.
l The base station preferentially tries the IKE proposal algorithm and IPsec proposal
algorithm with which the temporary IPsec tunnel was successfully established to
establish the formal IPsec tunnel. If this fails, the base station follows the sequence
described in the "3.3.3.5 Establishing a Temporary IPsec Tunnel" to try other IKE
proposal algorithms and IPsec proposal algorithms.
3.3.3.9 Establishing an OMCH

The procedure for establishing an OMCH in an IPsec networking scenario is similar to that in
a non-IPsec networking scenario, except that, in an IPsec networking scenario, the U2000 and
base station must authenticate each other after the base station obtains operator-issued
certificates. The operator can choose to use SSL for the authentication. To authenticate the
base station, a device certificate and root certificate must be configured for the U2000.

Table 3-22 lists the configuration requirements for NEs in IPsec networking scenario 1.
Table 3-22 Configuration requirements for NEs in IPsec networking scenario 1
Network Requirement
Equipment
L2 device l Allows the transmission of DHCP broadcast and unicast packets

without filtering or modifying DHCP packets.
l Is configured with correct VLAN information.

SingleRAN
Network Requirement
Equipment
Next-hop gateway l Is configured as the DHCP server or enabled with the DHCP relay
of the base station agent.
l Is configured with correct DHCP server IP addresses.
l Is configured with routes whose destination addresses are the
DHCP server IP address, CA IP address, and SeGW IP address,
respectively.
L3 device l (NEs in the untrusted domain): Is configured with routes whose

destination addresses are the temporary and formal interface IP
addresses of the base station, CA IP address, and SeGW IP
address.
l (NEs in the trusted domain): Is configured with three routes
whose destination addresses are the OM IP address of the base
station, U2000 IP address, and FTP server IP address.
U2000 Is configured with a route whose destination IP address is the OM IP

U2000 DHCP Is configured with a route whose destination IP address is that of the
server DHCP relay agent when the SeGW serves as the DHCP relay agent.
If the SeGW does not serve as the DHCP relay agent, the U2000
DHCP server is configured with a route whose destination IP address
is the temporary interface IP address of the base station.
FTP server l Is configured with a route whose destination IP address is the OM

IP address of the base station.
l Stores software and configuration files of the base station in the
specified directory.
l Provides access rights, such as the user name and password, for
the base station.

SingleRAN
Network Requirement
Equipment
SeGW l Allows DHCP packets to be exchanged between the base station

and the U2000.
l Allows packets to be exchanged between the base station and the
U2000 over an OMCH and between the base station and the FTP
server.
l Is configured with security parameters listed in Table 3-12.
l Is configured with ACL rules that allow the transmission of
packets sent from the base station during the DHCP procedure.
l Is configured with an "any to any" ACL rule or "any to base
station OM IP" ACL rule.
l Is enabled with the DHCP relay agent function if the SeGW
complies with RFC 3456.
l Is configured with related IP address pool and assignment rules if
the SeGW needs to assign an IP address for accessing the trusted
domain or a DHCP server IP address to the base station.
l Is configured with operator-issued CA certificates and its own
certificates.
CA l Is configured with the IP address that can be accessed by NEs in

the untrusted domain.
l Is configured with Huawei-issued CA root certificates.

Scenario 2

Figure 3-25 shows IPsec networking scenario 2, in which IPsec secures all packets except
DHCP packets.

SingleRAN

l An U2000 DHCP server in the trusted domain is deployed. IPsec does not secure DHCP
packets. Using a DHCP procedure in the untrusted domain, the base station obtains its
temporary IP address and the OM IP address, the SeGW IP address, and the CA IP
address. From the U2000 DHCP server, the base station obtains the formal transmission
The base station in the untrusted domain cannot directly access NEs in the trusted
domain. Instead, packets from the base station must be encrypted over the IPsec tunnel to
the SeGW before being transmitted to the U2000 or BSC in the trusted domain.
l A CA is deployed and provides digital certificates for the base station to perform mutual
authentication with other NEs. During PnP-based base station deployment, the CA can
be accessed through IP addresses of NEs in the untrusted domain (for example, the
interface IP address of the base station).
l After the base station starts, it must apply to the CA for operator-issued digital
certificates before connecting to the SeGW. Then the base station negotiates the IPsec
tunnel with the SeGW.

In IPsec networking scenario 2, the base station must obtain the base station IP address and
CA IP address from the U2000 DHCP server, and then obtain digital certificates from the CA.
scenario 2.
2. The base station obtains required configuration information from the U2000 DHCP
server. The information includes the OM IP address of the base station, the CA IP
address, and the SeGW address.

SingleRAN
NOTE
station changes its current RAT and then restarts. Afterwards, the base station reinitiates a DHCP
procedure.
3. By using the configuration information obtained from the U2000 DHCP server, the base
station applies to the CA for an operator-issued device certificate. (For details about the
certificate application procedure, see section "3.3.2.5 Obtaining an Operator-Issued
Device Certificate.") The base station then adds the obtained certificate to the default
trusted certificate list for subsequent IPsec tunnel establishment and SSL authentication.
4. By using the configuration information obtained from the U2000 DHCP server, the base
station establishes a formal IPsec tunnel to the SeGW.
5. After the formal IPsec tunnel is established, the base station waits for the OMCH
establishment request from the U2000/BSC and then establishes an OMCH to the
U2000/BSC. Because the base station has obtained the operator-issued device certificate,
SSL authentication is supported between the U2000 and base station.
NOTE
If an IPsec tunnel or OMCH fails to be established, the base station automatically restarts the automatic
OMCH establishment procedure.
IPsec Redundancy Among Multiple SeGWs is not supported during base station deployment by PnP when
multiple SeGWs are configured. The active SeGW must work properly during base station deployment by
PnP.

The U2000 DHCP server must be configured with the parameters listed in Table 3-7 as well
as the parameters listed in Table 3-23. These parameters are contained in subcodes of Option
43 in DHCP packets.
on
SeGW Serving 20 4 IP address Mandator DHCPOF

informatio SeGW IP of the y FER
n SeGW in
IPsec DHCPAC
networkin K
g
scenarios

SingleRAN

on
Serving 32 1 to 32 Local
SeGW name of
Local the
Name serving
SeGW. It
is
provided
by the
base
station to
authentica
te the
serving
SeGW in
IPsec
networkin
g
scenarios
CA CA URL 44 1 to 128 URL from Mandator DHCPOF

informatio which the y FER
n base DHCPAC
station K
obtains an
operator-
issued
device
certificate
in IPsec
networkin
g
scenarios.
This URL
must be
accessible
to NEs in
the
untrusted
domain.
CA Name 38 1 to 127 Name of

the CA

Table 3-24 lists the configuration requirements for network equipment in IPsec networking
scenario 2.

SingleRAN
Table 3-24 Configuration requirements for network equipment in IPsec networking scenario 2
Network Requirement
Equipment
L2 devices l Allow the transmission of DHCP broadcast and unicast packets

without filtering or modifying DHCP packets.
l Are configured with correct VLAN information.
Next-hop gateway l Is enabled with the DHCP relay agent function and is configured
of the base station with correct DHCP server IP addresses.
l Is configured with routes whose destination IP addresses are the
DHCP server IP address, CA IP address, and SeGW IP address.
L3 devices l (NEs in the untrusted domain): Are configured with routes to the
interface IP addresses of the base station and routes to the CA
and the SeGW.
l (NEs in the trusted domain): Are configured with a route whose
destination IP address is the OM IP address of the base station
and routes whose destination IP addresses are that of the U2000
and of the FTP server.
U2000 Is configured with a route whose destination IP address is the OM IP

U2000 DHCP Is configured with a route whose destination IP address is the DHCP
server relay agent IP address.
SeGW l Allows packets to be exchanged between the base station and the
U2000 over an OMCH and between the base station and the FTP
server.
l Is configured with security parameters listed in Table 3-13,
Table 3-15, and Table 3-24.
l Is configured with an "any to any" or "any to base station OM
IP" ACL rule.
l Is configured with operator-issued CA certificates and its own
certificates.
CA l Is configured with the following: An IP address that can be

accessed by NEs in the untrusted domain.
l Huawei-issued CA root certificates.

Scenario 3

Figure 3-27 shows IPsec networking scenario 3, in which IPsec secures service and signaling
data, but not DHCP packets or OMCH data.

SingleRAN

l An U2000 DHCP server is deployed as the only DHCP server in the network. The base
station obtains the OMCH configuration data and CA configuration data from the U2000
DHCP server. IPsec does not secure DHCP packets.
l IPsec does not secure OMCH data. The base station uses the OM IP address to access
NEs in the untrusted domain. IPsec tunnels established between the base station and the
SeGW are used to secure signaling and service data.
l Either party involved in IPsec negotiation uses digital certificates or PSK to authenticate
the other party.
l A CA is required if digital certificates are used for authentication. After the base station
starts, it must apply to the CA for operator-issued digital certificates before connecting to
the SeGW. During base station deployment, the CA is accessible through IP addresses of
NEs in the untrusted domain (for example, the interface IP address of the base station).

scenario 3.

SingleRAN
2. The base station obtains the OMCH configuration data and CA configuration data
(optional) from the U2000 DHCP server. If the base station uses the PSK for
authentication, the base station does not need to obtain the CA configuration data. If the
base station uses digital certificates for authentication, the base station must obtain the
CA configuration data.
NOTE
During a DHCP procedure, a DHCP response packet sent by the U2000 contains the target RAT for the
base station. Upon detecting an inconsistency between the current and target RATs, the base station
changes its current RAT and then restarts. Afterwards, the base station reinitiates a DHCP procedure.
3. The base station applies to the CA for an operator-issued device certificate if it has
obtained CA information. (For details about the certificate application procedure, see
section "3.3.2.5 Obtaining an Operator-Issued Device Certificate.") The base station
then adds the obtained certificate to the default trusted certificate list for subsequent
IPsec tunnel establishment and SSL authentication.
4. Based on the configuration information obtained from the U2000 DHCP server, the base
station establishes an OMCH to the U2000 or BSC. Because the base station has
obtained the operator-issued certificate, SSL authentication is supported between the
U2000 and base station.
NOTE
If an IPsec tunnel or OMCH fails to be established, the base station automatically restarts the automatic
OMCH establishment procedure. After the OMCH is established, the base station obtains the official
configuration information and makes the configuration take effect. Then, the base station restarts and
establishes an IPsec tunnel to the SeGW to secure services and signaling.

If the base station uses digital certificates for authentication, the U2000 DHCP server must be
configured with the parameters listed in both Table 3-7 and Table 3-25. These parameters are
contained in subcodes of Option 43 in DHCP packets.

SingleRAN
on
CA CA URL 44 1 to 128 URL from Mandator DHCPOF

informatio which the y FER
n base
station DHCPAC
obtains an K
operator-
issued
device
certificate
in IPsec
networkin
g
scenarios.
This URL
must be
accessible
by
network
equipment
in the
untrusted
domain,
that is, the
interface
IP address
that the
base
station
obtains
from the
U2000
DHCP
server
must be
accessible.
CA Name 38 1 to 127 CA name

Table 3-26 lists the configuration requirements for network equipment in IPsec networking
scenario 3.

SingleRAN
Table 3-26 Configuration requirements for network equipment in IPsec networking scenario 3
Network Equipment Requirement
L2 device l Allows the transmission of DHCP

broadcast and unicast packets without
filtering or modifying DHCP packets.
l Is configured with correct VLAN
information.
Next-hop gateway of the base station l Is enabled with the DHCP relay agent
function and configured with the IP
address of the DHCP server, that is, the
IP address of the U2000. If an NAT
server is deployed, the IP address of the
U2000 must be that converted by the
NAT server.
destination IP address is the DHCP
server IP address.
destination IP address is the OM IP
address of the base station if the OM IP
address is not the same as the interface
IP address of the base station.
destination IP address is the CA IP
address.
L3 device l (NEs in the untrusted domain): Is

configured with a route whose
destination IP address is the IP address
of the base station, a route whose
address of the base station, a route
whose destination IP address is the
U2000, a route whose destination IP
address is the FTP server, and a route
whose destination IP address is the CA.
l (NEs in the trusted domain): Is
configured with a route whose
address of the base station and routes
whose destination IP addresses are the
U2000 IP address and FTP server IP
address.
U2000 Is configured with a route whose destination

IP address is the OM IP address of the base
station.

IP address is that of the DHCP relay agent.

SingleRAN
Network Equipment Requirement
CA l Is configured with the IP address that

can be accessed by devices in the
untrusted domain.
l Is configured with Huawei-issued CA
root certificates.
3.4 Automatic OMCH Establishment by the Separate-MPT

Multimode Base Station
3.4.1 Networking
A separate-MPT multimode base station can use independent transmission or common
transmission. When independent transmission is used, the OMCH setup procedure is the same
as that in a single-mode base station. This section describes only common transmission.
Boards in a separate-MPT multimode base station can communicate with each other through
panel interconnection or backplane interconnection. Generally, the transmission board of a
certain mode provides a shared transmission interface for connecting to the transport network.
The base station in this mode is called an upper-level base station, and base stations in the
other modes are called lower-level base stations. The upper-level base station acts as the
DHCP relay agent of lower-level base stations.
Figure 3-29 shows the OMCH networking for the separate-MPT multimode base station that
uses panel-based interconnection. The upper-level base station provides two transmission
interfaces, one for panel-based interconnection (lower transmission interface) and the other
for connecting to the transport network (upper transmission interface).
Figure 3-29 OMCH networking for the separate-MPT multimode base station that uses panel-
based interconnection

SingleRAN
Figure 3-30 shows the OMCH networking for the separate-MPT multimode base station that
uses backplane-based interconnection.
Figure 3-30 OMCH networking for the separate-MPT multimode base station that uses
backplane-based interconnection
The automatic OMCH establishment procedure for the separate-MPT base station is similar to
the respective automatic OMCH establishment procedure for each single-mode base station.
Lower-level base stations can start the automatic OMCH establishment procedure only after
the upper-level base station completes the procedure. This section describes the differences in
the procedures between the separate-MPT base station and the single-mode base station.
3.4.2 Automatic OMCH Establishment Procedure

Figure 3-31 shows the automatic OMCH establishment procedure for the separate-MPT
multimode base station.
Figure 3-31 Automatic OMCH establishment procedure

SingleRAN
1. Same as the single-mode base station, the upper-level base station follows the OMCH
establishment procedure described in chapter "3.3-Automatic OMCH Establishment
by Single-mode Base Station, CloudRANCU_P, and Co-MPT Multimode Base
Station." The upper-level base station then obtains software and configuration files from
the U2000 or BSC over the established OMCH. The upper-level base station activates
software and configuration files and then enters the working state. For details about the
automatic OMCH establishment for a single-mode base station, see 3.3-Automatic
OMCH Establishment by Single-mode Base Station, CloudRANCU_P, and Co-
MPT Multimode Base Station.
2. Each lower-level base station exchanges DHCP packets with the DHCP relay agent
(upper-level base station) and the DHCP server to obtain the transmission configuration
information.
3. Each lower-level base station establishes an OMCH to the U2000 or BSC.
The DHCP servers of the upper-level base station and lower-level base stations can be
deployed on the same NE or different NEs.
NOTE
During a DHCP procedure, a DHCP response packet sent by the U2000 contains the target RAT for the
base station. Upon detecting an inconsistency between the current and target RATs, the base station
changes its current RAT and then restarts. Afterwards, the base station reinitiates a DHCP procedure.
3.4.3 Configuration Requirements for the DHCP Server

Each mode in a separate-MPT multimode base station has almost the same configuration
requirements for the DHCP server as a single-mode base station. The only difference lies in
the setting of the OM Bearing Board parameter on DHCP servers of lower-level base
stations, as described in Table 3-27. For details about the configuration requirements for the
DHCP server of each single-mode base station, see chapter "3.3-Automatic OMCH
Establishment by Single-mode Base Station, CloudRANCU_P, and Co-MPT Multimode
Base Station".

SingleRAN
Table 3-27 Setting of the OM Bearing Board parameter on DHCP servers of lower-level
base stations
n Optional Involved
OM Bearing 250 1 Value: Mandatory l DHCPO

Board l 0: An FFER
OMCH is l DHCPA
establish CK
ed on the
panel.
l 1: An
OMCH is
establish
ed on the
backplan
e.
Set this
paramete
r to 0
when the
separate-
MPT
multimod
e base
station
uses
panel-
based
interconn
ection.
Set this
paramete
r to 1
when the
separate-
MPT
multimod
e base
station
uses
backplan
e-based
interconn
ection.

SingleRAN

n Optional Involved
CERTDEPL 52 3 Slot No., Optional DHCPOFFE

OY Subrack No., Used only R
and Cabinet when DHCPACK
No. of the certificate
board on sharing is
which the applied.
certificate
for SSL
authenticatio
n is
deployed.
This
parameter is
used for
certificate
sharing.
NOTE
SSL authentication takes effect only on main control boards. If the certificate for SSL authentication is
not deployed on the main control board of a base station, the main control board must obtain a valid
certificate from other boards. In this case, certificate sharing must be used. For details, see PKI Feature
Parameter Description for SingleRAN.
3.4.4 Configuration Requirements for Network Equipment

Each mode in a separate-MPT multimode base station that has a route to the DHCP server has
similar configuration requirements for network equipment to those of a single-mode base
station. For details about these requirements, see 3.3-Automatic OMCH Establishment by
Single-mode Base Station, CloudRANCU_P, and Co-MPT Multimode Base Station. This
section describes only the differences in the configuration requirements.
The upper-level base station acts as the DHCP relay agent to forward DHCP packets and as a
router to forward OMCH and service packets for lower-level base stations. The transport
network for the upper-level base station needs to forward DHCP packets from the DHCP
servers of lower-level base stations. Therefore, the upper-level base station and its transport
network must be configured with data listed in Table 3-28.

SingleRAN
Table 3-28 Configuration requirements for network equipment

Network Requirement
Equipment
Upper-level base l Is enabled with the DHCP relay agent function. Is configured
station with IP addresses of the DHCP servers of lower-level base
stations.
l Is configured with the IP address of the transmission interface
(used for panel-based interconnection) provided by the upper-
level base station.
l Is configured with uplink routes to the DHCP servers of lower-
level base stations and to the peer IP addresses of lower-level
base stations. If the lower-level base station is the GBTS or
NodeB, uplink routes to the base station controller and U2000
must be configured. If the lower-level base station is the
eNodeB, uplink routes to the U2000, mobility management
entity (MME), and serving gateway (S-GW) must be configured.
l Is configured with routes to the source IP addresses of the DHCP
relay agent if source IP route is configured for the upper-level
base station.
NOTE
In scenarios where backplane co-transmission is applied, the IP address
of the DHCP relay agent must be configured if the IP address of the
plane port connecting to the transport network is to be used as the IP
address of the DHCP relay agent.
l Is configured with downlink routes to the OM IP address and
service IP address of the lower-level base station.
l Is configured with VLANs on the transmission interface
connecting to the lower-level base station if VLANs are
deployed between cascaded base stations. In this case, the
network segment configured by NEXTHOPIP (next-hop IP
address) and MASK (subnet mask) must overlap with the
network segment configured by the interconnection interface IP
address. Single VLAN mode is recommended for the upper- and
lower-level base stations.
l If the DHCP packets and OM data of lower-level base stations
are secured by the IPsec tunnel of the upper-level base station,
the upper-level base station needs to configure security
parameters for the passerby flows of lower-level base stations.
The security parameters include the packet filtering rules, ACL
rules, IPsec proposal, and IKE proposal.
All devices on the l Are configured with routes to the DHCP servers of lower-level
transport network base stations.
for the upper-level l Are configured with routes to the IP address of the DHCP relay
base station agent of the upper-level base station.
l Are configured with routes to the OM IP address and service IP
address of the lower-level base station.
U2000/BSC Is configured with routes to the OM IP address of the lower-level

base station.

SingleRAN
Network Requirement
Equipment
DHCP servers of Are configured with routes to the IP address of the DHCP relay
lower-level base agent of the upper-level base station.
stations
Lower-level base Are configured with routes to the U2000 or BSC.

stations Are configured with interface IP addresses that are on the same
network segment with IP addresses of the interfaces for
interconnection with the upper-level base stations.
l Backplane-based interconnection:
The IP addresses of the DHCP relay agent are as follows:
1. OM IP address of the upper-level base station
2. IP addresses of the upper transmission interface on the upper-level base station. If
there are several IP addresses of the upper transmission interface, the IP address used as
the IP address of the DHCP relay agent must be on the same network segment as the
next-hop IP address of the upper-level base station's route to the DHCP server of the
lower-level base station.
l Panel-based interconnection:
The IP addresses of the DHCP relay agent are as follows:
1. OM IP address of the upper-level base station
2. IP addresses of the lower transmission interface on the upper-level base station. If
there are several addresses of the lower transmission interface, the IP addresses used as
the IP addresses of the DHCP relay agent vary by scenario:
– If VLANs have been deployed for neither the OMCH nor the service channel on the
lower-level base station, the IP addresses of the lower transmission interface that is
not configured with VLANs are used.
– If VLANs have been deployed for both the OMCH and the service channel on the
lower-level base station, the IP address of the interface that is used by the OMCH to
deploy VLANs is used.
– If VLANs have been deployed for the service channel but not for the OMCH on the
lower-level base station, the IP addresses of the interface where no VLAN has been
deployed are used.
In both backplane- and panel-based interconnection scenarios, if there are active and standby
OMCHs on the upper-level base station, the OM IP address in use will be used as the IP
address of the DHCP relay agent. For example, if the OM IP address of the standby OMCH is
in use, it will be used as the IP address of the DHCP relay agent.
Backplane-based Interconnection
Figure 3-32 shows examples of DHCP relay agent's IP addresses and route deployment in
backplane-based interconnection.

SingleRAN
Figure 3-32 Examples of DHCP relay agent's IP addresses and route deployment in GBTS &
NodeB backplane-based interconnection
l IP address of the DHCP relay agent and route from the DHCP server to the IP address of
the DHCP relay agent
– IP addresses of the DHCP relay agent are 10.20.20.22 (OM IP address) and
10.100.1.10 (IP address 1).
– The destination IP address of the route from the DHCP server to the IP address of
the DHCP relay agent is 10.100.1.10 or 10.20.20.22.
l IP routes on the upper-level base station
– Run the following command to configure a route to the DHCP server of the lower-
level base station (BSC):
ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.101.1.10",
DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.1.1";
l Run the following command to configure a route to the U2000 IP address:

l Run the following command to configure a route to the RNC service IP address:
l Run the following command to configure a route to the OM IP address of the lower-level
base station (The service IP address is the same as the OM IP address):
ADD IPRT: RTIDX=1, SN=6, SBT=BACK_BOARD, DSTIP="10.30.20.20",
DSTMASK="255.255.255.255", RTTYPE=IF, IFT=TUNNEL, IFNO=1;
l IP route on the lower-level base station

Run the following command to configure a route to the DHCP server:
ADD BTSIPRT: IDTYPE=BYID, BTSID=10, RTIDX=1, DSTIP="10.101.1.10",
DSTMASK="255.255.255.255", RTTYPE=OUTIF, ITFType=TUNNEL, IFNO=1;
l IP route on the BSC

Run the following command to configure a route to the lower-level base station:
ADD IPRT: SRN=2, SN=18, DSTIP="10.30.20.20", DSTMASK="255.255.255.255",
NEXTHOPTYPE=Gateway, NEXTHOP="10.150.1.10", PRIORITY=HIGH;
Panel-based Interconnection
Figure 3-33 shows examples of DHCP relay agent's IP addresses and route deployment in
panel-based interconnection.

SingleRAN
Figure 3-33 Examples of DHCP relay agent's IP addresses and route deployment in panel-
based interconnection
l IP address of the DHCP relay agent and route from the DHCP server to the IP address of
the DHCP relay agent
– If VLANs have been deployed for neither the OMCH nor the service channel on the
lower-level base station, IP addresses of the DHCP relay agent are 10.20.20.22
(OM IP address), 10.100.1.10 (IP address 1), and 10.110.1.10 (IP address 2), and
the destination IP address of the route to the IP address of the DHCP relay agent is
10.20.20.22, 10.100.1.10, or 10.110.1.10.
– If VLANs have been deployed for both the OMCH and the service channel on the
(OM IP address) and 10.100.1.10 (IP address 1), and the destination IP address of
the route to the IP address of the DHCP relay agent is 10.20.20.22 or 10.100.1.10.
To deploy VLANs for the OMCH and service channel on the lower-level base
station, configure VLANMAP information on the upper-level base station as
follows:
//Configuring VLANs for the OMCH on the lower-level base station:
ADD VLANMAP: NEXTHOPIP="10.100.1.30", MASK="255.255.255.0",
VLANMODE=SINGLEVLAN, VLANID=10, SETPRIO=DISABLE;
//Configuring VLANs for the service channel on the lower-level base
station:
– If VLANs have been deployed for the service channel but not for the OMCH on the
(OM IP address) and 10.100.1.10 (IP address 1), and the destination IP address of
the route to the IP address of the DHCP relay agent is 10.20.20.22 or 10.100.1.10.
To deploy VLANs for the service channel on the lower-level base station, configure
VLANMAP information on the upper-level base station as follows:
//Configuring VLANs for the service channel on the lower-level base
station
l IP routes on the upper-level base station

– Run the following command to configure a route to the U2000 IP address:

SingleRAN
– Run the following command to configure a route to the RNC service IP address:
– Run the following command to configure a route to the MME:

– Run the following command to configure a route to the OM IP address of the lower-
level base station:
– Run the following command to configure a route to the service IP address of the
lower-level base station:
l IP route on the lower-level base station

Run the following command to configure a route to the U2000:
l Route from the U2000 to the OM IP address of the lower-level base station:
The destination IP address of the route is 10.20.20.20, the destination subnet mask is
255.255.255.255, and the next-hop IP address is 10.100.11.10.
3.5 Application Restrictions
3.5.1 Configuration Requirements for Base Stations and Other

Network Equipment
When a base station is to be deployed by PnP, configuration requirements for the base station
and related DHCP servers must be met to ensure successful automatic OMCH establishment.
If configuration requirements are not met, automatic OMCH establishment may fail, leading
to a deployment failure. Table 3-29 through Table 3-31 summarize the configuration
requirements.

SingleRAN
Table 3-29 Requirements for configuration files of the base station

SN MO Requirements
1 OMCH This MO is mandatory.

If the base station is configured with active and standby
OMCHs, only the active OMCH is used for base station
deployment by PnP. The active OMCH is the OMCH for which
the Flag parameter is set to MASTER(Master).
The active OMCH must meet the following requirements:
l If the active OMCH is bound to a route:
The PEERIP parameter must be set to the IP address of the
U2000. The IP addresses of the U2000 and the FTP server
must be on the network segment that is collectively
specified by the PEERIP and PEERMASK parameters.
l If the active OMCH is not bound to any route:
The FTP server and the U2000 must be deployed on the
same equipment or network segment. The PeerIP parameter
must be set to the IP address of the U2000. The IP addresses
of the U2000 and the FTP server must be on the network
segment that is collectively specified by the PeerIP and
PEERMASK parameters.
The base station must be configured with a route whose
destination IP address is the network segment of its peer IP
address.
If the requirements are not met, the PEERIP parameter must be
set to the next-hop IP address of the active OMCH, and the
PEERMASK parameter must be set to the interface IP address
mask of the base station.
If BBUs are interconnected, the OMCH must be configured on
the root BBU that provides a port connecting to the transport
network.
2 VLANMAP It is recommended that upper- and lower-level base stations

separately use the single VLAN mode instead of the VLAN
group mode to configure VLANs if base stations are cascaded
and the VLAN is planned in network design. If base stations
are cascaded and the upper-level base station uses the VLAN
group mode, the upper-level base station must attach related
VLAN IDs to services of the OM_HIGH and OM_LOW types
when configuring VLANCLASS. If the lower-level base station
is a GBTS, the upper-level base station must attach related
VLAN IDs to services of the USERDATA type with the
differentiated services code point (DSCP) set to the same value
as the DSCP of the GBTS OMCH.
The VLANMODE parameter specifies the VLAN mode.

SingleRAN
SN MO Requirements
3 BFDSESSION A BFD session is bound to a handover route if the CATLOG

parameter is set to RELIABILITY(Reliability) for the BFD
session in active/standby route scenarios. In scenarios in which
IPsec does not secure OMCH data, if the base station uses a
logical IP address as the OM IP address and the BFD session is
bound to a handover route, the base station cannot be deployed
by PnP.
4 NE If the combination of the DID, BBU subrack topology, and slot

number is used as the base station ID, the DID parameter in the
NE MO must be specified.
5 IPRT/SRCIPRT If the OMCH is configured with active and standby routes, only
the active route can be used for the base station deployment by
PnP. The active route has a higher priority than the standby one.
NOTE
The smaller the number of the route priority, the higher the priority.
Equivalent routes are not recommended for the OMCH. This is
because deployment may fail as the base station randomly
chooses a route from the equivalent routes for the OMCH
during deployment by PnP.
NOTE
Equivalent routes are routes configured with the same destination IP
address and priority and they are used for load sharing.
Table 3-30 Configuration requirements for the configuration files of the base station in IPsec
networking scenarios
SN Net MO Requirement
wor
k
Equi
pme
nt
1 Base OMCH If either the OMCH or the service channel is

statio secured by IPsec, the OMCH and the service
n channel must use different IP addresses. Otherwise,
an error may occur in DHCP parameters.

SingleRAN
SN Net MO Requirement
wor
k
Equi
pme
nt
2 Base ACLRULE If neither requirement is met, errors may occur

statio when parameters configured on the SeGW are
n exported from the CME, leading to failures in base
station deployment by PnP. The configured ACL
rule meets either of the following requirements:
l The SIP and DIP parameters are set to 0.0.0.0,
and the SWC and DWC parameters are set to
255.255.255.255. That is, both the source and
destination IP addresses can be any address.
l The SIP is set to the OM IP address, and the
DIP parameter is set to the IP address of the
U2000, the IP address of the U2000 network
segment, or 0.0.0.0. Note that IPsec tunnels do
not secure OMCHs established during base
station deployment if the ACTION parameter is
set to DENY(Deny). IPsec tunnels secure the
OMCHs only when the ACTION parameter is
not set to DENY(Deny).
3 Base IKEPROPOSAL Parameter settings in the IPSECPROPOSAL MO

statio IPSECPROPOSAL must be consistent with those described in Figure
n 3-24. Parameter settings in the IKEPROPOSAL
MO must be consistent with those described in
Table 3-13, Table 3-14, and Table 3-15.
If the base station uses the IPsec tunnel pair
topology, only the active tunnel supports base
station deployment by PnP.
4 Base BFDSESSION If the base station uses the IPsec tunnel pair
statio topology, the BFD session cannot be bound to a
n route during the BFD session configuration.
5 L2 ETHTRK Ethernet link aggregation group must not be

devic manually configured on the peer L2 devices of the
es base station.
6 CA CA l The CA must be accessible to devices in the

untrusted domain.
l In the case of base station deployment by PnP,
the base station does not support the polling
mode. When the CA is in polling mode, the
certificate application of the base station may
fail due to timeout.

SingleRAN
NOTE
When you configure or modify the information of the U2000 DHCP server on the U2000, the
destination IP address of the OMCH route and the IP address of the destination network segment must
be correct.
Table 3-31 Configuration requirements for a DHCP server

SN Requirement
1 The public DHCP server can be configured with a maximum of eight U2000
DHCP server IP addresses.
If base stations of SRAN7.0, SRAN8.0, and later versions co-exist in a network,
configuring eight U2000 DHCP server IP addresses on the public DHCP server
causes a deployment failure because SRAN7.0 base stations support only two
U2000 DHCP server IP addresses. In this scenario, configure two U2000 DHCP
server IP addresses or deploy SRAN7.0 base stations in non-PnP mode.
2 If the WMPT board of the NodeB needs to be replaced with the UMPT board, the
BS ID configured on the DHCP server must be changed from being bound to the
panel's ESN (mapping subcode 43 in DHCP Option 43) to being bound to the
backplane's ESN (mapping subcode 1 in DHCP Option 43).
3.5.2 Impact of U2000 Deployment on Base Station Deployment

by PnP
During base station deployment by PnP and subsequent commissioning, the base station
needs to communicate with many application services of the U2000, including the DHCP
service, FTP service, and OMCH management service.
The preceding three services can be deployed on different U2000s and use different IP
addresses. Therefore, network planning and base station data configuration must ensure
normal communication between the OM IP address of the base station and the IP addresses of
the three services.
Table 3-32 describes the impact of U2000 deployment on automatic OMCH establishment.

SingleRAN
Table 3-32 Impact of U2000 deployment on automatic OMCH establishment

U200 U2000 U200 U2000 Requirement for Impact on the
0 Deployme 0 Servin the Base Station Network
Depl nt Servi g as Deployment Configuration
oym Descriptio ng as the
ent n the OMC
DHC
P
Serv
er
Singl l All Singl Single For details, see 3.3 For details, see 3.3
e- applicati e server Automatic OMCH Automatic OMCH
server on serve Establishment by Establishment by
syste services r Single-mode Base Single-mode Base
m are Station and Co- Station and Co-MPT
deployed MPT Multimode Multimode Base
on the Base Station and 3.4 Station and 3.4
same Automatic OMCH Automatic OMCH
server. Establishment by Establishment by the
l The the Separate-MPT Separate-MPT
server Multimode Base Multimode Base
(U2000) Station. Station.
has only
one IP
address.
HA l The Activ Active For details, see 3.3 For details, see 3.3
syste active e or or Automatic OMCH Automatic OMCH
m and stand standby Establishment by Establishment by
standby by node Single-mode Base Single-mode Base
nodes node Station and Co- Station and Co-MPT
have the MPT Multimode Multimode Base
same Base Station and 3.4 Station and 3.4
function Automatic OMCH Automatic OMCH
and data Establishment by Establishment by the
on the the Separate-MPT Separate-MPT
two Multimode Base Multimode Base
nodes Station. Station.
are
synchron
ized.
l The
active
and
standby
nodes
use the
same IP
address.

SingleRAN

ent n the OMC
DHC
P
Serv
er
SLS l The Mast Master l The PeerIP In IPsec networking

syste slave er or parameter for the scenarios, the IP
m/ node node slave OMCH must be address of the U2000
ATAE performs node set to the IP DHCP server
cluste the address of the configured on the
r/ network U2000 that public DHCP server
virtua manage manages the base must be the IP address
lizati ment station. of the master node.
on function l If the OMCH is The SeGW must be
cluste only. bound to a route, configured with ACL
r l The IP the route must be rules which allow
address bound to the packets of the U2000
of the network segment DHCP server to pass.
master of the U2000. The SeGW must be
node is configured with ACL
different rules which allow OM
from that data to pass.
of the
slave The DHCP server IP
node, address configured on
and the the DHCP relay must
IP be the master node IP
addresse address of the U2000.
s of the
two
nodes
are in
the same
subnet.

SingleRAN

ent n the OMC
DHC
P
Serv
er
Remo l The Both The l The base station l In IPsec networking

te HA active the U2000 must be scenarios, the IP
syste and active must configured with address of the
m/ standby and serve routes to the two U2000 DHCP server
ATAE nodes stand as the IP address or two configured on the
ONLI are by DHCP network public DHCP server
NE deployed nodes server. segments. must be the IP
on two l The PeerIP address of the
locations parameter for the U2000 that serves as
. OMCH of the the DHCP server. If
l The IP base station must the operator expects
address be set to the IP to use either of the
of the address of the active and standby
active U2000 that serves nodes as the DHCP
node is as the DHCP server, the public
different server. DHCP server must
from that be configured with
of the the IP addresses of
standby the active and
node, standby nodes.
and the l The SeGW must be
IP configured with
addresse ACL rules which
s of the allow DHCP packets
two to pass. If the
nodes operator expects to
may not use either of the
be in the active and standby
same nodes as the DHCP
subnet. server, the SeGW
must be configured
with ACL rules
which allow packets
of active and
standby nodes to
pass.
l The SeGW must be
configured with
ACL rules which
allow OM data to
pass. If the operator

SingleRAN

ent n the OMC
DHC
P
Serv
er
expects to use either

of the active and
standby nodes as the
OMC, the SeGW
must be configured
with ACL rules
which allow packets
of active and
standby nodes to
pass.
l The DHCP relay
must be configured
with the active and
standby node IP
addresses which
serve as the DHCP
server IP address.
Emer The Not Not Not supported Not involved

gency emergency suppo support
syste system rted ed
m performs
basic
functions
only and
does not
support PnP
or DHCP.
Below is an example. When the U2000 uses the multi-server load-sharing (SLS) networking,
the DHCP service is deployed on the master server, whereas the FTP service and the OMCH
management service can be deployed on either the master or slave server. When the FTP
service and OMCH management service are deployed on different U2000 servers and
accordingly use different IP addresses, the route configuration on the base station and the
transport network must ensure that the IP addresses of the two services are reachable using
configured routes. If IPsec secures OMCH data, the IPsec SA's traffic selector (TS)
successfully negotiated between the base station and the SeGW must cover the traffic between
the OM IP address of the base station and the IP addresses of the FTP service and the OMCH
management service.

SingleRAN
OMCH networking requires that the NAT server be deployed only on the U2000 side, but not
the base station or BSC side. Figure 3-34 shows the OMCH networking in which the NAT
server is deployed on the U2000 side.
Figure 3-34 OMCH networking when the NAT server is deployed on the U2000
The IP address and port number of the U2000 can be converted by the NAT. Therefore, the
route whose destination IP address is the U2000 IP address on the base station side must use
an U2000 IP address visible on the base station side as the destination address. As shown in
Figure 3-34, the local IP address configured for the U2000 is 10.20.0.1, that is, the source IP
address of packets sent by the U2000 is 10.20.0.1. After the conversion performed by the
NAT server, however, the source IP address in TCP packets received by the base station is
10.10.1.1 instead of 10.20.0.1. Therefore, the route whose destination IP address is 10.10.1.1
instead of 10.20.0.1 must be configured on the base station side.
NOTE
The IP address and port number on the base station side cannot be converted by the NAT server because
the DHCP server uses the IP address of the DHCP relay agent (giaddr) or IP address of the DHCP client
(ciaddr) as the destination IP address for responding to the DHCP message and the giaddr or ciaddr
fields contained in the DHCP message cannot be converted by the NAT server.

SingleRAN
Automatic OMCH Establishment Feature Parameter 4 ATM-based Automatic OMCH Establishment for Base
4 ATM-based Automatic OMCH

Establishment for Base Stations
4.1 Overview
ATM-based automatic OMCH establishment for Base Stations (corresponding to feature
WRFD-031100 BOOTP) is used for the bootstrap of diskless workstations. It enables the
diskless workstation to obtain the IP address from the server during the startup. Compared
with the Reverse Address Resolution Protocol (RARP) that implements the same function,
BOOTP is more versatile and easier to use. BOOTP complies with the RFC 951 and RFC
1542 protocols.
BOOTP that is applied to the RAN system enables the NodeB to establish an IPoA path based
on the obtained IP address, PVC, and transmission port carrying the PVC. In this way, a
remote OM channel can be set up between the NodeB and the U2000 or LMT.
The NodeB configuration data normally contains the data of the IPoA path. If the data is
correct, the user can remotely access and maintain the NodeB. If the data is incorrect, BOOTP
helps the NodeB to establish a correct IPoA path so that the NodeB can be remotely
maintained.
4.2 Principles
BOOTP is used in ATM networking to establish an IPoA path so that a remote OM channel
from the U2000 or LMT to the NodeB can be set up.
The configuration data required for setting up an IPoA path includes the Permanent Virtual
Channel (PVC), transport ports carrying the PVC, and IP addresses.
The procedure of BOOTP establishment consists of port listening, port configuration, PVC
setup and BOOTP request initiation, RNC returning the BOOTPREPLY message, and IPoA
configuration, as shown in Figure 4-1.

SingleRAN
Figure 4-1 Procedure of BOOTP establishment
4.2.1 Port Listening

Port listening enables the NodeB to listen to the configuration data of peer ports so that the
NodeB transport ports that carry PVCs can be correctly configured.
The prerequisites for port listening are as follows: The physical links must be connected
properly. (If a link works abnormally, ports are not configured on this link.); the transport
ports of other transport devices connecting the RNC and the NodeB must be correctly
configured.
The port types applied to ATM networking are as follows:
l Inverse Multiplexing over ATM (IMA)

l User Network Interface (UNI)
l Fractional ATM
l Unchannelized STM-1/OC-3
The procedure of BOOTP establishment is different in the case of different port types. For the
unchannelized STM-1/OC-3 ports, the PVC can be set up without port listening as
interconnection is not involved. The following describes the port listening function in the case
of IMA, UNI, and fractional ATM.

SingleRAN
Port Listening in the Case of IMA/UNI

Through IMA/UNI ports, the NodeB can obtain the configuration data from peer ports by
listening to the IMA Control Protocol (ICP) cells of the peer end. According to the obtained
configuration data, the NodeB sets up an IMA group that carries the PVC (including the IMA
links in the IMA group) or UNI links.
The NodeB first tries to listen to the IMA/UNI ports because whether the IMA/UNI ports or
fractional ATM ports are used cannot be determined initially. If the listening fails, the NodeB
listens to the fractional ATM ports.
Port Listening in the Case of Fractional ATM

The fractional ATM link requires a bitmap of all types of timeslots contained in the link. If the
timeslots are inconsistent at the two ends, the setup of a fractional ATM link will fail.
Listening to the timeslots by using the exhaustive method will be time-consuming because the
combinations of timeslots are countless. To prevent this problem, the range of timeslot
combinations needs to be minimized. The combinations need to contain only the typical
timeslot bitmaps commonly used by the telecom operators.
To listen to fractional ATM links is to apply the exhaustive method to these typical timeslot
bitmaps, which is a way to configure the fractional ATM links. If the links work properly, the
listening is successful; if the links work abnormally, it indicates that the timeslot bitmap does
not match the configuration at the peer end, and the NodeB needs to try other timeslot
bitmaps.
The NodeB first uses the E1 timeslot bitmaps to listen to the ports, because whether the
physical links connected to the NodeB are E1s or T1s cannot be determined initially. If the
listening fails, the NodeB uses the T1 timeslot bitmaps to listen to the ports.
After the listening is successful, the PVC can be set up.
4.2.2 Port Configuration

The NodeB configures its IMA or UNI ports based on the configuration data of the ports at
the peer end. The configuration parameters of the peer ports, obtained through port listening,
include protocol version number and IMA frame length.
4.2.3 PVC Setup and BOOTP Request Initiation

The PVC used by BOOTP is permanently 1/33, that is, its Virtual Path Identifier (VPI) is set
to 1 and Virtual Channel Identifier (VCI) is set to 33. Such a PVC needs to be configured at
the RNC or at the ATM network equipment. The BOOTP process is implemented on this
PVC.
After the PVC is set up, the NodeB issues a BOOTPREQUEST message on this PVC to
request the RNC to assign an IP address. The IP address will be used as the OM address of the
NodeB. This IP address can be used for logging in to the NodeB and be used for maintenance
purposes.
4.2.4 RNC Returning the BOOTREPLY Message

The prerequisite for the RNC to respond to the BOOTPREQUEST message is that the RNC
has configured a PVC (fixed to 1/33) for the related NodeB and has obtained the
corresponding IP addresses.

SingleRAN
On receipt of the BOOTPREQUEST message, the RNC replies with a BOOTPREPLY

message containing the assigned IP address. The message is transmitted over the established
PVC (fixed to 1/33).
4.2.5 IPoA Configuration

After receiving the BOOTPREPLY message from the RNC, the NodeB configures an IPoA
path, which finalizes the BOOTP implementation process.
4.3 Configuration Guidelines

In the IP network:
l For details about data to be prepared before a base station starts the automatic OMCH
establishment, see 3900 & 5900 Series Base Station Initial Configuration Guide.
l For details about software and configuration file downloading, activation, and
commissioning on a base station after the automatic OMCH establishment is complete,
see 3900 & 5900 Series Base Station Commissioning Guide.
The following describes how to configure BOOTP on an ATM network.
Configuring BOOTP on the RNC Side on an ATM Network

On the RNC side, run the ADD IPOAPVC command to configure the PVC. When using
BOOTP, the PVC is to be configured with VPI = 1 and VCI = 33. The main parameters of this
command are as follows:
l CARRYVPI (BSC6900, BSC6910): This parameter specifies the VPI value of the PVC.
It is set to 1.
l CARRYVCI (BSC6900, BSC6910): This parameter specifies the VCI value of the PVC.
It is set to 33.
l IPADDR (BSC6900, BSC6910): This parameter specifies the local IP address.
l PEERIPADDR (BSC6900, BSC6910): This parameter specifies the IP address of the
peer end, that is, IP address of the NodeB.
On the RNC side, run the ADD UNODEBIP command to configure the IP address of the OM
channel. The main parameter of this command is as follows:
NBATMOAMIP (BSC6900, BSC6910): This parameter specifies the OM IP address of the

NodeB in ATM networking.
NBCTRLSN (BSC6900, BSC6910): This parameter specifies the main control board slot
number of the NodeB. When there are multiple main control boards in a base station, the
RNC compares the slot number of a main control board reported in the BOOTP process with
the slot number specified by users. If the reported and specified slot numbers are the same, the
RNC returns a BOOTPREPLY message to the base station.
Configuring BOOTP on the NodeB Side in an ATM Network

The BOOTP process can be implemented without any NodeB configuration data, and
therefore it is unnecessary to configure BOOTP on the NodeB side.

SingleRAN
Automatic OMCH Establishment Feature Parameter 5 TDM-based Base Station Automatic OMCH
Description Establishment
5 TDM-based Base Station Automatic

OMCH Establishment
5.1 Introduction
In TDM networking, the protocol stack on the Abis interface is as follows:
l Physical layer: Data is carried over E1/T1 links.

l Data link layer: High-Level Data Link Control (HDLC) is used.
l Application layer: Link access procedure on the D channel (LAPD) is used. LAPD
includes layer 2 management link (L2ML), OML, radio signaling link (RSL), and
extended signaling link (ESL).
Figure 5-1 shows the protocol stack on the Abis interface in TDM networking.
Figure 5-1 Protocol stack on the Abis interface in TDM networking
OML timeslot detection in TDM networking applies to the GBTS in Abis over TDM mode.
This function is used to establish an OMCH (that is, an OML) between the GBTS and BSC.
5.2 Process
As shown in Figure 5-2, the process of OML timeslot detection in TDM networking consists
of two procedures: sending L2ML establishment requests and saving detection information.

SingleRAN
Figure 5-2 Process of OML timeslot detection in TDM networking
5.2.1 Sending L2ML Establishment Requests

The procedure for sending L2ML establishment requests is as follows:
1. The GBTS determines whether an E1 or T1 link is used for OML timeslot detection
based on the DIP switch of the main control board.
2. To establish an OML to the BSC, the GBTS attempts to send L2ML establishment
requests based on certain combinations of bandwidths and E1/T1 ports that support
OML timeslot detection.
OML timeslot detection in TDM networking requires 64 kbit/s or 16 kbit/s bandwidth and can
be implemented on E1/T1 ports 0 and 1 of the main control board. Therefore, there are four
possible combinations, which the GBTS tries in the following order:
1. E1/T1 port 0, 64 kbit/s bandwidth

If the 64 kbit/s bandwidth is used:
l For an E1 link, the GBTS sends L2ML establishment requests over 64 kbit/s timeslots 1
through 31.
l For a T1 link, the GBTS sends L2ML establishment requests over 64 kbit/s timeslots 1
through 24.
If the 16 kbit/s bandwidth is used:

SingleRAN
l For an E1 link, the GBTS sends L2ML establishment requests over the third 16 kbit/s
sub-timeslots of 64 kbit/s timeslots 1 through 31.
l For a T1 link, the GBTS sends L2ML establishment requests over the third 16 kbit/s sub-
timeslots of 64 kbit/s timeslots 1 through 24.
Upon receiving an L2ML establishment request, the BSC selects a 64 kbit/s timeslot or a 16
kbit/s sub-timeslot based on base station configurations, and responds to the request. By
default, the BSC selects the last 64 kbit/s timeslot of an E1/T1 link, or the third 16 kbit/s sub-
timeslot of the last 64 kbit/s timeslot. The last 64 kbit/s timeslot is timeslot 31 for an E1 link
and timeslot 24 for a T1 link.
If the last 64 kbit/s timeslot or the third 16 kbit/s sub-timeslot of the last 64 kbit/s timeslot
cannot carry an OML, run the SET BTSOMLTS command on the BSC LMT to set the
timeslot that is used to carry the OML, and run the SET BTSOMLDETECT command to set
the OML timeslot detection function.
Upon receiving a correct response over a timeslot, the GBTS uses the timeslot to carry the
OML. Otherwise, the GBTS attempts to establish an OML on other ports or timeslots.
5.2.2 Saving Detection Information

The GBTS saves the combination of the bandwidth and E1/T1 port number that was used for
the previous successful L2ML establishment. Upon the next startup, the GBTS preferentially
uses the saved combination for OML establishment, which reduces the startup time.

SingleRAN
Description 6 Related Features
6 Related Features
Prerequisite Features
None
Mutually Exclusive Features

None
Impacted Features
None

SingleRAN
Description 7 Network Impact
7 Network Impact
System Capacity
No impact.
Network Performance
No impact.

SingleRAN
Description 8 Parameters
8 Parameters
Table 8-1 Parameters

Parame NE MML Feature Feature Description
ter ID Comma ID Name
nd
DHCPR BSC690 ADD None None Meaning: DHCP Relay ID.

LYID 0 DHCPR GUI Value Range: 0~2047
LY
Unit: None
MOD
DHCPR Actual Value Range: 0~2047
LY Default Value: None
RMV
DHCPR
LY
DHCPR BSC691 ADD None None Meaning: DHCP Relay ID.

LYID 0 DHCPR GUI Value Range: 0~2047
LY
Unit: None
MOD
DHCPR Actual Value Range: 0~2047
LY Default Value: None
RMV
DHCPR
LY
DHCPR BSC690 ADD None None Meaning: This parameter indicates the IP Address of
LYGAT 0 DHCPR DHCP Relay Gateway.
EWAYI LY GUI Value Range: Valid IP Address
P MOD Unit: None
DHCPR
LY Actual Value Range: Valid IP Address
Default Value: None

SingleRAN

nd
DHCPR BSC691 ADD None None Meaning: This parameter indicates the IP Address of
LYGAT 0 DHCPR DHCP Relay Gateway.
EWAYI LY GUI Value Range: Valid IP Address
P MOD Unit: None
DHCPR
LY Actual Value Range: Valid IP Address
Default Value: None
DHCPPI BSC690 ADD WRFD- IP Meaning: NE type identifier in the DHCP message.
D 0 DHCPR 050410 Transmi The parameter specifies the type of NEs for which the
LY ssion multimode base station controller can perform DHCP
MOD Introduc relay. TGWSWITCH is the relay switch of TGW, and
DHCPR tion on OTHERSWITCH is the relay switch of NEs
LY Iur supporting the relay function except TGW, such as
Interface SRAN, NodeB, USU, eNodeB, and eGBTS.
GUI Value Range: TGWSWITCH(TGWSWITCH),
OTHERSWITCH(OTHERSWITCH)
Unit: None
Actual Value Range: TGWSWITCH,
OTHERSWITCH
Default Value: TGWSWITCH:1, OTHERSWITCH:1
ES BTS390 SET MRFD- IP- Meaning: Indicates whether to enable the DHCP relay
0, DHCPR 121124 Based switch.
BTS390 ELAYS WRFD- Multi- GUI Value Range: DISABLE(Disable),
0 WITCH 031101 mode ENABLE(Enable)
WCDM LST Co-
A, Transmi Unit: None
DHCPR
BTS390 ELAYS ssion on Actual Value Range: DISABLE, ENABLE
0 LTE, WITCH BS Default Value: DISABLE(Disable)
BTS590 side(No
0, deB)
BTS590 NodeB
0 Self-
WCDM discover
A, y Based
BTS590 on IP
0 LTE Mode

SingleRAN

nd
DHCPS BTS390 ADD WRFD- NodeB Meaning: Indicates the IP address of the DHCP server.
VRIP 0, DHCPS 031101 Self- GUI Value Range: Valid IP address
BTS390 VRIP discover
0 y Based Unit: None
MOD
WCDM DHCPS on IP Actual Value Range: Valid IP address
A, VRIP Mode Default Value: None
BTS390
0 LTE, RMV
BTS590 DHCPS
0, VRIP
BTS590 LST
0 DHCPS
WCDM VRIP
A,
BTS590
0 LTE
IDTYPE BTS390 ADD LOFD-0 IPsec Meaning: Indicates the type of the identification
0, IKEPEE 03009 / payload that the local end transmits. The
BTS390 R TDLOF authentication can be performed based on IP or fully
0 MOD D-00300 qualified domain name (FQDN).
WCDM IKEPEE 9/ GUI Value Range: IP(IP Identify), FQDN(Name
A, R MLOFD Identify)
BTS390 -003009
0 LTE, DSP Unit: None
BTS590 IKEPEE Actual Value Range: IP, FQDN
0, R
Default Value: None
BTS590 LST
0 IKEPEE
WCDM R
A,
BTS590
0 LTE

SingleRAN

nd
FLAG BTS390 ADD WRFD- ATM/IP Meaning: Indicates the master/slave flag of the remote
0, OMCH 050404 Dual maintenance channel.
BTS390 DSP Stack GUI Value Range: MASTER(Master), SLAVE(Slave)
0 OMCH Node B
WCDM Unit: None
A, MOD Actual Value Range: MASTER, SLAVE
BTS390 OMCH
Default Value: None
0 LTE, RMV
BTS590 OMCH
0, LST
BTS590 OMCH
0
WCDM
A,
BTS590
0 LTE
PEERIP BTS390 ADD WRFD- ATM/IP Meaning: Indicates the peer IP address of the remote
0, OMCH 050404 Dual maintenance channel. Indicates the IP address of the
BTS390 MOD Stack U2000 in an IP network and the device IP address of
0 OMCH Node B the RNC in an ATM network.
WCDM GUI Value Range: Valid IP address
A, DSP
BTS390 OMCH Unit: None
0 LTE, LST Actual Value Range: Valid IP address
BTS590 OMCH Default Value: None
0,
BTS590
0
WCDM
A,
BTS590
0 LTE

SingleRAN

nd
PEERM BTS390 ADD WRFD- ATM/IP Meaning: Indicates the subnet mask of the peer IP
ASK 0, OMCH 050404 Dual address for the remote maintenance channel.
BTS390 MOD Stack GUI Value Range: Valid subnet mask
0 OMCH Node B
WCDM Unit: None
A, DSP Actual Value Range: Valid subnet mask
BTS390 OMCH
Default Value: None
0 LTE, LST
BTS590 OMCH
0,
BTS590
0
WCDM
A,
BTS590
0 LTE
VLAN BTS390 ADD WRFD- IP Meaning:

MODE 0, VLAN 050402 Transmi Indicates the VLAN mode. When this parameter is set
BTS390 MAP ssion to SINGLEVLAN, the configured VLAN ID and
0 MOD Introduc VLAN priority can be directly used to label the
WCDM VLAN tion on VLAN tag.
A, MAP Iub
BTS390 Interface If this parameter is set to VLANGROUP, the next hop
0 LTE, LST IP addresses are mapped to the VLAN groups, and
BTS590 VLAN then mapped to the VLAN tags in the VLAN groups
0, MAP according to the DSCPs of the IP packets. In VLAN
BTS590 group mode, ensure that the VLAN groups have been
0 configured by running the ADD VLANCLASS
WCDM command. Otherwise, the configuration does not take
A, effect.
BTS590 GUI Value Range: SINGLEVLAN(Single VLAN),
0 LTE VLANGROUP(VLAN Group)
Unit: None
Actual Value Range: SINGLEVLAN, VLANGROUP
Default Value: None

SingleRAN

nd
CATLO BTS390 ADD WRFD- Hybrid Meaning: Indicates the type of a BFD session. If this
G 0, BFDSE 050403 Iub IP parameter is set to MAINTENANCE, this BFD
BTS390 SSION Transmi session is used only for continuity check (CC). If this
0 MOD ssion parameter is set to RELIABILITY, the BFD session is
WCDM BFDSE used to trigger route interlock. Route interlock enables
A, SSION the standby route to take over once the active route
BTS390 becomes faulty, and therefore prevents service
0 LTE, DSP interruption caused by route failures.
BTS590 BFDSE
SSION GUI Value Range: MAINTENANCE(Maintenance),
0, RELIABILITY(Reliability)
BTS590 LST
0 BFDSE Unit: None
WCDM SSION Actual Value Range: MAINTENANCE,
A, RELIABILITY
BTS590 Default Value: RELIABILITY(Reliability)
0 LTE
DID BTS390 SET NE None None Meaning: Indicates the deployment identifier that
0, LST NE specifies the site of the NE. When multiple NEs are
BTS390 deployed at the same site, these NEs have the same
0 deployment identifier.
WCDM GUI Value Range: 0~64 characters
A,
BTS390 Unit: None
0 LTE, Actual Value Range: 0~64 characters
BTS590 Default Value: NULL(empty string)
0,
BTS590
0
WCDM
A,
BTS590
0 LTE

SingleRAN

nd
SIP BTS390 ADD WRFD- IP Meaning: Indicates the source IP address of data to
0, ACLRU 050402 Transmi which an ACL rule is applied. To add an ACL rule
BTS390 LE WRFD- ssion that is applicable to data of all source IP addresses, set
0 MOD 140209 Introduc this parameter to 0.0.0.0.
WCDM ACLRU tion on GUI Value Range: Valid IP address
A, LE Iub
BTS390 Interface Unit: None
0 LTE, DSP Actual Value Range: Valid IP address
ACLRU NodeB
BTS590 integrate Default Value: None
0, LE
d IPSec
BTS590 LST
0 ACLRU
WCDM LE
A,
BTS590
0 LTE
DIP BTS390 ADD WRFD- IP Meaning: Indicates the destination IP address of data
0, ACLRU 050402 Transmi to which an ACL rule is applied. To add an ACL rule
BTS390 LE WRFD- ssion that is applicable to data of all destination IP
0 MOD 140209 Introduc addresses, set this parameter to 0.0.0.0.
WCDM ACLRU tion on GUI Value Range: Valid IP address
A, LE Iub
BTS390 Interface Unit: None
0 LTE, DSP Actual Value Range: Valid IP address
ACLRU NodeB
BTS590 integrate Default Value: None
0, LE
d IPSec
BTS590 LST
0 ACLRU
WCDM LE
A,
BTS590
0 LTE

SingleRAN

nd
SWC BTS390 ADD WRFD- IP Meaning: Indicates the wildcard of a source IP

0, ACLRU 050402 Transmi address. The wildcard is used to determine which bits
BTS390 LE WRFD- ssion can be neglected when IP address matching is being
0 MOD 140209 Introduc performed. It can be considered as the inverse of the
WCDM ACLRU tion on corresponding subnet mask.
A, LE Iub GUI Value Range: Valid wildcard of the IP address
BTS390 Interface
ACLRU NodeB
BTS590 integrate Actual Value Range: Valid wildcard of the IP address
0, LE
d IPSec Default Value: None
BTS590 LST
0 ACLRU
WCDM LE
A,
BTS590
0 LTE
DWC BTS390 ADD WRFD- IP Meaning: Indicates the wildcard of a destination IP

0, ACLRU 050402 Transmi address. The wildcard is used to determine which bits
BTS390 LE WRFD- ssion can be neglected when IP address matching is being
0 MOD 140209 Introduc performed. It can be considered as the inverse of the
WCDM ACLRU tion on corresponding subnet mask.
A, LE Iub GUI Value Range: Valid wildcard of the IP address
BTS390 Interface
ACLRU NodeB
BTS590 integrate Actual Value Range: Valid wildcard of the IP address
0, LE
d IPSec Default Value: None
BTS590 LST
0 ACLRU
WCDM LE
A,
BTS590
0 LTE

SingleRAN

nd
ACTIO BTS390 ADD WRFD- IP Meaning: Indicates the action taken on the data that
N 0, ACLRU 050402 Transmi matches an ACL rule. When the ACL rule is
BTS390 LE WRFD- ssion referenced by packet filtering, the BS allows the data
0 DSP 140209 Introduc that matches the rule to transmit if this parameter is
WCDM ACLRU tion on set to PERMIT, and rejects the data if this parameter is
A, LE Iub set to DENY. When the ACL rule is referenced by an
BTS390 Interface IPSec policy, the BS encrypts or decrypts the data that
0 LTE, LST matches the rule if this parameter is set to PERMIT,
ACLRU NodeB
BTS590 integrate and does not encrypts or decrypts the data if this
0, LE parameter is set to DENY.
d IPSec
BTS590 GUI Value Range: DENY(Deny), PERMIT(Permit)
0
WCDM Unit: None
A, Actual Value Range: DENY, PERMIT
BTS590 Default Value: PERMIT(Permit)
0 LTE
CARRY BSC690 ADD WRFD- ATM Meaning: VPI value of the VCL of the bearer network
VPI 0 IPOAP 050105 Switchin GUI Value Range: 0~4095
VC WRFD- g Based
Hub Unit: None
MOD 031100
IPOAP Node B Actual Value Range: 0~4095
WRFD-
VC 0503010 BOOTP Default Value: None
5 Permane
WRFD- nt
050301 AAL5
Connect
ions for
Control
Plane
Traffic
ATM
Transmi
ssion
Introduc
tion
Package

SingleRAN

nd
CARRY BSC691 ADD WRFD- ATM Meaning: VPI value of the VCL of the bearer network
VPI 0 IPOAP 050105 Switchin GUI Value Range: 0~4095
VC WRFD- g Based
Hub Unit: None
MOD 031100
WRFD-
5 Permane
WRFD- nt
050301 AAL5
Connect
ions for
Control
Plane
Traffic
ATM
Transmi
ssion
Introduc
tion
Package
CARRY BSC690 ADD WRFD- ATM Meaning: VCI value of the VCL of the bearer network
VCI 0 IPOAP 050105 Switchin GUI Value Range: 32~65535
VC WRFD- g Based
Hub Unit: None
MOD 031100
WRFD-
5 Permane
WRFD- nt
050301 AAL5
Connect
ions for
Control
Plane
Traffic
ATM
Transmi
ssion
Introduc
tion
Package

SingleRAN

nd
CARRY BSC691 ADD WRFD- ATM Meaning: VCI value of the VCL of the bearer network
VCI 0 IPOAP 050105 Switchin GUI Value Range: 32~65535
VC WRFD- g Based
Hub Unit: None
MOD 031100
WRFD-
5 Permane
WRFD- nt
050301 AAL5
Connect
ions for
Control
Plane
Traffic
ATM
Transmi
ssion
Introduc
tion
Package
IPADD BSC690 ADD WRFD- ATM Meaning: Local IP address.

R 0 IPOAP 050105 Switchin GUI Value Range: Valid IP Address
VC WRFD- g Based
Hub Unit: None
MOD 031100
IPOAP Node B Actual Value Range: Valid IP Address
WRFD-
RMV 5 Permane
IPOAP WRFD- nt
VC 050301 AAL5
Connect
ions for
Control
Plane
Traffic
ATM
Transmi
ssion
Introduc
tion
Package

SingleRAN

nd
IPADD BSC691 ADD WRFD- ATM Meaning: Local IP address

R 0 IPOAP 050105 Switchin GUI Value Range: Valid IP Address
VC WRFD- g Based
Hub Unit: None
MOD 031100
WRFD-
RMV 5 Permane
IPOAP WRFD- nt
VC 050301 AAL5
Connect
ions for
Control
Plane
Traffic
ATM
Transmi
ssion
Introduc
tion
Package
PEERIP BSC690 ADD WRFD- ATM Meaning: Peer IP address.

ADDR 0 IPOAP 050105 Switchin GUI Value Range: Valid IP Address
VC WRFD- g Based
Hub Unit: None
MOD 031100
WRFD-
RMV 5 Permane
IPOAP WRFD- nt
VC 050301 AAL5
Connect
ions for
Control
Plane
Traffic
ATM
Transmi
ssion
Introduc
tion
Package

SingleRAN

nd
PEERIP BSC691 ADD WRFD- ATM Meaning: Peer IP address.

ADDR 0 IPOAP 050105 Switchin GUI Value Range: Valid IP Address
VC WRFD- g Based
Hub Unit: None
MOD 031100
WRFD-
RMV 5 Permane
IPOAP WRFD- nt
VC 050301 AAL5
Connect
ions for
Control
Plane
Traffic
ATM
Transmi
ssion
Introduc
tion
Package
NBATM BSC690 ADD WRFD- BOOTP Meaning: When the operation and maintenance
OAMIP 0 UNODE 031100 NodeB channel of NodeB is operating in the ATM, this
BIP WRFD- Self- parameter indicates the address of the operation and
MOD 031101 discover maintenance console. The IP address and IPOA client
UNODE y Based IP address must be in the same network segment.
BIP on IP GUI Value Range: Valid IP Address
Mode Unit: None
Actual Value Range: Valid IP Address
Default Value: None
NBATM BSC691 ADD WRFD- BOOTP Meaning: When the operation and maintenance
OAMIP 0 UNODE 031100 NodeB channel of NodeB is operating in the ATM, this
BIP WRFD- Self- parameter indicates the address of the operation and
MOD 031101 discover maintenance console. The IP address and IPOA client
UNODE y Based IP address must be in the same network segment.
BIP on IP GUI Value Range: Valid IP Address
Mode Unit: None
Actual Value Range: Valid IP Address
Default Value: None

SingleRAN

nd
NBCTR BSC690 ADD None None Meaning: Number of the slot for the NodeB main
LSN 0 UNODE control board.
BIP GUI Value Range: 0~7;255
MOD Unit: None
UNODE
BIP Actual Value Range: 0~7, 255
Default Value: 255
NBCTR BSC691 ADD None None Meaning: Number of the slot for the NodeB main
LSN 0 UNODE control board
BIP GUI Value Range: 0~7;255
MOD Unit: None
UNODE
BIP Actual Value Range: 0~7, 255
Default Value: 255

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

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

SingleRAN
Description 11 Reference Documents
11 Reference Documents
1. IPSec Feature Parameter Description for SingleRAN

2. PKI Feature Parameter Description for SingleRAN
3. SSL Feature Parameter Description for SingleRAN
4. 3900 Series Base Station Commissioning Guide
5. 3900 Series Base Station Initial Configuration Guide


Automatic OMCH Establishment (SRAN12.1 - 01)

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Automatic OMCH Establishment (SRAN12.1 - 01)

Hochgeladen von

Copyright:

Verfügbare Formate

SingleRAN

Automatic OMCH Establishment

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2017-03-08) Huawei Proprietary and Confidential i

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

3 IP-based Automatic OMCH Establishment for Base Stations..............................................8

Issue 01 (2017-03-08) Huawei Proprietary and Confidential ii

3.2.8.3 Scheme 2.................................................................................................................................................................30

Issue 01 (2017-03-08) Huawei Proprietary and Confidential iii

3.5.2 Impact of U2000 Deployment on Base Station Deployment by PnP........................................................................93

4 ATM-based Automatic OMCH Establishment for Base Stations......................................99

5 TDM-based Base Station Automatic OMCH Establishment............................................103

Issue 01 (2017-03-08) Huawei Proprietary and Confidential iv

1 About This Document

1.2 Intended Audience

1.3 Change History

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 1

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

Change Change Description Parameter Change

Feature Added support for NB-IoT. For details, see None

Editorial None None

1.4 Differences Between Base Station Types

WRFD-031100 BOOTP Yes No Yes

WRFD-031101 NodeB Self-discovery Based on IP Yes Yes Yes

LBFD-0020035 Self-configuration (for LTE FDD) Yes Yes Yes

TDLBFD-002036 Self-configuration (for LTE TDD) Yes No No

MLBFD-12000241 Self-configuration (for NB-IoT) Yes No No

Function Implementation in Macro, Micro, and LampSite Base Stations

Automatic data Micro base stations do not support automatic data

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 2

1.5 Functional Differences Between NB-IoT and FDD

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 3

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 4

l Basic information, including the following:

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 5

2.3 Application Networking Scenarios

Table 2-1 Application networking scenarios

Networking Scenario Description

Non-IPsec in IP IPsec does not secure Dynamic Host Configuration Protocol

IPsec in IP networking IPsec secures DHCP packets, OM data, IPsec scenario 1

IPsec secures OM data and all or a IPsec scenario 2

IPsec secures service data, signaling IPsec scenario 3

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 6

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 7

3 IP-based Automatic OMCH Establishment

3.1 OMCH Protocol Stacks

3.1.1 Non-IPsec Networking Scenario

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 8

3.1.2 IPsec Networking Scenario

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 9

Figure 3-3 Networking scenario in which IPsec secures OMCH data

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 10

The base station uses two types of IP addresses:

l IP addresses that can be used to access an untrusted domain

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 11

3.2 Base Station Obtaining Transmission Configuration

3.2.1 Transmission Mode of the OMCH

GBTS tries transmission modes in the following sequence:

3.2.2 Physical Layer Detection

Issue 01 (2017-03-08) Huawei Proprietary and Confidential 12

3.2.3 Data Link Layer Detection