Automatic OMCH Establishment Feature Parameter PDF

SingleRAN
Automatic OMCH Establishment

Feature Parameter Description Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice The purchased products, services and features are stipulated by the commercial contract made between Huawei and the customer. All or partial products, services and features described in this document may not be within the purchased scope or the usage scope. Unless otherwise agreed by the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
SingleRAN Automatic OMCH Establishment
Contents
Contents
1 About This Document ..............................................................................................................1-1
1.1 Scope ............................................................................................................................................ 1-1 1.2 Intended Audience......................................................................................................................... 1-1 1.3 Change History.............................................................................................................................. 1-1
2 Overview......................................................................................................................................2-1
2.1 Introduction.................................................................................................................................... 2-1 2.2 Benefits ......................................................................................................................................... 2-2 2.3 Application Networking Scenarios ................................................................................................. 2-3
3 OMCH Protocol Stacks ............................................................................................................3-1

3.1 Non-IPSec Networking Scenario ................................................................................................... 3-1 3.2 IPSec Networking Scenario .......................................................................................................... 3-2
4 Obtaining Transmission Configuration Information .......................................................4-1

4.1 DHCP Overview ............................................................................................................................ 4-1 4.1.1 Introduction ........................................................................................................................... 4-1 4.1.2 DHCP Interworking ............................................................................................................... 4-1 4.1.3 DHCP Packet Format ........................................................................................................... 4-2 4.2 Mapping Between DHCP Clients and Servers .............................................................................. 4-4 4.3 DHCP Procedure ........................................................................................................................... 4-4 4.3.1 Base Station Identification .................................................................................................... 4-4 4.3.2 Procedure for Obtaining Configuration Information in Non-IPSec Networking Scenarios ... 4-5 4.3.3 Procedure for Obtaining Configuration Information in IPSec Networking Scenarios ........... 4-6 4.3.4 Procedure for Releasing Allocated Configuration Information ............................................. 4-8 4.4 Schemes for Obtaining VLAN Information for DHCP Packets ...................................................... 4-8 4.4.1 Overview ............................................................................................................................... 4-8 4.4.2 Scheme 1 ........................................................................................................................... 4-10 4.4.3 Scheme 2 ........................................................................................................................... 4-11 4.4.4 Scheme 3 ........................................................................................................................... 4-12 4.4.5 Scheme 4 ........................................................................................................................... 4-13
5 Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station .............................................................................................................5-1
5.1 Overview ....................................................................................................................................... 5-1 5.2 Automatic OMCH Establishment in Non-IPSec Networking Scenarios ........................................ 5-1 5.2.1 Introduction to Non-IPSec Networking ................................................................................. 5-1 5.2.2 Automatic OMCH Establishment Procedure ........................................................................ 5-1 5.2.3 Configuration Requirements for the DHCP Server ............................................................... 5-2 5.2.4 Configuration Requirements for NEs .................................................................................... 5-8 5.3 Automatic OMCH Establishment in IPSec Networking Scenario 1 ............................................... 5-9 5.3.1 Introduction to IPSec Networking Scenario 1 ....................................................................... 5-9
Draft A (2012-12-30)
Contents
5.3.2 Automatic OMCH Establishment Procedure ...................................................................... 5-10 5.3.3 Configuration Requirements for the Public DHCP Server .................................................. 5-12 5.3.4 Establishing a Temporary IPSec Tunnel ............................................................................. 5-14 5.3.5 Configuration Requirements for the Internal DHCP Server ............................................... 5-16 5.3.6 Obtaining Formal Transmission Configuration Information from the Internal DHCP Server ..................................................................................................................................................... 5-17 5.3.7 Establishing a Formal IPSec Tunnel .................................................................................. 5-20 5.3.8 Configuration Requirements for NEs .................................................................................. 5-21 5.4 Automatic OMCH Establishment in IPSec Networking Scenario 2 ............................................. 5-22 5.4.1 Introduction to IPSec Networking Scenario 2 ..................................................................... 5-22 5.4.2 Automatic OMCH Establishment Procedure ...................................................................... 5-23 5.4.3 Configuration Requirements for the Internal DHCP Server ............................................... 5-23 5.4.4 Configuration Requirements for NEs .................................................................................. 5-24 5.5 Automatic OMCH Establishment in IPSec Networking Scenario 3 ............................................. 5-25 5.5.1 Introduction to IPSec Networking Scenario 3 ..................................................................... 5-25 5.5.2 Automatic OMCH Establishment Procedure ...................................................................... 5-26 5.5.3 Configuration Requirements for the Internal DHCP Server ............................................... 5-27 5.5.4 Configuration Requirements for NEs .................................................................................. 5-28
6 Automatic OMCH Establishment by the Separate-MPT Multimode Base Station ...6-1

6.1 Networking .................................................................................................................................... 6-1 6.2 Automatic OMCH Establishment Procedure ................................................................................. 6-2 6.3 Configuration Requirements for the DHCP Server ....................................................................... 6-3 6.4 Configuration Requirements for NEs ............................................................................................ 6-3
7 Application Restrictions .........................................................................................................7-1

7.1 Configuration Requirements for Base Stations and Other NEs .................................................... 7-1 7.2 Impact of M2000 Deployment on Base Station Deployment by PnP ............................................ 7-3
8 Glossary ......................................................................................................................................8-1 9 Reference Documents .............................................................................................................9-1
Draft A (2012-12-30)
ii
1 About This Document
1 About This Document

1.1 Scope
This document describes the Automatic OMCH Establishment feature, including its implementation principles, procedures, and requirements for NEs. For details about data to prepare before a base station starts the automatic OMCH establishment procedure, see 3900 Series Base Station Initial Configuration Guide. For details about software and configuration file downloading, activation, and commissioning on a base station after the automatic OMCH establishment procedure is complete, see 3900 Series Base Station Commissioning Guide. This document applies to IP-based 3900 GSM series base stations, 3900 WCDMA series base stations, 3900 LTE series base stations, and 3900 multimode base stations.
1.2 Intended Audience

This document is intended for personnel who:

Are familiar with GSM, WCDMA, and LTE basics Need to understand Automatic OMCH Establishment Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions. There are two types of changes, which are defined as follows:

Feature change: refers to a change in the Automatic OMCH Establishment feature of a specific product version. Editorial change: refers to a change in wording or the addition of information that was not described in the earlier version.
Document Versions
The document version is Draft A (2012-12-30).
Draft A (2012-12-30)
This is a draft. This is a new document.
Draft A (2012-12-30)
1-1
2 Overview
2 Overview
2.1 Introduction
Operation and maintenance channels (OMCHs) are established between base stations and the operation maintenance center (OMC, either the M2000 or BSC). OMCHs are used to transmit operation and maintenance information about base stations and are classified as follows:

OMCHs between the single-mode base station, such as the eGBTS, NodeB, or eNodeB and the M2000, or between the GBTS and the BSC. OMCHs between the co-MPT multimode base station and the M2000. MPT is short for main processing and transmission unit. OMCHs between the separate-MPT multimode base station and the M2000. The separate-MPT multimode base station is comprised of multiple cascaded single-mode base stations and therefore has multiple OMCHs. For example, OMCHs for the separate-MPT UMTS/LTE dual-mode base station include the OMCH between the NodeB and the M2000, and the OMCH between the eNodeB and the M2000.
OMCHs between the eGBTS, NodeB, eNodeB, or co-MPT multimode base station and the M2000 are carried over Transmission Control Protocol (TCP). OMCHs between the GBTS and the BSC are carried over User Datagram Protocol (UDP). For details about the protocol stacks for OMCHs, see chapter 3 "OMCH Protocol Stacks."
One end of an OMCH is located at the main control board of a base station. Depending on the configuration of the main control board, multimode base stations are classified into co-MPT multimode base stations and separate-MPT multimode base stations. For co-MPT multimode base stations, GSM, UMTS, and LTE modes share the same main control board and OMCH. For separate-MPT multimode base stations, GSM, UMTS, and LTE modes have their respective main control boards and OMCHs. In this document, a base station is used if differentiation among GSM, UMTS, and LTE modes is not required. A GBTS, eGBTS, NodeB, eNodeB, co-MPT multimode base station, or separate-MPT multimode base station is used if differentiation among GSM, UMTS, and LTE modes is required.
The Automatic OMCH Establishment feature enables a powered-on base station, which is configured with hardware but no transmission information, to obtain OMCH configuration information through the transport network and automatically establish an OMCH to the M2000 or BSC. The base station then can automatically download software and configuration files from the M2000 or BSC over the established OMCH and activate them. After being commissioned, the base station enters the working state. This feature applies to base station deployment by plug and play (PnP). Figure 2-1 shows the automatic OMCH establishment phase during base station deployment by PnP.
Draft A (2012-12-30)
2-1
2 Overview
Figure 2-1 Automatic OMCH establishment phase during base station deployment by PnP
To establish an OMCH, a base station needs to obtain the following transmission configuration information:
Basic information, including its OM IP address, OM virtual local area network (VLAN) ID, the interface IP address, the interface IP address mask, the IP address of the next-hop gateway, the IP address of the M2000 or BSC, and the IP address mask of the M2000 or BSC. Security-related information, including the Certificate Authority (CA) name, transmission protocol (HTTP or HTTPS) used by the CA, CA address, CA port number, CA path, and IP address of the security gateway (SeGW). Obtaining the operator's CA information is required only when the base station needs to use digital certificates issued by the operator's CA to perform identity authentication with other NEs.
For details about how the base station obtains the preceding information, see chapter 4 "Obtaining Transmission Configuration Information."
2.2 Benefits
With the Automatic OMCH Establishment feature, a base station can establish OMCHs by network communication without requiring operations at the local end. This implements remote base station deployment by PnP, thereby facilitating base station deployment and reducing the deployment cost and time.
Draft A (2012-12-30)
2-2
2 Overview
2.3 Application Networking Scenarios

The Automatic OMCH Establishment feature applies to base station deployment by PnP in Internet Protocol Security (IPSec) or non-IPSec networking scenarios. In this document, the IPSec or non-IPSec networking indicates that the IP layer communication between the base station and other NEs is secured or not secured by IPSec, respectively. Table 2-1 describes the application networking scenarios for the Automatic OMCH Establishment feature. Table 2-1 Application networking scenarios Networking Scenario Non-IPSec Description IPSec does not secure Dynamic Host Configuration Protocol (DHCP) packets, OMCH data, service data, signaling data, or clock data. IPSec secures DHCP packets, OMCH data, and all or some of the other data. IPSec secures OMCH data and all or some of the other data. It does not secure DHCP packets. IPSec secures service and signaling data. It neither secures OMCH data nor all or some of the other data.
IPSec
Scenario 1 Scenario 2 Scenario 3:
For details about how the single-mode base station and co-MPT multimode base station obtain OMCH configuration information and establish OMCHs in different scenarios, see chapter 5 "Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station." For details about how the separate-MPT multimode base station obtains OMCH configuration information and establishes OMCHs in different scenarios, see chapter 6 "Automatic OMCH Establishment by the Separate-MPT Multimode Base Station."
Draft A (2012-12-30)
2-3
3 OMCH Protocol Stacks

3.1 Non-IPSec Networking Scenario
Figure 3-1 shows the protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT multimode base station and the M2000 in non-IPSec networking scenarios. Figure 3-1 Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT multimode base station and the M2000 (non-IPSec networking)
As shown in Figure 3-1, an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT multimode base station and the M2000 is carried over TCP and Secure Sockets Layer (SSL), of which SSL is optional. The eGBTS, NodeB, eNodeB, or co-MPT multimode base station listens to the TCP connection establishment request with a specific TCP port number from the M2000, and establishes the TCP connection to the M2000 as requested. After the TCP connection is established, the M2000 initiates an OMCH establishment request to the eGBTS, NodeB, eNodeB, or co-MPT multimode base station. The M2000 can use SSL to perform encryption and authentication for OMCHs and enable the establishment of SSL-based OMCHs. SSL uses the public key infrastructure (PKI), with which the communication between the base station and the M2000 is protected against eavesdropping and therefore confidentiality and reliability are guaranteed. However, the M2000 should not use digital certificate to authenticate a base station if SSL-based OMCHs are to be established during base station deployment by PnP. For details about SSL, see SSL Feature Parameter Description. Figure 3-2 shows the protocol stacks for an OMCH between the GBTS and the BSC in non-IPSec networking scenarios.
Draft A (2012-12-30)
3-1
Figure 3-2 Protocol stacks for an OMCH between the GBTS and the BSC (non-IPSec networking)
As shown in Figure 3-2, an OMCH between the GBTS and the BSC is carried over UDP. The GBTS listens to the UDP connection establishment request with a specific UDP port number from the BSC, and establishes the UDP connection to the BSC as requested. After the UDP connection is established, the BSC initiates an OMCH establishment request to the GBTS.
3.2 IPSec Networking Scenario

In IPSec networking scenarios, OMCH data can be secured or not secured by IPSec. Figure 3-3 shows the networking scenario in which IPSec secures OMCH data. 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. NEs in the untrusted domain cannot access the NEs in the trusted domain. After a base station starts, it establishes an IPSec tunnel to the SeGW. Packets from the base station are sent over the IPSec tunnel to pass the untrusted domain and then forwarded by the SeGW to the M2000 or BSC in the trusted domain.
Draft A (2012-12-30)
3-2
Figure 3-4 shows the protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT multimode base station and the M2000 in IPSec networking scenarios. Figure 3-4 Protocol stacks for an OMCH between the eGBTS, NodeB, eNodeB, or co-MPT multimode base station and the M2000 (IPSec networking)
Figure 3-5 shows the protocol stacks for an OMCH between the GBTS and the BSC in IPSec networking scenarios. Figure 3-5 Protocol stacks for an OMCH between the GBTS and the BSC (IPSec networking)
In IPSec networking scenarios, IPSec secures base station data. IPSec is a security architecture defined by the Internet Engineering Task Force (IETF) and applicable to the IP layer. IPSec secures data communication by identity authentication, data encryption, data integrity, and address encryption. During the automatic OMCH establishment procedure, the base station establishes an IPSec tunnel to the SeGW and then an OMCH secured by the IPSec tunnel. The base station uses two types of source and destination IP addresses:
IP addresses in the untrusted domain, that is, the interface IP addresses used for communication with the SeGW in the untrusted domain after the base station starts.
Draft A (2012-12-30)
3-3
IP addresses in the trusted domain, that is, the IP addresses used for communication with the M2000, BSC, or a DHCP server that is built into the M2000 (referred to as M2000 DHCP server in this document) in the trusted domain.
The base station uses the interface IP address to access the untrusted domain. Unless otherwise specified, the base station uses the logical IP address to access the trusted domain. When using IPSec to secure data, an operator can determine whether to use digital certificates for identity authentication. If authentication by digital certificates is used, the PKI must be deployed. A base station interworks with the PKI using Certificate Management Protocol (CMP). During the automatic OMCH establishment procedure, the base station interworks with the operator's PKI to obtain the operator-issued device certificate and CA root certificate, and establishes an IPSec tunnel to the SeGW and then an OMCH secured by the IPSec tunnel. For details about IPSec tunnels, see IPSec Feature Parameter Description. For details about digital certificate management, see PKI Feature Parameter Description.
During the OMCH establishment procedure, the eGBTS, NodeB, eNodeB, or co-MPT multimode base station listens to specific TCP port numbers, and the GBTS listens to the UDP port numbers. For details, see Communication Matrix of 3900 Series Base Stations. The packets with these port numbers must be allowed to pass through the firewall between the base station and the DHCP server, M2000, or BSC. After establishing an OMCH to the M2000, the base station uses File Transmission Protocol (FTP) to download software and configuration files from the FTP server. FTP runs over TCP/IP, and therefore its transport layer can be secured using SSL. For details about FTP, see RFC 959. After establishing an OMCH to the BSC, the GBTS uses the proprietary protocol that runs over UDP to download software and configuration files from the BSC. IPSec networking is not supported by the following base stations:

GBTSs in which the GTMU provides the transmission port. NodeBs in which the WMPT provides the transmission port.
Draft A (2012-12-30)
3-4
4 Obtaining Transmission Configuration Information

4.1 DHCP Overview
4.1.1 Introduction
Before an OMCH is established, a base station is not configured with any data and cannot perform end-to-end communication with other NEs at the IP layer. To implement this communication, the base station needs to obtain the following information:
OMCH configuration data, including the OM IP address, OM VLAN ID, interface IP address, interface IP address mask, IP address of the next-hop gateway, IP address of the M2000 or BSC, and IP address mask of the M2000 or BSC. During base station deployment by PnP, if the base station needs to use digital certificates issued by the operator's CA to perform identity authentication with other NEs, it also needs to obtain the operator's CA information, including the CA name, CA address, CA port number, CA path, and transmission protocol (HTTP or HTTPS) used by the CA. In IPSec networking scenarios, the base station also needs to obtain SeGW information, including the SeGW IP address and SeGW local name.
The base station uses DHCP to obtain the preceding information. DHCP is used to allocate and distribute configuration parameters and adopts the client/server mode. The DHCP procedure involves the following logical NEs:

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

Figure 4-1 shows the interworking between a DHCP client and a DHCP server.
Draft A (2012-12-30)
4-1
Figure 4-1 DHCP interworking
1. After the DHCP client starts, it broadcasts a DHCPDISCOVER packet to search for an available DHCP server. The DHCPDISCOVER packet carries the identification information about the DHCP client. 2. The DHCP server responds to the DHCPDISCOVER packet with a DHCPOFFER packet. 3. The DHCP client sends a DHCPREQUEST packet to the DHCP server, requesting parameters such as an IP address. 4. The DHCP server sends a DHCPACK packet to the DHCP client to assign parameters such as an IP address. 5. If the assigned parameters cannot be used, for example, an assigned IP address has been used by other DHCP clients, the DHCP client sends a DHCPDECLINE packet to notify the DHCP server. 6. If the DHCP client does not need the assigned parameters any more, it sends a DHCPRELEASE packet to notify the DHCP server so that the DHCP server can assign these parameters to other DHCP clients.
4.1.3 DHCP Packet Format

Figure 4-2 shows the example format of DHCP packets shown in Figure 4-1.
Draft A (2012-12-30)
4-2
Figure 4-2 DHCP packet format
NOTE
The actual length and sequence of each field in a DHCP packet in software implementation may be different from those shown in Figure 4-2.
In a DHCP packet, the IP and UDP headers are in the standard format, and the DHCP header contains the DHCP control and configuration information. In the DHCP header, the fields related to automatic OMCH establishment are as follows:

yiaddr: This field carries the interface IP address of the base station. giaddr: This field carries the IP address of the DHCP relay agent.
Draft A (2012-12-30)
4-3
Option fields: These fields carry other configuration information. They are encoded in code-length-value (CLV) format and consist of many subcodes. Among them, Option 43 carries Huawei proprietary information elements (IEs) and most configuration information of the base station. For example, subcode 1 in Option 43 carries the electronic serial number (ESN) of the Huawei base station. Because Option 43 has a limited length, Option 224 is also used to carry Huawei proprietary IEs in SRAN8.0 or later.
For details about DHCP, see section "Dynamic Host Configuration Protocol (DHCP)" in RFC 2131 and "DHCP Options and BOOTP Vendor Extensions" in RFC 2132.
4.2 Mapping Between DHCP Clients and Servers

In this document, base stations act as DHCP clients. Table 4-1 describes the mapping between base stations and DHCP servers. Table 4-1 Mapping between base stations and DHCP servers Base Station Type Single-mode GBTS eGBTS NodeB eNodeB Multimode Co-MPT multimode base station Separate-MPT multimode base station DHCP Server in Non-IPSec Networking Scenarios BSC M2000 M2000 or RNC M2000 M2000 DHCP Server in IPSec Networking Scenarios In the trusted domain: M2000 DHCP server In the untrusted domain: public DHCP server
Same as that of each single-mode base station
Unless otherwise specified, "base station controller" in this document is a generic term for GSM and UMTS modes. The DHCP server and the M2000 are different logical communication entities, although they may be deployed on the same hardware. Therefore, this document distinguishes between the DHCP server and the M2000.
In SRAN8.0, if single-mode base stations or separate-MPT multimode base stations evolve to co-MPT multimode base stations, their DHCP servers must migrate to the M2000. Even if the evolution is not implemented, the migration is recommended, because it provides better function support and paves the way to future smooth upgrades and evolutions.
4.3 DHCP Procedure

4.3.1 Base Station Identification
Upon receiving a DHCP packet from a base station, the DHCP server finds and sends related configuration information to the base station based on the base station identification (BS ID) contained in the DHCP packet.
Draft A (2012-12-30)
4-4
The M2000 that matches SRAN8.0 uses the combination of the ESN and slot number or the combination of the deployment identifier (DID), subrack topology, and slot number as the BS ID. Base station controllers and M2000s that match versions earlier than SRAN8.0 use the combination of the ESN and NE type or the combination of the DID and NE type as the BS ID. The details about each element in the combinations are as follows:

ESN identifies the baseband unit (BBU) backplane of the base station. Each backplane has a unique ESN. The ESN is reported by the base station. DID is scanned into the base station using a barcode scanner connected to the USB port of the main control board. After being scanned into the base station, the DID is broadcast in all BBUs. All main control boards will record the DID and use it as the BS ID in the DHCP procedure. Subrack topology identifies the interconnection relationship between BBU subracks that are interconnected using UCIUs. The combination of the DID and subrack topology uniquely identifies a BBU subrack. Slot number identifies the number of the slot that accommodates the main control board. The slot number is used to differentiate main control boards in a BBU subrack. If the base station is configured with active and standby main control boards, the slot number is that of the active main control board. The slot number is reported by the base station. NE type indicates whether the base station works in the GSM, UMTS, or LTE mode.
When creating a base station commissioning task by PnP, operators must specify the ESN if the M2000 uses the combination of the ESN and slot number as the BS ID. The DID must be included in the base station configuration file if the M2000 uses the combination of the subrack topology and slot number as the BS ID.
4.3.2 Procedure for Obtaining Configuration Information in Non-IPSec Networking Scenarios

Procedure for Obtaining Configuration Information with No DHCP Relay Agent
A DHCP client and a DHCP server on the same Layer 2 (L2) network can directly communicate with each other. The L2 network is a subnet in which broadcast IP packets can be exchanged and forwarded by MAC addresses and VLAN IDs. An example is the Ethernet or a VLAN of the Ethernet. Figure 4-3 shows the procedure for a base station to obtain configuration information from a DHCP server when no DHCP relay agent is deployed. Figure 4-3 Procedure for obtaining configuration information with no DHCP relay agent
The procedure is as follows: After the base station is powered on, it broadcasts a DHCPDISCOVER packet with the BS ID. The DHCP server then sends configuration information to the base station based on the BS ID.
Draft A (2012-12-30)
4-5
The DHCP server can be deployed on the L2 network of the base station only when the DHCP server is deployed on the base station controller instead of the M2000. This is because DHCP packets carry the well-known UDP port number and the operating system of the M2000 always discards such packets. Therefore, the DHCP server deployed on the M2000 can process only DHCP packets forwarded by the DHCP relay agent, but not DHCP packets broadcast by the base station.
Procedure for Obtaining Configuration Information with a DHCP Relay Agent

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

In IPSec networking scenarios, a DHCP server in the trusted domain can be secured or not secured by IPSec. When the DHCP server is secured by IPSec, a public DHCP server in the untrusted domain must be deployed. Figure 4-5 shows the OMCH networking in this scenario.
Draft A (2012-12-30)
4-6
Figure 4-5 IPSec OMCH networking
Figure 4-6 shows the two procedures for the base station in Figure 4-5 to obtain transmission configuration information. Figure 4-6 Two procedures for obtaining transmission configuration information in IPSec networking scenarios
1. The base station exchanges DHCP packets with a public DHCP server to obtain information, such as the interface IP address for accessing the untrusted domain and the SeGW IP address. The base station also needs to obtain the CA IP address if digital certificates are required for identity authentication with the SeGW. This procedure is referred to as the first DHCP procedure.
Draft A (2012-12-30)
4-7
2. The base station negotiates with the SeGW on the Internet Key Exchange (IKE) security association (SA) and IPSec SA, and then establishes an IPSec tunnel. If digital certificates are required for identity authentication with the SeGW, the base station must apply to the CA for digital certificates that can be identified by the SeGW. 3. The base station exchanges DHCP packets with its M2000 DHCP server to obtain the OM IP address used for accessing the trusted domain. This procedure is referred to as the second DHCP procedure. The second DHCP procedure varies depending on IPSec networking scenarios. For details, see section 5.3.6 "Obtaining Formal Transmission Configuration Information from the Internal DHCP Server." During the first DHCP procedure, the public DHCP server runs DHCP. It may not support Huawei-defined DHCP Option fields and fail to identify the BS ID reported by the base station. If this occurs, the public DHCP server selects an IP address from the IP address pool and sends it to the base station. During the second DHCP procedure, the M2000 DHCP server sends configuration parameters to the base station based on the BS ID reported by the base station.
4.3.4 Procedure for Releasing Allocated Configuration Information

When a base station obtains configuration information from its M2000 DHCP server and does not need configuration information allocated by a public DHCP server, the base station sends a DHCPRELEASE message to the public DHCP server. After receiving the DHCPRELEASE message, the public DHCP server can redistribute allocated configuration information to other NEs. Figure 4-7 shows the procedure for releasing allocated configuration information. Figure 4-7 Procedure for releasing allocated configuration information
In addition to the preceding procedures, DHCP also supports the procedure for updating configuration information. However, base stations in SRAN8.0 do not support the procedure for updating configuration information.
4.4 Schemes for Obtaining VLAN Information for DHCP Packets

4.4.1 Overview
Packets sent by a base station on a VLAN-based network must carry the VLAN ID. Before an OMCH is established, that is, before the base station sends the first DHCP packet, it must automatically acquire VLAN information after it starts. After acquiring VLAN information, it sends DHCP packets with VLAN IDs to interwork with DHCP servers to obtain transmission configuration information. Table 4-2 describes the recommended schemes for the base station in SRAN8.0 to obtain VLAN information during deployment.
Draft A (2012-12-30)
4-8
Table 4-2 Obtaining VLAN information Scenario SN Scenario Description Base Station Deployment Mode By PnP By PnP Whether IPSec Secures OMCH Data No Yes Requirements for NEs How to Obtain VLAN Information
1 2
N/A
Using scheme 1
The SeGW initiates a request for IKE negotiation with the base station. The destination IP address of the request is the interface IP address that the base station uses to access the untrusted domain. The VLAN information in DHCP packets sent by the base station must be the same as the VLAN information in the configuration files of the base station. Using scheme 2
By PnP
Yes
The security policy allows the transmission of DHCP packets sent by DHCP servers or the M2000 to the base station. The L2 network is configured with the default VLAN ID or no VLAN ID. The next-hop gateway of the base station can periodically send ping packets to the interface IP address of the base station. N/A
By PnP
Yes
Using scheme 3
By PnP
Yes
Using scheme 4
By USB
Either Yes or No
From a USB flash drive
If a base station is deployed by USB, it imports transmission configuration information including VLAN configuration information from the USB. If the base station is deployed by PnP, the scheme for obtaining VLAN information varies depending on whether IPSec secures OMCH data and the capability of NEs:
If IPSec does not secure OMCH data, scheme 1 is used: The M2000 or BSC actively and periodically sends OMCH establishment requests to the base station. After receiving the requests, the next-hop gateway of the base station sends Address Resolution Protocol (ARP) packets to the base station. The base station then records VLAN IDs derived from ARP packets and includes recorded VLAN IDs in DHCP packets.
If IPSec secures OMCH data, any of the following schemes is used:

Scheme
1
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 4-9
Draft A (2012-12-30)

Scheme
2: The DHCP server on the M2000 periodically sends the base station empty packets with the destination IP address as the interface IP address of the base station. This enables the next-hop gateway of the base station to send ARP packets from which the base station derives VLAN information. 3: The base station sends DHCP packets with no VLAN ID, and the L2 network attaches a VLAN ID to DHCP packets sent by the base station. Therefore, the base station does not need to acquire VLAN information. 4: The next-hop gateway of the base station or other NEs periodically send packets to the base station or an idle address of the subnet in which the base station is deployed. This enables the next-hop gateway of the base station to send ARP packets from which the base station derives VLAN information.
Scheme
Scheme
4.4.2 Scheme 1
Scheme 1 applies to two scenarios:

IPSec does not secure OMCH data. Figure 4-8 shows the procedure for a base station to obtain VLAN information in this scenario. IPSec secures OMCH data and NEs meet specific requirements. Figure 4-9 shows the procedure for a base station to obtain VLAN information in this scenario.
Figure 4-8 Scheme 1 (IPSec does not secure OMCH data
1. The M2000 or BSC sends an OMCH establishment request to the OM IP address of the base station. 2. To forward the OMCH establishment request to the correct base station, the next-hop gateway of the base station broadcasts ARP packets to obtain the MAC address mapping the destination IP address of the request. The next-hop gateway or the L2 network attaches VLAN IDs to ARP packets so that correct VLAN IDs are contained in the ARP packets received by the base station. 3. The base station parses all received ARP packets and records the VLAN IDs contained in the packets. It may record the VLAN ID in an ARP packet destined for another base station. 4. The base station attempts to send all DHCP packets with recorded VLAN IDs. Only DHCP packets with correct VLAN IDs can reach the DHCP relay agent.
Draft A (2012-12-30)
4-10
Figure 4-9 Scheme 1 (IPSec secures OMCH data)
1. The M2000 or BSC sends an OMCH establishment request to the OM IP address of the base station. The request is forwarded to the SeGW. 2. The SeGW detects that the IPSec SA with the base station has not been established and sends an IKE negotiation request to the interface IP address of the base station. The request is routed to the next-hop gateway of the base station. 3. To forward the IKE negotiation request to the correct base station, the next-hop gateway of the base station broadcasts ARP packets to obtain the MAC address mapping the destination IP address of the request. The next-hop gateway or the L2 network attaches VLAN IDs to ARP packets so that correct VLAN IDs are contained in the ARP packets received by the base station. 4. The base station parses all received ARP packets and records the VLAN IDs contained in the 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 DHCP packets with correct VLAN IDs can reach the DHCP relay agent.
4.4.3 Scheme 2
Figure 4-10 shows the procedure for a base station to obtain VLAN information in scheme 2.
Draft A (2012-12-30)
4-11
Figure 4-10 Scheme 2
1. The M2000 sends a DHCPOFFER packet with no content to the interface IP address of the base station. The packet is forwarded to the next-hop gateway of the base station. 2. To forward the DHCPOFFER packet to the correct base station, the next-hop gateway of the base station broadcasts ARP packets to obtain the MAC address mapping the destination IP address of the request. The next-hop gateway or the L2 network attaches VLAN IDs to ARP packets so that correct VLAN IDs are contained in the ARP packets received by the base station. 3. The base station parses all received ARP packets and records the VLAN IDs contained in the packets. It may record the VLAN ID in an ARP packet destined for another base station. 4. The base station attempts to send all DHCP packets with recorded VLAN IDs. Only DHCP packets with correct VLAN IDs can reach the DHCP relay agent.
4.4.4 Scheme 3
Figure 4-11 shows the procedure for a base station to obtain VLAN information in scheme 3. Figure 4-11 Scheme 3
1. The base station sends a DHCP packet with no VLAN ID.
Draft A (2012-12-30)
4-12
2. The L2 network between the base station and the next-hop gateway of the base station automatically attaches the default VLAN ID to the DHCP packet. The default VLAN ID is the same as the VLAN ID required for deploying the base station. With the correct VLAN ID, the DHCP packet can be forwarded over the L2 network to the DHCP relay agent and then reach the DHCP server.
4.4.5 Scheme 4
Figure 4-12 shows the procedure for a base station to obtain VLAN information in scheme 4. Figure 4-12 Scheme 4
1. After the next-hop gateway of the base station is configured with the service level agreement (SLA), it periodically sends ping packets to the interface IP address of the base station or an IP address on the network segment of the base station. 2. To forward ping packets to the correct base station, the next-hop gateway of the base station broadcasts ARP packets to obtain the MAC address of the base station mapping the destination IP address of the ping packets. The ARP packets received by the base station carry correct VLAN IDs. 3. The base station parses all received ARP packets and records the VLAN IDs contained in the packets. It may record the VLAN ID in an ARP packet destined for another base station. 4. The base station attempts to send all DHCP packets with recorded VLAN IDs. Only DHCP packets with correct VLAN IDs can reach the DHCP relay agent.
Draft A (2012-12-30)
4-13
5 Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station
5.1 Overview
This chapter describes the automatic OMCH establishment procedures implemented by the single-mode base station and co-MPT multimode base station in IPSec or non-IPSec networking scenarios, and the procedures' requirements for NEs. In IPSec networking scenarios, the network is divided into the untrusted domain and the trusted domain. Depending on NE distribution in the untrusted domain and the trusted domain, IPSec networking scenarios are classified as follows:

Scenario 1: IPSec secures OMCH data and DHCP packets. Scenario 2: IPSec secures OMCH data, but not DHCP packets. Scenario 3: IPSec secure service data, but not OMCH data or DHCP packets.
5.2 Automatic OMCH Establishment in Non-IPSec Networking Scenarios

5.2.1 Introduction to Non-IPSec Networking
Figure 5-1 shows a non-IPSec networking scenario in which IPSec does not secure OMCH data. Figure 5-1 Non-IPSec networking
This networking has the following characteristics:

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

Figure 5-2 shows the automatic OMCH establishment procedure in non-IPSec networking scenarios.
Draft A (2012-12-30)
5-1
Figure 5-2 Automatic OMCH establishment in non-IPSec networking scenarios
1. After a base station commissioning by PnP task is created on the M2000, the M2000 or BSC periodically sends an SSL-based or plaintext-based OMCH establishment request to the base station. In the request, the source IP address is the IP address of the M2000 and the destination IP address is the OM IP address of the base station. After the next-hop gateway of the base station receives the request, it broadcasts ARP packets to the base station to obtain the MAC address mapping the interface IP address of the base station.
The next-hop gateway of the base station broadcasts ARP packets each time it receives a TCP connection request sent periodically by the M2000.
2. The base station obtains VLAN information. For details, see section 4.4 "Schemes for Obtaining VLAN Information for DHCP Packets." 3. The base station first sends DHCP packets with no VLAN ID and then DHCP packets with VLAN IDs. By exchanging DHCP packets with its next-hop gateway and DHCP server, the base station obtains the OMCH configuration data and validates the data. 4. In response to the ARP packets and the OMCH establishment request, the base station establishes an OMCH to the M2000 or BSC. The DHCP server then sends related configuration files to the base station based on the BS ID.
5.2.3 Configuration Requirements for the DHCP Server

The DHCP server of a base station must be configured with the following:

A route to the base station or the network segment of the base station. Parameters to be used during the DHCP procedure. These parameters are contained in the DHCP packet headers, Option fields defined by RFC 2132, and subcodes of Option 43 defined by Huawei.
Table 5-1 lists the parameters to be contained in the DHCP packet headers. Table 5-1 Parameters to be contained in the DHCP packet headers in non-IPSec networking scenarios Parameter Name Interface IP Address Mapping DHCP Field yiaddr Length (Bytes) 4 Parameter Description Mandatory or Optional Mandatory DHCP Packet Involved

Interface IP address of the base station
DHCPOFFER DHCPACK
Draft A (2012-12-30)
5-2
Parameter Name Relay Agent IP
Mapping DHCP Field giaddr
Length (Bytes) 4
Parameter Description
Mandatory or Optional Optional
DHCP Packet Involved

IP address of the DHCP relay agent deployed on the network, if any. Broadcast packets (Discovery and Request packets) sent by the base station do not carry this IP address, and the DHCP relay agent adds this IP address to DHCP packets to be forwarded. For details, see RFC 2131.
DHCPDISCOVERY DHCPOFFER DHCPREQUEST DHCPACK
Table 5-2 lists the parameters to be contained in Option fields defined by RFC 2132. Table 5-2 Parameters to be contained in DHCP Option fields in non-IPSec scenarios Parameter Name Subnet Mask Mapping DHCP Option 1 Length (Bytes) 4 Parameter Description DHCP Packet Involved
Subnet mask of a DHCP client
DHCPOFFER DHCPACK DHCPOFFER DHCPACK DHCPDISCOVER DHCPREQUEST DHCPOFFER DHCPACK DHCPOFFER DHCPACK DHCPDISCOVER DHCPREQUEST DHCPOFFER DHCPACK
Router Option
N*4
List of the IP addresses of routers deployed in a DHCP client's subnet Vendor-specific information exchanged between a DHCP client and a DHCP server
Vendor Specific Information
43
0-255
IP Address Lease Time DHCP Message Type
51
Lease time of an assigned IP address Value: 1: DHCPDISCOVER 2: DHCPOFFER 3: DHCPREQUEST 5: DHCPACK
53
Server Identifier
54
IP address of a DHCP server
DHCPOFFER DHCPACK DHCPOFFER DHCPACK
Renewal (T1) Time Value
58
Interval from address assignment to the transition to the RENEWING state
Draft A (2012-12-30)
5-3
Parameter Name Rebinding (T2) Time Value Vendor class identifier Client-identifier
Mapping DHCP Option 59
Length (Bytes) 4
Interval from address assignment to the transition to the REBINDING state Vendor type and client configuration Unique identifier of a DHCP client
DHCPOFFER DHCPACK DHCPDISCOVER DHCPREQUEST DHCPDISCOVER DHCPREQUEST
60
0-255
61
0-255
Table 5-3 lists the parameters to be contained in subcodes of Option 43 defined by Huawei. Table 5-3 Parameters to be contained in subcodes of option 43 in non-IPSec scenarios Parameter Name ESN Mapping Subcode 1 Length (Bytes) 20 Parameter Description ESN of the BBU backplane. It is used by a DHCP server to determine the location and BBU subrack of the base station. Slot number of the first main control board Mandatory or Optional Mandatory DHCP Packet Involved
DHCPDISCOV ER DHCPOFFER DHCPREQUES T DHCPACK
MPT 1st Slot Number
251
Mandatory
DHCPDISCOV ER DHCPOFFER DHCPREQUES T DHCPACK DHCPOFFER DHCPACK
MPT 2nd Slot Number
249
Slot number of the second main control board
Mandatory only if the base station is configured with active/standby or primary/seconda ry main control boards. Optional. The default value is 0.
OM Bearing Board
250
Value:
DHCPOFFER DHCPACK
0: An OMCH is established on the
Draft A (2012-12-30)
5-4
Parameter Name
Mapping Subcode
Length (Bytes)
Parameter Description panel. Use this value for single-mode base stations.
Mandatory or Optional
1: An OMCH is established on the backplane.
If the base station is configured with only one BBU, the DID serves the same purpose as the ESN. DID 27 1 to 64 If the base station is configured with multiple BBUs that are interconnecte d using UCIUs, these BBUs use the same DID. Interconnectio n relationship between the BBU accommodati ng the main control board that sends the DHCP packets and other BBUs if these BBUs are interconnecte d using UCIUs. The DHCP server uses the combination of the DID, subrack
Optional. The DID becomes mandatory after it is scanned.
Subrack Topo
246
1 to 16
Mandatory
Draft A (2012-12-30)
5-5
Parameter Name
Mapping Subcode
Length (Bytes)
Parameter Description topology, and slot number to identify the configuration file of the base station.
OM Interface Type
Transmission interface of the base station: Ethernet or E1.

NOTE
Optional The default value is Ethernet.
DHCPOFFER DHCPACK
If an Ethernet interface is used as the transmission interface, the OMCH managed object (MO) in configuration files of the base station must be bound to a route, or the peer IP address must be the IP address of the M2000 or the next-hop gateway of the base station.
OM Interface Slot Number
248
Slot number of the main control board if the transmission interface is provided by the main control board, or the slot number of the UTRP board if the transmission interface is provided by the UTRP board.
Mandatory in SRAN8.0 or later only if an Ethernet interface is used as the transmission interface. If this parameter is not specified, the base station automatically identifies the slot number.
DHCPOFFER DHCPACK
Draft A (2012-12-30)
5-6
Parameter Name OMCH Interface Port Number
Mapping Subcode 247
Length (Bytes) 1
Parameter Description Port number of the transmission interface of the base station
Mandatory or Optional Mandatory in SRAN8.0 or later only if an Ethernet interface is used as the transmission interface. If this parameter is not specified, the base station automatically identifies the port number. Mandatory in SRAN8.0 or later only if an Ethernet interface is used as the transmission interface. If this parameter is not specified, the base station automatically identifies the numbers of the cabinet, subrack, and slot. Mandatory

DHCPOFFER DHCPACK
OMLOCATION
51
The numbers of the cabinet, subrack, and slot that accommodate the main control board where the OMCH is located.
DHCPOFFER DHCPACK
OM IP Address
Local IP address of the OMCH Local IP address mask of the OMCH Peer IP address of the OMCH This parameter and OMCH Route Mask collectively identify an OMCH route. Peerl IP address mask
DHCPOFFER DHCPACK DHCPOFFER DHCPACK DHCPOFFER DHCPACK
OM IP Address Subnet Mask M2000 IP Address
Mandatory
Optional
M2000 IP Subnet Mask
Optional
DHCPOFFER
Draft A (2012-12-30)
5-7
Parameter Name
Mapping Subcode
Length (Bytes)
Parameter Description of the OMCH

NOTE
DHCPACK
In the decimal equivalent of this parameter value, 01 is not allowed.
OM Vlan ID
11
VLAN ID of the OMCH
Mandatory only if VLAN information is configured and an Ethernet interface is used as the transmission interface Optional
DHCPOFFER DHCPACK
OM Vlan Priority
12
VLAN priority of the OMCH IP address of the BSC Next-hop IP address of the base station
DHCPOFFER DHCPACK DHCPOFFER DHCPACK DHCPOFFER DHCPACK
BSC IP
13
Mandatory for the GSM mode Mandatory
OM Next Hop IP Address
17
When creating a base station commissioning by PnP task on the M2000, deployment engineers can export configuration information listed in Table 5-3 to the DHCP server. Deployment engineers can manually modify the configuration information for the DHCP server only on the M2000 GUI. Deployment may fail if the DHCP server is not configured with mandatory parameters listed in Table 5-3 or optional parameters that must be configured in certain scenarios.
5.2.4 Configuration Requirements for NEs

Table 5-4 lists the configuration requirements for NEs during base station deployment by PnP in the non-IPSec networking scenario shown in Figure 5-1. Table 5-4 Configuration requirements for NEs NE Base station Next-hop L2 NE of the base station L2 NEs Requirement None (Optional) Is configured with VLAN information. VLAN configuration is required only when the L2 network adopts VLANs.
Allow the transmission of DHCP broadcast and unicast packets without filtering or modifying DHCP packets. Are configured with the VLAN forwarding function that matches the base station.
Draft A (2012-12-30)
5-8
NE Next-hop L3 NE of the base station
Requirement

Is enabled with the DHCP relay agent function. Is configured with the IP address of the DHCP server. Generally, the IP address is that of the M2000. If a Network Address Translation (NAT) server is deployed, the IP address is the IP address converted by the NAT server. Is configured with a route to the DHCP server. Is configured with a route to the OM IP address of the base station if the OM IP address is not the interface IP address.
L3 NEs M2000 or BSC DHCP server FTP server
Are configured with routes to the OM IP address of the base station, the IP address of the M2000, and the DHCP relay agent. Is configured with a route to the OM IP address of the base station. Is configured with a route to the DHCP relay agent.

Is configured with a route to the OM IP address of the base station. Stores software and configuration files of the base station in the specified directory. Provides access rights, such as the user name and password, for the base station.
5.3 Automatic OMCH Establishment in IPSec Networking Scenario 1

5.3.1 Introduction to IPSec Networking Scenario 1
Figure 5-3 shows IPSec networking scenario 1, in which IPSec secures both OMCH data and DHCP packets. Figure 5-3 IPSec networking scenario 1
Draft A (2012-12-30)
5-9
A public DHCP server and an M2000 DHCP server are deployed in the untrusted domain and the trusted domain, respectively. The base station obtains from the public DHCP server the transmission configuration information required for establishing a temporary IPSec tunnel to the SeGW and obtains from the M2000 DHCP server the formal transmission configuration 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 SeGW before being transmitted to the M2000 or BSC in the trusted domain. A CA is deployed. During base station deployment, the CA can be accessed by NEs or using an IP address (for example, the interface IP address of the base station) in the untrusted domain. After the base station starts, it must apply to the CA for operator-issued digital certificates before connecting to the SeGW. After obtaining the certificates, the base station negotiates with the SeGW to establish an IPSec tunnel.

In IPSec networking scenario 1, the base station obtains configuration information as follows: 1. Obtains the following information from the public DHCP server:
Interface
IP address used for accessing NEs in the untrusted domain.
Configuration
information used for establishing an IPSec tunnel to the SeGW. The information includes the SeGW configuration data and the CA configuration data.
2. Obtains digital certificates from the CA. 3. After establishing the IPSec tunnel, obtains the OMCH configuration data from the M2000 DHCP server. The information is used for accessing NEs in the trusted domain and referred to as formal transmission configuration information in this document. The interface IP address obtained from the public DHCP server can be the same as or different from that obtained from the M2000 DHCP server. Figure 5-4 shows the automatic OMCH establishment procedure in IPSec networking scenario 1.
Draft A (2012-12-30)
5-10
Figure 5-4 Automatic OMCH establishment procedure in IPSec networking scenario 1
1. The base station obtains VLAN information. For details, see section 4.4 "Schemes for Obtaining VLAN Information for DHCP Packets." 2. Using the DHCP procedure, the base station obtains from the public DHCP server the transmission configuration information used for establishing a temporary IPSec tunnel. The information includes the interface IP address of the base station, CA configuration data, SeGW configuration data, and M2000 DHCP server IP address. For details about the configuration information on the public DHCP server, see section 5.2.3 "Configuration Requirements for the DHCP Server." 3. Using CMPv2, the base station applies to the CA for an operator-issued device certificate and a CA root certificate. The base station adds the obtained CA root certificate to the default trusted certificate list so that it can authenticate peer NEs, such as the SeGW. If the application for operator-issued digital certificates fails or receives no response within about 30 seconds, the preconfigured digital certificates are used for establishing an IPSec tunnel.
NOTE
The operator's CA must be configured with the Huawei-issued CA root certificate to authenticate the device certificate of the base station. The base station uses the Huawei-issued device certificate for identity authentication by the CA.
4. The base station establishes a temporary IPSec tunnel to the SeGW. For details about the security parameters used by the base station during the temporary IPSec tunnel establishment, see section 5.3.4 "Establishing a Temporary IPSec Tunnel." 5. With protection from the temporary IPSec tunnel, the base station obtains formal transmission configuration information from the M2000 DHCP server in different ways, depending on whether the IP address used for accessing the trusted domain and the M2000 DHCP server IP address are available. For details, see section 5.3.6 "Obtaining Formal Transmission Configuration Information from the Internal DHCP Server." 6. The base station releases the temporary IPSec tunnel and uses formal transmission configuration information to establish a formal IPSec tunnel to the SeGW. For details, see section 5.3.7 "Establishing a Formal IPSec Tunnel." 7. With protection from the formal IPSec tunnel, the base station waits 10 minutes for the SSL-based or plaintext-based OMCH establishment request from the M2000 or BSC and finally establishes an OMCH to the M2000 or BSC. If an OMCH is successfully established between the M2000 and base
Draft A (2012-12-30)
5-11
station within 10 minutes, base station deployment by PnP ends. Otherwise, base station deployment by PnP is restarted.
5.3.3 Configuration Requirements for the Public DHCP Server

The public DHCP server must be configured with the parameters listed in Table 5-5 as well as a route to the base station or the network segment of the base station. Unless otherwise specified, these parameters are contained in subcodes of Option 43 in DHCP packets. Table 5-5 Parameters to be configured on the public DHCP server Classifica tion CA informatio n Parameter Name PKI SERVER IP Mapping Subcode 35 Length (Bytes) 4 Parameter Description IP address of the CA Mandatory or Optional Mandatory only if identity authenticati on by digital certificates is required and the CA URL is not configured. These parameters collectively identify and equal the URL of the CA. These four parameters cannot be configured if the CA URL has been configured. Mandatory only if the following parameters are not configured when authenticati on by digital certificates is required: PKI SERVER IP, CA protocol type, CA port, and

DHCPOFFE R DHCPACK DHCPOFFE R DHCPACK DHCPOFFE DHCPACK
CA protocol type
39
Protocol used to access the CA: HTTP or HTTPS HTTP or HTTPS port number of the CA Path used for accessing digital certificates on the CA
CA port
36
CA Path
37
1 to 60
DHCPOFFE DHCPACK
CA URL
44
1 to 128
URL used for accessing the digital certificate path. This parameter is configurable only when the base station and CA use CMPv2. The CA URL format is as follows: http(s)://CAIP: CAport/CAPath
DHCPOFFE DHCPACK
Draft A (2012-12-30)
5-12
Classifica tion
Parameter Name
Mapping Subcode
Length (Bytes)
Mandatory or Optional CA Path.
CA Name
38
1 to 127
Name of the CA
Mandatory only if the base station uses the digital certificates for identity authenticati on Mandatory only if the base station needs to access the M2000 DHCP server through the SeGW
DHCPOFFE DHCPACK
SeGW informatio n
Public SeGW IP Address
18
IP address of the public SeGW in IPSec networking scenarios. This parameter is allocated by the public DHCP server and used during DHCP interworking between the base station and the M2000 DHCP server. Local name of the public SeGW. It is used by the base station to authenticate the public SeGW in IPSec networking scenarios.
DHCPOFFE DHCPACK
Public SeGW Local Name
31
1 to 32
Optional when the SeGW is configured
DHCPOFFE DHCPACK
Internal DHCP server IP address (list)
Internal DHCP Server IP Address (List)
42
N*4
IP address of the M2000 DHCP server that sends transmission configuration information to the base station. In SRAN8.0, a maximum of eight M2000
Optional. If this parameter is configured, the base station can send unicast DHCP packets to the DHCP server even if the SeGW
DHCPOFFE DHCPACK
Draft A (2012-12-30)
5-13
Classifica tion
Parameter Name
Mapping Subcode
Length (Bytes)
Parameter Description DHCP server addresses can be configured.
Mandatory or Optional cannot send any DHCP server IP address to the base station. Mandatory
Transmissi on configurati on informatio n for the base station
Interface IP Address
Carried in the yiaddr field in DHCP packet headers Carried in DHCP option 1 Carried in DHCP option 3
DHCPOFFE DHCPACK
Interface IP Address mask Next-hop Gateway IP Address
Mandatory
DHCPOFFE DHCPACK DHCPOFFE DHCPACK
Mandatory
All IP addresses or URLs listed in Table 5-5 except Internal DHCP Server IP Address (List) can be used only in the untrusted domain. Particularly, NEs in the untrusted domain must have access to the CA IP address and the CA URL. If the base station cannot access the CA, it cannot obtain any operator-issued certificate.
NOTE
In IPSec networking scenario 1, the public DHCP server assigns an interface IP address in the IP address pool to the base station, without parsing the BS ID contained in Option 43. Therefore, the BS ID contained in DHCP packets is meaningless in such a scenario.
5.3.4 Establishing a Temporary IPSec Tunnel

After the base station obtains the transmission configuration information (including its interface IP address, the SeGW IP address, and the CA IP address) from the public DHCP server, the base station obtains digital certificates from the CA and attempts to establish a temporary IPSec tunnel to the SeGW. For details about the temporary IPSec tunnel establishment, see IPSec Feature Parameter Description. This section describes the security parameters (algorithms) used by the base station during deployment by PnP. IKEv1 and IKEv2 are incompatible. During base station deployment by PnP, the base station cannot predict the IKE version used by the SeGW. If the base station successfully negotiated an IKE version with the SeGW, the base station preferentially tries this IKE version. Otherwise, the base station tries IKEv2 before IKEv1.
IKE SA Negotiation
During IKE SA negotiation in the normal operation of the base station, the base station supports a large number of algorithm groups. However, during base station deployment by PnP, the base station only supports the 48 algorithm groups (see Table 5-6) in the IKEv2 proposal and the 120 algorithm groups (see Table 5-7) in the IKEv1 proposal.
Draft A (2012-12-30)
5-14
Table 5-6 Algorithms in the IKEv2 proposal Encryption Algorithm 3DES AES128 AES192 AES256 Authentication Algorithm SHA1 AES_XCBC_96 N/A N/A Diffie-Hellman Group DH_GROUP2 DH_GROUP14 DH_GROUP15 N/A PRF Algorithm HMAC_SHA1 AES128_XCBC N/A N/A
Table 5-7 Algorithms in the IKEv1 proposal Encryption Algorithm Authentication Algorithm Diffie-Hellman Group Authentication Method (Only IKEv1) DES 3DES AES128 AES192 AES256 MD5 SHA1 DH_GROUP1 DH_GROUP2 DH_GROUP14 DH_GROUP15 PSK RSA-SIG DSS-SIG -
NOTE
During base station deployment by PnP, when performing IKEv1 negotiation, the base station tries only the perfect forward secrecy (PFS) value DISABLE, not PFS_GROUP1 or PFS_GROUP2.
To establish a temporary IPSec tunnel, the base station preferentially tries the five algorithm groups listed in Table 5-7 in sequence. If this fails, the base station tries the other groups until it establishes an IPSec tunnel. To increase the deployment success rate and shorten the deployment duration, it is recommended that security parameters in configuration files of the base station follow the configurations listed in Table 5-8. Table 5-8 The first five algorithm groups in the IKE proposal Sequence 1 2 3 4 5 Encryption Algorithm AES128 3DES AES256 AES192 AES128 Authentication Algorithm SHA1 SHA1 AES_XCBC_96 SHA1 SHA1 Diffie-Hellman Group DH-Group2 DH-Group2 DH_GROUP15 DH_GROUP14 DH_GROUP14 PRF Algorithm (Only IKEv2) HMAC-SHA1 HMAC-SHA1 AES128_XCBC HMAC_SHA1 HMAC_SHA1
Draft A (2012-12-30)
5-15
IPSec SA Negotiation
During IPSec SA negotiation in the normal operation of the base station, the base station supports ESP and AH authentication in tunnel or transport mode. However, during base station deployment by PnP, the base station only supports ESP authentication in tunnel mode. During IPSec SA negotiation in the normal operation of the base station, the base station supports multiple encryption and authentication algorithm groups. However, during base station deployment by PnP, the base station supports only the encryption and authentication algorithm groups listed in Figure 5-5. It first tries the six algorithm groups marked in green. If this fails, it tries the six algorithm groups marked in gray. Once IKE negotiation is successful using an algorithm group, the base station applies this algorithm group. The base station tries IKE version and algorithm groups in the following priority sequence: 1. IKEv2 and algorithm groups marked in green 2. IKEv2 and algorithm groups marked in gray 3. IKEv1 and algorithm groups marked in green 4. IKEv1 and algorithm groups marked in gray Figure 5-5 Encryption and authentication algorithms in IPSec proposal
Authentication algorithm Encryption algorithm 3DES AES128 AES192 AES256 SHA1 SHA256 AES-XCBC-MAC-96
NOTE
During base station deployment by PnP, the base station does not try all supported security parameters (such as the DES algorithm) when establishing an IPSec tunnel. This is because trying all supported combinations of security parameters may take a long time. During base station deployment by PnP, the base station must use tunnel mode instead of transfer mode as the encapsulation mode when establishing an IPSec tunnel. This is because the M2000, BSC, DHCP server, and FTP server do not support IPSec.
If the security parameters and their settings on the base station or SeGW side are inconsistent with those tried during base station deployment by PnP, OMCH establishment may fail, leading to deployment failures. Therefore, ensure there is consistency between the parameters and settings.
5.3.5 Configuration Requirements for the Internal DHCP Server

The M2000 DHCP server must be configured with the parameters listed in Table 5-9 as well as the parameters listed in Table 5-3. These parameters are contained in Option 43 in DHCP packets. Table 5-9 Parameters specific to the M2000 DHCP server in IPSec networking scenario 1 Classification SeGW Parameter Name Serving Mapping Subcode 20 Parameter Description IP address of the Mandatory or Optional Mandatory DHCP Packet Involved
DHCPOFFER
Draft A (2012-12-30)
5-16
Classification information
Parameter Name SecGW IP
Mapping Subcode
Parameter Description serving SeGW in IPSec networking scenarios
DHCPACK
Serving SecGW Local Name
32
Local name of the serving SeGW. It is provided by the base station to authenticate the serving SeGW in IPSec networking scenarios
Optional
5.3.6 Obtaining Formal Transmission Configuration Information from the Internal DHCP Server
RFC 4306, the standard protocol for IKEv2, defines the MODE-CONFIG mode in which the base station uses the configuration payload (CP) to apply to the SeGW for certain configuration information. Using the MODE-CONFIG mode during IKE negotiation, the base station can obtain one temporary logical IP address used for accessing the trusted domain and one M2000 DHCP server IP address. The base station can also interwork with the public DHCP server to obtain a maximum of eight M2000 DHCP server IP addresses.
NOTE
In IKEv1, CP is not standardized and is referred to as MODE-CONFIG, which is supported only by the base station in aggressive mode. For details about the MODE-CONFIG, see RFC4306 Internet Key Exchange (IKEv2) Protocol.
The base station follows procedures listed in Table 5-10 to obtain formal transmission configuration information from the M2000 DHCP server, depending on whether the logical IP address used for accessing the untrusted domain and any M2000 DHCP server IP address are available. Table 5-10 Obtaining formal transmission configuration information from the M2000 DHCP server If...
Then...
Configuration Requirements for NEs See Table 5-11.
The base station has obtained the interface IP address for accessing the untrusted domain, and has used the MODE-CONFIG mode during IKE negotiation to obtain the logical IP address for accessing the trusted domain. The base station has obtained one or more M2000 DHCP server IP addresses, using either the DHCP procedure or the MODE-CONFIG mode during IKE negotiation.
The base station uses the logical IP address for accessing the trusted domain as the source IP address, and uses any M2000 DHCP server IP address as the destination IP address. The base station then unicasts DHCP packets to each M2000 DHCP server. Only the M2000 DHCP server that has the correct BS ID sends configuration information to the base station. The base station automatically configures an access control list (ACL) rule that allows DHCP packets to reach the base station.
Draft A (2012-12-30)
5-17
If...
Then... In the ACL rule, both the source and destination IP addresses can be any address.
Configuration Requirements for NEs
The base station has obtained the interface IP address for accessing the untrusted domain, but not the logical IP address for accessing the trusted domain. The base station has obtained one or more M2000 DHCP server IP addresses.
The base station uses the interface IP address for accessing the untrusted domain as the source IP address, and uses any M2000 DHCP server IP address as the destination IP address. The base station then unicasts DHCP packets to each M2000 DHCP server. Only the M2000 DHCP server that has the correct BS ID sends configuration information to the base station. The base station automatically configures an ACL rule that allows DHCP packets to reach the base station. In the ACL rule, the source IP address is the interface IP address and the destination IP address is an M2000 DHCP server IP address. The base station uses 0.0.0.0 as the source IP address and 255.255.255.255 as the destination IP address to broadcast DHCP packets over an IPSec tunnel. The packets are encapsulated over the IPSec tunnel before reaching the SeGW. The base station automatically configures an ACL rule that allows DHCP packets to reach the base station. In the ACL rule, the source UDP port number is 68 and the destination UDP port number is 67.
See Table 5-12.
The base station has not obtained the logical IP address for accessing the trusted domain or any M2000 DHCP server IP address.
See Table 5-13.
Table 5-11 Configuration requirements for NEs (1) NE Public DHCP server Requirement Is configured with one to eight M2000 DHCP server IP addresses only if the SeGW is not configured with any M2000 DHCP server IP address.
SeGW
Supports the MODE-CONFIG mode so that the SeGW sends a temporary logical IP address and an M2000 DHCP server IP address to the base station. Alternatively, the SeGW sends a
Draft A (2012-12-30)
5-18
NE
Requirement temporary logical IP address and the public DHCP server sends an M2000 DHCP server IP address. It is recommended that the operator plan all temporary logical IP addresses for accessing the trusted domain on the same network segment and on a different network segment from the OM IP address of the base station.
Automatically generates an ACL rule after using the MODE-CONFIG mode to send the M2000 DHCP server IP address. In the ACL rule, the source IP address is the temporary logical IP address for accessing the trusted domain and the destination IP address can be any IP address. This eliminates the need to manually configure associated ACL rules. If an ACL rule is manually configured that the source IP address is the temporary logical IP address for accessing the trusted domain, the IP addresses of all M2000 DHCP servers must be on the network segment defined by this ACL rule. Are configured with the firewall policy or the packet filtering policy so that they allow the transmission of packets with 67 or 68 as the source and destination UDP port number. Are configured with a route to the logical IP address for accessing the trusted domain or network segment of the logical IP address so that related packets can be routed to the SeGW. Is configured with a route to the logical IP address of the base station.
All NEs between the base station and the M2000 DHCP server
M2000 DHCP server
Table 5-12 Configuration requirements for NEs (2) NE Public DHCP server All NEs between the base station and the M2000 DHCP server Requirement Is configured with one to eight M2000 DHCP server IP addresses.
Are configured with the firewall policy or the packet filtering policy so that they allow the transmission of packets with 67 or 68 as the source and destination UDP port number. Are configured with a route to the temporary logical IP address for accessing the trusted domain or network segment of the temporary logical IP address so that related packets can be routed to the SeGW. Are configured with a route to the interface IP address of the base station or the IP address of the network segment.
M2000 DHCP server
Is configured with a route to the interface IP address of the base station.
Draft A (2012-12-30)
5-19
Table 5-13 Configuration requirements for NEs (3) NE SeGW All NEs between the base station and the M2000 DHCP server Requirement Supports sending DHCP broadcast packets in IPSec tunnels, in compliance with RFC 3456.
Are configured with the firewall policy or the packet filtering policy so that they allow the transmission of packets with 67 or 68 as the source and destination UDP port number. Are configured with a route to the IP address of the DHCP relay agent on the SeGW. Are configured with a route to the IP address of the DHCP relay agent on the SeGW.
M2000 DHCP server
Compared with non-IPSec networking scenarios, IPSec networking scenario 1 has the following differences in the procedure for obtaining transmission configuration information from the M2000 DHCP server:

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

The SeGW IP address obtained from the M2000 DHCP server may or may not be the same as the SeGW IP address obtained from the public DHCP server. In either case, the base station needs to negotiate an IKE SA and an IPSec SA with the SeGW before establishing an IPSec tunnel to the SeGW. The SeGW is identified by the SeGW IP address in the configuration information from the M2000 DHCP server. The procedure for establishing a formal IPSec tunnel differs from the procedure for establishing a temporary IPSec tunnel as follows:
To establish an IKE SA and an IPSec tunnel to the SeGW, the base station uses the interface IP address and the SeGW IP address sent by the M2000 DHCP server. During IPSec tunnel negotiation, the base station automatically configures two ACL rules. In both ACL rules, the source IP address is the OM IP address of the base station, but the destination IP address can be any IP address in one rule and must be the IP address of the M2000 or BSC in the other rule. Accordingly, the SeGW can be configured with the two ACL rules. If the SeGW is configured with the two ACL rules, the ID of the ACL rule by which the destination IP address can be any IP address should be as small as possible to avoid rule mismatches.
NOTE
If the SeGW is configured with the ACL rule that the destination IP address is the IP address of the M2000 or BSC, the FTP server from which the base station downloads software and configuration files must be deployed on the M2000 or BSC and use the same IP address as the M2000 or BSC. Otherwise, the base station cannot access the FTP server after the base station and the SeGW filter packets according to ACL rules.
The base station preferentially tries security parameters with which the temporary IPSec tunnel was successfully established to establish the formal IPSec tunnel. If this fails, the base station follows the
Draft A (2012-12-30)
5-20
sequence described in section 5.3.4 "Establishing a Temporary IPSec Tunnel" to try other security parameters.

Table 5-14 lists the configuration requirements for NEs in IPSec networking scenario 1. Table 5-14 Configuration requirements for NEs in IPSec networking scenario 1 NE L2 NEs Requirement
Allow the transmission of DHCP broadcast and unicast packets without filtering or modifying DHCP packets. Are configured with correct VLAN information. Is configured as the DHCP server or enabled with the DHCP relay agent. Is configured with correct DHCP server IP addresses. Is configured with routes to the DHCP server, CA, and SeGW. (NEs in the untrusted domain): Are configured with routes to the temporary and formal interface IP addresses of the base station and routes to the CA and the SeGW. (NEs in the trusted domain): Are configured with a route to the OM IP address of the base station and routes to the M2000 and FTP server.
Next-hop L3 NE of the base station
L3 NEs
M2000
Is configured with a route to the OM IP address of the base station.
M2000 DHCP server
Is configured with a route to the DHCP relay agent.
FTP server
Is configured with a route to the OM IP address of the base station. Stores software and configuration files of the base station in the specified directory. Provides access rights, such as the user name and password, for the base station. Allows DHCP packets to be exchanged between the base station and the M2000. Allows packets to be exchanged between the base station and the M2000 over an OMCH and between the base station and the FTP server. Is enabled with the DHCP relay agent function if the SeGW complies with RFC 3456. Is configured with security parameters listed in Table 5-5. Is configured with ACL rules that allow the transmission of packets sent from the base station during the DHCP procedure and the OMCH establishment procedure. Is configured with related IP address pool and assignment rules if the SeGW needs to assign an IP address for accessing the trusted domain or a DHCP server IP address to the base station. Is configured with operator-issued CA certificates and its own certificates.
SeGW
Draft A (2012-12-30)
5-21
NE CA
Requirement Is configured with the following:

An IP address that can be accessed by NEs in the untrusted domain Huawei-issued CA root certificates

Figure 5-6 shows IPSec networking scenario 2, in which IPSec secures all packets except DHCP packets. Figure 5-6 IPSec networking scenario 2
An M2000 DHCP server in the trusted domain is deployed. IPSec does not secure DHCP packets. Using a DHCP procedure in the untrusted domain, the base station obtains its temporary IP address and the OM IP address, the SeGW IP address, and the CA IP address. From the M2000 DHCP server, the base station obtains the formal transmission configuration 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 SeGW before being transmitted to the M2000 or BSC in the trusted domain.
A CA is deployed and provides digital certificates for the base station to perform mutual authentication with other NEs. During base station deployment, the CA can be accessed by NEs or using an IP address in the untrusted domain. After the base station starts, it must apply to the CA for operator-issued digital certificates before connecting to the SeGW.
Draft A (2012-12-30)
5-22

In IPSec networking scenario 2, the base station must establish an IPSec tunnel to the SeGW before it can access the M2000 or BSC in the trusted domain. To establish the IPSec tunnel, the base station must obtain digital certificates issued by the operator's CA. To obtain digital certificates, the base station must obtain required configuration information from the M2000 DHCP server. Figure 5-7 shows the automatic OMCH establishment procedure in IPSec networking scenario 2. Figure 5-7 Automatic OMCH establishment procedure in IPSec networking scenario 2
1. The base station obtains VLAN information. For details, see section 4.4 "Schemes for Obtaining VLAN Information for DHCP Packets." 2. The base station obtains required configuration information from the M2000 DHCP server. The information includes the interface IP address and the OM IP address of the base station, the CA IP address, and the SeGW address.
NOTE
DHCP packets from the base station are forwarded by the DHCP relay agent to the DHCP server on the M2000.
3. By using the configuration information obtained from the M2000 DHCP server, the base station applies to the CA for operator-issued digital certificates. 4. By using the configuration information obtained from the M2000 DHCP server, the base station establishes a formal IPSec tunnel to the SeGW. 5. The base station validates the formal transmission configuration information. With protection from the formal IPSec tunnel, the base station waits for the SSL-based or plaintext-based OMCH establishment request from the M2000 or BSC and finally establishes an OMCH to the M2000 or BSC.

The M2000 DHCP server must be configured with the parameters listed in Table 5-15 as well as the parameters listed in Table 5-3. These parameters are contained in subcodes of Option 43 in DHCP packets.
Draft A (2012-12-30)
5-23
Table 5-15 Parameters specific to the M2000 DHCP server in IPSec networking scenario 2 Classific ation SeGW informati on Parameter Name Serving SecGW IP Mapping Subcode 20 Length (Bytes) 4 Parameter Description IP address of the SeGW in IPSec networking scenarios Local name of the serving SeGW. It is provided by the base station to authenticate the serving SeGW in IPSec networking scenarios URL from which the base station obtains operator-issued digital certificates. This URL must be accessible to NEs in the untrusted domain. CA Name 38 1 to 127 Name of the CA Mandatory

Mandatory or Optional Mandatory

DHCPOFFER DHCPACK
Serving SecGW Local Name
32
1 to 32
CA informati on
CA URL
44
1 to 128
DHCPOFFER DHCPACK

Allow the transmission of DHCP broadcast and unicast packets without filtering or modifying DHCP packets. Are configured with correct VLAN information. Is enabled with the DHCP relay agent function. Is configured with correct DHCP server IP addresses. Is configured with routes to the DHCP server, CA, and SeGW.
Next-hop gateway of the base station
Draft A (2012-12-30)
5-24
NE L3 NEs
Requirement
(NEs in the untrusted domain): Are configured with routes to the interface IP addresses of the base station and routes to the CA and the SeGW. (NEs in the trusted domain): Are configured with a route to the OM IP address of the base station and routes to the M2000 and FTP server.
M2000 M2000 DHCP server SeGW
Is configured with a route to the OM IP address of the base station Is configured with a route to the DHCP relay agent.
Allows packets to be exchanged between the base station and the M2000 over an OMCH and between the base station and the FTP server. Is configured with security parameters listed in Table 5-6, Table 5-7, and Figure 5-5. Is configured with ACL rules in which the source destination IP address can be any address and the destination IP address can be any IP address or the OM IP address of the base station . Is configured with operator-issued CA certificates and its own certificates.
CA
Is configured with the following:


Figure 5-8 shows IPSec networking scenario 3, in which IPSec secures service and signaling data, but not DHCP packets or OMCH data.
Draft A (2012-12-30)
5-25
Figure 5-8 IPSec networking scenario 3

An M2000 DHCP server is deployed. The base station obtains the OMCH configuration data and CA configuration data from the M2000 DHCP server. IPSec does not secure DHCP packets. IPSec does not secure OMCH data. The base station uses the OM IP address to access NEs in the untrusted domain. IPSec tunnels established between the base station and the SeGW are used to secure signaling and service data. Either party involved in IPSec negotiation uses digital certificates or PSK to authenticate the other party. The CA is optional. If the PSK is used for authentication, a CA is not required. If digital certificates are used for authentication, a CA is required. After the base station starts, it must apply to the CA for operator-issued digital certificates before connecting to the SeGW. During base station deployment, the CA can be accessed by NEs or using an IP address (for example, the interface IP address of the base station) in the untrusted domain.

Figure 5-9 shows the automatic OMCH establishment procedure in IPSec networking scenario 3.
Draft A (2012-12-30)
5-26
Figure 5-9 Automatic OMCH establishment procedure in IPSec networking scenario 3
1. The base station obtains VLAN information. For details, see section 4.4 "Schemes for Obtaining VLAN Information for DHCP Packets." 2. The base station obtains the OMCH configuration data and CA configuration data (optional) from the M2000 DHCP server. If the base station uses the PSK for authentication, the base station does not need to obtain the CA configuration data. If the base station uses digital certificates for authentication, the base station must obtain the CA configuration data. 3. The base station applies to the CA for operator-issued digital certificates if digital certificates are used for authentication. After the base station restarts, it establishes an IPSec tunnel to the SeGW to secure services and signaling. 4. Based on the configuration information obtained from the M2000 DHCP server, the base station establishes an OMCH to the M2000 or BSC

If the base station uses digital certificates for authentication, the M2000 DHCP server must be configured with the parameters listed in both Table 5-17 and Table 5-3. These parameters are contained in subcodes of Option 43 in DHCP packets. Table 5-17 Parameters specific to the M2000 DHCP server in IPSec networking scenario 3 Classificati on CA information Paramete r Name CA URL Subcod e 44 Length (Bytes) Parameter Description URL from which the base station obtains operator-issued digital certificates. This URL must be accessible to NEs in the untrusted domain. Name of the CA Mandato ry or Optional Mandator y DHCP Packet Involved
1 to 128
DHCPOFF ER DHCPACK
CA Name
38
1 to 127
Draft A (2012-12-30)
5-27

Allow the transmission of DHCP broadcast and unicast packets without filtering or modifying DHCP packets. Are configured with correct VLAN information. Is enabled with the DHCP relay agent function and configured with the IP address of the DHCP server, that is, the IP address of the M2000. If an NAT server is deployed, the IP address of the M2000 must be that converted by the NAT server. Is configured with a route to the DHCP server. Is configured with a route to the OM IP address of the base station if the OM IP address is not the same as the interface IP address of the base station. Is configured with a route to the CA. (NEs in the untrusted domain): Are configured with a route to the IP address of the base station, a route to the OM IP address of the base station, a route to the M2000, a route to the FTP server, and a route to the CA. (NEs in the trusted domain): Are configured with a route to the OM IP address of the base station and routes to the M2000 and FTP server.
Next-hop gateway of the base station
L3 NEs
M2000 M2000 DHCP server CA
Is configured with a route to the OM IP address of the base station. Is configured with a route to the DHCP relay agent.
Is configured with the following:

Draft A (2012-12-30)
5-28
6 Automatic OMCH Establishment by the Separate-MPT Multimode Base Station

6.1 Networking
The separate-MPT multimode base station is similar to many single-mode base stations that are interconnected using the transmission board. The interconnection can either be based on the panel or the backplane. Generally, the transmission board of a certain mode provides a shared transmission interface for connecting to the transport network. The base station in this mode is called an upper-level base station, and base stations in the other modes are called lower-level base stations. The upper-level base station acts as the DHCP relay agent of lower-level base stations. Figure 6-1 shows the OMCH networking for the separate-MPT multimode base station that uses panel-based interconnection. The upper-level base station provides two transmission interfaces, one for panel-based interconnection and the other for connecting to the transport network. Figure 6-1 OMCH networking for the separate-MPT multimode base station that uses panel-based interconnection
Figure 6-2 shows the OMCH networking for the separate-MPT multimode base station that uses backplane-based interconnection.
Draft A (2012-12-30)
6-1
Figure 6-2 OMCH networking for the separate-MPT multimode base station that uses backplane-based interconnection
The automatic OMCH establishment procedure for the separate-MPT base station is similar to the respective automatic OMCH establishment procedure for each single-mode base station. Lower-level base stations can start the automatic OMCH establishment procedure only after the upper-level base station completes the procedure. This section describes the differences in the procedures between the separate-MPT base station and the single-mode base station.
6.2 Automatic OMCH Establishment Procedure

Figure 6-3 shows the automatic OMCH establishment procedure for the separate-MPT multimode base station. Figure 6-3 Automatic OMCH establishment procedure
Lower-level base station Upper-level base station DHCP server of upper-level base station OMC of upperlevel base station DHCP server of lower-level base station OMC of lowerlevel base station
1. OMCH auto-establishment, configuration file download and activation, and transition to working state
2. DHCP procedure
2. DHCP procedure 3. OMCH establishment
1. Same as the single-mode base station, the upper-level base station follows the OMCH establishment procedure described in chapter 5 "Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station." The upper-level base station then obtains software and configuration files from the M2000 or BSC over the established OMCH. The upper-level base station activates software and configuration files and then enters the working state.
Draft A (2012-12-30)
6-2
2. Each lower-level base station exchanges DHCP packets with the DHCP relay agent (upper-level base station) and the DHCP server to obtain the transmission configuration information. 3. Each lower-level base station establishes an OMCH to the M2000 or BSC. The DHCP servers of the upper-level base station and lower-level base stations can be deployed on the same NE or different NEs.
6.3 Configuration Requirements for the DHCP Server

Each mode in a separate-MPT multimode base station has almost the same configuration requirements for the DHCP server as a single-mode base station. The only difference lies in the setting of the OM Bearing Board parameter on DHCP servers of lower-level base stations, as described in Table 6-1. For details about the configuration requirements for the DHCP server of each single-mode base station, see chapter 5 "Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station." Table 6-1 Setting of the OM Bearing Board parameter on DHCP servers of lower-level base stations Parameter Name OM Bearing Board Subcode 250 Parameter Description Value:
Length (Bytes) 1
Mandatory or Optional Mandatory

DHCPOFFER DHCPACK
0: An OMCH is established on the panel. 1: An OMCH is established on the backplane.
Set this parameter to 0 when the separate-MPT multimode base station uses panel-based interconnection. Set this parameter to 1 when the separate-MPT multimode base station uses backplane-based interconnection.
6.4 Configuration Requirements for NEs

Each mode in a separate-MPT multimode base station has similar configuration requirements for NEs to a single-mode base station. For details about these requirements, see chapter 5 "Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station." This section describes only the differences in the configuration requirements. The upper-level base station acts as the DHCP relay agent to forward DHCP packets and as a router to forward OMCH and service packets for lower-level base stations. The transport network for the upper-level base station needs to forward DHCP packets from the DHCP servers of lower-level base stations. Therefore, the upper-level base station and its transport network must be configured with data listed in Table 6-2.
Draft A (2012-12-30)
6-3
Table 6-2 Configuration requirements NE Upper-level base station Requirement

Is enabled with the DHCP relay agent function. Is configured with IP addresses of the DHCP servers of lower-level base stations. Is configured with routes to the DHCP servers of lower-level base stations. Is configured with routes used for serving lower-level base stations, including downlink routes to the IP addresses of lower-level base stations and uplink routes to the peer IP addresses of lower-level base stations.
If
the lower-level base station is the GBTS or NodeB, uplink routes to the base station controller must be configured. the lower-level base station is the eNodeB, uplink routes to the M2000, mobility management entity (MME), and serving gateway (S-GW) must be configured.
If
Is configured with the IP address of the transmission interface (used for panel-based interconnection) provided by the upper-level base station. It is recommended that only one such IP address be configured. If many such IP addresses are configured, the source IP address in DHCP packets forwarded by the upper-level base station is the first configured IP address. As a result, the packet forwarding may fail due to differences in the configuration sequence. If the DHCP packets and OM data of lower-level base stations are secured by the IPSec tunnel of the upper-level base station, the upper-level base station needs to configure security parameters for the passerby flows of lower-level base stations. The security parameters include the packet filtering rules, ACL rules, IPSec proposal, and IKE proposal. Are configured with routes to the DHCP servers of lower-level base stations. Are configured with routes to the IP address of the DHCP relay agent. Are configured with routes to the OM IP address of the upper-level base station or either of the following routes:
The
All NEs on the transport network for the upper-level base station
routes to the IP address of the transmission interface (used for panel-based interconnection) provided by the upper-level base station when the separate-MPT multimode base station uses panel-based interconnection routes to the network segment of the next-hop gateway of the upper-level base station when the separate-MPT multimode base station uses backplane-based interconnection
The
DHCP servers of lower-level base stations Lower-level base stations
Are configured with routes to the upper-level base station
Are configured with routes to the OM IP address of the upper-level base station. If the separate-MPT multimode base station uses panel-based interconnection, lower-level base stations can also be configured with routes to the IP address of either of the transmission interfaces (used for
Draft A (2012-12-30)
6-4
NE
Requirement panel-based connection or used for connecting to the transport network) provided by the upper-level base station.
Draft A (2012-12-30)
6-5
7 Application Restrictions
7.1 Configuration Requirements for Base Stations and Other NEs
When a base station is to be deployed by PnP, configuration requirements for the base station and related DHCP servers must be met to ensure successful automatic OMCH establishment. If configuration requirements are not met, automatic OMCH establishment may fail, leading to a deployment failure. Table 7-1 through Table 7-3 summarizes the configuration requirements. Table 7-1 lists the configuration requirements for the configuration files of the base station in all scenarios. Table 7-1 Configuration requirements for configuration files of the base station in all scenarios SN 1 MO OMCH Requirement If the base station is configured with active and standby OMCHs, only the active OMCH is used for base station deployment by PnP. The active OMCH is the OMCH for which the Flag parameter is set to MASTER(Master). The active OMCH must meet the following requirements:
If the active OMCH is bound to a route:

The The
PeerIP parameter must be set to the IP address of the M2000.
IP addresses of the M2000 and the FTP server must be on the network segment that is collectively specified by the PeerIP and PEERMASK parameters. FTP server and the M2000 must be deployed on the same equipment or network segment. PeerIP parameter must be set to the IP address of the M2000. IP addresses of the M2000 and the FTP server must be on the network segment that is collectively specified by the PeerIP and PEERMASK parameters. base station must be configured with a route to the network segment of its peer IP address.
If the active OMCH is not bound to any route:

The The The
The
If the requirements are not met, the PeerIP parameter must be set to the next-hop IP address of the active OMCH, and the PEERMASK parameter must be set to the interface IP address mask of the base station. 2 VLANMAP The VLANMODE parameter specifies the VLAN mode. It is recommended that upper-level and lower-level base stations use the SingleVLAN mode instead of the VLANGroup mode to configure VLANs. If base stations are cascaded and the upper-level base station uses the VLANGroup mode, the upper-level base station must attach related VLAN IDs to packets with differentiated services code point (DSCP) set to 46 (when the lower-level base station is the NodeB or eNodeB) or 48 (when the lower-level base station is GBTS or eGBTS).
Draft A (2012-12-30)
7-1
SN 3
MO BFDSESSION
Requirement If the CATLOG parameter is set to RELIABILITY(Reliability) for a BFD session, the BFD session is bound to a handover route. If the base station uses a logical IP address as the OM IP address, the base station cannot be deployed by PnP in non-IPSec networking scenarios. If the combination of the DID and NE type is used as the BS ID, the DID parameter in the NE MO must be specified.
NE
Table 7-2 lists the specific configuration requirements for the configuration files of the base station in IPSec networking scenarios. Table 7-2 Configuration requirements for the configuration files of the base station in IPSec networking scenarios SN 1 NE Base station MO ACLRULE Requirement The configured ACL rule meets either of the following requirements:
The SIP and DIP parameters are set to 0.0.0.0, and the SWC and DWC parameters are set to 255.255.255.255. That is, both the source and destination IP addresses can be any address. The SIP is set to the OM IP address, and the DIP parameter is set to the IP address of the M2000, the IP address of the M2000 network segment, or 0.0.0.0. Note that IPSec tunnels do not secure OMCHs established during base station deployment if the ACTION parameter is set to DENY(Deny). IPSec tunnels secure the OMCHs only when the ACTION parameter is set to PERMIT(Permit).
If neither requirement is met, errors may occur when parameters configured on the SeGW are exported from the CME, leading to failures in base station deployment by PnP. 2 Base station IKEPROPOSAL IPSECPROPOSAL Parameter settings of the IKEPROPOSAL MO must be consistent with those described in Table 5-6 or Table 5-7. Parameter settings of the IPSECPROPOSAL MO must be consistent with those described in Figure 5-5. If the base station uses the IPSec tunnel pair topology, only the active tunnel supports base station deployment by PnP.
Draft A (2012-12-30)
7-2
SN 3
NE Base station
MO BFDSESSION
Requirement If the base station uses the IPSec tunnel pair topology, the BFD session cannot be bound to a route during the BFD session configuration. Ethernet link aggregation group must not be manually configured on the peer L2 NEs of the base station. The CA must be configured with the INITREQSIP parameter and the UPDSIP parameter when identify authentication by digital certificates is required. The CA must be accessible to NEs in the untrusted domain.
L2 NEs
ETHTRK
CA
CA
Table 7-3 lists the configuration requirements for a DHCP server. Table 7-3 Configuration requirements for a DHCP server SN 1 2 Requirement The public DHCP server can be configured with a maximum of eight M2000 DHCP server IP addresses. If the WMPT board of the NodeB needs to be replaced with the UMPT board, the BS ID configured on the DHCP server must be changed from being bound to the panel's ESN (mapping subcode 43 in DHCP Option 43) to being bound to the backplane's ESN (mapping subcode 1 in DHCP Option 43).
NOTE
When you configure or modify the information of the M2000 DHCP server on the M2000, the destination IP address of the OMCH route and the IP address of the destination network segment must be correct.
7.2 Impact of M2000 Deployment on Base Station Deployment by PnP

During base station deployment by PnP and subsequent commissioning, the base station needs to communicate with many application services of the M2000, including the DHCP service, FTP service, and OMCH management service. The preceding three services can be deployed on different M2000s and use different IP addresses. Therefore, network planning and base station data configuration must ensure normal communication between the OM IP address of the base station and the IP addresses of the three services. Table 7-4 describes the impact of M2000 deployment on automatic OMCH establishment.
Draft A (2012-12-30)
7-3
Table 7-4 Impact of M2000 deployment on automatic OMCH establishment M2000 Deployment M2000 Deployment Description All application services are deployed on the same server and the server has only one IP address. M2000 Serving as the DHCP Server Single server M2000 Serving as the OMC Single server Requirement for the Base Station Deployment For details, see chapter 5 "Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station" and chapter 6 "Automatic OMCH Establishment by the Separate-MPT Multimode Base Station." Impact on the Network Configuration For details, see chapter 5 "Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station" and chapter 6 "Automatic OMCH Establishment by the Separate-MPT Multimode Base Station." For details, see chapter 5 "Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station" and chapter 6 "Automatic OMCH Establishment by the Separate-MPT Multimode Base Station." In IPSec networking scenarios, the IP address of the M2000 DHCP server configured on the public DHCP server
Single-server system
HA system
The active and standby nodes have the same function and data on the two nodes are synchronize d. The active and standby nodes use the same IP address.
Active or standby node
For details, see chapter 5 "Automatic OMCH Establishment by the Single-mode Base Station and Co-MPT Multimode Base Station" and chapter 6 "Automatic OMCH Establishment by the Separate-MPT Multimode Base Station."
SLS system
The slave node performs the network manageme nt function only. The IP address of
Master node
Master or slave node
The PeerIP parameter for the OMCH must be set to the IP address of the M2000 that manages the base station. If the OMCH is
Draft A (2012-12-30)
7-4
M2000 Deployment
M2000 Deployment Description the master node is different from that of the slave node, and the IP addresses of the two nodes are in the same subnet.
M2000 Serving as the DHCP Server
M2000 Serving as the OMC
Requirement for the Base Station Deployment bound to a route, the route must be to the network segment of the M2000.
Impact on the Network Configuration must be the IP address of the master node. The SeGW must be configured with ACL rules which allow packets of the M2000 DHCP server to pass. The SeGW must be configured with ACL rules which allow OM data to pass.
Remote HA system
The active and standby nodes are deployed on two locations. The IP address of the active node is different from that of the standby node, and the IP addresses of the two nodes may not be in the same subnet.
The M2000 must serve as the DHCP server.
The base station must be configured with routes to the two IP address or two network segments. The PeerIP parameter for the OMCH of the base station must be set to the IP address of the M2000 that serves as the DHCP server.
In IPSec networking scenarios, the IP address of the M2000 DHCP server configured on the public DHCP server must be the IP address of the M2000 that serves as the DHCP server. If the operator expects to use either of the active and standby nodes as the DHCP server, the public DHCP server must be configured with the IP addresses of the active and standby nodes.
Draft A (2012-12-30)
7-5
M2000 Deployment
M2000 Deployment Description
M2000 Serving as the DHCP Server
M2000 Serving as the OMC
Requirement for the Base Station Deployment
Impact on the Network Configuration
The SeGW must be configured with ACL rules which allow DHCP packets to pass. If the operator expects to use either of the active and standby nodes as the DHCP server, the SeGW must be configured with ACL rules which allow packets of active and standby nodes to pass. The SeGW must be configured with ACL rules which allow OM data to pass. If the operator expects to use either of the active and standby nodes as the OMC, the SeGW must be configured with ACL rules which allow packets of active and standby nodes to pass.
Draft A (2012-12-30)
7-6
M2000 Deployment
M2000 Deployment Description The emergency system performs basic functions only and does not support PnP or DHCP.
M2000 Serving as the DHCP Server Not supported
M2000 Serving as the OMC Not supported
Requirement for the Base Station Deployment Not involved
Impact on the Network Configuration Not involved
Emergency system
For example:
When the M2000 uses the multi-server load-sharing (SLS) networking, the DHCP service is deployed on the master server, whereas the FTP service and the OMCH management service can be deployed on either the master or slave server. When the FTP service and OMCH management service are deployed on different M2000 servers and accordingly use different IP addresses, the route configuration on the base station and the transport network must ensure that the IP addresses of the two services are reachable using configured routes. If IPSec secures OMCH data, the IPSec SA's traffic selector (TS) successfully negotiated between the base station and the SeGW must cover the traffic between the OM IP address of the base station and the IP addresses of the FTP service and the OMCH management service.
OMCH networking requires that the NAT server be deployed only on the M2000 side, but not the base station or BSC side. Figure 7-1 shows the OMCH networking in which the NAT server is deployed on the M2000 side. Figure 7-1 OMCH networking when the NAT server is deployed on the M2000
The IP address and port number of the M2000 can be converted by the NAT. Therefore, the route to the M2000 on the base station side must use an M2000 IP address visible on the base station side as the destination address. As shown in Figure 7-1, the local IP address configured for the M2000 is 10.0.0.1. After the conversion performed by the NAT server, however, the source IP address in TCP packets received by the base station is 20.1.1.1 instead of 10.0.0.1. Therefore, the route to 20.1.1.1 instead of 10.0.0.1 must be configured on the base station side
Draft A (2012-12-30)
7-7
8 Glossary
8 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.
Draft A (2012-12-30)
8-1
9 Reference Documents
9 Reference Documents
[1] IPSec Feature Parameter Description for SingleRAN [2] PKI Feature Parameter Description for SingleRAN [3] SSL Feature Parameter Description for SingleRAN [4] 3900 Series Base Station Commissioning Guide [5] 3900 Series Base Station Initial Configuration Guide
Draft A (2012-12-30)
9-1

Automatic OMCH Establishment Feature Parameter PDF

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Automatic OMCH Establishment Feature Parameter PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

SingleRAN

Automatic OMCH Establishment

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

3 OMCH Protocol Stacks ............................................................................................................3-1

4 Obtaining Transmission Configuration Information .......................................................4-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

6 Automatic OMCH Establishment by the Separate-MPT Multimode Base Station ...6-1

7 Application Restrictions .........................................................................................................7-1

8 Glossary ......................................................................................................................................8-1 9 Reference Documents .............................................................................................................9-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

1 About This Document

1 About This Document

1.2 Intended Audience

1.3 Change History

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

2.3 Application Networking Scenarios

Scenario 1 Scenario 2 Scenario 3:

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

3 OMCH Protocol Stacks

3 OMCH Protocol Stacks

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

3 OMCH Protocol Stacks

3.2 IPSec Networking Scenario

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

3 OMCH Protocol Stacks

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

3 OMCH Protocol Stacks

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

4 Obtaining Transmission Configuration Information

4 Obtaining Transmission Configuration Information

4.1.2 DHCP Interworking

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

4 Obtaining Transmission Configuration Information

Figure 4-1 DHCP interworking

4.1.3 DHCP Packet Format

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

4 Obtaining Transmission Configuration Information

Figure 4-2 DHCP packet format

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

4 Obtaining Transmission Configuration Information

4.2 Mapping Between DHCP Clients and Servers

Same as that of each single-mode base station

4.3 DHCP Procedure

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

SingleRAN Automatic OMCH Establishment

4 Obtaining Transmission Configuration Information