Telecommunications Industry
Association
(TIA)
Austin, TX
TR-30.3/10-12-027
December 6-8, 2010
DOCUMENT SUBMITTED TO
TR-30.3 Meeting
The document to which this cover statement is attached is submitted to a Formulating Group or subelement thereof of the Telecommunications Industry Association (TIA) in accordance with the provisions
of Sections 6.4.1-6.4.6 inclusive of the TIA Engineering Manual dated October 2009, all of which
provisions are hereby incorporated by reference.
SOURCE:
Editor, TIA-921-B
CONTACT:
Ed Schulz
LSI Corporation
1110 American Pkwy NE
Allentown, PA 18109
610-712-2068
Ed.Schulz@lsi.com
TITLE:
Proposed Outline and New Text for TIA-921-B
PROJECT:
PN-3-0062-RV2
DISTRIBUTION:
Members of TR-30.3
INTENDED PURPOSE OF
DOCUMENT:
_X_
FOR INCORPORATION INTO A TIA PUBLICATION
____ FOR INFORMATION ONLY
____ OTHER (please describe):
____________________
ABSTRACT
Rather than edit the draft TIA-921-B standard in place, it might be easier to review each
proposed section on its own, or held beside the original document. The proposed outline and
text are suggested by the existing TIA-921-A, and by presentations and discussions in TR-30.3
over the past few years. This text has been edited heavily during the August, 2010 and
September, 2010 meetings.
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
Table of Contents
Foreword .................................................................................................................................. 4
Introduction .............................................................................................................................. 5
Network Model for Evaluating Multimedia Transmission Performance Over Internet
Protocol .................................................................................................................................... 1
1
Scope ................................................................................................................................. 1
2
Informative References .................................................................................................... 2
3
Definitions and Abbreviations ......................................................................................... 3
3.1
Definitions .................................................................................................................... 3
3.2
4
5
Abbreviations ............................................................................................................... 3
Description of the Model .................................................................................................. 4
4.1
Model Overview ........................................................................................................... 4
4.2
Network Topology ........................................................................................................ 5
4.3
Models of Network Elements ....................................................................................... 5
4.4
Interfering Stream Files ................................................................................................ 6
4.5
Simulation Inputs ......................................................................................................... 8
4.6
Simulation Outputs......................................................................................................10
4.7
Packet Scheduling Algorithm ......................................................................................11
IP Network Impairment Level Requirements ..................................................................12
5.1
Service Test Profiles ...................................................................................................12
5.2
Impairment Combination Standard Test Cases ...........................................................13
Annex A
(Normative) – Description of Discrete Event Simulator ............................... 0
Annex B
(Normative) – C++ Source Code of Discrete Event Simulator ...................... 5
Annex C
(Normative) – Packet Capture Files of Interfering Traffic ............................. 5
Annex D
(Normative) – Simulator Output ..................................................................... 5
Annex E
(Informative) – Rationale for Network Model ................................................. 5
ii
PN-3-0062-RV2 (to become TIA-921-B)
Annex F
TR-30.3/10-12-027
(Informative) – User’s Guide ........................................................................... 5
F.1
Emulator Implementation ............................................................................................. 5
F.2
Practical Use of Test Cases ......................................................................................... 5
iii
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
Foreword
(This foreword is not part of this Standard.)
ANSI-accredited committee TR-30.3 has developed this TIA-921-B Standard, which defines an
IP network model. This model, along with the specified scenarios, are intended for evaluating
and comparing communications equipment connected over a converged network.
Building upon the experience of creating network nodels, TR-30.3 Subcommittee has created
this Network Model for IP Impairments using the similar methodology developed in its previous
standards and bulletins:
EIA/TIA-496-A-1989: Interface Between Data Circuit Terminating Equipment (DCE) and the
Public Switched Telephone Network, which includes a Network Model for Evaluating Modem
Performance
TIA TSB-37-A-1994: Telephone Network Transmission Model for Evaluating Analog Modem
Performance, which became ITU-T Recommendation V.56bis-1995
TIA TSB-38-1994 (and TSB-38-A -2007): Test Procedures for Evaluation of 2-Wire 4
Kilohertz Voice Band Duplex Modems, which became ITU-T Recommendation V.56ter1996
ANSI/TIA/EIA-3700-1999: Telephone Network Transmission Model for Evaluating Analog
Modem Performance
ANSI/TIA/EIA-793-2001: North American Telephone Network Transmission Model for
Evaluating Analog Client and Digitally Connected Server Modems
ANSI/TIA-876-2002: North American Network Access Transmission Model for Evaluating
xDSL Modem Performance
TIA-921-B was approved on [insert date]. It cancels and replaces TIA-921-A (2008) in its
entirety. Technical changes from TIA-921-A include:
TIA-921-B models the mechanisms that contribute to packet delay, jitter, and loss:
interfering streams, queueing delays in network elements, and the characteristics of specific
access technologies. The intent is to provide more realism than the earlier version. TIA921-A defined a mathematical model that fit certain observed network behavior, but was not
easily extended to other scenarios.
The “likelihood of occurrence” concept is no longer applied to IP networks.
TIA-921-B is a true bidrectional model.
Impairment levels are updated to keep current with evolving IP networks.
The number of standard test cases is greatly reduced.
Users can customize test cases to fit their specific needs.
There are 6 Annexes in this Standard. Annexes A, B, C, and D are normative and are
considered part of this Standard. Normative Annexes B, C, and D include electronic
attachments. Annexes E and F are informative and are not considered part of this Standard.
iv
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
Introduction
TIA-921-B describes a model of Internet Protocol (IP) networks for the purpose of evaluating the
performance of IP streams. The focus is on packet delay, delay variation, and loss. IP streams
from any type of network device can be evaluated using this model.
Emphasis is given to the fact that manufacturers of communications equipment and service
providers are interested in a specification that accurately models the IP network characteristics
that determine performance. Evaluators desire a definitive set of simple tests that properly
measure the performance of communications devices from various manufacturers. Therefore,
the objective of this standard is to define an application-independent model (e.g. data, voice,
voiceband data, and video) that is representative of IP networks, that can be simulated at
reasonable complexity, and that facilitates practical evaluation times. The IP network model
presented herein represents a snapshot of actual network data provided by anonymous IP
service providers and IP network equipment manufacturers in the 2010 timeframe, and will
continue to evolve as more statistical information becomes available and as the IP network
evolves.
v
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
Network Model for Evaluating Multimedia Transmission
Performance Over Internet Protocol
1 Scope
This Standard is broadly applicable to the evaluation of any equipment that terminates or routes
traffic using Internet Protocol. This Standard can also be used to evaluate media streams or
other protocols carried over IP networks. Examples of the types of equipment that can be
evaluated using this model include:
 IP-connected endpoints:
o IP network devices (such as: user agents, call agents, media servers, media
gateways, application servers, routers, switches, etc.)
o IP video (IPTV, video conferencing, telepresence, etc.)
o IP phones (including soft phones)
o IAF (Internet Aware Fax)
 PSTN-connected devices through IP gateways:
o POTS through Voice-over-IP (VoIP) gateways
o T.38 facsimile devices and gateways
o V.150.1 and V.152 (voiceband data, VBD) modem-over-IP gateways
o TIA-1001 and V.151 textphone-over-IP gateways
The IP network model can be used in two ways:
 Test an IP stream under simulated network conditions
 Test an IP stream in real time using hardware emulation of the network model.
The IP network model can be used to study and to understand:
 the interaction of different traffic mixes
 the effects of QoS and queuing on different types of traffic
 packet delay variation and packet loss.
Whether in software simulation or real-time hardware emulation, users can select from several
test cases specified in this Standard. Users can optionally define their own test cases.
This model has the following limitations:
 Some VoIP networks may utilize PSTN at one or both ends of the connection through a
media gateway. This model only addresses the IP portion of the network and does not
address the PSTN portion of the end-to-end connection.
 The network model represented in this Standard does not model all possible
connections that can be encountered between devices.
 This Standard only specifically includes GPON and DSL access technologies.
Characteristics of other access technologies such as CATV and wireless are for further
study.
 Abnormal events such as link failures and route flaps (and the packet reordering that
such events can cause) are not included in this Standard.
 The standard test cases use streams of interfering traffic that were captured on live
networks. While realistic, they are still just examples; users could substitute their own
files of interfering traffic.
1
PN-3-0062-RV2 (to become TIA-921-B)


TR-30.3/10-12-027
The LAN-to-LAN test cases of TIA-921-A are now modeled as two cascaded TIA-921-B
core-to-LAN segments. [See Annex]
The IP network model presented herein is based on an informal survey of anonymous IP
service providers and IP network equipment manufacturers in the 2010 timeframe and
will continue to evolve as more statistical information becomes available and as the IP
network evolves.
2 Informative References
At the time of publication, the editions indicated were valid. All standards and bulletins are
subject to revision, and parties to agreements based on this Standard are encouraged to
investigate the possibility of applying the most recent editions of the standards published by
them.
ETSI TIPHON TR 101 329 - Part 2, Quality of Service (QoS) Classes
IEEE 802.11A-1999, Information Technology Telecommunications and Information Exchange
Between Systems – LAN/MAN
IEEE 802.11B/COR 1-2001, Wireless LAN MAC and PHY Specifications Amendment 2: Higher
Speed Physical Layer Extension In The 2.4GHz Band
IEEE 802.11G-2003, Wireless LAN MAC and PHY Specifications Amendment 4: Further High
Data Rate Extension In The 2.4GHz Band
ITU-T Recommendation G.1050 (2007), Network Model for Evaluating Multimedia Transmission
Performance Over Internet Protocol
ITU-T Recommendation G.107 (2009), The E-model, a computational model for use in
transmission planning
ITU-T Recommendation G.108 (1999), Application of the E-model: A planning guide
ITU-T Recommendation G.114 (2003), One way transmission time
ITU-T Recommandation T.38 (2007), Procedures for real-time Group 3 facsimile communication
over IP networks
ITU-T Recommendation V.150.0 (2003), Modem-over-IP Networks: Foundation
ITU-T Recommendation V.150.1 (2003), Procedures for the end-to-end connection of V-series
DCEs over an IP Network
ITU-T Recommendation V.152 (2005), Procedures for supporting Voice-Band Data over IP
Networks
ITU-T Recommendation Y.1541 (2006), Network performance objectives for IP-Based services
ANSI/TIA-810-B-2006, Telecommunications – Telephone Terminal Equipment – Transmission
Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones
TIA-1001 (2004), Transport of TIA-825-A Signals over IP Networks
2
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
TIA TSB116-A-2006, Telecommunications – IP Telephony Equipment – Voice Quality
Recommendations for IP Telephony
ANSI/TIA-912-A-2004, Telecommunications – IP Telephony Equipment – Voice Gateway
Transmission Requirements
3 Definitions and Abbreviations
3.1 Definitions
For the purposes of this standard, the following definitions shall apply.
burst loss – a high density of packet loss over time, or loss of sequential packets, due to
congestion, bandwidth limitation, line errors, or rerouting (delay translated into loss due to
implementation) on the network.
delay – the time required for a packet to traverse the network or a segment of the network. See
latency.
downstream – a transmission from a service provider toward an end user.
end-to-end network – pertaining to an entire path from one endpoint to another. Metrics may
refer to a single segment (example: core delay) or to the entire path (example: end-to-end
network delay).
gateway – a network device that acts as an entrance to another network. One function is to
convert media provided in one type of network to the format required in another type of network.
For example, a gateway could terminate bearer channels from a switched circuit network (e.g.,
DS0s) and media streams from a packet network (e.g., RTP streams in an IP network).
interferer – a packet stream that contends with the test stream of interest for a limited network
resource, such as a link buffer.
IP Network – a network based on the Internet Protocol, a connectionless protocol.
jitter – variation in packet delay.
latency – an expression of how much time it takes for a packet of data to get from one
designated point to another. See delay.
MTU Size – the largest size packet or frame (specified in octets) that can be sent in a packet- or
frame-based network such as the Internet.
packet loss – the failure of a packet to traverse the network to its destination. (This model does
not take into account discards due to buffer overflow.)
peak jitter – the maximum variation of delay from the mean delay.
peak-to-peak jitter – the full range of packet delay from the maximum amount to the minimum
amount.
QoS Edge Routing – routing between the customer premises network and the service provider
network based on Quality of Service classification values.
reordered packets– A packet that arrives at the destination with a packet sequence number
that is smaller than the previous packet is deemed a reordered packet.
route flap – repeated changes in a path due to updates to a routing table. The network model
simulates the effect of route flaps by making incremental changes in the delay values of the
core segment.
sequential packet loss – two or more consecutive lost packets.
upstream – a transmission from an end user toward a service provider.
3.2 Abbreviations
For the purposes of this standard, the following abbreviations shall apply.
BER: Bit Error Rate
CATV: Cable Television
3
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
DSL: Digital Subscriber Line
DSLAM: DSL Access Multiplexer
IP: Internet Protocol
IPTV: Internet Protocol Television
LAN: Local Area Network
MTU: Maximum Transmission Unit
OLT: Optical Line Termination
ONT: Optical Network Termination
OTT: Over-the-top (streaming video, non-IPTV)
PBS: Peak Burst Size (pcap generator)
pcap: Packet Capture (file format)
PIR: Peak Information Rate (pcap generator) POTS: Plain Old Telephone Service
PSTN: Public Switched Telephone Network
QoS: Quality of Service
SLA: Service Level Agreement
VoIP: Voice over Internet Protocol
VTC: Video Teleconferencing
4 Description of the Model
4.1 Model Overview
The new IP network model of this Standard is embodied in a discrete event software simulator.
In a real sense, the simulator is the model. Other implementations are possible, including realtime hardware network emulators for test lab use, but their behavior must match that of the
simulator presented here.
The IP network is modeled as a network of basic elements. Figure 1 shows the basic network
element, called a “switch.”
Third Interferer
Second Interferer
Interfering Stream
Generator
Test Stream Input
to This Stage
Store
and
Forward
Link
Latency
+
Packet Priority
Queues with Loss
Test Stream Output
from This Stage
Disturbance
Packets
Figure 1: Model Basic Network Switch Element
The basic network elements are wired in series into a specific network topology as described in
4.2.
4
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
This is an outline of the simulator processing:
1. A packet generator drives packets into the simulator. The arrival times and sizes of the
test stream packets and the interfering stream packets are read from pcap files.
2. A switch receives packets on its ingress ports, and determines where packets should go
next.
3. A switch schedules each packet for transmission out one of its egress ports.
4. Wires connect the egress port of one switch to the ingress port of another switch.
5. The process repeats for all packets through all switches and wires.
6. Packet arrival and departure times are stored in a file for analysis.
The sections that follow explain the components of the model in more detail:
 Network Topology
 Interfering Stream Files
 Models of Network Elements
 Simulation Inputs
 Simulation Outputs
 Packet Scheduling Algorithm
4.2 Network Topology
Error! Reference source not found. (LAN to LAN) illustrates an end-to-end network with LAN
and access links on each side of the core as would occur in a client-to-client application such as
VoIP. Error! Reference source not found. (Core to LAN) illustrates an end-to-end network
with LAN and access on the destination side, but not on the source side as would occur in a
server-to-client application such as IPTV or web server access over the internet. [Explain that a
core-only model could be used to evaluate streams that never traverse an IP access link.]
[insert diagrams: high-level LAN-LAN (5 boxes), Core-LAN (3 boxes), Core only]
[insert diagram showing detail, like slide 12]
4.3 Models of Network Elements
The various types of network elements considered in this model [as depicted in Figure previous]
are listed as columns in Table 1:
 core switches
 edge router
 access head end device
o DSLAM
o GPON OLT
 access subscriber end device
o DSL modem
o GPON ONT
 firewall (as part of residential gateway, for example)LAN
 wires between devices
Table 1 lists the attributes of each element in the network model:
 # switches: For the core section only, there are between 3 and 10 cascaded Gigabit
Ethernet switches
5
PN-3-0062-RV2 (to become TIA-921-B)






TR-30.3/10-12-027
Link down rate: refers to the direction from the core toward the premises
Link up rate: refers to the direction from the premises toward the core
Delay: the one-way flat delay of the element
QoS: Indicates that the element implements QoS priority scheduling
Buffer size: For devices with QoS the queue at each priority level holds 96 kBytes.
BER: The bit error rate of the physical access link
# switches
LAN
Firewall
Wire
GPON
ONT
GPON
Access
3 to
10
Link rate
down
(Mbit/s)
Link rate
up (Mbit/s)
Delay
1000
1000
3 to
33
5 to
50
100
100
1000
1000
1 to
3
2 to
35
100
100
10 to
300
ms
100
ns
1
ms
1 ms
1 to
7
QoS
Buffer size
(kBytes)
OLT
DSL
Modem
DSL
Access
DSLAM
Wire
Edge
Router
Wire
Attribute
Core
switch
Table 1: Network Model Element Attributes
96
96
BER
1 to
7
96
96
96
96
10-8
10-12
to
10-7
to
10-9
96
4.4 Interfering Stream Files
The network traffic files used by the simulator are all of a standard packet capture format
commonly known as pcap, as defined in file pcap.h (version 2.4) of libpcap. See
http://wiki.wireshark.org/Development/LibpcapFileFormat . Usually the files have been captured
at the endpoints of the network at client devices. The goal of these files is that they be used as
traffic sources for input into the simulation model.
These files have been anonymously captured by a variety of researchers and from a variety of
sources as real examples of representative types of packet traffic. The actual sources of the
data cannot always be disclosed. In general, the files are a reflection of the traffic patterns
observed and have had the payloads stripped to protect the privacy and rights of the actual
content as well as to keep the overall file size small. Note that even though the traffic source
files omit the payloads, size information is maintained so that the full traffic is modeled by the
simulation. The simulator does pass payload data, if present in the pcap file.
In addition to payload stripping, the pcap files have had a number of processing steps:

Flow separation: The files are split into upstream (toward the core) and downstream
(toward the client endpoint) files.
6
PN-3-0062-RV2 (to become TIA-921-B)



TR-30.3/10-12-027
Bandwidth analysis: The files are analyzed as to their overall and average bandwidth
over finite time periods. As reference files, the microscopic and macroscopic bandwidth
characteristics must be understood so that they can be applied reasonably to the various
simulation test cases. In particular, the bandwidth with characteristics of the files are
highly dependent on factors such as the overall bandwidth capabilities and rate
limitations of the network path, behavior and rate adaptation of higher layer network
protocols.
Smoothing: At a microscopic level, bandwidth analysis of some pcap files have been
observed to exhibit micro-bursting behavior that can result because of characteristics of
the networks stack or because of the application protocols with the availability of
abundant bandwidth. [perhaps an example can be shown from OTT2] A potential of
these microbursts is that even though the overall bandwidth of the file is reasonable, the
instantaneous bandwidth requirement can overwhelm link or memory capacities of the
scenario under test. This can be alleviated either through external smoothing of the file
or by the rate shaping parameters in the simulation configuration file.
Bandwidth scaling: The standard pcap files are specific captures intended to be a
representative proxy of network usage. Since they are generic in nature, the playback
into the simulator is made by bandwidth scaling. This is accomplished by temporal
dilation, i.e. playback of packets by a constant scale factor faster or slower to achieve
the desired network usage.
[we probably want figures of the bandwidth of the "reference files". i probably already have this.
it's actually several related groups since the BW ranges between kbits and ~15Mbit]
Quality of service QoS [xx] is a critical part of real networks and of each simulation scenario.
Traffic flows are assigned a priority that is essential in practical access networks to ensure that
higher priority traffic from managed services is carried in preference to lower priority traffic. The
simulator has 7 priority levels and no per-class bandwidth reservation. The simulation test
cases are set as follows:
1: (highest priority) Managed voice traffic
2: Managed IPTV-type video traffic
3: Unused
4: Unused
5: Unused
6: Unused
7: (lowest priority) Best effort, OTT video, VoIP, P2P
[QoS assigned as managed or residual bandwidth (or does that belong elsewhere in the
Standard?)] - perhaps a section on the design philosophy of test cases.
not specifically document text ...
Test cases have managed and unmanaged services. The managed services were assigned
QoS 1 and 2. The remaining over-the-top services are best effort level 7. In the simulation,
these OTT services will exhibit packet loss due to network congestion. Typically higher layer
mechanisms such as TCP or retransmission / forward error correction that go beyond the scope
of this standard are used to manage reliable delivery over unreliable networks.
7
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
[how described by time series, PDV histogram]
[impairment severity is a function of pcap statistics, number and rate of streams]
[where they came from]
[remember to include telepresence files from Phil H]
[how selected]
[bidirectional]
[how processed: strip payload (or not), optionally scaled, optionally smoothed]
[how described by time series, PDV histogram]
[QoS assigned as managed or residual bandwidth (or does that belong elsewhere in the
Standard?)]
[impairment severity is a function of pcap statistics, number and rate of streams]
[files provided on disk]
4.5 Simulation Inputs
Input to the simulator is in the form of PCAP files. These files are driven into the simulation as
specified by the timestamps in PCAP files. The payload of the PCAP files, if present, is carried
along with the packets in the simulation and placed in the output files. The simulation parameter
settings can adjust the timing of the packets driven into the simulation, for example to speed up
or slow down the playback, or to smooth out unintended burstiness. A full list of the adjustable
parameters for the PCAP packet generator is given in [Annex].
[network topology input]
[where pcap files are inserted: artificially all at the start]
Table 2: Network Model Simulation Input Parameters
Network Element
Core
Impairment / Interferer
Parameter Range
Number of Switches
Buffer Size (kB)
Rate (Gbit/s)
Total Core Link Delay (ms)
3 to 10
96
1
10 to 300
Buffer Size (kB)
96
Edge Router
Access (pick one technology)
GPON
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
Buffer Size (kB)
Delay (ms)
5 to 50
2 to 35
10-12 to 10-9
96
1
8
PN-3-0062-RV2 (to become TIA-921-B)
DSL
TR-30.3/10-12-027
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
Buffer Size (kB)
Delay (ms)
3 to 33
Buffer Size (kB)
96
Buffer size
96
Effective Rate (Mbits/s)
100
1 to 3
10-8 to 10-7
96
1
"Modem" / ONT
Firewall
LAN
Managed Bandwidth
IPTV HD Stream 1 - CBR (qty)
Downstream Rate (Mbit/s)
Upstream Rate (Mbit/s)
Shaping
QoS
IPTV HD Stream 2 - VBR (qty)
Downstream Rate (Mbit/s)
Upstream Rate (Mbit/s)
Shaping
QoS
IPTV SD Stream 1 - CBR (qty)
Downstream Rate (Mbit/s)
Upstream Rate (Mbit/s)
Shaping
QoS
IPTV SD Stream 2 - VBR (qty)
Downstream Rate (Mbit/s)
Upstream Rate (Mbit/s)
Shaping
QoS
VoIP/Fax (qty)
Downstream Rate (Mbit/s)
Upstream Rate (Mbit/s)
QoS
9
8
0.01
PIR/PBS
8
0.01
PIR/PBS
2
0.01
PIR/PBS
2
0.01
PIR/PBS
0.064
0.064
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
Residual Bandwidth
Peer-to-peer Rate Down
Peer-to-peer Rate Up
QoS
POP3 Rate Down
POP3 Rate Up
QoS
HTTP Rate Down
HTTP Rate Up
QoS
Youtube Rate Down
Youtube Rate Up
QoS
OTT2 Rate Down
OTT2 Rate Up
QoS
VoIP/Fax Rate Down
VoIP/Fax Rate Down
QoS
1.89
0.768
0.5
0.02
1.7
0.007
7
0.128
1
0.025
0.064
0.064
4.6 Simulation Outputs
The simulator output is a file for each direction – upstream and downstream – that lists the
precise arrival time and delay of each packet in the stream under test from model ingress to
egress. Packets that are dropped because of network congestion are noted. See the example
in Table 3.
10
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
Table 3: Example Simulator Output [replace with recent output]
Source:
Creation Date:
Description:
ContentEncoding :
Delay Unit:
Time
2
2.064531
2.068719
2.083353
2.103442
2.129744
2.136147
2.160704
2.276267
2.306837
2.331988
2.36096
2.443818
TIA-921-B
5/5/2010
Misc Downstream
2
ASCII
ms
Delay
62.540836
62.5377494
62.106312
62.21563497
62.40617898
62.154648
62.401416
63.0072554
62.69638617
63.43353741
62.41461574
62.09868
63.41120351
Drop
0
0
0
0
0
1
0
1
1
1
1
1
0
The simulator can be configured to monitor points throughout the network under test. Typically,
the standard cases have monitors at the outputs of the various flows. At these monitor points,
the simulator will generate produce pcap files that represent the traffic perturbed by the delay
and loss through the simulator as well as a separate csv file of the simulator time, delay, and
loss of each packet to the monitor point.
The CSV file can be plotted and analyzed to show a time series of the delay patterns and loss
bursts. Furthermore, Packet Delay Variation (PDV) histograms and Cumulative Distribution
Functions (CDF) can be generated for these files to analyze network characteristics. Examples
of some of these plots are shown for the standard test scenarios.
The generated pcap files represent the input packets as perturbed by the network simulation.
Payloads, if present in the input pcap files, are passed with the packets thereby enabling
possible further analysis of the contribution of network impairments on traffic. This analysis goes
beyond the scope of this standard.
[Should examples of PDV and time series be included here, or in an informative Annex?]
[Show time series and PDV from the same simulation]
4.7 Packet Scheduling Algorithm
Capitalized nouns in the following description refer to objects in the C++ simulator source code.
11
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
A Packet is driven into the simulation from a PacketGenerator, usually by reading Packets from
a PCAP file, and sending them into a Port on a Switch. The Switch receives the Packet,
determines where it should go next, and Schedules it for transmission out one of its egress
Ports. The egress Port is connected by a Wire to another Switch and the Wire schedules the
packet for ingress on the next Switch after the wire’s delay. This process repeats for the entire
network topology being simulated and for all packets being simulated. When packets reach their
final destination, they are stored in a file for post-analysis.
Normative Annex [X], included as an electronic attachment, contains the C++ source code of
the simulator. Annex [Y] is a detailed description of the simulator code.
5 IP Network Impairment Level Requirements
An implementation of the network model shall create impairments that conform to the
impairment levels specified in this section.
5.1 Service Test Profiles
Error! Reference source not found. represents service test profiles and the applications, node
mechanisms and network techniques associated with them. ITU-T Y.1541 uses a similar
approach, but a one-to-one mapping to these service profiles may not be possible.
Service Test
Profiles
Well-Managed
IP Network
(Profile A)
PartiallyManaged IP
Network
(Profile B)
Unmanaged
IP Network,
Internet
(Profile C)
Applications (Examples)
High quality video and
VoIP, VTC (Real-time
applications, loss
sensitive, jitter sensitive,
high interaction)
VoIP, VTC
(Real-time applications,
jitter sensitive, interactive)
Lower quality video and
VoIP, signaling,
transaction data (highly
interactive)
Transaction data,
interactive
Short transactions, bulk
data (low loss)
Traditional Internet
applications (default IP
networks)
Node
Mechanisms
Strict QoS,
guaranteed no
over
subscription
on links
Separate
queue with
preferential
servicing,
traffic
grooming
Separate
queue, drop
priority
Long queue,
drop priority
Separate
queue (lowest
priority)
Network Techniques
Constrained routing and
distance
Less constrained
routing and distances
Constrained routing and
distance
Less constrained
routing and distances
Any route/path
Any route/path
The following three test profiles are used in this IP network model that can be associated with
Service Level Agreements (SLA):
12
PN-3-0062-RV2 (to become TIA-921-B)



TR-30.3/10-12-027
Well-Managed Network (Profile A) – a network with no over-committed links that
employs QoS edge routing.
Partially-Managed Network (Profile B) – a network that minimizes over-committed links
and has one or more links without QoS edge routing.
Unmanaged Network (Profile C) – an unmanaged network such as the Internet that
includes over-committed links and has one or more links without QoS edge routing.
These tables represent end-to-end impairment levels, including LAN and access. In Tables 2, 3
and 4, the total packet loss is the sum of the sequential packet loss and random packet loss.
Note that service provider SLAs only guarantee characteristics of the core section of the
network.
Impairment Type
Units
Profile A
Well-Managed
Range (min to
max)
Profile B
Partially-Managed
Range (min to max)
Profile C
Unmanaged
Range (min to
max)
One Way
Latency
ms
20 to 100
(regional)
90 to 300
(intercontinental)
20 to 100 (regional)
90 to 400
(intercontinental)
20 to 500
Jitter (peak to
peak)
ms
0 to 50
0 to 150
0 to 500
Sequential
Packet Loss
ms
Random loss only
(except when link
failure occurs)
40 to 200
40 to 10,000
Rate of
Sequential Loss
sec-1
Random loss only
(except when link
failure occurs)
< 10-3
< 10-1
Random Packet
Loss
%
0 to 0.05
0 to 2
0 to 20
Reordered
Packets
%
0 to 0.001
0 to 0.01
0 to 0.1
5.2 Impairment Combination Standard Test Cases
[say how these were chosen so that the simulation results align with the impairment level
requirements just described.]
 realistic mix of typical traffic, with QoS priority levels
 span easy to difficult test cases
 results align with the impairment level requirements just described
 access rates and technologies for GPON and DSL in 2011
[Explain naming of the test cases. (Les)]
[Where do we describe how these test cases can be used? User guide annex?]
[somehow fit the spreadsheet here]
13
PN-3-0062-RV2 (to become TIA-921-B)
Annex A
TR-30.3/10-12-027
(Normative) – Description of Discrete Event Simulator
Simulation Parameter files
The parameters for running the simulation are given in a TCL file. The advantage of using TCL as a
parameter file format is that it is a well-known file format, and it is extensible so that users can further
customize the behavior of the simulation to suit their particular needs. An example of how this helps is
that it gives a convenient way to comment out portions of code and to print messages to the screen for
information or debugging. [Welch] [Ousterhout]
At the very top of a parameter file, the user must include the common support routines from the file
tc/common.tcl.
source "tc/common.tcl"
The first section of the parameter file consists of variable settings using the TCL “set” command. It is no
different from setting a normal variable in TCL, except that the names of the variables are specific to the
simulator. The example below sets the simulation length to 10 minutes (600 seconds)
set SimLengthSeconds [expr 10*60]
Note here that a TCL expression is used to make it easy to specify 10 minutes without needing to do the
multiplication manually.
Next, set the CORE network parameters
set NumCoreSW
set CORE_Latency
set CORE_Speed
5
20E-3
1E9
Next, set the Remote LAN speed
set RLAN_Speed
100E6
Next, set the Remote Access parameters
set
set
set
set
RACC_SpeedDown
RACC_SpeedUp
RACC_BER_Fwd
RACC_BER_Rev
33E6
2E6
1E-12
1E-12
Next set the Buffer sizes in the network elements
set CORESW_BufSizeBytes
set DSLAM_BufSizeBytes
[expr 1*65536]
[expr 1*65536]
0
PN-3-0062-RV2 (to become TIA-921-B)
set Firewall_BufSizeBytes
set Modem_BufSizeBytes
TR-30.3/10-12-027
65536
65536
The next section of the parameter file specifies the PacketGenerators that read input PCAP files and
drive them into the simulation.
1
# =============================================================================================================
#
Upstream PCAP Generators
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #
Name
File
Start
BW
PPM Rand
Prio Repeat
PIR
PBS
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
2.0
-1
1.0
0.0 0.0
PCAPRevI3
1
vocal_g729_dir2
# -------------------------------------------------------------------------------------------------------------
# =============================================================================================================
#
Downstream PCAP Generators
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #
Name
File
Start
BW
PPM Rand
Prio Repeat
PIR
PBS
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
-1
PCAPFwdI7
2.0
vocal_g729_dir1
1.0
0.0 0.0
1
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
2
-1
PCAPFwdI3
sh_12Mb_cbr_deburst
0.0
0.514
0.0
0.5
PCAP_Generator
-1
PCAPFwdI5
sh_6Mb_cbr_deburst
10.0
0.260
0.0
0.5
2
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
-1
PCAPFwdI9
YouTube1080p_Down_nopayload 2.0
0.16
0.0 0.9
7
PCAP_Generator
-1
PCAPFwdI10
Hulu480p_Down_nopayload
2.0
0.25
0.0 0.9
7
# -------------------------------------------------------------------------------------------------------------
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
The parameters for the input PCAP generators are specified in columns as shown above. The meanings
of the columns is described briefly below
2
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027

Instance Name – the instance name of the generator. This depends on the specific top level
simulation file.

Filename – the file name of the input PCAP file. Assumes that the PCAP file is in the ./pcap
subdirectory and has a .pcap suffix so neither of these needs to be specified in the parameter
file.

Start Delay – the relative delay, in seconds, before starting generator.

Bandwidth Scale Factor – a scale factor that divides the relative timestamps in the PCAP file. A
value of 1.0 makes no change to the timing of the packets. A value of 2.0 causes the packets to
be transmitted twice as fast by dividing the timestamps in the PCAP file by 2.0.

PPM offset – this is similar to the Bandwidth Scale Factor, but is expressed in units of parts per
million. A value of 0 ppm makes no change to the rate at which packets are generated. A value
of 100ppm reduces the timestamps in the PCAP file by 100 ppm, which causes the file to be
transmitted 100 ppm faster than nominal.

Randomness – this is a value from 0.0 to 1.0 that adds a percentage of randomness to the interpacket times. A value of 0.5 represents 50% randomness for inter-packet timing. For example, if
the time between two consecutive packets in the PCAP file is 1 millisecond, and the randomness
is 0.5, then the actual time between those two consecutive packets could be in the range 500
microsecond to 1.5 millisecond.

Priority – this is the assigned priority of the packets

Repeat Count – this is the number of times to repeat the PCAP file. A value of 0 or 1 means to
play the file once, a value of two or more will play the file that many times, and a value of -1 will
repeat the file forever.

Shaper PIR and Shaper PBS – these parameters control a shaper that is built into the
PacketGeneratorPCAP object. The PIR is the Peak Information Rate and is expressed in bits per
second, so the value 10E6 represents 10 million bits per second. The PBS is the Peak Burst Size
and is expressed in bits. Normally the PIR should be set safely above (e.g. 2.5x) the bit rate of a
VBR video stream, unless the goal is to smooth out microbursts.
3
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027
The next section of the parameter file specifies the Packet Monitors that write output PCAP files and
“.out” files
# =====================================================
#
Downstream PCAP Monitors
# - - - - - - - - - - - - - - - - - - - - - - - - - - #
Name
File
# - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Monitor
PktMonPCAPFwdI7
VoIP1_down
#
PCAP_Monitor
PktMonPCAPFwdI3
HD_8Mbit_cbr
PCAP_Monitor
PktMonPCAPFwdI5
SD_2Mbit_cbr
#
PCAP_Monitor
PktMonPCAPFwdI9
YouTube_down
PCAP_Monitor
PktMonPCAPFwdI10
Hulu_down
# ----------------------------------------------------# =====================================================
#
Upstream PCAP Monitors
# - - - - - - - - - - - - - - - - - - - - - - - - - - #
Name
File
# - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Monitor
PktMonPCAPRevI3
VoIP1_up
# -----------------------------------------------------
There are only two parameters for the PCAP monitor command

Instance Name – the instance name of the monitor. This depends on the specific top level
simulation file.

File Name – the base name of the output files. The output files will be placed into the same
directory as the parameter file and will have suffixes .pcap and .out.
Note that if a PCAP_Monitor line is commented out or not present, the output files will not be written.
This is helpful in situations where only a subset of the output files are needed so that disk space can be
saved.
The simulation predefines two global variables for use by the TCL code in the parameter file

$paramfile – this is the name of the parameter file

$paramdir – this is the directory name of the parameter file
4
PN-3-0062-RV2 (to become TIA-921-B)
Annex B
TR-30.3/10-12-027
(Normative) – C++ Source Code of Discrete Event Simulator
[electronic attachment]
Annex C
(Normative) – Packet Capture Files of Interfering Traffic
[list file names and sufficient description of each]
[electronic attachments]
Annex D
(Normative) – Simulator Output
[list file names. Describe contents of each file.]
[electronic attachments]
Annex E
(Informative) – Rationale for Network Model
pcap stream selection
pcap bit rates
access technologies, bit rates, and error rates
network topology
buffer size (equipment vendor)
queuing algorithms
Annex F
(Informative) – User’s Guide
F.1 Emulator Implementation
For a specified test case, the simulation produces delay and loss characteristics that can be
used in a real-time emulator. The emulator accepts a packet stream under test, and plays out
the same stream with packet delays and losses that match the corresponding simulation.
An emulator must shape the stream under test to account for the “self-interference” effect.
Packets that arrive too close together in time contend for the available bandwidth in the
emulated network. The amount of shaping depends on the effective bandwidth available to the
stream under test in the given test case. This available capacity is the rate of the access link
(the lowest-rate link in the network) less the sum of the rates of the interfering streams at QoS
priority the same or higher than the stream under test.
[LAN-TO-LAN: Emulator only. Concatenate two core-to-LAN models. Losses add (OR fn).
Fixed delays add, but maybe that’s not relevant since...Jitter is a result of adding delays on each
half, packet by packet. Interfering streams enter in the core, but it depends on business or
residence.]
DelayLL = DelaySev1 + DelaySev2
LossLL = LossSev1 “or” LossSev2
BW LL = Min[EBSev1, EBSev2] (EB = Effective BW)
F.2 Practical Use of Test Cases
____________________
5