Technical Report

TR-471
Maximum IP-Layer Capacity Metric, Related Metrics,
and Measurements
Issue: 2
Date: December 2021

© The Broadband Forum. All rights reserved.

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Notice

The Broadband Forum is a non-profit corporation organized to create guidelines for broadband network system
development and deployment. This Technical Report has been approved by members of the Forum. This
Technical Report is subject to change. This Technical Report is owned and copyrighted by the Broadband
Forum, and all rights are reserved. Portions of this Technical Report may be owned and/or copyrighted by
Broadband Forum members.

Intellectual Property

Recipients of this Technical Report are requested to submit, with their comments, notification of any relevant
patent claims or other intellectual property rights of which they may be aware that might be infringed by any
implementation of this Technical Report, or use of any software code normatively referenced in this Technical
Report, and to provide supporting documentation.

Terms of Use

1. License
Broadband Forum hereby grants you the right, without charge, on a perpetual, non-exclusive and worldwide
basis, to utilize the Technical Report for the purpose of developing, making, having made, using, marketing,
importing, offering to sell or license, and selling or licensing, and to otherwise distribute, products complying
with the Technical Report, in all cases subject to the conditions set forth in this notice and any relevant patent
and other intellectual property rights of third parties (which may include members of Broadband Forum). This
license grant does not include the right to sublicense, modify or create derivative works based upon the
Technical Report except to the extent this Technical Report includes text implementable in computer code, in
which case your right under this License to create and modify derivative works is limited to modifying and
creating derivative works of such code. For the avoidance of doubt, except as qualified by the preceding
sentence, products implementing this Technical Report are not deemed to be derivative works of the Technical
Report.

2. NO WARRANTIES
THIS TECHNICAL REPORT IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN
PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT AND ANY IMPLIED WARRANTIES ARE
EXPRESSLY DISCLAIMED. ANY USE OF THIS TECHNICAL REPORT SHALL BE MADE ENTIRELY AT
THE USER’S OR IMPLEMENTER'S OWN RISK, AND NEITHER THE BROADBAND FORUM, NOR ANY OF
ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY USER,
IMPLEMENTER, OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY
OR INDIRECTLY, ARISING FROM THE USE OF THIS TECHNICAL REPORT, INCLUDING BUT NOT
LIMITED TO, ANY CONSEQUENTIAL, SPECIAL, PUNITIVE, INCIDENTAL, AND INDIRECT DAMAGES.

3. THIRD PARTY RIGHTS

Without limiting the generality of Section 2 above, BROADBAND FORUM ASSUMES NO RESPONSIBILITY
TO COMPILE, CONFIRM, UPDATE OR MAKE PUBLIC ANY THIRD PARTY ASSERTIONS OF PATENT OR
OTHER INTELLECTUAL PROPERTY RIGHTS THAT MIGHT NOW OR IN THE FUTURE BE INFRINGED BY
AN IMPLEMENTATION OF THE TECHNICAL REPORT IN ITS CURRENT, OR IN ANY FUTURE FORM. IF
ANY SUCH RIGHTS ARE DESCRIBED ON THE TECHNICAL REPORT, BROADBAND FORUM TAKES NO
POSITION AS TO THE VALIDITY OR INVALIDITY OF SUCH ASSERTIONS, OR THAT ALL SUCH
ASSERTIONS THAT HAVE OR MAY BE MADE ARE SO LISTED.

All copies of this Technical Report (or any portion hereof) must include the notices, legends, and other
provisions set forth on this page.

December 2021 © The Broadband Forum. All rights reserved 2 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Issue History

Issue Number Approval Date Release Date Issue Editor Changes

1 10 July 2020 10 July 2021 Al Morton, Original
AT&T
2 28 December 2021 28 December 2021 Al Morton, Expanded
AT&T configuration (Table
1) ; Reordering Metric
(Table 2) ; Revised
default valuses in
Table 3 ; New clause
5.2.2 ; New results
specified in Table 4 ;
New Diagnostic Test
Metrics in Table 5 ;
Spoftware version
and control protocol
version now in Table
6.

Comments or questions about this Broadband Forum Technical Report should be directed to info@broadband-
forum.org.

Editor: Al Morton, AT&T

Work Area Director(s): David Sinicrope, Ericsson

Project Stream Leader(s): Greg Mirsky, ZTE

December 2021 © The Broadband Forum. All rights reserved 3 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Table of Contents
1 Purpose and Scope ...................................................................................................... 7
1.1 Purpose ........................................................................................................................... 7
1.2 Scope .............................................................................................................................. 7
2 References and Terminology ....................................................................................... 8
2.1 Conventions ..................................................................................................................... 8
2.2 References ...................................................................................................................... 8
2.3 Definitions ........................................................................................................................ 9
2.4 Abbreviations ................................................................................................................... 9
3 Working Text Impact .................................................................................................. 11
3.1 Energy Efficiency ........................................................................................................... 11
3.2 Security.......................................................................................................................... 11
3.3 Privacy ........................................................................................................................... 11
4 Maximum IP-Layer Capacity Metric – related definitions............................................ 12
4.1 Population of Interest ..................................................................................................... 12
4.2 IP packet sending bit rate Metric Definition .................................................................... 12
4.3 Maximum IP-Layer Capacity Metric Definition ................................................................ 12
5 Methods of Measurement for the IP-Layer Capacity Metric ....................................... 14
5.1 Measurement Reference Architecture ............................................................................ 14
5.2 Measurement Procedure................................................................................................ 15
5.2.1 Sending Rate Search Algorithm..................................................................................................23
5.2.2 Lost Status Backoff Timeout and Interaction with the “B” Search Algorithm ..............................26
6 Results ....................................................................................................................... 28
Annex A: Sending Rates Table ....................................................................................... 35
A.1 Example Table of Sending Rates and Related Information ............................................ 35

December 2021 © The Broadband Forum. All rights reserved 4 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Table of Figures
Figure 1: Illustration of Time and Trial results during a single search for Maximum IP-Layer Capacity in the
measurement process. ............................................................................................................................12
Figure 2: Maximum IP Capacity measurement reference architecture ............................................................14
Figure 3: IP Edge to CPE measurement of Maximum IP Capacity ..................................................................15
Figure 4: Flowchart for Offered Load adjustment as part of the “B” Search Algorithm ....................................24

Table of Tables
Table 1: Measurement Variables, Ranges, and Default values .......................................................................15
Table 2: Parameters for Metrics and Supporting Test Protocols ......................................................................21
Table 3: Flowchart Variables, Descriptions, Ranges, and Default values ........................................................24
Table 4: Data Model Definition for Results .......................................................................................................28
Table A.1: Example Table of Sending Rates....................................................................................................35

December 2021 © The Broadband Forum. All rights reserved 5 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Executive Summary

As the speed of access links increase into the Gigabit range for some technologies, the dominant methods of
helping users test to discover their actual “Internet Speed” are showing their age. These TCP-based methods,
even with CUBIC window flow control, reacting conservatively to loss and round-trip delay often produce a
significant underestimate of Maximum IP-Layer Capacity.

Meanwhile, the Industry is seeing a transition to new Transport protocols that will replace TCP for many users.
They use UDP as the Transport protocol, and encrypt activity above the transport layer (such as IETF QUIC).
Measuring the IP-Layer Capacity on a User’s access link should be straightforward and use the same
Transport protocols as Users (many use UDP now, more in the future).

This document defines a Maximum IP-layer Capacity Metric and Methods of Measurement whose accuracy
has been carefully evaluated with lab and field measurements.

In Issue 2, several enhancements appear in the specification stemming from testing and development in the
Open Broadband Project (OB-UDPST) and elsewhere. Some access technologies are configured to offer an
initial “fast” mode where the Maximum IP-Layer Capacity delivered is higher than the subsequent Maximum
level offered to the same flow later in its lifetime. Repeatable observations of this bimodal behavior are
sufficient cause to report the results for each mode separately. Also, Issue 2 includes options whether to
process measurements of packet stream sequence discontinuities (such as reordering and
duplication/replication) in the load adjustment algorithm, in case these forms of impairment are prevalent in the
test stream and contribute a notable fraction of IP-Layer Capacity.

December 2021 © The Broadband Forum. All rights reserved 6 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

1 Purpose and Scope

The Purpose and Scope sections describe the work on Active measurements of Maximum IP-Layer Capacity.

1.1 Purpose
The main goal is to harmonize the specified definitions, metrics and methods across the industry, and this
project is the vehicle through which the BBF consensus is captured and communicated to achieve broad
agreement, and possibly resulting in changes in similar the specifications of other Standards Development
Organizations (SDO).

A goal unique to BBF is to provide efficient test procedures, especially the locations of measurement points,
and to recommend results reporting with a view to data models for the results. These procedures are developed
with an eye towards future remote control, data collection, and automation through TR-069 or TR-369 (USP).

1.2 Scope
The scope of this TR is to provide definitions, define metrics and the corresponding methods to unambiguously
perform active measurements of Maximum IP-Layer Capacity. This includes the definition of the metric's
parameters that influence how the test stream is generated and the metric is measured, resulting in an
assessment of the Maximum IP-Layer Capacity over the (short) test interval. The scope includes any related
IP-layer metrics as required by the method.

December 2021 © The Broadband Forum. All rights reserved 7 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

2 References and Terminology

2.1 Conventions
In this Technical Report, several words are used to signify the requirements of the specification. These words
are always capitalized. More information can be found be in RFC 2119 [9].

MUST This word, or the term “REQUIRED”, means that the definition is an absolute
requirement of the specification.
MUST NOT This phrase means that the definition is an absolute prohibition of the
specification.
SHOULD This word, or the term “RECOMMENDED”, means that there could exist valid
reasons in particular circumstances to ignore this item, but the full implications
need to be understood and carefully weighed before choosing a different
course.
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" means that there could
exist valid reasons in particular circumstances when the particular behavior is
acceptable or even useful, but the full implications need to be understood and
the case carefully weighed before implementing any behavior described with
this label.
MAY This word, or the term “OPTIONAL”, means that this item is one of an allowed
set of alternatives. An implementation that does not include this option MUST
be prepared to inter-operate with another implementation that does include
the option.

2.2 References
The following references are of relevance to this Technical Report. At the time of publication, the editions
indicated were valid. All references are subject to revision; users of this Technical Report are therefore
encouraged to investigate the possibility of applying the most recent edition of the references listed below.

A list of currently valid Broadband Forum Technical Reports is published at www.broadband-forum.org.

Document Title Source Year

[1] TR-069 CPE WAN Management Protocol BBF 2019
Amendment 6
[2] TR-101 Migration to Ethernet-Based Broadband Aggregation BBF 2011
Issue 2
[3] TR-143 Enabling Network Throughput Performance Tests and BBF 2015
Statistical Monitoring, Issue: 1 Amendment 1
Corrigendum 1
[4] TR-181 Device Data Model for TR-069 BBF 2015
[5] TR-304 Broadband Access Service Attributes and Performance BBF 2015
Metrics
[6] TR-369 User Services Platform (USP) BBF 2019

[7] Y.1540 Internet protocol data communication service - IP packet ITU-T 2019
transfer and availability performance parameters (and
Amendment 1)
[8] Y.1565 Home network performance parameters ITU-T 2011

December 2021 © The Broadband Forum. All rights reserved 8 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

[9] RFC 2119 Key words for use in RFCs to Indicate Requirement IETF 1997
Levels
[10] RFC 2681 A Round-trip Delay Metric for IPPM IETF 1999
[11] RFC 3393 IP Packet Delay Variation Metric for IP Performance IETF 2002
Metrics (IPPM)
[12] RFC 4737 Packet Reordering Metrics IETF 2006
[13] RFC 5481 Packet Delay Variation Applicability Statement IETF 2009
[14] RFC 6335 Internet Assigned Numbers Authority (IANA) Procedures IETF 2011
for the Management of the Service Name and Transport
Protocol Port Number Registry
[15] RFC 6576 IP Performance Metrics (IPPM) Standard Advancement IETF 2012
Testing (a.k.a. BCP 176)
[16] RFC 7680 A One-Way Loss Metric for IP Performance Metrics IETF 2016
(IPPM) (a.k.a. STD 82)
[17] RFC 5560 A One-Way Packet Duplication Metric IETF 2009
[18] RFC 7950 The YANG 1.1 Modeling Language IETF 2016

2.3 Definitions
The following terminology is used throughout this Technical Report.

Sender The test endpoint which sends test packets to the Receiver and which receives status
messages from the Receiver.
Receiver The test endpoint which receives test packets from the Sender and which sends status
messages to the Sender.
Test Endpoint The host at either end of the network test path. A test endpoint can be either a Sender
or a Receiver for any given test.
Test Controller A host which configures the test endpoints for a test. The test endpoint which performs
the sending rate search algorithm during the test and which reports the measurement
results. Either the Sender or the Receiver can be the Test Controller for any given test.

2.4 Abbreviations
This Technical Report uses the following abbreviations:

CUBIC A widespread form of congestion control for transport-layer protocols

DSCP Diffserv Code Point
Dst Destination
IETF Internet Engineering Task Force
IPDV IP Packet Delay Variation
IPRR IP Packet Reordered Ratio
IPSBR IP Packet Sending Bit Rate
PM Performance Metrics
QUIC A new transport protocol under development in the IETF (work-in-progress)
RIPR Replicated IP Packet Ratio
Src Source
TCP Transmission Control Protocol

December 2021 © The Broadband Forum. All rights reserved 9 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

TR Technical Report
UDP User Datagram Protocol
WA Work Area
WT Working Text

December 2021 © The Broadband Forum. All rights reserved 10 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

3 Technical Report Impact

3.1 Energy Efficiency

Similar to TR-143 [3], this Technical Report has no impact on energy efficiency.

3.2 Security
Similar to TR-143 [3], this Technical Report has no additional impact on Security.

3.3 Privacy
Similar to TR-143 [3], this Technical Report has no additional impact on Privacy.

December 2021 © The Broadband Forum. All rights reserved 11 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

4 Maximum IP-Layer Capacity Metric – related definitions

Supporting definitions and conventions are provided in this section.

4.1 Population of Interest

Population of Interest: All of the performance metrics defined in this document require a specific set of packets
called the population of interest. For the end-to-end 1-way measurement case, the population of interest is
(usually) the total set of measurement packets being sent from the sender to the receiver. The measurement
points in the end-to-end 1-way case are at the sender and receiver. This definition is equivalent to the sum of
qualifications used in IETF RFCs developed by the IPPM working group, where Parameters such as the packet
stream characteristics and the Type-P describing the make-up of packets in the measurement stream sent
from Src (source, or Sender) to Dst (destination, or Receiver) constitute the population of interest. For bi-
directional testing, the populations may be different by direction, and require a separate specification applying
to each direction.

4.2 IP packet sending bit rate Metric Definition

For a given population of interest, the IP packet sending bit rate (IPSBR) generated by the Source host is the
number of bits in the IP packet headers and payloads resulting in IP packet reference events divided by the
time interval duration.

4.3 Maximum IP-Layer Capacity Metric Definition

An illustration of the testing process is given below, as viewed by the Receiver.

Figure 1: Illustration of Time and Trial results during a single search for Maximum IP-Layer Capacity
in the measurement process.

The measurement process can be characterized as a search for the Maximum IP-Layer Capacity, where the
Sender bit-rate is adjusted according to feedback from the receiver in an effort to discover the Maximum IP-
Layer Capacity along with the performance in terms of packet loss and delay. The test packets arrive at the

December 2021 © The Broadband Forum. All rights reserved 12 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

receiver during a corresponding sub-interval dtn, (equivalent to [dtn, dtn+1]), of which m sub-intervals comprise
the complete measurement interval, [t, t + Δt].

During each sub-interval, dtn, there are many adjustments of the sending rate and subsequent measurement
feedback reports from the receiver, called Trials. Each Trial report is the input to a sender load-adjustment
algorithm. The search algorithm has a measurement goal, such as minimal loss and delay variation less than
a configured value. These adjustments apply to type Search, whereas type Fixed-rate runs at a fixed bit rate.

For each sub-interval, dtn, the IP-Layer Capacity is calculated as the number of IP-layer bits received (n0)
divided by the time, dt, for a result in bits per second. Corresponding values of Packet loss and delay are
summarized and associated with each Capacity.

When the time for a search is completed, the IP-layer Capacity values are evaluated for the maximum in the
test interval, and reported with the corresponding values of Packet loss and delay, with the condition that the
target threshold for at least one fundamental metric has been met in that sub-interval, dtn.

Mathematically, we express this process as follows:

For a given population of interest, the maximum IP-layer capacity during time interval [t, t + Δt] is:

Maximum_C(t, Δt, PM)

Equation 1: Maximum IP Capacity Metric

where:

time interval [t, t + Δt] is composed of m equal sub-intervals, dt in length;

PM is a list of fundamental metrics, such as loss, delay, and reordering, and a corresponding Target
performance threshold. At least one fundamental metric and Target performance threshold must be supplied
(such as One-way IP Packet Loss [RFC7680] equal to zero).

n0 is the total number of IP-layer header and payload bits that can be transferred over a basic section
generating successful IP packet transfer outcomes at the egress measurement point during a specified time
interval, [dtn, dtn+1] , and

the Maximum C(t, Δt) corresponds to the maximum value of n0 measured in any sub-interval [dtn, dtn+1] within
time interval [t, t + Δt], divided by the duration of the sub-interval.

Note that UDP transport shall be used when assessing the Measureable IP Capacity Metric.

The method of measurement also needs a definition for its sending rate, supplied in section 4.2.

December 2021 © The Broadband Forum. All rights reserved 13 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

5 Methods of Measurement for the IP-Layer Capacity Metric

Methods of measurement are provided in this section. The Methods have sufficiently detailed specifications
for implementation that will produce statistically equivalent results (as described in [IETF RFC 6576] from IPPM
work). The Methods are described independently of the data modeling language or the protocols used to
organize and transmit information between the different elements in the test architecture.

5.1 Measurement Reference Architecture

The reference architecture for measuring Maximum IP Capacity is shown in Figure 2. The primary functional
elements in the architecture are the Sender and Receiver, denoting the transmitting and receiving endpoints
of the test path through the network being measured. Sender and Receiver are functional terms defined by
both the network path to be tested and the direction of the test, in that the Sender for a test in one direction
becomes the Receiver for a test across the same network path in the other direction. A physical endpoint
supporting Maximum IP Capacity will support both Sender and Receiver functions.

Figure 2: Maximum IP Capacity measurement reference architecture

A Test Controller forms a third element.

The Test Controller receives requests to perform a test from one of the Test Endpoints, providing test
parameters prior to test initialization and receiving measurement results at the conclusion of the test. The Test
Controller will typically communicate with the same physical endpoint, even as the testing roles are reversed
in the course of testing both directions of a network path.

During a test, the Test Controller continually communicates with the Sender and the Receiver, to learn the
current measurement results from status messages and increase or decrease the test traffic sending rate. As
a result, it is essential to locate the Test Controller sufficiently near one of the Test Endpoints, to reduce the
delay in the feedback loop from status message generation to sending rate modification, and to allow more
accurate Round-Trip-Time (RTT) measurements.

The reference architecture shown in Figure 1 can be applied at any two nodes that can communicate with each
other across an IP-based network path. It can, for example, be applied at two devices within a home network
and controlled via USP [TR-369].

December 2021 © The Broadband Forum. All rights reserved 14 of 35

 Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Another example, in which a test platform located at the IP edge is used to measure the Maximum IP Capacity
between its location and the CPEs served by that access network, is shown in Figure 3 (partly adapted from
TR-304).

Figure 3: IP Edge to CPE measurement of Maximum IP Capacity

5.2 Measurement Procedure

Each measurement of Maximum IP Capacity occurs in a specific direction (for example, IP Edge to CPE)
across a network test path. A typical test process between two endpoints may include measuring the Maximum
IP Capacity in both directions; however, the measurement procedure in each direction is conducted
independently of the measurement procedure in the other direction. Multiple independent one-directional tests
MUST NOT be performed concurrently between the same endpoint pair.

Before the procedure begins, parameters needed to conduct the test are configured in both the Sender and
the Receiver. The test parameters are defined in Table 1.

Table 1: Measurement Variables, Ranges, and Default values

Name Parameter Unit Type; Write Default

Range value
Connection Category:
Interface The IP-layer interface NA string(256) W No Default
over which the test is to
be performed. Example:
Device.IP.Interface.1

If an empty string is
specified, the device
MUST use the interface
as directed by its routing
policy (Forwarding table
entries) to determine the
appropriate interface.
Role Configuration for the NA enumeration W No Default
measurement system’s [Receiver,
role in the method, Sender]
either Sender or
Receiver
Host Host name or address of string(256) No Default
the remote host to
perform tests to.
Port Port on the remote host unsignedInt- No Default
to perform tests to. [1:65535]

December 2021 © The Broadband Forum. All rights reserved 15 of 35

 Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

JumboFramesPermitted Configuration for the NA Boolean;[0:1] W 1(True:

measurement system permitted for
permitting use of sending rates
Jumbo-length Frames above
1Gbps) See
Note 3
NumberOfConnections (see Note 1) Number of parallel # unsignedInt; W 1 connection
connections in a test. 1 ≤ # ≤ 10, or
supported
Maximum if
less than 10
EthernetPriority Ethernet priority code for unsignedInt; W 0
marking packets [0:7]
transmitted in the test (if
applicable).
DSCP DSCP markings for unsignedInt; W 0 = Best
special treatment in the [0:63] Effort
network
ProtocolVersion Indicates the IP protocol string; W Any
version to be used. The
default value SHOULD
be Any. Enumeration of:

• Any (Use either

IPv4 or IPv6
depending on
the system
preference)
• IPv4 (Use IPv4
for the requests)
• IPv6 (Use IPv6
for the requests)
UDPPayloadRange Range of UDP Payload Bytes unsignedInt; W No default,
sizes, where 1 Byte = 8 [35:1472] Recommend
bits max at
Minimum largest value
35 byte, that avoids
Maximum at fragmentation
1472 bytes (i.e., using
(Max 8972 path MTU
with Jumbo discovery).
Frames, if
permitted.
Min for small
packets
added to
adjust rate,
method
unspecified.)
UDPPayloadContent UDP Payload Content NA string; W zeroes
Type, If there is payload
compression in the path
and tests intend to
characterize a possible
advantage due to

December 2021 © The Broadband Forum. All rights reserved 16 of 35

 Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

compression, then
payload content
SHOULD be supplied by
a pseudo-random
sequence generator, by
using part of a
compressed file, or by
other means. Payload
may also contain the
test protocol PDUs.

Enumeration of:
• ones,
• zeroes,
• alternates0and1
• random
PortRange REQUIRED range of # unsignedInt; W No default
ports supported for test The Dynamic
traffic and status Ports, also
feedback messages known as the
Private or
Ephemeral
Ports, from
49152-65535
(never
assigned by
IANA as per
RFC 6335)
PortRangeOptional OPTIONAL range of # unsignedInt; W No default.
ports supported for test The User Use of Port(s)
traffic and status Ports, also from the User
feedback messages known as the range and its
Registered impact on the
Ports, from network
1024-49151 needs to be
(assigned by carefully
IANA, RFC monitored by
6335) the testing
organization
before using
the ports in
testing, to
avoid
collision and
contention.
Test Category:
TestType Type of test, Search or enumeration; W Search
Fixed-Rate search or
fixed
EnableIPDV Configuration for the NA Boolean;[0:1] W 0 (False: Use
measurement system RTT= round-
permitting One-way trip delay
measurement of IPDV variation in
as per [Y.1540] the load rate

December 2021 © The Broadband Forum. All rights reserved 17 of 35

 Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

adjustment
algorithm)
(non-default
is 1=True
EnableIPDV
which uses
one-way
delay
variation for
the load rate
adjustment
algorithm)
EnableIPRR Configuration for the NA Boolean;[0:1] W 0 (False: not
measurement system enabled)
permitting measurement
of IPRR as per [Y.1540]
EnableRIPR Configuration for the NA Boolean;[0:1] W 0 (False: not
measurement system enabled)
permitting measurement
of RIPR as per [Y.1540]
PreambleDuration (see Note 2) Duration of active traffic seconds unsignedInt; W 2 seconds
preamble to testing. 0 ≤ seconds
≤5
StartSendingRate Initial value of Kbps, unsignedInt; W 500 Kbps
SendingRate where b=1 500 ≤ # ≤
bit 10,000,000
(10 Gbps)
Δt Duration of the test seconds unsignedInt; - Computed
(TestInterval) (either downlink or 5 ≤ seconds from m and
uplink) with search ≤ 60 dt,
algorithm in use, which Type;Range
serves as the maximum is a constraint
duration of the search on m * dt = Δt
process
m Number of intermediate # unsignedInt; W 10
(NumberTestSubIntervals) measurement intervals, 1 ≤ # ≤ 100
dt, in Δt
i Number of # unsignedInt; W Note: m is the
(NumberFirstModeTestSubIntervals) measurement intervals, 0≤#<m practical limit
dt, included in the report for a
of the initial Capacity consistent
mode (1 and higher). test, and 100
The remaining sub- is an absolute
intervals of the total m limit
are reported separately.
“0” is used to replace the
EnableBimodal
parameter, and means
the Bimodal analysis is
NOT enabled.
dt Duration of intermediate ms unsignedInt; W 1000 ms
(TestSubInterval) reporting intervals 100 ≤ ms ≤
6000 (max
Δt/(m=10)) in
milliseconds)

December 2021 © The Broadband Forum. All rights reserved 18 of 35

 Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

MUST meet
Type;Range
constraints
on
Δt = m * dt.
StatusFeedbackInterval Period of status ms 20 ≤ ms ≤ W 50 ms
feedback message 250
(Receiver of offered load
returns messages to the
sender with the results
of the measured
metrics)
TimeoutNoTestTraffic Timeout value, no test ms unsignedInt; W 1000ms
packets at Receiver 500 ≤ ms ≤ This value is
since previous test 1000 consistent
packet with a 10 sec
test duration.
TimeoutNoStatusMessage Timeout value, no ms unsignedInt; W 1000 ms
Status Messages at 500 Comment:
Sender since previous ≤ ms ≤1000 Take Sender
Status Message action to
reduce rate
before
stopping test.
This value is
consistent
with a 10 sec
test duration.
Tmax Maximum one-way ms unsignedInt; W 1000 ms
Waiting time for packets 50 ≤ ms ≤
to arrive 3000
TmaxRTT Maximum Round Trip ms unsignedInt; W 3000 ms
Waiting time for packets 50 ≤ ms ≤
to arrive 3000
TimestampResolution This is a function of the - See Table 2
measurement protocol, for
and it is usually information
determined once the on required
protocol chosen resolution
Note 1: For NumberOfConnections: Aggregate measurement results are for connections >1.
Note 2: For PreambleDuration: Traffic sent between sender and receiver at the StartingRate.
Note 3: For JumboFramesPermitted: The table of sending rates will change, depending on the option chosen.

In addition, the following should be included in External Model Definitions:

• Max number of supported connections (by a specific Test Endpoint).
• Interface specification: The IP-layer interface over which the test is to be performed.
• Max number of sub intervals (m)

During the measurement procedure, the Sender transmits a stream of test packets to the Receiver at a sending
rate that is periodically updated to find the maximum rate at which packets are delivered while meeting a set
of predefined performance requirements. The test interval Δt is subdivided into a number of sub-intervals dt,
and each sub-interval is further divided into a number of trial intervals. At the end of each trial interval, the
Receiver transmits a status message to the Sender with information used to update the sending rate.

December 2021 © The Broadband Forum. All rights reserved 19 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

The search algorithm that updates the sending rate can run on either the Sender or the Receiver. The endpoint
that runs the search algorithm for a specific test is referred to as the Test Controller. In addition to running the
search algorithm, the Test Controller calculates the Maximum IP Capacity as well as any secondary metrics
and makes the measurement results available at the test’s conclusion. At least one endpoint in a given test
needs to support the Test Controller functions.

[R-1] The test endpoint MUST support both Sender and Receiver functions.

[R-2] The test endpoint MUST support the test parameters listed in Table 1.

[R-3] At least one test endpoint MUST support Test Controller functions.

Each packet sent during the test includes a sending time stamp and sequence number. The Receiver uses the
time of reception for each packet along with its sending time stamp and sequence number to measure received
rate, packet loss, and one-way packet delay variation per Recommendation Y.1540. The Receiver then may
run an iteration of the search algorithm (if it is acting as the Test Controller) before sending a status feedback
message to the Sender. Depending on which endpoint is acting as the Test Controller:

• If the Receiver is acting as the Test Controller, it populates the status feedback message with the
updated sending rate generated by the search algorithm.

• If the Sender is acting as the Test Controller, the Receiver populates the status feedback message
with the received rate, packet loss, and one-way packet delay variation measurements calculated for
the most recent trial interval. The Sender then uses this information to run the search algorithm to
update its sending rate.

In addition to the above metrics, the Sender periodically measures round-trip delay using the following
procedure:

• When the Receiver has a status feedback message ready to send, it waits for the next test packet to
arrive from the Sender.

• When the test packet is received, the Receiver populates the status message with the sequence
number and sending time stamp of the test packet and immediately sends the status message to the
Sender.

• When the Sender receives the status message, it uses the sequence number and sending time stamp,
along with the received time of the status message to calculate the round trip delay. The calculated
round trip delay includes time to prepare the periodic status feedback message by the Receiver. An
implementation should strive to minimize that processing time or use other measurement methods to
evaluate round-trip delay.

[R-4] The Receiver MUST measure (using the sequence number and send and receive timestamps) the
following metrics during each trial interval: received rate and loss, specified as per Recommendation
Y.1540 [Y.1540].

[R-5] The Sender MUST measure sampled Round-trip time (RTT) as per RFC 2681 [RFC2681] or
Recommendation Y.1565 [Y.1565], based on periodic status feedback messages from the Receiver.

[R-6] The Receiver MAY measure (using the sequence number and send and receive timestamps) the
following metrics during each trial interval: 1-way packet delay variation, reordering, and duplication,
specified as per Recommendation Y.1540 [Y.1540] ], and/or the IETF RFC specifications tabulated
below.

Parameter values for metrics in R-4 through R-6 follow:

December 2021 © The Broadband Forum. All rights reserved 20 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Table 2: Parameters for Metrics and Supporting Test Protocols

Metric Parameter Description Unit Range Default value

IPLR (Loss Ratio) Tmax Maximum ms 50 ≤ ms ≤ 1000 ms
Y.1540, RFC Waiting time 3000
7680 for packets to
arrive
Sampled RTT TmaxRTT Maximum ms 50 ≤ ms ≤ 3000 ms
Y.1565, RFC Round Trip 3000
2681: RTT uses Waiting time
feedback status for packets to
messages from arrive
receiver TimestampResolution Resolution of ms 0.001 ≤ ms ≤ Suggested for fixed
(Determined when Timestamps 1 access: .001
test protocol is (based on current
chosen) implementation)
IPDV Tmax Maximum ms 50 ≤ ms ≤ 1000 ms
Y.1540, Waiting time 3000
RFC3393, for packets to
RFC5481 (PDV arrive
form is specified TimestampResolution Resolution of ms 0.001 ≤ ms ≤ Suggested for fixed
here) (Determined when Timestamps 1 access: .001
test protocol is (based on current
chosen) implementation)
IPRR Tmax Maximum ms 50 ≤ ms ≤ 1000 ms
Y.1540, RFC4737 Waiting time 3000
for packets to
arrive
TimestampResolution Resolution of ms 0.001 ≤ ms ≤ Suggested for fixed
(Determined when Timestamps 1 access: .001
test protocol is (based on current
chosen) implementation)
RIPR Tmax Maximum ms 50 ≤ ms ≤ 1000 ms
Y.1540, RFC5560 Waiting time 3000
for packets to
arrive
TimestampResolution Resolution of ms 0.001 ≤ ms ≤ Suggested for fixed
(Determined when Timestamps 1 access: .001
test protocol is (based on current
chosen) implementation)

If the Test Controller is acting as Sender:

[R-7] The Receiver MUST send a status feedback message to the Sender with the results of the
measured metrics at the end of each trial interval.

[R-8] The Sender MUST update its sending rate per the configured sending rate search algorithm
after receiving a status message.

[R-9] The Sending rate SHOULD be measured using the IP Packet Sending bit Rate (IPSBR) metric
defined in section 4.2.

If the Test Controller is acting as Receiver:

December 2021 © The Broadband Forum. All rights reserved 21 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

[R-10] The Receiver MUST update the Sender’s sending rate per the configured sending rate search
algorithm at the end of each trial interval.
[R-11] The Sending rate SHOULD be measured using the IP Packet Sending bit Rate (IPSBR) metric
defined in Annex A/Y.1540.

[R-12] The Receiver MUST send a status feedback message to the Sender with the updated sending
rate.

Two methods for updating the sending rate during a measurement are specified. The first method is the “Type
B” sending rate search algorithm specified in Section 5.2.1. The second method is a fixed sending rate that
does not change for the duration of the test. The fixed sending rate can be used to confirm the results of a
measurement using the search algorithm, for example using a sending rate set to a high percentage (e.g.,
99.x%) of the measured Maximum IP Capacity. Additional optional methods for determining the sending rate
can be supported in the Test Controller.

[R-13] The Test Controller MUST support the “Type B” sending rate search algorithm specified in Section
5.2.1.

[R-14] The Test Controller MUST support a configurable fixed sending rate.

[R-15] The Test Controller MAY support one or more additional sending rate search algorithms.

[R-16] The Test Controller MUST support selection of the sending rate search algorithm.

At the end of the test, the Test Controller generates the Maximum IP Capacity measurement result per the
metric definition in Equation 1. A minimal Test Controller can generate intermediate results after each trial
interval, updating the result each time a new maximum is found and discarding outdated values. Optionally,
the Test Controller can save all intermediate trial results, including IP Capacity as well as packet latency, loss
and reordering, for post-measurement analysis. Additional results that can be made available by the Test
Controller include:

The Maximum IP Capacity includes all bits in the IP header and extension header fields, the IP payload, which
is the UDP header and payload fields. The capacity available to the layers above UDP, which includes the
UDP payload but not the UDP header fields, is an additional useful metric that can be calculated from the
measurement results and test parameters.

Additional calculations are possible within this measurement framework:

• Calculating an average of all measured values (for IP-Layer Capacity) for all Trials in a sub-interval,
dtn, and for the complete measurement interval [t, t + Δt].
• Calculating an average of all measured values (for IP-Layer Capacity) for all Trials in a sub-interval,
dtn, and for all sub intervals in the complete measurement interval [t, t + Δt] where the search goal was
met.
• Calculating a maximum of all measured values of (for IP-Layer Capacity) for all Trials in a sub-interval,
dtn, and for all sub intervals in the complete measurement interval [t, t + Δt] where the search goal was
met.
• Calculating an average of all measured values of (for IP-Layer Capacity) for all Trials in a sub-interval,
dtn, and for the complete measurement interval [t, t + Δt] for all Trials, where a specified result exclusion
criteria has been met (e.g., removal of outliers, as determined by specified criteria).

[R-17] The Test Controller MUST calculate the Maximum IP Capacity measurement result according to
Equation 1.

[R-18] The Test Controller MUST report the Maximum IP Capacity and the IP packet loss ratio corresponding
to the sub-interval dtn in which the Maximum IP Capacity was measured according to Equation 1.

December 2021 © The Broadband Forum. All rights reserved 22 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

[R-19] The Test Controller MUST identify the sending rate search algorithm and parameters used when
reporting Maximum IP Capacity measurement results.

[R-20] The Test Controller MAY include one or more secondary measurement results as listed above when
reporting Maximum IP Capacity measurement results.

[R-21] The Test Controller MAY report the UDP Capacity corresponding to the Maximum IP-Layer Capacity
in terms of UDP payload bits delivered.

When post-measurement analysis is performed, for example to analyze the consistency of test results, the
process to summarize the results should include corresponding post-test analysis to ensure data quality and
to detect and exclude data artifacts (where possible). The post-test analysis methods should be published
with the analysis results.

Some conditions may temporarily prevent the generation of a valid Maximum IP Capacity result. Senders and
Receivers should support mechanisms to detect such conditions where possible and to prevent the generation
of invalid results. Specific conditions, and the mechanisms for detecting them, may be node-specific. For
example, a network-located test platform may need to check for host resource availability before accepting a
test command, while it may be more important for a residential gateway to check for user traffic on the
broadband connection before conducting a test.

5.2.1 Sending Rate Search Algorithm

The “Type B” sending rate search algorithm specified below makes use of a table of sender bit rates listed in
order of ascending rate from the minimum to the maximum rate supported by the test. Depending on the
Sender implementation, each bit rate may correspond to a number of packets of specified sizes sent during a
specified time interval (which may correspond to the timer granularity supported by the Sender).

An iteration of the Type B search algorithm is shown in the flowchart in Figure 4. In that flowchart, one step
represents a single row increment or decrement in the sending rates table (see Annex A). The flowchart uses
many variable names and in some cases, configurable thresholds that determine the flowchart decisions.
There are three main paths through the flowchart based on the following conditions:

• Feedback indicates measured impairments are absent,

• Impairments are first measured and some congestion may be present but sending rate change is
deferred,
• Measured impairments are confirmed by repeated measurement feedback.

December 2021 © The Broadband Forum. All rights reserved 23 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Figure 4: Flowchart for Offered Load adjustment as part of the “B” Search Algorithm

The variables and thresholds used in Figure 2 are explained in Table 3:

Table 3: Flowchart Variables, Descriptions, Ranges, and Default values

Name Description Unit Range Write Default value

SendingRate The current Kbps,where unsignedInt; - StartSendingRate
sending rate b=1 bit 500 ≤ # ≤
(equivalent to a 10,000,000
row of the table), (10 Gbps)
Initialized at
minimum Sending
Rate in the Table
of Sending Rates
SeqErrors Measured Count number unsignedInt; - NA
of any of Loss or 0 ≤ SeqErrors
Reordering or
Replication
impairments
(events where
received packet
sequence number
did not increase
by one)
SeqErrThresh Threshold for number unsignedInt; W 10
Loss or 0 ≤
Reordering or SeqErrThresh
Replication ≤ 100
impairments
measured (events
where received
packet sequence

December 2021 © The Broadband Forum. All rights reserved 24 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

number did not

increase by one)
ReordDupIgnoreEnable When True NA Boolean;[0:1] W 0 (False: not
(enabled) only enabled)
Loss counts
toward received
packet sequence
number errors,
and Reordering
and Duplication
impairments are
ignored.
When False,
Loss, Reordering
and Duplication
are all counted as
sequence number
errors. )
DelayVar Measured Range ms NA - NA
of Round Trip
Time, RTT (or 1-
way Packet Delay
Variation, above
minimum delay
when DelayVar 1-
way
measurements
are reliable)
LowThresh Low threshold on ms unsignedInt; W 30ms default
the Range of 5 ≤ ms ≤ 250
Round Trip Time
variation, RTT
(Range is values
above minimum
RTT)
UpperThresh High threshold on ms unsignedInt; W 90ms default
the Range of 5 ≤ ms ≤ 250
Round Trip Time
variation, RTT
(Range is values
above minimum
RTT)
HighSpeedDelta The number of number of unsignedInt; W 10 table rows (10
rows to move in a rows ≥2 Mbps currently)
single adjustment
when initially
increasing offered
load (to ramp-up
quickly)
SlowAdjCount Measured Count of NA - See
Number of occurrences SlowAdjThresh
consecutive
status reports
indicating loss
and/or delay

December 2021 © The Broadband Forum. All rights reserved 25 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

variation above
UpperThreshold.
SlowAdjThresh Threshold on Count of unsignedInt; W 3
SlowAdjCount occurrences >1
used to infer
congestion. Use
values >1 to avoid
misinterpreting
transient loss.
HSpeedThresh Threshold for Gbps, unsignedInt; W 1 Gbps
transition where b=1 ≥1
between low and bit
high sending rate
step sizes (such
as 1 Mbps and
100 Mbps). MAY
result in use of
Jumbo Frames if
permitted.

The writable parameters above will be used in any data model for configuring IP Capacity testing. Measured
output will not be included in reports from the data models (instead they will be included as part of test protocols
that support the status message communications).

5.2.2 Lost Status Backoff Timeout and Interaction with the “B” Search
Algorithm
A safety control related to the “B” search algorithm is the reduction of sending rate when no feedback is
received at the Sender for a time interval called the Lost Status Backoff Timeout.

Calculation of the timeout includes two existing parameters, UpperThresh and StatusFeedbackInterval, plus a
variable w that increments on each timeout to further reduce the rate when successive feedback messages
are lost.

December 2021 © The Broadband Forum. All rights reserved 26 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Figure 5: Flowchart for Lost Status Backoff Timeout Interaction with the “B” Search Algorithm

[R-22] If the Type “B” Search Algorithm is used, then the Test Controller MUST update appropriate algorithm
parameters and reduce the sending rate as directed when the Sender indicates that the Lost Status
Backoff Timeout has expired. The Lost Status Backoff Timeout SHALL be calculated as specified in
Figure 5. The rate reduction SHALL be as determined by the flowchart in Figure 5. The
RECOMMENDED initial value for variable w is 0.

December 2021 © The Broadband Forum. All rights reserved 27 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

6 Results
This section specifies details for the Results of measurements using the Maximum IP-Layer Capacity metric.

The primary output parameter is a Summary Statistic (Maximum of individual IP-layer Capacities), calculated
at the conclusion of the test.

There are iterations of results that are reported on a per sub-interval basis, and the results associated with the
Maximum Capacity measurement, all reported together at the end of the test.

Table 4: Data Model Definition for Results

Name Description Unit Type Wr Notes

ite
BeginningOfMeasurement t, the start of a measurement interval, dateTime -
in UTC, which MUST be specified to
TimestampResolution precision (Table
2)

For example: 2008-04-

09T15:01:05.123456Z
EndOfMeasurement t+ Δt , the end of a measurement dateTime -
interval, in UTC, which MUST be
specified to TimestampResolution
precision (Table 2)

For example: 2008-04-

09T15:01:05.123456Z
TmaxUsed Configured value of Tmax used in the ms unsignedInt; -
test 50 ≤ ms ≤
3000
TmaxRTTUsed Configured value of TmaxRTT used in ms unsignedInt; -
the test 50 ≤ ms ≤
3000
TestInterval Measured Duration of the test (either seconds (output) -
downlink or uplink). This value is
expected to equal dt * m
MaximumIP-LayerCapacity Results of measurements using the Mbps decimal64 -
Maximum IP-Layer Capacity metric, number with
see Equation 1 fraction digits
= 2, as
specified in
[Section 9.3 of
RFC7950].

TimeOfMaximumIP- End Time of the dtn to dtn+1 sub-interval dateTime - Note:

LayerCapacity when the Maximum IP-Layer Capacity millisecond
was measured, in UTC, which MUST resolution
be specified to TimestampResolution would be
precision (Table 2). In case of Max sufficient!
Capacity occurring in multiple sub-
intervals, report the Time of the earliest
sub-interval.
MaxETHCapacityNoFCS Results of measurements using the Mbps decimal64 -
Maximum IP-Layer Capacity metric, number with
see Equation 1, and calculations to fraction digits
estimate the capacity at Layer 2 with = 2, as
Preamble and Inter-frame gap, but no specified in
ETH Frame Check Sequence [Section 9.3 of
RFC7950].

MaxETHCapacityWithFCS Results of measurements using the Mbps decimal64 -

Maximum IP-Layer Capacity metric, number with
see Equation 1, and calculations to fraction digits
estimate the capacity at Layer 2 with = 2, as
ETH Frame Check Sequence specified in

December 2021 © The Broadband Forum. All rights reserved 28 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

[Section 9.3 of
RFC7950].

MaxETHCapacityWithFCSVLAN Results of measurements using the Mbps decimal64 -

Maximum IP-Layer Capacity metric, number with
see Equation 1, and calculations to fraction digits
estimate the capacity at Layer 2 with = 2, as
ETH Frame Check Sequence and 1 specified in
VLAN tag [Section 9.3 of
RFC7950].

LossRatioAtMaxCapacity Ratio of lost to total packets sent during decimal64 -

dtn corresponding to the Max IP-Layer with fraction
Capacity above), determined at the digits = 9 (see
conclusion of the test. section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
RTTRangeAtMaxCapacity The Range of RTT during the dtn seconds decimal64 -
corresponding to the Max IP-Layer with fraction
Capacity above, determined at the digits = 9 (see
conclusion of the test. The Range of section 9.3 of
RTT shall be calculated using the [RFC7950])
conditional distribution of all packets with resolution
with a finite value of round-trip delay of
(undefined delays are excluded), a 0.000000001
single value as follows: seconds (1.0
ns).
• See section 4.1 of
[RFC3393] for details on the
conditional distribution to
exclude undefined values of
delay, and Section 5 of
[RFC6703] for background
on this analysis choice.

• The time value of the result is

expressed in units of
seconds, as a positive value
PDVRangeAtMaxCapacity The Range of PDV during the dtn seconds decimal64 - Note: PDV is
corresponding to the Max IP-Layer with fraction the metric
Capacity above, determined at the digits = 9 (see defined in
conclusion of the test. The Range of section 9.3 of Y.1540 and
PDV shall be calculated using the [RFC7950]) RFC5481, not
conditional distribution of all packets with resolution inter-packet
with a finite value of one-way delay of delay
(undefined delays are excluded, as 0.000000001 variation.
described for other delay seconds (1.0 Y.1540 and
measurements). ns). RFC5481
prefer a
calculation of a
high (99.9)
percentile,
rather than
Max, and the
percentile
should be
reported
where
possible.
MinOnewayDelayAtMaxCapacity The Minimum One-way Delay during seconds decimal64 - Note: The
the dtn corresponding to the Max IP- with fraction Minimum One-
Layer Capacity above, The Minimum digits = 9 (see way Delay is
One-way Delay is determined at the section 9.3 of needed to
conclusion of the test. The Minimum [RFC7950]) calculate the
One-way Delay shall be calculated with resolution Y.1540 and
using the conditional distribution of all of RFC5481
packets with a finite value of one-way 0.000000001 PDV, and

December 2021 © The Broadband Forum. All rights reserved 29 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

delay (undefined delays are excluded, seconds (1.0 should be

as described for other delay ns). reported
measurements). separately.
ReorderedRatioAtMaxCapacity Ratio of Reordered to total packets sent decimal64 -
during dtn corresponding to the Max IP- with fraction
Layer Capacity above), determined at digits = 9 (see
the conclusion of the test. section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
ReplicatedRatioAtMaxCapacity Ratio of Replicated to total packets sent decimal64
during dtn corresponding to the Max IP- with fraction
Layer Capacity above), determined at digits = 9 (see
the conclusion of the test. section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
IP-LayerCapacitySummary Results of measurements using the IP- Mbps decimal64 -
Layer Capacity metric over the number with
complete TestInterval, dt * m, see fraction digits
Equation 1 = 2, as
specified in
[Section 9.3 of
RFC7950].

LossRatioSummary Ratio of lost to total packets sent during decimal64 -

the complete TestInterval, dt * m, with fraction
determined at the conclusion of the digits = 9 (see
test. section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
RTTRangeSummary The Range of RTT during the complete seconds decimal64 -
TestInterval, dt * m, determined at the with fraction
conclusion of the test. The Range of digits = 9 (see
RTT shall be calculated using the section 9.3 of
conditional distribution of all packets [RFC7950])
with a finite value of round-trip delay with resolution
(undefined delays are excluded), a of
single value as follows: 0.000000001
seconds (1.0
• See section 4.1 of ns).
[RFC3393] for details on the
conditional distribution to
exclude undefined values of
delay, and Section 5 of
[RFC6703] for background
on this analysis choice.

• The time value of the result is

expressed in units of
seconds, as a positive value
PDVRangeSummary The Range of PDV during the complete seconds decimal64 - Note: PDV is
TestInterval, dt * m, determined at the with fraction the metric
conclusion of the test. The Range of digits = 9 (see defined in
PDV shall be calculated using the section 9.3 of Y.1540 and
conditional distribution of all packets [RFC7950]) RFC5481, not
with a finite value of one-way delay with resolution inter-packet
(undefined delays are excluded, as of delay
described for other delay 0.000000001 variation.
measurements). seconds (1.0 Y.1540 and
ns). RFC5481
prefer a
calculation of a
high (99.9)
percentile,

December 2021 © The Broadband Forum. All rights reserved 30 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

rather than
Max, and the
percentile
should be
reported
where
possible.
MinOnewayDelaySummary The Minimum One-way Delay during seconds decimal64 - Note: The
the complete TestInterval, dt * m, The with fraction Minimum One-
Minimum One-way Delay is determined digits = 9 (see way Delay is
at the conclusion of the test. The section 9.3 of needed to
Minimum One-way Delay shall be [RFC7950]) calculate the
calculated using the conditional with resolution Y.1540 and
distribution of all packets with a finite of RFC5481
value of one-way delay (undefined 0.000000001 PDV, and
delays are excluded, as described for seconds (1.0 should be
other delay measurements). ns). reported
separately.
MinRTTSummary The Minimum RTT during the complete seconds decimal64 -
TestInterval, dt * m, The Minimum RTT with fraction
is determined at the conclusion of the digits = 9 (see
test. The Minimum RTT shall be section 9.3 of
calculated using the conditional [RFC7950])
distribution of all packets with a finite with resolution
value of RTT (undefined delays are of
excluded, as described for other delay 0.000000001
measurements). seconds (1.0
ns).
ReorderedRatioSummary Ratio of Reordered to total packets sent decimal64 -
during the complete TestInterval, dt * with fraction
m, determined at the conclusion of the digits = 9 (see
test. section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
ReplicatedRatioSummary Ratio of Replicated to total packets sent decimal64
during the complete TestInterval, dt * with fraction
m, determined at the conclusion of the digits = 9 (see
test. section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
TimestampResolutionUsed This is a function of the measurement microsec unsignedInt -
protocol, and it is usually determined
once the protocol chosen.
Value specified in microseconds.
ModalResult.{i}. Modal test results. Only returned when
bimodal test mode is enabled
(NumberFirstModeTestSubIntervals
>=1). If returned, it MUST contain 1 or
more entries, with instance number 1
corresponding to the second mode and
instance number 2 corresponding to
the third mode.

Results for the Maximum in each

mode/instance are calculated based on
IncrementalResult.{i}. data within the
boundary of its corresponding mode.

This table's Instance Numbers MUST

be 1, 2, 3... (assigned sequentially
without gaps).

IncrementalResult.{i}.
(Incremental Results for all sub-
intervals are described below)

December 2021 © The Broadband Forum. All rights reserved 31 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

IP-LayerCapacitySubInterval Results of measurements using the IP- Mbps decimal64 -

Layer Capacity metric for a single number with
interval dtn to dtn+1 , see Equation 1, fraction digits
where the Capacity is the number of = 2, as
bits received in the subinterval divided specified in
by the duration, dt. [Section 9.3 of
RFC7950].

TimeOfIP- End Time of the dtn to dtn+1 sub-interval dateTime - Note:

LayerCapacitySubInterval when each of the m IP-Layer Capacity millisecond
was measured, in UTC, which MUST resolution
be specified to TimestampResolution would be
precision(Table 2) sufficient!
LossRatioSubInterval Ratio of lost to total packets sent during decimal64 -
dtn to dtn+1 corresponding to each IP- with fraction
LayerCapacitySubInterval above). digits = 9 (see
section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
RTTRangeSubInterval The Range of RTT during dtn seconds decimal64 -
corresponding to packets sent during with fraction
dtn to dtn+1 corresponding to each IP- digits = 9 (see
LayerCapacitySubInterval above). The section 9.3 of
Range of RTT shall be calculated using [RFC7950])
the conditional distribution of all with resolution
packets with a finite value of round-trip of
delay (undefined delays are excluded), 0.000000001
a single value as follows: seconds (1.0
ns).
• See section 4.1 of
[RFC3393] for details on the
conditional distribution to
exclude undefined values of
delay, and Section 5 of
[RFC6703] for background
on this analysis choice.

• The time value of the result is

expressed in units of
seconds, as a positive value

PDVRangeSubInterval The Range of PDV during dtn seconds decimal64 - Note: PDV is
corresponding to packets sent during with fraction the metric
dtn to dtn+1 corresponding to each IP- digits = 9 (see defined in
LayerCapacitySubInterval above. The section 9.3 of Y.1540 and
Range of PDV shall be calculated using [RFC7950]) RFC5481, not
the conditional distribution of all with resolution inter-packet
packets with a finite value of one-way of delay
delay (undefined delays are excluded, 0.000000001 variation.
as described for other delay seconds (1.0 Y.1540 and
measurements). ns). RFC5481
prefer a
calculation of a
high (99.9)
percentile,
rather than
Max, and the
percentile
should be
reported
where
possible.
MinOnewayDelaySubInterval The Minimum One-way Delay during seconds decimal64 - Note: The
dtn corresponding to packets sent with fraction Minimum One-
during dtn to dtn+1 corresponding to each digits = 9 (see way Delay is
IP-LayerCapacitySubInterval above. section 9.3 of needed to
The Minimum One-way Delay is [RFC7950]) calculate the

December 2021 © The Broadband Forum. All rights reserved 32 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

determined at the conclusion of the with resolution Y.1540 and

test. The Minimum One-way Delay of RFC5481
shall be calculated using the 0.000000001 PDV, and
conditional distribution of all packets seconds (1.0 should be
with a finite value of one-way delay ns). reported
(undefined delays are excluded, as separately.
described for other delay
measurements).
ReorderedRatioSubInterval Ratio of Reordered to total packets sent decimal64
during dtn to dtn+1 corresponding to with fraction
each IP-LayerCapacitySubInterval digits = 9 (see
above). section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
ReplicatedRatioSubInterval Ratio of Replicated to total packets sent decimal64
during dtn to dtn+1 corresponding to with fraction
each IP-LayerCapacitySubInterval digits = 9 (see
above). section 9.3 of
[RFC6020])
with resolution
of
0.0000000001
The measurement variable, i, NumberFirstModeTestSubIntervals >= 1 (enabling Bimodal reporting) requires
that Maximum results are reported separately for two time intervals:

1. Sub-intervals from 1 to i
2. Sub-intervals from i + 1 to m

The ModalResult.{i} is the section of the data model above where the Second Mode Maximum results (and
any additional modes in the future) will be found.

[R-23] When the Client application operates at the CPE in Figure 3, and conducts measurements using an
interface that views all traffic during a test (not just test traffic), then the metrics defined in Table 5
MAY help to determine when non-test/subscriber traffic was present during a test. These calculations
are based on the interface counts (such as TotalBytesReceived) described in TR-143 [3].

Table 5: Additional Metrics for Diagnostic Measurement

Name Description Unit Type Wri Notes

te
IncrementalResult.{i}.

InterfaceEthMbpsSubInterval The number of bits Mbps decimal64 -

observed on the Interface number
during an IP-Layer Capacity with fraction
test for a single sub-interval digits = 2,
dtn to dtn+1 , divided by the as specified
duration, dt, and expressed in [Section
in Mbps. Measurement 9.3 of
direction follows the Role RFC7950].
(Sender or Receiver).
“AtMaxCapacity” and
ModalResult.{i}
InterfaceEthMbpsAtMaxCapacity The number of bits Mbps decimal64 -
observed on the Interface number

December 2021 © The Broadband Forum. All rights reserved 33 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

during an IP-Layer Capacity with fraction

test for a single sub-interval digits = 2,
dtn to dtn+1 corresponding to as specified
the Max IP-Layer Capacity, in [Section
divided by the duration, dt, 9.3 of
and expressed in Mbps. RFC7950].
Measurement direction
follows the Role (Sender or
Receiver).
“Summary”
InterfaceEthMbpsSummary The number of bits Mbps decimal64 -
observed on the Interface number
during an IP-Layer Capacity with fraction
test for the entire digits = 2,
TestInterval Δt, divided by as specified
the duration, Δt, and in [Section
expressed in Mbps. 9.3 of
Measurement direction RFC7950].
follows the Role (Sender or
Receiver).

Note that the CPE operating system and hardware implementation will likely determine the layer where these
bit counts can be observed as byte counts.

Table 6 provides additional information on the version of software and control protocol running on the
configured Endpoint.

[R-24] When the Client application operates at the CPE in Figure 3, then the information defined in Table 6
MAY be communicated with the results to confirm the versions used during a test.

Table 6: Supporting Information for Test Context

Name Description Unit Type Wri Notes

te
IPLayerCapSupportedSoftwareV Indicates the installed string; - Currently
ersion version of the test software. at version
The software version string “UDPST-
will be implementation- 7.3.0” for
dependent, and SHOULD udpst. This
identify both the would be a
implementation and the single
version (e.g., UDPST- string for
7.2.1). client.
IPLayerCapSupportedControlPro Indicates the control string; - Currently
tocolVersion protocol version supported at version
by the test software. 8 for
udpst. This
would be a
single
string for
client.

December 2021 © The Broadband Forum. All rights reserved 34 of 35

Maximum IP-Layer Capacity Metric, Related Metrics, and Measurements TR-471 Issue 2

Annex A: Sending Rates Table

This Annex provides information on the Sending Rates Table.

A.1 Example Table of Sending Rates and Related Information

When describing the system that conforms to this specification, the text in section 5.2.1 describes a table of
sending rates. This is a pre-defined table of transmit rates, which are the number of packets sent during each
time interval (corresponding to bits per second and a specified protocol layer) and packet sizes. The table has
ascending values for offered load rates, between the minimum and maximum supported sending rates,
inclusive. The rows in the table have an index number for simple reference to the flow-chart calculations of the
number of rows to move in steps.

The example Table A.1 below begins with the configured Initial Rate, and contains a representation of one
table that has been used (with reduced detail). Note that this table results from computation of simple bit rates
(in Mbps at Layer 3 or IP Layer) from packet counts, as this was considered efficient.

Table A.1: Example Table of Sending Rates

Index Other Components, such as sending interval, payload size(s), spacing

Mbps (L3/IP)
No. parameters, back-to-back (burst) packet counts, etc.
0 0.50
1 1.00
2 2.00
3 3.00
4 4.00
… …
997 997.00
998 998.00
999 999.00
1000 1000.00
… …

End of Broadband Forum Technical Report TR-471

December 2021 © The Broadband Forum. All rights reserved 35 of 35