Automatic OMCH Establishment(SRAN8.0_05)

5/26/2018 Automatic OMCH Establishment(SRAN8.0_05)

1/137

SingleRAN

Automatic OMCH Establishment

Feature Parameter Description

Issue 05

Date 2013-10-30

HUAWEI TECHNOLOGIES CO., LTD.


2/137

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 writtenconsent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice

The purchased products, services and features are stipulated by the contract made between Huawei and the

customer. All or part of the products, services and features described in this document may not be within the

purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,

and recommendations in this document are provided "AS IS" without warranties, guarantees or representations

of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in the

preparation of this document to ensure accuracy of the contents, but all statements, information, and

recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base

Bantian, Longgang

Shenzhen 518129

People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 05 (2013-10-30) Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

i
http://www.huawei.com/


3/137

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-basedAutomatic 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 AutomaticOMCH 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.........................................................................493.3.4 Automatic OMCH Establishment in IPSec Networking Scenario 2.........................................................................69

3.3.5 Automatic OMCH Establishment in IPSec Networking Scenario 3.........................................................................74

3.4 AutomaticOMCH 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/137

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

4.1 Overview....................................................................................................................................................................101

4.2 Principles....................................................................................................................................................................101

4.2.1 Port Listening..........................................................................................................................................................1024.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


5/137

1About 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


6/137

Change Type Change Description ParameterChange

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 ParameterChange

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)


ChangeType

Change Description ParameterChange

Feature

change

Added the function of saving VLAN IDs. For details, see

section Saving VLAN IDs.

None

SingleRAN





2


7/137

ChangeType


Editorial

change

Deleted the automatic OMCH establishment function for

micro base stations.

None

02 (2013-06-30)


Change Type


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


8/137

Change Type Change Description Parameter Change

Feature change l Added the VLAN

scanning function. For

details, see Enabling andDisabling 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 Stationsand 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


9/137


Editorial change Added cautions, MML

commands, and parameters

for deploying a DHCP relayagent.

None.

Draft B (2013-02-25)



Feature change l Changed the names of

parameters thatcorrespond 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


10/137

2Overview

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-1shows theautomatic OMCH establishment phase during base station deployment by PnP.

SingleRAN


Description 2 Overview



6


11/137

Figure 2-1Automatic 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 otherdevices.

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


12/137

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-1describes 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-1Application 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 neithersecures OMCH data nor all or

some of the other data.

SingleRAN





8


13/137

3IP-based Automatic OMCH Establishmentfor 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-1shows the protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or

co-MPT multimode base station and the M2000.

Figure 3-1Protocol 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 theTCP 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


14/137

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-2shows the protocol stacks for an OMCH between the GBTS and the BSC.

Figure 3-2Protocol 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. TheGBTS 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-3shows the networking scenario in which IPsec secures OMCH data.

SingleRAN


Description


Stations



10


15/137

Figure 3-3Networking 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-4shows 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-4Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT

multimode base station and the M2000 (IPSec networking)

Figure 3-5shows the protocol stacks for an OMCH between the GBTS and the BSC in IPSec

networking scenarios.

SingleRAN


Description


Stations



11


16/137

Figure 3-5Protocol stacks for an OMCH between the GBTS and the BSC (IPSec networking)

NOTE

The protocol stacks shown in Figure 3-4and Figure 3-5apply 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. Thebase 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 1and 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 providessecurity to.

SingleRAN


Description


Stations



12


17/137

For details about IPSec tunnels, seeIPSec Feature Parameter Description. For details about

digital certificate management, seePKI 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 OMCHA 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, CAport number, CA path, and transmission protocol (HTTP or HTTPS) used by the CA.

SingleRAN


Description


Stations



13


18/137

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 theDHCP 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-6shows the interworking between the DHCP client

and DHCP server that are in the same broadcast domain.

Figure 3-6DHCP 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 identificationinformation about the DHCP client.

SingleRAN


Description


Stations



14


19/137

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

receivebroadcast 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 isenabled 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-7shows the interworking between the DHCP client and DHCP server that are not in the

same broadcast domain.

Figure 3-7DHCP interworking between the DHCP client and DHCP server that are not in the

same broadcast domain

DHCP Packet Format

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

SingleRAN


Description


Stations



15


20/137

Figure 3-8DHCP 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


21/137

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-1describes the mapping between

base stations and DHCP servers.

Table 3-1Mapping between base stations and DHCP servers

Base Station Type DHCP Server inNon-IPSecNetworkingScenarios

DHCP Server inIPSec NetworkingScenarios

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-MPTmultimode base

station

Same as that of eachsingle-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 isrecommended, because it

provides better function support and paves the way to future smooth upgrades and evolutions.

SingleRAN


Description


Stations



17


22/137

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 ofthe 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 (theDHCPSRVIPparameter) 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 whenthe 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";

TheRSVDSW1(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 TS9using 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 basestation, run the SET DHCPRELAYSWITCHcommand withESset to ENABLEto

SingleRAN


Description


Stations



18


23/137

enable the DHCP relay agent function. Then, run the ADD DHCPSVRIPcommand 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 theM2000 uses the combination of the ESN and slot number as the BS ID. The DID must be included

SingleRAN


Description


Stations



19


24/137

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 publicDHCP 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 NetworkingScenarios

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-9shows the procedure for a base station to obtain configuration information from a

DHCP server when no DHCP relay agent is deployed.

Figure 3-9Procedure 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-10shows the procedure for a base station to obtain configuration information from aDHCP server when a DHCP relay agent is deployed.

SingleRAN


Description


Stations



20


25/137

Figure 3-10Procedure 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 NetworkingScenarios

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-11shows the OMCH networking in this scenario.

Figure 3-11IPsec OMCH networking

Figure 3-12shows the two procedures for the base station in Figure 3-11to obtain transmission

configuration information.

SingleRAN


Description


Stations



21


26/137

Figure 3-12Two 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-13shows the procedure for releasing allocated configuration information.

SingleRAN


Description


Stations



22


27/137

Figure 3-13Procedure 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 parsingreceived 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-2describes the recommended schemes for the base station in SRAN8.0 and laterversions to obtain VLAN information during deployment.

SingleRAN


Description


Stations



23


28/137

Table 3-2Obtaining VLAN information

Scenario SN Base StationDeploymentMode

WhetherIPSec SecuresOMCH Data

Requirementsfor NEs

How toObtain VLANInformation

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


29/137

Scenario SN Base StationDeploymentMode

WhetherIPSec SecuresOMCH Data

Requirementsfor NEs

How toObtain VLANInformation

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 IPaddress 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 sendsARP 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


30/137

l IPsec does not secure OMCH data. Figure 3-14shows 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-15shows the

procedure for a base station to obtain VLAN information in this scenario.

Figure 3-14Scheme 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-15Scheme 1 (IPSec secures OMCH data)

SingleRAN


Description


Stations



26


31/137

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 requestis 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-16shows the procedure for a base station to obtain VLAN information in scheme 2.

Figure 3-16Scheme 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.



4. The base station attempts to send all DHCP packets with recorded VLAN IDs. Only DHCPpackets with correct VLAN IDs can reach the DHCP relay agent.

SingleRAN


Description


Stations



27


32/137

Scheme 3


Figure 3-17Scheme 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 andthen reach the DHCP server.

Scheme 4


SingleRAN


Description


Stations



28


33/137

Figure 3-18Scheme 4

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 thedestination IP address of the ping packets. The ARP packets received by the base station

carry correct VLAN IDs.




packets with correct VLAN IDs can reach the DHCP relay agent.

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 DHCPSWcommand to enable or disable this function locally or remotely.


//Enabling the VLAN scanning function

SingleRAN


Description


Stations



29


34/137

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 DHCPSWcommand is used to

determine whether to start the DHCP procedure automatically to obtain the initial configuration information

or to restore the base station configuration. TheSWITCHparameter indicates whether to enable the

function of starting the DHCP procedure automatically. The VLANSCANSWparameter 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 newVLAN 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


35/137

Introduction to Non-IPSec Networking

Figure 3-19shows a non-IPSec networking scenario in which IPSec does not secure OMCH

data.

Figure 3-19Non-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.

lIPSec does not secure OMCH data.

Automatic OMCH Establishment Procedure

Figure 3-20shows the automatic OMCH establishment procedure in non-IPSec networking

scenarios.

Figure 3-20Automatic OMCH establishment in non-IPSec networking scenarios

SingleRAN


Description


Stations



31


36/137

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 addressof 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 SSLoption 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, thebase 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-3lists the parameters to be contained in the DHCP packet headers.

Table 3-3Parameters to be contained in the DHCP packet headers

ParameterName

MappingDHCPField

Length(Bytes)

ParameterDescription

Mandatoryor Optional

DHCPPacketInvolved

Interface IP

Address

yiaddr 4 Interface IP

address of

the base

station

Mandatory l DHCPO

FFER

l DHCPA

CK

SingleRAN


Description


Stations



32


37/137

ParameterName

MappingDHCPField

Length(Bytes)



DHCPPacketInvolved

Relay AgentIP

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

Optional l

DHCPDISCOVE

RY

l DHCPO

FFER

l DHCPR

EQUEST

l DHCPA

CK

Table 3-4lists the parameters to be contained in Option fields defined by RFC 2132.

Table 3-4Parameters to be contained in DHCP Option fields

ParameterName

MappingDHCP

Option

Length(Bytes)

ParameterDescriptio

n


DHCPPacket

InvolvedSubnet Mask 1 4 Subnet mask

of a DHCP

client

Mandatory l DHCPO

FFER

l DHCPA

CK

SingleRAN


Description


Stations



33


38/137

ParameterName

MappingDHCPOption

Length(Bytes)



DHCPPacketInvolved

RouterOption

3 N*4 List of the IPaddresses of

routers

deployed in a

DHCP

client's

subnet

N indicates

the number

of next-hop

gateways for

the DHCPclient.

Mandatory l

DHCPOFFER

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


39/137

ParameterName

MappingDHCPOption

Length(Bytes)



DHCPPacketInvolved

ServerIdentifier

54 4 IP address of a DHCP

server

Mandatory l

DHCPOFFER

l DHCPA

CK

l REQUES

T

Renewal

(T1) Time

Value

58 4 Interval from

address

assignment

to the

transition tothe

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-5lists the parameters to be contained in subcodes of Option 43 defined by Huawei.

SingleRAN


Description


Stations



35


40/137

Table 3-5Parameters to be contained in subcodes of option 43

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

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

M2000serves 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


41/137

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

MPT 2ndSlot Number

249 1 Slot number of the second

main control

board

Mandatoryonly if the

base station

is configured

with active/

standby or

primary/

secondary

main control

boards.

lDHCPOFFER

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 defaultvalue is 0.

l DHCPO

FFER

l DHCPA

CK

SingleRAN


Description


Stations



37


42/137

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

DID 27 1 to 64 If the basestation is

configured

with only

one BBU, the

DID serves

the same

purpose as

the ESN.

If the base

station is

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

lDHCPDISCOVE

R

l DHCPO

FFER

l DHCPR

EQUEST

l DHCPA

CK

SingleRAN


Description


Stations



38


43/137

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

SubrackTopo

246 1 to 16 Interconnection

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 slotnumber to

identify the

configuratio

n file of the

base station.

Mandatory l

DHCPDISCOVE

R

l DHCPO

FFER

l DHCPR

EQUEST

l DHCPA

CK

SingleRAN


Description


Stations



39


44/137

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

OMInterface

Type

2 1 Transmission interface of

the base

station:

Ethernet or

E1.

NOTE

If an

Ethernet

interface is

used as the

transmission

interface, theOMCH

managed

object (MO)

in

configuratio

n files of the

base station