IP Active Performance Measurement(SRAN9.0_Draft A).pdf

SingleRAN

IP Active Performance MeasurementFeature 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 writtenconsent 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. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase 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 representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.com

Email: [email protected]

Issue Draft A (2014-01-20) Huawei Proprietary and ConfidentialCopyright © Huawei Technologies Co., Ltd.

i

http://www.huawei.com

mailto:[email protected]

Contents

1 About This Document..................................................................................................................11.1 Scope..............................................................................................................................................................................11.2 Intended Audience..........................................................................................................................................................21.3 Change History...............................................................................................................................................................2

2 Overview.........................................................................................................................................32.1 Description......................................................................................................................................................................42.2 Benefits...........................................................................................................................................................................4

3 Technical Description...................................................................................................................53.1 Position of TWAMP in the TCP/IP Protocol Stack.......................................................................................................53.2 Basic Concepts...............................................................................................................................................................63.2.1 Measurement Model....................................................................................................................................................63.2.2 Measurement Process..................................................................................................................................................73.3 TWAMP Measurement Parameters................................................................................................................................83.3.1 Packet Loss Rate..........................................................................................................................................................93.3.2 Round-Trip Delay......................................................................................................................................................103.3.3 Delay Variation..........................................................................................................................................................10

4 TWAMP Application..................................................................................................................114.1 Differences Between TWAMP and Huawei-Private IP PM.........................................................................................114.2 TWAMP Application on the Base Station Side...........................................................................................................134.2.1 TWAMP Controller Function Configuration............................................................................................................144.2.2 TWAMP Responder Function Configuration............................................................................................................154.2.3 Networking Scenarios................................................................................................................................................164.3 TWAMP Application on the Base Station Controller Side..........................................................................................164.3.1 TWAMP Controller Function Configuration............................................................................................................174.3.2 TWAMP Responder Function Configuration............................................................................................................174.3.3 Networking Scenarios................................................................................................................................................17

5 Related Features...........................................................................................................................195.1 eGBTS TWAMP..........................................................................................................................................................195.2 BSC TWAMP...............................................................................................................................................................195.3 NodeB TWAMP...........................................................................................................................................................205.4 RNC TWAMP..............................................................................................................................................................20

SingleRANIP Active Performance Measurement Feature ParameterDescription Contents


ii

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

6 Network Impact...........................................................................................................................226.1 System Capacity...........................................................................................................................................................226.2 Network Performance...................................................................................................................................................22

7 Engineering Guidelines.............................................................................................................237.1 When to Use IP Active Performance Measurement.....................................................................................................237.2 Required Information...................................................................................................................................................237.3 Planning........................................................................................................................................................................237.4 Feature Deployment.....................................................................................................................................................247.4.1 Requirements.............................................................................................................................................................247.4.2 Data Preparation........................................................................................................................................................257.4.3 Precautions.................................................................................................................................................................287.4.4 Activation..................................................................................................................................................................287.4.5 Activation Observation..............................................................................................................................................327.4.6 Hardware Adjustment................................................................................................................................................357.4.7 Deactivation...............................................................................................................................................................357.5 Performance Monitoring...............................................................................................................................................367.6 Parameter Optimization................................................................................................................................................367.7 Troubleshooting............................................................................................................................................................367.7.1 Checking Alarms.......................................................................................................................................................367.7.2 Using MML Commands............................................................................................................................................367.7.3 Capturing Packets......................................................................................................................................................38

8 Parameters.....................................................................................................................................40

9 Counters........................................................................................................................................66

10 Glossary.......................................................................................................................................76

11 Reference Documents...............................................................................................................77

SingleRANIP Active Performance Measurement Feature ParameterDescription Contents


iii

1 About This Document

1.1 ScopeIP 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 basestation, 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

SingleRANIP Active Performance Measurement Feature ParameterDescription 1 About This Document


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 basestation

Installed with the UMPT_GU, UMPT_GL, UMPT_GT,UMPT_UL, UMPT_UT, UMPT_LT, UMPT_GUL,UMPT_GUT, UMPT_ULT, UMPT_GLT, or UMPT_GULT. Aco-MPT multimode base station can have the same functions asany combination of the eGBTS, NodeB, and eNodeB. Forexample, a co-MPT multimode base station has the samefunctions as a combination of the eGBTS and NodeB wheninstalled with a UMPT_GU.

Separate-MPTmultimode base station

Different modes of a separate-MPT multimode base station havedifferent main control boards. For example, a base stationinstalled with the GTMU and WMPT is a separate-MPT GSM/UMTS dual-mode base station.

1.2 Intended AudienceThis document is intended for personnel who:

l Need to understand the features described hereinl Work with Huawei products

1.3 Change HistoryThis section provides information about the changes in different document versions. There aretwo types of changes, which are defined as follows:

l Feature changeChanges in features of a specific product version

l Editorial changeChanges 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.

SingleRANIP Active Performance Measurement Feature ParameterDescription 1 About This Document


2

2 Overview

The Internet Engineering Task Force (IETF) IP Performance Metrics (IPPM) working grouphas defined standards for performance metrics to support the configuration and maintenance ofIP networks. These performance metrics test the performance of end-to-end (E2E) Ethernet linksand improve the interoperability between transmission and test devices.

Huawei has developed the IP Active Performance Measurement feature in accordance with theIETF 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 networkelements (NEs) and devices that support TWAMP in a radio transport network. The performancemetrics include packet loss rate, round-trip delay, and delay variation. For details about theseperformance 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 servinggateway (SGW), between base station controllers, between a base station controller and a corenetwork (CN), between a wireless NE and a transmission device (for example, a router), andbetween a wireless NE and a test device.

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

SingleRANIP Active Performance Measurement Feature ParameterDescription 2 Overview


3

2.1 Description

2.2 BenefitsThe IP Active Performance Measurement feature reduces maintenance costs using the followingfunctions:

l Network performance monitoringIn scenarios in which the transmission rate is unstable and the transmission bandwidthdynamically changes, this function can detect the quality of service (QoS) of the transportnetwork 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 longdelay, using TWAMP.

– Troubleshoots a transport network on a per segment basis by measuring round-tripnetwork performance between a wireless NE and a transmission device (such as anintermediate router that supports TWAMP), thereby improving network maintainabilityand reducing maintenance costs.

TWAMP testing uses User Datagram Protocol (UDP) packet injection, which generates trafficin the transport network and therefore occupies some bandwidth. For example, if 80-byte packetsare continuously sent at a rate of 10 packets per second in a test stream, the bandwidthconsumption is 6.4 kbit/s.

SingleRANIP Active Performance Measurement Feature ParameterDescription 2 Overview


4

3 Technical Description

3.1 Position of TWAMP in the TCP/IP Protocol StackFigure 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 Figure3-1.

In accordance with TWAMP, this feature measures the transmission quality at the IP layer. Ifthe local end (a wireless NE) serves as the Control End, it sends test packets before performingIP segmentation. If the local end (a wireless NE) serves as the Response End, it performs IPreassembly before responding to the received test packets.

NOTE

The Local TWAMP protocol version is RFC5357. It is recommended that the local and peer TWAMPprotocol versions be the same.

SingleRANIP Active Performance Measurement Feature ParameterDescription 3 Technical Description


5

3.2 Basic Concepts

3.2.1 Measurement ModelTWAMP 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 controlpackets to initiate, start, and stop TWAMP test sessions.

The Session-Sender and Session-Reflector are TWAMP-test hosts, responsible for exchangingtest packets for testing. The Session-Sender sends test packets to the Session-Reflector and theSession-Reflector responds to the test packets.

In application, TWAMP merges different logical roles on the same host for easierimplementation. 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 relatedstatistics.



6

The Responder passively responds to received packets.

3.2.2 Measurement ProcessTWAMP measurement includes negotiation and testing. Negotiation is conducted between theControl-Client and Server using Transmission Control Protocol (TCP) packets. The Server usesthe fixed port port 862. Testing is conducted between the Session-Sender and Session-Reflectorbased on the UDP. Ports used by the UDP are assigned and managed internally among NEs andnegotiated 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 theServer.

2. The Server responds with a Server-Greeting message, indicating its supported mode ofcommunication.

3. The Control-Client responds with a Set-Up-Response message with its chosen mode ofcommunication. However, if the Server does not respond or responds with an unexpectedmode of communication, the Control-Client closes the connection.

4. The Server responds with a Server-Start message, indicating the test start time. Theconnection setup is complete.

Phase 2: Creating test sessions



7

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 thecommands 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 forthe UDP transmit port number, UDP receive port number, IP address, and differentiatedservices code point (DSCP).

2. The Server responds with an Accept-Session message, indicating whether it accepts thenegotiated results. The Server can respond with a different UDP port number that it willallow the Control-Client to use. The Control-Client receives the port number and enters thenext 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 itaccepts the test session.

Phase 4: Testing

Testing is carried out using UDP packets. The Session-Sender actively inserts test packets forthe Session-Reflector's response. The inserted test packets are transmitted in a fixed stream withthe 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 encryptedmode.

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 ParametersTWAMP 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 theSession-Sender. The Session-Reflector copies the packet sequence numbers and timestampT1 extracted from the received packets into the corresponding reflected packets to theSession-Sender. The corresponding reflected packets also include the Session-Reflector'stransmit sequence numbers and timestamp T3.

3. The Session-Sender records timestamp T4 upon receiving response packets from theSession-Reflector and then calculates the number of received packets.



8

Figure 3-5 TWAMP test process

This feature enables the Session-Sender to send packets periodically at an interval of 10 ms to1000 ms and randomly within a period ranging from 10 ms to 1000 ms. All these can be set inthe 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 toeach test packet it receives as soon as possible.

TWAMP defines negotiation timeout and test timeout for the Responder, which can be set in theSERVWAIT(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 negotiationpacket within the period specified by the SERVWAIT(BSC6900,BSC6910,NodeB) parameter. TheSERVWAIT(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 controllerserves as the Controller, it reinitiates negotiations if it has not received any test packets from its peerend within 900s during the test. This is because the base station or base station controller assumes thatthe peer end may have deleted the session.

3.3.1 Packet Loss RateThe packet loss rate indicates the transmission quality of a detected IP link. This feature dividesthe number of lost packets by the number of transmitted packets to obtain the packet loss ratein a measurement period. The number of lost packets is calculated based on the numbers ofpackets 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 ofpackets 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 – Numberof 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



9

3.3.2 Round-Trip DelayThe round-trip delay is delay of packets transmitted back and forth between the Session-Senderand 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 VariationThe 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 localend serves as the TWAMP Controller and experiences an active/standby board switchover, the local endreinitiates a TWAMP negotiation and starts a test after the negotiation is successful. If the local end servesas the TWAMP Responder and experiences an active/standby board switchover, the ongoing TWAMP testwill be affected and the local end will not respond to any tests.



10

4 TWAMP Application

4.1 Differences Between TWAMP and Huawei-Private IPPM

TWAMP applies to the following interfaces:

l GSM interfaces: Abis, A, and Gbl UMTS interfaces: Iub, Iu, and Iurl LTE interface: S1 and X2

The implementation principles for interfaces of different modes are the same. For details aboutthe implementation principles, see chapter 3 "Technical Description.".

For details about the base station and base station controller's TWAMP-related activationcommands and configuration parameters as well as test parameters that support TWAMP, seesections 4.2 TWAMP Application on the Base Station Side and 4.3 TWAMP Applicationon the Base Station Controller Side, respectively.

NOTE

TWAMP application to the co-MPT multimode base station is not discussed in this document because itis the same as TWAMP application to the eGBTS, NodeB, and eNodeB.

TWAMP and Huawei-private IP performance monitoring (IP PM) have their own advantagesand disadvantages. The following paragraphs explain their differences from the technical andapplication perspectives.

The Technical PerspectiveTWAMP is a set of standards defined by the IETF and Huawei-private IP PM is a protocoldeveloped by Huawei. Table 4-1 explains their technical differences.

SingleRANIP Active Performance Measurement Feature ParameterDescription 4 TWAMP Application


11

Table 4-1 Technical differences between TWAMP and Huawei-private IP PM

Item Huawei-Private IP PM TWAMP

Interconnection

The peer end must be a Huaweidevice.

The peer end can be any device supportingTWAMP.

Test Transmission QoS of onlineservices is detected.

Service packets are simulated. Offline tests ontransmission links are recommended.

Restriction

Depends on online services. Notest can be conducted when noservices are running.

l Packet injection affects ongoing servicesand occupies some bandwidth.

l The peer device must support TWAMP.

Huawei-private IP PM is used to monitor the QoS of transmission links for online services onthe user plane (UP).

TWAMP employs active testing by inserting test packets to test the QoS of E2E transmissionlinks. The test does not rely on service packets. Huawei-private IP PM tests E2E connectionsbetween the base station and base station controller, while TWAMP tests the connectionsbetween the base station and base station controller, or those between the base station/base stationcontroller 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). TWAMPmeasurement is based on quintuples (source IP address, destination IP address, source UDP port number,destination UDP port number, and DSCP).

The Application PerspectiveTWAMP 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 andbase station controller, and between the eNodeB and Huawei SGW, and TWAMP isrecommended for testing connections between the base station/base station controller andtransmission 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 connectionbetween the base station and transport network is in good condition

l Transmission counters when there is no traffic or the traffic is lightl Connections between devices that support TWAMP



12

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

Item Scenario Huawei-Private IPPM

TWAMP

Maintenance and testing

Tests on transmission counters with noongoing service

-- √

Tests on Iub/Abis connections betweenthe base station and base stationcontroller

Huawei-private IP PM isrecommended.

Tests on connections between a RANdevice and an intermediate transmissiondevice

-- √

QoS tests on S1/X2 connections betweenan eNodeB and a Huawei SGW/eNodeB

Huawei-private IP PM isrecommended.

QoS tests on S1/X2 connections betweenan eNodeB and a non-Huawei SGW/eNodeB

-- √

Monitoring Online monitoring of wireless serviceson the Iub/Abis/S1/X2 interface

√ --

QoS monitoring of transmission betweena base station/base station controller anda router or a non-Huawei SGW

-- √

4.2 TWAMP Application on the Base Station SideThis section describes IP Active Performance Measurement on the base station side. The relatedfeatures 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 theconnected peer device.

Table 4-3 Base station's functions with TWAMP

Peer Device Base Station's Function

Transmissiondevice

The base station is configured as the TWAMP Controller because thetransmission device generally supports the TWAMP Responderfunction.



13

Peer Device Base Station's Function

SGW When the base station is connected to a non-Huawei SGW, it isrecommended that the SGW and eNodeB be configured as the TWAMPResponder and TWAMP Controller, respectively.

Base stationcontroller

Huawei IP PM is preferred.When there is no service and TWAMP is used for testing, it isrecommended that the base station controller and base station beconfigured as the TWAMP Controller and TWAMP Responder,respectively.

Test device Test devices, such as Sprient TestCenter, support TWAMP. It isrecommended that the test device and base station be configured as theTWAMP Responder and TWAMP Controller, respectively.

4.2.1 TWAMP Controller Function ConfigurationThe eGBTS/NodeB/eNodeB supports the TWAMP Controller function. The TWAMPController is responsible for actively initiating tests, collecting statistics, and displaying testresults on the local end. The Responder function must be enabled on the peer end, such as arouter, base station controller, or eNodeB, to transmit and receive the negotiation and testpackets.

You can run the ADD TWAMPCLIENT and ADD TWAMPSENDER commands to activatea 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. Thegreater the DSCP value, the higher priority of the negotiation packets. Boththe 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 isrecommended that you set this parameter to the DSCP value of the servicesfor which the user shows concern.



14


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 ConfigurationThe eGBTS/NodeB/eNodeB supports the TWAMP Responder function. The Responderpassively responds to test packets. The TWAMP Controller function must be enabled on thepeer end, such as a base station controller, eNodeB, or test device, so that the peer end activelyinitiates 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(NodeB,BSC6900,BSC6910)

Local IP address for TWAMP tests. The local end serves as the Responder.

VRFINDEX VRF index of the TWAMP Responder.

DSCP DSCP of TCP negotiation packets sent by the TWAMP Responder.

SERVWAIT(NodeB,BSC6910,BSC6900)

Negotiation timeout. During negotiations, the Server closes the connectionif it has not received any negotiation packets within the period specified bythe SERVWAIT parameter.

REFWAIT(BSC6900,BSC6910,NodeB)

Test timeout. During tests, the Session-Reflector releases resources if it hasnot received any test packets within the period specified by the REFWAIT(BSC6900,BSC6910,NodeB) parameter.

NOTE

A base station supports four Responders, with each Responder supporting a maximum of 16 passiveresponse test streams. A base station supports 16 passive response test streams in total.



15

4.2.3 Networking ScenariosTable 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/NotSupported

Description

Port level FE/GE ports as the transmissionports connecting to the transportnetwork

Supported -

E1/T1 ports as the transmissionports connecting to the transportnetwork

Supported The WMPT andUMPT support E1/T1 ports.

Link level Active and standby routing devices Supported -

Board level UTRPc as the transmissioninterface board in a multimode basestation

Supported TWAMP isrecommended forthe UTRPc in thisscenario.

Site level Cascaded base stations Supported TWAMP can beused on all cascadedbase stations.

4.3 TWAMP Application on the Base Station Controller SideThis 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 Measurementl UMTS: WRFD-151211 RNC IP Active Performance Measurement

When TWAMP is applied on a base station controller, the base station controller's functionsdiffer depending on the connected peer device.

Table 4-8 Base station controller's functions with TWAMP

Peer Device Base Station Controller's Function

Transmissiondevice

The base station controller is configured as the TWAMP Controller becausethe transmission device generally supports the TWAMP Responderfunction.



16

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 noservice, it is recommended that the base station and base station controllerbe configured as the TWAMP Responder and TWAMP Controller,respectively.

4.3.1 TWAMP Controller Function ConfigurationThe BSC/RNC supports the TWAMP Controller function. The TWAMP Controller isresponsible for actively initiating tests, collecting statistics, and displaying test results on thelocal 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 thesame on the base station controller side and on the base station side. For details, see section4.2.1 TWAMP Controller Function Configuration.

NOTE

A base station controller supports 1024 Control-Clients, with each Control-Client supporting a maximumof 16 Session-Sender test streams. A base station controller supports 1024 Session-Sender test streams intotal.

4.3.2 TWAMP Responder Function ConfigurationThe BSC/RNC supports the TWAMP Responder function. The TWAMP Responder passivelyresponds 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 activelyinitiates tests and the local end passively responds to the tests.

The MML command and parameters configured for the TWAMP Responder function are similaron the base station controller side and on the base station side. For details, see section 4.2.2TWAMP Responder Function Configuration.

NOTE

A base station controller supports 1024 Responders, with each Responder supporting a maximum of 160passive response test streams. A base station controller supports 1024 passive response test streams in total.

4.3.3 Networking ScenariosTable 4-9 provides the networking scenarios in which a base station controller supportsTWAMP.



17

Table 4-9 Networking scenarios in which a base station controller supports TWAMP

Networking Scenario Supported/NotSupported

Description

Port level FE/GE ports as the transmissionports connecting to the transportnetwork

Supported The FG2c/FG2d/GOUc/GOUe/GOUd/EXOUasupports TWAMP.

IP over E1/TI applied on the RNC Not supported -

Linklevel

Active and standby link aggregationgroups (LAGs)

Supported -

LAGs working in load sharing mode Supported -

Routing devices working in loadsharing mode

Supported -

Active and standby routing devices Supported -

Boardlevel

Active and standby boards Supported -

Interface boards working intransmission resource pool mode

Supported An IP address isassigned on the localend for startingTWAMP tests.



18

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 workwith TWAMP simultaneously to perform loopback tests on specified IP addresses or all IPaddresses.

The UDP loopback function affects TWAMP testing. If one TWAMP test end is enabled withthe UDP loopback function and specified IP addresses or all IP addresses use the same IP addressthat is used for TWAMP testing, the test packets will be directly looped back, resulting ininaccurate statistics. If the base station functions as the TWAMP Controller, the peer Responder'sresponse packets will be looped back. As a result, the UDP packets are retransmitted betweenthe 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, andGBFD-118603 Gb over IP features when it is applied to the BSC6900 on the Abis, A, and Gbinterfaces, respectively.

This feature is dependent on the GBFD-150201 A over IP Based on Dynamic Load Balancingfeature when it is applied to the BSC6910 on the Abis interface.

SingleRANIP Active Performance Measurement Feature ParameterDescription 5 Related Features


19

Mutually Exclusive FeaturesNone

Impacted FeaturesNone

5.3 NodeB TWAMP

Prerequisite FeaturesThis feature is dependent on the WRFD-050402 IP Transmission Introduction on Iub Interfacefeature.


Impacted FeaturesIf the UDP loopback function is enabled on the base station side, UDP loopback cannot workwith TWAMP simultaneously to perform loopback tests on specified IP addresses or all IPaddresses. The UDP loopback function affects TWAMP testing. If one TWAMP test end isenabled with the loopback function and an IP address being looped back is the IP address usedfor TWAMP testing, the test packets will be directly looped back, resulting in inaccuratestatistics. If the base station functions as the TWAMP Controller, the peer Responder's responsepackets will be looped back. As a result, the UDP packets are retransmitted between the localend and peer end (Responder), which increases network resource consumption.

TWAMP affects IP performance monitoring when applied with the WRFD-050402 IPTransmission Introduction on Iub Interface and WRFD-150243 Iub IP Transmission Based onDynamic Load Balancing features. When a WMPT is configured on a base station and TWAMPand Huawei-private IP PM are enabled simultaneously, Huawei-private IP PM fails to measurethe test packets of TWAMP due to WMPT restrictions, resulting in inaccurate IP PM statistics.

5.4 RNC TWAMP

Prerequisite FeaturesIn non-IP pool networking, this feature is dependent on the WRFD-050402 IP TransmissionIntroduction on Iub Interface, WRFD-050409 IP Transmission Introduction on Iu Interface, andWRFD-050410 IP Transmission Introduction on Iur Interface features when it is applied on theIub, Iu, and Iur interfaces, respectively.

In IP pool networking, this feature is dependent on the WRFD-140207 Iu/Iur TransmissionResource 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 LoadBalancing and WRFD-150244 Iu/Iur IP Transmission Based on Dynamic Load Balancingfeatures (applied to the BSC6910).



20


Impacted FeaturesNone

5.5 eNodeB TWAMP



Impacted FeaturesIf the UDP loopback function is enabled on the base station side, UDP loopback cannot workwith TWAMP simultaneously to perform loopback tests on specified IP addresses or all IPaddresses.

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



21

6 Network Impact

6.1 System CapacityBecause TWAMP negotiation packet interaction occurs in the protocol stack and only a smallnumber of packets are involved, TWAMP has negligible impact on CPU performance.

TWAMP test packets affect the user plane (UP) forwarding performance because they aretransmitted and received on the UP. The greater the transmit rate of test packets, the greater theresource consumption of TWAMP forwarding. However, TWAMP forwarding resourceconsumption still has negligible impact when compared with the base station and base stationcontroller's forwarding capabilities.

6.2 Network PerformanceTWAMP testing uses packet injection, which generates traffic in the transport network andtherefore occupies some bandwidth. The bandwidth consumption is related to the transmit rateof test packets. Users can specify the transmit interval and packet length for the packets to betransmitted.

In maintenance and testing scenarios, if you are not sure whether the transmit rate (determinedby 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 recommendedfor a TWAMP test. For example, if 80-byte packets are continuously sent at a rate of 10 packetsper 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 sothat involved packets can be sent continuously. If 80-byte packets are sent at a rate of 10 packetsper second in a test stream, the bandwidth consumption is 6.4 kbit/s. You can monitor the teststream to check whether any transmission faults are occurring.

SingleRANIP Active Performance Measurement Feature ParameterDescription 6 Network Impact


22

7 Engineering Guidelines

7.1 When to Use IP Active Performance MeasurementIt is recommended that you enable the IP Active Performance Measurement feature to monitortransport networks if the bandwidth is sufficient. It is recommended that you only enable thisfeature temporarily for troubleshooting transport network faults if the bandwidth of the transportnetwork is limited when a data service performance fault occurs, such as an unstable downloadrate. After the troubleshooting is complete, disable this feature.

Table 7-1 provides the maximum specifications of TWAMP sessions supported by the basestation controller and base station.

Table 7-1 Maximum specifications of TWAMP sessions supported by different NEs

NE Maximum Specifications of TWAMPSessions Supported

BSC/RNC 160 per GOUc/GOUe/FG2c/EXOUa/GOUd/FG2d1024 per BSC/RNC

eGBTS/NodeB/eNodeB 16

7.2 Required InformationObtain the bandwidth usage of the transport network.

7.3 Planning

RF Planning

None

SingleRANIP Active Performance Measurement Feature ParameterDescription 7 Engineering Guidelines


23

Network Planning

None

Hardware Planning

None

7.4 Feature Deployment

7.4.1 Requirements

NEl 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/UTRPcto support TWAMP.

Licensel Licenses for the features listed in the following table must be purchased and activated.

Feature ID Feature Name License ControlItem

NE SalesUnit

GBFD-151201 BSC IP ActivePerformanceMeasurement

BSC IP ActivePerformanceMeasurement

BSC Per TRX

GBFD-151202 BTS IP ActivePerformanceMeasurement

BTS IP ActivePerformanceMeasurement

BTS Per BTS

WRFD-151211 RNC IP ActivePerformanceMeasurement

RNC IP ActivePerformanceMeasurement

RNC PerErl&Mbps

WRFD-151212 NodeB IP ActivePerformanceMeasurement

NodeB IP ActivePerformanceMeasurement

NodeB PerNodeB

LOFD-070219 IP ActivePerformanceMeasurement

IP ActivePerformanceMeasurement

eNodeB PereNodeB

TDLOFD-003018



eNodeB PereNodeB



24

Otherl 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 thenext hop.

Base station: In single VLAN mode, VLAN tags can be added to negotiation and test packetsbased on the next hop. In VLAN group mode, negotiation packets use the VLAN of the OM_Hconfigured in the next hop and test packets use the VLAN of the data packets configured withthe same DSCP in the next hop.

7.4.2 Data PreparationTWAMP 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 inTable 7-2 and Table 7-3.

Table 7-2 Data preparation for the TWAMP Controller function

MO ParameterName

Parameter ID Setting Notes Data Source

TWAMPCLIENT

Local IPAddress

LocalIP(BSC6900,BSC6910,NodeB)

- Network plan

Peer IP Address PeerIP(BSC6900,BSC6910,NodeB)

- Network plan

Client Index ClientID(BSC6900,BSC6910,NodeB)

- Network plan

VRF Index(only for basestations)

VRFINDEX - Network plan

Differentiatedservices codepoint

DSCP(BSC6900,BSC6910,NodeB)

The default valueis 46.

Internal plan



25

MO ParameterName

Parameter ID Setting Notes Data Source

TWAMPSENDER

Differentiatedservices codepoint


It isrecommendedyou set thisparameter to thepriority of theservice packetsfor which the usershows concern.

Network plan

Packet SizeType

PktSizeType(BSC6900,BSC6910,NodeB)

The default valueFixed isrecommended.

Internal plan

Packet Size PktSize(BSC6900,BSC6910,NodeB)

The default valueis 128 bytes.

Internal plan

Packet SendInterval Type

PktIntType(BSC6900,BSC6910,NodeB)

The default valueis Fixed.

Internal plan

Packet Interval PktInt(BSC6900,BSC6910,NodeB)

- Internal plan

NOTE

The local end actively transmits packets when it functions as the TWAMP Controller. The bandwidthconsumed 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 servicesfrom being affected, it is recommended that you enable IP Active Performance Measurement onlywhen you are familiar with this feature and TWAMP. To minimize risks and negative impacts onservices, 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 bandwidthconsumed 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. Thegreater 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 ifthere is sufficient network bandwidth.



26

Table 7-3 Data preparation for the TWAMP Responder function

MO Parameter Name Parameter ID Setting Notes Data Source

TWAMPRESPONDER

Local IP Address LocalIP(BSC6900,BSC6910,NodeB)

- Network plan

Responder Index ResponderID(BSC6900,BSC6910,NodeB)

- Network plan

VRF Index (onlyfor base stations)

VRFINDEX -

Differentiatedservices code point


The defaultvalue is 46.

Internal plan

Negotiation WaitTime

SERVWAIT(NodeB,BSC6910,BSC6900)

The defaultvalue defined bythe protocol900s isrecommended.

Internal plan

Measurement WaitTime

REFWAIT(BSC6900,BSC6910,NodeB)

The defaultvalue defined bythe protocol900s isrecommended.

Internal plan

Table 7-4 TWAMP communication matrix requirements on base stations and base stationcontrollers

NE Transmit/Receive

Function

TCP UDP

Source Port Destination Port

SourcePort

Destination Port

BaseStation

Transmit Controller

1024-65535 862 64695-64710

*

Responder

862 * 64679-64695

*

Receive Controller

862 1024-65535

* 64695-64710

Responder

* 862 * 64679-64694



27

Basestationcontroller

Transmit Controller

5201-6225 862 64968-64983

*

Responder

862 * 64984-64999

*

Receive Controller

862 5201-6225

* 64968-64983

Responder

* 862 * 64984-64999

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 thenegotiation. If the TWAMP Responder does not accept the Receiver Port number sent by the local end, itmust reply with an Accept-Session message containing an appropriate UDP port number. Otherwise, thenegotiation may fail.

7.4.3 PrecautionsNone

7.4.4 ActivationThis section describes how to activate the TWAMP functions using MML commands and theCME.

Using MML CommandsNOTE

l When MML commands are used, the commands are the same for the base station and base stationcontroller.

l Table 4-3 and Table 4-4 provide the related key parameters for the TWAMP Responder on the basestation 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 theTWAMP Controller function.

Step 2 (Optional) If required, run the MOD TWAMPCLIENT and MOD TWAMPSENDERcommands 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.



28

Step 2 (Optional) Run the MOD TWAMPRESPONDER command to modify theTWAMPRESPONDER 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 singleconfiguration on the TWAMP Controller function and TWAMP Responder function.

Step 1 On the CME, set BSC6900/6910 and eGBTS/NodeB/eNodeB parameters according to theoperation sequence in Table 7-5 and Table 7-6. For detailed instructions, see SingleConfiguration Operation Guide

----End

Table 7-5 Parameters related to the TWAMP Controller function

MO NE Parameter Name Parameter ID

TWAMPCLIENT

Base stationcontroller/basestation

Client Index ClientID(BSC6900,BSC6910,NodeB)


Peer IP Address PeerIP(BSC6900,BSC6910,NodeB)

VRF Index (only for basestations)

VRFINDEX



29


Differentiated services codepoint


TWAMPSENDER

Client Index CLIENTID(BSC6900,BSC6910,NodeB)

Sender Index SENDERID(BSC6900,BSC6910,NodeB)

Differentiated services codepoint


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


TWAMPRESPONDER

Base stationcontroller/basestation

Responder Index ResponderID(BSC6900,BSC6910,NodeB)


VRF Index (only forbase stations)

VRFINDEX

Differentiatedservices code point




30


Negotiation WaitTime

ServWait(BSC6900,BSC6910)SERVTIME

Measurement WaitTime

RefWait(BSC6900,BSC6910)REFTIME

Using the CME to Perform Batch Configuration

The eGBTS/NodeB/eNodeB supports using the CME to perform batch configuration on theTWAMP Controller function and TWAMP Responder function.

TWAMP is enabled after a device functions well. Batch reconfiguration using the CME is therecommended method to activate IP Active Performance Measurement on base stations. Thismethod 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 U2000client, or choose Advanced > Customize Summary Data File from the main menu of a CMEclient, 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 > MBTSApplication > Export Data > Export Base Station Bulk Configuration Data from themain menu of the U2000 client, or choose SRAN Application > MBTS Application >Export Data > Export Base Station Bulk Configuration Data from the main menu of theCME client.

l For separate-MPT GSM-involved multimode base stations or GO base stations: ChooseCME > GSM Application > Export Data > eGBTS Bulk Configuration Data from themain menu of the U2000 client, or choose GSM Application > Export Data > ExporteGBTS Bulk Configuration Data from the main menu of the CME client.

l For separate-MPT UMTS-involved multimode base stations or UO base stations: ChooseCME > UMTS Application > Export Data > Export Base Station Bulk ConfigurationData from the main menu of the U2000 client, or choose UMTS Application > ExportData > Export Base Station Bulk Configuration Data from the main menu of the CMEclient.

l For separate-MPT LTE-involved multimode base stations or LO base stations: ChooseCME > LTE Application > Export Data > Export Base Station Bulk ConfigurationData from the main menu of the U2000 client, or choose LTE Application > ExportData > Export Base Station Bulk Configuration Data from the main menu of the CMEclient.



31

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 theSummary DataFile

Parameter Group

TWAMPCLIENT Transport Data Client ID/Local IP/Peer IP/Vrf Index

TWAMPSENDER Transport Data Client ID/Sender ID/DSCP/Packet SizeType/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 theU2000 client, or choose SRAN Application > MBTS Application > Import Data > ImportBase 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: ChooseCME > GSM Application > Import Data > Import eGBTS Bulk Configuration Datafrom 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: ChooseCME > UMTS Application > Import Data > Import Base Station Bulk ConfigurationData from the main menu of the U2000 client, or choose UMTS Application > ImportData > Import Base Station Bulk Configuration Data from the main menu of the CMEclient.

l For separate-MPT LTE-involved multimode base stations or LO base stations: ChooseCME > LTE Application > Import Data > Import Base Station Bulk ConfigurationData from the main menu of the U2000 client, or choose LTE Application > ImportData > Import Base Station Bulk Configuration Data from the main menu of the CMEclient.

----End

7.4.5 Activation ObservationAfter activating the TWAMP functions, use either of the following methods to verify whetherthe TWAMP functions have been successfully activated.

The MML commands are the same for the base station and base station controller.

Using MML CommandsIf the local end serves as the TWAMP Controller, perform the following operations for activationobservation:

Step 1 Query the local Control-Client status by running the DSP TWAMPCLIENT command 2minutes after the TWAMP Controller function is enabled.



32

l For a base station controller: If Negotiation Status is Negotiation succeeded, TWAMPnegotiation on the CP was successful.

l For a base station: If Negotiation Status is CONTROL_LINK_UP, TWAMP negotiationon 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 TWAMPtest session was negotiated successfully.

l For a base station: If Negotiation Status is SESSION_UP, the TWAMP test session wasnegotiated successfully.

----End

The MML commands are the same on the base station controller side and on the base stationside.

If the local end serves as the TWAMP Responder, perform the following operations for activationobservation:

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 TWAMPtest session was negotiated successfully.

l For a base station: If Negotiation Status is SESSION_UP, the TWAMP test session wasnegotiated 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 beensuccessfully activated. Table 7-8 and Table 7-9 provide TWAMP performance counters on thebase 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 LossRates for TWAMPMeasurement

73443304 VS.TWAMP.Forward.DropRates.Max Peak Forward Packet Loss Ratesfor TWAMP Measurement

73443305 VS.TWAMP.Backward.DropRates.Mean

Average Backward Packet LossRates for TWAMPMeasurement

73443306 VS.TWAMP.Backward.DropRates.Max Peak Backward Packet LossRates for TWAMPMeasurement



33


73426982 VS.TWAMP.RttDelay.Min Minimum RTT for TWAMPMeasurement

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

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

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

73443308 VS.TWAMP.Forward.Jitter.Mean Average Forward Delay Jittersfor TWAMP Measurement

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

73426989 VS.TWAMP.Backward.Jitter.Min Minimum Backward DelayJitters for TWAMPMeasurement

73443309 VS.TWAMP.Backward.Jitter.Mean Average Backward Delay Jittersfor TWAMP Measurement

73426990 VS.TWAMP.Backward.Jitter.Max Maximum Backward DelayJitters for TWAMPMeasurement

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


1542455996 VS.BSTWAMP.Forward.DropRates.Mean

Average forward packet loss rateon the BSTWAMP

1542455997 VS.BSTWAMP.Forward.DropRates.Max

Peak forward packet loss rate onthe BSTWAMP

1542455998 VS.BSTWAMP.Backward.DropRates.Mean

Average backward packet lossrate on the BSTWAMP

1542455999 VS.BSTWAMP.Backward.DropRates.Max

Peak backward packet loss rateon the BSTWAMP

1542456000 VS.BSTWAMP.RttDelay.Min Minimum RTT on theBSTWAMP

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



34


1542456002 VS.BSTWAMP.RttDelay.Max Maximum RTT on theBSTWAMP

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

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

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

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

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

1542456008 VS.BSTWAMP.Backward.Jitter.Max Maximum backward jitter on theBSTWAMP

7.4.6 Hardware AdjustmentNone

7.4.7 DeactivationThe MML commands for deactivating the TWAMP functions are the same for the base stationcontroller 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 Responderfunction.

----End

MML Command Examples//Removing the TWAMP Session-Sender

RMV TWAMPSENDER: ClientID=0, SenderID=0;

//Removing the TWAMP Control-Client



35

RMV TWAMPCLIENT: ClientID=0;

//Deactivating the TWAMP Responder function

RMV TWAMPRESPONDER: RESPONDERID=0;

7.5 Performance MonitoringNone

7.6 Parameter OptimizationNone

7.7 Troubleshooting

7.7.1 Checking AlarmsIf the local end serves as the Controller, an NE reports alarms listed in Table 7-10 when aTWAMP negotiation fails.

After the TWAMP Controller function is enabled on the local end, the local end startsnegotiations with the TWAMP Responder. If the negotiations are unsuccessful for fourconsecutive minutes, alarms listed in Table 7-10 are reported.

During normal measurements, if the CP transmission is not restored in 11 minutes after beinginterrupted, the local end reinitiates negotiations. Again, if the negotiations are unsuccessful forfour 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 andthe 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 fourconsecutive minutes, alarms listed in Table 7-10 are reported.

Table 7-10 Fault alarms related to IP Active Performance Measurement

WorkingMode

NE Alarm Name

GU BSC/RNC ALM-21354 IP Link Performance MeasurementFault

GULT eGBTS/NodeB/eNodeB

ALM-25904 IP Link Performance MeasurementFault

7.7.2 Using MML Commands1. If the local end serves as the TWAMP Responder, run the DSP

TWAMPRESPONDERSTA command to check the negotiation statistics.



36

l If the cause is transmission interruption, unavailable routing, incorrect configuration ofthe peer IP address, the Responder cannot receive any TCP negotiation packets. In thiscase, check Number of TCP Setup Request Packets Received.

l If the local TCP resources, such as ports, are limited, any TCP connection establishmentattempts will be rejected. In this case, check Number of TCP Rejection PacketsSent.

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-Responsemessage. 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 NAKmessage in response to the received Request-TW-Session message. In this case, checkNumber 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 andDSP TWAMPSENDER commands to check the negotiation status and the negotiationfailure cause, if any.

For a base station:

l If the cause is transmission interruption, unavailable routing, incorrect configuration ofthe peer IP address, the Controller cannot establish TCP connections. In this case, checkwhether Negotiation Failure Cause is TCP_LINK_DOWN.

l If the peer TCP resources, such as ports, are limited, any TCP connection establishmentattempts will be rejected. In this case, check whether Negotiation Failure Cause isServer internal error.

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-Responsemessage. In this case, check whether Negotiation Failure Cause is Server nosupport.

l If the peer UDP resources, such as ports, are limited, the peer end replies with a NAKmessage in response to the received Request-TW-Session message. In this case, checkwhether Negotiation Failure Cause is Server resource limitation.

For a base station controller:

l If the cause is transmission interruption, unavailable routing, incorrect configuration ofthe 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 establishmentattempts will be rejected. In this case, check whether Status Change Cause is Serverinternal error.

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-Responsemessage. 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 NAKmessage in response to the received Request-TW-Session message. In this case, checkwhether Status Change Cause is Temporary resource limitation.

2. Troubleshoot according to the related statistics on the TWAMP Responder end or thenegotiation failure causes on the TWAMP Controller end.



37

Step 1 Check the network connection if the peer end fails to respond in a specified time or does notrespond 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 TWAMPfunctions, as described in Table 7-4.

----End

7.7.3 Capturing PacketsStep 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 PortNo to 862. The local port number can be queried by running the DSP TWAMPCLIENTcommand.

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 thefollowing 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 packetformat, see RFC 5357.

Step 3 Check whether the local end has transmitted the expected packets or has received the expectedpackets from the peer end.

l If the local end has not received the expected packets from the peer end, check the networkconnection.



38

l If the local end has not transmitted any expected packets, run the DSP TWAMPCLIENTand 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 endand re-enable the TWAMP functions.

l Check whether any transmission device prohibits the use of the ports required for theTWAMP functions, as described in Table 7-4.

----End



39

8 Parameters

Table 8-1 Parameter description

Parameter ID NE MMLCommand

Feature ID Feature Name Description

ServWait BSC6900 ADDTWAMPRESPONDERMODTWAMPRESPONDER

None None Meaning:Thisparameterspecifies theperiod withinwhich the serverwaits for thenegotiationpackets sent bythe peer end. Ifthe server doesnot receive anynegotiationpackets withinthe periodspecified by thisparameter, thenegotiationends.GUI ValueRange:10~1800Unit:sActual ValueRange:10~1800Default Value:900

SingleRANIP Active Performance Measurement Feature ParameterDescription 8 Parameters


40



ServWait BSC6910 ADDTWAMPRESPONDERMODTWAMPRESPONDER

None None Meaning:Thisparameterspecifies theperiod withinwhich the serverwaits for thenegotiationpackets sent bythe peer end. Ifthe server doesnot receive anynegotiationpackets withinthe periodspecified by thisparameter, thenegotiationends.GUI ValueRange:10~1800Unit:sActual ValueRange:10~1800Default Value:900



41



SERVWAIT BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDTWAMPRESPONDERMODTWAMPRESPONDERLSTTWAMPRESPONDER

LOFD-003018TDLOFD-003018

IP ActivePerformanceMeasurement(FDD)IP ActivePerformanceMeasurement(TDD)

Meaning:Indi-cates thenegotiation waittime of aTWAMPresponder. TheSERVWAITtimer is startedto monitor theestablishmentstatus of acontrolconnectionbetween theserver and theclient. When thistimer expires,the serverreleases thecontrolconnection tothe client.GUI ValueRange:10~1800Unit:sActual ValueRange:10~1800Default Value:900



42



RefWait BSC6900 ADDTWAMPRESPONDERMODTWAMPRESPONDER

None None Meaning:Thisparameterspecifies theperiod withinwhich the serverwaits for the testpackets sent bythe peer end. Ifthe server doesnot receive anytest packetswithin theperiod specifiedby thisparameter, thetest ends.GUI ValueRange:10~1800Unit:sActual ValueRange:10~1800Default Value:900



43



RefWait BSC6910 ADDTWAMPRESPONDERMODTWAMPRESPONDER

None None Meaning:Thisparameterspecifies theperiod withinwhich the serverwaits for the testpackets sent bythe peer end. Ifthe server doesnot receive anytest packetswithin theperiod specifiedby thisparameter, thetest ends.GUI ValueRange:10~1800Unit:sActual ValueRange:10~1800Default Value:900



44



REFWAIT BTS3900,BTS3900WCDMA,BTS3900 LTE




Meaning:Indi-cates themeasurementwait time of aTWAMPresponder. TheREFWAITtimer is startedto monitor thestatus of a testsession betweenthe server andthe client. Whenthis timerexpires, theserver releasesthe test sessionand returns tothe linkestablishmentstate.GUI ValueRange:10~1800Unit:sActual ValueRange:10~1800Default Value:900

LOCALIP BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDTWAMPCLIENTMODTWAMPCLIENTDSPTWAMPCLIENTLSTTWAMPCLIENT



Meaning:Indi-cates the local IPaddress of aTWAMP client.GUI ValueRange:Valid IPaddressUnit:NoneActual ValueRange:Valid IPaddressDefaultValue:None



45



PEERIP BTS3900,BTS3900WCDMA,BTS3900 LTE




Meaning:Indi-cates the peer IPaddress of aTWAMP client.GUI ValueRange:Valid IPaddressUnit:NoneActual ValueRange:Valid IPaddressDefaultValue:None

DSCP BTS3900,BTS3900WCDMA,BTS3900 LTE


None None Meaning:Indi-cates the DSCPof TCPnegotiationpackets sent by aTWAMP client.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:46


ADDTWAMPSENDERMODTWAMPSENDERLSTTWAMPSENDER



Meaning:Indi-cates the DSCPof UDPmeasurementpackets sent by aTWAMPsender.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:0



46



PKTSIZETYPE BTS3900,BTS3900WCDMA,BTS3900 LTE




Meaning:Indi-cates the sizetype of packetssent by aTWAMPsender.GUI ValueRange:FIXED(FIXED),RANDOM(RANDOM)Unit:NoneActual ValueRange:FIXED,RANDOMDefaultValue:FIXED(FIXED)

PKTSIZE BTS3900,BTS3900WCDMA,BTS3900 LTE




Meaning:Indi-cates the size ofpackets sent by aTWAMPsender, IPheader isincluded.GUI ValueRange:69~1500Unit:byteActual ValueRange:69~1500Default Value:128



47



PKTINTTYPE BTS3900,BTS3900WCDMA,BTS3900 LTE




Meaning:Indi-cates the type ofthe interval atwhich packetsare sent by aTWAMPsender.GUI ValueRange:FIXED(FIXED),RANDOM(RANDOM)Unit:NoneActual ValueRange:FIXED,RANDOMDefaultValue:FIXED(FIXED)

PKTINT BTS3900,BTS3900WCDMA,BTS3900 LTE




Meaning:Indi-cates the intervalat which packetsare sent by aTWAMPsender.GUI ValueRange:10~1000Unit:msActual ValueRange:10~1000Default Value:1000



48



LOCALIP BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDTWAMPRESPONDERMODTWAMPRESPONDERDSPTWAMPRESPONDERLSTTWAMPRESPONDER



Meaning:Indi-cates the local IPaddress of aTWAMPresponder.GUI ValueRange:Valid IPaddressUnit:NoneActual ValueRange:Valid IPaddressDefaultValue:None

LocalIP BSC6900 ADDTWAMPRESPONDERMODTWAMPRESPONDER

None None Meaning:LocalIP address. Thelocal IP addressmust be thedevice IPaddress, IPaddress of anEthernet port, orIP address of atrunk groupconfiguredusing the"ADDDEVIP", "ADDETHIP" or"ADDETHTRKIP"command,respectively.GUI ValueRange:Valid IPAddressUnit:NoneActual ValueRange:Valid IPAddressDefaultValue:None



49



LocalIP BSC6910 ADDTWAMPRESPONDERMODTWAMPRESPONDER


VRFINDEX BTS3900,BTS3900WCDMA,BTS3900 LTE


None None Meaning:Indi-cates the VRFindex of aTWAMPresponder.GUI ValueRange:0~7Unit:NoneActual ValueRange:0~7Default Value:0



50




ADDTWAMPRESPONDERMODTWAMPRESPONDERDSPTWAMPRESPONDERLSTTWAMPRESPONDER

None None Meaning:Indi-cates the DSCPof TCPnegotiationpackets sent by aTWAMPresponder.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:46

LocalIP BSC6900 ADDTWAMPCLIENTMODTWAMPCLIENT




51



LocalIP BSC6910 ADDTWAMPCLIENTMODTWAMPCLIENT




52



PeerIP BSC6900 ADDTWAMPCLIENTMODTWAMPCLIENT

None None Meaning:PeerIP address of aTWAMP client.The peer IPaddress of aTWAMP clientmust neither bethe local IPaddressconfigured onthe RNC nor beon the samenetworksegment as theOMU internal IPaddress or OMUexternal IPaddress.GUI ValueRange:Valid IPAddressUnit:NoneActual ValueRange:Valid IPAddressDefaultValue:None



53



PeerIP BSC6910 ADDTWAMPCLIENTMODTWAMPCLIENT

None None Meaning:PeerIP address of aTWAMP client.The peer IPaddress of aTWAMP clientmust neither bethe local IPaddressconfigured onthe RNC nor beon the samenetworksegment as theOMU internal IPaddress or OMUexternal IPaddress.GUI ValueRange:Valid IPAddressUnit:NoneActual ValueRange:Valid IPAddressDefaultValue:None

ClientID BSC6900 ADDTWAMPCLIENTMODTWAMPCLIENTRMVTWAMPCLIENT

None None Meaning:Thisparameteridentifies aTWAMP client.GUI ValueRange:0~1023Unit:NoneActual ValueRange:0~1023DefaultValue:None



54



ClientID BSC6910 ADDTWAMPCLIENTMODTWAMPCLIENTRMVTWAMPCLIENT


CLIENTID BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDTWAMPCLIENTDSPTWAMPCLIENTLSTTWAMPCLIENTMODTWAMPCLIENTRMVTWAMPCLIENT

None None Meaning:Indi-cates the indexof a TWAMPclient.GUI ValueRange:0~15Unit:NoneActual ValueRange:0~15DefaultValue:None

VRFINDEX BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDTWAMPCLIENTMODTWAMPCLIENTLSTTWAMPCLIENT

None None Meaning:Indi-cates the VRFindex of aTWAMP client.GUI ValueRange:0~7Unit:NoneActual ValueRange:0~7Default Value:0



55



DSCP BSC6900 ADDTWAMPCLIENTMODTWAMPCLIENT

None None Meaning:Thisparameterspecifies thepriority of anegotiationpacket. A largervalue of thisparameterindicates ahigher priorityof thenegotiationpacket.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:46

DSCP BSC6910 ADDTWAMPCLIENTMODTWAMPCLIENT

None None Meaning:Differ-entiatedServices CodePoint (DSCP) ofa packet. Theservice priorityof a packet isdeterminedbased on thevalue of thisparameter.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:46



56



DSCP BSC6900 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies thepriority of a testpacket. A largervalue of thisparameterindicates ahigher priorityof the testpacket.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:0

DSCP BSC6910 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies thepriority of a testpacket. A largervalue of thisparameterindicates ahigher priorityof the testpacket.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:0



57



PktSizeType BSC6900 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies thelength type of atest packet.GUI ValueRange:FIXED(FIXED),RANDOM(RANDOM)Unit:NoneActual ValueRange:FIXED,RANDOMDefaultValue:FIXED(FIXED)

PktSizeType BSC6910 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies thelength type of atest packet.GUI ValueRange:FIXED(FIXED),RANDOM(RANDOM)Unit:NoneActual ValueRange:FIXED,RANDOMDefaultValue:FIXED(FIXED)



58



PktSize BSC6900 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies thelength of apacket to be sent(including the IPpacket header).GUI ValueRange:69~1500Unit:byteActual ValueRange:69~1500Default Value:128

PktSize BSC6910 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies thelength of apacket to be sent(including the IPpacket header).GUI ValueRange:69~1500Unit:byteActual ValueRange:69~1500Default Value:128



59



PktIntType BSC6900 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies thetype of theinterval at whichtest packets aresent.GUI ValueRange:FIXED(FIXED),RANDOM(RANDOM)Unit:NoneActual ValueRange:FIXED,RANDOMDefaultValue:FIXED(FIXED)

PktIntType BSC6910 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies thetype of theinterval at whichtest packets aresent.GUI ValueRange:FIXED(FIXED),RANDOM(RANDOM)Unit:NoneActual ValueRange:FIXED,RANDOMDefaultValue:FIXED(FIXED)



60



PktInt BSC6900 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies theinterval at whichtest packets aresent.GUI ValueRange:10~1000Unit:msActual ValueRange:10~1000Default Value:1000

PktInt BSC6910 ADDTWAMPSENDERMODTWAMPSENDER

None None Meaning:Thisparameterspecifies theinterval at whichtest packets aresent.GUI ValueRange:10~1000Unit:msActual ValueRange:10~1000Default Value:1000

ResponderID BSC6900 ADDTWAMPRESPONDERMODTWAMPRESPONDERRMVTWAMPRESPONDER

None None Meaning:Thisparameteridentifies aTWAMPresponder.GUI ValueRange:0~1023Unit:NoneActual ValueRange:0~1023DefaultValue:None



61



ResponderID BSC6910 ADDTWAMPRESPONDERMODTWAMPRESPONDERRMVTWAMPRESPONDER

None None Meaning:Thisparameteridentifies aTWAMPresponder.GUI ValueRange:0~1023Unit:NoneActual ValueRange:0~1023DefaultValue:None

RESPONDERID

BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDTWAMPRESPONDERDSPTWAMPRESPONDERDSPTWAMPRESPONDERSTALSTTWAMPRESPONDERMODTWAMPRESPONDERRMVTWAMPRESPONDER

None None Meaning:Indi-cates the indexof a TWAMPresponder.GUI ValueRange:0~3Unit:NoneActual ValueRange:0~3DefaultValue:None



62



DSCP BSC6900 ADDTWAMPRESPONDERMODTWAMPRESPONDER

None None Meaning:Thisparameterspecifies thepriority of anegotiationpacket. A largervalue of thisparameterindicates ahigher priorityof thenegotiationpacket.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:46

DSCP BSC6910 ADDTWAMPRESPONDERMODTWAMPRESPONDER

None None Meaning:Differ-entiatedServices CodePoint (DSCP) ofa packet. Theservice priorityof a packet isdeterminedbased on thevalue of thisparameter.GUI ValueRange:0~63Unit:NoneActual ValueRange:0~63Default Value:46



63



ClientID BSC6900 ADDTWAMPSENDERMODTWAMPSENDERRMVTWAMPSENDER


ClientID BSC6910 ADDTWAMPSENDERMODTWAMPSENDERRMVTWAMPSENDER


CLIENTID BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDTWAMPSENDERDSPTWAMPSENDERLSTTWAMPSENDERMODTWAMPSENDERRMVTWAMPSENDER

None None Meaning:Indi-cates the clientindex of aTWAMPsender.GUI ValueRange:0~15Unit:NoneActual ValueRange:0~15DefaultValue:None



64



SenderID BSC6900 ADDTWAMPSENDERMODTWAMPSENDERRMVTWAMPSENDER

None None Meaning:SenderID of a TWAMPclient.GUI ValueRange:0~15Unit:NoneActual ValueRange:0~15DefaultValue:None

SenderID BSC6910 ADDTWAMPSENDERMODTWAMPSENDERRMVTWAMPSENDER

None None Meaning:SenderID of a TWAMPclient.GUI ValueRange:0~15Unit:NoneActual ValueRange:0~15DefaultValue:None

SENDERID BTS3900,BTS3900WCDMA,BTS3900 LTE

ADDTWAMPSENDERDSPTWAMPSENDERLSTTWAMPSENDERMODTWAMPSENDERRMVTWAMPSENDER

None None Meaning:Indi-cates the indexof a TWAMPsender.GUI ValueRange:0~15Unit:NoneActual ValueRange:0~15DefaultValue:None



65

9 Counters

Table 9-1 Counter description

Counter ID Counter Name CounterDescription

NE Feature ID Feature Name

1542455996 VS.BSTWAMP.Forward.Drop-Means

Averageforward packetloss rate on theBSTWAMP

NodeB Multi-mode:NoneGSM:GBFD-151202UMTS:WRFD-151212LTE:LOFD-003018TDLOFD-003018

BTS IP ActivePerformanceMeasurementNodeB IPActivePerformanceMeasurementIP ActivePerformanceMeasurement(FDD)IP ActivePerformanceMeasurement(TDD)

SingleRANIP Active Performance Measurement Feature ParameterDescription 9 Counters


66



1542455997 VS.BSTWAMP.Forward.Peak.DropRates

Peak forwardpacket loss rateon theBSTWAMP



1542455998 VS.BSTWAMP.Backward.DropMeans

Averagebackwardpacket loss rateon theBSTWAMP





67



1542455999 VS.BSTWAMP.Backward.Peak.DropRates

Peak backwardpacket loss rateon theBSTWAMP



1542456000 VS.BSTWAMP.MinRttDelay

Minimum RTTon theBSTWAMP





68



1542456001 VS.BSTWAMP.Rtt.Means

Average RTT onthe BSTWAMP



1542456002 VS.BSTWAMP.MaxRttDelay

Maximum RTTon theBSTWAMP





69



1542456003 VS.BSTWAMP.Forward.MinJitter

Minimumforward jitter onthe BSTWAMP



1542456004 VS.BSTWAMP.Forward.Jitter.Means

Averageforward jitter onthe BSTWAMP





70



1542456005 VS.BSTWAMP.Forward.MaxJitter

Maximumforward jitter onthe BSTWAMP



1542456006 VS.BSTWAMP.Backward.Min-Jitter

Minimumbackward jitteron theBSTWAMP





71



1542456007 VS.BSTWAMP.Backward.Jitter.Means

Averagebackward jitteron theBSTWAMP



1542456008 VS.BSTWAMP.Backward.MaxJitter

Maximumbackward jitteron theBSTWAMP



73426982 VS.TWAMP.RttDelay.Min

Minimum RTTfor TWAMPMeasurement

BSC6900 WRFD-151211 RNC IP ActivePerformanceMeasurement

73426983 VS.TWAMP.RttDelay.Max

Maximum RTTfor TWAMPMeasurement


73426985 VS.TWAMP.Forward.Jitter.Min

MinimumForward DelayJitters forTWAMPMeasurement




72



73426986 VS.TWAMP.Forward.Jitter.Max

MaximumForward DelayJitters forTWAMPMeasurement


73426989 VS.TWAMP.Backward.Jitter.Min

MinimumBackward DelayJitters forTWAMPMeasurement


73426990 VS.TWAMP.Backward.Jitter.Max

MaximumBackward DelayJitters forTWAMPMeasurement


73443304 VS.TWAMP.Forward.DropRates.Max

Peak ForwardPacket LossRates forTWAMPMeasurement



AverageBackwardPacket LossRates forTWAMPMeasurement


73443306 VS.TWAMP.Backward.DropRates.Max

Peak BackwardPacket LossRates forTWAMPMeasurement


73443307 VS.TWAMP.RttDelay.Mean

Average RTTfor TWAMPMeasurement


73443308 VS.TWAMP.Forward.Jitter.Mean

AverageForward DelayJitters forTWAMPMeasurement




73



73443309 VS.TWAMP.Backward.Jitter.Mean

AverageBackward DelayJitters forTWAMPMeasurement


73443310 VS.TWAMP.Forward.DropRates.Mean

AverageForward PacketLoss Rates forTWAMPMeasurement


73426982 VS.TWAMP.RttDelay.Min

Minimum RTTfor TWAMPMeasurement


73426983 VS.TWAMP.RttDelay.Max

Maximum RTTfor TWAMPMeasurement


73426985 VS.TWAMP.Forward.Jitter.Min

MinimumForward DelayJitters forTWAMPMeasurement


73426986 VS.TWAMP.Forward.Jitter.Max

MaximumForward DelayJitters forTWAMPMeasurement


73426989 VS.TWAMP.Backward.Jitter.Min

MinimumBackward DelayJitters forTWAMPMeasurement


73426990 VS.TWAMP.Backward.Jitter.Max

MaximumBackward DelayJitters forTWAMPMeasurement


73443304 VS.TWAMP.Forward.DropRates.Max

Peak ForwardPacket LossRates forTWAMPMeasurement




74




AverageBackwardPacket LossRates forTWAMPMeasurement


73443306 VS.TWAMP.Backward.DropRates.Max

Peak BackwardPacket LossRates forTWAMPMeasurement


73443307 VS.TWAMP.RttDelay.Mean

Average RTTfor TWAMPMeasurement


73443308 VS.TWAMP.Forward.Jitter.Mean

AverageForward DelayJitters forTWAMPMeasurement


73443309 VS.TWAMP.Backward.Jitter.Mean

AverageBackward DelayJitters forTWAMPMeasurement


73443310 VS.TWAMP.Forward.DropRates.Mean

AverageForward PacketLoss Rates forTWAMPMeasurement




75

10 Glossary

For the acronyms, abbreviations, terms, and definitions, see Glossary.

SingleRANIP Active Performance Measurement Feature ParameterDescription 10 Glossary


76

11 Reference Documents

None.

SingleRANIP Active Performance Measurement Feature ParameterDescription 11 Reference Documents


77