Telecommunications Industry
Association
(TIA)
Austin, TX
TR-30.3/10-12-027r2
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, September,
November, and December 2010 meetings.
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Table of Contents
Foreword ..................................................................................................................................iv
Introduction .............................................................................................................................. v
1
Scope ................................................................................................................................. 1
2
Informative References .................................................................................................... 2
3
Definitions and Abbreviations ......................................................................................... 3
3.1
Definitions .................................................................................................................... 3
3.2
4
5
Abbreviations ............................................................................................................... 4
Description of the Model .................................................................................................. 4
4.1
Model Overview ........................................................................................................... 4
4.2
Network Topology ........................................................................................................ 5
4.3
Models of Network Elements ....................................................................................... 7
4.4
Interfering Stream Files ................................................................................................ 8
4.5
Simulation Inputs ........................................................................................................10
4.6
Simulation Outputs......................................................................................................11
4.7
Packet Scheduling Algorithm ......................................................................................14
IP Network Impairment Level Requirements ..................................................................14
5.1
Service Test Profiles ...................................................................................................15
5.2
Impairment Combination Standard Test Cases ...........................................................16
Annex A
(Normative) – Description of Discrete Event Simulator ...............................23
A.1 Simulator Overview .....................................................................................................23
A.2
Directory Structure ......................................................................................................23
A.3
Building the simulator ..................................................................................................24
A.4
Base CORE2LAN model .............................................................................................25
A.5
Simulator Input Data ...................................................................................................25
A.6
Running the simulation with convenience scripts ........................................................32
A.7
Simulator Output .........................................................................................................34
A.8
Plotting Results ...........................................................................................................35
A.9
Simulator Internal Conventions ...................................................................................36
A.9.1
Time .................................................................................................................36
A.9.2
Bits and Bytes ..................................................................................................36
A.9.3
Bit rates ............................................................................................................36
A.9.4
Priority ..............................................................................................................36
ii
PN-3-0062-RV2 (to become TIA-921-B)
A.9.5
A.10
TR-30.3/10-12-027r2
Addresses ........................................................................................................36
Simulator Objects for Network Elements ..........................................................37
A.10.1
Packet ..............................................................................................................37
A.10.2
Port Base Class ...............................................................................................38
A.10.3
Wire..................................................................................................................39
A.10.4
Switch ..............................................................................................................40
A.10.5
PacketQueue ...................................................................................................43
A.11
Simulator Input and Output Objects ..................................................................44
A.11.1
PacketGeneratorPCAP ....................................................................................44
A.11.2
PacketMonitorPCAP .........................................................................................46
A.11.3
“.out” File Format ..............................................................................................47
A.12
Other Base Classes .........................................................................................48
A.12.1
A.13
MemRecycler ...................................................................................................48
Simulator Objects for Discrete Event Simulation ..............................................49
A.13.1
Action ...............................................................................................................49
A.13.2
Functor .............................................................................................................49
A.13.3
Event ................................................................................................................49
A.13.4
Dispatcher/Scheduler .......................................................................................50
A.13.5
Red-Black Tree ................................................................................................51
A.14
Numbering conventions in the top Level Simulator (CORE2LAN.cpp) .............52
A.15
File List.............................................................................................................54
A.16
Common TCL file .............................................................................................57
Annex B
(Normative) – C++ Source Code of Discrete Event Simulator .....................61
Annex C
(Normative) – Packet Capture Files of Interfering Traffic ............................62
Annex D
(Normative) – Simulator Output ....................................................................63
Annex E
(Informative) – Rationale for Network Model ................................................63
Annex F
(Informative) – User’s Guide ..........................................................................63
F.1
Emulator Implementation ............................................................................................63
F.2
Practical Use of Test Cases ........................................................................................63
iii
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
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-027r2
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-027r2
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-027r2
The LAN-to-LAN test cases of TIA-921-A are now modeled as two cascaded TIA-921-B
core-to-LAN segments. See Informative Annex F.
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-027r2
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.
microburst – a packet traffic pattern characterized by short periods of high activity, and where
the bursts are not readily detectable when measuring average traffic rate over a period of one
second or longer.
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
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
3.2 Abbreviations
For the purposes of this standard, the following abbreviations shall apply.
BER: Bit Error Rate
CATV: Cable Television
CBR: Constant Bit Rate
CSV: Comma-Separated Values (file format)
DSL: Digital Subscriber Line
DSLAM: DSL Access Multiplexer
HD: High-Definition video
HTTP: Hypertext Transport Protocol
IP: Internet Protocol
IPTV: Internet Protocol Television (UDP)
LAN: Local Area Network
MTU: Maximum Transmission Unit
OLT: Optical Line Termination
ONT: Optical Network Termination
OTT: Over-the-top (TCP streaming video)
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
SD: Standard-Definition video
SLA: Service Level Agreement
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
VBR: Variable Bit Rate
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.”
4
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Third Interferer
Second Interferer
Interfering Stream
Generator
Test Stream Input
to This Stage
Store
and
Forward
Test Stream Output
from This Stage
Link
Latency
+
Packet Priority
Queues with Loss
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
section 4.2.
This is an outline of the simulator processing in one direction; both directions are included in the
model:
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
Figure 2 shows the IP service provider’s portion of the network, called the core, represented by
a cloud symbol. Basic network element switches within the core are interconnected to carry IP
traffic between ports.
5
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
1 Gbit/s
1 Gbit/s
# Switches
Queue
Delay
Reorder
Figure 2: Core Network Portion
Error! Reference source not found. shows the access portion of the IP network. In the
ownstream direction from the core to the customer premises, a series of network elements and
wires are connected: edge router, DSLAM (or OLT for GPON), DSL modem (or ONT for
GPON), firewall, and router. The model is bidirectional, so upstream traffic traverses the same
elements in reverse order.
Residential Gateway
DSLAM
or OLT
Edge Router
1 Gbit/s
Various
Rates
1 Gbit/s
Queue
Delay
DSL or
GPON
Queue per
QoS Level
Delay
BER
DSL Modem
or ONT
LAN
Firewall
100 Mbit/s
Queue
LAN
Router
100 Mbit/s
Queue
In/Out
Queue
Figure 3: Access Network Portion
Although the basic switch element of Figure 1 allows interfering streams to be inserted and to
exit at each stage, the network topologies of this Standard are simplified. Interferers only enter
and exit at the points shown next in Figure 4, Figure 5, and Figure 6.
Figure 4 shows a core-only network model. There is no access network. The core-only model
could be used to evaluate equipment and protocols that do not traverse an access link.
Interfering
Streams
(pcap files)
Interfering
Streams
(pcap files)
Core Network
Test
Stream
Test
Stream
Figure 4: Core-Only Network Model
Figure 5 (Core to LAN) illustrates a server-to-client application such as an IPTV or a web server.
All of the test case simultations of this Standard (except for a single core-only case) use the
core-to-LAN network model.
6
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Interfering
Streams
(pcap files)
Interfering
Streams
(pcap files)
Core Network
1 Gbit/s
Access Network
Test
Stream
Test
Stream
Figure 5: Core-to-LAN Network Model
Figure 6 (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. It is modeled as two
core-to-LAN networks concatenated. Some considerations for using the LAN-to-LAN model are
given in Annex F.
Interfering
Streams
(pcap files)
Access
Network
1 Gbit/s
Interfering
Streams
(pcap files)
Core Network
Test
Stream
1 Gbit/s
Interfering
Streams
(pcap files)
Core Network
1 Gbit/s
Access
Network
Interfering
Streams
(pcap files)
Test
Stream
Figure 6: LAN-to-LAN Network Model
4.3 Models of Network Elements
The various types of network elements considered in this model are listed as the 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
Each of the network elements is modeled identically in the simulator: as the basic switch
element shown in Figure 1. Only access head end devices implement multiple packet queues,
one per QoS priority. Each packet queue is 65 × 1518 = 98,670 bytes.
Table 1 rows list the attributes of each element in the network model:
 # switches: For the core section only, there are between 3 and 15 cascaded Gigabit
Ethernet switches
7
PN-3-0062-RV2 (to become TIA-921-B)





TR-30.3/10-12-027r2
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
BER: The bit error rate of the physical access link
# switches
Link rate
down
(Mbit/s)
Link rate
up (Mbit/s)
Delay
LAN
Firewall
Wire
GPON
ONT
GPON
Access
GPON
OLT
DSL
Modem
DSL
Access
DSLAM
Wire
Edge
Router
Wire
Attribute
Core
switch
Table 1: Network Model Element Attributes
3 to
15
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
QoS
BER
1 to
7
1 to
7
10-8
to
10-7
10-12
to
10-9
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. These files are used as interfering traffic input
to the simulation model.
The following types of streams are included in the standard test cases:
 IPTV: SD and HD, CBR and VBR
 VoIP
 FoIP (fax over IP)
 Peer-to-peer file transfer
 HTTP
 OTT TCP video: SD and HD
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.
8
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
In addition to payload stripping, the pcap files have had a number of processing steps:
 Flow separation: The captured files are split into upstream (toward the core) and
downstream (toward the client endpoint) files for simulation.
 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 characteristics of the files are highly
dependent on factors such as the overall bandwidth capabilities and rate limitations of
the network path, and the behavior and rate adaptation of higher layer network
protocols.
 Smoothing: At a microscopic level, bandwidth analysis of some pcap files reveals that
there are microbursts. A potential problem with these microbursts is that 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
representative of network usage. Since they are generic in nature, playback into the
simulator is made by bandwidth scaling. This is accomplished by temporal dilation
Playback of packets by a constant scale factor faster or slower achieves the desired
network usage.
Annex C describes the standard pcap files in detail, and includes the files as an electronic
attachment. The average bandwidth of one example (using a five second non-overlapping
window) is plotted in Figure 7.
Figure 7: Sample Interferer – OTT2 Downstream Flow
9
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
4.5 Simulation Inputs
Table 2 lists the inputs to the simulation. The core-to-LAN network topology is assumed. One
access technology (DSL or GPON) is selected. There are parameters for each network element
and for each pcap file used as an interfering traffic stream.
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 - 6: Unused
 7: (lowest priority) Best effort, OTT video, VoIP, peer-to-peer
10
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Table 2: Network Model Simulation Input Parameters
Network Element
Core
Impairment / Interferer
Number of Switches
Total Core Link Delay (ms)
Parameter Range
3 to 15
10 to 250
Access (pick one technology)
GPON
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
Delay (ms)
5 to 50
2 to 35
10-12 to 10-9
1
DSL
3 to 33
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
Delay (ms)
1 to 3
10-8 to 10-7
1
Managed Bandwidth
IPTV HD Stream 1 - CBR (qty)
Downstream Rate (Mbit/s)
IPTV HD Stream 2 - VBR (qty)
Downstream Rate (Mbit/s)
IPTV SD Stream 1 - CBR (qty)
Downstream Rate (Mbit/s)
IPTV SD Stream 2 - VBR (qty)
Downstream Rate (Mbit/s)
VoIP/Fax (qty)
Rate down/up (Mbit/s)
0 to 1 (10 core-only)
8
0 to 1 (10 core-only)
8
0 to 1 (10 core-only)
2
0 to 1 (10 core-only)
2
0 to 1 (10 core-only)
0.064 / 0.064
Residual Bandwidth
Peer-to-peer Rate Down / Up
HTTP Rate Down / Up
OTT1 Rate Down / Up
OTT2 Rate Down / Up
VoIP/Fax Rate Down / Up
1.89 / 0.768
1.7 / 0.007
7 / 0.128
1 / 0.025
0.064 / 0.064
4.6 Simulation Outputs
Output from the simulator is in the form of pcap files and “.out” files. The pcap files record the
output packets along with their timestamps. Comparisons of input pcap and output pcap files
can be performed to determine the effect of the impairment on, for example, video quality.
11
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The “.out” output files contain delay and packet loss information (in ASCII CSV format) about
the simulation result. This information is also implicitly contained in the pcap file, but because it
is not possible directly to indicate packet delay or loss in a pcap file, the “.out” files are helpful
for post analysis. For example, because the “.out” files are in CSV format, they can be read into
a spreadsheet programs for analysis.
The examples in Table 3, Figure 8, and Figure 9 are from the same simulation. Table 3 shows a
few packets from the csv file.
Table 3: Example Simulator Output for Case Dw4, Stream HD_cbr Downstream
Source:
Creation Date:
Description:
Content-Encoding :
Delay Unit:
TIA TR30.3: TIA-921B
12/7/2010
Dw4-HDTV1
ASCII
ms
Time
Delay
21.33439
21.33571
21.33703
21.33835
21.33967
21.34099
21.34363
21.34363
21.34495
77.69556
77.69556
78.00174
77.69556
77.69556
77.69556
77.69556
77.69556
77.69556
Drop
0
0
0
0
0
0
1
0
0
Figure 8 is a plot derived from the same csv file from which Table 3 is a tiny excerpt. Note the
first dropped packet around 21 seconds.
12
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Figure 8: Time Series Plot of Packet Delay and Loss
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. Figure 9 is
the PDV histogram from the same Dw4 simulation.
13
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Figure 9: PDV Histogram
Complete simulation output of the standard test cases are found in Annex D.
4.7 Packet Scheduling Algorithm
Capitalized nouns in the following description refer to objects in the C++ simulator source code.
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 B, included as an electronic attachment, contains the C++ source code of the
simulator. Annex A 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.
14
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
5.1 Service Test Profiles
Table 4 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.
Table 4: Service Test Profiles (from ITU-T Y.1541)
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
Table 5 shows industry accepted end-to-end impairment levels, including LAN and access, that
correspond to the Service Test Profiles. The total packet loss shown 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.
15
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Table 5: End-to-End LAN-to-LAN Impairment Levels per Service Test Profile
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
40 to 200
40 to 10,000
Rate of
Sequential Loss
sec-1
Random loss only
< 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
The standard test cases of this IP network model have the following characteristics for each
Service Test Profile:
 Well-Managed Network (Profile A) – a network with no over-committed links that
employs QoS edge routing. The well-managed test cases include managed voice and
video services.
 Partially Managed Network (Profile B) – a network that minimizes over-committed links
and has one or more links without QoS edge routing. The partially managed test cases
include a mixture of managed voice and video services, and unmanaged / best-effort
data and over-the-top video services
 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. The
unmanaged test cases include unmanaged data and over-the-top video services.
The specific core network parameters, interferers, and access network parameters for each test
case were selected so that the simulation results align with the impairment level requirements of
section 5.1, with an adjustment to account for the fact that the simulations only cover the coreto-LAN topology. The interferers represent a realistic mix of typical traffic. The test cases span
a range of impairment severities from mild to severe within each Service Test Profile.
The test cases are specified in Table 6, Table 7, and Table 8. Each test case is labeled as
follows:
16
PN-3-0062-RV2 (to become TIA-921-B)



TR-30.3/10-12-027r2
The first character is either D for DSL or G for GPON. The access rates and
impairments chosen represent typical values in 2011. (The single core-only test case,
lacking an access network portion, is labeled simply “Core.”)
The second character is one of the following:
o w for well-managed profile A, highlighted in green in Table 6.
o p for partially managed profile B, highlighted in yellow in Table 7.
o u for unmanaged profile C, highlighted in red in Table 8.
o c for the core-only case, highlighted in blue in Table 8.
The third character is an ordinal digit, where a higher value generally corresponds to a
higher severity (more difficult) test case.
For example, test case Dw5 uses DSL access in a well-managed network with impairment
severity 5. Note that all simulations (except the single core-only case) are for the core-to-LAN
network topology of Figure 5.
A given test case column uses the identical interfering streams and parameters between the
DSL and GPON versions. Only the access technology parameters differ.
The column “PCAP Avg BW” shows the long-term average bit rate of each pcap file after
smoothing, but before scaling. The percentages shown for each pcap file under each test case
are the time scale factors applied to the interferers by the packet generator. A higher
percentage decreases the inter-packet time, which increases the effective bit rate of the
interferer.
17
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Table 6: Well-Managed Service Test Profile A Test Cases
Well Managed
Network
Element
Core
Impairment / Interferer
PCAP Avg BW
(Mb/s)
Number of Switches
Total Core Link Delay (ms)
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
Managed Bandwidth
IPTV HD Stream 1 - CBR (qty)
IPTV HD Stream 2 - VBR (qty)
IPTV SD Stream 1 - CBR (qty)
IPTV SD Stream 2 - VBR (qty)
VoIP/Fax (qty)
Residual Bandwidth
Peer-to-peer Rate Down
Peer-to-peer Rate Up
HTTP Rate Down
HTTP Rate Up
OTT1 Rate Down
OTT1 Rate Up
OTT2 Rate Down
OTT2 Rate Up
VoIP/Fax Rate Down
VoIP/Fax Rate Down
w2
3
10
Access (pick one technology)
GPON
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
DSL
w1
w3
w4
4
25
5
50
50
50
25
25
1.E-12 1.E-12
33
33
3
3
1.E-08 1.E-08
w5
6
75
w6
w7
w8
7
85
8
100
9
125
10
150
35
25
1.E-11
35
25
25
25
1.E-10 1.E-10
25
25
1.E-09
25
15
25
5
1.E-09 1.E-09
33
3
1.E-08
22
16
2
1
1.E-08 1.E-07
16
1
1.E-07
16
10
1
1
1.E-07 1.E-07
(QoS Voice=1
Video=2)
8
8
2
2
0.064/0.064
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
100%
100%
100%
100%
100%
100%
100%
100%
1
1
1
1
1
1
100%
100%
100%
100%
100%
100%
100%
100%
QoS = 7
1.89
0.285
1.58
0.66
6.678
0.099
2.66
0.051
0.064
0.064
18
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Table 7: Partially Managed Service Test Profile B Test Cases
Partially Managed
Network
Element
Core
Impairment / Interferer
PCAP Avg BW
(Mb/s)
Number of Switches
Total Core Link Delay (ms)
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
Managed Bandwidth
IPTV HD Stream 1 - CBR (qty)
IPTV HD Stream 2 - VBR (qty)
IPTV SD Stream 1 - CBR (qty)
IPTV SD Stream 2 - VBR (qty)
VoIP/Fax (qty)
Residual Bandwidth
Peer-to-peer Rate Down
Peer-to-peer Rate Up
HTTP Rate Down
HTTP Rate Up
OTT1 Rate Down
OTT1 Rate Up
OTT2 Rate Down
OTT2 Rate Up
VoIP/Fax Rate Down
VoIP/Fax Rate Down
p2
3
10
Access (pick one technology)
GPON
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
DSL
p1
p3
4
25
p4
5
50
p5
8
75
p6
10
100
12
200
35
35
25
35
15
25
1.E-12 1.E-12 1.E-11
15
5
5
2
1.E-09 1.E-09
15
5
1.E-09
24
18
12
3
1.5
1.5
1.E-08 1.E-08 1.E-08
6
3
1
1
1.E-07 1.E-07
6
1
1.E-07
(QoS Voice=1
Video=2)
8
8
2
2
0.064/0.064
1
1
1
1
1
1
1
1
1
1
1
1
0
1
1
1
1
1
50%
135%
100%
50%
25%
135%
40%
50%
20%
135%
20%
60%
25%
135%
40%
50%
100%
100%
100%
100%
100%
100%
10%
135%
10%
10%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
100%
QoS = 7
1.89
0.285
1.58
0.66
6.678
0.099
2.66
0.051
0.064
0.064
19
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Table 8: Unmanaged Service Test Profile C and Core-Only Test Cases
Unmanaged
Network
Element
Core
Impairment / Interferer
PCAP Avg BW
(Mb/s)
u1
Number of Switches
Total Core Link Delay (ms)
3
10
Access (pick one technology)
GPON
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
DSL
Access Rate Down (Mbit/s)
Access Rate Up (Mbit/s)
Residual BER
Managed Bandwidth
IPTV HD Stream 1 - CBR (qty)
IPTV HD Stream 2 - VBR (qty)
IPTV SD Stream 1 - CBR (qty)
IPTV SD Stream 2 - VBR (qty)
VoIP/Fax (qty)
Residual Bandwidth
Peer-to-peer Rate Down
Peer-to-peer Rate Up
HTTP Rate Down
HTTP Rate Up
OTT1 Rate Down
OTT1 Rate Up
OTT2 Rate Down
OTT2 Rate Up
VoIP/Fax Rate Down
VoIP/Fax Rate Down
u2
4
25
u3
5
50
u4
Core
u5
8
75
10
100
u6
12
200
u7
c1
15
250
3
150
35
35
25
15
5
15
5
35
15
25
5
2
5
2
1.E-12 1.E-12 1.E-11 1.E-09 1.E-09 1.E-09 1.E-09
1000
1000
1.E-12
24
18
12
6
3
6
3
3
1.5
1.5
1
1
1
1
1.E-08 1.E-08 1.E-08 1.E-07 1.E-07 1.E-07 1.E-07
1000
1000
1.E-12
(QoS Voice=1
Video=2)
8
8
2
2
0.064/0.064
10
10
10
10
10
QoS = 7
1.89
0.285
1.58
0.66
6.678
0.099
2.66
0.051
0.064
0.064
100%
100%
200%
200%
100%
100%
10%
135%
10%
10%
100%
100%
200%
200%
100%
100%
50%
135%
100%
50%
25%
135%
40%
50%
20%
135%
20%
60%
25%
135%
40%
50%
20%
135%
20%
60%
200%
200%
100%
100%
100%
100%
100%
100%
50%
50%
100%
100%
100%
100%
100%
100%
50%
50%
100%
100%
1000%
2000%
1000%
1000%
500%
500%
500%
500%
1000%
1000%
Figure 10 shows the aggregate bit rate over time for the DSL well-managed profile. Test Profile
A has the following characteristics:
 Bandwidth utilization is stable.
 Packet loss is low.
 Jitter is low.
20
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Dw Test Series
14000000
Aggregate BW (bits/s)
12000000
10000000
8000000
6000000
4000000
2000000
0
0
60
120
180
240
300
360
420
480
540
Dw7
Dw8
600
time (sec)
Dw1
Dw2
Dw3
Dw4
Dw5
Dw6
Figure 10: Aggregate Bit Rate over Time for DSL Well-Managed Profile A
Figure 11 shows the aggregate bit rate over time for the DSL partially managed profile. Test
Profile B has the following characteristics:
 Bandwidth can vary significantly.
 Packet loss is medium to high for the subset of unmanaged services.
 Jitter is medium to high for the subset of unmanaged services.
Dp Test Series
Aggregate BW (bits/sec)
30000000
25000000
20000000
15000000
10000000
5000000
0
0
60
120
180
240
300
360
420
480
540
600
time (sec)
Dp1
Dp2
Dp3
Dp4
Dp5
Dp6
Dp7
Figure 11: Aggregate Bit Rate over Time for DSL Partially Managed Profile B
Figure 12 shows the aggregate bit rate over time for the DSL unmanaged profile. Test Profile C
has the following characteristics:
21
PN-3-0062-RV2 (to become TIA-921-B)



TR-30.3/10-12-027r2
Bandwidth can vary significantly.
Packet loss is high.
Jitter is high.
Du Test Series
Aggregate BW (bits/sec)
25000000
20000000
15000000
10000000
5000000
0
0
60
120
180
240
300
360
420
480
time (sec)
Du1
Du2
Du3
Du4
Du5
Du6
Figure 12: Aggregate Bit Rate over Time for DSL Unmanaged Profile C
22
Du7
540
600
PN-3-0062-RV2 (to become TIA-921-B)
Annex A
TR-30.3/10-12-027r2
(Normative) – Description of Discrete Event Simulator
A.1 Simulator Overview
The TIA-921B impairment simulation is implemented as a general purpose discrete event simulator. This
means that it contains discrete event models of generalized network elements, such as switches, routers
and set top boxes, which are connected together by means of wires. Events in the simulation consist
mainly of packet arrivals and departures from the different network elements, but other types of events
are also possible.
The simulator source code is implemented using object oriented design techniques in C++.
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.
The inputs and outputs from the simulation are in the form of PCAP packet files. PCAP is a de-facto
industry standard that can be read by a variety of commonly available tools such as wireshark and
tcpreplay.
A.2 Directory Structure
sim/
top level directory
sim/src
subdirectory for simulator source code
sim/pcap
subdirectory for input PCAP files
sim/tc
subdirectory for test case parameter files
sim/out
subdirectory for outputs from test cases
sim/tc/common.tcl
shared TCL routines
sim/tc/Dw1.param
input parameter file for test case Dw1
sim/out/Dw1
sub-subdirectory for outputs from test case “Dw1”
sim/src/bin.debug
subdirectory for simulator’s binary executable
23
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.3 Building the simulator
The source code for the simulation is written in the C++ language and has been tested under Cygwin 1.7
on Windows XP and Windows 7, Ubuntu Jaunty Jackalope (x86_64), openSUSE 11.1 (i386) and Fedora
Core 8. It has been built using GNU Make 3.81 and GCC/G++ version 3.4.4 or GCC version 4.3.4.
The simulator uses the TCL interpreter for reading simulation parameters, so the machine on which the
code is built must have the tcl.h header file and associated library to link against. This has been tested
with the ActiveState TCL distribution under Windows and with the native Linux TCL. In either case
versions 8.4 and 8.5 have been seen to work.
The path to the tcl.h and the library file is specified in the Makefile. You may need to modify the
Makefile to adjust the path to these two files on your system.
Once the paths for the TCL files has been set and verified, building the simulation requires running
“make”
If the simulator is built successfully, there will be an executable program called CORE2LAN.exe in the
sim/src/bin.debug subdirectory.
The following shows the result of a successful compilation.
$ make
Generating
Generating
Generating
Generating
Generating
Generating
Generating
Generating
Generating
Generating
Generating
Generating
Generating
Generating
Generating
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
dependencies
for
for
for
for
for
for
for
for
for
for
for
for
for
for
for
CORE2LAN.cpp
redblack.c
Wire.cpp
Switch.cpp
SimParam.cpp
Port.cpp
PacketQueue.cpp
PacketMonitorPCAP.cpp
PacketMonitor.cpp
PacketGeneratorPCAP.cpp
PacketGenerator.cpp
Packet.cpp
Event.cpp
Dispatcher.cpp
Clock.cpp
-----------------------Compiling for debug
- - - - - - - - - - - g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/CORE2LAN.o CORE2LAN.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/Clock.o Clock.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/Dispatcher.o Dispatcher.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/Event.o Event.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/Packet.o Packet.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/PacketGenerator.o PacketGenerator.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/PacketGeneratorPCAP.o PacketGeneratorPCAP.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
24
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
-Wno-write-strings -o objs.debug/PacketMonitor.o PacketMonitor.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/PacketMonitorPCAP.o PacketMonitorPCAP.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/PacketQueue.o PacketQueue.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/Port.o Port.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/SimParam.o SimParam.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/Switch.o Switch.cpp
g++ -c -g -O2 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include
-Wno-write-strings -o objs.debug/Wire.o Wire.cpp
gcc -c -g -O4 -Wall -DDEBUG -I../lib -Isrc -I. -I/cygdrive/c/tcl/include –
o objs.debug/redblack.o redblack.c
-----------------------Linking bin.debug/CORE2LAN.exe
- - - - - - - - - - - g++ -lm -g -o bin.debug/CORE2LAN.exe objs.debug/CORE2LAN.o
objs.debug/Clock.o
objs.debug/Dispatcher.o
objs.debug/Event.o
objs.debug/Packet.o
objs.debug/PacketGenerator.o
objs.debug/PacketGeneratorPCAP.o
objs.debug/PacketMonitor.o
objs.debug/PacketMonitorPCAP.o
objs.debug/PacketQueue.o
objs.debug/Port.o
objs.debug/SimParam.o
objs.debug/Switch.o
objs.debug/Wire.o
objs.debug/redblack.o
/cygdrive/c/tcl/bin/tcl84.dll
A.4 Base CORE2LAN model
The base simulator code contains the basic topology of a CORE-to-LAN configuration, with 5 nodes of a
high speed core network, a high speed edge router, an access link (for example with a DSLAM and DSL
modem), a residential firewall/gateway, a home LAN and four set top boxes and two PCs.
[Editor’s note: add diagram here]
A.5 Simulator Input Data
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 below.
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
25
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
that it gives a convenient way to comment out portions of code and to print messages to the screen for
information or debugging.
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)
# - - - - - - - - - - - - - - - # Simulation length
# - - - - - - - - - - - - - - - set SimLengthSeconds [expr 10*60]
In most test cases, the above line is commented out so that a default simulation length from
common.tcl can control the duration of the simulation.
Note also in this example that a TCL expression computes the number of seconds in ten minutes. While
it is also possible to also specify 600 seconds, using an expression in this way helps to make clear what is
intended (10 minutes) and also serves an example of how to use TCL expressions in the parameter file.
Next, set the Access and Core network parameters (this example is from test case Dp4):
# - - - - - - - - - - - - - - - # Network Parameters
# - - - - - - - - - - - - - - - Set_Access_Params dsl_p4_u4
Set_Core_Params p4_u4
The first line above sets parameters for the access network. The second line above sets parameters for
the core network. The arguments to these two procedures is a text string that refers to a pre-defined
combination of parameters that are given in common.tcl. Custom test cases can be created by setting
the individual simulator control variables at this level.
26
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The table below shows the names of the predefined access parameters, and the corresponding access
parameters:
Tech Param
Name
dsl_w1
dsl_w2
dsl_w3
dsl_w4
dsl_w5
dsl_w6
dsl_w7
dsl_w8
pon_w1
pon_w2
pon_w3
pon_w4
pon_w5
pon_w6
pon_w7
pon_w8
pon_p1_u1
pon_p2_u2
pon_p3_u3
pon_p4_u4
pon_p5_u5
pon_p6_u6
pon_p7_u7
dsl_p1_u1
dsl_p2_u2
dsl_p3_u3
dsl_p4_u4
dsl_p5_u5
dsl_p6_u6
dsl_p7_u7
Node
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
RACC
SpeedDn SpeedUp BER_Fwd BER_Rev
3.30E+07
3.30E+07
3.30E+07
2.20E+07
1.60E+07
1.60E+07
1.60E+07
1.00E+07
5.00E+07
5.00E+07
3.50E+07
3.50E+07
2.50E+07
2.50E+07
2.50E+07
1.50E+07
3.50E+07
3.50E+07
2.50E+07
1.50E+07
5.00E+06
1.50E+07
5.00E+06
2.40E+07
1.80E+07
1.20E+07
6.00E+06
3.00E+06
6.00E+06
3.00E+06
3.00E+06
3.00E+06
3.00E+06
2.00E+06
1.00E+06
1.00E+06
1.00E+06
1.00E+06
2.50E+07
2.50E+07
2.50E+07
2.50E+07
2.50E+07
2.50E+07
2.50E+07
5.00E+06
3.50E+07
1.50E+07
2.50E+07
5.00E+06
2.00E+06
5.00E+06
2.00E+06
3.00E+06
1.50E+06
1.50E+06
1.00E+06
1.00E+06
1.00E+06
1.00E+06
27
1.00E-08
1.00E-08
1.00E-08
1.00E-08
1.00E-07
1.00E-07
1.00E-07
1.00E-07
1.00E-12
1.00E-12
1.00E-11
1.00E-11
1.00E-10
1.00E-09
1.00E-09
1.00E-09
1.00E-12
1.00E-12
1.00E-11
1.00E-09
1.00E-09
1.00E-09
1.00E-09
1.00E-08
1.00E-08
1.00E-08
1.00E-07
1.00E-07
1.00E-07
1.00E-07
1.00E-08
1.00E-08
1.00E-08
1.00E-08
1.00E-07
1.00E-07
1.00E-07
1.00E-07
1.00E-12
1.00E-12
1.00E-11
1.00E-11
1.00E-10
1.00E-09
1.00E-09
1.00E-09
1.00E-12
1.00E-12
1.00E-11
1.00E-09
1.00E-09
1.00E-09
1.00E-09
1.00E-08
1.00E-08
1.00E-08
1.00E-07
1.00E-07
1.00E-07
1.00E-07
LatcyDn
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
LatcyUp
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
1.00E-03
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The table below shows the names of the predefined access parameters, and the corresponding access
parameters:
Name
w1
w2
w3
w4
w5
w6
w7
w8
p1_u1
p2_u2
p3_u3
p4_u4
p5_u5
p6_u6
p7_u7
core_only
NumCoreSW
3
4
5
6
7
8
9
10
3
4
5
8
10
12
15
5
Latency
10.0E-3
25.0E-3
50.0E-3
75.0E-3
85.0E-3
100.0E-3
125.0E-3
150.0E-3
10.0E-3
25.0E-3
50.0E-3
75.0E-3
100.0E-3
200.0E-3
250.0E-3
100.0E-3
Speed
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
1.00E+09
The next section of the parameter file specifies the input and output packet streams. PacketGenerators
read input PCAP files and drive them into the simulation. PacketMonitors receive packets from elements
within the simulation and saves them into PCAP format, and also saves delay and packet loss
information.
An example of this for test case Dp4 shown in the box on the following page:
28
# =====================================================================================================================
#
Residual Bandwidth PCAP Stream Generators and Monitors
#
#
Name
File
Start
BW
PPM Rand
Prio Repeat
PIR PBS
# --------------------------------------------------------------------------------------------------------------------PCAP_Generator
-1
PktGenPCAPFwdI7
HTTP_Down
0.0
0.40
0.0 0.0
7
PCAP_Monitor
PktMonPCAPFwdI7
HTTP_Down
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
-1
PktGenPCAPRevI7
HTTP_Up
0.0
0.50
0.0 0.0
7
PCAP_Monitor
PktMonPCAPRevI7
HTTP_Up_out
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
-1
;# 0.473 Mb/s
PktGenPCAPFwdI9
P2P_Down
2.0
0.25
0.0 0.0
7
PCAP_Monitor
PktMonPCAPFwdI9
P2P_Down
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
-1
;# 0.384 Mb/s
PktGenPCAPRevI9
P2P_Up
2.0
1.35
0.0 0.0
7
PCAP_Monitor
P2P_Up
PktMonPCAPRevI9
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
-1
PktGenPCAPFwdI8
ipfax_v34_t38_fwd
0.0
1.0
0.0 0.0
7
PCAP_Monitor
Fax_v34_t38_Fwd
PktMonPCAPFwdI8
PCAP_Generator
-1
PktGenPCAPRevI8
ipfax_v34_t38_rev
0.0
1.0
0.0 0.0
7
PCAP_Monitor
PktMonPCAPRevI8
Fax_v34_t38_Rev
# =====================================================================================================================
#
Managed Bandwidth PCAP Stream Generators and Monitors
#
#
Name
File
Start
BW
PPM Rand
Prio Repeat
PIR PBS
# --------------------------------------------------------------------------------------------------------------------PCAP_Generator
-1
PktGenPCAPFwdI1
voip_g729_fwd
2.0
1.0 0.0 0.0
1
PCAP_Monitor
PktMonPCAPFwdI1
VoIP1_Fwd
PCAP_Generator
-1
PktGenPCAPRevI1
voip_g729_rev
2.0
1.0 0.0 0.0
1
PCAP_Monitor
VoIP1_Rev
PktMonPCAPRevI1
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
-1
;# 2.0Mb/s
PktGenPCAPFwdI4
SD_cbr
5.0
0.260 0.0 0.0
2
PCAP_Monitor
PktMonPCAPFwdI4
SDTV1_Down
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PCAP_Generator
-1
2
;# 2.0Mb/s
PktGenPCAPFwdI5
SD_vbr
5.0
0.361 0.0 0.0
PCAP_Monitor
PktMonPCAPFwdI5
SDTV2_Down
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
29
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The parameters for the input PCAP generators are specified in columns as shown above. The meanings
of the columns is described briefly below

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.
30
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The Packet Monitors that write output PCAP files and “.out” files. 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 is 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

$outdir – this is the output directory name, and is set based on $paramfile in common.tcl.
31
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.6 Running the simulation with convenience scripts
Two convenience scripts are provided to help automate the process of running a simulation and plotting
results. The first is a shell script to run one test case from the command line. To use this script, type the
command:
./runone.ss
Dw1
Similarly, there is a convenience shell script to run all test cases that match a given shell filename
pattern. To use this script, type the command:
./runall.ss [GD]w[1-3]
(this runs GPON and DSL well managed cases number 1 through 3).
When the simulation is run, it prints a variety of messages to help the user understand what is
happening. At the beginning of the simulation, it prints out information regarding the input PCAP files,
and the output PCAP files. Then during the simulation, it prints some special characters to give an
indication of simulation progress, specifically:

A “.” is printed after every 100,000 events have been processed by the simulation dispatcher.
This character indicates that the simulation is progressing

A “D” is printed whenever a packet is dropped due to queue overflow

An “E” is printed whenever a packet is lost due to a bit error on a wire (BER)

An “^” (caret) is printed whenever a PCAP input file reaches the end and is restarted.
This characters is always printed at the beginning of a line.

An “X” is printed whenever a packet is dropped because it’s destination ID (address) is larger
than the forwarding table in a Switch (this should never happen in a properly configured
simulation)

An “N” is printed whenever a packet is dropped because the forwarding rule in a Switch has no
entry for the packet’s destination ID (address).
32
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
An example simulation output is shown below
$ ./runone.ss Du1
+ cd src
+ make
+ src/bin.debug/CORE2LAN tc/Dw1.param
INFO: PacketMonitorPCAP saving CSV stats to out/Dw1/VoIP1_Fwd.out
INFO: PacketMonitorPCAP saving PCAP output to out/Dw1/VoIP1_Fwd.pcap
INFO: PacketMonitorPCAP saving CSV stats to out/Dw1/HDTV1_Down.out
INFO: PacketMonitorPCAP saving PCAP output to out/Dw1/HDTV1_Down.pcap
INFO: PacketMonitorPCAP saving CSV stats to out/Dw1/Fax_v34_t38_Fwd.out
INFO: PacketMonitorPCAP saving PCAP output to out/Dw1/Fax_v34_t38_Fwd.pcap
INFO: PacketMonitorPCAP saving CSV stats to out/Dw1/VoIP1_Rev.out
INFO: PacketMonitorPCAP saving PCAP output to out/Dw1/VoIP1_Rev.pcap
INFO: PacketMonitorPCAP saving CSV stats to out/Dw1/Fax_v34_t38_Rev.out
INFO: PacketMonitorPCAP saving PCAP output to out/Dw1/Fax_v34_t38_Rev.pcap
..E...E..
^..EE...
^.EE..E..EE.
^....E..E.
^E...EEE.
^......E..E.
^.
^
^E.E
^..E....E
^.E..E..
^...
^....
^.E.EE..E.E.E....
^.
^.E...E.E..EE.E..
^
^.E.
^.EE.E
^E..EE.E.EE.E..
^......
^.E.E.
^..
^....E.E.E.E.
^
33
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.7 Simulator Output
All output files for test case tcname are placed in the ./out/tcname subdirectory. By placing the
output results for each test case in their own directory, it is easier to keep them organized. By placing
the outputs in a separate directory from the input parameter settings, the output results can be easily
cleaned up, and it is easier to manage the parameter files.
Output from the simulator is in the form of PCAP files and “.out” files. The PCAP files record the output
packets along with their timestamps. Comparisons of input PCAP and output PCAP files can be
performed to determine the effect of the impairment on, for example, video quality.
The “.out” output files contain delay and packet loss information (in ASCII CSV format) about the
simulation result. This information is also implicitly contained in the PCAP file, but because it is not
possible to directly indicate packet delay or loss in a PCAP file, the “.out” files are helpful for post
analysis. For example, because the “.out” files are in CSV format, they can be read into a spreadsheet
programs for analysis.
As described in the section above on the Parameter File, it is not necessary to save output for all of the
streams being tested. This can be helpful in conserving disk space, as the output files can be quite large.
34
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.8 Plotting Results
Scripts are also provided to create plots of packet delay/loss versus time from the “.out” files, as well as
plots of packet delay variation (PDV). The script “runone.ss” automatically runs these scripts after
running the simulator.
These scripts are written in the “perl” language and depend upon the “gnuplot” utility. Therefore it is
necessary to have both perl and gnuplot installed on the machine which will run the post-analysis.
On Windows machines, this needs to be the cygwin version of gnuplot because the perl script pipes the
gnuplot commands into gnuplot using a pipe. The version of gnuplot that is used is 4.2.
To make a PNG plot of delay and packet loss from a “.out” file use the “out2png.pl” script. To run this
script type the following command:
./src/out2png2.pl out/Dw1/HDTV1_Down.out
To make a PNG plot of the PDV is a two step process. First calculate the histogram statistics using the
“out2histo.pl” script, which creates a CSV file. This CSV file can then be plotted with the “histo2png.pl”
script:
./src/out2histo.pl out/Dw1/HDTV1_Down.out > out/Dw1/HDTV1_Down-PDV.csv
./histo2png.pl tc/sev1/HDTV1_Down-PDV.csv
35
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.9 Simulator Internal Conventions
A.9.1 Time
Time in the simulator is represented in units of seconds, and with the type SimTime which is defined as
double.
A.9.2 Bits and Bytes
Packets lengths are measured in units of Bytes, and variable names that contain byte quantities include
the word “Bytes” in order to make it clear what the units are.
In other places, bits are used (for example in burst sizes for the shaper).
A.9.3 Bit rates
Bit rates in the simulator are represented in units of bits per second, and with the type Bitrate_t which
is defined as double.
A.9.4 Priority
Priority levels in the simulator are represented as integers, with smaller numbers representing higher
priority packets.
A.9.5 Addresses
Endpoints in the simulation are assigned unique identifiers so that packets may be assigned a source and
destination ID. The identifiers are relatively small integer values that serve the same function that L2 or
L3 addresses would serve in a real network. Because the simulation model is much simpler than a real
L2 or L3 network, and because efficiency of the simulation is important, these identifiers are used
instead of actual L2 or L3 addresses.
36
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.10 Simulator Objects for Network Elements
A.10.1 Packet
A Packet object contains the data for a packet. The members of a Packet object are described briefly in
the table below.
Packet
Transmit Timestamp
Sequence Number
Priority
Source Node ID
Destination Node ID
Original Packet Length in bytes
Next pointer (for PacketQueue)
Payload Bytes
For efficiency in the simulation, movement of packets is done by passing a pointer to a packet from one
object to another. Usually a packet is constructed by a PacketGenerator from a PCAP file, and it is
usually deleted when it is received by a PacketMonitor. However, packets can also be lost as a result of
Physical link errors (BER) or as a result of Queue congestion.
The Packet Object is derived from the MemRecycler base class.
37
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.10.2 Port Base Class
Simulator objects such as a Switches or Wires have connection points called Ports. Port objects hold the
information necessary to maintain a bidirectional connection between two ports. The transmit side of
one port is connected to the receive side of another port at a specified bit rate. Usually the connection is
symmetric, but in certain cases, connections can be asymmetric. One example of asymmetry occurs in a
typical access link, where the downstream connection operates at a higher bit rate than the upstream
connection. Another example of asymmetry occurs in the simulation for packet generation or
monitoring, because a packet generator does not receive packets.
Ports never exist as stand-alone entities. The Port base class is always used by derived port types for
other objects, , such as WirePorts and SwitchPorts. When a port on derived object is created (such as on
a Wire) that derived object defines the Receive action to take when a packet is received. However, the
transmit action for a port is not known until two ports are connected together. Indeed, the notion of
connecting two ports together is simply a matter of setting the TxAction pointer on one port to point to
the Receive action on another port.
The receive action associated with a port is actually a Functor object. Functors are described in more
detail later in this document. The purpose of a functor in the Port object is to maintain two pointers:
the first is a pointer to the function in the derived port type that will handle the received packet and the
second is a pointer to the port itself, so that (for example) the function responsible for receiving packets
can keep per-port queue information.
Port
TxAction pointer
RxAction
TxBitrate
RxBitrate
38
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.10.3 Wire
A Wire object represents a bidirectional physical connection between two network elements, such as
switches, routers and firewalls. For each direction, a wire has two properties, delay and bit error rate.
Tx
BER[0]
Delay[0]
Wire Port[1]
R
x
Wire Port[0]
Wire
BER[1]
Delay[1]
Tx
R
x
The delay of a packet is given in seconds and is independent of bit rate. This makes sense, because for
example, the bit rate of an optical fiber or of a twisted pair copper cable is not specified. Instead its
physical properties such as propagation speed, bandwidth and loss. The bit rate of a connection is
controlled by the endpoints to which it is connected.
Wire
WirePort[0]
WirePort[1]
OtherPort Pointer
Delay
BER
TxAction pointer (inherited)
RxAction (inherited)
OtherPort Pointer
Delay
BER
TxAction pointer (inherited)
RxAction (inherited)
The wire class also contains two static methods called receive and transmit. The RxAction functor is
initialized with 1) a pointer to the receive method, and 2) a pointer to the associated WirePort. When a
packet is received on a port, the receive method is called, and it is passed a pointer to the WirePort
object as well as a pointer to the Packet. The receive function looks up the appropriate delay value and
(assuming it is not lost due to BER) schedules it to be transmitted by telling the dispatcher enqueue an
action for this packet at the appropriate time in the future. Packet loss due to BER is simulated as a
function of packet size according to the following formula
Pdrop = 1 – (1 - BER)PktLenBits
It is important to note that unlike with a Queue, packets that are dropped due to BER cannot change the
transmit time of subsequent packets over that wire. This makes sense because packet loss due to BER
cannot be determined until the packet is received and checked (e.g. with frame checksum).
The Wire object has two static methods:
39
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
1. receive – receives packets and schedules forwarding
2. transmit – transmits them to the next port
A.10.4 Switch
A Switch object can represent any network element having two or more ports. The purpose of the
Switch object is to model common characteristics of network elements, such as store and forward delay,
queuing delay, and strict priority QoS.
If a Switch object has just two ports, it can model a network element such as a firewall or modem. If a
switch object has more than two ports, it can model a L2 switch or L3 router. A high level view of a
switch object is shown below:
Tx
Switch
Port[3]
R
x
Forwarding Table
DID
Eport
100
0
101
0
10
1
11
1
12
1
13
DROP
Tx
Switch
Port[2]
Tx
Switch
Port[0]
R
x
Switch
Port[1]
Switch (example with 4 ports)
Tx
Each SwitchPort within a switch contains one or more configurable egress queues.
40
R
x
R
x
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
Switch
NumPorts
Port[]
MaxAddr
FwdTable
Id
SwitchPort[0]
SwitchPort[1]
SwitchPort[2]
MySwitch Pointer
NumQueues
Queue[]
PortState (IDLE or ACTIVE)
PortNum
TxAction pointer (inherited)
RxAction (inherited)
MySwitch Pointer
NumQueues
Queue[]
PortState (IDLE or ACTIVE)
PortNum
TxAction pointer (inherited)
RxAction (inherited)
MySwitch Pointer
NumQueues
Queue[]
PortState (IDLE or ACTIVE)
PortNum
TxAction pointer (inherited)
RxAction (inherited)
The Switch object has three static methods:
1. receive – implements store/fwd delay and schedules forwarding
2. forward – implements forwarding decision and enqueues in the appropriate egress queue
3. transmit – read packets from highest priority non-empty egress queue and transmit them
Like the Wire object, the switch object initializes the RxAction for each port with a receive function
pointer and a pointer to the SwitchPort object. The receive method calculates the store and forward
delay associated with each packet by dividing the packet length in bits by the ingress bit rate of the port.
After the store and forward delay, the packet is ready to get a forwarding decision. This is implemented
by scheduling an event to call the packet forwarding method after an appropriate store and forward
delay, and passing pointers to both the switch object and the packet to the forwarding method.
The forwarding method reads the DID (destination ID) of the packet and performs a lookup in the
forwarding table. The forwarding table is statically pre-configured by the top-level simulation according
to the simulation topology. If the DID is out of range, or if there is no forwarding rule for the specified
address, the packet is dropped. Otherwise, the packet is enqueued in the appropriate egress queue
(based on the priority of the packet and the availability of Queues). If the egress port is in the IDLE state,
its state is changed to ACTIVE and the transmit method is called.
41
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The transmit method examines the output queues and dequeues the highest priority available packet. It
then performs the transmit action associated with that port and schedules itself to be called again after
the serialization delay of the packet. If there are no packets available to transmit, the egress port marks
itself as IDLE and does not schedule itself to be called again.
This model of a switch can be extended in the future to incorporate other features found in more
advanced network elements, such as more advanced QoS mechanisms.
42
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.10.5 PacketQueue
A packet queue object represents a FIFO with limited depth. The elements of a packet queue are as
follows:
PacketQueue
Head Pointer
Tail Pointer
Fullness (Bytes)
MaxDepth (Bytes)
The Head and Tail pointers are simply pointers to the first and last packet in the queue. Packets may be
enqueued if there is enough space available in the queue to hold the packet. It is assumed that packets
can be packed into the queue memory without wasting any memory.
The packets in the queue are maintained as a conventional linked list.
43
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.11 Simulator Input and Output Objects
A.11.1 PacketGeneratorPCAP
The PacketGeneratorPCAP object reads packets from a PCAP file and drives them into the simulation. It
is derived from a Port object. The following table shows the parameters, internal states and inherited
members for it.
PacketGeneratorPCAP
Parameters
Internal State
Inherited Members
Filename
File pointer
TxAction pointer
SID / DID
Sequence Number
RxAction
Start Delay
LittleEndian
TxBitrate
Bandwidth Scale Factor
NanoTime
RxBitrate
PPM Offset
First Packet Timestamp
Randomness
Shaper State
Priority
Repeat Count
Shaper PIR
Shaper PBS

Filename – the file name of the input PCAP file (may be relative or absolute).

DID/SID – the source and destination ID of the packets that this PacketGeneratorPCAP sends. It
has no relation to the actual addresses of the packets in the file. See the section on Address
conventions for more information.

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.
44
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2

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. What this
means, is that 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. These options are useful if the PCAP file is has bursts or microbursts.
45
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.11.2 PacketMonitorPCAP
The PacketMonitorPCAP object receives packets from a Switch and saves them to an output PCAP file,
and also saves the delay and loss information for those packets to an ASCII CSV “.out” file.
The following table shows the parameters, internal states and inherited members for it.
PacketMonitorPCAP
Parameters
Internal State
Inherited Members
CSV File Name
CSV File pointer
TxAction pointer
PCAP File Name
PCAP File Pointer
RxAction
SID / DID
Packet Count
TxBitrate
Description
Last Seq Number
RxBitrate

CSV File Name – this is the name of the “.out” CSV file

PCAP File Name – this is the name of the PCAP output file

SID/DID – this is source and destination ID pair that this monitor should look for. It will ignore
all packets that do not match the SID/DID that is configured.

Description – this is a description of the output that is placed at the top of the “.out” file
46
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.11.3 “.out” File Format
The “.out” file format is a standard ASCII CSV format with three columns. The first column is the
simulation time in seconds that the packet was transmitted, the second column is usually Delay (usually
in milliseconds, other units can be specified in the header) and the third column is usually a Drop flag (1
means drop, 0 means successful delivery). The delay units and column order can be changed by
adjusting the column headings and the Delay Unit header field.
The “.out” file has a header with additional information.
An example is shown below:
Source:,"TIA TR30.3: TIA-921B"
Creation Date:,05/05/2010
Description:, Set Top Box #1 IPTV Downstream
Content-Encoding :, ASCII
Delay Unit:,ms
Time, Delay, Drop
0.000000000,22.518541212,0
0.019323502,22.518541212,0
0.021047588,22.518541212,0
0.021869050,22.518541212,0
0.023355058,22.518541212,0
0.025128660,22.518541212,0
2.000000000,14.241843818,0
2.217940424,14.022805455,0
2.221329923,14.145793333,0
2.292414978,14.102274545,0
2.559969646,14.023562303,0
3.161421736,21.071927650,0
3.235437406,30.352536693,0
3.236295847,30.536035327,1
3.414751156,18.975278612,0
3.563506112,36.299552277,0
3.678545565,17.087872868,0
3.964892379,14.022805455,0
3.970588431,14.573034303,0
3.972389489,14.573034303,0
3.974369414,15.531071169,0
3.975693763,14.578600829,0
4.010895351,14.573034303,0
4.011520585,15.026588428,0
4.026753201,21.923139616,1
4.910704084,14.106815636,0
47
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.12 Other Base Classes
A.12.1 MemRecycler
MemRecycler is a template base class that overrides the default new and delete operators. The
replacement new and delete operators maintain a stack of available memory buffers that can be very
quickly O(1) accessed. If there are no buffers available in the linked list, then another one is obtained
from malloc().
This strategy works well in situations where a few types of fixed size objects must be quickly created and
destroyed for three reasons
1. It avoids the overhead of using malloc() for every allocation. For many situations, the
MemRecycler object will reach a point where enough buffers of each type have been allocated
and these buffers keep being reused for the remainder of program execution.
2. There is a separate stack for each template type, meaning that every element in the stack is
exactly the right size.
3. The elements in the stack are used in LIFO order, which may help maintain locality of reference
for efficient use of virtual memory and/or CPU cache.
48
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.13 Simulator Objects for Discrete Event Simulation
A.13.1 Action
An Action is simply a pointer to a function taking two void pointers. Example actions include the receive
and transmit methods for Wire and Switch objects.
typedef void (*Action)(void *, void *);
A.13.2 Functor
In this simulation, a Functor object is a combination of an Action pointer and an object pointer. The
function call operator is overloaded in the Functor class, so that “calling” a Functor object with a void
pointer results in invoking the function referred to by the Action pointer, and providing the object
pointer as the first argument and the void pointer as the second argument.
class Functor
{
public:
Functor(Action action, void *arg1) : mAction(action), mArg1(arg1) { };
inline void operator()(void *arg2) { (*mAction)(mArg1,arg2); }
private:
Action mAction;
void
*mArg1;
}
The purpose of a functor is to encapsulate the function pointer and the first argument pointer for that
function. This is a common way to mimic the behavior of a closure in C++.
A.13.3 Event
An Event object holds an action, the arguments for the Action and the time at which to execute the
action. The purpose of an event is to encapsulate something that needs to happen at a time in the
future.
The event object is derived from the MemRecycler base class for efficiency reasons.
Event objects have a Doit() method that invokes the specified Action with the specified arguments.
49
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.13.4 Dispatcher/Scheduler
The Dispatcher object maintains a list of events in sorted order, with the soonest event first. Other
objects in the simulator, such as Wires and Switches may schedule events by calling the Scheduler
routines. There are two scheduler routines:
1. ScheduleAt – Schedules an event to occur at an absolute time in the future. This can be used to
schedule events to occur at precise times that are not dependent on the current simulation
time.
2. ScheduleIn – Schedules an event to occur at a relative time in the future. This can be used to
schedule events to occur at a precise amount of time after the current simulator time.
The event list maintained by the scheduler is held in a Red-Black tree.
The initialization routine for the Dispatcher must be called early in the simulation to ensure that it is
ready to receive events. This can be done with the following code
Dispatcher::Initialize();
The dispatcher can be started in one of two ways:
1. RunTill(T) – Invokes the dispatcher to execute events until the time reaches T, or there are no
more events to execute
2. RunFor(T) – Invokes the dispatcher to execute events for T seconds, or there are no more events
to execute.
When running, the dispatcher removes the event with the smallest time from the event list. If that event
is at a time in the future, the Dispatcher sets the simulator’s current time to the time of that event and
then it executes the event.
At the end of a simulation, it is good practice to shut down the Dispatcher by calling the ShutDown
method
Dispatcher::ShutDown();
The dispatcher object is a singleton class.
50
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.13.5 Red-Black Tree
As mentioned above, the Dispatcher keeps a list of Events in sorted order. It uses a Red-Black tree to do
this. A Red-Black tree is a type of binary tree which is partially balanced. Specifically, the tree is balanced
such that the in the worst case, the longest root-to-leaf path is no more than twice as long as the
shortest root-to-leaf path. This ensures that insertion, deletion and other operations are always O(log N)
in complexity.
Because the worst case performance of operations on the Red-Black tree is guaranteed to be O(log N),
and because the additional overhead of the self-balancing is relatively minor, Red-Black trees are well
suited for a variety of applications, such as scheduling events.
For more information on Red-Black trees, refer to
http://en.wikipedia.org/wiki/Red-black_tree
51
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.14 Numbering conventions in the top Level Simulator (CORE2LAN.cpp)
The general numbering convention for source ID and destination ID is to assign IDs from 1 to 50 to
nodes in the core of the network, and to assign IDs from 100 to 150 to the Remote LAN network (inside
the home). The reason for doing this is that it makes it easy to configure the forwarding tables inside the
switches, routers, modems, firewalls etc within the simulation.
There are four IDs in the core of the network
IDs in the Network Core
Name
SRV1
SRV2
SRV3
SRV4
ID
10
11
12
13
Description
Server 1 at CoreSw[0].Port(2)
Server 2 at CoreSw[0].Port(3)
Server 3 at CoreSw[0].Port(4)
Server 4 at CoreSw[0].Port(5)
There are 9 IDs in the remote (home) network
IDs in the Remote (Home)
Name
PC1
PC2
STB1
STB2
STB3
STB4
STB5
STB6
STB7
STB8
ID
101
102
103
104
105
106
107
108
109
110
Description
Home PC #1
Home PC #2
Set Top Box #1
Set Top Box #2
Set Top Box #3
Set Top Box #4
Set Top Box #5
Set Top Box #6
Set Top Box #7
Set Top Box #8
52
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The assignment of PacketGenerator instance names to IDs is as follows:
Packet Generator Instance Name to SID/DID
Name
SID
DID
PktGenPCAPFwdI1
PktGenPCAPFwdI2
PktGenPCAPFwdI3
PktGenPCAPFwdI4
PktGenPCAPFwdI5
PktGenPCAPFwdI6
PktGenPCAPFwdI7
PktGenPCAPFwdI8
PktGenPCAPFwdI9
PktGenPCAPFwdI10
PktGenPCAPFwdI11
PktGenPCAPFwdI12
PktGenPCAPFwdI13
PktGenPCAPFwdI14
PktGenPCAPFwdI15
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
PC1 (101)
PC2 (102)
STB1 (103)
STB2 (104)
STB3 (105)
STB4 (106)
STB5 (107)
STB6 (108)
STB7 (109)
STB8 (110)
STB8 (110)
STB8 (110)
STB8 (110)
STB8 (110)
STB8 (110)
The assignment of PacketMonitor instance names to IDs is as follows:
Packet Monitor Instance Name to SID/DID
Name
SID
DID
Name
PktMonPCAPFwdI1
PktMonPCAPFwdI2
PktMonPCAPFwdI3
PktMonPCAPFwdI4
PktMonPCAPFwdI5
PktMonPCAPFwdI6
PktMonPCAPFwdI7
PktMonPCAPFwdI8
PktMonPCAPFwdI9
PktMonPCAPFwdI10
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
SRV1 (10)
PC1 (101)
PC2 (102)
STB1 (103)
STB2 (104)
STB3 (105)
STB4 (106)
STB5 (107)
STB6 (108)
STB7 (109)
STB8 (110)
PC #1 Downstream
PC #2 Downstream
Set Top Box #1 Downstream
Set Top Box #2 Downstream
Set Top Box #3 Downstream
Set Top Box #4 Downstream
Misc Downstream 1
Misc Downstream 2
Misc Downstream 3
Misc Downstream 4
53
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
A.15 File List
The following is a list of files that make up the simulator. First is the top level directory named “sim”
./sim
There are four primary subdirectories of sim, namely the pcap input files, the simulator source code, the
test case parameter files (tc) and the output results directory.
./sim/pcap
./sim/src
./sim/tc
./sim/out
Within the top level “sim” directory, there are also two convenience scripts for running the simulator, as
described earlier:
./sim/runall.ss
./sim/runone.ss
The simulator input PCAP files are in the pcap/ subdirectory. Since these files are large, they are typically
distributed separately from the model source code, and often the pcap subdirectory is a soft-link to a
separate directory. Here is a list of typical input PCAP files.
pcap/12Mb_cbr.pcap
pcap/12Mb_vbr.pcap
pcap/6Mb_cbr.pcap
pcap/6Mb_vbr.pcap
pcap/BitTorrent_Down_nopayload.pcap
pcap/BitTorrent_Up_nopayload.pcap
pcap/Hulu480p_Down_nopayload.pcap
pcap/Hulu480p_Up_nopayload.pcap
pcap/POP3_Down.pcap
pcap/POP3_Up.pcap
pcap/YouTube1080p_Down_nopayload.pcap
pcap/YouTube1080p_Up_nopayload.pcap
pcap/vocal_g729_dir1.pcap
pcap/vocal_g729_dir2.pcap
pcap/vocal_v17_t38_dir1.pcap
pcap/vocal_v17_t38_dir2.pcap
pcap/vocal_v34_t38_dir1.pcap
pcap/vocal_v34_t38_dir2.pcap
The C++ and C source code is in the sim/src directory:
./sim/src/Action.h
./sim/src/Bitrate.h
./sim/src/CORE2LAN.cpp
54
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
./sim/src/CORE2LAN_Defaults.h
./sim/src/Clock.cpp
./sim/src/Clock.h
./sim/src/Dispatcher.cpp
./sim/src/Dispatcher.h
./sim/src/Event.cpp
./sim/src/Event.h
./sim/src/Functor.h
./sim/src/Makefile
./sim/src/MemRecycler.h
./sim/src/PCAP.h
./sim/src/Packet.cpp
./sim/src/Packet.h
./sim/src/PacketGenerator.cpp
./sim/src/PacketGenerator.h
./sim/src/PacketGeneratorPCAP.cpp
./sim/src/PacketGeneratorPCAP.h
./sim/src/PacketMonitor.cpp
./sim/src/PacketMonitor.h
./sim/src/PacketMonitorPCAP.cpp
./sim/src/PacketMonitorPCAP.h
./sim/src/PacketQueue.cpp
./sim/src/PacketQueue.h
./sim/src/PacketRO.cpp
./sim/src/PacketRO.h
./sim/src/Port.cpp
./sim/src/Port.h
./sim/src/SimParam.cpp
./sim/src/SimParam.h
./sim/src/Switch.cpp
./sim/src/Switch.h
./sim/src/Wire.cpp
./sim/src/Wire.h
./sim/src/bin.debug
./sim/src/bin.debug/CORE2LAN.exe
./sim/src/histo2png.pl
./sim/src/out2histo.pl
./sim/src/out2png2.pl
./sim/src/proc.info.pl
./sim/src/redblack.c
./sim/src/redblack.h
Within the source subdirectory there are several plotting utilities written in Perl
./sim/src/histo2png.pl
./sim/src/out2histo.pl
./sim/src/out2png2.pl
The individual test case parameter files are in the sim/tc directory.:
55
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
./sim/tc/Dp1.param
./sim/tc/Dp2.param
./sim/tc/Dp3.param
./sim/tc/Dp4.param
./sim/tc/Dp5.param
./sim/tc/Dp6.param
./sim/tc/Dp7.param
./sim/tc/Du1.param
./sim/tc/Du2.param
./sim/tc/Du3.param
./sim/tc/Du4.param
./sim/tc/Du5.param
./sim/tc/Du6.param
./sim/tc/Du7.param
./sim/tc/Dw1.param
./sim/tc/Dw2.param
./sim/tc/Dw3.param
./sim/tc/Dw4.param
./sim/tc/Dw5.param
./sim/tc/Dw6.param
./sim/tc/Dw7.param
./sim/tc/Dw8.param
./sim/tc/Gp1.param
./sim/tc/Gp2.param
./sim/tc/Gp3.param
./sim/tc/Gp4.param
./sim/tc/Gp5.param
./sim/tc/Gp6.param
./sim/tc/Gp7.param
./sim/tc/Gu1.param
./sim/tc/Gu2.param
./sim/tc/Gu3.param
./sim/tc/Gu4.param
./sim/tc/Gu5.param
./sim/tc/Gu6.param
./sim/tc/Gu7.param
./sim/tc/Gw1.param
./sim/tc/Gw2.param
./sim/tc/Gw3.param
./sim/tc/Gw4.param
./sim/tc/Gw5.param
./sim/tc/Gw6.param
./sim/tc/Gw7.param
./sim/tc/Gw8.param
./sim/tc/core.param
When a test case is run a log file of results is maintained in the info.log file. This is mainly for regression
testing the simulation.
56
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
./sim/info.log
The output results for each test case are placed in a subdirectory of the “sim/out” directory. For each
PacketMonitorPCAP that Is configured in the parameter file, there is an output PCAP file and an output
“.out” file (described below). The scripts for automatically running the simulation and postprocesses
create plots of delay/jitter and packet loss versus time and also plot a histogram of delay. The plots are
in PNG format.
./sim/out/Dw1
./sim/out/Dw1/Dw1-Fax_v34_t38_Fwd-PDV.png
./sim/out/Dw1/Dw1-Fax_v34_t38_Fwd.png
./sim/out/Dw1/Dw1-Fax_v34_t38_Rev-PDV.png
./sim/out/Dw1/Dw1-Fax_v34_t38_Rev.png
./sim/out/Dw1/Dw1-HDTV1_Down-PDV.png
./sim/out/Dw1/Dw1-HDTV1_Down.png
./sim/out/Dw1/Dw1-VoIP1_Fwd-PDV.png
./sim/out/Dw1/Dw1-VoIP1_Fwd.png
./sim/out/Dw1/Dw1-VoIP1_Rev-PDV.png
./sim/out/Dw1/Dw1-VoIP1_Rev.png
./sim/out/Dw1/Fax_v34_t38_Fwd-PDV.csv
./sim/out/Dw1/Fax_v34_t38_Fwd.out
./sim/out/Dw1/Fax_v34_t38_Fwd.pcap
./sim/out/Dw1/Fax_v34_t38_Rev-PDV.csv
./sim/out/Dw1/Fax_v34_t38_Rev.out
./sim/out/Dw1/Fax_v34_t38_Rev.pcap
./sim/out/Dw1/HDTV1_Down-PDV.csv
./sim/out/Dw1/HDTV1_Down.out
./sim/out/Dw1/HDTV1_Down.pcap
./sim/out/Dw1/VoIP1_Fwd-PDV.csv
./sim/out/Dw1/VoIP1_Fwd.out
./sim/out/Dw1/VoIP1_Fwd.pcap
./sim/out/Dw1/VoIP1_Rev-PDV.csv
./sim/out/Dw1/VoIP1_Rev.out
./sim/out/Dw1/VoIP1_Rev.pcap
./sim/out/Dw1/info.log
./sim/tc/common.tcl
There are two convenience scripts to help run the simulation and plot results
runcl.ss
runcl_plotone.ss
A.16 Common TCL file
There is one TCL support file that helps with setting up simulation parameters
sim/tc/common.tcl
57
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The common TCL support file “common.tcl” helps simplify the process of setting variables for the PCAP
generators and monitors.
The first thing that the common.tcl file does is create the output directory and set the variable $outdir
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # Create the output directory
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - set outroot "out"
set outdir [file join $outroot [file rootname [file tail $paramfile]]]
file mkdir $outdir
The next routine “gset” is a general purpose routine for setting a global variable
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # gset -- set a variable at global scope
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - proc gset {name value} {
upvar \#0 $name $name
set $name $value
}
The next routine defines parameters for a PCAP generator
# - - - - - - - - # Define parameters
# - - - - - - - - proc PCAP_Generator
if
if
if
if
if
if
if
if
{$start
{$bwscale
{$ppm
{$rand
{$prio
{$rept
{$PIR
{$PBS
!=
!=
!=
!=
!=
!=
!=
!=
- - for a
- - {name
{rand
""}
""}
""}
""}
""}
""}
""}
""}
{
{
{
{
{
{
{
{
- - - - - - - - - - - - - - - - - - - PCAP Generator
- - - - - - - - - - - - - - - - - - - file {start ""} {bwscale ""} {ppm ""} \
""} {prio ""} {rept ""} {PIR ""} {PBS ""}} {
gset ${name}_FileName
"pcap/$file.pcap"
gset ${name}_StartDelay $start
}
gset ${name}_BW_Scale
$bwscale }
gset ${name}_PPM_Offset $ppm
}
gset ${name}_Randomness $rand
}
gset ${name}_Priority
$prio
}
gset ${name}_RepeatCnt
$rept
}
gset ${name}_ShaperPIR
$PIR
}
gset ${name}_ShaperPBS
$PBS
}
}
The next routine defines parameters for a PCAP monitor
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # Define parameters for a PCAP Monitor
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - proc PCAP_Monitor {name file} {
global outdir
gset ${name}_OutFileName
"$outdir/$file.out"
gset ${name}_PCAPFileName
"$outdir/$file.pcap"
}
58
PN-3-0062-RV2 (to become TIA-921-B)
TR-30.3/10-12-027r2
The next routines help to set network parameters for the access link
# - - - - - - - - - - - - - - - - - - - - - - - - - - # Set Global Vars for Access Link Parameters
# - - - - - - - - - - - - - - - - - - - - - - - - - - proc _Access_Params {name
{SpeedDown ""}
{SpeedUp ""}
{BER_Fwd ""}
{BER_Rev ""}
{LatencyDown ""}
{LatencyUp ""}} {
if {$SpeedDown
!= ""} { gset ${name}_SpeedDown
if {$SpeedUp
!= ""} { gset ${name}_SpeedUp
if {$BER_Fwd
!= ""} { gset ${name}_BER_Fwd
if {$BER_Rev
!= ""} { gset ${name}_BER_Rev
if {$LatencyDown != ""} { gset ${name}_LatencyDown
if {$LatencyUp
!= ""} { gset ${name}_LatencyUp
if {$ReorderProb != ""} { gset RO_Fwd_Prob
if {$ReorderProb != ""} { gset RO_Rev_Prob
}
- - - - - - - - -
$SpeedDown
$SpeedUp
$BER_Fwd
$BER_Rev
$LatencyDown
$LatencyUp
$ReorderProb
$ReorderProb
}
}
}
}
}
}
}
}
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # Select a set of access link parameters based on name
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - proc Set_Access_Params {paramset} {
#
Node SpeedDn SpeedUp BER_Fwd BER_Rev LatcyDn LatcyUp
if {$paramset == "dsl_w1"}
{ _Access_Params
RACC
33e6
3e6
1e-8
1e-8
1e-3
1e-3
} elseif {$paramset == "dsl_w2"}
{ _Access_Params
RACC
33e6
3e6
1e-8
1e-8
1e-3
1e-3
} elseif {$paramset == "dsl_w3"}
{ _Access_Params
RACC
33e6
3e6
1e-8
1e-8
1e-3
1e-3
} elseif {$paramset == "dsl_w4"}
{ _Access_Params
RACC
22e6
2e6
1e-8
1e-8
1e-3
1e-3
} elseif {$paramset == "dsl_w5"}
{ _Access_Params
RACC
16e6
1e6
1e-7
1e-7
1e-3
1e-3
} elseif {$paramset == "dsl_w6"}
{ _Access_Params
RACC
16e6
1e6
1e-7
1e-7
1e-3
1e-3
} elseif {$paramset == "dsl_w7"}
{ _Access_Params
RACC
16e6
1e6
1e-7
1e-7
1e-3
1e-3
} elseif {$paramset == "dsl_w8"}
{ _Access_Params
RACC
10e6
1e6
1e-7
1e-7
1e-3
1e-3
} elseif {$paramset == "pon_w1"}
{ _Access_Params
RACC
50e6
25e6
1e-12
1e-12
1e-3
1e-3
} elseif {$paramset == "pon_w2"}
{ _Access_Params
RACC
50e6
25e6
1e-12
1e-12
1e-3
1e-3
} elseif {$paramset == "pon_w3"}
{ _Access_Params
RACC
35e6
25e6
1e-11
1e-11
1e-3
1e-3
} elseif {$paramset == "pon_w4"}
{ _Access_Params
RACC
35e6
25e6
1e-11
1e-11
1e-3
1e-3
} elseif {$paramset == "pon_w5"}
{ _Access_Params
RACC
25e6
25e6
1e-10
1e-10
1e-3
1e-3
} elseif {$paramset == "pon_w6"}
{ _Access_Params
RACC
25e6
25e6
1e-9
1e-9
1e-3
1e-3
} elseif {$paramset == "pon_w7"}
{ _Access_Params
RACC
25e6
25e6
1e-9
1e-9
1e-3
1e-3
} elseif {$paramset == "pon_w8"}
{ _Access_Params
RACC
15e6
5e6
1e-9
1e-9
1e-3
1e-3
} elseif {$paramset == "pon_p1_u1"} { _Access_Params
RACC
35e6
35e6
1e-12
1e-12
1e-3
1e-3
} elseif {$paramset == "pon_p2_u2"} { _Access_Params
RACC
35e6
15e6
1e-12
1e-12
1e-3
1e-3
} elseif {$paramset == "pon_p3_u3"} { _Access_Params
RACC
25e6
25e6
1e-11
1e-11
1e-3
1e-3
} elseif {$paramset == "pon_p4_u4"} { _Access_Params
RACC
15e6
5e6
1e-9
1e-9
1e-3
1e-3
} elseif {$paramset == "pon_p5_u5"} { _Access_Params
RACC
5e6
2e6
1e-9
1e-9
1e-3
1e-3
} elseif {$paramset == "pon_p6_u6"} { _Access_Params
RACC
15e6
5e6
1e-9
1e-9
1e-3
1e-3
} elseif {$paramset == "pon_p7_u7"} { _Access_Params
RACC
5e6
2e6
1e-9
1e-9
1e-3
1e-3
} elseif {$paramset == "dsl_p1_u1"} { _Access_Params
RACC
24e6
3.0e6
1e-8
1e-8
1e-3
1e-3
} elseif {$paramset == "dsl_p2_u2"} { _Access_Params
RACC
18e6
1.5e6
1e-8
1e-8
1e-3
1e-3
} elseif {$paramset == "dsl_p3_u3"} { _Access_Params
RACC
12e6
1.5e6
1e-8
1e-8
1e-3
1e-3
} elseif {$paramset == "dsl_p4_u4"} { _Access_Params
RACC
6e6
1.0e6
1e-7
1e-7
1e-3
1e-3
} elseif {$paramset == "dsl_p5_u5"} { _Access_Params
RACC
3e6
1.0e6
1e-7
1e-7
1e-3
1e-3
} elseif {$paramset == "dsl_p6_u6"} { _Access_Params
RACC
6e6
1.0e6
1e-7
1e-7
1e-3
1e-3
} elseif {$paramset == "dsl_p7_u7"} { _Access_Params
RACC
3e6
1.0e6
1e-7
1e-7
1e-3
1e-3
} elseif {$paramset == "core_only"} { _Access_Params
RACC
1e9
1e9
1e-12
1e-12
0
0
} else {
error "ERROR: Invalid Net_Param name $paramset."
}
}
The next routines help to set network parameters for the core
59
PN-3-0062-RV2 (to become TIA-921-B)
# - - - - - - - # Set Global Vars
# - - - - - - - proc _Core_Params
if {$numsw
if {$Latency
if {$Speed
TR-30.3/10-12-027r2
- - - - - - - - - - - - - - - - - - - - - - - for Access Link Parameters
- - - - - - - - - - - - - - - - - - - - - - - {{numsw ""}
{Latency ""}
{Speed ""}} {
!= ""} { gset NumCoreSW
$numsw
}
!= ""} { gset CORE_Latency
$Latency
}
!= ""} { gset CORE_Speed
$Speed
}
}
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # Select a set of core parameters based on name
# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - proc Set_Core_Params {paramset} {
#
NumCoreSW
if {$paramset == "w1"}
{ _Core_Params
3
} elseif {$paramset == "w2"}
{ _Core_Params
4
} elseif {$paramset == "w3"}
{ _Core_Params
5
} elseif {$paramset == "w4"}
{ _Core_Params
6
} elseif {$paramset == "w5"}
{ _Core_Params
7
} elseif {$paramset == "w6"}
{ _Core_Params
8
} elseif {$paramset == "w7"}
{ _Core_Params
9
} elseif {$paramset == "w8"}
{ _Core_Params
10
}
}
}
}
}
}
}
elseif
elseif
elseif
elseif
elseif
elseif
elseif
{$paramset
{$paramset
{$paramset
{$paramset
{$paramset
{$paramset
{$paramset
==
==
==
==
==
==
==
"p1_u1"}
"p2_u2"}
"p3_u3"}
"p4_u4"}
"p5_u5"}
"p6_u6"}
"p7_u7"}
{
{
{
{
{
{
{
_Core_Params
_Core_Params
_Core_Params
_Core_Params
_Core_Params
_Core_Params
_Core_Params
} elseif {$paramset == "core_only"} { _Core_Params
} else {
error "ERROR: Invalid Net_Param name $paramset."
}
}
# - - - - - - - - - - - - - - - # Other Misc parameter settings
# - - - - - - - - - - - - - - - set CORESW_BufSizeBytes
[expr
set DSLAM_BufSizeBytes
[expr
set Firewall_BufSizeBytes
[expr
set Modem_BufSizeBytes
[expr
set RLAN_Speed
65*1518]
65*1518]
65*1518]
65*1518]
100E6
# - - - - - - - - - - - - - - - # Set Default Simulation length
# - - - - - - - - - - - - - - - set SimLengthSeconds
[expr 10*60]
60
3
4
5
8
10
12
15
5
Latency
10e-3
25e-3
50e-3
75e-3
85e-3
100e-3
125e-3
150e-3
Speed
1e9
1e9
1e9
1e9
1e9
1e9
1e9
1e9
10e-3
25e-3
50e-3
75e-3
100e-3
200e-3
250e-3
1e9
1e9
1e9
1e9
1e9
1e9
1e9
100e-3
1e9
PN-3-0062-RV2 (to become TIA-921-B)
Annex B
TR-30.3/10-12-027r2
(Normative) – C++ Source Code of Discrete Event Simulator
The C++ source code of the simulator is included in folder xxx of the electronic attachment.
61
PN-3-0062-RV2 (to become TIA-921-B)
Annex C
TR-30.3/10-12-027r2
(Normative) – Packet Capture Files of Interfering Traffic
Table C.1 lists the pcap files used in the standard test cases. These files are included in folder
xxx in the electronic attachment.
Table C.1: PCAP Files of Interfering Traffic
QoS
PCAP File
Avg
Packet Avg Bit
Data Size Packets Duration Pkt
Rate
Rate
Size
2
HD_cbr
275756340
201282
142 1370
2
HD_vbr
196918938
143737
142 1370
2
SD_cbr
274844350
200617
285 1370
2
7
SD_vbr
OTT1_Down
197616080
119929381
144246
79619
285 1370
144 1506
7
7
OTT1_Up
OTT2_Down
1777873
110344529
32832
73522
144
54
331 1501
7
7
OTT2_Up
P2P_Down
2100467
34546941
36356
30000
332
58
147 1152
7
7
P2P_Up
HTTP_Down
5412102
27377604
25500
20000
152 212
138 1369
7
7
7
1
1
HTTP_Up
ipfax_v34_t38_fwd
ipfax_v34_t38_rev
voip_g729_fwd
voip_g729_rev
1451588
53619
31376
603120
602784
15000
278
156
7180
7176
176
49
46
215
215
62
97
193
201
84
84
5s peak 1s peak Description
High
Definition
IPTV Flow,
Constant Bit
1419 15555964 15558816 15574160 Rate
High
Definition
IPTV Flow,
Variable Bit
1014 11112049 13112544 18555280 Rate
Standard
Definition
IPTV Flow,
Constant Bit
703 7702130 7704880 7715840 Rate
Standard
Definition
IPTV Flow,
Variable Bit
507 5553410 6608880 8789920 Rate
554 6678690 7160352 7327760 Progressive
Downloaded
Over-TheTop High
Definition
229
99008 115257 121824 Video
222 2662988 12364163 13938272 Adaptively
Streamed
Over-theTop
Standard
Definition
110
50663 229643 272608 Video
205 1885957 3261356 3903608 Peer-to-Peer
File
Download
168 285154 530008 703416 and Sharing
145 1582495 2167475 4646512 Web
Browser
85
65997
89577 193624 Transactions
6
8809
50820
88000
Fax-over-IP
3
5468
45320
85600
33
22406
22444
22848 G.729 Voice33
22403
22444
22848 over-IP
PN-3-0062-RV2 (to become TIA-921-B)
Annex D
TR-30.3/10-12-027r2
(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.
The .out files can be in either a time based or packet based application as the user / emulator
implementer see fit. In time based implementation the impairments are applied on a time cell
basis that advances without regard to the presence or absence of packets. In a packet based
implementation the impairments are applied on a packet by packet basis. [reword]
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
[write me]
____________________
63