automatic omch establishment(sran9.0_01)

SingleRAN

Automatic OMCH EstablishmentFeature Parameter Description

Issue 01

Date 2014-04-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2015. 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. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase 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 representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue 01 (2014-04-30) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[email protected]

Contents

1 About This Document..................................................................................................................11.1 Scope..............................................................................................................................................................................11.2 Intended Audience..........................................................................................................................................................21.3 Change History...............................................................................................................................................................21.4 Differences Between Base Station Types.......................................................................................................................4

2 Overview.........................................................................................................................................52.1 Introduction....................................................................................................................................................................52.2 Benefits...........................................................................................................................................................................72.3 Application Networking Scenarios.................................................................................................................................7

3 IP-based Automatic OMCH Establishment for Base Stations..............................................83.1 OMCH Protocol Stacks..................................................................................................................................................83.1.1 Non-IPsec Networking Scenario.................................................................................................................................83.1.2 IPsec Networking Scenario.........................................................................................................................................93.2 Base Station Obtaining Transmission Configuration Information...............................................................................123.2.1 Transmission Mode of the OMCH............................................................................................................................123.2.2 Physical Layer Detection...........................................................................................................................................123.2.3 Data Link Layer Detection........................................................................................................................................133.2.4 DHCP Overview........................................................................................................................................................153.2.5 DHCP Clients and Servers........................................................................................................................................193.2.6 DHCP Procedure.......................................................................................................................................................213.2.7 Automatic DHCP Data Synchronization...................................................................................................................253.2.8 Schemes for Obtaining VLAN Information for DHCP Packets................................................................................263.3 Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station.............343.3.1 Overview...................................................................................................................................................................343.3.2 Automatic OMCH Establishment in Non-IPsec Networking Scenarios...................................................................343.3.3 Automatic OMCH Establishment in IPsec Networking Scenario 1..........................................................................533.3.4 Automatic OMCH Establishment in IPsec Networking Scenario 2..........................................................................713.3.5 Automatic OMCH Establishment in IPsec Networking Scenario 3..........................................................................763.4 Automatic OMCH Establishment by the Separate-MPT Multimode Base Station......................................................813.4.1 Networking................................................................................................................................................................813.4.2 Automatic OMCH Establishment Procedure............................................................................................................823.4.3 Configuration Requirements for the DHCP Server...................................................................................................83

SingleRANAutomatic OMCH Establishment Feature ParameterDescription Contents


ii

3.4.4 Configuration Requirements for Network Equipment..............................................................................................853.5 Application Restrictions...............................................................................................................................................903.5.1 Configuration Requirements for Base Stations and Other Network Equipment.......................................................913.5.2 Impact of U2000 Deployment on Base Station Deployment by PnP........................................................................96

4 ATM-based Automatic OMCH Establishment for Base Stations....................................1024.1 Overview....................................................................................................................................................................1024.2 Principles....................................................................................................................................................................1024.2.1 Port Listening..........................................................................................................................................................1034.2.2 Port Configuration...................................................................................................................................................1044.2.3 PVC Setup and BOOTP Request Initiation.............................................................................................................1044.2.4 RNC Returning the BOOTREPLY Message...........................................................................................................1044.2.5 IPoA Configuration.................................................................................................................................................1054.3 Configuration Guidelines...........................................................................................................................................105

5 TDM-based Base Station Automatic OMCH Establishment............................................1065.1 Introduction................................................................................................................................................................1065.2 Process........................................................................................................................................................................1065.2.1 Sending L2ML Establishment Requests..................................................................................................................1075.2.2 Saving Detection Information.................................................................................................................................108

6 Parameters...................................................................................................................................109

7 Counters......................................................................................................................................125

8 Glossary.......................................................................................................................................126

9 Reference Documents...............................................................................................................127

SingleRANAutomatic OMCH Establishment Feature ParameterDescription Contents


iii

1 About This Document

1.1 ScopeThis document describes the Automatic OMCH Establishment, including its implementationprinciples, 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

l TDLOFD-002004 Self-configuration

Table 1-1 lists the definitions of all kinds of macro base stations.

Table 1-1 Definitions of all kinds of base stations

Base StationName

Definition

GBTS GBTS refers to a base station deployed with GTMU.

eGBTS eGBTS refers to a base station deployed with UMPT_G.

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

eNodeB eNodeB refers to a base station deployed with LMPT, UMPT_L orUMPT_T.

Co-MPTMultimode BaseStation

Co-MPT multimode base station refers to a base station deployed withUMPT_GU, UMPT_GL, UMPT_GT, UMPT_UL, UMPT_UT,UMPT_LT, UMPT_GUL, UMPT_GUT, UMPT_ULT, UMPT_GLT,or UMPT_GULT, and it functionally corresponds to any combinationof eGBTS, NodeB, and eNodeB. For example, Co-MPT multimodebase station deployed with UMPT_GU functionally corresponds to thecombination of eGBTS and NodeB.

SingleRANAutomatic OMCH Establishment Feature ParameterDescription 1 About This Document


1

Base StationName

Definition

Separate-MPTMultimode BaseStation

Separate-MPT multimode base station refers to a base station on whichdifferent modes use different main control boards. For example, basestations deployed with GTMU and WMPT are called separate-MPTGSM/UMTS dual-mode base station.

1.2 Intended AudienceThis document is intended for personnel who:

l Need to understand the features described hereinl Work with Huawei products

1.3 Change HistoryThis section provides information about the changes in different document versions. There aretwo types of changes, which are defined as follows:

l Feature changeChanges in features of a specific product version

l Editorial changeChanges in wording or addition of information that was not described in the earlier version

SRAN9.0 01 (2014-04-30)This issue includes the following changes.

ChangeType

Change Description Parameter Change

Featurechange

None None

Editorialchange

Optimized descriptions in Table 3-29. None

SRAN9.0 Draft B (2014-02-28)This issue includes the following changes.



2

ChangeType


Featurechange

None None

Editorialchange

l Optimized descriptions in 3.2.7 AutomaticDHCP Data Synchronization.

l Optimized descriptions of configurationrequirements for network equipment. Fordetails, see 3.4.4 ConfigurationRequirements for Network Equipment.

l For details about feature support and functionimplementation differences between basestation types, see 1.4 Differences BetweenBase Station Types.

None

SRAN9.0 Draft A (2014-01-20)Compared with Issue 06 (2013-12-30) of SRAN8.0, Draft A (2014-01-20) of SRAN9.0 includesthe following changes.

ChangeType


Featurechange

Added the function of automatic DHCP datasynchronization. For details, see 3.2.7 AutomaticDHCP Data Synchronization.

None

Added the function of saving VLAN IDs. Fordetails, see Saving VLAN IDs.

Modified the configuration requirements fornetwork equipment. For details, see 3.4.4Configuration Requirements for NetworkEquipment.

Huawei mobile network management systemM2000 is renamed U2000.

Editorialchange

Added descriptions of physical layer and data linklayer detection. For details, see 3.2.2 PhysicalLayer Detection and 3.2.3 Data Link LayerDetection.

None

Modified descriptions in 3.2.5 DHCP Clientsand Servers.



3

1.4 Differences Between Base Station TypesLampSite base stations are distributed base stations that provide indoor coverage. In thisdocument, LampSite base stations work in UMTS, LTE, or UMTS+LTE mode, but not in GSMmode.

In this document, micro base stations are all integrated entities. They work in UMTS or LTEFDD mode, but not in GSM or LTE TDD mode. Descriptions of boards, cabinets, subracks,slots, and RRUs are not relevant to micro integrated base stations. The following base stationsare single-mode ones, without co-MPT or separate-MPT multimode applications:

l BTS3202El BTS3203El BTS3803El BTS3902E

Feature Support by Macro, Micro, and LampSite Base Stations

Feature ID Feature Name Supported byMacroSites

Supported byMicroSites

Supported byLampSiteSites

WRFD-031100 BOOTP Yes Yes Yes

WRFD-031101 NodeB Self-discovery Based on IPMode

Yes Yes Yes

LOFD-002004 Self-configuration Yes Yes Yes

TDLOFD-002004 Self-configuration Yes No No

Function Implementation in Macro, Micro, and LampSite Base Stations

Function Difference

Automatic datasynchronization byDHCP

Micro base stations do not support automatic data synchronizationthrough the DHCP process.



4

2 Overview

2.1 IntroductionOperation and maintenance channels (OMCHs) are established between base stations and theoperation maintenance center (OMC, either the U2000 or BSC). OMCHs are used to transmitoperation 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 andthe U2000, or between the GBTS and the BSC.

l OMCHs between the co-MPT multimode base station and the U2000.l MPT is short for main processing and transmission unit. OMCHs between the separate-

MPT multimode base station and the U2000. The separate-MPT multimode base station iscomprised of multiple cascaded single-mode base stations and therefore has multipleOMCHs. For example, OMCHs for the separate-MPT UMTS/LTE dual-mode base stationinclude the OMCH between the NodeB and the U2000, and the OMCH between theeNodeB and the U2000.

l OMCHs between the U2000 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 configurationof the main control board, multimode base stations are classified into co-MPT multimode base stations andseparate-MPT multimode base stations. For co-MPT multimode base stations, GSM, UMTS, and LTEmodes 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 notrequired. A GBTS, eGBTS, NodeB, eNodeB, co-MPT multimode base station, or separate-MPT multimodebase station is used if differentiation among GSM, UMTS, and LTE modes is required.In this document, the BSC is the OMC of a GBTS and the U2000 is the OMC of an eGBTS, NodeB,eNodeB, separate-MPT multimode base station, or co-MPT multimode base station.

The Automatic OMCH Establishment feature enables a powered-on base station, which isconfigured with hardware but no transmission information, to obtain OMCH configurationinformation through the transport network and automatically establish an OMCH to the U2000or BSC. The base station can then automatically download software and configuration files/configuration data from the U2000 or BSC over the established OMCH and activate them. Afterbeing commissioned, the base station enters the working state. For details, see 3900 Series BaseStation Commissioning Guide.

SingleRANAutomatic OMCH Establishment Feature ParameterDescription 2 Overview


5

This feature applies to base station deployment by PnP. Figure 2-1 shows the O&M path self-establishment phase during deployment by PnP.

Figure 2-1 Automatic OMCH establishment phase during base station deployment by PnP

NOTE

This document describes only the procedures marked in the dashed box shown in Figure 2-1.

To establish an OMCH, a base station needs to obtain the following transmission configurationinformation:

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-hopgateway, the IP address of the U2000 or BSC, and the IP address mask of the U2000 orBSC.

l Security-related information, including the Certificate Authority (CA) name, transmissionprotocol (HTTP or HTTPS) used by the CA, CA address, CA port number, CA path, IPaddress of the security gateway (SeGW), and name of the security gateway. Obtaining theoperator's CA information is required only when the base station needs to use digitalcertificates 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 "BaseStation Obtaining Transmission Configuration Information".



6

2.2 BenefitsWith the Automatic OMCH Establishment feature, a base station can establish OMCHs bynetwork communication without requiring operations at the local end. This implements remotebase station deployment by PnP, thereby facilitating base station deployment and reducing thedeployment cost and time.

2.3 Application Networking ScenariosGBTSs support automatic OMCH establishment in TDM and IP networking scenarios. NodeBssupport automatic OMCH establishment in ATM and IP networking scenarios. eNodeBs andeGBTSs support automatic OMCH establishment in IP networking scenarios.

Table 2-1 describes the application networking scenarios for the Automatic OMCHEstablishment feature. In this document, the IPsec or non-IPsec networking indicates that the IPlayer communication between the base station and other devices is secured or not secured byIPsec, respectively.

Table 2-1 Application networking scenarios

Networking Scenario Description

Non-IPsec IPsec does not secureDynamic Host ConfigurationProtocol (DHCP) packets,OMCH data, service data,signaling data, or clock data.

IPsec Scenario 1 IPsec secures DHCP packets,OMCH data, and all or someof the other data.

Scenario 2 IPsec secures OMCH dataand all or some of the otherdata. It does not secureDHCP packets.

Scenario 3: IPsec secures service data,signaling data, and all orsome of the other data. It doesnot secure OMCH data.

ATM The OMCH between theNodeB and M2000 isconfigured over ATM.

TDM The OMCH between theGBTS and BSC uses TDMtransmission. The OMCH isset up over E1 or T1 links.



7

3 IP-based Automatic OMCH Establishmentfor Base Stations

3.1 OMCH Protocol StacksOMCHs between the eGBTS, NodeB, eNodeB, or co-MPT multimode base station and theU2000 are carried over Transmission Control Protocol (TCP). OMCHs between the GBTS andthe BSC are carried over User Datagram Protocol (UDP).

3.1.1 Non-IPsec Networking ScenarioFigure 3-1 shows the protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, orco-MPT multimode base station and the U2000.

Figure 3-1 Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPTmultimode base station and the U2000

As shown in Figure 3-1, an OMCH between the eGBTS, NodeB, eNodeB, or co-MPTmultimode base station and the U2000 is carried over TCP and Secure Sockets Layer (SSL), ofwhich SSL is optional.

The eGBTS, NodeB, eNodeB, or co-MPT multimode base station listens to the TCP connectionestablishment request with a specific TCP port number from the U2000, and establishes the TCPconnection to the U2000 as requested. After the TCP connection is established, the U2000

SingleRANAutomatic OMCH Establishment Feature ParameterDescription

3 IP-based Automatic OMCH Establishment for BaseStations


8

initiates an OMCH establishment request to the eGBTS, NodeB, eNodeB, or co-MPT multimodebase station.

The U2000 can use SSL to perform encryption and authentication for OMCHs and enable theestablishment of SSL-based OMCHs. SSL uses the public key infrastructure (PKI), with whichthe communication between the base station and the U2000 is protected against eavesdroppingand therefore confidentiality and reliability are guaranteed. For details about SSL, see SSLFeature 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. TheGBTS listens to the UDP connection establishment request with a specific UDP port numberfrom the BSC, and establishes the UDP connection to the BSC as requested. After the UDPconnection is established, the BSC initiates an OMCH establishment request to the GBTS.

NOTE

During the OMCH establishment procedure, the eGBTS, NodeB, eNodeB, or co-MPT multimode basestation 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 beallowed to pass through the firewall between the base station and the DHCP server, U2000, or BSC.

After establishing an OMCH to the U2000, the base station uses File Transmission Protocol (FTP) todownload software and configuration files from the FTP server. FTP runs over TCP/IP, and therefore itstransport 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 todownload software and configuration files from the BSC.

3.1.2 IPsec Networking ScenarioIn IPsec networking scenarios, OMCH data can be secured or not secured by IPsec. Figure3-3 shows the networking scenario in which IPsec secures OMCH data.




9

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 devicesin 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 andthen forwarded by the SeGW to the U2000 or BSC in the trusted domain.

Figure 3-4 shows the protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, orco-MPT multimode base station and the U2000 in IPsec networking scenarios. Figure 3-5 showsthe protocol stacks for an OMCH between the GBTS and the BSC.

Figure 3-4 Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPTmultimode base station and the U2000 (IPsec networking)




10

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 networking scenarios. Whetherthe base station supports IPsec depends on the base station type and the software and hardware pertainingto the main control board.

IPsec networking is not supported by the following base stations: GBTSs in which the GTMU providesthe transmission port and NodeBs in which the WMPT provides the transmission port.

In IPsec networking scenarios, IPsec secures base station data. IPsec is a security architecturedefined by the Internet Engineering Task Force (IETF) and applicable to the IP layer. IPsecsecures data communication by identity authentication, data encryption, data integrity, andaddress encryption. During the automatic OMCH establishment procedure, the base stationestablishes an IPsec tunnel to the SeGW and then an OMCH secured by the IPsec tunnel.

The base station uses two types of IP addresses:

l IP addresses in an untrusted domain:

Interface IP addresses for the base station to communicate with the SeGW. These IPaddresses can be used to access to the SeGW in an untrusted domain.

l IP addresses in a trusted domain:

IP addresses for the base station to cmmunicate with the peer end such as the U2000, BSC,or U2000 with an integrated DHCP server. These IP addresses can be used to access to theU2000, BSC, or U2000 with an integrated DHCP server.

During site deployment, NEs in the untrusted and trusted domains may communicate with oneanother. For example, a base station uses an interface IP address in the untrusted domain tocommunicate with the DHCP server in the trusted domain, or the DHCP relay in the untrusteddomain uses the IP address in the untrusted domain to communicate with the DHCP server inthe trusted domain. For details, see 3.3.3 Automatic OMCH Establishment in IPsecNetworking Scenario 1 and 3.3.4 Automatic OMCH Establishment in IPsec NetworkingScenario 2.




11

The base station uses the interface IP address to access the untrusted domain. Unless otherwisespecified, 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, anoperator must deploy the PKI. During automatic OMCH establishment, the base stationinterworks with the operator's PKI using the Certificate Management Protocol (CMP) andobtains the operator-issued device certificate and CA root certificate. Then, the base stationestablishes an IPsec tunnel to the SeGW as well as the OMCH that the new IPsec tunnel providessecurity to. For details about IPsec tunnels, see IPsec Feature Parameter Description forSingleRAN. For details about digital certificate management, see PKI Feature ParameterDescription for SingleRAN.

If the operator uses IPsec and pre-shared key (PSK) authentication, the base station fails toautomatically establish an OMCH. In this case, you must use other methods to deploy the basestation.

SSL is optional. The U2000 can use SSL to perform encryption and authentication for OMCHsand enable the establishment of SSL-based OMCHs. SSL uses the PKI, with which thecommunication between the base station and the U2000 is protected against eavesdropping andtherefore confidentiality and reliability are guaranteed. For details about SSL, see SSL FeatureParameter Description.

3.2 Base Station Obtaining Transmission ConfigurationInformation

3.2.1 Transmission Mode of the OMCHA base station has two types of transmission ports: E1/T1 ports and Ethernet ports. E1/T1 portssupport TDM, ATM, and IP over E1/T1 transmission modes, and Ethernet ports support IPtransmission mode. No transmission mode is configured on the base station before the OMCHis established. Therefore, the base station tries different transmission modes over thetransmission ports until the OMCH is successfully established. Different base stations trydifferent transmission modes in polling mode:

l eGBTS, NodeB, eNodeB, and co-MPT multimode base station: IP over FE/GE, ATM, andthen IP over E1/T1

l GBTS: TDM, IP over E1/T1, and then IP over FE/GE

3.2.2 Physical Layer DetectionA base station negotiates with a peer transmission device about the duplex mode and data ratefor an Ethernet port on the physical layer. The peer transmission device can work in auto-negotiation or full duplex mode.

If an E1/T1 port is available on the physical layer, an eGBTS, NodeB, eNodeB, or co-MPTmultimode base station attempts to set the working mode of a detection port to E1/T1 mode, andusers can set the working mode of a detection port to E1/T1 mode for a GBTS by using therelated DIP switch.




12

3.2.3 Data Link Layer Detection

IP over FE/GE TransmissionA base station obtains the VLANs used by the data link layer through the VLAN acquisitionprocess. For details, see section 3.2.8 Schemes for Obtaining VLAN Information for DHCPPackets.

IP over E1/T1 TransmissionYou can learn that a base station works in E1 or T1 mode from physical layer detection. Thebase station supports PPP/MP detection on E1/T1 timeslot combinations. Table 3-1 and Table3-2 describe the E1 and T1 timeslot combinations, respectively. Note that PPP is short for Point-to-Point Protocol and MP is short for Multilink Protocol.

Table 3-1 E1 timeslot combinations

SerialNumber

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

1 11111111111111111111111111111110 0xFFFFFFFE

2 00000000000000001111111111111110 0x0000FFFE

3 00000000000000011111111111111110 0x0001FFFE

4 00000000000001111111111111111110 0x0007FFFE

5 00000000000000000011111111111110 0x00003FFE

6 00000000000111111111111111111110 0x001FFFFE

7 00000000000000000000111111111110 0x00000FFE

8 00000000011111111111111111111110 0x007FFFFE

9 00000000000000000000001111111110 0x000003FE

10 00000001111111111111111111111110 0x01FFFFFE

11 00000111111111111111111111111110 0x07FFFFFE

12 00011111111111111111111111111110 0x1FFFFFFE

13 01111111111111111111111111111110 0x7FFFFFFE

14 00000000000000000000000011111110 0x000000FE

15 00000000000000000000000000111110 0x0000003E

16 00000000000000111111111111111110 0x0003FFFE

17 00000000000000000111111111111110 0x00007FFE

18 00000000000011111111111111111110 0x000FFFFE

19 00000000000000000001111111111110 0x00001FFE




13

SerialNumber

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

20 00000000001111111111111111111110 0x003FFFFE

21 00000000000000000000011111111110 0x000007FE

22 00000000111111111111111111111110 0x00FFFFFE

23 00000011111111111111111111111110 0x03FFFFFE

24 00001111111111111111111111111110 0x0FFFFFFE

25 00111111111111111111111111111110 0x3FFFFFFE

26 00000000000000000000000111111110 0x000001FE

27 00000000000000000000000001111110 0x0000007E

Table 3-2 T1 timeslot combinations

SerialNumber

23 Timeslot<------------------>0Timeslot

Hexadecimal Digit

1 111111111111111111111111 0x00FFFFFF

2 000000000111111111111111 0x00007FFF

3 000000011111111111111111 0x0001FFFF

4 000000000001111111111111 0x00001FFF

5 000001111111111111111111 0x0007FFFF

6 000000000000011111111111 0x000007FF

7 000111111111111111111111 0x001FFFFF

8 000000000000000111111111 0x000001FF

9 011111111111111111111111 0x007FFFFF

10 000000000000000001111111 0x0000007F

11 000000000000000000011111 0x0000001F

12 000000001111111111111111 0x0000FFFF

13 000000000011111111111111 0x00003FFF

14 000000111111111111111111 0x0003FFFF

15 000000000000111111111111 0x00000FFF

16 000011111111111111111111 0x000FFFFF

17 000000000000001111111111 0x000003FF




14

SerialNumber

23 Timeslot<------------------>0Timeslot

Hexadecimal Digit

18 001111111111111111111111 0x003FFFFF

19 000000000000000011111111 0x000000FF

20 000000000000000000111111 0x0000003F

NOTE

In Table 3-1 and Table 3-2, 1 indicates that the timeslot is occupied and 0 indicates that the timeslot is notoccupied. Timeslot combinations that are not listed in the tables cannot be used for PnP deployment.

If a base station works in IP over E1/T1 mode, its peer transmission device must be configuredas follows:

l PPP/MP detection is configured as non-authentication.

l The peer IP address is configured for PPP/MP detection.

If the peer transmission device is not functioning as a DHCP server, the DHCP relay agentfunction must be enabled on the interface for PPP/MP detection on the peer transmission device.

3.2.4 DHCP Overview

Introduction

Before an OMCH is established, a base station is not configured with any data and cannotperform end-to-end communication with other devices at the IP layer. To implement thiscommunication, the base station needs to obtain the following information:

l OMCH configuration data, including the OM IP address, OM VLAN ID, interface IPaddress, interface IP address mask, IP address of the next-hop gateway, IP address of theU2000 or BSC, and IP address mask of the U2000 or BSC.

l During base station deployment by PnP, if the base station needs to use digital certificatesissued by the operator's CA to perform identity authentication with other devices, it alsoneeds 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.

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 anddistribute configuration parameters and adopts the client/server mode. The DHCP procedureinvolves 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 DHCPclient




15

l DHCP relay agent: an NE that transmits DHCP packets between a DHCP server and aDHCP client. A DHCP relay client must be deployed between a DHCP server and a DHCPclient that are in different broadcast domains.

After a DHCP client accesses the network, it actively exchanges DHCP packets with its DHCPserver to obtain configuration parameters. During the exchange, the DHCP server and the DHCPrelay 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 InterworkingWhen a DHCP client and a DHCP server are in the same broadcast domain, they can receivebroadcast packets from each other. Figure 3-6 shows the interworking between the DHCP clientand 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 samebroadcast domain

1. After the DHCP client starts, it broadcasts a DHCPDISCOVER packet to search for anavailable DHCP server. The DHCPDISCOVER packet carries the identificationinformation about the DHCP client.

2. The DHCP server responds to the DHCPDISCOVER packet with a DHCPOFFER packet.3. The DHCP client sends a DHCPREQUEST packet to the DHCP server, requesting

parameters such as an IP address.4. The DHCP server sends a DHCPACK packet to the DHCP client to assign parameters such

as an IP address.5. If the assigned parameters cannot be used, for example, an assigned IP address has been

used by other DHCP clients, the DHCP client sends a DHCPDECLINE packet to notifythe DHCP server.

6. If the DHCP client does not need the assigned parameters any more, it sends aDHCPRELEASE packet to notify the DHCP server so that the DHCP server can assignthese parameters to other DHCP clients.




16

When the DHCP client and DHCP server are not in the same broadcast domain, they cannotreceive broadcast packets from each other. In this case, the DHCP relay agent functionmust be enabled in the broadcast domain of the DHCP client to ensure the communicationbetween 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 addressof the corresponding DHCP server must be configured so that the DHCP relay agent canforward the DHCP packets from the DHCP client to the correct DHCP server. Figure3-7 shows the interworking between the DHCP client and DHCP server that are not in thesame broadcast domain.

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

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




17

Figure 3-8 DHCP packet format

NOTE

The actual length and sequence of each field in a DHCP packet in software implementation may be differentfrom those shown in Figure 3-8.

In a DHCP packet, the IP and UDP headers are in the standard format, and the DHCP headercontains the DHCP control and configuration information. In the DHCP header, the fields relatedto 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 manysubcodes. Among them, Option 43 carries Huawei proprietary information elements (IEs)and most configuration information of the base station. For example, subcode 1 in Option43 carries the electronic serial number (ESN) of the Huawei base station. For details aboutsubcodes of Option43, see Table 3-7.




18

Because Option 43 has a limited length, Option 224 is also used to carry Huawei proprietaryIEs in SRAN8.0 or later.

For details about DHCP, see section "Dynamic Host Configuration Protocol (DHCP)" in RFC2131 and "DHCP Options and BOOTP Vendor Extensions" in RFC 2132.

3.2.5 DHCP Clients and ServersIn this document, base stations act as DHCP clients. Table 3-3 describes the mapping betweenbase stations and DHCP servers.

Table 3-3 Mapping between base stations and DHCP servers

Base Station Type DHCP Server inNon-IPsecNetworkingScenarios

DHCP Server inIPsec NetworkingScenarios

Single-mode GBTS BSC In the trusteddomain: U2000DHCP serverIn the untrusteddomain: publicDHCP server

eGBTS/eNodeB U2000

NodeB U2000 or RNC

Multimode Co-MPT multimodebase station

U2000

Separate-MPTmultimode basestation

Same as that of eachsingle-mode basestation Unlessotherwise specified,"base stationcontroller" in thisdocument is ageneric term forGSM and UMTSmodes.

NOTE

The DHCP server and the U2000 are different logical communication entities, although they may bedeployed on the same hardware. Therefore, this document distinguishes between the DHCP server and theU2000.

If the DHCP server is deployed on the base station controller, the base station can be on the same L2network as the base station controller. If the DHCP server is deployed on the U2000, the base station cannotbe on the same L2 network as the U2000. For security reasons, the U2000's operating system can processonly DHCP unicast packets, not DHCP broadcast packets

From SRAN8.0 onwards, if single-mode base stations or separate-MPT multimode base stationsevolve to co-MPT multimode base stations, their DHCP servers must migrate to the U2000.Even if the evolution is not implemented, the migration is recommended, because it providesbetter function support and paves the way to future smooth upgrades and evolutions.




19

When the base station is not on the same L2 network as the DHCP server, a DHCP relay agentmust be deployed. Pay attention to the following when deploying a DHCP relay agent:

l When a next-hop gateway of the base station is deployed on the transport network, theDHCP relay agent function must be enabled and the U2000 DHCP server IP address mustbe configured on the next-hop gateway of the base station.– If the Virtual Router Redundancy Protocol (VRRP) is deployed on the next-hop

gateway, configure the VRRP's virtual IP address as the IP address of the DHCP relayagent.

– If the base station is a GBTS, run the SET BTSIP command. In this step, setBTSGWIPSWITCH to ON and NEXTHOP to the IP address of the base station's next-hop gateway.

l When the base station is on the same L2 network as the base station controller, DHCPpackets pass through the base station controller, and the U2000 serves as the DHCP serverfor the base station (for example, eGBTS or NodeB), this base station controller can bedeployed as the DHCP relay agent. If the DHCP relay agent function is enabled on a certainport of the base station controller, this port serves as the DHCP relay agent for all eGBTSsand NodeBs connected to this port. The ADD DHCPRLY command can be used to enablethe 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 U2000 that manages

the base station controller serves as the DHCP server for the base station. If not, theDHCP server IP address of the base station (the DHCPSRVIP1(BSC6900,BSC6910)parameter) also needs to be configured.

– DHCPPID is used to enable or disable the DHCP relay agent function only onBSC6900s. The base station controller serves as the DHCP server for the base stationby default. You can select the OTHERSWITCH check box under the DHCPPIDparameter to enable the DHCP relay agent function for the base station.A few MML command examples are as follows://Enabling the DHCP relay agent function on the base station controller when the U2000 that manages this base station controller is the DHCP server for the base stationADD DHCPRLY: DHCPRLYID=1, DHCPRLYGATEWAYIP="10.1.1.1", DHCPPID=OTHERSWITCH-1, DHCPSRVISEMSIP=Yes;//Enabling the DHCP relay agent function on the base station controller when the U2000 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.1ADD DHCPRLY: DHCPRLYID=1, DHCPRLYGATEWAYIP="10.1.1.1", DHCPPID=OTHERSWITCH-1, DHCPSRVISEMSIP=No, DHCPSRVIP1="10.0.0.1";

NOTE

Whether the base station controller can serve as the DHCP server or DHCP relay agent depends on thebase station type.

l For GBTSs, the base station controller can only serve as the DHCP relay server.

l For NodeBs, the base station controller can serve as both the DHCP server and DHCP relay agent.

l For other types of base stations, such as the eGBTS and co-MPT multimode base station, the basestation controller can only serve as the DHCP relay agent.

l When base stations are cascaded or backplane co-transmission is applied, an upper-levelbase station serves as the next-hop gateway for its lower-level base station. In this case, the




20

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 multimodebase station, run the SET DHCPRELAYSWITCH command with ES set toENABLE to enable the DHCP relay agent function. Then, run the ADDDHCPSVRIP command with DHCPSVRIP set to the DHCP server IP address of thelower-level base station. A maximum of four DHCP server IP addresses can beconfigured. A few MML command examples are as follows://Enabling the DHCP relay agent function on the upper-level base stationSET DHCPRELAYSWITCH: ES=ENABLE;//Setting the DHCP server IP address to 10.19.19.11. Each DHCP broadcast packet will be forwarded to all DHCP servers.ADD DHCPSVRIP: DHCPSVRIP="10.19.19.11";

– If the upper-level base station is a GBTS, run the ADD BTSDHCPSVRIP commandwith DHCPSRV set to the IP address of the lower-level base station's DHCP server. Afew MML command examples are as follows: For the eGBTS, NodeB, eNodeB, or co-MPT multimode base station:ADD BTSDHCPSVRIP: IDTYPE=BYID, BTSID=20, DHCPSRV="10.100.10.10";

In base station cascading scenarios, the upper-level base station attempts to use its OM IPaddress and lower port IP address as the DHCP relay agent IP addresses.

In backplane co-transmission scenarios, the upper-level base station attempts to use its OMIP address and upper transmission port's interface IP address as the DHCP relay agent IPadddress. Note that the upper transmission port's interface IP address is on the same networkas the next-hop IP address of the DHCP server IP address.

For details about configuration requirements, see Table 3-27.

l A base station can serve as the DHCP relay agent for other base stations in the same L2network. In this case, the DHCP relay agent function must be enabled and the DHCP serverIP 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.

l Cascaded base stations cannot exceed four levels on the chain topology because DHCPpackets will be discarded if the number of DHCP relay agents is greater than four in thetransport network.

3.2.6 DHCP Procedure

Base Station Identification

Upon receiving a DHCP packet from a base station, the DHCP server finds and sends relatedconfiguration information to the base station based on the base station identification (BS ID)contained in the DHCP packet.

The U2000 that matches SRAN8.0 or a later version uses the combination of the ESN and slotnumber or the combination of the deployment identifier (DID), subrack topology, and slotnumber as the BS ID.

Base station controllers and U2000s that match versions earlier than SRAN8.0 use thecombination 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:




21

l ESN identifies the baseband unit (BBU) backplane of the base station. Each backplane hasa 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 intothe base station using a barcode scanner connected to the USB port of the main controlboard during base station deployment. After being scanned into the base station, the DIDis broadcast in all BBUs. All main control boards will record the DID and use it as the BSID in the DHCP procedure.

l Subrack topology identifies the interconnection relationship between BBU subracks thatare interconnected. The combination of the DID and subrack topology uniquely identifiesa 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 basestation is configured with active and standby main control boards, the slot number is thatof 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 theU2000 uses the combination of the ESN and slot number as the BS ID. The DID must be includedin the base station configuration file if the U2000 uses the combination of the subrack topologyand 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 thetransmission port of the base station is an Ethernet port and the DHCP server of the base station is deployedon the U2000.

Procedure for Obtaining Configuration Information in Non-IPsec NetworkingScenarios

Procedure for Obtaining Configuration Information with No DHCP Relay AgentA DHCP client and a DHCP server on the same Layer 2 (L2) network can directly communicatewith each other. The L2 network is a subnet in which broadcast IP packets can be exchangedand forwarded by Media Access Control (MAC) addresses and VLAN IDs. An example is theEthernet or a VLAN of the Ethernet.

Figure 3-9 shows the procedure for a base station to obtain configuration information from aDHCP server when no DHCP relay agent is deployed.




22

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 aDHCPDISCOVER packet with the BS ID. The DHCP server then sends configurationinformation 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 mustbe installed on the next-hop gateway of the DHCP client to forward DHCP packets. The DHCPrelay agent must be on the same L2 network as the DHCP client, and the DHCP server must beon 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 aDHCP server when a DHCP relay agent is deployed.

Figure 3-10 Procedure for obtaining configuration information with a DHCP relay agent

The procedure is as follows: The DHCP relay agent converts DHCP packets broadcast by thebase station to unicast packets and routes the unicast packets to the DHCP server. The DHCPserver sends unicast response packets to the DHCP relay agent, which then broadcasts receivedresponse packets on the L2 network.




23

Procedure for Obtaining Configuration Information in IPsec NetworkingScenarios

In IPsec networking scenarios, a DHCP server in the trusted domain can be secured or not securedby IPsec. When the DHCP server is secured by IPsec, a public DHCP server in the untrusteddomain must be deployed. Figure 3-11 shows the OMCH networking in this scenario.

Figure 3-11 IPsec OMCH networking

Figure 3-11 shows the two procedures for the base station in Figure 3-12 to obtain transmissionconfiguration information.

Figure 3-12 Two procedures for obtaining transmission configuration information in IPsecnetworking scenarios

1. The base station exchanges DHCP packets with a public DHCP server to obtaininformation, such as the interface IP address for accessing the untrusted domain and theSeGW IP address. The base station also needs to obtain the CA IP address because digital




24

certificates are required for identity authentication with the SeGW. This procedure isreferred to as the first DHCP procedure.

2. The base station negotiates with the SeGW on the Internet Key Exchange (IKE) securityassociation (SA) and IPsec SA, and then establishes an IPsec tunnel. Because digitalcertificates are required for identity authentication with the SeGW, the base station mustapply to the CA for digital certificates that can be identified by the SeGW.

3. The base station exchanges DHCP packets with its U2000 DHCP server to obtain the OMIP address used for accessing the trusted domain. This procedure is referred to as the secondDHCP procedure. The second DHCP procedure varies depending on IPsec networkingscenarios. For details, see section "Obtaining Formal Transmission ConfigurationInformation from the Internal DHCP Server".

During the first DHCP procedure, the public DHCP server runs DHCP. It may not supportHuawei-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 sendsit to the base station. During the second DHCP procedure, the U2000 DHCP server sendsconfiguration parameters to the base station based on the BS ID reported by the base station.

Procedure for Releasing Allocated Configuration InformationWhen a base station obtains configuration information from its U2000 DHCP server and doesnot need configuration information allocated by a public DHCP server, the base station sends aDHCPRELEASE message to the public DHCP server. After receiving the DHCPRELEASEmessage, the public DHCP server can redistribute allocated configuration information to otherNEs. Figure 3-13 shows the procedure for releasing allocated configuration information.

Figure 3-13 Procedure for releasing allocated configuration information

NOTE

In addition to the preceding procedures, DHCP also supports the procedure for updating configurationinformation. However, base stations in SRAN8.0 do not support the procedure for updating configurationinformation.

3.2.7 Automatic DHCP Data SynchronizationBefore you use Automatic OMCH Establishment, ensure that correct DHCP data of a base stationis available on the U2000 DHCP server. Any manual modifications to a base station'stransmission configuration data may change its DHCP data on the U2000. In earlier versions,users have to manually ensure that the DHCP data on the U2000 DHCP server is correct before




25

the next automatic OMCH establishment procedure starts. As manual data check is a complexand error-prone process, the automatic DHCP data synchronization function is introduced in thisversion.

After the base station is deployed, the system automatically synchronizes manual modificationsto the transmission configuration data in the base station configuration file with the U2000 DHCPserver. This ensures the configuration information consistency between the U2000 DHCP serverand the base station. For manual modifications on a single base station, the system starts datasynchronization 10 minutes after the last manual data modification and completes thesynchronization within 5 minutes. For manual modifications on a number of base stations, thesystem starts data synchronization for every 200 base stations as a batch and completes eachbatch's synchronization within less than or equal to 30 minutes. DHCP data must be manuallymodified on the U2000 GUI.

However, the automatic DHCP data synchronization function does not support automaticsynchronization of the NE name, NE type, ESN, and working mode because they identify aspecific NE.

In addition, this function does not support automatic synchronization of Security GatewayEmergency Bypass because it must be manually configured.

Automatic DHCP data synchronization supports synchronization of other information on theU2000 DHCP server. Before starting automatic DHCP data synchronization, ensure that therelated NE data exists in the current data area on the CME.

3.2.8 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 anOMCH is established, that is, before the base station sends the first DHCP packet, the base stationmust learn VLAN information after it starts. After learning VLAN information by parsingreceived Address Resolution Protocol (ARP) packets with VLAN IDs, the base station deliversDHCP packets with VLAN IDs and interworks with DHCP servers to obtain transmissionconfiguration 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 VLANacquisition process. With VLAN acquisition, the base station actively acquires VLAN IDsof 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 VLANIDs 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 IDsto 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 precedingsteps on this port.




26

l If the base station has multiple transmission ports, it repeats the preceding steps on othertransmission ports.

Table 3-4 describes the recommended schemes for the base station in SRAN8.0 and laterversions to obtain VLAN information during deployment.

Table 3-4 Obtaining VLAN information

Scenario SN Whether IPsecSecuresOMCH Data

NetworkingScenario

Requirementsfor NEs

How to ObtainVLANInformation

1 No IPsecsecuresservicedata,signalingdata, and allor some ofthe otherdata. It doesnot secureOMCHdata. (IPsecnetworkingscenario 3)

N/A Using scheme 1




27


NetworkingScenario

Requirementsfor NEs


2 Yes IPsecsecuresDHCPpackets,OMCHdata, and allor some ofthe otherdata. (IPsecnetworkingscenario 1)

l The SeGWinitiates arequest forIKEnegotiationwith the basestation. Thedestination IPaddress of therequest is theinterface IPaddress thatthe basestation uses toaccess theuntrusteddomain.

l The VLANinformation inDHCP packetssent by thebase stationmust be thesame as theVLANinformation intheconfigurationfiles of thebase station.

3 Yes IPsecsecuresOMCHdata and allor some ofthe otherdata. It doesnot secureDHCPpackets.(IPsecnetworkingscenario 2)

The securitypolicy allows thetransmission ofDHCP packetssent by the U2000DHCP server tothe base station.

Using scheme 2




28


NetworkingScenario

Requirementsfor NEs



The L2 network isconfigured withthe default VLANID or no VLANID.

Using scheme 3


The next-hopgateway of thebase station canperiodically sendping packets tothe interface IPaddress of thebase station.

Using scheme 4

If a base station is deployed by PnP, the scheme for obtaining VLAN information variesdepending on whether IPsec secures OMCH data and the capability of NEs:

l If IPsec does not secure OMCH data, scheme 1 is used:The U2000 or BSC actively and periodically sends OMCH establishment requests to thebase 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 fromARP packets and includes recorded VLAN IDs in DHCP packets.

l If IPsec secures OMCH data, any of the following schemes is used:

– Scheme 1

– Scheme 2: The DHCP server on the U2000 periodically sends the base station emptyDHCPOFFER packets (containing DHCP headers only) with the destination IP addressset to the interface IP address of the base station. This enables the next-hop gateway ofthe base station to send ARP packets, from which the base station derives VLANinformation.

– Scheme 3: The base station sends DHCP packets with no VLAN ID, and the L2 networkattaches a VLAN ID to DHCP packets sent by the base station. Therefore, the basestation does not need to acquire VLAN information.

– Scheme 4: The next-hop gateway of the base station or other NEs periodically sendpackets to the base station or an idle address of the subnet in which the base station is




29

deployed. This enables the next-hop gateway of the base station to send ARP packetsfrom which the base station derives VLAN information.

Scheme 1Scheme 1 applies to two scenarios:

l IPsec does not secure OMCH data. Figure 3-14 shows the procedure for a base station toobtain VLAN information in this scenario.

l IPsec secures OMCH data and NEs meet specific requirements. Figure 3-15 shows theprocedure for a base station to obtain VLAN information in this scenario.

Figure 3-14 Scheme 1 (IPsec does not secure OMCH data)

1. The U2000 or BSC sends an OMCH establishment request to the OM IP address of thebase station.

2. To forward the OMCH establishment request to the correct base station, the next-hopgateway of the base station broadcasts ARP packets to obtain the MAC address mappingthe destination IP address of the request. The next-hop gateway or the L2 network attachesVLAN IDs to ARP packets so that correct VLAN IDs are contained in the ARP packetsreceived by the base station.

3. The base station parses all received ARP packets and records the VLAN IDs contained inthe packets.

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 that installed on the next-hop gateway of the DHCP client.




30

Figure 3-15 Scheme 1 (IPsec secures OMCH data)

1. The U2000 or BSC sends an OMCH establishment request to the OM IP address of thebase station. The request is forwarded to the SeGW.

2. The SeGW detects that the IPsec SA with the base station has not been established andsends 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 gatewayof the base station broadcasts ARP packets to obtain the MAC address mapping thedestination IP address of the request. The next-hop gateway or the L2 network attachesVLAN IDs to ARP packets so that correct VLAN IDs are contained in the ARP packetsreceived by the base station.

4. The base station parses all received ARP packets and records the VLAN IDs contained inthe packets. It may record the VLAN ID in an ARP packet destined for another base station.

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

Scheme 2Figure 3-16 shows the procedure for a base station to obtain VLAN information in scheme 2.

Figure 3-16 Scheme 2




31

1. The U2000 sends a DHCPOFFER packet with no content to the interface IP address of thebase 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 ofthe base station broadcasts ARP packets to obtain the MAC address mapping the destinationIP address of the request. The next-hop gateway or the L2 network attaches VLAN IDs toARP packets so that correct VLAN IDs are contained in the ARP packets received by thebase station.





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 IDis the same as the VLAN ID required for deploying the base station. With the correct VLANID, the DHCP packet can be forwarded over the L2 network to the DHCP relay agent andthen reach the DHCP server.





32


1. The next-hop gateway periodically sends ping packets to the interface IP address of thebase 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 stationbroadcasts 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 stationcarry correct VLAN IDs.



Enabling and Disabling the VLAN Scanning FunctionIn SRAN7.0, the VLAN scanning function is provided for eNodeBs to solve the problem thatbase stations cannot acquire VLAN IDs in secure networking scenarios. After the VLANscanning function is enabled, the base station tries to send DHCP packets with random VLANIDs if it does not receive a response after sending DHCP packets without a VLAN ID and DHCPpackets with acquired VLAN IDs.

After the VLAN scanning function is enabled, some DHCP packets with invalid VLAN IDsmay be broadcast. In scenarios where different VLANs are not isolated, VLAN scanning imposesgreat impacts on the network. Therefore, this function is disabled for base stations of SRAN8.0or 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.

Here are a few example MML commands:

//Enabling the VLAN scanning functionSET DHCPSW: SWITCH=ENABLE; VLANSCANSW=ENABLE;




33

//Disabling the VLAN scanning functionSET DHCPSW: SWITCH=ENABLE; VLANSCANSW=DISABLE;

NOTE

When the OMCH and service channels are disconnected, the SET DHCPSW command is used todetermine whether to start the DHCP procedure automatically to obtain the initial configuration informationor to restore the base station configuration. The SWITCH parameter indicates whether to enable thefunction of starting the DHCP procedure automatically. The VLANSCANSW parameter indicates whetherto 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 besaved. Upon receiving a DHCP-ACK message, the base station saves VLAN IDs that are usedfor 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 theearliest VLAN ID.

The base station can use the saved and learned VLAN IDs to send DHCP packets whenreinitiating 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-modeBase Station and Co-MPT Multimode Base Station

3.3.1 OverviewThis chapter describes the automatic OMCH establishment procedures implemented by thesingle-mode base station and co-MPT multimode base station in IPsec or non-IPsec networkingscenarios, and the procedures' requirements for NEs. In IPsec networking scenarios, the networkis divided into the untrusted domain and the trusted domain. Depending on NE distribution inthe untrusted domain and the trusted domain, IPsec networking scenarios are classified asfollows:

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, signaling data, all or some of the other data, but notOMCH data or DHCP packets.

Automatic OMCH establishment may fail if the peer equipment is not ready or the configurationof the base station, transmission equipment, or peer equipment is incorrect. In this case, the basestation initiates another DHCP procedure to obtain the configuration and then starts automaticOMCH establishment again.

3.3.2 Automatic OMCH Establishment in Non-IPsec NetworkingScenarios




34

Introduction to Non-IPsec Networking

Figure 3-19 shows a non-IPsec networking scenario in which IPsec does not secure OMCHdata.

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

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




35

1. After a base station commissioning task by PnP task is created on the U2000, the U2000periodically sends an SSL-based or plaintext-based OMCH establishment request to thebase 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 addressis the IP address of the U2000 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, itbroadcasts ARP packets to the base station to obtain the MAC address mapping the interfaceIP address of the base station.

NOTE

l The next-hop gateway of the base station broadcasts ARP packets each time it receives a TCPconnection request sent periodically by the U2000.

l If the Use SSL option on the U2000 is selected, the U2000 periodically sends an SSL-basedOMCH establishment request to the base station. For the automatic OMCH establishmentprocedure in this scenario, see the "SSL Authentication on the OMCH" section.

If this option is not selected, the U2000 periodically sends a plaintext-based OMCH establishmentrequest to the base station.

l During a DHCP procedure, a DHCP response packet sent by the U2000 contains the target RATfor the base station. Upon detecting an inconsistency between the current and target RATs, thebase station changes its current RAT and then restarts. Afterwards, the base station reinitiates aDHCP procedure.

2. The base station obtains VLAN information. For details, see section "3.2.8 Schemes forObtaining VLAN Information for DHCP Packets."

3. The base station first sends DHCP packets with no VLAN ID and then DHCP packets withVLAN 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. The base station responds to the OMCH establishment request from the U2000 or BSC andthen establishes an OMCH to the U2000 or BSC.

NOTE

If the OMCH fails to be established, the base station automatically restarts the automatic OMCH establishmentprocedure.

Configuration Requirements for the DHCP ServerThe DHCP server of a base station must be configured with the following: A route to the IPaddress of the DHCP relay agent. Parameters to be used during the DHCP procedure. Theseparameters are contained in the DHCP packet headers, Option fields defined by RFC 2132, andsubcodes of Option 43 defined by Huawei. Table 3-5 lists the parameters to be contained in theDHCP packet headers. Table 3-6 describes common Option fields. Table 3-7 provides subcodeinformation in the Option 43 field.




36

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

ParameterName

MappingDHCPField

Length(Bytes)

ParameterDescription

Mandatoryor Optional

DHCPPacketInvolved

Interface IPAddress

yiaddr 4 Interface IPaddress ofthe basestation

Mandatory DHCPOFFERDHCPACK

Relay AgentIP

giaddr 4 IP address ofthe DHCPrelay agentdeployed onthe network,if any.Broadcastpackets(Discoveryand Requestpackets) sentby the basestation do notcarry this IPaddress, andthe DHCPrelay agentadds this IPaddress toDHCPpackets to beforwarded.For details,see RFC2131.

Optional DHCPDISCOVERYDHCPOFFERDHCPREQUESTDHCPACK

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

Parameter Name

MappingDHCPOption

Length(Bytes)


Mandatory orOptional

DHCP PacketInvolved

SubnetMask

1 4 Subnet mask of aDHCP client





37

Parameter Name

MappingDHCPOption

Length(Bytes)



DHCP PacketInvolved

RouterOption

3 N*4 List of the IP addressesof routers deployed in aDHCP client's subnetN indicates the numberof next-hop gatewaysfor the DHCP client.


VendorSpecificInformation

43 0-255 Vendor-specificinformation exchangedbetween a DHCP clientand a DHCP server

Mandatory DHCPDISCOVERDHCPREQUESTDHCPOFFERDHCPACK

IPAddressLeaseTime

51 4 Lease time of anassigned IP address


DHCPMessageType

53 1 Value: 1:DHCPDISCOVER2: DHCPOFFER3: DHCPREQUEST5: DHCPACK

Mandatory DHCPDISCOVERDHCPREQUESTDHCPOFFERDHCPACK

ServerIdentifier

54 4 IP address of a DHCPserver

Mandatory DHCPOFFERDHCPACKREQUEST

Renewal(T1) TimeValue

58 4 Interval from addressassignment to thetransition to theRENEWING state

Optional DHCPOFFERDHCPACK

Rebinding(T2) TimeValue

59 4 Interval from addressassignment to thetransition to theREBINDING state

Optional DHCPOFFERDHCPACK




38

Parameter Name

MappingDHCPOption

Length(Bytes)



DHCP PacketInvolved

Vendorclassidentifier

60 0-255 Vendor type and clientconfiguration

Optional DHCPDISCOVERDHCPREQUEST

Client-identifier

61 0-255 Unique identifier of aDHCP client

Optional DHCPDISCOVERDHCPREQUEST

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

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

ESN 1 20 ESN of theBBUbackplane. Itis used by aDHCP serverto determinethe locationand BBUsubrack ofthe basestation.

Mandatory DHCPDISCOVERDHCPOFFERDHCPREQUESTDHCPACK




39

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

DHCPServer ID

50 1 Whether theDHCPpackets aresent by theU2000DHCPserver. TheU2000DHCP serverfills in thisfield whensending theDHCPpackets. Ifthe DHCPpackets arenot sent bythe U2000DHCPserver, thisfield is leftblank.

Mandatorywhen theU2000serves as theDHCPserver. Thisfield is leftblank when adevice otherthan theU2000serves as theDHCPserver.

DHCPOFFERDHCPACK

MPT 1st SlotNumber

251 1 Slot numberof the firstmain controlboard


MPT 2ndSlot Number

249 1 Slot numberof the secondmain controlboard

Optional.Mandatoryonly if thebase stationis configuredwith active/standby orprimary/secondarymain controlboards.

DHCPOFFERDHCPACK




40

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

DID 27 1 to 64 If the basestation isconfiguredwith onlyone BBU, theDID servesthe samepurpose asthe ESN.If the basestation isconfiguredwith multipleBBUs thatareinterconnected, theseBBUs usethe sameDID.

Optional.DID ismandatory ifit is used asthe basestationidentification in DHCPpackets.

DHCPDISCOVERDHCPOFFERDHCPREQUESTDHCPACK




41

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

SubrackTopo

246 1 to 16 Interconnectionrelationshipbetween theBBUaccommodating the maincontrol boardthat sends theDHCPpackets andother BBUsif theseBBUs areinterconnected. TheDHCP serveruses thecombinationof the DID,subracktopology,and slotnumber toidentify theconfiguration file of thebase station.





42

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

OM BearingBoard

250 1 Value:l 0: An

OMCH isestablished on thepanel.Use thisvalue forsingle-modebasestations.

l 1: AnOMCH isestablished on thebackplane.

Optional.The defaultvalue is 0.

DHCPOFFERDHCPACK




43

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

OMInterfaceType

2 1 Transmission interface ofthe basestation:Ethernet orE1.NOTE

If anEthernetinterface isused as thetransmissioninterface, theOMCHmanagedobject (MO)inconfiguration files of thebase stationmust bebound to aroute, or thepeer IPaddress mustbe the IPaddress ofthe U2000 orthe next-hopgateway ofthe basestation.

OptionalThe defaultvalue isEthernet.

DHCPOFFERDHCPACK




44

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

OMInterfaceSlot Number

248 1 Slot numberof the maincontrol boardif thetransmissioninterface isprovided bythe maincontrolboard, or theslot numberof the UTRPboard if thetransmissioninterface isprovided bythe UTRPboard.

Mandatoryin SRAN8.0or later onlyif an Ethernetinterface isused as thetransmissioninterface.If thisparameter isnotspecified, thebase stationautomatically identifiesthe slotnumber.

DHCPOFFERDHCPACK

OMCHInterfacePort Number

247 1 Port numberof thetransmissioninterface ofthe basestation

Optional.Mandatoryin SRAN8.0or later onlyif an Ethernetinterface isused as thetransmissioninterface.If thisparameter isnotspecified, thebase stationautomatically identifiesthe portnumber.

DHCPOFFERDHCPACK




45

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

OMLOCATION

51 2 The numbersof thecabinet, andsubrack thataccommodate the maincontrol boardwhere theOMCH islocated.

Optional.Mandatoryin SRAN8.0or later onlyif an Ethernetinterface isused as thetransmissioninterface. Ifthisparameter isnotspecified, thebase stationautomatically identifiesthe numbersof thecabinet, andsubrack.

DHCPOFFERDHCPACK

OM IPAddress

3 4 Local IPaddress ofthe OMCH


OM IPAddressSubnet Mask

4 4 Local IPaddress maskof theOMCH


U2000 IPAddress

5 4 Peer IPaddress ofthe OMCH


U2000 IPSubnet Mask

6 4 Peer IPaddress maskof theOMCH





46

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

OM Vlan ID 11 2 VLAN ID ofthe OMCH

Thisparameter ismandatory ifVLAN isconfiguredon theEthernet portof the basestation.

DHCPOFFERDHCPACK

OM VlanPriority

12 1 VLANpriority ofthe OMCH

Thisparameter isnot includedin DHCPpacketswhen an E1/T1 port isused as thetransmissionport.

DHCPOFFERDHCPACK

IP address ofthe BSC

13 4 IP address ofthe BSC

Mandatoryfor the GSMmode

DHCPOFFERDHCPACK

OM NextHop IPAddress

17 4 Next-hop IPaddress ofthe basestation


GBTSOMCHDSCP

54 1 DSCP usedby the GBTSto establishan OMCH.

OptionalThisparameter issupportedonly byGBTSs fromSRAN7.0onwards. Ifthisparameter isnotspecified, theDSCPsubcode willnot bedelivered.

DHCPOFFERDHCPACK




47

When creating a base station commissioning by PnP task on the U2000, deployment engineerscan import configuration information listed in Table 3-7 into the DHCP server Deploymentengineers can manually modify the configuration information for the DHCP server only on theU2000 GUI. Deployment may fail if the DHCP server is not configured with mandatoryparameters listed in Table 3-7 or optional parameters that must be configured in certainscenarios.

SSL Authentication on the OMCHIf an OMCH uses SSL authentication, the base station must obtain an operator-issued devicecertificate before establishing the OMCH with the U2000. Figure 3-21 shows the automaticOMCH establishment procedure in this scenario.

Figure 3-21 Automatic OMCH establishment procedure

1. After a PnP-based commissioning task is created on the U2000, the U2000 periodicallysends SSL-based OMCH establishment requests to the base station.The source and destination IP addresses of the request packets are the IP address of theU2000 and the O&M IP address of the base station, respectively.Upon receiving the requests, the next-hop gateway of the base station sends ARP broadcastpackets to the base station to parse the MAC address corresponding to the interface IPaddress of the base station.

2. The base station obtains VLAN information.For details, see section "3.2.8 Schemes for Obtaining VLAN Information for DHCPPackets."

3. The base station attempts to first send DHCP packets without VLAN IDs and then DHCPpackets with VLAN IDs. By exchanging the DHCP packets with the DHCP server, the basestation obtains OMCH configurations and makes them take effect.

4. Based on the CA information obtained from the DHCP server, the base station applies foran operator-issued device certificate from the CA. For details, see the "Obtaining anOperator-Issued Device Certificate" section.




48

5. In response to the OMCH establishment requests from the U2000, the base station performsmutual authentication with the U2000 using the obtained device certificate. After theauthentication is successful, an OMCH is established between them.

In this scenario, the U2000 DHCP server delivers configurations to the base station. Theconfigurations include those described in the "Configuration Requirements for the DHCPServer" section and CA information described in Table 3-8.

Table 3-8 Parameters specific to the U2000 DHCP server

ParameterCategory

ParameterName

Sub-code

Length (Bytes) ParameterDescription


DHCPPacket

CAinformation

CA URL 44 1 to 128 URL of the CAfrom which thebase stationobtains anoperator-issueddevice certificatein IPsecnetworkingscenariosThis URL must bereachable in theuntrusted domain.

Mandatory

l DHCPOFFER

l DHCPACK

CAName

38 1 to 127 CA name

Obtaining an Operator-Issued Device Certificate

After obtaining the interface IP address and CA information, the base station generates acertificate request file. The base station then uses this certificate request file to apply for anoperator-issued device certificate from the CA (obtained through the DHCP procedure) basedon 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 fromSRAN7.0 onwards). During the certification application, the base station provides the CA withHuawei-issued device certificates as its identity. The CA is also preconfigured with the Huaweiroot certificate.

Before the certificate application, the base station obtains from the DHCP server partialconfiguration data (such as the URL of the CA and the CA name) rather than the configurationfile. Therefore, the base station uses the default parameters described in Table 3-9 to completethe certificate application. The base station cannot contain parameters other than those listed inthe table during the certification application or in the certificate request files.




49

NOTE

For details about the certificate application procedure, see the "Certificate Management and ApplicationScenarios" part in PKI Feature Parameter Description for SingleRAN.

PKI redundancy is not supported during base station deployment by PnP. The active PKI server must workproperly during base station deployment by PnP.

Table 3-9 Default parameters used for certificate application

ParameterCategory

ParameterName

Parameter Description Remarks

CMPv2-relatedparameters

Source IP Source IP address used toapply for the operator-issued device certificate

This parameter is set to theinterface IP address of the basestation that is obtained through theDHCP procedure.

CA URLDuring SiteDeployment

URL of the CA This parameter is set to the URL ofthe CA that is obtained through theDHCP procedure.

SignatureAlgorithm

Signature algorithm forCMP messages

This parameter is set to SHA1.

Parameters inthecertificaterequestfile

Request Type Type of a certificate request.The request can be either anew certificate request or acertificate update request.The default type is newcertificate request.

This parameter is set to NEW.

CertificateRequest FileFormat

Format of a certificaterequest file

This parameter is set to CRMF.

Renew Key Whether to generate a newkey pair

This parameter is set to YES.

Key Size Length of a key This parameter is set toKEYSIZE2048.

CommonName

Common name of thecertificate request file

This parameter is set to theESN.huawei.com of the basestation that applies for a certificate.

Key Usage Usage of a key KEY_AGREEMENT (keynegotiation), DATA_ENCIPHER-MENT (data encryption),KEY_ENCIPHERMENT (keyencryption), andDIGITAL_SIGNATURE (digitalsignature) are selected for thisparameter.




50

ParameterCategory

ParameterName


SignatureAlgorithm

Signature algorithm for acertificate request file

This parameter is set to SHA256.NOTE

This parameter is set to SHA1 for abase station using an LMPT whoseversion is SRAN6.0 or earlier, and isset to SHA256 for a base station usingan LMPT whose version is SRAN7.0or later.

Local Name Local name of a basestation. This parameter isused to generate the DNSname of the subjectalternative name of acertificate, so as to verifythe peer's identification inIKE negotiation.

The value of this parameterconsists of the ESN of the basestation 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 IPaddress that the base station obtainsfrom the DHCP server, because the IPaddress obtained may not be usedfinally.

In addition to the operator-issued device certificate, the base station also obtains the rootcertificate of the CA.

If the application for operator-issued digital certificates fails or the base station receives noresponse within about 30 seconds, the preconfigured digital certificates are used for establishingan OMCH.

Configuration Requirements for NEsIntroduction to Non-IPsec Networking describes the configuration requirements for networkequipment during base station deployment by PnP (Introduction to Non-IPsec Networking isused as an example).




51

Table 3-10 Configuration requirements for network equipment

Network Equipment Requirement

L2 device l Allows the transmission of DHCPbroadcast and unicast packets withoutfiltering or modifying DHCP packets.

l Is configured with correct VLANinformation.

Next-hop gateway of the base station l Is enabled with the DHCP relay agentfunction and configured with the IPaddress of the DHCP server, that is, the IPaddress of the U2000. If an NAT server isdeployed, the IP address of the U2000must be that converted by the NAT server.

l Is configured with a route whosedestination IP address is the DHCP serverIP address

l If the base station's OM IP address is notits interface IP address, configure a routewhose destination IP address is the OM IPaddress of the base station.

l Is configured with a route whosedestination IP address is the IP address ofthe CA if the OMCH uses SSLauthentication.

L3 device l Is configured with a route whosedestination IP address is the OM IPaddress of the base station or the U2000IP address.

l Is configured with a route whosedestination IP address is the DHCP relayagent IP address.

l Is configured with a route whosedestination IP address is the CACA if theOMCH uses SSL authentication.

U2000/BSC Is configured with a route whose destinationIP address is the OM IP address of the basestation.

DHCP server Is configured with a route whose destinationIP address is the DHCP relay agent IPaddress.




52


FTP server l Is configured with a route whosedestination IP address is the OM IPaddress of the base station.

l Stores software and configuration files ofthe base station in the specified directory.

l Provides access rights, such as the username and password, for the base station.

CA(Required only when the OMCH uses SSLauthentication)

l Is configured with the IP address that canbe accessed by NEs in the untrusteddomain.

l Is configured with Huawei-issued CAroot certificates.

3.3.3 Automatic OMCH Establishment in IPsec NetworkingScenario 1

Introduction to IPsec Networking Scenario 1

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

Figure 3-22 IPsec networking scenario 1


l A public DHCP server and an U2000 DHCP server are deployed in the untrusted domainand the trusted domain, respectively. The base station obtains from the public DHCP serverthe transmission configuration information required for establishing a temporary IPsectunnel to the SeGW and obtains from the U2000 DHCP server the formal transmissionconfiguration information.




53

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 SeGWbefore being transmitted to the U2000 or BSC in the trusted domain.

l A CA is deployed. During base station deployment, the CA is accessible through IPaddresses of NEs in the untrusted domain (for example, the interface IP address of the basestation).

l After the base station starts, it must apply to the CA for operator-issued digital certificatesbefore connecting to the SeGW. After obtaining the certificates, the base station negotiateswith the SeGW to establish an IPsec tunnel.

Automatic OMCH Establishment Procedure

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 Temporary interface IP address used for accessing NEs in the untrusted domain.

l Configuration information used for establishing a temporary IPsec tunnel to the SeGW.The configuration information includes the SeGW configuration data and the CAconfiguration data.

2. The base station obtains digital certificates from the CA.

3. After establishing the temporary IPsec tunnel, the base station obtains the formal interfaceIP address and other OMCH configuration data from the U2000 DHCP server and thenestablishes a formal IPsec tunnel. The obtained information is used for accessing NEs inthe trusted domain and referred to as formal transmission configuration information in thisdocument.

The interface IP address obtained from the public DHCP server can be the same as or differentfrom that obtained from the U2000 DHCP server.

Figure 3-23 shows the automatic OMCH establishment procedure in IPsec networking scenario1.

Figure 3-23 Automatic OMCH establishment procedure in IPsec networking scenario 1




54


2. Using the DHCP procedure, the base station obtains from the public DHCP server thetransmission configuration information used for establishing a temporary IPsec tunnel. Theinformation includes the interface IP address of the base station, CA configuration data,SeGW configuration data, and U2000 DHCP server IP address. For details about theconfiguration information on the public DHCP server, see section "ConfigurationRequirements for the DHCP Server."

3. Using CMPv2, the base station applies to the CA for an operator-issued device certificate.(For details about the certificate application procedure, see the "Obtaining an Operator-Issued Device Certificate" section.) The base station then adds the obtained certificate tothe default trusted certificate list for subsequent IPsec tunnel establishment and SSLauthentication.

4. The base station establishes a temporary IPsec tunnel to the SeGW. For details about thesecurity parameters used by the base station during the temporary IPsec tunnelestablishment, see section "Establishing a Temporary IPsec Tunnel."

5. With protection from the temporary IPsec tunnel, the base station obtains formaltransmission configuration information from the U2000 DHCP server in different ways,depending on whether the IP address used for accessing the trusted domain and the U2000DHCP server IP address are available. For details, see section "Obtaining FormalTransmission Configuration Information from the Internal DHCP Server."

6. The base station releases the temporary IPsec tunnel and uses formal transmissionconfiguration information to establish a formal IPsec tunnel to the SeGW. For details, seesection "Establishing a Temporary IPsec Tunnel."

7. After the formal IPsec tunnel is established, the base station waits for the OMCHestablishment request from the U2000/BSC and then establishes an OMCH to the U2000/BSC. If an OMCH is not established between the U2000/BSC and base station within 10minutes, the base station restarts the automatic OMCH establishment procedure. Becausethe base station has obtained the operator-issued device certificate, SSL authentication issupported between the U2000 and base station.

NOTE

During a DHCP procedure, a DHCP response packet sent by the U2000 contains the target RAT forthe base station. Upon detecting an inconsistency between the current and target RATs, the basestation changes its current RAT and then restarts. Afterwards, the base station reinitiates a DHCPprocedure.

If any steps except step 1 fail during the automatic OMCH establishment procedure, the base stationautomatically restarts the automatic OMCH establishment procedure.

IPsec Redundancy Among Multiple SeGWs is not supported during base station deployment by PnPwhen multiple SeGWs are configured. The active SeGW must work properly during base stationdeployment by PnP.

Configuration Requirements for the Public DHCP ServerThe public DHCP server must be configured with the parameters listed in Table 3-11 as wellas a route whose destination IP address is the IP address of the base station or whose destinationnetwork segment is the network segment of the base station. Unless otherwise specified, theseparameters are contained in subcodes of Option 43 in DHCP packets.




55

Table 3-11 Parameters to be configured on the public DHCP server

Classification

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

CAinformation

PKISERVER IP

35 4 IP address of the CA Mandatory only ifidentityauthentication bydigitalcertificates isrequiredand theCA URLis notconfigured.

Theseparameterscollectively identifyand equalthe URLof the CA.

Thesefourparameters cannotbeconfigured if the CAURL hasbeenconfigured.

l DHCPOFFER

l DHCPACK

CAprotocol type

39 1 Protocol used toaccess the CA: HTTPor HTTPSValue 0 indicatesHTTP and value 1indicates HTTPS.When thecommunicationbetween the basestation and CA isprotected by SSL, thisparameter must be setto 1.

l DHCPOFFER

l DHCPACK

CAport

36 2 HTTP or HTTPS portnumber of the CA

l DHCPOFFE

l DHCPACK

CAPath

37 1 to60

Path for saving digitalcertificates on the CA.This parameter isoptional if no path isrequired for accessingthe CA.

l DHCPOFFE

l DHCPACK




56

Classification

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

CAURL

44 1 to128

URL used foraccessing the digitalcertificate path.This parameter isconfigurable onlywhen the base stationand CA use CMPv2.The CA URL formatis as follows: http(s)://CAIP:CAport/CAPath

Mandatory only ifthefollowingparameters are notconfigured whenauthentication bydigitalcertificates isrequired:PKISERVERIP, CAprotocoltype, CAport, andCA Path.

l DHCPOFFE

l DHCPACK

CAName

38 1 to127

CA name Mandatory only ifthe basestationuses thedigitalcertificates foridentityauthentication

l DHCPOFFE

l DHCPACK

SeGWinformation

PublicSeGWIPAddress

18 4 IP address of thepublic SeGW in IPsecnetworking scenarios.This parameter isallocated by thepublic DHCP serverand used duringDHCP interworkingbetween the basestation and the U2000DHCP server.

Mandatory only ifthe basestationneeds toaccess theU2000DHCPserverthroughthe SeGW

l DHCPOFFE

l DHCPACK




57

Classification

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

PublicSeGWLocalName

31 1 to32

Local name of thepublic SeGW.It is used by the basestation to authenticatethe public SeGW inIPsec networkingscenarios.

Optionalwhen theSeGW isconfigured

l DHCPOFFE

l DHCPACK

InternalDHCPserver IPaddress(list)

Internal DHCPServerIPAddress (List)

42 N*4 IP address of theU2000 DHCP serverthat sendstransmissionconfigurationinformation to thebase station.In SRAN8.0 and laterversions, a maximumof eight U2000 DHCPserver addresses canbe configured.N indicates thenumber of DHCPservers built into theU2000.

Optional.If thisparameterisconfigured, the basestationcan sendunicastDHCPpackets tothe DHCPservereven if theSeGWcannotsend anyDHCPserver IPaddress tothe basestation.

l DHCPOFFE

l DHCPACK

Transmissionconfigurationinformation for thebasestation

Interface IPAddress

- 4 Carried in the yiaddrfield in DHCP packetheaders

Mandatory

l DHCPOFFE

l DHCPACK

Interface IPAddress mask

- 4 Carried in DHCPoption 1

Mandatory

l DHCPOFFE

l DHCPACK




58

Classification

ParameterName

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

Next-hopGateway IPAddress

- 4 Carried in DHCPoption 3

Mandatory

l DHCPOFFE

l DHCPACK

All IP addresses or URLs listed in Table 3-11 except Internal DHCP Server IP Address(List) can be used only in the untrusted domain. Particularly, NEs in the untrusted domain musthave access to the CA IP address and the CA URL. If the base station cannot access the CA, itcannot obtain any operator-issued certificate.

NOTE

In IPsec networking scenario 1, the public DHCP server assigns an interface IP address in the IP addresspool to the base station, without parsing the BS ID contained in Option 43. Therefore, the BS ID containedin DHCP packets is meaningless in such a scenario.

Obtaining an Operator-Issued Device CertificateThe base station generates a certificate request file after it obtains a temporary IP address andCA 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 partialconfiguration data (such as the URL of the CA and the CA name) rather than the configurationfile. The default parameters for certificate application are the same as those listed in Table3-9 except for those listed in Table 3-12.

Table 3-12 Default parameters used for certificate application

ParameterCategory

ParameterName


CMPv2-relatedparameters

CA URLDuring SiteDeployment

URL of the CA This parameter is set to the URL ofthe CA configured on the publicDHCP server, or to a combinationof CA Protocol, CAIP, CA Path,and CA Port.NOTE

CA Path is optional. Whether it isrequired depends on the relative pathof the CA in which CMPv2 servicesare provided for the base station.




59

In addition to the operator-issued device certificate, the base station also obtains the rootcertificate of the CA. The base station then uses both certificates to perform mutualauthentication 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 accessesthe internal DHCP server and the U2000 in the trusted domain.

Establishing a Temporary IPsec TunnelAfter the base station obtains the transmission configuration information (including its interfaceIP address, the SeGW IP address, and the CA IP address) from the public DHCP server, the basestation obtains digital certificates from the CA and attempts to establish a temporary IPsec tunnelto the SeGW. For details about the temporary IPsec tunnel establishment, see IPsec FeatureParameter Description. This section describes the IPsec and IKE proposal algorithms used bythe base station during deployment by PnP.

IKEv1 and IKEv2 are incompatible. During base station deployment by PnP, the base stationcannot predict the IKE version used by the SeGW. If the base station successfully negotiated anIKE version with the SeGW, the base station preferentially tries this IKE version. Otherwise,the base station tries IKEv2 before IKEv1.

IKE SA NegotiationDuring IKE SA negotiation in the normal operation of the base station, the base station supportsa large number of algorithm groups. However, during base station deployment by PnP, the basestation only supports the 48 algorithm groups (see Table 3-13) in the IKEv2 proposal and the120 algorithm groups (see Table 3-14) in the IKEv1 proposal.

NOTE

The number of algorithm groups in the IKEv2 proposal is calculated as follows: Encryption Algorithm hasfour values, Authentication Algorithm has two values, Diffie-Hellman Group has three values, and PRFAlgorithm has two values. Therefore, the number of algorithm groups in the IKEv2 proposal is 48 (4 x 2x 3 x 2).

The number of algorithm groups in the IKEv1 proposal is calculated in the same way as that inthe IKEv2 proposal.

Table 3-13 Algorithms in the IKEv2 proposal

EncryptionAlgorithm

AuthenticationAlgorithm

Diffie-HellmanGroup

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




60

Table 3-14 Algorithms in the IKEv1 proposal

EncryptionAlgorithm

AuthenticationAlgorithm

Diffie-HellmanGroup

AuthenticationMethod(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 algorithmgroups listed in Table 3-14 in sequence. If this fails, the base station tries the other groups untilit establishes an IPsec tunnel. If all the supported algorithm groups fail, the base station obtainstransmission configuration from the public DHCP server again to set up a temporary IPsec tunneland then restarts an IKE SA negotiation.

IKEv2 proposal algorithms should be configured in the sequence shown in Table 3-15.Otherwise, the IKEv2 negotiation may fail. To increase the deployment success rate and shortenthe deployment duration, it is recommended that IKEv2 proposal algorithms in configurationfiles of the base station follow the configurations listed in Table 3-15.

Table 3-15 First five algorithms groups in the IKEv2 proposal

Sequence EncryptionAlgorithm

Authentication Algorithm

Diffie-HellmanGroup

PRFAlgorithm(Only IKEv2)

1 AES128 SHA1 DH-Group2 HMAC-SHA1

2 3DES SHA1 DH-Group2 HMAC-SHA1

3 AES256 AES_XCBC_96

DH_GROUP15 AES128_XCBC

4 AES192 SHA1 DH_GROUP14 HMAC_SHA1

5 AES128 SHA1 DH_GROUP14 HMAC_SHA1

NOTE

During base station deployment by PnP, the IDTYPE parameter in the IKEPEER MO is set to FQDN bydefault and the base station uses SubjectAltName in the digital certificate as the local name of the basestation for IKE negotiation.




61

IPsec SA Negotiation

During IPsec SA negotiation in the normal operation of the base station, the base station supportsESP and AH authentication in tunnel or transport mode. However, during base stationdeployment 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 supportsmultiple IPsec proposal algorithm groups. However, during base station deployment by PnP,the base station supports only the encryption and authentication algorithm groups listed in Figure3-24. It first tries the six algorithm groups marked in green. If this fails, it tries the six algorithmgroups marked in gray. Once IKE negotiation is successful using an algorithm group, the basestation 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

NOTE

During base station deployment by PnP, the base station does not try all supported IPsec and IKE proposalalgorithms (such as the DES algorithm) when establishing an IPsec tunnel. This is because trying allsupported 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 asthe encapsulation mode when establishing an IPsec tunnel. This is because the U2000, BSC, DHCP server,and FTP server do not support IPsec.

During base station deployment by PnP, the base station does not try the perfect forward secrecy (PFS).

If the IPsec and IKE proposal algorithms and their settings on the base station or SeGW side areinconsistent with those tried during base station deployment by PnP, OMCH establishment mayfail, leading to deployment failures. Therefore, ensure there is consistency between theparameters and settings.

Configuration Requirements for the Internal DHCP Server

The U2000 DHCP server must be configured with the parameters listed in Table 3-7 as well asthe parameters listed in Table 3-16. These parameters are contained in Option 43 in DHCPpackets.




62

Table 3-16 Parameters specific to the U2000 DHCP server in IPsec networking scenario 1

Classification

Parameter Name

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

SeGWinformation

ServingSeGW IP

20 4 IP addressof theservingSeGW inIPsecnetworking scenarios

Mandatory

DHCPOFFER

DHCPACK

ServingSeGWLocalName

32 1 to 32 Localname ofthe servingSeGW. Itis providedby the basestation toauthenticate theservingSeGW inIPsecnetworking scenarios

Optional

CAinformation

CA URL 44 1 to 128 URL of theCA fromwhich thebasestationobtains anoperator-issueddevicecertificatein IPsecnetworking scenarios

Mandatory

DHCPOFFERDHCPACK

CA Name 38 1 to 127 CA name

Obtaining Formal Transmission Configuration Information from the InternalDHCP Server

RFC 4306, the standard protocol for IKEv2, defines the MODE-CONFIG mode in which thebase station uses the configuration payload (CP) to apply to the SeGW for certain configuration




63

information. Using the MODE-CONFIG mode during IKE negotiation, the base station canobtain one temporary logical IP address used for accessing the trusted domain and one U2000DHCP server IP address. The base station can obtain one U2000 DHCP server IP address atmost.

NOTE

In IKEv1, CP is not standardized and is referred to as MODE-CONFIG, which is supported only by thebase station in aggressive mode. For details about the MODE-CONFIG, see RFC4306 Internet KeyExchange (IKEv2) Protocol.

The base station follows procedures listed in Table 3-17 to obtain formal transmissionconfiguration information from the U2000 DHCP server, depending on whether the logical IPaddress used for accessing the untrusted domain and any U2000 DHCP server IP address areavailable.

Table 3-17 Obtaining formal transmission configuration information from the U2000 DHCPserver

If... Then... ConfigurationRequirements for NEs

The base station has obtainedthe interface IP address,logical IP address, andU2000 DHCP server IPaddress.NOTE

The base station obtains thepreceding IP addresses indifferent ways: Interface IPaddress: from the DHCPprocedure Logical IP address:from MODE-CONFIG modeduring IKE negotiation U2000DHCP server IP address: fromthe DHCP procedure or fromMODE-CONFIG mode duringIKE negotiation

l The base station uses thelogical IP address foraccessing the trusteddomain as the source IPaddress, and uses anyU2000 DHCP server IPaddress as the destinationIP address. The basestation then unicastsDHCP packets to eachU2000 DHCP server.Only the U2000 DHCPserver that has the correctBS ID sendsconfigurationinformation to the basestation.

l The base stationautomatically configuresan access control list(ACL) rule in Any to Anymode that allows DHCPpackets to reach the basestation.

See Table 3-18.




64


The base station has obtainedthe interface IP address andU2000 DHCP server IPaddress, but not the logical IPaddress.

l The base station uses theinterface IP address foraccessing the untrusteddomain as the source IPaddress, and uses anyU2000 DHCP server IPaddress as the destinationIP address. The basestation then unicastsDHCP packets to eachU2000 DHCP server.Only the U2000 DHCPserver that has the correctBS ID sendsconfigurationinformation to the basestation.

l The base stationautomatically configuresan ACL rule that allowsDHCP packets to reachthe base station. In theACL rule, the source IPaddress is the interface IPaddress and thedestination IP address isan U2000 DHCP serverIP address. If there aremultiple U2000 DHCPservers, one ACL rule isgenerated for eachconnected U2000 DHCPserver.

See Table 3-19.




65


The base station has notobtained the logical IPaddress for accessing thetrusted domain or any U2000DHCP server IP address.

l The base station uses0.0.0.0 as the source IPaddress and255.255.255.255 as thedestination IP address tobroadcast DHCP packetsover an IPsec tunnel. Thepackets are encapsulatedover the IPsec tunnelbefore reaching theSeGW.

l The base stationautomatically configuresan ACL rule that allowsDHCP packets to reachthe base station. In theACL rule, the sourceUDP port number is 68and the destination UDPport number is 67.

See Table 3-20.

Table 3-18 Configuration requirements for network equipment(1)

NE Requirement

Public DHCP server l Is configured with one to eight U2000DHCP server IP addresses only if theSeGW is not configured with any U2000DHCP server IP address.

l No preceding configuration is required ifthe SeGW is configured with a U2000DHCP server IP address.

l For detailed configurations, see Table3-11.




66

NE Requirement

SeGW l Supports the MODE-CONFIG mode sothat the SeGW sends a temporary logicalIP address and an U2000 DHCP server IPaddress to the base station. Alternatively,the SeGW sends a temporary logical IPaddress and the public DHCP server sendsan U2000 DHCP server IP address. It isrecommended that the operator plan alltemporary logical IP addresses foraccessing the trusted domain on the samenetwork segment and on a differentnetwork segment from the OM IP addressof the base station.

l Automatically generates an ACL rule inTemporary Logical IP to Any mode afterusing the MODE-CONFIG mode to sendthe U2000 DHCP server IP address. Thiseliminates the need to manually configureassociated ACL rules. If an ACL rule ismanually configured that the source IPaddress is the temporary logical IP addressfor accessing the trusted domain, the IPaddresses of all U2000 DHCP serversmust be on the network segment definedby this ACL rule.

All NEs between the base station and theU2000 DHCP server

l Is configured with the firewall policy orthe packet filtering policy so that theyallow the transmission of packets with 67or 68 as the source and destination UDPport number.

l Is configured with a route whosedestination IP address is the logical IPaddress for accessing the trusted domainor network segment of the logical IPaddress so that related packets can berouted to the SeGW.

U2000 DHCP server Is configured with a route whose destinationIP address is the logical IP address of the basestation.




67


NE Requirement

Public DHCP server Is configured with one to eight U2000 DHCPserver IP addresses.For detailed configurations, see Table 3-11.



l Is configured with a route whosedestination IP address is the interface IPaddress of the base station or the IPaddress of the network segment.

U2000 DHCP server Is configured with a route whose destinationIP address is the interface IP address of thebase station.


NE Requirement

Public DHCP server For detailed configurations, see Table 3-11,in which the IP address of the internal DHCPserver does not need to be configured.

SeGW Supports sending DHCP broadcast packets inIPsec tunnels, in compliance with RFC 3456.



l Is configured with a route whosedestination IP address is the IP address ofthe DHCP relay agent on the SeGW.

U2000 DHCP server Is configured with a route whose destinationIP address is the IP address of the DHCP relayagent on the SeGW.

The base station obtains transmission configuration information in IPsec networking scenariosdifferently from non-IPsec networking scenarios:




68

l The DHCP server can be deployed only on the U2000, not the base station controller. Thatis, the U2000 DHCP server is used.

l The base station may obtain IP addresses of many DHCP servers. Therefore, it needs tocommunicate with each DHCP server to find the correct DHCP server. IPsec securesOMCH data.

l Therefore, among the configuration information sent by the U2000 DHCP server to thebase 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 TunnelThe SeGW IP address obtained from the U2000 DHCP server may or may not be the same asthe SeGW IP address obtained from the public DHCP server. In either case, the base stationneeds to negotiate an IKE SA and an IPsec SA with the SeGW before establishing a formaltunnel to the SeGW. The SeGW is identified by the SeGW IP address in the configurationinformation from the U2000 DHCP server.

The procedure for establishing a formal IPsec tunnel differs from the procedure for establishinga temporary IPsec tunnel as follows:

l The base station uses the interface IP address delivered by the U2000 DHCP server andSeGW IP address delivered by the U2000 DHCP server for IKE SA and formal IPsecestablishment negotiations between the base station and SeGW. During IPsec tunnelestablishment, the base station automatically configures an ACL rule in OM IP to Anymode 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 IPsectunnel was successfully established to establish the formal IPsec tunnel. If this fails, thebase station follows the sequence described in the "Establishing a Temporary IPsecTunnel" to try other security parameters.

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

Configuration Requirements for Network EquipmentTable 3-21 lists the configuration requirements for NEs in IPsec networking scenario 1.

Table 3-21 Configuration requirements for NEs in IPsec networking scenario 1

NE Requirement

L2 device l Allows the transmission of DHCPbroadcast and unicast packets withoutfiltering or modifying DHCP packets.





69

NE Requirement

Next-hop gateway of the base station l Is configured as the DHCP server orenabled with the DHCP relay agent. Isconfigured with correct DHCP server IPaddresses.

l Is configured with routes whosedestination addresses are the DHCP serverIP address,

l CA IP address, and SeGW IP address,respectively.

L3 device l (NEs in the untrusted domain): Isconfigured with routes whose destinationaddresses are the temporary and formalinterface IP addresses of the base station,CA IP address, and SeGW IP address.

l (NEs in the trusted domain): Is configuredwith three routes whose destinationaddresses are the OM IP address of thebase station, U2000 IP address, and FTPserver IP address.

U2000 Is configured with a route whose destinationIP address is the OM IP address of the basestation.

U2000 DHCP server Is configured with a route whose destinationIP address is that of the DHCP relay agentwhen the SeGW serves as the DHCP relayagent. If the SeGW does not serve as theDHCP relay agent, the U2000 DHCP serveris configured with a route whose destinationIP address is the temporary interface IPaddress of the base station.

FTP server l Is configured with a route whosedestination IP address is the OM IPaddress of the base station.

l Stores software and configuration files ofthe base station in the specified directory.

l Provides access rights, such as the username and password, for the base station.




70

NE Requirement

SeGW l Allows DHCP packets to be exchangedbetween the base station and the U2000.

l Allows packets to be exchanged betweenthe base station and the U2000 over anOMCH and between the base station andthe FTP server.

l Is configured with security parameterslisted in Table 3-12.

l Is configured with ACL rules that allowthe transmission of packets sent from thebase station during the DHCP procedure.

l Is configured with an ACL rule in Any toAny or Any to OM IP mode.

l Is enabled with the DHCP relay agentfunction if the SeGW complies with RFC3456.

l Is configured with related IP address pooland assignment rules if the SeGW needsto assign an IP address for accessing thetrusted domain or a DHCP server IPaddress to the base station.

l Is configured with operator-issued CAcertificates and its own certificates.

CA l Is configured with the IP address that canbe accessed by NEs in the untrusteddomain.



Introduction to IPsec Networking Scenario 2Figure 3-25 shows IPsec networking scenario 2, in which IPsec secures all packets except DHCPpackets.




71



l An U2000 DHCP server in the trusted domain is deployed. IPsec does not secure DHCPpackets. Using a DHCP procedure in the untrusted domain, the base station obtains itstemporary IP address and the OM IP address, the SeGW IP address, and the CA IP address.From the U2000 DHCP server, the base station obtains the formal transmissionconfiguration information.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 SeGWbefore being transmitted to the U2000 or BSC in the trusted domain.

l A CA is deployed and provides digital certificates for the base station to perform mutualauthentication with other NEs. During base station deployment, the CA can be accessedby NEs' IP addresses in the untrusted domain.

l After the base station starts, it must apply to the CA for operator-issued digital certificatesbefore connecting to the SeGW.

Automatic OMCH Establishment ProcedureIn IPsec networking scenario 2, the base station must obtain the base station IP address and CAIP address from the U2000 DHCP server, and then obtain digital certificates from the CA.

Figure 3-26 shows the automatic OMCH establishment procedure in IPsec networking scenario2.




72



2. The base station obtains required configuration information from the U2000 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

During a DHCP procedure, a DHCP response packet sent by the U2000 contains the target RAT forthe base station. Upon detecting an inconsistency between the current and target RATs, the basestation changes its current RAT and then restarts. Afterwards, the base station reinitiates a DHCPprocedure.

3. By using the configuration information obtained from the U2000 DHCP server, the basestation applies to the CA for an operator-issued device certificate. (For details about thecertificate application procedure, see the "Obtaining an Operator-Issued DeviceCertificate" section.) The base station then adds the obtained certificate to the defaulttrusted certificate list for subsequent IPsec tunnel establishment and SSL authentication.

4. By using the configuration information obtained from the U2000 DHCP server, the basestation establishes a formal IPsec tunnel to the SeGW.

5. After the formal IPsec tunnel is established, the base station waits for the OMCHestablishment request from the U2000/BSC and then establishes an OMCH to the U2000/BSC. Because the base station has obtained the operator-issued device certificate, SSLauthentication is supported between the U2000 and base station.

NOTE

If an IPsec tunnel or OMCH fails to be established, the base station automatically restarts the automatic OMCHestablishment procedure.

IPsec Redundancy Among Multiple SeGWs is not supported during base station deployment by PnP whenmultiple SeGWs are configured. The active SeGW must work properly during base station deployment by PnP.

Configuration Requirements for the Internal DHCP Server

The U2000 DHCP server must be configured with the parameters listed in Table 3-7 as well asthe parameters listed in Table 3-22. These parameters are contained in subcodes of Option 43in DHCP packets.




73


Classification

Parameter Name

MappingSubcode

Length(Bytes)



DHCPPacketInvolved

SeGWinformation

ServingSeGW IP

20 4 IP addressof theSeGW inIPsecnetworking scenarios

Mandatory

DHCPOFFER

DHCPACK

ServingSeGWLocalName

32 1-32 Localname ofthe servingSeGW. Itis providedby the basestation toauthenticate theservingSeGW inIPsecnetworking scenarios

CAinformation

CA URL 44 1-128 URL fromwhich thebasestationobtainsoperator-issueddigitalcertificates.This URLmust beaccessibleto NEs intheuntrusteddomain.

Mandatory

DHCPOFFERDHCPACK

CA Name 38 1-127 Name ofthe CA




74

Configuration Requirements for Network EquipmentTable 3-23 lists the configuration requirements for network equipment in IPsec networkingscenario 2.

Table 3-23 Configuration requirements for network equipment in IPsec networking scenario 2


L2 devices l Allow the transmission of DHCPbroadcast and unicast packets withoutfiltering or modifying DHCP packets.

l Are configured with correct VLANinformation.

Next-hop gateway of the base station l Is enabled with the DHCP relay agentfunction.

l Is configured with correct DHCP serverIP addresses.

L3 devices l (NEs in the untrusted domain): Areconfigured with routes to the interface IPaddresses of the base station and routes tothe CA and the SeGW.

l (NEs in the trusted domain): Areconfigured with a route whose destinationIP address is the OM IP address of the basestation and routes whose destination IPaddresses are that of the U2000 and of theFTP server.


U2000 DHCP server Is configured with a route whose destinationIP address is the DHCP relay agent IPaddress.

SeGW l Allows packets to be exchanged betweenthe base station and the U2000 over anOMCH and between the base station andthe FTP server.

l Is configured with security parameterslisted in Table 3-13, Table 3-14, andFigure 3-24.

l Is configured with an ACL rule in Any toAny or Any to OM IP mode.

l Is configured with operator-issued CAcertificates and its own certificates.




75


CA Is configured with the following:l An IP address that can be accessed by NEs

in the untrusted domainl Huawei-issued CA root certificates


Introduction to IPsec Networking Scenario 3Figure 3-27 shows IPsec networking scenario 3, in which IPsec secures service and signalingdata, but not DHCP packets or OMCH data.



l An U2000 DHCP server is deployed. The base station obtains the OMCH configurationdata and CA configuration data from the U2000 DHCP server. IPsec does not secure DHCPpackets.

l IPsec does not secure OMCH data. The base station uses the OM IP address to access NEsin the untrusted domain. IPsec tunnels established between the base station and the SeGWare used to secure signaling and service data.

l Either party involved in IPsec negotiation uses digital certificates or PSK to authenticatethe other party.

l A CA is required if digital certificates are used for authentication. After the base stationstarts, it must apply to the CA for operator-issued digital certificates before connecting to




76

the SeGW. During base station deployment, the CA is accessible through IP addresses ofNEs in the untrusted domain (for example, the interface IP address of the base station).

Automatic OMCH Establishment ProcedureFigure 3-28 shows the automatic OMCH establishment procedure in IPsec networking scenario3.



2. The base station obtains the OMCH configuration data and CA configuration data(optional) from the U2000 DHCP server. If the base station uses the PSK for authentication,the base station does not need to obtain the CA configuration data. If the base station usesdigital certificates for authentication, the base station must obtain the CA configurationdata.

NOTE

During a DHCP procedure, a DHCP response packet sent by the U2000 contains the target RAT for thebase station. Upon detecting an inconsistency between the current and target RATs, the base stationchanges its current RAT and then restarts. Afterwards, the base station reinitiates a DHCP procedure.

3. The base station applies to the CA for an operator-issued device certificate if it has obtainedCA information. (For details about the certificate application procedure, see the "Obtainingan Operator-Issued Device Certificate" section.) The base station then adds the obtainedcertificate to default trusted certificate list for subsequent IPsec tunnel establishment andSSL authentication.

4. Based on the configuration information obtained from the U2000 DHCP server, the basestation establishes an OMCH to the U2000 or BSC. Because the base station has obtainedoperator-issued certificates, SSL authentication is supported between the U2000 and basestation.




77

NOTE

If an IPsec tunnel or OMCH fails to be established, the base station automatically restarts the automatic OMCHestablishment procedure.

After the OMCH is established, the base station obtains the official configuration information and makes theconfiguration take effect. Then, the base station restarts and establishes an IPsec tunnel to the SeGW to secureservices and signaling.

Configuration Requirements for the Internal DHCP ServerIf the base station uses digital certificates for authentication, the U2000 DHCP server must beconfigured with the parameters listed in both Table 3-24 and Table 3-7. These parameters arecontained in subcodes of Option 43 in DHCP packets.




78


Classification

Parameter Name

Subcode Length(Bytes)



DHCPPacketInvolved

CAinformation

CA URL 44 1 to 128 URL of theCA fromwhich thebasestationobtains anoperator-issueddevicecertificate.This URLmust beaccessiblebynetworkequipmentin theuntrusteddomain,that is, theinterfaceIP addressthat thebasestationobtainsfrom theU2000DHCPservermust beaccessible.

Mandatory

l DHCPOFFER

l DHCPACK

CA Name 38 1 to 127 CA name

Configuration Requirements for Network EquipmentTable 3-25 lists the configuration requirements for network equipment in IPsec networkingscenario 3.




79

Table 3-25 Configuration requirements for network equipment in IPsec networking scenario 3


L2 devices l Allows the transmission of DHCPbroadcast and unicast packets withoutfiltering or modifying DHCP packets.


Next-hop gateway of the base station l Is enabled with the DHCP relay agentfunction and configured with the IPaddress of the DHCP server, that is, the IPaddress of the U2000. If an NAT server isdeployed, the IP address of the U2000must be that converted by the NAT server.

l Is configured with a route whosedestination IP address is the DHCP serverIP address.

l Is configured with a route whosedestination IP address is the OM IPaddress of the base station if the OM IPaddress is not the same as the interface IPaddress of the base station.

l Is configured with a route whosedestination IP address is the CA IPaddress.

L3 devices l (NEs in the untrusted domain): Isconfigured with a route whose destinationIP address is the IP address of the basestation, a route whose destination IPaddress is the OM IP address of the basestation, a route whose destination IPaddress is the U2000, a route whosedestination IP address is the FTP server,and a route whose destination IP addressis the CA.

l (NEs in the trusted domain): Is configuredwith a route whose destination IP addressis the OM IP address of the base stationand routes whose destination IP addressesare the U2000 IP address and FTP serverIP address.


U2000 DHCP server Is configured with a route whose destinationIP address is that of the DHCP relay agent.




80


CA l Is configured with the IP address that canbe accessed by devices in the untrusteddomain.


3.4 Automatic OMCH Establishment by the Separate-MPTMultimode Base Station

3.4.1 NetworkingThe separate-MPT multimode base station is similar to many single-mode base stations that areinterconnected using the transmission board. The interconnection can either be based on thepanel or the backplane. Generally, the transmission board of a certain mode provides a sharedtransmission interface for connecting to the transport network. The base station in this mode iscalled an upper-level base station, and base stations in the other modes are called lower-levelbase stations. The upper-level base station acts as the DHCP relay agent of lower-level basestations.

Figure 3-29 shows the OMCH networking for the separate-MPT multimode base station thatuses panel-based interconnection. The upper-level base station provides two transmissioninterfaces, one for panel-based interconnection (lower transmission interface) and the other forconnecting to the transport network (upper transmission interface).

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 thatuses backplane-based interconnection.




81

Figure 3-30 OMCH networking for the separate-MPT multimode base station that usesbackplane-based interconnection

The automatic OMCH establishment procedure for the separate-MPT base station is similar tothe respective automatic OMCH establishment procedure for each single-mode base station.Lower-level base stations can start the automatic OMCH establishment procedure only after theupper-level base station completes the procedure. This section describes the differences in theprocedures between the separate-MPT base station and the single-mode base station.

3.4.2 Automatic OMCH Establishment ProcedureFigure 3-31 shows the automatic OMCH establishment procedure for the separate-MPTmultimode base station.

Figure 3-31 Automatic OMCH establishment procedure

1. Same as the single-mode base station, the upper-level base station follows the OMCHestablishment procedure described in chapter "3.3 Automatic OMCH Establishment bythe Single-mode Base Station and Co-MPT Multimode Base Station." The upper-levelbase station then obtains software and configuration files from the U2000 or BSC over theestablished OMCH. The upper-level base station activates software and configuration filesand then enters the working state.




82

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

3. Each lower-level base station establishes an OMCH to the U2000 or BSC.

The DHCP servers of the upper-level base station and lower-level base stations can be deployedon the same NE or different NEs.

3.4.3 Configuration Requirements for the DHCP ServerEach mode in a separate-MPT multimode base station has almost the same configurationrequirements for the DHCP server as a single-mode base station. The only difference lies in thesetting of the OM Bearing Board parameter on DHCP servers of lower-level base stations, asdescribed in Table 3-26. For details about the configuration requirements for the DHCP serverof each single-mode base station, see chapter "3.3 Automatic OMCH Establishment by theSingle-mode Base Station and Co-MPT Multimode Base Station".




83

Table 3-26 Setting of the OM Bearing Board parameter on DHCP servers of lower-level basestations

ParameterName




DHCPPacketInvolved

OM BearingBoard

250 1 Value:l 0: An

OMCH isestablished on thepanel.

l 1: AnOMCH isestablished on thebackplane.Set thisparameter to 0when theseparate-MPTmultimode basestationusespanel-basedinterconnection.Set thisparameter to 1when theseparate-MPTmultimode basestationusesbackplane-basedinterconnection.

Mandatory l DHCPOFFER

l DHCPACK




84

ParameterName




DHCPPacketInvolved

CERTDEPLOY

52 3 Slot No.,Subrack No.,and CabinetNo. of theboard onwhich thecertificatefor SSLauthentication isdeployed.Thisparameter isused forcertificatesharing.

OptionalUsed onlywhencertificatesharing isapplied.

DHCPOFFERDHCPACK

NOTE

SSL authentication takes effect only on main control boards. If the certificate for SSL authentication is notdeployed on the main control board of a base station, the main control board must obtain a valid certificatefrom other boards. In this case, certificate sharing must be used. For details, see PKI Feature ParameterDescription for SingleRAN.

3.4.4 Configuration Requirements for Network EquipmentEach mode in a separate-MPT multimode base station has similar configuration requirementsfor network equipment to a single-mode base station. For details about these requirements, see3.3 Automatic OMCH Establishment by the Single-mode Base Station and Co-MPTMultimode Base Station. This section describes only the differences in the configurationrequirements.

The upper-level base station acts as the DHCP relay agent to forward DHCP packets and as arouter to forward OMCH and service packets for lower-level base stations. The transport networkfor 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 beconfigured with data listed in Table 3-27.




85

Table 3-27 Configuration requirements for network equipment


Upper-level base station l Is enabled with the DHCP relay agentfunction. Is configured with IP addressesof the DHCP servers of lower-level basestations.

l Is configured with the IP address of thetransmission interface (used for panel-based interconnection) provided by theupper-level base station.

l Is configured with uplink routes to theDHCP servers of lower-level base stationsand to the peer IP addresses of lower-levelbase stations. If the lower-level basestation is the GBTS or NodeB, uplinkroutes to the base station controller andU2000 must be configured. If the lower-level base station is the eNodeB, uplinkroutes to the U2000, mobilitymanagement entity (MME), and servinggateway (S-GW) must be configured.

l Is configured with downlink routes to theOM IP address and service IP address ofthe lower-level base station.

l Is configured with VLANs on thetransmission interface connecting to thelower-level base station if VLANs aredeployed between cascaded base stations.In this case, the network segmentconfigured by NEXTHOPIP (next-hop IPaddress) and MASK (subnet mask) mustoverlap with the network segmentconfigured by the interconnectioninterface IP address. SingleVLAN modeis recommended for the upper- and lower-level base stations.

l If the DHCP packets and OM data oflower-level base stations are secured bythe IPsec tunnel of the upper-level basestation, the upper-level base station needsto configure security parameters for thepasserby flows of lower-level basestations. The security parameters includethe packet filtering rules, ACL rules, IPsecproposal, and IKE proposal.




86


All devices on the transport network for theupper-level base station

l Is configured with routes to the DHCPservers of lower-level base stations.

l Is configured with routes to the IP addressof the DHCP relay agent of the upper-level base station.

l Is configured with routes to the OM IPaddress and service IP address of thelower-level base station.

U2000/BSC Is configured with routes to the OM IPaddress of the lower-level base station.

DHCP servers of lower-level base stations Is configured with routes to the IP address ofthe DHCP relay agent of the upper-level basestation.

Lower-level base stations Is configured with routes to the U2000 orBSC.Is configured with interface IP addresses thatare on the same network segment with IPaddresses of the interfaces forinterconnection with the upper-level basestations.

l Backplane-based interconnection:The IP addresses of the DHCP relay agent are as follows:1. OM IP address of the upper-level base station2. IP addresses of the upper transmission interface on the upper-level base station. If thereare several IP addresses of the upper transmission interface, the IP address used as the IPaddress of the DHCP relay agent must be on the same network segment as the next-hop IPaddress of the upper-level base station's route to the DHCP server of the lower-level basestation.

l Panel-based interconnection:The IP addresses of the DHCP relay agent are as follows:1. OM IP address of the upper-level base station2. IP addresses of the lower transmission interface on the upper-level base station. If thereare several addresses of the lower transmission interface, the IP addresses used as the IPaddresses of the DHCP relay agent vary by scenario:

– If VLANs have been deployed for neither the OMCH nor the service channel on thelower-level base station, the IP addresses of the lower transmission interface that is notconfigured with VLANs are used.




87

– If VLANs have been deployed for both the OMCH and the service channel on the lower-level base station, the IP address of the interface that is used by the OMCH to deployVLANs is used.

– If VLANs have been deployed for the service channel but not for the OMCH on thelower-level base station, the IP addresses of the interface where no VLAN has beendeployed are used.

In both backplane- and panel-based interconnection scenarios, if there are active and standbyOMCHs on the upper-level base station, the OM IP address in use will be used as the IP addressof the DHCP relay agent. For example, if the OM IP address of the standby OMCH is in use, itwill be used as the IP address of the DHCP relay agent.

Backplane-based Interconnection

Figure 3-32 shows examples of DHCP relay agent's IP addresses and route deployment inbackplane-based interconnection.

Figure 3-32 Examples of DHCP relay agent's IP addresses and route deployment in GBTS &NodeB backplane-based interconnection

l IP addresses of the DHCP relay agent and route from the DHCP server to the IP addressof the DHCP relay agent

– IP addresses of the DHCP relay agent are 10.20.20.22 (OM IP address) and 10.100.1.10(IP address 1).

– The destination IP address of the route from the DHCP server to the IP address of theDHCP relay agent is 10.100.1.10 or 10.20.20.22.

l IP routes on the upper-level base station

– Run the following command to configure a route to the DHCP server of the lower-levelbase station (BSC):ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.101.1.10", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.1.1";

l Run the following command to configure a route to the U2000 IP address:ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.120.1.10", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.10.1";

l Run the following command to configure a route to the RNC service IP address:




88

ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.110.1.10", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.20.1";

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

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

l IP route on the BSCRun the following command to configure a route to the lower-level base station:ADD IPRT: SRN=2, SN=18, DSTIP="10.30.20.20", DSTMASK="255.255.255.255", NEXTHOPTYPE=Gateway, NEXTHOP="10.150.1.10", PRIORITY=HIGH;

Panel-based Interconnection:Figure 3-33 shows examples of DHCP relay agent's IP addresses and route deployment in panel-based interconnection.

Figure 3-33 Examples of DHCP relay agent's IP addresses and route deployment in panel-basedinterconnection

l IP address of the DHCP relay agent and route from the DHCP server to the IP address ofthe DHCP relay agent– If VLANs have been deployed for neither the OMCH nor the service channel on the

lower-level base station, IP addresses of the DHCP relay agent are 10.20.20.22 (OM IPaddress), 10.100.1.10 (IP address 1), and 10.110.1.10 (IP address 2), and the destinationIP address of the route to the IP address of the DHCP relay agent is 10.20.20.22,10.100.1.10, or 10.110.1.10.

– If VLANs have been deployed for both the OMCH and the service channel on the lower-level base station, IP addresses of the DHCP relay agent are 10.20.20.22 (OM IPaddress) and 10.100.1.10 (IP address 1), and the destination IP address of the route tothe IP address of the DHCP relay agent is 10.20.20.22 or 10.100.1.10.To deploy VLANs for the OMCH and service channel on the lower-level base station,configure VLANMAP information on the upper-level base station as follows:




89

//Run the following command to configure VLANs for the OMCH on the lower-level base station:ADD VLANMAP: NEXTHOPIP="10.100.1.30", MASK="255.255.255.0", VLANMODE=SINGLEVLAN, VLANID=10, SETPRIO=DISABLE;//Run the following command to configure VLANs for the service channel on the lower-level base station:ADD VLANMAP: NEXTHOPIP="10.110.1.30", MASK="255.255.255.0", VLANMODE=SINGLEVLAN, VLANID=20, SETPRIO=DISABLE;

– If VLANs have been deployed for the service channel but not for the OMCH on thelower-level base station, IP addresses of the DHCP relay agent are 10.20.20.22 (OM IPaddress) and 10.100.1.10 (IP address 1), and the destination IP address of the route tothe IP address of the DHCP relay agent is 10.20.20.22 or 10.100.1.10.To deploy VLANs for the service channel on the lower-level base station, configureVLANMAP information on the upper-level base station as follows:IP addresses of the DHCP relay agent are 10.20.20.22 (OM IP address) and 10.100.1.10(IP address 1).//Run the following command to configure VLANs for the service channel on the lower-level base stationADD VLANMAP: NEXTHOPIP="10.110.1.30", MASK="255.255.255.0", VLANMODE=SINGLEVLAN, VLANID=20, SETPRIO=DISABLE;

l IP routes on the upper-level base station

– Run the following command to configure a route to the U2000 IP address:ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.200.10.10", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.10.1";

– Run the following command to configure a route to the RNC service IP address:ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.200.20.10", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.20.1";

– Run the following command to configure a route to the MME:ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.200.1.10", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.30.1";

– Run the following command to configure a route to the OM IP address of the lower-level base station:ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.20.20.20 ", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.1.30";

– Run the following command to configure a route to the service IP address of the lower-level base station:ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP=" 10.30.1.30 ", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.110.1.30";

l IP route on the lower-level base stationRun the following command to configure a route to the U2000:ADD IPRT: RTIDX=1, SN=6, SBT=BASE_BOARD, DSTIP="10.200.10.10", DSTMASK="255.255.255.255", RTTYPE=NEXTHOP, NEXTHOP="10.100.1.10";

l Route from the U2000 to the OM IP address of the lower-level base station:The destination IP address of the route is 10.20.20.20, the destination subnet mask is255.255.255.255, and the next-hop IP address is 10.100.11.10.

3.5 Application Restrictions




90

3.5.1 Configuration Requirements for Base Stations and OtherNetwork Equipment

When a base station is to be deployed by PnP, configuration requirements for the base stationand related DHCP servers must be met to ensure successful automatic OMCH establishment. Ifconfiguration requirements are not met, automatic OMCH establishment may fail, leading to adeployment failure. Table 3-28 through Table 3-30 summarizes the configuration requirements.




91

Table 3-28 Configuration requirements for configuration files of the base station in all scenarios

SN MO Requirement

1 OMCH This MO is mandatory.If the base station isconfigured with active andstandby OMCHs, only theactive OMCH is used forbase station deployment byPnP. The active OMCH is theOMCH for which the Flagparameter is set to MASTER(Master).The active OMCH must meetthe following requirements:l If the active OMCH is

bound to a route:The PEERIP parametermust be set to the IPaddress of the U2000. TheIP addresses of the U2000and the FTP server mustbe on the networksegment that iscollectively specified bythe PEERIP andPEERMASK parameters.

l If the active OMCH is notbound to any route:The FTP server and theU2000 must be deployedon the same equipment ornetwork segment. ThePEERIP parameter mustbe set to the IP address ofthe U2000. The IPaddresses of the U2000and the FTP server mustbe on the networksegment that iscollectively specified bythe PEERIP andPEERMASK parameters.The base station must beconfigured with a routewhose destination IPaddress is the networksegment of its peer IPaddress.




92

SN MO Requirement

If the requirements are notmet, the PEERIP parametermust be set to the next-hop IPaddress of the active OMCH,and the PEERMASKparameter must be set to theinterface IP address mask ofthe base station.If BBUs are interconnected,the OMCH must beconfigured on the root BBUthat provides a portconnecting to the transportnetwork.

2 VLANMAP It is recommended thatupper- and lower-level basestations use the SingleVLANmode instead of theVLANGroup mode toconfigure VLANs. If basestations are cascaded and theupper-level base station usesthe VLANGroup mode, theupper-level base station mustattach related VLAN IDs toservices of the OM_HIGHand OM_LOW types whenconfiguring VLANCLASS.If the lower-level base stationis a GBTS, the upper-levelbase station must attachrelated VLAN IDs to servicesof the USERDATA type withthe differentiated servicescode point (DSCP) set to thesame value as the DSCP ofthe GBTS OMCH.The VLANMODE parameterspecifies the VLAN mode.




93

SN MO Requirement

3 BFDSESSION If the CATLOG parameter isset to RELIABILITY(Reliability) for a BFDsession, the BFD session isbound to a handover route. Inscenarios in which IPsec doesnot secure OMCH data, if thebase station uses a logical IPaddress as the OM IP addressand the BFD session is boundto a handover route, the basestation cannot be deployed byPnP.

4 NE If the combination of theDID, subrack topology, andslot number is used as the BSID, the DID parameter in theNE MO must be specified.

5 IPRT/SRCIPRT If the OMCH is configuredwith active and standbyroutes, only the active routecan be used for the basestation deployment by PnP.The active route has a higherpriority than the standby one.NOTE

The smaller the number of theroute priority, the higher thepriority.

Equivalent routes are notrecommended for theOMCH. This is becausedeployment may fail as thebase station randomlychooses a route from theequivalent routes for theOMCH during deploymentby PnP.NOTE

Equivalent routes are routesconfigured with the samedestination IP address andpriority and they are used forload sharing.




94

Table 3-29 Configuration requirements for the configuration files of the base station in IPsecnetworking scenariosSNNEMORequirement

SN NE MO Requirement

1 Basestation

OMCH If either the OMCH or the service channel is secured by IPsec, theOMCH and the service channel must use different IP addresses.Otherwise, an error may occur in DHCP parameters.

2 Basestation

ACLRULE

If neither requirement is met, errors may occur when parametersconfigured on the SeGW are exported from the CME, leading tofailures in base station deployment by PnP. The configured ACLrule 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, boththe source and destination IP addresses can be any address.

l The SIP is set to the OM IP address, and the DIPparameter isset to the IP address of the U2000, the IP address of the U2000network segment, or 0.0.0.0. Note that IPsec tunnels do notsecure OMCHs established during base station deployment ifthe ACTION parameter is set to DENY(Deny). IPsec tunnelssecure the OMCHs only when the ACTION parameter is notset to DENY(Deny).

3 Basestation

IKEPROPOSALIPSECPROPOSAL

Parameter settings of the IPSECPROPOSAL MO must beconsistent with those described in Figure 3-26. Parameter settingsof the IKEPROPOSAL MO must be consistent with thosedescribed in Table 3-13 and Table 3-14.If the base station uses the IPsec tunnel pair topology, only theactive tunnel supports base station deployment by PnP.

4 Basestation

BFDSESSION

If the base station uses the IPsec tunnel pair topology, the BFDsession cannot be bound to a route during the BFD sessionconfiguration.

5 L2devices

ETHTRK

Ethernet link aggregation group must not be manually configuredon the peer L2 devices of the base station.

6 CA CA l The CA must be accessible to devices in the untrusted domain.l In the case of base station deployment by PnP, the base station

does not support the polling mode. When the CA is in pollingmode, the certificate application of the base station may faildue to timeout.

NOTE

When you configure or modify the information of the U2000 DHCP server on the U2000, the destinationIP address of the OMCH route and the IP address of the destination network segment must be correct.




95

Table 3-30 Configuration requirements for a DHCP server

SN Requirement

1 The public DHCP server can be configuredwith a maximum of eight U2000 DHCPserver IP addresses.If base stations of SRAN7.0, SRAN8.0, andlater versions co-exist in a network,configuring eight U2000 DHCP server IPaddresses on the public DHCP server causesa deployment failure because SRAN7.0 basestations support only two U2000 DHCPserver IP addresses. In this scenario,configure two U2000 DHCP server IPaddresses or deploy SRAN7.0 base stationsin non-PnP mode.

2 If the WMPT board of the NodeB needs to bereplaced with the UMPT board, the BS IDconfigured on the DHCP server must bechanged from being bound to the panel's ESN(mapping subcode 43 in DHCP Option 43) tobeing bound to the backplane's ESN(mapping subcode 1 in DHCP Option 43).

3.5.2 Impact of U2000 Deployment on Base Station Deployment byPnP

During base station deployment by PnP and subsequent commissioning, the base station needsto communicate with many application services of the U2000, including the DHCP service, FTPservice, and OMCH management service.

The preceding three services can be deployed on different U2000s and use different IP addresses.Therefore, network planning and base station data configuration must ensure normalcommunication between the OM IP address of the base station and the IP addresses of the threeservices.

Table 3-31 describes the impact of U2000 deployment on automatic OMCH establishment.




96

Table 3-31 Impact of U2000 deployment on automatic OMCH establishment

U2000Deployment

U2000DeploymentDescription

U2000Serving astheDHCPServer

U2000Serving astheOMC

Requirement forthe Base StationDeployment

Impact on theNetworkConfiguration

Single-serversystem

l Allapplicationservicesaredeployedon thesameserver

l and theserverhas onlyone IPaddress.

Singleserver

Singleserver

For details, see 3.3Automatic OMCHEstablishment by theSingle-mode BaseStation and Co-MPTMultimode BaseStation and 3.4Automatic OMCHEstablishment by theSeparate-MPTMultimode BaseStation.


HAsystem

l Theactiveandstandbynodeshave thesamefunctionand dataon thetwonodes aresynchronized.

l Theactiveandstandbynodesuse thesame IPaddress.

Active orstandbynode

Activeorstandbynode






97

U2000Deployment






SLSsystem

l Theslavenodeperformsthenetworkmanagementfunctiononly.

l The IPaddressof themasternode isdifferentfrom thatof theslavenode,and theIPaddresses of thetwonodes arein thesamesubnet.

Masternode

Masteror slavenode

l The PeerIPparameter for theOMCH must be setto the IP address ofthe U2000 thatmanages the basestation.

l If the OMCH isbound to a route,the route must beto the networksegment of theU2000.

In IPsec networkingscenarios, the IP addressof the U2000 DHCPserver configured on thepublic DHCP servermust be the IP address ofthe master node.The SeGW must beconfigured with ACLrules which allowpackets of the U2000DHCP server to pass.The SeGW must beconfigured with ACLrules which allow OMdata to pass.




98

U2000Deployment






Remote HAsystem

l Theactiveandstandbynodes aredeployedon twolocations.

l The IPaddressof theactivenode isdifferentfrom thatof thestandbynode,and theIPaddresses of thetwonodesmay notbe in thesamesubnet.

Active orstandbynode

TheU2000mustserve astheDHCPserver.

l The base stationmust beconfigured withroutes to the two IPaddress or twonetwork segments.

l The PeerIPparameter for theOMCH of the basestation must be setto the IP address ofthe U2000 thatserves as theDHCP server.

l In IPsec networkingscenarios, the IPaddress of the U2000DHCP serverconfigured on thepublic DHCP servermust be the IPaddress of the U2000that serves as theDHCP server. If theoperator expects touse either of theactive and standbynodes as the DHCPserver, the publicDHCP server mustbe configured withthe IP addresses ofthe active andstandby nodes.

l The SeGW must beconfigured with ACLrules which allowDHCP packets topass. If the operatorexpects to use eitherof the active andstandby nodes as theDHCP server, theSeGW must beconfigured with ACLrules which allowpackets of active andstandby nodes topass.

l The SeGW must beconfigured with ACLrules which allowOM data to pass. Ifthe operator expects




99

U2000Deployment






to use either of theactive and standbynodes as the OMC,the SeGW must beconfigured with ACLrules which allowpackets of active andstandby nodes topass.

Emergencysystem

Theemergencysystemperformsbasicfunctionsonly anddoes notsupport PnPor DHCP.

Notsupported

Notsupported

Not involved Not involved

For example:When the U2000 uses the multi-server load-sharing (SLS) networking, the DHCPservice is deployed on the master server, whereas the FTP service and the OMCH managementservice can be deployed on either the master or slave server. When the FTP service and OMCHmanagement service are deployed on different U2000 servers and accordingly use different IPaddresses, the route configuration on the base station and the transport network must ensure thatthe IP addresses of the two services are reachable using configured routes. If IPsec securesOMCH data, the IPsec SA's traffic selector (TS) successfully negotiated between the base stationand the SeGW must cover the traffic between the OM IP address of the base station and the IPaddresses of the FTP service and the OMCH management service.

OMCH networking requires that the NAT server be deployed only on the U2000 side, but notthe base station or BSC side. Figure 3-34 shows the OMCH networking in which the NAT serveris deployed on the U2000 side.




100

Figure 3-34 OMCH networking when the NAT server is deployed on the U2000

The IP address and port number of the U2000 can be converted by the NAT. Therefore, the routewhose destination IP address is the U2000 IP address on the base station side must use an U2000IP address visible on the base station side as the destination address. As shown in Figure3-34, the local IP address configured for the U2000 is 10.20.0.1, that is , the source IP addressof packtes sentd by the U2000 is 10.20.0.1. After the conversion performed by the NAT server,however, the source IP address in TCP packets received by the base station is 10.10.1.1 insteadof 10.20.0.1. Therefore, the route whose destination IP address is 10.10.1.1 instead of 10.20.0.1must be configured on the base station side.

NOTE

The IP address and port number on the base station side cannot be converted by the NAT server becausethe DHCP server uses the IP address of the DHCP relay agent (giaddr) or IP address of the DHCP client(ciaddr) as the destination IP address for responding to the DHCP message and the giaddr or ciaddr fieldscontained in the DHCP message cannot be converted by the NAT server.




101

4 ATM-based Automatic OMCHEstablishment for Base Stations

4.1 OverviewATM-based automatic OMCH establishment for Base Stations (corresponding to featureWRFD-031100 BOOTP) is used for the bootstrap of diskless workstations. It enables the disklessworkstation to obtain the IP address from the server during the startup. Compared with theReverse Address Resolution Protocol (RARP) that implements the same function, BOOTP ismore 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 basedon the obtained IP address and default PVC. In this way, a remote OM channel can be set upbetween the NodeB and the U2000 or LMT.

The NodeB configuration data normally contains the data of the IPoA path. If the data is correct,the user can remotely access and maintain the NodeB. If the data is incorrect, BOOTP helps theNodeB to establish a correct IPoA path so that the NodeB can be remotely maintained.

4.2 PrinciplesBOOTP is used in ATM networking to establish an IPoA path so that a remote OM channelfrom the U2000 or LMT to the NodeB can be set up.

The configuration data required for setting up an IPoA path includes the Permanent VirtualChannel (PVC), transport ports carrying the PVC, and IP addresses.

The procedure of BOOTP establishment consists of port listening, port configuration, PVC setupand BOOTP request initiation, RNC returning the BOOTPREPLY message, and IPoAconfiguration, as shown in Figure 4-1.


4 ATM-based Automatic OMCH Establishment for BaseStations


102

Figure 4-1 Procedure of BOOTP establishment

4.2.1 Port ListeningPort listening enables the NodeB to listen to the configuration data of peer ports so that theNodeB 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 othertransport 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 theunchannelized STM-1/OC-3 ports, the PVC can be set up without port listening asinterconnection is not involved. The following describes the port listening function in the caseof IMA, UNI, and fractional ATM.




103

Port Listening in the Case of IMA/UNI

Through IMA/UNI ports, the NodeB can obtain the configuration data from peer ports bylistening to the IMA Control Protocol (ICP) cells of the peer end. According to the obtainedconfiguration data, the NodeB sets up an IMA group that carries the PVC (including the IMAlinks in the IMA group) or UNI links.

The NodeB first tries to listen to the IMA/UNI ports because whether the IMA/UNI ports orfractional ATM ports are used cannot be determined initially. If the listening fails, the NodeBlistens 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 thetimeslots 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 thecombinations of timeslots are countless. To prevent this problem, the range of timeslotcombinations needs to be minimized. The combinations need to contain only the typical timeslotbitmaps commonly used by the telecom operators.

To listen to fractional ATM links is to apply the exhaustive method to these typical timeslotbitmaps, which is a way to configure the fractional ATM links. If the links work properly, thelistening is successful; if the links work abnormally, it indicates that the timeslot bitmap doesnot 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 physicallinks 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 ConfigurationThe NodeB configures its IMA or UNI ports based on the configuration data of the ports at thepeer end. The configuration parameters of the peer ports, obtained through port listening, includeprotocol version number and IMA frame length.

4.2.3 PVC Setup and BOOTP Request InitiationThe PVC used by BOOTP is permanently 1/33, that is, its Virtual Path Identifier (VPI) is set to1 and Virtual Channel Identifier (VCI) is set to 33. Such a PVC needs to be configured at theRNC 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 requestthe 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 MessageThe prerequisite for the RNC to respond to the BOOTPREQUEST message is that the RNC hasconfigured a PVC (fixed to 1/33) for the related NodeB and has obtained the corresponding IPaddresses.




104

On receipt of the BOOTPREQUEST message, the RNC replies with a BOOTPREPLY messagecontaining the assigned IP address. The message is transmitted over the established PVC (fixedto 1/33).

4.2.5 IPoA ConfigurationAfter receiving the BOOTPREPLY message from the RNC, the NodeB configures an IPoApath, which finalizes the BOOTP implementation process.

4.3 Configuration GuidelinesIn the IP network, For details about data to prepare before a base station starts the automaticoperation and maintenance channel (OMCH) establishment procedure, see 3900 Series BaseStation Initial Configuration Guide. For details about software and configuration filedownloading, activation, and commissioning on a base station after the automatic OMCHestablishment 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 usingBOOTP, the PVC is to be configured with VPI = 1 and VCI = 33. The main parameters of thiscommand are as follows:

l CARRYVPI(BSC6910,BSC6900): This parameter specifies the VPI value of the PVC. Itis set to 1.

l CARRYVCI(BSC6910,BSC6900): This parameter specifies the VCI value of the PVC. Itis 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 peerend, that is, IP address of the NodeB.

On the RNC side, run the ADD UNODEBIP command to configure the IP address of the OMchannel. The main parameter of this command is as follows:

NBATMOAMIP(BSC6900,BSC6910): This parameter specifies the OM IP address of theNodeB in ATM networking.

NBCTRLSN(BSC6900,BSC6910): This parameter specifies the main control board slot numberof the NodeB. When there are multiple main control boards in a base station, the RNC comparesthe slot number of a main control board reported in the BOOTP process with the slot numberspecified by users. If the reported and specified slot numbers are the same, the RNC returns aBOOTPREPLY message to the base station.

Configuring BOOTP on the NodeB Side in an ATM Network

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




105

5 TDM-based Base Station Automatic OMCHEstablishment

5.1 IntroductionIn 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 includeslayer 2 management link (L2ML), OML, radio signaling link (RSL), and extended signalinglink (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. Thisfunction is used to establish an OMCH (that is, an OML) between the GBTS and BSC.

5.2 ProcessAs shown in Figure 5-2, the process of OML timeslot detection in TDM networking consistsof two procedures: sending L2ML establishment requests and saving detection information.

SingleRANAutomatic OMCH Establishment Feature ParameterDescription 5 TDM-based Base Station Automatic OMCH Establishment


106

Figure 5-2 Process of OML timeslot detection in TDM networking

5.2.1 Sending L2ML Establishment RequestsThe 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 basedon the DIP switch of the main control board.

2. To establish an OML to the BSC, the GBTS attempts to send L2ML establishment requestsbased on certain combinations of bandwidths and E1/T1 ports that support OML timeslotdetection.

OML timeslot detection in TDM networking requires 64 kbit/s or 16 kbit/s bandwidth and canbe implemented on E1/T1 ports 0 and 1 of the main control board. Therefore, there are fourpossible 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 1through 31.

l For a T1 link, the GBTS sends L2ML establishment requests over 64 kbit/s timeslots 1through 24.

If the 16 kbit/s bandwidth is used:



107

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 16kbit/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-timeslotof the last 64 kbit/s timeslot. The last 64 kbit/s timeslot is timeslot 31 for an E1 link and timeslot24 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 cannotcarry an OML, run the SET BTSOMLTS command on the BSC LMT to set the timeslot thatis used to carry the OML, and run the SET BTSOMLDETECT command to set the OMLtimeslot 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 InformationThe GBTS saves the combination of the bandwidth and E1/T1 port number that was used forthe previous successful L2ML establishment. Upon the next startup, the GBTS preferentiallyuses the saved combination for OML establishment, which reduces the startup time.



108

6 Parameters

Table 6-1 Parameter description

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

DHCPRLYID

BSC6910

ADDDHCPRLYMODDHCPRLYRMVDHCPRLY

None None Meaning: DHCP Relay ID.GUI Value Range: 0~2047Unit: NoneActual Value Range: 0~2047Default Value: None

DHCPRLYID

BSC6900

ADDDHCPRLYMODDHCPRLYRMVDHCPRLY

None None Meaning: DHCP Relay ID.GUI Value Range: 0~2047Unit: NoneActual Value Range: 0~2047Default Value: None

DHCPRLYGATEWAYIP

BSC6900

ADDDHCPRLYMODDHCPRLY

None None Meaning: This parameter indicates the IP Address ofDHCP Relay Gateway.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None

SingleRANAutomatic OMCH Establishment Feature ParameterDescription 6 Parameters


109

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

DHCPRLYGATEWAYIP

BSC6910


None None Meaning: This parameter indicates the IP Address ofDHCP Relay Gateway.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None

DHCPSRVISEMSIP

BSC6900


WRFD-050410

IPTransmissionIntroduction onIurInterface

Meaning: Whether the IP address of the DHCP serveris the same as the IP address of the EMS.GUI Value Range: No(DHCP server IP address needsto be specified), Yes(Same as the EMS IP address)Unit: NoneActual Value Range: Yes, NoDefault Value: Yes(Same as the EMS IP address)

DHCPSRVISEMSIP

BSC6910


WRFD-150244

Iu/Iur IPTransmissionBasedonDynamic LoadBalance

Meaning: Whether the IP address of the DHCP serveris the same as the IP address of the EMS.GUI Value Range: No(DHCP server IP address needsto be specified), Yes(Same as the EMS IP address)Unit: NoneActual Value Range: Yes, NoDefault Value: Yes(Same as the EMS IP address)

DHCPSRVIP1

BSC6900


WRFD-050410


Meaning: First IP Address of the DHCP Server.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None

DHCPSRVIP1

BSC6910


WRFD-150244

Iu/Iur IPTransmissionBasedonDynamic LoadBalance

Meaning: First IP Address of the DHCP Server.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None



110

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

DHCPPID

BSC6900


WRFD-050410


Meaning: NE type identifier in the DHCP message. Theparameter specifies the type of NEs for which themultimode base station controller can perform DHCPrelay. TGWSWITCH is the relay switch of TGW, andOTHERSWITCH is the relay switch of NEs supportingthe relay function except TGW, such as SRAN, NodeB,USU, eNodeB, and eGBTS.GUI Value Range: TGWSWITCH(TGWSWITCH),OTHERSWITCH(OTHERSWITCH)Unit: NoneActual Value Range: TGWSWITCH,OTHERSWITCHDefault Value: TGWSWITCH:1,OTHERSWITCH:1



111

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

ES BTS3900,BTS3900WCDMA,BTS3900 LTE

SETDHCPRELAYSWITCHLSTDHCPRELAYSWITCH

MRFD-221501WRFD-031101

MRFD-231501LBFD-00300102/TDLBFD-00300102LBFD-00300103/TDLBFD-00300103

MRFD-211501

IP-BasedMulti-modeCo-Transmission onBS side(NodeB)NodeBSelf-discovery Basedon IPMode

IP-BasedMulti-modeCo-Transmission onBS side(eNodeB)ChainTopologyTreeTopology

IP-BasedMulti-modeCo-Transmission onBS side(GBTS)

Meaning: Indicates whether to enable the DHCP relayswitch.GUI Value Range: DISABLE(Disable), ENABLE(Enable)Unit: NoneActual Value Range: DISABLE, ENABLEDefault Value: DISABLE(Disable)



112

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

DHCPSVRIP

BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDDHCPSVRIPRMVDHCPSVRIPLSTDHCPSVRIP

WRFD-031101

MRFD-211501

LBFD-00300102/TDLBFD-00300102LBFD-00300103/TDLBFD-00300103

NodeBSelf-discovery Basedon IPMode

IP-BasedMulti-modeCo-Transmission onBS side(GBTS)

ChainTopologyTreeTopology

Meaning: Indicates the IP address of the DHCP server.GUI Value Range: Valid IP addressUnit: NoneActual Value Range: Valid IP addressDefault Value: None

IDTYPE BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDIKEPEERMODIKEPEERDSPIKEPEERLSTIKEPEER

LOFD-003009 /TDLOFD-003009

GBFD-113524

WRFD-140209

IPsec

BTSIntegrated Ipsec

NodeBIntegrated IPSec

Meaning: Indicates the type of the identificationpayload that the local end transmits. The authenticationcan be performed based on IP or fully qualified domainname (FQDN).GUI Value Range: IP(IP Identify), FQDN(NameIdentify)Unit: NoneActual Value Range: IP, FQDNDefault Value: None



113

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

FLAG BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDOMCHDSPOMCHMODOMCHRMVOMCHLSTOMCH

WRFD-050404

LBFD-004002 /TDLBFD-004002LOFD-003005

GBFD-118601GBFD-118611

ATM/IPDualStackNode B

CentralizedU2000ManagementOMChannelBackup

Abisover IPAbis IPover E1/T1

Meaning: Indicates the master/slave flag of the remotemaintenance channel.GUI Value Range: MASTER(Master), SLAVE(Slave)Unit: NoneActual Value Range: MASTER, SLAVEDefault Value: None

PEERIP BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDOMCHMODOMCHDSPOMCHLSTOMCH

WRFD-050404

LBFD-004002 /TDLBFD-004002LOFD-003005

GBFD-118601GBFD-118611




Meaning: Indicates the peer IP address of the remotemaintenance channel, indicates the IP address of theU2000 in an IP network and the device IP address of theRNC in an ATM network.GUI Value Range: Valid IP addressUnit: NoneActual Value Range: Valid IP addressDefault Value: None



114

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

PEERMASK


ADDOMCHMODOMCHDSPOMCHLSTOMCH

WRFD-050404

LBFD-004002 /TDLBFD-004002LOFD-003005

GBFD-118601GBFD-118611




Meaning: Indicates the subnet mask of the peer IPaddress for the remote maintenance channel.GUI Value Range: Valid IP addressUnit: NoneActual Value Range: Valid IP addressDefault Value: None

VLANMODE


ADDVLANMAPMODVLANMAPLSTVLANMAP

WRFD-050402

LBFD-003003 /TDLBFD-003003

GBFD-118601

IPTransmissionIntroduction onIubInterface

VLANSupport(IEEE802.1p/q)

Abisover IP

Meaning: Indicates the VLAN mode. When thisparameter is set to SINGLEVLAN, the configuredVLAN ID and VLAN priority can be directly used tolabel the VLAN tag. If this parameter is set toVLANGROUP, the next hop IP addresses are mappedto the VLAN groups, and then mapped to the VLANtags in the VLAN groups according to the DSCPs of theIP packets. In VLAN group mode, ensure that theVLAN groups have been configured by running theADD VLANCLASS command. Otherwise, theconfiguration does not take effect.GUI Value Range: SINGLEVLAN(Single VLAN),VLANGROUP(VLAN Group)Unit: NoneActual Value Range: SINGLEVLAN, VLANGROUPDefault Value: None



115

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

CATLOG


ADDBFDSESSIONMODBFDSESSIONDSPBFDSESSIONLSTBFDSESSION

WRFD-050403

LOFD-003007 /TDLOFD-003007

GBFD-118601

HybridIub IPTransmission

BidirectionalForwardingDetection

Abisover IP

Meaning: Indicates the type of the BFD session. If thisparameter is set to MAINTENANCE, this BFD sessionis used only for continuity check (CC). If this parameteris set to RELIABILITY, the BFD session is used totrigger route interlock. Route interlock enables thestandby route to take over once the active route becomesfaulty, and therefore prevents service interruptioncaused by route failures.GUI Value Range: MAINTENANCE(Maintenance),RELIABILITY(Reliability)Unit: NoneActual Value Range: MAINTENANCE,RELIABILITYDefault Value: RELIABILITY(Reliability)

DID BTS3900,BTS3900WCDMA,BTS3900 LTE

SET NELST NE

None None Meaning: Indicates the deployment identifier thatspecifies the site of the NE. When multiple NEs aredeployed at the same site, these NEs have the samedeployment identifier.GUI Value Range: 0~64 charactersUnit: NoneActual Value Range: 0~64 charactersDefault Value: NULL(empty string)



116

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

SIP BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDACLRULEMODACLRULEDSPACLRULELSTACLRULE

WRFD-050402

WRFD-140209

LOFD-003009 /TDLOFD-003009

LOFD-00301401/TDLOFD-00301401

GBFD-118601

GBFD-113524

IPTransmissionIntroduction onIubInterfaceNodeBintegrated IPSec

IPsecAccessControlList(ACL)

Abisover IPBTSIntegrated Ipsec

Meaning: Indicates the source IP address of data towhich the ACL rule is applied. To add an ACL rule thatis applicable to data of all source IP addresses, set thisparameter to 0.0.0.0.GUI Value Range: Valid IP addressUnit: NoneActual Value Range: Valid IP addressDefault Value: None

DIP BTS3900,BTS3900WCDMA,BTS3900 LTE


WRFD-050402

WRFD-140209

LOFD-003009 /TDLOFD-003009

LOFD-00301401/TDLOFD-00301401

GBFD-118601

GBFD-113524




Meaning: Indicates the destination IP address of data towhich the ACL rule is applied. To add an ACL rule thatis applicable to data of all destination IP addresses, setthis parameter to 0.0.0.0.GUI Value Range: Valid IP addressUnit: NoneActual Value Range: Valid IP addressDefault Value: None



117

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

SWC BTS3900,BTS3900WCDMA,BTS3900 LTE


WRFD-050402

WRFD-140209

LOFD-003009 /TDLOFD-003009

LOFD-00301401/TDLOFD-00301401

GBFD-118601

GBFD-113524




Meaning: Indicates the wildcard of the source IPaddress. The wildcard is used to determine which bitscan be neglected when IP address matching is beingperformed. It can be considered as the inverse of thecorresponding subnet mask.GUI Value Range: Valid wildcard of the IP addressUnit: NoneActual Value Range: Valid wildcard of the IP addressDefault Value: None

DWC BTS3900,BTS3900WCDMA,BTS3900 LTE


WRFD-050402

WRFD-140209

LOFD-003009 /TDLOFD-003009

LOFD-00301401/TDLOFD-00301401

GBFD-118601

GBFD-113524




Meaning: Indicates the wildcard of the destination IPaddress. The wildcard is used to determine which bitscan be neglected when IP address matching is beingperformed. It can be considered as the inverse of thecorresponding subnet mask.GUI Value Range: Valid wildcard of the IP addressUnit: NoneActual Value Range: Valid wildcard of the IP addressDefault Value: None



118

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

ACTION


ADDACLRULEDSPACLRULELSTACLRULE

WRFD-050402

WRFD-140209

LOFD-003009 /TDLOFD-003009

LOFD-00301401/TDLOFD-00301401

GBFD-118601

GBFD-113524




Meaning: Indicates the action taken on the data thatmatches the ACL rule. When the ACL to which the ACLrule belongs is referenced by a packet filter, the BSaccepts or transmits the data that matches the rule if thisparameter is set to PERMIT, and rejects the data if thisparameter is set to DENY. When the ACL is referencedby an IPSec policy, the BS encrypts or decrypts the datathat matches the rule if this parameter is set to PERMIT,and does not perform any encryption or decryption onthe data if this parameter is set to DENY.GUI Value Range: DENY(Deny), PERMIT(Permit)Unit: NoneActual Value Range: DENY, PERMITDefault Value: PERMIT(Permit)

CARRYVPI

BSC6910

ADDIPOAPVCMODIPOAPVC

WRFD-050105WRFD-031100WRFD-05030105WRFD-050301

ATMSwitching BasedHubNode BBOOTPPermanent AAL5Connections forControlPlaneTrafficATMTransmissionIntroductionPackage

Meaning: VPI value of the VCL of the bearer networkGUI Value Range: 0~4095Unit: NoneActual Value Range: 0~4095Default Value: None



119

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

CARRYVPI

BSC6900




Meaning: VPI value of the VCL of the bearer networkGUI Value Range: 0~4095Unit: NoneActual Value Range: 0~4095Default Value: None

CARRYVCI

BSC6910




Meaning: VCI value of the VCL of the bearer networkGUI Value Range: 32~65535Unit: NoneActual Value Range: 32~65535Default Value: None



120

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

CARRYVCI

BSC6900




Meaning: VCI value of the VCL of the bearer networkGUI Value Range: 32~65535Unit: NoneActual Value Range: 32~65535Default Value: None

IPADDR

BSC6910

ADDIPOAPVCMODIPOAPVCRMVIPOAPVC



Meaning: Local IP addressGUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None



121

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

IPADDR

BSC6900




Meaning: Local IP address.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None

PEERIPADDR

BSC6910




Meaning: Peer IP address.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None



122

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

PEERIPADDR

BSC6900




Meaning: Peer IP address.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None

NBATMOAMIP

BSC6900

ADDUNODEBIPMODUNODEBIP

WRFD-031100WRFD-031101

BOOTPNodeBSelf-discovery Basedon IPMode

Meaning: When the operation and maintenance channelof NodeB is operating in the ATM, this parameterindicates the address of the operation and maintenanceconsole. The IP address and IPOA client IP addressmust be in the same network segment.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None

NBATMOAMIP

BSC6910


WRFD-031100WRFD-031101

BOOTPNodeBSelf-discovery Basedon IPMode

Meaning: When the operation and maintenance channelof NodeB is operating in the ATM, this parameterindicates the address of the operation and maintenanceconsole. The IP address and IPOA client IP addressmust be in the same network segment.GUI Value Range: Valid IP AddressUnit: NoneActual Value Range: Valid IP AddressDefault Value: None



123

Parameter ID

NE MMLCommand

FeatureID

FeatureName

Description

NBCTRLSN

BSC6900


None None Meaning: Number of the slot for the NodeB maincontrol board.GUI Value Range: 0~7;255Unit: NoneActual Value Range: 0~7, 255Default Value: 255

NBCTRLSN

BSC6910


None None Meaning: Number of the slot for the NodeB maincontrol boardGUI Value Range: 0~7;255Unit: NoneActual Value Range: 0~7, 255Default Value: 255



124

7 Counters

There are no specific counters associated with this feature.

SingleRANAutomatic OMCH Establishment Feature ParameterDescription 7 Counters


125

8 Glossary

For the acronyms, abbreviations, terms, and definitions, see Glossary.

SingleRANAutomatic OMCH Establishment Feature ParameterDescription 8 Glossary


126

9 Reference Documents

1. IPSec Feature Parameter Description for SingleRAN2. PKI Feature Parameter Description for SingleRAN3. SSL Feature Parameter Description for SingleRAN4. 3900 Series Base Station Commissioning Guide5. 3900 Series Base Station Initial Configuration Guide

SingleRANAutomatic OMCH Establishment Feature ParameterDescription 9 Reference Documents


127

automatic omch establishment(sran9.0_01)

Documents

huawei trademarks

huawei proprietary

huawei industrial basebantian

thepurchase scope

usage scope

base stations

base station types

trade names