IP Transmission Efficiency Improvement (SRAN9.0 - Draft A) PDF

SingleRAN
IP Transmission Efficiency
Improvement Feature Parameter
Description
Issue Draft A
Date 2014-01-20
HUAWEI TECHNOLOGIES CO., LTD.

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

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
SingleRAN
IP Transmission Efficiency Improvement Feature Parameter
Description Contents
Contents
1 About This Document..................................................................................................................1

1.1 Scope..............................................................................................................................................................................1
1.2 Intended Audience..........................................................................................................................................................1
1.3 Change History...............................................................................................................................................................1
2 Overview.........................................................................................................................................3
3 Multiplexing...................................................................................................................................4
3.1 Overview........................................................................................................................................................................4
3.2 Frame Protocol Multiplexing (for UMTS Only)............................................................................................................4
3.2.1 Introduction.................................................................................................................................................................4
3.2.2 Technical Description..................................................................................................................................................5
3.2.2.1 Packet Format...........................................................................................................................................................5
3.2.2.2 Principles..................................................................................................................................................................6
3.3 UDP Multiplexing (for GSM and UMTS Only)............................................................................................................7
3.3.1 Introduction.................................................................................................................................................................7
3.3.2 Technical Description..................................................................................................................................................7
3.3.2.1 Packet Format...........................................................................................................................................................7
3.3.2.2 Principles................................................................................................................................................................10
3.4 Abis Multiplexing and Ater Multiplexing (for GSM Only).........................................................................................10
3.4.1 Introduction...............................................................................................................................................................10
3.4.2 Technical Description................................................................................................................................................11
3.5 PPP MUX.....................................................................................................................................................................12
3.5.1 Introduction...............................................................................................................................................................12
4 Header Compression...................................................................................................................15
4.1 Overview......................................................................................................................................................................15
4.2 IPHC.............................................................................................................................................................................15
4.2.1 Introduction...............................................................................................................................................................15
4.3 PPPHC..........................................................................................................................................................................18
4.3.1 Introduction...............................................................................................................................................................18
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential ii

SingleRAN
4.3.2.1 PPP Frame Format..................................................................................................................................................18

4.3.2.2 ACFC......................................................................................................................................................................20
4.3.2.3 PFC.........................................................................................................................................................................20
5 MLPPP/MCPPP............................................................................................................................21
5.1 Overview......................................................................................................................................................................21
5.2 Technical Description...................................................................................................................................................21
5.2.1 MLPPP.......................................................................................................................................................................22
5.2.2 MCPPP......................................................................................................................................................................23
6 Related Features...........................................................................................................................24
6.1 Features Related to LBFD-00300401 IP Header Compression....................................................................................24
6.2 Features Related to LBFD-003004 Compression & Multiplexing over E1/T1............................................................24
6.3 Features Related to LBFD-00300402 PPP MUX.........................................................................................................25
6.4 Features Related to LBFD-00300403 ML-PPP/MC-PPP............................................................................................25
6.5 Features Related to GBFD-118604 Abis MUX...........................................................................................................25
6.6 Features Related to GBFD-118612 Abis IPHC............................................................................................................26
6.7 Features Related to GBFD-118610 UDP MUX for A Transmission...........................................................................26
6.8 Features Related to WRFD-050420 FP MUX for IP Transmission.............................................................................26
6.9 Features Related to WRFD-050412 UDP MUX for Iu-CS Transmission...................................................................27
7 Network Impact...........................................................................................................................28
7.1 LBFD-00300401 IP Header Compression...................................................................................................................28
7.2 LBFD-003004 Compression & Multiplexing over E1/T1...........................................................................................28
7.3 LBFD-00300402 PPP MUX.........................................................................................................................................28
7.4 LBFD-00300403 ML-PPP/MC-PPP............................................................................................................................29
7.5 GBFD-118604 Abis MUX...........................................................................................................................................29
7.6 GBFD-118612 Abis IPHC............................................................................................................................................30
7.7 GBFD-118610 UDP MUX for A Transmission...........................................................................................................30
7.8 WRFD-050420 FP MUX for IP Transmission.............................................................................................................32
7.9 WRFD-050412 UDP MUX for Iu-CS Transmission...................................................................................................32
8 Engineering Guidelines.............................................................................................................33
8.1 FP MUX (for UMTS Only)..........................................................................................................................................33
8.1.1 When to Use FP MUX...............................................................................................................................................33
8.1.2 Required Information................................................................................................................................................33
8.1.3 Planning.....................................................................................................................................................................33
8.1.3.1 RF Planning............................................................................................................................................................33
8.1.3.2 Network Planning...................................................................................................................................................33
8.1.3.3 Hardware Planning.................................................................................................................................................33
8.1.4 Deployment...............................................................................................................................................................34
8.1.4.1 Requirements..........................................................................................................................................................34
8.1.4.2 Data Preparation.....................................................................................................................................................34
8.1.4.3 Activation...............................................................................................................................................................36
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential iii

SingleRAN
8.1.4.3.1 Using MML Commands......................................................................................................................................36

8.1.4.3.2 MML Command Examples.................................................................................................................................37
8.1.4.3.3 Using the CME....................................................................................................................................................37
8.1.4.4 Activation Observation...........................................................................................................................................38
8.1.4.5 Deactivation............................................................................................................................................................38
8.1.4.5.3 Using the CME....................................................................................................................................................39
8.1.5 Performance Monitoring............................................................................................................................................40
8.1.6 Parameter Optimization.............................................................................................................................................40
8.1.7 Troubleshooting.........................................................................................................................................................41
8.2 UDP MUX (for GSM and UMTS Only)......................................................................................................................41
8.2.1 When to Use UDP MUX...........................................................................................................................................41
8.2.3 Planning.....................................................................................................................................................................41
8.2.3.1 RF Planning............................................................................................................................................................41
8.2.4 Deployment...............................................................................................................................................................42
8.2.4.1 Requirements..........................................................................................................................................................42
8.2.4.3 Activation...............................................................................................................................................................43
8.2.4.3.3 Using the CME....................................................................................................................................................44
8.2.4.5 Deactivation............................................................................................................................................................46
8.2.4.5.3 Using the CME....................................................................................................................................................46
8.3 Abis MUX (for GSM Only).........................................................................................................................................49
8.3.1 When to Use Abis MUX...........................................................................................................................................49
8.3.3 Planning.....................................................................................................................................................................49
8.3.3.1 RF Planning............................................................................................................................................................49
8.3.4 Deployment...............................................................................................................................................................50
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential iv

SingleRAN
8.3.4.1 Requirements..........................................................................................................................................................51
8.3.4.3 Activation...............................................................................................................................................................53
8.3.4.3.3 Using the CME....................................................................................................................................................54
8.3.4.5 Deactivation............................................................................................................................................................56
8.3.4.5.3 Using the CME....................................................................................................................................................56
8.4 PPP MUX.....................................................................................................................................................................59
8.4.1 When to Use PPP MUX............................................................................................................................................59
8.4.3 Planning.....................................................................................................................................................................59
8.4.3.1 RF Planning............................................................................................................................................................59
8.4.4 Deployment on the Base Station...............................................................................................................................59
8.4.4.1 Requirements..........................................................................................................................................................60
8.4.4.3 Activation...............................................................................................................................................................63
8.4.4.3.3 Using the CME....................................................................................................................................................63
8.4.4.5 Deactivation............................................................................................................................................................69
8.4.5 Deployment on the Base Station Controller..............................................................................................................69
8.4.5.1 Requirements..........................................................................................................................................................69
8.4.5.3 Activation...............................................................................................................................................................72
8.4.5.3.3 Using the CME....................................................................................................................................................73
8.4.5.5 Deactivation............................................................................................................................................................78
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential v

SingleRAN
8.5 IPHC.............................................................................................................................................................................79
8.5.1 When to Use IPHC....................................................................................................................................................79
8.5.3 Planning.....................................................................................................................................................................80
8.5.3.1 RF Planning............................................................................................................................................................80
8.5.4 Deployment on the eNodeB/NodeB/eGBTS.............................................................................................................82
8.5.4.1 Requirements..........................................................................................................................................................82
8.5.4.3 Activation...............................................................................................................................................................87
8.5.4.3.3 Using the CME....................................................................................................................................................88
8.5.4.5 Deactivation............................................................................................................................................................93
8.5.4.5.3 Using the CME....................................................................................................................................................93
8.5.5 Deployment on the GBTS.........................................................................................................................................94
8.5.5.1 Requirements..........................................................................................................................................................94
8.5.5.3 Activation...............................................................................................................................................................95
8.5.5.3.3 Using the CME....................................................................................................................................................96
8.5.5.5 Deactivation............................................................................................................................................................99
8.5.5.5.3 Using the CME....................................................................................................................................................99
8.5.6 Deployment on the Base Station Controller............................................................................................................100
8.5.6.1 Requirements........................................................................................................................................................100
8.5.6.2 Data Preparation...................................................................................................................................................100
8.5.6.3 Activation.............................................................................................................................................................105
8.5.6.3.1 Using MML Commands....................................................................................................................................105
8.5.6.3.2 MML Command Examples...............................................................................................................................106
8.5.6.3.3 Using the CME..................................................................................................................................................106
8.5.6.4 Activation Observation.........................................................................................................................................109
8.5.6.5 Deactivation..........................................................................................................................................................110
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential vi

SingleRAN

8.5.6.5.3 Using the CME..................................................................................................................................................110
8.5.7 Performance Monitoring..........................................................................................................................................111
8.5.8 Parameter Optimization...........................................................................................................................................111
8.5.9 Troubleshooting.......................................................................................................................................................111
8.6 PPPHC........................................................................................................................................................................113
8.6.1 When to Use PPPHC...............................................................................................................................................113
8.6.2 Required Information..............................................................................................................................................113
8.6.3 Planning...................................................................................................................................................................113
8.6.3.1 RF Planning..........................................................................................................................................................114
8.6.3.2 Network Planning.................................................................................................................................................114
8.6.3.3 Hardware Planning...............................................................................................................................................114
8.6.4 Deployment on the eNodeB/NodeB/eGBTS...........................................................................................................114
8.6.4.1 Requirements........................................................................................................................................................114
8.6.4.3 Activation.............................................................................................................................................................118
8.6.4.3.3 Using the CME..................................................................................................................................................119
8.6.4.5 Deactivation..........................................................................................................................................................122
8.6.5 Deployment on the GBTS.......................................................................................................................................122
8.6.5.1 Requirements........................................................................................................................................................122
8.6.5.3 Activation.............................................................................................................................................................126
8.6.5.3.3 Using the CME..................................................................................................................................................127
8.6.5.5 Deactivation..........................................................................................................................................................130
8.6.6.1 Requirements........................................................................................................................................................130
8.6.6.3 Activation.............................................................................................................................................................135
8.6.6.3.3 Using the CME..................................................................................................................................................136
8.6.6.5 Deactivation..........................................................................................................................................................139
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential vii

SingleRAN

8.7 MLPPP/MCPPP..........................................................................................................................................................139
8.7.1 When to Use MLPPP/MCPPP.................................................................................................................................140
8.7.2 Required Information..............................................................................................................................................140
8.7.3 Planning...................................................................................................................................................................140
8.7.3.1 RF Planning..........................................................................................................................................................140
8.7.3.2 Network Planning.................................................................................................................................................140
8.7.3.3 Hardware Planning...............................................................................................................................................140
8.7.4 Deployment on the eNodeB/NodeB/eGBTS...........................................................................................................140
8.7.4.1 Requirements........................................................................................................................................................140
8.7.4.3 Activation.............................................................................................................................................................145
8.7.4.3.3 Using the CME..................................................................................................................................................146
8.7.4.5 Deactivation..........................................................................................................................................................150
8.7.5 Deployment on the GBTS.......................................................................................................................................150
8.7.5.1 Requirements........................................................................................................................................................150
8.7.5.3 Activation.............................................................................................................................................................154
8.7.5.3.3 Using the CME..................................................................................................................................................154
8.7.5.5 Deactivation..........................................................................................................................................................155
8.7.6.1 Requirements........................................................................................................................................................156
8.7.6.3 Activation.............................................................................................................................................................160
8.7.6.3.3 Using the CME..................................................................................................................................................161
8.7.6.5 Deactivation..........................................................................................................................................................163
9 Parameters...................................................................................................................................164
10 Counters....................................................................................................................................181
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential viii

SingleRAN
11 Glossary.....................................................................................................................................182
12 Reference Documents.............................................................................................................183
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential ix

SingleRAN
Description 1 About This Document
1 About This Document
1.1 Scope
This document describes IP transmission efficiency improvement mechanisms used in GSM,
UMTS, and LTE networks, including its technical principles, related features, network impact,
and engineering guidelines.
This document covers the following features:
l LBFD-003004 Compression & Multiplexing over E1/T1

l LBFD-00300401 IP Header Compression
l LBFD-00300402 PPP MUX
l LBFD-00300403 ML-PPP/MC-PPP
l GBFD-118604 Abis MUX
l GBFD-118612 Abis IPHC
l GBFD-118610 UDP MUX for A Transmission
l WRFD-050420 FP MUX for IP Transmission
l WRFD-050412 UDP MUX for Iu-CS Transmission
1.2 Intended Audience

This document is intended for personnel who:
l Need to understand the features described herein

l Work with Huawei products
1.3 Change History

This section provides information about the changes in different document versions. There are
two types of changes, which are defined as follows:
l Feature change
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 1

SingleRAN
Description 1 About This Document
Changes in features of a specific product version

l Editorial change
Changes in wording or addition of information that was not described in the earlier version
Draft A (2014-01-20)
This document is created for SRAN9.0.
This document integrates the following three documents:
l IP Transport Architecture Feature Parameter Description for GBSS

l IP Transport Architecture Feature Parameter Description for RAN
l S1X2OM Channel Management Feature Parameter Description for eRAN

SingleRAN
Description 2 Overview
2 Overview
Transmission efficiency improvement is highly necessary in today's networks with ever-

increasing traffic volume to increase their transmission bandwidth usage. The IP transmission
bandwidth usage can be increased by using multiplexing and header compression technologies
that reduce the header overhead of packets.
Different mechanisms for improving IP transmission efficiency are provided based on the
characteristics of the protocols, as shown in Figure 2-1.
Figure 2-1 Mechanisms for improving IP transmission efficiency

SingleRAN
Description 3 Multiplexing
3 Multiplexing
3.1 Overview
Multiplexing (MUX) reduces the header overhead of packets by multiplexing multiple packets
into one packet to improve transmission efficiency.
Multiplexing technologies include:
l FP MUX
l UDP MUX
l Abis MUX
l Ater MUX
l PPP MUX
Multiplexing may result in delay and jitter; therefore, multiplexing is not recommended when
bandwidth resources are sufficient.
3.2 Frame Protocol Multiplexing (for UMTS Only)
3.2.1 Introduction
Frame Protocol Multiplexing (FP MUX), corresponding to the WRFD-050420 FP MUX for IP
Transmission feature, encapsulates multiple FP PDUs into one FP MUX packet, reducing the
UDP/IP/L2/L1 header transmission overhead and resulting in improved transmission efficiency.
FP MUX is not an open standard.
FP MUX has the following characteristics:
l 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.
l FP MUX significantly improves the transmission efficiency but increases the transmission
delay.

SingleRAN
FP MUX is applicable only to the user plane of the Iub interface that is based on IP transmission.
The BSC6900, BSC6910, and NodeB support this feature.
3.2.2 Technical Description
3.2.2.1 Packet Format

Figure 3-1 shows the format of an IP packet where FP MUX is applied. A multiplexed IP packet
has the following characteristics:
l The FP PDUs in one FP MUX frame share the IP and UDP headers and therefore must
have the same source IP address, destination IP address, and DSCP.
l One FP MUX frame can carry the data of multiple users. The FP MUX header specifies
the size and owner of each FP PDU.
l The UDP header contains a fixed source UDP port number. The number indicates that this
packet is an FP MUX packet and therefore requires demultiplexing at the reception end.
Figure 3-1 Format of an FP MUX IP packet
The fields of an FP MUX IP packet are described as follows:
l User Identifier: specifies the owner of an FP PDU.

l Length Indicator: specifies the size of an FP PDU.
l FP PDU: is the payload of an FP subframe.
FP MUX significantly improves the transmission efficiency. Take the speech service as an
example. The size of each speech packet 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 packet 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 packet 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 + 3)
x n], where n is a natural number. However, when the size of the IP packet increases, the
transmission delay also increases.
The parameters related to FP MUX are as follows:
l FP MUX switch: specifies whether to enable FP MUX.

SingleRAN
l Max subframe length[byte]: specifies the maximum size of an FP subframe. If the size
of an FP subframe exceeds the value of this parameter, the FP subframe is not multiplexed.
l Max frame length[byte]: specifies the maximum size of an FP MUX frame.
l Max delay time[ms]: specifies the maximum period of 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 to prevent a long delay.
NE FP MUX Max Max frame Max delay

switch subframe length time
length
RNC When SUBFRAMEL MAXFRAME FPTIMER

MUXTYPE is EN LEN
set to FPMUX,
FP MUX is
enabled.
NodeB When SUBFRAMEL FRAMELEN TIMER (ADD

IPMUXSWIT EN (ADD (ADD IPPATH)
CH is set to IPPATH) IPPATH)
ENABLE, FP
MUX is
enabled.
3.2.2.2 Principles
The prerequisites for enabling FP MUX are as follows:
l Both the RNC and the NodeB support FP MUX.

l The data related to FP MUX is configured on both the RNC and NodeB sides.
Figure 3-2 shows the working principle of FP MUX at the transmission end.
Figure 3-2 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:

SingleRAN
l If the size of an FP PDU exceeds Max subframe length, the FP PDU is not multiplexed
but directly sent to the UDP layer.
l If the size of an FP MUX frame reaches Max frame length, the FP MUX frame is sent to
the UDP layer without being multiplexed with more FP PDUs.
l If the value of the timer reaches Max delay time, the FP MUX frame is sent to the UDP
layer without being multiplexed with 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.
3.3 UDP Multiplexing (for GSM and UMTS Only)
3.3.1 Introduction
UDP Multiplexing (UDP MUX) 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, reducing the overhead of the UDP/IP/L2/L1 header and
increasing the transmission efficiency.
UDP MUX has the following characteristics:
l 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.
l UDP MUX significantly improves the transmission efficiency but increases the
transmission delay.
l UDP MUX is an open standard.
UDP MUX is applicable to the user plane of the A and Iu-CS interfaces that are based on IP
transmission. The BSC6900 and BSC6910 support UDP MUX.
UDP MUX applied to the A interface corresponds to the GBFD-118610 UDP MUX for A
Transmission feature.
UDP MUX applied to the Iu-CS interface corresponds to the WRFD-050412 UDP MUX for Iu-
CS Transmission feature.
3.3.2.1 Packet Format

UDP MUX has two multiplexing modes:
l Multiplexing mode 1: In this mode, the RTP header is multiplexed without being
compressed. The size of an RTP header is 12 bytes. 3.3.2.1 Packet Format shows the IP
packet format with the RTP header uncompressed.
l 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. The size of the RTP

SingleRAN
header after compression is 3 bytes.Figure 3-4 shows the IP packet format with the RTP
header compressed.
Figure 3-3 IP packet format with the RTP header uncompressed
Figure 3-4 IP packet format with the RTP header compressed
The following describes the fields of a UDP MUX packet.
l 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.
l 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.
l 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.
l R: reserved extension bit. This field is set to 0.

SingleRAN
l 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.
l Sequence Number: specifies the sequence number of an RTP packet.
l Timestamp: specifies the time point when an RTP packet is sent.
l Payload Type: specifies the type of the payload.
UDP MUX packets have the following characteristics:
l The RTP packets in one UDP MUX packet share the IP and UDP headers and therefore
must have the same source IP address, destination IP address, and DSCP.
l A UDP MUX packet can carry the data of different users. The Multiplex header specifies
the size and owner of each RTP packet.
l The UDP header contains a fixed source UDP port number. The number indicates that this
packet is a UDP MUX packet and therefore requires demultiplexing at the reception end.
As shown in Figure 3-3 and Figure 3-4, 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
reducing number of packets. Therefore, the multiplexing efficiency is significantly improved.
For detailed analysis, see 3GPP TR 29.814.
The related parameters on the base station controller are as follows:
l The following three parameters need to be set to enable UDP MUX:

IP MUX type (MUXTYPE): specifies whether UDP MUX is enabled on the base station
controller side when no transmission resource pools are configured. When this
parameter is set to UDPMUX, UDP MUX is enabled.
MUX Type (MUXTYPE): specifies whether UDP MUX is enabled on the base station
controller side when transmission resource pools are configured. When this parameter
is set to UDPMUX, UDP MUX is enabled.
Sender UDP MUX mode (UDPMUXMODSEND): specifies the UDP MUX mode of
the base station controller when it transmits data. The value of this parameter can be
NORTPCOMP or RTPCOMP. If this parameter is set to NORTPCOMP, the base
station controller supports UDP MUX with uncompressed RTP headers when
transmitting data. If this parameter is set to RTPCOMP, the base station controller
supports UDP MUX with compressed RTP headers when transmitting data.
Receive UDP MUX mode (UDPMUXMODRECV): specifies the UDP MUX mode of
the base station controller when it receives data. The value of this parameter can be
NORTPCOMP or RTPCOMP. If this parameter is set to NORTPCOMP, the base
station controller supports UDP MUX with uncompressed RTP headers when receiving
data. If this parameter is set to RTPCOMP, the base station controller supports UDP
MUX with compressed RTP headers when receiving data.
l 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 transmitted without being multiplexed.

SingleRAN
l 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.
l Maximum delay time[ms] (FPTIMER): specifies the maximum period of 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 to prevent a long delay.
3.3.2.2 Principles
The prerequisites for enabling UDP MUX are as follows:
l Both the BSC/RNC and MGW support UDP MUX.

l The data related to UDP MUX is configured on both the BSC/RNC and MGW sides.
Figure 3-5 shows the working principle of UDP MUX at the transmission end.
Figure 3-5 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:
l If the size of a UDP MUX packet reaches MAXFRAMELEN, the UDP MUX packet is
sent without being multiplexed with more RTP packets.
l If the value of the timer reaches FPTIMER, the UDP MUX packet is sent without being
multiplexed with more RTP packets.
After receiving the UDP MUX packets in sequence, the reception end demultiplexes the packets
to obtain the original data and perform service processing.
3.4 Abis Multiplexing and Ater Multiplexing (for GSM

Only)
3.4.1 Introduction
Abis MUX (corresponding to the GBFD-118604 Abis MUX feature) saves bandwidth by
multiplexing packets. The BSC and BTS serve as transmit and receive ends for each other. When
Abis MUX is enabled, the transmit end multiplexes the IP or User Datagram Protocol (UDP)
packets that meet the multiplexing requirements. Multiple IP or UDP packets are multiplexed
into one IP or UDP header at the transmit end and demultiplexed at the receive end to recover

SingleRAN
the original data in the IP/UDP packets. This improves transmission efficiency and saves
transmission bandwidth.
The differences between Abis MUX and Ater MUX are as follows: Abis MUX applies to the
IP-based user plane for the Abis interface, whereas Ater MUX applies to the IP-based user plane
for the Ater interface.

This section describes the Ater MUX and Abis MUX (corresponding to the GBFD-118604 Abis
MUX feature) mechanisms. The packet formats and working principles for Ater MUX and Abis
MUX are the same as those for FP MUX. For details, see section 3.2 Frame Protocol
Multiplexing (for UMTS Only).
When the BSC works in non-transmission resource pool networking mode and MUXTYPE is
set to ABISMUX, Abis MUX is enabled on the BSC. Other parameters are as follows:
l IS QOSPATH (ISQOSPATH): specifies whether a path is a QoS path.
l Max frame length[byte] (MAXFRAMELEN): specifies the maximum size of an Abis
MUX frame.
l PHB (PHB): specifies the PHB type of the IPMUX to be enabled.
l Max subframe length[byte] (SUBFRAMELEN): specifies the maximum size of an Abis
subframe. If the size of an Abis subframe exceeds the value of this parameter, the Abis
subframe is not multiplexed.
When the BSC works in transmission resource pool networking mode and MUXTYPE is set to
ABISMUX, Abis MUX is enabled on the BSC. Other parameters are as follows:
l PHB (PHB): specifies the PHB type of the IPMUX to be enabled.

l Max subframe length[byte] (SUBFRAMELEN): specifies the maximum size of an Abis
l Max frame length[byte] (MAXFRAMELEN): specifies the maximum size of an Abis
MUX frame.
When IPMUXSWITCH is set to ENABLE, Abis MUX is enabled on the eGBTS. Other
parameters are as follows:
l Max Timer (TIMER): specifies the maximum period of 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 to prevent a long delay.
l Max Frame Length(FRAMELEN): specifies the maximum size of an Abis MUX frame.
l Max subframe length(SUBFRAMELEN): specifies the maximum size of an Abis

SingleRAN
The Abis MUX parameters on the GBTS are as follows:
l Max Subframe Length (SUBFRAMETHRES): specifies the maximum size of an Abis

l Maximum Frame Length (PKTLENTHRES): specifies the maximum size of an Abis
MUX frame.
l Maximum Delay Time (TIMEOUT): specifies the maximum period of time that the
l 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 high-priority
service, and PS low-priority service.
The Ater MUX parameters on the BSC6900 are as follows:
l IP MUX Type (MUXTYPE): When this parameter is set to ATERMUX, Ater MUX is
enabled on the BSC6900.
3.5 PPP MUX
3.5.1 Introduction
PPP MUX (corresponding to the LBFD-00300402 PPP MUX feature) is used to multiplex PPP
headers at the PPP/MLPPP layer.
PPP MUX is a technology through which multiple PPP payloads (also called PPP MUX
subframes) are encapsulated into a single PPP frame (also called a PPP MUX frame) to reduce
the overhead of each PPP subframe and improve the bandwidth usage on PPP links.
PPP MUX applies to scenarios where short packets such as speech and data are transmitted over
low-speed links. For long packets, PPP MUX does not improve the transmission efficiency
adequately and prolongs the transmission delay. Therefore, using PPP MUX to transmit long
packets is not recommended.
The PPP MUX frame format is defined in RFC3153. PPP MUX is supported by:
l GSM: the Ater interface of the BSC6900

l UMTS: the Iub, Iur, and Iu interfaces of the BSC6900 and the Iub interface of the NodeB
l LTE: the S1 and X2 interfaces of the eNodeB

By using PPP MUX, multiple PPP-encapsulated packets (or subframes), such as voice and data
packets, of small sizes on low-speed links can be sent in a single PPP multiframe, reducing the
PPP overhead of each frame. Subframes in a PPP multiframe are separated by field separators,
which ensures the recovery of the PPP frames at the receive end.
The PPP MUX frame is a multiframe. In a multiframe, each multiplexed frame is called a
subframe. Figure 3-6 shows the structure of a PPP MUX frame. Figure 3-7 shows the structure
of a subframe.

SingleRAN
Figure 3-6 Structure of a PPP MUX frame
Figure 3-7 Structure of a PPP subframe
Each PPP MUX protocol data unit (PDU) consists of a 2-byte PPP MUX identifier (0X0059)
and multiple subframes. Each subframe consists of the following parts:
l The protocol field flag (PFF) indicates whether a PPP identifier is included in the subframe.
l The length extension (LXT) bit indicates whether one or two bytes are contained in the
length field.
l The subframe length (LEN) indicates the number of bytes occupied by the PPP identifier
and information field of the subframe.
Compared with the original payload, each subframe is added with a 1-byte field indicating the
length and a protocol identifier (PID) field that exists only in the header subframe. The PID field
is shown as Protocol in Figure 3-7. The PID field consists of zero to two bytes, indicating the
multiplexed protocol types.
Parameters related to PPP MUX are as follows:
l PPP MUX switch: specifies whether to enable PPP MUX.

l Maximum PPP MUX subframe size: specifies the maximum size of a PPP MUX subframe.
If the size of a PPP MUX subframe exceeds the value of this parameter, the subframe is
transmitted directly without being multiplexed.
l Maximum PPP MUX frame size: specifies the maximum size of a PPP MUX frame.
l PPP MUX frame timer: specifies the maximum waiting time for multiplexing. If the waiting
time exceeds the value of this parameter, the PPP MUX frame is transmitted without adding
more PPP MUX subframes.
NE PPP MUX Maximum Maximum PPP MUX

Switch PPP MUX PPP MUX Frame Timer
Subframe Frame Size
Size
BSC6900 PPPMUX MAXSFLEN MAXMFLEN MUXTIME
NodeB MUXCP MAXSFLEN MAXMFLEN MUXTIME

SingleRAN
NE PPP MUX Maximum Maximum PPP MUX

Switch PPP MUX PPP MUX Frame Timer
Subframe Frame Size
Size
eNodeB MUXCP MAXSFLEN MAXMFLEN MUXTIME

SingleRAN
Description 4 Header Compression
4 Header Compression
4.1 Overview
Header compression is used in IP over E1/T1 mode to reduce the frame header load on PPP links
or MLPPP links so that transmission bandwidth usage increases. Header compression requires
point-to-point support from both the transmit and receive ends.
Header compression technologies include:
l IP Header Compression (IPHC)

l PPP Header Compression (PPPHC): Address and Control Field Compression (ACFC) and
Protocol Field Compression (PFC)
Compared with multiplexing, header compression is more suitable when the BER is high. Head
compression is supported by:
l GSM: the A, Abis, and Ater interfaces of the BSC6900 and the A and Abis interfaces of
the BSC6910
l UMTS: the Iub, Iur, and Iu interfaces
l LTE: the S1 and X2 interfaces
4.2 IPHC
4.2.1 Introduction
As defined in RFC2507 and RFC3544, IPHC is a standard compression technology in IP over
E1 mode and is used to compress the IP, UDP, and RTP headers transmitted over PPP links.
IPHC deletes redundant information from the headers of IP or UDP packets that share the same
source and destination IP addresses as well as the same source and destination ports in the UDP
data flow. This improves transmission efficiency and saves IP transmission resources.
This section describes IPHC for transmission efficiency improvement, which corresponds to the
following features:
l LBFD-00300401 IP Header Compression

SingleRAN
l GBFD-118612 Abis IPHC

The IPHC working principles are as follows:
l Fixed fields in the IP, UDP, and RTP headers are only included in some packets, and
variable fields are represented in fewer bits.
l During PPP establishment, packets with complete headers are transmitted to establish the
header context at both ends. Subsequently, complete headers are retrieved from the
compressed header based on the header context and the variable fields.
The IPHC-related parameters specify whether header compression is supported by both ends of
a PPP or MLPPP link. That is, the two ends negotiate whether to compress the UDP, IP, and
RTP headers during link establishment.
IPHC removes redundant information in IP/UDP headers in UDP data flows to improve
transmission efficiency.
The user plane uses UDP/IP protocols. A typical data packet includes an 8-byte UDP header
and a 20-byte IP header. Figure 4-1 shows the frame structure of a UDP/IP packet. The UDP
header contains 4 fields, indicating the IP addresses of the source and destination UDP ports,
packet length, and packet checksum. The IP header contains 12 fields, indicating the source and
destination IP addresses and type of service (ToS).
Figure 4-1 Frame structure of a UDP/IP packet
All packets in the same data stream have the same source and destination IP addresses. Most
fields in each packet header have constant values during transmission. IPHC compresses these
constant fields. In this way, the transmit end can use a simplified header to replace a standard
header (the IP/UDP header shown in Figure 4-1, which has 16 fields and occupies 28 bytes).

SingleRAN
An IP/UDP header for the GSM and UMTS is reduced from 28 bytes to 4 bytes, as shown in
Figure 4-2.
Figure 4-2 IPHC working principle
An IP/UDP header for the LTE is reduced from 28 bytes to 5 bytes. The 5-byte compressed
header contains a context identifier (CID, 2 bytes), a generation field (1 byte), and an IP identifier
(2 bytes). The header is enough for uniquely identifying the data stream. The receive end replaces
the compressed header with the standard header before decompressing the header.
Table 4-1 lists the parameters related to IPHC.
Table 4-1 IPHC parameters
NE Parameter Parameter Value Remarks
BSC/RNC IPHC(PPP link) or No_HC The BSC/RNC does

IPHC(MLPPP not support IPHC.
group)
UDP/IP_HC The BSC/RNC
supports IPHC for
UDP and IP packets.
RTP/UDP/IP_HC The BSC/RNC

supports IPHC for
UDP, RTP, and IP
packets.
GBTS IPHC(PPP link) or DISABLE The GBTS does not

IPHC(MLPPP support IPHC.
group)
ENABLE The GBTS supports
IPHC for UDP and IP
packets.

SingleRAN
NE Parameter Parameter Value Remarks
eGBTS/NodeB/ IPHC(PPP link) or DISABLE The NodeB/eNodeB/

eNodeB IPHC(MLPPP eGBTS does not
group) support IPHC.
ENABLE The NodeB/eNodeB/

eGBTS supports
IPHC for UDP and IP
packets.
IPHCSUBOPT(PPP DISABLE Set this parameter to

link) or DISABLE(Disable)
IPHCSUBOPT if the peer device
(MLPPP group) does not support
negotiating about the
setting of this
parameter with the
local device.
ENABLE Set this parameter to

ENABLE(Enable)
if the peer device
supports negotiating
about the setting of
this parameter with
the local device.
IPHC increases bandwidth usage, depending on the payload size. A smaller payload value will
result in higher bandwidth usage.
4.3 PPPHC
4.3.1 Introduction
This section describes PPPHC for transmission efficiency improvement (corresponding to the
LBFD-003004 Compression & Multiplexing over E1/T1 feature).
PPPHC is used to compress PPP headers. The ACFC and PFC techniques can be used together
or separately. The specific techniques are negotiated during the Link Control Protocol (LCP)
phase.
4.3.2.1 PPP Frame Format

The PPP frame format is defined in IETF RFC1661, as shown in Figure 4-3.

SingleRAN
Figure 4-3 PPP frame format
The flag field (F) is 0x7E. The address field (A) and the control field (C) have fixed values of
0xFF and 0x03.
The fields of a PPP frame shown in Figure 4-3 are described as follows:
l Flag: specifies the start or end of a frame. This field for a PPP frame is set to a fixed value.
l Address: specifies an address. This field is set to a fixed value.
l Control: specifies the control field. This field is set to a fixed value.
l Protocol: specifies the type of the protocol encapsulated by the information field. For
example, 0x0021 indicates that an IP packet is encapsulated.
l 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 1500 bytes.
Different values of the Protocol field indicate different types of information fields, as shown
in Table 4-2.
l FCS: specifies the frame check sequence field.
Table 4-2 Mapping between the Protocol field value and information field type
Protocol Field Information Field Type

Value
0x0021 IP packet
0xC021 LCP data
0x8021 Network Control Protocol (NCP) data
0xC023 Password Authentication Protocol (PAP) data
0xC025 Link Quality Report (LQR) data
0xC223 Challenge Handshake Authentication Protocol (CHAP) data

SingleRAN
4.3.2.2 ACFC
As defined in RFC1661, ACFC is used to compress the address and control fields in PPP and
MLPPP frames.
Since the address field (field A shown in Figure 4-3) and control field (field C shown in Figure
4-3) in a PPP header have fixed values during transmission, these fields can be compressed to
conserve bandwidth. During link establishment, the transmit and receive ends negotiate link
attributes, including whether to use ACFC. During the LCP phase, the transmit and receive ends
negotiate whether to compress these fields based on the option "Address-and-Control-Field-
Compression" in control messages sent on PPP links. If both ends use ACFC, the address and
control fields are omitted in subsequent frames.
On the BSC/RNC, if ACFC for PPP links and ACFC for MLPPP links are set to Enable, ACFC
is supported. The two ends then negotiate whether to use ACFC. If the parameters are set to
Disable, ACFC is not supported.
On the eNodeB/NodeB/eGBTS, the ACFC parameter specifies whether to activate ACFC for a
PPP link. The ACFC parameter specifies whether to activate ACFC for an MLPPP link.
On the GBTS, the ACFC parameter specifies whether to activate ACFC for a PPP link. The
ACFC parameter specifies whether to activate ACFC for an MLPPP link.
4.3.2.3 PFC
As defined in RFC1661, PFC is used to compress the protocol field in PPP and MLPPP frames.
The size of the protocol field in a PPP or MLPPP frame header (the Protocol field shown in
Figure 4-3) is two bytes. This field specifies the type of the encapsulated protocol. For example,
0x0021 indicates that an IP packet is encapsulated. Typically, packets at the network layer, such
as IP packets and compressed UDP/IP packets, have a protocol field value of less than 0xFF. In
this situation, the protocol field in each header can be compressed from 2 bytes to 1 byte.
The least significant bit of the protocol field in a PPP or MLPPP frame specifies whether to use
PFC. Value 0 indicates that PFC is not used, and value 1 indicates that PFC is used.
On the BSC/RNC, if PFC for PPP links and PFC for MLPPP links are set to Enable, PFC is
supported. The two ends then negotiate whether to use PFC. If the parameters are set to
Disable, PFC is not supported.
On the eNodeB/NodeB/eGBTS, the PFC parameter specifies whether to activate PFC for a PPP
link. The PFC parameter specifies whether to activate PFC for an MLPPP link.
On the GBTS, the PFC parameter specifies whether to activate PFC for a PPP link. The PFC
parameter specifies whether to activate PFC for an MLPPP link.

SingleRAN
Description 5 MLPPP/MCPPP
5 MLPPP/MCPPP
5.1 Overview
This section describes MLPPP/MCPPP for transmission efficiency improvement, which
corresponds to the feature LBFD-00300403 ML-PPP/MC-PPP. MLPPP (also called MP) is an
extension of the PPP protocol. It is a data link layer protocol that exists between the PPP layer
and the network layer. MLPPP stands for Multi-Link Point-to-Point Protocol.
MLPPP is used to combine multiple PPP links (also called MLPPP links) into one logical link.
MLPPP fragments upper-layer packets and then transmits the fragmented packets over MLPPP
links, increasing transmission efficiency.
MCPPP is an extension of MLPPP. MCPPP prioritizes packets and then fragments the packets
in descending order of priority, providing more service classes compared with MLPPP.
MLPPP/MCPPP is supported by:
l GSM: the A, Abis, and Ater interfaces of the BSC6900 and the A and Abis interfaces of
the BSC6910
l UMTS: the Iub, Iur, and Iu interfaces of the RNC and the Iub interface of the NodeB
l LTE: the S1 and X2 interfaces of the eNodeB
5.2 Technical Description

PPP defines the standard method of encapsulating the IP packets on point-to-point links. The
point-to-point links include the E1/T1 links and SDH links. E1/T1 ports use the PPP protocol at
the data link layer. The PPP protocol has two disadvantages:
l Each PPP link corresponds to only one E1 link. If multiple E1 links are used as transport
bearers, multiple PPP links must be configured. On a live network, the services with heavy
traffic require bandwidths of more than one E1 link.
l PPP frames are transmitted in sequence. As a result, high-priority frames may fail to be
transmitted because the network is congested with a large number of low-priority frames,
resulting in end-to-end performance deterioration.

SingleRAN
To address the preceding problems, the MLPPP/MCPPP technique is used to increase the
transport bandwidths, enhance transmission reliability, and ensure the transmission priority.
5.2.1 MLPPP
Data Transmission Mechanism

MLPPP is used to combine multiple PPP links into one logical link. MLPPP fragments IP packets
and then transmits the fragmented packets over MLPPP links. In this manner, the bandwidth
and throughput are increased. Meanwhile, the transmission delay is reduced. Figure 5-1 shows
the MLPPP process: A large packet is fragmented into small packets, and the small packets are
transmitted on different physical links.
Figure 5-1 MLPPP process
Frame Format
The MLPPP frame format is defined in RFC1990. The MLPPP frame has two formats: with a
long sequence number and with a short sequence number, as shown in Figure 5-2 and Figure
5-3, respectively.
Figure 5-2 MLPPP frame format with a long sequence number

SingleRAN
Figure 5-3 MLPPP frame format with a short sequence number
The fields of the MLPPP frame header are described as follows:
l B: Beginning fragment bit (one bit). This field specifies whether an MLPPP frame is the
first fragment of a PPP frame.
l E: Ending fragment bit (one bit). This field specifies whether an MLPPP frame is the last
fragment of a PPP frame.
5.2.2 MCPPP
MCPPP (also called MC) is an extended protocol on the basis of MLPPP. MCPPP stands for
Multi-Class Point-to-Point Protocol. By using the reserved bits in the MLPPP packets, MCPPP
grants priorities to the packets transmitted at the link convergence layer. Therefore, the packets
with higher real-time requirements or higher priorities can be transmitted preferentially, while
other packets are suspended. For details about MCPPP, see RFC2686.
The MLPPP technology divides a large packet into small packets and has each of the small
packets transmitted on different physical links. When different physical links have different
delays, the packets may be out of order. To ensure the correct sequence of packets, MLPPP and
MCPPP provide sequence numbers for the disassembled packets (small packets). MLPPP/
MCPPP provides long sequences and short sequences. Long sequences have a maximum of 16
MCPPP priorities. Short sequences have a maximum of four MCPPP priorities. Currently, the
base station controller and base station support different numbers of MCPPP priorities as
follows:
l If long sequences are used, 8 or 4 MCPPP priorities are supported.

l If short sequences are used, 4 MCPPP priorities are supported.

SingleRAN
Description 6 Related Features
6 Related Features
6.1 Features Related to LBFD-00300401 IP Header

Compression
Prerequisite Features
None
Mutually Exclusive Features

None
Impacted Features
None
6.2 Features Related to LBFD-003004 Compression &

Multiplexing over E1/T1
None

None
Impacted Features
None

SingleRAN
6.3 Features Related to LBFD-00300402 PPP MUX

None

None
Impacted Features
None
6.4 Features Related to LBFD-00300403 ML-PPP/MC-PPP

MCPPP must be used along with MLPPP, while MLPPP can be used alone.

None
Impacted Features
None
6.5 Features Related to GBFD-118604 Abis MUX

l GBFD-118601 Abis over IP
l GBFD-118611 Abis IP over E1/T1

None
Impacted Features
When this feature is used with the Transmission Load Adjustment Based on Actual Traffic
Measurement function of the GBFD-118605 IP QOS feature, the Abis transmission efficiency
improves significantly.

SingleRAN
6.6 Features Related to GBFD-118612 Abis IPHC

GBFD-118611 Abis IP over E1/T1

None
Impacted Features
None
6.7 Features Related to GBFD-118610 UDP MUX for A

Transmission
l GBFD-118602 A over IP
l GBFD-118622 A IP over E1/T1

None
Impacted Features
None
6.8 Features Related to WRFD-050420 FP MUX for IP

Transmission
WRFD-050402 IP Transmission Introduction on Iub Interface

None
Impacted Features
This feature affects the following features:

SingleRAN
l WRFD-140208 Iub Transmission Resource Pool in RNC

l WRFD-150243 Iub IP Transmission Based on Dynamic Load Balance
When FP MUX is used, an RNC pool supports only one IP address. NodeBs are interconnected
to the RNC using IP paths.
When Transmission Resource Pool in RNC is used, an RNC pool supports multiple IP addresses.
This enables traffic data to be transmitted on different transmission paths to implement load
balancing. However, FP MUX enables traffic data to converge on one transmission path and
multiplexes traffic packets of the same type to one packet for transmission, which reduces the
transmission overhead. Therefore, Transmission Resource Pool in RNC and FP MUX cannot
be used concurrently.
6.9 Features Related to WRFD-050412 UDP MUX for Iu-CS

Transmission
WRFD-050409 IP Transmission Introduction on Iu Interface

None
Impacted Features
None

SingleRAN
Description 7 Network Impact
7 Network Impact
7.1 LBFD-00300401 IP Header Compression

System Capacity
No impact.
Network Performance
No impact.
7.2 LBFD-003004 Compression & Multiplexing over E1/T1

System Capacity
No impact.
Network Performance
No impact.
7.3 LBFD-00300402 PPP MUX

System Capacity
No impact.
Network Performance
No impact.

SingleRAN
7.4 LBFD-00300403 ML-PPP/MC-PPP

System Capacity
No impact.
Network Performance
No impact.
7.5 GBFD-118604 Abis MUX

System Capacity
No impact.
Network Performance
Abis MUX improves transmission efficiency on the Abis interface. Figure 7-1 shows the frame
format before and after Abis MUX is enabled, using enhanced full rate (EFR) speech packets
as an example.
Figure 7-1 Frame format before and after Abis MUX is enabled
Using EFR speech packets as an example, before Abis MUX is enabled, the sizes of the Ethernet
header, IP/UDP header, and payload for a frame are 14, 28, and 37 bytes, respectively. Therefore,
the size of a frame is 83 bytes and the total size of six frames is 498 bytes. After Abis MUX is
enabled, six frames are multiplexed. The total size of these multiplexed frames is 286 bytes, and

SingleRAN
the average size of each frame is 47.67 bytes. Therefore, Abis MUX reduces the size of a frame
by: (83-47.67)/83 = 42.56%
Shorter original IP packets and more multiplexed frames lead to higher transmission efficiency.
When transmission quality deteriorates, especially when there is a bit error, enabling Abis MUX
has a negative impact on speech quality; for example, the mean opinion score (MOS) decreases.
The impact can be minimized by reducing the value of the parameter related to multiplexing
duration or by reducing the size of the frames to be multiplexed. However, the impact cannot
be eliminated. Abis MUX is not recommended if the BER is higher than 10-6.
7.6 GBFD-118612 Abis IPHC

System Capacity
No impact.
Network Performance
Abis IPHC improves transmission efficiency on the Abis interface.
l Without Abis MUX, IPHC improves transmission efficiency on the Abis interface by about
33%.
Using FR speech packets as an example, before Abis IPHC is enabled, the sizes of the IP/
UDP header and payload are 28 and 37 bytes, respectively. The size of a packet is 72 bytes.
After Abis IPHC is enabled, the size of the IP/UDP header is reduced to 4 bytes and
therefore the size of an IP/UDP packet is reduced to 48 bytes.
Abis IPHC reduces the size of a packet by: (72 - 48)/72 = 33%
l With Abis MUX, IPHC further improves transmission efficiency on the Abis interface by
about 5%.
For example, the size of a packet is 447 bytes after 10 speech packets are multiplexed using
Abis MUX. After IPHC, the size of the packet is further reduced to 423 bytes.
Abis IPHC reduces the size of a packet by: (447 - 423)/447 = 5.4%
7.7 GBFD-118610 UDP MUX for A Transmission

System Capacity
No impact.
Network Performance
The UDP MUX for A Transmission feature improves transmission efficiency on the A interface.
This feature supports two multiplexing modes:
l Multiplexing mode 1: In this mode, the RTP header is multiplexed without being
compressed.

SingleRAN
l Multiplexing mode 2: In this mode, the RTP header is multiplexed and compressed.
More multiplexed frames lead to higher transmission efficiency.
Figure 7-2 shows the frame format before and after this feature is enabled, using EFR speech
packets with the RTP header being compressed as an example.
Figure 7-2 Frame format before and after UDP MUX for A Transmission is enabled
As shown in Figure 7-2, before this feature is enabled, the sizes of the Ethernet header, IP/UDP
header, RTP header, speech type field, and FCS for a frame are 14, 28, 12, 31, and 4 bytes,
respectively. Therefore, the size of a frame is 89 bytes and the total size of 10 frames is 890
bytes.
After this feature is enabled, 10 frames are multiplexed. The sizes of the Ethernet header, IP/
UDP header, multiplexed header, RTP header, speech type field, and FCS for a frame are reduced
to 14, 28, 5, 4, 31, and 4 bytes, respectively. The formula for calculating the total size of these
multiplexed frames is as follows: 4 bytes + 28 bytes + (5 bytes + 4 bytes + 31 bytes) x 10 + 4
bytes = 446 bytes
After this feature is enabled, transmission efficiency increases from 34.83% to 69.50%.
l Transmission efficiency before the multiplexing: 31/89 = 34.83%

l Transmission efficiency after the multiplexing: 31/44.6 = 69.50%
When there is a bit error, enabling this feature has a negative impact on speech quality. The
impact can be minimized by reducing the value of the parameter related to multiplexing duration
or by reducing the size of the frames to be multiplexed. However, the impact cannot be
eliminated. This feature is not recommended if the BER is higher than 10-6.

SingleRAN
7.8 WRFD-050420 FP MUX for IP Transmission

System Capacity
No impact.
Network Performance
No impact.
7.9 WRFD-050412 UDP MUX for Iu-CS Transmission

System Capacity
No impact.
Network Performance
No impact.

SingleRAN
Description 8 Engineering Guidelines
8 Engineering Guidelines
8.1 FP MUX (for UMTS Only)

This section describes how to deploy the WRFD-050420 FP MUX for IP Transmission feature
in a newly deployed UMTS network. FP MUX is applicable only to the user plane of the Iub
interface that is based on IP transmission. FP MUX does not apply to the GSM or LTE.
8.1.1 When to Use FP MUX

It is recommended that FP MUX be activated in the following scenarios:
l The bandwidth of the bearer network is insufficient.

l The transmission performance of the bearer network is good. For the IP bearer network,
the packet loss rate is low; for the SDH/MSTP network, the bit error rate is low.
Since this feature may cause latency and jitter, it is not recommended that this feature be activated
if the bandwidth of the Iub interface is sufficient.
8.1.2 Required Information

None
8.1.3 Planning
8.1.3.1 RF Planning
N/A
8.1.3.2 Network Planning

The Iub interface is based on IP transmission.
8.1.3.3 Hardware Planning

RNC:

SingleRAN
l The FG2a/FG2c, GOUa/GOUc, and POUc of the BSC6900 support this feature.
l The FG2c, GOUc, and EXOUa of the BSC6910 support this feature.
NodeB:
l The UTRP, UTRPc, WMPT, and UMPT support this feature.
8.1.4 Deployment
8.1.4.1 Requirements
l Other features
This feature requires the WRFD-050402 IP Transmission Introduction on Iub Interface
feature.
l NEs
The receive end of IP packets support FP MUX.
l License
The license for the IP Transmission feature has been activated.
Feature ID Feature License NE Sales Unit

Name Control Item
WRFD-05042 FP MUX for IP FP MUX RNC Erl+Mbps

0 Transmission
8.1.4.2 Data Preparation

Table 8-1 and Table 8-2 list the data to prepare before activating FP MUX.
NOTE
The related MOs are IPMUX (when no transmission resource pools are configured) and IPPOOLMUX
(when transmission resource pools are configured).
Table 8-1 Data to prepare before activating FP MUX (RNC side)
Parameter Name Parameter ID Setting Notes Data Source
IP MUX Type MUXTYPE This parameter Default value/

specifies the IP Recommended value
packet multiplexing
type. Set this
parameter to
FPMUX.
Max subframe length SUBFRAMELEN N/A Default value/

[byte] Recommended value

SingleRAN
Maximum Frame MAXFRAMELEN To prevent the Default value/

Length[byte] multiplexed frame Recommended value
from being
segmented, the
following condition
must be met:
The size of
multiplexed header +
the size of IP packet
header + UDP header
+ the value of
MAXFRAMELEN
< the value of MTU.
Maximum Delay FPTIMER This parameter Default value/

Time[ms] specifies the Recommended value
maximum time that
the system waits
before sending the
multiplexed data.
The smaller the
parameter value, the
lower the
multiplexing rate. If
the parameter is set to
a value greater than
the maximum value,
latency and jitter may
occur and CS
services are affected.
Generally, set this
parameter to 1 or 2.
Table 8-2 Data that needs to be prepared before activating FP MUX (NodeB side)
IPMUX Switch Flag IPMUXSWITCH N/A Transport network

plan (internal)
Max Subframe SUBFRAMELEN N/A Transport network

Length plan (internal)

SingleRAN
Max Frame Length FRAMELEN To prevent the Default value/

multiplexed frame Recommended value
from being
segmented, the
following condition
must be met: The size
of multiplexed
header + the size of
IP packet header +
UDP header + the
value of
FRAMELEN< the
value of MTU.
Max Timer TIMER This parameter Transport network

specifies the plan (internal)
maximum time that
the system waits
before sending the
multiplexed data.
The smaller the
lower the
the maximum value,
occur and CS
Generally, set this
8.1.4.3 Activation
8.1.4.3.1 Using MML Commands

Step 1 Run the RNC MML command ADD IPMUX (when no transmission resource pools are
configured) or ADD IPPOOLMUX (when transmission resource pools are configured) with
MUXTYPE set to FPMUX to activate FP MUX over the Iub interface.

SingleRAN
NOTE
You do not need to configure the number of packets to be multiplexed after feature activation. This is
because the RNC selects appropriate subframes within the period specified by the Max Timer parameter.
Subframes that meet the following conditions will be combined into a packet:
l The sending of the subframe is within the time specified by the Max Timer parameter.
l The size of the subframe is smaller than the value of the Max Subframe Length parameter.
l The total size of the subframes plus 8 is not larger than the value of the Max Frame Length parameter.
Step 2 For RAN15.0 or later, run the NodeB MML command ADD IPPATH to activate FP MUX over
the Iub interface on the NodeB side. For versions earlier than RAN15.0, run the NodeB MML
command SET FPMUX to activate FP MUX over the Iub interface on the NodeB side.
----End
8.1.4.3.2 MML Command Examples

//Activating FP MUX on the RNC side when no transmission resource pools are
configured.
ADD IPMUX: MUXTYPE=FPMUX, ANI=1, PATHID=1, ISQOSPATH=NO, SUBFRAMELEN=352,
MAXFRAMELEN=1031, FPTIMER=2;
//Activating FP MUX on the NodeB side
ADD IPPATH: PATHID=0, CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PT=PPP, PN=0,
JNRSCGRP=ENABLE, RSCGRPID=0, LOCALIP="192.168.11.110", PEERIP="192.168.22.220",
DSCP=20, IPMUXSWITCH=ENABLE, SUBFRAMELEN=128, FRAMELEN=512, TIMER=2;
8.1.4.3.3 Using the CME

NOTE
When configuring FP MUX on the CME, perform a single configuration first, and then perform a batch
modification if required. Configure the parameters of a single object before a batch modification. Perform
a batch modification before logging out of the parameter setting interface.
Step 1 Configure a single object (such as a cell) on the CME.
Set parameters on the CME according to the operation sequence in Table 8-3. For instructions
on how to perform the CME single configuration, see CME Single Configuration Operation
Guide.
Step 2 (Optional) Modify objects in batches on the CME. (CME batch modification center)
To modify objects in batches, click on the CME to start the batch modification wizard. For
instructions on how to perform a batch modification through the CME batch modification center,
press F1 on the wizard interface to obtain online help.
----End

SingleRAN
Table 8-3 Configuring parameters on the CME
SN MO NE Parameter Parameter Configura

Name ID ble in CME
Batch
Modificati
on
1 IPMUX (No RNC IP MUX MUXTYPE No

transmission Type
resource
pools are Max SUBFRAM
configured.)/ subframe ELEN
IPPOOLM length[byte]
UX Maximum MAXFRAM
( Frame ELEN
Transmissio Length[byte]
n resource
pools are Maximum FPTIMER
configured.) Delay Time
[ms]
2 FPMUX NodeB IPMUX IPMUXSWI No

Switch Flag TCH
Max Timer TIMER
Max Frame FRAMELE

Length N
Max SUBFRAM
Subframe ELEN
Length
8.1.4.4 Activation Observation

Step 1 Run the RNC MML command DSP IPMUX (when no transmission resource pools are
configured) or DSP IPPOOLMUX (when transmission resource pools are configured) to query
the status and performance of the IP packet multiplexing.
Step 2 For RAN15.0 or later, run the NodeB MML command DSP IPPATH to query whether the value
of the IPMUX Switch Flag parameter is Enable for a specified IP path. For versions earlier
than RAN15.0, run the NodeB MML command LST FPMUX to query whether the value of the
IPMUX Switch Flag is Enable for a specified IP path.
----End
8.1.4.5 Deactivation

SingleRAN

Step 1 When no transmission resource pools are configured, run the RNC MML command RMV
IPMUX to deactivate the FP MUX for IP Transmission feature on the IP path of the RNC. When
transmission resource pools are configured, run the RNC MML command RMV
IPPOOLMUX to deactivate the FP MUX for IP Transmission feature on the adjacent node.
Step 2 Run the NodeB MML command MOD IPPATH to deactivate the FP MUX for IP Transmission
feature.
----End

//Deactivating FP MUX on the RNC side when no transmission resource pools are
configured
RMV IPMUX: IPMUXINDEX=1;
//Deactivating FP MUX on the RNC side when transmission resource pools are
configured
RMV IPPOOLMUX: IPPOOLMUXINDEX=1;
Deactivating FP MUX on the NodeB side
MOD IPPATH: IPMUXSWITCH=DISABLE;

NOTE
When configuring FP MUX on the CME, perform a single configuration first, and then perform a batch
Guide.
----End

SingleRAN

Name ID ble in CME
Batch
Modificati
on
1 IPMUX (No RNC IP MUX IPMUXIND No

transmission Index EX (No
resource transmission
pools are resource
configured.)/ pools are
IPPOOLM configured.)/
UX IPPOOLMU
( XINDEX
Transmissio (Transmissio
n resource n resource
pools are pools are
configured.) configured.)
2 FPMUX NodeB IPMUX IPMUXSWI No

Switch Flag TCH)
8.1.5 Performance Monitoring

Step 1 Run the RNC MML command DSP IPMUX (when no transmission resource pools are
the status and performance of the IP packet multiplexing.
Step 2 Run the NodeB MML command DSP IPPATH to query the value of the IPMUX Switch
Flag parameter for a specified IP path.
----End
8.1.6 Parameter Optimization

Generally, the default parameter values are the optimized ones. In some cases, the value of the
SUBFRAMELEN parameter requires to be modified to control the size of the subframe. To
ensure that a specified frame can be multiplexed, set the SUBFRAMELEN parameter to a value
smaller than the size of the specified frame. To prevent a specified frame from being multiplexed
to reduce delay, set the SUBFRAMELEN parameter to a value larger than the size of this frame.
If the size of the multiplexed frame is greater than the value of the MTU parameter, which can
be set by running the SET ETHPORT command, the multiplexed frame will be fragmented.
To avoid this, modify the value of the MAXFRAMELEN parameter.
The greater the value of the FPTIMER parameter, the higher the multiplexing rate and the more
obvious the delay and jitter.

SingleRAN
8.1.7 Troubleshooting
N/A
8.2 UDP MUX (for GSM and UMTS Only)

This section describes how to deploy the GBFD-118610 UDP MUX for A Transmission feature
in a newly deployed GSM network and how to deploy the WRFD-050412 UDP MUX for Iu-
CS Transmission feature in a newly deployed UMTS network. UDP MUX is applicable only to
the user plane of the A and Iu-CS interfaces that are based on IP transmission. UDP MUX does
not apply to the LTE.
8.2.1 When to Use UDP MUX

Use UDP MUX in the following scenarios:
l The bandwidth of the bearer network is insufficient.

l The transmission performance of the bearer network is good. For the IP bearer network,
the packet loss rate is low; for the SDH/MSTP network, the bit error rate is low.
UDP MUX is not recommended if the BER is higher than 10-6 or the transmission delay is close
to the threshold that the A/Iu-CS interface requires for the transmission network QoS.
Since UDP MUX may cause latency and jitter, it is not recommended that UDP MUX be
activated if the BSC/RNC and the CN equipment are located in the same equipment room.

Before you deploy the UDP MUX for A Transmission and UDP MUX for Iu-CS Transmission
features, collect the following information:
l Whether both the BSC and the CN support this feature.

This feature is available only when both the BSC and the CN support:
Negotiation about UDP multiplexing.
UDP multiplexing.
UDP multiplexing with the RTP header compressed.
l Quality of the transmission network.
For example, the BER and transmission delay. This feature is not recommended if the BER
is higher than 10-6 or the transmission delay is close to the threshold that the A interface
requires for the transmission network QoS.
8.2.3 Planning
8.2.3.1 RF Planning
N/A

SingleRAN

The A and Iu-CS interfaces are based on IP transmission.
Transmission bandwidth must be correctly planned.

Hardware planning for UDP MUX for A Transmission:
Transmission Mode NE Required Board
IP over Ethernet BSC6900 l FG2a, FG2c, or FG2d

l GOUa, GOUc, or GOUd
BSC6910 l FG2c or FG2d

l GOUc or GOUd
l EXOUa
IP over E1/T1 BSC6900 l POUc

l PEUa or PEUc
Hardware planning for UDP MUX for Iu-CS Transmission:
Transmission Mode NE Required Board
IP over Ethernet BSC6900 l FG2a or FG2c

l GOUa or GOUc
BSC6910 l FG2c
l GOUc
l EXOUa
IP over E1/T1 BSC6900 l POUc
8.2.4 Deployment
l Other features
The UDP MUX for A Transmission feature requires GBFD-118602 A over IP and
GBFD-118622 A IP over E1/T1.
The UDP MUX for Iu-CS Transmission feature requires the WRFD-050409 IP
Transmission Introduction on Iu Interface feature.
l NEs

SingleRAN
The CN supports UDP MUX.

l License
The licenses for the UDP MUX for A Transmission and UDP MUX for Iu-CS Transmission
features have been activated.
Feature ID Feature License NE Sales Unit

Name Control Item
GBFD-118610 UDP MUX for UDP MUX for BSC Erl

A A
Transmission Transmission
WRFD-05041 UDP MUX for UDP MUX for RNC Erl

2 Iu-CS Iu-CS
Transmission Transmission
l Other requirements
Static IP routing to the local BSC/RNC is configured on the peer device.
The RTCPSWITCH parameter is set to ON(Open) for the UDP MUX for A Transmission
feature. The RTCPSwitch parameter is set to ON for the UDP MUX for Iu-CS Transmission
feature. For detailed operations, see 8.2.4.3 Activation.

For information about data to prepare before deploying UDP MUX, see Table 8-1.
8.2.4.3 Activation

l If no transmission resource pools are configured, run the BSC/RNC MML command ADD
IPMUX or MOD IPMUX to activate UDP MUX. Set the IP MUX Type parameter to
UDPMUX and set the following parameters based on the network plan: Max subframe
length[byte], Maximum Frame Length[byte], and Maximum Delay Time[ms]. To
activate UDP MUX for multiple links, run this command for each link you want to activate.
l If transmission resource pools are configured, run the BSC/RNC MML command ADD
IPPOOLMUX or MOD IPPOOLMUX to activate UDP MUX. Set the IP MUX Type
parameter to UDPMUX and set the following parameters based on the network plan: Max
subframe length[byte], Maximum Frame Length[byte], and Maximum Delay Time
[ms]. To activate UDP MUX for multiple adjacent nodes, run this command for multiple
times.

SingleRAN
NOTE
l If no transmission resource pools are configured, IP paths must be configured based on the network
plan. If transmission resource pools are configured, correct adjacent nodes must be configured based
on the network plan.
l The BSC/RNC assigns a default IPMUXINDEX value, but this parameter can also be set manually.
l The RTCP function is enabled. To enable the function for the UDP MUX for A Transmission feature,
run the ADD GCNNODE command with RTCPSWITCH parameter is set to ON(Open). To enable
the function for the UDP MUX for Iu-CS Transmission feature, run the ADD UCNNODE command
with RTCPSwitch set to ON.

//Activating UDP MUX when no transmission resource pools are configured
ADD IPMUX: MUXTYPE=UDPMUX, ANI=0, PATHID=0, ISQOSPATH=NO, SUBFRAMELEN=352,
MAXFRAMELEN=1031, FPTIMER=2, UDPMUXMODSEND=RTPCOMP, UDPMUXMODRECV=RTPCOMP,
IPMUXINDEX=0;
//Activating UDP MUX when transmission resource pools are configured
ADD IPPOOLMUX: MUXTYPE=UDPMUX, ANI=0, PHB=AF33, SUBFRAMELEN=352, MAXFRAMELEN=1031,
FPTIMER=2, UDPMUXMODSEND=RTPCOMP, UDPMUXMODRECV=RTPCOMP, IPPOOLMUXINDEX=0;

NOTE
When configuring UDP MUX on the CME, perform a single configuration first, and then perform a batch
Guide.
----End

Name ID ble in CME
Batch
Modificati
on
1 IPMUX (No BSC6900 IP MUX MUXTYPE No

transmission Type
resource
pools are Adjacent ANI
configured.) node ID

SingleRAN

Name ID ble in CME
Batch
Modificati
on
IP path ID PATHID
IS ISQOSPAT
QOSPATH H
Max SUBFRAM
subframe ELEN
length[byte]
Maximum MAXFRAM
Frame ELEN
Length[byte]
Maximum FPTIMER
Delay Time
[ms]
Sender UDP UDPMUXM

MUX Mode ODSEND
Receive UDPMUXM
UDP MUX ODRECV
Mode
IP MUX IPMUXIND
Index EX
IPPOOLM BSC6900/ MUX Type MUXTYPE No

UX BSC6910
( Adjacent ANI
Transmissio node
n resource PHB PHB
pools are
configured.) Max SUBFRAM
subframe ELEN
length[byte]
Maximum MAXFRAM
Frame ELEN
Length[byte]
Maximum FPTIMER
Delay Time
[ms]
Sender UDP UDPMUXM

MUX Mode ODSEND

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Receive UDPMUXM
UDP MUX ODRECV
Mode
IP MUX IPPOOLMU
Index XINDEX

Run the BSC/RNC MML command DSP IPMUX (when no transmission resource pools are
the statistics and status of the IP packet multiplexing. Check whether the feature has been
activated based on the values of the IPMUX Status, Number of Received MUX Packets, and
Number of Sent MUX Sub-frames parameters.

Run the BSC/RNC MML command RMV IPMUX (when no transmission resource pools are
configured) or RMV IPPOOLMUX (when transmission resource pools are configured) to
deactivate UDP MUX.

//Deactivating UDP MUX when no transmission resource pools are configured
//Deactivating UDP MUX when transmission resource pools are configured
RMV IPPOOLMUX: IPPOOLMUXINDEX=0;
NOTE
When configuring UDP MUX on the CME, perform a single configuration first, and then perform a batch
Guide.

SingleRAN
----End

Name ID ble in CME
Batch
Modificati
on
1 IPMUX (No BSC6900 IP MUX IPMUXIND No

transmission Index EX
resource
pools are
configured.)
IPPOOLM BSC6900/ IP MUX IPPOOLMU No

UX BSC6910 Index XINDEX
(
Transmissio
n resource
pools are
configured.)

Run the BSC/RNC MML command DSP IPMUX (when no transmission resource pools are
the statistics and status of the IP packet multiplexing. Check the feature status based on the values
of the IPMUX Status, Number of Received MUX Packets, and Number of Sent MUX Sub-
frames parameters.
UDP MUX for Iu-CS Transmission

Generally, the default parameter values are the optimized ones. In some cases, the value of the
SUBFRAMELEN parameter requires to be modified to control the size of the subframe.
If the size of the multiplexed frame is greater than the value of the MTU parameter, which can
be set by running the SET ETHPORT command, the multiplexed frame will be fragmented.
To avoid this, modify the value of the MAXFRAMELEN parameter.
The greater the value of the FPTIMER parameter, the higher the frequency reuse coefficient
and the more obvious the delay and jitter.

SingleRAN
UDP MUX for A Transmission

l If the transmission quality of CS services is poor and the PS data rate is low, you can infer
that bit errors occur. In this situation, it is recommended that parameters listed in Table
8-7 be set to smaller values, minimizing the impact of high BER.
l If the transmission quality of CS services is favorable and the PS data rate is low, you can
infer that transmission congestion occurs. It is recommended that parameters listed in Table
8-7 be set to larger values, relieving transmission congestion.
NOTE
Transmission quality of CS services is indicated by the voice quality during calls.

Transmission quality of PS services is indicated by the PS data rate.
Table 8-7 Parameters to be adjusted
NE Parameter
BSC (No transmission resource pools are l FPTIMER

configured.) l MAXFRAMELEN
BSC (Transmission resource pools are l FPTIMER

If transmission bandwidth is not saved after UDP MUX is enabled, perform the following
operations:
Step 1 Observe the traffic volume.
During off-peak hours, few packets can be multiplexed and UDP MUX cannot save transmission
bandwidth. This is not a fault.
Step 2 Verify that SUBFRAMETHRES, TIMEOUT, and PKTLENTHRES are appropriately set to
ensure that packets can be multiplexed.
Step 3 Check the statistics and MUX status.
1. In non-transmission pool networking mode, run the DSP IPMUX command to query the
statistics and IP MUX status.
l If IPMUX Status is Enable and the number of sent and received packets increases after
multiplexing, the IP MUX function is normal.
l If IPMUX Status is Enable but the number of sent and received packets does not
increase after multiplexing, check whether the IP MUX function is configured correctly.
2. In transmission pool networking mode, run the DSP IPPOOLMUX command to query
the statistics and value of IPMUX Status.
l If IPMUX Status is Enable and the number of sent and received packets increases after
multiplexing, the IP pool MUX function is normal.

SingleRAN
l If IPMUX Status is Enable and the number of sent and received packets does not
increase after multiplexing, check whether the IP pool MUX function is configured
correctly.
----End
8.3 Abis MUX (for GSM Only)

This section describes how to deploy the GBFD-118604 Abis MUX feature in a newly deployed
GSM network. Abis MUX is applicable only to the user plane of the Abis interface that is based
on IP transmission. Abis MUX does not apply to the UMTS or LTE.
8.3.1 When to Use Abis MUX

In an IP-based RAN backhaul network, Abis MUX is recommended if transmission bandwidth
resources are insufficient and transmission quality is favorable.

Before you deploy Abis MUX, collect information about the quality of the transmission network,
for example, the BER and transmission delay. Abis MUX is not recommended if the BER is
higher than 10-6 or the transmission delay is close to the threshold that the Abis interface requires
for the transmission network QoS.
8.3.3 Planning
8.3.3.1 RF Planning
N/A

The Abis interface is based on IP transmission.

l BSC
If both the BSC and BTS use IP over E1/T1 transmission, the BSC must be configured with
the following boards:
BSC6900: PEUa, PEUc or POUc
BSC6910: POUc
If the BTS uses IP over E1/T1 transmission, the BSC uses IP over Ethernet transmission,
and the BSC and BTS are connected using a router, the BSC must be configured with
the boards listed in the following table.
NE Required Board
BSC6900 l FG2a, FG2c, or FG2d


SingleRAN
NE Required Board

l GOUc or GOUd
l EXOUa
If both the BSC and BTS use IP over Ethernet transmission, the BSC must be configured
with the boards listed in the following table.
NE Required Board


l GOUc or GOUd
l EXOUa
l BTS
The BTS3006C and BTS3002E do not support this feature.
8.3.4 Deployment

SingleRAN
Table 8-8 Deployment requirements
Aspect Requirement
BSC l If both the BSC and BTS use IP over E1/

T1 transmission, the BSC6900 must be
configured with PEUa or PEUc, and
POUc boards. The BSC6910 must be
configured with POUc boards.
l If the BTS uses IP over E1/T1
transmission, the BSC uses IP over
Ethernet transmission, and the BSC and
BTS are connected using a router:
The BSC6900 must be configured with
FG2a, FG2c, or FG2d
GOUa, GOUc, or GOUd
FG2c or FG2d
GOUc or GOUd
EXOUa
l If both the BSC and BTS use IP over
Ethernet transmission, the BSC must be
configured with the following boards:
FG2a, FG2c, or FG2d
GOUa, GOUc, or GOUd
FG2c or FG2d
GOUc or GOUd
EXOUa
BTS The BTS3006C and BTS3002E do not

support this feature.
GSM networking The Abis interface is based on IP

transmission.
MS None
MSC None

SingleRAN
Aspect Requirement
License The license controlling this feature has been

activated. For details on how to activate the
license, see License Management Feature
Parameter Description. For details about
license items, see License Control Item
Description.
Other requirements None

Table 8-1, Table 8-2, and Table 8-9 list the data to prepare before activating Abis MUX.
Table 8-9 Data to prepare before activating Abis MUX (GBTS side) (Related MO:
BTSABISMUXFLOW)
Service Type SRVTYPE - Network plan
Max Subframe SUBFRAMETHRE - Default value/

Length S Recommended value
Maximum Frame PKTLENTHRES To prevent the Default value/

Length multiplexed frame Recommended value
from being
segmented, the
following condition
must be met: The size
of multiplexed
header + the size of
IP packet header +
UDP header + the
value of
PKTLENTHRES <
the value of MTU.

SingleRAN
Maximum Delay TIMEOUT This parameter Default value/

Time specifies the Recommended value
maximum time that
the system waits
before sending the
multiplexed data.
The smaller the
lower the
the maximum value,
occur and CS
Generally, set this
8.3.4.3 Activation

l BSC
In transmission resource pool networking mode, run the ADD IPPOOLMUX
command on the BSC LMT to add an Abis MUX stream. In this step, set MUX Type
to ABISMUX, and set Adjacent node, PHB, and IP MUX Index to appropriate values.
In other networking modes, run the ADD IPMUX command on the BSC LMT to add
an Abis MUX stream. In this step, set IP MUX Type to ABISMUX, and set Adjacent
node ID, IP path ID, and IS QOSPATH to appropriate values.
NOTE
l The BSC can assign a value to IP MUX Index by default. You can also set this parameter based on
actual situations.
l If IS QOSPATH is set to YES(YES), set the PHB parameter to specify the per-hop behavior (PHB)
type for which Abis MUX is to be activated.
l GBTS
On the BSC LMT, run the ADD BTSABISMUXFLOW command with Service Type set
to an appropriate value to add an Abis MUX stream on the BTS side.
l eGBTS
During initial configuration, run the ADD IPPATH command on the BTS LMT to add
an Abis MUX stream on the eGBTS side. In this step, set Path Type to FIXED(Fixed
QoS) and IPMUX Switch Flag to ENABLE(Enable).

SingleRAN
During data adjustment, run the MOD IPPATH command on the BTS LMT to add an
Abis MUX stream on the eGBTS side. In this step, set Path Type to FIXED(Fixed
QoS) and IPMUX Switch Flag to ENABLE(Enable).

//Activating Abis MUX
//BSC (No transmission resource pools are configured.)
ADD IPMUX: MUXTYPE=ABISMUX, ANI=0, PATHID=0, ISQOSPATH=NO, IPMUXINDEX=0;
//BSC (Transmission resource pools are configured.)
ADD IPPOOLMUX: MUXTYPE=ABISMUX, ANI=0, PHB=BE, IPPOOLMUXINDEX=0
//GBTS
ADD BTSABISMUXFLOW: IDTYPE=BYID, BTSID=0, SRVTYPE=CSVOICE;
//eGBTS (during initial configuration)
ADD IPPATH: PATHID=0, CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PT=PPP, PN=0,
LOCALIP="192.168.11.110", PEERIP="192.168.22.220", DSCP=20, RXBW=8, TXBW=8,
TXCBS=15000, TXEBS=1000, IPMUXSWITCH=ENABLE, SUBFRAMELEN=128, FRAMELEN=512,
TIMER=2;
//eGBTS (during routine maintenance)
MOD IPPATH: PATHID=0, CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PT=PPP, PN=0,
IPMUXSWITCH=ENABLE;

NOTE
When configuring Abis MUX on the CME, perform a single configuration first, and then perform a batch
Set parameters on the CME according to the operation sequence in Table 8-10, Table 8-11, and
Table 8-12 . For instructions on how to perform the CME single configuration, see CME Single
Configuration Operation Guide.
----End
Table 8-10 Configuring parameters on the CME (BSC)

Name ID ble in CME
Batch
Modificati
on
1 IPMUX (No BSC6900 IP MUX MUXTYPE No

transmission Type
resource
pools are Adjacent ANI
configured.) node ID

SingleRAN

Name ID ble in CME
Batch
Modificati
on
IP PATH ID PATHID
IP MUX IPMUXIND
Index EX
IS ISQOSPAT
QOSPATH H
IPPOOLM BSC6900/ IP MUX MUXTYPE No

UX BSC6910 Type
(Transmissio
n resource Adjacent ANI
pools are node ID
configured.) PHB PHB
IP MUX IPPOOLMU
Index XINDEX
Table 8-11 Configuring parameters on the CME (GBTS)

Name ID ble in CME
Batch
Modificati
on
1 BTSABISM BSC6900/ Service Type SRVTYPE No

UXFLOW BSC6910
Table 8-12 Configuring parameters on the CME (eGBTS)

Name ID ble in CME
Batch
Modificati
on
1 IP Path eGBTS IPMUX IPMUXSWI Yes

Switch Flag TCH

SingleRAN

l BSC and GBTS
In transmission resource pool networking mode, run the DSP IPPOOLMUX command
on the BSC LMT to query the information about Abis MUX.
Expected result: The value of IPMUX Status is Enable.
In other networking modes, run the DSP IPMUX command on the BSC LMT to query
the information about Abis MUX.
Expected result: The value of IPMUX Status is Enable.
l eGBTS
On the BTS LMT, run the DSP IPPATH command to query the information about Abis
MUX.
Expected result: The value of IPMUX Switch Flag is Enable.

l BSC
In transmission resource pool networking mode, run the RMV IPPOOLMUX
command on the BSC LMT to delete the Abis MUX stream.
In other networking modes, run the RMV IPMUX command on the BSC LMT to delete
the Abis MUX stream.
l GBTS
On the BSC LMT, run the RMV BTSABISMUXFLOW command to delete the Abis
MUX stream from the BTS side.
l eGBTS
On the BTS LMT, run the MOD IPPATH command with IPMUX Switch Flag set to
DISABLE(Disable) to delete the Abis MUX stream from the eGBTS side.

//Deactivating Abis MUX
//BSC (No transmission resource pools are configured.)
//BSC (Transmission resource pools are configured.)
RMV IPPOOLMUX: IPPOOLMUXINDEX=0
//GBTS
RMV BTSABISMUXFLOW: IDTYPE=BYID, BTSID=0, SRVTYPE=CSVOICE;
//eGBTS
MOD IPPATH: PATHID=0, CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PT=PPP, PN=0,
IPMUXSWITCH=DISABLE;

NOTE
When configuring Abis MUX on the CME, perform a single configuration first, and then perform a batch

SingleRAN
Set parameters on the CME according to the operation sequence in Table 8-13 through Table
8-15. For instructions on how to perform the CME single configuration, see CME Single
----End

Name ID ble in CME
Batch
Modificati
on
1 IPMUX (No BSC6900 IP MUX IPMUXIND No

transmission Index EX
resource
pools are
configured.)
IPPOOLM BSC6900/ IP MUX IPPOOLMU No

UX BSC6910 Index XINDEX
(Transmissio
n resource
pools are
configured.)

Name ID ble in CME
Batch
Modificati
on
1 BTSABISM BSC6900/ Service Type SRVTYPE No

UXFLOW BSC6910

SingleRAN

Name ID ble in CME
Batch
Modificati
on
1 IP Path eGBTS IPMUX IPMUXSWI Yes

Switch Flag TCH

None

l If transmission quality is poor, for example, if there is a bit error, set parameters listed in
Table 8-16 to small values to improve service quality.
l If transmission quality is good but transmission bandwidth resources are insufficient, set
parameters listed in Table 8-16 to large values to save transmission bandwidth.
NOTE
To monitor IP transmission quality, enable GBFD-118607 IP Performance Monitor.
Table 8-16 Parameters to be adjusted
NE Parameter
BSC (No transmission resource pools are l FPTIMER

BSC (Transmission resource pools are l FPTIMER

GBTS l TIMEOUT
l PKTLENTHRES
eGBTS l TIMER
l FRAMELEN
If transmission bandwidth is not saved after Abis MUX is enabled, perform the following
operations:
Step 1 Observe the traffic volume.

SingleRAN
During off-peak hours, few packets can be multiplexed and Abis MUX cannot save transmission
bandwidth. This is not a fault.
Step 2 Modify the settings of SUBFRAMETHRES, TIMEOUT, and PKTLENTHRES to ensure that
packets can be multiplexed.
----End
8.4 PPP MUX

This section describes engineering guidelines for PPP MUX.
8.4.1 When to Use PPP MUX

PPP MUX is recommended if PPP headers are required to be multiplexed at the PPP/MLPPP
layer to increase transmission capacity.

None
8.4.3 Planning
8.4.3.1 RF Planning
None

IP over E1/T1 is applied to devices at the two ends where PPP MUX is used.

l Hardware planning for the LTE to enable LBFD-003004 Compression & Multiplexing over
E1/T1:
The eNodeB must be configured with the UMPT board. The LMPT board does not support
PPP MUX.
l GSM hardware planning:
The BSC6900 must be configured with the POUc board.
l UMTS hardware planning:
To support PPP MUX for a PPP link, the BSC6900 must be configured with the PEUa,
PEUc, POUa, UOIa, or POUc board.
To support PPP MUX for an MLPPP group, the BSC6900 must be configured with the
PEUa, PEUc, POUa, or POUc board.
The BTS3900 must be configured with the UTRP and UMPT/WMPT boards.
8.4.4 Deployment on the Base Station

SingleRAN
Transmission equipment connected to the eNodeB/NodeB supports E1/T1 ports along with PPP
MUX.

This section describes the data that you need to collect for setting parameters. Required data is
data that you must collect for all scenarios. Collect scenario-specific data when necessary for a
specific feature deployment scenario.
There are three types of data sources:
l Network plan (negotiation required): parameter values planned by the operator and
negotiated with the evolved packet core (EPC) or peer transmission equipment
l Network plan (negotiation not required): parameter values planned and set by the operator
l User-defined: parameter values set by users
Required Data
None
Scenario-specific Data
PPP MUX for a PPP Link
The following table describes the parameters that must be set in a PPPLNK MO to configure
PPP MUX for a PPP link. The cabinet number, subrack number, and slot number of the PPP
link must be the same as those of the board where the link is located. If a UMPT is used for
transmission, set the subboard type of the PPP link to BASE_BOARD(Base Board).
Parameter Name Parameter ID Data Source Setting Notes
PPPMUX PPPLNK.MUXCP Network plan Set this parameter to

(negotiation ENABLE(Enable).
required) This parameter value
must be consistent
with the setting of the
peer end.
Maximum Length of PPPLNK. Network plan Set this parameter

PPP Mux Subframe MAXSFLEN (negotiation based on the network
required) plan. These
parameters are valid
Maximum Length of PPPLNK. Network plan only if the
PPP Muxframe MAXMFLEN (negotiation PPPLNK.MUXCP
required) parameter is set to
PPP Muxframe PPPLNK. Network plan ENABLE(Enable).
Combination MUXTIME (negotiation
Timeout required)

SingleRAN
IP Header PPPLNK.IPHC Network plan Set this parameter

Compression (negotiation based on the network
required) plan.
Protocol Field PPPLNK.PFC Network plan Set this parameter

required) plan.
Address and Control PPPLNK.ACFC Network plan Set this parameter

Field Compression (negotiation based on the network
required) plan.
PPP MUX for an MLPPP Group
The following table describes the parameters that must be set in an MPGRP MO to configure
PPP MUX for an MLPPP group. The cabinet number, subrack number, and slot number of the
MLPPP group must be the same as those of the board where the group is located. If a UMPT is
used for transmission, set the subboard type of the PPP link to BASE_BOARD(Base Board).
PPPMUX MPGRP.MUXCP Network plan Set this parameter to

must be consistent
peer end.
PPP Mux Subframe MPGRP. Network plan Set this parameter

Max Length MAXSFLEN (negotiation based on the network
PPP Muxframe Max MPGRP. Network plan only if the
Length MAXMFLEN (negotiation MPGRP.MUXCP
PPPMUX Combine MPGRP. Network plan ENABLE(Enable).
Timeout MUXTIME (negotiation
required)
IP Header MPGRP.IPHC Network plan Set this parameter

required) plan.
Multi-Class PPP MPGRP.MCPPP Network plan Set this parameter

(negotiation based on the network
required) plan.

SingleRAN
MP/MC Header MPGRP.MHO Network plan Set this parameter

Option (negotiation based on the network
MCPPP Class MPGRP. Network plan only if the
MCCLASS (negotiation MPGRP.MCPPP
ENABLE(Enable).
The following table describes the parameters that must be set in an MPLNK MO to configure
PPP MUX for an MLPPP link in an MLPPP group. Before adding an MLPPP link to a specific
MLPPP group, ensure that the MLPPP group has been configured. The cabinet number, subrack
number, and slot number of an E1/T1 port must be the same as those of the board where the port
is located. If a UMPT is used for transmission, set the subboard types of the MLPPP link, MLPPP
group, and E1/T1 port to BASE_BOARD(Base Board).
Link No. MPLNK. Network plan Each MLPPP link in

PPPLNKN (negotiation an MLPPP group
required) must have a unique
link number.
MLPPP Group No. MPLNK.MPGRPN Network plan Each MLPPP group

(negotiation must have a unique
required) group number.
Timeslot No. MPLNK.TSN Network plan Set this parameter

required) plan.
Maximum Receive MPLNK.MRU Network plan Set this parameter

Unit (negotiation based on the network
required) plan.
Protocol Field MPLNK.PFC Network plan Set this parameter to

Compression (negotiation DISABLE
required) (Disable). This
parameter value must
be consistent with the
setting of the peer
end.

SingleRAN
Address and Control MPLNK.ACFC Network plan Set this parameter to

Field Compression (negotiation DISABLE
setting of the peer
end.
Negotiation Time MPLNK. Network plan Retain the default

RESTARTTMR (negotiation value.
required)
8.4.4.3 Activation

l PPP MUX for a PPP Link
Run the ADD PPPLNK command to configure PPP MUX for a PPP link.
l PPP MUX for an MLPPP Group
Step 1 Run the ADD MPGRP command to configure PPP MUX for an MLPPP group.
Step 2 Run the ADD MPLNK command to add an MLPPP link to the MLPPP group.
----End

ADD PPPLNK: CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PPPLNKN=0, PN=0, AUTH=NONAUTH,
TSN=TS1-1&TS2-1&TS3-1&TS4-1&TS5-1&TS6-1&TS7-1&TS8-1&TS9-1&TS10-1&TS11-1&TS12-1&TS1
3-1&TS14-1&TS15-1&TS16-1&TS17-1&TS18-1&TS19-1&TS20-1&TS21-1&TS22-1&TS23-1&TS24-1&T
S25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1, LOCALIP="192.168.20.3",
IPMASK="255.255.255.0", PEERIP="192.168.20.75", MUXCP=ENABLE;

ADD MPGRP: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, MPGRPN=0, AUTH=NONAUTH,
LOCALIP="192.168.20.3", IPMASK="255.255.255.0", PEERIP="192.168.20.75",
MUXCP=ENABLE, IPHC=ENABLE, MCPPP=ENABLE, MHO=LONG;
ADD MPLNK: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PPPLNKN=0, MPGRPN=0,
MPGRPSBT=BASE_BOARD, E1T1SRN=0, E1T1SN=7, E1T1SBT=BASE_BOARD, E1T1PN=0,
S25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1;
Using the CME to Perform Batch Configuration for Newly Deployed Base Stations
Enter the values of the parameters listed in Table 8-17 in a summary data file, which also contains
other data for the new base stations to be deployed. Then, import the summary data file into the

SingleRAN
CME for batch configuration. For detailed instructions, see sections "Creating eNodeBs in
Batches" and "Creating NodeBs in Batches" in the initial configuration guide for the eNodeB
and NodeB, respectively.
The summary data file may be a scenario-specific file provided by the CME or a customized
file, depending on the following conditions:
l The MOs in Table 8-17 are contained in a scenario-specific summary data file. In this
situation, set the parameters in the MOs, and then verify and save the file.
l Some MOs in Table 8-17 are not contained in a scenario-specific summary data file. In
this situation, customize a summary data file to include the MOs before you can set the
parameters.

SingleRAN
Table 8-17 Parameters for PPP MUX
MO Sheet in the Parameter Group Remarks

Summary Data
File
PPPLNK User-defined sheet Subrack No., None

eNodeB/NodeB Cabinet No.,
Transport Data is Subboard Type,
recommended. Slot No., PPP Link
No., Port No.,
Authentication
Type, Password,
User Name, Time
Slot No., Local IP,
Mask, Peer IP,
PPPMUX,
Maximum Length
of PPP Mux
Subframe (byte),
Maximum Length
of PPP Muxframe
(byte), PPP
Muxframe
Combination
Timeout(ms), IP
Header
Compression,
Maximum Receive
Unit(byte),
Negotiation Time
(ms), Protocol Field
Compression,
Address and
Control Field
Compression, PPP
Fault Frame
Occurrence
Threshold(per
mill), PPP Fault
Frame Clear
Threshold(per mill)

SingleRAN

Summary Data
File
MPGRP User-defined sheet Subrack No., None

eNodeB/NodeB Cabinet No.,
Transport Data is Subboard Type,
recommended. Slot No., MLPPP
Group No., Multi-
Class PPP,
Authentication
Type, User Name,
Password, Local IP,
Mask, Peer IP, MP,
MC Header Option,
PPPMUX, MLPPP
Fragment Size
(byte), PPP Mux
Subframe Max
Length(byte), PPP
Muxframe Max
Length(byte),
PPPMUX Combine
Timeout(ms),
MCPPP Class, IP
Header
Compression,
MLPPP Packets
Discard Alarm
Appear Threshold
(per mill), MLPPP
Packets Discard
Alarm Disappear
Threshold(per mill)

SingleRAN

Summary Data
File
MPLNK User-defined sheet Cabinet No., None

eNodeB/NodeB Subrack No., Slot
Transport Data is No., Subboard
recommended. Type, Link No.,
MLPPP Group
Subboard Type,
MLPPP Group No.,
E1/T1 Subrack No.,
E1/T1 Slot No., E1/
T1 Subboard Type,
E1/T1 Port No.,
Timeslot No.,
Maximum Receive
Unit, Protocol Field
Compression,
Address and
Control Field
Compression,
Negotiation Time
Using the CME to Perform Batch Configuration for Existing Base Stations
Batch reconfiguration using the CME is the recommended method to activate a feature on
existing base stations. This method reconfigures all data, except neighbor relationships, for
multiple base stations in a single procedure. The procedure is as follows:
Step 1 After creating a planned data area, choose CME > Advanced > Customize Summary Data
File (U2000 client mode), or choose Advanced > Customize Summary Data File (CME client
mode), to customize a summary data file for batch reconfiguration.
NOTE
For context-sensitive help on a current task in the client, press F1.
Step 2 Choose CME > LTE Application/UMTS Application/GSM Application > Export Data >
Export Base Station Bulk Configuration Data (U2000 client mode), or choose LTE
Application/UMTS Application/GSM Application > Export Data > Export Base Station
Bulk Configuration Data (CME client mode), to export the base station data stored on the CME
into the customized summary data file.
Step 3 In the summary data file, set the parameters in the MOs listed in Table 8-17 and close the file.
Step 4 Choose CME > LTE Application/UMTS Application/GSM Application > Import Data >
Import Base Station Bulk Configuration Data (U2000 client mode), or choose LTE
Application/UMTS Application/GSM Application > Import Data > Import Base Station
Bulk Configuration Data (CME client mode), to import the summary data file into the CME,
and then start the data verification.

SingleRAN
Step 5 After data verification is complete, choose CME > Planned Area > Export Incremental
Scripts (U2000 client mode), or choose Area Management > Planned Area > Export
Incremental Scripts (CME client mode), to export and activate the incremental scripts.
----End
Using the CME to Perform Single Configuration

On the CME, set the parameters listed in the "Data Preparation" section for a single base station.
The procedure is as follows:
Step 1 In the planned data area, click Base Station in the upper left corner of the configuration window.
Step 2 In area 1 shown in Figure 8-1, select the base station to which the MOs belong.
Figure 8-1 MO search and configuration window
NOTE
To view descriptions of the parameters in the MO, click in area 4 and press F1.
Area 5 displays the details of a selected area-4 entry in vertical format. Click the Details icon to show or
hide this area.
Step 3 On the Search tab page in area 2, enter an MO name, for example, CELL.
Step 4 In area 3, double-click the MO in the Object Name column. All parameters in this MO are
displayed in area 4.
Step 5 Set the parameters in area 4 or 5.

SingleRAN
Step 6 Choose CME > Planned Area > Export Incremental Scripts (U2000 client mode), or choose
Area Management > Planned Area > Export Incremental Scripts (CME client mode), to
export and activate the incremental scripts.
----End

l PPP MUX for a PPP link
Run the DSP PPPLNK command, and then check the command output. If the value of Link
Status is UP(Up), PPP MUX for the PPP link has been activated.
l PPP MUX for an MLPPP group

Run the DSP MPGRP command, and then check the command output. If the value of MLPPP
Group Status is UP(Up), PPP MUX for the MLPPP group has been activated.
N/A
8.4.5 Deployment on the Base Station Controller
Transmission equipment connected to the BSC/RNC supports E1/T1 ports along with PPP
MUX.

negotiated with the EPC or peer transmission equipment
Required Data
None
PPP MUX for a PPP Link
PPP MUX for a PPP link. The subrack number and slot number of the PPP link must be the same
as those of the board where the link is located.

SingleRAN
PPP mux PPPLNK.PPPMUX Network plan Set this parameter to

must be consistent
peer end.
PPP mux max sub- PPPLNK. Network plan Set this parameter
frame length MAXSFLEN (negotiation based on the network
PPP mux max mux- PPPLNK. Network plan only if the
frame length MAXMFLEN (negotiation PPPLNK.PPPMUX
PPP mux framing PPPLNK. Network plan ENABLE(Enable).
out-time[us] MUXTIME (negotiation
required)
Head compress PPPLNK.IPHC Network plan Set this parameter

required) plan.
Protocol field PPPLNK.PFC Network plan Set this parameter

compress (negotiation based on the network
required) plan.

Field Compress (negotiation based on the network
required) plan.
PPP MUX for an MLPPP Group
PPP MUX for an MLPPP group. The subrack number and slot number of the MLPPP group
must be the same as those of the board where the group is located.
MP type MPGRP.MPTYPE Network plan Set this parameter

required) plan.
MP/MC list head MPGRP.MHF Network plan Set this parameter

option (negotiation based on the network
required) plan.

SingleRAN
MC PRI number MPGRP. Network plan Set this parameter

MCCLASS (negotiation based on the network
only if the
MPGRP.MPTYPE
parameter is set to
MCPPP.
PPP mux MPGRP.PPPMUX Network plan Set this parameter to

must be consistent
peer end.
PPP mux max sub- MPGRP. Network plan Set this parameter
frame length MAXSFLEN (negotiation based on the network
PPP mux max mux- MPGRP. Network plan only if the
frame length MAXMFLEN (negotiation MPGRP.PPPMUX
PPP mux framing MPGRP. Network plan ENABLE(Enable).
required)
Head compress MPGRP.IPHC Network plan Set this parameter

required) plan.
Protocol field MPGRP.PFC Network plan Set this parameter

required) plan.
Address and Control MPGRP.ACFC Network plan Set this parameter

required) plan.
PPP MUX for an MLPPP link in an MLPPP group. Before adding an MLPPP link to a specific
MLPPP group, ensure that the MLPPP group has been configured. The subrack number and slot
number of an E1/T1 port must be the same as those of the board where the port is located.

SingleRAN
MP Group No. MPLNK.MPGRPN Network plan Each MLPPP group

PPP sub-link No. MPLNK. Network plan Each MLPPP link in

link number.
Bearing time slot MPLNK. Network plan Set this parameter

TSBITMAP (negotiation based on the network
required) plan.
Sub-protocol MPLNK. Network plan Retain the default

negotiate out time[S] RESTARTTMR (negotiation value.
required)
Keep-alive timer MPLNK. Network plan Retain the default

length[S] KEEPALIVE (negotiation value.
required)
CRC check mode MPLNK.FCSTYPE Network plan Retain the default

(negotiation value.
required)
8.4.5.3 Activation

See "Using MML Commands" in section 8.4.4.3.1 Using MML Commands.

ADD PPPLNK: SRN=0, SN=21, BRDTYPE=POUc, PPPLNKN=0, DS1=0,
TSBITMAP=TS1-1&TS2-1&TS3-1&TS4-1&TS5-1&TS6-1&TS7-1&TS8-1&TS9-1&TS10-1&TS11-1&TS12-
1&TS13-1&TS14-1&TS15-1&TS16-1&TS17-1&TS18-1&TS19-1&TS20-1&TS21-1&TS22-1&TS23-1&TS2
4-1&TS25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1, BORROWDEVIP=NO,
LOCALIP="192.168.20.75", MASK="255.255.255.0", PEERIP="192.168.20.3",
PPPMUX=Enable, AUTHTYPE=NO_V, FLOWCTRLSWITCH=ON, ERRDETECTSW=OFF, OPSEPFLAG=OFF;

ADD MPGRP: SRN=0, SN=21, BRDTYPE=POUc, MPGRPN=0, MPTYPE=MCPPP, BORROWDEVIP=NO,
LOCALIP="192.168.20.75", MASK="255.255.255.0", PEERIP="192.168.20.3", MHF=LONG,
PPPMUX=Enable, FLOWCTRLSWITCH=ON, AUTHTYPE=NO_V, ERRDETECTSW=OFF, ANTIERRFLAG=OFF,
OPSEPFLAG=OFF;
ADD MPLNK: SRN=0, SN=21, BRDTYPE=POUc, MPGRPN=0, PPPLNKN=0, DS1=0,
4-1&TS25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1;

SingleRAN

NOTE
When configuring PPP MUX on the CME, perform a single configuration first, and then perform a batch
Guide.
----End

Name ID ble in CME
Batch
Modificati
on
1 PPPLNK BSC/RNC Subrack No. SRN No
Slot No. SN
Board type BRDTYPE
Logic LGCAPPTY
function type PE
PPP link No. PPPLNKN
E1T1 port DS1

No.
Bearing time TSBITMAP

slot
Borrow BORROWD
DevIP EVIP
Local IP LOCALIP
address
Borrowed DEVIP
device IP
address

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Subnet mask MASK
Peer IP PEERIP
address
Head IPHC
compress
Protocol PFC
field
compress
Address and ACFC

Control Field
Compressio
n
PPP mux PPPMUX
PPP mux MAXSFLE

max sub- N
frame length
PPP mux MAXMFLE

max mux- N
frame length
PPP mux MUXTIME

framing out-
time[us]
Validate AUTHTYP
protocol type E
Validate AUTHMOD
mode E
Validate user AUTHNAM

name E
Validate AUTHPWD
password
Sub-protocol RESTARTT
negotiate out MR
time[S]

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Keep-alive KEEPALIV
timer length E
[S]
Flow control FLOWCTR

switch LSWITCH
OAM flow OAMFLOW

min BW
bandwidth
[%]
Flow control FCINDEX

parameter
index
CRC check FCSTYPE

mode
TRM load TRMLOAD

threshold THINDEX
index
Error-frame ERRDETE
detect switch CTSW
Error-frame ERRALAR
alarm MTHD
threshold
Operator OPSEPFLA
Separated G
Flag
Operator OPSEPIND
Separated EX
Index
Function REMARK
Description
1 MPGRP BSC/RNC Subrack No. SRN
Slot No. SN
Board type BRDTYPE
Logic LGCAPPTY
function type PE

SingleRAN

Name ID ble in CME
Batch
Modificati
on
MP Group MPGRPN
No.
MP type MPTYPE
Borrow BORROWD
DevIP EVIP
Local IP LOCALIP
address
Borrowed DEVIP
device IP
address
Subnet mask MASK
Peer IP PEERIP
address
MP/MC list MHF

head option
MC PRI MCCLASS
number
MP flake FRAGSIZE
size
Head IPHC
compress
Protocol PFC
field
compress
Address and ACFC

Control Field
Compress
PPP mux PPPMUX
PPP mux MAXSFLE

max sub- N
frame length
PPP mux MAXMFLE

max mux- N
frame length

SingleRAN

Name ID ble in CME
Batch
Modificati
on
PPP mux MUXTIME

framing out-
time[us]
Flow control FLOWCTR

switch LSWITCH
Flow control FCINDEX

parameter
index
OAM flow OAMFLOW

min BW
bandwidth
[%]
Validate AUTHTYP
protocol type E
Validate AUTHMOD
mode E
Validate user AUTHNAM

name E
Validate AUTHPWD
password
TRM load TRMLOAD

threshold THINDEX
index
Error-frame ERRDETE
detect switch CTSW
Error-frame ERRALAR
alarm MTHD
threshold
E1T1 anti- ANTIERRF

error switch LAG
Error emit EMITTHD

threshold
Error clear CLEARTH

threshold D

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Operator OPSEPFLA
Separated G
Flag
Operator OPSEPIND
Separated EX
Index
Function REMARK
Description
2 MPLNK BSC/RNC Subrack No. SRN
Slot No. SN
Board type BRDTYPE
MP Group MPGRPN
No.
PPP sub-link PPPLNKN

No.
E1T1 port DS1

No.

slot
negotiate out MR
time[S]
Keep-alive KEEPALIV
timer length E
[S]
CRC check FCSTYPE

mode

See 8.4.4.4 Activation Observation.
N/A

SingleRAN

None

None
None
8.5 IPHC
This section describes engineering guidelines for IPHC.
8.5.1 When to Use IPHC

Before using IPHC, you must ensure that the base station is configured with the E1/T1 port.
IPHC is recommended if IP headers are required to be compressed to reduce transmission

overhead.
Abis IPHC applies to the following scenarios:
l In scenarios where E1 resources are insufficient, use the following functions or features in
order of priority to save transmission resources: VAD, Abis MUX, Abis IPHC, and local
switching. If bandwidth requirements still cannot be met after VAD or Abis MUX is used,
use Abis IPHC.
NOTE
Use of the local switching function must be permitted by the operator because the function involves lawful
interception.
l High-BER scenarios, such as microwave transmission on BSCs in a desert. The
instantaneous BER may be larger than 1e-6 due to large temperature differences during a
day and a harsh environment. In these scenarios, it is recommended that IPHC be enabled
to improve transmission efficiency instead of Abis MUX. This is because Abis MUX
increases the datagram size, and therefore increases the packet loss rate. As a result, speech
quality deteriorates in high-BER scenarios. Unlike Abis MUX, IPHC reduces datagram
size, and therefore decreases the packet loss rate. As a result, speech quality improves.
l When TDM transmission is converted to IP over E1 transmission or IP over E1 transmission
is deployed, the bandwidth is limited. In this scenario, it is recommended that IPHC be
enabled to improve transmission efficiency. Abis MUX can be enabled together with IPHC,
this further improves transmission efficiency by about 5%.
l In scenarios where BTSs are cascaded in IP over E1 mode and transmission bandwidth
between BTSs is limited, perform IPHC on the MP/PPP links between the BTSs.
Iub IPHC applies to the following scenarios:
l E1 resources are insufficient.

l High-BER scenarios, such as microwave transmission on RNCs in a desert. The
instantaneous BER may be larger than 1e-6 due to large temperature differences during a

SingleRAN
day and a harsh environment. In these scenarios, it is recommended that IPHC be enabled
to improve transmission efficiency instead of FP MUX. This is because FP MUX increases
the datagram size, and therefore increases the packet loss rate. As a result, speech quality
deteriorates in high-BER scenarios. Unlike FP MUX, IPHC reduces datagram size, and
therefore decreases the packet loss rate. As a result, speech quality improves.
l In scenarios where NodeBs are cascaded in IP over E1 mode and transmission bandwidth
between NodeBs is limited, perform IPHC on the MP/PPP links between the NodeBs.

l If both the BSC and BTS use IP over E1/T1 transmission, the BSC and the BTS must
support the Abis IPHC feature.
l If the BTS uses IP over E1/T1 transmission, the BSC uses IP over Ethernet transmission,
and the BSC and BTS are connected using a router, the router and the BTS must support
the Abis IPHC feature.
NOTE
The BTS allows compression of non-TCP packets (UDP packets). It does not allow compression of TCP
and non-TCP packets simultaneously and compression of RTP packets. When the BTS is interconnected
to a router, the router allows compression of only non-TCP packets (UDP packets).
Collect information about the BTS traffic model and Abis link bandwidth to determine whether
to enable this feature based on the formula for calculating bandwidth. This is because this feature
is used only if bandwidth requirements still cannot be met after VAD or Abis MUX is used.
8.5.3 Planning
8.5.3.1 RF Planning
None

IP over E1/T1 is applied to devices at the two ends where IPHC is used.
Transmission bandwidth must be correctly planned.
The Abis IPHC feature applies to the following networking scenarios:
l IP over E1 end-to-end scenario: The BTS negotiates IPHC parameters with the BSC. IPHC
is enabled on both the BTS and the BSC to perform bidirectional compression.
Figure 8-2 IP over E1 end-to-end scenario
l IP over FE/GE transmission from the BSC to a router and IP over E1 transmission from
the router to the BTS: The BTS negotiates IPHC parameters with the router. The router

SingleRAN
supports UDP datagram header compression implemented by IPHC. This saves

transmission resources between the BTS and the router.
Figure 8-3 Conversion from IP over E1 to IP over FE/GE
l BTS cascading in IP over E1 mode: Cascaded BTSs perform IPHC compression and
decompression on datagram flows and passerby datagram flows.
Figure 8-4 BTS cascading in IP over E1 mode
The UMTS networking scenarios are the same as GSM networking scenarios.

l LTE hardware planning
IPHC.
l GSM hardware planning
BSC:
If both the BSC and BTS use IP over E1/T1 transmission, the BSC6900/BSC6910 must
be configured with a POUc board.
NOTE
The PEU board on the BSC does not support the Abis IPHC feature.
If the BTS uses IP over E1/T1 transmission, the BSC uses IP over Ethernet transmission,
and the BSC and BTS are connected using a router, the BSC must be configured with
the boards listed in the following table.
NE Required Board


l GOUc or GOUd
l EXOUa

SingleRAN
BTS:
l The GTMUb board must be configured on 3900 series base stations except BTS3900B and
BTS3900E.
l The DPTU board must be configured on the BTS3012 and BTS3012AE.
The router must support IPHC.
l UMTS hardware planning

RNC:
The BSC6900 must be configured with the following boards.
Scenario Required Board
IPHC for a PPP link l PEUa or PEUc

l POUa or POUc
l UOIa
IPHC for an MLPPP group l PEUa or PEUc

l POUa or POUc
NodeB:
8.5.4 Deployment on the eNodeB/NodeB/eGBTS
Transmission equipment connected to the eNodeB/NodeB/eGBTS supports E1/T1 ports along
with IPHC.
The license controlling this feature has been activated. For details on how to activate the license,
see License Management Feature Parameter Description. For details about license items, see
License Control Item Description.
If the base station connects to a router in IP over E1 mode, the router must support IPHC.


SingleRAN
Required Data
None
IPHC for a PPP Link
IPHC for a PPP link. The cabinet number, subrack number, and slot number of the PPP link
must be the same as those of the board where the link is located. If a UMPT is used for
Link No. PPPLNK. Network plan Each PPP link must

PPPLNKN (negotiation have a unique link
required) number.
Port No. PPPLNK.PN Network plan Set this parameter

(negotiation based on the actual
required) connection and the
peer configuration.
Authentication Type PPPLNK.AUTH Network plan Set this parameter to

(negotiation be consistent with the
required) setting of the peer
end.
User Name PPPLNK.UN Network plan These parameters are

(negotiation valid only if the
required) PPPLNK.AUTH
parameter is not set
Password PPPLNK.PWD Network plan to NONAUTH(No
(negotiation Authentication). Set
required) these parameters to
setting of the peer
end.
Time Slot No. PPPLNK.TSN Network plan Set this parameter to

end.
Local IP PPPLNK. Network plan Set this parameter

LOCALIP (negotiation based on the network
required) plan.
Mask PPPLNK.IPMASK Network plan Set this parameter

required) plan.

SingleRAN
Peer IP PPPLNK.PEERIP Network plan Set this parameter

required) plan.
PPPMUX PPPLNK.MUXCP Network plan Retain the default

(negotiation value DISABLE
required) (Disable). Set this
parameter to be
consistent with the
setting of the peer
end.
IP Header PPPLNK.IPHC Network plan Set this parameter to

Compression (negotiation ENABLE(Enable).
must be consistent
peer end.
IPHC SubOption PPPLNK. Network plan Set this parameter if

IPHCSUBOPT (negotiation the peer device needs
required) to negotiate about the
setting of this
parameter with the
local device.
Maximum Receive PPPLNK.MRU Network plan Set this parameter

required) plan.
Protocol Field PPPLNK.PFC Network plan Set this parameter

required) plan. Set this
parameter to be
consistent with the
setting of the peer
end.

parameter to be
consistent with the
setting of the peer
end.
IPHC for an MLPPP Group

IPHC for an MLPPP group. The cabinet number, subrack number, and slot number of the MLPPP

SingleRAN
group must be the same as those of the board where the group is located. If a UMPT is used for
Group No. MPGRP.MPGRPN Network plan Each MLPPP group

Authentication Type MPGRP.AUTH Network plan Set this parameter to

end.
User Name MPGRP.UN Network plan These parameters are

required) MPGRP.AUTH
Password MPGRP.PWD Network plan to NONAUTH(No
setting of the peer
end.
Local IP MPGRP.LOCALIP Network plan Set this parameter

required) plan.
Mask MPGRP.IPMASK Network plan Set this parameter

required) plan.
Peer IP MPGRP.PEERIP Network plan Set this parameter

required) plan.
MLPPP Fragment MPGRP. Network plan Set this parameter

Size FRAGSIZE (negotiation based on the network
required) plan.
PPPMUX MPGRP.MUXCP Network plan Set this parameter to

(negotiation DISABLE
setting of the peer
end.

SingleRAN
IP Header MPGRP.IPHC Network plan Set this parameter to

must be consistent
peer end.
IPHC SubOption MPGRP. Network plan Set this parameter if

IPHCSUBOPT (negotiation the peer device needs
required) to negotiate about the
setting of this
parameter with the
local device.
Multi-Class PPP MPGRP.MCPPP Network plan Set this parameter to

must be consistent
peer end.
IPHC for an MLPPP link in an MLPPP group. Before adding an MLPPP link to a specific MLPPP
group, ensure that the MLPPP group has been configured. The cabinet number, subrack number,
and slot number of an E1/T1 port must be the same as those of the board where the port is located.
If a UMPT is used for transmission, set the subboard types of the MLPPP link, MLPPP group,
and E1/T1 port to BASE_BOARD(Base Board).

link number.


required) plan.

required) plan.

SingleRAN

setting of the peer
end.

setting of the peer
end.

required)
8.5.4.3 Activation
For newly deployed base stations

l IPHC for a PPP link
Run the ADD PPPLNK command to configure IPHC for a PPP link.
l IPHC for an MLPPP group
Step 1 Run the ADD MPGRP command to configure IPHC for an MLPPP group.
----End
For existing base stations
NOTICE
Setting the IPHC parameter in this step will cause the base station to re-initiate a negotiation
with the base station controller or router to establish a PPP link or an MLPPP group. The
negotiation may cause mute voices or interrupt data transmission for less than 3s.

SingleRAN
Run the MOD PPPLNK or MOD MPGRP command with IPHC set to ENABLE(Enable). Set
IPHCSUBOPT to ENABLE(Enable) if the peer device needs to negotiate about the setting of
this parameter with the local device.

ADD PPPLNK: CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PPPLNKN=0, PN=0, AUTH=NONAUTH,
S25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1, LOCALIP="192.168.20.3",
IPMASK="255.255.255.0", MUXCP=DISABLE, IPHC=ENABLE;

LOCALIP="10.10.10.10", IPMASK="255.255.255.0", MUXCP=DISABLE, IPHC=ENABLE,
MCPPP=ENABLE, MHO=LONG;
ADD MPLNK: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, PPPLNKN=0, MPGRPN=0, E1T1SRN=0,
E1T1SN=7, E1T1SBT=BASE_BOARD, E1T1PN=0,
S25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1;

MOD PPPLNK: CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PPPLNKN=0, PN=0, IPHC=ENABLE;

MOD MPGRP: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, MPGRPN=0, IPHC=ENABLE;
Batches", "Creating NodeBs in Batches", and "Creating Co-MPT Base Stations in Batches" in
the initial configuration guide for the eNodeB, NodeB, and eGBTS, respectively.
parameters.

SingleRAN
Table 8-19 Parameters for IPHC

Summary Data
File
PPPLNK User-defined sheet Subrack No./ None

eNodeB/NodeB/ Cabinet No./
eGBTS Transport Subboard Type/
Data is Slot No./PPP Link
recommended. No./Port No.
Authentication
Type/Password/
User Name/Time
Slot No./Local IP/
Mask/Peer IP/
PPPMUX/
Maximum Length
of PPP Mux
Subframe (byte)/
Maximum Length
of PPP Muxframe
(byte)/PPP
Muxframe
Combination
Timeout(ms)/IP
Header
Compression/
Maximum Receive
Unit(byte)/
Negotiation Time
(ms)/Protocol Field
Compression/
Address and
Control Field
Compression/PPP
Fault Frame
Occurrence
Threshold(per
mill)/PPP Fault
Frame Clear
Threshold(per mill)

SingleRAN

Summary Data
File
MPGRP User-defined sheet Subrack No./ None

Transport Data is Cabinet No./
recommended. Subboard Type/
Slot No./MLPPP
Group No./Multi-
Class PPP/
Authentication
Type/User Name/
Password/Local IP/
Mask/Peer IP/MP/
MC Header Option/
PPPMUX/MLPPP
Fragment Size
(byte)/PPP Mux
Subframe Max
Length(byte)/PPP
Muxframe Max
Length(byte)/
PPPMUX Combine
Timeout(ms)/
MCPPP Class/IP
Header
Compression/
MLPPP Packets
Discard Alarm
Appear Threshold
(per mill)/MLPPP
Packets Discard
Alarm Disappear
Threshold(per mill)

SingleRAN

Summary Data
File
MPLNK User-defined sheet Cabinet No./ None

Transport Data is Subrack No./Slot
recommended. No./Subboard
Type/Link No./
MLPPP Group
Subboard Type/
MLPPP Group No./
E1/T1 Subrack No./
E1/T1 Slot No./E1/
T1 Subboard Type/
E1/T1 Port No./
Timeslot No./
Maximum Receive
Unit/Protocol Field
Compression/
Address and
Control Field
Compression/
Negotiation Time
NOTE
Step 2 Choose CME > LTE Application/UMTS Application > Export Data > Export Base Station
Bulk Configuration Data (U2000 client mode), or choose LTE Application/UMTS
Application > Export Data > Export Base Station Bulk Configuration Data (CME client
mode), to export the base station data stored on the CME into the customized summary data file.
Step 4 Choose CME > LTE Application/UMTS Application > Import Data > Import Base Station
Bulk Configuration Data (U2000 client mode), or choose LTE Application/UMTS
Application > Import Data > Import Base Station Bulk Configuration Data (CME client
mode), to import the summary data file into the CME, and then start the data verification.

SingleRAN
----End

NOTE
hide this area.

SingleRAN
----End

Step 1 Check the activation status.
Status is UP(Up), IPHC has been activated.
Run the DSP MPGRP command, and then check the command output. If the value of
MLPPP Group Status is UP(Up), IPHC has been activated.
Step 2 Observe the transmit flow during a call.

l If the BSC and the BTS are connected using PPP or MP links, monitor the transmit flow by
configuring Realtime Bandwidth. For details, see "Monitoring Transmission Resources" in
BSC6900 LMT User Guide or BSC6910 LMT User Guide.
l If the BSC and the BTS are connected using a router, obtain the transmit flow from the
transmission device.
Expected result: When the traffic volume is constant, the transmit flow when IPHC is set to
ENABLE(ENABLE) is less than the transmit flow when IPHC is set to DISABLE
(DISABLE).
----End

Run the MOD PPPLNK or MOD MPGRP command with IPHC set to DISABLE(Disable).

MOD PPPLNK: CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PPPLNKN=0, PN=0, IPHC=DISABLE;

MOD MPGRP: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, MPGRPN=0, IPHC=DISABLE;

NOTE
When configuring IPHC on the CME, perform a single configuration first, and then perform a batch

SingleRAN
Guide.
----End

Name ID ble in CME
Batch
Modificati
on
1 PPPLNK eNodeB/ IP Header IPHC Yes

NodeB/ Compressio
eGBTS n
MPGRP eNodeB/ IP Header IPHC Yes

NodeB/ Compressio
eGBTS n
8.5.5 Deployment on the GBTS
l Transmission equipment connected to the GBTS supports E1/T1 ports along with IPHC.
l The license controlling this feature has been activated. For details on how to activate the
license, see License Management Feature Parameter Description. For details about license
items, see License Control Item Description.
l If the base station connects to a router in IP over E1 mode, the router must support IPHC.


SingleRAN
Required Data
None
Table 8-21 Data to prepare before activating Abis IPCH (GBTS side) (related MOs:
BTSPPPLNK and BTSMPGRP)
IP Header BTSPPPLNK. Network plan Set this parameter to

Compression IPHC (negotiation ENABLE(Enable).
required) Set this parameter to
setting of the peer
end.
IP Header BTSMPGRP.IPHC Network plan Set this parameter to

required) Set this parameter to
setting of the peer
end.
8.5.5.3 Activation

Run the ADD BTSPPPLNK command to configure IPHC for a PPP link.
Step 1 Run the ADD BTSMPGRP command to configure IPHC for an MLPPP group.
Step 2 Run the ADD BTSMPLNK command to add an MLPPP link to the MLPPP group.
----End

SingleRAN
NOTICE
Run the ADD BTSPPPLNK or ADD BTSMPGRP command with IPHC set to ENABLE
(Enable).

ADD BTSPPPLNK: IDTYPE=BYID, BTSID=200, PPPLNKN=0, IPHC=ENABLE;

ADD BTSMPGRP: IDTYPE=BYID, BTSID=200, MPGRPN=0, IPHC=ENABLE;

MOD BTSPPPLNK: IDTYPE=BYID, BTSID=200, PPPLNKN=0, IPHC=ENABLE;

MOD BTSMPGRP: IDTYPE=BYID, BTSID=200, MPGRPN=0, IPHC=ENABLE;
NOTE
Set parameters on the CME according to the operation sequence in Table 8-22 through Table
----End

SingleRAN

Name ID ble in CME
Batch
Modificati
on
1 PPPLNK BSC6900/ Head IPHC No

BSC6910 compress
MPGRP BSC6900/ Head IPHC No

BSC6910 compress

Name ID ble in CME
Batch
Modificati
on
1 BTSPPPLN BSC6900/ IP Header IPHC No

K BSC6910 Compressio
n
BTSMPGRP BSC6900/ IP Header IPHC No

BSC6910 Compressio
n

Name ID ble in CME
Batch
Modificati
on
1 PPPLNK eGBTS IP Header IPHC Yes

Compressio
n

SingleRAN

Name ID ble in CME
Batch
Modificati
on
PPPLNK eGBTS IPHC IPHCSUBO Yes

NOTE SubOption PT
Set IPHC
SubOption
if the peer
device needs
to negotiate
about the
setting of
this
parameter
with the
local device.
MPGRP eGBTS IP Header IPHC Yes

Compressio
n
MPGRP eGBTS IPHC IPHCSUBO Yes

NOTE SubOption PT
Set IPHC
SubOption
if the peer
device needs
to negotiate
about the
setting of
this
parameter
with the
local device.

Step 1 Run the BSC MML command DSP BTSPPPLNK or DSP BTSMPGRP, and then check the
command output.
Expected result: The value of IPHC Negotiation Result reported by the BTS is ENABLE.


SingleRAN
(DISABLE).
----End

Run the MOD BTSPPPLNK or MOD BTSMPGRP command with IPHC set to DISABLE
(Disable).

MOD BTSPPPLNK: IDTYPE=BYID, BTSID=200, PPPLNKN=0, IPHC= DISABLE;

MOD BTSMPGRP: IDTYPE=BYID, BTSID=200, MPGRPN=0, IPHC= DISABLE;

NOTE
Guide.
----End

Name ID ble in CME
Batch
Modificati
on
1 BTSPPPLN BSC6900/ IP Header IPHC No

K BSC6910 Compressio
n

SingleRAN

Name ID ble in CME
Batch
Modificati
on
BTSMPGRP BSC6900/ IP Header IPHC No

BSC6910 Compressio
n
Transmission equipment connected to the base station controller supports E1/T1 ports along
with IPHC.

Required Data
None
IPHC for a PPP Link
IPHC for a PPP link. The subrack number and slot number of the PPP link must be the same as
those of the board where the link is located.
PPP link No. PPPLNK. Network plan Each PPP link must
required) number.

SingleRAN
E1T1 port No. PPPLNK.DS1 Network plan Set this parameter

peer configuration.
Bearing time slot PPPLNK. Network plan Set this parameter to

TSBITMAP (negotiation be consistent with the
end.
Borrow DevIP PPPLNK. Network plan Set this parameter

BORROWDEVIP (negotiation based on the network
required) plan.
Borrowed device IP PPPLNK.DEVIP Network plan This parameter is

address (negotiation valid only if the
required) PPPLNK.BORRO
WDEVIP parameter
is not set to YES
(YES).
Local IP address PPPLNK. Network plan Set this parameter

required) plan.
Subnet mask PPPLNK. MASK Network plan Set this parameter

required) plan.
Peer IP address PPPLNK.PEERIP Network plan Set this parameter

required) plan.
Head compress PPPLNK.IPHC Network plan Set this parameter to

(negotiation UDP/IP_HC(UDP/
required) IP_HC) or RTP/
UDP/IP_HC(RTP/
UDP/IP_HC). This
setting of the peer
end.
Protocol field PPPLNK.PFC Network plan Set this parameter

parameter to be
consistent with the
setting of the peer
end.

SingleRAN

parameter to be
consistent with the
setting of the peer
end.
PPP mux PPPLNK.PPPMUX Network plan Retain the default

parameter to be
consistent with the
setting of the peer
end.
Validate protocol PPPLNK. Network plan Set this parameter to

type AUTHTYPE (negotiation be consistent with the
end.
Validate user name PPPLNK. Network plan These parameters are

AUTHNAME (negotiation valid only if the
required) PPPLNK.AUTHNA
ME parameter is not
Validate password PPPLNK. Network plan set to NO_V
AUTHPWD (negotiation (NO_V). Set this
required) parameter to be
Validate mode PPPLNK. Network plan consistent with the
AUTHMODE (negotiation setting of the peer
required) end.
IPHC for an MLPPP Group
IPHC for an MLPPP group. The subrack number and slot number of the MLPPP group must be
the same as those of the board where the group is located.
MP Group No. MPGRP.MPGRPN Network plan Set this parameter

required) plan.

SingleRAN

required) plan. This parameter
value must be
consistent with the
setting of the peer
end.
Borrow DevIP MPGRP. Network plan Set this parameter

required) plan.
Borrowed device IP MPGRP.DEVIP Network plan This parameter is

required) MPGRP.BORROW
DEVIP parameter is
not set to YES
(YES).
Local IP address MPGRP.LOCALIP Network plan Set this parameter

required) plan.
Subnet mask MPGRP.MASK Network plan Set this parameter

required) plan.
MP/MC list head MPGRP.MHO Network plan Set this parameter

required) plan.
MC PRI number MPGRP. Network plan This parameter is

MCCLASS (negotiation valid only if the
required) MPGRP.MPTYPE
parameter is set to
MCPPP.
Head compress MPGRP.IPHC Network plan Set this parameter to

(negotiation UDP/IP_HC(UDP/
required) IP_HC) or RTP/
UDP/IP_HC(RTP/
UDP/IP_HC). This
setting of the peer
end.

SingleRAN

parameter to be
consistent with the
setting of the peer
end.

parameter to be
consistent with the
setting of the peer
end.
PPP mux MPGRP.PPPMUX Network plan Set this parameter

parameter to be
consistent with the
setting of the peer
end.
PPP mux max sub- MPGRP. Network plan These parameters are
frame length MAXSFLEN (negotiation valid only if the
required) MPGRP.PPPMUX
parameter is set to
PPP mux max mux- MPGRP. Network plan ENABLE(Enable).
frame length MAXMFLEN (negotiation Set this parameter
required) based on the network
PPP mux framing MPGRP. Network plan plan.
required)
IPHC for an MLPPP link in an MLPPP group. Before adding an MLPPP link to a specific MLPPP
group, ensure that the MLPPP group has been configured. The subrack number and slot number
of an E1/T1 port must be the same as those of the board where the port is located.


SingleRAN

link number.
E1T1 port No. MPLNK.DS1 Network plan Set this parameter

peer configuration.
Bearing time slot MPLNK. Network plan Set this parameter to

end.
CRC check mode MPLNK.FCSTYPE Network plan Set this parameter

required) plan.
8.5.6.3 Activation
For newly deployed base station controllers

Run the ADD PPPLNK command to configure IPHC for a PPP link.
Step 1 Run the ADD MPGRP command to configure IPHC for an MLPPP group.
----End
NOTE
If the BSC works in IP over FE/GE mode:

l Enable the IPHC function for the routers and then for the BTSs.
l Do not enable the IPHC function for the BSC.
l Enable the routers to support the IPHC function only for User Datagram Protocol (UDP) packet headers.

SingleRAN
For existing base station controllers
NOTICE
Run the MOD PPPLNK or MOD MPGRP command with Subrack No. and Slot No. be set
to the subrack and slot where the POUc board islocated and Head Compress be set to UDP/
IP_HC(UDP/IP_HC).
NOTE
If the BSC works in IP over FE/GE mode:

l Enable the IPHC function for the routers and then for the BTSs.
l Do not enable the IPHC function for the BSC.
l Enable the routers to support the IPHC function only for UDP packet headers.
For newly deployed base station controllers

ADD PPPLNK: SRN=0, SN=26, BRDTYPE=POUc, PPPLNKN=0, IPHC=UDP/IPHC;

ADD MPGRP: SRN=0, SN=26, BRDTYPE=POUc, MPGRPN=0, IPHC=UDP/IP_HC;
For existing base station controllers

MOD PPPLNK: SRN=0, SN=26, BRDTYPE=POUc, PPPLNKN=0, IPHC=UDP/IP_HC;

MOD MPGRP: SRN=0, SN=26, BRDTYPE=POUc, MPGRPN=0, IPHC=UDP/IP_HC;

NOTE
Set parameters on the CME according to the operation sequence in Table 8-26 and Table

SingleRAN
----End

Name ID ble in CME
Batch
Modificati
on
1 PPPLNK RNC PPP link No. PPPLNK. No

PPPLNKN
E1T1 port PPPLNK.

No. DS1
Bearing time PPPLNK.

slot TSBITMAP
Borrow PPPLNK.
DevIP BORROWD
EVIP
Borrowed PPPLNK.
device IP DEVIP
address
Local IP PPPLNK.
address LOCALIP
Subnet mask PPPLNK.

MASK
Peer IP PPPLNK.
address PEERIP
Head PPPLNK.
compress IPHC
Protocol PPPLNK.
field PFC
compress
Address and PPPLNK.

Control Field ACFC
Compress
PPP mux PPPLNK.

PPPMUX

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Validate PPPLNK.
protocol type AUTHTYP
E
Validate user PPPLNK.

name AUTHNAM
E
Validate PPPLNK.
password AUTHPWD
Validate PPPLNK.
mode AUTHMOD
E

Name ID ble in CME
Batch
Modificati
on
1 MPGRP RNC MP Group MPGRP. No

No. MPGRPN
MP type MPGRP.
MPTYPE
Borrow MPGRP.
DevIP BORROWD
EVIP
Borrowed MPGRP.
device IP DEVIP
address
Local IP MPGRP.
address LOCALIP
Subnet mask MPGRP.

MASK
MP/MC list MPGRP.

head option MHO

SingleRAN

Name ID ble in CME
Batch
Modificati
on
MC PRI MPGRP.
number MCCLASS
Head MPGRP.
compress IPHC
Protocol MPGRP.
field PFC
compress
Address and MPGRP.

Control Field ACFC
Compress
PPP mux MPGRP.

PPPMUX
PPP mux MPGRP.

max sub- MAXSFLE
frame length N
PPP mux MPGRP.

max mux- MAXMFLE
frame length N
PPP mux MPGRP.

framing out- MUXTIME
time[us]
2 MPLNK RNC MP Group MPLNK. No

No. MPGRPN
PPP sub-link MPLNK.

No. PPPLNKN
E1T1 port MPLNK.

No. DS1
Bearing time MPLNK.

slot TSBITMAP
CRC check MPLNK.

mode FCSTYPE

Step 1 Run the DSP PPPLNK or DSP MPGRP command, and then check the command output.

SingleRAN
Expected result: The value of IPHC Negotiation Result reported by the BTS is ENABLE.

(DISABLE).
----End

Run the MOD PPPLNK or MOD MPGRP command with Subrack No. and Slot No. be set
to the subrack and slot where the POUc board islocated and Head Compress be set to No_HC
(No_HC).

MOD PPPLNK: SRN=0, SN=26, BRDTYPE=POUc, PPPLNKN=0, IPHC=No_HC;

MOD MPGRP: SRN=0, SN=26, BRDTYPE=POUc, MPGRPN=0, IPHC=No_HC;
NOTE
Guide.
----End

SingleRAN

Name ID ble in CME
Batch
Modificati
on
1 PPPLNK BSC6900/ IP Header IPHC No

BSC6910 Compressio
n
MPGRP BSC6900/ IP Header IPHC No

BSC6910 Compressio
n

None

None
Abis IPHC is based on PPP. If Abis IPHC negotiation fails, link connectivity and performance
are not affected, but transmission bandwidth cannot be saved.
Possible faults may occur in the following scenarios:
Both the BSC and BTS Use IP over E1/T1 Transmission.

The following figure shows a network on which the BTC and BTS use IP over E1/T1
transmission.
Figure 8-6 The BSC and BTS using IP over E1/T1 transmission
l During PPP/MP initial negotiation, perform the following operations:
Step 1 On the BSC LMT, run the DSP PPPLNK or DSP MPGRP command to check whether the
IPHC negotiation is successful.

SingleRAN
Expected result: The Code compress type value is non-TCP code. This indicates that the
negotiation is successful.
Step 2 For the GBTS, run the DSP BTSPPPLNK or DSP BTSMPGRP command on the BSC LMT
to check whether the IPHC negotiation is successful.
Expected result: The IPHC Negotiation Result value is Enabled. This indicates that the
negotiation is successful.
Step 3 For the eGBTS, run the DSP PPPLNK or DSP MPGRP command on the BTS LMT to check
whether the IPHC negotiation is successful.
Expected result: The value of IPHC Negotiation Result is ENABLE(Enable). This indicates
that the negotiation is successful.
Step 4 On the BSC LMT, run the DSP PPPLNK or DSP MPGRP command to check whether the
IPHC negotiation parameters are configured correctly.
Expected result:
l Max CID for non-TCP Compression: negotiated value (default value: 767)
l Max quantity of code sent Continuous: 256
l Max space time of sending full head code: 1
l Size of max head which can be compressed: 28
If the negotiation fails, change the configuration on the BSC or the BTS to ensure that the
parameters are configured correctly. If the negotiation still fails, contact Huawei technical
support engineers.
----End
l After PPP/MP/IPHC negotiation, run the DSP PPPLNK or DSP MPGRP command on
the BSC LMT. In the command output, check the following information:
Number of packets sent that were not compressed
Number of IPV4/UDP compressed header packets which compressed successfully by
sender
Number of IPV4/UDP full header packets sent by sender
sender
Number of IPV6/UDP full header packets sent by sender
Number of IPV4/UDP full header packets which compressed successfully by receiver
receiver
Number of IPV6/UDP full header packets which compressed successfully by receiver
receiver
If the preceding information is not measured, contact Huawei Customer Service Center.

SingleRAN
The BTS Uses IP over E1/T1 Transmission, the BSC Uses IP over Ethernet
Transmission, and the BSC and BTS Are Connected Using a Router.
The following figure shows a network on which the BTS uses IP over E1/T1 transmission, the
BSC uses IP over Ethernet transmission, and the BSC and BTS are connected using a router.
Figure 8-7 The BTS using IP over E1/T1 transmission, the BSC using IP over Ethernet
transmission, and the BSC and BTS connected using a router
l In the PPP or MP initial negotiation phase:

For the GBTS, run the DSP BTSPPPLNK or DSP BTSMPGRP command on the BSC
LMT to check whether the IPHC negotiation is successful.
Expected result: The IPHC Negotiation Result value is Enabled. This indicates that
the negotiation is successful.
For the eGBTS, run the DSP PPPLNK or DSP MPGRP command on the BTS LMT
to check whether the IPHC negotiation is successful.
Expected result: The value of IPHC Negotiation Result is ENABLE(Enable). This
indicates that the negotiation is successful.
If the negotiation fails, change the configuration on the BSC, BTS, or router to ensure
that the parameters are configured correctly. If the negotiation still fails, contact Huawei
technical support engineers.
8.6 PPPHC
This section describes engineering guidelines for PPPHC. PPPHC is used to compress PPP
headers. The ACFC and PFC techniques can be used together or separately.
8.6.1 When to Use PPPHC

Before using PPPHC, you must ensure that the base station is configured with the E1/T1 port.
PPPHC is recommended if the address, control, and protocol fields in PPP headers are required
to be compressed to improve transmission efficiency.

None
8.6.3 Planning

SingleRAN
8.6.3.1 RF Planning
None

IP over E1/T1 is applied to devices at the two ends where PPPHC is used.

l Hardware planning for the LTE to enable LBFD-003004 Compression & Multiplexing over
E1/T1:
PPPHC.

PEUc, or POUc board and the BSC6910 must be configured with the POUc board.
PEUa, PEUc, or POUc board and the BSC6910 must be configured with the POUc
board.
The eGBTS must be configured with the UTRP and UMPT boards.
For the GBTS, the BTS3012 series base stations must be configured with the DPTU
boards and 3900 series base stations must be configured with the GTMUb boards.
PEUc, POUa, UOIa, or POUc board.
PEUa, PEUc, POUa, or POUc board.
The NodeB must be configured with the UTRP and UMPT/WMPT boards.
with PPPHC.


SingleRAN
Required Data
None
PPPHC for a PPP Link
PPPHC for a PPP link. The cabinet number, subrack number, and slot number of the PPP link
must be the same as those of the board where the link is located. If a UMPT is used for
Link No. PPPLNK. Network plan Each PPP link must

required) number.
Port No. PPPLNK.PN Network plan Set this parameter

peer configuration.
Authentication Type PPPLNK.AUTH Network plan Set this parameter to

end.
User Name PPPLNK.UN Network plan These parameters are

required) PPPLNK.AUTH
Password PPPLNK.PWD Network plan to NONAUTH(No
setting of the peer
end.
Time Slot No. PPPLNK.TSN Network plan Set this parameter to

end.
Local IP PPPLNK. Network plan Set this parameter

required) plan.

SingleRAN
Mask PPPLNK.IPMASK Network plan Set this parameter

required) plan.
Peer IP PPPLNK.PEERIP Network plan Set this parameter

required) plan.
PPPMUX PPPLNK.MUXCP Network plan Retain the default

parameter to be
consistent with the
setting of the peer
end.
IP Header PPPLNK.IPHC Network plan Set this parameter

parameter to be
consistent with the
setting of the peer
end.
Maximum Receive PPPLNK.MRU Network plan Set this parameter

required) plan.
Protocol Field PPPLNK.PFC Network plan Set this parameter to

must be consistent
peer end.
Address and Control PPPLNK.ACFC Network plan Set this parameter to

Field Compression (negotiation ENABLE(Enable).
must be consistent
peer end.
PPPHC for an MLPPP Group
For information about the parameters that must be set in an MPGRP MO to configure PPPHC
for an MLPPP group, see "IPHC for an MLPPP Group" in section 8.5 IPHC.
PPPHC for an MLPPP link in an MLPPP group. The cabinet number, subrack number, and slot
number of the MLPPP link must be the same as those of the board where the link is located. If

SingleRAN
a UMPT is used for transmission, set the subboard type of the MLPPP link to BASE_BOARD
(Base Board).

link number.
MLPPP Group MPLNK. Network plan Set this parameter to

Subboard Type MPGRPSBT (negotiation E1_COVERBOAR
required) D(E1 Cover Board)
or BASE_BOARD
(Base Board) based
on the actual
connection.

E1/T1 Subrack No. MPLNK.E1T1SRN Network plan Set these parameters

required) connection.
E1/T1 Slot No. MPLNK.E1T1SN Network plan

(negotiation
required)
E1/T1 Subboard MPLNK.E1T1SBT Network plan Set this parameter to

Type (negotiation E1_COVERBOAR
or BASE_BOARD
(Base Board) based
on the actual
connection.
E1/T1 Port No. MPLNK.E1T1PN Network plan Set this parameter

peer configuration.
Timeslot No. MPLNK.TSN Network plan Set this parameter to

end.

required) plan.

SingleRAN

must be consistent
peer end.

Field Compression (negotiation ENABLE(Enable).
must be consistent
peer end.
8.6.4.3 Activation

l PPPHC for a PPP link
Run the ADD PPPLNK command to configure PPPHC for a PPP link.
l PPPHC for an MLPPP group
Step 1 Run the ADD MPGRP command to configure PPPHC for an MLPPP group.
----End

ADD PPPLNK: CN=0, SRN=0, SN=6, SBT=BASE_BOARD, PPPLNKN=0, PN=0,
AUTH=NONAUTH,
TSN=TS1-1&TS2-1&TS3-1&TS4-1&TS5-1&TS6-1&TS7-1&TS8-1&TS9-1&TS10-1&
TS11-1&TS12-1&TS13-1&TS14-1&TS15-1&TS16-1&TS17-1&TS18-1&TS19-1&TS2
0-1&TS21-1&TS22-1&TS23-1&TS24-1&TS25-1&TS26-1&TS27-1&TS28-1&TS29-1
&TS30-1&TS31-1, LOCALIP="192.168.20.3", IPMASK="255.255.255.0",
PEERIP="192.168.20.75", MUXCP=ENABLE, PFC=ENABLE, ACFC=ENABLE;
ADD MPGRP: CN=0, SRN=0, SN=7, SBT=BASE_BOARD, MPGRPN=0,
AUTH=NONAUTH, LOCALIP="192.168.20.3", IPMASK="255.255.255.0",
PEERIP="192.168.20.75", MUXCP=ENABLE, IPHC=ENABLE, MCPPP=ENABLE,
MHO=LONG; ADD MPLNK: CN=0, SRN=0, SN=7, SBT=BASE_BOARD,
PPPLNKN=0, MPGRPN=0, MPGRPSBT=BASE_BOARD, E1T1SRN=0, E1T1SN=7,
E1T1SBT=BASE_BOARD, E1T1PN=0,
TSN=TS1-1&TS2-1&TS3-1&TS4-1&TS5-1&TS6-1&TS7-1&TS8-1&TS9-1&TS10-1&
TS11-1&TS12-1&TS13-1&TS14-1&TS15-1&TS16-1&TS17-1&TS18-1&TS19-1&TS2

SingleRAN
0-1&TS21-1&TS22-1&TS23-1&TS24-1&TS25-1&TS26-1&TS27-1&TS28-1&TS29-1
&TS30-1&TS31-1, PFC=ENABLE, ACFC=ENABLE;
parameters.
The PPPLNK and MPGRP MOs require user-defined templates. See 8.5.4.3.3 Using the
CME.
Table 8-29 Parameters for PPPHC

Summary Data
File
MPLNK User-defined sheet Cabinet No./Slot None

eNodeB/NodeB/ No./Subboard Type/
eGBTS Transport Subrack No./Link
Data is No./MLPPP Group
recommended. Subboard Type/
MLPPP Group No./
E1/T1 Subrack No./
E1/T1 Slot No./E1/
T1 Subboard Type/
E1/T1 Port No./
Timeslot No./
Maximum Receive
Unit(byte)/Protocol
Field Compression/
Address and Control
Field Compression/
Negotiation Time
(ms)

SingleRAN
NOTE
----End


SingleRAN
NOTE
hide this area.
----End

Status is UP(Up), PPPHC has been activated.
Group Status is UP(Up), PPPHC has been activated.

SingleRAN
N/A
Transmission equipment connected to the GBTS supports E1/T1 ports along with PPPHC.

Required Data
None
The following table describes the parameters that must be set in a BTSPPPLNK MO to
configure PPPHC for a PPP link. The cabinet number, subrack number, and slot number of the
PPP link must be the same as those of the board where the link is located.
PPP link No. BTSPPPLNK. Network plan Each PPP link must
required) number.
Port No. BTSPPPLNK.PN Network plan Set this parameter

peer configuration.
Bearing Time Slot BTSPPPLNK. Network plan Set this parameter to

end.

SingleRAN
Local IP Address BTSPPPLNK. Network plan Set this parameter

required) plan.
Subnet Mask BTSPPPLNK. Network plan Set this parameter

MASK (negotiation based on the network
required) plan.
Peer IP Address BTSPPPLNK. Network plan Set this parameter

PEERIP (negotiation based on the network
required) plan.
Support Protocol BTSPPPLNK.PFC Network plan Set this parameter to

Field Compress (negotiation YES(Yes). This
required) parameter value must
setting of the peer
end.
Support Address and BTSPPPLNK. Network plan Set this parameter to

Control Field ACFC (negotiation YES(Yes). This
Compress required) parameter value must
setting of the peer
end.
Max Receive Unit BTSPPPLNK.MRU Network plan Set this parameter

required) plan.
Validate Protocol BTSPPPLNK. Network plan Set this parameter to

Type AUTHTYPE (negotiation be consistent with the
end.
Validate User Name BTSPPPLNK. Network plan These parameters are

required) BTSPPPLNK.AUT
HTYPE parameter is
Validate Password BTSPPPLNK. Network plan not set to NO_V(No
AUTHPWD (negotiation Validate). Set this
Validate Mode BTSPPPLNK. Network plan consistent with the
required) end.
Restart Timer BTSPPPLNK. Network plan Retain the default

RSTIME (negotiation value.
required)

SingleRAN
IP Header BTSPPPLNK. Network plan Set this parameter

Compression IPHC (negotiation based on the network
required) plan and to be
consistent with the
setting of the peer
end.
The following table describes the parameters that must be set in a BTSMPGRP MO to configure
PPPHC for an MLPPP group. The cabinet number, subrack number, and slot number of the
MLPPP group must be the same as those of the board where the group is located.
MLPPP Group No. BTSMPGRP. Network plan Set this parameter

MPGRPN (negotiation based on the network
required) plan.
Local IP Address BTSMPGRP. Network plan Set this parameter

required) plan.
Subnet Mask BTSMPGRP. Network plan Set this parameter

MASK (negotiation based on the network
required) plan.
Peer IP Address BTSMPGRP. Network plan Set this parameter

PEERIP (negotiation based on the network
required) plan.
MCPPP Switch BTSMPGRP. Network plan Set this parameter

MPSWITCH (negotiation based on the network
consistent with the
setting of the peer
end.
MP/MC List Head BTSMPGRP.MHF Network plan Set this parameter

required) plan.
MC PRI Number BTSMPGRP. Network plan These parameters are

required) BTSMPGRP.MPS
WITCH parameter is
set to ENABLE
(Enable).

SingleRAN
Validate Protocol BTSMPGRP. Network plan Set this parameter to

Type AUTHTYPE (negotiation be consistent with the
end.
Support Protocol BTSMPGRP.PFC Network plan Set this parameter to

Field Compress (negotiation YES(Yes). This
setting of the peer
end.
Support Address and BTSMPGRP. Network plan Set this parameter to

Control Field ACFC (negotiation YES(Yes). This
Compress required) parameter value must
setting of the peer
end.
IP Header BTSMPGRP.IPHC Network plan Set this parameter

consistent with the
setting of the peer
end.
The following table describes the parameters that must be set in a BTSMPLNK MO to configure
PPPHC for an MLPPP link in an MLPPP group. The cabinet number, subrack number, and slot
number of the MLPPP link must be the same as those of the board where the link is located.
MLPPP Group No. BTSMPLNK. Network plan Each MLPPP group

MPGRPN (negotiation must have a unique
PPP Link No. BTSMPLNK. Network plan Each MLPPP link in

link number.
Port No. BTSMPLNK.PN Network plan Set this parameter

peer configuration.

SingleRAN
Bearing Time Slot BTSMPLNK. Network plan Set this parameter to

end.
Max Receive Unit BTSMPLNK.MRU Network plan Set this parameter

required) plan.
Restart Timer BTSMPLNK. Network plan Retain the default

required)
8.6.5.3 Activation

Run the ADD BTSPPPLNK command to configure PPPHC for a PPP link.
Step 1 Run the ADD BTSMPGRP command to configure PPPHC for an MLPPP group.
----End

ADD BTSPPPLNK: PPPLNKN=0, PN=0, CN=0, SRN=0, SN=6,
TSBITMAP=TS1-1&TS2-1&TS3-1&TS4-1&TS5-1&TS6-1&TS7-1&TS8-1&TS9-1&T
S10-1&TS11-1&TS12-1&TS13-1&TS14-1&TS15-1&TS16-1&TS17-1&TS18-1&TS19
-1&TS20-1&TS21-1&TS22-1&TS23-1&TS24-1&TS25-1&TS26-1&TS27-1&TS28-1&
TS29-1&TS30-1&TS31-1, LOCALIP="192.168.20.3", MASK="255.255.255.0",
PEERIP="192.168.20.75", PFC=YES, ACFC=YES, AUTHTYPE=NO_V;
ADD BTSMPGRP: IDTYPE=BYID, BTSID=0, MPGRPN=0, CN=0, SRN=0, SN=7,
MPSWITCH=ENABLE, MHF=LONG, AUTHTYPE=NO_V, PFC=YES, ACFC=YES,
IPHC=ENABLE; ADD BTSMPLNK: IDTYPE=BYNAME, BTSNAME="0",
MPGRPN=0, PPPLNKN=0, PN=0, CN=0, SRN=0, SN=7,
TS29-1&TS30-1&TS31-1;

SingleRAN

NOTE
When configuring PPPHC on the CME, perform a single configuration first, and then perform a batch
----End

Name ID ble in CME
Batch
Modificati
on
1 BTSPPPLN GBTS PPP Link BTSPPPLN No

K No. K.
PPPLNKN
Port No. BTSPPPLN

K.PN
Bearing BTSPPPLN
Time Slot K.
TSBITMAP
Local IP BTSPPPLN
Address K.
LOCALIP
Subnet Mask BTSPPPLN

K.MASK
Peer IP BTSPPPLN
Address K.PEERIP
Support BTSPPPLN
Protocol K.PFC
Field
Compress

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Support BTSPPPLN
Address and K.ACFC
Control Field
Compress
Max Receive BTSPPPLN

Unit K.MRU
Validate BTSPPPLN
Protocol K.
Type AUTHTYP
E
Validate BTSPPPLN
User Name K.
AUTHNAM
E
Validate BTSPPPLN
Password K.
AUTHPWD
Validate BTSPPPLN
Mode K.
AUTHMOD
E
Restart BTSPPPLN
Timer K.RSTIME
IP Header BTSPPPLN
Compressio K.IPHC
n

Name ID ble in CME
Batch
Modificati
on
1 BTSMPGRP GBTS MLPPP BTSMPGR No

Group No. P.MPGRPN

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Local IP BTSMPGR
Address P.LOCALIP
Subnet Mask BTSMPGR

P. MASK
Peer IP BTSMPGR
Address P.PEERIP
MCPPP BTSMPGR
Switch P.
MPSWITC
H
MP/MC List BTSMPGR

Head Option P.MHF
MC PRI BTSMPGR
Number P.
MCCLASS
Validate BTSMPGR
Protocol P.
Type AUTHTYP
E
Support BTSMPGR
Protocol P.PFC
Field
Compress
Support BTSMPGR
Address and P.ACFC
Control Field
Compress
IP Header BTSMPGR
Compressio P.IPHC
n
2 BTSMPLN GBTS MLPPP BTSMPLN No

K Group No. K.MPGRPN
PPP Link BTSMPLN

No. K.
PPPLNKN
Port No. BTSMPLN

K.PN

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Bearing BTSMPLN
Time Slot K.
TSBITMAP
Max Receive BTSMPLN

Unit K.MRU
Restart BTSMPLN
Timer K.RSTIME

Run the DSP BTSPPPLNK command, and then check the command output. If the value of
Link Status is UP(Up), PPPHC has been activated.
Run the DSP BTSMPGRP command, and then check the command output. If the value of
MLPPP Group Status is UP(Up), PPPHC has been activated.
N/A
with PPPHC.


SingleRAN
Required Data
None
PPPHC for a PPP link. The subrack number and slot number of the PPP link must be the same
as those of the board where the link is located.
PPP link No. PPPLNK. Network plan Each PPP link must
required) number.
E1T1 port No. PPPLNK.DS1 Network plan Set this parameter

peer configuration.
Bearing time slot PPPLNK. Network plan Set this parameter to

end.
Borrow DevIP PPPLNK. Network plan Set this parameter

required) plan.
Borrowed device IP PPPLNK. DEVIP Network plan This parameter is

WDEVIP parameter
is not set to YES
(YES).
Local IP address PPPLNK. Network plan Set this parameter

required) plan.
Subnet mask PPPLNK. MASK Network plan Set this parameter

required) plan.
Peer IP address PPPLNK.PEERIP Network plan Set this parameter

required) plan.

SingleRAN
Head compress PPPLNK.IPHC Network plan Set this parameter

consistent with the
setting of the peer
end.
Protocol field PPPLNK.PFC Network plan Set this parameter to

compress (negotiation ENABLE(Enable).
must be consistent
peer end.
Address and Control PPPLNK.ACFC Network plan Set this parameter to

Field Compress (negotiation ENABLE(Enable).
must be consistent
peer end.
PPP mux PPPLNK.PPPMUX Network plan Retain the default

parameter to be
consistent with the
setting of the peer
end.
Validate protocol PPPLNK. Network plan Set this parameter to

type AUTHTYPE (negotiation be consistent with the
end.
Validate user name PPPLNK. Network plan These parameters are

required) PPPLNK.AUTHTY
PE parameter is not
Validate password PPPLNK. Network plan set to NO_V
AUTHPWD (negotiation (NO_V). Set this
Validate mode PPPLNK. Network plan consistent with the
required) end.

PPPHC for an MLPPP group. The subrack number and slot number of the MLPPP group must
be the same as those of the board where the group is located.

SingleRAN
MP Group No. MPGRP.MPGRPN Network plan Set this parameter

required) plan.

consistent with the
setting of the peer
end.
Borrow DevIP MPGRP. Network plan Set this parameter

required) plan.
Borrowed device IP MPGRP.DEVIP Network plan This parameter is

WDEVIP parameter
is not set to YES
(YES).
Local IP address MPGRP.LOCALIP Network plan Set this parameter

required) plan.
Subnet mask MPGRP. MASK Network plan Set this parameter

required) plan.

required) plan.

parameter is set to
MCPPP.

consistent with the
setting of the peer
end.

SingleRAN
Protocol field MPGRP.PFC Network plan Set this parameter to

compress (negotiation ENABLE(Enable).
must be consistent
peer end.
Address and Control MPGRP.ACFC Network plan Set this parameter to

Field Compress (negotiation ENABLE(Enable).
must be consistent
peer end.

consistent with the
setting of the peer
end.
parameter is set to
frame length MAXMFLEN (negotiation Set these parameters
required)
PPPHC for an MLPPP link in an MLPPP group. The subrack number and slot number of the
MLPPP link must be the same as those of the board where the link is located.


link number.

SingleRAN

peer configuration.
Bearing time slot MPLNK. Network plan Set this parameter to

end.
CRC check mode MPLNK.FCSTYPE Network plan Set this parameter

required) plan.
8.6.6.3 Activation

Run the ADD PPPLNK command to configure PPPHC for a PPP link.
Step 1 Run the ADD MPGRP command to configure PPPHC for an MLPPP group.
----End

ADD PPPLNK: SRN=0, SN=6, BRDTYPE=POUc, PPPLNKN=0, DS1=0,
TS29-1&TS30-1&TS31-1, BORROWDEVIP=NO, LOCALIP="192.168.20.75",
MASK="255.255.255.0", PEERIP="192.168.20.3", PFC=Enable, ACFC=Enable,
PPPMUX=Enable, AUTHTYPE=NO_V, FLOWCTRLSWITCH=ON,
ERRDETECTSW=OFF, OPSEPFLAG=OFF;
ADD MPGRP: SRN=0, SN=21, BRDTYPE=POUc, MPGRPN=0, MPTYPE=MLPPP,
BORROWDEVIP=NO, LOCALIP="192.168.20.75", MASK="255.255.255.0",
PEERIP="192.168.20.3", PFC=Enable, ACFC=Enable, PPPMUX=Enable,
FLOWCTRLSWITCH=ON, AUTHTYPE=NO_V, ERRDETECTSW=OFF,
ANTIERRFLAG=OFF, OPSEPFLAG=OFF; ADD MPLNK: SRN=0, SN=7,
BRDTYPE=POUc, MPGRPN=0, PPPLNKN=0, DS1=0,

SingleRAN
TS29-1&TS30-1&TS31-1;
NOTE
When configuring PPPHC on the CME, perform a single configuration first, and then perform a batch
----End

Name ID ble in CME
Batch
Modificati
on
1 PPPLNK BSC/RNC PPP link No. PPPLNK. No

PPPLNKN
E1T1 port PPPLNK.

No. DS1
Bearing time PPPLNK.

slot TSBITMAP
Borrow PPPLNK.
DevIP BORROWD
EVIP
Borrowed PPPLNK.
device IP DEVIP
address
Local IP PPPLNK.
address LOCALIP

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Subnet mask PPPLNK.

MASK
Peer IP PPPLNK.
address PEERIP
Head PPPLNK.
compress IPHC
Protocol PPPLNK.
field PFC
compress
Address and PPPLNK.

Control Field ACFC
Compress
PPP mux PPPLNK.

PPPMUX
Validate PPPLNK.
protocol type AUTHTYP
E
Validate user PPPLNK.

name AUTHNAM
E
Validate PPPLNK.
password AUTHPWD
Validate PPPLNK.
mode AUTHMOD
E

Name ID ble in CME
Batch
Modificati
on
1 MPGRP BSC/RNC MP Group MPGRP. No

No. MPGRPN

SingleRAN

Name ID ble in CME
Batch
Modificati
on
MP type MPGRP.
MPTYPE
Borrow MPGRP.
DevIP BORROWD
EVIP
Borrowed MPGRP.
device IP DEVIP
address
Local IP MPGRP.
address LOCALIP
Subnet mask MPGRP.

MASK
MP/MC list MPGRP.

head option MHO
MC PRI MPGRP.
number MCCLASS
Head MPGRP.
compress IPHC
Protocol MPGRP.
field PFC
compress
Address and MPGRP.

Control Field ACFC
Compress
PPP mux MPGRP.

PPPMUX
PPP mux MPGRP.

max sub- MAXSFLE
frame length N
PPP mux MPGRP.

max mux- MAXMFLE
frame length N
PPP mux MPGRP.

framing out- MUXTIME
time[us]

SingleRAN

Name ID ble in CME
Batch
Modificati
on
2 MPLNK BSC/RNC MP Group MPLNK. No

No. MPGRPN
PPP sub-link MPLNK.

No. PPPLNKN
E1T1 port MPLNK.

No. DS1
Bearing time MPLNK.

slot TSBITMAP
CRC check MPLNK.

mode FCSTYPE

Status is UP(Up), PPPHC has been activated.
Group Status is UP(Up), PPPHC has been activated.
N/A

None

None
None
8.7 MLPPP/MCPPP
This section describes engineering guidelines for MLPPP/MCPPP.

SingleRAN
8.7.1 When to Use MLPPP/MCPPP

Before using MLPPP/MCPPP, you must ensure that the base station and base station controller
are configured with the E1/T1 port.
MCPPP is recommended if packet transmission efficiency is required to be improved and more

service classes are required.
MLPPP is recommended if the throughput is required to be increased and the transmission delay
is required to be reduced.

None
8.7.3 Planning
8.7.3.1 RF Planning
None

IP over E1/T1 is applied to devices at the two ends where MLPPP/MCPPP is used.

l Hardware planning for the LTE to enable LBFD-00300403 MLPPP/MCPPP:
PPPHC.
The BSC6900 must be configured with the PEUa, PEUc, or POUc board.
The BSC6910 must be configured with the POUc board.
The eGBTS must be configured with the UTRP and UMPT boards.
For the GBTS, the BTS3012 series base stations must be configured with the DPTU
boards and 3900 series base stations must be configured with the GTMUb boards.
The BSC6900 must be configured with the PEUa, PEUc, POUa, or POUc board.
with MLPPP/MCPPP.

SingleRAN

Required Data
None
MCPPP
MLPPP/MCPPP for an MLPPP group. The cabinet number, subrack number, and slot number
of the MLPPP group must be the same as those of the board where the group is located. If a
UMPT is used for transmission, set the subboard type of the MLPPP group to BASE_BOARD
(Base Board).
PPPMUX MPGRP.MUXCP Network plan Set this parameter

required) plan.
PPP Mux Subframe MPGRP. Network plan These parameters are

Max Length MAXSFLEN (negotiation valid only if the
required) MPGRP.MUXCP
parameter is set to
PPP Muxframe Max MPGRP. Network plan ENABLE(Enable).
Length MAXMFLEN (negotiation Set this parameter
PPPMUX Combine MPGRP. Network plan plan.
Timeout(ms) MUXTIME (negotiation
required)

parameter to be
consistent with the
setting of the peer
end.

SingleRAN

must be consistent
peer end.
MP/MC Header MPGRP.MHO Network plan These parameters are

Option (negotiation valid only if the
required) MPGRP.MCPPP
parameter is set to
MCPPP Class MPGRP. Network plan ENABLE(Enable).
MCCLASS (negotiation
required)
MLPPP/MCPPP for an MLPPP link in an MLPPP group. Before adding an MLPPP link to a
specific MLPPP group, ensure that the MLPPP group has been configured. The cabinet number,
subrack number, and slot number of an E1/T1 port must be the same as those of the board where
the port is located. If a UMPT is used for transmission, set the subboard types of the MLPPP
link, MLPPP group, and E1/T1 port to BASE_BOARD(Base Board).

link number.


required) plan.

required) plan.

setting of the peer
end.

SingleRAN

setting of the peer
end.

required)
MLPPP
Before deploying MLPPP, collect data for configuring an MLPPP group and an MLPPP link in
the MLPPP group.
of the MLPPP group must be the same as those of the board where the group is located.
PPPMUX MPGRP.MUXCP Network plan Set this parameter

consistent with the
setting of the peer
end.
PPP Mux Subframe MPGRP. Network plan These parameters are

Max Length MAXSFLEN (negotiation valid only if the
required) MPGRP.MUXCP
parameter is set to
PPP Muxframe Max MPGRP. Network plan ENABLE(Enable).
Length MAXMFLEN (negotiation Set this parameter
PPPMUX Combine MPGRP. Network plan plan.
Timeout MUXTIME (negotiation
required)

required) plan.

SingleRAN

(negotiation DISABLE
setting of the peer
end.
MP/MC Header MPGRP.MHO Network plan These parameters are

Option (negotiation valid only if the
required) MPGRP.MCPPP
parameter is set to
MCPPP Class MPGRP. Network plan ENABLE(Enable).
MCCLASS (negotiation
required)
MLPPP/MCPPP for an MLPPP link in an MLPPP group. The cabinet number, subrack number,
and slot number of the MLPPP link must be the same as those of the board where the group is
located. If a UMPT is used for transmission, set the subboard type of the MLPPP group to
BASE_BOARD(Base Board).

link number.
MLPPP Group MPLNK. Network plan Set this parameter to

Subboard Type MPGRPSBT (negotiation E1_COVERBOAR
or BASE_BOARD
(Base Board) based
on the actual
connection.

E1/T1 Subrack No. MPLNK.E1T1SRN Network plan Set these parameters

required) connection.
E1/T1 Slot No. MPLNK.E1T1SN Network plan

(negotiation
required)

SingleRAN
E1/T1 Subboard MPLNK.E1T1SBT Network plan Set this parameter to

Type (negotiation E1_COVERBOAR
or BASE_BOARD
(Base Board) based
on the actual
connection.
E1/T1 Port No. MPLNK.E1T1PN Network plan Set this parameter

peer configuration.
Timeslot No. MPLNK.TSN Network plan Set this parameter to

end.

required) plan.
Protocol Field MPLNK.PFC Network plan Set this parameter

required) plan.
Address and Control MPLNK.ACFC Network plan Set this parameter

required) plan.
8.7.4.3 Activation

Step 1 Run the ADD MPGRP command to configure MLPPP/MCPPP for an MLPPP group.
----End

l MCPPP
MUXCP=ENABLE, IPHC=ENABLE, MCPPP=ENABLE, MHO=LONG, MCCLASS=8;
S25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1, PFC=DISABLE, ACFC=DISABLE;

SingleRAN
l MLPPP
MUXCP=ENABLE, IPHC=ENABLE, MCPPP=DISABLE;
S25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1, PFC=DISABLE, ACFC=DISABLE;
parameters.

SingleRAN
Table 8-34 Parameters for MCPPP

Summary Data
File
MPGRP User-defined sheet Subrack No./ None

eNodeB/NodeB/ Cabinet No./
eGBTS Transport Subboard Type/
Data is Slot No./MLPPP
recommended. Group No./Multi-
Class PPP/
Authentication
Type/User Name/
Password/Local IP/
Mask/Peer IP/MP/
MC Header Option/
PPPMUX/MLPPP
Fragment Size
(byte)/PPP Mux
Subframe Max
Length(byte)/PPP
Muxframe Max
Length(byte)/
PPPMUX Combine
Timeout(ms)/
MCPPP Class/IP
Header
Compression/
MLPPP Packets
Discard Alarm
Appear Threshold
(per mill)/MLPPP
Packets Discard
Alarm Disappear
Threshold(per mill)

SingleRAN

Summary Data
File
MPLNK User-defined sheet Cabinet No./ None

eNodeB/NodeB/ Subrack No./Slot
eGBTS Transport No./Subboard
Data is Type/Link No./
recommended. MLPPP Group
Subboard Type/
MLPPP Group No./
E1/T1 Subrack No./
E1/T1 Slot No./E1/
T1 Subboard Type/
E1/T1 Port No./
Timeslot No./
Maximum Receive
Unit/Protocol Field
Compression/
Address and
Control Field
Compression/
Negotiation Time
NOTE

SingleRAN
----End

NOTE
hide this area.

SingleRAN
----End

Group Status is UP(Up), MLPPP/MCPPP has been activated.
N/A
Transmission equipment connected to the GBTS supports E1/T1 ports along with MLPPP/
MCPPP.

Required Data
None
MCPPP

SingleRAN
MCPPP Switch BTSMPGRP. Network plan Set this parameter to

MPSWITCH (negotiation ENABLE(Enable).
must be consistent
peer end.

required) plan.

WITCH parameter is
set to ENABLE
(Enable).
Support Protocol BTSMPGRP.PFC Network plan Set this parameter

consistent with the
setting of the peer
end.
Support Address and BTSMPGRP. Network plan Set this parameter

Control Field ACFC (negotiation based on the network
Compress required) plan and to be
consistent with the
setting of the peer
end.

consistent with the
setting of the peer
end.
specific MLPPP group, ensure that the MLPPP group has been configured. The cabinet number,
subrack number, and slot number of the MLPPP link must be the same as those of the board
where the link is located.

SingleRAN


link number.
Bearing Time Slot BTSMPLNK. Network plan Set this parameter

required) plan.

required) plan.

required)
MLPPP
the MLPPP group.
MCPPP Switch BTSMPGRP. Network plan Set this parameter to

MPSWITCH (negotiation DISABLE
setting of the peer
end.

required) plan.

WITCH parameter is
set to ENABLE
(Enable).

SingleRAN
Support Protocol BTSMPGRP.PFC Network plan Set this parameter

consistent with the
setting of the peer
end.
Support Address and BTSMPGRP. Network plan Set this parameter

Control Field ACFC (negotiation based on the network
Compress required) plan and to be
consistent with the
setting of the peer
end.

consistent with the
setting of the peer
end.
MLPPP/MCPPP for an MLPPP link in an MLPPP group. The cabinet number, subrack number,
and slot number of the MLPPP link must be the same as those of the board where the link is
located.


link number.
Bearing Time Slot BTSMPLNK. Network plan Set this parameter

required) plan.

required) plan.

required)

SingleRAN
8.7.5.3 Activation

Step 1 Run the ADD BTSMPGRP command to configure MLPPP/MCPPP for an MLPPP group.
----End

l MCPPP
ADD BTSMPGRP: MPGRPN=0, CN=0, SRN=0, SN=7, LOCALIP="192.168.20.3",
MASK="255.255.255.0", PEERIP="192.168.20.75", MPSWITCH=ENABLE, MHF=LONG,
MCCLASS=8, AUTHTYPE=NO_V, IPHC=ENABLE;
ADD BTSMPLNK: IDTYPE=BYID, BTSID=0, MPGRPN=0, PPPLNKN=0, PN=0, CN=0, SRN=0, SN=7,
4-1&TS25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1;
l MLPPP
ADD BTSMPGRP: MPGRPN=0, CN=0, SRN=0, SN=7, LOCALIP="192.168.20.3",
MASK="255.255.255.0", PEERIP="192.168.20.75", MPSWITCH=DISABLE, MHF=LONG,
AUTHTYPE=NO_V, IPHC=ENABLE;
ADD BTSMPLNK: IDTYPE=BYID, BTSID=0, MPGRPN=0, PPPLNKN=0, PN=0, CN=0, SRN=0, SN=7,
4-1&TS25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1;

NOTE
When configuring MLPPP/MCPPP on the CME, perform a single configuration first, and then perform a
batch modification if required. Configure the parameters of a single object before a batch modification.
Perform a batch modification before logging out of the parameter setting interface.
Guide.
----End

SingleRAN

Name ID ble in CME
Batch
Modificati
on
1 BTSMPGRP GBTS MCPPP MPSWITC No

Switch H
MP/MC List MHF

Head Option
MC PRI MCCLASS
Number
Support PFC
Protocol
Field
Compress
Support ACFC
Address and
Control Field
Compress
IP Header IPHC
Compressio
n
2 BTSMPLN GBTS MLPPP MPGRPN No

K Group No.
PPP Link PPPLNKN

No.
Bearing TSBITMAP
Time Slot
Max Receive MRU

Unit
Restart RSTIME
Timer

Run the DSP BTSMPGRP command, and then check the command output. If the value of
MLPPP Group Status is UP(Up), MLPPP/MCPPP has been activated.
N/A

SingleRAN
with MLPPP/MCPPP.

Required Data
None
MCPPP
MLPPP/MCPPP for an MLPPP group. The subrack number and slot number of the MLPPP
group must be the same as those of the board where the group is located.
MP type MPGRP.MPTYPE Network plan Set this parameter to

(negotiation MCPPP. This
setting of the peer
end.

required) plan.

parameter is set to
MCPPP.

SingleRAN

consistent with the
setting of the peer
end.

consistent with the
setting of the peer
end.

consistent with the
setting of the peer
end.

consistent with the
setting of the peer
end.
parameter is set to
required)
specific MLPPP group, ensure that the MLPPP group has been configured. The subrack number
and slot number of an E1/T1 port must be the same as those of the board where the port is located.

SingleRAN


link number.

required) plan.

required) plan.

required)

required)

(negotiation value.
required)
MLPPP
the MLPPP group.
MLPPP/MCPPP for an MLPPP group. The subrack number and slot number of the MLPPP
group must be the same as those of the board where the group is located.
MP type MPGRP.MPTYPE Network plan Set this parameter to

(negotiation MLPPP. This
setting of the peer
end.

required) plan.

SingleRAN

parameter is set to
MLPPP.

consistent with the
setting of the peer
end.

consistent with the
setting of the peer
end.

consistent with the
setting of the peer
end.

consistent with the
setting of the peer
end.
parameter is set to
required)
MLPPP/MCPPP for an MLPPP link in an MLPPP group. The subrack number and slot number
of the MLPPP link must be the same as those of the board where the group is located.

SingleRAN


link number.

required) plan.

required) plan.

required)

required)

(negotiation value.
required)
8.7.6.3 Activation

Step 1 Run the ADD MPGRP command to configure MLPPP/MCPPP for an MLPPP group.
----End

l MCPPP
ADD MPGRP: SRN=0, SN=21, BRDTYPE=POUc, MPGRPN=0, MPTYPE=MCPPP, BORROWDEVIP=NO,
LOCALIP="192.168.20.75", MASK="255.255.255.0", PEERIP="192.168.20.3", MHF=LONG,
OPSEPFLAG=OFF;
4-1&TS25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1;
l MLPPP

SingleRAN
ADD MPGRP: SRN=0, SN=21, BRDTYPE=POUc, MPGRPN=0, MPTYPE=MLPPP, BORROWDEVIP=NO,

OPSEPFLAG=OFF;
4-1&TS25-1&TS26-1&TS27-1&TS28-1&TS29-1&TS30-1&TS31-1;
NOTE
When configuring MLPPP/MCPPP on the CME, perform a single configuration first, and then perform a
batch modification if required. Configure the parameters of a single object before a batch modification.
Perform a batch modification before logging out of the parameter setting interface.
Guide.
----End

Name ID ble in CME
Batch
Modificati
on
1 MPGRP BSC/RNC MP Group MPGRPN No

No.
MP type MPTYPE
MP/MC list MHF

head option
MC PRI MCCLASS
number
MP flake FRAGSIZE
size
Head IPHC
compress

SingleRAN

Name ID ble in CME
Batch
Modificati
on
Protocol PFC
field
compress
Address and ACFC

Control Field
Compress
PPP mux PPPMUX
PPP mux MAXSFLE

max sub- N
frame length
PPP mux MAXMFLE

max mux- N
frame length
PPP mux MUXTIME

framing out-
time[us]
2 MPLNK BSC/RNC MP Group MPGRPN No

No.
PPP sub-link PPPLNKN

No.
E1T1 port DS1

No.

slot
negotiate out MR
time[S]
Keep-alive KEEPALIV
timer length E
[S]
CRC check FCSTYPE

mode

SingleRAN

Group Status is UP(Up), MLPPP/MCPPP has been activated.
N/A

None

None
None

SingleRAN
Description 9 Parameters
9 Parameters
Table 9-1 Parameter description
Parameter ID NE MML Feature ID Feature Name Description

Command
MUXTYPE BSC6900 ADD IPMUX WRFD-050412 UDP MUX for Meaning:IP

MOD IPMUX WRFD-050420 Iu-CS packet
Transmission multiplexing
FP MUX for IP type.
Transmission GUI Value
Range:FPMUX,
UDPMUX
Unit:None
Actual Value
Range:FPMUX,
UDPMUX
Default
Value:None

SingleRAN

Command
SUBFRAMELE BSC6900 ADD IPMUX WRFD-050412 UDP MUX for Meaning:Maxi

N MOD IPMUX WRFD-050420 Iu-CS mum sub-frame
Transmission length. This
FP MUX for IP parameter
Transmission indicates the
maximum sub-
frame length for
multiplexing. If
the length of a
sub-frame
exceeds this
value, the sub-
frame is not
multiplexed.
GUI Value
Range:16~1023
Unit:byte
Actual Value
Range:16~1023
Default Value:
352
MAXFRAMEL BSC6900 ADD IPMUX WRFD-050412 UDP MUX for Meaning:Maxi

EN MOD IPMUX WRFD-050420 Iu-CS mum
Transmission multiplexing
FP MUX for IP frame length
Range:24~1031
Unit:byte
Actual Value
Range:24~1031
Default Value:
1031

SingleRAN

Command
FPTIMER BSC6900 ADD IPMUX WRFD-050412 UDP MUX for Meaning:This

MOD IPMUX WRFD-050420 Iu-CS parameter
Transmission specifies the
FP MUX for IP maximum time
Transmission that the system
waits before
sending the
multiplexed
data. 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
extended delay
can be
prevented.
GUI Value
Range:1~90
Unit:ms
Actual Value
Range:1~90
Default Value:2

SingleRAN

Command
IPMUXSWITC BTS3900, ADD IPPATH WRFD-050420 FP MUX for IP Meaning:Indi-

H BTS3900 MOD IPPATH Transmission cates whether
WCDMA, the IPMUX
BTS3900 LTE DSP IPPATH function is
LST IPPATH enabled on IP
paths. The LTE
currently does
not support this
function.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:DISABL
E(Disable)
SUBFRAMELE BTS3900, ADD IPPATH WRFD-050420 FP MUX for IP Meaning:Indi-

N BTS3900 MOD IPPATH Transmission cates the
WCDMA, maximum
BTS3900 LTE LST IPPATH subframe length
of IPMUX. The
LTE currently
does not support
the IPMUX
function.
GUI Value
Range:1~1023
Unit:byte
Actual Value
Range:1~1023
Default Value:
127

SingleRAN

Command
FRAMELEN BTS3900, ADD IPPATH WRFD-050420 FP MUX for IP Meaning:Indi-

BTS3900 MOD IPPATH Transmission cates the
WCDMA, maximum
BTS3900 LTE LST IPPATH multiframe
length of
IPMUX. The
LTE currently
does not support
the IPMUX
function.
GUI Value
Range:
100~1031
Unit:byte
Actual Value
Range:
100~1031
Default Value:
270
TIMER BTS3900, ADD IPPATH WRFD-050420 FP MUX for IP Meaning:Indi-

BTS3900 MOD IPPATH Transmission cates the length
WCDMA, of the IPMUX
BTS3900 LTE LST IPPATH timer, which
defines the
maximum
buffer time for
IPMUX packets.
The LTE
currently does
not support the
IPMUX
function.
GUI Value
Range:1~20
Unit:ms
Actual Value
Range:1~20
Default Value:1

SingleRAN

Command
MUXTYPE BSC6900 ADD WRFD-050412 UDP MUX for Meaning:IP

IPPOOLMUX WRFD-050420 Iu-CS packet
MOD Transmission multiplexing
IPPOOLMUX FP MUX for IP type.
Range:FPMUX,
UDPMUX
Unit:None
Actual Value
Range:FPMUX,
UDPMUX
Default
Value:None

SingleRAN

Command
UDPMUXMO BSC6900 ADD IPMUX WRFD-050412 UDP MUX for Meaning:UDP

DSEND MOD IPMUX WRFD-050420 Iu-CS multiplexing
Transmission mode of the
FP MUX for IP sending party. If
Transmission 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:NORTP
COMP,
RTPCOMP
Unit:None
Actual Value
Range:NORTP
COMP,
RTPCOMP
Default
Value:None

SingleRAN

Command
UDPMUXMO BSC6900 ADD IPMUX WRFD-050412 UDP MUX for Meaning:UDP

DRECV MOD IPMUX Iu-CS multiplexing
Transmission mode of the
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:NORTP
COMP,
RTPCOMP
Unit:None
Actual Value
Range:NORTP
COMP,
RTPCOMP
Default
Value:None

SingleRAN

Command
IPHC BSC6900 ADD PPPLNK WRFD-050409 IP Transmission Meaning:This

MOD PPPLNK WRFD-050402 Introduction on parameter
Iu Interface specifies
WRFD-050410 whether to
IP Transmission
Introduction on compress the
Iub Interface packet headers,
or not.
IP Transmission
Introduction on GUI Value
Iur Interface Range:RTP/
UDP/IP_HC
(RTP/UDP/
IP_HC), UDP/
IP_HC(UDP/
IP_HC), No_HC
(No_HC)
Unit:None
Actual Value
Range:RTP/
UDP/IP_HC,
UDP/IP_HC,
No_HC
Default
Value:UDP/
IP_HC(UDP/
IP_HC)

SingleRAN

Command
IPHC BSC6900 ADD MPGRP WRFD-050409 IP Transmission Meaning:This

MOD MPGRP WRFD-050402 Introduction on parameter
IP Transmission
Introduction on compress the IP
Iub Interface header of a
MLPPP group,
IP Transmission or not.
Introduction on
Iur Interface GUI Value
Range:RTP/
UDP/IP_HC
(RTP/UDP/
IP_HC), UDP/
IP_HC(UDP/
IP_HC), No_HC
(No_HC)
Unit:None
Actual Value
Range:RTP/
UDP/IP_HC,
UDP/IP_HC,
No_HC
Default
Value:UDP/
IP_HC(UDP/
IP_HC)
IPHC BTS3900, ADD PPPLNK WRFD-050411 Fractional IP Meaning:Indi-

BTS3900 MOD PPPLNK WRFD-050402 Function on Iub cates whether to
WCDMA, Interface enable IP header
BTS3900 LTE DSP PPPLNK compression.
IP Transmission
LST PPPLNK Introduction on GUI Value
Iub Interface Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:ENABLE
(Enable)

SingleRAN

Command
IPHC BTS3900, ADD MPGRP WRFD-050411 Fractional IP Meaning:Indi-

BTS3900 MOD MPGRP Function on Iub cates whether to
WCDMA, Interface enable IP header
BTS3900 LTE DSP MPGRP compression.
LST MPGRP GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:ENABLE
(Enable)
IPHCSUBOPT BTS3900, ADD PPPLNK WRFD-050411 Fractional IP Meaning:Indi-

WCDMA, Interface enable IPHC
BTS3900 LTE LST PPPLNK suboption
IP Transmission
Introduction on negotiation.
Iub Interface GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:DISABL
E(Disable)

SingleRAN

Command
IPHCSUBOPT BTS3900, ADD MPGRP WRFD-050411 Fractional IP Meaning:Indi-

BTS3900 MOD MPGRP Function on Iub cates whether to
WCDMA, Interface enable IPHC
BTS3900 LTE LST MPGRP suboption
negotiation.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:DISABL
E(Disable)

SingleRAN

Command
ACFC BSC6900 ADD PPPLNK WRFD-050409 IP Transmission Meaning:This

MOD PPPLNK WRFD-050402 Introduction on parameter
IP Transmission
Iub Interface address and
control fields, or
IP Transmission not. If this
Introduction on parameter is set
Iur Interface 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.
GUI Value
Range:Disable
(Disable),
Enable(Enable)
Unit:None
Actual Value
Range:Disable,
Enable
Default
Value:Enable
(Enable)

SingleRAN

Command
ACFC BSC6900 ADD MPGRP WRFD-050409 IP Transmission Meaning:This

MOD MPGRP WRFD-050402 Introduction on parameter
IP Transmission
Iub Interface address and
control fields, or
IP Transmission not. If this
Introduction on parameter is set
Iur Interface 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.
GUI Value
Range:Disable
(Disable),
Enable(Enable)
Unit:None
Actual Value
Range:Disable,
Enable
Default
Value:Enable
(Enable)

SingleRAN

Command
ACFC BTS3900, ADD PPPLNK WRFD-050411 Fractional IP Meaning:Indi-

WCDMA, Interface enable the
BTS3900 LTE DSP PPPLNK compression of
IP Transmission
LST PPPLNK Introduction on the address field
Iub Interface and control
field.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:ENABLE
(Enable)
ACFC BTS3900, ADD MPLNK WRFD-050411 Fractional IP Meaning:Indi-

BTS3900 DSP MPLNK Function on Iub cates whether to
WCDMA, Interface enable the
BTS3900 LTE LST MPLNK compression of
the address field
and control
field.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:ENABLE
(Enable)

SingleRAN

Command
PFC BSC6900 ADD PPPLNK WRFD-050409 IP Transmission Meaning:Compr

MOD PPPLNK WRFD-050402 Introduction on ession flag of the
Iu Interface PPP link
WRFD-050410 protocol domain
IP Transmission
Iub Interface Range:Disable
IP Transmission (Disable),
Introduction on Enable(Enable)
Iur Interface Unit:None
Actual Value
Range:Disable,
Enable
Default
Value:Enable
(Enable)
PFC BSC6900 ADD MPGRP WRFD-050409 IP Transmission Meaning:Compr

MOD MPGRP WRFD-050402 Introduction on ession flag of the
Iu Interface PPP link
WRFD-050410 protocol domain
IP Transmission
Iub Interface Range:Disable
IP Transmission (Disable),
Introduction on Enable(Enable)
Iur Interface Unit:None
Actual Value
Range:Disable,
Enable
Default
Value:Enable
(Enable)

SingleRAN

Command
PFC BTS3900, ADD PPPLNK WRFD-050411 Fractional IP Meaning:Indi-

WCDMA, Interface enable protocol
BTS3900 LTE DSP PPPLNK field
IP Transmission
LST PPPLNK Introduction on compression.
Iub Interface GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:ENABLE
(Enable)
PFC BTS3900, ADD MPLNK WRFD-050411 Fractional IP Meaning:Indi-

BTS3900 DSP MPLNK Function on Iub cates whether to
WCDMA, Interface enable protocol
BTS3900 LTE LST MPLNK field
compression.
GUI Value
Range:DISABL
E(Disable),
ENABLE
(Enable)
Unit:None
Actual Value
Range:DISABL
E, ENABLE
Default
Value:ENABLE
(Enable)

SingleRAN
Description 10 Counters
10 Counters
There are no specific counters associated with this feature.

SingleRAN
Description 11 Glossary
11 Glossary
For the acronyms, abbreviations, terms, and definitions, see Glossary.

SingleRAN
Description 12 Reference Documents
12 Reference Documents
RFC 2686, " The Multi-Class Extension to Multi-Link PPP"


IP Transmission Efficiency Improvement (SRAN9.0 - Draft A) PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IP Transmission Efficiency Improvement (SRAN9.0 - Draft A) PDF

Hochgeladen von

Copyright:

Verfügbare Formate

SingleRAN

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential i

1 About This Document..................................................................................................................1

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential ii

4.3.2.1 PPP Frame Format..................................................................................................................................................18

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential iii

8.1.4.3.1 Using MML Commands......................................................................................................................................36

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential iv

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential v

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential vi

8.5.6.5.1 Using MML Commands....................................................................................................................................110

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential vii

8.6.8 Parameter Optimization...........................................................................................................................................139

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential viii

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential ix

1 About This Document

This document covers the following features:

l LBFD-003004 Compression & Multiplexing over E1/T1

1.2 Intended Audience

l Need to understand the features described herein

1.3 Change History

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 1

Changes in features of a specific product version

This document integrates the following three documents:

l IP Transport Architecture Feature Parameter Description for GBSS

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 2

Transmission efficiency improvement is highly necessary in today's networks with ever-

Figure 2-1 Mechanisms for improving IP transmission efficiency

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 3

Multiplexing technologies include:

3.2 Frame Protocol Multiplexing (for UMTS Only)

FP MUX has the following characteristics:

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 4

3.2.2 Technical Description

3.2.2.1 Packet Format

Figure 3-1 Format of an FP MUX IP packet

The fields of an FP MUX IP packet are described as follows:

l User Identifier: specifies the owner of an FP PDU.

The parameters related to FP MUX are as follows:

l FP MUX switch: specifies whether to enable FP MUX.

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 5

NE FP MUX Max Max frame Max delay

RNC When SUBFRAMEL MAXFRAME FPTIMER

NodeB When SUBFRAMEL FRAMELEN TIMER (ADD

l Both the RNC and the NodeB support FP MUX.

Figure 3-2 Buffering and multiplexing performed at the transmission end

The multiplexing conditions are as follows:

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 6

3.3 UDP Multiplexing (for GSM and UMTS Only)

UDP MUX has the following characteristics:

3.3.2 Technical Description

3.3.2.1 Packet Format

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 7

Figure 3-3 IP packet format with the RTP header uncompressed

Figure 3-4 IP packet format with the RTP header compressed

The following describes the fields of a UDP MUX packet.

Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 8

UDP MUX packets have the following characteristics:

The related parameters on the base station controller are as follows:

l The following three parameters need to be set to enable UDP MUX: