Vdocuments - MX - Ip Active Performance Measurementsran90draft Apdf PDF

SingleRAN
IP Active Performance Measurement

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 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
2 Overview.........................................................................................................................................3
2.1 Description......................................................................................................................................................................4
2.2 Benefits...........................................................................................................................................................................4
3 Technical Description...................................................................................................................5
3.1 Position of TWAMP in the TCP/IP Protocol Stack.......................................................................................................5
3.2 Basic Concepts...............................................................................................................................................................6
3.2.1 Measurement Model....................................................................................................................................................6
3.2.2 Measurement Process..................................................................................................................................................7
3.3 TWAMP Measurement Parameters................................................................................................................................8
3.3.1 Packet Loss Rate..........................................................................................................................................................9
3.3.2 Round-Trip Delay......................................................................................................................................................10
3.3.3 Delay Variation..........................................................................................................................................................10
4 TWAMP Application..................................................................................................................11
4.1 Differences Between TWAMP and Huawei-Private IP PM.........................................................................................11
4.2 TWAMP Application on the Base Station Side...........................................................................................................13
4.2.1 TWAMP Controller Function Configuration............................................................................................................14
4.2.2 TWAMP Responder Function Configuration............................................................................................................15
4.2.3 Networking Scenarios................................................................................................................................................16
4.3 TWAMP Application on the Base Station Controller Side..........................................................................................16
4.3.1 TWAMP Controller Function Configuration............................................................................................................17
4.3.2 TWAMP Responder Function Configuration............................................................................................................17
4.3.3 Networking Scenarios................................................................................................................................................17
5 Related Features...........................................................................................................................19
5.1 eGBTS TWAMP..........................................................................................................................................................19
5.2 BSC TWAMP...............................................................................................................................................................19
5.3 NodeB TWAMP...........................................................................................................................................................20
5.4 RNC TWAMP..............................................................................................................................................................20
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential ii

SingleRAN
Description Contents
5.5 eNodeB TWAMP.........................................................................................................................................................21
6 Network Impact...........................................................................................................................22
6.1 System Capacity...........................................................................................................................................................22
6.2 Network Performance...................................................................................................................................................22
7 Engineering Guidelines.............................................................................................................23
7.1 When to Use IP Active Performance Measurement.....................................................................................................23
7.2 Required Information...................................................................................................................................................23
7.3 Planning........................................................................................................................................................................23
7.4 Feature Deployment.....................................................................................................................................................24
7.4.1 Requirements.............................................................................................................................................................24
7.4.2 Data Preparation........................................................................................................................................................25
7.4.3 Precautions.................................................................................................................................................................28
7.4.4 Activation..................................................................................................................................................................28
7.4.5 Activation Observation..............................................................................................................................................32
7.4.6 Hardware Adjustment................................................................................................................................................35
7.4.7 Deactivation...............................................................................................................................................................35
7.5 Performance Monitoring...............................................................................................................................................36
7.6 Parameter Optimization................................................................................................................................................36
7.7 Troubleshooting............................................................................................................................................................36
7.7.1 Checking Alarms.......................................................................................................................................................36
7.7.2 Using MML Commands............................................................................................................................................36
7.7.3 Capturing Packets......................................................................................................................................................38
8 Parameters.....................................................................................................................................40
9 Counters........................................................................................................................................66
10 Glossary.......................................................................................................................................76
11 Reference Documents...............................................................................................................77
Issue Draft A (2014-01-20) 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 GBTS/eGBTS, NodeB, eNodeB, separate-MPT multimode base
station, co-MPT multimode base station, and base station controller.
Table 1-1 defines different types of base stations.
Table 1-1 Definitions of different types of base stations
Base Station Type Description
GBTS Installed with the GTMU
Issue Draft A (2014-01-20) Huawei Proprietary and Confidential 1

SingleRAN
Description 1 About This Document
Base Station Type Description
eGBTS Installed with the UMPT_G
NodeB Installed with the WMPT or UMPT_U
eNodeB Installed with the LMPT, UMPT_L, or UMPT_T
Co-MPT multimode base Installed with the UMPT_GU, UMPT_GL, UMPT_GT,

station UMPT_UL, UMPT_UT, UMPT_LT, UMPT_GUL,
UMPT_GUT, UMPT_ULT, UMPT_GLT, or UMPT_GULT. A
co-MPT multimode base station can have the same functions as
any combination of the eGBTS, NodeB, and eNodeB. For
example, a co-MPT multimode base station has the same
functions as a combination of the eGBTS and NodeB when
installed with a UMPT_GU.
Separate-MPT Different modes of a separate-MPT multimode base station have

multimode base station different main control boards. For example, a base station
installed with the GTMU and WMPT is a separate-MPT GSM/
UMTS dual-mode base station.
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
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.

SingleRAN
Description 2 Overview
2 Overview
The Internet Engineering Task Force (IETF) IP Performance Metrics (IPPM) working group
has defined standards for performance metrics to support the configuration and maintenance of
IP networks. These performance metrics test the performance of end-to-end (E2E) Ethernet links
and improve the interoperability between transmission and test devices.
Huawei has developed the IP Active Performance Measurement feature in accordance with the
IETF IPPM standards listed in the following table.
Protocol Number 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 supports IP performance detection on connections between wireless network

elements (NEs) and devices that support TWAMP in a radio transport network. The performance
metrics include packet loss rate, round-trip delay, and delay variation. For details about these
performance metrics, see section 3.3 TWAMP Measurement Parameters.
IP performance detection 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 (SGW), between base station controllers, between a base station controller and a core
network (CN), between a wireless NE and a transmission device (for example, a router), and
between a wireless NE and a test device.
This document focuses on RFC5357: A Two-way Active Measurement Protocol (TWAMP).

SingleRAN
Description 2 Overview
2.1 Description
2.2 Benefits
The IP Active Performance Measurement feature reduces maintenance costs using the following
functions:
l Network performance monitoring

In scenarios in which the transmission rate is unstable and the transmission bandwidth
dynamically changes, this function can detect the quality of service (QoS) of the transport
network so that operators can quickly troubleshoot network problems and take measures,
such as capacity expansion and network optimization.
l Transmission fault diagnosis
– Quickly locates and isolates transmission faults, such as a high packet loss rate or a long
delay, using TWAMP.
– Troubleshoots a transport network on a per segment basis by measuring round-trip
network performance between a wireless NE and a transmission device (such as an
intermediate router that supports TWAMP), thereby improving network maintainability
and reducing maintenance costs.
TWAMP testing uses User Datagram Protocol (UDP) packet injection, which generates traffic
in the transport network and therefore occupies some bandwidth. 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.

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 segmentation and reassembly at the network layer, as shown in Figure
3-1.
In accordance with TWAMP, this feature measures the transmission quality at the IP layer. If
the local end (a wireless NE) serves as the Control End, it sends test packets before performing
IP segmentation. If the local end (a wireless NE) serves as the Response End, it performs IP
reassembly before responding to the received test packets.
NOTE
The Local TWAMP protocol version is RFC5357. It is recommended that the local and peer TWAMP
protocol versions be the same.

SingleRAN
3.2 Basic Concepts
3.2.1 Measurement Model

TWAMP defines the measurement model, as shown in Figure 3-2.
Figure 3-2 TWAMP measurement model
TWAMP architecture is composed of four logical roles: Session-Sender, Session-Reflector,

Control-Client, and Server.
TWAMP defines two protocol packet types: control packets and test packets.
The Control-Client and server are TWAMP-control hosts, responsible for exchanging control
packets to initiate, start, and stop TWAMP test sessions.
The Session-Sender and Session-Reflector are TWAMP-test hosts, responsible for exchanging
test packets for testing. The Session-Sender sends test packets to the Session-Reflector and the
Session-Reflector responds to the test packets.
In application, TWAMP merges different logical roles on the same host for easier
implementation. For example, as shown in Figure 3-3, there could actually be two hosts: one
(Controller) playing the roles of Control-Client and Session-Sender, and the other (Responder)
playing the roles of Server and Session-Reflector.
Figure 3-3 TWAMP measurement entities
The Controller actively sends 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 Transmission Control Protocol (TCP) packets. The Server uses
the fixed port port 862. Testing is conducted between the Session-Sender and Session-Reflector
based on the UDP. Ports used by the UDP are assigned and managed internally among NEs and
negotiated during the negotiation process, as shown in Figure 3-4.
Figure 3-4 TWAMP negotiation process
The measurement process includes four phases: TCP connection setup, creating test sessions,
starting test sessions, and testing, as outlined below:
Phase 1: TCP connection setup
1. The Control-Client opens a TCP connection to the Server on the fixed port 862 on the
Server.
2. The Server responds with a Server-Greeting message, indicating its supported mode of
communication.
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 test start time. 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 can send the following messages in response to the
commands it receives: 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 for
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 whether it accepts the
negotiated results. The Server can respond with a different UDP port number that it will
allow 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 to the test session with a Start-Ack message, indicating whether it
accepts the test session.
Phase 4: Testing
Testing is carried out using UDP packets. The Session-Sender actively inserts test packets for
the Session-Reflector's response. The inserted test packets are transmitted 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 are transmitted in unauthenticated mode, authenticated mode, or encrypted
mode.
l In unauthenticated mode, neither shared keys nor hashed message authentication code
(HMAC) keys are authenticated.
l In authenticated mode, the public key must be authenticated.
l In encrypted mode, negotiation packets and test packets must be encrypted.
Currently, this feature supports only unauthenticated mode.
3.3 TWAMP Measurement Parameters

TWAMP actively inserts test packets on links being tested and calculates the packet loss rate,
delay, and delay variation based on fields contained in the test packets.
Figure 3-5 describes the test process.
1. The Session-Sender sends test packets filled with sequence numbers and timestamp T1.
2. The Session-Reflector records timestamp T2 upon receiving the test packets from the
Session-Sender. The Session-Reflector copies the packet sequence numbers and timestamp
T1 extracted from the received packets into the corresponding reflected packets to the
Session-Sender. The corresponding reflected packets also include the Session-Reflector's
transmit sequence numbers and timestamp T3.
3. The Session-Sender records timestamp T4 upon receiving response packets from the
Session-Reflector and then calculates the number of received packets.

SingleRAN
Figure 3-5 TWAMP test process
This feature enables the Session-Sender to send packets periodically at an interval of 10 ms to

1000 ms and randomly within a period ranging from 10 ms to 1000 ms. All these can be set in
the TWAMPSENDER managed object (MO).
NOTE
This feature enables test packets to be sent based on quintuples consisting of the source IP address,
destination IP address, DSCP, source UDP port number, and destination UDP port number.
TWAMP requires the Session-Reflector to send a response packet to the Session-Sender in response to
each test packet it receives as soon as possible.
TWAMP defines negotiation timeout and test timeout for the Responder, which can be set in the
SERVWAIT(BSC6900,BSC6910,NodeB) and REFWAIT(BSC6900,BSC6910,NodeB) parameters,
respectively.
l ServWait: The Server closes the connection during negotiations if it has not received any negotiation
packet within the period specified by the SERVWAIT(BSC6900,BSC6910,NodeB) parameter. The
SERVWAIT(BSC6900,BSC6910,NodeB) parameter is configurable and its default value is 900s.
l REFWAIT(BSC6900,BSC6910,NodeB) parameter. The REFWAIT(BSC6900,BSC6910,NodeB)
parameter is configurable and its default value is 900s. When a base station or base station controller
serves as the Controller, it reinitiates negotiations if it has not received any test packets from its peer
end within 900s during the test. This is because the base station or base station 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 detected IP link. This feature divides
the number of lost packets by the number of transmitted packets to obtain the packet loss rate
in a measurement period. The number of lost packets is calculated based on the numbers of
packets transmitted and received by the Session-Sender and those transmitted by the Session-
Reflector.
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

SingleRAN
3.3.2 Round-Trip Delay

The round-trip delay is delay of packets transmitted back and forth between the Session-Sender
and Session-Reflector. The round-trip delay indicates the delay in a transport network.
This feature uses the following formula to calculate the round-trip delay:
Round-trip delay = (T2 - T1) + (T4 - T3) = (T4 - T1) - (T3 - T2)
where,
T1: time when the Session-Sender transmits packets
T2: time when the Session-Reflector receives packets
T3: time when the Session-Reflector responds with packets
T4: time when the Session-Sender receives response packets
3.3.3 Delay Variation

The packet delay variation indicates the difference between packet delays on a detected IP link.
The greater the fluctuations in delays, the greater the delay variation.
This feature calculates the packet delay variation based on the delays of two adjacent packets.
Forward delay variation: Difference between the forward delays of two adjacent test packets
Backward delay variation: 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.
The IP Active Performance Measurement feature supports active/standby board switchovers. If the local
end serves as the TWAMP Controller and experiences an active/standby board switchover, the local end
reinitiates a TWAMP negotiation and starts a test after the negotiation is successful. If the local end serves
as the TWAMP Responder and experiences an active/standby board switchover, the ongoing TWAMP test
will be affected and the local end will not respond to any tests.

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 and X2
The implementation principles for interfaces of different modes are the same. For details about
the implementation principles, see chapter 3 "Technical Description.".
For details about the base station and base station controller's TWAMP-related activation
commands and configuration parameters as well as test parameters that support TWAMP, see
sections 4.2 TWAMP Application on the Base Station Side and 4.3 TWAMP Application
on the Base Station Controller Side, respectively.
NOTE
TWAMP application to the co-MPT multimode base station is not discussed in this document because it
is the same as TWAMP application to the eGBTS, NodeB, and eNodeB.
TWAMP and Huawei-private IP performance monitoring (IP PM) have their own advantages
and disadvantages. The following paragraphs explain their differences from the technical and
application perspectives.
The Technical Perspective

TWAMP is a set of standards defined by the IETF and Huawei-private IP PM is a protocol
developed by Huawei. Table 4-1 explains their technical differences.

SingleRAN
Table 4-1 Technical differences between TWAMP and Huawei-private IP PM
Item Huawei-Private IP PM TWAMP
Inter The peer end must be a Huawei The peer end can be any device supporting
conn device. TWAMP.
ectio
n
Test Transmission QoS of online Service packets are simulated. Offline tests on
services is detected. transmission links are recommended.
Restr Depends on online services. No l Packet injection affects ongoing services

iction test can be conducted when no and occupies some bandwidth.
services are running. l The peer device must support TWAMP.
Huawei-private IP PM is used to monitor the QoS of transmission links for online services on
the user plane (UP).
TWAMP employs active testing by inserting test packets to test the QoS of E2E transmission
links. The test does not rely on service packets. Huawei-private IP PM tests E2E connections
between the base station and base station controller, while TWAMP tests the connections
between the base station and base station controller, or those between the base station/base station
controller and transmission devices in the transport network.
NOTE
Huawei-private IP PM measurement is based on four-tuples (source IP address, destination IP address,

UDP, and DSCP) or three-tuples (source IP address, destination IP address, and UDP). TWAMP
measurement is based on quintuples (source IP address, destination IP address, source UDP port number,
destination UDP port number, and DSCP).
The Application Perspective

TWAMP and Huawei-private IP PM are complementary. When there are ongoing services,
Huawei-private IP PM is recommended for testing connections between the base station and
base station controller, and between the eNodeB and Huawei SGW, and TWAMP is
recommended for testing connections between the base station/base station controller and
transmission devices in the transport network.
TWAMP actively simulates service packets to measure the following:
l Transmission counters when a base station fails to provide services but the connection
between the base station and transport network is in good condition
l Transmission counters when there is no traffic or the traffic is light
l Connections between devices that support TWAMP

SingleRAN
Table 4-2 Application differences between TWAMP and Huawei-private IP PM
Item Scenario Huawei- TWAMP

Private IP
PM
Maintenanc Tests on transmission counters with no -- √

e and testing ongoing service
Tests on Iub/Abis connections between Huawei-private IP PM is

the base station and base station recommended.
controller
Tests on connections between a RAN -- √

device and an intermediate transmission
device
QoS tests on S1/X2 connections between Huawei-private IP PM is

an eNodeB and a Huawei SGW/eNodeB recommended.
QoS tests on S1/X2 connections between -- √

an eNodeB and a non-Huawei SGW/
eNodeB
Monitoring Online monitoring of wireless services √ --

on the Iub/Abis/S1/X2 interface
QoS monitoring of transmission between -- √

a base station/base station controller and
a router or a non-Huawei SGW
4.2 TWAMP Application on the Base Station Side

This section describes IP Active Performance Measurement 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 base station's functions differ depending on the
connected peer device.
Table 4-3 Base station's functions with TWAMP
Peer Device Base Station's Function
Transmission The base station is configured as the TWAMP Controller because the
device transmission device generally supports the TWAMP Responder
function.

SingleRAN
Peer Device Base Station's Function
SGW When the base station is connected to a non-Huawei SGW, it is

recommended that the SGW and eNodeB be configured as the TWAMP
Responder and TWAMP Controller, respectively.
Base station Huawei IP PM is preferred.

controller When there is no service and TWAMP is used for testing, it is
recommended that the base station controller and base station be
configured as the TWAMP Controller and TWAMP Responder,
respectively.
Test device Test devices, such as Sprient TestCenter, support TWAMP. It is

recommended that the test device and base station be configured as the
TWAMP Responder and TWAMP Controller, respectively.
4.2.1 TWAMP Controller Function Configuration

The eGBTS/NodeB/eNodeB supports the TWAMP Controller function. The TWAMP
Controller is responsible for actively initiating tests, collecting statistics, and displaying test
results on the local end. The Responder function must be enabled on the peer end, such as a
router, base station controller, or eNodeB, to transmit and receive the negotiation and test
packets.
You can run the ADD TWAMPCLIENT and ADD TWAMPSENDER commands to activate
a test. Table 4-4 and Table 4-5 provides the related key parameters.
Table 4-4 Related key parameters for the TWAMP Control-Client on the base station side
Parameter ID Setting Notes
LocalIP Local IP address for TWAMP tests. The local end, as the Controller,
actively transmits packets.
PeerIP Peer IP address for TWAMP tests. The peer end, as the Responder,
passively responds to received negotiation packets and test packets.
DSCP DSCP of TCP negotiation packets sent by the TWAMP Responder. The
greater the DSCP value, the higher priority of the negotiation packets. Both
the default and recommended values are 46.
Table 4-5 Related key parameters for the TWAMP Session-Sender on the base station side
DSCP Priority of the test IP packets on the tested transmission link. It is

recommended that you set this parameter to the DSCP value of the services
for which the user shows concern.

SingleRAN
PktSizeType Size type of a test packet. The value is either random or fixed.
PktSize Length of a test packet. The value ranges from 69 to 1500.
PktIntType Type of the test packet transmit interval. The value is either random or fixed.
PktInt Transmit interval of a test packet. The value ranges from 10 ms to 1000 ms.
NOTE
A base station supports 16 Control-Clients, with each Control-Client supporting a maximum of 16 Session-
Sender test streams. A base station supports 16 Session-Sender test streams in total.
4.2.2 TWAMP Responder Function Configuration

The eGBTS/NodeB/eNodeB supports the TWAMP Responder function. The Responder
passively responds to test packets. The TWAMP Controller function must be enabled on the
peer end, such as a base station controller, eNodeB, or test device, so that the peer end actively
initiates tests and the local end passively responds to the tests.
Run the ADD TWAMPRESPONDER command to enable the TWAMP Responder function.
Table 4-6 provides the related key parameters.
Table 4-6 Related key parameters for the TWAMP Responder on the base station side
LocalIP Local IP address for TWAMP tests. The local end serves as the Responder.
(NodeB,
BSC6900,
BSC6910)
VRFINDEX VRF index of the TWAMP Responder.
DSCP DSCP of TCP negotiation packets sent by the TWAMP Responder.
SERVWAIT Negotiation timeout. During negotiations, the Server closes the connection
(NodeB, if it has not received any negotiation packets within the period specified by
BSC6910, the SERVWAIT parameter.
BSC6900)
REFWAIT Test timeout. During tests, the Session-Reflector releases resources if it has
(BSC6900, not received any test packets within the period specified by the REFWAIT
BSC6910, (BSC6900,BSC6910,NodeB) parameter.
NodeB)
NOTE
A base station supports four Responders, with each Responder supporting a maximum of 16 passive
response test streams. A base station supports 16 passive response test streams in total.

SingleRAN
4.2.3 Networking Scenarios

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

Not
Supported
Port level FE/GE ports as the transmission Supported -

ports connecting to the transport
network
E1/T1 ports as the transmission Supported The WMPT and

ports connecting to the transport UMPT support E1/
network T1 ports.
Link level Active and standby routing devices Supported -
Board level UTRPc as the transmission Supported TWAMP is

interface board in a multimode base recommended for
station the UTRPc in this
scenario.
Site level Cascaded base stations Supported TWAMP can be

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

This section describes IP Active Performance Measurement 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 base station controller's functions
differ depending on the connected peer device.
Table 4-8 Base station controller's functions with TWAMP
Peer Device Base Station Controller's Function
Transmission The base station controller is configured as the TWAMP Controller because
device the transmission device generally supports the TWAMP Responder
function.

SingleRAN
Peer Device Base Station Controller's Function
Base station Huawei IP PM is preferred when the base station is provided by Huawei.
When a non-Huawei base station is used for TWAMP testing or 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 Configuration

The BSC/RNC supports the TWAMP Controller function. The TWAMP Controller is
responsible for actively initiating tests, collecting statistics, and displaying test results on the
local end. The TWAMP Responder function must be enabled on the peer end, such as a router,
base station controller, base station, or SGW, to transmit and receive negotiation and test packets.
The MML commands and parameters configured for the TWAMP Controller function are the
same on the base station controller side and on the base station side. For details, see section
4.2.1 TWAMP Controller Function Configuration.
NOTE
A base station controller supports 1024 Control-Clients, with each Control-Client supporting a maximum
of 16 Session-Sender test streams. A base station controller supports 1024 Session-Sender test streams in
total.
4.3.2 TWAMP Responder Function Configuration

The BSC/RNC supports the TWAMP Responder function. The TWAMP Responder passively
responds to test packets. The TWAMP Controller function must be enabled on the peer end,
such as a base station controller, base station, test device, or SGW, so that the peer end actively
initiates tests and the local end passively responds to the tests.
The MML command and parameters configured for the TWAMP Responder function are similar
on the base station controller side and on the base station side. For details, see section 4.2.2
TWAMP Responder Function Configuration.
NOTE
A base station controller supports 1024 Responders, with each Responder supporting a maximum of 160
passive response test streams. A base station controller supports 1024 passive response test streams in total.
4.3.3 Networking Scenarios

Table 4-9 provides the networking scenarios in which a base station controller supports
TWAMP.

SingleRAN
Table 4-9 Networking scenarios in which a base station controller supports TWAMP
Networking Scenario Supported/ Description

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

ports connecting to the transport GOUc/GOUe/
network GOUd/EXOUa
supports TWAMP.
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 mode Supported -
Routing devices working in load Supported -

sharing mode
Active and standby routing devices Supported -
Board Active and standby boards Supported -

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

SingleRAN
Description 5 Related Features
5 Related Features
5.1 eGBTS TWAMP

Prerequisite Features
This feature is dependent on the GBFD-118601 Abis over IP feature.
Mutually Exclusive Features

None
Impacted Features
If the UDP loopback function is enabled on the base station side, UDP loopback cannot work
with TWAMP simultaneously to perform loopback tests on specified IP addresses or all IP
addresses.
The UDP loopback function affects TWAMP testing. If one TWAMP test end is enabled with
the UDP loopback function and specified IP addresses or all IP addresses use the same IP address
that is used for TWAMP testing, the test packets will be directly looped back, resulting in
inaccurate statistics. If the base station functions as the TWAMP Controller, the peer Responder's
response packets will be looped back. As a result, the UDP packets are retransmitted between
the local end and peer end (Responder), which increases network resource consumption.
5.2 BSC TWAMP

This feature is dependent on the GBFD-118601 Abis over IP, GBFD-118602 A over IP, and
GBFD-118603 Gb over IP features when it is applied to the BSC6900 on the Abis, A, and Gb
interfaces, respectively.
This feature is dependent on the GBFD-150201 A over IP Based on Dynamic Load Balancing
feature when it is applied to the BSC6910 on the Abis interface.

SingleRAN

None
Impacted Features
None
5.3 NodeB TWAMP

This feature is dependent on the WRFD-050402 IP Transmission Introduction on Iub Interface
feature.

None
Impacted Features
addresses. The UDP loopback function affects TWAMP testing. If one TWAMP test end is
enabled with the loopback function and an IP address being looped back is the IP address used
for TWAMP testing, the test packets will be directly looped back, resulting in inaccurate
statistics. If the base station functions as the TWAMP Controller, the peer Responder's response
packets will be looped back. As a result, the UDP packets are retransmitted between the local
end and peer end (Responder), which increases network resource consumption.
TWAMP affects IP performance monitoring when applied with the WRFD-050402 IP
Transmission Introduction on Iub Interface and WRFD-150243 Iub IP Transmission Based on
Dynamic Load Balancing features. When a WMPT is configured on a base station and TWAMP
and 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 RNC TWAMP

In non-IP pool networking, this feature is dependent on the WRFD-050402 IP Transmission
Introduction on Iub Interface, WRFD-050409 IP Transmission Introduction on Iu Interface, and
WRFD-050410 IP Transmission Introduction on Iur Interface features when it is applied on the
Iub, Iu, and Iur interfaces, respectively.
In IP pool networking, this feature is dependent on the WRFD-140207 Iu/Iur Transmission
Resource Pool of RNC and WRFD-140208 Iub Transmission Resource Pool of RNC features
(applied to the BSC6900) and the WRFD-150243 Iub IP Transmission Based on Dynamic Load
Balancing and WRFD-150244 Iu/Iur IP Transmission Based on Dynamic Load Balancing
features (applied to the BSC6910).

SingleRAN

None
Impacted Features
None
5.5 eNodeB TWAMP


None
Impacted Features
addresses.
The UDP loopback function affects TWAMP testing. If one TWAMP test end is enabled with
the loopback function and an IP address being looped back is the IP address used for TWAMP
testing, the test packets will be directly looped back, resulting in inaccurate statistics. If the base
station functions as the TWAMP Controller, the peer Responder's response packets will be
looped back. As a result, the UDP packets are retransmitted between the local end and peer end
(Responder), which increases network resource consumption.

SingleRAN
Description 6 Network Impact
6 Network Impact
6.1 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 user plane (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.
6.2 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 packet 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 the TWAMP test so
that involved 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 160 per GOUc/GOUe/FG2c/EXOUa/GOUd/

FG2d
1024 per BSC/RNC
eGBTS/NodeB/eNodeB 16
7.2 Required Information

Obtain the bandwidth usage of the transport network.
7.3 Planning
RF Planning
None

SingleRAN
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/UTRPc
to support TWAMP.
License
l Licenses for the features listed in the following table must be purchased and activated.
Feature ID Feature Name License Control NE Sales

Item Unit
GBFD-151201 BSC IP Active BSC IP Active BSC Per TRX

Performance Performance
Measurement Measurement
GBFD-151202 BTS IP Active BTS IP Active BTS Per BTS

Performance Performance
WRFD-151211 RNC IP Active RNC IP Active RNC Per

Performance Performance Erl&Mbp
Measurement Measurement s
WRFD-151212 NodeB IP Active NodeB IP Active NodeB Per

Performance Performance NodeB
LOFD-070219 IP Active IP Active eNodeB Per

Performance Performance eNodeB
TDLOFD-003 IP Active IP Active eNodeB Per

018 Performance Performance eNodeB

SingleRAN
Other
l The peer end must support TWAMP if the local end is interconnected with the other device.
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 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-2 and Table 7-3.
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 (BSC6900,
BSC6910,
NodeB)
Peer IP Address PeerIP - Network plan

(BSC6900,
BSC6910,
NodeB)
Client Index ClientID - Network plan

(BSC6900,
BSC6910,
NodeB)
VRF Index VRFINDEX - Network plan

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

services code (BSC6900, is 46.
point BSC6910,
NodeB)

SingleRAN
MO Parameter Parameter ID Setting Notes Data Source

Name
TWAMPSEND Differentiated DSCP It is Network plan

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

Type (BSC6900, Fixed is
BSC6910, recommended.
NodeB)
Packet Size PktSize The default value Internal plan

(BSC6900, is 128 bytes.
BSC6910,
NodeB)
Packet Send PktIntType The default value Internal plan

Interval Type (BSC6900, is Fixed.
BSC6910,
NodeB)
Packet Interval PktInt - Internal plan

(BSC6900,
BSC6910,
NodeB)
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(BSC6900,BSC6910,NodeB) and PktInt
(BSC6900,BSC6910,NodeB) 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(BSC6900,BSC6910,NodeB) and PktInt(BSC6900,BSC6910,NodeB)
parameters are set to their default values 128 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
(BSC6900,BSC6910,NodeB) parameter to increase the packet transmit rate for a higher accuracy if
there is sufficient network bandwidth.

SingleRAN
Table 7-3 Data preparation for the TWAMP Responder function
MO Parameter Name Parameter ID Setting Notes Data Source
TWAMPR Local IP Address LocalIP - Network plan

ESPONDE (BSC6900,
R BSC6910,
NodeB)
Responder Index ResponderID - Network plan

(BSC6900,
BSC6910,
NodeB)
VRF Index (only VRFINDEX -

for base stations)
Differentiated DSCP The default Internal plan

services code point (BSC6900, value is 46.
BSC6910,
NodeB)
Negotiation Wait SERVWAIT The default Internal plan

Time (NodeB, value defined by
BSC6910, the protocol
BSC6900) 900s is
recommended.
Measurement Wait REFWAIT The default Internal plan

Time (BSC6900, value defined by
BSC6910, the protocol
NodeB) 900s is
recommended.
Table 7-4 TWAMP communication matrix requirements on base stations and base station
controllers
NE Transmit/ Functio TCP UDP

Receive n
Source Port Destinati Source Destinatio
on Port Port n Port
Base Transmit Controll 1024-65535 862 64695-64 *

Statio er 710
n
Respon 862 * 64679-64 *
der 695
Receive Controll 862 1024-65 * 64695-64

er 535 710
Respon * 862 * 64679-64

der 694

SingleRAN
Base Transmit Controll 5201-6225 862 64968-64 *

station er 983
contro
ller Respon 862 * 64984-64 *
der 999
Receive Controll 862 5201-62 * 64968-64

er 25 983
Respon * 862 * 64984-64

der 999
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.3 Precautions
None
7.4.4 Activation
This section describes how to activate the TWAMP functions using MML commands and the
CME.
Using MML Commands

NOTE
l When MML commands are used, the commands are the same for the base station and base station
controller.
l Table 4-3 and Table 4-4 provide the related key parameters for the TWAMP Responder on the base
station side and base station controller side, respectively.
To activate the TWAMP Controller function on the local end, perform the following steps:
Step 1 Run the ADD TWAMPCLIENT and ADD TWAMPSENDER commands to activate the
TWAMP Controller function.
Step 2 (Optional) If required, run the MOD TWAMPCLIENT and MOD TWAMPSENDER
commands to modify the TWAMPCLIENT and TWAMPSENDER MOs, respectively.
----End
To activate the TWAMP Responder function, perform the following steps:
Step 1 Run the ADD TWAMPRESPONDER command to activate the TWAMP Responder function.

SingleRAN
Step 2 (Optional) Run the MOD TWAMPRESPONDER command to modify the

TWAMPRESPONDER MO if required.
----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

//Configuring the TWAMP Control-Client:
ADD TWAMPCLIENT: CLIENTID=0, LOCALIP="192.168.11.110", PEERIP="192.168.22.220";
//Configuring the TWAMP Session-Sender:

ADD TWAMPSENDER: ClientID=0, SenderID=0, PktSizeType=FIXED, PktIntType=FIXED;
//Configuring the TWAMP Responder:

ADD TWAMPRESPONDER: RESPONDERID=0, LOCALIP="192.168.11.110";
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-5 and Table 7-6. For detailed instructions, see Single
Configuration Operation Guide
----End
Table 7-5 Parameters related to the TWAMP Controller function
MO NE Parameter Name Parameter ID
TWAMPCLIEN Base station Client Index ClientID

T controller/base (BSC6900,BSC6910
station ,NodeB)
Local IP Address LocalIP

(BSC6900,BSC6910
,NodeB)
Peer IP Address PeerIP

(BSC6900,BSC6910
,NodeB)
VRF Index (only for base VRFINDEX

stations)

SingleRAN
Differentiated services code DSCP

point (BSC6900,BSC6910
,NodeB)
TWAMPSENDE Client Index CLIENTID

R (BSC6900,BSC6910
,NodeB)
Sender Index SENDERID

(BSC6900,BSC6910
,NodeB)
Differentiated services code DSCP

point (BSC6900,BSC6910
,NodeB)
Packet Size Type PktSizeType

(BSC6900,BSC6910
,NodeB)
Packet Size PktSize

(BSC6900,BSC6910
,NodeB)
Packet Send Interval Type PktIntType

(BSC6900,BSC6910
,NodeB)
Packet Send Interval PktInt

(BSC6900,BSC6910
,NodeB)
Table 7-6 Parameters related to the TWAMP Responder function
TWAMPRESPON Base station Responder Index ResponderID

DER controller/base (BSC6900,BSC6910
station ,NodeB)
Local IP Address LocalIP

(BSC6900,BSC6910
,NodeB)
VRF Index (only for VRFINDEX

base stations)
Differentiated DSCP
services code point (BSC6900,BSC6910
,NodeB)

SingleRAN
Negotiation Wait ServWait

Time (BSC6900,BSC6910
)
SERVTIME
Measurement Wait RefWait

Time (BSC6900,BSC6910
)
REFTIME
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.
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.
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.

SingleRAN
Step 3 In the summary data file, set the parameters in the MOs listed in Table 7-7 and close the file.
Table 7-7 TWAMP summary data file

MO Sheet in the Parameter Group
Summary Data
File
TWAMPCLIENT Transport Data Client ID/Local IP/Peer IP/Vrf Index
TWAMPSENDER Transport Data Client ID/Sender ID/DSCP/Packet Size

Type/Packet Size/Packet Interval Type/
Packet Interval
TWAMPRESPONDER Transport Data Responder ID/Local IP/Vrf Index
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
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.

SingleRAN
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 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
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-8 and Table 7-9 provide TWAMP performance counters on the
base station controller side and base station side, respectively.
Table 7-8 TWAMP performance counters on the base station controller side
Counter ID Counter Name Counter Description
73443310 VS.TWAMP.Forward.DropRates.Mean Average Forward Packet Loss

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

for TWAMP Measurement
73443305 VS.TWAMP.Backward.DropRates.Mea Average Backward Packet Loss

n Rates for TWAMP
Measurement
73443306 VS.TWAMP.Backward.DropRates.Max Peak Backward Packet Loss

Rates for TWAMP
Measurement

SingleRAN
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

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

73426986 VS.TWAMP.Forward.Jitter.Max Maximum Forward Delay Jitters

73426989 VS.TWAMP.Backward.Jitter.Min Minimum Backward Delay

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

73426990 VS.TWAMP.Backward.Jitter.Max Maximum Backward Delay

Jitters for TWAMP
Measurement
Table 7-9 TWAMP performance counters on the base station side
1542455996 VS.BSTWAMP.Forward.DropRates.Me Average forward packet loss rate

an on the BSTWAMP
1542455997 VS.BSTWAMP.Forward.DropRates.Ma Peak forward packet loss rate on

x the BSTWAMP
1542455998 VS.BSTWAMP.Backward.DropRates. Average backward packet loss

Mean rate on the BSTWAMP
1542455999 VS.BSTWAMP.Backward.DropRates. Peak backward packet loss rate

Max on the BSTWAMP
1542456000 VS.BSTWAMP.RttDelay.Min Minimum RTT on the

BSTWAMP
1542456001 VS.BSTWAMP.RttDelay.Mean Average RTT on the

BSTWAMP

SingleRAN
1542456002 VS.BSTWAMP.RttDelay.Max Maximum RTT on the

BSTWAMP
1542456003 VS.BSTWAMP.Forward.Jitter.Min Minimum forward jitter on the

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

BSTWAMP
1542456005 VS.BSTWAMP.Forward.Jitter.Max Maximum forward jitter on the

BSTWAMP
1542456006 VS.BSTWAMP.Backward.Jitter.Min Minimum backward jitter on the

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

BSTWAMP
1542456008 VS.BSTWAMP.Backward.Jitter.Max 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.
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

SingleRAN
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-10 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-10 are reported.
During normal measurements, if the CP transmission is not restored in 11 minutes after being
interrupted, the local end reinitiates negotiations. Again, if the negotiations are unsuccessful for
four consecutive minutes, alarms listed in Table 7-10 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 minutes,
the local end reinitiates negotiations. In this case, if negotiations are unsuccessful for four
consecutive minutes, alarms listed in Table 7-10 are reported.
Table 7-10 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.

SingleRAN
l 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.
l 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.
l 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.
l 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.
l 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:
the peer IP address, the Controller cannot establish TCP connections. In this case, check
whether Negotiation Failure Cause is TCP_LINK_DOWN.
l 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.
message. In this case, check whether Negotiation Failure Cause is Server no
support.
l If the peer UDP resources, such as ports, are limited, the peer end replies with a NAK
whether Negotiation Failure Cause is Server resource limitation.
For a base station controller:
the peer IP address, the Controller cannot receive any negotiation packets. In this case,
check whether Status Change Cause is Connection expired.
l 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.
message. In this case, check whether Status Change Cause is Mode unsupported.
l If the peer UDP resources, such as ports, are limited, the peer end replies with a NAK
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.

SingleRAN
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 Capturing Packets

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 both Local Port No and Peer Port
No to 862. The local port number can be queried by running the DSP TWAMPCLIENT
command.
l If the local end serves as the TWAMP Responder, set Local Port No to 862.
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.

SingleRAN
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 Parameter description
Parameter ID NE MML Feature ID Feature Name Description

Command
ServWait BSC6900 ADD None None Meaning:This

TWAMPRESP parameter
ONDER specifies the
MOD period within
TWAMPRESP which the server
ONDER waits for the
negotiation
packets sent by
the peer end. If
the server does
not receive any
negotiation
packets within
the period
specified by this
parameter, the
negotiation
ends.
GUI Value
Range:10~1800
Unit:s
Actual Value
Range:10~1800
Default Value:
900

SingleRAN

Command
ServWait BSC6910 ADD None None Meaning:This

TWAMPRESP parameter
ONDER specifies the
MOD period within
ONDER waits for the
negotiation
packets sent by
the peer end. If
the server does
not receive any
negotiation
packets within
the period
specified by this
parameter, the
negotiation
ends.
GUI Value
Range:10~1800
Unit:s
Actual Value
Range:10~1800
Default Value:
900

SingleRAN

Command
SERVWAIT BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPRESP TDLOFD-0030 Performance cates the
WCDMA, ONDER 18 Measurement negotiation wait
BTS3900 LTE MOD (FDD) time of a
TWAMPRESP IP Active TWAMP
ONDER Performance responder. The
Measurement SERVWAIT
LST timer is started
TWAMPRESP (TDD)
to monitor the
ONDER establishment
status of a
control
connection
between the
server and the
client. When this
timer expires,
the server
releases the
control
connection to
the client.
GUI Value
Range:10~1800
Unit:s
Actual Value
Range:10~1800
Default Value:
900

SingleRAN

Command
RefWait BSC6900 ADD None None Meaning:This

TWAMPRESP parameter
ONDER specifies the
MOD period within
ONDER waits for the test
packets sent by
the peer end. If
the server does
not receive any
test packets
within the
period specified
by this
parameter, the
test ends.
GUI Value
Range:10~1800
Unit:s
Actual Value
Range:10~1800
Default Value:
900

SingleRAN

Command
RefWait BSC6910 ADD None None Meaning:This

TWAMPRESP parameter
ONDER specifies the
MOD period within
ONDER waits for the test
packets sent by
the peer end. If
the server does
not receive any
test packets
within the
period specified
by this
parameter, the
test ends.
GUI Value
Range:10~1800
Unit:s
Actual Value
Range:10~1800
Default Value:
900

SingleRAN

Command
REFWAIT BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPRESP TDLOFD-0030 Performance cates the
WCDMA, ONDER 18 Measurement measurement
BTS3900 LTE MOD (FDD) wait time of a
TWAMPRESP IP Active TWAMP
ONDER Performance responder. The
Measurement REFWAIT
LST timer is started
TWAMPRESP (TDD)
to monitor the
ONDER status of a test
session between
the server and
the client. When
this timer
expires, the
server releases
the test session
and returns to
the link
establishment
state.
GUI Value
Range:10~1800
Unit:s
Actual Value
Range:10~1800
Default Value:
900
LOCALIP BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPCLIE TDLOFD-0030 Performance cates the local IP
WCDMA, NT 18 Measurement address of a
BTS3900 LTE MOD (FDD) TWAMP client.
TWAMPCLIE IP Active GUI Value
NT Performance Range:Valid IP
DSP Measurement address
TWAMPCLIE (TDD) Unit:None
NT Actual Value
LST Range:Valid IP
TWAMPCLIE address
NT Default
Value:None

SingleRAN

Command
PEERIP BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPCLIE TDLOFD-0030 Performance cates the peer IP
WCDMA, NT 18 Measurement address of a
BTS3900 LTE MOD (FDD) TWAMP client.
TWAMPCLIE IP Active GUI Value
NT Performance Range:Valid IP
DSP Measurement address
TWAMPCLIE (TDD) Unit:None
NT Actual Value
LST Range:Valid IP
TWAMPCLIE address
NT Default
Value:None
DSCP BTS3900, ADD None None Meaning:Indi-

BTS3900 TWAMPCLIE cates the DSCP
WCDMA, NT of TCP
BTS3900 LTE MOD negotiation
TWAMPCLIE packets sent by a
NT TWAMP client.
DSP GUI Value

TWAMPCLIE Range:0~63
NT Unit:None
LST Actual Value
TWAMPCLIE Range:0~63
NT Default Value:
46
DSCP BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPSEND TDLOFD-0030 Performance cates the DSCP
WCDMA, ER 18 Measurement of UDP
BTS3900 LTE MOD (FDD) measurement
TWAMPSEND IP Active packets sent by a
ER Performance TWAMP
Measurement sender.
LST
TWAMPSEND (TDD) GUI Value
ER Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:0

SingleRAN

Command
PKTSIZETYPE BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPSEND TDLOFD-0030 Performance cates the size
WCDMA, ER 18 Measurement type of packets
BTS3900 LTE MOD (FDD) sent by a
TWAMPSEND IP Active TWAMP
ER Performance sender.
LST Measurement GUI Value

TWAMPSEND (TDD) Range:FIXED
ER (FIXED),
RANDOM
(RANDOM)
Unit:None
Actual Value
Range:FIXED,
RANDOM
Default
Value:FIXED
(FIXED)
PKTSIZE BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPSEND TDLOFD-0030 Performance cates the size of
WCDMA, ER 18 Measurement packets sent by a
BTS3900 LTE MOD (FDD) TWAMP
TWAMPSEND IP Active sender, IP
ER Performance header is
Measurement included.
LST
ER Range:69~1500
Unit:byte
Actual Value
Range:69~1500
Default Value:
128

SingleRAN

Command
PKTINTTYPE BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPSEND TDLOFD-0030 Performance cates the type of
WCDMA, ER 18 Measurement the interval at
BTS3900 LTE MOD (FDD) which packets
TWAMPSEND IP Active are sent by a
ER Performance TWAMP
Measurement sender.
LST
ER Range:FIXED
(FIXED),
RANDOM
(RANDOM)
Unit:None
Actual Value
Range:FIXED,
RANDOM
Default
Value:FIXED
(FIXED)
PKTINT BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPSEND TDLOFD-0030 Performance cates the interval
WCDMA, ER 18 Measurement at which packets
BTS3900 LTE MOD (FDD) are sent by a
TWAMPSEND IP Active TWAMP
ER Performance sender.
LST Measurement GUI Value

TWAMPSEND (TDD) Range:10~1000
ER Unit:ms
Actual Value
Range:10~1000
Default Value:
1000

SingleRAN

Command
LOCALIP BTS3900, ADD LOFD-003018 IP Active Meaning:Indi-

BTS3900 TWAMPRESP TDLOFD-0030 Performance cates the local IP
WCDMA, ONDER 18 Measurement address of a
BTS3900 LTE MOD (FDD) TWAMP
TWAMPRESP IP Active responder.
ONDER Performance GUI Value
DSP Measurement Range:Valid IP
TWAMPRESP (TDD) address
ONDER Unit:None
LST Actual Value
TWAMPRESP Range:Valid IP
ONDER address
Default
Value:None
LocalIP BSC6900 ADD None None Meaning:Local

TWAMPRESP IP address. The
ONDER local IP address
MOD must be the
TWAMPRESP device IP
ONDER address, IP
address of an
Ethernet port, or
IP address of a
trunk group
configured
using the"ADD
DEVIP", "ADD
ETHIP" or
"ADD
ETHTRKIP"
command,
respectively.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None

SingleRAN

Command

TWAMPRESP IP address. The
ONDER local IP address
MOD must be the
TWAMPRESP device IP
ONDER address, IP
address of an
Ethernet port, or
IP address of a
trunk group
configured
using the"ADD
DEVIP", "ADD
ETHIP" or
"ADD
ETHTRKIP"
command,
respectively.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
VRFINDEX BTS3900, ADD None None Meaning:Indi-

BTS3900 TWAMPRESP cates the VRF
WCDMA, ONDER index of a
BTS3900 LTE MOD TWAMP
TWAMPRESP responder.
ONDER GUI Value
LST Range:0~7
TWAMPRESP Unit:None
ONDER Actual Value
Range:0~7
Default Value:0

SingleRAN

Command
DSCP BTS3900, ADD None None Meaning:Indi-

BTS3900 TWAMPRESP cates the DSCP
WCDMA, ONDER of TCP
BTS3900 LTE MOD negotiation
TWAMPRESP packets sent by a
ONDER TWAMP
responder.
DSP
TWAMPRESP GUI Value
ONDER Range:0~63
LST Unit:None
TWAMPRESP Actual Value
ONDER Range:0~63
Default Value:
46

TWAMPCLIE IP address. The
NT local IP address
MOD must be the
TWAMPCLIE device IP
NT address, IP
address of an
Ethernet port, or
IP address of a
trunk group
configured
using the"ADD
DEVIP", "ADD
ETHIP" or
"ADD
ETHTRKIP"
command,
respectively.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None

SingleRAN

Command

TWAMPCLIE IP address. The
NT local IP address
MOD must be the
TWAMPCLIE device IP
NT address, IP
address of an
Ethernet port, or
IP address of a
trunk group
configured
using the"ADD
DEVIP", "ADD
ETHIP" or
"ADD
ETHTRKIP"
command,
respectively.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None

SingleRAN

Command
PeerIP BSC6900 ADD None None Meaning:Peer

TWAMPCLIE IP address of a
NT TWAMP client.
MOD The peer IP
TWAMPCLIE address of a
NT TWAMP client
must neither be
the local IP
address
configured on
the RNC nor be
on the same
network
segment as the
OMU internal IP
address or OMU
external IP
address.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None

SingleRAN

Command
PeerIP BSC6910 ADD None None Meaning:Peer

TWAMPCLIE IP address of a
NT TWAMP client.
MOD The peer IP
TWAMPCLIE address of a
NT TWAMP client
must neither be
the local IP
address
configured on
the RNC nor be
on the same
network
segment as the
OMU internal IP
address or OMU
external IP
address.
GUI Value
Range:Valid IP
Address
Unit:None
Actual Value
Range:Valid IP
Address
Default
Value:None
ClientID BSC6900 ADD None None Meaning:This

TWAMPCLIE parameter
NT identifies a
MOD TWAMP client.
TWAMPCLIE GUI Value
NT Range:0~1023
RMV Unit:None
TWAMPCLIE Actual Value
NT Range:0~1023
Default
Value:None

SingleRAN

Command

TWAMPCLIE parameter
NT identifies a
MOD TWAMP client.
TWAMPCLIE GUI Value
NT Range:0~1023
RMV Unit:None
NT Range:0~1023
Default
Value:None
CLIENTID BTS3900, ADD None None Meaning:Indi-

BTS3900 TWAMPCLIE cates the index
WCDMA, NT of a TWAMP
BTS3900 LTE DSP client.
TWAMPCLIE GUI Value
NT Range:0~15
LST Unit:None
NT Range:0~15
MOD Default
TWAMPCLIE Value:None
NT
RMV
TWAMPCLIE
NT
VRFINDEX BTS3900, ADD None None Meaning:Indi-

BTS3900 TWAMPCLIE cates the VRF
WCDMA, NT index of a
BTS3900 LTE MOD TWAMP client.
TWAMPCLIE GUI Value
NT Range:0~7
LST Unit:None
NT Range:0~7
Default Value:0

SingleRAN

Command
DSCP BSC6900 ADD None None Meaning:This

TWAMPCLIE parameter
NT specifies the
MOD priority of a
TWAMPCLIE negotiation
NT packet. A larger
value of this
parameter
indicates a
higher priority
of the
negotiation
packet.
GUI Value
Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:
46
DSCP BSC6910 ADD None None Meaning:Differ-

TWAMPCLIE entiated
NT Services Code
MOD Point (DSCP) of
TWAMPCLIE a packet. The
NT service priority
of a packet is
determined
based on the
value of this
parameter.
GUI Value
Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:
46

SingleRAN

Command

TWAMPSEND parameter
ER specifies the
MOD priority of a test
TWAMPSEND packet. A larger
ER value of this
parameter
indicates a
higher priority
of the test
packet.
GUI Value
Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:0

TWAMPSEND parameter
ER specifies the
MOD priority of a test
TWAMPSEND packet. A larger
ER value of this
parameter
indicates a
higher priority
of the test
packet.
GUI Value
Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:0

SingleRAN

Command
PktSizeType BSC6900 ADD None None Meaning:This

TWAMPSEND parameter
ER specifies the
MOD length type of a
TWAMPSEND test packet.
ER GUI Value
Range:FIXED
(FIXED),
RANDOM
(RANDOM)
Unit:None
Actual Value
Range:FIXED,
RANDOM
Default
Value:FIXED
(FIXED)
PktSizeType BSC6910 ADD None None Meaning:This

TWAMPSEND parameter
ER specifies the
MOD length type of a
TWAMPSEND test packet.
ER GUI Value
Range:FIXED
(FIXED),
RANDOM
(RANDOM)
Unit:None
Actual Value
Range:FIXED,
RANDOM
Default
Value:FIXED
(FIXED)

SingleRAN

Command
PktSize BSC6900 ADD None None Meaning:This

TWAMPSEND parameter
ER specifies the
MOD length of a
TWAMPSEND packet to be sent
ER (including the IP
packet header).
GUI Value
Range:69~1500
Unit:byte
Actual Value
Range:69~1500
Default Value:
128
PktSize BSC6910 ADD None None Meaning:This

TWAMPSEND parameter
ER specifies the
MOD length of a
TWAMPSEND packet to be sent
ER (including the IP
packet header).
GUI Value
Range:69~1500
Unit:byte
Actual Value
Range:69~1500
Default Value:
128

SingleRAN

Command
PktIntType BSC6900 ADD None None Meaning:This

TWAMPSEND parameter
ER specifies the
MOD type of the
TWAMPSEND interval at which
ER test packets are
sent.
GUI Value
Range:FIXED
(FIXED),
RANDOM
(RANDOM)
Unit:None
Actual Value
Range:FIXED,
RANDOM
Default
Value:FIXED
(FIXED)
PktIntType BSC6910 ADD None None Meaning:This

TWAMPSEND parameter
ER specifies the
MOD type of the
TWAMPSEND interval at which
ER test packets are
sent.
GUI Value
Range:FIXED
(FIXED),
RANDOM
(RANDOM)
Unit:None
Actual Value
Range:FIXED,
RANDOM
Default
Value:FIXED
(FIXED)

SingleRAN

Command
PktInt BSC6900 ADD None None Meaning:This

TWAMPSEND parameter
ER specifies the
MOD interval at which
TWAMPSEND test packets are
ER sent.
GUI Value
Range:10~1000
Unit:ms
Actual Value
Range:10~1000
Default Value:
1000
PktInt BSC6910 ADD None None Meaning:This

TWAMPSEND parameter
ER specifies the
MOD interval at which
TWAMPSEND test packets are
ER sent.
GUI Value
Range:10~1000
Unit:ms
Actual Value
Range:10~1000
Default Value:
1000
ResponderID BSC6900 ADD None None Meaning:This

TWAMPRESP parameter
ONDER identifies a
MOD TWAMP
ONDER GUI Value
RMV Range:0~1023
TWAMPRESP Unit:None
ONDER Actual Value
Range:0~1023
Default
Value:None

SingleRAN

Command
ResponderID BSC6910 ADD None None Meaning:This

TWAMPRESP parameter
ONDER identifies a
MOD TWAMP
ONDER GUI Value
RMV Range:0~1023
TWAMPRESP Unit:None
ONDER Actual Value
Range:0~1023
Default
Value:None
RESPONDERI BTS3900, ADD None None Meaning:Indi-

D BTS3900 TWAMPRESP cates the index
WCDMA, ONDER of a TWAMP
BTS3900 LTE DSP responder.
TWAMPRESP GUI Value
ONDER Range:0~3
DSP Unit:None
TWAMPRESP Actual Value
ONDERSTA Range:0~3
LST Default
TWAMPRESP Value:None
ONDER
MOD
TWAMPRESP
ONDER
RMV
TWAMPRESP
ONDER

SingleRAN

Command

TWAMPRESP parameter
ONDER specifies the
MOD priority of a
TWAMPRESP negotiation
ONDER packet. A larger
value of this
parameter
indicates a
higher priority
of the
negotiation
packet.
GUI Value
Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:
46
DSCP BSC6910 ADD None None Meaning:Differ-

TWAMPRESP entiated
ONDER Services Code
MOD Point (DSCP) of
TWAMPRESP a packet. The
ONDER service priority
of a packet is
determined
based on the
value of this
parameter.
GUI Value
Range:0~63
Unit:None
Actual Value
Range:0~63
Default Value:
46

SingleRAN

Command

TWAMPSEND parameter
ER identifies a
MOD TWAMP client.
TWAMPSEND GUI Value
ER Range:0~1023
RMV Unit:None
TWAMPSEND Actual Value
ER Range:0~1023
Default
Value:None

TWAMPSEND parameter
ER identifies a
MOD TWAMP client.
TWAMPSEND GUI Value
ER Range:0~1023
RMV Unit:None
ER Range:0~1023
Default
Value:None
CLIENTID BTS3900, ADD None None Meaning:Indi-

BTS3900 TWAMPSEND cates the client
WCDMA, ER index of a
BTS3900 LTE DSP TWAMP
TWAMPSEND sender.
ER GUI Value
LST Range:0~15
TWAMPSEND Unit:None
ER Actual Value
MOD Range:0~15
TWAMPSEND Default
ER Value:None
RMV
TWAMPSEND
ER

SingleRAN

Command
SenderID BSC6900 ADD None None Meaning:Sender

TWAMPSEND ID of a TWAMP
ER client.
MOD GUI Value
TWAMPSEND Range:0~15
ER Unit:None
RMV Actual Value
ER
Default
Value:None
SenderID BSC6910 ADD None None Meaning:Sender

TWAMPSEND ID of a TWAMP
ER client.
MOD GUI Value
ER Unit:None
RMV Actual Value
ER
Default
Value:None
SENDERID BTS3900, ADD None None Meaning:Indi-

BTS3900 TWAMPSEND cates the index
WCDMA, ER of a TWAMP
BTS3900 LTE DSP sender.
TWAMPSEND GUI Value
ER Range:0~15
LST Unit:None
ER Range:0~15
MOD Default
TWAMPSEND Value:None
ER
RMV
TWAMPSEND
ER

SingleRAN
Description 9 Counters
9 Counters
Table 9-1 Counter description
Counter ID Counter Name Counter NE Feature ID Feature Name

Description
1542455996 VS.BSTWAMP Average NodeB Multi-mode: BTS IP Active

.Forward.Drop- forward packet None Performance
Means loss rate on the GSM: Measurement
BSTWAMP GBFD-151202 NodeB IP
UMTS: Active
WRFD-151212 Performance
Measurement
LTE:
LOFD-003018 IP Active
Performance
TDLOFD-0030 Measurement
18 (FDD)
IP Active
Performance
Measurement
(TDD)

SingleRAN

Description
1542455997 VS.BSTWAMP Peak forward NodeB Multi-mode: BTS IP Active

.Forward.Peak. packet loss rate None Performance
DropRates on the GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)

.Backward.Drop backward None Performance
Means packet loss rate GSM: Measurement
on the GBFD-151202 NodeB IP
BSTWAMP Active
UMTS:
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)

SingleRAN

Description
1542455999 VS.BSTWAMP Peak backward NodeB Multi-mode: BTS IP Active

.Backward.Peak packet loss rate None Performance
.DropRates on the GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)
1542456000 VS.BSTWAMP Minimum RTT NodeB Multi-mode: BTS IP Active

.MinRttDelay on the None Performance
BSTWAMP GSM: Measurement
GBFD-151202 NodeB IP
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)

SingleRAN

Description
1542456001 VS.BSTWAMP Average RTT on NodeB Multi-mode: BTS IP Active

.Rtt.Means the BSTWAMP None Performance
GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)
1542456002 VS.BSTWAMP Maximum RTT NodeB Multi-mode: BTS IP Active

.MaxRttDelay on the None Performance
BSTWAMP GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)

SingleRAN

Description
1542456003 VS.BSTWAMP Minimum NodeB Multi-mode: BTS IP Active

.Forward.MinJit forward jitter on None Performance
ter the BSTWAMP GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)

.Forward.Jitter. forward jitter on None Performance
Means the BSTWAMP GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)

SingleRAN

Description
1542456005 VS.BSTWAMP Maximum NodeB Multi-mode: BTS IP Active

.Forward.MaxJi forward jitter on None Performance
tter the BSTWAMP GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)
1542456006 VS.BSTWAMP Minimum NodeB Multi-mode: BTS IP Active

.Backward.Min- backward jitter None Performance
Jitter on the GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)

SingleRAN

Description

.Backward.Jitter backward jitter None Performance
.Means on the GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)
1542456008 VS.BSTWAMP Maximum NodeB Multi-mode: BTS IP Active

.Backward.Max backward jitter None Performance
Jitter on the GSM: Measurement
UMTS: Active
Measurement
LTE:
Performance
18 (FDD)
IP Active
Performance
Measurement
(TDD)
73426982 VS.TWAMP.Rt Minimum RTT BSC6900 WRFD-151211 RNC IP Active

tDelay.Min for TWAMP Performance
73426983 VS.TWAMP.Rt Maximum RTT BSC6900 WRFD-151211 RNC IP Active

tDelay.Max for TWAMP Performance
73426985 VS.TWAMP.Fo Minimum BSC6900 WRFD-151211 RNC IP Active

rward.Jitter.Min Forward Delay Performance
Jitters for Measurement
TWAMP
Measurement

SingleRAN

Description
73426986 VS.TWAMP.Fo Maximum BSC6900 WRFD-151211 RNC IP Active

rward.Jitter.Ma Forward Delay Performance
x Jitters for Measurement
TWAMP
Measurement
73426989 VS.TWAMP.Ba Minimum BSC6900 WRFD-151211 RNC IP Active

ckward.Jitter.Mi Backward Delay Performance
n Jitters for Measurement
TWAMP
Measurement
73426990 VS.TWAMP.Ba Maximum BSC6900 WRFD-151211 RNC IP Active

ckward.Jitter.M Backward Delay Performance
ax Jitters for Measurement
TWAMP
Measurement
73443304 VS.TWAMP.Fo Peak Forward BSC6900 WRFD-151211 RNC IP Active

rward.DropRate Packet Loss Performance
s.Max Rates for Measurement
TWAMP
Measurement
73443305 VS.TWAMP.Ba Average BSC6900 WRFD-151211 RNC IP Active

ckward.DropRa Backward Performance
tes.Mean Packet Loss Measurement
Rates for
TWAMP
Measurement
73443306 VS.TWAMP.Ba Peak Backward BSC6900 WRFD-151211 RNC IP Active

ckward.DropRa Packet Loss Performance
tes.Max Rates for Measurement
TWAMP
Measurement
73443307 VS.TWAMP.Rt Average RTT BSC6900 WRFD-151211 RNC IP Active

tDelay.Mean for TWAMP Performance
73443308 VS.TWAMP.Fo Average BSC6900 WRFD-151211 RNC IP Active

rward.Jitter.Mea Forward Delay Performance
TWAMP
Measurement

SingleRAN

Description

ean Jitters for Measurement
TWAMP
Measurement

rward.DropRate Forward Packet Performance
s.Mean Loss Rates for Measurement
TWAMP
Measurement
73426982 VS.TWAMP.Rt Minimum RTT BSC6910 WRFD-151211 RNC IP Active

tDelay.Min for TWAMP Performance
73426983 VS.TWAMP.Rt Maximum RTT BSC6910 WRFD-151211 RNC IP Active

tDelay.Max for TWAMP Performance
73426985 VS.TWAMP.Fo Minimum BSC6910 WRFD-151211 RNC IP Active

rward.Jitter.Min Forward Delay Performance
Jitters for Measurement
TWAMP
Measurement
73426986 VS.TWAMP.Fo Maximum BSC6910 WRFD-151211 RNC IP Active

rward.Jitter.Ma Forward Delay Performance
x Jitters for Measurement
TWAMP
Measurement
73426989 VS.TWAMP.Ba Minimum BSC6910 WRFD-151211 RNC IP Active

ckward.Jitter.Mi Backward Delay Performance
TWAMP
Measurement
73426990 VS.TWAMP.Ba Maximum BSC6910 WRFD-151211 RNC IP Active

ax Jitters for Measurement
TWAMP
Measurement
73443304 VS.TWAMP.Fo Peak Forward BSC6910 WRFD-151211 RNC IP Active

rward.DropRate Packet Loss Performance
s.Max Rates for Measurement
TWAMP
Measurement

SingleRAN

Description

ckward.DropRa Backward Performance
tes.Mean Packet Loss Measurement
Rates for
TWAMP
Measurement
73443306 VS.TWAMP.Ba Peak Backward BSC6910 WRFD-151211 RNC IP Active

ckward.DropRa Packet Loss Performance
tes.Max Rates for Measurement
TWAMP
Measurement
73443307 VS.TWAMP.Rt Average RTT BSC6910 WRFD-151211 RNC IP Active

tDelay.Mean for TWAMP Performance

rward.Jitter.Mea Forward Delay Performance
TWAMP
Measurement

ean Jitters for Measurement
TWAMP
Measurement

rward.DropRate Forward Packet Performance
s.Mean Loss Rates for Measurement
TWAMP
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.


Vdocuments - MX - Ip Active Performance Measurementsran90draft Apdf PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vdocuments - MX - Ip Active Performance Measurementsran90draft Apdf PDF

Uploaded by

Copyright:

Available Formats

SingleRAN

IP Active Performance Measurement

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

5.5 eNodeB TWAMP.........................................................................................................................................................21

Issue Draft A (2014-01-20) 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 defines different types of base stations.

Table 1-1 Definitions of different types of base stations

Base Station Type Description

GBTS Installed with the GTMU

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

Base Station Type Description

eGBTS Installed with the UMPT_G

NodeB Installed with the WMPT or UMPT_U

eNodeB Installed with the LMPT, UMPT_L, or UMPT_T

Co-MPT multimode base Installed with the UMPT_GU, UMPT_GL, UMPT_GT,

Separate-MPT Different modes of a separate-MPT multimode base station have

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 2

Protocol Number 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 supports IP performance detection on connections between wireless network

IP performance detection can be performed on connections between eNodeBs, between a GSM/

This document focuses on RFC5357: A Two-way Active Measurement Protocol (TWAMP).

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

l Network performance monitoring

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

3.1 Position of TWAMP in the TCP/IP Protocol Stack

Figure 3-1 Position of TWAMP in the TCP/IP protocol stack

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

3.2 Basic Concepts

3.2.1 Measurement Model

Figure 3-2 TWAMP measurement model

TWAMP architecture is composed of four logical roles: Session-Sender, Session-Reflector,

Figure 3-3 TWAMP measurement entities

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

The Responder passively responds to received packets.

3.2.2 Measurement Process

Figure 3-4 TWAMP negotiation process

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

In this phase, the test negotiation starts.

Phase 3: Starting test sessions

Currently, this feature supports only unauthenticated mode.

3.3 TWAMP Measurement Parameters

Figure 3-5 describes the test process.

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

Figure 3-5 TWAMP test process

This feature enables the Session-Sender to send packets periodically at an interval of 10 ms to

3.3.1 Packet Loss Rate