IP Transport Architecture

IP Transport Architecture
SRAN5.0
Feature Parameter Description
Issue 02
Date 2011-09-30
HUAWEI TECHNOLOGIES CO., LTD.

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

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
SingleRAN
IP Transport Architecture Contents
Contents
1 Introduction ................................................................................................................................1-1
1.1 Scope ............................................................................................................................................ 1-1
1.2 Additional Information .................................................................................................................... 1-1
1.3 Intended Audience ........................................................................................................................ 1-1
1.4 Change History.............................................................................................................................. 1-1
2 Overview of IP Transport Architecture ................................................................................2-1

2.1 Introduction.................................................................................................................................... 2-1
2.2 IP Transport Architecture ............................................................................................................... 2-1
3 IP Transport Protocols ............................................................................................................3-1

3.1 Introduction.................................................................................................................................... 3-1
3.2 Data Link Layer Protocols ............................................................................................................. 3-2
3.2.1 Ethernet ................................................................................................................................ 3-2
3.2.2 Virtual Local Area Network ................................................................................................... 3-4
3.2.3 Point-to-Point Protocol.......................................................................................................... 3-5
3.2.4 Multilink-PPP ........................................................................................................................ 3-7
3.3 Internet Protocol ............................................................................................................................ 3-9
3.3.1 Datagram Format ................................................................................................................. 3-9
3.3.2 IP Address and Routing ...................................................................................................... 3-11
3.3.3 Layer 2 Networking and Layer 3 Networking ..................................................................... 3-13
3.4 User Datagram Protocol .............................................................................................................. 3-14
3.5 Real-Time Transport Protocol ..................................................................................................... 3-15
3.6 Stream Control Transmission Protocol ........................................................................................ 3-16
3.7 MTP3-User Adaptation Layer ...................................................................................................... 3-18
3.8 Signaling Connection Control Part .............................................................................................. 3-19
4 IP Transmission Efficiency Improvement ..........................................................................4-1

4.1 Introduction.................................................................................................................................... 4-1
4.2 Frame Protocol Multiplexing.......................................................................................................... 4-1
4.2.1 Datagram Format ................................................................................................................. 4-1
4.2.2 FP-Mux Principles ................................................................................................................ 4-2
4.3 Abis-Mux and Ater-Mux ................................................................................................................. 4-3
4.4 UDP Multiplexing ........................................................................................................................... 4-4
4.4.1 Packet Format ...................................................................................................................... 4-4
4.4.2 UDP-Mux Principles ............................................................................................................. 4-6
4.5 Header Compression .................................................................................................................... 4-7
4.5.1 Address and Control Field Compression .............................................................................. 4-7
4.5.2 Protocol Field Compression ................................................................................................. 4-7
4.5.3 IP Header Compression ....................................................................................................... 4-8
5 IP Clock Synchronization .......................................................................................................5-1
Issue 02 (2011-09-30) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd
SingleRAN
IP Transport Architecture Contents
5.1 Introduction.................................................................................................................................... 5-1

5.2 Clock over IP Solution ................................................................................................................... 5-1
5.3 IEEE1588 V2 Solution ................................................................................................................... 5-2
5.4 Synchronous Ethernet Solution..................................................................................................... 5-3
6 Fault Detection Mechanisms .................................................................................................6-1

6.1 Overview ....................................................................................................................................... 6-1
6.2 ETH Operation, Administration, and Maintenance ........................................................................ 6-1
6.2.2 Solution Based on IEEE 802.3ah ......................................................................................... 6-2
6.2.3 Solution Based on IEEE 802.1ag ......................................................................................... 6-3
6.3 Bidirectional Forwarding Detection ............................................................................................... 6-4
6.3.2 Single-Hop Bidirectional Forwarding Detection .................................................................... 6-7
6.3.3 Multi-Hop Bidirectional Forwarding Detection ...................................................................... 6-7
6.4 Address Resolution Protocol Detection ......................................................................................... 6-8
6.4.1 Binding Between SBFD/ARP and IPRT ............................................................................... 6-9
6.4.2 Application of SBFD/ARP in VRRP Topology ....................................................................... 6-9
6.5 IP Performance Monitoring ......................................................................................................... 6-10
7 Network Reliability ...................................................................................................................7-1

7.1 Overview ....................................................................................................................................... 7-1
7.2 Board Backup ................................................................................................................................ 7-1
7.3 Ethernet Port Backup .................................................................................................................... 7-2
7.4 Ethernet Port Load Sharing........................................................................................................... 7-3
7.5 Route-Based Port Backup and Load Sharing ............................................................................... 7-4
7.6 Ethernet Link Aggregation ............................................................................................................. 7-4
7.6.1 Prerequesites for Link Aggregation ...................................................................................... 7-4
7.6.2 Basic Principles of Link Aggregation .................................................................................... 7-5
7.6.3 Application of Link Aggregation ............................................................................................ 7-6
8 IP DHCP .......................................................................................................................................8-1
8.1 Dynamic Host Configuration Protocol ........................................................................................... 8-1
8.2 VLAN Detection ............................................................................................................................. 8-1
9 Parameters .................................................................................................................................9-1
10 Counters .................................................................................................................................10-1
11 Glossary ..................................................................................................................................11-1
12 Appendix .................................................................................................................................12-1
13 Reference Documents .........................................................................................................13-1
Issue 02 (2011-09-30) Huawei Proprietary and Confidential ii

SingleRAN
IP Transport Architecture 1 Introduction
1 Introduction
1.1 Scope
This document describes the IP transport architecture of the BSC6900. The architecture enables IP
transport on the interfaces of the GSM and UMTS networks. This document also describes the related
transport protocols, transmission efficiency improvement mechanisms, fault detection mechanisams,
and network reliability.
1.2 Additional Information

Read the following documents for more information about the IP transport architecture:
 IP RAN Feature Parameter Description: provides the overview, network topologies, interface protocols,
and parameters of the IP RAN feature for the UMTS network.
 IP BSS Feature Parameter Description: provides the overview, network topologies, interface protocols,
and parameters of the IP BSS feature for the GSM network.
 Common Transmission Feature Parameter Description: provides the overview, network topologies,
interface protocols, and parameters of the Iub and Abis Co-IP Transmission feature.
1.3 Intended Audience

This document is intended for:
 Personnel who are familiar with WCDMA and GSM basics
 Personnel who need to understand BSC6900 IP transport architecture
 Personnel who work with Huawei products
 Personnel who dimension and plan the GSM or UMTS transport network
 Personnel who configure and manage the GSM or UMTS transport network
1.4 Change History

This section provides information on the changes in different document versions.
There are two types of changes, which are defined as follows:
 Feature change: refers to the change in the IP transport architecture feature.
 Editorial change: refers to the change in wording or the addition of the information that was not
described in the earlier version.
Document Issues
The document issues are as follows:
 02 (2011-09-30)
 01 (2010-03-30)
 Draft (2009-12-05)
02 (2011-09-30)
This is the document for the second commercial release of SRAN5.0.
Compared with issue 01 (2010-03-30) of GBSS12.0, this issue optimizes the description.
Issue 02 (2011-09-30) Huawei Proprietary and Confidential 1-1

SingleRAN
IP Transport Architecture 1 Introduction
01 (2010-03-30)
This is the document for the first commercial release of GBSS12.0.
Compared with issue Draft (2009-12-05) of GBSS12.0, this issue optimizes the description.
Draft (2009-12-05)
This is the draft of the document for GBSS12.0.
This is a new document.

SingleRAN
IP Transport Architecture 2 Overview of IP Transport Architecture
2 Overview of IP Transport Architecture

2.1 Introduction
With the development and wide use of IP technology, the application of IP technology to wireless
communications networks has become a necessary trend. In 3GPP R5, IP transport is introduced to the
radio access network (RAN) of UMTS, and the corresponding feature is called IP RAN. From 3GPP R4
onwards, IP transport is gradually introduced to the base station system (BSS) of GSM, and the
corresponding feature is called IP BSS.
If the IP technology is applied in the RAN, the data bearer capability of the transport network is
drastically improved, thus reducing capital expenditure (CAPEX) and operating expense (OPEX). In
addition, the IP transport network can carry the data of multiple radio access technology (RAT) networks,
which meets the long-term evolution requirements of operators.
2.2 IP Transport Architecture

The BSC6900 is a multi-mode base station controller for the GSM and UMTS networks and it supports
the IP transport architecture, as shown in Figure 2-1. The architecture provides IP transport bearer
services for the GSM BSS and UMTS RAN. Transport Resource Management (TRM) provides
transmission resource management functions to ensure the transmission quality and improve the
transmission resource utilization. For details about TRM, see the Transmission Resource Management
Feature Parameter Description.
Figure 2-1 IP transport architecture
IP transport architecture consists of the following functional modules:

 IP transport protocols
To support IP RAN and IP BSS, a set of transport protocols is introduced to the BSC6900. These
protocols have a bottom-up design and implement the IP transmission bearers in the RAN, as defined
in 3GPP technical specifications. For details, see Section 3 "IP Transport Protocols."
 IP transmission efficiency improvement
The multiplexing and header compression technologies are used to reduce the header overhead of
packets. In this manner, the utilization of IP transmission bandwidth is increased. For details, see
Section 4 "IP Transmission Efficiency Improvement."

SingleRAN
IP Transport Architecture 2 Overview of IP Transport Architecture
 IP clock synchronization
Layer 1 of the IP network does not provide clock synchronization. Instead, other clock synchronization
solutions, such as clock over IP, IEEE1588 V2, or synchronous Ethernet, can be used. For details, see
Section 5 "IP Clock Synchronization."
 IP QoS
The BSC6900 provides the following mechanisms to ensure IP quality of service (QoS): admission
control, overload and congestion control, backpressure-based congestion control, Differentiated
Service Code Point (DSCP), and Virtual Local Area Network (VLAN) priority. For details about these
mechanisms, see the Transmission Resource Management Feature Parameter Description.
 IP fault detection
The ETH Operation, Administration, and Maintenance (ETH OAM), Address Resolution Protocol
(ARP), Bidirectional Forwarding Detection (BFD), and IP performance monitoring (IP PM) mechanisms
can be used to detect the transmission fault and performance deterioration between the transmission
and reception ends and in the intermediate network. For details, see Section 6 "Fault Detection
Mechanisms."
 Network reliability
The reliability of the IP transport network can be improved by adopting mechanisms such as board
backup, Ethernet port backup, Ethernet port load sharing, and Ethernet link aggregation. For details,
see Section 7 "Network Reliability".
 IP DHCP
IP Dynamic Host Configuration Protocol (DHCP) is used for the Iub and Abis interfaces. It enables the
BSC6900 to automatically allocate network addresses and establish OM channels for the NodeB and
for the BTS. For details, see Section 8 "IP DHCP."

SingleRAN
IP Transport Architecture 3 IP Transport Protocols
3 IP Transport Protocols
3.1 Introduction
To support IP RAN and IP BSS, the BSC6900 uses a set of transport protocols, as shown in Figure 3-1.
These protocols have a bottom-up design and implement the IP transmission bearers for the RAN, as
defined in 3GPP technical specifications.
The application layer shown in Figure 3-1 refers to the radio network layer of the interfaces in the GSM and UMTS
networks. It is not described in this document.
Figure 3-1 IP transport protocol architecture
The IP transport architecture consists of three parts:

 Fundamental protocol part
The fundamental protocol part contains the common underlying protocols for the control plane and
user plane. It is the basis for the communications between the BSC6900 and the peer end.
The fundamental protocol part consists of the physical layer protocols, data link layer protocols,
Internet Protocol (IP), and User Datagram Protocol (UDP). The data link layer protocols include
Ethernet protocols and derived VLAN, Point-to-Point Protocol (PPP) and derived PPPMux, and
Multilink-PPP (MLPPP) and derived Multi-Class PPP (MCPPP).
 Control plane part
The control plane part and the fundamental protocol part work together to provide the transport
network layer functions for the control planes of the GSM and UMTS interfaces. That is, the control

SingleRAN
plane part and the fundamental protocol part provide transport bearer services for the radio network
layer of the control planes of the GSM and UMTS interfaces.
The control plane consists of the Stream Control Transmission Protocol (SCTP), MTP3-User
Adaptation Layer (M3UA), Signaling Connection Control Part (SCCP), Link Access Procedure on the
D channel (LAPD), and Mapping and Transfer between LAPD entity and Service entity (MTLS).
 User plane part
The user plane part and the fundamental protocol part work together to provide the transport network
layer functions for the user planes of the GSM and UMTS interfaces. That is, the user plane part and
the fundamental protocol part provide transport bearer services for the radio network layer of the user
planes of the GSM and UMTS interfaces.
The user plane consists of the Real-time Transport Protocol (RTP) and the User plane of GPRS
Tunneling Protocol (GTP-U).
The following sections describe the related transport protocols in the IP transport architecture.
3.2 Data Link Layer Protocols

The data link layer is the second layer of the TCP/IP protocol stack. Based on the physical layer, the data
link layer provides reliable data transmission for the network layer.
The data link layer protocols contained in the IP transport architecture are classified into the following
two types:
 Local area network (LAN) protocols: Ethernet and VLAN
 Wide area network (WAN) protocols: PPP, PPPMux, MLPPP, and MCPPP
3.2.1 Ethernet
Currently, Ethernet is the most widely used data link layer technology of LAN.
The BSC6900 supports Ethernet on the Iub, Iur, and Iu interfaces of the UMTS network and on the Abis,
A, and Gb interfaces of the GSM network.
Frame Format
Ethernet has many frame formats. The Ethernet II frame format is defined in RFC894, as shown in
Figure 3-2. The IEEE 802.3 frame format is defined in RFC1042, as shown in Figure 3-3. The main
difference between the two frame formats is the last field of the frame header: The last field of the
Ethernet II frame header is Type whereas the last field of the IEEE 802.3 frame header is Length.
The BSC6900 supports the transmission of frames in Ethernet II format and the reception of frames in
IEEE 802.3 or Ethernet II formats.
Figure 3-2 Ethernet II frame format
Frame header
Destination Source MAC

Type Payload FCS
MAC address address
6 bytes 6 bytes 2 bytes 46-1500 bytes 4 bytes

SingleRAN
Figure 3-3 IEEE 802.3 frame format

Frame header
Destination Source MAC

Length Payload FCS
MAC address address
6 bytes 6 bytes 2 bytes 46-1500 bytes 4 bytes
The fields shown in Figure 3-2 and Figure 3-3 are described as follows:
 Destination MAC address: specifies the Media Access Control (MAC) address of the physical device
that receives the frame.
 Source MAC address: specifies the MAC address of the physical device that transmits the frame.
 (Ethernet II) Type: indicates the type of payload carried by an Ethernet II frame. For example, 0x0800
signifies an IP payload.
 (IEEE 802.3) Length: indicates the size of the payload in the Ethernet frame.
 Payload: contains the upper-layer protocol data encapsulated by the Ethernet frame. The upper-layer
protocol data is usually an IP packet. The size of the Payload field is limited. The minimum size of the
Payload field is 46 bytes and the maximum size (that is, the size of the maximum transmission unit,
MTU) is 1,500 bytes. When the size of the actual data is smaller than 46 bytes, padding is added to the
Payload field. If the size of the upper-layer protocol packet exceeds the size of the MTU, the packet is
segmented.
 FCS: frame check sequence field. The cyclic redundancy check (CRC) is used. If the reception end
detects an error during the frame check, the frame is discarded.
The related parameters of the BSC6900 are as follows:
 Board type (BRDTYPE) and Port type (PTYPE): specify the type of interface board and the type of
port respectively.
 Auto negotiation (AUTO): specifies whether an Ethernet port supports auto-negotiation.
 MTU[Byte] (MTU): The default value of the MTU is 1,500 bytes.
MAC Address
In the OSI reference model, the data link layer consists of the LLC sublayer and the MAC sublayer. The
MAC address is also called physical address, hardware address, or link address. It is used at the MAC
sublayer to uniquely identify a physical device. The MAC address is burned into the hardware at the time
of manufacture. During a communication, the physical layer identifies a host by its MAC address.
The 48-bit MAC address is usually represented by 12 hexadecimal digits separated by dots. The MAC
address consists of two parts:
 Manufacturer identifier: first 24 bits, assigned by the Ethernet address management organization
 Serial number: last 24 bits, assigned by the manufacturer
Figure 3-4 shows an example of the MAC address.

SingleRAN
Figure 3-4 Example of the MAC address
3.2.2 Virtual Local Area Network

VLAN is a data exchange technology derived from the traditional LAN.
VLAN allows LAN devices to be logically grouped into multiple network segments (that is, smaller LANs)
to implement virtual workgroups. The hosts within the same VLAN can communicate with each other
through VLAN switches. The hosts in different VLANs are separated from each other and they
communicate with each other only through routers. A VLAN is a broadcast domain, that is, a host in a
VLAN can receive the broadcast packets from the other hosts in the same VLAN but cannot receive any
broadcast packets from other VLANs.
VLAN provides the following advantages:
 Suppresses broadcast storm
 Improves transmission security
 Provides differentiated services
Frame Format
The VLAN frame format is defined in IEEE 802.1Q. In comparison to a standard Ethernet frame, a
four-byte VLAN tag is added to the VLAN frame header, as shown in Figure 3-5.
Figure 3-5 VLAN frame format
The fields of the VLAN tag are described as follows:

 TPID: tag protocol identifier. If a VLAN frame complies with IEEE 802.1Q, TPID is permanently set to
0x8100.

SingleRAN
 VLAN priority: specifies the priority of a VLAN frame. The priority ranges from 0 to 7. Ethernet provides
differentiated services based on the VLAN priority.
 CFI (Canonical Format Indicator): specifies the format of a frame that is exchanged between the bus
Ethernet and a Fiber Distributed Data Interface (FDDI) or between the bus Ethernet and the token ring
network.
 VLAN ID: specifies the VLAN to which a frame is to be sent. Each VLAN is identified by a VLAN ID.
 VLAN ID (VLANID): specifies the identifier of a VLAN. The mapping relations of VLANID should be
preconfigured in the BSC6900. The BSC6900 determines the ID of a VLAN frame according to the
VLANID mapping relations. The BSC6900 supports two VLAN configuration modes:
− Configuring VLAN according to the next hop
The VLAN ID is determined according to the preconfigured mapping between the next hop IP
address and the VLAN ID.
The related parameters are Next Hop IP address (IPADDR) and VLAN ID (VLANID).
− Configuring VLAN according to the data stream
The VLAN ID is determined according to the preconfigured mapping among the SCTP link, IP path,
and VLAN ID.
The related parameters are SCTP link No. (SCTPLNKN), IP path ID (PATHID), and VLAN ID
(VLANID).
 VLAN Priority (VLANPRI): specifies the priority of a VLAN frame.
VLAN configuration supported by the interfaces of the BSC6900 is described as follows:
 Interfaces of the GSM network
− The A and Abis interfaces support both VLAN configuration according to the next hop and VLAN
configuration according to the data stream.
− The Gb interface supports VLAN configuration according to the next hop.
− The Ater interface does not support VLAN.
 Interfaces of the UMTS network
− TheIub, Iu, and Iur interfaces support both VLAN configuration according to the next hop and VLAN
configuration according to the data stream.
3.2.3 Point-to-Point Protocol

PPP is a data link layer protocol, which is commonly used in a WAN.
PPP is designed to encapsulate and transmit datagrams of various network layer protocols over
point-to-point links. These network layer protocols include IP, Internetwork Packet Exchange (IPX), and
AppleTalk.
The BSC6900 supports the PPP protocol on the Iub, Iu, and Iur interfaces of the UMTS network and on
the Abis, A, and Ater interfaces of the GSM network.
Frame Format
The PPP frame format is defined in RFC1661, as shown in Figure 3-6.

SingleRAN
Figure 3-6 PPP frame format
The fields of the PPP frame are described as follows:

 Flag: indicates the start or end of a frame. This field of a PPP frame is set to a fixed value.
 Address: This field is set to a fixed value.
 Control: This field is set to a fixed value.
 Protocol: specifies the type of the protocol encapsulated by the Information field. For example, 0x0021
indicates that an IP datagram is encapsulated.
 Information (also known as payload): contains the upper-layer protocol datagram encapsulated by a
PPP frame. The size of the Information field varies and the maximum size is specified by the maximum
receive unit (MRU). The MRU is negotiable during the PPP link establishment. If the MRU is not
negotiated, the default size is 1,500 bytes.
 FCS: frame check sequence field.
 Board type (BRDTYPE): specifies the type of the interface board that carries a PPP link.
 E1T1 port No. (DS1) and Bearing time slot (TSBITMAP): specify the port number and the timeslot
number respectively of the E1/T1 link that carries the PPP link. The two parameters should be
specified only when the PEUa, POUa, or POUc board is used. A PPP link can be carried on only one
of the E1/T1 links of the BSC6900. It can be carried on all the timeslots of an E1/T1 link, that is,
timeslot 1 through timeslot 31 of an E1 link, or timeslot 1 through timeslot 24 of a T1 link, with the
bandwidth of each timeslot being 64 kbit/s. A PPP link can also be carried on some of the timeslots of
an E1/T1 link. In this case, it is called Fractional IP. After being transmitted through a timeslot cross
connection device on the intermediate transport network, the PPP link can be carried on only one of
the E1/T1 links.
 PPP link No. (PPPLNKN): specifies the number of a PPP link. It uniquely identifies a PPP link on an
interface board.
 Local IP address (LOCALIP), Peer IP address (PEERIP), and Subnet mask (MASK): specify the
local IP address, peer IP address, and subnet mask respectively of a PPP link. The device IP address
can also be used as the local IP address of a PPP link to save the IP address resources. To use the
device IP address as the local IP address, set the Borrow DevIP (BORROWDEVIP) parameter to Yes
and then specify the Borrowed device IP address (DEVIP) parameter.
 CRC check mode (FCSTYPE): specifies the size of the FCS field.
PPPMux
PPPMux is a technology through which multiple PPP payloads (also called PPPMux subframes) are
concatenated into a single PPP frame (also called a PPPMux frame) to reduce the overhead per PPP
subframe and improve the bandwidth utilization of PPP links.
PPPMux is applicable to scenarios where short packets such as speech and data are transmitted over
low-speed links. For long packets, PPPMux cannot improve the transmission efficiency to a large extent
but it increases the transmission delay. Therefore, using PPPMux to transmit long packets is not
recommended.

SingleRAN
The PPPMux frame format is defined in RFC3153. The Information field of a PPPMux frame consists of
a one-byte PPPMux identifier (set to 0x59) and multiple subframes. The subframes are separated by
separators.
The BSC6900 supports PPPMux on the Iub, Iur, and Iu interfaces of the UMTS network and on the Ater
interface of the GSM network.
 PPP mux (PPPMUX): specifies whether a PPP link supports the PPPMux function.
 PPP mux max sub-frame length (MAXSFLEN): specifies the maximum size of a PPPMux subframe.
If the size of a PPPMux subframe exceeds the value of this parameter, the subframe is directly
transmitted without being multiplexed.
 PPP mux max mux-frame length (MAXMFLEN): specifies the maximum size of a PPPMux frame.
 PPP mux framing out-time[us] (MUXTIME): specifies the maximum time waiting for multiplexing. If
the waiting time exceeds the value of this parameter, the PPPMux frame is transmitted without being
added with more PPPMux subframes.
3.2.4 Multilink-PPP
MLPPP (also called MP) is an extension of the PPP protocol. It is a data link layer protocol that exists
between PPP and the network layer.
Data Transmission Mechanism

MLPPP is a technology through which multiple PPP physical links (also called MLPPP sublinks) are
combined into one logical link. MLPPP fragments network layer packets and then transmits the
fragmented packets over MLPPP sublinks. In this manner, the bandwidth, data transmission rate, and
throughput are increased. In addition, the transmission delay is reduced.
Figure 3-7 shows the data transmission mechanism of MLPPP.
Figure 3-7 Data transmission mechanism of MLPPP
NOTE
A PPP link or an MLPPP link can be carried on only one E1/T1 link. In this case, the PPP or MLPPP link can be carried on
all the timeslots of an E1/T1 link, that is, timeslot 1 through timeslot 31 of an E1 link, or timeslot 1 through timeslot 24 of a
T1 link, with the bandwidth of each timeslot being 64 kbit/s. It can also be carried on some of the timeslots of an E1/T1 link.
When it is carried on some of the timeslots, the peer end reassembles the original IP packets from these timeslots, and
other timeslots can transmit other data. This function is called Fractional IP (WRFD-050411 Fractional IP Function on Iub
Interface).

SingleRAN
Frame Format
The MLPPP frame format is defined in RFC1990. The MLPPP frame has two formats: with long
sequence number and with short sequence number, as shown in Figure 3-8 and Figure 3-9 respectively.
Figure 3-8 MLPPP frame format with long sequence number
Figure 3-9 MLPPP frame format with short sequence number
The fields of the MLPPP frame header are described as follows:

 B: Beginning fragment bit (one bit). This field indicates whether an MLPPP frame is the beginning
fragment of a PPP frame.
 E: Ending fragment bit (one bit). This field indicates whether an MLPPP frame is the last fragment of a
PPP frame.
 MLPPP group:
− Board type (BRDTYPE): specifies the type of the interface board that carries an MLPPP link.

SingleRAN
− MP Group No. (MPGRPN): specifies an MLPPP group within an interface board.

− MP type (MPTYPE): specifies whether the type of an MLPPP group is MLPPP or MCPPP.
− Local IP address (LOCALIP), Subnet mask (MASK), and Peer IP address (PEERIP): specify the
local IP address, subnet mask, and peer IP address respectively of an MLPPP group. The device IP
address can also be used as the local IP address of an MLPPP group to save the IP address
resources. To use the device IP address as the local IP address, set the Borrow DevIP
(BORROWDEVIP) parameter to Yes and then specify the Borrowed device IP address (DEVIP)
parameter.
− MP flake size (FRAGSIZE): specifies the size of an MLPPP fragment. MLPPP fragments network
layer packets according to the value of this parameter. Both MLPPP and MCPPP support the
fragmentation function, and the fragment size is determined by this parameter.
 MLPPP link:
− E1T1port No. (DS1) and Bearing time slot (TSBITMAP): specify the E1/T1 port number and the
bearer timeslot respectively of the PEUa, POUa, or POUc board that carries a PPP link.
− PPP sub-link No. (PPPLNKN): identifies an MLPPP link on an interface board.
− MP Group No. (MPGRPN): specifies the MLPPP group to which an MLPPP link belongs.
− CRC check mode (FCSTYPE): specifies the size of the FCS field.
Multi-Class PPP
MCPPP (also called MC) is an extension of MLPPP. Compared with MLPPP, MCPPP provides service
priorities. High-priority packets can interrupt the transmission of low-priority packets. The MCPPP frame
format is defined in RFC2686.
When adding an MLPPP group on the BSC6900 side, set the MP type (MPTYPE) parameter to MLPPP
or MCPPP.
 If this parameter is set to MCPPP, the MLPPP group transmits data to the peer end according to the
MCPPP protocol. In addition, the MC PRI number (MCCLASS) parameter needs to be specified,
which indicates the number of priorities supported by MC.
 If this parameter is set to MLPPP, the MLPPP group transmits data to the peer end according to the
MLPPP protocol. For details, see section 3.2.4 "Multilink-PPP."
The default setting, MCPPP, is recommended.
3.3 Internet Protocol

IP is a primary protocol at the network layer. The IP protocol supports a universal packet format, that is,
IP datagram. The IP datagram conceals the differences in implementation at the data link layer and
enables network interworking. Other protocols, such as TCP, UDP, Internet Control Message Protocol
(ICMP), and Internet Group Management Protocol (IGMP) in the TCP/IP protocol stack, transmit data in
the IP datagram format.
The IP protocol is an unreliable and connectionless data packet protocol. It provides functions such as IP
addressing, routing, IP datagram fragmentation, and IP datagram reassembly.
3.3.1 Datagram Format

At the transmission end, the IP layer receives the source data packet (for example, a UDP message)
from the upper layer. Then, the IP layer determines whether to segment the data packet according to the
MTU of the data link layer. The data after being segmented is called segment. Data packets or segments
are encapsulated into IP datagrams in a fixed format. Later, IP datagrams are transmitted to the data link
layer and then transmitted over Internet.

SingleRAN
An IP datagram is conceptually divided into two pieces: the header and the payload. The header
contains addressing and control fields, whereas the payload carries the actual data to be sent over the
Internet.
At the reception end, the IP layer receives data from the data link layer, reassembles the payload to
obtain the original data packet, and then transmits the data to the upper layer for further processing.
Figure 3-10 shows the IP datagram format.
Figure 3-10 IP datagram format
The fields of the IP datagram are described as follows:

 Version: contains the IP version number. For example, 4 indicates IPv4.
 IHL (Internet Header Length): specifies the size of an IP datagram header. The minimum size of the IP
datagram header is 20 bytes (excluding the size of the Options field), and the maximum size is 60
bytes (including the size of the Options field).
 TOS: specifies the type of service. Of the eight bits occupied by the TOS field, three bits specify the
priority (obsolete now) of the IP datagram, four bits specify the optional service type (minimum delay,
maximum throughput, maximum reliability, and minimum cost), and one bit is permanently set to 0.
 Total Length: specifies the total size of an IP datagram.
 Identification: identifies the datagram sent by a host. The value of this field is common to each of the
fragments belonging to a particular message. This field is used by the reception end to reassemble
messages without accidentally mixing fragments from different messages.
 Flags: specifies whether the current data is the last fragment of an IP datagram and whether
fragmentation is allowed. This field is used to fragment and reassemble datagrams.
 Fragment Offset: specifies the position of a fragment in an IP datagram. This field is used to fragment
and reassemble datagrams.
 TTL (Time to Live): specifies how long the IP datagram is allowed to “live” on the network, in terms of
router hops. Each router decrements the value of the TTL field (reduces it by one) before transmitting it.
When the value of TTL becomes zero, the IP datagram is discarded. Meanwhile, an ICMP packet is
sent to the transmission end.
 Protocol: specifies the type of the upper-layer protocol carried in the IP datagram, which can be TCP,
UDP, ICMP, or IGMP.
 Header Checksum: contains the checksum on the header of an IP datagram.
 Source IP Address: specifies the source IP address of an IP datagram.
 Destination IP Address: specifies the destination IP address of an IP datagram.

SingleRAN
 Options: specifies whether measures such as error correction, measurement, and security are taken.
This field has a variable size, from 1 byte to 40 bytes, depending on the selected items. Padding may
be added to ensure that the size of this field is a multiple of four.
 Data: contains the data to be transmitted in the datagram, either an entire higher-layer message or a
fragment of one message.
3.3.2 IP Address and Routing

The following describes the classes of IP addresses, the subnet mask, and the IP routing of the
BSC6900.
IP Address
The IP protocol defines the IP address, which uniquely identifies a host or a port of a router on the
Internet. An IP address consists of the network part and the host part. The network part uniquely
identifies a network or a subnet, and the host part uniquely identifies a host on a subnet.
In the IP transport architecture, four types of IP addresses are used, as described in Table 3-1.
Table 3-1 Description of four types of IP addresses
IP Address Description
Eth Port IP address Each Ethernet port must be configured with at least one IP address.
PPP link/MLPPP link IP Each PPP link/ MLPPP link must be configured with one IP address, which
address can be the device IP address.
Device IP address Device IP address indicates the IP address of an IP interface board. Whether
to configure the device IP address is optional.
Eth Trunk IP address Several Ethernet ports can be bound to form an Eth Trunk port. One Eth Trunk
port should be configured with at least one IP address.
Note:
The Eth Port IP address, PPP link IP address, and MLPPP link IP address are collectively called port IP addresses.
Caution:
All the IP addresses of the BSC6900 cannot be on the same network segment.
Figure 3-11 shows the distribution of four types of IP addresses on an IP interface board.

SingleRAN
Figure 3-11 Distribution of four types of IP addresses on an IP interface board
PPP/MP IP address
IP over E1 interface board Device IP
PPP/MP IP address
Eth Port IP address

IP over FE/GE interface board Device IP
Eth Port IP address
IP over FE/GE interface board Device IP ETH Trunk IP address
The four types of IP addresses use the standard IP addresses defined in the IP protocol. The IP protocol
also defines some special IP addresses. For example, an IP address with all 0s in the host part indicates
a network segment IP address. A network segment IP address identifies a subnet. All the hosts on the
same subnet have the same subnet mask and network segment IP address.
Subnet Mask
A network device uses subnet mask to differentiate between the network part and the host part in an IP
address. The subnet mask has the same structure as an IP address, that is, all 1s are in the network part
and all 0s are in the host part.
Generally, the length of a subnet mask is used to indicate the subnet mask. The length of a subnet mask
is in decimal form and represents the number of 1s in the subnet mask. For example, the length of the
subnet mask 11111111.11111111.11111111.11000000 is 26. The subnet mask can also be represented in
the "IP address/length of subnet mask" form. For example, "10.161.161.7/26" means that the length of
the subnet mask is 26 and the IP address is 10.161.161.7.
The related parameters of the BSC6900 are described as follows:
 Subnet mask (MASK): specifies the subnet mask at the local end. This parameter is used to
configure the device IP address and port IP address at the local end.
 Peer subnet mask (PEERMASK): specifies the subnet mask at the peer end. This parameter is used
to configure the IP address at the peer end.
IP Routing
IP Routing is an umbrella term for the set of protocols that determine the path that data follows in order to
travel across multiple networks from its source to its destination.
 Destination IP address (DSTIP): specifies the destination IP address, which can be a host IP address
or a network segment IP address.
 Destination address mask (DSTMASK): specifies the subnet mask of the destination subnet. The
binary AND operation is performed on the destination IP address and the subnet mask. The operation
result determines the scope of the destination IP addresses that the route can reach.
 Forward route address (NEXTHOP): specifies the IP address of the next hop of a route.
 Priority (PRIORITY): specifies the priority of a route.

SingleRAN
− When multiple routes to the same subnet are configured, these routes can be classified into the
following two types according to the setting of the Priority (PRIORITY) parameter:
Active and standby routes: indicate multiple routes that can reach the same subnet but have different
priorities.
Equivalent routes: indicate multiple routes that can reach the same subnet and have the same
priority. In load sharing mode, equivalent routes must be configured.
− If
multiple routes to the same subnet are configured, by default the system uses the route whose
subnet mask is long. If two routes have subnet masks of the same length, by default the system uses
the route with a higher priority.
3.3.3 Layer 2 Networking and Layer 3 Networking

According to the data switching technology, IP networking can be classified into layer 2 networking and
layer 3 networking.
Layer 2 Networking
In layer 2 networking, all the network devices are located on the same network segment, data is
switched by a layer 2 device (for example, a LAN switch), and IP routes do not need to be configured.
Figure 3-12 shows layer 2 networking.
Figure 3-12 Layer 2 networking
In layer 2 networking, VLAN can be used to separate broadcast domains, suppress broadcast storm,
improve transmission security, and provide differentiated services.
Layer 3 Networking
In layer 3 networking, the network devices are located on different network segments, data is switched
by a layer 3 device (for example, a router), and IP routes have to be configured.
Figure 3-13 shows layer 3 networking.

SingleRAN
Figure 3-13 Layer 3 networking
3.4 User Datagram Protocol

The UDP protocol is used to transmit user data stream. UDP runs over the network layer and is an
unreliable and connectionless transport layer protocol.
UDP is mainly used to perform conversion between network data streams and UDP datagrams. At the
transmission end, UDP encapsulates network data streams into datagrams and then transmits the
datagrams. At the reception end, UDP de-encapsulates datagrams to obtain the original data.
Datagram Format
Figure 3-14 shows the UDP datagram format.
Figure 3-14 UDP datagram format
The fields of the UDP datagram are described as follows:

 Source Port and Destination Port: specify the type of upper-layer application at the source end and
destination end respectively.
 Length: indicates the number of bytes in the UDP header and Data fields.
 Checksum: contains the checksum on the UDP header and Data fields.
 Data: contains the data to be received by the destination application. The size of this field is variable.
IP Path
In the IP transport architecture, the UDP data stream is carried over IP path. IP path is a logical entity
that is established for the UDP transmission resources of devices. It enables both communication ends
to provide admission bandwidth, flow control, and differentiated services.

SingleRAN

 Local IP address (IPADDR): specifies the IP address of an IP path on the BSC6900 side. This IP
address is used for data transmission on the user plane. The local IP address can be the port IP
address or device IP address.
 Peer IP address (PEERIPADDR): specifies the IP address of an IP path at the peer end. This IP
address is used for data transmission on the user plane. The peer IP address can be a host IP address
or a network segment IP address, as shown in Figure 3-15.
 Peer subnet mask (PEERMASK): specifies the subnet mask at the peer end. The default value of
this parameter is 255.255.255.255, which indicates that the IP path has only one peer IP address. If
the peer end of the IP path has multiple IP addresses, the value of this parameter needs to be
configured.
 IP path type (PATHT): specifies the type of IP path. IP paths of different types can be configured
between both parties in a communication to carry the service data of different types. For details about
the mapping between the types of IP paths and the types of services, see the Transmission Resource
Management Feature Parameter Description.
 Forward Bandwidth (TXBW): specifies the admission bandwidth of the IP path in the transmission
direction. For details about the admission bandwidth, see the Transmission Resource
ManagementFeature Parameter Description.
 Backward Bandwidth (RXBW): specifies the admission bandwidth of the IP path in the reception
direction. For details about the admission bandwidth, see the Transmission Resource Management
Feature Parameter Description.
Figure 3-15 is shown as an example, in which the peer end of the IP path is a network segment.
Figure 3-15 Example of setting the peer IP addresses of an IP Path
In this example, an IP path is configured between the BSC6900 and the SGSN, and the IP path has
three IP addresses on the SGSN side. Peer IP address (PEERIPADDR) and Peer subnet mask
(PEERMASK) of the IP path need to be set to the network segment IP address and the subnet mask
respectively, for example, 20.10.10.0/28. When planning the subnet at the peer end, reserve some IP
addresses so that no more configuration is required on the BSC6900 side when some new IP addresses
are added to the subnet.
3.5 Real-Time Transport Protocol

The RTP protocol is specially designed for transmitting Internet multimedia data.
RTP is usually used in combination with UDP to transmit real-time data. UDP is responsible for
transmitting datagrams, but it does not ensure the timing sequence of datagram transmission. RTP adds
fields such as Timestamp and Sequence Number to the datagrams to provide timing information and

SingleRAN
implement streaming synchronization. RTP, however, does not provide reliable transmission
mechanisms, flow control, or congestion control.
Figure 3-16 shows the RTP datagram format.
Figure 3-16 RTP datagram format
The fields of the RTP datagram are described as follows:

 V: specifies the version of RTP.
 P: specifies whether padding is added to the tail of the datagram.
 X: specifies whether an Extension header exists between the standard header and the payload data.
 CC: contains the number of CSRC identifiers that follow the fixed header.
 M: contains the marker.
 PT: specifies the type of payload. The transmission end uses this field to indicate the coding scheme
used at the reception end.
 Sequence Number: specifies the number of an RTP datagram. The Sequence Number is incremented
by one each time an RTP datagram is sent.
 Timestamp: specifies the time point when an RTP datagram is sent. The Timestamp and Sequence
Number fields are used by the reception end to sequentially play back the received RTP datagrams.
 SSRC Identifier: identifies the synchronization source.
 CSRC Identifier: identifies the contributing source of the payload in an RTP datagram.
 Payload: contains the payload.
3.6 Stream Control Transmission Protocol

The SCTP protocol provides connection-oriented reliable transmission between both SCTP end points
by establishing an SCTP association.
SCTP is a transport layer protocol and it is designed to transmit signaling. SCTP meets the requirements
of high-performance transmission by implementing the following mechanisms:
 Multi-homing
 Multi-streaming
 Initiation protection

SingleRAN
 Message framing
 Configurable unordered delivery
 Graceful shutdown
An SCTP link is a connection between two SCTP end points. It is identified by the combination of the
local IP address, local SCTP PORT No., peer SCTP PORT No., and peer IP address. The following
describes the transmission mode and multi-homing of the SCTP link.
SCTP Link Transmission Mode

Both end points of an SCTP link work in server/client mode. The client sends a link initiation request, and
the server listens to the listening port.
On the Iub interface, the BSC6900 must be configured as the server of an SCTP link. On the Iu and Iur
interfaces, it is recommended that the BSC6900 be configured as the client. On the A interface, the
BSC6900 is always configured as the client and therefore manual configuration is not required.
The BSC6900 parameter related to SCTP is Signalling link mode (MODE), which can be set to
SERVER or CLIENT.
Multi-Homing
In the case of multi-homing, both end points of an SCTP link are bound with multiple IP addresses.
Therefore, redundancy transmission paths exist between the two SCTP end points. If a path is faulty,
data can be transmitted on another path. This improves the fault tolerance capability.
On the BSC6900 side, a single SCTP link is bound with a maximum of two IP addresses. If an SCTP link
is bound with two IP addresses on the BSC6900 side, the peer end must also be bound with two IP
addresses.
The BSC6900 supports SCTP multi-homing on the Iub, Iu, and Iur interfaces of the UMTS network and
on the A interface of the GSM network.
 Local IP address and port
− First
local IP address (LOCIP1): When SCTP multi-homing is not used, this parameter specifies the
IP address of an SCTP link on the BSC6900 side. When SCTP multi-homing is used, this parameter
in combination with PEERIP1 specifies the main path of an SCTP link.
− Second
local IP address (LOCIP2): specifies the second IP address of an SCTP link on the
BSC6900 side. This parameter should be set only when SCTP multi-homing is used.
− Local SCTP port No. (LOCPN): specifies the local port number of an SCTP link. This parameter
should be set only when the BSC6900 functions as the client. When the BSC6900 functions as the
server, the two local IP addresses correspond to the same SCTP port, which is specified by NBAP
service listening port No. (NBAPSRVPN) on the Iub interface and by M3UA service listening port
No. (M3UASRVPN) on the Iu and Iur interfaces.
 Peer IP address and port
− Firstdestination IP address (PEERIP1): When SCTP multi-homing is not used, this parameter
specifies the peer (that is, NodeB in the case of Iub) IP address of an SCTP link. When SCTP
multi-homing is used, this parameter in combination with LOCIP1 specifies the main path of an SCTP
link.
− Second destination IP address (PEERIP2): specifies the second peer IP address of an SCTP link.
This parameter should be set only when SCTP multi-homing is used.
− Destination SCTP port No. (PEERPN): specifies the peer port number of an SCTP link.

SingleRAN
 Cross IP address available flag (CROSSIPFLAG): specifies whether the cross path of an SCTP link
is available.
Figure 3-17 shows SCTP multi-homing.
Figure 3-17 SCTP multi-homing
Path 1
IP 1 Network IP 3
Path 2
SCTP server Path 3 SCTP client
IP 2 IP 4
Path 4
As shown in Figure 3-17, the SCTP link between the server and the client adopts multi-homing, and
each end point has two IP addresses. Thus, there are a maximum of four paths: Path 1 (between IP 1
and IP 3), Path 2 (between IP 1 and IP 4), Path 3 (between IP 2 and IP 3), and Path 4 (between IP 2 and
IP 4). Assume that IP 1 and IP 3 are the first IP addresses at both ends of the SCTP link. Then, Path 1 is
the main path, Path 2 and Path 3 are the cross paths, and Path 4 is the standby path.
Generally, SCTP messages are transmitted over the main path. If the main path is unavailable, SCTP
end points detect whether other paths are available by sending heartbeat messages. If another path is
available, the SCTP messages are transmitted over that path.
The Cross IP address available flag (CROSSIPFLAG) parameter specifies whether the cross paths
are available. If this parameter is set to UNAVAILABLE, the cross paths are disabled and only the main
and standby paths can be used.
3.7 MTP3-User Adaptation Layer

The M3UA protocol is the user adaptation protocol for MTP3 or MTP-3b. It provides primitive-based
communication services for the MTP3 users on the IP network and for the MTP3 users (on the signaling
gateway) at the network edge. M3UA enables the interworking between TDM-based SS7 and IP.
M3UA provides connectionless services. The data configurations of M3UA are similar to those of
MTP-3b. The local and destination entities of M3UA can be considered as the originating signaling point
(OSP) and destination signaling point (DSP) of SS7.
 Local entity No. (LENO): identifies a local entity within the OSP.
 Destination entity No. (DENO): identifies a destination entity within the DSP.
 Local entity type (ENTITYT) and Destination entity type (ENTITYT): specify the type of local and
destination entities respectively. The type of local entity can be M3UA_ASP or M3UA_IPSP. The type
of destination entity can be M3UA_SGP, M3UA_IPSP, M3UA_SS7SP, or M3UA_SP. For details
about ASP, SGP, IPSP, and SS7SP, see RFC4666.
 Routing Context (RTCONTEXT): specifies the route context of the M3UA local entity in the ADD
M3LE command or the route context of the M3UA destination entity in the ADD M3DE command. For
details, see RFC4666.
 Signalling link set index (SIGLKSX): uniquely identifies a signaling link set within the BSC6900.
 Signalling link mask (LNKSLSMASK): specifies the signaling link mask corresponding to an M3UA
link set. It is used for the M3UA link load sharing. In the value of this parameter, the number of 1s
(represented by n) determines the maximum number (2n) of links for load sharing. For example, B0000
indicates that a maximum of one (20) link is used for load sharing; B0001 and B1000 indicate that a

SingleRAN
maximum of two (21) links are used for load sharing. The additional links are not used for load sharing.
The AND operation between this value and the value of the Signalling route mask (SLSMASK)
parameter in the ADD N7DPC command must be equal to 0.
 Traffic mode (TRAMODE): specifies the traffic mode of an M3UA link set. Currently, the value of this
parameter can be M3UA_OVERRIDE_MOD or M3UA_LOADSHARE_MOD. For details about the two
modes, see RFC4666.
 Work mode (WKMODE): specifies the working mode of an M3UA link set. The value of this parameter
can be M3UA_ASP or M3UA_IPSP. For details about ASP and IPSP, see RFC4666.
 PENDING timer (PDTMRVALUE): specifies the value of the PENDING timer for an M3UA link set.
 Signaling link ID (SIGLNKID): uniquely identifies a signaling link within a signaling link set (specified
by the Signalling link set index (SIGLKSX) parameter).
 SCTP link No. (SCTPLNKN): specifies the SCTP link that carries an M3UA link.
 Signalling link priority (PRIORITY): specifies the priority of a signaling link. Value 0 indicates the
highest priority.
 Initial bearing traffic active tag (LNKREDFLAG): specifies the initial bearer flag of an M3UA link.
The value of this parameter can be M3UA_MASTER_MOD or M3UA_SLAVE_MOD. For details about
the bearer flag, see RFC4666.
 Route priority (PRIORITY): specifies the priority of a route. Value 0 indicates the highest priority.
3.8 Signaling Connection Control Part

SCCP provides additional functions for MTP-3b and M3UA. It enables the SS7 signaling points to
transmit circuit-related messages and non-circuit-related messages.
SCCP supports connection-oriented and connectionless services and provides address resolution. In
the IP transport architecture, SCCP is used on the Iu, Iur, and A interfaces to transmit RANAP, RNSAP,
and BSSMAP messages respectively. Messages related to a single user are transmitted in
connection-oriented mode, and other messages are transmitted in connectionless mode.
SCCP performs addressing according to the Destination Point Code (DPC) and the Subsystem Number
(SSN). Both communication parties use the SSN to identify the upper-layer application, such as RANAP
or RNSAP. The parameters of the BSC6900 are as follows:
 OSP index (SPX): uniquely identifies an OSP in the SS7 signaling network. For the BSC6900 GU, two
OSPs can be configured. One OSP is configured for the GSM BSC and the other for the UMTS RNC.
 DSP index (DPX): uniquely identifies a DSP in the SS7 signaling network.

SingleRAN
IP Transport Architecture 4 IP Transmission Efficiency Improvement
4 IP Transmission Efficiency Improvement

4.1 Introduction
With the development of communications services and the increase in device capacity, more and more
data flow is transmitted over each interface. This results in demands for improvements of the
transmission efficiency in order to increase the bandwidth utilization.
The BSC6900 provides IP transmission efficiency improvement mechanisms based on the
characteristics of the protocols, as shown in Figure 4-1.
Figure 4-1 IP transmission efficiency improvement mechanisms
The following sections describe the IP transmission efficiency improvement mechanisms.
4.2 Frame Protocol Multiplexing

Frame Protocol Multiplexing (FP-Mux, WRFD-050420 FP MUX for IP Transmission) encapsulates
multiple FP PDUs into one FP-Mux packet, thus reducing the UDP/IP/L2/L1 header transmission
overhead and resulting in improved transmission efficiency.
FP-Mux has the following characteristics:
 The implementation is simple. FP-Mux requires the support of only the transmission end and the
reception end. The intermediate transport equipment does not need to support FP-Mux.
 FP-Mux significantly improves the transmission efficiency but increases the transmission delay.
 FP-Mux is not an open standard.
FP-Mux is applicable to the user plane of the Iub interface that is based on IP transmission.
4.2.1 Datagram Format

Figure 4-2 shows the format of the IP datagram that adopts FP-Mux. The multiplexed IP datagram has
the following characteristics:
 The FP PDUs in one FP-Mux frame share the IP and UDP headers and thus must have the same
source IP address, destination IP address, and DSCP.
 One FP-Mux frame can carry the data of multiple users. The FP-Mux header specifies the size and
owner of each FP PDU.
 The UDP header contains a fixed source UDP port number. The number indicates that this packet is
an FP-Mux frame and therefore requires demultiplexing at the reception end.

SingleRAN
Figure 4-2 FP-Mux IP packet format
FP-Mux frame
FP subframe 1 FP subframe 2 FP subframe m
IP header UDP header FP-Mux FP PDU FP-Mux FP PDU ... FP-Mux FP PDU
header header header
20/40 bytes 8 bytes 3-4 bytes n byte 3-4 bytes n bytes ... 3-4 bytes n bytes
User Length
identifier indicator
2 bytes 1-2 bytes
The fields of the FP-Mux IP packet are described as follows:

 User Identifier: specifies the owner of the FP PDU.
 Length Indicator: specifies the size of the FP PDU.
 FP PDU: is the payload of the FP subframe.
FP-Mux significantly improves the transmission efficiency. Take the speech service as an example. The
size of each speech datagram is 41 bytes, and the total size of the IP and UDP headers is 28 bytes. If
FP-Mux is not applied, the size of the IP datagram is 69 bytes (28 bytes + 41 bytes). If FP-Mux is applied,
the transmission efficiency is improved, because the ratio of the UDP data size to the IP datagram size
increases from 60% to 70% or even to 90% when the number of FP subframes in the FP-Mux frame
increases. The ratio equals (41 x n) divided by (28 + 41 x n), where n is a natural number. However,
when the size of the IP datagram increases, the transmission delay also increases.
 IP MUX Type (MUXTYPE): specifies whether the FP-Mux function is enabled on the BSC6900 side.
When this parameter is set to FPMUX, the FP-Mux function is enabled.
 Max subframe length[byte] (SUBFRAMELEN): specifies the maximum size of an FP subframe. If
the size of an FP frame exceeds the value of this parameter, the FP subframe is not multiplexed.
 Maximum Frame Length[byte] (MAXFRAMELEN): specifies the maximum size of an FP-Mux frame.
 Maximum Delay Time[ms] (FPTIMER): specifies the maximum time that the system waits before
sending the multiplexed data. If the waiting time exceeds the value of this parameter, the system
immediately sends the multiplexed data in order to prevent a too long delay.
4.2.2 FP-Mux Principles

The prerequisites for enabling the FP-Mux function are as follows:
 Both the BSC and the BTS support the FP-Mux function.
 The data related to the FP-Mux function is configured on both the BSC and BTS sides.
Figure 4-3 shows the working principles of FP-Mux at the transmission end.

SingleRAN
Figure 4-3 Buffering and multiplexing performed at the transmission end
The transmission end buffers the user data (FP PDUs) and encapsulates the data into FP-Mux frames
according to specific multiplexing conditions. Then, the FP-Mux frame is sent to the UDP layer.
The multiplexing conditions are as follows:
 If the size of an FP PDU exceeds SUBFRAMELEN, the FP PDU is not multiplexed but directly sent to
the UDP layer.
 If the size of an FP-Mux frame reaches MAXFRAMELEN, the FP-Mux frame is sent to the UDP layer
without multiplexing more FP PDUs.
 If the value of the timer reaches FPTIMER, the FP-Mux frame is sent to the UDP layer without
multiplexing more FP PDUs.
After receiving the FP-Mux frames in sequence, the reception end demultiplexes the frames to obtain the
original data and perform service processing.
4.3 Abis-Mux and Ater-Mux

The datagram format and working principle of both Abis-Mux and Ater-Mux are the same as those of
FP-Mux. For details, see section 4.2 "Frame Protocol Multiplexing."
The difference between Abis-Mux, Ater-Mux, and FP-Mux is that they are applicable to different
interfaces. Abis-Mux is applicable only to the user plane of the Abis interface that is based on IP
transmission. Ater-Mux is applicable only to the user plane of the Ater interface that is based on IP
transmission.
The BSC6900 parameters related to the Abis-Mux function are as follows:
 IPMUX Type (MUXTYPE): specifies whether the Abis-Mux function is enabled on the BSC6900 side.
When this parameter is set to AbisMux, the Abis-Mux function is enabled.
 Max Subframe Length (SUBFRAMETHRES): specifies the maximum size of an Abis-Mux subframe.
If the size of an Abis-Mux subframe exceeds the value of this parameter, the Abis-Mux subframe is not
multiplexed.
 Maximum Frame Length (PKTLENTHRES): specifies the maximum size of an Abis-Mux frame.
 Time Out (TIMEOUT): specifies the maximum time that the system waits before sending the
multiplexed data. If the waiting time exceeds the value of this parameter, the system immediately
sends the multiplexed data in order to prevent a too long delay.
 Service Type (SRVTYPE): specifies the type of service for which multiplexing is performed. The
service type can be CS speech service, CS data service, PS service with high priority, and PS service
with low priority.
The BSC6900 parameters related to the Ater-Mux function are as follows:
 IPMUX Type (MUXTYPE): When this parameter is set to AterMux, the Ater-Mux function is enabled
on the BSC6900 side.

SingleRAN
4.4 UDP Multiplexing

UDP Multiplexing (UDP-Mux, WRFD-050412 UDP MUX for Iu-CS Transmission) is a transport bearer
multiplexing technology, which is defined in 3GPP TR 29.814. It is also called RTP-Mux. This technology
enables multiple RTP packets to be multiplexed in one UDP packet, thus reducing the overhead of the
UDP/IP/L2/L1 header and increasing the transmission efficiency.
UDP-Mux has the following characteristics:
 The implementation is simple. UDP-Mux requires support only at the transmission end and the
reception end. The intermediate transport equipment does not need to support UDP-Mux.
 UDP-Mux significantly improves the transmission efficiency but increases the transmission delay.
 UDP-Mux is an open standard.
UDP-Mux is applicable to the user planes of the Iu-CS and A interfaces that are based on IP
transmission.
4.4.1 Packet Format

UDP-Mux has two multiplexing modes:
 Multiplexing mode 1: In this mode, the RTP header is multiplexed without being compressed. The size
of an RTP header is 12 bytes. Figure 4-4 shows the IP datagram format with the RTP header
uncompressed.
 Multiplexing mode 2: In this mode, the RTP header is compressed and then multiplexed. The field that
remains unchanged during a call is removed from the RTP header, and only the variable Sequence
Number and Timestamp fields are reserved. Thus, the size of the RTP header after compression is 3
bytes for the UMTS network and 4 bytes for the GSM network. Figure 4-5 shows the IP datagram
format with the RTP header compressed.
Figure 4-4 IP datagram format with the RTP header uncompressed

SingleRAN
Figure 4-5 IP datagram format with the RTP header compressed
The fields of the IP multiplexing datagram are described as follows. For the descriptions of other fields,
see the related contents in Section 3 "IP Transport Protocols."
 T: specifies whether the RTP header is compressed. Value 0 indicates that the RTP header is not
compressed, and value 1 indicates that the RTP header is compressed.
 Mux ID: is used in combination with the Source ID field to identify a user plane connection. The value
of this field is equal to the destination UDP port number of the RTP packet divided by two.
 Length indicator: specifies the size of a multiplexed RTP packet, including the size of the RTP header
and payload. This field gives the information where the next multiplexed packet starts.
 R: reserved extension bit. This field is set to 0.
 Source ID: is used in combination with the Mux ID field to identify a user plane connection. The value
of this field is equal to the source UDP port number of the RTP packet divided by two.
 Sequence Number: specifies the sequence number of an RTP datagram.
 Timestamp: specifies the time point when an RTP datagram is sent.
 Payload Type: specifies the type of the payload.
The UDP-Mux packet has the following characteristics:
 The RTP packets in one UDP-Mux packet share the IP and UDP headers and thus must have the
same source IP address, destination IP address, and DSCP.
 A single UDP-Mux packet can carry the data of different users. The Multiplex header specifies the size
and owner of each RTP packet.
 The UDP header includes a fixed source UDP port number, which indicates that the packet is a
UDP-Mux packet. Therefore, demultiplexing is required at the reception end.
As shown in Figure 4-4 and Figure 4-5, when k RTP packets are multiplexed into one UDP packet, the IP
packet overhead is reduced. When the RTP header is not compressed, an overhead of (23 x k - 28)
bytes is saved. When the RTP header is compressed, an overhead of (32 x k - 28) bytes is saved. In
addition, the total layer 2 and layer 1 header overhead decreases with the reduction of the number of
packets. Thus, the multiplexing efficiency is significantly improved. For detailed analysis, see 3GPP TR
29.814.

SingleRAN
 The following three parameters should be set in order to enable the UDP-Mux function.
− IP
MUX Type (MUXTYPE): specifies whether the UDP-Mux function is enabled on the BSC6900 side.
When this parameter is set to UDPMUX, the UDP-Mux function is enabled.
− Sender UDP MUX Mode (UDPMUXMODSEND): specifies the UDP Mux mode of the BSC6900
when it transmits data. The value of this parameter can be NORTPCOMP or RTPCOMP. If this
parameter is set to NORTPCOMP, the BSC6900 supports the UDP-Mux function with uncompressed
RTP headers when transmitting data. If this parameter is set to RTPCOMP, the BSC6900 supports
the UDP-Mux function with compressed RTP headers when transmitting data.
− Receive UDP MUX Mode (UDPMUXMODRECV): specifies the UDP Mux mode of the BSC6900
when it receives data. The value of this parameter can be NORTPCOMP or RTPCOMP. If this
parameter is set to NORTPCOMP, the BSC6900 supports the UDP-Mux function with uncompressed
RTP headers when receiving data. If this parameter is set to RTPCOMP, the BSC6900 supports the
UDP-Mux function with compressed RTP headers when receiving data.
 Max subframe length[byte] (SUBFRAMELEN): specifies the maximum size of an RTP packet that
can be multiplexed. If the size of an RTP packet exceeds the value of this parameter, the RTP packet
is not multiplexed but is directly transmitted.
 Maximum Frame Length[byte] (MAXFRAMELEN): specifies the maximum size of a UDP-Mux
packet. If the size of a UDP-Mux packet exceeds the value of this parameter, the packet is transmitted
without being added with more packets.
 Maximum Delay Time[ms] (FPTIMER): specifies the maximum time that the system waits before
sending the multiplexed data. If the waiting time exceeds the value of this parameter, the system
immediately sends the multiplexed data in order to prevent a too long delay.
4.4.2 UDP-Mux Principles

The prerequisites for enabling the UDP-Mux function are as follows:
 Both the BSC and the MGW support the UDP-Mux function.
 The data related to the UDP-Mux function is configured on both the BSC and MGW sides.
Figure 4-6 shows the working principle of UDP-Mux at the transmission end.
Figure 4-6 Buffering and multiplexing performed at the transmission end
The transmission end buffers the user data and encapsulates multiple RTP packets into one UDP-Mux
packet according to specific multiplexing conditions.
The multiplexing conditions are as follows:
 If the size of a UDP-Mux packet reaches MAXFRAMELEN, the UDP-Mux packet is sent without being
multiplexed with more RTP packets.
 If the value of the timer reaches FPTIMER, the UDP-Mux packet is sent without being multiplexed with
more RTP packets.

SingleRAN
After receiving the UDP-Mux packets in sequence, the reception end demultiplexes the packets to obtain
the original data and then performs service processing.
4.5 Header Compression

Header compression is used to reduce the frame header overhead on PPP links and to improve
bandwidth efficiency. Header compression requires the point-to-point support of both the transmission
and reception ends.
The BSC6900 supports the following types of header compression:
 Address and Control Field Compression (ACFC)
 Protocol Field Compression (PFC)
 IP Header Compression (IPHC)
Contrary to multiplexing technologies, header compression is applicable to the scenarios where the
transmission bit error rate on the interfaces is high.
The BSC6900 supports header compression on the Iub, Iur, and Iu interfaces of the UMTS network and
on the A and Ater interfaces of the GSM network. The following describes the three header compression
methods.
4.5.1 Address and Control Field Compression

ACFC is defined in RFC1661 and is used to compress the address and control fields of PPP and MLPPP
frames.
The size of the address and control fields in both the PPP and MLPPP frame headers is two bytes, and
these two fields have fixed values. Therefore, the two fields can be compressed. For details about the
PPP frame format, see section 3.2.3 "Point-to-Point Protocol." For details about the MLPPP frame
format, see section 3.2.4 "Multilink-PPP."
When a link is established, the transmission and reception ends negotiate link attributes, including
whether to use ACFC. If both ends determine to use ACFC, the address and control fields are omitted in
subsequent frames.
If the Address and control field compress (ACFC) parameter of the BSC6900 is set to Enable, the
BSC6900 supports ACFC and the two ends of the link negotiate whether to use ACFC. If this parameter
is set to Disable, the BSC6900 does not support ACFC.
4.5.2 Protocol Field Compression

PFC is defined in RFC1661 and is used to compress the protocol field of PPP and MLPPP frames.
The two-byte Protocol field of a PPP or MLPPP frame specifies the type of protocol encapsulated in the
Information field. For example, 0x0021 indicates that an IP datagram is encapsulated. The value of the
protocol type assigned is usually less than 256, which can be represented in one byte. Therefore, the
protocol field of most frames can be compressed to one byte.
The least significant bit of the Protocol field in a PPP or MLPPP frame specifies whether PFC is applied.
Value 0 indicates that the Protocol field is not compressed, and value 1 indicates that the Protocol field is
compressed.
If the Protocol field compress (PFC) parameter of the BSC6900 is set to Enable, the BSC6900
supports PFC and the two ends of the link negotiate whether to use PFC. If this parameter is set to
Disable, the BSC6900 does not support PFC.

SingleRAN
4.5.3 IP Header Compression

IPHC is defined in RFC2507 and RFC3544. It is used to compress the IP/UDP/RTP header over PPP
links.
IPHC improves bandwidth utilization in the following ways:
 The header can be classified into two types: fixed fields and variable fields. In IPHC, the fixed fields
are only included in some packets and omitted in other packets, whereas the variable fields are
represented in less bytes for each packet..
 When a PPP link is established, both parties in a communication send packets with complete headers
to establish the header context before they can send packets with compressed headers. With the
header context, complete headers can be retrieved from the compressed headers.
The Head compress (IPHC) parameter of the BSC6900 specifies whether the IP header of a PPP or
MLPPP link is compressed.
 If this parameter is set to No_HC, the BSC6900 does not support IPHC.
 If this parameter is set to UDP/IP_HC, the BSC6900 supports UDP and IP header compression, and
the two ends of the link negotiate whether to compress the UDP and IP headers at link establishment.
 If this parameter is set to RTP/UDP/IP_HC, the BSC6900 supports UDP, RTP, and IP header
compression, and the two ends of the link negotiate whether to compress the UDP, RTP, and IP
headers at link establishment.

SingleRAN
IP Transport Architecture 5 IP Clock Synchronization
5 IP Clock Synchronization
5.1 Introduction
In a communication system, clock synchronization is a key factor to ensure the reliable and error-free
transmission of speech and data. With the wide application of IP technologies in the communication
system, clock synchronization becomes more and more complex. Currently, three IP clock
synchronization solutions are available:
 Clock over IP solution
 IEEE1588 V2 solution
 Synchronous Ethernet solution
IP clock synchronization is mainly applicable to the Iub and Abis interfaces. If IP over E1 is used on the
Abis interface, the clock over IP and the IEEE1588 V2 solutions are not applicable to the Abis interface.
The following sections describe the three IP clock synchronization solutions. For details about the
parameter settings, see the IPCLK1000 product documents and the BTS product documents.
5.2 Clock over IP Solution

The clock over IP solution is based on the server/client architecture.
The clock synchronization process is as follows:
1. The IP clock server obtains the reference clock source from other devices, such as the Global
Positioning System (GPS) or Building Integrated Timing Supply System (BITS).
2. According to the Huawei proprietary standard, the IP clock server encapsulates clock
synchronization signals into IP datagrams and then transmits these datagrams to the IP clock client
through the IP network.
3. The IP clock client processes the IP datagrams to obtain the local clock that meets its clock accuracy
requirement.
The IP clock server can be Huawei IPCLK1000. The Huawei base stations provide the IP clock client
function. If a base station does not support the IP clock client function, the IPCLK1000 can be configured
as the IP clock client.
Figure 5-1 shows a typical networking of the clock over IP solution.

SingleRAN
Figure 5-1 Typical networking of the clock over IP solution
You can also deploy two IPCLK1000s in the network to improve reliability. If one IPCLK1000 is faulty or
the intermediate network is faulty, the base stations can obtain clock signals from the other IPCLK1000.
The transmission of IP datagrams requires a specific bandwidth. In addition, the clock over IP solution
has specific requirements for the delay, jitter, and packet loss rate on the intermediate network. If the
QoS of the intermediate network cannot be guaranteed, the IPCLK1000 can be deployed near the base
station (as shown in Figure 5-1, the IPCLK1000 is deployed at the same site as the router). This enables
the IPCLK1000 to provide clock signals directly for the base stations nearby, thus reducing the
dependence on the quality of the intermediate network.
The clock over IP solution adopts the server/client architecture, thus making the network deployment
flexible. One IP clock server can provide reference clock signals for hundreds of base stations.
Compared with other solutions such as GPS, the clock over IP solution saves the costs for equipment
investment and installation. The intermediate transport equipment only forwards IP timing packets, and
therefore the clock over IP solution does not require the support of intermediate transport equipment.
5.3 IEEE1588 V2 Solution

The IEEE1588 V2 solution uses the same server/client architecture as the clock over IP solution. In the
IEEE1588 V2 solution, the IPCLK1000 acts as the server, and the Huawei base station is embedded
with the synchronization client. The clock over IP solution and the IEEE1588 V2 solution differ with
respect to the clock synchronization procedure and the frame format. As for the frame format, the clock
over IP solution complies with the Huawei proprietary standard, whereas the IEEE1588 V2 solution
complies with the IEEE1588 V2 standard.
The IEEE1588 V2 standard defines frequency synchronization and time synchronization. Currently, the
NodeB and BTS implement only frequency synchronization.
Compared with the clock over IP solution, the IEEE1588 V2 solution requires a lower bandwidth on the
intermediate network, supports the interworking between devices of different manufacturers, and
enables the evolution towards time synchronization in the future.
The IEEE1588 V2 solution supports two modes: unicast and multicast. In unicast mode, clock links are
established between the clock server and each BTS; the clock server transmits clock packets to each
BTS, as shown in Figure 5-2. In multicast mode, clock links are established between the clock server
and a set of BTSs; the clock server transmits clock packets to each set of BTSs instead of a single BTS,
as shown in Figure 5-3. Therefore, transmission bandwidth in the intermediate network is saved in
multicast mode, and accordingly the CAPEX is reduced.

SingleRAN
Figure 5-2 Unicast in the IEEE1588 V2 solution
Figure 5-3 Multicast in the IEEE1588 V2 solution
5.4 Synchronous Ethernet Solution

Synchronous Ethernet is defined in ITU-T G.8262. The synchronous Ethernet solution has the same
basic principles as SDH and PDH network clock synchronization. That is, a higher-level device encodes
clock signals into serial data bit streams and a lower-level device receives the serial data bit streams
from the physical layer to extract and trace the higher-level clock.
Figure 5-4 shows the synchronous Ethernet solution. The intermediate device (for example, the Hub
NodeB of the UMTS network) that has the synchronous Ethernet function can obtain the clock source in
several ways. After obtaining the synchronous clock, the intermediate device distributes the clock signals
to other base stations.

SingleRAN
Figure 5-4 Synchronous Ethernet solution
The synchronous Ethernet solution has the following advantages:

 The clock is extracted from the physical layer and is not related to upper layer services. Therefore, the
interworking performance is satisfactory.
 The clock recovery quality is relatively good and immune to packet loss and jitter.
 The transmission of clock signals in the synchronous Ethernet solution requires a lower bandwidth in
comparison to the transmission of clock signals in the IEEE1588 V2 solution.
The synchronous Ethernet solution, however, has the following disadvantages:
 This solution does not support time synchronization.
 The 10 Mbit/s Ethernet does not support the synchronous Ethernet function.
 All the intermediate transport equipment must support the synchronous Ethernet function. Otherwise,
clock signals cannot be distributed to lower-level devices.

SingleRAN
IP Transport Architecture 6 Fault Detection Mechanisms
6 Fault Detection Mechanisms

6.1 Overview
Related to Ethernet there exists a number of mechanisms for fault detection with the basic aim to
improve the network reliability. These mechanisms appear at different layers in the Ethernet protocol
stack, as shown in Figure 6-1.
The Ethernet fault detection mechanisms are physical detection, Ethernet Operation, Administration,
and Maintenance (ETH OAM), Bidirectional Forwarding Detection (BFD), Address Resolution Protocol
(ARP), and IP Performance Monitoring (PM).
Figure 6-1 shows the fault detection mechanisms supported by different protocol layers.
Figure 6-1 Fault detection mechanisms supported by different protocol layers
6.2 ETH Operation, Administration, and Maintenance

The ETH OAM (WRFD-050425 Ethernet OAM) provides end-to-end and point-to-point Ethernet link
OAM functions. Currently, it complies with two protocols, namely, IEEE 802.1ag and IEEE 802.3ah.
As shown in Figure 6-2, the ETH OAM protocol is located between the MAC sublayer and the LLC
sublayer. The following advantages can be identified, related to ETH OAM:
 The bandwidth occupied by ETH OAM is limited. Being a low-rate protocol, the ETH OAM protocol
only has a small impact on the user data flows. Generally, EHT OAM has only a minor impact on the
capacity of links.
 By using the MAC address, the ETH OAM packets are processed only at the MAC sublayer. Thus,
other Ethernet layers are not affected.
Figure 6-2 Position of ETH OAM on the network

SingleRAN
6.2.2 Solution Based on IEEE 802.3ah

The point-to-point ETH OAM solution is based on the IEEE 802.3ah protocol. It is oriented to the user
side instead of to the network side.
Application Scenarios of IEEE 802.3ah Based Link Fault Detection

In the scenarios of link fault detection based on the IEEE 802.3ah protocol, the local end and the peer
end must be connected without any intermediate switches. This solution is mainly applicable to the
management of Ethernet links between BTSs/NodeBs, between BSC6900s, between BSC6900 and
BTS/NodeB, and between BSC6900/BTS/NodeB and transport equipment.
In this document, BTS refers to the base station of the GSM network, and NodeB refers to the base station of the UMTS
network.
Figure 6-3 Examples of application scenarios of IEEE 802.3ah based link fault detection
Data Configurations of IEEE 802.3ah Based Link Fault Detection

The network equipment connected to the BSC6900 must support the ETH OAM function based on the
IEEE 802.3ah protocol.
There must not be any intermediate equipment between the BSC6900 and the interconnected network
equipment.
To enable link monitoring and fault detection of the IEEE 802.3ah protocol based ETH OAM function,
configure the BSC6900 as follows:
 Run the ACT ETHOAMAH command to set the PDU Send Prid[ms] (PDUPrid) parameter. This
parameter specifies the fault report period based on the IEEE 802.3ah protocol.
 Run the ACT ETHOAMAH command to set the PDU Pkt Len[byte] (PDUSize) parameter. This
parameter specifies the size of an OAM PDU based on the IEEE 802.3ah protocol.

SingleRAN
 Run the ACT ETHOAMAH command to set the time window and threshold of each link according to
the IEEE 802.3ah protocol. The related parameters are as follows:
− Err Frame Event Prid (ERFAMEventPrid)
− Err Frame Event Para (ERFAMEventPara)
− Err Frame Cyc Event Prid (ERFAMPRDEventPrid)
− Err Frmae Cyc Event Para (ERFAMPRDEventPara)
− Err Frmae Sec Event Prid[s] (ERFAMSCDEventPrid)
− Err Frmae Sec Event Para[s] (ERFAMSCDEventPara)
6.2.3 Solution Based on IEEE 802.1ag

The ETH OAM function based on the IEEE 802.1ag protocol performs end-to-end detection on a per
maintenance domain (MD) basis. This facilitates the maintenance of the Ethernet connection.
Maintenance end points (MEPs) are created at both ends of an MD to define the range of the MD. In
other positions of the MD, maintenance intermediate points (MIPs) are created as required. By detecting
the MEPs and MIPs, it is possible to learn the network status and identify faults.
The management level field in the ETH OAM frame is used to implement hierarchical management. If
the level of an OAM frame is higher than the MP level, the MP transparently transmits the OAM frame. If
the level of an OAM frame is lower than the MP level, the MP directly discards the OAM frame. If the
level of an OAM frame is equal to the MP level, the MP responds according to the message type or
terminates the OAM frame.
The end-to-end ETH OAM solution is based on the IEEE 802.1ag protocol. It provides three functions:
connectivity check (CC), loopback (LB), and link tracking (LT).
The three functions are described as follows:
 CC: The IEEE 802.1ag protocol supports unidirectional CC. The source MEP sends a connectivity
check message (CCM) frame periodically. When the destination MEP receives the CCM frame, it
starts the CC function. If the destination MEP does not receive a CCM frame from the source MEP
within a specified time (3.5 times the CCM transmission interval), the destination MEP reports
CC_LOS alarms repeatedly until the link becomes normal and the destination MEP receives a CCM
frame from the source MEP.
 LB: The source MEP sends a loopback message (LBM) frame to the destination MP (that is, an MIP or
MEP). At the same time, the source MEP starts a timer. The destination MP returns a loopback reply
(LBR) frame, after reception of the LBM frame. If the source MEP does not receive the LBR frame
before the timer expires, the loopback fails. Note that only an MEP can initiate an LB test. Both an MIP
and an MEP can function as the destination end in an LB test.
 LT: The source MEP sends a link trace message (LTM) frame to the destination MEP. At the same time,
the source MEP starts a timer. When an MIP belonging to the MD receives the LTM frame, it forwards
the frame to the destination MEP and at the same time sends a link trace reply (LTR) frame to the
source MEP. After the destination MEP receives the LTM frame, it terminates the frame and sends an
LTR frame to the source MEP. If the source MEP receives the LTR frame from the destination MEP, the
LT test is successful. Run the TRC MAC command at the BSC6900 to perform a link trace test.
Application Scenarios of IEEE 802.1ag Based Link Fault Detection

The link fault detection based on the IEEE 802.1ag protocol is applicable to the scenarios where BTSs
are cascaded. The application scenarios of ETH OAM in IP transmission are shown in Figure 6-4. The
BTS/NodeB, BSC6900, and transport equipment are deployed to implement the end-to-end ETH OAM
function based on the IEEE 802.1ag protocol. All devices in the MD must support forwarding or
transparent transmission of ETH OAM PDUs.

SingleRAN
Figure 6-4 Examples of application scenarios of IEEE 802.1ag based link fault detection
Data Configurations of IEEE 802.1ag Based Link Fault Detection

The network equipment that are interconnected with the BSC6900 must support the ETH OAM function
based on the IEEE 802.1ag protocol.
Use the ACT ETHCC command to set the BSC6900 parameters related to the IEEE 802.1ag ETH OAM
function. If the interconnected equipment is a GSM BTS, you also need to use the ACT BTSETHCC
command to set the parameters of the BTS.
Figure 6-5 gives an example, where the local end and the peer end are configured in the same MD. In
the MD, two maintenance associations MA1 and MA2 are created. LPort1, LPort2, and RPort7 are
located in MA1; LPort8 and RPort1 are located in MA2. LPort1, LPort2, and LPort8 can work as the
MEPs of the local end, and RPort1, RPort2 and RPort7 can work as the MEPs of the peer end.
Figure 6-5 Example of MEP configuration
6.3 Bidirectional Forwarding Detection

Network equipment requires that the communication faults between adjacent systems be detected
quickly. If a fault occurs, a substitute link can be established quickly or the data can be switched over to
other links. Bidirectional Forwarding Detection (BFD, corresponding to feature WRFD-050421 IP Fault
Detection Based on BFD) is a means to quickly detect link faults.

SingleRAN
The BFD protocol is a type of high-speed independent Hello protocol. It is used to detect the
transmission accuracy of Ethernet, Multiprotocol Label Switching (MPLS), common routing
encapsulation, and IP Security Protocol (IPSec) tunnel. BFD can detect faults and trigger fault isolation
within tens of milliseconds, thus minimizing the service losses.
When a fault is detected, a port switchover or IP rerouting is triggered through BFD. This avoids packet
losses and call drops and thus improves the reliability of the network communication.
BFD can detect faults quickly without adding too much extra load. BFD messages can be considered
heartbeat messages. If the system transmits several BFD messages but receives no response
messages, it considers the link faulty.
Figure 6-6 shows the BFD state machine, which indicates BFD state transitions. To simplify the
illustration, the Admin Down state is excluded. In this figure, the notion in each rectangle indicates a
session state and the notion on each arc indicates the state (specified by the state field in the BFD
control message received) of the peer system or the expiry of the timer.
Figure 6-6 BFD state machine
Down indicates that the BFD session has stopped or has just started. Init indicates that the peer system
is in communication. Up indicates that the BFD session has been set up successfully.
The BFD protocol is intrinsically a handshake protocol. BFD messages are periodically transmitted
based on the negotiation result. The purpose is to detect the link connectivity. If the system does not
receive any BFD message from the peer system for a long time, it considers the link disconnected.
Figure 6-7 shows the BFD message exchange when the link is disconnected.

SingleRAN
Figure 6-7 BFD message exchange when the link is disconnected
After a BFD session is set up, the system periodically transmits BFD control messages in asynchronous
BFD mode. If the peer system receives BFD control messages within the detection time shown in Figure
6-7, it considers that the BFD session is in the UP state. Otherwise, it considers that the session is in the
DOWN state.
There are two types of BFD: single-hop BFD (SBFD) and multi-hop BFD (MBFD).
The BSC6900 supports BFD on the A, Abis, Gb, Iub, Iu, and Iur interfaces.
The parameters related to BFD are as follows:
 The Subrack No. (SRN), Slot No. (SN), and Check Index (CHKN) parameters for the interface board
uniquely specify a detection object.
 The Check type (CHKTYPE) parameter specifies the detection type. It can be set to SBFD, MBFD, or
ARP.
 The Check mode (MODE) parameter specifies whether the detection is performed on the active port,
standby port, or independent port.
 The Port No. (PN) and Peer IP address (PEERIP) parameters specify the IP address pair of a BFD
session.
 The Min interval of BFD packet send [ms] (MINTXINT) and Min interval of BFD packet receive
[ms] (MINRXINT) parameters should be set during the BFD session negotiation to negotiate a
capability with the peer end.
 The Detect multiplier of BFD packet (BFDDETECTCOUNT) parameter specifies the number of
packets that the local end does not receive from the peer end before a BFD session is declared to be
down.

SingleRAN
6.3.2 Single-Hop Bidirectional Forwarding Detection

SBFD is applicable only to the direct connection where the IP addresses of both ends are on the same
network segment. Its characteristics are as follows:
 SBFD must be started at both ends simultaneously. The detection duration of the two ends must be
similar.
 The port status is associated with the detection status. If a fault is detected, a port switchover is
triggered and the routes whose next hop is the detected address are deleted. Then, the upper layer
selects other available routes.
 Independent port detection is supported.
Currently, the BSC6900 supports only the asynchronous mode and detection of the active port; it does
not support simultaneous detection of active and standby ports.
If an SBFD session is down during SBFD, the BSC6900 automatically disables the routes whose
next-hop IP address is the peer IP address of this failed SBFD session. If SBFD is configured to be
applicable only to the active port and the Whether affect the port swapping
(WHETHERAFFECTSWAP) parameter is set to YES, an SBFD link fault triggers a port switchover.
Otherwise, an SBFD link fault does not trigger a port switchover, but the availability of the related routes
is affected.
SBFD requires that both the BSC6900 and the devices connected to the BSC6900 support the BFD
protocol.
6.3.3 Multi-Hop Bidirectional Forwarding Detection

MBFD can perform end-to-end indirect-connection link detection across several layer 3 devices. Its
characteristics are as follows:
 MBFD must be started at both ends simultaneously. The detection duration of the two ends must be
similar.
 The port status is not associated with the MBFD detection status. Instead, the status of the routes
configured for MBFD is associated with the MBFD detection status. After a fault is detected, the routes
configured for this MBFD become unavailable and the upper layer selects other available routes.
 Both the device IP address and the port IP address of the interface board can act as the local IP
address of MBFD. The peer IP address of MBFD, however, cannot be on the same network segment
as any local IP address.
Currently, the BSC6900 supports only the asynchronous mode.
If an MBFD session is down during MBFD, the BSC6900 disables the routes configured for this failed
BFD session. The status of other routes is not affected and a port switchover is not triggered. In this case,
packets are forwarded by other routes and IP rerouting is achieved.
MBFD requires the peer equipment to support the BFD protocol.
MBFD is a type of end-to-end fault detection. It is used to detect the connectivity of the link between the
source IP address and the destination IP address. For the BSC6900, the source IP address of MBFD
can be the device IP address or Ethernet port IP address of a board to be detected. The source and
destination IP addresses can also be the IP addresses of other network devices to be detected.
The ADD IPRTBIND/ADD IPPATHBIND commands can be used to specify the binding relation between
MBFD and a certain IP route or IP path. Once the binding relation is specified, the IP route or IP path
configured for the MBFD is found unavailable if MBFD detects a fault.

SingleRAN
6.4 Address Resolution Protocol Detection

The working principle of Address Resolution Protocol (ARP) detection is similar to that of SBFD
detection. ARP detection uses the ARP mechanism, where the local end sends an ARP request to the
peer end and determines the connectivity of the link according to the ARP response from the peer end.
The BSC6900 sends an ARP request to the network periodically. The destination of the request is the
peer address to be detected. The BSC6900 determines the connectivity of the link based on whether it
receives an ARP response from the destination. If the BSC6900 receives an ARP response from the
destination, it considers the link normal. If the BSC6900 does not receive any ARP response from the
destination for certain consecutive periods, it considers the link faulty.
ARP detection is applicable only to the direct connection where the IP addresses of both ends are on the
same network segment. ARP detection can be used as an alternative when the peer equipment does not
support BFD detection. If BFD detection is supported, however, it is preferentially to be used as it uses a
fast bidirectional detection mechanism.
ARP messages are broadcast messages. If the BSC6900 and the layer 3 devices are directly connected, broadcast
storms will not occur. If the BSC6900 and the layer 3 devices are not directly connected, broadcast storms are likely to
occur.
The characteristics of ARP detection are as follows:

 ARP detection is independent of the peer equipment. The detection can be started by a single end.
 The port status is associated with the detection status. If a fault is detected, a port switchover is
triggered and the routes whose next hop is the detected address are deleted. Then, the upper layer
selects other available routes.
 Independent port detection is supported. In board backup mode, detection of active port and
simultaneous detection of active and standby ports are supported.
 When the active and standby ports are detected simultaneously, the IP addresses of the ports cannot
be on the same network segment.
The differences between ARP detection and BFD detection are as follows:
 ARP detection needs a longer time to detect a fault than BFD detection.
 BFD detection requires support from both ends of the link whereas ARP detection does not.
 When a link is found faulty through ARP detection, the corresponding routes are triggered to be
unavailable. In this case, a port switchover can also be triggered through parameter configurations.
This is similar to SBFD detection.
ARP detection and SBFD detection are used for the following purposes:
 To detect the connectivity of the link between the BSC6900 and the gateway under the existence of
routers
 To detect the connectivity of the link between the BSC6900 and the peer equipment (generally referred
to as CN equipment) when the BSC6900 and the peer equipment are directly connected
With respect to parameter configurations, the ARP packet time-out[100ms] (ARPTIMEOUT) and ARP
packet resend times (ARPRETRY) parameters should be configured for ARP detection. ARP packet
time-out[100ms] (ARPTIMEOUT) specifies the interval for the BSC6900 to send an ARP detection
packet. ARP packet resend times (ARPRETRY) specifies the number of consecutive response packets
that are not received by the BSC6900 before the ARP link is declared to be faulty.
The BSC6900 supports ARP detection on the A, Abis, Gb, Iub, Iu, and Iur interfaces.
The parameters related to ARP detection are as follows:

SingleRAN
 Peer IP address (PEERIP) : This parameter specifies the destination IP address for BFD or ARP
detection.
 Backup port IP address (BAKIP): This parameter specifies the IP address of the standby Ethernet
port. The standby Ethernet port can be used to detect faults at the physical layer and to start ARP
detection to detect faults at higher layers. In the case of ARP detection, the IP address of the standby
port should be on different network segments from that of the active port.
 Backup port mask (BAKMASK): This parameter specifies the subnet mask of the standby port where
ARP detection is enabled.
 Check type (CHKTYPE) : This parameter specifies the detection type. It can be set to SBFD, MBFD,
or ARP. The VRRP does not support BFD detection. Therefore, in VRRP topology, ARP detection is
recommended.
 Check mode (MODE): This parameter specifies the detection mode. If this parameter is set to
PRIMARY, it indicates that detection is performed on the active port. If this parameter is set to
STANDBY, it indicates that detection is performed on the standby port. If this parameter is set to
INDEPENDENT, it indicates that detection is performed on the independent port.
6.4.1 Binding Between SBFD/ARP and IPRT

When SBFD/ARP detection is performed, each SBFD/ARP detection task must be bound with an IPRT
(IP route).
For each pair of source and destination IP addresses, only one SBFD/ARP detection task can be started.
In this case, the source IP address must be the port IP address, and the destination IP address must be
on the same network segment as the source IP address.
If detection is started at an independent port or an active port, the route whose next hop is the
destination IP address is automatically selected as the detected route. SBFD/ARP detection started at
the active port is classified into key detection and common detection. If key detection detects a fault in
the active port and does not detect a fault in the standby port, a port switchover is triggered. Common
detection does not trigger a switchover.
 If a fault is found through the detection started at the independent port, you can infer that the routes
configured for the detection are faulty.
 If a fault is found through the detection started at the active port and a port switchover is not triggered,
you can infer that the routes configured for the detection are faulty. If a fault is detected and a port
switchover is triggered, the route is switched to the standby port.
6.4.2 Application of SBFD/ARP in VRRP Topology

In the case of VRRP, a master router is selected from routers according to specified criteria. The master
router forwards data packets and uses its virtual MAC address as the SBFD/ARP source address for the
host to respond. Other routers function as backups. The master router communicates with backup
routers by sending VRRP multicast packets periodically, so that the backup routers know the status of
the master router in real time. Normally, backup routers do not forward the data packets that are destined
for the virtual MAC address. If the master router fails and the backup router does not receive VRRP
messages within a specified time interval, the backup takes over the services handled by the master. In
this manner, the continuity and reliability of communications are maintained.
Figure 6-8 shows the VRRP topology.

SingleRAN
Figure 6-8 VRRP topology
In this topology, the BSC6900 uses VRRP IP2 (virtual IP address) as the next-hop IP address for
communication. Note that VRRP IP2 cannot be used as the source or destination IP address for SBFD
detection because of the existence of routers.
In this case, only key ARP detection can be used to detect the connectivity of the link between IP1 and
VRRP IP2. In addition, common SBFD detection can be used to detect the connectivity of the
communication link, with IP1 (port IP address) used as the source IP address and IP3/IP4 (port IP
address of the router) used as the destination IP address. At the same time, the router starts to detect
the BSC6900. Thus, the router can perform a VRRP switchover in case of link faults. Furthermore, the
BSC6900 knows whether VRRP IP2 is faulty and then determines whether to switch over the port that is
connected to the router.
6.5 IP Performance Monitoring

IP performance monitoring (IP PM) is a method of detecting the QoS of the IP transport network. The
QoS detection of the IP transport network provides a basis for flow control and admission control after
the introduction of IP transport. The IP PM function effectively monitors the transport network by
detecting the QoS of the intermediate transport network in a fast and timely manner.
IP PM uses forward monitoring (FM) and backward reporting (BR) mechanisms to detect delay, jitter,
and packet loss. Figure 6-9 shows the principle of IP PM.
Figure 6-9 Principle of IP PM
FM
A B
BR
PM initiator PM responsor
The principle of IP PM is as follows:

 End A (for example, the BSC6900) periodically sends end B (for example, the BTS/NodeB) an FM
message, indicating the number of packets transmitted by end A.

SingleRAN
 After receiving the FM message, end B responds to end A with a BR message, indicating the number
of received packets.
 End A collects statistics on delay, jitter, and packet loss rate related to the reception of the BR
message.
IP PM enables the measurement of QoS indexes, such as delay, jitter, and packet loss rate of a certain
IP link between the BSC6900 and the BTS/NodeB. IP PM uses a Huawei proprietary protocol and
requires support from both the BSC6900 and the BTS/NodeB.
IP PM is performed on a per IP path basis. The Adjacent Node ID (ANI) and IP path ID (PATHID)
parameters specify the IP path where IP PM is to be performed.

SingleRAN
IP Transport Architecture 7 Network Reliability
7 Network Reliability
7.1 Overview
To ensure reliability in IP networks and provide reliable end-to-end data communications, the BSC6900
implements the following reliability mechanisms:
 Board backup
 Ethernet port backup
 Ethernet port load sharing
 Route-based port backup and load sharing
 Ethernet link aggregation
Different networking reliability mechanisms are applicable to IP interface ports of different types, as
described in Table 7-1. Appendix 12 describes the reliability mechanisms supported by different interface
boards.
Table 7-1 Reliability mechanisms supported by different interface boards
Port Reliability Mechanism Supported
FE/GE ports Board backup
Ethernet port backup
Ethernet port load sharing
Ethernet link aggregation
Route-based port backup and load sharing
E1/T1/Ch-STM-1 ports Board backup
The following sections describe the network reliability mechanisms.
For details about board backup, Ethernet port backup, and Ethernet port load sharing, see the BSC6900 Technical
Description.
7.2 Board Backup

Board backup is applicable to all IP interface boards. When adding a board, configure board backup by
setting the Backup (RED) parameter to YES.
In IP over FE/GE or IP over PPP over E1/T1 transmission mode, all the IP interface boards of the
BSC6900 can work in active/standby mode. Below is an example for board backup described, related to
IP over PPP over E1/T1 transmission.
The E1/T1 ports of the active and standby boards are connected through Y-shaped cables. Only the
E1/T1 port of the active board transmits and receives IP packets; the E1/T1 port of the standby board is
used only for link detection. The standby board does not process services but saves the PPP link status,
negotiation session information, and some user data of the active board. In this case, renegotiation is not
required during an active/standby switchover, thus avoiding service disruption. When the active board
becomes faulty but the standby board is in normal operation, a switchover is performed between the
active and standby boards.

SingleRAN
When multiple E1/T1 links are configured between the BSC6900 and the interconnected network element (NE), these
E1/T1 links are generally bound together to form an MLPPP link to achieve high reliability and efficiency. In this case, the
failure of a single E1 link only causes the reduction of transmission bandwidth, without disrupting the services.
Figure 7-1 shows the networking for board backup in an IP over PPP over E1/T1 situation.
Figure 7-1 Networking for board backup in an IP over PPP over E1/T1 situation
In an IP over PPP over Ch-STM-1 situation, the interface boards of the BSC6900 can work in
active/standby mode in a similar way as described previously. The active and standby boards connect to
the optical transport equipment at the peer end through optical cables. When the working channel
becomes faulty, the BSC6900 negotiates with the optical transport equipment on the protection channel
according to the MSP protocol to switch the services to the protection channel. In this manner, MSP
switching is implemented.
7.3 Ethernet Port Backup

Ethernet port backup is based on the board backup mechanism. The Ethernet ports on the active and
standby boards are configured to work in active/standby mode.
In Ethernet port backup mode, the active port transmits and receives data and processes services; the
standby port does not process services and it is used only for link detection. Ethernet port backup is
independent of the board backup mechanism, that is, the active port can be on the active board or on the
standby board.
Link detection is performed between the active/standby port and the interconnected equipment by using
ARP, BFD, or physical layer detection. For details about fault detection, see Section 6 "Fault Detection
Mechanisms." When the active link is found faulty but the standby link is in normal operation, or when
the active port is found faulty but the standby port is in normal operation, a switchover is performed
between the active and standby ports.
To configure the Ethernet port backup of the BSC6900, start to configure board backup (for details about
how to configure board backup, see section 7.2 "Board Backup"); secondly, enter the ADD
ETHREDPORT command and set the parameters Subrack No. (SRN), Slot No. (SN), and Port No.
(PN) to specify the active and standby Ethernet ports.
Figure 7-2 shows the networking for Ethernet port backup. In this case, data configuration is not required
for the standby port. After an active/standby port switchover has been performed, the original standby
port automatically uses the data configuration of the original active port.

SingleRAN
Figure 7-2 Networking for Ethernet port backup
VLAN
Active
port
V
BSC6900 IP 1-0 R
IP 1-1 LAG IP network
R
P
Standby
port
PE
In this situation, the active and standby FE/GE ports of the BSC6900 are connected to the two Provider
Edges (PEs), which connect to the IP network. The two PEs provide redundancy protection on the data
transmitted between the BSC6900 and the PEs by using the Virtual Router Redundancy Protocol
(VRRP). One PE connects to the other through two GE ports. The links between the PEs adopt the link
aggregation group (LAG) to increase link bandwidth and improve link stability. The active and standby
FE/GE ports of the BSC6900 share one IP address, represented by IP1-0. On the PE side, the active
and standby FE/GE ports of the BSC6900 are configured on the same VLAN and use the same VRRP IP
address, represented by IP1-1.
 If the distance between the BSC6900 and the PEs is greater than or equal to 100 m, it is recommended that the GE
optical ports of the GOUa boards be used to connect the BSC6900 to the PEs.
 If the distance between the BSC6900 and the PEs is less than 100 m, it is recommended that the FE/GE electrical ports
of the FG2a boards be used to connect the BSC6900 to the PEs.
7.4 Ethernet Port Load Sharing

When using the Ethernet port backup mechanism, only one port works and thus the port utilization is low.
To improve the port utilization, Ethernet port load sharing can be used. In load sharing mode, two ports
work simultaneously and both can receive and transmit packets. Service data is shared between the
ports. This reduces the risk that one port is busy but the other port is idle, thus improving transmission
efficiency. This operation mode, however, does not provide redundancy protection for data transmission.
So, if one port fails, the transmission bandwidth will decrease.
Ethernet port load sharing is based on the board backup mechanism. Use the ADD IPRT command to
add the corresponding IP route.
In Ethernet port load sharing mode, service data is transmitted through two ports. When either of the
ports or links is faulty, all service data is transmitted and received through the other port, and therefore
the services are still processed normally. In load sharing mode, a port failure will not result in a port
switchover.
Figure 7-3 shows the networking for Ethernet port load sharing.

SingleRAN
Figure 7-3 Networking for Ethernet port load sharing
The two FE/GE ports on the active and standby boards use different IP addresses IP1-0 and IP2-0,
which are on different network segments. The PE is configured with two IP addresses corresponding to
IP1-0 and IP2-0, namely, IP1-1 and IP2-1. Two routes from IP1-0 and IP2-0 respectively to the
destination IP address are configured; the next hops of the two routes are IP1-1 and IP2-1 respectively;
the two routes are configured with the same Priority (PRIORITY). In this manner, the two ports work in
load sharing mode, and the data from the BSC6900 to the destination IP address is transmitted over the
two routes in load sharing mode.
 The two ports of the BSC6900 working in load sharing mode can be connected to one PE or two PEs.
 If the distance between the BSC6900 and the PEs is greater than or equal to 100 m, it is recommended that the GE
optical ports of the GOUa boards be used to connect the BSC6900 to the PEs.
 If the distance between the BSC6900 and the PEs is less than 100 m, it is recommended that the FE/GE electrical ports
of the FG2a boards be used to connect the BSC6900 to the PEs.
7.5 Route-Based Port Backup and Load Sharing

Intra-board route-based port backup is implemented by configuring multiple routes to the same
destination IP address. The priorities of the routes vary, depending on the next-hop IP address.
Intra-board route-based load sharing is implemented by configuring multiple routes to the same
destination IP address. The priorities of the routes are the same, but the next-hop IP addresses are
different.
Route-based port backup and route-based load sharing require the interface board to work in
independent mode. Use the ADD IPRT command to add the corresponding IP routes. For details about
the route configuration, see section 7.4 "Ethernet Port Load Sharing."
7.6 Ethernet Link Aggregation

In compliance with the IEEE 802.3ad protocol, link aggregation (MRFD-210103 Link aggregation)
enables multiple physical links to be bound to form a logical link. That is, multiple links are aggregated to
form a link aggregation group (LAG), which can be considered as an independent link in an upper-layer
application perspective.
Ethernet link aggregation increases transmission bandwidth and improves reliability and enables user
data to be transmitted over multiple links. When an Ethernet port in a link aggregation group becomes
faulty, services are not disrupted.
7.6.1 Prerequesites for Link Aggregation

If the BSC6900 is configured with a link aggregation group, the interconnected peer equipment must
also support link aggregation and there must not be any intermediate equipment between the
interconnected equipment and the BSC6900.

SingleRAN
When the BSC6900 is configured with a link aggregation group, the links in the link aggregation group
must have the same attributes.
For the BSC6900, both the links of the active and standby boards and the links within one board can be
aggregated. It is recommended that the board backup mechanism be used to implement the link
aggregation function.
Currently, the BTS does not support link aggregation. Therefore, link aggregation cannot be implemented over the Abis
interface.
7.6.2 Basic Principles of Link Aggregation

Based on the IEEE 802.3ad protocol, the Link Aggregation Control Protocol (LACP) provides a method
to dynamically aggregate or deaggregate links. The local end exchanges information with the peer end
by sending Link Aggregation Control Protocol Data Units (LACPDUs).
LACP is located at the link aggregation sublayer, which belongs to the data link layer. As shown in Figure
7-4, the link aggregation sublayer is an optional sublayer between the MAC client sublayer and the MAC
sublayer.
Figure 7-4 Position of the link aggregation sublayer in the TCP/IP reference model
In the LACP protocol, the two ends of a link are called Actor and Partner respectively. By exchanging
LACPDUs, the two end points notify each other of the information about the system priority, system MAC
address, port priority, port number, and operation key. After receiving the information, the peer end
compares it with the stored information related to other ports to choose an aggregation port. The two end
points negotiate with each other about which links can be bound to form an aggregation group and about
when a link can be put into the group.
The BSC6900 supports manual aggregation and static aggregation.
 Manual aggregation
In manual aggregation mode, the system is not allowed to automatically add or delete a port from an
aggregation group. An aggregation group must contain at least one port. If an aggregation group
contains only one port, the port can be removed from the aggregation group only by deleting the
aggregation group.
In manual aggregation mode, the LACP protocol is not enabled for the ports; only the local end
determines the ports to be aggregated.
 Static aggregation
In static aggregation mode, the system is not allowed to automatically add or delete a port from an
aggregation group. The system automatically enables the LACP protocol for the ports in a static
aggregation group.

SingleRAN
When a static aggregation group is deleted, the ports in the group form one or more dynamic LACP
aggregations, and the LACP protocol remains enabled. Users are not allowed to disable the LACP
protocol for the ports in a static aggregation group.
Compared with manual aggregation, static aggregation has the following characteristics: The ports in
a static aggregation group are aggregated according to the manual configuration data and
communicate with each other according to the LACP protocol to determine whether the manually
aggregated ports can be aggregated.
The attributes of all the ports in an aggregation group must be the same in both manual aggregation and
static aggregation.
Multiple ports negotiate with each other according to the LACP protocol to form a logical port and share
the same IP address. This IP address also acts as the IP address of the link aggregation group and is
specified by the Local IP address (IPADDR) parameter.
The aggregation mode is specified by the Aggregation Mode (LACPMODE) parameter.
To enable the aggregation group function, configure the BSC6900 as follows:
 Run the ADD ETHTRK command to add a link aggregation group and set the Trunk No. (TRKN)
parameter.
 Run the ADD ETHTRKLNK command to add a link to the aggregation group and set the Trunk Link
No. (TRKLNKPN) parameter.
 Run the ADD ETHTRKIP command to configure the IP address for the link aggregation group.
 Run the SET ETHPORT command to configure the attributes of the ports in the link aggregation
group.
7.6.3 Application of Link Aggregation

When the BSC6900 is interconnected to the Optical Switch Node (OSN), link aggregation can be
performed on the FE/GE ports to increase transmission bandwidth and improve reliability. The BSC6900
supports link aggregation on the FE/GE ports of the active and standby boards. After the links are
aggregated, the corresponding FE/GE ports share a Virtual MAC (VMAC) and an IP address. Figure 7-5
illustrates link aggregation using GE ports.
Figure 7-5 Link aggregation performed on the GE ports

SingleRAN
To use the link aggregation group for transmission, both the BSC6900 and the interconnected equipment
must support the link aggregation function.
The links in the link aggregation group can work properly only after the aggregation group is successfully
negotiated.

SingleRAN
IP Transport Architecture 8 IP DHCP
8 IP DHCP
8.1 Dynamic Host Configuration Protocol
The Dynamic Host Configuration Protocol (DHCP) dynamically provides the terminal with configuration
information such as the IP address. DHCP can allocate IP addresses automatically and establish OM
channels for IP RAN and IP BSS. The BSC6900 allocates the planned IP address and port number to
the BTS/NodeB automatically by using the DHCP mechanism and reports the information related to the
BSC6900 to the BTS/NodeB through DHCP information exchange. This substitutes local configuration
operation and thus facilitates fast network deployment.
The DHCP has the following characteristics:
 Works in client/server mode. When receiving a request from the client, the server responds with
information such as the IP address, gateway address, and DNS server address.
 Simplifies IP address management.
 Provides centralized IP address management.
 Complies with RFC2131 and RFC2132.
The DHCP procedure has a DHCP server and a DHCP client, as shown in Figure 8-1. In the following
example, the BSC6900 functions as the DHCP server, and the BTS/NodeB functions as the DHCP client.
The BTS/NodeB can obtain the IP address dynamically.
Figure 8-1 DHCP procedure
DHCP DISCOVER
DHCP OFFER
DHCP DHCP
server DHCP REQUEST client
DHCP ACK
The DHCP procedure is described as follows:

Step 1 The BTS/NodeB sends a DHCP DISCOVER message to the BSC6900.
Step 2 The BSC6900 sends configuration information such as the IP address to the BTS/NodeB
through DHCP OFFER messages.
Step 3 The BTS/NodeB selects an IP address from the received DHCP OFFER messages and
responds with a DHCP REQUEST message.
Step 4 The BSC6900 sends a DHCP ACK message to the BTS/NodeB.
----End
8.2 VLAN Detection

The VLAN detection procedure is as follows:
When a base station starts to operate, it does not have the current VLAN information. Therefore,
messages cannot traverse the layer 2 network in the DHCP phase and the base station cannot obtain
the IP address. Thus, the base station cannot operate normally.

SingleRAN
IP Transport Architecture 8 IP DHCP
In this situation, the BSC6900 or the intermediate transport equipment must send the base station an
ARP message that carries correct VLAN information. After receiving the ARP message, the base station
records the VLAN ID and includes it in the DHCP message. Then, it sends the DHCP message (DHCP
DISCOVER) to the DHCP server through the layer 2 network. The DHCP server returns a response
message. In this manner, the base station obtains the correct IP address and establishes a signaling link
to the BSC6900.
To implement VLAN detection on the BSC6900 side, the mapping between the IP address and the VLAN
must be configured first.
 In layer 2 networking, this IP address is the communication IP address of the base station, and the
VLAN ID must be supported by the layer 2 network.
 In layer 3 networking, this IP address is the next-hop IP address of the port IP address of the BSC6900,
and the VLAN ID (identifies the VLAN between the BTS/NodeB and the layer 3 devices) must be
supported by the layer 2 devices.
For UMTS, the STR NODEBDETECT command is used to enable the VLAN detection function so that
the detection based on a single NodeB and on multiple NodeBs is supported. The BSC6900 periodically
sends the VLAN ID to the NodeBs. Therefore, when a NodeB is added or a faulty NodeB is restored, the
NodeB can automatically obtain its VLAN ID from the BSC6900.
For GSM, the BTS Detect Switch (BTSDETECTSWITCH) parameter can be set to OPEN to enable the
VLAN detection function.

SingleRAN
IP Transport Architecture 9 Parameters
9 Parameters
Table 9-1 Parameter description
Parameter ID NE MML Description
PTYPE BSC6900 SET ETHPORT(Mandatory) Meaning: Ethernet port type
GUI Value Range: FE, GE
Actual Value Range: FE, GE
Unit: None
Default Value: None
AUTO BSC6900 SET ETHPORT(Optional) Meaning: Whether the self-negotiation mode is
adopted
1. When the FG2 board is used and the port type
is GE, the self-negotiation mode must be
adopted.
2. If the self-negotiation mode is adopted, the FE
port rate, working mode and flow control mode
must be in accordance with the negotiation
result. If the self-negotiation mode is not adopted,
the FE port rate, working mode and flow control
mode must be specified. Make sure that the
specified attributes are the same as that of the
peer. Otherwise, transmission failure must be
incurred.
3. If the self-negotiation mode is adopted on the
local system, the peer must use the
self-negotiation mode.
GUI Value Range: ENABLE, DISABLE

Actual Value Range: ENABLE, DISABLE
Unit: None
Default Value: None
MTU BSC6900 SET ETHPORT(Optional) Meaning: Maximum transmission unit
GUI Value Range: 256~1650

Actual Value Range: 256~1650
Unit: byte
Default Value: None
VLANID BSC6900 ADD IPPATH(Mandatory) Meaning: VLANID of the IP address of the
MOD IPPATH(Mandatory) specified next hop
Unit: None
Default Value: None
VLANID BSC6900 ADD VLANID(Mandatory) Meaning: VLANID of the IP address of the
specified next hop
Unit: None
Default Value: None

SingleRAN

IPADDR BSC6900 ADD Meaning: Local IP address of the aggregation
ETHTRKIP(Mandatory) group.
MOD ETHTRKIP(Optional) GUI Value Range: None
Actual Value Range: 0.0.0.0~255.255.255.255
Unit: None
Default Value: None
IPADDR BSC6900 ADD IPPATH(Mandatory) Meaning: The local IP address must be the
configured IP address (including the IP address
and port address of the interface board).
GUI Value Range: None
Unit: None
Default Value: None
IPADDR BSC6900 ADD VLANID(Mandatory) Meaning: IP address of the next hop
RMV VLANID(Mandatory) GUI Value Range: None
Unit: None
Default Value: None
SCTPLNKN BSC6900 ADD M3LNK(Mandatory) Meaning: SCTP link number of XPU board. This
number identifies an SCTP link uniquely.
Unit: None
Default Value: None
SCTPLNKN BSC6900 ADD SCTPLNK(Mandatory) Meaning: SCTP link number of XPU board. This
MOD number identifies an SCTP link uniquely.
SCTPLNK(Mandatory) GUI Value Range: 0~1199
RMV SCTPLNK(Mandatory) Actual Value Range: 0~1199
Unit: None
Default Value: None
DS1 BSC6900 ADD MPLNK(Optional) Meaning: Number of the E1T1 port for bearing
MOD MPLNK(Optional) the PPP link
Actual Value Range: 0~31(PEUa), 0~125(E1 of
POUa), 0~167(T1 of POUa), 0~251(E1 of
POUc), 0~335(T1 of POUc)
Unit: None
Default Value: None
DS1 BSC6900 ADD PPPLNK(Optional) Meaning: Number of the E1T1 port for bearing
MOD PPPLNK(Optional) the PPP link
Unit: None
Default Value: None

SingleRAN

TSBITMAP BSC6900 ADD MPLNK(Mandatory) Meaning: Bearer E1/T1 port timeslot of MP link.
MOD MPLNK(Optional) GUI Value Range: TS1, TS2, TS3, TS4, TS5,
TS6, TS7, TS8, TS9, TS10, TS11, TS12, TS13,
TS14, TS15, TS16, TS17, TS18, TS19, TS20,
TS21, TS22, TS23, TS24, TS25, TS26, TS27,
TS28, TS29, TS30, TS31
Actual Value Range: TS1, TS2, TS3, TS4, TS5,
TS14, TS15, TS16, TS17, TS18, TS19, TS20,
TS21, TS22, TS23, TS24, TS25, TS26, TS27,
TS28, TS29, TS30, TS31
Unit: None
Default Value: None
TSBITMAP BSC6900 ADD PPPLNK(Mandatory) Meaning: Bearer E1/T1 port timeslot of PPP link.
MOD PPPLNK(Optional) GUI Value Range: TS1, TS2, TS3, TS4, TS5,
TS14, TS15, TS16, TS17, TS18, TS19, TS20,
TS21, TS22, TS23, TS24, TS25, TS26, TS27,
TS28, TS29, TS30, TS31
Actual Value Range: TS1, TS2, TS3, TS4, TS5,
TS14, TS15, TS16, TS17, TS18, TS19, TS20,
TS21, TS22, TS23, TS24, TS25, TS26, TS27,
TS28, TS29, TS30, TS31
Unit: None
Default Value: None
PPPLNKN BSC6900 ADD MPLNK(Optional) Meaning: PPP link number
MOD MPLNK(Mandatory) GUI Value Range: 0~499
RMV MPLNK(Mandatory) Actual Value Range: 0~499
Unit: None
Default Value: None
PPPLNKN BSC6900 ADD PPPLNK(Optional) Meaning: PPP link number of BSC.
MOD PPPLNK(Optional) GUI Value Range: 0~499
RMV PPPLNK(Mandatory) Actual Value Range: 0~499
Unit: None
Default Value: None
LOCALIP BSC6900 ADD MPGRP(Mandatory) Meaning: Local IP address of the MP group
MOD MPGRP(Mandatory) GUI Value Range: None
Unit: None
Default Value: None
LOCALIP BSC6900 ADD PPPLNK(Mandatory) Meaning: Local IP address of PPP link.

MOD PPPLNK(Mandatory) GUI Value Range: None
Unit: None
Default Value: None

SingleRAN

PEERIP BSC6900 ADD MPGRP(Mandatory) Meaning: Peer IP address of the MP group.
MOD MPGRP(Optional) GUI Value Range: None
Unit: None
Default Value: None
PEERIP BSC6900 ADD PPPLNK(Mandatory) Meaning: Peer IP address of PPP link

MOD PPPLNK(Optional) GUI Value Range: None
Unit: None
Default Value: None
MASK BSC6900 ADD DEVIP(Mandatory) Meaning: Subnet mask of the board

Unit: None
Default Value: None
MASK BSC6900 ADD ETHIP(Mandatory) Meaning: Subnet mask of the board
Unit: None
Default Value: None
MASK BSC6900 MOD ETHIP(Optional) Meaning: Subnet mask of the ether port
Unit: None
Default Value: None
MASK BSC6900 ADD Meaning: Subnet mask
ETHTRKIP(Mandatory) GUI Value Range: None
MOD ETHTRKIP(Optional) Actual Value Range: 0.0.0.0~255.255.255.255
Unit: None
Default Value: None
MASK BSC6900 ADD MPGRP(Mandatory) Meaning: Subnet mask of the MP group in BSC.
MOD MPGRP(Optional) GUI Value Range: None
Unit: None
Default Value: None
MASK BSC6900 ADD PPPLNK(Mandatory) Meaning: Subnet mask of the PPP link
MOD PPPLNK(Optional) GUI Value Range: None
Unit: None
Default Value: None

SingleRAN

BORROWDEVIP BSC6900 ADD MPGRP(Mandatory) Meaning: Whether to use the device IP address
MOD MPGRP(Optional) as the local IP address. If this parameter is set
to YES, the device IP address is used as the
local IP address. If this parameter is set to NO,
the device IP address is not used as the local IP
address.
GUI Value Range: NO(NO), YES(YES)
Actual Value Range: NO, YES
Unit: None
Default Value: None
BORROWDEVIP BSC6900 ADD PPPLNK(Mandatory) Meaning: Whether to use the device IP address
MOD PPPLNK(Optional) as the local IP address. If this parameter is set
to YES, the device IP address is used as the
local IP address. If this parameter is set to NO,
the device IP address is not used as the local IP
address.
GUI Value Range: NO(NO), YES(YES)
Actual Value Range: NO, YES
Unit: None
Default Value: None
DEVIP BSC6900 ADD MPGRP(Mandatory) Meaning: Borrowed device IP address.
MOD MPGRP(Mandatory) GUI Value Range: None
Unit: None
Default Value: None
DEVIP BSC6900 ADD PPPLNK(Mandatory) Meaning: Borrowed device IP address.

MOD PPPLNK(Mandatory) GUI Value Range: None
Unit: None
Default Value: None
FCSTYPE BSC6900 ADD MPLNK(Optional) Meaning: CRC verification mode of MP link.

MOD MPLNK(Optional) GUI Value Range: None(None), 16bit(16bit),
32bit(32bit)
Actual Value Range: None, 16bit, 32bit
Unit: None
Default Value: 16bit
FCSTYPE BSC6900 ADD PPPLNK(Optional) Meaning: CRC verification mode of PPP link.
MOD PPPLNK(Optional) GUI Value Range: None(None), 16bit(16bit),
32bit(32bit)
Actual Value Range: None, 16bit, 32bit
Unit: None
Default Value: 16bit

SingleRAN

PPPMUX BSC6900 ADD MPGRP(Optional) Meaning: Whether to enable the PPP frame
MOD MPGRP(Optional) multiplexing function. If this parameter is set to
ENABLE, the PPP frame multiplexing function is
enabled. If this parameter is set to DISABLE, the
PPP frame multiplexing function is disabled.
GUI Value Range: Disable(Disable),
Enable(Enable)
Actual Value Range: Disable, Enable
Unit: None
Default Value: Disable
PPPMUX BSC6900 ADD PPPLNK(Optional) Meaning: Whether to enable the PPP frame
multiplexing function. If this parameter is set to
Enable(Enable)
Unit: None
Default Value: Disable
PPPMUX BSC6900 MOD PPPLNK(Optional) Meaning: Whether to enable the PPP frame
multiplexing function. If this parameter is set to
Enable(Enable)
Unit: None
Default Value: Enable
MAXSFLEN BSC6900 ADD MPGRP(Optional) Meaning: Maximum length of the PPP
multiplexing frame
Unit: None
Default Value: None
MAXSFLEN BSC6900 MOD MPGRP(Optional) Meaning: Maximum PPPMUX sub-frame length.
If the PPP frame length is larger than this value,
the PPPMUX multiplexing is performed. The
value of this parameter cannot be larger than the
maximum multiplexed frame length wMuxMfl. To
enable the PPPMUX, the number of sub-frames
must be more than or equal to 2. The following
condition must be met:
wMuxMaxSfL<=( wMuxMfl-8 )/2
Unit: byte
Default Value: 64

SingleRAN

MAXSFLEN BSC6900 ADD PPPLNK(Optional) Meaning: Maximum PPPMUX sub-frame length.
MOD PPPLNK(Optional) If the PPP frame length is larger than this value,
the PPPMUX multiplexing is performed. The
value of this parameter cannot be larger than the
maximum multiplexed frame length wMuxMfl. To
enable the PPPMUX, the number of sub-frames
must be more than or equal to 2. The following
condition must be met: wMuxMaxSfL <=
( wMuxMfl-8 )/2
Unit: byte
Default Value: 64
MAXMFLEN BSC6900 ADD MPGRP(Optional) Meaning: Maximum length of the PPP
multiplexing frame
Unit: None
Default Value: None
MAXMFLEN BSC6900 MOD MPGRP(Optional) Meaning: The value of this parameter cannot be
less than the maximum PPPMUX sub-frame
length (MUXMAXSFL). This parameter can be
associated with the maximum segment length of
the MP to control whether to segment the
multiplexed MP. To enable the PPPMUX, the
number of sub-frames must be more than or
equal to 2. The following condition must be met:
wMuxMaxSfL <= ( wMuxMfl-8 )/2
Unit: byte
Default Value: 256
MAXMFLEN BSC6900 ADD PPPLNK(Optional) Meaning: The value of this parameter cannot be
MOD PPPLNK(Optional) less than the maximum PPPMUX sub-frame
length (MUXMAXSFL). This parameter can be
associated with the maximum segment length of
the MP to control whether to segment the
multiplexed MP. To enable the PPPMUX, the
number of sub-frames must be more than or
equal to 2. The following condition must be met:
wMuxMaxSfL <= ( wMuxMfl-8 )/2.
Unit: byte
Default Value: 256

SingleRAN

MUXTIME BSC6900 ADD MPGRP(Optional) Meaning: Frame timeout duration of the PPP
multiplexing group
Unit: ls
Default Value: None
MUXTIME BSC6900 MOD MPGRP(Optional) Meaning: Maximum time waiting for multiplexing
Unit: ls
Default Value: 1000
MUXTIME BSC6900 ADD PPPLNK(Optional) Meaning: Maximum time waiting for multiplexing
Unit: ls
Default Value: 1000
MUXTIME BSC6900 MOD PPPLNK(Optional) Meaning: Maximum time waiting for multiplexing
Unit: ls
Default Value: 1000
MPGRPN BSC6900 ADD MPGRP(Mandatory) Meaning: MP group number
MOD MPGRP(Mandatory) GUI Value Range: 0~167
RMV MPGRP(Mandatory) Actual Value Range: 0~31(PEUa), 0~63(POUa),
0~167(POUc)
Unit: None
Default Value: None
MPGRPN BSC6900 ADD MPLNK(Mandatory) Meaning: MP group number
Actual Value Range: 0~31(PEUa), 0~63(POUa),
0~167(POUc)
Unit: None
Default Value: None
MPTYPE BSC6900 ADD MPGRP(Optional) Meaning: MP type
MOD MPGRP(Optional) GUI Value Range: MLPPP, MCPPP
Actual Value Range: MLPPP, MCPPP
Unit: None
Default Value: MCPPP
FRAGSIZE BSC6900 ADD MPGRP(Optional) Meaning: MP segment size,the length of packet

MOD MPGRP(Optional) should be bigger or equel with it.
Unit: byte
Default Value: 256

SingleRAN

MCCLASS BSC6900 ADD MPGRP(Optional) Meaning: Number of MC priorities. This
parameter is valid when the MP group type is
MC.
GUI Value Range: 4,8
Actual Value Range: 4, 8
Unit: None
Default Value: None
MCCLASS BSC6900 MOD MPGRP(Optional) Meaning: Number of MC priorities.This
parameter is valid when the MP group type is
MC.4(Use two bytes to present MC priority
number, 4 classes), 8(Use four bytes to present
MC priority number, 8 classes)
GUI Value Range: 4,8
Actual Value Range: 4, 8
Unit: None
Default Value: 8
PEERMASK BSC6900 ADD IPPATH(Optional) Meaning: Subnet mask of the peer IP
Unit: None
Default Value: 255.255.255.255
DSTIP BSC6900 ADD IPRT(Mandatory) Meaning: Destination IP address
RMV IPRT(Mandatory) GUI Value Range: None
MOD IPRT(Mandatory) Actual Value Range: 0.0.0.0~255.255.255.255
Unit: None
Default Value: None
DSTMASK BSC6900 ADD IPRT(Mandatory) Meaning: Subnet mask

MOD IPRT(Mandatory) GUI Value Range: None
Unit: None
Default Value: None
DSTMASK BSC6900 RMV IPRT(Mandatory) Meaning: Subnet mask

Unit: None
Default Value: None
NEXTHOP BSC6900 ADD IPRT(Mandatory) Meaning: IP address of the next hop
RMV IPRT(Mandatory) GUI Value Range: None
MOD IPRT(Mandatory) Actual Value Range: 0.0.0.0~255.255.255.255
Unit: None
Default Value: None

SingleRAN

PRIORITY BSC6900 ADD IPRT(Mandatory) Meaning: Route priority. The boards FG2a,
GOUa, UOIa(IP), FG2c, and GOUc support the
configuration of routes with different priorities.
Suppose two or more routes are configured and
their addresses, masks, addresses of the next
hop and priorities are the same, then these
routes can be configured in the active and
standby mode. When the route with higher
priority is available and only this route is valid, the
system switches to the route with lower priority
once the route with higher priority fails.
GUI Value Range: HIGH, LOW
Actual Value Range: HIGH, LOW
Unit: None
Default Value: None
PRIORITY BSC6900 ADD M3LNK(Optional) Meaning: Priority of the signaling link. 0 indicates
MOD M3LNK(Optional) the highest priority.
Unit: None
Default Value: 0
PRIORITY BSC6900 ADD M3RT(Optional) Meaning: Route priority. The highest priority is
MOD M3RT(Optional) represented by 0.
Unit: None
Default Value: 0
PEERIPADDR BSC6900 ADD IPPATH(Mandatory) Meaning: The peer IP address should not be the
same as the local address.
Unit: None
Default Value: None

SingleRAN

PATHT BSC6900 ADD IPPATH(Optional) Meaning: Type of the IP path
GUI Value Range: QoS(QoS), BE(BE),
AF11(AF11), AF12(AF12), AF13(AF13),
AF21(AF21), AF22(AF22), AF23(AF23),
AF31(AF31), AF32(AF32), AF33(AF33),
AF41(AF41), AF42(AF42), AF43(AF43), EF(EF),
LQ_QOS(LQ_QOS), LQ_BE(LQ_BE),
LQ_AF11(LQ_AF11), LQ_AF12(LQ_AF12),
LQ_EF(LQ_EF)
Actual Value Range: QoS, BE, AF11, AF12,
AF13, AF21, AF22, AF23, AF31, AF32, AF33,
AF41, AF42, AF43, EF, LQ_QOS, LQ_BE,
LQ_AF11, LQ_AF12, LQ_AF13, LQ_AF21,
LQ_EF
Unit: None
Default Value: None
LOCIP1 BSC6900 ADD SCTPLNK(Mandatory) Meaning: Identifies the first local IP address that
MOD SCTPLNK(Optional) communicates with the peer end. When it is set
to 0, it is invalid. This IP address must be first
configured on the corresponding interface board.
Unit: None
Default Value: None
LOCIP2 BSC6900 ADD SCTPLNK(Optional) Meaning: Identifies the second local IP address
MOD SCTPLNK(Optional) that communicates with the peer end. When it is
set to 0, it is invalid. This IP address must be first
configured on the corresponding interface board.
Unit: None
Default Value: None
LOCPN BSC6900 ADD SCTPLNK(Mandatory) Meaning: Local SCTP port number

MOD GUI Value Range: 1024~65535
SCTPLNK(Mandatory) Actual Value Range: 1024~65535
Unit: None
Default Value: None
NBAPSRVPN BSC6900 SET Meaning: Number of the NBAP service listening

SCTPSRVPORT(Optional) port
Unit: None

SingleRAN

Default Value: 58080
M3UASRVPN BSC6900 SET Meaning: Number of the M3UA service listening

SCTPSRVPORT(Optional) port
Unit: None
Default Value: 2905
PEERIP1 BSC6900 ADD SCTPLNK(Mandatory) Meaning: First destination IP address. The
MOD SCTPLNK(Optional) invalid value is 0.
Unit: None
Default Value: None
PEERIP2 BSC6900 ADD SCTPLNK(Optional) Meaning: Second destination IP address. The
MOD SCTPLNK(Optional) invalid value is 0.
Unit: None
Default Value: None
PEERPN BSC6900 ADD SCTPLNK(Mandatory) Meaning: Destination SCTP port number
MOD SCTPLNK(Optional) GUI Value Range: 1024~65535
Unit: None
Default Value: None

SingleRAN

CROSSIPFLAG BSC6900 ADD SCTPLNK(Optional) Meaning: The field indicates whether the
MOD SCTPLNK(Optional) cross-connect path is available. When the
cross-path is available, a maximum of four IP
paths exists. The four IP paths are the IP path
between the first local IP address and the first
peer IP address, the IP path between the first
local IP address and the second peer IP address,
the IP path between the second local IP address
and the first peer IP address, and the IP path
between the second local IP address and the
second peer IP address. When the cross-path is
unavailable, a maximum of two IP paths exists.
The two IP paths are the IP path between the first
local IP address and the first peer IP address and
the IP path between the second local IP address
and the second peer IP address.
GUI Value Range:
UNAVAILABLE(UNAVAILABLE),
AVAILABLE(AVAILABLE)
Actual Value Range: UNAVAILABLE,
AVAILABLE
Unit: None
Default Value: UNAVAILABLE
LENO BSC6900 ADD M3DE(Mandatory) Meaning: The local entity number uniquely
identifies a local entity.
Unit: None
Default Value: None
LENO BSC6900 ADD M3LE(Mandatory) Meaning: The local entity number uniquely
MOD M3LE(Mandatory) identifies a local entity.
RMV M3LE(Mandatory) GUI Value Range: 0~186
Unit: None
Default Value: None
DENO BSC6900 ADD M3DE(Mandatory) Meaning: The destination entity number uniquely
MOD M3DE(Mandatory) identifies a destination entity.
RMV M3DE(Mandatory) GUI Value Range: 0~186
Unit: None
Default Value: None
DENO BSC6900 ADD M3LKS(Mandatory) Meaning: The destination entity number uniquely
identifies a destination entity.
Unit: None
Default Value: None

SingleRAN

DENO BSC6900 ADD M3RT(Mandatory) Meaning: The destination entity number uniquely
MOD M3RT(Mandatory) identifies a destination entity.
RMV M3RT(Mandatory) GUI Value Range: 0~186
Unit: None
Default Value: None
ENTITYT BSC6900 ADD M3DE(Mandatory) Meaning: Type of the destination entity. For
MOD M3DE(Optional) details, see RFC4666.
M3UA_ASP: suggested to use when there is a
signaling transfer point (STP) between the local
entity and the destination entity
M3UA_IPSP: suggested to use when there is no
M3UA_SS7SP: suggested to use when the
destination entity is a narrowband signaling point
M3UA_SP: represents all types of the destination
entity
GUI Value Range: M3UA_SGP(M3UA SGP),
M3UA_IPSP(M3UA IPSP),
M3UA_SS7SP(M3UA SS7SP),
M3UA_SP(M3UA SP)
Actual Value Range: M3UA_SGP, M3UA_IPSP,
M3UA_SS7SP, M3UA_SP
Unit: None
Default Value: None
ENTITYT BSC6900 ADD M3LE(Mandatory) Meaning: Type of the M3UA local entity. For
details about the ASP and IPSP, see RFC4666.
M3UA_ASP: suggested to use when there is a
M3UA_IPSP: suggested to use when there is no
GUI Value Range: M3UA_ASP(M3UA_ASP),
M3UA_IPSP(M3UA_IPSP)
Actual Value Range: M3UA_ASP, M3UA_IPSP
Unit: None
Default Value: None
RTCONTEXT BSC6900 ADD M3DE(Optional) Meaning: Routing context. The routing context
MOD M3DE(Optional) identifies a specified route. If the routing context
is to be configured, its value must be negotiated
between the two ends.
Unit: None

SingleRAN

RTCONTEXT BSC6900 ADD M3LE(Optional) Meaning: Routing context. The routing context
MOD M3LE(Optional) identifies a specified route. If the routing context
is to be configured, its value must be negotiated
between the two ends.
Unit: None
SIGLKSX BSC6900 ADD M3LKS(Mandatory) Meaning: Uniquely identifies a signaling link set
MOD M3LKS(Mandatory) GUI Value Range: 0~186
RMV M3LKS(Mandatory) Actual Value Range: 0~186
Unit: None
Default Value: None
SIGLKSX BSC6900 ADD M3LNK(Mandatory) Meaning: Uniquely identifies a signaling link set
MOD M3LNK(Mandatory) GUI Value Range: 0~186
RMV M3LNK(Mandatory) Actual Value Range: 0~186
Unit: None
Default Value: None
SIGLKSX BSC6900 ADD M3RT(Mandatory) Meaning: Uniquely identifies a signaling link set
MOD M3RT(Mandatory) GUI Value Range: 0~186
RMV M3RT(Mandatory) Actual Value Range: 0~186
Unit: None
Default Value: None
LNKSLSMASK BSC6900 ADD M3LKS(Optional) Meaning: Signaling link mask corresponding to

MOD M3LKS(Optional) the M3UA link set. It is used for the M3UA link
load sharing. It is valid only when the working
mode of the signaling link set is set to load
sharing. In the value, the number of 1s
(represented by n) determines the maximum
number (2^n) of links for the load sharing. For
example, B0000 indicates that up to one link is
used for the load sharing, B0001 and B1000
indicate that up to two links are used for the load
sharing. The additional links are not used for the
load sharing. The AND operation between this
value and " signaling route mask " in the "ADD
N7DPC" is equal to 0.
GUI Value Range: B0000(B0000),
B0001(B0001), B0010(B0010), B0011(B0011),
B0100(B0100), B0101(B0101), B0110(B0110),
B0111(B0111), B1000(B1000), B1001(B1001),
B1010(B1010), B1011(B1011), B1100(B1100),
B1101(B1101), B1110(B1110), B1111(B1111)
Actual Value Range: B0000, B0001, B0010,
B0011, B0100, B0101, B0110, B0111, B1000,
B1001, B1010, B1011, B1100, B1101, B1110,
B1111
Unit: None

SingleRAN

Default Value: B1111
SLSMASK BSC6900 ADD N7DPC(Optional) Meaning: Signaling route load sharing. In the
MOD N7DPC(Optional) value, the number of 1s (represented by n)
determines the maximum number (2) of routes
for the load sharing. For example, B0000
indicates that up to one route is used for the load
sharing, B0001 and B1000 indicate that up to two
routes are used for the load sharing. The
additional routes are not used for the load
sharing. The AND operation between this value
and " signaling link mask " in the link set is equal
to 0.
GUI Value Range: B0000(B0000),
B0001(B0001), B0010(B0010), B0011(B0011),
B0100(B0100), B0101(B0101), B0110(B0110),
B0111(B0111), B1000(B1000), B1001(B1001),
B1010(B1010), B1011(B1011), B1100(B1100),
B1101(B1101), B1110(B1110), B1111(B1111)
Actual Value Range: B0000, B0001, B0010,
B0011, B0100, B0101, B0110, B0111, B1000,
B1001, B1010, B1011, B1100, B1101, B1110,
B1111
Unit: None
Default Value: B0000

SingleRAN

TRAMODE BSC6900 ADD M3LKS(Optional) Meaning: Traffic mode of the M3UA link set. At
present, only the active/standby and load sharing
mode is available.
If the M3UA links in the link set work in overriding
mode, only one link in the link set works in the
active mode, and all other links work in the
standby mode. In this case, only the active link
carries traffic, and the standby links do not carry
any traffic. When the active link is faulty, the
standby link with the highest priority is
automatically activated to take over as the active
link.
If the M3UA links in the link set work in
load-sharing mode, all the M3UA links in the link
set work in active mode and carry traffic.
GUI Value Range:
M3UA_OVERRIDE_MOD(Active/Standby
Mode), M3UA_LOADSHARE_MOD(Load
Sharing Mode)
Actual Value Range: M3UA_OVERRIDE_MOD,
M3UA_LOADSHARE_MOD
Unit: None
Default Value: M3UA_LOADSHARE_MOD
WKMODE BSC6900 ADD M3LKS(Optional) Meaning: Working mode of the M3UA link set,
including M3UA_ASP and M3UA_IPSP. For
details about the ASP and IPSP, see the
RFC4666.
GUI Value Range: M3UA_ASP(M3UA_ASP),
M3UA_IPSP(M3UA_IPSP)
Actual Value Range: M3UA_ASP, M3UA_IPSP
Unit: None
Default Value: M3UA_ASP
PDTMRVALUE BSC6900 ADD M3LKS(Optional) Meaning: Pending timer of the M3UA link set
MOD M3LKS(Optional) GUI Value Range: 1~10
Unit: s
Default Value: 5
SIGLNKID BSC6900 ADD M3LNK(Mandatory) Meaning: ID of an M3UA link in the specified link
MOD M3LNK(Mandatory) set
RMV M3LNK(Mandatory) GUI Value Range: 0~15
Unit: None
Default Value: None

SingleRAN

LNKREDFLAG BSC6900 ADD M3LNK(Optional) Meaning: Initial bearing tag of the M3UA link.
This parameter can be set to either active mode
or standby mode. For details about the relevant
bearer tag, see the the parameter "Traffic mode"
of the "ADD M3LKS".
GUI Value Range:
M3UA_MASTER_MOD(M3UA_MASTER_MOD),
M3UA_SLAVE_MOD(M3UA_SLAVE_MOD)
Actual Value Range: M3UA_MASTER_MOD,
M3UA_SLAVE_MOD
Unit: None
Default Value: M3UA_MASTER_MOD
SPX BSC6900 ADD N7DPC(Mandatory) Meaning: Uniquely identifies an OSP
Unit: None
Default Value: None
DPX BSC6900 ADD N7DPC(Mandatory) Meaning: The DSP index uniquely identifies a
MOD N7DPC(Mandatory) DSP.
RMV N7DPC(Mandatory) GUI Value Range: 0~186
Unit: None
Default Value: None
MUXTYPE BSC6900 ADD IPMUX(Mandatory) Meaning: IP packet multiplexing type
GUI Value Range: FPMUX, UDPMUX
Actual Value Range: FPMUX, UDPMUX
Unit: None
Default Value: None
MUXTYPE BSC6900 MOD IPMUX(Mandatory) Meaning: IP packet multiplexing type
GUI Value Range: FPMUX, UDPMUX
Actual Value Range: FPMUX, UDPMUX
Unit: None
Default Value: None
SUBFRAMELEN BSC6900 ADD IPMUX(Optional) Meaning: Maximum sub-frame length. This
MOD IPMUX(Optional) parameter indicates the maximum sub-frame
length for multiplexing. If the length of a
sub-frame exceeds this value, the sub-frame is
not multiplexed.
Unit: byte
Default Value: 352
MAXFRAMELEN BSC6900 ADD IPMUX(Optional) Meaning: Maximum multiplexing frame length
MOD IPMUX(Optional) GUI Value Range: 24~1031
Unit: byte
Default Value: 1031

SingleRAN

FPTIMER BSC6900 ADD IPMUX(Optional) Meaning: Maximum time of delay for
MOD IPMUX(Optional) multiplexing. This parameter is used for the
system to send the multiplexed data. If the time
for buffering the data exceeds this value, the
system does not wait for the multiplexing of
other packets. In this way, the overlong delay can
be prevented.
Unit: ms
Default Value: 2
UDPMUXMODSEND BSC6900 ADD IPMUX(Mandatory) Meaning: UDP multiplexing mode of the sending
MOD IPMUX(Optional) party. If the mode that does not support the
function of compressing the RTP header
indicates that the sending party supports the
UDP MUX RTP header but not the function of
compressing the RTP header. The mode that
supports the function of compressing the RTP
header indicates that the sending party supports
both the UDP MUX RTP header and the function
of compressing the RTP header.
GUI Value Range: NORTPCOMP, RTPCOMP
Actual Value Range: NORTPCOMP, RTPCOMP
Unit: None
Default Value: None
UDPMUXMODRECV BSC6900 ADD IPMUX(Mandatory) Meaning: UDP multiplexing mode of the
MOD IPMUX(Optional) receiving party. The mode that does not support
the function of compressing the RTP header
indicates that the receiving party supports the
UDP MUX RTP header but not the function of
compressing the RTP header. The mode that
supports the function of compressing the RTP
header indicates that the receiving party supports
both the UDP MUX RTP header and the function
of compressing the RTP header.
GUI Value Range: NORTPCOMP, RTPCOMP
Actual Value Range: NORTPCOMP, RTPCOMP
Unit: None
Default Value: None
ACFC BSC6900 ADD MPGRP(Optional) Meaning: Whether to compress the address and
MOD MPGRP(Optional) control fields. If this parameter is set to ENABLE,
both ends negotiate whether to compress the
address and control fields. If this parameter is set
to DISABLE, the address and control fields are
not compressed.
Enable(Enable)
Unit: None

SingleRAN

ACFC BSC6900 ADD PPPLNK(Optional) Meaning: Whether to compress the address and
MOD PPPLNK(Optional) control fields. If this parameter is set to ENABLE,
both ends negotiate whether to compress the
address and control fields. If this parameter is set
to DISABLE, the address and control fields are
not compressed.
Enable(Enable)
Unit: None
PFC BSC6900 ADD MPGRP(Optional) Meaning: Compression flag of the PPP link
MOD MPGRP(Optional) protocol domain
Enable(Enable)
Unit: None
PFC BSC6900 ADD PPPLNK(Optional) Meaning: Compression flag of the PPP link
MOD PPPLNK(Optional) protocol domain
Enable(Enable)
Unit: None
IPHC BSC6900 ADD MPGRP(Optional) Meaning: Whether to compress the IP header of
MOD MPGRP(Optional) a MP group
GUI Value Range: No_HC(No_HC),
UDP/IP_HC(UDP/IP_HC),
RTP/UDP/IP_HC(RTP/UDP/IP_HC)
Actual Value Range: No_HC, UDP/IP_HC,
RTP/UDP/IP_HC
Unit: None
Default Value: UDP/IP_HC
IPHC BSC6900 ADD PPPLNK(Optional) Meaning: Whether to compress the packet
MOD PPPLNK(Optional) headers
GUI Value Range: No_HC(No_HC),
UDP/IP_HC(UDP/IP_HC),
RTP/UDP/IP_HC(RTP/UDP/IP_HC)
Actual Value Range: No_HC, UDP/IP_HC,
RTP/UDP/IP_HC
Unit: None
Default Value: UDP/IP_HC
RED BSC6900 ADD BRD(Mandatory) Meaning: Whether to back up the data of the
board
GUI Value Range: YES(YES), NO(NO)
Actual Value Range: YES, NO
Unit: None
Default Value: None

SingleRAN

RED BSC6900 MOD BRD(Mandatory) Meaning: Whether to back up the data of the
board
GUI Value Range: YES(YES)
Actual Value Range: YES
Unit: None
Default Value: None
SRN BSC6900 SET Meaning: Number of the subrack
BFDPROTOSW(Mandatory) GUI Value Range: 0~11
Unit: None
Default Value: None
SRN BSC6900 ADD Meaning: Number of the subrack
ETHREDPORT(Mandatory) GUI Value Range: 0~11
RMV Actual Value Range: 0~11
ETHREDPORT(Mandatory) Unit: None
Default Value: None
LACPMODE BSC6900 ADD ETHTRK(Mandatory) Meaning: Aggregation mode. When this
parameter is set to static aggregation, the LACP
protocol is activated; otherwise, the LACP
protocol is deactivated.
GUI Value Range: STATIC_LACP,
MANUAL_AGGREGATION
Actual Value Range: STATIC_LACP,
MANUAL_AGGREGATION
Unit: None
Default Value: None
TRKN BSC6900 ADD ETHTRK(Mandatory) Meaning: Aggregation group number
RMV ETHTRK(Mandatory) GUI Value Range: 0~11
Actual Value Range: 0~7(FG2a), 0~1(GOUa),
0~11(FG2c), 0~3(GOUc)
Unit: None
Default Value: None
TRKLNKPN BSC6900 ADD Meaning: Port number of the aggregation
ETHTRKLNK(Mandatory) member
RMV GUI Value Range: 0~11
ETHTRKLNK(Mandatory) Actual Value Range: 0~7(FG2a), 0~1(GOUa),
0~11(FG2c), 0~3(GOUc)
Unit: None
Default Value: None
CHKN BSC6900 ADD Meaning: Detection index
IPPATHBIND(Mandatory) GUI Value Range: 0~511
Unit: None
Default Value: None

SingleRAN

BRDTYPE BSC6900 ADD BRD(Optional) Meaning: Type of the board
GUI Value Range: PEUa, AEUa, FG2a, GOUa,
AOUa, POUa, UOIa, AOUc, POUc, UOIc, FG2c,
GOUc, SPUa, SPUb, DPUb, DPUe, OMUa,
OMUb, SAUa
Actual Value Range: PEUa, AEUa, FG2a,
GOUa, AOUa, POUa, UOIa, AOUc, POUc, UOIc,
FG2c, GOUc, SPUa, SPUb, DPUb, DPUe,
OMUa, OMUb, SAUa
Unit: None
Default Value: None
BRDTYPE BSC6900 SET ETHPORT(Mandatory) Meaning: Board type
GUI Value Range: FG2a, GOUa, FG2c, GOUc
Actual Value Range: FG2a, GOUa, FG2c, GOUc
Unit: None
Default Value: None
BRDTYPE BSC6900 ADD MPLNK(Mandatory) Meaning: Board type
MOD MPLNK(Mandatory) GUI Value Range: PEUa, POUa, POUc
Actual Value Range: PEUa, POUa, POUc
Unit: None
Default Value: None
BRDTYPE BSC6900 ADD PPPLNK(Mandatory) Meaning: Board type

MOD PPPLNK(Mandatory) GUI Value Range: PEUa, POUa, UOIa, POUc
Actual Value Range: PEUa, POUa, UOIa, POUc
Unit: None
Default Value: None
PATHID BSC6900 ADD IPPATH(Mandatory) Meaning: Uniquely identifies an IP path

MOD IPPATH(Mandatory) GUI Value Range: 0~65535
RMV IPPATH(Mandatory) Actual Value Range: 0~65535
Unit: None
Default Value: None
SN BSC6900 SET Meaning: Number of the slot
BFDPROTOSW(Mandatory) GUI Value Range: 0~27
Unit: None
Default Value: None
SN BSC6900 SET ETHPORT(Mandatory) Meaning: Indicates the slot number for running
this command
GUI Value Range: 0~5,8~27
Actual Value Range: 0~5, 8~27
Unit: None
Default Value: None
TXBW BSC6900 ADD IPPATH(Mandatory) Meaning: Transmit bandwidth of IP path
MOD IPPATH(Optional) GUI Value Range: 1~3000000
Unit: kbit/s
Default Value: None

SingleRAN

RXBW BSC6900 ADD IPPATH(Mandatory) Meaning: Receive bandwidth of IP path
MOD IPPATH(Optional) GUI Value Range: 1~3000000
Unit: kbit/s
Default Value: None
MODE BSC6900 ADD SCTPLNK(Mandatory) Meaning: SCTP link work mode. Server mode:
MOD SCTPLNK(Optional) BSC6900 starts the listening and waits for the
peer to send the SCTP-INIT message. Client
mode: BSC6900 actively sends the SCTP-INIT
message.
GUI Value Range: SERVER(SERVER MOD),
CLIENT(CLIENT MOD)
Actual Value Range: SERVER, CLIENT
Unit: None
Default Value: None
PN BSC6900 SET ETHPORT(Optional) Meaning: Ethernet port
Actual Value Range: 0~7(FG2a), 0~1(GOUa),
0~11(FG2c), 0~3(GOUc)
Unit: None
Default Value: None
SUBFRAMELEN NodeB SET FPMUX(Optional) Meaning: Sub frame maximum length
Unit: byte
Default Value: 127
SUBFRAMELEN NodeB ADD IPPATH(Optional) Meaning: Sub frame maximum length
Unit: byte
Default Value: 127
ACFC NodeB ADD MPLNK(Optional) Meaning: Address & Control Field Compress
GUI Value Range: DISABLE(Not Support
Compressed), ENABLE(Support Compressed)
Actual Value Range: DISABLE, ENABLE
Unit: None
Default Value: ENABLE
ACFC NodeB ADD PPPLNK(Optional) Meaning: Address & Control field compress
GUI Value Range: DISABLE, ENABLE
Unit: None
PFC NodeB ADD MPLNK(Optional) Meaning: Protocol Field Compress
Unit: None

SingleRAN

PFC NodeB ADD PPPLNK(Optional) Meaning: Protocol field compress
Unit: None
IPHC NodeB ADD MPGRP(Optional) Meaning: IP header compress
Unit: None
IPHC NodeB ADD PPPLNK(Optional) Meaning: IP header compress
Unit: None

SingleRAN
IP Transport Architecture 10 Counters
10 Counters
For details, see the BSC6900 UMTS Performance Counter Reference and the NodeB Performance
Counter Reference.

SingleRAN
IP Transport Architecture 11 Glossary
11 Glossary
For the acronyms, abbreviations, terms, and definitions, see the Glossary.

SingleRAN
IP Transport Architecture 12 Appendix
12 Appendix
To implement IP RAN, IP interface boards need to be configured on the BSC6900 and BTS/NodeB. For
details about the IP interface boards, see the hardware description document of each network element.
Table 12-1 lists the IP interface boards of the BSC6900.
Table 12-1 IP interface boards of the BSC6900
Board Name Port Type Port Number Reliability Mechanism Supported
PEUa E1/T1 0-31 Board backup
POUa E1/T1 E1 ports: 0-25 Board backup
T1 ports: 0-67
UOIa Unchannelized 0-3 Board backup
STM-1/OC-3C
optical port
POUc Ch-STM-1/OC-3C 0-3 Board backup
optical port
FG2a FE/GE electrical port FE electrical ports: Board backup/Ethernet port backup/Ethernet
0-7 port load sharing/Ethernet link
GE electrical ports: aggregation/Route-based port backup and
0 and 1 (correspond load sharing
to FE ports 0 and 3)
GOUa GE optical port GE optical ports: Board backup/Ethernet port backup/Ethernet
aggregation/Route-based port backup and
load sharing
FG2c FE/GE electrical port FE electrical ports: Board backup/Ethernet port backup/Ethernet
GE electrical ports: aggregation/Route-based port backup and
0-3 load sharing
GOUc GE optical port GE optical ports: Board backup/Ethernet port backup/Ethernet

aggregation/Route-based port backup and
load sharing

SingleRAN
IP Transport Architecture 13 Reference Documents
13 Reference Documents
[1] 3GPP TR23.107: Quality of Service (QoS) concept and architecture
[2] 3GPP TR25.933: IP transport in UTRAN
[3] 3GPP TS 48.103: Base Station System - Media GateWay (BSS-MGW) interface; User plane
transport mechanism
[4] 3GPP TS 48.008: Mobile Switching Centre - Base Station system (MSC-BSS) interface; Layer 3
specification
[5] IEEE 802.1Q: Virtual LANs, defines the operation of Virtual LAN (VLAN) Bridges that permit the
definition, operation and administration of Virtual LAN topologies within a Bridged LAN
infrastructure.
[6] IEEE 802.1ag: Connectivity Fault Management
[7] IEEE 802.3ah: Ethernet in the first mile
[8] IETF DRAFT (02-2002): SS7 MTP3-User Adaptation Layer (M3UA)
[9] IP CLK1000 product documentation
[10] RFC894: A Standard for the Transmission of IP Datagrams over Ethernet Networks
[11] RFC1042: A Standard for the Transmission of IP Datagrams over IEEE 802 Networks
[12] RFC1661: The Point-to-Point Protocol (PPP), provides a standard method for transporting
multi-protocol datagrams over point-to-point links
[13] RFC1662: PPP in HDLC-link Framing, describes the use of HDLC-like framing for PPP
encapsulated packets
[14] RFC1889(01/1996): RTP: A Transport Protocol for Real Time Applications
[15] RFC1990: The PPP Multilink Protocol (ML-PPP), describes a method for splitting, recombining and
sequencing datagrams across multiple logical data links
[16] RFC2131: Dynamic Host Configuration Protocol
[17] RFC2132: DHCP Options and BOOTP Vendor Extensions
[18] RFC2686: The Multi-Class Extension to Multi-link PPP (MC-PPP), describes extensions that allow a
sender to fragment the packets of various priorities into multiple classes of fragments, allowing
high-priority packets to be sent between fragments of lower priorities
[19] RFC3153: PPP Multiplexing (PPPmux), describes a method to reduce the PPP framing overhead
used to transport small packets over low bandwidth links.
[20] RFC3309 (09/2002): Stream Control Transmission Protocol (SCTP) Checksum Change
[21] Transmission Resource Management Feature Parameter Description


IP Transport Architecture

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IP Transport Architecture

Uploaded by

Copyright:

Available Formats

IP Transport Architecture

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

2 Overview of IP Transport Architecture ................................................................................2-1

3 IP Transport Protocols ............................................................................................................3-1

4 IP Transmission Efficiency Improvement ..........................................................................4-1

5 IP Clock Synchronization .......................................................................................................5-1

Issue 02 (2011-09-30) Huawei Proprietary and Confidential i

5.1 Introduction.................................................................................................................................... 5-1

6 Fault Detection Mechanisms .................................................................................................6-1

7 Network Reliability ...................................................................................................................7-1

Issue 02 (2011-09-30) Huawei Proprietary and Confidential ii

1.2 Additional Information

1.3 Intended Audience

1.4 Change History

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 1-1

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 1-2

2 Overview of IP Transport Architecture

2.2 IP Transport Architecture

IP transport architecture consists of the following functional modules:

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 2-1

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 2-2

Figure 3-1 IP transport protocol architecture

The IP transport architecture consists of three parts:

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-1

3.2 Data Link Layer Protocols

Destination Source MAC

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-2

Figure 3-3 IEEE 802.3 frame format

Destination Source MAC

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-3

Figure 3-4 Example of the MAC address

3.2.2 Virtual Local Area Network

The fields of the VLAN tag are described as follows:

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-4

3.2.3 Point-to-Point Protocol

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-5

Figure 3-6 PPP frame format

The fields of the PPP frame are described as follows:

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-6

Data Transmission Mechanism

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-7

Figure 3-9 MLPPP frame format with short sequence number

The fields of the MLPPP frame header are described as follows:

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-8

− MP Group No. (MPGRPN): specifies an MLPPP group within an interface board.

3.3 Internet Protocol

3.3.1 Datagram Format

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-9

The fields of the IP datagram are described as follows:

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-10

3.3.2 IP Address and Routing

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-11

Figure 3-11 Distribution of four types of IP addresses on an IP interface board

Eth Port IP address

IP over FE/GE interface board Device IP ETH Trunk IP address

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-12

3.3.3 Layer 2 Networking and Layer 3 Networking

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-13

Figure 3-13 Layer 3 networking

3.4 User Datagram Protocol

The fields of the UDP datagram are described as follows:

Issue 02 (2011-09-30) Huawei Proprietary and Confidential 3-14