IP Active Performance Measurement (SRAN10.1 - 04)

SingleRAN
IP Active Performance Measurement

Feature Parameter Description
Issue 04
Date 2015-12-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2015. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior 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 04 (2015-12-30) Huawei Proprietary and Confidential i

Copyright Huawei Technologies Co., Ltd.
SingleRAN
IP Active Performance Measurement Feature Parameter
Description Contents
Contents
1 About This Document.................................................................................................................. 1

1.1 Scope.............................................................................................................................................................................. 1
1.2 Intended Audience.......................................................................................................................................................... 2
1.3 Change History............................................................................................................................................................... 2
1.4 Differences Between Base Station Types....................................................................................................................... 4
2 Overview......................................................................................................................................... 6
2.1 Description......................................................................................................................................................................7
2.2 Benefits........................................................................................................................................................................... 7
3 Technical Description...................................................................................................................9
3.1 Position of TWAMP in the TCP/IP Protocol Stack........................................................................................................ 9
3.2 Basic Concepts............................................................................................................................................................... 9
3.2.1 Measurement Model.................................................................................................................................................. 10
3.2.2 Measurement Process................................................................................................................................................ 11
3.3 TWAMP Measurement Parameters.............................................................................................................................. 12
3.3.1 Packet Loss Rate........................................................................................................................................................13
3.3.2 Round-Trip Delay...................................................................................................................................................... 13
3.3.3 Delay Variation.......................................................................................................................................................... 13
4 TWAMP Application.................................................................................................................. 15
4.1 Differences Between TWAMP and Huawei-Private IP PM......................................................................................... 15
4.2 TWAMP Application on the Base Station Side............................................................................................................17
4.2.1 TWAMP Controller Function.................................................................................................................................... 17
4.2.2 TWAMP Responder Function................................................................................................................................... 18
4.2.3 Networking Scenarios................................................................................................................................................18
4.3 TWAMP Application on the Base Station Controller Side.......................................................................................... 18
4.3.1 TWAMP Controller Function.................................................................................................................................... 19
4.3.2 TWAMP Responder Function................................................................................................................................... 19
4.3.3 Networking Scenarios................................................................................................................................................19
5 Related Features...........................................................................................................................21
5.1 GBFD-151202 BTS IP Active Performance Measurement......................................................................................... 21
5.2 GBFD-151201 BSC IP Active Performance Measurement......................................................................................... 22
5.3 WRFD-151212 NodeB IP Active Performance Measurement.....................................................................................22
5.4 WRFD-151211 RNC IP Active Performance Measurement........................................................................................23
Issue 04 (2015-12-30) Huawei Proprietary and Confidential ii

SingleRAN
Description Contents
5.5 LOFD-070219/TDLOFD-003018 IP Active Performance Measurement....................................................................24
6 Network Impact........................................................................................................................... 25
7 Engineering Guidelines............................................................................................................. 26
7.1 When to Use IP Active Performance Measurement..................................................................................................... 26
7.2 Required Information................................................................................................................................................... 27
7.3 Planning........................................................................................................................................................................ 27
7.4 Feature Deployment..................................................................................................................................................... 27
7.4.1 Requirements............................................................................................................................................................. 27
7.4.2 Precautions.................................................................................................................................................................28
7.4.3 Data Preparation........................................................................................................................................................ 28
7.4.4 Activation.................................................................................................................................................................. 31
7.4.5 Activation Observation..............................................................................................................................................34
7.4.6 Hardware Adjustment................................................................................................................................................36
7.4.7 Deactivation...............................................................................................................................................................36
7.5 Performance Monitoring...............................................................................................................................................37
7.6 Parameter Optimization................................................................................................................................................ 37
7.7 Troubleshooting............................................................................................................................................................ 37
7.7.1 Checking Alarms....................................................................................................................................................... 37
7.7.2 Using MML Commands............................................................................................................................................ 38
7.7.3 Fault Locating Method.............................................................................................................................................. 39
8 Parameters..................................................................................................................................... 41
9 Counters........................................................................................................................................ 54
10 Glossary....................................................................................................................................... 59
11 Reference Documents............................................................................................................... 60
Issue 04 (2015-12-30) Huawei Proprietary and Confidential iii

SingleRAN
Description 1 About This Document
1 About This Document
1.1 Scope
IP Active Performance Measurement consists of the following features:
l GSM: GBFD-151201 BSC IP Active Performance Measurement

l GSM: GBFD-151202 BTS IP Active Performance Measurement
l UMTS: WRFD-151211 RNC IP Active Performance Measurement
l UMTS: WRFD-151212 NodeB IP Active Performance Measurement
l LTE: LOFD-070219 IP Active Performance Measurement
l LTE: TDLOFD-003018 IP Active Performance Measurement
In this document, the following naming conventions apply for LTE terms.
Includes FDD and TDD Includes FDD Only Includes TDD Only
LTE LTE FDD LTE TDD
eNodeB LTE FDD eNodeB LTE TDD eNodeB
eRAN LTE FDD eRAN LTE TDD eRAN
In addition, the "L" and "T" in RAT acronyms refer to LTE FDD and LTE TDD, respectively.
This document applies to the eGBTS, NodeB, eNodeB, separate-MPT multimode base
station, co-MPT multimode base station, and base station controller. Base stations in this
document refer to eGBTSs, NodeBs, eNodeBs, co-MPT multimode base stations, and
separate-MPT multimode base stations. The GBTS does not support IP Active Performance
Measurement feature.
NOTE
The eGBTS using the GTMUb as main control boards does not support IP Active Performance
Measurement.
Table 1-1 lists the definitions of all kinds of base stations.
Issue 04 (2015-12-30) Huawei Proprietary and Confidential 1

SingleRAN
Table 1-1 Base station definitions
Base Station Definition

Name
GBTS A base station configured with a GTMU, GTMUb, or GTMUc and

maintained through a base station controller.
eGBTS A base station configured with a GTMUb, UMPT_G, or UMDU_G and

directly maintained by the element management system (EMS).
NodeB A base station configured with a WMPT, UMPT_U, or UMDU_U.
eNodeB A base station configured with an LMPT, UMPT_L, UMPT_T,

UMDU_L, or UMDU_T.
Co-MPT A base station configured with a UMPT_GU, UMDU_GU, UMPT_GL,

multimode base UMDU_GL, UMPT_GT, UMDU_GT, UMPT_UL, UMDU_UL,
station UMPT_UT, UMDU_UT, UMPT_LT, UMDU_LT, UMPT_GUL,
UMDU_GUL, UMPT_GUT, UMDU_GUT, UMPT_ULT, UMDU_ULT,
UMPT_GLT, UMDU_GLT, UMPT_GULT, or UMDU_GULT. A co-
MPT multimode base station functionally corresponds to any physical
combination of eGBTS, NodeB, and eNodeB. For example, a co-MPT
multimode base station configured with a UMPT_GU or UMDU_GU
functionally corresponds to the physical combination of eGBTS and
NodeB.
NOTE
Unless otherwise specified, the descriptions and examples of the UMPT in a co-
MPT base station also apply to the UMDU in a co-MPT base station.
Separate-MPT A base station on which each mode uses its separate main control board.
multimode base For example, a base station configured with a GTMU and WMPT is
station called a separate-MPT GSM/UMTS dual-mode base station.
NOTE
A UMDU cannot be used in a separate-MPT base station.
The Two-Way Active Measurement Protocol (TWAMP) has defined a security protection
mechanism. TWAMP does not use any security protection mechanism in this version.
However, you can enable security protection for this feature using IPsec at the IP layer.
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:

SingleRAN
l Feature change
Changes in features of a specific product version
l Editorial change
Changes in wording or addition of information that was not described in the earlier
version
SRAN10.1 04 (2015-12-30)
This issue includes the following changes.
Change Change Description Parameter Change

Type
Feature None None

change
Editorial Optimized descriptions in the following section: None

change 3.3 TWAMP Measurement Parameters
SRAN10.1 03 (2015-11-30)

Type
Feature None None

change

change 4.2 TWAMP Application on the Base Station
Side
4.3 TWAMP Application on the Base Station
Controller Side
SRAN10.1 02 (2015-08-30)

Type
Feature None None

change

change 7.4.1 Requirements

SingleRAN
SRAN10.1 01 (2015-03-23)
This issue does not include any changes.
SRAN10.1 Draft A (2015-01-15)

Compared with issue 03 (2014-12-20) of SRAN9.0, Draft A (2015-01-15) of SRAN10.1
includes the following changes.

Type
Feature Added the descriptions of IP Active Added two new

change Performance Measurement for the eGBTS using parameters:
a GTMUb board as the main control board. l PEERPORT
Added the descriptions that listening ports can l LOCALPORT
be configured for a TCP link. For details, see the
following sections:
3.2.2 Measurement Process
7.4 Feature Deployment
Added the descriptions of TWAMP application
on the base station side when a base station is
connected with the peer base station. For details
see 4.2 TWAMP Application on the Base
Station Side.
Added the descriptions of IP Active
Performance Measurement for a new interface
eX2, For details, see the following sections:
l 4.1 Differences Between TWAMP and
Huawei-Private IP PM
l 4.2 TWAMP Application on the Base
Station Side
l 7.4.1 Requirements
Editorial None None

change
1.4 Differences Between Base Station Types

Definition
The macro base stations described in this document refer to 3900 series base stations. These
base stations work in GSM, UMTS, or LTE mode, as listed in the section Scope.
The LampSite base stations described in this document refer to distributed base stations that
provide indoor coverage. These base stations work in UMTS or LTE mode but not in GSM
mode.

SingleRAN
The micro base stations described in this document refer to all integrated entities that work in
UMTS or LTE mode but not in GSM mode. Descriptions of boards, cabinets, subracks, slots,
and RRUs do not apply to micro base stations.
The following table defines the types of micro base stations.
Base Station Model RAT
BTS3202E LTE FDD
NOTE
The co-MPT and separate-MPT applications are irrelevant to single-mode micro base stations.
Feature Support by Macro, Micro, and LampSite Base Stations

Feature ID Feature Name Suppo Suppo Suppo
rted rted rted
by by by
Macro Micro Lamp
Base Base Site
Statio Statio Base
ns ns Statio
ns
GBFD-151201 BSC IP Active Performance Yes No No

Measurement
GBFD-151202 BTS IP Active Performance Yes No No

Measurement
WRFD-151211 RNC IP Active Performance Yes Yes Yes

Measurement
WRFD-151212 NodeB IP Active Performance Yes Yes Yes

Measurement
LOFD-070219 IP Performance Monitoring Yes Yes Yes
TDLOFD-003018 IP Performance Monitoring Yes No No
Function Implementation in Macro, Micro, and LampSite Base Stations

Function Difference
Active/standby Macro base stations support active/standby switchovers during IP

switchovers during IP Active Performance Measurement. Micro base stations do not
Active Performance involve the concept of board and therefore do not support active/
Measurement standby switchovers

SingleRAN
Description 2 Overview
2 Overview
The Internet Engineering Task Force (IETF) IP Performance Metrics (IPPM) working group
has defined configuration and maintenance standards for IP-based transmission networks.
These standards simplify performance tests and maintenance of end-to-end (E2E) Ethernet
links.
Huawei introduced the IP Active Performance Measurement feature in accordance with the
IETF IPPM standards listed in the following table.
Protocol Number Protocol Name
RFC5357 A Two-way Active Measurement Protocol (TWAMP)
RFC2680 A One-way Packet Loss Metric for IPPM
RFC2681 A Round-trip Delay Metric for IPPM
RFC3393 IP Packet Delay Variation Metric for IP Performance Metrics

(IPPM)
This feature measures IP performance on connections between network elements (NEs) and
devices that support TWAMP in a radio transmission network. The performance metrics
include one-way packet loss rate, round-trip delay, and one-way delay variation, which will be
elaborated in section 3.3 TWAMP Measurement Parameters.
IP performance measurement can be performed on connections between eNodeBs, between a
GSM/UMTS dual-mode base station and a base station controller, between an eNodeB and a
serving gateway (S-GW), between base station controllers, between a base station controller
and a core network (CN), between an NE in a radio network and a transmission device (for
example, a router), and between an NE in a radio network and a test device.
This document describes how to implement IP Active Performance Measurement based on
RFC5357: A Two-way Active Measurement Protocol (TWAMP).

SingleRAN
2.1 Description
The Internet Engineering Task Force (IETF) IP Performance Metrics (IPPM) working group
has defined configuration and maintenance standards for IP-based transmission networks.
These standards simplify performance tests and maintenance of end-to-end (E2E) Ethernet
links.
Huawei introduced the IP Active Performance Measurement feature in accordance with the
IETF IPPM standards listed in the following table.
Protocol Number Protocol Name
RFC5357 A Two-way Active Measurement Protocol (TWAMP)
RFC2680 A One-way Packet Loss Metric for IPPM
RFC2681 A Round-trip Delay Metric for IPPM
RFC3393 IP Packet Delay Variation Metric for IP Performance Metrics

(IPPM)
This feature measures IP performance on connections between network elements (NEs) and
devices that support TWAMP in a radio transmission network. The performance metrics
include one-way packet loss rate, round-trip delay, and one-way delay variation, which will be
elaborated in section 3.3 TWAMP Measurement Parameters.
IP performance measurement can be performed on connections between eNodeBs, between a
GSM/UMTS dual-mode base station and a base station controller, between an eNodeB and a
serving gateway (S-GW), between base station controllers, between a base station controller
and a core network (CN), between an NE in a radio network and a transmission device (for
example, a router), and between an NE in a radio network and a test device.
This document describes how to implement IP Active Performance Measurement based on
RFC5357: A Two-way Active Measurement Protocol (TWAMP).
2.2 Benefits
The IP Active Performance Measurement feature provides the following benefits:
l Quick transmission network performance monitoring

If the transmission rate is unstable and the transmission bandwidth changes, this feature
enables operators to quickly identify transmission network problems for future capacity
expansion and network optimization.
l Quick fault diagnosis
This feature uses TWAMP to quickly troubleshoot transmission faults, such as high
packet loss rate or long delay.
l Low maintenance costs
This feature enables troubleshooting a transmission network by segment, which
improves network maintainability and reduce maintenance costs.

SingleRAN
However, TWAMP uses User Datagram Protocol (UDP) packet injection, which generates
traffic and occupies bandwidth. For example, if 80-byte packets are continuously sent at a rate
of 10 packets per second in a test stream, a bandwidth of 6.4 kbit/s is consumed.

SingleRAN
Description 3 Technical Description
3 Technical Description
3.1 Position of TWAMP in the TCP/IP Protocol Stack

Figure 3-1 illustrates the position of TWAMP in the TCP/IP protocol stack.
Figure 3-1 Position of TWAMP in the TCP/IP protocol stack
TWAMP resides above IP packet fragmentation and assembly at the network layer, as shown
in Figure 3-1.
In accordance with TWAMP, this feature measures the transmission quality at the network
layer. The controller sends test packets before performing IP packet fragmentation. The
responder performs IP packet assembly before responding to the received test packets.
NOTE
It is recommended that the TWAMP protocol RFC5357 be used at the local and peer ends.
3.2 Basic Concepts

SingleRAN
3.2.1 Measurement Model

TWAMP defines the measurement model, as shown in Figure 3-2.
Figure 3-2 TWAMP measurement model
The TWAMP measurement model consists of four logical entities: Session-Sender, Session-
Reflector, Control-Client, and Server. TWAMP defines two packet types: control packet and
test packet. The following table describes the functions of these logical entities.
Control Plane Logical Entity Function

or Test Plane
Control plane Control-Client The Control-Client and Server exchange control

packets to initiate, start, and stop TWAMP test
Server sessions.
Test plane Session-Sender The Session-Sender sends test packets to the

Session-Reflector, which responds to test packets.
Session-
Reflector
In most cases, the Control-Client and Session-Sender are combined into one entity called
Controller, and the Server and Session-Reflector are combined into one entity called
Responder, as shown in Figure 3-3.
Figure 3-3 TWAMP measurement entities
The Controller actively transmits packets, collects measurement information, and provides
related statistics.

SingleRAN
The Responder passively responds to received packets.
3.2.2 Measurement Process

TWAMP measurement includes negotiation and testing. Negotiation is conducted between the
Control-Client and Server using TCP packets. The Server uses port 862 as the listening port
by default, and the listening port is configurable. Testing is conducted between the Session-
Sender and Session-Reflector based on the UDP. The used UDP ports are assigned and
managed inside each NE and negotiated between NEs, as shown in Figure 3-4.
Figure 3-4 TWAMP negotiation process
TWAMP measurement includes four phases: establishing a TCP connection, creating test
sessions, starting test sessions, and testing.
Phase 1: Establishing a TCP connection
1. The Control-Client initiates a TCP connection to the Server on the listening port of the
Server.
2. The Server responds with a Server-Greeting message, indicating the mode of
communication it supports.
3. The Control-Client responds with a Set-UP-Response message with its chosen mode of
communication. However, if the Server does not respond or responds with an unexpected
mode of communication, the Control-Client closes the connection.
4. The Server responds with a Server-Start message, indicating the start time of the test.
The connection setup is complete.
Phase 2: Creating test sessions

SingleRAN
The following commands are available for the Control-Client: Request-TW-Session, Start-
Sessions, and Stop-Sessions. The Server responds to these commands by sending one of the
following messages: Accept-Session, Start-Ack, and Stop-Sessions.
In this phase, the test negotiation starts.
1. The Control-Client sends a Request-TW-Session message to negotiate with the Server
about the UDP transmit port number, UDP receive port number, IP address, and
differentiated services code point (DSCP).
2. The Server responds with an Accept-Session message, indicating that it accepts the
negotiated results. The Server can respond with a different UDP port number for the
Control-Client to use. The Control-Client receives the port number and enters the next
phase.
Phase 3: Starting test sessions
1. The Control-Client sends a Start-Session message, indicating that it starts a test session.
2. The Server responds with a Start-Ack message, indicating that it accepts the test session.
Phase 4: Testing
UDP packets are used for testing. The Session-Sender actively sends test packets to the
Session-Reflector in a fixed stream with the same Session-Sender IP address, Session-
Reflector IP address, source UDP port number, destination UDP port number, and DSCP.
The test packets can be transmitted in unauthenticated mode, authenticated mode, or
encrypted mode.
l In unauthenticated mode, neither shared keys nor hashed message authentication code
(HMAC) keys are used.
l In authenticated mode, the public key is used.
l In encrypted mode, negotiation packets and test packets are encrypted.
Currently, this feature supports only the unauthenticated mode.
3.3 TWAMP Measurement Parameters

TWAMP actively inserts test packets into links being tested and calculates the packet loss
rate, round-trip delay, and delay variation based on the fields contained in the test packets.
Figure 3-5 shows the test process.
1. The Session-Sender sends test packets containing sequence numbers and timestamp T1.
2. The Session-Reflector records timestamp T2 upon receiving the test packets from the
Session-Sender. The Session-Reflector then copies the sequence numbers and timestamp
T1 into the reflected packets and also includes the Session-Reflector's transmit sequence
numbers and timestamp T3 in the reflected packets.
3. Upon receiving the reflected packets, the Session-Sender records timestamp T4 and
calculates the number of received packets.
Figure 3-5 Test process

SingleRAN
The Session-Sender sends packets at an interval of 10 ms to 1000 ms. The interval can be set
in the TWAMPSENDER managed object (MO).
NOTE
Test packets can be sent based on the source IP address, destination IP address, DSCP, source UDP port
number, and destination UDP port number.
The Session-Reflector processes a test packet as soon as possible.
TWAMP defines negotiation timeout and test timeout for the Responder, which can be configured by the
SERVWAIT and REFWAIT parameters, respectively.
l SERVWAIT: The Server closes the connection during the negotiation if it has not received any
negotiation packet within the period specified by this parameter. This parameter is configurable with
the default value of 900s.
l REFWAIT: During a test, the Session-Reflector releases resources if it has not received any test
packets within the period specified by this parameter. This parameter is configurable with the default
value of 900s. When a base station or base station controller serves as the Controller, it reinitiates a
negotiation if it has not received any test packets within 900s during the test. This occurs because the
Controller assumes that the peer end may have deleted the session.
3.3.1 Packet Loss Rate

The packet loss rate indicates the transmission quality of a tested IP link.
The calculation formulas are as follows:
Forward packet loss rate = (Number of packets transmitted by the Session-Sender Number
of packets transmitted by the Session-Reflector)/Number of packets transmitted by the
Session-Sender
Backward packet loss rate = (Number of packets transmitted by the Session-Reflector
Number of packets received by the Session-Sender)/Number of packets transmitted by the
Session-Reflector
NOTE
Forward: from Session-Sender to Session-Reflector

Backward: from Session-Reflector to Session-Sender
3.3.2 Round-Trip Delay

The round-trip delay is the length of time it takes for a packet to be sent plus the length of
time it takes for an acknowledgment of that packet to be received. The round-trip delay
indicates the delay in a transmission network.
This feature uses the following formula to calculate the round-trip delay:
Round-trip delay = (T2 - T1) + (T4 - T3) = (T4 - T1) - (T3 - T2)
For details about these timestamps, see section 3.3 TWAMP Measurement Parameters.
3.3.3 Delay Variation

The delay variation indicates the difference between delays of selected packets on an IP link.
This feature calculates the delay variation based on the delays of two adjacent test packets.
Forward delay variation indicates the difference between the forward delays of two adjacent
test packets.

SingleRAN
Backward delay variation indicates the difference between the backward delays of two
adjacent test packets.
NOTE
TWAMP results may be inaccurate during router switchovers and active/standby Ethernet port
switchovers.
TWAMP supports active/standby board switchovers. If the Controller experiences an active/standby
board switchover, it reinitiates a negotiation and restarts a test until the negotiation is successful. If the
Responder experiences an active/standby board switchover, it will not respond to any tests, and the
ongoing TWAMP test will be affected.

SingleRAN
Description 4 TWAMP Application
4 TWAMP Application
4.1 Differences Between TWAMP and Huawei-Private IP

PM
TWAMP applies to the following interfaces:
l GSM interfaces: Abis, A, and Gb

l UMTS interfaces: Iub, Iu, and Iur
l LTE interface: S1, X2 and eX2
The working principles of TWAMP on these interfaces are the same. For details about these
working principles, see chapter 3 Technical Description.
The following paragraphs explain the differences between TWAMP and Huawei-private IP
PM from technical and application perspectives.
Technical Differences
Table 4-1 describes their technical differences between TWAMP and Huawei-private IP PM.
Table 4-1 Technical differences between TWAMP and Huawei-private IP PM

Item Huawei-Private IP TWAMP
PM
Interconnection The peer device must The peer device can be provided by any
be provided by vendors as long as it supports TWAMP.
Huawei.
Test Service packets are Injected test packets are measured. Offline
measured. measurement is recommended.
Restriction Huawei-private IP l Packet injection affects ongoing services

PM applies only to and occupies bandwidth.
online services. l The peer device must support TWAMP.

SingleRAN
NOTE
Huawei-private IP PM uses the combination of source IP address, destination IP address, UDP, and
DSCP or the combination of source IP address, destination IP address, and UDP to identify a
transmission link. TWAMP uses the combination of source IP address, destination IP address, source
UDP port number, destination UDP port number, and DSCP to identify a transmission link.
Application Differences
Both TWAMP and Huawei-private IP PM measure the transmission quality in real time.
Huawei-private IP PM is recommended if both ends use Huawei devices, for example,
between a Huawei base station and a Huawei base station controller, between a Huawei
eNodeB and a Huawei S-GW, and between two Huawei base stations. TWAMP is
recommended if devices provided by different vendors are used at the two ends, for example,
between a Huawei base station or base station controller and a transmission device provided
by another vendor.
TWAMP and Huawei-private IP PM are complementary. Only TWAMP is available to the
following scenarios:
l When a base station fails to provide services but the connection between the base station
and transmission network is in good condition
l When there is no traffic or the traffic is light, for example, in the early morning
l When both local and peer devices support TWAMP
Table 4-2 Application differences between TWAMP and Huawei-private IP PM

Item Scenario Huawei- TWAMP
Private IP
PM
Maintenanc When there are no ongoing services Not Supported

e and testing supported
Iub/Abis connections between the base Huawei-private IP PM is

station and base station controller recommended.
Between the base station or base station Not Supported

controller and a transmission device in supported
the transmission network
QoS measurement of S1/X2/eX2 Huawei-private IP PM is

connections between an eNodeB and a recommended.
Huawei S-GW/eNodeB
QoS measurement of S1/X2 Not Supported

connections between an eNodeB and a supported
non-Huawei S-GW/eNodeB
Monitoring Online monitoring of wireless services Supported Not

on the Iub/Abis/S1/X2/eX2 interface supported
QoS monitoring of transmission Not Supported

between a base station/base station supported
controller and a router or a non-Huawei
S-GW

SingleRAN
4.2 TWAMP Application on the Base Station Side

This section describes the TWAMP application on the base station side. The related features
are as follows:
l GSM: GBFD-151202 BTS IP Active Performance Measurement

l UMTS: WRFD-151212 NodeB IP Active Performance Measurement
l LTE: LOFD-070219 IP Active Performance Measurement
l LTE: TDLOFD-003018 IP Active Performance Measurement
When TWAMP is applied on a base station, the roles of the base station differ depending on
the connected peer device.
NOTE
TWAMP application on the co-MPT multimode base station is the same as TWAMP application on the
eGBTS, NodeB, and eNodeB.
Table 4-3 Base station's roles with TWAMP
Peer Device Base Station's Role
Transmission The base station is configured as the TWAMP Controller because most
device transmission devices can work as the TWAMP Responder.
S-GW When a non-Huawei S-GW is used, it is recommended that the S-GW

and eNodeB be configured as the TWAMP Responder and TWAMP
Controller, respectively.
Base station Huawei-private IP PM is preferred when there are ongoing services.

controller TWAMP is used when there is no service. It is recommended that the
base station controller and base station be configured as the TWAMP
Controller and TWAMP Responder, respectively.
Test device When a test device, such as Sprient TestCenter, supports TWAMP, the
test device and base station are configured as the TWAMP Responder
and TWAMP Controller, respectively.
Peer base station Generally, the local base station is configured as the TWAMP
Controller, and the peer base station is configured as the TWAMP
Responder.
4.2.1 TWAMP Controller Function

When the eGBTS/NodeB/eNodeB serves as the TWAMP Controller, it is responsible for
initiating tests, collecting statistics, and displaying test results at the local end. The peer end,
for example, a router, base station controller, or eNodeB serves as the Responder, which
transmits and receives the negotiation and test packets.

SingleRAN
A base station supports 16 Control-Clients, each supporting a maximum of 16 Session-Sender

test streams. A base station supports 16 Session-Sender test streams in total. Run the ADD
TWAMPCLIENT and ADD TWAMPSENDER commands to activate a test.
4.2.2 TWAMP Responder Function

When the eGBTS/NodeB/eNodeB serves as the TWAMP Responder, it passively responds to
test packets. The base station controller, eNodeB, or test device at the peer end serves as the
TWAMP Controller, which actively initiates tests.
A base station supports four Responders, each supporting a maximum of 16 passive response
test streams. A base station supports 16 passive response test streams in total. Run the ADD
TWAMPRESPONDER command to enable the TWAMP Responder function.
4.2.3 Networking Scenarios

Table 4-4 provides the networking scenarios in which a base station supports TWAMP.
Table 4-4 Networking scenarios in which a base station supports TWAMP
Networking Scenario Description
Port level FE/GE/10GE ports as the transmission -

ports
E1/T1 ports as the transmission ports E1/T1 ports are provided

by the WMPT, UMPT, or
UMDU board.
UMPT interconnection port -
Link level Active and standby routes -
Board level UTRPc as the transmission interface Enable TWAMP on the

board in a multimode base station UTRPc board.
UCCU board -
Site level Cascaded base stations TWAMP can be used on

all cascaded base stations.
4.3 TWAMP Application on the Base Station Controller

Side
This section describes the TWAMP application on the base station controller side. The related
features are as follows:
l GSM: GBFD-151201 BSC IP Active Performance Measurement

l UMTS: WRFD-151211 RNC IP Active Performance Measurement
When TWAMP is applied on a base station controller, the roles of the base station controller
differ depending on the connected peer device.

SingleRAN
Table 4-5 Base station controller's roles with TWAMP
Peer Device Base Station Controller's Role
Transmission The base station controller is configured as the TWAMP Controller

device because most transmission devices support the TWAMP Responder
function.
Base station Huawei-private IP PM is preferred when there are ongoing services.

TWAMP is used when there is no service. It is recommended that the
base station and base station controller be configured as the TWAMP
Responder and TWAMP Controller, respectively.
4.3.1 TWAMP Controller Function

When the BSC/RNC serves as the TWAMP Controller, it is responsible for actively initiating
tests, collecting statistics, and displaying test results at the local end. The peer end, for
example, a router, base station controller, base station, or S-GW serves as the Responder,
which transmits and receives negotiation and test packets.
A base station controller supports 1024 Control-Clients, each supporting a maximum of 16

Session-Sender test streams. A base station controller supports 1024 Session-Sender test
streams in total. Run the ADD TWAMPCLIENT and ADD TWAMPSENDER commands
to activate a test.
4.3.2 TWAMP Responder Function

When the BSC/RNC serves as the TWAMP Responder, it passively responds to test packets.
The base station controller, base station, test device, or S-GW at the peer end serves as the
TWAMP Controller, which actively initiates tests.
A base station controller supports 1024 Responders, each supporting a maximum of 160
passive response test streams. A base station controller supports 1024 passive response test
streams in total. Run the ADD TWAMPRESPONDER command to enable the TWAMP
Responder function.
4.3.3 Networking Scenarios

Table 4-6 provides the networking scenarios in which a base station controller supports
TWAMP.
Table 4-6 Networking scenarios in which a base station controller supports TWAMP
Networking Scenario Supported/No Description

t Supported
Port level FE/GE ports as the transmission Supported The FG2c/FG2d/

ports GOUc/GOUe/
GOUd/EXOUa
board supports
TWAMP.

SingleRAN
Networking Scenario Supported/No Description

t Supported
IP over E1/TI applied on the RNC Not supported -
Link Active and standby link aggregation Supported -

level groups (LAGs)
LAGs working in load sharing Supported -

mode
Routes working in load sharing Supported -

mode
Active and standby routes Supported -
Board Active and standby boards Supported -

level
Interface boards working in Supported An IP address is
transmission resource pool mode assigned at the local
end for starting
TWAMP tests.

SingleRAN
Description 5 Related Features
5 Related Features
5.1 GBFD-151202 BTS IP Active Performance

Measurement
Prerequisite Features
Feature ID Feature Name Description
GBFD-118601 Abis over IP -
Mutually Exclusive Features

None
Impacted Features
Function Name Description
The UDP loopback On the base station side, if one TWAMP test end is enabled with
function the UDP loopback function and a specified IP address or all IP
addresses are used for TWAMP testing, test packets will be
directly looped back, resulting in inaccurate statistics. If the base
station functions as the TWAMP Controller, the Responder's
response packets will be looped back. As a result, UDP packets are
retransmitted between the local end and peer end (Responder),
which consumes more network resources.

SingleRAN
5.2 GBFD-151201 BSC IP Active Performance

Measurement
GBFD-118601 Abis over IP When IP Active Performance Measurement is

applied to the BSC6900 or BSC6910 on the
Abis interface.
GBFD-118602 A over IP When IP Active Performance Measurement is

applied to the BSC6900 on the A interface.
GBFD-118603 Gb over IP When IP Active Performance Measurement is

applied to the BSC6900 or BSC6910 on the
Gb interface.
GBFD-150201 A over IP Based on When IP Active Performance Measurement is

Dynamic Load applied to the BSC6910 on the A interface.
Balancing

None
Impacted Features
None
5.3 WRFD-151212 NodeB IP Active Performance

Measurement
WRFD-050402 IP Transmission Introduction -

on Iub Interface

None

SingleRAN
Impacted Features
IP performance When a WMPT is configured on a base station and TWAMP and

monitoring Huawei-private IP PM are enabled simultaneously, Huawei-private
IP PM fails to measure the test packets of TWAMP due to WMPT
restrictions, resulting in inaccurate IP PM statistics.
5.4 WRFD-151211 RNC IP Active Performance

Measurement
WRFD-050402 IP Transmission In non-IP pool networking, when IP Active

Introduction on Iub Performance Measurement is applied on the Iub
Interface interface.

Introduction on Iu Performance Measurement is applied on the Iu

Introduction on Iur Performance Measurement is applied on the Iur
WRFD-140207 Iu/Iur Transmission In IP pool networking, when IP Active

Resource Pool of Performance Measurement is applied to the
RNC BSC6900 on the Iu/Iur interface.
WRFD-140208 Iub Transmission In IP pool networking, when IP Active

Resource Pool of Performance Measurement is applied to the
RNC BSC6900 on the Iub interface.
WRFD-150243 Iub IP Transmission In IP pool networking, when IP Active

Based on Dynamic Performance Measurement is applied to the
Load Balancing BSC6900 on the Iub interface.

SingleRAN
WRFD-150244 Iu/Iur IP In IP pool networking, when IP Active

Transmission Based Performance Measurement is applied to the
on Dynamic Load BSC6900 on the Iu/Iur interface.
Balancing

None
Impacted Features
None
5.5 LOFD-070219/TDLOFD-003018 IP Active Performance

Measurement
None

None
Impacted Features

SingleRAN
Description 6 Network Impact
6 Network Impact
System Capacity
Because TWAMP negotiation packet interaction occurs in the protocol stack and only a small
number of packets are involved, TWAMP has negligible impact on CPU performance.
TWAMP test packets affect the UP forwarding performance because they are transmitted and
received on the UP. The greater the transmit rate of test packets, the greater the resource
consumption of TWAMP forwarding. However, TWAMP forwarding resource consumption
still has negligible impact when compared with the base station and base station controller's
forwarding capabilities.
Network Performance
TWAMP testing uses packet injection, which generates traffic in the transport network and
therefore occupies some bandwidth. The bandwidth consumption is related to the transmit rate
of test packets. Users can specify the transmit interval and length for the packets to be
transmitted.
In maintenance and testing scenarios, if you are not sure whether the transmit rate (determined
by the IP path, resource group, and port) on transmission links is close to the planned
bandwidth, transmitting a small number of packets at an appropriate interval (low-traffic) is
recommended for a TWAMP test. For example, if 80-byte packets are continuously sent at a
rate of 10 packets per second in a test stream, the bandwidth consumption is 6.4 kbit/s.
In monitoring scenarios, it is recommended that you reserve bandwidth for TWAMP tests so
that test packets can be sent continuously. If 80-byte packets are sent at a rate of 10 packets
per second in a test stream, the bandwidth consumption is 6.4 kbit/s. You can monitor the test
stream to check whether any transmission faults are occurring.

SingleRAN
Description 7 Engineering Guidelines
7 Engineering Guidelines
7.1 When to Use IP Active Performance Measurement

It is recommended that you enable the IP Active Performance Measurement feature to
monitor transport networks if the bandwidth is sufficient. It is recommended that you only
enable this feature temporarily for troubleshooting transport network faults if the bandwidth
of the transport network is limited when a data service performance fault occurs, such as an
unstable download rate. After the troubleshooting is complete, disable this feature.
Table 7-1 provides the maximum specifications of TWAMP sessions supported by the base
station controller and base station.
Table 7-1 Maximum specifications of TWAMP sessions supported by different NEs

NE Maximum Specifications of TWAMP
Sessions Supported
BSC/RNC l Session-Sender
160 per board
1024 per BSC/RNC
l Control-Client
160 per board
1024 per BSC/RNC
l Responder
32 per board
1024 per BSC/RNC

SingleRAN
NE Maximum Specifications of TWAMP

Sessions Supported
eGBTS/NodeB/eNodeB l Session-Sender
16 per board
16 per base station
l Control-Client
16 per board
16 per base station
l Responder
4 per board
4 per base station
7.2 Required Information

Obtain the bandwidth usage of the transport network.
7.3 Planning
RF Planning
None
Network Planning
None
Hardware Planning
None
7.4 Feature Deployment
7.4.1 Requirements
NE
l The BSC6900/BSC6910 must be configured with the FG2c/FG2d/GOUc/GOUe/GOUd/
EXOUa to support TWAMP.
l The eGBTS/NodeB/eNodeB must be configured with the WMPT/LMPT/UMPT/
UMDU/UTRPc/UCCU to support TWAMP.
License
l Licenses for the features listed in the following table must be purchased and activated.

SingleRAN
Feature Feature License License NE Sales

ID Name Control Item Control Item Unit
ID
GBFD-15 BSC IP Active LGMIBSCTW BSC IP Active BSC Per

1201 Performance AMP Performance TRX
Measurement Measurement
GBFD-15 BTS IP Active LGB3TWAMP BTS IP Active BTS Per

1202 Performance 01 Performance BTS
WRFD-1 RNC IP Active LQW1RNCTW RNC IP Active RNC Per Erl

51211 Performance AMPRESE & Performance &
Measurement LQW1RNCTW Measurement Mbps
AMPRESM
WRFD-1 NodeB IP LQW9IPAPM0 NodeB IP NodeB Per

51212 Active 1 Active NodeB
Performance Performance
LOFD-07 IP Active LT1S0IPAPM0 IP Active eNode Per

0219 Performance 0 Performance B eNode
Measurement Measurement B
(FDD)
TDLOFD IP Active LT1SIPAPM00 IP Active eNode Per

-003018 Performance 0 Performance B eNode
Measurement Measurement B
(TDD)
Other
l During TWAMP measurement, one end serves as the TWAMP Controller while the other
end serves as the TWAMP Responder.
l Virtual local area network (VLAN) Planning and Configuration
Base station controller: VLAN tags can be added to negotiation and test packets
based on the next hop.
Base station: In single VLAN mode, VLAN tags can be added to negotiation and
test packets based on the next hop. In VLAN group mode, negotiation packets use
the VLAN of the OM_H configured in the next hop and test packets use the VLAN
of the data packets configured with the same DSCP in the next hop.
7.4.2 Precautions
None
7.4.3 Data Preparation

TWAMP on the base station side is independent of that on the base station controller side.
However, the MML commands, parameters, and data preparation are the same, as shown in
Table 7-2and Table 7-3.

SingleRAN
Table 7-2 Data preparation for the TWAMP Controller function

MO Parameter Parameter ID Setting Notes Data Source
Name
TWAMPCLIE Local IP LocalIP - Network plan

NT Address
Peer IP Address PeerIP - Network plan
Peer TCP Port PEERPORT - Network plan

No
Client Index ClientID - Network plan
VRF Index VRFINDEX - Network plan

(only for base
stations)
Differentiated DSCP The default Internal plan

services code value is 46.
point
TWAMPSEND Differentiated DSCP It is Network plan

ER services code recommended
point you set this
parameter to the
priority of the
service packets
for which the
user shows
concern.
Packet Size PktSizeType The default Internal plan

Type value Fixed is
recommended.
Packet Size PktSize The default Internal plan

value is 128
bytes.
Packet Send PktIntType The default Internal plan

Interval Type value is Fixed.
Packet Interval PktInt - Internal plan

SingleRAN
NOTE
The local end actively transmits packets when it functions as the TWAMP Controller. The bandwidth
consumed by the transmitted packets can be set using the PktSize and PktInt parameters.
l Services packets are simulated in TWAMP tests, which occupy some bandwidth. To prevent services
from being affected, it is recommended that you enable IP Active Performance Measurement only
when you are familiar with this feature and TWAMP. To minimize risks and negative impacts on
services, the PktSize and PktInt parameters are set to their default values 128ms and 1000ms,
respectively. In this case, the bandwidth consumed by the transmitted packets is only 1 kbit/s.
l TWAMP testing uses packet injection and the test accuracy is related to the packet transmit rate. The
greater the packet transmit rate, the higher the accuracy. You can modify the PktInt parameter to
increase the packet transmit rate for higher accuracy if there is sufficient network bandwidth.
Table 7-3 Data preparation for the TWAMP Responder function
MO Parameter Parameter ID Setting Notes Data Source

Name
TWAMPR Local IP Address LocalIP - Network plan

ESPONDE
R Local TCP Port LOCALPORT - Network plan
No
Responder Index ResponderID - Network plan
VRF Index (only VRFINDEX - Internal plan

for base stations)
Differentiated DSCP The default Internal plan

services code value is 46.
point
Negotiation Wait SERVWAIT The default Internal plan

Time value defined
by the protocol
900s is
recommended.
Measurement REFWAIT The default Internal plan

Wait Time value defined
by the protocol
900s is
recommended.
Table 7-4 TWAMP communication matrix requirements on base stations and base station
controllers
NE Transmit Function TCP UDP

/Receive
Source Port Destination Source Destinatio
Port Port n Port
Base Transmit Controller 1024-65535 1-65535 64695-647 *

Station 10

SingleRAN
Responder 862, * 64679-646 *

1024-65535 95
Receive Controller 1-65535 1024-6553 * 64695-647

5 10
Responder * 862, * 64679-646

1024-6553 94
5
Base Transmit Controller 5201-6225 1-65535 64968-649 *

station 83
control
ler Responder 862, * 64984-649 *
1024-65535 99
Receive Controller 1-65535 5201-6225 * 64968-649

83
Responder * 862, * 64984-649

1024-6553 99
5
NOTE
The symbol "*" indicates no port restriction.

When serving as the TWAMP Controller, the local end sends the TWAMP Responder a Request-TW-
Session message with the Receiver Port number allocated to the peer end being a fixed value during the
negotiation. If the TWAMP Responder does not accept the Receiver Port number sent by the local end, it
must reply with an Accept-Session message containing an appropriate UDP port number. Otherwise, the
negotiation may fail.
7.4.4 Activation
This section describes how to activate the TWAMP functions using MML commands and the
CME.
Using MML Commands

NOTE
When MML commands are used, the commands are the same for the base station and base station
controller.
To activate the TWAMP Controller function on the local end, perform the following steps:
Step 1 Run the MML command ADD TWAMPCLIENT to set the TWAMP Control-Client, which
sends negotiation packets to establish TCP connections with the Responder, and negotiates
control information (such DSCP and UPD ports) for test sessions.
Step 2 Run the MML command ADD TWAMPSENDER to set the TWAMP Session-Sender, which
sends measurement packets and collects measurement information.
----End
To activate the TWAMP Responder function on the local end, perform the following steps:

SingleRAN
Step 1 Run the MML command ADD TWAMPRESPONDER to configure the TWAMP
Responder, which responds to the negotiation packets and measurement packets sent by the
TWAMP Controller.
----End
NOTE
Either of the following operations results in a TWAMP re-negotiation, which takes about two minutes:
l A modification to the TWAMPCLIENT or TWAMPSENDER MO
l Removal and subsequent addition of the TWAMPSENDER MO
MML Command Examples

The local end serves as the TWAMP Controller.
//Configuring the TWAMP Control-Client on the local end:
ADD TWAMPCLIENT: CLIENTID=0, LOCALIP="192.168.11.110", PEERIP="192.168.22.220",
PEERPORT=862;
//Configuring the TWAMP Session-Sender on the local end:

ADD TWAMPSENDER: ClientID=0, SenderID=0, PktSizeType=FIXED, PktIntType=FIXED;
The local end serves as the TWAMP Responder.

//Configuring the TWAMP Responder on the local end:
ADD TWAMPRESPONDER: RESPONDERID=0, LOCALIP="192.168.22.220", LOCALPORT=862;
Using the CME to Perform Single Configuration

The BSC6900/6910 and eGBTS/NodeB/eNodeB support using the CME to perform single
configuration on the TWAMP Controller function and TWAMP Responder function.
Step 1 On the CME, set BSC6900/6910 and eGBTS/NodeB/eNodeB parameters according to the
operation sequence in Table 7-2 and Table 7-3. For detailed instructions, see CME Single
Configuration Operation Guide
----End
Using the CME to Perform Batch Configuration

The eGBTS/NodeB/eNodeB supports using the CME to perform batch configuration on the
TWAMP Controller function and TWAMP Responder function, but the BSC6900/6910 does
not.
TWAMP is enabled after a device functions well. Batch reconfiguration using the CME is the
recommended method to activate IP Active Performance Measurement on base stations. This
method reconfigures all data, except neighbor relationships, for multiple eGBTSs/NodeBs/
eNodeBs using a single procedure. The procedure is as follows:
Step 1 Choose CME > Advanced > Customize Summary Data File from the main menu of an
U2000 client, or choose Advanced > Customize Summary Data File from the main menu of
a CME client, to customize a summary data file for batch reconfiguration.
NOTE
For context-sensitive help on a current task in the client, press F1.

SingleRAN
Step 2 Export the NE data stored on the CME into the customized summary data file.
l For co-MPT multimode base stations: Choose CME > SRAN Application > MBTS
Application > Export Data > Export Base Station Bulk Configuration Data from the
main menu of the U2000 client, or choose SRAN Application > MBTS Application >
Export Data > Export Base Station Bulk Configuration Data from the main menu of
the CME client.
l For separate-MPT GSM-involved multimode base stations or GO base stations: Choose
CME > GSM Application > Export Data > eGBTS Bulk Configuration Data from
the main menu of the U2000 client, or choose GSM Application > Export Data >
Export eGBTS Bulk Configuration Data from the main menu of the CME client.
l For separate-MPT UMTS-involved multimode base stations or UO base stations: Choose
CME > UMTS Application > Export Data > Export Base Station Bulk
Configuration Data from the main menu of the U2000 client, or choose UMTS
Application > Export Data > Export Base Station Bulk Configuration Data from the
main menu of the CME client.
l For separate-MPT LTE-involved multimode base stations or LO base stations: Choose
CME > LTE Application > Export Data > Export Base Station Bulk Configuration
Data from the main menu of the U2000 client, or choose LTE Application > Export
Data > Export Base Station Bulk Configuration Data from the main menu of the
CME client.
Step 3 In the summary data file, set the parameters in the MOs listed in Table 7-5 and close the file.
Table 7-5 TWAMP summary data file

MO Sheet in the Parameter Group
Summary Data
File
TWAMPCLIENT Transport Data See Table 7-2
TWAMPSENDER Transport Data See Table 7-2
TWAMPRESPONDER Transport Data See Table 7-3
Step 4 Import the summary data file into the CME.

l For co-MPT multimode base stations: Choose CME > SRAN Application > MBTS
Application > Import Base Station Bulk Configuration Data from the main menu of
the U2000 client, or choose SRAN Application > MBTS Application > Import Data >
Import Base Station Bulk Configuration Data from the main menu of the CME client.
l For separate-MPT GSM-involved multimode base stations or GO base stations: Choose
CME > GSM Application > Import Data > Import eGBTS Bulk Configuration Data
from the main menu of the U2000 client, or choose GSM Application > Import Data >
Import eGBTS Bulk Configuration Data from the main menu of the CME client.
l For separate-MPT UMTS-involved multimode base stations or UO base stations: Choose
CME > UMTS Application > Import Data > Import Base Station Bulk
Configuration Data from the main menu of the U2000 client, or choose UMTS
Application > Import Data > Import Base Station Bulk Configuration Data from the
main menu of the CME client.
l For separate-MPT LTE-involved multimode base stations or LO base stations: Choose
CME > LTE Application > Import Data > Import Base Station Bulk Configuration

SingleRAN
Data from the main menu of the U2000 client, or choose LTE Application > Import
Data > Import Base Station Bulk Configuration Data from the main menu of the
CME client.
----End
7.4.5 Activation Observation

After activating the TWAMP functions, use either of the following methods to verify whether
the TWAMP functions have been successfully activated.
The MML commands are the same for the base station and base station controller.
Using MML Commands

If the local end serves as the TWAMP Controller, perform the following operations for
activation observation:
Step 1 Query the local Control-Client status by running the DSP TWAMPCLIENT command 2
minutes after the TWAMP Controller function is enabled.
l For a base station controller: If Negotiation Status is Negotiation succeeded, TWAMP
negotiation on the CP was successful.
l For a base station: If Negotiation Status is CONTROL_LINK_UP, TWAMP
negotiation on the CP was successful.
Step 2 Query the local Session-Sender status by running the DSP TWAMPSENDER command.
l For a base station controller: If Negotiation Status is Negotiation succeeded, the
TWAMP test session was negotiated successfully.
l For a base station: If Negotiation Status is SESSION_UP, the TWAMP test session was
negotiated successfully.
----End
The MML commands are the same on the base station controller side and on the base station
side.
If the local end serves as the TWAMP Responder, perform the following operations for
activation observation:
Step 1 Query the local Responder status by running the DSP TWAMPRESPONDER command.
l For a base station controller: If Negotiation Status is Session succeeded, the TWAMP
test session was negotiated successfully.
l For a base station: If Negotiation Status is SESSION_UP, the TWAMP test session was
negotiated successfully.
----End
Using Performance Statistics

Collect values of TWAMP performance counters for the base station controller and base
station. If none of the counter values are null, the IP Active Performance Measurement feature
has been successfully activated. Table 7-6 and Table 7-7 provide TWAMP performance
counters on the base station controller side and base station side, respectively.

SingleRAN
Table 7-6 TWAMP performance counters on the base station controller side
Counter ID Counter Name Counter Description
73443310 VS.TWAMP.Forward.DropRates.Mea Average Forward Packet Loss

n Rates for TWAMP
Measurement
73443304 VS.TWAMP.Forward.DropRates.Ma Peak Forward Packet Loss

x Rates for TWAMP
Measurement
73443305 VS.TWAMP.Backward.DropRates.M Average Backward Packet Loss

ean Rates for TWAMP
Measurement
73443306 VS.TWAMP.Backward.DropRates.M Peak Backward Packet Loss

ax Rates for TWAMP
Measurement
73426982 VS.TWAMP.RttDelay.Min Minimum RTT for TWAMP

Measurement
73443307 VS.TWAMP.RttDelay.Mean Average RTT for TWAMP

Measurement
73426983 VS.TWAMP.RttDelay.Max Maximum RTT for TWAMP

Measurement
73426985 VS.TWAMP.Forward.Jitter.Min Minimum Forward Delay

Jitters for TWAMP
Measurement
73443308 VS.TWAMP.Forward.Jitter.Mean Average Forward Delay Jitters

for TWAMP Measurement
73426986 VS.TWAMP.Forward.Jitter.Max Maximum Forward Delay

Jitters for TWAMP
Measurement
73426989 VS.TWAMP.Backward.Jitter.Min Minimum Backward Delay

Jitters for TWAMP
Measurement
73443309 VS.TWAMP.Backward.Jitter.Mean Average Backward Delay

Jitters for TWAMP
Measurement
73426990 VS.TWAMP.Backward.Jitter.Max Maximum Backward Delay

Jitters for TWAMP
Measurement

SingleRAN
Table 7-7 TWAMP performance counters on the base station side

Counter ID Counter Name Counter Description
1542455996 VS.BSTWAMP.Forward.DropMeans Average forward packet loss

rate on the BSTWAMP
1542455997 VS.BSTWAMP.Forward.Peak.DropR Peak forward packet loss rate

ates on the BSTWAMP
1542455998 VS.BSTWAMP.Backward.DropMean Average backward packet loss

s rate on the BSTWAMP
1542455999 VS.BSTWAMP.Backward.Peak.Drop Peak backward packet loss rate

Rates on the BSTWAMP
1542456000 VS.BSTWAMP.MinRttDelay Minimum RTT on the

BSTWAMP
1542456001 VS.BSTWAMP.Rtt.Means Average RTT on the

BSTWAMP
1542456002 VS.BSTWAMP.MaxRttDelay Maximum RTT on the

BSTWAMP
1542456003 VS.BSTWAMP.Forward.MinJitter Minimum forward jitter on the

BSTWAMP
1542456004 VS.BSTWAMP.Forward.Jitter.Means Average forward jitter on the

BSTWAMP
1542456005 VS.BSTWAMP.Forward.MaxJitter Maximum forward jitter on the

BSTWAMP
1542456006 VS.BSTWAMP.Backward.MinJitter Minimum backward jitter on

the BSTWAMP
1542456007 VS.BSTWAMP.Backward.Jitter.Mean Average backward jitter on the

s BSTWAMP
1542456008 VS.BSTWAMP.Backward.MaxJitter Maximum backward jitter on

the BSTWAMP
7.4.6 Hardware Adjustment

None
7.4.7 Deactivation
The MML commands for deactivating the TWAMP functions are the same for the base station
controller and base station.
Using MML Commands

Step 1 Run the RMV TWAMPSENDER command to remove a TWAMP Session-Sender.

SingleRAN
NOTE
You must remove all the Session-Senders corresponding to a Control-Client before removing the
Control-Client.
Step 2 Run the RMV TWAMPCLIENT command to remove a TWAMP Control-Client.
Step 3 Run the RMV TWAMPRESPONDER command to deactivate the TWAMP Responder
function.
----End
MML Command Examples

//Removing the TWAMP Session-Sender
RMV TWAMPSENDER: ClientID=0, SenderID=0;
//Removing the TWAMP Control-Client

RMV TWAMPCLIENT: ClientID=0;
//Deactivating the TWAMP Responder function

RMV TWAMPRESPONDER: RESPONDERID=0;
7.5 Performance Monitoring

None
7.6 Parameter Optimization

None
7.7 Troubleshooting
7.7.1 Checking Alarms

If the local end serves as the Controller, an NE reports alarms listed in Table 7-8 when a
TWAMP negotiation fails.
After the TWAMP Controller function is enabled on the local end, the local end starts
negotiations with the TWAMP Responder. If the negotiations are unsuccessful for four
consecutive minutes, alarms listed in Table 7-8 are reported.
During normal measurements, the keep-alive period for TCP connections on the CP is 75s. If
the CP transmission is interrupted, the local end reinitiates negotiations when it receives no
response after sending 10 TCP keep-alive messages to the peer end. Because a TCP
disconnection may occur at any time (for example, t second) in the first keep-alive period, the
local end reinitiates negotiations at the time of 750 minus t second. If the negotiations are
unsuccessful for four consecutive minutes, alarms listed in Table 7-8 are reported.
During normal measurements, if all the tests of the Control-Client are interrupted on the UP
and the local end receives no test packet responses from the peer end for 15 consecutive

SingleRAN
minutes, the local end reinitiates negotiations. If negotiations are unsuccessful for four
consecutive minutes, alarms listed in Table 7-8 are reported.
Table 7-8 Fault alarms related to IP Active Performance Measurement
Working NE Alarm Name

Mode
GU BSC/RNC ALM-21354 IP Link Performance Measurement

Fault
GULT eGBTS/NodeB/ ALM-25904 IP Link Performance Measurement

eNodeB Fault
7.7.2 Using MML Commands

1. If the local end serves as the TWAMP Responder, run the DSP
TWAMPRESPONDERSTA command to check the negotiation statistics.
If the cause is transmission interruption, unavailable routing, incorrect configuration
of the peer IP address, the Responder cannot receive any TCP negotiation packets.
In this case, check Number of TCP Setup Request Packets Received.
If the local TCP resources, such as ports, are limited, any TCP connection
establishment attempts will be rejected. In this case, check Number of TCP
Rejection Packets Sent.
If the local end does not accept the mode of communication requested by the peer
end, the local end replies with a NAK message in response to the received Set-Up-
Response message. In this case, check Number of Set-up-response Rejection
Packets.
If the local UDP resources, such as ports, are limited, the local end replies with a
NAK message in response to the received Request-TW-Session message. In this
case, check Number of Request-TW-Session Rejection Packets Sent.
If the peer end stops the test, the local end receives a Stop-Session message. In this
case, check Number of Stop-Session Packets Received.
If the local end serves as the TWAMP Controller, run the DSP TWAMPCLIENT and
DSP TWAMPSENDER commands to check the negotiation status and the negotiation
failure cause, if any.
For a base station:
of the peer IP address, the Controller cannot establish TCP connections. In this
case, check whether Negotiation Failure Cause is TCP_LINK_DOWN.
If the peer TCP resources, such as ports, are limited, any TCP connection
establishment attempts will be rejected. In this case, check whether Negotiation
Failure Cause is Server internal error.
Response message. In this case, check whether Negotiation Failure Cause is
Server no support.

SingleRAN
If the peer UDP resources, such as ports, are limited, the peer end replies with a
case, check whether Negotiation Failure Cause is Server resource limitation.
For a base station controller:
of the peer IP address, the Controller cannot receive any negotiation packets. In this
case, check whether Status Change Cause is Connection expired.
If the peer TCP resources, such as ports, are limited, any TCP connection
establishment attempts will be rejected. In this case, check whether Status Change
Cause is Server internal error.
Response message. In this case, check whether Status Change Cause is Mode
unsupported.
If the peer UDP resources, such as ports, are limited, the peer end replies with a
case, check whether Status Change Cause is Temporary resource limitation.
2. Troubleshoot according to the related statistics on the TWAMP Responder end or the
negotiation failure causes on the TWAMP Controller end.
Step 1 Check the network connection if the peer end fails to respond in a specified time or does not
respond at all. If the network connection is normal, go to Step 2.
Step 2 Check whether the TWAMP functions are enabled on the peer end. If yes, go to Step 3.
Step 3 Check whether the negotiation failure cause is that resources on the peer end are limited. If
yes, re-enable the TWAMP functions.
Step 4 Check whether any transmission device prohibits the use of the ports required for the
TWAMP functions, as described in Table 7-4.
----End
7.7.3 Fault Locating Method

Step 1 Set Protocol Type to TCP and set Local IP Address, Peer IP Address, and the related port
numbers, as shown in Figure 7-1.
l If the local end serves as the TWAMP Controller, set Peer Port No to a value same as
the local port number specified on the TWAMP Responder. Local Port No does not need
to be specified.
l If the local end serves as the TWAMP Responder, set Local Port No to a value same as
the peer port number specified on the TWAMP Controller. Peer Port No does not need
to be specified.

SingleRAN
Figure 7-1 Setting Protocol Type, Local IP Address, Peer IP Address and port numbers
Step 2 Check the TCP packets sent between the local end and peer end. The messages are sent in the
following order: initial TCP-Connection, Server-Greeting, Set-Up-Response, Server-Start,
Request-TW-Session, Accept-Session, Start-Session, and Start-Ack. For details about the
packet format, see RFC 5357.
Step 3 Check whether the local end has transmitted the expected packets or has received the
expected packets from the peer end.
l If the local end has not received the expected packets from the peer end, check the
network connection.
l If the local end has not transmitted any expected packets, run the DSP
TWAMPCLIENT and DSP TWAMPSENDER commands to check the failure cause.
l If the failure cause is that resources on the peer end are limited, troubleshoot the peer end
and re-enable the TWAMP functions.
l Check whether any transmission device prohibits the use of the ports required for the
TWAMP functions, as described in Table 7-4.
----End

SingleRAN
Description 8 Parameters
8 Parameters
Table 8-1 Parameters

MO Parame MML Feature Feature Description
ter ID Comma ID Name
nd
TWAM SERVW ADD LOFD-0 IP Meaning: Indicates the negotiation wait time of a
PRESP AIT TWAM 70219 Active TWAMP responder. The SERVWAIT timer is started
ONDER PRESP TDLOF Perform to monitor the establishment status of a control
ONDER D-00301 ance connection between the server and the client. When
MOD 8 Measure this timer expires, the server releases the control
TWAM ment connection to the client.
PRESP WRFD- IP GUI Value Range: 10~1800
ONDER 151212 Active Unit: s
LST GBFD-1 Perform
ance Actual Value Range: 10~1800
TWAM 51202
PRESP Measure Default Value: 900
ONDER ment
NodeB
IP
Active
Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment

SingleRAN

nd
TWAM REFWA ADD LOFD-0 IP Meaning: Indicates the measurement wait time of a
PRESP IT TWAM 70219 Active TWAMP responder. The REFWAIT timer is started to
ONDER PRESP TDLOF Perform monitor the status of a test session between the server
ONDER D-00301 ance and the client. When this timer expires, the server
MOD 8 Measure releases the test session and returns to the link
TWAM ment establishment state.
PRESP WRFD- IP GUI Value Range: 10~1800
ONDER 151212 Active Unit: s
LST GBFD-1 Perform
ance Actual Value Range: 10~1800
TWAM 51202
PRESP Measure Default Value: 900
ONDER ment
NodeB
IP
Active
Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment

SingleRAN

nd
TWAM LOCAL ADD LOFD-0 IP Meaning: Indicates the local IP address of a TWAMP
PCLIEN IP TWAM 70219 Active client.
T PCLIEN TDLOF Perform GUI Value Range: Valid IP address
T D-00301 ance
Measure Unit: None
MOD 8
TWAM ment Actual Value Range: Valid IP address
PCLIEN WRFD- IP Default Value: None
T 151212 Active
DSP GBFD-1 Perform
TWAM 51202 ance
PCLIEN Measure
T ment
LST NodeB
TWAM IP
PCLIEN Active
T Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment

SingleRAN

nd
TWAM PEERIP ADD LOFD-0 IP Meaning: Indicates the peer IP address of a TWAMP
PCLIEN TWAM 70219 Active client.
T PCLIEN TDLOF Perform GUI Value Range: Valid IP address
T D-00301 ance
Measure Unit: None
MOD 8
PCLIEN WRFD- IP Default Value: None
T 151212 Active
DSP GBFD-1 Perform
TWAM 51202 ance
PCLIEN Measure
T ment
LST NodeB
TWAM IP
PCLIEN Active
T Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment
TWAM PEERP ADD None None Meaning: Indicates the peer TCP port number of a
PCLIEN ORT TWAM TWAMP client.
T PCLIEN GUI Value Range: 1~65535
T
Unit: None
MOD
TWAM Actual Value Range: 1~65535
PCLIEN Default Value: 862
T
DSP
TWAM
PCLIEN
T
LST
TWAM
PCLIEN
T

SingleRAN

nd
TWAM CLIENT ADD None None Meaning: Indicates the index of a TWAMP client.
PCLIEN ID TWAM GUI Value Range: 0~15
T PCLIEN
T Unit: None
DSP Actual Value Range: 0~15

TWAM Default Value: None
PCLIEN
T
LST
TWAM
PCLIEN
T
MOD
TWAM
PCLIEN
T
RMV
TWAM
PCLIEN
T
TWAM VRFIN ADD None None Meaning: Indicates the VRF index of a TWAMP
PCLIEN DEX TWAM client.
T
Unit: None
MOD
T
LST
TWAM
PCLIEN
T

SingleRAN

nd
TWAM DSCP ADD None None Meaning: Indicates the DSCP of TCP negotiation
PCLIEN TWAM packets sent by a TWAMP client.
T
Unit: None
MOD
T
DSP
TWAM
PCLIEN
T
LST
TWAM
PCLIEN
T
TWAM DSCP ADD LOFD-0 IP Meaning: Indicates the DSCP of UDP measurement
PSEND TWAM 70219 Active packets sent by a TWAMP sender.
ER PSEND TDLOF Perform GUI Value Range: 0~63
ER D-00301 ance
Measure Unit: None
MOD 8
TWAM ment Actual Value Range: 0~63
PSEND WRFD- IP Default Value: 0
ER 151212 Active
LST GBFD-1 Perform
TWAM 51202 ance
PSEND Measure
ER ment
NodeB
IP
Active
Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment

SingleRAN

nd
TWAM PKTSIZ ADD LOFD-0 IP Meaning: Indicates the size type of packets sent by a
PSEND ETYPE TWAM 70219 Active TWAMP sender.
ER PSEND TDLOF Perform GUI Value Range: FIXED(FIXED),
ER D-00301 ance RANDOM(RANDOM)
MOD 8 Measure
ment Unit: None
TWAM
PSEND WRFD- IP Actual Value Range: FIXED, RANDOM
ER 151212 Active Default Value: FIXED(FIXED)
LST GBFD-1 Perform
TWAM 51202 ance
PSEND Measure
ER ment
NodeB
IP
Active
Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment

SingleRAN

nd
TWAM PKTSIZ ADD LOFD-0 IP Meaning: Indicates the size of packets sent by a
PSEND E TWAM 70219 Active TWAMP sender, IP header is included.
ER D-00301 ance
Measure Unit: byte
MOD 8
ER 151212 Active
LST GBFD-1 Perform
TWAM 51202 ance
PSEND Measure
ER ment
NodeB
IP
Active
Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment

SingleRAN

nd
TWAM PKTINT ADD LOFD-0 IP Meaning: Indicates the type of the interval at which
PSEND TYPE TWAM 70219 Active packets are sent by a TWAMP sender.
ER PSEND TDLOF Perform GUI Value Range: FIXED(FIXED),
ER D-00301 ance RANDOM(RANDOM)
MOD 8 Measure
ment Unit: None
TWAM
PSEND WRFD- IP Actual Value Range: FIXED, RANDOM
ER 151212 Active Default Value: FIXED(FIXED)
LST GBFD-1 Perform
TWAM 51202 ance
PSEND Measure
ER ment
NodeB
IP
Active
Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment

SingleRAN

nd
TWAM PKTINT ADD LOFD-0 IP Meaning: Indicates the interval at which packets are
PSEND TWAM 70219 Active sent by a TWAMP sender.
ER D-00301 ance
Measure Unit: ms
MOD 8
ER 151212 Active
LST GBFD-1 Perform
TWAM 51202 ance
PSEND Measure
ER ment
NodeB
IP
Active
Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment

SingleRAN

nd
TWAM LOCAL ADD LOFD-0 IP Meaning: Indicates the local IP address of a TWAMP
PRESP IP TWAM 70219 Active responder.
ONDER PRESP TDLOF Perform GUI Value Range: Valid IP address
ONDER D-00301 ance
Measure Unit: None
MOD 8
PRESP WRFD- IP Default Value: None
ONDER 151212 Active
DSP GBFD-1 Perform
TWAM 51202 ance
PRESP Measure
ONDER ment
LST NodeB
TWAM IP
PRESP Active
ONDER Perform
ance
Measure
ment
BTS IP
Active
Perform
ance
Measure
ment
TWAM LOCAL ADD None None Meaning: Indicates the local TCP port number of a
PRESP PORT TWAM TWAMP responder.
ONDER PRESP GUI Value Range: 862,1024~65535
ONDER
Unit: None
MOD
TWAM Actual Value Range: 862,1024~65535
PRESP Default Value: 862
ONDER
DSP
TWAM
PRESP
ONDER
LST
TWAM
PRESP
ONDER

SingleRAN

nd
TWAM RESPO ADD None None Meaning: Indicates the index of a TWAMP responder.
PRESP NDERI TWAM GUI Value Range: 0~3
ONDER D PRESP
ONDER Unit: None
DSP Actual Value Range: 0~3

TWAM Default Value: None
PRESP
ONDER
DSP
TWAM
PRESP
ONDER
STA
LST
TWAM
PRESP
ONDER
MOD
TWAM
PRESP
ONDER
RMV
TWAM
PRESP
ONDER
TWAM VRFIN ADD None None Meaning: Indicates the VRF index of a TWAMP
PRESP DEX TWAM responder.
ONDER PRESP GUI Value Range: 0~7
ONDER
Unit: None
MOD
ONDER
LST
TWAM
PRESP
ONDER

SingleRAN

nd
TWAM DSCP ADD None None Meaning: Indicates the DSCP of TCP negotiation
PRESP TWAM packets sent by a TWAMP responder.
ONDER PRESP GUI Value Range: 0~63
ONDER
Unit: None
MOD
ONDER
DSP
TWAM
PRESP
ONDER
LST
TWAM
PRESP
ONDER

SingleRAN
Description 9 Counters
9 Counters
Table 9-1 Counters

Counter ID Counter Name Counter Feature ID Feature Name
Description
1542455996 VS.BSTWAMP.For Average forward Multi-mode: None BTS IP Active

ward.DropMeans packet loss rate on GSM: Performance
the BSTWAMP GBFD-151202 Measurement
UMTS: NodeB IP Active
WRFD-151212 Performance
Measurement
LTE:
LOFD-070219 IP Active
Performance
TDLOFD-003018 Measurement
IP Active
Performance
Measurement
1542455997 VS.BSTWAMP.For Peak forward Multi-mode: None BTS IP Active

ward.Peak.DropRat packet loss rate on GSM: Performance
es the BSTWAMP GBFD-151202 Measurement
Measurement
LTE:
Performance
IP Active
Performance
Measurement

SingleRAN

Description
1542455998 VS.BSTWAMP.Bac Average backward Multi-mode: None BTS IP Active

kward.DropMeans packet loss rate on GSM: Performance
Measurement
LTE:
Performance
IP Active
Performance
Measurement
1542455999 VS.BSTWAMP.Bac Peak backward Multi-mode: None BTS IP Active

kward.Peak.DropRa packet loss rate on GSM: Performance
tes the BSTWAMP GBFD-151202 Measurement
Measurement
LTE:
Performance
IP Active
Performance
Measurement
1542456000 VS.BSTWAMP.Mi Minimum RTT on Multi-mode: None BTS IP Active

nRttDelay the BSTWAMP GSM: Performance
GBFD-151202 Measurement
Measurement
LTE:
Performance
IP Active
Performance
Measurement

SingleRAN

Description
1542456001 VS.BSTWAMP.Rtt. Average RTT on the Multi-mode: None BTS IP Active

Means BSTWAMP GSM: Performance
Measurement
LTE:
Performance
IP Active
Performance
Measurement
1542456002 VS.BSTWAMP.Ma Maximum RTT on Multi-mode: None BTS IP Active

xRttDelay the BSTWAMP GSM: Performance
Measurement
LTE:
Performance
IP Active
Performance
Measurement
1542456003 VS.BSTWAMP.For Minimum forward Multi-mode: None BTS IP Active

ward.MinJitter jitter on the GSM: Performance
BSTWAMP GBFD-151202 Measurement
Measurement
LTE:
Performance
IP Active
Performance
Measurement

SingleRAN

Description
1542456004 VS.BSTWAMP.For Average forward Multi-mode: None BTS IP Active

ward.Jitter.Means jitter on the GSM: Performance
Measurement
LTE:
Performance
IP Active
Performance
Measurement
1542456005 VS.BSTWAMP.For Maximum forward Multi-mode: None BTS IP Active

ward.MaxJitter jitter on the GSM: Performance
Measurement
LTE:
Performance
IP Active
Performance
Measurement
1542456006 VS.BSTWAMP.Bac Minimum backward Multi-mode: None BTS IP Active

kward.MinJitter jitter on the GSM: Performance
Measurement
LTE:
Performance
IP Active
Performance
Measurement

SingleRAN

Description
1542456007 VS.BSTWAMP.Bac Average backward Multi-mode: None BTS IP Active

kward.Jitter.Means jitter on the GSM: Performance
Measurement
LTE:
Performance
IP Active
Performance
Measurement
1542456008 VS.BSTWAMP.Bac Maximum Multi-mode: None BTS IP Active

kward.MaxJitter backward jitter on GSM: Performance
Measurement
LTE:
Performance
IP Active
Performance
Measurement

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

SingleRAN
Description 11 Reference Documents
11 Reference Documents
None.


IP Active Performance Measurement (SRAN10.1 - 04)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

IP Active Performance Measurement (SRAN10.1 - 04)

Загружено:

Авторское право:

Доступные форматы

SingleRAN

IP Active Performance Measurement

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 04 (2015-12-30) Huawei Proprietary and Confidential i

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

Issue 04 (2015-12-30) Huawei Proprietary and Confidential ii

5.5 LOFD-070219/TDLOFD-003018 IP Active Performance Measurement....................................................................24

Issue 04 (2015-12-30) Huawei Proprietary and Confidential iii

1 About This Document

l GSM: GBFD-151201 BSC IP Active Performance Measurement

LTE LTE FDD LTE TDD

eNodeB LTE FDD eNodeB LTE TDD eNodeB

eRAN LTE FDD eRAN LTE TDD eRAN

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

Issue 04 (2015-12-30) Huawei Proprietary and Confidential 1

Table 1-1 Base station definitions

Base Station Definition

GBTS A base station configured with a GTMU, GTMUb, or GTMUc and

eGBTS A base station configured with a GTMUb, UMPT_G, or UMDU_G and

NodeB A base station configured with a WMPT, UMPT_U, or UMDU_U.

eNodeB A base station configured with an LMPT, UMPT_L, UMPT_T,

Co-MPT A base station configured with a UMPT_GU, UMDU_GU, UMPT_GL,

1.2 Intended Audience

l Need to understand the features described herein

1.3 Change History

Issue 04 (2015-12-30) Huawei Proprietary and Confidential 2

Change Change Description Parameter Change

Feature None None

Editorial Optimized descriptions in the following section: None

Change Change Description Parameter Change

Feature None None

Editorial Optimized descriptions in the following section: None

Change Change Description Parameter Change

Feature None None

Editorial Optimized descriptions in the following section: None

Issue 04 (2015-12-30) Huawei Proprietary and Confidential 3

SRAN10.1 Draft A (2015-01-15)

Change Change Description Parameter Change

Feature Added the descriptions of IP Active Added two new

Editorial None None

1.4 Differences Between Base Station Types

Issue 04 (2015-12-30) Huawei Proprietary and Confidential 4

Base Station Model RAT

BTS3202E LTE FDD

Feature Support by Macro, Micro, and LampSite Base Stations

GBFD-151201 BSC IP Active Performance Yes No No

GBFD-151202 BTS IP Active Performance Yes No No

WRFD-151211 RNC IP Active Performance Yes Yes Yes

WRFD-151212 NodeB IP Active Performance Yes Yes Yes

LOFD-070219 IP Performance Monitoring Yes Yes Yes

TDLOFD-003018 IP Performance Monitoring Yes No No

Function Implementation in Macro, Micro, and LampSite Base Stations

Active/standby Macro base stations support active/standby switchovers during IP

Issue 04 (2015-12-30) Huawei Proprietary and Confidential 5

Protocol Number Protocol Name

RFC5357 A Two-way Active Measurement Protocol (TWAMP)

RFC2680 A One-way Packet Loss Metric for IPPM

RFC2681 A Round-trip Delay Metric for IPPM

RFC3393 IP Packet Delay Variation Metric for IP Performance Metrics

Issue 04 (2015-12-30) Huawei Proprietary and Confidential 6

Protocol Number Protocol Name