Automatic OMCH Establishment (SRAN8.0 - 05)

SingleRAN
Automatic OMCH Establishment

Feature Parameter Description
Issue 05
Date 2013-10-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

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

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 05 (2013-10-30) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
Contents
1 About This Document..................................................................................................................1
1.1 Scope..............................................................................................................................................................................1
1.2 Intended Audience..........................................................................................................................................................1
1.3 Change History...............................................................................................................................................................1
2 Overview.........................................................................................................................................6
2.1 Introduction....................................................................................................................................................................6
2.2 Benefits...........................................................................................................................................................................7
2.3 Application Networking Scenarios.................................................................................................................................8
3 IP-based Automatic OMCH Establishment for Base Stations..............................................9
3.1 OMCH Protocol Stacks..................................................................................................................................................9
3.1.1 Non-IPsec Networking Scenario.................................................................................................................................9
3.1.2 IPsec Networking Scenario.......................................................................................................................................10
3.2 Base Station Obtaining Transmission Configuration Information...............................................................................13
3.2.1 Transmission Mode of the OMCH............................................................................................................................13
3.2.2 DHCP Overview........................................................................................................................................................13
3.2.3 DHCP Clients, Servers, and Relay Agents................................................................................................................17
3.2.4 DHCP Procedure.......................................................................................................................................................19
3.2.5 Schemes for Obtaining VLAN Information for DHCP Packets................................................................................23
3.3 Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station.............30
3.3.1 Overview...................................................................................................................................................................30
3.3.2 Automatic OMCH Establishment in Non-IPSec Networking Scenarios..................................................................30
3.3.3 Automatic OMCH Establishment in IPSec Networking Scenario 1.........................................................................49
3.4 Automatic OMCH Establishment by the Separate-MPT Multimode Base Station......................................................79
3.4.1 Networking................................................................................................................................................................79
3.4.2 Automatic OMCH Establishment Procedure............................................................................................................80
3.4.3 Configuration Requirements for the DHCP Server...................................................................................................81
3.4.4 Configuration Requirements for Network Equipment..............................................................................................83
3.5 Application Restrictions...............................................................................................................................................85
3.5.1 Configuration Requirements for Base Stations and Other Network Equipment.......................................................85
3.5.2 Impact of M2000 Deployment on Base Station Deployment by PnP.......................................................................92
SingleRAN
Automatic OMCH Establishment Feature Parameter
Description Contents
ii
4 ATM-based Automatic OMCH Establishment for Base Stations....................................101
4.1 Overview.................................................................................................................................................................... 101
4.2 Principles.................................................................................................................................................................... 101
4.2.1 Port Listening.......................................................................................................................................................... 102
4.2.2 Port Configuration................................................................................................................................................... 103
4.2.3 PVC Setup and BOOTP Request Initiation............................................................................................................. 103
4.2.4 RNC Returning the BOOTREPLY Message...........................................................................................................103
4.2.5 IPoA Configuration................................................................................................................................................. 104
4.3 Configuration Guidelines........................................................................................................................................... 104
5 TDM-based Automatic OMCH Establishment for Base Stations....................................105
5.1 Introduction................................................................................................................................................................ 105
5.2 Process........................................................................................................................................................................ 105
5.2.1 Sending L2ML Establishment Requests..................................................................................................................106
5.2.2 Saving Detection Information................................................................................................................................. 107
6 Parameters...................................................................................................................................108
7 Counters......................................................................................................................................131
8 Glossary.......................................................................................................................................132
9 Reference Documents...............................................................................................................133
SingleRAN
Description Contents
iii
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 LOFD-002004 Self-configuration
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
05 (2013-10-30)
This issue includes the following changes.
SingleRAN
Description 1 About This Document
1
Change Type Change Description Parameter
Change
Feature change None. None.
Editorial
change
Modified descriptions in the following sections:
l 3.2.3 DHCP Clients, Servers, and Relay Agents
l 3.5.1 Configuration Requirements for Base
Stations and Other Network Equipment
None.

04 (2013-09-30)
Change Type Change Description Parameter
Change
Feature change None. None.
Editorial
change
Adjusted the document structure as follows:
l Chapters 3 through 7 have been incorporated into
chapter 3 IP-based Automatic OMCH
Establishment for Base Stations
l The original chapter 8 is now chapter 4, and the
chapter title has been changed from "BOOTP" to 4
ATM-based Automatic OMCH Establishment
for Base Stations
l The original chapter 9 is now chapter 5, and the
chapter title has been changed from "OML
Timeslot Detection in TDM Networking" to 5
TDM-based Automatic OMCH Establishment
for Base Stations
l The original chapter 10 is now section 4.3, and the
section title has been changed from "Engineering
Guidelines" to 4.3 Configuration Guidelines
None.

03 (2013-08-30)
Change
Type
Change Description Parameter
Change
Feature
change
Added the function of saving VLAN IDs. For details, see
section Saving VLAN IDs.
None
SingleRAN
2
Change
Type
Change
Editorial
change
Deleted the automatic OMCH establishment function for
micro base stations.
None

02 (2013-06-30)
Chang
e Type
Change
Feature
change
l Added SSL authentication on the OMCH. For details, see
section SSL Authentication on the OMCH.
l Added the procedure for obtaining an operator-issued
device certificate in non-IPSec networking scenarios. For
details, see section Obtaining an Operator-Issued
Device Certificate.
l Added the procedure for obtaining an operator-issued
device certificate in IPSec networking scenario 2. For
details, see section Obtaining an Operator-Issued
Device Certificate.
l Added operation and maintenance link (OML)
establishment in time division multiplexing (TDM)
networking. For details, see chapter 5 TDM-based
Automatic OMCH Establishment for Base Stations.
None.
Editori
al
chang
Improved the document description. None.

01 (2013-04-28)
SingleRAN
3
Change Type Change Description Parameter Change
Feature change l Added the VLAN
scanning function. For
details, see Enabling and
Disabling the VLAN
Scanning Function.
l Added the Obtaining
Operator-issued
Certificates, see
Obtaining an Operator-
Issued Device
Certificate.
l Added the Establishing
an OMCH ,see
Establishing an OMCH.
Added the following
parameters:
l SWITCH
l VLANSCANSW
Editorial change l Added the transmission
mode of the OMCH. For
details, see section 3.2.1
Transmission Mode of
the OMCH.
l Added the automatic
OMCH establishment for
a NodeB in an
asynchronous transfer
mode (ATM) network.
For details, see 4 ATM-
based Automatic
OMCH Establishment
for Base Stations and 4.3
Configuration
Guidelines.
l Optimized the document
description.
Added the following
parameters:
l CARRYVPI
l CARRYVCI
l IPADDR
l PEERIPADDR
l NBATMOAMIP

Draft C (2013-04-10)
Feature change Added the automatic OMCH
establishment function for
micro base stations.
None.
SingleRAN
4
Editorial change Added cautions, MML
commands, and parameters
for deploying a DHCP relay
agent.
None.

Draft B (2013-02-25)
Feature change l Changed the names of
parameters that
correspond to subcodes 5
and 6 of Option 43 on the
M2000 DHCP server. For
details, see Table 3-5.
l Changed the length range
for subcode 38 of Option
43 to 1-127. For details,
see Table 3-9.
l Changed the IKEv1
proposal algorithms
supported by the base
station during
establishment of a
temporary IPSec tunnel.
For details, see Table
3-12.
None.
Editorial change None. None.

Draft A (2012-12-30)
This document is created for SRAN8.0.
SingleRAN
5
2 Overview
2.1 Introduction
Operation and maintenance channels (OMCHs) are established between base stations and the
operation maintenance center (OMC, either the M2000 or BSC). OMCHs are used to transmit
operation and maintenance information about base stations and are classified as follows:
l OMCHs between the single-mode base station, such as the eGBTS, NodeB, or eNodeB and
the M2000, or between the GBTS and the BSC.
l OMCHs between the co-MPT multimode base station and the M2000. MPT is short for
main processing and transmission unit.
l OMCHs between the separate-MPT multimode base station and the M2000. The separate-
MPT multimode base station is comprised of multiple cascaded single-mode base stations
and therefore has multiple OMCHs. For example, OMCHs for the separate-MPT UMTS/
LTE dual-mode base station include the OMCH between the NodeB and the M2000, and
the OMCH between the eNodeB and the M2000.
l OMCHs between the M2000 and the NodeB in an ATM 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 base stations 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 their respective main control boards and OMCHs.
In this document, a base station is used if differentiation among GSM, UMTS, and LTE modes is not
required. A GBTS, eGBTS, NodeB, eNodeB, co-MPT multimode base station, or separate-MPT multimode
base station is used if differentiation among GSM, UMTS, and LTE modes is required.
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 through the transport network and automatically establish an OMCH to the M2000
or BSC. The base station then can automatically download software and configuration files from
the M2000 or BSC over the established OMCH and activate them. After being commissioned,
the base station enters the working state.
This feature applies to base station deployment by plug and play (PnP). Figure 2-1 shows the
automatic OMCH establishment phase during base station deployment by PnP.
SingleRAN
Description 2 Overview
6
Figure 2-1 Automatic OMCH establishment phase during base station deployment by PnP
To establish an OMCH, a base station needs to obtain the following transmission configuration
information:
l Basic information, including its OM IP address, OM virtual local area network (VLAN)
ID, the interface IP address, the interface IP address mask, the IP address of the next-hop
gateway, the IP address of the M2000 or BSC, and the IP address mask of the M2000 or
BSC.
l Security-related information, including the Certificate Authority (CA) name, transmission
protocol (HTTP or HTTPS) used by the CA, CA address, CA port number, CA path, IP
address of the security gateway (SeGW),and name of the security gateway. Obtaining the
operator's CA information is required only when the base station needs to use 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 chapter "Base
Station Obtaining Transmission Configuration Information".
2.2 Benefits
With the Automatic OMCH Establishment feature, a base station can establish OMCHs by
network communication without requiring operations at the local end. This implements remote
base station deployment by PnP, thereby facilitating base station deployment and reducing the
deployment cost and time.
SingleRAN
7
2.3 Application Networking Scenarios
GBTSs and eGBTSs support automatic OMCH establishment in TDM and IP networking
scenarios. NodeBs support automatic OMCH establishment in ATM and IP networking
scenarios. eNodeBs support automatic OMCH establishment in IP networking scenarios.
Table 2-1 describes the application networking scenarios for the Automatic OMCH
Establishment feature. 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.
Table 2-1 Application networking scenarios
Networking Scenario Description
ATM The OMCH between the
NodeB and M2000 is
configured over ATM.
TDM The OMCH between the
GBTS and BSC is configured
over TDM.
Non-IPSec IPSec does not secure
Dynamic Host Configuration
Protocol (DHCP) packets,
OMCH data, service data,
signaling data, or clock data.
IPSec Scenario 1 IPSec secures DHCP
packets, OMCH data, and all
or some of the other data.
Scenario 2 IPSec secures OMCH data
and all or some of the other
data. It does not secure
DHCP packets.
Scenario 3: IPSec secures service and
signaling data. It neither
secures OMCH data nor all or
some of the other data.
SingleRAN
8
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
M2000 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 M2000.
Figure 3-1 Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT
multimode base station and the M2000
As shown in Figure 3-1, an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT
multimode base station and the M2000 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 M2000, and establishes the
TCP connection to the M2000 as requested. After the TCP connection is established, the M2000
SingleRAN
Description
3 IP-based Automatic OMCH Establishment for Base
Stations
9
initiates an OMCH establishment request to the eGBTS, NodeB, eNodeB, or co-MPT multimode
base station.
The M2000 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 M2000 is protected against eavesdropping
and therefore confidentiality and reliability are guaranteed. For details about SSL, see SSL
Feature Parameter Description.
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.
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
Description
Stations
10
Figure 3-3 Networking scenario in which IPsec secures OMCH data
As shown in Figure 3-3, the network is divided into the trusted domain and the untrusted domain,
which are separated by the SeGW. Devices in the untrusted domain cannot access the devices
in the trusted domain. After a base station starts, it establishes an IPSec tunnel to the SeGW.
Packets from the base station are sent over the IPSec tunnel to pass the untrusted domain and
then forwarded by the SeGW to the M2000 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 M2000 in IPSec networking scenarios.
Figure 3-4 Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT
multimode base station and the M2000 (IPSec networking)
Figure 3-5 shows the protocol stacks for an OMCH between the GBTS and the BSC in IPSec
networking scenarios.
SingleRAN
Description
Stations
11
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 apply only to IPSec scenarios. Whether the base
station supports IPSec depends on the base station type and the software and hardware pertaining to the
main control board.
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 the automatic OMCH establishment procedure, 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 source and destination IP addresses:
l IP addresses in the untrusted domain, that is, the interface IP addresses used for
communication with the SeGW in the untrusted domain after the base station starts.
l IP addresses in the trusted domain, that is, the IP addresses used for communication with
the M2000, BSC, or a DHCP server that is built into the M2000 (referred to as M2000
DHCP server in this document) in the trusted domain.
During base station deployment, devices in trusted and untrusted domains may communicate
with each other. For example, the base station uses an interface IP address in the untrusted domain
to communicate with the DHCP server in the trusted domain, or the DHCP relay agent uses an
IP address in the untrusted domain to communicate with the DHCP server in the trusted domain.
For details about the automatic OMCH establishment procedure, see sections 3.3.3 Automatic
OMCH Establishment in IPSec Networking Scenario 1 and 3.3.4 Automatic OMCH
Establishment in IPSec Networking Scenario 2.
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. Then, the base station
establishes an IPSec tunnel to the SeGW as well as the OMCH that the new IPSec tunnel provides
security to.
SingleRAN
Description
Stations
12
For details about IPSec tunnels, see IPSec Feature Parameter Description. For details about
digital certificate management, see PKI Feature Parameter Description.
If the operator uses IPSec and pre-shared key (PSK) authentication, the base station fails to
automatically establish an OMCH. In this case, you must use other methods to deploy the base
station.
NOTE
During the OMCH establishment procedure, the eGBTS, NodeB, eNodeB, or co-MPT multimode base
station listens to specific TCP port numbers, and the GBTS listens to the UDP port numbers. For details,
see Communication Matrix of 3900 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, M2000, or BSC.
After establishing an OMCH to the M2000, the base station uses File Transmission Protocol (FTP) to
download software and configuration files from the FTP server. FTP runs over TCP/IP, and therefore its
transport layer can be 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.
IPSec networking is not supported by the following base stations:
l GBTSs in which the GTMU provides the transmission port.
l NodeBs in which the WMPT provides the transmission port.
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 transmission modes, and Ethernet ports support the IP transmission
mode. No transmission mode is configured on the base station before the OMCH is established.
Therefore, the base station tries different transmission modes over the transmission ports until
the OMCH is successfully established. The base station tries, in descending order of priority, IP
over FE/GE, ATM, and IP over E1/T1 transmission modes.
3.2.2 DHCP Overview
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. To implement this
communication, the base station needs to obtain the following information:
l OMCH configuration data, including the OM IP address, OM VLAN ID, interface IP
address, interface IP address mask, IP address of the next-hop gateway, IP address of the
M2000 or BSC, and IP address mask of the M2000 or BSC.
l During base station deployment by PnP, if the base station needs to use digital certificates
issued by the operator's CA to perform identity authentication with other devices, it also
needs to obtain the operator's CA information, including the CA name, CA address, CA
port number, CA path, and transmission protocol (HTTP or HTTPS) used by the CA.
SingleRAN
Description
Stations
13
l In IPSec networking scenarios, the base station also needs to obtain SeGW information,
including the SeGW IP address and SeGW local name.
The base station uses DHCP to obtain the preceding information. DHCP is used to allocate and
distribute configuration parameters and adopts the 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 client 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.
DHCP Interworking
When a DHCP client and a DHCP server are in the same broadcast domain, they can receive
broadcast packets from 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
1. After the DHCP client starts, it broadcasts a DHCPDISCOVER packet to search for an
available DHCP server. The DHCPDISCOVER packet carries the identification
information about the DHCP client.
SingleRAN
Description
Stations
14
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, the DHCP client sends a DHCPDECLINE packet to notify
the DHCP server.
6. If the DHCP client does not need the assigned parameters any more, it sends a
DHCPRELEASE packet 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, they cannot
receive broadcast packets from 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. Generally, 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
DHCP Packet Format
Figure 3-8 shows the example format of DHCP packets shown in Figure 3-6.
SingleRAN
Description
Stations
15
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.
In a DHCP packet, the IP and UDP headers are in the standard format, and 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.
Option fields: They are encoded in code-length-value (CLV) format and consist of many
subcodes. Among them, 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 Option43, see Table 3-5.
SingleRAN
Description
Stations
16
Because 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.3 DHCP Clients, Servers, and Relay Agents
In this document, base stations act as DHCP clients. Table 3-1 describes the mapping between
base stations and DHCP servers.
Table 3-1 Mapping between base stations and DHCP servers
Base Station Type DHCP Server in
Non-IPSec
Networking
Scenarios
DHCP Server in
IPSec Networking
Scenarios
Single-mode GBTS BSC In the trusted
domain: M2000
DHCP server
In the untrusted
domain: public
DHCP server
eGBTS M2000
NodeB M2000 or RNC
eNodeB M2000
Multimode Co-MPT multimode
base station
M2000
Separate-MPT
multimode base
station
Same as that of each
single-mode base
station

NOTE
Unless otherwise specified, "base station controller" in this document is a generic term for GSM and UMTS
modes.
The DHCP server and the M2000 are different logical communication entities, although they may be
deployed on the same hardware. Therefore, this document distinguishes between the DHCP server and the
M2000.
The DHCP server can be deployed on the L2 network of the base station only when the DHCP
server is deployed on the base station controller instead of the M2000. This is because DHCP
packets carry the well-known UDP port number and the operating system of the M2000 always
discards such packets. Therefore, the DHCP server deployed on the M2000 can process only
DHCP packets forwarded by the DHCP relay agent, but not DHCP packets broadcast by the
base station.
In SRAN8.0 and later versions, if single-mode base stations or separate-MPT multimode base
stations evolve to co-MPT multimode base stations, their DHCP servers must migrate to the
M2000. Even if the evolution is not implemented, the migration is recommended, because it
provides better function support and paves the way to future smooth upgrades and evolutions.
SingleRAN
Description
Stations
17
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 The DHCP relay agent function must be enabled and the DHCP server IP address must be
configured on the next-hop gateway of the base station. A port on the base station controller
cannot serve as the DHCP relay agent and DHCP server simultaneously for a GBTS or
NodeB. In this case, the base station controller serves as the DHCP relay agent or DHCP
server for all of the GBTSs and NodeBs it is connected to.
l When the base station is on the same L2 network as the base station controller and the
M2000 serves as the DHCP server for the base station, 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. In this command:
DHCPRLYID(BSC6910,BSC6900) indicates the identity of a DHCP relay agent.
DHCPRLYGATEWAYIP(BSC6900,BSC6910) indicates the interface IP address of
the base station controller.
DHCPSRVISEMSIP(BSC6900,BSC6910) indicates whether the M2000 that manages
the base station controller serves as the DHCP server for the base station. If not, the
DHCP server IP address of the base station (the DHCPSRVIP parameter) also needs
to be configured.
Here are a few example MML commands:
//Enabling the DHCP relay agent function on the base station controller when
the M2000 that manages this base station controller is the DHCP server for
the base station
ADD DHCPRLY: DHCPRLYID=1, DHCPRLYGATEWAYIP="10.1.1.1.1",
DHCPSRVISEMSIP=Yes;
//Enabling the DHCP relay agent function on the base station controller when
the M2000 that manages this base station controller is not the DHCP server
for the base station and the DHCP server IP address of the base station is
10.0.0.0.1
ADD DHCPRLY: DHCPRLYID=1, DHCPRLYGATEWAYIP="10.1.1.1.1", DHCPSRVISEMSIP=No,
DHCPSRVIP1="10.0.0.0.1";
The RSVDSW1(BSC6900,BSC6910) parameter applies to BSC6900 only. If this
parameter is left unspecified, the base station controller serves as the DHCP server. If
this parameter is set to TS9 using the following command, the base station controller
serves as the DHCP relay agent and forwards all the DHCP packets except those from
the GBTS to the DHCP server.
SET TRANSRSVPARA: RSVDSW1=TS9-1;
NOTE
A port on the base station controller cannot serve as the DHCP relay agent or DHCP server simultaneously.
l If the base station controller is not on the same L2 network as the base station and the
M2000 serves as the DHCP server for the base station, the DHCP relay agent function must
be enabled and the IP address of the M2000 DHCP server must be configured on the next-
hop gateway of the base station.
l When base stations are cascaded, an upper-level base station serves as the next-hop gateway
for its 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
SingleRAN
Description
Stations
18
enable the DHCP relay agent function. Then, run the ADD DHCPSVRIP command with
DHCPSRVIP set to the DHCP server IP address of the lower-level base station. A
maximum of four DHCP server IP addresses can be configured.
//Enabling the DHCP relay agent function on the upper-level base station
SET DHCPRELAYSWITCH: ES=ENABLE;
// Setting the DHCP server IP address to 19.19.19.11. Each broadcast DHCP
packet received by the upper-level base station will be forwarded to all DHCP
servers.
ADD DHCPSVRIP: DHCPSVRIP="19.19.19.11";
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 is the same as those for an upper-
level base station.
3.2.4 DHCP Procedure
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 based on the base station identification (BS ID)
contained in the DHCP packet.
The M2000 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 M2000s 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.
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. The ESN is 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
M2000 uses the combination of the ESN and slot number as the BS ID. The DID must be included
SingleRAN
Description
Stations
19
in the base station configuration file if the M2000 uses the combination of the 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 and the DHCP server of the base station is deployed
on the M2000.
Procedure for Obtaining Configuration Information in Non-IPSec Networking
Scenarios
Procedure for 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 the
Ethernet or a VLAN of the Ethernet.
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.
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, it broadcasts a
DHCPDISCOVER packet with the BS ID. The DHCP server then sends configuration
information to the base station based on the BS ID.
Procedure for 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.
SingleRAN
Description
Stations
20
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 to unicast packets and routes the unicast packets 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.
Procedure for Obtaining Configuration Information in IPSec Networking
Scenarios
In IPSec networking scenarios, a 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
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 in Figure 3-11 to obtain transmission
configuration information.
SingleRAN
Description
Stations
21
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 also needs to obtain the CA IP address because digital
certificates are required 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. Because digital
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 M2000 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 "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.
If this occurs, 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 M2000 DHCP server sends
configuration parameters to the base station based on the BS ID reported by the base station.
Procedure for Releasing Allocated Configuration Information
When a base station obtains configuration information from its M2000 DHCP server and does
not need 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.
SingleRAN
Description
Stations
22
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 configuration
information.
3.2.5 Schemes for Obtaining VLAN Information for DHCP Packets
Overview
Packets sent by a base station on a VLAN-based network must carry the VLAN ID. Before an
OMCH is established, that is, 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.
2. The base station sends DHCP packets without VLAN IDs or DHCP packets with VLAN
IDs set to 0.
3. 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 goes to the next step.
4. The base station checks the PnP VLAN-ID table and tries to use all acquired VLAN IDs
to send DHCP packets. After that, if the base station receives a valid DHCPOFFER packet,
it exits the DHCP procedure and enters the subsequent PnP deployment procedure.
5. When the preceding steps fail:
l If the base station has only one transmission port, the base station repeats the preceding
steps on this port.
l If the base station has multiple transmission ports, it repeats the preceding steps on other
transmission ports.
Table 3-2 describes the recommended schemes for the base station in SRAN8.0 and later
versions to obtain VLAN information during deployment.
SingleRAN
Description
Stations
23
Table 3-2 Obtaining VLAN information
Scenario SN Base Station
Deployment
Mode
Whether
IPSec Secures
OMCH Data
Requirements
for NEs
How to
Obtain VLAN
Information
1 By PnP No N/A Using scheme 1
2 By PnP Yes l The SeGW
initiates a
request for
IKE
negotiation
with the base
station. The
destination
IP address 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
configuratio
n files of the
base station.
3 By PnP Yes The security
policy allows
the transmission
of DHCP
packets sent by
the M2000
DHCP server to
the base station.
Using scheme 2
SingleRAN
Description
Stations
24
Scenario SN Base Station
Deployment
Mode
Whether
IPSec Secures
OMCH Data
Requirements
for NEs
How to
Obtain VLAN
Information
4 By PnP Yes The L2 network
is configured
with the default
VLAN ID or no
VLAN ID.
Using scheme 3
5 By PnP Yes The next-hop
gateway of the
base station can
periodically
send ping
packets to the
interface IP
address of the
base station.
Using scheme 4

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 M2000 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 M2000 periodically sends the base station empty
DHCPOFFER packets (containing DHCP headers only) with the destination IP address
set to the 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. Therefore, 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.
Scheme 1
Scheme 1 applies to two scenarios:
SingleRAN
Description
Stations
25
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.
Figure 3-14 Scheme 1 (IPsec does not secure OMCH data)
1. The M2000 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 attempts to send all DHCP packets with recorded VLAN IDs. Only DHCP
packets with correct VLAN IDs can reach the DHCP relay agent that installed on the next-
hop gateway of the DHCP client.
Figure 3-15 Scheme 1 (IPSec secures OMCH data)
SingleRAN
Description
Stations
26
1. The M2000 or BSC sends an OMCH establishment request to the OM IP address of the
base station. The request is forwarded to the SeGW.
2. The SeGW detects that the IPSec SA with the base station has not been established and
sends an IKE negotiation request to the interface IP address of the base station. The request
is 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.
the packets. It may record the VLAN ID in an ARP packet destined for another base station.
packets with correct VLAN IDs can reach the DHCP relay agent.
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 M2000 sends a DHCPOFFER packet with no content to the interface IP address of the
base station. The packet is 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.
SingleRAN
Description
Stations
27
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 be forwarded over the L2 network to the DHCP relay agent and
then reach the DHCP server.
Scheme 4
SingleRAN
Description
Stations
28
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.
Enabling and Disabling the VLAN Scanning Function
In SRAN7.0, the VLAN scanning function is provided for eNodeBs to solve the problem that
base stations cannot acquire VLAN IDs in secure networking scenarios. After the VLAN
scanning function is enabled, the base station tries to send DHCP packets with random VLAN
IDs if it 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,
you can run the SET DHCPSW command to enable or disable this function locally or remotely.
//Enabling the VLAN scanning function
SingleRAN
Description
Stations
29
SET DHCPSW: SWITCH=ENABLE; VLANSCANSW=ENABLE;
//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 start the DHCP procedure automatically 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.
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 that are used
for the DHCP procedure. A maximum of eight VLAN IDs can be saved. When saving a new
VLAN ID if eight VLAN IDs have already been saved, the new VLAN ID will replace the
earliest VLAN ID.
The base station can use the saved VLAN IDs 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 the 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, and the procedures' requirements for NEs. In IPSec networking scenarios, the network
is divided into the untrusted domain and the trusted domain. Depending on NE distribution in
the untrusted domain and the trusted domain, IPSec networking scenarios are classified as
follows:
l Scenario 1: IPSec secures OMCH data and DHCP packets.
l Scenario 2: IPSec secures OMCH data, but not DHCP packets.
l Scenario 3: IPSec secure service data, but not OMCH data or DHCP packets.
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 starts automatic
OMCH establishment again.
3.3.2 Automatic OMCH Establishment in Non-IPSec Networking
Scenarios
SingleRAN
Description
Stations
30
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.
Automatic OMCH Establishment Procedure
Figure 3-20 shows the automatic OMCH establishment procedure in non-IPSec networking
scenarios.
Figure 3-20 Automatic OMCH establishment in non-IPSec networking scenarios
SingleRAN
Description
Stations
31
1. After a base station commissioning task by PnP task is created on the M2000, the M2000
periodically sends an SSL-based or plaintext-based OMCH establishment request to the
base station. After an NE is created on the BSC, the BSC periodically sends a plaintext-
based OMCH establishment request to the base station. In the request, the source IP address
is the IP address of the M2000 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, it
broadcasts ARP packets to the base station to obtain the MAC address mapping the interface
IP address of the base station.
NOTE
l The next-hop gateway of the base station broadcasts ARP packets each time it receives a TCP
connection request sent periodically by the M2000.
l If the Use SSL option on the M2000 is selected, the M2000 periodically sends an SSL-based
OMCH establishment request to the base station. If this option is not selected, M2000 periodically
sends a plaintext-based OMCH establishment request to the base station.
l During a DHCP procedure, a DHCP response packet sent by the M2000 contains the target RAT
for the base station. Upon detecting the inconsistency between the current and target RATs, the
base station changes its current RAT for consistency and then restarts. Afterwards, the base
station reinitiates a DHCP procedure.
2. The base station obtains VLAN information. For details, see section "Schemes for
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 validates the data.
4. In response to the ARP packets and the OMCH establishment request, the base station
establishes an OMCH to the M2000 or BSC. The DHCP server then sends related
configuration files to the base station based on the BS ID.
Configuration Requirements for the DHCP Server
The DHCP server of a base station must be configured with the following:
l A route whose destination IP address is the IP address of the base station or whose
destination network segment is the network segment of the base station.
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-3 lists the parameters to be contained in the DHCP packet headers.
Table 3-3 Parameters to be contained in the DHCP packet headers
Parameter
Name
Mapping
DHCP
Field
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
Interface IP
Address
yiaddr 4 Interface IP
address of
the base
station
Mandatory l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
32
Parameter
Name
Mapping
DHCP
Field
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
Relay Agent
IP
giaddr 4 IP address of
the DHCP
relay agent
deployed on
the network,
if any.
Broadcast
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.
Optional l DHCPDI
SCOVE
RY
l DHCPO
FFER
l DHCPR
EQUEST
l DHCPA
CK

Table 3-4 lists the parameters to be contained in Option fields defined by RFC 2132.
Table 3-4 Parameters to be contained in DHCP Option fields
Parameter
Name
Mapping
DHCP
Option
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
Subnet Mask 1 4 Subnet mask
of a DHCP
client
Mandatory l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
33
Parameter
Name
Mapping
DHCP
Option
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
Router
Option
3 N*4 List of the IP
addresses of
routers
deployed in a
DHCP
client's
subnet
N indicates
the number
of next-hop
gateways for
the DHCP
client.
Mandatory l DHCPO
FFER
l DHCPA
CK
Vendor
Specific
Information
43 0-255 Vendor-
specific
information
exchanged
between a
DHCP client
and a DHCP
server
Mandatory l DHCPDI
SCOVE
R
l DHCPR
EQUEST
l DHCPO
FFER
l DHCPA
CK
IP Address
Lease Time
51 4 Lease time of
an assigned
IP address
Mandatory l DHCPO
FFER
l DHCPA
CK
DHCP
Message
Type
53 1 Value:
1:
DHCPDISC
OVER
2:
DHCPOFFE
R
3:
DHCPREQ
UEST
5:
DHCPACK
Mandatory l DHCPDI
SCOVE
R
l DHCPR
EQUEST
l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
34
Parameter
Name
Mapping
DHCP
Option
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
Server
Identifier
54 4 IP address of
a DHCP
server
Mandatory l DHCPO
FFER
l DHCPA
CK
l REQUES
T
Renewal
(T1) Time
Value
58 4 Interval from
address
assignment
to the
transition to
the
RENEWIN
G state
Optional l DHCPO
FFER
l DHCPA
CK
Rebinding
(T2) Time
Value
59 4 Interval from
address
assignment
to the
transition to
the
REBINDIN
G state
Optional l DHCPO
FFER
l DHCPA
CK
Vendor class
identifier
60 0-255 Vendor type
and client
configuratio
n
Optional l DHCPDI
SCOVE
R
l DHCPR
EQUEST
Client-
identifier
61 0-255 Unique
identifier of a
DHCP client
Optional l DHCPDI
SCOVE
R
l DHCPR
EQUEST

Table 3-5 lists the parameters to be contained in subcodes of Option 43 defined by Huawei.
SingleRAN
Description
Stations
35
Table 3-5 Parameters to be contained in subcodes of option 43
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
ESN 1 20 ESN of the
BBU
backplane. It
is used by a
DHCP server
to determine
the location
and BBU
subrack of
the base
station.
Mandatory l DHCPDI
SCOVE
R
l DHCPO
FFER
l DHCPR
EQUEST
l DHCPA
CK
DHCP
Server ID
50 1 Whether the
DHCP
packets are
sent by the
M2000
DHCP
server. The
M2000
DHCP server
fills in this
field when
sending the
DHCP
packets. If
the DHCP
packets are
not sent by
the M2000
DHCP
server, this
field is left
blank.
Mandatory
when the
M2000
serves as the
DHCP
server. This
field is left
blank when a
device other
than the
M2000
serves as the
DHCP
server.
l DHCPO
FFER
l DHCPA
CK
MPT 1st Slot
Number
251 1 Slot number
of the first
main control
board
Mandatory l DHCPDI
SCOVE
R
l DHCPO
FFER
l DHCPR
EQUEST
l DHCPA
CK
SingleRAN
Description
Stations
36
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
MPT 2nd
Slot Number
249 1 Slot number
of the second
main control
board
Mandatory
only if the
base station
is configured
with active/
standby or
primary/
secondary
main control
boards.
l DHCPO
FFER
l DHCPA
CK
OM Bearing
Board
250 1 Value:
l 0: An
OMCH is
establish
ed on the
panel.
Use this
value for
single-
mode
base
stations.
l 1: An
OMCH is
establish
ed on the
backplan
e.
Optional.
The default
value is 0.
l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
37
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
DID 27 1 to 64 If the base
station is
configured
with only
one BBU, the
DID serves
the same
purpose as
the ESN.
If the base
station is
configured
with multiple
BBUs that
are
interconnect
ed using
UCIUs,
these BBUs
use the same
DID.
Optional.
DID is
mandatory if
it is used as
the base
station
identificatio
n in DHCP
packets.
l DHCPDI
SCOVE
R
l DHCPO
FFER
l DHCPR
EQUEST
l DHCPA
CK
SingleRAN
Description
Stations
38
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
Subrack
Topo
246 1 to 16 Interconnecti
on
relationship
between the
BBU
accommodat
ing the main
control board
that sends the
DHCP
packets and
other BBUs
if these
BBUs are
interconnect
ed using
UCIUs. The
DHCP server
uses the
combination
of the DID,
subrack
topology,
and slot
number to
identify the
configuratio
n file of the
base station.
Mandatory l DHCPDI
SCOVE
R
l DHCPO
FFER
l DHCPR
EQUEST
l DHCPA
CK
SingleRAN
Description
Stations
39
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
OM
Interface
Type
2 1 Transmissio
n interface of
the base
station:
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 M2000
or the next-
hop gateway
of the base
station.
Optional
The default
value is
Ethernet.
l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
40
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
OM
Interface
Slot Number
248 1 Slot number
of the main
control board
if the
transmission
interface is
provided by
the main
control
board, or the
slot number
of the UTRP
board if the
transmission
interface is
provided by
the UTRP
board.
Mandatory
in SRAN8.0
or later only
if an Ethernet
interface is
used as the
transmission
interface. If
this
parameter is
not
specified, the
base station
automaticall
y identifies
the slot
number.
l DHCPO
FFER
l DHCPA
CK
OMCH
Interface
Port Number
247 1 Port number
of the
transmission
interface of
the base
station
Mandatory
in SRAN8.0
or later only
if an Ethernet
interface is
used as the
transmission
interface. If
this
parameter is
not
specified, the
base station
automaticall
y identifies
the port
number.
l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
41
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
OMLOCAT
ION
51 2 The numbers
of the
cabinet, and
subrack that
accommodat
e the main
control board
where the
OMCH is
located.
Mandatory
in SRAN8.0
or later only
if an Ethernet
interface is
used as the
transmission
interface.
If this
parameter is
not
specified, the
base station
automaticall
y identifies
the numbers
of the
cabinet, and
subrack.
l DHCPO
FFER
l DHCPA
CK
OM IP
Address
3 4 Local IP
address of
the OMCH
Mandatory l DHCPO
FFER
l DHCPA
CK
OM IP
Address
Subnet Mask
4 4 Local IP
address mask
of the
OMCH
Mandatory l DHCPO
FFER
l DHCPA
CK
M2000 IP
Address
5 4 Peer IP
address of
the OMCH
Optional l DHCPO
FFER
l DHCPA
CK
M2000 IP
Subnet Mask
6 4 Peer IP
address mask
of the
OMCH
NOTE
In the
decimal
equivalent of
this
parameter
value, 01 is
not allowed.
Optional l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
42
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
OM Vlan ID 11 2 VLAN ID of
the OMCH
Optional.
This
parameter is
mandatory if
VLAN is
configured
on the
Ethernet port
of the base
station.
l DHCPO
FFER
l DHCPA
CK
OM Vlan
Priority
12 1 VLAN
priority of
the OMCH
Optional.
This
parameter is
not included
in DHCP
packets
when an E1/
T1 port is
used as the
transmission
port.
l DHCPO
FFER
l DHCPA
CK
BSC IP 13 4 IP address of
the BSC
Mandatory
for the GSM
mode
l DHCPO
FFER
l DHCPA
CK
OM Next
Hop IP
Address
17 4 Next-hop IP
address of
the base
station
Mandatory l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
43
Parameter
Name
Mapping
Subcode
Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
GBTS
OMCH
DSCP
54 1 DSCP the
GBTS uses
to establish
an OMCH.
Optional.
This
parameter is
supported
only by
GBTSs from
SRAN7.0
onwards. If
this
parameter is
not
specified, the
DSCP
subcode will
not be
delivered.
DHCPOFFE
R
DHCPACK

When creating a base station commissioning by PnP task on the M2000, deployment engineers
can import configuration information listed in Table 3-5 into the DHCP server. Deployment
engineers can manually modify the configuration information for the DHCP server only on the
M2000 GUI. Deployment may fail if the DHCP server is not configured with mandatory
parameters listed in Table 3-5 or optional parameters that must be configured in certain
scenarios.
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 M2000.Figure 3-21 shows the automatic
OMCH establishment procedure in this scenario.
Figure 3-21 Automatic OMCH establishment procedure
SingleRAN
Description
Stations
44
1. After a PnP-based commissioning task is created on the M2000, the M2000 periodically
sends SSL-based or plaintext OMCH establishment requests to the base station.
The source and destination IP addresses of the request packets are the IP address of the
M2000 and the O&M IP address of the base station, respectively.
2. 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.
3. The base station obtains VLAN information.
For details, see section "Schemes for Obtaining VLAN Information for DHCP Packets".
4. The base station attempts to first send DHCP packets without VLAN IDs and then DHCP
packets with VLAN IDs. By exchanging the DHCP packets with its next-hop gateway and
the DHCP server, the base station obtains OMCH configurations and makes them take
effect.
5. Based on the CA information obtained from the DHCP server, the base station applies for
an operator-issued device certificate from the CA.
6. In response to ARP requests of the next-hop gateway and OMCH establishment requests
of the M2000, the base station implements authentication and establishes an OMCH to the
M2000.
In this scenario, the M2000 functions as the DHCP server and delivers configurations to the base
station. The configurations include those described in section Configuration Requirements
for the DHCP Server and CA information described in Table 3-6.
Table 3-6 Parameters specific to the M2000 DHCP server
Param
eter
Catego
ry
Parame
ter
Name
Sub-
code
Length (Bytes) Parameter
Description
Man
dato
ry or
Opti
onal
DHCP
Packet
CA
informa
tion
CA URL 44 1-128 URL of the CA
from which the
base station
obtains an
operator-issued
device certificate
in IPSec
networking
scenarios
This URL must be
reachable in the
untrusted domain.
Man
dator
y
l DH
CPO
FFE
R
l DH
CPA
CK
CA
Name
38 1-127 CA name

SingleRAN
Description
Stations
45
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. Before delivery, Huawei base stations are preconfigured with Huawei-
issued device certificates, which are deployed on the UMPT and the LMPT (available from
SRAN7.0 onwards). The CA is also preconfigured with the 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-7 to complete
the certificate application.
NOTE
For details about the certificate application procedure, see the "Certificate Management and Application
Scenarios" part in PKI Feature Parameter Description for SingleRAN.
Table 3-7 Default parameters used for certificate application
Paramet
er
Categor
y
Parameter
Name
Parameter Description Remarks
CMPv2-
related
paramete
rs
Source IP Source IP address used to
apply for the operator-
issued device certificate
This parameter is set to the
interface IP address of the base
station that is obtained through the
DHCP procedure.
CA URL
During Site
Deployment
URL of the CA This parameter is set to the URL
of the CA that is obtained through
the DHCP procedure.
Signature
Algorithm
Signature algorithm for
CMP messages
This parameter is set to SHA1.
Paramete
rs in the
certificat
e request
file
Request
Type
Type of a certificate
request. The request can be
either a new certificate
request or a certificate
update request. The default
type is new certificate
request.
This parameter is set to NEW.
Certificate
Request File
Format
Format of a certificate
request file
This parameter is set to CRMF.
Renew Key Whether to generate a new
key pair
This parameter is set to YES.
SingleRAN
Description
Stations
46
Paramet
er
Categor
y
Parameter
Name
Key Size Length of a key This parameter is set to
KEYSIZE2048.
Common
Name
Common name of the
certificate request file
This parameter is set to the ESN of
the base station that applies for a
certificate.
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
Algorithm
Signature algorithm for a
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
station. This parameter is
used to generate the DNS
name of the subject
alternative name of a
certificate.
The value of this parameter
consists of the ESN of the base
station and ".huawei.com."
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 IP
address obtained may not be used
finally.

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 M2000. After the authentication is successful, a secure OMCH is
established between them.
SingleRAN
Description
Stations
47
Configuration Requirements for NEs
Table 3-8 describes the configuration requirements for network equipment during base station
deployment by PnP in the non-IPSec networking scenario shown in Figure 3-19.
Table 3-8 Configuration requirements for network equipment
Network Equipment Requirement
Base station None
Next-hop L2 device of the base station (Optional) Is configured with VLAN
information. VLAN configuration is required
only when the L2 network adopts VLANs.
L2 devices l Allow the transmission of DHCP
broadcast and unicast packets without
filtering or modifying DHCP packets.
l Are configured with the VLAN
forwarding function that matches the base
station.
Next-hop L3 device of the base station l Is enabled with the DHCP relay agent
function.
l Is configured with the IP address of the
DHCP server. Generally, the IP address is
that of the M2000. If a Network Address
Translation (NAT) server is deployed, the
IP address is the IP address converted by
the NAT server.
l Is configured with a route whose
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 interface IP address.
destination IP address is the IP address of
the CA if the OMCH uses SSL
authentication.
L3 devices l Are configured with a route whose
address of the base station, the IP address
of the M2000, and the DHCP relay agent,
respectively.
l Are configured with a route whose
the CA if the OMCH uses SSL
authentication.
SingleRAN
Description
Stations
48
M2000 or BSC Is configured with a route whose destination
IP address is the OM IP address of the base
station.
DHCP server Is configured with a route whose destination
IP address is the DHCP relay agent IP
address.
FTP server
CA (used only when the OMCH uses SSL
authentication)
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.
l Is configured with an IP address that is
accessible by devices in the untrusted
domain.
l Is configured with the Huawei root
certificate.

3.3.3 Automatic OMCH Establishment in IPSec Networking
Scenario 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
Description
Stations
49
l A public DHCP server and an M2000 DHCP server are deployed in the untrusted domain
and the trusted domain, respectively. The base station obtains from the public DHCP server
the transmission configuration information required for establishing a temporary IPSec
tunnel to the SeGW and obtains from the M2000 DHCP server the formal transmission
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 M2000 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:
1. The base station obtains the following information from the public DHCP server:
l Interface IP address used for accessing NEs in the untrusted domain.
l Configuration information used for establishing an IPSec tunnel to the SeGW. The
information includes the SeGW configuration data and the CA configuration data.
2. The base station obtains digital certificates from the CA.
3. After establishing the IPSec tunnel, the base station obtains the OMCH configuration data
from the M2000 DHCP server. The 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 M2000 DHCP server.
Figure 3-23 shows the automatic OMCH establishment procedure in IPSec networking scenario
1.
Figure 3-23 Automatic OMCH establishment procedure in IPSec networking scenario 1
SingleRAN
Description
Stations
50
1. The base station obtains VLAN information. For details, see section "3.2.5 Schemes for
2. Using the DHCP procedure, the base station obtains from the public DHCP server the
transmission configuration information 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 M2000 DHCP server IP address. For details about the
configuration information on the public DHCP server, see section "Configuration
Requirements for the DHCP Server".
3. Using CMPv2, the base station applies to the CA for an operator-issued device certificate
and a CA root certificate. The base station adds the obtained CA root certificate to the
default trusted certificate list so that it can authenticate peer NEs, such as the SeGW. If the
application for operator-issued digital certificates fails or receives no response within about
30 seconds, the preconfigured digital certificates are used for establishing an IPSec tunnel.
NOTE
l The operator's CA must be configured with the Huawei-issued CA root certificate to authenticate
the device certificate of the base station. The base station uses the Huawei-issued device
certificate for identity authentication by the CA.
l During a DHCP procedure, a DHCP response packet sent by the M2000 contains the target RAT
for the base station. Upon detecting the inconsistency between the current and target RATs, the
base station changes its current RAT for consistency and then restarts. Afterwards, the base
station reinitiates a DHCP procedure.
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 "Establishing a Temporary IPSec Tunnel".
5. With protection from the temporary IPSec tunnel, the base station obtains formal
transmission configuration information from the M2000 DHCP server in different ways,
depending on whether the IP address used for accessing the trusted domain and the M2000
DHCP server IP address are available. For details, see section "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 "Establishing a Formal IPSec Tunnel".
7. With protection from the formal IPSec tunnel, the base station waits 10 minutes for the
SSL-based or plaintext-based OMCH establishment request from the M2000 or BSC and
finally establishes an OMCH to the M2000 or BSC. If an OMCH is established between
the M2000 and base station within 10 minutes, the automatic OMCH establishment
procedure ends and the system enters the subsequent PnP deployment procedure. If an
OMCH is not established between the M2000 and base station within 10 minutes, the
automatic OMCH establishment procedure is restarted.
Configuration Requirements for the Public DHCP Server
The public DHCP server must be configured with the parameters listed in Table 3-9 as well as
a route whose destination IP address is the IP address of the base station or whose 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.
SingleRAN
Description
Stations
51
Table 3-9 Parameters to be configured on the public DHCP server
Classific
ation
Param
eter
Name
Mapp
ing
Subc
ode
Leng
th
(Byt
es)
Parameter
Description
Mandato
ry or
Optional
DHCP
Packet
Involved
CA
informati
on
PKI
SERV
ER IP
35 4 IP address of the CA Mandator
y only if
identity
authentica
tion by
digital
certificate
s is
required
and the
CA URL
is not
configure
d.
These
parameter
s
collectivel
y identify
and equal
the URL
of the CA.
These
four
parameter
s cannot
be
configure
d if the CA
URL has
been
configure
d.
l DHCPOF
FER
l DHCPA
CK
CA
protoco
l type
39 1 Protocol used to
access the CA: HTTP
or HTTPS
Value 0 indicates
HTTP and value 1
indicates HTTPS.
When the
communication
between the base
station and CA is
protected by SSL, this
parameter must be set
to 1.
l DHCPOF
FER
l DHCPA
CK
CA
port
36 2 HTTP or HTTPS port
number of the CA
l DHCPOF
FE
l DHCPA
CK
CA
Path
37 1 to
60
Path for saving digital
certificates on the CA.
This parameter is
optional if no path is
required for accessing
the CA.
l DHCPOF
FE
l DHCPA
CK
SingleRAN
Description
Stations
52
Classific
ation
Param
eter
Name
Mapp
ing
Subc
ode
Leng
th
(Byt
es)
Parameter
Description
Mandato
ry or
Optional
DHCP
Packet
Involved
CA
URL
44 1 to
128
URL used for
accessing the digital
certificate path.
This parameter is
configurable only
when the base station
and CA use CMPv2.
The CA URL format
is as follows: http(s)://
CAIP:CAport/
CAPath
Mandator
y only if
the
following
parameter
s are not
configure
d when
authentica
tion by
digital
certificate
s is
required:
PKI
SERVER
IP, CA
protocol
type, CA
port, and
CA Path.
l DHCPOF
FE
l DHCPA
CK
CA
Name
38 1 to
127
CA name Mandator
y only if
the base
station
uses the
digital
certificate
s for
identity
authentica
tion
l DHCPOF
FE
l DHCPA
CK
SeGW
informati
on
Public
SeGW
IP
Addres
s
18 4 IP address of the
public SeGW in IPSec
networking scenarios.
This parameter is
allocated by the
public DHCP server
and used during
DHCP interworking
between the base
station and the M2000
DHCP server.
Mandator
y only if
the base
station
needs to
access the
M2000
DHCP
server
through
the SeGW
l DHCPOF
FE
l DHCPA
CK
SingleRAN
Description
Stations
53
Classific
ation
Param
eter
Name
Mapp
ing
Subc
ode
Leng
th
(Byt
es)
Parameter
Description
Mandato
ry or
Optional
DHCP
Packet
Involved
Public
SeGW
Local
Name
31 1 to
32
Local name of the
public SeGW.
It is used by the base
station to authenticate
the public SeGW in
IPSec networking
scenarios.
Optional
when the
SeGW is
configure
d
l DHCPOF
FE
l DHCPA
CK
Internal
DHCP
server IP
address
(list)
Interna
l DHCP
Server
IP
Addres
s (List)
42 N*4 IP address of the
M2000 DHCP server
that sends
transmission
configuration
information to the
base station.
In SRAN8.0 and later
versions, a maximum
of eight M2000
DHCP server
addresses can be
configured.
N indicates the
number of DHCP
servers built into the
M2000.
Optional.
If this
parameter
is
configure
d, the base
station
can send
unicast
DHCP
packets to
the DHCP
server
even if the
SeGW
cannot
send any
DHCP
server IP
address to
the base
station.
l DHCPOF
FE
l DHCPA
CK
Transmis
sion
configura
tion
informati
on for the
base
station
Interfa
ce IP
Addres
s
- 4 Carried in the yiaddr
field in DHCP packet
headers
Mandator
y
l DHCPOF
FE
l DHCPA
CK
Interfa
ce IP
Addres
s mask
- 4 Carried in DHCP
option 1
Mandator
y
l DHCPOF
FE
l DHCPA
CK
SingleRAN
Description
Stations
54
Classific
ation
Param
eter
Name
Mapp
ing
Subc
ode
Leng
th
(Byt
es)
Parameter
Description
Mandato
ry or
Optional
DHCP
Packet
Involved
Next-
hop
Gatewa
y IP
Addres
s
- 4 Carried in DHCP
option 3
Mandator
y
l DHCPOF
FE
l DHCPA
CK

All IP addresses or URLs listed in Table 3-9 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, it
cannot obtain any operator-issued certificate.
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.
The base station generates a certificate request file after it obtains a temporary IP address and
CA information. 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. Therefore, the base station uses the default parameters described in Table 3-10 to complete
the certificate application.
Table 3-10 Default parameters used for certificate application
Parameter
Category
Parameter
Name
CMPv2-
related
parameters
Source IP Source IP address used to
apply for the operator-
issued device certificate
This parameter is set to the
interface IP address of the base
station that is obtained through
the DHCP procedure.
SingleRAN
Description
Stations
55
Parameter
Category
Parameter
Name
CA URL
During Site
Deployment
URL of the CA This parameter is set to the URL
of the CA obtained through the
DHCP procedure, 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.
Signature
Algorithm
Signature algorithm for
CMP messages
Parameters
in the
certificate
request file
Request
Type
Type of a certificate
request. The request can
be either a new certificate
request or a certificate
update request. The
default type is new
certificate request.
This parameter is set to NEW.
Certificate
Request File
Format
Format of a certificate
request file
This parameter is set to CRMF.
Renew Key Whether to generate a
new key pair
This parameter is set to YES.
Key Size Length of a key This parameter is set to
KEYSIZE2048.
Common
Name
Common name of the
This parameter is set to the ESN
of the base station that applies for
a certificate.
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.
SingleRAN
Description
Stations
56
Parameter
Category
Parameter
Name
Signature
Algorithm
Signature algorithm for a
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
station. This parameter is
used to generate the DNS
name of the subject
alternative name of a
certificate, so as to verify
the peer's identification in
IKE negotiation.
The value of this parameter
consists of the ESN of the base
station and ".huawei.com."
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 IP address obtained may
not be used finally.

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 M2000 in the trusted domain.
Establishing a Temporary IPSec Tunnel
After the base station obtains the transmission configuration information (including its interface
IP address, the SeGW IP address, and the CA IP address) from the public DHCP server, the base
station obtains digital certificates from the CA and attempts to establish a temporary IPSec tunnel
to the SeGW. For details about the temporary IPSec tunnel establishment, see IPSec Feature
Parameter Description. 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 tries this IKE version. Otherwise,
the base station tries 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 groups. However, during base station deployment by PnP, the base
SingleRAN
Description
Stations
57
station only supports the 48 algorithm groups (see Table 3-11) in the IKEv2 proposal and the
120 algorithm groups (see Table 3-12) in the IKEv1 proposal.
NOTE
The number of algorithm groups in the IKEv2 proposal is calculated 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 groups in the IKEv2 proposal is 48 (4 x 2
x 3 x 2).
The number of algorithm groups in the IKEv1 proposal is calculated in the same way as that in
the IKEv2 proposal.
Table 3-11 Algorithms in the IKEv2 proposal
Encryption
Algorithm
Authentication
Algorithm
Diffie-Hellman
Group
PRF Algorithm
3DES SHA1 DH_GROUP2 HMAC_SHA1
AES128 AES_XCBC_96 DH_GROUP14 AES128_XCBC
AES192 N/A DH_GROUP15 N/A
AES256 N/A N/A N/A

Table 3-12 Algorithms in the IKEv1 proposal
Encryption
Algorithm
Authentication
Algorithm
Diffie-Hellman
Group
Authentication
Method
(Only IKEv1)
DES MD5 DH_GROUP1 PSK
3DES SHA1 DH_GROUP2 RSA-SIG
AES128 N/A DH_GROUP14 DSS-SIG
AES192 N/A DH_GROUP15 N/A
AES256 N/A N/A N/A

To establish a temporary IPSec tunnel, the base station preferentially tries the five algorithm
groups listed in Table 3-12 in sequence. If this fails, the base station tries the other groups until
it establishes an IPSec tunnel. If all the supported algorithm groups 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.
IKEv2 proposal algorithms should be configured in the sequence shown in Table 3-13.
Otherwise, the IKEv2 negotiation may fail. To increase the deployment success rate and shorten
the deployment duration, it is recommended that IKEv2 proposal algorithms in configuration
files of the base station follow the configurations listed in Table 3-13.
SingleRAN
Description
Stations
58
Table 3-13 First five algorithms groups in the IKEv2 proposal
Sequence Encryption
Algorithm
Authenticatio
n Algorithm
Diffie-
Hellman
Group
PRF
Algorithm
(Only IKEv2)
1 AES128 SHA1 DH-Group2 HMAC-SHA1
2 3DES SHA1 DH-Group2 HMAC-SHA1
3 AES256 AES_XCBC_9
6
DH_GROUP15 AES128_XCB
C
4 AES192 SHA1 DH_GROUP14 HMAC_SHA1
5 AES128 SHA1 DH_GROUP14 HMAC_SHA1

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 groups. However, during base station deployment by PnP,
the base station supports only the encryption and authentication algorithm groups listed in Figure
3-24. It first tries the six algorithm groups marked in green. If this fails, it tries the six algorithm
groups marked in gray. Once IKE negotiation is successful using an algorithm group, the base
station applies this algorithm group.
The base station tries IKE version and algorithm groups in the following priority sequence:
1. IKEv2 and algorithm groups marked in green
2. IKEv2 and algorithm groups marked in gray
3. IKEv1 and algorithm groups marked in green
4. IKEv1 and algorithm groups marked in gray
Figure 3-24 Encryption and authentication algorithms in IPSec proposal
SingleRAN
Description
Stations
59
NOTE
During base station deployment by PnP, the base station does not try all supported IPSec and IKE proposal
algorithms (such as the DES algorithm) when establishing an IPSec tunnel. This is because trying all
supported combinations of security parameters may take a long time.
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 M2000, 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 there is consistency between the
parameters and settings.
Configuration Requirements for the Internal DHCP Server
The M2000 DHCP server must be configured with the parameters listed in Table 3-14 as well
as the parameters listed in Table 3-5. These parameters are contained in Option 43 in DHCP
packets.
Table 3-14 Parameters specific to the M2000 DHCP server in IPSec networking scenario 1
Classific
ation
Parameter
Name
Mapping
Subcode
Leng
th
(Byte
s)
Parameter
Descriptio
n
Mand
atory
or
Optio
nal
DHCP
Packet
Involved
SeGW
informati
on
Serving
SecGW IP
20 4 IP address of
the serving
SeGW in
IPSec
networking
scenarios
Mandat
ory
l DHCPO
FFER
l DHCPA
CK
Serving
SecGW Local
Name
32 1 to
32
Local name
of the
serving
SeGW.
It is provided
by the base
station to
authenticate
the serving
SeGW in
IPSec
networking
scenarios
Option
al
SingleRAN
Description
Stations
60
Classific
ation
Parameter
Name
Mapping
Subcode
Leng
th
(Byte
s)
Parameter
Descriptio
n
Mand
atory
or
Optio
nal
DHCP
Packet
Involved
CA
informati
on
CA URL 44 1-128 URL of the
CA from
which the
base station
obtains an
operator-
issued
device
certificate in
IPSec
networking
scenarios
This URL
must be
reachable in
the untrusted
domain.
Mandat
ory
DHCPOFFE
R
DHCPACK
CA Name 38 1-127 CA name

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 M2000
DHCP server IP address. The base station can also interwork with the public DHCP server to
obtain a maximum of eight M2000 DHCP server IP addresses.
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-15 to obtain formal transmission
configuration information from the M2000 DHCP server, depending on whether the logical IP
address used for accessing the untrusted domain and any M2000 DHCP server IP address are
available.
SingleRAN
Description
Stations
61
Table 3-15 Obtaining formal transmission configuration information from the M2000 DHCP
server
If... Then... Configuration
Requirements for NEs
The base station has obtained
the interface IP address for
accessing the untrusted
domain, and has used the
MODE-CONFIG mode
during IKE negotiation to
obtain the logical IP address
for accessing the trusted
domain. In addition, the base
station has obtained one or
more M2000 DHCP server IP
addresses, using either the
DHCP procedure or the
MODE-CONFIG mode
during IKE negotiation.
l The base station uses the
logical IP address for
accessing the trusted
domain as the source IP
address, and uses any
M2000 DHCP server IP
address as the destination
IP address. The base
station then unicasts
DHCP packets to each
M2000 DHCP server.
Only the M2000 DHCP
server that has the correct
BS ID sends
configuration
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.
See Table 3-16.
SingleRAN
Description
Stations
62
The base station has obtained
the interface IP address for
domain, but not the logical IP
address for accessing the
trusted domain. In addition,
the base station has obtained
one or more M2000 DHCP
server IP addresses.
l The base station uses the
interface IP address for
domain as the source IP
address, and uses any
M2000 DHCP server IP
address as the destination
IP address. The base
station then unicasts
DHCP packets to each
M2000 DHCP server.
Only the M2000 DHCP
server that has the correct
BS ID sends
configuration
information to the base
station.
l The base station
an ACL rule that allows
DHCP packets to reach
the base station. In the
ACL rule, the source IP
address is the interface IP
address and the
destination IP address is
an M2000 DHCP server
IP address. If there are
multiple M2000 DHCP
servers, one ACL rule is
generated for each
connected M2000 DHCP
server.
See Table 3-17.
SingleRAN
Description
Stations
63
The base station has not
obtained the logical IP
address for accessing the
trusted domain or any M2000
DHCP server IP address.
l The base station uses
0.0.0.0 as the source IP
address and
255.255.255.255 as the
destination IP address to
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
DHCP packets to reach
the base station. In the
ACL rule, the source
UDP port number is 68
and the destination UDP
port number is 67.
See Table 3-18.

Table 3-16 Configuration requirements for network equipment(1)
NE Requirement
Public DHCP server Is configured with one to eight M2000 DHCP
server IP addresses only if the SeGW is not
configured with any M2000 DHCP server IP
address.
For detailed configurations, see Table 3-9.
SingleRAN
Description
Stations
64
NE Requirement
SeGW l Supports the MODE-CONFIG mode so
that the SeGW sends a temporary logical
IP address and an M2000 DHCP server IP
address to the base station. Alternatively,
the SeGW sends a temporary logical IP
address and the public DHCP server sends
an M2000 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 M2000 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 M2000 DHCP servers
must be on the network segment defined
by this ACL rule.
All NEs between the base station and the
M2000 DHCP server
l Are configured with the firewall policy or
the packet filtering policy so that they
allow the transmission of packets with 67
or 68 as the source and destination UDP
port number.
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.
M2000 DHCP server l Is configured with a route whose
destination IP address is the logical IP

SingleRAN
Description
Stations
65
NE Requirement
Public DHCP server Is configured with one to eight M2000 DHCP
For detailed configurations, see Table 3-9.
M2000 DHCP server
port number.
destination IP address is the temporary
logical IP address for accessing the trusted
domain or network segment of the
temporary logical IP address so that
related packets can be routed to the
SeGW.
destination IP address is the interface IP
address of the base station or the IP
address of the network segment.
M2000 DHCP server Is configured with a route whose destination
IP address is the interface IP address of the
base station.

NE Requirement
Public DHCP server For detailed configurations, see Table 5-7, 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.
M2000 DHCP server
port number.
the DHCP relay agent on the SeGW.
SingleRAN
Description
Stations
66
NE Requirement
M2000 DHCP server l Are configured with a route whose
the DHCP relay agent on the SeGW.

Compared with non-IPSec networking scenarios, IPSec networking scenario 1 has the following
differences in the procedure for obtaining transmission configuration information from the
M2000 DHCP server:
l The M2000 DHCP server can be deployed only on the M2000, not the base station
controller.
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.
l IPSec secures OMCH data. Therefore, among the configuration information sent by the
M2000 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.
Establishing a Formal IPSec Tunnel
The SeGW IP address obtained from the M2000 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 an IPSec
tunnel to the SeGW. The SeGW is identified by the SeGW IP address in the configuration
information from the M2000 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 and SeGW IP address delivered by the M2000
DHCP server for IKE SA and IPSec SA 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 security parameters 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 section "Establishing a Temporary IPSec
Tunnel" to try other security parameters.
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 M2000 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 M2000.
SingleRAN
Description
Stations
67
Configuration Requirements for Network Equipment
Table 3-19 lists the configuration requirements for NEs in IPSec networking scenario 1.
Table 3-19 Configuration requirements for NEs in IPSec networking scenario 1
NE Requirement
L2 NEs l Allow the transmission of DHCP
l Are configured with correct VLAN
information.
Next-hop L3 NE of the base station l Is configured as the DHCP server or
enabled with the DHCP relay 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 NEs l (NEs in the untrusted domain): Are
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): Are
configured with three routes whose
destination addresses are the OM IP
address of the base station, M2000 IP
address, and FTP server IP address.
M2000 Is configured with a route whose destination
station.
IP address is that of the DHCP relay agent
when the SeGW serves as the DHCP relay
agent. If the SeGW does not serve as the
DHCP relay agent, the M2000 DHCP server
is configured with a route whose destination
IP address is the temporary interface IP
SingleRAN
Description
Stations
68
NE Requirement
FTP server l Is configured with a route whose
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.
SeGW l Allows DHCP packets to be exchanged
between the base station and the M2000.
l Allows packets to be exchanged between
the base station and the M2000 over an
OMCH and between the base station and
the FTP server.
l Is enabled with the DHCP relay agent
function if the SeGW complies with RFC
3456.
l Is configured with security parameters
listed in Configuration Requirements
for the Public DHCP Server.
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 ACL rule in Any to
Any or Any to OM IP mode.
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 Is configured with the following:
l An IP address that can be accessed by NEs
in the untrusted domain
l Huawei-issued CA root certificates

Scenario 2
SingleRAN
Description
Stations
69
Figure 3-25 shows IPSec networking scenario 2, in which IPSec secures all packets except
DHCP packets.
Figure 3-25 IPsec networking scenario 2
l An M2000 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 M2000 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 M2000 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 base station deployment, the CA can be accessed
by NEs or using an IP address in the untrusted domain.
l After the base station starts, it must apply to the CA for operator-issued digital certificates
before connecting to the SeGW.
In IPSec networking scenario 2, the base station must obtain the base station IP address and CA
IP address from the M2000 DHCP server, and then obtain digital certificates from the CA.
2.
SingleRAN
Description
Stations
70
2. The base station obtains required configuration information from the M2000 DHCP server.
The information includes the interface IP address and the OM IP address of the base station,
the CA IP address, and the SeGW address.
NOTE
DHCP packets from the base station are forwarded by the DHCP relay agent to the DHCP server on
the M2000.
During a DHCP procedure, a DHCP response packet sent by the M2000 contains the target RAT for
the base station. Upon detecting the inconsistency between the current and target RATs, the base
station changes its current RAT for consistency and then restarts. Afterwards, the base station
reinitiates a DHCP procedure.
3. By using the configuration information obtained from the M2000 DHCP server, the base
station applies to the CA for operator-issued digital certificates. For details about the
certificate application procedure, see Obtaining an Operator-Issued Device
Certificate. The only difference is that the CA information in this scenario is obtained from
the M2000 DHCP server, not the public DHCP server.
4. By using the configuration information obtained from the M2000 DHCP server, the base
station establishes a formal IPSec tunnel to the SeGW.
5. With protection from the formal IPSec tunnel, the base station waits for the SSL-based or
plaintext-based OMCH establishment request from the M2000 or BSC and finally
establishes an OMCH to the M2000 or BSC.
The M2000 DHCP server must be configured with the parameters listed in Table 3-20 as well
as the parameters listed in Table 3-5. These parameters are contained in subcodes of Option 43
in DHCP packets.
SingleRAN
Description
Stations
71
Classific
ation
Paramete
r Name
Mapping
Subcode
Length
(Bytes)
Paramete
r
Descripti
on
Mandato
ry or
Optional
DHCP
Packet
Involved
SeGW
informatio
n
Serving
SecGW IP
20 4 IP address
of the
SeGW in
IPSec
networkin
g scenarios
Mandator
y
l DHCP
OFFE
R
l DHCP
ACK
Serving
SecGW
Local
Name
32 1 to 32 Local
name of
the serving
SeGW. It
is provided
by the base
station to
authentica
te the
serving
SeGW in
IPSec
networkin
g scenarios
CA
informatio
n
CA URL 44 1 to 128 URL from
which the
base
station
obtains
operator-
issued
digital
certificate
s.
This URL
must be
accessible
to NEs in
the
untrusted
domain.
Mandator
y
l DHCP
OFFE
R
l DHCP
ACK
CA Name 38 1 to 127 Name of
the CA

SingleRAN
Description
Stations
72
For details, see section Obtaining an Operator-Issued Device Certificate.
Table 3-21 lists the configuration requirements for network equipment in IPSec networking
scenario 2.
Table 3-21 Configuration requirements for network equipment in IPSec networking scenario 2
information.
Next-hop gateway of the base station l Is enabled with the DHCP relay agent
function.
l Is configured with correct DHCP server
IP addresses.
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.
configured with a route whose destination
station and routes whose destination IP
addresses are that of the M2000 and of the
FTP server.
station.
IP address is the DHCP relay agent IP
address.
SingleRAN
Description
Stations
73
SeGW l Allows packets to be exchanged between
the base station and the M2000 over an
OMCH and between the base station and
the FTP server.
l Is configured with security parameters
listed in Table 3-11, Table 3-12, and
Figure 3-24.
l Is configured with an ACL rule in Any to
Any or Any to OM IP mode.
l Is configured with operator-issued CA
certificates and its own certificates.
l An IP address that can be accessed by NEs
in the untrusted domain

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.
Figure 3-27 IPSec networking scenario 3
SingleRAN
Description
Stations
74
l An M2000 DHCP server is deployed. The base station obtains the OMCH configuration
data and CA configuration data from the M2000 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 because 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).
3.
2. The base station obtains the OMCH configuration data and CA configuration data
(optional) from the M2000 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.
3. The base station applies to the CA for operator-issued digital certificates if digital
certificates are used for authentication. After the base station obtains the configuration
information and the configuration takes effect, the base station restarts and then establishes
an IPSec tunnel to the SeGW to secure services and signaling.
SingleRAN
Description
Stations
75
NOTE
During a DHCP procedure, a DHCP response packet sent by the M2000 contains the target RAT for
the base station. Upon detecting the inconsistency between the current and target RATs, the base
station changes its current RAT for consistency and then restarts. Afterwards, the base station
reinitiates a DHCP procedure.
4. Based on the configuration information obtained from the M2000 DHCP server, the base
station establishes an OMCH to the M2000 or BSC
If the base station uses digital certificates for authentication, the M2000 DHCP server must be
configured with the parameters listed in both Table 3-22 and Table 3-5. These parameters are
contained in subcodes of Option 43 in DHCP packets.
SingleRAN
Description
Stations
76
Classific
ation
Paramete
r Name
Subcode Length
(Bytes)
Paramete
r
Descripti
on
Mandato
ry or
Optional
DHCP
Packet
Involved
CA
informatio
n
CA URL 44 1 to 128 URL of the
CA from
which the
base
station
obtains an
operator-
issued
device
certificate.
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
M2000
DHCP
server
must be
accessible.
Mandator
y
l DHCP
OFFE
R
l DHCP
ACK
CA Name 38 1 to 127 CA name

Table 3-23 lists the configuration requirements for network equipment in IPSec networking
scenario 3.
SingleRAN
Description
Stations
77
Table 3-23 Configuration requirements for network equipment in IPSec networking scenario 3
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 M2000. If an NAT server is
deployed, the IP address of the M2000
must be that converted by the NAT server.
destination IP address is the DHCP server
IP address.
address of the base station if the OM IP
address is not the same as the interface IP
destination IP address is the CA IP
address.
L3 devices l (NEs in the untrusted domain): Are
IP address is the IP address of the base
station, a route whose destination IP
address is the OM IP address of the base
station, a route whose destination IP
address is the M2000, a route whose
destination IP address is the FTP server,
and a route whose destination IP address
is the CA.
station and routes whose destination IP
addresses are the M2000 IP address and
FTP server IP address.
station.
IP address is that of the DHCP relay agent.
SingleRAN
Description
Stations
78
l An IP address that can be accessed by
devices in the untrusted domain

3.4 Automatic OMCH Establishment by the Separate-MPT
Multimode Base Station
3.4.1 Networking
The separate-MPT multimode base station is similar to many single-mode base stations that are
interconnected using the transmission board. The interconnection can either be based on the
panel or the backplane. 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 and the other for connecting to the transport
network.
Figure 3-29 OMCH networking for the separate-MPT multimode base station that uses panel-
based interconnection
Figure 3-30 shows the OMCH networking for the separate-MPT multimode base station that
uses backplane-based interconnection.
SingleRAN
Description
Stations
79
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
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
the Single-mode Base Station and Co-MPT Multimode Base Station". The upper-level
base station then obtains software and configuration files from the M2000 or BSC over the
established OMCH. The upper-level base station activates software and configuration files
and then enters the working state.
SingleRAN
Description
Stations
80
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 M2000 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.
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-24. For details about the configuration requirements for the DHCP server
of each single-mode base station, see chapter "3.3 Automatic OMCH Establishment by the
Single-mode Base Station and Co-MPT Multimode Base Station".
SingleRAN
Description
Stations
81
Table 3-24 Setting of the OM Bearing Board parameter on DHCP servers of lower-level base
stations
Parameter
Name
Subcode Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
OM Bearing
Board
250 1 Value:
l 0: An
OMCH is
establish
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.
Mandatory l DHCPO
FFER
l DHCPA
CK
SingleRAN
Description
Stations
82
Parameter
Name
Subcode Length
(Bytes)
Parameter
Descriptio
n
Mandatory
or Optional
DHCP
Packet
Involved
CERTDEPL
OY
52 3 Slot No.,
Subrack No.,
and Cabinet
No. of the
board on
which the
certificate
for SSL
authenticatio
n is
deployed.
This
parameter is
used for
certificate
sharing.
Optional
Used only
when
certificate
sharing is
applied.
DHCPOFFE
R
DHCPACK

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 has similar configuration requirements
for network equipment to a single-mode base station. For details about these requirements, see
chapter "3.3 Automatic OMCH Establishment by the Single-mode Base Station 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-25.
SingleRAN
Description
Stations
83
Table 3-25 Configuration requirements for network equipment
Upper-level base station l Is enabled with the DHCP relay agent
function.
l Is configured with IP addresses of the
DHCP servers of lower-level base
stations.
l Is configured with routes to the DHCP
servers of lower-level base stations.
l Is configured with routes used for serving
lower-level base stations, including
downlink routes to the IP addresses of
lower-level base stations and uplink
routes 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 must be configured. If the
lower-level base station is the eNodeB,
uplink routes to the M2000, mobility
management entity (MME), and serving
gateway (S-GW) must be configured.
l Is configured with the IP address of the
transmission interface (used for panel-
based interconnection) provided by the
upper-level base station. It is
recommended that only one such IP
address be configured. If many such IP
addresses are configured, the source IP
address in DHCP packets forwarded by
the upper-level base station is the first
configured IP address. As a result, the
packet forwarding may fail due to
differences in the configuration sequence.
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.
SingleRAN
Description
Stations
84
All devices on the transport network for the
upper-level base station
l Are configured with routes to the DHCP
servers of lower-level base stations.
l Are configured with routes to the IP
address of the DHCP relay agent.
l Are configured with routes to the OM IP
address of the upper-level base station or
either of the following routes:
The routes to the IP address of the
transmission interface (used for panel-
based interconnection) provided by the
upper-level base station when the
separate-MPT multimode base station
uses panel-based interconnection. The
routes to the network segment of the next-
hop gateway of the upper-level base
station when the separate-MPT
multimode base station uses backplane-
based interconnection
DHCP servers of lower-level base stations Are configured with routes to the upper-level
base station
Lower-level base stations Are configured with routes to the OM IP
address of the upper-level base station. If the
separate-MPT multimode base station uses
panel-based interconnection, lower-level
base stations can also be configured with
routes to the IP address of either of the
transmission interfaces (used for panel-based
connection or used for connecting to the
transport network) provided by the upper-
level base station.

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-26 through Table 3-28 summarizes the configuration requirements.
Table 3-26 lists the configuration requirements for the configuration files of the base station in
all scenarios.
SingleRAN
Description
Stations
85
Table 3-26 Configuration requirements for configuration files of the base station in all scenarios
SN MO Requirement
1 OMCH 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 M2000.The
IP addresses of the
M2000 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
M2000 must be deployed
on the same equipment or
network segment. The
PEERIP parameter must
be set to the IP address of
the M2000.The IP
addresses of the M2000
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
SingleRAN
Description
Stations
86
SN MO Requirement
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.
2 VLANMAP The VLANMODE parameter
specifies the VLAN mode. It
is recommended that upper-
and lower-level base stations
use the SingleVLAN mode
instead of the VLANGroup
mode to configure VLANs. If
base stations are cascaded
and the upper-level base
station uses the VLANGroup
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.
SingleRAN
Description
Stations
87
SN MO Requirement
3 BFDSESSION If the CATLOG parameter is
set to RELIABILITY
(Reliability) for a BFD
session, the BFD session is
bound to a handover route.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, subrack topology, and
slot number is used as the BS
ID, the DID parameter in the
NE MO must be specified.
5 IPRT 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 that the smaller the
number of the route priority,
the higher the priority.

Table 3-27 lists the specific configuration requirements for the configuration files of the base
station in IPSec networking scenarios.
SingleRAN
Description
Stations
88
Table 3-27 Configuration requirements for the configuration files of the base station in IPSec
networking scenarios
SN NE MO Requirement
1 Base station ACLRULE 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
M2000, the IP
address of the
M2000 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 set to
PERMIT
(Permit). If the
SingleRAN
Description
Stations
89
ACTION
parameter is set to
DENY(Deny),
do not use the
O&M IP address
to receive and
transmit non-
O&M data.
Otherwise, an
error may occur
in DHCP
parameters.
If neither
requirement is
met, errors may
occur when
parameters
configured on the
SeGW are
exported from the
CME, leading to
failures in base
station
deployment by
PnP.
2 Base station IKEPROPOSAL
IPSECPROPOSAL
Parameter settings of
the
IKEPROPOSAL
MO must be
consistent with those
described in Table
3-11 or Table 3-12.
Parameter settings of
the
IPSECPROPOSAL
MO must be
consistent with those
described in Figure
3-24.
If the base station
uses the IPSec tunnel
pair topology, only
the active tunnel
supports base station
deployment by PnP.
SingleRAN
Description
Stations
90
3 Base station BFDSESSION If the base station
uses the IPSec tunnel
pair topology, the
BFD session cannot
be bound to a route
during the BFD
session
configuration.
4 L2 devices ETHTRK Ethernet link
aggregation group
must not be manually
configured on the
peer L2 devices of
the base station.
5 CA CA The CA must be
accessible to devices
in the untrusted
domain.
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.

Table 3-28 lists the configuration requirements for a DHCP server.
SingleRAN
Description
Stations
91
Table 3-28 Configuration requirements for a DHCP server
SN Requirement
1 The public DHCP server can be configured
with a maximum of eight M2000 DHCP
If base stations of SRAN7.0, SRAN8.0, and
later versions co-exist in a network,
configuring eight M2000 DHCP server IP
addresses on the public DHCP server causes
a deployment failure because SRAN7.0 base
stations support only two M2000 DHCP
server IP addresses. In this scenario,
configure two M2000 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).

NOTE
When you configure or modify the information of the M2000 DHCP server on the M2000, the destination
IP address of the OMCH route and the IP address of the destination network segment must be correct.
3.5.2 Impact of M2000 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 M2000, including the DHCP service, FTP
service, and OMCH management service.
The preceding three services can be deployed on different M2000s 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-29 describes the impact of M2000 deployment on automatic OMCH establishment.
SingleRAN
Description
Stations
92
Table 3-29 Impact of M2000 deployment on automatic OMCH establishment
M2000
Deployme
nt
M2000
Deployme
nt
Descriptio
n
M2000
Serving as
the DHCP
Server
M2000
Serving as
the OMC
Requireme
nt for the
Base
Station
Deployme
nt
Impact on
the
Network
Configurat
ion
Single-
server
system
All
application
services are
deployed on
the same
server and
the server
has only one
IP address.
Single server Single server For details,
see section
"3.3
Automatic
OMCH
Establishme
nt by the
Single-
mode Base
Station and
Co-MPT
Multimode
Base
Station "
and section
"3.4
Automatic
OMCH
Establishme
nt by the
Separate-
MPT
Multimode
Base
Station".
For details,
see section
"3.3
Automatic
OMCH
Establishme
nt by the
Single-
mode Base
Station and
Co-MPT
Multimode
Base
Station" and
section "3.4
Automatic
OMCH
Establishme
nt by the
Separate-
MPT
Multimode
Base
Station".
SingleRAN
Description
Stations
93
M2000
Deployme
nt
M2000
Deployme
nt
Descriptio
n
M2000
Serving as
the DHCP
Server
M2000
Serving as
the OMC
Requireme
nt for the
Base
Station
Deployme
nt
Impact on
the
Network
Configurat
ion
HA system l The
active
and
standby
nodes
have the
same
function
and data
on the
two
nodes are
synchron
ized.
l The
active
and
standby
nodes use
the same
IP
address.
Active or
standby node
Active or
standby node
For details,
see section
"3.3
Automatic
OMCH
Establishme
nt by the
Single-
mode Base
Station and
Co-MPT
Multimode
Base
Station" and
section "3.4
Automatic
OMCH
Establishme
nt by the
Separate-
MPT
Multimode
Base
Station".
For details,
see section
"3.3
Automatic
OMCH
Establishme
nt by the
Single-
mode Base
Station and
Co-MPT
Multimode
Base
Station" and
section "3.4
Automatic
OMCH
Establishme
nt by the
Separate-
MPT
Multimode
Base
Station".
SingleRAN
Description
Stations
94
M2000
Deployme
nt
M2000
Deployme
nt
Descriptio
n
M2000
Serving as
the DHCP
Server
M2000
Serving as
the OMC
Requireme
nt for the
Base
Station
Deployme
nt
Impact on
the
Network
Configurat
ion
SLS system l The slave
node
performs
the
network
managem
ent
function
only.
l The IP
address
of the
master
node is
different
from that
of the
slave
node, and
the IP
addresses
of the two
nodes are
in the
same
subnet.
Master node Master or
slave node
l The
PeerIP
paramete
r for the
OMCH
must be
set to the
IP
address
of the
M2000
that
manages
the base
station.
l If the
OMCH is
bound to
a route,
the route
must be
to the
network
segment
of the
M2000.
In IPSec
networking
scenarios,
the IP
address of
the M2000
DHCP server
configured
on the public
DHCP server
must be the
IP address of
the master
node.
The SeGW
must be
configured
with ACL
rules which
allow
packets of
the M2000
DHCP server
to pass.
The SeGW
must be
configured
with ACL
rules which
allow OM
data to pass.
SingleRAN
Description
Stations
95
M2000
Deployme
nt
M2000
Deployme
nt
Descriptio
n
M2000
Serving as
the DHCP
Server
M2000
Serving as
the OMC
Requireme
nt for the
Base
Station
Deployme
nt
Impact on
the
Network
Configurat
ion
Remote HA
system
l The
active
and
standby
nodes are
deployed
on two
locations.
l The IP
address
of the
active
node is
different
from that
of the
standby
node, and
the IP
addresses
of the two
nodes
may not
be in the
same
subnet.
Active or
standby node
The M2000
must serve as
the DHCP
server.
l The base
station
must be
configure
d with
routes to
the two IP
address
or two
network
segments
.
l The
PeerIP
paramet
er for the
OMCH
of the
base
station
must be
set to the
IP
address
of the
M2000
that
serves as
the
DHCP
server.
l In IPSec
networki
ng
scenarios
, the IP
address
of the
M2000
DHCP
server
configure
d on the
public
DHCP
server
must be
the IP
address
of the
M2000
that
serves as
the
DHCP
server. If
the
operator
expects
to use
either of
the active
and
standby
nodes as
the
DHCP
server,
the public
DHCP
server
must be
configure
d with the
SingleRAN
Description
Stations
96
M2000
Deployme
nt
M2000
Deployme
nt
Descriptio
n
M2000
Serving as
the DHCP
Server
M2000
Serving as
the OMC
Requireme
nt for the
Base
Station
Deployme
nt
Impact on
the
Network
Configurat
ion
IP
addresses
of the
active
and
standby
nodes.
l The
SeGW
must be
configure
d with
ACL
rules
which
allow
DHCP
packets
to pass. If
the
operator
expects
to use
either of
the active
and
standby
nodes as
the
DHCP
server,
the
SeGW
must be
configure
d with
ACL
rules
which
allow
packets
of active
and
SingleRAN
Description
Stations
97
M2000
Deployme
nt
M2000
Deployme
nt
Descriptio
n
M2000
Serving as
the DHCP
Server
M2000
Serving as
the OMC
Requireme
nt for the
Base
Station
Deployme
nt
Impact on
the
Network
Configurat
ion
standby
nodes to
pass.
l The
SeGW
must be
configure
d with
ACL
rules
which
allow
OM data
to pass. If
the
operator
expects
to use
either of
the active
and
standby
nodes as
the OMC,
the
SeGW
must be
configure
d with
ACL
rules
which
allow
packets
of active
and
standby
nodes to
pass.
SingleRAN
Description
Stations
98
M2000
Deployme
nt
M2000
Deployme
nt
Descriptio
n
M2000
Serving as
the DHCP
Server
M2000
Serving as
the OMC
Requireme
nt for the
Base
Station
Deployme
nt
Impact on
the
Network
Configurat
ion
Emergency
system
The
emergency
system
performs
basic
functions
only and
does not
support PnP
or DHCP.
Not
supported
Not
supported
Not involved Not involved

For example:
l When the M2000 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 M2000 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.
l 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.
OMCH networking requires that the NAT server be deployed only on the M2000 side, but not
the base station or BSC side. Figure 3-32 shows the OMCH networking in which the NAT server
is deployed on the M2000 side.
Figure 3-32 OMCH networking when the NAT server is deployed on the M2000
The IP address and port number of the M2000 can be converted by the NAT. Therefore, the
route whose destination IP address is the M2000 IP address on the base station side must use an
SingleRAN
Description
Stations
99
M2000 IP address visible on the base station side as the destination address. As shown in Figure
3-32, the local IP address configured for the M2000 is 10.0.0.1. After the conversion performed
by the NAT server, however, the source IP address in TCP packets received by the base station
is 20.1.1.1 instead of 10.0.0.1. Therefore, the route whose destination IP address is 20.1.1.1
instead of 10.0.0.1 must be configured on the base station side.
SingleRAN
Description
Stations
100
4 ATM-based Automatic OMCH
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 and default PVC. In this way, a remote OM channel can be set up
between the NodeB and the M2000 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 M2000 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
Description
4 ATM-based Automatic OMCH Establishment for Base
Stations
101
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
Description
Stations
102
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
Description
Stations
103
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, For details about data to prepare before a base station starts the automatic
operation and maintenance channel (OMCH) establishment procedure, see 3900 Series Base
Station Initial Configuration Guide. For details about software and configuration file
downloading, activation, and commissioning on a base station after the automatic OMCH
establishment procedure is complete, see 3900 Series Base Station Commissioning Guide.
The following describes how to configure BOOTP in an ATM network.
Configuring BOOTP on the RNC Side in 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(BSC6910,BSC6900): This parameter specifies the VPI value of the PVC. It
is set to 1.
l CARRYVCI(BSC6910,BSC6900): This parameter specifies the VCI value of the PVC. It
is set to 33.
l IPADDR(BSC6910,BSC6900): This parameter specifies the local IP address.
l PEERIPADDR(BSC6910,BSC6900): 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.
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
Description
Stations
104
5 TDM-based Automatic OMCH
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
Description
5 TDM-based Automatic OMCH Establishment for Base
Stations
105
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
Description
Stations
106
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
Stations
107
6 Parameters
Table 6-1 UMTS: Parameter description
Parameter ID NE MML
Command
Feature ID Feature Name Description
DHCPRLYID BSC6910 ADD
DHCPRLY
MOD
DHCPRLY
RMV
DHCPRLY
None None Meaning:DHCP
Relay ID.
GUI Value
Range:0~2047
Unit:None
Actual Value
Range:0~2047
Default
Value:None
DHCPRLYID BSC6900 ADD
DHCPRLY
MOD
DHCPRLY
RMV
DHCPRLY
None None Meaning:DHCP
Relay ID.
GUI Value
Range:0~2047
Unit:None
Actual Value
Range:0~2047
Default
Value:None
SingleRAN
Description 6 Parameters
108
Parameter ID NE MML
Command
DHCPRLYGA
TEWAYIP
BSC6900 ADD
DHCPRLY
MOD
DHCPRLY
None None Meaning:This
parameter
indicates the IP
Address of
DHCP Relay
Gateway.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
DHCPRLYGA
TEWAYIP
BSC6910 ADD
DHCPRLY
MOD
DHCPRLY
None None Meaning:This
parameter
indicates the IP
Address of
DHCP Relay
Gateway.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
SingleRAN
109
Parameter ID NE MML
Command
DHCPSRVISE
MSIP
BSC6900 ADD
DHCPRLY
MOD
DHCPRLY
WRFD-050410 IP Transmission
Introduction on
Iur Interface
Meaning:Wheth
er the IP address
of the DHCP
server is the
same as the IP
address of the
EMS.
GUI Value
Range:No
(DHCP server
IP address needs
to be specified),
Yes(Same as the
EMS IP address)
Unit:None
Actual Value
Range:Yes, No
Default
Value:Yes
(Same as the
EMS IP address)
DHCPSRVISE
MSIP
BSC6910 ADD
DHCPRLY
MOD
DHCPRLY
WRFD-150244 Iu/Iur IP
Transmission
Based on
Dynamic Load
Balance
Meaning:Wheth
er the IP address
of the DHCP
server is the
same as the IP
address of the
EMS.
GUI Value
Range:No
(DHCP server
IP address needs
to be specified),
Yes(Same as the
EMS IP address)
Unit:None
Actual Value
Range:Yes, No
Default
Value:Yes
(Same as the
EMS IP address)
SingleRAN
110
Parameter ID NE MML
Command
RSVDSW1 BSC6900 SET
TRANSRSVPA
RA
None None Meaning:Switch
1 reserved for
future use.
Disuse
statement: This
parameter is
used
temporarily in
patch versions
and will be
replaced with a
new parameter
in later versions.
The new
parameter ID
reflects the
parameter
function.
Therefore, this
parameter is not
recommended
for the
configuration
interface.
GUI Value
Range:TS0
(Time_slot_0),
TS1
(Time_slot_1),
TS2
(Time_slot_2),
TS3
(Time_slot_3),
TS4
(Time_slot_4),
TS5
(Time_slot_5),
TS6
(Time_slot_6),
TS7
(Time_slot_7),
TS8
(Time_slot_8),
TS9
(Time_slot_9),
TS10
(Time_slot_10),
SingleRAN
111
Parameter ID NE MML
Command
TS11
(Time_slot_11),
TS12
(Time_slot_12),
TS13
(Time_slot_13),
TS14
(Time_slot_14),
TS15
(Time_slot_15),
TS16
(Time_slot_16),
TS17
(Time_slot_17),
TS18
(Time_slot_18),
TS19
(Time_slot_19),
TS20
(Time_slot_20),
TS21
(Time_slot_21),
TS22
(Time_slot_22),
TS23
(Time_slot_23),
TS24
(Time_slot_24),
TS25
(Time_slot_25),
TS26
(Time_slot_26),
TS27
(Time_slot_27),
TS28
(Time_slot_28),
TS29
(Time_slot_29),
TS30
(Time_slot_30),
TS31
(Time_slot_31)
Unit:None
Actual Value
Range:TS0,
TS1, TS2, TS3,
TS4, TS5, TS6,
SingleRAN
112
Parameter ID NE MML
Command
TS7, TS8, TS9,
TS10, TS11,
TS12, TS13,
TS14, TS15,
TS16, TS17,
TS18, TS19,
TS20, TS21,
TS22, TS23,
TS24, TS25,
TS26, TS27,
TS28, TS29,
TS30, TS31
Default
Value:TS0-1&T
S1-1&TS2-1&T
S3-1&TS4-1&T
S5-1&TS6-1&T
S7-1&TS8-1&T
S9-1&TS10-1&
TS11-1&TS12-
1&TS13-1&TS
14-1&TS15-1&
TS16-1&TS17-
1&TS18-1&TS
19-1&TS20-1&
TS21-1&TS22-
1&TS23-1&TS
24-1&TS25-1&
TS26-1&TS27-
1&TS28-1&TS
29-1&TS30-1&
TS31-1
SingleRAN
113
Parameter ID NE MML
Command
RSVDSW1 BSC6910 SET
TRANSRSVPA
RA
None None Meaning:Switch
1 reserved for
future use.
Disuse
statement: This
parameter is
used
temporarily in
patch versions
and will be
replaced with a
new parameter
in later versions.
The new
parameter ID
reflects the
parameter
function.
Therefore, this
parameter is not
recommended
for the
configuration
interface.
GUI Value
Range:TS0
(Time_slot_0),
TS1
(Time_slot_1),
TS2
(Time_slot_2),
TS3
(Time_slot_3),
TS4
(Time_slot_4),
TS5
(Time_slot_5),
TS6
(Time_slot_6),
TS7
(Time_slot_7),
TS8
(Time_slot_8),
TS9
(Time_slot_9),
TS10
(Time_slot_10),
SingleRAN
114
Parameter ID NE MML
Command
TS11
(Time_slot_11),
TS12
(Time_slot_12),
TS13
(Time_slot_13),
TS14
(Time_slot_14),
TS15
(Time_slot_15),
TS16
(Time_slot_16),
TS17
(Time_slot_17),
TS18
(Time_slot_18),
TS19
(Time_slot_19),
TS20
(Time_slot_20),
TS21
(Time_slot_21),
TS22
(Time_slot_22),
TS23
(Time_slot_23),
TS24
(Time_slot_24),
TS25
(Time_slot_25),
TS26
(Time_slot_26),
TS27
(Time_slot_27),
TS28
(Time_slot_28),
TS29
(Time_slot_29),
TS30
(Time_slot_30),
TS31
(Time_slot_31)
Unit:None
Actual Value
Range:TS0,
TS1, TS2, TS3,
TS4, TS5, TS6,
SingleRAN
115
Parameter ID NE MML
Command
TS7, TS8, TS9,
TS10, TS11,
TS12, TS13,
TS14, TS15,
TS16, TS17,
TS18, TS19,
TS20, TS21,
TS22, TS23,
TS24, TS25,
TS26, TS27,
TS28, TS29,
TS30, TS31
Default
Value:TS0-1&T
S1-1&TS2-1&T
S3-1&TS4-1&T
S5-1&TS6-1&T
S7-1&TS8-1&T
S9-1&TS10-1&
TS11-1&TS12-
1&TS13-1&TS
14-1&TS15-1&
TS16-1&TS17-
1&TS18-1&TS
19-1&TS20-1&
TS21-1&TS22-
1&TS23-1&TS
24-1&TS25-1&
TS26-1&TS27-
1&TS28-1&TS
29-1&TS30-1&
TS31-1
SingleRAN
116
Parameter ID NE MML
Command
ES BTS3900 SET
DHCPRELAYS
WITCH
LST
DHCPRELAYS
WITCH
MRFD-221501
WRFD-031101
MRFD-231501
LBFD-0030010
2 /
TDLBFD-0030
0102
LBFD-0030010
3 /
TDLBFD-0030
0103
MRFD-211501
IP-Based Multi-
mode Co-
Transmission on
BS side(NodeB)
NodeB Self-
discovery Based
on IP Mode
IP-Based Multi-
mode Co-
Transmission on
BS side
(eNodeB)
Chain Topology
Tree Topology
IP-Based Multi-
mode Co-
Transmission on
BS side(GBTS)
Meaning:Indi-
cates whether to
enable the
DHCP relay
switch.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:DISABL
E(Disable)
SWITCH BTS3900 SET DHCPSW
LST DHCPSW
WRFD-031101
LOFD-002004 /
TDLOFD-0020
04
GBFD-118601
GBFD-118611
NodeB Self-
discovery Based
on IP Mode
Self-
configuration
Abis over IP
Abis IP over E1/
T1
Meaning:Indi-
cates whether to
enable detection
of automatic
establishment of
the remote
maintenance
channel.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:ENABLE
(Enable)
SingleRAN
117
Parameter ID NE MML
Command
VLANSCANS
W
BTS3900 SET DHCPSW
LST DHCPSW
None None Meaning:Indi-
cates whether to
enable VLAN
scanning for the
base station.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:DISABL
E(Disable)
FLAG BTS3900 ADD OMCH
DSP OMCH
MOD OMCH
RMV OMCH
LST OMCH
WRFD-050404
LBFD-004002 /
TDLBFD-0040
02
LOFD-003005
GBFD-118601
GBFD-118611
ATM/IP Dual
Stack Node B
Centralized
M2000
Management
OM Channel
Backup
Abis over IP
Abis IP over E1/
T1
Meaning:Indi-
cates the master/
slave flag of the
remote
maintenance
channel.
GUI Value
Range:MASTE
R(Master),
SLAVE(Slave)
Unit:None
Actual Value
Range:MASTE
R, SLAVE
Default
Value:None
SingleRAN
118
Parameter ID NE MML
Command
PEERIP BTS3900 ADD OMCH
MOD OMCH
DSP OMCH
LST OMCH
WRFD-050404
LBFD-004002 /
TDLBFD-0040
02
LOFD-003005
GBFD-118601
GBFD-118611
ATM/IP Dual
Stack Node B
Centralized
M2000
Management
OM Channel
Backup
Abis over IP
Abis IP over E1/
T1
Meaning:Indi-
cates the peer IP
address of the
remote
maintenance
channel,
indicates the IP
address of the
M2000 in an IP
network and the
device IP
address of the
RNC in an ATM
network.
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Default
Value:None
PEERMASK BTS3900 ADD OMCH
MOD OMCH
DSP OMCH
LST OMCH
WRFD-050404
LBFD-004002 /
TDLBFD-0040
02
LOFD-003005
GBFD-118601
GBFD-118611
ATM/IP Dual
Stack Node B
Centralized
M2000
Management
OM Channel
Backup
Abis over IP
Abis IP over E1/
T1
Meaning:Indi-
cates the subnet
mask of the peer
IP address for
the remote
maintenance
channel.
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Default
Value:None
SingleRAN
119
Parameter ID NE MML
Command
VLANMODE BTS3900 ADD
VLANMAP
MOD
VLANMAP
LST
VLANMAP
WRFD-050402
LBFD-003003 /
TDLBFD-0030
03
GBFD-118601
IP Transmission
Introduction on
Iub Interface
VLAN Support
(IEEE 802.1p/q)
Abis over IP
Meaning:Indi-
cates the VLAN
mode. When this
parameter is set
to
SINGLEVLAN,
the configured
VLAN ID and
VLAN priority
can be directly
used to label the
VLAN tag. If
this parameter is
set to
VLANGROUP,
the next hop IP
addresses are
mapped to the
VLAN groups,
and then
mapped to the
VLAN tags in
the VLAN
groups
according to the
DSCPs of the IP
packets. In
VLAN group
mode, ensure
that the VLAN
groups have
been configured
by running the
ADD
VLANCLASS
command.
Otherwise, the
configuration
does not take
effect.
GUI Value
Range:SINGLE
VLAN(Single
VLAN),
VLANGROUP
(VLAN Group)
Unit:None
SingleRAN
120
Parameter ID NE MML
Command
Actual Value
Range:SINGLE
VLAN,
VLANGROUP
Default
Value:None
SingleRAN
121
Parameter ID NE MML
Command
CATLOG BTS3900 ADD
BFDSESSION
MOD
BFDSESSION
DSP
BFDSESSION
LST
BFDSESSION
WRFD-050403
LOFD-003007 /
TDLOFD-0030
07
GBFD-118601
Hybrid Iub IP
Transmission
Bidirectional
Forwarding
Detection
Abis over IP
Meaning:Indi-
cates the type of
the BFD session.
If this parameter
is set to
MAINTENAN
CE, this BFD
session is used
only for
continuity check
(CC). If this
parameter is set
to
RELIABILITY,
the BFD session
is used to trigger
route interlock.
Route interlock
enables the
standby route to
take over once
the active route
becomes faulty,
and therefore
prevents service
interruption
caused by route
failures.
GUI Value
Range:MAINT
ENANCE
(Maintenance),
RELIABILITY
(Reliability)
Unit:None
Actual Value
Range:MAINT
ENANCE,
RELIABILITY
Default
Value:RELIABI
LITY
(Reliability)
SingleRAN
122
Parameter ID NE MML
Command
DID BTS3900 SET NE
LST NE
None None Meaning:Indi-
cates the
deployment
identifier that
specifies the site
of the NE. When
multiple NEs are
deployed at the
same site, these
NEs have the
same
deployment
identifier.
GUI Value
Range:0~64
characters
Unit:None
Actual Value
Range:0~64
characters
Default
Value:NULL
(empty string)
SIP BTS3900 ADD
ACLRULE
MOD
ACLRULE
LST ACLRULE
WRFD-050402
WRFD-140209
LOFD-003009 /
TDLOFD-0030
09
LOFD-0030140
1 /
TDLOFD-0030
1401
GBFD-118601
GBFD-113524
IP Transmission
Introduction on
Iub Interface
NodeB
integrated IPSec
IPsec
Access Control
List (ACL)
Abis over IP
BTS Integrated
Ipsec
Meaning:Indi-
cates the source
IP address of
data to which the
ACL rule is
applied. To add
an ACL rule that
is applicable to
data of all source
IP addresses, set
this parameter to
0.0.0.0.
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Default
Value:None
SingleRAN
123
Parameter ID NE MML
Command
DIP BTS3900 ADD
ACLRULE
MOD
ACLRULE
LST ACLRULE
WRFD-050402
WRFD-140209
LOFD-003009 /
TDLOFD-0030
09
LOFD-0030140
1 /
TDLOFD-0030
1401
GBFD-118601
GBFD-113524
IP Transmission
Introduction on
Iub Interface
NodeB
integrated IPSec
IPsec
Access Control
List (ACL)
Abis over IP
BTS Integrated
Ipsec
Meaning:Indi-
cates the
destination IP
address of data
to which the
ACL rule is
applied. To add
an ACL rule that
is applicable to
data of all
destination IP
addresses, set
this parameter to
0.0.0.0.
GUI Value
Range:Valid IP
address
Unit:None
Actual Value
Range:Valid IP
address
Default
Value:None
SingleRAN
124
Parameter ID NE MML
Command
ACTION BTS3900 ADD
ACLRULE
LST ACLRULE
WRFD-050402
WRFD-140209
LOFD-003009 /
TDLOFD-0030
09
LOFD-0030140
1 /
TDLOFD-0030
1401
GBFD-118601
GBFD-113524
IP Transmission
Introduction on
Iub Interface
NodeB
integrated IPSec
IPsec
Access Control
List (ACL)
Abis over IP
BTS Integrated
Ipsec
Meaning:Indi-
cates the action
taken on the data
that matches the
ACL rule. When
the ACL to
which the ACL
rule belongs is
referenced by a
packet filter, the
BS accepts or
transmits the
data that
matches the rule
if this parameter
is set to
PERMIT, and
rejects the data if
this parameter is
set to DENY.
When the ACL
is referenced by
an IPSec policy,
the BS encrypts
or decrypts the
data that
matches the rule
if this parameter
is set to
PERMIT, and
does not
perform any
encryption or
decryption on
the data if this
parameter is set
to DENY.
GUI Value
Range:DENY
(Deny),
PERMIT
(Permit)
Unit:None
Actual Value
Range:DENY,
PERMIT
SingleRAN
125
Parameter ID NE MML
Command
Default
Value:PERMIT
(Permit)
CARRYVPI BSC6910 ADD IPOAPVC
MOD
IPOAPVC
None None Meaning:VPI
value of the
VCL of the
bearer network
GUI Value
Range:0~4095
Unit:None
Actual Value
Range:0~4095
Default
Value:None
CARRYVPI BSC6900 ADD IPOAPVC
MOD
IPOAPVC
None None Meaning:VPI
value of the
VCL of the
bearer network
GUI Value
Range:0~4095
Unit:None
Actual Value
Range:0~4095
Default
Value:None
CARRYVCI BSC6910 ADD IPOAPVC
MOD
IPOAPVC
None None Meaning:VCI
value of the
VCL of the
bearer network
GUI Value
Range:
32~65535
Unit:None
Actual Value
Range:
32~65535
Default
Value:None
SingleRAN
126
Parameter ID NE MML
Command
CARRYVCI BSC6900 ADD IPOAPVC
MOD
IPOAPVC
None None Meaning:VCI
value of the
VCL of the
bearer network
GUI Value
Range:
32~65535
Unit:None
Actual Value
Range:
32~65535
Default
Value:None
IPADDR BSC6910 ADD IPOAPVC
MOD
IPOAPVC
RMV
IPOAPVC
None None Meaning:Local
IP address
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
IPADDR BSC6900 ADD IPOAPVC
MOD
IPOAPVC
RMV
IPOAPVC
None None Meaning:Local
IP address
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
SingleRAN
127
Parameter ID NE MML
Command
PEERIPADDR BSC6910 ADD IPOAPVC
MOD
IPOAPVC
RMV
IPOAPVC
WRFD-031100
WRFD-050301
05
WRFD-050301
WRFD-050105
BOOTP
Permanent
AAL5
Connections for
Control Plane
Traffic
ATM
Transmission
Introduction
Package
ATM Switching
Based Hub
Node B
Meaning:Peer
IP address.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
PEERIPADDR BSC6900 ADD IPOAPVC
MOD
IPOAPVC
RMV
IPOAPVC
WRFD-031100
WRFD-050301
05
WRFD-050301
WRFD-050105
BOOTP
Permanent
AAL5
Connections for
Control Plane
Traffic
ATM
Transmission
Introduction
Package
ATM Switching
Based Hub
Node B
Meaning:Peer
IP address.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
SingleRAN
128
Parameter ID NE MML
Command
NBATMOAMI
P
BSC6900 ADD
UNODEBIP
MOD
UNODEBIP
WRFD-031100
WRFD-031101
BOOTP
NodeB Self-
discovery Based
on IP Mode
Meaning:When
the operation
and
maintenance
channel of
NodeB is
operating in the
ATM, this
parameter
indicates the
address of the
operation and
maintenance
console. The IP
address and
IPOA client IP
address must be
in the same
network
segment.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
SingleRAN
129
Parameter ID NE MML
Command
NBATMOAMI
P
BSC6910 ADD
UNODEBIP
MOD
UNODEBIP
WRFD-031100
WRFD-031101
BOOTP
NodeB Self-
discovery Based
on IP Mode
Meaning:When
the operation
and
maintenance
channel of
NodeB is
operating in the
ATM, this
parameter
indicates the
address of the
operation and
maintenance
console. The IP
address and
IPOA client IP
address must be
in the same
network
segment.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
SingleRAN
130
7 Counters
UMTS:There are no specific counters associated with this feature.
SingleRAN
Description 7 Counters
131
8 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.
SingleRAN
Description 8 Glossary
132
9 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
SingleRAN
Description 9 Reference Documents
133

Automatic OMCH Establishment (SRAN8.0 - 05)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Automatic OMCH Establishment (SRAN8.0 - 05)

Uploaded by

Copyright:

Available Formats

SingleRAN

Automatic OMCH Establishment

You might also like