Nokia 

Networks

LTE Radio Access, Rel. FDD-

LTE 16, Operating
Documentation, Issue 02

Feature Descriptions RL30

DN0986461
Issue 01O
Approval Date 2015-09-30

 
 
   

Descriptions of transport and transmission features Feature Descriptions RL30

Table 97: New parameters lists parameters introduced with this feature.

Table 97 New parameters

Full name Abbreviated name Managed object

LTAC identifier ltacId LTAC

TAC activity factor tacActivityFactor LTAC

Exclude layer 2 overhead tacExludeL2Overhead LTAC

TAC limit GBR emergency tacLimitGbrEmergency LTAC

TAC limit GBR handover tacLimitGbrHandover LTAC

TAC limit GBR normal tacLimitGbrNormal LTAC

TAC identifier tacId TAC

Table 98: Additional parameters for RL40 lists parameters introduced with RL40 for this
feature.

Table 98 Additional parameters for RL40

Full name Abbreviated name Managed object

Average Packet Size For QCI Value 2 qci2AvPacketSize LTAC

Average Packet Size For QCI Value 3 qci3AvPacketSize LTAC

Average Packet Size For QCI Value 4 qci4AvPacketSize LTAC

5.1.1.6 Sales information

Table 99 Sales information

BSW/ASW License control in License control

network element attributes

BSW - -

5.2 LTE574: IP Transport Network Measurements

Introduction to the feature

160 DN0986461 Issue: 01O

   

Feature Descriptions RL30 Descriptions of transport and transmission features

The LTE574: IP Transport Network Measurements feature provides active measures and
supervision of the conditions through the mobile backhaul transport network between two
points, for example:

• eNB and SEG
• eNB and other (third party) site router or measuring equipment

Measuring and supervising is based on RFC863 UDP Echo and/or RFC5357 Two Way
Active Measurement Protocol (TWAMP).

5.2.1 Benefits
This feature brings OPEX savings as the operator is able to monitor the network
conditions and can react quickly to potential service degradations. The measurements
provide an indication of possible violations against an SLA (Service Level Agreement).
CAPEX savings are obtained, because the built-in measurement obsoletes expensive
measurement equipment that would be otherwise required to supervise and troubleshoot
the network.

5.2.2 Requirements
Software requirements
Table 100: Software requirements lists the software required for this feature.

Table 100 Software requirements

System eNodeB MME SAE GW UE NetAct

release

Release RL30 LBTS3.0 - - - -

Hardware requirements
This feature requires no new or additional hardware.

5.2.3 Functional description

The feature LTE574: IP Transport Network Measurements introduces a possibility to
actively measure and supervise the conditions through the mobile backhaul transport
network between two points, using RFC863 UDP Echo and RFC5357 TWAMP protocols
(TWAMP light). Measurements can be performed, for example, between the eNB and
SEG, between eNB and other site router or measuring equipment or between two eNBs
(X2 interface measuring).
The purpose of the measurement is to have an estimation of the quality and performance
of the IP-based mobile backhaul. If the measured values fall under configurable
thresholds, an alarm is raised. With this feature it is possible to carry out the
measurements with different, configurable DiffServ Code points and packet sizes.
All measurements are performed on IP layer. Thus, either physical or virtual interfaces
can be measured if only IP address is assigned.
This feature allows the eNB to take part in measurements in three different roles:

Issue: 01O DN0986461 161

   

Descriptions of transport and transmission features Feature Descriptions RL30

• TWAMP measurement sender (initiator) - the eNB actively sends and receives test

traffic. The following values are measured:
– Round-trip time (RTT)
– Round-trip Packet Loss Ratio (PLR)

• TWAMP responder - the eNB reflects the received test traffic after adding receive
and transmit timestamps towards the entity which carries out the measurement.
• UDP echo server -to support measurement senders without TWAMP capability, the
eNB provides an UDP Echo service according to RFC862. The eNB only reflects the
received test traffic without adding any further information towards the entity which
carries out the measurement. The echoed packets have the same DSCP value and
the Do Not Fragment flag (DF) is copied as well.

g Note: The total traffic which is reflected by the eNB UDP Echo server and TWAMP
responder applications is restricted by a rate limiter to 100 packets per second. The
purpose of the rate limiter is to avoid Denial of Service attacks.

TWAMP packet formats

Figure 17: Packet formats gives an overview on the TWAMP packet formats (both for
request and response packet).

Figure 17 Packet formats
Sender
PacketPadding
TTL (8bit)
SenderErrorEst.(16bit) MBZ(16bit)

Sender Timestamp(64bit)

Sender SequenceNumber(32bit)

Reciving TimestampatReflector(64bit)

ErrorEst.(16bit) PacketPadding ErrorEst.(16bit) MBZ(16bit)

TransmitTimestampatSender(64bit) Transmit TimestampatReflector(64bit)

SequenceNumberatSender(32bit) SequenceNumberatReflector(32bit)

UDP UDP

IP IP

Layer2 Layer2

Packetformatfor Packetformatfor
Session-Sender Session-Reflector
The TWAMP sender sends presented packet to the configured end-point of the
measurement. The sequence number field carries the information about the number of
the packet according to the transmit order (it starts with zero and is incremented one for
each packet). The Error Estimate specifies the estimate of the error and synchronization.
The Timestamp field is used to calculate packet delay. To ensure the same measurement
conditions, it is reccomended that session-sender and session-reflector packets have the
same length. This can be achieved with the use of the Packet Padding field.

162 DN0986461 Issue: 01O

   

Feature Descriptions RL30 Descriptions of transport and transmission features

In the packet format for session-reflector the Sender Sequence Number, Sender
Timestamp and Sender Error Estimate fields are copied from the received packet and
TTL 255 is set. The MBZ abbreviation stands for Must Be Zero statement. That means
that all bits are equal to zero.

5.2.3.1 Measured values

Round-Trip Time (RTT) based on two timestamps
When the reflector has an UDP echo server implemented, the round-trip time (RTT) is
calculated based on 2 timestamps (Figure 18: RTT based on two timestamps). The RTT
is defined as the difference between the timestamp when the reply packet was received
(Receive Timestamp Sender - RTSS) and the timestamp when the measurement packet
was initially sent (Transmit Timestamp Sender - TTSS. The equation for calculation the
RTT based on two timestamps is as follows:
RTT = RTSS - TTSS
The minumum, maximum and average values of the round-trip time are presented for
both 1 minute and 15 minutes time interval via the BTS Site Manager application.

Figure 18 RTT based on two timestamps

T TTSS TWAMPmessagecontainingTTSS
S
G

T ReflectedTWAMPmessagecontainingTTSS
TWAMP UDPEcho
S
Sender Server
G RTSS

TSG:TimeStampGenerator
TTSS:TransmitTimeStampatSender
RTSS:Received TimeStampatSender
Round-Trip Time (RTT) based on four timestamps
When the reflector has a TWAMP responder implementation, the round-trip time (RTT) is
calculated based on four timestamps (Figure 19: RTT based on four timestamps). The
RTT is defined as the difference between the timestamp when the reply packet was
received (Receive timestamp Sender - RTSS) and the timestamp when the
measurement packet was initially sent (Transmit Timestamp Sender - TTSS). This delay
value is corrected by eliminating the internal processing time at the reflector side, which
is defined as the difference between Transmit Timestamp Reflector (TTSR) and Receive
Timestamp Reflector (RTSR). The equation for calculation the RTT based on four
timestamps is as follows:
RTT = RTSS - TTSS - (TTSR - RTSR)
The minumum, maximum, and average values of the round-trip time are presented for
both 1minute and 15 minutes time interval via BTS Site Manager application.

Issue: 01O DN0986461 163

   

Descriptions of transport and transmission features Feature Descriptions RL30

Figure 19 RTT based on four timestamps

TTSS RTSR
T TWAMPmessagecontainingTTSS T
S S
G G

TWAMPmessagecontainingTTSS,
T T
TWAMP RTSRandTTSR TWAMP
Sender S S Reflector
RTSS TTSR
G G

TSG:TimeStampGenerator
TTSS:TransmitTimeStampatSender
RTSR:Receive TimeStampatReceiver
TTSR: TransmitTimeStampatReceiver
RTSS:Received TimeStampatSender
Two-way packet loss
When the responder node has a TWAMP reflector implementation, it is possible to
calculate the two-way packet loss. The eNB sends TWAMP request packets towards the
reflector entity with a sequence number according to the transmit order (it starts with
zero and is incremented one for each packet). The reflector copies the sequence number
from the received test packet to the corresponding field in the header of the response
packet and sends it back to the measurement initiator. The two-way packet loss is
defined as a difference between the total amount of sent measurement packets and the
number of all response packets received at the eNB during the measurement time
interval. The packet loss ratio statistics are presented for each 15 minutes measurement
time interval via the BTS Site Manager (BTSSM) application.

5.2.3.2 User scenarios

Three different use case secnarios can be applied:

• eNB as TWAMP sender, SEG/site router/external PC as TWAMP responder or

UDP Echo server
The reflector must mirror the test traffic, which may or may not include the insertion
of receive/transmit time stamps,. The eNB must be able to calculate the roundtrip
delay both from packets with and without these time stamps (Figure 20: User
scenario 1).
Figure 20 User scenario 1

L2/L3
Transport
Network
SecurityGatewayor externalPCwith
analyzertool=TWAMPresponderor
eNB =TWAMPsender UDPechoserver

ExternalPC
• eNB as TWAMP responder, SEG/site router/external PC as TWAMP sender

164 DN0986461 Issue: 01O

   

Feature Descriptions RL30 Descriptions of transport and transmission features

This configuration would allow starting the measurement from a central site towards
the eNB. The drawback of this usage is that the measurement results are available
at the SEG/site-router only. How to retrieve this data and present it in the
management system depends on the used router device (Figure 21: User scenario
2).
Figure 21 User scenario 2

L2/L3
Transport
Network
SecurityGatewayor externalPCwith
analyzertool=TWAMPsender
eNB =TWAMP responder

ExternalPC
• eNB as UDP Echo server, SEG/site router/external PC as UDP sender
The eNB supports the UDP Echo functionality which allows reflecting received UDP
measurement traffic on the standard port back. The UDP test traffic is generated and
sent by the SEG, a site router or an external PC, which also analyzes the results and
presents the statistics to the operator (Figure 22: User scenario 3).
Figure 22 User scenario 3

L2/L3
Transport
Network

SecurityGatewayor externalPCwith
analyzertool=UDP sender
eNB =UDPechoserver

ExternalPC

g Note: There are no particular limitations to be taken into account when IPSec is used.
The IP measurements can be done inside the IPSec tunnel or outside the tunnel.

5.2.3.3 Feature limitations

If IP network measurements are performed inside IPsec tunnel, measurement packets
are naturally encrypted/decrypted by IPsec termination points. However, neither
authenticated nor encrypted measurement messages are supported outside the IPsec
tunnel.

5.2.4 System impact

Interdependencies between features
This feature has no interdependencies with other features.
Impact on interfaces

Issue: 01O DN0986461 165

   

Descriptions of transport and transmission features Feature Descriptions RL30

This feature has no impact on interfaces.
Impact on network and network element management tools
This feature introduces new operator configurable parameters.
Impact on system performance and capacity
This feature has a small impact on eNB performance due to sending/receiving
measurement traffic. TWAMP test traffic has a minor influence on capacity of transport
linkfrom/towards the eNB. The operator needs to take this capacity into account.

• 8kbps for default values (rate limit: 10messages/second; message size: 100B)
• 120 kbps for maximum values (rate limit: 10 messages/second; message size:
MTU=1500 B)

5.2.5 LTE574: IP Transport Network Measurements management

data
For information on alarms, counters, key performance indicators, and parameter
documents, see Reference documentation.
Alarms
 lists existing alarms related to this feature.

Table 101 Related existing alarms

Alarm ID Alarm name

7665 BASE STATION TRANSMISSION ALARM
The following LTE574 relevant BTS Faults are related to this alarm:

• 61610 TWAMP RTT Threshold Crossed
• 61611 TWAMP PLR Threshold Crossed

Measurements and counters

 lists counters introduced with this feature.

Table 102 New counters

Counter ID Counter name Measurement

M51132C0 avgRTT_15Min LTE TWAMP Statistics

(TWAMP)

M51132C1 maxRTT_15Min LTE TWAMP Statistics

(TWAMP)

M51132C2 minRTT_15Min LTE TWAMP Statistics

(TWAMP)

166 DN0986461 Issue: 01O

   

Feature Descriptions RL30 Descriptions of transport and transmission features

Table 102 New counters (Cont.)

Counter ID Counter name Measurement

M51132C3 lostTwampMessages LTE TWAMP Statistics

(TWAMP)

M51132C4 txTwampMessage LTE TWAMP Statistics

(TWAMP)

Key performance indicators

There are no key performance indicators related to this feature.
Parameters
 lists parameters introduced with this feature.

Table 103 New parameters

Full name Abbreviated name Managed

object

Feature Activation Flag IP Transport Network twampFlag IPNO

Measurements

TWAMP reflector and udp echo flag indicator actIpTnlMeasure IPNO

TWAMP application or IP interface address twampIpAddress IPNO

TWAMP message response enabling flag twampReflFlag IPNO

UDP echo flag udpEchoFlag IPNO

TWAMP initiator rate for sending messages twampMessageRate IPNO

TWAMP reflector port number twampReflectorPort IPNO

Lock or unlock a TWAMP session administrativeState TWAMP

TWAMP session destination IP address destIpAddress TWAMP

TWAMP session destination port destPort TWAMP

DSCP value for TWAMP message transmission dscp TWAMP

TWAMP initiator message size messageSize TWAMP

Packet loss ratio alarm threshold plrAlarmThreshold TWAMP

Round-trip-time alarm threshold rttAlarmThreshold TWAMP

Issue: 01O DN0986461 167

   

Descriptions of transport and transmission features Feature Descriptions RL30

Table 103 New parameters (Cont.)

Full name Abbreviated name Managed

object

TWAMP initiator messages source IP address sourceIpAddress TWAMP

TWAMP session identifier twampId TWAMP

5.2.6 Sales information

Table 104 Sales information

BSW/ASW License control in License control

network element attributes

ASW - -

5.3 LTE866: Fast IP Rerouting

Introduction to the feature
Fast IP Rerouting feature introduces path switchover mechanism that is able to:

• define Primary Path (preferred) and Alternative Path (redundant) in the L2 network
• reroute traffic from failed path over working path (with switchover time tolerable for
an end user

L3 Bidirectional Forwarding Detection (BFD) described in LTE592: Link Supervision with
BFD is used to detect failures.

5.3.1 Benefits
End-user benefits
This feature improves network reliability.
Operator benefits
This feature benefits the operator as follows:

• IP network reliability is improved
• redundant routers are introduced
• switchover time tolerable for an end user

5.3.2 Requirements
Software requirements
Table 105: Software requirements lists the software required for this feature.

168 DN0986461 Issue: 01O